Для нашего приложения SaaS я хочу иметь систему на случай сбоя всего центра обработки данных.
В главном центре обработки данных у нас есть два сервера, настроенных с зеркальным отображением базы данных MSSQL (синхронизировано). Это дает нам достаточно хорошее решение для обеспечения высокой доступности при сбоях серверов. Если сервер умирает, он автоматически отключается (с помощью третьего сервера-свидетеля) в течение нескольких секунд.
Я думал об использовании Репликация MSSQL или доставка журналов из зеркальной базы данных, чтобы сохранить теплый режим ожидания сервер в другой дата-центр - обратите внимание, это будет трансатлантический и, следовательно, высокий пинг ~ 100 мс. Думаю, я мог бы использовать Отказоустойчивость DNS сервис с коротким (5 мин) TTL, который будет направлять трафик во второй центр обработки данных в случае отказа первого.
Вопросы:
Могу ли я использовать репликацию или доставку журналов из зеркальной базы данных (без проблем при переключении на другой экземпляр)?
Что предпочтительнее - репликация, доставка журналов или что-то еще?
Возможно ли, чтобы база данных аварийного переключения принимала записи?
Или будет возможна потеря данных из-за аварийного переключения, и поэтому лучше всего иметь этот режим только для чтения, пока мы не вернемся в основной центр обработки данных?
Спасибо!
РЕДАКТИРОВАТЬ: у кого-нибудь есть идеи для конфигурации резервного сервера MSSQL?
Либо доставка журналов, либо репликация будут работать с зеркалированием БД - какой из них вы должны использовать, зависит от ваших требований, но репликация может быть сложнее настроить и управлять, чем доставка журналов, поэтому лично я бы придерживался доставки журналов, если нет функции репликации, которую вы очень нужно. Ссылки ниже предоставляют дополнительную информацию о том, как настроить каждый из них.
Возможно ли, чтобы база данных аварийного переключения принимала записи?
Примечание: я предполагаю, что вы имеете в виду, когда произошло аварийное переключение, а не во время повседневной нормальной работы.
Конечно, с доставкой журналов можно иметь базу данных аварийного переключения на вторичном контроллере домена, принимающую записи. Если вы можете взять и применить резервную копию хвостового журнала базы данных, работающей на первичном DC (чтобы минимизировать потерю данных и сохранить целостность цепочки журналов), то у вас будет актуальная копия работающей базы данных, тем не мение не забывайте, что в этой ситуации вы работаете открыто. Регулярное резервное копирование журналов может помочь, но если ваша цель не состоит в том, чтобы не потерять транзакции, это не может быть гарантировано, если вы работаете исключительно на вторичном сервере доставки журналов на другом DC. Может быть лучше просто запустить приложение в режиме только для чтения, пока ваша высокая доступность не будет снова настроена. Из этого состояния вы можете скопировать резервные копии журналов в основной центр обработки данных, а затем повторно инициализировать зеркальное отображение.
Полезные ссылки:
http://msdn.microsoft.com/en-us/library/ms187016.aspx - Доставка журналов и зеркальное отображение базы данных http://msdn.microsoft.com/en-us/library/ms151799.aspx - Репликация и зеркальное отображение базы данных
Примечание: чтобы получить доступ для записи в базу данных отправки журналов, вам необходимо ВОССТАНОВИТЬ имя базы данных базы данных С ВОССТАНОВЛЕНИЕМ. После этого его можно будет записать как мастер, НО после этого вы не сможете восстановить никакие дополнительные журналы. Вам необходимо восстановить новую полную резервную копию, чтобы обработка журналов снова заработала. Но это, по крайней мере, позволит вам переключиться на него.
Я нахожусь на стадии планирования чего-то похожего, но не для всего мира, а для США. Мы планируем продолжить доставку бревен. Он кажется (по крайней мере, мне) более надежным, чем репликация (с которой я работал), проще в администрировании и более простой настройке (по крайней мере, для меня).
Вот краткий список за и против. Самый большой недостаток для нас - это отсутствие автоматического переключения при отказе, как при зеркалировании.
Как правило, вы выбираете хороший маршрут, но учтите следующее:
Это причины, по которым это обеспечивает ограниченное увеличение HA. Кеширование до 24 часов - не редкость. Я бы предположил, что это больше подход DR, поскольку это действительно то, что вы действительно хотели бы делать только в том случае, если ваш основной сайт затронут в течение более длительного периода, поскольку восстановление после отказа также занимает 24 часа для распространения на определенных клиентов.