Что такое высокая доступность (HA)? Почему ваш бизнес должен планировать это
Очевидно, что никто планирует простои. Но проблемы неизбежны, и если у вас нет плана для их немедленного и автоматического решения, вы потеряете доход, когда ваши услуги перестанут работать. Высокая доступность поможет вам спланировать наихудший сценарий.
Что такое высокая доступность?
Высокая доступность (HA) — это практика минимизации времени простоя всех серверов, в идеале до нуля. Он включает в себя множество методов, таких как автоматическое масштабирование, мониторинг в реальном времени и автоматическое развертывание синих/зеленых обновлений.
Основная концепция довольно проста: один сервер — это не сервер. Два сервера это один сервер. Чем больше избыточности вы планируете, тем более доступной будет ваша услуга. Ваша служба не должна прерываться даже в случае возгорания одного из ваших компонентов.
Этого можно добиться с помощью такой простой вещи, как группа автоматического масштабирования, которую очень хорошо поддерживают такие облачные сервисы, как AWS. Если на сервере возникла проблема, например внезапный сбой, балансировщик нагрузки обнаружит, что он не отвечает. Затем он может перенаправить трафик с поврежденного сервера на другие серверы в кластере, даже запуская новый экземпляр, если ему нужна емкость.
Эта избыточная философия применима ко всем уровням иерархии компонентов. Например, если у вас есть микросервис для обработки изображений загруженных пользователем медиафайлов, было бы неплохо просто запустить его в фоновом режиме на одной из ваших машин. Если на этом компьютере есть проблемы, пользователи могут не иметь возможности загружать файлы, что считается частичным простоем вашей службы и может разочаровать конечного пользователя.
Иногда вам нужно гарантировать доступность для клиентов. Если вы гарантируете доступность на уровне 99,999 % в соглашении об уровне обслуживания (SLA), это означает, что ваш сервис не может быть отключен более чем на пять минут в год. Это делает HA необходимым с самого начала для многих крупных компаний.
Например, такие сервисы, как AWS S3, поставляются с SLA, гарантирующими 99,9999999% (девять девяток) избыточности данных. По сути, это означает, что все ваши данные реплицируются по регионам, что делает их безопасными от всего, кроме сценария падения гигантского метеорита на ваше хранилище данных. Даже тогда, при физическом разделении, он может быть в безопасности от небольших метеоритов или, по крайней мере, в гораздо более реалистичной ситуации с пожаром на складе или отключением электроэнергии.
Компоненты хороших систем высокой доступности
Что приводит к простоям? За исключением стихийных бедствий, простои обычно вызваны человеческими ошибками или случайными сбоями.
Случайные сбои на самом деле нельзя запланировать, но их можно спланировать с помощью резервных систем. Их также можно поймать, когда они происходят, с помощью хороших систем мониторинга, которые могут предупредить вас о проблемах в вашей сети.
Человеческая ошибка может быть запланирована. В первую очередь за счет минимизации количества ошибок с помощью тщательных тестовых сред. Но все совершают ошибки, даже крупные компании, поэтому у вас должен быть план на случай возникновения ошибок.
Автоматическое масштабирование и резервирование
Автомасштабирование — это процесс автоматического масштабирования количества имеющихся у вас серверов, обычно в течение дня, для удовлетворения пиковой нагрузки, а также в ситуациях высокой нагрузки.
Один из основных способов выхода сервисов из строя — это «объятия смерти», когда на сайт массово стекаются тысячи пользователей, или всплески трафика каким-то другим образом. Без автоматического масштабирования вы облажались, так как больше не можете раскручивать серверы и должны ждать, пока нагрузка не спадет, или вручную запускать новый экземпляр для удовлетворения спроса.
Автоматическое масштабирование означает, что вам никогда не придется сталкиваться с этой проблемой (хотя вам придется платить за дополнительное серверное время, которое вам нужно). Это одна из причин, почему сервисы, такие как бессерверные базы данных и AWS Lambda Functions, так хороши: они очень хорошо масштабируются сразу после установки.
Однако это выходит за рамки простого автоматического масштабирования ваших основных серверов — если в вашей сети есть другие компоненты или службы, они также должны иметь возможность масштабирования. Например, вам может потребоваться развернуть дополнительные веб-серверы для удовлетворения потребностей в трафике, но если ваш сервер базы данных перегружен, у вас также возникнут проблемы.
Если вы хотите узнать больше, вы можете прочитать нашу статью о начале работы с автоматическим масштабированием AWS.
Круглосуточный мониторинг
Мониторинг включает в себя отслеживание журналов и показателей ваших сервисов в режиме реального времени. Выполнение этого автоматически с помощью автоматических сигналов тревоги может предупредить вас о проблемах в вашей сети во время их возникновения, а не после того, как они затронут пользователей.
Например, вы можете установить сигнал тревоги, который срабатывает, когда ваш сервер достигает 90% использования памяти, что может указывать на утечку памяти или проблему с перегрузкой приложения.
Затем вы можете настроить этот сигнал, чтобы ваша группа автоматического масштабирования добавила еще один экземпляр или заменила текущий экземпляр новым.
Автоматические синие/зеленые обновления
Самый распространенный сценарий ошибок — неудачное обновление, когда ваш код изменяется и ломает непредвиденную часть вашего приложения. Это можно запланировать с помощью синего/зеленого развертывания.
Сине-зеленое развертывание — это медленный, постепенный процесс, при котором изменения кода развертываются поэтапно, а не все сразу. Например, представьте, что у вас есть 10 серверов с одним и тем же программным обеспечением за балансировщиком нагрузки.
Обычное развертывание может просто обновлять их все немедленно, когда вносятся новые изменения, или, по крайней мере, обновлять их по одному, чтобы предотвратить простои.
Сине-зеленое развертывание вместо этого запустит 11-й сервер в вашей группе автоматического масштабирования и установит новые изменения кода. Затем, как только он станет «зеленым» или примет запросы и будет готов к работе, он немедленно заменит один из существующих «синих» серверов в вашей группе. Затем вы прополоскаете и повторите для каждого сервера в кластере. Даже если у вас только один сервер, этот метод обновления не приведет к отсутствию простоев.
Более того, вы можете немедленно отменить изменения обратно на синие серверы, если обнаружатся проблемы с вашими системами мониторинга и сигнализацией. Это означает, что даже полностью неудачное обновление не остановит ваш сервис более чем на несколько минут, в идеале вообще не отключит, если у вас несколько серверов и вы можете медленно развертывать обновление. Синие/зеленые развертывания могут быть настроены на обновление только 10 % ваших серверов каждые пять минут, например, медленное развертывание обновления в течение часа.