distribuce vykonu mezi stroje - cluster/grid

[Michal Dobes]

Tomáš Koželuh napsal(a):
> Přesně tohle umí VMware ESX, ale cena je hodně vysoká...

Ano, přesně toto umí VMware ESX a dá se  podobného chování
dosáhnou pomocí VMware server v kombinaci s Red Hat Cluster Suite.

Nástin řešení:
Předpokladem je, že na všech uzlech bude stejná výchozí
konfigurace virtuální sítě do VMware.
Při startu systému se normálně pustí VMware server s lehkou
úpravou, která před spuštěním odmaže všechny registrované virtuály,
takže VMware server se pustí, jen si nakonfiguruje virtuální síť,
žádný virtuál neběží a čeká.
Na všech uzlech je samozřejmě běžící cluster suite a sestavený
cluster. V cluster suite jsou vytvořeny služby, kdy pro každý
virtuální stroj je jedna služba. Tato služba fakticky dělá to,
že zavolá při startu vmware-cmd -s register <cfg virtuálu>
a následně vmware-cmd <cfg virtuálu> start.
Pro zastavování služby daný skript volá patřičně stop hard a
unregister, pro kontrolu běžící služby se dá dělat spousta věcí,
nejjednodušší vmware-cmd ... getstate.
V cluster suite si vytvořím volné failover domény a pomocí nich
staticky rozmístím virtuální stroje na jednotlivé fyzické, tak
to poběží v případě, že všechno bude OK. Když nějaký fyzický
stroj chcípne, tak se to přemigruje samo jinam (dá se částečně
ovlivnit kam) a po opětovném naběhnutí se to vrátí zpět.

Toto řešení funguje systémem activ/activ/cold-failover, takže
při selhání fyzického stroje je výpadek cca do minuty daného
virtuálu, než to přejde jinam a vše najede.

Je potřeba dořešit ještě otázku sdíleného disku, ale i tady
se dá vymyslet spousta řešení za levno. Já bych třeba volil
vzít 20 kKč a koupit si na ebay.de z Německa pár fibre channel
polí i s FC kartami a switchi (sice to bude za tu cenu jen 1
nebo 2 Gpbs, ale mohlo by to stačit) second hand i s náhradníma
kousky to skříně a mít zlatý klid.
Jiná varianta je vzít dva stroje bokem (na nich není cluster suite),
které budou dělat diskové pole, zhruba tak, že oba budou stejné
s hoooodně velkým diskem, tyto dva stroje budou tento disk mezi sebou
synchronizovat pomocí drbd v master-master konfiguraci obousměrně přes
vyhrazenou bondovanou linku 2x 1 Gbps. Tento prostor budou exportovat
ven pomocí iSCSI nebo možná v tomto případě i lépe pomocí gnbd do všech
členů clusteru. GNBD bych upřednostnil proto, abych mohl použít jeho
vestavěný I/O fabric fencing pro nouzové vytlačování chcíplých členů
clusteru od sdíleného diskového prostoru, protože SCSI reservation
v ietd moc nefunguje. Fabric fencing samozřejmě jen jako nouzová záloha
druhého řádu, primární musí být power fencing.
Do každého členu clusteru se naimportují disky z obou diskových uzlů,
je třeba pohlídat, aby to dostalo správné UUID na SCSI, aby fungoval
multipath  pro rozdělování zátěže a failover při chcípnutí jednoho
diskového serveru. Nad takto importovanými disky přes multipath udělat
diskový prostor do kterého se udělají oddíly pomocí clvm2 a každý
virtuální stroj bude mít svůj oddíl s daty a v rámci konfigurace služby 
v cluster suite se vždy daný oddíl přimoutuje ke stroji, kde to poběží.
Jiná  varianta tam nacpat GFS a mít to současně připojené ke všem členům
clusteru a nepřemoutovávat disky dynamicky jako součást migrace
virtuálů, ale má to i své slabiny. Tady nutnost mít současně přístupné
data všude nevidím, takže bych to GFS nekomplikoval.

Pak je třeba vhodně dořešit propojení ethernetů (jen spotřeba síťovek
je cca 80 kusů, pokud má jít o 20 strojů), napájení přes PDU switche
(nebo použití vestavěných management karet v serverech, pokud tam jsou),
přívody elektriky ze dvou trafostanic, všechno napájení zdvojeně udělat
dle SELV zásad, abych nemusel cluster vypínat, když se mi zamotá někdo
do elektriky, to naštve (takže typicky vše napájeno přes -48V
stejnosměr) a tunu dalších blbostí, aby to mělo trošku úroveň. :-)

M.