Многие из вас уже, должно быть, начинают думать о начале проекта по виртуализации серверов на базе платформы VMware vSphere, которая стала вполне доступной для сектора SMB (издания VMware vSphere Essentials). Кроме того, пакеты VMware vSphere Acceleration Kits со скидками для приобретающих впервые - никто не отменял (скидки 20-30% при покупке лицензий на 3-4 сервера). Но сегодня не о ценах, а о том, как правильно спланировать виртуальную инфраструктуру VMware vSphere с учетом появившихся новых технологий и возможностей VMware.
Итак, если начать планировать по этапам, вот так выглядят составляющие инфраструктуры при проектировании решения VMware vSphere 4:
Обоснование экономического эффекта перед руководством (ТЭО - по-русски, TCO+ROI - по-западному)
1. Для первоначальных расчетов можно использовать следующие калькуляторы VMware:
http://www.vmware.com/go/calculator - более точный калькулятор, который детально расписывает статьи затрат (например, приобретение системы хранения) и совокупную стоимость владения виртуальной и физической инфраструктурой (TCO).
2. Далее расчеты можно уточнять в собственных калькуляторах Excel. Можно использовать русскоязычные источники:
3. Посчитать все самим, используя мощное средство всех времен и народов Microsoft Excel.
При самостоятельном расчете во внимание нужно принимать следующие факторы:
1. Выбирайте оборудование только из официального списка совместимости VMware HCL (в котором есть vSphere), чтобы не столкнуться с проблемами стабильности и производительности, а также отказе в технической поддержке VMware.
2. "Узким местом" сайзинга почти всегда является оперативная память. Соответственно, нужно выбирать серверы с наибольшим объемом оперативной памяти, но помните что много - не всегда значит быстро. С точки зрения CPU и Network - почти всегда хватает отсайзенного под память оборудования. Конечно же, правильным образом нужно посчитать и систему хранения, особенно для нагрузок чувствительных ко вводу-выводу.
3. vSphere лицензируется по физическим процессорам - поэтому берите процессоры с большим числом ядер (однако учтите, что 6 ядер предел для некоторых изданий VMware vSphere).
4. При развертывании виртуальных серверов VMware на имеющемся оборудовании, учитывайте совместимость хостов по EVC (Enhanced VMotion Compatibility). Подробнее можно прочитать в KB1003212.
5. Если вы планируете использовать VMware Fault Tolerance - помните об ограничениях данной технологии у VMware vSphere. Для проверки существующей инфраструктуры на совместимость по Fault Tolerance есть утилита от VMware - SiteSurvey.
6. Помните, что такие технологии как Memory sharing и overcommittment снижают требования к объему необходимой памяти в среднем на 30% для большинства инфраструктур.
7. При выборе блейд-платформы будьте внимательны - не столкнитесь с проблемами ограничения I/O на корзину.
8. По-возможности стандартизируйте закупку серверов и систем хранения для виртуальной инфраструктуры. Это поможет избежать проблем совместимости по VMotion / DRS / Fault Tolerance и снизить затраты на администрирование.
9. Помните, что сейчас ключевая точка принятия решения - ESX или ESXi. 4-я версия VMware vSphere - последняя, где есть "толстый" гипервизор с сервисной консолью - ESX. Однако сейчас, все-таки, пока стоит выбрать ESX.
Выбор системы хранения и построение SAN
Здесь вариантов огромное количество. Fibre Channel, iSCSI, NAS / NFS и Local Storage - все поддерживается для VMware vSphere. Тем не менее, у каждого производителя есть свои рекомендации. Например, вот некоторые рекомендации: EMC, HP, NetApp.
2. Помните, что в VMware vSphere появилась возможность Thin Provisioning для виртуальных дисков, что позволяет сократить необходимые дисковые емкости на 20-50% для большинства инфраструктур. За счет чего? Раньше системные администраторы выделяли виртуальным машинам дисковое пространство, учитывая что в будущем задача будет больше его потреблять. Однако, зачастую, это пространство так и не начинает использоваться, вследствие чего теряются дорогостоящие емкости. Теперь же виртуальные машины могут потреблять дисковое пространство по мере наполнения своих виртуальных "тонких" дисков.
4. Помните, что для некоторых массивов появились возможности балансировки по путям в SAN, реализуемые через модули производителей. Например, продукт Powerpath/VE от EMC.
5. Проектируйте SAN по архитектуре Dual Fabric / Core-Edge, обеспечьте отказоустойчивость для всех компонентов сети SAN.
8. Тщательно измеряйте Disk I/O физических систем, которые сейчас работают с локальными дисками - потом несколько таких систем будут находиться на общей системе хранения.
9. Планируйте размещение ресурсов хранения в виртуальной среде в концепции "ярусного хранения" (tiered storage). Разносите хранилища тестовых и продуктивных виртуальных машин.
10. Планируйте использование Storage VMotion - технологии, которая сделает виртуальные машины более мобильными с точки зрения хранилищ.
Сетевое взаимодействие хостов ESX и виртуальных машин в VMware vSphere
У VMware vSphere появилось несколько нововведений, которые упрощают администрирование хостов VMware ESX / ESXi, что необходимо учитывать при планировании виртуальной инфраструктуры. Чему именно надо уделять внимание:
1. На хостах ESX / ESXi число сетевых адаптеров должно быть максимально большим: понадобится организация сети управления (Service Console), VMotion, Fault Tolerance (несколько адаптеров) и Failover / Load Balancing-адаптеры для виртуальных машин. Рекомендуется не менее 4-х сетевых адаптеров для каждого хоста ESX.
2. Планируйте использование VLAN (выберите режим тегирования). Помните, что vSphere поддерживает Private VLAN (PVLAN) для vNetwork Distributed Switch. Детали можно узнать в документе ESX Configuration Guide на странице 32.
3. Помните, что с появлением Distributed Switch в VMware vSphere стало проще управлять сетевыми конфигурациями хостов. Планируйте внедрение этих коммутаторов в обязательном порядке для сокращения затрат на администрирование.
4. Планируйте использование сетевого экрана VMware vShield Zones - с ним проще централизованно управлять конфигурациями сетевых экранов на хостах VMware ESX.
5. Если вам нужна дополнительная функциональность от виртуальных коммутаторов - задумайтесь об использовании Cisco Nexus 1000V Virtual Switch. Здесь таблица отличий от dvSwitch.
7. Обеспечьте отказоустойчивость на уровне физических компонентов сети.
Выделение ресурсов - пулы ресурсов, VMware DRS
Здесь мало что изменилось, поэтому рекомендации при планировании следующие:
1. Появился режим экономии питания VMware Distributed Power Management. По испытаниям он позволяет экономить до 40% электроэнергии, затрачиваемой на питание хостов ESX / ESXi. Это полностью поддерживаемая промышленная технология у VMware vSphere, что может помочь вам на начальном этапе с экономическим обоснованием.
2. Планируйте будущие пулы ресурсов. Ограничивайте потребление ресурсов тестовыми системами и пулами сверху (Limit), а резервирование ресурсов производственными системами снизу (Reservation). Гарантируйте ресурсы на случай отказов хостов.
3. Создайте отдельный кластер для тестовых систем.
4. Если администратор управляет связкой серверов, которые зависят друг от друга, имеет смысл использовать контейнеры vApps для групп виртуальных машин.
5. Экспериментируйте с порогом миграции VMware DRS - начните с "консервативного" и продвигайтесь до "агрессивного".
С точки зрения защиты данных появилось много новых возможностей в VMware vSphere и теперь можно планировать виртуальную инфраструктуру с высоким уровнем обеспечения надежности данных и высокой доступностью.
1. Появился VMware vCenter Data Recovery - это позволит создавать резервные копии виртуальных машин и восстанавливать их. Этот функционал поддерживается и в VMware vSphere Essentials Plus - приемлемом по ценам издание vSphere. Обязательно опробуйте это средство.
2. Теперь запасы отказоустойчивости расчитываются и настраиваются более гибко, что облегчает планирование. Для наименее стабильных систем полезно будет включить режим защиты от "зависаний" - VM Monitoring.
3. Одна из стратегий защиты от сбоев серверов - помещение в виртуальной инфраструктуре "горячего" хост-сервера ESX. В случае отказа одного из продуктивных хост-серверов - его виртуальные машины перезапустятся на этом сервере.
4. Помните, что отказоустойчивость на уровне ЦОД средствами VMware Site Recovery Manager не поддерживается для VMware vSphere. VMware SRM будет доступен во втором квартале 2009 г. Тем не менее, сейчас есть возможность "даунгрейда" на VMware Virtual Infrastructure 3.5.
5. По статистике непрерывной доступности требуют 10-15% систем в инфраструктурах. Запланируйте тестовую зону с VMware Fault Tolerance. Помните об ограничениях.
Централизованное управление VMware vCenter 4
1. Планируйте объединение хостов VMware vCenter через Linked Mode для прозрачного контроля над инфраструктурой. Откажитесь от "менеджера менеджеров" Microsoft SC VMM.
2. Назначайте новые роли организационной структуры - администраторы сетевого окружения серверов ESX (Network Consumer) и администраторы хранилищ виртуальных машин (Datastore Consumer).
4. Помните, что у VMware vCenter 4 требования выше, чем у прошлой версии - VirtualCenter 2.5.
5. При необходимости непрерывной доступности серверов VMware vCenter (например, для SRM) можно использовать продукт vCenter Heartbeat.
6. Для планирования миграции физических систем в виртуальную среду используйте VMware vCenter Converter. Обязательно просмотрите документ VMware vCenter Converter Admin Guide.
7. Помните, что сейчас самое время сделать VMware vCenter виртуальным, если сейчас он физический. Это повысит отказоустойчивость и высвободит сервер.
Автоматизация операций в виртуальной инфраструктуре
Надо понимать, что VMware vSphere управляется не только через "жестко прошитый" функционал VMware vCenter. Есть также несколько путей по автоматизации рутинных операций администраторов VMware vSphere и надо обязательно рассмотреть возможность их использования:
1. Интерфейс Microsoft PowerShell для автоматизации задач администратора посредством скриптов.
2. VMware vSphere Management Assistant (бывший продукт VIMA - VI Management Assistant) - виртуальный модуль для управления набором хостов ESX / ESXi.
3. VMware vCenter Orchestrator для автоматизации типовых процессов управления виртуальной инфраструктурой.