На проходящей сейчас конференции TechEd 2014 в Хьюстоне компания Microsoft сделала несколько интересных анонсов, касающихся публичного облака Microsoft Azure. Мы уже писали о выпуске превью-версии Azure RemoteApp, а ниже расскажем о других нововведениях Azure.
Во-первых, прояснилась ситуация с Microsoft Azure Site Recovery (так теперь называется решение Hyper-V Recovery Manager) - он будет доступен в виде превью в июне этого года. Это катастрофоустойчивое решение позволяет проводить прямое и обратное восстановление виртуальной инфраструктуры датацентров, находящихся под управлением Microsoft System Center 2012. При этом будет доступна возможность восстановления онпремизной инфраструктуры под управлением SC Virtual Machine Manager в публичное облако Microsoft Azure.
Процесс восстановления будет полностью оркестрируем на основе заданного сценария, в качестве интервала репликации можно будет использовать время 30 секунд, а также 5 или 15 минут. Можно будет иметь до 15 точек восстановления, консистентность будет обеспечиваться технологией VSS, а пользователь при необходимости сможет включать шифрование данных.
Плата за Microsoft Azure Site Recovery будет производиться на основе используемого инфраструктурой хранилища, так как в нормальном режиме репликации виртуальные машины на резервной площадке будут выключены. Если в качестве резервной площадки используется облако Azure, то виртуальные машины там будут приведены к стандартным инстансам - small, large, A6, A8, в зависимости от такого, какой ближе по конфигурации.
Также будут поддерживаться диски VHDX, но ВМ второго поколения (Generation 2 virtual machines) пока не поддерживаются. Более подробно о решении Microsoft Azure Site Recovery можно почитать тут.
Во-вторых, было анонсировано расширение Microsoft Azure Antimalware, предоставляющее сервисы защиты от вредоносного ПО в виртуальных машинах на платформе Azure.
Теперь в ВМ можно использовать расширения от различных вендоров, обеспечивающие ее защиту от вирусов и т.п.:
В-третьих, Microsoft анонсировала доступность решения Microsoft Azure ExpressRoute, которое представляет собой единое решение для организации межоблачных VPN, безопасных соединений VNET-to-VNET, управление выделенными IP, внутреннюю балансировку и интеграцию с такими провайдерами, как AT&T, Equinix, Verizon, BT и Level3.
Технические подробности о ExpressRoute доступны тут.
Также на TechEd было сделано еще несколько анонсов, касающихся облака Azure, таких как сервис импорта-экспорта виртуальных машин на дисках для больших объемов данных, новая служба SMB File Sharing Service и т.п. Обо всем этом можно почитать тут.
На прошлой неделе компания VMware объявила о запуске нужного сервиса по восстановлению инфраструктуры Disaster Recovery для облачной инфраструктуры vCloud Hybrid Service (vCHS). Напомним, что совсем недавно сервисы vCHS подешевели и стали доступны в Европе.
Анонсированное DR-решение доступно как услуга (RaaS, Recovery-as-a-Servie) для конечных заказчиков, которые могут делать бэкап своего частного облака в инфраструктуру vCHS. При этом для заказа услуги (она доступна на 1,12,24 или 36 месяцев) не требуется быть клиентом vCHS и иметь там свою виртуальную инфраструктуру.
Это очень удобно для тех заказчиков, которые не хотят вкладывать сразу большие деньги в построение полноценной резервной площадки, а пока просто хотят протестировать сервисы катастрофоустойчивости VMware. Ведь в любой момент можно отказаться от использования vCHS, когда будут введены в эксплуатацию собственные резервные мощности.
Новые возможности Disaster Recovery в облаке vCloud Hybrid Service:
Self-Service disaster recovery Protection - возможность защитить до 500 виртуальных машин с помощью технологии vSphere Replication самостоятельно, прямо из консоли vCenter Server.
Custom Recovery Point Objectives - возможность настройки политик репликации, которые дают RPO от 15 минут до 24-х часов, в зависимости от характеристик канала связи, объема реплицируемых данных и прочих факторов.
Industry-Standard Recovery Time Objectives - время восстановления сервиса после сбоя (RTO) гарантировано на уровне 4-х часов (или менее), что подразумевает полное включение резервных копий всех машин на стороне vCHS.
Automated Failover Testing, Planned Migrations and Recovery - встроенные возможности (преднастроенные workflows), позволяющие проводить тестирование аварийного восстановления, live-восстановление продуктивной ВМ в среду vCHS, а также проводить запланированные миграции в облако VMware.
Elastic Cloud Compute and Storage - возможность гибкого изменения требуемых под DR-инфраструктуру ресурсов, что позволяет, например, быстро построить среду под аварийное восстановление инфраструктуры на стороне vCHS в самое ближайшее время.
Offline Data Seeding - возможность первичной передачи большого объема данных через офлайн-механизм vCloud Connector Offline Data Transfer.
Private Leased Line Networks - использование выделенных провайдерских сетей (Direct Connect) для возможности аварийного восстановления.
Flexible Failover Testing - возможность использования различных преконфигуренных сценариев аварийного восстановления.
Для использования сервисов DR в vCHS вам потребуется:
VMware vSphere 5.1 или выше
VMware vCenter 5.1 или выше
Механизм VMware vSphere Replication 5.6
Подписка VMware vCloud Hybrid Service – Disaster Recovery
Развернутый виртуальный датацентр (DR-VDC) в инфраструктуре
vCloud Hybrid Service
Достаточное по скорости соединение через интернет с облаком vCHS
Сначала DR vCHS можно купить как Core Service базовой мощности:
А потом уже можно расширять его аддонами (минимальная гранулярность подписки - месяц, что удобно):
Более подробно о возможностях аварийного восстановления своей инфраструктуры в среду vCHS можно почитать в даташите или FAQ.
Многие администраторы VMware vSphere знают, что еще в версии Veeam Backup and Replication 6.5 появилось средство Veeam Explorer for SAN, которое поддерживает гранулярное (то есть до уровня отдельных объектов гостевой ОС) восстановление виртуальных машин напрямую из снапшотов, сделанных устройствами хранения. До настоящего времени это решение поддерживало только хранилища HP StoreVirtual VSA и HP LeftHand (а также была добавлена поддержка StoreServ, т.е. 3PAR). Эта технология изначально была разработана Veeam совместно с HP и поддерживала все функции Veeam: Instant VM Recovery, Instant File-Level Recovery и Explorer for Exchange item recovery.
Теперь же, совсем недавно, компания Veeam Software объявила о партнерстве с NetApp - одним из лидеров в области производства систем хранения данных. Теперь Veeam Backup & Replication 8, который будет следующим мажорным релизом ведущего продукта для резервного копирования и репликации ВМ, сможет восстанавливать виртуальные машины напрямую из снапшотов NetApp:
Это уже вторая фича, заявленная к выпуску в восьмой версии Veeam B&R, первой, напомним, было средство восстановления объектов каталога Active Directory из резервных копий виртуальных машин - Veeam Explorer for Active Directory.
Основные возможности Veeam Explorer for SAN при работе с массивами NetApp:
Fast backups: возможность резервного копирования виртуальных машин из снапшотов хранилищ, сделанных самим NetApp, что работает до 20 раз быстрее.
Quick recovery: возможность восстановления машин или их отдельных объектов (документы Exchange, файлы гостевых ОС и т.п.) из объектов хранилищ, сделанных средствами технологий NetApp Snapshot, SnapMirror и SnapVault.
Improved protection: возможность создания снапшотов или удаленных резервных копий инфраструктуры средствами хранилищ NetApp (например, на DR-площадке).
Пример помещения второго бэкапа в удаленное волт-хранилище в целях обеспечения катастрофоустойчивости инфраструктуры:
Недавно компания VMware начала серию статей про совместимость ее решения для организации кластеров хранилищ Virtual SAN с различными продуктами (например, с vCloud Automation Center и решением для резервного копирования vSphere Data Protection). Но многих пользователей интересует юзкейс использования VSAN для катастрофоустойчивой инфраструктуры, управляемой VMware Site Recovery Manager. А именно, с точки зрения экономии, наиболее интересным вариантом является создание резервной инфраструктуры на базе хранилищ локальных дисков серверов VMware ESXi, бэкэнд которых обеспечивается кластером хранилищ VSAN:
Такая схема полностью поддерживается со стороны VMware, как для решения vSphere Replication, обеспечивающего репликацию виртуальных машин на резервный сайт и его VSAN-хранилища, так и для vCenter Site Recovery Manager, обеспечивающего оркестрацию процесса.
Естественно, на данный момент поддерживается совместимость SRM+VSAN только на базе технологии асинхронной репликации vSphere Replication, поэтому такой сценарий не подойдет тем, кто хочет обеспечить RPO=0 для сервисов виртуальных машин в случае массового сбоя или катастрофы на основной площадке. Но для сценариев с RPO=15 минут такая схема вполне подойдет.
Зато такая схема не требует больших вложений в резервную инфраструктуру - не нужно покупать дорогостоящие FC-хранилища, SAN-коммутаторы и прочее. Для организации такой схемы резервирования можно использовать как только механизм vSphere Replication (но тогда потребуются регулярные ручные операции + ручное сопровождение в случае сбоя), так и автоматизировать процесс с помощью vCenter SRM.
При этом SRM может обеспечить следующие возможности:
Автоматизированный Failover и Failback (нужно только нажать кнопку).
Управление процессом восстановления из консоли vCenter.
Возможность запланированной миграции сервисов на резервную площадку (при этом основную площадку можно сделать резервной).
Несколько точек для восстановления в случае порчи данных (например, надо откатиться на день назад).
Возможность протестировать процесс восстановления, не затрагивая продакшен-среду.
На тему всего этого компания VMware сделала отличное поясняющее видео, в котором показан процесс переезда с традиционной SAN-инфраструктуры на новую площадку, где хранилища построены на базе технологии VMware Virtual SAN:
Мы уже очень много писали про технологию VMware VSAN, которая позволяет создать кластер из локальных хранилищ хостов VMware ESXi (например, последнее - тут, тут и тут). На днях стало известно, что 10 марта состоится релиз этого решения, которое будет поставляться как дополнение к VMware vSphere, либо как предустановленное решение на брендовых серверах.
VSAN - один из самых серьезных и сложных продуктов VMware. В его тестировании приняло участие более 12 тысяч пользователей, и вот версия 1.0 уже почти готова.
Какие особенности будут у финальной версии VMware Virtual SAN:
Технологию Virtua SAN будет поддерживать новый релиз платформы виртуализации vSphere 5.5 Update 1, который, очевидно, будет выпущен вместе с VSAN. Также будет поддерживаться и решение VMware Horizon View.
Апгрейд бета-версий VSAN на релизную версию поддерживаться не будет.
Стоимость и комплектация изданий будут известны вместе с выходом продукта 10 марта.
Обещают, что производительность кластера VSAN будет масштабироваться линейно по мере роста количества узлов в нем.
В кластере хранилищ VSAN поддерживается до 32-х узлов. Минимально нужно 3 хоста ESXi.
На одном узле поддерживается работа до 100 виртуальных машин. Всего, таким образом, получается до 3200 машин в кластере.
Для работы кластера на каждом узле должны быть как SSD-диски (как минимум один), так и HDD-накопители. Если чего-то из этого нет - работать не будет.
Максимально на одном узле поддерживается до 35 HDD-дисков и до 5 SSD-дисков (один SSD на 7 HDD, то есть каждые 7 дисков обязательно требуют твердотельный диск емкостью около 0.1 от совокупной емкости этих HDD).
Где можно использовать VSAN (например): для VDI-инфраструктуры, среднекритичные нагрузки (Tier 2/3) и DR-сценарии (хранилища резервной площадки).
Минимальная скорость адаптера на хосте ESXi - 1 Гбит, но чтобы все работало надежно, очень рекомендуется строить сеть на адаптерах 10 Гбит. А все потому, что репликация идет синхронно.
Дедупликации пока не будет.
Производители оборудования, такие как Dell, HP и Cisco будут поддерживать VSAN и серверы "VSAN Ready". Вот тут можно посмотреть на список совместимого с VSAN оборудования. В день релиза станут доступными аж 13 готовых к VSAN конфигураций.
Ввод-вывод на узле кластера разгоняли до 2-х миллионов IOPS (IOmeter 100% read, 4KB block size, а также 640K IOPS с профилем нагрузки 70/30 read/write и 4KB block size).
Многие видели, что поддерживается совместная работа технологии VSAN с некоторыми решениями VMware, такими как vSphere Replication. Теперь также будет поддерживаться vSphere Data Protection for backups, vMotion, DRS, HA и многое другое.
Ну что ж, ждем с нетерпением выхода этой штуки, которая может оказаться весьма полезной многим.
Таги: VMware, VSAN, Update, Storage, HA, vSphere, DR
Напомним, что утилиту Capacity Planner for Hyper-V Replica компания Microsoft выпустила еще в мае 2013 года для платформы Windows Server 2012, теперь же продукт поддерживает Windows Server 2012 R2.
Основное назначение планировщика Hyper-V Replica - посчитать необходимую емкость канала репликации и инфраструктуру резервного сайта, основываясь на профиле рабочей нагрузки, имеющейся серверной и сетевой инфраструктуре основной площадки и ее хранилищах. Утилита производит автоматизированный сбор и анализ необходимых метрик, после чего запускается процесс подсчета и предоставляется детальный отчет.
Новые возможности Capacity Planner for Hyper-V Replica:
Поддержка Windows Server 2012 R2 наряду с обычным Windows Server 2012.
Поддержка хостов Extended Replica.
Поддержка виртуальных дисков, размещенных на хранилищах NTFS, CSVFS и общие SMB-ресурсы.
Мониторинг нескольких отдельных хостов одновременно.
Улучшенная производительность и масштабируемость - отслеживание до 100 виртуальных машин одновременно.
Параметры резервной площадки (Replica site) можно не вводить - это для тех, кто еще планирует развертывание DR-инфраструктуры.
Улучшения в отчетах (например, пиковое использование ресурсов).
Улучшенная документация.
Улучшенный рабочий процесс использования утилиты и пользовательского интерфейса.
Кстати, в документации есть раздел о том, как утилиту Capacity Planner for Hyper-V Replica можно использовать для инфраструктуры на базе решения Hyper-V Recovery Manager, о котором мы писали недавно.
Скачать Capacity Planner for Hyper-V Replica и документацию к утилите можно бесплатно по этой ссылке.
Продолжаем знакомить вас с анонсами VMworld 2013, среди которых было немалоинтересного. Как вы помните, у компании VMware в основном продуктовом портфеле есть решение VMware Site Recovery Manager, предназначенное для построения катастрофоустойчивой архитектуры на базе основной и резервной площадок. О предыдущей версии VMware SRM 5.1 мы уже писали вот тут. Ну а сегодня расскажем про VMware Site Recovery Manager 5.5.
Но сначала для тех, кто хочет знать, как об этом рассказывали на VMworld:
Напомним, что в SRM можно использовать репликацию на уровне дисковых массивов (array-based), которая работает быстро, надежно (до RPO=0) и синхронно (или асинхронно), но требует вложений в инфраструктуру, а также host-based репликацию по сети передачи данных, которая работает менее эффективно (RPO - от 15 минут до 24-х часов), зато использует существующую инфраструктуру Ethernet. О некоторых улучшениях host-based репликации в VMware vSphere 5.5 мы уже упоминали в этой статье.
Итак, что нового появилось в VMware SRM 5.5:
Возможность протестировать процедуру аварийного восстановления с двух сторон, без нарушения работы производственного окружения.
Поддержка виртуальных машин с дисками более 2 ТБ.
Поддержка Windows Server 2012 для установки компонентов SRM.
Новые настройки для поддержки режима vSphere Replicaiton.
При перемещении машин в рамках одной consistency group полностью поддерживаются техники Storage DRS и Storage vMotion.
Защита виртуальных машин, хранилища которых находятся на бэкэнде Virtual SAN (vSAN). Естественно, это реализовано на базе vSphere Replication.
Поддержка техники multiple point-in-time (MPIT) - нескольких точек для восстановления целевой реплицируемой машины. Это защищает сервисы от логических повреждений данных, изменения в которых реплицируются на резервную площадку.
SRM 5.5 больше не поддерживает базу данных IBM DB2.
Надо отметить, что для управления инфраструктурой SRM по-прежнему требуется "толстый" клиент vSphere Client (напомним, что его не убрали из vSphere 5.5, хотя и обещали - похоже именно из-за сопутствующих продуктов), а про поддержку vSphere Web Client пока ничего не говорят.
Интересной новой возможностью, о которой шла речь на VMworld, стал сценарий создания резервной инфраструктуры SRM в одном из поддерживаемых публичных облаков (он может быть использован как общий Recovery-сайт для нескольких филиалов компании):
Лицензирование продукта осталось прежним - либо за защищаемые виртуальные машины (если покупаем просто SRM), либо по процессорам хостов VMware ESXi (если покупаем в составе vCloud Suite).
О доступности для загрузки VMware Site Recovery Manager 5.5 будет объявлено несколько позднее.
Ну и помните (на всякий случай) предупреждение VMware:
Using SRM and vSphere Replication to replicate and recover virtual machines on VMware Virtual SAN datastores can results in incomplete replications when the virtual machines are performing heavy I/O. ESXi Server can stop unexpectedly.
Кстати, в будущем нам обещают, что VMware SRM будет доступен в виде виртуального модуля (Virtual Appliance).
Таги: VMware, SRM, Update, vSphere, Replication, DR
Это гостевой пост компании ИТ-ГРАД - ведущего сервис-провайдера, предоставляющего услуги аренды виртуальных машин.
Для подавляющего большинства компаний наличие двух или более собственных площадок все еще остается непозволительной роскошью. И что же делать с обеспечением непрерывности оказания ИТ-сервисов в такой ситуации? Вывод очевиден: если по каким-то причинам нет возможности использовать публичное облако в качестве основной площадки - его можно использовать в качестве резервной!
С развитием облачных технологий все большее количество заказчиков готовы отказаться от собственной инфраструктуры в пользу высокодоступных сервисов по размещению виртуальных машин в публичном облаке.
Однако остаются ситуации, обусловленные спецификой деятельности компании, наличием уже осуществленных проектов по построению приватного облака, специфическими требованиями по производительности, безопасности и т.п., которые, возможно, временны, но не дают возможности воспользоваться публичным облаком для хостинга своих ИТ-сервисов.
Возможно ли разместить резервную площадку в публичном облаке?
С какими трудностями придется столкнуться при реализации проекта?
И, в конце концов, сколько это будет стоить?
Такие вопросы все чаще возникают как на просторах сети, так и у потенциальных потребителей наших облачных услуг.
На днях, на сайте проекта VMware Labs (у нас есть тэг Labs) появилась новая утилита DRMdiagnose, с помощью которой возможно просмотреть информацию о текущем состоянии ресурсов кластера и получить рекомендации по управлению ими.
DRM - это Distributed Resource Manager, основной компонент VMware vSphere, являющийся ядром механизма VMware DRS, который осуществляет балансировку ресурсов в кластере. Основное назначение утилиты DRMdiagnose - это предоставление информации о том, что произойдет с производительностью виртуальных машин и их вычислительными ресурсами, если настройки ресурсов (limit, shares, reservation) будут изменены для какой-то из виртуальных машин. Кроме того, эта утилита выдает рекомендации относительно того, что нужно сделать с ресурсами виртуальных машин по отношению к текущим назначенным ресурсам (уменьшить, увеличить).
Появилась эта утилита по той причине, что пользователи VMware vSphere не знали, что происходит с кластером и его производительностью при регулировании настроек выделения ресурсов для виртуальных машин. Утилита позволяет получить рекомендации относительно того, как можно изменить настройки ресурсов ВМ для достижения оптимальной производительности.
DRMdiagnose позволяет увидеть рекомендации в кластере наподобие таких:
Increase CPU size of VM Webserver by 1
Increase CPU shares of VM Webserver by 4000
Increase memory size of VM Database01 by 800 MB
Increase memory shares of VM Database01 by 2000
Decrease CPU reservation of RP Silver by 340 MHz
Decrease CPU reservation of VM AD01 by 214 MHz
Increase CPU reservation of VM Database01 by 1000 MHz
Для того, чтобы начать пользоваться DRMdiagnose, нужно скопировать в рабочую папку с утилитой снапшот кластера (drmdump), содержащий информацию о виртуальных машинах и их запросы на вычислительные ресурсы. Находится он вот тут:
vCenter server appliance: /var/log/vmware/vpx/drmdump/clusterX/
vCenter server Windows 2003: %ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\
vCenter server Windows 2008: %ALLUSERSPROFILE%\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\
Сама утилитка может работать в трех режимах:
Default - если указан путь к drmdump, то выводятся все ВМ кластера, их назначенные ресурсы, а также запрашиваемые ресурсы.
Guided - если указан путь к drmdump и целевые параметры ресурсов ВМ, то утилита сгенерирует набор рекомендаций для их достижения.
Auto - если указан путь к drmdump, то будут сгенерированы рекомендации для самых несбалансированных ВМ (то есть ВМ, для которых разница между назначенными и запрашиваемыми ресурсами самая большая).
Выглядят снапшоты кластера вот так:
А вот так можно запустить утилиту в дефолтном режиме для вывода информации в файл output.txt:
Формат использования DRMdiagnose:
Работает DRMdiagnose только с VMware vCenter 5.1 и выше, скачать утилиту можно по этой ссылке.
Duncan и Frank, известные своими изысканиями в сфере механизмов отказоустойчивости (HA) и балансировки нагрузки (DRS) в виртуальной инфраструктуре VMware vSphere, опубликовали паруинтересныхматериалов, касающихся настройки среды vCloud Director и механизма Storage DRS.
Как вы знаете, в настройках кластера хранилищ (Datastore Cluster) есть галка, которая определяет, будут ли виртуальные диски VMDK машин обязательно находиться на одном хранилище (Datastore) при миграции средствами механизма Storage DRS:
Надо отметить, что галка Keep VMDKs together by default - это не совсем простая для понимания галка. Если ее не поставить, то действовать будет обратное - диски виртуальной машины будут обязательно размещаться на разных хранилищах. Это, по заверениям блоггеров, даст больше гибкости в использовании механизма SDRS в среде vCloud Director при перемещении виртуальных машин между хранилищами, что даст больше преимуществ в динамически балансирующейся среде (особенно для "тонких" дисков). Соответственно, по умолчанию галка Keep VMDKs together by default должна быть выключена.
Чтобы обезопасить бизнес вашей компании от сбоев в работе ИТ-инфраструктуры и возможной потери информации, необходимо иметь план аварийного восстановления (disaster recovery plan). Облачная услуга резервного копирования компании ИТ-ГРАД позволяет обеспечить высокую доступность и сохранность ваших данных, в том числе виртуальных машин на платформе VMware vSphere. Это на 75% эффективнее и выгоднее по сравнению с традиционными планами восстановления.
Традиционный план восстановления подразумевает организацию второй, желательно географически удаленной, площадки. Для ее организации зачастую требуется поставить практически такой же набор оборудования, что и на первой площадке. Требуется обеспечить инфраструктуру площадки, приобрести программное обеспечение для резервного копирования, все настроить и запустить. При этом затраты на создание и обслуживание второй площадки могут быть сопоставимы с затратами на основную площадку. Это означает, что обеспечение непрерывности бизнеса может съедать до 50% всего ИТ-бюджета.
Услуга облачного резервного копирования предоставляет возможность быстро увеличивать или уменьшать объемы потребления, услуга не требует первоначальных капитальных затрат, кроме того она экономически выгодна за счет эффекта масштаба (затраты на инфраструктуру дата-центра делятся на всех заказчиков услуги).
Как это работает
В рамках данной услуги, вы получаете возможность резервирования своих критичных данных (файлы, базы данных, конфигурации ОС) в вычислительное облако компании ИТ-ГРАД с целью обеспечения их целостности и сохранности. Также клиент получает клиентское программное обеспечение (поддерживаются наиболее распространенные операционные системы и серверные приложения), с помощью которого осуществляет резервное копирование данных. Передача резервируемых данных осуществляется через каналы Интернет защищенным (шифрованным) способом, и не зависит от месторасположения оборудования клиента.
Стоимость услуги резервного копирования напрямую зависит от количества и типа клиентов (сервер, рабочая станция), размера данных и параметров их хранения. Все стоимостные и качественные показатели услуги фиксируются в соглашении об уровне обслуживания (Service Level Agreement, SLA) на данную услугу.
Виртуальные машины, резервируемые в облако, можно потом использовать как основную производственную нагрузку непосредственно в облаке ИТ-ГРАД.
Frank Denneman опять написал интересную статью. Оказывается у механизма VMware Storage DRS, который производит балансировку виртуальных машин по хранилищам кластера SDRS, есть механизм задания допустимого уровня over-commitment для хранилища при миграции ВМ на тонких дисках.
Как вы знаете, у тонких VMDK-дисков (Thin Disks) виртуальных машин есть 2 параметра:
Provisioned Space - максимальный размер VMDK-файла, до которого может вырости диск виртуальной машины.
Allocated Space - текущий размер растущего VMDK-диска.
Разность этих двух парметров есть значение IdleMB, отражающее объем, на который виртуальный диск еще может вырасти. В расширенных настройках Storage DRS можно задать параметр PercentIdleMBinSpaceDemand, который определяет, сколько процентов от IdleMB механизм SDRS прибавляет к Allocated Space при выдаче и применении рекомендаций по размещению виртуальных машин на хранилищах кластера.
Рассмотрим на примере. Пусть максимальный размер диска VMDK составляет 6 ГБ при Allocated Space в 2 ГБ. Допустим мы задали PercentIdleMBinSpaceDemand = 25%. Тогда мы получим такую картину:
Таким образом, при размещении виртуальной машины на хранилище механизм Storage DRS будет считать, что ВМ занимает не 2 ГБ дискового пространства, а 2+0.25*4 = 3 ГБ. Ну и увидев такую машину на 10 ГБ-хранилище, механизм SDRS, при расчете выравнивания хранилищ по заполненности, будет считать что она занимает 3 ГБ, и свободно осталось лишь 7 ГБ.
Регулируя эту настройку можно добиться различных коэффициентов консолидации тонких VMDK-дисков машин на хранилищах. Ну и очевидно, что значение параметра PercentIdleMBinSpaceDemand равное 100% приведет к тому, что тонкие диски при размещении будут учитываться как их обычные flat-собратья.
Дни VMworld 2012 на VM Guru продолжаются. Вслед за анонсом новой версии платформы виртуализации VMware vSphere 5.1 (а также новых условий лицензирования), компания VMware анонсировала продукт VMware Site Recovery Manager 5.1 (SRM). О возможностях версии SRM 5.0 мы уже писали вот тут. vCenter Site Recovery Manager — это
продукт для управления аварийным восстановлением,
обеспечивающий надежную
защиту от аварий для виртуальных машин. SRM использует технологию VMware vSphere Replication
или средства репликации хранилищ
для централизованного управления планами восстановления и автоматизации процессов восстановления
и переноса инфраструктур VMware vSphere.
Основные ключевые возможности VMware SRM 5.1:
Возможность построения DR-конфигурации без собственного резервного датацентра. В этом случае можно использовать ЦОД сервис-провайдера, работающего по программе предоставления облачных сервисов в аренду - VSPP. В случае серьезного сбоя или аварии в инфраструктуре компания может продолжить исполнять сервисы VMware vSphere из облака.
Репликация с поддержкой приложений, а также автоматический Failback при использовании vSphere Replication. Теперь появилась интеграция SRM в механизмом VSS в гостевых ОС, кроме того обратное восстановление с резервной площадки на основную (Failback) возможно не только для технологии репликации на уровне дисковых массивов, но и для технологии репликации на уровне хоста vSphere Replication.
Поддержка окружений vSphere Essentials Plus. Как многие уже знают, в Essentials Plus появились встроенные функции vSphere Replication, которые поддерживаются со стороны SRM, поэтому данное издание полностью поддерживается со стороны последнего.
Теперь, как все это выглядит технически. В консоли SRM появились настройки репликации, учитывающие RPO и Guest OS Quiescing с поддержкой VSS. Работает это через VMware Tools в гостевой ОС:
Автоматический Failback с поддержкой vSphere Replication и перенаправлением репликации в случае возврата на основную площадку:
Запланированные миграции в целях тестирования или переезда в другой ЦОД теперь могут происходить без потери данных приложений:
Миграция в публичное облако сервис-провайдера теперь может быть произведена в случае аварии на предприятии. Об этом думали уже давно, но сделали только сейчас:
Такую конфигурацию можно протестировать без урона для инфраструктуры компании. Сейчас это доступно от следующих партнеров VMware:
FusionStorm
Hosting.com
iland
VeriStor
Terremark
Они могут предоставить различные SLA в зависимости от критичности приложений.
Также улучшилась обработка ситуации All Paths Down (APD), которая поддерживается как со стороны vSphere, так и со стороны SRM:
Ну и появилась поддержка VMware vSphere Essentials Plus, то есть СМБ-сегмент пользователей также может строить катастрофоустойчивые архитектуры для своих сервисов, что раньше было трудно себе представить.
Схема лицензирования VMware Site Recovery Manager 5.1 такова - можно купить продукт отдельно (в этом случае лицензии надо приобретать на защищаемые виртуальные машины), а можно - в составе vCloud Suite (в этом случае лицензироваться будут процессоры хост-серверов):
Традиционно у SRM остаются два издания - Standard и Enterprise. По функциональности они полностью идентичны, разница лишь в том, что изданием Standard можно защитить только 75 виртуальных машин:
Скачать пробную вирсию VMware Site Recovery Manager можно по этой ссылке.
Недавно мы уже писали о том, как работает технология балансировки нагрузки на хранилища VMware Storage DRS (там же и про Profile Driven Storage). Сегодня мы посмотрим на то, как эта технология работает совместно с различными фичами дисковых массиов, а также функциями самой VMware vSphere и других продуктов VMware.
Для начала приведем простую таблицу, из которой понятно, что поддерживается, а что нет, совместно с SDRS:
Возможность
Поддерживается или нет
Рекомендации VMware по режиму работы SDRS
Снапшоты на уровне массива (array-based snapshots)
Поддерживается
Ручное применение рекомендаций (Manual Mode)
Дедупликация на уровне массива (array-based deduplication)
Поддерживается
Ручное применение рекомендаций (Manual Mode)
Использование "тонких" дисков на уровне массива (array-based thin provisioning)
Поддерживается
Ручное применение рекомендаций (Manual Mode)
Использование функций автоматического ярусного хранения (array-based auto-tiering)
Поддерживается
Ручное применение рекомендаций (Manual Mode), только для распределения по заполненности хранилищ (auto-tiering по распределению нагрузки сам решит, что делать)
Репликация на уровне массива (array-based replication)
Автоматическое применение рекомендаций (Fully Automated Mode)
Технология репликации на уровне хоста (VMware vSphere Replication)
Не поддерживается
-----
Снапшоты виртуальных машин (VMware vSphere Snapshots)
Поддерживается
Автоматическое применение рекомендаций (Fully Automated Mode)
Использование "тонких" дисков на уровне виртуальных хранилищ (VMware vSphere Thin Provisioning)
Поддерживается
Автоматическое применение рекомендаций (Fully Automated Mode)
Технология связанных клонов (VMware vSphere Linked Clones)
Не поддерживается
-----
"Растянутый" кластер (VMware vSphere Storage Metro Cluster)
Поддерживается
Ручное применение рекомендаций (Manual Mode)
Хосты с версией ПО, младше чем vSphere 5.0
Не поддерживается
-----
Использование совместно с продуктом VMware vSphere Site Recovery Manager
Не поддерживается
-----
Использование совместно с продуктом VMware vCloud Director
Не поддерживается
-----
Комментарии к таблице:
Снапшоты на уровне массива - они никак не влияют на работу механизма SDRS, однако рекомендуется оставить его в ручном режиме, чтобы избежать возможных проблем при одновременном создании снапшота и перемещении виртуальных дисков.
Дедупликация на уровне массива - полностью совместима со механизмом SDRS, однако рекомендуется ручной режим, так как, с точки зрения дедупликации, наиболее эффективно сначала применить рекомендации по миграции виртуальных дисков, а потом уже использовать дедупликацию (для большинства сценариев).
Использование array-based auto-tiering - очевидно, что функции анализа производительности в дисковом массиве и перемещения данных по ярусам с различными характеристиками могут вступить вступить в конфликт с алгоритмами определения нагрузки в SDRS и перемещения vmdk-дисков по хранилищам на логическом уровне. Сам Storage DRS вступает в действие после 16 часов анализа нагрузки и генерирует рекомендации каждые 8 часов, в дисковом же массиве механизм перераспределения блоков по ярусам может работать по-разному: от real-time процесса в High-end массивах, до распределения каждые 24 часа в недорогих массивах. Понятно, что массиву лучше знать, какие блоки куда перемещать с точки зрения производительности физических устройств, поэтому для SDRS рекомендуется оставить выравнивание хранилищ только по заполненности томов VMFS, с отключенной I/O Metric.
Репликация на уровне массива - полностью поддерживается со стороны SDRS, однако, в зависимости от использования метода репликации, во время применения рекомендаций SDRS виртуальные машины могут остаться в незащищенном состоянии. Поэтому рекомендуется применять эти рекомендации SDRS во время запланированного окна обслуживания хранилищ.
VMware vSphere Storage Metro Cluster - здесь нужно избегать ситуации, когда виртуальный диск vmdk машины может уехать на другой сайт по отношению к хосту ESXi, который ее исполняет (когда используется общий Datastore Cluster хранилищ). Поэтому, а еще и потому, что распределенные кластеры могут строиться на базе технологий синхронной репликации хранилищ (см. предыдущий пункт), нужно использовать ручное применение рекомендаций SDRS.
Поддержка VMware vSphere Site Recovery Manager - на данный момент SDRS не обнаруживает Datastore Groups в SRM, а SRM не отслеживает миграции SDRS по хранилищам. Соответственно, при миграции ВМ на другое хранилище не обновляются protection groups в SRM, как следствие - виртуальные машины оказываются незащищенными. Поэтому совместное использование этих продуктов не поддерживается со стороны VMware.
Поддержка томов RDM - SDRS полностью поддерживает тома RDM, однако эта поддержка совершенно ничего не дает, так как в миграциях может участвовать только vmdk pointer, то есть прокси-файл виртуального диска, который занимает мало места (нет смысла балансировать по заполненности) и не генерирует никаких I/O на хранилище, где он лежит (нет смысла балансировать по I/O). Соответственно понадобиться эта поддержка может лишь на время перевода Datastore, где лежит этот файл-указатель, в режим обслуживания.
Поддержка VMware vSphere Replication - SDRS не поддерживается в комбинации с хостовой репликацией vSphere. Это потому, что файлы *.psf, используемые для нужд репликации, не поддерживаются, а даже удаляются при миграции ВМ на другое хранилище. Вследствие этого, механизм репликации для смигрированной машины считает, что она нуждается в полной синхронизации, что вызывает ситуацию, когда репликация будет отложена, а значит существенно ухудшатся показатели RTO/RPO. Поэтому (пока) совместное использование этих функций не поддерживается.
Поддержка VMware vSphere Snapshots - SDRS полностью поддерживает спапшоты виртуальных машин. При этом, по умолчанию, все снапшоты и виртуальные диски машины при применении рекомендаций перемещаются на другое хранилище полностью (см. левую часть картинки). Если же для дисков ВМ настроено anti-affinity rule, то они разъезжаются по разным хранилищам, однако снапшоты едут вместе со своим родительским диском (см. правую часть картинки).
Использование тонких дисков VMware vSphere - полностью поддерживается SDRS, при этом учитывается реально потребляемое дисковое пространство, а не заданный в конфигурации ВМ объем виртуального диска. Также SDRS учитывает и темпы роста тонкого виртуального диска - если он в течение последующих 30 часов может заполнить хранилище до порогового значения, то такая рекомендация показана и применена не будет.
Технология Linked Clones - не поддерживается со стороны SDRS, так как этот механизм не отслеживает взаимосвязи между дисками родительской и дочерних машин, а при их перемещении между хранилищами - они будут разорваны. Это же значит, что SDRS не поддерживается совместно с продуктом VMware View.
Использование с VMware vCloud Director - пока не поддерживается из-за проблем с размещением объектов vApp в кластере хранилищ.
Хосты с версией ПО, младше чем vSphere 5.0 - если один из таких хостов поключен к тому VMFS, то для него SDRS работать не будет. Причина очевидна - хосты до ESXi 5.0 не знали о том, что будет такая функция как SDRS.
Одним из ключевых нововведений VMware vSphere 5, безусловно, стала технология выравнивания нагрузки на хранилища VMware vSphere Storage DRS (SDRS), которая позволяет оптимизировать нагрузку виртуальных машин на дисковые устройства без прерывания работы ВМ средствами технологии Storage vMotion, а также учитывать характеристики хранилищ при их первоначальном размещении.
Основными функциями Storage DRS являются:
Балансировка виртуальных машин между хранилищами по вводу-выводу (I/O)
Балансировка виртуальных машин между хранилищами по их заполненности
Интеллектуальное первичное размещение виртуальных машин на Datastore в целях равномерного распределения пространства
Учет правил существования виртуальных дисков и виртуальных машин на хранилищах (affinity и anti-affinity rules)
Ключевыми понятими Storage DRS и функции Profile Driven Storage являются:
Datastore Cluster - кластер виртуальных хранилищ (томов VMFS или NFS-хранилищ), являющийся логической сущностью в пределах которой происходит балансировка. Эта сущность в чем-то похожа на обычный DRS-кластер, который составляется из хост-серверов ESXi.
Storage Profile - профиль хранилища, используемый механизмом Profile Driven Storage, который создается, как правило, для различных групп хранилищ (Tier), где эти группы содержат устройства с похожими характеристиками производительности. Необходимы эти профили для того, чтобы виртуальные машины с различным уровнем обслуживания по вводу-выводу (или их отдельные диски) всегда оказывались на хранилищах с требуемыми характеристиками производительности.
При создании Datastore Cluster администратор указывает, какие хранилища будут в него входить (максимально - 32 штуки в одном кластере):
Как и VMware DRS, Storage DRS может работать как в ручном, так и в автоматическом режиме. То есть Storage DRS может генерировать рекомендации и автоматически применять их, а может оставить их применение на усмотрение пользователя, что зависит от настройки Automation Level.
С точки зрения балансировки по вводу-выводу Storage DRS учитывает параметр I/O Latency, то есть round trip-время прохождения SCSI-команд от виртуальных машин к хранилищу. Вторым значимым параметром является заполненность Datastore (Utilized Space):
Параметр I/O Latency, который вы планируете задавать, зависит от типа дисков, которые вы используете в кластере хранилищ, и инфраструктуры хранения в целом. Однако есть некоторые пороговые значения по Latency, на которые можно ориентироваться:
SSD-диски: 10-15 миллисекунд
Диски Fibre Channel и SAS: 20-40 миллисекунд
SATA-диски: 30-50 миллисекунд
По умолчанию рекомендации по I/O Latency для виртуальных машин обновляются каждые 8 часов с учетом истории нагрузки на хранилища. Также как и DRS, Storage DRS имеет степень агрессивности: если ставите агрессивный уровень - миграции будут чаще, консервативный - реже. Первой галкой "Enable I/O metric for SDRS recommendations" можно отключить генерацию и выполнение рекомендаций, которые основаны на I/O Latency, и оставить только балансировку по заполненности хранилищ.
То есть, проще говоря, SDRS может переместить в горячем режиме диск или всю виртуальную машину при наличии большого I/O Latency или высокой степени заполненности хранилища на альтернативный Datastore.
Самый простой способ - это балансировка между хранилищами в кластере на базе их заполненности, чтобы не ломать голову с производительностью, когда она находится на приемлемом уровне.
Администратор может просматривать и применять предлагаемые рекомендации Storage DRS из специального окна:
Когда администратор нажмет кнопку "Apply Recommendations" виртуальные машины за счет Storage vMotion поедут на другие хранилища кластера, в соответствии с определенным для нее профилем (об этом ниже).
Аналогичным образом работает и первичное размещение виртуальной машины при ее создании. Администратор определяет Datastore Cluster, в который ее поместить, а Storage DRS сама решает, на какой именно Datastore в кластере ее поместить (основываясь также на их Latency и заполненности).
При этом, при первичном размещении может случиться ситуация, когда машину поместить некуда, но возможно подвигать уже находящиеся на хранилищах машины между ними, что освободит место для новой машины (об этом подробнее тут):
Как видно из картинки с выбором кластера хранилищ для новой ВМ, кроме Datastore Cluster, администратор первоначально выбирает профиль хранилищ (Storage Profile), который определяет, по сути, уровень производительности виртуальной машины. Это условное деление хранилищ, которое администратор задает для хранилищ, обладающих разными характеристиками производительности. Например, хранилища на SSD-дисках можно объединить в профиль "Gold", Fibre Channel диски - в профиль "Silver", а остальные хранилища - в профиль "Bronze". Таким образом вы реализуете концепцию ярусного хранения данных виртуальных машин:
Выбирая Storage Profile, администратор будет всегда уверен, что виртуальная машина попадет на тот Datastore в рамках выбранного кластера хранилищ, который создан поверх дисковых устройств с требуемой производительностью. Профиль хранилищ создается в отельном интерфейсе VM Storage Profiles, где выбираются хранилища, предоставляющие определенный набор характеристик (уровень RAID, тип и т.п.), которые платформа vSphere получает через механизм VASA (VMware vStorage APIs for Storage Awareness):
Ну а дальше при создании ВМ администратор определяет уровень обслуживания и характеристики хранилища (Storage Profile), а также кластер хранилища, датасторы которого удовлетворяют требованиям профиля (они отображаются как Compatible) или не удовлетворяют им (Incompatible). Концепция, я думаю, понятна.
Регулируются профили хранилищ для виртуальной машины в ее настройках, на вкладке "Profiles", где можно их настраивать на уровне отдельных дисков:
На вкладке "Summary" для виртуальной машины вы можете увидеть ее текущий профиль и соответствует ли в данный момент она его требованиям:
Также можно из оснастки управления профилями посмотреть, все ли виртуальные машины находятся на тех хранилищах, профиль которых совпадает с их профилем:
Далее - правила размещения виртуальных машин и их дисков. Определяются они в рамках кластера хранилищ. Есть 3 типа таких правил:
Все виртуальные диски машины держать на одном хранилище (Intra-VM affinity) - установлено по умолчанию.
Держать виртуальные диски обязательно на разных хранилищах (VMDK anti-affinity) - например, чтобы отделить логи БД и диски данных. При этом такие диски можно сопоставить с различными профилями хранилищ (логи - на Bronze, данны - на Gold).
Держать виртуальные машины на разных хранилищах (VM anti-affinity). Подойдет, например, для разнесения основной и резервной системы в целях отказоустойчивости.
Естественно, у Storage DRS есть и свои ограничения. Основные из них приведены на картинке ниже:
Основной важный момент - будьте осторожны со всякими фичами дискового массива, не все из которых могут поддерживаться Storage DRS.
И последнее. Технологии VMware DRS и VMware Storage DRS абсолютно и полностью соместимы, их можно использовать совместно.
Как знают пользователи виртуализации от Microsoft, в средстве управления System Center Virtual Machine Manager 2008 R2 имелась функция Performance and Resource Optimization (PRO), которая позволяла осуществлять балансировку нагрузки на хост-серверы виртуальной инфраструктуры Hyper-V. Происходит это путем горячей миграции виртуальных машин с загруженных на незагруженные хосты, за счет использования пороговых значений на хостах, задаваемых пользователем (т.е. превышение лимитов памяти или утилизации процессора). По-сути, это аналог VMware DRS в VMware vSphere (и даже Storage DRS, поскольку через партнерские решения могут отслеживаться параметры производительности хранилищ). Миграция виртуальных машин в соответствии с рекомендациями PRO может проводиться автоматически или вручную:
Большим недостатком данной технологии было то, что она требовала наличия продукта System Center Operations Manager, который есть далеко не у всех СМБ-пользователей.
В System Center Virtual Machine Manager 2012 технология PRO была заменена на техники Dynamic Optimization и Power Optimization, которые уже, к счастью, не зависят от Operations Manager и не требуют его. Также появились функции Power Optimization, которые позволяют отключать хост-серверы Hyper-V с малой нагрузкой, за счет миграции с них виртуальных машин (также по пороговым значениям, задаваемым пользователем), в целях экономии электроэнергии (аналог VMware Distributed Power Management, который является частью технологии DRS).
Dynamic Optimization и Power Optimization в SC VMM 2012 позволяют нам настроить следующие параметры:
Степерь агрессивности Dynamic Optimization при применении рекомендаций в кластере или группе хостов (Host group)
Автоматический или ручной режим работы
Интервал между генерациями и применением рекомендаций (по умолчанию 10 минут)
Использовать или нет Power Optimization
Окно (промежуток времени в течение суток), в котое Power Optimization будет работать
Так выглядят настройки Dynamic Optimization:
Пользователь определяет минимальные значения доступных ресурсов при размещении виртуальных машин на хостах:
Обратите, внимание, что пороговые значения могут быть заданы и для Disk I/O, т.е. виртуальную машину можно смигрировать не только между хостами, но и хранилищами средствами технологии Storage Live Migration.
Хосты, находящиеся в режиме обслуживания (maintenance mode) исключаются из механизма Dynamic Optimization.
А так настройка окна Power Optimization:
Все очень просто - ночью нагрузка спадает и можно смигрировать виртуальные машины с некоторых хостов, а сами хосты выключить. Потом окно заканчивается (начинается рабочий день) - хосты включаются, виртуальные машины переезжают на них, а Power Optimization не вмешивается.
Таким образом, получается, что Dynamic Optimization и Power Optimization в System Center Virtual Machine Manager 2012 представляют собой аналог VMware DRS и sDRS, что будет очень приятным моментом при использовании SC VMM 2012 с Hyper-V 3.0. И напоследок отметим, что функции Dynamic Optimization и Power Optimization в VMM 2012 работают при управлении не только хостами Hyper-V, но и платформами VMware vSphere и Citrix XenServer.
Но все же отличие Dynamic Optimization от VMware DRS есть - для Dynamic Optimization нельзя задавать Anti-affinity rules, что может оказаться некоторым неудобством для администраторов.
Как многие из вас знают, в среде VMware vSphere есть специализированные виртуальные машины, которую выполняют служебные функции, специфические для виртуальной инфраструктуры. К ним, например, можно отнести, виртуальные агенты (Agent VMs) - машины, предназначенные для того, чтобы присутствовать на хосте всегда (т.е. не участвовать в DRS/DPM) и обслуживать другие ВМ. Хороший пример - это антивирусные виртуальные модули (Virtual Appliance), которые сейчас есть у Trend Micro и Касперского и которые работают через vShield Endpoint и VMsafe API:
Логично предположить, что эти виртуальные машины в среде VMware vSphere надо обрабатывать как-то по-особенному. Это так и происходит. Давайте посмотрим, как это делается:
1. Платформа vSphere помечает внутри себя такие виртуальные машины как виртуальные агенты (Agent VMs).
2. Поскольку виртуальный агент должен предоставлять сервис для других виртуальных машин, агенские ВМ, в случае сбоя, на каждом хосте запускаются в первую очередь, чтобы не оставить никого без этого сервиса.
Таким образом, в случае сбоя порядок загрузки ВМ на хосте ESXi следующий:
стартуют виртуальные агенты
запускаются Secondary виртуальные машины для тех, которые защищены технологией Fault Tolerance
поднимаются виртуальные машины с высоким, средним и низким приоритетом, соответственно
3. Механизм VMware DRS/DPM, осуществляющий балансировку виртуальных машин по хостам средствами vMotion и экономию электропитания серверов средствами их отключения при недогрузке датацентра, также в курсе о виртуальных агентах. Поэтому здесь следующее поведение:
DRS учитывает Reservations, заданные для агентов, даже в том случае, когда они выключены
для режимов обслуживания (maintenance mode) и Standby - виртуальные агенты никуда с хоста автоматически не мигрируют
виртуальные агенты должны быть доступны на хосте перед тем, как там будут включены обычные ВМ или они туда будут смигрированы
Вот эта заметка на блоге VMware напомнила об одной интересной особенности поведения правил совместного и несовместного размещения виртуальных машин на хосте ESX/ESXi (DRS Host Affinity Rules).
Напомним, что для виртуальных машин в класетере DRS можно задавать данные правила для ситуаций, когда требуется определенным образом распределять группы виртуальных машин по хостам или их группам. Требуется это обычно для соблюдения правил лицензирования (см., например, правила лицензирования для ВМ Oracle), когда виртуальные машины могут исполняться только на определенных физических серверах, либо для всяких экзотических ситуаций, когда, к примеру, основную и резервную системут нужно держать на разных хостах.
То есть, мы задаем группы виртуальных машин и хостов:
И указываем, что виртуальные машины DRS-группы могут работать только на данной DRS-группе хостов:
Правила эти бывают мягкими (preferential), когда DRS+HA будут стараться следовать им при штатном функционировании кластера, и жесткими (mandatory, "Must run") - в этом случае ни при каких условиях виртуальные машины не переедут на хосты не из группы. Этого не произойдет ни средствами vMotion/DRS/Maintenance Mode, ни средствами перезапуска HA в аварийных ситуациях.
Для жестких правил есть один интересный аспект: они сохраняются и продолжают действовать даже тогда, когда вы отключили кластер VMware DRS. То есть вы не сможете сделать ручной vMotion или Power On машин на хостах не из группы, а HA не будет их там перезапускать. При этом в настройках кластера с отключенным DRS уже не будет возможности редактирования этих правил (категория VMware DRS пропадет). Это сделано для того, чтобы во время временных сбоев (например, vCenter) лицензионные правила существования ВМ для приложений на хостах не нарушались в любом случае.
Поэтому, если нужно удалить правила, нужно снова включить DRS, удалить их и снова отключить DRS.
Таги: VMware, DRS, Обучение, vSphere, ESX, ESXi, vMotion, HA
Многие из вас знают продукт номер 1 для резервного копирования виртуальных машин VMware vSphere - Veeam Backup and Replication. Мы уже много писали как о функциональности Veeam Backup and Replication 5, так и о новых возможностях, которые появляются в Veeam Backup and Replication 6. В среду, 30 ноября, должен состояться релиз новой версии продукта, поэтому постараемся в этой статье собрать все новые функции, улучшения и нововведения Veeam Backup and Replication 6 (обратите также внимание на повышение цен на продукт с 1 декабря).
Приведенная ниже информация основана на документе "Veeam Backup & Replication. What's new in v6", который вы можете почитать в оригинале для понимания всех аспектов новых возможностей этого средства для резервного копирования виртуальных машин.
Новые ключевые возможности и улучшения Veeam Backup and Replication 6:
Enterprise scalability: улучшенная архитектура продукта позволяет производить развертывание в удаленных офисах и филиалах, а также для больших инсталляций. Теперь появилось несколько backup proxy серверов для крупных окружений (data movers), которые могут распределять между собой нагрузку в процессе резервного копирования, а управляет процессом сервер Veeam Enterprise Manager. Виртуальные машины динамически назначаются proxy-серверам с учетом алгоритма балансировки нагрузки, что снижает затраты на администрирование инфраструктуры РК. Также увеличена производительность для резервного копирования, репликации и восстановления по WAN-каналам.
Advanced replication: в некоторых случаях скорость репликации выросла до 10 раз, а также появится Failback (обратное восстановление виртуальной машины после возобновления работы отказавшего хоста с ВМ) с возможностью синхронизации дельты (различия данных с момента отказа основной машины на основном сервере и хранилище - Failover). Кроме того, поддерживается репликация в thin provisined-диски на целевой сервер. Это сильная заявка на победу над VMware SRM 5 (в издании Standard) для небольших компаний, где серверов не много и нужно укладываться в небольшие бюджеты. Появилась также возможность создания реплик базового образа для окружений VMware View.
Multi-hypervisor support: полная поддержка Windows Server с ролью Hyper-V и Microsoft Hyper-V Server, а также возможность управления резервным копированием для гипервизоров разных производителей из одной консоли. Одна и та же инсталляция Veeam Backup позволит делать резервные копии и с VMware vSphere, и с Microsoft Hyper-V. При этом лицензирование также единое - один пул лицензий Veeam вы можете распределить между лицензиями на процессоры для хостов ESXi и Hyper-V. Кроме того, появилась поддержка методики Changed Block Tracking для Hyper-V для ускорения процесса инкрементального резервного копирования (отслеживание изменившихся блоков с момента последнего бэкапа).
1-Click File Restore - с помощью 1-Click File Restore можно зайти в Enterprise Manager, выбрать нужный файл и восстановить туда, откуда он был удален (это можно сделать также из результатов поиска файла по резервным копиям). При этом есть разделение ролей - есть тот, кто может файл восстановить (helpdesk), а есть тот, кто открыть. Данная возможность доступна только в Enterprise Edition.
Полный список новых возможностей:
Архитектура Veeam Backup and Replication 6
ESXi-centric processing engine - теперь архитектура продукта полностью опирается на архитектуру ESXi, но в поддержка гипервизора ESX остается в полной мере.
Backup proxy servers - один сервер Veeam Backup может контролировать несколько прокси-серверов, обеспечивающих передачу данных на целевые хранилища. Прокси-серверы не нуждаются в Microsoft SQL
Server и содержат минимальный набор компонентов.
Backup repositories - новая концепция репозиториев резервного копирования (в традиционном РК известная как медиа-серверы), которые хранят настройки задач резервного копирования и параметры целевых хранилищ. Задачи по РК виртуальных машин с помощью медиа-серверов динамически назначаются proxy-серверам с учетом алогоритма балансировки нагрузки.
Windows smart target - в дополнение к Linux target agent, который помогает при резервном копировании в удаленные хранилища, появился также агент для Windows. Этот агент на целевой машине позволяет производить эффективную компрессию и обновлять синтетические резервные копии.
Enhanced vPower scalability - теперь можно использовать несколько серверов vPower NFS. Теперь можно запускать еще больше ВМ напрямую из резервных копий (например, если у вас много ВМ с большими дисками это очень может помочь). Любой сервер РК Veeam или Windows backup repository может быть таким сервером.
Ядро продукта Veeam Backup and Replication 6
Optimization of source data retrieval - теперь учитываются параметры дисковых хранилищ при обращении к виртуальным машинам. Это позволяет до 4-х раз увеличить производительность для одной операции, в зависимости от настроек дискового массива.
Reduced CPU usage - теперь в два раза меньше нагрузка задач на процессор, что позволяет запустить больше задач РК или репликации на одном сервере Veeam Backup или прокси-сервере.
Traffic throttling - теперь доступны опции по регулированию полосы пропускания, которые производятся на базе пары source/target IP. Эти правила могут быть основаны на времени операций - время дня или день недели.
Multiple TCP/IP connections per job - теперь агенты Data Movers могут инициировать соединение по нескольким IP-адресам, что существенно увеличивает скорость резервного копирования. Особенно это эффективно для репликации по WAN-каналам.
WAN optimizations - протокол передачи данных Veeam Backup был существенно доработан в плане производительности для передачи данных по соединениям с большими задержками в канале.
Exclusion of swap files - блоки, относящиеся к файлам подкачки, теперь исключаются из передачи в резервную копию, что существенно увеличивает производительность.
Enforceable processing window - теперь для каждой задачи можно задавать окно РК или репликации (все задачи, не попадающие в это окно завершаются). Также вне рамок окна не разрешается применение снэпшотов, что не позволяет оказывать влияние на производительность ВМ в рабочие часы.
Parallel backup and replication - теперь задачи, относящиеся к одной и той же ВМ, могут быть выполнены параллельно. Например, вы можете запускать ежедневную задачу Full Backup параллельно с работающей задачей репликации.
Улучшения резервного копирования в Veeam Backup and Replication 6
Backup mapping - при создании новой задачи резервного копирования ВМ, ее можно присоединить к уже имеющейся задаче (например, в ней есть уже файлы этой ВМ). В этом случае Full Backup этой ВМ может не потребоваться.
Enhanced backup file format - новый формат метаданных позволяет осуществлять быстрый импорт резервных копий, а также закладывает основу для поддержки новой функциональности в следующих релизах продукта.
Backup file data alignment - данные ВМ, сохраненные в бэкап-файле, могут быть размещены в пределах блоков по 4 КБ. Это увеличивает производительность дедупликации как самого Veeam Backup, так и сторонних технологий дедупликации (например, средствами дискового массива).
Improved compatibility with deduplicating storage - теперь механизм РК оказывает меньшее влияние на предыдущие файлы резервной копии, что улучшает производительность массивов, которые осуществляют пост-процессинг хранимых данных.
Репликация Veeam Backup and Replication 6
New replication architecture - теперь репликация использует двухагентную архитектуру, которая позволяет собирать данные хранилищ ВМ на исходном DR-сайте одним прокси-сервером РК и посылать их напрямую к прокси-серверу резервной площадки (и наоборот), минуя главный сервер Veeam Backup. Поэтому теперь не разницы, где размещать последний.
Replica state protection - теперь инкрементальные задачи репликации больше не обновляют последнюю точку восстановления ВМ. Это позволяет при прерывании задачи не перестраивать последнюю точку восстановления до того, как следующая задача откатит ее к последнему согласованному состоянию, как в прошлых версиях. В версии 6 последняя точка восстановления всегда согласована и ВМ может быть запущена в любой момент.
Traffic compression - за счет новой архитектуры репликации теперь не важно где находится основной сервер РК Veeam, а трафик сжимается намного более эффективно. Кроме того, появились настройки уровня компрессии для передаваемого трафика, что позволяет уменьшить требования к полосе пропускания до 5 раз.
Hot Add replication - теперь прокси-сервер на целевой площадке представляет диски реплики, используя технологию Hot Add. Это уменьшает поток трафика до 4 раз.
1-click automated failback - позволяет произвести обратное восстановление (Failback) виртуальной машины после возобновления работы отказавшего хоста с ВМ с возможностью синхронизации только дельты с момента последнего отказа (Failover), т.е. различия данных с момента отказа основной машины на основном сервере и хранилище) . Перед завершением этого процесса можно проверить ВМ на работоспособность на основной площадке.
1-click permanent failover - возможность в один клик провести все необходимые процедуры по завершению процесса превращения резервной машины в основную, когда в случае отказа основной ВМ она переместилась на резервный сайт.
Active rollbacks - репликация теперь хранит точки восстановления как обычные снапшоты ВМ. Это позволяет откатиться в любую точку на резервной площадке, даже без участия Veeam Backup.
Improved replica seeding - улучшения механизма организации репликации. Теперь репликация использует обычные бэкап-файлы, это позволяет уменьшить размер передаваемых данных, поддерживаются ВМ с тонкими (thin) дисками и многое другое.
Replica mapping - теперь реплицируемую виртуальную машину можно привязать к уже существующей ВМ на резервной площадке (например, ранее для нее использовалась репликация или на резервную площадку ее восстановили из резервной копии). Это позволяет не передавать весь объем данных для создания реплицируемой пары.
Re-IP - теперь можно задать правила автоматического назначения IP-адреса для восстанавливаемой ВМ. Это очень полезно, когда требуется восстановить ВМ на резервную площадку, где действует другая схема IP-адресации, в случае сбоя основной.
Cluster target - задачи репликации теперь поддерживают указание определенного хоста или кластера как целевого для репликации. Это позволяет убедиться в том, что при восстановлении ВМ она окажется доступной (например, на резервной площадке).
Full support for DVS - полная поддержка распределенных коммутаторов VMware Distributed Virtual Switches технологией репликации, что позволяет передавать состояние реплики без дополнительных ручных операций (например, в окружениях с VMware vCloud Director).
Automatic job update - операции failover и failback автоматически обновляют задачу репликации путем исключения из нее ВМ и повторного добавления.
Multi-select operations - в консоли теперь можно выбрать несколько ВМ для операций с репликацией. Например, при массовом выходе из строя хостов можно провести операции failover сразу с несколькими ВМ (аналогично и для failback).
Enhanced job configuration - теперь мастер создания реплицируемой пары поддерживает возможность настройки репликации на уровне vmdk-дисков, а также предоставляет возможность настроить целевые объекты: resource pool, VM folder и virtual network, где будет размещаться реплика и восстанавливаться ВМ.
Миграция виртуальных машин в Veeam Backup and Replication 6
Quick Migration - эта технология позволяет организовать миграцию виртуальной машины между хостами и/или хранилищами путем передачи данных ВМ в фоновом режиме (пока она запущена) и потом на время простоя (переключения) передается только дельта файлов vmdk. Переключение осуществляется с помощью технологии SmartSwitch или просто повторной загрузкой ВМ. По сути, эта функция - аналог vMotion и Storage vMotion, но с небольшим простоем ВМ.
SmartSwitch - эта технология позволяет передать текущее состояние ВМ от исходного хоста и хранилища к источнику на время переключения виртуальной машины между ними (с простоем). При этом процессоры исходного и целевого хостов должны быть совместимы по инструкциями.
Migration jobs - новый тип задач "миграция ВМ". С учетом имеющейся у вас лицензии на VMware vSphere, мастер миграции выполняет одну из следующих задач: VMware vMotion, VMware Storage vMotion, Veeam Quick Migration
with SmartSwitch или Veeam Quick Migration with cold switch. Это позволяет быстро перевести ВМ с хостов, для которых требуется срочное обслуживание или останов (например, электричество выключили, а они на UPS'ах) или перенести ВМ в другой датацентр с минимальным влиянием на доступность сервисов в ВМ.
Instant VM Recovery integration - задачи миграции ВМ теперь оптимизированы для работы с функцией Instant VM Recovery. Если задача миграции обнаруживает, что ВМ переносится из состояния, когда она была мгновенно восстановлена (т.е. дельта размещается на vPower NFS datastore), то постоянная составляющая этой ВМ берется из бэкап-файла, а различия уже с NFS-хранилища для ускорения процесса миграции и оптимизации производительности.
Копирование файлов в Veeam Backup and Replication 6
Support for copying individual file - поддержка копирования отдельных файлов. Задача по копированию файлов теперь поддерживается так же, как и для каталогов.
Восстановление виртуальных машин в Veeam Backup and Replication 6
1-click VM restore - при восстановлении ВМ в исходное размещение (самый частый случай), это может быть сделано в один клик.
Virtual Disk Restore wizard - новый режим восстановления позволяет восстановить отдельные vmdk-диски в их исходное размещение или присоединить к другой или новой ВМ. При этом мастер Virtual Disk Restore может восстанавливать диски как "thin" (т.е. растущими по мере наполнения данными), а также делает все необходимые настройки в заголовочном vmdk-файле.
Hot Add restores - Veeam Backup первым стал поддерживать технологию Hot Add не только для РК, но и для восстановления vmdk-дисков, что позволяет избежать проблем производительности.
Multi-VM restore - возможность восстановления сразу многих ВМ из графического интерфейса, что очень удобно для случаев массовых отказов хранилищ или хост-серверов.
Full support for DVS - полная поддержка распределенных коммутаторов VMware Distributed Virtual Switches и улучшения в интерфейсе по интеграции с ним (что удобно, например, при использовании совместно с vCloud Director).
Network mapping - при восстановлении виртуальных машин на сервер или площадку с другой конфигурацией виртуальных сетей, можно указать новые параметры сетевого взаимодействия.
moRef preservation - при восстановлении ВМ с заменой существующей копии, ее идентификатор сохраняется, что позволяет не перенастраивать задачи Veeam, а также стороннее ПО, работающее с виртуальными машинами по их идентификатору (почти все так и работают).
Восстановление на уровне файлов в Veeam Backup and Replication 6
Support for GPT and simple dynamic disks - теперь восстановление на уровне файлов поддерживает тома GPT и simple dynamic disks.
Preservation of NTFS permissions - опционально при восстановлении файлов Windows можно сохранить владельца и права на них в NTFS.
Индексирование и поиск файлов в резервных копиях Veeam Backup and Replication 6
Optional Search Server - теперь поиск по файлам гостевой ОС работает без Microsoft Search Server. Однако он рекомендуется для больших окружений с сотнями ВМ для лучшей производительности.
Reduced catalog size - размер каталога файловой системы гостевых ОС существенно уменьшился, что позволяет экономить место на сервере Veeam Backup.
User profile indexing - появилась поддержка индексации профиля пользователя в гостевой ОС.
Статистика и отчетность в Veeam Backup and Replication 6
Enhanced real-time statistics - теперь статистика в реальном времени по задачам РК улучшена в плане дизайна, чаще обновляется и более информативна для пользователя.
Improved job reports - отчеты о задачах РК лучше выглядят, имеют дополнительную информацию, включая количество изменившихся данных, уровень компрессии и коэффициент дедупликации.
Bottleneck monitor - в ответ на наиболее частые вопросы о низкой производительности в различных окружениях, Veeam сделала новый компонент, который позволяет выявить узкие места на различных стадиях РК и репликации. Все это отображается в статистике реального времени.
VM loss warning - история задач РК теперь оповещает пользователя о виртуальных машинах, которые раньше бэкапились, а потом задачи РК перестали существовать (например, случайно или намеренно удалили).
Интерфейс пользователя консоли Veeam Backup and Replication 6
Wizard improvements - все мастера были обновлены для возможности быстрой навигации при создании задач РК. Некоторые мастера стали динамическими - т.е. сфокусированными только на той задаче, которую вы хотите выполнить.
VM ordering - мастера резервного копирования и репликации теперь позволяют задать порядок, в котором ВМ должны обрабатываться.
Multi-user access - доступ нескольких пользователей к консоли теперь включен по умолчанию, позволяя нескольким пользователям получить доступ к консоли по RDP на одном сервере.
Веб-интерфейс Enterprise Manager в Veeam Backup and Replication 6
Job editing - в дополнение к управлению задачами, Enterprise Manager позволяет теперь менять их настройки для защищаемых ВМ, бэкап-репозитории, учетную запись гостевой ОС - все прямо из веб-интерфейса.
Job cloning - существующие задачи теперь могут быть клонированы прямо из веб-интерфейса с сохранением всех настроек.
Helpdesk FLR - появилась новая роль "File Restore Operator" в Enterprise Manager, которой делегированы полномочия по восстановлению отдельных файлов. Ее можно назначить персоналу службы help desk. При этом файлы восстанавливаются в их исходное размещение, а персоналу hepl desk можно ограничить возможности их скачивания, и, соответственно, доступа к ним (есть настройки касательно типов файлов и прочее).
FIPS compliance - веб-интерфейс теперь полностью совмести с стандартом FISP.
Design improvements - веб-интерфейс имеет множество улучшений в плане юзабилити и дизайна.
Улучшения технологии SureBackup в Veeam Backup and Replication 6
Improved DC handling - теперь улучшена работа с контроллерами домена в ситуациях, когда он оказывается изолированным в окружениях с несколькими DC.
Support for unmanaged VMware Tools - задачи SureBackup теперь поддерживают виртуальные машины с пакетами VMware Tools, которые установлены вручную.
Остальные улучшения Veeam Backup and Replication 6
Enhanced PowerShell support - расширены возможности PowerShell API, что позволяет управлять всеми настройками Veeam Backup. Все командлеты PowerShell были упрощены в плане синтаксиса (старый синтаксис также поддерживается). Появились маски в именах объектов, поиск объектов - все аналогично возможностям в консоли.
Log collection wizard - новый мастер, который собирает лог-файлы с защищенных хостов и подготавливает пакет, необходимый при обращении в техподдержку Veeam.
1-click automated upgrade - все компоненты продукта, включая те, что установлены на удаленной площадке (backup
proxy servers и backup repositories), могут быть просто обновлены с использованием мастера Upgrade wizard. При открытии консоли, Veeam Backup & Replication автоматически определяет компоненты решения, которые следует обновить.
Продукт Veeam Backup and Replication 6 должен быть доступен для скачивания с сайта Veeam ориентировочно в среду на странице загрузки продукта.
Несколько скриншотов. Восстановление файла резервной копии из результатов поиска в Enterprise Manager:
Настройки Traffic Throttling:
Мастер восстановления виртуальной машины Microsoftc Hyper-V:
Настройка бэкап-репозиториев:
Настройки Re-IP при восстановлении на резервной площадке:
Интересный момент обнаружился на блогах компании VMware. Оказывается, если вы используете в кластере VMware HA разные версии платформы VMware ESXi (например, 4.1 и 5.0), то при включенной технологии Storage DRS (выравнивание нагрузки на хранилища), вы можете повредить виртуальный диск вашей ВМ, что приведет к его полной утере.
In clusters where Storage vMotion is used extensively or where Storage DRS is enabled, VMware recommends that you do not deploy vSphere HA. vSphere HA might respond to a host failure by restarting a virtual machine on a host with an ESXi version different from the one on which the virtual machine was running before the failure. A problem can occur if, at the time of failure, the virtual machine was involved in a Storage vMotion action on an ESXi 5.0 host, and vSphere HA restarts the virtual machine on a host with a version prior to ESXi 5.0. While the virtual machine might power on, any subsequent attempts at snapshot operations could corrupt the vdisk state and leave the virtual machine unusable.
По русски это выглядит так:
Если вы широко используете Storage vMotion или у вас включен Storage DRS, то лучше не использовать кластер VMware HA. Так как при падении хост-сервера ESXi, HA может перезапустить его виртуальные машины на хостах ESXi с другой версией (а точнее, с версией ниже 5.0, например, 4.1). А в это время хост ESXi 5.0 начнет Storage vMotion, соответственно, во время накатывания последовательности различий vmdk (см. как работает Storage vMotion) машина возьмет и запустится - и это приведет к порче диска vmdk.
Надо отметить, что такая ситуация, когда у вас в кластере используется только ESXi 5.0 и выше - произойти не может. Для таких ситуаций HA и Storage vMotion полностью совместимы.
Скоро нам придется участвовать в интереснейшем проекте - построение "растянутого" кластера VMware vSphere 5 на базе технологии и оборудования EMC VPLEX Metro с поддержкой возможностей VMware HA и vMotion для отказоустойчивости и распределения нагрузки между географически распределенными ЦОД.
Вообще говоря, решение EMC VPLEX весьма новое и анонсировано было только в прошлом году, но сейчас для нашего заказчика уже едут модули VPLEX Metro и мы будем строить active-active конфигурацию ЦОД (расстояние небольшое - где-то 3-5 км) для виртуальных машин.
Для начала EMC VPLEX - это решение для виртуализации сети хранения данных SAN, которое позволяет объединить ресурсы различных дисковых массивов различных производителей в единый логический пул на уровне датацентра. Это позволяет гибко подходить к распределению дискового пространства и осуществлять централизованный мониторинг и контроль дисковых ресурсов. Эта технология называется EMC VPLEX Local:
С физической точки зрения EMC VPLEX Local представляет собой набор VPLEX-директоров (кластер), работающих в режиме отказоустойчивости и балансировки нагрузки, которые представляют собой промежуточный слой между SAN предприятия и дисковыми массивами в рамках одного ЦОД:
В этом подходе есть очень много преимуществ (например, mirroring томов двух массивов на случай отказа одного из них), но мы на них останавливаться не будем, поскольку нам гораздо более интересна технология EMC VPLEX Metro, которая позволяет объединить дисковые ресурсы двух географически разделенных площадок в единый пул хранения (обоим площадкам виден один логический том), который обладает свойством катастрофоустойчивости (и внутри него на уровне HA - отказоустойчивости), поскольку данные физически хранятся и синхронизируются на обоих площадках. В плане VMware vSphere это выглядит так:
То есть для хост-серверов VMware ESXi, расположенных на двух площадках есть одно виртуальное хранилище (Datastore), т.е. тот самый Virtualized LUN, на котором они видят виртуальные машины, исполняющиеся на разных площадках (т.е. режим active-active - разные сервисы на разных площадках но на одном хранилище). Хосты ESXi видят VPLEX-директоры как таргеты, а сами VPLEX-директоры являются инициаторами по отношению к дисковым массивам.
Все это обеспечивается технологией EMC AccessAnywhere, которая позволяет работать хостам в режиме read/write на массивы обоих узлов, тома которых входят в общий пул виртуальных LUN.
Надо сказать, что технология EMC VPLEX Metro поддерживается на расстояниях между ЦОД в диапазоне до 100-150 км (и несколько более), где возникают задержки (latency) до 5 мс (это связано с тем, что RTT-время пакета в канале нужно умножить на два для FC-кадра, именно два пакета необходимо, чтобы донести операцию записи). Но и 150 км - это вовсе немало.
До появления VMware vSphere 5 существовали некоторые варианты конфигураций для инфраструктуры виртуализации с использованием общих томов обоих площадок (с поддержкой vMotion), но растянутые HA-кластеры не поддерживались.
С выходом vSphere 5 появилась технология vSphere Metro Storage Cluster (vMSC), поддерживаемая на сегодняшний день только для решения EMC VPLEX, но поддерживаемая полностью согласно HCL в плане технологий HA и vMotion:
Обратите внимание на компонент посередине - это виртуальная машина VPLEX Witness, которая представляет собой "свидетеля", наблюдающего за обоими площадками (сам он расположен на третьей площадке - то есть ни на одном из двух ЦОД, чтобы его не затронула авария ни на одном из ЦОД), который может отличить падения линка по сети SAN и LAN между ЦОД (экскаватор разрезал провода) от падения одного из ЦОД (например, попадание ракеты) за счет мониторинга площадок по IP-соединению. В зависимости от этих обстоятельств персонал организации может предпринять те или иные действия, либо они могут быть выполнены автоматически по определенным правилам.
Теперь если у нас выходит из строя основной сайт A, то механизм VMware HA перезагружает его ВМ на сайте B, обслуживая их ввод-вывод уже с этой площадки, где находится выжившая копия виртуального хранилища. То же самое у нас происходит и при массовом отказе хост-серверов ESXi на основной площадке (например, дематериализация блейд-корзины) - виртуальные машины перезапускаются на хостах растянутого кластера сайта B.
Абсолютно аналогична и ситуация с отказами на стороне сайта B, где тоже есть активные нагрузки - его машины передут на сайт A. Когда сайт восстановится (в обоих случаях с отказом и для A, и для B) - виртуальный том будет синхронизирован на обоих площадках (т.е. Failback полностью поддерживается). Все остальные возможные ситуации отказов рассмотрены тут.
Если откажет только сеть управления для хостов ESXi на одной площадке - то умный VMware HA оставит её виртуальные машины запущенными, поскольку есть механизм для обмена хартбитами через Datastore (см. тут).
Что касается VMware vMotion, DRS и Storage vMotion - они также поддерживаются при использовании решения EMC VPLEX Metro. Это позволяет переносить нагрузки виртуальных машин (как вычислительную, так и хранилище - vmdk-диски) между ЦОД без простоя сервисов. Это открывает возможности не только для катастрофоустойчивости, но и для таких стратегий, как follow the sun и follow the moon (но 100 км для них мало, специально для них сделана технология EMC VPLEX Geo - там уже 2000 км и 50 мс latency).
Самое интересное, что скоро приедет этот самый VPLEX на обе площадки (где уже есть DWDM-канал и единый SAN) - поэтому мы все будем реально настраивать, что, безусловно, круто. Так что ждите чего-нибудь про это дело интересного.
Таги: VMware, HA, Metro, EMC, Storage, vMotion, DRS, VPLEX
Компания VMware в июле 2011 года объявила о доступности новых версий целой линейки своих продуктов для облачных вычислений, среди которых находится самая технологически зрелая на сегодняшний день платформа виртуализации VMware vSphere 5.0.
Мы уже рассказывали об основном наборе новых возможностей VMware vSphere 5.0 неофициально, но сейчас ограничения на распространение информации сняты, и мы можем вполне официально рассказать о том, что нового для пользователей дает vSphere 5.
На сайте myvirtualcloud.net появилась отличная статья, в которой описываются подходы к отказоустойчивости и восстановлению после сбоев (Disaster Recovery) в инфраструктуре виртуальных ПК VMware View 4.5.
Рассматриваются конфигурации Active-Active и Active-Passive для сайтов, где развернуто решение VMware View. Статья обязательна к ознакомлению тем, кто еще не задумывался над этим важным вопросом.
Технология VMware Fault Tolerance позволяет защитить виртуальные машины с помощью кластеров непрерывной доступности, позволяющих в случае отказа хоста с основной виртуальной машиной мгновенно переключиться на ее "теневую" работющую копию на другом сервере ESX. Однако эта технология имеет существенные ограничения, приведенные ниже. Таги: VMware, Fault Tolerance, FT, vSphere, ESX, DRS, DPM, HA, Enterprise
Как вы знаете, в VMware vSphere 4.1 механизм VMware DRS, осуществляющий балансировку нагрузки на хост-серверы ESX, теперь интегрирован с технологией непрерывной доступности VMware Faut Tolerance.
То есть DRS автоматически распределяет по хост-серверам и FT-машины, однако тут есть небольшой нюанс. В соответствии с рекомендациями Fault Tolerance, число таких машин на хосте должно быть не больше 4-х в целях оптимального быстродействия. Если вы попробуете смигрировать пятую виртуальную машину с включенной технологией FT на хост, вы получите вот такое сообщение:
Host already has the recommended number of 4 Fault Tolerance VMs running on it
То есть DRS не смигрирует и не сделает Initial Placement для FT-машин на хосты VMware ESX, где уже работают 4 таких ВМ. Однако, есть возможность увеличить это количество. Для этого необходимо в расширенных настройках (Advanced Settings) кластера VMware HA/DRS добавить параметр:
das.maxftvmsperhost
со значением, например, 6. Если вы поставите значение 0, то VMware DRS будет полностью игнорировать данное требование к числу FT-машин на хост.
Большинству пользователей виртуальной инфраструктуры VMware vSphere известны такие параметры как Limit, Reservation и Shares для пулов ресурсов (Resource Pool) в пределах кластеров VMware DRS и отельных хостов ESX. Именно этими тремя параметрами определяется потребление виртуальными машинами оперативной памяти и процессорных ресурсов хоста VMware ESX. Таги: VMware, vSphere, Resources, ESX, HA, DRS
Андрей Вахитов (vmind.ru) в своем блоге разместил просочившуюся информацию о новой функциональности готовящегося к выпуску релиза платформы виртуализации VMware vSphere 4.1, включая ESX 4.1 и vCenter 4.1.
Приблизительный список основных новых возможностей VMware vSphere 4.1:
Поддержка развертывания тонкого гипервизора VMware ESXi по PXE.
Контроль обмена трафиком с системой хранения Storage I/O Control в стиле QoS.
Network I/O Traffic Management - более гибкое регулирование полосы пропускания сетевого взаимодействия виртуальных машин (в том числе сети VMotion, Fault Tolerance).
VMware HA Healthcheck Status - автоматическая проверка работоспособности VMware HA, при этом в случае отклонения настроек кластера от требуемых выдается Alarm в VMware vCenter.
Fault Tolerance (FT) Enhancements - теперь FT полностью интегрирован с VMware DRS, работает в кластерах EVC, а первичные и вторичные виртуальные машины корректно балансируются DRS. Кроме того, VMware FT может теперь работать без VMware HA.
vCenter Converter Hyper-V Import - можно импортировать виртуальную машину на ESX с сервера Hyper-V
DRS Virtual Machine Host Affinity Rules - возможность запрещать некоторые хосты к размещению на них ВМ. Пригодится для соблюдения лицензионной политики.
Memory Compression - новый уровень абстракции оперативной памяти ВМ. Быстрее чем засвопированная на диск память, но медленнее, чем физическая.
vMotion Enhancements - теперь VMotion работает быстрее (до 8 раз), и увеличено число одновременных миграций ВМ на хосте (с 4 до 8).
8GB Fibre Channel Support
ESXi Active Directory Integration - теперь ESXi можно загнать в AD.
Configuring USB Device Passthrough from an ESX/ESXi Host to a Virtual Machine - поддержка USB-устройств на хосте ESX / ESXi, пробрасываемых к виртуальной машине.
User-configurable Number of Virtual CPUs per Virtual Socket - по-сути, многоядерные (не путать с многопроцессорными) виртуальные машины. Несколько виртуальных ядер в одном виртуальном vCPU.
Как вы знаете, недавно компания Microsoft выпустила не только вторую версию бесплатного гипервизора Hyper-V 2.0 (R2) который встроен в ОС Windows 2008 Server R2, но и вслед за этим зарелизила продукт System Center Virtual Machine Manager 2008 R2 (SC VMM 2008 R2), предназначенный для управления виртуальной инфраструктурой Microsoft. Как и к любому продукту Microsoft, к SC VMM 2008 R2 прилагается прицеп с документацией, ссылки на которую приведены ниже:
Великий Duncanподнял очередную болезненную тему для VMware vSphere. У них (VMware) есть заказчик, у которого 5 хостов VMware ESX в кластере VMware DRS. Вечером, когда нагрузка на хосты ESX спадает, 4 из них переходят в standby режим (делает это механизм Distributed Power Management), остается один хост на котором сервер vCenter, работающий в виртуальной машине.
Если этот единственный хост VMware ESX погибает - вся инфраструктура остается выключенной, поскольку некому вывести остальные хосты из standby и перезапустить vCenter. Все это потому, что Admission Control в настройках кластера VMware HA выключен и отказоустойчивость кластера не гарантирована. То есть это не баг - а фича. Но...
Раз уж речь пошла о Maintenance Mode, то расскажем как выйти из DRS Maintenance Mode хоста ESX, когда его не получается вывести оттуда через vSphere Client. Причины могут быть различны, однако такое встречается время от времени. Что нужно сделать, чтобы убрать Maintenance Mode на непокорном хосте VMware ESX:
1. Перезапустить Management Agents на ESX, используя KB1003490, командой # service mgmt-vmware restart и попробовать Exit Maintenance Mode из vSphere Client еще раз.
2. Если не помогло, выполнить команду:
vimsh -n -e /hostsvc/maintenance_mode_exit
из сервисной консоли для выхода из Maintenance Mode, ну а команда...