înregistrare Logare
Puncte:2
avatar Server

Cum să creșteți viteza RAID 5 cu mdadm + luks + lvm

drapel cn
Jayson Reis

Cred că sunt cam pierdut cu configurarea actuală a serverului. Este un HP Proliant dl160 gen 6, si am pus 4 discuri rotative cu un setup care are mdmadm + luks + lvm si pe deasupra btrfs (poate am mers prea departe?) si chiar sufera pe viteza IO la care citeste in jur 50MB/s și scrie în jur de 2MB/s și am senzația că am greșit ceva.

Unul dintre lucrurile pe care le-am observat este că am configurat mdadm pe dispozitivul bloc (sbd) și nu pe partiții (sdb1), ar afecta asta ceva?

Aici puteți vedea rezultatul fio fio --name=randwrite --rw=randwrite --direct=1 --bs=16k --numjobs=128 --size=200M --runtime=60 --group_reporting atunci când nu este aproape nici o utilizare pe mașină.

randwrite: (groupid=0, jobs=128): err= 0: pid=54290: Tue Oct 26 16:21:50 2021
  scrie: IOPS=137, BW=2193KiB/s (2246kB/s)(131MiB/61080msec); 0 zone resetate
    clat (msec): min=180, max=2784, avg=924,48, stdev=318,02
     lat (msec): min=180, max=2784, avg=924,48, stdev=318,02
    percentile clat (msec):
     | 1.00=[ 405], 5.00th=[ 542], 10.00th=[ 600], 20.00th=[ 693],
     | 30.00th=[ 760], 40.00th=[ 818], 50.00th=[ 860], 60.00th=[ 927],
     | 70,00=[ 1011], 80,00=[ 1133], 90,00=[ 1267], 95,00=[ 1452],
     | 99.00th=[ 2165], 99.50th=[ 2232], 99.90th=[ 2635], 99.95th=[ 2769],
     | 99.99th=[ 2769]
   bw ( KiB/s): min= 3972, max= 4735, per=100,00%, avg=4097,79, stdev= 1,58, mostre=8224
   iops : min= 132, max= 295, avg=248,40, stdev= 0,26, mostre=8224
  lat (msec): 250=0,04%, 500=2,82%, 750=25,96%, 1000=40,58%, 2000=28,67%
  lat (msec): >=2000=1,95%
  CPU : usr=0,00%, sys=0,01%, ctx=18166, majf=0, minf=1412
  Adâncimi IO: 1=100,0%, 2=0,0%, 4=0,0%, 8=0,0%, 16=0,0%, 32=0,0%, >=64=0,0%
     trimite: 0=0,0%, 4=100,0%, 8=0,0%, 16=0,0%, 32=0,0%, 64=0,0%, >=64=0,0%
     complet: 0=0,0%, 4=100,0%, 8=0,0%, 16=0,0%, 32=0,0%, 64=0,0%, >=64=0,0%
     rwts emise: total=0,8372,0,0 scurt=0,0,0,0 scăzut=0,0,0,0
     latență: țintă=0, fereastră=0, percentilă=100,00%, adâncime=1

Executați grupul de stare 0 (toate joburile):
  SCRIERE: bw=2193KiB/s (2246kB/s), 2193KiB/s-2193KiB/s (2246kB/s-2246kB/s), io=131MiB (137MB), rulare=61080-61080msec

Actualizați 1 scrieri secvențiale cu dd

root@hp-proliant-dl160-g6-1:~# dd if=/dev/zero of=disk-test oflag=direct bs=512k count=100
100+0 înregistrări în 100+0 înregistrări din 52428800 de octeți (52 MB, 50 MiB) copiați, 5,81511 s, 9,0 MB/s

Nuez: 5.4.0-89-generic

OS: Ubuntu 20.04.3

mdadm: 4.1-5ubuntu1.2

lvm2: 2.03.07-1ubuntu1

ieșire blkid

/dev/mapper/dm_crypt-0: UUID="r7TBdk-1GZ4-zbUh-007u-BfuP-dtis-bTllYi" TYPE="LVM2_member"
/dev/sda2: UUID="64528d97-f05c-4f34-a238-f7b844b3bb58" UUID_SUB="263ae70e-d2b8-4dfe-bc6b-bbc2251a9f32" TYPE="bt404b32"93ae70e-d2b8-4dfe-bc6b-bbc2251a9f32" TYPE="bt404ub58"93ae70e-d2b8-4dfe-bc6b-bbc2251a9f32"
/dev/sdb: UUID="478e8132-7783-1fb1-936a-358d06dbd871" UUID_SUB="4aeb4804-6380-5421-6aea-d090e6aea8a0" LABEL=":meunux"_id_server=":meunux"_idb
/dev/sdc: UUID="478e8132-7783-1fb1-936a-358d06dbd871" UUID_SUB="9d5a4ddd-bb9e-bb40-9b21-90f4151a5875" LABEL="linux"-IDserver="ubuntu"-TYserver="ubuntu"
/dev/sdd: UUID="478e8132-7783-1fb1-936a-358d06dbd871" UUID_SUB="f08b5e6d-f971-c622-cd37-50af8ff4b308" LABEL="linux"-IDserver="ubuntu"-IDserver="ubuntu"-TYPE
/dev/sde: UUID="478e8132-7783-1fb1-936a-358d06dbd871" UUID_SUB="362025d4-a4d2-8727-6853-e503c540c4f7" LABEL=":meu"_id25d4-a4d2-8727-6853-e503c540c4f7" LABEL=":meu"_id"
/dev/md0: UUID="a5b5bf95-1ff1-47f9-b3f6-059356e3af41" TYPE="crypto_LUKS"
/dev/mapper/vg0-lv--0: UUID="6db4e233-5d97-46d2-ac11-1ce6c72f5352" TYPE="swap"
/dev/mapper/vg0-lv--1: UUID="4e1a5131-cb91-48c4-8266-5b165d9f5071" UUID_SUB="e5fc407e-57c2-43eb-9b66-b00207eaTYPE="9btr"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/loop7: TYPE="squashfs"
/dev/loop8: TYPE="squashfs"
/dev/loop9: TYPE="squashfs"
/dev/loop10: TYPE="squashfs"
/dev/sda1: PARTUUID="fa30c3f5-6952-45f0-b844-9bfb46fa0224"

cat /proc/mdstat

Personalități: [raid6] [raid5] [raid4] [liniar] [multipath] [raid0] [raid1] [raid10]
md0 : raid5 activ sdb[0] sdc[1] sdd[2] sde[4]
      5860147200 blocuri super 1.2 nivel 5, 512k bucată, algoritm 2 [4/4] [UUUU]
      bitmap: 2/15 pagini [8KB], bucată de 65536KB

dispozitive nefolosite: <niciunul>

lshw -c disc

  *-disc
       descriere: disc SCSI
       produs: DT 101 G2
       furnizor: Kingston
       ID fizic: 0.0.0
       informații despre autobuz: scsi@0:0.0.0
       nume logic: /dev/sda
       versiunea: 1.00
       seria: xxxxxxxxxxxxxxxxxxxxx
       dimensiune: 7643 MiB (8015 MB)
       capacitati: detasabil
       configurație: ansiversion=4 logicalsectorsize=512 sectorsize=512
     *-mediu
          ID fizic: 0
          nume logic: /dev/sda
          dimensiune: 7643 MiB (8015 MB)
          capabilități: gpt-1.00 partitioned partitioned:gpt
          configurație: guid=6c166e3e-27c9-4edf-9b0d-e21892cbce41
  *-disc
       descriere: ATA Disk
       produs: ST2000DM008-2FR1
       ID fizic: 0.0.0
       info autobuz: scsi@1:0.0.0
       nume logic: /dev/sdb
       versiunea: 0001
       seria: xxxxxxxxxxxxxxxxxxxxx
       dimensiune: 1863 GiB (2TB)
       capacitati: detasabil
       configurație: ansiversion=5 logicalsectorsize=512 sectorsize=4096
     *-mediu
          ID fizic: 0
          nume logic: /dev/sdb
          dimensiune: 1863 GiB (2TB)
  *-disc
       descriere: ATA Disk
       produs: ST2000DM008-2FR1
       ID fizic: 0.0.0
       info autobuz: scsi@2:0.0.0
       nume logic: /dev/sdc
       versiunea: 0001
       seria: xxxxxxxxxxxxxxxxxxxxx
       dimensiune: 1863 GiB (2TB)
       capacitati: detasabil
       configurație: ansiversion=5 logicalsectorsize=512 sectorsize=4096
     *-mediu
          ID fizic: 0
          nume logic: /dev/sdc
          dimensiune: 1863 GiB (2TB)
  *-disc
       descriere: ATA Disk
       produs: WDC WD20EZBX-00A
       furnizor: Western Digital
       ID fizic: 0.0.0
       info autobuz: scsi@3:0.0.0
       nume logic: /dev/sdd
       versiunea: 1A01
       seria: xxxxxxxxxxxxxxxxxxxxx
       dimensiune: 1863 GiB (2TB)
       capacitati: detasabil
       configurație: ansiversion=5 logicalsectorsize=512 sectorsize=4096
     *-mediu
          ID fizic: 0
          nume logic: /dev/sdd
          dimensiune: 1863 GiB (2TB)
  *-disc
       descriere: ATA Disk
       produs: WDC WD20EZBX-00A
       furnizor: Western Digital
       ID fizic: 0.0.0
       info autobuz: scsi@4:0.0.0
       nume logic: /dev/sde
       versiunea: 1A01
       seria: xxxxxxxxxxxxxxxxxxxxx
       dimensiune: 1863 GiB (2TB)
       capacitati: detasabil
       configurație: ansiversion=5 logicalsectorsize=512 sectorsize=4096
     *-mediu
          ID fizic: 0
          nume logic: /dev/sde
          dimensiune: 1863 GiB (2TB)

Vedeți ceva care ar putea fi greșit în configurare? Credeți că ar fi util să adăugați un nvme cu o placă PCI și să îl folosiți pentru cache?

647
0 + 0
lvm
drapel us
Tero Kilkanen
Nu ar trebui să utilizați RAID5 dacă doriți fiabilitate. Atunci când o unitate se rupe, șansa de a se rupe a doua unitate în timpul resilvering este destul de mare. Când a doua unitate se rupe, toate datele dvs. se pierd.
2
Răspunde
drapel br
Chopper3
+1 la Tero - R5 a murit de peste un deceniu acum - prietenii nu-i lasă pe prieteni să folosească R5 :)
0
Răspunde
drapel cn
Jayson Reis
Bună, oameni buni, ce ați sugera pentru un acces mai rapid, o dimensiune mai mare și să fie în continuare redundant? Eram dispus să folosesc 1 hard disk pentru a obține 6TB și totuși să fiu în siguranță
0
Răspunde
Puncte:1
shodanshok avatar Server
drapel ca
shodanshok

Performanțele proaste înregistrate provin din diferiți factori:

  • discurile mecanice sunt pur și simplu foarte proaste la IO de citire/scriere aleatorie. A descoperi cat de rau pot fi, pur și simplu adăugați --sync=1 pentru dumneavoastră fio comanda (nuvelă: ei sunt incredibil rău, cel puțin în comparație cu controlerele RAID BBU adecvate sau cu SSD-uri protejate împotriva pierderii energiei);

  • RAID5 are o penalizare inerentă de scriere din cauza citirii/modificării/scrierii stripe. În plus, se recomandă cu tărie evita este pe discuri mecanice multi-TB din motive de siguranță. Având 4 discuri, vă rugăm să luați în considerare cu seriozitate utilizarea RAID10;

  • LUKS, care oferă criptare pe disc complet bazată pe software, are în mod inevitabil o taxă (semnificativă) atât la citire, cât și la scriere;

  • folosind BTRFS, LVM este total inutil. În timp ce un volum gras bazat pe LVM nu va afecta performanța într-un mod semnificativ în sine, totuși introduceți un alt strat IO și vă expuneți la (mai multe) probleme de aliniere;

  • în cele din urmă, BTRFS în sine nu este deosebit de rapid. În special citirile tale secvențiale lente pot fi urmărite la fragmentarea oribilă a BTRFS (din cauza faptului că este CoW și aplicarea granularității 4K - ca o comparație, pentru a obține performanțe bune de la ZFS, ar trebui să selectați în general înregistrări 64K-128K atunci când utilizați discuri mecanice).

Pentru a avea o comparație a performanței de bază, vă sugerez insistent să refaceți stiva dvs. de IO care măsoară viteza de citire/scriere aleatorie și secvențială la fiecare pas. Cu alte cuvinte:

  • creați o matrice RAID10 și rulați dd și fio pe matricea brută (fără un sistem de fișiere);

  • dacă este într-adevăr necesară criptarea completă a discului, utilizați LUKS pentru a crea un dispozitiv criptat și a rula din nou dd + fio pe dispozitivul criptat brut (din nou, fără sistem de fișiere). Comparați cu rezultatele anterioare pentru a vă face o idee despre ceea ce înseamnă din punct de vedere al performanței;

  • încerca ambii XFS și BTRFS (rulând modul obișnuit dd + fio quick bench) pentru a înțelege cum se comportă două sisteme de fișiere diferite. Dacă BTRFS este prea lent, încercați să îl înlocuiți cu lvmthin și XFS (dar amintiți-vă că în acest caz veți pierde suma de verificare a datelor utilizatorului, pentru care aveți nevoie de încă un strat - dmintegritate - el însuși comandând o lovitură semnificativă de performanță).

Dacă toate acestea par o mizerie, ei bine, chiar așa este. Făcând toate cele de mai sus, doar reduceți performanța stocării: trebuia să luați în considerare comportamentul real al aplicației (mai degrabă decât total secvenţial dd sau pur aleatoriu fio rezultate), rata de accesare a memoriei cache, alinierea modelului IO etc. Dar hei - puţini este mult mai bine decât nimic, deci să începem cu ceva de bază.

0 + 0
drapel cn
Jayson Reis
Deci, ce ați spune despre a avea luks apoi lvm cu ext4 vechi simplu și eliminarea tuturor fanteziei, ar fi mai bine la scrierile și citirile secvențiale? Am câteva aplicații care folosesc baze de date sqlite și scriu, de asemenea, fișiere de metadate locale: radarr, sonarr, readarr și plex, de exemplu, dar toate aceste citiri fac ca întregul sistem să sufere foarte mult. De asemenea, am avut multe probleme la rularea comenzilor precum kubectl get pod, deoarece creează multe fișiere mici pentru stocarea în cache, așa că pentru asta am montat un tmpfs pe acel folder, dar fac, așa că în cele din urmă voi ieși din memorie chiar și lucrând cu acest tip de efemer
0
Răspunde
drapel cn
Jayson Reis
Adică, habar n-am de ce am folosit lvm, înainte să fi folosit luks cu mdadm și ext 4
0
Răspunde
shodanshok avatar
drapel ca
shodanshok
fără LVM pierzi instantanee la nivel de bloc; dacă sistemul dvs. de fișiere nu le acceptă în mod nativ (ext3/4, xfs, etc) nu veți putea face niciun instantaneu. Numai tu poți evalua dacă/cât de mult pierderea instantaneelor ​​este importantă (sau nu). btrfs, pe de altă parte, are instantanee încorporate, deci nu are nevoie de LVM, dar mi s-a părut că performanța sa este destul de scăzută pentru orice altceva decât un simplu server de fișiere.
0
Răspunde
drapel cn
Jayson Reis
Mulțumesc foarte mult! L-am schimbat în raid 10 și am folosit luks + lvm + ext și a ajuns la 150MB/s la scriere
0
Răspunde
Puncte:1
Mike Andrews avatar Server
drapel ng
Mike Andrews

Versiunea scurtă: cred că este probabil ca problema ta să fie că folosește benchmark-ul tău scrieri aleatorii care sunt mult mai mici decât dimensiunea fragmentului RAID.

Este problema de performanță ceva pe care ați observat-o în timp ce utilizați sistemul? Sau doar că rezultatele benchmark-ului arată prost? Acest benchmark de scriere aleatorie de 16K se apropie de cel mai rău caz pentru acel RAID 5 cu o bucată mare de 512K.

RAID 5 are o bucată de paritate care trebuie actualizată împreună cu datele. Dacă ai avea o sarcină de lucru secvenţială pe care nucleul ar putea să o taie în 512K scrieri, ai calcula pur şi simplu noi informaţii de paritate, apoi ai scrie bucăţile de date şi fragmentele de paritate. O singură scriere se traduce în două scrieri.

Dar, cu scrieri de 16K care sunt mult mai mici decât dimensiunea fragmentului, trebuie să citiți mai întâi datele vechi și paritatea veche, apoi să calculați noile informații de paritate și apoi să scrieți noile date și paritatea. Asta înseamnă citire-citire-scriere-scriere. O scriere se traduce în patru I/O-uri. Cu scrieri aleatorii, nici cel mai bun controler RAID de pe planetă nu are nicio modalitate de a prezice ce bucăți să memoreze în cache.

Dacă utilizați matricea pentru a stoca fișiere mari, atunci aveți noroc: utilizați doar un benchmark greșit pentru a-i evalua performanța. Dacă te schimbi randwrite a pur si simplu scrie în benchmark-ul tău, astfel încât scrierile să fie secvențiale, ar trebui să fie mult mai bine!

Dar dacă volumul dvs. de lucru este într-adevăr format din scrieri mai mici aleatorii, atunci va trebui să schimbați ceva la matrice. Ai fi mai bine servit de un RAID 10 cu 4 discuri. Nu vă va zgudui lumea. Mi-aș imagina că performanța RAID 10 ar trebui să fie de 2x până la 3x față de cea pe care o ai acum, ceva de genul 275 până la 400 IOPS, poate de la 4 MiB/s la 6 MiB/s pe acel benchmark?

În ceea ce privește utilizarea unui SSD pentru a stoca în cache, poate cu ceva de genul bcache, ați elimina redundanța. Luați în considerare utilizarea unui RAID 1 din două SSD-uri pentru stocarea în cache? Cu siguranță nu aveți nevoie de NVMe aici, având în vedere viteza acestor unități. SATA ar fi bine.

(BTW, nu transpirați partițiile față de dispozitivele brute. Nu face o diferență. Personal, nu folosesc partiții.)

0 + 0
drapel cn
Jayson Reis
Bună, Mike, mulțumesc foarte mult pentru răspuns! Problema de performanță pe care am observat-o a fost în timpul utilizării sistemului. Mai întâi am făcut un simplu test dd scriind secvențiale 0 scrieri și totuși, nu a fost aproape de viteza acelui sata. Așa că doar pentru a vă arăta că l-am refăcut și am folosit site-ul de blocare al raidului, astfel încât să puteți vedea cum merge ``` root@hp-proliant-dl160-g6-1:~# dd if=/dev/zero of=disk-test oflag=direct bs=512k count=100 100+0 înregistrări în 100+0 înregistrări scoase 52428800 octeți (52 MB, 50 MiB) copiați, 5,81511 s, 9,0 MB/s ``` Am vrut raid 5 ca să pot folosi mai mult spc și să am în continuare siguranță în caz de eșec
0
Răspunde
Nikita Kipriyanov avatar
drapel za
Nikita Kipriyanov
... redundanța cache-ului SSD ar putea fi restabilită cu ușurință prin utilizarea *două* SSD-uri, construind o matrice RAID1 din ele și folosind *acea matrice* ca dispozitiv de stocare în cache.
1
Răspunde
Mike Andrews avatar
drapel ng
Mike Andrews
@JaysonReis, wow... asta e lent. Câteva idei: în primul rând, doar pentru a verifica starea de spirit, excludeți posibilitatea ca unitățile să se fi întors. Când faceți acest test, încercați `dd`, apoi repetați-l imediat după aceea. Luați cronometrarea din a 2-a rundă. De asemenea, ceea ce @shodanshok a descris mai jos este un sfat bun: Profilați direct RAID-ul, apoi adăugați straturi. Vedeți dacă vă puteți da seama ce strat cauzează problema.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.