Мы стремимся улучшить наши возможности Disater для восстановления и отработки отказа или наш веб-сервер и сервер приложений Webpshere.
У нас есть 2 сайта в Великобритании [HQ и Callcentre], и мы хотим разместить веб-сервер DR и сервер приложений на сайте call-центра. Так что, если HQ не работает, сервер Callcenter может взять на себя ответственность.
Мы думали запустить два бокса VMware ESx и отразить изменения конфигурации между ними (насколько я не уверен)
Альтернатива, о которой мы думали, - это использование Websphere Culstering.
Кажется, это хорошие варианты?
У вас есть две проблемы:
Ваш выбор должен соответствовать архитектуре вашей сети и приложений.
Один из вариантов, который я видел реализованным (он был на физических серверах, но его можно было легко адаптировать для виртуальных серверов), заключался в том, чтобы производственная система работала на первичном сайте на некотором заданном оборудовании, со всем хранилищем, поддерживаемым SAN (как система, так и тома данных ). Затем SAN управляет репликацией в другую SAN на сайте аварийного восстановления на уровне кластера в реальном времени.
Если первичный сервер выходит из строя, то копия первичного сервера на сайте аварийного восстановления может быть запущена на резервном оборудовании, и он вернется с конфигурацией и данными почти непосредственно перед неисправностью. ОС подумает, что с оборудованием что-то пошло не так (например, отключение электроэнергии), и восстановится, как обычно.
Преимущество этой настройки заключается в том, что резервный режим обновляется почти в реальном времени, и вам не нужно вносить какие-либо изменения в приложения для поддержки этого вида или переключения при отказе. Обратной стороной этой настройки являются требуемые накладные расходы на инфраструктуру (двойные сети SAN, двойные серверы), которые могут быть доступны или недоступны.