Сегодня разговор пойдет о практической стороне дела, а именно, я постараюсь ответить на вопрос о том, как расчитать производительность для аппаратного обеспечения ЦОД для применения виртуализации, а в конце статьи немного коснусь проблемы бутылочного горлышка.
Дисклеймер:)
Идеи, которые я излагаю тут, это мой практический опыт и наблюдения, которые были сделаны в процессе работы. Они не являются позицией какого либо конкретного вендора или руководством к незамедлительному действию.
Планирование виртуализации в ЦОД
Виртуализация инфраструктуры - сложный процесс. Десятки, а иногда и сотни различных серверов с многими и многими приложениями и различной нагрузкой на аппаратную часть.
Основные вопросы, на которые, в этой ситуации, должен ответить инженер, планирующий виртуализацию ЦОД, должны быть следующими:
- Как сформировать требования к аппаратной платформе ЦОД, чтобы производительности аппаратного обеспечения хватило для виртуальных серверов?
- Как заложить резерв аппаратного обеспечения для быстрой замены или масштабирования ЦОД?
- Как обеспечить отказоустойчивость и обойти единые точки отказа?
Формально, требования к компонентам аппаратной платформы ЦОД можно описать формулой:
Reqtotal= ((Reqcurr + Reqpl)* 2) +(((Reqcurr + Reqpl)* 2)*0.30),
где:
Reqtotal - Сумма всех требований к компоненту аппаратной платформы
Reqcurr - Требования для виртуализации, исходя из текущей загрузки серверов
Reqpl - Требования к " с нуля" планируемым сервисам
((Reqcurr + Reqpl)*2) - 50 % резервирование производительности для обеспечения отказоустойчивости и высокой доступности за счёт кластеризации.В этом случае полявляется возможность сохранения работоспособности сервисов в случае отказа 1 узла кластера.
(((Reqcurr + Reqpl)2)*0.30) - 30 % резерв производительности в ЦОД, в случае возникновения необходимости увеличения кол-ва виртуальных серверов, при сохранении полной отказоустойчивости.
В конце статьи я опишу пример, как использовать эту формулу, чтобы понять какое количество ядер, оперативной памяти, какой должен быть объём жестких дисков и т.д. в ЦОД, ну а пока что остановимся на вопросе сбора исходных данных.
Определение требований
На первый вопрос нам поможет ответить Microsoft Assesment and Planning Toolkit (MAP).
Данный продукт является бесплатным. Текущая версия уже адаптированна к Windows Server 2012, позволяет оценить готовность инфраструктуры к переходу на новую платформу. Microsoft рашририла функционал данной утилиты, подробнее с ним можно ознакомиться скачав Getting Started Guide.doc по ссылке выше.
Но самой главной особенностью MAP является возможность оценить загрузку физических серверов, работающих под управлением Windows или *nix операционных систем, а так же получить рекомендации по консолидации их в виртуальной среде на базе Hyper-V.
Ответ на второй вопрос состоит из нескольких частей:
Во-первых, обратимся к документации, предоставляемой производителем. Исходные данные можно получить там. Если говорить о решениях Microsoft для таких сервисов, как Exchange Server, SCOM, SCCM и многих других есть уже расчитанные и проверенные конфигурации. Существует большое количество sizer'ов или калькуляторов для расчёта нагрузки. Они помогут сформулировать втрорую составляющую к аппаратной платформе ЦОД.
Во-вторых, при внедрении любого крупного решения, после выхода его на планируемую мощность, необходимо нагрузочное тестирования для уточнения пороговых значений
Отказоустойчивость и резервирование
При использовании отказоустойчивой кластеризации мы должны резервировать 50% доступной производительности на каждом узле кластера на случай сбоя другого узла, чтобы мигрировавшие на него виртуальные машины могли запуститься и работать. Аналогично стоит подходить к резервированию компонентов сетевой инфраструктуры, инфраструктуры обмена данными между серверами и СХД (SAN или NAS) - об этом в конце статьи.
Пример расчёта аппаратной платформы ЦОД
Давайте рассмотрим конкретную ситуацию. К примеру, мы решили реализовать нашу инфраструткура на 2 - х узловом отказоустойчивом кластере. При этом, необходимо зарезервировать 30% производительности для будущих нужд.
Проведя аудит, мы получили следующие результаты с помощью MAP о нашей инфраструктуре.
Server name
|
OS
|
CPU
|
RAM
|
CPU utilization
|
Sirius
|
Windows Server 2008 R2
|
x2 Intel 4 Cores Xeon 2.66 Ghz
|
8 GB
|
35%
|
Quantum
|
Windows Server 2008 R2
|
1 Intel 2 Cores Xeon 2 Ghz
|
4 Gb
|
65%
|
Tesla
|
Red Hat 5.7
|
1 Intel 4 Cores Xeon 2 Ghz
|
16 Gb
|
35%
|
Nessy
|
Suse Linux 11
|
1 Intel 2 Cores Xeon 2 Ghz
|
8 Gb
|
30 %
|
Зная значения количества ядер и процессоров, а так же значение утилизации CPU, мы можем расчитать количество реально используемых ядер для нужд каждого сервера, формула будет следующей:
NumberCoresUtilized = Phy. CoresNumber * (CpuUtilizationPercent/100),
где:
NumberCoresUtilized - суммарно используемое сервером кол-во ядер
Phy. CoresNumber - количество физических ядер процессора на сервере
CpuUtilizationPercent - суммарный процент утилизации процессоров физического сервера
Для серверов из примера мы получили следующие значения, округлённые в большую сторону
Server name
|
CPU
|
CPU utilization
|
~ Cores
Utilized
|
Sirius
|
x2 Intel 4 Cores Xeon 2.66 Ghz
|
35%
|
2,5
|
Quantum
|
1 Intel 2 Cores Xeon 2 Ghz
|
65%
|
1,5
|
Tesla
|
1 Intel 4 Cores Xeon 2 Ghz
|
35%
|
1,5
|
Nessy
|
1 Intel 2 Cores Xeon 2 Ghz
|
30 %
|
1
|
TOTAL
|
~ 7 |
То есть в данном случае мы можем говорить о том, что для виртуализации данных серверов нам необходимо 6.5 (~7) физических ядер. По требованиям к развёртыванию Windows Server 2008 R2 (2012) с ролью Hyper-V нам необходимо зарезервировать для операционной системы сервера виртуализации 1 физическое ядро и 2 гигабайта оперативной памяти.
Допустим, помимо вышеперечисленных виртуальных машин, у нас ещё есть сервис 1С, который съедает ещё 3 ядра и 8 ГБ ОЗУ.
Итого мы знаем, что нам требуется 11 ядер и 44 гигабайта ОЗУ на одном хосте.
Для начала разберёмся с оперативной памятью.
Всего наши виртуальные машины используют 44 гигабайт оперативной памяти.
Возьмём формулу из первой статьи цикла и рассчитаем административную нагрузку от использования оперативной памяти.
ADMoverhead = (5*32) + (37*8) = 456 Mb
Плюс 2 гигабайта для серверной операционной системы итого получается 44 + 0,456 + 2 = 46, 456 гигабайта. При использованнии большего количества памяти виртуальными машинами коэффициен административной нагрузки увеличится, имейте это ввиду при дальнейшем выделении памяти.
Для спавки:
Распределение памяти выглядит следующим образом:
1. Память зарезервированная для гипервизора и родительского раздела
2. Память зарезервированная под административную нагрузку, возникающую при выделении ОЗУ виртуальным машинам
3. Доступный сегмент памяти для виртуальных машин
Теперь используем формулу расчёта требований к аппаратной платформе для каждого из компонентов:
Пример для расчёта количеств ядер процессоров, необходимых в ЦОД
Reqtotal = ((8 + 3)*2) +(((8 + 3)*2)*0.30) = 28,6 шт.
Аналогично расчитываем память:
Суммарно памяти нам надо Reqtotal = (46,45 * 2) +((46,45 * 2)*0.30) = 120,77 Gb
Так же можно расчитать дисковое пространство, которое займёт VHD диск одной виртуальной машины
VHDTotalSize = (VMDiskSize + VMRam*2) * 1.1
VHDTotalSize - суммарный размер VHD диска
VMDiskSize - выделяемое место
VMRam*2 - коррекция размера диска при использованнии SWAP файла
* 1.1 - резерв 10% дискового пространства.
Предположим наши виртуальные машины утилизируют каждая по 80 гигабайт дискового пространства. Тогда у нас получится следующая табличка.
Server Name|Param
|
RAM Allocation
|
HDD Planned
|
Total Disk Space
requirements
|
Sirius
|
8 GB
|
80
Gb
|
105.6
|
Quantum
|
4 Gb
|
80
Gb
|
96.8
|
Tesla
|
16 Gb
|
80
Gb
|
123.2
|
Nessy
|
8 Gb
|
80
Gb
|
105.6
|
1C
|
8
Gb
|
80
Gb
|
105.6
|
TOTAL
|
536.8
|
Мы можем увидем, что минимальный размер LUN под CSV составит ~ 540 Gb
Вроде бы всё хорошо, однако мы забыли о резервном копировании, тем более с применением SNAP SHOTS. Как минимум нам надо хранить резервные копии (РК) в архиве некоторое количество времени, это РК не только виртуальных машин, но и подчас РК pass-through дисков, различных шаблонов конфигураций и т.д. Данные будут периодически приращиваться. И опять же мы можем примерно прикинуть размер с помощью формул приведённой в начале статьи. При использовании normal back up нам надо иметь место 1:1 минимум. То есть если мы имеем 540 Gb данных виртуальных машин, нам надо обеспечить ещё как минимум столько же, плюс резерв на другие задачи, итого минимум дискового пространства где то 1242 Gb. Так же можно вспомнить о теневых копиях путём функционала, предоставляемого системой хранения данных (СХД), что требует дополнительного дискового пространства на СХД.
Тестовые данные выглядят неособо впечатляюще, однако в крупной среде с разными требованиями к виртуальным машинам, их отказоустойчивости, РК и хранению картина будет другая.
Да, диски, используемые для хранения данных обычного РК (нормальный back up) могут быть низкопроизводительными, к примеру, подключенные к полке SATA диски или полка NAS, подключенная по iSCSI. С другой стороны, если мы хотим быстро сделать снимоки виртуальных машин или восстановить машины из снимков - это не вариант, тут нужны высокопроизводительные диски (вернее СХД). Ленточные носители могут использоваться, как долговременный архив для некритичных данных.
Немного об узких местах и отказоустойчивости
Дисковая подсистема
Особое внимание следует уделить IOPs системы хранения данных (СХД) http://ru.wikipedia.org/wiki/IOPS. Очень часто именно производительность дисковой подсистемы приводит к замедленной работе виртуальных машин.
При выборе СХД по производительности, мы можем операться на достоверную информацию, полученную входе обследования уже существующих сервисов и прогнозируемую инфромацию о планируемых.
Так же необходимо уделить внимания системам взаимодействия СХД и серверов виртуализации (FC, iSCSI). Каждая имеет свои ограничения по производительности. К примеру, если мы планируем высоконагруженные приложения и большое количество виртуальных машин лучше использовать FC, но при отсутсвтии возможности применения FC, можно задействовать функционал Network Teaming для Ethernet сетевых адаптеров, этот фукнционал прекрасно реализован в Windows Server 2012, кстати, это не исключает применение Network Teaming и для FC, ну и наконец MPIO никто не отменял.
Для справки:
Виртуальные машины на базе Hyper-V 3.0 поддерживают подключение FC адаптеров напрямую. SAN должен поддерживать NPIV (N_Port ID Virtualization).
Сетевая инфрастуктура и коммутирование устройств для отказоустойчивости.
Формально мы можем выделить три разных уровня сетевой архитектуры в нашей инфраструктуре:
- Уровень предоставления данных пользователям;
- Уровень взаимодействия серверных компонентов, СУБД и т.д.;
- Уровень взаимодействия серверов и СУБД с СХД;
Если говорить о первом уровне, то тут всё достаточно просто. Как правило используется резервирование каналов и их расширение их провайдером по запросу, так же возможно применение QoS.
Самыми сложными в реализации и высоконгруженными уровнями являются:
По сути эти два уровня - это сердце любого ЦОД.
На данных уровнях необходимо вспомнить об отказоустойчивости не только на уровне сетевых каналов, а так же сетевых устройств. Один FC коммутатор, лежащий в основе взаимодействия узлов кластера и СХД при выходе его из строя надолго остановит работу всей инфраструктуры офиса, ЦОД и т.д, если ему нет замены.
Единой точкой отказа может являться нетолько сетевой коммутатор, но так же и один сетевой интерфейс физического сервера виртуализации, полки СХД, единственный RIAD контроллер и много другое.
Для обеспечения высокой доступности серверной инфраструктуры и инфраструктуры хранения данных необходимо чётко продумать систему резервирования и дублирования компонентов, а так же штатные процедуры работы персонала в тех или иных случаях.
Так же нужно держать в уме вероятную необходимость увеличения пропускной способности этих двух уровней.
Отдельный разговор - это проработка репликации данных территориально распределённых ЦОД. Как правило, такие операции максимально утилизируют пропускную способность каналов связи и для них требуется предусмотреть отдельный выделенный канал с высокой гарантией доступности и пропускной способности.
Заключение
Конечно, в рамках одной статьи детально все аспекты не рассмотришь. Тем не менее, очень надеюсь, что данная информация поможет кому нибудь в общем понимании затронутых тут вопросов.
Всё, что написано в данной статье, основанно на моём опыте и не является официальной позицией какого либо вендора (С)
