vlarkanov

Получилось разобраться. Нужно выгрузить (например, через браузер) самоподписанный сертификат реджистри, положить его в /usr/local/share/ca-certificates под именем docker.companyname.crt и выполнить update-ca-certificates.

Вот так вот.

В общем, всё работает, я сам дурак: нужно было ставить МНОГО запросов в параллели:
ab -n 100 -c 20 https://мой_сайт.ru/*

Тогда всё логируется в error.

В итоге сделал так:
1) загрузил установщик Ubuntu Server в UEFI. Установил Ubuntu на второй диск в деградированный RAID1 из одного диска вместо двух;
2) загрузил существующую систему через Legacy; подмонтировал деградированный рейд в папочу, всё там удалил, рсинкнул туда существующую ОС (с сохранением прав);
3) поправил fstab, зачрутился в примонтированную папку, обновил GRUB;
4) загрузился через UEFI, увидел что перенесённая система работает, добавил в массив первый диск (предварительно создав такие же разделы);
5) скопировал содержимое /boot/efi в efi раздел первого диска. Теперь система грузится с обоих дисков в режиме UEFI;

Итак, разобрался сам. Нам понадобится утилита sysfsutils. Ставим ее из стандартных репозиториев

apt install sysfsutils

Смотрим статус

systool -c fc_host -v | grep port_state
port_state = "Online"
port_state = "Online"

Отлично, порты видны.
Теперь узнаем WWN:

systool -c fc_host -v | grep port_name
port_name = "0x21000024ff3c00c2"
port_name = "0x21000024ff3c00c3"

Вот мы и узнали, что наши Host port identifier'ы:
21:00:00:24:ff:3c:00:c2
21:00:00:24:ff:3c:00:c3

Решил в итоге просто. Удалил визуализации, дэшборды, темплейт. Закомментил в конфиге Logstash, прописал Elasticsearch.

Выполнил

filebeat setup

Установились и шаблон и дешборды и всё что надо. Раскомментил Logstash, закомментил Elasticsearch, запустил Filebeat. Работает.

Походу,

-E output.logstash.enabled=false \
-E output.elasticsearch.hosts=['localhost:9200']

не обрабатываются нормально.

debian-help.ru/articles/nastroika-nfs-servera-debian

Тут и про сервер и про клиент, очень доходчиво.

Итак, что в итоге сделано для успешного переноса Zabbix.
1) На новом сервере развернул Zabbix той же версии.
-скопированы конфиги, алерт-скрипты, внешние скрипты
-"стандартная" база данных развернута на системных HDD, по стандартному пути /var/lib/mysql
2) На старом сервере сделал бекапы через innobackupex, mysqldump.
3) На обоих серверах остановил mysql, файлы из /var/lib/mysql старого сервера скопировал в ту же папку на новом сервере.
4) Запустил на новом сервере mysql. Запустился. Делаю mysql_upgrade - утилита менее чем за минуту проверила все таблицы базы на совместимость с новой версией MariaDB (на старом была 10.0, на новом 10.1). Отлично
5) Перенес SSD из старого сервера в новый, собрал из них RAID1 (на старом сервере HP контроллер, на новом mdadm).
6) Смонтировал RAID в папку (/srv/ssd, можно в любую пустую), скопировал в /srv/ssd/mysql "проверенные" данные из /var/lib/mysql.
7) Очистил /var/lib/mysql, примонтировал туда /srv/ssd/mysql.
6) Запустил mysql - работает.
7) Остановил старый сервер, назначил новому серверу ip старого, чтобы не перенастраивать тысячи zabbix-агентов.
8) PROFIT!

Всем спасибо за советы!

Всем спасибо, поставил Opennebula. Тоже на KVM, тоже с удобным веб-интерфейсом.

Обновился с 2.1.3 до 2.1.7 - пять часов тестирую, проблема пока не проявляется.

Разобрался, повнимательней почитав собственный вопрос:)

Независимо от того какой диск для установки GRUB я выбирал, система почему-то пыталась ставить его на /dev/md, что, разумеется приводило к ошибке. Потому я просто выбрал пункт меню "Ввести вручную" и ввел туда /dev/sdm. После этого установка прошла как положено, система грузится. Вот такая загогулина.

Погуглите ошибку leap second - одним из ее симптомов может быть аномальная загрузка проца.

Ещё вариант: посмотрите как настроен и как функционирует NUMA. Возможно, стоит включить interleave в настройках mysqld_safe (через numactl).

Что с IO? Какова нагрузка на диск? Посмотрите через iotop например.

По параметрам. Кроме мускула на сервере что-то крутится? Если нет, смело выкручивайте
innodb_buffer_pool_size до примерно 70% объема RAM.
innodb_log_file_size - это размера лога транзакций innodb. Чем он больше - тем реже пересоздается этот файл, и тем меньше нагрузка на диск. Но тем дольше восстановление в случае сбоя. 512mb должно хватить.

innodb_flush_log_at_trx_commit = 0 Вы уверены? Поставьте хотя бы 2 - по производительности тож на тож, но безопаснее. А лучше и вовсе 1. Медленно, зато надежно.

query_cache_size = 4096M Куда столько? Помните, что при каждом INSERT\UPDATE этот кеш переписывается. Поставьте 100mb для начала.