Наконец таки решил написать.

Стораджи бывают разные….

Но я не об этом. Я о режимах работы их контроллеров.

И так в природе есть несколько режимов работы контроллеров (на английском часто называют Storage Processor или SP) у различных СХД —  это Active/Passive и Active/Active. Последние еще делятся на SAA и ААА.

Более подробно ниже.

Active/Passive

Старый вариант СХД, сейчас этот вид отживает последний срок. К ним относятся такие стораджи как HP MSA первого поколения, HP EVA (предыдущих поколений), IBM DS 3xxx/4xxx (предыдущих поколений), EMC CLARiiON с CX по СX3 и много других.  Суть работы такова. Один из контроллеров является активным и участвует в операциях I/O. Второй контроллер просто находится в ожидающем состояние и не участвует в операциях ввода вывода. Как только произошел сбой или авария (умер контроллер, упали все пути до контроллера и т.п.) активным контроллером становиться пассивный (это происходит автоматически или же выполняется администратором вручную).

Active/Active

Данные класс делиться на два подкласса:

• Symmetrical Active/Active (SAA)
• Asymmetric Active-Active (AAA)

Symmetrical Active/Active (SAA)

Это СХД хайэнд класса уровня enterprise. Очень шустрые, мега функциональные и жутко дорогие. В этих стораджах все контроллеры участвуют в операциях I/O. Причем в таких СХД обычно больше двух контроллеров. К ним относятся такие стораджи как EMC SYMETRIX, HP XP, IBM 8xxx.

Asymmetric Active-Active (AAA)

Самый широкий по моделям класс СХД (начальный и средний уровень). Кстати почти все модели стораджей которые раньше были Active/Passive теперь стали AAA. К примеру таже HP MSA первого поколение, после определенной прошивки (не помню номер), становиться ААА. Сейчас к этому классу относиться HP MSA второго и третьего поколения, HP EVA, IBM DS 3xxx/4xxx/5xxx, EMC CLARiiON CX4 и много других.

Принцип работы AAA стораджей отличается от их старших собратьев SAA. Причем у разных производителей дела обстоят по разному.

В общем схема выглядит так, оба контроллера активны. К определенному контроллеру привязывается LUN (такой контроллер называется  owner [владелец] данного LUN). И все операции I/O идут только через контроллер владелец.  Путь или пути от HBA до LUN через owner контроллер называются оптимизированными, при этом достигается максимальная производительность. В случае сбоя операции ввода вывода пойдут через другой контроллер не являющийся владельцем LUN. Такие пути или путь называются не оптимизированными и обычно в таких случаях наблюдается потеря производительности. Почему собственно так происходит? Дело в том что, операция I/O идущие через неоптимизированный путь, попадают на второй контроллер, далее второй контроллер по внутренней шине передает их на owner контроллер, тот обрабатывает запросы и передает все в обратном порядке.  Такой способ передачи данных по интерконекту не является быстрым, да плюс ко всему живой контроллер обрабатывает еще операции I/O со своими  “родными ”LUN, в итоге мы получаем на живом контроллере большую нагрузку.

В этих же стораджах (но не во всех) применяется и еще такая технология как ALUA .

ALUA  — Asymmetric Logical Unit Access. Протокол стандарта SCSI-2 и SCSI-3 предоставляющий доступ к данным через разные пути передачи, причем с разными видами доступа. Она также помогает автоматически переключиться на оптимизированные пути.

Итак рассмотрим ситуацию, на СХД имеем два контроллера и два LUN-a, на хосте 2 одно портовых HBA, каждая из которых подключена к контроллеру одним путем.

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

После того как основные пути поднялись сторадж без ALUA продолжает работать по тем же не оптимизированным путям. Чтобы переключить I/O на оптимизированные пути администратору необходимо выполнить это действие вручную.

Вот тут как раз нам приходит на помощь ALUA, она как раз и занимается тем, что автоматически переключает операции I/O на оптимизированные пути.

Multipath

Я уже писал о политиках multipath в vSphere. Тут снова немного повторюсь.

Для Active/Passive лучше всего подходит политика MRU и она обычно используется, но сразу замечу что и для многих стораджей типа AAA тоже используется MRU. К примеру по умолчанию для IBM DS 3xxx/4xxx сторджей.

Для SAA стораджей используется обычно Fixed, а также можно и нужно использовать Round Robin, так как достигается максимальная производительность. Отдельно напишу о Round Robin чуть ниже.

Для AAA Fixed или же RR.

К слову сказать часто производители стораджей делают свои плагины для multipath, например powerpath для EMC стораджей.

И так round robin лучше всего включать, когда есть несколько путей. В идеально данная политики подходит для SAA стораджей. Мы получаем и повышение производительности и отказоустойчивость.

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

И еще к слову часто читал в интернете что при RR на AAA стораджах наблюдаеться падение производительности. Собственно я ни разу за практику такого не наблюдал, не считая авральных случаев с отваливание всех путей до owner контроллера, но тут и так понятно, что будет потеря.

И на последок несколько рекомендаций для админов AAA стораджей:

• Не вешайте на один контроллер все LUN.
• Планировать SAN так, чтобы был multipath, желательно как минимум по два пути от одного хоста к каждому контроллеру СХД.
• Разделите особо нагруженные LUN по разным контроллерам.
• Используйте политику Round Robin. Если нет родной политики multipath. Перед включение RR на продакшен LUN’ах, протестируйте работу политики на тестовых LUN’ах.
• На AAA стораджах без ALUA, особенно после сбоев, обращайте внимание на warning сообщение СХД о том, что данные идут по неоптимизированным путям.

Глобальных изменений в функционал он не принес. Большая часть изменений касается багфиксов, расширения списка поддерживаемых гостевых ОС, расширение списка поддерживаемых СУБД для vCenter.

Более подробно можно прочитать: VMware vCenter Server 4.1 Update 1 Release Notes, VMware ESXi 4.1 Update 1 Release Notes,

VMware ESX 4.1 Update 1 Release Notes, VMware vCenter Update Manager Release Notes.

Углядел новость тут.

Так что после выходных буду обновлять тестовый кластер и тестировать Update 1.

30 августа 2010 г. вышел VMware vCloud Director (vCD). Этот проект ранее был известен под названием Redwood.

vCD – это служба которая предоставляет ресурсы VMware vSphere в виде каталога служб. Ориентированно в первую очередь на провайдеров услуг и крупные компании. Собственно vCD это еще один уровень абстракции теперь над VMware vSphere.

Подробней  о продукте VMware vCloud Director  на сайте VMware.

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

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

Ссылки где можно почитать о vCD

Официальная документация

Подборка статей о vCD сделанная Duncan Epping:

• VMware vCloud Director (vCD)
• Unloading the vCD Agent
• vCD – Networking part 1 – Intro
• vCD – Networking part 2 – Network Pools
• vCD – Networking part 3 – Use case
• vCD – Networking part 3 – Use case 2
• Creating a vCD Lab on your Mac/Laptop
• Error during creation of NAT Routed network via VMware vCloud Director (vCD)

Статьи о vCD от Hany Michael

Установка продукта

Буду краток, так как в интернете есть много информации по установки vCD. Приведу основные моменты.

Для установки vCD нужно:

1. VMware vSphere и VMware vCenter;
2. База данных и причем только на Oracle;
3. Кластер в VMware vSphere;
4. VMware vShield;
5. Виртуальная машина с Red Hat Enterprise Linux 5 (64 bit)

VMware vCloud Director 1.0 installation requirements

Если все есть. Скачиваем сам VMware vCloud Director. Закидываем его в ВМ. Устанавливаем.

KB с видео — установка VMware vCloud Director.

На этом пока все.

Многим  знаком режим unsupported в ESXi 4 и чтобы войти в данный режим надо было набрать unsupported на клавиатуре в локальной консоли, после этого мы попадали в busybox консоль ESXi.  Еще, наверное, многие помнят, как было немного геморно включать SSH на ESXi 4.  Да и кстати данные вещи официально не поддерживались VMware, так что если что то случилось после работы в режиме unsupported и Вы пошли писать письмо о помощи или с вопросом, то можно было сказать прощай офф. саппорту. Единственными официальными способами работы из командной строки были vSphereCLI и vMA.

Но парни из VMware не стоят на месте и в версии ESXi 4.1 официально появилась поддержка интерфейса командной строки busybox консоли как локально, так и удаленно через SSH и называются они соответственно Local Tech Support и Remote Tech Support . Активация этих режимов стала очень быстрой и удобной.

Существует два вариант активации Tech Support Mode

1. Локально из DCUI консоли ESXi;
2. Через vSphere Client;

Активация через DCUI.

Логинимся и заходим в локальную консоль.

Нас интересует Troubleshooting Options. В этом разделе как раз все и включается, а также и отключается.

Идем туда и видим

Опция Enable Local Tech Support включает локальный интерфейс командной строки.

Опция Enable Remote Tech Support (SSH) включает удаленный доступ к командной строке busybox консоли через SSH.

Опция Modify Tech Support timeout — это время ожидание в минутах при котором оба режима Tech Support  отключаются автоматом. Если есть открытые сессии, то на них эта опция не распространяется. Опция срабатывает только в том случае если нет открытых сессий (локальной и/или удаленных). Чтобы отключить данную опцию необходимо выставить время таймаута в 0.

Активация через GUI vSphere Client.

Идем в раздел Configuration -> Security Profile

Далее Properties.

Тут в принципе все теже опции что и в локальной консоли ESXi. Службы для Local Tech Support и Remote Tech Support (SSH) не запущены.

Выбираем нужный сервис (Local Tech Support/Remote Tech Support (SSH) ) и жмем Options.

Далее жмем кнопку Start дабы сейчас запустить сервис, а затем выбираем в Startup Policy режим автоматического запуска.

После выполнение процедуры видим что статус демонов стоит в Running.

Чтобы включить/отключить/изменить таймаут для автоматического отключения Tech Support Mode (в DCUI опция назывывается Modify Tech Support timeout) в GUI vSphere Client необходимо сделать следующее.

Идем Configuration -> Advansed Settings -> UserVars. Далее параметр UserVars.TSMTimeOut.

Кстати тут время измеряется в секундах, а не в минутах как в опции Modify Tech Support timeout в DCUI ESXi. Чтобы отключить таймаут необходимо просто выставить значение времени в 0. Любое другое значение означает, что таймаут включен.

О релизе тут.

О новых возможностях в этом официальном документе.

Страница загрузки продуктов.

Документация как всегда тут.

Все вкусности описывать не буду, так как коллеги уже подробно описали на русском, даю линки.

Отличный документ о новых возможностях vSphere 4.1 от Александра Самойленко.

Подробное описание новых фич от Михаила Михеева.

Хочется также сказать, что в редакциях изменился доступный функционал. Теперь VMotion доступен в редакциях Standart и Essentials Plus. Посмотреть можно тут и тут.

Цитирую что ответили.

- As you must be aware, thin provisioning is only available for in ESX 4.0. The behavior that you have mentioned in the case description is by design. Whenever a think provisioned disk is moved or copied to a different data store it will be converted to a thick disk. When you are copying it to a workstation and if we assume that it is running Windows (NTFS file system) it is automatically converted to a thick disk.

- However we can clone a thin provisioned vmdk to anther data store keeping it in the thin format.

Как я и думал. Прямого копирование между датасторами или же на другую файловую систему тонких дисков нет. Т.е оно есть, но при копирование он автоматом превращается в толстый. Хотите перенести ВМ с тонким диском на другую датасторе – мигрируйте (Migrate) или клонируйте (Clone) ее.

Планируется выпустить в этом году. Когда именно не известно.

Список того что будет.

Переводить не буду, даю как есть, вроде и так все понятно. Самое, наверное вкусное чего так многие ждали так это Support for USB pass-through.

• Storage I/O can be shaped by I/O shares and limits through the new Storage I/O Control quality of service (QoS) feature
• Network I/O can be partitioned through a new QoS engine that distinguish between virtual machines, vMotion, Fault Tolerance (FT) and IP storage traffic.
• Memory compression will allow to compress RAM pages instead of swapping on disk, improving virtual machines performance.
• Distribute Resource Scheduling (DRS) now can follow affinity rules defining a subset of hosts where a virtual machine can be placed
• Virtual sockets can now have multiple virtual CPUs. Each virtual CPU will appear as a single core in the guest operating system.
• A team physical network interface cards in a vNetwork Distributed Switch can now dynamically load balance traffic.
• Health check status and operational dashboard are available for HA configurations.
• vSphere Client is no more part of the ESX and ESXi installation packages. At the end of the installation process administrators are redirected online to download the client.
• ESXi installation can be scripted. The script can start from a CD or over a PXE boot source, and can install the hypervisor on local or remote disks.
• ESX can boot from iSCSI targets (support for iBFT)
• NFS performance stats are included in esxtop and vCenter Server, as well as through the vSphere SDK.
• Virtual machines serial ports redirection over the network
• Support for up to 4 vMotion concurrent live migrations in 1GbE networks and up to 8 concurrent live migrations in 10GbE networks
• Support for USB pass-through (virtual machines can use ESX/ESXi local USB devices)
• Support for administrator password change in Host Profiles
• Support for FT in DRS clusters with with Enhanced vMotion Compatibility (EVC)
• Support for iSCSI TCP/IP Offload Engine (TOE) network interface cards (both 10GB an 1GB)
• Support for 8GB Fibre Chanell HBAs
• Support for IPsec on IPv6 network configurations
• Support for multiple Data Recovery virtual appliances
• Support for Microsoft Volume Shadow Service (VSS) in Windows Server 2008 and 2008 R2 guest operating systems for vStorage APIs for Data Protection (VADP)
• Update Manager (VUM) can now patch additional 3rd party modules for ESX (like EMC PowerPath)
• Virtual to Virtual (V2) migration for offline Hyper-V virtual machines in vCenter Converter
• ESX and ESXi direct support for Microsoft Active Directory through Likewise technology integration
• Support for Intel Xeon 7500 / 5600 / 3600 CPU series (this includes EVC support)
• Support for AMD Opteron 4000 / 6000 CPU series (this includes EVC support)

Так что ждемс.

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

Информация о релизе документа

В физической среде было бы не так быстро и просто выполнить данную операцию. Во первых сама процедура установки нового железа. Во вторых в зависимости от оборудования и инфраструктуры, пришлось бы останавливать сервер, для добавления железа. А если учесть что данный сервер постоянно находится под нагрузкой и в работе, то пришлось либо переносить/перенаправлять его на другой сервер в кластере, либо если нет кластера (а в секторе СМБ часто кластеров нет), то ждать ночи и делать апгрейд. Конечно, терять свое драгоценное время для отдыха, как то порой не очень хочется. А еще я стремлюсь сократить любые простои ИТ инфраструктуры до минимума. Вот и дилемма была бы.

Но блага у меня инфраструктура виртуальная и это решает кучу таких вот дилемм и маленьких проблем.

В данном случае на помощь приходит Hot Add или горячее добавление устройств в ВМ.

Пара движений, максимум 10 минут на все и вуаля у нас на сервере уже на диске место, и прибавка к оперативке без лишних хлопот, остановок и больших трудозатрат. Скажу одно: Hot Add реально облегчает жизнь, а также экономит время административного персонала и сокращает финансовые расходы компании.

Чтобы была возможность горячего добавление CPU и RAM, ее нужно разрешить в свойствах ВМ (Свойства ВМ -> Вкладка Options -> Memory/CPU Hotplug), по умолчанию данные опции выключены.

Если ВМ включена, то ее придется выключать иначе никак. После включение данной опции можно уже в работающей ВМ добавлять CPU или RAM. Горячее добавление дисков сразу поддерживается без включения, каких либо опций.

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

Cписок ОС которые поддерживают горячее добавление.

• Windows Server 2003 Enterprise – только горячее добавление RAM. CPU добавляется только после перезагрузки;
• Windows Server 2003 Datacenter – горячее добавление CPU и RAM;
• Windows Server 2008 Enterprise — только горячее добавление RAM. CPU добавляется только после перезагрузки;
• Windows Server 2008 Datacenter — горячее добавление CPU и RAM;
• Linux дистрибутивы с ядром 2.6.14 или более поздним. (Сам не проверял, взял с инета);

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

Открылся новый интересный сайт VMwareSecurityGroup.ru посвященный безопасности в одной из моих любимых областей — виртуализации.

Поздравляю коллег и искренне за них рад! Удачи в плавание по просторам интернета!

Рекомендую всем к частому посещению данного ресурса.

* Адрес интернет-портала был изменен на VirtualizationSecurityGroup.Ru