понедельник, 27 июля 2009 г.

[VMware VI Wiki] Обновлено: Security

Пользователь Михаил Михеев обновил страницу Security. Изменения указаны ниже.

Цветовой ключ: Вставка | Удаление

Перейти на страницу: Security


-------------
Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
Не хотите получать уведомления о собственных изменениях? Измените настройки.

[VMware VI Wiki] Документ приложен к x-files

Пользователь Михаил Михеев приложил к странице x-files файл с именем Xtravirt_VI3_Security_Assessment.doc.

Перейти на страницу: x-files

-------------
Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
Не хотите получать уведомления о собственных изменениях? Измените настройки.

пятница, 24 июля 2009 г.

[VMware VI Wiki] Обновлено: VMware HA

Пользователь Михаил Михеев обновил страницу VMware HA. Изменения указаны ниже.

Цветовой ключ: Вставка | Удаление

Что надо знать про VMware HA Cluster.

Во первых, что он умеет - сводить к минимуму время простоя ВМ, в случае падения хоста. Есть несколько хостов, включенных в HA кластер, есть ВМ на них. Падает какой то хост - ВМ на нем умирают. Но сразу же включаются на других хостах кластера.



Для него необходим VC и соответствующие лицензии. В консоли VC создаем кластер(напомню, что в контексте VMware "кластер" - просто группа хостов). Создали кластер, перетащили туда хотя бы 2(max 32) хостов. В свойствах кластера поставили галочку "HA".
Теперь на хостах начнется конфигурирование HA агента. Чтобы это конфигурирование закончилось успешно, должны быть выполнены следующие условия:
  1. Интерфейсы SC должны находиться в одной подсети, т.е. из консоли каждого ESX вы должны пинговать все другие.
  2. Должно быть настроено разрешение имен - т.е. должны ходить пинги и по именам. Для этого используем DNS, или добавляем в /etc/hosts соответствующие записи . Для ESX 3.5 начиная с Update 2 не критично - ибо начиная с этой версии имена разрешаются в IP за счет информации, предоставляемой Virtual Center.
  3. Названия групп портов для ВМ должны называться одинаково на всех хостах кластера. Т.е. вот ВМ1 работает на хосте "ESX1", и ее виртуальный сетевой контроллер смотрит в группу портов "VM_network". Вот на ESX2 должна быть группа портов для ВМ с тем же названием. И, само собой, через нее должна быть доступна та же физическая сеть, что и на ESX1.
  4. Само собой, те ВМ, которые мы хотим защитить с помощью HA, должны лежать на общем(shared) LUN на внешней СХД. Т.е. чтобы с каждого хоста в кластере все файлы этих ВМ были видны.
Как работает HA кластер:
когда мы перетаскивам хосты в кластер в консоли VC, то VC настраивает HA агенты на этих хостах. Будучи настроенными, агенты не требуют(!) VC для своей работы. Т.е. VC может находиться даже на виртуалке, и даже если эта виртуалка сдохнет вместе со сдохшим хостом - HA все равно отработает, и поднимет эту ВМ на другом хосте. Достигается это тем, что HA агенты на хостах образуют между собой децентрализованную систему, управляемую самими агентами.

Агенты друг друга пингуют. Для какого то хоста пропажа пингов означает одно из двух - или умер неотзывающийся хост, или умерла сеть для этого хоста. Второй случай называется изоляцией, и должен обрабатываться особым образом:
Вот у нас 3 хоста. У одного становиться недоступен интерфейс SC(напр. выгорает порт на коммутаторе). Остальные думают что он умер(т.к. пинги к нему не ходят) и пытаются запустить те ВМ, которые работали на нем. Это не создаст проблемы, т.к. файлы этих ВМ заблокированны как открытые. Но если выход из строя этого порта коммутатора отрезал от сети ВМ этого хоста - то от того, что они работают, нам не легче.

Поэтому каждый хост умеет проверять, не изолирован ли он. Делается это пингованием IP, по умолчанию это шлюз SC. Или произвольный. Или два произвольных - подробнее про это я писал тут. Предпологается, что эти IP будут отзываться 24\7.

Итак, хост перестал получать отклики от проверочного IP и понял, что оказался изолирован. Мы в настройках можем указать - что делать с каждой ВМ в случае изоляции - выключать или оставлять. Изолированный ESX выключает свои ВМ, они поднимаются на других хостах кластера. Или не выключает и не поднимаются - это как настроим.

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

Что еще мы можем настроить:
Number of hosts failures allowed - смерть какого кол-ва хостов должен пережить наш кластер. Чем большая тут цифирка - тем больше ресурсов резервируется на случай сбоя. Например - у нас 6 хостов, на каждом по 10 ВМ. Если хотим защититься от сбоя одновременно 2 хостов - значит на любых 4х надо мочь запустить все 60 ВМ. Если хотим защититься от падения одновременно 3х - значит на любых 3 надо мочь запустить все 60. "Смочь" - имеется в виду ,что ресурсов должно хватить.
Admissions control - можно ли запускать ВМ, если ее запуск потребует использования заначки ресурсов из предыдущей настройки.

Рекомендации - HA best practices.


Advanced Options.

Многие настройки HA не вынесены в галочки и выпадающие меню. Они вводятся в табличку, доступную по кнопке "Advanced Options" в настройках HA кластера, в виде "имя опции"  "значение".

Возможные опции:

  • das.failuredetectiontime - количество миллисекунд. Таймаут перед срабатыванием "isolation response". Значение по умолчанию 15000 миллисекунд.
  • das.isolationaddress[x] - IP адрес. Этот(эти) IP адреса используются ESX для проверки на событие изоляции. [x] = 1‐10. По умолчанию используется шлюз Service Console. Эти IP'шники должны отвечать на пинги 24\7.
  • das.poweroffonisolation - Значение False или True. Это - настройка действия по умолчанию в случае изоляции.
  • das.vmMemoryMinMB - Чем выше значение, тем больше памяти будет резервироваться на случай сбоя.
  • das.vmCpuMinMHz - Чем выше значение, тем больше ресурсов CPU будет резервироваться на случай сбоя.
  • das.defaultfailoverhost - значение - имя хоста. Этот хост будет использоваться как предпочитаемый в случае сбоя.
  • das.failuredetectioninterval - количество миллисекунд. Для изменения интервала проверочных пингов между хостами (heartbeat). По умолчанию - каждую секунду (1000 миллимекунд).
  • das.allowVmotionNetworks - Allows a NIC that is used for VMotion networks to be
    considered for VMware HA usage. This permits a host to have only one NIC configured for management and VMotion combined.
    Если через сетевушку идет трафик Vmotion, то HA не использует ее для своих пингов. Этот параметр разрешает ему это делать.  Подробности и варианты, когда опция пригодится см. в VMware HA Implementation Notes ниже.
  • das.allowNetwork[x] - имя интерфейса Service Console, а точнее - ее portgroup. Например - ʺService Console 2ʺ. [x] = 1‐? .
    Если у нас несколько интерфейсов SC, указываем в каком порядке использовать их под heartbeat'ы HA.
  • das.isolationShutdownTimeout - таймаут перед выключением ВМ в случае изоляции, если выбрана опция "Shutdown VM". По умолчанию - 300 секунд. Другими словами, если ВМ корректно не завершили работу в случае изоляции, то через 300 секнуд они будут выключены насильно.
  • das.ignoreRedundantNetWarning - если true, то вас не будет доставать сообщение "Host <xxx> currently has no management network redundancy."
  • das.bypassNetCompatCheck - если true, то при активации HA не будут проверятся некоторые условия. Актуально при сообщении об ошибке: " Cannot complete the configuration of the HA agent on the host. See the task details for additional information. Misconfiguration in the host network setup."

Опции из непроверенных источников, пока, к сожалению, без описания:

  • das.trace = ON|OFF
  • das.tracelevel = 0..3|FunctionTracing
  • das.traceoutput = File|EventLog|stdout
  • das.consoleperm = perm_all | perm_oper | perm_user
  • das.consolenode = fqdn
  • das.consoleuser = username
  • das.checkvmstatedelay
  • das.primarycount

Историческая справка - "DAS" - это первый вариант название функции, ныне известной как VMware HA. Отсюда и наличие этих букв в названии опций.

Еще на ту же тему: "Расширенные настройки (advanced settings) кластера VMware HA (High Availability) для отказоустойчивости хостов ESX и виртуальных машин."


Отдельная функция VMware HA, появившаяся после Update 2 - Virtual Machine Failure Monitoring (VMFM).

Работает она следующим образом: система мониторит ежесекундные heartbeat сигналы от VMware tools, и по факту их пропажи перезагружает ВМ.
Таким образом, для включения этой функции нам надо:
ESX 3.5
VC 2.5
HA кластер
Установленные VMware tools

Чтобы включить VMFM, идем в расширенные настройки HA кластера, и указываем следующие опции:
  • das.vmFailoverEnabled – true (true или false)
  • das.FailureInterval – 30 (ВМ считается зависшей, если от нее не было heartbeat в течении этого кол-ва секунд)
  • das.minUptime – 120 (После включения ВМ нужно какое то время - для загрузки ОС, VMware tools и стабилизации heartbeat'ов. Вот тут мы это время и указываем, в секундах.)
  • das.maxFailures - 2 (Максимальное кол-во сбоев и последующих перезагрузок ВМ в течении времени, указанного в опции das.maxFailureWindow. Если das.maxFailureWindow выставленно ‐1 (no window), das.maxFailures представляет абсолютное количество сбоев, после которого VMFM прекращает автоматические перезапуски ВМ.)
  • das.maxFailureWindow выставлен не в -1, и число  – 86400 (Или -1 или значение в секундах. Если число рестартов превысило указанное в опции das.maxFailures, то VMFM прекращает автоматические рестарты.)

Для тестов этой функции можно пользоваться симуляцией BSOD.




Как считаются ресурсы под HA:

http://virtualgeek.typepad.com/virtual_geek/2008/06/so-how-exactly.html


http://virtualgeek.typepad.com/virtual_geek/2008/07/vm-ha---service.html


что то вроде FAQ по работе HA
имеет смысл перевести и добавить сюда
http://www.yellow-bricks.com/2008/09/09/ha-primary-and-secondary-nodes/

Очень правильный документик - VMware HA Implementation Notes - рекомендуется к ознакомлению. Он же приаттачен к этой странице.

Наконец, что пробовать в первую очередь при траблшутинге - статья в KB Troubleshooting Adding an ESX Server Host to a VMware High Availability Cluster.
Если HA кластер не собирается -
  1. проверить, что для каждого хоста задано короткое и FQDN имя. проверить можно командной "hostname"
  2. в имени хоста используются только маленькие буквы.
  3. проверить, что все хосты друг друга пингуют по именам командой "ping <имя другого сервера>".
  4. проверить, что в vCenter хосты добавлены по именам(!). т.е. в vCenter вы видите не IP серера а его имя.
  5. можно попробовать Переустановить агент VMware HA на хосте ESX, когда не получается добавить его в HA-кластер.

еще можно почитать Diagnosing a VMware High Availability cluster configuration failure и Troubleshooting Adding an ESX Server Host to a VMware High Availability Cluster.

Перейти на страницу: VMware HA


-------------
Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
Не хотите получать уведомления о собственных изменениях? Измените настройки.

четверг, 23 июля 2009 г.

[VMware VI Wiki] Обновлено: Security

Пользователь Михаил Михеев обновил страницу Security. Изменения указаны ниже.

Цветовой ключ: Вставка | Удаление

Перейти на страницу: Security


-------------
Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
Не хотите получать уведомления о собственных изменениях? Измените настройки.

[VMware VI Wiki] Обновлено: Security

Пользователь Maria Sidorova обновил страницу Security. Изменения указаны ниже.

Цветовой ключ: Вставка | Удаление

Перейти на страницу: Security


-------------
Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
Не хотите получать уведомления о собственных изменениях? Измените настройки.

[VMware VI Wiki] Обновлено: Security

Пользователь Maria Sidorova обновил страницу Security. Изменения указаны ниже.

Цветовой ключ: Вставка | Удаление

Перейти на страницу: Security


-------------
Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
Не хотите получать уведомления о собственных изменениях? Измените настройки.

[VMware VI Wiki] Обновлено: Security

Пользователь Maria Sidorova обновил страницу Security. Изменения указаны ниже.

Цветовой ключ: Вставка | Удаление

Перейти на страницу: Security


-------------
Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
Не хотите получать уведомления о собственных изменениях? Измените настройки.

[VMware VI Wiki] Обновлено: Security

Пользователь Maria Sidorova обновил страницу Security. Изменения указаны ниже.

Цветовой ключ: Вставка | Удаление

Перейти на страницу: Security


-------------
Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
Не хотите получать уведомления о собственных изменениях? Измените настройки.

[VMware VI Wiki] Документ приложен к x-files

Пользователь Maria Sidorova приложил к странице x-files файл с именем Virtual Networking Feature.pdf.

Перейти на страницу: x-files

-------------
Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
Не хотите получать уведомления о собственных изменениях? Измените настройки.

[VMware VI Wiki] Документ приложен к x-files

Пользователь Maria Sidorova приложил к странице x-files файл с именем Security Configuration Guide Cisco Nexus 1000v.pdf.

Перейти на страницу: x-files

-------------
Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
Не хотите получать уведомления о собственных изменениях? Измените настройки.

суббота, 18 июля 2009 г.

[VMware VI Wiki] Обновлено: Snapshot

Пользователь Михаил Михеев обновил страницу Snapshot. Изменения указаны ниже.

Цветовой ключ: Вставка | Удаление

Роль диска ВМ выполняет пара файлов - <vm-name>.vmdk и <vm-name>-flat.vmdk.
Именно в последнем содержаться те данные, что лежат на диске виртуалки.

Притом, этот файл по умолчанию создается предразмеченным - т.е. под него резервируется все место, которое он может занять. Т.о., если вы создали диск для ВМ и его размер указали в 40 ГБ, все 40 ГБ на VMFS разделе у окажутся занятыми сразу.
(Отступление в сторону - если vmdk создается на NFS разделе, то именно на NFS он сразу создается в формате "thick" - "растущий" по факту, с нулевым начальным размером. Так же, можем в этом формате создавать vmdk и на VMFS - но сейчас только с помощью командной строки, не из GUI. Подробнее тут - Типы дисков(vmdk файлов))

Так вот. Теперь, с ВМ мы можем сделать снапшот. Это - снимок состояния, фиксация текущего состояния этой ВМ, на которое можно вернуться потом.
Технически это означает следующее:
файл <vm-name>-flat.vmdk переводится в режим только чтения.
Создается файл <vm-name>-delta0001.vmdk, и в эту дельту начинают писаться те блоки, которые меняются относительно исходного файла. Т.е. по умолчанию дельта размера 0, а потом начинает расти. Растет она блоками по 16 МБ. Это не очень хорошо, потому что для каждого увеличения генериться SCSI reservation. Один SCSI reservation - это нормально, но если они будут генериться часто - это приведет к снижению производительности дисковой подсистемы.

Если спустя еще какое то время сделать еще один снапшот, то теперь в режим только чтение переводится и <vm-name>-delta0001.vmdk, и появляется файл <vm-name>-delta0002.vmdk. Во вторую дельту начинают писаться те блоки, которые меняются относительно <vm-name>-flat.vmdk+<vm-name>-delta001.vmdk.

Файл <vm-name>-delta000Xvmdk не будет размером больше, чем номинальный размер диска ВМ.
В моем примере это 40 ГБ.

ВАЖНО!
Для функционирования ВМ нужны все vmdk файлы - и основной, -flat.vmdk, и все файлы-дельта. Не уподобляйтесь персонажу отсюда.

На что стоит обратить внимание:

ВМ с диском в 40 ГБ реально на VMFS разделе может занимать до 40*(кол-во снапшотов + 1) гигабайт места. Каждая такая ВМ.
Притом, есть мнение, что в некоторых случаях файлы дельты могут расти достаточно активно при практически нулевой активности с диском ВМ. Ведь даже тогда, когда вы или приложение ничего не меняете на диске виртуалки, там есть файл подкачки, к примеру - который меняется => растет дельта.

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

Удаление снапшота размером в 100ГБ может занимать 3-6 часов.

Расширять диск ВМ имеющей снапшоты - плохая идея. Увеличить размер диска можно командой vmkfstools -X или из GUI(начиная с 3.5 версии ESX). Так вот, скорее всего, ВМ больше не стартует, если расширение диска было произведено при имеющихся снапшотах. Как чинить - Top Support Issues and How to Solve Them - Batch 2.

Если есть желание, чтобы диск ВМ был неподвержен снапшотам, то в его свойствах выберите "Independent ". Кстати, если ВМ имеет "Independent " диски, то в снапшот не может быть включена ее память.



Следующая проблема. которая может перед вами встать - это удаление снашотов.
Если у ВМ есть несколько снапшотов, и вы нажали кнопку "Delete all", то
сначала последовательно сольются все дельты, потом они добавяться к <vm-name>-flat.vmdk. И только после этого удаляться. И на все это вам должно хватить свободного места.
Пример:

у вас есть несколько снапшотов, т.е. несколько файлов. Примерно так:
VM1-flat.vmdk (40ГБ)
    VM1-001-delta.vmdk(5ГБ)
        VM1-002-delta.vmdk(7ГБ)
            Всего занято 52ГБ
    
 
Вы хотите удалить все эти снапшоты. Что происходит:
  1. VM1-flat.vmdk (40ГБ)
        VM1-001-delta.vmdk(5ГБ) + VM1-002-delta.vmdk(7ГБ) = 12 ГБ. Это максимум, в реальности сумма может быть меньше. А может и не быть.
            VM1-002-delta.vmdk(7ГБ)
                Всего занято до 59ГБ
  2. VM1-flat.vmdk (40ГБ) + VM1-001-delta.vmdk(5ГБ) + VM1-002-delta.vmdk(7ГБ) = 40 ГБ.
    Т.к. в дельтах те же самые блоки. только измененные, то они пишутся поверх тех, что есть в  flat  файле. Его размер никогда не превысит номинальный.
        VM1-001-delta.vmdk(5ГБ) + VM1-002-delta.vmdk(7ГБ)
            VM1-002-delta.vmdk(7ГБ)
                Всего занято до 59ГБ
  3. VM1-flat.vmdk (40ГБ)
                Всего занято 40ГБ

Т.е. для применения всех снапшотов вам может потребоваться место сверх занятого - порядка до 5ГБ в моем примере. После окончания применения оно освободиться.


Если такой вариант вам не подходит, потому что от снапшотов надо избавиться срочно, а места на ЛУНе взять неоткуда, то можно пойти другим путем:
  • Клонировать ВМ в другое хранилище(Datastore). Если у вас версия ниже, чем VI 3.5 Update 2, это потребует ее выключения. У клона снапшотов не будет.
    Правда, иногда бывает глюк, и при клонировании все снапшоты корректно не применяются(для клона). Но эта ситуация описана в KB VMware:

    If a clone through the VMware Infrastructure 3 client did not commit the snapshots; you can try to export the disk with vmkfstools to recreate the virtual machine:

    1. Run the following command to create a directory for the new disk:

    [root@bs-tse-d06 RHEL5]# mkdir /vmfs/volumes/openfiler-iscsi/new_RHEL5

    2. Run the following command to point vmkfstools at the last snapshot file:

    [root@bs-tse-d06 RHEL5]# vmkfstools -i RHEL5-000001.vmdk /vmfs/volumes/openfiler
    iscsi/new_RHEL5/new_RHEL5.vmdk

    Destination disk format: VMFS thick
    Cloning disk ‘RHEL5-000001.vmdk’…
    Clone: 3% done
    [root@bs-tse-d06 RHEL5]#

    3. Recreate the machine. Select Use an existing virtual disk.

  • Еще один путь - по сути, то же клонирование, но "изнутри" ВМ. Делаем еще одну ВМ, исходную загружаем с live CD Ghost\Acronis или чего то другого для работы с образами, и переливаем образ из ВМ со снапшотами, в ВМ без снапшотов. Этим путем, кстати, можно уменьшить размер диска - если на исходной ВМ мы задали размер диска больше, чем реально надо.

  • Наконец, можем из этой ВМ сделать еще одну ВМ, уже без снапшотов, с помощью VMware Converter.


Еще при создании снапшота создаются:
*.vmsd файл - файл с описание этого снапшота.Содержит snapshot display name, unique identifier (UID), disk file name, и т.д.
*.vmsn файл - файл с оперативкой ВМ на момент снятия снапшота (если она была включена, и вы указали что память нужно сохранить). Если память сохранена, то при возвращении к этому снапшоту ВМ окажется в работающем состоянии.
Важно: если объем памяти ВМ равен 3 ГБ, у нее сделано 4 снашота с сохранением памяти - то это еще 12 ГБ места на VMFS разделе.

Можно создавать снапшоты из командной строки, командой "vmware-cmd createsnapshot".
Синтаксис примерно такой:
 "vmware-cmd myvm1.vmx createsnapshot snap1 'before upgrade' 1 1"
Две последнии позиции - это ответы на вопросы - делать ли "quiesce" дисков ВМ, и сохранять ли ее память. 1= да, 0= нет.
Так же есть команды "vmware-cmd removesnapshots" и "vmware-cmd revertsnapshot".


Наконец, оставлю в конце первый вариант объяснения и примеров снапшотов.

Снапшот, или снимок состояния - это, по сути, граница. Граница между двумя состояниями ВМ.
 Физически - граница между двумя файлами:
vm1-flat.vmdk и vm1-001-delta.vmdk.

Если снапшот не первый, то между vm1-deltaN.vmdk и vm1-deltaN+1.vmdk

Все файлы кроме последнего используются только на чтение. В последнем хранятся все изменения диска ВМ с момента последнего снапшота, т.е. относительно предпоследнего файла.
 
Т.е., например:
Вы установили ОС, сделали снапшот1.
Установили приложение, сделали снапшот2.
Добились нужной работы от этого приложения - сделали снапшот3.

На диске у вас примерно такая структура vmdk файлов:

  vm.vmdk               - в этом файле хранится все, что было на диске ВМ до 1го снапшота. Т.е. установленная ОС.
--------------------------- наличие этой границы - это и есть снапшот1, с логической т.зрения
    vm-delta1.vmdk   - в этом файле хранятся все изменения на диске с момента первого снапшота. Т.е. установленное приложение попадает уже сюда
----------------------------наличие этой границы - это и есть снапшот2, с логической т.зрения
     vm-delta2.vmdk  - сюда попадают все изменения на диске с момента снапшота2, т.е. изменения настроек приложения.
---------------------------- наличие этой границы - это и есть снапшот3, с логической т.зрения
     vm-delta3.vmdk   - сюда будут попадать все изменения с момента снапшота3, т.е. работа с настроенным приложением.

При удалении снапшота у вас удаляется НЕ файл, а граница между файлами, т.е. происходит объединение vmdk.
 







"
.
Синтаксис примерно такой:
 "vmware-cmd myvm1.vmx createsnapshot snap1 'before upgrade' 1 1"
Две последнии позиции - это ответы на вопросы - делать ли "quiesce" дисков ВМ, и сохранять ли ее память. 1= да, 0= нет.
Так же есть команды "vmware-cmd removesnapshots" и "vmware-cmd revertsnapshot".


Очень важная для траблшутинга снапшотов статья - Устройство снимков виртуальных дисков в VMware VI3.



Перейти на страницу: Snapshot


-------------
Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
Не хотите получать уведомления о собственных изменениях? Измените настройки.

[VMware VI Wiki] Обновлено: Источники информации

Пользователь Михаил Михеев обновил страницу Источники информации. Изменения указаны ниже.

Цветовой ключ: Вставка | Удаление

Сначала - упомяну про поиск по всем этим и другим ресурсам - виПоиск. Чуть подробнее о нем тут.

Из официальных ресурсов стоит выделить:
 
  • Страничка с документацией по VI3 - тут лежат:
    • Compatibility Guides  - списки совместимости серверов, СХД и компонентов. На обновление этих списков можно подписаться по rss.
    • Release Notes.
    • Patches & Updates.
    • Documentation - списки всех pdf. обязательно к ознакомению.
  • Online Library - практически вся та же документация, что и пункте Documentation, но в html. Долго загружается. Очень пригождается возможность поиска сразу по всем документам - очень часто мною используемая возможность.
  • KB - kb.vmware.com - База знаний. Без комментариев.

    Эти ссылки могут устаревать, после выхода больших обновлений. Стартовая страница для самых последних версий тут - VMware Infrastructure 3 Documentation.

Из ресурсов неофициальных:
Русскоязычные:
  • http://vm.pro-it.kz/ - этот блог посвящен теме виртуализации на продуктах VMware.

    Если вы только только начинаете интересоваться все этим, то вам может быть удобно подписаться на rss аггрегатор всех блогов из этого списка - http://www.vmkb.ru/.

  • Англоязычные:


     Если вас интересует информация не онлайн,
                           то приходите учиться - Авторизованные курсы VMware.

    Перейти на страницу: Источники информации


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Обновлено: Источники информации

    Пользователь Михаил Михеев обновил страницу Источники информации. Изменения указаны ниже.

    Цветовой ключ: Вставка | Удаление

    Сначала - упомяну про поиск по всем этим и другим ресурсам - виПоиск. Чуть подробнее о нем тут.

    Из официальных ресурсов стоит выделить:
     
    • Страничка с документацией по VI3 - тут лежат:
      • Compatibility Guides  - списки совместимости серверов, СХД и компонентов. На обновление этих списков можно подписаться по rss.
      • Release Notes.
      • Patches & Updates.
      • Documentation - списки всех pdf. обязательно к ознакомению.
    • Online Library - практически вся та же документация, что и пункте Documentation, но в html. Долго загружается. Очень пригождается возможность поиска сразу по всем документам - очень часто мною используемая возможность.
    • KB - kb.vmware.com - База знаний. Без комментариев.

      Эти ссылки могут устаревать, после выхода больших обновлений. Стартовая страница для самых последних версий тут - VMware Infrastructure 3 Documentation.
    Из ресурсов неофициальных:
    Русскоязычные:
    Англоязычные:


     Если вас интересует информация не онлайн,
                           то приходите учиться - Авторизованные курсы VMware.

    Перейти на страницу: Источники информации


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    понедельник, 13 июля 2009 г.

    [VMware VI Wiki] Обновлено: Security

    Пользователь Михаил Михеев обновил страницу Security. Изменения указаны ниже.

    Цветовой ключ: Вставка | Удаление

    Перейти на страницу: Security


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Обновлено: Security

    Пользователь Михаил Михеев обновил страницу Security. Изменения указаны ниже.

    Цветовой ключ: Вставка | Удаление

    Подборка материалов по VI 3.X

    Перейти на страницу: Security


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Документ удален из files

    Пользователь Михаил Михеев удалил приложение Подборка материалов по VI 3.X.rar со страницы files.

    Перейти на страницу: files

    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Удалено: files

    Пользователь Михаил Михеев удалил страницу files. Перед удалением страница выглядела так:

    Перейти на страницу: files


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Документ приложен к x-files

    Пользователь Михаил Михеев приложил к странице x-files файл с именем ПодборкаматериаловпоVI3.X.rar.

    Перейти на страницу: x-files

    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Создано: x-files

    Пользователь Михаил Михеев создал страницу x-files.

    Перейти на страницу: x-files


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Обновлено: Security

    Пользователь Maria Sidorova обновил страницу Security. Изменения указаны ниже.

    Цветовой ключ: Вставка | Удаление

    Подборка материалов по VI 3.X
    Подборка материалов по VI 3.X

    Перейти на страницу: Security


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Обновлено: Security

    Пользователь Maria Sidorova обновил страницу Security. Изменения указаны ниже.

    Цветовой ключ: Вставка | Удаление

    Материалы

    а вот тут файлыПодборка материалов по VI 3.X

    Перейти на страницу: Security


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Документ приложен к files

    Пользователь Maria Sidorova приложил к странице files файл с именем Подборка материалов по VI 3.X.rar.

    Перейти на страницу: files

    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Обновлено: Security

    Пользователь Maria Sidorova обновил страницу Security. Изменения указаны ниже.

    Цветовой ключ: Вставка | Удаление

    тут всякие ссылки, наверное?Материалы

    а вот тут файлы

    Перейти на страницу: Security


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Обновлено: security

    Пользователь Михаил Михеев обновил страницу security. Изменения указаны ниже.

    Цветовой ключ: Вставка | Удаление

    тут всякие ссылки, наверное?

    а вот тут файлы

    Перейти на страницу: security


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Создано: files

    Пользователь Михаил Михеев создал страницу files.

    Перейти на страницу: files


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Создано: security

    Пользователь Михаил Михеев создал страницу security.

    Перейти на страницу: security


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    воскресенье, 12 июля 2009 г.

    [VMware VI Wiki] Обновлено: VMware HA

    Пользователь Михаил Михеев обновил страницу VMware HA. Изменения указаны ниже.

    Цветовой ключ: Вставка | Удаление

    Что надо знать про VMware HA Cluster.

    Во первых, что он умеет - сводить к минимуму время простоя ВМ, в случае падения хоста. Есть несколько хостов, включенных в HA кластер, есть ВМ на них. Падает какой то хост - ВМ на нем умирают. Но сразу же включаются на других хостах кластера.



    Для него необходим VC и соответствующие лицензии. В консоли VC создаем кластер(напомню, что в контексте VMware "кластер" - просто группа хостов). Создали кластер, перетащили туда хотя бы 2(max 32) хостов. В свойствах кластера поставили галочку "HA".
    Теперь на хостах начнется конфигурирование HA агента. Чтобы это конфигурирование закончилось успешно, должны быть выполнены следующие условия:
    1. Интерфейсы SC должны находиться в одной подсети, т.е. из консоли каждого ESX вы должны пинговать все другие.
    2. Должно быть настроено разрешение имен - т.е. должны ходить пинги и по именам. Для этого используем DNS, или добавляем в /etc/hosts соответствующие записи . Для ESX 3.5 начиная с Update 2 не критично - ибо начиная с этой версии имена разрешаются в IP за счет информации, предоставляемой Virtual Center.
    3. Названия групп портов для ВМ должны называться одинаково на всех хостах кластера. Т.е. вот ВМ1 работает на хосте "ESX1", и ее виртуальный сетевой контроллер смотрит в группу портов "VM_network". Вот на ESX2 должна быть группа портов для ВМ с тем же названием. И, само собой, через нее должна быть доступна та же физическая сеть, что и на ESX1.
    4. Само собой, те ВМ, которые мы хотим защитить с помощью HA, должны лежать на общем(shared) LUN на внешней СХД. Т.е. чтобы с каждого хоста в кластере все файлы этих ВМ были видны.
    Как работает HA кластер:
    когда мы перетаскивам хосты в кластер в консоли VC, то VC настраивает HA агенты на этих хостах. Будучи настроенными, агенты не требуют(!) VC для своей работы. Т.е. VC может находиться даже на виртуалке, и даже если эта виртуалка сдохнет вместе со сдохшим хостом - HA все равно отработает, и поднимет эту ВМ на другом хосте. Достигается это тем, что HA агенты на хостах образуют между собой децентрализованную систему, управляемую самими агентами.

    Агенты друг друга пингуют. Для какого то хоста пропажа пингов означает одно из двух - или умер неотзывающийся хост, или умерла сеть для этого хоста. Второй случай называется изоляцией, и должен обрабатываться особым образом:
    Вот у нас 3 хоста. У одного становиться недоступен интерфейс SC(напр. выгорает порт на коммутаторе). Остальные думают что он умер(т.к. пинги к нему не ходят) и пытаются запустить те ВМ, которые работали на нем. Это не создаст проблемы, т.к. файлы этих ВМ заблокированны как открытые. Но если выход из строя этого порта коммутатора отрезал от сети ВМ этого хоста - то от того, что они работают, нам не легче.

    Поэтому каждый хост умеет проверять, не изолирован ли он. Делается это пингованием IP, по умолчанию это шлюз SC. Или произвольный. Или два произвольных - подробнее про это я писал тут. Предпологается, что эти IP будут отзываться 24\7.

    Итак, хост перестал получать отклики от проверочного IP и понял, что оказался изолирован. Мы в настройках можем указать - что делать с каждой ВМ в случае изоляции - выключать или оставлять. Изолированный ESX выключает свои ВМ, они поднимаются на других хостах кластера. Или не выключает и не поднимаются - это как настроим.

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

    Что еще мы можем настроить:
    Number of hosts failures allowed - смерть какого кол-ва хостов должен пережить наш кластер. Чем большая тут цифирка - тем больше ресурсов резервируется на случай сбоя. Например - у нас 6 хостов, на каждом по 10 ВМ. Если хотим защититься от сбоя одновременно 2 хостов - значит на любых 4х надо мочь запустить все 60 ВМ. Если хотим защититься от падения одновременно 3х - значит на любых 3 надо мочь запустить все 60. "Смочь" - имеется в виду ,что ресурсов должно хватить.
    Admissions control - можно ли запускать ВМ, если ее запуск потребует использования заначки ресурсов из предыдущей настройки.

    Рекомендации - HA best practices.


    Advanced Options.

    Многие настройки HA не вынесены в галочки и выпадающие меню. Они вводятся в табличку, доступную по кнопке "Advanced Options" в настройках HA кластера, в виде "имя опции"  "значение".

    Возможные опции:

    • das.failuredetectiontime - количество миллисекунд. Таймаут перед срабатыванием "isolation response". Значение по умолчанию 15000 миллисекунд.
    • das.isolationaddress[x] - IP адрес. Этот(эти) IP адреса используются ESX для проверки на событие изоляции. [x] = 1‐10. По умолчанию используется шлюз Service Console. Эти IP'шники должны отвечать на пинги 24\7.
    • das.poweroffonisolation - Значение False или True. Это - настройка действия по умолчанию в случае изоляции.
    • das.vmMemoryMinMB - Чем выше значение, тем больше памяти будет резервироваться на случай сбоя.
    • das.vmCpuMinMHz - Чем выше значение, тем больше ресурсов CPU будет резервироваться на случай сбоя.
    • das.defaultfailoverhost - значение - имя хоста. Этот хост будет использоваться как предпочитаемый в случае сбоя.
    • das.failuredetectioninterval - количество миллисекунд. Для изменения интервала проверочных пингов между хостами (heartbeat). По умолчанию - каждую секунду (1000 миллимекунд).
    • das.allowVmotionNetworks - Allows a NIC that is used for VMotion networks to be
      considered for VMware HA usage. This permits a host to have only one NIC configured for management and VMotion combined.
      Если через сетевушку идет трафик Vmotion, то HA не использует ее для своих пингов. Этот параметр разрешает ему это делать.  Подробности и варианты, когда опция пригодится см. в VMware HA Implementation Notes ниже.
    • das.allowNetwork[x] - имя интерфейса Service Console, а точнее - ее portgroup. Например - ʺService Console 2ʺ. [x] = 1‐? .
      Если у нас несколько интерфейсов SC, указываем в каком порядке использовать их под heartbeat'ы HA.
    • das.isolationShutdownTimeout - таймаут перед выключением ВМ в случае изоляции, если выбрана опция "Shutdown VM". По умолчанию - 300 секунд. Другими словами, если ВМ корректно не завершили работу в случае изоляции, то через 300 секнуд они будут выключены насильно.

    • das.ignoreRedundantNetWarning - если true, то вас не будет доставать сообщение "Host <xxx> currently has no management network redundancy."

    Опции из непроверенных источников, пока, к сожалению, без описания:

    • das.trace = ON|OFF
    • das.tracelevel = 0..3|FunctionTracing
    • das.traceoutput = File|EventLog|stdout
    • das.consoleperm = perm_all | perm_oper | perm_user
    • das.consolenode = fqdn
    • das.consoleuser = username
    • das.checkvmstatedelay
    • das.primarycount

    Историческая справка - "DAS" - это первый вариант название функции, ныне известной как VMware HA. Отсюда и наличие этих букв в названии опций.

    Еще на ту же тему: "Расширенные настройки (advanced settings) кластера VMware HA (High Availability) для отказоустойчивости хостов ESX и виртуальных машин."


    Отдельная функция VMware HA, появившаяся после Update 2 - Virtual Machine Failure Monitoring (VMFM).

    Работает она следующим образом: система мониторит ежесекундные heartbeat сигналы от VMware tools, и по факту их пропажи перезагружает ВМ.
    Таким образом, для включения этой функции нам надо:
    ESX 3.5
    VC 2.5
    HA кластер
    Установленные VMware tools

    Чтобы включить VMFM, идем в расширенные настройки HA кластера, и указываем следующие опции:
    • das.vmFailoverEnabled – true (true или false)
    • das.FailureInterval – 30 (ВМ считается зависшей, если от нее не было heartbeat в течении этого кол-ва секунд)
    • das.minUptime – 120 (После включения ВМ нужно какое то время - для загрузки ОС, VMware tools и стабилизации heartbeat'ов. Вот тут мы это время и указываем, в секундах.)
    • das.maxFailures - 2 (Максимальное кол-во сбоев и последующих перезагрузок ВМ в течении времени, указанного в опции das.maxFailureWindow. Если das.maxFailureWindow выставленно ‐1 (no window), das.maxFailures представляет абсолютное количество сбоев, после которого VMFM прекращает автоматические перезапуски ВМ.)
    • das.maxFailureWindow выставлен не в -1, и число  – 86400 (Или -1 или значение в секундах. Если число рестартов превысило указанное в опции das.maxFailures, то VMFM прекращает автоматические рестарты.)

    Для тестов этой функции можно пользоваться симуляцией BSOD.




    Как считаются ресурсы под HA:

    http://virtualgeek.typepad.com/virtual_geek/2008/06/so-how-exactly.html


    http://virtualgeek.typepad.com/virtual_geek/2008/07/vm-ha---service.html


    что то вроде FAQ по работе HA
    имеет смысл перевести и добавить сюда
    http://www.yellow-bricks.com/2008/09/09/ha-primary-and-secondary-nodes/

    Очень правильный документик - VMware HA Implementation Notes - рекомендуется к ознакомлению. Он же приаттачен к этой странице.

    Наконец, что пробовать в первую очередь при траблшутинге - статья в KB Troubleshooting Adding an ESX Server Host to a VMware High Availability Cluster.
    Если HA кластер не собирается -
    1. проверить, что для каждого хоста задано короткое и FQDN имя. проверить можно командной "hostname"
    2. в имени хоста используются только маленькие буквы.
    3. проверить, что все хосты друг друга пингуют по именам командой "ping <имя другого сервера>".
    4. проверить, что в vCenter хосты добавлены по именам(!). т.е. в vCenter вы видите не IP серера а его имя.
    5. можно попробовать Переустановить агент VMware HA на хосте ESX, когда не получается добавить его в HA-кластер.

    еще можно почитать Diagnosing a VMware High Availability cluster configuration failure и Troubleshooting Adding an ESX Server Host to a VMware High Availability Cluster.

    Перейти на страницу: VMware HA


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.