iSCSI problema es egyebek
Kollár Csaba
Zs�kutc�ba futottam egy probl�ma kapcs�n, k�v�ncsi lenn�k r�, hogy van e
valakinek �tlete a megold�sra:
Adott egy DC, benne 2db cluster, 3-3db ESXi hosttal (4.1). Adott 2db
iSCSI storage, melyek mindegyik hoston mountolva vannak. Az egyik
lunjain az �les vm-ek laknak, a m�sikra egy Data Recovery backupol. A
backup storage �zemeltet�je gondolt egyet, �s mindenf�le bejelent�s
n�lk�l rebootolgatni �s konfigur�lgatni kezdte a storaget (egy�bk�nt
az�ta sem m�k�dik, de ennek most nincs jelent�s�ge). A hostok nem vett�k
j� n�ven a dolgot, �s disconnected st�tuszba ker�ltek a Vcenterben.
"Beragad�", semmire sem v�laszol� vpxa, aam, hostd �s hasonl� j� m�k�k
k�s�rt�k az esem�nyt. A hostokra sem a Vsphere Client sem a Vcenter nem
tudott csatlakozni ebb�l kifoly�lag. A vm-ek viszont legal�bb probl�ma
n�lk�l futottak.
A d�gl�tt iscsi target k�zi kil�v�se kapcs�n a k�vetkez�k�ppen j�rtam el:
http://www.itbasement.net/vsphere5-remove-iscsi-target-shell/
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003714
Rendesen kellett massz�rozni �ket ssh-n ezen k�v�l is, mire v�gre
eljutottam od�ig, hogy kiirtottam a halott iscsi
linkeket/datastore-okat, �s rendben elindult a vpxa, hostd, aminek
k�sz�nhet�en �jra tudtam managelni a hostokat. R�ad�sul 2db hoston
sz�momra ismeretlen okokb�l tov�bbra sem b�rom elind�tani a HA agentet
(�s persze a Vcenternek sem siker�l), err�l majd lehet, hogy k�l�n
k�rdezek :)
Sz�val az aktu�lis k�rd�s az, hogy mit lehet tenni annak �rdek�ben, hogy
ez ne �gy t�rt�njen amikor leszakad egy storage? Azzal tiszt�ban vagyok,
hogy a dolog nem egyedi, rengetegen panaszkodnak r� a neten, �n is
futottam m�r bele, csak az esetek 99%-ban az ember csukl�b�l rebootolhat
amikor elhullik egy storage, akkor ezen m�r nem m�lik, �s egy reboot
megoldja a probl�m�t, err�l m�g tal�n KB is van...
Jelen esetben viszont m�lt, mert csak a backupot �rintette.
Kellemetlen a dolog, mert itt van k�t HA cluster, FT enabled vm-ekkel,
melyek rezzen�stelen�l m�k�dnek, de gyakorlatilag teljesen
haszn�lhatatlanok a fontosabb featurek. Az egyed�li gyors �s biztos
megold�s egy reboot mindegyik hoston, ez viszont nagyon nem sz�p.
Sz�val k�v�ncsi lenn�k, hogy m�s is belefutott e m�r ebbe, �s van a r�
jobb megold�sa. Persze az megfordult a fejemben, hogy �trakatom a
backupos j�emberekkel a dolgaikat NFS-re, de �rdekelne az�rt m�s �tlet is.
--
Csaba
"Bognár Attila - Netalfa Kft."
Sajnos ebbe rendszeresen bele lehet futni v�ratlanul, ez akkor a
legkellemetlenebb egy magas rendelkez�sre �ll�s� infrastrukt�r�ban,
amikor k�t t�rol� van, �s az egyik teljesen (redund�ns volta ellen�re)
megadja mag�t: eredm�ny az, hogy az a VM is reboot (pontosabban kil�v�s)
es�lyes, amelyiknek semmi k�ze a lehalt t�rol�hoz.
A VMware legink�bb t�rogatja karjait, mondv�n nem az � probl�m�juk a
t�rol� hal�la vagy el�rhetetlens�ge, ha szeretn�l v�ltoz�st ez �gyben,
akkor itt kell jelezni:
https://www.vmware.com/contact/contactus.html?department=prod_request
Ami viszonylag gyorsan megold�sra vezethet, az az adatt�r lecsatol�sa
(http://kb.vmware.com/kb/2004605), de nem garant�lt az eredm�ny,
szitu�ci�t�l is f�gg.
Kulcssz�: APD szitu�ci� (=All Paths Down)
A VMware t�mogat�s szerint a kulcs a gyors reakci�: min�l gyorsabban
pr�b�l valamit az ember (lecsatol�s, t�rol� vissza�ll�t�sa, ...), ann�l
nagyobb es�llyel ker�lhet� el az, hogy az ESX(i)-t �jra kelljen
ind�tani, rajta a fut� VM-ekkel.
�dv,
Attila
2012.04.06. 22:18 keltez�ssel, Koll�r Csaba �rta:
e-mail: abo...@netalfa.hu
telefon: +36 30 / 363-31-97
telefax: +36 94 / 999-673
honlap: www.netalfa.hu
c�m: H-9700 Szombathely, Pr�ga u. 3.
Kollár Csaba
siker�lt megoldani k�zi massz�roz�ssal a dolgot (nagyj�b�l hasonl�an
mint ahogy a KB �rja, de ez akkor sajnos nem l�tezett m�g, nomeg ez
5.x-r�l sz�l). A HA agentek is elindultak, amihez a hostd k�rny�k�n
kellett gyoml�lni valamit, majd start/stop-olni megfelel� sorrendben p�r
servicet. R�g volt, annyira nem eml�kszem m�r.
Szerencs�re az�ta siker�lt azt is el�rni, hogy a backup storaget
�zemeltet� j�emberek is ink�bb olyasmivel t�r�djenek amihez �rtenek is,
sz�val most csend van �s b�kess�g ezen rendszer kapcs�n :)
--
Csaba
Péter Neumann
Az előző héten magam is tapasztaltam az APD szépségeit. Van 38 4.0/4.1 ESXi-m hat clusterben és pár datastore-al sikerült elvesztenem a kapcsolatot. Olyanokkal melyek bár több path-on elérhetőek, de SAN szinten nem redundánsak és a SAN nyiffant ki. A rajtuk lévő VM-ek tetszhalott állapotba kerültek, ami "nem" probléma - hiszen nem kritikus voltuk miatt vannak nem replikált LUN-okon - de minden más VM is megállt az érintett hosztokon.
Most elég erősen gondolkodom azon hogy affinitást fogok bevezetni a replikált datastore-okon futó VM-eknek és a nem replikáltaknak. Szóval ha adott 4-4 blade két DC-ben akkor 2-2 - nyilván a különböző szintű VM-ek számától függően - csak a fontos, 2-2 csak a kevésbé fontos VM-ek számára lesz fenntartva. Tudom hogy ez minden alapszabályba ütközik, de így akár egy SAN eszköz elvesztése is elviszi az adott hosztot.
FalconStor aktív-passzív storage virtualizációt használok vegyes storage-ekkel (Hitachi, Nexsan, HP 3PAR).
Üdv,
Peter
CZW
Kollár Csaba
> bocsi, csaba, de milyen kodolassal irod a leveleidet?
> szamomra olvashatatlan :)
lásd a másik lótenyésztős listát amelyiken te is fent vagy :).
Viszont te UTF-8/quoted printablebe idézted, ráadásul dupláztál is, csak
nem céges Zimbra? :PP
--
Chal
Szabó Benjámin
2012/9/5 CZW <czw...@gmail.com>: