Зависимости службы веб-сайтов веб-сайтов пакета Windows Azure
Область применения: Windows Пакет Azure
Действия, описанные в данной главе, очень важны для проведения успешной установки службы веб-сайтов пакета веб-сайты. Внимательно прочитайте каждый раздел и выполните требуемые действия. Разделы главы:
Выбор среды с доменом или рабочей группой
Создать серверы для ролей веб-сайтов
Совет по подготовке VHD-файлов и серверов
Подготовить SQL Server для размещения базы данных времени выполнения службы веб-сайтов Windows Azure Pack
Подготовить базы данных приложений SQL Server и MySQL для использования клиентами
Конфигурация брандмауэра для ролей веб-сайтов
Настройте внешний интерфейс, издателя, рабочий веб-процесс, сервер управления и заранее не настроенную роль файлового сервера (необязательно) для получения доступа из Интернета
Настройка Windows Azure Pack. на использование прокси-серверов
Изменение правил контроля учетных записей для разрешения удаленного доступа
Настройка сопоставлений DNS для службы Web Sites Cloud
Выбор среды с доменом или рабочей группой
Зависимости службы веб-сайтов может быть установлена в среде с присоединением к домену или без него (в рабочей группе). Среда с рабочей группой может быть подходящей для разработки и тестирования, однако рекомендуется использовать среду, присоединенную к домену, по следующим причинам.
Пользователи могут использовать протокол Kerberos для проверки подлинности, что намного надежнее, чем протоколы NTLM и NTLM v2.
Упрощенное управление пользователями и учетными данными.
Улучшенные возможности управления посредством групповых политик
Создать серверы для ролей веб-сайтов
До установки облака службы веб-сайтов подготовьте по одному серверу Windows Server 2012 R2 на каждую роль службы веб-сайтов (серверы могут быть как физическими, так и виртуальными). Позднее для обеспечения высокого уровня доступности следует добавить более одного сервера на роль. Для упрощения поддержки системы используйте описательные имена компьютеров, как в примерах ниже. Согласно соглашению об именовании рекомендуется заменять символ «x» в каждом имени на «1» (добавляя нули при необходимости) и затем увеличивать это число по мере добавления к роли экземпляров серверов.
SitesCNx — контроллер облака службы веб-сайтов
SitesMNx — сервер управления облаком службы веб-сайтов
SitesFEx — внешний интерфейс облака службы веб-сайтов
SitesPBx — издатель облака службы веб-сайтов
SitesWWSx — общая рабочая роль облака службы веб-сайтов
SitesWWRx — зарезервированная рабочая роль облака службы веб-сайтов
SitesFSx — файловый сервер облака службы веб-сайтов
Совет по подготовке VHD-файлов и серверов
Проводите чистую установку Windows Server 2012 (рекомендуется версия Windows Server 2012 R2).
Не размещаете роли службы веб-сайтов на одной машине, каждая роль должна иметь отдельный сервер или ВМ.
Не размещайте роли службы веб-сайтов на серверах с API-интерфейсами или порталами (для клиентов или администраторов). Например, роль контроллера облака службы веб-сайтов и роль интерфейса Admin API должны быть на отдельных машинах.
Рекомендуется использовать присоединенные к домену серверы, как было сказано ранее.
Если используются ВМ, то рекомендуется сохранить моментальные снимки для каждой роли на следующих этапах:
Перед установкой
После установки
После настройки
Примечание
Чтобы избежать ошибок NetBIOS и автоматического усечения имен, следите за тем, чтобы имена компьютеров не превышали 15 символов в длину.
Подготовить SQL Server для размещения базы данных времени выполнения службы веб-сайтов Windows Azure Pack
Подготовьте базу данных SQL Server для базы данных времени выполнения службы веб-сайтов. Рекомендуется, чтобы все роли сервера SQL Server, включая базу данных времени выполнения службы веб-сайтов, базу данных интерфейса Service Management API, которая является ее частью, размещались на раздельных машинах.
Для тестирования, разработки или прототипирования можно использовать SQL Express 2012 с пакетом обновления 1 (SP1) или более поздней версии. Сведения о скачивании см. в статье Download SQL Server 2012 Express with SP1 (Скачивание SQL Server 2012 Express с пакетом обновления 1).
В финальном продукте следует использовать полную версию SQL 2012 с пакетом обновления 1 (SP1) или более позднюю. Сведения об установке SQL Server см. в статье Установка SQL Server.
Должен быть включен смешанный режим проверки подлинности.
SQL Server времени выполнения службы веб-сайтов должен быть доступен для всех ролей этой службы.
Для любой роли SQL Server можно использовать экземпляр по умолчанию или именованный экземпляр. Однако, если используется именованный экземпляр, вручную запустите службу обозревателя SQL и откройте порт 1434.
Дополнительные сведения см. в статье Using SQL Server or MySQL with Windows Azure Pack.
Подготовить базы данных приложений SQL Server и MySQL для использования клиентами
Для среды может потребоваться поддержка клиентских приложений баз данных SQL Server или MySQL. В этом случае нужно установить и настроить отдельные экземпляры SQL Server и MySQL, предназначенные для обслуживания клиентской базы данных приложения.
Требования к серверу базы данных SQL Server для клиентских приложений.
Должен быть включен смешанный режим проверки подлинности.
Сервер SQL Server должен быть доступен из рабочей веб-роли и роли издателя
Сервер SQL Server должен быть доступен из ролей интерфейсов Admin и Tenant API
Требования к серверу базы данных MySQL для клиентских приложений.
Пользователь root должен иметь удаленный доступ с паролем через интерфейс командной строки MySQL. Пример синтаксиса:
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION; FLUSH PRIVILEGES;
Дополнительные сведения про интерфейс командной строки MySQL см. в разделе Документация по MySQL.
Сервер MySQL должен быть доступен из рабочей веб-роли и роли издателя
Сервер MySQL должен быть доступен из ролей интерфейсов Admin и Tenant API
Для поддержки IPv6 используйте MySQL версии 5.5.30 или более поздней
Дополнительные сведения см. в статье Configure SQL Server and MySQL Application databases for tenant use. Сведения о масштабировании SQL Server для использования в рабочей среде см. в разделе Configuring SQL Server for High Availability.
Конфигурация брандмауэра для ролей веб-сайтов
Если служба веб-сайтов Windows Azure Pack полностью реализуется в интранет-окружении, то публичный доступ из Интернета не является обязательным. (Даже если доступ из Интернета обязателен, хорошо спланированная топология сети может предотвратить прямой доступ к ролям службы веб-сайтов из Интернета.)
Перед добавлением к серверу роли службы веб-сайтов следует настроить параметры брандмауэра сервера. В следующем списке обобщены требования, касающиеся доступа из Интернета, для каждой роли службы веб-сайтов.
Сервер управления — открытый доступ из Интернета не требуется.
Файловый сервер — доступ из Интернета не требуется, более того, эта роль никогда не должна быть доступна из Интернета.
Контроллер службы веб-сайтов — требуется исходящий HTTP-доступ, но не входящий. Роли контроллера требуется исходящий доступ для загрузки ПО, необходимого для установки ролей службы веб-сайтов.
Рабочие веб-роли — не требуется входящий доступ из Интернета, но может требоваться исходящий доступ, если, например, веб-приложение обращается к внешней веб-службе.
Серверам внешнего интерфейса в зависимости от сетевой топологии может требоваться прямой входящий доступ из сети для принятия клиентских запросов на веб-сайты.
Издатели — в зависимости от сетевой топологии может требоваться прямой входящий доступ для принятия запросов публикации FTP или WebDeploy.
Для ролей внешнего интерфейса и издателей можно избежать предоставления прямого доступа из Интернета, если использовать подсистемы балансировки исходящей нагрузки или NAT-устройств, выполняющих преобразование сетевых адресов с внешних во внутренние.
Настройте внешний интерфейс, издателя, рабочий веб-процесс, сервер управления и заранее не настроенную роль файлового сервера (необязательно) для получения доступа из Интернета
На серверах, где будут размещены роли внешнего интерфейса, рабочего веб-процесса, издателя и сервера управления, разрешите доступ извне к следующим службам. Также необходимо применить эти параметры к роли файлового сервера, если используется заранее не настроенный вариант роли файлового сервера.
Общий доступ к папкам и принтерам (SMB-In)
Инструментарий управления Windows (WMI-In)
Для настройки доступа извне можно использовать следующие команды netsh.
netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes
netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes
Примечание
Сетевые адаптеры для ролей внешнего интерфейса и издателя должны использовать в брандмауэре Windows открытый профиль.
Настройка Windows Azure Pack. на использование прокси-серверов
Если для исходящего доступа к Интернету используется прокси-адрес, следует разрешить службе веб-сайтов использовать этот прокси-адрес до установки службы веб-сайты.
Примечание
Проверка подлинности веб-фермы через прокси-сервер в данный момент не поддерживается. В этом разделе описаны действия, которые следует выполнить, для установки и запуска службы веб-сайтов при работе через прокси-сервер. Здесь дается описание настройки прокси-серверов.
Чтобы разрешить ферме обмен данным через прокси-сервер без проверки подлинности, выполните следующие команды PowerShell с правами администратора на компьютере с контроллером службы. Замените <ProxyAddress> адресом прокси-сервера.
Import-Module WebSites
Set-WebSitesConfig Global -ProxyEnabled True -ProxyAddress <ProxyAddress>
Примечание
При установке службы веб-сайтов для Windows Azure Pack запустите установщик веб-платформы с помощью учетной записи, которая может пройти проверку подлинности на прокси-сервере.
Предоставление разрешения центру обновления Майкрософт обращаться к службе веб-сайтов Windows Azure Pack при работе через прокси-сервер
В том случае, когда служба веб-сайтов работает через прокси как дополнительный шаг, рекомендуется включить получение центра обновления Майкрософт, чтобы они могли правильно работать со службой веб-сайты. Для этого выполните следующие команды PowerShell с правами администратора на контроллере, где user <ProxyUser> с паролем <ProxyUserPassword> может пройти проверку подлинности в прокси-сервере:
Import-Module WebSites
New-WebSitesConfig Credential -CredentialName ProxyUserCredential -UserName <ProxyUser> -Password <ProxyUserPassword> -CredentialType SystemCredential
Изменение правил контроля учетных записей для разрешения удаленного доступа
На каждом сервере, где будет размещена роль службы веб-сайтов, отключите контроль учетных записей (UAC) для удаленных подключений, как описано ниже. Это позволит выполнять удаленное администрирование.
Примечание
Локальная конфигурация контроля учетных записей не изменится.
Выполните следующую команду в командной строке с повышенными привилегиями:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Перезапустите сервер.
Настройка сопоставлений DNS для службы Web Sites Cloud
Во время установки облака службы веб-сайтов настройке контроллера будет выдан запрос на ввод имени домена, которое по умолчанию будет использоваться для веб-сайтов конечных пользователей.
По умолчанию веб-сайты создаются в домене по умолчанию. После создания веб-сайта пользователи могут добавлять собственные имена доменов для каждого веб-сайта. Хотя клиентские веб-сайты можно настроить для работы с пользовательскими доменами, служба веб-сайтов Windows Azure Pack не обновляет пользовательские записи DNS. Чтобы все веб-сайты, доступные из Интернета, имели подходящие назначения IP-адресов, следуйте руководству, приведенному ниже.
Для определенного домена, например Contoso.com, создайте следующие записи DNS типа A:
Имя узла |
IP-адрес для |
* |
Серверы внешнего интерфейса |
*.scm |
Серверы внешнего интерфейса |
ftp |
Серверы публикаций |
Опубликовать |
Серверы публикаций |
Эта схема сопоставления позволяет пользователям выполнять вход как на свои сайты, так https://www.contoso.com и https://contoso.com управлять ими. Портал управления для администраторов и портал управления для клиентов описываются в разделе Развертывание Windows Azure Pack для Windows Server.
В примере конфигурации выше созданные пользователями веб-сайты изначально создаются с помощью дочерних доменов, таких как site1.contoso.com, site2.contoso.com.
Когда пользователи публикуют содержимое в своих веб-сайтах через инструмент веб-развертывания или FTP, они будут использовать publish.contoso.com или ftp.contoso.com соответственно. При публикации содержимого с помощью git используется адрес *.scm.contoso.com.
Примечание
Для этого развертывания не требуется специального домена. Можно использовать дочерний домен, например my.yourdomain.com, существующего домена.