Dopo aver cercato un po’ mi sono accorto che non esiste un plugin che può monitorare il carico dei singoli processi in esecuzione su una macchina. Alcuni plugin permettono di creare un grafico specifico per un determinato processo ma nessuno lo fa in maniera aggregata per tutti i processi contemporaneamente.

Così, vista la semplicità con cui è possibile scrivere un plugin munin, ho deciso di crearne uno che facesse al caso mio.

Questo è il risultato che ho ottenuto con poco sforzo:

Uso della CPU per processo

Oltre al carico di CPU ho deciso di monitorare anche i minor-faults e i major-faults. I minor faults avvengono ogni qual volta un processo cerca di scrivere in una pagina di memoria protetta da scrittura, mentre i major faults avvengono quando questa operazione richiede anche una o più operazioni di I/O (e.g: swap). L’analisi dei minor/major faults può essere utile durante l’indagine di un problema di performance di un sistema.

Questo, ad esempio, è il grafico dei minor-faults corrispondente al precendete grafico di carico CPU per la stessa macchina:

Errori di pagina "minori" per processor

I plugin, da copiare nella cartella /etc/munin/plugins sono questi:
- processes_cpu
- processes_minorfaults
- processes_majorfaults

Dopo aver copiato i plugin, è necessario riavviare il munin-node:

sh# service munin-node restart

Possibili migliorie

Purtroppo i colori devo necessariamente lasciarli gestire a munin automaticamente.

Non ho idea di come si potrebbe fare a mettere in legenda solo quei processi che hanno usato almeno un 1% della CPU o funzionalità del genere.

Se lo stesso plugin viene installato in più macchine i processi vengono colorati diversamente per ogni macchina, rendendo di fatto poco intuitivo il confronto. Forse decidere il colore in base ad un hash calcolato dal nome del processo permettere stabilità ma potrebbe capitare che i processi più importanti abbiano poi un colore identico e siano indistinguibili.

Nessun articolo simile

Questo articolo prevede l’uso di Fedora Core 10 con Apache 2 installato e funzionante. Altre distribuzioni potrebbero richiedere la compilazione dei pacchetti che invece su FC10 sono già disponibili.

Installare CBand

Fortunatamente anche per il modulo cband esiste un pacchetto precompilato per FC10 e quindi l’installazione è molto rapida:

sh# yum install mod_cband

Installato il mod_cband aggiungiamo alla definizione di ogni VirtualHost che vogliamo monitorare la configurazione di cband:

<IfModule mod_cband.c>
CBandLimit 600G
CBandExceededURL http://www.google.com
CBandScoreboard /var/run/httpd/cband_scoreboard-#DOMINIO#
CBandPeriod 1W
</IfModule>

Da notare che ho impostato un limite di 600GB in 1 settimana, che nel mio caso corrisponde praticamente a non limitare, poichè il traffico è molto minore. E’ però necessario imporre un limite (seppur irraggiungibile) per far si che cband conteggi l’utilizzo di banda.

Fatto questo per ogni VH possiamo testare che la configurazione sia corretta, riavviare apache e vedere la pagina delle statistiche di cband:

sh# httpd -t
sh# service httpd restart

Aprendo http://localhost/cband-status vedremo una pagina simile a questa:

La pagina delle statistiche di cband

Impostare Classi in Cband

cband permette di definire fino a 3 classi di utenti in base all’IP. Con un po’ di lavoro possiamo quindi identificare i bot dei motori di ricerca, magari tenendo separato google che ci interessa più degli altri, e le classi di IP locali, per evitare che alcune macchine che effettuano richieste automatizzate possano inficiare le statistiche.

Queste sono le mie configurazioni messe in /etc/httpd/conf.d/mod_cband.conf

<CBandClass googlebot_class>
CBandClassDst 66.249.64/20
</CBandClass>

<CBandClass local_class>
CBandClassDst XXX.XXX.XXX.XXX
CBandClassDst 127.0.0.1
</CBandClass>

<CBandClass bots_class>
# Yanga
CBandClassDst 91.205.124.3/22
# Exabot
CBandClassDst 193.47.80.0/24
# Slurp
CBandClassDst 72.30.0.0/16
CBandClassDst 74.6.0.0/16
CBandClassDst 67.195.114.0/24
CBandClassDst 67.195.37.0/24
CBandClassDst 202.160.178.0/20
# Yandex
CBandClassDst 77.88.22.0/21
CBandClassDst 93.158.146.0/23
# Jyxobot
CBandClassDst 195.113.214.197
# DotBot
CBandClassDst 208.115.111.0/24
# libwww-perl
CBandClassDst 195.210.89.0/24
# MSN con referrer di ricerca
# CBandClassDst 65.55.104.0/21
# Twiceler
CBandClassDst 216.129.119.1/24
CBandClassDst 64.1.215.1/24
CBandClassDst 208.36.144.1/24
CBandClassDst 38.99.13.1/24
CBandClassDst 38.99.44.1/24
# AskJeeves
CBandClassDst 66.235.124.0/24
# majestic12
CBandClassDst 85.23.64.207
CBandClassDst 212.50.134.32
CBandClassDst 85.16.151.236
CBandClassDst 85.113.244.201
CBandClassDst 68.192.9.221
CBandClassDst 85.178.109.63
# Wikio Feed
CBandClassDst 84.55.184.91
# Turnitin
CBandClassDst 65.98.224.7
# MSN
# CBandClassDst 65.55.208.0/24
# CBandClassDst 65.55.51.0/24
CBandClassDst 65.55.0.0/16
CBandClassDst 219.142.53.0/24
# Gaisbot
CBandClassDst 122.147.76.64/28
CBandClassDst 210.66.69.128/26
CBandClassDst 219.87.182.128/27
CBandClassDst 220.228.152.64/27
</CBandClass>

In questo modo il calcolo del traffico avverrà separatamente per “classe”. Potremo conoscere il traffico degli “utenti normali” per differenza, sottraendo dal traffico totale le classi local_class, bots_class, googlebot_class.

Installare Munin

Munin è uno strumento di monitoring con un meccanismo di estendibilità a plugin estremamente semplice ed intuitivo (rispetto a MRTG) che permette di monitorare uno o più server.

Munin si divide infatti in due pacchetti: munin e munin-node.

Mentre munin-node è necessario in ogni server che intendiamo controllare il pacchetto munin serve solamente nella macchina che aggregherà le statistiche per creare dei grafici tramite il noto strumento rrdtool.

Su Fedora Core 10 installare munin è molto semplice:

sh# yum install munin munin-node

Una delle peculiarità di munin è l’autoconfigurazione: i plugin infatti possono verificare l’ambiente in cui sono installati per stabilire se sono “applicabili” all’ambiente o meno. Per verificare l’autoconfigurazione possiamo lanciare questo comando:

sh# munin-node-configure --shell

L’output di questo comando conterrà l’elenco dei comandi da impartire alla shell per installare i plugin che dichiarano la loro compatibilità.

Creare un plugin munin per mod_cband

A questo punto non ci resta che creare un plugin munin che legga la pagina /cband-status e permetta così a munin di visualizzare il grafico degli accessi diviso per vhost.

Questo è un esempio del plugin munin che richiede la pagina e ne estrae i dati:

#!/bin/sh

URL="http://localhost/cband-status?refresh=15&unit=K";
WGET=`which wget`;
WGET_FLAGS="-Yoff";

# Settigs required for autoconf
#%# family=manual
#%# capabilities=autoconf

if [ "$1" = "autoconf" ]; then
echo no
exit 0
fi

if [ "$1" = "config" ]; then

echo 'graph_title CBandwith Usage '
echo 'graph_args -l 0'
echo 'graph_category apache'
echo 'graph_info This graph shows per virtual host traffic from the cband module.'
echo 'graph_vlabel Kbytes per ${graph_period}'

wget -q $WGET_FLAGS "$URL" -O - | grep -A 3 http |grep "^<td .*http" |sed -e 's^.*http://\(.*\)".*^\1^' | while read site; do
metricname=$(echo $site | sed -e 's/\.//g')
#echo $metricname $site
echo $metricname'.label '$site
echo $metricname'.info Traffic generated on '$site'.'
echo $metricname'.min 0'
echo $metricname'.type DERIVE'
done;
exit 0
fi

if [ -x $WGET ]; then
SITES=$(wget -q $WGET_FLAGS "$URL" -O - | grep -A 3 http |grep "^<td.*http" |sed -e 's^.*http://\(.*\)".*^\1^')
$WGET -q $WGET_FLAGS "$URL" -O - | grep -A 3 http |grep "^<td.*\(color\|http\)" | while read v; do
echo -n $v | sed -e 's^.*http://\(.*\)".*^\1^' | sed -e 's/\.//g'
echo -n '.value '
read v;
echo $v | sed -e 's^.*\/\(.*\)KB.*^\1^'
done;
exit 0
fi

exit 0

E questo è il risultato:

Traffico generato da Google su ogni VHost

I plugin munin che ho creato sono molto spartani ma utili e controllano il traffico totale, quello di google, quello degli altri bots, e il traffico utente (il totale meno i robot e meno la classe locale).

Conclusioni

Il modulo cband, nonostante non più aggiornato dal 2006, non sembra pesare sulle performance e la stabilità di apache2 e dopo un mesetto di utilizzo ne sono soddisfatto.

Dovrei migliorare il plugin configurando meglio le impostazioni dei grafici (usare il min/max/avg, stili di linea differenti.

Troubleshooting

Se cband non vi funziona bene probabilmente si tratta di un problema di ordine di caricamento dei files nella /etc/httpd/conf.d . Questi files vengono caricati in ordine alfabetico, quindi se le definizioni dei virtualhost le avete qui assicuratevi che vengano il ordine alfabetico dopo al mod_cband.conf

Io, per convenzione, li chiamo vh-dominio.conf

Nessun articolo simile

Lo spostamento di un sito/servizio web da un IP ad un altro può essere molto problematica. I grattacapi principali sono dovuti al tempo di propagazione del DNS, durante il quale i visitatori potrebbero approdare sia sul vecchio che sul nuovo IP in funzione di quale server DNS utilizzano e lo stato della cache.

Per ridurre al minimo questo problema è buona norma ridurre l’expire della cache di un dominio prima di un’operazione di trasloco di questo tipo, ma questa soluzione riduce solo il problema senza rimuoverlo.

Il problema fondamentale consiste nel fatto che a volte non possiamo permetterci che i due servizi su i 2 IP diversi ricevano richieste contemporaneamente perchè queste richieste potrebbero modificare lo stato di entrambi i server creando una divergenza non più sincronizzabile. Basta pensare ad un blog ed il fatto che alcuni utenti potrebbero commentare sul primo IP mentre altri sul secondo, con la conseguente perdita di dati che si avrebbe a transizione completata.

Una soluzione spesso adottata è quella di far rispondere il nuovo (www.dominio.com) sito ad una nuova URL tipo nuovo.dominio.com, sincronizzare il database, modificare la configurazione del webserver per far si che qualunque richiesta a www.dominio.com venga rediretta (302, temporary redirect) a nuovo.dominio.com e poi aggiornare il DNS. Questa soluzione però, oltre a non essere completamente trasparente per l’utente finale, potrebbe creare problemi nel caso in cui l’applicazione che dobbiamo spostare non sia indipendente dal nome. Potremmo infatti avere già dei cookie impostati per quel detterminato l’hostname o potremmo avere dei punti del codice che controllano quale sia l’hostname attuale.

Per questo motivo la mia soluzione preferita è quella di utilizzare un reverse proxy. In pratica si configura il sito nuovo, si sincronizza il db, poi si configura il vecchio non più per fare un redirect ma piuttosto per andare a chiedere la stessa pagina al sito nuovo e fornirla al navigatore.

Per fare questo con apache2 è sufficiente abilitare il mod_proxy in /etc/httpd/conf/httpd.conf togliendo il # dalle due righe:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

ed aggiungere al virtualhost che stiamo spostando le seguenti istruzioni:

ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://[IP-NUOVO-SERVER]/

Con questa configurazione facciamo sì che le richieste fatte a quel sito vengano gestite non più dal server locale, ma piuttosto apache2 si preoccuperà di andarle a fare sull’[IP-NUOVO-SERVER]. ProxyPreserverHost ci serve così da poter mantenere l’Host nella richiesta e fare in modo che il server di destinazione riceva la richiesta come se l’avesse ricevuta dall’utente originale.

ProxyPass dice che tutte le pagine vengono “girate” al nuovo IP, ma potremmo anche decidere di fare questa operazione solo con alcune sottodirectory.

Esiste però ancora un problema legato a questa tecnica, e cioè che il nuovo server vedrà tutte le richieste venire dall’IP del vecchio server e non conoscerà più l’IP originale. Questo significa che i log avranno l’IP del “proxy” e che alcuni script potrebbero non funzionare bene.

Per questo viene d’aiuto un altro modulo apache chiamato mod_extract_forwarded che permette di estrarre l’IP presente nell’header X-Forwarded-For (aggiunto dal mod_proxy) e sostituirlo al remote address usato da apache.

Se il vostro nuovo server è una fedora core 10, come la mia, allora potete installare il modulo direttamente:

shell# yum install mod_extract_forwarded.i386

Il file di configurazione del modulo è in /etc/httpd/conf.d/mod_extract_forwarded.conf . E’ sufficiente aprirlo e modificare la riga MEFaccept inserendo l’elenco degli IP dei “proxy” fidati:

MEFaccept [IP-VECCHIO-SERVER]

E’ importante specificare questa opzione solo per gli IP dei proxy fidati perchè l’header X-Forwarded-For è un semplice header HTTP e di conseguenza è falsificabile molto semplicemente. Basti pensare che esiste una estensione Firefox che permette di impostare tale header a piacimento.

Ecco fatto, sia i log che tutte le applicazioni mostreranno l’IP originale e non quello del “proxy”.

Nessun articolo simile

VMware Server 2.0 - Interfaccia webAccess

VMware Server 2.0 - webAccess - Interfaccia macchina virtuale

La cosa interessante è che i servizi di gestione remota sono un servizio separato e quindi con Virtual Infrastructure Client 2.5 è possibile connettersi alla porta 8333 (in https) del server sul quale è installato VMware Server 2 e gestire tutti i parametri.

VMware Virtual Infrastructure Client 2.5

VIC 2.5 - Pagina macchina virtuale

L’unica limitazione è che con il VIC è possibile gestire solamente i formati di macchina virtuale fino al 4 mentre quelli fatti con l’interfaccia web (webAccess) sono in versione 7. Se volete mantenere la possibilità di disabilitare il webAccess, quindi, vi consiglio di creare le vostre macchine virtuali con il VI client.

Veniamo ora alla modifica del file /etc/rc.d/init.d/vmware
Dovrete trovare la funzione:

vmware_start_webAccess() {
  echo -n '   '"$webAccessServiceName"
  $watchdog -s webAccess -u 30 -q 5 "$webAccess $webAccessOpts start" > /dev/null 2>&1 &
}

e modificarla in

vmware_start_webAccess() {
  echo -n '   '"$webAccessServiceName"' DISABLED'
#  echo -n '   '"$webAccessServiceName"
#  $watchdog -s webAccess -u 30 -q 5 "$webAccess $webAccessOpts start" > /dev/null 2>&1 &
}

In questo modo al prossimo riavvio di vmware verrà comunque lanciato hostd (il servizio di gestione base) ma non il webAccess (l’applicativo basato su Java/Tomcat che si frega così tanta RAM).

Non si capisce perchè VMware abbia deciso di spezzare in script di avvio separati altri 3 servizi ma poi abbia deciso di consolidare hostd (management per le virtual machine) con webAccess (accesso web al management).

Chrissy propone una soluzione alternativa allo stesso problema.

Nessun articolo simile

Configurazione standard DRBD

Premessa

DRBD (Distributed Replicated Block Device) è una sorta di disco virtuale che gestice un RAID 1 via rete. In pratica due dischi installati su due macchine fisiche diverse possono essere visti come unico disco. DRBD è uno dei mattoni fondamentali per la gestione di un cluster HA (High Availability) low cost.

Requisiti

Esistono gli RPM di DRBD già fatti per Centos e si possono usare anche con la Fedora, però funzionano solo con i kernel ufficiali delle rispettive distribuzioni, quindi dovremo crearci il nostro pacchetto.

Innanzitutto dovete assicurarvi di avere installato un kernel che supporta i moduli e che supporta la funzionalità “Connector”.

Inoltre è consigliabile che abbiate riservato una partizione, identica sulle due macchine che vorrete mantenere sincronizzate, da utilizzare con DRBD.
Se non ne avete una potrete comunque provare creando un loop device (questo crea un loop device da 10GB):

shell# dd if=/dev/zero of=/home/drbdloop bs=1024 count=10485760
shell# losetup /dev/loop0 /home/drbdloop

In questo modo avrete un device (/dev/loop0) da utilizzare come disco per DRBD.

Compilazione di DRBD

shell# cd /usr/src
shell# wget http://oss.linbit.com/drbd/8.3/drbd-8.3.1.tar.gz
shell# tar -zxf drbd-8.3.1.tar.gz
shell# cd drbd-8.3.1
shell# make rpm

Nel mio caso mi è stato dato un errore perchè nel mio sistema mancava flex.

errore: Compilazione dipendenze fallita:
flex necessita di drbd-8.3.1-3.i386

In realtà l’errore italiano è tradotto male. Il problema è l’esatto opposto. E’ sufficiente installare flex e ripetere il make:

shell# yum install flex
Installato:
  flex.i386 0:2.5.35-2.fc9
shell# make rpm
[ COMPILAZIONE ]
+ exit 0
You have now:
-rw-r--r-- 1 root root 185530  3 apr 11:23 dist/RPMS/i386/drbd-8.3.1-3.i386.rpm
-rw-r--r-- 1 root root 304874  3 apr 11:23 dist/RPMS/i386/drbd-debuginfo-8.3.1-3.i386.rpm
-rw-r--r-- 1 root root 154010  3 apr 11:23 dist/RPMS/i386/drbd-km-2.6.28.4_custom_std_ipv4_32_mod-8.3.1-3.i386.rpm

A questo punto sarà sufficiente installare drbd (i tools) e drbd-km (il modulo del kernel).

Installazione di DRBD

shell# rpm -Uvh --force dist/RPMS/i386/drbd-8.3.1-3.i386.rpm dist/RPMS/i386/drbd-km-2.6.28.4_custom_std_ipv4_32_mod-8.3.1-3.i386.rpm
errore: Dipendenze fallite:
        kernel necessita di drbd-km-2.6.28.4_custom_std_ipv4_32_mod-8.3.1-3.i386

La distribuzione di fedora core 9 fatta da OVH non include un pacchetto kernel, ma noi abbiamo installato il kernel manualmente e quindi forziamo l’installazione.

shell# rpm -Uvh --nodeps dist/RPMS/i386/drbd-8.3.1-3.i386.rpm dist/RPMS/i386/drbd-km-2.6.28.4_custom_std_ipv4_32_mod-8.3.1-3.i386.rpm
Preparazione in corso...    ########################################### [100%]
   1:drbd                   ########################################### [ 50%]
   2:drbd-km-2.6.28.4_custom########################################### [100%]
shell#

Ogni volta che cambierete il kernel dovrete ripetere questa procedura ed installare il nuovo modulo del kernel (ne possono coesistere più di uno).

Failover di un sistema con DRBD

Configurazione DRBD

D’ora in poi ipotizzerò che le due macchine siano rXXXX1.ovh.net e rXXXX2.ovh.net, che l’IP delle due macchine sia rispettivamente 87.98.XXX.101 e 87.98.XXX.102 e che per entrambe le macchine la partizione di cui tenere il mirror sia /dev/sda5.

Innanzitutto dovremo configurare la risorsa (che chiamo “r0″ ma alla quale potrete assegnare il nome che preferite) su /etc/mrtg.conf

resource r0 {
  protocol C;
  startup { degr-wfc-timeout 120; }
  syncer { rate 3M; al-extents 257; }
  on rXXXX1.ovh.net {
    device /dev/drbd0;
    disk /dev/sda5;
    address 87.98.XXX.101:7789;
    meta-disk internal;
  }
  on rXXXX2.ovh.net {
    device /dev/drbd0;
    disk /dev/sda5;
    address 87.98.XXX.102:7789;
    meta-disk internal;
  }
}

Una volta configurato possiamo preparare il disco con i metadati di DRBD ed attivare la risorsa:

shell# drbdadm create-md r0
shell# drbdadm up r0

Fate la stessa cosa sul secondo server e poi, sul server che volete sia il primario (quello che potrà montare la partizione) fate:

shell# drbdadm -- -o primary r0

Ora /dev/drbd0 è un dispositivo a blocchi (disco virtuale) valido e possiamo procedere nella formattazione:

shell# mkfs.ext3 /dev/drbd0

A questo punto potrete montare il disco ed utilizzarlo

shell# mkdir /mnt/discoha
shell# mount /dev/drbd0 /mnt/discoha

Se non volete rischiare di perdere tutti i dati per un comando errato è d’obbligo la lettura del manuale, per una buona comprensione dello stato di connessione, dello stato dei dischi e dello stato della sincronizzazione.

Se vi interessano configurazioni master-master in cui entrambi gli host possono usare contemporaneamente il disco allora avrete bisogno di una filesystem distribuita come OCFS2 o GFS: leggete l’articolo di GuiGui che riporto in fondo all’articolo per un esempio.

Riferimenti

Dal manuale – Building a DRBD RPM package
Articolo di GuiGui -
Mise en oeuvre d’un système de fichier distribué et accès concurrents en SAN avec DRBD, ISCSI ,OCFS2 et DM-Multipath

Nessun articolo simile

OVH + VMware

Prerequisiti

Innanzitutto dovete aver configurato un kernel modulare e installato vmware server con supporto per bridge e hostonly.

Inoltre potreste dover aggiungere altri IP failover da assegnare alle macchine virtuali.

Abilitare il forwarding

Verificate se ip_forware il proxy_arp sono abilitati:

shell# cat /proc/sys/net/ipv4/ip_forward
1
shell# cat /proc/sys/net/ipv4/conf/vmnet1/proxy_arp
1

Se è già così saltate questa sezione, altrimenti dovrete abilitarli.

shell# vi /etc/sysctl.conf

Aggiungete (o modificate se sono già presenti) queste due direttive:

net.ipv4.ip_forward = 1
net.ipv4.conf.vmnet1.proxy_arp=1

ricaricate le impostazioni con sysctl -p e verificate che i “cat” precedenti ora restituiscano 1. Se non è così potreste avere un kernel configurato male (mancanza del supporto iptables per il forwarding).

Aggiungere il routing dell’IP FailOver

Se in precedenza avete assegnato l’IP failover ad un alias della scheda dummy0 dovrete rimuoverlo, ad esempio:

shell# rm /etc/sysconfig/network-scripts/ifcfg-dummy0:0
shell# ifconfig dummy0:0 down

A questo punto dobbiamo aggiungere il routing per l’IP failover con

shell# route add [IPFAILOVER] dev vmnet1

A questo punto la macchina virtuale dovrebbe essere raggiungibile dall’esterno e viceversa, se invece la dovete configurare seguitemi al prossimo paragrafo.

Configurare la rete nel Guest OS

La configurazione di un guest è la seguente:
IP: [IPDIFAILOVER]
GATEWAY: [IPDIFAILOVER]
NETMASK: 255.255.255.255
E’ poi necessario assicurarsi che esista un routing di default verso la scheda di rete.

Se il guestOS è una fedora come per me allora dovrete configurare l’IP in /etc/sysconfig/network-scripts/ifcfg-eth0

shell# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
NETMASK=255.255.255.255
IPADDR=XX.XXX.XXX.XXX (IP FAILOVER)
USERCTL=no
IPV6INIT=no
NM_CONTROLLED=no
TYPE=Ethernet
GATEWAY=XX.XXX.XXX.XXX (IP FAILOVER)

e poi dovrete creare la route di default

shell# echo "default dev eth0" > /etc/sysconfig/network-scripts/route-eth0

riavviando il servizio di rete dovrebbe funzionare tutto:

shell# service network restart

Automatizzare la configurazione al boot

Le istruzioni date fino ad ora non rendono persistenti le modifiche e quindi al primo riavvio dovrete ripeterle.

Come suggerito da Superkikim nell’articolo linkato prima ho creato un file routes.conf dove ho inserito l’elenco degli IP FailOver da assegnare alle VM:

shell# echo [IPFAILOVER] >> /etc/vmware/routes.conf

Invece di modificare l’init script di vmware ho preferito creare uno script /etc/rc.d/init.d/vmware-routes che si preoccupa di leggere quel file ed applicare le modifiche necessarie. Lo potete trovare qui.

Rendiamo lo script eseguibile ed aggiungiamolo alla sequenza di boot

shell# chmod 775 /etc/rc.d/init.d/vmware-routes

shell# chkconfig --add vmware-routes

Se avete vmware avviato potete provarlo e verificare che abbia funzionato con

shell# service vmware-routes start
shell# route -n

L’ultima riga vi fornisce le route presenti e dovreste vedere, per ogni IP che avete scelto, una riga che dice che è assegnato alla vmnet1.

Troubleshooting

net.ipv4.conf.default.forwarding

Ho letto che qualcuno aggiunge anche queste due direttive al sysctl.conf, io non le ho.

net.ipv4.conf.default.forwarding=1
net.ipv4.conf.all.forwarding=1

FTP backup di OVH dalle macchine virtuali non funziona

Superkikim suggerisce di utilizzare questa regola iptables per poter utilizzare l’FTP backup di OVH dall’interno delle macchine virtuali:

shell# iptables -t nat -A POSTROUTING --source [IPFAILOVER] --match iprange --dst-range [IPFTPBACKUP] -j SNAT --to [IPDEDICATO]

In pratica solo per i pacchetti destinati all’FTP backup viene fatto NAT e non routing così che l’FTP backup accetti la connessione.
Questa regola può essere aggiunta nello script vmware-routes.

netmask 255.255.255.255 in Windows

In Windows non è possibile applicare la netmask 255.255.255.255 via interfaccia. Bisogna quindi impostare la 255.255.255.0 e poi sistemarla tramite regedit.

La rete del guest non va in Fedora Core 10

Nel mio caso (Fedora Core 10) il guestOS non otteneva correttamente l’indirizzo perchè il servizio NetworkManager provava ad ottenerne uno in DHCP e la gestione della rete HostOnly di VMWareServer ne assegnava uno nella rete privata della vmnet dell’host. Ho rimosso tutti i pacchetti relativi a NetworkManager ed ho attivato il servizio network standard

shell# chkconfig --levels 235 network on

Riferimenti

Articolo di GuiGui – OVH, Ip Failover dans une machine virtuelle VMWare

Nessun articolo simile

OVH, importante società di hosting francese che da poco ha aperto una filiale italiana, vende un servizio chiamato Real Private Server (RPS).
Di fatto si tratta di una macchina dedicata con l’unica differenza che il disco non è interno ma piuttosto viene utilizzato il protocollo iSCSI (e come opzione NFS) per utilizzare un disco di rete.

Il Real Private Server di OVH in breve

Questa soluzione permette di avere grandi prestazioni in termini di calcolo e memoria (pari ad un dedicato) e buona affidabilità in termini di disco: senza bisogno di avere soluzioni avanzate di RAID interno i nostri dati sono al sicuro da eventuali crash di dischi con l’unico svantaggio di un accesso non troppo veloce al disco ed una limitata capacità.

In particolare l’accesso al disco avviene sempre tramite la scheda di rete a 100mbps che collega l’RPS ad internet e quindi non potrà in alcun caso superare questa velocità (circa 10MB/s). Il disco di rete predefinito, inoltre, è di soli 10GB, che vi verranno molto stretti se volete installare una macchina virtuale. Io ho approfittato di una offerta presente fino a qualche giorno fa con la quale OVH regalava un disco da 50GB al posto dei 10GB predefiniti, mantenendo il prezzo.

Confronto caratteristiche RPS3, RPS4 e RPS5

Se intendete provare VMWare il mio consiglio è di scegliere almeno una RPS3 che per 20€ al mese vi da 2GB di RAM e un processore dual code AMD che supporta i flag di virtualizzazione (chiamato “svm” nel caso dei processori AMD). Con circa 40€ potete permettervi un server con 4GB di RAM e un AMD Phenom X4. Teniamo sembre presente che più memoria abbiamo più dati del disco riusciremo a cachare e meno la lentezza dell’accesso al disco influirà sulle prestazioni finali. WOW!

Kernel

Gli RPS vengono consegnate con una distribuzione linux a vostra scelta. Io ho scelto Fedora Core 9, poichè utilizzo redhat/fedora da circa 10 anni e la conosco meglio e poi, in questo caso, torna utile il supporto per i pacchetti RPM.

Innanzitutto per poter installare VMWare Server è necessario che il kernel del sistema supporti il caricamento dinamico di moduli e il dispositivo /dev/rtc (Real Time Clock). I kernel predefiniti presenti nel netboot degli RPS non supportano i moduli e quindi dovrete compilare ed installare un kernel personalizzato.

Assicuratevi quindi che dopo il reboot il comando “lsmod” non restituisca errore e che il device /dev/rtc esista (ls /dev/rtc)

shell# lsmod
Module                  Size  Used by
iptable_filter          3072  0
ip_tables              11920  1 iptable_filter
....

shell# ls -al /dev/rtc
lrwxrwxrwx 1 root root 4  2 apr 02:00 /dev/rtc -> rtc0

Download di VMware Server 2.0.1

VMWare Server 2.0

Vi consiglio di eseguire la procedura di registrazione sul sito di vmware così da ottenere una login e password da utilizzare per scaricare il file dal vostro server e la chiave di registrazione.

Sito VMWare - Download e chiave licenza

Una volta ottenuta la login/password e i codici di licenza per la versione linux potrete, direttamente dal server scaricare il pacchetto rpm:

shell# lynx http://www.vmware.com/go/getserver

Accetate i cookies con “A” (vi verrà chiesto un paio di volte), trovate il punto dove mettere username e password per poi proseguire con “continue” e a quel punto selezionate la versione RPM per linux e scaricatela con “D”.
Quando vi viene chiesto il nome assicuratevi di cancellare i parametri presenti dopo al “?” così che il file abbia estensione .rpm.
Noterete che il server scarica i quasi 500MB dal sito VMWare a 10MB/s ma li salva in memoria. Quando andrete a salvararli su disco ci metterà altrettanto tempo (anche l’accesso al disco è a 10MB/s circa!! ).

Installazione

shell# rpm -Uvh VMware-server-2.0.1-156745.i386.rpm

Preparazione in corso...   ########################################### [100%]
1:VMware-server          ########################################### [100%]

The installation of VMware Server 2.0.1 for Linux completed successfully.
You can decide to remove this software from your system at any time by
invoking the following command: "rpm -e VMware-server".

Before running VMware Server for the first time, you need to
configure it for your running kernel by invoking the
following command: "/usr/bin/vmware-config.pl".

Enjoy,

--the VMware team

Come suggerito dal testo avviamo poi la configurazione:

shell# /usr/bin/vmware-config.pl
Making sure services for VMware Server are stopped.

Stopping VMware autostart virtual machines:
Virtual machines                                        [FALLITO]
Stopping VMware management services:
VMware Virtual Infrastructure Web Access
VMware Server Host Agent                                [FALLITO]
Stopping VMware services:
VMware Authentication Daemon                            [  OK  ]
Virtual machine monitor                                 [  OK  ]

You must read and accept the End User License Agreement to continue.
Press enter to display it.

Ci viene mostrata l’intera licenza…

Do you accept? (yes/no) yes

Thank you.

None of the pre-built vmmon modules for VMware Server is suitable for your running kernel.  Do you want this program to try to build the vmmon module for your system (you need to have a C compiler installed on your system)? [yes]

Using compiler "/usr/bin/gcc". Use environment variable CC to override.

What is the location of the directory of C header files that match your running kernel?
[/lib/modules/2.6.28.4-custom-std-ipv4-32-mod/build/include]

Extracting the sources of the vmmon module.

Building the vmmon module.

Using 2.6.x kernel build system.
make: [RIMOSSO OUTPUT COMPILAZIONE]
The vmmon module loads perfectly into the running kernel.

None of the pre-built vmci modules for VMware Server is suitable for your running kernel.  Do you want this program to try to build the vmci module for your system (you need to have a C compiler installed on your system)? [yes]

Extracting the sources of the vmci module.

Building the vmci module.

Using 2.6.x kernel build system.
make: [RIMOSSO OUTPUT COMPILAZIONE]
The vmci module loads perfectly into the running kernel.

None of the pre-built vsock modules for VMware Server is suitable for your running kernel.  Do you want this program to try to build the vsock module for your system (you need to have a C compiler installed on your system)? [yes]

Extracting the sources of the vsock module.

Building the vsock module.

Using 2.6.x kernel build system.
make: [RIMOSSO OUTPUT COMPILAZIONE]
The vsock module loads perfectly into the running kernel.
[yes]

A questo punto viene la parte importante della configurazione della rete di VMware. In pratica creiamo una rete Bridged sulla dummy0 (già presente per la gestione dell’IP FailOver nell’RPS) ed una HostOnly lasciando scegliere un IP privato a VMware Server (non useremo questo IP).

Do you want networking for your virtual machines? (yes/no/help) [yes]

Configuring a bridged network for vmnet0.

Please specify a name for this network.
[Bridged]

Your computer has multiple ethernet network interfaces available: dummy0, eth0.
Which one do you want to bridge to vmnet0? [eth0] dummy0

The following bridged networks have been defined:

. vmnet0 is bridged to dummy0

Do you wish to configure another bridged network? (yes/no) [no]

Do you want to be able to use NAT networking in your virtual machines? (yes/no) [yes] no

Do you want to be able to use host-only networking in your virtual machines? [no] yes

Configuring a host-only network for vmnet1.

Please specify a name for this network.
[HostOnly]

Do you want this program to probe for an unused private subnet? (yes/no/help) [yes]

Probing for an unused private subnet (this can take some time)...

The subnet 192.168.219.0/255.255.255.0 appears to be unused.

The following host-only networks have been defined:

. vmnet1 is a host-only network on private subnet 192.168.219.0.

Do you wish to configure another host-only network? (yes/no) [no]

None of the pre-built vmnet modules for VMware Server is suitable for your
running kernel.  Do you want this program to try to build the vmnet module for
your system (you need to have a C compiler installed on your system)? [yes]

Extracting the sources of the vmnet module.

Building the vmnet module.

Using 2.6.x kernel build system.
make: [RIMOSSO OUTPUT COMPILAZIONE]
The vmnet module loads perfectly into the running kernel.

Please specify a port for remote connections to use [902]

You have a pre-existing config.xml.  The new version will be created as
/etc/vmware/hostd/NEW_config.xml.  Please check the new file for any new values
that you may need to migrate to your current config.xml.

Please specify a port for standard http connections to use [8222]

Please specify a port for secure http (https) connections to use [8333]

The current administrative user for VMware Server  is ''.  Would you like to
specify a different administrator? [no]

Using root as the VMware Server administrator.

You have a pre-existing vmInventory.xml.  The new version will be created as
/etc/vmware/hostd/NEW_vmInventory.xml.  Please check the new file for any new
values that you may need to migrate to your current vmInventory.xml.

In which directory do you want to keep your virtual machine files?
[/var/lib/vmware/Virtual Machines] /home/vms

You have a pre-existing datastores.xml.  The new version will be created as
/etc/vmware/hostd/NEW_datastores.xml.  Please check the new file for any new
values that you may need to migrate to your current datastores.xml.

Do you want to enter a serial number now? (yes/no/help) [no] yes

Please enter your 20-character serial number.

Type XXXXX-XXXXX-XXXXX-XXXXX or 'Enter' to cancel:  YYYYY-YYYYY-YYYYY-YYYYY

Creating a new VMware VIX API installer database using the tar4 format.

Installing VMware VIX API.

In which directory do you want to install the VMware VIX API binary files?
[/usr/bin]

In which directory do you want to install the VMware VIX API library files?
[/usr/lib/vmware-vix/lib]

The path "/usr/lib/vmware-vix/lib" does not exist currently. This program is
going to create it, including needed parent directories. Is this what you want?
[yes]

In which directory do you want to install the VMware VIX API document pages?
[/usr/share/doc/vmware-vix]

The path "/usr/share/doc/vmware-vix" does not exist currently. This program is
going to create it, including needed parent directories. Is this what you want?
[yes]

The installation of VMware VIX API 1.6.2 build-156745 for Linux completed
successfully. You can decide to remove this software from your system at any
time by invoking the following command: "/usr/bin/vmware-uninstall-vix.pl".

Enjoy,

--the VMware team

L’installazione prosegue poi avviando vmware:

Starting VMware services:
Virtual machine monitor                                 [  OK  ]
Virtual machine communication interface                 [  OK  ]
VM communication interface socket family:               [  OK  ]
Virtual ethernet                                        [  OK  ]
Bridged networking on /dev/vmnet0                       [  OK  ]
Host-only networking on /dev/vmnet1 (background)        [  OK  ]
DHCP server on /dev/vmnet1                              [  OK  ]
VMware Server Authentication Daemon (background)        [  OK  ]
Shared Memory Available                                 [  OK  ]
Starting VMware management services:
VMware Server Host Agent (background)                   [  OK  ]
VMware Virtual Infrastructure Web Access
Starting VMware autostart virtual machines:
Virtual machines                                        [  OK  ]

The configuration of VMware Server 2.0.1 build-156745 for Linux for this
running kernel completed successfully.

Verifica

Se tutto è andato bene dovreste vedere che vmware ha fatto il bind di parecchie porte:

shell# netstat -lnp | grep '\(vmware\|webA\)'
tcp        0      0 127.0.0.1:8005              0.0.0.0:*                   LISTEN      3253/webAccess
tcp        0      0 0.0.0.0:902                 0.0.0.0:*                   LISTEN      3222/vmware-authdla
tcp        0      0 0.0.0.0:8009                0.0.0.0:*                   LISTEN      3253/webAccess
tcp        0      0 0.0.0.0:8333                0.0.0.0:*                   LISTEN      3346/vmware-hostd
tcp        0      0 127.0.0.1:8307              0.0.0.0:*                   LISTEN      3346/vmware-hostd
tcp        0      0 0.0.0.0:8308                0.0.0.0:*                   LISTEN      3253/webAccess
tcp        0      0 0.0.0.0:8222                0.0.0.0:*                   LISTEN      3346/vmware-hostd

A questo punto aprendo un browser su https://VOSTROSERVER:8333/ui/ dovrebbe apparirvi la richiesta d’accesso al pannello di gestione vmware via web.
Se avete installato il Virtual Infrastructure Client potete alternativamente utilizzare quest’ultimo usando come indirizzo VOSTROSERVER:8333.
Vedremo successivamente come sia possibile disabilitare la gestione web di vmware che utilizza un sacco di memoria sul server.

Se non vi funziona (molto probabile) allora controllate la prossima sezione.

Se vi funziona sappiate che non è ancora finita. Bisogna infatti ancora configurare il nostro server perchè faccia il forwarding dei pacchetti per l’IP failover verso le macchine virtuali e configurare correttamente le macchine virtuali.

Risoluzione problemi

Disabilitazione SELinux

vmware server 2.0 ha problemi con SELinux. I kernel di OVH non supportano SELinux, quindi se non l’avete abilitato voi non dovreste averlo. Se invece ce l’avete e non volete disabilitarlo provate a leggere il changelog di VMware server 2.0.1 che include qualche suggerimento su come sistemare i problemi con SELinux.

Problemi con HALdaemon

Riconoscete questo problema controllando il contenuto del log di vmware:

shell# tail /var/log/vmware/hostd.log
[2009-04-02 19:41:58.793 'Libs' 3077572288 info] HAL05LoadHALLibraries: dlopened libhal.so.1.
[2009-04-02 19:41:58.793 'Libs' 3077572288 info] HAL05LoadHalLibraries: dlopened libdbus-1.so.3.
[2009-04-02 19:41:58.795 'Libs' 3077572288 info] HAL05Init: HAL context initialization failed. Try starting hald as root.

Innanzitutto verificate che haldaemon sia installato e caricato (ps aux | grep hal visualizza processi?).

shell# rpm -qa |grep hal

Non dovrebbe darvi alcun risultato, che significa che non è installato.

shell# yum install hal

Una volta installato provate a riavviare l’RPS. Probabilmente continuerete a vedere lo stesso errore nel log vmware.
Questo succede perchè di default vmware server si avvia con una priorità maggiore rispetto ad haldaemon e questo non gli permette di avviarsi correttamente. E’ quindi necessario modificare l’ordine di avvio così che vmware venga avviato successivamente ad haldaemon.

shell# vi /etc/rc.d/init.d/vmware
( nelle prime righe troverete i parametri chkconfig )
###
# chkconfig: 235 19 08
# description: Manages the services needed to run VMware software
###

Modificate il 19 in 39 così da ritardare maggiormente l’inizializzazione, salvate e avviate la riconfigurazione degli script di avvio:

chkconfig vmware reset

Con ogni probabilità continuerete a vedere questo errore perchè il servizio HAL sembra non partire correttamente. Nel mio caso ho risolto cambiando la priorità di avvio anche per hal:

shell# vi /etc/rc.d/init.d/haldaemon
( nelle prime righe troverete i parametri chkconfig )
###
# chkconfig: 235 26 72
# description: Manages the services needed to run VMware software
###

Modificate il 26 72 in 36 62 così da ritardare maggiormente l’inizializzazione mantenendola comunque prima di vmware (che abbiamo messo a 39), salvate e avviate la riconfigurazione degli script di avvio:

chkconfig haldaemon reset

Risorse

Le risorse, prevalentemente in francese (che non conosco) ma anche in inglese, usate come guida:
Joannes Vermorel’s Installing VMWare Server 2.0 on a OVH RPS
Softilion’s OVH: monter un serveur dédié Windows Server avec une licence déjà acquise par ailleurs via virtualisation VMWare
GuiGui’s VMWare Server 2.0 sur dédiés OVH et mise en oeuvre d’une solution de haute disponibilité avec datastore en DRBD

Nessun articolo simile

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 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.

Nessun articolo simile

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.

Nessun articolo simile

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

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

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.

Nessun articolo simile