Мне всегда нравится визуализировать решения высокой доступности:
Экземпляр отказоустойчивого кластера SQL Server (FCI)
Что высоко доступно? Весь экземпляр. Сюда входят все объекты сервера (имена входа, задания агента SQL Server и т. Д.). Это также включает базы данных и содержащие их объекты. Это отличное решение для высокодоступных экземпляров SQL Server, потому что это будет уровень сдерживания с данным решением.
Как насчет отчетности? Нет, NULL, не существует. Экземпляр отказоустойчивого кластера имеет активный узел, доставляющий группу кластеров, содержащую этот экземпляр, VNN и т. Д., А все остальные узлы пассивны, находятся в режиме ожидания (что касается текущей группы кластеров) и ожидают переключения при сбое.
Что происходит, когда происходит аварийное переключение? Время простоя для FCI будет определяться количеством времени, которое пассивному узлу требуется для захвата ресурса кластера и перевода экземпляра SQL Server в рабочее состояние. Это обычно минимально по времени.
Любая клиентская абстракция? Да, это будет встроено в имя виртуальной сети для экземпляра отказоустойчивого кластера. Это всегда будет указывать на активный узел, который в данный момент доставляет ресурс кластера SQL Server.
Группы доступности AlwaysOn
Что высоко доступно? Группа доступности будет здесь логическим сдерживанием высокой доступности, тогда как группа доступности состоит из нескольких баз данных и имени виртуальной сети (слушатель, необязательный ресурс кластера). Стоит отметить, что объекты сервера, такие как учетные записи и задания агента SQL Server, не будут частью решения высокой доступности, и необходимо принять особые меры для обеспечения их правильной реализации с группой доступности. Не слишком обременительное требование, но о нем нужно заботиться.
Как насчет отчетности? Это отличное решение для создания отчетов, хотя я, вероятно, не буду использовать синхронную реплику в качестве экземпляра отчетов. Существует два отношения фиксации, синхронные и асинхронные. По моему мнению и из того, что я видел на практике, ваша вторичная синхронная реплика находится там в ожидании катастрофы. Думайте об этом как о той реплике, которая готова принять аварийное переключение без потери данных в случае возникновения проблемы. Затем существуют асинхронные реплики, которые могут обрабатывать эту рабочую нагрузку. Вы не используете эту реплику в качестве вышеупомянутого решения, но в большей степени для таких вещей, как отчетность. Отчеты о рабочих нагрузках могут быть направлены на эту реплику (напрямую или косвенно через маршрутизацию только для чтения через слушателя).
Что происходит, когда происходит аварийное переключение? Для вторичной реплики синхронной фиксации, которая связана с автоматическим переключением при сбое, это будет изменение состояния роли реплики с SECONDARY_NORMAL на PRIMARY_NORMAL. Для того чтобы происходил автоматический переход на другой ресурс, вам необходимо иметь синхронную вторичную реплику, которая в настоящий момент синхронизирована, и в ней реализована гибкая политика перехода на другой ресурс, чтобы определить, когда на самом деле должно происходить это переключение. Эта политика действительно настраивается.
Любая клиентская абстракция? Да, вы можете дополнительно настроить прослушиватель группы доступности AlwaysOn. По сути, это просто имя виртуальной сети (может рассматриваться через WSFC как ресурс кластера в группе кластеров AG), которое указывает на текущую первичную реплику. Это ключевая часть перемещения рабочей нагрузки по отчетам, а также настройки списка маршрутизации только для чтения на любых серверах, на которые вы хотите перенаправлять трафик ReadOnly (это задается через строку подключения с помощью поставщика .NET Framework для SQL Сервер, это будет параметр Application Intent , установленный на ReadOnly ). Вам также необходимо установить URL-адрес маршрутизации только для чтения для каждой реплики, для которой вы хотите получать эту рабочую нагрузку создания отчетов, находясь в роли вторичной реплики.
Транзакционная репликация
Что высоко доступно? Это спорно, но я собираюсь сказать ничего . Я не рассматриваю репликацию как решение высокой доступности. Да, изменения данных передаются подписчикам, но мы говорим на уровне публикации / статьи. Это будет подмножество данных (может включать в себя все данные, но оно не будет применено. Т.е. вы создаете новую таблицу в базе данных издателя, и она не будет автоматически отправляться подписчикам). Что касается HA, то это «дно», и я не буду группировать его там с надежным решением HA.
Как насчет отчетности? Отличное решение для составления отчетов по подмножеству данных, без сомнений. Если у вас есть база данных объемом 1 ТБ с высокой транзакционной нагрузкой, и вы хотите сохранить эту рабочую нагрузку отчетов вне базы данных OLTP, репликация транзакций является отличным способом передачи подмножества данных подписчику (или подписчикам) для рабочей нагрузки отчетности. Что произойдет, если из этого 1 ТБ данных ваша рабочая нагрузка составляет всего около 50 ГБ? Это разумное решение, которое можно настроить в соответствии с потребностями вашего бизнеса.
Резюме
То, к чему это сводится, является горсткой вопросов, на которые нужно ответить (частично бизнесом):
- Что должно быть доступно ?
- Что SLA диктует для HA / DR?
- Какого рода отчетность будет осуществляться и какие задержки допустимы?
- Что нам нужно делать с географически распределенной ГА? (Репликация хранилища стоит дорого, но обязательно с FCI. AGs не требуют общего хранилища от автономных экземпляров, и вы можете использовать свидетеля общего файлового ресурса для кворума, что потенциально устраняет необходимость в общем хранилище)