Кластерный vCenter

VMware опубликовала официальный гайд по кластеризации vCenter средствами MSCS.

Одним словом: Wow!

До недавнего времени альтернативой был пожалуй только vCenter HeartBeat за 16 килобаксов.

Upd: извините, за 10 килобаксов по прайсу. 12 - vCenter Heartbeat с 1 годом золотой поддержки, 16 - с 3 платиновой.

Проблемы с большими VMDK в 3.5

На форуме поделились информацией:

В 3.5u4 вы не можете увеличить VMDK диск, если он больше терабайта размером, через VI Client. Придется пользоваться командной строкой и vmkfstools.
VMware официально признала это багом, ждем исправления.

MSCS на vSphere

Изменились ли правила для установки Microsoft кластеров на vSphere? Ответ: слегка.

Есть три сценария работы MSCS и ESX: Cluster-in-a-box (оба узла MSCS работают на одном физическом сервере - удобно для тестирования), cross-host (узлы MSCS находятся на разных физических серверах) и physical-virtual (когда один узел MSCS физический, а второй виртуальный).

• MSCS все еще ограничены двумя узлами при работе на ESX 4.
• Можно использовать локальные диски (для cluster-in-a-box) или Fibre Channel для двух других вариантов. Поддержка NFS и iSCSI пока отсутствует.
• При работе в cross-host варианте оба ESX хоста должны иметь одинаковые версии.
• Узлы MSCS не могут находиться в кластерах HA или DRS.
• Нельзя использовать MSCS одновременно с FT. точнее сказать, FT машины могут работать на тех же физических хостах, но узлы MSCS не могут быть запущены как FT машины.
• Нельзя перемещать узлы MSCS при помощи VMotion.
• Нельзя использовать N-Port ID Virtualization (NPIV).
• При использовании Fibre Channel и родного multipathing в ESX нельзя использовать round-robin политику путей.
• Использовование VM hadware 7 для ESX/ESXi 4.0 обязательно.
• Failover кластеры Windows 2008 не поддерживаются с virtual RDM, обязательно использование physical RDM.
• Нельзя использовать тонкие vmdk диски для Windows.
• Для Windows 2000 / 2003 необходимо использовать LSI Logic Parallel как контроллер Для общего хранилища, для Windows 2008 - LSI Logic SAS.
• Для physical-virtual MSCS кластеров необходимо использование physical RDM.
• Нельзя использовать multipathing ПО в ВМ или на ESX (как например PowerPath VE).
• Нельзя использовать Memory Overcommit для узлов MSCS, требуется полностью резервировать память для MSCS ВМ.
• Необходимо выставить значение disk I/O timeout в 60 секунд или более (HKLM\System\CurrentControlSet\Services\Disk\TimeOutValue)

Оригинал: Dave Lawrence (VMware)

Лицензирование Windows под Parallels

Иногда встречаются утверждения от любителей продуктов Parallels, что в случае контейнеров Virtuozzo не требуется платить многократно за Windows, поскольку реально используется всего один экземпляр ОС.

Андрей Бешков (Microsoft) прокомментировал данное утверждение таким образом: "С точки зрения Product Usage Rigths нет никакой разницы, контейнер это или отдельная виртуальная машина. Каждый контейнер имеет в себе ЭКЗЕМПЛЯР ОС. Лицензируется количество одновременно-запущенных экземпляров. Поэтому никакой экономии лицензий Windows продукт Parallels в сравнении с Hyper-V или vSphere или Xen не дает."

Господа любители Parallels, не делайте больше, пожалуйста, такой "рекламы" для любимого вендора.

Роли, которые мы выбираем…

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

Используй то, что под рукой и не ищи себе другое.

Если в вашей компании только один администратор, то дальше можете не читать, доверьтесь администратору и спите спокойно (или наоборот беспокойно), ведь он как ходил везде, имея отмычку от всех дверей, так и будет это делать дальше. И плевать ему, что на столе лежит многопудовая связка новеньких ключиков с бирками. А вот если у вас, к примеру, чертова куча серверов и целая толпа унылого вида красноглазых админов всех мастей и размеров? Что делать тогда? А вот тогда – читать дальше.

Помните одиозного помощника лорда Мейса? - «Есть ли у вас план, мистер Фикс? — Есть ли у меня план? Есть ли у меня план? Да у меня целых три плана!». В сущности, он был совершенно прав, имея целых три плана.
А сколько нужно нам для понимания масштабов бедствия и разработки возможных вариантов спасения утопающих, используя силы этих самых утопающих? Все те же 3 плана, точнее итерации:

1. Составьте для себя перечень повседневных задач, которые придется решать. Составьте его тщательно, продуманно, взвешенно. Но я ручаюсь, вы все равно что-нибудь да забудете. Впрочем, к этой работе можно будет вернуться еше раз, на второй итерации.
2. Чтобы выполнить все то, что вы описали ранее – а что КОНКРЕТНО надо делать? Вот так и распишите все как Петька оперу - про ВСЕХ И ОЧЕНЬ ПОДРОБНО.
3. Когда с первыми этапами покончено - задумайтесь, а КТО и ГДЕ все это будет делать? Это самый важный и сложный момент во всем вашем безумном предприятии.

Что получилось в итоге? А в итоге мы получили три важных компонента управления доступа – перечень ролей, перечень конкретных привилегий для каждой роли и, о чудо, МАТРИЦУ ДОСТУПА к информации – мечту любого безопасника от мала до велика.

Три ореха это уже куча или еще не куча?

Никогда не используйте встроенные роли кроме системных, таких как в VI, так в vSphere всего 3 - No Access (по умолчанию для всех пользователей кому в явном виде не прописан доступ), Read Only (роль содержит привилегии на просмотр детальной информации на уровне объекта иерархии), Administrator (роль содержит все привилегии на уровне объекта иерархии).

Эти роли не подлежат удалению или изменению, так как для инфраструктуры это может окончиться плачевно.

Обязательно продумайте, какие функции будут выполнять люди, не создавайте 1 роли которая может все. Очень сомнительна роль «все включено», вы же не вытираете со стола и не моете пол одной и той же тряпкой.

Несколько слов о роли Administrator. Обычно эта роль назначается администраторам виртуальной инфраструктуры. Таких администраторов, скорее всего, будет несколько и каждый из них будет отвечать только за определенный участок работы, а, следовательно, каждый будет иметь полномочия, которые не соответствуют его функциональным задачам (контроль над всеми серверами ESX и возможность назначения полномочий). Хорошим решением в данном случае было бы создание 2 персонифицированных аккаунтов с ролью Administrator (основной и резервный) что называется на исключительный случай, а для повседневной работы создание специальных ролей для каждого администратора с минимально необходимыми привилегиями согласно функциональным задачам.

Так же в списке ролей существующих по умолчанию есть еще роли, созданные для ознакомления, как примеры и не более того (в терминах компании VMware).
VI3:

1. Resource Pool Administrator
2. Virtual Machine Power User
3. Virtual Machine User
4. VMware Consolidated Backup User
5. Virtual Machine Administrator
6. Datacenter Administrator

vSphere:

1. Resource Pool Administrator
2. Virtual Machine Power User
3. Virtual MachineUser
4. VMware Consolidated Backup User
5. Datastore Consumer
6. Network Consumer

Несколько слов о роли VMware Consolidated Backup User. Согласно технической документации компании VMware изменение или удаление это роли не допускается.

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

Рассмотрим на примере.
Роль Virtual Machine User (обычно назначается всем рядовым пользователям) обладает 15 полномочиями, среди которых – Global – CancelTask, VirtualMachine – ConsoleInteract, VirtualMachine – SetCDMedia, ScheduledTask – Create, ScheduledTask – Run. Вы уверены в том, что эти полномочия необходимы для работы? Это как в театре, если на сцене в первом акте висит ружьё, то в третьем оно непременно выстрелит.

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

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

«Разделяй и властвуй» Николо Макиавелли

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

Ролевой механизм насчитывает порядка 110 доступных привилегий.

Не забывайте о том, что роль, назначенная индивидуальному пользователю для данного объекта, будет иметь приоритет над привилегиями, назначенными групповой ролью; а при наличии нескольких ролей на объект пользователю будут суммированы все привилегии назначенных ролей.

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

Возникает вопрос, а что делать с ролями, существующими по умолчанию для ознакомления? Здесь 2 варианта: либо удалять, либо вносить изменения в эти роли. Выбор решения в каждом конкретном случае будет зависеть от того, насколько полно производится документирование всех изменений вносимых в конфигурацию. Если действия при внесении изменений в разрешения роли, удалении роли или создании новой роли фиксируются в соответствующей документации, то у вас будет возможность следить за матрицей ролей и целесообразностью предоставляемых полномочий администраторам и пользователям. В противном случае, запутавшись в собственных разрешениях и запретах, можно остаться и без доступа к инфраструктуре.

Осенняя встреча VMware User Group Russia

Хочу объявить, что мы начинаем подготовку к осенней встрече пользователей VMware.
Ориентировочное время и место: Москва, конец сентября-начало октября.

На какие темы вы хотели бы услышать доклады? Или, может быть, прочитать :)
Представители вендоров с техническими докладами также будут желанными гостями.

10 причин ненавидеть vSphere

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

2. Поставщики железа больше не приглашают меня на обед, ведь я стал покупать меньше оборудования.

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

4. Мне постоянно приходится доказывать, что бизнес-приложения будут работать так же хорошо, как и на выделенных серверах.

5. Я стал добавлять приставку 'v' к каждому техническому термину в разговоре.

6. После внедрения VDI я стал редко навещать пользователей.

7. Мой почтовый ящик завален письмами от экофанатов, ведь у нас теперь "зеленый датацентр".

8. Меня замучали звонками компании, пытающиеся продать мне продукты для vSphere (восстановление данных).

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

10. Не могу купить новую Fibre Channel СХД, потому что iSCSI в vSphere работает просто замечательно.

Оригинал.