Практики SRE: SLO, инциденты, отказоустойчивость / Ступень 7 из 8

Балансировщик и проверка здоровья

Не запущена Запускается обычно ~20 с

Шаг 9 из 10 · лаба · 30 мин

Адрес сайта не переезжает на запасную машину

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

Ситуация

Сайт магазина shop.lab.test живёт на плавающем адресе — VIP: имя указывает на адрес .100 в сети машин (строка в /etc/hosts обеих машин, там же — короткое имя vip). Адрес держит keepalived: в обычном режиме он у node1, а если node1 упадёт, его должен подхватить node2. На обеих машинах работает nginx с одной и той же страницей, только каждая подписана своим именем: shop: served by node1 или shop: served by node2.

На учениях остановили keepalived на node1 — так выглядит падение машины для её соседа. Адрес с node1 ушёл, а сайт пропал: на node2 ничего не переехало.

node1 — твой терминал. Команды на node2 выполняй через SSH: ssh node2 'команда' или войди в оболочку — ssh node2, назад — exit. sudo на обеих машинах работает без пароля. Где сейчас адрес и кто отвечает по нему:

ip -br a; ssh node2 ip -br a
curl -s http://shop.lab.test/

Задача

В обычном режиме плавающий адрес — на node1, и только на нём; сайт http://shop.lab.test/ отвечает страницей node1.
Когда keepalived на node1 останавливается, не позже чем через 10 секунд адрес на node2, а сайт по нему отвечает страницей node2.
Когда keepalived на node1 снова запущен, не позже чем через 10 секунд адрес возвращается на node1.

«Проверить» само останавливает keepalived на node1, смотрит, куда ушёл адрес и кто отвечает по нему, потом запускает keepalived обратно и ждёт, когда адрес вернётся. Проверка занимает до 40 секунд.

Ограничения

Всё должно пережить перезагрузку обеих машин: службы включены, настройки лежат в файлах, а работающие службы прочитали эти файлы после правки.
Плавающим адресом управляет только keepalived: не назначай его вручную (ip addr add) и не прописывай в настройках сети.
node1 остаётся главной машиной: не меняй его настройки keepalived и не отдавай адрес node2 насовсем.

Интернета в лабе нет — только сеть между node1 и node2, всё нужное установлено. Устрой учения сам: sudo systemctl stop keepalived на node1, посмотри, где адрес и что отвечает сайт, затем sudo systemctl start keepalived.

Лаба · самостоятельно

Команды в этой лабе не даны: набирай их в терминале сам. Цели проверяются на машине после каждой команды.

Цели

0 из 4

В обычном режиме плавающий адрес — на node1 и только на нём, сайт http://shop.lab.test/ отвечает страницей node1 — ещё не выполнена
Когда keepalived на node1 останавливается, не позже чем через 10 с адрес на node2, а сайт по нему отвечает страницей node2 — ещё не выполнена
Когда keepalived на node1 снова запущен, не позже чем через 10 с адрес возвращается на node1 — ещё не выполнена
keepalived и nginx на обеих машинах включены и работают с настройками из своих файлов — всё переживёт перезагрузку — ещё не выполнена

Ctrl+Enter

Запустит машину node1 · Ubuntu 24.04

Машина запускается

Подсказки

0 из 3

Сообщить о проблеме

Цели лабы

0 из 4

В обычном режиме плавающий адрес — на node1 и только на нём, сайт http://shop.lab.test/ отвечает страницей node1 — ещё не выполнена
Когда keepalived на node1 останавливается, не позже чем через 10 с адрес на node2, а сайт по нему отвечает страницей node2 — ещё не выполнена
Когда keepalived на node1 снова запущен, не позже чем через 10 с адрес возвращается на node1 — ещё не выполнена
keepalived и nginx на обеих машинах включены и работают с настройками из своих файлов — всё переживёт перезагрузку — ещё не выполнена

node1 Ubuntu 24.04

Для запуска машины нужен вход

Машина запускается на твой аккаунт, там же хранится прогресс. Читать можно без входа.

После входа вернёшься на эту лабу.

Цели лабы

0 из 4

В обычном режиме плавающий адрес — на node1 и только на нём, сайт http://shop.lab.test/ отвечает страницей node1 — ещё не выполнена
Когда keepalived на node1 останавливается, не позже чем через 10 с адрес на node2, а сайт по нему отвечает страницей node2 — ещё не выполнена
Когда keepalived на node1 снова запущен, не позже чем через 10 с адрес возвращается на node1 — ещё не выполнена
keepalived и nginx на обеих машинах включены и работают с настройками из своих файлов — всё переживёт перезагрузку — ещё не выполнена

Сеть · подобрано по лабе

Балансировка нагрузки — копии за одним адресом и проверка здоровья

Шпаргалка

$_ — вставить в терминал

sudo nginx -T | grep -A4 '^upstream' копии и их параметры
tail -n 5 /var/log/nginx/access.log $upstream_addr: кто ответил
sudo tail -n 3 /var/log/nginx/error.log почему копия выпала
curl -s -o /dev/null -w '%{http_code}\n' 127.0.0.1:8082 копия сама
curl -s -o /dev/null -w '%{http_code} %header{x-upstream}\n' localhost
sudo nginx -t && sudo systemctl reload nginx применить без простоя
ip -br a VIP — второй адрес интерфейса

Убрать копию из ротации на время работ

nginx

server 127.0.0.1:8082 down;

sudo nginx -t && sudo systemctl reload nginx — копия больше не получает новых запросов, текущие доходят. Вернуть — убрать down и снова reload. reload не рвёт соединения, restart рвёт (nginx).

Сколько запросов досталось каждой копии

bash

grep -o 'upstream=[^ ]*' /var/log/nginx/lb-access.log | sort | uniq -c

Поле upstream= — подпись $upstream_addr в формате журнала; в своём формате ищи то же поле. Перекос — weight, ip_hash, копия выключена после неудач или помечена backup.

Найти больную копию

bash

for p in 8081 8082; do
  curl -s -o /dev/null -w "$p %{http_code} %{time_total}\n" \
    http://127.0.0.1:$p/
done

Запрос к каждой копии напрямую, мимо балансировщика: код и время ответа. Копия на другой машине — её адрес вместо 127.0.0.1.

Каждый второй запрос — ошибка

Одна копия из двух отвечает 500 или 503 сама. Для nginx такой ответ — успешный: копия остаётся в ротации, и через раз пользователь получает ошибку. Почини копию, убери её (down) или добавь коды в proxy_next_upstream (load-balancing). Какая копия отвечает ошибкой — $upstream_addr у строк с 500 в журнале.

Запрос висит минуту, потом ответ

Копия недоступна по сети или зависла, и nginx ждёт proxy_connect_timeout или proxy_read_timeout — по 60 с. В error.log — upstream timed out (110: Connection timed out). Поставь 2–3 секунды (load-balancing).

no live upstreams

text

[error] … no live upstreams while connecting to upstream,
  … upstream: "http://app/"

Все копии группы выключены после неудач — клиент получает 502, в $upstream_addr вместо адреса имя группы (app). Почини хотя бы одну копию: через fail_timeout nginx попробует их снова.

Копию починили, а запросов на неё нет

не прошёл fail_timeout после последней неудачи;
у строки осталась пометка down или backup;
копия указана именем, а адрес сменился: nginx разрешает имена в upstream при загрузке конфига — нужен reload.

В error.log нет строки о выключении копии

upstream server temporarily disabled nginx пишет с уровнем warn, а error_log в Ubuntu ведёт уровень error и выше. Выключение копии видно по Connection refused и upstream timed out в error.log и по спискам в $upstream_addr.

max_fails=0

Учёт неудач выключен: мёртвая копия остаётся в ротации навсегда. При отказе в соединении это лишний повтор на каждом запросе, при зависшей копии — тайм-аут на каждом её запросе.

Повтор запросов, которые меняют данные

non_idempotent в proxy_next_upstream разрешает повторять POST на другой копии. Если первая копия успела выполнить запрос и упала на ответе, заказ или платёж пройдёт дважды.