Администратор в Windows 7 и Customization Specification

По умолчанию, в операционных системах Windows Vista и Windows 7 для большей безопасности встроенная локальная учетная запись администратора отключена (disabled). Кроме того, учетная запись администратора отключается при отработке утилиты sysprep (например, при разворачивании и настройке виртуальной машины из шаблона с помощью Customization Specification).

Чтобы обойти это ограничение, создайте в виртуальной машине Windows 7 в папке "%WINDIR%\Setup\Scripts\" файл setupcomplete.cmd и добавьте в него следующую команду:

net user Administrator /active:yes

Для русской версии, соответственно, будет "Администратор".

Теперь при отработке sysprep будет автоматически выполнен скрипт, который включит учетную запись администратора.

Загрузка и установка VMware ESXi по сети

Вариант загрузки и установки ESXi по сети может пригодиться, если вам требуется в короткие сроки развернуть большое количество однотипных серверов, не оснащенных CD приводами (например, блейд-серверы), а также автоматизировать однотипные действия, вроде принятия лицензионного соглашения или установки пароля администратора. При наличии уже развернутого vCenter Server можно воспользоваться VMware PXE Manager for vCenter, однако, если его нет - придется делать все самим.

Процесс загрузки и установки сервера по сети включает в себя следующие этапы:

1. При запуске сервера, управление передается загрузчику в сетевом адаптере (PXE - Preboot eXecution Environment).
2. PXE посылает широковещательный запрос DHCP серверам сети с целью получения сетевых настроек.
3. Помимо IP адреса и маски подсети, DHCP сервер отправляет дополнительные параметры - адрес TFTP сервера и путь к файлу загрузчика, который следует запустить.
4. Загрузчик (в нашем случае pxelinux) в соответствии с настройками, заданными в конфигурационном файле (default), загружает ядро, также используя протокол TFTP.
5. Наконец, ядро запускает процесс автоматической установки ESXi с параметрами из kickstart файла, который может располагаться, например, на FTP или HTTP сервере.

В качестве примера рассмотрим процесс подготовки сервера Windows Server 2008 R2 для развертывания с его помощью VMware ESXi 4.1 Update 1.

Подготовка дистрибутива
Загрузите последнюю версию Syslinux с сайта (на момент написания - syslinux-4.04.zip).

Скопируйте содержимое дистрибутива VMware ESXi 4.1 Update 1 в папку на сервере (например, 'C:\FTPRoot'). В эту же папку скопируйте три файла из архива Syslinux: pxelinux.0 (расположен в ".\core\"), mboot.c32 (расположен в ".\com32\mboot\") и menu.c32.(расположен в ".\com32\menu\") Подтвердите замену файлов.

Создайте папку и назовите ее pxelinux.cfg, скопируйте в нее файл isolinux.cfg из дистрибутива ESXi и переименуйте его в default (без расширения).

Настройка сервера
Для загрузки по сети нам понадобятся следующие службы:

• TFTP;
• DHCP;
• DNS;
• FTP.

Необязательно размещать все службы на одном сервере, однако, в тестовых целях вполне можно и совместить их.

В качестве TFTP сервера вы можете использовать встроенную службу Windows Deployment Services. Пример настройки TFTP сервера приведен в данной статье. В качестве альтернативного TFTP сервера можно использовать TFTPD. TFTPD проще в установке, а также может выступать в роли DHCP сервера.

При настройке TFTP сервера в качестве корневой укажите ранее созданную папку, в которую был скопирован дистрибутив ESXi.

Если требуется - установите DHCP сервер. Создайте резервацию для MAC адреса адаптера будущего ESXi сервера, с которого будет осуществляться загрузка по сети. Использование резервации вместо задания параметров на уровне всего диапазона адресов или сервера DHCP является хорошей идеей, дабы ненароком не запустить установку ESXi на других компьютерах, настроенных на загрузку по сети.

Обязательно задайте следующие DHCP опции.

• 060 PXE Client - в качестве значения укажите: PXE Client.
• 066 Boot Server Host Name - в качестве значения укажите IP адрес или DNS имя TFTP сервера.
• 067 Bootfile Name - в качестве значения укажите: pxelinux.0.

В качестве примера по настройке опций DHCP можете ознакомиться с этой статьей.

DNS сервер может понадобиться, если вы планируете указывать DNS имена серверов вместо IP адресов в параметрах DHCP и в конфигурационных файлах.

Установите FTP сервер, используя мастер Add Roles Wizard.

Откройте консоль управления IIS и создайте новый FTP сайт.

На вкладке Site Information задайте произвольное имя (FTP site name), а в качестве корневой директории FTP сайта (Physical path) укажите ранее созданную папку с дистрибутивом (например, "C:\FTPRoot"). Нажмите Next.

На вкладке Binding and SSL Settings отключите требование использования SSL при подключении (No SSL). Нажмите Next.

На вкладке Authentication and Authorization Information разрешите анонимным пользователям аутентифицироваться на сайте, включив Authentication | Anonymous, а также загружать файлы Allow access to: Anonymous users и Permissions | Read. Нажмите Finish для завершения мастера и создания сайта.

Редактирование kickstart файла
При редактировании текстовых файлов из Windows обратите внимание на следующие особенности.

В Windows и в ESXi используются разные форматы перевода строк. Из-за этого файл, сохраненный в Windows, в ESXi будет отображаться вот так:

Это может стать причиной разнообразных ошибок при выполнении скриптов из kickstart файла. Для решения данной проблемы вы можете:

1. Использовать для загрузки kickstart файла протокол FTP.
2. Использовать сторонний текстовый редактор, который позволяет настраивать формат переносов (например, Notepad++).

В текстовом редакторе создайте файл ks.cfg следующего содержания:

vmaccepteula
rootpw P@ssw0rd
autopart --firstdisk=local
install url ftp://<SERVERNAME>
network --bootproto=dhcp --device=vmnic0 --vlanid=0 --addvmportgroup=0
reboot

где <SERVERNAME> соответствует имени или IP адресу FTP сервера, на котором расположен дистрибутив.

Подробнее о параметрах в файле ks.cfg можно прочитать в руководстве по установке ESXi.

Сохраните файл в корневую папку FTP сервера.

Отредактируйте файл default в папке pxelinux.cfg, добавив в него параметр, указывающий на расположение kickstart файла, например так:

default menu.c32

menu title VMware VMvisor Boot Menu

timeout 80
label ESXi Installer
menu label ^ESXi Installer
kernel mboot.c32
append vmkboot.gz ks=ftp://<SERVERNAME>/ks.cfg --- vmkernel.gz --- sys.vgz --- cim.vgz --- ienviron.vgz --- install.vgz
labelBoot from local disk
menu label ^Boot from local disk
localboot 0x80

Где <SERVERNAME> соответствует IP адресу или DNS имени вашего FTP сервера, на котором располагается kickstart файл.

Обратите внимание, что параметр ks= следует указывать сразу за vmkboot.gz, в противном случае, вы можете получить сообщение об ошибке.

Проверка работы
Для проверки работоспособности решения, достаточно запустить целевой сервер в качестве загрузочного устройства выбрать сетевой адаптер. Если все было сделано правильно, то через некоторое время вы увидите привычное окно установщика ESXi, а буквально через пару минут, и сам установленный ESXi.

VMware vExpert 2011

Пускай и с небольшим опозданием, но тоже спешу похвалиться получением в этом году статуса VMware vExpert.

Хочу выразить благодарность людям, которые номинировали меня - без Вас я бы даже не почесался, своим коллегам-блоггерам по цеху, и, конечно, уважаемым читателям. Спасибо!

P.S. Надеюсь и дальше продолжать радовать Вас новыми постами.

Механизм настройки прав в VMware vCenter

Небольшая заметка о том, каким образом VMware vCenter Server хранит разрешения на управление виртуальной инфраструктурой.

Все разрешения хранятся в виде записей в таблице dbo.VPX_ACCESS в базе Microsoft SQL Server'а.

Всего в таблице пять столбцов:

ID - уникальный идентификатор.
PRINCIPAL - имя учетной записи пользователя или группы для которых назначаются права. Задаются в формате <ИМЯ_ЗАПИСИ> или <ДОМЕН\ИМЯ_ЗАПИСИ>.
ROLE_ID - идентификатор роли, содержащий необходимые права.
ENTITY_ID - идентификатор объекта, на который назначаются разрешения.
FLAG - переключатель хранит информацию о наследовании и типе учетной записи (пользователь, группа). Может принимать одно из четырех значений:

• 0 - учетная запись - пользователь, права не наследуются (no propagate);
• 1 - учетная запись - пользователь, права наследуются (propagate);
• 2 - учетная запись - группа, права не наследуются (no propagate);
• 3 - учетная запись - группа, права наследуются (propagate).

Для каждой роли при создании задается свой уникальный ROLE_ID. В vCenter все роли подразделяются на два типа: системные (System roles) и пользовательские (User roles).

Системные роли существуют в vCenter изначально и не могут быть изменены или удалены. К системным относятся следующие роли:
Administrator - идентификатор роли (ROLE_ID): -1;
Read Only - идентификатор роли: -2;
No Access - идентификатор роли: -5.

Пользовательские роли могут быть созданы, отредактированы и удалены администратором vCenter. В vCenter после установки также присутствует несколько предустановленных (sample) пользовательских ролей:
Virtual machine power user (sample) - идентификатор роли (ROLE_ID): 4;
Virtual machine user (sample) - идентификатор роли: 5;
Resource pool administrator (sample) - идентификатор роли: 6;
VMware Consolidated Backup user (sample) - идентификатор роли: 7;
Datastore consumer (sample) - идентификатор роли: 8;
Network consumer (sample) - идентификатор роли: 9.

Все пользовательские роли хранятся в каталоге "DC=virtualcenter,DC=vmware,DC=int".
Для определения нужного ROLE_ID достаточно подключиться к каталогу (например, с помощью утилиты ADSIEdit) и в подразделении UserRoles найти требуемую группу.

Наконец, значения ENTITY_ID для всех объектов виртуальной инфраструктуры хранятся в таблице dbo.VPX_ENTITY, поле ID.

Таким образом, если вы по ошибке удалили права для всех администраторов в vCenter, то можете сравнительно легко восстановить полный доступ, добавив соответствующую запись в таблицу. Однако, верно и обратное - любой администратор SQL сервера, где размещается база vCenter, может получить полный доступ к вашей виртуальной инфраструктуре.

Выдача SSL сертификата для vShield Manager

Недавно у меня появилась необходимость заменить самоподписанный сертификат для VMware vShield Manager на заверенный нашим УЦ, однако в процессе выполнения данной операции пришлось столкнуться с небольшой проблемой, о которой и хотелось бы рассказать.

Сама процедура крайне проста, первоначально требуется создать .CSR запрос из интерфейса vShield Manager, заполнив необходимые поля, после чего на его основе выпустить с помощью УЦ сертификат и импортировать его в vShield Manager.

Поскольку все клиенты vSphere Client подключаются к vShield Manager'у по IP-адресу, то при создании запроса в поле Common Name следует указывать IP-адрес. В руководстве vShield Administration Guide дословно написано так:

Enter the name that matches the site name. For example, if the IP address of vShield
Manager management interface is 192.168.1.10, enter 192.168.1.10.

Проблема заключается в том, что при использовании IP-адреса в качестве Common Name, vShield Manager выводит предупреждение "Please enter correct domain name as common name".

Более того - не получится задать hostname (NetBIOS) имя сервера, или DNS имя с доменами первого уровня вроде .local или .internal.

Усугубить ситуацию может попытка разобраться в происходящем в 2 часа ночи.

Если заглянуть в исходный код страницы, то можно обнаружить следующее. За проверку Common Name отвечает javascripts функция checkDomain(), в которой жестко прописаны, какие домены первого уровня допустимо использовать в имени сервера. Соответственно, написать IP-адрес никак не получится.

Конечно, можно выписать сертификат на одно из допустимых DNS имен (надеюсь, у вас сервер не в зоне .рф находится?), а при первом подключении добавить сертификат в доверенные, но можно применить небольшой workaround.

Откройте страницу запроса сертификата https:///CertificateSummary.do?operation=showCertSummary и замените код функции checkDomain() на:

function checkDomain(nname){
return true;
}

Для этого можно использовать, например, отладчик, встроенный в браузер Opera.

После этого, запрос успешно создастся, и сертификат может быть заверен вашим УЦ.

Еще один момент связан с самой процедурой добавления. Перед тем, как добавлять подписанный сертификат, вам потребуется импортировать корневой и все промежуточные сертификаты УЦ в цепочке, в противном случае вы получите сообщение об ошибке.

После добавления сертификата вам потребуется перезагрузить vShield Manager. Сертификат успешно установлен.

VMware High Availability и проверка изоляции

Одной из функций высокодоступного кластера VMware является механизм проверки изоляции, который запускается, если сервер в течение некоторого времени (по умолчанию 12 секунд) не получает heartbeat сигналов от других членов кластера.

Изоляция возникает из-за ошибок конфигурирования оборудования или сбоя в работе сегмента сети, и может повлечь недоступность виртуальных машин.

Для определения изоляции узел посылает echo-запрос на специальные IP-адреса (isolation address).

Если на запросы никто не ответил, узел считает себя изолированным от остальной сети и завершает работу всех ВМ, с тем, чтобы остальные работающие узлы кластера могли их запустить.

По умолчанию в качестве адреса для проверки изоляции используется маршрутизатор по умолчанию.

Использование маршрутизатора по умолчанию в качестве адреса для проверки изоляции является хорошей идеей, поскольку в крупных инфраструктурах управляющие интерфейсы серверов ESXi, как правило, вынесены в отдельную сеть. В этом случае, "ближайшим" адресом, который можно использовать для проверки, является адрес маршрутизатора.

С другой стороны, использование маршрутизатора по умолчанию в качестве адреса для проверки изоляции не является хорошей идеей, поскольку в небольших компаниях в качестве маршрутизатора может использоваться, например, ISA Server, развернутый в виртуальной машине. Это может привести к ситуации, когда сервер ESXi будет успешно пересылать пакеты любой из запущенных на нем ВМ (в пределах одного виртуального коммутатора), хотя в действительности окажется изолированным от физической сети.

Наконец, в ряде случаев, возможно и ложное срабатывание, когда все узлы кластера, подключенные к одному коммутатору, из-за кратковременной недоступности сети посчитают себя изолированными и остановят свои виртуальные машины.

Для предотвращения этой ситуации следует, во-первых, дублировать сетевое оборудование, во вторых, добавить проверку дополнительных адресов, прописав в Advanced Options настройках HA кластера параметры das.isolationaddress и/или das.isolationaddress{n}.

Первый параметр позволяет задать один дополнительный адрес для проверки изоляции, второй, точнее остальные - до десяти дополнительных адресов (в различных документах описывается, что параметры должны иметь значение das.isolationaddress1, das.isolationaddress2, ... das.isolationaddress10, хотя на практике мне удавалось задать и das.isolationaddress0; номер в названии параметра влияет на очередность при проверке).

Теоретически, у вас может быть до 11 дополнительных адресов для проверки изоляции. Только это вовсе не означает, что вам нужно задавать их все, поскольку проверка узлом каждого дополнительного адреса занимает 1 секунду, следовательно, реакция узла на изоляцию последует позже, что в свою очередь увеличит время, необходимое на перезапуск ВМ на других узлах.

Также для предотвращения ложного срабатывания можно задать параметр das.failuredetectiontime (по умолчанию используется значение 15000 миллисекунд), влияющий на время, в течение которого узлы будут пытаться отправлять друг-другу heartbeat'ы, до того как начать проверку на изоляцию.

Важно отметить, что использование параметров das.isolationaddress не отменяет маршрутизатор по умолчанию в качестве адреса для проверки изоляции. Чтобы не использовать маршрутизатор для проверки вам потребуется добавить параметр "das.usedefaultisolationaddress = false".

Учтите, что для изменения настроек уже существующего кластера, то вам потребуется отключить, а затем снова включить HA кластер, что приведет к повторной установке HA агентов на всех узлах.

Для проверки изоляции не обязательно использовать адреса в той же подсети, в которой расположены VMKernel интерфейсы, однако это будет крайне разумным решением. И вот почему.

Если для хранения виртуальных машин вы используете iSCSI или NFS хранилище, то в качестве адреса для проверки изоляции рекомендуется указывать один из интерфейсов хранилища. Это позволит избежать ситуации, когда из-за сетевой изоляции у ВМ пропадает доступ к виртуальным дискам, и сервер виртуализации держит их включенными, вместо того, чтобы остановить.

Однако с этим решением связан один важный момент. При добавлении узла в кластер требуется, чтобы все указанные адреса для проверки изоляции были доступны. Если хотя бы один из адресов недоступен, вы получите сообщение об ошибке: "Could not reach isolation address".

Проблема заключается в том, что echo-запрос отправляется с любого "ближайшего" VMKernel интерфейса (например, с интерфейса из той же подсети, где находится адрес для проверки изоляции), а не с того, который настроен для передачи управляющего трафика (Management traffic).

Наглядно эту ситуацию демонстрирует следующая картинка.

В данном примере IP адрес 10.0.0.4 соответствует VMKernel интерфейсу, на котором включен management traffic, а 10.0.1.4 - интерфейсу VMKernel, который используется только для передачи iSCSI трафика (адрес 10.0.0.254 соответствует маршрутизатору по умолчанию, 10.0.1.1 - хранилищу iSCSI). В момент проверки узла на изоляцию наблюдается следующее.

VMKernel пытается отправить echo-запрос на адрес 10.0.1.1 уже не с адреса 10.0.1.4, как делал это при создании кластера, а с 10.0.0.4. И если у вас не настроена маршрутизация между подсетями, то смысл в дополнительном адресе для проверки изоляции теряется.

Один последний момент, который я хотел рассмотреть - обеспечение избыточности для управляющих интерфейсов (Management Network) серверов ESXi. Управляющие интерфейсы используются узлами HA кластера для отправки heartbeat пакетов, согласования изменений в конфигурации и проверки изоляции.

По умолчанию, если вы создаете HA кластер, используя всего один управляющий интерфейс и один сетевой адаптер, то увидите следующее предупреждение.

Избыточность для управляющего трафика может достигаться двумя способами:

• Подключение дополнительных сетевых адаптеров к управляющему интерфейсу.
• Создание дополнительных VMKernel интерфейсов и назначение на них функции передачи управляющего трафика (Management traffic).

С первым вариантом все просто - добавили в vSwitch второй (третий, четвертый...) адаптер и переопределили на уровне VMKernel порядок их использования (рекомендуется настроить один из адаптеров как Active, остальные - Standby).

Данный вариант обеспечит защиту от сбоев оборудования: сгоревшего порта, сетевой карты, коммутатора (если они дублированы) или отключенного кабеля, однако не поможет в случае ошибок в конфигурации VLAN'ов, неправильным назначением сетевых настроек, ARP или IP spoofing'е и т.п.

Создание дополнительных управляющих VMKernel интерфейсов в отдельных VLAN'ах, а еще лучше - подключенных через отдельные сетевые адаптеры, повысит доступность, но в то же время приведет к усложнению конфигурации кластера и потребует дополнительных настроек на сетевом оборудовании.

Все.

Опыт проектов виртуализации

Решил поделиться с читателями неким обобщенным опытом, касаемо проектов виртуализации (и не только), снабдив их небольшими байками по теме. Заранее хочу подчеркнуть, что все истории выдуманы, и любое совпадение с реальными персонажами и ситуациями из жизни - чистая случайность.

1) Выбирайте оборудование и ПО, исходя из ваших потребностей.

Часто можно столкнуться с такими перегибами. Клиент покупает полную корзину блейд-серверов с двумя управляющими модулями, ethernet и FC коммутаторами для отказоустойчивости, но при этом "забывает" купить несколько FC кабелей, или же банально не хватает PDU с какими-нибудь розетками типа IEC320 C19 для подключения всех блоков питания, а после подключения, оказывается, что ИБП не тянут.

Или же клиент берет три четырехсокетных сервера, покупает по 4-ре лицензии vSphere Enterprise Plus и Windows Server Datacenter на каждый сервер, хотя никакой функционал Enterprise Plus использовать не планирует, да и виртуальных машин у него всего ~10 на весь кластер. А иногда, бывает, и по одной ВМ на сервер хочет оставить, чтобы "надежнее" и "производительнее".

2) "У нас мало денег, возможно, мы даже не сможем вам заплатить."

Это противоположная крайность (я о ней писал). У инженеров будет прекрасная возможность научиться работать с консолью Windows Server Core, а также научиться подключаться MMC оснасткой Hyper-V Manager с недоменных компьютеров.

Еще пример: раньше у заказчика были 2 сервера с 6-тью 18 ГБ SCSI жесткими дисками, а теперь стал один с 4-мя ВМ на нескольких 1 ТБ SATA дисках. Все работает и не тормозит... почти.

3) Смотреть HCL нужно до покупки оборудования.

Об этом случае я тоже рассказывал. Клиент купил FC библиотеку, надо бы подключить к серверу резервного копирования. А он, оказывается, в ВМ на VMware.

4) Не все, что работает - поддерживается, не все, что поддерживается - работает.

У заказчика на виртуальном сервере один из разделов зашифрован с помощью Secret Disk. Для работы данного ПО требуется USB ключ защиты Aladdin, который предусмотрительно "проброшен" в ВМ с помощью соответствующей функции (даже галочка для поддержки работы с vMotion стоит). Требуется перенести диски ВМ с одного хранилища на другое без простоя. Нам поможет Storage vMotion. Алле-оп! USB ключ после переноса остается, Secret Disk отваливается из-за его отсутствия.

5) Это не баг, это фича/by design.

Например, совсем недавно столкнулся с особенностями работы блейд-коммутаторов Brocade, которые после собственной перезагрузки не отображают WWN HBA серверов, на которых установлен VMware ESXi. И чтобы это исправить, нужно сами серверы перезагрузить.

6) Середина проекта - отличный способ начать всё сначала.

Проект по внедрению виртуализации на базе Microsoft Hyper-V. Все машины развернуты, AD поднята, Exchange установлен, почтовые ящики смигрированы, файловые папки перетащены. В какой-то момент выясняется, что Failover Cluster просто не отрабатывает (это не камень в огород Microsoft, просто так было). Недолгая переписка с поддержкой результатов не дала, а сроки и так были сорваны. Волевое решение - переход на VMware ESX. Два выходных дня и все виртуальные машины сконвертированы. А дизайн-проект и прочую документацию всегда можно переписать.

7) Нет ничего более постоянного, чем временное.

Предположим, вы с коллегой монтируете сервер и подключаете его разными кабелями:

(Вы): -Давай прикрутим этот прекрасный HP Cable Management Arm?
(Он): -Ой, так ломает, тут такая путаница в проводах, давай, я чуть попозже прикручу.
(прошло 2 месяца...)

Поэтому, например, чем дольше идет проект, тем меньше шансов обновить firmware для СХД или для одного из серверов.

8) Бумажка с паролями.

Мало у кого из клиентов инфраструктура подробно документирована. Часто он и сам не знает, что-какой сервер делает, особенно если предыдущий администратор уволился и толком дела никому не передал.

Нередки случаи, когда "базы у нас хранятся вот на этой СХД, но пароля от нее я не помню".

Или, например, клиент отказывается от покупки почтового антивируса, мотивируя тем, что у него уже есть необходимые лицензии. Проект начинается, и оказывается, что лицензии на антивирус есть, но только на файловый антивирус на клиентские компьютеры.

9) Приёмо-сдаточные испытания - прекрасный способ еще раз "обработать напильником".

Наверняка все так или иначе с этим сталкивались. Заказчик принимает систему, инженер исполнителя проверяет чек-лист, выполняя заранее описанные действия, и демонстрируя ожидаемый результат, вроде: "Проверить журнал событий и убедиться в отсутствии ошибок... Так, проверяем... ошибок не... есть." Дальше следует разбор полетов с судорожной попыткой инженера если уж не решить проблему, то придумать правдивую отмазку. Самый тяжелый случай был, когда в результате запуска и проверки работы одного из бизнес-приложений, описанного в требованиях в ТЗ, сервер просто уходил в перезагрузку... на глазах у заказчика.

10) Законы Мёрфи работают.

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

Купил один клиент MSA 2000i с двумя контроллерами, каждый к своему коммутатору подключен, оба блока питания запитаны от двух разных ИБП. Отдельный диск под hot spare. Сломалась эта MSA. Просто так.