Механизм настройки прав в 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. Просто так.

Что хранится в базе VMware Guided Consolidation?

Многим из вас должно быть известно, что у VMware существует продукт, предназначенный для малого и среднего бизнеса, который позволяет автоматизировать процесс планирования, анализа и миграции физических серверов в виртуальную среду - VMware Guided Consolidation.


В различных книгах и руководствах по vSphere написано, что Guided Consolidation собирает и хранит большое количество параметров и счетчиков производительности серверов, однако, непосредственно из консоли vSphere Client администраторам доступно не так уж много информации.

Вдобавок, Guided Consolidation не имеет встроенных средств для формирования отчетов в отличии от того же Microsoft Assessment & Planning Toolkit.

Так что же именно собирает и хранит Guided Consolidation?

Для хранения базы Guided Consolidation использует формат Firebird. Сам файл с данными Collector.FDB размещается в папке '%programfiles%\VMware\Infrastructure\Guided Consolidation Server\Data'.

Для препарирования базы вы можете использовать Firebird ISQL Tool, который можно загрузить в составе дистрибутива с сайта разработчиков Firebird. Однако гораздо удобнее использовать для этих целей какой-нибудь сторонний инструментарий вроде RazorSQL.

Для подключения к файлу базы с помощью Firebird ISQL Tool используется следующая команда (перед подключением не забудьте скопировать базу во временную папку):
CONNECT <ПУТЬ_К_БАЗЕ> user "SYSDBA" password "masterkey";

Все данные, собираемые Guided Consolidation, хранятся в нескольких десятках таблиц.

Например, из таблицы PERF_HOUR_SUMMARY видно, что Guided Consolidation каждый час сохраняет в базе максимальное и минимально значение счетчиков загрузки процессора (в %) и свободной памяти (в байтах) для всех обследуемых серверов.

Кроме того, в базе хранятся и другие параметры (модель и частота процессора, объем оперативной памяти, свободное место на дисках и т.д.), которые можно найти в соответствующих таблицах "DESС_" или "INV_".

Остается неясным, насколько все эти данные важны при составлении Guided Consolidation рейтинга оптимальных хостов для размещения конвертированных ВМ. Возможно, что это просто 'хвосты', оставленные от старшего брата - Capacity Planner.

Новая книга по виртуализации

Вслед за Михаилом Михеевым (автором блога vm4.ru) я решил написать собственную книгу по технологиям виртуализации и облачным вычислениям: "По дороге с облаками: том 1".

Книга рассчитана на начинающих специалистов, однако будет интересна и опытным администраторам и архитекторам заоблачных ЦОДов.

Специально для читателей данного блога я решил опубликовать краткую аннотацию к книге.

Книга содержит высококачественные иллюстрации и детальные схемы компонентов виртуальной инфраструктуры.

Подробно описан весь цикл проектирования инфраструктуры - от первоначальной идеи - до конечного воплощения.

Особое внимание уделяется вопросам разработки дизайна, взаимодействия с заказчиками и командной работе.

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

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

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

Помимо печатного варианта, планируется издавать цифровой, который можно будет приобрести в магазинах Amazon и Apple AppStore, а также загрузить в составе дистрибутива облачной операционной системы VMware vSphere 5.0.

Выход книги намечен на 1 апреля 2012 года.

Видео: Установка и настройка Citrix Access Gateway VPX 5 (часть II)

Продолжение видео об установке и настройке Citrix Access Gateway.

Часть 2: Настройка Access Gateway:

Части 3 и 4: настройка сертификатов и проверка работы Access Gateway: