*) SRM - это плагин к VC(посему он ставится на машину с VC, появляется в плагинах VC и становится доступна новая кнопочка Site Recovery), поэтому требует VC от 2.5. А ESX любой (3.x.х)
Сама служба SRM, может стоять на другой машине, нежели VC
у SRM есть отдельная база - может быть отдельным инстансом в DB VC.
*) в основе лежит
независимость от железа - самой виртуализацией
две разнесенные СХД и репликация между ними. Вот тут интереснее: СХД должа обеспечивать доступ на уровне блоков(т.е. это не NFS),
репликация делается средствами стораджа. SRM не делает репликацию, он опирается на существующую и настроенную репликацию. Соответственно может её видеть и читать через т.н. Storage Adapter. Когда происходит тестирование Recovery Plan SRM через Storage Adapter даёт команду стораджу на snapshot.Мотивируется такой подход тем, что стандарта среди FC\iSCSI СХД особо нету, поэтому вендор стораджа сам делает софт для репликации, и сам пишет софтинку, которая транслирует команды SRM в понятные СХД, и обратно. А за это VMware называет такие СХД сертифицированными. Как я понял, все заинтересованы в такой сетификации
В твоих терминах эта сертификация и есть разработка того самого Storage Adapter. Итак, у нас есть два набора железок(хосты + СХД), разнесенные для большей устойчивости. В тексте я буду использовать термины "локация" или "ЦОД" для именования этих двух наборов.
У нас есть репликация данных на СХД - между основным и резервным. Теперь нам интересно поиметь автоматизацию процесса восстановления:
В SRM можно создавать т.н. сценарии восстановления - указываем группу ВМ, которая попадает под действие конкретного сценария. Например, сценарий "Полная жопа" применяется при крахе ЦОД - под его действия попадают все ВМ. В сценарии указано - при его запуске задействовать VC резервного ЦОДа , регистрировать в нем и запускать ВМ, причем в качестве хранилища используется LUN, физически лежащий на сторадже в резвной локации. Запускать не все ВМ(для экономии ресурсов), например, третьи резервные DC, DNS и т.п. сервера лежат, тестовые лежат, некритичные задачи лежат. Запускаются только критичные ВМ, притом с указанными приоритетам - сначала DB, потом Exchange, потом некритичный IIS, если хватит ресурсов.
Если ты имеешь план восстановления, но не пробывал его в деле - ты его не имеешь. Проверка сценария восстановления - отдельная, штатная и мощная функция. В случае запуска проверки сценария - делается снапшот задействованного LUN/LUN'ов, и на запасной локации, в изолированной сети, поднимаются указанные в сценарии ВМ. Соответственно, образуется "песочница", работоспособность поднявшейся инфраструктуры в которой можно(нужно!) с удобством проверять. И уже отлаженные "на кошках" сценарии ждут своего применения в "боевых" условиях.
В примере я указал сценарий аля "Большая красная кнопка", но, само собой, чем глобальный сбой в рамках ЦОД, более вероятны сбой сервера, стойки, дисковой полки - т.е. сбои, затрагивающие только часть ВМ. И мы можем делать сколько угодно сценариев под разные ситуации, под разные группы ВМ - и все их безопасно отлаживать.
Сообщения
