Распространенные вопросы о Service Fabric

Пользователи задают множество схожих вопросов о возможностях и использовании Service Fabric. В этом документе приведены ответы на многие из этих вопросов.

Настройка кластера и управление им

Как откатить сертификат кластера Service Fabric?

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

Если кластер по-прежнему использует классическое свойство отпечатка сертификата в шаблоне Resource Manager, рекомендуется изменить кластер с отпечатка сертификата на общее имя, чтобы применить современные функции управления секретами.

Можно ли создать кластер, охватывающий несколько регионов Azure или моих центров обработки данных?

Да.

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

Если вы заинтересованы в этом сценарии, мы рекомендуем обратиться в список проблем Service Fabric GitHub или через представителя службы поддержки, чтобы получить дополнительные рекомендации. Команда разработчиков Service Fabric работает над тем, чтобы предоставить дополнительные сведения, указания и рекомендации для данного сценария.

Необходимо учитывать следующие факторы.

1. На данный момент кластерный ресурс Service Fabric в Azure относится к определенному региону, как и масштабируемые наборы виртуальных машин, на основе которых создан кластер. Это означает, что в случае регионального сбоя вы можете утратить возможность управления кластером с помощью Azure Resource Manager или портала Azure. Это может произойти, даже если кластер продолжает работать и вы можете напрямую взаимодействовать с ним. Кроме того, Azure сегодня не предлагает возможность использовать одну виртуальную сеть, которая подходит для использования в разных регионах. Это означает, что для кластера, охватывающего несколько регионов Azure, требуются либо общедоступные IP-адреса для каждой виртуальной машины в масштабируемых наборах виртуальных машин, либо VPN-шлюзы Azure. Эти варианты сетевых подключений по-разному влияют на затраты, производительность и, в некоторой степени, на структуру приложений, поэтому перед внедрением такой среды требуется выполнить тщательный анализ и планирование.
2. Обслуживание, мониторинг этих компьютеров и управление ими может стать сложной задачей, особенно в том случае, если они распределены по средам разных типов, например, между разными поставщиками облачных служб или между локальными ресурсами и Azure. Перед запуском производственных рабочих нагрузок в такой среде необходимо убедиться в том, что операции обновления, мониторинга, управления и диагностики понятны как для кластера, так и для приложений. Если у вас уже есть опыт решения этих проблем в Azure или в собственных центрах обработки данных, скорее всего, эти же решения можно применить при создании или запуске кластера Service Fabric.

Получают ли узлы Service Fabric обновления операционной системы автоматически?

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

Для кластеров, которые не выполняются в Azure, мы предоставили приложение для исправления операционных систем на узлах службы Fabric.

При использовании автоматического обновления образа ОС кластеры Service Fabric должны следовать документированным рекомендациям по масштабированию обновлений типа узла или поэтапным обновлениям, чтобы управлять доменами обновления и поддерживать доступность приложений. Сведения об обновлении до Windows Server 2022 или Windows Server 2025 см. в руководстве по обновлению образа ОС для основных узлов и неосновных узлов.

До какого времени Windows Server 2019 поддерживается для кластеров Service Fabric?

Поддержка служб Fabric для кластеров, работающих на Windows Server 2019, завершается 31 марта 2027 года. Azure Virtual Machine Scale Sets с Windows Server 2019 будет продолжать работать после этой даты, но поддержка службы Fabric прекращается в эту дату. Служба Fabric поддерживает Windows Server образы ОС только через основные даты окончания поддержки, а явные объявления о выходе на пенсию заменяют общее правило. Запланируйте перенос кластеров на Windows Server 2025 заблаговременно, до 31 марта 2027 года, и проведите проверку совместимости приложений на образах Windows Server 2025 с помощью промежуточного кластера и документированного процесса последовательного обновления. Для получения дополнительной информации ознакомьтесь со страницей поддерживаемых версий Службы Fabric и анонсом о снятии с поддержки.

Можно ли использовать большие масштабируемые наборы виртуальных машин в кластере Service Fabric?

Краткий ответ. Нет.

Подробный ответ. Хотя большие масштабируемые наборы виртуальных машин можно масштабировать до 1000 экземпляров виртуальных машин, это делается с помощью групп размещения. Домены сбоя (FDs) и домены обновления (UDs) согласовываются только в пределах группы размещения. Service Fabric использует домены сбоя и домены обновления для принятия решений о размещении реплик служб или их экземпляров. Так как FD и UD сопоставимы только в группе размещения, SF не может использовать их. Например, если vm1 в PG1 имеет топологию FD=0 и VM9 в PG2 имеет топологию FD=4, это не означает, что VM1 и VM2 находятся на двух разных аппаратных стоек, поэтому SF не может использовать значения FD в этом случае для принятия решений о размещении.

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

Каков минимальный размер кластера Service Fabric? Почему он не может быть меньше?

Минимальный поддерживаемый размер кластера Service Fabric с рабочими нагрузками — пять узлов. Для сценариев разработки мы поддерживаем кластеры с одним узлом, (оптимизированные для быстрой разработки в Visual Studio) и кластеры с пятью узлами.

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

1. Даже если не запущена ни одна служба пользователя, в кластере Service Fabric выполняется ряд системных служб с отслеживанием состояния, включая службу имен и службу диспетчера отработки отказов. Эти системные службы важны для сохранения работоспособности кластера.
2. Мы всегда размещаем одну реплику службы на каждом узле, поэтому размер кластера является верхним пределом для числа реплик, допустимых для службы (фактически для секции).
3. Так как обновление кластера приведет к остановке как минимум одного узла, нам требуется буфер хотя бы из одного узла. Таким образом, дополнительно к абсолютному минимуму нам необходим рабочий кластер по меньшей мере с двумя узлами. Допустимый минимум — это размер кворума системной службы, как описано ниже.

Необходимо, чтобы кластер оставался доступным в случае одновременного сбоя двух его узлов. Для обеспечения доступности кластера Service Fabric должны быть доступны системные службы. Системные службы, такие как служба имен и служба управления отработкой отказов, которые отслеживают, какие службы развернуты в кластере и где они в настоящее время размещены, зависят от сильной согласованности. Эта строгая согласованность, в свою очередь, зависит от способности обеспечить кворум для любого обновления состояния этих служб, где кворум представляет собой строгое большинство реплик (N/2 + 1) для данной службы. Таким образом, если мы хотим быть устойчивыми к одновременной потере двух узлов (одновременная потеря двух реплик системной службы), необходимо иметь ClusterSize - QuorumSize >= 2, что заставляет минимальный размер быть пять.

Обратите внимание, что в приведенном выше аргументе предполагается, что каждый узел имеет реплику системной службы; Таким образом, размер кворума вычисляется на основе количества узлов в кластере. Однако, изменив значение параметра TargetReplicaSetSize, можно было бы сделать размер кворума меньше чем (N / 2 + 1), создать впечатление, что у нас может быть кластер с числом узлов меньше пяти и при этом иметь два дополнительных узла помимо размера кворума. Например, если в кластере с четырьмя узлами параметру TargetReplicaSetSize задать значение 3, размер кворума на основе TargetReplicaSetSize будет равен (3 / 2 + 1) или 2, поэтому неравенство имеет вид ClusterSize (размер_кластера) – QuorumSize (размер_кворума) = 4 – 2 >= 2. Однако мы не можем гарантировать, что системная служба будет в кворуме или выше, если мы одновременно потеряем любую пару узлов. Возможно, что два узла, которые мы потеряли, размещали две реплики, из-за чего системная служба теряет кворум (у нее остается только одна реплика) и становится недоступной.

С учетом этого давайте рассмотрим некоторые возможные конфигурации кластера.

Один узел: этот параметр не обеспечивает высокую доступность, так как потеря одного узла по какой-либо причине означает потерю всего кластера.

Два узла. Кворум для службы, развернутой на двух узлах (N = 2), составляет 2 узла (2/2 + 1 = 2). Потеря одной реплики делает создание кворума невозможным. Поскольку выполнение обновления службы требует временного отключения реплики, это не полезная конфигурация.

Три узла. В случае трех узлов (N = 3) для создания кворума по-прежнему нужно два узла (3/2 + 1 = 2). Это означает, что можно потерять один узел и по-прежнему сохранить кворум. Однако при одновременном сбое двух узлов системные службы перейдут в состояние потери кворума и кластер станет недоступен.

Четыре узла. В случае четырех узлов (N = 4) для создания кворума нужно три узла (4 / 2 + 1 = 3). Это означает, что можно потерять один узел и по-прежнему сохранить кворум. Однако при одновременном сбое двух узлов системные службы перейдут в состояние потери кворума и кластер станет недоступен.

Пять узлов. В случае пяти узлов (N = 5) для создания кворума нужно по-прежнему три узла (5 / 2 + 1 = 3). Это означает, что можно потерять два узла одновременно и по-прежнему сохранить кворум для системных служб.

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

Можно ли отключить кластер на ночь или выходные дни для снижения расходов?

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

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

Как обновить операционную систему (например, с Windows Server 2012 до Windows Server 2016)?

Рекомендуемый подход: выполнять обновление образа ОС через расширение типов узлов и использование поддерживаемых пошаговых процедур, чтобы избежать воздействия на приложение; затем освободить и удалить старые узлы. Используйте документированный метод горизонтального масштабирования и масштаба вниз для типа узлов, чтобы добавить узлы с новым образом ОС, перенести рабочие нагрузки и вывести из эксплуатации узлы на старом образе ОС. Эта процедура применяется к обновлению с Windows Server 2019 до Windows Server 2022 или до Windows Server 2025 года. Пошаговые инструкции см. в разделах Масштабирование первичных узлов кластера Service Fabric и Масштабирование непервичных узлов кластера Service Fabric.

Можно ли зашифровать присоединенные диски данных в типе узла кластера (масштабируемый набор виртуальных машин)?

Да. Дополнительные сведения см. в разделе Создание кластера с подключенными дисками данных и статье Шифрование дисков Azure для масштабируемых наборов виртуальных машин.

Можно ли использовать низкоприоритетные виртуальные машины в типе узла кластера (масштабируемый набор виртуальных машин)?

№ Низкоприоритетные виртуальные машины не поддерживаются.

Какие каталоги и процессы необходимо исключить при запуске антивирусной программы в кластере?

Как приложение может выполнить аутентификацию в Key Vault и получить секреты?

Ниже описаны способы, с помощью которых ваше приложение может получить учетные данные для аутентификации в Key Vault:

А. Во время выполнения задания по сборке и упаковке вы можете включить сертификат в пакет данных вашего приложения SF и использовать его для аутентификации в Key Vault. B. Для узлов масштабируемого набора виртуальных машин с включенной поддержкой MSI следует разработать простой сценарий PowerShell SetupEntryPoint для вашего приложения Service Fabric, чтобы получить маркер доступа из конечной точки MSI, а затем получить секреты из Key Vault.

Можно ли перенести подписку в другой клиент Microsoft Entra?

№ В настоящее время необходимо создать новый ресурс кластера Service Fabric после передачи подписки другому клиенту Microsoft Entra.

Можно ли переместить или перенести кластер между клиентами Microsoft Entra?

№ В настоящее время необходимо создать новый ресурс кластера Service Fabric в новом клиенте.

Можно ли переносить кластер между подписками?

№ В настоящее время необходимо создать новый ресурс кластера Service Fabric в новой подписке.

Можно ли переместить или перенести ресурсы кластера или кластера в другие группы ресурсов или переименовать их?

№ В настоящее время необходимо создать новый ресурс кластера Service Fabric в новой группе ресурсов или имени.

Проектирование приложений

Как лучше запрашивать данные из всех разделов Reliable Collection?

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

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

Как лучше запрашивать данные из моих субъектов?

Акторы предназначены для работы в качестве независимых единиц состояния и вычислений, поэтому не рекомендуется выполнять широкие запросы состояния актора в процессе выполнения. Если вам нужно сделать запрос по всему набору состояния актора, вы должны рассмотреть один из следующих вариантов:

• Замените ваши актерские службы на надежные службы с отслеживанием состояния, чтобы уменьшить количество сетевых запросов от числа актеров до числа разделов в вашей службе.
• Разрабатывать акторы для того, чтобы они периодически передавали своё состояние во внешнее хранилище для упрощения выполнения запросов. Как описано выше, этот подход подходит только в том случае, если выполняемые запросы не требуются для поведения среды выполнения.

Сколько данных можно сохранить в Reliable Collection?

Reliable Services обычно состоит из нескольких разделов, поэтому объем данных, которые можно хранить, ограничивается только числом компьютеров в кластере и объемом доступной памяти на этих компьютерах.

Допустим, у вас есть надежная коллекция в службе со 100 разделами и 3 репликами, хранящая объекты со средним размером 1 КБ. Теперь предположим, что имеется кластер из 10 компьютеров с 16 ГБ памяти на каждом компьютере. Чтобы обеспечить простоту и умеренность оценки, предположим, что операционная система и системные службы, среда выполнения Service Fabric и службы используют 6 ГБ, оставляя свободными 10 ГБ на каждом компьютере, или 100 ГБ на кластер.

Учитывая, что каждый объект должен быть сохранен трижды (основная копия и две реплики), памяти будет достаточно примерно для 35 миллионов объектов в коллекции при полной загрузке. Тем не менее мы рекомендуем обеспечить устойчивость к одновременной потере домена сбоя и домена обновления, что составляет около трети емкости, что сократило бы количество примерно до 23 миллионов объектов.

Эта оценка также основана на следующих предположениях:

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

• Рассматриваемая надежная служба является единственной, которая сохраняет состояние в кластере. Так как в кластере можно развернуть несколько служб, необходимо учитывать ресурсы, которые необходимо запускать для каждой из них, и управлять состоянием этих служб.

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

Сколько данных можно хранить в акторе?

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

Где поставщик ресурсов Service Fabric хранит данные клиентов?

Поставщик ресурсов Azure Service Fabric не перемещает или не хранит данные клиента из региона, в который он развернут.

Другие вопросы

Как Service Fabric связана с контейнерами?

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

Планируете создать решение на базе Service Fabric с открытым исходным кодом?

Мы предоставляем элементы Service Fabric с открытым кодом (платформа Reliable Services, платформа Reliable Actors, библиотеки интеграции ASP.NET Core, Service Fabric Explorer и CLI Service Fabric) на сайте GitHub и принимаем предложения сообщества по усовершенствованию этих проектов.

Недавно мы объявили о намерении открыть исходный код среды выполнения Service Fabric. Сейчас у нас есть репозиторий Service Fabric на GitHub с инструментами для сборки и тестирования на Linux. Это означает, что вы можете клонировать репозиторий, собрать Service Fabric для Linux, проводить базовые тесты, создавать задачи и отправлять pull-запросы. Мы прилагаем все усилия, чтобы также перенести окружение для сборки Windows вместе со всем окружением CI.

Для получения более подробной информации следите за блогом Service Fabric, где они будут анонсированы.

Следующие шаги

Узнайте о концепциях среды выполнения Service Fabric и рекомендациях.

Планируйте миграцию с Windows Server 2019 заранее до 31 марта 2027 года, просмотрите страницу поддерживаемые версии Service Fabric и следуя процедурам обновления ОС для основных типов узлов и неосновных типов узлов.