XEN vagy KVM esetleg VMWare?

Red Hat, Fedora, CentOS

Egy ideje érdeklődöm a téma iránt.
Most jutottam oda, hogy van egy tesztelésre alkalmas gépem. (E8300 CPU, 8GB 1333 MHz DDR3, 2x gigabit Ethernet)
Gondoltam a CentOS 6.x gazdagépen XEN virtualizációval kezdem a tanulást.
Meglepődve vettem észre, hogy a RedHat az 5.x-ben még alapértelmezett tárolókból támogatták a XEN-t, de a 6-x-ben úgy látom már a KVM-et preferálják.
Tudja valaki, hogy ennek mi lehet az oka?
A KVM esetleg az utóbbi időkben jobb lett a XEN-nél, vagy inkább üzletpolitikai oka lehet a váltásnak?

Szerver virtualizációt szeretnék csinálni főleg gyakorlás és tapasztalatszerzés céljából.
Elsősorban a RedHat-et jobban mondva a CentOS-t vagy SL-t azaz Scientific Linuxot szeretnék használni gazda rendszerként. Esetleg az Ubuntu jöhet még szóba, ha valami nyomós érv merülne fel mellette.
Szóval kinek mivel van tapasztalata, illetve mit javasol, merre induljak? XEN, KVM esetleg VMWare?

  • 27912 megtekintés

( asm v | 2012. 07. 01., v – 11:30 )

VMware-rel ne kezdj, mert akkor nehez lesz a valtas :)

Egyszer, de azert a migracio se egy leanyalom. Linux eseteben nincs gond, minden nagyobb platform jol tamogatott (bar egy VMware - OpenVZ migracioba valoszinleg nem kezdenek bele), de Windows eseten neki lehet szaladni a pofonfanak.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Persze, viszont ellenben a többivel, ott nem muszáj :-)

A vmware sem a szívem csücske, főként költség okokból nézegettük, hogy le lehetne-e cserélni, megnyomkodtam a xent meg az rhevt is. Hát, a xen a vmwarehez képest überfapad, alap dolgok fele nincs kint a guin (ami a vmwareénél is idegesítőbb), az egész általában tákolmánynak tűnik (az összes plusz funkciót futtató cucc más alap osen, centos 5, 6, és annak alfajai, debina, bsd...) az rhevnek meg annyira béta szaga volt, hogy nagyon, baszottul csuklott...

( STP | 2012. 07. 01., v – 11:36 )

"Meglepődve vettem észre, hogy a RedHat az 5.x-ben még alapértelmezett tárolókból támogatták a XEN-t, de a 6-x-ben úgy látom már a KVM-et preferálják.
Tudja valaki, hogy ennek mi lehet az oka?"
Hacsak az nem, hogy a KVM-et fejlesztő Qumranet-et 2008-ban kilóra megvették a piroskalaposok.

Köszi. Ha ebből indulok ki, akkor talán látnak benne fantáziát és fejlesztik is, ha a XEN helyett a KVM-et használják és nem azért vették, hogy kidobják. Szóval ez ebből a szempontból jó hír!
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Azert volt ennek a dontesnek technikai oka is. Erdemes kicsit nezegetni a xen architekturajat, kulonosen a perfieria-virtualizacio megoldasat. Aztan a forraskodba benezve is talalni fura dolgokat (pl monolitikus, 1 .c fajlban megirt x86 emulatort, ami nem 100%-ban implementalja a x86 utasitaskeszletet, es sokkal lassabb a qemu-nal, aztan van boven linux kernelbol reges-regen majdnem 1:1 atmasolt kod a xen kernelben, rengeteg funkcio duplikacio, stb). Nem alaptalanul nem kerult be a dom0 support a mainline linux forrasba, kb mostanaban jutottak a kod letisztazasban oda, hogy be lehessen olvasztani. RedHat-nek lenyegesen tobb munka lett volna fenntartani dom-0 tamogatast, mint KVM-re atallni.

Mas kerdes, hogy a KVM feature-ok tekinteteben meg mindig nem erte utol a Xen-t.
---
Internet Memetikai Tanszék

Teljesen mas teszta a ketto. A Xen PV modban a _CPU-t_ paravirtualizalja, es mellesleg (konfiguraciotol fuggoen) a periferiakat is. A KVM viszont csak hardveres virtualizacios modban kezel CPU-t (Xen-nel ennek megfeleloje a HVM mode), a periferiaknal valoban itt is van lehetoseg paravirtualizaciora.

A periferiak paravirtualizacioja csak IO teljesitmenyben jelent pluszt. Hogy jelenleg a Xen-es virtio hogy all a KVM-es virtiohoz kepest, azt nem tudom. En tobbnyire regi valtozatokat hasznalok mindkettobol (KVM 2.6.32, Xen 3.x), mert az adott platformon ezek a supportalt verziok. Igazabol nem tudom eldonteni, hogy melyiket szidjam jobban, mindketto eleg siralmas.
---
Internet Memetikai Tanszék

Ez igaz, hogy kvm eseteben kell a proci hw virtualizacio tamogatas, de egy ideje mar lenyegeben mindegyik ertelmesebb processzor tamogatja ezt (beleertve a topicban szereplot is), abban az esetben pedig nem erzodik semmi lenyegi kulonbseg xen vagy kvm kozott. Sok esetben ezek utan mar inkabb I/O a korlat nem cpu, akkor pedig jol tud jonni a virtio tamogatas.

--
Don't Panic if you see me laughing,
that's not a bug, just a feature.

Egy ilyen összehasonlítást találtam. Ez alapján nem lehet általánosan kijelenteni, hogy egyik vagy másik magasan verné a többit.
Vmware vs Virtualbox vs KVM vs XEN: virtual machines performance comparison
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Ilyen bencheket én is látok, viszont saját méréseim, nem támasztották alá. Igaz pár alap egyszerű teszteket szoktam csinálni pl.: kernel forgatás, dd, sakkmotor a CPU teszthez stb.

A másik, a managelhetőség. Ebben a vmware egyelőre verhetetlen. Persze annyi pénzért amibe kerül még szép. Viszont az ESXi tudhatná a live migrációt, ahogy pl a citrix is szállítja az ingyenes verzióiban.

A xen a citrix révén egy viszonylag normális management eszközt ad, persze van lemaradás a vmware-hez képest, de árban meszebb van tőle. Meg van 1-2 opensource projekt ami talán 1x beérik, openxenmanager, XVP.

A kvm-hez ugye van a RedHat nak o-virt-je, ami szerintem még nem az igazi, a másik meg a proxmox.

Szóval mint ahogy az lenni szokott próbáld ki mind, aztán amelyik tetszik azt használd :>

Fedora 16, Thinkpad x61s

Egy Citrix XEN szervert már feltettem és a Windowsos admin felületről telepítettem rá néhány gépet.
A következő a CentOS 6.2-n futó KVM lesz, amennyire lehet egyelőre a "gyárilag" szállított környezettel és eszközökkel.
Mivel a Citrix XEN Server kérdés nélkül kiosztotta magának a teljes 500GB-os HDD-t, így a CentOS-t valószínűleg egy másik HDD-re telepítem, csak azt még fel kell szabadítanom. Így könnyebb lesz váltogatni.

Amúgy úgy látom a KVM is tud live migrációt. :-)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Ez tervben van!
Jelenleg egy otthoni gépen gyakorlok, tanulok. Gyűjtöm a tapasztalatot.
Ha úgy látom, hogy már "én üzembiztos vagyok", akkor a munkahelyen szeretném ezt kamatoztatni. :-)
Sőt még a live migrációt is ki tudom otthon próbálni, mert arra az időre az asztali gépemet is tudom hostként használni és van egy NAS-om is ami tud nfs-t. Lassú lesz, de tesztre elég.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

"Nem alaptalanul nem kerult be a dom0 support a mainline linux forrasba, kb mostanaban jutottak a kod letisztazasban oda, hogy be lehessen olvasztani."

Itt milyen dom0 supportra gondolsz? Mert ami xent én használok, az gentoo-sources, de ez a vanilla kernelen kívül nem tartalmaz xenhez patchet, és minden támogatás megvan, a xen-tools csomag kell csak telepíteni, a domu nál szintén ez a helyzet. Az x86 utasításost se teljesen értem, mert a xen újabban upstream qemu t használ, a paravirtualizált domu-hoz meg ugye nem kell x86 emulátor. Bevallom, én ilyen szinten nem néztem a forrását, de így "userként" nem hiszem, hogy pontos, amiket írtál.

szerk: nem néztem, hogy ez a topic nagyon régi, és a hozzászólás, amire reagáltam szintén. A qemu upstreames rész jó eséllyel azóta vált valósággá, lehet, hogy a dom0 support is. Mindenesetre akkor se árt, ha le van írva. :)

( uid_228 | 2012. 07. 01., v – 15:50 )

Üzletpolitika. A Xenre a Citrix építi a saját, kereskedelmi virtualizációs termékét, a XenServert. A Redhat ezt nem hagyhatta. :))

Arról sajnos nem tudok nyilatkozni, hogy a 6.0-ás XenServer (ami a 4-es opensource Xenre épül) és az újabb KVM-ek feature-ben és teljesítményben hogyan aránylanak egymáshoz, mert KVM-ből csak tavaly láttam tanfolyamon valami régit, XenServerből pedig a munkahelyemen 5.5u2-őt használunk még. Viszont ha azt a két verziót veszem, akkor a XenServer lemossa a RHEV-et, ez utóbbinak a menedzsmentje egy rossz vicc volt. De hangsúlyozom: régi rendszer, az még a full Windowsra és MS SQL-re (Redhatről beszélünk!) épülő változat. Ígérte akkor a Redhat, hogy átírja a menedzsmentszervert JBossra és az adatbázisnak is jó lesz a PostgreSQL/EDB, de hogy ezekkel hol tartanak, nem tudom.

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Ev elejen (talan februar-marcius) adtak ki az rhev3.0-t ami mar mellozi a windows hasznalatot, ill. ovirt neven elsodlegesen fedora alapokon van kozossegi (amolyan teszteloi) valtozata is.
Teny, hogy van meg mit behozniuk, de annyira azert nem allnak rosszul szerintem, en tobb potencialt latok a kvm-ben mint a xen-ben.
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.

( arpi_esp v | 2012. 07. 01., v – 17:30 )

xen: vagy hasznald komplettul az o image-ikkel, vagy szopni fogsz. ossze vissza patchelt kernel kell hozza, a patch kulon nem is elerheto csak git-bol valami folyton rc/beta kernel patchelve ami altalaban le se fordul.
a hypervisort csak grub-al lehet betolteni, lilo kiakad tole.

kvm: nekem sokkal szimpibb, hogy vanila kernelben benen van minden ami kell hozza, nincs kulon hypervisor csak host es guest kernelek. hatranya, hogy macerasabb a vm-ek kezelese (en effektive screen-bol futattom a sok qemu-kat) es 32 bites guest kernellel 1-2 het utan megfagytak mindenfele hibauzenet nelkul. 64 biten eddig stabil.

vmware: jo, stabil, de winnyoz kell hozza :(

A'rpi

screen-ben nyitok tobb "taszkot" es mindegyiken eleresztek egy qemu parancsot a megfelelo parameterekkel, amik elindulas utan az adott vm konzoljat adjak.
ha hatterben futnanak a qemu-k akkor nem fernek hozza a vm-ek konzoljahoz.

eleg gany ez igy, foleg a xen-hez kepest, de vegulis mukodik.

A'rpi

virsh connect-el lehet csatlakozni vm soros portjahoz, csak guest-ben be kell allitanod, hogy kuldje ki oda a jelet, mint xen eseteben is, csak ott ezt a beallitast megteszi helyetted a xen-install.
Annyira nagy eroforras nem kell a virt-manaeger-hez sem, ssh-n X forward-al siman at lehet kuldeni, nem erzodik kulonosebben sebessegbeli gond nalam.

--
Don't Panic if you see me laughing,
that's not a bug, just a feature.

Ha csak grafikus konzol kell a vm-hez, akkor egyebkent X nelkul is lehet. Csak be kell allitani az adott vm-hez tartozo libvirt.xml-ben, hogy a grafikus konzol VNC-re van iranyitva, es inditas utan mar figyel is az 5900-as porton. Nem kell X es egyebek. Mar a BIOS bootolast is latod rajta/be tudsz avatkozni ha kell. Annak mondjuk nem neztem utana, hogy a vnc servert konkretan libvirt rakja ra, vagy a qemu-kvm nativan tudja es libvirt csak a konfiguraciot tovabbitja.
---
Internet Memetikai Tanszék

Azert a libvirtnek (virsh) is vannak tarka bogarai. A vm konzol kezeles eleg esetleges, a nyero host-guest konfig kombinaciot neha eleg nehez eltalalni. Sulyosbodik helyzet, ha fajlba is kell logolni a VM console kimenetet. Olyat nekem meg nem sikerult osszehoznom, hogy egyszerre mukodjon a ketto. Xen-nel tipikusan az interaktiv szoveges konzol szokott menni, KVM-nel meg a fajba logolas, ilyenkor csak grafikus konzol van VNC-vel.

A masik problema, hogy ha valami hiba vagy barmi esemeny tortenik a vm futasaban (vCPU lockup, boot nem sikerult, kernel crash, vagy csak sima guestbol kezdemenyezett powerdown stb.), akkor a libvirt ugy reagal, hogy eltunik a vm a listabol, innentol semmit nem lehet rola lekerdezni. Utana meg probald meg API-bol kideriteni, hogy a vm-et szabalyosan leallitotta valaki, vagy crashelt. (Cloud controllert erre nehez alapozni)
---
Internet Memetikai Tanszék

A libvirt (virsh) console eleres ugyanazt csinalja mint a xen, csak xen eseteben installer beallitja ezt neked a guest rendszerben, hogy cli kimenetet kikuldje soros portra, amire te host rendszerbol csatlakozni tudsz.

Az nem lehet hogy csak azert tunik el a listabol mert virsh list alapbol csak a futo guest-eket irja ki, 'virsh list --all' -al meg lehet nezni az osszeset, amugy meg logol libvirt beallitasoktol fuggoen amit host rendszeren meg tudsz nezni.

Teny hogy ez (virsh/virt-manager) onmagaban nem cloud vagy komolyabb virtualicios megoldasnak jo, csak 1-1 host gepet kezelni, de nem is arra van tervezve.

--
Don't Panic if you see me laughing,
that's not a bug, just a feature.

csak xen eseteben installer beallitja ezt neked a guest rendszerben, hogy cli kimenetet kikuldje soros portra
Igen, ezek termeszetesen be vannak allitva. Lassan mar fejbol fujom a vonatkozo kernel parametereket.

nem lehet hogy csak azert tunik el a listabol mert virsh list alapbol csak a futo guest-eket irja ki, 'virsh list --all' -al meg lehet nezni az osszeset
Nem, sajnos eltunik onnan is. Bar jo kerdes, hogy miert...

En konkretan Eucalyptus-t hasznalok (hasznalok... ez mondjuk eros tulzas, inkabb debugolom, mint hasznalnam) cloud controllernek, tehat a libvirt konfigot nem en allitom elo, legfeljebb megfelelo hookokkal bele tudok patchelni libvirt.xml-be. Viszont sajnos mar tobbedik Eucalyptus bugot sikerult visszavezetnem libvirt hianyossagra.
---
Internet Memetikai Tanszék

"eltunik a vm a listabol"

virsh list --all
virsh list --inactive

Mondjuk ez a leallitott gepeket is listazza. A masik lehetoseg, hogy KVM-nel inditas utan megszerzed a gep PID-jet, es erre keresel ra. Ha valaki lelotte, akkor a PID nem el, ha elcrashelt, de meg fut, a PID el.

Xen eseteben a dolog meg egyszerubb, mert a virsh gyakorlatilag xm wrapperkent uzemel.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( Lacyc3 v | 2012. 07. 01., v – 17:30 )

Pár hónapja fut Ubuntu szerveren egy teszt kiépítés KVM-mel (3 gép: web, levelezés, adatbázis) és teljesen meg vagyok vele elégedve, minden megy szépen. Egyszerű telepítés, beállítás. Az Ubuntu Wiki részletes, ha bármi olyan feature kellene, amit nem találsz meg. Ha számít, virt-manager jó kattogtatós felületet ad az egész alá.

Csak ajánlani tudom.

( denke v | 2012. 07. 01., v – 19:28 )

Szia!

Ha komoly virtualizacios platformot akarsz, akkor vmware es pont.
olyan rugalmassagot, supportot es megbizhatosagot olyen kicsi overheaddel mint a vmware semmi mas nem fog neked adni. Nem veletlenul kerul sokszazezerbe a prog egy komolyabb serverre. Nem is beszelve a vmotionrol es a teljes datapark solutionokrol.

Ha jatszogatni akarsz, es csak arra kell, hogy otthon a fileservereden indits egy xp-t is ahol torrentezhetsz, akkor tok 8 mit hasznalsz, ha viszont profi megoldast akarsz es ezzel korrekt modon penzt is szeretnel keresni (es nem a fillerb*szo reteget akarod megcelozni) akkor vmware.

( bubor | 2012. 07. 01., v – 20:54 )

Nem a kerdesre valasz, de esetleg nem hallottal meg openvz es tarsai "operating system-level virtualization". Kozos kernellel mukodik, megis letre tudsz hozni kulonallo vmeket, amikben fontosabb dolgokat customizalhatsz (pl iptables), nincsen overhead, native disk/fs stb van. ( http://en.wikipedia.org/wiki/OpenVZ )
Megsem erdekel, akkor elnezest az offert.

( uid_6201 v | 2012. 07. 01., v – 21:25 )

Nálam a XEN és a KVM egyaránt bevált.

Web és egyéb szolgáltatói szerveren 2006. decembere óta szépen teljesít nálunk a XEN.

Aztán amikor felröppent, hogy macerás lesz a XEN kernelbeli támogatása, két új webszerver vasát már KVM-mel virtualizáltam szét. Azóta XEN és KVM egyaránt van életemben.

Tehát a KVM is 4 éve jól teljesít. Sok domain weboldalát szolgálja ki nagy megbízhatósággal.

Az alábbi tartalmú shell scriptet használom azóta is. Nem screen-elek, hanem háttérbe küldöm és ha nagyon muszáj a konzol, akkor tcp proxy és vnc. Igen ritkán kell. Bár be van készítve egy -curses opció is a shell scriptbe, kikommentezve. :)

kvm -hda /dev/WEB/negyedik \
... \
... \
-enable-kvm \
-nographic \
-daemonize \
-vnc 127.0.0.1:4

( zsolt | 2012. 07. 02., h – 00:12 )

Épp most kezdtem én is egy KVM-es szervert összerakni.
Szeretnék hozzá web-es felületet is.

ConVirt 2-t esetleg használja valaki?
Vagy valami más hasonlót tudtok ajánlani?

( freeoli v | 2012. 07. 02., h – 09:28 )

Ki kell próbálni az összeset és el kell dönteni. A hyperv nem szereti meg a linuxot, de a win srv 8 már olyan szolgáltatásokat hoz amik már impozansak. A xent csak arra osszereszelt disztribucioval javaslom, pl xenserver free a citrixtol, a kvm a leggyorsabb ami persze elhanyalgolhato pár százalék, viszont minden linuxon pengen megy.

Összességében a vmware termékeit javaslom, ha van alá vasad, nem típus hanem komponens szerint támogatva, a free esxi egy kizsirozott tal hogy megsusd a pecsenyed.

Ha nem tamogatott hardveren akarod végezni a kiszolgálást akkor kvm és a kényelmi dolgokat megoldod más rétegekben, pl sw raid, scriptek stb.

Vagy próbáld ki valamelyik előkészített disztrot kvm el, pl zentyal, amiben minden benne van ami kellhet, de ha csak virtualizalsz, az is benne és megy.

"A hyperv nem szereti meg a linuxot"

De. Tobbszor volt itt szo rola, hir is volt, hogy mind szelesebb es szelesebb koru tamogatas van a Linuxhoz. Az IC komponensek mar a Debiant is tamogatjak.

"A xent csak arra osszereszelt disztribucioval javaslom"

? Nekem openSUSE-m van, rajta Xen. Problemamentes. Ugyanez a tapasztalat Ubuntu Serverrel is. A live migrationt egy picit reszelni kell, hogy menjen is, de ez se mindig kell.

-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( dejo v | 2012. 07. 02., h – 09:39 )

Köszönöm mindenkinek aki eddig hozzászólt.
Szépen gyűlnek az infók. A szempontok és vélemények is ütköznek néha, de ez nem baj. :-)
Eddig abban erősített meg, hogy ez a három eszköz bármelyike használható és szinte az egyéni ízlés és legfeljebb a hardver támogatottság lesz a mérvadó.
Ezzel a hozzászólásommal természetesen nem akarom lezárni a topikot, csak azt szeretném kifejezni vele, hogy hasznosnak tartom az eddigieket!
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

( kisg v | 2012. 07. 02., h – 10:32 )

Ha relatíve gyorsan akarsz eredményt, akkor én alapvetően azt javaslom, hogy valamilyen virtualizációhoz kitalált appliance-t használj. Ha így döntesz, akkor néhány opció:

- Xen: Citrix XenServer, vagy annak az opensource változata az XCP (Xen Cloud Platform)
dolgoztam vele, többé kevésbé működik is, de képes csúnyán összezuhanni. RHEL / CentOS-re épül az alaprendszer. Gyárilag Windowsos management felület van hozzá + parancssoros (nagyon kényelmetlen) + webservice api.

- KVM: Proxmox (proxmox.com): Debianra épül, KVM és OpenVZ alapú virtualizációt támogat, webes felület van hozzá (console hozzáférés flashes VNC kliensen keresztül). Eddig jók vele a tapasztalatok.

- Vmware: ESXi: Megbízhatóan megy, Windowsos kliens kell a managementhez, VM konzol hozzáférés, illetve VM start / stop újabb VMWare Workstationökből már Linux alól is megy.

A három közül a Vmware a legfinnyásabb a hardverre, a másik kettőnél alapvetően a Linux driverek határozzák meg, hogy min fog működni. Vmware esetében korlátozottan van lehetőség Linux driverek újrafordítására Vmware alá, mivel írtak egy kompatibilitási réteget a Linux kernel modulok számára a vmware kerneléhez. Ha elterjedt hardvered van, akkor viszont jó eséllyel ezt már valaki megcsinálta (sok esetben maga a gyártó), kis Google, és ki fogja dobni. Persze akinek Vmware certifikált szerverei vannak a spájzban otthon, annak ez nem annyira érdekes. :)

Mindhárom lehetőségre igaz, hogy helyi storage esetén HW RAID-et várnak, de a különböző migrációs megoldásokhoz shared storage-re van szükség értelemszerűen. A Xen és KVM alapú megoldásoknál mdraid ráhekkelhető, szükség esetén működik is (csináltam már mindkettőre), de a készítők nem ajánlják, upgrade problémáknál magadra maradsz ... stb.

Vmware ESXi-nél tudtommal ilyen lehetőség nincs, ha valaki tud róla, akkor jelezze, mert érdekelne.

Én a következő sorrendben választanék:
- Ha van pénz, vagy kevés (1-2) szerver, akkor Vmware. Egy-két szerver még sima ESXi-vel is elmenedzselhető, ha nem kell nagyon magas rendelkezésre állás. Elvileg van egy Essentials nevű licenccsomaguk, ami 3 szerverig érvényes, jár hozzá vCenter, bár vMotion nem. Ezt az adott esetben kell eldönteni, hogy vMotionra szükség van-e. Ennek az ára 580 EUR /év. Ha kell vMotion is, akkor az Essentials Plus ugyanígy 3 szerverre 5600 EUR-tól indul, bár ebben már van support is.

- Ha nincs pénz, akkor én először a Proxmox felé nézelődnék, XenServer / XCP irányban túl sok negatív tapasztalatom volt (beragadó VM-ek, beragadó API hívások, kényelmetlen parancssoros API, instabil XenCenter)

Üdv,
Gergely

Szerintem is nagyon jó összefoglaló, le a kalappal :)
Államigazgatásban használok virtualizációt, eddig squeeze alatti Xen-t használtam, de most ennek az írásnak ihletésére kipróbáltam a Proxmox-ot.
Eddig nagyon tetszik, igaz a HDD IO sebessége (KVM Win2k3 server) kb. csak a kétharmada annak, amit a XEN alatt tudott, de a webes felület kárpótol ezért. Még az OpenVZ-s linuxra leszek kíváncsi, van eléggé nagyigényű iktatóprogramunk linuxra ami Postgre-t használ db-nek. Csak egy sima dump visszatöltés 22-25 percig terjed Xen alatt 15k RPS hdd-re (jó teszt).

off:

Ha van lehetoseged probald ki: a dump file elejere irj egy BEGIN; -t, a vegere egy COMMIT; -et. Igy nem fog minden egyes sor utan diszket cibalni a postgres, hanem megcsinalja az egesz tranzakciot es a vegen (ha minden sikerult) egyszerre veglegesiti a lemezen. Tippelek: 1-2 percre rovidul majd a dump visszatoltes.

/off

Nem vagyok sql szakértő, én is csak nem rég szereztem tudomást erről az okosságról. Röviden a lényege, hogy insert/update során nem egyessével tolja be a sorokat, hanem feldolgozza az egészet a memóriában és egyszerre írja ki vinyóra. Ha pedig gond van az insert/update során, nem commitolod le. Így nincs az, hogy 50.000 soros adatbázis egyik fele módosult, másik fele nem és akkor honnan is folytassuk c. történet.
Ha OK mind bekerül, ha nem OK, megy a devnullba az egész:)

Ha már ilyen kérdés felmerült, hadd kérdezzek egy olyat, hogy:

van egy gépem (HP DL380G5) két fizikai CPU-val (4magos, HT). Használnám routernek (tc queueing-al) valamint nagios, ill. egyéb monitoringot is tennék rá (pl netflow).

Xen domU-ban nem megy a tc queueing
HVM domU-ban nagyon nyögve nyelős (kéne ide nekem linuxra spec driver, v egy ide telepített Debian már ezt jól kezeli?)
Dom0-ba nem szívesen tenném (az inkább legyen korlátozva)

A PCI Passthru-t még nem próbáltam, de nem vagyok meggyőződve róla hogy ez megoldaná a gondomat - vagy mégis? próbálta már valaki?

Esetleg OpenVZ lenne a barátom erre?

Xenserver 5.5 esetleg 5.6 voltak nekem is problémáim, de az új 6.0.2 egész jó stabil.
Jelenleg két gép fut 1 pool ban 2 storage al hibátlanul teszik a dolgukat.

Amúgy a parancssor szerintem subjektív, nekem egész tetszik. Viszont az tény hogy bele lehet buherálni bármit mivel centos fut alatta, viszont egy rolling pool upgradenél minden oda :>

Fedora 16, Thinkpad x61s

Parancssorhoz: elsőre sok minden hiányozhat az opensource xen-hez képest, de ha alaposabban szemügyre vesszük az xenes mappákat, egész jó fejlesztői toolokra bukkanhatunk.
Többek közt a klasszikus xm console megfelelője is ott van :)

http://forums.citrix.com/thread.jspa?threadID=247484

On the host console:
xe vm-list to get the list of domins running (just note the uuid of the
domain you want).
list_domains will list the domain name and the uuid of the domains.
Match up your uuid so you get the proper dom_id

xm console equivlent is
/usr/lib/xen/bin/xenconsole 


[root@dom0 1]# list_domains | grep bbd07af2-bce5-8ed8-1a9b-7b92399097a2
1160 | bbd07af2-bce5-8ed8-1a9b-7b92399097a2 |    B
[root@dom0 1]# /usr/lib/xen/bin/xenconsole 1160
Debian GNU/Linux 6.0 xenvps hvc0

xenvps login:

+ a /opt/xensource mappát is érdemes átnézni.

Nem értem. Xenserverről beszélünk? Mert ott xe-t akartál inkább írni, nem?
Opensource xennél pedig nincs 6-os szeria, 4-esnél járnak, ahol xm van.

Mod: OK, értem, megnéztem:) Szóval xl parancs is van már xenserver 6-ban, és egész ügyes, ezt nem ismertem. Köszi!

Ez minden container alapú megoldásra igaz, pl. az OpenVZ-re is.

Az egyik fejlesztői szerverünkön évekig LXC alapú virtualizáció volt Ubuntu 10.04 alapon, és működött szépen. Ami gond volt vele az nem az LXC, hanem az Ubuntusok hibája (gyakorlatilag a -32 -es kerneltől kezdve kinyírták az LXC támogatást.)

Tény, hogy kevésbé kiforrott, mint az OpenVZ. És továbbra is az a véleményem, hogy manapság virtualizálni (ha nem a reszelés a cél), akkor legjobban / leggyorsabban, egy arra kihegyezett rendszerrel lehet.

Üdv,
Gergely

( elod v | 2012. 07. 08., v – 20:31 )

Új vas, játsszunk vele. Egy HP ML150G6, van mellé egy P410, 512MB FBWC-el. A proci úgy néz ki támogatja a VTd-t.

Kár volna a négymagos procit elpocsékolni fileszerverre, így azon gondolkozom, hogy inkább virtuális hostként futtatnám, a P410 pedig PCI Passthrough-n keresztül majd szépen a fileszerver guesthez lesz hozzárendelve, 2 SAS lemez pedig rajta lóg majd.

Az alaprendszer pedig majd a SATA lemezeken lesz, az alaplapi kontrollerrel. Webszerver lesz még rajta, infrastrukturális szolgáltatások (dns, dhcp, radius, vpn, asterisk) külön hostban.

Van valakinek tapasztalata hasonlóval? Lomha lesz, vagy normális sebességgel fog futni? Komolyabb külső storage esélytelen, középiskolai környezet... Bár van még egy Microszerver, de az leginkább biztonsági mentésre szándékozom használni.

Hát inkább ne úgy csináld.

Nézd meg, hogy most mekkora modulok vannak benne (gondolom 3x2Gb) rakjál bele még ennyit (úgy 12G azzal már lehet valamit kezdeni).

Érdemes a leírásban utánanézni, hogy mi a támogatott memória konfiguráció: mekkora modulok és melyik slotba, ha más kiépítésben gondolkodsz.

Manapság nem 2 hatvány memória van úgy általában a gépekben, mert az eddigi 2 csatornás helyett 3 csatornás a buszkialakítás.

Nem jól gondolod, legalábbis nem vSphere-rel:

Myth #1: RDMs have better performance than VMFS
http://goo.gl/QspKW

Elveszted a flexibilitás egy részét és nem nagyon nyersz vele semmit.

(Egy esetet tudok elképzelni, én akkor raktam RDM-nek diszkeket amikor ZFS volt rajtuk és egy esetleges HW meghibásodás esetén biztos akartam lenni hogy a diszkek másik gépben, hypervisor nélkül is olvashatóak lesznek.)

Az RDM nem egy másik állat? Mármint amikor egy Vmware VMKernel által látott block device-t (akár helyi, akár pl. iSCSI) adsz tovább a VM-nek. Ehhez úgy tudom nem kell VT-d támogatás, viszont lokális SATA driveoknál talán nem is engedi, csak hackeléssel.

A PCI-Passthroughnál meg magát a SATA / SAS vezérlőt adod át, és a VMWare-nek fogalma nem lesz, hogy hány diszk, milyen konfigurációban van rajta. Ehhez viszont kell VT-d támogatás, és nem bármilyen vezérlővel működik, pl. az alaplapiakkal gyakran nem (legalábbis nekem még nem volt olyan, amivel ment).

Üdv,
Gergely

( mpali | 2014. 09. 10., sze – 14:15 )

két év elteltével kinek mi az álláspontja?

Xen vagy KVM?

Hat, ott a DRBD lesz a necces, mert az aktiv-aktiv kapcsolat lassu is tud lenni, raadasul nem is mindegy, hogy milyen kernel meg milyen DRBD.

En nem sajnalnam a penzt egy shared storage-ra, egyreszt meghalalja, masreszt egy picit is nagyobb rendszernel ugyis kelleni fog. A DRBD-vel csak az idodet fogod fecserelni.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

oracle VM -vel van tapasztalatottok?

Szarpalacsinta konkrétan.
Kell a managementhez telepíteni külön vnc klienst (ez még nem lenne baj).
De hogy egyszer elkezdi a Java app, hogy válogat a gépek között, hogy mihez dob fel konzolt, és mihez nem (persze hibaüzenet nélkül), majd folytatja avval, hogy egy idő után már semmihez sem, az felettébb zavaró.
És mellesleg ocsmány a management felülete.
A szolgáltatásaiban hozza a kívánt szintet, futnak rajta a vm-ek gond nélkül (a háttérben a xen teszi a dolgát, ahogy illik)
--
PtY - www.onlinedemo.hu, www.westeros.hu

+ DRBD és Pacemaker. Tervezett leállásnál live migration. Olcsó, jó IO teljesítményű és mégis igen megbízható setup.

Vaszeg Xen alapon is működne ugyanez, de a KVM-et válaszottuk, miután a RedHat felkarolta és a mainline kernel szállította, biztosabbnak tűnt a jövője.

1. Jól. :) Persze van néhány elméleti eset, amikor megcsúszik a replikálás és néhány másodpercnyi adatot fel kellhet áldozni a rendelkezésre állás oltárán, de ez gyakorlatilag aligha probléma. Ilyen lehet pl a primary node OOM eseménye, amikor a replikálás megszakad a secondary felé, de a helyi példány írása (még) nem, de rebootolni kell a host-ot. Ekkor ugye dönteni kell, hogy leállás a reboot idejére vagy használod a pár másodperccel régebbi replikát. Ez már történt meg, de amúgy kiküszöbölhető.

2. Őő, erre mit kéne válaszolni? Replikálással..? :) Pacemaker, aktív-passzív DRBD felállás, redundáns kommunikációs csatornák, STONITH.

Igen, minden egyes guesthez egyedi DRBD tartozik, tehát mind a 2 host aktív lehet.

Mondjuk én az aktív-passzív clustert preferálom, mert az aktív-aktív hiba esetén csökkent kapacitással megy tovább ami vagy elég vagy nem.

De pl N+1 cluster is megoldható így, amikor van pl 8 aktív node és egy sokdiszkes passzív, amelyk mind a 8-at replikálja, hiba esetén pedig aktív lesz. Itt nem csökken a kapacitás.

A SAN-hoz képest előnynek tartom a lokális IO-t, ez egyrészt nagy teljesítményt ad olcsón (SSD), másrészt lokalizálja az IO terhelést, pl egy megkergült guest nem tudja megterhelni a SAN-t és így kihatni több hostra is. (Persze limitekkel és jól partícionált/túlméretezett SAN-nal ez is elkerülhető, de a DRBD "by design" ilyen.)

Igen.

-Cluster: A failover cluster műszaki követelményei közt szerepel, hogy a host gépeknek Active Directory domain tagoknak kell lenni. Ez - ha szigorúan vesszük - akár még "licenc" követelménynek is értelmezhető, de szerintem jobbára csak elvileg. Viszonylag ritka az a környezet, ahol a clusterhez szükséges shared storage rendelkezésre áll, de nincs egy Active Directory a környéken.
-Live Migration: megy cluster nélkül is, "shared nothing" live migration van.
-HA: mit értesz alatta?
-Riasztások: miért ne mennének? Olyan felügyeletet teszel rá, amilyet szeretnél és a nélkül is ültethetsz az eseménynaplóra riasztásokat.

Üdv,
Marci

"-Cluster: A failover cluster műszaki követelményei közt szerepel, hogy a host gépeknek Active Directory domain tagoknak kell lenni. Ez - ha szigorúan vesszük - akár még "licenc" követelménynek is értelmezhető, de szerintem jobbára csak elvileg. Viszonylag ritka az a környezet, ahol a clusterhez szükséges shared storage rendelkezésre áll, de nincs egy Active Directory a környéken."

Köszi, ezzel megkíméltél attól, hogy megnézzem a cluster miatt, ami már érett egy ideje, mert ahol érdekes lenne, ott pont nincs AD :) (Ettől még valóban ritka valószínűleg)

Ahova én ezt néztem, ott igen. (Nem is feltétlen az ára miatt, hanem amiatt, hogy oda kell tenni mellé, ezt meg csak be kéne tolni üfhez, ezzel plusz hw költésget generálva, meg bonyolítva az adminiszrációt. Ilyen erővel a vas ára helyett kifizetem a vmware-t aztán legalább egyforma...)

Van egy olyan sejtes, hogy amire a failover cluster hasznalja az AD-t (gyakorlatilag adattarolas) arra egy megfeleloen felkeszitett Samba4 megfelelo lehet. Persze kerdes, kepes-e kezelni ezt a semat, de ezen felul maga a cluster tenyleg csak egy fuggetlen DB-kent tekint az AD-ra.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

HA High Aviability, egyik vas kidől a másik átveszi a VM-eket.
A riasztás alatt azt értem hogy maga a xenserver riaszt ha a VM elér bizonyos értékeket pl cpu terhelés.

Viszont akkor egy AD fog kelleni, viszont ha van 2-3 fizikai vasam amit hypervizornak szánok + egy közös SAN, valamint ezek szerint kell még egy AD (ami ugye nincsen ingyen) ?

Fedora 20, Thinkpad x220

HA: megoldhatod failover clusterrel, vagy ha kellően biztos vagy abban, amit csinálsz, Hyper-V replicával is: http://blogs.technet.com/b/keithmayer/archive/2012/10/05/automate-disas…

Az, hogy kell AD a Failover Clusterhez, egy ilyen környezet költségeihez képest nem egy jelentős összeg.
A 15 useres Windows Server 2012 R2 Foundation OEM csatornákon szerezhető be, ahogy nézem, 60-70e Ft.
A 25 useres Windows Server 2012 R2 Essentials listaára az USA-ban kb. $500.
Ha nem profitorientált cégről van szó, akkor pedig általában még sokkal olcsóbb lehetőségek is vannak.

Azon elgondolkodnék, hogy hasznos-e egy cluster egy mindösszesen 2-3 fizikai vason kialakítandó környezet esetén...
Ugyanis egy cluster tud a rendelkezésre állást csökkentő tényező is lenni, ha olyan üzemeltetési környezetbe/kultúrába kerül. (És ezt konkrét clusterezési technológiától függetlenül gondolom.)

Üdv,
Marci
A Microsoftnál dolgozom.

Igen 2-3 fizikai gép + SAN árához képest a windows ára csekély. Viszont nekem eleve nonszensz az a koncepció, hogyha akarok egy virtualizált környezetet akkor kell hozzá egy AD. Xenserver letisztultabb jóval betolod, a hpyervisorokat amin fut az ssh meg a xen-api.

Ez is olyan, hogy kinek a pap kinek a papné. A kvm nél a type-2 felépítés nem jön be.

És akkor a teljesítményről még szó se esett. Az meg egy külön történet.

Fedora 20, Thinkpad x220

Virtulizalt környezethez nem kell AD, ha Failover Cluster technológiát szeretnél használni, akkor kell az AD tagság. De ha megfigyeled, egyre gyengül az AD iránti követelmény a failover clusterben, van már pl AD-Detached belőle, amihez nem kell computer objektumot létrehozni ADban.
Mivel Kerberost használ a cluster a kommunikációhoz és az az ADban van implementálva Windowson, ezért a műszaki követelmény.

Üdv,
Marci

Hát ha van több hypervizor + SAN, azért akkor már igencsak kell a failover HA. Ez xenserverben pár kattintás. 6.2 előtt ezért a kattintásért pénzt kértek, mostmár ingyen van. A kvm/proxmox nál régebben ehhez kézzel kellett buherálni scripteket, azóta nem néztem és nem tudom hogy megy-e a webfeluletről. Néztem én az RHEV-t is mikor megjelent de eleve vicc volt hogy üzemeltetéshez kellett akkoriban windows szerver. Később ezt elhagyták, legutóbb mikor néztem talán az első 3.0 is erősen pilótavizsgás volt.

Szóval értem én, hogy elhagyják egyszer, majd talán. Viszont minek vesződni vele, ha van olyan környezet amihez nem kell ? Ott ahol van 20 windows szerver 2-3 AD, esetleg 1-2 linux ott simán jó lehet. Viszont ott ahol ez nincsen meg, ott milyen érv van a hyper-v mögött ? Én mint üzemeltető csak plusz koloncokat látok, amik mind potenciális hibaforrás lehet.

Fedora 20, Thinkpad x220

Hát igen xenserverben storage xenmotion a neve. Ezzel gyakorlatilag független xenserverek közt tudsz VM-et mozgatni live módban, még az sem kell hogy közös pool-ban legyenek. Talán annyi a feltétel hogy egyforma CPU-k legyenek, illetve rosszabbról újabb felé lehet migrálni.

Fedora 20, Thinkpad x220

Azért a Replica használhatósági köre eléggé korlátozott (lévén, hogy semmi nem garantálja az adatok integritását).
De bedobok én is párat a HP meleltt: dinamikus (leállás nélküli) memória menedzsment, RDMA-val támogatott live migráció, DHCP Snooping.

"Azért a Replica használhatósági köre eléggé korlátozott (lévén, hogy semmi nem garantálja az adatok integritását)."

Már miért is lenne korlátozott? Pont jó arra, amire való. :)
Ott a rendszer max negyedórával ezelőtti állapota (inkonzisztensen, még szép!), működik, hálózati kapcsolatai is működnek: fogod az utolsó érvényes mentést vagy kézzel helyrepofozod a konzisztenciát és mész tovább.
Alig hinném, hogy az elsődleges környezet katasztrofális meghibásodására van ennél kényelmesebb megoldás.

Üdv,
Marci

Hasznos link-ek:

http://www.altaro.com/hyper-v/the-hyper-v-virtual-switch-explained-part…

E nélkül halott vagy: http://technet.microsoft.com/en-us/library/hh848559.aspx

CoreFig hasznos: http://corefig.codeplex.com/

Veeam Task Manager innen: http://www.veeam.com/downloads/

Két sor amiről jó ha tudunk:
RDP-t engedjük be a tűzfalon:
netsh advfirewall firewall set rule group="remote desktop" new enable=Yes

Ha nincs lokális elérésünk elég trükkös letölteni bármit is mivel az FTP nem működik. Powershell alól:
New-NetFirewallRule -DisplayName "FTP In" -Direction Inbound -Protocol TCP –Enabled True –Action Allow -Profile Any -Program "%SystemRoot%\System32\ftp.exe" -Service Any -LocalPort 20,21,1024-65535 -EdgeTraversalPolicy Allow

"RDP-t engedjük be a tűzfalon:"

sconfig megfelelo opcioja megcsinalja

de egyebkent megfeleloen elszeparalt kornyezetben a hyperv tuzfala letilthato kompletten. Marpedig az ember virtualizacios vasat elszeparaltan futtat, ugyhogy ott igazabol csak hatraltato tenyezo egy olyan tuzfal, ami teljesen ignorans a rajta futo szolgaltatasok irant.

Ami a letoltest illeti, ha atdobod privat halora az interfeszeit, megoldja (ha nem akarod letiltani a tuzfalat): 


$connections = $networkListManager.GetNetworkConnections()
$type = 1
$connections | % {$_.GetNetwork().SetCategory($type)}
  • $type = 0 - public
  • $type = 1 - private
  • $type = 2 - domain

2-esre csak akkor erdemes rakni, ha van AD meg domain.

Ami a corefiget illeti: az uj Hyper-V -t meg nem tamogatja teljes mertekben, a .Net frameworkot manualisan kell felengedelyezni, es igazabol nem talaltam eleg hasznosnak Hyper-V eseteben, mivel magara a virtualizacios vasra ha egyszer beleptel felkonfigolni a halozatot, akkor csak a shutdown parancs miatt lepkedsz be - szoval a billentyuzetkiosztason kivul nincs mit beallitani rajta. A halokartyanak ugyis out-of-the-box mennie kell, custom kartyakkal csak szopni fogsz, mert tavoli menedzsment nelkul rettenetesen szopo a drivertelepites, foleg olyan drivereknel, aminel a gyarto a Server Core fogalomrol sosem hallott.

Amire erdemes odafigyelni: rengeteg workaround van ugyan, de az RSAT nem megkerulheto. Sajnos azonban a Hyper-V 2012-hoz valo RSAT csak Windows 8 vagy ekvivalens operacios rendszerre (Windows 2012 barmilyen edition, Windows 8, Windows 8.1) megy fel, a Windows 7-et undorral loki el magatol, a Metro kornyezet hianya miatt.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Nem tudom, pontosan mire probalsz utalni.
- Hogy nem biztonsagos a belso halo? Az. De a Windows tuzfala ezen semmit nem valtoztat. Jellemzoen a belulrol erkezo tamadasok tipikusan amugy is engedelyezett szolgaltatasok ellen iranyulnak (RPC, SMB, HTTP(WinRM) ami itt szobajohet), raadasul az epkezlab menedzselhetoseghez agyuval kell lyuggatni a Windows tuzfalat, hogy minden fisz-fasz menedzsment cucc atmehessen rajta.
- Hogy ha be is jutottak nehezebb megtorni egy gepet, ha van tuzfala? Jellemzoen, ha megtortek egy gepet, akkor megprobaljak valamelyik admin jelszavat visszafejteni, ami egy olyan integralt halozatban, mint amilyet az AD biztosit, gyakorlatilag szabad utat biztosit. Arrol nem is beszelve, hogy a Windowsban heti szinten talalnak biztonsagi reseket, ami ellen a Windows tuzfal semmit nem ved, raadasul - mivel Server Core-rol beszelunk - nem sok biztonsagi termek van, ami egyaltalan megvedheti a gepet. A Microsoftnak peldaul semmilyen ilyen jellegu megoldasa nincsen, ami megvedhetne egy Server Core szervert.

Arrol nem is beszelve, hogy az FTP mukodesehez pl. az egesz 1024 feletti tartomanyt ki kell nyitni ha a tuzfal a legszigorubb beallitason van (mert nem adhato meg egyszeruen, hogy az FTP milyen portokat hasznalhat), ettol mar csak egy apro lepes a tuzfal letiltasa. Mivel a Windows tuzfal messze nem rendelkezik az ISA (TMG? Nem tudom mar mi lett a helyettese) kepessegeivel, igy nem lehet benne connection alapu szabalyt hozni, nem ismeri az FTP protokoll ilyen iranyu mukodeset.

Kerlek, utalasok helyett inkabb gyere szakmai ervekkel.

Es mielott lehulyeznel: pontosan tudom, miert jo ha van tuzfal egy gepen. Viszont izolalt kornyezetben, ahol kivulrol kozvetlenul nem lehet elerni egy gepet, ott a tuzfalnak megkerdojelezheto haszna van. Ha pedig a tamado bejutott a belso halora, az mar amugy is regen rossz, egy Server Core-n raadasul nem sok kozvetlenul hasznos adat van, leven hogy a Hyper-V -t jellemzoen shared storage-ra teszik, a komplett VHD-t meg eleg nyugos ugy ellopni, hogy ne tunjon fel a konstans kifele iranyu forgalom.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

-Arra utalok, hogy a mélységi védelem olyan általános alapelv, ami ellen univerzális kivételeket (~"kapcsold ki a tűzfalat, ha megfelelően szeparált a gép") nem tennék. Minden helyzetet külön javaslok megvizsgálni.
-Egyetértek azzal, hogy a menedzselhetőség és a biztonság nem barátok.
-Egy bekapcsolt tűzfal például nehezíti, hogy a támadó a sebezhető gép fölött átvegye az irányítást.
-Az admin jelszavakra tett utalásoddal nagyon egyetértek. Egy Active Directory környezetben szerintem különösen nagy figyelmet kell fordítani az admin felhasználók működésére és az AD megfelelő kialakítására, mert egy AD feletti kontroll elvesztése nagyon fájdalmas ügy.
-FTP ne működjön, szerintem, ha egy mód van rá.
-Nem hülyéztelek le, de minden "perem-védelem" jellegű megközelítést szeretek megkérdőjelezni.

Üdv,
Marci

"FTP ne mukodjon" - eleg maceras egy olyan gepre adatot tolteni, ami adott esetben nincs is elerheto kozelsegben. Ha akozott kell valasztanom, hggy SMB megosztast csinalok a gepen, vagy FTP-rol letoltok dolgokat, akkor inkabb az FTP mellett fogok szavazni. Az, hogy a Windowsba tizensok ev alatt se sikerult egy normalis tuzfalat szulni, ami kepes az FTP protokoll idiotizmuasat elkezelni, az hadd ne az en hibam legyen.

"melysegi vedelem" - reszben egyetertek. En is probalom minel inkabb vedeni a gepeket, tuzfalazni ott, ahol van kulso tuzfal is (bar ez inkabb abbol fakad, hogy en nem mindig bizom a belso haloban sem). Azonban, egy Server Core menedzselhetosegehez nagyon sok portot ki kell nyitni, ami legalabbis felveti a lehetoseget, hogy nem egyszerubb-e kikapcsolni a tuzfalat, mint egy bonyolult tuzfalat uzemeltetni (ami az upgradek soran bonyolultabba valhat, vagy uj monitoring szoftverek bevezetesevel bonyolodhat). Foleg egy olyan rendszer eseteben, ahol - egy jol tervezett felho-clusterrol beszelve - a management halo teljes mertekben vedett, a node-k pedig ezen felul csak a cluster haloval kommunikalnak, mas gepet (a halon belul) adott esetben el sem ernek. Egy jol vedett halot script kiddie-k kis arannyal tornek fel, aki pedig komolyabban gondolkodik, az inkabb a node-ken futtatott virtualis gepeket veszi celba, semmint magukat a node-kat.

Ami igazan jo lenne, az egy, kifejezetten Server Core-kre kitalalt tuzfalmegoldas, ami automatikusan felismerne a telepitett szoftvereket (mondjuk azok elindulasakor) es kezelne nekik a tuzfalat. Mivel egy Core hozzaferese minden szempontbol csak tavolrol kepzelheto el, nem merul fel, hogy egy szolgaltatas azert nyitna tuzfalat, hogy lokalisan legyen elerheto.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

"FTP ne működjön" - De ne ám. Az a csúnya cleartextben küldözgeti a jelszavakat. Fujj! Ne legyen!
Ha meg FTPs-ről beszélünk, akkor hogyan is oldod meg a dolgot jobban, mint a Windows?

"Az, hogy a Windowsba tizensok ev alatt se sikerult egy normalis tuzfalat szulni, ami kepes az FTP protokoll idiotizmuasat elkezelni, az hadd ne az en hibam legyen. " - Már a Windows Server 2008 is stateful módon kezeli az FTP-t: http://technet.microsoft.com/en-us/library/dd421710(v=WS.10).aspx

Üdv,
Marci

sconfig megvolt, ettől a tűzfalban még nem jelent meg a szabály és nem csatlakozott. Bug lehet, de teljesen friss (múlt csütörtöki) letöltésből telepítettem.

Tűzfalat nem szeretném tovább lukasztgatni, az FTP-t is ki fogom kapcsolni, mert az első dolog az volt, hogy putty-t, pscp-t másoltam rá.

Varj, ne keverd a dolgokat. Az, hogy en egy exe-nek megmondhatom, hogy az altala kinyitott portokon kommunikalhat, az legfeljebb csak egyszerusiti a tuzfal konfiguralasat, de ettol a tuzfal meg nem fogja erteni, mi zajlik rajta keresztul. Az FTP, a SIP, a H323 mind-mind olyan protokollok, amiknel egyaltalan nem eleg portokat nyitni-csukni, alapszinten erteni kell a protokollok mukodeset, es felkeszulni az esetleges vissziranyu kapcsolatokra is.

Ahhoz, hogy egy tuzfal ertse ezeket, nem kell teljeserteku L7 tuzfalnak lennie, de bele kell tudjon nezni az adatforgalomba, mert csak igy tudja dinamikusan kitalalni, hogy mi a teendoje. Nem veletlen, hogy ezek a specialis protokollok a Linuxos tuzfalban dedikalt modult kaptak a kapcsolataik kovetesehez (connection tracking).
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

"csak egyszerusiti a tuzfal konfiguralasat"
Azért az, hogy a tűzfalat csak egy megnevezett futtatható program számára nyitod ki az adott paraméterekkel, az adott felhasználó számára, az mégiscsak több, mint egymással összefüggő csomagszűrő szabályokat létrehozni.

Üdv,
Marci

Mibe fogadsz? ;)
A Windows tűzfalban full path-al adod meg a futtatható programot, így annak különböző változatait gond nélkül tudod kezelni.
Azt, hogy egy adott full path-on az a program található-e mint szeretnéd és szabad-e neki futnia, az nyilván nem a tűzfal dolga: erre az Applocker való.

Üdv,
Marci

"Es a WF kepes egyutt dolgozni az AppLockerrel?" - Milyen együttdolgozásra gondolsz? A tűzfal engedi/tiltja az adott helyen levő program kommunikációját, az Applocker meg biztosítja, hogy tényleg az a program legyen ott, amelyiknek kell.

"Es mi van, ha az AppLocker le van tiltva/nem mukodik valamiert?" Szerinted? :)

Üdv,
Marci

'valami'="az AppLocker"
Ha 'valami' le van tiltva/nem mukodik valamiert, akkor nem csinálja azt, amit kell neki.
Ilyen esetekre lehet felügyeletet ültetni 'valami' nyakára, ami alkalmas lehet arra, hogy a nem csinálás esetén riasszon/korlátozó intézkedéseket indítson el/állítsa helyre (vagy legalább kísérelje meg helyreállítani) a kívánt működést.

És, ha a felügyelet sem működik? Akkor elbújnék.

Üdv,
Marci

Nem a nyilvanvalora akartam rakerdezni, de persze ertelmezni tudni kell.

Ezek szerint akkor a tuzfal es az AppLocker kozott nincs erdemi kommunikacio. Ennyi erdekelt a tortenetbol, nem tobb.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

( zeller | 2014. 09. 15., h – 10:18 )

A RHEL5 az már történelem, nem érdemes azon rágódni, mi volt benne, és azt mire cserélték...