Комментарии 5
Wow!
Спасибо большое за эту статью!
А вы не пробовали переллельно работать на двух ДЦ, active-active?
Спасибо большое за эту статью!
А вы не пробовали переллельно работать на двух ДЦ, active-active?
Из текста это не очевидно, но так и есть, оба DC работают active-active.
На точках входа вкратце это выглядит так:
— VIP, конечно же, не один; в конфигурации 2DC мы делаем две группы адресов. Для первой группы адресов primary_DC = DC1, backup_DC = DC2, для второй — наоборот.
— Capacity management каждого DC подразумевает что нагрузка может прийти из соседнего
— Переключение нагрузки между дата-центрами описывает один VIP, но в реальности в backup DC (справа на диаграммах) есть такой же, для которого primary — DC2
В telephony core active-active достигается другими средствами, но это совершенно другая история :)
На точках входа вкратце это выглядит так:
— VIP, конечно же, не один; в конфигурации 2DC мы делаем две группы адресов. Для первой группы адресов primary_DC = DC1, backup_DC = DC2, для второй — наоборот.
— Capacity management каждого DC подразумевает что нагрузка может прийти из соседнего
— Переключение нагрузки между дата-центрами описывает один VIP, но в реальности в backup DC (справа на диаграммах) есть такой же, для которого primary — DC2
В telephony core active-active достигается другими средствами, но это совершенно другая история :)
копирование мультикаста с помощью tee и ipip тунелей, а так же обслуживание увеличивающегося с каждым новым членом lvs кластера неужели проще, чем поднять роутинг мульитикаста между дата центрами?
Привет, Дима :)
Организационно и по требованиям к инфраструктуре — да, вышло проще/быстрее.
> увеличивающегося с каждым новым членом lvs кластера
LVS-кластер fixed-size (в отличие от кол-ва бэкендов под ним). Мы не скейлим его бесконечно, поднимаем новую копию с заданным capacity. Такой подход выглядит более предсказуемым.
Организационно и по требованиям к инфраструктуре — да, вышло проще/быстрее.
> увеличивающегося с каждым новым членом lvs кластера
LVS-кластер fixed-size (в отличие от кол-ва бэкендов под ним). Мы не скейлим его бесконечно, поднимаем новую копию с заданным capacity. Такой подход выглядит более предсказуемым.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Отказоустойчивая балансировка VoIP-трафика. Переключение нагрузки между дата-центрами в пик-тайм