Nu börjar det bli intressant och lite imponerande, faktiskt. Oracle har ställt samman en i mina ögon väldigt komplett och kompetent variant av Xen och i enlighet med GPL släppt den fri tillsammans med ett väldigt yxigt webb-gränssnitt (OVMM). Oracle erbjuder alltså en (kostnadsfri!) egen lösning på high availibility för servrar och VM i en kombination av OVS och OVMM. För att undvika single point of failure så kan man dessutom clustra OVMM med Oracle’s Clusterware som man ”får” om man prenumererar på Oracle:s uppdateringar för Oracle Unbreakable Linux:ULN (Unbreakable Linux Network). Detta kostar kring en tusenlapp per år och är något som jag kommer att investera i. Senare 🙂
Vill man däremot inte använda OVMM så blir det genast svårare att dra nytta av allt det goda som Oracle har packat med i OVS. Jag har den senaste tiden lagt ner mycket tid och engagemang för att hitta (och försöka att få fungera!) ett bättre GUI för att hantera servrar och VM men de flesta faller på att de inte klarar av att dra nytta av OVS inbyggda möjlighet till clustring. Dessa GUI utgår iställer från att man redan har en central NFS eller iSCSI baserad lagringsplats att lägga VM på för att kopiera dessa till lokal hårddisk när ett VM startas på en server. Det är inte såhär OVS fungerar och jag måste säga att Oracle har skapat en mycket fiffig och elegant lösning på detta behov när de bakade in en annan av sina produkter: OCFS2 1.4.7.
OCFS2 är ett klustrat filsystem som kan hantera samtidig åtkomst till filer från flera klienter. Det är till skillnad från Samba ett filsystem och inte ett nätverksprotokoll, med andra ord kan flera servrar samtidigt ha samma partition mountad och låta processer / program komma åt filerna utan att filsystemet blir korrupt. Skulle man göra samma sak med en partition formatterad för Ext2/3/4 eller NTFS, mfl. som ju inte klarar av att dela partition mellan flera datorer så skulle filsystemet krascha ganska snabbt. OCFS2 är gjord för detta men det är inte alldeles enkelt att på egen hand sätta upp ett OCFS2 baserat klustrat filsystem. Här kommer då det fina och som är ännu en anledning till att gilla OVS: OVS är förberedd för enkel handhavande och användning av OCFS2.
I mina försök att ”tämja” OVS till att samarbeta med andra GUI så lärde jag mig hur saker o ting fungerar, nämligen att nästan alla av dessa kräver att det installeras en liten klient på varje server. Klienten används för att GUI:t ska kunna styra servrarna och hämta statistik och föga förvånande har OVMM en egen klient (ovs-agent) som installeras automagiskt i samband med installationen av OVS. Jag började med att gå igenom de script som används i samband med konfigurering av ett SR för OVS, dvs. följa metoden för att sätta upp ett OCFS2 cluster i OVS som senare används av OVMM för att tillhandahålla HA och migrering av VM.
Det visade sig att mycket av magin ligger i ovs-agent klienten som installeras på varje OVS server och att OVMM mer eller mindre ”bara” är ett skal med egen databas som är väldigt beroende av ovs-agent! Det är riktigt enkelt att sätta upp en gemensam SR på en central lagringsplats och att få igång clustret är inte mycket svårare. Oracle har lagt ner en hel del jobb på att få detta att bli smidigt!
Börja med att skapa ett LUN på SAN:et och gör det tillgänglig för alla servrar som ska ingå i klustret. Formattera LUN:et med OCFS2, det finns beskrivet här, fortsätt enligt beskrivningen här nedan när partitionen är formatterad.
Skapa en ny SR (Storage Repository) på partitionen som är formatterad med OCFS2 och som är tillgänglig via SAN:et på alla servrar som ska vara med i clustret:
# cd /opt/ovs-agent-2.3/
# utils/repos.py -n /dev/mapper/OVSp1
När den är klar återkommer den med UUID för SR:et, denna kan även visas med följande kommando:
# utils/repos.py -l
Gör så att SR:et blir en ”root SR”, dvs. det är här som OCFS2 kommer att lagra sin hearbeat information:
# utils/repos.py -r <UUID>
Skapa en VIP (virtuell IP) adress som ovs-agent bollar mellan servrarna i SP:n (Server Pool) genom att först kontrollera att VIP adressen är i samma subnät som serverns IP adress och därefter registrera VIP:
# export PYTHONPATH=/opt/ovs-agent-2.3
# python -c ”from OVSSiteRMServer import *; print validate_master_vip(‘192.168.10.10′,’192.168.10.33’)”
# python -c ”from OVSSiteRMServer import *; print register_master_vip(‘192.168.10.10’)”
# python -c ”from OVSSiteRMServer import *; print get_master_vip()”
Registrera första servern i SP:n som Master (detta anges genom att markera servern som ‘site’, annars ‘xen’ eller ‘utility’), lösenordet (”oracle”) är det som sattes för ovs-agenten när OVS installerades:
# python -c ”from OVSSiteRMServer import *; print register_server(‘server1.mindomän.com’,’site’,True,’oracle’,'<lösenord>’)”
Registrera andra servern som en ‘xen’ server eller som en ‘utility’ server, skillnaden är att en ‘utility’ server sköter migreringar förutom att den som en ‘xen’ även tillhandahåller VM. Det går att registrera upp till 16 servrar i ett cluster, men inte fler än vad som angavs när partitionen formatterades med OCFS2:
# python -c ”from OVSSiteRMServer import *; print register_server(‘server2.mindomän.com’,’xen’,True,’oracle’,'<lösenord>’)”
Skapa OCFS2 clustret och konfigurera servrarna. OBS! Detta ska köras på mastern varje gång en ny server tillkommer i klustret eller en server ska tas bort permanent:
# python -c ”from OVSSiteCluster import *; print cluster_setup()”
Hämta info om clustret:
# python -c ”from OVSSiteCluster import *; print cluster_get_info()”
Nuså ska alla registrerade servrar ha tillgång till en /OVS/ katalog som i sin tur är den mountade OCFS2 formatterade partitionen på LUN:et. Alla servrar ska kunna skriva och läsa till katalogen och alla ska kunna se de filer som skapats där oavsett vilken av servrarna som användes för att skapa filerna / katalogerna!
Det fina i det hela är att VIP adressen alltid finns tillgänglig sålänge som minst en server i clustret är igång. Oavsett vilken av servrarna som är ”Master” i SP:n så kommer den att vara åtkomlig i och med att den server som av clustret tilldelas att vara Master är den som tar över VIP adressen.
Nu återstår bara att få ett vettigt GUI att fatta sig på och nyttja detta magiska fina cluster till att lagra alla VM på 🙂
Ifall man glömmer vilka användare / lösenord (MD5 hash!) som finns i OVS:
# python -c ”from OVSConfig import *; print get_passwd()”
Kolla att ovs-agent lever på en server:
# python -c ”from OVSSiteRMServer import *; print get_srv_agent_status(‘192.168.10.33’)”
Kolla om SP är redo för cluster OBS! Verkar säga success till allt oavsett vad 😦
# python -c ”from OVSSiteCluster import *; print cluster_check_prerequisite()”
# python -c ”from utils.do_rpc import *; print get_local_agt_url()”
# python -c ”from OVSXHA import *; print ha_get_ocfs2_config()”
Krokodox's Blog 
Lämna en kommentar