Комментарии 32
Почему не сразу в кактус?
Не для разжигания, разрешите рассказать, как это делается в Windows Server.
Запускаем Perfmon и добавляем счетчик DHCP Server-Request sec.
Запускаем Perfmon и добавляем счетчик DHCP Server-Request sec.
Я еще добавлю, что с 2012 там и failover нормальный и вполне работают вместе два dhcp.
Вообще способов решение такой проблемы много, включая всякие коммутаторы L3 или L2+ уровня.
Вообще способов решение такой проблемы много, включая всякие коммутаторы L3 или L2+ уровня.
Да не нужен мне файловер.
А какую проблему с построением графиков мы будем решать с помощью L3 коммутатора? А то у меня там пачка стоит в серверной, кошки всякие, экстримы… А графики не рисуют…
А какую проблему с построением графиков мы будем решать с помощью L3 коммутатора? А то у меня там пачка стоит в серверной, кошки всякие, экстримы… А графики не рисуют…
>А какую проблему с построением графиков мы будем решать с помощью L3 коммутатора?
А какая там проблема есть?
Извините, но у вас чисто колхозный подход. Хренак хренак и в продакшен.
Я не хочу ходить со своим уставом в чужой монастырь, если у вас это все работает и устраивает — то ok.
Если у вас есть кошки и кошки нормальные и вызнаете как их готовить, то логично было бы использовать их.
Еще и NetFlow задействовать и собирать все в одно место типа zabbix.
А какая там проблема есть?
Извините, но у вас чисто колхозный подход. Хренак хренак и в продакшен.
Я не хочу ходить со своим уставом в чужой монастырь, если у вас это все работает и устраивает — то ok.
Если у вас есть кошки и кошки нормальные и вызнаете как их готовить, то логично было бы использовать их.
Еще и NetFlow задействовать и собирать все в одно место типа zabbix.
Какая проблема говорите… А вот неизвестно, какая проблема и есть ли.
Вот например — админ с кошки обращается ко мне и говорит — у меня тут второй час проц почти на полочке, а почему — непонятно. Искали долго. Но в конце концов добрался до лога dhcp. И просто смотрю его по tail -f, пытаясь понять — почему relay процесс на кошке проц кушает. И обращаю внимание, что чаще всего мне в логе DHCPOFFER попадается. Почитал повнимательней — нашел влан, в котором DHCPOFFER и сыпались. Ну и дальше нашли проблему — свичик с ума в городе сошел маленько. Причем ни штормконтроль, никто не реагировали…
И чем вас мой подход не устраивает? Я не обсуждаю структуру своей сети, не обсуждаю методику раздачи интернета. Я привел способ решения одной маленькой задачи в мониторинге. Прежде чем я начал писать все это — я сначала искал в интернетах, как люди поступают. И пришел к выводу, что никак. Судя по всему работоспособность DHCP принимается за аксиому. Т.е. запустили dhcp сервер — значит работает ;). Честно говоря я и сам так считал. Но подобного графика мне не хватало. Сейчас вот рисуется, смотрим. Если этот график мне через год поможет найти ровно одну проблему — значит я не зря его рисовал…
Вот например — админ с кошки обращается ко мне и говорит — у меня тут второй час проц почти на полочке, а почему — непонятно. Искали долго. Но в конце концов добрался до лога dhcp. И просто смотрю его по tail -f, пытаясь понять — почему relay процесс на кошке проц кушает. И обращаю внимание, что чаще всего мне в логе DHCPOFFER попадается. Почитал повнимательней — нашел влан, в котором DHCPOFFER и сыпались. Ну и дальше нашли проблему — свичик с ума в городе сошел маленько. Причем ни штормконтроль, никто не реагировали…
И чем вас мой подход не устраивает? Я не обсуждаю структуру своей сети, не обсуждаю методику раздачи интернета. Я привел способ решения одной маленькой задачи в мониторинге. Прежде чем я начал писать все это — я сначала искал в интернетах, как люди поступают. И пришел к выводу, что никак. Судя по всему работоспособность DHCP принимается за аксиому. Т.е. запустили dhcp сервер — значит работает ;). Честно говоря я и сам так считал. Но подобного графика мне не хватало. Сейчас вот рисуется, смотрим. Если этот график мне через год поможет найти ровно одну проблему — значит я не зря его рисовал…
>И чем вас мой подход не устраивает?
Направление верное, инструменты не те. Но опять же, тут личное мнение каждого. Если выбирать между никак и как то, лучше как то чем никак ;) Тут я с вами спорить вообще не буду.
На тему железок ситуация разные и много чего надо принимать в расчет. Приходилось помогать интегратору, у которого каждое утро DHCP молча умирал. Клиентов больше 2000. Если коротко, то машина просто не справлялась. Решили в приделах широковищательного домена поднимать DHCP на L2+, а запросы уже перенаправлять на умирающий сервер через option 82.
И да мониторинга там не было, поэтому я вашу боль прекрасно понимаю.
Направление верное, инструменты не те. Но опять же, тут личное мнение каждого. Если выбирать между никак и как то, лучше как то чем никак ;) Тут я с вами спорить вообще не буду.
На тему железок ситуация разные и много чего надо принимать в расчет. Приходилось помогать интегратору, у которого каждое утро DHCP молча умирал. Клиентов больше 2000. Если коротко, то машина просто не справлялась. Решили в приделах широковищательного домена поднимать DHCP на L2+, а запросы уже перенаправлять на умирающий сервер через option 82.
И да мониторинга там не было, поэтому я вашу боль прекрасно понимаю.
Кхм. всего то 2к клиентов и dhcp сервер не справляется????? Или это единственный сервер во всей инфраструктуре, и на нем все крутится, или я даже не представляю. У меня просто на порядок больше, и LA на dhcp — не выше 0.1
А вот решение ваше я даже не понял. Ну добавили вы relay. А что для сервера то изменилось?
А вот решение ваше я даже не понял. Ну добавили вы relay. А что для сервера то изменилось?
А дальше? Ну вот добавил. Но мне абсолютно неинтересно ходить на какой то сервер, и смотреть там какой то один график. Все нужные мне графики объединены на едином сервере. Как мне из этого «Perfmon» данные то получить? snmp подойдет, вот только где об этом почитать?
ЗЫ. Ну не ориентируюсь я в винде.
ЗЫ. Ну не ориентируюсь я в винде.
В результате я реализовал вот такую схему.
Почему не отправлять логи сразу на нужный сервер через Syslog? Зачем лишний геморрой с SCP?
На целевом сервере можно уже либо методом аналогичным tail -f читать из скрипта логфайл в режиме реального времени, либо по крону.
Ну и вообще ни разу не энтерпрайзно. Правильный подход — написать скрипт, который будет готовить данные для единой системы мониторинга (заббикс, нагиос, кактус), а не рисовать на коленке графики сам.
Соответственно, в мониторинге нужно сделать триггеры чтобы он рассылал уведомления если что-то не так, а не оператор сидел и в графиках искал смысл жизни в ночи.
Ну и наконец, в ISC DHCP есть встроенный failover механизм, который отлично работает.
Городить два независимых сервера с идентичными конфигами мне кажется странным, тем более если это виртуалки.
>ISC DHCP есть встроенный failover
а давно он там? РУками ISC DHCP давно не трогал.
Ну и ссылку на доку если ткнете, буду только рад почитать. (хотя думаю и сам найду)
а давно он там? РУками ISC DHCP давно не трогал.
Ну и ссылку на доку если ткнете, буду только рад почитать. (хотя думаю и сам найду)
Давно, несколько лет точно.
kb.isc.org/article/AA-00502/0/A-Basic-Guide-to-Configuring-DHCP-Failover.html
kb.isc.org/article/AA-00502/0/A-Basic-Guide-to-Configuring-DHCP-Failover.html
не нужен файловер в dhcp. Двух серверов с идентичными конфигами хватает более чем.
Мониторинг есть, графики реализовал больше для себя — чтобы оценить нагрузку на сервера и посмотреть, как там оно работает ;)
Мониторинг есть, графики реализовал больше для себя — чтобы оценить нагрузку на сервера и посмотреть, как там оно работает ;)
не нужен файловер в dhcp. Двух серверов с идентичными конфигами хватает более чем.
И как они работают?
Обслуживают разные броадкаст домены?
Или оба слушают одинаковые домены и отвечают в режиме кто первый встал — того и тапки?
Раздают адреса из разных пулов?
В общем, не понятно зачем делать криво, если есть встроенный failover-функционал, который настраивается в несколько строчек в конфиге.
сервера стоят за релеем. Оба слушают одинаковые домены — около 700 вланов. В каждом влане абоненты привязаны к маку. Т.е. в любом случае ответ от обоих серверов — одинаков. Для новых абонентов, поменянных устройств и т.п. — в каждом влане есть выделенный диапазон в 16 адресов. В этом диапазоне ответы идут по принципу кто первый встал, того и тапки. Судя по логам — ни разу не видел попытки выдать два разных адреса на один запрос. Обычно отвечает какой то один сервер, второй молчит, но отмечает у себя занятие адреса. Длительность аренды у меня установлена в 10 минут. На самом деле не имеет принципиального значения, какой именно адрес в гостевом диапазоне выдан — абонент заходит в личный кабинет и прописывает себе новый мак, после чего в течении 2 минут происходит перегенерация конфига dhcp, раз в 5 минут он разливается на сервера и примерно через час (винда не хочет добровольно освобождать адрес раньше, хоть лиза и выдается на 10 минут) у абонента уже закрепленный за ним адрес. Интернет мы раздаем по pppoe, работать он начинает сразу после указания абонентом мака в личном кабинете.
Да уж, про механизм предоставления интернета я промолчу :) В наше-то время использовать привязку к маку, да ещё и с PPPoE наверченым поверх…
По серверам. У тебя получается, что сервера клиенту отвечают оба одновременно и клиент из них уже выбирает того, чей ответ пришёл первым и дальше с ним говорит уже по уникасту. В итоге у тебя куча лишнего траффика в сети получается.
Если сделать failover, то сервера между собой будут договариваться насчёт того кто будет выдавать аренду и отвечать клиенту будет только один из них.
По серверам. У тебя получается, что сервера клиенту отвечают оба одновременно и клиент из них уже выбирает того, чей ответ пришёл первым и дальше с ним говорит уже по уникасту. В итоге у тебя куча лишнего траффика в сети получается.
Если сделать failover, то сервера между собой будут договариваться насчёт того кто будет выдавать аренду и отвечать клиенту будет только один из них.
ну не такая уж и куча, как показывает практика ;)
имеем в среднем около 10-20 запросов в секунду. Из них отвечают оба сервера — это DHCPOFFER и DHCPACK. DHCPINFORM, которым запрашиваются доп параметры — уже не широковещательный.
failover я пробовал изначально. В результате на вторые-третьи сутки dhcp становились раком. Почему — уже не знаю, это было лет так 8 назад ;). С тех пор стоят два сервера, паралелльно они же еще и dns сервера для клиентов. Самые нетребовательные и беспроблемные виртуалки. Либо ошибка в конфиге, либо проблемы в транспорте. Других причин ошибок DHCP и не припомню за эти годы ;)
имеем в среднем около 10-20 запросов в секунду. Из них отвечают оба сервера — это DHCPOFFER и DHCPACK. DHCPINFORM, которым запрашиваются доп параметры — уже не широковещательный.
failover я пробовал изначально. В результате на вторые-третьи сутки dhcp становились раком. Почему — уже не знаю, это было лет так 8 назад ;). С тех пор стоят два сервера, паралелльно они же еще и dns сервера для клиентов. Самые нетребовательные и беспроблемные виртуалки. Либо ошибка в конфиге, либо проблемы в транспорте. Других причин ошибок DHCP и не припомню за эти годы ;)
failover я пробовал изначально. В результате на вторые-третьи сутки dhcp становились раком. Почему — уже не знаю, это было лет так 8 назад ;)
У меня уже лет, наверное, пять пашет ОК, ни разу с нимм проблем не было.
Конфиги тоже генерятся централизованно и раскидываются по обоим серверам (за исключением failover блока в конфиге всё общее). Так что вполне юзабельно.
Неужели еще кто-то делает такие скрипты «на коленке»?
Как мне казалось уже все давно перешли или на logstash+kibana, или sensu+grafana или на худой конец cacti/zabbix.
Как мне казалось уже все давно перешли или на logstash+kibana, или sensu+grafana или на худой конец cacti/zabbix.
Иногда. В моём случае «наколенный велосипед» предназначен для OpenNMS (тот же zabbix, только в профиль) и получение данных статистики идёт по SNMP. Единая система мониторинга, триггеры-алармы на всякие случаи и прочие плюшки.
Подтверждая слова blind_oracle об эффективности мониторинга только в случае возможности прописывать реакцию на отклонения от нормы, могу сказать, что не только о failover нужно заботится. Вот, например, так выглядит плохое поведение одного роутера Canyon, который генерирует DHCPDISCOVER изо всех своих щенячьих сил. Узенькая полосочка внизу графика — это нормальный ритм работы сетки на 10к хостов.
Подтверждая слова blind_oracle об эффективности мониторинга только в случае возможности прописывать реакцию на отклонения от нормы, могу сказать, что не только о failover нужно заботится. Вот, например, так выглядит плохое поведение одного роутера Canyon, который генерирует DHCPDISCOVER изо всех своих щенячьих сил. Узенькая полосочка внизу графика — это нормальный ритм работы сетки на 10к хостов.
«Наколенных велосипедов» приходится делать очень много, ибо встроенного функционала (SNMP, агенты в ОС) хватает лишь для небольшого круга задач.
Например:
и многое многое другое
Например:
- Мониторинг серверов через IPMI-over-LAN. В заббиксе достаточно давно была поддержка IPMI, но до последнего времени она не поддерживала дискретные сенсоры. Поэтому на базе freeipmi был написан комплекс скриптов в auto-discoverу сенсоров и преферансом
- RAID-контроллеры и их подмножества (физ диски, массивы, дисковые полки с inband-мониторингом, суперконденсаторы, ...) — тоже пришлось писать самому скрипты, которые всё это в нужном формате отдают заббиксу
- Промышленное добро типа кондиционеров через шлюзы RS485-Ethernet
- Всякие линуксовые подсистемы типа DRBD/MDRAID/Pacemaker/SCST/MySQL+Galera
и многое многое другое
Вы не поверите. От безисходности в крупных ынтерпрайсах и не такое увидишь, а как увидишь начинают шевелится волосы в разных местах и срочно хочется развидить.
Используем счетчики iptables с комментарием для легкого парсинга. Шаг 30 секунд для оперативности. Lease time 10 минут.
Microsoft делает службы, и покрывает их счетчиками производительности и WMI классами (а сейчас и обертками Powershell) для управления.
Разрабочикам Open Source стоило бы всегда реализовывать в базе как минимум мониторинг по SNMP, чтобы Linux-адмнистратор не мучался с sed/awk парсингом, а просто подключал очередной сервис к имеющейся системе мониторинга.
Разрабочикам Open Source стоило бы всегда реализовывать в базе как минимум мониторинг по SNMP, чтобы Linux-адмнистратор не мучался с sed/awk парсингом, а просто подключал очередной сервис к имеющейся системе мониторинга.
/me немного плохо в винде ориентируется, можно уточнить?
Вот есть у нас perfmon со счетчиками производительности по dhcp серверу. А добраться то до них как? Через тот же старый добрый snmp?
Вот есть у нас perfmon со счетчиками производительности по dhcp серверу. А добраться то до них как? Через тот же старый добрый snmp?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Построение графиков работы DHCP сервера