det er to av dem, med identisk konfigurasjon. de har:

• Athlon 64-prosessor med 6 kjerner
• 16 gigabyte ram
• 4x2tb disk i raid10 for virtuelle maskiner
• 6x2tb disk i raid5 for generelt lagringsbruk
• fint kabinett med diskskuffer
• hovedkort med ikvm og 10 onboard sata-porter
• forhåpentligvis snart noen nye, fine sas-kontrollere

den ene heter green, den andre heter purple. de er oppkalt etter tentaklene i day of the tentacle!

ideen her er å virtualisere serverparken til nova. vi ønsker å få en mer finkornet inndeling av oppgaver, få anledning til å kjøre et staging/lab-miljø, kunne tilby flere tjenester til novere, lage images uten å sitte på nova og se på windows installere seg selv i timesvis og generelt være mer smidige, kule og fine på håret.

her er litt om hvordan ting er satt opp helt konkret:

prosessorene er ganske ordinære desktop-cpuer med 6 kjerner. det kule er at amd bruker nøyaktig samme arkitektur for desktop-cpuene og server-cpuene sine, så de støtter begge ecc-ram. vi gir dem max, 16 gb hver!

raid-arrayene er av typen mdraid, dvs. software-basert raid av linux-slaget. dette er et bevisst valg da vi ikke har lyst til å låse oss til noen spesielle kontrollere, og vi har mer enn nok prosessorkraft å ta av på disse boksene.

de fire diskene i raid10-arrayet har gpt som partisjonstabell, siden de er over 2tb. diskene har to partisjoner hver, hvor nummer to er en mdraid-partisjon. disse partisjonene ligger så i et raid10 som vi igjen har brukt som et fysisk volum til lvm - dette for å enkelt og smidig kunne gjøre systemdisker større og mindre. purple og green selv har også systemdisk på dette volumet. volumgruppen heter “system”, det logiske volumet som er systemdisken på hver av virtualiseringsserverne heter det samme som serveren heter, og logiske volum til vmer skal ha samme navn som den virtuelle maskinen. for å sørge for at purple og green klarer å boote som de skal, har hver av diskene en 1 megabyte stor grub2 bios boot-partisjon som er smart nok til å forstå både mdraid, lvm og lvm inni mdraid. *uten* initrd. yeaaaaaaahhhhhhhhh!

grunnen til at vi har kjøpt og bygd to identiske maskiner er ikke at vi ble ferdig med den ene, puttet den i et kott og glemte at vi hadde laget den. planen har hele tiden vært å bruke noe som heter drbd som lar oss speile disker mellom serverne over en nettverksforbindelse. drbd gir bare tilgang til diskene på en node av gangen - for å unngå at ting i vanvare tas opp på begge nodene og filsystemet blir veldig brukket.

virtualiseringen er av slaget kvm, fordi å bruke linux-kernelen som hypervizor synes vi er kult og en god ide. det er deilig å kunne kill -9 vmer som ikke oppfører seg!

nettverksmessig er det slik:

vi kjører trunk fra switch direkte inn i nettkortene på serverne. serverne har så virtuelle interfjaser satt opp på hvert av vlanene (med tilhørende bridge-devices, navngitt type br<vlan-id>), slik at vi kan gi de åndelige serverne grensesnitt på de forskjellige nettverkene etter ønske og behov. det betyr at vi kan virtualisere eksterne servere og interne nova-servere på de samme jernene, eller lage en server som er tilgjengelig utenfra men også har tilgang til interne tjenester på novanettet. alt dette uten å tøyse med en fysisk kabel! totally *chk-chk*

vi har et dedikert nettverk mellom maskinene for drbd. per nu er dette en enkel gigabit-kobberlink, men når vi får et par grensesnitt til i maskinene skal vi fikse LAG mellom dem.

her er en fungerende prosedyre for å lage en vm på dette flotte systemet. jeg oppretter her en linux-boks ved navn trixie med 512 meg ram og 20gb disk. det er litt tungrodd foreløpig, men det er i alle fall ikke så mye magi vi ikke vet hvordan funker.

[note for n00bs: bli root før du gjør dette, feks. med sudo -i]

opprett et lvm-volum med servernavnet på hver av vmene, i system-volumgruppen.

lvcreate -L 20gb system -n trixie

gjør dette på begge serverne.

lag en drbd-konfigurasjonsfil til denne vmen i /etc/drbd.d/, kall den servernavn.res - her er innholdet i trixie.res som et eksempel:

resource trixie {
  device	/dev/drbd1;
  disk		/dev/system/trixie;
  meta-disk	internal;

  on green {
    address	192.168.255.1:7801;
  }
  on purple {
    address	192.168.255.2:7801;
  }
}

hvert drbd-volum krever separate portnummer og separat drbd-device. for ordens skyld inkrementerer vi devicenummer og portnummer sammen, dvs. drbd2 = 7802, drbd3 = 7803 osv. se de andre .res-filene for å se hvor langt vi har kommet.

denne filen må ligge på begge serverne, og den må være identisk. for å forenkle duplisering av konfigurasjonsfiler har jeg satt opp public key authentication mellom serverne - om du blir root, kan du scpe filer fritt mellom maskinene, type:

scp /etc/drbd.d/trixie.res green:/etc/drbd.d/

i fremtiden kan vi ha noe som overvåker etter endringer og kopierer over automatisk. eller rsync i en cronjobb. eller eller.

det finnes et velsignet init-script i ubuntu som håndterer drbd-volumene for oss. det er enkelte ting dette svikter litt på, og derfor bør diskene initieres manuelt:

drbdadm create-md trixie

gjør dette på begge serverne.

etter dette skal man teoretisk sett få opp drbd-volumet ved å fyre init-scriptet:

service drbd reload

på begge serverne, men jeg hadde littegrann problemer med dette - devicet kom ikke opp som det skulle, noe jeg kunne se i /proc/drbd. løsningen var å google feilmeldingen jeg fikk og kjøre en drbdsetup-kommando. dokumenterer det sikkert her en gang!

når du har fått ting opp og sykle og /proc/drbd ser nogenlunde ok ut er fremdeles begge diskene i en inconsistent tilstand. dette er fordi drbd ikke vet hvilken node som har de riktige dataene, og for å unngå å herpe den fine vmen du lagde i fjor venter den til du har fortalt den hvilken som er primær. i dette tilfellet driter vi i det, da vmen ikke er installert en gang, og kjører på en vilkårlig node:

drbdadm primary --force trixie

her fikk jeg feilmelding:

1: State change failed: (-2) Need access to UpToDate data
Command 'drbdsetup 1 primary' terminated with exit code 17

dette er drbdadm som ikke forcer ting selv om man ber om det. kanskje –do-what-i-say elns hjelper, jeg gjorde:

drbdsetup 1 primary -o

nå burde du se at volumet holder på å synke mellom nodene. dette tar irriterende lang tid på grunn av en litt teit rate-begrensning. i følge dok skal man kunne kjøre:

drbdadm disk-options --resync-rate=110M

det funka ikke for meg, men det gjorde derimot:

drbdsetup /dev/drbd/by-res/trixie syncer -r 110M

for å resette:

drbdadm adjust trixie

etter dette er drbd-volumet tilgjengelig på en av nodene, du kan se hvilken ved å kjøre:

drbdadm role trixie

om du er på serveren som har tilgang til volumet, står det Primary/Secondary. Er du på den andre noden, står det Secondary/Primary. om du vil ta opp vmen på den andre noden, kan du:

drbdadm secondary trixie

på noden du ikke vil ha den på, etterfulgt av

drbdadm primary trixie

på noden der du vil ha den.

nå burde du være klar til å installere den nye vmen din!

[note for n00bs: Den nye vmen er nok fortsatt inconsistent en stund til, men drit i det. Bare sett igang med resten av installasjonsprosessen]

her er en grei mal å bruke når du skal lage xml-fil som du kan definere vmen med i virsh:

<domain type='kvm'>
  <name>trixie</name>
  <description>testserver</description>
  <memory>524288</memory>
  <currentMemory>524288</currentMemory>
  <vcpu>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc-1.0'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <cpu match='exact'>
    <model>Opteron_G3</model>
    <feature policy='require' name='wdt'/>
    <feature policy='require' name='skinit'/>
    <feature policy='require' name='osvw'/>
    <feature policy='require' name='3dnowprefetch'/>
    <feature policy='require' name='cr8legacy'/>
    <feature policy='require' name='extapic'/>
    <feature policy='require' name='cmp_legacy'/>
    <feature policy='require' name='3dnow'/>
    <feature policy='require' name='3dnowext'/>
    <feature policy='require' name='pdpe1gb'/>
    <feature policy='require' name='fxsr_opt'/>
    <feature policy='require' name='mmxext'/>
    <feature policy='require' name='ht'/>
    <feature policy='require' name='vme'/>
  </cpu>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/kvm</emulator>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/drbd/by-res/trixie'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    <disk type='block' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source dev='/root/ubuntu-12.04-mini.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
    </disk>
    <interface type='bridge'>
      <source bridge='br16'/>
      <model type='virtio'/>
    </interface>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='5916' autoport='no' keymap='no'/>
    <video>
      <model type='cirrus' vram='9216' heads='1'/>
    </video>
    <memballoon model='none'/>
  </devices>
</domain>

sett vnc-port sånn passe etter drbd-device og greier. sett source-device for bridgen ettersom hvilket vlan du vil maskinen skal henge på, br10 er vlan 10, br16 er vlan 16 etc. se ip-adresser

start virsh, og gi den kommandoene:

define trixie.xml
start trixie

på dette tidspunktet burde det være duket for å røske meg seg en vnc-port fra maskina du sitter på inn til vmen:

ssh -L 5900:localhost:5900 green.radionova.no

også vnc til localhost på maskinen du sitter på. forhåpentligvis får du nå opp et snilt installasjonsbilde og kan kjøre på med installering, partisjonering etc. som vanlig!

når du er ferdig kan du

virsh edit trixie

og endre

 boot dev 

til

hd

og fjern disk-blokken hvor cd-romen er definert. lagre endringene, og gjør:

virsh destroy <maskinnavn>
virsh start <maskinnavn>

så skal ting være i boks!

NB: det dukker opp en xml i /etc/libvirt/qemu/ som du må scpe over til den andre noden (og gjerne definere opp der også)! om den ikke er kopiert til den andre noden så har vi et skikkelig problem om en av serverne dør og vi må få opp vmen igjen!

NNB:* installer acpid på VMen din, slik at virsh shutdown <maskinnavn> funker!

good luck and godspeed