Sziasztok, én már ezt azt csináltam ESXi-ben, de azok leginkább egszerű 1 db ESXi host, X db lemezzel, helyi VMFS datastore-okkal.
De most giga mega át akrom alakítani az itthoni lab-ot. (Keretik nem azt kritizálni, hogy miért ekkorát... csak... mert ez a hobbim 
)
Szóval tudom mit szeretnék, csak performancia stempontjából nem tudom melyik lenne a jó megoldás. Igazából azt nem tudom a Datastore hogyanan vagyis HOL legyen? Az biztos, hogy erre célra lesz pár TB SSD hardware LSI RAID5-ben, és pár tucat terabájtnyi SAS winyó. RAID5-vagy JBOD ez majd fájlrendszer függő.. Ja és van egy LTO-7 library Vagy VM-be migrálódna, vagy standalone vas lenne: egy tűzfal, egy archiváló rendszer + LTO7 kezelés, NAS, na meg sok tucat VM erre-arra
A "basic" megoldás amit nem akarok:
- Egy db ESXI, sok datastore-al, minden VM lokális VMFS/VMDK-ban. Tűzfal, archiváló rendszer, NAS, st... minden VMFS-en, VMDK-val. Ahogy a klegeccerűbb... Ami ezzel bajom van, hogy nagyon félek hogy teljesen szétforgácsolódik a lemez teljesítmény...
Opció A (kicsit trükkös):
- Egy db ESXi. Az SSD-k szokásos VMFS alapú datastore. Erről bootol az ESXI is. De a NAS is csak egy VM lenne ebben, aki az összes HDD-t megkapná RDM-ben, vagy akár azt a komplett SCSI vezérlőt passthrough-ban amin a HDD-k vannak. Aztán ebben a VM-ben Linux alatt ZFS, Btrfs, stb lenne. Aki "visszaosztaná" a Datastore-t NFS-ben magának a host ESXi-nek EZ mondjuk vicces így tudom, de működne... Ami nem teccik, hogy szerintem az LTO-7 "éhségét" (~300-600 MB/s vagy több) nem igazán bírná ez VM kiszolgálni. És hát a VM-ben kialakított NAS-tól sem kelle túl sokat várni (Bár mondjuk maga az ESXi itt a VM direkt "fizikai" lemezkezelése miatt nem sokat szólna ebbe bele...)
Opció B:
- Egy valós vas, közepes telesítménnyel, natív Linux-al. Ezen semmi VM. Ebben lenne az összes HDD és az LTO-7 library etetése (+backup és miegymás). Fájlrendszer mint fentebb (ZFS,Btrfs, stb). Itt aztán diszk performancia (a lehetőségekhez képest) maxon lenne... Szóval egy natív NAS ahogy kell. 10Gbe interfésszel...
Valamint lenne egy mésik vas, az ESXi. Ebben csak az SSD lenne, szokásos VMFS datastore-al. És egy 10Gbe csatolón az NFS alapú Datastore-t is használná... Ami itt nem teccik, hogy még egy energizabáló hangos hősugárzó
Van amit nem igazán vettem figyelembe, ami a döntést segíti?
Jogos a félelmem (tapasztalatom) hogy a lemezkezelés a VM-ben (főleg ha még egy VMFS-VMDK "réteg" is közte van) azért odavág a teljesítménynek? Főleg... HDD-nél.
Hozzászólások
Sub
Hány sas winyó, milyen iops-al?
Jó cucc a 10gbe, alacsonyabb a latency, de meg is kell azt pörgetni hogy valóban értelme legyen.
Kikellene mérni ezeket a dolgokat kezdésnek, kiszámolni ki kivel van...
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"
Ja vinyók nem olyan extra, valami HGST SAS nearline sorozat, asszem 7k2-sok csak.. Nagy iopsra amúgy ott az SSD :)
De talán a rettenetes nagy iops nem is fontos, mert a VM-ekben nem ezer klienses adatbázisok lesznek...
(Fészbúkozáshoz és Jútyúb nézegetéshez jó lesz a HDD is :):):) Csak vicc...)
ha nem esxi lenne, hanem mondjuk KVM, akkor a hypervisor hoston is megcsinálhatod a btrfs/zfs "datastore"-t.
Gyanítom, hogy nem licenszelt cuccról van szó, tehát a csilivili webes felületen kívül semmi sem szól esx mellett (nincs se CBT, se backup api a free verzióban.)
Ingyenesben is van CBT, csak kézzel kell bekapcsolni.
backup api nélkül semmit nem ér, az meg nincs benne
attól még be lehet kapcsolni és működik.
Nem világos, mit akarsz ezzel az egésszel (mit szeretnél tanuni/tesztelni), szerintem túlbonyolítod.
"basic" megoldás: miért akarsz "sok" "datastore"-t? (egyébként "datastore-ral" helyesen írva, ha már angolul írod). Minél kevesebb, annál jobb: kevesbé töredezik a tárterületed, jobban ki tudod használni a teljesítményt.
Olyat is tudsz, hogy VM-ben futtatsz ESXi-ket, és akkor fürtöt is tanulhatod egyetlen vason.
Arra van esély, hogy az LTO7 nem fog működni VM-ben SAS felületen.
A sokat, nem annyira soknak gondoltam... egy az SSD egy meg ami HDD alapúaknak. Persze persze, nem úgy gondoltam hogy egybefüggő területeket darabolok szerteszét :)
Jaj... igen sok ezer szempont van még ahogy írtátok köszönöm, amit figyelembe kell venni...
Én most a csak a NAS alapú datastore kialakításával kapcsolatban érdeklődtem...
Hogy nagyon nagy teljesítmény veszteség ha azt is VM-be teszem, vagy ilyenen ne is gondolkodjak?.. Mert ez egy nagyon elvetélt ötlet? :):):)
Igen az nekem is eszembe jutott, hogy egy KVM alapú virtualizációt használnék. Akkor legalább válogathatok mely funkciókat futtatom natívban (NAS,LTO-7, tűzfal, backup rendszer) és melyeket pakolok a VM-be.. És mindezt egyetlen egy nagy vason... De valahogy az ESXi nőtt a szívemhez... Úgy, hogy amúgy van amit utálok benne... pl. pont a lemezteljesítmény veszteség.
Tehát a kérdésem inkább filozófiai jellegű, hogy melyik az a fő irány, amiben érdemes gondolkodni... hogy a datastore "merre" legyen. Amúgy azért is szeretném hogy egy NAS-on (akár natív akár VM-ben) legyen, mert szeretnék a konténerekhez mással is hozzáférni kívülről+ (pl. backup, más hostok). Csakhogy NAS-ra még sosem csináltam datastore-t és nincs tapasztalatom... főleg a teljesítmény tekintetében... (Mert már a helyi lemezes VMFS-sem tetszik :):):):) Ja iSCSI nem érdekel, kb ugyanott lennék mint a helyi lemezeken lévő VMFS-el :):):)
Kis háttérinfó: Amúgy a végcél, hogy legyen egy (otthoni felhasználáshoz képest) tetemes erőforrással rendelkező virtuális rendszerem. Na jó... nem csak otthoni, mert mellékállásban igazságügyi szakértő vagyok otthon, és gyakran van hogy egész komoly (lefoglalt) vállalatirányítási rendszereket kell virtuális környezetben összerakni és, vizsgálni... erre eddig is 256GB RAM, 12 magos rendszerem volt, "sok" HDD és SSD-vel. Persze itt a "komoly" teljesítményt nem arra kell kihegyezni hogy lesz ezer kliens, mert az csak 1 lesz :):):) Én... De ezek a dög szoftverek így is több szervert+klienst és nagyon sok RAM-ot igényelnek... De amúgy a kialakítandó VM-ek teljesen vegyes célra kellenek... (A mostani végcél, amihez más a sarokban sorakoznak a cuccok, egy régebbi Dell R720XD szerver, 384GB RAM és 2 db E5-2680v2, meg LSI MegaRaid kártyák, sőt még egy nVidia GRID K2 is háta lesz vGPU, 8x4TB HGST SAS és 4x2TB SATA SSD, és még bónusz 2x512GB SSD disk cache-nek)
A villanyszámláról most nem is beszélek... de hát van aki drogra költi, én meg villanyra :)::)
Nekem itthon félig maszek, félig céges dolgaimra a következő van:
Del T320 8x LFF, 1x Xeon E5 (8 mag, L kivitel), 64GB memória. Van benne (5.25" helyen) 2x 256 GB és 2x 512 GB SATA SSD az alaplapi vezérlőn, a kisebbeken ZFS mirror-on fut a Proxmox, a nagyobbakon szintén ZFS mirror a Proxmox alá lokális tárolónak VM/CT képeknek (a host ZFS ARC 8 GB-ra van korlátozva). A hot-swap helyeken 8x 3 TB 7k2 NLSAS HDD, amit egy IT módban futó PERC H310 vezérlőn keresztül (PCIe passthrough) megkap egy FreeNAS VM.
A gépen OPNsense a tűzfal VM, a FreeNAS VM a hálózati mindenes tároló (16 GB memóriát kap), a host-ról NFS-en egyedül bizonyos VM/CT backup-ok kerülnek rá, VM/CT diszkek nincsenek rajta, csak a hálózat egyéb gépeinek és a klienseknek tárol adatot. Ezen kívül még vagy 20 különböző VM/CT fut "céges" és magán feladatokkal. Az egész mondjuk nem túl teljesítmény igényes, átlagosan 30-40% között van az host-on a CPU terhelés és 70% körül a RAM foglaltság. VM szintről backup egy külön Synology NAS-ra megy a fontos adatokról, ahogy bizonyos VM/CT backup-ok is mennek erre. A FreeNAS-ról és a Synology-ről is megy backup B2-be.
Mielőtt ezt összeraktam ilyen homeoffice-os költség és helyhatékony megoldásnak, én is sokat találgattam, hogy legyen. A két gépes verziót dobtam, mert a havi tizen ezres villanyszámla (amit kettő ilyen gép lenyel) már nem hiányzott (ez az egy elmegy 5-6000 Ft-ból). A virtuális NAS-on tárolt VM-eket végül elvetettem teljesítmény és megbízhatósági okokból. A virtuális NAS jelen felállásban simán kiszolgálja az 1 GbE helyi hálózatomat, teljesítmény probléma nincs az én felhasználásom mellett. Az előző szerveren Hyper-V Core volt, de én utáltam a nehézkes menedzsmentet PS-ből (nem krekkelt Windows szerver, ahnem a tényleg free volt).
Aztán elsőre ezen az "új" szerveren ESXi volt fent, de gyorsan Proxmox-ra cserélődött, mikor átgondoltam, hogy egy csomó dolognak nem kell saját VM, hanem egy sima LXC is épp elég szeparációt ad az én igényeim szerint, és sokkal kevesebb az overhead. Amikor a Proxmox csere jött, akkor a PERC H710-et kicsetéltem egy IT módra szoftverezhető H310-re, mert a ZFS alá nem kell HW RAID, a Proxmox meg szintén remekül elvan ZFS tükrön natívan.
Most a Proxmox-al bogarat ültettél a fülembe :):)
Jópár éve néztem, akkor még nekem fapadosnak tűnt az ESXi-hez képest... Meg az ESXi olyan "enterprise-osabbnak" hangzott :):):)
Nekem is az lenne a szimpi valami hasonló megoldásban, hogy válaszhtatnék mit mibe valósítok meg:
- A natív Linux-ban (backup, NAS, LTO-7 kezelés)
- A VM-ben (minden egyéb)
- és még ott lenne az LXC is
Ja tényleg... Az oké hogy PCI passthrough van a Proxmoxba... nade vGPU van-e? Ha mondjuk a GRID K2 kártyát szabdalnám fel a VM-ek között?
Közben találtam a fiókban egy AMD FirePRO R5000 kártyát... Ami nem valami modern (7 éves), de nagyon érdekes :):):) Van egy Ethernet csati is rajta :)
Ami még jól is jöhetne. Mert lenne a VM-ek között egy komolyabb "desktop" gép is a mindennapi munkához, amihez egy izmosabb GPU-s grafkártya jó lenne...
Na ez ehhez elég lesz nekem... (Kb nyolcad teljesítményű mint egy nVidia 1080, de cserébe 100W-al többet eszik :) )
Ami pedig ez Ethernet csatit illeti a grafkártyán:
A kártyára a GPU mellé egy Teradici TERA3 PCoIP "szerver" van ráintegrélva... fullosan. Utóbbi nulla OS supportot igényel. Így a hálózaton elhozom a "képet" :) 2 vagy 4 monitorig talán. Kb mint egy IP KVM :)
Van két kis Dell PCoiP vékony kliensem, hátha össze tudnak fütyülni a grafkártyával :):):)
Mert az RDP valahogy nekem annyira nem jött be... Néha az alkalmazások bukdácsolnak vele, ami amúgy konzolon meg menne.
Persze megmarad az RDP, ha éppen a világ végéről jelentkeznék be ahol nincs PCoIP.. :) Bár szoftver PCoIP kliens is van...
De amúgy találtam itthon olyan TERA3-as kártyát, amin HDMI bemenetek vannak, és tualjdonképpen bármilyen standard VGA kártya "képéből" PCoIP-ot csinál... Meg valami APEX2800 PCoIP HW gyorsítót, ami semmi más, mint egy jó nagy hűtőbordás kártya minden fajta csati nélkül (jó cak PCIe van)... :)
Asszem valamikor jól rákészültem a PCoIP alapú remote megoldásokra, és a virtualizációra, minden sz@rt össezvásároltam e-bay-ről:
- nVidia Tesla K10 (ami könnyen 100%-os GRID K2-vé alakítható) -> ESXi vGPU
- AMD FirePro R5000 VGA/GPU kártya -> VGA + PCoIP szerver
- Teradici TERA2220 PCoIP host kártya
- APEX2800 PCoIP HW offload kártya (asszem csak ESXi támogatja) (ez volt legdrágább mind közül... és semmi haszna nem lesz Proxmox-al... inkább vettem volna 128 GB RAM-ot még, többet ért volna)
- Dell Wyse 3040 vékony kliens (PCoE/Blast/RDP)
- Dell Wyse PxN vékony kliens (PCoE és talán RDP)
Hmmm... ennyi PoC-et végigpróbálni :):):):)
Én is a Proxmox-nak adok +1-et. a 9 virtuális gépből 8 LXC-n fut, egyedül a pfSense tűzfal kapott egy VM-et. És egy i3-as Fujitsu P900 desktop, nem szervergép, 32 GB memóriával.
"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"
Épp nemrég az asztali gépem egyik SSD-jéről leválasztva 120GB-ot, feldobtam rá egy Proxmox teszt rendszert. Jelenleg fut rajta VM-ben egy OPNSense tűzfal, Openmediavault NAS és egy Win 10. Utóbbinak USB vezérlő és egy GTX 1050Ti kártya átadva. Hibátlanul üzemel ez így együtt. A VGA átadásával volt némi agyalás, olvasgatás, plusz menet, az nem volt annyira egyszerű, de működik.
Évek óta használok Proxmox-ot mindenfélére, szerintem jó és stabil rendszer, megszerettem. Aminek nem kell VM tényleg nagy nyereség hogy ott az LXC. Minden fajta mentés igen jól megoldható benne, snapshot funkciók stb.
Van gép amin már kétszer is volt nagy verzióváltás, Debian alap, nem volt semmi probléma.
Én néhány ügyfélhez a szimpla szerver cseréjekor ESXi-t tettem fel, hogy az igényeknél jóval nagyobb teljesítményű hardvert (mert nem lehetett már kellőképpen "gyengét" kapni az egyszerű feladatra) kicsit jobban el lehessen használni. Ezekre ESXi free került, mert ötletként sem merült fel olyan igény, amit később csak a fizetős verzió tudott volna. Működnek is szépen, de az elejétől zavart valamiért, hogy az ESXi nekem egy fekete doboz, és úgy éreztem, hogy ha bármi történik, akkor nem tudok vele semmit kezdeni, csak az újratepelítést próbálhatom meg. (Mondjuk az eddig eltelt néhány év alatt nem történt semmi, működnek...).
Ezen felül a legfőbb problémát az okozta, hogy jó/konzisztens VM szintű mentést rettentő macerás csinálni a free verzióval. Kvázi csak a GhettoVCB jön szóba, semmi más, és azt Bacula-val csak SSH-n keresztül utasítgatva, trükkösen elérve lehet rendesen automatizáltan menteni máshová. Szóval macerás.
Egyszer csak valamiért előkerült a Proxmox, és kipróbáltam. Akkor már mondjuk valamelyik 5.x verziónál tartott, szóval nem az ősidőkben került elém. Nagyon kényelmes a webes felülete, tetszett, hogy majdnem mindent lehet CLI-ből is csinálni, és, hogy valójában egy sima Debian az alapja, nem egy "zárt" rendszer. A Xen-variánsokkal szemben azt írták rá már akkor is, hogy kifejezetten jó a Windows guest kompatibilitása is (ami néhány ügyfélnél számít), és az LXC kipóbálása megintcsak feldobott, hogy milyen egyszerű egy ilyen konténert elindítani, és mennyire kevés erősorrás-vesztesége van (Proxmox előtt nem használtam ilyent, csak FreeBSD-n jail-t ami elvében hasonló).
Az ESXi free-hez képest aduász a beépített, nagyon jól működő VM/CT backup. Megfelelő tároló választásával élő VM/CT-ről is készülhet gyorsan konzisztens backup, ami (nálam) két NAS-ra kerül, ahonnan mennek B2-be (3-2-1). Teljesen automatizáltan, és (hardcore Linux-osok előtt szégyenlem, de) teljesen GUI-ból konfigurálva. Ráadásul nemsokára kész lesz a Proxmox Beckup szerver (most bétában érhető el), ami inkrementális és differenciális mentéseket is tud készíteni, így nagyon idő- és tárhely hatékony lehet a komplett VM/CT mentési folyamat, ingyenesen...
A PCI passthrough valóban nem olyan egyszerű, mint ESXi-nél, ahogy csak kijelölöm a megfelelő eszközt, és egy host úraindítás után odaadhatom bármelyik VM-nek. Itt kicsit matatni kell konfig állományokkal, meg udev-vel, stb. De van majdnem mindenhez már leírás a neten, és ESXi alatt nem működő egzotikus dolgokat is látom, hogy használnak Proxmox alatt így.
A vGPU kérdésben semennyire sem vagyok jártas, de szerintem úgy tudsz előre lépni, hogy ha a hardvered tud valamiféle SR-IOV jellegű működést, és a (jellemzően BIOS-ban vagy UEFI-ben definiált) virtuális példányok látszanak külön PCI(e) eszköz azonosítóként a host-on, akkor minden további nélkül oda tudod adni különböző VM-eknek a virtuális GPU példányokat. Az SR-IOV képes hálózati kártyák virtuális többszörözése teljesen jól működik Proxmox alatt (persze a host hardvernek is támogatnia kell az SR-IOV-t).
Proxmox-al azóta már csináltam HA rendszert, most Ceph-fel (hiperkonvergens klaszter keretében) próbálkozok élesben, és eddig komoly problémába nem ütköztem soha. Működik.
Az ESXi nagyon jó termék, irtózat jó a kompatibilitása megfelelő hardver esetén, a fizetős tényleg mindent tud (sőt), viszont a free verzió néhány, de annál bosszantóbb korlátja miatt szerintem jobb választás a Proxmox kis/olcsó/ingyenes rendszer esetén (meg klaszteres/HA igény esetén, kis költségvetés mellet is a vSphere árazása alapján).
erről a hyperkonvergens cuccról meg tudsz osztani néhány részletet?
Milyen vasakkal, megy és mennyi a cpu/mem overhead a node-okon a storage miatt?
Még csak teszt fázisban vagyunk, így éles működési adataim nincsenek. Valamint ez egy próba projekt egy számunka új területen. A kiindulás alap az volt, hogy nem találtunk könnyen telepíthető és üzemeltethető, nagy rendelkezésre állású storage-et használtan (amit meg tudunk fizetni, ebből új nem jöhetett szóba az ára miatt). FC-s ajánlatok vannak szép számmal, de 1) nem értünk hozzá semennyire, 2) eléggé drága mindennel együtt egy FC-s rendszer használtan is (meg sokat is fogyaszt arányaiban). Így jutottunk oda, hogy legyen hiperkonvergens, de a VMware vSAN megint kiesett az ára miatt, viszont a Proxmox régebbi jó tapasztalatok alapján kézenfekvő volt, és ott van benne a Ceph elég jól támogatva. Összesen 10-20 VM fot majd rajta, nem nagy számítási igénnyel (web, e-mail kiszolgáló, ilyesmi).
A rendszerben 4 node van, mindegyik egyforma: Dell R630 10x SFF, 2x E5-2630L CPU, 128 GB RAM, 2x 10 GbE, 2x 1GbE hálózat, H330 HBA, 2x 250 GB M.2 SATA SSD, 2x 250 GB M.2 NVMe SSD (az M.2 meghajtók PCIe slot-os illesztőkön, hogy ne foglaljanak hot-swap helyet a fő tárolótól), 2x 1.92 TB 2.5" SSD és 2x 1.8 TB 10k SAS HDD.
Szempont az alacsony fogyasztás, hogy ha DC-be kerül a rendszer, unit alapon bérelt helyre, akkor benne legyünk a havi fogyasztási keretben.
A 2x 250 GB SATA-n van a Proxmox ZFS mirror-on, a két NVMe meghajtó RocksDB/WAL DB-nek (HDD-k mellé) és cache tier-nek szántuk, de utóbbi ugye már nem támogatott, így ezek üresek minden node-on egyenlőre. A 4 db hot-swap meghajtó mind Ceph OSD, device class alapján konfigurált SSD és HDD-pool-okban. Jeleneleg 3/2-es replikációval 3.4 TB használható az SSD pool-on és kb. 3.2 TB a HDD pool-on (0.7-es nearfull érték mellett).
Persze a beépített M.2 meghajtók nagyon nem enterprise megoldás, de költséghatékonyság miatt minél több hot-swap helyet akartunk megtartani tárkapacitás bővítésre, és úgy kalkuláltunk, ezen belső meghajtók hibájánál egy host leállítása mellett teljesen működőképes marad a rendszer a javítás idején.
Teszteket sokat futtattam már, de szívesen futtatok újabbakat, ha van valami elképzelés. Igazából nem tudom még, hogy milyen tesztet érdemes nézni, ahogyan azt sem, hogyan kellene ennek a rendszernek teljesítenie. Nincs még ilyen téren tapasztalatom.
Kettő 10 GbE swtich van, bond-olt VLAN-okkal megoldott aktív-backup kapcsolatokkal. Mind a szerverek, mind a switch-ek dupla táposak. Egyedül a router szóló, de csak 1 becsatlakozásunk lesz egyenlőre, így azt a redundanciát meg gondoltuk fontosnak növelni. A VM-ek saját VLAN-(ok)ban, a Proxmox cluster (Corosync) megint másikban kommunikálnak az 1 GbE kapcsolatokon, a Ceph publikus és replikációs hálózatok is saját VLAN-ba kerültek elválasztva, és amíg minden működik, addig 10 GbE mindkét Ceph VLAN sebessége egymástól függetlenül.
A VM-ek Ceph RBD-n lesznek, lokális tárolón csak ISO image és backup lesz (az is csak ideiglenesen). Mind a négy node a Proxmox cluster része, és mindegyiken vannak Ceph OSD-k. Az első hármon fut MON és MGR. CephFS vagy RGW nem fut (egyenlőre, nincs rá szükségünk).
Az overhead-ek: CPU overhead a Ceph miatt olyan nagyon sok nem lesz, mert a replikáció nem annyira CPU igényes mint az EC (olvasmány, nem tapasztalat). Memória: a host ZFS-nek limitáltam 8 GB-ra, a Ceph még all-default fut memória terén, de mivel nem sok és nem nagy OSD-k vannak, így elvileg 10-20 GB között lesz a max overhead (Ceph terén).
Ha van még kérdésed, szívesen válaszolok, ha tudok. Nem titkos semmi.
köszi a sok részletet.
Üzemeltetési tapasztalat más rendszerrel, hogy a "storage-node" + "compute-node" - nem jó ugyanarra a node-ra rakni:
> storage-node: tároló szerver (iscsi, nas, ... )
> compute-node: virtuális-gépeket futtató szerver
Két rendszert el kell szeparálni - ne legyen közös "stack":
PÉLDÁK:
-Virtuális gép megeszi a hoszt gép CPU/memóriáját: belassúl a "közös" storage
-Hoszt gépen futó IO megeszi a hoszt gép CPU/memóriáját: belassúl a virtuális gép
Az ilyen közösített "stack" rendszereket "hamis/ál-redundancia" csoportba sorolom mert, "elméletben" függetlenek, gyakorlatban mégsem.
Másképpen megfogalmazva, "a mentést is az éles rendszeren tároljuk".
+ specialis le/felkapcsolasi szekvenciara van szukseg
Kulonosen elmeny egy ilyet ujrainditani szabalytalan lekapcsolas (aramszunet) utan.
Igen, ezek valóban lehetnek (és biztosan lesznek is) problémák. Viszont finanszírozási oldalról nem annyira egyszerű egy virtualizációs és egy külön tároló klasztert megfinanszírozni mikro vállalkozásnak, próba projektre. Szóval ha az anyagiak korlátoznak, akkor muszáj kompromisszumot kötni.
Majd az idő megmutatja, jó-e ez a mi céljainkra, vagy sem. Igazából nagy bukó nincs akkor sem, ha nagyon sok probléma merül fel, és inkább nem tesszül éles használatba ezt a felállást. Ugyanis egy külön storage-et venni, és a tárolási feladatokat oda átrakni a meglévő szerverek megtartása mellett is lehet, ha úgy alakul. Nyilván ahhoz nagyon rosszul kell működnie a tesztek alatt, hogy még újabb eszközöket akarjunk venni inkább.
Jópár hyperconverged rendszert építettem az elmúlt pár évben, és a per vm ár kedvezőbb, mintha mindent szétszedsz. Itt nem csak a szerver beszerzési árára érdemes gondolni, hanem ha rendesen üzemelteted, akkor a support díjban is jelentős megtakarítást tudsz elérni. Nyilván azt is figyelembe kell venni, mi a workload igénk, van ahol ez nem fit és tényleg külön kell szedni.
Köszönöm a pro hozzászólást a sok kontra között! Már kezdtem elkeseredni, hogy ennyire benéztük, és ilyen kicsi rendszerben senki sem használ ilyen "közösített" megoldást, mert nem költséghatékony ellenben túl összetett.
Remélem nekünk is több jó tapasztalatunk lesz, mint rossz, ha teljesen összeáll.
Ehhez annyit tennék hozzá, hogy VMware vSAN-on kívül is van "gyári" hiperkonvergens megoldás. Azaz nemcsak fizikai tároló van "drágán" vagy csináld-magad "olcsón". Azaz ilyen aspektusból is felmerül, hogy mennyire éri meg küzdeni és akár kockáztatni (a teljesség kedvéért hozzátéve, hogy gyári megoldás is hagyhat kívánni valót maga után).
Én bennem csak az merült fel (olvasva a másik Ceph szálat is), hogy ez a sok szívás és apróság biztosan olcsóbb-e, mint egy (akár használt) redundáns tároló? (akár FC alapon) Rengeteg időtök elmegy rá, arra is esélyt látok, hogy folyamatosan "simogatni" kell, míg egy normális rendszert ha egyszer beüzemeltél, túl sokat nem kell vele vesződni, nincsenek kötéltáncok, viszonylag jól definiált esetek vannak, nem túl nagy számban.
2-4 node és 10-15T storage igény esetén eddig akárhogy számoltam, olcsóbb volt FC vagy 10Gbit storage, mint CEPH és hasonszőrű társai.
Sok igényt akár 1Gb iSCSI/NFS is kielégít.
Hát, számszakilag nem tudtuk kihozni ugyan ennyiből a külön tárolós megoldást. Aztán az majd csak idővel derül ki, hogy ebből a "kevesebb" pénzből sikerül-e a feladathoz megfelelő rendszert előállítani, vagy megkerülhetetlen a külön tároló használata.
Azért amikor elkezdtük összeszedni, hogy egy FC-s tárolóhoz mi minden kell, és az mibe kerül akkor azért meglepődtünk. Ráadásul a fogyasztás is szempont a havi üzemeltetési költség miatt, és az FC eszközök nem jeleskednek a takarékosságban (na persze azokról beszélek amiket használtan, az elképzelt árszinten meg lehet venni mostanában).
10GbE alapon (iSCSI/NFS) is nagyon jó rendszert össze lehet hozni, nem feltétlenül kell FC. Gondolom 10GbE switcheket mindenképpen vesztek.
A költségbe a munkaidőt is illik beleszámolni, valamint - bár ezt nyilván nem egyszerű - az üzemeltetési kockázatot is. Az más kérdés, ha egy csapatnak a kisujjában van egy "ingyenes" rendszer, de a leírások alapján nem feltétlenül ez a helyzet.
Mikro vállalkozásnál azért a legtöbben nem a beletett munkaidő költségét kezdik el számolgatni új projektnél (lehet kellene, de akkor költség alapon kb. senki semmibe nem kezdene bele amíg egy pár fős cégről beszélünk...)
Az ingyenes rendszer meg csak akkor lesz bárki kisujjában, ha megtanulja. Ezt a lépést nem lehet átugrani (mondjuk ezt más - fizetős - rendszernél sem lehet átugrani...). Ha szívunk is vele induláskor vagy menet közben, akkor is tanulunk belőle, és a jövőben a megszerzett tapasztalatok alapján ilyen rendszert is ajánlhatunk ügyfélnek (na persze csak akkor, ha arra jutunk, hogy vállalható, nem túl sok vele a baj).
A 10GbE storage is azért esetett ki, amiért a sima SAS csatolós (mert 3 host esetén az is teljesen jó lett volna nekünk): akkor éppen nem volt elérhető semmi, számunka elfogadható áron. Csak az FC-s verziók. De az FC-nek meg a járulékos költségei annyira felvitték a végösszeget, hogy ejtettük.
Egy mikrovállalkozásnál sem ingyen dolgoznak az emberek. Ha valakinek van ideje ilyennel játszani, akkor lehet, hogy felesleges az állás (vagy amíg ezzel foglalkozik, nem tud mással foglalkozni és nem haladnak a dolgok). Az nyilván más, ha van puffer idő vagy fiatalon magának süti az ember a pecsenyét és idő dögivel van.
A tanulást tény, hogy fizetős rendszernél sem lehet átugrani, de normális rendszer esetén az erre fordított idő töredéke egy "csináld magad"-hoz képest. Egy alap FC infrastruktúrát megtanulni sem igényel több hetet/hónapot. Lehet, hogy a beüzemelést érdemes másra bízni és akkor adott egy alap kiinduló pontnak.
Ez alapján ez a szituáció "majd megoldjuk" felállásnak tűnik, aminek van kockázata a résztvevők között. Amíg reszelitek a rendszert, addig igazából semmi nincs, aztán elindul, de lehetnek bakik és addig sem teljesíti az elvárást, ebből lehetnek szóváltások. Az elején úgy tűnt, hogy "ingyen" lesz "minden", de végül esetleg "drágán" lesz a "semmi". Kiderül, hogy az "olcsón valami" pedig jobb lett volna.
A kérdés tipikusan egyszerű: az üzlet számára mennyit ér meg a rendelkezésre állás. Pénzre fordítva ki szoktak derülni a *valós* prioritások (melyek idővel változhatnak).
De nyilván minden helyzet más, főleg ha valakinek van ideje játszani és nincs nagy kockázat.
Ajanlanam ilyen helyzetben az essential csomagokat, 100k kornyeke a 3 nodeos csomag, lehet menteni veeam-mel, es ha kell vcentert is tartalmaz.
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"
Hát, ha szükségem van a HA funkcióra (mi elsősorban ezért csinálunk klasztert, hogy hiba esetén reagáljon önállóan), akkor mindjárt az Essentials Plus Kit kell, ami viszont 1.38 millió Ft nettó... A nem-Plus verzió igazából a remote API-kat és a központi menedzsmentet adja, de ettől még szóló ESXi-knek lehet tekinteni a gépeket (nagyon egyszerűsítve). Persze nem vagyok VMware szakértő, csak a funkció listát átolvasva így tűnik.
A megjegyzés arról szólt, hogy az ingyenes ESXi-hez képest nem egy vészes költség az Essentials licenc, ezért sok apró kellemetlenségtől megkíméli az embert. Pl. egyszerűen használható normális mentő szoftverrel.
ha a VM-ből adsz datastore-t az ESX-nek, és arra más VM-eket telepítesz, abból összejöhet egy kellemes kis deadlock szituáció.
Én is szórakoztam ilyesmivel régebben - nem emlékszem már melyik hypervisorral - de baromi nagy borulás lett belőle.
Azóta lehet, hogy ez változott, de én azért tesztelném egy ideig mindenféle IO terheléssel, mielőtt fontos adatot rakok rá....
Igen asszem a jó válaszra marad a jó öreg megoldás: ki kell próbélni...
Végül is megy egy mostani ESXi vas is... Abba teszek RAID kártyát és plusz HDD-t... kipróblom NAS a VM-ben szitut.
Illetve van egy üres vas is, meg 10Gbe kártyák direkt kábellel... Aztán meg kipróbálom a külön NAS megoldást...
Pfff... Lesz vagy pár nap :) De akkor már tudok dönteni..