Планирование и подготовка развертывания изолированного кластера Service Fabric
Перед созданием кластера выполните следующее.
Планирование инфраструктуры кластера
Вы собираетесь создать кластер Service Fabric на принадлежащих вам компьютерах, поэтому вам нужно решить, к каким сбоям должен быть устойчив кластер. Например, нужны ли отдельные линии электропитания или подключения к Интернету для этих компьютеров? Кроме того, следует также учитывать физическую безопасность этих компьютеров. Где находятся компьютеры и кому необходим доступ к ним? После принятия этих решений вы можете логически сопоставить компьютеры с различными доменами сбоя (см. следующий шаг). Планирование инфраструктуры для рабочих кластеров требует больше усилий, чем для тестовых кластеров.
Определение количества доменов сбоя и доменов обновления
Домен сбоя (FD) — это физическая единица сбоя, непосредственно связанная с физической инфраструктурой в центрах обработки данных. Домен сбоя состоит из аппаратных компонентов (компьютеры, коммутаторы, сеть и многое другое), совместно использующих единую точку отказа. Хотя нет однозначного соответствия между доменами сбоя и стойками, грубо говоря, каждую стойку можно считать доменом сбоя.
При указании доменов сбоя в файле ClusterConfig.json можно выбрать имя для каждого из них. Service Fabric поддерживает иерархические домены сбоя, поэтому в них можно отразить имеющуюся топологию инфраструктуры. Например, допускаются следующие домены сбоя.
- "faultDomain": "fd:/Room1/Rack1/Machine1"
- "faultDomain": "fd:/FD1"
- "faultDomain": "fd:/Room1/Rack1/PDU1/M1"
Домен обновления — это логическая единица узлов. Во время обновления под управлением Service Fabric (обновления приложения или кластера) все узлы в домене обновления отключаются, а узлы в других доменах обновления остаются доступными для обслуживания запросов. Обновления встроенного ПО, выполняемые на компьютерах, не связаны с работой доменов обновления, поэтому их необходимо выполнять на компьютерах по очереди.
Проще всего рассматривать эти понятия, считая домен сбоя единицей незапланированного сбоя, а домен обновления — единицей планового обслуживания.
При указании доменов обновления в файле ClusterConfig.json можно выбрать имя для каждого из них. Например, допускаются следующие имена:
- "upgradeDomain": "UD0"
- "upgradeDomain": "UD1A"
- "upgradeDomain": "DomainRed"
- "upgradeDomain": "Blue"
Дополнительные сведения о доменах обновления и доменах сбоя см. в статье Описание кластера Service Fabric.
Если вы полностью контролируете обслуживание и использование узлов, то есть несете ответственность за обновление и замену компьютеров, кластер должен охватывать не менее трех доменов сбоя, чтобы он поддерживался в рабочей среде. Для кластеров, запущенных в средах (т. е. экземплярах виртуальных машин Amazon Web Services), в которых у вас нет полного контроля над компьютерами, требуется как минимум пять доменов сбоя в кластере. Каждый домен сбоя может содержать один или несколько узлов. Это позволяет предотвратить проблемы, вызванные обновлениями компьютеров, которые в зависимости от их расписания могут влиять на работу приложений и служб в кластерах.
Определение исходного размера кластера
Как правило, количество узлов в кластере определяется в зависимости от бизнес-требований, т. е. от того, сколько служб и контейнеров будет запущено в кластере и сколько ресурсов требуется для обработки рабочих нагрузок. Для рабочих кластеров рекомендуется наличие по крайней мере пять узлов в кластере, охватывающем пять доменов сбоя. Однако, как описано выше, если имеется полный контроль над узлами и возможность охвата троих доменов сбоя, три узла также должны выполнить задание.
Тестовые кластеры, выполняющие рабочие нагрузки с отслеживанием состояния, должны иметь три узла, тогда как для тестовых кластеров, выполняющих только рабочие нагрузки без отслеживания состояния, требуется только один узел. Важно отметить, что в целях разработки на одном компьютере можно настроить более одного узла. Однако в рабочей среде Service Fabric поддерживает только один узел на физический компьютер или виртуальную машину.
Подготовка компьютеров, которые будут работать в качестве узлов
Ниже приведены рекомендуемые спецификации для компьютеров в кластере Service Fabric:
- Не менее 16 ГБ ОЗУ.
- Наличие не менее 40 ГБ свободного дискового пространства.
- Центральный процессор с 4 ядрами или больше.
- Подключение к защищенной сети или сетям для всех компьютеров.
- Установленная ОС Windows Server (допустимые версии: 2012 R2, 2016, 1709 или 1803). Service Fabric версии 6.4.654.9590 и более поздних также поддерживают Server 2019 и 1809.
- Полностью установленная платформа .NET Framework 4.5.1 или более поздней версии.
- Windows PowerShell 3.0.
- На всех компьютерах должна быть запущена служба RemoteRegistry.
- Установочный диск Service Fabric должен иметь формат файловой системы NTFS.
- Журналы производительности и оповещения служб Windows, а такжежурналы событий Windows должны быть включены.
- Удаленный контроль учетных записей пользователей должен быть отключен
Важно!
У администратора кластера, который развертывает и настраивает кластер, должны быть привилегии администратора на всех компьютерах. Пакет Service Fabric нельзя установить на контроллере домена.
Скачивание изолированного пакета Service Fabric для Windows Server
Скачайте изолированный пакет Service Fabric для Windows Server и извлеките его содержимое на компьютер развертывания, который не является частью кластера, или на один из компьютеров, которые будут частью кластера.
Изменение конфигурации кластера
Чтобы создать изолированный кластер, для него необходимо создать файл конфигурации ClusterConfig.json, описывающий характеристики кластера. Можно создать этот файл на основе шаблонов, доступных по ссылке ниже.
Конфигурации изолированного кластера
Сведения о разделах в этом файле см. в статье Параметры конфигурации для автономного кластера Windows.
Откройте один из файлов ClusterConfig.json из скачанного пакета и настройте следующие параметры.
| Параметр конфигурации | Description |
|---|---|
| NodeTypes | Типы узлов позволяют разделить узлы кластера на различные группы. У кластера должен быть по крайней мере один NodeType. Все узлы в группе имеют следующие общие характеристики: Name — имя типа узла. Endpoint ports — различные именованные конечные точки (порты), связанные с этим типом узла. Вы можете использовать любой номер порта, который не конфликтует с другими компонентами в этом манифесте и не используется другим приложением на компьютере или виртуальной машине. Placement Properties — свойства для типа узла, с помощью которых задаются ограничения на размещение системных или своих служб. Эти свойства представляют собой определяемые пользователем пары "ключ-значение", которые содержат дополнительные метаданные для заданного узла. К свойствам узла относится, например, наличие у него жесткого диска или видеоадаптера, количество шпинделей в его жестком диске, число ядер и другие физические качества. Capacities — емкость узла определяет имя и величину конкретного ресурса, доступного для использования на определенном узле. Например, для узла может быть определена емкость для метрики MemoryInMb и выделено 2048 МБ памяти, доступной по умолчанию. Емкости используются во время выполнения, чтобы гарантировать, что службы, которым требуется определенный объем ресурсов, будут размещены на узлах, обладающих такими ресурсами. IsPrimary — при наличии нескольких определенных типов узлов убедитесь, что только один из них назначен первичным (это свойство имеет значение true) и на нем выполняются системные службы. Узлам всех остальных типов необходимо присвоить значение false. |
| Узлы | Сведения о каждом узле, который является частью кластера (тип узла, имя узла, IP-адрес, домен сбоя и домен обновления узла). В этом разделе необходимо перечислить компьютеры, на основе которых вы хотите создать кластер, и их IP-адреса. Если использовать одинаковые IP-адреса для всех узлов, будет создан универсальный кластер, который можно использовать для тестирования. Не используйте универсальные кластеры для развертывания рабочих нагрузок в рабочей среде. |
После настройки всех параметров конфигурации кластера в среде эту конфигурацию можно протестировать в среде кластера (шаг 7).
Настройка среды
Когда администратор кластера настраивает автономный кластер Service Fabric, среда должна быть настроена со следующими критериями:
У пользователя, создающего кластер, должны быть привилегии безопасности уровня администратора для всех компьютеров, которые указаны в качестве узлов в файле конфигурации кластера.
На компьютере, с которого создается кластер, а также на каждом компьютере узла кластера требуется выполнить следующее.
- Удалите пакет SDK для Service Fabric.
- Удалите среду выполнения Service Fabric.
- Включите службу брандмауэра Windows (mpssvc).
- Включите службу удаленного управления реестром (remote registry).
- Включите общий доступ к файлам (SMB).
- Откройте необходимые порты в соответствии с конфигурацией портов кластера.
- Откройте необходимые порты для Windows SMB и службы удаленного управления реестром: 135, 137, 138, 139 и 445.
- Установите сетевые подключения между ними.
Ни один из компьютеров узлов кластера не должен быть контроллером домена.
Если развертывается безопасный кластер, проверьте, установлены и настроены ли обязательные компоненты системы безопасности в соответствии с конфигурацией.
Если компьютеры в составе кластера не имеют доступ к Интернету, задайте в конфигурации кластера следующие параметры:
- Отключите телеметрию: в разделе properties задайте параметр "enableTelemetry": false.
- Отключите автоматическое скачивание версий Service Fabric и уведомления о том, что приближается окончание срока поддержки текущей версии кластера: в разделе properties задайте параметр "fabricClusterAutoupgradeEnabled": false.
- Кроме того, если доступ из Интернета к сети ограничен доменами из списка разрешений, для автоматического обновления необходимы такие домены: go.microsoft.com, download.microsoft.com.
Установите соответствующие исключения при проверке антивирусной программой для Service Fabric:
| Исключаемые при проверке антивирусной программой каталоги |
|---|
| Program Files\Microsoft Service Fabric |
| FabricDataRoot (из конфигурации кластера) |
| FabricLogRoot (из конфигурации кластера) |
| Исключаемые при проверке антивирусной программой процессы |
|---|
| Fabric.exe |
| FabricHost.exe |
| FabricInstallerService.exe |
| FabricSetup.exe |
| FabricDeployer.exe |
| ImageBuilder.exe |
| FabricGateway.exe |
| FabricDCA.exe |
| FabricFAS.exe |
| FabricUOS.exe |
| FabricRM.exe |
| FileStoreService.exe |
Проверка среды с помощью сценария TestConfiguration
Сценарий TestConfiguration.ps1 можно найти в изолированном пакете. Он используется как анализатор соответствия рекомендациям и позволяет проверить некоторые описанные выше условия. Его следует использовать для проверки работоспособности развертывания кластера в конкретной среде. В случае любого сбоя обратитесь к списку в подразделе Настройка среды, чтобы устранить неполадки.
Этот сценарий может выполняться на любом компьютере, у которого есть доступ администратора ко всем компьютерам, перечисленным в качестве узлов в файле конфигурации кластера. Компьютер, на котором выполняется этот сценарий, может и не входить в кластер.
PS C:\temp\Microsoft.Azure.ServiceFabric.WindowsServer> .\TestConfiguration.ps1 -ClusterConfigFilePath .\ClusterConfig.Unsecure.DevCluster.json
Trace folder already exists. Traces will be written to existing trace folder: C:\temp\Microsoft.Azure.ServiceFabric.WindowsServer\DeploymentTraces
Running Best Practices Analyzer...
Best Practices Analyzer completed successfully.
LocalAdminPrivilege : True
IsJsonValid : True
IsCabValid : True
RequiredPortsOpen : True
RemoteRegistryAvailable : True
FirewallAvailable : True
RpcCheckPassed : True
NoConflictingInstallations : True
FabricInstallable : True
Passed : True
В настоящее время данный модуль тестирования конфигурации не проверяет конфигурацию безопасности, поэтому ее нужно проверить отдельно.
Примечание.
Мы постоянно вносим улучшения для повышения надежности модуля. Поэтому, если вы обнаружили сбои в работе модуля TestConfiguration или полагаете, что в нем чего-то не хватает, сообщите нам через поддерживаемые каналы.