Что такое высокая доступность (HA)? Почему вашему бизнесу нужно это планировать — CloudSavvy IT

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

Что такое высокая доступность?

Высокая доступность (HA) — это практика минимизации всего времени простоя сервера, в идеале до нуля. Он включает в себя множество методов, таких как автоматическое масштабирование, мониторинг в реальном времени и автоматическое развертывание синих / зеленых обновлений.

Основная концепция довольно проста: один сервер — это не сервер. Два сервера — это один сервер. Чем больше избыточности вы планируете, тем более высокодоступным будет ваш сервис. Ваш сервис не должен прерываться даже в случае возгорания одного из ваших компонентов.

Этого можно достичь с помощью такой простой вещи, как группа автоматического масштабирования, которую облачные сервисы, такие как AWS, очень хорошо поддерживают. Если на сервере возникла проблема, например, внезапный сбой, балансировщик нагрузки обнаружит, что он не отвечает. Затем он может перенаправить трафик с вышедшего из строя сервера на другие серверы в кластере, даже запустив новый экземпляр, если ему нужна мощность.

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

Иногда вам нужно гарантия доступность для клиентов. Если вы гарантируете доступность 99,999% в соглашении об уровне обслуживания (SLA), это означает, что ваша служба не может отключаться более пяти минут в год. Это делает высокую доступность необходимой для многих крупных компаний с самого начала.

Например, такие сервисы, как AWS S3, поставляются с SLA, гарантирующими 99,9999999% (девять девяток) избыточности данных. По сути, это означает, что все ваши данные реплицируются по регионам, что делает их безопасными от всего, кроме сценария «гигантский метеор, поражающий ваше хранилище данных». Даже тогда, с физическим разделением, это может быть безопасно от небольших метеоров или, по крайней мере, от гораздо более реалистичной ситуации пожара на складе или отключения электроэнергии.

Компоненты хороших систем высокой доступности

Что приводит к простоям? За исключением стихийных бедствий, простои обычно вызваны человеческими ошибками или случайными сбоями.

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

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

Автоматическое масштабирование и резервирование

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

Один из основных способов отказа сервисов — это «объятия смерти», когда тысячи пользователей массово стекаются на сайт или какой-то другой скачок трафика. Без автоматического масштабирования вы облажались, так как вы не можете больше запускать серверы и должны дождаться, пока нагрузка спадет, или вручную развернуть новый экземпляр для удовлетворения спроса.

Автоматическое масштабирование означает, что вам никогда не придется сталкиваться с этой проблемой (хотя вам нужно будет заплатить за дополнительное серверное время, которое вам нужно). Это одна из причин того, почему такие сервисы, как бессерверные базы данных и AWS Lambda Functions, так хороши: они отлично масштабируются сразу после установки.

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

Если вы хотите узнать больше, вы можете прочитать нашу статью о начале работы с автоматическим масштабированием AWS.

24/7 Мониторинг

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

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

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

Автоматические сине-зеленые обновления

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

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

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

Сине-зеленое развертывание вместо этого запустит 11-й сервер в вашей группе автоматического масштабирования и установит новые изменения кода. Затем, когда он стал «зеленым» или принимал запросы и был готов к работе, он немедленно заменил один из существующих «синих» серверов в вашей группе. Затем промойте и повторите процедуру для каждого сервера в кластере. Даже если бы у вас был только один сервер, этот метод обновления привел бы к без простоев.

Еще лучше, если вы обнаружите проблемы с вашими системами мониторинга и сигнализацией, вы можете немедленно вернуть изменения обратно к синим серверам. Это означает, что даже полностью неудачное обновление не остановит вашу службу дольше, чем на несколько минут, в идеале — вообще не будет, если у вас несколько серверов и вы можете медленно развернуть обновление. Сине-зеленые развертывания можно настроить на обновление только 10% ваших серверов каждые пять минут, например, медленное развертывание обновления в течение часа.

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *