Экспорт (0) Печать
Развернуть все
Развернуть Свернуть

Рекомендации по изоляции приложений Service Bus в случае сбоев Service Bus и аварий

Обновлено: Апрель 2014 г.

Критически важные приложения должны работать постоянно даже при незапланированных сбоях или авариях. В этом разделе описаны методики защиты приложений от возможных сбоев Шина службы Microsoft Azure или аварий.

Простой — это временная недоступность Шина службы Microsoft Azure. Простой может влиять на некоторые компоненты Служебная шина, например хранилище сообщений или даже весь центр обработки данных. После устранения ошибки доступность Служебная шина восстанавливается. Как правило, сбой не приводит к утрате сообщений или других данных. Примером сбоя компонента является недоступность Microsoft Azure Active Directory Access Control (также называется Access Control Service или ACS) либо недоступность определенного хранилища сообщений. Примером простоя на уровне центра обработки данных может послужить перебой в питании центра обработки данных или сбой коммутатора сети центра обработки данных. Сбой может длиться от нескольких минут до нескольких дней.

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

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

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

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

Для защиты от простоев ACS используются маркеры подписанного URL-адреса (SAS). В этом случае аутентификацию клиента выполняет непосредственно Служебная шина, подписывая самостоятельно созданный маркер секретным ключом. И вызовы ACS больше не требуются. Дополнительные сведения маркерах подписанного URL-адреса см. в разделе Проверка подлинности шины обслуживания.

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

Для реализации отработки отказов между двумя центрами обработки данных, можно создать по Служебная шина и Служба управления доступом пространство имен службы в каждом центре. Например, Служебная шина пространство имен службы contosoPrimary.servicebus.windows.net может располагаться на севере США, а contosoSecondary.servicebus.windows.net — на юге. Если объект обмена сообщениями в Служебная шина должен оставаться доступным даже при перебое в работе центра обработки данных, можно создать его в обоих пространство имен службы.

Географически распределенная репликация конечных точек ретрансляции позволяет службе, поддерживающей такую точку, оставаться доступной даже в случае перебоя в работе Служебная шина. Для реализации такой репликации в службе следует создать две конечных точки ретрансляции в разных пространство имен службы. Оба пространство имен службы должны находиться в разных центрах обработки данных, а точки должны иметь разные имена. Так, основная точка может публиковаться как contosoPrimary.servicebus.windows.net/myPrimaryService, а дополнительная — contosoSecondary.servicebus.windows.net/mySecondaryService.

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

В примере Географически распределенная репликация с помощью ретрансляции сообщений через Service Bus показана репликация точек ретрансляции.

Для обеспечения устойчивости к перебоям в работе центра обработки данных при передаче сообщений через посредника Служебная шина поддерживает два подхода: активную и пассивную репликацию. Если (в обоих подходах) очередь или раздел должны оставаться доступными даже при перебое в работе центра обработки данных, можно создать их в обоих пространство имен службы. Оба объекта могут иметь одно имя. Так, основная очередь может публиковаться как contosoPrimary.servicebus.windows.net/myQueue, а дополнительная — contosoSecondary.servicebus.windows.net/myQueue.

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

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

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

В примере Географически распределенная репликация с помощью ретрансляции сообщений через Service Bus показана активная репликация объектов обмена сообщениями.

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

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

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

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

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

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

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

В примере Географически распределенная репликация с помощью ретрансляции сообщений через Service Bus показана пассивная репликация объектов обмена сообщениями.

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

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

См. также

Показ:
© 2014 Microsoft