Vmware srm что это
blog.vmpress.org
Страницы
вторник, 17 января 2012 г.
Катастрофоустойчивая инфраструктура на базе VMware SRM (Часть I)
Сегодня я планирую начать серию статей, посвященных продукту VMware vCenter Site Recovery Manager (SRM). VMware SRM является основой для организации катастрофоустойчивых решений и предоставляет возможность автоматизации процедуры восстановления виртуальной инфраструктуры при авариях, повлекших за собой недоступность серверов, систем хранения данных (СХД) или целого сайта, а также позволяет проводить плановую миграцию инфраструктуры на резервный сайт и тестировать корректность работы резервной инфраструктуры.
В этих статьях я хотел бы рассказать об актуальной 5-й версии продукта, а также описать процедуру его установки и настройки и работу в связке с СХД NetApp.
Но если вы думаете, что я начну первую статью с хвалебных од в честь SRM или с примера конфигурирования СХД, то спешу Вас разочаровать. В первой части я хотел бы рассказать о некоторых базовых вещах, без которых будет сложно описать все преимущества, недостатки и особенности работы SRM.
При работе любой системы всегда существует риск, что-то пойдет не так, и система перестанет выполнять возложенные на нее функции, т.е. произойдет сбой. В некоторых случаях сбой может быть настолько разрушителен по своему воздействию, что даже отказоустойчивая система выйдет из строя. Вот это и будет катастрофой. И чтобы ей противостоять нам, как ни странно, следует спроектировать и развернуть катастрофоустойчивое решение.
Конечно, можно положиться на русский авось. А можно оценить риски, величину потерь в случае возникновения того или иного сбоя и сравнить со стоимостью внедрения катастрофоустойчивого решения, написать технико-экономическое обоснование, подсчитать ROI, TCO. и решиться на внедрение SRM.
С другой стороны следует понимать, что SRM не является волшебной палочкой, его покупка совершенно не означает, что Ваша инфраструктура автоматически станет защищенной от всевозможных катастроф. Установка, настройка и тестирование SRM составляет лишь малую часть работ в общем проекте по созданию надежной катастрофоустойчивой инфраструктуры, потому что еще требуется провести аудит существующей инфраструктуры, оценить возможные риски, спланировать архитектуру будущего решения, написать пару десятков различных документов (планов, регламентов, инструкций и пр.), наконец, построить резервный ЦОД (если его нет).
Помимо причины возникновения, сбои можно классифицировать по тому, приводят ли они к потере данных или нет.
Понятно, что наиболее болезненными для организации являются сбои, приводящие к потере данных, так как зачастую эти данные могут стоить гораздо дороже, чем оборудование, используемое для их хранения и обработки. Каким образом от этого можно защититься?
Во-первых, многие приложения и службы имеют встроенные механизмы защиты данных. Так, например, файловые серверы на базе Windows могут реплицировать файлы и папки, используя протокол DFS, контроллеры домена реплицуруют объекты службы каталога, для баз данных Exchange или SQL можно настроить зеркалирование.
Резервное копирование
Как известно администраторы делятся на тех, кто еще не делает резервные копии, и на тех, кто уже делает.
Этот недостаток присущ для большинства систем резервного копирования, хотя существуют и исключения, компания Veeam предоставляет продукт для резервного копирования Veeam Backup & Replication, который позволяет монтировать резервные копии в виде NFS хранилища, и напрямую запускать с них ВМ, а после переносить их на основное хранилище с помощью Storage vMotion.
RPO (Recovery Point Objective или точка восстановления) характеризуется временем, прошедшим с момента последнего резервного копирования данных, и также тем объемом данных, которые были изменены, и соответственно, могут быть потеряны из-за сбоя.
Таким образом, чем чаще наша система выполняет резервное копирование, тем меньше показатель RPO, большинство СРК позволяют создавать резервные копии хоть каждые 15 минут. Проблемы начинаются в тех случаях, когда для особо критичных сервисов этого может быть недостаточно.
Отдельным пунктом можно выделить мгновенные снимки (snapshots), поддерживаемые большинством СХД, которые хотя и не в полной мере являются резервными копиями, но также позволяют сохранить копию данных на определенный момент времени. Мгновенные снимки могут создаваться администратором вручную или по расписанию, а также использоваться для создания полноценных резервных копий или репликации данных.
Кластеризация СХД
Другой метод защиты данных основан на кластеризации СХД. У разных вендоров технологии обеспечивающие кластеризацию могут называться по разному, у кого-то это синхронизация, у кого-то зеркалирование, но идея одна. Несколько узлов СХД объединяются, и представляются для всех потребителей дисковых ресурсов единым логическим хранилищем (как правило, узлов два, но в некоторых решения их может быть и больше). Внутри хранилища обеспечивается избыточность хранения LUN’ов, таким образом, что отказ одного из узлов не приводит к потере доступа к LUN’у с данными для клиента.
Даже у VMware есть собственный продукт (vSphere Storage Appliance), позволяющий объединить локальные хранилища серверов виртуализации, однако у него есть ряд серьезных ограничений.
Бороться с этим можно различными способами: использовать несколько независимых маршрутов, или организовать третий ЦОД с узлом-арбитром, который будет доступен для узлов кластера по независимым каналам связи и позволит определить, какому из узлов СХД должен принадлежать тот или иной LUN.
Еще один негативный момент использование кластеризации заключается в том, что данные защищаются на уровне физического оборудования, но не на логическом. Любые изменения внутри LUN’а мгновенно синхронизируются, если какой-либо файл или виртуальная машина будет удалена, то это мгновенно отразится на всех копиях. Для того, чтобы иметь возможность «отменить» сделанные изменения следует использовать резервное копирование, мгновенные снимки или асинхронную репликацию.
Репликация
Репликация позволяет настроить копирование по заданному расписанию данных с основного хранилища на резервное. При необходимости, администратор может приостановить репликацию и переключить клиентов на резервное хранилище. Репликация между СХД выполняется на блочном уровне и передает только измененные блоки данных, а не все файлы или LUN’ы целиком.
Функционал репликации есть у большинства вендоров СХД, если не брать в расчет Home Office NAS’ы, где репликация выполняется с помощью какого-нибудь rsync, то, например, в СХД entry уровня HP StorageWorks P2000 G3 появилась такая возможность.
К недостаткам синхронной репликации можно отнести высокие требования к каналам связи (фактически такие же как у кластеризованных хранилищ).
Кроме того, при использовании синхронной репликации, у администратора нет возможности «отменить» изменения, сделанные на исходном хранилище (если какие-либо данные удаляются на исходном хранилище, то измененные блоки сразу же копируются, и данные удаляются с резервного хранилища). Для восстановления данных в этом случае потребуется использовать резервные копии или мгновенные снимки.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
VMware Site Recovery Manager
 | |
| Разработчики: | VMware |
|---|---|
| Операционная система: | кроссплатформенная |
| Тип ПО: | ПО для аварийного восстановления |
| Веб-сайт | https://www.vmware.com/ |
Содержание
Возможности VMware Site Recovery Manager
Архитектура VMware Site Recovery Manager
Отказоустойчивая система состоит из основного и резервного сайтов (ЦОДов). Оба cайта имеют типовую виртуальную IT-инфраструктуру VMware: виртуальные машины запущены на серверах ESX централизованно управляемых сервером vCenter. Работа SRM основывается на репликации блоков данных уровня дисковых массивов. Репликация обеспечивается средствами ПО производителей систем хранения. Для интеграции с дисковыми массивами SRM использует программные адаптеры репликации (SRA, Storage Replication Adapter), которые поставляются производителями дисковых массивов. Используя адаптер репликации, SRM проверяет наличие репликации LUN, на которых хранятся файлы защищаемых виртуальных машин, а также инициирует выполнение различных команд дисковыми массивами, таких как создание снэпшотов, переключение режимов работы и т.п. Администрирование производится с автоматизированного рабочего места администратора с установленным VMware vSphere Client. В каждый сайт добавляется сервер Site Recovery Manager, управляющий процессами аварийного восстановления и реализующий функционал создания, тестирования и выполнения планов восстановления. Кроме того, сервер SRM интегрируется с серверами vCenter основного и резервного сайта, что обеспечивает централизованное управление процессами аварийного восстановления, мониторинг их состояния, а также оповещение операторов в случае возникновения аварийных ситуаций. [Источник 3]
Варианты восстановления сайта
Плановая миграция. Предполагает доступность и полную функциональность основного и резервного сайтов. Исключает потерю данных, это запланированная операция, проходит в рабочем порядке, без аварийных ситуаций:
Аварийное восстановление (Disaster recovery). Рассчитано на внезапное падение основного сайта, осуществляется переключение на резервный сайт, незапланированная операция:
Требования к конфигурации сайтов для работы Site Recovery Manager
Подходы к защите виртуальных машин
Различные режимы репликации
Site Recovery Manager с репликацией на уровне массива (Array-based replication)
Данный подход предполагает репликацию данных между сайтами на уровне массивов (СХД), посредством заложенных в них механизмов репликации. Интеграция SRM с массивами осуществляется посредством storage replication adapters (SRAs), это программные компоненты, которые должны разрабатываться производителями массивов. Для поддержки Array-based replication на SRM-server каждого сайта должны быть установлены SRA для каждого подключенного к нему массива.
Site Recovery Manager с использованием vSphere Replication
Site Recovery Manager может использовать vSphere Replication (встроенная и бесплатная технология пакета VMware vSphere) для репликации данных на уровне виртуальных машин между сайтами. Работа vSphere Replication не зависит от типа и модели хранилища, не требует интеграции с массивом (разработки SRA) и поддерживает любое хранилище совместимое с vSphere. vSphere Replication позволяет создавать цепочку снэпшотов для реплицируемых виртуальных машин на резервном сайте – множество реплик защищаемых машин на разные моменты времени. Таким образом, появляется возможность выбора оптимального состояния виртуальной машины для восстановления среди множества снапшотов реплики. [Источник 5]
Смешанный режим репликации
Site Recovery Manager поддерживает смешанный режим работы в котором совместно используются оба механизма репликации: Array-based replication и vSphere Replication. Данный режим требует развертывания и настройки этих технологий на обоих сайтах. Настройка разных механизмов репликации для одних и тех же виртуальных машин не поддерживается. Однако, Site Recovery Manager позволяет включать в один план задачи по восстановлению с разными механизмами репликации, но для разных виртуальных машин.
Disaster Recovery Software Site Recovery Manager
Automate orchestration of failover and failback to minimize downtime and improve availability with VMware Site Recovery Manager.
Enable Application Availability and Mobility for Private and Public Cloud with Site Recovery Manager
Simple, Policy-Based Management
Use policy-driven automation to protect thousands of virtual machines easily using centralized recovery plans managed from the vSphere Web Client.
Compatible With Any Storage
Experience flexibility and choice through native integration with vSphere Replication, Virtual Volumes (vVols), and array-based replication solutions from all major VMware storage partners.
Hybrid Cloud Ready
Get end-to-end disaster recovery protection as-a-service with VMware Site Recovery for VMC on AWS. This quick-to-deploy solution leverages existing investments and prepares you for hybrid cloud.
Multi-cloud Ready
With SRM for Hyperscalers, leverage Azure and Google Cloud as DR failover targets for on-premises and cloud workloads within the same hyperscaler.
What’s New with Site Recovery Manager?
SRM on Azure VMware Solution
Product your on-premises workloads to Azure VMware Solution, as well as workloads across regions to support your cloud adoption strategy and drive data resilience.
SRM on Google Cloud VMware Engine
Seamlessly recover workloads using Google Cloud VMware Engine as a failover target or source site, and achieve RPOs as low as 5 minutes.
Continuous Data Protection
With stretched storage expanded support, you can instantly migrate VMs in between sites with zero downtime.
Related Resources
Learn more about Site Recovery Manager
See what’s new in the industry-leading solution that enables application availability and mobility across private cloud environments.
Rapid Recovery and Minimal Disruption with Site Recovery Manager
Learn why Shriram Value, a financial services conglomerate, choose SRM for their disaster recovery and business continuity planning.
Test Drive Site Recovery Manager
Get hands-on experience planning a data center migration and executing a disaster recovery plan. It’s free and there is nothing to install.
Related Products
VMware Site Recovery
On-demand disaster recovery as a service (DRaaS)
VMware Cloud Disaster Recovery
On-demand disaster recovery with cloud economics
Purchasing Options
VMware Site Recovery Manager is available in two editions: Standard and Enterprise.
Both standalone editions are licensed per protected virtual machine and sold in packs of 25 virtual machines.
Licensing
Standard
Enterprise
Max. protected virtual machines
Features
Standard
Enterprise
Frequently Asked Questions
Site Recovery Manager (SRM) is the industry-leading disaster recovery (DR) management solution, designed to minimize downtime in case of a disaster. It provides policy-based management, automated orchestration, and non-disruptive testing of centralized recovery plans. It is designed for virtual machines and scalable to manage all applications in a vSphere environment.
SRM automates and orchestrates failover and failback, ensuring minimal downtime in a disaster. Built-in non-disruptive testing ensures your recovery time objectives are met.
Overall, SRM simplifies management through automation, ensures fast and highly predictable recovery times, and minimizes the total cost of ownership. SRM addresses multiple use cases, such as disaster recovery, disaster avoidance, planned data center migrations, site-level load balancing or even application maintenance testing.
For maximum flexibility and choice, Site Recovery Manager integrates with vSphere through VMware Server and an underlying replication technology. It can integrate natively with vSphere Replication, vSphere Virtual Volumes (vVols) integrated storage arrays, or with a broad range of storage array–based replication solutions from leading storage vendors through storage replication adapters
SRM guides users through the process of configuring recovery plans. At the time of failover or testing, SRM automates the execution of the recovery plan. SRM allows teams to perform frequent non-disruptive testing, even during business hours, to ensure predictable recovery objectives. It reduces recovery time to minutes with automated orchestration workflows. And it achieves zero-downtime application mobility, orchestrating live migration of virtual machines at scale across sites.
Site Recovery Manager requires the use of either vSphere Replication, vSphere Virtual Volumes (vVols) integrated storage arrays, array-based replication, storage-based replication for iSCSI, FibreChannel, or NFS storage arrays. For storage-based replication, VMware works with storage partners to ensure that customers can deploy SRM with their choice of storage and storage replication platform. SRM works with a wide variety of replication software through storage replication adapter (SRA) plug-ins developed and certified by storage vendors for use with SRM. When using vVols integrated storage arrays, the VASA provider replaces the SRA. For a current list of SRAs and supported storage view the Storage Partner Compatibility Matrix. View the SRM for vVols Compatibility Matrix.
VMware Site Recovery for VMware Cloud on AWS is a separate service, but it is built on top of Site Recovery Manager and vSphere Replication. Site Recovery provides on-demand disaster recovery as a service to protect your workloads both on-premises and on VMware Cloud on AWS. The service automates workload recovery in a DR event between on-premises data centers and VMware Cloud on AWS, as well as between different instances of VMware Cloud on AWS. It replicates workloads to VMware Cloud on AWS, allowing you to spin them up whenever you need them.
Решения VMware для репликации и аварийного восстановления: vSphere Replication и Site Recovery Manager (SRM)
Site Recovery Manager (SRM)
VMware Site Recovery Manager (SRM) это решение для обеспечения непрерывности бизнеса и аварийного восстановления, предназначенное для планирования, тестирования и восстановления ВМ (виртуальных машин) с защищаемого (основного) сайта на (резервный) сайт восстановления.
SRM предлагает 3 подхода к защите (репликации) ВМ:
• Группы хранилищ (datastore groups). Защита ВМ в группах хранилищ посредством сторонних механизмов репликации (3-я сторона). Используется репликация на уровне массива (Array-based replication).
• Отдельные ВМ. Защита отдельных ВМ на уровне хостов. SRM используется в комбинации с технологией VMware vSphere Replication.
• Политики хранения (storage policies). Защита ВМ на основе специальных политик хранения. Используется репликация на уровне массива (Array-based replication).
SRM обеспечивает 2 варианта восстановления сайта (датацентра):
• Плановая миграция. Предполагает доступность и полную функциональность основного и резервного сайтов. Исключает потерю данных, это запланированная операция, проходит в рабочем порядке, без аварийных ситуаций.
• Аварийное восстановление (Disaster recovery). Рассчитано на внезапное падение основного сайта, осуществляется переключение на резервный сайт, незапланированная операция.
SRM осуществляет оркестровку процессов восстановления дата-центра и механизмов репликации, что обеспечивает минимизацию потерь данных и времени восстановления:
• SRM обеспечивает гашение ВМ на основном сайте и синхронизацию данных между сайтами в случае работоспособности основного сайта.
• SRM запускает на резервном сайте реплицированные ВМ в порядке определяемом планом восстановления.
SRM дает возможность тестирования планов восстановления. Для проведения тестов используются временные копии реплицированных данных, что позволяет исключить влияние на основные процессы обоих сайтов.
SRM обеспечивает 2 варианта развёртывания в контексте взаимоотношений между сайтами:
• Базовый (однонаправленный) вариант – предполагает возможность миграции сервисов основного дата-центра (защищаемый сайт) на резервную площадку (сайт восстановления).
• Двунаправленный вариант – обеспечивает защиту ВМ в обоих направлениях. Каждый сайт в образованной паре является основным, выполняя при этом функцию резервного для своего соседа.
Требования к конфигурации сайтов для работы SRM:
• Идентичность и совместимость версий SRM, vCenter Server, vSphere Replication на обоих сайтах.
• В случае репликации на уровне массива (Array-based replication), выбранная технология репликации должна поддерживаться на обоих сайтах, массивы образовывать пару.
• Инфраструктура резервного сайта (хосты, сети, хранилища) должна соответствовать ВМ и поддерживать нагрузки основного сайта. Резервный сайт может быть нагружен (сверх нормы) непродуктивными или некритичными ВМ, которые могут быть остановлены в случае восстановления основного сайта.
• Сайты должны быть соединены через надежную IP-сеть, обеспечивающую необходимую пропускную способность.
• Резервный сайт должен иметь подключение к публичным и частным сетям, доступным основному сайту.
Для работы технологии требуется установка SRM-серверов (Site Recovery Manager Server) на основном и резервном сайтах. Для небольших датацентров допустима установка SRM-сервера на одну систему с сервером vCenter, в частности установка их на одной ВМ. Для крупных инфраструктур из соображений нагруженности и доступности целесообразна установка SRM-сервера на отдельной системе (на отдельной ВМ).
Много-сайтовые конфигурации SRM
Стандартная конфигурация, которая рассматривалась выше, включала 2 сайта: основной и резервный. Оба сайта имеют по серверу vCenter, которые связываются посредством SRM-серверов, устанавливаемых на обоих сайтах. Таким образом, ВМ принадлежащие vCenter основного сайта могут быть восстановлены на vCenter резервного сайта.
На случай если дата-центр имеет более 2х площадок SRM поддерживает различные много-сайтовые конфигурации:
• Общий сайт восстановления — shared recovery site (many-to-one, N:1) – множество защищаемых сайтов могут реплицировать и восстанавливать свои ВМ на один общий резервный сайт;
• Общий основной сайт — shared protected site (one-to-many, 1:N) – основной сайт имеет несколько резервных площадок;
• Многие ко многим — many-to-many (N:N).
Сущности SRM (SRM-серверы) на основном и резервном сайте должны образовывать пару, им присваиваются одинаковые идентификаторы (extension ID). Поэтому, на общем сайте должно быть поднято количество сущностей SRM равное количеству его сайтов партнеров. Например, если общий сайт восстановления обслуживает 5 защищаемых сайтов, то на нем должно быть развернуто 5 SRM-серверов, образующих пары с защищаемыми сайтами. SRM-серверы общего сайта должны быть установлены на разных ВМ (хост-машинах) и иметь уникальные идентификаторы. При этом множество SRM сущностей общего сайта взаимодействуют с одним сервером vCenter, управляющим данным сайтом.
Нельзя устанавливать несколько SRM-серверов на одну хост-машину (ВМ). Каждый SRM-сервер должен иметь собственную БД. Один сайт восстановления может иметь не более 10 защищаемых сайтов.
SRM с репликацией на уровне массива (Array-based replication)
Данный подход предполагает репликацию данных между сайтами на уровне массивов (СХД), посредством заложенных в них механизмов репликации. Интеграция SRM с массивами осуществляется посредством storage replication adapters (SRAs), это программные компоненты, которые должны разрабатываться производителями массивов. Для поддержки Array-based replication на SRM-server каждого сайта должны быть установлены SRA для каждого подключенного к нему массива.
SRM с использованием vSphere Replication
SRM может использовать vSphere Replication (встроенная и бесплатная технология пакета VMware vSphere) для репликации данных на уровне ВМ между сайтами. Работа vSphere Replication не зависит от типа и модели хранилища, не требует интеграции с массивом (разработки SRA) и поддерживает любое хранилище совместимое с vSphere.
vSphere Replication позволяет создавать цепочку снапшотов для реплицируемых ВМ на резервном сайте – множество реплик защищаемых машин на разные моменты времени. Таким образом, появляется возможность выбора оптимального состояния ВМ для восстановления среди множества снапшотов реплики.
Смешанный режим репликации
SRM поддерживает смешанный режим работы в котором совместно используются оба механизма репликации: Array-based replication и vSphere Replication. Данный режим требует развертывания и настройки этих технологий на обоих сайтах. Настройка разных механизмов репликации для одних и тех же ВМ не поддерживается. Однако, SRM позволяет включать в один план задачи по восстановлению с разными механизмами репликации, но для разных ВМ.
vSphere Replication
vSphere Replication это расширение для vCenter, которое обеспечивает репликацию и восстановление ВМ на уровне гипервизора, а также обеспечивает мониторинг и управление данными процессами. Данная технология является альтернативой репликации на уровне массива. Решение поддерживает следующие варианты репликации ВМ сайта:
• между сайтом источника и целевым сайтом (site-to-site);
• между кластерами внутри одного сайта;
• между множеством сайтов источников и общим целевым сайтом (many-to-one).
vSphere Replication не зависит от типа массива и поддерживает любое хранилище совместимое с vSphere. Решение входит во все редакции vSphere (за исключением самой простой и бесполезной) и не требует покупки лицензий.
Репликация осуществляется путем передачи измененных блоков между сайтами или кластерами источника и цели. Это подразумевает первоначальную полную синхронизацию ВМ источника и её реплики. Настройка задания репликации позволяет установить RPO, а также активировать возможность сохранения множества промежуточных временнЫх состояний реплики (MPIT — multiple points in time) – аналог снапшотов ВМ.
Существует возможность мониторинга и управления состоянием репликации, получения информации о входящих и исходящих репликациях, состоянии сайтов, результатах репликации и ошибках.
Процесс восстановления ВМ из реплики не автоматизирован и требует ручного вмешательства. В частности, он требует вручную выбрать синхронизацию состояния ВМ с сайтом источника или восстановить последнее состояние из реплики. Восстановленная ВМ не имеет сетевых подключений дабы не вызвать потенциальных конфликтов, что требует ручного подключения ВМ к нужным виртуальным сетям дата-центра. MPIT обеспечивает восстановление реплицированной ВМ с заданной цепочкой снапшотов, что дает возможность выбрать нужное состояние восстановленной ВМ.
vSphere Replication appliance – основная сущность решения, которая регистрируется и подключается как расширение к серверу vCenter. vCenter допускает установку и подключение только одного vSphere Replication appliance (VR appliance). VR appliance включает встроенный vSphere Replication server, который управляет всеми процессами репликации. Для балансировки нагрузки поддерживается развертывание дополнительных vSphere Replication server, которые подключаются к основному VR appliance данного сайта (vCenter-а) и по сути сами являются виртуальными эплаенсами.
Пример конфигурации репликации site-to-site:
Пример конфигурации репликации между кластерами внутри одного сайта, при этом используются 2 VR сервера для балансировки нагрузки (это не обязательно, можно было обойтись одним VR appliance):
Пример конфигурации репликации many-to-one: