Архитектура без переключения локального хранилища Azure

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

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

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

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

Макет статьи

Architecture

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

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

Используйте эту структуру и проекты, описанные в эталонной архитектуре локальных базовых показателей Azure, для решения следующих требований к использованию:

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

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

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

Компоненты архитектуры

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

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

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

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

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

Структура сети относится к общему расположению физических и логических компонентов в сети. В конфигурации без переключения хранилища с тремя узлами для локальной среды Azure три физических узла напрямую подключены без использования внешнего коммутатора для трафика хранилища. Эти прямые сетевые подключения упрощают проектирование сети, уменьшая сложность, так как на коммутаторах нет необходимости определять или применять конфигурации обеспечения качества хранения и приоритета. Технологии, которые лежат в основе связи RDMA без потери, такие как явное уведомление о перегрузке (ECN), управление потоками приоритета (PFC) или качество обслуживания (QoS), необходимые для RoCE версии 2 и iWARP, не требуются. Однако эта конфигурация поддерживает не более четырех компьютеров, что означает, что нельзя масштабировать экземпляр, добавляя дополнительные узлы после развертывания для существующего экземпляра без переключения хранилища узлов.

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

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

• Три узла (или компьютеры):

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

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

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

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

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

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

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

  • Это прямое взаимодействие устраняет необходимость дополнительных портов сетевого коммутатора для хранилища и удаляет требование применить конфигурацию QoS или PFC для трафика SMB Direct или RDMA на сетевых коммутаторах.

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

• Переключатели двойной верхней части стойки (ToR):

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

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

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

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

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

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

    

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

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

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

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

• Локальная служба Azure применяет сетевую автоматизацию и конфигурацию сети на основе намерений с помощью службы Network ATC.

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

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

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

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

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

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

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

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

  • Узлы взаимодействуют друг с другом напрямую для трафика хранилища с помощью четырех прямых портов Ethernet между подключениями на узел, которые используют шесть отдельных сетей, отличных от сети (или уровня 2) для трафика хранилища.

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

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

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

    

    Схема, демонстрирующая логическую топологию сети для трехузлового локального экземпляра Azure. В нем используется архитектура хранилища без переключения с двумя коммутаторами ToR для внешнего подключения (или на юге).

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

Чтобы развернуть бессерверную конфигурацию хранилища Azure Local с двумя ссылками для межсоединений хранилища, платформа инфраструктуры кластера требует выделения не менее 20 x IP-адресов. Дополнительные IP-адреса требуются, если вы используете устройство виртуальной машины, предоставленное партнером производителя оборудования, или при использовании микросегментации или программно-определенных сетей (SDN). Дополнительные сведения см. в статье Ознакомьтесь с требованиями к IP-адресам шаблона хранилища с тремя узлами для локальногоAzure.

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

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

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

Considerations

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Локальная служба Azure
• Azure Arc
• Azure Key Vault
• хранилище BLOB-объектов Azure
• Monitor
• Политика Azure
• реестра контейнеров Azure
• Microsoft Defender для cloud
• Azure Site Recovery
• Backup

Модули Microsoft Learn:

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