Назад | Перейти на главную страницу

Сочетание отказоустойчивой кластеризации и зеркального отображения базы данных

Когда вы комбинируете отказоустойчивую кластеризацию и зеркальное отображение базы данных в SQL Server, вам необходимо изменить значение тайм-аута партнера по зеркальному отображению, чтобы у локального кластера была возможность отработки отказа до того, как произойдет отработка отказа зеркального отображения базы данных. Мне любопытно, что люди делают, комбинируя эти технологии - я преподаю различные классы HA, и это не слишком распространенная комбинация.

Вот мои вопросы, ЕСЛИ вы используете отказоустойчивую кластеризацию и зеркальное отображение базы данных вместе. Если бы вы могли ответить на все вопросы в каждом ответе, это было бы очень полезно для меня. Мне не нужно объяснять, почему нужно что-то менять или как работают технологии - я владел ими обоими, когда работал в Microsoft - меня интересуют отраслевые практики, теперь возможность жениться на них существует уже 4 года .

1) сколько времени в среднем уходит на переключение кластерного экземпляра SQL Server за вас? (Я знаю, это зависит от того, сколько требуется восстановления после сбоя, но каков средний показатель для вас?)

2) для этих же экземпляров, на что вы устанавливаете тайм-аут партнера по зеркалированию?

3) вас устраивает тот факт, что может произойти реальный сбой кластера, и может пройти довольно много времени, пока зеркалирование не заметит, что сбой произошел из-за того, что вы увеличили время ожидания партнера зеркалирования?

Спасибо за все отзывы!

Пол, 1. Обычно от нескольких секунд до пары минут в зависимости от ... (остальное вы знаете).

  1. Если бы я настроил автоматическое переключение при отказе, я бы потратил несколько минут. Таким образом, VPN-соединения между сайтами будут иметь время для восстановления, кластер может перезапуститься и т.д. отключение электричества.

  2. Ага. Проблемы аварийного восстановления обычно определяются как сбой в течение часа. Кроме того, глобальному балансировщику нагрузки, вероятно, потребуется больше времени, чтобы заметить, что другой сайт не работает, и загрузить все DNS плюс время TTL на DNS. Это общее время должно быть верхним пределом времени для автоматического переключения при отказе.

Я не участвовал в первоначальном дизайне, но вот как все было настроено:

  • Кластер из 2 узлов на каждом сайте, работает активный / активный
  • Всего приложение использует 5 баз данных, 4 из которых работают на одном экземпляре. Другой db 1 работает сам по себе (гораздо более высокая нагрузка)
  • Сайты соединены темным волокном
  • У каждого сайта одинаковое количество веб-серверов, использующих клиент с поддержкой зеркала.
  • Зеркальное отображение базы данных настроено для всех 5 баз данных.
  • На каждом сайте есть еще один автономный сервер, который может действовать как свидетель. Свидетель в настоящее время работает на сайте, где находятся все участники.

    1. Я никогда не видел, чтобы произошел отказ кластера. Отказ зеркала происходит быстро, я бы сказал, самое большее 10 секунд.

    2. Тайм-аут партнера составляет 30 секунд для всех БД

    3. Было задумано, что переключение зеркала произойдет до переключения кластера. БД кластеризуются только как дополнительный уровень избыточности, хотя каждый экземпляр настроен на использование только половины доступной оперативной памяти на сервере.