Высокая доступность и аварийное восстановление Центра Интернета вещей
Первый шаг, который архитекторы, разработчики и владельцы предприятий должны выполнить для реализации отказоустойчивого решения для Интернета вещей, — это определить цели доступности для создаваемых решений. Эти цели можно определить преимущественно на основе конкретных бизнес-целей для каждого сценария. В этом контексте в статье Проектирование устойчивых приложений для Azure описывается общая платформа, которая поможет вам понять непрерывность бизнес-процессов и аварийного восстановления. Статья об аварийном восстановлении и высокой доступности для приложений Azure представляет собой руководство об архитектуре со стратегиями, позволяющими обеспечить высокий уровень доступности и возможности аварийного восстановления для приложений Azure.
В этой статье рассматриваются функции обеспечения высокого уровня доступности и аварийного восстановления, предлагаемые конкретно службой Центра Интернета вещей. Особое внимание в этой статье уделено таким областям:
- Обеспечение высокого уровня доступности внутри региона
- Обеспечение возможности аварийного восстановления между регионами
- обеспечение высокого уровня доступности между регионами.
В зависимости от целей простоя, которые вы определяете для решений Интернета вещей, следует определить, какие из вариантов, описанных в этой статье, лучше всего подходят для ваших бизнес-целей. Включение любой из этих альтернатив обеспечения высокого уровня доступности и аварийного восстановления в решение для Интернета вещей требует тщательной оценки компромиссов между:
- требуемым уровнем отказоустойчивости;
- сложностью реализации и обслуживания;
- влиянием расходов COGS.
Обеспечение высокого уровня доступности внутри региона
Служба "Центр Интернета вещей" обеспечивает высокую доступность внутри регионов с помощью реализации избыточности почти во всех слоях службы. Соглашение об уровне обслуживания, опубликованное службой "Центр Интернета вещей" достигается за счет использования этой избыточности. Дополнительная работа не требуется разработчикам решения Интернета вещей, чтобы воспользоваться преимуществами этих функций высокой доступности. Хотя Центр Интернета вещей предлагает достаточно высокую гарантию уровня доступности, как и в случае с любой распределенной вычислительной платформой можно ожидать временные сбои. Если вы только начинаете переносить свои решения в облако из локального решения, вам необходимо перейти с оптимизации "среднего времени безотказной работы" на оптимизацию "среднего времени восстановления". Другими словами, временные сбои считаются нормальными при работе с облаком в наборе. Соответствующие шаблоны повторных попыток должны быть встроены в компоненты, взаимодействующие с облачным приложением, чтобы справиться с временными сбоями.
Зоны доступности
поддерживается Центр Интернета вещейЗоны доступности Azure. Зона доступности обеспечивает высокий уровень доступности и защищает приложения и данные от сбоев в центрах обработки данных. Регион с поддержкой зоны доступности состоит из трех зон, поддерживающих этот регион. Каждая зона предоставляет один или несколько центров обработки данных, каждый из которых находится в уникальном физическом расположении с независимым питанием, охлаждением и сетью. Эта конфигурация обеспечивает репликацию и избыточность в регионе.
Зоны доступности обеспечивают два преимущества: устойчивость данных и более плавное развертывание.
Устойчивость данных происходит от замены базовых служб хранилища на хранилище, поддерживаемого зонами доступности. Устойчивость данных важна для решений Интернета вещей, так как эти решения часто работают в сложных, динамических и неопределенных средах, где сбои или нарушения могут иметь значительные последствия. Независимо от того, поддерживает ли решение Интернета вещей производственный этаж, розничную или ресторанную среду, системы здравоохранения или инфраструктуру, доступность и качество данных необходимо для восстановления после сбоев и обеспечения надежных и согласованных служб.
Более плавные развертывания приходят от замены базового оборудования центра обработки данных новым оборудованием, поддерживающим зоны доступности. Эти улучшения оборудования минимизировали влияние клиентов на отключение устройства и повторное подключение, а также другие время простоя, связанного с развертыванием. Команда разработчиков Центр Интернета вещей развертывает несколько обновлений в каждом Центре Интернета вещей каждый месяц по соображениям безопасности и для улучшения функций. Оборудование, поддерживаемое зонами доступности, разделено на 15 доменов обновлений, чтобы каждое обновление было более гладко, с минимальным воздействием на рабочие процессы. Дополнительные сведения о доменах обновления см. в разделе "Группы доступности".
Поддержка зоны доступности для Центр Интернета вещей включена автоматически для новых ресурсов Центр Интернета вещей, созданных в следующих регионах Azure:
| Область/регион | Устойчивость данных | Более гладкие развертывания |
|---|---|---|
| Восточная Австралия | 
|
|
| Южная Бразилия |
|
|
| Центральная Канада |
|
|
| Центральная Индия | 
|
|
| Центральная часть США |
|
|
| Восточная часть США |
|
|
| Центральная Франция |
|
|
| Центрально-Западная Германия |
|
|
| Восточная Япония |
|
|
| Республика Корея, центральный регион |
|
|
| Северная Европа |
|
|
| Восточная Норвегия; |
|
|
| Центральный Катар |
|
|
| Центральная часть южных регионов США |
|
|
| Юго-Восточная Азия |
|
|
| южная часть Соединенного Королевства |
|
|
| Западная Европа |
|
|
| западная часть США 2 |
|
|
| Западная часть США — 3 |
|
|
Обеспечение возможности аварийного восстановления между регионами
Изредка могут случаться ситуации, когда в центре обработки данных наблюдаются длительные сбои из-за сбоев питания или других сбоев, связанных с физическими ресурсами. Такие события редки, во время которых возможности высокой доступности внутри региона, описанные ранее, могут не всегда помочь. Центр Интернета вещей предоставляет несколько решений для восстановления после таких длительных сбоев.
Вариантами восстановления, которые доступны клиентам в такой ситуации, являются отработка отказа, инициируемая Майкрософт, и переход на другой ресурс вручную. Основное различие между ними состоит в том, что первый процесс инициирует корпорация Майкрософт, а второй — пользователь. Также переход на другой ресурс вручную обеспечивает меньшее целевое время восстановления (RTO) по сравнению с вариантом восстановления, инициируемым корпорацией Майкрософт. В следующих разделах рассматриваются определенные ОСРВ, предлагаемые с каждым вариантом. При использовании любого из этих вариантов для отработки отказа Центра Интернета вещей из его основного региона все функции этого центра работают в соответствующем географически связанном регионе Azure.
Оба этих варианта отработки отказа предлагают следующие целевые точки восстановления (RPO):
| Тип данных | Целевые точки восстановления (RPO) |
|---|---|
| Реестр удостоверений | Потеря 0–5 мин данных |
| Данные двойника устройства | Потеря 0–5 мин данных |
| Получение сообщений из облака на устройство 1 | Потеря 0–5 мин данных |
| Родительское1 устройство и его задания | Потеря 0–5 мин данных |
| Отправка сообщений с устройства в облако | Теряются все непрочитанные сообщения |
| Сообщения обратной связи из облака на устройство | Теряются все непрочитанные сообщения |
1Сообщения из облака на устройство и родительские задания не восстанавливаются в рамках отработки отказа вручную.
После завершения операции отработки отказа Центра Интернета вещей все операции устройства и внутренних приложений будут выполняться без активации каких-либо действий вручную. Это означает, что сообщения, отправляемые с устройства в облако, должны продолжать работать, и весь реестр устройства не изменяется. События, генерируемые через Сетку событий, можно использовать с помощью тех же ранее настроенных подписок, так как эти подписки остаются доступными. Для пользовательских конечных точек дополнительная обработка не требуется.
Внимание
- Имя и конечная точка, совместимые с Центрами событий, Центр Интернета вещей после отработки отказа изменяются встроенные конечные точки событий. При получении сообщений телеметрии из встроенной конечной точки с помощью клиента центров событий или узла обработчика событий следует использовать центр Интернета вещей строка подключения для установления подключения. Это гарантирует, что ваши серверные приложения продолжат работу без активации (после отработки отказа) каких-либо действий вручную. Если вы используете имя, совместимое с концентратором событий, а также конечную точку непосредственно в приложении, то для продолжения операций после отработки отказа получить новую конечную точку, совместимую с концентратором событий. Дополнительные сведения см. в подразделе Переход на другой ресурс вручную и концентратор событий.
- Если вы используете Функции Azure или Azure Stream Analytics для подключения к встроенной конечной точки событий, может потребоваться выполнить перезапуск. Это связано с тем, что во время отработки отказа предыдущие смещения становятся недействительными.
- При маршрутизации в хранилище рекомендуется включить BLOB-объекты или файлы в список, а затем выполнять по ним итерацию, чтобы обеспечить считывание всех BLOB-объектов или файлов независимо от раздела. Диапазон разделов может измениться в процессе инициированной Майкрософт отработки отказа или при переходе на другой ресурс вручную. Вы можете использовать API перечисления BLOB-объектов или API перечисления ADLS 2-го поколения для составления списка файлов. Дополнительные сведения см. в разделе Служба хранилища Azure в качестве конечной точки маршрутизации.
Корпорация Майкрософт инициирует отработку отказа
Отработка отказа, инициированная корпорацией Майкрософт, выполняется в редких ситуациях, чтобы выполнить отработку отказа всех центров Интернета вещей из затронутого региона в соответствующий геопарированный регион. Это процесс по умолчанию, и он не требует действий пользователя. Майкрософт оставляет за собой право определять, в каких случаях использовать этот параметр. Отработка отказа центра пользователя с помощью этого механизма не требует согласия этого пользователя. Целевое время восстановления (RTO) отработки отказа, инициируемого корпорацией Майкрософт, составляет 2–26 часов.
Большое время RTO объясняется тем, что Майкрософт нужно выполнить отработку отказа от имени всех затронутых пользователей в этом регионе. Если вы используете менее критическое решение Интернета вещей, которое может поддерживать время простоя примерно в день, это нормально для вас, чтобы принять зависимость от этого варианта, чтобы удовлетворить общие цели аварийного восстановления для решения Интернета вещей. Общее время готовности к выполнению операций в среде выполнения после запуска соответствующего процесса описывается в разделе, посвященном времени восстановления.
Только пользователи, развертывающие центры Интернета вещей, в регионах Южной Бразилии и Юго-Восточной Азии (Сингапур) могут отказаться от этой функции. Дополнительные сведения см. в разделе Отключение аварийного восстановления.
Примечание.
Центр Интернета вещей Azure не хранит и не обрабатывает данные клиентов за пределами географического региона, в котором развертывается экземпляр службы. Дополнительные сведения см. в статье Репликация между регионами в Azure.
Переход на другой ресурс вручную
Если время RTO, которое обеспечивает отработка отказа, инициируемая Майкрософт, не подходит для целей доступности вашей организации, вы можете выполнить переход на другой ресурс вручную, чтобы самостоятельно запустить этот процесс. При использовании этого параметра время RTO может составлять от 10 минут до пары часов. В настоящее время RTO является функцией ряда устройств, зарегистрированных в экземпляре Центра Интернета вещей, к которому применяется отработка отказа. Для центра, в котором размещается примерно 100 000 устройств, время RTO будет приблизительно 15 минут. Общее время готовности к выполнению операций в среде выполнения после запуска соответствующего процесса описывается в разделе, посвященном времени восстановления.
Параметр перехода на другой ресурс вручную всегда можно использовать независимо от наличия простоя в основном регионе. Таким образом, этот параметр потенциально можно использовать для выполнения запланированных отработок отказа. Одним из примеров использования запланированных отработок отказа является выполнение тестовых отработок отказа. Тем не менее запланированная отработка отказа является причиной простоя в центре в течение времени, определенного в соответствии со временем RTO этого параметра, а также приводит к потере данных, как определено в таблице RPO выше. Вы можете настроить тестовый экземпляр Центра Интернета вещей для периодического запуска параметра запланированной отработки отказа, чтобы быть уверенными в том, что во время реального сбоя комплексные решения будут настроены и готовы к запуску.
Функция перехода на другой ресурс вручную предоставляется клиентам бесплатно для их центров Интернета вещей, созданных после 18 мая 2017 года.
Пошаговые инструкции см. в разделе Выполнение перехода на другой ресурс вручную для центра Интернета вещей
Отработка отказа вручную и центры событий
Имя и конечная точка центров событий, совместимые с центрами событий, и конечная точка Центр Интернета вещей после отработки отказа вручную. Это связано с тем, что клиент Центров событий не имеет видимости Центр Интернета вещей событий. Это справедливо и для других облачных клиентов, например клиентов служб "Функции" и Azure Stream Analytics. Чтобы получить конечную точку и имя, можно использовать портал Azure или пакет SDK для .NET.
Использование портала
Дополнительные сведения об использовании портала для получения конечной точки, совместимой с Концентратором событий, и имени, совместимого с Концентратором событий, см. в статье "Подключение к встроенной конечной точке".
Использование пакета SDK для .NET
Чтобы использовать Центр Интернета вещей строка подключения для повторного извлечения конечной точки, совместимой с Центрами событий, используйте пример, расположенный по адресуhttps://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubs. В примере кода используется строка подключения для получения новой конечной точки Центров событий и повторной установки подключения. Необходимо установить Visual Studio.
Выполнение тестовой детализации
Тестовые детализации не должны выполняться в центрах Интернета вещей, которые используются в рабочих средах.
Не используйте переход на другой ресурс вручную для переноса центра Интернета вещей в другой регион.
Не нужно использовать переход на другой ресурс вручную как механизм для окончательной миграции центра между географически связанными регионами Azure. Предположим, что устройства расположены ближе всего к основному региону концентратора, задержка операций, выполняемых в Центре Интернета вещей, увеличится, когда концентратор отработки отказа в дополнительный регион.
Восстановление размещения
Вы можете вернуться к старому основному региону, активировав действие отработки отказа во второй раз. Если первоначальная операция отработки отказа была выполнена для восстановления после длительного сбоя в исходном основном регионе, мы рекомендовали восстановить размещение центра в исходном расположении после его восстановления после сбоя.
Внимание
- Пользователям разрешается выполнять только 2 успешные отработки отказа и 2 успешные операции восстановления размещения в день.
- Нельзя повторно выполнить прежнюю отработку отказа или операцию восстановления размещения. Необходимо подождать 1 час между этими операциями.
Время восстановления
Хотя полное доменное имя (и, следовательно, строка подключения) экземпляра Центра Интернета вещей остается неизменным после отработки отказа, базовый IP-адрес изменяется. Время выполнения операций среды выполнения для экземпляра Центра Интернета вещей, чтобы стать полностью операционным после процесса отработки отказа, можно выразить с помощью следующей функции:
Время восстановления = RTO [от 10 мин до 2 ч для перехода на другой ресурс вручную | от 2 до 26 часов для отработки отказа, инициируемой корпорацией Майкрософт] + задержка распространения DNS + время, затраченное приложением клиента для обновления любого кэшированного IP-адреса Центра Интернета вещей.
Внимание
Пакеты SDK Интернета вещей не кэшируют IP-адрес Центра Интернета вещей. Лучше, если код пользователя, взаимодействующий с пакетами SDK, не будет кэшировать IP-адрес Центра Интернета вещей.
Отключение аварийного восстановления
Центр Интернета вещей обеспечивает отработку отказа, инициируемую Майкрософт, и ручную отработку отказа путем репликации данных в парный регион для каждого центра Интернета вещей. В некоторых регионах можно избежать репликации данных за пределами региона, отключив аварийное восстановление при создании центра Интернета вещей. Эту функцию поддерживают следующие регионы:
- Южная Бразилия; парный регион, центрально-южная часть США.
- Юго-Восточная Азия (Сингапур); парный регион, Восточная Азия (Гонконг САР).
Чтобы отключить аварийное восстановление в поддерживаемых регионах, при создании центра Интернета вещей отмените выбор параметра Включено аварийное восстановление:
Вы также можете отключить аварийное восстановление при создании центра Интернета вещей с помощью шаблона ARM.
Возможность отработки отказа не будет доступна, если отключить аварийное восстановление для Центра Интернета вещей.
Вы можете отключить аварийное восстановление, чтобы избежать репликации данных за пределами парного региона в Южной Бразилии или Юго-Восточной Азии при создании центра Интернета вещей. Если вы хотите настроить существующий центр Интернета вещей для отключения аварийного восстановления, нужно создать центр Интернета вещей с отключенным аварийным восстановлением и вручную перенести существующий центр Интернета вещей. Инструкции см. в разделе "Как перенести центр Интернета вещей".
Обеспечение высокой доступности между регионами
Если время RTO, которое обеспечивается отработкой отказа, инициируемой корпорацией Майкрософт, или переходом на другой ресурс вручную, не подходит для целей доступности вашей организации, вы можете реализовать автоматический механизм отработки отказа между регионами для каждого устройства. Полное освещение топологий развертывания в решениях Интернета вещей выходит за рамки этой статьи. В этой статье рассматривается модель регионального развертывания отработки отказа для обеспечения высокой доступности и аварийного восстановления.
В модели региональной отработки отказа серверная часть решения запускается в первую очередь в центре обработки данных в одном расположении. Дополнительные Центр Интернета вещей и серверная часть развертываются в другом расположении центра обработки данных. Если в Центре Интернета вещей в основном регионе произойдет сбой или сетевое подключение устройства к основному региону по какой-то причине будет нарушено, устройства будут использовать дополнительную конечную точку службы. Доступность решения можно повысить, реализовав модель отработки отказа между регионами, а не в пределах одного региона.
Если говорить в общем, то чтобы реализовать модель с отработкой отказа между регионами, необходимо следующее:
Дополнительный Центр Интернета вещей и логика маршрутизации устройств. В случае нарушения работы службы в основном регионе устройства должны подключаться к дополнительному региону. Учитывая, что состояние большинства задействованных служб отслеживается, чаще всего процесс отработки отказа между регионами активируют администраторы решений. Лучший способ сообщить устройствам новую конечную точку и сохранить контроль над процессом — заставить устройства регулярно получать из дежурной службы текущую активную конечную точку. Дежурной службой может быть простое реплицируемое веб-приложение, доступность которого обеспечивается посредством перенаправления DNS-трафика (например, с помощью диспетчера трафика Azure).
Примечание.
Служба "Центр Интернета вещей" не является поддерживаемым типом конечной точки в диспетчере трафика Azure. Мы рекомендуем интегрировать предложенную дежурную службу с диспетчером трафика Azure путем реализации API пробы работоспособности конечной точки.
Репликация реестра удостоверений. Дополнительный Центр Интернета вещей будет работоспособен только в том случае, если в нем будут все удостоверения устройств и эти удостоверения смогут подключаться к решению. Решение должно хранить геореплицированные резервные копии удостоверений устройств и передавать их в дополнительный центр IoT до перевода устройств на другую конечную точку. В этом случае вам пригодится функция Центра Интернета вещей для экспорта удостоверений устройств. Дополнительные сведения см. в разделе, посвященном реестру удостоверений, руководства разработчика для Центра Интернета вещей.
Логика объединения. Когда основной регион снова станет доступным, все состояния и данные, которые были созданы в дополнительном регионе, необходимо перенести обратно в основной. Эти состояния и данные главным образом относятся к удостоверениям устройств и метаданным приложений, которые необходимо добавить в основной Центр Интернета вещей и другие хранилища приложений в основном регионе.
Чтобы упростить эту процедуру, следует использовать идемпотентные операции. Они сводят к минимуму количество побочных эффектов от итогового согласованного распределения событий и от дублирования данных или беспорядочной доставки событий. Кроме того, логику приложения необходимо спроектировать таким образом, чтобы потенциальные несоответствия или незначительно устаревшие состояния считались допустимыми. Эта ситуация может произойти из-за дополнительного времени, необходимого для лечения системы на основе целей точки восстановления (RPO).
Выбор правильного варианта обеспечения высокого уровня доступности и аварийного восстановления
Вот общие сведения о вариантах обеспечения высокого уровня доступности и аварийного восстановления, которые можно использовать в качестве справки, чтобы выбрать вариант, подходящий для вашего решения.
| Вариант обеспечения высокого уровня доступности и аварийного восстановления | RTO | RPO | Требуются действия вручную? | Сложность реализации | Влияние на затраты |
|---|---|---|---|---|---|
| Корпорация Майкрософт инициирует отработку отказа | 2–26 часов | См. таблицу RPO выше | No | нет | нет |
| Переход на другой ресурс вручную | От 10 мин до 2 ч | См. таблицу RPO выше | Да | Очень низкая. Необходимо просто запустить эту операцию на портале. | нет |
| Обеспечение высокого уровня доступности между регионами | < 1 мин | Зависит от частоты репликации пользовательского решения обеспечения высокого уровня доступности | No | Высокая | > 1-кратной стоимости 1 центра Интернета вещей |