Архитектурные подходы для Интернета вещей в мультитенантном решении

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

Ключевые рекомендации и требования

Эти рекомендации и требования представлены в том порядке, в котором они обычно задают приоритеты для проектирования решения.

Система управления и соответствие требованиям

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

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

Масштабировать

Важно спланировать масштаб решения. Масштаб часто рассматривается в следующих трех измерениях:

• Количество устройств: все службы управления устройствами Azure — Azure IoT Central, Центр Интернета вещей Azure служба подготовки устройств (DPS) и Центр Интернета вещей Azure — имеют ограничения на количество устройств, поддерживаемых в одном экземпляре.

  Совет

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

• Пропускная способность устройства: разные устройства, даже в одном решении, могут иметь разные требования к пропускной способности. "Пропускная способность" в этом контексте относится как к количеству сообщений за период времени, так и к размеру сообщений. Например, в решении smart-building термостаты, скорее всего, будут сообщать данные с меньшей частотой, чем лифты, в то время как в решении для подключенного транспортного средства запись сообщений данных камеры автомобиля, скорее всего, будет больше, чем сообщения телеметрии навигации. Если сообщения регулируются относительно частоты, может потребоваться увеличить масштаб до большего числа экземпляров конкретной службы, но если они регулируются относительно размера, может потребоваться увеличить масштаб до более крупных экземпляров конкретной службы.

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

Повышение производительности и надежности

Изоляция арендаторов

Полностью общие решения могут иметь шумных соседей. В случаях Центр Интернета вещей и IoT Central это может привести к кодам ответов HTTP 429 ("слишком много запросов"), которые являются жесткими сбоями, которые могут вызвать каскадный эффект. Дополнительные сведения см. в разделе "Квоты" и "Регулирование".

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

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

Хранилище данных, запрос, использование и хранение

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

Безопасность

Решения Интернета вещей часто учитывают безопасность на нескольких уровнях, особенно в решениях, развернутых в облачно измененной архитектуре Purdue Enterprise Reference Architecture или Industry 4.0 . Подход к проектированию, выбранный из приведенных ниже, будет влиять на то, какие сетевые слои и границы существуют; После выбора физической структуры можно выбрать реализацию безопасности. Средства, которые могут использоваться в любом подходе, включают:

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

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

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

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

Подходы к рассмотрению

Все рекомендации, которые вы обычно делаете в архитектуре Интернета вещей, для всех основных компонентов (таких как управление, прием, обработка, хранение, безопасность и т. д.), являются все варианты, которые по-прежнему необходимо сделать при реализации мультитенантного решения. Основное различие заключается в том, как упорядочивать и использовать компоненты для поддержки мультитенантности. Например, распространенные точки принятия решений для хранилища могут быть решены, следует ли использовать SQL Server или Azure Data Explorer, или, возможно, на уровне приема и управления, вы можете выбрать между Центр Интернета вещей и IoT Central.

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

Одним из крупнейших точек принятия решений, которые необходимо принять, в пространстве Интернета вещей, является выбор между подходами application-platform-as-service (aPaaS) и platform-as-service (PaaS). Дополнительные сведения см. в статье "Сравнение подходов к интернету вещей(IoT) (PaaS и aPaaS)".

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

Основные понятия и рекомендации по решениям aPaaS

Обычное решение aPaaS с помощью Azure IoT Central в качестве ядра решения может использовать следующие службы Azure PaaS и aPaaS:

• Центры событий Azure в качестве кроссплатформенного, корпоративного уровня обмена сообщениями и подсистемы потока данных.
• Azure Logic Apps — это платформа интеграции как услуга или iPaaS.
• Azure Data Explorer в качестве платформы аналитики данных.
• Power BI в качестве платформы визуализации и отчетов.

На предыдущей схеме клиенты совместно используют среду IoT Central, Azure Data Explorer, Power BI и Azure Logic Apps.

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

Важно понимать, что, поскольку IoT Central является предложением aPaaS, существуют определенные решения, которые находятся за пределами контроля реализации. К этим решениям относятся:

• IoT Central использует идентификатор Microsoft Entra в качестве поставщика удостоверений.
• Развертывание IoT Central достигается с помощью операций управления и плоскости данных, которые объединяют декларативные документы с императивным кодом.
• В мультитенантном шаблоне максимальное ограничение узла IoT Central (которое применяется как к родителям, так и к листьям) и максимальной глубине дерева может привести к тому, что поставщик услуг может иметь несколько экземпляров IoT Central. В этом случае следует учесть шаблон метки развертывания.
• IoT Central накладывает ограничения вызовов API, которые могут повлиять на большие реализации.

Основные понятия и рекомендации по решениям PaaS

Подход на основе PaaS может использовать следующие службы Azure:

• Центр Интернета вещей Azure в качестве основной платформы конфигурации устройства и коммуникации.
• Служба подготовки устройств Интернета вещей Azure в качестве платформы развертывания устройств и начальной конфигурации.
• Azure Data Explorer для хранения и анализа данных временных рядов теплых и холодных путей с устройств Интернета вещей.
• Azure Stream Analytics для анализа данных горячего пути с устройств Интернета вещей.
• Azure IoT Edge для запуска искусственного интеллекта (ИИ), сторонних служб или собственной бизнес-логики на устройствах IoT Edge.

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

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

Шаблоны корневой архитектуры

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

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

Простой SaaS

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

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

Обмен данными с системами за пределами IoT Central, например для долгосрочного анализа данных, на холодном пути или подключении к бизнес-операциям, осуществляется с помощью других предложений Microsoft PaaS и aPaaS. К этим дополнительным предложениям могут относиться следующие службы:

• Центры событий Azure как кроссплатформенный, корпоративный модуль обмена сообщениями и потока данных.
• Azure Logic Apps — это платформа интеграции как услуга или iPaaS.
• Azure Data Explorer в качестве платформы аналитики данных.
• Power BI в качестве платформы визуализации и отчетов.

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

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

Преимущества:

• Проще управлять и работать относительно других подходов, представленных здесь.

Риски:

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

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

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

Горизонтальное решение SaaS

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

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

Пример горизонтального saaS

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

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

Преимущества:

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

Риски:

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

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

Базы данных

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

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

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

Управление устройствами, обмен данными и администрирование

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

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

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

Потоковая обработка

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

Автоматизировано с одним клиентом

Автоматизированный подход с одним клиентом основан на аналогичном процессе принятия решений и проектировании корпоративного решения.

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

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

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

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

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

Автоматизированный подход с одним клиентом аналогичен простой модели SaaS aPaaS. Основное различие между двумя моделями заключается в том, что в автоматизированном подходе с одним клиентом развертывается отдельный экземпляр IoT Central для каждого клиента, а в простой модели SaaS с моделью APaaS развертывается общий экземпляр IoT Central с несколькими организациями IoT Central.

Преимущества:

• Относительно легко управлять и работать.
• Изоляция клиента по сути гарантируется.

Риски:

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

Увеличение масштаба SaaS

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

• Майкл С. Зазаревский | Старший инженер по работе с клиентами, FastTrack для Azure
• Дэвид Крук | Главный инженер клиента, FastTrack для Azure

Другие участники:

• Джон Даунс | Главный инженер программного обеспечения
• Арсен Владимирский | Главный инженер клиента, FastTrack для Azure

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

• Ознакомьтесь с рекомендациями по мультитенантности и Azure Cosmos DB.
• Узнайте о горячих, теплых и холодных путях данных с помощью Интернета вещей в Azure.
• См. эталонные архитектуры Azure IoT.
• Ознакомьтесь с документацией по масштабированию решений Интернета вещей с метками развертывания.