Üdv,
Adott:
FreeNAS-9.1.1
Ennek kiajánlott ISCSI meghajtói fel vannak csatolva 1-1 debian 7 host-on (redundancia miatt) KVM guest-ek számára.
Hibajelenség:
A második host-on futó guestek esetén a fájlrendszer hiba miatt readonly módba vált.
A második host-on ping esetén csomagvesztést tapasztalok, és az alábbi üzenetet kapom syslogba:
Apr 8 14:11:47 nfbalance22 kernel: [ 7486.886110] connection2:0: detected conn error (1021)
Apr 8 14:11:48 nfbalance22 iscsid: Kernel reported iSCSI connection 2:0 error (1021 - ISCSI_ERR_SCSI_EH_SESSION_RST: Session was dropped as a result of SCSI error recovery) state (3)
Apr 8 14:11:50 nfbalance22 kernel: [ 7489.756554] connection1:0: detected conn error (1021)
Apr 8 14:11:51 nfbalance22 iscsid: Kernel reported iSCSI connection 1:0 error (1021 - ISCSI_ERR_SCSI_EH_SESSION_RST: Session was dropped as a result of SCSI error recovery) state (3)
Apr 8 14:11:59 nfbalance22 iscsid: connection2:0 is operational after recovery (1 attempts)
Apr 8 14:12:01 nfbalance22 iscsid: connection1:0 is operational after recovery (1 attempts)
FreeNAS oldalon
Apr 8 14:11:05 storage1 istgt[3039]: istgt_iscsi.c:3484:istgt_iscsi_transfer_in
_internal: ***ERROR*** iscsi_write_pdu() failed
Apr 8 14:11:05 storage1 istgt[3039]: istgt_iscsi.c:3853:istgt_iscsi_task_respon
se: ***ERROR*** iscsi_transfer_in() failed
Apr 8 14:11:05 storage1 istgt[3039]: istgt_iscsi.c:5392:sender: ***ERROR*** isc
si_task_response() CmdSN=15911 failed on iqn.storage1.netfabrik:nf-ns,t,0x0001(i
qn.1993-08.org.debian:01:2b1c6edaa,i,0x00023d010000)
Van valakinek erre megodása?
Hozzászólások
Csak futólag olvastam és lehet rosszul értelmezem, de ugyanaz azt az iscsi targetet használod 2 gépen? (Én úgy tudtam, hogy az "big no-no")
-
Valahogy biztosan meg lehet oldani mert nekem 2 db Proxmox clusterben használ közös ISCSI lemezt!
De én a clusterben adtam hozzá és mind a két gép látja, azaz írja és olvassa.
Igaz nem FreeNAS, hanem NetApp.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox
Érdekelne, hogyan van ilyenkor megoldva a file locking (nem tudom van e erre jó magyar kifejezés). Mi történik ha mindkét gép ugyanazt a file-t akarja írni? Hátha tudja valaki!
-
Ez nem is fájl zárolási kérdés már (az sima multi-user elérésnél érdekes, ahogy egy helyre van csak csatolva az FS, és többen érik el a tartalmát egy időben), hanem fájlrendszer szintű megosztási móka, mert itt több helyre van csatolva ugyan azt az FS. Ilyen felhasználásra "speciális" FS-ek léteznek, pl. GlusterFS, ceph, GFS, stb. Persze ezek közül nem mind való iSCSI Target fölé.
Az persze jó kérdés, hogy ezt a hibát a többszörös csatolás, istgt szoftver hiba vagy mondjuk hálózati átviteli hiba okozza. Az tény, hogy arra utal, a target nem tudta időben végrehajtani a parancsot. Azt az eredeti kérdező nem írta, hogy milyen FS van ezen a közös meghajtón.
Viszont nem FreeNAS jellegzetesség, mert ugyan erről a hibáról számolnak be SUSE, Red Hat és más disztrók esetében is. Sőt, Synology DSM-es ugyan ilyen hibáról is lehet olvasni.
.
Engem érdekelne, hogy mit volt a pont helyén eredetileg! Mert ugye a hibákból tanulna az ember, így én is.
Elvben nem tud ilyen történni a proxmoxban
Most lehet, hogy bődületes ökörségeket fogok írni, de pont most mélyedek a témában:
1. Proxmox cluster esetén vlm over iscsi-t ajánl.
( hup-os thread:http://hup.hu/node/126557 )
Másrészt a proxmox cluster egy pontos további része a linux fence, hogy a cluster pontosan tudja az egyes node-ok állapotát a problémák elkerülésének céljából.
http://forum.proxmox.com/threads/8623-Proxmox-2-node-cluster-fencing-de…
"Én úgy tudtam, hogy az "big no-no""
Már freenas esetén? Mert amúgy ez alapfunkció cluster-aware FS esetén. Én több ilyen win-es klasztert üzemeltetek, igaz Windows server 2012 R2 iSCSI targetjén, de nehezen hiszem, hogy ezt ne támogassa a freenas.
Arra gondoltam mikor azt írtam, hogy nem cluster filerendszer használatával két gépen egyszerre használni ugyanazt a lemezt.
-
> A második host-on futó guestek esetén a fájlrendszer hiba miatt readonly módba vált.
Milyen fájlrendszer? Ahhoz, hogy ugyanarról az iSCSI targetről két initiator-on is fel tudd csatolni ugyanazt a fájlrendszert, valamilyen cluster fájlrendszert kell használnod.
> A második host-on ping esetén csomagvesztést tapasztalok, és az alábbi üzenetet kapom syslogba:
Az iSCSI-nak nem kellene tudnia olyan hibát produkálnia, ami csomagvesztést okoz.
FreeNAS oldalon ZFS fájlrendszert használok.
A kiajánlott ISCSI meghajtó egy időben csak az egyik host-on aktív, azaz csak az egyik hoston fut egy időben a guest, így nam futhatunk file locking problémába.
A host redundancia miatt van mind a 2 hoston felcsatolva az ISCSI. Így ha elhasal az egyik host, a guest futtatását a másik host veszi át, de ehhez a migráláshoz az kell, hogy mind a 2 hoston állandóan fel legyen csatolva a kiajánlott ISCSI tárterület.
Minden guest Ubuntu 12.04. ext4 fájlrendszer. Az ISCSI csatoláson bekövetkező I/O hiba vált readonly módba. Ezt a hibát szeretném kiszűrni, de mint írtam egyszerre csak az egy hoston aktív egy guest, és az alatta futó ISCSI tárterület.
Ha fel van csatolva két helyre egy időben, akkor tekinthetjük két egyidejű élő csatolásnak a helyzetet. Szerintem az ext4 nem kezeli az ilyen szituációkat.
Ezen felül - nem ismerve az ext4 lelki világát részletesen - nem biztos, hogy semmilyen lemezművelet nem történik akkor, amikor Te azt hiszed, hogy nem történik. A kernel azt csinál az FS-en, amit akar, olyankor is (azaz főleg olyankor), amikor Te pont nem dolgozol rá (pl. defrag, fsck, akármi).
Ha aktív a kapcsolat, akkor olyan FS kellene, ami szereti a többszörös csatolást. Vagy csak akkor csatolod, mikor tényleg használni szeretnéd (mondjuk megállt a másik VM).
Teszteld úgy, hogy csak az egyik gépre van felcsatolva, aztán csak a másikra. Ha így nem fordul elő a hiba, akkor valószínű a nem cluster-képes FS az oka.
Szóval. A FreeNAs-on ZFS fájlrendszert használunk ami a FreeNAs sajátja. Gondolom azért dolgozik a FreeNas ZFS-el mert ez alkalmas a clusterezésre. Azután, hogy mi a kiajánlott ISCSI targeten amit felcsatolunk a guestre milyen fájlrendszert használunk az már irreleváns, hiszen ahhoz a fájlrendszerhez, csak az a guest nyúl amelyik éppen fut. Az összeomlás is csak akkor jelentkezik, ha migrálok. Jelenleg a két kvm host között live migration van kialakítva LCMC/HeartBeat/Pacemaker segítségével.
Sajnos virtuális gépek migrálása tekintetében nem tudok segíteni.
De a ZFS részt rosszul tudod, plusz a fenti hozzászólás alapján az iSCSI-t is...
Szóval a ZFS nem cluster FS, hanem (nagyon leegyszerűsítve) egy helyi FS, amibe hibatűrési és volume management funkciók is vannak. De iSCSI viszonylatban ez irreleváns.
Ugyanis az iSCSI lényege, hogy a kezdeményező (initiator, iSCSI "kliens") a célról (target, iSCSI "szerver") felcsatol egy blokk eszközt, ami pont ugyan úgy viselkedik a kezdeményezőn, mint egy helyben beépített HDD. Így az iSCSI-n felcsatolt eszközön lévő FS-t a kliens kezeli teljesen, az iSCSI target-nek (jelen esetben ez a FreeNAS) ahhoz semmi köze.
Ha a kliens erre a távoli "nyers" blokk eszközre nem cluster-képes FS-t tesz, aztán Te azt felcsatolod egy másik gépre is egyidejűleg (mondjuk a live migration során), akkor nyilván a kliens gépeken futó kerneleknek nem fog tetszeni, hogy más is matatja a szerinte saját FS-t.
Ha úgy jó, hogy az egyik VM-et leállítod, majd mikor leállt, a másikat elindítod, akkor biztos a kliensen használt FS lesz a ludas a hibában.
Hát nem fogjátok elhinni mi volt a gond. A négy hostból kettő-kettő clusterben van ugyebár. A clusterek 1-1 hostjai gond nélkül mentek a 2-2 hostjai hibáztak. Mind a két cluster kettes hostján a Linux sérült volt. Egy sima reinstall megoldotta a problémát. Ezek Dell 6100-as szerverek, amiben szervrenként 4 darab NOD van. Az 1. szerver NODjai a cluster 1-es HOSTjai a 2. szerver NODjai a cluster 2-es HOSjai. Valszeg szállításnál a második szerver kapott egy gellert, mert azon az oprendszerek már pingelésnél hibáztak.
Vigyázni kell ezekkel a linuxokkal, kicsit leejted aztán összekeverednek benne a bitek :D
De most komolyan, mi volt sérült? Ha a hdd lett badsectoros akkor a reinstall után is nagy eséllyel az. Pingelésnél hibázik? De reinstall után meg jó? wtf?
Én sem igazán értem, hogy a fent körülírt hibát miként tudja orvosolni az OS újratelepítése.
Ahogyan azt sem, hogy egy esetleges fizikai behatás miatt hogyan tud logikai hálózati hibákat produkálni egy szerver.
Ezért szerintem nem oldotta meg. Most épp nem jelentkezik a hiba, de azért ott van.