In 15 minutes…

Оглавление:
П. Осика, В. Пантюхин

Вертикальные и Введение ................................................................................................ 4

Многоуровневая архитектура................................................... 4

горизонтальные
Горизонтальная и вертикальная архитектуры компьютеров... 5
Вертикальная архитектура ....................................................... 6
Горизонтальная архитектура ................................................... 6
Сравнение вертикальной и горизонтальной архитектур ... 8

архитектуры
Диагональная архитектура ..................................................... 11
Производительность ......................................................................... 11
Процессоры и интерконнект ................................................... 12
Система ввода-вывода ............................................................. 12
Операционная система ............................................................. 13
Доступность системы................................................................ 13
Оптимизация приложений ...................................................... 13
Сайзинг приложений ........................................................................ 14
Уровень базы данных. .............................................................. 15
Уровень приложений................................................................ 18
Уровень представлений. .......................................................... 19
TCO приложений в горизонтальных и вертикальных системах.
............................................................................................................... 20
Пример 1: ................................................................................ 22
Пример 2: ................................................................................ 23
Сравнение уровня доступности вертикальных и
горизонтальных систем.................................................................... 25
Пример 3: ................................................................................ 27
Консолидация..................................................................................... 28
Варианты многоуровневой реализации........................................ 30
Приведи свои мозги в порядок …
Rev. 0.9

Санкт-Петербург 2005
2

Вертикальная 2-уровневая ...................................................... 30
Вертикальная 3-уровневая ...................................................... 31
Горизонтальная 3-уровневая .................................................. 32
Сравнение TCA горизонтальной и вертикальной 3-
уровневых реализаций.......................................................... 33
Диагональная 3-уровневая ...................................................... 34
Сравнение TCA диагональной и горизонтальной 3-
уровневых реализаций.......................................................... 35
Выводы. ............................................................................................... 36
3 4
Введение
На протяжении нескольких последних лет в центрах обработки
данных (ЦОД) развивается тенденция появления комплексов,
состоящих из малых горизонтально-масштабируемых серверов.
Стало модно рассуждать о простоте реализации, неограниченной
масштабируемости и низкой стоимости внедрения и обслуживания
таких систем. С точки зрения многих администраторов ЦОД,
позиции классических вертикально-масштабируемых средних и
«тяжелых» систем заметно пошатнулись. В тоже время, рынок
таких систем говорит об обратном. Например, по данным IDC,
продажи серверов среднего уровня (от 25.000$ до 250.000$) только
за вторую половину 2005 года выросли на 15,6%, а продажи
серверов класса hi-end (стоимостью выше 500.000$) выросли на
19,2%.
Какой же подход лучше? Какую архитектуру, вертикальную или
горизонтальную, выбирать для центра обработки данных? Конечно,
простого ответа не существует. Все зависит от конкретных задач и
требований к ним. Цель этого документа – выработать критерии
оценки и показать, в каких случаях оправдано то или иное
решение.
Многоуровневая архитектура
Большинство современных приложений, используемых в центрах
обработки данных, в той или иной мере реализуются в рамках, так
называемой, многоуровневой архитектуры (multi-tiers
architecture). Модель разделения на несколько уровней
обеспечивает эффективный способ организации распределенных
задач и методологию их реализации в соответствием с
необходимым уровнем сервиса и выполняемой роли в ЦОД.
 Вертикальная архитектура
Вертикальная архитектура обычно реализуется с использованием
многопроцессорных (больше 4 CPU) SMP серверов. В них только
один экземпляр операционной системы и единые подсистемы
памяти и ввода-вывода (см. рис. 2). Обычно все эти компоненты
размещены внутри одного корпуса. Общий интерконнект обладает
низкой латентностью и высокой пропускной способностью.
Ресурсы добавляются с помощью увеличения количества плат в
сервере.

Рисунок 1

Обычно выделяют три уровня, каждый из которых имеет свои

отличительные особенности:
• Уровень 1 или презентационный уровень использует
горизонтальное масштабирование большого количества
малых серверов.
• Уровень 3 или уровень баз данных использует Рисунок 2
вертикальное масштабирование нескольких «тяжелых»
многопроцессорных серверов. В вертикально масштабируемой системе, на уровне ОС
• Уровень 2 или уровень приложений использует оба оперативная память общая (SMP) и доступ любого процессора и
варианта масштабирования: горизонтальное и вертикальное. компоненты системы ввода-вывода к ней равнозначны. Проще
говоря, память видится ОС как один большой кусок.

Горизонтальная и вертикальная архитектуры Горизонтальная архитектура

компьютеров. Альтернативный метод масштабирования – горизонтальный. Этот
метод обеспечивается объединением (чаще всего кластеризацией)
нескольких серверов через сеть. Интерконнект использует
стандартные сетевые адаптеры, например Fast Ethernet или Gigabit
5 6
Ethernet (GBE). Эти способы соединения по сравнению
с вертикальными системами обладают гораздо меньшей Сравнение вертикальной и горизонтальной архитектур
пропускной способностью и более высокой латентностью.
Все ресурсы находятся внутри узлов. Каждый узел имеет свои Вертикальные системы Горизонтальные системы
процессоры (обычно от 1 до 4), память и систему ввода-вывода, Большое разделяемое Малый объем неразделяемой
которая может разделяться между узлами. Каждый узел имеет пространство памяти памяти
собственный экземпляр операционной системы. Ресурсы Много зависимых потоков Много независимых потоков
наращиваются только добавлением новых узлов. выполнения выполнения
Сильно-связанный внутренний Слабо-связанный внутренний
Каждый узел имеет свою собственную оперативную память, с интерконнект интерконнект
которой работают только его локальные процессоры. Доступ к Высокий показатель RAS для Достижение высокого RAS
оперативной памяти другого узла значительно медленнее, чем у одной системы посредством репликации
вертикальных систем. Обычно кластеризация не поддерживает Большое количество Большое количество
никакого кэширования доступа к памяти других узлов. стандартных процессоров стандартных процессоров
Единая ОС на много CPU Много ОС системы с 1-4 CPU
В горизонтальных системах стоимость владения (TCO) на Монолитные системы Модульные системы
процессор для всей системы много меньше, чем в вертикальной Широко распространенные и Широко распространенные
системе. Но низкая пропускная способность интерконнекта часто проприетарные компоненты компоненты
ограничивает применение горизонтальных систем для критичных 64-bit 64 и 32 bit
приложений. Важно, что в таких системах обязательно Таблица 1
присутствует дополнительный слой кластерного программного
обеспечения. В таблице 1 просуммированы ключевые атрибуты вертикальных и
горизонтальных систем:
Примером горизонтальных архитектур также являются MPPs • Память в вертикальных системах общая и имеет
(massively parallel processing systems). Эти системы когерентный кэш
характеризуются большим количеством процессоров, каждый из • Для вертикальных систем идеальны приложения, которые
которых работает со своим экземпляром операционной системы используют интерконнект
или микрокода, и объединены в одном корпусе. Примерами таких • Параметр RAS (reliability, availability, serviceability -
систем могут служить NCR Terradata systems, IBM RS/6000SP (SP- надежность, доступность, обслуживаемость) лучше у
2) и HP Tandem non-stop systems. вертикальных систем, но для приложений с параллельными
транзакциями доступность выше у горизонтальных
кластерных комплексов.
• Вертикальные системы имеют один экземпляр
операционной системы, которая владеет всеми ресурсами.

7 8
 Правда стоит заметить, что широко
распространяются архитектуры, использующие более одной
ОС в сервере, например доменная архитектура или системы
виртуальных контейнеров.
• Большая часть компонентов вертикальных систем являются
стандартными и широко распространены, но некоторые
ключевые для производительности и надежности
компонентs, такие как интерконнект, являются
проприетарными.
• Вертикальная система может масштабироваться
добавлением памяти, процессоров, плат ввода-вывода, а
горизонтальная система расширяется только за счет
добавления узлов.
• Современные вертикальные системы, как правило, 64
разрядные, тогда как горизонтальные системы могут быть
как 32 так и 64 разрядные.
Для вертикальных и горизонтальных систем можно выделить
приложения, которые наилучшим образом подходят для этих
архитектур. Они приведены в таблице 2.
Серверы приложений
Распараллеливаемые
(partitionable)
высокопроизводительные
системы инженерно-
технических расчетов (HPTC)
Таблица 2
На рынке систем высокопроизводительных инженерно-
технических расчетов (High Performance Technical Computing,
HPTC) существует много приложений, имеющих большое
количество взаимозависимых потоков которые постоянно
взаимодействуют друг с другом. Также существуют задачи,
требующие огромное количество разделяемой памяти.
Приложения, которые обрабатывают большие объемы данных
множества пользователей и требуют эффективного
масштабирования на уровне внутреннего взаимодействия больше
подходят для вертикальных серверов (см. рис. 3).

Вертикальные системы Горизонтальные системы

Большие базы данных Web- серверы
Транзакционные базы данных Фаерволы, proxy
Централизованные хранилища Научные вычисления
данных
Системы интеллектуального Серверы обработки потоков
анализа информации медиа-данных
Серверы приложений Обработка XML
Не распараллеливаемые (non- Приложения JSP
partitionable) Рисунок 3
высокопроизводительных
системы инженерно-технических
расчетов (HPTC)
9 10

В тоже время, есть приложения HPTC, потоки которых слабо
зависят друг от друга и не нуждаются в больших объемах памяти.
Небольшие и хорошо реплицируемые приложения являются
идеальными для малых серверов и кластеров.
Диагональная архитектура
Конечно, нет явной линии, разделяющей вертикальную и
горизонтальную архитектуры. Существуют промежуточные
решения, в которых реализованы лучшие аспекты обоих подходов.
Диагональная архитектура совмещает небольшое количество
средних SMP систем с приемлемым уровнем доступности и
достаточной простотой управления (см. рис. 4).
Рисунок 4
Производительность
Хорошо сбалансированный комплекс должен иметь
производительные процессоры, быстрый интерконнект, высокую
пропускную способность системы ввода-вывода, масштабируемую
операционную систему и высокий показатель RAS.
11
Процессоры и интерконнект
Процессор - очень важный компонент системы. Но не только
мощность процессора определяет производительность всего
комплекса. Если процессор с большой тактовой частотой загружен
не полностью, например на 50%, то такая система может быть
медленнее, чем сервер, имеющий процессор с меньшей тактовой
частотой, но работающий с большей загрузкой (80%).
Кроме этого, в параллельных системах зачастую добавление
процессоров меньше сказывается на производительности, чем
увеличение пропускной способности интерконнекта. В
параллельных системах интерконнект занимается пересылкой
данных между дисками, памятью, сетью и процессорами. В
системах с вертикальной архитектурой он называется системным
интерконнектом и реализован внутри сервера. Поэтому он очень
быстрый и имеет низкую латентность. Пропускная способность
системного интерконнекта для SMP серверов SUN от 9.6GB/sec для
малых серверов и 172GB/sec для Sun Fire 25K. Латентность
колеблется в пределах 200 - 450ns.
В кластерах, в качестве кластерного интерконнекта
используются стандартные сетевые интерфейсы, например Fast
Ethernet, Gigabit Ethernet или SCI (scalable coherent interconnect).
Кластерный интерконнект по сравнению с системным обладает
более низкой пропускной способностью и более высокой
латентностью. Пропускная способность кластерного интерконнекта
зависит от типа интерфейса. Для GBE она составляет 125MB/sec, а
для SCI - 200MB/sec. Sun Fire Link имеет пропускную способность
1.2GB/sec и латентность 4000ns. Он доступен на серверах Sun Fire
6800- 25K.
Система ввода-вывода
Система ввода-вывода отвечает за передачу данные с дисков или
сети в интерконнект и процессоры. Низкая скорость ввода-вывода
12
может быть причиной снижения производительности Сайзинг приложений
даже при быстрых интерконнекте и процессорах. Как уже было сказано, большие SMP системы имеют быстрый
интерконнект и, как следствие, более высокую комплексную
Операционная система производительность. В горизонтальных системах также можно
Даже замечательный по своим аппаратным характеристикам сервер получить приемлемую производительность. Для этого приложения
может понизить свою производительность из-за плохо на узлах кластера должны работать независимо (или слабо
масштабируемой операционной системы. С тех пор как в 1993 году взаимодействуют друг с другом) и минимально использовать
технологии Cray Research сервера CS6400 были приобретены Sun и высоколатентный, достаточно медленный интерконнект.
портированы на популярный 64-процессорный сервер E10K,
операционная система Solaris является бессменным лидером На рисунке 5 представлена горизонтальная архитектура с 4-х
масштабируемости. процессорными узлами. Каждый узел имеет свою независимую
память и систему ввода-вывода. Интерконнект реализован на
Доступность системы интерфейсах GBE.
Доступность (availability) системы зависит от выбранной
архитектуры. В системах с вертикальной архитектурой, функции
повышения доступности обеспечивается внутри самой системы.
Большие SMP серверы гарантируют работоспособность при 2-4
аппаратных сбоях. В комплексах с горизонтальной архитектурой
каждый сервер может иметь небольшой уровень доступности, но,
при этом, общая доступность всей системы увеличивается, так как
отказоустойчивость всего кластера пропорциональна количеству
его узлов.

Оптимизация приложений
Приложения, которые используют вертикальные и горизонтальные Рисунок 5
архитектуры серверов должны быть специально спроектированы
Слабая нагрузка (красная) может распределяться внутри одного
или настроены. Без того, эффект от применения соответствующих
узла. Значительная нагрузка (сиреневая и зеленая) требует
систем может не дать ожидаемого результата. Большинство
распределения по нескольким узлам. В этом случае ключевую роль
основных коммерческих приложений уже адаптировано под
играет интерконнект, который будет заметно влиять на
вертикальные архитектуры серверов. Этим объясняется
производительность. Следовательно, идеальной нагрузкой для
доминирование SMP серверов в последнее десятилетие и большой
горизонтальной системы будет та, которую сможет выдержать
потенциал их использования в ближайшем будущем. Адаптация
один узел.
приложений под кластерные горизонтальные архитектуры имеет
значительные трудности.

13 14
На рисунке 6 представлена вертикальная SMP
архитектура с большим количеством CPU, объемом разделяемой
памяти и высокоскоростным интерконнектом.
Рисунок 6
Эта архитектура прекрасно работает как с малой, так и с большой
нагрузкой. Каждый процессор имеет доступ к разделяемой памяти,
любому диску и сети.
Можно ли использовать эту архитектуру для большого количества
приложений с небольшой нагрузкой? Конечно да. Но позже мы
увидим, что стоимость такой SMP системы в пересчете на 1
процессор гораздо выше, чем у небольших систем. Поэтому такие
системы целесообразнее использовать для «тяжелых» критичных
приложений.
Далее рассмотрим производительность 3-х уровневой архитектуры
приложений.
Уровень базы данных.
Что же все-таки лучше использовать для БД, один большой SMP
сервер или кластер из нескольких небольших серверов? Сначала
определимся с основными терминами.
15
Относительная производительность (speedup)
приложения на многопроцессорном SMP сервере определяется тем,
во сколько раз оно работает быстрее, утилизируя все процессоры
сервера по сравнению с аналогичной однопроцессорной системой.
Если на 40 процессорах приложение работает в 40 раз быстрее, чем
на одном, то мы наблюдаем линейную относительную
производительность. Speedup не всегда зависит от количества
процессоров, например, когда скорость работы приложения на 24
процессорах такая же как и на 48. Термин кластерная
относительная производительность (cluster speedup) является
характеристикой комплексной производительности кластерного
приложения и зависит от количества узлов.
Коэффициент масштабируемости (scaling efficiency) обычно
определяется способностью приложения использовать все
имеющиеся процессоры или узлы кластера. Коэффициент
масштабируемости SMP сервера определяется как отношение
speedup к количеству процессоров. Соответственно, в случае
кластера, scaling efficiency определяется как отношение cluster
speedup к количеству узлов. Стоит отметить, что значение
коэффициента масштабируемости зависит от общего количества
его узлов, т. е. этот параметр имеет различные значения, например,
для 2-узлового и 4-узлового кластеров.
Графики, изображенные на рисунке 7 показывают, что существует
вполне конкретный предел масштабируемости. Объединение
большого количества маленьких серверов не обеспечивает
масштабируемости, необходимой для «тяжелых» приложений.
Причинами такого поведения являются ограничения по пропускной
способности интерконнекта, накладные расходы базы данных на
управление кластером и сложности разработки эффективного для
горизонтальных архитектур ПО.
Тесты показывают, что коэффициент масштабируемости для SMP
серверов близок к линейному. При 24 процессорах он составляет
16
95% (23 speedup / 24 CPU), а при количестве CPU,
равном 72, снижается всего до 90% (64 speedup / 72 CPU).
В тоже время, этот параметр в тестах с Oracle9i RAC уже при двух
4-процессорных узлах равен 90% (1.8 speedup / 2 узла), а при 18
узлах снижается до 30% (6 speedup / 18 узла. Также стоит
учитывать, что в качестве примера взяты лучшие показатели тестов
RAC.
Рисунок 7
Результаты тестов полностью соответствуют известному закону
Амдала (Amdahl's Law). Этот закон может использоваться для
экстраполяции параметра speedup при большом количестве
процессоров.
17
где
“se” - коэффициент масштабируемости
“n” - количество узлов
Соответственно, решения на базе Oracle9i (не RAC) для SMP
серверов с количеством процессоров больше 24 является более
предпочтительным по сравнению с кластерами RAC. Для такой же
относительной производительности как у одного 24-процессорного
сервера SMP потребовалось бы тринадцать 4-процессорных
серверов.
Следует заметить, что описанные тесты проводились для OLTP баз
данных. Существует особый класс приложений, таких как
сейсмические системы, имитаторы Monte-Carlo или системы
обработки рисков, которые характеризуются большим количеством
простых запросов на чтение из базы данных. Такие приложения
масштабируются принципиально лучше, чем OLTP.
Уровень приложений
Характеристики уровня приложений в центрах обработки
существенно отличаются от уровня баз данных. Как правило,
приложения этого уровня не отслеживают сессии взаимодействия с
пользователем (stateless) и, соответственно, сохраняют меньше
данных на сервере. Транзакции, которые приходят с уровня
представлений обрабатываются в соответствии с бизнес-логикой и
перенаправляются на уровень баз данных. Сервер приложений
обычно объединяет несколько запросов к базе в одну транзакцию,
что существенно снижает накладные расходы.
На этом уровне, в отличие от уровня баз данных, приложения в
основном потребляют ресурсы процессоров. Например,
18
соотношение утилизируемых процессоров для
приложений SAP R/3 к количеству CPU, рекомендуемой SAP
системы БД составляет 1 к 10. Для Oracle Applications это
соотношение - 5:1. Поэтому, принципы, которыми мы пользовались
при оценке эффективности масштабируемости для уровня баз
данных, не работают для уровня приложений. Это связано с тем,
что на этом уровне просто нет потребности распараллеливания
запросов и, соответственно, размещения нескольких копий одного
сервера приложений на нескольких системах. В тоже время,
различные серверы приложений могут размещаться на физически
независимых серверах разной конфигурации или в динамических
доменах многопроцессорных SMP серверов. Необходимое
количество процессоров для этого уровня не зависит от того, какой
архитектурой, горизонтальной или вертикальной, характеризуется
система.
На основании того, что относительная стоимость приобретения
($/CPU) у горизонтальных систем заметно ниже чем у
вертикальных, можно говорить, что горизонтальная архитектура
для этого уровня более предпочтительна. Но, учитывая
дополнительную стоимость управления и обслуживания большого
количества серверов и экземпляров операционной системы,
тонкости лицензионной политики производителей ПО серверов
приложений, а также сложность резервного копирования и
восстановления горизонтальных систем, делает преимущества
стоимости неочевидными. Поэтому наиболее эффективно
производить сравнительный анализ возможных вариантов в
каждом конкретном случае.
Уровень представлений.
Уровень представлений – это точка доступа для сервисов уровня
приложений. На этом уровне доминируют такие сервисы, как web,
proxy, VPN, файерволы. Эти приложения масштабируются слабо.
Они не отслеживают сессии взаимодействия с пользователем
(stateless) и обычно просто передают запросы на уровень
19
приложений. Такие приложения идеально подходят для
горизонтальных систем, т.к. их относительная стоимость ($/CPU)
гораздо ниже, чем у SMP систем.
TCO приложений в горизонтальных и вертикальных
системах.
Использование баз данных в горизонтальных системах требует
кластеризации. Ранее мы уже останавливались на вопросах
масштабируемости приложений в горизонтальных и вертикальных
системах. Сейчас мы рассмотрим общую стоимость приобретения
системы (total cost of acquisition, TCA). TCA включает в себя
стоимость лицензий, стоимость серверов и кластерных
интерконнектов. Стоимость дисковых массивов в этом расчете не
учитывается.
Наиболее часто используемой кластерной базой данных для Solaris
является Oracle 9i RAC. Использование RAC нуждается в
соответствующих лицензиях. Для всех систем независимо от
размера стоимость основной лицензии базы данных составляет
40000$/CPU (цены U. S. на апрель 2003 г.). Опция RAC стоит
20000$/CPU. Кроме того, часто требуется дополнительная опция
базы partition, которая значительно ускоряет работу с большими
объемами данными. Итого, стоимость Oracle RAC равна
70000$/CPU против 40000$/CPU для базы Oracle на SMP сервере.
Существует простой инструмент для подсчета и сравнения цен
TCA Oracle для SMP серверов и Oracle RAC одинаковой
относительной производительности. Он называется RAC Calculator.
Для подсчета требуются следующие параметры:
• название/модель SMP сервера
• количество процессоров SMP сервера
• цена по прайсу SMP сервера
• название/модель узлов кластера
20
 • количество узлов кластера стоимости SAN, но в стандартных расчетах она
• отношение производительностей процессоров, приравнивается к нулю. Рассмотрим несколько примеров:
используемых в кластерных узлах и SMP сервере
• цена/CPU Oracle 9i Пример 1:
• цена/CPU опции RAC В этом примере серверы Sun Fire 4800 и 6800 сравниваются c
• цена/CPU опции partitioning кластером, узлами которого является серверы Sun Fire v480 (см.
• процент скидки для SMP сервера таб. 3).
• процент скидки для узла кластера
• процент скидки для Oracle Сервер Процессоры Память Параметры расчета
Sun Fire v480 4 x 900MHz 8GB RAM 90% scaling
• процент масштабирования (scalability percentage) UltraSPARC-III 10% decay
• процент уменьшения производительности (decay), 50% скидка Oracle
связанный с добавлением каждого нового узла 20% скидка сервера
Sun Fire 4800 12 x 900Mhz 20GB RAM 90% scaling
UltraSPARC-III 10% decay
Формула вычислений: 50% скидка Oracle
40% скидка сервера
Sun Fire 6800 20 x 900Mhz 32GB RAM 90% scaling
UltraSPARC-III 10% decay
где: 50% скидка Oracle
sp – процент масштабирования 40% скидка сервера
de – процент уменьшения производительности Таблица 3
n – количество узлов
Результат вычислений показан в таблице 4.
Отметим, что, так как параметр de не зависит от количества узлов,
то слагаемое sp-(n-2)de стремится к нулю и каждый новый / SF4800 SF480 SF6800 SF480
добавленный узел вносит все меньший вклад в общую CPU 12 16 20 32
производительность. Количество узлов, которые вносят вклад в Кол-во узлов 1 4 1 8
Стоимость
увеличение производительности, определяется как n=sp/de. аппаратной 229.680$ 172.000$ 346.360$ 345.600
Соответственно, чем больше sp и/или меньше de, тем больше части
эффективных узлов может быть в кластере. Стоимость
программного 240.000$ 560.000$ 480.000$ 1.120.000$
После подсчета количества узлов и процессоров RAC Calculator обеспечения
Общая
подсчитывает TCA, используя прайс-лист и скидки. Эту величину стоимость
469.680$ 732.000$ 826.360$ 1.465.600$
он рассчитывает для обоих вариантов (SMP и кластер) с учетом Таблица 4
стоимости железа, софта и интерконнекта. Существует опция учета

21 22
На рисунке 8 показана гистограмма распределения Xeon 4x 1.5GHz и SF480 показывают приблизительно
стоимости SMP системs SF4800 и 4-узлового кластера на SF480. одинаковую производительность. В качестве операционной
Для SMP сервера характерна высокая цена аппаратной части и системы платформы x86 используется Linux.
приемлемая цена лицензий Oracle. К тому же, в этом варианте Ниже приводятся параметры серверов Dell 6600:
отсутствуют затраты на интерконнект. Для кластерной
архитектуры характерны низкая стоимость аппаратной части и Сервер Процессоры Память Параметры расчета
высокая стоимость лицензий Oracle RAC. Dell 6600 4 x 1.5GHz Xeon 8GB RAM 90% scaling
10% decay
50% Oracle discount
20% Dell 6600 discount
Sun Fire 4800 12 x 900Mhz 20GB RAM 90% scaling
UltraSPARC-III 10% decay
50% скидка Oracle
40% скидка сервера
Sun Fire 6800 20 x 900Mhz 32GB RAM 90% scaling
UltraSPARC-III 10% decay
50% скидка Oracle
40% скидка сервера
Таблица 5

Результат сравнения показан в таблице 6.

/ SF4800 SF480 SF6800 SF480

CPU 12 16 20 32
Кол-во узлов 1 4 1 8
Рисунок 8 Стоимость
аппаратной 229.680$ 108.800$ 346.360$ 217.600$
Таким образом, основная ценовая составляющая в кластерной части
архитектуре – это лицензии на ПО. Кроме того, с ростом Стоимость
количества процессоров в кластере цена лицензий Oracle может программного 240.000$ 560.000$ 480.000$ 1.120.000$
обеспечения
значительно вырасти. Общая
469.680$ 668.800$ 826.360$ 1.337.600$
стоимость
Таблица 6
Пример 2:
В этом примере мы сравним SMP серверы Sun Fire с кластером Во всех приведенных выше примерах TCA многопроцессорных
серверов архитектуры x86 от компании Dell (см. таб. 5). По тестам SMP серверов заметно ниже стоимости приобретения аналогичных
производительности TPC-H, серверы Dell 6600 с процессорами кластерных комплексов.

23 24
Сравнение уровня доступности
вертикальных и горизонтальных систем.
Доступность является одной из наиболее важных характеристик
современных центров обработки данных. Многие важные сервисы,
предоставляемые приложениями, должны быть доступны
пользователям в режиме 7x24x365. Существуют различные схемы
обеспечения высокой доступности в центрах обработки данных.
Выбор той или иной схемы зависит от требований к конкретным
сервисам (плановое и неплановое максимальные времена простоя)
и цены решения. Рисунок 9 показывает зависимость уровня
доступности от времени простоя для различных вариантов
решений:
Рисунок 9
25
При увеличении уровня доступности решения
увеличивается его цена и сложность, поэтому люди, принимающие
решения о выборе реализации той или иной схемы, должны
проанализировать все аспекты решения и цену каждого из них.
На рисунке 9 видно, что доступность кластерных систем выше, чем
у многопроцессорных серверов. Но стоит понимать, что зачастую
для центров обработки данных вполне достаточно уровня
доступности 99.95% (около 4 часов простоя в год). Такой уровень
доступности могут обеспечить многие современные SMP серверы,
обладающие высоким показателем RAS.
Повысить уровень доступности вертикально масштабируемого
комплекса до 99.975% можно при помощи использования кластера
высокой готовности (high availability, HA). Это решение, как
правило, построено на двух серверах, один из которых является
продуктивным, а второй находится в режиме постоянной
готовности (hot standby). При выходе из строя продуктивного
сервера приложение перезапускается на резервном сервере. Время
переключения зависит от используемого приложения. Для баз
данных оно обычно составляет несколько минут, так как для них
необходимо дополнительное время на «накатку» пропущенных
транзакции на резервном сервере. Статистика показывает, что
около ¾ всех кластеров в мире составляют кластеры HA.
Если же уровень доступности должен быть максимальным, то
резонно использовать кластерное решение Real Application Cluster,
в котором все узлы работают параллельно. Время простоя при сбое
системы с RAC определяется тем, как построено само приложение,
и обычно менее 1 минуты.
Вертикальные серверы обеспечивают высокий уровень
доступности и, соответственно, минимизации времени простоя
системы, за счет реализации дополнительных функций RAS. В
свою очередь, узлы горизонтальных кластерных решений обычно
имеют такие функции в минимальном объеме и обеспечивают
26
высокий общий уровень RAS за счет репликации
данных и распределения задач между собой. Принципиальные № Серверы Стоимость Коментарии
отличия уровня RAS и параметров интерконнекта SMP серверов 1
1 x Sun Fire 6800 20-
826.360$
С лицензиями Oracle 9i
CPU сервер
определяют разницу в стоимости аппаратного обеспечения (такая же производительность как у 1
вертикальных и горизонтальных решений. 2 x Sun Fire 6800 12-
2 1.461.360$ x 20-CPU SF6800) С лицензиями
CPU сервера
Oracle 9i RAC
В трехуровневых архитектурах для уровня представлений, (такая же производительность как у 1
8 x Sun Fire v480 4-CPU
3 1.465.600$ x 20-CPU SF6800) С лицензиями
например для web-серверов, как правило, используются сервера
Oracle 9i RAC
горизонтальные решения. Можно установить несколько копий ПО Таблица 7
web-сервера на нескольких системах. В случае выхода из строя
одного из серверов запросы легко перенаправляются на рабочие Из таблицы 7 мы видим, что расчетная TCA вариантов 2 и 3 очень
системы. близка. Казалось бы, эти варианты равнозначны, но стоит
Серверы приложений, в свою очередь, для обеспечения учитывать, что вариант 2 имеет лучшие показатели RAS,
надлежащего уровня доступности могут использовать как характеристики масштабирования и проще в управлении. Поэтому
вертикальную, так и горизонтальную архитектуры. Независимо от он более предпочтителен.
того будут ли использоваться несколько больших или много
маленьких серверов основной технологией, обеспечивающей
высокую доступность, будет репликация данных. Консолидация.
Ситуация меняется коренным образом в случае уровня баз данных. Еще несколько лет назад общепринятой практикой являлось
Базы данных интенсивно используют обмен между процессами и выделять отдельный сервер под каждое приложение или экземпляр
общую разделяемую память. Поэтому вертикальные серверы для базы данных. При этом сайзинг аппаратной части рассчитывался на
них более предпочтительны. Кластерные решения следует пиковые нагрузки приложений. Такой подход вел к неэффективной
использовать только в случае повышенных требований к уровню утилизации серверов, так как большую часть времени эти серверы
доступности. простаивали или работали с малой загрузкой.
Многие современные приложения, такие как PeopleSoft, SAP и
Oracle Applications содержат компоненты, которые работают на
Пример 3: различных уровнях ЦОД. Например, модуль PeopleSoft HR имеет
Сравним TCA решений с Oracle RAC для кластера, состоящего из компоненты на всех трех уровнях. Поэтому, в рамках описанного
двух «тяжелых» SMP серверов, кластера нескольких небольших выше подхода, необходимо иметь отдельные системы для БД,
серверов и некластеризованной базой данных Oracle на одном 20- сервера приложений и web-сервисов для каждого модуля (см. рис.
процессорном сервере с уровнем доступности 99.95%. Для расчета 10).
использовались те же параметры, что и в предыдущих примерах.

27 28
 Solaris 10. Совместно с возможностью динамической
реконфигурации (Dynamic Reconfiguration, DR) системных
доменов эти функции обеспечивают необходимый уровень
автономности, а соответственно безопасности и надежности, при
эффективной утилизации общих ресурсов.

Варианты многоуровневой реализации

Рисунок 10 При оценке вертикальной, горизонтальной и диагональной
архитектур полезно сравнить различные варианты их
Очевидно, что такой подход ведет к быстрому увеличению многоуровневой реализации. В таблице 8 в качестве основных
количества серверов и, как следствие, усложнению и повышению критериев оценки выбраны производительность, доступность и
стоимости их администрирования. На сегодняшний день, сложность реализации и администрирования.
большинство компаний пытаются контролировать разрастание
приложений путем их консолидации в нескольких мощных и легко Архитектура Производительность Доступность Сложность
управляемых системах. Один из таких способов улучшения Вертикальная
Очень хорошая Плохая Низкая
утилизации ресурсов – это распределение нескольких уровней 2-уровневая
различных приложений в общей системе (см. рис. 11). Вертикальная
Превосходная Хорошая Низкая
3-уровневая
Горизонтальная
Хорошая Превосходная Высокая
3-уровневая
Диагональная Очень
Хорошая Средняя
3-уровневая хорошая
Таблица 8

Рассмотри эти варианты более подробно.

Рисунок 11
Однако, возможность эффективно запускать несколько
экземпляров приложений на одном сервере требует наличия
специальных функций распределения ресурсов в оперативной
системе. Примерами такого функционала являются Resource
Manager в Solaris 9 (S9RM) и контейнеры (Grid Containers) в
29
Вертикальная 2-уровневая
Реализация вертикальной 2-уровневой архитектуры подразумевает
установку базы данных и сервера приложений на одном сервере
или системном домене (см. рис. 12). При этом, используется только
один экземпляр ОС, что приводит к низким затратам на
администрирование.
30
 Рисунок 12
Такая реализация показывает очень высокий уровень
производительности, так как база данных и сервер приложений
взаимодействуют друг с другом посредством внутренних
механизмов ОС (например, через интерфейс loopback). Некоторые
стандартные тесты производительности, например SAP 2-Tier
benchmark, проводятся именно на такой архитектуре.
Использование единой операционной системы приводит к тому,
что ресурсы утилизируются эффективно. К сожалению, уровень
доступности в такой системе невысок, так как выход из строя
сервера ведет к недоступности для пользователей как базы данных,
так и сервера приложений. Для улучшения этой характеристики
можно использовать решения HA, но это ведет к удвоению общей
стоимости комплекса. Использование S9RM и контейнеров
ненамного повышает общий уровень доступности.
Можно сказать, что использование такой архитектуры в
продуктиве не желательно.
Вертикальная 3-уровневая
Как и в предыдущем примере, в вертикальной 3-уровневой
архитектуре приложения и база данных расположены на едином
сервере (см. рис. 13).
31
Рисунок 13
В тоже время, такая реализация подразумевает размещение базы
данных и приложений в различных системных доменах. Так как
домены обеспечивают больший уровень изоляции ошибок и
безопасности, чем системы с единой ОС, то они обеспечивают
лучшие характеристики доступности.
В тоже время, такая реализация легко управляется и позволяет
контролировать утилизацию ресурсов при помощи динамической
реконфигурации.
Такая архитектура активно используется во многих продуктивных
системах.
Горизонтальная 3-уровневая
В горизонтальной 3-уровневой архитектуре используется большое
количество относительно слабых серверов (см. рис. 14). В
современных реализациях эти серверы имеют внутреннюю
архитектуру x64 и обладают 1 - 4 процессорами.
32
 Рисунок 14
Как уже обсуждалось выше, хотя каждый сервер обладает
невысоким показателем RAS, в целом, такая архитектура
обеспечивает очень высокий уровень доступности.
В тоже время, комплекс обладает средней производительностью и
статический утилизацией ресурсов. Также стоит помнить о
сложности управления и мониторинга множества систем.
Сравнение TCA горизонтальной и вертикальной 3-уровневых
реализаций
Для сравнения взяты приблизительно одинаковые по
производительности в зависимости от уровня загрузки
конфигурации:
1. шестнадцать 4-процессорных (Ultra SCAPC III) серверов Sun
Fire V480 (при средней утилизации 30%)
2. два 16-процессорных (Ultra SCAPC IV) серверов Sun Fire
E6900 (при средней утилизации 30%)
3. один 24-процессорный (Ultra SCAPC IV) сервер Sun Fire
E6900 (при средней утилизации 45%)
33
Рисунок 15
Видно, что стоимость более эффективно нагруженного 24-
процессороного сервера всего на 18% выше аналогичного по
производительности, но уступающего по масштабируемости и
сложности администрирования комплексу из шестнадцати 4-
процессорных серверов. В расчете не учитывались значительные
затраты на лицензии кластерного ПО.
Диагональная 3-уровневая
Диагональная 3-уровневая архитектура очень похожа на
горизонтальную. Основным отличием является то, что в ней вместо
множества маленьких (1-4 CPU) серверов используются несколько
средних (например, с 24 CPU) (см. рис. 16).
34
 Рисунок 16
Такой компромиссный подход позволяет сохранить достаточно
высокий уровень доступности приложений и базы данных. При
этом заметно улучшается характеристики утилизации ресурсов и
снижаются затраты на управление и мониторинг всего комплекса.
Дополнительную гибкость масштабирования такому решению
придает возможность одновременного использования серверов
разных аппаратных конфигураций и, соответственно, различной
мощности.
Сравнение TCA диагональной и горизонтальной 3-уровневых
реализаций
Для сравнения взяты приблизительно одинаковые по
производительности в зависимости от уровня загрузки
конфигурации:
4. шестнадцать 4-процессорных (Ultra SCAPC III) серверов Sun
Fire V480 (при средней утилизации 30%)
5. четыре 8-процессорных (Ultra SCAPC IV) серверов Sun Fire
E2900 (при средней утилизации 30%)
6. два 24-процессорных (Ultra SCAPC IV) сервера Sun Fire
E2900 (при средней утилизации 45%)
35
Рисунок 17
Видно, что стоимость комплекса из шестнадцати 4-процессорных
серверов всего на 10% ниже аналогичного по производительности
комплекса из четырех «средних» 8-процессороных серверов и
сравнима со стоимостью более эффективно нагруженной системы
из двух серверов E2900.
Выводы.
Обе архитектуры занимают свою нишу в современных центрах
обработки данных.
Ключевым отличием горизонтальных и вертикальных архитектур
является интерконнект. В горизонтальных системах он внешний и
достаточно медленный, а в вертикальных он внутренний и
быстрый. В 3-уровневой архитектуре приложений вертикальные
системы наиболее предпочтительны на уровне баз данных, а
горизонтальные - на уровне слабосвязанных приложений.
Лучшим подтверждениями вышесказанного являются статистика и
прогнозы. Данные о продажах серверов (см. рис. 18) говорят о
значительном объеме продаж средних и «тяжелых» систем.
36
 Рисунок 18
При этом распределение этих серверов между задачами в 3-
уровневой модели (см. рис. 19) показывает, что такие системы
используются в основном на уровнях приложений и баз данных и,
соответственно имеют вертикальную архитектуру.
В тоже время, прогнозируется, что рынок малых серверов в
ближайшие несколько лет будет достаточно стабилен. В основном
такие системы будут использоваться на презентационном уровне.
37
Рисунок 19
Существуют некие общие тенденции, но в каждом отдельном
случае вопрос о реализации той или иной архитектуры следует
решать только при детальном анализе плюсов и минусов
различных вариантов решений.
38
 Vasily.Pantyukhin@lynx.ru

Санкт-Петербург 2005

39 40