Articoli correlati ‘server’

Data Protector installazione client su Ubuntu linux

23 August 2011

Il software di Backup Data Protector di HP è certificato per funzionare, come client, sotto sistemi linux Suse Enterprise e Red Hat Enterprise. Quindi abbiamo dei pacchetti di distribuzione tar.gz e rpm, non certo l’ideale per un sistema Debian like come Ubuntu. Saranno sufficienti lo stesso per installare un funzionale client per effettuare il backup.

Innanzitutto occorre avere a disposizione i cd di Data Protector etichettati come Solaris e Linux e HP UX. Nel caso in esempio abbiamo preso in esame la versione 6.11, mentre Ubuntu Linux è la versione 10.04 Server, che dovrà essere risolta in reverse DNS come pre-requisito iniziale.

Per iniziare abbiamo bisogno di installare il pacchetto RPM e Xinetd che si occuperà di “ascoltare” le richieste dal Data Protector.

sudo apt-get update
sudo apt-get install rpm xinetd

RPM necessita di una piccola modifica, infatti dobbiamo lanciare il comando con l’opzione –force-debian, quindi automatizzeremo le operazioni. Per prima cosa rinominiamo l’eseguibile:

sudo mv /usr/bin/rpm /usr/bin/rpm-ori

Ora creiamo un file (sudo vi /usr/bin/rpm) che si chiamerà rpm con il contenuto:

#!/bin/sh
/usr/bin/rpm-ori --force-debian $@

Rendiamo eseguibile il file appena creato:

sudo chmod 755 /usr/bin/rpm

Prima di procedere all’installazione vera e propria verifichiamo che la porta 5555 del servizio xinetd sia libera (verrà usata appunto per attendere le istruzioni dal server di Data Protector). Con un editor di testo apriamo il file /etc/services e commentiamo:

#rplay 5555/udp # RPlay audio service

Ora possiamo caricare il cdrom (noi abbiamo usato quello denominato HP-UX), montarlo nel sistema e avviare l’installazione indicando il server e quali componenti installare.

sudo mount /dev/cdrom/ /media/cdrom
cd /media/cdrom/LOCAL_INSTALL
sudo ./omnisetup.sh -server FQDN.server.dataprotector -install da

dove modificheremo ovviamente FQDN.server.dataprotector con il nome del server in questione, mentre per i componenti sarà sufficiente indicare quali scegliere (da = disk agent). Si otterrà un output simile a questo:

  Data Protector version A.06.11 found
  Client detected, installed packets:  da

  Packets going to be installed: omnicf da

  Unpacking selected packets from CD, please wait (5-10 minutes)...
  Unpacking complete!

Data Protector software package successfully installed
  Installing Disk Agent (da)...

Data Protector software package successfully installed
  Importing client to FQDN.server.dataprotector...
Import host successful.

  Installation/Upgrade session finished.

Abbiamo quasi concluso, con l’operazione precedente avremo già inserito tra i client noti all’interno di Data Protector il nostro server Linux (dovreste vederlo attivo alla voce client) tuttavia nel caso abbiate partizionato il vostro sistema con il filesystem Ext4 serve ancora una piccola modifica. Per qualche motivo Ext4 non è tra i filesystem elencati. Dovremo semplicemente indicarlo con una piccola modifica.. In caso contrario vi ritroverete durante il backup un errore simile a “All mountpoints on host “x.y.z” are excluded.“.
Il workaround richiede di modificare il file che si trova sotto /opt/omni/lbin/.util
Alla riga 351 troveremo un comando piuttosto lungo dove sono elencati i vari filesystem. Aggiungeremo dopo -t ext3 il nostro ext4 e la stringa dovrà essere come segue:

/bin/df -P -t ext2 -t SFS -t ext -t minix -t xiafs -t reiserfs -t ext3 -t ext4 -t vfat -t vxfs -t xfs 2>/dev/null | sed '1d' | awk '{print $6}'

A questo punto serve un ulteriore verifica di buon funzionamento. Nel nostro caso il servizio sulla porta 5555 non era attivo, infatti dando il comando netstat -vantp questa non compariva tra quelle attive in ascolto. Forse un bug non ha scritto la porta nel file /etc/xinetd.d/omni. Editato con il nostro solito editor avremo cura che appaia come segue:

service omni
{
disable = no
id = omni
socket_type = stream
protocol = tcp
user = root
wait = no
server = /opt/omni/lbin/inet
server_args = -log /var/opt/omni/log/inet.log
port = 5555
}

Riavviamo il servizio sudo /etc/inet.d/xinetd restart e abbiamo concluso il lavoro nel nostro sistema operativo. Dalla Gui di Data Protector ora siamo pronti a creare e lanciare il backup del server Ubuntu.

iLO firmware is in a network flash recovery state

6 July 2011

Mi è capitato di trovarmi con la iLO (server HP) letteralmente bloccata. Entrando con il browser web la situazione che mi trovavo era un messaggio scritto in XML che recitava:

The iLO firmware is in a network flash recovery state.
Refer to the iLO network flash recovery under the trouble shooting section in the iLO users guide.

La situazione è che il firmware che carica appunto il sottosistema iLO è probabilmente corrotto. Tuttavia dovreste comunque pingare lo stesso la sua interfaccia IP. Questo significa che lo potrete ancora raggiungere via FTP e caricare una immagine sana, senza tra l’altro perdere le impostazioni precedentemente caricate, poiché sono memorizzate in altra area. Quindi per prima cosa è necessario recuperare il firmware dal sito di HP. Solitamente sta dentro i pacchetti per Windows sotto un falso eseguibile. Io, da ambiente Ubuntu Linux, ho scaricato uno di questi, scompattato in una cartella e tra i vari files al suo interno ho individuato quello che mi interessava e che corrisponde al nome di ilo194.bin

Abbiamo notato che è altamente consigliato di re-inserire la versione di firmware ospitata prima del blocco e non una nuova.
A questo punto si procede come segue:

ftp 192.168.1.1
Connected to 192.168.1.1.
220 FTP flash recovery server ready.
Name: flash
331 Password required.
Password: recovery
231 User name accepted.
ftp binary
200 OK.
ftp put /home/walter/Downloads/ilo194.bin
local: /home/walter/Downloads/ilo194.bin remote: /home/walter/Downloads/ilo194.bin
200 OK.
150 ready to take file.
226-Image is valid
226-Flashing part  1 of 31
..cut
226-Flashing part 31 of 31
226 Image programmed.
2097152 bytes sent in 3.67 secs (557.8 kB/s)

Come vedete abbiamo usato un ftp in modalità binaria, inserito le credenziali username: flash e password: recovery quindi con il comando put caricato il file ilo194.bin

Se tutto è andato bene la iLO verrà resettata e potrete accedere normalmente al sistema.

Muovere i servizi di Windows Cluster via command line

5 August 2009

Nell’amministrazione di un cluster sotto ambiente Windows Server Enterprise, può capitare che a seguito dell’installazione di una patch sia necessario riavviare la macchina. Il movimento dei gruppi (leggi come servizi erogati) da un nodo all’altro significa comunque un disservizio anche se molto limitato nel tempo (solitamente qualche secondo).
Ad esempio, spostare un gruppo che contiene il servizio di posta Microsoft Exchange, comporterà per parecchi client l’avviso sul desktop di perdita e ripristino della connessione. Decisamente seccante se non volete ricevere chiamate d’assistenza totalmetne inutili.

In questo caso si può “spostare” nel tempo il momento in cui potremo cambiare nodo, ad esempio dopo l’orario di lavoro, anche se noi non siamo fisicamente presenti. Per fare questo ci viene in aiuto la command-line, che potremo schedulare comodamente con lo scheduler di windows.

Sotto la directory C:\Windows\System32 è presente il file cluster.exe che di fatto permette di effettuare le operazioni sul cluster non solo tramite la GUI ma anche via command-line.

Potrete trovare documentazione aggiuntiva presso la Technet Microsoft a questa pagina. Oppure un sunto dell’help alla fine di questo articolo.

Procediamo a vedere come si muove un gruppo di un cluster. Poniamo che il cluster si chiami MYCLUSTER, e i nodi fisici si chiamino NODE1 e NODE2. Per il gruppo solitamente troviamo MSDTC e ClusterGroup.

Il comando che daremo sarà:
C:\WINDOWS\system32>cluster.exe /cluster:MYCLUSTER group “MSDTC” /moveto:NODE02

Quindi ricapitolando, basterà che modifichiate MYCLUSTER, NODE02 e MSDTC con le nomenclature che avete scelto. Notare che il gruppo va racchiuso tra virgolette, questo perchè i nodi talvolta sono insiemi di parole, tipo “Cluster Group”.

Sicuramente la successiva domanda sarà, già ma un cluster difficilmente è composto da un solo gruppo, visto che è buona norma usare appunto un gruppo per il cluster, uno per l’MSDTC e uno per il servizio erogato.
In questo caso è possibile “raggruppare” i gruppi, come descritto in questa pagina del technet, con questo comando:
cluster MYCLUSTER group “disk group 1″ /prop AntiAffinityClassNames=”SEP1″
cluster MYCLUSTER group “disk group 2″ /prop AntiAffinityClassNames=”SEP1″

Possiamo anche fare più associazioni, anche incrociate, modificando il valore “SEP1″

Un estratto dell’help di cluster.exe

C:\WINDOWS\system32>cluster.exe -?
The syntax of this command is:

CLUSTER /LIST[:domain-name]

CLUSTER /CHANGEPASS[WORD] /?
CLUSTER /CHANGEPASS[WORD] /HELP
CLUSTER /CLUSTER:clustername1[,clustername2[,...]]
/CHANGEPASS[WORD][:newpassword[,oldpassword]]

=
[/FORCE] [/QUIET] [/SKIPDC] [/TEST] [/VERB[OSE]] [/UNATTEND[ED]] [/?] [/HELP]

CLUSTER [/CLUSTER:]cluster-name

=
/CREATE [/NODE:node-name] [/VERB[OSE]] [/UNATTEND[ED]] [/MIN[IMUM]]
/USER:domain\username | username@domain [/PASS[WORD]:password]
/IPADDR[ESS]:xxx.xxx.xxx.xxx[,xxx.xxx.xxx.xxx,network-connection-name]
/ADD[NODES][:node-name[,node-name ...]] [/VERB[OSE]] [/UNATTEND[ED]]
[/MIN[IMUM]] [/PASSWORD:service-account-password]

CLUSTER [[/CLUSTER:]cluster-name]

=
/CREATE [/NODE:node-name] /WIZ[ARD] [/MIN[IMUM]]
[/USER:domain\username | username@domain] [/PASS[WORD]:password]
[/IPADDR[ESS]:xxx.xxx.xxx.xxx]
/ADD[NODES][:node-name[,node-name ...]] /WIZ[ARD] [/MIN[IMUM]]
[/PASSWORD:service-account-password]
/PROP[ERTIES] []
/PRIV[PROPERTIES] []
/PROP[ERTIES][:propname[,propname ...] /USEDEFAULT]
/PRIV[PROPERTIES][:propname[,propname ...] /USEDEFAULT]
/REN[AME]:cluster-name
/QUORUM[RESOURCE][:resource-name] [/PATH:path] [/MAXLOGSIZE:max-size-kbytes]
/SETFAIL[UREACTIONS][:node-name[,node-name ...]]
/LISTNETPRI[ORITY]
/SETNETPRI[ORITY]:net[,net ...]
/REG[ADMIN]EXT:admin-extension-dll[,admin-extension-dll ...]
/UNREG[ADMIN]EXT:admin-extension-dll[,admin-extension-dll ...]
/VER[SION]
NODE [node-name] node-command
GROUP [group-name] group-command
RES[OURCE] [resource-name] resource-command
{RESOURCETYPE|RESTYPE} [resourcetype-name] resourcetype-command
NET[WORK] [network-name] network-command
NETINT[ERFACE] [interface-name] interface-command

=
name=value[,value ...][:] [name=value[,value ...][:] …]

=
BINARY|DWORD|STR[ING]|EXPANDSTR[ING]|MULTISTR[ING]|SECURITY|ULARGE

CLUSTER /?
CLUSTER /HELP

Note: With the /CREATE, /ADDNODES, and /CHANGEPASSWORD options, you
will be prompted for passwords not provided on the command line
unless you also specify the /UNATTENDED option.

The cluster node already exists

5 August 2009

Puo’ capitare che nella creazione di un nodo cluster, specie dopo un recovery da backup o una nuova installazione, si incappi in questo errore che non permette di fatto alla macchina di essere aggiunta, come nodo, al cluster.

Per uscire da questa empasse, per prima cosa controllate che il disco di quorum sia online e caricato sul nodo funzionante, poi eseguite questa operazione che però NON E’ REVERSIBILE
  1. start, quindi Run (esegui), date il comando CMD
  2. scrivete il comando “cluster node/forcecleanup” e date invio
  3. dovrebbe apparire il messaggio “clean up successufully completed
  4. ripetete l’operazione di aggiunta del nodo al cluster