Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Оригинально! В закладки!
IP SLA на маршрутизаторах Cisco позволяет проводить мониторинг также по HTTP GET запросам, что поможет определить падение веб-сервера не только по его отсутствию в сети, но и при нерабочем состоянии веб сервиса.
Ок, так почему же в итоге было сделано через ICMP?
А вообще такая схема гораздо удобнее реализуется через Anycast как мне кажется. Немного сложнее т.к. требует поднятия OSPF или BGP, но работает более гибко. Можно реализовать разные healthcheck локально и приостанавливать анонс адреса на роутер в случае проблем.
В принципе можно это делать и в вашей топологии, но придется например дропать пинги или класть интерфейс.
У автора в сети может не быть никаких протоколов вообще судя по топологии, а вы v4anycast предлагаете :)
Было сделано через ICMP потому, что план был реализован на Cisco ASA. Функционал IP Sla не позволял использовать HTTP GET, в отличие от маршрутизаторов Cisco.
Когда говорят Anycast, я представляю IPv6, что не есть тоже самое. По поводу простоты healthcheck, интересно какие процедуры применяются для этого?
Дропать пинги и класть интерфейс — один из вариантов, но самый простой — удалить роут из маршрутизатора.
Когда говорят Anycast, я представляю IPv6, что не есть тоже самое. По поводу простоты healthcheck, интересно какие процедуры применяются для этого?
Дропать пинги и класть интерфейс — один из вариантов, но самый простой — удалить роут из маршрутизатора.
Получается, ваши сервисы уже кластеризованы, раз вам не требуется persistence на вашем самодельном «балансировщике».
Не совсем понял про persistence, если можете киньте ссылку для ознокомления.
По поводу кластеризации:
1) Реализована синхронизация баз данных.
2) Реализована синхронизация необходимых директорий, при помощи средств ОС.
По поводу кластеризации:
1) Реализована синхронизация баз данных.
2) Реализована синхронизация необходимых директорий, при помощи средств ОС.
Понял, согласен. А есть такие балансировщики с такими функционалом? Не имею ввиду кластеризацию, например, на уровне ОС или виртуальных машин.
Из опенсорса навскидку — HAproxy, nginx. Seesaw я бы попробовал тоже.
(добавлено) прочитал, что есть что-то виртуальное от KEMP. Если это бесплатно или условно-бесплатно, обязательно попробуйте. Это коммерчески успешный продукт.
(добавлено) прочитал, что есть что-то виртуальное от KEMP. Если это бесплатно или условно-бесплатно, обязательно попробуйте. Это коммерчески успешный продукт.
В силу простоты веб сервера, необходимости в persistence не было. Но не знал о данном функционале у HAproxy. Надо будет поднять в лабораторных условиях поднять.
Про Kemp.
Далее идет огромный рекламный булшит.
Имеется бесплатная версия с порезанным функционалом.
Имеется полноценная демо-версия с триальной лицензией на 30 дней, можно до 45 дней тестировать.
Если покупать: Все как у белых производителей. Виртуалки на 1G/3G/5G/10G/ обычные коробки, лицензии на ажур/амазон, лицензии к cisco ucs и baremetal.
С позволения сообщества на правах рекламы.
Получить триалку или узнать сколько стоит kemp можно постучавшись ко мне в личку.
Представляю Kemp в России и СНГ.
Далее идет огромный рекламный булшит.
Имеется бесплатная версия с порезанным функционалом.
Имеется полноценная демо-версия с триальной лицензией на 30 дней, можно до 45 дней тестировать.
Если покупать: Все как у белых производителей. Виртуалки на 1G/3G/5G/10G/ обычные коробки, лицензии на ажур/амазон, лицензии к cisco ucs и baremetal.
С позволения сообщества на правах рекламы.
Получить триалку или узнать сколько стоит kemp можно постучавшись ко мне в личку.
Представляю Kemp в России и СНГ.
Так это же самы обычный ECMP, будет работать на большинстве вендоров. Ну и как хорошо выше заметили, лучше поднять между серверами (quagga, exabgp, gobgp, ...) и роутером BGP и анонсировать виртуальный ip с серверов, вместо статики. Таким образом админы серверов смогут сами спокойна, когда надо, выодить сервера из кластера и заводить назад, не залазия на сетевое оборудования или не пиная сетевого админа
Если разбирать схему с динамическими протоколами, то в качестве плюса у нас — это то, что админ веб-сервера может выводить сам из строя сервер. В качестве минуса — сложность схемы, учитывая также и использование дополнительных ресурсов.
В схеме, указанной выше, тоже можно выводить сервер из строя на стороне сервера, добавляю одну строчку в iptables. Минусы от BGP понятные, плюс же не самый явный.
В схеме, указанной выше, тоже можно выводить сервер из строя на стороне сервера, добавляю одну строчку в iptables. Минусы от BGP понятные, плюс же не самый явный.
Уточните какие минусы есть у BGP или любого протокола динамической маршрутизации относительно статических маршрутов? Кстати да, ECMP умеет не только статика или BGP, а в принципе любой современный протокол.
Минус для данной схемы у BGP в том, что схема сложнее, требует больше ресурсов, постоянный обмен сообщений, взамен каких-либо плюсов относительно статики нет. Значит, чем проще, тем лучше.Также, учитывая гибкость ip sla, можно мониторить состояние веб сервиса, что, в случае, bgp не приходит в голову как сделать.
IP SLA тоже потребляет ресурсы и еще не факт что будет потреблять меньше ресурсов чем два BGP соседа с одним префиксом каждый. Если привести конкретно цифры, то 1 маршрут в BGP таблице занимает 120 байт памяти (в реализации Cisco по крайней мере). Что касательно нагрузки на процессор — если ничего в сети не меняется, то и обновлений таблиц не происходит, так что нагрузка будет только на поддержание ТСР соединения, что тоже не факт что будет потреблять ресурсов больше чем пинги в вашей конфигурации IP SLA.
Плюсы относительно статики — легко масштабировать, например если понадобится добавить еще несколько адресов для балансировки, или несколько сотен адресов — вы будете это всё вколачивать статикой? Мониторить состояние сервиса с сетевой железки — такое себе решение, для этого существуют системы мониторинга, а задача сетевого оборудования побыстрее передавать пакеты из одного порта в другой. Ничего не мешает мониторить состояние сервиса чем угодно и по результату HTTP GET того же можно очень разными способами снимать анонс адреса с хоста где крутится сервис.
Плюсы относительно статики — легко масштабировать, например если понадобится добавить еще несколько адресов для балансировки, или несколько сотен адресов — вы будете это всё вколачивать статикой? Мониторить состояние сервиса с сетевой железки — такое себе решение, для этого существуют системы мониторинга, а задача сетевого оборудования побыстрее передавать пакеты из одного порта в другой. Ничего не мешает мониторить состояние сервиса чем угодно и по результату HTTP GET того же можно очень разными способами снимать анонс адреса с хоста где крутится сервис.
Если для сотни серверов руками поднимаете BGP сессии, то прописать маршрут не составит труда. Правда не знаю сколько требует ресурсов сервис и процессы BGP, но что-то да нужно. У статики это — место для в памяти для маршрута и пару сообщений каждые 10 секунж. Посмотрите плюсы статической маршрутизации перед динамической. Там несколько пунктов. Например, безопасность.
Я имел ввиду мониторить с сетевой железки для определение актуальности таблицы маршрутизации, а не в целом мониторить систему только с сетевой железки.
Я имел ввиду мониторить с сетевой железки для определение актуальности таблицы маршрутизации, а не в целом мониторить систему только с сетевой железки.
Прочитайте внимательно комментарий — я писал про пару сотен адресов, а не про пару сотен серверов. Также в первом комментарии была фраза «у BGP или любого протокола динамической маршрутизации» — так вот OSPF включается двумя строчками для минимальной конфигурации — руками соседей настраивать не нужно, да и рисовать BGP соседей руками тоже никто не заставляет — есть масса способов автоматизации процесса.
> У статики это — место для в памяти для маршрута и пару сообщений каждые 10 секунж.
Я о чем и пишу выше — у BGP также.
Безопасность статики? Вы серьезно? В каком месте там есть такая базовая вещь безопасности как аутентификация? Вот в протоколах динамической маршрутизации например есть аутентификация соседа в полный рост. Вобщем не увидел ни одного плюса статики пока. Единственный вариант для чего она может быть полезна в современных сетях, тем более с заявкой на продакшен, хайлоад, фолт-толеранс и т.п. — это backup route на случай аварийного режима работы.
> У статики это — место для в памяти для маршрута и пару сообщений каждые 10 секунж.
Я о чем и пишу выше — у BGP также.
Безопасность статики? Вы серьезно? В каком месте там есть такая базовая вещь безопасности как аутентификация? Вот в протоколах динамической маршрутизации например есть аутентификация соседа в полный рост. Вобщем не увидел ни одного плюса статики пока. Единственный вариант для чего она может быть полезна в современных сетях, тем более с заявкой на продакшен, хайлоад, фолт-толеранс и т.п. — это backup route на случай аварийного режима работы.
Интересно, конечно, где требуется сотни адресов на одном серверов?
BGP или OSPF — это отельный дополнительный сервис, который требуется поднимать. Статика это не требует.
Аутентификация на статике?? Это, Вы серьезно? Как раз в этом и заключается безопасность) Просто оставлю ссылку.
BGP или OSPF — это отельный дополнительный сервис, который требуется поднимать. Статика это не требует.
Аутентификация на статике?? Это, Вы серьезно? Как раз в этом и заключается безопасность) Просто оставлю ссылку.
Сотни адресов требуются например на баланисровщиках нагрузки, когда на одном балансере крутятся тысячи сервисов (не обязательно HTTP), бывает по разным причинам нужно выделять некоторым сервисам разные адреса. То что вам не нужен балансер — рад за вас, если не понадобится в будущем еще болше рад. Моя цель не доказать вам что ваше решение неработоспособно, а доказть то что оно немасштабируемо. По приведенной ссылке ровно об этом и говорится.
Например — у вас всего один маршрутизатор и два сервера. А если для отказоустойчивости понадобится несколько маршрутизаторов, раскиданных по разным цодам и с десяток балансеров/фронтов — вы тоже будете на всем этом статику делать?
Например — у вас всего один маршрутизатор и два сервера. А если для отказоустойчивости понадобится несколько маршрутизаторов, раскиданных по разным цодам и с десяток балансеров/фронтов — вы тоже будете на всем этом статику делать?
Я предположил, что вы используете статику исключительно в силу простоты вашей конструкции.
Если вы используете «безопасность статики» как аргумент, вы делаете маршрутизацию неверно. В любом случае, пока у вас 1 аплинк по одному каналу, маршрутизация вам не нужна; заниматься ею искуственно ради неё самой не стоит.
Если вы используете «безопасность статики» как аргумент, вы делаете маршрутизацию неверно. В любом случае, пока у вас 1 аплинк по одному каналу, маршрутизация вам не нужна; заниматься ею искуственно ради неё самой не стоит.
Anycast — это больше про балансировку географически разнесенных ресурсов. Принцип работы основан на приоритете короткого маршрута в протоколе bgp. Как с помощью anycast резервировать ресурсы на одной площадке не совсем понятно.
Добавлю, что с помощью описанного метода можно балансировать не только сервера, но и любой трафик. Например, равнозначные по пропускной способности каналы передачи данных.
> Принцип работы основан на приоритете короткого маршрута в протоколе bgp.
«короткого» — видимо тут имеется в виду атрибут BGP AS-PATH, хотя он далеко не единственный и даже не первый в алгоритме выбора лучшего маршрута. А еще BGP не обязан выбирать только один лучший маршрут, а может выбрать их два, три, четыре и больше — и все они будут с одинаковыми «длинами» и прочими атрибутами кроме next-hop, что приведет к балансировке.
> Как с помощью anycast резервировать ресурсы на одной площадке не совсем понятно.
Легко и просто, абсолютно никакой разницы находятся ресурсы в пределах одной стойки или разнесены по разным континентам.
Более того если использовать EIGRP то можно добиться неравномерного распределения трафика подкручивая метрики.
«короткого» — видимо тут имеется в виду атрибут BGP AS-PATH, хотя он далеко не единственный и даже не первый в алгоритме выбора лучшего маршрута. А еще BGP не обязан выбирать только один лучший маршрут, а может выбрать их два, три, четыре и больше — и все они будут с одинаковыми «длинами» и прочими атрибутами кроме next-hop, что приведет к балансировке.
> Как с помощью anycast резервировать ресурсы на одной площадке не совсем понятно.
Легко и просто, абсолютно никакой разницы находятся ресурсы в пределах одной стойки или разнесены по разным континентам.
Более того если использовать EIGRP то можно добиться неравномерного распределения трафика подкручивая метрики.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Балансировка трафика между Web-серверами при помощи IP CEF на сетевом оборудовании