Замена выпавшего диска в Ceph:Jewel

Для начала надо удалить диск с кластера.

На ноде управления исполняем:

ceph osd out ID

Где ID это номер osd мертвого диска.

На самой ноде с osd исполняем:

systemctl stop ceph-osd@ID

И на головной ноде полностью выводим osd из кластера:

ceph osd crush remove osd.ID
ceph auth del osd.ID
ceph osd rm ID

Теперь выключаем сервер, изымаем диск и вводим новый.

Смотрим привязки дисков и определяем где лежат журналы. На ноде с osd исполняем:

ceph-disk list | grep journal

Так мы увидим какой журнал подключен к какому диску.

Удаляем партицию с журналом с диска с журналами.

parted /dev/диск_с_журналом rm номер_партиции

Заводим диск в кластер.

Замечание: после создания новой ceph-osd номер партиции журнала будет не прежним а больше на 1 самого большого номера на диске с журналом. То есть, если на диске с журналами было 10 партиций, мы удаляем например 1-ю, то новая партиция будет на месте 1-й партиции но с номером 11 (появится дырка в нумерации разделов).

Замечание: также обнаружится, что вывод команд ceph osd tree и ceph osd df tree теряет сортировку. На самом деле там сортировка происходит по порядку создания osd-шек и вывод группируется по серверам.

Чтобы номер osd совпадал с тем, который у него был, нумерация должна быть сквозной и непрерывной, если у нас есть дырки в нумерации, то на момент ввода диска в кластер надо их закрыть. То есть сделать липовые osd:

ceph osd create $ID

Потом надо будет их удалить!

ceph osd rm $ID

Далее, на новом диске должна быть partition table типа gpt.

parted /dev/диск_с_данными mklabel gpt

Теперь можно создавать новый ceph-osd и заводить его в кластер.

Замечание: после создания osd-шка сразу начнёт заходить в кластер и начнётся синк. Поэтому желательно после ввода osd поставить ей reweight 0 и постепенно повышать. Так нагрузка на кластер будет минимальной:

ceph osd reweight $ID 0

С головной ноды запускаем (он сам создаст партицию на диске с журналом):

ceph-deploy osd prepare нода:/dev/диск_с_данными:/dev/диск_с_журналом

Все! Мы молодцы, мертвый диск заменен!

Connectivity issues in part of our network in SIN

We experienced connectivity issues in part of our network in our SIN-10 and SIN-11 data centers between 09:25 and 11:35 CEST due to another provider connected to Equinix SG1 that started announcing all the routes on the Internet. Part of the traffic to our network in SIN was passing through their network and you might have experienced increased latency and packet loss during that time. We stopped advertising our prefixes to that IX and traffic resumed as normal.

Читать дальше →