Разработка глобально доступных сервисов с использованием базы данных SQL Azure - PullRequest
0 голосов
/ 23 сентября 2019

Мы работаем с отказоустойчивыми группами SQL, и я натолкнулся на в этой статье , в которой предполагается, что можно построить архитектуру, обеспечивающую целостность региона во время отработки отказа, с помощью Traffic Manager и Failover Groups.Сценарий, который меня интересует, это Сценарий 1, который имеет следующую диаграмму:

enter image description here

Мне известны другие способы достижения целостности региона,но мне интересно понять, как это возможно в этом сценарии.Может кто-нибудь уточнить, как регион базы данных остается совместимым с регионом веб-приложения в сценарии 1?Диаграмма показывает, что в обоих регионах используется строка подключения Read Write группы аварийного переключения.Насколько я понимаю, когда база данных в области A сообщает о проблеме, веб-приложение в области A, которое все еще подключено к базе данных в области A через основное соединение RW отказоустойчивой группы, сообщит диспетчеру трафика (TM) о наличиипроблема с подключением во время пинга TM, и поэтому область A ухудшается.

TM будет затем направлять трафик в область B. Однако в области B используется строка подключения группы аварийного переключения RW, и поэтому она зависит от переключения группы аварийного переключения на DB в области B.

Моя путаница заключается в следующем: как только отказоустойчивая группа успешно переключается на базу данных в области B, то есть основным сервером БД теперь является область B, что мешает TM переключиться обратно на веб-приложение в области A?Регион A теперь должен сообщать об этом как о подключенном к TM в связи с успешным подключением к БД, поскольку отказоустойчивая группа переключила свою основную, хотя и на базу данных в регионе B, но веб-приложение не знает, в каком именно регионе находится база данных, посколькуон находится за Failover Group и поэтому должен просто сообщить об успешном соединении, что заставит TM направить трафик обратно в область A, оставив архитектуру в межрегиональном состоянии, сводя на нет цель решения, то есть иметь все ресурсызапускаться под одним регионом в случае сбоя и возврата.

Может кто-нибудь объяснить, как здесь поддерживается целостность региона?

Обновление

После некоторого копаниявокруг я нашел эту статью , которая, кажется, дополняет другую .В статье описывается проблема с точки зрения VNET, где важно региональное размещение.Таким образом, в примере с точки зрения VNET: если происходит сбой БД в области A, что приводит к аварийному переключению на БД в регионе B, узел RW группы аварийного переключения становится областью B, вызывая сбой в области A, т.е. область A не может подключиться к области Bиз-за правил VNET;поэтому вся система полностью переключается на область B и поддерживает узел RW как в приложениях области A, так и в области B, т. е. отдельная конфигурация соединения с базой данных не требуется.Это допускает полное восстановление после сбоя региона, когда происходит сбой только основной базы данных.Вот соответствующий раздел из статьи:

Инициировать аварийное переключение вручную при обнаружении сбоя.Эта опция оптимизирована для приложений, которым требуется постоянная задержка между внешним интерфейсом и уровнем данных, и поддерживает восстановление, когда сбой влияет на внешний интерфейс, уровень данных или оба.

Так что до сих порКак я могу сказать, для достижения полного перехода на другой ресурс при сбое региона и поддержания регионального совместного размещения ресурсов в случае сбоя базы данных в группе аварийного переключения вы должны настроить VNET в дополнение к компонентам на приведенной выше схеме и шагам, подробно описанным в оригинальная статья .Кажется очевидным, но это не ясно из простого чтения этой страницы.Если есть другие мнения, пожалуйста, сообщите.

...