Breve luna di miele con il Surface 4, dal punto di vista di un sysadmin

Sono stato tentato dall’offerta del volantino UniEuro, per il Surface 4 core M3 (4Gb di RAM) con tastiera-cover e punte per la penna incluse.

L’idea era quella di affiancarlo al mio fido MBP Late 2011, che per le sue dimensioni ricade oggi nella categoria “mobile workstation”… il Surface promette di coniugare la portabilità di un tablet alla funzionalità di un classico laptop, candidandosi a diventare il mio endpoint leggero di riferimento.

Anbocsing

Il Surface 4 m3, appena sballato
Il Surface 4 M3, appena sballato

La confezione è molto curata, Apple-style.

Il dispositivo arriva già parzialmente carico; il caricabatterie è piccolo e leggero, mentre il peso del tablet è decisamente più alto rispetto ad un iPad air.

Il meccanismo di aggancio della tastiera è comodo e veloce, anche se non è nulla di paragonabile alle sensazioni “unibody” alle quali sono abituato da un po’. Il primo avvio non è stato privo di difficoltà: durante la configurazione iniziale ho chiuso inavvertitamente la cover appena dopo la configurazione di Windows Hello, ritrovandomi con un sistema sostanzialmente inutilizzabile.

S’è rott? / Impressioni di Dicembre

Dopo un paio di riavvii forzati (l’utente medio l’avrebbe mandato in assistenza), il dispositivo è tornato alla vita ed ha completato la configurazione.
C’è da dire che l’ottimizzazione di Windows per l’hardware è davvero ottima, il core M3 non fatica nel multitasking, neanche quando questo consiste in un paio di macchine virtuali Linux sotto VirtualBox, più Netflix e diverse applicazioni in esecuzione: brava Microsoft!

Lo schermo è fantastico, veramente spettacolare quanto a colori e risoluzione, nonché risposta al tocco. Solo un po’ di lag rispetto ai dispositivi con iOS. Le camere sono entrambe ottime. Voglio puntualizzare come il riconoscimento facciale non sbagli un colpo, impressionante.

Di contro, la modalità tablet di Windows 10 è del tutto inutile e anche la penna non mi ha convinto granché; dopo averci giocato un quarto d’ora, ci si chiede quale sia il modo migliore per non perderla.

Un’altra problematica, forse la più grande, è il form factor. Non riesco a trovare alcun modo per inserire questo oggetto nel mio workflow quotidiano: il dispositivo è troppo grande come tablet (rischia di scivolare dalle mani e non si impugna facilmente), il kickstand è macchinoso e scomodo da usare. Per posizionare il dispositivo su un piano servono due mani (?!), bisogna fare diversi movimenti poco comodi, niente a che spartire con la semplicità operativa di un tradizionale laptop clamshell.

La tastiera non “portante” rende inoltre impossibile prendere il convertibile dalla base: la distribuzione dei pesi è semplicemente sbagliata se si pensa al tipico use-case nel quale ci si sposta fra una scrivania all’altra o fra i ripiani di un rack. Peccato, perché la digitazione non è male per una tastiera leggera e flessibile come questa. Con questa distribuzione dei pesi, l’unica modalità di utilizzo sensata sarebbe stata quella da tablet puro, mal supportata da Windows 10.

L’ultima pecca, abbastanza ovvia: la macchina ha un supporto a Linux abbastanza scadente, l’unico modo per utilizzare decentemente il pinguino è in macchina virtuale. Il sottosistema Linux per Windows è carino, ma rimane un giocattolo.

… moi non plus!

Pensavo di poter vivere in un ambiente Windows-only, ma una settimana di utilizzo mi ha portato a crisi d’astinenza da terminale. Sì, PowerShell fa schifo.

Alla fine, ho ritornato il Surface, la nostra primavera non è diventata estate.

Cosa mi aspettavo da questa macchina? Le promesse mantenute, sono quelle che ho sopra elencato come punti di forza: per un creativo o un utilizzatore di applicazioni Windows-only il dispositivo può essere LA soluzione fanless di riferimento. Il core M3 si comporta bene dal punto di vista prestazionale per task da sysadmin, ovvero virtualizzazione leggera, web app, RDP e VPN, thick client per hypervisor ecc.

Aftermath

In realtà, la settimana è stata foriera di diverse riflessioni sul futuro dell’IT… probabilmente, oggi ci sono troppi vantaggi nell’avere Linux come sistema host. Questo, con i problemi dovuti allo strano form-factor, mi hanno convinto a ritornarlo.

Perché Linux (che è già il sistema di riferimento per server) in un portatile/ultrabook, oggi?
Perché il focus si sta spostando… anzi, si è già spostato. Preferisco avere la CLI di AWS integrata, piuttosto che il fat client di VMware. Perché Mac OS  X fa quasi tutto quello che si può fare con Linux, ma è parecchio indietro sul versante virtualizzazione/containers. Il mondo del cloud computing si muove su Linux, quale modo migliore per abbracciarlo che utilizzare quotidianamente i sistemi del pinguino anche sul laptop da battaglia?

E poi… LXD e Docker sono qualcosa di fantastico. La possibilità di poter partizionare una macchina come fosse un mainframe, senza l’overhead della virtualizzazione classica, è impagabile.
Il mio prossimo portatile sarà una macchina Linux, probabilmente un XPS 9360.

XenServer 7 software RAID with mail alert

Leggi questo articolo anche in italiano.

XenServer 7 is emerging as the reference implementation of the opensource hypervisor Xen, proving advanced features regarding storage, networking, HA and management; all packaged in a self-contained, enterprise-level bundle, often superior to VMware vSphere, HyperV and KVM, the other big players of the enterprise virtualization market.

It should also be noticed that Xen is the hypervisor of choice for the majority of public clouds (AWS and the others), is completely FLOSS  software and its XenServer declination is managed directly from the Linux Foundation (no CITRIX anymore), making it the de-facto standard solution for the bare metal opensource virtualization.

Powerful batteries included!

The software stack that surrounds the Xen kernel has made a giant leap thanks to the adoption of a modified CentOS 7 as the dom0 in XenServer 7.
The standard installation of XS already include every piece of software needed to completely skip an hardware RAID solution and adopt an enterprise-ready software RAID solution! As of today, MDADM is one of the few RAID solution that can manage NVMe RAID or other niche configurations; thanks to the modern CPU power, MDADM (especially with very big arrays) plays on the same ground of some ASICS-based controller.

Furthermore, software RAID enable the creation of array using non-branded disks, a strategic feature of XS7 in comparison to products like VMware, that at most permits the creation of a RAIN using paid add-ons like vSAN. If you have ever compared the price of branded HDD or SSD  (HP, IBM, Dell, ecc.) with the COTS ones, you know what I’m talking about.

Dive into MDADM

This is the to-do list you have to follow in order to build a software RAID that will warn you in the event of malfunction:

  • Creation on an MDADM array;
  • Configure SSMTP to send email warnings;
  • Test if email alerts are working;
  • Add the array as an SR to XS7.

MDADM is a very battle-tested piece of software; included in the Linux kernel since many years, has earned on the field its reputation of very stable and bug-free software; indeed it is used in big critical system (like the “big irons x86”) and in the majority of commercial NAS system (Synology, QNAP, Buffalo, ecc).

Because is already included in the standard installation on XS7, the creation of a RAID array is very simple, especially in the typical scenario in which you have installed the hypervisor in a USB drive that won’t be part of the array… as recommended by the best practices! I have spoke about that here (Warning, italian inside™! Let me know if you want to read it in english).

For instance, create a RAID 10 with the first four HDDs is as simple as

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

To monitor the disk syncing, just do

 watch cat /proc/mdstat 

or the evergreen

 mdadm --detail /dev/md0

that will also give you various information about the status of the array.

Would you trust a system that does not warn you in the event of failure?

We are going to set the array monitoring; just to begin, copy the active array configuration in the config file of MDADM with

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

This will enable the array monitoring by the MDADM daemon.
Now, configure the SSMTP to send email warnings… just as an example, this configuration of /etc/ssmtp/ssmtp.conf is usable to send notification from a gmail address:

 
root=your_mail@gmail.com
mailhub=smtp.gmail.com:587
Hostname=your_hostname.yourdomain.sth
UseTLS=YES
TLS_CA_File=/etc/pki/tls/certs/ca-bundle.crt
UseSTARTTLS=YES
AuthUser=your_mail@gmail.com
AuthPass=your_password
FromLineOverride=YES

It’s important to set /etc/ssmtp/revaliases like that:

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

Eventually, the MAILADDR and MAILFROM parameters from the last rows of /etc/mdadm.conf will need to be assigned to your sender and receiver addresses, so mdadm.conf will look like that:

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

Don’t leave your chair without some testing!

Now that the configuration is completed, you need to do some checks; MDADM can send a test email with

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

But, if you really want, you can put a disk in “failed” state (be aware of rebuilding times with big HDD) using

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

You have to wait a little for the fail detection, as far as ten minutes, because the daemon is correctly “lazy” at recognizing the fail, even if it is simulated.

Now that the array is tested and ready to be used, just add it to the XS7 SR:

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

In XS7, the array is recognized even after a reboot without manual module insertion or other configurations; everything is just ready to go!

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.

IPMI, questo sconosciuto; o anche, “Butta dalla finestra il tuo KVM”

Ho sempre amato le descrizioni “funzionali” dei devices.

Se dovessi descrivere un server, il primo requisito che mi verrebbe in mente sarebbe “è un computer completamente gestibile da remoto”; un requisito cardine, che dovrebbe entrare a far parte della stessa definizione di macchina server.

Come si gestisce da remoto una macchina fisica? Vedo già sbrilluccicare gli occhi del vostro vendor di switch KVM…

NO! I moduli KVM sono costosi, richiedono parecchia banda, non sono inclusi di serie (a parte rari casi) nelle vostre macchine server e comunque non fanno tutto quello che fa IPMI. È nato un grosso business attorno ad essi nel settore SMB a causa delle installazioni fisiche di Windows Server, ma… se nel 2016 pensate davvero di installare Windows Server non virtualizzato su un server per uso generalista (esistono casi edge dove la virtualizzazione è problematica), forse avete sbagliato blog.

Cos’è IPMI

Una descrizione generale di IPMI la trovate qui; la mia idea a riguardo, è che si tratti di una delle più misconosciute (sempre in ambito SMB) e utili funzionalità di gestione remota, molto più dei vari DRAC, iLO, IMM.

IPMI permette di controllare accensione/spegnimento della macchina, leggerne qualsiasi sensore, settare diverse impostazioni senza mai adoperare il BIOS (ad esempio, il device di boot), e ancora dialogare con il sistema operativo (o hypervisor di turno) tramite un’interfaccia dedicata out-of-band, seriale.

Come funzionalità OOB, IPMI non dipende dal software installato sulla macchina, né da eventuali agent.

Come si usa IPMI

Dovreste essere in grado di configurare completamente un server appena sballato senza mai collegarvi un monitor; sì, davvero.

Tutto quello di cui ha bisogno un server, oltre all’alimentazione, è una rete. Solitamente, le macchine provviste di IPMI hanno una porta ethernet dedicata al management; collegatela alla vostra rete, ed eseguendo

 ipmitool lan set 1 ipsrc dhcp 

IPMI verrà abilitato; basta rintracciare il lease per cominciare ad utilizzarlo.
Ad esempio, potremmo controllare se la nostra macchina è accesa con

 ipmitool -H ipmi_ip -U user -P password chassis power status 

e magari attivarla con

 ipmitool -H ipmi_ip -U user -P password chassis power on 

. Oppure, decidere di resettarla “elettricamente”:

 ipmitool -H ipmi_ip -U user -P password chassis power reset 

tutto senza mai toccare il tasto di accensione.
Controllare temperatura esterna e delle componenti, funzionamento delle ventole ed altri sensori hardware, è altrettanto semplice:

 ipmitool -H ipmi_ip -U user -P password sensor list 

e ora, una chicca: stufi di attendere il momento topico per premere F2, ESC &co per entrare nel bios dell’ultimo Proliant fiammante?

Ecco come impostare l’entrata automatica nel bios al successivo riavvio:

 ipmitool -H ipmi_ip -U user -P password chassis bootparam set bootflag force_bios 

Come avrete intuito, è possibile anche impostare qualsiasi dispositivo di boot tramite IPMI; il provisioning automatizzato tramite boot PXE impostato da IPMI è il metodo standard per la preparazione delle macchine utilizzate nelle server farm cloud.

SOL

Tutto molto bello, no? Ma eccoci arrivati alla funzionalità groundbreaking, “the real thing”; Serial-Over-Lan, o SOL per gli amici. In altri termini, redirezione della seriale via ethernet. Per la precisione, una porta seriale virtuale alla quale viene inviato l’output “video” del BIOS, dei vari controllers e del sistema operativo (se configurato opportunamente).

Adesso sapete come vengono fatti quei video in cui la fase di boot della macchina appare in un terminale: ve lo siete sempre chiesti, ammettetelo.

A titolo di esempio, ecco un video del boot di una mia macchina visto tramite SOL, una CentOS che fa da host per la virtualizzazione basato su KVM.

La SOL è uno strumento molto potente: possibile accedere al bios, quindi si può anche reinstallare da zero la macchina, e modificarne qualsiasi impostazione.

Non è tutto: come vedete alla fine del video, dopo il boot del sistema operativo si presenta anche il prompt di login… da questo, possiamo accedere alla macchina come faremmo in locale: costituisce a tutti gli effetti uno strumento di gestione out-of-band del sistema operativo, ovvero utilizzabile anche in caso la configurazione di rete del sistema sia per qualche motivo compromessa; ottimo per sperimentare con il networking, senza correre il rischio di essere tagliati fuori dalla gestione della macchina.

Tutti i principali OS/Hypervisor enterprise supportano pienamente la console seriale:

  • qualsiasi distribuzione di Linux può essere facilmente configurata per esporre una console seriale, basta seguire la documentazione della particolare distribuzione;
  • XenServer (il cui dom0 è Linux, naturalmente) include la voce “XenServer – Serial” nel menù di boot: rendetela default;
  • VMware ESXi può essere anch’esso facilmente configurato per la redirezione della console sulla porta seriale.

E AMT?

La Intel Active Management Technology è una tecnologia pensata per sistemi desktop e workstation, ma presente anche in diversi sistemi server. Alcune delle sue funzionalità si sovrappongono a quelle di IPMI e ne sono una evoluzione (sempre interessante vedere cosa riporta la wiki a riguardo), inoltre sono presenti grandi miglioramenti alla sicurezza, con un enforcing della cifratura TLS per le comunicazioni.
Avendo avuto modo di testare alcune sue caratteristiche, posso dire che la sintassi e le modalità di utilizzo delle funzionalità che mappano quelle classiche di IPMI via commandline (controllo status di alimentazione, ad esempio) sono abbastanza complesse rispetto alla controparte tradizionale.

Di contro, le funzioni per il provisioning automatico sono piuttosto avanzate, cosa che rende questa tecnologia parecchio idonea a deployment massivi nelle grandi enterprise.

AMT è pensato per essere utilizzato con software di management appositi, e il protocollo web-based sottostante è piuttosto complicato rispetto ad IPMI. Su piattaforma Linux vi consiglio amtterm, che fornisce una esperienza SOL-equivalente (notare che AMT include anche il KVM vero e proprio) con modalità molto user-friendly, mentre la tool wsmancli  consente di utilizzare appieno le funzionalità avanzate.

Alcuni produttori pensano di sostituire/affiancare AMT ad IPMI nel prossimo futuro; a mio avviso, come per l’interfaccia seriale (che adesso ha più di 40 anni!), lo zoccolo duro-legacy di IPMI rimarrà con noi ancora per diverso tempo…