pool-ul nostru de backup ZFS produce erori ciudate de disc la scrierea datelor. Acest pool este replicat prin DRBD pe un al doilea server cu hardware identic, care se confruntă și cu aceleași erori. Acesta este motivul pentru care nu cred că este o problemă hardware.
Configurarea este următoarea (pe ambele servere):
- Server Debian 10 cu card de controler RAID Adaptec ASR 71605 în modul HBA. Toate discurile sunt expuse ca discuri RAW.
- Există două pool-uri (toate discurile sunt SSD-uri pentru centre de date):
- RAID-Z3 folosind opt discuri, funcționând fără probleme
- MIRROR folosind două discuri, obținând erori de disc
- Pool-urile au fiecare câte un volum ZFS creat pe ele (compresie=lz4)
- Volumele sunt sincronizate cu al doilea server prin DRBD (protocol C)
- Dispozitivul bloc expus de DRBD are volume LVM pe el care sunt expuse hipervizoarelor noastre prin iSCSI. Hypervisorii (XCP-ng) își gestionează discurile în mod transparent pe volumele iSCSI.
Toate discurile din pool-urile în oglindă au întâmpinat următoarele erori (nu simultan, ci în momente diferite):
10 noiembrie 18:00:09 st41 kernel: [240970.603991] sd 0:1:8:0: [sdi] tag#977 FAILED Rezultat: hostbyte=DID_ABORT driverbyte=DRIVER_OK
Nov 10 18:00:09 st41 kernel: [240970.603997] sd 0:1:8:0: [sdi] tag#977 CDB: Write(10) 2a 00 a8 20 31 67 00 01 00 00
10 noiembrie 18:00:09 st41 kernel: [240970.604000] print_req_error: eroare I/O, dev sdi, sector 2820682087
10 nov 18:00:09 st41 kernel: [240970.604065] zio pool=tank2 vdev=/dev/disk/by-id/ata-SAMSUNG_MZ7KH1T9HAJR-00005_S47PNA0R101405=101407-101407-00005_S47PNA0R101407-101407-101407-00005
10 noiembrie 18:00:10 st41 kernel: [240970.675209] aacraid: Solicitare de resetare a magistralei gazdă. SCSI se blochează?
10 noiembrie 18:00:10 kernel st41: [240970.675272] aacraid 0000:82:00.0: cmd remarcabil: nivel mediu-1
10 noiembrie 18:00:10 st41 kernel: [240970.675275] aacraid 0000:82:00.0: cmd excepțional: lowlevel-0
10 noiembrie 18:00:10 st41 kernel: [240970.675278] aacraid 0000:82:00.0: cmd restante: handler de erori-0
10 noiembrie 18:00:10 st41 kernel: [240970.675280] aacraid 0000:82:00.0: cmd excepțional: firmware-0
10 noiembrie 18:00:10 st41 kernel: [240970.675283] aacraid 0000:82:00.0: cmd excepțional: kernel-0
10 noiembrie 18:00:10 st41 kernel: [240970.675317] aacraid 0000:82:00.0: Tipul de resetare a controlerului este 3
10 noiembrie 18:00:10 st41 kernel: [240970.675358] aacraid 0000:82:00.0: Se emite resetarea IOP
10 noiembrie 18:00:45 st41 kernel: [241005.856763] aacraid 0000:82:00.0: Resetarea IOP a reușit
10 noiembrie 18:00:45 st41 kernel: [241005.879733] aacraid: Comm Interface type2 activat
10 noiembrie 18:00:54 st41 kernel: [241014.950498] aacraid 0000:82:00.0: Se programează rescanarea autobuzului
Primele patru linii ale jurnalului de mai sus apar de mai multe ori cu sectoare diferite și date CDB Write(10), dar în rest sunt aceleași. Acest lucru are loc întotdeauna în partea de sus a orei, exact când scripturile noastre de rezervă încep să scrie în acest pool.
Am încercat să actualizez pachetele ZFSonlinux, firmware-ul controlerului RAID și am încercat să conectez discurile la diferite sloturi de pe backplane. Rapoartele SMART ale discurilor nu arată deloc erori (și discurile sunt relativ noi).
Deoarece acest lucru se întâmplă pe ambele servere și cu toate cele patru discuri, nu cred că este o problemă hardware cu discurile sau controlerele RAID.
Singura diferență de configurare între discurile de pe ambele pool-uri pe care am găsit-o este că ARCCONF raportează Cache de scriere: activată (rescriere) pentru discurile pool oglindite, dar Cache de scriere: dezactivat (scriere prin scriere) pentru discurile de grup RAID-Z3. Nu am putut schimba acest mod cache deoarece ARCCONF spune că discurile sunt în modul RAW și nu acceptă stocarea în cache, așa că nu sunt sigur dacă raportul de configurare poate fi de încredere.
Nu sunt sigur ce să fac acum, orice ajutor este apreciat.
