Каковы опции для системы HA?
Я изучаю создание машины Linux HA для веб-сайта моего клиента. Каковы основные опции, которые я имею, или место/статья, где я могу узнать больше?
Я любил бы, если бы это было единственное изображение также так, чтобы существующее программное обеспечение просто работало бы.
Любая справка ценится.
Спасибо!
У вас много вариантов. Какие из них вы можете использовать, зависят от того, как закодирован ваш сайт.
T tightly Coupled, Single State
Этот сайт может работать только с одним экземпляром по... причинам. Запуск двух параллельно по каким-то причинам был бы крайне плохой идеей. Довольно необычно быть таким сайтом.
CAP Theorem: Первостепенное значение имеет последовательность по всей системе, а не толерантность к разделам, что делает доступность главной инженерной целью.
T tightly Coupled, Single State Per Session
Этот веб-сайт работает только тогда, когда пользователи постоянно взаимодействуют с одним и тем же веб-сайтом. Если они попадают не на тот сервер, все может пойти не так.
CAP Theorem: Пользовательские сессии нуждаются в строгой последовательности, но система в этом не нуждается. Немного толерантности разделов, так как потерянные сессии во время сбоя все еще являются деградацией сервиса, но система в целом выживет.
Loosely Coupled, State Doesn't Matter
Самый масштабируемый вариант, сайты этого типа сохраняют состояние сессии на уровне базы данных, если состояние вообще сохраняется. Попадание не на тот сервер, не имеет значения, так как веб-сервер просто попадает в базу данных для состояния.
CAP Theorem: Пользовательские сессии довольны непоследовательностью, толерантность разделов очень высока, а это значит, что доступность имеет первостепенное значение.
Single State на сегодняшний день является самым трудным для HA, поэтому сайты почти никогда не кодируются для него. Для этого требуется одна и только одна база данных или набор файлов и один и только один веб-сервер, с репликацией или передачей объема между членами HA-сервера, чтобы другой мог забрать его после смерти первого сервера. Инжиниринг достаточно сложен, обычно проще перекодировать сайт в приложение Single State Per Session, где проблема гораздо проще.
Но если у вас нет выбора, ваш единственный основной вариант - это кластеризация, как heartbeat. Соберите группу серверов вместе, настройте репликацию файлов и баз данных и установите правила обхода отказа. Нелегко.
Single System Image не подходит для веб-сайтов, так как сложность в создании как производительной, так и доступной системы очень высока. SSI системы имеют много инженерных решений для обеспечения единого IPC пространства и строгой согласованности на системном уровне, что делает веб-сервисы очень, очень медленными. Лучше всего использовать его для систем, которые требуют такого уровня интеграции между физическими узлами, а web-сервинг не является такой системой. Ее устойчивость к разделам очень, очень плохая, что делает SSI плохим решением для HA. Это не короткий путь к HA. Лучше обслуживать кластер.
Single State Per Session обычно обрабатывается созданием нескольких веб-серверов и фронтовой установкой на них таких балансировщиков нагрузки, как haproxy, AWS Elastic Load Balancer (elb), или аппаратной системы типа F5 BigIP. Они сконфигурированы с sticky-сессиями, где каждая пользовательская сессия подается на один сервер. Когда один из них умирает, другие берут на себя ответственность; любой пользователь с сеансом на выключенном блоке перезапуска перезапускается, и это жизнь. Кодируйте свой сайт так, чтобы такое прерывание сеанса не повреждало вещи.
State Doesn't Matter обрабатывается так же, как и сеанс с одним состоянием на одном сервере, но главное отличие заключается в отсутствии "липких" сеансов. Балансировщики нагрузки настроены на подачу каждого запроса к любому серверу в пуле, а состояние подачи веб-серверов из базы данных по каждому запросу. Когда один сервер умирает, никто не замечает.
.