Рекомендации по планированию интеграции центра обработки данных для интегрированных систем Azure Stack Hub
Если вы заинтересованы в интегрированной системе Azure Stack Hub, следует понять основные аспекты планирования развертывания и как система вписывается в центр обработки данных. В этой статье представлен общий обзор этих рекомендаций, которые помогут вам принимать важные решения по инфраструктуре для интегрированных систем Azure Stack Hub. Понимание этих рекомендаций помогает при работе с поставщиком оборудования OEM при развертывании Azure Stack Hub в центре обработки данных.
Заметка
Интегрированные системы Azure Stack Hub можно приобрести только у авторизованных поставщиков оборудования.
Чтобы развернуть Azure Stack Hub, необходимо предоставить сведения о планировании поставщику решений перед началом развертывания, чтобы помочь процессу быстро и гладко. Информация, необходимая в таких областях, как сети, безопасность и идентификация, включает множество важных решений, которые могут требовать знаний из различных сфер и от разнообразных руководителей. Вам потребуются пользователи из нескольких команд в вашей организации, чтобы убедиться, что все необходимые сведения готовы перед развертыванием. Полезно поговорить с вашим поставщиком оборудования в процессе сбора этой информации, потому что у них могут быть полезные советы.
При изучении и сборе необходимых сведений вам может понадобиться внести некоторые изменения в предварительную конфигурацию вашей сетевой среды. Эти изменения могут включать резервирование пространств IP-адресов для решения Azure Stack Hub, а также настройку маршрутизаторов, коммутаторов и брандмауэров для подготовки к подключению к новым коммутаторам решения Azure Stack Hub. Убедитесь, что у вас есть эксперт в данной области, который поможет вам в планировании.
Рекомендации по планированию емкости
При оценке решения Azure Stack Hub для приобретения вы можете выбрать конфигурацию оборудования, которая напрямую влияет на общую емкость решения Azure Stack Hub. К ним относятся классические варианты ЦП, плотности памяти, конфигурации хранилища и общего масштаба решения (например, количество серверов). В отличие от традиционного решения виртуализации, простая арифметика этих компонентов для определения используемой емкости не применяется. Первая причина заключается в том, что Azure Stack Hub разработан для размещения компонентов инфраструктуры или управления в самом решении. Вторая причина заключается в том, что некоторые из возможностей решения зарезервированы в поддержку устойчивости путем обновления программного обеспечения решения таким образом, чтобы свести к минимуму нарушения рабочих нагрузок клиента.
Электронная таблица планировщика емкости Azure Stack Hub помогает принимать обоснованные решения о планировании емкости двумя способами. Первый способ - выбрать аппаратное решение и попытаться подобрать комбинацию ресурсов. Во-вторых, определите рабочую нагрузку, которую должен поддерживать Azure Stack Hub, чтобы увидеть доступные модели аппаратных SKU, способных его поддерживать. Наконец, электронная таблица предназначена для принятия решений, связанных с планированием и настройкой Azure Stack Hub.
Электронная таблица не предназначена для того, чтобы служить заменой для собственного исследования и анализа. Корпорация Майкрософт не предоставляет никаких представлений или гарантий, явных или подразумеваемых в отношении информации, предоставленной в электронной таблице.
Рекомендации по управлению
Azure Stack Hub — это запечатаная система, в которой инфраструктура заблокирована как с разрешениями, так и с точки зрения сети. Списки управления доступом к сети применяются для блокировки всего несанкционированного входящего трафика и всех ненужных подключений между компонентами инфраструктуры. Эта система затрудняет доступ несанкционированных пользователей к системе.
Для ежедневного управления и операций нет неограниченного доступа администратора к инфраструктуре. Операторы Azure Stack Hub должны управлять системой с помощью портала администрирования или с помощью Azure Resource Manager (с помощью PowerShell или REST API). Нет доступа к системе другими инструментами управления, такими как диспетчер Hyper-V или Диспетчер отказоустойчивого кластера. Чтобы защитить систему, стороннее программное обеспечение (например, агенты) не может быть установлено в компонентах инфраструктуры Azure Stack Hub. Взаимодействие с внешним программным обеспечением управления и безопасности происходит через PowerShell или REST API.
Обратитесь в службу поддержки Майкрософт, если вам нужен более высокий уровень доступа для устранения проблем, которые не решаются с помощью мер по урегулированию оповещений. Благодаря поддержке существует метод предоставления временного полного доступа администратора к системе для более сложных операций.
Рекомендации по идентификации
Выбор поставщика удостоверений
Вам нужно определить, какого поставщика удостоверений вы хотите использовать для развертывания Azure Stack Hub: Microsoft Entra ID или AD FS. После развертывания невозможно переключить поставщиков удостоверений без полного повторного развертывания системы. Если вы не владеете учетной записью Microsoft Entra и используете учетную запись, предоставленную поставщиком облачных решений, и если вы решите переключить поставщик и использовать другую учетную запись Microsoft Entra, вам придется обратиться к поставщику решений для повторного развертывания решения по вашим затратам.
Выбор поставщика удостоверений не имеет никакой связи с виртуальными машинами клиента, системой удостоверений, учетными записями, которые они используют, или могут ли они присоединиться к домену Active Directory и т. д. Эти вещи отдельны.
Вы можете развернуть несколько систем Azure Stack Hub с одинаковым клиентом Microsoft Entra или Active Directory.
Интеграция AD FS и Graph
Если вы решили развернуть Azure Stack Hub с использованием AD FS в качестве поставщика удостоверений, необходимо интегрировать экземпляр AD FS на Azure Stack Hub с существующим экземпляром AD FS через федеративное доверие. Эта интеграция позволяет удостоверениям в существующем лесу Active Directory проходить проверку подлинности с помощью ресурсов в Azure Stack Hub.
Вы также можете интегрировать службу Graph в Azure Stack Hub с существующим Active Directory. Эта интеграция позволяет управлять Role-Based управление доступом (RBAC) в Azure Stack Hub. При делегировании доступа к ресурсу компонент Graph ищет учетную запись пользователя в существующем лесу Active Directory с помощью протокола LDAP.
На следующей схеме показан интегрированный поток трафика AD FS и Graph.
Схема 
Модель лицензирования
Необходимо решить, какую модель лицензирования вы хотите использовать. Доступные параметры зависят от развертывания Azure Stack Hub, подключенного к Интернету:
- Для подключенного развертывания можно выбрать лицензирование с оплатой по мере использования или на основе емкости. Для услуги «оплата по факту использования» требуется подключение к Azure для фиксации объема использования, который затем выставляется через торговую платформу Azure.
- При развертывании отключенных из Интернета поддерживается только лицензирование на основе емкости.
Дополнительные сведения о моделях лицензирования см. в разделе по оформлению и ценам на Microsoft Azure Stack Hub.
Решения об именовании
Вам потребуется подумать о том, как спланировать пространство имен Azure Stack Hub, особенно имя региона и внешнее доменное имя. Внешнее полное доменное имя (FQDN) развертывания Azure Stack Hub для общедоступных конечных точек — это сочетание этих двух имен: <region>.<fqdn>. Например, east.cloud.fabrikam.com. В этом примере порталы Azure Stack Hub будут доступны по следующим URL-адресам:
https://portal.east.cloud.fabrikam.comhttps://adminportal.east.cloud.fabrikam.com
Важный
Имя региона, выбранное для развертывания Azure Stack Hub, должно быть уникальным и будет отображаться на адресах портала.
В следующей таблице перечислены эти решения об именовании домена.
| Имя | Описание |
|---|---|
| Имя региона | Имя вашего первого региона Azure Stack Hub. Это имя используется как часть полного доменного имени для общедоступных виртуальных IP-адресов ,которым управляет Azure Stack Hub. Как правило, имя региона будет физическим идентификатором расположения, например расположением центра обработки данных. Имя региона должно состоять только из букв и чисел от 0 до 9. Не допускаются специальные символы (например, -, #и т. д.). |
| Внешнее доменное имя | Имя зоны доменных имен (DNS) для конечных точек с внешними IP-адресами. Используется в FQDN для этих общедоступных виртуальных IP-адресов. |
| Частное (внутреннее) доменное имя | Имя домена (и внутренней зоны DNS), созданного в Azure Stack Hub для управления инфраструктурой. |
Требования к сертификату
Для развертывания необходимо предоставить сертификаты SSL для общедоступных конечных точек. На высоком уровне сертификаты имеют следующие требования:
- Вы можете использовать один подстановочный сертификат или использовать набор выделенных сертификатов, а затем использовать подстановочные знаки только для конечных точек, таких как хранилище и Key Vault.
- Сертификаты могут быть выданы доверенным общедоступным центром сертификации (ЦС) или центром сертификации, управляемым клиентом.
Дополнительные сведения о том, какие сертификаты PKI необходимы для развертывания Azure Stack Hub и как их получить, см. в требования к сертификату инфраструктуры открытого ключа Azure Stack Hub.
Важный
Предоставленные сведения о сертификате PKI должны использоваться в качестве общих рекомендаций. Прежде чем приобрести сертификаты PKI для Azure Stack Hub, обратитесь к своему партнеру по оборудованию OEM. Они будут предоставлять более подробные рекомендации и требования, касающиеся сертификатов.
Синхронизация времени
Необходимо выбрать конкретный сервер времени, используемый для синхронизации Azure Stack Hub. Синхронизация времени важна для Azure Stack Hub и его инфраструктурных ролей, так как она используется для создания тикетов Kerberos. Тикеты Kerberos используются для аутентификации внутренних служб между собой.
Необходимо указать IP-адрес сервера синхронизации времени. Хотя большинство компонентов инфраструктуры могут обрабатывать URL-адреса, некоторые из них поддерживают только IP-адреса. Если вы используете отключенный вариант развертывания, необходимо указать сервер времени в корпоративной сети, который, как вы уверены, доступен из сети инфраструктуры в Azure Stack Hub.
Важный
Если сервер времени не является сервером NTP под управлением Windows, необходимо добавить ,0x8 в конец IP-адреса. Например, 10.1.1.123,0x8.
Подключение Azure Stack Hub к Azure
Для сценариев гибридного облака необходимо спланировать подключение Azure Stack Hub к Azure. Существует два поддерживаемых метода подключения виртуальных сетей в Azure Stack Hub к виртуальным сетям в Azure:
типа "сеть — сеть": подключение виртуальной частной сети (VPN) через IPsec (IKE v1 и IKE версии 2). Для этого типа подключения требуется VPN-устройство или служба маршрутизации и удаленного доступа (RRAS). Дополнительные сведения о VPN-шлюзах в Azure см. в статье О VPN-шлюзе. Обмен данными по этому туннелю шифруется и защищается. Однако пропускная способность ограничена максимальной пропускной способностью туннеля (100–200 Мбит/с).
исходящий NAT. По умолчанию все виртуальные машины в Azure Stack Hub будут иметь подключение к внешним сетям через исходящий NAT. Каждая виртуальная сеть, созданная в Azure Stack Hub, получает общедоступный IP-адрес, назначенный ему. Независимо от того, назначен ли виртуальной машине напрямую общедоступный IP-адрес или она находится за балансировщиком нагрузки с общедоступным IP-адресом, она будет иметь исходящий доступ через исходящий NAT, используя виртуальный IP-адрес (VIP) виртуальной сети. Этот метод работает только для обмена данными, инициируемыми виртуальной машиной и предназначенными для внешних сетей (интернет или интрасети). Его нельзя использовать для взаимодействия с виртуальной машиной извне.
Параметры гибридного подключения
Для гибридного подключения важно рассмотреть вопрос о том, какой тип развертывания вы хотите предложить и где он будет развернут. Вам потребуется указать, нужно ли изолировать сетевой трафик для каждого клиента и будет ли у вас интрасетя или интернет-развертывание.
ОдноарендныйAzure Stack Hub: развертывание Azure Stack Hub, которое выглядит, по крайней мере с точки зрения сети, как будто это один клиент. Существует множество подписок клиента, но, как и любая служба интрасети, все трафик перемещается по одной сети. Сетевой трафик из одной подписки проходит через то же сетевое подключение, что и из другой подписки, и его не требуется изолировать через зашифрованный туннель.
многопользовательскийAzure Stack Hub: развертывание Azure Stack Hub, в котором трафик каждой подписки арендатора, направленный в сети, внешние по отношению к Azure Stack Hub, должен быть изолирован от сетевого трафика других арендаторов.
Развертывание интрасети : Развертывание Azure Stack Hub, расположенное в корпоративной интрасети, обычно в пространстве частных IP-адресов и за одним или несколькими брандмауэрами. Общедоступные IP-адреса не являются действительно общедоступными, так как они не могут быть перенаправлены непосредственно через общедоступный Интернет.
Интернет-развертывание: Развертывание Azure Stack Hub, подключенное к публичному интернету и использующее публичные IP-адреса для диапазона публичных VIP-адресов. Развертывание по-прежнему может находиться за брандмауэром, но общедоступный диапазон ВИРТУАЛЬНЫх IP-адресов доступен напрямую из общедоступного Интернета и Azure.
В следующей таблице приведены примеры сценариев гибридного подключения с преимуществами, минусами и вариантами использования.
| Сценарий | Метод подключения | Плюсы | Минусы | Хорошо для |
|---|---|---|---|---|
| Однотенантное развертывание Azure Stack Hub, интрасети | Исходящий NAT | Улучшенная пропускная способность для ускорения передачи. Простой для реализации; шлюзы не требуются. | Трафик не зашифрован; отсутствие изоляции или шифрования за пределами стека. | Корпоративные развертывания, в которых все клиенты одинаково доверенны. Предприятия с каналом Azure ExpressRoute в Azure. |
| Многотенантное развертывание Azure Stack Hub, развертывание внутри сети. | VPN типа "сеть — сеть" | Трафик из виртуальной сети клиента в место назначения является безопасным. | Пропускная способность ограничена VPN-туннелем между сетями. Требуется шлюз в виртуальной сети и VPN-устройство в целевой сети. |
Корпоративные развертывания, в которых некоторый трафик клиента должен быть защищен от других клиентов. |
| Единый клиент Azure Stack Hub, развертывание Интернета | Исходящий NAT | Улучшенная пропускная способность для ускорения передачи. | Трафик не зашифрован; отсутствие изоляции или шифрования за пределами стека. | Сценарии размещения, в которых арендатор получает собственное развертывание Azure Stack Hub и выделенный канал для доступа к среде Azure Stack Hub. Например, ExpressRoute и многоадресная коммутация методом меток (MPLS). |
| Многопользовательское развертывание Azure Stack Hub, развертывание подключений к Интернету | Межсайтовый VPN | Трафик из виртуальной сети клиента в место назначения является безопасным. | Пропускная способность ограничена VPN-туннельом типа "сеть — сеть". Требуется шлюз в виртуальной сети и VPN-устройство в целевой сети. |
Сценарии размещения, в которых поставщик хочет предложить мультитенантное облако, где клиенты не доверяют друг другу, и трафик должен быть зашифрован. |
Использование ExpressRoute
Azure Stack Hub можно подключить к Azure с помощью ExpressRoute для сценариев интрасети с одним клиентом и несколькими клиентами. Вам потребуется зарезервированный канал ExpressRoute через поставщика подключения.
На следующей схеме показан ExpressRoute для сценария с одним клиентом (где "Подключение клиента" — это канал ExpressRoute).
Схема 
На следующей схеме показан ExpressRoute для сценария с несколькими клиентами.
Схема 
Внешний мониторинг
Чтобы получить единое представление обо всех оповещениях из развертывания и устройств Azure Stack Hub, а также интегрировать оповещения в существующие рабочие процессы управления ИТ-службами для работы с заявками, вы можете интегрировать Azure Stack Hub с решениями для мониторинга внешних центров обработки данных.
Входит в решение Azure Stack Hub, узел жизненного цикла оборудования — это компьютер за пределами Azure Stack Hub, на котором работают средства управления, предоставляемые поставщиком OEM для оборудования. Вы можете использовать эти инструменты или другие решения, которые напрямую интегрируются с существующими решениями мониторинга в вашем центре обработки данных.
В следующей таблице приведен список доступных вариантов.
| Площадь | Решение внешнего мониторинга |
|---|---|
| Программное обеспечение Azure Stack Hub |
Пакет управления Azure Stack Hub для Operations Manager плагин Nagios Вызовы API на основе REST |
| Физические серверы (BMCs с помощью IPMI) | Оборудование OEM — пакет управления поставщиками Operations Manager Предоставленное поставщиком оборудования OEM решение Плагины для Nagios от производителя аппаратного обеспечения. Поддерживаемое партнером OEM решение для мониторинга (включено) |
| Сетевые устройства (SNMP) | Обнаружение сетевых устройств в Operations Manager Предоставленное поставщиком оборудования OEM решение Подключаемый модуль коммутатора Nagios |
| Мониторинг работоспособности подписки клиента | пакет управления System Center для Windows Azure |
Обратите внимание на следующие требования:
- Используемое решение не должно требовать установки агента. Не удается установить сторонние агенты в компонентах Azure Stack Hub.
- Если вы хотите использовать System Center Operations Manager, требуется Operations Manager 2012 R2 или Operations Manager 2016.
Резервное копирование и аварийное восстановление
Планирование резервного копирования и аварийного восстановления включает планирование базовой инфраструктуры Azure Stack Hub, включающей виртуальные машины IaaS и службы PaaS, а также для приложений и данных клиента. Запланируйте эти вещи отдельно.
Защита компонентов инфраструктуры
Вы можете выполнить резервное копирование компонентов инфраструктуры Azure Stack Hub на указанный SMB-ресурс:
- Вам потребуется внешний файловый ресурс SMB на существующем файловом сервере под управлением Windows или стороннем устройстве.
- Используйте эту же общую папку для резервного копирования сетевых коммутаторов и узла жизненного цикла оборудования. Поставщик оборудования OEM поможет предоставить рекомендации по резервному копированию и восстановлению этих компонентов, так как они являются внешними для Azure Stack Hub. Вы несете ответственность за выполнение рабочих процессов резервного копирования на основе рекомендации поставщика OEM.
Если происходит катастрофическая потеря данных, вы можете использовать резервную копию инфраструктуры для повторного развертывания данных, таких как:
- Входные данные развертывания и идентификаторы
- Учетные записи служб
- Корневой сертификат ЦС
- Федеративные ресурсы (в неподключенных развертываниях)
- Планы, предложения, подписки и квоты
- Политики RBAC и назначения ролей
- Секреты Key Vault
Предупреждение
По умолчанию метка Azure Stack Hub настроена только с одной учетной записью CloudAdmin. Параметры восстановления отсутствуют, если учетные данные учетной записи потеряны, скомпрометированы или заблокированы. Вы потеряете доступ к привилегированной конечной точке и другим ресурсам.
Настоятельно рекомендуется создавать дополнительные учетные записи CloudAdmin, чтобы избежать повторного развертывания инфраструктуры за ваш счет. Убедитесь, что вы задокументируете эти учетные данные на основе рекомендаций вашей компании.
Защита приложений клиента на виртуальных машинах IaaS
Azure Stack Hub не поддерживает резервное копирование приложений и данных клиента. Необходимо спланировать защиту резервного копирования и аварийного восстановления на целевой внешний объект в Azure Stack Hub. Защита клиентов — это действие, управляемое клиентом. Для виртуальных машин IaaS клиенты могут использовать гостевые технологии для защиты папок файлов, данных приложения и состояния системы. Однако, как предприятие или поставщик услуг, вы можете захотеть предложить решение резервного копирования и восстановления в том же центре обработки данных или внешне в облаке.
Чтобы создать резервную копию виртуальных машин Linux или Windows IaaS, необходимо использовать продукты резервного копирования с доступом к гостевой операционной системе для защиты файлов, папок, состояния операционной системы и данных приложения. Вы можете использовать Azure Backup, System Center Datacenter Protection Manager или поддерживаемые сторонние продукты.
Чтобы реплицировать данные во вторичное местоположение и оркестрировать переключение на резервный ресурс приложения в случае аварии, можно использовать Azure Site Recovery или поддерживаемые сторонние продукты. Кроме того, приложения, поддерживающие собственную репликацию, такие как Microsoft SQL Server, могут реплицировать данные в другое место, где работает приложение.
Подробнее
- Сведения о вариантах использования, покупках, партнерах и поставщиках оборудования OEM см. на странице продукта Azure Stack Hub.
- Сведения о стратегии и геодоступности интегрированных систем Azure Stack Hub см. в техническом документе: Azure Stack Hub: расширение Azure.