[100matolog]

Заранее прошу просить за возможно высказанные глупости - в маршрутизации и все что связано с ней - я полный нуль.

 

1. Есть порядка 15 серверов разбросанных по разным ДЦ. Количество серверов увеличивается.

2. Все сервера держат один и тот же вебапликейшн

3. Клиенты попадают на апликейшн через Round robin DNS. То есть за одним доменом закреплено 15 айпи.

 

А теперь проблема - периодически один из ДЦ отваливается на n время. И получается что один из айпи который прописан в днс - не работает. И клиент по RRDns периодически попадает на неработающий айпи

 

Купили AS+PI.

Есть задачка, которая состоит в следующем:

можно ли при помощи AS разбросать адреса этой системы по всем серверам и при падении/недоступности одного из серверов , айпи недоступного сервера , стал бы активным на следующем по приоритету сервере. По типу CARP.

Был бы очень признателен если бы объяснили доходчиво и подробно.

Заранее благодарен.

Изменено 25 июля, 2011 пользователем 100matolog

[s.lobanov]

Теоретически есть такая штука http://en.wikipedia.org/wiki/Anycast , но лично я так и не знаю как решена проблема с tcp, если кто-нибудь используется ebgp multipath. Да и в любом случае, качество балансировки тут будет "как повезёт"

 

В вашем случае проще всего поставить TTL для dns-зоны 60 секунд и сделать костыль, который будет периодически опрашивать сервера и в случае, если какой-то недоступен, то быстренько удалять соответствующую запись на пару часиков(защита от флаппинга). Всё равно время сходимости bgp может быть значительно больше 60 секунд

[100matolog]

Теоретически есть такая штука http://en.wikipedia.org/wiki/Anycast , но лично я так и не знаю как решена проблема с tcp, если кто-нибудь используется ebgp multipath. Да и в любом случае, качество балансировки тут будет "как повезёт"

 

В вашем случае проще всего поставить TTL для dns-зоны 60 секунд и сделать костыль, который будет периодически опрашивать сервера и в случае, если какой-то недоступен, то быстренько удалять соответствующую запись на пару часиков(защита от флаппинга). Всё равно время сходимости bgp может быть значительно больше 60 секунд

 

Решение с маленьким TTL зоны - возможный выход. Но все таки - есть AS и как бы ее прикрутить к решению задачки?

[s.lobanov]

Какого размера у вас PI? Сколько всего ДЦ на эти 15 серверов?

[100matolog]

Какого размера у вас PI? Сколько всего ДЦ на эти 15 серверов?

/24, 4 ДЦ

Изменено 21 июня, 2011 пользователем 100matolog

[s.lobanov]

Ну вообщем-то с такой маленькой сеткой у вас два варианта:

1. делать ipv4 anycast. интересную презентацию на тему tcp over ipv4 anycast обязательно посмотрите: http://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf . Вариант плох тем, что равномерность балансировки будет намного хуже(большая часть запросов может уйти в один/два ДЦ) чем у вас сейчас, будет зависеть от географического расположения ваших клиентов и инструментов, чтобы повлиять на эту балансировку у вас будет минимум.

2. делать asbr(возможно, два) и балансер в виде reverse-proxy(nginx/squid/etc). вариант очень кривой + значительное увеличение времени отклика + затраты на сам asbr и его размещение

 

Если первый вариант всё же заинтересует, то могу описать чуть более подробно. О втором варианте даже не думайте, оно будет работать только "на бумаге"

 

Если бы было 4x/24(а лучше 4x/23) можно было бы из каждого ДЦ аннонсировать /24 + из какого-нибудь одного ещё аннонсировать /23 и ещё из одного всю /22. В этом случае будет и хорошая балансировка с помощью dns и резервирование в случае недоступности(с точки зрения bgp) одного из ДЦ. С ipv6 такую схему организовать было бы намного проще, там адресов можно больше захапать.

[100matolog]

Ну вообщем-то с такой маленькой сеткой у вас два варианта:

1. делать ipv4 anycast. интересную презентацию на тему tcp over ipv4 anycast обязательно посмотрите: http://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf . Вариант плох тем, что равномерность балансировки будет намного хуже(большая часть запросов может уйти в один/два ДЦ) чем у вас сейчас, будет зависеть от географического расположения ваших клиентов и инструментов, чтобы повлиять на эту балансировку у вас будет минимум.

2. делать asbr(возможно, два) и балансер в виде reverse-proxy(nginx/squid/etc). вариант очень кривой + значительное увеличение времени отклика + затраты на сам asbr и его размещение

 

Если первый вариант всё же заинтересует, то могу описать чуть более подробно. О втором варианте даже не думайте, оно будет работать только "на бумаге"

 

Если бы было 4x/24(а лучше 4x/23) можно было бы из каждого ДЦ аннонсировать /24 + из какого-нибудь одного ещё аннонсировать /23 и ещё из одного всю /22. В этом случае будет и хорошая балансировка с помощью dns и резервирование в случае недоступности(с точки зрения bgp) одного из ДЦ. С ipv6 такую схему организовать было бы намного проще, там адресов можно больше захапать.

 

Пожалуйста - опишите, если не сложно первый вариант.

[s.lobanov]

На примере 4ёх серверов и 2ух ДЦ это будет выглядеть так:

ваш PI 1.1.1.0/24

ваша AS - 4, у датацентров 2,3, в первом ДЦ сервера №1 и 2, во втором 3 и 4

на всех серверах поднимаете лупбэки: 1.1.1.1/32, 1.1.1.2/32

между каждым сервером и роутером ДЦ поднимаете ebgp (quagga/bird/openbgpd(только bsd))

c серверов 1 и 3 аннонсируете 1.1.1.1/32 без препендов, 1.1.1.2/32 с одним препендом

с серверов 2 и 4 ровно наооборот: 1.1.1.1/32 с препендом, 1.1.1.2/32 без

каждый ДЦ аннонсирует своим аплинкам 1.1.1.0/24. В dns прописываете две A-записи 1.1.1.1 и 1.1.1.2.

Таким образом получается балансировка между ДЦ и резервирование серверов внутри одного ДЦ

[100matolog]

На примере 4ёх серверов и 2ух ДЦ это будет выглядеть так:

ваш PI 1.1.1.0/24

ваша AS - 4, у датацентров 2,3, в первом ДЦ сервера №1 и 2, во втором 3 и 4

на всех серверах поднимаете лупбэки: 1.1.1.1/32, 1.1.1.2/32

между каждым сервером и роутером ДЦ поднимаете ebgp (quagga/bird/openbgpd(только bsd))

c серверов 1 и 3 аннонсируете 1.1.1.1/32 без препендов, 1.1.1.2/32 с одним препендом

с серверов 2 и 4 ровно наооборот: 1.1.1.1/32 с препендом, 1.1.1.2/32 без

каждый ДЦ аннонсирует своим аплинкам 1.1.1.0/24. В dns прописываете две A-записи 1.1.1.1 и 1.1.1.2.

Таким образом получается балансировка между ДЦ и резервирование серверов внутри одного ДЦ

Что такое "поднимаете лупбэки" и что такое "без препендов" и "с препендом" ?

[s.lobanov]

http://wiki.networksecuritytoolkit.org/nstwiki/index.php/Dummy_Interface - лупбэки

http://ciscodreamer.blogspot.com/2009/07/bgp-as-path-prepending.html - препенды

[anad]

Э, вопрос наверное глупый, но..

А что мешает аносить целиком всю сеть через каждый из ДЦ? придется много играться с препендами, чтобы нагрузку ровнять, а так - изменение маршрута в процессе сесии - IMHO маловероятно, куда идти решает BGP роутер со стороны клиента. Есть проблема связаности между серверами в ДЦ, но это либо тоннели наружу, либо запросить у провайдера второй хвост и висеть на ip не из своей PI.

Вся зависит от кого кто сеть аносит ( Ваш серерер себя же, ваш роутер, или Ваш провайдер - если провайдер то игры с препендами могут оказаться очень долгими)

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

P.S. я совсем не уверен что /32 не потрут препенды апстримы. ( никогда не пробовал что - нибудь делать по BGP с сетями менее /24 ну кроме как блэкхолить у апстрима)

Изменено 23 июня, 2011 пользователем anad

[100matolog]

Э, вопрос наверное глупый, но..

А что мешает аносить целиком всю сеть через каждый из ДЦ? придется много играться с препендами, чтобы нагрузку ровнять, а так - изменение маршрута в процессе сесии - IMHO маловероятно, куда идти решает BGP роутер со стороны клиента. Есть проблема связаности между серверами в ДЦ, но это либо тоннели наружу, либо запросить у провайдера второй хвост и висеть на ip не из своей PI.

Вся зависит от кого кто сеть аносит ( Ваш серерер себя же, ваш роутер, или Ваш провайдер - если провайдер то игры с препендами могут оказаться очень долгими)

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

P.S. я совсем не уверен что /32 не потрут препенды апстримы. ( никогда не пробовал что - нибудь делать по BGP с сетями менее /24 ну кроме как блэкхолить у апстрима)

ничего не понял ))

[breusovok]

P.S. я совсем не уверен что /32 не потрут препенды апстримы. ( никогда не пробовал что - нибудь делать по BGP с сетями менее /24 ну кроме как блэкхолить у апстрима)

Анонс Сетей меньше чем 256 адресов очень часто дропается вышестоящим провайдером по причине того, что память на маршрутизаторах не резиновая, и помнить все маршруты очень сложно!

[anad]

ничего не понял ))

Коротко - в каждом ДЦ делаете вид ( анонс BGP) что ВСЕ ваши сервера стоят только в этом ДЦ, дальше для тех серверов которые слишком хорошо доступны удлиняете маршрут к ним. Сложность процесса - либо само ставить/арендовать роутер в каждом ДЦ, либо долго договариваться с провайдерами, потому что делать равные длины маршрутов по BGP - работа довольно муторная (не сложно, но долго), если все еще не понимаете - не знаю как проще объяснить ( мне лень рисовать картинки)

Про анонс одного адреса - попробовал - из моих 6 апстримов 4 - ро откусили такое безобразие. Так что идея удлинять маршрут для одиночного определенного сервера боюсь не прокатит.