Wahl der CEPH. Teil 1
Wir hatten fĂŒnf Racks, zehn optische Switches, konfiguriertes BGP, ein paar Dutzend SSDs und eine Reihe von SAS-Festplatten aller Farben und GröĂen sowie Proxmox und den Wunsch, die gesamte statische Aufladung in unseren eigenen S3-Speicher zu stellen. Nicht, dass dies alles fĂŒr die Virtualisierung notwendig gewesen wĂ€re, aber sobald Sie OpenSource verwendet haben, gehen Sie Ihrem Hobby bis zum Ende nach. Das einzige, was mich störte, war BGP. Es gibt niemanden auf der Welt, der hilfloser, verantwortungsloser und unmoralischer ist als das interne BGP-Routing. Und ich wusste, dass wir uns ziemlich bald darauf einlassen wĂŒrden.
Die Aufgabe war alltÀglich - es gab CEPH, es funktionierte nicht sehr gut. Es war notwendig, "gut" zu machen.
Der Cluster, den ich bekam, war heterogen, ausgepeitscht und praktisch nicht abgestimmt. Es bestand aus zwei Gruppen verschiedener Knoten, wobei ein gemeinsames Gitter sowohl die Rolle des Clusters als auch des öffentlichen Netzwerks spielte. Die Knoten wurden mit vier Festplattentypen gepackt - zwei Arten von SSDs, die zu zwei separaten Platzierungsregeln zusammengesetzt waren, und zwei Arten von Festplatten unterschiedlicher GröĂe, die zu einer dritten Gruppe zusammengefasst waren. Das Problem mit unterschiedlichen GröĂen wurde durch unterschiedliche OSD-Gewichte gelöst.
Die Einstellung selbst war in zwei Teile unterteilt: Optimieren des Betriebssystems und Optimieren des CEPH selbst und seiner Einstellungen.
Leveling OS
Netzwerk
Die hohe Latenz wirkt sich sowohl beim Aufnehmen als auch beim Balancieren aus. Bei der Aufzeichnung - da der Client keine Antwort auf die erfolgreiche Aufzeichnung erhĂ€lt, bis die Datenreplikate in anderen Platzierungsgruppen den Erfolg bestĂ€tigen. Da die Regeln fĂŒr die Verteilung von Replikaten in der CRUSH-Map ein Replikat pro Host hatten, wurde immer das Netzwerk verwendet.
Daher habe ich mich als erstes entschlossen, das aktuelle Netzwerk leicht zu konfigurieren, wĂ€hrend ich versuchte, mich davon zu ĂŒberzeugen, in separate Netzwerke zu wechseln.
Drehen Sie zunÀchst die Einstellungen der Netzwerkkarten. Begonnen mit dem Einrichten von Warteschlangen:
was war:
ethtool -l ens1f1root@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: 1
Es ist ersichtlich, dass die aktuellen Parameter weit von den Maximalwerten entfernt sind. Erhöht:
root@ceph01:~#ethtool -G ens1f0 rx 4096 root@ceph01:~#ethtool -G ens1f0 tx 4096 root@ceph01:~#ethtool -L ens1f0 combined 63
GefĂŒhrt von einem ausgezeichneten Artikel
https://blog.packagecloud.io/eng/2017/02/06/monitoring-tuning-linux-networking-stack-sending-data/
Die LÀnge der Versandwarteschlange von txqueuelen wurde von 1000 auf 10.000 erhöht
root@ceph01:~#ip link set ens1f0 txqueuelen 10000
Nun, folgen Sie der Dokumentation von Ceph selbst
https://ceph.com/geen-categorie/ceph-loves-jumbo-frames/
erhöhte MTU auf 9000.
root@ceph01:~#ip link set dev ens1f0 mtu 9000
Zu / etc / network / interfaces hinzugefĂŒgt, damit alle oben genannten Elemente beim Start geladen werden
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 9000
Danach begann er nach demselben Artikel, die 4.15-Kernel-Handles vorsichtig aufzuwickeln. In Anbetracht dessen, dass wir auf 128G RAM-Knoten eine bestimmte Konfigurationsdatei fĂŒr sysctl haben
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- bytes\2 -tcp_adv_win_scale # bytes â . tcp_adv_win_scale # , : # Bytes- bytes\2 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 . , # )
Mit Lustre Network wurde es auf separaten 10-Gbit / s-Netzwerkschnittstellen einem separaten Flachnetzwerk zugewiesen. Auf jedem Computer wurden Mellanox 10/25- Gbit / s-Dual-Port-Netzwerkkarten geliefert, die in zwei separaten 10-Gbit / s-Switches geliefert wurden. Die Aggregation wurde unter Verwendung von OSPF durchgefĂŒhrt, da das Verbinden mit lacp aus irgendeinem Grund eine Gesamtbandbreite von maximal 16 Gbit / s zeigte, wĂ€hrend ospf beide Dutzend auf jeder Maschine erfolgreich vollstĂ€ndig nutzte. ZukĂŒnftige PlĂ€ne waren die Verwendung von ROCE fĂŒr diese Melanoxe, um die Latenz zu verringern. So konfigurieren Sie diesen Teil des Netzwerks:
- Da die Maschinen selbst externe IPs auf BGP haben, benötigen wir Software - (oder besser gesagt, zum Zeitpunkt dieses Schreibens war es frr = 6.0-1 ) .
- Insgesamt hatten die Maschinen zwei Netzwerkschnittstellen mit zwei Schnittstellen - insgesamt 4 Ports. Eine Netzwerkkarte wurde ab Werk mit zwei Ports betrachtet und BGP wurde darauf konfiguriert, die zweite - an zwei Ports wurden zwei verschiedene Switches betrachtet und OSPF wurde darauf eingestellt
Details zum OSPF-Setup: Die Hauptaufgabe besteht darin, zwei Links zusammenzufassen und Fehlertoleranz zu haben.
Zwei Netzwerkschnittstellen werden in zwei einfachen flachen Netzwerken konfiguriert - 10.10.10.0/24 und 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 ens1f1
von denen Autos sich sehen.
DISK
Der nĂ€chste Schritt bestand darin, die Leistung der Festplatten zu optimieren. FĂŒr SSD habe ich den Scheduler auf noop geĂ€ndert , fĂŒr HDD - Deadline . Wenn grob - dann arbeitet NOOP nach dem Prinzip "Wer war zuerst auf - und Hausschuhe", was auf Englisch wie "FIFO (First In, First Out)" klingt. Anfragen werden in die Warteschlange gestellt, sobald sie verfĂŒgbar sind. DEADLINE ist schreibgeschĂŒtzter, und der Prozess aus der Warteschlange erhĂ€lt zum Zeitpunkt des Vorgangs fast ausschlieĂlich Zugriff auf die Festplatte. Dies ist groĂartig fĂŒr unser System - schlieĂlich funktioniert nur ein Prozess mit jeder Festplatte - der OSD-Daemon.
(Wer in den E / A-Planer eintauchen möchte, kann hier darĂŒber lesen:
http://www.admin-magazine.com/HPC/Articles/Linux-IO-Schedulers
Lesen Sie lieber auf Russisch: https://www.opennet.ru/base/sys/linux_shedulers.txt.html )
In Empfehlungen zur Optimierung von Linux wird empfohlen, auch nr_request zu erhöhen
nr_requests
Der Wert von nr_requests bestimmt die Anzahl der E / A-Anforderungen, die gepuffert werden, bevor der E / A-Scheduler Daten an das BlockgerĂ€t sendet / empfĂ€ngt, wenn Sie eine RAID-Karte / ein BlockgerĂ€t verwenden, die eine gröĂere Warteschlange als das I verarbeiten kann Der E / A-Scheduler ist auf eingestellt. Das Erhöhen des Werts von nr_requests kann dazu beitragen, die Serverlast zu verbessern und zu verringern, wenn groĂe E / A-Mengen auf dem Server auftreten. Wenn Sie Deadline oder CFQ als Scheduler verwenden, wird empfohlen, den Wert nr_request auf das Zweifache des Werts der Warteschlangentiefe festzulegen.
ABER! Die BĂŒrger selbst sind die CEPH-Entwickler, die uns davon ĂŒberzeugen, dass ihr PrioritĂ€tssystem besser funktioniert
WBThrottle und / oder nr_requestsWBThrottle und / oder nr_requests
Der Dateispeicher verwendet gepufferte E / A zum Schreiben. Dies bringt eine Reihe von Vorteilen mit sich, wenn sich das Dateispeicherprotokoll auf schnelleren Medien befindet. Clientanforderungen werden benachrichtigt, sobald die Daten in das Protokoll geschrieben und zu einem spĂ€teren Zeitpunkt mithilfe der Standard-Linux-FunktionalitĂ€t auf die Datenfestplatte selbst ĂŒbertragen werden. Dies ermöglicht es OSD-Spindelplatten, beim Schreiben in kleinen Paketen Schreiblatenzen Ă€hnlich wie bei SSDs bereitzustellen. Dieses verzögerte verzögerte Schreiben ermöglicht es dem Kernel selbst, die E / A-Anforderungen auf der Festplatte neu zu erstellen, in der Hoffnung, sie entweder zusammenzufĂŒhren oder den vorhandenen Plattenköpfen zu ermöglichen, einen optimaleren Pfad auf ihren Platten zu wĂ€hlen. Der Endeffekt besteht darin, dass Sie von jeder Festplatte etwas mehr E / A drĂŒcken können, als dies mit direkten oder synchronen E / A möglich wĂ€re.
Ein bestimmtes Problem tritt jedoch auf, wenn das Volumen der eingehenden DatensĂ€tze in einem bestimmten Ceph-Cluster allen Funktionen der zugrunde liegenden Festplatten voraus ist. In einem solchen Szenario kann die Gesamtzahl der ausstehenden E / A-SchreibvorgĂ€nge auf eine Festplatte unkontrolliert zunehmen und zu einer Warteschlange von E / A-VorgĂ€ngen fĂŒhren, die die gesamte Festplatten- und Ceph-Warteschlange fĂŒllen. Leseanforderungen funktionieren besonders schlecht, da sie zwischen Schreibanforderungen hĂ€ngen bleiben. Das Löschen auf die Hauptfestplatte kann einige Sekunden dauern.
Um dieses Problem zu beheben, verfĂŒgt Ceph ĂŒber einen im Dateispeicher integrierten RĂŒckschreib-Drosselungsmechanismus namens WBThrottle. Es wurde entwickelt, um die Gesamtzahl der ausstehenden Schreib-E / A-VorgĂ€nge zu begrenzen, die in die Warteschlange gestellt werden können, und um den RĂŒcksetzprozess frĂŒher zu starten, als dies aufgrund der Einbeziehung durch den Kernel selbst der Fall wĂ€re. Leider zeigen Tests, dass die Standardwerte das vorhandene Verhalten möglicherweise immer noch nicht auf ein Niveau reduzieren, das diesen Effekt auf die Latenz von LesevorgĂ€ngen verringern kann. Eine Anpassung kann dieses Verhalten Ă€ndern und die GesamtlĂ€nge der Aufzeichnungswarteschlangen verringern und eine solche Auswirkung nicht stark machen. Es gibt jedoch einen Kompromiss: Indem Sie die maximale Anzahl von EintrĂ€gen reduzieren, die in die Warteschlange gestellt werden dĂŒrfen, können Sie die FĂ€higkeit des Kernels selbst verringern, seine Effizienz bei der Bestellung eingehender Anforderungen zu maximieren. Es lohnt sich ein wenig darĂŒber nachzudenken, dass Sie mehr fĂŒr Ihre spezifische Anwendung und Workloads benötigen und sich an diese anpassen mĂŒssen.
Um die Tiefe einer solchen ausstehenden Schreibwarteschlange zu steuern, können Sie entweder die maximale Anzahl fehlgeschlagener E / A-VorgĂ€nge mithilfe der WBThrottle-Einstellungen verringern oder den Maximalwert fĂŒr fehlgeschlagene VorgĂ€nge auf Blockebene Ihres Kernels verringern. Sowohl das als auch ein anderes können das gleiche Verhalten effektiv steuern, und es sind Ihre PrĂ€ferenzen, die die Grundlage fĂŒr die Implementierung dieser Einstellung bilden.
Es sollte auch beachtet werden, dass die PrioritĂ€t des Ceph-Betriebssystems fĂŒr kĂŒrzere Abfragen auf Plattenebene effizienter ist. Wenn Sie die Gesamtwarteschlange auf eine bestimmte Festplatte reduzieren, wird der Hauptwarteschlangenstandort nach Ceph verschoben, wo Sie mehr Kontrolle darĂŒber haben, welche PrioritĂ€t die E / A-Operation hat. Betrachten Sie das folgende Beispiel:
echo 8 > /sys/block/sda/queue/nr_requests
http://onreader.mdl.ru/MasteringCeph/content/Ch09.html#030202
GEMEINSAM
Und noch ein paar Kernel-Einstellungen Ihr Auto ist weich und seidig DrĂŒcken Sie etwas mehr Leistung aus Eisen
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 # ,, , .
Tauchen Sie bei CEPH
Einstellungen, auf die ich nÀher eingehen möchte:
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: 4
Einige Parameter, die in Version 12.2.12 auf QA getestet wurden, fehlen in ceph Version 12.2.2, z. B. osd_recovery_threads. Daher enthielten die PlÀne eine Aktualisierung des Produkts auf 12.2.12. Die Praxis hat gezeigt, dass ein Cluster der Versionen 12.2.2 und 12.2.12 kompatibel ist, was ein fortlaufendes Update ermöglicht.
Testcluster
Zum Testen war es natĂŒrlich notwendig, die gleiche Version wie im Kampf zu haben, aber als ich anfing, mit dem Cluster im Repository zu arbeiten, gab es nur eine neuere. Da Sie in der Nebenversion nicht sehr groĂ sind ( 1393 Zeilen in Konfigurationen gegenĂŒber 1436 Zeilen in der neuen Version), haben wir beschlossen, eine neue zu testen (sie ist immer noch aktualisiert, warum sollten Sie den alten Papierkorb verwenden)?
Das einzige, was sie versuchten, die alte Version zu verlassen, war das ceph-deploy- Paket , da ein Teil der Dienstprogramme (und ein Teil der Mitarbeiter) durch seine Syntax geschÀrft wurde. Die neue Version war ganz anders, hatte jedoch keine Auswirkungen auf den Betrieb des Clusters selbst, und die Versionen 1.5.39 haben sie verlassen
Da der Befehl ceph-disk eindeutig angibt, dass er veraltet ist und den Befehl ceph-volume verwendet, meine Lieben, haben wir mit diesem Befehl begonnen, das OSD zu erstellen, ohne Zeit mit dem Veralten zu verschwenden.
Der Plan war, einen Spiegel aus zwei SSD-Festplatten zu erstellen, auf denen wir die OSD-Protokolle ablegen, die sich wiederum auf den Spindel-SASs befinden. So können wir uns vor Datenproblemen schĂŒtzen, wenn eine Festplatte mit einem Protokoll herunterfĂ€llt.
Erstellen Sie einen Cluster mit Stahldokumentationen
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-q
, ceph-deploy 12.2.12 â OSD db -
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sde --block.db /dev/md0 blkid could not detect a PARTUUID for device: /dev/md1
, blkid PARTUUID, :
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 "n\n\n\n+5G\nw" | fdisk /dev/md0; done
, OSD (, , )
OSD bluestore WAL, 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 argumen
- ( , ) WAL OSD â ( WAL, , , ).
, WAL NVMe, .
root@ceph01-qa:~#ceph-volume lvm create --bluestore --data /dev/sdf --block.wal /dev/md0p2 --block.db /dev/md1p2
, OSD. , â SSD , SAS.
20 , , â .
, , :
ceph osd treeroot@eph01-q:~# ceph osd tree
ID CLASS WEIGHT TYPE NAME 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
:
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 rack01
, , â ceph osd crush move ceph01-host root=rack01 , . CTRL+C .
: https://tracker.ceph.com/issues/23386
crushmap rule 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 #
: placement group OSD. , .
, â , OSD , , root default.
, , root ssd , default root. OSD .
, .
.
root- â ssd hdd
root@ceph01-q:~#ceph osd crush add-bucket ssd-root root root@ceph01-q:~#ceph osd crush add-bucket hdd-root root
â
# : 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
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:~#
ssd-root hdd-root root-default ,
root-ceph01-q:~#ceph osd crush remove default
, â root â , ( root, )
:
http://docs.ceph.com/docs/jewel/rados/operations/crush-map/#crushmaprules
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 firstn
, â 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 1024
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
â , ( ) , .
300 , â 10 Tb 10 PG â (pg) â ).
PG â â .
, CEPH.
:
https://blog.packagecloud.io/eng/2017/02/06/monitoring-tuning-linux-networking-stack-sending-data
http://www.admin-magazine.com/HPC/Articles/Linux-IO-Schedulers
http://onreader.mdl.ru/MasteringCeph/content/Ch09.html#030202
https://tracker.ceph.com/issues/23386
https://ceph.com/pgcalc/