Планирование и подготовка развертывания кластера

Статья
06/01/2023

Планирование и подготовка к развертыванию производственного кластера очень важны. Существует множество факторов, которые необходимо учитывать. В этой статье описаны шаги для того, чтобы подготовить развертывание кластера.

Прочтите сведения о рекомендациях

Для успешного менеджмента приложений и кластеров Azure Fabric присутствует набор операций, которые мы рекомендуем выполнять с целью максимизации надежности производственной среды. Дополнительные сведения см. в статье Service Fabric: рекомендации по приложениям и кластерам.

Выбор ОС для кластера

Service Fabric позволяет создавать кластеры Service Fabric на любых виртуальных машинах или компьютерах под управлением Windows Server или Linux. Перед развертыванием кластера необходимо выбрать ОС: Windows или Linux. Каждый узел (виртуальная машина) в кластере управляется одной и той же ОС. Вы не можете смешивать виртуальные машины Windows и Linux в одном кластере.

Планирование ресурсов

Для любой рабочей развернутой службы важным шагом является планирование загрузки. Вот несколько моментов, которые необходимо учесть:

Начальное число типов узлов для кластера
Свойства каждого типа узла (размер, число экземпляров, первичный узел, доступ к Интернету, количество виртуальных машин и т. п.).
Надежность и устойчивость характеристик кластера.

Выберите начальное число типов узлов

Во-первых, необходимо выяснить, для чего будет использоваться создаваемый кластер и какие виды приложений планируется в нем развернуть. Есть ли у вашего приложения несколько служб, среди которых есть службы, которые должны быть общедоступными или доступными из Интернета? У служб (составляющих приложение) различные требования к инфраструктуре, например больше ОЗУ или тактов центрального процессора? Кластер Service Fabric может состоять более чем из одного типа узла: типа первичного узла и одного или нескольких типов непервичных узлов. Каждый тип узла соответствует набору масштабирования виртуальных машин. Каждый тип узла поддерживает возможность независимого масштабирования, имеет разные наборы открытых портов и собственные метрики емкости. Свойства узла и ограничения на размещение можно настроить для ограничения конкретных служб конкретными типами узлов. Дополнительные сведения см. в разделе Рекомендации по планированию загрузки кластера Service Fabric.

Выберите свойства узла для каждого типа узла

Типы узлов определяют номера SKU, количество и свойства виртуальных машин в связанном масштабируемом наборе.

Минимальный размер виртуальных машин для каждого типа узла зависит от выбранного уровня устойчивости. Прежде чем выбрать номер SKU виртуальной машины, убедитесь, что вы понимаете шаги, необходимые для выполнения вертикального масштабирования, если в будущем потребуется выбрать другой номер SKU виртуальной машины.

Минимальное количество виртуальных машин для типа первичного узла зависит от выбранного уровня надежности.

Ознакомьтесь с минимальными рекомендациями для типов первичных узлов, рабочих нагрузок с отслеживанием состояния на типах узлов, не являющихся первичными и рабочих нагрузок без отслеживания состояния на типах узлов, не являющихся первичными.

Число, превышающее минимальное количество узлов, следует выбирать, руководствуясь количеством реплик приложения или служб, которые вы хотите запустить на узле этого типа. Планирование ресурсов для приложений Service Fabric помогает оценить ресурсы, необходимые для выполнения приложений. Вы всегда можете увеличить или уменьшить масштаб кластера позже, чтобы он соответствовал рабочей нагрузке приложения.

Использование временных дисков ОС для масштабируемых наборов виртуальных машин

Временные диски ОС создаются в хранилище локальной виртуальной машины и не сохраняются в удаленном хранилище Azure. Они рекомендуются для всех типов узлов Service Fabric (основного и дополнительного), так как по сравнению с традиционными сохраняемыми дисками ОС, временные диски ОС:

Сокращают задержки при чтении и записи на диск ОС
обеспечивают более быстрое выполнение сброса и управление повторным созданием образа узла;
сокращают общие затраты (такие диски бесплатны и не требуют дополнительных затрат на хранение).

Временные диски ОС не являются определенной функцией Service Fabric, а представляют собой функцию масштабируемых наборов виртуальных машин Azure, сопоставленных с типами узлов Service Fabric. Для их использования с Service Fabric выполните следующее в шаблоне Azure Resource Manager кластера.

Убедитесь, что типы узлов задают поддерживаемые размеры виртуальных машин Azure для временных дисков ОС и что размер кэша виртуальной машины достаточен для поддержки размера диска ОС (см. Примечание ниже). Например:
```
"vmNodeType1Size": {
    "type": "string",
    "defaultValue": "Standard_DS3_v2"
```
Примечание.

Не забудьте выбрать размер виртуальной машины с размером кэша, равным или превышающим размер диска ОС самой виртуальной машины. в противном случае развертывание Azure может привести к ошибке (даже если изначально оно принято).
Укажите версию масштабируемого набора виртуальных машин (vmssApiVersion) 2018-06-01 или более позднюю:
```
"variables": {
    "vmssApiVersion": "2018-06-01",
```

В разделе масштабируемого набора виртуальных машин шаблона развертывания укажите параметр Local для diffDiskSettings.

"apiVersion": "[variables('vmssApiVersion')]",
"type": "Microsoft.Compute/virtualMachineScaleSets",
    "virtualMachineProfile": {
        "storageProfile": {
            "osDisk": {
                    "caching": "ReadOnly",
                    "createOption": "FromImage",
                    "diffDiskSettings": {
                        "option": "Local"
                    },
            }
        }
    }

Примечание.

Пользовательские приложения не должны иметь никаких зависимостей, файлов или артефактов на диске операционной системы, так как при обновлении ОС диск операционной системы будет потерян.

Примечание.

Существующие невременные VMSS нельзя обновить на месте, чтобы использовать временные диски. Чтобы выполнить миграцию, пользователям потребуется Добавить новый nodeType с временными дисками, переместить рабочие нагрузки в новый nodeType и Удалить существующий.

Дополнительные сведения и дополнительные параметры конфигурации см. в статье Диски с временными ОС для виртуальных машин Azure.

Выбор уровней устойчивости и надежности для кластера

Уровень устойчивости используется, чтобы указать системе привилегии, имеющиеся у виртуальных машин в базовой инфраструктуре Azure. Для типа первичного узла эта привилегия позволяет Service Fabric приостановить любой запрос инфраструктуры на уровне виртуальной машины (например, перезагрузку, переустановку из образа или перенос виртуальной машины), который влияет на требования к кворуму, установленные для системных служб и ваших служб с отслеживанием состояния. Для типов вторичных узлов эта привилегия позволяет Service Fabric приостановить любой запрос инфраструктуры на уровне виртуальной машины (например, перезагрузку, переустановку из образа и перенос виртуальной машины), который влияет на требования к кворуму, установленные для ваших служб с отслеживанием состояния. Чтобы узнать преимущества различных уровней и рекомендации в отношении того, какой уровень использовать и когда, см. раздел Характеристики устойчивости кластера.

Уровень надежности используется для задания числа реплик системных служб, которые будут выполняться в этом кластере на первичных узлах. Чем больше реплик, тем надежнее системные службы в кластере. Чтобы узнать преимущества различных уровней и рекомендации в отношении того, какой уровень использовать и когда, см. раздел Характеристики надежности кластера.

Включение обратных прокси-серверов и/или DNS

Службы, которые подключаются друг к другу в рамках кластера, обычно могут напрямую обратиться к конечным точкам другой службы, так как узлы в кластере расположены в пределах одной локальной сети. Чтобы упростить подключение между службами, Service Fabric предоставляет дополнительные службы: службу DNS и службу обратных прокси-серверов. Обе службы можно включить при развертывании кластера.

Так как многие службы, а именно контейнерные службы, могут содержать URL-адрес, возможность разрешить его с помощью стандартного протокола DNS (а не протокола службы именования) удобна, особенно в сценариях Lift-аnd-Shift приложения. Именно это и делает служба DNS. Она позволяет сопоставить DNS-имена с именем службы и, следовательно, разрешить IP-адреса конечных точек.

Службы адресов обратного прокси-сервера находятся в кластере, предоставляющем конечные точки HTTP, включая HTTPS. Обратный прокси-сервер значительно упрощает вызов других служб, предоставляя конкретный формат URI. Обратный прокси-сервер также выполняет шаги разрешения, подключения и повторные попытки для реализации коммуникации служб.

Подготовка к аварийному восстановлению

Для обеспечения высокого уровня доступности крайне важно гарантировать продолжение работы всех типов служб при любых сбоях. Это особенно важно в ситуациях незапланированных сбоев, которые находятся вне вашего контроля. В статье Подготовка к аварийному восстановлению описываются некоторые часто встречающиеся виды сбоев, которые могут привести к авариям, если их не смоделировать и не взять под контроль должным образом. Также рассматриваются способы устранения рисков и действия при аварии, если она все-таки произошла.

Контрольный список готовности рабочей среды

Готовы ли ваше приложение и кластер к приему рабочего трафика? Перед развертыванием кластера в рабочей среде выполните Контрольный список готовности рабочей среды. Обеспечьте бесперебойную работу приложения и кластера, выполнив шаги, указанные в этом контрольном списке. Мы настоятельно рекомендуем проверить все шаги перед переходом в рабочую среду.