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

  • Статья

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

Примечание.

Мы рекомендуем использовать модуль Azure Az PowerShell для взаимодействия с Azure. Чтобы начать работу, см. статью Установка Azure PowerShell. Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.

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

Как откатить сертификат кластера 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, мы предоставили приложение, которое устанавливает исправления для операционных систем на узлах Service Fabric.

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

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

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

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

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

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

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

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

Необходимо, чтобы кластер оставался доступным в случае одновременного сбоя двух его узлов. Для обеспечения доступности кластера Service Fabric должны быть доступны системные службы. Системные службы с отслеживанием состояния (например, служба имен и служба диспетчера отработки отказа), которые отслеживают, какие службы развернуты в кластере и где они в настоящее время размещены, существенно зависят от целостности кластера. Эта целостность, в свою очередь, зависит от возможности получения кворума для любого обновления состояния служб, где кворум означает строгое большинство реплик (N/2 + 1) для данной службы. Поэтому чтобы обеспечить устойчивость при одновременной потере двух узлов (т. е. при одновременной потере двух реплик системной службы), мы должны соблюсти неравенство ClusterSize (размер_кластера) – QuorumSize (размер_кворума) >= 2, при котором минимальный размер равен 5. С учетом этого давайте рассмотрим ситуацию, когда существует кластер с N узлами и N репликами системной службы (по одной на каждом узле). Размер кворума для системной службы — (N / 2 + 1). Приведенное выше неравенство имеет вид N – (N / 2 + 1) >= 2. Необходимо учитывать два возможных случая: когда N является четным числом и когда N является нечетным. Если N является четным, например N = 2m, где m >= 1, то неравенство имеет вид 2m – (2m / 2 + 1) >= 2 или m >= 3. Минимальное значение N равно 6. Оно получается, когда m = 3. С другой стороны, если N является нечетным, например N = 2m + 1, где m >= 1, неравенство имеет вид 2m+1 – ((2m + 1) / 2 + 1) >= 2, или 2m +1 – (m + 1) >= 2 или m >= 2. Минимальное значение N равно 5. Оно получается, когда m = 2. Таким образом, среди всех значений N, которые удовлетворяют неравенству ClusterSize (размер_кластера) – QuorumSize (размер_кворума) >= 2, минимальным значением является 5.

Обратите внимание, выше предполагалось, что каждый узел имеет реплику системной службы, поэтому размер кворума вычислялся на основе числа узлов в кластере. Однако, изменив значение параметра TargetReplicaSetSize, можно было бы сделать размер кворума меньше чем (N / 2 + 1), создать впечатление, что у нас может быть кластер с числом узлов меньше пяти и при этом иметь два дополнительных узла помимо размера кворума. Например, если в кластере с четырьмя узлами параметру TargetReplicaSetSize задать значение 3, размер кворума на основе TargetReplicaSetSize будет равен (3 / 2 + 1) или 2, поэтому неравенство имеет вид CluserSize (размер_кластера) – 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)?

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

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

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

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

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

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

Исключаемые при проверке антивирусной программой каталоги
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

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

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

А. Во время задания сборки и упаковки вы можете внедрить сертификат в пакет данных приложения Service Fabric и использовать его для аутентификации в 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 Collection?

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

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

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

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

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

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

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

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

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

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

Поставщик ресурсов 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, выполнять базовые тесты, открывать вопросы и отправлять запросы на вытягивание. Мы прилагаем все усилия, чтобы также перенести окружение для сборки Windows вместе со всем окружением CI.

После объявления о начале их реализации см. дополнительные сведения в блоге Service Fabric.

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

Ознакомьтесь с основными понятиями среды выполнения Service Fabric и рекомендациями по ее использованию