100matolog Опубликовано 21 июня, 2011 (изменено) · Жалоба Заранее прошу просить за возможно высказанные глупости - в маршрутизации и все что связано с ней - я полный нуль. 1. Есть порядка 15 серверов разбросанных по разным ДЦ. Количество серверов увеличивается. 2. Все сервера держат один и тот же вебапликейшн 3. Клиенты попадают на апликейшн через Round robin DNS. То есть за одним доменом закреплено 15 айпи. А теперь проблема - периодически один из ДЦ отваливается на n время. И получается что один из айпи который прописан в днс - не работает. И клиент по RRDns периодически попадает на неработающий айпи Купили AS+PI. Есть задачка, которая состоит в следующем: можно ли при помощи AS разбросать адреса этой системы по всем серверам и при падении/недоступности одного из серверов , айпи недоступного сервера , стал бы активным на следующем по приоритету сервере. По типу CARP. Был бы очень признателен если бы объяснили доходчиво и подробно. Заранее благодарен. Изменено 25 июля, 2011 пользователем 100matolog Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 21 июня, 2011 · Жалоба Теоретически есть такая штука http://en.wikipedia.org/wiki/Anycast , но лично я так и не знаю как решена проблема с tcp, если кто-нибудь используется ebgp multipath. Да и в любом случае, качество балансировки тут будет "как повезёт" В вашем случае проще всего поставить TTL для dns-зоны 60 секунд и сделать костыль, который будет периодически опрашивать сервера и в случае, если какой-то недоступен, то быстренько удалять соответствующую запись на пару часиков(защита от флаппинга). Всё равно время сходимости bgp может быть значительно больше 60 секунд Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
100matolog Опубликовано 21 июня, 2011 · Жалоба Теоретически есть такая штука http://en.wikipedia.org/wiki/Anycast , но лично я так и не знаю как решена проблема с tcp, если кто-нибудь используется ebgp multipath. Да и в любом случае, качество балансировки тут будет "как повезёт" В вашем случае проще всего поставить TTL для dns-зоны 60 секунд и сделать костыль, который будет периодически опрашивать сервера и в случае, если какой-то недоступен, то быстренько удалять соответствующую запись на пару часиков(защита от флаппинга). Всё равно время сходимости bgp может быть значительно больше 60 секунд Решение с маленьким TTL зоны - возможный выход. Но все таки - есть AS и как бы ее прикрутить к решению задачки? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 21 июня, 2011 · Жалоба Какого размера у вас PI? Сколько всего ДЦ на эти 15 серверов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
100matolog Опубликовано 21 июня, 2011 (изменено) · Жалоба Какого размера у вас PI? Сколько всего ДЦ на эти 15 серверов? /24, 4 ДЦ Изменено 21 июня, 2011 пользователем 100matolog Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 21 июня, 2011 · Жалоба Ну вообщем-то с такой маленькой сеткой у вас два варианта: 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 такую схему организовать было бы намного проще, там адресов можно больше захапать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
100matolog Опубликовано 21 июня, 2011 · Жалоба Ну вообщем-то с такой маленькой сеткой у вас два варианта: 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 такую схему организовать было бы намного проще, там адресов можно больше захапать. Пожалуйста - опишите, если не сложно первый вариант. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 21 июня, 2011 · Жалоба На примере 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. Таким образом получается балансировка между ДЦ и резервирование серверов внутри одного ДЦ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
100matolog Опубликовано 22 июня, 2011 · Жалоба На примере 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. Таким образом получается балансировка между ДЦ и резервирование серверов внутри одного ДЦ Что такое "поднимаете лупбэки" и что такое "без препендов" и "с препендом" ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 22 июня, 2011 · Жалоба http://wiki.networksecuritytoolkit.org/nstwiki/index.php/Dummy_Interface - лупбэки http://ciscodreamer.blogspot.com/2009/07/bgp-as-path-prepending.html - препенды Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
anad Опубликовано 23 июня, 2011 (изменено) · Жалоба Э, вопрос наверное глупый, но.. А что мешает аносить целиком всю сеть через каждый из ДЦ? придется много играться с препендами, чтобы нагрузку ровнять, а так - изменение маршрута в процессе сесии - IMHO маловероятно, куда идти решает BGP роутер со стороны клиента. Есть проблема связаности между серверами в ДЦ, но это либо тоннели наружу, либо запросить у провайдера второй хвост и висеть на ip не из своей PI. Вся зависит от кого кто сеть аносит ( Ваш серерер себя же, ваш роутер, или Ваш провайдер - если провайдер то игры с препендами могут оказаться очень долгими) В схеме будет проблема с тем, что при падении маршрута все кто шел по нему таки пойдут новым ( остальные сервера получат куски сессий о которых ничего не знают) но новые соединения пойдут правильно. P.S. я совсем не уверен что /32 не потрут препенды апстримы. ( никогда не пробовал что - нибудь делать по BGP с сетями менее /24 ну кроме как блэкхолить у апстрима) Изменено 23 июня, 2011 пользователем anad Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
100matolog Опубликовано 24 июня, 2011 · Жалоба Э, вопрос наверное глупый, но.. А что мешает аносить целиком всю сеть через каждый из ДЦ? придется много играться с препендами, чтобы нагрузку ровнять, а так - изменение маршрута в процессе сесии - IMHO маловероятно, куда идти решает BGP роутер со стороны клиента. Есть проблема связаности между серверами в ДЦ, но это либо тоннели наружу, либо запросить у провайдера второй хвост и висеть на ip не из своей PI. Вся зависит от кого кто сеть аносит ( Ваш серерер себя же, ваш роутер, или Ваш провайдер - если провайдер то игры с препендами могут оказаться очень долгими) В схеме будет проблема с тем, что при падении маршрута все кто шел по нему таки пойдут новым ( остальные сервера получат куски сессий о которых ничего не знают) но новые соединения пойдут правильно. P.S. я совсем не уверен что /32 не потрут препенды апстримы. ( никогда не пробовал что - нибудь делать по BGP с сетями менее /24 ну кроме как блэкхолить у апстрима) ничего не понял )) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
breusovok Опубликовано 26 июня, 2011 · Жалоба P.S. я совсем не уверен что /32 не потрут препенды апстримы. ( никогда не пробовал что - нибудь делать по BGP с сетями менее /24 ну кроме как блэкхолить у апстрима) Анонс Сетей меньше чем 256 адресов очень часто дропается вышестоящим провайдером по причине того, что память на маршрутизаторах не резиновая, и помнить все маршруты очень сложно! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
anad Опубликовано 26 июня, 2011 · Жалоба ничего не понял )) Коротко - в каждом ДЦ делаете вид ( анонс BGP) что ВСЕ ваши сервера стоят только в этом ДЦ, дальше для тех серверов которые слишком хорошо доступны удлиняете маршрут к ним. Сложность процесса - либо само ставить/арендовать роутер в каждом ДЦ, либо долго договариваться с провайдерами, потому что делать равные длины маршрутов по BGP - работа довольно муторная (не сложно, но долго), если все еще не понимаете - не знаю как проще объяснить ( мне лень рисовать картинки) Про анонс одного адреса - попробовал - из моих 6 апстримов 4 - ро откусили такое безобразие. Так что идея удлинять маршрут для одиночного определенного сервера боюсь не прокатит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...