Da UNIX* a SUSE® Linux Enterprise

White paper tecnico
OPEN PLATFORM SOLUTION
www.suse.com
Da UNIX a
SUSE Linux Enterprise
*
®
Guida per la valutazione
Da UNIX a SUSE Linux Enterprise
Indice:
2 . . . . . Da UNIX a SUSE Linux
Enterprise
2 . . . . . Scopo del documento
2 . . . . . Perché si migra da
UNIX a Linux
3. . . . . . La disponibilità, l’affidabilità
e la gestione in esercizio
di Linux su x86_64
13 . . . . . Casi reali di successo
14 . . . . . Termini ricorrenti,
abbreviazioni e definizioni
15 . . . . . Risposte a domande
frequenti
p. 1
Da UNIX* a SUSE Linux Enterprise
®
Scopo del documento
Questo documento ha due obiettivi principali:
introdurre perché sia economicamente e
strategicamente vantaggioso migrare servizi
ed applicazioni oggi in esecuzione su server
UNIX* ed hardware proprietario verso server
Linux* su architettura Intel*/AMD* x86_64;
dimostrare come la coppia (Linux; x86_64)
e relativi strumenti di clustering e gestione
consentano di supportare l’esecuzione e la
gestione operativa di servizi e applicazioni
al medesimo livello di UNIX in termini di
affidabilità e prestazioni.
Seppure Linux sia supportato anche su
server di classe intermedia (Power, Itanium)
e su macchine di classe mainframe (IBM*
System z*) queste tipologie di migrazioni
non sono prese in considerazione in questo
documento.
Nel documento sono descritti i razionali
­economici, argomentate le motivazioni
­strategiche, viene data risposta alle domande
più frequenti e sono infine riportati alcuni
casi di successo in Italia e nel mondo.
Il presente documento non ha scopi di
­marketing ma si vuole bensì posizionare quale
documento tecnico destinato ai ­responsabili
di scelte architetturali, ai responsabili IT,
ai responsabili di esercizio/operations e della
pianificazione IT, ai consulenti e a chiunque
desideri approfondire a scopo professionale
il tema in oggetto.
Perché si migra da UNIX a Linux
Nella stragrande maggioranza dei casi le
aziende decidono di migrare servizi ed applica­
zioni da UNIX a Linux per ragioni economiche.
Tale considerazione rimane però molto limitata
in termini di risparmio di costi se per il confronto
viene semplicemente preso in considerazione
il costo di una “subscription Linux” Vs quello
di una “licenza+manutenzione UNIX”.
Ferman­dosi a questo livello superficiale
infatti la risposta alla domanda “Linux costa
di per sé meno di UNIX” è: no.
p. 2
Per capire veramente quanto il passaggio
da UNIX a Linux possa essere conveniente
per le aziende è necessario fare un passo
ulteriore e considerare che:
E’ l’insieme “Linux su hardware di classe
x86_64” che costa sensibilmente meno
di quello (inscindibile) “UNIX su hardware
proprietario”, a parità di prestazioni,
disponibilità e affidabilità.
Vediamo in dettaglio come, quanto e perché.
L’investimento in hardware è
­sensibilmente inferiore
L’aspetto economicamente più rilevante
in termini assoluti è il costo di acquisizione
hardware a parità di prestazioni e affidabilità.
L’esperienza mostra che a parità di potenza
elaborativa, un’architettura basata su hard­
ware x86_64 rispetto all’equivalente basata
su processori RISC costa il 60-70% in meno.
Per una trattazione esaustiva si rimanda
al white paper di Realtech, disponibile al
­seguente link: http://tinyurl.com/yjjyanc
Cosa permette di arrivare ad un risparmio
così elevato? Sostanzialmente le macchine
basate su processori x86_64 continuano ad
evolvere in termini di prestazioni (non tanto
sull’incremento della velocità di clock che
porterebbe a eccessivi consumi di energia
elettrica, ma bensì grazie alle architetture
multi-core), senza però che i prezzi dei
server aumentino (anzi).
I prezzi dei server x86_64 inoltre tendono a
diminuire col tempo perché il mercato è reso
estremamente competitivo dalla presenza
di numerosi player), sia per le CPU (Intel,
AMD) e sia per i server completi (Dell*, HP*,
IBM, Fujitsu* ecc.). Ne consegue che, per
una medesima architettura hardware x86_64
e mantenendo il sistema operativo Linux
invariato, è possibile ottenere sconti ­maggiori
grazie alla possibilità di poter ottenere
un’offerta anche da 4 o 5 differenti fornitori
contemporaneamente.
Da UNIX a SUSE Linux Enterprise
Il costo della manutenzione hardware
è sensibilmente inferiore
Il costo della manutenzione hardware per
le macchine standard x86_64 è tipicamente
l’80-90% meno di quello dei server RISC.
Questo perché i server RISC sono prodotti
da pochi player e sia l’attività di assistenza
tecnica che i pezzi di ricambio/upgrade sono
forniti quasi esclusivamente dai produttori
hardware stessi. Ne consegue che è pratica­
mente impossibile riuscire ad ottenere sconti
vantaggiosi, poiché il fornitore lavora in una
situazione pressoché monopolistica.
Nel mondo dei server industry standard
x86_64 questa dipendenza dal produttore
è quasi nulla.
I costi del software sono inferiori
Per quanto riguarda i costi del software è
importante notare che non è tanto il costo del
sistema operativo ad essere inferiore quanto
bensì i costi delle licenze+manutenzioni dei
pacchetti applicativi, middleware, application
server o DB, che sono più bassi su hardware
x86_64 rispetto a quelli per macchine RISC.
Questo perché spesso i costi del software
sono considerati in base alla potenza di
calcolo esprimibile dalle macchine RISC
rispetto a quella effettivamente utilizzata.
Al fine di portare un esempio pratico è
possibile far riferimento al caso di un cliente
SUSE operante nel campo assicurativo
che ha spostato la sua farm di macchine di
front-end web di un’applicazione businesscritical (web server e application server
IBM WebSphere*) da AIX*/Power a SUSE®
Linux/x86_64 risparmiando notevolmente
anche i termini di licenze e manutenzioni
di IBM WebSphere.
Il legame indissolubile di ogni
UNIX col proprio hardware
Tutti i sistemi operativi UNIX attualmente
in uso sono legati in maniera indissolubile
all’hardware del medesimo produttore
(Oracle*/Sun* Solaris* e le macchine
SPARC*1, HP-UX* e le macchine Itanium 2,
IBM AIX ed i server System p basati su
processori Power). Questa scelta porta
con sé per il cliente vantaggi e svantaggi
e l’esperienza degli ultimi anni ha ormai
www.suse.com
dimostrato che i secondi hanno ormai
superato i primi.
__________
I vantaggi sono ovviamente riconducibili
all’ottimizzazione delle piattaforme, al
supporto totale e completo su tutto lo stack
e, in passato, la standardizzazione portata
da UNIX rispetto al mondo centralizzato e
chiuso dei mainframe.
Caratteristiche consolidate inoltre delle
piattaforme RISC sono una notevole
affidabilità (grazie anche a soluzioni di
ridondanza e controllo a livello hardware)
e la scalabilità verticale pressoché lineare
per molti workload (uno su tutti i database
relazionali). I processori RISC inoltre, fino a
una decina di anni fa, avevano prestazioni
inavvicinabili per quelli x86.
Ma, sebbene vantaggi delle piattaforme
UNIX siano ormai quasi tutti annullati nel
momento i cui si fa il confronto con il mondo
Linux/x86_64, gli svantaggi rimangono.
Un parallelo esemplificativo può essere
ritrovato in quanto accadde in passato per
il passaggio dal mondo centralizzato dei
mainframe a quello “open” degli UNIX, gli
UNIX oggi hanno lo svantaggio di portare ai
clienti un legame indissolubile col fornitore
su tutto lo stack.
Concludendo, non si tratta di un problema di
qualità, prestazioni e affidabilità, ma bensì di
una questione di lock-in non più giustificato
da una superiorità tecnologica.
La disponibilità, l’affidabilità
e la gestione in esercizio
di Linux su x86_64
Quando si parla di sistemi UNIX ci si riferisce
nella maggioranza dei casi a scenari di sistemi
per applicazioni critiche o, quantomeno,
molto rilevanti, la cui effettiva disponibilità è
fattore chiave di successo. L’affidabilità dei
sistemi UNIX (intesa come la capacità di
rispettare le specifiche di funzionamento
nel tempo) è notoriamente molto alta, ma i
guasti sono inevitabili e quindi, all’atto pratico,
è importante realizzare sistemi che nel loro
complesso (hardware, sistema operativo,
applicazioni, networking, storage ecc.) siano
tolleranti ai guasti più comuni (rispetto ai
costi che si possono/vogliono sostenere).
p. 3
1 Per completezza segnaliamo
anche l’esistenza di ­macchine
Solaris su server SPARC
prodotti da Fujitsu
2 In precedenza macchine
PA-RISC
__________
3 Riferimento a Reliability, Availability, Serviceability (RAS)
4 CPUset è disponibile per
SUSE Linux Enterprise Server.
Per elaborazioni in tempo
reale, esiste poi un prodotto
SUSE Linux ad hoc chiamato
SUSE Linux Enterprise Real
Time (SLERT), basato su un
kernel real-time che consente
di avere tempi di latenza
dell’ordine di microsecondi
anziché di millisecondi
(kernel non real-time)
Nel mondo Linux, nato per funzionare su
qualsiasi hardware, anche di costo estrema­
mente ridotto, l’affidabilità dei sistemi e
la conseguente progettazione per l’alta
disponibilità sono state sviluppate nel tempo
principalmente come componenti software.
Dove in passato l’alta disponibilità di
un sistema UNIX era garantita anche
da hardware ridondato e meccanismi di
controllo a livello hardware, nei sistemi Linux
tutto questo è stato realizzato da tempo a
livello software.
Vediamo alcuni esempi di cosa venga
fornito da SUSE Linux Enterprise Server per
poter realizzare sistemi affidabili, con alta
disponibilità e che siano semplici da gestire
in esercizio3.
Alcune funzionalità RAS incluse in
SUSE Linux Enterprise Server
Swap over NFS: possibilità di utilizzare come
partizione di swap anche un disco remoto
acceduto via NFS. Questa funzionalità è
molto utile in alcuni scenari quali:
server senza dischi locali (es.: blade o
server in cluster dove avere dischi locali
può comportare costi indiretti/imprevisti
per manutenzione hardware o eccessiva
richiesta di energia elettrica per raffreddare
i server);
p. 4
in ambito virtualizzazione per semplificare
operazioni di migrazione;
in generale come forma di protezione per
minimizzare i riavvii applicativi.
Multipath I/O
il multipath I/O consente di tollerare meglio
alcuni malfunzionamenti nel percorso
fisico fra la CPU di un sistema ed i relativi
dispositivi di storage di massa (attaverso
bus, switch, bridge). Si utilizza tipicamente
nelle combinazioni Host _ HBA _ SAN
in fibra _ Storage esterno. SUSE Linux
permette di configurare questi dispositivi
mediante un modulo di YaST® in maniera
grafica
sono disponibili inoltre prodotti di terze
parti quali EMC2 PowerPath, Hitachi Data
Systems HDLM, Symantec Veritas Storage
Foundation, ecc.
Control group e CPUset
Control group: gestione “a grana fina”
delle risorse (CPU, memoria, storage,
rete). Permette di assegnare specifiche
risorse hardware ad applicazioni, processi
e thread, consentendo di potere riservare
le risorse pregiate ai processi/thread critici
per garantirne prestazioni e affidabilità
anche in situazioni di scarsità
CPUset: consente di riservare un
processore/thread per task ad alta priorità
e migliorare quindi le prestazioni in ambito
computazione in tempo reale4
Da UNIX a SUSE Linux Enterprise
www.suse.com
SUSE Linux Enterprise High Availability Extension
Si tratta di un’estensione di SUSE Linux Enterprise Server che consente di realizzare cluster
per alta disponibilità.
Figura 1. Interfaccia grafica del cluster resource manager
SUSE Linux Enterprise High Availability
Extension include varie componenti, tutte
open source e integrate fra loro, quali ad
esempio:
Pacemaker / OpenAIS: cluster manager
e monitor che permette di clusterizzare
qualsiasi applicazione o servizio. Di base
è fornito con circa 40 resource agent per
tutti i servizi di rete, per le applicazioni e
DB Open Source più comuni (es.: Apache*
httpd, Tomcat*, MySQL*, PostgreSQL ecc.)
ed è certificato per alcune applicazioni
proprietarie quali SAP* e Oracle RDBMS.
Pacemaker / OpenAIS non ha limitazioni
nel numero di nodi in un cluster HA ed
è estendibile per potere clusterizzare
qualsiasi applicazione;
p. 5
__________
5 Alcuni riferimenti del mondo
UNIX classico: OCFS2 è stato
sviluppato da Oracle partendo
dal codice del file system dei
cluster Digital di cui acquisì i
sorgenti. Fa parte del kernel
mainline di Linux dalla versione
2.6.19 (anno 2005 circa).
6 Contestualizzando al mondo
UNIX, il concetto di Distributed
Lock Manager è del tutto
simile a quello presente in
OpenVMS* (uno dei primi
UNIX a supportare cluster
simmetrici e paralleli)
Figura 2. SLE HAE: architettura interna
cLVM e LVM2: gestore dei volumi logici
che supporta configurazioni in cluster,
standard de facto del mondo Open Source.
Alcune delle funzionalità più rilevanti di
LVM sono:
– ridimensionamento online dei volume
group (assorbendo/espellendo volumi
fisici)
– creazione di snapshot (sia a sola lettura
che anche scrivibili) dei volumi logici
– queste funzionalità sono particolarmente
utili quando è necessario effettuare
operazioni di backup senza interrompere
i servizi ad esempio
– RAID 0 e RAID 1 dei volumi logici sui
volumi fisici
– divisione o fusione di volumi logici in situ
OCFS2 (Oracle Cluster File System 2)5:
file system journaled per cluster ad accesso
parallelo e simmetrico ad alte prestazioni e
per alta disponibilità:
– può essere utilizzato per qualsiasi
applicazione
– le applicazioni cluster-aware possono
beneficiare dell’accesso parallelo in
lettura/scrittura per aumentare le
prestazioni
p. 6
– scenari esemplificativi: Oracle RAC,
scale-out di web server e file server
– le applicazioni “normali” possono
beneficiare del fatto che il volume
condiviso è “mounted” da tutti i nodi per
ridurre notevolmente il tempo di fail-over
(il nodo che fa il take-over non deve
effetturare il “mount” del volume)
– scenari esemplificativi: image store per
macchine virtuali, fail-over di mail server
– supporta il controllo degli accessi
­secondo la semantica POSIX e le
quote disco
– usa un gestore dei lock distribuito6
per cui non ha single point of failure per
quello che riguarda il coordinamento
del cluster
– la dimensione dei blocchi può essere
variabile
– supporta molteplici modelli di alloca­
zione dello spazio disco (extent, sparse)
– il journaling può essere effettuato in
2 modalità (ordinato .vs. writeback)
– supporta diverse modalità di I/O
(bufferizzato, diretto, asincrono ecc.)
– supporta gli strumenti standard di
manipolazione dei file system Linux quali
mkfs, fsck ecc.
Da UNIX a SUSE Linux Enterprise
– SUSE Linux Enterprise Server è stato il
primo Linux commerciale a supportare
ufficialmente OCFS2 (SUSE Linux
Enterprise Server 10, 2006) ed è possibile
delegare il coordinamento di OCFS2 a
Pacemaker per unificare la gestione in
cluster del file system e delle applicazioni/
servizi.
DRBD (Distributed Replicated Block
Device): è un sistema di replica dello
storage a livello di blocchi fisici che funziona
su una normale rete locale (LAN), simile
al concetto del RAID 1 ma su rete, viene
utilizzato nei cluster di alta disponibilità
quando non si dispone di uno storage
condiviso o come alternativa allo storage
condiviso per non avere single point of
failure:
– tutte le operazioni lettura sono locali,
le operazioni di scrittura e replica
possono essere sincrone o asincrone
– la modalità di replica sincrona è utilizzata
per applicazioni stateful in cui è assoluta­
mente indispensabile non perdere
neanche una transazione nel caso
di guasto al nodo primario
www.suse.com
– la modalità asincrona è utilizzata invece
negli scenari di replica a lunga distanza
(es.: disaster recovery) o quando la
durata del round trip di rete è maggiore
della latenza in scrittura accettabile per
l’applicazione
– quando un nodo ritorna disponibile dopo
un guasto, DRBD effettua automatica­
mente la sincronizzazione con gli ultimi
dati, così come quando la rete di replica
ritorna disponibile dopo un disservizio
temporaneo
– DRBD è anche in grado di mascherare
un guasto a un disco sul nodo attivo
– lavorando a livello di blocchi fisici,
DRBD è agnostico rispetto al file system
e volume manager soprastante e rispetto
all’applicazione/servizio
– in SUSE Linux Enterprise High Availability
Extension è possibile sfruttare l’integra­
zione fra Pacemaker e DRBD per
realizzare cluster per alta disponibilità
anche senza storage condiviso
utilizzando server industry standard
– fra le distribuzioni Linux commerciali
solo SUSE Linux Enterprise Server
include e supporta DRBD
Figura 3. Cluster resource manager: migrazione manuale a scopo manutenzione
p. 7
System Management
La gestione del ciclo di vita di un sistema
SUSE Linux Enterprise viene di seguito
­affrontata nei seguenti aspetti:
installazione iniziale di un sistema e di una
“batteria” di sistemi SUSE Linux
amministrazione ordinaria di un sistema
SUSE Linux
gestione degli aggiornamenti di più sistemi
SUSE Linux
Applies the appropriate business rules
soluzioni certificate di terze parti
Installazione iniziale di un sistema e di una
“batteria” di sistemi SUSE Linux “identici”
Il programma di installazione, configurazione
ed amministrazione di SUSE Linux è YaST.
YaST è un programma dotato di interfaccia
utente grafica e invocabile a linea di
comando. Tutte le operazioni di installazione,
configura­zione e amministrazione possono
essere effettuate mediante moduli di
YaST. La semplicità d’uso e la coerenza
dell’interfaccia utente di YaST rendono
possibile l’amministra­zione di un sistema
SUSE anche ad amministratori che non
conoscano tutti i segreti di Linux e rende
rapide le operazioni anche per gli
amministratori esperti. La collezione di
moduli di YaST è ampia ed è integrato
un motore di ricerca che permette di
trovare rapidamente il modulo da usare
conoscendone lo scopo anche se non se
ne conosce il nome.
Figura 4. YaST Control Center
E’ proprio una procedura guidata di YaST che permette di effettuare l’installazione di un
sistema SUSE Linux. Al termine della fase di raccolta dei parametri per l’installazione viene
proposto di “clonare questo sistema con AutoYaST”, e qualora si risponda positivamente,
YaST genera un file XML in cui sono raccolte tutte le informazioni inserite dall’amministratore
in fase di installazione. Nel caso in cui si debbano installare n macchine identiche è quindi
possibile utilizzare il file generato di cui sopra come unico parametro di ingresso, e l’installa­
zione procede in maniera automatica garantendo l’uguaglianza dei sistemi. Questa funzionalità,
unita alla possibilità di usare un “server di installazione di rete”, è estremamente comoda
quando si devono installare n macchine identiche. Permette inoltre di completare le operazioni
in maniera rapida e precisa (intervento umano ridotto al minimo indispensabile).
p. 8
Da UNIX a SUSE Linux Enterprise
Importante notare inoltre come sia possibile
aggiungere alla lista dei pattern/pacchetti
da installare anche pacchetti di terze parti
mediante la funzione di “Add-on CD”:
questa funzionalità è utile in quei casi in
cui sia necessario aggiungere ai sistemi
pacchetti software standard per l’azienda
quali ad esempio agenti di soluzioni di
­system management, di backup ecc.
di terze parti.
AutoYaST consente inoltre di richiedere
l’inserimento manuale di parametri di
installazione da parte dell’amministratore.
Ad esempio è possibile automatizzare
tutta l’installazione, tranne l’inserimento
dell’indirizzo IP del server: l’installazione
automatica parte, si ferma al momento
dell’inserimento dell’indirizzo IP e - una
volta inserito il valore - l’installazione si
completa automaticamente (scenario
molto comune).
Amministrazione ordinaria di un
sistema SUSE Linux
Sempre con YaST è possibile effettuare
l’amministrazione ordinaria di un sistema
SUSE Linux. I moduli di YaST sono suddivisi
nei seguenti gruppi:
Hardware
Miscellaneous
Network devices
Network services
AppArmor® (si rimanda alla sezione
­dedicata alla sicurezza)
Security and users
Software
System
Virtualization
Other
www.suse.com
Non è obiettivo di questo documento
descrivere nel dettaglio tutte le funzionalità
di YaST, per chi fosse interessato si rimanda
alla documentazione di prodotto.
L’interfaccia grafica di YaST è disponibile
sia in ambiente grafico Gnome*/KDE e sia
a terminale come applicazione ncurses,
in modo da essere fruibile anche sui server
che sono in esecuzione a runlevel=3 e nei
quali spesso non viene installato l’ambiente
grafico.
Infine è importante sottolineare come l’uso di
YaST non inibisca la possibilità di cambiare
le configurazioni del sistema modificando
direttamente i file appositi o utilizzando le
numerose utility tipiche di un sistema Linux.
Ad esempio la gestione completa del software
di un sistema (installazione, aggiornamento,
rimozione, gestione dei repository in vari
formati, risoluzione delle dipendenze, inter­
ro­gazioni ecc.) può essere effettuata senza
YaST, a linea di comando con zypper.
Gestione degli aggiornamenti di più
sistemi SUSE Linux
In questo paragrafo presentiamo il SUSE
Subscription Management Tool (SMT), ovvero
il sistema che consente di centralizzare il
download degli aggiornamenti e dei patch
da SUSE verso il cliente in maniera semplice,
efficiente e sicura.
SMT è sostanzialmente un proxy di aggiorna­
mento, si installa su un server SLES® 11 in
DMZ 7 e permette di scaricare aggiornamenti/
patch in un unico punto senza fare acce­
dere i server interni a Internet, con evidenti
­vantaggi in termini di sicurezza, risparmio
di banda e semplicità.
p. 9
__________
7 De-Militarized Zone – rete del
cliente con i server che sono
esposti su Internet e/o che
devono accedere a servizi
Internet
Figura 5. Subscription Management Tool 2
I server interni vengono poi configurati per usare SMT come sorgente di aggiornamento.
Figura 6. Subscription Management Tool 3
SMT permette di gestire i canali di aggiorna­
mento per tutte le versioni di SLES corrente­
mente supportate e sincronizza lo stato
delle macchine con SUSE Customer Center,
p. 10
ovvero il portale a servizio dei clienti che
permette di avere un unico punto di riferimento
per verificare le scadenze delle subscription,
ottenere supporto tecnico, ecc.
Da UNIX a SUSE Linux Enterprise
www.suse.com
__________
8 SUSE Linux Enteprise Server
with Expanded Support:
www.suse.com/products/
expandedsupport/
Figura 7. Subscription Management Tool 4
SUSE SMT è un pacchetto gratuito a
disposi­zione dei clienti con subscription
attive.
macchine Linux che supporta sia SUSE che
Red Hat.
Tale soluzione si chiama SUSE Manager.
Si osservi inoltre che SUSE SMT è in grado
di gestire gli aggiornamenti anche per server
Red Hat* Enterprise Linux, per quei clienti
SUSE che abbiano acquisito subscription
di tipo “expanded support 8”.
SUSE Manager permette di effettuare il
­deployment, l’amministrazione remota e
la manutenzione delle macchine Linux
­avvalendosi di funzionalità di automazione
basate su policy.
Gestione del ciclo di vita completo di più
sistemi SUSE Linux e Red Hat
La contemporanea presenza delle due
­distribuzioni Linux commerciali più diffuse
è abbastanza frequente presso i clienti di
­dimensione medio-grande e questo avviene
al fine di non legarsi in maniera indissolubile
ad un unico fornitore (la stessa cosa avveniva
presso i grandi clienti per i sistemi UNIX).
In particolare, grazie a queste policy,
è possibile automatizzare operazioni
di inventario, aggiornamento, imaging,
“blindatura” anche su un grande numero
di macchine. Così come automatizzare la
distribuzione degli aggiornamenti/patch in
maniera selettiva e in modo da non saturare
la banda disponibile sulla rete.
E’ per questo motivo che SUSE, oltre agli
strumenti nativi SUSE, offre una soluzione
di gestione completa del ciclo di vita delle
SUSE Linux Enteprise Server with Expanded
Support: www.suse.com/products/
expandedsupport/
p. 11
__________
9 CIM è l’abbreviazione di
Common Information Model –
uno standard sviluppato dal
Distributed Management Task
Force (DMTF) per descrivere
le informazioni relative alle
applicazioni ed ai dispositivi
presenti su una rete etero­
genea con piattaforme /
sistemi operativi multipli.
Può essere pensato come la
“lingua franca” del systems
management.
10 Debugger standard Linux
per applicazioni
Figura 8. SUSE Manager - schermata esemplificativa
Soluzioni certificate di terze parti
Oltre che dalle soluzioni integrate di system
management SUSE Linux è “gestibile” anche
dalle piattaforme più diffuse sul mercato.
In primo luogo SUSE Linux Enterprise
è un “CIM provider 9”, può essere quindi
­amministrato remotamente da numerose
soluzioni che supportano questo standard.
In secondo luogo SUSE Linux Enterprise è
supportato dalle soluzioni di terze parti di
produttori quali:
BMC
HP
CA NSM
Microsoft System Center Operations
Manager (SCOM)
mediante SUSE Linux Enterprise
Management Pack for SCOM è possibile
amministratore i server SUSE Linux dalla
piattaforma Microsoft, con alcune funzionalità
aggiuntive in ambito monitoraggio e
­gestione di servizi non disponibili per
altri sistemi Linux/UNIX
IBM Tivoli
p. 12
Analisi dei malfunzionamenti
I malfunzionamenti ed i problemi di presta­
zioni accadono e non si possono evitare:
occorre però essere rapidi e precisi nel
risolverli, possibilmente osservando un
sistema in produzione senza doverlo
spegnere/disattivare/riavviare. Il mondo UNIX
è noto per le notevoli capacità di diagnostica
fornite in ogni dialetto UNIX (es. per il traccia­
mento delle chiamate di sistema: syscalls
di AIX, truss di Solaris, tusc di HP-UX). Nel
corso degli anni Linux ha sviluppato anche
questo aspetto di UNIX-ness per potere
essere ovviamente adeguato ad ambienti
critici. Si riportano nel seguito le descrizioni
di alcuni strumenti presenti in SUSE Linux
Enterprise Server.
Crash
Crash a un pacchetto presente in tutte le
distribuzioni Linux commerciali ed è una
collezione di strumenti che consentono di
effettuare debugging e analisi sia su sistemi
in esecuzione che analizzando core dump
creati con LKCD. É integrato con gdb10.
Da UNIX a SUSE Linux Enterprise
www.suse.com
Consente anche di analizzare dump effettuati
con netdump, diskdump, mcore. Sostanzial­
mente è lo standard Linux per l’analisi dei
kernel core dump.
Un filmato dimostrativo del funzionamento
di NSA è disponibile al seguente link:
www.youtube.com/watch?gl=IT&v=
cQmqYeH_75U
Sysstat
Pacchetto che include:
Casi reali di successo
iostat: generatore di statistiche sull’utilizzo
di CPU, I/O (dischi, rete). Viene usato
tipicamente per analizzare i colli di
bottiglia o le prestazioni di un sistema
in condizioni di stress o quando le
prestazioni decadono
mpstat: monitoraggio prestazioni CPU
pidstat: monitoraggio singoli processi
sar, sadf: per creare report dai valori
raccolti dagli strumenti suddetti.
SystemTap
Infrastruttura per la raccolta di informazioni
da un kernel Linux in esecuzione. Semplifica
il lavoro di diagnosi di problemi prestazionali
o malfunzionamenti perché non richiede
ricompilazioni del kernel e nemmeno riavvi.
Paragonabile a DTrace di Solaris o trace
di AIX.
Novell® Support Advisor (NSA)
Si tratta di uno strumento gratuito che
può essere utilizzato per analizzare lo stato
di salute di uno o più sistemi SUSE Linux
Enterprise, senza installare agenti sui
sistemi stessi.
NSA si installa come client su un computer
che possa connettersi ai server da analizzare
e al sito SUSE. L’amministratore seleziona
i server da analizzare ed NSA si occupa di
­effettuare le analisi e raccogliere gli esiti.
Gli esiti vengono confrontati con determinati
schemi di analisi SUSE e, in base ai
risultati, NSA fornisce raccomandazioni
per evitare problemi potenziali o sistemare
quelli in corso.
In caso di malfunzionamenti gravi NSA
può essere inoltre usato direttamente per
aprire incident al supporto tecnico SUSE
corredan­doli con le informazioni raccolte
e quindi velocizzando il processo di
troubleshooting.
In questo capitolo riportiamo a scopo
esemplificativo alcuni casi reali, sia italiani
che esteri, di migrazioni di sistemi critici da
UNIX verso Linux su x86_64. Sono riportate
alcune referenze italiane ed alcune estere
particolarmente interessanti.
Gruppo assicurativo Arca
Il cliente
Il Gruppo assicurativo Arca opera nell’ambito
delle polizze vita, RC auto, casa e generiche
attraverso una rete di 1.500 filiali di banche
partner e 150 agenzie dirette su tutto il
territorio italiano. Con sede centrale a
Verona, la società raccoglie approssimativa­
mente 650 milioni di Euro di premi all’anno.
Il problema
Tutti i sistemi di Arca sono centralizzati e
l’accesso alle applicazioni di business da
parte dalle agenzie e dalle filiali delle banche
partner avviene via browser web. L’accesso
a queste applicazioni extranet avviene
medi­ante reti private virtuali (VPN). I sistemi
su cui girano queste applicazioni sono sistemi
IBM AIX su hardware proprietario IBM su
server dal costo superiore ai 50.000 Euro
ciascuno. Arca aveva la necessità di trovare
una soluzione meno costosa, senza perdere in
funzionalità di sicurezza ed svincolandosi dalla
dipendenza da una tecnologia proprietaria.
La soluzione
Le applicazioni Arca sono basate sul IBM
WebSphere Application Server e sono state
facilmente migrate da AIX a SUSE Linux
Enterprise Server su server industry-standard
x86_64.
Per aumentare la sicurezza dei sistemi
inoltre, è stato creato un modello base di
SUSE Linux Enterprise Server dal quale sono
stati rimossi tutti i componenti inutili nello
specifico e sono state impostate policy
di anti-intrusione applicativa con AppArmor.
In questo modo è stato creato un modello
di installazione fortemente blindato e messo
in sicurezza.
p. 13
__________
11 Il confronto è basato su un
sistema Linux su hardware
x86_64 nuovo, con un
sistema Unix su hardware
non nuovo. Ma il paragone
non deve sembrare scorretto,
anzi: è proprio l’evoluzione
tecnologica dei server
industry-standard con Linux
che fa risultare i sistemi Unix
che hanno anche solo 3-4
anni di vita costosi e poco
prestazionali
12 Il costo di questo middleware
è tarato sulla potenza di
calcolo esprimibile dal
sistema, indipendentemente
dall’utilizzo effettivo. Ne deriva,
che lo stesso software,
su piattaforma x86_64 costa
molto meno rispetto alla
piattaforma Power.
L’installazione di questo modello di SUSE
Linux Enterprise Server “blindato” è stato
poi automatizzato con SUSE AutoYaST.
I risultati
La migrazione a SUSE Linux Enterprise
Server ha consentito ad Arca di ridurre
­significativamente gli investimenti ed i
costi operativi, incrementando al contempo
le prestazioni ed aumentando il livello
­complessivo di sicurezza grazie alla facilità
di configurazione. Alcune metriche basate
su osservazioni del cliente:
costi di acquisizione hardware: 60% in
meno
prestazioni del nuovo sistema: 4x il
­precedente11
costi delle licenze di IBM WebSphere
­­Application Server: 30% in meno12
La facilità di messa in sicurezza di SUSE
Linux Enteprrise Server consente ad Arca
di avere sistemi più sicuri.
Infine, la possibilità di fare scalare orizzontal­
mente il front-end applicativo su macchine
poco costose o anche su macchine virtuali,
consente ad Arca di potere gestire la crescita
del carico di lavoro senza essere legati
all’innovazione hardware.
Ansaldo STS
Il cliente
Ansaldo STS progetta, installa e gestisce
sistemi e componenti di segnalazione e
automazione ferroviaria. Le sue soluzioni
sono usate per più di 5.000 km sulla rete
ferroviaria italiana. L’azienda ha clienti anche
negli Stati Uniti, in Gran Bretagna, in Svezia e
in altre nazioni.
Il problema
Quando Ansaldo STS iniziò a cercare un
nuovo sistema operativo per supportare la
sua soluzione di automazione ferroviaria, il
requisito fondamentale era l’alta disponibilità.
L’automazione ferroviaria è basata sulla
capacità di instradare i treni operando sugli
scambi in maniera sicura in tempi ristretti.
Come tutti sappiamo ogni interruzione dei
sistemi informatici che regolano il traffico
ferroviario e le previsioni sui tempi di arrivo
comporta gravi ritardi e notevoli disservizi
ai passeggeri.
p. 14
Il livello di servizio da garantire per questo
tipo di soluzioni è tale da dovere garantire
di avere meno di 5 minuti / anno di fermo.
La soluzione era basata su HP-UX su hard­
ware proprietario HP e la disponibilità era
adeguata, ma i costi erano alti.
La soluzione
L’evoluzione dei server industry standard
x86_64, accoppiata all’evoluzione dei sistemi
di clustering software disponibili per Linux
ha fatto sì che Ansaldo STS abbia potuto
migrare la propria soluzione sulla piattaforma
SUSE Linux Enterprise Server su hardware
x86_64 Intel/AMD. Come soluzione di alta
disponibilità è usato SUSE Linux Enterprise
High Availability Extension. I database usati
sono Oracle e MySQL. La funzionalità di
replica a caldo di DRBD consente inoltre di
non perdere dati e ripartire rapidamente in
caso di guasto.
I risultati
Ansaldo STS ha migrato tutte le proprie
soluzioni di automazione ferroviaria su
SUSE Linux Enterprise Server su hardware
standard x86_64. Spezzando il legame di
dipendenza dal produttore hardware il cliente
può acquistare sempre al meglio garantendo
comunque i precedenti livelli di servizio.
Termini ricorrenti, abbreviazioni
e definizioni
UNIX
In questo documento ci si riferisce indistinta­
mente alle coppie (Sistema Operativo,
Hardware proprietario con processore RISC):
Solaris, server SPARC
IBM AIX, server Power
HP HP-UX, server Itanium (o anche più
­vecchi)
Subscription Linux
Linux è un sistema operativo Open Source
e quando viene commercializzato l’oggetto
dell’acquisto/vendita non è una licenza d’uso
(come nei software commerciali classici),
bensì una sottoscrizione a un servizio di
supporto tecnico. Ad esempio SUSE
commercializza sottoscrizioni a SUSE Linux
Enterprise Server di durata annuale o triennale
con 3 possibili livelli di supporto tecnico:
Da UNIX a SUSE Linux Enterprise
basic: patch e aggiornamenti – no
assistenza tecnica
standard: patch e aggiornamenti +
supporto tecnico 12x5 con 4h di presa in
carico di un problema
priority: patch e aggiornamenti + supporto
tecnico 24x7 con 1h di presa in carico
per i problemi gravi
Volendo fare un paragone puramente
monetario col modello del software commer­
ciale classico, è come se la licenza fosse
gratuita e si pagasse esclusivamente la
manutenzione/supporto annuale.
Risposte a domande frequenti
1. Il kernel di SUSE e quello di Red Hat non
sono uguali? E non sono lo stesso kernel
“vanilla” che si trova su kernel.org?
www.suse.com
puntuale o di un fix rilasciato per un singolo
problema critico per un singolo cliente.
Il modo per mitigare questo rischio è
controllare il processo e renderlo reversibile.
Nel caso di applicazione di una patch/­
aggiornamento di un pacchetto (anche del
kernel) che produca effetti collaterali dannosi
peggiori del problema risolto, è sempre
possibile riportare il pacchetto (o insieme
di pacchetti) alla versione precedente e
ripristinare la situazione precedente.
Come ulteriore forma di protezione da
aggiornamenti rischiosi è possibile inoltre
contrassegnare pacchetti come “taboo”
e renderne impossibile l’aggiornamento
automatico.13
No. I kernel delle distribuzioni commerciali
includono patch di sicurezza che il kernel
“vanilla” non ha. I kernel commerciali inoltre
includono backport di funzionalità che nel
kernel vanilla sono implementate in release
successive: questo implica che sia inutile e
scorretto confrontare le release dei kernel
commerciali con quelle vanilla per sapere
quali funzionalità sono implementate.
Discorso diverso sono i Service Pack o
Support Pack (SP). Un SP è un insieme di
patch (micro o macro) che sono sottoposte
a un processo di assicurazione qualità (QA)
non solo singolarmente, ma nel complesso­
tutte assieme. Tale processo ha una durata
di numerose settimane ed ha lo scopo di
garantire che non vi siano effetti collaterali
dannosi. Semplificando: l’applicazione di
un SP è un processo “sicuro”.
SUSE e Red Hat hanno poi cicli di rilascio
indipendenti e quindi ad ogni nuova release,
introducono nuove funzionalità. Nel corso
del ciclo di vita di una release poi vengono
rilasciati aggiornamenti anche del kernel,
soprattutto per 2 motivi:
3. È vero che ci sono ancora problemi nel
passaggio da una release all’altra del
sistema operativo, e che il passaggio di
release richiede una ri-certificazione delle
applicazioni in quanto non è garantita la
retro-compatibilità?
2. È vero che il processo di patching è
ancora critico in quanto spesso foriero di
problemi, e come è gestito tale processo
in SUSE (10 e 11)?
Parlando di SUSE Linux Enterprise Server
(SLES) i problemi di passaggio da una release
alla successiva risalgono al passaggio da
SLES 8 a SLES 9 (anno 2004). SLES 8 è
stata l’ultima release basata sul kernel 2.4
mentre SLES 9 la prima basata su kernel 2.6.
Tale cambio di kernel ha apportato notevoli
modifiche a basso livello e a livello di organiz­
zazione del file system, tali da rendere
l’aggiornamento possibile, ma non banale.
Se per patching si intende l’aggiornamento
di singoli pacchetti a fronte di problemi noti
e puntuali che affliggono un sistema, allora
è necessario effettuare un chiarimento: non
esistono sistemi operativi esenti da rischi
a fronte dell’applicazione di una patch
Tuttavia, è bene qui ricordare brevemente
come funziona il ciclo di vita di una release
di SLES. Ogni release ha un ciclo di vita
di 7 anni da quando viene rilasciata (es.:
SLES 11 è stato rilasciato a Marzo 2009 e
sarà quindi supportato ufficialmente fino a
supporto al nuovo hardware – questo
avviene con i service pack, all’incirca uno
all’anno
patch di sicurezza – secondo necessità
fix di bug: secondo necessità
p. 15
__________
13 Un esempio: driver di scheda
grafica super avanzata e
­particolare che devono
­essere compilati su un
dato kernel per funzionare
corretta­mente. Si marca il
kernel come taboo, perché
se il kernel venisse aggiornato
con leggerezza, la scheda
grafica non funzionerebbe
più. Questi casi sono tuttavia
sempre più rari e confinati al
mondo client e non server.
__________
14 # CPU come visto dal kernel,
su una macchina fisica
­moderna corrispondono
ai CPU-core
15 Il limite teorico è 64 TiB,
quello certificato corrisponde
a server reali disponibili
sul mercato
Marzo 2016). Per i primi 4 anni di vita viene
rilasciato all’incirca un SP ogni 12-18 mesi.
E ogni 3 anni circa viene rilasciata una nuova
release (es.: SLES 9 nel 2004, SLES 10 nel
2006, SLES 11 nel 2009). Ne consegue che
in ogni momento esistono sempre almeno 2
release di SLES correntemente supportate,
spesso 3.
Oggi (Ottobre 2011), sono supportate le
seguenti release/SP attuale/end-of-life della
release:
SLES 10 SP4 – fino al Luglio 2013
SLES 11 SP1 – fino al Marzo 2016.
Nella gestione operativa degli ambienti Linux
in ambito datacenter quello che si riscontra
abitualmente è che un server installato con
una determinata release viene aggiornato
quando escono i SP (o per fix di sicurezza
o patch necessarie a risolvere determinati
problemi) per tutta la durata della sua vita,
ma molto raramente si vedono cambi-direlease in-place se non in casi molto
particolari. Questo perché i SP, come
già osservato, includono anche parecchi
back-port a scopo hardware enablement
(per intendersi, fra il set di hardware
supportato da SLES 10 SP3 e quello di
SLES 11 non c’è una differenza abissale).
Relativamente alla certificazione di applica­
zioni di terze parti SUSE, come produttore
del sistema operativo garantisce che le
API esposte dal kernel non cambino a
fronte di un nuovo SP. Questo implica che
un’applicazione certificata non sia da
ri-certificare a fronte di un SP nuovo.
Per completezza è poi importante osservare
che la questione tipicamente va posta
soprattutto al produttore dell’applicazione.
Ribadiamo in ogni caso,che un SP di
SUSE Linux Enterprise non cambia le API
esposte dal kernel.
p. 16
4. Ma Linux scala bene verticalmente su
tante CPU?
Ovviamente la risposta a questa domanda
richiede considerazioni non banali relative
al tipo di applicazione, al tipo di architettura
hardware, ecc.
Se ci limitiamo all’architettura x86_64
(come in tutto il resto del documento) alcuni
degli attuali limiti del kernel di SUSE Linux
Enterprise 11 SP1 sono:
max # CPU logiche14: 4096
max RAM (certificata15): 16 TiB.
La lista completa è disponibile al seguente
link www.suse.com/products/server/
technical-information/, tab “Kernel limits”.
Guardando a questi numeri si evince che dal
punto di vista tecnico la scalabilità verticale
di Linux su x86_64 non è inibita a priori dal
punto di vista computazionale.
Osservando poi i file system supportati ed
alcuni limiti:
ext3
– massima dimensione file system: 16 TiB
– massima dimensione singolo file: 2TiB
ReiserFS v3
– max. dim. FS: 16 TiB
– max dim. File: 2 TiB
XFS (file system particolarmente adatto
per applicazioni che usano file di grandi
dimensioni)
– max. dim. FS: 8 EiB
– max. dim. File: 8 EiB
OCFS2
– max. dim. FS: 4 PiB
– max. dim. File: 4 PiB
Anche in questo caso si ha la conferma che
non esistano limiti a priori relativamente a
tale aspetto.
Da UNIX a SUSE Linux Enterprise
Un secondo aspetto da valutare è la
disponibilità di sistemi reali e certificati.
Riportiamo di seguito a scopo esemplificativo
alcuni sistemi dei produttori di hardware più
diffusi sul mercato:
DELL PowerEdge* R810, R910
IBM System x3850 X5, x3690 X5,
x3755 M3
HP Proliant* BL680c G7, DL 980 G7
Si noti che dal primo gennaio 2011 al
20 ­Ottobre 2011 sono stati certificati 231
nuovi modelli di server x86_64 per SUSE
www.suse.com
Linux Enterprise Server x86_64, è pertanto
­consigli­abile rivolgersi ai produttori per avere
le migliori indicazioni sui modelli più adatti.
Il terzo aspetto da valutare, il più importante
però, è indubbiamente la prova sul campo.
Da questo punto di vista niente può
sostituire test sul campo con simulatori di
workload (es.: benchmark SAP, benchmark
per CPU, benchmark per I/O ecc.) realmente
utilizzati da ogni cliente e confrontare i dati
presta­zionali raccolti con quelli disponibili
per i sistemi UNIX potenzialmente soggetti
a sostituzione.
p. 17
www.suse.com
Contattate il rivenditore
autorizzato SUSE più vicino.
SUSE Italia
Via Tirone 11
00146 Roma
Italia
T: +39 06 45 213 421
F: +39 06 45 213 301
www.suse.com
SUSE
Maxfeldstrasse
90409 Nuremberg
Germany
462-IT2167-003 | 10/11 | © 2011 Novell, Inc. All rights reserved. Novell, AppArmor, SLES, SUSE, the SUSE logo and YaST are r­ egistered
trademarks of Novell, Inc. in the United States and other countries.
*All third-party trademarks are the property of their respective owners.