Ок, то есть если у меня будет стоять отдельный сервер с nginx, в конфигах которого прописано
upstream cool_backend{
server 1.2.3.4;
server 5.6.7.8;
}
где 1.2.3.4 - ip адрес основного зеркала, а 5.6.7.8 - адрес зеркала, то при обращении пользователя к nginx и при доступности 1.2.3.4 - он будет всегда попадать ТОЛЬКО на 1.2.3.4 если вдруг по каким-либо причинам 1.2.3.4 лег, а 5.6.7.8 - доступен, то пользователь сразу же попадет на 5.6.7.8? расскажите плиз механизм работы nginx в случае нескольких бекендов
Пользователь будет всегда попадать на сервер на котором установлен nginx, а nginx уже будет проксировать через себя запросы на 1.2.3.4 или на 5.6.7.8. Но если ляжет сервер с nginx запросы никуда дальше не пойдут. Поэтому хорошим резервированием будет вариант с микшированием, т.е. имеем два разных nginx'а которые через себя проксируют на 1.2.3.4 и на 5.6.7.8, сервера с nginx настроены в NS как round-robin записи, итого получаем 4 сервера для резервирования. Можно пойти дальше и в round-robin включить 1.2.3.4 напрямую, зависит от того какой уровень доступности хотим обеспечить и сколько стоит простой.
Поведением nginx при наличии нескольких бэкендов управляет директива proxy_next_upstream. Вот синтаксис её использования:
syntax: proxy_next_upstream [error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_404 | off] [...]
default: proxy_next_upstream error timeout
context: http, server, location
Директива определяет, в каких случаях запрос будет передан следующему серверу:
error — произшла ошибка соединения с сервером, передачи ему запроса или чтения заголовка ответа сервера;
timeout — произошёл таймаут во время соединения с сервером, передачи ему запроса или чтения заголовка ответа сервера;
invalid_header — сервер вернул пустой или неверный ответ;
http_500 — сервер вернул ответ с кодом 500;
http_502 — сервер вернул ответ с кодом 502;
http_503 — сервер вернул ответ с кодом 503;
http_504 — сервер вернул ответ с кодом 504;
http_404 — сервер вернул ответ с кодом 404;
off — запрещает передачу запроса следующему серверу;
Необходимо понимать, что передача запроса следующему серверу возможна только при условии, что клиенту ещё ничего не передавалось. То есть, если ошибка или таймаут возникли в середине передачи ответа, то исправить это уже невозможно.
Тут основной момент для понимания - nginx проксирует, т.е. пропускает через себя. Если сервера на разных каналах будет фактически удвоение общего трафика: клиент -> nginx -> backend -> nginx -> клиент