ovh
Utilizzare IP failover su un RPS
Pannello di controllo servizi OVH
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
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 sysconfigshell# cd /etc/sysconfig/network-scriptsshell# cp dummy0 dummy0:1shell# vi ifcfg-dummy0:1DEVICE=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:1dummy0: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.
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 abilitiamomkswap -v1 /dev/sdbswapon /dev/sdbgrep -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 4Importante 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.
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.
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 sorgenticd /usr/src/# download del kernelwget ftp://ftp.ovh.net/made-in-ovh/bzImage/linux-2.6.28.4-ovh.tar.gz# decompressionetar 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 kernelcd 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 .configmv 2.6-config-xxxx-std-ipv4-32 .configA 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
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
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:
# compilamake# installazione dei modulimake modules_install# installazione degli headersmake 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 kernelcp /usr/src/linux/arch/i386/boot/bzImage /boot/bzImage-2.6.28.4-custom-std-ipv4-32-mod# copia della System.mapcp /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 liloLILO 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.
Pagine
Articoli recenti
Archivi
- Luglio 2009 (1)
- Giugno 2009 (3)
- Maggio 2009 (2)
- Aprile 2009 (8)
- Marzo 2009 (1)