VMkernel.ru

Давно ничего не писал — просто не было времени. Если кто-то вам скажет, что руководить проще — плюньте ему в лицо Это не проще — но, конечно, намного интереснее.

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

vRAM Entitlement: vRAM is defined as the virtual memory configured to virtual machines. When a virtual machine is created, it is configured with a certain amount of virtual memory (vRAM) available to the virtual machine. Depending on the edition, each vSphere 5.0-CPU license provides a certain vRAM capacity entitlement. When the virtual machine is powered on, the vRAM configured for that virtual machine counts against the total vRAM entitled to the user.

Что я думаю по этому поводу? Что это вполне закономерно. Раньше (по «летоисчислению» HP — это модели g4/g5) на хостах очень не хватало памяти, зато процессорной мощности было с избытком. Лицензий на память было бы просто меньше. Теперь же (g6/g7) все с точностью до наоборот. Памяти все больше и больше (да и IBM со своим MAX5 не дремлет). Зато не хватает «тиков» Отсюда вполне логичное и человеческое желание попытаться заработать как можно больше денег. Тем более, что считает даже не установленная физическая, а сконфигурированная виртуальная память.
Т.е. любителям выделять виртуальному домен-контроллеру по 2Гб придется пересмотреть свои хотелки

Продолжаем разбираться в алгоритмах CPU Scheduler-а. В предыдущих заметках я постарался описать то, как он работает с многопроцессорными машинами вообще и с учетом NUMA-архитектуры. Сегодня поговорим о влиянии кэша процессора на перемещение виртуальной машины. Современные многоядерные процессоры имеют сложную многоуровневую структуру кэш-памяти. Конечно, будет большая схема, ее можно посмотреть под cut-ом: Читать полностью »

До определенного момента мое представление о системах хранения для датасторов VMware было примерно таким:
Если кто-то предлагал организовать датастор на чем-либо, отличном от Fibre Channel, моей первой мыслью было «ага, тестовая лаборатория!» или «а, маленькое внедрение, надо им Essentials посоветовать». Или просто — «вам что, бюджет урезали?». Хотя, я готов был рассматривать iSCSI… для View. Т.е. NAS, как серьезное решение, рассматривать отказывался. Но времена меняются, а вместе с ними — и мнения. Мое мнение начало меняться после появления в vSphere технологии NetIOC и окончательно изменилось после знакомства с системами СХД от NetApp. Откровенно говоря, я очарован возможностями их Unified Architecture. Особенно после многолетнего общения с EVA-ми от HP. Впрочем, в сторону вендоров СХД, вернемся к vSphere и NFS. Сначала разберемся, чем же NFS проигрывает Fibre Channel?

Вот небольшая табличка:

Итак — по порядку:
— Загрузка ESX(i).
Тут все просто. Если у вас есть FC — то несколько маленьких LUN-ов вас совершенно не утянут (если, конечно, ваш вендор не лицензирует СХД по их количеству). В любом другом случае, загрузка с флешки — выбор настоящего самурая. Тем более, что приличные вендоры уже давно предлагают эту самую внутреннюю флешку как опцию — возможно, даже с уже установленным ESXi. А если хотите использовать полноценный ESX… то срочно перестаньте хотеть странного. Прислушайтесь к рекомендациям VMware и проведите, наконец, миграцию на ESXi.
— RDM (Raw Device Mapping).
Тут NFS не игрок. С другой стороны — а для чего обычно используют RDM? Единственное по-настоящему «полезное» применение RDM — это кворумный диск для кластера. Однако и тут — сплошные минусы. Начиная с того, что Storage VMotion для таких виртуальных машин заказан. Да и просто VMotion это Ад и погибель. Некоторые могут возразить — а как же выигрыш в I/O? Коллеги, есть замечательный документ, называющийся «Performance Characterization of VMFS and RDM Using a SAN«. Из него можно вынести, что как при random, так и при sequential чтении и записи VMFS и RDM идут практически вровень. Единственное отличие в том, что нагрузка на CPU сервера ESX(i) чуть выше (от 5 до 8%). Минусы RDM перевешивают плюсы. Соответственно, не будем рассматривать отсутствие RDM на NFS большой потерей.
— VMotion, Storage VMotion, Fault Tolerance & HA.
Все в равных условиях, все «просто работает» (с).

Ну вот, со стороны vSphere получается, что NFS нас вполне устраивает, вернемся обратно к СХД и прочим «железным» вопросам организации датасторов. Что тут можно сказать в защиту NFS?
Начали:

— Скорость.
Все мы знаем, что Fibre Channel это быстро и весело, а NFS — медленно и уныло. Однако мегабайты в секунду — это не все, что нам требуется. Для виртуальной инфраструктуры более критичен другой показатель. IOPS. Виртуальные машины генерят массу операций ввода/вывода и если ваша СХД не может с этим справиться — то никакой FC 8g тут ситуацию не исправит. Теперь о скоростях в NFS . Отдельный LAN (или хотя бы VLAN) для трафика NFS существенно исправит положение. Я уже не говорю о 10g Ethernet, vDistributed Switch и NetIOC.
— Сложность решения.
Откровенно говоря, сделать зонинг и нарезать/презентовать несколько LUN-ов не кажется мне чем-то сверхчеловеческим. Однако многие считают поддержку SAN сродни подвигам Геракла. Отлично, запишем это в минус FC и, соответственно, в плюс NFS. Другое дело, что блочная реализация снапшотов на СХД более сложна в использовании, чем их реализация на основе файловой системы NFS.

Резюме:
Смысл данной заметки — не попытка убедить выбросить FC SAN и срочно закупать оборудование под NFS, нет. Просто несколько аргументов в пользу того, что решения на NFS так же имеют право на жизнь. Причем это аргументы от убежденного сторонника Fiber Channel

Читая документацию по CPU Scheduling в ESX(i) видно, как от версии к версии этот самый Scheduler хорошеет на глазах. Например, в 4.1 существенно был переработан алгоритм работы широких (wide) виртуальных машин на хостах с NUMA-архитектурой. Wide-ВМ — виртуальные машины с количеством vCPU превышающим количество ядер на одном физическом процессоре (сокете). Теперь — традиционное обзорное отступление для рассказа об этой самой NUMA-архитектуре. Отступление с иллюстрациями, потому так же традиционно под cut-ом: Читать полностью »

Довольно часто от коллег по цеху виртуализации слышу слова о неэффективности многопроцессорных виртуальных машин. На первый взгляд это логично, т.к. для работы им нужно столько же свободных ядер физического процессора, сколько vCPU выставлено у них в настройках. Причем — одновременно. Иначе (при отсутствии синхронизации между vCPU) Windows благополучно падает в BSOD, а Linux kernel начинает паниковать. В сегодняшней статье я постараюсь сказать несколько слов в защиту производительности многопроцессорных виртуальных машин. Для большей наглядности будут встречаться иллюстрации, поэтому продолжение спрятано под cut. Читать полностью »

Недавно, один ведущий инженер из интегратора задал вопрос — каким я вижу идеальный датацентр? Без привязки к затратной части проекта — просто «идеальный сферический датацентр в вакууме». В тот момент мне было не до размышлений — третий день ОРВИ и температура не способствовала творческой работе мысли. Поэтому я обрисовал ему стандартный датацентр — основной, резервный, SRM, HeartBeat, 10G и FC. Без подробностей. Но вот сама мысль о подробностях в памяти засела. Вернулась она во время разработки конфигурации для тестовой лаборатории под Cloud Director. Посчитав, сколько понадобится «служебных» виртуальных машин для стенда:
— VM для Active Directory/DNS
— VM для самого Cloud Director
— VM для БД Cloud Director-а — Oracle (жаль, что он не работает с MS SQL)
— VM для vShield Manager
— VM для vCenter
— VM для Chargeback
— VM для MS SQL
я подумал, что все это «хозяйство» и так уже полноценный кластер. К тому же вспомнил некоторые возможные неприятности, подстерегающие тех, кто использует vCenter в виде VM и при этом использует vShield App / Zones (ну и не читает при этом документацию, конечно). И тут, как говорят, «я узрел истину» И имя ей — Management Cluster.
Два или три «pizza-box»-а (например, HP DL360) или три лезвия в разных корзинах, на которых собраны все управляющие виртуальной инфраструктурой виртуальные машины. Эта концепция, как мне кажется, очень хорошо вписывается в определение «идеальный датацентр».
Конечно, эта концепция подойдет только для больших внедрений — какой прок от отдельного кластера под management, когда у вас Essentials Plus? Тут весь management уложится в одну VM под vCenter+SQL Express. Зато когда количество VM для управления вашим облаком начинает расти под ваши нужды (всякие Nexus, Chargeback, разные Appliances) отдельный кластер начинает казаться отличной затеей.

Жаль, но через день оказалось, что до этой гениальной идеи уже додумались товарищи из VMware. Т.к. посетившее меня озарение, буквально слово в слово (с поправкой на английский язык) оказалось изложено в VMware® vCloud™ Director Evaluator’s Guide.

Перед началом чтения убедительно прошу обратить внимание на disclaimer справа от статьи Для начала — как обычно, в сети есть видео, как это настроить. Но более-менее подробные обзоры отсутствуют. Итак, мои личные ощущения от тестирования данного (Symantec ApplicationHA, версия 5.1 sp1 for Windows) продукта:

Инсталляция:

Вроде бы все просто:
Консоль на vCenter.
Пакетная установка Tools на каждую VM, которую требуется защитить.

Но не тут-то было. С установкой на каждую VM есть несколько неприятных моментов:
— При попытке установить на standalone (не принадлежащую к домену) VM:
Цитата:
«Host Name: AppHA-test
VM is in another Domain. Cannot be selected for install.»
А все почему? При запуске инсталлятора нас радуют следующей фразой:
«The logged-on user must have administrator privileges to perform the installation on the virtual machines»
Это особенно неудобно в многодоменной среде. Инсталлятор Netbackup в этом отношении гораздо более гибкий. Там можно задавать реквизиты пользователя, от имени которого будет происходить установка. А в случае с ApplicationHA потребуется столько раз запускать инсталлятор, сколько разных доменов. О рабочих группах вообще страшно подумать — видимо, придется ставить отдельно, внутри каждой VM.

С установкой консоли на сервер также не все гладко:
— Для работы нужен Adobe Flash.
Что по этому поводу говорит Adobe, при нажатии на соответствующую ссылку на вкладке ApplicationHA?
Цитата:
«Проигрыватель Flash Player 10.1 в настоящий момент не доступен для вашего 64-разрядного веб-обозревателя.
На 64-разрядных компьютерах, работающих под ОС Windows и Mac, есть 32-разрядные обозреватели, совместимые с Flash Player. Для получения инструкций о том, как открыть совместимый обозреватель и запустить проигрыватель Flash Player см. Проигрыватель Flash Player на 64-разрядных операционных системах.
Загрузите ознакомительную версию проигрывателя Flash Player с полной поддержкой 64-разрядных веб-обозревателей для компьютеров, работающих под ОС Windows, Mac и Linux, с веб-сайта Adobe Labs.»
Загружать нечто тестовое на production сервер не хотелось бы. Не хотелось бы и на тестовый.
Но ничего страшного, загружаем 32-х битную версию. Работает. На месте разработчиков стоило бы постарался следить за тенденциями VMware. 32-х битные ОС для сервера vCenter более не подходят. А пока плеер для 64-х битной версии только в тесте, не помешало бы поменять ссылку на скачивание. Вернее — открывать при нажатии на нее 32-битный IE.

Настройка:

- на вкладке ApplicationHA в клиенте vSphere необходимо ввести имя и пароль пользователя, обладающего административными правами на данную виртуальную машину. Великолепно. Понятно, что необходим специальный пользователь для каждого домена и каждой VM в рабочей группе для осуществления мониторинга. Но тогда уж не помешала бы и вкладка для менеджмента сохраненными цепочками «домен-имя-пароль».

— Для функционирования ApplicationHA необходимо, чтобы виртуальная машина была видна в сети.
Отключив ее от сети, мы получаем предупреждение, что мониторинг недоступен. Это здорово, но если нам бы хотелось продолжать мониторить процессы внутри VM (например, сеть не очень критична для задач обработки на данной VM)? О том, что VM снова в сети, мониторинг узнает с достаточно ощутимой (минутной) задержкой. Опять же, задержки нигде не настраиваются.

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

— Параметры конфигурации.
Нет настраиваемых шаблонов конфигураций. Совершенно неинтересно настраивать на n+1 критичных VM, выполняющих одинаковые функции одну и ту же конфигурацию вручную.

Использование:

Если отбросить маркетинг, то я не вижу применения данной функции именно как части vSphere. Возможно, при совмещении функций администраторов AD, приложений и виртуальной инфраструктуры это имело бы смысл. При разделении данных ролей, администраторы приложений получают +1 клиент (vSphere), который они должны освоить и применять в работе. В данном случае использование System Center Operation Manager-а более обоснованно. Он предоставляет более полные возможности для контроля сервисов, причем не только виртуальных машин, а всей инфраструктуры (при наличии соответствующих плагинов) в целом.
Да и для малых организаций я не вижу особой необходимости в данном продукте. Скорее всего из-за того, что он делает то же, что можно сделать и стандартными средствами (вкладка Services ОС Windows), но хуже т.к. стандартными средствами эти настройки даже в малых организациях легко тиражировать с помощью GPO. Без необходимости докупать что-либо к существующей инфраструктуре.

Итог:

— Отсутствие в поставке документации. Рекламная брошюра на сайте является только рекламной брошюрой.
— Неудобное развертывание в многодоменной и/или тестовой (standalone) среде.
— Интерфейс. Огромное количество отсутствующих, но нужных настроек.

Наверное, получилось не очень позитивная заметка, но я разочарован.
И это — пятая версия. Я реально счастлив, что не видел предыдущие 4.

В отличии от наполненной общими словами третьей части, в четвертой (и последней) я постараюсь сосредоточиться на технической стороне реализации Network IO Control в vDS. Техническая направленность подразумевает картинки, поэтому остальной текст опять будет спрятан под cut. В конце статьи постараюсь в нескольких словах подытожить, чем же так хорош vDS.
Читать полностью »

Вот и закончились курсы VCP (спасибо Михаилу Михееву, ни разу не заставившему пожалеть о потраченном времени). Самое время закончить последнюю статью про vDS. Однако, хотя на этапе задумки было запланировано три статьи, в итоге их будет четыре.
Всю последнюю неделю коллеги задавали один и тот же вопрос. А именно: «какая третья часть, если все самое интересное уже описал»? Услышав ответ, фыркали: «ну, это пока неприменимо…». Думаю, вы уже догадались, что речь пойдет о замечательной, на мой взгляд, функции — Network IO Control. Или, для краткости — NetIOC. Как и в предыдущих двух, в этой статье будут встречаться сетевые термины (я все еще продолжаю упорствовать в том, что администратор VMware должен хотя бы немного разбираться в смежных областях).

Итак, начнем.
Первое и самое важное.
Основополагающая концепция NetIOC состоит в том, что 1Гб недостаточно. Звучит немного дико, учитывая то, что не так давно 100Мб хватало всем и для всего. Впрочем, как и 640Кб памяти — но уже существенно раньше Но если не останавливаться на мысли «что за чушь, мне 1Гб хватает, да и тот ненагружен» и подумать о CAPEX, то мысли о 10Гб выглядят уже намного более привлекательными. Как со стороны CAPEX выглядят существующие подключения сервера ESXi? Посчитаем минимум:
1 pNIC на Management
1 pNIC на VMotion (хотя многие совмещают с Management… их право)
1 pNIC на VM Network
1 pNIC на iSCSI или NAS (для VM 3-4 классов надежности)
теперь вспомним, что было бы неплохо задублировать (teaming) хотя бы VM Network и iSCSI/NAS чтобы внезапно не оказаться в сложном положении при отказе критичных виртуальных машин. Ну и Management, обеспечивающий нас полезным HA тоже бы неплохо зарезервировать… Что в итоге? Как минимум 6 физических сетевых адаптеров. Но это не самое страшное. Примерно столько сейчас как раз идет в стандартных 1U серверах. Самое страшное, что все эти физические адаптеры нужно… подключить. То есть выделить и сконфигурировать сетевое оборудование, потом подключить все 6 pNIC к этому сетевому оборудованию. И да, это сетевое оборудование мало того, что стоит денег само по себе, так еще и занимает место в стойках, греет воздух, ест электричество и требует специально обученных людей для настройки. Ради чего столько портов, учитывая, что часть из них не будет нагружена даже наполовину?
Вот в таких драматических условиях на сцену и выходит 10Гб, постепенно внедряемый сетевыми инженерами в core и медленно заменяющий 1Гб в датацентрах.
Что мы имеем с его приходом? Два pNIC в team на сервер. Т.к. мы сейчас говорим о Production сети, то нет смысла выделять Management отдельно. Оставим это для DMZ-инсталляций. Весь трафик (так же эффективно, как и физическим разделением по разным pNIC) будет разделен с помощью правил QoS.
Что же такое QoS?
Данный термин очень часто к месту и не к месту применяется сетевиками и обозначает (дословно) «качество обслуживания». Если кто-то хорошо знаком с этой темой — для вас хорошая новость. Тут не будет никаких отброшенных пакетов при перегрузках. Хотя бы потому, что перегрузок не будет. Для тех, кому не интересны технические детали, могу сказать одно. Если вы настраивали пулы ресурсов для использования процессора/памяти — вы уже представляете, как работает NetIOC. Все те же старые знакомые Shares и Limits.

Думаю, мне удалось заинтересовать вас общими словами. Если да — то вам будет интересна и следующая статья, детально описывающая механику работы NetIOC. В эту уже не влезет, из-за обилия тут маркетинга Сам не ожидал, что будет так много общих слов о данной технологии.

To be continued…

Продолжим беседу о vDS.
Из первой заметки можно сделать следующий вывод: vDS это шаблон обычного vSS, задаваемый на уровне датацентра и распространяемый на все использующие его серверы. При отказе vCenter Server этот шаблон становится недоступным для редактирования, не смотря на то, что копии его настроек продолжают функционировать на отдельных ESX/ESXi-серверах.
Т.е. не стОит думать о vDS как о коммутаторе, к которому подключены серверы ESX/ESXi. Реальная картина (почти) такая же, какой была до внедрения vDS. На каждом сервере по прежнему есть vSS — только скрытый. И на него распространяются (обновляясь каждые 5 минут) настройки общего шаблона (vDS), конфигурируемого на vCenter.

(т.к. в тексте опять будут периодически появляться картинки, то сам текст благополучно спрятан под cut)
Читать полностью »