ibm storwize v3700 inter-canister pcie link failure

Szerverek

Sziasztok!

Érdekelne, hogy akinek van tapasztalata IBM Storwize v3700 -zal, az mit szól ehhez?

Történt, hogy ma éjjel bejelzett a monitoring rendszer, hogy pár vm nem válaszol ping-re.... Ezek egy vSphere ESXi hoston futnak.
Az ESXi-n három datastore van, amik 10Gbit iscsi -n egy IBM Storwize v3700-ról jönnek, s a vSphere Client "Browse Datastore" -ra nyomva csak pörög, pörög, de nem mutat semmit.... (mint amikor leszakad az iscsi kapcsolat).
Tehát a storage-vel lesz valami.

A Storwize v3700 azt mutatja, hogy "Inter-canister PCIe link failure" esete áll fenn, s a lemeztömb degraded (ezt mindegy egyes fizikai lemez mellé is kiírja, tehát minden egyes fizikai lemeznek "Degraded" a statusza, továbbá a Storwize -n létező mindhárom volume is degraded (amik iscsi -n vannak datastore -nak felcsatolva az előbb említett ESXi-re).
Tehát kb. így tökön szúrta magát, és áll az egész, de nagyon durván.

Nyílván az IBM support leírása alapján fogunk eljárni, az IBM support segítségét tervezzük igénybe venni, de felteszem azért itt is a kérdést:
- találkozott -e már valaki ilyesmivel?
- szerintetek van-e esély arra, hogy akár egy power off-on cycle után magához tér, a lemeztömb feláll, és menthető róla minden?
- van-e valami lehetőség az adatok biztonságba helyezésére?
- a rosszként jelölt canister eltávoltása után elindítható-e mind a három volume a működő canisteren, feláll-e a tömb, számítsunk-e adatvesztésre?
- hogy a fenébe fordulhat elő az, hogy egy elvileg teljesen redundáns aktiv/aktiv storage így tökönszúrja magát?? a másik canisterről miért nem működik simán tovább, észrevétlenül???

(Kérem, hogy aki még nem is látott ilyet, nem dolgozott ilyennel, nem látott még brand storaget, az ne okoskodjon/trollkodjon bele, mert nem ezért nyitottam ezt a topicot, hanem azért, hogy hátha valaki hozzáértő, tapasztalt ember tényleg erre jár, s tud adni egy-két hasznos tanácsot (azon kívül, hogy fejszével verjük szét a szerverterem udvarán)).

Köszi előre is!

(A témabesorolás nem pontos, mert storage, vagy arra hasonltó kategóriát nem találtam, de ez volt a legközelebb hozzá....)

  • 11834 megtekintés

( freeoli v | 2016. 03. 13., v – 10:12 )

Tömören:
- Nem, nem is jellemző, de IBM esetén mindig számolni kell anomáliákkal.
- Igen az esélyes de a hiba okán előtte, alatt és utána is ellenőrizném az összeköttetéseket mert lehet, hogy egymás után mindkét loop halt le.
- Az adatok megvannak, a lemezen vannak, de ahogy sejtem nincs mentésetek :(.
- A jó cansiter működni fog, de az eltávolítottra masszívan fog sírni. Ne távolítsátok el a konfigból, maradjon csak missing meg fail, a lényeg, hogy ne felejtse el a konfigot róla mert akkor már bűvészkedni kell az adatokért.
- Azért mert IBM, ha nincs support rá akkor időzített bomba. Azért ez nem egy jellemző hiba.

Kosz sikerult console trukkokkel onlineba rakni ejjel, latszik minden datastore, varjuk a csere canistert.
Adatvesztes nincs ugy nez ki, backup azert van de nem csak sajat cucc van rajta es azokrol nem tudni van-e backup... Mindenesetre most lesz azokrol is biztos ami biztos. No meg a backup az adatokrol egy dolog de 30-40 vm-et ujrahuzni (wannak windowsok is) es az adatokat visszatolteni nem kis munka, ezert nem mindegy hogy megvannak-e a storageon az adatok es elerhetok-e vagy par napos szopas es leallas visszaallitani mindent.
Egyebkent durva a szitu hogy ez elofordulhat. Es az utolso bizadalom is elment a brand storagektol.... :(

Szerk: iscsi osszekottetesek rendben levonek tunnek fizikailag, egyszeruen ahogy bedobta a storage az inter-canister pcie link hibat, nem vette at csendben a masik a munkat (dacara higy aktiv/aktiv dobozrol van szo es redundans iscsi kapcsolatrol (ellenorzotten), hanem felmutatta a feher zaszlot es megadta magat. ESXi meg akkor ugy gondolta hogy o is a storage melle terdel hiszen nem elerheto egyik iscsi path se egy darabig... Vagy valami ilyesmi lehetett a scenario.

Sikerult visszahozni a datastoreokat.
Az esxi is ludas volt!
Ami latszik: canister2 bedobta az inter canister link errort.
A masik nem vette at azonnal a mukodest hanem percekkel kesobb csak.
Ez azt eredmenyezte hogy az esxi dobott egy eventlogot hogy xxxx iscsi path tobb mint 30 masodperce nem valaszol. Es meg sem probalta a masik pathot, vagy nem tudom, ez nem derul ki.
Ezt loggolta meg 3 alkalommal.
A futo freebsd vmek beragadtak, esxi-cli bol sem lehetett leloni oket!
A datastoreok elerhetetlensege miatt linux es windows vmek nem kerultek ilyen allapotba, azokat le lehetett allitani.
Amikor minden vm eroszakkal leallitasra kerult, hopp, az esxi atkapcsolt a masik iscsi path-ra es latszanak a datastoreok es a vmek is elindulnak.
Ezt igy hogy?!
Na mindegy. Jelenleg megy a backup a vmdk-krol aztan majd meglatjuk.
(Support szerzodes amugy nincs csak sima garancia a storwize on.)
Ha a vmdk-k lent vannak, akkor majd jon az hogy konzolbol a rossz canister poweroff on, s firmware frissites, kozben kollega beszel ibm azert mielott ennek nekiall, hogy mi legyen.

"No meg a backup az adatokrol egy dolog de 30-40 vm-et ujrahuzni (wannak windowsok is) es az adatokat visszatolteni nem kis munka, ezert nem mindegy hogy megvannak-e a storageon az adatok es elerhetok-e vagy par napos szopas es leallas visszaallitani mindent."

Többek között ilyen esetben nagyon hasznos VM szintű mentéssel rendelkezni. Nem okoskodásként írom, hanem jó tanácsként. Nem szeretnék reklám felületet nyitni: javaslom, nézz körül (elég sok szoftver van erre a célra, a VMware-nek is a maga korlátaival akár ingyenesen), ha érdekel tapasztalat, írjál.

Tároló téma, "hogy a fenébe fordulhat elő az, hogy egy elvileg teljesen redundáns aktiv/aktiv storage így tökönszúrja magát?? a másik canisterről miért nem működik simán tovább, észrevétlenül???"

Sajnos van ilyen, hogy "mégsem redundáns tároló". Persze elég aljas egy hiba, és jó eséllyel lehet még 1-2 chip, aminek a meghibásodása kérdés, miként van kezelve.

Ezzel kapcsolatban: az egy vezérlőn ("canister") levő iSCSI portok egy kártyán vannak vagy sem, ha egy kártyán vannak, akkor miként oldja meg a tároló a kártya hibáját. Amennyire sikerült kiderítenem IBM doksiból, iSCSI esetén csak az egyik vezérlőhöz van útvonal, azaz kérdés, milyen hiba felismerési eljárás van, illetve hiba esetén mit lép a tároló?

A "kéne jobb esetben" helyett pontos műszaki leírás hasznosabb lenne, mert a szálat indító eset is azért születhetett meg, mert nem a "kéne jobb esetben" felállás a valóság.

Ha van egy LUN-od ("volume"), annak van egy "preferred" vezérlője (= canister, node). A
http://www.redbooks.ibm.com/redbooks/pdfs/sg247521.pdf, 85. oldal (2.9.4-es fejezet) szerint a failover nem úgy történik, hogy a másik vezérlő IP címén lesz elérhető a LUN, hanem az "preferred" vezérlő IP címe és iSCSI identitása megy át a másik vezérlőre. Ebből implicit következik, hogy a "host"-ok irányából minden LUN-hoz mindössze két aktív útvonal van.
Ezen két útvonal nyilván lehet aktív-aktív, de ez önmagában semmit nem old meg, mert mindkettő ugyanazon a hálókártyán keresztül él. Ha ez két útvonal elhal a hálókártya hibája miatt, akkor az ESXi számára nincs lehetőség másik kapcsolatra. Kérdés, hogy ezt a tároló érzékeli-e (beleértve olyan sunyi hibát is, hogy az interfész látszólag "up", csak éppen adatforgalmazás nincs), ha igen, akkor tud-e rá reagálni?

FC esetén jobbnak tűnik a helyzet, mert a LUN a másik vezérlőn át is elérhető (ALUA), konkrét mérések is vannak a késleltetés növekedésre, de magára a hibakezelésre ez esetben sem találtam leírást.

"teljesen aktiv-aktivkent lehet futtatni a pathokat" - igen, de ez nem teljesen igaz, mivel nem egyformán hatékonya bármely vezérlőn adott kötet elérése, lásd fenti PDF 257. oldala: "Update: From vSphere version 5.5 and on, VMware multipath driver fully supports SAN Volume Controller/Storwize V7000 ALUA preferred path algorithms. VMware administrators should choose Round Robin and validate that VMW_SATP_ALUA is displayed. This reduces operational overhead and improves cache hit rate by sending the I/O to the preferred node."

"a szálat indító eset is azért születhetett meg, mert nem a "kéne jobb esetben" felállás a valóság."

Kozben kiderult hogy a szalat indito eset azert szulethetett meg mert egy tetves linux fut benne celeron processzoron es mindent softwarebol csinal, es az IBM szervizmernok szerint neha elofordul hogy ezekben fejreall a linux.
(Magyarra forditva: -cenzuraztam magam-)

"szerint a failover nem úgy történik, hogy a másik vezérlő IP címén lesz elérhető a LUN, hanem az "preferred" vezérlő IP címe és iSCSI identitása megy át a másik vezérlőre. Ebből implicit következik, hogy a "host"-ok irányából minden LUN-hoz mindössze két aktív útvonal van.
Ezen két útvonal nyilván lehet aktív-aktív, de ez önmagában semmit nem old meg, mert mindkettő ugyanazon a hálókártyán keresztül él. Ha ez két útvonal elhal a hálókártya hibája miatt, akkor az ESXi számára nincs lehetőség másik kapcsolatra. Kérdés, hogy ezt a tároló érzékeli-e (beleértve olyan sunyi hibát is, hogy az interfész látszólag "up", csak éppen adatforgalmazás nincs), ha igen, akkor tud-e rá reagálni?"

Itt egy kis zavart erzek az okfejtesedben. Odaig rendben van, hogy az iSCSI iqn megy at a masik vezerlore, de igazabol erre sem lenne szukseg, mivel multipath iscsi-rol van szo, ezert az esxi ketto path -on eri el a lun-t, es az egyik path bedoglese eseten atall egybol a masikra.
Ugye fizikailag ez ugy nez ki, hogy van ketto canister a storageban, mindketton ketto-ketto 10Gbit port. Es ketto (igazabol 4 ha jol emlekszem) 10Gbit port az esxi hoston. Mindketto canister egy-egy 10Gbit portja be van dugva a host egy-egy portjaba. Kulon ip cimek, ugy emlekszem kulon iqn (node1. es node2 .valami.iqn)
Es az ESXi ISCSI targetban mindketto iqn fel van veve (erdekesseg, hogy ha a storwize-hoz ip cim alapjan akarsz iSCSI-n csatlakozni, akkor nem tudsz, kizarolag az iqn -nel(!)). Tehat a target discovery -nél nem ip cimet adsz meg, hanem kulon-kulon mindketto IQN-t, amiken keresztul latja ugyan azt a LUN-t ketto, fuggetlen path-on, aktiv-aktiv modban.
Ha nem latja aLUN-t, azonnal atall a masik path-ra es megy tovabb minden. Fontos nyilvan, es ezert hivjak aktiv-aktiv storage-nak, hogy a ketto canister memoriaja es allapota ugyan az legyen mindig.
Az olyan sunyi hibk eseteben, hogy latszolag "up" a link de adat nem megy at rajta, lejar a par masodperc az ISCSI initiator-ban (nem kap SCSI parancsra valaszt), es failed -nek minositi a path-ot, es atvalt a masik path -ra.

"VMware multipath driver fully supports SAN Volume Controller/Storwize V7000 ALUA preferred path algorithms."
Storwize V3700 -rol beszelunk.

"az esxi ketto path -on eri el a lun-t, es az egyik path bedoglese eseten atall egybol a masikra."

Ez akkor történik meg, ha mindkét port másik switchbe van bedugva és például az egyik switch pusztul ki.
De ha a tárolóban levő duál portos kártya (?) pusztul ki, akkor nincs másik útvonal, mert mindkettő lehal.

Csak IQN-nel nem tudsz kapcsolódni, legalább egy IP cím kell, ami majd publikálja a többit.

"Fontos nyilvan, es ezert hivjak aktiv-aktiv storage-nak, hogy a ketto canister memoriaja es allapota ugyan az legyen mindig."

Tekintve, hogy ezt a V7000 nagytesó nem tudja, szerintem a V3700 sem.
Az aktív-aktív tároló fogalom az esetek nagy részében annyit jelent, hogy mindkét vezérlő képes valamilyen adatot kiszolgálni, de egyszerre mindkét vezérlő nem tudja azonos módon ugyanazt az adotot kiszolgálni. E célból van az ALUA: a preferred/owning vezérlőn keresztül optimális az elérés, a másikon keresztül nem.

"Az olyan sunyi hibk eseteben, hogy latszolag "up" a link de adat nem megy at rajta, lejar a par masodperc az ISCSI initiator-ban (nem kap SCSI parancsra valaszt), es failed -nek minositi a path-ot, es atvalt a masik path -ra."

Ez még mindig csak a switch hiba esete. A kérdés az, hogy egy canisteren levő 10GbE portok egy kártyán vannak vagy sem. Ha igen, akkor kérdés, hogy a tároló ezt miként kezeli, mert erre nem találtam leírást. Ha nem, akkor ez elvileg nem gond. (több tárolót is tudok, ahol a portok egy kártyán vannak, tehát itt sem elképzelhetetlen)

"Storwize V3700 -rol beszelunk."

Igen, tudom, köszi. Több okból kifolyólag is nézegettem a V7000-et az utóbbi időben, és gyanítom, hogy szoftveresen elég nagy a kettő között az átfedés, de persze tévedhetek. Az viszont szinte 100%, hogy amit nem csináltak meg a V7000-ben, azt a V3700-ban sem.

""az esxi ketto path -on eri el a lun-t, es az egyik path bedoglese eseten atall egybol a masikra."

Ez akkor történik meg, ha mindkét port másik switchbe van bedugva és például az egyik switch pusztul ki.
De ha a tárolóban levő duál portos kártya (?) pusztul ki, akkor nincs másik útvonal, mert mindkettő lehal."

várjál, várjál.
a tárolóban van kettő node, mindegyikben van egy-egy (dual portos, de ez most mindegy) kártya.
fizikailag nincs switch ( de lehetne is akár, kettő is), mert mindkét node egy-egy portja be van kötve a host -ba, egy-egy SFP+ kábellel.
Ha az egyik path meghal, a multipath miatt a masik kabelen, a masik node masik portjan folytatodik a moka.

""Fontos nyilvan, es ezert hivjak aktiv-aktiv storage-nak, hogy a ketto canister memoriaja es allapota ugyan az legyen mindig."

Tekintve, hogy ezt a V7000 nagytesó nem tudja, szerintem a V3700 sem."
Az ALUA masra jo, arra valo hogy egy-egy volume-ot preferraltan melyik node szolgaljon ki. termeszetesen ha kiesik egy node, atugrik a masikra.
Az aktiv-aktiv mukodesnek az a lenyege, hogy mindket node konzisztens, nem aktiv/stanby, hanem aktiv/akttiv. Mindketto vegez adatfeldolgozast.

""Az olyan sunyi hibk eseteben, hogy latszolag "up" a link de adat nem megy at rajta, lejar a par masodperc az ISCSI initiator-ban (nem kap SCSI parancsra valaszt), es failed -nek minositi a path-ot, es atvalt a masik path -ra."

Ez még mindig csak a switch hiba esete. A kérdés az, hogy egy canisteren levő 10GbE portok egy kártyán vannak vagy sem. Ha igen, akkor kérdés, hogy a tároló ezt miként kezeli, mert erre nem találtam leírást. Ha nem, akkor ez elvileg nem gond. (több tárolót is tudok, ahol a portok egy kártyán vannak, tehát itt sem elképzelhetetlen)"

Milyen switch??? Nincs switch a rendszerben. Egy canisteren levo portok egy kartyan vannak, de ez tok mindegy. Ket cansiter van.
Bocs a kerdesert, de te lattal mar redundans storage-t?

En elhiszem, de ezt a mondatat akkor nem ertem semmikepp.

"Ez még mindig csak a switch hiba esete. A kérdés az, hogy egy canisteren levő 10GbE portok egy kártyán vannak vagy sem. Ha igen, akkor kérdés, hogy a tároló ezt miként kezeli, mert erre nem találtam leírást. Ha nem, akkor ez elvileg nem gond. (több tárolót is tudok, ahol a portok egy kártyán vannak, tehát itt sem elképzelhetetlen)""

Lesz egy kis átfedés a másik hozzászólásommal, de talán segít pontosítani.

Nem ismerem pontosan a Storwize tárolókat, ellenben szeretném megismerni, elég sok IBM doksit elolvastam. iSCSI esetén a leírások alapján felmerült, hogy gond lehet a redundanciával. Nem azért, mert én olyan nagyon okos lennék, hanem azért, mert már szívtam meg redundáns tárolóval, ami hasonlóan működik; a másik tárolóról kiderült (a lehető legkellemetlenebb módon), hogy a hálózati kártya SPoF lehet.

Lehet, hogy Storwize esetén nincs ilyen gond iSCSI esetén, de mivel nem találtam meg pontosan leírva a működési mechanizmust, ezért szeretnék utána járni. Egy ügyfél használ V5000-et, de az utóbbi időben nagyon el van havazva és sajnos nem ért rá vele foglalkozni, gondoltam most itt egy másik lehetőség, ráadásul Neked is hasznos lehet tudni, ha kiderül, hogy mégsem redundáns (nyilván szívnád a fogadat, de ha előfordul, jobban tudod kezelni).

V7000-re ezt írja az IBM:
"FC host attachment relies on host multipathing software to provide high availability if a node that is in an I/O group is lost. iSCSI allows failover without host multipathing. To achieve this type of failover, the partner node in the I/O group takes over the port IP addresses and iSCSI names of the failed node."

Azaz ebből akár arra is következtethetek, hogy iSCSI esetén 4 lehetséges hálózati útvonalból (mindegyik ESXi hálózati portról mindkét vezérlő látszódik, azaz két hálózati kártyáról összesen 4 lehetőség van) csak 2 látszik, mindkét útvonal ugyanazon vezérlőn keresztül. Ha a vezérlő meghibásodik, akkor a másik vezérlőre fog mutatni 2 útvonal (azaz a 2 "láthatatlan" éled fel, ugyanazon IP címekre mutatva).

Nyilván lehet eltérés V3700 és V7000 között, félre is érthetem a leírást, de ha segítenél tisztázni, hogy valójában hány kábel megy az ESXi-ből a tárolóba, hány útvonalat látsz 1-1 kötet felé (ebből hány Active I/O), mi az SATP, megköszönném.

Ha 4-ből csak 2 útvonal látszik, akkor az azt jelenti, hogy kártya hiba esetén mindkét útvonal elhal, azaz az adattár elérhetetlen lesz (amennyiben egy kártyán van a két port a vezérlőn). A nagy kérdés az, hogy ezzel az esettel kezd valamit a tároló vagy sem.

"Azaz ebből akár arra is következtethetek, hogy iSCSI esetén 4 lehetséges hálózati útvonalból (mindegyik ESXi hálózati portról mindkét vezérlő látszódik, azaz két hálózati kártyáról összesen 4 lehetőség van) csak 2 látszik, mindkét útvonal ugyanazon vezérlőn keresztül. Ha a vezérlő meghibásodik, akkor a másik vezérlőre fog mutatni 2 útvonal (azaz a 2 "láthatatlan" éled fel, ugyanazon IP címekre mutatva)."

Nem.

"valójában hány kábel megy az ESXi-ből a tárolóba"

Ez tök mindegy. Mindkettő canister node be van kötve a host -ba. Ez a lényeg, nem az, hogy nodeonként hány kábellel.

"Ha 4-ből csak 2 útvonal látszik, akkor az azt jelenti, hogy kártya hiba esetén mindkét útvonal elhal, azaz az adattár elérhetetlen lesz (amennyiben egy kártyán van a két port a vezérlőn)."

Figyelj, aktiv/aktiv storage. Teljesen mindegy, hogy egy node -on a két port egy kártyán vane, HISZEN ott a másik node, külön hálózati interfaceval, ami szintén be van kötve a host -ba.
Mindkettő node -nak van saját ip cime és saját iqn -je.
Az esxi-be fel van véve mind a kettő iqn. Mind a kettő node -ot látja. Aktiv/Aktiv modban. Ha kitepem az egyik canister node-bol a kabeleket, megy tovabb minden. Ha visszadugom bele, es kitepem a masikbol, akkor is megy tovabb minden. Ha az egesz canister node-t kirantom menet kozben, nem tortenik semmi, minden megy tovabb.
(Ezeket a scenariokat termeszetesen ki is probaltuk, nem csak a levegobe beszelek, de termeszetszeruleg ennek igy kell mukodnie, hiszen aktiv/aktiv tipusu a storage lenyege, es mindketto node -ot latja iscsi -n a host - multipath iscsi-rol beszelunk. FC nalunk nincs, azt ne is keverd ide. 10Gbit multipath iscsi van. aktiv/aktiv.)

Jelenleg a topic apropojat az az anomalia adta, hogy az egyik node kidolt es nem ment tovabb minden, ahogy kellett volna, hanem ABNORMALISAN inter-canister pcie link failure -t dobott es leterdelt. Nyugi, az IBM szervizmernoknek is okozott fejvakarast, meg hummogott egyet, de hozzankvagott szo nelkul egy uj canister node-ot.

Mar bent van az uj canister node, epp mostanaban konfiguralja magat, adatvesztes nincs, haladjunk, kerem haladjunk, nincs itt semmi latnivalo.

Tisztában vagyok azzal, mi adta a téma apropóját, gondoltam más kapcsolódó témát is fel lehet vetni. Elnézést, ha zavarkodtam.

Lehet, hogy Te még nem láttál másfélét, de sokféle aktív-aktív tároló van (közel annyiféle, ahány termékcsalád), eltérő működéssel, ezért bátorkodtam részleteket kérdezni.

Köszönöm a válaszodat, megfelelő teszt mindenképpen meggyőző érv helyes működésre, a leírással kapcsolatos ellentmondást majd megpróbálom feloldani V3700 doksi olvasással is.

Egyébként nem mindegy, miként van a kábelezés, mert ha az ESXi-ből egy hálózati kártyából megy mindkét kapcsolat a tároló felé, akkor a hálózati kártya is egy hibaforrás, ami leállíthatja az egész rendszert. (a SPoF-okat célszerű minimalizálni)

"Egyébként nem mindegy, miként van a kábelezés, mert ha az ESXi-ből egy hálózati kártyából megy mindkét kapcsolat a tároló felé, akkor a hálózati kártya is egy hibaforrás, ami leállíthatja az egész rendszert. "

vártam mikor jön ez elő.

itt most erről nincs szó. bedughatok mellé akár egy másik esxi hostot is (vmotion, live migration, failover, etc.etc.), akármi. nem tudom hogy jön ez ide, tényleg.

topic címet olvasd már el légyszives, meg a nyitó hozzászólást is légyszives. egy betűt nem írtam arról, hogy milyen esxi host van rádugva, lehet, hogy nem is egy, vagy bármi. rohadtul nem erről van szó. hogy jön ide az esxi host?! ennyi erővel beszélgethetnénk az itthoni microservermről is!

A végén kezdeném: " Bocs a kerdesert, de te lattal mar redundans storage-t?" - igen, láttam már néhányat, többfélét. A válaszaid alapján talán jobban is ismerem őket.

A témát nem azért hoztam fel, hogy kötekedjek, hanem mivel a műszaki leírás nem egyértelmű és vannak kétségeim (több okból kifolyólag szeretném megismerni a Storwize tárolókat), szerettem volna a végére járni. Ha bebizonyosodik, hogy más téren is van probléma forrás, gondoltam hasznos lehet számodra tudni róla. Ugyanis van nem redundáns tároló hálózati kártya szempontból, sajnos kellemetlen módon kellett megtudnom - kvázi mint most Neked.
Működési elv szempontjából mindegy, hogy mibe vannak dugva a portok, switch-et feltételezni és alapul venni nem gondolnám, hogy túl nagy eretnekség lenne.

"fizikailag nincs switch ( de lehetne is akár, kettő is)"

Ez azért nem ilyen egyszerű... Konkrétan a VMware kompatibilitási listában nem szerepel támogatottként a "direct attach" felállás. Ettől függetlenül működhet, de azért érdemes lenne töviről-hegyire átgondolni, mi lehet ennek az oka (lehet, hogy már megtettétek, ez esetben tekintsd ezt a megjegyzést tárgytalannak), ugyanis van olyan tároló, ahol a működési módból kifolyólag elméletileg sem működőképes a "direct attach".

Arról nem beszélve, hogy a rendszer leírásod nem volt 100%-osan pontos: akár 4x 10GbE port is van az ESXi-ben, kétszer is szerepel kétség kifejezése az "emlékezés" révén. Azaz nem zárnám ki, hogy valójában 4 kábel van az ESXi és tároló között, és így van 2 útvonal (esetleg azért emlékszel két kábelre, mert két útvonal van, holott 4-et várnál). Megköszönném, ha megnéznéd, valószínűleg Neked sem ártana pontosan tudnod.

ALUA: nem, nem az ALUA határozza meg, hogy melyik node legyen a preferált. A preferált node-ot a tároló vagy Te határozod meg. A tároló az ALUA protokollal közli a hosttal, hogy melyik útvonal optimalizált, melyik nem. (azok az útvonalak lesznek optimalizáltak, amelyek a preferált node-on keresztül vannak, ESXi esetén ezeken lesz aktív I/O, a nem optimalizált útvonalakat akkor használja az ESXi, ha csak azok érhetők el; ez utóbbi esetben lehet vezérlő váltás, de ez nem a normális eset)
A "termeszetesen ha kiesik egy node, atugrik a masikra" működésnek semmi köze az ALUA-hoz, ez a tároló (elvileg) redundáns természetéből adódik. Például azon szóba hozott DS tárolók is így viselkednek, melyek nem ismerik az ALUA-t.

Aktív-aktív: három különböző állításod van. Például nem ismerek aktív/standby tárolót, olyat sem, amelyikben nem lenne képes bármelyik vezérlő adatfeldolgozást végezni. A konzisztencia pedig több módon is értelmezhető.

"Többek között ilyen esetben nagyon hasznos VM szintű mentéssel rendelkezni."

Elonyei es hatranyai is vannak.
Mivel "megbizhato" a storage eleg az adatszintu mentes. Eddig felesleges volt meg pluszb a vmdk szintu mentes is. Most persze at lesz ez gondolva...

"Ezzel kapcsolatban: az egy vezérlőn ("canister") levő iSCSI portok egy kártyán vannak vagy sem, ha egy kártyán vannak, akkor miként oldja meg a tároló a kártya hibáját. "
Ez szimulalhato a halozati kabel menet kozbeni kihuzasaval. Termeszetesen az tortenik, mint ami a multipath iSCSI eseteben elvart: azonnal a masik path-on keresztul forgalmaz tovabb a host. Ez nem uj dolog, nincs ebben semmi varazslat.

" iSCSI esetén csak az egyik vezérlőhöz van útvonal, azaz kérdés, milyen hiba felismerési eljárás van, illetve hiba esetén mit lép a tároló?"
Multipath iSCSI -rol van szo.
Amugy a tarolo azt csinalja, hogy a kiesett tarolo IQN -jet is atveszi (ez mas tarolonal nem lattam amugy, ott mindig cak a host szokta "kezelni" a multipath -ot, a tarolonak az esetben annyi a dolga hogy totalisan ugyan az legyen mindket node memoriajaban).
De mivel az esxi a multipath iscsi -t termeszetesen rendesen kezeli, velemenyem szerint a storwize reszerol az IQN buveszkedesre sem lenne szukseg. A host ketto path -on latja ugyan azt a tarolot, ha az egyik path bedoglik, seamless folytatja a masikon...

( NagyZ v | 2016. 03. 13., v – 11:42 )

en csak az nem ertem, hogy miert "tervezitek" az IBM support segitseget igenybe venni, miert nem azzal kezdtetek, hogy felhivjatok :) a sajat barkacsnal sokkal rosszab dolog nincs.

de hogy hozza is tegyek valamit, erdemes a legujabb fw-n tartani mindig a dobozokat, sok hibat javitanak benne. (7.6.1.0 a legujabb ha jol latom)

Fent irtam hogy allunk. :)

Fw ugyben: tavaly augusztus 20-an volt benne egy tap csere mert az egyik tap megdoglott. Akkor kapott egy fw upgradet is. Ez nem olyan reg volt, nem szoktunk vsak ugy frissitgetni semmilyen firmwaret (meg regen sun serverek eseteben volt ezzel cumi, az uj fw rosszabb volt mint az elozo... Altalanosan a ne javitsuk meg ha nincs baja szemlelet alapjan fw-ket sem frissitgetunk hetente ha nincs ra ok..)

(A taphiba is erdekes volt. SEMMIT nem jelzett! Belepve nagy zold "health OK" volt kiirva. Van benne egy olyan details resz ahogy az egyes alkatreszek egyenkent megnezhetok. Jo melyen eldugva. Na OTT latszott csak hogy az egyik tap igazabol nem is mukodik. A gep hatuljan van kb 10-10 zold led. A rossz tap abban tert el a jotol, hogy az egyik zold led NEM vilagitott.... Na ezt vedd eszre... De ne rakott ki se pirosat se sargat se nem alertezett hanem azt alitotta hogy minden ok. )

Nem tudom mennyit dolgoztok brand gyártókkal, de mindenhol mostanában az dívik, ha nem egyértelműen hibás alkatrészről van szó, akkor neki sem állnak a hiba javításának addig, ameddig a nem frissítettek firmware-t.

Én ilyenkor szoktam visszakérdezni, hogy mutassa meg azt a FW changelog bejegyzést, ami az aktuális problémánkat javítja. Erre csak ködösítés szokott visszajönni, és végül úgyis az lesz, hogy meg kell csinálni a frissítést.

Próbáljatok meg a supporttól kierőszakolni egy Root Cause Analys-t, ahol egy mérnök utólag megpróbálja kideríteni, hogy mi a fene történt. Ha szerencsétek van, akkor nem az lesz a konklúzió, hogy a hiba oka az elavult FW verzió volt.

Ez a legyenfent-minden-fwupgrade azért is gáz, mert van olyan felállás, ahol baromi hosszú idő mire felmegy minden (többtagú clusterek és tagjaik és azokon lévő VM-ek migrációja...) és a sok reboot simán el is fedi az alapproblémát, hiszen sokszor csak adott futásidő után jelentkezik.

Ez nem olyan reg volt, nem szoktunk vsak ugy frissitgetni semmilyen firmwaret

Ha nagyon friss még a cucc (értsd: a termékszéria GA-jától számított 1-2 éven belül vagyunk még), akkor ez lehet, hogy nem jó stratégia. Minimum követni kéne, hogy a kijövő firmware-ekben kb. milyen sötétségeket javítottak, mert ezt a vendor nem fogja megtenni a kedves kuncsaft helyett, hogy "figyu, ezt most nagyon fel kéne rakni", szívni meg ugye nem a gyártó fog, amikor összeszarja magát a berendezés.

meg regen sun serverek eseteben volt ezzel cumi, az uj fw rosszabb volt mint az elozo...

Ha már... érdekelne, hogy milyen szerver is volt pontosan ez, és mennyire volt még friss ropogós (a különleges eseteket mindig érdekesnak találtam) :D

Az IT termékek minősége zuhanó repülésben van. Mindenki először akar a felhőben lenni, felvásárlások begányolása a fő termékbe, legcsillogóbb fícsőrök bevarázslása stb.

Ha megnézzük a mindenféle firmware-ek (és egyéb kritikus szoftverek) javítási jegyzékét, akkor az derül ki, hogy mindenben rengeteg a hiba. Persze ez nem akkor látszik (nem gyakori a "known problems/bugs" vagy hasonló fejezet), mikor kijön a legfrissebb, hanem akkor derül ki, mikor a rákövetkező jön ki. Tehát tuti, hogy minden verzió hemzseg a hibáktól és nem lehet tudni, hogy mennyi az olyan hiba, ami fejlesztés közben kerül bele.

Én teljesen megértem a kolléga "ha működik, nem piszkáljuk" hozzáállását, főleg tároló esetén, aminél nem igazán van perzisztensebb és központibb elem egy infrastruktúrában.

( Celtic v | 2016. 03. 13., v – 12:06 )

Nekunk egy idoben ket egyidoben vasarolt 3700-es halta ossze magat, felvaltva. XEN-ekre voltak csatolva, a vm-eket ujrainditva helyrejott. Itt az fw frissites segitett. (vmi a.b.c verzio helyett a.b.d kellett, szoval pl szintu volt)

Masik egy frissen vasarolt (ket node + egy storage) verzio, osszeraktam, ment es hetvegen total osszeszarta magat. Az egyik cannister elerhetetlen lett. Kijott a szerviz, razta a fejet, nem ertette, cserelte es azota (fel eve) gond nelkul megy a storage. Szoval ez gyari hibas cucc lehetett...csak nem rogton jott elo, hanem par nap futas utan.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

( NagyZ v | 2016. 03. 13., v – 13:11 )

ha mar itt osszegyulnek az otthoni storwize tulajok, miert dontottetek a v3700 mellett, miert nem v5000 vagy v7000? csak az ar szamit, nem volt olyan funkcio, ami kene, de nincs benne a v3700-ban?

Kellett egy megbizhato storage esxi ala, v7000 felesleges, ez is tobb millio volt sas lemezekkel, es kb 15%-ban van kihasznalva igy is hogy van rajta 30-40 vm.. (Leveleto serverek, weboldalak, nehany virtualis windows, meg az apro.)
Igazabol 10gbit iscsin be van csatolva esxi ala, kb semmi mas funkcio nincs hasznalatban.
Par partner elozo generacios ds storaget hasznal sok sok eve gond nelkul, ez megalapozta az ibm-et. Probaltunk elotte eternus dx80 vagy 90-est de nem gyozott meg. Dell volt egy partnernel es panaszkodik ra nagyon igy abban nem gondolkoztunk. Hp nem tudodd ajanlani semmit a kategoriaban. Igy eternus es storwize kozul dontottunk vegul. De most egy kicsit banom. :)

Csak hangosan gondolkodom:
Az SVC node-jai FC-n keresztul kommunikalnak egymassal. Storwize-nal bejott ez a pcie link is, de ugy tudom maradt az FC is, mint masodlagos csatorna. Viszont ha nincs FC (iSCSI only), akkor lehet hogy a pcie link az egyetlen osszekottetes a node-ok kozott? Igy lehet hogy split-brain miatt allt meg.

aktiv/aktiv felallas eseten a split-brain igencsak necces........ hogy??

a support azt mondta legyen power off power on a kiesett nodenak, mert sajnos elofordul hogy fejreall bennuk a linux (ezt igy...)
power off power on utan mar nem is latja a canistert. fizikai eltavolitas es 15 perc mulva visszahelyezes utan unconfigurednek latja a canistert, nem lehet rajta semmit csinalni, nem reagal semmire, csak latja hogy ott van. kikapcsolni bekapcsolni sem lehet tobbe.

mdisk-ek, volume-ok meg mindig degraded allapotban vannak, pedig elvileg mar kizarolag a jo canisterrol megyunk...
ibm support a fejet vakarja, fel lett toltve analizalas celjabol a log, majd szerdan lepunk tovabb. (a tiszta kep kedviert: support szerzodes nincs, csak garancia.)

igen, igazad van, en arra gondoltam, hogy aktiv/passive allapotnal ha megszakad a ketto kozott a kapcsolat, akkor a az addigi passive is aktivba kapcsolja magat es kesz a baj, mig aktiv/aktiv eseten mashogy mukodik.
de valoban, ha aktiv/aktiv eseten is megszakad a kapcsolat kozottuk, es mindketto azt hiszi hogy o az egyeduli node, akkor is lehet baj.

minden esetre azert vettuk tobb millioert ezt a storaget, hogy ne ezzel kelljen foglalkozni, es leszarjuk, pusztan mukodjon.
oldja meg az ibm hogy ne legyen split-brain, ha mar tizen-x eves celeron processzor-ra epitik a tobb millios storeget, leszarom hogy hogy. ez nem free oepn source termek, hanem egy tobb millios storage.

nem is tudom egyebkent, hogy milyen storageban van harom node. szrintem ketto szokott lenni altalaban mindben, aktiv/aktiv modban.

Szia!

"a support azt mondta legyen power off power on a kiesett nodenak, mert sajnos elofordul hogy fejreall bennuk a linux (ezt igy...)
power off power on utan mar nem is latja a canistert. fizikai eltavolitas es 15 perc mulva visszahelyezes utan unconfigurednek latja a canistert, nem lehet rajta semmit csinalni, nem reagal semmire, csak latja hogy ott van. kikapcsolni bekapcsolni sem lehet tobbe."

Erre a dologra született valami megoldás?

Nagyon hasonlóan jártam én is. Leállt a szerverterem klímája és szépen felmelegedett minden.
(A szerverszoba külföldön van és nem tudtam bemenni elhárítani a klíma problémáját, ettől most tekintsünk el... :))
2 db v3700 megy függetlenül egymástól és kb. ugyan azt produkálták a magas hőmérséklet hatására. Mind 2 stogare-on leállt az egyik canister, de csak az egyik. Egyikben sem kezdett el dolgozni csak a másik, szóval mind a 2 storage elérhetetlenné vált. Miután lehűlt a cucc, az egyikben elindult a leállt canister is, minden visszaállt bármi féle hozzányúlás nélkül.

Mivel a melegedési folyamat alatt nem tudtam, hogy mi is lesz, elkezdtem leállítgatni a storage-t, hátha jobbat teszek vele.
Nos, ekkor a leállított canister el is tűnt a listából Server Assistant Tool-ban, szóval itt le is álltam a kikapcsolgatással.. :)
Azóta a storage nem elérhető, mert próbáltam újraindítani a másik canistert, hátha történik valami, de azóta az csak Starting állapotban van 550-es hibával. A másikat továbbra sem látom.

Fizikailag még nem tudtam senkit beküldeni a szerverszobába, de ha kiveszik és visszateszik a kikapcsolt canistest, valószínű, hogy engem is az unconfigured hiba fog fogadni?
Erre mi a megoldás? Teljes újraconfig?
(Szerencsére ez nem prod környezet)

Sajnos a Management GUI-t nem érem el, mert pont a leállt canister IP címén volt elérhető.
Erre esetleg valami megoldás?

Köszönöm!
Üdv.