Попробуйте PfSense — очень милый дистрибутивчик FreeBSD, ставится за две минуты, есть нескучный WEB-интерфейс с дашбоардами (можно начальству графики показывать),
Слышал, смотрел картинки. В вашем варианте один сервер подменяет другой, при этом нет гарантии, что второй правильно распознает падение первого. Мне по этой причине кажется более помехоустойчивым кажется вариант, когда сервера работают параллельно и делят нагрузку + подключены к единой системе мониторинга и подсчета трафика. Я для этих целей использую Zabbix и NetAMS.
есть CARP
Данную функцию я еще детально не изучил, но с большой вероятностью буду использовать в своей системе в ближайшем будущем.
А вообще, очень интересна тема балансировки двух каналов (так, чтобы оба одновременно работали и не были завязаны на статические маршруты), когда у вас один сервер, два WAN и один LAN.
Данная тематика вскользь упомянута в статье. Лично мне известны 2 варианта балансировки — это посредством NAT(во всяком случае при использовании «ядерного» NAT и скорее всего здесь навязывается ipfw) и с помощью proxy сервера, в частности, squid. Статей по данному вопросу хватает. Разве что, я не вдавался в детали относительно статических маршрутов…
Типовой костыль «дла балансировки интерента», сделано для офиса (Pentium 3, 512 ОП), офисным админом.
Так точно. Только я и публикую по этой самой причине — сделать из «типового костыля» что-то приемлемое.
О BGP речи не идёт, 2 провайдера 2 IP, 2 провода — с точки зрения автора это настолько очевидно, что даже не заслуживает упоминания.
По правде говоря, до публикации именно так и было. Теперь многие свои взгляды на данный вопрос я пересмотрел, многие уже наметились для пересмотра в ближайшем будущем.
каждый пишет свой костыль скрипт, а потом ссыт кипятком бегает как угорелый и всем его показывает
Хочу заметить, что я его показываю не от большой гордости, а ровно с двумя целями: 1. исправление проблем/улучшение алгоритма, 2. помощь другим «офисным админам» с решением подобной задачи.
А если кто-то решит использовать ваш, то почему он должен предпочесть его любому другому из пункта 3. Сами же туда попадаете, сделайте хоть какое-то сравнение/обзор, а то «проще написать свою версию, нежели разбираться в чужой». Так и в вашей никто разбираться не будет…
Здравая мысль, товарисч! К сожалению, мне она сразу не пришла в голову, посему получилось то, что получилось. Ну относительно плюсов как минимум 1 очевидный назвать могу с ходу — модульность. Если не нравится, к примеру, система тестирования соединения — переписываешь модуль Tester и получаешь то, что лично тебе нужно и т.д., при этом всё остальное будет взаимодействовать с новым модулем также, как и раньше, не обращая внимание, что изменилась внутренняя логика. Разумеется, это работает, если в новом модуле не нарушен ввод-вывод, относительно старого. По поводу сравнения — какое ваше мнение, писать новую статью(на мой взгляд нет причин для отдельной публикации) или изложить это самое сравнение в комментариях?
Для меня более привычный. Возможно, если будет решено оставить данную, не побоюсь этого слова, программу именно на скриптовом языке, — рассмотрю варианты реализации на sh или другом родном для FreeBSD языке.
2. rc.d — у вас от десктопа, что за треш!?
Местами осталось от старой настройки. По поводу языка с вами соглашусь. Относительно мышки — при работе непосредственно на сервере иногда помогает. Остальное еще раз изучу, возможно, действительно лишнее.
3. Для мелкой конторы без своих зон вместо бинд лучше unbound, а вместо dhcpd — dnsmasq (с отключённым днс и тфтп).
Возможно, но уже изучен bind и isc-dhcpd и, честно говоря, их работа вполне устраивает и изучать/настраивать что-то другое не очень хочется. К тому же имеется вероятность, что своя зона все же появится рано или поздно.
можно тестить все имеющиеся подключения одновременно.
Они итак тестируются одновременно. как раз при помощи setfib. Однако, нюансы использования именно SO_SETFIB из вашего замечания изучу.
я бы максимально часто запускал вочдог во избежании продолжительной неработоспособности демона
Не уверен, что это оправдано, хотя с другой стороны, конечно, и не повредит. Но за прошедшие шесть месяцев модуль Daemon ни разу самопроизвольно не выключался, так что он сделан, скорее, для подстраховки, нежели, как жизненная необходимость. Конечно же, всегда остается вероятность того, что мне несказанно везло весь вышеописанный промежуток времени, но в это слабо верится.
Относительно конкретно данного вопроса — у меня лично опыта использования подобных систем практически нет. Поэтому ориентируюсь исключительно на мнение более опытных знакомых или общественности. Итог по данному вопросу пока что такой: разница между шифрованным и не шифрованным трафиком с точки зрения использования прокси всё же есть. Вот два варианта: 1 2
В случае первого — настройка на клиентах требуется, второго — требуется приобретение сертификата, а это деньги и время (зато не требуется настройка у клиентов). Это как раз те самые дополнительные сложности, которые я и имел ввиду, хотя не исключаю того варианты, что они несколько преувеличены.
Watchdog запускается раз в час в любом варианте, чтобы проверить, что Daemon работает и, возможно, запустить его. Также Watchdog может быть вызван другими модулями в случае неожиданных значений переменных.
Частота запуска из cron не должна превышать:
$TESTERMAXDELAY + $JUDGEMAXDELAY + $LOGGERMAXDELAY + 30
В указанном в статье примере конфигурационного файла частота должна быть не меньше 2 минут, но на мой взгляд — запуска 1 раз в час вполне достаточно.
Чтобы получить стоимость серьезных железок, вдобавок операторского класса (со всеми лицензиями и модулями на вкус), надо «р.» заменить на "$", иногда к получившемуся прибавить еще нолик.
К сожалению, не большой опыт работы с данными железками и, судя по указанной вами цене, еще не скоро представится шанс. Цену указывал для контраста, старался не взять слишком высоко. В целом — принял к сведению, в будущем учту.
Стояла задача — максимально охватить круг возможных решений. Данный вариант было сложно обойти стороной.
Почему NAT отдельным пунктом, когда это по факту дополнение к любому из других вариантов?
Имеется ввиду именно балансировка правилами NAT.
Я правильно понял, что вы средствами DHCP будете переключать клиентов между серверами?
Пока что это только наиболее очевидный для меня вариант за неимением других. И это пока что возможное решение и то, что оно не отличается элегантностью не удивительно. Какие ваши предложения?
Именно из-за весьма смутного представления, каким образом реализовывать задумки далее и стоит ли вообще(т.к. возможно это пустая трата времени и изобретение давно придуманного и прекрасно работающего велосипеда) и была написана статья.
И почему на схеме изображена жирная единая точка отказа — L2 свитч?
Да, я прекрасно понимаю, что с точки зрения надежности и стабильности логичнее было бы использовать к примеру 2 неуправляемых коммутатора или те же 2 L2 коммутатора. Но на схеме изображена реально работающая система и она пока что выглядит именно так.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Слышал, смотрел картинки. В вашем варианте один сервер подменяет другой, при этом нет гарантии, что второй правильно распознает падение первого. Мне по этой причине кажется более помехоустойчивым кажется вариант, когда сервера работают параллельно и делят нагрузку + подключены к единой системе мониторинга и подсчета трафика. Я для этих целей использую Zabbix и NetAMS.
Данную функцию я еще детально не изучил, но с большой вероятностью буду использовать в своей системе в ближайшем будущем.
Данная тематика вскользь упомянута в статье. Лично мне известны 2 варианта балансировки — это посредством NAT(во всяком случае при использовании «ядерного» NAT и скорее всего здесь навязывается ipfw) и с помощью proxy сервера, в частности, squid. Статей по данному вопросу хватает. Разве что, я не вдавался в детали относительно статических маршрутов…
Так точно. Только я и публикую по этой самой причине — сделать из «типового костыля» что-то приемлемое.
По правде говоря, до публикации именно так и было. Теперь многие свои взгляды на данный вопрос я пересмотрел, многие уже наметились для пересмотра в ближайшем будущем.
Хочу заметить, что я его показываю не от большой гордости, а ровно с двумя целями: 1. исправление проблем/улучшение алгоритма, 2. помощь другим «офисным админам» с решением подобной задачи.
Здравая мысль, товарисч! К сожалению, мне она сразу не пришла в голову, посему получилось то, что получилось. Ну относительно плюсов как минимум 1 очевидный назвать могу с ходу — модульность. Если не нравится, к примеру, система тестирования соединения — переписываешь модуль Tester и получаешь то, что лично тебе нужно и т.д., при этом всё остальное будет взаимодействовать с новым модулем также, как и раньше, не обращая внимание, что изменилась внутренняя логика. Разумеется, это работает, если в новом модуле не нарушен ввод-вывод, относительно старого. По поводу сравнения — какое ваше мнение, писать новую статью(на мой взгляд нет причин для отдельной публикации) или изложить это самое сравнение в комментариях?
Для меня более привычный. Возможно, если будет решено оставить данную, не побоюсь этого слова, программу именно на скриптовом языке, — рассмотрю варианты реализации на sh или другом родном для FreeBSD языке.
Местами осталось от старой настройки. По поводу языка с вами соглашусь. Относительно мышки — при работе непосредственно на сервере иногда помогает. Остальное еще раз изучу, возможно, действительно лишнее.
Возможно, но уже изучен bind и isc-dhcpd и, честно говоря, их работа вполне устраивает и изучать/настраивать что-то другое не очень хочется. К тому же имеется вероятность, что своя зона все же появится рано или поздно.
Они итак тестируются одновременно. как раз при помощи setfib. Однако, нюансы использования именно SO_SETFIB из вашего замечания изучу.
Не уверен, что это оправдано, хотя с другой стороны, конечно, и не повредит. Но за прошедшие шесть месяцев модуль Daemon ни разу самопроизвольно не выключался, так что он сделан, скорее, для подстраховки, нежели, как жизненная необходимость. Конечно же, всегда остается вероятность того, что мне несказанно везло весь вышеописанный промежуток времени, но в это слабо верится.
Относительно конкретно данного вопроса — у меня лично опыта использования подобных систем практически нет. Поэтому ориентируюсь исключительно на мнение более опытных знакомых или общественности. Итог по данному вопросу пока что такой: разница между шифрованным и не шифрованным трафиком с точки зрения использования прокси всё же есть. Вот два варианта:
1
2
В случае первого — настройка на клиентах требуется, второго — требуется приобретение сертификата, а это деньги и время (зато не требуется настройка у клиентов). Это как раз те самые дополнительные сложности, которые я и имел ввиду, хотя не исключаю того варианты, что они несколько преувеличены.
Спасибо огромное. Похоже, что это именно то, что нужно!
Watchdog запускается раз в час в любом варианте, чтобы проверить, что Daemon работает и, возможно, запустить его. Также Watchdog может быть вызван другими модулями в случае неожиданных значений переменных.
Частота запуска из cron не должна превышать:
$TESTERMAXDELAY + $JUDGEMAXDELAY + $LOGGERMAXDELAY + 30
В указанном в статье примере конфигурационного файла частота должна быть не меньше 2 минут, но на мой взгляд — запуска 1 раз в час вполне достаточно.
К сожалению, не большой опыт работы с данными железками и, судя по указанной вами цене, еще не скоро представится шанс. Цену указывал для контраста, старался не взять слишком высоко. В целом — принял к сведению, в будущем учту.
Ну в основном, конечно, ценой…
Спасибо. Изучу.
Да, но шифрованный трафик через нее не пропустишь.
Стояла задача — максимально охватить круг возможных решений. Данный вариант было сложно обойти стороной.
Имеется ввиду именно балансировка правилами NAT.
Пока что это только наиболее очевидный для меня вариант за неимением других. И это пока что возможное решение и то, что оно не отличается элегантностью не удивительно. Какие ваши предложения?
Именно из-за весьма смутного представления, каким образом реализовывать задумки далее и стоит ли вообще(т.к. возможно это пустая трата времени и изобретение давно придуманного и прекрасно работающего велосипеда) и была написана статья.
Да, я прекрасно понимаю, что с точки зрения надежности и стабильности логичнее было бы использовать к примеру 2 неуправляемых коммутатора или те же 2 L2 коммутатора. Но на схеме изображена реально работающая система и она пока что выглядит именно так.