Meltdown and Spectre

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

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

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


"Официальный" сайт с описанием найденных уязвимостей: https://meltdownattack.com

Проект Project Zero с подробным техническим описанием уязвимостей: https://googleprojectzero.blogspot.ru/2018/01/reading-privileged-memory-with-side.html

Еще технические детали от Google: https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html

Многие вендоры уже выпустили свои информационные бюллетени, ищем их на сайте уязвимости, внизу страницы есть ссылки: https://meltdownattack.com

Список ссылок на информационные бюллетени вендоров также есть на reddit:
https://www.reddit.com/r/networking/comments/7o4y40/meltdownspectre_vulnerability_tracker/

Что касается VMware

Используем только проверенные источники/первоисточники, на сайте VMware раздел с описание уязвимостей: https://www.vmware.com/security/advisories.html

Согласно VMSA-2018-0002 патчи для ESXi были выпущены еще 19 декабря 2017, их нужно устанавливать: https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html

Гостевые ОС также подвержены уязвимостям, следим за новостями у производителей ОС, ссылки есть здесь: https://meltdownattack.com

Следим за блогом VMware Security & Compliance Blog. Например, сегодня появилась информация о vRealize Operations for Horizon, vRealize Operations for Published Applications, Workstation, Horizon View Client and Tools: https://blogs.vmware.com/security

VMware выпустили статью с описанием уязвимостей в Virtual Appliances: https://kb.vmware.com/s/article/52264

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

Всем успехов!


UPD. История продолжается, прилетели новые обновления для ESXi и vCenter: https://www.vmware.com/us/security/advisories/VMSA-2018-0004.html

UPD. Патчи из VMSA-2018-0004 пока лучше не ставить:
https://kb.vmware.com/s/article/52345

UPD. Вышел новый эпизод:
https://www.vmware.com/us/security/advisories/VMSA-2018-0004.html

Восстанавливаем файловую систему загрузочного диска ESXi

Столкнулся с проблемой установки/обновления VMware Tools на машинах, работающих на одном из хостов в кластере:



С машинами, работающими на других хостах кластера такой проблемы нет, можно без ошибок установить/обновить VMware Tools.
После прочтения, предложенного в сообщении об ошибке KB Installing and upgrading the latest version of VMware Tools on existing hosts, подключился по SSH к проблемному хосту и обнаружил следующую картину:



Файловая система раздела, содержащего VMware Tools разрушена.
Первая мысль переустанавливать ESXi с нуля, но подумав пару минут, пришло осознание, ESXi все-таки Linux и должен быть путь «починить» файловую систему раздела без полной переустановки ESXi.

Возможно, данная проблема связана с KB High frequency of read operations on VMware Tools image may cause SD card corruption.
Начиная с ESXi 6.0 U3 появился дополнительный параметр, который позволяет при загрузке ESXi создать RAM диск, содержащий образы VMware Tools. Это снизит нагрузку на загрузочный диск при многократной установке VMware Tools.

Итак, первым делом выводим хост в Maintenance Mode.
Далее, нужно понять какой раздел смонтирован в папку /store (locker – это ссылка на store). Для это этого выполним команду:

vmkfstools -P /store

Обычно это 8 раздел загрузочного устройства (почему 8 раздел можно прочитать в статье Загрузка ESXi c USB/SD и что меняется, когда появляется vSAN):



Запускаем проверку диска для 8 раздела загрузочного диска:

dosfsck -a -w /dev/disks/mpx.vmhba32:C0:T0:L0:8

Бывает, что требуется ручное исправление ошибок на диске, тогда:

dosfsck -v -w -r /dev/disks/mpx.vmhba32:C0:T0:L0:8

Далее, удаляем содержимое папки /store и перезагружаем проблемный хост:

rm -r /store/*

При загрузке ESXi восстановит необходимые файлы и папки в store, но vib пакет с VMware Tools нам придется восстановить руками, можно это сделать, например, через Update Manager:




К сожалению, я сталкивался с ситуациями, когда USB/SD карты выходили из строя или «ломались» партиции на них. Вообщем, разбираться и «чинить» точно бы заняло кучу времени.
На этот случай есть возможность создания резервной копии конфигурации ESXi и последующего восстановления из нее. Все это описано в KB How to back up ESXi host configuration. Данная процедура работает и для хостов с VMware vSAN без необходимости эвакуировать данные с проблемного хоста.

Делаем резервную копию конфигурации, например, через PowerCLI:

Connect-VIServer -Server host_ip
Get-VMHostFirmware -VMHost host_ip -BackupConfiguration -DestinationPath C:\Temp

Переустанавливаем ESXi с нуля. И восстанавливаем настройки из резервной копии:

Connect-VIServer -Server host_ip
Set-VMHost -VMHost -State 'Maintenance'
Set-VMHostFirmware -VMHost host_ip -Restore -SourcePath C:\Temp\configBundle host_ip.tgz -HostUser root -HostPassword Password

Перезапуск Management agents в ESXi и терпение

Бывает такое, что ESXi отключается от vCenter, но виртуальные машины, запущенные на нем, продолжают работать, это означает, что проблема в сервисах гипервизора, отвечающих за коммуникацию с vCenter'ом (Troubleshooting an ESXi/ESX host in non responding state).



Самое очевидное решение, просто их перезапустить, но как раз в этом то может и крыться проблема.
Перезапустить hostd и vpxa (а именно эти сервисы отвечают за связь ESXi и vCenter), согласно Restarting the Management agents in ESXi, можно через Host Client (https://<esxihost>/ui/), подключившись к хосту через SSH или DCUI.
Как все легко, но обычно, когда есть проблемы с hostd и vpxa, то и Host Client перестает работать и выглядит вот так:



При этом по умолчанию SSH на ESXi хостах выключен. И соответственно остается только DCUI - радуемся, что у нас есть iDRAC, iLO, etc. или бежим к серверу.

Ну и здесь все не без проблем. Нажав F2 в DCUI и введя пароль нас ожидает новая проблема, ничего дальше не происходит, окошко логина висит, а в меню мы попасть не можем. Тут нам поможет только терпение, в таком состоянии логин может идти несколько минут, а бывает, что и 15-20 минут. Ждем.
Дождавшись входа на нужно найти пункт меню Troubleshooting Options и выбрать Restart Management Agents:



К сожалению, это не всегда помогает, иногда нужно подключится по SSH, почитать логи и выполнить какие-нибудь команды. Проще простого.
Для это нам нужно включить SSH через DCUI, выбираем пункт меню Troubleshooting Options и Enable SSH. Вот здесь нас снова ожидает большой сюрприз, DCUI перестает реагировать на клавиатуру. Это может продолжаться полчаса, а может и несколько часов. Терпение, ждем и SSH включен. Дело за малым, подключиться по SSH и выполнить команды:

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

Транспортные протоколы резервного копирования VMware

Для резервного копирования виртуальных машин используется несколько транспортных протоколов – NBD, SAN, HotAdd. 

NBD (Network Block Device) является наиболее универсальным и доступным для любых видов СХД и окружений. При его использовании поток данных с СХД проходит через гипервизор ESXi и направляется на сервер резервного копирования по локальной сети. На практике его не рекомендуют использовать, если есть возможность работы с протоколами SAN и HotAdd, превосходящими его по разным отзывам от двух до десяти и более раз по скорости передачи данных.

SAN – используется при прямом подключении сервера резервного копирования в сеть хранения данных. Для его использования серверу РК необходим прямой доступ к томам с VMFS, что накладывает требования на конфигурирование хоста и ограничение доступа к нему. Для Windows необходимо отключить автоматическую инициализацию дисков во избежание перетирания сигнатур и метаданных VMFS. И разумеется никто не хочет, чтобы чьи-то неумелые или напротив, опытные, но зловредные потерли сами данные. Возможно предварительно их утащив.

В случае с Fiber Channel сетью сервер РК должен быть физическим и физически подключен в оптическую фабрику. В процессе резервного копирования гипервизор сообщает какие блоки необходимо забирать с тома VMFS и сервер РК читает их с СХД самостоятельно. Скорость резервного копирования ограничена лишь нагрузкой на СХД и способностью сервера РК справиться с потоком данных. Влияние гипервизора в данном случае минимально.

Несмотря на очевидное преимущество SAN протокола, не все так просто. Идеальным вариантом он является только при восстановлении толстых (thick) дисков, но наихудшим для тонких из-за постоянных вызовов API дискового менеджера (AllocateBlock, ClearLazyZero). В случае восстановления тонких дисков предпочтительно использовать NBD.

Также при восстановлении по SAN необходимо отключать CBT. Также не поддерживается запись в redo логи (снапшоты), восстановление идет только базовых дисков.
Особая тонкость в том, что размер диска должен быть точно кратен размеру блоку VMFS, иначе последний блок не сможет быть записан и весь процесс упадет с ошибкой "Invalid Argument". Для обхода этой проблемы софт резервного копирования должен дописать в конец блока недостающие нули.

HotAdd – способ, при котором к специальной виртуальной машине-прокси на горячую подключаются виртуальные диски целевой виртуальной машины, после чего прокси машина пересылает данные по локальной сети на сервер РК. Прокси может выполнять компрессию и дедупликацию данных при пересылке, в зависимости от используемого продукта РК. Роль прокси и сервера РК может быть также совмещена. Несмотря на использование дискового стека гипервизора для доступа к данным, скорость на практике практически равна варианту SAN.

В случае VMFS3 располагайте прокси на томах с большим размером блока VMFS, чтобы быть в состоянии бэкапить и восстанавливать очень большие файлы. Для VMFS5 размер блока унифицирован и эта рекомендация более неактуальна.

Поскольку при работе HotAdd создаются redo логи, не удаляйте подключенную ВМ пока не завершится процесс резервного копирования. Иначе гипервизор потом не сможет правильно обработать redo логи и диски от прокси придется отключать вручную. (!) Не удаляйте снапшоты до окончания резервного копирования (!).

vVNX Community Edition

EMC опубликовала бесплатный полнофункциональный виртуальный VNX с ограничением до 4ТБ емкости. Поддерживается функционал vVols - соотв. это отличный способ попробовать их на практике.

Фактически это код от VNXe 3200, доступен в формате OVA и требует среду VMware.

http://www.emc.com/products-solutions/trial-software-download/vvnx.htm

Техническое описание VVol

Первое что хотелось бы отметить - технология называется VVol, не vVol, Vvol и прочее (от переводчика).


Традиционные системы хранения данных имеют следующие недостатки:

• Специализированное и дорогое железо - не общедоступное, стандартное оборудование, низкая утилизация и переподписка (overprovisioning);
• Архитектуру от устройства - статические уровни предоставления качества, стандартизированное выделение ресурсов, невозможность гранулярного контроля;
• Сложные процессы - недостаточность автоматизации, затратные по времени процессы, медленная скорость реакции на запросы.

Гипервизор позволяет реализовать автоматизацию СХД от приложения, так как:

• Знает все требования приложений в реальном времени;
• Является элементом пути в операции ввода-вывода;
• Видит все нижележащие СХД;
• Может динамически настраивать СХД;
• Независим от аппаратного обеспечения.

Традиционная модель - длительные циклы предоставления ресурсов, управление LUN, сложные и частые миграции данных.

Автоматизация от приложения - динамическое предоставление ресурсов СХД по мере необходимости. Контроль уровня предоставления сервиса на уровне отдельной ВМ. Общее управление разными устройствами.


vSphere Virtual Volumes

• Виртуализирует SAN и NAS устройства;
• Виртуальные диски нативно предоставляются массиву;
• Позволяют выполнять операции на уровне отдельной ВМ используя функции СХД;
• Управление хранилище на основе политик (SPBM, Storage policy-based management) позволяет автоматизировать потребление ресурсов при масштабировании;
• Широкая поддержка основнымит производителями СХД;
• Поставляется с vSphere.

Что такое VVol?

• Пять типов объектов VVols: Config, Data, MEM, SWAP, Other;
• Отсутствие необходимости использования СХД (VMFS отходит в историю);
• Объекты виртуальной машины хранятся нативно на СХД;

Контейнер массива (Storage Container)

• Логическая конструкция массива для группирования виртуальных томов;
• Обычно определяется администратором СХД на самом массиве для определения ёмкости массива и его ограничений;
• Ёмкость определяется физической ёмкостью массива.

Разница между контейнерами массива и LUN

• Размер контейнера основан на ёмкости массива;
• Максимальное количество контейнеров зависит от массива;
• Размер контейнера может быть расширен;
• LUN требует файловой системы, стандартизация размера LUN требует большего их количества.

Протокол конечной точки (Protocol End Points)

• Точка доступа реализовывающая коммуникацию между ESXi и СХД;
• На данный момент поддерживаются: iSCSI, NFS v3, FC, FCoE;
• Для каждой конечной точки единовременно поддерживается какой-то один обозначенный протокол;
• Конечная точка получает SCSI либо NFS команды;
• Контейнера массива - для большого количества метаданных и данных ВМ.

Панель управления

• VASA Provider (VP) - разрабатывается поставщиком СХД;
• Один VP может управлять несколькими массивами;
• VASA Provider может быть реализован как внутри массива, так и в виде внешней ВМ;
• Внеполосной (out of band) обмен сообщениями;
• ESXi и vCenter Server подключаются к VASA Provider.

Возможности массива и политики хранения ВМ (Storage Capabilities и VM Storage Policies)

• Являются функциями массива и требованиями ВМ к этим функциям, соответственно. Требования могут быть удовлетворены возможностями, предоставляемыми массивом;
• Возможности массива определяют что может предоставить массив в ответ на требования ВМ;
• Политики хранения ВМ являются компонентом хранилища на основе политик
• Представленные возможности - функции и сервисы массива, предоставленные гипервизору через VASA API;
• Управляются на уровне виртуального диска ВМ
• Используют концепцию соответствия для контроля предоставляемого уровня сервиса.

Сценарии операций

• Разгрузка операций: разворачивание, удаление, клонирование (полное и связанных), снепшоты;
• Снепшоты: управляемые ESXi или массивом.

В данной версии SRM не поддерживает VVol, но будет в следующей.

В будущих версиях VVol позволит пулу массива распространяться между физическими массивами.

Статья написана на основе доклада Роулинсона Риверы (Rawlinson Rivera) с VMware PEX 2015.

Оригинал: VVol Technical Overview

VMUG 2014 - Проблемы с дисками?

Моя презентация на VMUG Россия 26 июня 2014. Краткий обзор VMware Pluggable Storage Architecture и гайд по траблшутингу подсистемы хранения.

VMUG Moscow 2014 Проблемы с дисками? from Anton Zhbankov

Adaptive Queueing против Storage I/O Control

В данном посте мы рассмотрим две разные технологии vSphere по управлению глубиной очереди на ESXi хостах. Очередь определяет количество запланированных операций ввода-вывода, которые могут быть отправлены к СХД. В случае с vSphere, где обычно к одному общему дисковому устройству обращается несколько хостов, может быть полезно управлять глубиной очереди в моменты нехватки ресурсов. В данной статье мы сравним Adaptive Queues и Storage I/O Control (SIOC).

Чем эти технологии отличаются?
SIOC использует концепцию уровня перегруженности основанном на задержках доступа. По сути, если задержки на определённом datastore превысят определённый порог - включится SIOC. Этот порог может быть выставлен вручную (стандартное значение 30мс) или автоматически с помощью инжектора запросов (представлен в 5.1). В случае с адаптивным управлением очередью vSphere ждёт фактического наступления нехватки ресурсов, то есть получения от СХД в ответ на запрос команды ввода-вывода SCSI команды USY или QUEUE FULL.

Какой механизм когда работает?
Обе технологии урезают глубину очереди. В случае с SIOC каждая ВМ на datastore имеет своё значение долей (shares), при этом сами ВМ могут быть на разных хостах. Когда порог превышен доступ к LUN начинает контролироваться путём управления глубиной очереди для каждого отдельного хоста, но при этом учитываются доли каждой отдельной ВМ. Возьмём, к примеру, два хоста с двумя ВМ на каждом. Если доли ВМ на первом хосте будут по 1000, а на втором по 2000, то второй хост сможет отправить в два раза больше команд в момент нехватки ресурсов. Как только ситуация нормализуется - все хосты и ВМ смогут отправлять данные без ограничений глубины очереди, и SIOC перестанет ограничивать ресурсы.

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

Когда какая технология была представлена?
SIOC впервые был представлен в vSphere 4.1 для блочных устройств и в vSphere 5.0 для NAS. Адаптивное управление очередью - в ESX 3.5U4.

Как включить данные технологии?
SIOC включается в свойствах каждого отдельного хранилища. По умолчанию данная функция выключена. Данная функция доступна только в редакции Enterprise+.

Для включения адаптивного управления очередью необходимо в расширенных настройках каждого отдельного хоста перейти в раздел Disk, и изменить значение параметров Disk.QFullSampleSize и Disk.QFullThreshold. По умолчанию параметр QFullSampleSize имеет значение 0, то есть выключено, а QFullThreshold редактирует необходимое количество команд о нормализации статуса для снятия блокировки.

Итоги
Каждая функция может принести свою пользу в вашей инфраструктуре. SIOC, по сравнению с адаптивной глубиной очереди, более гибкая технология, но и доступна она только в Enterprise+. Но, в свою очередь, адаптивная очередь требует настройки на каждом отдельном хосте. Также если порты СХД используются для работы с другими ОС, не только vSphere, я рекомендую прочитать следующую статью базы данных: 1008113.

Corrupt дисковой системы. Что делать?

Рассмотрим ситуацию: достоверно известно, что случился corrupt на уровне дисковой системы. Битые сектора или что-то еще - не столь важно. Сверху живет VMFS и виртуальные машины, но в ВМ вроде ничего не случилось, они продолжают работать.
В этой ситуации вполне может быть, что битая область вообще не затрагивает ВМ и все данные остались целыми. Так что же сделать, чтобы свести риски к минимуму?

1. Выключаем затронутые ВМ.
2. Клонируем ВМ на заведомо исправный датастор.
3. Включаем клоны, запускаем проверку целостности файловой системы в каждой ВМ. Можно использовать встроенные средства ОС или использовать любой Rescue CD.

Зачем выключать? При дальнейшей работе, в особенности в случае машин с тонкими дисками и снапшотами, можем затронуть битую область и соотв. ВМ приходит в негодность.
Обратите внимание, что ВМ именно клонируем, а не перемещаем. И тем более не делаем Storage vMotion, иначе есть риск остаться наедине с резервной копией. В случае если она вообще есть.

В каких случаях трафик vMotion пойдёт по сети управления вместо vMotion

Сценарий 1: Миграция между хостами и без общего хранилища
В версии vSphere 5.1 появилась возможность одновременной миграции ВМ между хостами и датасторами. Если ВМ хранится на локальном или не общем для хостов хранилище, то vMotion использует сеть vMotion для миграции ВМ на целевое хранилище. При мониторинге сетевых интерфейсов VMkernel можно увидеть, что трафик идёт по интерфейсу управления вместо vMotion.

При миграции виртуальной машины vMotion определяет горячие и холодные данные. Активно используемые виртуальные диски и снэпшоты считаются горячими данными, тогда как нижестоящие снэпшоты и базовый диск считаются холодными данными. К примеру, представим, что у нас есть ВМ с пятью снэпшотами. Последний снэпшот считается горячими данными, и пересылается по vMotion сети, а остальные 4 снэпшота и базовый диск – холодными, и передаются по VMkernel NIC (vmk0) с помощью network file copy (NFC).

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

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

Если же у ВМ нету снэпшотов, то её диск считается горячими данными, и передаётся по сети vMotion, тогда как все остальные файлы из директории – по VMkernel сети.

Сценарий 2: Сеть управления и vMotion используют одну подсеть
Если управляющая сеть (если быть точным то первый интерфейс VMkernel) и vMotion используют одну и ту же подсеть, то vMotion будет отправлять трафик через первый интерфейс VMkernel даже если вы создадите выделенную сеть vMotion на отдельном стандартном или распределённом свитче с отдельным физическим интерфейсом. В любом случае vMotion будет обращаться к первому интерфейсу VMkernel если обнаружит совпадение подсети.

Отдельно хочу отметить, что на целевом хосте конечным интерфейсом будет интерфейс vMotion.

Я проводил онлайн исследование по результатам которого оказалось, что больше 95% респондентов используют выделенный диапазон IP адресов для vMotion сети. Тем не менее я бы хотел напомнить, что рекомендуется использовать отдельную сеть для vMotion. Сеть управления считается небезопасной сетью, и поэтому не рекомендуется использовать её для vMotion.

В случае если хост использует Multi-NIC vMotion то даже в случае использования одной подсети vMotion учитывает настройки, и использует для передачи трафика VMkernel только с активированной опцией использования для vMotion.

Если в вашем окружении используется один диапазон адресов для обоих типов сети, то я бы рекомендовал создание Multi-NIC vMotion. В случае ограниченного количества физических интерфейсов, вы можете использовать одни и тот же сетевой интерфейс для обоих VMkernel, в таком случае хоть балансировка нагрузки и не будет доступна, но VMkernel будет использовать сеть vMotion по назначению.

Источник: Frank Denneman

Горизонтальное и вертикальное масштабирование. Взгляд со стороны бизнес приложений.

К концу 2012 года более 50% приложений работающих на х86 платформе виртуализированы. Вместе с тем виртуализировано только 20% бизнес критических приложений .

Это из-за того что ИТ отделы не доверяют платформам виртуализации? Считают ли они платформы виртуализации не достаточно стабильными для поддержки работы критически важных приложений?

За последние 10 лет VMware доказала что виртуализация это уже реальность, и, фактически, виртуализированные приложения часто более стабильны, когда работают на инфраструктуре под управлением VMware.

Тогда если доверие или стабильность не являются проблемой в чём же причина того что ИТ отделы еще не виртуализировали оставшиеся приложения?

VMware Metro Stretched Cluster: вопросы из зала

Задали мне вопрос, а точнее даже два, насчет механизмов работы растянутых кластеров. Ну и соотв. как их проектировать.
Предварительное условие: растянутый метрокластер поверх EMC VPLEX.

1) Нужно ли 2 vCenter?

Ответ: нет. В метрокластере работает HA, и при падении одного из сайтов vCenter будет перезапущен на оставшемся. Разумеется, vCenter должен находиться на LUN, защищенном VPLEX.

2) Что произойдет с dvSwitch, если упадет vCenter.

Ответ: ничего. Проблема может возникнуть только, если происходит полное падение инфраструктуры, и все без исключения хосты стартуют при остановленном vCenter. В случае с падением 1 сайта все иначе - все хосты на сайте 2 уже загружены, сконфигурированы и работают без проблем. Поэтому vCenter будет просто перезапущен на сайте 2 посредством HA, и вся инфраструктура продолжит свою работу.

Как заставить ESXi5 видеть диск как SSD datastore

В vSphere 5 представлена новая функция Host Cache, которая позволяет выгрузить своп файл виртуальной машины на выделенный SSD диск для повышения производительности. Для этого на диске, который SATP (Storage Adapter Type Plugin) опознала как твердотельный, создать VMFS раздел, добавить и настроить данное VMFS хранилище для хранения кэша.

Во время тестирования vSphere 5 тестировал самые разнообразные функции, включая Host Caching, но у меня не было доступа к системе с SSD диском во время обновления и создания новых скриптов. После небольшого расследования я узнал, что стандартное правило SATP не опознаёт определённый твердотельный диск, и что можно создать новое правило, содержащее мета информацию о данном конкретном устройстве.

В данном примере я заставлю ESXi 5 думать, что локальный диск mpx.vmhba1:C0:T2:L0 является SSD диском.

Необходимо иметь доступ к esxcli, без разницы через локальную оболочку ESXi, vMA или PowerCLI.

Для выполнения дальнейших шагов диск, который будет представлен как твердотельный, уже должен быть форматирован в VMFS.

Для начала необходимо создать новое SATP правило, в котором будет указан диск, и enable_ssd как опция параметра option.

esxcli storage nmp satp rule add --satp VMW_SATP_LOCAL --device mpx.vmhba1:C0:T2:L0 --option=enable_ssd

Проверить правильность создания можно с помощью листинга всех правил

esxcli storage nmp satp rule list | grep enable_ssd

VMW_SATP_LOCAL       mpx.vmhba1:C0:T2:L0  enable_ssd                  user

Теперь необходимо перерегистрировать диск в системе, чтобы применить к нему новое правило.

esxcli storage core claiming reclaim -d mpx.vmhba1:C0:T2:L0

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

esxcli storage core device list --device=mpx.vmhba1:C0:T2:L0

mpx.vmhba1:C0:T2:L0
   Display Name: Local VMware Disk (mpx.vmhba1:C0:T2:L0)
   Has Settable Display Name: false
   Size: 5120
   Device Type: Direct-Access
   Multipath Plugin: NMP
   Devfs Path: /vmfs/devices/disks/mpx.vmhba1:C0:T2:L0
   Vendor: VMware
   Model: Virtual disk
   Revision: 1.0
   SCSI Level: 2
   Is Pseudo: false
   Status: on
   Is RDM Capable: false
   Is Local: true
   Is Removable: false
   Is SSD: true
   Is Offline: false
   Is Perennially Reserved: false
   Thin Provisioning Status: unknown
   Attached Filters:
   VAAI Status: unsupported
   Other UIDs: vml.0000000000766d686261313a323a30

Теперь параметр Is SSD имеет значение true.

Вы можете обновить Storage view в vSphere Client или через командную строку командой vim-cmd hostsvc/storage/refresh.

Теперь в vSphere Client в разделе Host Cache Configuration появится новый твердотельный диск, который необходимо добавить для использования Host Cache.

Официально это, конечно же, не поддерживается.


Оригинал: http://www.virtuallyghetto.com/

Резервирование всей памяти Виртуальной машины (all locked)

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

Настройки резервирования памяти статичны, то есть если пользователь изменит объём памяти у ВМ, то настройки резервирования останутся предыдущими. Если же необходимо, чтобы объём зарезервированной памяти всегда равнялся объёму сконфигурированной памяти - в интерфейсе, как классическом, так и вэб, есть опция Reserve all guest memory (all locked).

Это опция напрямую связана с настройками объёма памяти виртуальной машины - при увеличении объёма выделенной ОЗУ увеличиться и резерв, при уменьшении, соответственно, уменьшится.

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

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

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

Пример использования NetIO Control

Network I/O Control (NetIOC, NIOC) позволяет контролировать разделение сетевых ресурсов в случае борьбы за ресурсы. NIOC предоставляет дополнительный уровень контроля использования пропускной способности сети в виде лимитов и изоляции. Операции vMotion создают кратковременный скачок трафика, который пытается использовать максимум доступной пропускной способности сети. В конвергентной сети операция vMotion иметь деструктивный эффект на другие типы трафика. Принцип работы NetIOC позволяет каждому типу трафика предоставить гарантированную полосу пропускания учитывая, что все они борются за одну полосу пропускания. Данная статья относится к vSphere 5.1.

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

Одна из частых задач для администратора виртуальной платформы - изменение размера диска ВМ.
Вопрос: Зачем это вообще нужно, и почему нельзя создавать ВМ сразу с нужным диском?
Ответ: шаблоны. У меня лично, например, был шаблон с мааааленьким диском (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/