Изменение размера диска ВМ

Одна из частых задач для администратора виртуальной платформы - изменение размера диска ВМ.
Вопрос: Зачем это вообще нужно, и почему нельзя создавать ВМ сразу с нужным диском?
Ответ: шаблоны. У меня лично, например, был шаблон с мааааленьким диском (8ГБ) и установленной Windows 2003, который после развертывания нужно было увеличивать под задачу.
Ну диск-то ладно, увеличить просто. А что делать с системным разделом Windows? Дополнительный софт, зачастую платный, перезагрузки и т.д.

Между тем есть магическая утилита от Dell - ExtPart, позволяющая за буквально 30 секунд без перезагрузок увеличить размер диска C: до нужного, если соотв. vmdk уже увеличен.

vSphere 5.1 vs Hyper-V R3. Оценка стоимости ресурсов.

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

То есть вместо того, чтобы платить за фиксированные ресурсы - количество ЦПУ, объём памяти и объёмы ГБ на СХД пользователь платит только за количество реально использованных мощностей поставщика - количество гГц, количество IOPS и утилизированную память. Основываясь на этих данных облачный провайдер уже может выставить счёт заказчику.

Hyper-V
Сам гипервизор позволяет измерять количество гГц, объём занятой памяти, количество переданной по сети информации и объём диска ВМ, но не позволяет считать количество IOPS, что тоже было бы неплохо.

Hyper-V не имеет какого-либо графического интерфейса для составления отчётов, управления стоимостью ресурсов, и т.д. Для создания отчёта об использовании ресурсов необходимо использовать скрипты на PowerShell, а отчёты потом импортировать в соответствующее ПО.

System Center Service Manager 2012 SP1
Оценка стоимости утилизации ресурсов реализована в специальном дполнении Center Cloud Services Process Pack для System Center Service Manager 2012 SP1.

vSphere
VMware предлагает отдельный продукт - vCenter Chargeback Manager, который позволяет считать самые разнообразные параметры и автоматически выставлять счета.

vSphere 5.1 vs Hyper-V R3. Интеграция с СХД.

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

Поддержка SAN 
Обе системы поддерживают основные блочные протоколы доступа - FC, iSCSI, FCoE, тогда как на файловом уровне Hyper-V использует SMB, а vSphere - NFS. Я бы сказал, что это полный паритет.

Do it yourself (DIY) или дешёвые СХД
Системы хранения данных обычно являются самым дорогим компонентом, поэтому некоторые предпочитают собрать самим более дешёвое решение.

VMware предлагает Virtual Storage Appliance (VSA), работающий как ВМ на хосте и использующий локальные диски для создания отказоустойчивого решения.

Hyper-V предлагает встроенную поддержку iSCSI таргета и SMB шары.

Кроме того, существуют сторонние решения для обоих решений типа LeftHand VSA, Datacore, StarWind и т.д.

Выгрузка операций на массив
Некоторые операции гораздо выгоднее выполнять на самом массиве, а не на хосте - например, клонирование ВМ или перемещение на другой LUN.

На данный момент VMware VAAI, в отличие от Hyper-V ODX, может использовать данные примитивы для клонирования ВМ, а также поддерживается более широким количеством производителей.

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

vSphere в данном случае предлагает два механизма:

SIOC (Storage IO Control) - аналог QoS для СХД. Пока задержки не достигнут критического уровня все ВМ потребляют необходимое им количество ресурсов, в случае выхода за критическую отметку - ВМ с большим приоритетом получают большую полосу пропускания.

Storage DRS - данный механизм по необходимости перемещает ВМ между датасторами в автоматическом режиме для оптимизации нагрузки.

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

Максимальный размер виртуального диска поддержка дисков с размером блока 4k
Для vSphere максимальный размер диска составляет 2ТБ-512байт, тогда как Hyper-V поддерживает два формата - VHD и VHDX. Последний ограничен размером в 64ТБ.

Также на данный момент vSphere, в отличие от Hyper-V, не поддерживает Advanced Format и диски с размером сектора в 4кб.

Репликация 
Обе платформы имеют встроенные механизмы репликации данных, работающие независимо от подлежащей СХД.

Управление и автоматизация работы с СХД
Virtual Machine Manager использует протокол SMI-S для интеграции с массивами, как следствие операции проводимые с СХД ограничены возможностями данного протокола.

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

Кэширование для VDI
Boot storm - понятие описывающее резкую пиковую загрузку на СХД из-за массовых логинов пользователей утром при приходе на работу. Для снижения нагрузки на СХД используются алгоритмы интеллектуального кэширования данных.

Данная технология есть у обоих продуктов - CBRC (Content Based Reading Cache) у vSphere и CSV Cache у Hyper-V.

Оригинал: http://up2v.nl/

BPDU фильтр в vSphere 5.1

BPDU (Bridged Packet Data Unit) - пакеты которыми обмениваются физические свитчи в рамках протокола Spanning Tree, который блокирует возможные петли в сети. При подключении порта на свитче STP начинает рассылать BPDU пакеты, чтобы определить должен ли данный порт пересылать данные или быть в заблокированном состоянии. Обмен пакетами происходит между всеми свитчами в сети для определения корневого свитча и построения древовидной структуры сети. Виртуальные свитчи не принимают участия в STP, и потому не отсылают BPDU, а при получении такого пакета просто его отбрасывают.

Процесс определения корневого свитча и требуемого состояния порта занимает от 30 до 50 секунд, в течение которых через данных порт данные пересылаться не могут. Если какое-либо приложение будет пытаться достучаться до данных, находящихся на данном порту, то, в итоге, столкнётся таймаутом. Для нивелирования таких задержек рекомендуется включать на свитчах Port Fast - в таком случае порт сразу будет активным, а в случае обнаружения петли будет блокирован.

Также на портах используемых для vSphere рекомендуется включать функцию BPDU Guard, которая позволяет не позволяет указанным портам вносить изменения в структуру данных STP. Изображение ниже приводит является наглядным примером того на каком уровне сети начинает работать BPDU Guard.

vSphere 5.1 vs Hyper-V R3. Правила близости (affinity rules)

Этим постом мы открываем серию по сравнению функционала vSphere 5 и Hyper-V R3. Рассматриваться будут ESXi 5.1 + vCenter 5.1 и Hyper-V R3 + Virtual Machine Manager 2012 SP1, который в данный момент находится в состоянии бета тестирования, и финальная версия которого выйдет в начале следующего года.

В первой статье хотелось бы раскрыть тему правил близости - affinitity rules, механизма который позволяет держать ВМ на разных или на одном хосте, в зависимости от ваших требований. Первое может быть необходимо, например, для Exchange кластера, тогда как второе для ВМ активно обменивающихся трафиком между собой.

Настройка правил близости в vSphere 5.1 
Правила задаются в свойствах кластера. Настройка доступна как через вэб, так и через классический клиент. Правила начинают действовать сразу после создания.

Существует три вида правил:
VM-VM affinity rules - указанные ВМ будут работать на одном хосте
VM-VM anti-affinity rules - указанные ВМ будут работать на разных хостах
Host-VM affinity - ВМ будет работать на определённой группе хостов.

Данные виды бывают двух типов:
Should - "желательное" правило, может быть нарушено в случае необходимости (например, недостаток хостов в кластере)
Must - обязательное правило, не может быть нарушено ни в каком случае.

Также в vSphere 5.1 была представлена функция Storage DRS, предоставляющая такие же функции, но для жёстких дисков виртуальных машин.

Детали работы vSphere Affinity Rules описаны отдельным постом: http://blog.vadmin.ru/2012/09/affinity-rules.html

Настройка правил близости в SCVMM 2012 SP1
В данном релизе представлена новая функция - availability set. Данная опция настраивается на уровне каждой отдельной виртуальной машины, после чего VMM будет пытаться держать ВМ входящие в одну группу на разных хостах.


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


Мне не удалось найти опции заставить работать ВМ на одном хосте.


Оригинал: http://up2v.nl/

VMware User Group Belarus

7 декабря в городе Минск пройдет первый VMUG Belarus.

Время и место: 10-00 гостиница Орбита.

Что это: неофициальное, некоммерческое мероприятие, посвященное продуктам VMware и смежным технологиям.

Зачем: это отличная возможность поделиться опытом, узнать ответы на технические вопросы, послушать доклады представителей EMC, VMware и других профильных компаний. И все это в неформальной обстановке.

Для кого: системные администраторы, инженеры поддержки, руководители IT отделов, IT аналитики и все кто не равнодушен к технологиям виртуализации.

Программа:

1. Возможности EMC Avamar для резервного копирования сред VMware. (Антон Жбанков. EMC / VMUG RU)
2. vSphere 5.1: Что нового? (Константин Введенский. VMUG UA)
3. Симбиоз Citrix XenAPP и VMware vSphere (Сергей Горлинский. VMUG BY)
4. VMware vSphere Replication Technical Deepdive (Евгений Гарбузов. VMUG UA)
5. Как сделать, чтобы дисковая система не стала узким местом инфраструктуры (Антон Жбанков. EMC / VMUG RU)
6. И погружение в практику от Владислава Кириллина. VMware Professional Service

Регистрация обязательна!

Управление памятью в ESXi 5.x

VMware опубликовала статью в Knowledge Base, превосходно описывающую управление памятью в ESXi 5.x. Причем в отличие от более ранних версий, в форме презентации и диаграммы, прекрасно понятных даже для тех, у кого хромает английский язык.



ЗЫ: кликать надо по самой презентации, а не по стрелкам внизу.

Перезапуск виртуальной машины: в кластер или в ресурсный пул?

Недавно меня спросили: виртуальная машина, перезапущенная HA, попадёт в свой ресурсный пул или в корневой ресурсный пул кластера?

Когда HA перезапускает ВМ после сбоя он размещает её в корневом ресурсном пуле кластера, а уже DRS перемещает её в соответствующий ресурсный пул. Так как, по умолчанию, DRS вызывается каждые 5 минут, то максимальное время которое ВМ будет работать вне ресурсного пула – 5 минут.

Как насчёт долей (shares)? Что если ВМ были назначены высокие значения доли, или, что может быть хуже, низкие? Ведь в течении этих 5 минут в ожидании запуска DRS относительные доли данной ВМ могут доминировать над дочерними объектами, или, наоборот, ВМ может столкнуться с недостатком ресурсов из-за других ВМ.

Для решения возможных проблем HA «выравнивает» значение долей данной ВМ перед её запуском. Данный процесс гарантирует, что ВМ получит количество ресурсов равное тому, которое бы она получила если бы была размещена в своём ресурсном пуле. После того как DRS поместит ВМ в соответствующий ресурсный пул ВМ снова будут возвращены её значения долей.

http://blogs.vmware.com/

Разница в функционале vSphere Client и vSphere Web client

С выходом vSphere 5.1 стандартным инструментом для управления инфраструктурой стал vSphere Web Client, классическая же версия vSphere Desktop Client больше не развивается.

Предоставляемые функции обоих клиентов немного разнятся, если какая-либо функция не приведена в списке ниже, значит она доступна в обоих версиях клиента.

vSphere Web Client

• vCenter Single Sign-On
  • Аутентификация
  • Администрирование
• Навигация с помощью Inventory Lists
• Поддержка тегов
• Work In Progress (Пауза)
• Автоподстановка при поиске
• Сохранение результатов поиска
• Улучшенная скорость чтения при использовании Inventory Service
• vSphere Replication (не SRM)
• Virtual Infrastructure Navigator
• Enhanced vMotion (без необходимости использования общего хранилища)
• Интеграция с vCenter Orchestrator (vCO) Workflows (расширенное меню)
• Virtual Distributed Switch (vDS)
  • Health Check
  • Экспорт и импорт конфигурации
  • Фильтрация диаграмм
• Плагин для просмотра логов
• vSphere Data Protection (VDP)

vSphere Desktop Client

• VMware Desktop Plug-ins (VUM, SRM, и т.д.)
• Сторонние Desktop Plugin
• Работа с VXLAN
• Возможность изменять тип и версию гостевой ОС
• vCenter Server Maps
• Создание и редактирование аттрибутов ВМ
• Прямое подключение к ESXi хосту
• Конвертация тонких дисков в толстые в Datastore Browser

 Источник: http://blogs.vmware.com/

Storage DRS и альтернативное хранилище своп файлов

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

Альтернативное расположение своп файлов

Таким хранилищем может быть как общедоступное хранилище, так и локальные диски сервера. Хочу отметить, что второй вариант влияет на производительность vMotion из-за необходимости копирования своп файла на целевой датастор конечного хоста. Вместе с тем, может использоваться небольшой датастор, доступный всем хостам в DRS кластере. В таком случае имеет смысл использовать небольшой пул SSD дисков, что позволит уменьшить влияние падение производительности ВМ из-за свопа памяти на диск в случае нехватки физической памяти на сервере.

Сертификации и учебы псот

Небольшие новости авторского коллектива vAdmin.RU. Что модно учить и сдавать в этом сезоне.

Антон Жбанков:
- Закрыл трек EMC Cloud Architect со сдачей экзамена Cloud Infrastructure & Services, базовый уровень по облачным архитектурам
- В планах сдача CompTIA Security+, VCP Cloud, VCAP Cloud, обновление сертификации по Hyper-V R3
- Учеба на бета курсе по vCloud Director 5.1

Константин Введенский:
- Успешно сдал VCAP DCD 5, ожидаем результат VCAP DCA 5
- В планах сдача VCP Cloud

P.S. коллеги, не зевайте. На мероприятиях вендоров становится модным делать отдельную секцию с бесплатной сдачей экзаменов (обычно стоят 100-200$ за попытку). Так например было на EMC Forum 2012.

Изменения обработки отказов СХД в vSphere 5.1

В vSphere были добавлены два типа отказов СХД, обрабатываемых гипервизором – APD (All Paths Down) в случае выхода временного пропадания всех путей до LUN, и PDL (Permanent Device Lost) – когда LUN считается потерянным безвозвратно.

С версии 5.0 гипервизор научился отличать PDL от APD, так как в первом случае СХД отправляет инициатору соответствующие SCSI команды о том, что LUN удалён и данные с него соотв. недоступны. Таким образом, vmkernel знает, что IO запросы к данному LUN можно сразу отбрасывать, а не ждать ответа (что в конечном итоге могло привести к зависанию корневого процесса hostd).

В vSphere 5.1 представлены новые параметры для управления поведением гипервизора при потере доступа к хранилищу данных. Опция Misc.APDHandlingEnable указывает механизм обработки какой версии 5.0 (0) или 5.1 (1) необходимо использовать, и количество попыток передачи IO к массиву.

В случае использования нового механизма операции ввода-вывода будут отбрасываться со статусом NO_CONNECT через 140 секунд после того как ESXi обнаружит что массив не доступен. Изменять этот таймаут позволяет опция Misc.APDTimeout. Как только один из путей к массиву будет восстановлен – ESXi продолжит передавать данные.

Некоторые массивы используют схему 1 target – 1 LUN. Если на таком массиве удалить LUN, то массив не будет возвращать SCSI команды о том, что LUN не доступен. С версии 5.1 гипервизор способен проанализировать ответ массива и определить, что СХД сбрасывает попытки подключения именно по причине недоступности целевого target, после чего присваивает ему состояние PDL и прекращает попытки подключения.

А что делает VMware, кроме Workstation?

Часто, очень часто на форумах задают вопрос типа "а как в VMware можно?". В 85% случаев имеется в виду Workstation, в оставшихся 15 - Server. Но VMware делает помимо Workstation и Server еще целую кучу продуктов.

Решил написать краткий обзор, а что же есть еще?

Прежде всего, это платформы виртуализации.

• VMware Server - бесплатная серверная платформа, гипервизор 2го типа (Win + Lin). 

vSphere (в прошлом Virtual Infrastructure) – это общее имя продуктов серверной виртуализации от VMware.

• ESX / ESXi (VMware Hypervisor) - гипервизор первого типа, с версии 5.0 доступен только ESXi
• VMware Go Pro – веб-сервис для упрощенной установки и управления ESXi в малых инфраструктурых
• vSphere Storage Appliance – виртуальная СХД для vSphere, использующая локальные диски хостов vSphere

Практически все остальные продукты направлены на обслуживание vSphere и добавляют различный функционал к ней.
Семейство vCenter

• vCenter Server - сервер централизованного управления ESX/ESXi серверами и виртуальными машинами
• vCenter Orchestrator - средство для автоматизации на основе workflow, позволяетделать интерфейсы самообслуживания для сотрудников, у которых нет прямого доступа к vSphere
• Update Manager - централизованный патчинг серверов ESX/ESXi 
• vCenter Converter – конвертер виртуальных машин, средство миграции физических машин в среду vSphere
• Data Recovery – виртуальный модуль для резервного копирования ВМ, предназначен для малых инфраструктур. С версии vSphere 5.1 заменен на
• Data Protection - виртуальный модуль для резервного копирования ВМ, предназначен для малых инфраструктур. На базе EMC Avamar
• Auto Deploy – ESXi теперь может быть совсем бездисковым и загружаться по PXE
• Cisco Nexus 1000v – виртуальный сетевой коммутатор от Cisco, расширяющий сетевые возможности vSphere
  
• vCenter Server HeartBeat – кластерное решение для vCenter Server, лицензированная технология от Neverfail
• vCenter Operations Manager – решение для анализа, визуализации и мониторинга инфраструктуры 
• vCenter Operations Manager for View -  решение для анализа, визуализации и мониторинга инфраструктуры виртуальных рабочих столов
• vCenter Lab Manager – продукт для компаний-разработчиков ПО. Направленность - управление гигантским количеством снапшотов для отладки и тестирования. Увы, жизненный цикл его подошел к концу.
• vCenter Application Discovery Manager – исследование инфраструктуры на предмет приложений и сервисов, построение зависимостей сервисов друг от друга
• vCenter Site Recovery Manager – автоматизирует восстановление инфраструктуры при катастрофах (полная недоступность ЦОД)
• vCenter Chargeback Manager - биллинг виртуальной инфраструктуры
• vCenter AppSpeed - контроль за работой приложений и соблюдением SLA на vSphere. К сожалению, данный продукт уже устарел. Заменой является vFabric Application Performance Manager.
• vCenter CapacityIQ - контроль мощностей инфраструктуры, анализ и предсказание роста потребления ресурсов. Интегрирован в Operations Manager, и более недоступен как отдельный продукт
• vCenter Configuration Manager – мощное средство управления конфигурациями ВМ, физических серверов и десктопов 
• vCenter Infrastructure Navigator - компонент Operations Manager отвечающий за автоматическое обнаружение сервисов, построения карт зависимостей и построения карты инфраструктуры
• vCenter Protect - централизованный патчинг операционных систем виртуальных машин и антивирус
• VMware vCenter Protect Update Catalog - расширение возможностей MS SCCM по установке обновлений для приложений.

Семейство vCloud

• vCloud Director – превращаем виртуализованный датацентр в облачный, в том числе и для создания публичного IaaS облака
• vCloud Request Manager – автоматизированное управление заявками на развертывание новых сервисов или изменение существующих в vCloud. Увы, данный продукт больше не поддерживается и не доступен для использования.
• vCloud Express – готовые публичные облака на базе VMware vCloud – подключайтесь и пользуйтесь!

Любите управлять инфраструктурой при помощи скриптов и командной строки?

• vSphere PowerCLI - управление vSphere из командной строки при помощи PowerShell
• vSphere CLI - управление vSphere из командной строки
• vSphere Management Assistant - модуль (appliance) для хостинга скриптов и агентов
• Project Onyx - генерация кода для захваченных действий в vSphere Client

Семейство продуктов vCloud Networking and Security (до версии 5.1 - данное семейство носило имя vShield) для обеспечения безопасности виртуальной инфраструктуры:

• App - сетевая защита приложений в виртуальной инфраструктуре
• Data Security – система класса DLP (Data Leakage Prevention) на базе технологий RSA
• Edge - пограничый шлюз для виртуальной инфраструктуры
• vShield Endpoint - антивирусная защита виртуальной инфраструктуры.
• vShield Zones - базовая сетевая защита виртуальной инфраструктуры (включена в лицензию vSphere). 

Что VMware предлагает для клиентских устройств и конечных пользователей?

• VMware View - VDI платформа от VMware
• VMware ThinApp - виртуализация приложений
• Workstation / Player – легендарная десктопная платформа для PC (Win + Lin), гипервизор второго типа
• ACE (Assured Computing Environment) - средство создания доверенных ВМ в непроверенном окружении. Увы, данный продукт уже не поддерживается.
• Fusion – запускаем Windows в виртуальной машине на Apple MacOS X
• VMware Horizon Application Manager – управление облачными SaaS приложениями
• VMware MVP (Mobile Virtualization Platform) - средство управления корпоративными мобильными устройствами 
• Mirage - управление физическиими устройств (ПК, ноутбуки и т.д.)
• VMware Zimbra - платформа коллективной работы, аналог Microsoft Exchange 
• Socialcast by VMware - корпоративная социальная сеть
• SlideRocket - сервис по публикации медиа презентаций.

Дополнительные инструменты

• Service Manager - система управления IT согласно ITSM (End of Life)
• IT Business Management Suite - комплексная система управления IT
• VMware Capacity Planner - средство исследования загрузки ресурсов в гетерогенных средах (доступно только для партнеров)
• Compliance Checker for PCI - средство для проверки серверов на соответствие PCI DSS 
• Compliance Checker for vSphere - средство для проверки серверов на соответствие vSphere Hardering Guide
• Open Virtualization Format Tool - средство для создания ВМ в формате OVF
• VMware Studio - средство для создания виртуальных модулей (Virtual Appliance)
• VMware VMmark - бенчмарк для виртуальной инфраструктуры
• SUSE Linux Enterprise Server for VMware - бесплатная версия Linux для всех клиентов VMware.

Платформа облачных приложений – семейство vFabric

• vFabric Enterprise Ready Server – готовый и преднастроенный сервер Apache, используемый как вебсервер и балансировщик нагрузки при разворачивании vFabric
• vFabric Hyperic – средство мониторинга и анализа производительности веб-приложений
• vFabric GemFire – параллельная база данных для высоконагруженных веб-приложений
• vFabric RabbitMQ – высокоэффективная очередь сообщений
• vFabric tc Server – оптимизированный мощный сервер tomcat
• vFabric WebServer - сервер Apache, используемый как вебсервер и балансировщик нагрузки при разворачивании vFabric
• vFabric SQLFire – высокопроизводительная база данных “в памяти”
• vFabric Data Director – сервис самообслуживания для быстрого разворачивания и управлениями базами данных
• vFabric Application Director - сервис самообслуживания для быстрого разворачивания и управлениями виртуальными машинами и сервисов в них
• vFabric Application Performance Manager - контроль за работой приложений и соблюдением SLA на vSphere
• vFabric Hyperic - мониторинг производительности сервисов, ОС, оборудования
• vFabric Postgres - высокопроизводительная база данных на базе Postgres.

vRAM & vSphere 5.0

Вопрос: нужно ли обновляться до vSphere 5.1, чтобы избавиться от лицензирования по vRAM?

Ответ: нет, лицензирование по vRAM отменено как для 5.1, так и для 5.0. Обновляться можно в любой момент, который будет удобен вам.

Анонсы с VMworld 2012: vVol, vSAN, vFlash

На недавно прошедшей в Сан-Франциско конференции VMWorld были анонсированы интересные технологии в области работы с СХД, точнее с vStorage, которые VMware собирается представить в ближайшее время: Virtual Volumes (vVols), Virtual SAN (vSAN) и Virtual Flash (vFlash?). Итак, что это за названия и в каком направлении движется VMware?

Virtual Volumes или vVols

Принципы работы с SAN и NAS массивами были заложены десятки лет назад: взять кучу дисков, равномерно распределить данные между ними во избежание возможных проблем при выходе одного из дисков из строя, объединить их логические единицы и предоставить серверам. Сегодня принцип практически тот же: у вас есть LUN или «шара», куда сохраняются виртуальные диски.

Задайте себе вопрос: оптимальное ли это решение? Что если вы хотите реплицировать ВМ? Тогда вам нужно реплицировать весь LUN. Выхода из данной ситуации два: создать LUN достаточный чтобы положить туда нужное количество ВМ и реплицировать их все сразу, или создать под каждую ВМ один LUN и, таким образом, получить требуемую частоту репликации. Оптимального решения нет. Или всё таки есть? Идеально иметь одну точку для подключения всех ВМ, и уйти от идеи с LUN или разграничением доступа (share).

Лучшие сертификации и навыки в ИТ.

Недавно наткнулся на статью Randy Muller (Global Knowledge Instructor, MCT, MCSE, MCSA, MCDST) - 15 Top Paying IT Certifications for 2012.
И она заставила меня задуматься. Как человек, который регулярно ищет сотрудников, нанимает их, а также менторит, я решил подкинуть дровишек в костер обсуждений “Какой сертификат дает большую зарплату” по мотивам обращений ко мне рекрутеров (внешние или внутренние) за кандидатами. Попробую разбить статью на части, но непосредственно в деньги углубляться, пожалуй, не буду.
Disclaimer: Вы можете решить, что это вендорский перекос в большом выборе сертификаций, но поверьте, это не только МОИ слова. Это слова бесчисленного количества нанимающих менеджеров в индустрии. И поверьте, если у вас будут эти сертификаты, то ваш аккаунт в LinkedIn просто взорвется от количества возможностей и вакансий. Не шутка.

Лучшие сертификаты для начально-среднего уровня

• MCP (Microsoft Certified Professional)
• CCENT (Cisco Certified Entry Networking Technician)
• VCP (VMware Certified Professional)
• A+, Network+, Security+ (Ладно, на самом деле ЛЮБОЙ сертификат CompTIA)
• EMCISM (EMC Information Storage and Management)

Если вы только начинаете свою карьеру в ИТ, то в зависимости от вашей специализации, эти сертификации помогут вам выстроить как доверие к вам, так и ваш набор навыков, безусловно требуемый для движения вверх. Большинство из них недостаточно “продуктовые”, но тем не менее, они предоставляют достаточный базовый “административный” уровень в Microsoft, сетевых технологиях, виртуализации VMware и т.д. И да, если имеете достаточные навыки, но не имеете сертификата – ситуация ничуть не хуже. За одним исключением – придется доказывать свои навыки на каждом собеседовании. Поэтому просто идите и сдайте тест.

Комбинирование разных типов affinity rules

Недавно заказчик спросил меня можно ли комбинировать affinity rules типа VM-host и VM-VM anti-affinity rules, какое влияние это окажет на систему и какие минусы такого решения.

Пример сценария
В данном примере две ВМ являют собой одно приложение, кластеризованное на уровне  приложения. ВМ 1 и 2 предоставляют сервис для  App-cluster1, точно также настроены  App-cluster2 и App-cluster3. Вычислительный кластер состоит из 6 хостов. Требование заказчика состоит в том, чтобы каждое кластеризованное приложение работало на собственных физическах серверах. Также разные приложения не должны размещаться на одном физическом сервере за исключением ситуаций обслуживания серверов. Виртуальные машины одного кластера приложений не могут работать на одном сервере.

Построение кластеров. Clouds NN 2012

23-24 августа я выступал на Clouds NN 2012 с темой "Как строить геораспределенные облака". Получилась, на мой взгляд, отличная презентация на тему видов кластеров.

* Для управления необходимо кликать по слайду, или жать пробел - слайды с анимацией.

Польза правильного сайзинга ВМ

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

В кластере с большим количеством ВМ с избыточным уровнем переподиски также развёрнут сервер с 4 ЦПУ на котором работает БД на SQL.

На графике ниже видно, что до 24 июля среднее значение метрики CPU Ready было около 10%, а 24 числа резко скакнуло выше 30%. То есть, 30% времени виртуальная машина ждала, когда на физическом ЦПУ будут доступны ресурсы для выполнения. Приложение, работающее с данной БД испытывало серьёзные проблемы с производительностью из-за этого.

В тот же день количество vCPU было снижено с 4 до 2, и результат очевиден. Значение CPU Ready упало примерно до 1%, и оставалось на том же уровне и дальше. При этом производительность всех приложений, использующих данный БД, в том числе и vCenter Server, серьёзно выросла.

 

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

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

Отдельно хотелось бы отметить, что лично я считаю, что данная ВМ могла бы использовать все преимущества и от 4 vCPU, но не в кластере с таким высоким уровнем борьбы за ресурсы.

Теперь вы верите в правильный сайзинг ВМ?

Как работает Storage IO Control (SIOC)

В vSphere есть отличная функция Storage IO Control, которая используется для предотвращения захвата всей пропускной способности одной виртуальной машиной или хостом. Для определения момента захвата ресурсов одним источником SIOC мониторит задержки работы СХД, и после определённого порога урезает глубину очереди к массиву.

Вопрос в том, какие именно метрики задержек отслеживаются SIOC - среднее время ответа устройства (DAVG), время ответа ядра (KAVG) или задержки ВМ (GAVG)?

На самом деле ни одна из них. Все они являются локальными метриками планировщика ресурсов, которые и отвечает за отправку всех запросов к СХД. Основная же задача SIOC - управлять ресурсами общей СХД между несколькими ESXi хостами, предоставляя IO ресурсы для всех ВМ независимо от того на каком хосте они работают. И так как SIOC должен регулировать и приоритезировать доступ к общему хранилищу нескольких ESXi хостов, локальные метрики хоста игнорируются. Но какие же, в таком случае, используются метрики? По сути, пороговое значение сравнивается со средним значением DAVG на каждом хосте и средним количеством IOPS на хосте.

vSphere Admission Control

Когда мы говорим про контроль доступа, или же admission control, мы обычно имеем в виду политики HA, хотя это не единственная функция, использующая контроль доступа. DRS, Storage DRS, да и сами ESXi хосты имеют свой собственный механизм контроля доступа. Предлагаю детально взглянуть на то, чем же является механизм контроля доступа, и какое участие он принимает в запуске виртуальной машины.

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

Параметры DRS кластера MinGoodness и CostBenefit

В VMware KB есть статья о настройке таких параметров DRS кластера как MinGoodness и CostBenefit. Обычно после перезагрузки хоста или перевода его в/из режима поддержки DRS ещё какое-то время не перемещает на него ВМ, и сервер работает вхолостую. С помощью данных параметров эту опцию можно выключить, а также заставить DRS более агрессивно мигрировать ВМ между хостами. Вместе с тем, эти параметры были сделаны тоже не просто так, и я не рекомендую изменять эти параметры, и вот почему.

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

Изменения в обработке отказа СХД в vSphere 5.0 U1

О том какие бывают типа отказа СХД и чем отличает APD от PDL можно прочитать в данной статье.

В vSphere 5.0 НА никак не реагировал на изменения состояние СХД, и если у ВМ пропадал доступ к данным считалось, что так и должно быть, и ВМ продолжит работать или будет перезапущена администратором после решения проблем с СХД.

В vSphere 5.0 U1 был представлен новый механизм, который позволяет менять поведение НА в случае потери доступа (PDL) к массиву. Управлять реакцией НА в можно с помощью двух опций: disk.terminateVMOnPDLDefault, параметры которой редактируются в файле /etc/vmware/settings, и das.maskCleanShutdownEnabled, параметры которой редактируются в расширенных свойствах НА кластера.

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

Также при наступлении аварийной ситуации в логе vmkernel будут появляться следующие сообщения:

2012-03-14T13:39:25.085Z cpu7:4499)WARNING: VSCSI: 4055: handle 8198(vscsi4:0):opened by wid 4499 (vmm0:fri-iscsi-02) has Permanent Device Loss. Killing world group leader 4491
2012-03-14T13:39:25.085Z cpu7:4499)WARNING: World: vm 4491: 3173: VMMWorld group leader = 4499, members = 1

Оригинал: Duncan Epping

Я знаю отличную шутку про...

1. Я знаю отличную шутку про UDP, но не факт, что она до вас дойдет.
2. Я знаю отличную шутку про TCP, но если она до вас не дойдет, то я повторю.

3. А кто знает отличную шутку про ARP?
4. А вы слышали шутку про ICMP?
5. Вам еще кто-то рассказывал шутку про STP?
6. Я подожду Антона и расскажу классную шутку про QoS.
7. Про MTU тоже есть кла
8. <шутка><смешная/><про>XML</про></шутка>
9. А про FSMO роли шутить могут не более пяти человек.
10. Подождите все, я расскажу шутку о сети типа "шина".
11. Я бы рассказал отличную шутку про Token Ring, но сейчас не моя очередь.
12. Стой-стой, послушай сначала шутку о прерываниях.
13. Помню времена, когда шутка про модем пшшшшшшш.....
14. Только что, специально для сообщества пришла шутка про мультикаст.
15. Жаль, что шутка про Fault Tolerance не может состоять больше, чем из одного слова.
16. Настало время рассказать шутку про NTP.
17. Я сейчас расскажу отличную шутку про VPN, но ее поймет только один.
18. К шутке про SCTP вначале должны все подготовиться.
19. Из-за одного, кто зевнул, придётся заново рассказывать шутку про frame relay в топологии point-to-multipoint.
20. А шутки про HDLC обычно не понимают те, кто знает другие шутки про HDLC.
21. Про DWDM шутят сразу несколькими голосами.
22. Шутка про Е3 - это 30 одинаковых шуток про Е1 и еще две шутки, понятных только тем, кто в теме.

Облака и RCCPA

Мы сделали это!

В России создана Russian Cloud Computing Professional Association (RCCPA) – первое профессиональное объединение независимых экспертов, работающих в области создания, развития и внедрения «облачных» технологий и сервисов. Ассоциация создана в марте 2012 года группой активистов «облачного» рынка. Наши основные цели - выработка единых подходов к формированию развития «облачных» вычислений в России и формирование экспертной площадки для развития российских “облачных” проектов на международных рынках. В планах ассоциации – регулярное проведение встреч, семинаров и конференций, в рамках которых члены ассоциации смогут обмениваться опытом по профильным вопросам.  Мы открыты для сотрудничества, членство и участие в мероприятиях ассоциации бесплатно.

Ждем вас в ассоциации - специалистов по дизайну виртуализованных инфраструктур, превращению железа в облако и продажам облачных услуг. Приходите на CloudConf 2012, где мы будем вручать первую в России премию за достижения в облачных вычислениях - Cloud Award 2012. Ну а я буду участвовать в зажигательном круглом столе "Облачная жесть как она есть" и рассказывать об особенностях облачного хранения данных.

А в этом блоге появляется новая тематика: облака :)

И в качестве начала новых, облачных дискуссий, предлагаю вашему вниманию перевод стандарта NIST по облачным вычислениям. Замечания и критика приветствуются!

Что лучше: Etherchannel и IP Hash или Load Based Teaming?

Споры что лучше - Etherchannel или LBT ведутся с тех пор, как последний механизм балансировки нагрузки появился в vSphere 4.1. Основная причина споров состоит в том, что администраторы или не знают о существовании LBT, или же думают, что сетевой стек у vSphere работает как и у физических серверов - один интерфейс активен, а все остальные простаивают до момент выхода активного из строя.

Варианты тиминга сетевых интерфейсов в vSphere

С самого начала хочу отметить, что vNetwork Distributed Switch (vDS) поддерживает пять разных режимов тиминга, но не поддерживает  LACP (802.3ad) или же Dynamic Etherchannel, поддерживается только Static Etherchannel. Для использования LACP необходимо использовать Cisco Nexus 1000V или какой-либо другой сторонний vDS.

Итак, vSphere поддерживает следующие режимы работы:

Использование одного Storage DRS кластера c несколькими DRS кластерами

Во-первых, такая конфигурация полностью поддерживается VMware. Во время создания ВМ администратор выбирает в каком DRS кластере будет работать ВМ, а Storage DRS кластер, в свою очередь, сервер который может предоставить наибольшее количество ресурсов для виртуальной машины в данном кластере. Рекомендованные миграции, генерированные Storage DRS, не мигрируют ВМ на уровне физического хоста, так как виртуальная машина не может быть перемещена между DRS кластерами по запросу от Storage DRS кластера.

При таком дизайне также необходимо учитывать максимумы конфигураций: в Storage DRS кластер может входить до 32 датасторов, к одному датастору может быть подключено до 64 хостов одновременно, а максимальное количество LUN подключённых к хосту - 255 или же 1024 пути, при использовании multipathing.

Также рекомендуется использовать СХД с поддержкой VAAI или же включать данную технологию, если она поддерживается, так как один из примитивов - Hardware assisted locking или Test and Set (ATS) заменяет SCSI-2 резервирование, что позволяет значительно увеличить скорость работы. Разница между SCSI-2 резервированием и ATS состоит в том, что первый метод блокирует весь LUN при обновлении метаданных или увеличении размера файла, а второй только требуемые сектора, таким образом, позволяя другим хостам использовать данный LUN не ожидая пока будет снято резервирование. Дополнительную информацию о резервировании вы можете найти в КВ 1021976.

При использовании IO Metric для всех датасторов в кластере автоматически включается SIOC (Storage IO Control). Storage DRS использует IO инжектор SIOC для определения производительности СХД, а SIOC используется для равномерного распределения нагрузки в периоды нехватки ресурсов.

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

Оригинал: http://frankdenneman.nl/

Cравнение протоколов доступа к СХД

	iSCSI	NFS	FC	FCoE
Описание	Протокол блочного уровня. Все SCSI команды инкапсулируются в TCP/IP пакеты и передаются на СХД	Протокол файлового уровня. NFS массив предоставляет доступ ESX хосту к своей локальной файловой системе. ESX хост же обращается к метаданным и файлам используя протокол основанный на RPC. В данный момент поддерживается NFS v3 поверх TCP/IP	Протокол блочного уровня. Все SCSI команды инкапсулируются в FC фреймы	Протокол блочного уровня. Все SCSI команды инкапсулируются в Ethernet фреймы. Во многом схож с Fibre Channel. Поддерживается с vSphere 5
Возможности реализации	1. vSphere vmkernel (обычная сетевая карта) 2. Dependent iSCSI Initiator (сетевая карта с функциями SCSI Offload+vmkernel) 3. Independent iSCSI Initiator (отдельный HBA адаптер)	vSphere vmkernel (обычная сетевая карта)	Выделенный HBA адаптер. Для отказоустойчивости и поддержки multipathing требуется минимум 2 адаптера	1. Hardware Converged Network Adapter (CNA) 2. Software FCoE инициатор (требуется сетевая карта с поддержкой FCoE)
Производительность	1. Поддерживается 1Gbit\10Gbit Ethernet. 2. Несколько соединений могут быть объединены в одну сессию. 3. Поддержка Jumbo Frames. 4. Более высокая нагрузка на ЦПУ за счёт инкапсуляции трафика	1. Поддерживается 1Gbit\10Gbit Ethernet. 2. Не смотря на возможность использования UDP, VMware её не поддерживает. 3. Поддержка Jumbo Frames. 4. Более высокая нагрузка на ЦПУ за счёт инкапсуляции трафика	1. Поддерживается 1/2/4/8 и 16Gb HBA, но последние в vSphere 5 должны работать в режиме 8Gb. 2. Buffer-to-Buffer и End-to-End кредиты гарантируют сеть без потери пакетов. 3. Низкая нагрузка на ЦПУ, так как HBA инкапсулирует весь трафик	1. Требует 10Gb Ethernet. 2. Требует поддержки Jumbo Frames (стандартный размер пакета FC – 2.2KB, а не 1.5 как у Ethernet). 3. Меньшая нагрузка на сеть, по сравнению с iSCSI и NFS, так как нету инкапсуляции SCSI в TCP\IP
Балансировка нагрузки	VMware Pluggable Storage Architecture (PSA)поддерживает Round-Robin для распределения нагрузки между путями. Лучше использовать с большим количеством LUN	В данный момент такой возможности не существует, так как используется только одна сессия. Агрегация каналов может быть достигнута путём подключения по разным путям	VMware Pluggable Storage Architecture (PSA)поддерживает Round-Robin для распределения нагрузки между путями. Лучше использовать с большим количеством LUN	VMware Pluggable Storage Architecture (PSA)поддерживает Round-Robin для распределения нагрузки между путями. Лучше использовать с большим количеством LUN
Отказоустойчивость	Отказоустойчивость обеспечивается с помощью Storage Array Type Plugin (SATP) для всех поддерживаемых iSCSI массивов	NIC Teaming. Хотя данный метод не защищает от сбоев на стороне хранилища	Отказоустойчивость обеспечивается с помощью Storage Array Type Plugin (SATP) для всех поддерживаемых FC массивов	Отказоустойчивость обеспечивается с помощью Storage Array Type Plugin (SATP) для всех поддерживаемых FCoE массивов
Проверка на наличие ошибок	Протокол использует TCP, который пересылает пакеты в случае потери пакетов	Протокол использует TCP, который пересылает пакеты в случае потери пакетов	FC является сетью с гарантией сохранности данных. Обеспечивается благодаря Buffer-to-Buffer и End-to-End кредитам и регулированием полосы пропускания в случае нехватки ресурсов	FCoE требует использования сети с гарантией сохранности данных. Достигается использованием механизма Pause Frame в случае нехватки ресурсов
Безопасность	Авторизация, в том числе и двусторонняя, обеспечивается протоколом Challenge Handshake Authentication Protocol (CHAP). Рекомендуется использовать VLAN или выделенные сети для разделения трафика	Рекомендуется использовать VLAN или выделенные сети для разделения трафика	Некоторые свитчи поддерживают VSAN, являющуюся аналогом VLAN. Также рекомендуется использовать зонинг между массивов и хостами	Некоторые свитчи поддерживают VSAN, являющуюся аналогом VLAN. Также рекомендуется использовать зонинг между массивов и хостами
Поддержка Virtual API for Array Integration	Поддержка определённых примитивов зависит от производителя. Всего доступны следующие примитивы: Atomic Test/Set, Full Copy, Block Zero, Thin Provisioning, Unmap. Все они интегрированы в ESXi и не требуют установки дополнительных элементов	Поддержка определённых примитивов зависит от производителя. Всего доступны следующие примитивы:Full Copy (не поддерживается для Storage vMotion, только для холодной миграции), Write Zeros, Clone Offload. Требуется плагин для ESXi от производителя массива	Поддержка определённых примитивов зависит от производителя. Всего доступны следующие примитивы: Atomic Test/Set, Full Copy, Block Zero, Thin Provisioning, Unmap. Все они интегрированы в ESXi и не требуют установки дополнительных элементов	Поддержка определённых примитивов зависит от производителя. Всего доступны следующие примитивы: Atomic Test/Set, Full Copy, Block Zero, Thin Provisioning, Unmap. Все они интегрированы в ESXi и не требуют установки дополнительных элементов
Загрузка ESXi с СХД	Да	Нет	Да	Да для CNA, нет для software initiator
Поддержка Raw Device Mapping	Да	Нет	Да	Да
Максимальный размер datastore	64ТБ	Зависит от производителя массива	64ТБ	64ТБ
Максимальное количество устройств	256	по умолчанию 8, максимально 256	256	256
Прямое подключение СХД в ВМ	Да, с помощью инициатора в ВМ	Да, с помощью клиента в ВМ	Нет, но FC устройства могут быть подключены к ВМ с помощью NPIV. Требует предварительного подключения RDM и поддержки NPIV со стороны оборудования	Нет
Поддержка Storage vMotion	Да	Да	Да	Да
Поддержка Storage DRS	Да	Да	Да	Да
Поддержка Storage I/O Control	Да, с vSphere 4.1	Да, с vSphere 5.0	Да, с vSphere 4.1	Да, с vSphere 5.0
Поддержка MSCS в ВМ	VMware не поддерживает такую конфигурацию, если ВМ хранятся на iSCSI массиве. Если iSCSI LUN подключён напрямую в ВМ, то такая конфигурация поддерживается Microsoft.	Нет	Да	Нет
Сложность настройки	Средняя. Необходимо знать FQDN или IP адрес массива. Может быть необходима настройка подключений инициатора со стороны массива. Сразу после обнаружения LUN доступен для форматирования под VMFS или подключения как RDM	Низкая. Необходимо знать FQDN или IP адрес массива и точка монтирования. Сразу после обнаружения массив доступен для работы	Высокая. Включает в себя зонирование со стороны свитча и маскирование LUN со стороны хоста. Сразу после обнаружения LUN доступен для форматирования под VMFS или подключения как RDM	Высокая. Включает в себя зонирование со стороны свитча и маскирование LUN со стороны хоста. Сразу после обнаружения LUN доступен для форматирования под VMFS или подключения как RDM
Преимущества	Не требует использования дополнительного оборудования, можно построить используя существующие ресурсы. Хорошо известный и зрелый протокол. Администраторы с небольшими знаниями о сетях смогут без проблем подключить массив. Проблемы решаются использованием стандартных инструментов типа Wireshark	Не требует использования дополнительного оборудования, можно построить используя существующие ресурсы. Хорошо известный и зрелый протокол. Администраторы с небольшими знаниями о сетях смогут без проблем подключить массив. Проблемы решаются использованием стандартных инструментов типа Wireshark	Хорошо известный и зрелый протокол. Используется в большинстве критически важных инфраструктур	Позволяет строить конвергированные сети, консолидируя трафик разных в одной сети, используя CNA. Благодаря использованию протокола DCB (Data Center Bridging ) FCoE является протоколом без потери пакетов не смотря на то, что работает поверх Ethernet.
Недостатки	Невозможность маршрутизации при использовании iSCSI Binding. Возможны проблемы с безопасностью из-за отсутствия встроенных механизмов шифрования, необходимость использовать VLAN. Software iSCSI инициатор повышает нагрузку на ЦПУ. TCP повышает задержки	Так как используется только одна сессия на подключение, настройка при использовании multipathing требует аккуратности и внимания. Нету PSA multipathing. Возможны проблемы с безопасностью из-за отсутствия встроенных механизмов шифрования, необходимость использовать VLAN. VMware все еще использует NFS v3, хотя доступны v4 и v4.1. NFS повышает нагрузку на ЦПУ. TCP повышает задержки	Не поддерживается FC 16Gb. Необходимо дополнительное оборудование - свитчи, HBA и т.д. Сложность в поддержке. Сложность в решении проблем.	Новый протокол, и не такой зрелый, как остальные. Требует lossless 10Gb Ethernet. Для маршрутизации используются не механизмы IP, а свой протокол - FIP (FCoE Initialization Protocol). Возможны сложности в решении проблемы из-за использования одного канала для всех видов трафика

В таблицу специально не включён протокол AoE (ATA over Ethernet) из-за своей непопулярности и небольшого количества реализаций.  

Кастомизируем образ ESXi и скриптуем инсталлляцию ESXi от EMC Proven

Канал EMCProvenSolutions радует новым видео.

VMware vSphere 5 - Using Image Builder To Create Custom ISO

Scripted ESXi Installation

Дед vAdmin

Перед Новым годом, как вы помните, я решил побыть Дедом vAdmin'ом и подарить немного подарков вместе с Iomega.

Iomega® ScreenPlay® MX получил Идрис Кубатаев.

Wireless iConnect Station отправилась в Киев к Кириллу Сухоставскому.

Поздравляем!

В чем разница между CPU Ready и %RDY?

Самым важным ресурсом для виртуальной машины является ЦПУ. И если администратор сталкивается с падением производительности у какой-либо ВМ, то для тонкого траблшутинга производительности очень удобно пользоваться командной утилитой esxtop, которая все значения показывает в процентном соотношении.

В vSphere Client же, в свою очередь, показывает значения в миллисекундах. И если из документации известно, что значение %RDY не должно превышать 10, то соответствующее значение CPU Ready очень легко посчитать.

Итак, и esxtop и vClient собирают данные в реальном времени, и обновляют их каждые 20 секунд  - 20 000 миллисекунд. Таким образом, если CPU Ready за эти 20 000 мс составил 500 мс, то мы делим 500 на 20 000, и получаем значение %RDY около 3, что является прекрасным показателем. Если же CPU Ready составил 7 500, то деление 7 500 на 20 000 даст около 37.5% RDY, что ужасно для однопроцессорной виртуальной машины.

Здесь важно отметить «для однопроцессорной виртуальной машины», так как значение %RDY является суммой значений для всех ядер ВМ. То есть, если в esxtop у 4-ёх ядерной ВМ значение %RDY 20 – то для каждого отдельного vCPU оно составляет в среднем 5.

vClient же, в отличие от esxtop, позволяет просматривать значение CPU Ready как в целом, так и для каждого отдельного вЦПУ.

Оригинал: Jason Boche

IBM выпустила distributed virtual switch для vSphere 5

Буквально на днях компания объявила о выпуске собственного распределённого виртуального свитча для vSphere 5 под названием IBM System Networking Distributed Virtual Switch 5000V конкурирующего с аналогом от Cisco – Nexus 1000V.

IBM DVS 5000 заменяет собой встроенный в vSphere 5 виртуальный распределённый свитч и эмулирует аналог физического свитча от IBM.

Основными преимуществами IBM DVS 5000V являются поддержка большого количества протоколов для управления (Telnet, SSH, SNMP, TACACS+, RADIUS, и локальная командная строка), широкий набор функций (L2-L4 ACL, статическая и динамическая агрегация каналов, PVLAN, QoS и EVB) и возможность отладки с помощью протоколов SPAN, ERSPAN, sFlow, Syslog, а также мониторинг статистики ВМ.

Подробности на официальном сайте IBM.

Работа с multicast трафиком в vSphere 5

 С выходом vSphere 5 VMware также выпустила отличный документ Multicast Performance on vSphere 5.0, рассказывающий об увеличении производительности обработки multicast трафика, но при этом никак не раскрывая техническую сторону вопроса.

Когда виртуальная машина настроена на получение трафика из какой-либо multicast группы она публикует соответствующий MAC адрес через свой сетевой интерфейс, и отправляет пакет на запрашивающий добавление её в группу. Виртуальный свитч (как vSS, так и vDS) никак не изменяя пакет отправляет его на физический свитч, который на основе, и благодаря, настройкам IGMP snooping`а на уровне физического хоста определяет через какой порт отправлять какую multicast группу, а vSwitch, в свою очередь, добавляет этот MAC адрес в свою таблицу переадресации.

Когда виртуальный свитч получает multicast трафик, то он переадресовывает его виртуальным машинам, входящим в эту multicast группу. Переадресация работает, как и в случае с unicast трафиком - на основе MAC адреса получателя. Так как vSwitch отслеживает,какие именно ВМ входят в какие именно multicast группы, то трафик переадресовывается не всем ВМ и всем интерфейсам, а только необходимым.

Если виртуальная машина отправляет запрос на удаление себя из multicast группы, её MAC адрес будет удалён из таблицы переадресации, после того как неизменённый пакет будет отослан на физический свитч. Если же данная виртуальная машина была последней на данном ESXi хосте, которая получала multicast трафик, то физический свитч также удалит этот хост из списка своих интерфейсов, через которые необходимо рассылать multicast трафик.

Если виртуальная машина переезжает на другой хост с помощью vMotion, то её настройки переедут вместе с ней. Целевой хост обновит свои таблицы переадресации согласно настройкам интерфейса виртуальной машины. Чтобы избежать возможной потери трафика из-за vMotion, виртуальный свитч целевого хоста отправляет IGMP запрос в ВМ, используя её unicast MAC адрес, чтобы физический свитч сразу получил информацию о новом местоположении ВМ. Это позволяет избежать потери трафика в ожидании следующего IGMP запроса от IGMP маршрутизатора.

Обычно IGMP маршрутизатором является какой-либо роутер в сети, и требуется для работы IGMP snooping на физических свитчах, которые, в свою очередь, используют эту информацию в своих таблицах переадресации IGMP трафика, и без которой не могут обеспечить работу IGMP snooping. Маршрутизатор отправляет запрос на адрес 224.0.0.1, общую multicast группу, а все ВМ в ответ отправляют информацию о том в какие-именно multicast группы они входят. Физический свитч, получая эту информацию, обновляет свои таблицы переадресации, и начинает пересылку трафика.
NIC Teaming физических интерфейсов также поддерживается, но механизм его работы зависит от используемого способа балансировки нагрузки.

Если активны все сетевые интерфейсы, а механизм балансировки нагрузки virtual source port ID или MAC hash based, то IGMP запрос на добавление будет выслан настроенным интерфейсом, и физический свитч обновит свою таблицу переадресации, и будет отсылать multicast трафик через соответствующий порт.

Если же один или несколько интерфейсов находятся в режиме ожидания, и начинают пересылать трафик только в случае выхода из строя активного интерфейса, то vSwitch вставит в поток IGMP запрос как в случае с vMotion.

В случае использования IP hash, физический свитч видит все физические интерфейсы как один интерфейс, и не сможет отправлять multicast трафик на разные интерфейсы, так как все физические интерфейсы являются членами всех групп. Физический интерфейс, используемый для передачи трафика в vSwitch, будет выбран согласно правилам балансировки нагрузки физического свитча.

Необходимо отметить, что для правильно работы агрегации каналов с несколькими физическими свитчами они должны быть объединены в стек, чтобы ESXi их воспринимал как один.

Оригинал: Kamau Wanguhu

Storage DRS и частично подключённые массивы

В ситуации с частично подключенными массивами столько всего интересного!

Начнём с определений понятий. Для этого рассмотрим следующую ситуацию: у вас развернут кластер из определённого количества хостов с ESXi и какой-либо внешний дисковый массив.

Некоторые из LUN массива подключены ко всем хостам в кластере, а некоторые нет. Полностью подключёнными массивами/LUNами в терминологии VMware называются именно те, которые подключены ко всем серверам в кластере, а частично подключённые, соответственно, не ко всем. Эта же терминология касается и кластеров хранилищ.

Почему VMware не рекомендует использовать конфигурации с частично подключёнными датасторами?

В кластере для каждой виртуальной машины создаётся так называемый список совместимости, в котором указываются серверы, настройки которых отвечают требованиям виртуальной машины, как-то: портгруппы, датасторы, правила anti-affinity.

Основное назначение DRS и Storage DRS это обеспечение максимального количества доступных ресурсов, а требованием для этого является мобильность нагрузки между серверами. Именно исходя из этого при создании виртуальной машины DRS и SDRS генерирует рекомендации для изначального расположения ВМ.

Кроме того, если Storage DRS обнаруживает в кластере частично подключенные датасторы вперемешку с полностью подключёнными, то SDRS выключает балансировщик нагрузки (IO load balancing). А балансировщик свободного места, в свою очередь, просто игнорирует такие датасторы при расчётах.

Оригинал: Frank Denneman

Top 25 VMware blogs

Портал vSphere Land открыл очередной раунд голосования, чтобы определить 25 лучших блогов о виртуализации VMware.

При выборе фаворитов пожалуйста руководствуйтесь следующими принципами:

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

И немного информации о самом голосовании:

• Вы можете выбрать 10 ваших любимых блогов и сделать свою собственную горячую десятку. Блог #1 получит 10 очков, блог #10 - 1 очко. В конце будут подсчитаны общие результаты и блоги получат соответствующие места в итоговом списке Top25.
• Если Вы не знаете блоггеров, то можете руководствоваться vLaunchpad для ознакомления с блогами и оценки.

Ну и, конечно, голосуйте за меня :)) В списке представлен как "Virtual Admin Notes (Anton Zhbankov)"

Обработка отказа СХД в vSphere 5

К сожалению, бывают случаи, когда vSphere теряет доступ к системе хранения данных по той или иной причине. В vSphere 4 отказ доступа к СХД мог привести к непредсказуемому результату: от немедленного BSoD у высоконагруженных ВМ до нормальной работы у простаивающих серверов за счёт работы с локальным кэшем. В vSphere 5 обработка отказов СХД была существенно переработана и улучшена.
vSphere 5 теперь различает два состояния отказа LUN: отказ всех путей (APD – All Paths Down) и перманентный отказ устройства (PDL – Permanent Device Lost). Разница между APD и PDL видна в названии – в первом случае система временно не имеет доступа к LUN (например, вышел из строя свитч к СХД), тогда как во втором случае LUN был удалён из СХД.

С технической стороны разница состоит в SCSI кодах, получаемых vmkernel при попытке обращения к LUN. Детальное описание всех кодов и сообщений в логах доступно в этой статье VMware KB.

Данные о APD/PDL никак не передаются виртуальной машине, и обрабатываются на уровне гипервизора, так что если в случае APD/PDL не записанные из-за истечения тайм-аута данные будут сброшены, виртуальная машина попытается снова записать их на диск.
Гипервизор же в случае отказа всех путей к LUN будет хранить данные в кэше vmkernel вплоть до восстановления доступа к устройству, тогда как в случае с перманентным отказом устройства данные даже не будут кэшироваться, чтобы избежать ситуаций с переполнением буфера процесса hostd, что приводило к неотзывчивости системы в vSphere 4.

Нюанс обработки удаления LUN в некоторых СХД

Некоторые низкоуровневые СХД не поддерживают технологию multi LUN, и используют схему 1 LUN – 1 таргет. Если такой LUN удалить из СХД, то при обращении в ответ не будут высланы соответствующие SCSI коды и vSphere не сможет понять, что LUN удалён навсегда (PDL), а будет считать, что это временный отказ путей к хранилищу (APD).