Я собираюсь создать машину HA Linux для веб-сайта моего клиента. Какие у меня есть основные варианты или место / статья, где я могу узнать больше?
Мне тоже очень понравилось бы, если бы это было одно изображение, чтобы существующее программное обеспечение просто работало.
Любая помощь приветствуется.
Спасибо!
У вас есть много вариантов. Какие из них вы можете использовать, зависит от того, как написан ваш сайт.
Сильно связанное, одиночное состояние
Этот веб-сайт может работать только с одним экземпляром по ... причинам. По какой-то причине запуск двух параллельно было бы крайне плохой идеей. Это довольно необычный сайт.
Теорема CAP: Согласованность во всей системе имеет первостепенное значение, не допускает разделения на разделы, что делает доступность первоочередной инженерной целью.
Сильно связанное, одно состояние на сеанс
Этот веб-сайт работает правильно только тогда, когда пользователи все время взаимодействуют с одним и тем же сайтом. Если они попадут не на тот сервер, все может пойти не так.
Теорема CAP: пользовательским сеансам нужна строгая согласованность, но системе это не нужно. В некоторой степени толерантный к разделу, поскольку потерянные сеансы во время сбоя все еще являются ухудшением обслуживания, но система в целом выживет.
Слабо связанное состояние не имеет значения
Наиболее масштабируемый вариант, сайты этого типа сохраняют состояние сеанса на уровне базы данных, если состояние сохраняется вообще. Попадание не на тот сервер, не имеет значения, поскольку веб-сервер просто обращается к базе данных для состояния.
Теорема CAP: пользовательские сеансы довольны слабой согласованностью, устойчивость к разделам очень высока, что означает, что доступность имеет первостепенное значение.
Одно государство является безусловно труднее всего сделать HA, поэтому сайты почти никогда не кодируются для этого. Для этого требуется одна и только одна база данных или набор файлов и один и только один веб-сервер с репликацией или передачей томов между участниками сервера высокой доступности, чтобы другой мог поднять его после смерти первого сервера. Инженерия достаточно сложна, обычно проще перекодировать сайт в приложение с одним состоянием на сеанс, где проблема намного проще.
Но если у вас нет выбора, ваш единственный основной вариант - это кластеризация, например сердцебиение. Соберите группу серверов, настройте репликацию файлов и баз данных и установите правила аварийного переключения. Нелегко.
Единый образ системы не подходит для веб-сайтов, поскольку очень сложно создать одновременно работающую и доступную систему. За системами SSI стоит много инженерных разработок, чтобы обеспечить единое пространство IPC и строгую согласованность на уровне системы, что, как правило, делает веб-обслуживание действительно очень медленным. Его лучше всего использовать для систем, которые требуют такого уровня интеграции между физическими узлами, и веб-обслуживание не является такой системой. Его устойчивость к разделению действительно очень плохая, что делает SSI плохим решением высокой доступности. Это не короткий путь к HA. Вам будет лучше работать с кластером.
Одно состояние на сеанс обычно обрабатывается путем создания нескольких веб-серверов и работы с ними с помощью балансировщика нагрузки, такого как haproxy, AWS Elastic Load Balancer (Эльб) или аппаратную систему, такую как F5 BigIP. Они настроены с липкие сессии где каждый пользовательский сеанс передается на один сервер. Когда один умирает, его заменяют другие; любой пользователь с сеансом в нижнем блоке перезапускается, и это жизнь. Закодируйте свой сайт, чтобы такое прерывание сеанса не повредило вещи.
Состояние не имеет значения обрабатывается так же, как и одно состояние на сеанс, но ключевым отличием является отсутствие липких сеансов. Балансировщики нагрузки настроены для подачи каждого запроса на любой сервер в пуле, а веб-серверы передают состояние из базы данных по каждому запросу. Когда один сервер умирает, этого никто не замечает.