четверг, 30 июня 2011 г.

Подборка важных материалов


Сделал на блоге еще одну страницу - Подборка важных материалов. Процитирую ее в этом посте:


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

Механизмы ESX(i) работы с памятью - Memory management.

Виртуальные коммутаторы VMware умеют делать балансировку нагрузки между физическими сетевыми контроллерами. Вроде бы. Ну, должны. В документации же написано. Да, кое что балансируется, но и нюансов хватает - LACP, 802.3ad, load based IP hash и все такое.


У кластера VMware High Availability есть настройка Admission control, контроль\резервирование ресурсов для заначки на случай сбоя. Варианты этой настройки менее тривиальны, чем кажутся - HA admission control.

Скриптование действий над vSphere из PowerShell - PowerShell + VMware = PowerCLI. How-to.

Минималистская инструкция по настройке и задействованию VMware View 4.x - View 4.5 how-to.

How to speed-up the execution of the first PowerCLI cmdlet


Появилась рекомендация по ускорению первого выполнения скрипта posh - How to speed-up the execution of the first PowerCLI cmdlet.
Вроде как .Net что-то там компилирует, в первый раз, поэтому два подряд выполнения одного скрипта могут на порядок отличаться по скорости. Вот для борьбы с этим есть пара действий.

Ubuntu linux + VMware View PCoIP

 

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

Появился, правда, пока неофициально, клиент VMware View с поддержкой PCoIP для Ubuntu.

Видео:

Ссылка - VMware View PCoIP on Ubuntu How to.

вторник, 28 июня 2011 г.

boot storm. TPS vs. hardware MMU



В комментариях к посту про page sharing - TPS vs. Large Pages in real life
- подсказали пару интересных ссылок.

Итак, суть вот в чем:
TPS позволяет нам сэкономить память, сэкономить заметно, особенно при отключении Large Pages.

После выключения Large Pages  потребляется на треть ОЗУ меньше 

Нагрузка на процессор вроде как растет, но если у вас (как у большинства) процессоры нагружены на 40 и менее процентов, то пофиг до небольшого роста.

Однако возникает опасения бут-шторма.
Так вот, по ссылкам из комментариев приводят данные тестирования ситуации бут-шторма.


Large Pages, Zero Pages, TPS and Boot-Storm in vSphere 4.x
Large Pages, Zero Pages, TPS and Boot-Storm Part II


Вводная:

Сервер с 32 ГБ памяти. Притом серверов два - старый и новый, с поддержкой аппаратной виртуализации памяти и без.
Типовая ВМ - Windows 2003 (а потом Windows 2008) с 4 ГБ памяти.

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

Одновременно включалось 12 таких ВМ.

Вот он boot storm - гости одновременно хотят 48 гигабайт памяти, из 32 имеющихся.

Что происходит на сервере постарее, без аппаратной поддержки виртуализации памяти:


Как видно, как только произошел overcomitment а TPS не смог помочь его избежать - начали применяться механизмы вытеснения гостя из оперативной памяти (balloon\memory compression\vmkernel swap). Конкретно тут, почему-то, использовался своп гипервизора, а не balloon.

UPD. swap вырос аж до 3 мегабайт, видимо в самом начале, когда balloon-драйвер еще не загрузился. Потом не снижается с этих 3 мегабайт так как не было запросов к этой памяти.

Однако - и это узкое место данного теста - большая часть памяти занята не значимыми данными, а только нулями (на это указывает параметр acvtive memory). И раздутый swap оказывал влияние только(или в большей степени) на ненужные гостю страницы с нулями, т.е. провалов в производительности не было. Это-то хорошо, но непонятно как относится к реальной жизни.

Как видно из графика, ситуация стабилизировалась в течении 5-10 минут с момента старта.
А в течении 20 минут потребление памяти опустилось ниже 10 ГБ - за счет работы  TPS.

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



Тут все просто офигенно - все свопы по нулям, память выделенная(consumed) и_не_поднималась(!) выше отметки в 10 ГБ.

Довольно важный вывод - на процессорах с аппаратным MMU ESX(i) не выделяет реальную память под нолики, просто "засчитывая" их гостю.

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

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

vsphere client for iPad


Обновился клиент vSphere для iPad:


remotefx & citrix HDX test


Некоторые особенности виртуализации пользовательских рабочих мест (VDI).

... 
Мы, в компании «СетьПроект», попытались сравнить эти технологии и провести тестирование для оценки возможностей технологий Microsoft RemoteFX и Citrix HDX по виртуализации представлений графических приложений. 
При тестировании мы использовали следующие приложения: AutoCad 2012, Google Earth, Solid Works 2008 SP2.1, Photoshop CS3, 3Ds MAX 2012.
.... 
 

воскресенье, 26 июня 2011 г.

TPS vc. LP UPD.


Пост про эффективность дедупликации ОЗУ после выключения использования больших страниц пополнился данными по нагрузке на процессоры.

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

the cloud and MHz


Много букв на нерусском, по поводу мегагерц в облаках The Cloud and the Sunset of the GHz-based CPU Metric.

Две заинтересовавшие меня цитаты:

Old Benchmark:     150,000 tpmC (4 sockets, 4 cores, 3.66Ghz)
New Benchmark:   2,300,000 tpmC (4 sockets, 32 cores, 2.26Ghz)
(здесь tpmC - транзакций в минуту определенного типа, суть - количество сделанной работы)
и

  • Old server: 150K transactions on 4 cores makes roughly 38000K transactions per 3.66Ghz core which means roughly 10 transactions per MHz.
  • New server: 2.3M transactions on a 32 cores make 72K transactions per 2.26Ghz core which means roughly 32 transactions per MHz
     Идея в чем: одно и то же количество мегагерц на разном оборудовании (у разных облакопровайдеров) может давать разную производительность. В том смысле что старые мегагерцы более медленные, и если провайдер запускает нашу задачу на не самом новом сервере - это может сказаться .

    Как вариант решения проблемы - договоренность о "сферическом виртуальном процессоре в вакууме", как это сделано у Amazon:
     “One EC2 Compute Unit provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor. This is also the equivalent to an early-2006 1.7 GHz Xeon processor“

    Данные размышления применимы, в основном, к облакам в смысле "Инфраструктура", IaaS.
    Однако, не исключены  ситуации когда чьи-то PaaS или SaaS построены поверх IaaS.

    life is life


    Вот так живешь, работаешь, весь такой умный и знающий.
    А потом тебя однажды спрашивают:

    а что это за вкладка Library вот на этом шаге развертывания из шаблона:

    А ты не только впервые в жизни обращаешь внимание на эту неприметную вкладку, но даже и потом нагуглить не можешь что это и зачем это.

    Или еще пример, из не совсем очевидного.
    Если для Windows ВМ указать использование контроллера Paravirtual SCSI перед установкой ОС, то потребуется подложить драйвер.

    Образ дискеты с драйвером идет прямо в составе ESX(i), и можно без проблем зайти в свойства ВМ, выбрать подключение существующего образа дискеты и в каталоге vmimages обнаружить искомое:




    Но есть нюанс:
    Если мы работаем с ESXi, то при работе через vCenter каталог vmimages отображается пустым, т.е. этот способ не работает.
    А вот при подключении напрямую к ESXi - все ок (я вот как-то не знал об этом раньше).

    А с ESX все работает и так и так.


    суббота, 25 июня 2011 г.

    PHD VirtualSAN

    Из переписки:

     

    Михаил добрый день.
    Вот инструкция по настройке бесплатного аналога http://www.vmgu.ru/news/starwind-enterprise-vsa если интересно.
    Замеры скорости пока не делал.

    1. Скачиваем Virtual Appliance http://www.phdvirtual.com/virtualSAN

     

    2. Распаковываем архив

     

    clip_image001

     

    3. Запускаем VMware Converter

     

    4. Создаем XVS1 из архива.

     

    clip_image003

     

    5. Добавляем в виртуальную систему

     

    clip_image004

     

    6. Выбираем ESX-09 и его локальное хранилище

     

    clip_image006

     

    7. Выбираем сеть:

     

    clip_image007

     

    8. После создания XVS1 должна быть такая картина:

     

    clip_image008

     

    9. Проделываем шаги 5 – 7 для другого ESX’а и его локального хранилища

     

    clip_image009

    10. В созданную VM’ку добавляем виртуальный диск, размер этого диска будет равен размеру общего хранилища.

    clip_image010

     

    11. Конфигурируем первую ноду:

     

    12. Выбираем п. 1

     

    clip_image011

     

    13. Задаем идентификатор ноды и ее IP-адреса и адреса второй ноды.

     

    clip_image012

    clip_image013

     

    14. Выходим из меню конфигурирования для дополнительного конфигурирования сети.

     

    clip_image014

    clip_image015

     

    15. Вводим имя пользователя: root пароль: xtravirt

     

    clip_image016

     

    16. Открываем в VI для редактирования файл: /etc/sysconfig/network-scripts/ifcfg-eth0

     

    clip_image017

    clip_image019

     

    17. Для редактирования нажимаем «Insert»

     

    Вводим строчку GATEWAY=[IP-адрес шлюза]

     

    Изменяем маску подсети.

     

    Для выхода нажимем «ESC» далее вводим «Shift + :» «wq» «Enter»

     

    clip_image020

     

    18. Перезагружаем, набирая «Init 6»

     

    19. Повторяем шаги 10 – 18, для второй ноды.

     

    20. Запускаем конфигурирование кворумных дисков на XVS1. Выбираем меню 2. Повторяем операцию для XVS2

     

    clip_image021

     

    21. Запускаем синхронизацию дисков на XVS1. Выбираем меню 3. Повторяем операцию для XVS2

     

    clip_image022

     

    Запустится синхронизация данных.

     

    clip_image023

     

    По окончании синхронизации:

     

    clip_image024

     

    Нажимаем «Enter» для выхода в главное меню. Отключаемся от консоли.

     

    22. Добавляем на ESX-08 в iSCSI Software Adapter iSCSI Targets XVS1

     

    clip_image025

     

    Если все правильно сделано, должно появиться:

     

    clip_image026

     

    23. Повторяем шаг 22 для ESX-09.

     

    24. Проводим rescan HBA

     

    clip_image027

     

    25. Добавляем хранилище:

     

    clip_image029

    clip_image031

     

    thx surgut

    четверг, 23 июня 2011 г.

    MTBF


    Интересный пост по поводу данных о надежности современных дисков - MTBF — откуда берется «миллион часов MTBF».

    TPS vs. Large Pages in real life


    Помните пост Transparent Page Sharing?

    Напомню суть: от механизма дедупликации памяти, Transparent Memory Page Sharing можно ожидать больше эффективности, если отключить использование Large Pages, больших страниц памяти.

    Тут со мной поделились парой графиков по результатам экспериментов:

    clip_image002

    Рисунок 1. Первый кластер 

    Рисунок 1-а. График загрузки процессоров кластера 1


    Обратите внимание на момент, показанный первой стрелкой. Это перед выключением Large Pages, вечер пятницы. До этого порядка 190-200 ГБ ОЗУ было выделено (Granted) для ВМ, и порядка 190 было потреблено(Consumed) на серверах. Затем часть ВМ, видимо обслуживалась, выключалась, перезагружалась, и ESX(i) стал выделять им меньше памяти. А вот затем (двойная стрелка) аппетиты ВМ вернулись на прежний уровень, а вот выделение памяти опустилось с примерно 190 ГБ до примерно 143 ГБ.

    Чуть ли не 50 ГБ, 25%, экономии для одного кластера.

    clip_image003

    Рисунок 2. Второй кластер. 

    Здесь объем занятой памяти снизился с примерно 230 ГБ до примерно 160 ГБ.
    Экономия 70 ГБ, порядка 30%.

    Рисунок 2-а. Нагрузка на процессоры кластера 2


    clip_image004

    Рисунок 3. Третий кластер. 

    Еще порядка трети экономии.

    Рисунок 3-а. Нагрузка на процессоры кластера 3.
     (тут, правда, не очень понятен пик на 167%, но вряд ли это TPS)

    Я не знаю точных размеров инфраструктуры, но это больше сотни ВМ. Из примерно 500 ГБ памяти мы освободили порядка 150 ГБ. Сто пятьдесят гигабайт оперативки. На халяву :-)

    P.S. У нас же тут не маркетинговые сказки, так? Поэтому стоит обсудить вторую сторону медали. Потенциальных проблем по факту таких манипуляция я вижу две:

    1) Снижение производительности из за неиспользования больших страниц.

    К сожалению, мне не удалось быстро нагуглить какие-либо внятные тесты по этому поводу, поэтому вопрос, по большому счету, открыт. К примеру, если выигрыш от их использования наступает только при 10 ГБ на гостя, то далеко не для всех ВМ разница вообще будет.

    Буду рад, если кто подскажет ссылку или поделится опытом.

    2) Самый, наверное, веский аргумент тех, кому по долгу службы требуется указывать на недостатки продуктов-конкурентов – ненадежность сэкономленного. Есть вероятность, что ВНЕЗАПНО!!111 значительная доля одинаковой памяти поменяется у многих ВМ, и Consumed memory резко скакнет. И имеющейся физически памяти на всех не хватит.

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

    А вот если на этой вСфере работают и менее критичные ВМ, и если такая ситуация наступит, то заранее розданные shares позволят производственным ВМ пережить такой всплеск «недедуплицируемости» памяти с минимальным падением комфорта, ну а через какое-то время все устаканится и неважные ВМ вернуться из своих свопов.

    Ну а стоят ли эти минусы экономии трети* памяти вашей вСферы – решать вам.

    *Здесь «треть» означает «больше или меньше 30%»**. 

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

    ***Автор не несет ответственности за негативные результаты, полученные при использовании приведенной здесь информации.
    За позитивные результаты – несет, пишите спасибо в камментах к посту. 
    ;-) 

    big thx Сергею Щадных за информацию.

    понедельник, 20 июня 2011 г.

    грусти псто


    Сегодня меня поджидало два разочарования.

    Во-первых, выяснилось, что сдавать оба теста VCAP смысла нет - за второй приходит точно такая-же кепка, как за первый :-(

    Во-вторых, мне прислали бонусную футболку VMware Certified Trainer.
    Как оказалось, размер XL в штатах рассчитан на двоих меня за раз :-(

    Ну, значит повезет в чем другом :-)

    четверг, 16 июня 2011 г.

    VAAI


    есть такая штука - VAAI, vSphere API for Array Integration. Ее поддержка на стороне СХД позволит ускорить выполнение некоторых операций и сократить накладные расходы на дисковую подсистему за счет сокращения числа блокировок LUN'ов для изменения метаданных.

    Есть мнение - Using VAAI to Maintain Control? - , что эти API всего лишь часть стандарта SCSI, и другим вендорам не составит труда реализовать подобное в своих гипервизорах.

    View + SRM


    У VMware есть продукт для организации катастрофоустойчивой инфраструктуры - Site Recovery Manager.

    Что такое SRM, очень вкратце:



    Несмотря на свою популярность (особо и выбора то нет что применять при решении такой задачи) у этого продукта есть куда стремиться. В частности, отсутствие интеграции с чем-то кроме vSphere. Я не имею в виду сторонние гипервизоры, я имею в виду надстройки над vSphere, в первую очередь VMware View.

    Если у нас есть инфраструктура виртуальных рабочих столов, и мы используем Linked Clones, то штатно защитить эти ВМ при помощи SRM нельзя.

    Если очень очень надо, можно попробовать скрипты. И вот пример - Failover of persistent desktops using SRM and View 4.6.

    Scripted Removal Of Non-present Hardware After A P2V


    Те, кому приходилось использовать VMware Converter для переноса физических серверов в ВМ знают, что в перенесенной таким образом ВМ остается много теперь ненужного.

    Это разного рода софт\драйверы физического сервера, и само оборудование физического сервера, упоминание о котором остается в гостевой ОС.


    Я недавно в очередной раз писал о существовании удобной утилиты для серверов HP - HP Proliant Support Pack Cleaner, умеющей подчищать софт этого вендора.

    А поводом к этому посту стал пост Scripted Removal Of Non-present Hardware After A P2V.

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

    На свой страх и риск. Делаем снапшот перед попыткой применить эту штуку.

    зачем нужен каталог .dvsData для распределенных виртуальных коммутаторов


    Если кто пользуется распределенными виртуальными коммутаторами VMware, то вы скорее всего обращали внимание на каталоги .dvsData, появляющиеся на хранилищах.

    Я тут узнал зачем они нужны - vDS config location and HA. Или оно же по русски - vDS конфиг файлы и VMware HA.

    Virtual Storage Applience - Starwind


    Коллеги, новый частично тематический русскоязычный блог - Секреты работы StarWind, автор Константин Введенский.

    И интересная новость с его блога - Отрелизился StarWind VSA.

    Transparent Page Sharing



    Просто вау - Transparent Page Sharing в ESX 4.1 — по следам прошлогодней статьи.

    Я задавался примерно теми же вопросами (напр. Transparent memory page sharing, vdi, large pages), но автор поста по ссылке вроде как нашел ответы.


    Очень, очень рекомендуется к прочтению.

    P.S. TPS это лишь одна из нескольких технологий ESX(i) для работы с памятью. Вспомнить об остальных можно тут - Memory management.

    P.P.S. блог автора (предположительно), англоязычный - http://vmnomad.blogspot.com/

    HA Isolation and restart delay


    Когда VMware HA обнаруживает отказавший сервер, то предпринимается несколько попыток перезапустить ВМ с проблемного сервера.

    Зачем попыток несколько?

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

    Но не суть.

    Итак, попыток несколько. Если как Т обозначить момент фиксации сбоя, то попытки рестарта происходят по следующему расписанию:

    T       – Рестарт
    T+2   – Повтор 1 (через 2 минуты после предыдущего)
    T+6   – Повтор 2 (через 4 минуты после предыдущего)
    T+14 – Повтор 3 (через 8 минут после предыдущего)
    T+22 – Повтор 4 (через 8 минут после предыдущего)
    T+30 – Повтор 5 (через 8 минут после предыдущего)

    т.е. через 2, 6, 14, 22 и 30 минут после момента отказа.

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

    С другой стороны, если изолированный сервер выключил свои ВМ, минуте на 15 после сбоя, то ждать 8 минут до следующей попытки рестарта может быть многовато.

    С третьей стороны, сделать все равно ничего нельзя.

    Однако есть информация о неподдерживаемом способе - VMware High Availability Isolation Event – Hack The Eight Minutes Delay:
    1.     Go to your ESXi host console (SSH)
    2.     And navigate to /opt/vmware/aam/ha
    3.     vi vmwaremanager.pl
    4.     Scroll down to line 37: “my $VM_RESTART_DELAY_MAX = 480; #8 min“
    5.     Change the value to whatever you want, i.e. 120
    6.     Save and quit
    7.     Restart the management agents: service mgmt-vmware restart and service vmware-vpxa restart
    8.     Tests :)




    job


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

    По совокупности причин мне не хочется теперь публиковать это на блоге, но все же проскакивает мысль - "а вдруг это кому будет полезно?"

    Как компромиссный вариант - подпишитесь на список рассылки, если инфа о вакансиях в дефолт-сити может представлять для вас интерес.



    Это - эксперимент, никаких гарантий я дать не могу, никаких обязательств на себя взять не могу.

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

    deinoscloud, vsphere miltipathing


    Углядел тут нового для себя западного блогера - deinoscloud.wordpress.com.

    Для памятки пара интересных постов.



    Например, интересная инфа про именование модулей сторадж-стека:
    Или инфа про то, что вроде как для ев хьюлет рекомендует настраивать для round-robin балансировки смену пути через каждую 1 команду, не через 1000 как по умолчанию.


    В частности, мне понравилось следующее разъяснение по поводу multipathing:
    "В составе ESX(i) есть поддержка многопутевости в смысле работы с СХД, доступной по нескольким путям, и обработки отказа пути. Но нет поддержки балансировки нагрузки, т.е. работы сразу по нескольким путям с неким алгоритмом балансировки."

    • Хорошо написано про ALUA - Aloha ALUA.


    четверг, 9 июня 2011 г.

    custom MAC


    Узнал, что способ установки произвольного MAC адреса для виртуальной машины работает только в случае стандартного вКоммутатора. Для распределенного вКоммутатора (и Nexus) не нашел как можно произвольный MAC поставить.

    Если дописать произвольный MAC и
    ethernetX.checkMACAddress = “false”

    то ВМ даже не включится с ошибкой.

    оффтоп


    чуток оффтопа - мой друг продает недолго юзаный Macbook Pro i5 2.53, 15" (MC372RS/A), так как этой конфигурации под его программисткие задачи не хватает.

    отличное состояние, если вдруг кого заинтересует - http://mac-sale.livejournal.com/4740700.html.

    понедельник, 6 июня 2011 г.

    kgb

    Наверное, нет такого админа в "этой стране" (tm), который не думал бы о страшных проверках, проводимых соответствующими ведомствами с целью взять его за яйца.

    На курсах, конференциях, иногда даже пьянках возникают дискуссии по этому вопросу.

    Лично я с большим интересом ознакомился с опытом и комментариями к процессу из первых рук на официальном форуме VMware


    - пост с мобильного устройства, сорри за краткость и опечатки.

    питер


    Коллеги, немного оффтопа:

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

    Я это к тому, что эту неделю с небольшим я в этом красивом городе, и как нибудь вечером можно по пивку :-)

    Есть желание - пишите mikhail.mikheev@vm4.ru, буду рад.

    Ephemeral Port Binding


    Как-то я писал о том, что мы теряем если у нас упал vCenter. Напомню:
    1. Перестает централизованно собираться статистика производительности, та, что доступна на вкладке Performance.
    2. Не собираются события, произошедшие с инфраструктурой – вкладка Events.
    3. Перестанут работать alarm.
    4. Кластер drs перестанет работать.
    5. DPM, если был, перестанет работать.
    6. vMotion и все прочие миграции перестанут быть возможными.
    7. Перестанут работать интегрирующиеся с vCenter программы: Converter, Update Manager, Data Recovery.
    8. Если коммутаторы распределенные , изменение их настроек станет невозможным. 
    9. Частично это касается и Cisco Nexus 1000V.
    10. Не получиться быстро найти и включить виртуальную машину, если она лежит на каком-то из большого числа серверов.
    11. Нельзя будет развертывать ВМ из шаблонов
    Скорее всего, мы переживем без этого даже пока быстренько не поднимем vCenter с нуля.
    Однако поступив так, мы теряем:
    1. Статистику производительности, что хранится до года – что плохо для анализа и планирования инфраструктуры.
    2. Теряются события, произошедшие с инфраструктурой – вкладка Events.
    3. Потеряются alarm, созданные нами вручную, и изменения существующих по умолчанию (настройки оповещения в первую очередь).
    4. Потеряются vApp и пулы ресурсов кластера drs
    5. Потеряются правила кластера drs
    6. Перестанут работать интегрирующиеся с vCenter программы: Converter, Update Manager, Data Recovery (возможно, у вас будет что-то еще). Для некоторых потребуется переустановка.
    7. Если коммутаторы распределенные , то конфигурация их будет потеряна  - т.е. при появлении нового vCenter придется подключать к нему сервера ESX(i) и создавать новые распределенные виртуальные коммутаторы.
    8. Частично это касается и Cisco Nexus 1000V.
    9. Потеряются сертификаты.
    10. Если при установке vCenter мы указывали использование портов, отличных от по умолчанию – мы теряем эти значения.
    Мораль – лучше бы нам поднапрячься, и осуществлять таки резервное копирование базы данных vCenter.

    Так вот, с мест сообщают - The Secret of Ephemeral Port Groups - что если для распределенного коммутатора, точнее группы портов на нем, указать port binding = ephemeral, то подключать ВМ к этому вКоммутатору можно будет и без vCenter.

    Напомню, что у port binding есть три варианта настройки:
    1. Static. Виртуальная машина занимает порт, вне зависимости от того включена она или выключена. Число портов в группе портов фиксировано.
    2. Dynamic. Виртуальная машина занимает порт только если она включена. Число портов в группе портов фиксировано.
    3. Ephemeral. Число портов в группе портов безлимитно.

    пятница, 3 июня 2011 г.

    HA admission control



    Последние несколько недель у меня происходило довольно много дискуссий по поводу вроде бы довольно банального VMware HA. Дело в том, что в какой-то момент я задумался над некоторыми его настройками, и нашел их менее очевидными, чем это мне казалось. И вот по этому поводу и хотелось бы немного вбросить.

    Часть первая, введение

    Итак, коллеги, начнем с банальностей.

    Чем мы платим за высокую доступность, которую дает нам VMware HA?

    Правильный ответ – ресурсами. Вернее, заначкой ресурсов на случай сбоя.

    Эту заначку ресурсов мы учитываем

    1. При планировании инфраструктуры.
    2. При эксплуатации инфраструктуры.
    В первом пункте это выглядит примерно так:

    «Ага, нам надо будет запустить 40 ВМ по 2 ГБ ОЗУ каждая, всего 80 ГБ. Накинем еще

    • Запас на пиковые нагрузки;
    • Запас на рост на будущее;
    • Запас на случай отказа одного из серверов;
    • Запас на неправильные расчеты исходных ресурсов ВМ.
    И получим (к примеру) 120 ГБ, которые и раскидаем по трем предлагаемым серверам, очевидно по 40 ГБ в каждом».



    А во втором случае это выглядит примерно так:

    «Ага, если нагрузка на мои сервера превысит 65%, то при отказе одного (двух\трех\...) серверов ресурсов остальных уже не хватит для всех виртуальных машин. Поимею-ка я это в виду…»

    Часть вторая, контроль заначки ресурсов

    Теперь, внимание, вопрос – а каким образом мы можем поиметь в виду недопустимость нагрузки на каждый из серверов выше порогового значения? Вариантов, в общем-то, два:

    1. Или сам администратор заявляет «Я не включу ни одной дополнительной виртуальной машины, пока не будет приобретен еще сервер-другой в мою вСферу». Или, как вариант, «Давайте купим еще сервер, иначе через месяц новые ВМ негде будет включать без опасения что ресурсов не хватит в случае отказа сервера».
    2. или при попытке администратора включить еще одну ВМ появится сообщение об ошибке вида как на рис. 1


    Рисунок 1. Сообщение о невозможности включить ВМ из за настроенного Admission Control


    Вольный перевод:
    «VMware HA запрещает тебе, холоп, включать эту ВМ, ибо претендует она на мою заначку ресурсов на случай сбоя».



    И какой вариант контроля выберете вы?


    Давайте их обсудим.

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

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

    Случай номер два, в принципе, выглядит неплохим. Мы поручаем работу по контролю нагрузки на инфраструктуру кластеру HA, и теперь система непрерывно следит «А можем ли мы себе позволить еще одну ВМ?». Однако, и вот моя самая главная претензия, способы оценки «можем\не можем» далеки от идеала, и именно этот тонкий момент мне хотелось бы проговорить.

    Часть третья, настройки Admission Control

    У кластера HA есть соответствующая настройка - Admission Control (рис.2).


    Рисунок 2. Настройка контроля заначки ресурсов


    В положении «Disable: Power on VMs…» HA не будет сам контролировать заначку. Как раз такая настройка нам подойдет, если мы этот контроль будем осуществлять сами.

    А настройка «Enable: Do not power on VMs…» как раз и приведет к автоматическому контролю «заначки ресурсов», что может вызвать за собой сообщение с рис.1.

    А три варианта настройки с рис.2 – это способы оценки заначки. Давайте про них поговорим.

    Specify a failover host – сервер-запаска


    Рисунок 3. Указание сервера-запаски


    Самый простой вариант. Мы сами выбираем тот один сервер, на котором HA не позволит работать ни одной виртуальной машине. Даже DRS или мы сами не сможем мигрировать на него ВМ или включить. Но сам сервер работать будет все время, пустым. А остальные сервера HA не будет контролировать никак (рис. 4).


     


    Рисунок 4. Пример статистики по нагрузке на сервера кластера


    Мне этот вариант настройки нравится по следующим причинам:

    • Он простой и понятный. Вот сервер – запаска, вот – все остальные сервера, на которые контроль не распространяется.
    • Он дает хорошую гарантию достаточности ресурсов. Если допустить, что сервера у нас типовой конфигурации, то при отказе одного у нас есть 100% ресурсов такого же сервера – неплохая гарантия что после сбоя виртуалкам будет где подняться.
    Однако минусы тоже есть:

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

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

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

    Percentage of cluster resources reserved as failover spare capacity – процент ресурсов

    Второй вариант настройки резервирования ресурсов кластера на случай отказа – резерв указанного процента ресурсов на каждом сервере (рис. 5).


    Рисунок 5. Резерв процента ресурсов


    Проблем две.


    Первая, не очень острая - а сколько процентов надо указать?


    Вторая  проблема возникает в правильном понимании этих процентов. Как вы думаете, что они означают?

    Наводящая картинка – как вы думаете, рис. 6 это чудеса фотошопа или реально возможная ситуация?

    Рисунок 6. Статус резервирования для кластера и фактическая нагрузка на сервера кластера


    Раскрою что здесь изображено - HA считает что ему надо резервировать 25% ресурсов, а реально у него еще свободно от резервов 97%. 
    А на нижней части рисунка отображена реальная нагрузка на оба сервера кластера в 100%.


    Так как - это возможно?


    Правильный ответ – такая ситуация возможна, и вполне вероятна.

    Для правильного понимания ситуации давайте немного отвлечемся.

    Взгляните – вот информация по параметрам виртуальных машин (рис. 7).

    Рисунок 7. Четыре разных параметра ОЗУ виртуальных машин


    Здесь мы видим, что у виртуальной машины vCenter:

    • 3 гигабайта памяти – максимум;
    • 0.5 гигайбата – резерв;
    • 1.9 гигабайта гипервизор реально тратит на нее;
    • 7% от 3 гигабайт она активно использует.
    Внимание, вопрос – какой из этих показателей контролируется HA Admission Control?

    Правы те, кто ответил Reservation.

    Т.е. резервирование 25% ресурсов каждого сервера означает, что на каждом сервере сумма резервов включенных виртуальных машин должна быть меньше-равна 75% ресурсов сервера.

    А максимальное или реальное потребление ресурсов виртуальными машинами НЕ_УЧИТЫВАЕТСЯ_НИКАК.

    Допустим:
    • У типового сервера 64 гигабайта оперативной памяти;
    • 4 ГБ занял гипервизор, 60 ГБ (для ровного счета) доступно виртуальным машинам;
    • Для HA мы указали зарезервировать 25% ресурсов – т.е. 15 ГБ памяти он зарезервировал;
    • Типовая виртуальная машина имеет 4 ГБ памяти как максимум, 0.1 ГБ как резерв, сколько-то потребляет де-факто.
    Сколько типовых ВМ нам дадут запустить на этом типовом сервере с 25% резерва под HA?

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

    Это означает, что

    без указания адекватного reservation для каждой (или большей части) ВМ этот тип резервирования – фикция.

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

    Кстати говоря, а какой должна быть настройка reservation?

    Я вижу два основных варианта – или reservation = 100% от выданного ВМ объема памяти, или reservation равен среднему объему активно используемой памяти (рис. 8).

    Рисунок 8. Активно потребляемая память


    Именно на уровне каждой ВМ, не только пулов ресурсов или vApp!

    Host failures cluster tolerates – по слотам

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


    Рисунок 9. Резервирование "По слотам"


    Далее, HA формирует размер «слота». «Слот» это всего лишь количество мегагерц и мегабайт. 

    Формируется слот или автоматически – по наибольшему reservation среди всех ВМ в кластере, или (что правильнее) указывается вручную через Advanced settings.

    Так или иначе размер слота выбран, теперь считаем статистику нашего кластера (рис. 10).

    Рисунок 10. Статистика по слотам в кластере
    Мы видим, что:

    • Один слот это 50 МГц и 100 МБ;
    • В кластере у нас 82 слота;
    • 14 слотов занято;
    • 9 слотов можно занять еще (9 а не 27 по той причине что серверы различны по конфигурации, а расчет идет по наихудшему сценарию – отказу самого мощного сервера).
    (Эти подсчеты никак не связаны с параметрами виртуальных машин из предыдущих примеров).

    Одна виртуальная машина может занять один, а может несколько слотов (как на рисунке 10 – включено всего 2 ВМ, однако занято 14 слотов). 

    Внимание, вопрос – от чего это зависит?

    Внимание, не самый радостный ответ – снова от reservation виртуальной машины.

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

    Небольшая иллюстрация на рис. 11:


    Рисунок 11. Размер кресла = размер слота, а реальный размер задницы соседей (= реальным аппетитам прочих ВМ) не учитывается


    Этим чудесным хенд-мейд комиксом я хочу проиллюстрировать тот факт, что нам будет мало радости от того, что очередная виртуальная машина включиться (так как слот под нее есть), но работать будет плохо (так как достаточно ресурсов для нее нет) – рис. 12 или, что то же самое – рис. 6.


    Рисунок 12. Иллюстрация оторванности подсчета слотов от реальных аппетитов ВМ


    Некоторые факты и соображения

    В инфраструктурах покрупнее кластеру HA впору опасаться не только отказа сервера, но и отказа группы серверов – из-за отказа шасси блейд-серверов.

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


    Рисунок 13. Разбивка кластеров HA по шасси


    В каждом шасси не более четырех серверов, потому что HA гарантированно переживает отказ максимум четырех серверов.


    И теперь нас интересует настройка резервирования ресурсов для каждого кластера независимо. К сожалению, если отказ шасси влечет за собой отказ более одного сервера кластера, то простого способа гарантировать достаточность ресурсов для ВМ после сбоя нет. Ну или я не вижу :-)

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

    Подведение итогов

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

    Для автоматического контроля запаса ресурсов есть несколько вариантов расчета этого запаса.
    Вариант «резервирование целого одного сервера» мне видится очень хорошим, но не всегда применимым по вышеизложенным причинам.

    Варианты резервирования «процент ресурсов кластера» и «по слотам» мне видятся неприменимыми без указания адекватного reservation для каждой важной ВМ.

    Обратите внимание - по данным опроса в прошлом посте 169 из 184 (на момент написания) ответивших не используют reservation для широкого круга ВМ - т.е. если у этих 92% ответивших  настроен первый или второй вариант Admission Control - это бессмысленно.

    А стоит ли заморачиваться с reservation для работы этих вариантов Admission control – это отдельный вопрос, и не факт что ответ будет «да».

    Еще одним вариантом как можно поступить является следующий:
    1. Как-то адекватно настроить admissions control – самое применимое это выбрать сервер-запаску или вообще отключить этот контроль.
    2. Создать набор пулов ресурсов, и распихать туда виртуальные машины в соответствии с их важностью для нас. В соответствие с важностью указать shares(и, может быть, reservation) на уровне пулов.
    3. Теперь мы получим гарантию, что нашим важным виртуальным машинам хватит ресурсов, пусть даже путем вытеснения неважных ВМ с процессоров и в своп если после срабатывания HA ресурсов на всех не хватает.
    ИМХО, этот вариант лидер по соотношению сложности\эффективности.

    Еще одним вариантом является добавление логики к работе HA при помощи самописных скриптов. Но это уже нефиговое такое джедайство, и я тут ничего конкретного посоветовать не могу.