Archive for Aprile, 2009
Trasloco di siti, propagazione DNS e Reverse Proxy
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”.
Liberare 240MB di RAM disabilitando la console web di VMware Server 2
La versione 2.0 di VMware Server ha introdotto una nuova interfaccia di gestione via web. Si tratta di una interfaccia molto comoda ed esteticamente molto gradevole che però utilizza, nell’installazione predefinita, 240MB di RAM.
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.
Installare DRBD su un RPS di OVH e Fedora
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
VMware Server is installed, but it has not been (correctly) configured
Ogni volta che parte VMware prova a caricare i propri moduli del kernel e se non riesce si segna che non è stato configurato correttamente e non riprova più fino a che non lo riconfigurate.
shell# service vmware start VMware Server is installed, but it has not been (correctly) configured for the running kernel. To (re-)configure it, invoke the following command: /usr/bin/vmware-config.pl.
Se usate OVH e vi capita di riavviare con un kernel differente (ad esempio via netboot) per fare qualunque cosa e poi tornare al kernel su hd con il quale vmware dovrebbe funzionare ogni volta vmware vi farà questo scherzo perchè quando partite con il netboot non riesce a caricare i propri moduli e si segna che deve essere riconfigurato.
La soluzione è piuttosto semplice: prima di riavviare la macchina con il kernel corretto ricordatevi di cancellare il file “not_configured” che ha creato appena partito con il kernel non modulare:
shell# rm -f /etc/vmware/not_configured
In questo modo vi risparmierete di rilanciare la configurazione e la conseguente ricompilazione ogni volta che fate un netboot!
Se vi dimenticate di farlo prima di riavviare potete farlo anche quando il sistema è già riavviato, ma dopo dovrete avviare vmware manualmente (service vmware start).
Configurare la rete per VMware server e gli IP Failover in un dedicato OVH
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
Pagine
Articoli recenti
Archivi
- Luglio 2009 (1)
- Giugno 2009 (3)
- Maggio 2009 (2)
- Aprile 2009 (8)
- Marzo 2009 (1)