Несколько слов об отказоустойчивых решениях.
Это избыточные решения. Чтобы система могла справиться с любым единичным отказом, должен быть другой элемент, который может взять на себя функции отказавшего.
Это географически распределенные решения. Разные элементы системы могут находиться в физической инфраструктуре компании. Но лучше, если они находятся как минимум, в разных зданиях, и эти здания должны быть как можно меньше связаны между собой (разные собственники, интернет-провайдеры, пути доступа и пр.), а лучше — если в разных городах или даже странах.
Отказоустойчивость, как правило, связана либо с понижением скорости / эффективности, либо с большими затратами.
Есть законодательные ограничения, связанные с хранением персональных данных. В разных странах применимы различные варианты.
Допустим, у вас несколько ЦОД, и вам надо построить отказоустойчивое решение, которое позволит им обмениваться данными. Прежде всего, нужно ответить на вопрос: какие требования к системе? Насколько важно гарантированное одинаковое состояние данных и невозможность их потери? Что важнее: скорость или точность? Или важно и то, и другое, и есть бюджет на достижение этих целей?
Ситуация 1: данные должны быть идентичны в любой части системы, требуется подтверждение транзакции на удаленной системе. Например, в сервер 1 приходит запрос по отгрузкам. Если в это время на сервере 2 фиксируется новая отгрузка, а сервер 1 об этом еще не знает, то клиент получит неточную информацию. Поэтому если на сервере 1 произошли изменения, вся система недоступна, пока она не обновится. В таком случае применяется синхронная репликация, при которой можно гарантировать, что никакие данные не потеряются, но в какой-то момент система может быть недоступна. Это дорогое и медленное решение. Минимизация времени простоя достигается аппаратной избыточностью.
Ситуация 2: не нужна абсолютная точность в любой момент времени, допустимы временные потери данных, которые восполняются через определенный промежуток времени. Система работает и доступна в любой момент времени, изменения в одной части системы в течение получаса появляются в других ее частях, все участники процесса в курсе, их это устраивает. В случае аварии происходит потеря незавершенных транзакций и тех данных, которые не были перенесены в резервное хранилище. Через некоторое время данные восстанавливаются с небольшой потерей точности, а может, и без потерь. Мы говорим об асинхронной репликации. При таком решении для минимизации потери точности требуется широкий канал связи.
Для отказоустойчивых систем возможны два архитектурных решения.
Active-active: все части распределенной системы работоспособны в любой момент времени, в случае отказа происходит автоматическое переключение нагрузки с одного ЦОД на другой. При таком варианте возможна ситуация, когда два пользователя отправят информацию в одну ячейку памяти.
Active-passive: в любой момент времени из двух узлов работает только один, второй включается только в случае отказа. Репликация идёт только в одну сторону — от активного к пассивному. Это проще реализовать технически, но требуется дублирование всех узлов.
В конструировании этих решений важно учитывать не только требования бизнеса, но и требования и нюансы самих приложений и систем. Как гласит закон Мэрфи, любая проблема имеет простое, легкое для восприятия неправильное решение. Другими словами, можно построить отличное отказоустойчивое решение, которое нельзя будет использовать просто потому, что определённое ПО не умеет работать в режиме синхронной репликации.
Другое требование — целесообразность затрат. Готовы ли вы оплачивать повышение точности или отказоустойчивости? Можно построить суперотказоустойчивую систему на трех континентах и спутнике, но она будет стоить неоправданно дорого. Может быть, для данного случая вообще не стоит строить отказоустойчивость на уровне инфраструктуры, а стоит переписать приложение и адаптировать его так, чтобы оно могло быть запущено на нескольких серверах в разных местах и могло обрабатывать местных клиентов. Решение может быть гибридным, с использованием облачных сервисов.
Для того чтобы отказоустойчивое решение не было раздутым и реально отвечало требованиям бизнеса, нужно ответить себе на несколько вопросов.
Каковы требования к функционалу и доступности системы?
Какова вероятность отказов и на что они повлияют?
Какова географическая распределенность системы?
Что более критично: простой или потеря данных?
