A 4-es Xen alatt már definiálva van elvileg a "fault tolerance" motor, Remus alapokon.
http://wiki.xen.org/xenwiki/Remus
Gyakorlati tapasztalat valakinél?
Debian 6-ra (64 bit) tenném, iscsi storage-el.
- 6415 megtekintés
Hozzászólások
Meg nem, de napok kerdese es elkezdem tesztelni. Majd megirom a tapasztalatokat, ha erdekel.
- A hozzászóláshoz be kell jelentkezni
Én is várom :)
- A hozzászóláshoz be kell jelentkezni
érdekel engem is :>
Ubuntu 10.04, Thinkpad x61s
- A hozzászóláshoz be kell jelentkezni
frankó...debian lesz? Mintha Opensuse alatt több doksi lenne róla a neten...
- A hozzászóláshoz be kell jelentkezni
Igen, Debian Squeeze, 64-bit. A storage viszont nem iscsi, hanem local. Neztem a DRBD-s megoldast is, de sajnos DRBD-vel nincs jo tapasztalatom.
- A hozzászóláshoz be kell jelentkezni
Mármint mi a local? A Remus-nál ha az egyik gép kimegy, akkor látnia kellene az image-t a másiknak is....local esetében hogyan?
- A hozzászóláshoz be kell jelentkezni
Arra ertettem, hogy a dokumentacioban javasoljak a DRBD-t, hogy hamarabb szinkronizaljon hiba eseten a ket oldal. Ez az, amit nem fogok tesztelni, vagyis sima helyi hattertaron fognak futni (ertsd: LVM tomb :) ).
- A hozzászóláshoz be kell jelentkezni
Node idefigyu...a remus nemcsak a CPU és memória dolgokat szinkronizálja hálón? A diszk IO-val mi a helyzet?
- A hozzászóláshoz be kell jelentkezni
Nekem a leirasbol az jon le, hogy a disk image-ek is szinkronban vannak.
- A hozzászóláshoz be kell jelentkezni
hápersze, ha van drbd (vagy iscsi...), local-nál kétlem (márha az ESX példájából indulunk ki)
- A hozzászóláshoz be kell jelentkezni
Akkor lehet, hogy ujra elo kell venni a DRBD-t. Mondjuk 3 eve probaltam, azota csak javult. :)
- A hozzászóláshoz be kell jelentkezni
nem
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Én ugyan csak teszt jelleggel használtam, éles környezetben nem lett bevetve, de semmi bajom nem volt vele. Sokszor találkozom én is DRBD ellenes posztokkal, de normális, korrekt infót még nem találtam/kaptam, hogy miért is.
- A hozzászóláshoz be kell jelentkezni
mi is használtuk, nem volt vele gond
- A hozzászóláshoz be kell jelentkezni
Kipróbáltuk, kell hozzá shared storage. Egyébként nem váltotta be a hozzá fűzött reményeket, de részleteket sajnos nem tudok, mert nem én csináltam.
- A hozzászóláshoz be kell jelentkezni
Koszi, ez is valami. :) Akkor mar nem indulok neki akkora lelkesedessel.
- A hozzászóláshoz be kell jelentkezni
ennél kicsit bővebben jó lenne info
főleg azügyben, mi nem jött be?
- A hozzászóláshoz be kell jelentkezni
megbízhatatlan volt a működése. játszani jó, de éles gépet nem bíznék rá.
- A hozzászóláshoz be kell jelentkezni
Mármint failover esetben nem megy tovább a cucc? Kicsit részleteznéd?
- A hozzászóláshoz be kell jelentkezni
Na az engem is érdekelne :P
- A hozzászóláshoz be kell jelentkezni
s
- A hozzászóláshoz be kell jelentkezni
Ha minden jol alakul, akkor holnap reggelre meglesz a ket tesztgep.
- A hozzászóláshoz be kell jelentkezni
Hmm..egész jó..impresszív.
http://nss.cs.ubc.ca/remus/papers/remus-nsdi08.pdf
Már csak ki kellene próbálni. Megvannak a tesztgépek?
- A hozzászóláshoz be kell jelentkezni
Ma reggelre sikerult felszabaditani a masodik gepet. Meg takaritani kell rola es ujrahuzni. Szerintem holnap fogok nekiallni a Remus-nak.
Szerk.: koszi a doksit!
- A hozzászóláshoz be kell jelentkezni
nos?
- A hozzászóláshoz be kell jelentkezni
Ket hete a diskek-re varok amik a tesztgepek bovitesehez kellenek. Berelt szerverekrol leven szo szeretem a szolgaltatonkat. :)
- A hozzászóláshoz be kell jelentkezni
azért várjuk a fejleményeket :)
- A hozzászóláshoz be kell jelentkezni
Mindenkeppen megirom, nem felejtettem el a dolgot, csak meg mindig varok a diskekre. :) De talan mar jovo het elejen meglesznek.
- A hozzászóláshoz be kell jelentkezni
No, igen csak megkesve, de eljutottam oda, hogy teszteljem.
A host gepeken Debian 6 fut. Reszletesebb leirast kesobb csinalok, mert meg nem mukodik jol a dolog. Ott tartok, hogy forgatott 2.6.32.48-as dom0 kernellel, 4.1.2-es xen-nel hajlandi elindulni a remus, de halozati gondok vannak. A vm drbd tombon van, a remus letrehozza a backup hoston a vm peldanyt, azoban a vm halozatat megoli es meg nem jottem ra, hogy miert.
- A hozzászóláshoz be kell jelentkezni
No, sikerult eletre rugni a halozatot, az egyik iranyba mukodik a failover, bar a drbd-vel meg gondok vannak, ugyhogy megyek tovabb.
- A hozzászóláshoz be kell jelentkezni
Engem is erdekel. Esetleg leirnad, mi volt a konkret problema es a megoldas?
10x
tompos
- A hozzászóláshoz be kell jelentkezni
Ha a halozati problemara gondolsz, akkor ott az volt a baj, hogy a domU a stock debian kernelt hasznalta, mert nem olvastam el eleg alaposan a doksit. :) A remus tamogatassal forgatott kernelt hasznalva tokeletesen mukodott a halozat failover eseten is. Most mar csak azt kell elernem, hogyha a master node megall, akkor a backup-on a drbd tomb legyen primary.
- A hozzászóláshoz be kell jelentkezni
Szia, drbd-t még mindig nem teszi primary-be a Xen4? (Ha kézzel primarybe teszed akkor elindul a vm csak hogy lesz így live-migration?)
- A hozzászóláshoz be kell jelentkezni
"Elvileg" primary-be teszi, legalabbis a script a helyen van (drbd csomag tette oda) es a xen vm config megette a drbd eroforrast, de a gyakorlatban meg nem igazan mukodik. :)
szerk.: egeszen pontosan az tortenik, hogy a primary node-ot secondary-be csapja es a vm meghal mindket dom0-n, szoval nagy gebasz van valahol.
- A hozzászóláshoz be kell jelentkezni
Ismet a doksi olvasas segitett. :) A drbd-nek kellett az "allow-two-primaries;" opcio, igy mar tokeletesen mukodik. Oda-vissza failover tesztelve, ssh session tulelte mindket iranyt. Jonnek a komolyabb terhelessel jaro tesztek.
- A hozzászóláshoz be kell jelentkezni
Ez jó hír! Nekem a Xen 4-esre átállás után nem kezelte a drbd-t. A Qemu nem ismerte, "elfelejtette" (kihagyták) a drbd kezelést. Azóta rá sem néztem de akkor ismét előszedem. Lehet frissíteni pár régebbi rendszert. Úgyis elmúlt már február 6.-a! :-)
- A hozzászóláshoz be kell jelentkezni
Arra azert figyelj, hogy a Squeeze-ben levo stock 4.0.1-es xen-nel nem mukodik a remus es sokat nem vacakoltam vele, mentem tovabb a sid-ben levo 4.1.2-es csomagra.
- A hozzászóláshoz be kell jelentkezni
Vmit ott felrenezel szerintem.
Az allow-two-primaries akkor kell, ha a ket node-on egyszerre fel akarod mountolni ugyanazt a tomb-ot. master-slave felallas eseten erre tuti nem lesz szukseged. Ill. egesz pontosan a legrosszabb, amit tehetsz, mivel nem clusterfs-t hasznalsz. Vagy kulonben nincs ertelme annak, amit korabban irta, h secondary igy meg ugy..
Akkor mi a felallas?
tompos
ui.: A remus-rol keveset tudok, szoval ennek megfeleloen irtam, amit...
- A hozzászóláshoz be kell jelentkezni
A live migration miatt kell ez a beallitas. A remus failover eseten mindket oldalt egy pillanatra primary-be kapcsolja, de megoldja, hogy ne legyen ket oldalrol iras. Ezen beallitas nelkul elhasal a backup node-on a vm a xen szintjen.
Egyebkent teljesen igazad van a beallitast illetoen, de ez egy kivetelt kepezo eset. A DRBD hivatalos doksijaban is benne van.
- A hozzászóláshoz be kell jelentkezni
valamint,h a DRBD-re LVM-et raksz, ahol a külön domU-knak külön volume van. pri-pri esetben megoldható, hogy az egyik volume az egyiken, a másik a másikon fusson. Ha ellenőrzöd, h azonos domU ne fusson mindkét dom0-n akkor nem lesz kavar. szerintem.
- A hozzászóláshoz be kell jelentkezni
Annyit azert hozzatennek, hogy ehhez mar clvm kell, hogy minden lvm modositasod (ami lvm metadata modositassal jar) disztributalodjon az osszes node-ra.
- A hozzászóláshoz be kell jelentkezni
Ahha. Igy mar erthetobb. Bar egy kisse rizikos szaga van.
Majd megnezem en is kozelebbrol, ha lesz idom.
Koszi,
tamas
- A hozzászóláshoz be kell jelentkezni
Igen, valoban az. :) Ezert akarom minel alaposabban kitesztelni.
- A hozzászóláshoz be kell jelentkezni
Ehhez inkabb uj szalat nyitok.
Tobb cpu dedikalasa eseten a remus parse-olasi hibaval elhalalozik. Megirom a xen-devel listara, mert nem tunik trivialisnak a problema szamomra.
- A hozzászóláshoz be kell jelentkezni
A jelenlegi script nem szereti, ha dedikaljuk a core-okat, vagyis a "cpus" beallitast ki kell venni a configbol, igy mukodik.
- A hozzászóláshoz be kell jelentkezni
Itt írták mások, hogy nem megbízható, hát ez így nem igaz, maga a Remus és a live migráció igenis megbízható! Nincs azzal semmi gond, de pár megjegyzés:
- Mivel automatizálod a DomU migrálását (failover), persze ha nem ehhez kell akkor nincs gond, de nekem heartbeat -el nem igazán sikerült úgy összehozni, hogy az üzembiztos legyen.
- iSCSI nagyon nézd meg, hogy mire és mit használsz, az iscsi-target az NTFS szolgáltatásai közül csak keveset képes kezelni, átvinni. Más file rendszerekkel is lehet, van gond, szóval óvatpsan. Én inkább FC-t, FCoE-t javasolnék, vagy ha iSCSI akkor linux-iscsi
- Gondold át, mit fogsz csinálni ha kevés lesz a disk
----
올드보이
http://molnaristvan.eu/
- A hozzászóláshoz be kell jelentkezni
drbd, innentol felejtos az egesz :(
- A hozzászóláshoz be kell jelentkezni
Lehet hozzá storageot is használni..
- A hozzászóláshoz be kell jelentkezni
Pontosan, a feltetel csak annyi, hogy mindket host erje el a block device-t. A DRBD poor man's javaslat a remus leirasban.
- A hozzászóláshoz be kell jelentkezni
/off milyen lehetosegek vannak hogy nem a diskek legyen a spof?
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
level 1) van két géped
level 2) a gép(ek)ben raid van
level 3) a gép(ek)ben hw raid van
level 4) a gép(ek)ben redundáns hw raid van
az elsőt kivéve nem a disk a SPoF
- A hozzászóláshoz be kell jelentkezni
ez eddig ok, de hogy lesz a ket gepen levo adat szinkronban?
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Nem kerlek, hogy fejtsd ki, mert veget nem ero offtopic kerekedne belole (gondolom megtalhato mar ez a "vita" a forumon). Nem is akarlak meggyozni, hogy nincs igazad csak szimplan leirom az en tapasztalatom:
A kettovel ezelotti munkahelyemen kb. 10 cluster-nel hasznaltunk primary/secondary config-gal drbd-t es uzemeltettuk 3 even keresztul (customer-nek nem volt penze hardware-re. ertsd, entry level szerverek, no shared storage).
SEMMI bajunk nem volt a drbd-vel, atomstabil volt (gondolom a megfelelo konfiguralas es teszteles eredmenye). Ez alatt a 3 ev alatt volt disk error es nem csak egyszer billent a cluster (egyeb okok miatt).
- A hozzászóláshoz be kell jelentkezni
Csak nehogy véletlenül egyszer meglazuljon a kábel és csak egy picit packet lossoljon. Nekem sikerült úgy összeborítani a kolléga DRBD-jét, hogy az érintett gép fölötti gépet szereltem ki és egy hajszálra meglazult a kábel.
- A hozzászóláshoz be kell jelentkezni
Ez igy rendben is van, ez az elvart viselkedes a design-bol adodoan es ez nem von le semmit a stabilitasabol ( bar mar regen hasznaltam, ha jol tudom a ket node kepes tobb network szegmensen is kommunikalni... ezen felul pedig bonding).
A lenyeg, hogy fel tudsz allni egy split brain utan is. Tobb munka mint egy shared storage-nal, de olcsobb is. Valamit valamiert ;)
- A hozzászóláshoz be kell jelentkezni