Создание отказоустойчивых облачных служб
Большую часть управления центром обработки данных и облачными службами составляет проектирование и обслуживание надежной службы на основе ненадежных частей. На следующем рисунке показана часть обучения для новых сотрудников, которая должна дать представление о большом числе (и типах) сбоев, которые регулярно возникают в большом центре обработки данных.
Рис. 2. Проблемы с надежностью, как показано в презентации обучения
Отказ системы происходит в результате неправильного состояния, возникшего в системе из-за сбоя. В системах обычно возникают сбои одного из следующих типов.
- Временные ошибки: временные ошибки в системе, которые исправляют себя с течением времени.
- Постоянные ошибки: ошибки, которые не могут быть восстановлены и обычно требуют замены ресурсов.
- Периодические ошибки: ошибки, которые периодически происходят в системе.
Сбои могут повлиять на доступность системы, снижая качество служб или производительность системы. Отказоустойчивая система может выполнять свою функцию даже при наличии сбоев в системе. В облаке отказоустойчивая система часто рассматривается как система, предоставляющая службы согласованным образом с меньшим временем простоя, чем позволяет соглашение об уровне обслуживания (SLA).
Почему важна отказоустойчивость?
Сбои в больших критически важных системах могут привести к значительным денежным потерям для всех заинтересованных сторон. Сама природа облачных вычислительных систем заключается в том, что они имеют многоуровневую архитектуру. Поэтому сбой на одном уровне облачных ресурсов может вызвать ошибки на верхних уровнях или перекрыть доступ к нижним уровням.
Например, ошибка в любом аппаратном компоненте системы может повлиять на нормальное выполнение приложения SaaS (программное обеспечение как услуга), работающего на виртуальной машине, использующей неисправные ресурсы. Ошибки в системе на любом уровне напрямую связаны с соглашениями об уровне обслуживания между поставщиками на каждом уровне.
Упреждающие меры
Поставщики услуг принимают определенные меры для проектирования системы таким образом, чтобы избежать известных проблем или предсказуемых сбоев.
Профилирование и тестирование
Загрузка и нагрузочное тестирование облачных ресурсов с целью определения возможных причин сбоев очень важны для обеспечения доступности служб. Профилирование этих метрик помогает в проектировании системы, которая может успешно вынести ожидаемую нагрузку без какого-либо непредсказуемого поведения.
Избыточная подготовка
Избыточная подготовка — это практика развертывания ресурсов в объемах, превышающих общее прогнозируемое использование ресурсов в текущий момент времени. В ситуациях, когда потребности системы нельзя точно предсказать, избыточное выделение ресурсов может быть приемлемой стратегией для обработки непредвиденных пиков нагрузки.
Рассмотрим в качестве примера платформу для электронной коммерции, которая имеет среднюю постоянную нагрузку на свои серверы в течение года, но в период праздников ожидается, что структура нагрузки быстро возрастет. В пиковое время рекомендуется подготавливать дополнительные ресурсы на основе данных журнала прошлых периодов пикового использования. К быстрому росту трафика, как правило, трудно приспособиться за короткий период времени. Как будет обсуждаться в последующих разделах, необходимы временные затраты, связанные с динамическим масштабированием, которое включает в себя длительные этапы обнаружения изменений в шаблоне нагрузки и подготовки дополнительных ресурсов для удовлетворения новой нагрузки. Оба этих шага требуют времени. Этой задержки в корректировке может оказаться достаточно для перегрузки, которая в худшем случае приведет к сбою системы, а в лучшем — к снижению качества обслуживания.
Избыточная подготовка также является способом защиты от DoS-атак (отказ в обслуживании) или от атак DDoS (распределенных DoS-атак), когда злоумышленники генерируют запросы, предназначенные для перегрузки системы, вбрасывая в нее большие объемы трафика и пытаясь вызвать сбой системы. При любой атаке системе всегда требуется некоторое время для ее обнаружения и выполнения корректирующих мер. Несмотря на то, что такой анализ шаблонов запросов выполняется, система уже находится под угрозой и должна иметь возможность справиться с увеличенным трафиком, пока не будет реализована стратегия устранения рисков.
Репликация
Критические компоненты системы могут дублироваться с помощью дополнительных аппаратных и программных компонентов, чтобы автоматически обрабатывать сбои в частях системы без сбоя всей системы. Есть две основных стратегии репликации.
- Активная репликация, когда все дублирующие ресурсы работают параллельно и отвечают и обрабатывают все запросы. Это означает, что для любого клиентского запроса все ресурсы получают один и тот же запрос, все ресурсы отвечают на один и тот же запрос, а порядок запросов сохраняет состояние во всех ресурсах.
- Пассивная репликация, при которой только основная единица обрабатывает запросы, а вторичные единицы просто сохраняют состояние и вступают в работу после сбоя основного устройства. Клиент имеет доступ только к основному ресурсу, который передает изменение состояния во все вторичные ресурсы. Недостаток пассивной репликации заключается в том, что при переключении с основного экземпляра на дополнительный экземпляр могут быть потеряны запросы или снижено качество обслуживания.
Также существует гибридная стратегия, которая называется полуактивной, которая очень похожа на активную стратегию. Разница заключается в том, что клиенту предоставляется вывод только основного ресурса. Выходные данные дополнительных ресурсов подавляются и сохраняются для переключения на них в случае сбоя основного ресурса. На следующем рисунке показаны различия между стратегиями репликации.
Рис. 3. Стратегии репликации
Важным фактором, который следует учитывать при репликации, является количество используемых дополнительных ресурсов. Хотя это отличается от приложения к приложению в зависимости от важности системы, существует 3 формальных уровня репликации.
- N+1. Это означает, что для приложения, которому нужен N-узлы для правильной работы, один дополнительный ресурс подготавливается как отказоустойчивый.
- 2N. На этом уровне один дополнительный узел для каждого узла, необходимого для нормальной функции, подготавливается как отказоустойчивый.
- 2N+1. На этом уровне один дополнительный узел для каждого узла, необходимого для нормальной функции, и один дополнительный узел в целом подготавливается как отказоустойчивый.
Реактивные меры
Помимо прогнозных мер, системы могут принимать реактивные меры и устранять сбои по мере их возникновения.
Проверки и мониторинг
Все ресурсы постоянно отслеживаются для проверки непредсказуемого поведения или потери ресурсов. Основываясь на данных мониторинга, стратегии восстановления и перенастройки предназначены для перезапуска ресурсов или создания новых ресурсов. Мониторинг может помочь в выявлении ошибок в системах. Ошибки, которые приводят к недоступности службы, называются аварийными сбоями, а те, которые вызывают необычное или неправильное поведение системы, называются византийскими сбоями.
Существует несколько методов наблюдения, которые используются для проверки аварийных сбоев в системе. Ниже приведены две из таких тактик.
- Ping-echo: служба мониторинга запрашивает каждый ресурс для своего состояния и получает время реагирования.
- Пульс. Каждый экземпляр отправляет состояние в службу мониторинга через регулярные интервалы без триггера.
Наблюдение за византийскими ошибками обычно зависит от свойств предоставляемой службы. Системы мониторинга могут проверять основные метрики, такие как задержка, загрузка ЦП и использование памяти, и проверять ожидаемые значения, чтобы узнать, не снижено ли качество обслуживания. Кроме того, журналы контроля для конкретных приложений обычно хранятся в каждой важной точке выполнения службы и периодически анализируются, чтобы убедиться в том, что служба работает правильно (или имеются ли в системе внедренные сбои).
Контрольная точка и перезапуск
Несколько моделей программирования в облаке реализуют стратегии контрольных точек, поэтому состояние сохраняется на нескольких этапах выполнения, чтобы обеспечить восстановление до последней сохраненной контрольной точки. В приложениях аналитики данных часто выполняются длительные параллельные распределенные задачи, которые выполняются на терабайтах наборов данных для извлечения информации. Поскольку эти задачи состоят из нескольких небольших фрагментов выполнения, каждый шаг при выполнении программы может сохранить общее состояние выполнения в виде контрольной точки. В точках сбоя, когда отдельные узлы не могут завершить свою работу, выполнение может быть перезапущено с момента создания предыдущей контрольной точки. Самая большая проблема при определении допустимых контрольных точек для отката возникает, когда параллельные процессы обмениваются информацией. Сбой одного из процессов может привести к каскадному откату в другом процессе, так как контрольные точки, созданные в этом процессе, могут быть основаны на ошибочных данных, передаваемых сбойным процессом. Вы узнаете больше об отказоустойчивости для моделей программирования в последующих модулях.
Примеры тестирования устойчивости
Облачные службы должны быть построены с учетом избыточности и отказоустойчивости, так как ни один компонент большой распределенной системы не может гарантировать доступность или бесперебойную работу на 100 %.
Все сбои (включая сбои зависимостей в одном узле, в стойке, в центре обработки данных или регионально избыточных развертываниях) должны быть корректно обработаны без влияния на всю систему. Тестирование способности системы работать с критическими сбоями очень важно, так как иногда даже несколько секунд простоя или ухудшения качества обслуживания могут привести к потерям в сотни тысяч, если не в миллионы долларов.
Тестирование на наличие сбоев с реальным трафиком должно выполняться регулярно, чтобы система была защищена и могла справляться с незапланированными сбоями. Существуют различные системы, созданные для тестирования устойчивости. Одним из таких наборов для тестирования является Simian Army, созданный Netflix.
Simian Army состоит из облачных служб (называемых обезьянами), которые генерируют различные виды сбоев, обнаруживают аномальные условия и проверяют способность системы их пережить. Цель — обеспечить безопасность, надежность и высокую доступность облака. Ниже описаны некоторые обезьяны Simian Army.
- Обезьяна хаоса: инструмент, который случайным образом выбирает рабочий экземпляр и отключает его, чтобы убедиться, что облако выживает распространенные типы сбоев без какого-либо влияния клиента. Netflix описывает подход "обезьяна хаоса" как "идею впустить обезьяну с гранатой в ваш центр обработки данных (или в облачный регион), чтобы она случайным образом крушила экземпляры и грызла кабели, а мы в это время продолжали бы обслуживать наших клиентов без перерывов". Этот тип тестирования с подробным мониторингом может вскрыть различные формы слабых мест в системе, и на основе его результатов можно построить стратегии автоматического восстановления.
- Обезьяна задержки: служба, которая вызывает задержки между взаимодействием RESTful между различными клиентами и серверами, имитируя снижение производительности службы и время простоя.
- Врач обезьяна: служба, которая находит экземпляры, которые демонстрируют неработоспособное поведение (например, загрузка ЦП) и удаляет их из службы. Она дает владельцам службы определенное время для выяснения причины проблемы и в конечном итоге завершает работу экземпляра.
- Хаос гориллы: служба, которая может имитировать потерю всей зоны доступности AWS. Она используется для проверки того, что службы автоматически перераспределяют функциональность в оставшихся зонах без влияния на работу пользователей и без ручного вмешательства.