тогда стоит построить графики, например по средней задержке до ваших комутаторов, и условному сайту в интернете. А после, если до ваших коммутаторов - будет всё нормально - то обращаться к провайдеру. Если провайдер крупный, можно настоять (попросить) на том чтобы он завернул ваш трафик по другому BGP маршруту.
1.как регулярно происходят проблемы? в том плане нет ли в кроне какой-то задачи которая может влиять на сеть?
2. на Ubuntu можно посмотреть кольцевой буфер сетевых карт и выкрутить его на максимум
ControlMaster - похоже используется сокет установленного соединения.
пока сокет не умрёт, ансибл продолжит ходить по нему даже с неправильным паролем.
ControlPersist =60 т.е. минута
1. gxneur - не стоит? похоже на автоматически переключатель - когда он глючит - могут быть подобные проблемы. и не обязательно он переключает раскладку, он может выкидывать в консоль, то что было в буфере
2. второй вариант - залипание клавиш
для konsole - можно попробовать изменить тип привязки клавиш. поставить к примеру linux (по умолчанию как в дистрибутиве)
без информации что отвечает каждый forwarder во время проблем, можно только гадать
попробуйте собрать эту информацию.
Есть серверы, которые по умолчанию используют наш DNS в качестве основного.
сервера в локальной сети? если да, то можно настроить отдельную зону view - которые будут содержать адреса только локальной сети, и отдавать их если запрос придёт из LAN.
если диски в рэйде, тогда вообще не понятно в чём проблема, если зеркало, добавляются новые разделы в него, а потом отстрелить старый из рэйда
/boot обычно не добавляется в рэйд, как минимум если рэйд софтовый - то это обычный раздел, который должен быть виден UEFI
|Нужен ли EFI-раздел?
зависит от того, есть ли он сейчас. если есть, то да нужен
количество разделов должно быть один в один.
в 3 пункте, надо добавить ещё - проверить fstab - чтобы верно были указаны точки монтирования
|Обязательно ли он должен быть в начале диска?
не уверен. скорее всего нет, главное чтобы он был, и имел соответствующую метку. но утверждать не буду.
список меток можно посмотреть
проверить сервер: как минимум пингануть его с разнных мест - со своего компьютера, с компьютера коллеги, или через один из многих веб сервисов в интернете.
сервер наверняка отвечал за какой-то сервис, проверить доступность сервиса на порту
через telnet:
telnet IP:Port
или nc:
nc -zv ip port
если сервисы не отвечают - значит завис полностью сервер.
если отвечают, то возможно сработала блокировка - фаервол или fail2ban (к примеру)
после проверок выбирать дальнейшие действия, или ждать пока снимется блокировка - неизвестно сколько, или искать логин/пароль для админской панели, где будет доступна консоль.
судя по аптайму сервера не падали, а был не доступен сервис или сеть. в 6 утра могла быть ротация логов, с перезапуском httpd
смотрите логи /var/log/messages, /var/log/cron
да, возможно это было бы верным решением. однако в копилку для поиска других вариантов упало ещё и прожорливость связки.
Chronograf пока видится отличным вариантом