GG
В принципе т.к. в днс ответе выдаются multiple A-записи, то для тех же браузеров это тоже не проблема. Да и мобильные приложения - недоступен один ip из ответа, идем на другой.
Проблема, которая не проблема
Size: a a a
2020 February 14
GG
Я на месте клиента не был бы сильно счастлив такой отказоустойчивости
AS
ну это получается затрагивает только тех, у кого днс резолвится на серверах настроенных через одно место, с игнором ttl
AS
все остальные в течении 2х минут перестают получать просто адреса недоступных балансеров
AS
и ходят только на живые
GG
Охеренно
GG
Т.е. 2 минуты пользователь наблюдает протормозки на сайте
GG
Или ты всерьез думаешь, что любой браузер ходит только лишь на живые айпи ?
Р
и как там сид указать?)
не очень понял, про какой сид речь
n🐈
не очень понял, про какой сид речь
это потому что линукс не умеет в него)
AS
Т.е. 2 минуты пользователь наблюдает протормозки на сайте
Как сделать лучше? Могу платить больше денег за более частые хелсчеки, ttl записи не уверен можно ли уменьшить еще, но предположим. Снизим 2 минуты до десятков секунд-1 минуты. А дальше?
Еще раз условия задачи - 2 ДЦ, только виртуалки.
Еще раз условия задачи - 2 ДЦ, только виртуалки.
DS
Как сделать лучше? Могу платить больше денег за более частые хелсчеки, ttl записи не уверен можно ли уменьшить еще, но предположим. Снизим 2 минуты до десятков секунд-1 минуты. А дальше?
Еще раз условия задачи - 2 ДЦ, только виртуалки.
Еще раз условия задачи - 2 ДЦ, только виртуалки.
а что за хостинг? Мб там можно взять айпишники, которые можно двигать между датацентрами? Но там тоже не быстро (около 60 секунд)
n🐈
днсом быстрее никак
AS
а что за хостинг? Мб там можно взять айпишники, которые можно двигать между датацентрами? Но там тоже не быстро (около 60 секунд)
нет, только внутри одного ДЦ можно
DS
У меня вот сейчас как раз второй вариант - всё на виртуалках, продублировано в двух ДЦ, а HA между ДЦ - только на хелсчеках и днс на Route53.
Продублировано полностью? То есть второй дц подключается только в случае отказа первого и там все уже готово принимать трафик? А с базами как поступаете? Может случиться такое. Что отказали только балансеры в первом ДЦ, но остальное все работает норм? Чек о недоступности балансера в первом дц сработал, трафик пошел на второй ДЦ. Но бэкенды во втором ДЦ идут в базу первого ДЦ, так как мастер во второй ДЦ не переехал. В итоге получили большой latency в запросах и возможно все упадет.
Задаю вопрос не целью прикопаться, а просто интересно как делаете.
Задаю вопрос не целью прикопаться, а просто интересно как делаете.
СХ
я там админ - и я тебя предупреждал - о том что надо поуважительней общение строить
а мне вообще выписал бан хотя я там только читал и 1 рах задал вопрос про стоимость
DS
Да странно что @yamlcoder где-то забанили. Адекватный человек, полезные советы дает
AS
Продублировано полностью? То есть второй дц подключается только в случае отказа первого и там все уже готово принимать трафик? А с базами как поступаете? Может случиться такое. Что отказали только балансеры в первом ДЦ, но остальное все работает норм? Чек о недоступности балансера в первом дц сработал, трафик пошел на второй ДЦ. Но бэкенды во втором ДЦ идут в базу первого ДЦ, так как мастер во второй ДЦ не переехал. В итоге получили большой latency в запросах и возможно все упадет.
Задаю вопрос не целью прикопаться, а просто интересно как делаете.
Задаю вопрос не целью прикопаться, а просто интересно как делаете.
Полностью, всё включая базы. Оба ДЦ работают постоянно одновременно, а не только задействуются при аварии. Но запас ресурсов позволяет работать без одного ДЦ.
DS
Полностью, всё включая базы. Оба ДЦ работают постоянно одновременно, а не только задействуются при аварии. Но запас ресурсов позволяет работать без одного ДЦ.
а в каком ДЦ мастер базы? Если мульти мастер, нет ли проблем из-за latency между ДЦ с мульти мастером?
СХ
Полностью, всё включая базы. Оба ДЦ работают постоянно одновременно, а не только задействуются при аварии. Но запас ресурсов позволяет работать без одного ДЦ.
red hat multi data center в гугл и полно инфы