Общие сведения о службе анализа сбоев

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

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

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

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

  • Сценарий хаотического тестирования
  • Сценарий отработки отказа

Тестирование как услуга

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

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

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

Тестирование распределенных систем

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

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

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

Моделирование и создание реальных сценариев возникновения ошибок

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

  1. Клиент отправляет запрос на завершение работы узла.

  2. Запрос отправляется в нужный узел.

    а. Если узел не найден, возникнет ошибка.

    b. Если узел найден, запрос должен вернуться, только если узел не работает.

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

Создание необходимых событий и сценариев

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

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

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

Единые возможности в различных средах

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

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

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

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

Аналогичный механизм используется и в платформе Service Fabric (только мы имеем дело с другим масштабом сбоев и другими средами). Это позволяет намного быстрее внедрить код в конвейере развертывания и проверить службы в условиях реальных нагрузок.

Использование службы анализа сбоев

C#

Компоненты службы анализа сбоев находятся в пространстве имен System.Fabric в пакете Microsoft.ServiceFabric NuGet. Чтобы использовать функции службы анализа сбоев, включите пакет NuGet в качестве ссылки в свой проект.

PowerShell

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

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

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

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