Те из вас, кто использовал решение для обеспечения высокой доступности хранилищ под виртуализацию StarWind Virtual SAN, знают, что в продукте предусмотрена возможность асинхронной репликации данных на резервный узел для обеспечения катастрофоустойчивости. В этом случае на резервную площадку откидывается снапшот данных основного узла по заданному администратором расписанию.
В документе приведены как общие сведения об устройстве механизма асинхронной репликации данных StarWind Virtual SAN, так и подробные пошаговые инструкции по его настройке. Также советуем посмотреть еще один документ StarWind об асинхронной репликации.
Пару месяцев назад мы писали о том, что вышло обновление VMware vSphere 5.5 Update 3, которое полезно для пользователей, еще не перешедших на обновленную версию платформы виртуализации vSphere 6.
Новых возможностей там было немного, поэтому многие проигнорировали этот апдейт - а зря. Там появилось множество улучшений производительности операций в Web Client, о чем у VMware есть отдельная статья. Приведем основную выжимку здесь.
Как вы знаете, в vSphere Web Client 6.0 был сделан шаг вперед в плане улучшения производительности, а сейчас инженеры VMware портировали эти изменения уже на младшую версию vSphere 5.5 U3. При этом, по оценке самой VMware, теперь производительность тонкого клиента в этой версии в некоторых аспектах аналогична оной в vSphere 6.0 Update 1.
Улучшения были сделаны в следующих областях:
Меню действий и меню по правому клику мыши
Страницы Related Objects, Summary и Settings
Мастера выполнения операций (миграция, создание шаблона и т.п.)
Процесс логина в консоль
Графики отображения производительности
Для тестирования сделанных улучшений (VMware уверяет, что их было сделано очень много) использовались 2 типа окружения:
Большое – vCenter Server (32 vCPU / 64 GB RAM), 1000 хостов, 15000 ВМ
Посмотрим на время логина в Web Client:
Уменьшилось ровно в 2 раза. Теперь посмотрим на отклик меню действий (оно же вызывается по правой кнопке мыши):
Здесь кое-где и в 3 раза улучшилась ситуация. Для меню виртуальных машин ситуация не сильно улучшилась, так как в этом меню большое количество контекстно-зависимых действий.
Генерация графиков производительности (выбор объектов, ресайз графиков, обновление, выбор элементов для отображения). Здесь очень существенные улучшения, более чем в 2 раза:
Отображение связанных объектов, например, вы выбираете кластер и отображения списка виртуальных машин в нем происходит намного быстрее:
В общем, если вы еще не обновились - причина поставить новую версию Web Client есть.
Для тех из вас, кто использует в производственной среде или тестирует решение VMware NSX для виртуализации сетей своего датацентра, компания VMware подготовила полезный документ "VMware NSX for vSphere Network Virtualization Design Guide", который вышел уже аж в третьей редакции.
Документ представляет собой рефернсный дизайн инфраструктуры виртуализации сетей в датацентре и описывает архитектуру решения NSX на физическом и логическом уровнях.
В новой версии документа появилась следующая информация для сетевых архитекторов:
сайзинг решения NSX для небольших датацентров
лучшие практики маршрутизации
микросегментация и архитектура компонента обеспечения безопасности среды Service Composer
Документ содержит ни много ни мало 167 страниц. Скачать его можно по этой ссылке.
Мы уже не раз писали про веб-консоль управления ESXi Embedded Host Client, которая доступна на сайте проекта VMware Labs как VIB-пакет для вашего сервера ESXi. Вот тут мы писали о возможностях третьей версии, а на днях стал доступен обновленный ESXi Embedded Host Client v4.
Давайте посмотрим на его новые возможности.
Основное:
Новое меню Tools and links под разделом Help.
Механизм обновления теперь принимает URL или путь к хранилищу с zip-файлом метаданных, что позволяет обновлять собственно сам сервер ESXi, а не только накатывать VIB-пакеты. Подробнее об этом тут.
Локализация и интернационализация (французский, испанский, японский, немецкий, китайский и корейский).
Возможность отключить таймаут сессии (очен удобно, если клиент всегда открыт у вас на вкладке браузера).
Большое количество исправлений ошибок и мелких улучшений.
Операции с виртуальными машинами:
Работа со списком виртуальных машин была оптимизирована по производительности.
Возможность изменять расширенные настройки ВМ (advanced settings).
Возможность изменять настройки видеоадаптера ВМ.
Добавление девайса PCI pass-through (и его удаление).
Поддержка функции SRIOV для сетевых карточек.
Возможность изменения раскладки клавиатуры в браузере.
Поддержка комбинаций Cmd+a или Ctrl+a для выделения всех ВМ в списке.
Поддержка функций Soft-power и Reset для виртуальных машин, если установлены VMware Tools.
Операции с хостом:
Возможность изменять host acceptance level для установки сторонних пакетов.
Редактирование списка пользователей для исключений режима lockdown mode.
Изменение настроек системного свопа.
Скачать ESXi Embedded Host Client v4 можно по этой ссылке.
У большинства администраторов хотя бы раз была ситуация, когда управляющий сервер VMware vCenter оказывался недоступен. Как правило, этот сервер работает в виртуальной машине, которая может перемещаться между физическими хостами VMware ESXi.
Если вы знаете, где находится vCenter, то нужно зайти на хост ESXi через веб-консоль Embedded Host Client (который у вас должен быть развернут) и запустить/перезапустить ВМ с управляющим сервером. Если же вы не знаете, где именно ваш vCenter был в последний раз, то вам поможет вот эта статья.
Ну а как же повлияет недоступность vCenter на функционирование вашей виртуальной инфраструктуры? Давайте взглянем на картинку:
Зеленым отмечено то, что продолжает работать - собственно, виртуальные машины на хостах ESXi. Оранжевое - это то, что работает, но с некоторыми ограничениями, а красное - то, что совсем не работает.
Начнем с полностью нерабочих компонентов в случае недоступности vCenter:
Централизованное управление инфраструктурой (Management) - тут все очевидно, без vCenter ничего работать не будет.
DRS/Storage DRS - эти сервисы полностью зависят от vCenter, который определяет хосты ESXi и хранилища для миграций, ну и зависят от технологий vMotion/Storage vMotion, которые без vCenter не работают.
vMotion/SVMotion - они не работают, когда vCenter недоступен, так как нужно одновременно видеть все серверы кластера, проверять кучу различных условий на совместимость, доступность и т.п., что может делать только vCenter.
Теперь перейдем к ограниченно доступным функциям:
Fault Tolerance - да, даже без vCenter ваши виртуальные машины будут защищены кластером непрерывной доступности. Но вот если один из узлов ESXi откажет, то новый Secondary-узел уже не будет выбран для виртуальной машины, взявшей на себя нагрузку, так как этот функционал опирается на vCenter.
High Availability (HA) - тут все будет работать, так как настроенный кластер HA функционирует независимо от vCenter, но вот если вы запустите новые ВМ - они уже не будут защищены кластером HA. Кроме того, кластер HA не может быть переконфигурирован без vCenter.
VMware Distributed Switch (vDS) - распределенный виртуальный коммутатор как объект управления на сервере vCenter работать перестанет, однако сетевая коммуникация между виртуальными машинами будет доступна. Но вот если вам потребуется изменить сетевые настройки виртуальной машины, то уже придется прицеплять ее к обычному Standard Switch, так как вся конфигурация vDS доступна для редактирования только с работающим vCenter.
Other products - это сторонние продукты VMware, такие как vRealize Operations и прочие. Тут все зависит от самих продуктов - какие-то опираются на сервисы vCenter, какие-то нет. Но, как правило, без vCenter все довольно плохо с управлением сторонними продуктами, поэтому его нужно как можно скорее поднимать.
Для обеспечения доступности vCenter вы можете сделать следующее:
Защитить ВМ с vCenter технологией HA для рестарта машины на другом хосте ESXi в случае сбоя.
Использовать кластер непрерывной доступности VMware Fault Tolerance (FT) для сервера vCenter.
Как вы знаете, некоторое время назад вышло обновление платформы виртуализации VMware vSphere 6 Update 1, в котором были, в основном, только минорные обновления. Но было и важное - теперь виртуальный модуль VMware vCenter Server Appliance (vCSA) стало возможно обновлять путем монтирования к нему ISO-образа с апдейтом.
Давайте покажем упрощенный процесс обновления через смонтированный образ. Итак, соединимся с хостом vCSA по SSH (если у вас есть отдельный сервер Platform Services Controller, то коннектиться нужно к нему):
Далее скачаем обновление vCenter, в котором есть и обновление vCSA версии 6.0.0 (выберите продукт VC и в разделе VC-6.0.0U1-Appliance скачайтеVMware-vCenter-Server-Appliance-6.0.0.10000-3018521-patch-FP.iso):
Здесь надо пояснить, что это за обновления:
FP (Full patch) - это обновление всех компонентов vCenter, включая полноценные продукты, vCenter, vCSA, VMware Update Manager, PSC и прочее.
TP (Third party patch) - это обновление только отдельных компонентов vCenter.
Скачиваем патч FP (VMware-vCenter-Server-Appliance-6.0.0.10000-3018521-patch-FP.iso), после чего монтируем этот ISO-образ к виртуальной машине vCSA через vSphere Web Client или Embedded Host Client.
Далее возвращаемся к консоли vCSA:
Смонтировать ISO-образ можно также через PowerCLI с помощью следующих команд:
Далее выполняем следующую команду, если вы хотите накатить патчи прямо сейчас:
software-packages install --iso --acceptEulas
Либо патчи можно отправить на стейджинг отстаиваться (то есть пока обновить компоненты, но не устанавливать). Сначала выполняем команду отсылки на стейджинг:
software-packages install --iso --acceptEulas
Далее просматриваем содержимое пакетов:
software-packages list --staged
И устанавливаем апдейт со стейджинга:
software-packages install --staged
Если во время обновления на стейджинг или установки обновления возникли проблемы, вы можете просмотреть логи, выполнив следующие команды:
shell.set –enabled True shell cd /var/log/vmware/applmgmt/ tail software-packaged.log –n 25
Далее размонтируйте ISO-образ от виртуальной машины или сделайте это через PowerCLI следующей командой:
shutdown reboot -r "Updated to vCenter Server 6.0 Update 1"
Теперь откройте веб-консоль vCSA по адресу:
https://<FQDN-or-IP>:5480
И перейдите в раздел Update, где вы можете увидеть актуальную версию продукта:
Кстати, обратите внимание, что возможность проверки обновления в репозитории (Check URL) вернулась, и обновлять vCSA можно прямо отсюда по кнопке "Check Updates".
Продолжаем рассказывать о решении номер 1 для создания программных хранилищ под виртуализацию VMware и Microsoft - StarWind Virtual SAN. Сегодня мы расскажем об альтернативном способе приобретения продукта, который может быть полезен, в основном, сервисным компаниям, которые предоставляют услуги пользователям на базе подписки.
Мы хотим рассказать о двух вариантах использования лицензий StarWind, которые позволяют перенести капитальные затраты (CapEX) в операционные расходы (OpEX) - это важно для провайдера ИТ-услуг, например, IaaS-хостинга виртуальных машин.
Первый вариант - аренда лицензий PaaS (Platform-as-a-Service). В этом случае заказчик платит по мере потребления услуги помесячно. Нет платежа - нет лицензии, тут все просто. StarWind выступает в виде облачной платформы хранения, к сервисам которой у клиента есть "подключение" и которая потребляется по SaaS-модели для клиента.
Второй вариант - лизинг ПО StraWind. В этом случае также есть помесячные платежи, но в результате всех выплат лицензия на ПО остается в собственности клиента, который далее может использовать ее и продлевать подписку на обновления.
Многие из вас знают, что в решении VMware Horizon View есть две полезных возможности, касающихся функций печати из виртуального ПК пользователя - это перенаправление принтеров (Printer redirection) и печать на основе местоположения (Location based printing). Об этих функциях подробно рассказано в документе "Virtual Printing Solutions with View in Horizon 6", а мы изложим тут лишь основные сведения, содержащиеся в нем.
Printer redirection
Эта возможность позволяет перенаправить печать из виртуального ПК к локальному устройству пользователя, с которого он работает, и к которому подключен принтер уже физически. Функция поддерживается не только для Windows-машин, но и для ПК с ОС Linux и Mac OS X. Работает эта фича как для обычных компьютеров, так и для тонких клиентов (поддерживается большинство современных принтеров).
При печати пользователь видит принтер хоста не только в диалоге печати приложения, но и в панели управления. При этом не требуется в виртуальном ПК иметь драйвер принтера - достаточно, чтобы он был установлен на хостовом устройстве.
Перенаправление принтеров полезно в следующих случаях:
в общем случае, когда к физическому ПК пользователя привязан принтер
когда пользователь работает из дома со своим десктопом и хочет что-то распечатать на домашнем принтере
работники филиала печатают на локальных принтерах, в то время, как сами десктопы расположены в датацентре центрального офиса
Схема передачи задания на печать для перенаправления принтера выглядит так:
То есть Horizon Client получает данные в формате EMF от виртуального ПК и передает его уже на хостовом устройстве к драйверу принтера.
Location based printing
Эта фича позволяет пользователям виртуальных ПК печатать на тех принтерах, которые находятся географически ближе к нему, чтобы не бегать, например, на другой этаж офисного здания, чтобы забирать распечатанное, когда есть принтеры поблизости. Правила такой печати определяются системным администратором.
Для функции Location based printing задания печати направляются с виртуального ПК напрямую на принтер, а значит нужно, чтобы на виртуальном десктопе был установлен драйвер этого принтера.
Есть 2 типа правил Location based printing:
IP-based printing - используется IP-адрес принтера для определения правил маппинга принтера к десктопам.
UNC-based printing - используются пути в формате Universal Naming Convention (UNC) для определения правил маппинга принтеров.
Здесь задание на печать передается в рамках следующего рабочего процесса:
Запрос пользователя с хостового устройства через Horizon Client передается к View Agent, который через взаимодействие с приложением передает задание драйверу принтера в гостевой ОС с учетом правил маппинга принтеров, а дальше уже обработанное задание идет на печать.
В зависимости от способа доступа, поддерживаются методы перенаправления принтеров или печать на основе местоположения:
Очевидно, что в нулевом клиенте и в мобильном девайсе нет хостового драйвера принтера, поэтому там и нет поддержки Printer redirection. Ну и то же самое можно сказать про доступ HTML access через браузер - там тоже поддержка отсутствует.
Надо сказать, что и Printer redirection, и Location based printing поддерживаются для следующих моделей доступа пользователей инфраструктуры VDI:
Десктопы View
Десктопы RDSH
Десктопы Windows Server 2008 R2 и Windows Server 2012 R2
Приложения Hosted apps
Ну а о том, как настраивать обе техники печати из виртуальных ПК вы можете прочитать в документе.
Мы уже писали о том, что последней версии решения для виртуализации настольных ПК VMware Horizon View 6.2 есть поддержка режима vGPU. Напомним, что это самая прогрессивная технология NVIDIA для поддержки требовательных к производительности графической подсистемы виртуальных десктопов.
Ранее мы уже писали про режимы Soft 3D, vSGA и vDGA, которые можно применять для виртуальных машин, использующих ресурсы графического адаптера на стороне сервера.
Напомним их:
Soft 3D - рендеринг 3D-картинки без использования адаптера на основе программных техник с использованием памяти сервера.
vDGA - выделение отдельного графического адаптера (GPU) одной виртуальной машине.
vSGA - использование общего графического адаптера несколькими виртуальными машинами.
Режим vSGA выглядит вот так:
Здесь графическая карта представляется виртуальной машине как программный видеодрайвер, а графический ввод-вывод обрабатывается через специальный драйвер в гипервизоре - ESXi driver (VIB-пакет). Команды обрабатываются по принципу "first come - first serve".
Режим vDGA выглядит вот так:
Здесь уже физический GPU назначается виртуальной машине через механизм проброса устройств DirectPath I/O. То есть целый графический адаптер потребляется виртуальной машиной, что совсем неэкономно, но очень производительно.
В этом случае специальный драйвер NVIDIA GPU Driver Package устанавливается внутри виртуальной машины, а сам режим полностью поддерживается в релизах Horizon View 5.3.х и 6.х (то есть это давно уже не превью и не экспериментальная технология). Этот режим работает в графических картах K1 и K2, а также и более свежих адаптерах, о которых речь пойдет ниже.
Режим vGPU выглядит вот так:
То есть встроенный в гипервизор NVIDIA vGPU Manager (это тоже драйвер в виде пакета ESXi VIB) осуществляет управление виртуальными графическими адаптерами vGPU, которые прикрепляются к виртуальным машинам в режиме 1:1. В операционной системе виртуальных ПК также устанавливается GRID Software Driver.
Здесь уже вводится понятие профиля vGPU (Certified NVIDIA vGPU Profiles), который определяет типовую рабочую нагрузку и технические параметры десктопа (максимальное разрешение, объем видеопамяти, число пользователей на физический GPU и т.п.).
vGPU можно применять с первой версией технологии GRID 1.0, которая поддерживается для графических карт K1 и K2:
Но если мы говорим о последней версии технологии GRID 2.0, работающей с адаптерами Tesla M60/M6, то там все устроено несколько иначе. Напомним, что адаптеры Tesla M60 предназначены для Rack/Tower серверов с шиной PCIe, а M6 - для блейд-систем различных вендоров.
Технология NVIDIA GRID 2.0 доступна в трех версиях, которые позволяют распределять ресурсы между пользователями:
Характеристики данных лицензируемых для адаптеров Tesla изданий представлены ниже:
Тут мы видим, что дело уже не только в аппаратных свойствах графической карточки, но и в лицензируемых фичах для соответствующего варианта использования рабочей нагрузки.
Каждый "experience" лицензируется на определенное число пользователей (одновременные подключения) для определенного уровня виртуальных профилей. Поэтому в инфраструктуре GRID 2.0 добавляется еще два вспомогательных компонента: Licensing Manager и GPU Mode Change Utility (она нужна, чтобы перевести адаптер Tesla M60/M6 из режима compute mode в режим graphics mode для работы с соответствующим типом лицензии виртуальных профилей).
Обратите внимание, что поддержка гостевых ОС Linux заявлена только в последних двух типах лицензий.
На данный момент сертификацию драйверов GRID прошло следующее программное обеспечение сторонних вендоров (подробнее об этом тут):
Спецификации карточек Tesla выглядят на сегодняшний день вот так:
Поддержка также разделена на 2 уровня (также прикрепляется к лицензии):
Руководство по развертыванию NVIDIA GRID можно скачать по этой ссылке, ну а в целом про технологию написано тут.
Напомним, что о подходе VMware к контейнеризованным приложениям Docker мы писали вот тут. Вкратце: VMware предлагает на базе Photon OS запускать контейнеры в виртуальных машинах (одна ВМ - одно приложение), а с помощью средств VMFork мгновенно создавать экземпляры таких виртуальных машин по требованию.
Выпущенный на днях Docker Management Pack for vRealize Operations Manager собирает данные о производительности этих контейнеров в вашем окружении Docker, а также предоставляет анализ о возможных трудностях с производительностью. Кроме того, в данном средстве в реальном времени доступна информация об имеющихся проблемах в инфраструктуре Docker (они обозначаются красными квадратиками).
Данный management pack представляет собой плагин к vRealize Operations Manager 6.x. Он отображает взаимосвязи между различными компонентами инфраструктуры Docker (например соотношение между образом и контейнером), а также собирает данные о производительности и свойствах с каждой системы Docker.
Для установки плагина нужно зайти в раздел Administration > Solutions в vRealize Operations Manager и загрузить pak-файл, нажав плюсик:
Скачать VMware vRealize Operations Docker 1.0 Adapter можно по этой ссылке.
Те, из вас, кто пользуется веб-средством vSphere Web Client для управления виртуальной инфраструктурой VMware vSphere, знают, что при логине в окно клиента в самом низу предлагают скачать Client Integration Plugin (CIP):
CIP - это пакет средств от VMware, представляющий собой набор полезных утилит для некоторых административных операций в виртуальной инфраструктуре. Утилиты доступны как для Microsoft Windows, так и для Apple Mac OS X (а скоро будет и поддержка Linux).
Посмотрим на состав этого набора:
ovftool - это отдельная утилита CLI, которую можно использовать для импорта и экспорта виртуальных модулей (Virtual Appliances) в форматах OVF и OVA.
Windows Authentication - позволяет использовать аутентификацию SSPI Windows при логине через vSphere Web Client.
Remote Devices - возможность подключить клиентские устройства (CD-ROM, Floppy, USB и прочие) к виртуальной машине.
File Upload/Download - это вынесенный в отдельную утилиту Datastore browser для загрузки файлов на виртуальные хранилища.
Content Library - операции импорта и экспорта для компонента Content Library.
Client Side Logging/Config - позволяет записывать логи на стороне клиента, а также реализует настройки логирования vSphere Web Client.
Процедура развертывания vSphere Client Integration Plugin выглядит примерно так (видео от версии vSphere 5.5):
Ранее CIP как браузерный плагин использовал модель Netscape Plugin Application Programming Interface (NPAPI), но поскольку в Google Chrome последних версий и прочих браузерах поддержка этой устаревшей модели была окончена, то теперь используется обновленная модель отображения, которая реализована, начиная с Sphere 5.5 Update 3a и vSphere 6.0 Update 1 (поэтому лучше CIP использовать с платформами этих версий или выше).
Более подробно об утилитах CIP рассказано вот тут.
Для тех из вас, кто еще не обновил свою инфраструктуру на последнюю версию VMware vSphere 6, компания VMware приготовила очередной пакет исправлений VMware vSphere 5.5 Update 3b. На самом деле, это просто патч VMware ESXi 5.5 patch ESXi550-201512001, в котором произошли некоторые изменения в плане безопасности, а также исправлены ошибки.
Среди заявленных фич, касающихся security, основная - это отключенный по умолчанию SSL третьей версии (SSLv3). Отключили его (как в клиенте, так и в сервере) потому, что он считается устаревшим, и его поддержка уже не предоставляется в большинстве Enterprise-продуктов (об этом можно почитать в RFC 7568).
Внимание! Обязательно следуйте рекомендованной последовательности обновления продуктов VMware, то есть сначала обновите vCenter до версии 5.5 Update 3b и только потом ESXi 5.5 до версии Update 3b, чтобы избежать проблем с отключением хостов от сервера управления vCenter.
Также помните, что VMware View Composer версии ниже 6.2 не будет работать с хостами ESXi 5.5 Update 3b.
Когда вы выбираете облачного провайдера под проект IaaS, основное внимание уделяется характеристикам самого облака. Вы уточняете время доступности сервисов, гарантированные параметры производительности, возможности расширения набора облачных ресурсов и т. п. Но за любым виртуальным облаком кроется реальное оборудование, установленное в четырех стенах на некой территории. И от надежности всей этой «фоновой» инфраструктуры в значительной степени зависит надежность нового разворачиваемого в облаке сервиса.
Так как облачные вычисления привлекают не только маленькие компании с невысокой зависимостью от ИТ, но и действительно крупные корпорации с полностью «цифровыми» бизнес-направлениями, ко всем компонентам стоит отнестись особенно внимательно. Дело в том, что облачный провайдер часто оперирует характеристиками собственных сервисов, декларируя тот или иной уровень надежности (привычные нам «девятки»). Но даже если предположить, что в цифрах заявленной надежности и производительности нет лукавства, остается открытым вопрос соответствия подобным показателям нижележащей инфраструктуры. Ведь никакое дублирование и кластеризация не помогут вашим облачным виртуальным машинам при перегреве оборудования в машинном зале.
Не стоит забывать и о национальных особенностях ИТ-бизнеса. Далеко не все коммерческие дата-центры имеют официальную сертификацию по классу надежности, и еще меньшее их число подтверждено реальным независимым аудитом. Увы, но все еще встречаются разнообразные «внутренние сертификации», «нам это не нужно, мы уверены» и «заявленный уровень надежности — TIER III+» (с этими плюсами ситуация вообще забавная, но об этом позже).
Чтобы избежать будущих и вполне реальных неприятностей на ровном месте, рекомендуем внимательно подойти к выбору облачного поставщика, самостоятельно проверив характеристики его дата-центров. В конце концов, вы имеете полное право знать, где и как хранится ваша информация и насколько надежен «цифровой фундамент» бизнеса. Далее мы будем говорить преимущественно о самих ЦОД, отложив в сторону особенности облачных провайдеров.
Чем отличается надежность со стороны клиента и владельца дата-центра
Очевидно, что у владельца ЦОД и его клиента совершенно разные цели и ориентиры. Если вы, как будущий заказчик, стремитесь получить максимально качественный и отвечающий требованиям продукт за разумные деньги, то провайдер, скорее всего, пойдет по пути наименьшего сопротивления. И быть бы всем нашим ЦОД максимально примитивными, если бы не требования рынка. Многие заказчики откажутся пользоваться услугами ЦОД без резервных источников питания и дублированной системы охлаждения. А некоторые еще и обратят внимание на географическое расположение и характеристики самого здания с машинным залом.
В то же время можно встретить немало ЦОД, где систему охлаждения проектировали несведущие в вопросе люди, оба «независимых» подвода питания исходят из одной магистральной линии города либо для дизельного генератора не предусмотрено своевременного подвоза топлива. Да что там говорить, мне лично доводилось видеть дата-центр, где холодный коридор был реализован двумя кондиционерами, дующими в некую точку посередине. Очевидно, что температура оборудования в крайних стойках может и не уложиться в ожидаемые пределы при высокой нагрузке.
Что же обычно хочет видеть заказчик при оценке надежности дата-центра:
Непрерывную работу ЦОД не менее определенного значения в год. На этот фактор влияет уровень резервирования всех ключевых узлов (охлаждение, электропитание, класс серверного оборудования).
Соразмерный ожиданиям заказчика уровень гарантированной производительности.
Возможности по защите информации от хищения. Сюда входит скорее риск физического доступа к оборудованию посторонних лиц, то есть речь идет об охране.
Между тем порой упускаются важные и неочевидные моменты, которые могут вылиться в серьезные неприятности:
Юридический статус ЦОД (права собственности, разрешения всех государственных инстанций и прочее).
Наличие всех необходимых контрактов на обслуживание систем и их поддержку при наступлении аварийной ситуации (тот же контракт на подвозку дизельного топлива для генераторов или план проверок всех систем на готовность к отработке аварии).
Возможности работы инженерных систем при нетипичных температурах и погодных аномалиях.
Проектирование инфраструктуры в соответствии с принятыми в отрасли нормами и правилами.
Разумеется, список неполный. Но даже этот перечень заставляет задуматься о существовании множества особенностей и нюансов, которые при проектировании объекта балансируют между стоимостью и возможностями. Дабы упорядочить ситуацию и внести какое-то подобие структуры, в 1993 году в США был основан The Uptime Institute (UTI), который является лидером в области оценки надежности и доступности дата-центров. Uptime Institute признан мировым ИТ-сообществом как независимый аудитор соответствия ЦОД требованиям отказоустойчивости.
UTI
Организация Uptime Institute за время своего существования собрала информацию о тысячах происшествий в дата-центрах по всему миру. Эти данные использовались для создания классификации по уровням готовности Tier Classification. Этот классификатор через некоторое время стал стандартом де-факто и был включен в состав американского стандарта построения центров обработки данных TIA/EIA-942.
Классификатор состоит из четырех уровней (Tier1 — 4), где большее число означает более высокий уровень надежности:
Tier 1 предполагает отсутствие резервирования систем электропитания и охлаждения машинного зала, отсутствие резервирования серверных систем. Фактически инженерная инфраструктура просто должна быть собственной и иметь подстраховку на случай перебоев с электропитанием (генератор). Уровень доступности — 99,671 %, что соответствует примерно 28,8 часам простоев ежегодно.
Tier 2 основывается на Tier 1, но предполагает резервирование всех активных систем. Это уже более надежный класс, который все же допускает около 22 часов простоев в год (99,75 %).
Tier 3 уже может считаться работающим без остановок. На этом уровне обязательно должны быть зарезервированы все инженерные системы (включая пассивные), должны обеспечиваться возможности ремонта и модернизации без остановки сервисов. Tier 3 фактически предполагает постройку второго ЦОД внутри того же здания — дублирующая СКС, подводы электричества, отдельная система охлаждения, у всего серверного оборудования независимые подключения к нескольким источникам питания. Допускается не более 1,6 часа простоев в год (99,98 %);
Tier 4 является дальнейшим развитием третьего уровня и, помимо резервирования всех систем, предполагает сохранение уровня отказоустойчивости даже при аварии. Схема позволяет гарантировать непрерывность работы при любых умышленных или случайных поломках, допуская простой продолжительностью лишь 0,8 часа ежегодно (99,99 %).
Для вашего удобства я собрал отличия уровней надежности в табличку:
Приходите на вебинар, чтобы узнать, как именно можно получить максимальный эффект от использования All-Flash хранилищ серверов хранения в сочетании с виртуализацией и проприетарной высокопроизводительной файловой системой LSFS от компании StarWind. Ребята действительно очень далеко продвинулись в этом плане.
Как вы знаете, у компании VMware есть средство для комплексного мониторинга и решения проблем в виртуальной среде vRealize Operations. Также в решении для создания инфраструктуры виртуальных ПК предприятия VMware Horizon View (еще с версии 6.0) есть поддержка опубликованных приложений на серверах RDS Hosted Apps.
Ну и логично, что у VMware есть решение vRealize Operations for Published Applications, которое поддерживает мониторинг инфраструктуры доставки приложений через механизм RDS Hosted Apps. На днях вышла обновленная версия этого продукта - vRealize Operations for Published Applications 6.2 одновременно с основным релизом Operations 6.2, с поддержкой не только приложений опубликованных, через RDS, но и продуктов Citrix XenApp и XenDesktop.
Основные новые возможности vRealize Operations for Published Applications 6.2:
Поддержка последних версий Citrix XenDesktop and XenApp 7.6 - функции мониторинга и отчетности теперь доступны для инфраструктуры виртуализации и доставки приложений и десктопов, созданных на данных платформах.
Application and Usage Reports - готовые шаблоны отчетов, которые позволяют администраторам приложений определить потребление ресурсов приложениями, пиковые нагрузки, параметры сессий пользователей на серверных ресурсах, а также учитывать потребление пользователями лицензий отдельных приложений.
Proactive User Experience Monitoring - новый дэшборд "User Experience", который постоянно мониторит vCPU, vRAM и vDisk, чтобы с помощью карты heat map оповестить администратора о том, что некоторые пользователи испытывают проблемы при работе с их приложениями.
Reduced Time to Resolve - новые метрики сессии, которые помогают устранять проблемы: длительность процесса логина, сортировка по времени логина сессий, использование системных ресурсов, а также ICA Round Trip Time для приложений Citrix.
Windows 10 support - теперь Windows 10 поддерживается для мониторинга, как для VMware Horizon View, так и для решений XenDesktop/XenApp.
Алерты для Citrix Storefront, PVS Server, Citrix License Server и Citrix Database Server - теперь все эти компоненты поддерживаются в рамках общей процедуры мониторинга доступности компонентов инфраструктры виртуальных ПК и приложений.
Мониторинг лицензий Citrix License Server - теперь можно учитывать лицензии, считаемые этим продуктом.
Improved Logon Breakdown metrics to meet SLAs - дэшборд "Session Details" теперь показывает метрику длительность процесса логина для самых тормозных ПК.
Connection and machine failure data - эта новая метрика мониторит общее число неудачных соединений и стартов машин на ферме Citrix XenDesktop.
Более подробно о новых функциях решения vRealize Operations for Published Applications 6.2 написано в Release Notes. Напомним, что это решение включено в состав продукта vRealize Operations for Horizon, который можно скачать по этой ссылке.
Компания VMware на днях выпустила обновление своей платформы виртуализации для Mac OS - VMware Fusion 8.1. Напомним, что о прошлой версии VMware Fusion 8 мы писали вот тут.
Интересно, что эта версия продукта не предоставляет новых возможностей, но несет в себе достаточно много исправлений ошибок, что означает, что их в восьмой версии было немало (вообще говоря, в последнее время VMware довольно часто выпускает продукты с серьезными багами).
От себя скажу, что для меня лично была очень актуальна ошибка с задержками при работе в Excel - пишут что был "one-second delay", однако ничего подобного - у меня вся машина фризилась секунд на 20-30, пока я не обновил Fusion.
Итак, какие багофиксы были сделаны:
Исправления ошибок для упрощенного процесса инсталляции гостевых ОС из ISO-образов Windows 10 и Windows server 2012 R2.
Исправлена ошибка с неработающим обратным DNS lookup в виртуальной машине, когла на Mac-хосте установлен сервер dnsmasq.
Исправление ошибки с крэшем машины при отключении внешнего монитора от Mac, когда Fusion работает в полноэкранном режиме.
Исправлена ошибка при зависании машины на несколько секунд при работе в Microsoft Excel.
Исправлена ошибка, когда использование USB-устройств на OS X 10.11 могло завалить виртуальную машину.
Исправлена ошибка, когда хостовая и гостевая раскладки клавиатуры (non-English) отличались при использовании VNC.
Исправлена ошибка подключения хоста к гостевой ОС, когда USB Attached SCSI (UAS) присоединен к порту USB 3.0 на Mac OS X 10.9 или более поздних версий.
Исправлено поведение, когда копирование большого файла с USB могло приводить к замораживанию процесса и в итоге его прерыванию по таймауту.
Посмотрите на список: большинство из этого - реально серьезные вещи. Что-то VMware в последнее время не радует своим подходом к тестированию продуктов.
Обновление VMware Fusion 8.1 бесплатно для всех пользователей восьмой версии, скачать его можно по этой ссылке.
На блогах VMware появился интересный пост про производительность виртуальных машин, которые "растянуты" по ресурсам на весь физический сервер, на котором они запущены. В частности, в посте речь идет о сервере баз данных, от которого требуется максимальная производительность в числе транзакций в секунду (см. наш похожий пост о производительности облачного MS SQL здесь).
В данном случае речь идет о виртуализации БД с типом нагрузки OLTP, то есть обработка небольших транзакций в реальном времени. Для тестирования использовался профиль Order-Entry, который основан на базе бенчмарка TPC-C. Результаты подробно описаны в открытом документе "Virtualizing Performance Critical Database Applications in VMware vSphere 6.0", а здесь мы приведем основные выдержки.
Сводная таблица потерь на виртуализацию:
Метрика
Нативное исполнение нагрузки
Виртуальная машина
Пропускная способность транзакций в секунду
66.5K
59.5K
Средняя загрузка логических процессоров (72 штуки)
84.7%
85.1%
Число операций ввода-вывода (Disk IOPS)
173K
155K
Пропускная способность ввода-вывода дисковой подсистемы (Disk Megabytes/second)
929MB/s
831MB/s
Передача пакетов по сети в секунду
71K/s receive
71K/s send
63K/s receive
64K/s send
Пропускная способность сети в секунду
15MB/s receive
36MB/s send
13MB/s receive
32MB/s send
А вот так выглядит график итогового тестирования (кликабельно):
Для платформы VMware ESXi 5.1 сравнивалась производительность на процессоре микроархитектуры Westmere, а для ESXi 6.0 - на процессорах Haswell.
Результаты, выраженные в числе транзакций в секунду, вы видите на картинке. Интересно заметить, что ESXi версии 6.0 всерьез прибавил по сравнению с прошлой версией в плане уменьшения потерь на накладные расходы на виртуализацию.
А вот так выглядят усредненные значения для версий ESXi в сравнении друг с другом по отношению к запуску нагрузки на нативной платформе:
Ну и несложно догадаться, что исследуемая база данных - это Oracle. Остальное читайте в интереснейшем документе.
Horizon Toolbox 2 - это дополнение к стандартной консоли View Administrator, исполненное в виде веб-портала с различными функциями вроде аудита, удаленной поддержки и прочих полезных возможностей:
Перечислим основные нововведения VMware View Horizon Toolbox 2:
1. Console Access
Теперь появилась возможность полноценного доступа к консоли виртуальных ПК:
Можно просматривать список виртуальных машин для пулов виртуальных ПК и фильтровать их по именам машин (или DNS-именам).
2. Power-on policy
Теперь появилась вкладка Power-on policy, на которой можно посмотреть и изменить политику включения рабочих виртуальных ПК по дням недели:
Отдельную политику включения можно настраивать для каждого пула виртуальных десктопов.
3. Client IP address auditing
Теперь можно просматривать детальную информацию обо всех сессиях, обслуживаемых брокером соединений: IP-адреса клиентов, время логина и логаута и другое.
4. Installation file
Теперь процесс развертывания Horizon Toolbox 2 идет в полноценном графическом интерфейсе.
5. Прочие улучшения
Производительность функций аудита была существенно повышения за счет оптимизации SQL-запросов.
Функция Remote assistance работает более стабильно.
Улучшена совместимость с различными версиями Horizon View.
Установщик на стороне пользователя проверяет, что режим Windows Remote Assistance настроен корректно.
Если вы не успели на этот вебинар, можно посмотреть его запись по этой ссылке:
Напомним, что StarWind HyperConverged Appliance - это программно-аппаратный комплекс, который строится все это на базе следующих аппаратных платформ (спецификации - тут):
Напомним, что vGate - это решение, которое позволяет защитить вашу виртуальную инфраструктуру Microsoft от несанкционированного доступа и безопасно сконфигурировать ее средствами политик безопасности.
Мероприятие пройдет 15 декабря в 11:00 по московскому времени. Вебинар проведет
Денис Полянский, менеджер по продукту компании «Код Безопасности».
В ходе вебинара будут подробно рассмотрены такие темы, как:
новый функционал продукта
редакции vGate и новая схема лицензирования
процессы обновления и перехода между редакциями
В конце вебинара в режиме чата участники смогут задать вопросы и оставить заявки на получение дополнительных материалов.
В блоге VMware появился интересный пост о производительности СУБД Microsoft SQL Server на облачной платформе VMware vCloud Air. Целью исследования было выявить, каким образом увеличение числа процессоров и числа виртуальных машин сказываются на увеличении производительности баз данных, которые во многих случаях являются бизнес-критичными приложениями уровня Tier 1 на предприятии.
В качестве тестовой конфигурации использовались виртуальные машины с числом виртуальных процессоров (vCPU) от 4 до 16, с памятью от 8 до 32 ГБ на одну ВМ, а на хост-серверах запускалось от 1 до 4 виртуальных машин:
На физическом сервере было 2 восьмиядерных процессора (всего 16 CPU), то есть можно было запустить до 16 vCPU в режиме тестирования линейного роста производительности (Hyper-Threading не использовался).
В качестве приложения использовалась база данных MS SQL с типом нагрузки OLTP, а сами машины размещались на хостинге vCloud Air по модели Virtual Private Cloud (более подробно об этом мы писали вот тут). Для создания стрессовой нагрузки использовалась утилита DVD Store 2.1.
Первый эксперимент. Увеличиваем число четырехпроцессорных ВМ на хосте от 1 до 4 и смотрим за увеличением производительности, выраженной в OPM (Orders Per Minute), то есть числе небольших транзакций в минуту:
Как видно, производительность показывает вполне линейный рост с небольшим несущественным замедлением (до 10%).
Второй эксперимент. Увеличиваем число восьмипроцессорных ВМ с одной до двух:
Здесь также линейный рост.
Замеряем производительность 16-процессорной ВМ и сводим все данные воедино:
Проседание производительности ВМ с 16 vCPU обусловлено охватом процессорами ВМ нескольких NUMA-узлов, что дает некоторые потери (да и вообще при увеличении числа vCPU удельная производительность на процессор падает).
Но в целом, как при увеличении числа процессоров ВМ, так и при увеличении числа виртуальных машин на хосте, производительность растет вполне линейно, что говорит о хорошей масштабируемости Microsoft SQL Server в облаке vCloud Air.
Кстати, если хочется почитать заказуху про то, как облака VMware vCloud Air уделывают Microsoft Azure и Amazon AWS, можно пройти по этим ссылкам:
Осенью 2006 года я начал вести первый и на тот момент единственный на русском языке блог о виртуализации (понятное дело, тогда его никто еще не читал). Сначала это был небольшой бложек на движке Blogger, и посты были о каких-то настройках в VMware Workstaion. Того блога, как и первой версии сайта, уже давным давно нет, а портал VM Guru как самостоятельный ресурс оформился ровно 9 лет назад - 3 декабря 2006 года. Вот так он выглядел в далеком 2006 году:
С тех пор на нашем сайте появилось более трех с половиной тысяч записей, и сегодня это главный ресурс о виртуализации в России.
Трудно такое представить, но системные администраторы, которые сейчас управляют виртуальными инфраструктурами в свои 22 года, закончив институт, тогда еще ходили в 8-й класс. От всей души поздравляю всех авторов VM Guru и наших читателей с годовщиной!
Странные вещи происходят в последнее время с VMware. Сначала в технологии Changed Block Tracking (CBT) платформы VMware vSphere 6 был найдет серьезный баг, заключавшийся в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могли быть потеряны. Из-за этого пользователи переполошились не на шутку, ведь бэкапы, а это критически важная составляющая инфраструктуры, могли оказаться невосстановимыми.
Недавно этот баг был пофикшен в обновлении ESXi600-201511401-BG, и вроде бы все стало окей. Но нет - оказалось, что накатить обновление на ваши серверы VMware ESXi недостаточно, о чем своевременно сообщила компания Veeam (официальная KB находится вот тут). Нужно еще и сделать операцию "CBT reset", то есть реинициализировать Changed Block Tracking для виртуальных машин.
Все дело в том, что уже созданные файлы CBT map могут содержать невалидные данные, касательно изменившихся блоков, а ведь они могли быть созданы еще до накатывания патча от VMware. Таким образом, простое обновление ESXi не убирает потенциальную проблему - старые файлы *-ctk.vmdk могут, по-прежнему, быть источником проблем. Удивительно, как такая могучая компания как VMware просто взяла и прошляпила этот момент.
Итак, как нужно делать CBT reset для виртуальной машины описано вот тут у Veeam. Приведем этот процесс вкратце:
1. Открываем настройки виртуальной машины (да-да, для каждой ВМ придется это делать) и идем в Configuration Parameters:
2. Там устанавливаем значение параметра:
ctkEnabled = false
3. Далее устанавливаем
scsi0:x.ctkEnabled также в значение false:
4. Открываем папку с виртуальной машиной через Datastore Browser и удаляем все файлы *-ctk.vmdk (это и есть CBT map файлы):
5. Включаем виртуальную машину и заново запускаем задачу резервного копирования Veeam Backup and Replication.
Для тех, кто умеет пользоваться интерфейсом PowerCLI есть бонус - компания Veeam сделала PowerShell-скрипт, который автоматизирует эту операцию. Он позволяет переинициализировать CBT для указанных пользователем виртуальных машин. Виртуальные машины со снапшотом, а также выключенные ВМ будут проигнорированы. Также надо отметить, что при выполнении сценария создается снапшот машины, а потом удаляется, что может вызвать временное "подвисание" машины и ее недоступность в течение некоторого времени, поэтому лучше выполнять этот скрипт ночью или в нерабочие часы.
Рады представить вам очередного спонсора ресурса VM Guru - компанию 1cloud, предоставляющую услуги по аренде виртуальной инфраструктуры для физических и юридических лиц с 2012 года. Кликайте на баннер справа.
На данный момент оборудование 1cloud размещено в двух Дата-Центрах Росси: SDN в Санкт-Петербурге и Dataspace в Москве. Для построения инфраструктуры используется только самое надежное, качественное и современное оборудование: CISCO, DELL, NetApp, Juniper и другое).
В 1cloud используется платформа виртуализации VMware vSphere. 1cloud гарантирует доступность по SLA на уровне 99,9%. Главным вектором в развитии сервиса сотрудники 1cloud простоту и удобство работы с сервисом. Именно поэтому 1cloud постоянно дополняется всевозможными фичами призванными упростить жизнь конечного пользователя, например, возможность автоматического выставления счетов или возможность добавлять дополнительные диски различных типов. При этом, дизайн и устройство собственной панели управления 1cloud позволяют легко воспользоваться всем спектром возможностей пользователям с любым уровнем знаний в IT.
С той же целью в 1cloud разработали довольно обширную базу знаний, покрывающую основные потребности и вопросы пользователей, которая постоянно пополняется новыми статьями. Добавив к вышесказанному надежность, отказоустойчивость архитектуры 1cloud, весьма демократичные цены и качественную, вежливую техническую поддержку, работающую в режиме 24x7, вы получите представление о 1cloud.ru.
Аренда виртуальной инфраструктуры в 1cloud - это отличный выбор как для среднего и малого бизнеса, так и для частных лиц. Зайдите на сайт и вы сразу увидите конфигуратор виртуального сервера, а также его цену за месяц, сутки и час:
Выбирая 1cloud, Вы получаете сразу целый ряд выгод по доступным ценам:
Надежное оборудование High-End класса.
Возможность изменения конфигурации Ваших VPS практически налету.
Использование технологий High Availability и DRS позволяют гарантировать непрерывную доступность ваших виртуальных серверов и их высокую производительность (доступность по SLA 99,9 %).
Выделенный IPv4 для каждого виртуального сервера.
Тарификация каждые 10 минут и оплата только тех ресурсов, которые вы используете (при выключенном сервере оплата за RAM и CPU не списывается) позволяют экономить Ваши средства.
API, позволяющий автоматизировать операции в виртуальной среде.
Грамотная вежливая техподдержка, доступная в любой момент дня и ночи.
Собственная удобная и простая панель управления, с множеством возможностей:
- Изменять конфигурацию виртуального сервера
- Создавать частные сети
- Управлять DNS записями
- Создавать снапшоты виртуальных серверов
- Управлять резервными копиями серверов
- Работать с виртуальными серверами через web-консоль
- Создавать шаблоны виртуальных серверов и разворачивать из них новые сервера.
Удобные средства оплаты как для физических так и для юридических лиц (автовыставление счетов).
Финансовые закрывающие документы для юр. лиц.
Обширная, постоянно пополняющаяся база знаний.
При этом 1cloud постоянно развивают и улучшают свой сервис - оставляйте ваши комментарии. Подробнее о компании вы можете узнать по этой ссылке: https://1cloud.ru
Мы уже писали о том, что "растянутый" кластер VMware HA Stretched Cluster прекрасно работает и поддерживается вместе с отказоустойчивыми хранилищами Virtual SAN. Также мы писали о документе с лучшими практиками по построению таких кластеров, для которых требуется обеспечивать максимальную производительность.
Однако многие задаются вопросом - а как планировать ширину канала между площадками таких растянутых кластеров, чтобы обеспечить необходимую пропускную способность для синхронизации узлов кластера VMware Virtual SAN? В помощь таким пользователям компания VMware выпустила интересный документ "VMware Virtual SAN Stretched Cluster Bandwidth Sizing Guidance", в котором даются конкретные параметры и формулы для расчета необходимой пропускной способности между площадками.
Архитектура растянутого кластера в общем случае выглядит так:
Таким образом, имеет место быть 2 связи - между двумя площадками как узлами кластера, а также между каждой из площадок и компонентом Witness, следящим за состоянием каждой из площадок и предотвращающим сценарии Split Brain.
Для этих соединений рекомендуются следующие параметры:
Как известно, реальный трафик состоит из отношения операций чтения и записи, которое зависит от характера нагрузки. Например, в VDI-среде это отношение составляет примерно 30/70, то есть 30% - это операции чтения (read), а 70% - операции записи (write).
В среде растянутого кластера данные виртуальной машины всегда читаются с локальных узлов VSAN - это называется Read Locality. Ну а для операций записи, само собой, нужна определенная пропускная способность на другую площадку. Она рассчитывается как:
B = Wb * md * mr
где:
Wb - полоса записи данных.
md - множитель данных, он зависит от потока метаданных кластера VSAN и сервисных операций. VMware рекомендует использовать значение 1,4 для этого параметра.
mr - множитель ресинхронизации. Для целей ресинхронизации VMware рекомендует заложить в канал еще 25%, то есть использовать значение этого параметра 1,25.
Например, рабочая нагрузка у вас составляет 10 000 IOPS на запись (10 тысяч операций в секунду). Возьмем типичный размер операции записи в 4 КБ и получим параметр Wb:
Wb = 10 000 * 4KB = 40 MB/s = 320 Mbps
Мегабайты в секунду переводятся в мегабиты умножением на 8. Ну и заметим, что требование канала по записи нужно умножать на 1,4*1,25 = 1,75. То есть канал нужно закладывать почти в 2 раза больше от требований по записи данных.
Теперь считаем требуемую пропускную способность канала между площадками:
Многие из вас, следящие за новостями о лучшем продукте для создания отказоустойчивых хранилищ StarWind Virtual SAN, часто задаются вопросом - а чем это решение лучше существующих аналогов от VMware и Microsoft? Первый и наиболее очевидный ответ - цена. Просто посмотрите на то, сколько стоит VMware VSAN, и сравните это со стоимостью лицензий StarWind. Разницу вы почувствуете сразу.
Но это еще не все. Компания StarWind выпустила полезный каждому сомневающемуся документ "StarWind Virtual SAN: Differentiation [from competitors]", в котором весьма подробно рассмотрены преимущества продукта перед решениями от маститых вендоров.
Например, почему StarWind Virtual SAN лучше VMware Virtual SAN:
Для работы отказоустойчивых хранилищ StarWind нужно всего 2 узла (VMware требует минимум 3). Плюс StarWind не требует какой-то особенной инфраструктуры типа поддержки 10G Ethernet или SSD-дисков. У StarWind все проще.
VMware Virtual SAN лицензируется по числу процессоров ESXi плюс требуются лицензии на сам ESXi. У StarWind лицензия выйдет дешевле - вы можете лицензировать по числу узлов кластера хранилищ, либо весь датацентр сразу, и использовать бесплатные издания ESXi.
Кластер VMware Virtual SAN вы можете использовать только для платформы vSphere, а StarWind Virtual SAN можно использовать для хранения виртуальных машин на базе любого гипервизора - хоть ESXi, хоть Hyper-V, хоть XenServer.
StarWind Virtual SAN - это продукт, который сейчас находится в 8-й версии, а Virtual SAN - это всего лишь вторая версия решения. Поскольку это решение относится к самому нижнему уровню сервисов хранения датацентра, надежность работы решения является определяющим факторов.
Более подробно об этом и других продуктах для сравнения, в частности, Microsoft Storage Spaces, Microsoft Scale-Out File Server, HP Lefthand VSA, DataCore SANsymphony, Maxta и PernixData, вы можете узнать непосредственно из документа.
Некоторое время назад мы писали об очень серьезном баге в технологии Changed Block Tracking, обеспечивающей работу инкрементального резервного копирования виртуальных машин VMware vSphere 6. Баг заключался в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могли быть потеряны. Для первого бэкапа в этом нет ничего страшного, а вот вызываемая во второй раз функция QueryDiskChangedAreas технологии CBT не учитывала потерянные операции ввода-вывода, а соответственно при восстановлении из резервной копии такой бэкап был неконсистентным.
Мы писали про временное решение, заключающееся в отключении технологии CBT при снятии резервных копий продуктом Veeam Backup and Replication, но оно, конечно же, было неприемлемым, так как скорость бэкапов снижалась в разы, расширяя окно резервного копирования до неприличных значений.
И вот, наконец, вышло исправление этого бага, описанное в KB 2137545. Это патч для сервера VMware ESXi, который распространяется в виде стандартного VIB-пакета в сжатом zip-архиве.
Чтобы скачать патч, идите по этой ссылке, выберите продукт "ESXi Embedded and Installable" и введите в поле Enter Bulletin Number следующую строчку:
ESXi600-201511401-BG
Нажмите Search, после чего скачайте обновленный билд VMware ESXi 6.0 по кнопке Download:
Про патч в формате VIB-пакета написано вот тут, а про сам обновленный релиз ESXi вот тут. Для установки VIB на сервере ESXi используйте следующую команду:
Компания VMware выпустила очень познавательный документ "An overview of VMware Virtual SAN caching algorithms", который может оказаться полезным всем тем, кто интересуется решением для создания программных хранилищ под виртуальные машины - VMware Virtual SAN. В документе описан механизм работы кэширования, который опирается на производительные SSD-диски в гибридной конфигурации серверов ESXi (то есть, SSD+HDD).
SSD-диски используются как Performance tier для каждой дисковой группы, то есть как ярус производительности, который преимущественно предназначен для обеспечения работы механизма кэширования на чтение (Read cache, RC). По умолчанию для этих целей используется 70% емкости SSD-накопителей, что экспериментально было определено компанией VMware как оптимальное соотношение.
SSD-диски значительно более производительны в плане IOPS (тысячи и десятки тысяч операций в секунду), поэтому их удобно использовать для кэширования. Это выгодно и с экономической точки зрения (доллары на IOPS), об этом в документе есть наглядная табличка:
То есть, вы можете купить диск SSD Intel S3700 на 100 ГБ за $200, который может выдавать до 45 000 IOPS, а это где-то $0,004 за IOPS. С другой же стороны, можно купить за те же $200 диск от Seagate на 1 ТБ, который будет выдавать всего 100 IOPS, что составит $2 на один IOPS.
Кэш на чтение (RC) логически разделен на "cache lines" емкостью 1 МБ. Это такая единица информации при работе с кэшем - именно такой минимальный объем на чтение и резервирование данных в памяти используется. Эта цифра была высчитана экспериментальным путем в исследовании нагрузок на дисковую подсистему в реальном мире, которое VMware предпочитает не раскрывать. Кстати, такой же величины объем блока в файловой системе VMFS 5.x.
Помимо обслуживания кэша на SSD, сервер VMware ESXi использует небольшой объем оперативной памяти (RAM) для поддержки горячего кэша обслуживания этих самых cache lines. Он содержит несколько самых последних использованных cache lines, а его объем зависит от доступной памяти в системе.
Также в памяти хранятся некоторые метаданные, включая логические адреса cache lines, валидные и невалидные регионы кэша, информация о сроке хранения данных в кэше и прочее. Все эти данные постоянно хранятся в памяти в сжатом виде и никогда не попадают в своп. При перезагрузке или выключении/включении хоста кэш нужно прогревать заново.
Итак, как именно работает кэширование на SSD в VMware Virtual SAN:
1. Когда операция чтения приходит к Virtual SAN, сразу же включается механизм определения того, находятся ли соответствующие данные в кэше или нет. При этом запрашиваемые данные за одну операцию могут быть больше одной cache line.
2. Если данные или их часть не находятся в RC, то для них резервируется буфер нужного объема с гранулярностью 1 МБ (под нужное количество cache lines).
3. Новые аллоцированные cache lines вытесняют из кэша старые в соответствии с алгоритмом Adaptive Replacement Cache (ARC), который был лицензирован VMware у IBM.
4. В случае промаха кэша каждое чтение одной cache line с HDD разбивается на чанки размером 64 КБ (этот размер тоже был определен экспериментально в ходе исследований). Это сделано для того, чтобы не забивать очередь на чтение с HDD "жирной" операцией чтения в 1 МБ, которая бы затормозила общий процесс ввода-вывода на диск.
5. В общем случае, одна операция чтения запрашивает лишь часть данных одной cache line, а первыми читаются именно нужные 64 КБ чанки с HDD-диска от этой cache line.
6. Запрошенные с HDD-диска данные сразу отдаются к подсистеме вывода и направляются туда, откуда их запросили, а уже потом в асинхронном режиме они попадают в соответствующие cache lines кэша и под каждую из них выделяется буфер 1 МБ в памяти. Таким образом устраняются потенциальные затыки в производительности.
В документе описаны также и механики работы кэша на запись (Write cache), для которого используется техника write-back, а также рассматриваются All Flash конфигурации. Читайте - это интересно!
На днях компания Microsoft выпустила очередное обновление технологического превью следующего поколения своей серверной платформы - Windows Sever 2016 Technical Preview 4 (а также и System Center 2016).
В новой версии появилось несколько важных нововведений, многие из которых непосредственно касаются технологий виртуализации:
1. Поддержка контейнеров приложений Windows Server Containers и Hyper-V Containers.
Эта поддержка появилась еще в Technical Preview 3, но в этом обновлении была существенно расширена. Напомним, что мы уже писали об этом вот тут. В новой версии Windows Server будут поддерживаться как контейнеры Docker на базе механизма Windows Server Containers в среде физических серверов:
так и Hyper-V Containers на базе виртуальных машин (подробнее об этом - тут):
В прошлом превью поддерживалась только технология Windows Server Containers, теперь же Microsoft сделала публичной технологию Hyper-V Containers. Она позволяет развертывать виртуальные сервисы в контейнерах в средах с повышенной изоляцией на базе виртуальных машин на платформе Hyper-V. Аналогичный подход компания VMware предлагает и в своей платформе vSphere с технологией vSphere Integrated Containers.
Ниже можно посмотреть живую демонстрацию технологии Hyper-V Containers от легендарного Марка Руссиновича:
Документация о контейнерах на платформе Windows Server доступна вот тут.
2. Улучшения Nano Server.
Напомним, что об этом решении мы также писали вот тут. Nano Server как раз подходит как среда исполнения для контейнеров Docker (но не только). По сравнению с прошлым превью Windows Server в данной версии Nano Server появились следующие улучшения:
Поддержка роли DNS server
Поддержка роли IIS
Поддержка технологии MPIO
Средства Virtual Machine Manager (VMM)
Поддержка интерфейса мониторинга SCOM
Работа с режимом PowerShell DSC (Desire State Configuration) для развертывания и настройки новых систем
Поддержка технологии DCB (Data Center Bridging)
Улучшенный установщик Windows Server Installer
Инструментарий WMI для механизма Windows Update
Поддержка пакетов AppX
3. Поддержка вложенной виртуализации Hyper-V.
Об этом мы весьма подробно писали вот тут. Ранее эти средства были доступны в сборках Windows 10, теперь же возможность была добавлена и в Windows Server.
4. Поддержка Direct Device Assignment (проброс устройств на шине PCIe).
Теперь в Windows Server появился полноценный прямой проброс PCI-устройств в виртуальные машины. Если ранее поддерживалась только технология SR-IOV для сетевых адаптеров, то теперь Direct Device Assignment можно применять для любых устройств на шине PCI Express, например, для устройств хранения на базе Flash-накопителей (см. раскрытое устройство Dell):
Это позволит превратить вашу виртуальную машину в сервер хранения как Virtual Storage Appliance (например, для тех же виртуальных машин) с прямым доступом к хранилищу.
5. Улучшения технологии Storage Spaces Direct (S2D).
Теперь в рамках данной технологии появилась поддержка виртуальных дисков Multi-Resilient Virtual Disks, которые представляют собой так называемый "3D-RAID", то есть каждый виртуальный диск содержит в себе зеркальные копии данных других дисков, кодированные по алгоритму с контролем четности (это позволяет создавать избыточность любой глубины на уровне виртуальных дисков):
Все данные записываются в Mirror tier (это часть виртуального диска с наибольше производительностью underlying storage), а в Parity tier уходят избыточные данные для коррекции ошибок в случае сбоев. Операционная система ReFS всегда записывает данные сначала в mirror tier, а если требуется апдейт parity tier, то он идет следом. Таким образом достигается полная надежность рабочего процесса изменения данных:
Нечто подобное (на простейшем уровне) используется в решении VMware Virtual SAN (а в следующей версии будет еще круче). Более подробнее о технологии S2D можно почитать вот тут.
6. Прочие улучшения.
Среди прочего, появилась поддержка технологии Virtual Machine Multi-Queue для виртуальных машин, позволяющей максимально эффективно использовать сети 10G+. Также были расширены возможности технологии Just Enough Administration (JEA), предоставляющей только самые необходимые инструменты для таких серверных ролей, как, например, контроллер домена, которые требуют максимального уменьшения поверхности возможной атаки.
Также интересно, что теперь в разделе документации по платформе Hyper-V в Windows 10 была добавлена возможность самому внести вклад в разделы о продуктах и технологиях (нужно нажать "Contribute to this topic"):
Скачать Windows Sever 2016 Technical Preview 4 можно по этой ссылке. Подробно обо всех нововведениях обновленного превью можно прочитать вот здесь.
Компания VMware на днях представила проект VMware Sample Exchange, представляющий собой портал, где разработчики выкладывают для загрузки различные шаблоны сценариев, помогающие в решении повседневных задач по администрированию виртуальной инфраструктуры VMware vSphere.
На этом сайте можно найти не только сценарии сотрудников VMware на языках/оболочках PowerShell/PowerCLI, Python, Ruby, Java и других, но и предложить свой вариант решения задачи или запросить его у сообщества профессионалов, которые будут там тусоваться (потому и называется Exchange). На данный момент на портале есть контент от таких известных многим людей, как Alan Renouf и William Lam.
Сейчас загружать свой контент и сценарии могут только носители звания VMware vExpert и авторизованные со стороны VMware люди, но в релизной версии сервиса это смогут сделать все желающие (на данный момент обсуждения по этим вопросам находятся вот тут).
В левой колонке портала находятся фильтры по категориям применения сценариев (платформы, решения VMware и бизнес-задачи):
А также по языку программирования/интерфейсу:
Пока в библиотеке всего 260 сэмплов (нераспиханных по категориям и интерфейсам), но будем надеяться, что скоро коллекция существенно расширится и там наведут порядок.
RSS
