В этой статье мы приводим описание подхода, которым сами пользуемся при проектировании виртуальных инфраструктур для наших клиентов.
Он может помочь и при работе с интегратором, и в том случае, если вы решили провести консолидацию виртуальной инфраструктуры силами собственной ИТ-службы.
Этап 1. Инвентаризация
Для начала стоит провести инвентаризацию серверных операционных систем и физических серверов, на которых они функционируют.
Суть этого этапа — отделить существующие операционные системы, которые уже виртуализированы, от физически живущих на серверах систем.
Собираем информацию о физических серверах в таблицу или в виде записей в реляционной базе данных:
Производитель, модель, поколение (Vendor / Model / Generation);
Серийный номер (SN) оборудования;
Дата производства (Manufacture Date);
Срок окончания гарантии (Warranty end) — позволяет выделить устаревшее оборудование;
IP-адрес сервисного процессора сервера (SC IP);
Объём жесткого диска (HDD Size), модель (model), время загрузки ввода-вывода (IO load (storage)), конфигурация дисков;
Характеристики оперативной памяти (RAM): частота, размер GB, количество;
Процессоры (CPU) — модель, количество;
Характеристики операционной системы (OS):
название (OS name), тип (OS type), версия (OS version), язык программирования (OS language), лицензия (OS license), на каком компьютере установлена (Computer name), домен или рабочая группа (Domain / workgroup), IP-адрес (IP);
Дополнительные устройства (USB and other uniq devices) — важный атрибут для планирования.
Заметим, что сбор информации в виде записей в реляционной базе данных упрощает фиксацию дальнейших изменений и анализ системы — мы делаем именно так с учетом нашего опыта:-).
Далее отдельной сущностью / таблицей собираем информацию о виртуальных машинах / операционных системах на этом физическом оборудовании:
Сервер (Host), на котором операционная система функционирует, из списка выше;
IP-адрес (IP);
Характеристики диска (DISK): размер (Size), Место хранения (storage), формат данных (vmdk\RAW), резерв (provision);
Оперативная память (RAM): выделенная, потребляемая;
Характеристики виртуального процессора (vCPU): количество ядер, выделенная частота, средняя загрузка;
Характеристики сети (Network): (среднее время утилизации) канала, максимальная загрузка, длительность периода максимальной нагрузки;
Характеристики операционной системы: название (OS name), тип (OS type), версия (OS version), язык программирования (OS language), лицензия (OS license);
Имя компьютера (Computer name);
Имя домена или рабочей группы (Domain / workgroup)
Прочие адреса (IPs);
Шифрование диска (Disk Encryption)
Использование съемных дисков (USB Usage) — указываем, какие USB используем;
Кластеризация с ролями виртуальных машин (Clustered with vm Roles);
Описание (Description).
Для операционных систем, в том числе виртуальных машин, важно снять информацию и по загрузке ресурсов, желательно в соотношении с рабочим циклом системы (смена на заводе, неделя и т. д.):
Время активной эксплуатации жесткого диска (HDD active time);
Время загрузки процессора (CPU load);
Длительность периода максимальной нагрузки и особенности пиковых загрузок (например, еженедельное задание полного резервного копирования);
Количество операций ввода-вывода (IO load, IOPS);
Использование оперативной памяти (RAM usage).
Этап 2. Аудит
В рамках этого этапа мы определяем проблемные системы и прогнозируем ресурсы.
С точки зрения подбора оборудования для виртуализации нам надо свести нашу инфраструктуру из состояния “AS IS” (как есть) после этапа 1 в формальный набор критериев итогового решения, выраженный в сумме:
vCPU — количество ядер процессора, необходимое для нормальной работы;
Memory — объём памяти;
Количество быстрых жестких дисков (HDD);
Количество медленных жестких дисков (HDD).
Планируя виртуализацию, важно грамотно обозначить желаемое состояние. Например, если какая-то система съедает ресурсы диска по производительности, относим это в категорию «AS IS» (как есть) и планируем изменения, а не надеемся, что в рабочем порядке получится сделать что-то, что уменьшит очередь к диску. Если это уже так работает и никто не обращал внимания, то вряд ли что-то изменится в будущем без дополнительного стимула. При этом ничто не мешает вам параллельно поставить задачу своим подчиненным.
Если CPU load высокий (выше 70%) и есть очередь к диску (высокий hdd active time), следует присмотреться, есть ли причинно-следственная связь между недостатком дискового ввода-вывода и загрузкой процессора: загрузка процессора может означать ожидание ресурсов. То же самое может быть с памятью — ввод-вывод забивается активным SWAP.
Описываем в итоговой таблице vCPU c учетом загрузки. Если аудит показывает избыток — сокращаем, если недостаток — увеличиваем количество в два раза.
Аналогично с оперативной памятью.
По дискам — смотрим по IOPS: если выявили нехватку памяти, планируем меры по ее увеличению.
В итоге мы имеем описание существующих систем и оценку аудита по следующим параметрам:
количество требуемой памяти,
требуемый объем быстрых дисков,
требуемый объем медленных дисков,
количество vCPU
Этап 3. Выбор архитектуры виртуализации
Аппаратная часть должна быть избыточна для непрерывности работы при обслуживании /сбое части физических серверов и устройств. Архитектурой в данном контексте и является модель, согласно которой будут располагаться и функционировать виртуальные машины на физических серверах с учётом требований по отказоустойчивости и доступности.
Архитектуру определяют по:
Возможностям платформ виртуализации (XEN, VmWare, KVM, Hyper-V);
Мощности физических серверов, подлежащих виртуализации;
Лицензионным наборам (bundles), в которых приобретать различные программы для обеспечения виртуализации выгоднее, чем по отдельности;
Требования к отказоустойчивости (например, допустимо, что один сервер будет в простое в течение такого-то времени) и т. д.
Для лучшего понимания приведу возможные архитектуры:
Active-passive — кластер, состоящий, как правило, из двух физических узлов с холодным резервированием одного из серверов. Когда система запущена на одном из серверов, второй находится в резерве. В случае проблемы с работающим (active) сервером в работу включается другой, который до этого был passive.
Распределенный кластер с избыточностью по одному, двум, трем и более серверам — в случае выключения ресурсы переносятся на «живые узлы», что соответствует распределению нагрузки на физ. устройства. Один экземпляр ОС может одновременно быть запущен на нескольких узлах. В случае отказа одного из узлов система продолжает работать без единой секунды простоя.
Архитектура без избыточности — в случае выхода из строя сервера виртуальные машины на нем будут недоступны.
Multi-site кластер — решение для географически распределенных дата-центров с перекрытием критических систем на уровне виртуальных машин, при этом может быть реализована архитектура 1 или 2.
Вопрос выбора сводится к тому, чтобы в итоге сократить расходы как на закупку, так и на эксплуатацию систем бизнесом. Это зависит от того, сможет ли конечный набор оборудования при требуемой «лучшей» архитектуре быть минимальным и достаточным, и вписывается ли он в имеющиеся лицензионные наборы (бандлы) среды виртуализации и сопутствующего ПО.
Этап 4. Конфигурации серверов и выбор модели
Некоторые вендоры имеют наборы, соответствующие типовым запросам бизнеса. Например, для малого бизнеса VmWare имеет наборы Essentials kit, выгодные при количестве двухпроцессорных серверов не более трех. При этом на трех двухпроцессорных серверах можно построить архитектуру с распределением ресурсов и избыточностью в один сервер (если один сервер выходит из строя, виртуальные машины продолжают работу на двух оставшихся).
Вопрос в этом примере сводится к тому, сможем ли мы разместить количество виртуальных машин, требуемое нам по результатам аудита (этап 2) на двух серверах (третий в резерве) и системе хранения, и если да, то на какой конфигурации и за какие деньги. При этом нужно учесть память, диски и процессорные ядра из расчета 1 vCPU = 1 ядро CPU. Запас, который остается для роста инфраструктуры, обозначаем в цифрах и процентах — так понятнее для бизнеса.
На этом этапе формируется область допустимых значений — конфигурации с количеством серверов, в зависимости от количества серверов — конфигурации процессоров с учетом загрузки, допустимые архитектуры, деньги и планирование бюджета по поддержке оборудования и программного обеспечения виртуализации.
Сопутствующие расходы будут и при лицензировании системы резервного копирования на инфраструктуру (см. След. шаг)
Этап 5. Лицензирование операционных систем
Включаем в смету лицензирование Microsoft — или актуализируем, какие лицензии мы можем использовать из существующих. В кластерной среде у Microsoft есть свои Требования по коммерческому лицензированию и переездам виртуальной машины между физическими серверами. Возможно, придется докупать лицензии или переходить на лицензирование по модели Datacenter, более того, старые лицензии OEM невозможно будет применить в новой инфраструктуре. http://download.microsoft.com/download/3/D/4/3D42BDC2-6725-4B29-B75A-A5B04179958B/WindowsServer2016VirtualTech_VLBrief.pdf
Включаем решение по резервному копированию, например, Veeam — тоже зависящий от серверов и ядер, и имеющий Essentials наборы.
https://www.veeam.com/licensing-policy.html
Этап 6. Планирование на расширение аппетита
Важный пункт выбранной модели — что потребуется сделать, когда текущие ресурсы будут исчерпаны?
Например, у нас могут быть предусмотрены варианты:
запас оперативной памяти сервера (при условии соблюдения правил загрузки каналов);
замена CPU на более дорогой — как правило, лучше сразу выбрать с запасом или предусмотреть еще один CPU во второй слот в сервере;
увеличение количества дисков;
дополнительные сетевые адаптеры;
покупка еще одного / двух… серверов схожей конфигурации и т. п.
Рекомендую ограничиваться ближайшими прогнозируемыми шагами для увеличения ресурсов. Не стоит планировать закупку десяти серверов — виртуализация придумана для того, чтобы без этого обойтись.
В итоговой стоимости учитываем лицензии не только среды виртуализации, но и прочего программного обеспечения (см. предыдущий этап), а также лицензии на ПО по резервному копированию.
В результате вы имеете четко описанную инфраструктуру и подобранное под её виртуализацию оборудование с программным обеспечением, жизненным циклом, планом расширения и финансовым обоснованием для бизнеса.
Виртуализация — это современный адекватный базис любой ИТ-инфраструктуры, кроме разве что высокопроизводительных вычислений (high performance computing). Но какой бы путь вы ни выбрали, нужно понимать, что виртуализация — это не панацея, она не решает всех ИТ-проблем. Прежде чем пускаться в этот путь, определитесь с целями: 1) чего вы хотите достичь в результате и 2) каких улучшений ждёте? Рассмотрите все возможные варианты, трезво оцените свои возможности и потребности. Реалистичный взгляд — хорошее подспорье в любом проекте.
За консультацией и помощью — смело можете обращаться к нам! Мы реализуем проекты по виртуализации любой сложности.
