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”. Fermandosi 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, configurazione e amministrazione possono essere effettuate mediante moduli di YaST. La semplicità d’uso e la coerenza dell’interfaccia utente di YaST rendono possibile l’amministrazione 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 rogazioni 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 disposizione 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 corredandoli 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 mediante 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 correttamente. 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 consigliabile 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 prestazionali 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.
