Пример рабочей нагрузки, описанной ниже, описывает создание имитации, которая выполняется автоматически и оценивает имитированную функцию транспортного средства с помощью конвейера Azure DevOps. Этот конвейер выполняется каждый раз, когда инженер проверка новую версию исходного кода функции или ее среды моделирования.
Архитектура
Скачайте файл Visio для этой архитектуры.
Уровень ввода пользователей
Разработчик будет взаимодействовать только с этим уровнем. Он содержит рабочую станцию разработчика (виртуальную машину Azure в нашей область) и файл спецификации, описывающий среду моделирования.
Уровень оркестрации
"Оркестрация" имеет широкий смысл: некоторые из проблем, описанных словом, тривиально решены; другие гораздо сложнее. Например, проблема "оркестрации" создания, мониторинга и уничтожения контейнеров и виртуальных машин решается многими средствами. Сам API Azure является достаточным "оркестратором" для этого!
Рабочий процесс
Однако важно разбить черный ящик "оркестрации" на меньшие компоненты.
API моделирования. Этот API получает файл спецификации и является точкой входа для управления средами моделирования и имитацией запусков с уровнем оркестрации.
Интерпретатор. Этот компонент интерпретирует файл спецификации в логическую структуру диспетчера моделирования.
Диспетчер моделирования: это компьютер состояния, который преобразует объект среды логического моделирования в требуемые состояния и действия, которые будут использоваться другими компонентами. Это компонент, который активирует сборку, выполнение и слезвание имитации. Он также управляет внутренними зависимостями и режимами сбоя.
Планировщик: этот компонент назначает стандартные блоки ресурсам инфраструктуры и запускает их там. Он учитывает требования к оборудованию и доступу, доступные ресурсы и ограничения ресурсов.
Диспетчер среды. Этот компонент проверяет базовую инфраструктуру и реагирует на проблемы, например, когда узел контейнера выходит из строя.
Network Manager: этот компонент управляет сетями и маршрутизацией для сред моделирования. Каждая среда должна жить в изолированной сетевой среде, при этом изолированные стандартные блоки получают входящие подключения для интерактивности. Этот компонент также будет использоваться для разрешения стандартных блоков в моделировании (например, через внутренний DNS).
Диспетчер доступа: этот компонент отражает авторизацию и проверку подлинности из идентификатора Microsoft Entra в остальную часть системы.
Configuration Manager: этот компонент выступает в качестве постоянного механизма хранения для состояния сред инфраструктуры и моделирования.
Абстракция инфраструктуры. Это уровень абстракции, который преобразует универсальные команды в определенные команды API Azure для контейнеров и виртуальных машин.
диспетчер служба хранилища: этот компонент управляет подготовкой и подключением хранилища для сред моделирования (например, корневых устройств виртуальных машин или подключенных томов контейнера).
Монитор ресурсов. Этот компонент отслеживает использование ресурсов на уровне инфраструктуры в базу данных временных рядов для экспорта в основной мониторинг ADP.
Log Manager: этот компонент объединяет журналы из стандартных блоков для проверки пользователей. Он также экспортирует журналы в ведение журнала ядра ADP.
Уровень оркестрации является основным фокусом этой рабочей нагрузки.
Уровень инфраструктуры моделирования
Этот уровень представляет все выполняемые среды моделирования.
Среда моделирования: сочетание стандартных блоков, определенных файлом определения и параметрами, создается здесь в сетевой изоляции от любых других сред моделирования.
Контракт на стандартный блок: написанный стандарт, определяющий, как все стандартные блоки отправляют выходные данные, ошибки и состояние на уровень оркестрации.
Конвейер стандартных блоков: эта область управляет созданием и хранилищем стандартных блоков.
Репозиторий стандартных блоков: это система хранения и извлечения образов стандартных блоков, таких как реестр контейнеров и (или) коллекция образов Azure.
Фабрика стандартных блоков: конвейер непрерывной интеграции и непрерывного развертывания (CI/CD), который создает образы стандартных блоков с помощью неизменяемых, проверяемых пакетов компонентов (например, dpkg или apt) на языке декларативной конфигурации (например, Chef или Ansible).
уровень служба хранилища
Этот слой может хранить результаты моделирования. Это в первую очередь ответственность за платформу разработки мобильных приложений (MADP) Data Lake workstream, хотя выходные данные должны управляться этой командой.
служба хранилища интерфейс: интерфейс, позволяющий пользователям работать с хранилищем результатов моделирования. Это работает в тесном концерте с или может быть заменено компонентом оркестрации служба хранилища Manager выше.
служба хранилища. Механизм хранения, используемый для сохранения результатов моделирования (например, Хранилище BLOB-объектов Azure или ресурсов служба хранилища дисков Azure).
Компоненты
Виртуальные машины Azure — это предоставляемый по запросу масштабируемый вычислительный ресурс, который обеспечивает гибкость виртуализации без необходимости приобретать и обслуживать физическое оборудование.
Виртуальная сеть Azure — это фундаментальный строительный блок для вашей частной сети в Azure. Azure виртуальная сеть позволяет различным типам ресурсов Azure, таким как Azure Виртуальные машины, безопасно взаимодействовать друг с другом, Интернетом и локальными сетями.
Экземпляры контейнеров Azure предоставляют быстрый и простой способ запуска контейнера в Azure без управления виртуальными машинами и применения службы более высокого уровня.
Реестр контейнеров Azure — это управляемая частная служба реестра Docker, основанная на реестре Docker 2.0 с открытым кодом. Используйте реестры контейнеров Azure с существующими конвейерами разработки и развертывания контейнеров или используйте задачи Реестра контейнеров Azure для создания образов контейнеров в Azure. Создавайте сборки по требованию или полностью автоматизированные сборки с помощью триггеров, таких как принятие исходного кода и обновление базового образа.
Azure Pipelines входит в состав Azure DevOps Services и выполняет автоматизированные сборки, тесты и развертывания. Вы также можете использовать сторонние решения для CI/CD, такие как Jenkins.
Идентификатор Microsoft Entra — это облачная служба управления удостоверениями и доступом, которая проверяет подлинность пользователей, служб и приложений.
Служба хранилища Azure предоставляет устойчивое, высокодоступное и высокомасштабируемое решение облачного хранилища. Оно включает в себя хранилище объектов, файлов, дисков, очередей и таблиц.
Azure Monitor собирает данные телеметрии мониторинга из различных локальных источников и источников Azure. Эта служба агрегирует и сохраняет данные телеметрии в хранилище данных журнала, оптимизированном для затрат и производительности.
Альтернативные варианты
Эта архитектура использует виртуальные машины и контейнеры для развертывания различных средств и служб. В качестве альтернативы можно также использовать Служба Azure Kubernetes (AKS). AKS предоставляет бессерверную платформу Kubernetes со встроенными возможностями CI/CD, а также безопасностью и управлением корпоративного уровня.
Механизм хранения, используемый для сохранения имитации, основан на Хранилище BLOB-объектов Azure или служба хранилища диска Azure. В качестве альтернативы для больших рабочих нагрузок можно также просмотреть крупномасштабные решения для хранения и анализа данных Azure.
Кроме того, рекомендуется использовать Azure Monitor для анализа и оптимизации производительности инфраструктуры, а также для мониторинга и диагностики сетевых проблем без входа в виртуальные машины.
Подробности сценария
Для оценки автономного вождения (AD) инженеры-функции должны имитировать поведение транспортных средств с возможностями AD. Рассмотрим следующий пример сценария вождения:
Тестовый автомобиль автономно управляется на 80 миль /ч в правой полосе на 3-полосе шоссе. Существует грузовик 600 футов впереди вождения в той же полосе и в том же направлении на 55 миль/ч. В средней полосе нет транспортного средства. Дорожные маркеры видны, солнце светит перпендикулярно к транспортному средству, и дорога сухая.
Конечное моделирование поведения транспортного средства с использованием такого сценария называется симуляционным запуском. В приведенном выше сценарии ожидаемое поведение имитированного транспортного средства заключается в том, чтобы комфортно пройти грузовик без возникновения аварии и без нарушения правил дорожного движения. Запустив имитацию для каждой новой версии функции, инженеры-функции AD проверяют, по-прежнему ли новая версия демонстрирует ожидаемое поведение.
Для выполнения моделирования инженеры-функции AD обычно используют набор программных приложений. К ним могут относиться виртуальный тестовый выпуск (VTD), тестирование секций времени (TPT), система разработки Avionics (ADS2) и автомобильные данные и платформы с активацией времени (ADTF), все из которых взаимодействуют друг с другом в соответствии с конкретными конфигурациями для тестирования заданной автономной функции вождения, такой как пилот шоссе. Развертывание этого набора программных средств и их конфигураций на физических и(или) виртуальных машинах (виртуальных машинах) в локальной среде и(или) в облаке называется средой моделирования.
Чтобы убедиться, что результаты теста, созданные каждой выполняемой имитацией, необходимо убедиться, что моделирование начинается в новой среде моделирования, заданной в исходном состоянии.
Каждая команда автономного вождения нуждается в отдельном наборе приложений в их среде моделирования с уникальной конфигурацией. Во многих командах также потребуется несколько разных сред моделирования. Например, чтобы оценить датчик LIDAR, вам потребуется очень высокое разрешение объектного моделирования, но другие водители, дорожные маркировки или другие функции. Несмотря на то, что каждая среда уникальна, существует значительное перекрытие используемых приложений. Например, многие команды используют VTD в нескольких средах моделирования.
Можно запустить имитацию в среде моделирования, состоящей из многократно используемых, инкапсулированных и независимо вычисляемых единиц. Эти единицы служат в качестве стандартных блоков, которые будут использоваться для автоматического и по требованию создания сред моделирования в облаке Azure. Эти среды моделирования также называются автоматизированной платформой вождения (ADP).
Потенциальные варианты использования
Это решение идеально подходит для автомобильных и транспортных отраслей. Типичные варианты использования для этой рабочей нагрузки:
Автоматизация тестов вождения.
Прототипирование, разработка, интеграция, тестирование, проверка и проверка систем управления в автомобильной отрасли.
Запись данных транспортного средства для визуализации.
Имитация сложных сценариев вождения в автомобильной отрасли.
Рекомендации
Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.
Доступность и устойчивость
Рассмотрите возможность развертывания виртуальных машин в группах доступности или зонах доступности, которые помогают защитить приложения от запланированных событий обслуживания и незапланированных сбоев.
Группа доступности — это логическая группа виртуальных машин, которая позволяет Azure понять структуру вашего приложения, чтобы обеспечить избыточность и доступность.
Зоны доступности — это уникальные физические расположения в регионах Azure, которые помогают защитить виртуальные машины, приложения и данные от сбоев центра обработки данных. Каждая зона состоит из одного или нескольких центров обработки данных. Виртуальные машины и приложения в зонах могут оставаться доступными, даже если в одном центре обработки данных возникает физический сбой.
Масштабируемость
Виртуальные машины Azure можно масштабировать вручную или с помощью функций автомасштабирования.
Для развертываний контейнеров экземпляры контейнеров Azure и Служба Azure Kubernetes также предназначены для масштабирования или автоматического масштабирования.
Безопасность
Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".
Как и в любом другом типе приложения, среда моделирования может быть разработана для обработки конфиденциальных данных. Поэтому следует ограничить, кто может войти и использовать его, а также ограничить доступ к данным на основе удостоверения или роли пользователя. Используйте идентификатор Microsoft Entra для управления удостоверениями и доступом и используйте Azure Key Vault для управления ключами и секретами.
Общие рекомендации по разработке безопасных решений см. в разделе Документация по системе безопасности Azure.
DevOps
Для развертывания новых сред моделирования лучше всего использовать процессы CI/CD с помощью решения, такого как Azure DevOps или GitHub Actions.
Оптимизация затрат
Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".
В общих случаях для оценки затрат используйте калькулятор цен Azure. Вы также можете оптимизировать затраты, следуя процессу, чтобы правильно оценить емкость виртуальных машин с самого начала, а также упрощенное изменение размера по мере необходимости. Другие рекомендации описаны в разделе "Затраты" в Microsoft Azure Well-Architected Framework.
Следующие шаги
Документация по продукту:
Схемы обучения Майкрософт:
Реализация хранилища и управление ими для администраторов Azure
Развертывание вычислительных ресурсов и управление ими для администраторов Azure
Настройка виртуальных сетей для администраторов Azure и управление ими
Управление удостоверениями и управлением для администраторов Azure
Мониторинг и резервное копирование ресурсов для администраторов Azure
Связанные ресурсы
Статьи с обзором Центра архитектуры Azure:
Соответствующие архитектуры: