Есть веб-сервер. Для простоты не будем рассматривать L7-балансировку, и будем считать, что сервер подключен напрямую к внешнему миру через два WAN-соединения (и имеет два ip-адреса). Интересует организация сети на уровне TCP/IP (L3/L4), чтобы обеспечить балансировку (при работе обоих интерфейсов) и отказоустойчивость (при отказе одного).
1) Простой вариант — прописать в DNS два этих ip-адреса. Балансироваться будут, но переключения на второй канал не будет.
2) Более сложный вариант — L3/L4 балансеры (пусть будет пока один) с виртуальным IP. Но стоять он должен где-то во внешнем мире, только так он сможет что-то балансировать.
2а) Можно взять условный VPS, организовать на нем балансер, гонять трафик через него. Какие open source системы это делают — LVS?
2б) Такой балансер можно взять в аренду в облаках (AWS, GCP). Это завязывает на провайдера. Трафик из их сетей во внешний мир очень дорогой.
2в) Возможно бывает у "простых" провайдеров услуга virtual ip? Или она не не мыслима без всяких BGP и прочих сложных штук?
И вообще, можно ли уменьшить трафик с балансера, перекинув соединение на реальные ip сервера? Как это делается? Чтобы например, на балансере был только входящий трафик, а исходящий шел с реального ip.
Путаница в голове, проясните, пожалуйста.
ДОБАВЛЕНО:
Перефразирую — мне нужна услуга virtual ip (расположенная где угодно). При этом серверы с реальными ip находятся в моей сети.
Ищется провайдер с такой услугой или способ организовать ее самостоятельно.
Да, спасибо, где-то раньше слышал про CARP.
V_>Несимметричный траффик возможен, но не имеет экономического смысла/ По простому только внутренний исходящий траффик отдельно
Почему смысла нет. Если нужно оплачивать трафик балансера, то лучше прогонять через него только входящий трафик (сильное меньше исходящего)
V_>Простой WAN failover можно на VPN создать, если VPN исходящий через multi-wan. Но это не твой случай, да и точка входа для VPN не failover
Да, я и предполагал — взять VPS, сделать к нему два канала VPN (GRE?) и гонять трафик. Но трафик стоит денег (а может и не дорого это все не больших сервисов?). Но в любом случае этот VPS поддерживать — их две штуки надо + как-то синхронизировать.
Тот же CARP, он работает внутри сегмента одного. Не факт, что у провайдера можно арендовать два VPS внутри сегмента. Или опять же между ними канал делать — что-то вообще сложно. Проще арендовать
V_>Вот этот вот on-prem setup с провайдеровскими IP и прочим, обойдется дороже, чем недорогой LB:
У меня такое ощущение, что это микро-AWS/GCP. Они предполагают virtual ip внутри своих сетей. Т.е. серверы должны находится у них.
Здравствуйте, Буравчик, Вы писали:
Б>Есть веб-сервер. Для простоты не будем рассматривать L7-балансировку, и будем считать, что сервер подключен напрямую к внешнему миру через два WAN-соединения (и имеет два ip-адреса). Интересует организация сети на уровне TCP/IP (L3/L4), чтобы обеспечить балансировку (при работе обоих интерфейсов) и отказоустойчивость (при отказе одного).
Б>1) Простой вариант — прописать в DNS два этих ip-адреса. Балансироваться будут, но переключения на второй канал не будет.
Если DNS задаёт некоторый внешний ресурс, который проверяет живость адресов — он может задавать только доступные сейчас адреса.
TTL уменьшить до адекватных пределов (например, 3 минуты).
Б>2) Более сложный вариант — L3/L4 балансеры (пусть будет пока один) с виртуальным IP. Но стоять он должен где-то во внешнем мире, только так он сможет что-то балансировать.
Или несколько таких.
Б>И вообще, можно ли уменьшить трафик с балансера, перекинув соединение на реальные ip сервера? Как это делается? Чтобы например, на балансере был только входящий трафик, а исходящий шел с реального ip.
По максимуму перекинутьв всё кроме входных страничек...
Здравствуйте, netch80, Вы писали:
N>Если DNS задаёт некоторый внешний ресурс, который проверяет живость адресов — он может задавать только доступные сейчас адреса. N>TTL уменьшить до адекватных пределов (например, 3 минуты).
Т.е. надо свой DNS поднимать? Чтобы он умел проверять реальные ip?
Б>>2) Более сложный вариант — L3/L4 балансеры (пусть будет пока один) с виртуальным IP. Но стоять он должен где-то во внешнем мире, только так он сможет что-то балансировать. N>Или несколько таких.
Не понял, в чем существенное отличие нескольких по сравнению с одним (кроме отказоустойчивости)?
Б>>И вообще, можно ли уменьшить трафик с балансера, перекинув соединение на реальные ip сервера? Как это делается? Чтобы например, на балансере был только входящий трафик, а исходящий шел с реального ip.
N>По максимуму перекинутьв всё кроме входных страничек...
Прочие (не входные) странички же тоже балансировать надо. А значит трафик останется на балансере
Б>Почему не получится? Просто нужен третий провайдер, у которого есть доступ к первым двум.
Да, но цена вопроса. Свой BGP AS номер, настройка, поддержка.
Б>Да, спасибо, где-то раньше слышал про CARP.
Это как пример компонентов системы. Иллюстрация WAN switch, Uplink провайдеров. CARP это уже "ниже по течению", ближе к тебе. Failower самого Gateway
Б>Почему смысла нет. Если нужно оплачивать трафик балансера, то лучше прогонять через него только входящий трафик (сильное меньше исходящего)
Для ответов основного траффика, тебе нужна та же пропускная способность и надежность, что и для входа.
Если мы про внутренний траффик. Что есть вызовы платежных систем от сервера, апдейты, сервисы. Он, обычно, гораздо скромнее. Максимум, это APM (logging в какой-нибудь DataDog, мониторинг)
Б>Да, я и предполагал — взять VPS, сделать к нему два канала VPN (GRE?) и гонять трафик. Но трафик стоит денег (а может и не дорого это все не больших сервисов?). Но в любом случае этот VPS поддерживать — их две штуки надо + как-то синхронизировать.
Это дорого только для всяких домашних случаев. Когда эти $10+ заметны. Но там и LB не нужен
А так, если сервис нагруженный, то там и поток денег от клиентов должен быть "нагруженный". Т.е., если у тебя прибыль от клиента сопоставима с ценой траффика им генерируемым, то оно не взлетит. Вручную будет еще дороже
Б>Тот же CARP, он работает внутри сегмента одного. Не факт, что у провайдера можно арендовать два VPS внутри сегмента. Или опять же между ними канал делать — что-то вообще сложно. Проще арендовать
CARP тебе не нужен в данном случае. LB + несколько VPS. За $10/мес, сэкономленное время пустишь на решение других проблем
Б>У меня такое ощущение, что это микро-AWS/GCP. Они предполагают virtual ip внутри своих сетей. Т.е. серверы должны находится у них.
У тебя есть тяжелый и не быстрый компонент внутри? Все сервера не обязаны находиться внутри сети провайдера. Только то, что high load, low latency и прочее. Внутреннюю БД для подкачки можно прикрутить. При помощи того же VPN, от On-Prem к провайдеру с VPS
Здравствуйте, Vetal_ca, Вы писали:
V_>А так, если сервис нагруженный, то там и поток денег от клиентов должен быть "нагруженный". Т.е., если у тебя прибыль от клиента сопоставима с ценой траффика им генерируемым, то оно не взлетит. Вручную будет еще дороже
Да, согласен, трафик наверное не так уж и дорог. Не знаю почему заморочился.
V_>CARP тебе не нужен в данном случае. LB + несколько VPS. За $10/мес, сэкономленное время пустишь на решение других проблем
V_>У тебя есть тяжелый и не быстрый компонент внутри? Все сервера не обязаны находиться внутри сети провайдера. Только то, что high load, low latency и прочее. Внутреннюю БД для подкачки можно прикрутить. При помощи того же VPN, от On-Prem к провайдеру с VPS
LB + 2 VPS в одном облаке. VPS связаны с реальными каналами по VPN.
Норм вариант
