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

Непонятно какие проблемы вы решаете таким разбросом. Разные ДЦ обычно используют для отказоустойчивости, ваше распределение через всю страну неэффективно в целом. Обычно сервера для статики ставят поближе к пользователю, для этого есть CDN. Если для вас критичен пинг, то вы ставите 2 отдельных проекта один в Питере один во Владике и уже придумываете способ синхронизации нужных данных, но людей с Владика вы ведете исключительно на сервер во Владике, а с Питера исключительно в Питер, так как пинг критичен, репликация БД вам тут не нужна, у вас она из-за сетевых задержек постоянно будет отставать при том скорее всего критично. Я не занимаюсь игровыми проектами, поэтому в целом нам хватает локаций Питер-Москва чтоб построить отказоустойчивый кластер, хотя наша розница и клиенты так же есть во Владивостоке.

PS. У меня есть проект в ОАЭ, так сервер под проект вообще живет в Германии так как чет ничего нормального поближе не нашлось и ничего

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

Вспомним OVH, 2021 год.

Это грустно. Вы правильно уловили мою мысль, вот как раз возвращаясь к вопросу из стартпоста, когда сервера территориально размещены в разных ДЦ, пусть даже недалеко в одном городе. Насколько вообще практикуется выделение локальной линии между ДЦ для клиентов? Чтобы на серверах стояли интерфейсы с внутренними IP для взаимодействия с серверами клиента в соседнем ДЦ? Или я слишком много хочу?

Почему то репликацию пытаются натянуть на отказоустойчивость, оно не для этого, репликация нужна для распределения нагрузки запросов на чтение. Можно поставить какую то реплику в другой резервный ДЦ и в обычной работе приложения её не использовать или использовать для создания бэкапов и так далее, но в целом это очень редкие ситуации типа овх 2021 хотя я не знаю что это и никогда там не хостился. в большинстве случаев хватает бэкапа в другой ДЦ эффект примерно тот же, а если его делать правильно и нужными инструментами то развернуть его будет не сильно то и сложно в сравнении того чтоб раз в жизни переключить приложение на другой ДЦ. При том с учетом того что это еще никто и тестировать постоянно не будет, то то что это нормально переключится еще не факт.

В селектеле есть, мы используем. Если говорить про виртуалки есть еще в 1cloud, видел но не пробовал

Ну такие глобальные, с полной потерей данных, - действительно редкость. Но случаются и чуть менее серьёзные, типа как мастерхост простаивал неделю из-за разборок между собственниками. Гораздо чаще - когда в ДЦ  внезапно "электричество кончилось" или экскаватор оптоволоконку покромсал. А уж простои на полчаса - час -два - вообще сплошь и рядом.
Тема, к сожалению, давно ушла в сторону от того, о чём написано в её названии и в стартпосте, но по смыслу темы имеются в виду как раз серверы в разных ДЦ.

Когда вы сознательно выбираете предложения на рынке из разряда по дешевле (лоукостеров или как там), вы сознательно идете на риск что кончится электричество, удалятся все данные и прочее, ведь так? Я вначале в своих первых сообщениях написал что выбор в сторону проверенных ДЦ и больших хостеров, а так же на физических машинах в целом позволяет держать аптайм на уровне не ниже 99.9, а в основном и выше, на селектеле опять же повторюсь, на одном проекте у меня с 2019 года аптайм 99.999. а с 2017 простой был у селектела максимум 2ч когда там грохнулось какое то сетевое оборудование у ДЦ.

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

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

Каждая из этих тем довольно сложна. А когда они перемешиваются, сложность коммуникации еще более возрастает.

Резервирование, масштабирование, надёжность, мониторинг, доступность, устойчивость к сбоям, удобство и скорость развертывания, применимость для разных типов приложений и в разных ситуациях, архитектура баз данных, взаимодействие с ДЦ и многие другие темы - по каждой из них можно писать монографию и даже в ней не охватить полностью все многочисленные детали.

Информации о проекте почти нет.

IP разные, VDS-ы тоже 

на разных хостингах
, домен один и тот же. 
Требуется «бесшовно» переключать одну машину на другую при падении «головной». 
Как вы это реализуете? 

Да никак мы это не реализуем. Я о задаче такой сложности читал только один раз, когда обсуждалось как транснациональные корпорации из ТОП-10 организуют доступность своих сервисов по всему миру.

Насколько помню (так как читал давно), у них используется спец.железо, на котором строится некая сетевая структура. Спецификации как железа, так и организации сети в то время в паблике я не находил, вероятно проприетарные.

Можно (но не нужно) пойти простым, очевидным путём. Подключить какой-нибудь сервис DNS Failover (и верить, что не упадёт он).
Взять и продублировать всю инфраструктуру на два ДЦ, настроить репликацию и мириться с тем, что либо данные в базе будут неактуальными, либо всё будет тормозить.