Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: История про Ceph и реплику 1+2"	+/–
Сообщение от auto_tips (??), 08-Ноя-18, 14:36
Обратился как-то знакомый с вопросом можно ли 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. определимся с сетью в качеcтве коммутатора у заказчика 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-.../ Кластер нужен на запись, поэтому основные тесты на запись. Остался доволен и отдал для теста заказчику Утром след дня заказчик заявил, что я неверно все сделал!!! ???????!!!!!! захожу и вижу    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 URL: Обсуждается: https://www.opennet.ru/tips/info/3083.shtml
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по ответам | RSS]

	1. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Аноним (1), 08-Ноя-18, 14:36
	> Выяснилось, заказчик взял и переставил 2 ssd и 2 HDD с другого сервера, а затем отключил 1 OSD. Я правильно понимаю что это был тест "Пьяная обезьянка порезвилась в серверной".  Ок. Заказчик молодец. >Так похоже что FileStore мало подходит FileStore тест на пьяную обезьянку не прошел? Можно объяснить подробнее в чем проблемма? >Пробуем с Blustore >Blustore оказался более пригоден и более живуч BlueStore прошел тест?  Где подробности?
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "История про Ceph и реплику 1+2"	+/–
	Сообщение от alex (??), 08-Ноя-18, 15:23
	для Блястора допишу Видать не все влезло
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "История про Ceph и реплику 1+2"	+/–
	Сообщение от alex (??), 08-Ноя-18, 16:40
	Кстати аноним ! Интересно послушать Ваш опыт в данном распределенном хранилище ! И дай Вам счастье чтоб заказчик был всегда адекватный !
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "История про Ceph и реплику 1+2"	+/–
	Сообщение от твой лучший друг (?), 09-Ноя-18, 22:31
	перед awk не надо grep. Денег дали-то? Чем закончилось?
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "История про Ceph и реплику 1+2"	+/–
	Сообщение от alexpn (ok), 09-Ноя-18, 23:04
	мне же не все события нужны а именно эти Денег пока не дали ушел на Блюстор и заказчик затих ! Видимо сломать не получилось.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "История про Ceph и реплику 1+2"	+/–
	Сообщение от твой лучший друг (?), 10-Ноя-18, 12:59
	в начале нулевых именно здесь на опеннете за связки греп|awk grep|sed cat|grep и тп и тд на полном серьёзе один неанонимный уважаемый комментатор говорил, что для него это как жёлтая карточка: первый раз он разраба предупредит, на второе использование будут кадровые решения. Понимаете, вы используете базовые "кирпичики" юникс в правильном ключе, именно комбинируя маленькие утилиты - но в данном случае сами утилиты достаточно мощны, чтобы выполнить фильтрацию без использования греп.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "История про Ceph и реплику 1+2"	+/–
	Сообщение от alexpn (ok), 10-Ноя-18, 16:30
	> в начале нулевых именно здесь на опеннете за связки греп|awk grep|sed cat|grep > и тп и тд на полном серьёзе один неанонимный уважаемый комментатор > говорил, что для него это как жёлтая карточка: первый раз он > разраба предупредит, на второе использование будут кадровые решения. Понимаете, вы используете > базовые "кирпичики" юникс в правильном ключе, именно комбинируя маленькие утилиты - > но в данном случае сами утилиты достаточно мощны, чтобы выполнить фильтрацию > без использования греп. Логично . Учту на будущее. Если есть решение проще то опубликуйте
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	8. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Аноним (8), 10-Ноя-18, 17:47
	#~/bin/sh CEPH=/usr/bin/ceph $CEPH health detail |     grep -oP "(?<=pg )(.+)(?=is active\+clean\+inconsistent)" |         xargs -l $CEPH pg repair Подотритесь вместе со своим гуру.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	9. "История про Ceph и реплику 1+2"	+1 +/–
	Сообщение от твой лучший друг (?), 10-Ноя-18, 18:26
	> #~/bin/sh > CEPH=/usr/bin/ceph > $CEPH health detail | >  grep -oP "(?<=pg )(.+)(?=is active\+clean\+inconsistent)" | >   xargs -l $CEPH pg repair > Подотритесь вместе со своим гуру. Хорошее использование регулярки, претензия на использование двух утилит там, где достаточно одной снимается, но врядли бы замена директивы "распечатай столбец номер два" на регулярку с префиксом "до столбца вот это" и постфиксом "а после столбца вот это" прошла любое кодеревью. Кто-нибудь откаменил "что, если требуемый столбец сменился?" и после этого зеленую кнопку нажать духу не хватило б.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Аноним (8), 11-Ноя-18, 13:10
	>[оверквотинг удален] >> $CEPH health detail | >>  grep -oP "(?<=pg )(.+)(?=is active\+clean\+inconsistent)" | >>   xargs -l $CEPH pg repair >> Подотритесь вместе со своим гуру. > Хорошее использование регулярки, претензия на использование двух утилит там, где достаточно > одной снимается, но врядли бы замена директивы "распечатай столбец номер два" > на регулярку с префиксом "до столбца вот это" и постфиксом "а > после столбца вот это" прошла любое кодеревью. Кто-нибудь откаменил "что, если > требуемый столбец сменился?" и после этого зеленую кнопку нажать духу не > хватило б. Да ну. Где так серьезно пишут на шелле, что даже с кодревью? Шепните название фирмы. Лидер отрасли, не иначе. Смена формата вывода внутри мажорной версии софта обычно не происходит. Перед обновлением на проде админ это проверит и перепишет регулярку. Информация об этом скрипте уже документирована. К чему это брюзжание? Переписывание греп + авк на чистый авк - это вкусовщина чистейшая. Скрипт делает то, что нужно? Делает. Будет ли он редактироваться в обозримом будущем? Нет. Работает быстро? Да. Какая разница, что внутри? Никакой. Идите пристаньте к бэкэнд-программерам с их ORM и прочими гиперабстракциями. Отстаньте от админов.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Anonymouss (?), 11-Ноя-18, 21:38
	/usr/bin/ceph health detail | awk '/active+clean+inconsistent/ {run="/usr/bin/ceph pg repair "$2; print run; system(run)}' так ж быстрее. да.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	12. "История про Ceph и реплику 1+2"	+1 +/–
	Сообщение от Anonymouss (?), 11-Ноя-18, 21:44
	>[оверквотинг удален] >>>   xargs -l $CEPH pg repair >>> Подотритесь вместе со своим гуру. >> Хорошее использование регулярки, претензия на использование двух утилит там, где достаточно >> одной снимается, но врядли бы замена директивы "распечатай столбец номер два" >> на регулярку с префиксом "до столбца вот это" и постфиксом "а >> после столбца вот это" прошла любое кодеревью. Кто-нибудь откаменил "что, если >> требуемый столбец сменился?" и после этого зеленую кнопку нажать духу не >> хватило б. > Да ну. Где так серьезно пишут на шелле, что даже с кодревью? > Шепните название фирмы. Лидер отрасли, не иначе. Поверьте, писать на шелле с кодревью - это во многих компаниях, которые себя уважают и продают свои решения, особенно если их потом за это могут взять ... Знаю сходу пяток таких контор, причем кол-во людей работающих в каждой, превышает 1К человек и они действительно проходят кодревью на любые вещи, которые пишут.      > Смена формата вывода внутри мажорной версии софта обычно не происходит. Перед обновлением > на проде админ это проверит и перепишет регулярку. > Информация об этом скрипте уже документирована. Вы не дооцениваете человеческую лень. Лучше уж скрипт будет вываливаться и отправлять алерты, чем работать не так как запланировано. > К чему это брюзжание? > Переписывание греп + авк на чистый авк - это вкусовщина чистейшая. > Скрипт делает то, что нужно? Делает. Будет ли он редактироваться в обозримом > будущем? Нет. Работает быстро? Да. Какая разница, что внутри? Никакой. "И так сойдет" (с) какой то мультфильм, ага. > Идите пристаньте к бэкэнд-программерам с их ORM и прочими гиперабстракциями. Отстаньте > от админов.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	13. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Аноним (8), 12-Ноя-18, 00:54
	Наверно не про _нашу_ страну речь. Бюрократическая техноутопия (: >"И так сойдет" (с) какой то мультфильм, ага. Общему уровню решения соответствует вполне. Сойдет. Если по уму делать, то надо взять вывод ceph pg dump. Ну хотя бы. Вот о чем надо было писать. Остальное - треп.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	14. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Аноним (8), 12-Ноя-18, 01:29
	> /usr/bin/ceph health detail | awk '/active+clean+inconsistent/ {run="/usr/bin/ceph > pg repair "$2; print run; system(run)}' > так ж быстрее. да. Вряд ли быстрее, но красивенько.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	15. "История про Ceph и реплику 1+2"	+/–
	Сообщение от alex (??), 12-Ноя-18, 03:14
	Торопится собственно некуда Задача развесить флаги востановления и по возможности понять от чего  они , а не с играть в стрелялку. Спеши медленно и практично.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	16. "История про Ceph и реплику 1+2"	+/–
	Сообщение от твой лучший друг (?), 12-Ноя-18, 15:34
	К каждому коммиту должен быть убедительный рассказ, зачем это сделано, что именно сделано, какие варианты были, кто одобрил. Кто был против этого кода, по какой причине, как его задобрили. кодеревью наше всё. потом, по поводу баттла awk vs grep regex. Представим две команды, в моей эту задачу решает крутой перловод, в другой какой-то васян использовал авк. И тут перед обедом прилетает задача "брать инфо из другого столбца", и васян идет обедать, ты же яростно анализируешь содержимое строчки, тестишь, материшься втихую, и немного уже жалеешь, что васяна забрали соседи.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	17. "История про Ceph и реплику 1+2"	–1 +/–
	Сообщение от имя (?), 12-Ноя-18, 17:54
	ну а swap то зачем 16 GB, ещё и на каждом диске? те представляешь себе что если твой сервер действительно начнём им пользоваться хотяб на 5%?
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "История про Ceph и реплику 1+2"	–1 +/–
	Сообщение от alex (??), 12-Ноя-18, 18:28
	да ... будет прикольно может к тому времени заплатят ?
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Аноним (8), 12-Ноя-18, 23:54
	Перловик на авк может вообще не включая голову. Максимум полминуты ман прочитать. Ну греп-то и легче и лучше. Греп-кун
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	20. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Anonymouss (?), 13-Ноя-18, 00:27
	Я просто оттолкнулся от того, что скрипт запускается из крона без перевода вывода в /dev/null, соответственно при попадании в этот шаблон, рут будет получать уведомления на почту, о том что что либо произошло.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	21. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Crazy Alex (ok), 14-Ноя-18, 03:38
	Ни хрена. Собственно, первая реакция при виде этих закорюк - как раз расчехлить привычный перл и не заниматься фигнёй. Вообще, если шелловый скрипт получается длинее десятка строк или имеет хоть как-то нетривиальную логику (по факту - что-то большее, чем установка переменных и вызов команды с ними) - надо сразу бежать на нормальные скрипты. Питон, перл, да хоть js - что угодно, но подальше от этой слабоподдерживаемой мути. Применение awk/sed - один из признаков тоже. Тут не крутостью шелл-фу надо меряться, а брать что-то человеческое.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	22. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Адекват (ok), 14-Ноя-18, 09:35
	А вот мне, кажется, чем более читаем и понятен код, тем лучше. Уж лучше иметь много sed | grep | awk | cut и прочее, чем один скажем awk но с совершенно не читаемой кашой ' { ; и прочее. В случае если случится ЧП и код будет оформлен как awk, sed, cut, grep - большинство админов быстрее разберется в чем проблема, в отличии от ситуации, когда будет один awk но с магическими заклинаниями. Админы они такие - сегодня работают, завтра нет, и у каждого нового свои взгляды на то, как и что правильно :) Имхо конечно.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	23. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Аноним (23), 14-Ноя-18, 15:05
	Лучше, чтобы ООМ пришел рандомные osd килять? Swap только дает немного времени при возниктовении проблем с памятью
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	24. "История про Ceph и реплику 1+2"	+/–
	Сообщение от RomanCh (ok), 14-Ноя-18, 17:40
	> Основной задачей было обеспечение надёжности без применения 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.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	25. "История про Ceph и реплику 1+2"	+/–
	Сообщение от твой лучший друг (?), 15-Ноя-18, 09:29
	расчехлиться про яваскрипт именно здесь это сродни камингауту, да и питон туда же. Именно эту задачу на питоне решать сравнительно нечитаемо и неподдерживаемо,с внесением зависимостей и тп и тд. Не говоря уже о запуске с задействием яваскрипта. Мгновенная дисквалификация.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	26. "История про Ceph и реплику 1+2"	+/–
	Сообщение от имя (?), 15-Ноя-18, 13:11
	настоящая беда не в OOM, а лишь в том что ты не удосужился прочесть ни статью, ни мой комментарий. попытаюсь объяснить серверы позиционированы на использование Ceph, который представляет собой обычное user-space приложение, т.е. если Ceph не хватает памяти она залезет в swap (19 GB). надо объяснять потери производительности что возникнут при этом у и без того медленной Ceph? прочти статью ещё раз и попытайся найти хотяб 1-2 строчки настроек sysctl которые порой могли бы помочь. правильно - их нет. значит получаем Ceph и file system cache периодически залазят в swap размером до 19GB. даже при SSD-дисках, swap подобного размера вместо тюнинга vm - ЗЛО!
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	27. "История про Ceph и реплику 1+2"	+/–
	Сообщение от default (??), 16-Ноя-18, 01:02
	отчет об аварии у digital ocean говорит о том, что swap для ceph нужен обязательно
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	28. "История про Ceph и реплику 1+2"	+/–
	Сообщение от rumanzo (?), 16-Ноя-18, 02:44
	собственно: 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
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	29. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Lantaris (ok), 18-Ноя-18, 09:49
	Подход, как сама реализация - полный бред. Цеф в продакт нести можно только  с size >= 3 и minsize >= 2. Точек отказа, в зависимости от структуры крушмапа, должно быть как минимум 3. Нужно было людям дать обычный DRBD и не играться с тем, что рано или поздно убъет данные.
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	30. "История про Ceph и реплику 1+2"	+1 +/–
	Сообщение от Alex (??), 18-Ноя-18, 14:31
	Оказалось не бредом Скоро допишу статью то все это чем закончилось Как говорится чуток терпения и все получится
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	31. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Alex (??), 18-Ноя-18, 14:32
	Тыва так тыква но как говорится это выбор не мой а заказчик всегда прав
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	32. "История про Ceph и реплику 1+2"	+/–
	Сообщение от щавель (?), 19-Ноя-18, 14:15
	Представьте себе, да. Иначе лаги начнутся (и не закончатся) во всем кластере. А так кильнул osd, сделал ребаланс и живи дальше.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	33. "История про Ceph и реплику 1+2"	+/–
	Сообщение от RomanCh (ok), 20-Ноя-18, 19:37
	> Тыва так тыква но как говорится это выбор не мой а заказчик > всегда прав Ну а по остальным вопросам?
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	34. "История про Ceph и реплику 1+2"	+/–
	Сообщение от . (?), 21-Ноя-18, 09:36
	> Нужно было людям дать обычный DRBD и не играться с тем, > что рано или поздно убъет данные. судя по их "тестам", эти странные люди убьют данные самостоятельно. хоть с ceph, хоть без. задача исполнителя - выполнить формальные требования, получить оплату и свалить в туман. Тем более что заказчик именно на таком подходе и настаивает.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	35. "История про Ceph и реплику 1+2"	+/–
	Сообщение от a2l (?), 29-Ноя-18, 05:24
	Заказчик то поди Росреестр? :-)
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	36. "История про Ceph и реплику 1+2"	+/–
	Сообщение от alex (??), 01-Дек-18, 16:12
	нет Ростелеком
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	37. "История про Ceph и реплику 1+2"	+/–
	Сообщение от alex (??), 01-Дек-18, 16:16
	>> Основной задачей было обеспечение надёжности без применения CRUSH Map. опечатка сорри Когда начинал общатся с заказчиком у них в штате был кршМаппер Официальная должность с должностной инструкцией тоесть чувак занимался чисто картой ... определял какой туп дика куда засунуть и за это получал 60к в мес !!! Причем убеждал всех что он делает работу которую никто сделать не может
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	38. "История про Ceph и реплику 1+2"	+/–
	Сообщение от RomanCh (ok), 01-Дек-18, 17:46
	> тоесть чувак занимался чисто картой ... определял какой туп дика куда засунуть > и за это получал 60к в мес !!! Нда, неплохо устроился! Вот к чему приводит низкая компетентность управляющего звена.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	39. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Аноним (39), 02-Дек-18, 18:55
	Ссылкой на отчёт поделитесь
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	40. "Раздел полезных советов: История про Ceph и реплику 1+2"	+/–
	Сообщение от Аноним (39), 02-Дек-18, 19:02
	Возможно запустить рабочею osd(допустим железка умерла но диски с osd живы) на другом хосте? К чему такой вариант, допустим быстрей перетащить диски чем ждать пока всё синхронизируется.
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	41. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Аноним (41), 03-Дек-18, 22:11
	Насколько я помню, когда у Росреестра эпично бомбанул ceph, то баллон катили именно на Ростелеком
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	42. "История про Ceph и реплику 1+2"	+/–
	Сообщение от XoRe (ok), 04-Дек-18, 03:17
	> osd pool default size = 2 > osd pool default min size = 1 На этом месте оно перестает быть продом.
	Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	43. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Весёлый Пастер (?), 24-Дек-18, 13:10
	Использование переменных в system - это не секурно уже лет 20, да и нафига? если следующий форк дополнительного процесса не завершит выполнение скрипта!?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	44. "История про Ceph и реплику 1+2"	+/–
	Сообщение от Весёлый Пастер (?), 24-Дек-18, 13:12
	> А вот мне, кажется, чем более читаем и понятен код, тем лучше. > Уж лучше иметь много sed | grep | awk | cut > и прочее, чем один скажем awk но с совершенно не читаемой > кашой ' { ; и прочее. > В случае если случится ЧП и код будет оформлен как awk, sed, > cut, grep - большинство админов быстрее разберется в чем проблема, в > отличии от ситуации, когда будет один awk но с магическими заклинаниями. > Админы они такие - сегодня работают, завтра нет, и у каждого нового > свои взгляды на то, как и что правильно :) > Имхо конечно. Твоё право использовать "большинство админов", а не "меньшинство админов" особенно если не понимать их различия)))
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	45. "История про Ceph и реплику 1+2"	+/–
	Сообщение от AlexZorin (?), 16-Янв-19, 19:33
	> Заказчик то поди Росреестр? :-) Ждём продолжение
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема