XenServer 7 software RAID con mail alert

You can also read this article in english.
XenServer 7 si sta imponendo come l’implementazione di riferimento dell’Hypervisor open source Xen, fornendo funzionalità avanzate di storage, networking e gestione (oltre che HA) pacchettizzate in una soluzione totalmente self-contained e di livello enterprise; il tutto, risultando spesso superiore a VMware vSphere e ad HyperV e KVM, gli altri big player del settore.

Giusto per ricordarlo, Xen è l’Hypervisor che funge da motore per la maggior parte dei cloud pubblici (da AWS in giù), è totalmente open source e la sua declinazione XenServer è ora gestita direttamente dalla Linux Foundation (non più da CITRIX),  risultando de facto la soluzione standard per la virtualizzazione bare-metal FLOSS.

Potenti batterie incluse!

Nella versione 7, l’adozione di una CentOS 7 modificata come dom0 ha fatto fare passi da gigante allo stack software che circonda il microkernel Xen… difatti, l’installazione standard di XS7 include già tutti gli elementi del puzzle necessari per poter saltare a piè pari una soluzione RAID hardware e tuffarci nelle meraviglie del software RAID! MDADM, ad oggi, è una delle pochissime alternative per creare array fra dischi NVMe o gestire altre configurazioni di nicchia e/o con un forte stress sulle performance; grazie alle CPU moderne, il software RAID (specie su grossi array, e naturalmente con diverse peculiarità) gioca spesso alla pari con gli ASICS dei più rinomati controllers.

Il RAID software consente inoltre di creare array utilizzando dischi di qualsiasi brand (anche non certificati per il vostro server), cosa che da un vantaggio strategico a XS rispetto a prodotti come VMware, che invece permettono al più di creare RAIN  tramite add-on a pagamento come vSAN. Se avete mai comparato i costi dei dischi branded (HP, IBM, Dell, ecc.) VS gli stessi modelli off-the-shelf (in special modo SSD), capirete bene quale possa essere il vantaggio economico.

Dive into MDADM

Il workflow da seguire per realizzare una soluzione RAID software di livello enterprise su XS7 che ci avviserà in automatico di eventuali malfunzionamenti, è molto semplice:

  • creazione di un array con MDADM;
  • configurazione di SSMTP per l’invio di notifiche;
  • test dell’invio notifiche e fault-rebuild dell’array;
  • aggiunta dell’array come SR.

MDADM è un software veramente battle-tested; incluso nel kernel linux da moltissimi anni, si è guadagnato sul campo la sua fama di stack molto stabile e privo di bugs importanti, tant’è che viene da anni utilizzato in grossi sistemi di produzione (degni di nota sopratutto i “big irons x86” dell’ultimo quinquennio), nonché nella maggior parte dei NAS commerciali (Synology, QNAP, Buffalo, ecc).

Risultando già incluso nella installazione standard di XS7, creare un array RAID risulta semplicissimo nel tipico scenario in cui avete installato l’Hypervisor su un drive USB che non farà parte dell’array… come da best practice! E voi seguite le best practices, no? Ne faccio cenno anche qui.

Ad esempio, nel caso in cui volessimo creare un array RAID 10 con i primi quattro HDD del sistema, basterà eseguire

 mdadm --create /dev/md0 --run --level=10 --raid-devices=4 /dev/sd[a,b,c,d] 

e, per monitorare la costruzione dell’array,

 watch cat /proc/mdstat 

oppure il sempreverde

 mdadm --detail /dev/md0

che, inoltre, ci fornisce varie informazioni sullo status del nostro array.

Ti fidi di un sistema che non ti avvisa se c’è un guasto?

Settiamo io monitoraggio dell’array; intanto, copiamo la configurazione attiva nel file di configurazione di MDADM

 mdadm --verbose --detail --scan >> /etc/mdadm.conf 

questo attiva il monitoring dell’array con le caratteristiche specificate. Quindi, configuriamo SSMTP per l’invio della posta ad un nostro indirizzo e-mail.

A titolo di esempio, la seguente configurazione del file /etc/ssmtp/ssmtp.conf è utilizzabile per l’invio delle notifiche da un indirizzo gmail:

 
root=vostra_mail@gmail.com
mailhub=smtp.gmail.com:587
Hostname=vostro_hostname.vostrodominio.sth
UseTLS=YES
TLS_CA_File=/etc/pki/tls/certs/ca-bundle.crt
UseSTARTTLS=YES
AuthUser=vostra_mail@gmail.com
AuthPass=vostra_password
FromLineOverride=YES

È importante non dimenticare di configurare anche il file /etc/ssmtp/revaliases con una riga come la seguente:

 root:vostra_mail@gmail.com:smtp.gmail.com:587 

Infine, è necessario aggiungere i parametri MAILADDR e MAILFROM nelle ultime righe di /etc/mdadm.conf, in modo che il file risultante sia assimilabile a questo modello:

 
ARRAY /dev/md0 level=raid10 num-devices=4 metadata=1.2 name=vostro_hostname:0 UUID=UUID_ARRAY
    devices=/dev/sda,/dev/sdb,/dev/sdc,/dev/sdd
MAILADDR mail_di_destinazione@provider.sth
MAILFROM vostra_mail@gmail.com

Che setup sarebbe, senza nute… senza testing?

Ora che la configurazione è completata, possiamo testarla; MDADM può eseguire l’invio di una mail di test del sottosistema di notifiche con

 mdadm --monitor --scan --test --oneshot 

; in generale, il test è affidabile, ma se volete potete anche mettere in status “failed” uno dei dischi (attenzione ai tempi di rebuild) con

 mdadm --manage --set-faulty /dev/mdo /dev/sdb mdadm --manage /dev/md0 --add /dev/sdb 

Raccomando di attendere la notifica via mail per una decina di minuti, il demone è giustamente un po “lazy” nel riconoscere il fail, anche quando simulato.

Ora che l’array è testato e pronto all’uso, basta aggiungerlo agli SR utilizzabili da XenServer con un semplice

 xe sr-create content-type=user device-config:device=/dev/md0  name-label="Local RAID10" shared=false type=lvm 

In XS7 l’array viene riconosciuto al reboot senza dover forzare il caricamento di moduli o altre configurazioni particolari, tutto è semplicemente pronto all’uso.

 

Il problema del giorno: updates Windows 10 rompono la compatibilità con SAP B1

Se dopo un aggiornamento automatico di Windows 10 il client di SAP B1 (versione <9.2) vi riporta un errore come il seguente,

SAP B1 Error

non disperate! La radice della causa sta in una patch di Windows che ha deprecato una serie di certificati crittografici, considerati tecnologicamente obsoleti.

Sulla SCN di SAP consigliano (ad esempio qui e qui) di disinstallare gli aggiornamenti KB3163018KB3163017, ma potreste trovarvi nella caso in cui queste KB non risultano installate; questo poiché l’aggiornamento vi è stato somministrato tramite un’altra combinazione di patch cumulate, le quali risultano avere altri (vari!) identificativi di riferimento.

In tal caso, disinstallate in ordine anti-cronologico gli aggiornamenti di sicurezza di Windows; dalla mia esperienza, rimuovendo tutto quanto installato dopo Giugno 2016 il client torna a funzionare correttamente.