Proxmox clustert használó embert keresek

Virtualizáció

Bevezetés előtt lenne pár kérdésem a Proxmox VE-vel kapcsolatban.

Főleg 4-es verzió, clusterezés valamint stabilitás érdekelne.

  • 4773 megtekintés

Egyelőre nincs konkrét kérdésem. 4-essel szeretnék clustert építeni és ezen futtatni a jelenleg max 10 virtuális gépünket. Alapvető üzemeltetési tapasztalat érdekelne elsőre, illetve, hogy a community repo megfelelő, vagy a fizetőset érdemes használni?

KVM-ről migrálnék egyrészt a gui miatt, másrészt a failover cluser illetve a centos 6 alatt már elég sok feature hiányzik, pld esxi image-et konvertálva sem indulnak már el.

Szintén 3 node, ceph storage a háttérben. HA belőve, de jelenleg nincs VM amire bekapcsoltuk volna (amikor beállítottam, akkor teszteltem, tökéletesen működött).
Stabilitásról: 377 days, 19:43 szerintem mindent elmond. Ha egyszer jól belövöd, csak akkor találkozol vele ha a vm-eket adminisztrálod:)
Mi most decemberben akarjuk frissíteni 4-re a gépeket

// Happy debugging, suckers
#define true (rand() > 10)

( Zs | 2015. 12. 07., h – 13:58 )

A ProxMox alapvetően jó, a cluster szintén pöpec benne - de a HA kapcsán baromira nem mindegy ám az, hogy milyen shared storage-t teszel mögé! Ezzel is lehet nagyot szívni. Erre vonatkozó elképzelés van-e? Vagy arra gondolsz, hogy ebben a témában is a ProxMox üzemeltető véleményét kéred ki? Ő mit tett mögé és az mennyire vált be?

Két Dell szerver, egy NetApp tároló. A cluster megvan, de HA nincs, mert oda kellene egy harmadik szerver is. Egyelőre Proxmox 3, de lassan tervezem a migrálást.
Azt tapasztaltam, hogy ha a VM-ek NFS-en vannak gyorsabban mennek mint ISCSI-n.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

?
mitol instabil az nfs?!
vam vware rendszerunk, ami 10gbiten, nfs-sel, 2 eve megy hiba nelkul.
freebsd+zfs adja ala az nfs -t.

vmware 6 teszterendszer is megy mar kb 4 honapja, freenas-rol nfs-sel hiba nelkul, megy rajta folyamatosan a dd 4 vm-en, szoval terhelest is kap.

te mirol beszelsz?

hazi stress-testnek elso korben ezt szoktam alkalmazni a storage rendszernek.
napokik, hetekig, jelen esetben honapokig fut paralell tobb dd iras es olvasas. azert szar vas borut mar meg ettol... :)
tudom hogy vannak professzionalisabb stress-tesztek, de amugy alapjaiban mi a problemad a modszeremmel?

nem értek egyet.
fogtam már így storage hibát (storwize!), hálókártya hibát (emulex), freebsd -ben ixgbe és oce driver hibát (freebsd devlisten is fent van, patch is keszult a javaslataim alapjan, stb.) (mindezt brand ibm hardwaren, amit egyebkent tobbet nem veszunk...)
memtest persze alap, mielőtt feltelepitjuk a test rendszert. utana megy memoriazabalo cucc is, nyilvan.

annyi igaz, hogy fent emlitett bugokat, hibakat 2-3 nap dd-vel meg lehet fogni, most azert megy honapok ota, mert ugy maradt, es kivancsi vagyok, hogy valami lesz-e hosszutavon.

osszegezve sezrintem a tobb szalon, nagy bufferekkel torteno pseudo-random adatokat tartalmazo, tobbtiz-gigas fileok ide-oda dd-zese (vm-ek kozott is nfs-en, smb-n!) igenis ad egy akkora stress-t a rendszernek, ami altal tobb olyan dolog kibukhat.

en szeretem csak az atomstabil rendszereket hasznalni, ezzel a modszerrel le lehet laposan tesztelni tobb hardware es software komponenst. nekem/nekunk mar bizonyitottan bevallt.
ha ezt birja, akkor mindent birni fog.

Valamit felreertesz. Hibakat fogni nem ugyanaz, mint teljesitmenyt merni. Marmint, a driver hibak, halokartya hibak, meg ezek kijonnek, csak realis sebessegadatokat nem kapsz a dd-tol.

Azt korabban nem irtad, hogy pszeudorandom fajllal csinaljatok, ez kicsit arnyalja a kepet, nagyon sokan csak /dev/zero-t hasznalnak, ami nem random, es emiatt nem ad realis kepet. Viszont megmondom oszinten, hogy nekem pofara sokkal jobban tetszettek azok a cuccok, amik direkt erre voltak kitalalva, mert tobb es jobb minosegu adatot szolgaltattak a rendszerrol, mint a dd. Foleg mert a dd-vel nem tudsz random irast merni, ami pl. egy swap vagy adatbazis-jellegu terhelesre optimalizalasnal letfontossagu.
--
Blog | @hron84
Üzemeltető macik

A problema, hogy a dd - foleg, ha a /dev/zero -t dd-zitek -, baromira nem teszt, foleg nem stresszteszt. Egy jobb storage cuccnal kb. az elso, amit kioptimalizal, az a dd if=/dev/zero (a FreeBSD+ZFS mondjuk nem esik bele ebbe a kategoriaba, de el tudom kepzelni, hogy a ZFS-ben van erre optimalizacio). Nalunk pl. pont az volt a gond, hogy egy brand storage tesztjenel a dd-re lehetetlen sebessegeket meg idoket kaptunk (a kabel nem vitt volna ennyit at), es nem is volt a storage-n lathato terheles, pedig 2-3 vm is tolta. Amint elkezdtunk diszkterhelesre szakosodott programokat futtatni, amik nem nullakat irtak szekvencialisan, egybol megjottek a valos terhelesi adatok is, meg elkezdtek kb. realis sebessegek meg idok kijonni.

Ami az NFS-t illeti: azert instabil, mert nem igazan turi jol a halozati hibakat. Alapertelmezes szerint UDP protokollt hasznal, aminek elmeletileg az a benefitje, hogy gyorsabb, cserebe viszont semmilyen garancia nincs meg benne, ami a TCP-ben megvan, vagyis ha egy csomag elveszett, akkor az a csomag valojaban sosem indult el, legalabbis sose fogja senki hianyolni. At lehet ugyan konfiguralni az NFS-t, hogy TCP-t hasznaljon, de ennek az a hatranya, hogy eleg csunyan csokken a teljesitmenye, VM-ekhez alkalmatlan lesz.

Raadasul az NFS ket plusz retegen is atmegy, amin nem kellene neki atmenni. Ugye, ha belegondolsz, NFS-en at csak felcsatolt fajlrendszereket tudsz megosztani, vagyis a host gepen at kell menni a VFS-en is, nem csak siman a blokkeszkozt dobaljuk. Plusz, a kliensnel szinten fajlrendszerkent latszodik az NFS, vagyis ott is atmegyunk a VFS-en. iSCSI eseteben mindez kisse maskeppen van, hiszen az iSCSI-n kiajanlott eszkozok blokkeszkozkent latszanak, vagyis - jo esellyel - mar a host oldalon se megy at a rajtuk meno forgalom a fajlrendszer-kezelon (ez persze kicsit - de csak kicsit - valtozik, ha LVM van ervenyben).

Az iSCSI hatranya, es ami miatt bizonyos eszkozokkel lassabb lehet, az az, hogy stricten TCP-n kommunikal. Itt eleg sokmindennel lehet jatszani, a jumbo frame-tol kezdve a switch oldali konfigig, de az a mondas, hogy ha iSCSI storaget epitesz, akkor iSCSI-kompatibilis halozati eszkozket kell venned. A 10G-s cuccok azok jellemzoen ilyenek egyebkent, de tesztelni kell, sokat, sokfelekeppen. Nalunk vegul az volt a jo megoldas, hogy direktbe kotottuk ossze a HV-ket a storage-gel, switch kozbeiktatasa nelkul.

Ami rendszert en epitettem, ott fontos volt, hogy akkor se alljon meg, ha a virtualis gepek elkezdenek vadul swappelni. Mivel nem sajat gepek voltak rajta, nem volt kihatasunk arra, hogy mennyire tervezik alul a memoriafoglalast a VM-ek keszitoi, egyszeruen el kellett kezelni ezt a fajta terhelest. Emiatt nagyon-nagyon sok kombinaciot kiprobaltunk, mire talaltunk valamit, ami ebben jo volt.
--
Blog | @hron84
Üzemeltető macik

FYI: "At lehet ugyan konfiguralni az NFS-t, hogy TCP-t hasznaljon, de ennek az a hatranya, hogy eleg csunyan csokken a teljesitmenye, VM-ekhez alkalmatlan lesz."

Es nem tevhit, hanem meres (az igaz, hogy nem mostanaban mertem, szoval az ujabb kernelekkel akar jobb is lehet a helyzet, vegulis mar 4.x-nel tartunk en meg meg 2.6-tal mertem). Ha igy van, akkor elnezest kerek erte, de hidd el, nem szoktam ilyesmit hitbol allitani. Sajnos mostanaban nincs annyi lehetosegem storage halozatokkal jatszani, mert a munka elvitt az AWS fele, ott pedig ez a fajta tudas sajnos ertektelen, mert az AWS maga adja alad a storage-t.
--
Blog | @hron84
Üzemeltető macik

te nem erted amit mondok, probaljuk ujra: ha a te lokalis halozatodon elvesznek UDP csomagok, ott gaz van. (ettol meg TCP-n se lesz rossz a teljesitmeny, sot.)

de mindegy is, mar probalod menteni magad azzal, hogy regi a tudasod, de ha ezt tudod magadrol, akkor inkabb ne terjessz tevhiteket.

Magában az NFS-ben nincsen hibatűrés (bár kérdés, ezt miként értjük), emiatt LACP-t kell kialakítani alá (NetApp és switch között), fizikailag két hálókártya mindkét vezérlőbe (azaz összesen 4 darab hálókártya szükséges, duál portos nem megfelelő). Ezzel a felállással nincs gond a redundanciával.

keretlen tanacs: ciscot ne, inkabb juniper-t vegyel.
btw, ehhez nem feltetlenul kell cluster kepes switch, lacp-nek az a lenyege hogy ha kiesik az egyik path akkor meg a masikon. ezt nem a switchek "csinaljak", hanem a vegpontok.
akkor kolts clusterkepes switchre, ha tenyleg olyan alkalmazasod van, de nem akarok beleszolni.

Árnyaltabb a helyzet.
LACP-hez jár egy keret üzenet, valamint konfigurálható, hogy milyen meghatározott rendszer szerint közlekednek a bitek a több tyúkbélen. Ezzel meg is növekszik a kiszolgálás sávszélessége, addig a pontig, amíg ez a sávszél rendelkezésre áll.

VMware résznél lehet állítani NIC failover-t, abban az esetben, ha nem megy az egyik, a másik kezd el szólni. Ez enélkül egyéb módon kell megoldani.

A márka terén elég közel vagyok a tűzhöz, úgyhogy ebből a szempontból nincs gondom. Egyébként igazat adok.

Van qfx rossz tapasztalatod?

Igy kilőve az arista, junier qfx, cisco nexus vonal. :)

Am ezen a szinten nem játszik datacenter switch. 5 virt gépről beszélünk, azért is proxmox a target, nem vmware.

Két ex2200 szerintem lekezeli azt a 2 gigát röhögve. A mostani kis sg200 is megcsinálja, csak kifutunk a 4 lacpből, ha bekerül a 3. Gép a ha miatt.

nezegettem junipert sokat, nekem nem fekszik annyira. mostanaban a virtualis cuccaikat neztem, az sem :) valamiert a Cisco jobban kezre all, de nyilvan mindenkinek az, amivel dolgozik naponta. mi N9K-ra epitettunk.

ennyi gepre en nem lacpznek egyaltalan, az az igazsag, mert halokartyat elpukkanni sokkal kevesebbett lattam (0) mint switchet (sok).

Nekem a bsd kerettel van pici személyes ellenérzésem. Valahogy nem emésztem meg, hogy jó lehet ez flash kártyán. Persze a tükrözött boot particio ezen segít. Maga a konfig gumi. Sok féle képpen összeállhat. Persze a te szinteden gondolom san switching külön van választva.

Az arista terjed nagyon datacenter irányban.linuxal, cisco like clivel. A kérdésem az, mint a qfx-nél. Gyötörtél már ilyet?

en oszinten csalodnek (es sokat ordibalnek a telefonon), ha az N9K-n gond lenne azzal, hogy csak VLANozok :) minden gepunk 2x10Gbit LACP-vel (illetve jovore jon egy racknyi ami 2x40Gbit LACP), ezen megy egy kulon VLAN-ban az iSCSI, kulon VLAN-ban VSAN, kulon VLAN-ban vMotion, kulon VLAN management, etc.

nem hiszek az FC-ben plusz a legnagyobb storageunk januar vegetol ceph lesz (~2PB), oda nem is valo az FC.

Aristat tendereztettem amikor megvettuk a Ciscokat, engem nem gyoztek meg, a cisco-like nekem keves, az meg, hogy most linux/bsd/akarmi fut benne, engem hidegen hagy. sokan jottek azzal, hogy dehat kisebb a latency, ugyanazt a chipet hasznaljak (broadcom trident 2), raadasul az arista oversubscribeolja a chipet (van valahol errol egy jo cisco liveos video, hogy ok a chip portjainak csak 75%-at hasznaljak, igy ki tudod lineraten tolni <200 byteos csomagokkal is - mi RDMA-zunk, ott elofordul ilyen a control planen)

jovore lesz egy redesign, de ott is Cisco FEX-ekben gondolkozunk...

Nem a VM-ek mennyiségétől függ, hogy mit érdemes alá tenni, hanem azok kritikusságától.

Mire mész redundáns tárolóra & co-ra elköltött vödörnyi pénzzel, ha aztán egy aprócska hálókártya megfekteti az egészet (vagy csak a felét... hidd el: el tudnak pukkanni, tudnak sunnyogni)? Az egész redundáns architektúrának semmi értelme, ha tele van a padló elszórt banánhéjakkal.

Ha egyetlen kártyád van (akárhány porttal) és elhal (esetleg csak funkcionálisan), semmit nem migrálsz sehova, csak reménykedsz, hogy minden egyben van, mivel a tár is kiesett alóla... Remélhetőleg van VMware HA, mert akkor annyival kisebb a gond, hogy az emberi reakció idővel nem növekedik az állás ideje.

Nagyobb a gond, ha mindez tároló oldalon történik, azaz az adatok nem érhetők el. Itt inkább legyen LACP, ha már redundáns tárolóra ment pénz...

Idézlek:
"ennyi gepre en nem lacpznek egyaltalan, az az igazsag, mert halokartyat elpukkanni sokkal kevesebbett lattam (0) mint switchet (sok)."
"minden gepunk 2x10Gbit LACP-vel [...] ezen megy [...] iSCSI, [...] VSAN, [...] vMotion, [...] management, etc"
"ha elhal a NIC, majd atmigralom a VMet a management reszen mashova, a nodeot meg kikukazom :)"
"olyan sosincs, hogy egy kartya van... :) az alaplapon azert van 2-4x gigabit, plusz a kartyan 2x10gbit (vagy 2 kartyan osszesen 4x10gbit), legrosszabb esetben a failover mehet a gigabitre"

- eléggé ötlet kavalkád van itt: most akkor 2x10Gbit vagy mégsem?
(2x10Gbit általában egy kártyán van - utolsó megjegyzésed alapján Nálatok is -, emiatt bátorkodtam kiemelni, hogy 1 kártya esetén nem feltétlenül fogsz vidáman és magabiztosan migrálni)

- én semmilyen módon nem keverném (legrosszabb esetben sem) a 10GbE-t és a GbE-t, a szervert tessék úgy rendelni, hogy ne kelljen ilyet csinálni (több okból se)

- eredeti témához visszakanyarodva: VM-eket kiszolgáló NFS szerver esetén mindenképpen fontos az LACP; Te hiába nem láttál még elpukkanó hálókártyát, hidd el: előfordul. Azaz ha valaki redundáns VM infrastruktúrát épít NFS alapon, akkor kell az LACP. LACP nélkül olyan, mint SAN multipathing nélkül.

(Egyébként ha egy cégnél kevés VM fut, lehet, hogy az a kevés VM nagyon is kritikus az egész üzlet szempontjából - tudok ilyen konkrét példát, nem is egyet.)

Lehet, hogy menő infrastruktúrában/val dolgozol, de hidd el, más is van itt, aki nemcsak az anyósa notebookját nyomogatta eddig, minden másról legfeljebb olvasott. (és akkor még nem is feltételeztem, hogy netán nálatok sem minden 100%; láttam már drága infrastruktúrát jó nagy spof-fal, amitől kvázi az egész cég megállhatott volna...)

- 2x10gbit van LACP-vel, viszont fallbacknek ott a gigabit - de azt csak akkor hasznalnank, ha elpukkanna a kartya - ami me'g nem tortent meg

- ismetlem: fallback. ha tenyleg meghalt minden, akkor van egy plan B. ez meg mindig jobb, mint a teljes connectivity loss, szerintem. de ha nem igy gondolod, erdekel, hogy mit csinalnal, mert az, hogy dugjunk bele 2 halokartyat, nem megoldas (es nem is penzugyi zonvata van: fizikailag nem fer bele a fel-U-s gepbe tobb...)

- senki nem mondta, hogy ne legyen LACP, mint irtam is, nalunk minden gepen van; csak azt irtam, hogy ha egy switchhez megy az LACP, akkor semmi mas nem tortent, csak athelyeztuk a spofot a halokartyakrol a switchre... de ha van 2 NIC, 2 switch, mLAG/VPC-vel, akkor az mar kiraly.

azt meg megjegyzem, hogy en az iSCSI-t is LACP felett csinalom, nyilvan ezzel is lehet hitvitat generalni.

nyilvan van mas is, aki ilyen infraval dolgozik, senki nem vitatta :) csak azt mondom, hogy a sok gep kozott, ami atment a kezem alatt meg, a halokartyahalal a legritkabb eddig, de nyilvan ezt embere valogatja, lehet, hogy csak mi voltunk szerencsesek.

- "fallbacknek ott a gigabit - de azt csak akkor hasznalnank, ha elpukkanna a kartya - ami me'g nem tortent meg". Ha ESXi szinten van erőforrás tartalék a fürtben (márpedig szokás), akkor minek GbE-en kínlódni? Vagy minek 10GbE, ha GbE-en is elfut a cucc? Ráadásul ha jól értem, kézzel konfigoltok át GbE-re (ha nem, akkor pedig ott van annak a veszélye, hogy valaki félrenyom valamit). De ha automata is az egész, nekem akkor sem kerek ez a felállás: ha elpukkan a hálókártya, akkor az adott ESXi kiesik a csere idejére, aztán visszaáll szolgálatba.

- Hálókártyák száma: más a tároló és más a szerverek. A tároló (eredendően erről volt szó) nyilván sokkal kritikusabb, ott nem hagyható ki az LACP (NFS esetén), mert nem lesz "normálisan redundáns". Ha a szerverek esetén nem oldható meg a redundáns kártya, akkor az ember hozzácsapja az alaplaphoz a hálókártyát meghibásodás szempontjából, ez van, lehet vele együtt élni, de tudni kell róla.

- Az "ennyi gepre en nem lacpznek egyaltalan" és "senki nem mondta, hogy ne legyen LACP" kijelentések között én ellentmondást vélek felfedezni, de lehet, hogy csak öregszem :-).
(Az alapkövetelmény, hogy ilyen környezetben a hálózat redundáns, anélkül nagyon korlátozottan van értelme bármi mást redundánsá tenni.)

- iSCSI+LACP: nekem az iSCSI SAN technológia, így eddig MPIO-t csináltunk. Első blikkre bármilyen tárolóval sem lehet ezt megcsinálni, ha pedig tároló oldalon nincs LACP iSCSI-hez, akkor nem világos, miként áll össze ESXi oldalon összesen 2x10GbE kapcsolattal (ettől még nem zárom ki a lehetőségét, csak jobban el kellene rajta gondolkodni, illetve meg kellene nézni).
Így hirtelen értelmét sem látom, ez miért jobb, mint az MPIO? Talán egyenletesebb terhelést lehet elérni a különböző kapcsolatokon megfelelő LACP beállítás mellett, de ez sem feltétlenül igaz.

- aktiv/passziv interface van: ha lehalna a 10giga teljesen, akkor szerintem van ertelme gigara atallni, a congestion meg mindig jobb, mint ha teljesen lehal, de megegyezhetunk abban, hogy nem ertunk egyet :)

- elmentunk szerver iranyba szerintem, ha a storagerol beszelunk, akkor en mar reg atalltam ceph-re majdnem mindenutt, igy nem zavar, ha egy gep vagy akar egy teljes rack elpukkan. teljesen distributed storage a jovo (mint pl a vSAN is, ha mar VMware vonalon vagyunk)

- igazad van, pontatlan voltam, es nem azt irtam, amit igazabol akartam: arra gondoltam, hogy ha keves fizikai gep/VM van, de nincs penz megegy switchre (mert ha jol emlekszem egy switchen vegzodo LACP-rol volt szo), akkor az nem lehet mission critical, hiszen nem csinaltunk semmi mast, csak athelyeztuk a spofot a nicrol a switchre... erre gondoltam a nem LACP-znek alatt. a szereny velemenyem szerint hiaba lesz a halozat redundans ha a switch barmikor epukkanhat, mert csak egy van... vagy azt nem is neveznem redundans halozatnak :)

- szerencsere mar csak egyetlen iSCSI-s dobozom van, igy nem kell majd ilyeneken gondolkodnom ;-) (oda is ceph megy)

Kezd egyen frekvencia lenni, így világos, köszi :-)

Annyit fűznék hozzá, hogy elosztott tárolóval lehet, hogy a GbE még inkább problémát okozhat, mert olyan adatforgalmakat is belassíthat, aminek semmi köze az adott géphez, azaz sokkal nagyobb hatása lehet infrastruktúra szinten ("hagyományos" tároló architektúra esetén csak az adott szervert és azon futó VM-eket érinti a hiba, elosztott tároló esetén pedig nem tudhatod, mire van hatással).

Arra kiváncsi vagyok, hogy 5 év múlva mi lesz az elterjedt tároló architektúra, én még nem annyira látom a szerver+tároló felállás *általános* nagy előnyét, de lehet, hogy csak azért, mert nem voltam olyan szituációban, amikor fájdalom a hagyományos.

Például vSAN-ból elég sok "normál" tárolóbeli funkció hiányzik, illetve a skálázhatósági lehetőségek nem annyira szimpatikusak (tároló kapacitás bővítésével számítási kapacitást is kell bővíteni, ami adott esetben nem kevés többlet licenc költséget is indukálhat).

Egy rendszerben minél homogénebbek és dedikáltabbak az elemek, annál könnyebben kezelhető, átláthatóbb, elosztott tároló esetén nagyon jó statisztikák (és jövőbe látási képesség) kellenek megfelelő döntésekhez (hosszú távon is minél homogénebb szerverek legyenek).

Például mi történik 3-4-5 év után, amikor elhasználódnak a szerverek? Vagy 2 év után már csak teljesen másik processzor család kapható? Elhatárolt tároló esetén könnyű: legfeljebb +1 vasat kell venni új fürthöz, míg elosztott tároló esetén nem ennyire egyszerű: vagy kesze-kusza lesz, vagy visszatérünk SAN előtti időkhöz, mikor adatszigetek vannak (azaz a következő evolúciós lépés ismét valamilyen SAN).
Ezenkívül a tárolók átlagos élettartama hosszabb, mint a szervereké, ami a költségvonzat szempontjából sem mindegy. Persze itt fel lehet hozni, hogy egy teljes nagyobb tárolót sem egyszerű lecserélni (sőt).

Ha ez ügyben van konkrét tapasztalatod (vagy másnak), megköszönöm, mert nekem nem tiszta még a kép.

nem nem jol erted
hogy tudnek letrehozni nem lacp kepes switch es a vegpontok (host -ok, storage, akarmi) kozott lacp-t ha a switch nem tudja?!
de ehhez nem feltetlenul kell clusterkepes switch.
lacp ugyis ugy lesz jo ha mar clusterben beszelunk, hogy mindket switchbe egy-egy lacp trunk, es ha egyik switch megpukkan a clusterkepes switch atteszi a masik switchre/masik switchen letrehozott lacp trunkre kieses nekul a kapcsolatokat.
ha ere van szuksege akkor en ertettem felre valamit.
ha arra van szuksege, hogy ha az egyik switch elpukkan, akkor azt ket kuonallo switch-csel is meg tudja oldani (olcsobban) pl. iscsi mpio-val, amennyiben a storage oldalrol van szo.
ha nem a storage networkrol van szo, es switch kieses ellen akarunk vedelmet akkor johet be a cluster kepes switch nic teaming-gel (nem lacp -vel) egyik nic egyik switchbe masik nic masik switchbe. persze fel lehet meg egy lacp -t is huzni mindket switch fele, es a nic teaminget az lacp -k felett alakitani ki, stb.stb.
igazabol mar tokom se tudja, hogy mit akar, mert ha csak nagyobb savszelt akar lacp altal a switch es a hypervisor kozott akkor ahhoz nem kell clusterkepes switch, az masra jo. :)
viszont ha eszerint http://hup.hu/node/144379#comment-1937844 ertendo az "lacp" akkor megint masrol van szo. :)

"A problema, hogy a dd - foleg, ha a /dev/zero -t dd-zitek -, baromira nem teszt"
nem devzero-t dd-zunk, ne nezz mar teljesen hulyenek, koszi! :)
tobbtiz gigas, openssl randommal feltoltott fileokat ddzunk ide-oda es vm-ek kozott is fajlmegosztaas szintjen. akkorakat, hogy biztos semmilyen cacheba nem fer bele.

"Ami az NFS-t illeti: azert instabil, mert nem igazan turi jol a halozati hibakat. Alapertelmezes szerint UDP protokollt hasznal, aminek elmeletileg az a benefitje, hogy gyorsabb, cserebe viszont semmilyen garancia nincs meg benne, ami a TCP-ben megvan, vagyis ha egy csomag elveszett, akkor az a csomag valojaban sosem indult el, legalabbis sose fogja senki hianyolni. At lehet ugyan konfiguralni az NFS-t, hogy TCP-t hasznaljon, de ennek az a hatranya, hogy eleg csunyan csokken a teljesitmenye, VM-ekhez alkalmatlan lesz."

szerintem az regen volt mar, ahogy nezem tcp-n kapcsolodik, vmware is alapbol tcp-n nfs-ezik.
sebessegrol: a 10gigabitet ki lehet rohogve tolni nfs-en.
iscsi+vmfs kombohoz kepest a zfs+nfs kp 25-30%-kkal gyorsabb, sokkal inkabb alkalmasabbnak talalom vm-ekhez mint az iscsi+vmfs kombot.
tovabbmegyek: vm szintu backupolas is joval egyszerubb.

"Raadasul az NFS ket plusz retegen is atmegy, amin nem kellene neki atmenni. Ugye, ha belegondolsz, NFS-en at csak felcsatolt fajlrendszereket tudsz megosztani, vagyis a host gepen at kell menni a VFS-en is, nem csak siman a blokkeszkozt dobaljuk. Plusz, a kliensnel szinten fajlrendszerkent latszodik az NFS, vagyis ott is atmegyunk a VFS-en. iSCSI eseteben mindez kisse maskeppen van, hiszen az iSCSI-n kiajanlott eszkozok blokkeszkozkent latszanak, vagyis - jo esellyel - mar a host oldalon se megy at a rajtuk meno forgalom a fajlrendszer-kezelon (ez persze kicsit - de csak kicsit - valtozik, ha LVM van ervenyben)."
pont hogy iscsi eseten van plusz regeteg, plusz overheaded, amire rajon meg a vmfs filerendszer is. gondold ezt at. persze ez zfs+nfs eseteben igaz, mi ugy hasznaljuk.ű

"Az iSCSI hatranya, es ami miatt bizonyos eszkozokkel lassabb lehet, az az, hogy stricten TCP-n kommunikal. Itt eleg sokmindennel lehet jatszani, a jumbo frame-tol kezdve a switch oldali konfigig, de az a mondas, hogy ha iSCSI storaget epitesz, akkor iSCSI-kompatibilis halozati eszkozket kell venned. A 10G-s cuccok azok jellemzoen ilyenek egyebkent, de tesztelni kell, sokat, sokfelekeppen. Nalunk vegul az volt a jo megoldas, hogy direktbe kotottuk ossze a HV-ket a storage-gel, switch kozbeiktatasa nelkul."
nekunk switchen megy keresztul a 10g, kulon vlanban, nem ertem mirol beszelsz. nem pocsolunk jumbo frameokkal, minek? 10gbit atmegy rajta. mint mondottam, nfs-unk is tcp -n megy, termeszetesen. nalad valami gebasz lesz, vagy hozanemertes, esetleg dzsunka, gagyi eszkozok.

szerintem az regen volt mar, ahogy nezem tcp-n kapcsolodik, vmware is alapbol tcp-n nfs-ezik.

ne is torodj hrgy84 nfs kurzusaval :-)

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

"sebessegrol: a 10gigabitet ki lehet rohogve tolni nfs-en."

Hat, ez eleg sokmindentol fugg, NFS szervertol es NFS klienstol is. Regebben, legalabbis a 2.6-os kernelek idejeben meg TCP-n merhetoen lassabb volt az NFS az UDP-hez kepest, ha barmilyen, Linux-alapu szerver volt mogotte (ez takarja mind a PC-alapu cuccokat, mind pedig az olyan storage boxokat, amin valami OpenXXX cucc futott. Elvben az NFS szerver elinditja mindkettot, a kliensen mulik, mit hasznal by default. Nekunk raadasul nem VMwareink voltak, hanem Xenjeink meg XenServereink, amik foleg szinten Linux alapu kliensek voltak, a XenServerben raadasul jo regi kernel dolgozott, lecserelhetetlenul.

VM-szintu backupolas: Hat, en LVM fole epitettem, mert akkoriban a ZFS Linux oldalrol fasorban sem volt, BSD-t meg nem akartunk mas okbol kifolyolag, a Solaris meg mar par eve is haldoklott, plusz azzal vegkepp nem volt senkinek tapasztalata, meg nekem se. Az LVM ugye azert jo ilyesmire, mert ott a snapshot funkcio, amivel eleg egyszeru volt a gepeket backupolni, a kesobb vasarolt HV-kezelo cucc pedig pont ki is hasznalta ezt a lehetoseget (felig-meddig annak a system requirementjeit vettuk alapul a tervezesnel).

Ha VMware-rel hasznalod, akkor persze az NFS-nek van ertelme, mert o alapertelmezes szerint mindenkeppen fajlban fogja tarolni a gepeket, Xen/KVM eseteben van meg csak az a lehetoseg alapbol, hogy LVM kotetekre is ki tudja osztani a gepet. Nalunk ez utobbi felallas volt, es emiatt a gepek mentese is joval gyorsabb volt, mert csak az LVM snapshot idejere kellett pause-olni, ami kb. egy pillanat muve, kimaradt valami ket ping.

Nalunk is atvitte switch a 10G-t, azzal hiba nem volt, csak a vegen arra jutottunk, hogy felesleges meg hardvert beiktatni a rendszerbe, ami elromolhat, cserelni kell, pluszkoltseg, amikor volt eleg luk es volt eleg kabel ahhoz, hogy ezeket direktbe is osszekossuk. Vagyis igazabol a TCO-t csokkentettuk. Persze a konfig ugy lett osszelove, hogy kesobb barmikor be lehessen rakni a switcheket, ha esetleg bovul a rendszer plusz HV-kkel, de akkor ugy nezett ki, hogy az a kapacitas, ami ott volt, az eleg egy darabig, ha meg keves lesz, ugyis uj site-t is kell nyitni, mert addigra mar igeny lesz, hogy tobb fizikai helyen is legyenek gepek.

Ami a jumbo frameket illeti, kicsit megkeveredtek bennem a dolgok, nem faradtan kellene kommentelni, azzal akkor jatszottunk, amikor meg nem voltak 10G-s switcheink, mert nem volt akkora teljesitmenyigeny. 10G-nel persze nincs szukseg ilyesmire, az egy oszinte dolog: vagy atmegy, vagy nem megy at, es akkor szar valami eszkoz.
--
Blog | @hron84
Üzemeltető macik

"Regebben, legalabbis a 2.6-os kernelek idejeben"

Regen, az MS-DOS 6.22 idejeben meg IPX/SPX halozaton jatsszottam, BNC-n keresztul, 10(?)Mbiten.
Raadasul minek a 2.6-os kernelerol van szo egyaltalan? A vmware-nek? a storwize-nak? a freebsd-nek? a freenas-nak? a storage-nek? Arra akarok ravilagitani, hogy elee senki nem beszelt itt linuxrol (gondolom annak a 2.6-os kernelerol beszelsz), meg a 2.6-os kernel-re az elozo mondatot tudom valaszolni.
Inentol a hsz -ed amugy nem relevans.

"Elvben az NFS szerver elinditja mindkettot, a kliensen mulik, mit hasznal by default."
oooo, nem tudom, nalam csak tcp alapu nfsd -k indulnak alapbol. rc.conf -ban legalabbis -t van megadva. Mi hogy van defaultban, mi vaan? Erted, attol hogy nalad EGY rendszeren egy osregi kernelen gondolom egy bitang regi gepen valami hogy van/volt defaultban, az nem relevans. Sot, sok cuccban direkt kell bekapcsolni az NFS udp-t...

"VM-szintu backupolas: Hat, en LVM fole epitettem," ...
Hogy jon ez ide? Illetve ebbol a szempontbol mi a kulombseg a zfs snapshot es az lvm snapshot tekinteteben? Ha nem nfs -t hasznalsz, hanem iscsi -t, akkor hogy backupolod a storage gepen lvm -mel a vm-eket?? Csak nem az isci disk-raw fileokat snapshotolod???!

"Ha VMware-rel hasznalod, akkor persze az NFS-nek van ertelme, mert o alapertelmezes szerint mindenkeppen fajlban fogja tarolni a gepeket,"
Ez hulyeseg, tobb okbol. Egy: minden vegul fajlban tarolja a gepeket. :) Ketto: vmware alatt is van tobb lehetoseged, pl. vmfs-en disk image, raw disk, iscsi lun, stb....

"Xen/KVM eseteben van meg csak az a lehetoseg alapbol, hogy LVM kotetekre is ki tudja osztani a gepet. Nalunk ez utobbi felallas volt, es emiatt a gepek mentese is joval gyorsabb volt, mert csak az LVM snapshot idejere kellett pause-olni, ami kb. egy pillanat muve, kimaradt valami ket ping."
Tovabbra sem ertem a backupodat. Egy, nem a xen/kvm "osztja ki" a gepet LVM kotetekre, hanem a keretrendszer, amit hasznalsz kore. Pl. proxmox ve 4 tud kulon lun-t, kulon zvol -t, kulonbozo formatumu disk-imageket, stb.stb. kijelolni, mint diskimage taroloja. Aztan a xen/kvm/qemu whatever -t ugy parameterezi fel..

"mert csak az LVM snapshot idejere kellett pause-olni, ami kb. egy pillanat muve, kimaradt valami ket ping."
hm? ezt ugy szoktak, hogy a hypervisor-on futtatsz egy live snapshot-ot, majd mikor ez letrejott, akkor csinalsz a live snapshotrol/egesz geprol a live snapshot-tal egyutt egy zfs/lvm snapshotot, majd ezt mented. Ezutan az elkeszult live snapshotot opcionalisan azonnal, vagy rotalva torlod. Milyen pause van nalatok?? Azert ez igy nem tul jo megoldas, hogy vm szintu backup idejere pause-olgatod a gepeidet.. Pl. kerberos eetbe felnek, hogy az idoeltolodas miatt problemazna, stb...

"Nalunk is atvitte switch a 10G-t, azzal hiba nem volt, csak a vegen arra jutottunk, hogy felesleges meg hardvert beiktatni a rendszerbe"
Nalad akkor se live migration, se shared storage se semmi nincs, hanem egy madzagon ra van dugva egy storage gep egy darab hypervisorra. Ez is egy megoldas, csak akkor ne adj tanacsokat cluster ugyben, mert nem ertesz hozza, nincs tapasztalatod. :)
Tovabba ha nektek eleg, hogy egy darab csigabiten log a hypervisor a kliensek fele, akkor mi szuksegetek amugy 10G storagera? Eleg lenne a gigabit, vagy 2-4 gigabit bondingolva. :)
Valamint azt mondod, hogy nalatok is atvitte a switch a 10gbit-et, amit arra valaszoltal, hogy en elotte irtam, hogy nfs-en ohogve atmegy a 10gbit a switchen (tcp-vel). Tehat most nem ertelek. Lassu szar instabil az nfs vagy nalad is atviszi konyneden a 10gbit-et? :) Dontsd mar el. :)

"Ami a jumbo frameket illeti, kicsit megkeveredtek bennem a dolgok, nem faradtan kellene kommentelni, azzal akkor jatszottunk, amikor meg nem voltak 10G-s switcheink, mert nem volt akkora teljesitmenyigeny. 10G-nel persze nincs szukseg ilyesmire, az egy oszinte dolog: vagy atmegy, vagy nem megy at, es akkor szar valami eszkoz."
Es mostmar vannak 10G switcheitek? Mit dugtok ra, ha nem a storaget meg a hypervisorokat? :)

lattal mar te netapp-ot kozelrol? Csakhogy kontextusba lehessen helyezni a fikazasodat. Mert en nem tapasztaltam, hogy rosszabb lenne iscsi-n az i/o(?) teljesitmenye...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

4 nodeos cluster 4.0-s Proxmox-szal, NFS storage alattuk. Nem túl régóta üzemel (cirka másfél hónapja). Egy kisebb bajom volt a tűzfalával (ékezetes betűket mertem használni a szabályok megjegyzéseiben, azt nem annyira szerette) de egyébként rendben van.

HA-t csak KVM gépekkel tudsz, LXC konténerek nem tudnak live migrálni. Mi community repoval használjuk.

--
openSUSE - KDE user

( junior013 | 2015. 12. 07., h – 14:28 )

Bár, én némi tesztelés után egyelőre lemondtam róla (marad a natív KVM Ubuntu-n), de becsatlakoznék, hátha okosabb leszek.

A shared storage-ra az én tervem shared LVM over iSCSI (LUN-okat részben FreeNAS, részben DELL EQL szolgáltatná), de nálam ott ledobta a láncot a Proxmox, mikor egy újra húzott tesztnode-ra felcsatolt, előzőleg használt LUN-ról felhúztam az LVM-et, de a rajta levő - előzőleg használt - vm disk image-et egyszerűen nem lehettett felcsatolni egy újonnan definiált virt. géphez, majd később szó nélkül el is tűnt, mintha sosem létezett volna. Ezt így hogy?

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

( uid_10547 | 2015. 12. 07., h – 18:59 )

Sziasztok,

pont most néztünk ProxMox-ot, mert mostanság a citrix féle xenservernél egyre több gondunk jön elő, pl most CPU cserék után hiába maszkoljuk a procik featurejeit, ha a jobb procis server felől a rosszabb felé live migrálunk, elhalnak a vm-ek, és restart kell.
Esetleg van valakinek tapasztalata xenserver felőli átállásról? Esetleg migrálásokról, hogy mennyire jól bírják a heterogén procikat?

köszi

Attól függ mennyire heterogén környezet (intel<->amd?:)). A KVM egyébként ezt az esetet is megoldja ha generic subset-et használsz (-cpu qemu64), bár, nah, ez nem a legjobb megoldás.
Sajnos ez egy ilyen dolog, ezt ilyen környezetben nem lehet megoldani. Ha live migration-t szeretnél, akkor igazából a homogén környezet egy nagy feltétel
Egyébként xen -> proxmox ez alapján menni fog: https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE

// Happy debugging, suckers
#define true (rand() > 10)

Hát, itt azért baromi nagy különbségek vannak, lényegében minden.
CPU freq nem számít, de 12 helyett 16 core (thread), 16 helyett 22 mb l2 cache, l1-nél pedig 192 vs 256 kb.
És akkor bizonyos cpu utasításokról nem is írtam amik szintén tudnak jelentős problémákat okozni

// Happy debugging, suckers
#define true (rand() > 10)

Az hogy 2 év egy dolog, de ezek közt generációs különbségek vannak.

Ahogy másik is mondták ha live migration-t akarsz gond nélkül akkor homogén környezet. Különben eléggé lutri lesz.

Nem tudom melyik megoldás vállal garanciát arra, hogy a live migration fog működni nem homogén környezetben.

Fedora 22, Thinkpad x220

( szollosiimre | 2015. 12. 08., k – 23:11 )

Elindult a 3 gép a node-ok elérhetetlenségét a lan kártyák lekapcsolásával teszteltem. 1 perc-en belül újraindul a problémás node, majs kb 2 perc múlva a virtuális gép újraindul a resource group maradék egyik elemén. Kellemes.

Live migration pipa, de volt olyan, hogy kiakadt a szolgáltatás:
TASK ERROR: command 'ha-manager migrate vm:100 pve1' failed: exit code 2

( szollosiimre | 2015. 12. 12., szo – 10:39 )

Kicsit elszaladt a téma a hálózati irányba, annak ellenére, hogy az adott. Sebaj. NagyZ-nek köszönöm a rengeteg türelmet és kimerítő válaszokat a datacenter switchekkel való tapasztalatairól, azt hiszem ezzel eléggé értékessé sikerült tenni ezt a témát.

Ugyanakkor:
A teszt környezethez hozzáadtam a no-pve-subscription repository-t, mivel a teszt környezethez sem árt némi update. Ehhez itt kaptam megfelelő dokumentációt:

https://pve.proxmox.com/wiki/Package_repositories

A frissítések és rebootok után a teszt virtuális gép nem indult el. Erre a support azt javasolja, hogy vegyük ki a HA-ból, majd rakjuk bele ismét. Ezt követően szépen működött a HA migráció, mivel Ha-környezetbe állított vm esetén a HA manager végzi a gép újraindítását is.

ha-manager disable vm-id
ha-manager delete vm-id
ha-manager add vm-id

Arra nem kaptam választ, hogy ilyenkor hogy történik az átvitel. Az látszik, hogy a gép újraindul, ugyanakkor nem tudom van-e szabványos leállítás, annak érdekében, hogy a memóriaállapot tiszta legyen. Ez egy adatbázis környezetben elég fontos lehet.

Továbbra sem világos, amit a 4.0 HA-ban, a különböző network csatolókról írtak. Egyelőre két hálókártya közül a host-only-ban raktam össze a clustert, az mégis a normál bridge-es kapcsolaton állt össze.

( szollosiimre | 2015. 12. 14., h – 10:27 )

Nem egészen értem, a fencing-et a HA-ban.

Ha jól értem úgy kellene működnie, hogyha elhallgat a gép, akkor a biztonság kedvéért újraindítja, ezzel leállítja a virtuális gépet, tehát a memória állapot kíírásra kerül. Majd ezt követően indítja el új hoston. Jól feltételezem?

( Elbandi v | 2016. 01. 20., sze – 01:32 )

az uj verzioban atirtak a "szegeny ember ha storage" (=drbd :D) reszt, lvm-over-drbd megoldas helyett, drbd-over-lvm felepites lett, amit a drbdmanager segitsegevel hasznalnak. ami eddig kibukott: a disk atmeretezes nem mukodik. (itt abbahagytam a kiserletezest). Viszont kiprobaltam a regi megoldas, az is me'g mukodni latszik.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

3.2, de nem upgrade, inkább újrahúztam az összes node-ot mert a hálózatot is nagyban megvariáltuk (10g sfp+ -ra raktuk át a storage hálót, illetve a belső cluster hálót is).
Több munka volt vele, de így tisztább az egész ;)

// Happy debugging, suckers
#define true (rand() > 10)