Эталонная архитектура локальных базовых показателей Azure

Эта эталонная архитектура предоставляет рекомендации и рекомендации по настройке azure Local, версии 23H2, выпуска 2311 и более поздних версий, чтобы обеспечить надежную платформу, которая может развертывать высокодоступные и контейнерные рабочие нагрузки и управлять ими. Эта архитектура описывает компоненты ресурсов и варианты проектирования кластера для физических узлов, которые предоставляют локальные вычислительные ресурсы, хранилище и сетевые функции. В нем также описывается, как использовать службы Azure для упрощения и оптимизации повседневного управления локальными службами Azure.

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

Эта архитектура является отправной точкой для использования переключения сети хранилища для развертывания многопользовательского локального экземпляра Azure. Приложения рабочей нагрузки, развернутые в локальном экземпляре Azure, должны быть хорошо спроектированы. Хорошо спроектированные приложения рабочей нагрузки должны быть развернуты с помощью нескольких экземпляров или высокого уровня доступности всех критически важных служб рабочих нагрузок и имеют соответствующие элементы управления непрерывностью бизнес-процессов и аварийного восстановления (BCDR). Эти элементы управления BCDR включают регулярные резервные копии и возможности отработки отказа аварийного восстановления. Чтобы сосредоточиться на платформе инфраструктуры HCI, эти аспекты проектирования рабочей нагрузки намеренно исключены из этой статьи.

Дополнительные сведения о рекомендациях и рекомендациях для пяти основных компонентов Azure Well-Architected Framework см. в руководстве по службе azure Local Well-Architected Framework.

Макет статьи

Архитектура

Дополнительные сведения см. в связанных ресурсов.

Возможные варианты использования

Типичные варианты использования azure Local включают возможность выполнения рабочих нагрузок высокого уровня доступности (HA) в локальных или пограничных расположениях, которые предоставляют решение для решения требований к рабочей нагрузке. Вы можете:

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

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

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

• Предоставьте централизованную возможность подготовки с помощью Azure и Azure Arc для развертывания рабочих нагрузок в нескольких расположениях согласованно и безопасно. Такие инструменты, как портал Azure, Azure CLI или инфраструктура как код (IaC) используют Kubernetes для контейнеризации или традиционной виртуализации рабочей нагрузки для автоматизации и повторяемости.

• Соблюдайте строгие требования к безопасности, соответствию и аудиту. Локальный сервер Azure развертывается с защищенным состоянием безопасности, настроенным по умолчанию или безопасной по умолчанию. Azure Local включает сертифицированное оборудование, безопасную загрузку, доверенный модуль платформы (TPM), безопасность на основе виртуализации (VBS), Credential Guard и примененные политики управления приложениями в Защитнике Windows. Она также интегрируется с современными облачными службами безопасности и управления угрозами, такими как Microsoft Defender для Облака и Microsoft Sentinel.

Сведения о сценарии

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

Использование Azure Arc с локальной службой Azure

Локальная служба Azure напрямую интегрируется с Azure с помощью Azure Arc, чтобы снизить затраты на TCO и эксплуатационные расходы. Локальные службы Azure развертываются и управляются с помощью Azure, которая обеспечивает встроенную интеграцию Azure Arc с помощью развертывания компонента моста ресурсов Azure Arc. Этот компонент устанавливается во время процесса развертывания кластера HCI. Узлы локального кластера Azure регистрируются с Azure Arc для серверов как необходимые условия для запуска облачного развертывания кластера. Во время развертывания обязательные расширения устанавливаются на каждом узле кластера, например в диспетчере жизненного цикла, управлении устройствами Microsoft Edge, телеметрии и диагностике. Azure Monitor и Log Analytics можно использовать для мониторинга кластера HCI после развертывания, включив Insights для Azure Local. обновления компонентов для локального Azure периодически выпускаются для улучшения взаимодействия с клиентами. Обновления управляются и управляются диспетчера обновлений Azure.

Вы можете развернуть ресурсы рабочей нагрузки, такие как виртуальные машины Azure Arc, azure Arc с поддержкой Службы Azure Kubernetes Service (AKS) и узлах сеансов Виртуального рабочего стола Azure, использующих портал Azure, выбрав пользовательское расположение локального экземпляра Azure в качестве целевого объекта для развертывания рабочей нагрузки. Эти компоненты обеспечивают централизованное администрирование, управление и поддержку. Если у вас есть активные лицензии Software Assurance на существующих лицензиях Центра обработки данных Windows Server, вы можете сократить затраты дальше, применяя преимущество гибридного использования Azure к локальным, виртуальным машинам Windows Server и кластерам AKS. Эта оптимизация помогает эффективно управлять затратами для этих служб.

Интеграция Azure и Azure Arc расширяют возможности виртуализированных и контейнерных рабочих нагрузок Azure, включая:

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

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

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

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

• Расширение службы "Сетка событий Azure" с поддержкой Azure Arc для Kubernetes для развертывания брокера сетки событий и оператора сетки событий компонентов. Это развертывание позволяет использовать такие возможности, как разделы сетки событий и подписки для обработки событий.

• машинное обучение с поддержкой Azure Arc с кластером AKS, развернутым в локальной среде Azure в качестве целевого объекта вычислений для запуска Машинного обучения Azure. Этот подход можно использовать для обучения или развертывания моделей машинного обучения на границе.

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

Воспользуйтесь преимуществами конфигурации безопасности по умолчанию для локальной среды Azure

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

Локально сертифицированное оборудование Azure обеспечивает встроенную безопасную загрузку, единый расширяемый интерфейс встроенного ПО (UEFI) и поддержку доверенного платформенного модуля. Используйте эти технологии в сочетании с VBS для защиты рабочих нагрузок с учетом безопасности. Шифрование дисков BitLocker можно использовать для шифрования томов загрузочных дисков и дисковых пространств, неактивных томов. Шифрование блока сообщений сервера (SMB) обеспечивает автоматическое шифрование трафика между серверами в кластере (в сети хранилища) и подписывание трафика SMB между узлами кластера и другими системами. Шифрование SMB также помогает предотвратить атаки ретранслятора и упрощает соответствие нормативным стандартам.

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

Компоненты

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

Ресурсы платформы

Для архитектуры требуются следующие обязательные ресурсы и компоненты:

• локальной Azure — это решение гиперконвергентной инфраструктуры (HCI), которое развертывается локально или в пограничных расположениях с помощью физического оборудования и сетевой инфраструктуры сервера. Локальная служба Azure предоставляет платформу для развертывания виртуализированных рабочих нагрузок, таких как виртуальные машины, кластеры Kubernetes и другие службы, включенные Azure Arc. Локальные экземпляры Azure могут масштабироваться от развертывания с одним узлом до шестнадцати узлов, используя проверенные, интегрированные или премиум категории оборудования, предоставляемые партнерами изготовителя оборудования (OEM).

• Azure Arc — это облачная служба, которая расширяет модель управления на основе Azure Resource Manager до локальных и других расположений, отличных от Azure. Azure Arc использует Azure в качестве уровня управления и управления для управления различными ресурсами, такими как виртуальные машины, кластеры Kubernetes, а также контейнерные службы данных и машинного обучения.

• Azure Key Vault — это облачная служба, которую можно использовать для безопасного хранения и доступа к секретам. Секрет — это все, что вы хотите жестко ограничить доступ, например ключи API, пароли, сертификаты, криптографические ключи, учетные данные локального администратора и ключи восстановления BitLocker.

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

• Update Manager — это единая служба, предназначенная для управления обновлениями для локальной среды Azure и управления ими. Диспетчер обновлений можно использовать для управления рабочими нагрузками, развернутыми в локальной среде Azure, включая соответствие обновлений гостевой ОС для виртуальных машин Windows и Linux. Этот унифицированный подход упрощает управление исправлениями в локальных средах Azure и других облачных платформах с помощью одной панели мониторинга.

Ресурсы, поддерживающие платформу

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

• Мониторинг — это облачная служба для сбора, анализа и действия с журналами диагностики и телеметрией из облачных и локальных рабочих нагрузок. Монитор можно использовать для максимальной доступности и производительности приложений и служб с помощью комплексного решения для мониторинга. Разверните Insights для Azure Local, чтобы упростить создание правила сбора данных монитора (DCR) и быстро включить мониторинг локальных экземпляров Azure.

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

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

• Azure Backup — это облачная служба, которая предоставляет простое, безопасное и экономичное решение для резервного копирования данных и его восстановления из Microsoft Cloud. Azure Backup Server используется для резервного копирования виртуальных машин, развернутых в локальной среде Azure, и хранения их в службе архивации.

• Site Recovery — это служба аварийного восстановления, которая предоставляет возможности BCDR, позволяя бизнес-приложениям и рабочим нагрузкам выполнять отработку отказа в случае аварии или сбоя. Site Recovery управляет репликацией и отработкой отказа рабочих нагрузок, выполняемых на физических серверах и виртуальных машинах между основным сайтом (локальной средой) и дополнительным расположением (Azure).

Варианты проектирования кластера

Важно понимать требования к производительности и устойчивости рабочей нагрузки при разработке локального экземпляра Azure. К этим требованиям относятся целевое время восстановления (RTO) и целевой точки восстановления (RPO), вычислительные ресурсы (ЦП), память и требования к хранилищу для всех рабочих нагрузок, развернутых в локальном экземпляре Azure. Некоторые характеристики рабочей нагрузки влияют на процесс принятия решений и включают:

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

• Требования к единице обработки графики (GPU) рабочей нагрузки, например для искусственного интеллекта или машинного обучения, вывода или отрисовки графики.

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

• Количество физических узлов в кластере, 1 до 16 узлов в масштабе. Максимальное количество узлов составляет три при использовании архитектуры сети без переключения хранилища.

  • Чтобы обеспечить устойчивость вычислительных ресурсов, необходимо зарезервировать по крайней мере N+1 узлов в кластере. Эта стратегия обеспечивает очистку узлов для обновлений или восстановления от внезапных сбоев питания, таких как сбои питания или аппаратные сбои.

  • Для критически важных для бизнеса рабочих нагрузок рекомендуется зарезервировать узлы N+2, чтобы повысить устойчивость. Например, если два узла в кластере находятся в автономном режиме, рабочая нагрузка может оставаться в сети. Этот подход обеспечивает устойчивость для сценариев, в которых узел, на котором выполняется рабочая нагрузка, переходит в автономный режим во время запланированной процедуры обновления и приводит к тому, что два узла находятся в автономном режиме одновременно.

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

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

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

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

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

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

• Зарезервируете не менее 1 узлов с емкостью или одним узлом в кластере.

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

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

Выходные данные из средства локального размера Azure — это список рекомендуемых номеров SKU оборудования, которые могут обеспечить необходимую емкость рабочей нагрузки и требования к устойчивости платформы на основе входных значений в проекте Sizer. Дополнительные сведения о доступных решениях для партнеров оборудования OEM см. в каталоге локальных решений Azure. Чтобы обеспечить защиту номеров SKU решения в соответствии с вашими требованиями, обратитесь к вашему предпочтительному поставщику решений оборудования или партнеру по интеграции с системой (SI).

Физические диски дисков

локальных дисковых пространств поддерживает несколько типов дисковых дисков, которые зависят от производительности и емкости. При разработке локального экземпляра Azure обратитесь к выбранному партнеру изготовителя оборудования, чтобы определить наиболее подходящие типы физических дисков для удовлетворения требований к емкости и производительности рабочей нагрузки. К примерам относятся спиннинг жестких дисков (HDD) или твердотельные накопители (SSD) и диски NVMe. Эти диски часто называются флэш-накопителямиили сохраняемой памяти (PMem), которая называется памятью класса хранилища (SCM).

Надежность платформы зависит от производительности критически важных зависимостей платформы, таких как типы физических дисков. Обязательно выберите нужные типы дисков для ваших требований. Используйте решения для хранения всех флэш-памяти, такие как NVMe или SSD-диски для рабочих нагрузок с высоким уровнем производительности или низкой задержкой. Эти рабочие нагрузки включают в себя, но не ограничиваются технологиями базы данных с высокой транзакцией, рабочими кластерами AKS или критически важными для бизнеса рабочими нагрузками, которые имеют требования к хранилищу с низкой задержкой или высокой пропускной способностью. Используйте развертывания all-flash для повышения производительности хранилища. All-NVMe диска или конфигурации диска ssd, особенно в небольшом масштабе, повысить эффективность хранения и повысить производительность, так как диски не используются в качестве уровня кэша. Дополнительные сведения см. в все флэш-накопители.

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

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

Локальные дисковые пространства предоставляют встроенны й, постоянный, постоянный, постоянный, режим реального времени, чтение, запись, кэша на стороне сервера, который обеспечивает максимальную производительность хранилища. Кэш должен быть настроен для размещения рабочего набора приложений и рабочих нагрузок. Локальные виртуальные диски дисковых пространств или томаиспользуются в сочетании с кэшем чтения общего тома кластера (CSV) для повышения производительности Hyper-V производительности, особенно для неуффеферированного доступа к файлам виртуального жесткого диска рабочей нагрузки (VHD) или виртуальных жестких дисков версии 2 (VHDX).

Проектирование сети

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

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

Для этой архитектуры требуется два или более физических узлов и не более 16 узлов в масштабе. Для каждого узла требуется четыре порта сетевого адаптера, подключенные к двум коммутаторам Top-of-Rack (ToR). Два коммутатора ToR должны быть соединены через связи с несколькими корпусами связи группы агрегирования (MLAG). Два порта сетевого адаптера, используемые для трафика намерений хранилища, должны поддерживать удаленного прямого доступа к памяти (RDMA). Эти порты требуют минимальной скорости связи 10 Гбит/с, но мы рекомендуем скорость 25 Гбит/с или выше. Два порта сетевого адаптера, используемые для управления и намерений вычислений, конвергентируются с помощью технологии переключения внедренных команд (SET). Технология SET обеспечивает избыточность ссылок и возможности балансировки нагрузки. Для этих портов требуется минимальная скорость канала 1 Гбит/с, но рекомендуется скорость 10 Гбит/с или выше.

Топология физической сети

В следующей топологии физической сети показаны фактические физические подключения между узлами и сетевыми компонентами.

При разработке многопользовательского хранилища необходимо использовать следующие компоненты, которые переключили локальное развертывание Azure, использующее эту базовую архитектуру:

• Двойные переключатели ToR:

  • Для обеспечения устойчивости сети требуются двойные сетевые коммутаторы ToR, а также возможность обслуживания или применения обновлений встроенного ПО к коммутаторам без простоя. Эта стратегия предотвращает одну точку сбоя (SPoF).

  • Двойные коммутаторы ToR используются для хранилища или на востоке, трафика. Эти коммутаторы используют два выделенных порта Ethernet с определенными локальными сетями хранилища (VLAN) и классами трафика управления потоками приоритета (PFC), определенными для обеспечения связи RDMA без потери.

  • Эти коммутаторы подключаются к узлам через кабели Ethernet.

• Два или более физических узлов и не более 16 узлов:

  • Каждый узел — это физический сервер, на котором выполняется ОС Azure Stack HCI.

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

  • Хранилище использует два выделенных сетевых адаптера с поддержкой RDMA порты, которые подключаются к одному пути к каждому из двух коммутаторов ToR. Этот подход обеспечивает избыточность пути связи и выделенную приоритетную пропускную способность для трафика прямого хранилища SMB.

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

• Внешнее подключение:

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

  • Подключение внешнего трафика на север к югу поддерживает намерение управления кластерами и намерения вычислений. Это достигается с помощью двух портов коммутатора и двух портов сетевого адаптера на каждый узел, которые конвергентны через внедренное объединение коммутаторов (SET) и виртуальный коммутатор в Hyper-V для обеспечения устойчивости. Эти компоненты работают для обеспечения внешнего подключения для виртуальных машин Azure Arc и других ресурсов рабочей нагрузки, развернутых в логических сетях, созданных в Resource Manager с помощью портала Azure, интерфейса командной строки или шаблонов IaC.

Топология логической сети

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

Сводка логической установки для этой переключения базовой архитектуры для хранилища с несколькими узлами для локальной среды Azure выглядит следующим образом:

• Двойные переключатели ToR:

  • Перед развертыванием кластера необходимо настроить два сетевых коммутатора ToR с необходимыми идентификаторами виртуальных локальных ЛС, максимальными параметрами единицы передачи и конфигурацией бриджинга центра обработки данных для управления, вычислительныхи портов хранилища. Дополнительные сведения см. в статье Требования к физической сети для локальнойAzure или обратитесь к поставщику оборудования коммутатора или партнеру SI.

• Локальный azure использует подход сетевого ATC для применения сетевой автоматизации и конфигурации сети на основе намерений.

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

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

• Внешнее взаимодействие:

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

  • Когда два коммутатора ToR выполняют роль устройств уровня 3, они обрабатывают маршрутизацию и обеспечивают подключение за пределами кластера к пограничному устройству, например брандмауэру или маршрутизатору.

  • Намерение сети управления использует конвергентный виртуальный интерфейс группы SET, который позволяет IP-адресу управления кластерами и ресурсам плоскости управления взаимодействовать внешне.

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

• Трафик хранилища:

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

  • Порты хранилища SMB1 и SMB2 подключения к двум отдельным неизменяемым сетям (или уровня 2). Каждая сеть имеет определенный идентификатор виртуальной локальной сети, который должен соответствовать конфигурации портов коммутаторов на идентификаторах виртуальной локальной сети хранилища по умолчанию: 711 и 712.

  • Шлюз по умолчанию не настроен на двух портах сетевого адаптера намерения хранилища в ОС Azure Stack HCI.

  • Каждый узел может получить доступ к прямым возможностям кластера, таким как удаленные физические диски, используемые в пуле носителей, виртуальных дисках и томах. Доступ к этим возможностям упрощается через протокол RDMA SMB-Direct через два выделенных порта сетевого адаптера хранилища, доступные на каждом узле. SMB Multichannel используется для обеспечения устойчивости.

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

Требования к сетевому коммутатору

Коммутаторы Ethernet должны соответствовать различным спецификациям, необходимым для Azure Local и установленным Институтом стандартов электротехнических инженеров (IEEE SA). Например, для переключенных развертываний с несколькими узлами сеть хранения используется для RDMA через RoCE версии 2 или iWARP. Для этого процесса требуется IEEE 802.1Qbb PFC, чтобы обеспечить бесполезное взаимодействие для класса трафика хранилища . Коммутаторы ToR должны обеспечить поддержку IEEE 802.1Q для виртуальных ЛС и IEEE 802.1AB для протокола обнаружения уровней ссылок.

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

Требования к IP-адресу

В переключении развертывания с несколькими узлами количество IP-адресов, необходимых для добавления каждого физического узла, не более 16 узлов в одном кластере. Например, для развертывания переключения конфигурации хранилища с двумя узлами локальной среды Azure инфраструктура кластера требует выделения не менее 11 x IP-адресов. При использовании микросегментации или программно-определяемой сети требуется больше IP-адресов. Дополнительные сведения см. в статье Просмотр требований к IP-адресам для локальногохранилища с двумя узлами.

При разработке и планировании требований к IP-адресам для локальной среды Azure не забудьте учесть дополнительные IP-адреса или диапазоны сети, необходимые для рабочей нагрузки, кроме тех, которые необходимы для локальных экземпляров и компонентов инфраструктуры Azure. Если вы планируете развернуть AKS в локальной среде Azure, ознакомьтесь с AKS, включенными требованиями к сети Azure Arc.

Контроль

Чтобы улучшить мониторинг и оповещения, включите Monitor Insights в локальнойAzure. Аналитика может масштабироваться для мониторинга нескольких локальных кластеров и управления ими с помощью согласованного интерфейса Azure. Аналитика использует счетчики производительности кластера и каналы журналов событий для мониторинга ключевых функций Azure Local. Журналы собираются С помощью DCR, настроенного с помощью Monitor и Log Analytics.

Аналитика для локальной среды Azure создается с помощью Monitor и Log Analytics, что обеспечивает всегда up-to-date, масштабируемое решение, которое очень настраивается. Аналитика предоставляет доступ к книгам по умолчанию с базовыми метриками, а также специализированными книгами, созданными для мониторинга ключевых функций Azure Local. Эти компоненты предоставляют решение для мониторинга практически в режиме реального времени и позволяют создавать графы, настраивать визуализации с помощью агрегирования и фильтрации, а также настраивать пользовательские правила оповещений о работоспособности ресурсов.

Управление обновлениями

Локальные экземпляры Azure и развернутые ресурсы рабочей нагрузки, такие как виртуальные машины Azure Arc, должны обновляться и исправляться регулярно. Регулярно применяя обновления, вы гарантируете, что ваша организация поддерживает высокий уровень безопасности и повышает общую надежность и поддержку вашего имущества. Мы рекомендуем использовать автоматические и периодические оценки вручную для раннего обнаружения и применения исправлений безопасности и обновлений ОС.

Обновления инфраструктуры

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

Update Manager — это служба Azure, которую можно использовать для применения, просмотра и управления обновлениями для локальной среды Azure. Эта служба предоставляет механизм просмотра всех локальных экземпляровAzure во всей инфраструктуре и пограничных расположениях с помощью портала Azure для централизованного управления. Дополнительные сведения см. в следующих ресурсах:

• сведения о локальном выпуске Azure

• локального жизненного цикла Azure

• этапы обновления локальной Azure

• Использовать Диспетчер обновлений Azure для обновления локальной Azure

Важно регулярно проверять наличие обновлений драйверов и встроенного ПО, например каждые три-шесть месяцев. Если вы используете версию категории решений Premier для локального оборудования Azure, обновления пакета расширения построителя решений интегрированы с Update Manager, чтобы обеспечить упрощенное обновление. Если вы используете проверенные узлы или интегрированную системную категорию, может потребоваться скачать и запустить пакет обновления для изготовителя оборудования, содержащий обновления встроенного ПО и драйверов для вашего оборудования. Чтобы определить, как предоставляются обновления для оборудования, обратитесь к партнеру OEM или SI оборудования.

Исправление гостевой ОС рабочей нагрузки

Вы можете зарегистрировать виртуальные машины Azure Arc, развернутые в локальной среде Azure, с помощью azure Update Manager (AUM), чтобы обеспечить унифицированное управление исправлениями с помощью того же механизма, который используется для обновления физических узлов локального кластера Azure. С помощью AUM можно создать конфигурации обслуживания гостевых. Эти параметры управления конфигурацией, такие как параметр перезагрузки перезагрузки при необходимости, расписание (даты, время и повторение), а также динамический (подписка) или статический список виртуальных машин Azure Arc для области. Эти параметры управляют конфигурацией при установке исправлений безопасности ОС в гостевой ОС виртуальной машины рабочей нагрузки.

Соображения

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

Надёжность

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

Определение потенциальных точек сбоя

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

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

Целевые показатели надежности

В этом разделе описывается пример сценария. Вымышленный клиент, называемый Contoso Manufacturing использует эту эталонную архитектуру для развертывания Azure Local. Они хотят решить свои требования и развернуть локальные рабочие нагрузки и управлять ими. Contoso Manufacturing имеет внутреннюю цель уровня обслуживания (SLO) 99,8%, что заинтересованные лица бизнеса и приложений согласны со своими службами.

• SLO 99.8% времени простоя или доступности приводит к следующим периодам разрешенного простоя или недоступности для приложений, развернутых с помощью виртуальных машин Azure Arc, работающих в локальной среде Azure:

  • Еженедельно: 20 минут и 10 секунд

  • Ежемесячно: 1 час, 26 минут и 56 секунд

  • Квартальные: 4 часа, 20 минут и 49 секунд

  • Год: 17 часов, 23 минуты и 16 секунд

• , чтобы помочь удовлетворить целевые показатели SLO, Contoso Manufacturing реализует принцип наименьших привилегий (PoLP), чтобы ограничить число администраторов локальных экземпляров Azure небольшой группой доверенных и квалифицированных лиц. Этот подход помогает предотвратить простой из-за каких-либо непреднамеренно или случайных действий, выполняемых на рабочих ресурсах. Кроме того, журналы событий безопасности для локальных контроллеров доменных служб Active Directory (AD DS) отслеживаются, чтобы обнаруживать и сообщать об изменениях членства в группах пользователей, известных как добавления и удаления действий, для администраторов локальных экземпляров Azure с помощью решения управления событиями безопасности (SIEM). Мониторинг повышает надежность и повышает безопасность решения.

  Дополнительные сведения см. в рекомендации по управлению удостоверениями и доступом.

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

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

• ежемесячные исправления системы безопасности и квартальные базовые обновления применяются к рабочему экземпляру Azure Local только после их проверки в предварительной среде. Диспетчер обновлений и компонент обновления, поддерживающий кластер, автоматизируйте процесс использования динамической миграции виртуальных машин , чтобы свести к минимуму время простоя для критически важных для бизнеса рабочих нагрузок во время ежемесячных операций обслуживания. Для стандартных операционных процедур Contoso Production требуется, чтобы обновления безопасности, надежности или базовой сборки применялись ко всем производственным системам в течение четырех недель до даты выпуска. Без этой политики рабочие системы постоянно не могут оставаться в курсе ежемесячных обновлений ОС и системы безопасности. Устаревшие системы негативно влияют на надежность и безопасность платформы.

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

• Contoso Manufacturing реализует ежедневно, еженедельные и ежемесячные резервные копии сохранять последние 6 x дней ежедневных резервных копий (понедельники до субботы), последние 3 x еженедельные (каждый воскресенье) и 3 x ежемесячные резервные копии, с каждым воскресенье неделя 4 сохраняться, чтобы стать месяцем 1, месяцем 2 и 3 резервными копиями с помощью последовательного календаря на основе расписания, который задокументирован и проверяем. Этот подход соответствует требованиям компании Contoso Manufacturing для обеспечения достаточного баланса между количеством доступных точек восстановления данных и сокращением затрат на обслуживание внесайтового или облачного хранилища резервных копий.

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

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

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

• Операционные процессы и процедуры, описанные ранее в статье, и рекомендации, описанные в руководстве по службе Well-Architected Framework для локальнойAzure, позволяют Contoso Manufacturing соответствовать целевым объектам SLO 99,8% SLO и эффективно масштабировать развертывания локальной и рабочей нагрузки Azure на нескольких производственных сайтах, распределенных по всему миру.

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

Избыточность

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

Используйте стандартные отраслевые шаблоны высокой доступности для рабочих нагрузок, которые обеспечивают активную и пассивной репликацию, синхронную репликацию или асинхронную репликацию, например SQL Server AlwaysOn. Вы также можете использовать технологию балансировки нагрузки внешней сети (NLB), которая направляет запросы пользователей по нескольким экземплярам рабочей нагрузки, которые выполняются в локальных экземплярах Azure, развернутых в отдельных физических расположениях. Рассмотрите возможность использования внешнего устройства NLB партнера. Кроме того, можно оценить параметры балансировки нагрузки , которые поддерживают маршрутизацию трафика для гибридных и локальных служб, таких как экземпляр шлюза приложений Azure, использующий Azure ExpressRoute или VPN-туннель для подключения к локальной службе.

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

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

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

Вопросы безопасности:

• Безопасный фундамент для локальной платформы Azure: Локальный Azure — это защищенный по умолчанию продукт, использующий проверенные аппаратные компоненты с TPM, UEFI и безопасной загрузкой для создания безопасной основы для обеспечения безопасности локальной платформы Azure и безопасности рабочей нагрузки. При развертывании с параметрами безопасности по умолчанию в локальной среде Azure включен элемент управления приложениями в Защитнике Windows, Credential Guard и BitLocker. Чтобы упростить делегирование разрешений с помощью PoLP, используйте встроенные роли управления доступом на основе ролей (RBAC) Azure, такие как локальный администратор Azure для администраторов платформы и участник локальной виртуальной машины Azure или средство чтения локальных виртуальных машин Azure для операторов рабочей нагрузки.

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

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

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

• обнаружение угроз и исправление угроз: Microsoft Advanced Threat Analytics обнаруживает и устраняет угрозы, такие как целевые службы AD DS, которые предоставляют службы проверки подлинности узлам локальных экземпляров Azure и рабочим нагрузкам виртуальных машин Windows Server.

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

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

Оптимизация затрат

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

Рекомендации по оптимизации затрат включают:

• модель выставления счетов в стиле облака для лицензирования. Локальные цены Azure соответствую т модели выставления счетов за ежемесячную подписку с плоской ставкой на ядро физического процессора в локальном экземпляре Azure. Дополнительные расходы на использование применяются при использовании других служб Azure. Если вы владеете локальными лицензиями для Windows Server Datacenter edition с активным software Assurance, вы можете обменять эти лицензии, чтобы активировать локальный экземпляр Azure и подписку на виртуальную машину Windows Server.

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

• консолидации мониторинга затрат. Чтобы объединить затраты на мониторинг, используйте Insights для локальной Azure и исправления с помощью диспетчера обновлений для локальнойAzure. Аналитика использует Monitor для предоставления широких возможностей метрик и оповещений. Компонент диспетчера жизненного цикла Azure Localintegrates с помощью Update Manager упрощает задачу поддержания актуальности кластеров путем консолидации рабочих процессов обновления для различных компонентов в одном интерфейсе. Используйте Monitor и Update Manager для оптимизации распределения ресурсов и повышения общей эффективности затрат.

  Дополнительные сведения см. в рекомендациях по оптимизации времени персонала.

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

  Дополнительные сведения см. в рекомендациях по оптимизации затрат на компоненты.

Операционное превосходство

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

Рекомендации по операционному превосходству включают:

• упрощенной подготовки и управления, интегрированные с Azure. Развертывание Cloud Based в Azure предоставляет интерфейс, управляемый мастером, который показывает, как создать локальный экземпляр Azure. Аналогичным образом Azure упрощает процесс управления локальными экземплярами Azure и виртуальными машинами Azure Arc. Вы можете автоматизировать развертывание локального экземпляра Azure на портале с помощью шаблона ARM. Этот шаблон обеспечивает согласованность и автоматизацию для развертывания локальной среды Azure в масштабе, в частности в пограничных сценариях, таких как розничные магазины или производственные сайты, требующие локального экземпляра Azure для выполнения критически важных для бизнеса рабочих нагрузок.

• возможности автоматизации для виртуальных машин. Локальная служба Azure предоставляет широкий спектр возможностей автоматизации для управления рабочими нагрузками, таких как виртуальные машины Azure Arc, с помощью автоматического развертывания виртуальных машин Azure Arc с помощью Azure CLI, ARM илишаблона Bicep с обновлениями ОС виртуальной машины с помощью расширения Azure Arc для обновлений и Azure Update Manager для обновления каждого локального экземпляра Azure. Azure Local также предоставляет поддержку управления виртуальными машинами Azure Arc с помощью Azure CLI и виртуальных машин, отличных от Azure Arc, с помощью Windows PowerShell. Команды Azure CLI можно выполнять локально с одного из локальных компьютеров Azure или удаленно с компьютера управления. Интеграция с службы автоматизации Azure и Azure Arc упрощает широкий спектр дополнительных сценариев автоматизации для рабочих нагрузок виртуальных машин с помощью расширений Azure Arc.

  Дополнительные сведения см. в рекомендациях по использованиюIaC.

• возможности автоматизации для контейнеров в AKS. Локальный azure предоставляет широкий спектр возможностей автоматизации для управления рабочими нагрузками, такими как контейнеры, в AKS. Вы можете автоматизировать развертывание кластеров AKS с помощью Azure CLI. Обновление кластеров рабочих нагрузок AKS с помощью расширения Azure Arc для обновлений Kubernetes. Вы также можете управлять AKS с поддержкой Azure Arc с помощью Azure CLI. Команды Azure CLI можно выполнять локально с одного из локальных компьютеров Azure или удаленно с компьютера управления. Интеграция с Azure Arc для широкого спектра дополнительных сценариев автоматизации для контейнерных рабочих нагрузок с помощью расширений Azure Arc.

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

Эффективность производительности

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

Рекомендации по эффективности производительности:

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

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

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

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

  Дополнительные сведения см. в рекомендациях по планированию емкости.

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

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

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

Развертывание этого сценария

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

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

1. Сбор требований к рабочей нагрузке и варианту использования со стороны соответствующих заинтересованных лиц. Эта стратегия позволяет проекту убедиться, что функции и возможности Azure Local соответствуют требованиям к масштабированию, производительности и функциональности рабочей нагрузки. Этот процесс проверки должен включать понимание масштаба рабочей нагрузки или размера, а также необходимые функции, такие как виртуальные машины Azure Arc, AKS, виртуальный рабочий стол Azure или службы данных с поддержкой Azure Arc или службы машинного обучения с поддержкой Azure Arc. Значения RTO и RPO (надежность) рабочей нагрузки и другие нефункциональные требования (масштабируемость производительности и нагрузки) должны быть задокументированы в рамках этого шага сбора требований.

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

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

4. просмотрите выходные данные локального размера Azure для рекомендуемого решения партнера по оборудованию. Это решение содержит сведения о рекомендуемом оборудовании физического сервера (make и model), количестве физических узлов и спецификациях конфигурации ЦП, памяти и хранилища каждого физического узла, необходимого для развертывания и запуска рабочих нагрузок.

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

6. Развернуть два коммутатора ToR длясетевой интеграции. Для решений с высоким уровнем доступности кластеры HCI требуют развертывания двух коммутаторов ToR. Для каждого физического узла требуется четыре сетевых адаптера, два из которых должны иметь возможность RDMA, которая предоставляет две связи между каждым узлом и двумя коммутаторами ToR. Два сетевых адаптера, подключенные к каждому коммутатору, конвергентны для исходящего подключения к северу от юга для вычислительных сетей и сетей управления. Другие два сетевых адаптера с поддержкой RDMA предназначены для трафика на востоке-западе хранилища. Если вы планируете использовать существующие сетевые коммутаторы, убедитесь, что макет и модель коммутаторов находятся в утвержденном списке сетевых коммутаторов, поддерживаемых локальнойAzure.

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

8. Выполнить развертывание локального экземпляра Azure. В зависимости от выбранной версии решения (решение Premier, интегрированная система или проверенные узлы), партнер по оборудованию, SI или сотрудники могут развернуть локальное программное обеспечение Azure. На этом шаге начинается подключение физических узлов Ос Azure Stack HCI к серверам с поддержкой Azure Arc, а затем запуск процесса развертывания локального облака Azure. Клиенты и партнеры могут напрямую отправить запрос на поддержку корпорации Майкрософт на портале Azure , выбрав значок поддержки и устранения неполадок или связався со своим партнером oem или SI, в зависимости от характера запроса и категории решения оборудования.

   Кончик

   Ос ОС Azure Stack HCI версии 23H2, демонстрирует развертывание переключённого многосерверного развертывания Azure Local с помощью шаблона ARM и файла параметров. Кроме того, примере Bicep демонстрирует использование шаблона Bicep для развертывания локального экземпляра Azure, включая необходимые ресурсы.

9. Развертывание высокодоступных рабочих нагрузок в Локальной среде Azure с помощью портала Azure, ИНТЕРФЕЙСА командной строки или шаблонов ARM + Azure Arc для автоматизации. Используйте пользовательское расположение ресурс нового кластера HCI в качестве целевого региона при развертывания ресурсов рабочей нагрузки, таких как виртуальные машины Azure Arc, AKS, узлы сеансов Виртуального рабочего стола Azure или другие службы с поддержкой Azure Arc, которые можно включить с помощью расширений и контейнеров AKS в локальной среде Azure.

10. установить ежемесячные обновления для повышения безопасности и надежности платформы. Чтобы обеспечить актуальность локальных экземпляров Azure, важно установить обновления программного обеспечения Майкрософт и аппаратный драйвер OEM и обновления встроенного ПО. Эти обновления повышают безопасность и надежность платформы. Update Manager применяет обновления и предоставляет централизованное и масштабируемое решение для установки обновлений в одном кластере или нескольких кластерах. Обратитесь к партнеру oem по оборудованию, чтобы определить процесс установки обновлений драйвера оборудования и встроенного ПО, так как этот процесс может отличаться в зависимости от выбранного типа решения оборудования (решение Premier, интегрированная система или проверенные узлы). Дополнительные сведения см. в обновлениях инфраструктуры.

Связанные ресурсы

• проектирование гибридной архитектуры
• гибридные параметры Azure
• автоматизация в гибридной среде
• конфигурации состояния автоматизации Azure
• Оптимизация администрирования экземпляров SQL Server в локальных и многооблачных средах с помощью Azure Arc

Дальнейшие действия

Документация по продукту:

• ОС Azure Stack HCI версии 23H2
• AKS в локальном Azure
• виртуального рабочего стола Azure для локального Azure
• Что такое локальный мониторинг Azure?
• Защита рабочих нагрузок виртуальных машин с помощью Site Recovery на локальном Azure
• Обзор монитора
• Обзор отслеживания изменений и инвентаризации
• Обзор диспетчера обновлений
• Что такое службы данных с поддержкой Azure Arc?
• Что такое серверы с поддержкой Azure Arc?
• Что такое служба резервного копирования?

Документация по продуктам для конкретных служб Azure:

• локальной Azure
• Azure Arc
• Key Vault
• хранилище BLOB-объектов Azure
• монитор
• политики Azure
• реестра контейнеров Azure
• Defender для облака
• Site Recovery
• резервного копирования

Модули Microsoft Learn:

• Настройка монитора
• Проектирование решения для восстановления сайта в Azure
• Общие сведения о серверах с поддержкой Azure Arc
• Общие сведения о службах данных с поддержкой Azure Arc
• Введение в AKS
• развертывание модели с помощью машинного обучения в любом месте — блог tech Community
• реализации машинного обучения в любом месте с помощью AKS и Машинного обучения с поддержкой Azure Arc — блог сообщества tech community
• Машинное обучение в гибридной среде AKS и Stack HCI с помощью машинного обучения с поддержкой Azure Arc — блог сообщества tech community
• Общие сведения о целевом объекте вычислений Kubernetes в машинного обучения
• обновление виртуальных машин
• Защита параметров виртуальной машины с помощью конфигурации состояния автоматизации
• Защитить виртуальные машины с помощью резервного копирования