VMware kommersz gépen

Virtualizáció

Hi!

 

Egy 2 node-os VMware clusteren gondolkodom - most tekintsünk el attól, hogy a 3 node lenne az igazi - aminek az egyik node-ján futna egy VM, ami megállás esetén elindulna a másik node-on. A VM-ben egy linux, ami 2 magot és 8GB RAM-ot igényelne, szóval picike feladat, így azon elmélkedtem, hogy odatennék 2db "kommersz" alkatrészből összerakott masinát:

Asus Prime B460M-K
Intel i5-10400
16GB RAM
2db SSD
"normális" tápegység

 

Sajnos a VMware oldalán nem igazán találtam infót, hogy a fenti hardwerek mennyire támogatottak és a live migration működni fog -e. Ezzel kapcsolatban van esetleg valakinek tapasztalata? Esetleg link, hogy hol tudnék ennek utánaolvasni?

 

Előre is köszönöm a segítséget.

  • 1481 megtekintés

( mauzi v | 2021. 01. 04., h – 04:44 )

Unatkozó informatikusok szoktak azzal végtelen időket eltölteni, hogy szopjanak nem támogatott rendszerekkel... Nézd meg, hogy mi a pénzügyi keret, és hogy abból mit lehet venni, ami támogatott. Lehet, hogy nem 10. generációs Intel proci lesz benne, de ha veszel egy pár éves, egyébként újszerű állapotú, használt szerver- vagy munkaállomás vasat, azzal minden téren beljebb vagy. (az i5-10400 árából például lehet kapni egy pár generációval ezelőtti, 10-12 magos Xeon-t.)

( zrubi v | 2021. 01. 04., h – 05:16 )

Ha játszani akarsz - mert a nem supportált hardveren való kísérletezés biztosan az - akkor a játék része az is, hogy megveszed, összerakod, kipróbálod. Ha jófej vagy, publikálod az eredményt.

Ha megy örülsz, ha nem megy, akkor újra próbálod...

 

De ha tényleg ezt akarod - a működés/nem működés alapvetően azon fog múlni, hogy abban a deszktop lapban éppen milyen diszk vezérlő van.

Mivel a desktop lapok sokkal előrébb járnak, (és sokkal olcsóbb alkatrészekből építkeznek) ezért nem fogsz találni semmilyen hivatalos utalást sem arra, hogy ez működik vagy nem.

A másik sarkallatos pont a hálókártya. az olcsó desktop lapokban rendszerint olcsó realtek van - aból is a legolcsóbb és a legújabb, tehát neked kell kipróbálni.

A gyakorlatban eddig már elég sok vason futtattam ESXi-t, még laptopon is  - szóval azért nem esélytelen :)

(de produktív környezetbe semmiképp sem javaslolt)

zrubi.hu

( agostonl | 2021. 01. 04., h – 08:42 )

Ezen a Proxmox vígan elfutkosna, ráadásul az debian alap. (bár tuti, ezért mosz kapok a fejemre :P )

( •̀ᴗ•́)╭∩╮

"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"

Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek

Ha meg akarod nevettetni Istent, készíts tervet!

Ha arra gondolsz, hogy a CPU-nak egyeznie kell a két host-ban, akkor ez így nem igaz, mert pl. a VM-ben "KVM64" CPU-t állítasz be akkor majdnem mindegy, milyen CPU van a host-ban (na persze azért durva képesség beli eltérés ne legyen köztük). Persze ehhez kell, hogy a "KVM64" CPU emuláció tudása elég legyen a futtatni kívánt VM-nek.

Igen, pontosan ez van. 

Tehát a progi licensze 1 gépre szólna, ha a masina elhasal, akkor licenszt visszavonatni, majd újat kellene kérni az új gépre. Virtualizálva amennyiben a processzor ID megmaradna, akkor ezt a licensz mizériát nem kellene eljátszani + jó lenne egy ilyen elhasalásnál nem lenne megállás.

Annyi infó jött előzetesen, hogy VMware alatt ezt gyakorlatból tudják, hogy működik, Proxmox alatt viszont nincs tapasztalat (bár qemu támogatott) ezért próbáltam VMware felé indulni. 

A sok hasznos építő hozzászólásból azt vontam le, hogy:

- kommersz gépeket beszerzem és megnézem proxmox alatt, hogyan viselkedik a szoftver

- amennyiben valamiért "nem tetszene" a proxmox alatt a szoftvernek, akkor nézek használt Dell R330-as masinát és megy rá VMware.

( asm v | 2021. 01. 04., h – 09:12 )

Ha tenyleg igeny van a Live Migrationre, annak azert van par fuggosege: pl. szukseges vCenter Server hozza (hol fog futni?) + licence, kozponti storage (vmi NAS esetleg), redundans halozat se art, stb.

Es ezen a ponton erdemes hatralepni nehanyat es atgondolni, hogy tenyleg annyira mission critical-e az az egy szem VM. Ha igen, akkor nem-e erdemes public cloudban futtatni, es nem bajlodni a redundans infraval...

A vSAN is SAN meg közös. Amiről én beszélek, az két teljesen független fizikai gép, saját local storage-al. Lehet akár a föld másik felén is. Értelemszerűen lássák egymást a hálüzaton, és akkor már mehet a live migráció. Van még 1-2 megkötés de az értelemszerű.

Fedora 42, Thinkpad x280

Errol irok en is.

Kette kell valasztani a ket esetet:

  • tervezett VM migracio (vMotion): VMware is tud storage migraciot vegezni vMotion kozben (kulonbozo hosztok lokal diszkjei kozott)
  • HA/failover eset: ehhez folyamatosan szinkronban kell tartani a vdiskek tartalmat. Ehhez kulso storage kell (SAN/NAS) vagy vSAN. XenServer/Proxmox esetben gondolom glusterfs van alatta, hogy tudjon ilyet.

igen... HA-nal erdemes megnezni jellemzoen mi szokott elromlani:

- disk -> legyen redundans, de pl. foldrenges vagy raid kartya hibaja ellen az se ved :)

- tap -> legyen redundans, bar en mar lattam olyat is kimulni

- halokartya/switchport, ritka, de elofordul. supermicroknak egyik alapbetegsege, hogy eloszor a lan portok mulnak ki aztan az alaplap...

ha vmware-s failovert szeretnel akkor valoban kell egy kozos storage, celszeruen dual controllerrel (es emiatt sas diskekkel feltoltve). ennek az arahoz kepest mar a szerver kb elhanyagolhato :)  es akkor meg ott a licensz kerdes is, az ingyenes nem tud ilyet.

ha kokanyolni kell akkor meg kell egy kvm-qemu glusterfs-el vagy valamilyen szoftveres cluster filerendszeren aztan legalabb jo lassu lesz ;)

sajnos minel inkabb HA-t akar annal inkabb exponencialisan szallnak el a koltsegek...

( KoGa v | 2021. 01. 04., h – 11:04 )

Régen foglalkoztam már vele, de nekem úgy rémlik támogatott RAID vezérlő hiányában már a telepítés sem fog menni. Nekünk az összerakott gépekben mind támogatott kártya volt.

( Yuhl | 2021. 01. 04., h – 11:12 )

Leírom nekem mi van, aztán majd kimazsolázod belőle, ami számodra érdekes:

Én tesztelési, tanulási céllal használok otthon vmware-t két node-on, storage-al. A mostani munkahelyen nincs játszós környezet, ráadásul a kulcsfontosságú szolgáltatások másik terület felügyelete alatt vannak, ezért inkább otthon csináltam magamnak játszóteret.

Ez egy-egy FX-6300 és FX-6350-es, 32-32GB RAM-al, lokálban 250GB HDD-vel, 4x1Gb hálókártyával. A hálókártyán kívül minden eleme "kommersz".

Storage egy HP kiskocka, 8GB RAM-al, 2x256GB SSD-vel (ez egy-egy datastore, NFS-el kifele) és ebben is van pluszban 4x1Gb háló. A rendszer (openmediavault) meg egy 120-ason van.

A háló belül sima gigabit, egy 8-as kis smart ciscón átvezetve. A managementre elég a 100-as.

A hostokon 5.5-ös ESXi van, a vcenter mostanában 6-os. (terraform-al játszom, 5-öst már nem ismeri, a 6-os a minimum.) Minden sima 60 napos trial licenc, a vcentert appliance-ból már vagy hatszor újraraktam, az ESX-ek ugye működési időt néznek, de azokon is van még 20-30 nap. Szerintem ezért a licenc nem probléma.

Asztalin van hekkölt workstation torrentboltból, azzal kezelek mindent.

Első 60 napos időszakban kipróbáltam a HA clustert rajta, kíváncsiságból. Van egy 8 szerveres játszós környezetem kis linux-os VM-ekkel, ide-oda dobáltam őket, egyszer-egyszer kimaradt a ping. Úgy emlékszem a reset gombot nem nyomtam meg, ezért erre nem tudok válaszolni, akkor mi lett volna.)

vmware-en a legnagyobb probléma a hálókártya, meg telepítéskor a bios/uefi beállítása, hogy be is bootoljon. Ha bebootol és hálózatod is van, onnan már minden fasza :)

A 6.5-öst, vagy nagyobbat a vcenter erőforrásigénye miatt nem javaslom (fel kell tolni valamelyik node-ra és megeszi az összes ramod, helyed)

Azt írja:

Igen, "picit" játszani szeretnék, de ha működik, akkor menne élesben...

Átgondoltam.

Ha játszani szeretne, akkor elég neki a 60 nap. A trial full repertoárt ad, kipróbálhat mindent.

Mert az első döntési helyzete az lesz, hogy kipróbálja, megy-e így. A második meg, amikor meglátja a licenc árakat, hogy akarja-e tényleg. (Az meg már az ő döntése teljesen, tanácsot sem akarok adni.)

ps: Aztán vannak olyan keygen-csodák, amivel tud magának kulcsot generálni, hostnak, vcenternek.

Csak hogy a posztolo nem otthoni jatszos kornyezetet epitene. Legalabbis nekem nem az derult ki a kommentjei alapjan.

"picit" játszani szeretnék, de ha működik, akkor menne élesben

Mondjuk Yuhl arra ertette, csak sok relevanciaja nincs a posztolora nezve.

Ja, pontosan. Az idézett mondat második felét meg mondjuk úgy, nem is "hallottam", vagy akarom hallani. Túl sok ilyen projektet láttam már belülről, hogy csak kipróbáljuk, aztán ha beválik akkor megy ki élesbe. Hogy csak tesztre kell, becsszó, másnap meg jöttek csapatostól, hogy adjak mindenkinek rá jogot, mert azzal termelnének.

Amíg csak játékra, addig teljes mellszélességgel támogatom, de a második felét én a kérdező helyében kétszer is nagyon alaposan átgondolnám, akarom-e.

A 60 nap az csak magyarosch módon szól arról, hogy -kisarkítva a dolgot- kéthavonta csinál egy full backup-ot a vm-ekről, majd újraépíti a motyót, és visszarakja a vm-eket. Én pl. a ToAD-ot dobtam ki, mert itthonra nincs rá keret - ha a munkahelyemen lesz bólintás rá, akkor a céges notebook-ra fel fog kerülni, de addig nem. Pedig az egyik, ha nem _a_ legjobb eszköz Oracle DB-k maszírozására. (Tudom, én vagyok az a hülye, aki még a WinRAR-t is megvette...)

Szeretek becsületesen élni. Lehet, hogy neked, echte magyarosch hozzáállással ez fura, de nekem ez természetes. Igen, fizettem a WinRAR-ért, mert használom. Tudom, van ingyenes alternatíva is, meg én vagyok a hülye, de ez az én döntésem volt, hogy adok egy kis pénzt a fejlesztőnek a munkájáért. Van, aki bagózik, van, aki kocsmázik, vagy épp kurvákhoz jár - én egyiket sem teszem, úgyhogy belefér szoftverre is költeni.

Nem vagyunk nagy „barátok” zellerrel, de itt igazat kell adjak neki! 3 gyerekem van, mind arra tanítottam, hogy amivel termelsz és pénzt keresel, azzal más is pénzt akar keresni, mondjuk kenyérre az ő gyerekeinek! A nagyfiam elmúlt már 30 és infósként kezdte a középsulit annó. Javában csúszott le a gépére a tört windows amikor ezt megbeszéltük, hogy ha ács lenne akkor a kalapácsot/szekercét/egyebet nem tudná letölteni, hanem meg kellene vennie. Az a tény, hogy letölthető, még nem jelenti, hogy helyes. A lányom steamen nyomja, elég nagyban játszik. Van jogtiszta dobozos win10 pro-ja, mert megtanulta, hogy ha a játékokért fizet, az oprendszerért is fizetni kell. Egyszerűen így korrekt! Én (szinte kizárólag) linuxot használok, de vannak programjaim amiket megvettem. Van winre is, androidra is amikért fizettem. Nincs viszont win10 amiért fizettem (van egy win8.1 licencem), mert nem használom napi munkára (majd ha kötelez rá a cégem, akkor fizesse is ki), a céges gépeken meg nem az én gondom.

Az, hogy jelen kérdés esetén van 60 napja kipróbálni, az én meglátásom szerint teljesen helyénvaló! Erre vannak a sharerware/trial verziók, el kell valahogy döntsd, hogy kell az adott termék vagy nem! Ha kell, majd megveszi. Ha nem, lelke rajta...

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

nana, nem tudom hogy jott ide ez a "termelsz es penzt keresel" dolog. itt nem errol van szo. itt arrol van szo, hogy otthon, jatszosban ki akarsz valamit probalni. ez a szal (amire en reagaltam) errol szol.

 

prodban, munkahoz termeszetesen meg kell mindent venni, szerintem ezt senki nem vitatja.

Itt az egész szál arról szól, hogy kipróbálná és majd megy élesben, erre jönnek a mindenféle savazások a 60 nap meg többi és én kifejezetten erre reagáltam: „a szokasos mekkorakiralyvagyok hozzallas a hup onjelolt hazmesteretol.”. Arra, hogy azért vannak helyzetek amikor már túllő a célon a savazás. Természetesen ha valaki nem akarja érteni a mondandót, akkor nem is fogja, de itt pontosan arról van szó, hogy a játszós után megy prodba és a kommentek egy része letámadja a megvásárlást, mert majd így meg úgy. Így szerintem egyáltalán nem a mekkorakirályság hangzott el a hozzászólásában, hanem a realitás (az önjelölt házmesterre inkább nem reagálok, mert olykor stimmel :) )! 

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

szerintem az, h ezzel a sufni epitett geppel prodba menjen, azzal senki nem ert itt egyet. en biztos nem, szornyu dolog lenne. :)

de arra hogy kiprobalja es eldontse megeri-e beleinvesztalni, arra tokeletes az n*60 nap meg a jatszos gep. en elolvastam az EULA-t, es nem tiltja semmi azt, hogy ujratelepitse az ember. az EULA a kulcshoz koti az evalt, non-prod kornyezetben engedi, es mivel a vmware annyiszor ad 60 napos evalt, amennyiszer keri az ember, igy ezzel nincs problema.

 

ismetlem: prodba rakni 2 gepes VMware rendszert ugy h eleteben nem latott meg es sufniszar gepen akarja futtatni, az az egyik legnagyobb uzleti ontokonloves amit egy ceg elkovethet.

Igen, itt is erről van szó. Tehát próba, aztán, a tapasztalatok alapján lépünk tovább a licensz vásárlás irányába.

 

Eddig debianon Xen-t üzemeltetek több "kommersz" gépen ill. Dell szervereken (feladatfüggően), néhol Qemu fut hasonlóan. Persze raid és minden "jóság" játszik, de nagy gondom még nem volt (táp-, disk hiba). Egy Dell-nek az alaplapja szállt, az új szerver meg annyira "új" volt, hogy a Xen sem akarta nagyon felmenni, talán ez volt kihívás.

Tehát annyira nem tartok a kommersz géptől, de úgy látom a VMware azért más lépcső, lehet akkor inkább proxmox felé kacsingatok.

Becsülendő, ha valaki megvesz szoftvereket otthonra, vagy támogat fejlesztőket az ingyenes programjaik után, de a winrar árát elég hamar elfagyiznánk a gyerekekkel, a vsphere legolcsóbb fajtájából meg felújítanám a kerítést a ház előtt két automata kapuval. Azért van különbség.

Ráadásul itt valami olyanra költeni, ami lehet pár hónap múlva a kukában landol... értelmetlennek látom.

Ez így igaz! Ezért nem veszek(ünk) otthonra ilyen volumenű szoftvereket. Majd ha a munkáltató elvárja, akkor fizesse! Pont ezért írtam, hogy a trial lényege, hogy kipróbáld (jelenleg én is ezt az utat járom, felépítek valamit amit be kell mutatnom azután a döntéshozók meg majd eldöntik mekkora a lik a pénzes tarsolyon. Épül, szépül és a VMware sajnos nekem sem lesz kihagyhatatlan, mert kérik. Hidd el, nem fogom megvenni ;) ). Azt azért kicsit túlzónak tartom, hogy majdnem több hozzászólás érkezik a licencelésről, mint a  felvetett kérdésre releváns válasz. Ez mondjuk nem csak erre a topicra igaz.

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

Az ember az életben sokszor nem azt a választ kapja a feltett kérdésre, mint amire számít.

A kérdező feltette a kérdést, hogy ha ejtőernyővel leugrik a tizedik emeleti ablakból, akkor mire kell figyelnie földet éréskor. Többen itt elmagyaráztuk, hogy a tizedik emeletről nem ugrunk ki ejtőernyővel, mert kitöri a nyakát.

Vannak akik siklóernyőre szavaztak.

Mi most azon vitatkozunk, hogy vegyen-e lakást a tizediken, vagy sem az ugráshoz, vagy elég bekéreckednie a másodikon valakihez, mert akkor csak a bokáját töri ki, ha baj van.

Zeller mondta, hogy ő becsületesen a strandra is vesz belépőt, ha a medencébe ugrál. (-> Ezen nem is vitatkozunk, de amint látom NagyZ inkább az ingyenes otthoni medencébe ugrálást pártolja.)

Summa summarum:  ha a kérdező megcsinálja, amit tervez, baleset lesz belőle.

(Ez így elég fárasztó volt? :) )

Én magamnak otthonra vettem egy Dell T430-as szervert és tudom ezért pokolra kerülök de vettem hozzá Windows Server 2019-es szerver licenszt is 10 db RDS user call-al.

Nem érzem tisztességesnek, hogy ha használok valamit (én) ami fizetős azért ne fizessek.

Persze megértem ha valaki otthonra csak "játszós" környezetet alakít ki és nem fizet érte (mondjuk, mert tanúlni szeretne). Anno én is imádtam főiskolán a Dreamspark (leánykori nevén MSDNAA) programot ahol ingyen juthattam Microsoft termékekhez.

 

ui: Mentségemre szolgáljon van még 2 db r200-as Dell szerverem amin Centos fut docker konténerekkel. :)

Egy nap 24 óra, plusz az éjszaka!

( VincentV | 2021. 01. 04., h – 11:19 )

Szerkesztve: 2021. 01. 04., h – 11:21

Azért nem találod a HCL-ben, mert csak a brand szerverek támogatottak. És ez egyre nagyobb szívás a különféle eszközök (NIC, hba, stb..) firmware-driver-esxi szentháromság függőségei miatt, sokszor még támogatott hw elemek esetén is lehet probléma. Ugyanakkor nálam van Asus workstation alaplapokból (x99, xeon, nvme, 40G nic) álló laborkörnyezet, amiken ESXi-is szokott futni (vsan, nsx, meg egyéb dolgok is). Azért használjuk, mert baromi olcsó, és nagyon rugalmasan lehet variálni. Nem mondom hogy volt vele bármilyen gond, de ez főképp szerencse kérdése, meg van rá esély, hogy egy vib megváltozásától (pl. update) megfeküdne az egész, mert az érintett hw elem utána nem működne. Ez viszont csak egy poc környezet, a következő lépcsőnél (normális teszt és accepctance) már levetett gen9 hp-kat használunk. Szóval éles környezetbe én biztosan nem tenném.

( thedioda | 2021. 01. 04., h – 11:52 )

Menni fog, de lapból keress másikat amin intel lan van Realtek-et nem támogatja az esxi semennyire. Nálam is járt már esxi minden féle kommersz cuccon. Vcenter mindenképp kelleni fog majd a live migration-t csak azzal tudod kezelni, kérdés hogy elég e az ha kézel tudod mozgatni vagy azt akarod hogy automatikus legyen, ha elég kézel akkor közös storage sem kell, ha automatikusan akarod akkor kell közös storage vagy inkább 3 node és csinálsz egy vsan-t alá.

Háttértár tekintetében nekem eddig mindent felismert alaplapi sata/nvme csatikon, egyedül a kis kinai 4 portos sata HBA-t nem szerette.

A kommerszebb ssdk amik nálam jók: Samsung 850/860 evo, crucuial mx300, wd green, wd sn750, hynix pc401

Minden gépem esxi 6.7 el volt telepítve.

CPU-k amivel probaltam: i5 3470, i7 3770, i5 8500, r3 1300x, r5 1600, r5 3600

Igen, természetesen van HW kiadás is, de többe kerül (mert ugye a HW is ők adják) + skálázhatóság szempontjából is korlátozottak a lehetőségek.

VM-ben lehetne rendes HA verziót venni, aminél, ha az egyik elhasal, akkor sem áll meg és a kapcsolatokat is átviszi, de pár percet kibírnak. Viszont, ha úgy alakul, akkor nem szeretnék egyből rohanni....

Azt ugye tudod, hogy failover eseten a VM ujraindul a masik hoszton, tehat lesz kieses a firewall mukodeseben.

Tobbe kerul mint 2 low cost szerver ara? Tobbe mint 2 szerver + vSphere licence + NAS?

Skalazhatosag szempontjabol: egy HW appliance-nek egy vagy tobb 10GbE portja van, mig az emlitett desktop alaplapnak 1GbE rezes portja van. Nem egy ligaban van a ketto.

Ezt nem értem, ha mi alakul "úgy"?

Ha VM-ben fut magas rendelkezésre állással két példány, akkor egyik kiesése esetén átveszi a másik.

Ha a magas rendelkezésre állást ESXi-vel biztosítod, ugyanúgy kell egy failover, ami ráadásul rosszabb, mert van egy tervezetlen leállás (konzisztencia).

Másként: ESXi esetén vSphere Essentials Plus licenc kell, valamint osztott redundáns tároló a magas rendelkezésre álláshoz (enélkül nem vagy előbbre, mintha lenne egy szóló géped lokális tárral, 4 órás támogatással). Ebből jó eséllyel kijön egy második licenc, de akár két hardver tűzfal is.

És akkor arról még nem volt szó, hogy általában célszerűbb hardver tűzfalat használni, leginkább azért, mert csökken a függőségek száma, egyszerűbb az infrastruktúra.

ha az egyik elhasal, akkor sem áll meg és a kapcsolatokat is átviszi, de pár percet kibírnak.

Teljesen tévúton jársz. ilyen biztosan még csak nem is ígér egyetlen HA cluster sem.

 

És akkor a "VM-ben tűzfal" ötletről még meg is feletkeztünk - mert ahogy kivettem nem VM-eket akarsz tűzfalazni, hanem fizikai környezetet...

zrubi.hu

A témához ezzel már csak elég lazán kapcsolódva: szerintem a pfSense HA megoldása pont ezt tudja: a pf stat-eket is szinkronban tartja, és a virtuális IP másik host-ra kerülésekor tényleg nem szakadnak meg a felépített kapcsolatok. Ha meg a pfSense tudja, akkor a drága, fizetős tűzfal megoldások is tudhatják (merthogy sokuk valójában OpenBSD pf-re épül a mai napig, ahol ez kb. alap tudás).

Ez pontosan így van! Nem is igazán hiszem, hogy ezt infrastruktúra szinten értelmes összegből meg lehet valósítani (ha egyáltalán bármennyiért meg lehet olyan módon).

Gondolom a vezetés bele van szeretve valami neves tűzfalba, amiről azt hiszik, jobban véd, mint bármi más tűzfal, úgyhogy annak a cseréje az elvárt cél elérése miatt nem járható út. Legalább is nekem ilyen tapasztalatom van. De ide is illik az az autós mondás, hogy ha majmot akartak, akkor banánra is teljen utána. Ha ezzel a tűzfallal kell HA megoldás, akkor ki kell fizetni. Ha nincs pénz, de kell HA, akkor más megoldás után kell nézni.

De gyanítom itt arról van szó, hogy a tűzfal ki van fizetve, a projektre több pénzt nem ad a cég, és minden szívás az üzemeltetőre csapódik, aki saját magát mentendő próbál csinálni valamit, hogy ne kelljen futnia, mikor magába fordul a szuper fizetős rendszer, vagy az alá tett (az elvárásokhoz mérten) nem eléggé megbízható hardver.

Itt azért kicsit ellentmondásba keveredett az egész probléma, mert ha 7x24-es termelésről van szó, ami ettől az eszköztől erősen függ, és létezik belőle gyári, megbízható, HA megoldás, akkor miért kell fillérekből összeszögelni valami mást ami vagy jó, vagy nem? Ha termel, akkor meg kell alá venni. Ha meg annyit nem termel, hogy kiteljen a HA gyári verzió, akkor a termelés kieséssel sem lehet olyan óriási a veszteség...
Azt már csak félve kérdem meg, hogy ha 7x24 üzemben megy a termelés, akkor ugye van mind a három műszakra IT-s kolléga alkalmazva, és nem egyetlen embernek kell rohanni 365/24-ben, ha baj van?

Van egy ügyfelünk (kis helyi cég, nem multi vagy ilyesmi), akinek évente 1x-2x elmúlt egyik-másik boltjában az internet (jellemzően nem is egész nyitvatartásra, csak pár órára), és ezzel a VPN is a központban futó számlázó/raktárkezelő felé. Elkezdte találgatni, hogy ez tűrhetetlen, ha kiesik 1-2 napnyi bevétel az nagyon nagyon nagy baj, csináljunk redundáns kapcsolatot, "mindig" működő VPN kapcsolattal. Nem lehet ilyen kiesés többet.

Oké, szépen leírtam, hogyakkor: a központba kell két internet, eltérő szolgáltatótól, eltérő nyomvonalon behozva (mertugye ott pont ugyan úgy elmúlhat a net, mint a távoli helyen), kell egy jobb router, amin stabilan meg lehet csinálni a dual WAN failover működést. Ezután kell a távoli boltokba is ugyan így két internet mindenhol, eltérő nyomvonalon, ugyan úgy komolyabb router-be dugva. Meg célszerűen azonos router, és plusz egy tartalékba, ha elromlik valamelyik (olyanba bele se mentem náluk, hogy rendundáns router felállás, mert a dupla net is ágyúval verébre lesz, előre éreztem...). Plusz az egész konfigurálási díja, plusz egy kicsit több havi díj az üzemeltetésre, mert nagyobb lesz kapásból a felelősség is a "nagy rendelkezésre állású" rendszeren.

Ez ugye nagyon egyszerű berendezésekkel, olcsó plusz internetekkel is olyan 100 ezres egyszeri beruházás 2-3 helyszínig és évi plusz 100-150 ezernyi plusz költség a plusz internet kapcsolatok miatt. Mindez szembe állítva azzal, hogy napi 30-60 eFt nyereségtől (mert ugye nem az számít, mennyi a forgalom, hanem az, abból mennyi marad zsebben) esnek el egy-egy bolt egy-egy egész napos kiesése során. Ergo semennyire sem éri meg egy Forintot is költeni erre a fejlesztésre, meg legjobb esetben is csak nullára jön ki, rosszabb esetben meg masszívan minuszos lesz.

Ez itt persze kis összegekről szóló egyszerű eset, de ugyan ez igaz bármekkora nagyságrendre.

Tizensok évvel ezelőtt hasonló eesetre simán oda lett rakva midnenhova egy 3G-s mobilstick, és az volt a backup vonal, amivel annyi volt a korlátozás, hogy akokr csak egy pécéről lehetett dolgozni (a 3G bőven elég volt, mert nem nagy adatmennyiségről volt szó, csak arról, hogy az távoli végpontoknak legyen tartalék kapcsolatuk, és az adatcsere akkor is működjön valamilyen módon)

Na igen. De ez egy MS SQL-t használó app, "nem kifejezetten" lassú hálózatra tervezett adatforgalommal. Meg a mobil stick ugyan úgy kell N darab és abba előfizetés a mobilnethez szintén nem ajándék, havi több ezer Ft per helyszín. Szóval legvékonyabban is 100 ezres nagyságrend az első évre vetítve a hardver, és akkor hajlandónak kell lennie a géppel dolgozónak mindenhol megtanulni, hogyan álljon át manuálisan a mobilnetre.

Igen, ez lehet(ne), de hosszútávon mégis kifizetődőbb lehet. Ugyanis a terhelés növekedésével a VM majd kap némi RAM-ot és CPU-t + licensz bővítést és minden mehet ugyanazon az infrastruktúrán, míg HW esetén "kidobós". Most még beleférünk a "kisebb" kapacitású VM-be, de várható, hogy 1-1,5 év után már nem... tehát hosszab távra tervezek.

hany ilyen projektet lattam mar :))))))))))) bocs, de hangosan felrohogtem amikor olvastam a kommented.

milyen KKV az akinek magas rendelkezesreallasu tuzfal kell mert hudenagyonfontos, takolt szar fos clusteren, ahol majd meg noni is fog a kapacitas?

ne nevettessuk egymast kerem, valoszinuleg a tuzfal appliance helyett egy raspberry pi is eleg lenne.

Szívesen.

Hát ha csak tervezett leállás miatt kell a 2 node meg a live migration, akkor meg lehet úszni közös storage nélkül, lehet kapni bagoért mellanox connectx-2/3 kártyákat használtan öszekötöd a két gépet direktbe egy dac kábelel 10G mellet meg már egész gyorsan költözik a vm mindenstöl a másikra. Nyilván egy network storage jobb megoldás viszont ez töredéke annyiba kerül.

Arra érdemes még figyelni ha ezt az utat választod hogy a connect-x2 csak esxi6.7 ig tamogatott az intelek elvileg mennek 7.x allat is viszont drágábbak azthiszem talán x520ad vagy ilyesmi volt a tipus amivel próbáltam az jó volt, iletve az asus lapok nem mindig ismerik fel ezeket a kártyákat, gigabyte-bol eddig 4-5 különböző lappal próbáltam azok müködtek.

Lehet, hogy neves csak nem tudom miért, semelyik gyárto termékeivel nem szivtam mêg anyit mint az asusal. Sw/fw és rma-s pormblémák miatt egyaránt, pedig soha nem az alsó kategoriás cucot vetem tőlük. Részemröl én többet nem veszek semmit ami asus.

Ha szeretnéd eljöhetsz megnézni, csak a kedvedért szétszedek 2 gépet, ittvan melletem a konkrét példa dual port 10G mellanox halokártya asus prime x570 pro ba nem megye egy x570 aorus masterbe meg csontnélkül mindketö proxmoxon tesztelve asusnál nem is látszik a pcie eszközök között, ha ugyneböl a típusból egyportos verziót rakom ugyanabba a slotba az meg megy.

De amugy igen, tudom amit te nem tudsz az nem léterzik.

Kommersz SSD-k nem jók ilyen feladatra, utána meg majd "lassú pedig SSD van benne" - VM alatt még a HDD teljesítményét se éri el.

Helyette ( kicsit drágább mint a "kommersz" SSD ):
-SAMSUNG PM883 (SATA port)

https://www.sebastien-han.fr/blog/2014/10/10/ceph-how-to-test-if-your-s…

 VM alatt még a HDD teljesítményét se éri el.

Ez nincs így. 4K random szinkron write általában  HDD-nél  úgy 0.3 MB/sec. Ennél azért egy samsung pro 2-3M/sec sebesége is 10X. 

Az más kérdés, hogy alig drágábban van 30-60 MB/sec-es ssd,  ami már 100X.

Samsung pro asztalinak jó a marketingje, szokták is ajánlani , pedig ennyit tud ebben a műfajban.

Optane ssd meg még egy nagyságrenddel többet, vagyis ssd és ssd között 2 nagységrend eltérés lehet. HDD-nél nem volt ilyen. (Mostmár van, SMR hdd-k)

De ez csak a journal ssd-nél érdekes. A belinkelt teszt is erről szól.  Ahogy nő a blokkméret úgy csökkennek a különbségek a sebességben. És egy nem journalnak használt ssd terhelése nem  azonnali 4k random írás 7/24-ben . 

https://blog.claryel.hu

Ha VMotion az indíttatás, akkor osztott tároló feltételezhető, így az ESXi-be nem is kell igazán SSD, elég egy pendrive is.

Ebben a témában borzasztóan sok minden keveredik, infrastruktúra HA vs tűzfal HA, sufni vs enterprise, vSphere ismeretek hiánya stb.

( mac1125 | 2021. 01. 04., h – 13:41 )

Röviden: Nem ezeket a robotokat keresed.

Hosszabban:
Van rá esély hogy összetákold a dolgot. Vannak lehetőség saját telepítő iso készítésére ahol összeválogatod kétes és/vagy nem kétes forrásokból hogy milyen dolgokat akarsz beletenni. Supportált nem lesz, de az a hajó már az elején elment.
HA-hoz kell a vCenter, ami licencdíjas, de mivel az ESXI nem lesz alatta supportált, tehát gondolom "nem hivatalos" lesz ez is.

A legkisebb vCenter 2VCPU 10GB-t igényel, de akkor nagyon nagyon nagyon sok kávét fogsz inni mire az rendesen elindul. Ha lehal az egyik hostod, akkor a vCenternek el kell indulnia a másik hoston, dupla erőforrás allokációval számolj.

Kell közös storage, ami akár NFS is lehet, de erősen ajánlott hogy kívülről jöjjön. A tiny vCentered elkér 450GB-t(persze lehet veszélyesen élni Thin provisioninggel, amikor behazudod hogy ott van, csak ki ne használja azt a helyet, de akkor megint egy nagy lyukat adsz az egésznek.

A hálózati része triviális, ugyanazokat a dolgokat kel elérd mindkét oldalon, ezt nem részletezem.

Szóval összeraknál egy nem supportált rendszert, ami eleszik egy csomó erőforrást azért hogy egy iciri piciri VM két helyen is tudjon indulni?
Ha játszani akarsz akkor hajrá, arra tökéletes, annyi önszívatás van a dologban amiből rengeteget lehet tanulni. Összerakni össze lehet, de nem érdemes.
Ha mindenképp VMwarezni szeretnél, vegyél régebben supportált használt gépet, tegyél fel rá egy régebbi verziót és játssz, de a kiemelt dolgok miatt ez soha nem mehet élesbe.

De közelítsük meg picit az igazi problémát is. Ha jól értem van egy alkalmazásod amit mindenképp futtatni szeretnél. Ilyen piciben lehet hogy inkább szoftveresen kellene leszimulálni egy HA-t. Biztosan vannak rá kidolgozott megoldások, pl. két kis daemon beszélget egymással két gépen és ha a haver nem válaszol akkor elindítja a másik is az alkalmazást. Amint a másik visszajön eldöntik mi legyen.

( zz7 | 2021. 01. 04., h – 15:24 )

Inkább Proxmox felé nézelődnék ilyen célra. Debian, újabb kernel, általában mindenféle kommersz cuccon is elmegy.
Viszont annak is elvileg 3 node kellene a Ceph clusterhez.

( evilroy | 2021. 01. 04., h – 15:48 )

Proxmox-ot ajánlom én is, esxi 6.5-öt próbáltam kommersz gépre felrakni a hetekben, csak a szívás volt vele. 

( ggallo | 2021. 01. 04., h – 16:18 )

Szerkesztve: 2021. 01. 04., h – 16:31

Az a baj, hogy az olyan cluster-en, ami köszönőviszonyban sincs az ajánlásokkal, a rendelkezésre állás inkább kevesebb lesz, mint több. A két gép osztott tároló nélkül meg sose lesz cluster.
Hiába "oldják meg" sokan két géppel, hogy működjön (pontosabba elinduljon és fusson), valójában nem véd semmi ellen, és irtó könnyű split-brain-be futni vele. Legrosszabb esetben is kell egy harmadik gép a döntés miatt, akkor is, ha az történetesen egy RPi, és VM-et futtatni nem tud.

Ezen felül osztott tároló nélkül nincs HA sem, és értelmes live migration sem.
Hiába tud a Proxmox (meg más is) local tárolók között is migrálni, ha a gigabites hálózaton 35 perc, mire az 50 GB-os VM átmásolódik, márpedig osztoitt tároló nélkül át kell másolni minden mozgatásnál... Ezen felül ha nincs osztott tároló, akkor egy váratlan host leállás után ugyan honnan lesz meg a VM, ami a döglött host-on futott local tárolóról?

Két kommersz géppel akkor van a legnagyobb esélyed, ha teszel rájuk Proxmox-ot, alá DRBD-t osztott tárolónak, és melléjük egy RPi-t (vagy más, Linux-képes olcsó-kicsi gépet) QDisk-nek a rendes cluster működéshez. És ha ez megvan, akkor se várt tőle túl sokat. Annyit érhetsz el, hogy a live migration aránylag gyorsan lefut, és egyik igazi host hirtelen halála esetén a HA manager el tudja indítani a VM-et a másik host-on.

De tapasztalatból mondom, hogy ennek a tesztelése után élesbe be ne állítsd! Meg fog szivatni. Ha élesben kell nagy(obb) rendelkezésre állás olcsón, akkor 3 db használt (egyforma) szerver és két (használt) minőségi switch fog kelleni minimum. Meg két UPS a redundáns tápok elé.

Valamint azért Proxmox-ozok én is itt sorra, mert VMware vonalon ezek a szolgáltatások mind csak a fizetős verziókban érhetők el, azon felül, hogy háklis a hardverre. De azt azért tudd, hogy a VMware-nek van egy programja, amiben évi 200 USD tagsági díjért magán/teszt célokra bármilyen VMware szoftvert használhatsz teljes tudással (lehet igazi live migration-os, vSAN-os, vCenter-es VMware virtualizációd, idő- és hardverkorlát nélkül).
Viszont ha erre be is fizetsz, élesben működő rendszert akkor sem építhetsz az így szerzett licenszekre.

( Executioner1337 | 2021. 01. 04., h – 16:22 )

A Hyper-V -t nézted már? Az kevésbé allergiás a desktop gépekre.

Igen, de a Hyper-V Manager desktop és a Hyper-V Core szerver kózötti authentikáció egy óriási szívas, ha nem AD tag mindkét gép (pl. otthoni "workgroup" üzemmód), ami ráadásul minden második Win10 desktop frissítéssel elmúlik és lehet küzdeni, hogy ismét lássa a Manager a szervert.

A HP ML310e Gen8v2 szerveremen az volt fent (Hyper-V Core 2012R2) új korától, és alig vártam, hogy lecseréljem a szervert, és megszabaduljak a Hyper-V ilyen módú használatától.

AD környezetben, gyári leiratoknszerinti felállásban biztosan más (vagy nem, igen sokal köpködik), de otthonra, kísérletezni alapjában véve nem élmény meg tanulás, hanem nettó idegeskedés.

( bognarattila | 2021. 01. 04., h – 17:47 )

Sokan sok mindent leírtak már, így azt nem ismételném meg.

Viszont a "most tekintsünk el attól, hogy a 3 node lenne az igazi" alapján először nem ártana megismerkedni a működéssel, mert két ESXi is tud failovert, három leginkább azért szerencsésebb, mert gazdaságosabb (tartalék erőforrás csak 30%, kettő esetén 50%). Viszont kell közös tároló, nyilván redundáns. És persze redundáns hálózat.

Ismerkedéshez nem sok minden kell:
- kompatibilis CPU (igen, újabb ESXi nem megy fel tetszőlegesen régi CPU-ra)
- kompatibilis hálókártya
- USB pendrive, amire telepíted és amiről indul
- NFS tároló egy tetszőleges gépre (akár lehet az egyik ESXi is, ez esetben kompatibilis RAID vezérlő is kell)
- vcenter: akár egyik ESXi-n, akár máshol.
- teszt licenccel el lehet játszadozni egy darabig, talán 60 nap

( STP | 2021. 01. 06., sze – 01:50 )

Csak az elejébe olvastam bele, így ha N+1 info lesz, akkor bocs.

Egyrészt szervert üzemeltetni nem ECC memóriával nagy fokú „bátorságra” utal.

Másrészt azt írtad a process ID-nak meg kell maradni migrálásnál. Majd azt, hogy igazából nem is LiveMigration lenne, csak failover. Utóbbi esetben nincs gondod a process ID-val?

Harmadrészt shared storage nélkül lehet, csak nem érdemes ilyen környezetet összepattintani.

Negyedrészt bármilyen (Xen-t már nem ismerem) virtualizációs rendszer alá normális vas kell. Még a Proxmox is azt mondja, hogy tegyél alá BBU-s HW raid-et.

Akkor "bátor" vagyok. :-)  Kommersz gépen Xen, azon 3db VM, évek óta teszi a dolgát, talán innen a "bátorság".

A koncepció az volt, hogy esetleg egy új szerver árából 2db kommersz gép clusterbe fogva. Így lenne "redundáns táp", "redundáns minden" és még hiba esetén át is áll a másik vasra - pár perc kiesés belefér. 

Dell szervert is üzemeltetek és remekül mennek, de még azok is képesek megállni néha, talán innen ez az "agymenés".

Köszönöm az észrevételeket!

 

Negyedrészt bármilyen (Xen-t már nem ismerem) virtualizációs rendszer alá normális vas kell. Még a Proxmox is azt mondja, hogy tegyél alá BBU-s HW raid-et.

Meg azt is mondja proxmox, hogy zfs-hez nehogy tegyél BBU-s HW-raid-et. CEPH-hez meg minek. Ahogy meg nőnek a nodok számai, egyre jobban használhatsz "hulladék" gépeket, eldobhatóak .

https://blog.claryel.hu

No nem pontosan.

A helyzet az, hogy teljes felesleges (lenne) a HW RAID vezérlő, hiszen maga a 'filerendszer' elvégzi azt a műveletet. Azonban bármilyen I/O műveletre jótékony hatással van egy I/O optimalizált cache háttér. Azt meg illik BBU-val védeni. Anno a Sun nyomatékosan ajánlotta a BBU-t ZFS használathoz. Ez a javaslat azóta sem változott, max már nem a Sun mondja. Viszont mutass olyan SATA/SAS/NVMe vezérlőt, amin van cache és BBU, de nem RAID vezérlő. Nincs túl sok. És hát azt a RAID vezérlőt lehet úgy konfigurálni, hogy ne akarjon RAID-elni... ;)

Két node-ra Ceph-et? (Mert ugye az volt az alapvetés, hogy két gépet szeretne a kolléga...)

ez a szal a topicon belul nem errol szolt, de mindegy:)

a fo topicon meg csak nevetnem kell, a szarbol varat tipikus esete latszik korvonalazodni. voltam mar ilyen helyzetben, ismerem ezt a fajta tulajdonosi hozzallast, hogy "jozsi, oldd meg okosba! mennyi???? annak a felebol jo lenne, oke?"... szinte sosincs jo vege.

Nekem nem kell mondani... Nem véletlenül kerülöm a KKV szektort, meg a "még úgy maradt, hogy részben zsebbe fizetünk" cégeket.  Ilyenkor egyébként érdemes szembesíteni az illetékest azzal, hogy az olcsóbb megoldás esetén ha megáll, akkor x óra/nap kieséssel kell számolni, és hogy ezt a kockázatot bevállalja-e, vagy sem? És ami fontos, alternatív megoldást javasolni a kockázatok csökkentésére, illetve a költséghatékonyabb megoldásnál a kiesési idő minimalizálására.

( kisg v | 2021. 01. 06., sze – 14:15 )

Nem tudom milyen ez a csodaszoftver amit futtatni akarsz, de ha online lehet visszavonni a licencet és újra regisztrálni, akkor jobban jársz a Proxmoxszal. Ha jól válogatod össze az alkatrészeket, akkor jó eséllyel 2-3 évig nem lesz rá szükség, a rendelkezésre állást nem ez fogja akadályozni.

Egyébként fejlesztői clustert én csináltam 3 db ivy-bridge E3-as "dzsunkaszerverből" + sima Samsung 850 PRO (desktop) SSD + Proxmox + Ceph (igen, ugyanazokon a gépeken). Így volt 3x-os redundáns 1TB Ceph tárhely, abból jöttek a VM-ek. Nem volt szupergyors, csak sima gigás net volt a szerverek között, de annyira kicsi volt a terhelés, hogy nem lőttem össze a 10G-s hálót, pedig már a HW össze is volt kötve. És Proxmoxban minden pöccre működött. Tény, hogy nem volt szétterhelve, tehát a desktop SSD-ket se "ette meg" a Ceph, de évekig ment gond nélkül.

Ezzel azt akarom mondani, hogy lehet vízzel főzni ha nincs elég lóvé, de látni kell a korlátokat (és ha nem te vagy a főnök, akkor írásban kommunikálni a főnökség felé).

Én pl. ECC RAM-ból nem engedek szerveren. A régi E3-as sorozatok Intel Server Board alaplappal nagyon jól hozták a majdnem-desktop árszínvonalat a majdnem-szerver megbízhatósággal / menedzselhetőséggel. Mostanában nem kellett új ilyen dzsunkaszervert építenem, de ha kéne, akkor a mostani Intel E3-asok és az AMD Ryzenek valamilyen ASRock Rack (vagy hasonló) jellegű alaplappal biztos fent lennének a listámon.

Ha a proxmox alternatíva, akkor egy lehetséges alternatívát már az első hozzászóló leírta. Angliából 150-200 fontért kaphatsz valamilyen olcsóbb v2 xeon szervert, 10Gb-es hálókártyával, de egy Mellanox MCX311A-XCA kártya is 10-15 ezerért beszerezhető. De kicsit drágábban itthon is van hasonló, ebból kell akkor 3.

https://www.bargainhardware.co.uk/quanta-stratos-s210-x12rs-v2-1u-4x-3-5-lff

Ez persze sok idő , aztán a  tesztelés, nyilván a "meghoztuk a szervert, tegyék a polcra és szóljanak ha bekapcsolták" -nál jóval több energiádba kerül. 

https://blog.claryel.hu