Když proxmox dostane krámy

Dnes se mi stala nepříjemná věc. Restartoval jsem 2 mašiny a po restartu už to v quorum a v proxmoxu řvalo, že ty mašiny jsou odpojeny. Co teď? Pvecm status vypisuje, že je v clusteru jediná node a to je ta, která vše kontroluje, restartované mašiny jsou pryč. Po delším googlení jsem došel k následujícímu řešení, které Vás však může připravit o veškerou konfiguraci, či virtuálky, takže pozor! Na jednotlivých mašinách (mimo kontrolní, ze které cluster spravujete):  // ikdyž jsem to na kontrolní virtuálce pak udělal taky a v pohodě.

systemctl stop pve-cluster
systemctl stop corosync
pmxcfs -l
rm /etc/pve/corosync.conf
rm /etc/corosync/*
ps aux | grep pmxcfs
kill -9 $(pgrep pmxcfs)
systemctl restart pve-cluster

A potom mi šla mašina znovu přidat do clusteru příkazem: pvecm add <název čip IP adresa kontrolního stroje, kam chci fyzickou mašinu přidat), pak už to vypíše něco ve smyslu:

pvecm add dns_název_kontrolního_stroje
copy corosync auth key
stopping pve-cluster service
backup old database
waiting for quorum...OK
generating node certificates
merge known_hosts file
restart services
successfully added node 'název_stroje' to cluster.

zdroj zdroj2 zdroj3

Nepodporované síťové karty na Centos7 (Sun Fire X2200m2)

Ono to podle posledních článečků vypadá, že mám nějakou pifku proti Red Hatu, jenže to není pravda. Mě se prostě jen dějí podezřelé náhody, které mě nutí k zamyšlení, proč se tak děje. Doteď jsem nějak nepochopil, proč by Red Hat odebíral ovladače hardwaru z jejich distribuce.

Teď k tomu co se mi stalo.

lspci mi ukazuje na centosu7, že má stroj 4 síťové karty. Bohužel v ifconfig -a či ip addr show vidím jen 2. Kam se poděly ty zbývající 2? Odpověď je jednodušší, než byste mohli čekat. Mám asi moc staré síťové karty, ačkoliv jsou gigabitové a Red Hat si prostě usmyslel, že už je nebude standardně podporovat.

Mé řešení v mém případě pomohlo na mašinách Sun Fire X2200 M2:

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
#Pokud byste měli Realtek 8168, tak:
yum install kmod-r8168 -y
#Pokud máte síťovky od Nvidie, tak:
yum install kmod-forcedeth -y

Pokud to nepůjde jinak, tak rebootnete stroj a po rebootu už síťovky uvidíte všechny.

zdroj1 zdroj2

 

 

Zahoďte oVirt, je tu Proxmox ver. 4.x

Za tenhle článek mě Red Haťáci sežerou zaživa, na druhou stranu, než se pustím do Proxmoxu, popovídám Vám o oVirtu.

OVirt je skvělá technologie, založená na KVM (kernel based virtual machine), která umí live migraci, High-availability (vysokou dostupnost, dále jen HA), podporuje jak GlusterFS, tak namapování nejrůznějších diskových polí, umí snapshoty a je to prostě super technologie, o které jsem psal i ve své diplomce. Ovirt vychází z RHEV (Red Hat Enterprise Virtualization), máte na výběr si to buď rozjet na Centos 7, nebo Fedora Server, anebo si zkompilujete zdrojáky na Debianu/Ubuntu, což spíš nedoporučuji, protože oVirt je masivně podporovaný a používaný na Centosech a Fedorách, ale zatím jsem neviděl jedinou funkční bezproblémovou instalaci oVirtu na Debianu či Ubuntu. Parametricky je oVirt úplně vynikající technologie, která poměrem cena/výkon (je zdarma), nabízí to stejné, co konkurenti nabízí v cenové kategorii „platím jako mourovatý“. Ke zprovoznění oVirtu potřebujete 2 fyzické servery a aspoň 1 virtuálku. Občas se na internetu setkávám s pojmem „hosted engine“, kde honíte virtuálku, která řídí ty 2 fyzické mašiny uvnitř clusteru.

No a teď moje zkušenosti s oVirtem. Ještě jednou píšu, oVirt je vynikající technologie, která se řídí myšlenkou, že oVirtem spravujete v podstatě celý server. A už tady oVirt u mě naráží. Já chci virtualizační technologii, ať si ona virtualizuje, ale ať mě jako admina nechá možnost změnit něco v síťových připojeních serveru a ať ona vidí jen síťové mosty, které ji řeknu, že má vidět. Dále chci mít server pod kontrolou i jinačí možností, než jen přes rozhraní oVirtu a to se tu přesně nedoporučuje. Takže ikdyž jsem byl z oVirtu nadšený, stejně tak jako jsem byl předtím nadšený z OpenStacku, než mi došlo, že na správu a údržbu OpenStacku potřebujete celý team adminů a občas i nějakého programátora, který Vám ohne třeba síťová rozhraní, tak jak vy potřebujete, tak u oVirtu si uvědomuji, že jsem už na začátku dělal jednu chybu. Nevzal jsem si filosofii oVirtu a neporovnal to s tím, jaké víry ohledně Virtualizace jsem založený já sám.
Další co mi tak trošililinku vadí na oVirtu je fakt, že já musím mít ideálně server spárovaný s APC nebo napojený na ILOM, IMM či jiná management rozhraní serverů, ze kterých oVirt čerpá data pro HA a když to tak neudělám, tak mi ten oVirt zkrátka nezaručuje, že bude fungovat zcela bezproblémově s HA (tedy HA bude fungovat omezeně až po několika minutách viz zdroj2). No a teď ale k tomu, co si myslím, že já dělám špatně, když jsem kdykoliv nasazoval oVirt. Měl jsem si vždycky vzít bare metal instalační ISO a nainstalovat oVirt tak jak je rovnou přes něj a jsem přesvědčen, že by se mi neprojevovala většina problémů, které se mi projevovaly tehdy, když jsem oVirt instaloval dodatečně do Centosu 7. Další co mi vadilo na oVirtu byl web management. Já mám rád příkazy, ale jediné, kdy jsem ovládal virtualizační technologií příkazy bylo jen tehdy, když jsem tomu prováděl nějaký ruční update, nebo když jsem to chtěl nějak zautomatizovat přes webové rozhraní, aby se mi vytvářelo jedním kliknutím třeba desítky virtuálek a na to jsem si vygooglil příkazy, ozkoušel a za 14 dní zapomněl. Na oVirtu je web management jen taková nouzovka, která nabíhá pomale, má fakt docela mizernou odezvu a občas jsem měl strach na něco kliknout v obavách, že bych tím tu technologii rozbil, což se mi i parkrát na testovacím clusteru stalo. Potom se mi třeba stávalo, že mašina, která se mi „bugla“, prostě nešla z clusteru odebrat, takže jsem musel odebrat i nějaké další věci, nebo zrušit i celý cluster a povytvářet znovu a zkrátka jsem s tou technologií celý život spíš bojoval a přemlouval, abych ji dostal tam kam potřebuju, než že by to intuitivně fungovalo bez problémů tak, jak od virtualizační technologie očekávám (a to už mi rukama prošel VMware, Xenserver, KVM, VirtualBox, LXC kontejnery, OpenVZ, Xen a další…). Teď představte, že se vám něco takového bugne na produkčním clusteru? To se prostě nesmí stávat a z té nejistoty, kterou ve mě chování web managementu oVirtu vytvářelo, jsem z něho nakonec upustil (a nejen proto). Byla to verze 3.6 a já doteď nenávidím VDSM za to, jak mě, administrátora mlátí přes prsty. Je ale pravda, že sami Red Haťáci mi řekli, že web management je nouzovka, že oVirt se stejně ve většině případů ovládá přes příkazy, což je spolehlivé (ano, v tom jim dávám za pravdu) + s přihlédnutím na filosofii oVirtu jim musím zase dát za pravdu, že není chyba v oVirtu, ale v mém výběru virtualizační technologie vzhledem k mému smýšlení, ačkoliv parametricky splňuje vše, co administrátor potřebuje. Je to prostě jako když si ženská vysní nějaké úžasné boty, úplně se do nich zamiluje, ví že parametricky ji všechno kolem těch bot vyhovuje, cena, velikost bot, kvalita materiálů apod… Bohužel až druhý den, co nosí boty zjistí, že z nich má odřenou patu a že ji taky trošku tlačí palec. A to je přesně můj případ. oVirt je fajn, umí vše dle parametrů, co admin očekává od virtualizační technologie založené na KVM, která umí HA a web management, ale zkrátka mě v oVirtu tlačí palec a mám z něj odřenou patu.

Red Haťáci, promiňte, mám vás rád, děláte dobrý produkty, oVirt má vynikající budoucnost, hodně agresivně se vyvíjí a neustále přibývají nové vychytávky, ale bohužel, pokud chci nějaký cluster, moje následující požadavky na cluster jsou:

1) Ta technologie musí být tak primitivní a jednoduchá s ideologií „Keep it stupid simple“, abych se na ni mohl spolehnout i v časech updatování, pádu stroje, kritických situací apod…

2) Musí to umět vše co potom chci tak, aby se mi to nesypalo pod rukama, nepsalo to stovky warningů, nebo errorů

3) Já jsem tady administrátor, ne Virtualizační technologie, která mě bude házet klacky pod nohy a dělat si svoje a sahat mi do řízení serveru. Chci virtualizační technologii, která virtualizuje, vidí si jen to minimum, které potřebuje k virtualizaci (jiné stroje, virtuální bridge, virtuálky, disková pole, gluster fs atd…), ale už mě nepeskuje za to, jak si upravím nebo přidám vlany, vlany do trunku, bondingu, co nahážu do firewallu apod…

PROXMOX ver 4.x

O proxmox jsem vždycky zavadil, na jednu stranu jsem viděl, že je to „free“ a na druhou stranu jsem viděl subscription a ceny předplatné podpory. Slovo bare metal je u mě na single strojích spíš sprosté slovo kvůli ztrátě jedné veřejné IP, která padne v tu ranu pro management a taky nešťastnost updatů některých bare metal řešení. Tam kde použiju bare metal virtualizaci, tak jsou střední firmy, které si mohou nakoupit spoustu železa, mají dostatek IP adres, mašiny jsou schované za hardwarovým firewallem, nebo vůbec za nějakým spolehlivým firewallovým řešení, které chrání celou firmu a často se setkávám s tím, že na bare metalu mi najednou nepůjde dodat tu napojení na nagios, plugin pro munin, zkrátka přicházím o všechny výhody, které jsou spojené se svobodou plnohodnotného operačního systému, na kterém běží virtualizační technologie.

A Proxmox je přesně taková technologie, jakou jsem dlouho hledal. Je totiž:

1) Téměř nerozbitná
2) Tváří se jako Bare Metal, ale je to Debian s funkčním apt-get balíčkovacím systémem
3) Virtualizační technologie si řeší virtualizaci a jakékoliv další balíčky si do systému nahodíte, to už je na Vás. Stejně tak Vás neplácá proxmox přes ruce, když si změníte něco v konfigurácích.
4) Je zdarma či open-source
5) Podporuje HA, Live migraci, snapshoty, GlusterFS a jako bonus vnímám podporu ZFS a RAIDZ/RAIDZ2/RAIDZ3, pokud tedy máte levnější železo, můžete si tam rozjet velmi kvalitní softwarový raid založený na ZFS RAID.
6) A má webové rozhraní, kde si naklikám co potřebuji s integrovanou konzolí, která se mi zatím ani jednou nebugla, vše je extrémně rychlé, běží to na všech prohlížečích a nejeví to známku nějaké unavenosti, nebo problémů. Když se objeví problém, dá mi to najevo, vyplivne mi to errorovou hlášku, vložím ji do googlu a hned vím řešení.
7) Je to tak intuitivní, že ani nemusím studovat dokumentaci a rozběhám si během chvíle cluster, HA, cokoliv chci dodat dalšího, to si tam dodám, ale nic se v tom nesype.
8) V případě, že se to vážně rozsype, musím být schopen z technologie vytáhnout virtuálky a jejich image. Když jsem záměrně rozbil oVirt s GlusterFS, abych tohleto zjistil, vytáhnout se mi z toho virtuálky jen tak snadno nepodařilo.
9) Musí to umět jak local datastore, tak replicated, tak network datastore

Jediná velká nevýhoda Proxmoxu, kterou třeba nemá nejnovější Xenserver je, že na funkční HA cluster potřebujete 3 stroje a je jedno jestli ty 2 jsou fyzické a ten třetí je virtuálka, která ty 2 fyzické stroje řídí, ale potřebujete zkrátka 3 stroje a to znamená, že se Vám to ročně na provozních nákladech prodraží a to je velká škoda. Xenserver narozdíl od toho zvládá fungovat na 2 strojích s HA redundancí.

Další výhoda Proxmoxu (pro mě) je ta, že má IPtables a nemá FirewallD. FirewallD je doménou zejména RedHatích produktů, tedy Centosu, Fedory. Nikde jinde jsem FirewallD snad neviděl, ubuntu ho nemá, debian ho nemá, arch linux taky ne, gentoo nikoliv, zkrátka je snazší napsat, které distribuce ho mají, než které ho nemají. Další nevýhodou je kratší životní cylus Debianu, který je zhruba +- 2 roky, u LTS distribuce je to zhruba +- 4 roky. Ale protože ty virtuálky

No a teď konečně k ukázce virtualizační technologie a jejího chování.

1) Běžná ukázka, instalace jedné virtuálky uvnitř jednoho ze strojů:

2) Ukázka Live Migrace

3) Ukázka snapshotů a revertnutí

4) Ukázka zafungování HA redundance

5) Jak to vypadá, když odpojený fyzický stroj zase zapojíte do sítě

 

zdroje oficiální dokumentace a mé osobní poznatky + rozhovory s kolegy, které tímto zdravím

zdroj2 zdroj3 zdroj4

Error: file not found. Entering rescue mode … Grub rescue>

Velmi nepříjemná situace, kterou zjistíte, až rebootnete stroj. V tom se zásadně liší Windows a Linux administrátoři. Zatímco Windows administrátoři se těší, až to po restartu začne konečně fungovat, Linuxoví administrátoři si začínají okusovat nehty, protože když restartujete třeba po 3 letech, tak už si nejste úplně jistí, jestli ta mašina fakt nabootuje bez problémů.

Příkazem ls zjistíme, jaké oddíly máme k dispozici. Pokud nepoužíváte RAID ani LVM, tak to bude jeden z disků typu:

(hdČíslo,číslo)

Na to pomůže tento návod.
Když nevíte, co ta mašina má (jestli raid má či nikoliv), tak můžete klidně zkusit (hd0,msdos1) atd… vyzkoušíte všechny možnosti, ono vám to stejně bude řvát, že to nejde (file not found, nebo unrecognized device string apod…) viz odkaz.

V případě /boot partitiony na /dev/md0 (pokud je to třeba v SW raid 1):

set root=(md/0)
set prefix=(md/0)/grub
//pokud by to bylo na běžném diskovém poli s neodděleným adresářem /boot tak set prefix=(md/0)/boot/grub
insmod normal
normal

(po odkliknutí normal to začne bootovat do linuxu)

Po náběhu stačí nadhodit následující kletbu (bez těchto příkazů, by Vám to při příštím restartu opět naběhlo do grub rescue!) :

update-grub
grub-install /dev/md0

když se objeví error:

debian grub-install:_ error: will not proceed with blocklists

grub-install: error: diskfilter writes are not supported

V mém případě to řvalo errorama a warningama, takže:

grub-install --target=i386-pc --force /dev/md0

zdroj1 zdroj2 zdroj3 zdroj4 zdroj5 zdroj6