Selezzione CEPH. Parte 1
Avemu avutu cinque rack, deci switch ottici, BGP cunfigurati, un paru di decine di SSD è una mansa di dischi SAS di tutti i culori è dimensioni, è ancu proxmox è u desideriu di mette tutte e dati statichi in u nostru propiu almacenamiento S3. Ùn hè micca chì tuttu questu hè necessariu per a virtualizazione, ma quandu avete principiatu à aduprà opensource, seguite u vostru hobby finu à a fine. L'unicu ciò chì m'hà disturbatu era BGP. Ùn ci hè nimu in u mondu più impotente, irresponsibile è immorale chì u routing BGP internu. È sapia chì abbastanza prestu ci sariamu tuffà in questu.
U compitu era triviale - ci era CEPH, ma ùn hà micca travagliatu bè. Era necessariu di fà "bonu".
U cluster chì aghju ricevutu era eterogeneu, sintonizatu in fretta è praticamenti micca sintonizatu. Hè custituitu di dui gruppi di nodi diffirenti, cù una reta cumuna chì agisce cum'è un cluster è una reta publica. I nodi sò pieni di quattru tippi di discu - dui tipi di SSD, cullati in dui reguli di piazzamentu separati, è dui tipi di HDD di diverse dimensioni, cullate in un terzu gruppu. U prublema cù diverse dimensioni hè stata risolta da diversi pesi OSD.
A cunfigurazione stessu hè divisa in dui parti - tuning di u sistema operatore и tuning di CEPH stessu è i so paràmetri.
L'aghjurnamentu di l'OS
Network
L'alta latenza hà affettatu à l'arregistramentu è l'equilibriu. Quandu a registrazione - perchè u cliente ùn riceve micca una risposta per a registrazione successu finu à chì e repliche di dati in altri gruppi di piazzamentu cunfirmanu u successu. Siccomu e regule per a distribuzione di repliche in a mappa CRUSH eranu una replica per host, a reta era sempre utilizata.
Per quessa, a prima cosa ch'e decisu di fà era un pocu tweak a rete attuale, mentre à u stessu tempu pruvatu à cunvince à passà à e rete separati.
Per cumincià, aghju aghjustatu i paràmetri di e carte di rete. Aghju cuminciatu à mette in fila:
chi hè successu:
ethtool -l ens1f1
root@ceph01:~# ethtool -l ens1f1
Channel parameters for ens1f1:
Pre-set maximums:
RX: 0
TX: 0
Other: 1
Combined: 63
Current hardware settings:
RX: 0
TX: 0
Other: 1
Combined: 1
root@ceph01:~# ethtool -g ens1f1
Ring parameters for ens1f1:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256
root@ceph01:~# ethtool -l ens1f1
Channel parameters for ens1f1:
Pre-set maximums:
RX: 0
TX: 0
Other: 1
Combined: 63
Current hardware settings:
RX: 0
TX: 0
Other: 1
Combined: 1Si pò vede chì i paràmetri attuali sò luntanu da i massimi. Aumentu:
root@ceph01:~#ethtool -G ens1f0 rx 4096
root@ceph01:~#ethtool -G ens1f0 tx 4096
root@ceph01:~#ethtool -L ens1f0 combined 63Guidatu da un articulu eccellente
hà aumentatu a durata di a fila di mandatu txqueuelen da 1000 à 10 000
root@ceph01:~#ip link set ens1f0 txqueuelen 10000Ebbè, dopu à a documentazione di ceph stessu
aumentatu MTU finu à 9000.
root@ceph01:~#ip link set dev ens1f0 mtu 9000Aggiuntu à /etc/network/interfaces per chì tuttu ciò chì sopra hè caricatu à l'iniziu
cat / etc / network / interfaces
root@ceph01:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto ens1f0
iface ens1f0 inet manual
post-up /sbin/ethtool -G ens1f0 rx 4096
post-up /sbin/ethtool -G ens1f0 tx 4096
post-up /sbin/ethtool -L ens1f0 combined 63
post-up /sbin/ip link set ens1f0 txqueuelen 10000
mtu 9000
auto ens1f1
iface ens1f1 inet manual
post-up /sbin/ethtool -G ens1f1 rx 4096
post-up /sbin/ethtool -G ens1f1 tx 4096
post-up /sbin/ethtool -L ens1f1 combined 63
post-up /sbin/ip link set ens1f1 txqueuelen 10000
mtu 9000Dopu quì, dopu à u stessu articulu, aghju cuminciatu à torce pensativamente i manichi di u kernel 4.15. Cunsiderendu chì i nodi anu 128G RAM, avemu finitu cun un schedariu di cunfigurazione per sysctl
cat /etc/sysctl.d/50-ceph.conf
net.core.rmem_max = 56623104
#Максимальный размер буфера приема данных для всех соединений 54M
net.core.wmem_max = 56623104
#Максимальный размер буфера передачи данных для всех соединений 54M
net.core.rmem_default = 56623104
#Размер буфера приема данных по умолчанию для всех соединений. 54M
net.core.wmem_default = 56623104
#Размер буфера передачи данных по умолчанию для всех соединений 54M
# на каждый сокет
net.ipv4.tcp_rmem = 4096 87380 56623104
#Векторная (минимум, по умолчанию, максимум) переменная в файле tcp_rmem
# содержит 3 целых числа, определяющих размер приемного буфера сокетов TCP.
# Минимум: каждый сокет TCP имеет право использовать эту память по
# факту своего создания. Возможность использования такого буфера
# гарантируется даже при достижении порога ограничения (moderate memory pressure).
# Размер минимального буфера по умолчанию составляет 8 Кбайт (8192).
#Значение по умолчанию: количество памяти, допустимое для буфера
# передачи сокета TCP по умолчанию. Это значение применяется взамен
# параметра /proc/sys/net/core/rmem_default, используемого другими протоколами.
# Значение используемого по умолчанию буфера обычно (по умолчанию)
# составляет 87830 байт. Это определяет размер окна 65535 с
# заданным по умолчанию значением tcp_adv_win_scale и tcp_app_win = 0,
# несколько меньший, нежели определяет принятое по умолчанию значение tcp_app_win.
# Максимум: максимальный размер буфера, который может быть автоматически
# выделен для приема сокету TCP. Это значение не отменяет максимума,
# заданного в файле /proc/sys/net/core/rmem_max. При «статическом»
# выделении памяти с помощью SO_RCVBUF этот параметр не имеет значения.
net.ipv4.tcp_wmem = 4096 65536 56623104
net.core.somaxconn = 5000
# Максимальное число открытых сокетов, ждущих соединения.
net.ipv4.tcp_timestamps=1
# Разрешает использование временных меток (timestamps), в соответствии с RFC 1323.
net.ipv4.tcp_sack=1
# Разрешить выборочные подтверждения протокола TCP
net.core.netdev_max_backlog=5000 (дефолт 1000)
# максимальное количество пакетов в очереди на обработку, если
# интерфейс получает пакеты быстрее, чем ядро может их обработать.
net.ipv4.tcp_max_tw_buckets=262144
# Максимальное число сокетов, находящихся в состоянии TIME-WAIT одновременно.
# При превышении этого порога – «лишний» сокет разрушается и пишется
# сообщение в системный журнал.
net.ipv4.tcp_tw_reuse=1
#Разрешаем повторное использование TIME-WAIT сокетов в случаях,
# если протокол считает это безопасным.
net.core.optmem_max=4194304
#Увеличить максимальный общий буфер-космической ALLOCATABLE
#измеряется в единицах страниц (4096 байт)
net.ipv4.tcp_low_latency=1
#Разрешает стеку TCP/IP отдавать предпочтение низкому времени ожидания
# перед более высокой пропускной способностью.
net.ipv4.tcp_adv_win_scale=1
# Эта переменная влияет на вычисление объема памяти в буфере сокета,
# выделяемой под размер TCP-окна и под буфер приложения.
# Если величина tcp_adv_win_scale отрицательная, то для вычисления размера
# используется следующее выражение:
# Bytes- bytes2в степени -tcp_adv_win_scale
# Где bytes – это размер окна в байтах. Если величина tcp_adv_win_scale
# положительная, то для определения размера используется следующее выражение:
# Bytes- bytes2в степени tcp_adv_win_scale
# Переменная принимает целое значение. Значение по-умолчанию – 2,
# т.е. под буфер приложения отводится ¼ часть объема, определяемого переменной
# tcp_rmem.
net.ipv4.tcp_slow_start_after_idle=0
# механизм перезапуска медленного старта, который сбрасывает значение окна
# перегрузки, если соединение не использовалось заданный период времени.
# Лучше отключить SSR на сервере, чтобы улучшить производительность
# долгоживущих соединений.
net.ipv4.tcp_no_metrics_save=1
#Не сохранять результаты измерений TCP соединения в кеше при его закрытии.
net.ipv4.tcp_syncookies=0
#Отключить механизм отправки syncookie
net.ipv4.tcp_ecn=0
#Explicit Congestion Notification (Явное Уведомление о Перегруженности) в
# TCP-соединениях. Используется для уведомления о возникновении «затора»
# на маршруте к заданному хосту или сети. Может использоваться для извещения
# хоста-отправителя о необходимости снизить скорость передачи пакетов через
# конкретный маршрутизатор или брандмауэр.
net.ipv4.conf.all.send_redirects=0
# выключает выдачу ICMP Redirect … другим хостам. Эта опция обязательно
# должна быть включена, если хост выступает в роли маршрутизатора любого рода.
# У нас нет маршрутизации.
net.ipv4.ip_forward=0
#Сопсно отключение форвардинга. Мы не шлюз, докер на машинах не поднят,
# нам это не нужно.
net.ipv4.icmp_echo_ignore_broadcasts=1
#Не отвечаем на ICMP ECHO запросы, переданные широковещательными пакетами
net.ipv4.tcp_fin_timeout=10
#определяет время сохранения сокета в состоянии FIN-WAIT-2 после его
# закрытия локальной стороной. Дефолт 60
net.core.netdev_budget=600 # (дефолт 300)
# Если выполнение программных прерываний не выполняются достаточно долго,
# то темп роста входящих данных может превысить возможность ядра
# опустошить буфер. В результате буферы NIC переполнятся, и трафик будет потерян.
# Иногда, необходимо увеличить длительность работы SoftIRQs
# (программных прерываний) с CPU. За это отвечает netdev_budget.
# Значение по умолчанию 300. Параметр заставит процесс SoftIRQ обработать
# 300 пакетов от NIC перед тем как отпустить CPU
net.ipv4.tcp_fastopen=3
# TFO TCP Fast Open
# если и клиент и сервер имеют поддержку TFO, о которой сообщают за счет
# специального флага в TCP пакете. В нашем случае является плацебо, просто
# выглядит красиво)Сrete di lustru hè stata attribuita nantu à interfacce di rete 10Gbps separati in una reta piatta separata. Ogni macchina era dotata di carte di rete dual-port mellanox 10/25 Gbps, cunnessu in dui switch 10Gbps separati. L'aggregazione hè stata realizata cù OSPF, postu chì u ligame cù lacp per una certa ragione hà dimustratu un throughput tutale di un massimu di 16 Gbps, mentre chì l'ospf hà utilizatu bè e duie decine in ogni macchina. I piani futuri eranu di prufittà di ROCE nantu à questi melanoxes per riduce a latenza. Cumu stabilisce sta parte di a reta:
- Siccomu i machini stessi anu indirizzi IP esterni nantu à BGP, avemu bisognu di software - (più precisamente, à u mumentu di a scrittura di stu articulu era ) era digià in piedi.
- In totale, i machini avianu dui interfacce di rete, ognunu cù dui interfacce - un totale di porti 4. Una carta di rete hà guardatu à a fabbrica cù dui porti è BGP hè stata cunfigurata nantu à questu, a seconda hà guardatu dui switches differenti cù dui porti è OSPF hè stata stallata nantu à questu.
Più dettagli nantu à a stallazione di OSPF: U compitu principale hè di aggregate dui ligami è avè a tolleranza di difetti.
duie interfacce di rete sò cunfigurate in duie rete piatte simplici - 10.10.10.0/24 è 10.10.20.0/24
1: ens1f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
inet 10.10.10.2/24 brd 10.10.10.255 scope global ens1f0
2: ens1f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
inet 10.10.20.2/24 brd 10.10.20.255 scope global ens1f1da quali vitture si vedenu.
DISCU
U prossimu passu era di ottimisà i dischi. Per SSD aghju cambiatu u scheduler à nò, per HDD - a fine. Per dì chjaramente, NOOP travaglia nantu à u principiu di "first in, first out", chì in inglese sona cum'è "FIFO (First In, First Out)". E dumande sò in fila à l'arrivu. U TEMPU hè più orientatu à leghje, più u prucessu di fila riceve un accessu quasi esclusivu à u discu à u mumentu di l'operazione. Questu hè perfettu per u nostru sistema - dopu tuttu, solu un prucessu funziona cù ogni discu - daemon OSD.
(Quelli chì volenu immergersi in u pianificatore I / O ponu leghje quì:
Quelli chì preferanu leghje in russo: )
In i cunsiglii per tuning Linux, hè ancu cunsigliatu per aumentà nr_request
nr_requests
U valore di nr_requests determina a quantità di richieste I/O chì sò buffered prima chì u pianificatore I/O invii / riceve dati à u dispositivu di bloccu, se utilizate una carta RAID / Dispositivu di bloccu chì pò trattà una fila più grande di ciò chì l'I. L'agendatore / O hè stabilitu, aumentà u valore di nr_requests pò aiutà à migliurà in tuttu è riduce a carica di u servitore quandu una grande quantità di I / O si trovanu in u servitore. Sè vo aduprate Deadline o CFQ cum'è pianificatore, hè suggeritu chì duvete stabilisce u valore nr_request à 2 volte u valore di a prufundità di a fila.
MA ! I citadini stessi, i sviluppatori di CEPH, ci cunvincenu chì u so sistema di priorità funziona megliu
WBThrottle è/o nr_requests
WBThrottle è/o nr_requests
L'archiviazione di fugliali usa operazioni I/O bufferizzate per a scrittura; questu offre una quantità di vantaghji se u ghjurnale di l'archiviazione di fugliali si trova nantu à supporti più veloci. E richieste di i clienti sò notificate appena i dati sò scritti in u ghjurnale, è dopu sò scaricate nantu à u discu di dati in un mumentu dopu aduprendu a funzionalità standard. LinuxQuestu permette à i dischi di u spindle OSD di furnisce una latenza di scrittura simile à l'SSD quandu scrivenu in picculi pacchetti. Questa scrittura ritardata permette ancu à u kernel stessu di ristrutturà e richieste I/O à u discu, sperendu di fusionalli inseme o di permette à e teste di u discu di sceglie un percorsu più ottimale trà i so piatti. U risultatu finale hè chì pudete sprime un pocu più operazioni I/O da ogni discu di ciò chì seria pussibule cù operazioni I/O dirette o sincrone.
In ogni casu, un certu prublema nasce se u voluminu di registri in entrata à un determinatu cluster Ceph supera tutte e capacità di i dischi sottostanti. In questu scenariu, u numeru tutale di operazioni I/O pendenti in attesa di esse scritte à u discu puderia cresce incontrollably è risultatu in file d'I/O chì riempianu tuttu u discu è e file Ceph. E dumande di lettura sò particularmente affettate perchè s'imbulighjanu trà e dumande di scrittura, chì ponu piglià parechji sicondi per flussu à u discu primariu.
Per superà stu prublema, Ceph hà un mecanismu di throttling writeback integratu in u almacenamentu di schedari chjamatu WBThrottle. Hè cuncepitu per limità a quantità generale di I/O di scrittura lazy chì pò mette in fila è principià u so prucessu di flussu prima di ciò chì accade naturalmente per esse attivatu da u kernel stessu. Sfortunatamente, a prova dimustra chì i valori predeterminati ponu ancu micca riduce u cumpurtamentu esistenti à un livellu chì pò riduce stu impattu nantu à a latenza di lettura. L'aghjustamenti ponu cambià stu cumpurtamentu è riduce a lunghezza generale di a fila di scrittura è rende stu impattu menu severu. Tuttavia, ci hè un scambiu: riducendu u numeru massimu generale di entrate permesse per esse in fila, pudete riduce a capacità di u kernel stessu per maximizà a so efficienza in l'urdinamentu di e dumande entrate. Hè vale a pena pensà à ciò chì avete bisognu di più per u vostru casu d'usu specificu, carichi di travagliu è aghjustà per adattà.
Per cuntrullà a prufundità di una tale fila di scrittura di backlog, pudete riduce u numeru massimu generale di operazioni I / O eccezziunali cù i paràmetri WBThrottle, o pudete riduce u valore massimu per operazioni eccezziunali à u livellu di bloccu di u vostru kernel stessu. Tutti dui ponu cuntrullà in modu efficace u listessu cumpurtamentu, è e vostre preferenze seranu a basa per implementà sta paràmetra.
Hè ancu esse nutatu chì u sistema di priorità di l'operazione di Ceph hè più efficau per e dumande più brevi à u nivellu di discu. Riducendu a fila generale à un discu datu, u locu primariu di a fila si move in Ceph, induve hà più cuntrollu di quale priorità l'operazione I / O hà. Cunsiderate l'esempiu seguente:
echo 8 > /sys/block/sda/queue/nr_requestsCOMUN
È uni pochi di più tweaks di u kernel per rende a vostra vittura morbida è setosa è stringhje un pocu più rendimentu da u hardware
cat /etc/sysctl.d/60-ceph2.conf
kernel.pid_max = 4194303
#Дисков в каждой машине по 25, потому рассчитывали что процессов будет много
kernel.threads-max=2097152
# Тредов, естессно, тоже.
vm.max_map_count=524288
# Увеличили количество областей карты памяти процесса.
# Как следует из документации по ядерным переменным
# Области карты памяти используется как побочный эффект вызова
# malloc, напрямую с помощью mmap, mprotect и madvise, а также при загрузке
# общих библиотек.
fs.aio-max-nr=50000000
# Подтюним параметры input-output
# Ядро Linux предоставляет функцию асинхронного неблокирующего ввода-вывода (AIO),
# которая позволяет процессу инициировать несколько операций ввода-вывода
# одновременно, не дожидаясь завершения какой-либо из них.
# Это помогает повысить производительность приложений,
# которые могут перекрывать обработку и ввод-вывод.
# Параметр aio-max-nr определяет максимальное количество допустимых
# одновременных запросов.
vm.min_free_kbytes=1048576
# минимальный размер свободной памяти который необходимо поддерживать.
# Выставлен 1Gb, чего вполне достаточно для работы операционной системы,
# и позволяет избегать OOM Killer для процессов OSD. Хотя памяти и так
# как у дурака фантиков, но запас карман не тянет
vm.swappiness=10
# Говорим использовать своп если осталось свободным 10% памяти.
# На машинах 128G оперативы, и 10% это 12 Гигов. Более чем достаточно для работы.
# Штатный параметр в 60% заставлял тормозить систему, залезая в своп,
# когда есть еще куча свободной памяти
vm.vfs_cache_pressure=1000
# Увеличиваем со штатных 100. Заставляем ядро активнее выгружать
# неиспользуемые страницы памяти из кеша.
vm.zone_reclaim_mode=0
# Позволяет устанавливать более или менее агрессивные подходы к
# восстановлению памяти, когда в зоне заканчивается память.
# Если он установлен на ноль, то не происходит восстановление зоны.
# Для файловых серверов или рабочих нагрузок
# выгодно, если их данные кэшированы, zone_reclaim_mode
# оставить отключенным, поскольку эффект кэширования,
# вероятно, будет более важным, чем местонахождение данных.
vm.dirty_ratio=20
# Процент оперативной памяти, который можно выделить под "грязные" страницы
# Вычисляли из примерного расчета:
# В система 128 гигов памяти.
# Примерно по 20 дисков SSD, у которых в настройках CEPH указано
# выделять под кэширование по 3G оперативы.
# Примерно по 40 дисков HDD, для которых этот параметр равен 1G
# 20% от 128 это 25.6 гигов. Итого, в случае максимальной утилизации памяти,
# для системы останется 2.4G памяти. Чего ей должно хватить чтоб выжить и дождаться
# стука копыт кавалерии - то есть пришествия DevOps который все починит.
vm.dirty_background_ratio=3
# процент системной памяти, который можно заполнить dirty pages до того,
# как фоновые процессы pdflush/flush/kdmflush запишут их на диск
fs.file-max=524288
# Ну и открытых файлов у нас,вероятно, будет сильно больше, чем указано по дефолту. Immersione in CEPH
Paràmetri chì mi piacerebbe aspittà in più dettagli:
cat /etc/ceph/ceph.conf
osd:
journal_aio: true # Три параметра, включающие
journal_block_align: true # прямой i/o
journal_dio: true # на журнал
journal_max_write_bytes: 1073714824 # Немного растянем максимальный размер
# разово записываемой операции в журнал
journal_max_write_entries: 10000 # Ну и количество одновременных записей
journal_queue_max_bytes: 10485760000
journal_queue_max_ops: 50000
rocksdb_separate_wal_dir: true # Решили делать отдельный wal
# Даже попытались выбить под это дело
# NVMe
bluestore_block_db_create: true # Ну и под журнал отдельное устройство
bluestore_block_db_size: '5368709120 #5G'
bluestore_block_wal_create: true
bluestore_block_wal_size: '1073741824 #1G'
bluestore_cache_size_hdd: '3221225472 # 3G'
# большой объем оперативы позволяет
# хранить достаточно большие объемы
bluestore_cache_size_ssd: '9663676416 # 9G'
keyring: /var/lib/ceph/osd/ceph-$id/keyring
osd_client_message_size_cap: '1073741824 #1G'
osd_disk_thread_ioprio_class: idle
osd_disk_thread_ioprio_priority: 7
osd_disk_threads: 2 # количество тредов у демона на один диск
osd_failsafe_full_ratio: 0.95
osd_heartbeat_grace: 5
osd_heartbeat_interval: 3
osd_map_dedup: true
osd_max_backfills: 2 # количество одновременных операций заполнения на один ОСД.
osd_max_write_size: 256
osd_mon_heartbeat_interval: 5
osd_op_threads: 16
osd_op_num_threads_per_shard: 1
osd_op_num_threads_per_shard_hdd: 2
osd_op_num_threads_per_shard_ssd: 2
osd_pool_default_min_size: 1 # Особенности жадности. Очень быстро стало
osd_pool_default_size: 2 # нехватать места, потому как временное
# решение приняли уменьшение количество
# реплик данных
osd_recovery_delay_start: 10.000000
osd_recovery_max_active: 2
osd_recovery_max_chunk: 1048576
osd_recovery_max_single_start: 3
osd_recovery_op_priority: 1
osd_recovery_priority: 1 # параметр регулируем по необходимости на ходу
osd_recovery_sleep: 2
osd_scrub_chunk_max: 4Certi di i paràmetri chì sò stati pruvati per QA in a versione 12.2.12 mancanu in a versione ceph 12.2.2, per esempiu osd_recovery_threads. Dunque, i piani includenu un aghjurnamentu di a produzzione à 12.2.12. A pratica hà dimustratu a cumpatibilità trà e versioni 12.2.2 è 12.2.12 in un cluster, chì permette l'aghjurnamenti rolling.
Test cluster
Naturalmente, per pruvà era necessariu avè a listessa versione cum'è in a battaglia, ma à l'epica ch'e aghju cuminciatu à travaglià cù u cluster, solu u novu era dispunibule in u repository. Dopu avè vistu, ciò chì pudete discernisce in a versione minore ùn hè micca assai grande (1393 linee in cunfigurazione contru 1436 in a nova versione), avemu decisu di inizià a prova di a nova (aghjurnà in ogni modu, perchè andà cun vechji junk)
L'unicu ciò chì avemu pruvatu à abbandunà a vechja versione hè u pacchettu ceph-deploy postu chì alcuni di l'utilità (è alcuni di l'impiegati) sò stati adattati à a so sintassi. A nova versione era assai sfarente, ma ùn hà micca affettatu u funziunamentu di u cluster stessu, è hè stata lasciata in a versione 1.5.39
Siccomu u cumandamentu di ceph-disk dice chjaramente chì hè deprecated è utilizate l'ordine di ceph-volume, cari, avemu cuminciatu à creà OSD cù questu cumandamentu, senza perde u tempu in quelli obsoleti.
U pianu era di creà un specchiu di dui unità SSD nantu à quale mettimu logs OSD, chì, à u turnu, sò situati nantu à SAS di spindle. In questu modu, pudemu prutezzione di i prublemi cù i dati se u discu cù u logu casca.
Avemu cuminciatu à creà un cluster secondu a ducumentazione
cat /etc/ceph/ceph.conf
root@ceph01-qa:~# cat /etc/ceph/ceph.conf # положили заранее подготовленный конфиг
[client]
rbd_cache = true
rbd_cache_max_dirty = 50331648
rbd_cache_max_dirty_age = 2
rbd_cache_size = 67108864
rbd_cache_target_dirty = 33554432
rbd_cache_writethrough_until_flush = true
rbd_concurrent_management_ops = 10
rbd_default_format = 2
[global]
auth_client_required = cephx
auth_cluster_required = cephx
auth_service_required = cephx
cluster network = 10.10.10.0/24
debug_asok = 0/0
debug_auth = 0/0
debug_buffer = 0/0
debug_client = 0/0
debug_context = 0/0
debug_crush = 0/0
debug_filer = 0/0
debug_filestore = 0/0
debug_finisher = 0/0
debug_heartbeatmap = 0/0
debug_journal = 0/0
debug_journaler = 0/0
debug_lockdep = 0/0
debug_mon = 0/0
debug_monc = 0/0
debug_ms = 0/0
debug_objclass = 0/0
debug_objectcatcher = 0/0
debug_objecter = 0/0
debug_optracker = 0/0
debug_osd = 0/0
debug_paxos = 0/0
debug_perfcounter = 0/0
debug_rados = 0/0
debug_rbd = 0/0
debug_rgw = 0/0
debug_throttle = 0/0
debug_timer = 0/0
debug_tp = 0/0
fsid = d0000000d-4000-4b00-b00b-0123qwe123qwf9
mon_host = ceph01-q, ceph02-q, ceph03-q
mon_initial_members = ceph01-q, ceph02-q, ceph03-q
public network = 8.8.8.8/28 # адрес изменен, естественно ))
rgw_dns_name = s3-qa.mycompany.ru # и этот адрес измен
rgw_host = s3-qa.mycompany.ru # и этот тоже
[mon]
mon allow pool delete = true
mon_max_pg_per_osd = 300 # больше трехсот плейсмент групп
# на диск не решились
# хотя параметр, естественно, зависит от количества пулов,
# их размеров и количества OSD. Иметь мало но здоровых PG
# тоже не лучший выбор - страдает точность балансировки
mon_osd_backfillfull_ratio = 0.9
mon_osd_down_out_interval = 5
mon_osd_full_ratio = 0.95 # пока для SSD дисков местом для их
# журнала является тот-же девайс что и для ОСД
# решили что 5% от диска (который сам размером 1.2Tb)
# должно вполне хватить, и коррелирует с параметром
# bluestore_block_db_size плюс вариативность на большие
# плейсмент группы
mon_osd_nearfull_ratio = 0.9
mon_pg_warn_max_per_osd = 520
[osd]
bluestore_block_db_create = true
bluestore_block_db_size = 5368709120 #5G
bluestore_block_wal_create = true
bluestore_block_wal_size = 1073741824 #1G
bluestore_cache_size_hdd = 3221225472 # 3G
bluestore_cache_size_ssd = 9663676416 # 9G
journal_aio = true
journal_block_align = true
journal_dio = true
journal_max_write_bytes = 1073714824
journal_max_write_entries = 10000
journal_queue_max_bytes = 10485760000
journal_queue_max_ops = 50000
keyring = /var/lib/ceph/osd/ceph-$id/keyring
osd_client_message_size_cap = 1073741824 #1G
osd_disk_thread_ioprio_class = idle
osd_disk_thread_ioprio_priority = 7
osd_disk_threads = 2
osd_failsafe_full_ratio = 0.95
osd_heartbeat_grace = 5
osd_heartbeat_interval = 3
osd_map_dedup = true
osd_max_backfills = 4
osd_max_write_size = 256
osd_mon_heartbeat_interval = 5
osd_op_num_threads_per_shard = 1
osd_op_num_threads_per_shard_hdd = 2
osd_op_num_threads_per_shard_ssd = 2
osd_op_threads = 16
osd_pool_default_min_size = 1
osd_pool_default_size = 2
osd_recovery_delay_start = 10.0
osd_recovery_max_active = 1
osd_recovery_max_chunk = 1048576
osd_recovery_max_single_start = 3
osd_recovery_op_priority = 1
osd_recovery_priority = 1
osd_recovery_sleep = 2
osd_scrub_chunk_max = 4
osd_scrub_chunk_min = 2
osd_scrub_sleep = 0.1
rocksdb_separate_wal_dir = true# создаем мониторы
root@ceph01-qa:~#ceph-deploy mon create ceph01-q
# генерируем ключи для аутентификации нод в кластере
root@ceph01-qa:~#ceph-deploy gatherkeys ceph01-q
# Это если поштучно. Если у нас несколько машин доступны - те, которые описаны в конфиге в секции
# mon_initial_members = ceph01-q, ceph02-q, ceph03-q
# можно запустить эти две команды в виде одной
root@ceph01-qa:~#ceph-deploy mon create-initial
# Положим ключи в указанные в конфиге места
root@ceph01-qa:~#cat ceph.bootstrap-osd.keyring > /var/lib/ceph/bootstrap-osd/ceph.keyring
root@ceph01-qa:~#cat ceph.bootstrap-mgr.keyring > /var/lib/ceph/bootstrap-mgr/ceph.keyring
root@ceph01-qa:~#cat ceph.bootstrap-rgw.keyring > /var/lib/ceph/bootstrap-rgw/ceph.keyring
# создадим ключ для управления кластером
root@ceph01-qa:~#ceph-deploy admin ceph01-q
# и менеджер, плагинами управлять
root@ceph01-qa:~#ceph-deploy mgr create ceph01-qA prima cosa ch'e aghju scuppiatu quandu travagliava cù questa versione di ceph-deploy cù una versione di cluster 12.2.12 era un errore quandu provava à creà un OSD cù db in un raid di software -
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sde --block.db /dev/md0
blkid could not detect a PARTUUID for device: /dev/md1Infatti, blkid ùn pare micca esse PARTUUID, cusì aghju avutu à creà partizioni manualmente:
root@ceph01-qa:~#parted /dev/md0 mklabel GPT
# разделов будет много,
# без GPT их создать не получится
# размер раздела мы указали в конфиге выше = bluestore_block_db_size: '5368709120 #5G'
# Дисков у меня 20 под OSD, руками создавать разделы лень
# потому сделал цикл
root@ceph01-qa:~#for i in {1..20}; do echo -e "nnnn+5Gnw" | fdisk /dev/md0; doneTuttu pare esse prontu, pruvemu di creà l'OSD di novu è uttene u seguente errore (chì, per via, ùn hè micca riproduciutu in battaglia)
quandu crea un OSD di tipu bluestore senza specificà u percorsu à WAL, ma specificà db
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sde --block.db /dev/md0
stderr: 2019-04-12 10:39:27.211242 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) _read_fsid unparsable uuid
stderr: 2019-04-12 10:39:27.213185 7eff461b6e00 -1 bdev(0x55824c273680 /var/lib/ceph/osd/ceph-0//block.wal) open open got: (22) Invalid argument
stderr: 2019-04-12 10:39:27.213201 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) _open_db add block device(/var/lib/ceph/osd/ceph-0//block.wal) returned: (22) Invalid argument
stderr: 2019-04-12 10:39:27.999039 7eff461b6e00 -1 bluestore(/var/lib/ceph/osd/ceph-0/) mkfs failed, (22) Invalid argument
stderr: 2019-04-12 10:39:27.999057 7eff461b6e00 -1 OSD::mkfs: ObjectStore::mkfs failed with error (22) Invalid argument
stderr: 2019-04-12 10:39:27.999141 7eff461b6e00 -1 ** ERROR: error creating empty object store in /var/lib/ceph/osd/ceph-0/: (22) Invalid argumenInoltre, se in u stessu specchiu (o in un altru locu, di a vostra scelta) create una altra partizione per WAL è specificate quandu crea l'OSD, allora tuttu andarà bè (eccettu per l'apparizione di un WAL separatu, chì pudete micca. anu vulutu).
Ma, postu chì era sempre in i piani distanti per traslassi WAL à NVMe, a pratica ùn hè micca superflua.
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sdf --block.wal /dev/md0p2 --block.db /dev/md1p2Creatu monitori, gestori è OSD. Avà mi piacerebbe raggrupparli in modu diversu, perchè pensa à avè diversi tipi di discu - piscine veloci nantu à SSD è piscine grandi, ma lenti nantu à pancakes SAS.
Assumimu chì i servitori anu 20 discu, i primi deci sò un tipu, u sicondu sò un altru.
A carta iniziale, predeterminata, s'assumiglia cusì:
ceph osd tree
root@ceph01-q:~# ceph osd tree
ID CLASSE PESO TIPU NOME STATUS REWEIGHT PRI-AFF
-1 14.54799 root default
-3 9.09200 host ceph01-q
0 ssd 1.00000 osd.0 up 1.00000 1.00000
1 ssd 1.00000 osd.1 up 1.00000 1.00000
2 ssd 1.00000 osd.2 up 1.00000 1.00000
3 ssd 1.00000 osd.3 up 1.00000 1.00000
4 hdd 1.00000 osd.4 up 1.00000 1.00000
5 hdd 0.27299 osd.5 up 1.00000 1.00000
6 hdd 0.27299 osd.6 up 1.00000 1.00000
7 hdd 0.27299 osd.7 up 1.00000 1.00000
8 hdd 0.27299 osd.8 up 1.00000 1.00000
9 hdd 0.27299 osd.9 up 1.00000 1.00000
10 hdd 0.27299 osd.10 up 1.00000 1.00000
11 hdd 0.27299 osd.11 up 1.00000 1.00000
12 hdd 0.27299 osd.12 up 1.00000 1.00000
13 hdd 0.27299 osd.13 up 1.00000 1.00000
14 hdd 0.27299 osd.14 up 1.00000 1.00000
15 hdd 0.27299 osd.15 up 1.00000 1.00000
16 hdd 0.27299 osd.16 up 1.00000 1.00000
17 hdd 0.27299 osd.17 up 1.00000 1.00000
18 hdd 0.27299 osd.18 up 1.00000 1.00000
19 hdd 0.27299 osd.19 up 1.00000 1.00000
-5 5.45599 host ceph02-q
20 ssd 0.27299 osd.20 up 1.00000 1.00000
21 ssd 0.27299 osd.21 up 1.00000 1.00000
22 ssd 0.27299 osd.22 up 1.00000 1.00000
23 ssd 0.27299 osd.23 up 1.00000 1.00000
24 hdd 0.27299 osd.24 up 1.00000 1.00000
25 hdd 0.27299 osd.25 up 1.00000 1.00000
26 hdd 0.27299 osd.26 up 1.00000 1.00000
27 hdd 0.27299 osd.27 up 1.00000 1.00000
28 hdd 0.27299 osd.28 up 1.00000 1.00000
29 hdd 0.27299 osd.29 up 1.00000 1.00000
30 hdd 0.27299 osd.30 up 1.00000 1.00000
31 hdd 0.27299 osd.31 up 1.00000 1.00000
32 hdd 0.27299 osd.32 up 1.00000 1.00000
33 hdd 0.27299 osd.33 up 1.00000 1.00000
34 hdd 0.27299 osd.34 up 1.00000 1.00000
35 hdd 0.27299 osd.35 up 1.00000 1.00000
36 hdd 0.27299 osd.36 up 1.00000 1.00000
37 hdd 0.27299 osd.37 up 1.00000 1.00000
38 hdd 0.27299 osd.38 up 1.00000 1.00000
39 hdd 0.27299 osd.39 up 1.00000 1.00000
-7 6.08690 host ceph03-q
40 ssd 0.27299 osd.40 up 1.00000 1.00000
41 ssd 0.27299 osd.41 up 1.00000 1.00000
42 ssd 0.27299 osd.42 up 1.00000 1.00000
43 ssd 0.27299 osd.43 up 1.00000 1.00000
44 hdd 0.27299 osd.44 up 1.00000 1.00000
45 hdd 0.27299 osd.45 up 1.00000 1.00000
46 hdd 0.27299 osd.46 up 1.00000 1.00000
47 hdd 0.27299 osd.47 up 1.00000 1.00000
48 hdd 0.27299 osd.48 up 1.00000 1.00000
49 hdd 0.27299 osd.49 up 1.00000 1.00000
50 hdd 0.27299 osd.50 up 1.00000 1.00000
51 hdd 0.27299 osd.51 up 1.00000 1.00000
52 hdd 0.27299 osd.52 up 1.00000 1.00000
53 hdd 0.27299 osd.53 up 1.00000 1.00000
54 hdd 0.27299 osd.54 up 1.00000 1.00000
55 hdd 0.27299 osd.55 up 1.00000 1.00000
56 hdd 0.27299 osd.56 up 1.00000 1.00000
57 hdd 0.27299 osd.57 up 1.00000 1.00000
58 hdd 0.27299 osd.58 up 1.00000 1.00000
59 hdd 0.89999 osd.59 up 1.00000 1.00000
Creemu i nostri propri rack virtuali è servitori cù blackjack è altre cose:
root@ceph01-q:~#ceph osd crush add-bucket rack01 root #создали новый root
root@ceph01-q:~#ceph osd crush add-bucket ceph01-q host #создали новый хост
root@ceph01-q:~#ceph osd crush move ceph01-q root=rack01 #переставили сервер в другую стойку
root@ceph01-q:~#osd crush add 28 1.0 host=ceph02-q # Добавили ОСД в сервер
# Если криво создали то можно удалить
root@ceph01-q:~# ceph osd crush remove osd.4
root@ceph01-q:~# ceph osd crush remove rack01I prublemi chì avemu scontru cumbattimentu cluster, quandu pruvate di creà un novu òspite è u move in un rack esistente - cumanda ceph osd crush move ceph01-host root=rack01 si congelava, è i monitori cuminciaru à cascà unu à unu. Aborting the command with a simple CTRL + C returned the cluster to the world of the living.
Una ricerca hà dimustratu stu prublema:
A suluzione hè stata per esse di dump crushmap è caccià a seccione da quì regula replicated_ruleset
root@ceph01-prod:~#ceph osd getcrushmap -o crushmap.row #Дампим карту в сыром виде
root@ceph01-prod:~#crushtool -d crushmap.row -o crushmap.txt #переводим в читаемый
root@ceph01-prod:~#vim crushmap.txt #редактируем, удаляя rule replicated_ruleset
root@ceph01-prod:~#crushtool -c crushmap.txt -o new_crushmap.row #компилируем обратно
root@ceph01-prod:~#ceph osd setcrushmap -i new_crushmap.row #загружаем в кластерAkhtung: Questa operazione pò causà un riequilibriu di u gruppu di piazzamentu trà l'OSD. Hè fattu questu per noi, ma assai pocu.
È a cosa strana chì avemu scontru in u cluster di teste hè chì dopu avè riavviatu u servitore OSD, si scurdanu chì sò stati spustati in novi servitori è rack, è tornanu à a radica predeterminata.
In u risultatu, avè assemblatu u schema finali in quale avemu creatu una radica separata per i drive ssd è una separata per i drive spindle, avemu pigliatu tutti l'OSD in rack è simpricimenti sguassate a radica predeterminata. Dopu u reboot, l'OSD hà cuminciatu à stà in u locu.
Dopu à scavà a documentazione dopu, avemu trovu un paràmetru chì hè rispunsevuli di stu cumpurtamentu. Circa ellu in a seconda parte
Cumu avemu fattu diversi gruppi per tipu di discu.
Per principià, avemu creatu dui radichi - per ssd è per hdd
root@ceph01-q:~#ceph osd crush add-bucket ssd-root root
root@ceph01-q:~#ceph osd crush add-bucket hdd-root rootSiccomu i servitori sò fisicamenti situati in diverse racks, per comodità avemu creatu racks cù servitori in elli
# Стойки:
root@ceph01-q:~#ceph osd crush add-bucket ssd-rack01 rack
root@ceph01-q:~#ceph osd crush add-bucket ssd-rack02 rack
root@ceph01-q:~#ceph osd crush add-bucket ssd-rack03 rack
root@ceph01-q:~#ceph osd crush add-bucket hdd-rack01 rack
root@ceph01-q:~#ceph osd crush add-bucket hdd-rack01 rack
root@ceph01-q:~#ceph osd crush add-bucket hdd-rack01 rack
# Сервера
root@ceph01-q:~#ceph osd crush add-bucket ssd-ceph01-q host
root@ceph01-q:~#ceph osd crush add-bucket ssd-ceph02-q host
root@ceph01-q:~#ceph osd crush add-bucket ssd-ceph03-q host
root@ceph01-q:~#ceph osd crush add-bucket hdd-ceph01-q host
root@ceph01-q:~#ceph osd crush add-bucket hdd-ceph02-q host
root@ceph01-q:~#ceph osd crush add-bucket hdd-ceph02-q hostè distribuitu i dischi sicondu i so tipi in diversi servitori
root@ceph01-q:~# Диски с 0 по 3 это SSD, находятся в ceph01-q, ставим их в сервер
root@ceph01-q:~# ssd-ceph01-q
root@ceph01-q:~#ceph osd crush add 0 1 host=ssd-ceph01-q
root@ceph01-q:~#ceph osd crush add 1 1 host=ssd-ceph01-q
root@ceph01-q:~#ceph osd crush add 2 1 host=ssd-ceph01-q
root@ceph01-q:~#ceph osd crush add 3 1 host=ssd-ceph01-q
root-ceph01-q:~# аналогично с другими серверамиDopu avè spargugliatu i dischi trà e rotte ssd-root è hdd-root, avemu lasciatu a root-default viota, cusì pudemu sguassà.
root-ceph01-q:~#ceph osd crush remove defaultIn seguitu, avemu bisognu di creà regule di distribuzione chì avemu da ligà à e piscine chì sò creatu - in e regule indicà quale radiche ponu mette i nostri dati di piscina è u livellu di unicità di a replica - per esempiu, e rèpliche deve esse in diversi servitori, o in diverse racks (pudete ancu in diverse radiche, se avemu una distribuzione cusì)
Prima di sceglie un tipu, hè megliu à leghje a documentazione:
root-ceph01-q:~#ceph osd crush rule create-simple rule-ssd ssd-root host firstn
root-ceph01-q:~#ceph osd crush rule create-simple rule-hdd hdd-root host firstn
root-ceph01-q:~# Мы указали два правила, в которых данные реплицируются
root-ceph01-q:~# между хостами - то есть реплика должна лежать на другом хосте,
root-ceph01-q:~# даже если они в одной стойке
root-ceph01-q:~# В продакшене, если есть возможность, лучше распределить хосты
root-ceph01-q:~# по стойкам и указать распределять реплики по стойкам:
root-ceph01-q:~# ##ceph osd crush rule create-simple rule-ssd ssd-root rack firstnEbbè, creemu piscine in quale vulemu almacenà l'imaghjini di discu di a nostra virtualizazione in u futuru - PROXMOX:
root-ceph01-q:~# #ceph osd pool create {NAME} {pg_num} {pgp_num}
root-ceph01-q:~# ceph osd pool create ssd_pool 1024 1024
root-ceph01-q:~# ceph osd pool create hdd_pool 1024 1024E dicemu à queste piscine chì regule di piazzamentu à aduprà
root-ceph01-q:~#ceph osd crush rule ls # смотрим список правил
root-ceph01-q:~#ceph osd crush rule dump rule-ssd | grep rule_id #выбираем ID нужного
root-ceph01-q:~#ceph osd pool set ssd_pool crush_rule 2
L'scelta di u numeru di gruppi di piazzamentu deve esse avvicinatu cù una visione preesistente per u vostru cluster - apprussimatamente quanti OSD seranu quì, chì quantità di dati (per centu di u voluminu tutale) seranu in a piscina, ciò chì hè. a quantità tutale di dati.
In u tutale, hè cunsigliatu di ùn avè più di 300 gruppi di piazzamentu nantu à u discu, è serà più faciule per equilibrà cù picculi gruppi di piazzamentu - vale à dì, se a vostra piscina sana piglia 10 Tb è hà 10 PG in questu - allora equilibrendu. da scaccià i mattoni di terabyte (pg) serà problematicu - pour a sabbia cù un granu di sabbia di piccula dimensione in buckets più faciule è più uniforme).
Ma avemu da ricurdà chì u più grande u numeru di PG, più risorse sò spese per calculà a so locu - a memoria è u CPU cumincianu à esse utilizati.
Una comprensione grossa pò , furnitu da i sviluppatori di a documentazione CEPH.
Lista di materiali:
Source: www.habr.com
