rps

Installare DRBD su un RPS di OVH e Fedora

Configurazione standard DRBD

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

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

Tags: , , , , ,

lunedì, aprile 6th, 2009 Sysadmin Nessun commento

Configurare la rete per VMware server e gli IP Failover in un dedicato OVH

OVH + VMware

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

Tags: , , , , ,

sabato, aprile 4th, 2009 Sysadmin 2 Comments

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

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

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

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

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

Tags: , , , ,

venerdì, aprile 3rd, 2009 Sysadmin 2 Comments

Utilizzare IP failover su un RPS

Pannello di controllo servizi OVH

Pannello di controllo servizi OVH

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

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

Come e perchè

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

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

Pannello di controllo degli IP FailOver sul Manager di OVH

Pannello di controllo degli IP FailOver sul Manager di OVH

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

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

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

Configurazione di un IP FailOver su Fedora Core 9

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

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

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

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

shell# ./ifup-aliases dummy0

E verificare che abbia funzionato:

shell# ifconfig dummy0:1

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

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

Next

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

Tags: , , , ,

giovedì, aprile 2nd, 2009 Sysadmin Nessun commento

Installare un kernel modulare su un RPS di OVH

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

Pagina di gestione del netboot nel manager v3 di OVH

Gestione del netboot nel manager v3 di OVH

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

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

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

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

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

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

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

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

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

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

Interfaccia ncurses della riconfigurazione del kernel

Interfaccia ncurses della riconfigurazione del kernel


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

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

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

Scelta del suffisso del kernel

Scelta del suffisso del kernel


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

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

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

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

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

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

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

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

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


# salviamo ed aggiorniamo il bootloader:
lilo -v

# risultato del comando lilo

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

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

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

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

Tags: , , ,

martedì, marzo 31st, 2009 Sysadmin 4 Comments