Высокая доступность: концепции, общие практики построения и сопровождения

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

Дополнение и объяснение этих заблуждений будет выходить за рамки данной статьи, но Вы сможете найти больше информации в публикации Fallacies of Distributed Computing: Explained от архитектора Arnon Rotem-Gal-Oz.

В этих заблуждениях упомянули, что задержка по сети не равна нулю, что пропускная способность не бесконечна, что сама сеть не надёжна. В следствии того, что информация не может распространяться по разным узлам сети мгновенно и в любом объеме, спровоцировано появление большого количества моделей управления данными в распределенных системах, а на основе них появилась CAP теорема [cap]. Поверхностные детали теоремы рассматривать не будем, так как они интуитивно простые, прочтения статьи с Wikipedia достаточно. Сложность как обычно в деталях, а именно моделях консистентности, которые будут влиять на такие характеристики системы как: латентность, пропускная способность, величину RPO, способ решения проблем конкурентности.

Существует довольно большое множество моделей консистентности, которые описывают различные подходы при работе с данными в распределенной системе и естественно с больше, чем одним агентом, которые с ними работают. Так как статья посвящена высокодоступным системам, то мы подразумеваем, что клиенты получают доступ к сервису без ожиданий и попыток синхронизироваться друг с другом, то есть система работоспособна даже тогда, когда доступен остался лишь один узел. Это называется wait-free-атрибут распределенной системы. В следствии наличия wait-free атрибута, приходится раскрывать сам факт конкурентности доступа к данным в такой системе. Так как бизнес диктует свои потребности с некоторой областью возможностей, то при проектировании системы и мы можем выбирать, в каких случаях и как организовать проведение транзакций. Транзакций не в терминах СУБД, а в терминах предметной области, что важно.

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

Ниже представлена решетка моделей консистентности от самого слабого критерия до сильного. Граф разделён CAP границей, всё что ниже неё может использоваться в wait-free системах, всё что выше - нет.

Решётка моделей консистентности[ds1e]: Как видно из изображения, в wait-free системе могу быть реализованы: update consistency модель, eventual concistency, pipelined consistency.
Отдельно хочется отметить serilizability, многие инженеры ошибочно считают, что она даст возможность забыть о проблеме консистентности проведения транзакций в распределённой системе. Она строже event consistency, но всё же не исключает проблем при разделении кластера (split brain), так как гарантирует проведение изолированных серий транзакций на локальных данных, а синхронизацию через shared object и арбитраж. Когда отделившийся узел возвращается в кластер, он будет вынужден вернуться к состоянию в момент сплита, либо потребует операцию по слиянию данных. Такая модель позволяет реализовать хорошие показатели производительности и предоставляет отличный контроль данных. Именно поэтому получила столь широкое распространение и для работы с важными данными (мед. записи, банковские транзакции), но как всегда есть нюансы.

Сверху находятся модели с жесткими критериями последовательности транзакций и линеаризацией, получается не wait-free система, но данные однозначно останутся консистентными в любой момент времени. Для более более подробного знакомства с этими моделями рекомендую заглянуть в [ds1e].

Большинство с ACID должны быть знакомы в общих чертах и даже в трактовках. Если нет - есть wiki: ACID_(computer_science). Продолжаем тему применимости принципов и моделей в построении HA систем. Ниже граф уровни изоляции транзакций (ACID) на основе CAP моделей, источник [hat] (нарисовал Alexey Grischenko):

Что это значит:

Практическое использование. В большинстве классических РСУБД по умолчанию используется serializable модель, иногда и как наиболее строгая, пример PostgreSQL [pgsql-tr]. Microsoft SQL Server [mssql-si] и Oracle [oracle-si] позволяют повысить изоляцию до snapshot isolation.

В принципе, когда говорят про CAP и ACID, зачастую подразумевают не serializable, а linearizable консистентность. Нюанс тут в том, что большинство РСУБД используют serializable или snapshot уровни изоляции с Multivesion concurrency control (MVCC), но не способны реализовать линеаризуемость транзакций, так как это сильно снизит скорость конкурентного доступа к данным. В этом и есть неочевидный и мало кому знакомый нюанс использования этих терминов.

Те, кто уже хорошо знаком с ACID, могут обратить внимание, что сериализуемые транзакции, являющиеся "эталоном" для достижения целостности и истинности данных в принципе для большой распределенной системы, не подходят из-за жестких ограничений. При большом количестве узлов требует и больших затрат ресурсов, и времени, нет толерантности к разделению(CAP). Это и вызвало появление AP NoSQL систем таких как Amazon Dynamo, Cassandra.

Из-за вот таких неочевидных нюансов, невозможности отнести все системы к классу CA, AP, CP, потребности более точно и кратко описать системы использующие не serializable модель и появились BASE и PACELC аббревиатуры.

Обязано появлением систем на основе eventual consistency, для которых приемлемо находиться в неконсистетном состоянии какое-то время и отдавать клиенту неконсистентные данные, тем самым сохраняя доступность. BASE - Basically Available, Soft state, Eventual consistency. По графу моделей консистентности видно, что они не такие жесткие, как системы на serializable модели. Пример BASE-баз данных: CouchDB, Amazon SimpleDB, Amazon Dynamo, Riak.

Ещё одна post-CAP теорема, а фактически её расширение. Созданное, чтобы в общую модель добавить современные NoSQL решения. Была предложена в работе "Consistency Tradeoffs in Modern Distributed Database System Design" [abadi]. Трактовка из оригинала:

Теперь в рамках одной теоремы можно более точно указать "классы" хранилищ и описать требования к ним. Классические ACID системы - PC/EС. Сохраняют целостность кластера (P), консистетность (С), но вынуждены жертвовать доступностью и задержками ради (E) консистентности (С). Современные NoSQL, в лице MongoDB, Amazon Dynamo, Cassandra, Aerospike являются PA/EL: уcтойчивы к сплитам (P), сохраняют доступность (A), но жертвуют консистентностью ради (E) низких задержек (L).

Для более детальной информации, рекомендую всё же ознакомиться c [abadi] и заглянуть в wikipedia, где приводятся классы наиболее популярных СУБД.

Отдельно хочется упомянуть Conway’s Law.

Строя распределённую систему, формируйте команды под задачи, а не наоборот. Иначе система будет иметь такие же проблемы, что и здесь.

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

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

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

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

Один из самых популярных вариантов организации высокодоступных кластеров при построении Web-сервисов. Все узлы в активном использовании, балансировщик раскидывает трафик в зависимости от его политики (random, round robin, etc.). В случае, если один из узлов перестал отвечать, балансировщик сам может перекинуть коннект на другой узел, тем самым избежав потери данных и с нулевым даунтаймом. Плюсы:

Минусы:

Примеры: кластера WEB, REST серверов.

Сходный принцип с Activ-Active, за тем исключением, что балансировщик обычно не используется, обычно клиент уже знает несколько адресов Master узлов, к которым и пробует подключаться. В случае невозможности подсоединиться к первому, пробует следующий адрес и т.д. Встречается в двух основных случаях: процессинг большого количества данных (батчи, стримы), отказоустойчивые БД.

В случае процессинга мастер-узлы сами выполняют лишь координационную функцию, обмениваясь между собой метаданными и занимаясь скедулингом (Spark, Flink)

В базах данных: Cassandra, MySQL с Multi-Master, Aerospike, MSSQL c P2P transaction replication.

Вариация Hot Standby. Все узлы кластера проверяют друг друга на доступность по heartbeat. В случае обнаружения недоступности master узла инициализируют выбор нового и проводят failover. Узлы-реплики могут использоваться для чтения. Пример: MongoDB (replica set), Redis, MSSQL, MySQL, PostgreSQL, RabbitMQ, Kafka (но есть нюансы).

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

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

Таймлайны отказов рассматривали ранее, сейчас вкратце: Вкратце:

Современные Agile подходы с короткими циклами релизов, CI/CD практики и прочий Ops-инструментарий очень сильно упростили работу с отказами, позволяя эксплуатировать большие системы существенно меньшим количеством людей.

Чек-лист того, чтобы упросить детекцию, диагностику отказов, а также оценку эффекта от их возникновения:

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

Компоненты системы должны быть согласованы между собой, например:

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

Ни вендор, ни поставщик программного обеспечения, ни программисты не могут построить высокодоступную и комфортную для пользователя системы. Построение такой системы - это тестирование, интеграция, испытания, верификация приложений и рабочих процессов. Наивно полагать, что развернув определенное ПО на рабочем контуре, вы получите высокодоступную систему, так как это: максимальный MTBF и минимальный MTTR, которые доводятся до нужных значений именно отладкой рабочих процессов сотрудников. Не стоит уповать и на организацию кластеров и средства репликации данных. Без своевременных вмешательств и организации работ по выводу из состоянии деградации система не может быть отказоустойчивой и высокодоступной. Формируйте SLA, SLO, ведите SLI.

Анализируйте систему на присутствие в ней элементов, выход из стоя которых может привести к невозможности продолжить исполнение даже в ограниченном режиме. Проще всего начать с анализа цепочек исполнения, зависимостей или data-flow диаграмм. Достаточно пройтись по ключевым обслуживаемым процессам, чтобы уже появилось представление о самых слабых узлах в цепочке. Но далеко не каждый компонент, представляющий собой SPOF, возможно дублировать или устранить иногда по финансовым причинам (слишком дорогое дублирующее железо), ограничения физические (например только один вводной канал) или концептуальное ограничение (например CAP-теорема[cap])

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

Инструментарий для виртуализации и оркестрацией серверов упрощает управление распределенной инфраструктурой, еще и с прослойкой абстракции над железом, но для части задач (такие как базы данных) или большие legacy системы, всё ещё имеет смысл.

Чем выше уровень автоматизации - тем меньше требуется время на операции, меньше ответственных за них. Ускорение и автоматизация цикла "сборка-тестирование" добавляет удобства для инженеров, увеличивает количество таких циклов за единицу времени, время тратится более эффективно. СI/CD подходы сильно упрощают раскатывание новых релизов по контурам, тем самым уменьшая и MTTR, и time to market (TTM).

Унификация сильно помогает для уменьшения времени на проектирование, тестирование и развертывание новых сервисов. Общие конфигурации и артефакты сильно помогают в этом на всех стадиях от идентификации потребности, до развертывания в production. Чек-лист:

Без мониторинга невозможно разобраться в каком состоянии находится система. Каждое запущенное приложение представляет без сбора метрик, health-checks и логов представляет собой чёрный ящик: что-то подаётся на вход, что-то поступает на выход с не всегда очевидными side-effects. Чтобы это избежать используют health-check интерфейсы и сбор метрик.
Через Health-check интерфейс проверяют живо ли приложение, вместе с пустым ответом приложение может предоставлять ещё и некоторую информацию о своём состоянии. В зависимости от подходов и вариантов процедуры развертывания организуют и автоматические операции, там может быть: перезапуск, оповещение оператора, добавление информации об этом в журнал.
Метрики - одномоментные показатели состояния ПО и железа, могут быть в виде счётчиков, таймеров, гистограм и т.п. Все они помогают понять в каком состоянии система была, находится и какова динамика изменений. Кроме системных метрик (RPS, QPS, latency, заполненность очередни и т.п.) могут собираться и бизнесовые метрики с информацией из предметной области бизнеса.

Собрать метрики мало - нужно ещё ими воспользоваться, в этом помогают различные инструменты их отображения: Kibana, Grafana, Prometheus, Datadog. Быстрый и удобный UI с дашбордами для просмотра информации о метриках - хорошая инвестиция в комфорт работы и уменьшение MTTR.

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

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

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

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

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

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