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

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

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

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

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

Макет статьи

Architecture	Решения по проектированию	подход Well-Architected Framework
▪ Архитектура ▪ компоненты ▪ Ресурсы платформы ▪ Ресурсы, поддерживающие платформу ▪ Сведения о сценарии ▪ Использование Azure Arc с локальной службой Azure ▪ Воспользуйтесь преимуществами конфигурации безопасности по умолчанию для локальной среды Azure ▪ потенциальные варианты использования ▪ развернуть этот сценарий	▪ варианты проектирования кластера ▪ физических дисков ▪ Проектирование сети ▪ Контроль ▪ Управление обновлениями	▪ Надёжность ▪ Безопасность ▪ Оптимизация затрат ▪ Операционное превосходство ▪ Эффективность производительности

Architecture

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

Components

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробности сценария

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

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

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

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

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

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

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

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

• Службы данных с поддержкой Azure Arc для контейнеризованного управляемого экземпляра SQL Azure.

• Приложения контейнеров Azure с поддержкой Azure Arc для запуска приложений и микрослужб на основе контейнеров. Его можно развернуть с помощью расширения "Контейнерные приложения" для Kubernetes, которое обеспечивает развертывание подключенных сред контейнерных приложений. После включения в кластере AKS можно запускать такие службы, как Функции Azure. В целях поддержки масштабирования с учетом событий установите, при необходимости, расширение Kubernetes Event-Driven Autoscaling (KEDA).

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

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

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

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

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

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

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

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

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

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

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

• Уменьшите TCO, развернув решение, сертифицированное корпорацией Майкрософт и ее партнерами по оборудованию OEM. Это решение использует современный облачный процесс развертывания и обеспечивает централизованное управление и мониторинг Azure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В разделе «Параметры» средства выбора конфигурации приводятся вопросы, касающиеся типа системы, включая решение Premier, интегрированную систему или проверенный узел, а также параметры семейства ЦП. Он также помогает выбрать требования к устойчивости для экземпляра. Чтобы задать уровни устойчивости, следуйте приведенным ниже рекомендациям.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Два или более физических компьютеров и до 16 физических компьютеров:

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

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

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

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

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

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

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

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

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

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

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

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

• Сеть ATC

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

  • Локальный 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.

Исходящее сетевое подключение

Перед развертыванием решения важно понимать требования к исходящему сетевому подключению Azure Local и учитывать эти требования в плане разработки и реализации. Исходящее сетевое подключение требуется, чтобы локальный azure мог взаимодействовать с Azure и Azure Arc для операций управления и плоскости управления. Например, исходящее подключение необходимо для подготовки ресурсов с поддержкой Azure Arc, таких как локальные виртуальные машины Azure или кластеры AKS, а также для использования служб управления Azure, таких как Update Manager и Azure Monitor.

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

Почему важно исходящее сетевое подключение

Требуется исходящее сетевое подключение для вашего локального экземпляра Azure. Это требование включает физические машины, устройство моста ресурсов Azure Arc , кластеры AKS и локальные виртуальные машины Azure, если вы используете Azure Arc для управления гостевой операционной системой виртуальной машины. Эти устройства имеют локальные агенты или службы, которые подключаются к общедоступным конечным точкам с помощью исходящего сетевого доступа для обмена данными в режиме реального времени, что позволяет подключаться к поставщикам ресурсов уровня управления и управления, работающим в Azure. Например, исходящие подключения необходимы операторам для использования портала Azure, Azure CLI или средств IaC, таких как ARM, Bicep или Terraform-шаблоны, чтобы подготовить ресурсы, управлять ими или выполнять оба действия. Мост ресурсов Azure и Azure Arc взаимодействуют с настраиваемым расположением ресурса локальной инстанции Azure. Это сочетание позволяет использовать конкретный локальный экземпляр Azure для любых операций CRUD ресурса (создание, чтение, обновление или удаление) для ресурсов рабочей нагрузки с поддержкой Azure Arc.

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

• Azure Local не поддерживает проверку пакетов SSL/TLS на любом из сетевых маршрутов от ваших экземпляров Azure Local к общедоступным конечным точкам. Кроме того, приватный канал и Azure ExpressRoute не поддерживаются для подключения к необходимым общедоступным конечным точкам. Дополнительные сведения см. в статье Требования к брандмауэру для локальнойAzure.

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

• При развертывании Azure Local с использованием прокси-сервера для контроля и управления выходом в интернет изучите требования к прокси.

Monitoring

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

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

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

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

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

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

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

• Сведения о локальном выпуске Azure
• Частота локального жизненного цикла Azure
• этапы обновления локальной Azure
• Использование диспетчера обновлений для обновления локальной среды Azure

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

Исправление гостевой операционной системы рабочей нагрузки

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

Considerations

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

Reliability

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

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

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

Component	Risk	Likelihood	Влияние и устранение рисков	Outage
Сбой локального экземпляра Azure	Сбой питания, сети, оборудования или программного обеспечения	Medium	Чтобы предотвратить длительный сбой приложения, вызванный отказом локального экземпляра Azure, который обслуживает критически важные и бизнес-критичные варианты использования, ваша система должна быть спроектирована с использованием принципов высокой доступности и аварийного восстановления. Например, можно использовать стандартные технологии репликации данных рабочей нагрузки для хранения нескольких копий данных постоянного состояния, развернутых с помощью нескольких локальных виртуальных машин Azure или экземпляров AKS, развернутых в отдельных локальных экземплярах Azure и в отдельных физических расположениях.	Потенциальный сбой
Сбой локального физического компьютера Azure	Сбой питания, оборудования или программного обеспечения	Medium	Чтобы предотвратить длительный сбой приложения, вызванный сбоем одного локального компьютера Azure, локальный экземпляр Azure должен иметь несколько физических компьютеров. Требования к емкости рабочей нагрузки на этапе разработки кластера определяют количество физических компьютеров. Рекомендуется использовать три или более физических компьютеров. Мы также рекомендуем использовать трехстороннее зеркальное отображение, которое является режимом устойчивости хранилища по умолчанию для кластеров с тремя или более физическими компьютерами. Чтобы предотвратить SPoF и повысить устойчивость рабочей нагрузки, разверните несколько экземпляров рабочей нагрузки с помощью двух или нескольких локальных виртуальных машин Azure или контейнерных подов, работающих на нескольких рабочих узлах AKS. Если одна машина отказывает, локальные виртуальные машины Azure и нагрузки или службы приложений перезапускаются на оставшихся в сети физических машинах в кластере.	Потенциальный сбой
Локальная виртуальная машина Azure или рабочий узел AKS (рабочая нагрузка)	Misconfiguration	Medium	Пользователи приложений не могут войти или получить доступ к приложению. Определите неправильные конфигурации во время развертывания. Если эти ошибки возникают во время обновления конфигурации, команда DevOps должна откатить изменения. При необходимости можно повторно развернуть виртуальную машину. Развертывание занимает менее 10 минут, но может занять больше времени в соответствии с типом развертывания.	Потенциальный сбой
Подключение к Azure	Сбой сети	Medium	Для обеспечения доступности сетевых подключений к Azure локальным службам Azure требуется подключение к Azure. Например, чтобы подготовить новые локальные виртуальные машины Azure или кластеры AKS, установить обновления решения с помощью Update Manager или отслеживать состояние работоспособности экземпляра с помощью Azure Monitor. Если подключение к Azure недоступно, экземпляр работает в ограниченном режиме, и эти возможности недоступны. Однако существующие рабочие нагрузки, которые уже выполняются в локальной среде Azure, продолжают выполняться. Если сетевое подключение к Azure не восстанавливается в течение 30 дней, экземпляр вводит состояние "Вне политики", которое может ограничить функциональные возможности. Мост ресурсов Azure не может быть отключен более чем на 45 дней, так как эта неактивность может повлиять на действительность ключа безопасности, используемого для проверки подлинности.	Операции управления недоступны

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

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

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

• SLO в 99,8% времени безотказной работы или доступности означает следующие допустимые периоды простоя для приложений, развернутых с использованием локальных виртуальных машин Azure, работающих на Azure Local.

  • Еженедельно: 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 ежемесячных резервных копий, при этом каждое воскресенье четвертой недели сохраняется, чтобы стать резервной копией месяца 1, месяца 2 и месяца 3 с использованием скользящего календарного расписания, который задокументирован и проверяем. Этот подход соответствует требованиям компании Contoso Manufacturing для обеспечения достаточного баланса между количеством доступных точек восстановления данных и сокращением затрат на обслуживание внесайтового или облачного хранилища резервных копий.

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

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

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

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

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

Redundancy

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

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

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

Security

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

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

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

• Журналы событий безопасности:Локальная пересылка syslog в 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: Эта функция помогает снизить затраты на исправление вручную и связанные расходы на обслуживание. Это действие не только помогает сделать систему более безопасной, но и оптимизирует выделение ресурсов и способствует общей эффективности затрат.

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

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

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

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

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

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

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

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

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

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

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

  • Рекомендации по включению автоматизации
  • Сравнение возможностей управления виртуальными машинами в локальной среде Azure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   Tip

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

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

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

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

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

Дальнейшие шаги

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

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

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

• Локальная служба Azure
• Azure Arc
• Хранилище ключей
• хранилище BLOB-объектов Azure
• Azure Monitor
• Политика Azure
• реестра контейнеров Azure
• Defender для облака
• Восстановление сайта
• Backup

Учебный курс Microsoft Learn:

• Настройка Azure Monitor
• Разработка решения для резервного копирования и аварийного восстановления
• Общие сведения о Azure Arc
• Введение в AKS
• обновление виртуальных машин
• Защитить виртуальные машины с помощью резервного копирования

Другие ресурсы:

• развертывание модели с помощью машинного обучения в любом месте — блог tech Community
• реализации машинного обучения в любом месте с помощью AKS и Машинного обучения с поддержкой Azure Arc — блог сообщества tech community
• Машинное обучение в гибридной среде AKS и локальной среде Azure с помощью машинного обучения с поддержкой Azure Arc — блог tech Community