Vmware SRM (site recovery manager) + vmware replication. Так же можно использовать бэкапное ПО типа veeam backup & replication . Что дешевле сложно сказать, считайте. Можно хоть скриптом загнать вообще бесплатно. Но если хочется красоты и удобства то 1 вариант.
Так же можно настроить репликацию на уровне системы хранения (если поддерживается), к примеру 2 одинаковые хранилки на сайте A и сайте B.
PS. Используйте поиск по форуму, ЕМНИП кто то уже спрашивал про похожую тему..
Так же можно настроить репликацию на уровне системы хранения (если поддерживается), к примеру 2 одинаковые хранилки на сайте A и сайте B.
PS. Используйте поиск по форуму, ЕМНИП кто то уже спрашивал про похожую тему..
Oleg75
Случайный прохожий
Могу спросить у коллег но нужна следующая дополнительная информация:
Количество ресурсов, выделенных на каждую ВМ в VMware, выраженное в GHz процессора, GB RAM, GB хранилища (отдельно SATA, SAS, SSD);
Частота бэкапов (RPO) – раз в определенный период (раз в 3 дня. В неделю, в месяц и т.п.) или репликация в реальном времени;
Максимальное время на поднятие резервной системы – RTO;
посчитают
Xeno
Случайный прохожий
Возможны две основных стратегии использования распределенных ЦОД – «активный/активный», когда инфраструктурные приложения и сервисы распределены между площадками, и пользователи работают с ближайшим ЦОД, либо «активный/пассивный», при которой приложения централизованы, и пользователи работают с основным узлом. В случае отказа системы, нагрузка автоматически переключается на резервный ЦОД. Возможность применения той или иной стратегии зависит от приложения.
Нередко в основе устойчивого к катастрофам ЦОД – территориально-распределенная кластерная конфигурация серверов с подключением к общей сети хранения данных (SAN). Узлы разнесенного кластера размещаются на основной и резервной площадках, образуя единую систему. Это обеспечивает непрерывную доступность сервисов даже в случае потери основного ЦОД. С помощью кластеризации можно обеспечить автоматическое переключение нагрузки между площадками распределенного ЦОД в случае аварии. Возможна и экономичная модификация решения, при которой удаленный ЦОД функционирует в резервном режиме и в случае отказа основного ЦОД поддерживает ограниченный набор сервисов.
В зависимости от расстояния и архитектуры решения для коммуникаций между площадками можно использовать Ethernet, протоколы MPLS или IP. Расстояния между ЦОД при синхронной репликации может составлять до 80-100 км – оно ограничивается допустимыми для приложений задержками в сети. При синхронной репликации приложение получает подтверждение завершения операции ввода/вывода после ее выполнения на обеих сторонах. По технологии FCIP через отдельные коммутаторы можно организовать также асинхронное взаимодействие между ЦОД, удаленными друг от друга на тысячи километров, использовать аппаратное сжатие трафика. По сравнению с протоколом Fibre Channel (FC) на расстоянии более 100 км FCIP работает быстрее. При использовании FCIP, пакеты Fibre Channel инкапсулируются в TCP/IP, а затем передаются через IP-туннель. FCIP – основной практически работающий способ связи ЦОД, когда передача FC по темной оптике или через xWDM невозможна или нецелесообразна. Поддерживается как прямое подключение FCIP устройств друг к другу, так и соединение через WAN.
Ключевой элемент катастрофоустойчивого решения – территориально распределенная система хранения данных. Современные СХД предусматривают встроенные средства для построения катастрофоустойчивых решений. Например, системы хранения данных на указанных площадках могут полностью дублировать друг друга, а сами площадки связывают резервированными высокоскоростными каналами связи, что позволяет реализовать проекты с самыми высокими требованиями к надежности передачи данных и их доступности, включая синхронную репликацию данных. Либо резервирование данных может осуществляться в асинхронном режиме.
У некоторых СХД есть возможность «растягивать» тома между площадками при помощи средств самого дискового массива. В результате создается недорогое катастрофоустойчивое решение, не требующее перестройки архитектуры хранения данных. Другой вариант – использование для резервного копирования данных облачной инфраструктуры Microsoft Azure.
Типичный сценарий – резервный ЦОД в другом городе в пределах региона (расстояние — 300-400 км). Для связи по LAN используется IP или MPLS/VPLS, DWDM; для связи по SAN – FCIP, DWDM. В этом случае можно применять ряд «метрокластерных» технологий, использовать асинхронную репликацию. Синхронная репликация на таком расстоянии требует ограничений и дополнительных инструментов. При разнесении площадок на тысячи километров говорят уже о «геокластере».
Способы кластеризации предлагают поставщики операционных систем, сред виртуализации, разработчики приложений, производители ИТ-систем и сетевого оборудования. Например, в основе метрокластера на базе VMware vSphere лежит дублирование систем хранения данных на двух территориально разделенных площадках с возможным балансированием нагрузки на уровне сети ЦОД. При недоступности одного из дата-центров виртуальные машины будут автоматически запущены на второй площадке. При этом скорость восстановления виртуальной среды (RTO) составляет обычно несколько минут.
Экономика катастрофоустойчивости
Не стоит забывать, что реализация стратегии DR требует серьезных инвестиций. Реализация подобного проекта, как правило, связана с большими финансовыми затратами. Обосновать и принять решение о построении такого класса систем весьма сложно. Причем вполне вероятно, что планом резервного восстановления вы никогда не воспользуетесь. Однако в случае чрезвычайной ситуации хороший план восстановления сэкономит время и деньги, поможет свести к минимуму убытки из-за простоя. Серьезная авария может привести к потере дата-центра, а это серьезная проблема для бизнеса. Согласно мировой статистике, 93% компаний, лишившихся своего дата-центра всего на 10 дней, разоряются в течение года.
Нужно найти баланс между затратами на поддержание катастрофоустойчивости и потерями бизнеса в случае катастрофы с учетом времени полного восстановления всех бизнес-процессов. Приведенные ниже иллюстрации помогут получить некоторое представление о затратах на внедрение распределенного ЦОД в компании, точнее оценить объем неизбежных затрат и избежать возможного недопонимания руководителей. В целом зависимость такова: чем меньше требуемое время восстановления, тем дороже обходятся методы защиты данных (по информации Gartner):
Нередко в основе устойчивого к катастрофам ЦОД – территориально-распределенная кластерная конфигурация серверов с подключением к общей сети хранения данных (SAN). Узлы разнесенного кластера размещаются на основной и резервной площадках, образуя единую систему. Это обеспечивает непрерывную доступность сервисов даже в случае потери основного ЦОД. С помощью кластеризации можно обеспечить автоматическое переключение нагрузки между площадками распределенного ЦОД в случае аварии. Возможна и экономичная модификация решения, при которой удаленный ЦОД функционирует в резервном режиме и в случае отказа основного ЦОД поддерживает ограниченный набор сервисов.
В зависимости от расстояния и архитектуры решения для коммуникаций между площадками можно использовать Ethernet, протоколы MPLS или IP. Расстояния между ЦОД при синхронной репликации может составлять до 80-100 км – оно ограничивается допустимыми для приложений задержками в сети. При синхронной репликации приложение получает подтверждение завершения операции ввода/вывода после ее выполнения на обеих сторонах. По технологии FCIP через отдельные коммутаторы можно организовать также асинхронное взаимодействие между ЦОД, удаленными друг от друга на тысячи километров, использовать аппаратное сжатие трафика. По сравнению с протоколом Fibre Channel (FC) на расстоянии более 100 км FCIP работает быстрее. При использовании FCIP, пакеты Fibre Channel инкапсулируются в TCP/IP, а затем передаются через IP-туннель. FCIP – основной практически работающий способ связи ЦОД, когда передача FC по темной оптике или через xWDM невозможна или нецелесообразна. Поддерживается как прямое подключение FCIP устройств друг к другу, так и соединение через WAN.
Ключевой элемент катастрофоустойчивого решения – территориально распределенная система хранения данных. Современные СХД предусматривают встроенные средства для построения катастрофоустойчивых решений. Например, системы хранения данных на указанных площадках могут полностью дублировать друг друга, а сами площадки связывают резервированными высокоскоростными каналами связи, что позволяет реализовать проекты с самыми высокими требованиями к надежности передачи данных и их доступности, включая синхронную репликацию данных. Либо резервирование данных может осуществляться в асинхронном режиме.
У некоторых СХД есть возможность «растягивать» тома между площадками при помощи средств самого дискового массива. В результате создается недорогое катастрофоустойчивое решение, не требующее перестройки архитектуры хранения данных. Другой вариант – использование для резервного копирования данных облачной инфраструктуры Microsoft Azure.
Типичный сценарий – резервный ЦОД в другом городе в пределах региона (расстояние — 300-400 км). Для связи по LAN используется IP или MPLS/VPLS, DWDM; для связи по SAN – FCIP, DWDM. В этом случае можно применять ряд «метрокластерных» технологий, использовать асинхронную репликацию. Синхронная репликация на таком расстоянии требует ограничений и дополнительных инструментов. При разнесении площадок на тысячи километров говорят уже о «геокластере».
Способы кластеризации предлагают поставщики операционных систем, сред виртуализации, разработчики приложений, производители ИТ-систем и сетевого оборудования. Например, в основе метрокластера на базе VMware vSphere лежит дублирование систем хранения данных на двух территориально разделенных площадках с возможным балансированием нагрузки на уровне сети ЦОД. При недоступности одного из дата-центров виртуальные машины будут автоматически запущены на второй площадке. При этом скорость восстановления виртуальной среды (RTO) составляет обычно несколько минут.
Экономика катастрофоустойчивости
Не стоит забывать, что реализация стратегии DR требует серьезных инвестиций. Реализация подобного проекта, как правило, связана с большими финансовыми затратами. Обосновать и принять решение о построении такого класса систем весьма сложно. Причем вполне вероятно, что планом резервного восстановления вы никогда не воспользуетесь. Однако в случае чрезвычайной ситуации хороший план восстановления сэкономит время и деньги, поможет свести к минимуму убытки из-за простоя. Серьезная авария может привести к потере дата-центра, а это серьезная проблема для бизнеса. Согласно мировой статистике, 93% компаний, лишившихся своего дата-центра всего на 10 дней, разоряются в течение года.
Нужно найти баланс между затратами на поддержание катастрофоустойчивости и потерями бизнеса в случае катастрофы с учетом времени полного восстановления всех бизнес-процессов. Приведенные ниже иллюстрации помогут получить некоторое представление о затратах на внедрение распределенного ЦОД в компании, точнее оценить объем неизбежных затрат и избежать возможного недопонимания руководителей. В целом зависимость такова: чем меньше требуемое время восстановления, тем дороже обходятся методы защиты данных (по информации Gartner):