Dotaz: proxmox dobra volba?

[miker]

Zdravim, bude proxmox dobra volba pre virtualizaciu do produkcie? Pre solidny kus HW a niekolko linux virtual hostov. Performance je celkom dolezity.

---

---

Odpovědi

[Jesus Jimenez]

Ano

[Jan Kratochvíl]

+1

[Jendа]

Osobně mi různé distribuce bundlované třeba s takovýmto webovým rozhraním nikdy k srdci moc nepřirostly. První problém většinou nastane v okamžiku, kdy je potřeba nastavit něco, s čím tvůrci nepočítali. Proto mám raději normální Linux a nad ním ty potřebné aplikace nastavené „nativně“, tedy v tomto případě asi KVM+libvirt. Ale možná je Proxmox jiný.

[mirko]

diky za nazor, suhlasim. Nahodil som to zatial do testovacieho prostredia a uvidim neskor ci sa to vyplati nasadit alebo nie :)

[maník]

Je, navíc ho můžete nainstalovat do Debianu.

[pavele]

A k čemu ho bude mít v Debianu?

[Ondro]

Osobně mi různé distribuce bundlované třeba s takovýmto webovým rozhraním nikdy k srdci moc nepřirostly. První problém většinou nastane v okamžiku, kdy je potřeba nastavit něco, s čím tvůrci nepočítali. Proto mám raději normální Linux a nad ním ty potřebné aplikace nastavené „nativně“

Na to tam mas ssh pristup, takze smelo mozes nastavovat "nativne".

[Jendа]

Samozřejmě, že tam mám ssh přístup. Ale aby pak ty moje změny fungovaly s tím webovým rozhraním, to je nepřepsalo zpátky, nebo se kvůli tomu nerozbilo.

[ZS-Man]

http://www.montanalinux.org/proxmox-ve-martin-interview.html

ML: Does Proxmox VE use libvirt? If not, why not?

Martin: We do not use libvirt. libvirt is written in C and contains large parts we will never use. With perl, we can do the same in ten times less code and time. Therefore development is much faster without libvirt.

Proxmox ma vlastni CLI utility, webove klikatko by mela byt pouze nadstavba nad temito utilitami, takze by to melo oboustrane fungovat. https://pve.proxmox.com/wiki/Command_line_tools

[scott]

Takto to vidím já :

• ESXi Free
• verze zdarma je bez hw limitů
• je problém s monitoringem hw, reportingem apod. - free verze nemá třeba podporu snmp
• omezená podpora hw
• nemožnost použít sw raid
• dostupný je klient jen pro windows a ještě ke všemu ve starší verzi, protože nově se přešlo na web klienta, který je součástí pouze placené verze
• všechny systémy pracují hodně dobře, mají to pěkně vyladěno
• léty prověřené řešení
• většina produktů mají oficiální support pro provoz na VMWare, ostatní řešení nebývají oficiálně podporována
• Oficiálně je možný i provoz z flash disku
• oVirt
• je free
• stojí za něm RHEL a vychází z něj RHEV
• je to trochu větší řešení (standardní instalace doporučuje oddělit management od hypervisoru)
• součástí je i captive portal pro virtualizaci stanic, ale samotná virtualizace stanic má několik problémů, takže to není produkčně použitelné
• přijde mi ještě šíleně hodně ve vývoji, nepřišlo mi to stabilní
• řešení není blbuvzdorné (chybí kontrolní mechanismi), jeden omylný klik a celý cluster může jít dolu jako nic
• Proxmox
• je free
• jako hypervisor používají debian, ale lze nainstalovat i přímo do čistého debianu
• podporují i kontejnery
• mají to prý už solidně vyladěno
• nevím, jaká je podpora windows, resp. jak moc jsou na tom windows výkonné apod.
• XenServer
• je free bez limitů
• léty prověřené řešení
• nejsem si zcela jist, zda má budoucnost
• centrální mgmt je pro windows (lze použít alternativy, ale nevím, jak moc jsou spolehlivé)
• ruční kvm/libvirt
• vše si člověk musí udělat sám, žádné grafy, jednoduché ovládání apod.

Já osobně mám v práci asi 10x ESXi Free, aktuálně ve verzi 6.0. Vše vesměs na HP DL380g8/9. Virtualizuji jak windows (Exchange, MSSQL, AD, FS ...), tak linux (Kerio Connect, Oracle, ftp, http, freeradius, dns ...)

Osobně jsem měl čas otestovat jen oVirt a ten jsem odmítl. Pokud máš nějaké menší řešení, tak bych se Proxmoxu nebál. Všichni o něm mluví docela kladně a na wiki má pěknou dokumentaci a ničeho se nebojí (viz podpora ZFSonLinux, GlusterFS, drbd apod.).

Zdar Max

[miker]

super, pekne popisane!

co sa taka systemov tak virtualizovane budu len linux systemy, 10G ethernet a NFS v proxmoxe nebude problem. Aj podpora kontajnerov sa zide, hlavne developeri budu urcite radi

[MP]

Vzhledem k tomu, ze proxmox je postaven nad KVM, tak vykon Windows odpovida vykonu KVM.

Jinak ja bezim ted nekolik clusteru na Xen ve Wheezy a v planu je migrace na proxmox. Takze asi tak.

[Max]

A můžeš se podělit o to, proč budeš migrovat / jaké k tomu máš důvody?
díky
Zdar Max

[MP]

Jasne. Serazeno dle momentalni dulezitosti:

1] xen (ne xenserver) ve wheezy je zabugovany a zpusobuje s oblibou pady resources

2] xen v jessii nebyl v dobe vydani kompletni, chybely tam veci kolem HA

3] potreba admin rozhrani - cli je fajn, ale neumoznuje jemnejsi spravu opravneni.

Premyslel jsem i o xenserveru, ale odrazuje me od toho trochu omezenejsi podpora hw, zpusob instalace zaplat, a hlavne - casto jsem narazil na smutek adminu, kdyz jim padl primar - klidne to sundalo i zbytek clusteru resp. to minimalne znemoznilo administraci. Lakalo me i ESXi, ale trochu jsem se bal tech omezeni kolem HW.

btw: nema hw limity a pritom pracuje s omezenym HW je trochu zmatecne ;)

[Max]

Ok, osobně bych se Xen bál nasadit mimo XenServer.
Jinak "omezená podpora hw" a "je bez hw limitů" mi přijdou jako dvě rozdílné věci, nic zmatečného.
Zdar Max

[Heron]

žádné grafy

Ano, to je na virtualizaci to nejpodstatnější...

Mám v jobu 4xESX vSphere nad 12x ESX a pokud to funguje, tak to funguje. Problém je, že je to black box, takže když to nefunguje, tak máš omezené možnosti zjistit proč. Navíc to stojí nějaké peníze (free ESX tuto nevýhodu samozřejmě nemá, ale má HW omezení).

Kdysi jsem o tom něco ublognul. (Sice už je spousta věcí jinak, závislost na Widlích je konečně pryč, ale základní myšlenka zůstává.)

Pro mě je stále nejprůchodnější varianta plně oss řešení, linux, kvm, pro devel třeba lxc nebo nspawn (nebo cokoliv chcete) a vše dělat ručně. Pro správu stačí ssh. Je to linux jako kterýkoliv jiný. Ať si ty firmy a klikátory hrají na co chtějí.

Je to nejjednodušší řešení, máte to plně pod kontrolou a funguje. To že tam nejsou grafy ... no tak si je tam dodělejte (zabbix, munin, cacti, nebo chvilka soukromí s rrd tool).

[MP]

Rucne a pres SSH? A jak budete pres SSH resit jemnejsi spravu pravomoci napr. pro tym IT, dev? Jako ze treba develu dovolite pristup pres SSH primo na core servery?

[Heron]

Nemám příliš rád otázky na jak, přičemž vůbec není definované proč a zda vůbec.

IT tým (tech) má snad přístup na stroje vždy z titulu své práce, z develu se na produkční servery (na jejich správu ani na produkci) zase nepřistupuje vůbec.

[Max]

Jen bych měl jednu připomínku, IT nemusí mít přístup na všechny stroje vždy. Bývá to třeba z důvodů eliminace úniku dat. Třeba k našemu personálnímu (platy apod.) serveru nemáme přístup všichni z našeho IT, jen někteří, a může s ním manipulovat jen někdo a ještě jen za určitých podmínek.
Dokážu si představit, že jen "personální" server to ve větších firmách nebude.
Zdar Max

[Heron]

Asi je potřeba si definovat co tím přístupem myslíme.

Jednak je to přístup na danou virtuálku (do toho OS) a taky je to přístup na daný hypervizor (ovládání, do toho hypervizor OS třeba přes ssh, nebo klienta, tj jedno). Pokud někdo má mít přístup pouze k vybrané skupině virtuálek (do jejich os), tak nemůže mít přístup na ten hypervizor, pokud tam běží i virtuálky, kam nemá mít přístup. (Prostě jen proto, že by je mohl okopírovat nebo spustit v single režimu apod.)

To, že se někde definuje uživatel ovládající hypervizor, který má přístup jen k nějaké množině virtuálek které může ovládat bych za zabezpečení tedy nepovažoval.

Mimochodem, tohle je zrovna věc, která se dá dělat jinak. Já mám ve správě servery, kde jsou neveřejná data a ani já se k těm datům nedostanu. Prostě jsou šifrovaná, klíč je u zákazníka. Takže vůbec nevadí, že k tomu má přístup "kde kdo" (tech), protože se do těch dat stejně nikdo nedostane. Tohle mám na mysli tím, že vždy existuje více způsobů řešení. A mimochodem, je to také ochrana pro mě, protože se vyskytují pokusy, kdy někdo zavolá a řekne: "hele, potřebujeme změnit něco v těch datech". Já to udělat nemůžu, protože jsou buď šifrovaná, nebo otevřená, ale zase podepsaná. Klíč nemám. Jakákoliv změna by byla okamžitě vidět (neplatný podpis). Takže to chrání i mě před nařčením, že jsem něco změnil.

Jinak ad to personální: jasně, přístup na ten server třeba někdo nemá, ale má přístup na email server... Víc snad netřeba dodávat. Lidé jsou lidé (premiér je premiér) a jsou schopni citlivé informace z jinak dobře zabezpečeného systému prostě poslat emailem (nebo jakkoliv jinak). Takže i technik bez přístupu "do bunkru" se k těm datům stejně dostane.

[Max]

Ano, vymezit práva na konkrétním hypervisoru pro konkrétní uživatele/skupiny + vymezit, co vše smí a nesmí (zda mohou něco připojovat, zda mohou upravovat hw mašiny, zda mohou vytvářen nové apod.).
To všechno lze třeba v ESXi nastavit a je to plně bezpečné a znám lidi, co to využívají, protože poskytuji VM jiným firmám.
Druhou věcí je, proč bych měl řešit ACL na úrovni přístupu k hypervisorům? Proč bych měl skupiny odděleovat tak, že budu mít více fyzických serverů s hypervisory a lidi budu třídit tak, že jim budu dávat jen přístup k celým hv. To je podle mně mrhání (za předpokladu, že to zvládne jeden server).
Šifrování jako ochrana dat ok, ale v dost případech to také není možné, jelikož to ty app neumožňují :-/
To, že někdo pošle fake mail a vytahá si tak nějaké info díky hloupému uživateli nelze považovat za argument, aby se servery nezabezpečovaly.
Zdar Max

[Heron]

To všechno lze třeba v ESXi nastavit a je to plně bezpečné a znám lidi, co to využívají, protože poskytuji VM jiným firmám.

Ano, dělá se to tak. Plně bezpečné bych se neodvážil napsat o ničem. A už vůbec ne o uzavřeném produktu.

To, že někdo pošle fake mail a vytahá si tak nějaké info díky hloupému uživateli nelze považovat za argument, aby se servery nezabezpečovaly.

Já jsem to ale nepoužil jako argument pro to, aby se servery nezabezpečovaly. Já jsem to použil jako ukázku, že to celé je mnohem složitější a nelze si myslet, že pokud někdo nemá přístup na personální server, tak se k těm datům nedostane.

To jsou totiž dvě úplně odlišné otázky: nemá se dostat na server / nemá se dostat k datům. To se nedá zaměňovat. Pokud je cílem nedostat někoho k datům, tak se to musí řešit trochu jinak, než mu nedat přístup na server.

[Max]

Prvním krokem pro bezpečnost je zabezpečit fyzický přístup k HW, případně přístup k mgmt VM (o což se u hv starají ACL). Nikde jsem nepsal, že tím bezpečnost končí.
Bezpečnost OSS vs. closed source je nekonečné téma a vůbec bych s tím nezačínal.
Zdar Max

[MP]

Ve chvili, kdy je IT tech vice nez 2-3 polozek a jeste maji oddelene pravomoce (sprava VM, sprava hypervizoru, sprava backupu apod, audit) zacinate mit problem.

A napr. u develu, takze kdyz budou mit centralizovane devel prostredi, neni toto prostredi "produkcni"? Jak ale pak develu umoznite, aby si podle potreby z default vm/kontejneru generovali testovaci vm/kontejner bez toho, aniz by na ten hypervizor meli pristup?

[Heron]

A napr. u develu, takze kdyz budou mit centralizovane devel prostredi, neni toto prostredi "produkcni"? Jak ale pak develu umoznite, aby si podle potreby z default vm/kontejneru generovali testovaci vm/kontejner bez toho, aniz by na ten hypervizor meli pristup?

Nevím co máš na mysli centralizovaným devel prostředím. Prostě devel je devel a tam klidně dám lidem přístup, aby si vyrobili další virtuálku (hotový skript, klikátko, to je fakt jedno). Bude to oddělený hw, klidně jim dám přístup i na ssh hypervizora. Nevidím v tom problém. Produkci (to je to, kde jsou ostrá data klientů) to nijak neovlivňuje. Na produkci se instaluje hotový balíček aplikace.

Pokud by někdo měl pocit, že jedna skupina vývojářů by neměla vidět pod ruce druhé skupině (proč?), tak se ten devel rozdělí a každý skupina dostane přístup jen na svůj devel hw.

[Max]

Grafy jsou dobrý kvůli historii. Samozřejmě, je to jen maličkost, ale horší už je třeba správa ACL pro přístup k VM, jak už někdo poznamenal. Ano, někde to potřeba není, někde to potřeba je. A klikátka to mají. Další problém může nastat v případě pokročilějších požadavků na cluster jako takový (automaticky migrovat mašiny vzhledem k zatížení hypervisoru, vzhledem ke spotřebě atd.).
My zatím nic takového nepotřebujeme, ale dokážu si představit, že jinde ano.
Nerozporuji, že to bez klikátek nejde, jen někde jsou takové požadavky, že by nepoužití klikátek bylo kontraproduktivní.
Zdar Max

[Max]

Ještě mně jako příklad pro nasazení klikátek napadá captive portal pro virtualizaci stanic. oVirt to má, je to něco stejného jako citrix řešení, přihlásíš se na web portálu, kde máš plochu a svoje VM / aplikace. Po kliknutí na desktop se vygeneruje ticket, který se otevře v desktop klientovi a jsi na serveru. Vše se loguje, vše je centrální, klikací a jednoduché. Dále lze nastavit usínání VM po nějaké době nečinnosti, jejich automatické probouzení po přihlášení uživatele do portálu apod.
Prostě slušné all-in-one řešení, jen to zatím nefunguje stabilně, ale nic lepšího z OSS jsem zatím neviděl :-/.
Vím, že něco takového má IBM postaveno nad KVM, málem jsme do toho šli místo Citrixu, ale oni celou akci stornovali, protože tam našli nějakou chybu, kterou nechtěli řešit s další firmou a čekali, až vyjde oprava, což byl termín "nevíme, možná za pár měsíců"
Zdar Max

[Heron]

Grafy jsou dobrý kvůli historii.

Já nevím, asi jsem jinej, ale já provozní grafy nikdy nepotřeboval. Byl jsem několikrát přehlasován s tím, že se to (zabbix, cacti, munin a spol.) musí někam nasadit, tak se to tam nasadilo a vždy to dopadlo tak, že jsem zapomněl, že to tam vůbec je. Nikdy jsem to nepoužil. Zrovna toto řadím do kategorie věcí, které na papíře nebo na prezentaci vypadají dobře, ale v praxi jsou na nic. Pokud to někdo potřebuje, tak ať si to tam dá, no.

jen někde jsou takové požadavky

Otázkou je, zda ty požadavky vycházejí z reality, z marketingu*, z dezinformací**, z hlouposti*** atd.

*) Znám člověka, který kdykoliv jede na nějakou "snídani s", tak přiveze podepsanou smlouvu na nějaký strašně potřebný produkt o kterém včera ještě nevěděl.

**) Jistý IT pracovník u policie tvrdí (a je o tom přesvědčen), že i za OSS se platí a proto nevidí důvod proč nenakoupit MS produkty (což je samo o sobě dost zvláštní argument) a že oni na OSS stejně přecházejí, protože se vše přepíše do C#

***) Většina věcí jde dělat několika různými způsoby, je otázkou, zda je realizátor vidí.

Většinou je to nějaká kombinace všech předchozích a dalších vlastností. Když se bavím (většinou teda ve státní správě) proč je daná věc udělána tak a proč se koupilo to či ono, tak se buď odpovědi nedočkám (takže ti lidé vůbec nevědí, nebo vědí, že je to špatně), nebo mi řeknou nějakou kravinu. Velmi často (jako ten příklad s tím IT pracovníkem - bavíme se na úrovni přibližně policejního prezidia, nikoliv v nějaké zapadlé stanici v Horní Dolní) je dotyčný o své pravdě přesvědčen natolik, že si ji ani neověřuje a jedná podle toho.

Samozřejmě, to co píšu je můj názor a moje praxe. Pokud si někdo vyhodnotí, že je pro něj nějaké klikátko nebo nějaký produkt přínosný, proti tomu vůbec nic nemám. Jen jsem se toho vysvětlení nikdy pořádně nedočkal. (Samozřejmě, soukromá osoba mi nemusí nic vysvětlovat, ale od státní správy placené z mých daní bych vysvětlení očekával.)

[MP]

U tech grafu, jak bez techto systemu dokazete rozpoznat, ze den X cas Y doslo k vyrazne dlouhodobe zmene napr. na zatezi VM (souvisejici treba s novou verzi Z aplikace), aniz by se to projevilo na trigerech? Nebo mate v hlave u kazdeho systemu jeho standardni zatez v ruznych casech?

[Heron]

Nebo mate v hlave u kazdeho systemu jeho standardni zatez v ruznych casech?

Ano. Trochu mi to připomnělo situaci, kdy jsem byl před lety seřván za to, že někde není nastavené logování "dle rozkazu" (), teď je tam nějaký problém a že jsou moc zvědaví, jak to teď vyřeším (prostě to na mě chtěli hodit a vykoupat mě v tom). Měl jsem to opravené asi za 30s a logy, natožpak "dle zadání" jsem k tomu nepotřeboval.

Ne, nejsem geniální, nemám křišťálovou kouli, jen prostě vím, jak se systém funguje.

Zase, neříkám, že logy jsou na nic, to vůbec ne, logy jsou potřeba. Ale říkám, že pokud někdo neví, jak ten systém funguje, jak má fungovat, co je tam nainstalované apod, tak mu žádné logy na světě nepomohou. Základem je vědět, co je ten systém zač, znát ho.

[miker]

a taka otazka pre tych ktori maju viac skusenosti s proxmoxom

je mozne proxmox nasadit tak, ze pod nim bude bezat niekolko fyzickych masin? resp. ci je mozne aj distribuovat vykon tychto masin pre urcite VMhosty. Napr. VMhost1 bude vediet vyuzit vykon viacerych fyzickych masin ked bude potreba. Diky

[Max]

Vím, že třeba VMWare má DRS / DPM, který umožňuje to, že se VM přesouvá po nodech dle potřeb. Tzn., když jeden nod zahálí, tak na něj automaticky přesune nějakou VM, aby rozdělil zátěž. Nebo lze třeba na období, kdy nejsou služby tolik využívány (třeba přes noc), přesunout VM na méně hypervisorů, původní se odstaví, čímž se zvýší úspora energie.
Ale že by jedno VM běželo nad více hypervisory a z každého využívalo nějaké prostředky, o tom nevím, že by VMWare uměl. A myslím si, že to neumí ani ostatní, nějak si nedokážu představit předávání/sync dat.
Zdar Max

[Peter Golis]

Pokiaľ už niekto dorobil hypervízor do Plan9, tak to možné je. OP si zrejme myslí že napr Beowulf cluster môže byť nahradený virtualizáciou.

[Max]

Myslím si, že pleteš hrušky s jabky.
Výpočetní cluster je přecijen něco trochu jiného, než plně oddělené systémy / VM, které využívají přímého přístupu k HW (CPU i GPU).
Jinak Plan9 neznám, takže nevím, co má tak super, ale výpočetní cluster se sdílenými zdroji není problém ani na linuchu, viz : mpich
Zdar Max

[miker]

diky na ten mpich sa pozriem. Pripadne ma napada este http://www.rocksclusters.org

zatial moja predstava je taka, ze prepojenie tychto HW by bolo zabezpecene cez 10G ethernet (co je mozno stale malo). Cluster fyzickych serverov a nad nimi rozny pocet virtualnych hostov, ktore by vedeli vyuzit vypoctovy vykon viac serverov naraz podla potreby.

takze sme sa dostali od virtualizacie ku clusteru :)

[Max]

1) mpich je určen pro úplně něco jiného a neposkytuje tebou zamýšlenou službu.
2) rocksclusters neznám, ale dle popisu je to obdobné řešení : výpočetní clustery, takže úplně něco jiného, než o čem je řeč
3) zkus si schválně postavit jen nějaký storage cluster a uvidíš, že to je nejen složité, ale i s velkým výkonovým propadem, viz GlusterFS, Ceph, Scheepdog ...

Jinak většina virtualizačních clusterů se staví tak, že máš nějaký storage, ke kterýmu je připojeno více serverů/nodů. Všechny VM jsou tedy uloženy na jednom storage a všechny servery je vidí (nejčastěji se storage distribuuje přes iSCSI, FC, NFS). VM vždy běží jen na jednom ze serverů. Clusterem se pak rozumí to, že v případě pádu jednoho serveru přebere jeho roli/běžící VM druhý server. Lze to nastavit i tak, že pád jednoho serveru/nodu znamená výpadek jen pingu dané VM.
Dále lze jednodušeji dělat údržby hypervisorů, protože je můžeš odstavovat jak je libo a všechny VM poběží nepřerušeně.

Společným storage se může rozumět nějaký storage cluster (viz ten GlusterFS, Ceph, Scheepdog), nebo HW pole v podobě třeba NetApp. Tyto pole/storage clustery můžeš mít roztažený přes více lokalit, většinou právě asynchronně. Stejně tak ten hypervisor cluster můžeš mít přes více lokalit, je to ovšem náročné na rychlost a kvalitu linky(záleží, co je provozováno).
Troufám si tvrdit, že jsme docela velká firma, máme dvě dvě serverovny a mezi nima několik optických vláken a zatím to vypadá, že půjdeme cestou NetApp v obou lokalitách + asynchronní sync mezi nima a nad tím ESXi cluster
Zdar Max

[miker]

a je pre vas dolezity vypoctovy vykon?

u nas bezi python software s ktorym sa spracuvava velky objem dat. Takze podla vsetkeho virtualizacia nieje idealna (ale proxmox pouzijeme na klasicke sluzby ako wiki, zabbix a nejake web appky). By ma celkom zaujimal cluster dvoch fyzickych masin, ktorych vypoctovy vykon by vedeli vyuzit nase python aplikacie ako som spominal uz vyssie. A medzi nimi 10G presietovanie (niesom si isty ci by 10G postacovalo). NAS uz nakonfigurovany na 10G + RAID 10 pre rychlost.

kazdopadne k proxmoxu diky za informacie, uz ho v podstate vyuzivame.

[Peter Golis]

Ja nie, zadávateľ poslednej otázky si to pletie. V Plan9 bolo možné zdieľať prostriedky viacerých strojov (RAM/CPU/...) tak, ako keby sa jednalo o jednu mašinu ktorej výkon bol približne súčtom nodov. A to sa akosi v dnešných bežných OS alebo Hypervízoroch nedá.