Комментарии 40
Нужная статья, обязательно пригодится. Давно на Хабре с такой тематикой статей не было, с удовольствием почитал, спасибо.
Для fail-over есть ещё ucarp — его не рассматривали как oss-альтернативу?
Рассматривал, но отпугнула немного большая сложность настройки да пара сообщений на форумах о немного кривом портировании под Linux (ucarp это ведь из Free- и NetBSD, если мне память не изменяет). Но если с VRRP не получилось бы — пришлось с UCARP разбираться.
А LVS не кошернее было бы?
Проблема только одна может возникнуть — если клиентам до этого выдавались /30 сетки. Для vrrp (и hsrp у cisco) сетка должна быть минимум /29. Хотя, vrrp «экономит» один адрес, в отличие от hsrp.
про то что ucarp немного кривой я тоже слышал, но на своем опыте могу сказать что работает нормально. На данный момент у меня в кластере работают два сервера пока не жалуюсь
Использую его для своих серверов телефонной тематики, правда у меня допиленная версия, работает на паре с monit, monit смотрит если сервер получил статус Мастер, если да то запускает все сервисы. Ну о приоритетах и броадкасте я думаю вы уже знаете. А, ещё есть интерфейс от опенсипса где можно это дело контролить:
У меня были проблемы с убунту и старт скриптами по началу, а в дебиане работает. Если заинтересует то гуглите opensips opensips-cp
У меня были проблемы с убунту и старт скриптами по началу, а в дебиане работает. Если заинтересует то гуглите opensips opensips-cp
А у клиентов обрываются соединения, потому что все сидят за NAT?
Если клиентам раздавать белые адреса, никаких обрывов при переключении маршрутизатора быть не должно.
Но раз у вас оба сервера мастеры в своих вланах, то полагаю что у них разные белые адреса, а у всех клиентов — серые.
А как у вас резервируется DHCP?
Если клиентам раздавать белые адреса, никаких обрывов при переключении маршрутизатора быть не должно.
Но раз у вас оба сервера мастеры в своих вланах, то полагаю что у них разные белые адреса, а у всех клиентов — серые.
А как у вас резервируется DHCP?
Те соединения которые обрываются, я имел ввиду TCP-сессии и т.п., состояние которых можно увидеть в /proc/net/ip_conntrack. Естестевенно состояние TCP-сессии не синхронизируется между серверами и при переключении на резерв новые TCP-сессии открываются уже на другом сервере. Это касается и белых сетей, ведь к переключению MASTER-BACKUP добавляется перестройка OSPF и маршрутизации. Мне сложно представить как сделать сохранение состояния TCP-сессии в таком случае. Да и нужно ли оно?
Белые сети реальзованы похожим образом: интерфейс одной белой сети MASTER на одном сервере, интерфейс второй белой подсети — MASTER на другом сервере. Пока сетей только две, реализовано так, но я не вижу никаких проблем при наращивании их количества.
DHCP пока никак не резервируется, планирую заняться этим в ближайшее время. В ISC DHCP это стандартный функционал, ничего городить не требуется.
Белые сети реальзованы похожим образом: интерфейс одной белой сети MASTER на одном сервере, интерфейс второй белой подсети — MASTER на другом сервере. Пока сетей только две, реализовано так, но я не вижу никаких проблем при наращивании их количества.
DHCP пока никак не резервируется, планирую заняться этим в ближайшее время. В ISC DHCP это стандартный функционал, ничего городить не требуется.
да, я и имел ввиду, что городить DHCP на VRRP было бы странно, но интересно, какие могут возникнуть проблемы.
Для клиентов с белыми адресами вообще не нужно использовать ip_conntrack, информация о соединении хранится только на клиенте и сервере, а как сегменты идут через промежуточные хосты им безразлично (изменение маршрута они не замечают).
Для клиентов с белыми адресами вообще не нужно использовать ip_conntrack, информация о соединении хранится только на клиенте и сервере, а как сегменты идут через промежуточные хосты им безразлично (изменение маршрута они не замечают).
У клиентов с белым IP ничего рваться не должно.
Сколько у вас занимает времени перестройка OSPF маршрутов? Если выставить низкие значения таймеров (на небольшой сети это вполне допустимо), то для клиента переключение на резервный сервер будет выглядеть как небольшой лаг и всё.
Кстати, VRRP позволяет (не знаю как в Linux'е, скорее всего тоже) иметь не только виртуальный IP, но ещё и виртуальный MAC и переносить его вместе с IP адресом. В этом случае время переключения = времени обновления MAC таблицы на свиче и спокойно может быть меньше секунды.
p.s. Ну и напоследок — а не думали ли вы над тем, чтобы полностью отказаться от линуксового сервера в маршрутизационном ядре? VLAN'ы сейчас можно терминировать на массе относительно недорогого оборудования.
Сколько у вас занимает времени перестройка OSPF маршрутов? Если выставить низкие значения таймеров (на небольшой сети это вполне допустимо), то для клиента переключение на резервный сервер будет выглядеть как небольшой лаг и всё.
Кстати, VRRP позволяет (не знаю как в Linux'е, скорее всего тоже) иметь не только виртуальный IP, но ещё и виртуальный MAC и переносить его вместе с IP адресом. В этом случае время переключения = времени обновления MAC таблицы на свиче и спокойно может быть меньше секунды.
p.s. Ну и напоследок — а не думали ли вы над тем, чтобы полностью отказаться от линуксового сервера в маршрутизационном ядре? VLAN'ы сейчас можно терминировать на массе относительно недорогого оборудования.
Скорее всего, у автора на тех же серверах реализуется ещё и traffic shaping, и NAT. Собственно вынос только терминации vlan в общей схеме ничего не упрощает.
это один из пунктов того, что нужно сделать. а так же разделить нат и шейпинг, тогда куда проще внедрять резервные сервера в случае ухода какого-либо узла на тех. обслуживание. Даунтайм можно свести до пары секунд, никто ничего и не заметит.
Всё разделять не всегда верно. Конечно всё зависит нагрузки, денег и желания. Но в бюджетном варианте совмещение shaping + терминация VLAN считаю вполне разумным. Первый кандидат на вынос, конечно, NAT.
в бюджетном варианте предлагаете и биллинг с бд держать на маршрутизаторе? l3 коммутаторы меняются очень быстро и просто в отличии от серваков(всего-то залить конфиг нужно на железку), обновление прошивки проходит куда быстрее, чем обновление ПО на линукс-роутере(например поднять пару тысяч вланов с интерфейсами нормальный коммутатор сможет за несколько секунд, когда как во многих дистрибутивах линукса это будет производиться минут эдак 30-50), да и производительность их на много порядков выше в плане передачи данных.
Биллинг с БД, вообще то, не трогали. Конечно, под это свой сервак.
Всего-то залить конфиг/прошивку — не аргумент. Посмотрите в сторону vyatta, например.
А вот скорость поднятия VLAN интерфейсов — это аргумент. Указанные цифры на практике видели или это предположение?
И про производительность. L3 switch обычно может 10-тки Гбит/сек. Однако если сеть — сотни абоннентов и десяток другой свичей, то зачем стрелять из пушки по воробъям. На агрегации хватит 1-2 Гбит производительности.
К тому же узким местом будет shaping и/или NAT. Так что мощь L3 switch будет не задействована.
Всего-то залить конфиг/прошивку — не аргумент. Посмотрите в сторону vyatta, например.
А вот скорость поднятия VLAN интерфейсов — это аргумент. Указанные цифры на практике видели или это предположение?
И про производительность. L3 switch обычно может 10-тки Гбит/сек. Однако если сеть — сотни абоннентов и десяток другой свичей, то зачем стрелять из пушки по воробъям. На агрегации хватит 1-2 Гбит производительности.
К тому же узким местом будет shaping и/или NAT. Так что мощь L3 switch будет не задействована.
я строил сети на 18 тысяч пользователей, я знаю о чем говорю. Помимо юникст траффика, который уходит в интернет, можно задействовать iptv, тогда уже нагрузка на агрегаторы будет выше. Узким место shaping и/или NAT будет, если на этом сэкономить — вот если поставить железку за миллион рублей(семитонник или ASR от циски, ну или джунипер аналогичный), то все будет ок.
Нормальные железки это лучшее решение безусловно. Сам работаю в достаточно крупном провайдере. И настраивал Cisco 4948, 3750G, ASR/ISG, SCE трогал и ещё и ещё. И всё ок. Терминировать и шейпить одно удовольствие.
Интересно что делать провайдерам, которые не могут себе позволить портратить по 1млн руб на NAT, shaping и L3 switch.
Кстати потестил ту же vyatta с 1Гбит/сек Intel сетевухой. 500 vlan подинтерфейсов поднимаются минуту или две. Однако еще больше создать не удалось, ошибка выделения памяти.
На этом предлагаю закончить, т.к. оффтоп…
Интересно что делать провайдерам, которые не могут себе позволить портратить по 1млн руб на NAT, shaping и L3 switch.
Кстати потестил ту же vyatta с 1Гбит/сек Intel сетевухой. 500 vlan подинтерфейсов поднимаются минуту или две. Однако еще больше создать не удалось, ошибка выделения памяти.
На этом предлагаю закончить, т.к. оффтоп…
Самый главный аргумент — коммутация пакетов на L3 свиче выполняется не на центральном процессоре, как у Линукс-роутере, а обрабатывается на ASIC-схемах. Это позволяет добиться скорости, равной обычной L2 коммутации, при условии задействования технологий CEF или route cache.
Сколько у вас занимает времени перестройка OSPF маршрутов?
А вот время перестройки OSPF я не мерил, но т.к. хостов мало перестройка идет очень быстро, т.к. при тестировании не заметил, что произошло переключение на другой сервер, а маршруты еще не перестроились.
Кстати, VRRP позволяет (не знаю как в Linux'е, скорее всего тоже) иметь не только виртуальный IP, но ещё и виртуальный MAC
Появляющийся MAC виртуального интерфейса 00:00:5E:00:01:xx, вы это имели ввиду?
не думали ли вы над тем, чтобы полностью отказаться от линуксового сервера в маршрутизационном ядре?
Это не ядро. В ядре стоит железячный маршрутизатор. А это одни из серверов доступа.
И, как правильно заметил товарищ umraf, там еще реализован NAT и shape.
В больших инсталляциях самый большой косяк — в максимальном количестве VRRP-групп. Потребность в этом хозяйстве изначально возникла для нужд энтерпрайза, поэтому такое ограничение вполне объяснимо. Ну и для небольшого провайдера, конечно, оно отлично работает.
Во первых вам нужно отказаться от линукс-роутеров — это тупик. Ставить надо какие-нибудь l3-коммутаторы, например dlink dgs-3627 или если у вас около тысячи вланов и больше — то allied telesyn присмотреть. Да это дороже, чем использовать писюшники, но они куда имеют более высокую производительность на несколько порядков.
Во вторых по возможности отказаться от серых ip-адресов, можете даже рассмотреть вариант с ipv6, тогда вы сможете отказаться от NAT/PAT. Если же нет, то NAT выполнять на отдельной железке.
Единственное что оставить в виде писюка — это шейпер. Мне на FreeBSD 8 удавалось пропускать(и шейпить) через сервак 2.6 ТБ/с с тремья четырехядерными ксеонами и нагрузка была около 40-50% суммарно по всем ядрам. Сервер работал в режиме моста, на нем не было маршрутизации, тажил из одного влана в другой и был подключен обоими линками в центральный маршрутизатор. В итоге если надо было его заменить\перезагрузить, можно было его просто выкинуть из конфига свитча, поменяв в нем 3 строчки, после чего траффик бежал не через него, можно было сделать и динамическую маршрутизацию, но это была бы лишняя нагрузка на сервер, из которого и так выжималось все, вплоть до отключения всяких usb. Без тюнинга он упирался в полную загрузку по цпу уже на 1.6 тб\с.
Во вторых по возможности отказаться от серых ip-адресов, можете даже рассмотреть вариант с ipv6, тогда вы сможете отказаться от NAT/PAT. Если же нет, то NAT выполнять на отдельной железке.
Единственное что оставить в виде писюка — это шейпер. Мне на FreeBSD 8 удавалось пропускать(и шейпить) через сервак 2.6 ТБ/с с тремья четырехядерными ксеонами и нагрузка была около 40-50% суммарно по всем ядрам. Сервер работал в режиме моста, на нем не было маршрутизации, тажил из одного влана в другой и был подключен обоими линками в центральный маршрутизатор. В итоге если надо было его заменить\перезагрузить, можно было его просто выкинуть из конфига свитча, поменяв в нем 3 строчки, после чего траффик бежал не через него, можно было сделать и динамическую маршрутизацию, но это была бы лишняя нагрузка на сервер, из которого и так выжималось все, вплоть до отключения всяких usb. Без тюнинга он упирался в полную загрузку по цпу уже на 1.6 тб\с.
2.6Тб/с — это ошибка? Имелось в виду Гбит/сек?
Производительность шейпера во FreeBSD и Linux сравнивали?
Производительность шейпера во FreeBSD и Linux сравнивали?
1 — Полностью согласен по поводу линукс роутеров — это от бедности.
2 — Вы так говорите — откажитесь от ната, словно это детская задача — перевести структуру на ipv6. Кстати это одно из мест, где бы я стал использовать linux/unix.
3 — Шейпинг более чем 50-100 мбит на писюке/рековом сервере — это уже бред.
2 — Вы так говорите — откажитесь от ната, словно это детская задача — перевести структуру на ipv6. Кстати это одно из мест, где бы я стал использовать linux/unix.
3 — Шейпинг более чем 50-100 мбит на писюке/рековом сервере — это уже бред.
2. Эта задача поможет сэкономить на оборудовании с NAT, а это по хорошему от 300 тысяч рублей при общем трафике в инет от 1 гб\с.
3. почему бред? просто вы не умеете его готовить, похоже.
3. почему бред? просто вы не умеете его готовить, похоже.
Натить можно вполне себе спокойно на двух сервачках за 2к вечнозеленых.
Шейпинг на серваках? Я например с год назад искал средство для борьбы с tcp синхронизацией — че то не нашел. Да и как то сложно представить, что bsd/linux со своими шедулерами справиться с гигабитным потоком так же, как циска/джунипер.
Я не говорю, что это не возможно, но по возможности я бы взял нормальную железку.
Шейпинг на серваках? Я например с год назад искал средство для борьбы с tcp синхронизацией — че то не нашел. Да и как то сложно представить, что bsd/linux со своими шедулерами справиться с гигабитным потоком так же, как циска/джунипер.
Я не говорю, что это не возможно, но по возможности я бы взял нормальную железку.
я уже выше писал, что шейпил 2.6 гб\с и это не предел, теоретически около 5 гб\с можно пропустить. Без значительного(более чем на 5-10мс) увеличения задержек и без потери пакетов.
Бюджет — около 120 тысяч рублей на сервак сертифицированный по ССС + работа квалифицированного админа. Конечно можно купить джунипер за 1-2 млн рублей, но зачем? Когда как сервак справляется + еще можно купить 1-2 шт для горячей замены(ради надежности и уменьшения даунтайма).
Бюджет — около 120 тысяч рублей на сервак сертифицированный по ССС + работа квалифицированного админа. Конечно можно купить джунипер за 1-2 млн рублей, но зачем? Когда как сервак справляется + еще можно купить 1-2 шт для горячей замены(ради надежности и уменьшения даунтайма).
Можете написать поподробнее или посоветовать чего почитать по поводу этого самого «тюнинга»? Много про это слышал, но конкретики никакой. Весь мой тюнинг сводится к правке sysctl и настройке сетевух через ethtool.
начинается с того, что из ядра выкидывается лишьний мусор, остается только самое необходимое. потом нужны правильные сетевухи(а именно intel) с правильными драйверами(от intel, если речь про 10G, или от яндекса, если речь про 1G). Дальше надо пересмотреть фаервол и уменьшить кол-во правил до минимума, включить one-pass, т.е. как только правило доходит до allow — то выходим из фаервола и дальше не идем, каждое уменьшенное правило влияет на производительность намного больше, чем вы себе можете представить(при хайлоаде). Но это вообще далеко не все общие принципы, конкретика начинается в каждом конкретном случае(все зависит от траффика, что идет через шейпер\шлюз, что за ОС используется(желательно использовать что-нибудь самое последнее и очень желательно freebsd)… так же без ковыряния в исходниках ядра не обходится…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
VRRP в Linux