Поделиться через

Распространенные вопросы о 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 использует домены сбоя и домены обновления для принятия решений о размещении экземпляров реплик или экземпляров служб. Так как 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, поэтому неравенство имеет вид 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 хранит данные клиентов?

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

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

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

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