Надежность в Центр Интернета вещей Azure

Центр Интернета вещей Azure — это управляемая служба, размещенная в облаке, которая выступает в качестве центрального центра сообщений для обмена данными между приложением Интернета вещей и подключенными устройствами.

При использовании Azure надежность является совместной ответственностью. Майкрософт предоставляет ряд возможностей для поддержки устойчивости и восстановления. Вы несете ответственность за понимание того, как работают эти возможности во всех используемых вами службах, а также за выбор возможностей, необходимых для достижения бизнес-целей и целей бесперебойной работы.

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

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

Для производственных нагрузок мы рекомендуем следовать следующим советам.

• Разверните центр Интернета вещей в регионе, который поддерживает резервирование по зонам как для вычислительных, так и для компонентов данных. Дополнительные сведения см. в разделе "Требования".
• Реализуйте соответствующие шаблоны повторных попыток во всех устройствах и приложениях, которые взаимодействуют с Центр Интернета вещей.
• Настройте логику повторного подключения вашего устройства для обработки кратковременных сбоев и переключения служб. Дополнительные сведения см. в разделе "Управление подключением устройств" для создания устойчивых приложений.
• Для крупномасштабных развертываний следуйте приведенным ниже рекомендациям.
  • Реализуйте экспоненциальные шаблоны повторных попыток на основе джиттера в устройствах и приложениях при повторном подключении к Центр Интернета вещей, что помогает избежать шторма повторных подключений в случае отказов на стороне сервера или сбоев в сети.
  • Ознакомьтесь с квотами и ограничениями службы Центр Интернета вещей и составьте план их управления. Учитывая поведение регулирования на стороне службы, ограничения подключений и единицы пропускной способности, вы можете заранее разработать решение, чтобы обеспечить прогнозируемую масштабируемость и избежать рефакторинга архитектуры по мере роста парка. Дополнительные рекомендации см. в разделе Масштабирование и квоты Центр Интернета вещей.
  • Используйте Центр Интернета вещей Azure вместе со службой подготовки устройств Центр Интернета вещей Azure (DPS). DPS обеспечивает безопасную, автоматическую регистрацию и назначение устройств в одном или нескольких узлах. Даже если вы не ожидаете наличия большого парка, включив DPS с самого начала, ваши рабочие процессы производства и подключения могут масштабироваться, не требуя изменения встроенного ПО или инфраструктуры позже. Дополнительные сведения см. в статье "Развертывание решений Интернета вещей в масштабе с помощью DPS".
  • Рекомендуется использовать политики выделения DPS для распределения устройств между несколькими экземплярами Центр Интернета вещей для повышения доступности и устойчивости региона. Этот подход обеспечивает горизонтальное масштабирование способности по приему данных и обеспечивает возможность будущего увеличения флота без необходимости повторной подготовки устройств.

Обзор архитектуры надежности

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

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

• Компоненты обмена сообщениями: Центр Интернета вещей обрабатывает двунаправленный обмен сообщениями между устройствами и вашими серверными приложениями, включая телеметрию устройство-облако, команды облако-устройство и прямые вызовы методов.

• Двойники устройств: Документы JSON, которые хранят сведения о состоянии устройства, включая метаданные, конфигурации и условия. Устройства и серверные приложения могут считывать и обновлять двойники устройств.

В целях надежности компоненты Центр Интернета вещей классифицируются по двум группам:

• Вычислительные компоненты: Управление подключениями устройств, проверка подлинности запросов, перенаправление сообщений и вызовы прямых методов. Эти компоненты определяют возможность Центр Интернета вещей принимать и обрабатывать запросы.

• Компоненты данных: Хранит реестр удостоверений устройств, двойники устройств и сообщения устройство-облако. Эти компоненты определяют доступность и устойчивость данных.

Это различие важно, так как разные регионы поддерживают различные типы избыточности для этих компонентов.

Интеграция с другими службами

Вы можете интегрировать Центр Интернета вещей с реестром устройств Azure. При использовании этого подхода ознакомьтесь с Reliability в реестре устройств Azure для понимания надежности обеих служб.

Если для подготовки устройств используется Центр Интернета вещей служба подготовки устройств (DPS), надежность решения также зависит от DPS. Дополнительные сведения см. в разделе Центр Интернета вещей Служба подготовки устройств с высоким уровнем доступности и аварийного восстановления.

Устойчивость к временным сбоям

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

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

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

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

Устойчивость к сбоям зоны доступности

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

Центр Интернета вещей поддерживает два различных типа поддержки зоны доступности:

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

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

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

Требования

Поддержка региона: Тип поддержки зоны доступности для Центра Интернета вещей зависит от региона, в который он развернут.

Регион	Зональная избыточность для данных	Избыточность зоны для вычислений
Australia East
Бразилия (Юг)
Canada Central
Центральная Индия
Central US
East US
Центральная Франция
Западно-Центральная Германия
Japan East
Korea Central
North Europe
Norway East
Qatar Central
Южно-Центральная часть США
Юго-Восточная Азия
UK South
West Europe
Западная часть США 2
Западная часть США 3

Центры Интернета вещей, создаваемые в регионах, которые не указаны в этом списке, не устойчивы к сбоям зон.

Себестоимость

Дополнительная плата за зоны с избыточностью в Центр Интернета вещей не взимается.

Настройка поддержки зоны доступности

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

Поведение, когда все зоны работоспособны

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

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

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

Поведение во время сбоя зоны

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

• Обнаружение и реагирование: служба Центр Интернета вещей отвечает за обнаружение сбоя в зоне доступности. Вам не нужно ничего делать, чтобы инициировать переключение зоны.

• Notification: Майкрософт не уведомляет вас, когда зона отключена. Однако вы можете использовать Azure Работоспособность ресурсов для отслеживания работоспособности отдельного ресурса и настроить оповещения Работоспособность ресурсов для уведомления о проблемах. Вы также можете использовать Работоспособность служб Azure для понимания общего состояния службы, включая любые сбои зоны, и настроить оповещения Service Health для уведомления о проблемах.

• Активные запросы: Во время сбоя зоны активные запросы могут быть удалены. Клиенты и устройства должны иметь достаточную логику повторных попыток для обработки временных сбоев.

• Ожидаемая потеря данных: При развертывании Центра Интернета вещей в регионе, поддерживающем избыточность зоны для данных, сбой зоны не должен привести к потере данных.

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

• Traffic rerouting (перенаправление трафика): При развертывании IoT-хаба в регионе, поддерживающем зональную избыточность для вычислительных компонентов, IoT-хаб обнаруживает потерю зоны. Затем все новые запросы автоматически перенаправляются на новый главный экземпляр сервиса в одной из исправных зон доступности.

Восстановление зоны

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

Тестирование на сбои в зоне

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

Устойчивость к сбоям на уровне региона

Центр Интернета вещей — это региональная служба. Если регион становится недоступным, ресурсы Центр Интернета вещей также недоступны. Хотя Центр Интернета вещей поддерживает асинхронную репликацию данных в парном регионе Azure для аварийного восстановления, для подключения устройств не предусмотрена встроенная межрегиональная отказоустойчивость.

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

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

• Подготовка вторичного Центр Интернета вещей в другом регионе Azure.
• Реализация механизма перенаправления конечных точек для направления устройств в альтернативный регион при необходимости. Например, вы можете заранее подготовить каждое устройство в обоих концентраторах и настроить обе строки подключения для устройств, чтобы они могли переключаться между концентраторами при необходимости.

Переключение при отказе, управляемое Майкрософт, к сопряжённому региону

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

Типы аварийного переключения

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

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

• Инициированное Майкрософт переключение при отказе: Если регион потерян, Майкрософт может инициировать переключение при отказе узлов IoT на парный регион. Однако Майкрософт вряд ли будет инициировать переключение на резервный сервер, только после значительной задержки и в зависимости от наличия ресурсов. Переключение на резервный узел ресурсов Центр Интернета вещей может происходить в другое время, чем переключение остальных служб Azure. Этот процесс является параметром по умолчанию и не требует вмешательства от вас.

Требования

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

Соображения

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

Себестоимость

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

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

Настройка репликации и подготовка к переключению на резерв

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

Если ваш центр Интернета вещей находится в регионах Южная Бразилия или Юго-Восточная Азия (Сингапур), вы можете отключить репликацию данных и отказаться от резервного переключения. Дополнительные сведения см. в разделе Об отключении аварийного восстановления (DR).

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

Поведение, когда все регионы работоспособны

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

• Репликация данных между регионами: Данные, включая реестр удостоверений устройств, автоматически реплицируются в парный регион. Репликация выполняется асинхронно, что означает, что в случае сбоя ожидается некоторая потеря данных. Репликация данных между регионами для центров Интернета вещей в неспаренных регионах отсутствует.

• Маршрутизация трафика между регионами: В обычных операциях трафик передается только в основной регион.

Поведение во время сбоя региона

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

• Обнаружение и ответ: Ответственность за обнаружение и реагирование на сбой в основном регионе может отличаться.

  • Переключение при отказе, инициированное клиентом: Вы несете ответственность за обнаружение отказа региона и принятие решения о времени переключения. Для получения дополнительной информации о том, как выполнить переключение, инициированное клиентом, между парными регионами, см. раздел «Ручное переключение для IoT-центра».

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

    • Пользователи могут выполнять две успешные операции переключения на резервный сервер и две успешные операции переключения на основной сервер в день.

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

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

• Активные запросы: Все запросы, которые основной регион обрабатывает во время переключения на резервный узел, скорее всего, будут потеряны. Клиенты должны повторить запросы после завершения переключения на резервный сервер.

• Ожидаемая потеря данных: Для парных регионов данные реплицируются асинхронно в парный регион. В результате ожидаются некоторые потери данных после переключения на резервный ресурс. Этот процесс применяется как к управляемым Майкрософт, так и к управляемым клиентом отказоустойчивостям. В следующей таблице описана цель точки восстановления (RPO) или ожидаемая потеря данных каждого типа данных, которые хранятся в центрах Интернета вещей.

  Тип данных	RPO
  Реестр удостоверений	Потеря данных в течение 0–5 минут
  Данные двойника устройства	Потеря данных в течение 0–5 минут
  Сообщения из облака на устройство 1	Потеря данных в течение 0–5 минут
  Задания родителя 1 и для устройств	Потеря данных в течение 0–5 минут
  Отправка сообщений с устройства в облако	Теряются все непрочитанные сообщения
  Сообщения обратной связи из облака на устройство	Теряются все непрочитанные сообщения

  ¹ Сообщения из облака на устройство и основные задания не восстанавливаются в рамках переключения на резервный сервер по инициативе клиента.

• Ожидаемое время простоя: Ожидаемое время простоя во время переключения региона зависит от вида переключения.

  • Отработка отказа, инициированная клиентом: Следует ожидать примерно 10 минут до 2 часов простоя с момента потери региона до восстановления работоспособности ресурса в парном регионе. Количество устройств, зарегистрированных против экземпляра узла IoT, переключение на резервный сервер влияет на время восстановления. Вы можете ожидать, что время восстановления для концентратора, на котором размещено около 100 000 устройств, составляет около 15 минут.

  • Обеспечиваемый Майкрософт отказ переключения: Ожидается примерно 2–26 часов простоя с момента сбоя региона до момента, когда ресурс станет доступен в парном регионе.

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

  • Для обоих типов отработки отказа полное доменное имя экземпляра Центра Интернета вещей остается неизменным после отработки отказа, что означает, что строка подключения также остается одинаковой. Тем не менее, поскольку базовый IP-адрес изменяется, клиенты должны дождаться обновления записей системы доменных имен (DNS), прежде чем получить доступ к узлу Интернета вещей после переключения.

    Это важно

    Пакеты SDK Центр Интернета вещей не кэшируют IP-адрес Центр Интернета вещей. Пользовательский код, взаимодействующий с пакетами SDK, также не должен кэшировать IP-адрес центра Интернета вещей.

    Из-за этих факторов время выполнения операций времени выполнения для экземпляра Центра Интернета вещей, чтобы стать полностью функциональным после процесса переключения на резервный экземпляр, можно выразить с помощью следующей функции:

    Время восстановления = RTO [10 минут до 2 часов для отработки отказа, инициированного клиентом, или от 2 до 26 часов для отработки отказа, инициированного Майкрософт] + задержка распространения DNS + время, которое клиентское приложение принимает для обновления любого кэшированного IP-адреса Центра Интернета вещей

• Traffic rerouting: Во время процесса переключения на резервный узел Центр Интернета вещей обновляет записи DNS для указания на резервный регион. Все последующие запросы отправляются в парный регион.

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

Необходимая конфигурация после переключения на резервный узел

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

• Центры событий Azure: Имя и конечная точка, совместимые с Event Hubs, вашего встроенного узла событий IoT изменяются после отработки отказа. Это изменение происходит, так как клиент Центров событий не имеет видимости событий Центр Интернета вещей.

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

  Если вы используете имя и конечную точку, совместимые с Центрами событий, непосредственно в приложении, необходимо получить новую конечную точку, совместимую с Центрами событий после переключения на резервную схему для продолжения работы. Чтобы получить конечную точку и имя, можно использовать портал Azure или пакет SDK .NET:

  • Портал Azure: Дополнительные сведения о том, как использовать портал для получения конечной точки, совместимой с Центрами событий, и имени, совместимого с Центрами событий, см. в статье Подключение к встроенной конечной точке.

  • .NET SDK: Чтобы использовать строку подключения центра Интернета вещей для повторного извлечения конечной точки, совместимой с Центрами событий, используйте пример кода . В этом примере кода используется строка подключения, чтобы получить новую конечную точку Центров событий и повторно установить подключение. Необходимо установить Visual Studio.

• Функции Azure и Azure Stream Analytics: Если вы используете Функции Azure или Stream Analytics для подключения к встроенной конечной точке событий, необходимо обновить конечную точку Центров событий, к которым подключается функция или задание, после того же процесса, описанного в предыдущей точке маркера. Затем выполните действие перезапуска, так как любые смещения потока событий становятся недействительными после переключения при отказе.

• служба хранилища Azure: При маршрутизации в служба хранилища Azure сначала перечисляйте блобы или файлы. Затем выполните итерацию по ним, чтобы убедиться, что все большие двоичные объекты или файлы считываются без необходимости секционирования. Диапазон разделов может измениться во время переключения на отказоустойчивую систему, инициированного Майкрософт, или переключения на отказоустойчивую систему, инициированного клиентом. Вы можете использовать API List Blobs для перечисления списка блобов или API List Azure Data Lake Storage для списка файлов. Дополнительные сведения см. в разделе служба хранилища Azure как конечная точка маршрутизации.

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

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

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

Проверка сбоев в регионе

Чтобы имитировать сбой во время простоя региона, можно вручную перевести IoT-хаб на резервный режим. Однако, так как переключение при отказе в регионе приводит к простою и потере данных, тестовые переключения при отказе следует проводить только в средах, не предназначенных для эксплуатации. Дополнительные сведения см. в разделе "Поведение во время сбоя региона". Рассмотрите возможность настройки экземпляра Центр Интернета вещей для периодического инициирования планового режима отказоустойчивости. Периодическое тестирование может помочь вам обеспечить уверенность в том, что вы сможете эффективно восстанавливать и управлять комплексными решениями при возникновении реальной аварии.

Индивидуальные решения для нескольких регионов для повышения устойчивости

Возможности отказоустойчивости между регионами Центр Интернета вещей не подходят для следующих сценариев:

• Центр Интернета вещей находится в неспаренном регионе.

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

• Необходимо переключиться на регион, который не является парой вашего основного региона.

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

• Ожидаемое время простоя: Этот подход имеет менее одной минуты простоя, но может быть сложным для реализации.

• Ожидаемая потеря данных: Объем потери данных зависит от используемых хранилищ данных и способа настройки георепликации между ними.

• Стоить: Этот подход требует подготовки по крайней мере одного дополнительного центра Интернета вещей, что повышает общую стоимость.

На общем уровне для реализации региональной модели отработки отказа с помощью Центр Интернета вещей нужно предпринять следующие шаги:

• Вторичная логика маршрутизации устройств и Центра Интернета вещей: Если служба в основном регионе нарушена, устройства должны начать подключаться к вашему дополнительному региону. Из-за того, что большинство служб зависят от состояния, администраторы решений обычно вручную инициируют процесс переключения между регионами. Лучший способ обмена данными новой конечной точки с устройствами при сохранении контроля над процессом заключается в том, чтобы они регулярно проверяли службу поддержки для текущей активной конечной точки. Служба concierge может быть веб-приложением, которое реплицируется и поддерживается с помощью методов перенаправления DNS, таких как Диспетчер трафика Azure.

  Замечание

  Диспетчер трафика не имеет встроенной поддержки для Центр Интернета вещей. Вы можете настроить пользовательские конечные точки менеджера трафика для каждого IoT-узла. Настройте пробу работоспособности диспетчера трафика для использования конечной точки Центра Интернета вещей.

• Репликация реестра удостоверений: Для удобства использования дополнительный центр Интернета вещей должен содержать все удостоверения устройств, которые могут подключаться к решению. Решение должно хранить геореплицированные резервные копии удостоверений устройств и отправлять их во вторичный центр Интернета вещей перед переключением активной точки подключения устройств. Функции экспорта идентификации устройства Центр Интернета вещей полезны в этом контексте. Дополнительные сведения см. в статье Сведения о реестре удостоверений в центре Интернета вещей.

• Логика слияния: Когда основной регион снова становится доступным, все состояние и данные, созданные в дополнительном регионе, должны быть перенесены обратно в основной регион. Эти состояния и данные главным образом относятся к идентификациям устройств и метаданным приложений, которые необходимо объединить с основным Центром Интернета вещей и любыми другими специализированными хранилищами приложений в основном регионе.

  Чтобы упростить этот шаг, используйте идемпотентные операции. Идемпотентные операции минимизируют побочные эффекты от распределения событий при конечной согласованности и от дублирования или доставки событий в неправильном порядке. Кроме того, логика приложения должна быть разработана для того, чтобы терпеть потенциальные несоответствия или немного устаревшее состояние. Этот сценарий может произойти из-за дополнительного времени, необходимого для восстановления системы, учитывая RPO (Целевой Показатель Восстановления).

Резервное копирование и восстановление

Служба Центр Интернета вещей включает операции массового экспорта, которые позволяют экспортировать весь реестр удостоверений IoT hub. Эти данные передаются в контейнер BLOB-объектов служба хранилища Azure с помощью подписи общего доступа. Этот метод позволяет создавать надежные резервные копии данных устройства в BLOB-контейнере, которым вы управляете. Дополнительные сведения см. в разделе Импорт и экспорт идентификаторов устройств Центр Интернета вещей пакетно.

Вы также можете экспортировать существующий шаблон центра Интернета вещей Azure Resource Manager (шаблон ARM), чтобы создать резервную копию конфигурации Центра Интернета вещей. Дополнительные сведения см. в разделе "Перенос центра Интернета вещей вручную" с помощью шаблона ARM.

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

Устойчивость к обслуживанию служб

Майкрософт регулярно применяет обновления служб и выполняет другое обслуживание. Платформа Azure автоматически обрабатывает эти действия, обеспечивая простое и прозрачное обслуживание. Во время мероприятий технического обслуживания простой не ожидается, если только вас не предупредили через Работоспособность служб Azure о плановом обслуживании.

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Дополнительные сведения см. в разделе SLAs для онлайн-сервисов.

Связанный контент

• Масштабируемость решения Интернета вещей, высокий уровень доступности и аварийное восстановление
• Надежность в реестре устройств Azure
• Надежность в Azure