The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]



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

"Раздел полезных советов: История про 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:
Обсуждается: http://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"  +/
Сообщение от alexemail (??), 08-Ноя-18, 15:23 
для Блястора допишу
Видать не все влезло
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "История про Ceph и реплику 1+2"  +/
Сообщение от alexemail (??), 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ообщить модератору

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ообщить модератору

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ообщить модератору

12. "История про Ceph и реплику 1+2"  +1 +/
Сообщение от Anonymoussemail (?), 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ообщить модератору

11. "История про Ceph и реплику 1+2"  +/
Сообщение от Anonymoussemail (?), 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ообщить модератору

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ообщить модератору

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

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

21. "История про Ceph и реплику 1+2"  +/
Сообщение от Crazy Alex (ok), 14-Ноя-18, 03:38 
Ни хрена. Собственно, первая реакция при виде этих закорюк - как раз расчехлить привычный перл и не заниматься фигнёй.

Вообще, если шелловый скрипт получается длинее десятка строк или имеет хоть как-то нетривиальную логику (по факту - что-то большее, чем установка переменных и вызов команды с ними) - надо сразу бежать на нормальные скрипты. Питон, перл, да хоть js - что угодно, но подальше от этой слабоподдерживаемой мути. Применение awk/sed - один из признаков тоже. Тут не крутостью шелл-фу надо меряться, а брать что-то человеческое.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

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

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

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

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

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

23. "История про Ceph и реплику 1+2"  +/
Сообщение от Аноним (23), 14-Ноя-18, 15:05 
Лучше, чтобы ООМ пришел рандомные osd килять?

Swap только дает немного времени при возниктовении проблем с памятью

Ответить | Правка | ^ к родителю #17 | Наверх | 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ообщить модератору

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

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

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

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

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

Ну а по остальным вопросам?

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

29. "История про Ceph и реплику 1+2"  +/
Сообщение от Lantarisemail (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ообщить модератору

34. "История про Ceph и реплику 1+2"  +/
Сообщение от . (?), 21-Ноя-18, 09:36 
> Нужно было людям дать обычный DRBD и не играться с тем,
> что рано или поздно убъет данные.

судя по их "тестам", эти странные люди убьют данные самостоятельно.
хоть с ceph, хоть без.

задача исполнителя - выполнить формальные требования, получить оплату и свалить в туман. Тем более что заказчик именно на таком подходе и настаивает.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

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

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


  Закладки на сайте
  Проследить за страницей
Created 1996-2018 by Maxim Chirkov  
ДобавитьПоддержатьВебмастеруГИД  
Hosting by Ihor