С выходом Windows 7 и Windows Server 2008 R2 нам была представлена технология Direct Access, позволяющая получать доступ к корпоративной сети без создания виртуальных частных сетей (VPN) или использования служб Удалённого рабочего стола (Remote Desktop). Подробнее о Direct Access можно почитать на блоге моего коллеги — эта технология заслуживает, по меньшей мере, внимательного изучения.
Прошёл год с выхода новой ОС, и теперь всё чаще мои заказчики начинают её использовать. Начинают, конечно же, с подразделений IT, с администраторов. Какой доступ требуется администратору из дома в корпоративную сеть? Почта обычно доступна и без таких модных технологий. Работать с документами и порталами? Из дома? Извините! Для меня DirectAccess дает возможность при необходимости запустить консоль администрированя той или иной службы для настройки и исправления возникающих проблем. Ну и, естественно, меня интересует консоль Hyper-V Manager для управления узлами виртуализации — на которых, собственно, и развёрнута вся корпоративня инфраструктура.
Тут, однако, есть тонкий момент. Настроив DirectAccess и проверив, что контроллеры домена мне доступны, что я получаю доступ к файловым серверам, что я могу «удалённым рабочим столом» зайти на серверы виртуализации, — я считаю задачу выполненной. Но в один «прекрасный» день я пробую соединиться с узлами виртуализации из консоли Hyper-V Manager — и... не могу этого сделать. Давайте разберемся, в чем же дело, и что необходимо настроить дополнительно.
Консоль Hyper-V Manager работает с узлами виртуализации при помощи двусторонних (bi-directional) запросов к WMI. При установки консоли Hyper-V Manager (из Windows 7 Remote Server Administration Tools) во встроенном брандмауэре создаются три специальных исключения. Да, три правила, даже на клиентской ОС!
Эти три правила разрешают входящий трафик RPC и DCOM, необходимый для управления узлами виртуализации и виртуальными машинами Hyper-V.
Вкупе с использованием DirectAccess возникает следующая проблема.
Для того, чтобы исправить это досадное недоразумение, нам потребуется слегка видоизменить обозначенные выше правила брандмауэра. Для этого из Administrative Tools откроем оснастку Windows Firewall with Advanced Security.
Выберем список правил, разрешающих входящий трафик, и найдем те, которые отвечают за Hyper-V.
Откроем первое из этих правил.
В закладке Advanced заметим, что Edge Traversal запрещен, блокируя трафик NAT.
Изменим это значение на Allow Edge Traversal и применим аналогичные настройки для двух оставшихся правил.
Следует понимать, что для работы Hyper-V Manager через DirectAccess потребуется, чтобы узел виртуализации мог разрешить адрес IPv6 вашего компьютера по его имени (ведь DirectAccess использует только IPv6). Чтобы проверить это, убедитесь в том, что с сервера виртуализации команда ping на имя вашего удаленного ПК должна отрабатывать на его адрес IPv6. Обычно это не является проблемой при правильно настроенном DNS. Если ваш сервер DNS не поддерживает записи AAA IPv6, вы можете вручную добавить соотношение имени и адреса IPv6 в файл hosts на узлах виртуализации.
Надеюсь, что кому-то это поможет. Помните, что DirectAccess доступен только в редакциях Enterprise и Ultimate Windows 7 и работает по IPv6.
К написанию этой заметки меня подтолкнула необходимость миграции одного из кластеров с виртуальными машинами в технологическом центре Microsoft с платформы Windows Server 2008 на Windows Server 2008 R2. Задача назрела уже давно, однако, на миграцию стабильно работающей продуктивной среды не было времени. К тому же заранее вырисовывалась одна техническая проблема: кластер использует различные внешние дисковые массивы, а в частности HP MSA 2012fc, который не поддерживается HP под Windows Server 2008 R2. Что означает «не поддерживается HP»? К сожалению, HP не предоставляет программного обеспечения для массивов MSA под новую ОС.
Как вы понимаете, большинство серверов, имеющие HBA для подключения к SAN, имеют несколько портов. И каждый сервер может (и в нормальной ситуации должен) подключаться к любому из устройств хранения через несколько портов одновременно. Кроме того, у системы хранения, как правило, тоже не одна точка подключения в сеть, а у некоторых из таких систем — ещё и по несколько контроллеров, каждый со своим набором портов. При правильной настройке SAN, каждый из портов сервера должен «видеть» каждый из портов системы хранения. При этом между ними ещё могут находиться не один, а несколько коммутаторов. Всё это служит, в первую очередь, для обеспечения избыточности — подключение к хранилищу более не является единой точкой сбоя. Кроме того, при определённых условиях эта схема может обеспечивать дополнительные преимущества — такие, например, как балансировку нагрузки между путями.
Однако при настройке по умолчанию операционная система ещё «не понимает», что то, что она «видит» по разным путям, на самом деле является не разными устройствами, а одним и тем же. И для того, чтобы она «видела» каждый из представленных ей дисков в единственном экземпляре, мы устанавливаем во-первых, специальный компонент (Feature), который так и называется: Multi-Path Input-Output (MPIO). А во-вторых — специальное ПО, которое поставляется производителем системы хранения, встраивается в инфраструктуру Microsoft MPIO и обеспечивает работу с данной конкретной моделью оборудования. Этот компонент называется Device-Specific Module (DSM).
Увы, для Windows Server 2008 R2 компания HP не предоставляет MPIO DSM, совместимого с массивами Modular Storage Array (MSA) 1000/1500/2000. А MPIO DSM для Windows Server 2008 не работает в Windows Server 2008 R2. В связи со сложившейся ситуацией передо мной возникает задача настройки MPIO без использования специального ПО.
Рассмотрим на реальном примере процесс установки и настройки Microsoft Multipath I/O в Windows Server 2008 R2. Для начала нам потребуется установить сам компонент ОС (Feature).
Просто установка компонента ещё никак не влияет на то, как система «видит» диски. Теперь нам предстоит настроить MPIO. Сейчас в Disk Manager мне доступны два LUN с MSA 2012fc — по двум путям каждый — и один LUN с NetApp — по четырём путям.
Для начала откроем панель управления MPIO.
Перейдя в закладку Discover Multi-Paths увидим те массивы, которые доступны системе по нескольким путям, но для которых MPIO еще не настроен.
Выделим требуемый массив, выберем Add и по требованию системы перезагрузим сервер.
После перезагрузки в панели управления MPIO мы уже увидим добавленные массивы, появившиеся в основной закладке MPIO Devices.
Уже сейчас в Disk Manager я вижу каждый LUN только один раз — задача выполнена.
Теперь при желании я могу настроить параметры выбора пути MPIO. Для этого в Device Manager выберем диск, и во вкладке MPIO можем настроить различные способы определения путей. По умолчанию выставлен режим Round Robin, пытающийся равномерно распределять запросы к диску по всем путям.
Лично я для Microsoft MPIO предпочитаю выбирать режим Fail Over Only. Для этого необходимо выбрать соответствующий путь в выпадающем списке — и для всех путей, кроме основного, выставить настройку Standby, оставив Active/Optimized только для основного пути.
Для конфигурации доступны и другие политики настройки MPIO, о которых вам следует внимательно почитать.
Если эта заметка вызовет интерес, я готов более подробно описать теорию различных политик настройки MPIO, а также отличия в настройке для Server Core и Hyper- V Server, не имеющих панели управления и диспетчера устройств.
На этой неделе вместе с очередными обновлениями безопасности были выпущены и два долгожданных обновления для SCVMM 2008 R2. Эти обновления не связаны с безопасностью, а исправляют целый ряд проблем, которые могли возникать при работе с продуктом.
Первое исправление предназначено для установки на сервер SCVMM и описано в статье Базы знаний Microsoft под номером 982522 — Description of the System Center Virtual Machine Manager 2008 R2 hotfix rollup package: June 8, 2010. Оно исправляет следующие проблемы.
При подключении диска GPT к выскокодоступной виртуальной машине (Highly available virtual machine) с помощью оснасток Hyper-V Manager или Failover Cluster Management, SCVMM меняет статус виртуальной машины на «Unsupported Cluster Configuration».
При подключении инфраструктуры VMware vSphere, использующей распределённые виртуальные коммутаторы (Distributed Virtual Switch), служба Virtual Machine Manager (процесс Vmmservice.exe) постоянно завершается с ошибкой.
После проведения быстрой миграции на другое хранилище (Quick Storage Migration, QSM) между общими томами в кластере (Cluster Shared Volume, CSV), оснастка Failover Cluster Management отображает, что виртуальная машина всё ещё использует старое хранилище.
Если виртуальная машина настроена на использование трёх виртуальных процессоров, Консоль админинстратора SCVMM закрывается с ошибкой.
Настройки виртуальной сети искажаются после выполнения коммандлета Refresh-VMHost .
Кроме того, это обновление включает в себя оба ранее выпущенных исправления для SCVMM. О них мы писали в заметке «Накопительные обновления (Rollup Update) для System Center Virtual Machine Manager (SC VMM) 2008 R2». Там же опубликована подробная информация о том, как загружать обновления для SCVMM и устанавливать их вручную.
Второе исправление предназначено для установки на компьютеры, на которых используется Консоль администратора SCVMM. Оно описано в статье Базы знаний Microsoft под номером 982523 Description of the System Center Virtual Machine Manager 2008 R2 Admin Console hotfix rollup package: June 8, 2010
Это исправление необходимо для решения четвёртой проблемы, описанной выше. Т.е. вам потребуется установить оба обновления — первое на сервер, а второе на компьютер, на котором запускается Консоль администратора.