Планирование интеграции центра обработки данных для интегрированных систем 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 является закрытой системой, в которой инфраструктура заблокирована как с точки зрения разрешений, так и с точки зрения сети. Для блокировки всего несанкционированного входящего трафика и всей ненужной связи между компонентами инфраструктуры применяются списки управления доступом к сети (ACL). Такая система затрудняет несанкционированный доступ к системе.
Администратору не предоставляется неограниченный доступ к инфраструктуре для ежедневного управления и совершения операций. Операторы 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. Такая интеграция позволяет управлять доступом на основе ролей (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>.<полное доменное имя>. Например, 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 для общедоступных конечных точек. На высоком уровне к сертификатам существуют следующие требования:
- Вы можете использовать один групповой сертификат или набор выделенных сертификатов и применять групповые сертификаты только для конечных точек, например хранилища данных и хранилища ключей.
- Сертификаты могут быть выданы общедоступным доверенным центром сертификации (ЦС) или ЦС, управляемым клиентом.
См. сведения о том, какие 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 v2). Для этого типа подключения требуется VPN-устройство или служба маршрутизации и удаленного доступа (RRAS). Дополнительные сведения о VPN-шлюзах в Azure см. в этой статье. Связь через этот туннель шифруется и защищена. Тем не менее пропускная способность ограничена максимальной пропускной способностью туннеля (100–200 Мбит/с).
NAT для исходящего трафика. По умолчанию все виртуальные машины в Azure Stack Hub будут подключаться к внешним сетям через исходящий NAT. Каждой виртуальной сети, созданной в Azure Stack Hub, назначается общедоступный IP-адрес. Независимо от того, назначен ли виртуальной машине общедоступный IP-адрес или она находится за балансировщиком нагрузки с общедоступным IP-адресом, она будет иметь исходящий доступ для исходящего трафика через NAT, используя виртуальный IP-адрес виртуальной сети. Этот метод применим только для связи, которая инициируется виртуальной машиной и направлена во внешнюю сеть (Интернет или интрасеть). Его нельзя использовать для обращения к виртуальной машине извне.
Гибридные варианты подключений
Для гибридного подключения важно рассмотреть, какое развертывание вы хотите предложить и где оно будет развернуто. Необходимо определить, нужна ли изоляция сетевого трафика для каждого клиента и тип связи с развертывании (в интрасети или Интернете).
Azure Stack Hub с одним арендатором: развертывание Azure Stack Hub, которое выглядит как развертывание с одним арендатором, по крайней, мере с точки зрения структуры сети. Существует много подписок клиентов, но, как и любая служба интрасети, весь трафик проходит по тем же сетям. Сетевой трафик из одной подписки перемещается по тому же сетевому подключению, что и другая подписка, и его не нужно изолировать через зашифрованный туннель.
Azure Stack Hub с несколькими арендаторами: развертывание Azure Stack Hub, в рамках которого трафик подписки каждого арендатора, связанного с сетями, которые являются внешними по отношению к Azure Stack Hub, должен быть изолирован от сетевого трафика других арендаторов.
Развертывание в интрасети: развертывание Azure Stack Hub, которое находится в корпоративной интрасети, обычно в пространстве частных IP-адресов и под защитой одного или нескольких брандмауэров. Общедоступные IP-адреса не являются полностью общедоступными, так как не маршрутизируются через Интернет.
Развертывание в Интернете: это развертывание Azure Stack Hub, которое подключено к общедоступному Интернету и использует общедоступные IP-адреса, поддерживающие маршрутизацию в Интернете, для диапазона общедоступных виртуальных ЛС. Развертывание по-прежнему может находиться за брандмауэром, но диапазон общедоступных виртуальных 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 для сценария с одним клиентом (где Customer's connection (подключение клиента) — это канал 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 |
| Физические серверы (BMC через IPMI) | Оборудование OEM — пакет управления поставщика Operations Manager Предоставленное поставщиком оборудования OEM решение Подключаемые модули Nagios поставщика оборудования Решение для мониторинга, поддерживаемое партнером OEM (включено) |
| Сетевые устройства (SNMP) | Обнаружение сетевых устройств Оperations 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 клиенты могут использовать гостевые технологии для защиты папок с файлами, данных приложений и состояния системы. Однако как организация или поставщик услуг вы можете предложить решение для резервного копирования и восстановления в том же центре обработки данных или извне в облаке.
Чтобы создать резервную копию виртуальных машин IaaS Linux или Windows, необходимо использовать решения резервного копирования с доступом к гостевой операционной системе для защиты файлов, папок, состояния операционной системы и данных приложений. Вы можете использовать Azure Backup, System Center Data Center Protection Manager или поддерживаемые продукты сторонних производителей.
Для репликации данных во вторичное расположение и оркестрации отработки отказа приложений в случае сбоя можно использовать Azure Site Recovery или поддерживаемые продукты сторонних производителей. Кроме того, приложения, поддерживающие встроенную репликацию, например Microsoft SQL Server, могут реплицировать данные в другое расположение, в котором выполняется приложение.
Подробнее
- Дополнительные сведения об использовании, покупке, партнерах и поставщиках оборудования OEM см. на странице продукта Azure Stack Hub.
- Сведения о стратегии развития и географической доступности для интегрированных систем Azure Stack Hub см. в техническом документе Azure Stack Hub: расширение Azure Stack Hub.