Що переживає перемикання VIP проксі?
Відокремте відновлення входу проксі від збереження встановлених тунелів CONNECT і зовнішньої адреси щодо сайту.
Плаваюча адреса зберігає налаштування проксі стабільним: після відмови активної машини клієнти продовжують використовувати те саме ім'я хоста або IP. Це корисна доступність. Але вже розпочате завантаження все одно може перерватися.
Розгляньте HTTPS-запит, який уже перебуває всередині CONNECT. Активний проксі володіє TCP-з'єднанням із клієнтом і ще одним з'єднанням до сайту. Він також володіє станом застосунку, що з'єднує ці потоки.
Перенесення адреси на резервну машину саме собою не переносить ані блоку керування TCP, ані цього стану ретрансляції. Новий власник може приймати нові з'єднання, але не може продовжити потік байтів, встановлений старим.
| Очікування | Чи дає це звичайне перемикання адреси? |
|---|---|
| Зберегти один налаштований вхід | Це і є задумана перевага |
| Продовжити встановлений потік CONNECT | Знадобиться додатковий механізм зі станом |
| Зберегти ту саму зовнішню публічну IP | Залежить від маршрутизації виходу та NAT |
| Безпечно повторити перервану операцію | Залежить від операції та клієнта |
VRRP визначає вибори та володіння адресою. Це не протокол реплікації для процесу проксі. Розгортання з іншим програмним забезпеченням високої доступності потребує того самого розрізнення, якщо воно явно не надає більше.
Перегляньте, що насправді спостерігає перевірка працездатності. Машина може відповідати на оголошення, коли її служба проксі, DNS або вихідний маршрут уже відмовили. І навпаки, надто чутливі перевірки спричиняють непотрібні перемикання.
Відновлення на боці клієнта теж важливе. Новий запит браузера легко перепідключиться; завантаження з уже використаним тілом або неідемпотентна операція API може вимагати обробки, специфічної для застосунку. Не обіцяйте невидимого перемикання лише тому, що новий запит проходить через резерв.