Munin, NTP и IPv6

Такая себе заметка на тему…

Давно, в принципе, на хостах на сервере раскидан munin-node, строятся графики и все такое. Разве что местами не строились графики для сдвига ntp относительно мирового времени. Но график некритичный, так что не обращал внимания. Сейчас решил копнуть и найти разницу между хостами.

Разница в /etc/hosts – в тех случаях, где график был, не было записи ::1 localhost и обращение на локальный ntpq шло исключительно через ipv4. А вот запрос по ipv6 вешался и данные не отдавались. Может, конечно, удаление localhost для ipv6 не вполне корректный фикс, но – работает.

Снова немного iptables’а, на сей раз со вкусом IPv6

Еще один косяк словил при непродуманной работе с iptables’ом. В interfaces у меня описан 6to4-адрес – думаю в будущем использовать ipv6 на хостах, но пока повесил его только на внешний интерфейс сервера.

Глянув снаружи на адрес, увидел, что службы NFS-сервера теперь прекрасно видятся с внешнего мира. Решил это запретить через ip6tables -P INPUT DROP. Сделал, проверил – все ок, лег спать.

Наутро заметил, что в munin с dom0 один из графиков оборвался – график сдвига времени в ntp относительно мирового.

Что произошло: все осталось работать, так как работает через ipv4 и там правила корректно прописаны. Плагин ntp_kernel_pll_off дергает ntpq, который пытается обратиться к местному ntpd прежде всего по ipv6-адресу, видя, что тот слушает и ipv6-сеть. В итоге обламывается, так как политика для INPUT подразумевает отброс вообще любого входящего трафика, в том числе и для localhost’а, если не задано другое.

В общем, надо быстрее осваивать IPv6 и уже корректно оформлять все правила с учетом двух стеков 🙂

Пофиксил глючащий DHCP на сервере

(На самом деле нет) (с)

Собственно, сам по себе DHCP не глючил, путаница возникла из-за особенностей правил iptables. Я получал IP-адрес устройством один раз, а потом DHCP-сервер (поставил udhcpd) переставал откликаться на запросы. Грешил на udhcpd, думал ставить полноценную версию; временно использовал Tp-link 6020 как DHCP-сервер и так далее. Проблема оказалась немного в другом месте 🙂

Читать далее Пофиксил глючащий DHCP на сервере

Потребление в серверной

Заметка по потреблению нового железа:

  • Примерно 32W уходит сейчас на полностью погашенной UPS’ке на заряд аккумуляторов. Почему так много – не знаю; на батареях 27.2V – т.е., заряд на 100%
  • При включении UPS потребление 34.2W – т.е., собственное потребление UPS примерно 2.2W
  • При подключении блока питания от сервера, который не подключен к серверу, потребление возрастает до 35.3W – т.е., блок сам по себе потребляет около 1W. Не сильно хороший КПД холостого хода, но уж как есть.
  • Свич Tp-link TL-SG1016PE с подключенными к нему Xiaomi Mi Wifi 3G и GPON-модемом – 52.3 по ваттметру – т.е., 17W на все. При этом устройства, подключенные к PoE, судя по админке, потребляют в сумме 6.4W – 2.3W на модем и 4.1W на Xiaomi – т.е., собственное потребление свича около 10.5W. Примерно сходится с тем, что мерял на холостом ходу – там было 9.5W без подключенных кабелей и ближе к 10 при подключении какого-то устройства.
  • Вместе с сервером на базе Gigabyte j4005n d2p, 8 ГБ DDR4 и 2 HDD на 1 ТБ – Hitachi HTS721010A9E630 – после загрузки ваттметр показывает 65-66W, изредка просаживаясь до 64.5. Итого потребление сервера порядка 13W.

Следовательно, критичной нагрузки у нас только на 10.5 (свич) + 13 (сервер) + 2.3 (модем) = 25.8W + 4.1 (wifi-точка) = 30W

Восстановление Biostar H61B

Пришлось тут по случаю помогать товарищу восстанавливать материнскую плату Biostar H61B. Возникла проблема с BIOS’ом из-за использования pci-e-хаба – уж не знаю, что там накосячили в BIOS’е разработчики в Biostar’е, но при попытке воткнуть 7-ю видеокарту через хаб в материнку BIOS окирпичивался и материнка переставала запускаться; сброс не помогал. Проблема популярная и, хоть сам не сталкивался, уже читал про это в Интернете ранее.

Читать далее Восстановление Biostar H61B

Впечатления о Tp-link TL-SG1016PE

Как уже упоминал ранее, купил себе новый управляемый свич на 16 портов – Tp-link TL-SG1016PE. Старого TL-SG2008 уже по портам хватало впритык с учетом увеличившегося парка машин (да и то еще не все подключено), а когда добавлю камеры наблюдения, то и вовсе портов не будет хватать.

Читать далее Впечатления о Tp-link TL-SG1016PE

Открыл для себя “оптимизаторы нагрузки”

Сабж. В “Эпицентре” при покупке всякого-разного для щитка в отделе электротоваров заметил интересный девайс – нечто, похожее на разветвитель на 2 розетки.

Ценника не было, но на упаковке прочитал краткое описание. Устройство оказалось “умным”: могло коммутировать одну из нагрузок в то время, когда другая нагрузка не работала. Как пример – бойлер и стиральная машина, подключенные в одну розетку. Штатно работает бойлер, но если включилась стиралка – бойлер отключается на время ее работы. В целом, достаточно полезный девайс при жестком ограничении по мощности (спасибо “Облэнерго”), недостаточно толстой проводке или по каким-то внешним причинам (например, сильные просадки сети без отключения автомата при большой потребляемой мощности – что, в принципе, родственно варианту с тонкой проводкой, но в глобальном масштабе).

Читать далее Открыл для себя “оптимизаторы нагрузки”

Еще немного о щитке для серверной

Из нового для себя – обзавелся коммутатором фаз. В доме 3 фазы, но сеть бывает нестабильна; возможно отключение одной из фаз из-за реле напряжения в главном щитке в силу кратковременных просадок. Ну или по любой другой причине. Данный девайс по мере сил решает проблему.

Читать далее Еще немного о щитке для серверной

Перешел на NFLOG в iptables

Решил добить проблему спама iptables’ом отброшенными пакетами системных логов. Логи сами по себе полезны (правда, стоит провести реорганизацию), но разрастаются до совсем уж неприличных размеров.

Читать далее Перешел на NFLOG в iptables