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

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

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

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

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

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

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

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

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

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

  Совет

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

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

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

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

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

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

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

Полностью общие решения могут иметь шумных соседей. В случаях IoT Hub и 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 Firewall или устройство брандмауэра стороннего производителя, которое следует учитывать для изоляции сетевых слоев и мониторинга сетевого трафика. Точный выбор подхода определяет, где рабочие нагрузки имеют сетевую изоляцию и общую сеть, как описано далее в этой статье.

• Azure IoT Edge.

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

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

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

• Можно выбрать использование SQL Server или Azure Data Explorer для хранения данных.
• Уровень приема и управления подразумевает выбор между IoT Hub и IoT Central.

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

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

Целевой объект развертывания	Модель аренды	Модель развертывания
Подписка поставщика услуг	Полностью мультитенантный	Простая

Простой подход 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 для каждого клиента.
• В Simple SaaS с моделью PaaS вы развертываете общий экземпляр для нескольких клиентов и создаете организацию IoT Central для каждого клиента.

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

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

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

Риски:

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

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

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

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

Целевой объект развертывания	Модель аренды	Модель развертывания
Подписка поставщика услуг	Горизонтально секционированные	Метка развертывания

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

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

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

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

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

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

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

Риски:

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

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

Базы данных

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

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

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

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

Центр Интернета вещей Azure служба подготовки устройств, Центр Интернета вещей и приложения IoT Central часто развертываются как горизонтально секционированные компоненты. В этом подходе требуется другая служба для перенаправления устройств в соответствующий экземпляр DPS для управления, контроля и телеметрии конкретного клиента. Дополнительные сведения см. в статье Масштабирование решения Интернета вещей 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.