Комментарии и ответы

Коллеги, прошу прощения у всех, кому не было ответа на комментарии и вопросы в блоге. В потоке спама все просто потерялось.
Постараемся ответить на все.

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

Не получается подключиться к NFS на Iomega

При попытке создать NFS датастор появляется сообщение

Call "HostDatastoreSystem.CreateNasDatastore" for object "ha-datastoresystem" on ESXi "192.168.X.X" failed.NFS mount 192.168.X.X:/mnt/part2/nfs_vmware failed: Unable to connect to NFS server.

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

Проблема в том, что Iomega (в моем случае это ix4-200d) пытается отрезолвить DNS в обратную сторону. Ну а поскольку у меня все полегло после переключения питания, а DNS лежит на этой самой Iomega - замкнутый круг.

Решение:
1. Включить Support Mode на Iomega (простыми словами SSH доступ) на странице https://ix4-vadmin/support.html (заменить ix4-vadmin на IP вашей хранилки).
2. SSH на хранилку с логином root, и паролем из вашего административного пароля с добавкой soho в начале. Если пароля нет, значит просто soho.
3. Прописать в /etc/hosts имена ESXi, с которых будете подключаться
...
PROFIT!

Почему загрузка файлов на VMFS такая медленная?

Мы все видели это множество раз - залить файл на VMFS датастор занимает слишком много времени. Например, ISO с образом Windows 7 заливается 10 минут на iSCSI, и менее минуты на NFS. Оба датастора не имеют проблем и достаточно быстрые, на обоих работают ВМ.

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

Один из путей подтверждения этого - статистика VAAI для дисковых массивов с поддержкой VAAI, или статистика SCSI reservation для массивов без. В качестве простейшего примера можно использовать gzip большого vmdk файла на VMFS датасторе (множество маленьких операций чтения и записи). Даже для VAAI будет видно множество запросов ATS и ZERO:

ATS ATSF ZERO ZERO_F MBZERO/s
42052 3 61370 0 5.72

Заключаем, что gzip блокирует ресурсный блок, заполняет нулями, а затем копирует содержание. То же самое происходит при загрузке файла на VMFS как из GUI, так и из командной строки.

Автор: Cormac Hogan

Nicira Virtualization Platform. NVP Manager

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

Роль NVP Manager
NVP была разработана так чтобы интегрироваться с самыми разнообразными платформами управления облаком (CMP) с помощью набора «северных» API. Фактически эти REST API реализованы в контроллерах NVP, а не NVP Manager. Менеджер предоставляет вэб интерфейс, используемый для следующих задач:

Добавление гипервизоров
Добавление транспортных нод (шлюзы и сервисные ноды)
Настройку транспортных зон
Сбор информации и отладка

NVP Manager ориентирован на настройку, а не обеспечение работоспособности NVP. Другими словами – данный компонент вы будете использовать для управления компонентами платформы NVP – шлюзами, гипервизорами, но фактическое использование возможностей NVP, создание логических сетей, логических маршрутизаторов и тому подобное, будет происходить из CMP через вызовы к REST API к контроллерам. Таким образом, я буду использовать NVP Manager для выполнения некоторых задач, которые должны выполняться в CMP, но просто потому что под рукой у меня нету CMP.

Итак, разобравшись с ролью данного компонента перед к процессу установки и настройки.

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

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

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

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

Nicira Virtualization Platrform. Контроллеры NVP

Во второй части цикла о платформе виртуализации сети от VMware я расскажу о контроллерах. Напомню, что они нужны для расчёта сетевой топологии, распространения настроек и создания логических сетей и логики распространения трафика внутри неё. Для этого контроллеры на «южную» сторону, Open vSwitch (OVS) устройства, распространяют необходимую информацию, полученную с «северного» NVP API, чем обеспечивают соответствие между логическими сетями, согласно данным полученным NVP API и транспортной сетью, обеспечиваемой программируемыми виртуальными пограничными устройствами.

Детальнее это выглядит так:

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

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

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

Итак, разобравшись с ролью контроллеров перейдём к процессу сборки контроллеров.

В каких случаях трафик 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

Курс EMC Cloud Architect в Москве

Коллеги, EMC планирует провести курс из трека EMC Cloud Architect в Москве в сентябре. И у меня появилась возможность пригласить одного-двух человек на этот курс бесплатно.

Мое впечатление от Virtualized Datacenter - http://blog.vadmin.ru/2011/09/emc-cloud-architect.html

Напишите мне в личку / e-mail - почему вам интересно этот курс посетить, и почему именно вам должно достаться место в классе :)

Nicira Virtualization Platform. Высокоуровневая архитектура

Это первая из цикла статей, описывающих более глубокое изучение мной Nicira Network Virtualization Platform (NVP). Как по мне NVP это прекрасный продукт, но о котором доступно очень мало информации: как он работает, как он настраивается и т.д - именно эту проблему я и собираюсь решить данным циклом статей. И начнём с высокоуровнего описания архитектуры.

Перед тем как начать хотелось бы прояснить взаимосвязь между NVP и NSX. Данный цикл будет акцентироваться на NVP - продукте который уже доступен, и используется некоторыми компаниями. Архитектура которую я тут буду описывать также будет применима и к стеку NSX, который VMware анонсировала в марте, так как NSX будет использовать архитектуру NVP, так что изучение NVP сейчас поможет с NSX в будущем.

Начнём с картинки - схема внизу показывает высокоуровневую архитектуру NVP:

Ключевыми компонентами являются:

• Горизонтально масштабируемый кластер контроллеров - NVP контроллеры обрабатывают расчёты сетевой топологии, предоставляют конфигурацию и распространяют настройки требуемые для создания логических сетей. Для повышения уровня доступности и масштабируемости контроллеры поддерживают возможность горизонтального масштабирования. Контроллеры поддерживают "северный" REST API, который может быть использован системами управления облаком типа OpenStack, CloudStack или же внутренними разработками каждой компании.
• Программируемый виртуальный свитч - для этой роли NVP использует Open vSwitch (OVS) - независимый проект с открытым исходным кодом, разрабатываемый самыми разными игроками рынка. OVS связывается с кластером контроллеров NVP для получения настроек и информации о логических сетях.
• "Южный" протокол коммутации - NVP использует два открытых протокола для связи между контроллерами и OVS. Для передачи настроек используется протокол OVSDB, а логических сетей - OpenFlow. Управляющий трафик протокола OVSDB между OSV и контроллерами зашифрован с помощью SSL.
• Шлюзы: шлюзы являются входом и выходом в\для логических сетей в NVP. Шлюзы могу быть как L2 (свитчинг логических сетей в NVP в физические) так и L3 (маршрутизация между логическими сетями в NVP и физическими сетями). В любом случае шлюзы поддерживают горизонтальное масштабирование для обеспечения отказоустойчивости и повышения масштабируемости L2 и L3 шлюзов, работающих на хосте.
• Протоколы инкапсуляции: для обеспечения полной независимости и изоляции логических сетей от подлежащих физических сетей NVP использует протоколы инкапсуляции для транспортировки трафика логических сетей поверх физических сетей. На данный момент NVP поддерживает Generic Routing Encapsulation (GRE) и Stateless Transport Tunneling (STT), а в будущих версиях этот список будет расширен.
• Ноды обслуживания- для разгрузки BUM трафика (Broadcast, Unknown Unicast, и Multicast) NVP опционально может использовать несколько нод обслуживания. На схеме выше они не отображены. Если не использовать ноды обслуживания BUM трафик будет обрабатываться каждым гипервизором локально.

Оригинал: Scott Lowe

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

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

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

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

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

vCenter Operations: Подсчёт параметра Health в редакции Foundation

Меня спрашивали, есть ли разница в том, как работает подсчёт параметра Health в vCOps Foundation? В общем, разница есть с другими редакциями есть, и большая.

В более высоких редакциях (Standard/Advance/Enterprise) данный параметр считается на основе трёх под-параметров: Workload, Anomalies, Faults. В Foundation версии же отсутствуют под-параметры Anomalies и Faults (точнее Faults отображается, но не как отдельный параметр, хотя vCOps и отсылает предупреждения по данному параметру). Что же тогда принимается в расчёт при расчётах?

У ВМ AD01-Server параметр Health составляет 71% без каких-либо Faults. В данном случае расчёт следующий: 100-29 (так как память самый нагруженный ресурс) = 71%.

Перейдём к хосту ESX. На хосте я отключил сетевой интерфейс,что привело к увеличению значения Faults до 70. При этом память хоста загружена на 45%. Исходя из прошлых результатов можно ожидать, что значение Health составит 55%, но, как видно на картинке, оно составляет только 30%. Причина кроется в учёте значения Faults.

Как только я исправил ошибку, значение Health выросло до ожидаемых 57%, так как память хоста нагружена на 43%.

Оригинал: http://www.virtualclouds.co.za/

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

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

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

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

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

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

Как работает планировщик процессора ESXi. Презентация с VMUG 2013.

Как заставить 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/

Виртуализация приложений класса Business Critical. Часть 1.

Мне довелось присутствовать на добром десятке презентаций по виртуализации бизнес приложений, и в большинстве случаев оставалось чувство недоговоренности. Словно я пропустил самую главную часть. Вендоры средств виртуализации утверждают, что business critical приложения в виртуальных машинах прекрасно работают. Вендоры железа презентуют свли линейки hi end оборудования для этих приложений.
Но что же такое на самом деле приложения класса "business critical" и чем они отличются от остальных? Поскольку обычно при разговоре мы многое подразумеваем само собой разумеющимся, а в итоге запутываемся, то давайте начнем с самого начала.

Приложение

Приложение - это компьютерная программа, предназначенная для выполнения пользовательских задач. В этом его отличие от операционной системы, предназначенной для того, чтобы быть прослойкой между железом и приложениями. И системных программ, обслуживающих ту или иную задачу по обеспечению функционирования всего комплекса (например дефрагментатор).
Так что же тогда бизнес-критичное приложение? Для этого надо разобраться с остальными словами.

Top 25 VMware blogs

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

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

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

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

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

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

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

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

Виртуализация сетей в Software Defined Datacenter

VMware давно известна как компания, которая изменила компьютерные вычисления благодаря технологиям виртуализации серверов. Мы в Nicira решили для себя, что с помощью виртуализации хотим изменить сети так же, как VMware - компьютерные вычисления. Аналогия между серверной и сетевой виртуализацией может быть полезной, но всё же это только аналогия. Цель данного поста в том, чтобы углубиться в виртуализацию сетей – рассказать, что это такое, что это значит для индустрии, и как VMware, после покупки Nicira, собирается изменить сети.