Посоветуйте параллельный метод работы более одного VDS

О чём я и написал где-то в начале этой темы. А дальше уже пошёл какой-то поток самовыражения.

Да задача на самом деле не сложная, по крайней мере из того что вы процитировали. Не очень понятен только почему разный IP. Самый тривиальный вариант это балансировщик с резервированием, раньше настраивали VRRP, да и в целом селектел предоставляет плавающий IP, перекидывать его в целом может какой нибудь супервизор который следит за живыми серверами. Далее за балансировщиком стоят 2 виртуалки одна в Питере другая в Москве там запущен код, далее заказываем облачную БД с 2 доп репликами и в целом тут можно остановится, бложик на вордпрессе будет обходится порядка ~15к рублей в месяц, за то без простоев и с переключением. Хз что там за топ 10, но сейчас это задача решается достаточно просто, но не дешево.

ОП, похоже, хочет быть защищенным от падений именно ДЦ.

А когда падает ДЦ, то балансировщики должны упасть вместе  с ним.
Иначе зачем разносить сервера именно по разным ДЦ?

Если датацентр работает хорошо, вместе со всеми своими балансировщиками, то наличие копии приложения в другой локации поможет мало.

Балансировщик может помочь решить проблемы горизонтального масштабирования в рамках одного ДЦ.

В задаче ОПа нужно либо работать на уровень выше - это DNS, либо как условный Google переходить на железные сверхпроизводительные балансировщики где-то в изолированных защищенных многократно резервированных строениях, которые никогда не падают, не перезагружаются и хитро связаны между собой и серверами.

В Селектеле балансировщики держат, как понял, 34000RPS HTTP или 9000 HTTPS. Это не так, чтобы много. Исходя из этих значений, положить его с помощью спец.сервиса сможет даже небогатый школьник (извините, настоящие школьники, речь не о вас, это старый IT-термин, обозначающий молодых, безответственных хулиганов, которым по причине малого возраста ничего не грозит даже в случае поимки).

В жизни мне дважды доводилось сталкиваться с одним типом атак, от которых шевелились волосы на голове. Это когда нагрузка на сами сервера в порядке, а сеть накрывает волнами непонятных снижений пропускной способности. Может быть это были какие-нибудь DNS-амплификации или атаки непосредственно на сетевые устройства на более низких уровнях OSI. Сложно сидеть и понимать, что ничего не можешь сделать.  А тут - чужой балансировщик, который непонятно как настроен, что на нем происходит и как его защищать. "Школьники" кинут копейку крипты на стpeсcбот и начнётся веселье. И что делать, когда всё уже завязано на этом балансировщике?

Облачная БД - это интересно. Раньше запросы к ним были значительно дороже, чем при использовании баз данных на своих серверах, а скорость доступа была чуть ниже. Было бы интересно посмотреть насколько ситуация стала лучше за несколько лет.

UPD.: Ну вот, по облачным базам в Селектел. Три хилых 16-ядерных сервера в СПб

PostgreSQL 14
Санкт-Петербург
32 vCPU
128 ГБ RAM
1024 ГБ диск
Подсеть /29 (5 адресов IPv4)
2 реплики
Итого: 243 855,13 ₽/мес.

Как сделать географическое распределение пока не понял.

И за эту цену я наверно собрал бы конфигурации поинтереснее на условном AMD 7443P.

Вы не вникли в услугу, балансировщик с резервированием это значит что если упадет ДЦ с балансировщиком, то IP адрес уйдет другому балансировщику в другом ДЦ, вам как клиенту ничего делать не надо для этого, только платить.

Это много, проектов такого масштаба в рунете можно пересчитать по пальцам. Но скиньте ссылку где вы это прочитали, там написано что используют HAProxy, а про производительность его можно прочитать например тут https://www.haproxy.com/blog/haproxy-forwards-over-2-million-http-requests-per-second-on-a-single-aws-arm-instance 

PS. Я понял где вы прочитали, но там есть ссылочка на запрос кастомной конфигурации балансировщика если требуется

Не очень понимаю при чем тут это, оно не призвано бороться с паразитным трафиком, под 9000 RPS я так предполагаю скорее всего умрет сервер за балансировщиком раньше.

С чего вы взяли что они хилые?

Вам его как клиенту делать не надо

Никто не утверждает, что облако это недорого, облака это про другое, это когда вы используете например 3 дохлых реплики на 2 ядра и 4 гига и в случае прилета нагрузки, ваша БД запускается на инстансах в 16 ядер, а когда нагрузка падает то оно снова работает на 2 ядрах. Дело в том, что вам не надо платить всегда такую сумму, 90% времени эти ресурсы у вас будут простаивать, но в вашем случае если вы вбруг упретесь в свои ресурсы, то за минуту еще один железный ящик вам никто не предоставит в отличии от облачной БД. Вы не путайте услуги и пользуйтесь ими правильно и с умом

Туповата любая схема, РКН блочит по доменному имени, и хостер заблокирует ресурс независимо от IP.
Вообще непонятно, откуда наш друг нафантазировал про РКН.
Если хостер забугорный, то всё равно заблокируют провайдеры интернета, прыганье по разным IP - это ненадолго и тут вообще ни при чём "боюсь падения VDS даже на минуту ", согласно стартпосту.

Это интересная штука.
Раньше знал только про FailoverDNS, которые перключаются не мгновенно, а за пару минут или даже сильно дольше. Как, интересно, такое может быть реализовано, надо почитать...

Кстати, вариант - поднимать инстансы с приложением, у которых локальная база будет в SQLITE, а важные изменяемые данные - подтягиваться и обновляться с управляющего сервера по API с БД в надёжном ДЦ. 

Если нагрузки небольшие, управляющий сервер может  сам создавать и запускать такие инстансы в работу по мере их падения, а также время от времени актуализировать локальные БД для повышения их производительности.

Время на переключение DNS будет не слишком малым. Но можно поднять свой DNS с API и выставить на нём минимальное TTL. Либо найти провайдера DNS с API и возможностью устанавливать такое минимальное TTL.

Legal notice: Конечно же, противозаконное использование таких технологий недопустимо !0!

Можете начать от сюда https://ru.wikipedia.org/wiki/VRRP

Что то вы всё слишком усложняете, вы свои решения для своих больших проектов приводите, думаю если бы у ТС был такой проект, то он бы не задавал вопрос на форуме, а просто нанял бы работников с соответствующей квалификацией.

у меня sqlite отлично работает и огромное количество запросов держит, запись данных НЕ идет напрямую в файл базы с которым взаимодействуют посетители, все новые данные вносятся в копию базы после чего файлы переименовываются, в случае ошибки всегда можно назад переименовать, но за годы работы проблем не было пока.

Спасибо, это один из самых интересных материалов по IT, что я читал в этом месяце.

С первой итерации не получилось понять как всё это взаимодействует с TCP-IP, какой путь проходит пакет и много других деталей. Но даже для далёкого от сетей человека понятно в каком направлении следует изучать дальше.

Первое понимание такое:

1. Несколько маршрутизаторов, объединенных в один виртуальный, находятся на одном IP и получают одинаковые пакеты.
2. Между собой они решают, кто обработает эти пакеты и отправит дальше.
3. Один выбранный маршрутизатор обрабатывает пакет, остальные ждут.
4. Если некоторые маршрутизаторы выключены, то оставшиеся продолжают работать по тому же принципу в сответствии с их приоритетами.

Общие принципы описаны верно?

Если так, то пока непонятно, возможно ли назначить один IP маршрутизаторам из разных датацентров? Похоже, что для этого в каждом из двух ДЦ должна быть одна AS. Теоретически это наверно возможно в случае, когда оба ДЦ принадлежат одной компании. 

Один комментарий на хабре также похоже намекает, что обрыв аплинка одного из маршрутизаторов, который не выключен, без дополнительных настроек и/или железа может приводить к появлению blackhole для пакетов.