Сделай сам: стенд с решениями для виртуализации — введение

Привет, меня зовут Артём Проничкин. С самого начала я участвую в этом блоге в качестве редактора, а на прошедшей неделе работал с Алексом и его коллегами над стендом для демонстрации Hyper-V и SCVMM. Этой статьёй я открываю цикл заметок, в которых обобщу сделанные нами выводы и полученный опыт. Во вводной статье я затрону самые общие соображения и расскажу историю нашего собственного стенда. А дальше перейду к конкретным описаниям настройки тех или иных компонентов. Прошу обратить внимание, что описываемые здесь сценарии хорошо подходят для демонстраций и тестов, но совершенно не поддерживаются в промышленной эксплуатации. Поэтому если вас интересует выбор оборудования для сборки системы, готовой к настоящей работе, — обратитесь к официальной документации и Windows Server Catalog.

В простейшем случае вам понадобятся две машины, которые будут узлами кластера Hyper-V, и общее хранилище для них. Поскольку вы вряд ли найдёте дешёвое аппаратное общее хранилище (если найдёте — напишите мне об этом), рекомендую воспользоваться программной реализацией iSCSI. Это потребует от вас третьей машины, которую по совместительству можно сделать контроллером домена, установить на неё System Center Virtual Machine Manager и VMware VirtualCenter (при необходимости). Понятное дело, что если позволят ресурсы, то все эти приложения лучше разнести по разным виртуальным машинам, но в принципе это необязательно. Также, если вы последуете моей рекомендации и установите узлы кластера в варианте Server Core, то на эту третью машину можно будет установить инструменты удалённого управления Hyper-V и Failover Cluster — для удобства работы через графический интерфейс. Ещё можно добавить одну-две машины с Virtual Server — им SCVMM тоже может управлять. Понятно также, что если вам потребуется демонстрировать интероперабельность с VMware, вам потребуется одна (а лучше две) машины, на которые вы установите VMware ESX Server.

Задачей нашего стенда было продемонстрировать работу SCVMM 2008 с кластерами Hyper-V, а также возможность управления VMware Virtual Infrastructure 3. Таким образом, первоначально мы хотели ограничиться пятью ноутбуками Lenovo ThinkPad T61p. Они хороши тем, что отвечают всем системным требованиям Hyper-V: поддерживают Intel VT, Execute Disable bit, а также существенный объём оперативной памяти — на наших системах было по 4 Gb. Однако позже выяснилось, что на этом оборудовании не работают системы VMware. Поэтому нам пришлось экспроприировать в лабораторном классе два десктопа HP Workstation xw6200. Они не подходят для Hyper-V, так как не поддерживают технологию Intel VT. Однако, на них прекрасно установились и заработали как VMware ESX Server 3.5, так и ESX Server 3i. Освободившиеся ноутбуки мы использовали для того, чтобы выделить отдельную машину для iSCSI Target — понятно, что это увеличивает производительность.

В конечном итоге наш стенд состоял из шести машин, объединённых в общую сеть. (Стрелки на диаграмме показывают логическое взаимодействие, а не физические подключения).

 

 

Ещё пара слов о производительности. В нашем распоряжении оказался только один коммутатор, работающий на скорости всего 100 mb/s. В результате мы получили одну из худших конфигураций из вообще возможных. Мало того, что использовалась программная реализация iSCSI вместо аппаратной (не говоря уже о Fibre Channel) — так ещё и работала она на скорости 100 mb/s в одной сети с трафиком виртуальных машин и управления. Кроме того, на ноутбуках было установлено по единственному жёсткому диску со скоростью 4200 оборотов в минуту. И на сервере iSCSI Target этот диск использовали два кластера сразу — Hyper-V и ESX Server. Но даже в таком запущеном случае машина с объёмом оперативной памяти 1 Gb перемещалась между узлами кластера Hyper-V примерно за 30-40 секунд.

Продолжение темы (список будет пополняться по мере добавления новых статей).