Поделиться через

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

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

Надежность — это общая ответственность между вами и корпорацией Майкрософт. Это руководство позволяет определить, какие варианты надежности соответствуют конкретным бизнес-целям и целям простоя.

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

  • Уровень устойчивости, который требуется
  • сложностью реализации и обслуживания;
  • Стоимость реализации различных вариантов

Дополнительные сведения см. в разделе " Компромиссы надежности".

Временные сбои

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

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

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

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

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

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

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

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

Поддержка регионов

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

Регион Зональная избыточность для данных Избыточность зоны для вычислений
Восточная Австралия Да Да
Бразилия (Юг) Да Да
Центральная Канада Да Да
Центральная Индия Нет Да
Центральная часть США Да Да
Восток США Нет Да
Центральная Франция Да Да
Западно-Центральная Германия Да Да
Восточная Япония Да Да
Центральная Корея Нет Да
Северная Европа Да Да
Восточная Норвегия Нет Да
Центральный Катар Нет Да
Южно-Центральная часть США Нет Да
Юго-Восточная Азия Да Да
Юг Соединённого Королевства Да Да
Западная Европа Нет Да
Западная часть США 2 Да Да
Западная часть США 3 Нет Да

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

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

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

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

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

Нормальная работа

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

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

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

Опыт понижения зоны

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

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

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

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

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

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

Возврат к исходному состоянию

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

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

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

Поддержка нескольких регионов

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

Однако если ресурсы находятся в парном регионе, данные Центра Интернета вещей реплицируются в парном регионе.

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

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

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

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

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

Поддержка регионов

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

Требования

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

Соображения

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

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

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

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

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

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

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

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

Нормальная работа

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

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

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

Опыт региональной недоступности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Это важно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Возврат к исходному состоянию

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

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

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

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

Альтернативные подходы с несколькими регионами

Способности резервирования между регионами Центра IoT не подходят для следующих сценариев:

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

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

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

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

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

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

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

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

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

    Замечание

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

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

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

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

Резервные копии

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

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

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

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

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

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