Proxmox VE

[hapi]

řešim tu teď jednu věc... přidal jsem jednomu virtualu druhej disk, pak odebral a teď se nedá vymazat. Něco jsem přehlídnul?

[sub_zero]

tenhle problém je i na XENu. Pokud uděláš druhej disk (a je jedno jestli iSCSI, NFS, SMB nebo přímo k mašině), tak po odpojení nebo smazání mašiny ten disk už nedostanu pryč. Jediná možnost je zazálohovat virtuální mašiny a reinstall hostitele

[hapi]

myslel jsem virtualni disk. Mám debiana ve virtualu kterej má virtualni disk. Přidal jsem mu pokusně druhej virtualni disk místo virtuální cdromky. Pak jsem ten virtualni disk odpojil od virtualniho debiana ale nedá se z proxmoxu smazat. Prostě tam na disku ten virtualni disk smrdní a nedá se nijak smazat přes gui.

[hafieror]

Také máte problémy s webovým rozhraním, že vytuhává? Přestane reagovat a rozjede se až po nějaké blíže neurčené době, kterou většinou nevydržím a zavřu to a otevřu znovu. Stejné chování Chrome i Firefox.

[zdenek.svarc]

Také máte problémy s webovým rozhraním, že vytuhává?

Jaká verze PVE? Jak jsem psal v druhém příspěvku v tomto vlákně:

"2) Občas chyby v UI (špatné překreslení, prázdné hodnoty). Týká se i 2x."

Bohužel se to občas stává.

[hafieror]

Verze 2.1-1

Jinak zatím spokojenost.

[hafieror]

Pokud někdo používáte proxmox jako Two-Node High Availability Cluster viz http://pve.proxmox.com/wiki/Two-Node_Hi ... ty_Cluster můžete mě sem prosím dát config /etc/pve/cluster.conf ?

Nějak ho nemůžu srovnat tak aby to prošlo, stále mě to hlásí "config validation failed: unknown error (500)"

[rsaf]

Two-node HA cluster jsem celkem bez problemu rozjel podle nejakeho videa - disky byly přes DRBD.

Zajímalo by mě, jestli někdo takový cluster provozuje prakticky a s jakými zkušenostmi. Moje představa:
2x DELL PE2950, každý 2x4core Xeon, 64GB RAM, 6x GE LAN, v kazdem serveru by bylo 6x1TB SATA HDD v RAID10 (3TB použitelná storage na každém serveru)
2x GLAN bude pro DRBD + pro cluster komunikaci, propojeno napřímo (porty v bodnu, balance-rr)
2x GLAN bude pro produkční připojení do sítě (BOND do dvojice switchů ve STACKu)
1x GLAN bude pro management, live migraci... (připojeno do switche)
1x GLAN bude pro QUORUM DISK (pokud ho vůbec bude potřeba; zvažoval jsem, že by jako QUORUM sloužil třeba ALIX s 3xLAN a na něm vsdílený NFS nebo iSCSI disk...)

Co si myslíte o výkonu storage v tomto řešení? Ty SATA disky byť v RAID10 nejsou žádný zázrak, dost si ukrojí DRBD
Má někdo zkušenost s PROXMOXem + DRBD + FlashCache? Zvažoval jsem do každého stroje 1 nebo 2 SSDčka, do těch dellů bych asi použil tento (http://www.alza.cz/axago-pces-shr-d457460.htm) řadič protože napřímo to není kam připojit (a navíc ten řadič elegantně vyřeší umístění těch SSDček).
Bohužel jsem nikde nenarazil na to, že by to někdo zrovna takto provozoval...

[Majklik]

Nu, Proxmox nepoiužívám, ale podobné konfigurace mám v provozu, kde je linux (dle stáří instalace CentOS5/6/7) dva uzly v HA clusteru a nad tím virtuály buď v KVM nebo kontejnery, dneska už LXC. Takže je někde řešen sdílený disk pomocí DRBD, někde jsou sdílené SAS/FC disková pole a teď po novu testujeme replikaci lokálních disků pomocí GlusterFS (jako náhrada za DRBD).
Tak to vezmu pozpátku...

Quorum disk - musí to být blkové zařízení, takže nelze NFS/Samba/Gluster, ale jen případně to iSCSI. Jeslti je nutný záleží jak máš řešen fencing. Pokud bude použito například externího APC Powerswitche (nebo dvou, pokud používáš duální napájení), který serializuje přístup a nedovolí, aby oba uzly se mohly vypnout naráz, tak ho nepotřebuješ. Pokud chceš vypínání řešit přes IPMI, DRAC a podobné, tak si musíš silně vyhrát s tím, aby nemohlo dojít k současnému vypnutí obou strojů vzájemě (několikrát jsem v praxi už zažil), takže toto řeší quorum disk, když se správně načasují akce, aby bylo deterministické vypínání. Jiná metoda je, že fence agentům vnutíš timetouty tak (pokud to podporují), aby v rámci určité naděje nemohl být příkaz k vypnutí poslán naráz. Pokud chceš používat IP tie breaker, tak qourum disk potřebuješ také (pokud daný uzel ztratí IP spojení s defualt bránou, tak se ma zastavit a předat vše na druhý uzel, u novějších verzí clusteru s pacemakerem to řeší checking objekty a quorum disk nepotřebuješ a ani není podporován).
Quorum disk mám použit všude, kde o něco jde, ale tam je použito i rozumné duální diskové pole, z kterého ty virtuály jedou (takže ztráta spojení s quorum diskem i znamená, že uzel přišel o diskové pole a má jít k zemi).

Live migraci nemusíš dělat přes ten vyhrazený kabel, pokud se má migrovat jen mezi těma dvěma uzly, tak stejnou spojkou jak pro DRBD.

DRBD šlape relativně OK, ale nepočítej s tím, že bude rychlejší přes ten bond s balance-rr. To bude pravděpodobně pomalejší, jak když použiješ active backup nebo 802.3ad. Bohužel. Vyvolává to víc problémů, jak užitku. Pokud třeba vezmu dva 10 Gbps porty a udělám bond balance-rr, tak tím spojem nedostanu při migraci virtuálů víc, jak cca 4 Gbps, pokud to jede v 802.3ad, kde to jde fakticky jen jendou linkou, tak to jede 9 Gbps. u DRBD i GluterFS replikace je to stejné. Takže pokud chceš větší replikační rychlost, tak buď 10 Gbps ethernet nebo dneska se z pár šupů dají koupit Infiniband karty, takové dvě dovuportové IB karty s duálníma 20 Gbps porty a propojovací 3 metry metalické CX4 kabely dohromady možná pod 7 kKč na ebay.uk a máš 20 Gbps linku. Navíc mající hardwarové RDMA, které dneska už umí i DRBD8.4 použít (transport typ SDP tomu říkají), taktéž KVM umí migraci přes RDMA a trvá pák desítky milisekund nebo po novu i mikrosynchronizace, takže podpora fault tolerant systémů. Přes infiniband funguje i normální TCP/IP (přes IPoIB modul), takže i cluster komunikace jde takto poslat. Nové Infiniband karty jsou už 40/56 Gbps na QSFP, většina výrobců ti dodá rovnou se serverem, stojí cca jak 10 Gbps ethernet (drahé jsou IB karty softwarověvě přepinatelné jako 40 Gbps IB nebo Ethernet). Nicméně infiniband svět, zvláště point-point propojení, je svět pro otrlé.

Neděllal bych z toho RAID10. Udělal bych normálně 3 ks RAID1 polí, měl nad nima 3 DRBD disky a každé to pole syncoval zvlášt. Pokud nad tím chceš pustit hromadu virtuálů, bude to tak rychlejší na IO, jak když to slepíš dohromady na RAID10. Váýhoda i je, když ti nějaký ten DRBD disk padne, tak aspoň něco pojede. SATA nemám, mám to všude na SAS 15 krpm diskách, ale to s tím RAID10 kontra RAID1 bude stejné pro oba.
Navíc, pokud to uděláš jako dva drbd disky, tka budeš mít mezi servery dvě TCP/IP spojení otevřená, když si dobře zvolíš TCP porty a uděláš ten bond jako 802.3ad s L4 politikou, tka dosáhneš, že každý drbd disk ti pojede sync přes jeden Gbps port v tom bondu (a při zdechnutí daného propoje pojedeš tím dalším).

[Majklik]

Ja vychazim z VMware, kterej provozujeme v HAcku. Tam mam napr 2 hosty, na kazdym 20 masin + k nim jsou pres FC pripojeny 2 pole. A pokud budu napr potrebovat provest upgrade z VMFS 3ky na 5ku, tim padem musim presunout vsechny vmdk z jednoho pole na druhy, udelam to za provozu. Coz teda jestli dobre chapu Zdenkovo objasneni, ze Proxmox pracuje s masinama jako celek, tak to asi mozny neni. Momentalne zkousime XEN 5.0.6 od Citrixu, ale ten ma s timto taky problem.

Sice trochu staré, ale pro doplnění. Tohle není starost vrtualizační vrstvy v linuxu, tohle dělá bloková. Pokud nejsem blbej a používám LVM, tak ten toto umí - normálně za chodu přesunout běžící systém z jednoho disku na druhý. Té virutálizaci je to jedno, pokud jako úložiště pro virtuál použije soubor na souborovém systému, který je položen na LVM. Stejně tak, pokud virutál přímo používá LVM oddíl jako virtuální disk (což je rychlejší). Jde takto přesunout za chodu a vyměnit komplet disky v serveru, včetně toho, z kterého se startuje systém - několikrát děláno.
V návaznosit na předchozí HA příspěvěk - trošku se to komplikuje, když je takový LVM disk sdílen naráz mezi vícero servery, když je LVM disk vytvořen jako clusterový, ta si s tím starší varianty pvmove neporadily. Bylo nutno to dělat tak, že LVM disk ležící na fyzickém disku A se online rozšířil na mirror, kdy LVM disk leží naráz na A i B, počkat na sync a pak provést konverzi na jednoduchý disk, kdy se disk A odebere. Fakticky interně pvmove to dělá stejně, jen automatizovaně. U clusterového LVM jsem to musel dělat ručně. I když u posledních verzí už to umí asi i pvmove nativně, pokud v clusteru běží cmirror služba.