rps
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
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
Installare VMWare Server 2.0.1 su un RPS di OVH
Cos’è OVH e cos’è un RPS
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
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.
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)