nagyon jó hogy sok fogalmat próbálsz elmagyaráni/megértetni, sokkal emészthetőbb a cikk 
üzenetek
hozzászólások
TErmeszetesen, ahogy egy proxmox, openstack vagy cloudstack is. De a tesztnek hatarozott celja volt.
Jó kis írás! Végre egy kis Vmware 
"- Raid10 helyett raid5: Mivel a hálózat limitál, ezért megfelel a lassabb raid is, cserébe kapnánk kb. 1.2TB plusz kapacitást."
Soha soha soha!.... Ejj de rühellem a Raid 5 öt... Kellet már összekaparnod összeomlott raid 5 öt? Sose keljen 
Egyébként akár teszt erejéig ajánlom a vmware vSAN-t! Isten király. Optimális használathoz kéne a 10 Gigabit ethernet, de elmegy az 1 Gigabit-tel is. Plusz kell neki SSD cache.
License ára pedig bőven jó. Van 50 USD/ VM es konstrukció ami szépen megéri a 2495 USD/CPU hoz képest. Gyakorlatilag egy 4 hostos cluster 2 cpu/host alapon 400 VM ig költséghatékonyabb.
vSAN-t mindenkinek!
(#3) frescho
Valami jó kis openstack tesztet megnéznék, vagy beszállnék, akár szerverrel is. Csak valaki szervezze le 
[ Szerkesztve ]
Több dolgot nem értek, ezek közül az egyik, hogy miért NFS-t használtál LACP-vel, ami ugye hash alapon fog terheléselosztást biztosítani kevés végpontnál valszeg elég kiszámíthatatlan és gyenge minőségben ezáltal jó eséllyel csak 1db GbE kártyát fog használni.
Ahelyett hogy software-es iSCSI-t használtál volna több ethernet-interfésszel és port bindingel ezáltal lehetővé téve egy aktive-aktív (round robin) terheléselozstásos multipathingot. (feltéve hogy a Gluster képes erre. A FreeNAS9.3 például iSCSI-vel tuti képes erre.)
Még egy ehhez kapcsolódó kérdés:
LACP kapcsán egyszer source+dest mac hast írtál (vmware oldalon) másszor Etherchannel-t (switch oldalon). Miért nem IP hash (vmware oldalon)+Etherchannel(switch oldalon) -t komót használtál? (Igazából én mindig azt hittem, hogy ha switchen beállítod az Etherchannel, akkor onnantól muszáj IP Hast használnod vmware oldalon)
J.
[ Szerkesztve ]
Kellett. De Raid10-el is jartam mar meg. Nincs 100%-os megoldas es jelen esetben a raid5 folott can meg egy gluster, ami attukrozi az adatot a masik oldalra.
Ezzel a vSAN 50 dollarral dragabb, mint a gluster. Teszt rendszernel nem elvaras a 100%-os mukodes, a production alatt site redundans FC alapu storage van.
Openstackbol van tesz clusterem otthon es tervben van egy nagyobb epitese is. Ha van erdeklodes tudok rola irni.
Openstack engem erdekelne, egyebkent koszi a cikket, erdekes volt!
Javíts ki ha tévedek:
Minden hoston két virtual switchet hoztam létre. Az első a külső forgalomért felelt, ahol minden host és a tárolásért felelős storage VM-ek is külön IP-t kaptak.
Tehát ennek a switchnek voltak az uplinkjei és azokra állítottál be LACP-t
Ezen zajlott a GlusterFS cluster, vCenter és a többi VM kommunikációja is, amiket VLAN-ok segítségével szeparáltam el.
Tehát itt ment a management traffic, illetve storage traffic is, ha az adott hoston nem futott GlusterFS példány.
A második vswitch-en a storage VM és a hostja kommunikált. Mivel a második switchre kötött hálózati csatolóknál mindenhol ugyanazokat az IP-ket (192.168.1.1 és .2) vettem fel, ezért a cluster konfigurációnál egyetlen közös tárolónak látta a gluster clustert a vSphere.
Ennek a vSwitch-nek nyilván nem volt uplink-je (vagy legalábbis a fizikai hálózat nem switchelte a forgalmát), ezért futtathattál 4 darab VM-et ugyanazokkal az IP-kel.
Ha a hoston futott GlusterFS, akkor az a storage eléréshez mindenképpen az ezen a vswitchen levő interfészét használta és a GlusterFS belső interfészéhez (192.168.1.1-2) ment.
Ha a host olyan blokkokat akart olvasni, amelyek nem voltak rajta ezen a GlusterFS instance-on, akkor a hoston futó GlusterFS instance a másik hálózati interfészén keresztül lekérdezte a GlusterFS cluster megfelelő tagját
Jól értem?
Poor man's VSAN...
J.
[ Szerkesztve ]
"Teszt rendszernel nem elvaras a 100%-os mukodes, a production alatt site redundans FC alapu storage van."
Viszont sokkal többet kapsz a pénzért és nagyobb teljesítményt és rendelkezésre állást.(automatikus adat és vm mozgatás stb) 
Nem poénból kerül pénzbe. 
Egy két ismerőssel már 5.5 vSAN óta tesztelgetjük, most 6.0 ás az már még jobb. 5-10 éves hardverből kis + kis feljesztés [10Gbit ethernet + támogatott raid vezérlő "Pass-Through " támogatással] és szinte egy-két új szerver árából össze van rakva egy 5 ös cluster... kb 99.999% rendelkezésre állással drága storage nélkül.
Amúgy érdekes cikk volt köszi !
[ Szerkesztve ]
hallador
(addikt)
frescho
Köszönöm a cikket ez nagyon kis alapos munka, és ami fontosabb sokan hálásak lesznek ezért...
Köszi.
(#2) kraftxld
Mást sem tanítanak a Hyper-V tanfolyamokon, hivatalosan (MS20409, Server Virtualization with Windows Server Hyper-V and System Center), abban mi a kihívás? A Hyper-V tudja ingyen is, ha éppen nem akar összeomlani, nem dobálja el a hálózati csatolót, vagy éppen, nem rántja el a komplett "Cluster"-t a mentő rendszer, mert hiányzik egy patch a hostokról....
Kár hogy csak elméletben stabil a rendszer, gyakorlatban csak olyan Microsoftos...
Ingyen elmegy kólával, csak éppen arra itt a Xen, ami legalább működik is.
Szerencsém volt 10 hónapot "foglalkozni" (szenvedni) Hyper-V-vel, talán mint az MS termékeknél úgy általában a 3 - 4-dik kiadás használható is lesz...
Persze ez szigorúan szvsz
[ Szerkesztve ]
Erre a szimpla MS anyázásra miért is volt feltétlenül szükség?
Ha valaki tud nekem esetleg hivatalos linked dobni a VSAN licensz struktúrájához, azt megköszönném, én semmit nem találtam. (nálunk is terítéken van a téma egy tesztrendszer keretében)
J.
hallador
(addikt)
Nem annak szántam, csak éppen miért kellene valamiről írni bármit, ha valaki felmegy az MS oldalára, és az alapján megcsinálja, ebben a cikkben pont az volt a jó, hogy a VMware hivatalosan nem tudja ezt, az az a VMware azt mondja, hogy nem feltétlenül támogatott, a Microsoft meg támogatja.
A Tény meg tény marad. A Hyper-V minden szempontból elég erősen el van maradva a VMware-től, ráadásul láthatóan nem azért tart ott a Hyper-V ahol tart mert jó, hanem azért mert van mögötte egy jókora marketing, az az egy hegy pénzt ölnek bele, hogy azt higyjük, hogy jó, de nem az...
Nem anyázás volt, hanem tények nagy különbség, de még csak fikázás sem, mert nem azt mondtam hogy "szar" hanem azt, hogy messze van attól amit ígér, ami megint csak tény....
Az NFS a 2-es belso vswitchen ment. Azert NFS, mert az netivan tamogatott, mig az iSCSI nem a glusternel.
A hasheles-nel mindegy, hogy IP, vagy MAC alapu, a storage gep a parjaval maximum 1Gbit-en fog kommunikalni, kiveve ha aktiv-aktiv megoldast hasznalnek. Szimplan ido es eroforras (ket interface osszesen) tul sok variaciot nem tudtam kiprobalni.
#8 kerdeseidre a valasz:
Minden gepen futott Gluster FS. Tehat az adott host NFS-el a belso masodik vswitch-en kommunikalt. Ahogy irod is, ezert tudtam azonos IP-ket hasznalni. A storage host (gluster) az elso vswitchen kommunikalt a tobbivel es olvasta a tobbi brick tartalmat pontosan ugy ahogy irod. Igen, ez a poor man's vSAN es megy ingyenes ESXi-vel is, csak nem lehet egyben adminolni.
djgeg: Kifejtened melyik feature-re gondolsz? Vmotion nem fugg vsan-tol, vsphere replication pedig az essential plusban is megvan.
hallador: VMware-nek van ilyen funkcioja, ha megfizeted. Csak esetleg a vas aranak felet kifizeted a licencre.
[ Szerkesztve ]
Ha csak tesztelni kell akkor vgun!
http://www.vmug.com/
[VMUG Advantage Subscribe]
200 USD 1 userre (többre kevesebb/user) és megkapod az egész vmware palettát 1 évre (non production). Ezek mellet pedig kapsz jó kis kedvezményeket oktatóanyagokra stb.-re.
Árak vmware bejelentésből:
[link]
"VMware Virtual SAN 6 and VMware vSphere Virtual Volumes are expected to become available in Q1 2015. VMware Virtual SAN is priced at $2,495 per CPU. VMware Virtual SAN for Desktop is priced at $50 per user. The new All-Flash architecture will be available as on add-on to VMware Virtual SAN 6 and will be priced at $1,495 per CPU and $30 per desktop. VMware vSphere Virtual Volumes will be packaged as a feature in VMware vSphere Standard Edition and above as well as VMware vSphere ROBO editions."
Ygg
(senior tag)
4. Hyper-V verziónál vagyunk. 2012 R2
Semmi gondom vele.
Előtte a 2008 vagy a 2008 R2-vel sem volt, pedig azok tényleg a kezdet voltak.
VMware előadásokon meg mást sem hallottam, mint a Hyper-V fröcsögő szidalmazását.
Elhiszem, hogy a VMware-nem nagy tapasztalata van a virtualizációban, az MS meg új szereplő...de...
A Hyper-V benne van az árban, mondjuk, hogy "ingyen" van.
A VMware iszonyatosan drága, ha egy használható rendszert szeretnél.
20+ virtualizált szerver fut jó ideje gond nélkül.
Nem tapasztaltam olyan stabilitási gondokat, mint Te.
Biztos a Hyper-V okozta a gondot? Rendesen be volt állítva?
Lehet, 100+ szervernél már gond lenne.
Ezt nem tudom.
A Hyper-V ingyenes, és tesztelni teljesen jó, és nem kell fizetni a storage meg a live migration-ért sem.
Egy HP VSA-t rárakva pedig már majdnem VSAN élmény lehet, ez is ingyenes 1TB-ig.
[link]
Ertem, hogy tobb ev MS tapasztalattal a hatad mogott a Hyper-V-t javaslod, de ugy gondoltam, hogy erthetoen leirtam a cikkben, hogy miert VMware:
„Mivel VMware vSphere már üzemel a cégnél, ezért azt is végiggondoltuk, hogy talán az lenne a leginkább költséghatékony, ha ilyen alapokon építkeznénk."
Maskent leirva: Uj rendszer bevezetese, annak megtanulasa ido es ezert penz. Raadasul ami az egyiken tuti jol mukodik nem 100%, hogy ugyan olyan jol fog menni a masikon. A teszt/QA rendszernel ezert kell az ESXi.
Termeszetesen nem ragadunk itt le, a csoportunk nagyon nyitott:
Alternativakent KVM felmerult, mert CentOS alapu gepekrol van szo es linux uzemeltetesi tapasztalat boven akad, de egyszerre tobb lepest atugorni nem tunt szerencses otletnek. Masik termek, ahol KVM alapu a virtualizacio, de "osdi modon" csak parok vannak elobb, mint utobb valamilyen VI-t epitunk, de az is KVM alapu marad, csak kozponti management, GUI es mas hasonlo "luxus" dolgok lesznek bevezetve. Erre pl. jo lehet egy oVirt vagy openstack, de az utobbi sajat tapasztalataim alapjan nem problema mentes fokent ha upgradelni akarja az ember. Az oVirt lassan kezd kikupalodni, 2 evvel ezelott azert voltak vele apro gondjaim, amik nem a stabilitassal, hanem a hasznalat egyszerusegevel voltak kapcsolatosak.
Hyper-V az office infrastruktura ala fog kerulni kozeptavon, de azt nem tartozik mar a csoportunkhoz. Persze a szomszedokkal sokat beszelgetunk, de soha nem fogom olyan jol megismerni, mint azt, amit napi szinten butykolok.
Ugyanannyi ideje bütykölök VMware-t meg Hyper-V-t, a gyárban elég komoly VMware vCentereket is kell rugdossak
Rengeteg cégnél eléggé WTF arcot vágnak amikor a tesztrendszert is licenszelni szeretnék minden funkcióval VMware-re. Elég sok helyen a termelés VMware-n a tesztelés meg Hyper-V-n megy. Néha van küzdés amikor VM-eket kell mozgatni a két rendszer között, de már vannak egész jó cuccok hozzá.
A legnagyobb előnye még, hogy nem olyan szigorú a HCL mint a VMware-nél, bármin amin elfut a 2012 R2 és a proci támogatja a virtualizációt menni fog.
Nem azt mondom, hogy ez a tuti, csak elég sok helyen látom, és aránylag jól működik. Van persze néhány nyűgje, de nem megoldhatatlan.
A KVM-et meg nem ismerem, így nem tudok sokat hozzáfűzni.
Pont ezert szuletett a teszt, mert nem meg akartuk sporolni az arat. ESXi ingyenes, szoval abbol is lehet epiteni teszt rendszert, csak a kozponti management hianyaval kell akkor megbekulni, vagy az olcso max 3 szervert tamogato licencet kell megvenni hozza.
Az a 10%, konvertalas, vagy a deploy massaga az, ami miatt mar nem lesz valid az egesz. En pont forditva vagyok vele, mint te. VMware es KVM tapasztalat van, szoval ha ingyenes rendszer, akkor inkabb valami linux alapu cucc. Ott is hasonlo gondokkal kellene megkuzdeni, mintha Hyper-V es VMware lenne, a nagy kulonbseg az, hogy sokkal konnyebben boldogulnek vele. De a gond faktort minimalizalva kiesik a Hyper-V es a KVM alapu cuccok is. Szimplan a teszt nem a hypervisorrol, hanem a storage megoldasarol szolt.
Miért nem próbálkoztok az általad is említett oVirt, KVM, Gluster, Openstack(!) nagyvállalati, Red Hat által támogatott verzióival?
A költségeket meg kell nézni, de lehet, hogy az áraik mellett beleférne még egy oktatás is, hogy el tudjátok sajátítani. Na meg ott van a gyártói támogatás is, ha elakadtok valahol.
Nagyon sokan elköltenek sok pénzt a drága, tulajdonosi, sok kötöttséggel bíró szoftvermegoldásokra, de a nyílt szoftverekből csak az ingyeneset nézik, holott létezik középút, ahol a nyílt szoftverek nyitottsága, innovációja is megmarad, és vállalati szintű támogatás is jár hozzá.
Persze, ha csak teszt, próbálgatás a cél, akkor a lehetőség mindig meg van a közösségi változatok használatára, de hosszútávon, pláne éles környezetben szerintem mindenképpen megéri az Enterprise változatokat megnézni.
Na ez is olyan furán hangzik, hogy a tesztelés Hyper-V-n az éles meg VMWare-en
Ott a KVM, az oVirt, és ezek vállalati változata a RHEV. Az előzőek szabadon elérhetőek, közösségiek, az utóbbi meg a gyártó által összerakott, hosszú távon támogatott változat. Negyed annyi kötöttségük sincs, mint az általad említetteknek, oktatás is van hozzájuk, nem lehet arra hivatkozni, hogy nincs tudás hozzá.
Az meg szerintem csak extra, hogy ha valakinek van ideje, erőforrása, akkor a közösségi változattal úgymond azt csinál, amit akar, tesztel, átírja, gyakorol rajta, szabadon, ingyenesen.
egykettő
(aktív tag)
én mostanában a ceph-et nyúzom sokat. Ha lesz időm erre is rálesek majd.
Az ido penz. Nem csak azt kell nezni, hogy mennyibe kerul, hanem hogy van-e ra ideje a csapatnak. Ma volt openstack CEE, ahol termeszetesen ott voltunk, de ahhoz, hogy uzembiztosan uzemeltessunk egy vadonat uj VI-t nem 1-2 honapnak kell eltelnie. Ebben nem segit meg a training sem, mert azt ismeri csak az ember jol, amit tobbszor telepitett es debugolt vegig. Ez a konzervativ megkozelites, ami sokaknak maradinak tunik. VMware-nel ott van a lehetoseg, hogy ESXi-t hasznaljon az ember es akkor a hypervisor megegyezik, csak a management ter el.
Visszaterve az openstack-re. Sok dolog nagyon kezdetleges allapotban van meg, nem igazan kiforrott rendszer. Van olyan szolgaltatas, ami ket verziot ert meg es kinyirtak, nagyon sok melekaga van stb. Lehet vele production cuccot csinalni, de akkor egy ember szinte csak azt pasztorolja. Licence koltseget lecsereljuk ber koltsegre
oVirt-ot probaltam, lassan alakulgat, de nem 100%-os meg mindig. A HA megoldasa egy kinszenvedes, a management gep vezerel szinte mindent, amit kulon kell vedeni stb. Nem megoldhatatlan, csak kicsit erdekes.
Tomoren megfogalmazva: nem veletlenul fizet az ember a VMware licencert annyit.
"Tomoren megfogalmazva: nem veletlenul fizet az ember a VMware licencert annyit."
+1
"oVirt-ot probaltam, lassan alakulgat, de nem 100%-os meg mindig. A HA megoldasa egy kinszenvedes, a management gep vezerel szinte mindent, amit kulon kell vedeni stb. Nem megoldhatatlan, csak kicsit erdekes."
Próbáld ki a RHEV-et is, van belőle 60 napos eval.
Az oVirt tobbet tud a RHEV-nel, elvegre az utobbi anna ka a stabil verzioja. Mi a problemam az oVirt HA funkcionalitasaval?
- Eredetileg kulso hardveren futott csak a manager. Ebbol kellett legalabb ketto es valamilyen linuxos cluster megoldas. Kis mennyisegnel ez pazarlas.
- Self hosted megoldasnal, ami meg mindig nem az igazi VM-kent futhat a manager. Ezt a hoston futo cluster megoldas vedi. Csak ezt az egy gepet, ezert kell az egesz. Az install nem 100%-ig stabil meg...
- A HA-t nem a hostok, hanem a Manager vegzi, ha lehal, nincs HA. Self hostednel tehat meg kell varni, hogy magahoz terjen...
klambi
(addikt)
glusterfs-nél, azt hogy oldod meg, ha mondjuk 2 résztvevőd van,az egyiket kilövöd, a másikon meg a folyamat tovább, a 2. versenyző visszatér az élők sorába, és automatikusan "pótolja a különbséget"?
Ne kézzel hanem automatikusan, ez lenne a lényeg.
A self heal daemon elvileg rendezi. Tesztek alatt legalabbis megoldotta nagyreszt. Split brain-be kergetve mar kellett neki a manualis beavatkozas: okos modon kivettem az uplinket (switchbol jobb lett, volna ,de hajnali 2-kor mellenyulhat az ember). Csak konzolbol tudtam ujbol aktivalni, persze kozben mind a ket brickre tortent iras. Ez az, amit nem szeret...
Döglött Róka
(veterán)
Ezek szerint csak az en csoromet boki, hogy Gen 9-es vasak hevernek parlagon.
Keresunk linuxos mernokoket, akik integralnak a rendszerbe a tarsaival egyutt.
klambi
(addikt)
Na ez nekem a fő gondom, hogy kézzel kell, nem mászik saját maga után, pedig ez lenne a cél.
Privatban elkuldtem
klambi: split brain eseten az a jobb, ha nem all neki ossze vissza szinkronizalni. Egy DRBD sem teszi meg, mert csak nagyobb gondot okozna, ha valamit rossz helyre szinkronizalna. Normal restart, vagy hasonlo esetben rendbe rakja magat.
