Отказоустойчивость сервера важна в том числе для небольших проектов, для крупных она обязательна и при проектировании инфраструктурного решения обычно исходят прежде всего из того, что критичные сервисы должны работать всегда. Или закладывается минимальный простой на случай аварии.
Работа каждого сервера характеризуется таким параметром как UPTIME.
В хорошо спроектированной системе структура такая, которая позволит сохранить работоспособность в максимальном количестве внештатных ситуаций. Риск в случае появления аппаратных проблем, проблем с сетью, аварий в датацентре нужно свести к минимуму.
Если рассматривать систему для сайта, то в ней всегда будут следующие компоненты:
- фронтэнд-сервера, принимающие запросы и балансирующие их
- бэкенд-сервера, выполняющие скрипты
- сервера баз данных, часто объединенные в кластеры
- хранилища сессий
Для каждого проекта требования индивидуальны — основное правило всегда — избегать появления единой точки отказа. Отказоустойчивость сервера обеспечивается тем, что элементы системы дублируют друг друга и автоматически переключаются при сбоях.
Например, HAPROXY на фронтэнде. Он обычно ставится чтобы разгрузить бэкенд сервера и получить гарантию того, что запросы будут выполняться при падении одного из них.
Решение не самое лучшее потому, что если что-то случится в с фронтэндом система полностью перестанет работать.
Можно поставить 2 фронтэнда, каждый из которых будет проксировать запросы на бэкенды. При этом в DNS для доменного имени прописать две A-записи, указывающие на сервера с HAPROXY.
Если сервер одним из фронтэндов перестанет работать все запросы, попадающие на него будут завершаться ошибкой. Запросы на другой фронтэнд при этом будут нормально обрабатываться.
Таким образом, ошибки будет видеть каждый второй посетитель сайта. Соотношение можно изменить добавляя фронтэнды. Если их поставить 10 — в случае падения одного из серверов только каждый десятый посетитель сайта увидит ошибку.
Состояние всех машин контролируется системой мониторинга, если один из фронэндов стал недоступен — А-запись DNS с его адресом удаляется из доменной зоны. Как только информация обновится (время зависит от установленного TTL — можно поставить 5 минут) система начнет работать без недоступного фронтэнда не выдавая никаких ошибок.
Записи DNS можно менять автоматически.
Отказоустойчивость сервера баз данных
В большинстве проектов используется MySQL. Поскольку почти все часто изменяемые данные хранятся в базе, к которой идут постоянные обращения, данный элемент архитектуры всегда самый нагруженный.
БД на отдельный сервер выносят как только на одной машине ресурсов начинает не хватать. Для нагруженных проектов MySQL всегда работает отдельно от приложения и обычно сервера объединяются в кластеры. Удобнее всего использовать Galera Cluster.
При этом сервера баз данных можно объединить в локальную сеть, весь же кластер сделать доступным по одному белому IP адресу, на который и будут отправляться все запросы.
Хранение пользовательских сессий
Хранить пользовательские сессии на отдельных серверах необходимо при использовании более одной машины, обрабатывающей PHP скрипты — обычно для этого используются Memcache. Memcache из коробки позволяет неограниченно масштабироваться, т.е. в PHP коде можно указать адреса машин, выделенных под хранилище, других настроек не требуется.
Система может расти и расширяться до бесконечности, возможность простого масштабирования как раз является признаком хорошей архитектуры.
При организации данной схемы лучше использовать виртуальные сервера, размещенные в разных датацентрах. Не стоит забывать про NS сервера, отвечающие за разрешение запросов к доменному имени в IP адрес. Они также могут являться точкой отказа.
Нужно либо использовать NS компании, которая может обеспечить их постоянную работу, либо использовать свои NS выделив для этого несколько серверных машин и настроив их необходимым образом.
В любом случае главное правило — иметь несколько записей типа NS. Как и с любыми другими записями здесь работает round robin, т.е. запросы распределяются поровну и несколько записей будут гарантировать, что в случае отказа по крайней мере большая часть посетителей сайта будет получать корректный ответ на запрос к DNS.
Читайте про балансировку в Nginx и тонкую настройку MySQL.