Обратился как-то знакомый с вопросом можно ли 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/X99CPU : 2 x Xeon(R) CPU E5-2620 v4 @ 2.10GHz
RAM : 192G DIMM DDR4 M393A4K40BB0-CPB
Video: AST1150 ASPEED Technology, Inc.
HDD: 2xINTEL SSDSC2BA20LAN : 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
Внешний JBODSAS3008 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-deploy2. добавим ключи с машины инсталлятора, чтобы ходить по ssh без пароля
3. определимся с сетью
в качеcтве коммутатора у заказчика Mellanox SX1024
1 12x40G + 48x10G что вполне со слов заказчика достаточно на первое время
2 Dlink 36xx для сети 1G и портом 10G на всякий случай для стыковки с мелланоксом
сетьpublic-network 10.0.0.0/24
cluster-network 10.200.0.0/24mon01 10.0.0.1/24
mon02 10.0.0.2/24
mon03 10.0.0.3/24osd01 10G 10.0.0.4/24
40G 10.200.0.4/24osd02 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}
раздадим и проверим конфигурацию на всех серверах
и проверим cephceph -s
cluster:
id: 6dae468a-ac29-4cc6-a3e1-7b2a7247eb5b
health: HEALTH_OKservices:
mon: 3 daemons, quorum mon01,mon02,mon03
mgr: mgr01(active), standbys: mgr02, mgr03
** Займёмся osdssh 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:sdhceph-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 osd010 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.000000 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.000000 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.
далее подготовим pgceph 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/secdd 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
попробуем, что скажет fiofio --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=libaiowritefile: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-
1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=200fio-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_reportingbenchmark: (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=128Run 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-30006msecDisk 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-.../
Кластер нужен на запись, поэтому основные тесты на запись.
Остался доволен и отдал для теста заказчикуУтром след дня заказчик заявил, что я неверно все сделал!!!
???????!!!!!!захожу и вижу
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,mon03services:
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 detailHEALTH_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
URL:
Обсуждается: https://www.opennet.ru/tips/info/3083.shtml
> Выяснилось, заказчик взял и переставил 2 ssd и 2 HDD с другого сервера, а затем отключил 1 OSD.Я правильно понимаю что это был тест "Пьяная обезьянка порезвилась в серверной". Ок. Заказчик молодец.
>Так похоже что FileStore мало подходит
FileStore тест на пьяную обезьянку не прошел? Можно объяснить подробнее в чем проблемма?
>Пробуем с Blustore
>Blustore оказался более пригоден и более живучBlueStore прошел тест? Где подробности?
для Блястора допишу
Видать не все влезло
Кстати аноним !
Интересно послушать Ваш опыт в данном распределенном хранилище !
И дай Вам счастье чтоб заказчик был всегда адекватный !
перед awk не надо grep. Денег дали-то? Чем закончилось?
мне же не все события нужны а именно эти
Денег пока не дали
ушел на Блюстор и заказчик затих ! Видимо сломать не получилось.
в начале нулевых именно здесь на опеннете за связки греп|awk grep|sed cat|grep и тп и тд на полном серьёзе один неанонимный уважаемый комментатор говорил, что для него это как жёлтая карточка: первый раз он разраба предупредит, на второе использование будут кадровые решения. Понимаете, вы используете базовые "кирпичики" юникс в правильном ключе, именно комбинируя маленькие утилиты - но в данном случае сами утилиты достаточно мощны, чтобы выполнить фильтрацию без использования греп.
> в начале нулевых именно здесь на опеннете за связки греп|awk grep|sed cat|grep
> и тп и тд на полном серьёзе один неанонимный уважаемый комментатор
> говорил, что для него это как жёлтая карточка: первый раз он
> разраба предупредит, на второе использование будут кадровые решения. Понимаете, вы используете
> базовые "кирпичики" юникс в правильном ключе, именно комбинируя маленькие утилиты -
> но в данном случае сами утилиты достаточно мощны, чтобы выполнить фильтрацию
> без использования греп.Логично . Учту на будущее.
Если есть решение проще то опубликуйте
собственно:
ceph pg dump_stuck inconsistent -f json 2>/dev/null | jq -r '.[]?.pgid?' | xargs -L1 -r ceph pg repairТут во первых сразу дамп pg нужного статуса, во вторых передаётся в сериализованном виде, и скорее всего это не придется переписывать когда вывод в очередной версии поменяется
А вообще запихивать такое в крон не лучшая идея:
http://lists.ceph.com/pipermail/ceph-users-ceph.com/2016-Jun...
А если очень уж хочется, можно поковырять параметр osd_scrub_auto_repair и osd_scrub_auto_repair_num_errors
#~/bin/sh
CEPH=/usr/bin/ceph
$CEPH health detail |
grep -oP "(?<=pg )(.+)(?=is active\+clean\+inconsistent)" |
xargs -l $CEPH pg repairПодотритесь вместе со своим гуру.
> #~/bin/sh
> CEPH=/usr/bin/ceph
> $CEPH health detail |
> grep -oP "(?<=pg )(.+)(?=is active\+clean\+inconsistent)" |
> xargs -l $CEPH pg repair
> Подотритесь вместе со своим гуру.Хорошее использование регулярки, претензия на использование двух утилит там, где достаточно одной снимается, но врядли бы замена директивы "распечатай столбец номер два" на регулярку с префиксом "до столбца вот это" и постфиксом "а после столбца вот это" прошла любое кодеревью. Кто-нибудь откаменил "что, если требуемый столбец сменился?" и после этого зеленую кнопку нажать духу не хватило б.
>[оверквотинг удален]
>> $CEPH health detail |
>> grep -oP "(?<=pg )(.+)(?=is active\+clean\+inconsistent)" |
>> xargs -l $CEPH pg repair
>> Подотритесь вместе со своим гуру.
> Хорошее использование регулярки, претензия на использование двух утилит там, где достаточно
> одной снимается, но врядли бы замена директивы "распечатай столбец номер два"
> на регулярку с префиксом "до столбца вот это" и постфиксом "а
> после столбца вот это" прошла любое кодеревью. Кто-нибудь откаменил "что, если
> требуемый столбец сменился?" и после этого зеленую кнопку нажать духу не
> хватило б.Да ну. Где так серьезно пишут на шелле, что даже с кодревью? Шепните название фирмы. Лидер отрасли, не иначе.
Смена формата вывода внутри мажорной версии софта обычно не происходит. Перед обновлением на проде админ это проверит и перепишет регулярку.
Информация об этом скрипте уже документирована.К чему это брюзжание?
Переписывание греп + авк на чистый авк - это вкусовщина чистейшая.
Скрипт делает то, что нужно? Делает. Будет ли он редактироваться в обозримом будущем? Нет. Работает быстро? Да. Какая разница, что внутри? Никакой.Идите пристаньте к бэкэнд-программерам с их ORM и прочими гиперабстракциями. Отстаньте от админов.
>[оверквотинг удален]
>>> xargs -l $CEPH pg repair
>>> Подотритесь вместе со своим гуру.
>> Хорошее использование регулярки, претензия на использование двух утилит там, где достаточно
>> одной снимается, но врядли бы замена директивы "распечатай столбец номер два"
>> на регулярку с префиксом "до столбца вот это" и постфиксом "а
>> после столбца вот это" прошла любое кодеревью. Кто-нибудь откаменил "что, если
>> требуемый столбец сменился?" и после этого зеленую кнопку нажать духу не
>> хватило б.
> Да ну. Где так серьезно пишут на шелле, что даже с кодревью?
> Шепните название фирмы. Лидер отрасли, не иначе.Поверьте, писать на шелле с кодревью - это во многих компаниях, которые себя уважают и продают свои решения, особенно если их потом за это могут взять ...
Знаю сходу пяток таких контор, причем кол-во людей работающих в каждой, превышает 1К человек и они действительно проходят кодревью на любые вещи, которые пишут.
> Смена формата вывода внутри мажорной версии софта обычно не происходит. Перед обновлением
> на проде админ это проверит и перепишет регулярку.
> Информация об этом скрипте уже документирована.Вы не дооцениваете человеческую лень. Лучше уж скрипт будет вываливаться и отправлять алерты, чем работать не так как запланировано.
> К чему это брюзжание?
> Переписывание греп + авк на чистый авк - это вкусовщина чистейшая.
> Скрипт делает то, что нужно? Делает. Будет ли он редактироваться в обозримом
> будущем? Нет. Работает быстро? Да. Какая разница, что внутри? Никакой."И так сойдет" (с) какой то мультфильм, ага.
> Идите пристаньте к бэкэнд-программерам с их ORM и прочими гиперабстракциями. Отстаньте
> от админов.
Наверно не про _нашу_ страну речь. Бюрократическая техноутопия (:>"И так сойдет" (с) какой то мультфильм, ага.
Общему уровню решения соответствует вполне. Сойдет.
Если по уму делать, то надо взять вывод ceph pg dump. Ну хотя бы.
Вот о чем надо было писать. Остальное - треп.
/usr/bin/ceph health detail | awk '/active+clean+inconsistent/ {run="/usr/bin/ceph pg repair "$2; print run; system(run)}'
так ж быстрее. да.
> /usr/bin/ceph health detail | awk '/active+clean+inconsistent/ {run="/usr/bin/ceph
> pg repair "$2; print run; system(run)}'
> так ж быстрее. да.Вряд ли быстрее, но красивенько.
К каждому коммиту должен быть убедительный рассказ, зачем это сделано, что именно сделано, какие варианты были, кто одобрил. Кто был против этого кода, по какой причине, как его задобрили. кодеревью наше всё.
потом, по поводу баттла awk vs grep regex. Представим две команды, в моей эту задачу решает крутой перловод, в другой какой-то васян использовал авк. И тут перед обедом прилетает задача "брать инфо из другого столбца", и васян идет обедать, ты же яростно анализируешь содержимое строчки, тестишь, материшься втихую, и немного уже жалеешь, что васяна забрали соседи.
Перловик на авк может вообще не включая голову. Максимум полминуты ман прочитать.
Ну греп-то и легче и лучше.
Греп-кун
Ни хрена. Собственно, первая реакция при виде этих закорюк - как раз расчехлить привычный перл и не заниматься фигнёй.Вообще, если шелловый скрипт получается длинее десятка строк или имеет хоть как-то нетривиальную логику (по факту - что-то большее, чем установка переменных и вызов команды с ними) - надо сразу бежать на нормальные скрипты. Питон, перл, да хоть js - что угодно, но подальше от этой слабоподдерживаемой мути. Применение awk/sed - один из признаков тоже. Тут не крутостью шелл-фу надо меряться, а брать что-то человеческое.
расчехлиться про яваскрипт именно здесь это сродни камингауту, да и питон туда же. Именно эту задачу на питоне решать сравнительно нечитаемо и неподдерживаемо,с внесением зависимостей и тп и тд. Не говоря уже о запуске с задействием яваскрипта. Мгновенная дисквалификация.
Я просто оттолкнулся от того, что скрипт запускается из крона без перевода вывода в /dev/null, соответственно при попадании в этот шаблон, рут будет получать уведомления на почту, о том что что либо произошло.
Использование переменных в system - это не секурно уже лет 20, да и нафига? если следующий форк дополнительного процесса не завершит выполнение скрипта!?
Торопится собственно некуда
Задача развесить флаги востановления и по возможности понять от чего они , а не с играть в стрелялку. Спеши медленно и практично.
А вот мне, кажется, чем более читаем и понятен код, тем лучше. Уж лучше иметь много sed | grep | awk | cut и прочее, чем один скажем awk но с совершенно не читаемой кашой ' { ; и прочее.
В случае если случится ЧП и код будет оформлен как awk, sed, cut, grep - большинство админов быстрее разберется в чем проблема, в отличии от ситуации, когда будет один awk но с магическими заклинаниями.
Админы они такие - сегодня работают, завтра нет, и у каждого нового свои взгляды на то, как и что правильно :)
Имхо конечно.
> А вот мне, кажется, чем более читаем и понятен код, тем лучше.
> Уж лучше иметь много sed | grep | awk | cut
> и прочее, чем один скажем awk но с совершенно не читаемой
> кашой ' { ; и прочее.
> В случае если случится ЧП и код будет оформлен как awk, sed,
> cut, grep - большинство админов быстрее разберется в чем проблема, в
> отличии от ситуации, когда будет один awk но с магическими заклинаниями.
> Админы они такие - сегодня работают, завтра нет, и у каждого нового
> свои взгляды на то, как и что правильно :)
> Имхо конечно.Твоё право использовать "большинство админов", а не "меньшинство админов" особенно если не понимать их различия)))
ну а swap то зачем 16 GB, ещё и на каждом диске? те представляешь себе что если твой сервер действительно начнём им пользоваться хотяб на 5%?
Лучше, чтобы ООМ пришел рандомные osd килять?Swap только дает немного времени при возниктовении проблем с памятью
настоящая беда не в OOM, а лишь в том что ты не удосужился прочесть ни статью, ни мой комментарий. попытаюсь объяснитьсерверы позиционированы на использование Ceph, который представляет собой обычное user-space приложение, т.е. если Ceph не хватает памяти она залезет в swap (19 GB). надо объяснять потери производительности что возникнут при этом у и без того медленной Ceph? прочти статью ещё раз и попытайся найти хотяб 1-2 строчки настроек sysctl которые порой могли бы помочь. правильно - их нет. значит получаем Ceph и file system cache периодически залазят в swap размером до 19GB. даже при SSD-дисках, swap подобного размера вместо тюнинга vm - ЗЛО!
Представьте себе, да. Иначе лаги начнутся (и не закончатся) во всем кластере. А так кильнул osd, сделал ребаланс и живи дальше.
отчет об аварии у digital ocean говорит о том, что swap для ceph нужен обязательно
Ссылкой на отчёт поделитесь
да ... будет прикольно
может к тому времени заплатят ?
> Основной задачей было обеспечение надёжности без применения CRUSH Map.Расскажите пожалуйста как Ceph может работать без CRUSH map. Этот алгоритм лежит в центре его вселенной распределения данных.
Кстати, вы там команды ниже выдаёте из раздела http://docs.ceph.com/docs/mimic/rados/operations/crush-map/ - адрес его нам как бы намекает.
Или я чего-то глубоко не знаю? Тогда хочу пруфлинк на ознакомление.> Ceph: Версия не важно но
Очень смелое заявление, особенно для человека который опирается на обработку выхлопа утилит. Который например очень сильно поменялся от jewel к luminous.
> то есть 1 SSD на 6 HDD дисков
Тоже так себе решение. Официально рекомендовано не более 4х на 1 диск. Иначе, можно запросто получить ужасающую производительность, настолько, что проще жить без SSD сделав журнал на тех же дисках что и данные.
И второе - вы же понимаете что в случае отказа 1 SSD из имеющихся 4х вы получаете превращение в тыкву четверти дисков с данными? Т.е. нужен экстренный recovery дающий высокий I/O (настроек обрезающих его я не заметил) на оставшихся живых дисках с парной машины, что с высокой вероятностью может привести к выводу из строя их и как результат (при вашей архитектуре) - полной потере половины данных. Если пользовательские данные хранились через RBD, то фактически это будет эквивалентно потере *всех* данных. Т.к. данные каждого RBD будут +/- равномерно распределены по всем osd, следовательно каждая RBD у вас будет на 50% потеряна. На практике это обозначает его полную потерю, потому что при попытке чтения смещения указывающего на недоступную PG вы получите D статус процесса.
Есть ещё ряд причин по которым делать избыточность = 2 строго не рекомендовано, это ещё сам производитель начиная с jewel версии говорит. В общем, "подумайте о детях" как говорится.
> напомню, что проблема с правкой крушмапа осталась в версии до 12.x.x.
Напомните пожалуйста что за проблема конкретно. На паре кластеров что я разворачивал и поддерживал никаких проблем не было.
> /usr/bin/ceph health detail | grep active+clean+inconsistent | awk '{ print $2 }' | while read a; do /usr/bin/ceph pg repair $a ; done
Вот за это... Ну ничего хорошего я не сказал бы ни вам, ни кому быт то ни было ещё. И нет, дело тут не только в безумной цепочке конвейеров, или даже в том что вывод от версии к версии таки может поменяться (используйте API если хотите делать нормально, зачем стыдобищу выкладывать?).
Бездумный repair раз в 10 минут на умирающие PG приведёт вас к тому что рано или поздно они перестанут восстанавливаться и ваш кластер превратится в тыкву по сценарию описанному выше.
Сами по себе PG не вываливаются, чаще всего (исключив неадекватов в серверной) это симптом проблемного диска. Т.е. надо смотреть после каждого такого развала в smart и как минимум фиксировать его состояние (если не можете сразу менять диски с reallocated и прочим странным), что бы сравнивать с последующим случаем выпадения PG.
Тыва так тыква но как говорится это выбор не мой а заказчик всегда прав
> Тыва так тыква но как говорится это выбор не мой а заказчик
> всегда правНу а по остальным вопросам?
>> Основной задачей было обеспечение надёжности без применения CRUSH Map.опечатка сорри
Когда начинал общатся с заказчиком у них в штате был кршМапперОфициальная должность с должностной инструкцией
тоесть чувак занимался чисто картой ... определял какой туп дика куда засунуть и за это получал 60к в мес !!!
Причем убеждал всех что он делает работу которую никто сделать не может
> тоесть чувак занимался чисто картой ... определял какой туп дика куда засунуть
> и за это получал 60к в мес !!!Нда, неплохо устроился! Вот к чему приводит низкая компетентность управляющего звена.
Подход, как сама реализация - полный бред. Цеф в продакт нести можно только с size >= 3 и minsize >= 2. Точек отказа, в зависимости от структуры крушмапа, должно быть как минимум 3. Нужно было людям дать обычный DRBD и не играться с тем, что рано или поздно убъет данные.
Оказалось не бредом
Скоро допишу статью то все это чем закончилось
Как говорится чуток терпения и все получится
> Нужно было людям дать обычный DRBD и не играться с тем,
> что рано или поздно убъет данные.судя по их "тестам", эти странные люди убьют данные самостоятельно.
хоть с ceph, хоть без.задача исполнителя - выполнить формальные требования, получить оплату и свалить в туман. Тем более что заказчик именно на таком подходе и настаивает.
Заказчик то поди Росреестр? :-)
нет
Ростелеком
Насколько я помню, когда у Росреестра эпично бомбанул ceph, то баллон катили именно на Ростелеком
> Заказчик то поди Росреестр? :-)Ждём продолжение
Возможно запустить рабочею osd(допустим железка умерла но диски с osd живы) на другом хосте?
К чему такой вариант, допустим быстрей перетащить диски чем ждать пока всё синхронизируется.
> osd pool default size = 2
> osd pool default min size = 1На этом месте оно перестает быть продом.