Условно бесплатная. Что-то серьезнее влога домохозяйки на Тильде не сделать.
Вы наверное это заявляете как эксперт по тильде создавший не один десяток проектов на ней и досконально изучив все возможности я так понимаю? Или это из разряда "слышал звон не знаю где он"? =))
они там будут среди первых 3х позиций и последних 3х, сколько там нынче позиций под директ отдано? То что их там в серп нет это ведь не говорит что это невозможно?
Так вы наверное и сайты хостите дома, зачем кормить дармоедов хостеров? Тильда так то бесплатная =)
Можете начать от сюда https://ru.wikipedia.org/wiki/VRRP
ОП, похоже, хочет быть защищенным от падений именно ДЦ.
А когда падает ДЦ, то балансировщики должны упасть вместе с ним.
Вы не вникли в услугу, балансировщик с резервированием это значит что если упадет ДЦ с балансировщиком, то 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. Самый тривиальный вариант это балансировщик с резервированием, раньше настраивали VRRP, да и в целом селектел предоставляет плавающий IP, перекидывать его в целом может какой нибудь супервизор который следит за живыми серверами. Далее за балансировщиком стоят 2 виртуалки одна в Питере другая в Москве там запущен код, далее заказываем облачную БД с 2 доп репликами и в целом тут можно остановится, бложик на вордпрессе будет обходится порядка ~15к рублей в месяц, за то без простоев и с переключением. Хз что там за топ 10, но сейчас это задача решается достаточно просто, но не дешево.
Ну такие глобальные, с полной потерей данных, - действительно редкость. Но случаются и чуть менее серьёзные, типа как мастерхост простаивал неделю из-за разборок между собственниками. Гораздо чаще - когда в ДЦ внезапно "электричество кончилось" или экскаватор оптоволоконку покромсал. А уж простои на полчаса - час -два - вообще сплошь и рядом.Тема, к сожалению, давно ушла в сторону от того, о чём написано в её названии и в стартпосте, но по смыслу темы имеются в виду как раз серверы в разных ДЦ.
Когда вы сознательно выбираете предложения на рынке из разряда по дешевле (лоукостеров или как там), вы сознательно идете на риск что кончится электричество, удалятся все данные и прочее, ведь так? Я вначале в своих первых сообщениях написал что выбор в сторону проверенных ДЦ и больших хостеров, а так же на физических машинах в целом позволяет держать аптайм на уровне не ниже 99.9, а в основном и выше, на селектеле опять же повторюсь, на одном проекте у меня с 2019 года аптайм 99.999. а с 2017 простой был у селектела максимум 2ч когда там грохнулось какое то сетевое оборудование у ДЦ.
Почему то репликацию пытаются натянуть на отказоустойчивость, оно не для этого, репликация нужна для распределения нагрузки запросов на чтение. Можно поставить какую то реплику в другой резервный ДЦ и в обычной работе приложения её не использовать или использовать для создания бэкапов и так далее, но в целом это очень редкие ситуации типа овх 2021 хотя я не знаю что это и никогда там не хостился. в большинстве случаев хватает бэкапа в другой ДЦ эффект примерно тот же, а если его делать правильно и нужными инструментами то развернуть его будет не сильно то и сложно в сравнении того чтоб раз в жизни переключить приложение на другой ДЦ. При том с учетом того что это еще никто и тестировать постоянно не будет, то то что это нормально переключится еще не факт.
В селектеле есть, мы используем. Если говорить про виртуалки есть еще в 1cloud, видел но не пробовал
В вашем случае у вас шаред канал скорее всего, который сам по себе для репликации не годится, так как между репликами может ходить огромное количество данных, при том чем больше реплик тем больше данных. В общем использовать шаред каналы для репликаций идея прям совсем грустная, лучше всего делать репликации между серверами которые стоят в одном ДЦ и подключены между собой отдельным кабелем в отдельные порты.
Непонятно какие проблемы вы решаете таким разбросом. Разные ДЦ обычно используют для отказоустойчивости, ваше распределение через всю страну неэффективно в целом. Обычно сервера для статики ставят поближе к пользователю, для этого есть CDN. Если для вас критичен пинг, то вы ставите 2 отдельных проекта один в Питере один во Владике и уже придумываете способ синхронизации нужных данных, но людей с Владика вы ведете исключительно на сервер во Владике, а с Питера исключительно в Питер, так как пинг критичен, репликация БД вам тут не нужна, у вас она из-за сетевых задержек постоянно будет отставать при том скорее всего критично. Я не занимаюсь игровыми проектами, поэтому в целом нам хватает локаций Питер-Москва чтоб построить отказоустойчивый кластер, хотя наша розница и клиенты так же есть во Владивостоке.
PS. У меня есть проект в ОАЭ, так сервер под проект вообще живет в Германии так как чет ничего нормального поближе не нашлось и ничего
