Choix du CEPH. Partie 1
Nous avions cinq racks, dix commutateurs optiques, BGP configuré, une douzaine de SSD et un tas de disques SAS de toutes les couleurs et tailles, ainsi que du proxmox et le désir de mettre toute la statique dans notre propre stockage S3. Non pas que tout cela était nécessaire pour la virtualisation, mais une fois que vous avez commencé à utiliser opensource, passez à la fin de votre passe-temps. La seule chose qui me dérangeait était BGP. Il n'y a personne au monde plus impuissant, irresponsable et immoral que le routage BGP interne. Et je savais que très bientôt nous y plongerions.
La tâche était courante - il y avait le CEPH, cela ne fonctionnait pas très bien. Il fallait faire "bien".
Le cluster que j'ai obtenu était hétérogène, fouetté et pratiquement pas réglé. Il se composait de deux groupes de nœuds différents, avec une grille commune jouant le rôle de cluster et de réseau public. Les nœuds étaient équipés de quatre types de disques - deux types de SSD, assemblés en deux règles de placement distinctes et deux types de disques durs de tailles différentes, assemblés en un troisième groupe. Le problème avec différentes tailles a été résolu par différents poids OSD.
Le paramètre lui-même était divisé en deux parties: le réglage du système d'exploitation et le réglage du CEPH lui - même et de ses paramètres.
Mise à niveau du système d'exploitation
RĂ©seau
Une latence élevée affectait à la fois l'enregistrement et l'équilibrage. Lors de l'enregistrement - parce que le client ne reçoit pas de réponse sur l'enregistrement réussi jusqu'à ce que les répliques de données dans d'autres groupes de placement confirment le succès. Étant donné que les règles de distribution des répliques dans la carte CRUSH comportaient une réplique par hôte, le réseau était toujours utilisé.
Par conséquent, la première chose que j'ai décidé de configurer légèrement le réseau actuel, tout en essayant de me convaincre de passer à des réseaux distincts.
Tout d'abord, tordu les paramètres des cartes réseau. Commencé par la mise en place de files d'attente:
ce qui Ă©tait:
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
On voit que les paramètres actuels sont loin d'être des maximums. Augmenté:
root@ceph01:~#ethtool -G ens1f0 rx 4096 root@ceph01:~#ethtool -G ens1f0 tx 4096 root@ceph01:~#ethtool -L ens1f0 combined 63
Guidé par un excellent article
https://blog.packagecloud.io/eng/2017/02/06/monitoring-tuning-linux-networking-stack-sending-data/
augmentation de la longueur de la file d' attente de txqueuelen de 1000 Ă 10 000
root@ceph01:~#ip link set ens1f0 txqueuelen 10000
Eh bien, en suivant la documentation de ceph elle-mĂŞme
https://ceph.com/geen-categorie/ceph-loves-jumbo-frames/
augmentation du MTU Ă 9000.
root@ceph01:~#ip link set dev ens1f0 mtu 9000
Ajouté à / etc / network / interfaces, de sorte que tout ce qui précède est chargé au démarrage
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
Après quoi, suivant le même article, il a commencé à remonter soigneusement les poignées du noyau 4.15. Considérant que sur les nœuds de RAM 128G, nous avons obtenu un certain fichier de configuration pour 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- 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 . , # )
Avec un réseau lustré , il a été alloué sur des interfaces réseau 10 Gbit / s distinctes à un réseau plat distinct. Les cartes réseau Mellanox 10/25 Gbit / s à deux ports livrées dans deux commutateurs 10 Gbit / s distincts ont été livrées sur chaque machine. L'agrégation a été réalisée en utilisant OSPF, car la liaison avec lacp pour une raison quelconque a montré une bande passante totale d'un maximum de 16 Gbps, tandis que ospf a utilisé avec succès les deux douzaines sur chaque machine. Les plans futurs étaient d'utiliser ROCE sur ces mélanoxes pour réduire la latence. Comment configurer cette partie du réseau:
- Puisque les machines elles-mêmes ont des IP externes sur BGP, nous avons besoin d'un logiciel - (ou plutôt, au moment de la rédaction de ce document, c'était frr = 6.0-1 ) déjà installé.
- Au total, les machines avaient deux interfaces réseau avec deux interfaces - un total de 4 ports. Une carte réseau a regardé l'usine avec deux ports et BGP a été configuré dessus, la seconde - sur deux ports a regardé deux commutateurs différents et OSPF a été réglé dessus
Détails de configuration OSPF: La tâche principale consiste à agréger deux liens et à avoir une tolérance aux pannes.
deux interfaces réseau sont configurées dans deux réseaux plats simples - 10.10.10.0/24 et 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
par lequel les voitures se voient.
DISK
L'étape suivante consistait à optimiser les performances des disques. Pour SSD, j'ai changé le planificateur en noop , pour HDD - date limite . Si à peu près - alors NOOP fonctionne sur le principe de "qui s'est levé en premier - et des pantoufles", qui en anglais ressemble à "FIFO (First In, First Out)". Les demandes sont mises en file d'attente dès qu'elles sont disponibles. DEADLINE est plus en lecture seule, et le processus de la file d'attente obtient un accès presque exclusif au disque au moment de l'opération. C'est très bien pour notre système - après tout, un seul processus fonctionne avec chaque disque - le démon OSD.
(Ceux qui souhaitent s'immerger dans le planificateur d'E / S peuvent en lire plus ici:
http://www.admin-magazine.com/HPC/Articles/Linux-IO-Schedulers
Je préfère lire en russe: https://www.opennet.ru/base/sys/linux_shedulers.txt.html )
Dans les recommandations pour l'optimisation de Linux, il est conseillé d'augmenter également nr_request
nr_requests
La valeur de nr_requests détermine la quantité de demandes d'E / S qui sont mises en mémoire tampon avant que le planificateur d'E / S envoie / reçoive des données au périphérique de bloc, si vous utilisez une carte RAID / périphérique de bloc qui peut gérer une file d'attente plus grande que ce que le I Le planificateur d'E / S est défini sur, l'augmentation de la valeur de nr_requests peut aider à améliorer l'ensemble et à réduire la charge du serveur lorsque de grandes quantités d'E / S se produisent sur le serveur. Si vous utilisez Deadline ou CFQ comme planificateur, il est conseillé de définir la valeur nr_request sur 2 fois la valeur de la profondeur de file d'attente.
MAIS! Les citoyens eux-mêmes sont les développeurs du CEPH qui nous convainc que leur système de priorité fonctionne mieux
WBThrottle et / ou nr_requestsWBThrottle et / ou nr_requests
Le stockage de fichiers utilise des E / S tamponnées pour écrire; cela apporte un certain nombre d'avantages si le journal de stockage de fichiers se trouve sur un support plus rapide. Les demandes des clients sont notifiées dès que les données sont écrites dans le journal, puis vidées sur le disque de données lui-même ultérieurement à l'aide de la fonctionnalité Linux standard. Cela permet aux disques de broche OSD de fournir des latences d'écriture similaires aux SSD lors de l'écriture en petits paquets. Cette écriture différée retardée permet également au noyau lui-même de reconstruire les demandes d'E / S sur le disque dans l'espoir de les fusionner ou de permettre aux têtes de disque existantes de choisir un chemin plus optimal au-dessus de leurs plaques. L'effet final est que vous pouvez extraire légèrement plus d'E / S de chaque disque que ce ne serait possible avec des E / S directes ou synchrones.
Cependant, un certain problème se pose si le volume d'enregistrements entrants dans un cluster Ceph donné est en avance sur toutes les capacités des disques sous-jacents. Dans un tel scénario, le nombre total d'E / S en attente d'écriture en attente sur un disque peut augmenter de manière incontrôlable et entraîner une file d'attente d'opérations d'E / S qui remplissent l'intégralité du disque et les files d'attente Ceph. Les demandes de lecture fonctionnent particulièrement mal, car elles se bloquent entre les demandes d'écriture, ce qui peut prendre plusieurs secondes pour être vidée sur le disque principal.
Pour vaincre ce problème, Ceph a un mécanisme de limitation de réécriture appelé WBThrottle intégré au stockage de fichiers. Il est conçu pour limiter le nombre total d'opérations d'E / S d'écriture en attente qui peuvent être mises en file d'attente et démarrer leur processus de réinitialisation plus tôt que cela ne se produirait naturellement en raison de l'inclusion par le noyau lui-même. Malheureusement, les tests démontrent que les valeurs par défaut ne peuvent toujours pas réduire le comportement existant à un niveau qui peut réduire cet effet sur la latence des opérations de lecture. L'ajustement peut changer ce comportement et réduire la longueur totale des files d'attente d'enregistrement et rendre un tel impact peu fort. Cependant, il y a un compromis: en réduisant le nombre maximal total d'entrées pouvant être mises en file d'attente, vous pouvez réduire la capacité du noyau lui-même à maximiser son efficacité dans la commande des demandes entrantes. Cela vaut la peine de penser que vous avez besoin de plus pour votre application spécifique, vos charges de travail et ajustez-les en conséquence.
Pour contrôler la profondeur d'une telle file d'attente d'écriture en attente, vous pouvez soit réduire le nombre maximal total d'opérations d'E / S ayant échoué à l'aide des paramètres WBThrottle, soit diminuer la valeur maximale des opérations ayant échoué au niveau même du bloc de votre noyau. Cela et un autre peuvent contrôler efficacement le même comportement et ce sont vos préférences qui seront la base de la mise en œuvre de ce paramètre.
Il convient également de noter que la priorité du système d'exploitation Ceph est plus efficace pour les requêtes plus courtes au niveau du disque. Lors de la réduction de la file d'attente globale à un disque donné, l'emplacement de la file d'attente principale se déplace vers Ceph, où il a plus de contrôle sur la priorité de l'opération d'E / S. Prenons l'exemple suivant:
echo 8 > /sys/block/sda/queue/nr_requests
http://onreader.mdl.ru/MasteringCeph/content/Ch09.html#030202
COMMUN
Et quelques paramètres de noyau supplémentaires à faire votre voiture est douce et soyeuse presser un peu plus de performances en fer
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 # ,, , .
Plongez au CEPH
Paramètres sur lesquels je voudrais m'attarder plus en détail:
chat /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
Certains paramètres qui ont été testés sur QA sur la version 12.2.12 sont manquants dans ceph version 12.2.2, par exemple, osd_recovery_threads. Par conséquent, les plans incluaient une mise à jour de la prod au 12.2.12. La pratique a montré la compatibilité dans un cluster de versions 12.2.2 et 12.2.12, ce qui permet une mise à jour continue.
Cluster de test
Naturellement, pour les tests, il était nécessaire d'avoir la même version que dans la bataille, mais au moment où j'ai commencé à travailler avec le cluster dans le référentiel, il n'y en avait qu'une plus récente. Voyant que dans la version mineure, vous n'êtes pas très volumineux ( 1393 lignes dans les configurations contre 1436 lignes dans la nouvelle version), nous avons décidé de commencer à tester une nouvelle (elle est toujours mise à jour, pourquoi continuer sur l'ancienne corbeille)
La seule chose qu'ils ont essayé de quitter l'ancienne version est le package ceph-deploy, car une partie des utilitaires (et une partie des employés) a été affinée par sa syntaxe. La nouvelle version était assez différente, mais elle n'a pas affecté le fonctionnement du cluster lui-même, et les versions 1.5.39 l'ont laissé
Étant donné que la commande ceph-disk indique clairement qu'elle est obsolète et que nous utilisons, chère, la commande ceph-volume - nous avons commencé à créer l'OSD avec cette commande, sans perdre de temps sur l'obsolète.
Le plan était de créer un miroir de deux disques SSD, sur lesquels nous plaçons les journaux OSD, qui, à leur tour, sont situés sur les SAS de la broche. Ainsi, nous pouvons nous protéger des problèmes de données lorsqu'un disque avec un journal tombe.
Créer un cluster de documentation acier
chat /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/