Бөлісу құралы:

Рекомендации по изолированию приложений от простоев и аварий служебной шины

  • Мақала

Критически важные приложения должны работать постоянно, даже при возникновении незапланированных простоев или аварий. Устойчивость к катастрофическим сбоям ресурсов обработки данных является обязательным требованием для многих предприятий, а в некоторых случаях даже входит в состав отраслевых нормативных положений. В этой статье описаны методы, которые можно использовать для защиты приложений служебной шины от возможного простоя службы или аварии.

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

Кроме того, риск сбоя также распространяется на три физически разделенных объекта (зоны доступности), и служба имеет достаточно ресурсов, чтобы мгновенно справиться с полным, катастрофическим потерей центра обработки данных. Все активные Служебная шина Azure модель кластера в домене сбоя вместе с поддержкой зоны доступности превосходят любой локальный продукт брокера сообщений с точки зрения устойчивости к серьезным сбоям оборудования и даже катастрофической потере всего центра обработки данных. Тем не менее могут возникнуть серьезные ситуации с широкомасштабными повреждениями, обеспечить защиту от которых не в силах даже эти меры.

Служебная шина функции геоизбытого восстановления и георепликации предназначены для упрощения восстановления после аварии этого масштаба и отказа от неудачного региона Azure для хорошего и без необходимости изменять конфигурации приложения.

Сбои и аварийные ситуации

Важно отметить различия между "сбоями" и "авариями".

Сбой — это временная недоступность служебной шины Azure. Он может повлиять на некоторые компоненты службы, такие как хранилище сообщений, или даже весь центр обработки данных. Однако после устранения проблемы служебная шина снова становится доступной. Как правило, простой не приводит к утрате сообщений или других данных. Примером сбоя компонента является недоступность определенного хранилища сообщений. Примером простоя центра обработки данных является сбой питания центра обработки данных или неисправность сетевого коммутатора центра обработки данных. Простой может длиться от нескольких минут до нескольких дней. Некоторые сбои являются всего лишь кратковременными потерями подключения из-за временных или сетевых проблем.

Авария определяется как полная или долговременная потеря кластера служебной шины, региона Azure или центра обработки данных. Регион или центр обработки данных может снова или не станет доступным или может быть отключен в течение нескольких часов или дней. Примеры аварий — пожар, наводнение или землетрясение. Длительное аварийное состояние может привести к потере некоторых сообщений, событий или других данных. Однако в большинстве случаев не должно быть потери данных и сообщения можно восстановить после резервного копирования центра обработки данных.

Защита от сбоев и аварий

В Служебная шина Azure уровня "Премиум" предусмотрено два компонента, которые обеспечивают геокатастасторное восстановление. Во-первых, существует геоизбыточное восстановление (аварийное восстановление метаданных), обеспечивающее репликацию метаданных (сущностей, конфигурации, свойств). Во-вторых, существует георепликация, которая в настоящее время находится в общедоступной предварительной версии, обеспечивая репликацию как метаданных, так и данных (данные сообщения и изменения состояния или изменения состояния). Ни функция гео-аварийного восстановления не должна путаться с Зоны доступности. Независимо от того, является ли это аварийное восстановление метаданных или георепликация, обе функции гео графического восстановления обеспечивают устойчивость между регионами Azure, такими как восточная часть США и западная часть США.

Зоны доступности доступны на всех уровнях служебная шина, а поддержка обеспечивает устойчивость в определенном географическом регионе, например на востоке США. Дополнительные сведения об аварийном восстановлении в Microsoft Azure см. в статье Аварийное восстановление для приложений на платформе Azure.

Концепции высокого уровня доступности и аварийного восстановления встроены прямо в уровень "Премиум" Служебная шина Azure, как в одном регионе (через зоны доступности), так и в разных регионах (с помощью геокатастирной восстановления и георепликации).

Варианты геокатастного восстановления

Геоизбыточное аварийное восстановление

служебная шина уровня "Премиум" поддерживает геокатастасовочное восстановление на уровне пространства имен. Дополнительные сведения см. в разделе Служебная шина Azure геоизбыточное восстановление. Функция геокадрового восстановления, доступная только для уровня "Премиум", реализует аварийное восстановление метаданных и зависит от основных и вторичных пространств имен. При использовании геоизбыточное восстановление только метаданные для сущностей реплицируются между основными и вторичными пространствами имен.

Георепликация

служебная шина уровня "Премиум" также поддерживает георепликацию на уровне пространства имен. Дополнительные сведения см. в Служебная шина Azure георепликации (общедоступная предварительная версия). Функция георепликации, доступная только для уровня "Премиум" и в настоящее время в общедоступной предварительной версии, реализует метаданные и аварийное восстановление данных и использует первичные и вторичные регионы. При георепликации метаданные и данные для сущностей реплицируются между основными и вторичными регионами.

Различия функций высокого уровня

Функция гео-аварийного восстановления (аварийное восстановление метаданных) реплицирует метаданные для пространства имен из первичного пространства имен в дополнительное пространство имен. Он поддерживает однократную отработку отказа только в дополнительный регион. Во время отработки отказа, инициированного клиентом, псевдоним имени пространства имен перенаправляется в дополнительное пространство имен, а затем сбой связывания. Никакие данные не реплицируются, кроме метаданных, и не реплицируются назначения RBAC.

Функция георепликации реплицирует метаданные и все данные из основного региона в один или несколько дополнительных регионов. Когда отработка отказа выполняется клиентом, выбранная вторичная становится первичной, а предыдущая первичная становится вторичной. При необходимости пользователи могут выполнить отработку отказа на исходный первичный ресурс.

Зоны доступности

Все уровни служебная шина поддерживают зоны доступности, предоставляя изолированные от сбоя расположения в одном регионе Azure. служебная шина управляет тремя копиями хранилища сообщений (1 первичный и 2 вторичный). служебная шина сохраняет синхронизацию всех трех копий для операций управления и данных. Если первичная копия завершается сбоем, одна из вторичных копий повышается до первичной без наблюдаемого простоя. Если приложения видят временные отключения от служебная шина, логика повторных попыток в пакете SDK автоматически повторно подключается к служебная шина.

При использовании зон доступности метаданные и данные (сообщения) реплицируются в центрах обработки данных в зоне доступности.

Примечание.

Поддержка зон доступности доступна только в регионах Azure, где присутствуют зоны доступности.

При создании пространства имен поддержка зон доступности (если она доступна в выбранном регионе) автоматически включается для пространства имен. Дополнительные затраты на использование этой функции не требуются, и вы не можете отключить или включить эту функцию после создания пространства имен.

Примечание.

Ранее было необходимо задать свойство zoneRedundant для true включения зон доступности, однако это поведение изменилось, чтобы включить зоны доступности по умолчанию. Существующие пространства имен переносятся в зоны доступности, а свойство zoneRedundant устарело. Свойство zoneRedundant по-прежнему может отображаться как false, даже если зоны доступности включены.

Защита от аварий — стандартный уровень

Чтобы обеспечить устойчивость к авариям с помощью уровня "стандартный" служебная шина, можно использовать активную или пассивной репликацию. В каждом из этих подходов, если заданная очередь или раздел должны оставаться доступными при простое центра обработки данных, то эти очередь или раздел можно создать в обоих пространствах имен. Обе сущности могут иметь одно и то же имя. Например, первичная очередь может быть доступна как contosoPrimary.servicebus.windows.net/myQueue, а ее вторичный аналог — как contosoSecondary.servicebus.windows.net/myQueue.

Примечание.

Активная репликация и настройка пассивной репликации являются решениями общего назначения, а не конкретными функциями служебная шина. Логика репликации (отправка в 2 разных пространства имен) находится в приложениях отправителя, а получатель должен иметь пользовательскую логику для обнаружения повторяющихся данных.

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

Активная репликация

При активной репликации для каждой операции используются объекты в обоих пространствах имен. Любой клиент, отправляющий сообщение, отправляет две копии одного и того же сообщения. Первая копия отправляется основной сущности (например, contosoPrimary.servicebus.windows.net/sales), а вторая копия — дополнительной сущности (например, contosoSecondary.servicebus.windows.net/sales).

Клиент получает сообщения из обеих очередей. Получатель обрабатывает первую копию сообщения, а вторая копия пропускается. Во избежание дублирования сообщений отправитель должен помечать каждое сообщение уникальным идентификатором. Обе копии сообщения должны быть помечены одним и тем же идентификатором. Для тега сообщения можно использовать свойства ServiceBusMessage.MessageId или ServiceBusMessage.Subject или пользовательское свойство. Получатель должен хранить список уже полученных им сообщений.

Примечание.

При активной репликации количество операций удваивается, поэтому этот подход может привести к увеличению расходов.

Пассивная репликация

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

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

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

При использовании пассивной репликации в следующих сценариях сообщения могут быть потеряны или получены дважды:

  • Задержка или потеря сообщения. Предположим, что отправитель успешно отправил сообщение m1 в основную очередь, а затем очередь стала недоступной до получения сообщения m1 получателем. Отправитель отправляет следующее сообщение m2 в дополнительную очередь. Если основная очередь временно недоступна, то получатель получит сообщение m1 после того, как очередь снова станет доступной. Когда происходит авария, получатель никогда не получит m1.
  • Дублирование. Предположим, что отправитель отправляет сообщение m в основную очередь. Служебная шина успешно обрабатывает m, но ей не удается отправить ответ. По истечении времени ожидания отправки сообщения отправитель посылает идентичную копию сообщения m в дополнительную очередь. Если получатель смог получить первую копию m до того как основная очередь стала недоступной, то он получит обе копии m приблизительно в одно и то же время. Если получатель не может получить первую копию m до того, как первичная очередь становится недоступной, получатель изначально получает только вторую копию m, но затем получает вторую копию m, когда первичная очередь становится доступной.

В примере задач репликации сообщений Azure с помощью .NET Core демонстрируется репликация сообщений между пространствами имен.

Следующие шаги

Дополнительные сведения об аварийном восстановлении см. в следующих статьях: