Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
Честно говоря, какая-то фигня у вас написана в разделе «способы решения задачи». Причем тут L3 коммутаторы? Почему NAT отдельным пунктом, когда это по факту дополнение к любому из других вариантов?
Фактически, способов фейловера три (возможно их комбинировать):
1) BGP с full view. Провайдер прислал маршрут? Идем. Отозвал? Не идем.
2) Разного рода костыли, определяющие доступность расположенных по ту сторону канала ресурсов. Соответственно, единственное сложное в этом случае — определить критерии, по которым канал считается живым/мертвым.
3) Непосредственный анализ транзитного трафика на предмет того, что с ним происходит.
Третий вариант — экзотика, и уж точно отсутствует на L3 коммутаторах, которые, вопреки вашим словам, не гибкие, а наоборот — тугие и весьма безмозглые, и катастрофически отстают по возможностям от других решений. Первые два неплохи, особенно вместе.
А еще прокси-сервер, внезапно, может стоять inline, ничего прописывать нигде не придется. А если off-path — есть много способов автоматически скормить конечным системам его контакты.
Я правильно понял, что вы средствами DHCP будете переключать клиентов между серверами? Если так, то поздравляю — это занимает почетное первое место в моем списке наиболее омерзительных архитектурных решений.
И почему на схеме изображена жирная единая точка отказа — L2 свитч?
Фактически, способов фейловера три (возможно их комбинировать):
1) BGP с full view. Провайдер прислал маршрут? Идем. Отозвал? Не идем.
2) Разного рода костыли, определяющие доступность расположенных по ту сторону канала ресурсов. Соответственно, единственное сложное в этом случае — определить критерии, по которым канал считается живым/мертвым.
3) Непосредственный анализ транзитного трафика на предмет того, что с ним происходит.
Третий вариант — экзотика, и уж точно отсутствует на L3 коммутаторах, которые, вопреки вашим словам, не гибкие, а наоборот — тугие и весьма безмозглые, и катастрофически отстают по возможностям от других решений. Первые два неплохи, особенно вместе.
А еще прокси-сервер, внезапно, может стоять inline, ничего прописывать нигде не придется. А если off-path — есть много способов автоматически скормить конечным системам его контакты.
Сервер, в свою очередь, анализирует полученные данные и определяет, какой канал и на каком «маршрутизаторе» на текущий момент приоритетен. Именно для этого в статье рассмотрены настройки DHCP сервера, т.к. для изменения шлюза будут меняться настройки dhcpd.
Я правильно понял, что вы средствами DHCP будете переключать клиентов между серверами? Если так, то поздравляю — это занимает почетное первое место в моем списке наиболее омерзительных архитектурных решений.
И почему на схеме изображена жирная единая точка отказа — L2 свитч?
Причем тут L3 коммутаторы?
Стояла задача — максимально охватить круг возможных решений. Данный вариант было сложно обойти стороной.
Почему NAT отдельным пунктом, когда это по факту дополнение к любому из других вариантов?
Имеется ввиду именно балансировка правилами NAT.
Я правильно понял, что вы средствами DHCP будете переключать клиентов между серверами?
Пока что это только наиболее очевидный для меня вариант за неимением других. И это пока что возможное решение и то, что оно не отличается элегантностью не удивительно. Какие ваши предложения?
Именно из-за весьма смутного представления, каким образом реализовывать задумки далее и стоит ли вообще(т.к. возможно это пустая трата времени и изобретение давно придуманного и прекрасно работающего велосипеда) и была написана статья.
И почему на схеме изображена жирная единая точка отказа — L2 свитч?
Да, я прекрасно понимаю, что с точки зрения надежности и стабильности логичнее было бы использовать к примеру 2 неуправляемых коммутатора или те же 2 L2 коммутатора. Но на схеме изображена реально работающая система и она пока что выглядит именно так.
Данный вариант было сложно обойти стороной.
А чем он отличается от остальных помимо аппаратной реализации data plane (вместо программной) и следующих из этого ограничений?
Есть и аппаратные маршрутизаторы. Некоторые из которых способны смотреть в data plane и на основании анализа сиквенсов TCP за пару секунд фиксировать потери пакетов или пропадание связи (без всяких отдельных пингалок) и предпринимать соответствующие меры. Но такой функционал, конечно, и в софтовых решениях имеется. L3 свитчи о таком и не мечтают.
Имеется ввиду именно балансировка правилами NAT.
Все платформы разные, всякое бывает, но обычно при отсутствии записи в state table (т.е. новое соединение) первым отрабатывает роутинг, и только потом — NAT. Обычно. Есть исключения, но принципиально от них ничего не меняется, суть та же, просто правила NAT начинают притворяться таблицей маршрутизации.
Какие ваши предложения?
В данной топологии напрашивается VRRP разумеется. Это обеспечивает резервирование первого хопа и переключение на резерв за доли секунды прозрачно для клиента (если правильно настроить и если сбой будет тривиальным). Первые хопы будут active/standby со стороны LAN и active/active в сторону LAN. Дальнейшее распределение трафика от LAN по WAN линкам можно организовать на самих роутерах, т.е. перекидывать трафик между собой по мере надобности (например, ради балансировки или при фейловере), благо LAN емкость будет существенно больше WAN емкости. Есть варианты, чтобы трафик от клиента до первого хопа тоже распределялся между узлами, но это по многим причинам плохая идея.
т.к. возможно это пустая трата времени и изобретение давно придуманного и прекрасно работающего велосипеда
Ну в принципе да. Простейшая топология, best practices имеются для любых вендоров/решений.
А чем он отличается от остальных помимо аппаратной реализации data plane (вместо программной) и следующих из этого ограничений?
Ну в основном, конечно, ценой…
В данной топологии напрашивается VRRP разумеется.
Спасибо. Изучу.
Ну в основном, конечно, ценой…
Тогда вы выбрали неправильный пример. «Аппаратные маршрутизаторы» в целом стоят дороже L3 свитчей (а если смотреть на стоимость порта, то это как авианосец по сравнению с надувной лодкой). Архитектура похожая, но в чипах реализован более серьезный функционал.
Ну и «Обычно цены на подобные устройства лежат за пределами 50 т. р.» вызывает улыбку :) Чтобы получить стоимость серьезных железок, вдобавок операторского класса (со всеми лицензиями и модулями на вкус), надо «р.» заменить на "$", иногда к получившемуся прибавить еще нолик. То, что можно купить за полтора килобакса из аппаратного, можно будет использовать именно в режиме умеющего маршрутизировать свитча — под шлюз в интернет оно не годится вообще хотя бы по причине отсутствия NAT, возможности работать с потоками, ограниченности размеров FIB, ограниченности программного функционала (экономят) и так далее.
Чтобы получить стоимость серьезных железок, вдобавок операторского класса (со всеми лицензиями и модулями на вкус), надо «р.» заменить на "$", иногда к получившемуся прибавить еще нолик.
К сожалению, не большой опыт работы с данными железками и, судя по указанной вами цене, еще не скоро представится шанс. Цену указывал для контраста, старался не взять слишком высоко. В целом — принял к сведению, в будущем учту.
Почему прокси требует дополнительной настройки на стороне клиентов?
Разве прозрачный прокси не убирает данный минус?
Разве прозрачный прокси не убирает данный минус?
Разве прозрачный прокси не убирает данный минус?
Да, но шифрованный трафик через нее не пропустишь.
Вообще никакой разницы нет.
Вообще никакой разницы нет.
Относительно конкретно данного вопроса — у меня лично опыта использования подобных систем практически нет. Поэтому ориентируюсь исключительно на мнение более опытных знакомых или общественности. Итог по данному вопросу пока что такой: разница между шифрованным и не шифрованным трафиком с точки зрения использования прокси всё же есть. Вот два варианта:
1
2
В случае первого — настройка на клиентах требуется, второго — требуется приобретение сертификата, а это деньги и время (зато не требуется настройка у клиентов). Это как раз те самые дополнительные сложности, которые я и имел ввиду, хотя не исключаю того варианты, что они несколько преувеличены.
Немного не так.
Есть две совершенно независимые задачи:
1) Доставить трафик до прокси.
2) На проксе что-то вытворять с трафиком. Например — разобрать SSL.
Первое может решаться установкой прокси в inline (тогда сетевое оборудование будет гнать трафик наружу/внутрь через прокси, полностью прозрачно для клиента) или off-path (тогда клиент будет инкапсулировать HTTP и адресовать трафик непосредственно прокси).
В обоих случаях как минимум на винде никаких дополнительных настроек не требуется. Можно подсунуть WPAD по DHCP или DNS, там будет описано к чему идти через прокси и какой адрес у той прокси. По умолчанию у винды стоит галка «автоматически определять настройки прокси», это оно и есть. Никакой ручной работы.
Вторая задача — классический MITM. Прокси на лету генерирует сертификат для домена, к которому обратился клиент. Если ее CA в доверенных у клиента, то клиент не заругается. Если не в доверенных — заругается. О покупке сертификата речь в любом случае не идет, никто не даст вам подписанный доверенным всеми ОС и браузерами CA сертификат на не принадлежащий вам домен.
Но повторюсь, обе задачи совершенно независимые, решение одной не влияет на другую. Разница только в «будет ли клиент инкапсулировать внешний трафик и слать его напрямую проксе?».
Есть две совершенно независимые задачи:
1) Доставить трафик до прокси.
2) На проксе что-то вытворять с трафиком. Например — разобрать SSL.
Первое может решаться установкой прокси в inline (тогда сетевое оборудование будет гнать трафик наружу/внутрь через прокси, полностью прозрачно для клиента) или off-path (тогда клиент будет инкапсулировать HTTP и адресовать трафик непосредственно прокси).
В обоих случаях как минимум на винде никаких дополнительных настроек не требуется. Можно подсунуть WPAD по DHCP или DNS, там будет описано к чему идти через прокси и какой адрес у той прокси. По умолчанию у винды стоит галка «автоматически определять настройки прокси», это оно и есть. Никакой ручной работы.
Вторая задача — классический MITM. Прокси на лету генерирует сертификат для домена, к которому обратился клиент. Если ее CA в доверенных у клиента, то клиент не заругается. Если не в доверенных — заругается. О покупке сертификата речь в любом случае не идет, никто не даст вам подписанный доверенным всеми ОС и браузерами CA сертификат на не принадлежащий вам домен.
Но повторюсь, обе задачи совершенно независимые, решение одной не влияет на другую. Разница только в «будет ли клиент инкапсулировать внешний трафик и слать его напрямую проксе?».
вочдог раз в час запускается?
вочдог раз в час запускается?
Watchdog запускается раз в час в любом варианте, чтобы проверить, что Daemon работает и, возможно, запустить его. Также Watchdog может быть вызван другими модулями в случае неожиданных значений переменных.
Частота запуска из cron не должна превышать:
$TESTERMAXDELAY + $JUDGEMAXDELAY + $LOGGERMAXDELAY + 30
В указанном в статье примере конфигурационного файла частота должна быть не меньше 2 минут, но на мой взгляд — запуска 1 раз в час вполне достаточно.
я бы максимально часто запускал вочдог во избежании продолжительной неработоспособности демона
я бы максимально часто запускал вочдог во избежании продолжительной неработоспособности демона
Не уверен, что это оправдано, хотя с другой стороны, конечно, и не повредит. Но за прошедшие шесть месяцев модуль Daemon ни разу самопроизвольно не выключался, так что он сделан, скорее, для подстраховки, нежели, как жизненная необходимость. Конечно же, всегда остается вероятность того, что мне несказанно везло весь вышеописанный промежуток времени, но в это слабо верится.
0. баш во фре не родной.
Для меня более привычный. Возможно, если будет решено оставить данную, не побоюсь этого слова, программу именно на скриптовом языке, — рассмотрю варианты реализации на sh или другом родном для FreeBSD языке.
2. rc.d — у вас от десктопа, что за треш!?
Местами осталось от старой настройки. По поводу языка с вами соглашусь. Относительно мышки — при работе непосредственно на сервере иногда помогает. Остальное еще раз изучу, возможно, действительно лишнее.
3. Для мелкой конторы без своих зон вместо бинд лучше unbound, а вместо dhcpd — dnsmasq (с отключённым днс и тфтп).
Возможно, но уже изучен bind и isc-dhcpd и, честно говоря, их работа вполне устраивает и изучать/настраивать что-то другое не очень хочется. К тому же имеется вероятность, что своя зона все же появится рано или поздно.
можно тестить все имеющиеся подключения одновременно.
Они итак тестируются одновременно. как раз при помощи setfib. Однако, нюансы использования именно SO_SETFIB из вашего замечания изучу.
собственно, Дмитрий уже сказал про самый приемлемый вариант (на этом оборудовании) — стандартный VRRP.
Странно, что в списке решений автор перепрыгнул от SOHO-маршрутизаторов сразу к операторским крммутатором, обойдя своим вниманием огромный сегмент маршрутизаторов уровня предприятий. Их у каждого серьезного производителя не по одному в линейке предстаалено, и с поставленой задачей, подозреваю, справятся они не хуже скриптов на фряхе
Странно, что в списке решений автор перепрыгнул от SOHO-маршрутизаторов сразу к операторским крммутатором, обойдя своим вниманием огромный сегмент маршрутизаторов уровня предприятий. Их у каждого серьезного производителя не по одному в линейке предстаалено, и с поставленой задачей, подозреваю, справятся они не хуже скриптов на фряхе
И, в случае, если мы заранее установили a=1, данное выражение будет означать 123, а если a=2, то 321Вам нужен eval. Примеров достаточно в /etc/rc.d.
Типовой костыль «дла балансировки интерента», сделано для офиса (Pentium 3, 512 ОП), офисным админом.
О BGP речи не идёт, 2 провайдера 2 IP, 2 провода — с точки зрения автора это настолько очевидно, что даже не заслуживает упоминания.
Скрипту несколько лет, он был переписан и ни слова про VRRP, а лучше CARP если уж FreeBSD.
Вобще, ИМХО, скрипт на бюджетном сервере, нормальное решение для офиса. Но, понимаете, так принято, что каждый пишет свойкостыль скрипт, а потом ссыт кипятком бегает как угорелый и всем его показывает. Предлагая своё готовое решение вы лишаете других администраторов такой радости.
А если кто-то решит использовать ваш, то почему он должен предпочесть его любому другому из пункта 3. Сами же туда попадаете, сделайте хоть какое-то сравнение/обзор, а то «проще написать свою версию, нежели разбираться в чужой». Так и в вашей никто разбираться не будет…
О BGP речи не идёт, 2 провайдера 2 IP, 2 провода — с точки зрения автора это настолько очевидно, что даже не заслуживает упоминания.
Скрипту несколько лет, он был переписан и ни слова про VRRP, а лучше CARP если уж FreeBSD.
Вобще, ИМХО, скрипт на бюджетном сервере, нормальное решение для офиса. Но, понимаете, так принято, что каждый пишет свой
А если кто-то решит использовать ваш, то почему он должен предпочесть его любому другому из пункта 3. Сами же туда попадаете, сделайте хоть какое-то сравнение/обзор, а то «проще написать свою версию, нежели разбираться в чужой». Так и в вашей никто разбираться не будет…
Типовой костыль «дла балансировки интерента», сделано для офиса (Pentium 3, 512 ОП), офисным админом.
Так точно. Только я и публикую по этой самой причине — сделать из «типового костыля» что-то приемлемое.
О BGP речи не идёт, 2 провайдера 2 IP, 2 провода — с точки зрения автора это настолько очевидно, что даже не заслуживает упоминания.
По правде говоря, до публикации именно так и было. Теперь многие свои взгляды на данный вопрос я пересмотрел, многие уже наметились для пересмотра в ближайшем будущем.
каждый пишет свой костыль скрипт, а потом ссыт кипятком бегает как угорелый и всем его показывает
Хочу заметить, что я его показываю не от большой гордости, а ровно с двумя целями: 1. исправление проблем/улучшение алгоритма, 2. помощь другим «офисным админам» с решением подобной задачи.
А если кто-то решит использовать ваш, то почему он должен предпочесть его любому другому из пункта 3. Сами же туда попадаете, сделайте хоть какое-то сравнение/обзор, а то «проще написать свою версию, нежели разбираться в чужой». Так и в вашей никто разбираться не будет…
Здравая мысль, товарисч! К сожалению, мне она сразу не пришла в голову, посему получилось то, что получилось. Ну относительно плюсов как минимум 1 очевидный назвать могу с ходу — модульность. Если не нравится, к примеру, система тестирования соединения — переписываешь модуль Tester и получаешь то, что лично тебе нужно и т.д., при этом всё остальное будет взаимодействовать с новым модулем также, как и раньше, не обращая внимание, что изменилась внутренняя логика. Разумеется, это работает, если в новом модуле не нарушен ввод-вывод, относительно старого. По поводу сравнения — какое ваше мнение, писать новую статью(на мой взгляд нет причин для отдельной публикации) или изложить это самое сравнение в комментариях?
Попробуйте PfSense — очень милый дистрибутивчик FreeBSD, ставится за две минуты, есть нескучный WEB-интерфейс с дашбоардами (можно начальству графики показывать), вагон дополнительных пакетов, есть CARP (это когда один сервер падает, а второй это видит и его LAN-адрес забирает). А вообще, очень интересна тема балансировки двух каналов (так, чтобы оба одновременно работали и не были завязаны на статические маршруты), когда у вас один сервер, два WAN и один LAN.
Попробуйте PfSense — очень милый дистрибутивчик FreeBSD, ставится за две минуты, есть нескучный WEB-интерфейс с дашбоардами (можно начальству графики показывать),
Слышал, смотрел картинки. В вашем варианте один сервер подменяет другой, при этом нет гарантии, что второй правильно распознает падение первого. Мне по этой причине кажется более помехоустойчивым кажется вариант, когда сервера работают параллельно и делят нагрузку + подключены к единой системе мониторинга и подсчета трафика. Я для этих целей использую Zabbix и NetAMS.
есть CARP
Данную функцию я еще детально не изучил, но с большой вероятностью буду использовать в своей системе в ближайшем будущем.
А вообще, очень интересна тема балансировки двух каналов (так, чтобы оба одновременно работали и не были завязаны на статические маршруты), когда у вас один сервер, два WAN и один LAN.
Данная тематика вскользь упомянута в статье. Лично мне известны 2 варианта балансировки — это посредством NAT(во всяком случае при использовании «ядерного» NAT и скорее всего здесь навязывается ipfw) и с помощью proxy сервера, в частности, squid. Статей по данному вопросу хватает. Разве что, я не вдавался в детали относительно статических маршрутов…
Данная тематика вскользь упомянута в статье. Лично мне известны 2 варианта балансировки — это посредством NAT(во всяком случае при использовании «ядерного» NAT и скорее всего здесь навязывается ipfw) и с помощью proxy сервера, в частности, squid. Статей по данному вопросу хватает. Разве что, я не вдавался в детали относительно статических маршрутов…
Я, честно говоря, с ipfw практически не сталкивался, а в iptables это делается довольно изящно, через маркировку соединений (не знаю, есть ли аналог в ipfw) и создание правил маршрутизации (по принципу «если есть метка — отправляем сюда»). Хорошие люди, оказывается, написали статью: http://habrahabr.ru/post/173713/.Комментарии там тоже весьма полезны. Правда, в статье описывается случай, когда вам нужно балансировать внешний трафик внутрь сети, но ничего не мешает развернуть этот принцип «наоборот».
Чего не сделают эти русские, чтобы не использовать BGP.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ToFoIn – Toggle Failover of Internet или переключение между двумя внешними каналами в FreeBSD