Обратился как-то знакомый с вопросом можно ли c Ceph реализовать реплику 1+2.
Было 2 сервера OSD и требовалось сделать хранилище, причём только на запись
(операции чтения не больше 10 процентов, а 90 процентов это запись). В виду
горького раннего опыта с данной репликой и файловым Ceph пытался отговорить его
от этого, но интерес взял своё.
Итак задача звучала так: есть 2xOSD, в каждом 24 HDD диска по 8T и 4 SSD по 400G
Основной задачей было обеспечение надёжности без применения CRUSH Map.
Требовалось:
Ceph 2xOSD + 3MON,
Ceph: Версия не важно но
1 Обязательно файловая
2 Вынос журналов на SSD, то есть 1 SSD на 6 HDD дисков
Железо осмотр:
OSD
все на intel C610/X99
CPU : 2 x Xeon(R) CPU E5-2620 v4 @ 2.10GHz
RAM : 192G DIMM DDR4 M393A4K40BB0-CPB
Video: AST1150 ASPEED Technology, Inc.
HDD: 2xINTEL SSDSC2BA20
LAN : 2 x 1G I210 (ILO + Управление)
LAN : 2 x 82599ES 10-Gigabit SFI/SFP+ Network Connection (на борту)
LAN : 2 x MT27520 Family [ConnectX-3 Pro] 40-Gigabit QFP+ Mellanox Technologies
Внешний JBOD
SAS3008 PCI-Express Fusion-MPT SAS-3
24 x HDD HUH728080AL5204 (HGST) 7452GiB 7200rpm
4 x SDD HUSMM1640ASS204 (HGST) 372GiB
Первое что было сделано это обновлены все биосы и прочее, что могло обновляться
включая HDD: 2xINTEL SSDSC2BA20
установлен дистрибутив Ubuntu 18.04.1 LTS
HDD: 2xINTEL SSDSC2BA20 были объедены в MD зеркало
(бортовой аппаратный райд не помог т.к. в итоге система не видела 2 диска как
единое блочное устройство)
в итоге получилось
1G /boot (MD0)
16G SWAP на каждом диске
170G /
также выделил 3 сервера одинаковых для mon и один сервер для настроек с
которого собственно и буду все поднимать
серверы одинаковые:
ProLiant DL360 G5
CPU: 2xIntel(R) Xeon(R) CPU E5420 @ 2.50GHz
RAM: 8G
HDD: 2x148 на базе аппаратного Smart Array Controller P400i
LAN: 2xNetXtreme II BCM5708 Gigabit Ethernet (Broadcom Limited)
собрав все в зеркало и установил систему
Ceph
Подключаем репозиторий. Раз версия не важна то используем Mimic (13.2.0),
остальных версий под указанный дистрибутив нет.
1. компьютер установщика:
wget -q -O- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add -
echo "deb https://download.ceph.com/debian-mimic/ bionic main" > /etc/apt/sources.list.d/ceph.list
apt update
apt upgrade
apt install ceph-common ceph-deploy
2. добавим ключи с машины инсталлятора, чтобы ходить по ssh без пароля
3. определимся с сетью
в качестве коммутатора у заказчика Mellanox SX1024
1 12x40G + 48x10G что вполне со слов заказчика достаточно на первое время
2 Dlink 36xx для сети 1G и портом 10G на всякий случай для стыковки с мелланоксом
сеть
public-network 10.0.0.0/24
cluster-network 10.200.0.0/24
mon01 10.0.0.1/24
mon02 10.0.0.2/24
mon03 10.0.0.3/24
osd01 10G 10.0.0.4/24
40G 10.200.0.4/24
osd02 10G 10.0.0.5/24
40G 10.200.0.5/24
слепил я и оповестил файлы /etc/hosts этими значениями
Инсталляция
начнём как рекомендуется в документации, с мониторов
1. установим демон точного времени
apt install chrony
на OSD серверах шлюзов не будет, соответственно настроим сразу получение времени с mon01-03
2. Установим мониторы и сразу MGR
ceph-deploy install --mon --release=mimic mon0{1,2,3}
ceph-deploy install --mgr --release=mimic mgr0{1,2,3}
ceph-deploy install --osd --release=mimic osd0{1,2}
3. Создадим кластер
ceph-deploy new --public-network 10.0.0.0/24 mon0{1,2,3}
добавим мониторы
ceph-deploy mon create mon0{1,2,3}
раздадим ключи
ceph-deploy gatherkeys mon0{1,2,3}
добавим в начальный файл конфигурации
mon_allow_pool_delete = true
cluster network = 10.200.0.0/24
osd pool default size = 2
osd pool default min size = 1
osd mkfs options xfs = -f -s size=4096
и раздадим его всем
cp *.keyring ceph.conf /etc/ceph/
добавим mgr
ceph-deploy mgr create mgr0{1,2,3}
раздадим и проверим конфигурацию на всех серверах
и проверим ceph
ceph -s
cluster:
id: 6dae468a-ac29-4cc6-a3e1-7b2a7247eb5b
health: HEALTH_OK
services:
mon: 3 daemons, quorum mon01,mon02,mon03
mgr: mgr01(active), standbys: mgr02, mgr03
Займёмся osd
ssh osd01
прогоним все диски
parted -s /dev/sdj mklabel gpt
почистим диски
/usr/sbin/ceph-volume zap /dev/sdh
................
/usr/sbin/ceph-volume zap /dev/sdo
и повторим то же на OSD02
вернёмся на инсталлиционый сервер и для теста создадим пару OSD с двух OSD серверов
можно ещё раз проделать это с инсталляционного сервера
ceph-deploy disk zap osd01:sdh
ceph-deploy disk zap osd02:sdh
ceph-deploy disk zap osd01:sdi
ceph-deploy disk zap osd02:sdi
/dev/sdh это HDD OSD01
/dev/sdh это HDD OSD02
/dev/sdi это SSD OSD01
/dev/sdi это SSD OSD02
напомним, версия ФАЙЛОВАЯ и журналы на SSD без параметров, создаётся bluestore
ceph-deploy osd create --filestore --data /dev/sdh --journal /dev/sdi osd01
ceph-deploy osd create --filestore --data /dev/sdh --journal /dev/sdi osd02
Убедимся что все верно
ceph-deploy osd list osd01
ceph-deploy osd list osd02
клиент предупредил, что тестировать будет и нужно минимум 4 диска
ну 4 так 4
проделал с остальными тоже самое
в итоге 4 диска
ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 352.22583 root default
-7 176.11292 host osd01
0 hdd 7.27739 osd.0 up 1.00000 1.00000
1 hdd 7.27739 osd.1 up 1.00000 1.00000
2 hdd 7.27739 osd.2 up 1.00000 1.00000
3 hdd 7.27739 osd.3 up 1.00000 1.00000
0 ssd 0.36389 osd.0 up 1.00000 1.00000
1 ssd 0.36389 osd.1 up 1.00000 1.00000
2 ssd 0.36389 osd.2 up 1.00000 1.00000
3 ssd 0.36389 osd.3 up 1.00000 1.00000
-7 176.11292 host osd02
0 hdd 7.27739 osd.0 up 1.00000 1.00000
1 hdd 7.27739 osd.1 up 1.00000 1.00000
2 hdd 7.27739 osd.2 up 1.00000 1.00000
3 hdd 7.27739 osd.3 up 1.00000 1.00000
0 ssd 0.36389 osd.0 up 1.00000 1.00000
1 ssd 0.36389 osd.1 up 1.00000 1.00000
2 ssd 0.36389 osd.2 up 1.00000 1.00000
3 ssd 0.36389 osd.3 up 1.00000 1.00000
Видно что SSD нормально определился
напомню, что проблема с правкой крушмапа осталась в версии до 12.x.x.
далее подготовим pg
ceph osd crush rule create-replicated hdd default host hdd
ceph osd pool create hdd-rbd 512
ceph osd pool set hdd-rbd crush_rule hdd
для тестов подойдёт и не забываем что на SSD у нас журналы и за ними надо следить !!
подготовим для теста RBD
rbd create --size 1T --image-feature layering,exclusive-lock --image hdd-rbd/test
--image-feature именно такие так как будем использовать ядерный модуль, а с
другими параметрами он не цепляется
Дополним
cat /etc/ceph/rbdmap
hdd-rbd/test id=admin,keyring=/etc/ceph/ceph.client.admin.keyring
и примонтируем
rbdmap map
проверим
ls /dev/rbd/hdd-rbd/test
/dev/rbd/hdd-rbd/test
и появилось у нас новое устройство
/dev/rbd0
померим
hdparm -Tt /dev/rbd0
/dev/rbd0:
Timing cached reads: 8226 MB in 2.00 seconds = 4122.93 MB/sec
Timing buffered disk reads: 1636 MB in 3.00 seconds = 545.21 MB/sec
dd if=/dev/zero of=/dev/rbd0 bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 10,0574 s, 107 MB/s
попробуем, что скажет fio
fio --name=writefile --size=1G --filesize=1G --filename=/dev/rbd0 --bs=1M --nrfiles=1 \
--direct=1 --sync=0 --randrepeat=0 --rw=write --refill_buffers --end_fsync=1 --iodepth=200 --ioengine=libaio
writefile: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-
1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=200
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [W(1)][83.3%][r=0KiB/s,w=20.0MiB/s][r=0,w=20 IOPS][eta 00m:02s]
writefile: (groupid=0, jobs=1): err= 0: pid=6404: Thu Aug 9 19:50:56 2018
write: IOPS=109, BW=110MiB/s (115MB/s)(1024MiB/9320msec)
ну и случайное
fio --time_based --name=benchmark --size=1G --runtime=30 --filename=/dev/rbd0 --ioengine=libaio \
--randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=4 \
--rw=randwrite --blocksize=4k --group_reporting
benchmark: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B,
(T) 4096B-4096B, ioengine=libaio, iodepth=128
...
fio-3.1
Starting 4 processes
Jobs: 4 (f=4): [w(4)][100.0%][r=0KiB/s,w=80.2MiB/s][r=0,w=20.5k IOPS][eta 00m:00s]
benchmark: (groupid=0, jobs=4): err= 0: pid=6411: Thu Aug 9 19:53:37 2018
write: IOPS=19.8k, BW=77.2MiB/s (80.9MB/s)(2315MiB/30006msec)
slat (usec): min=4, max=199825, avg=193.15, stdev=1838.51
clat (msec): min=3, max=1348, avg=25.70, stdev=28.44
lat (msec): min=3, max=1349, avg=25.89, stdev=28.54
clat percentiles (msec):
| 1.00th=[ 12], 5.00th=[ 14], 10.00th=[ 16], 20.00th=[ 17],
| 30.00th=[ 19], 40.00th=[ 20], 50.00th=[ 21], 60.00th=[ 22],
| 70.00th=[ 24], 80.00th=[ 26], 90.00th=[ 30], 95.00th=[ 41],
| 99.00th=[ 155], 99.50th=[ 169], 99.90th=[ 363], 99.95th=[ 401],
| 99.99th=[ 827]
bw ( KiB/s): min= 4444, max=26995, per=25.07%, avg=19805.94, stdev=5061.73, samples=240
iops : min= 1111, max= 6748, avg=4951.28, stdev=1265.42, samples=240
lat (msec) : 4=0.01%, 10=0.30%, 20=44.53%, 50=51.12%, 100=1.34%
lat (msec) : 250=2.50%, 500=0.18%, 750=0.01%, 1000=0.01%, 2000=0.01%
cpu : usr=3.38%, sys=5.67%, ctx=75740, majf=0, minf=37
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.1%
issued rwt: total=0,592666,0, short=0,0,0, dropped=0,0,0
latency : target=0, window=0, percentile=100.00%, depth=128
Run status group 0 (all jobs):
WRITE: bw=77.2MiB/s (80.9MB/s), 77.2MiB/s-77.2MiB/s (80.9MB/s-80.9MB/s), io=2315MiB (2428MB), run=30006-30006msec
Disk stats (read/write):
rbd0: ios=0/589859, merge=0/0, ticks=0/3725372, in_queue=3594988, util=100.00%
также любезный Себастьян написал красивые вещи:
https://www.sebastien-han.fr/blog/2012/08/26/ceph-benchmarks/
https://www.sebastien-han.fr/blog/2013/10/03/quick-analysis-of-the-ceph-io-layer/
Кластер нужен на запись, поэтому основные тесты на запись.
Остался доволен и отдал для теста заказчику
Утром след дня заказчик заявил, что я неверно все сделал!!!
???????!!!!!!
захожу и вижу
cluster:
id: 6dae468a-ac29-4cc6-a3e1-7b2a7247eb5b
health: HEALTH_ERR
6 osds down
1 host (6 osds) down
5 scrub errors
Possible data damage: 4 pgs inconsistent
Degraded data redundancy: 2423/4847 objects degraded (50.000%), 2560 pgs degraded, 2560 pgs undersized
clock skew detected on mon.mon03
1/3 mons down, quorum mon01,mon03
services:
mon: 3 daemons, quorum mon01,mon03, out of quorum: mon02
mgr: mgr02(active), standbys: mgr03, mgr01
osd: 12 osds: 6 up, 12 in
ceph health detail
HEALTH_ERR 5 scrub errors; Possible data damage: 4 pgs inconsistent
OSD_SCRUB_ERRORS 5 scrub errors
PG_DAMAGED Possible data damage: 4 pgs inconsistent
pg 1.14 is active+clean+inconsistent, acting [12,34]
pg 1.27b is active+clean+inconsistent, acting [46,20]
pg 1.683 is active+clean+inconsistent, acting [20,34]
pg 1.728 is active+clean+inconsistent, acting [49,6]
ну ладно попробуем восстановить
root@ceph-deploy:~# ceph pg repair 1.728
instructing pg 1.728 on osd.4 to repair
..................
instructing pg 1.14 on osd.2 to repair
Тем временем задаю вопросы. Выяснилось, заказчик взял и переставил 2 ssd и 2
HDD с другого сервера, а затем отключил 1 OSD.
Вспомнив, что на SSD журналы слал думать что можно сделать.
Заодно спросил чем 3-й монитор не угодил? На что получил ответ, что все это для
теста и нужно проверить все.
Так похоже что FileStore мало подходит
Пробуем с Blustore
Blustore оказался более пригоден и более живуч
для исправления ошибок написал скрипт
cat /root/rep.sh
#!/bin/sh
/usr/bin/ceph health detail | grep active+clean+inconsistent | awk '{ print $2 }' | while read a; do /usr/bin/ceph pg repair $a ; done
который стартую по крону
*/10 * * * * /root/rep.sh
|