Proxmox - szabad szoftverekre épülő, vállalati szintű virtualizációs megoldás a LAS aktuális kiadásában

Linux

Saját, szűk körben végzett, nem reprezentatív felmérésem szerint nem sokan ismerik a Proxmox-ot. A Proxmox - a saját bevallása szerint - egy szabad szoftverekre épülő, vállalati szintű virtualizációs megoldás. Összetevői: Debian, OpenVZ és KVM:

Egy, a Proxmox által készített, nem független összehasonlítás a VMware vSphere, Windows Hyper-V, Citrix Xen Server termékekkel elérhető itt.

A Linux Action Show (LAS) friss kiadásának főszereplője a Proxmox volt. A kiadás megtekinthető, letölthető innen.

A Proxmox weboldala itt.

( cvk v | 2012. 12. 04., k – 16:34 )

Én is használom CPU virtualizáció nélküli gépe(ke)n de érdekelne, hogy a Debian GNU/Linux 7.0-ban megszüntetésre kerülő OpenVZ támogatás után ráállnak az LXC konténerek kezelésére és végre lesz egy használható webes felület a Linux Containerekhez? Én ebben reménykedek.

Ó f*ck :( Miért szüntetik meg D7-ben? Az OpenVZ az egyik legjobb megoldás szerintem nagy terhelésű WEB frontendek számára: kis erőforrás overhead, egyszerű kezelés és működtetés. Atomstabilan fut egy rakás konténer a kezeim alatt :S
És nem utolsósorban két link:
http://wiki.openvz.org/Performance
http://facility.bioinformatics.ucr.edu/people/aleksandr-levchuk/for-adm…

Nekem is ez volt az első reakcióm, de Umath szerint a Proxmox a jelenlegi Debian 6-os kiadásában is Redhat kernelt használ.
Debian 7 alatt ezért hiába szűnik meg a disztribúció részéről az OpenVZ támogatás, ők (Proxmox) továbbra is azt fogják használni.

A támogatás megszűnésének okán én azt értem, hogy a Wheezy már 3.x -es kernellel jön, az OVZ pacth meg még csak 2.6.x kernelre létezik ezért nem tudnak/akarnak váltani.

Ugyanez szerencsére igaz az LXC-re is, mellesleg az IBM mellett maga az OpenVZ tolja a szekerét leginkább.

"Our kernel developers work hard to merge containers functionality into the Linux kernel, making OpenVZ team the biggest contributor to Linux Containers (LXC) kernel, with features such as PID and network namespaces, memory controller, checkpoint-restore etc." -- http://wiki.openvz.org/Main_Page

( mickeyratt | 2012. 12. 04., k – 18:50 )

Mi is használjuk közigazgatási területen, de az OpenVZ nem nagyon jön be :( Egyébként már közel egy éve megy hiba nélkül a rendszer.

2 éve több hasonló visszajelzés is volt a felvetésemre, ami az volt, hogy míg egy xen-en futtatott rendszer 256MB memóriával beérte, addig openvz-ben _ugyanez_ 1GB memóriát követelt magának.Olyannyira ugyanaz volt a rendszer, hogy magam rsynceltem át xen-ből openvz-be és indítottam be.
Swap xen alatt sem volt.
Az említett openvz-s szitu épp egy 2010 tavaszi proxmox alatt történt.
Erre mondták többen, hogy másnál is előfordult. Volt akinek egy grafikai alkalmazáshoz xen-en 4GB RAM, openvz-ben 8GB RAM kellett (a számok lehet, hogy nem pontosak, de az arányok igen).

OpenVZ esetében van vagy 30 paraméter, amit állítani lehet és ha nem tudja az ember mit csinál, akkor egészen elvadult dolgok is születhetnek belőle.
Én vagy 6 éve használom a fentit, de ilyent nem tapasztaltam.

Másrészről az OpenVZ egy ideje kezeli már a swap-et a kliensek felé, így már az sem gond. Talán pont a Redhat/Proxmox vonalon láttam elsőnek ezt a funkciót.

( STP | 2012. 12. 04., k – 19:43 )

FC storage-ot érdekesen kezeli, normális tűzfal még mindig nuku, management eszközei sem túl szofisztikáltak.
Játszani, vagy kisebb megoldásokhoz jó, de enterspájzba nem való.

enterprise-knak ott az esx, megveszik nehany ezer $-ert a ficsoroket es orulnek. De sajna sok helyen erre nincs keret. Na az ott dolgozok eletet konnyiti meg ez, mert egyszeru, es nemkell kezzel osszereszelni a dolgokat.

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

FC storage-ot nálam egész jól kezeli, cc. 5 LUN van alá rakva 4 gépes clusterrel tekerem és semmi baja.
Normális tűzfal? Hova? Kicsit másképp kell hozzáállni mint ESX-hez, de meg lehet jól csinálni szerintem.
Management? A 2-es verziót láttad már élesben? Egész sok újdonság és könnyítés van benne, szerintem egész szofisztikált dolgokat is tud már.
Enterspájzba meg az való -ahogy mondani szokták-, ami mögött cég áll. Lásd. Nagios vs. Zabbix.

Majd 100+ LUN felett mond ezt.
Hogy miért kell tűzfal? Hogy ne tudják megborítani a cuccot. Akár belülről is.
Miután a videó is 2-es verziót mutogatja, miért írtam volna az 1.x-ről?
A Proxmox mögött pedig a Proxmox Server Solutions GmbH áll. Kb úgy, ahogy a Zabbix mögött a ZABBIX SIA.

( gabrielakos v | 2012. 12. 04., k – 22:40 )

Jó cuccnak látszik. Nekem most kétféle virtualizációm van: esxi 5.0 és virtualbox 4.2 .
A virtualbox 4.2 időnként megöli a gépet (mondjuk egyre ritkábban szerencsére) viszont phpvirtualbox-al ad egy frankó felületet, használhatós.
Az esxi atomstabil de eleve nem szeretem a licenszes cuccot, másrészt az admin felülete (főleg macről) botrányos, utálom.

Ehhez képest a proxmox milyen?
Kérdés: videóban az ürge egy csomó mindent választott hw dolgokban. Ezekről van vmi leírás hogy mikor mit kell választani?

--
Gábriel Ákos
http://i-logic.hu

Nem tudom, mire gondolsz. Ha a virtualis gep letrehozo varazslora, akkor ahogy elneztem, nagyjabol ugyanazokat valasztotta, amit mondjuk egy VMware eseteben is bebokdos az ember, egyedul talan a csatolo emulacio az, ami kerdeses lehet, ott altalaban jo otlet VIRTIO-t valasztani, mert sokszor gyorsabb a masik ket lehetosegnel. CPU-nal igazabol a qemu vagy kvm kezdetueket (ha kvm-ed van) erdemes valasztani, az utana allo 32/64 gondolom egyertelmu. Minden mast akkor kell valasztani, ha valami specko CPU emulaciora van szukseged, ebben a QEMU doksija vezet el reszletesebben, de a legtobb esetben nem szokott kelleni.

En csak a VM ID-t nem ertem, hogy azt miert kell kezzel megadni, de mondjuk en nem ismerem az OpenVZ mukodeset, szoval ha valaki elmondana, annak orulnek.
-- 

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

openvz egy konténer alapú virtualizáció... azaz a host kernelét kapja kicsit chroot jellegűen a guest, ezért csak Linux kernel alapú guest működhet.
A Guest-en gyakorlatilag olyan érzésed van mintha önálló géped lenne saját hálózattal fájlrendszerrel stb.
A hoston teljesen látszik a guest fájlrendszere processzei és képes cachelni a guest-ek között azonos librarikat izoláltan.

Ennek az az előnye, hogy minimális a késleltetés. Így valós idejű alklamazások gyorsabban mennek, mintha még egy processzor+ram stb emuláció lenne.

Neked ment egyből az openvz-s ubuntu? Nekem eth0-t nem csinált, így se konzol, se net, nehéz elérni. A debianokon legalább a konzol jó volt, onnan tudtam netet csiholni. Most már az ubuntus konzolok is mennek, tudtam netet is csinálni, minden frankó.

--
Gábriel Ákos
http://i-logic.hu

Nálam nem ubuntu van, hanem Debian. És én nem most telepítettem, hanem korábban, tehát ez egy működő rendszer volt.

Amikor frissítettem a Proxmox szervert 2.1-ről 2.2-re, akkor jelentkezett az a hiba, hogy a webes Java-s Consolon nem tudtam csatlakozni az openvz-s debian szerverhez.

A http://pve.proxmox.com/wiki/OpenVZ_Console weboldalon le is van írva, hogy a Proxmox 2.2-től kezdve egy másik Consol-t használnak. Nálam ez okozta a hibát. Miután a hivatkozott weboldal szerint módosítottam az openvz-s debian-t, már működött az új webes java-s Consol.

Véleményem szerint az új webes java consol módszer bevezetése nem befolyásolja az NIC interfészeket.

( Imo | 2012. 12. 05., sze – 07:30 )

Az összehasonlitó táblázat már-már nevetségesen hazug, a konkurenciát illetően.

( LZ | 2012. 12. 05., sze – 17:34 )

Tessék ma' mondani, ez mitől "vállalati szintű" ?!

( turul16 v | 2012. 12. 05., sze – 17:48 )

Es vajon hanyan ismerik az oVirt -et vagy az openstack-et :)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

devstack az fejlesztoknek van, de meglopen jol es egyszeruen megy Fedora 17/18 -an is.

Az OpenStack fejlesztoi infrastructura nagyon kiraly. git gerrit (review), jenkins buildel egy rendszert, devstack -el feltoja a cumokat, kuld ra egy integracios tesztet, aztan, ha a nepeknek is tetszik a modositas (Tobb ember reviewol aztan senior approval) mehet a master branchbe (ujabb integracios test).

Szoval jo esellyel, futni fog a git verzio is :)
Egyesek szerint, ha egy git verzioban 2 hetig nem talalnak critikus bugot akkor akar mehetne prodra is :)

Tobb ezren dolgonak rajta, kurva nagy projekt, sok viszonylag apro onallo koponensel. Amolyan Unix philosophy REST API vilagban.

Fedora reszletes manulais install leiras csomagbol

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

oVirt Engine

* Minimum - Dual core server with 4 GB RAM, with 25 GB free disk space and 1 Gbps network interface.
* Recommended - Dual Sockets/Quad core server with 16 GB RAM, 50 GB free disk space on multiple disk spindles and 1 Gbps network interface.

Hiába no, JBoss szereti a RAM-ot.

( pappe v | 2016. 02. 24., sze – 16:21 )

Most mi újság a házuk táján? Használjátok? Tapasztalatok?