Я ищу варианты обеспечения высокой доступности для моего приложения на базе SQL Server.
Требования:
Я видел два основных варианта: отказоустойчивую кластеризацию SQL Server и зеркалирование SQL Server.
Я понимаю, что отказоустойчивая кластеризация SQL Server требует приобретения общего дискового массива и не предлагает никакой защиты, если общее хранилище выходит из строя (поэтому в документации рекомендуется настроить зеркалирование между двумя кластерами).
Зеркальное отображение базы данных кажется более дешевым вариантом (поскольку для этого требуется только два сервера баз данных и простой свидетель), но я слышал, что оно не работает, когда у вас большое количество баз данных. Приложение, которое я разрабатываю, включает предоставление каждому клиенту собственной базы данных для своего приложения - может быть сотни баз данных. Настроить зеркалирование не проблема благодаря имеющимся у нас системам автоматизации.
Мое последнее замечание касается того, как отработка отказа работает в отношении клиентских подключений - отказоустойчивая кластеризация SQL Server использует MSCS, что означает, что кластер невидим для клиентов - попытка подключения может завершиться неудачей во время отработки отказа, но простое повторное подключение заставит его снова работать. Однако зеркальное отображение, насколько мне известно, требует, чтобы клиент знал о зеркалируемых партнерах: если клиент не может подключиться к первичному серверу, он пробует вторичный сервер.
Мне интересно, как это работает в отношении пула подключений в приложениях ASP.NET - означает ли отказ клиентского подключения при отказе, что существует потенциальная 2-секундная (при условии, что политика тайм-аута TCP 2000 мс), когда пул подключений пытается использовать основной сервер при каждом подключении попытка?
Я где-то читал, что зеркалирование можно использовать поверх MSCS, что означает, что клиенту не нужно знать о зеркалировании (чтобы не было никаких потенциальных задержек во время подключения, а также что не нужно было бы вносить изменения в client, даже не строку подключения), однако мне трудно получить документацию или официальные документы по этому подходу. Но если это правда, то это означает, что лучшим методом является зеркалирование (для HA) с помощью MSCS (для незнания клиента и производительности соединения).
... но как это масштабировать до экземпляра сервера, который может содержать сотни зеркальных баз данных?
Вы правы в том, что зеркалирование и кластеризацию можно использовать вместе, но я думаю, что ваше представление о том, как это работает, немного неверно. Если вы хотите, чтобы ваше приложение поддерживало зеркальное отображение, вы должны установить строку подключения так, чтобы в ней был указан партнер по отработке отказа. Теперь, если у вас есть отказоустойчивый кластер, то, что произойдет, зависит от того, как вы настроили зеркалирование. Если вы настроили автоматическое переключение при отказе, зеркало возьмет на себя управление, и ваше приложение подключится к партнеру по зеркалированию. Если вы настроили ручное переключение при отказе, один из других узлов в кластере для основного запустит службу SQL, а основной будет продолжать обслуживать трафик. Проверять, выписываться http://technet.microsoft.com/en-us/library/ms191309.aspx для получения дополнительной информации.
Кроме того, в SQL 2012 появился новый способ сделать это - «Всегда включен». Это может решить ваши проблемы с меньшими усилиями.