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

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

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

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

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

Макет статьи

Архитектура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Три узла (или серверы):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения о разработке, приобретении и развертывании локального решения 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
• монитор
• политики Azure
• реестра контейнеров Azure
• Microsoft Defender для cloud
• Azure Site Recovery
• резервного копирования

Модули Microsoft Learn:

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