Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4250 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: Сколько стоят артисты на пати VMworld?

Новые возможности VMware Site Recovery Manager 6.5.1.


Как вы знаете, недавно компания VMware сделала доступным для загрузки обновление платформы виртуализации vSphere 6.5 Update 1, одновременно с которым были выпущены апдейты и других продуктов. Одним из них стал релиз продукта для обеспечения катастрофоустойчивости VMware Site Recovery Manager 6.5.1 (SRM).

Напомним, что выпуск версии SRM 6.5 состоялся осенью прошлого года, и там было весьма много новых возможностей. В этом же небольшом обновлении основной фичей является поддержка последней версии платформы vSphere, но не только. Давайте посмотрим на нововведения VMware SRM 6.5.1:

  • VMware Site Recovery Manager 6.5.1 теперь полностью совместим с VMware vSphere 6.5 Update 1 и средствами репликации VMware vSphere Replication 6.5.1, которые также были выпущены с апдейтом vSphere.
  • Доступна миграция vCenter Server Virtual Appliance 6.0 Update 3 на vCenter Server Virtual Appliance 6.5 Update 1, что дает пользователям прямой путь апгрейда с SRM 6.1.2 на SRM 6.5.1 (если же вы делаете апгрейд с версии SRM 6.0, то надо будет сначала обновиться на 6.1.2).
  • Поддержка новых внешних баз данных:
    • Microsoft SQL Server 2014 Service Pack 2
    • Microsoft SQL Server 2016 Service Pack 1
  • Поддержка новых гостевых ОС:
    • Windows Server 2016
    • CentOS 6.9
    • RHEL 7.3.5
    • Ubuntu 17.04 non Long Term Support (LTS)
  • Исправления ошибок

Скачать VMware Site Recovery Manager 6.5.1 можно по этой ссылке.


Таги: VMware, SRM, Update, DR

Репликация назначения прав для инфраструктуры VMware Horizon 7 и App Volumes.


В последнее время от продуктовой команды VMware Horizon идет много новостей. Мы уже писали о документах "VMware Horizon Apps Performance Reference Architecture" и "Best Practices for Published Applications and Desktops in VMware Horizon Apps and VMware Horizon 7", а также о том, что VMware Horizon Cloud будет скоро доступен на платформе Microsoft Azure.

На днях пришла еще одна интересная новость - вышел документ "VMware Horizon 7 Enterprise Edition Multi-Site Reference Architecture", в котором рассказывает о том, как строить архитектуру решения Horizon 7 для нескольких площадок в целях отказо- и катастрофоустойчивости.

Как один из вариантов резервирования инфраструктуры App Volumes там рассматривается поддержание резервной инфраструктуры серверов App Volumes Managers и баз данных SQL Server на каждой площадке (их может быть не только две, но и больше):

Но проблема в том, что права доступа пользователей (Entitlements) в этом случае не синхронизированы (они хранятся на SQL Server), что повлечет за собой проблемы доступа при переключении на резервную площадку.

Для решения этой проблемы коллеги написали PowerShell-скрипт, который позволяет синхронизировать назначения прав (Entitlements) на основной и резервной площадках. При этом данный скрипт не реплицирует данные AppStacks, которые можно перенести обычным копированием, либо автоматизировать этот процесс за счет настройки Storage Groups, как это описано в документе "App Volumes Deployment Considerations".

Сначала проверьте работоспособность данного сценария, а потом уже можно добавить его, например, в планировщик Windows.


Таги: VMware, App Volumes, DR, Horizon, PowerShell

Новое на VMware Labs - утилита DRS Lens для более глубокого понимания механизма балансировки нагрузки.


На сайте проекта VMware Labs появилась очередная заслуживающая внимания утилита DRS Lens, поставляемая в виде виртуального модуля (Virtual Appliance). Она позволяет администраторам виртуальных инфраструктур получить больше информации о работе механизма балансировки нагрузки на хост-серверы VMware vSphere DRS.

Полученная информация располагается на 5 дэшбордах, которые дают представление о различных аспектах DRS.

Summary

Это вкладка с общей информацией. Тут агрегируются данные с других разделов в удобное представление для администратора.

Cluster Balance

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

VM Happiness

На этом дэшборде впервые можно увидеть метрику VM happiness в графическом интерфейсе. Здесь представлена диаграмма, показывающая число ВМ, которые "счастливы" в кластере (то есть работают под нормальной нагрузкой) и число тех, которые "несчастны" (работают в стрессовых условиях при недостатке ресурсов). Пользователь может выбирать отдельные ВМ для просмотра метрик производительности, которые влияют на VM happiness, такие как %CPU ready, memory swapped и т.п.

vMotions

Этот дэшборд предоставляет суммаризованную информацию о миграциях vMotion, которые происходили в кластере по инициативе DRS или пользователя. Для каждого временного периода можно посмотреть разбивку миграций по каждому из этих двух видов. Это не только позволяет наблюдать за количественными показателями работы DRS в миграциях, но и оценить, не делают ли администраторы слишком много миграций vMotion, что влияет на баланс кластера.

Operations

На этом дэшборде можно отслеживать различные операции (задачи на стороне vCenter Server), которые выполнялись с течением времени. Администраторы могут сопоставлять информацию о задачах с этого дэшборда с данными других вкладок.

Все эти вещи позволят более детально ответить на вопрос - а что же именно и когда механизм DRS делает с виртуальными машинами при перемещении между хост-серверами ESXi.

Скачать VMware DRS Lens можно по этой ссылке. После развертывания виртуального модуля утилитой можно пользоваться по следующим адресам:

https://<appliance-ip>/drs/app

http://<appliance-ip>:8080/drs/app


Таги: VMware, Labs, DRS, vSphere, VMachines, Virtual Appliance

Что такое и как работает VMware vCloud Availability.


На днях компания VMware выпустила чуть обновленную версию своего продукта VMware vCloud Availability 1.0.1, предназначенного для создания резервной инфраструктуры в одном из публичных облаков сервис-провайдеров на основе VMware vCloud Director (так называемая услуга Disaster-Recovery-as-a-Service, DRaaS).

Сервис-провайдер, участвующий в программе vCloud Air Network (vCAN), предоставляет ресурсы своего облака как Disaster Recovery площадку на случай аварии в датацентре клиента.

Репликация данных виртуальных машин происходит с помощью виртуального модуля VMware vSphere Replication Appliance (VSRA), который развертывается только на стороне датацентра клиента. Технология vSphere Replication позволяет откидывать реплики виртуальных машин в удаленную инфраструктуру сервис-провайлера, при этом как только данные покидают хост VMware ESXi - они сразу же шифруются.

Таким образом, никто не получит доступ к вашим ВМ в удаленном датацентре:

Архитектура решения VMware vCloud Availability выглядит следующим образом:

Модуль vSphere Replication Appliance содержит в себе несколько компонентов, в частности vCloud Tunneling Agent (vCTA), который обеспечивает безопасное SSL-соединение с датацентром сервис-провайдера. На стороне же провайдера vCAN работают так называемые Cloud Proxy Cells, которые принимают данные и являются составляющей частью решения vCloud Director.

Также в составе vCD есть Hybrid DR API, через который происходит коммуникация с компонентом vSphere Replication Cloud Service (vRCS). vRCS предназначен для того, чтобы постоянно информировать vCloud Director о составе получаемой инфраструктуры клиента, конфигурациях виртуальных машин, а также их размещении в провайдерском датацентре. В этом случае VSRA делает все то же самое, что он и делал бы для инфраструктуры онпремизной репликации через vCenter.

Ну а на видео ниже можно узнать, как происходит развертывание решения VMware vCloud Air Disaster Recovery для инфраструктуры клиента, который настраивает соединение с инфраструктурой сервис-провайдера:

Вот тут детально рассказывается о предварительных требованиях для создания такой инфраструктуры аварийного восстановления:

Ну а здесь, собственно, мы можем посмотреть, как конфигурируется удаленный (резервный) сайт под восстановление инфраструктуры предприятия в случае аварии:

Таким вот образом настраивается репликация в VSRA:

А на последнем видео - показан тест восстановления инфраструктуры в облаке после сбоя в датацентре клиента:

Больше о продукте VMware vCloud Availability и решении vCloud Air Disaster Recovery можно узнать по этим ссылкам:


Таги: VMware, vCloud, Air, Replication, DR

Анонсы VeeamON 2017: День 3 - выпуск Veeam Management Pack v8 Update 4, бэкап Office 365 и прочее.


Последний день конференции VeeamON 2017, проходящей сейчас в Новом Орлеане, оказался не менее интересным и богатым на анонсы, чем предыдущие (вот они - День 0 / День 1 / День 2).

Вот основные анонсы последнего дня конференции:

Первый в списке - это новая технология Veeam Disaster Recovery in Microsoft Azure, предназначенная для восстановления инфраструктуры в облако Microsoft Azure и состоящая из двух основных компонентов - техника прямого восстановления из резервных копий и реплик непосредственно в облако Azure, а также утилита предоставления и восстановления сетевого доступа Veeam PN (она уже доступна как релиз-кандидат).

В рамках анонса этой возможности прежде всего было рассказано о новой утилите Veeam PN, которая представляет собой надстройку над OpenVPN, позволяющую создать инфраструктуру облачного восстановления не только данных, но и преобразования сетевых настроек для восстановления доступа к сетевым сервисам в случае восстановления инфраструктуры в резервном облаке Azure.

При этом большой плюс подхода Veeam DR in Microsoft Azure - это то, что компании не потребуется оплачивать и поддерживать инфраструктуру на стороне Azure - она развертывается и конфигурируется по запросу (для старта не нужна даже учетная запись Azure).

Следующий интересный анонс - это продукт Veeam Backup for Microsoft Office 365 версии 1.5, представляющий собой средство создания резервных копий из облака Microsoft на уровне приложения.

Также было рассказано о возможностях второй версии этого решения, которая также будет выпущена вскоре за 1.5. Теперь Veeam Backup сможет делать резервные копии SharePoint и данных хранилища OneDrive for Business.

Ну и заключительный анонс - это объявление о доступности для загрузки финальной версии продукта Veeam Management Pack (MP) for System Center v8 Update 4.

Его уже можно скачать с официального сайта Veeam, а вот его новые возможности:

1. Интеграция с Microsoft Operations Management Suite (OMS) и новые дэшборды.

Veeam MP теперь имеет интеграцию с OMS и предоставляет агрегированные данные мониторинга через Azure-based OMS консоль. Если у вас Microsoft System Center Operations Manager (SCOM) подключен к функционирующему сервису OMS с подпиской, то данные будут агрегироваться там с периодом 15 минут.

Veeam MP будет отображать состояния различных объектов инфраструктуры, таких как VMware vSphere, Microsoft Hyper-V и системы Veeam Backup & Replication. Процесс интеграции выглядит следующим образом:

  1. Испорт файлов MBP из Veeam MP Resource Kit в SCOM.
  2. Добавление представлений OMS из Veeam MP Resource Kit в консоль OMS.

Эти представления в OMS можно организовать каким угодно способом:

По умолчанию доступны следующие представления:

  • Veeam Morning Coffee Dashboard for VMware vSphere
  • Veeam Morning Coffee Dashboard for Microsoft Hyper-V
  • Veeam Morning Coffee Dashboard for Backup
  • Veeam Management Pack health dashboard

Например, Veeam Morning Coffee Dashboard дает информацию об общем состоянии систем резервного копирования и исполняемых задачах бэкапа:

2. Новые способы идентификации и решения проблем.

Несколько разнесенных систем SCOM можно объединить в едином представлении OMS и видеть общее состояние виртуальных датацентров под управлением Veeam MP. Также в едином пространстве OMS можно наблюдать за физическими и виртуальными инфраструктурами.

3. Алармы и отчеты.

Veeam MP, работая в паре с OMS, дает возможность просматривать OMS-алерты от серверов управления виртуальной инфраструктурой (vCenter или SCVMM). Высокоуровненые отчеты о состоянии инфраструктуры можно формировать для руководства.

4. Превью технологии Power BI для Veeam MP.

За счет использования коннектора OMS to Power BI можно отсылать данные Veeam MP в систему Power BI для дальнейшего анализа и визуализации. Например, с помощью следующего запроса можно сформировать датасет в Power BI:

"Type=Perf CounterName="cpuUsedPct" ObjectName="VMware vSphere Host" InstanceName<>_Total"

А дальше можно уже визуализовать его:

Скачать Veeam Management Pack (MP) for System Center v8 Update 4 можно по этой ссылке.


Таги: Veeam, DR in Azure, Cloud, Backup, MP, Update, VeeamPN, VeeamON, Microsoft, SCOM, Azure

Почему Witness VM нельзя перекрестно размещать на двух площадках для двух растянутых кластеров.


Интересный пост написал Cormac Hogan, касающийся конфигурации растянутых кластеров VMware vSphere Stretched Clusters и размещения компонентов Witness VM для них. Если у вас есть 2 площадки и два растянутых кластера VMware vSAN между ними, то сама собой напрашивается следующая конфигурация:

Но так делать, конечно же, нельзя - и вот почему. Допустим у вас отказал сайт 2, на котором не было Witness-машин. Только в этом случае у вас будет все хорошо - для каждого из кластеров будет кворум (Witness VM+узел), и они продолжат нормальную работу.

Но если у вас откажет сайт 1, то вы лишитесь сразу двух Witness VM (и WA, и WB), узлы на площадке 2 окажутся изолированными, и все виртуальные машины на них будут недоступны (нет кворума):

А что для случая, если машины Witness VM разместить на разных площадках?

Да тоже ничего хорошего - откажет сайт 1, вследствие чего виртуальные машины выжившего сайта 2 кластера A будут недоступны (не будет кворума, ведь WA, присматривающий за эти узлом умер на первой площадке). Ну а поскольку WB является как раз виртуальной машиной, данного узла кластера A ставшего недоступным, то и у выжившего узла кластера B также не будет кворума. В итоге и виртуальные машины кластера B при данном сбое будут недоступны.

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


Таги: VMware, vSphere, HA, DR, vSAN, Blogs

Новый документ - "DRS Cluster Management with Reservation and Shares".


Все администраторы платформы VMware vSphere знают, что такое параметры Shares и Reservation, но не все понимают, как именно они работают для виртуальных машин и пулов ресурсов. Мы уже затрагивали эту тему для виртуальных машин, не погружаясь в распределение ресурсов между пулами (хотя там все работает точно так же).

Основным источником знаний о Reservation и Shares является документ "Resource Management Guide", однако он большой и нудный, а на днях VMware выпустила более простую версию, сфокусированную на управлении кластером DRS с точки зрения резерваций и шар - "DRS Cluster Management with Reservation and Shares".

Именно из этого документа лучше узнать, как работают Shares (распределение ресурсов) и Reservations (гарантирование ресурсов) в рамках отдельных виртуальных машин, пулов ресурсов в рамках кластера DRS с учетом возможности заимствования ресурсов из родительского пула (expandable reservation).

Конечно же, если вы администратор платформы VMware vSphere, то вы должны были разобраться с этим всем еще в самом начале, но если какие-то аспекты работы механизмов гарантирования и распределения ресурсов вам остались непонятными, обязательно пробегитесь по документу "DRS Cluster Management with Reservation and Shares".


Таги: VMware, DRS, Whitepaper, Performance

Неделя новых штук на VMware Labs: Cluster Rules Manager (CRM).


Даже для опытных администраторов VMware vSphere понимание всех аспектов работы механизма DRS является непростой задачей. Чтобы облегчить понимание действующих правил DRS (affinity и anti-affinity) в кластере для отдельных виртуальных машин, а также на уровне всего датацентра, сотрудники VMware на сайте проекта Labs выпустили очередную утилиту Cluster Rules Manager (CRM).

С помощью CRM, построенного на базе модуля с веб-интерфейсом для Apache Tomcat, можно делать следующие вещи:

  • Аудит правил anti-affinity (несуществования ВМ на одном хосте) по всем машинам в рамках vCenter Server.
  • Импорт правил DRS affinity сразу из нескольких серверов vCenter.
  • Экспорт правил DRS affinity в новый vCenter.
  • Отчет о всех действующих правилах DRS с подробными параметрами в реальном времени, содержащий различные интеллектуальные метрики. Его можно сделать на уровне всего vCenter, виртуальных датацентров или кластеров. Отчет можно экспортировать и сохранить на диске.
  • Отчет об ассоциированных с виртуальными машинами правилах. Этот отчет также можно сделать на уровне всего vCenter, виртуальных датацентров, кластеров или отдельных ВМ.
  • Возможность соединиться с другим сервером vCenter прямо из интерфейса.

Скачать VMware Cluster Rules Manager можно по этой ссылке. Также полезно будет почитать документы Installation Guide и FAQ.


Таги: VMware, Labs, DRS, vSphere, VMachines

VMware predictive DRS - умный алгоритм для обработки нагрузок предприятия.


Многие из вас читали, что в новой версии VMware vSphere 6.5 появилась экспериментальная поддержка механизма Predictive DRS, который проактивно предпринимает действия по выравниванию нагрузки виртуальных машин на хосты ESXi, еще до того, как эта нагрузка придет.

Посмотрим как раньше работал VMware Distributed Resource Scheduler (DRS):

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

Поэтому появился сбалансированный метод (Balanced). В этом случае DRS старается поддерживать баланс по нагрузке на хосты кластера (или даже между кластерами), чтобы не было перекосов в ту или другую сторону. Работает этот метод совместно с продуктом vRealize Operations (vROps), который собирает метрики с хостов и старается поддерживать баланс в виртуальном датацентре:

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

Поэтому в VMware решили применить другой подход - Predictive DRS. Суть этого метода проста - компонент vROps ежедневно собирает сотни различных метрик со всех объектов виртуального датацентра (хосты, ВМ, хранилища). Эти метрики "обучают" механизм vROps, который каждую ночь анализирует данные о производительности хостов и формирует так называемые Dynamic Thresholds:

Predictive DRS производит очень сложный анализ на основе 10 различных алгоритмов и формирует коридор производительности "нормального" поведения виртуальных машин (обозначен на картинке серым). Границы этого коридора и есть Dynamic Thresholds, при выходе за границы которых в данное время, поведение в кластере считается аномальным. Работает этот механизм на уровне каждой виртуальной машины.

И тут самое интересное - Predictive DRS позволяет заранее понять, что на таких-то хостах виртуальные машины будут биться за ресурсы через некоторое время, и проактивно начинает мигрировать виртуальные машины, готовясь к ситуации изменения нагрузки:

То есть, синяя линия - это то, как будет (а точнее, как обычно было раньше - ведь так, скорее всего, будет и сегодня), а вот красная линия - это то, что подается на вход обычного DRS, чтобы он заранее начинал действия по подготовке ко всплеску нагрузки, который произойдет через некоторое время (например, бухгалтерия придет к 9-00 и будет включать свои виртуальные десктопы). В этот момент их, например, можно поддержать простаивающими хостами ESXi, где хостятся десктопы ленивых менеджеров, приходящих к 11 утра.

Ну а какой метод нужно использовать? VMware рекомендует использовать все три, в зависимости от ситуации:

Ну и отметим, что этот функционал доступен только в рамках решения vRealize Operations, о котором также можно почитать вот тут.


Таги: VMware, DRS, vROps, Update, vSphere

Анонсирован VMware Site Recovery Manager 6.5 - что нового?


На прошедшей конференции VMworld Europe 2016 в Барселоне компания VMware сделала довольно много анонсов новых продуктов, доступность которых ожидается до конца этого года. Мы уже писали о некоторых из них:

В этой заметке мы рассмотрим новые возможности средства для обеспечения катастрофоустойчивости виртуальных датацентров - VMware Site Recovery Manager 6.5. Напомним, что о прошлой версии SRM 6.1 мы уже писали вот тут.

Итак, что нового в VMware SRM 6.5:

1. Полная совместимость с VMware vSphere 6.5.

Это включает в себя:

  • Полную интеграцию с возможностью vCenter HA. SRM продолжит функционировать в штатном режиме, если vCenter HA сработает на восстановление сервера управления в случае сбоя.
  • Полную поддержку процесса миграции с vCenter на vCSA. Если пользователь произведет такую миграцию, то с точки зрения SRM это будет апгрейд vCenter с его надстройкой SRM - и все продолжит работать.
  • Защиту виртуальных машин, использующих функции шифрования виртуальных дисков при использовании Storage Policy-Based Protection Groups (SPPGs).
  • Поддержку двухфакторной аутентификации, такой как RSA SecurID.
  • Интеграцию с новыми vSphere Guest Operations API. Это означает, что изменения в IP-адресе машины и сценарии в ней исполняемые теперь станут более безопасными.

2. Полная совместимость с VMware Virtual SAN 6.5.

SRM 6.5 полностью поддерживается для инфраструктуры виртуальных хранилищ VSAN 6.5, а также и для предыдущих версий этого продукта для механизма vSphere Replication. Во всех остальных аспектах SRM и VSAN также отлично работают вместе, что позволяет строить гибкие и защищенные распределенные инфраструктуры.

3. Совместимость SRM и VVOLs.

В дополнение ко всем новым возможностям, которые были анонсированы в Virtual Volumes (VVols) 2.0, SRM 6.5 теперь поддерживает защиту виртуальных машин на VVols средствами технологии vSphere Replication.

4. Улучшения API и плагина к vRealize Orchestrator.

В плане программных интерфейсов SRM 6.5 было сделано множество улучшений. В плане API появилось несколько новых функций, которые будут описаны в отдельном документе (для версии 6.1 они есть вот тут). Плагин vRealize Orchestrator (vRO) для SRM использует эти интерфейсы для реализации коммуникации между продуктами и интеграции необходимых рабочих процессов SRM в vRO (подробнее об этом тут).

Вот какие функции теперь также полностью автоматизируемы через API:

  • Add a Test Network Mapping
  • Get Test Network Mappings
  • Remove a Test Network Mapping
  • Remove Folder Mapping
  • Remove Network Mapping
  • Remove Resource Mapping
  • Remove Protection Group
  • Remove Replicated VM From VR Group
  • Unprotect Virtual Machines
  • Add Test Network Mapping to Recovery Plan
  • Create Recovery Plan
  • Delete Recovery Plan
  • Initiate Planned Migration Recovery Plan
  • Remove Protection Group From Recovery Plan
  • Remove Test Network Mapping From Recovery Plan
  • Discover Replicated Devices

Вкупе с функциями API прошлых версий, эти функции покрывают практически всю функциональность SRM.

Кроме того, SRM 6.5 теперь полностью поддерживает "тихую" (unattended/silent) установку и апгрейды. Это позволяет экономить на развертывании и обслуживании компонентов виртуальной инфраструктуры.

5. vSphere Replication RPO.

Для технологии репликации vSphere Replication, на базе которой работает SRM, теперь поддерживаются политики контрольной точки восстановления (Recovery Point Objective, RPO), которые доходят до 5 минут в некоторых архитектурах. Это дешевый и надежный метод реализации катастрофоустойчивости, а функции vSphere Replication есть уже в издании vSphere Essentials Plus и более поздних редакциях.

6. Новый vROps SRM Management Pack.

Теперь решение для комплексного мониторинга и решения проблем в виртуальной инфраструктуре vRealize Operations имеет специальный пак для SRM, который позволяет осуществлять мониторинг самого сервера SRM, протекшн групп и планов восстановления прямо из консоли vROps. Это позволяет добавить SRM в линейку ИТ-систем, наблюдаемых администратором датацентра из единой консоли vROps.

Доступность VMware SRM 6.5 ожидается ближайшие пару месяцев. Следите за обновлениями - мы напишем об этом.


Таги: VMware, SRM, Update, DR

Как сохранить иерархию пулов ресурсов в кластере при отключении VMware DRS.


Многие администраторы VMware vSphere бояться отключать механизм балансировки нагрузки VMware DRS из-за того, что после отключения DRS потеряется иерархия пулов ресурсов, которая была рассчитана и выстроена.

Не стоит этого бояться, ведь при снятии с кластера галочки DRS в vSphere Web Client вас спросят, нужно ли сохранить иерархию ресурсных пулов (снапшот), которая может быть восстановлена, когда вы снова включите DRS:

Сохраняем ее в файл:

Если вы нажмете правой кнопкой на кластере в Web Client, вы увидите загрееный пункт "Restore Resource Pool Tree" в меню "All vCenter Actions":

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

Все довольно просто. Если, все-таки, что-то осталось непонятным - обратитесь к KB 2032893 или посмотрите вот это обучающее видео от VMware:


Таги: VMware, vSphere, DRS, Обучение

Новая утилита на VMware Labs - DRS Doctor для диагностики кластеров.


На сайте проекта VMware Labs, где очень часто появляются полезные штуковины для продуктов VMware, была выпущена очередная интересная утилита - DRS Doctor. Это средство позволяет проводить диагностику поведения DRS-кластера в рамках сервера VMware vCenter. DRS Doctor собирает такую информацию, как состояние кластера, распределение рабочей нагрузки, миграции DRS и многое другое. Все это объединяется в удобном и человекочитаемом формате логов.

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

DRS Doctor соединяется с vCenter и отслеживает действия, которые происходят в кластере DRS, в реальном времени. Самое интересное, что утилита выводит причину для каждой миграции DRS, что раньше было доступно только в файлах дампов. Так можно узнать, чем руководствуется DRS при выборе хоста для vMotion виртуальных машин между ними.

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

Утилита поставляется в качестве средства командной строки для Linux. Для работы вам понадобится установленный Python. Инструкции по установке на CentOS доступны здесь, а скачать DRS Doctor можно по этой ссылке.


Таги: VMware Labs, DRS, Troubleshooting, vSphere

Бесплатный вебинар StarWind о восстановлении после сбоев - Minimize downtime after blackouts, recover IT infrastructure easier.


Компания StarWind Software, производитель главного решения Virtual SAN для создания отказоустойчивых программных хранилищ под виртуализацию, 30 июня проведет интересный вебинар "Minimize downtime after blackouts, recover IT infrastructure easier", посвященный средствам восстановления после сбоев (Disaster Recovery).

На вебинаре речь пойдет об одном из вариантов сбоев - блэкауте, то есть когда вам отключили электричество настолько, что мощности аккумуляторов / генераторов не хватило. В этом случае вам потребуется специальное ПО, которое позволит восстановить работоспособность ИТ-сервисов на основной или удаленной инфраструктуре.

Обо всем этом вы сможете послушать и пообсуждать (в том числе, на русском языке) на бесплатном вебинаре StarWind, который пройдет 30 июня в 15-00 по московскому времени.

Регистрируйтесь!


Таги: StarWind, DR, Webinar, Virtual SAN

Сценарии, когда нужно отключить Site / Data Locality для растянутого кластера VMware Virtual SAN.


Какое-то время назад мы писали о функции Data Locality, которая есть в решении для создания отказоустойчивых кластеров VMware Virtual SAN. Каждый раз, когда виртуальная машина читает данные с хранилища, они сохраняются в кэше (Read Cache) на SSD-накопителе, и эти данные могут быть востребованы очень быстро. Но в рамках растянутого кластера (vSphere Stretched Cluster) с высокой скоростью доступа к данным по сети передачи данных, возможно, фича Site / Data Locality вам не понадобится. Вот по какой причине.

Если ваши виртуальные машины часто переезжают с хоста на хост ESXi, при этом сами хосты географически разнесены в рамках VSAN Fault Domains, например, по одному зданию географически, то срабатывает функция Site Locality, которая требует, чтобы кэш на чтение располагался на том же узле/сайте, что и сами дисковые объекты машины. Это отнимает время на прогрев кэша хоста ESXi на новом месте для машины, а вот в скорости в итоге особой прибавки не дает, особенно, если у вас высокоскоростное соединение для всех серверов в рамках здания.

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

[root@esxi-01:~] esxcfg-advcfg -g /VSAN/DOMOwnerForceWarmCache

Value of DOMOwnerForceWarmCache is 0

Устанавливаем значение в 1, если хотим отключить принудительный прогрев кэша при смене площадки размещения машины:

[root@esxi-01:~] esxcfg-advcfg -s 1 /VSAN/DOMOwnerForceWarmCache

Value of DOMOwnerForceWarmCache is 1

Таги: VMware, Virtual SAN, DR, Stretched, HA, Performance

Руководство по асинхронной репликации для StarWind Virtual SAN.


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

Пару месяцев назад компания StarWind выпустила интереснейший документ на эту тему - "Asynchronous Replication. Configuring Scheduled Snapshots":

В документе приведены как общие сведения об устройстве механизма асинхронной репликации данных StarWind Virtual SAN, так и подробные пошаговые инструкции по его настройке. Также советуем посмотреть еще один документ StarWind об асинхронной репликации.


Таги: StarWind, Virtual SAN, DR, Whitepaper

Новый документ: VMware Site Recovery Manager 6.1 Technical Overview.


Компания VMware еще в августе выпустила полезный технический документ VMware Site Recovery Manager 6.1 Technical Overview, в котором описываются основные возможности средства для создания катастрофоустойчивых инфраструктур VMware SRM 6.1.

Основные сведения, которые можно почерпнуть из небольшого 22-страничного документа:

  • варианты использования решения SRM
  • основные топологии при построении архитектуры (active/active, active/passive и т.д.)
  • развертывание и настройка продукта
  • возможности механизма репликации
  • сведения о настройке Protection Groups
  • настройка и использование планов аварийного восстановления (Recovery Plans)
  • рабочие процессы по тестированию аварийного восстановления, собственно аварийному восстановлению (Failover), а также возврату рабочей инфраструктуры с резервной на основную (Failback)

Таги: VMware, SRM, Whitepaper, DR

Конфигурация "растянутого" кластера VMware HA Stretched Cluster вместе с отказоустойчивыми хранилищами Virtual SAN.


Недавно Cormac Hogan написал интересный пост о том, как нужно настраивать "растянутый" между двумя площадками HA-кластер на платформе VMware vSphere, которая использует отказоустойчивую архитектуру Virtual SAN.

Напомним, как это должно выглядеть (два сайта на разнесенных площадках и witness-хост, который обрабатывает ситуации разделения площадок):

Основная идея такой конфигурации в том, что при отказе отдельного хоста или его компонентов виртуальная машина обязательно должна запуститься на той же площадке, где и была до этого, а в случае отказа всей площадки (аварии) - машины должны быть автоматически запущены на резервном сайте.

Откроем настройки кластера HA. Во-первых, он должен быть включен (Turn on vSphere HA), и средства обнаружения сетевых отказов кластера (Host Monitoring) также должны быть включены:

Host Monitoring позволяет хостам кластера обмениваться сигналами доступности (heartbeats) и в случае отказа предпринимать определенные действия с виртуальными машинами отказавшего хоста.

Для того, чтобы виртуальная машина всегда находилась на своей площадке в случае отказа хоста (и использовала локальные копии данных на виртуальных дисках VMDK), нужно создать Affinity Rules, которые определяют правила перезапуска ВМ на определенных группах хостов в рамках соответствующей площадки. При этом эти правила должны быть "Soft" (так называемые should rules), то есть они будут соблюдаться при возможности, но при отказе всей площадки они будут нарушены, чтобы запустить машины на резервном сайте.

Далее переходим к настройке "Host Hardware Monitoring - VM Component Protection":

На данный момент кластер VSAN не поддерживает VMCP (VM Component Protection), поэтому данную настройку надо оставить выключенной. Напомним, что VMCP - это новая функция VMware vSphere 6.0, которая позволяет восстанавливать виртуальные машины на хранилищах, которые попали в состояние All Paths Down (APD) или Permanent Device Loss (PDL). Соответственно, все что касается APD и PDL будет выставлено в Disabled:

Теперь посмотрим на картинку выше - следующей опцией идет Virtual Machine Monitoring - механизм, перезапускающий виртуальную машину в случае отсутствия сигналов от VMware Tools. Ее можно использовать или нет по вашему усмотрению - оба варианта полностью поддерживаются.

На этой же кариинке мы видим настройки Host Isolation и Responce for Host Isolation - это действие, которое будет предпринято в случае, если хост обнаруживает себя изолированным от основной сети управления. Тут VMware однозначно рекомендует выставить действие "Power off and restart VMs", чтобы в случае отделения хоста от основной сети он самостоятельно погасил виртуальные машины, а мастер-хост кластера HA дал команду на ее восстановление на одном из полноценных хостов.

Далее идут настройки Admission Control:

Здесь VMware настоятельно рекомендует использовать Admission Control по простой причине - для растянутых кластеров характерно требование самого высокого уровня доступности (для этого он, как правило, и создается), поэтому логично гарантировать ресурсы для запуска виртуальных машин в случае отказа всей площадки. То есть правильно было бы зарезервировать 50% ресурсов по памяти и процессору. Но можно и не гарантировать прям все 100% ресурсов в случае сбоя, поэтому можно здесь поставить 30-50%, в зависимости от требований и условий работы ваших рабочих нагрузок в виртуальных машинах.

Далее идет настройка Datastore for Heartbeating:

Тут все просто - кластер Virtual SAN не поддерживает использование Datastore for Heartbeating, но такого варианта тут нет :) Поэтому надо выставить вариант "Use datastores only from the secified list" и ничего из списка не выбирать (убедиться, что ничего не выбрано). В этом случае вы получите сообщение "number of vSphere HA heartbeat datastore for this host is 0, which is less than required:2".

Убрать его можно по инструкции в KB 2004739, установив расширенную настройку кластера das.ignoreInsufficientHbDatastore = true.

Далее нужно обязательно установить кое-какие Advanced Options. Так как кластер у нас растянутый, то для обнаружения наступления события изоляции нужно использовать как минимум 2 адреса - по одному на каждой площадке, поэтому расширенная настройка das.usedefaultisolationaddress должна быть установлена в значение false. Ну и нужно добавить IP-адреса хостов, которые будут пинговаться на наступление изоляции хост-серверов VMware ESXi - это настройки das.isolationaddress0 и das.isolationaddress1.

Таким образом мы получаем следующие рекомендуемые настройки растянутого кластера HA совместно с кластером Virtual SAN:

vSphere HA Turn on
Host Monitoring Enabled
Host Hardware Monitoring – VM Component Protection: “Protect against Storage Connectivity Loss” Disabled (по умолчанию)
Virtual Machine Monitoring Опционально, по умолчанию "Disabled"
Admission Control 30-50% для CPU и Memory.
Host Isolation Response Power off and restart VMs
Datastore Heartbeats Выбрать "Use datastores only from the specified list", но не выбирать ни одного хранилища из списка

Ну и должны быть добавлены следующие Advanced Settings:

das.usedefaultisolationaddress False
das.isolationaddress0 IP-адрес VSAN-сети на площадке 1
das.isolationaddress1 IP-адрес VSAN-сети на площадке 2

Более подробно об этом всем написано в документе "Virtual SAN 6.1 Stretched Cluster Guide".


Таги: VMware, HA, Virtual SAN, VSAN, Stretched, DR

Новые возможности VMware Site Recovery Manager 6.1.


Как вы знаете, на конференции VMware VMworld 2015 было сделано немало интересных анонсов. О некоторых из них мы уже писали - это объявления о выходе VMware Virtual SAN 6.1 и VMware Horizon 6.2. Сегодня мы расскажем еще об одной интересной новости с VMworld - выпуске решения для обеспечения катастрофоустойчивости виртуального датацентра VMware Site Recovery Manager 6.1.

1. Управление защитой данных на базе политик

Напомним, что в VMware vSphere есть понятие Storage Profile - это профиль хранилища, используемый механизмом Profile Driven Storage, который создается, как правило, для различных групп хранилищ (Tier), где эти группы содержат устройства с похожими характеристиками производительности. Виртуальную машину при создании или миграции можно разместить на хранилище, соответствующем требованиям к производительности и надежности:

В SRM 6.1 появился новый тип Protection-групп - storage policy-based protection groups. Они используют механизм vSphere Storage Profiles для идентификации виртуальных машин и добавления их в группы. Также существенно упрощается настройка защищаемых хранилищ.

Теперь профилю хранилищ, а также отдельным хранилищам, можно назначить тэг, которым можно оперировать при создании групп, сортировке или поиске элементов:

Кроме того, появилась интеграция со средствами развертывания виртуальных машин, такими как VMware vRealize Automation.

2. Поддержка растянутых кластеров и vMotion между датацентрами.

Раньше пользователям приходилось выбирать между использованием Site Recovery Manager и vSphere Metro Storage Clusters (так называемые Stretched Clusters, vMSC). Теперь обе этих технологии используются совместно.

Site Recovery Manager 6.1 теперь поддерживает и координирует исполнение операций cross-vCenter vMotion для обеспечения единого пространства отказо- и катастрофоустойчивости для распределенных датацентров:

Таким образом, SRM 6.1 вобрал в себя все преимущества "растянутых" кластеров:

Интеграция растянутых кластеров и VMware SRM 6.1 позволяет реализовать следующие сценарии, ранее доступны только в vMSC:

  • Плановое обслуживание оборудования целого датацентра - исполнение плана миграции виртуальных машин на другую площадку под управлением другого vCenter прозрачно для пользователей и приложений.
  • Нулевой простой при сбоях - исполнение плана аварийного восстановления в сочетании с cross-site vMotion (эвакуация машин) поможет избежать простоев при авариях и прочих неприятностях. Ранее такой план мог быть выполнен только путем остановки машин в основном ЦОД и последующим запуском на резервной площадке.

Вот как исполнение плана с подобным сценарием выглядит в консоли SRM:

Также функции растянутого кластера и vMotion между датацентрами будут востребованы при тестировании плана аварийного восстановления в распределенных ЦОД.

3. Улучшенная интеграция с VMware NSX.

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

Используя новые логические коммутаторы NSX, которые охватывают несколько серверов vCenter, Site Recovery Manager позволяет автоматически создать маппинги виртуальных сетевых ресурсов сред при создании плана восстановления, что снижает эксплуатационные расходы и сокращает время, необходимое для настройки.

Объекты Universal Logical Switches объединяют два сетевых домена vCenter на уровне Layer-2, позволяя создавать виртуальные группы портов, которые подключены к виртуальным коммутаторам обеих площадок.

В этом случае Site Recovery Manager автоматически определяет и сопоставляет сети основного и резервного сайтов, никаких ручных операций по настройке маппинга не требуется:

В случае сбоя на основной площадке, необходимые параметры сети и настройки безопасности (включая IP-адреса, security groups, параметры сетевого экрана и конфигурации оконечных устройств) применяются на восстанавливаемых виртуальных машинах, что дополнительно сокращает время восстановления.

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

Доступность для загрузки VMware Site Recovery Manager 6.1 ожидается в ближайшее время, пока можно следить за новостями на странице обновленного продукта.


Таги: VMware, SRM, Update, NSX, DR

Репликация данных корпоративной инфраструктуры в облако NetApp сервис-провайдера.


Гостевой пост нашего партнера - компании ИТ-ГРАД, предоставляющей услуги аренды виртуальных машин из облака.

История партнерских взаимоотношений «ИТ-ГРАД» и NetApp берет свое начало в 2010 году. За пять лет было реализовано большое количество проектов: от простых до сложных, от внедрения систем хранения данных до реализации полнофункциональных облачных решений.

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

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

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

Нажмите читать дальше и комментировать
Таги: IT-Grad, NetApp, DR, IaaS

Обновленный документ VMware по технологии vSphere Metro Storage Cluster (vMSC).


На днях компания VMware выпустила интересный документ "VMware vSphere Metro Storage Cluster Recommended Practices" о построении архитектуры распределенного кластера VMware HA/DRS. Теперь в документе учтены все самые последние изменения, которые произошли в этом плане после выхода VMware vSphere 6.

Документ состоит из двух частей: в первой части рассказывается о том, как правильно спроектировать кластер vMSC и настроить платформу VMware vSphere соответствующим образом:

Во второй части подробно описаны различные сценарии сбоев и их обработка кластером vMSC в вашей распределенной виртуальной инфраструктуре:

В документе описаны следующие виды сбоев:

  • Отказ одного хоста в основном датацентре
  • Изоляция одного хоста в основном датацентре
  • Разделение пула виртуальных хранилищ
  • Разделение датацентра на сегменты (сети хостов и сети хранилищ)
  • Отказ дисковой полки в основном ЦОД
  • Полный отказ всех хранилищ в основном датацентре
  • Потеря устройств (полный выход из строя, выведение из эксплуатации) - Permanent Device Loss (PDL)

Понятное дело, что документ обязателен к прочтению, если вы планируете строить распределенную инфраструктуру для ваших виртуальных машин на платформе VMware vSphere 6.0.


Таги: VMware, vSphere, vMSC, HA, DRS, DR

Типы репликации виртуальных машин и некоторые подробности о VMware vSphere Replication.


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

Во-первых, репликация с точки зрения синхронизации данных, бывает двух типов:

  • Full sync - это когда требуется полная синхронизация виртуальной машины и всех ее дисков в целевое местоположение. Для этого в версии VMware vSphere 5.x использовалось сравнение контрольных сумм дисков на исходном и целевом хранилище. Если они не совпадают, и нужно делать Full sync, исходя из начальных условий - начинается процесс полной репликации ВМ. В первую очередь, основным подвидом этого типа является Initial full sync - первичная синхронизация работающей виртуальной машины, для которой репликация включается впервые.

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

  • Delta sync - после того, как полная синхронизация закончена, начинается процесс передачи целевой ВМ только различий с момента полной репликации. Тут используется технология changed block tracking, чтобы понять, какие блоки надо отреплицировать с последнего Full sync. Периодичность дельта-репликации зависит от установленной политики Recovery Point Objective (RPO).

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

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

Таким образом, репликация делится еще на 2 типа:

  • Online sync - репликация включенной ВМ, проходящая автоматически.
  • Offline sync - репликация выключенной ВМ, запускаемая вручную.

Вот так запускается репликация для выключенной ВМ:

Во время offline-репликации виртуальную машину нельзя включить, а ее диски будут залочены. Кроме того, вы не сможете отменить эту операцию. Поэтому при нажатии Sync Now будет выведено вот такое предупреждение:

Обычно offline-репликация используется для создания гарантированной копии ВМ на другой площадке (например, при переезде датацентра или частичном восстановлении инфраструктуры на другом оборудовании). Ну или если у вас была настроена online-репликация, а вы выключили ВМ, то в конце нужно сделать еще ручной Sync Now.

Также в VMware vSphere 6.0 было сделано существенное улучшение в производительности процесса репликации. Если раньше идентичность копий основного диска и реплики сверялась только на базе контрольных сумм (все данные диска надо прочитать - а это затратно по вводу-выводу и CPU), то теперь иногда используются данные о конфигурации виртуального диска на базе регионов. Например, если на исходном диске есть регионы, которые не были аллоцированы на целевом диске, то репликация это отслеживает и передает данные в эти регионы на целевое хранилище. Это работает значительно быстрее вычисления контрольных сумм.

Но такая оптимизация работает не для всех типов виртуальных дисков, а только для Lazy zeroed thick disks, thin disks и vSAN sparse disks и только на томах VMFS. Тома NFS, тома VVols, а также диски типа Eager zeroed thick не предоставляют информации об аллокации регионов, поэтому для них оптимизация работать не будет. Более подробно об этом написано тут.


Таги: VMware, vSphere, Replication, Storage, DR, VMDK

Катастрофоустойчивое решение с использованием IaaS


Это гостевой пост компании ИТ-ГРАД. В нашу эпоху бурного роста объемов информации и «хотелок» бизнеса подход к сохранности данных тоже требует перемен. Вспомните, как раньше небольшие и средние компании решали вопрос с временной недоступностью своих сервисов. Если кратко — то никак. Полагались на авось и резервные копии. Сейчас же рост популярности виртуализации и облачных вычислений фактически уравнял в возможностях компании с любыми бюджетами.

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


Таги: IT-Grad, IaaS, DR

Microsoft выпустила технологическое превью поддержки защиты инфраструктур VMware решением Azure Site Recovery.


У компании Microsoft есть такое решение Azure Site Recovery (о котором мы упоминали вот тут), предназначенное для создания катастрофоустойчивых инфраструктур, находящихся под управлением Microsoft System Center. Для репликации виртуальных машин используется технология Hyper-V Replica и возможности продукта System Center Data Protection Manager (SCDPM).

Недавно стало известно, что в режиме технологического превью решение Azure Site Recovery теперь поддерживает виртуальную инфраструктуру на платформе VMware vSphere. В качестве целевой резервной площадки для реплицируемых виртуальных машин используется сервис Microsoft Azure, либо резервная инфраструктура VMware.

При реализации этой технологии использовались наработки InMage Scout, купленные компанией Microsoft летом прошлого года. Вот так выглядит настройка катастрофоустойчивости между двумя площадками с виртуальной инфраструктурой на базе VMware средствами InMage:

На данный момент поддержка этой технологии доступна абсолютно бесплатно для клиентов Azure Site Recovery (включая репликацию между двумя площадками на базе VMware).


Таги: Microsoft, DR, Update, Site Recovery, VMware

Новые возможности VMware Site Recovery Manager 6.0.


Вскоре после релиза новой версии платформы виртуализации VMware vSphere 6.0 компания VMware объявила о доступности для загрузки обновленного решения VMware Site Recovery Manager 6.0, предназначенного для создания катастрофоустойчивой виртуальной инфраструктуры. Напомним, что о возможностях прошлой версии - VMware SRM 5.8 - мы писали вот тут.

В продукте VMware SRM 6.0 появилось четыре основных улучшения:

1. Улучшенная совместимость с Storage DRS и Storage vMotion.

Ранее была только базовая совместимость с этими продуктами - во-первых, при перемещении с помощью SVMotion машины из consistency group, защищенной SRM, не выводилось никакого предупреждения (теперь есть), а, во-вторых, теперь Datastore Cluster в SDRS поддерживает несколько consistency groups, защищенных SRM:

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

2. Упрощенные требования в SSL-сертификатам.

 

Теперь SRM 6.0 полностью интегрирован со службами vSphere 6.0 platform services (SSO, Authorization, Licensing, Tags и прочее), что делает удобным развертывание и установку сертификатов SSL для безопасного взаимодействия компонентов.

3. Полная поддержка VMware vSphere 6.0.

SRM 6.0 теперь поддерживается в связке со следующими компонентами:

  • vCenter Server 6.0
  • vSphere Web Client 6.0
  • vSphere Replication, version 6.0 (если используется)

Большинство SRA (Storage Replication Adapters), которые поддерживались в версии SRM 5.8, продолжают поддерживаться и в 6.0. Для точной информации смотрите Compatibility Guide.

Все максимальные лимиты vSphere 6.0 также поддерживаются и со стороны SRM 6.0. Кроме того, теперь стали доступны для развертывания различные топологии совместно с SRM, описанные вот тут. Об этом постараемся написать вскоре подробнее.

4. Улучшения IP-кастомизации.

Утилита dr-ip-customizer теперь при кастомизации IP-адреса виртуальной машины обновляет как IPv4, так и IPv6 спецификацию. Кроме того, в этом плане поддерживается обратная совместимость с версиями SRM 5.x.

Скачать VMware Site Recovery Manager 6.0 можно по этой ссылке.


Таги: VMware, SRM, Update, DR

Сжатие данных при передаче (compression) в VMware vSphere Replication 6.0.


Продолжаем рассказывать о новых функциях платформы виртуализации vSphere 6.0 (для этого у нас есть специальная страница). Сегодня у нас на очереди функции сжатия данных в VMware vSphere Replication 6.0. Функция репликации включена во все издания VMware vSphere, начиная с Essentials Plus (то есть, за бортом только Essentials). Кстати, родственная репликации функция резервного копирования VMware Data Protection 6.0 также есть во всех изданиях, начиная с Essentials Plus.

Начнем с того, что vSphere Replication 6.0 полностью совместима с продуктами VMware Virtual SAN 6.0 и vCenter Site Recovery Manager (SRM). Также в vSphere 6.0 появилась функция сжатия данных сетевого трафика при передаче:

Это снижает требования к ширине канала репликации, что особенно актуально при использовании продукта VMware SRM для обеспечения отказоустойчивости на уровне помещений или датацентров. Делается сжатие средствами библиотеки FastLZ, однако сжатие выключено по умолчанию.

При передаче данных репликации пакеты остаются сжатыми до того момента, пока они не отправляются на запись на диск. Но в некоторых случаях, в зависимости от версий ПО и особенностей архитектуры, сжатие может быть не на всем участке пути данных, или его может не быть вовсе. Пример: репликация vSphere 6.0 при соединении с виртуальным модулем vSphere Replication 5.8 - сжатия не будет. Если же, например, данные хоста ESXi 6.0 идут на виртуальный модуль vSphere Replication 6.0, а дальше на хранилище хоста vSphere 5.5, то данные будут разжаты на виртуальном модуле репликации, а дальше пойдут в обычном виде. Отсюда мораль - старайтесь поддерживать актуальные версии своего ПО на всех компонентах инфраструктуры.

В большинстве случаев достигается коэффициент сжатия данных в диапазоне от 1.6 к 1 до 1.8 к 1. Это приводит к уменьшению времени синхронизации и возможности настройки более строгой политики RPO.

Примеры:

1. ВМ с гостевой ОС Windows и диском в 37.5 ГБ при первой репликации без компрессии синхронизируется за 52 минуты. Когда включили компрессию, 20.2 ГБ данных отреплицировалось за 29 минут. Таким образом, эффективное использование канала выросло с 98 Mbps до 177 Mbps.

2. ВМ с гостевой ОС Linux и 4.7 ГБ данных при первичной репликации синхронизировались за 13 минут. После включения компрессии 2,8 ГБ ушли за 8 минут. Эффективное уменьшение ширины канала - с 49 Mbps до 80 Mbps.

Из минусов - компрессия создает нагрузку на процессор, поэтому нужно ее использовать аккуратно, и потому она отключена по умолчанию. Больше информации о технологии репликации от VMware можно найти в документе "VMware vSphere Replication 6.0 Technical Overview".


Таги: VMware, vSphere, Replication, Update, DR, ESXi

Обеспечение защиты сервера управления VMware vCenter Server 5.5.


Как вы знаете, у компании VMware был такой продукт как vCenter Server Heartbeat, который защищал управляющий сервер vCenter от сбоя различных его компонентов и на различных уровнях. Некоторое время этот продукт был снят с производства, и теперь защиту vCenter от сбоев рекомендуется обеспечивать стандартными средствами платформы VMware vSphere.

Надо сказать, что обеспечение надежности сервера vCenter, работающего в виртуальной машине (а сейчас уже мало кто ставит его в физической), начинается с обеспечения доступности и дублирования компонентов, которые находятся "под ним", а именно: хост-сервер ESXi, источники питания, хранилища, сетевые подключения и т.п.

Ну а, собственно, для правильной конфигурации самой платформы vSphere и сервера vCenter, компания VMware выпустила полезный документ "VMware vCenter Server 5.5 Availability Guide".

Итак, начнем с того, что VMware предлагает разделить сервисы vCenter на две большие части:

  • Compute Node - это сам vCenter и все сервисы к нему относящиеся (SSO, Web Client, Inventory service)
  • Data Node - это узел, где хранятся данные vCenter, попросту говоря, это СУБД и сама база данных.

Понятно, что оба этих компонента могут быть как на одном сервере (для небольшой инфраструктуры), так и в разных машинах, когда требуется производительная база данных (например, в Enterprise-окружениях).

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

Но чаще всего у вас есть просто одна или максимум две виртуальные машины - одна под vCenter, вторая - под его базу данных.

Доступность Compute Node

Это раздел включает в себя доступность следующих комопнентов:

  • vCenter Single Sign-On services
  • vCenter Inventory Service
  • vCenter Server
  • vCenter Server management Web service
  • vSphere Web Client

Здесь рекомендуется настроить защиту средствами технологии VMware HA и придерживаться следующих рекомендаций:

  • Создавайте (по-возможности) отдельный кластер для управляющих сервисов - в случае отказа любого из компонентов сервисы будут перезапущены с помощью HA автоматически.
  • Включите не только VMware HA, но и технологию virtual machine monitoring, которая отключена по умолчанию. Это позволит перезапустить сервер с vCenter при зависании гостевой ОС.

  • Включите и настройте admission control в кластере HA/DRS, где работает vCenter. Это позволит гарантированно перезапустить vCenter на одном из хостов в случае сбоя.
  • Установите restart priority в настройках HA для машины с vCenter Server в значение "High". Он будет первым запускаться.
  • Если ваш vCenter находится в Windows-машине, то можно настроить автоматический рестарт машины при невозможности после многократных попыток запустить службу vCenter Service.

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

  • Если у вас компоненты vCenter на разных машинах, не забудьте установить правило affinity rule, чтобы машины оказались на одном хосте при миграции и восстановлении, в целях сохранения максимальной производительности управляющего сервиса.
  • Также для гарантии можно выделить управляющим компонентам гарантированную физическую память (Memory Reservation) в настройках виртуальной машины.

Доступность Data Node

Тут VMware приводит следующие рекомендации:

  • Также, как и в случае с Compute Node, рекомендуется использовать для управляющих сервисов и базы данных отдельный кластер.
  • Если вы используете решение для кластеризации vCenter, необходимо убедиться, что настройка ForceAffinePoweron в параметрах vSphere DRS установлена в значение 1, чтобы включать сервер БД, несмотря на правила DRS.
  • Так же, как и в случае с Compute Node, используйте технику virtual machine monitoring для перезапуска зависшей гостевой ОС.
  • То же самое и про admission control - используйте его для гарантированного восстановления ВМ с сервером БД.
  • Аналогично Compute Node, установите restart priority в настройках HA для машины с базой данных в значение "High". Он будет первым запускаться.
  • Для защиты vCenter Server SQL Server database можно использовать Microsoft Failover Clustering, который официально поддерживается со стороны VMware. Табличка совместимости СУБД и версий vCenter приведена ниже.

О том, как восстанавливать серверы vCenter, и многом другом можно почитать в документе "VMware vCenter Server 5.5 Availability Guide".


Таги: VMware, vCenter, HA, DRS, VMachines

Краш-тест облачной платформы высокой доступности


Как убедиться в том, что инфраструктура облачного провайдера действительно не имеет единой точки отказа? Проверить это на деле!

В этой заметке сотрудники ИТ-ГРАД расскажут о том, как они проводили приёмо-сдаточные испытания своей новой облачной площадки.

Предыстория

24 сентября мы открыли новую публичную облачную площадку в Санкт-Петербурге. Вот тут предварительный план испытаний облачной платформы.

И вот мы приступаем…

Удаленное тестирование

1. Поочередное выключение контроллеров FAS8040

Ожидаемый результат... [Читать статью далее]


Таги: IT-Grad, Cloud, HA, DR

Как запретить vMotion отдельной виртуальной машине на VMware vSphere.


Если вы хотите, чтобы никто не делал vMotion конкретной виртуальной машины с конкретного сервера VMware ESXi, то нужно просто разослать письмо администраторам vSphere с просьбой этого не делать. Но есть еще один способ, который поведал нам Frank Denneman - хотя он тоже имеет ограниченные условия применения. Ну и не забываем, что есть способ путем задания правил механизма балансировки VMware DRS (однако, не у всех по лицензии DRS есть).

В этом способе есть один существенный минус - в то время, как он не позволяет пользователю двинуть виртуальную машину через vMotion вручную, смигрировать машину можно будет через перевод хоста ESXi в Maintenance mode, так как делается это не под аккаунтом пользователя, а под системной учетной записью (System). Но режим обслуживания используется редко, и хотя бы для ручных операций это можно будет сделать. Ну и имейте в виду, что механизм VMware HA также может перезапустить машину на другом хосте в случае сбоя, наплевав на все.

Итак, чтобы отключить vMotion для конкретной виртуальной машины, нужно создать новую роль (No-vMotion), для которой необходимо отключить привилегию по vMotion машины, назначатить эту роль администраторам и добавить пермиссию для виртуальной машины, указав юзеров с этой ролью (как работает этот механизм читайте здесь).

Итак, добавляем роль No-vMotion в vSphere Web Client:

1. Заходим в vCenter как administrator.
2. Идем на домашний экран и переходим в Roles на экране Administration.
3. Выбираем действие создать роль (зеленый плюс).
4. Выбираем "All Priveleges", скроллимся до категории "Resource" и отчекиваем следующие привилегии,

  • Migrate powered off virtual machine
  • Migrate powered on virtual machine
  • Query vMotion

Далее добавляем пермиссию для виртуальной машины для нужного администратора/группы:

1. Выбираем "Host and Clusters" и находим нужную ВМ на вкладке Manage.
2. Выбираем пункт "Permissions" и кликаем на добавление пермиссии (зеленый плюс).
3. Нажимаем "Add" и выбираем пользователя или группу, которым мы хотим запретить vMotion этой виртуальной машины.
4. В правой части экрана выбираем роль "No-vMotion" и нажимаем "Ok".

Убеждаемся, что роль применена для данного пользователя к данному объекту (на остальные пермиссии это не повлияет):

Попробуем смигрировать эту виртуальную машину пользователем FrankD - видим, что опция "Migrate" загреена:

Но вот возможность перевода в Maintenance mode, к сожалению, по-прежнему активна:

Кто-нибудь знает более простой и надежный способ?


Таги: VMware, vSphere, vMotion, VMachines, Security, Обучение, ESXi, DRS, Blogs

Технология репликации VMware vSphere Replication и обеспечение политики RPO.


Как вы знаете, в VMware vSphere (еще с версии 5.1) есть механизм репликации виртуальных машин vSphere Replication (VR), который позволяет создавать копию виртуальной машины на другом хосте и хранилище на случай сбоя. Именно она используется для асинхронной репликации в катастрофоустойчивом решении VMware vCenter Site Recovery Manager (SRM).

Периодичность репликации со стороны владельца системы должна задаваться политикой RPO (Recovery Point Objective), определяющей какое максимальное количество данных выраженное во времени мы можем потерять в случае сбоя. Например, RPO=15 минут означает, что самое большое, что не будет подлежать восстановлению - это изменения, произошедшие в системе за последние 15 минут.

Этот параметр и задается в первую очередь при настройке репликации для виртуальной машины:

Здесь можно задать значение от 15 минут до 24 часов. Однако не обязательно это требование будет выполнено, ведь если ширина канала у вас небольшая, а машин на хостах много, то они просто могут не поместиться в эту полосу с необходимой для обеспечения RPO частотой репликации.

Кстати, на данный момент расписание задачи репликации генерируется автоматически на основании исторических данных об изменении блоков виртуальных дисков за последние 48 часов. При этом расписание репликации пересчитывается каждый раз, когда виртуальная машина меняет свое состояние (питание, реконфигурация репликации и т.п.).

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

Ожидаемое время репликации вычисляется как среднее время последних 15 репликаций плюс 20% прибавка в качестве запаса к этому времени.

Рассмотрим пример:

Здесь у нас установлено RPO=60 минут. В первом случае на репликацию ушло 22 (текущая) и 23 (ожидаемая) минуты, каждая из них меньше половины времени RPO, соответственно политика считается выполненной. Во втором случае текущая и следующая репликации выходят за границы половины RPO, обе репликации в сумме дают 68 минут, поэтому политика считается нарушенной.

То есть, если исходный хост навернется через 67 минут, то мы сможем откатиться только в то состояние хоста, которое было 67 минут назад (восстановив первую реплику), что противоречит политике RPO, которая была определена как 60 минут.

В случае нарушения RPO сама репликация будет продолжена, однако вы будете получать вот такие алерты в консоли vSphere Client:

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

Кстати, в плане определения необходимой ширины канала для репликации вам поможет специальное средство VMware vSphere Replication Capacity Planning Appliance.


Таги: VMware, vSphere, Replication, DR, VMachines

Решение VPLEX Geosynchrony 5.2 сертифицировано для задержек в канале до 10 мс для технологий HA/DRS кластера vMSC.


Интересная новость пришла с конференции EMC World 2014, которая проходила с 5 по 8 мая в Лас-Вегасе. Теперь при построении распределенного ("растянутого") кластера VMware HA/DRS (он называется vSphere Metro Storage Cluster, vMSC) поддерживается задержка RTT (Round Trip Time) в канале до 10 миллисекунд. Для такого варианта использования сертифицировано решение VPLEX Geosynchrony 5.2, начиная с версии VMware vSphere 5.5.

Надо сказать, что технология EMC VPLEX Metro ранее поддерживалась на расстояниях между ЦОД в диапазоне до 100-150 км (иногда несколько более), где возникают задержки (latency) до 5 мс (это связано с тем, что RTT-время пакета в канале нужно умножить на два для FC-кадра, именно два пакета необходимо, чтобы донести операцию записи). Но и 150 км - это вовсе немало. Теперь же это расстояние увеличилось до 300 километров.

Ранее технология vMotion поддерживалась и для latency до 10 мс, а вот механизм отказоустойчивости VMware HA гарантированно работал только для задержек до 5 мс.

При этом сейчас кластер vMSC сертифицирован как для нативного плагина доступа к хранилищам NMP (Native Multi-pathing), так и для плагина PowerPath/VE. Здесь надо обязательно отметить, что данная конфигурация поддерживается только издания VMware vSphere Enterprise Plus.

Более подробная информация о кластерах vMSC приведена в KB 2007545.


Таги: VMware, vMSC, Update, EMC, Storage, HA, DR, Replication

1 | 2 | 3    >   >>
Реклама

Advertisement

Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

27/08/2017:  VMware VMworld 2017
11/09/2017:  VMware VMworld Europe 2017
26/10/2017:  VeeamON Forum Russia 2017

Быстрый переход:
VMware IT-Grad Veeam StarWind Microsoft Parallels IaaS Citrix 5nine HP VeeamON VMFS RVTools PowerCLI VM Guru Oracle Red Hat Azure KVM vGate VeeamOn Security Code 1cloud Cloud Docker Storage Offtopic NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo Nutanix vRealize VirtualBox Symantec Gartner Softline EMC Login VSI Xen Enterprise Teradici Amazon NetApp VDI Linux Hyper-V IBM Cisco Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Hardware Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell vSphere IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V vSAN Backup Horizon SRM Client App Volumes Performance Workstation Manager Labs Nested vCloud AWS Log Insight XenDesktop VSA vNetwork SSO DRS LSFS Workspace Host Client VMDK vROPs VTL Update iSCSI SDDC vCSA NSX Agent Virtual Appliance Whitepaper PowerShell Fusion Appliance VUM VVols V2V Tools Cache VMworld Support Обучение Web Client Mobile OpenStack Automation Replication Desktop Fault Tolerance DR Photon Vanguard SaaS Connector HA Event Free Datacenter SQL VSAN Lifecycle Sponsorship Finance FT Cloud Computing Converter XenApp esxtop Snapshots VCP Auto Deploy SMB RDM Mirage XenClient MP Video Operations SC VMM Certification SSD VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo Visio Intel vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Networking Monitoring VPLEX UCS SDK Poster VSPP SDRS Receiver vMotion VDI-in-a-Box Deduplication Forum Reporter vShield ACE Go nworks iPad XCP Data Recovery Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Troubleshooting Air API CLI Plugin DPM Director Book Memory Upgrade SIOC Flex Mac Bug Open Source SSH VAAI Chargeback Heartbeat Android MSCS Ports SVMotion Storage DRS Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Сравнение Oracle VirtualBox и VMware Workstation.

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Как использовать возможности VMware vSphere Management Assistant (vMA).

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Отличия VMware ESXi 4 free (бесплатного), ESXi 4 и ESX 4 в составе VMware vSphere.

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2017, Александр Самойленко. Правила перепечатки материалов.