Относится к Configuration Manager (Current Branch)
Эти часто задаваемые вопросы о Configuration Manager в Microsoft Azure помогут вам понять, когда его следует использовать и как настроить.
Общие вопросы
Можно ли переместить локальные серверы Configuration Manager в Azure?
Да, этот сценарий поддерживается. Дополнительные сведения см. в разделе Поддержка сред виртуализации.
Должны ли все дочерние первичные сайты находиться в Azure с сайтом центра администрирования или локальной средой? Как насчет вторичных сайтов?
Репликация на основе файлов и баз данных для обмена данными типа "сеть — сеть" выигрывает от близости размещения в Azure. Однако весь трафик, связанный с клиентом, будет удаленным от серверов сайта и систем сайта. Если вы используете быстрое и надежное сетевое подключение между Azure и интрасетью с неограниченным тарифным планом, вы можете разместить всю инфраструктуру в Azure.
Если вы используете лимитный план данных, а доступная пропускная способность или стоимость являются проблемой, рассмотрите возможность размещения определенных сайтов и систем сайта в локальной среде. Затем используйте элементы управления пропускной способностью, встроенные в Configuration Manager. Также учитывайте эту конфигурацию, если сетевое подключение между Azure и интрасетью не является быстрым или может быть ненадежным.
Считается ли Configuration Manager в Azure "программное обеспечение как услуга" (SaaS)?
Нет, это инфраструктура как услуга (IaaS). Серверы инфраструктуры Configuration Manager размещаются на виртуальных машинах Azure.
Какие факторы наиболее важны при переносе Configuration Manager в Azure?
- Сеть
- Доступность
- Производительность
- Cost
- Взаимодействие с пользователем
Дополнительные сведения об этих факторах см. в других вопросах ниже.
Можно ли использовать Configuration Manager с Azure Stack Hub?
Да. Azure Stack Hub поддерживает виртуальные машины IaaS так же, как и облако Azure. Таким образом, Configuration Manager поддерживается в Azure Stack Hub так же, как в Azure IaaS.
Configuration Manager функции, подключенные к облаку, которые используют определенные облачные службы, не поддерживаются в Azure Stack Hub. Например, невозможно создать шлюз управления облаком (CMG) в Azure Stack Hub.
Сеть
Следует ли использовать ExpressRoute или VPN-шлюз Azure?
Корпорация Майкрософт рекомендует использовать ExpressRoute. Скорость сети и задержка могут повлиять на функциональность между сервером сайта и удаленными системами сайта, а также между любыми клиентскими данными с системами сайта.
В Configuration Manager для использования Azure VPN-шлюз нет ограничений. Следует внимательно изучить следующие требования этой инфраструктуры, а затем принять решение:
- Производительность
- Patching
- Распространение программного обеспечения
- Развертывание ОС
Рассмотрите следующие аспекты для каждого решения.
ExpressRoute (рекомендуется)
- Естественное расширение для центра обработки данных и может связать несколько центров обработки данных
- Частные подключения между центрами обработки данных Azure и инфраструктурой
- Не переходит через общедоступный Интернет
- Обеспечивает надежность, высокую скорость, меньшую задержку, высокий уровень безопасности
- Предлагает скорость до 10 Гбит/с и неограниченные возможности плана передачи данных
VPN-шлюз
- VPN типа "сеть — сеть" или "точка — сеть"
- Трафик проходит через общедоступный Интернет
- Использует протокол IPsec и обмен ключами Интернета (IKE)
Дополнительные сведения см. в статье ExpressRoute или Azure VPN.
Какие параметры ExpressRoute следует выбрать?
У всех по-разному. ExpressRoute имеет множество различных вариантов, таких как неограниченные или лимитные, различные варианты скорости и надстройки premium. Выбор параметров зависит от используемой функции Configuration Manager и объема данных, которые планируется распространить. Вы можете управлять передачей данных Configuration Manager между серверами сайта и точками распространения, но не можете управлять взаимодействием между серверами типа "сеть — сеть". При использовании тарифного плана данных, если вы размещаете определенные сайты и системы сайтов в локальной среде и используете встроенные элементы управления пропускной способностью Configuration Manager, вы можете контролировать затраты на использование Azure.
Нужно ли по-прежнему присоединять серверы сайта к домену Active Directory?
Да. При переходе в Azure поддерживаемые конфигурации остаются прежними, включая требования Active Directory для установки Configuration Manager.
Можно ли использовать идентификатор Microsoft Entra?
Нет. идентификатор Microsoft Entra в настоящее время не поддерживается. Серверы сайта по-прежнему должны быть членами домена Active Directory.
Доступность
Можно ли использовать параметры высокого уровня доступности, такие как группы доступности виртуальных машин Azure, с Configuration Manager?
Да. Группы доступности виртуальных машин Azure можно использовать для избыточных ролей системы сайта, таких как точки распространения или точки управления.
Их также можно использовать для серверов сайта Configuration Manager. Например, сайты центра администрирования и первичные сайты могут находиться в одной группе доступности. Эта конфигурация поможет вам убедиться, что они не перезагружаются одновременно.
Дополнительные сведения см. в разделах Параметры доступности для Azure Виртуальные машины и Параметры высокого уровня доступности для Configuration Manager.
Можно ли использовать базу данных сервера Azure SQL?
Нет. На виртуальной машине необходимо использовать SQL Server. Configuration Manager в настоящее время не поддерживает сервер Azure SQL.
Для обеспечения высокого уровня доступности сервера базы данных сайта используйте SQL Server Always On группы доступности. Дополнительные сведения см. в статье Подготовка к использованию группы доступности SQL Server Always On с Configuration Manager.
Можно ли использовать подсистемы балансировки нагрузки Azure с ролями системы сайта, такими как точки управления или точки обновления программного обеспечения?
Configuration Manager не тестируется с помощью подсистем балансировки нагрузки Azure. Если функциональность является прозрачной для приложения, она не должна оказывать негативного влияния на обычные операции.
Производительность
Какие факторы влияют на производительность в этом сценарии?
Следующие факторы являются наиболее важными для Configuration Manager производительности в Azure:
- Размер и тип виртуальной машины Azure
- Диски виртуальных машин Azure: рекомендуется использовать хранилище уровня "Премиум", особенно для SQL Server
- Задержка и скорость сети
Какой размер виртуальных машин следует использовать?
Как правило, вычислительная мощность (ЦП и память) должна соответствовать рекомендуемму оборудованию для Configuration Manager. Но существуют некоторые различия между обычным компьютерным оборудованием и виртуальными машинами Azure, особенно если речь идет о дисках, используемых этими виртуальными машинами. Используемый размер виртуальной машины зависит от размера вашей среды.
В следующем списке приведены некоторые общие рекомендации по размеру виртуальной машины.
- Для производственных развертываний любого значительного размера используйте виртуальные машины Azure класса S . Эти виртуальные машины могут использовать диски хранилища класса Premium. Виртуальные машины класса , отличные от S , используют хранилище BLOB-объектов и, как правило, не соответствуют требованиям к производительности, необходимым для приемлемой рабочей среды.
- Используйте несколько дисков хранилища уровня "Премиум" для более высокого масштаба и чередуются в консоли управления дисками Windows для максимального количества операций ввода-вывода в секунду.
- Используйте более качественные или несколько дисков уровня "Премиум" во время начального развертывания сайта. Например, P30 вместо P20 и два диска P30 в чередующемся томе вместо одного P30. Если сайту позже потребуется увеличить размер виртуальной машины из-за дополнительной нагрузки, вы можете воспользоваться дополнительными ЦП и памятью, которые предоставляет более крупный размер виртуальной машины. Кроме того, у вас уже есть диски, которые могут воспользоваться дополнительными преимуществами пропускной способности операций ввода-вывода в секунду, что позволяет более крупный размер виртуальной машины.
В следующих таблицах перечислены первоначально предлагаемые числа дисков, которые будут использоваться на первичных сайтах и сайтах центра администрирования для установки различных размеров.
База данных совместно расположенного сайта
Первичный сайт или сайт центра администрирования с базой данных сайта на сервере сайта:
| Клиенты настольных компьютеров | Рекомендуемый размер виртуальной машины | Рекомендуемые диски |
|---|---|---|
| < 25,000 | DS4_V2 | 2xP30 (полосатый) |
| от 25 000 до 50 000 | DS13_V2 | 2xP30 (полосатый) |
| от 50 000 до 100 000 | DS14_V2 | 3xP30 (полосатый) |
Удаленная база данных сайта
Первичный сайт или сайт центра администрирования с базой данных сайта на удаленном сервере:
| Клиенты настольных компьютеров | Рекомендуемый размер виртуальной машины | Рекомендуемые диски |
|---|---|---|
| < 25,000 | Сервер сайта: сервер базы данных F4S : DS12_V2 |
Сервер сайта: сервер базы данных 1xP30 : 2xP30 (чередуется) |
| от 25 000 до 50 000 | Сервер сайта: сервер базы данных F4S : DS13_V2 |
Сервер сайта: сервер базы данных 1xP30 : 2xP30 (чередуется) |
| от 50 000 до 100 000 | Сервер сайта: сервер базы данных F8S : DS14_V2 |
Сервер сайта: 2xP30 (чередуется) Сервер базы данных: 3xP30 (чередуется) |
Пример
На этом образе показан пример конфигурации диска для следующей виртуальной машины:
- Виртуальная машина DS14_V2 размера для сайта, который управляет от 50 000 до 100 000 клиентов.
- Три диска P30 в чередующемся томе
- Отдельные логические тома для файлов установки и базы данных Configuration Manager
Взаимодействие с пользователем
Почему взаимодействие с пользователем является main важной областью?
Решения, которые вы принимаете в отношении сети, доступности, производительности и расположения сервера сайта, могут напрямую повлиять на пользователей. Перемещение сайта в Azure должно быть прозрачным для пользователей, чтобы они не сталкивались с изменениями в повседневном взаимодействии с Configuration Manager.
Чтобы снизить затраты на один первичный сайт, должны ли удаленные системы сайтов находиться в Azure или локальной среде?
За исключением обмена данными с сервера сайта с точкой распространения, эти связи между серверами на сайте могут происходить в любое время и не использовать механизмы для управления использованием пропускной способности сети. Так как вы не можете контролировать обмен данными между системами сайта, такими как точки управления и точки обновления программного обеспечения, обязательно рассмотрите все затраты, связанные с этими коммуникациями.
Скорость сети и задержка также являются другими факторами, которые следует учитывать. Медленные или ненадежные сети могут повлиять на функциональность между сервером сайта и удаленными системами сайта, а также на взаимодействие клиента с системами сайта. Учитывайте количество управляемых клиентов, использующих данную систему сайта, и функции, которые вы активно используете.
В качестве отправной точки можно использовать стандартное руководство по системам сайта в разных каналах глобальной сети. В идеале пропускная способность сети, которую вы выбираете и получаете между Azure и интрасетью, будет соответствовать глобальной сети, которая хорошо подключена к быстрой сети.
Как насчет распространения содержимого и управления содержимым?
Подход к управлению содержимым во многом совпадает с подходом к серверам сайта и системам сайта.
Если вы используете быстрое и надежное сетевое подключение между Azure и интрасетью с неограниченным тарифным планом, размещение стандартных точек распространения в Azure может быть вариантом.
Если применяется какой-либо из следующих факторов:
- Вы используете план лимитных данных
- Стоимость пропускной способности является проблемой
- Сетевое подключение между Azure и интрасетью не является быстрым или может быть ненадежным.
Затем можно рассмотреть следующие другие подходы:
- Используйте стандартные точки распространения или точки распространения по запросу в локальной среде.
- Включите Windows BranchCache в точках распространения или других технологиях однорангового кэширования.
- Используйте шлюз управления облачными клиентами (CMG) с поддержкой содержимого. Обратите внимание, что он не поддерживает пакеты обновлений программного обеспечения для обновлений Майкрософт. Необходимо иметь альтернативное расположение или настроить развертывание обновлений программного обеспечения, чтобы клиенты могли получать содержимое обновлений из Интернета.
Примечание.
Если требуется поддержка PXE или многоадресной рассылки, вам потребуется локальная точка распространения для реагирования на эти запросы на загрузку.
Что можно сделать для поддержки интернет-клиентов вместо того, чтобы использовать точку управления с выходом в Интернет?
Используйте шлюз управления облаком (CMG). CMG предоставляет простой способ управления Configuration Manager клиентами в Интернете. Вы развертываете службу в подписке Azure, и она подключается к локальной инфраструктуре через точку соединителя шлюза управления облаком. Затем клиенты могут получать доступ к локальным ролям системы сайта независимо от того, подключены ли они к внутренней сети или Через Интернет.
Какую технологию однорангового кэширования следует использовать?
Одноранговый кэш — это 100 % собственная технология Configuration Manager. BranchCache и оптимизация доставки — это функции Windows. Все они могут быть полезны в зависимости от ваших требований. Дополнительные сведения, включая таблицу для сравнения функций, см. в статье Основы управления содержимым — технологии однорангового кэширования.
Cost
Будет ли перемещение Configuration Manager в Azure экономичным решением для моей организации?
Трудно сказать, так как каждая среда отличается. Чтобы оценить затраты для вашей среды, используйте калькулятор цен Azure.
Дополнительная информация
Где можно узнать больше об этих технологиях Azure?
Основы
Типы виртуальных машин Azure
Рекомендации по производительности диска
- Хранилище уровня "Премиум"
- Выбор типа диска виртуальных машин IaaS
- Целевые показатели масштабируемости и производительности для учетных записей хранения уровня "Стандартный"
- Запись блога о том, как работает хранилище уровня "Премиум"
Доступность
- Соглашение об уровне обслуживания Azure (SLA) для виртуальных машин
- Параметры доступности для виртуальных машин Azure