С ростом популярности Hyper-V, увеличением числа серверов виртуализации на предприятиях и количества используемых виртуальных машин становится актуальным вопрос сохранения уникальности используемых виртуальными машинами MAC-адресов. Как быть уверенным в том, что конфликтов из-за совпадения MAC-адресов у разных виртуальных машин не будет? Конечно, вы можете вручную задавать MAC-адрес для каждой сетевой карты каждой виртуальной машины — а также виртуальных адаптеров, подключающих «родительский» раздел к виртуальным сетям). Такой адрес называется «статическим» (Static). Но этот способ трудоёмок, слабоэффективен и подвержен челвеческим ошибкам. Для устранения этой проблемы в Windows Server 2008 и 2008 R2 существует механизм, автоматически задающий для виртуальных адаптеров последовательные MAC-адреса из специального диапазона. Однако по умолчанию этот диапазон ограничен лишь 256 значениями и не может гарантировать уникальность MAC-адресов ВМ, запущенных на разных серверах. Как же правильно спланировать инфраструктуру?
Способ первый. Ручная настройка серверов виртуализации
В Windows Server 2008 и 2008 R2 диапазоны MAC-адресов виртуальных машин Hyper-V задаются значениями MinimumMacAddress и MaximumMacAddress ключа реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion\Virtualization. В Windows Server 2008 R2 нет нужды просматривать и редактировать эти значения напрямую в реестре — они были добавлены в интерфейс диалогового окна «Virtual Network Manager» (Диспетчер виртуальных сетей).
Эти значения генерируются ОС при установке роли Hyper-V. Первые три октета являются идентификатором (00-15-5d), закреплённым за Microsoft как производителем сетевой карты (хоть она и виртуальная). Следующие два октета берутся из второй половины IP-адреса первого сетевого адаптера родительского сервера. На рисунке выше это 0b-27, потому что единственный IP-адрес моего сервера равен 192.168.11.39. Последний октет у значения MinimumMacAddress по умолчанию равен нулю, а у значения MaximumMacAddress равен FF — то есть на 256 больше начального.
Важно понимать, что диапазоны адресов генерируются только при установке роли Hyper-V и не сбрасываются при выполнении команды SysPrep. Так что если вы не используете SCVMM для управления инфраструктурой виртуализации (об этом см. ниже) и развёртываете серверы с помощью клонирования (например, используя MDT) — то выполняйте установку роли Hyper-V уже после применения образа, либо сами изменяйте диапазоны MAC адресов (вручную или сценарием). Не забывайте при этом проверять, чтобы диапазоны на разных серверах виртуализации не пересекались. Альтернативным вариантом будет перед запуском утилиты SysPrep удалить из реестра значения MinimumMacAddress и MaximumMacAddress. После развёртывания из образа система сгенерирует их автоматически при следующем запуске службы VMMS.
Динамический MAC-адрес присваивается виртуальному адаптеру при первом включении виртуальной машины и остаётся в свойствах ВМ до её удаления (или смены MAC-адреса на статический). Это верно как для унаследованных (Legacy), так и для синтетических (Synthetic) сетевых адаптеров, вне зависимости от того, подключены они к внешней (External), внутренней (Internal) или частной (Private) виртуальной сети. С настройками по умолчанию вам гарантирована уникальность 256 MAC-адресов, что дает возможность запустить 256 виртуальных машин, имеющих по одному сетевому интерфейсу. Или всего 64 виртуальных машины с четырьмя интерфейсами в каждой. Или любую комбинацию при условии, что суммарное количество интерфейсов запущенных виртуальных машин не превысит 256. Если вам требуется обеспечить возможность одновременной работы на одном узле большего числа виртуальных машин, потребуется расширить на этом узле диапазон MAC-адресов. Технически вы можете задать для него любые значения. Во избежание конфликтов с MAC-адресами физического оборудования рекомендется придерживаться диапазона, зарегистрированного за Microsoft (00-15-5D). Например, установив значение MinimumMacAddress в 00-15-5D-01-80-00 и MaximumMacAddress в 00-15-5D-01-8F-FF, вы получите диапазон из 4096 уникальных MAC-адресов на узле. И можете сделать аналогичные настройки на 4095 других узлах, задавая непересекающиеся диапазоны, начинающиеся на 00-15-5D.
Способ второй. System Center Virtual Machine Manager
Установив SCVMM и развернув его агентов на всех серверах виртуализации, создавая виртуальные машины и меняя их сетевые настройки из консоли администратора SCVMM, вы автоматически решаете задачу уникальности MAC-адресов виртуальных машин. SCVMM контролирует диапазоны динамических адресов на всех управляемых узлах, а при указании статических MAC-адресов проверяет их уникальность.
Для всех управляемых из SCVMM виртуальных машин на базе Hyper-V, VS2005 или VMware ESX зарегистрирован глобальный диапазон из 3998719 уникальных MAC-адресов в от 1D-D8-B7-1C-00 до 00-1D-D8-F4-1F-FF. Вы можете изменить этот диапазон, зайдя в представление «Administration» консоли администратора VMM, выбрав пункт «Networking» и управляя значениями полей «Global Static MAC Address Range». При этом следует соблюдать два правила.
Следует понимать, что при создании виртуальных машин из консоли SCVMM или его же коммандлетов Powershell, сетевые интерфейсы ВМ получат статические MAC-адреса из диапазона, указанного в настройках VMM (Global Static MAC address Range). Если же вы создадите виртуальную машину вручную через консоль (или API) Hyper-V Manager, то она получит динамический MAC-адрес из диапазона, заданного локально на узле, — согласно правилам, указанным в описании первого способа.
Если вы столкнётесь с конфликтами из-за дублирующихся MAC-адресов, вам может оказаться непросто найти источник этой проблемы. Очевидно, что при потере пакетов или странных задержках сети следует обращать внимание на MAC-адреса виртуальных машин, если только вы не используете SCVMM. Надеюсь, что теперь вам будет несколько проще спланировать непересекающиеся диапазоны уникальных MAC-адресов, удовлетворяющие потребностям вашей инфраструктуры.
Известно, что для построения кластера Hyper-V требуется общее хранилище, к которому будут иметь доступ все узлы кластера, и на котором будут храниться файлы виртуальных машин. В случае, когда все узлы кластера находятся в непосредственной физической близости (или хотя бы в пределах одного ЦОД) такое решение не вызывает вопросов. Существует множество хорошо известных способов организации общего хранилища — начиная общей шиной SAS и заканчивая SAN с подключением по FibreChannel. Поддержка работы со всеми этими типами хранилищ встроена в ОС Windows Server.
Однако что делать в случае, когда требуется обеспечить защиту от выхода из строя целого ЦОД? Для таких случаев предусмотрена возможность объединения в кластер узлов, которые физически расположены в разных ЦОД. Но как быть с данными? Вопрос организации общего хранилища здесь оказывается не столь тривиален, как в предыдущем случае. Ведь выход из строя ЦОД автоматически означает потерю данных, которые в нём хранятся. А значит — для борьбы с этим нам необходима независимая копия данных в каждом ЦОД. Однако эти копии должны быть синхронизированы, иначе пользы от такого решения не много. Проще говоря, необходим механизм репликации данных между СХД, находящимися в разных ЦОД.
Кластеры Windows Server вообще и Hyper-V в частности не содержат встроенного механизма репликации данных и предполагают, что все узлы кластера подключены в одной и той же копии данных. А значит — разница между физическими хранилищами и репликация между ними должны быть полностью прозрачны для ОС и используемой ею файловой системы. Иными словами, такие механизмы как DFS-R хоть и встроены в состав Windows Server, не подходят для построения территориально распределённого кластера виртуализации.
И вот здесь открываются возможности для решений компаний-партнёров. Существует несколько продуктов и технологий, которые решают поставленную задачу и совместимы с Hyper-V. Эти решения могут быть как аппаратными (встроенными в реализацию СХД), так и программными. Одним из поставщиков таких решений является компания SteelEye Technology, Inc. Она предлагает продукты для аварийного восстановления (Disaster Recovery), репликации данных (Data Replication) и построения территориально распределенных и мульти-серверных кластерных систем (Multi-Site Clustering).
В эту пятницу, 29 января 2010 с 15.30 до 16.30 по московскому времени компания SteelEye проводит обзорную вебтрансляцию для партнёров и потенциальных заказчиков. Эта вебтрансляция будет посвящена презентации линейки продуктов SteelEye и тому, как они могут дополнить решения виртуализации Microsoft. Вот как выглядит заявленная программа.
Для участя в вебтрансляции требуется предварительная регистрация на сайте компании Nordicmind.
Сегодня для большинства серверных нагрузок наиболее узким местом с точки зрения производительности является подсистема памяти. Основными сдерживающим фактором этой производительности являются пропускная способность шины памяти (как правило её частота ниже, чем половина частоты ядра процессора), а также задержка при выполнении адресации на микросхемах памяти. Получение строки данных из оперативной памяти в среднем может занимать до нескольких тысяч тактов процессора, во время которых он фактически простаивает. Для решения данной проблемы давно используется техника введения дополнительных уровней быстродействующей памяти (кэш), в которые заранее подгружаются необходимые строки из оперативной памяти.
Использование многопроцессорных и многоядерных систем подразумевает еще больше проблем с доступом к памяти. Разделение шины памяти между несколькими процессорами еще сильнее снижает скорость получения данных из памяти. Кроме того, возникают новые сложности, связанные с обеспечением когерентности кэша процессоров. С инженерной точки зрения одним из простейших подходов к ускорению пропускной способности доступа к памяти в многопроцессорных системах является технология NUMA («Non-Uniform Memory Access» или «Non-Uniform Memory Architecture»). В этом случае у каждого процессора есть «своя часть» оперативной памяти, к которой он получает доступ через выделенный контроллер. При этом к памяти, привязанной к другим процессорам, можно получить доступ через «чужой» контроллер. Естественно, скорость получения данных при обращении к «чужой» памяти будет значительно ниже, чем при обращении к «своей». Накладные расходы, связанные с обеспечением когерентности кэшей, также повышают задержку при доступе к памяти другого процессора.
Современные серверные платформы на базе процессоров Intel и AMD используют NUMA с помощью технологий QPI и HyperTransport соответственно. Кроме того, существует технология IBM Multinode, которая позволяет задействовать NUMA на более высоком уровне путем объединения нескольких серверов (уже использующих NUMA) на коммутаторе. Примером систем, реализующих NUMA, являются HP ProLiant DL785 G5/G6 и IBM x3850 M2.
Серверные операционные системы, поддерживающие NUMA, — такие, как Windows Sever 2008 и Windows Server 2008 R2 — должны оптимизировать использование процессорами памяти, доступной для них наиболее быстро. Что происходит в данном случае с виртуальными машинами?
Мы знаем, что Hyper-V не использует жесткую привязку к физическому процессору (Processor affinity). Виртуальная машина использует те логические процессоры, которые в настоящее время свободны и предоставляются гипервизору постановщиком ресурсов (Scheduler). Но при этом каждая виртуальная машина имеет специальную характеристику для задания «узла NUMA». Она позволяет гипервизору указать, с каких процессоров и с какой шины памяти будут использоваться ресурсы для данной ВМ.
Этот параметр задаётся при каждом включении виртуальной машины, получая ссылку на наиболее свободный на момет её запуска узел. В случае недостатка ресурсов в «своём» узле NUMA, гипервизор начинает предоставлять виртуальной машине ресурсы другого узла. Поэтому технически могут возникать ситуации, в которых виртуальные машины используют ресурсы нескольких узлов NUMA одновременно. Чтобы предотвратить такое неэффективное использование ресурсов, администратор может в явном виде задать предпочитаемый узел NUMA для каждой виртуальной машины. При этом вы можете в любой момент проверить, какой узел использует виртуальная машина.
В моём примере созданы четыре виртуальным машины.
Если я запущу все виртуальные машины и открою Performance Monitor, то в строке «Preferred NUMA Node Index» я увижу, на каком из узлов NUMA запущена виртуальная машина. В нашем случае гипервизор сбалансировано распределил четыре виртуальных машины между двумя узлами NUMA.
Узлы NUMA нумеруются с нуля, две виртуальных машины разместились на узле 0, а две на узле 1. Причем используемое количество логических процессоров и памяти суммарно на каждом из узлов NUMA максимально схоже — так работает балансировка.
Теперь предположим, что виртуальная машина Test-2, которой мы предоставили наибольшее количество процессоров и памяти, в действительности требует большей производительности чем остальные. И что мы бы хотели разместить её на отдельном узле NUMA, оставив все прочием машины на другом.
Мой коллега из Windows Perfomance Team разместил в своём блоге сценарий Powershell, который позволяет явно указывать узел NUMA для виртуальной машины. На всякий случай также прикладываю файл со сценарием к этой статье. Используя этот сценарий, я в явном виде укажу виртуальной машине Test-2 всегда запускаться на узле 0: numa.ps1 /set test-2 0. А виртуальные машины Test-1, Test-3 и Test-4 будут запускаться на узле 1: numa.ps1 /set test-1 1, numa.ps1 /set test-3 1, numa.ps1 /set test-4 1. Изменение привязки к узлу NUMA работает только после включения виртуальной машины. Если виртуальная машина была включена, вам потребуется перезапустить её.
Теперь виртуальная машина Test-2 исключительно занимает узел 0. Заданное предпочтение узла NUMA совместимо с Live Migration и Quick Migration. Переместив такую виртуальную машину на другой узел кластера, вы увидите, что привязка к конкретному узлу NUMA «переехала» вместе с машиной.
К описанной настройке следует подходить осторожно. Надо понимать, что если вы жёстко задали всем виртуальным машинам использовать конкретный узел NUMA, и они используют всю его память или полностью загружают ресурсы процессора, то уже никакой механизм автоматически не перенесет эти машины на другой узел NUMA.