The OpenNET Project / Index page

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

История про Ceph и реплику 1+2
Обратился как-то знакомый с вопросом можно ли 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-of-the-ceph-io-layer/ Кластер нужен на запись, поэтому основные тесты на запись. Остался доволен и отдал для теста заказчику Утром след дня заказчик заявил, что я неверно все сделал!!! ???????!!!!!! захожу и вижу cluster: id: 6dae468a-ac29-4cc6-a3e1-7b2a7247eb5b health: HEALTH_ERR 6 osds down 1 host (6 osds) down 5 scrub errors Possible data damage: 4 pgs inconsistent Degraded data redundancy: 2423/4847 objects degraded (50.000%), 2560 pgs degraded, 2560 pgs undersized clock skew detected on mon.mon03 1/3 mons down, quorum mon01,mon03 services: mon: 3 daemons, quorum mon01,mon03, out of quorum: mon02 mgr: mgr02(active), standbys: mgr03, mgr01 osd: 12 osds: 6 up, 12 in ceph health detail HEALTH_ERR 5 scrub errors; Possible data damage: 4 pgs inconsistent OSD_SCRUB_ERRORS 5 scrub errors PG_DAMAGED Possible data damage: 4 pgs inconsistent pg 1.14 is active+clean+inconsistent, acting [12,34] pg 1.27b is active+clean+inconsistent, acting [46,20] pg 1.683 is active+clean+inconsistent, acting [20,34] pg 1.728 is active+clean+inconsistent, acting [49,6] ну ладно попробуем восстановить root@ceph-deploy:~# ceph pg repair 1.728 instructing pg 1.728 on osd.4 to repair .................. instructing pg 1.14 on osd.2 to repair Тем временем задаю вопросы. Выяснилось, заказчик взял и переставил 2 ssd и 2 HDD с другого сервера, а затем отключил 1 OSD. Вспомнив, что на SSD журналы слал думать что можно сделать. Заодно спросил чем 3-й монитор не угодил? На что получил ответ, что все это для теста и нужно проверить все. Так похоже что FileStore мало подходит Пробуем с Blustore Blustore оказался более пригоден и более живуч для исправления ошибок написал скрипт cat /root/rep.sh #!/bin/sh /usr/bin/ceph health detail | grep active+clean+inconsistent | awk '{ print $2 }' | while read a; do /usr/bin/ceph pg repair $a ; done который стартую по крону */10 * * * * /root/rep.sh
  •  
    07.11.2018 , Автор: alex
    Ключи: ceph, cluster, replication / Лицензия: CC-BY
    Раздел:    Корень / Администратору / Система / Кластерные технологии

    Обсуждение [ Линейный режим | Показать все | RSS ]
     
  • 1.1, Аноним (1), 14:36, 08/11/2018 [ответить] [показать ветку] [···]     [к модератору]
  • +/
    Я правильно понимаю что это был тест Пьяная обезьянка порезвилась в серверной ... весь текст скрыт [показать]
     
  • 1.2, alex (??), 15:23, 08/11/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    для Блястора допишу
    Видать не все влезло
     
  • 1.3, alex (??), 16:40, 08/11/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Кстати аноним !
    Интересно послушать Ваш опыт в данном распределенном хранилище !
    И дай Вам счастье чтоб заказчик был всегда адекватный !
     
  • 1.4, твой лучший друг (?), 22:31, 09/11/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    перед awk не надо grep. Денег дали-то? Чем закончилось?
     
     
  • 2.5, alexpn (ok), 23:04, 09/11/2018 [^] [ответить]    [к модератору]  
  • +/
    мне же не все события нужны а именно эти
    Денег пока не дали
    ушел на Блюстор и заказчик затих ! Видимо сломать не получилось.
     
     
  • 3.6, твой лучший друг (?), 12:59, 10/11/2018 [^] [ответить]    [к модератору]  
  • +/
    в начале нулевых именно здесь на опеннете за связки греп|awk grep|sed cat|grep и тп и тд на полном серьёзе один неанонимный уважаемый комментатор говорил, что для него это как жёлтая карточка: первый раз он разраба предупредит, на второе использование будут кадровые решения. Понимаете, вы используете базовые "кирпичики" юникс в правильном ключе, именно комбинируя маленькие утилиты - но в данном случае сами утилиты достаточно мощны, чтобы выполнить фильтрацию без использования греп.
     
     
  • 4.7, alexpn (ok), 16:30, 10/11/2018 [^] [ответить]    [к модератору]  
  • +/
    > в начале нулевых именно здесь на опеннете за связки греп|awk grep|sed cat|grep
    > и тп и тд на полном серьёзе один неанонимный уважаемый комментатор
    > говорил, что для него это как жёлтая карточка: первый раз он
    > разраба предупредит, на второе использование будут кадровые решения. Понимаете, вы используете
    > базовые "кирпичики" юникс в правильном ключе, именно комбинируя маленькие утилиты -
    > но в данном случае сами утилиты достаточно мощны, чтобы выполнить фильтрацию
    > без использования греп.

    Логично . Учту на будущее.
    Если есть решение проще то опубликуйте

     
     
  • 5.28, rumanzo (?), 02:44, 16/11/2018 [^] [ответить]    [к модератору]  
  • +/
    собственно:
    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-June/010920.html
    А если очень уж хочется, можно поковырять параметр osd_scrub_auto_repair и osd_scrub_auto_repair_num_errors

     
  • 4.8, Аноним (8), 17:47, 10/11/2018 [^] [ответить]    [к модератору]  
  • +/
    #~/bin/sh
    CEPH=/usr/bin/ceph
    $CEPH health detail |
    grep -oP "(?<=pg )(.+)(?=is active\+clean\+inconsistent)" |
    xargs -l $CEPH pg repair

    Подотритесь вместе со своим гуру.

     
     
  • 5.9, твой лучший друг (?), 18:26, 10/11/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    > #~/bin/sh
    > CEPH=/usr/bin/ceph
    > $CEPH health detail |
    >  grep -oP "(?<=pg )(.+)(?=is active\+clean\+inconsistent)" |
    >   xargs -l $CEPH pg repair
    > Подотритесь вместе со своим гуру.

    Хорошее использование регулярки, претензия на использование двух утилит там, где достаточно одной снимается, но врядли бы замена директивы "распечатай столбец номер два" на регулярку с префиксом "до столбца вот это" и постфиксом "а после столбца вот это" прошла любое кодеревью. Кто-нибудь откаменил "что, если требуемый столбец сменился?" и после этого зеленую кнопку нажать духу не хватило б.

     
     
  • 6.10, Аноним (8), 13:10, 11/11/2018 [^] [ответить]     [к модератору]  
  • +/
    gt оверквотинг удален Да ну Где так серьезно пишут на шелле, что даже с кодре... весь текст скрыт [показать]
     
     
  • 7.12, Anonymouss (?), 21:44, 11/11/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    gt оверквотинг удален Поверьте, писать на шелле с кодревью - это во многих ком... весь текст скрыт [показать]
     
     
  • 8.13, Аноним (8), 00:54, 12/11/2018 [^] [ответить]     [к модератору]  
  • +/
    Наверно не про _нашу_ страну речь Бюрократическая техноутопия Общему уровню ... весь текст скрыт [показать]
     
  • 6.11, Anonymouss (?), 21:38, 11/11/2018 [^] [ответить]    [к модератору]  
  • +/
    /usr/bin/ceph health detail | awk '/active+clean+inconsistent/ {run="/usr/bin/ceph pg repair "$2; print run; system(run)}'
    так ж быстрее. да.
     
     
  • 7.14, Аноним (8), 01:29, 12/11/2018 [^] [ответить]    [к модератору]  
  • +/
    > /usr/bin/ceph health detail | awk '/active+clean+inconsistent/ {run="/usr/bin/ceph
    > pg repair "$2; print run; system(run)}'
    > так ж быстрее. да.

    Вряд ли быстрее, но красивенько.

     
     
  • 8.16, твой лучший друг (?), 15:34, 12/11/2018 [^] [ответить]    [к модератору]  
  • +/
    К каждому коммиту должен быть убедительный рассказ, зачем это сделано, что именно сделано, какие варианты были, кто одобрил. Кто был против этого кода, по какой причине, как его задобрили. кодеревью наше всё.
    потом, по поводу баттла awk vs grep regex. Представим две команды, в моей эту задачу решает крутой перловод, в другой какой-то васян использовал авк. И тут перед обедом прилетает задача "брать инфо из другого столбца", и васян идет обедать, ты же яростно анализируешь содержимое строчки, тестишь, материшься втихую, и немного уже жалеешь, что васяна забрали соседи.
     
     
  • 9.19, Аноним (8), 23:54, 12/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Перловик на авк может вообще не включая голову. Максимум полминуты ман прочитать.
    Ну греп-то и легче и лучше.
    Греп-кун
     
     
  • 10.21, Crazy Alex (ok), 03:38, 14/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Ни хрена. Собственно, первая реакция при виде этих закорюк - как раз расчехлить привычный перл и не заниматься фигнёй.

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

     
     
  • 11.25, твой лучший друг (?), 09:29, 15/11/2018 [^] [ответить]    [к модератору]  
  • +/
    расчехлиться про яваскрипт именно здесь это сродни камингауту, да и питон туда же. Именно эту задачу на питоне решать сравнительно нечитаемо и неподдерживаемо,с внесением зависимостей и тп и тд. Не говоря уже о запуске с задействием яваскрипта. Мгновенная дисквалификация.
     
  • 8.20, Anonymouss (?), 00:27, 13/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Я просто оттолкнулся от того, что скрипт запускается из крона без перевода вывода в /dev/null, соответственно при попадании в этот шаблон, рут будет получать уведомления на почту, о том что что либо произошло.
     
  • 7.15, alex (??), 03:14, 12/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Торопится собственно некуда
    Задача развесить флаги востановления и по возможности понять от чего  они , а не с играть в стрелялку. Спеши медленно и практично.
     
  • 4.22, Адекват (ok), 09:35, 14/11/2018 [^] [ответить]    [к модератору]  
  • +/
    А вот мне, кажется, чем более читаем и понятен код, тем лучше. Уж лучше иметь много sed | grep | awk | cut и прочее, чем один скажем awk но с совершенно не читаемой кашой ' { ; и прочее.
    В случае если случится ЧП и код будет оформлен как awk, sed, cut, grep - большинство админов быстрее разберется в чем проблема, в отличии от ситуации, когда будет один awk но с магическими заклинаниями.
    Админы они такие - сегодня работают, завтра нет, и у каждого нового свои взгляды на то, как и что правильно :)
    Имхо конечно.
     
  • 1.17, имя (?), 17:54, 12/11/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    ну а swap то зачем 16 GB, ещё и на каждом диске? те представляешь себе что если твой сервер действительно начнём им пользоваться хотяб на 5%?
     
     
  • 2.23, Аноним (23), 15:05, 14/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Лучше, чтобы ООМ пришел рандомные osd килять?

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

     
     
  • 3.26, имя (?), 13:11, 15/11/2018 [^] [ответить]    [к модератору]  
  • +/
    настоящая беда не в OOM, а лишь в том что ты не удосужился прочесть ни статью, ни мой комментарий. попытаюсь объяснить

    серверы позиционированы на использование Ceph, который представляет собой обычное user-space приложение, т.е. если Ceph не хватает памяти она залезет в swap (19 GB). надо объяснять потери производительности что возникнут при этом у и без того медленной Ceph? прочти статью ещё раз и попытайся найти хотяб 1-2 строчки настроек sysctl которые порой могли бы помочь. правильно - их нет. значит получаем Ceph и file system cache периодически залазят в swap размером до 19GB. даже при SSD-дисках, swap подобного размера вместо тюнинга vm - ЗЛО!

     
  • 2.27, default (??), 01:02, 16/11/2018 [^] [ответить]    [к модератору]  
  • +/
    отчет об аварии у digital ocean говорит о том, что swap для ceph нужен обязательно
     
  • 1.18, alex (??), 18:28, 12/11/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    да ... будет прикольно
    может к тому времени заплатят ?
     
     
  • 2.24, RomanCh (ok), 17:40, 14/11/2018 [^] [ответить]     [к модератору]  
  • +/
    Расскажите пожалуйста как Ceph может работать без CRUSH map Этот алгоритм лежит... весь текст скрыт [показать]
     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:



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