Аварийное восстановление в Azure Service Fabric

  • Статья

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

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

Предотвращение аварий

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

В основном существует два типа сценариев аварий и сбоев:

  • Сбои оборудования или программного обеспечения
  • Проблемы с работоспособностью

Сбои оборудования или программного обеспечения

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

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

Этот шаблон работает независимо от того, какой сбой вы пытаетесь предотвратить. Если вы хотите избежать сбоев сети хранения данных, храните данные в нескольких сетях SAN. Если вы хотите избежать выхода из строя серверов и серверных стоек, используйте несколько серверов и серверных стоек. Если вы беспокоитесь об утере центров обработки данных, ваша служба должна выполняться сразу в нескольких регионах Azure, нескольких зонах доступности Azure или собственных центрах обработки данных.

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

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

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

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

Проблемы с работоспособностью

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

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

Лучшие способы предотвращения подобных функциональных ошибок:

  • Ограничение оперативного доступа к среде.
  • Строгий аудит небезопасных операций.
  • Внедрение автоматизации, запрет изменений вручную или внештатных изменений и проверка определенных изменений в фактической среде перед их применением.
  • Убедитесь в том, что деструктивные операции являются обратимыми. Обратимые операции не выполняются сразу и могут быть отменены в течение определенного периода.

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

Обработка сбоев

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

Обработка единичных сбоев

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

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

Самый простой способ справиться с любым единичным отказом — это обеспечить выполнение служб на нескольких узлах по умолчанию. Для служб без отслеживания состояния убедитесь, что параметр InstanceCount больше 1. Для служб с отслеживанием состояния минимальная рекомендация заключается в том, чтобы оба параметра, TargetReplicaSetSize и MinReplicaSetSize, имели значение 3. Запуск нескольких копий кода службы гарантирует, что служба может автоматически обработать любой единичный отказ.

Обработка координированных сбоев

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

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

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

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

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

Для визуализации структуры кластера можно использовать схему кластера в Service Fabric Explorer:

Узлы распределены между доменами сбоя в Service Fabric Explorer

Примечание

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

Обработка одновременных сбоев оборудования или программного обеспечения

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

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

Службы без отслеживания состояния

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

Например, предположим, что служба без отслеживания состояния имеет значение InstanceCount, равное –1. Это значение указывает, что на каждом узле в кластере должен выполняться один экземпляр. В случае сбоя некоторых из этих экземпляров Service Fabric обнаружит, что служба не находится в требуемом состоянии, и попытается создать экземпляры на узлах, где они отсутствуют.

Служба с отслеживанием состояния

Существует два типа служб с отслеживанием состояния.

  • Отслеживание состояния с сохранением состояния.
  • Отслеживание состояния без сохранения состояния. (Состояние хранится в памяти.)

Восстановление после сбоя службы с отслеживанием состояния зависит от типа службы с отслеживанием состояния, количества реплик, которые имела служба, и количества сбоев реплик.

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

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

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

  1. Определение, произошла ли потеря кворума.

    Объявление потери кворума, если большинство реплик службы с отслеживанием состояния одновременно не срабатывают.

  2. Определение того, является ли потеря кворума постоянной.

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

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

  3. Определение потери данных и восстановление из резервных копий.

    Если была объявлена потеря кворума (автоматически или через административное действие), Service Fabric и службы переходят к определению факта потери данных. На этом этапе Service Fabric также определяет, что другие реплики не будут восстановлены. Это решение принимается в момент прекращения ожидания восстановления потери кворума. Лучше всего заморозить службу и дождаться помощи администратора.

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

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

    Что же дает типичная реализация метода OnDataLossAsync?

    1. Происходит активация журналов реализации OnDataLossAsync, которые запускают все необходимые административные оповещения.

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

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

    3. Часто также существуют какая-то другая телеметрия или данные, получаемые от службы. Эти метаданные могут содержаться в других службах или журналах. С помощью этих сведений можно определить, были ли получены и обработаны в первичной реплике вызовы, которые не присутствовали в резервной копии либо реплицированы в эту конкретную реплику. Может потребоваться воспроизвести или добавить эти данные к резервной копии, прежде чем восстановление станет возможным.

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

    5. После завершения сравнения и (при необходимости) восстановления код службы должен вернуть значение true, если были внесены изменения состояния. Если реплика определяется как лучшая доступная копия состояния и изменения не вносятся, возвращается значение false.

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

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

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

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

Если вы обнаружите, что оставшихся реплик недостаточно для продолжения работы в сценарии потери данных, и не можете восстановить состояние службы из телеметрии или выходных данных, наилучшая возможная цель точки восстановления (RPO) определяется частотой получения резервных копий. Service Fabric предоставляет множество средств для тестирования различных сценариев сбоя, включая постоянный кворум и потерю данных, при которой требуется восстановление из резервной копии. Эти сценарии включены как часть средств тестирования Service Fabric, управляемых службой анализа сбоев. Дополнительные сведения об этих средствах и шаблонах см. в статье Введение в службу Fault Analysis Service.

Примечание

Работа системных служб также может нарушиться из-за потери кворума. Ее влияние зависит от конкретной службы. Например, потеря кворума в службе именования влияет на разрешение имен, а потеря кворума в службе диспетчера отработки отказа блокирует создание службы и переход на другой ресурс.

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

Устранение потерь кворума

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

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

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

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

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

Примечание

Эти методы всегда небезопасно использовать, кроме как целевым образом по отношению к конкретным секциям.

  • Используйте API Repair-ServiceFabricPartition -PartitionId или System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId). Эти API позволяют указывать идентификатор секции для перемещения из состояния потери кворума в состояние потенциальной потери данных.
  • Если кластер сталкивается с частыми сбоями, которые приводят к тому, что службы переходят в состояние потери кворума, и возможная потеря данных приемлема, настройка соответствующего значения QuorumLossWaitDuration может помочь службе автоматически восстановиться. Service Fabric будет ожидать указанного значения QuorumLossWaitDuration (по умолчанию бесконечно) перед запуском восстановления. Мы не рекомендуем использовать этот метод, так как он может привести к непредвиденным потерям данных.

Доступность кластера Service Fabric

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

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

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

Сбои в центре обработки данных или регионе Azure

В редких случаях физические центры обработки данных могут стать временно недоступными из-за отключения питания или потери сетевого подключения. В этих случаях кластеры Service Fabric, а также службы в таких центрах обработки данных или в регионе Azure будут недоступны. Тем не менее данные сохраняются.

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

Есть несколько разных стратегий предотвращения постоянного или неустранимого сбоя в одном центре обработки данных или регионе:

  • Запустите отдельные кластеры Service Fabric в нескольких регионах и используйте механизм для отработки отказа и восстановления размещения между этими средами. Для такой мультикластерной модели типа "активный-активный" или "активный-пассивный" требуется дополнительный код для управления и операций. Также требуется координация резервных копий служб в одном центре обработки данных или регионе, чтобы они были доступны в других центрах обработки данных или регионах в случае сбоя.

  • Запустите кластер Service Fabric, охватывающий несколько центров обработки данных. Минимальные требования для такой конфигурации — три центра обработки данных. Дополнительные сведения см. в статье Развертывание кластера Service Fabric в зонах доступности.

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

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

  • Запустите кластер Service Fabric, охватывающий несколько регионов, с помощью автономной модели. Рекомендуемое число регионов — 3. Подробные сведения о настройке автономного кластера Service Fabric см. в статье Создание автономного кластера.

Случайные сбои, вызывающие сбои кластеров

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

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

В Azure поставщик ресурсов Service Fabric управляет конфигурациями кластера Service Fabric. По умолчанию поставщик ресурсов распределяет начальные узлы между доменами сбоя и обновления для типа первичного узла. Если тип первичного узла помечен как имеющий стойкость Silver или Gold, при удалении начального узла (путем горизонтального масштабирования типа первичного узла или при его удалении вручную) кластер попытается распространить другой узел, отличный от начального, из доступной емкости типа первичного узла. Эти попытки завершатся неудачей, если у вас меньше ресурсов, чем требуется согласно уровню надежности кластера для типа первичного узла.

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

Дальнейшие действия