Как мы реализовали отказоустойчивый WireGuard в трёх зонах Yandex Cloud

[Botkin]

Интересно. А сам NLB не умеет просто долбить в первый, а если он недоступен, то в следующий? Без необходимости логику реализовывать на серверах wg

[netw0rker]

NLB умеет распределять трафик в соответствии с 5-tuple hash по всем целевым ресурсам для которых проверки живости (Health Checks / HC) зеленые. Наливать трафик только на какой-то отдельный взятый ресурс не получится (для этого у других ресурсов надо HC сломать).

[andreysam]

Конкретно с NLB Яндекса не работал, но имел опыт с виртуалками. По моей памяти они очень даже стабильно работают. Вот и возникает вопрос, насколько эффективна текущая конфигурация с несколькими вм за единой точкой отказа в виде NLB? В документах Яндекса указано, что уровень обслуживания у ВМ даже выше, чем у NLB(99.95 против 99.9). Всё конечно зависит от кейса, но будто проще конечному пользователю передать резервный адрес (которым он не факт, что когда либо воспользуется), чем делать сложное авто переключение. В случае соединения офисов ещё проще поднять одновременно несколько соединений на разные сервера и переключаться в зависимости от доступности. Спасибо за статью!

[BaCuJIuu]

Виртуалки очень надежны, аптайм некоторых сервисов исчислялся сотнями дней, но случается так, что целая зона лежит 12 часов (https://status.yandex.cloud/ru/incidents/1129), собственно это и побудило на написание данной статьи.

Да и те же виртуалки надо иногда обслуживать, желательно без большого простоя)

Конечных пользователей (живых) нет, все удаленные клиенты это сервера на колесах (несколько сотен, и не все одновременно в сети), администрировать сетевое оборудование этого парка, выстраивать логику работы переключения на нём накладнее, чем поднять отказоустойчивый впн и поддерживать его иаком.

[GTDOGg]

Мне кажется,что Вы пошли по неверному пути. Я не знаю вашу задачу,при которой нужно иметь отказоустойчивый vpn сервер в России,но если для подключения к внутреннему контуру и реализации защиты веб сервисов и API от внешних воздействий,то лучше использовать OpenZiti или Ngrok,коль уж Clodflare tunnel и warp в РФ нежелателен

[yellowmew]

Мнение:

с таким использованием NLB вы за него переплачиваете. Не рассматривали просто сделать один IP статическим и похожей на вашу же схемой перебрасывать его между инстансами, не используя NLB?
В скриптах соответственно не будет необходимости останавливать листенер, ибо работать будет только один - как на вход так и на выход. При этом все инстансы сервиса будут хелсчекаться (во внутренней сети) - полезно для мониторинга
А еще, можно использовать keepalived для описанных вами целей (но бОльшая часть ваших скриптов все равно понадобится, хелсчекинг и переключения кипэлайвд будет делать ими). Кипэлайвд умеет в приоритеты: основная нода это мастер, вторая и третья - бэкапы с разными приоритетами

[BaCuJIuu]

Я не очень горю желанием HC делать на внутренних адресах, ведь доступность может отвалиться и на другом уровне. По этому каждая ВМ имеет внешний статический адрес который используется для проверки. 6 копеек за гигабайт не высокая плата.

[yellowmew]

доступность может отвалиться и на другом уровне

может

Но одновременно с этим то что "А" и "Б" видят "В" не означает что "В" виден клиентам, поэтому во внутреннем хелсчекинге, имхо, нет ничего плохого - он информационный, а реальную доступность надо проверять вообще третьим сервисом, имитирующим клиента (или же если вы про кипэлайвд - он не проверяет внутренними хелсчеками другие ноды, он проверяет живость только своей, и в случае фейла - слагает полномочия. Перекличка "живых" - другими методами)

[BaCuJIuu]

ну способ рабочий, имеет право на жизнь)

[yellowmew]

так я и не спорю, просто предлагаю альтернативу(и задаю вопросы, для самообразования, мало ли какой кейс еще есть). Вы скриптом по сути сделали хелсчекинг (на своих правила) и автопереключение, подобное задаче которую я решал в прошлом проекте (но там нужно было сделать автопереброс EIP с одной ноды на другую, плюс ноды были равнозначные)

[nick1982ad]

Статья скорее демонстрирует нам все убожество инструментария сети Yandex Cloud. Почему там недоступны инструменты, которые в корпоративных сетях прекрасно использовались еще 20 лет назад? И почему нет инструментов уже характерных для облачных сред (типа того же Site recovery manager)?
Вот и переноси после этого все ресурсы в облака... Зато можно поразвлекаться, делая свой аналог VRRP дендрофекальным методом...

[jenki]

Вы же знаете, что согласно МКБ есть такая болезнь Яндекса в народе именуемая велосипедостроением. Со всеми вытекающими последствиями. И это чуть ли не повсеместно и практически во всех продуктах этой компании.

Куда важнее другое. Причина побудившая автора статьи на такое решение - сетевая недоступность некоторых зон доступности. Если посмотреть список инцидентов, то складывается впечатление, что сеть яндекса представляет из себя тестовый полигон для подготовки к сдаче экзаменов на получение сертификатов CCNA. Ну и при выходе из строя NLB в соответствующей зоне доступности (такое бывало и не раз) толку от такого решения мало.

[nick1982ad]

Я так понимаю про наличие GSLB у Яндекса просто глупо спрашивать?