Hetzner — IT Blog

Как я делал заявку в Hetzner на замену диска в рейде

Уже довольно часто писал заяви в Hetzner на замену дисков в рейде и в этой статье опишу один из случаев.

И так, однажды утром, после выпадения диска из рейда, mdadm прислал мне сообщение на email.
Читать далее «Как я делал заявку в Hetzner на замену диска в рейде»

Обновление ядра Linux на серверах Hetzner

Понадобилось однажды обновить ядро CentOS на сервере в Hetzner который проработал без перезагрузки около 2 лет.

Посмотрел различную информацию о системе, версиях установленных ядрах и запущенном ядре:

lsb_release -a
uname -r
uname -a
cat /proc/version
sudo rpm -q kernel
ls /boot | grep vmlinuz

Обновил ядро:

yum -y update

Перезагрузил сервер используя ссылку в cPanel https://example.com:2087/scripts/dialog?dialog=reboot

Можно также командой:

reboot

После ухода на перезагрузку сервер не запустился, я сразу же сделал заявку в техническую поддержку через панель https://robot.your-server.de.
Техническая поддержка отреагировала в течении двух минут, как они сообщили, сервер не отвечал на нажатия клавиш, был черный экран, после физического выключения и включения он успешно запустился.
Вот такие бывают случаи перезагрузки, нужно быть готовым ко всему.
При следующих перезагрузках зависание больше не повторялось.

Настройка Reverse DNS (PTR) в Hetzner

Настроить обратную DNS запись (PTR) для Hetzner сервера можно в панели управления robot.your-server.de

Решение проблемы с выпавшими дисками mdadm

Получил сегодня от одного из серверов на Hetzner три email сообщения с информацией о рейдах md0, md1, md2:

DegradedArray event on /dev/md/0:example.com
This is an automatically generated mail message from mdadm
running on example.com
A DegradedArray event had been detected on md device /dev/md/0.
Faithfully yours, etc.
P.S. The /proc/mdstat file currently contains the following:
Personalities : [raid6] [raid5] [raid4] [raid1]
md2 : active raid6 sdb3[1] sdd3[3]
208218112 blocks super 1.0 level 6, 512k chunk, algorithm 2 [4/2] [_U_U]
md1 : active raid1 sdb2[1] sdd2[3]
524224 blocks super 1.0 [4/2] [_U_U]
md0 : active raid1 sdb1[1] sdd1[3]
12582784 blocks super 1.0 [4/2] [_U_U]
unused devices:

Посмотрел информацию о RAID и дисках:

cat /proc/mdstat
cat /proc/partitions
mdadm --detail /dev/md0
mdadm --detail /dev/md1
mdadm --detail /dev/md2
fdisk -l | grep '/dev/sd'
fdisk -l | less

Собрался отправить тикет в техподдержку и запланировать замену выпавших SSD дисков.
Записал SMART информацию о выпавших дисках в файлы, там же был их серийный номер:

smartctl -x /dev/sda > sda.log
smartctl -x /dev/sdc > sdc.log

Удалить диски из рейда если что можно так:

mdadm /dev/md0 -r /dev/sda1
mdadm /dev/md1 -r /dev/sda2
mdadm /dev/md2 -r /dev/sda3

mdadm /dev/md0 -r /dev/sdc1
mdadm /dev/md1 -r /dev/sdc2
mdadm /dev/md2 -r /dev/sdc3

Если какой-то раздел диска отображается как рабочий, а диск нужно извлечь, то сначала помечаем раздел не рабочим и потом удаляем, например если /dev/sda1, /dev/sda2 выпали, а /dev/sda3 работает:

mdadm /dev/md0 -f /dev/sda3
mdadm /dev/md0 -r /dev/sda3

В моем случае, посмотрев информацию о выпавших дисках обнаружил что они целые и рабочие, даже лучше активных.

Посмотрел разделы дисков:

fdisk /dev/sda
p
q
fdisk /dev/sdc
p
q

Они были размечены одинаково как и прежде:

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00015e3f
Device Boot Start End Blocks Id System
/dev/sda1 1 1567 12582912+ fd Linux raid autodetect
/dev/sda2 1567 1633 524288+ fd Linux raid autodetect
/dev/sda3 1633 14594 104109528+ fd Linux raid autodetect

Поэтому поочередно дождавшись синхронизации каждого вернул эти диски обратно в рейд:

mdadm /dev/md0 -a /dev/sda1
mdadm /dev/md1 -a /dev/sda2
mdadm /dev/md2 -a /dev/sda3

mdadm /dev/md0 -a /dev/sdc1
mdadm /dev/md1 -a /dev/sdc2
mdadm /dev/md2 -a /dev/sdc3

По окончании команда cat /proc/mdstat уже отображалась с [UUUU].

Если диски заменили новыми, то их нужно разбить аналогично установленным.
Пример разметки диска /dev/sdb аналогично /dev/sda с MBR:

sfdisk -d /dev/sda | sfdisk --force /dev/sdb

Пример разметки /dev/sdb с GTP и назначения диску случайного UUID:

sgdisk -R /dev/sdb /dev/sda
sgdisk -G /dev/sdb

Также на новоустановленный диск необходимо установить загрузчик:

grub-install --version
grub-install /dev/sdb
update-grub

Либо через меню grub (hd0 это /dev/sda, hd0,1 — /dev/sda2):

cat /boot/grub/device.map
grub
device (hd0) /dev/sda
root (hd0,1)
setup (hd0)
quit

Если установка grub выполняется из загрузочного диска, то нужно посмотреть список разделов и выполнить монтирование, например если RAID не используется:

ls /dev/[hsv]d[a-z]*[0-9]*
mount /dev/sda3 /mnt

Если используется программный RAID:

ls /dev/md*
mount /dev/md2 /mnt

Либо LVM:

ls /dev/mapper/*
mount /dev/mapper/vg0-root /mnt

И выполнить chroot:

chroot-prepare /mnt
chroot /mnt

После монтирования можно восстанавливать GRUB как я писал выше.

Настройка места для резервных копий Hetzner.de

На тесте вошел на https://robot.your-server.de/, открыл Main functions — Servers, выбрал сервер и во вкладке Backup активировал бесплатные 100GB, так как для серверов стоимостью 39€ или более это место выделялось бесплатно.
Активировал WebDAV чтобы протестировать, samba было уже активировано, также можно подключаться по FTP, FTPS, SFTP и SCP используя имя пользователя и пароль, через SFTP/SCP можно также подключаться по ключу.
Скорость передачи данных на сервер резервного копирования зависит от количества подключенных пользователей и их трафика.
При подключении следует использовать доменное имя, например USER.your-backup.de, так как IP адрес может меняться.
Также нельзя создать директории /etc и /lib на месте для резервных копий.

На примере в Ubuntu Server смонтирую место для резервных копий через SAMBA/CIFS.
Установим необходимые утилиты и создадим директорию в которую будем монтировать:

sudo apt install cifs-utils
sudo mkdir /backup

Временно смонтировать место можно командой:

sudo mount.cifs -o user=USER,pass=PASSWORD //USER.your-backup.de/backup /backup

Для автоматического монтирования после перезапуска системы добавим в файл /etc/fstab следующую строку:

//USER.your-backup.de/backup /backup   cifs  iocharset=utf8,rw,credentials=/etc/backup-credentials.txt,uid=SYSTEM_USER,gid=SYSTEM_GROUP,file_mode=0660,dir_mode=0770 0 0

Открыть файл можно например текстовым редактором nano (CTRL+X для выхода, y/n для сохранения или отмены изменений):

sudo nano /etc/fstab

А в файл /etc/backup-credentials.txt добавим следующие строки:

username=USER
password=PASSWORD

Установим права только для владельца файла в целях безопасности:

sudo chmod 600 /etc/backup-credentials.txt

Если используется операционная система Windows, то нужно создать системного пользователя с такими же логином и паролем как у места для резервных копий.

Теперь для теста подключусь через WebDAV.
Установим необходимые утилиты и создадим директорию в которую будем монтировать:

sudo apt install davfs2
sudo mkdir /backup

В CentOS так:

yum install davfs2
mkdir /backup

Временно смонтировать через WebDAV место можно командой:

sudo mount -t davfs https://USER.your-backup.de /backup

Для автоматического монтирования после перезапуска системы добавим в файл /etc/fstab следующую строку:

https://USER.your-backup.de /backup davfs rw,uid=SYSTEM_USER,gid=SYSTEM_GROUP,file_mode=0660,dir_mode=0770 0 0

А в файл /etc/davfs2/secrets следующую строку:

https://USER.your-backup.de USER PASSWORD

На этом все, в моем случае можно сохранять резервные копии в директорию /backup.

Понижение приоритета IPv6

Понадобилось однажды понизить приоритет IPv6 на одном Ubuntu сервере в Hetzner.de, так как сеть IPv6 работала нестабильно, некоторые хосты били периодически недоступны по IPv6, появлялись задержки и т.д.