ovh

Utilizzare IP failover su un RPS

Pannello di controllo servizi OVH

Pannello di controllo servizi OVH

Gli RPS di OVH vengono consegnati con 2 IP, di cui uno viene chiamato IP Failover. Purtroppo, a differenza dei dedicati, questo IP non può essere reindirizzato su un’altro RPS poichè è necessario durante il boot per la corretta connessione al disco iSCSI.

Di fatto, quindi, l’IP failover in dotazione non può essere “basculato” tra gli RPS.

Come e perchè

Qualche giorno fa OVH ha annunciato che ora è possibile acquistare fino a 30 IP Failover aggiuntivi anche sugli RPS.

Per poter assegnare IP FailOver aggiuntivi al server è necessario acquistare degli “slot” e lo possiamo fare direttamente dal menu “Servizi” => “IP FailOver” del pannello di controllo:

Pannello di controllo degli IP FailOver sul Manager di OVH

Pannello di controllo degli IP FailOver sul Manager di OVH

Una volta acquistati gli slot è possibile selezionare l’IP tra quelli ancora disponibili sulle reti OVH. L’IP FailOver appartiene ad un blocco registrato al RIPE come italiano e quindi, nonostante sia fisicamente in francia, dal punto di vista dell’assegnazione di una nazionalità risulterà italiano (alcuni esperti SEO sostengono che questo fattore sia importante per migliorare l’indicizzazione dei siti italiani: io, sinceramente, sono molto scettico e non ho ancora trovato prove in merito).

Al momento in cui ho effettuato l’acquisto io erano disponibili molti IP in 5 differenti classi C (alcuni esperti SEO sostengono che è importante che i link tra siti siano su IP differenti, meglio ancora su classi C differenti. Questo mi sembra già più plausibile e lo verificherò a breve spostando alcuni siti su nuovi IP).

Molto interessante a parer mio poter vedere l’elenco degli IP tra i quali scegliere così da assicurarsi di non utilizzare un IP con una cattiva reputazione (un IP usato in precedenza per scopi non troppo etici).

Configurazione di un IP FailOver su Fedora Core 9

Aggiungere un IP FailOver ad un RPS con Fedora Core 9 è piuttosto semplice.

l’IP failover in dotazione è già configurato su una interfaccia di rete “virtuale” chiamata dummy0
Per aggiungere un alias possiamo creare copie del file dummy0 aggiungendo :1, :2, :3 per ogni IP FailOver che ci serve aggiungere.

# la cartella di configurazione della rete è per le Fedora in sysconfig
shell# cd /etc/sysconfig/network-scripts
shell# cp dummy0 dummy0:1
shell# vi ifcfg-dummy0:1
DEVICE=dummy0:1
BOOTPROTO=static
IPADDR=94.23.XX.XXX
NETMASK=255.255.255.255
ONBOOT=yes

A questo punto sarà sufficiente modificare il file appena creato (ifcfg-dummy0:1) inserendo come IPADDR l’ip failover acquistato e poi abilitare gli alias

shell# ./ifup-aliases dummy0

E verificare che abbia funzionato:

shell# ifconfig dummy0:1

dummy0:1  Link encap:Ethernet  HWaddr F2:DD:43:XX:XX:XX
  inet addr:94.23.XX.XXX  Bcast:94.23.XX.XXX  Mask:255.255.255.255
  UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1

Il mio consiglio è quello di provare subito anche a riavviare il server per verificare che l’IP venga riacquisito correttamente al boot.

Next

La mia intenzione è quella di provare ad installare VMware Server 2 e configurare una macchina virtuale che utilizzi l’IP FailOver appena configurato. Per ora tutto liscio, le prossime puntate saranno un po’ più complicate.

Tags: , , , ,

giovedì, Aprile 2nd, 2009 Sysadmin Nessun commento

Ridurre le dimensioni del kernel su un RPS3

Due giorni fa ho scritto come ricompilare il kernel per un RPS di OVH e come questo renda il boot molto lento.

Convertendo in moduli caricabili dinamicamente tutte le opzioni del kernel che lo supportano e che non siano necessarie durante il boot, togliendo alcune funzionalità non utilizzate e lasciando i soli moduli necessari per l’hardware dell’RPS3 (AMD Athlon 64) sono riuscito a ridurre l’immagine compressa del kernel da 4.5MB a 1.8MB!

Ho lasciato la compilazione statica per la scheda di rete 100mbps (nForce), il supporto per le filesystems ext2, ext3, cramfs, il supporto per iSCSI, iSCSI initiator, il supporto per i block devices, il supporto per il ramdisk.

Ho inoltre impostato l’ottimizzazione per processori AMD Athlon 64 togliendo il supporto per tutti gli Intel ed altri.

Ho abilitato tutte le funzionalità di iptables ma come modulo.

Il risultato è questo .config che potete utilizzare al posto di quello di OVH e poi ricompilare ed installare il kernel.

Così facendo il tempo direboot del mio RPS3 è passato da 15 minuti a 8 minuti. Continuo a ricevere i ticket di OVH che si accorge che il sistema non è raggiungibile da troppo tempo ma a questo punto il ticket rimane aperto talmente poco che è improbabile che un tecnico OVH prenda in carico il ticket e decida di riavviare l’RPS con il netboot.

Riabilitare lo swap

La rimozione del supporto USB dal kernel verso un modulo fa si che la direttiva append=”libusual.bias=ub” (presente nel /etc/lilo.conf) non funzioni più. Quella direttiva fa si che la chiave usb presente per lo swap venga chiamata /dev/uba e non /dev/sd* per evitare di fare conflitto con i dischi iSCSI.
Per risistemare le cose dobbiamo quindi eliminare l’append “inutile” dal lilo.conf e poi abilitare lo swap manualmente.

swapon -s
# se non è già presente lo swap su /dev/sdb lo abilitiamo
mkswap -v1 /dev/sdb
swapon /dev/sdb
grep -q "/dev/sdb" /etc/fstab || echo "/dev/sdb none swap sw 0 0" >> /etc/fstab

A questo punto lo swap verrà riabilitato in automatico al boot.
Ricordatevi inoltre che dopo aver modificato il lilo.conf dovete aggiornare il bootrecord con “lilo -v

Altro sulle dimensioni del kernel

Per capire quanto influisca ciascuna funzionalità “built-in” sulla dimensione del kernel possiamo usare un metodo grezzo quanto efficace:

cd /usr/src/linux
find . -name "built-in.o" | xargs size | sort -n -r -k 4

Importante tenere in considerazione che i moduli built-in vengono aggregati per cartella e quindi ad esempio “./fs/built-in.o” includerà “./fs/ext3/built-in.o“.

Per ridurre ulteriormente forse si potrebbe far uso della chiave usb inserita nel’RPS (usata normalmente come swap), ma forse c’è bisogno di modificare anche l’initrd.

Per la cronaca l’initrd-iscsi.img che trovate nella root del disco è un loop device con filesystem cramfs.

Potete esplorarne il contenuto così:

cp /initrd-iscsi.img /tmp/initrd
mkdir /tmp/content
mount -o loop /tmp/initrd /tmp/content

All’interno della cartella /tmp/content troverete tutti gli script specifici per montare il disco iSCSI come root.

Tags: , , , ,

mercoledì, Aprile 1st, 2009 Sysadmin Nessun commento

Installare un kernel modulare su un RPS di OVH

Gli RPS (Real Private Server) di OVH sono server “reali” (e non virtuali) con la sola differenza che non hanno un disco proprio ma piuttosto utilizzano iSCSI per accedere ad un disco di rete.

Pagina di gestione del netboot nel manager v3 di OVH

Gestione del netboot nel manager v3 di OVH

Di default gli RPS effettuano il boot via netboot, ossia dalla rete. OVH utilizza un sistema per il quale è possibile tramite interfaccia web (manager) selezionare che tipo di boot si voglia effettuare tra hd, rescue-pro, vKVM e vari kernel precompilati da OVH con o senza supporto di ipv6 e con o senza supporto GRSEC (patch che migliora la sicurezza del kernel).

Alla consegna esiste già un kernel installato anche sull’hd ed è quindi possibile fare il boot da hd: basta selezionare “hd” e poi riavviare l’RPS ed aspettare un po’.

Ebbene sì, il boot da HD risulta molto più lento del netboot ed impiega circa 15 minuti, durante i quali riceverete alcune email da OVH che si accorge che il sistema non è raggiungibile ed apre automaticamente un ticket di assistenza per poi richiuderlo (sempre automaticamente) appena il server torna online.

Nei numerosi test che ho effettuato qualche volta mi è capitato che i tecnici di OVH gestissero il ticket prima che venisse effettivamente richiuso in automatico. In questi casi mi sono ritrovato il server impostato sul netboot del primo kernel di rete e riavviato con quello.

Utilizzare un kernel su hd per un RPS è quindi fortemente sconsigliato ma ci sono casi in cui può essere fondamentale poter utilizzare un kernel personalizzato, come ad esempio l’uso di un driver particolare (e.g: DRBD), di una particolare regola iptables oppure del supporto per i moduli del kernel (e.g: per installare vmware server). Il kernel di rete non è modulare e non è modificabile quindi in tutti questi casi avrete bisogno di ricompilare il kernel, installarlo ed attivare il boot da hd.

Nel mio caso l’OS dell’RPS è una Fedora Core 9 Italiano, ma le istruzioni dovrebbero essere sostanzialmente le stesse con tutte le distribuzioni.

Scarichiamo i sorgenti del kernel usato da OVH dal loro server. Mentre scrivo questo articolo la 2.6.28.4 è l’ultima disponibile:

# lavoriamo in /usr/src, cartella standard per i sorgenti
cd /usr/src/
# download del kernel
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/linux-2.6.28.4-ovh.tar.gz
# decompressione
tar xzf linux-2.6.28.4-ovh.tar.gz
# link a /usr/src/linux per comodità
ln -s linux-2.6.28.4-ovh linux

Scarichiamo poi il file di configurazione usato da OVH, come base prima delle nostre modifiche. Sempre nell’ftp precedente OVH ne fornisce 2, quello a 32bit e quello a 64bit.

# entriamo nella cartella del kernel
cd linux
# scarichiamo il file di configuraizone (nel mio caso a 32bit)
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6-config-xxxx-std-ipv4-32
# rinominiamo il file a .config
mv 2.6-config-xxxx-std-ipv4-32 .config
A questo punto siamo pronti per riconfigurare il kernel secondo le nostre esigenze:
# lancio della configurazione del server:
make menuconfig

Interfaccia ncurses della riconfigurazione del kernel

Interfaccia ncurses della riconfigurazione del kernel


A questo punto potete apportare le modifiche di configurazione che vi servono.

Nel mio caso si trattava dell’abilitazione del supporto dei moduli con “Enable loadable module support” e la sotto funzione “Module unloading“, da “Device Drivers” la funzione “Connector – unified userspace <-> kernelspace linker” e il “Real Time Clock“, che in questo caso attivo come moduli esterni (<M>)

Per distinguere correttamente il nostro kernel dovremo poi cambiare il suffisso nel menu “General setup” alla voce “Local version – append to kernel release“.

Scelta del suffisso del kernel

Scelta del suffisso del kernel


Io ho scelto “-custom-std-ipv4-32-mod

Completate le modifiche uscite memorizzando il .config e proseguiamo con la compilazione che richiederà tra i 15 e i 30 minuti e l’installazione:

# compila
make
# installazione dei moduli
make modules_install
# installazione degli headers
make headers_install

Completata questa procedura il kernel è pronto. Evitate di usare il classico “make install” per l’installazione perchè l’installazione ovh usa un initrd molto particolare (per l’uso del disco iscsi) che non vogliamo rigenerare.

# copia del kernel
cp /usr/src/linux/arch/i386/boot/bzImage /boot/bzImage-2.6.28.4-custom-std-ipv4-32-mod
# copia della System.map
cp /usr/src/linux/System.map /boot/System.map-2.6.28.4-custom-std-ipv4-32-mod

Non ci resta che abilitare il nuovo kernel in lilo (credo che in tutte le RPS sia installato lilo)

# lancia l'editing (vi o il vostro editor preferito).
vi /etc/lilo.conf

# mantengo il vecchio kernel come "linux-orig" e aggiungo la configurazione del nuovo. Il file risultante è:

prompt
timeout=10
default=linux
boot=/dev/sda
map=/boot/map
install=/boot/boot.b
lba32
  
image=/boot/bzImage-2.6.28.4-custom-std-ipv4-32-mod
  label=linux
  read-only
  root=/dev/ram0
  initrd=/initrd-iscsi.img
  append="libusual.bias=ub"
image=/boot/bzImage-2.6.24.5-xxxx-grs-ipv4-32
  label=linux-orig
  read-only
  root=/dev/ram0
  initrd=/initrd-iscsi.img
  append="libusual.bias=ub"


# salviamo ed aggiorniamo il bootloader:
lilo -v

# risultato del comando lilo

LILO version 22.8, Copyright (C) 1992-1998 Werner Almesberger
Development beyond version 21 Copyright (C) 1999-2006 John Coffman
Released 19-Feb-2007 and compiled at 09:15:23 on Feb 19 2007.
  
Reading boot sector from /dev/sda
Using MENU secondary loader
Calling map_insert_data
  
Boot image: /boot/bzImage-2.6.28.4-custom-std-ipv4-32-mod
Mapping RAM disk /initrd-iscsi.img
Added linux *
  
Boot image: /boot/bzImage-2.6.24.5-xxxx-grs-ipv4-32
Mapping RAM disk /initrd-iscsi.img
Added linux-orig
  
Writing boot sector.
/boot/boot.0800 exists - no boot sector backup copy made.

Riavviamo la macchina (shutdown -r now) e dopo 10-15 minuti la macchina dovrebbe essere caricata con il nuovo kernel. Il comando uname -r dovrebbe perciò dirci “2.6.28.4-custom-std-ipv4-32-mod” e non più “2.6.28.4-xxxx-std-ipv4-32” e il comando lsmod dovrebbe funzionare (mostra l’elenco dei moduli se il kernel è modulare).

Se la macchina non dovesse ripartire potete sempre andare nel manager ed impostare il netboot sul kernel di rete per poi forzare in riavvio.

Nel prossimo articolo vi mostro il mio .config con il quale ho ridotto le dimensioni dell’immagine del kernel da 4.5MB a 1.8MB così da ridurre i tempi di reboot a circa 6-7 minuti.

Tags: , , ,

martedì, Marzo 31st, 2009 Sysadmin 4 Comments