Decidere di portare l architettura

Transcript

1 AMD Opteron: la potenza dei 64 bit, anche per Linux! In prova in questo articolo uno dei primissimi computer in Europa equipaggiati con il nuovissimo AMD Opteron. Decidere di portare l architettura x86 su una piattaforma a 64 bit è stata una decisione molto coraggiosa da parte di AMD. Da tempo, infatti, si era diffusa negli ambienti specialistici l opinione che questa tipologia di processori CISC avesse ormai ben poco di nuovo da offrire. Probabilmente, si pensava, per quanto riguarda la velocità pura delle CPU, ci sarebbe stato spazio per una certa crescita delle performance. In fondo, semplificando, si tratta di un fattore eminentemente legato alla tecnica costruttiva, ossia alla possibilità di limitare la produzione di calore da dissipare, rendere sempre più sottili le pipe del processore, aumentare il numero di transistor, e ingrandire le cache L1 ed L2 migliorandone anche la resa. Dal punto di vista dello sviluppo tecnologico, invece, le prospettive parevano molto più limitate. L Opteron dimostra in primo luogo che ci si era sbagliati. Per poter capire, però, quale sia il vero valore dei nuovi processori dell AMD occorre analizzarne nel dettaglio le caratteristiche tecniche. Si tratta, infatti, di una evoluzione della piattaforma x86 affatto particolare. Da un certo punto di vista, addirittura, si potrebbe parlare di una evoluzione in un certo qual modo naturale. Purtroppo esistono parecchi miti su cosa sia un processore a 64 bit. Nella maggior parte dei casi si associa tale concetto all idea di una maggiore velocità computazionale. Più raramente si pensa un po confusamente alla massima quantità di memoria gestibile da parte del sistema operativo, o alle dimensioni massime dei filesystem e dei singoli file. Si tratta però di limiti che un x86-32 può valicare tranquillamente, purché il sistema operativo sia stato progettato in maniera opportuna, bene inteso. Esistono server Linux su processori di classe Pentium o Athlon che gestiscono 64 Gb di RAM e filesystem larghi diversi terabyte, sui quali si trovano file a volte altrettanto grandi. Proprio per fugare qualsiasi preconcetto, occorre partire da molto lontano, dal funzionamento teorico delle CPU. Descrivendo in maniera semplicistica (ad essere sinceri forse un po troppo semplicistica), il funzionamento di un processore: citeremo una control unit, composta da program counter (PC), e da instruction register (IR), e dal registro Program Status Word (PSW), che contiene i bit di codice di condizione fra cui la priorità della CPU e se l operazione eseguita è in kernel o user space. Il funzionamento della control unit è semplice. Il PC carica una istruzione dall indirizzo contenuto nel counter e ne opera la decodifica, incrementando, di conseguenza, il counter stesso. L istruzione viene quindi eseguita dall instruction unit, mentre, al contempo, il program counter decodifica quella successiva e così via, ciclicamente. Il PSW indica la modalità di esecuzione di ciascuna istruzione. Delle apposite Execution Unit si occupano dell esecuzione delle operazioni sugli interi, in virgola mobile e vettoriali. In particolare, le operazioni cogli interi vengono effettuate dall Arithmetic Logic Unit (ALU). L ALU carica i dati dei General Purpose Register (GPR), ai quali poi affida i risultati ottenuti. Un I/O unit consente l interazione con la memoria ed vari BUS del sistema. Dati e codice vengono cariti dai registri tramite istruzioni LOAD e STORE, tramite l I/O unit, la quale accede a grossi blocchi di memoria chiamati pagine, ove sono contenuti sia i dati che il codice. Nei processori moderni, in realtà, questo meccanismo è implementato sfruttando 24 intermedio

2 una forma particolare di parallelismo a pipeline. Più istruzioni vengono decodificate contemporaneamente, e vengono depositate in un buffer sino a che non potranno passare attraverso le varie Execution Unit, che operano indipendentemente. I processori che sfruttano questa tecnologia sono detti superscalari. Il sistema operativo deve essere consapevole di tutti i registri e di quali siano le loro caratteristiche. Quando esso ripartisce la CPU rispetto al tempo fra i vari processi, ogni qual volta che interrompe un programma in esecuzione a favore di un altro, deve salvarne tutti i registri in memoria, per poterli di nuovo caricare e ripristinare quando dovrà tornare ad eseguirlo. Tradizionalmente i processori x86 si definiscono a 32 bit per il fatto che sono dotati di otto General Purpose Register (GPR) i quali hanno per l appunto la dimensione di 32 bit. Il processore a 32 bit può effettuare dei calcoli su un range di interi che spazia da -2 (32-1) a 2 (32-1) - 1. Come si sarà capito, un processore a 64 bit ha dei GPR della dimensioni di 64 bit, e può compiere calcoli in intero in un range di valori che va da -2 (64-1) a 2 (64-1) - 1. In realtà, difficilmente una CPU ha modo di effettuare una operazione che richieda uno spazio di valori tanto ampio. I dati hanno dimensioni variabili. Possono arrivare ad un massimo di 32 o 64 bit, ma, in realtà, spesso, sono molto più piccoli, ed un registro difficilmente viene riempito per intero. Comunque, per venire incontro alle massime dimensioni potenziali, è necessario raddoppiare anche le dimensioni dell internal data path. Se si guarda alla situazione da questa prospettiva, non c è motivo per cui un calcolo a 64 bit, a parità di clock, e di numero di istruzioni eseguite per ciclo di clock, debba essere più veloce in uno user space a 64 bit rispetto a quella a 32 bit. Al contrario, sarebbe lecito aspettarsi un lieve rallentamento. La cache L1 è potenzialmente più piccola. Il numero di cache miss, al contrario, CPU Il Dual Opteron in prova 2 AMD Opteron 64-bit x86-64 architecture Memory 512MB 16GB ECC, Registered DDR333 SDRAM (8 slots, 2GB DIMM Max per slot, 3.05 cm max. height) Hard Drives 1-2 Hot swap 36GB 146GB U320 SCSI or 1-2 internal IDE HDDs SCSI Controller Embedded U320 controller with integrated mirroring support diviene verosimilmente maggiore, con un conseguente aggravio dell overhead. D altro canto, i General Purpose Register e l ALU sono utilizzati anche il memory addressing. Si tratta, in fondo, di semplici calcoli su interi, finalizzati ad indicare indirizzi in memoria. In questo senso il maggior numero di bit comporta la capacità di indirizzare direttamente una quantità di memoria maggiore. E risaputo che una CPU a 32 bit può indirizzare al massimo 4 GB di RAM. 32 bit equivale a 4.3 miliardi di byte. In realtà tramite delle vere e proprie alchimie sulla dimensione delle pagine, ed utilizzando uno speciale set di istruzioni/registri, il PAE, è possibile arrivare ad indirizzare sino a 64 GB di RAM, al prezzo di un piccolo calo prestazionale. In realtà usare il PAE, con tutti gli accrocchi che comporta, è una soluzione molto brutta, che pone parecchi problemi di carattere implementativo. In aggiunta a ciò, si deve considerare il fatto che, all interno di un user space a 32 bit, non è possibile che un processo posso allocare uno stack di dimensioni maggiori a 3.6 GB (non è qui il caso di approfondire perché si perda qualcosa dei potenziali 4GB totali). Network I/O Dual embedded Gigabit Ethernet PCI I/O 2 PCI-X expansion slots: 1 full-length 133Mhz/64-bit 1 half-length 66Mhz/64-bit Other I/O Internal CD-ROM & Floppy drives Embedded SVGA video, keyboard & mouse connectors Management Service processor running embedded Web server and SSL encryption for secure Web-based management from anywhere and dedicated dual 10/100 Ethernet ports to service processor Queste limitazioni scompaiono del tutto con un processore a 64 bit, ed uno spazio utente analogo, dal momento che in teoria si potrebbero indirizzare sino a 18 milioni di terabyte. A dire il vero, parlando di memoria, l x86-64, come anche l alpha, può far affidamento sino a 48 bit di spazio d indirizzamento virtuale, il che equivale pur sempre a più di un terabyte. Uno spazio d indirizzamento più ampio richiede una maggiore potenza per calcolare gli indirizzi in memoria, è vero, ma è un prezzo tutto sommato ridotto, che si paga ben volentieri a fronte dei vantaggi che conferisce. Un discorso analogo si può fare per i file più larghi di 2 GB, per i quali i sistemi operativi per processori a 32 bit debbono ricorrere ad artifici quali spezzettare l offset in due parti da 32 bit. Per quello che riguarda le operazioni in virgola mobile, la situazione è ancora più semplice. Avere dei registri più grandi, in linea di principio, serve ad aumentare l accuratezza dei risultati. Lo standard IEEE 754 stabilisce che per i calcoli in singola precisione si debbano usare almeno 32 bit, 64 per quelli in doppia precisione. Lo standard non è più rispettato da anni. intermedio 25

3 In effetti i moderni processori x86 usano degli appositi registri detti FPR, ed i conti veri e propri vengono effettuati dalla Floating Point Unit (FPU). Il fatto è che questi registri, anche sui vecchi x86, sono già di per sé grandi 64 bit. Inoltre per i calcoli in doppia precisione si impiegano i registri 387, ampi 80 bit. Anche se i float restano di 64 bit, il coprocessore li converte in un formato ad 80 bit per aumentare la precisione. Per quanto riguarda le operazioni in virgola mobile, quindi, non c è differenza fra processori a 32 e 64 bit. Un discorso analogo si applica al calcolo vettoriale, per il quale si impiegano registri di ben 128 bit. Opteron in legacy mode, un Athlon con qualcosa un più Abbiamo detto che il sistema operativo deve avere ben presente quali registri siano a disposizione, e di che dimensione siano. Dal canto suo, una CPU a 64 bit, normalmente, per eseguire codice a 32 bit, deve necessariamente ricorrere a vari stratagemmi per emulare un processore con GPR più piccoli. L Opteron, a differenza di ogni altra architettura a 64 bit, è in grado di far funzionare codice a 32 bit nativamente. Infatti, per poter garantire la piena compatibilità con i processori CISC attuali, compresa anche la modalità reale a 16 bit, l Opteron è in grado di funzionare in diverse modalità. A seconda di quella richiesta dall OS, si può veramente dire che si ha a che fare con una CPU differente. Con un sistema operativo con kernel ed user space a 32 bit, questo nuovo x86 funziona in quello che viene definito legacy mode. Sostanzialmente vengono usati solo otto GPR, per una estensione di 32 bit ciascuno. Lo stesso succede anche per l IR. In legacy mode, sostanzialmente, ci si trova di fronte sostanzialmente ad un Athlon. In questo modo le normali distribuzioni Linux create per le architetture derivate dal 386 funzionano nativamente. Come è facile intuire, non dover ricorrere ad alcuna forma di emulazione fa si che, con sistemi operativi ed applicazioni per i CISC tradizionali, non venga comportato alcun calo prestazionale di sorta rispetto alle altre piattaforme native. L Opteron in legacy mode non è solo in grado di far funzionare i sistemi operativi e le applicazioni che richiedono la modalità protetta a 32 bit, ma può anche funzionare in modalità reale. Tanto per intenderci, è possibile vedere su Opteron un vecchio DOS, con i suoi binari a 16 bit. L unica differenza avvertibile da parte dell utenza consiste nel fatto che la cache L2 è di ben 1024KB (invero sono varie unità da 128KB). In realtà, da quanto abbiamo detto prima, è facile capire perché la cache di secondo livello sia così grande. Persino i 512 KB di cui sono dotati i recentissimi Barton sono troppo pochi per uno user space a 64 bit. Ovviamente ciò ha degli strascichi più che positivi quando ci si trova in legacy mode. Legata alle necessità di supportare l indirizzamento della memoria a 64 bit è la riprogettazione dei Translation Lookaside Buffer (TLB) in hardware sulla CPU, anche se, a dire il vero, il Barton aveva già intrappreso questa strada. L eredità dell Athlon si vede anche nella fatto che l L1 è divisa in due parti, una che funge da data cache, l altra da instruction cache. Purtroppo non abbiamo dati sul consumo energetico effettivo del processore, e di conseguenza sul quanto calore si debba potenzialmente dissipare. Un altra differenza rispetto agli Athlon MP ed XP consiste nella presenza del set di istruzioni SSE2, che si pone come alternativa, e forse futuro sostituto, del vecchio 387 per i calcoli in virgola mobile. Tale set di istruzioni era già presente sui processori PentiumIV e sugli Xeon da esso derivati. Averlo anche su Opteron fa capire come l AMD intenda proporre il suo nuovo prodotto come un valido concorrente non solo nel mondo dei server a 64 bit ai blasonati SParc64, PPC64, Alpha, PaRISC, ia64, ma anche come una concreta alternativa nel mondo dei sistemi a 32 bit. Resta l indubbio vantaggio che, quando sarà il momento, Opteron su cui ora gira Linux per Athlon, potrà poi far funzionare, quando le applicazioni utili saranno ben presenti e radicate nell utenza, uno user space a 64 bit. In breve, la sua curva di obsolescenza verosimilmente sarà molto meno ripida di quella della concorrenza. Opteron in long mode, una CPU a 64 bit, che non rallenta con binari a 32 bit Con un sistema operativo ed uno user space concepita per i 64 bit, l Opteron, è logico, dà il meglio di sé. La modalità con cui è possibile far funzionare un OS a 64 bit si definisce long mode. Essa è in grado di supportare due submodalità per l esecuzione dei binari. Il 64-bit mode, come dice il nome, è quello per le nuove applicazioni a 64 bit. La compatibility mode rende possibile lanciare anche programmi in modalità protetta a 2 bit con un OS con kernel a 64 bit. Rimangono tutte le limitazioni dello user space a 32 bit. Un processo non può allocare uno stack di esecuzione di più di 3.6 GB di RAM, e non si può fare affidamento su più di 4 GB di RAM totali. Il PAE, ovviamente, non è presente. Il long mode non ha alcuna sub modalità per lo user space a 16 bit. In fondo non è una mancanza molto grave. In 64-bit mode l Opteron può accedere a ben trentadue registri General Purpose grandi 64 bit. In compatibility mode il processore rende disponibili agli applicativi solo otto di questi registri, dimezzandone naturalmente le dimensioni. Abbiamo visto come in realtà, a parità di numero di GPR, una CPU a 64 bit sia forzatamente un poco più lenta di una a 32. Le operazioni per cogliere gli interi ed il calcolo delle allocazioni di memoria sono più costosi, secondo alcune stime di 26 intermedio

4 carattere generale, la differenza di performance si aggira attorno al 5%. Il fatto che i GPR siano ben 32, consente, invece, un notevole incremento prestazionale rispetto agli Athlon a parità di clock. C è però un altro dettaglio grazie al quale l Opteron è persino leggermente più veloce in 64-bit mode di quanto non sia in compatibility o in legacy mode. Abbiamo visto come poter contare su un range da -2 (64-1) a 2 (64-1) -1 per il calcolo sugli interi, il più delle volte, non sia poi così necessario per i programmatori. Inoltre una simile ampiezza si paga, tanto, troppo per quello che rende. Nell Opteron, anche nella submodalità a 64 bit, la data size di default per il LOAD e lo STORE nei GPR resta di 32 bit. Con questa data size la CPU esegue le varie istruzioni. Se occorre operare su un intero più grande o più piccolo, il processore deve premettere, alle istruzioni che debbono sfruttare tale intero, l apposito prefisso REX. Questo prefisso è di un bit e, di conseguenza, alla fine, il codice che viene eseguito risulta di 65 bit. Sarebbe logico obiettare che, così, si spreca ancora un poco di cache L1 ed L2 ma, a conti fatti, occorrerebbe che un eseguibile usi molti interi a 64 bit rispetto a quelli a 32 perché tale strategia comporti una perdita invece che un guadagno. Se il sistema operativo è stato concepito e progettato correttamente, applicazioni a 32 e 64 bit possono girare contemporaneamente, senza alcun conflitto. In più, non trattandosi di una emulazione, lo user space a 32 bit non risulta affatto rallentato rispetto al legacy mode, o ad una normale CPU x86. Semplicemente non vengono sfruttati tutti i General Purpose Register e le nuove feature aggiuntive dell X Da questo punto di vista occorre ammettere che le distribuzioni Linux già portate su Opteron costituiscono uno splendido esempio di progettazioni. Ciascuno user space, infatti richiede un set di shared library differente. Per dirla con semplicità, debbono essere presenti, e venir caricate in memoria, due glibc diverse (a 64 e 32 bit), come pure due versioni separate per ogni libreria condivisa. Ciò comporta una notevole complicazione per quanto riguarda il loader ld.so, che deve saper riconoscere il formato esatto dei binari. Ciò comporta uno spreco di RAM più che accettabile. Il fatto è che, sino a che non saranno disponibili tutte la applicazioni necessarie all utenza compilate per sfruttare i 64 bit, non si sarà comunque forzati a rinunziare ad un sistema operativo che a 64 bit abbia almeno il kernel. E un po quello che succede con Solaris 8, in cui lo user space è interamente a 32 bit, con tutte le limitazioni del caso, ma il kernel è a 64 bit, o meglio con Solaris 9, il quale nello spazio utente piò avere ambedue i tipi di eseguibile (ovviamente il processore Sparc64 funziona molto diversamente). Al di là della tecnologia: alla ricerca dell uso I processori CISC x86 erano ormai giunti ad un bivio. Il problema non era tanto la velocità, o la quantità massima di memoria che potesse essere gestita dal sistema operativo. Abbiamo visto che il PAE permette di aggirare questo ultimo problema. Il vero ostacolo che avrebbe potuto portare alla morte dei fortunati eredi dell 8086 è l impossibilità di allocare uno stack maggiore ai 3.6GB di RAM per ciascun processo in esecuzione. Anche se sui desktop sicuramente nessuno ha ancora avuto modo di cozzare addosso a questo muro, ciò non è altrettando vero per il mondo del calcolo scientifico. Ci sono parecchie simulazioni ormai che richiedono processi in grado di allocare ben più di 4 GB di RAM. In questi casi, attualmente, si può solo ricorrere agli Unix proprietari, o più raramente a Linux, sulle CPU RISC a 64 bit attualmente sul mercato, oppure occorre poter scomporre la simulazione in più parti di dimensioni ridotte. Questo ultimo metodo non sempre è applicabile, il primo, invece, è troppo costoso. La situazione è forse più complessa per quanto riguarda il mondo dei server non destinati al calcolo puro. In linea di principio, ad eccezione di certi giganteschi database, è molto difficile che si abbia bisogno di 64 bit su questi server. Forse solo certe applicazioni in Java fanno eccezione, ma, più che altro, a causa di errori progettuali nelle applicazioni stesse. Permane tuttavia il preconcetto, forse leggermente alimentato da altri sistemi operativi, che i processori a 64 bit siano più veloci, e siano gli unici a poter gestire tanti GB di memoria fisica. Inoltre ben pochi hanno l ardire di provare su di essi Linux, credendosi maggiormente garantiti dall adozione dello Unix proprietario distribuito dal vendor dell hardware. Ciò penalizza essenzialmente Linux, legandolo all x86 e relegandolo a compiti minori. AMD ha mostrato che il futuro dei CISC non è così limitato come si credeva, e che per avere i 64 bit non serve ricreare dal niente una nuova architettura, basta intermedio 27

5 Figura 1 e 2: vista dall alto e frontale del server Newisys equipaggiato da due Opteron. saper migliorare quella già esistente. Per sua natura, però, l X86-64 ha dei costi molto ridotti rispetto alle altre CPU a 64 bit e, eccetto la motherboard, il resto dell hardware cui si accompagna è quello dei normalissimi PC. Ciò lo rende particolarmente concorrenziale su un mercato tanto selettivo, dove i problemi di budget sono all ordine del giorno. Rimane, al momento, il problema delle applicazioni. Ad eccezione del software libero, poco o niente è stato ancora portato su x E più o meno lo stesso problema che ha l ia64 di Intel. Non essere costretti a ricorrere ad alcuna emulazione di sorta, però, fa si che anche gli attuali binari a 32 bit per Linux su PC possano essere eseguiti senza decrementi prestazionali. Tutto ciò che gira su Linux per Pentium/Athlon gira anche su x86-64, solo che lo fa un po più velocemente. La transizione, quindi, è molto facilitata, e può avvenire senza strappi netti, seguendo il normale ciclo di sviluppo ed obsolescenza del software. Questa transizione, del resto, non potrà non avvenire, se non altro perché i programmatori impiegati nella aziende che vendono applicazioni destinate a Linux o Windows non aspettavano altro che una piattaforma di questo tipo, per potersi svincolare da tutti quegli obrobri di gestione della memoria cui l user space a 32 bit li vincolava. Server Newisys dual Opteron Presentiamo la soluzione 1U dual Opteron rack server disegnata dalla Newisys che rappresenta una sorta di materializzazione del sogno Opteron per gli AMD-addicted nei trade-show e negli eventi legati al mercato High Performance Computing dello scorso anno. Premettiamo che si tratta di unità di PRE-PRODUZIONE e, quindi, il design della board e le funzionalità offerte 1 2 possono essere modificate al momento dell annuncio ufficiale del prodotto. Vediamo questo server più da vicino, avvalendoci dall immagine di figura 1. Viene configurato con due dischi fissi hot-swappable, un CDROM ed un drive floppy. Si possono aver fino ad 8 banchi di memoria DDR registered, in tagli fino a 2 GB, per un totale di 16GB. Esaminando più da vicino il retro del server si notano le caratteristiche di I/O. Le possibilità di espansione sono costituite da 2 slot a 64 bit PCI-X: uno slot PCI-X full-length a 133Mhz ed un halflength PCI-X a 66 Mhz. Nell angolo in alto si trovano i due chip Gigabit Ethernet della Broadcom, il chip AMD nel centro della board è l HUB di IO HyperTransport 8111, mentre il chip con il dissipatore verde è il PCI-X HyperTransport tunnel Tra i due slot PCI-X si trova il sistema di monitoraggio. Questo sistema è costituito da un Service Processor che altro non è che un PowerPC embedded che si trova tra i chip di memoria dove viene immagazzinato il software di monitoraggio. Si possono utilizzare fino a 8 chip di memoria flash da 2 MB. Il service processor è separato dal resto del sistema ed è connesso alla rete da una porta Ethernet 10/100. In questa area sono presenti anche il chip del BIOS e il chip video (Trident). All avvio del sistema la prima componente a fare boot è il sistema di monitoraggio. Il pannello LCD presente sul frontale (figura 2) fornisce lo stato della macchina (stato del sistema operativo e numero IP assegnato al service processor). È possible collegarsi al sistema di controllo del sistema via rete. Controllo Remoto e Service Processor La Newisys la disegnato questa board per Opteron in modo da poterne permettere il controllo totale da remoto. Già in questo stato iniziale di pre-produzione, l obbiettivo di fornire uno strumento 28 intermedio

6 completo di monitoraggio e di amministrazione remota sembra raggiunto, e sia gli attuali tool di console management che quelli previsti in futuro sembrano molto promettenti per assicurare una notevole scalabilità e flessibilità operativa in ogni situazione. Allo stato attuale, le funzionalità implementate sono: accensione e spegnimento. Questo implica che l hardware per il System Management deve essere indipendente da quello del server e funzionare quindi quando il processore Opteron è spento; gestione del consumo elettrico del server. Al momento è un settaggio statico ma in futuro (una volta implementato nel sistema operativo) permetterà di gestire il livello del consumo dei server dinamicamente in base al carico; Figura 4: il system event tiene traccia di tutto quello che accade nel server. boot, shutdown, e re-boot del sistema operativo del server; stop del boot del server al BIOS per controllare e modificare i settaggi; upgrade del BIOS del server ( flash the BIOS ) usando il download dei file dalla rete; installazione e upgrade del sistema operativo del server; upgrade del software di System Management stesso (via download dalla rete); monitoraggio dello stato fisico del server in fase di operazione: controllo delle temperature,voltaggio errato e componenti malfunzionanti. Il service processor (che fa girare una versione embedded di Linux) è la chiave di tutte queste funzionalità di monitoraggio, installazione e supporto: il suo scopo principale è di monitorare il sistema per evitare guasti hardware. 3 Figura 3: la console di management del server di Newisys. 4 Sono in fase di implementazione funzionalità aggiuntive di gestione del consumo e del rumore (usando istruzione PowerNow! dei futuri Opteron per alimentare la CPU con alimentazione variabile a seconda dell uso) Diamo ora un occhiata alla console di System Management del server Newisys, la cui schermata principale è riprodotta in figura 3. Questa console fa parte del sistema operativo embedded del Service Processor. Si può vedere lo stato di tutti i componenti principali del server (temperatura, velocità delle ventole, power supply etc.). Questi valori sono visualizzati sia in forma grafica che in formato tabellare. L applicazione si compone di html, javascript e Applet Java in modo che ogni Browser con supporto Java possa controllare e monitorare il sistema. È comunque possible accedere alla console del sistema di controllo in modalità testuale (CLI command line interface). La CLI permette di realizzare script e fornisce tutte le funzionalità della console grafica. La schermata dei system event, di cui produciamo un esempio in figura 4, tiene traccia di tutto quello che è successo nel sistema (verde significa che tutto è ok, giallo avverte sulla presenza di un possibile problema mentre il rosso che la componente monitorata è in uno stato critico e va immediatamente controllata). Analizziamo ora più da vicino le funzionalità di ammistrazione e monitoraggio del sistema Newisys. La figura 5 mostra uno schema dei sensori e dei controller previsti nel server. Il cervello del sistema di controllo è un processore Motorola MPC855T PowerPC embedded, che include una DRAM dedicata e una memoria flash in cui sono immagazzinate le applicazioni. È presente anche una interfaccia Ethernet 10/100 per collegarlo ad una LAN di management. Sono presenti vari sensori di voltaggio e temperatura, oltre a 8 controller delle ventole di raffreddamento. L interfaccia JTAG fornisce la capacità di monitoraggio del processore Opteron: nel monitoraggio è incluso la lettura dei intermedio 29

7 registri interni e lo stato delle CPU. Questi dati vengono analizzati e registrati, come per una scatola nera di un aereo; è quindi possible registrare lo stato dell Opteron prima di un eventuale crash ed analizzarne in tempo reale i motivi. È infine possibile collegare i sistemi di controllo di vari sistemi Newisys attraverso una LAN di management come mostrato nello schema di figura 6. In questo modo è possible gestire insieme centinaia di macchine attraverso degli script scritti ad hoc. Caratteristiche applicative e protocolli del remote system management Per la realizzazione della suddetta LAN di management sono stati implementati vari meccanismi ed utilizzati diversi protocolli di amministrazione remota. Vediamoli un po più in dettaglio. Figura 6: attraverso una LAN di management si possono amministrare più server. 5 Figura 5: lo schema dei sensori e dei controller previsti nel server. 6 Simple Network Management Protocol (SNMP) SNMP vers. 2/3 viene usato per accedere alla management information base (MIB) del service processor e per gli Opteron è accessibile via IP address del service processor. Il supporto SNMP può essere incluso in sistemi di Enteprise Management come IBM Director, Tivoli NewView, and HP Openview. Secured Shell (SSH) È lo standard SSH di Linux e viene usata per accedere in modo sicuro da remoto al service processor. L accesso SSH fornisce una shell interattiva e la possibilità di esecuzione remota. NFS e Samba NFS and Samba permettono al service processor di accedere a file system su server remoti; i file server di rete sono utilizzati per consentire al service processor di avere spazio disco a disposizione per registrare log file, caricare nuovi BIOS, consultare il sistema di help, utilizzare sistemi di diagnostica etc. NIS e Active Directory L autenticazione di accesso al service processor può essere integrata in domini NIS e Active Directory già presenti sulla rete. Web Server Il system processor include un proprio web server. Viene usata la versione standard di Apache 2.0 con interfaccia SSL (quindi ogni accesso viene effettuato in modo sicuro). È possible inoltre implementare script CGI per inviare comandi al service processor direttamente dal browser. Web Browser Per accedere alla console di system management server un browser moderno che implementi Java e SSL (consigliato Internet Explorer o una versione recente di Netscape). Scripting Tutte le funzionalità disponibili via Web sono disponibili anche in modalità command line. Questo permette di realizzare script di gestione per cluster composti da molti nodi (via SSH). Sicurezza Vengono utilizzate connessioni separate per il service processor ed il server. Tali connessioni possono essere mantenute anche disconnesse. Sono previsti, per entrambe le connessioni, protocolli di criptazione (SSL e SSH). Diagnostica Newisys fornisce diagnostica per le CPU Opteron e per il service processor. Il sistema operativo deve essere in stato di shutdown per usare i diagnostici: questi 30 intermedio

8 sono applicazioni che girano su di un kernel Linux speciale creato per Opteron. Non riescono ad essere caricate nella flash del service processor e debbono essere caricate via rete (via NFS o SAMBA) Update Software È possible fare l update del software di system management sia dalla flash che via rete. Vengono forniti comandi e procedure ad hoc per il processo. Failure del System Processor In caso di failure del system processor il sistema continua a funzionare regolarmente. Il boot del sistema operativo non richiede il service processor e l hardware funziona regolarmente. In questo caso le ventole girano però a velocità massima per assicurare che il raffreddamento non sia compromesso. Chiaramente il management remoto e il monitoraggio non sono disponibili. Infine, fra le funzionalità non ancora implementate ma previste in futuro, citiamo le seguenti: Server logici Newisys pensa di offrire in futuro macchine con più processori e caratteristiche superiori di I/O e memoria. È pensabile implementare la suddivisione del server fisico in vari moduli logici. Ogni modulo logico potrà eseguire il proprio sistema operativo ed essere clusterizzato con le altre partizioni. A livello di service processor servirà una modifica del sistema operativo e del software di gestione. Coordinated Server Group Power Management Newisys crede che in futuro i sistemi operativi permetteranno di gestire il Altri sistemi operativi e compilatori per il sistema Opteron Abbiamo visto le caratteristiche principali di quella che è la distribuzione più sperimentata per l uso sulla piattaforma Opteron. Ma non è l unica. Per prima cosa non dobbiamo dimenticare che la caratteristica principale di questa piattaforma è la possibilità di funzionare indifferentemente in modalità 32 o 64 bit. E questo lo possiamo verificare direttamente in fase di uso. Per esempio, è possibile installare la distribuzione RedHat 7.3 standard versione x86 senza perdere alcuna funzionalità e, nel caso della configurazione Newisys, senza bisogno di installare driver aggiuntivi (per esempio per la famosa interfaccia GigaEthernet Broadcom). Altra distribuzione a 32 bit utilizzabile è la Suse 8.1 (anche nella versione Enterprise Server 8.0). E, anche se andiamo fuori tema, lo stesso vale per Windows 2000 Server A livello di distribuzione a 64 bit è disponibile ad oggi e liberamente scaricabile dai mirror ftp la versione Mandrake 9.0 per Opteron (Beta 2) che offre su questa piattaforma tutte le caratteristiche di facilità d uso e configurabilità tipiche di questa distribuzione. Mandrake ha oggi un forte commitment sul supporto della piattaforma Opteron. E in programma (metà 2003) anche una distribuzione ad hoc per la configurazione e la gestione di sistemi di cluster basati su processori Opteron. Sempre in ambiente clustering anche Scyld Beowulf (la versione commerciale del software di clusterizzazione più diffuso in ambiente tecnico/scientifico) è disponibile su piattaforma Opteron da subito. A livello di compilatori il Portland Group offre in public beta la versione 5 della sua suite di compilatori ottimizzati per il 64 bit su piattaforma Opteron (a breve anche la versione a 32 bit). Tra le varie distribuzioni su nominate le versioni a 32 bit offrono una stabilità pressoché perfetta. La versione Mandrake a 64 bit soffre ad oggi di qualche problema di gioventù (ha qualche problema di stabilità del kernel) che sarà sicuramente risolto al più presto. E interessante vedere come, anche a livello software, ci sia un grande interesse intorno a questa piattaforma come dimostra la disponibilità da subito di un corredo software sufficientemente completo. power management di gruppi di server in modo integrato, ponendo dei limiti alla quantità di potenza elettrica che un certo rack di server sarà autorizzato ad utilizzare. Questo modulo, particolarmente utile in siti di grandi installazioni, verrà incontro a queste esigenze. Predizione di Failure Hardware Sarà possibile fare delle previsioni di rotture hardware dall analisi dei dati immagazzinati dal software di management. In base a queste previsioni, sarà quindi possibile sostituire alcuni componenti hardware prima della rotture minimizzando i tempi di downtime. E in futuro Il prodotto di lancio della Newisys sarà questo Dual Opteron 1U server. Viste le caratteristiche della CPU e la cura posta nello sviluppo del sistema di management e diagnostica, sono facilmente ipotizzabili estensioni multicpu di questa architettura. Tuttavia, al momento AMD non vuole anticipare niente ma, date le premesse, attendiamo fiduciosi ogni possibile sviluppo. SuSE Linux Enterprise Server 8 RC5 per sistemi AMD 64-bit Questa distribuzione è stata appositamente sviluppata da SuSE, in collaborazione con AMD, per sfruttare appieno l architettura 64 bit dei processori di ultima generazione Opteron. Sebbene si tratti di una prerelease, il livello di stabilità e la completezza della SLES 8 RC5 da noi riscontrato fa fugare ogni minimo dubbio sul fatto che essa possa essere una seria candidata a release definitiva. Con essa il sistema Newisis descritto in questo articolo non ha avuto nessuna difficoltà ad essere installato, e tutta la serie di applicazioni industriali a 32 bit (da Fluent ad Abacus), ed utilizzando il intermedio 31

9 compilatore gcc-33 (C, C++ e FORTRAN) anche applicazioni 64 bit, hanno portato a termine i test run senza problemi. Il fatto che si parli di una prerelease non ci permette di allegare a queste note figure e snapshot. Non ce ne vogliano i lettori, anche se indubbiamente la presenza di figure possa servire ad alleviare la lettura, ci sembrava comunque del tutto pleonastico proporre nuove immagini dello YaST. La SLES 8 RC5 prerelease for AMD 64-bit system si presenta con un SLES 8 install CD e 3 United Linux install CDs. Questo insieme può essere utilizzato per installare un nuovo sistema SuSE su sistemi dotati di AMD Opteron e Athlon 64. All inizio un po di warning sulle release notes ci mettono in guardia sull uso di determinate combinazioni video card/motherboard. Ci rassicuriamo che i nostri server Newisys non rientrino nel novero della black list (invero corta), e poi partiamo. Di fronte, la solita rassicurante interfaccia dello YaST: l unica vera novità che val la pena menzionare è la procedura di installazione della nuova versione dello GNU C Compiler (GCC 3.3 prerelease e Glibc version che si installa in /opt/gcc-33) che consente prestazioni migliorate sulle architetture x Va notato che il gcc 3.3 di default prova a compilare per architettura x86-64, a meno di non utilizzare l opzione -m32 per produrre invece codice a 32 bit. Con questa versione non è possibile compilare il kernel , mentre è possibile compilare kernel e successivi. In mancanza di reali applicazioni a 64 bit, la nostra attenzione si è concentrata sulle applicazioni a 32 bit in legacy mode. Il supporto all esecuzione di codice a 32 bit su Opteron è supportata tranne poche eccezioni dichiarate: applicazioni che accedono direttamente al kernel, ovvero programmi che accedono direttamente alle strutture del kernel, e che quindi debbono lavorare necessariamente sui 64 bit. Un esempio di tali architetture sono le modutils oppure i tool di gestione del logical volume manager. SLES 8 for x86-64 presenta per tali applicazioni una versione a 64 bit. Sun Java 1.3 release per piattaforma x86 Sun Java 1.3 ha una dipedenza relativa alla fine dello spazio di indirizzamento di default di Linux/x86, che è posto a 3GB. In Linux/x86-64 tale spazio di indirizzamento di default e di 4GB, provocando quindi il fallimento della Java Virtual Machine. Questo problema non si presenta con Java IBM o con il Blackdown release. Moduli PAM Le librerie PAM sono a 64-bit, e non è possibile gestire o aggiungere moduli a 32-bit. Questo di fatto limita fortemente l utilizzo di moduli aggiuntivi per l autenticazione e l accounting. Con queste premesse abbiamo testato due codici industriali di largo interesse, quali Fluent vers. 6.1 ed Abacus vers. 6.3, entrambi per Linux/x86 a 32 bit. Come premesso i test si sono conclusi con i dataset di prova senza alcun intoppo. Poiché questo articolo viene scritto in regime di no disclosure, non ci è consentito di pubblicare dati relativi alle prestazioni, che possiamo comunque definire molto interessanti. Per i test su applicazioni 64bit abbiamo provato con successo la compilazione di alcune applicazioni che prevedevano interazione con diverse componenti di sistema (ad esempio ntop per il network layer, varie utility per la grafica ecc.), sia con compilatore GCC che con compilatore Portland. Abbiamo anche modificato la Unixbench suite per testare il comportamento della nota raccolta di benchmark su architettura a 64 bit. Le conclusioni che possiamo trarre, in attesa dell ufficializzazione di tutte le componenti in lizza, si riassumono in poche parole: l architettura AMD x86-64 è pienamente supportata dalla SuSE Linux Entrerprise Server 8, ed insieme rappresentano un interessante connubio, fra l altro destinato a rafforzarsi dato l impegno profuso dalla SuSE stessa (con Andrea Arcangeli in prima linea) sullo sviluppo di estensioni NUMA per il kernel Linux. Al momento, comunque, l insieme ci appare un ottima scelta; pur rimanendo in attesa del porting a 64bit di applicazioni critiche, ovvero applicazioni con necessità di allocare più di 4 GB di RAM, le prestazioni del legacy mode dell Opteron garantiscono comunque una buona salvaguardia dell investimento. note sugli autori Maurizio Davini m.davini@oltrelinux.com Lavora come sistemista presso il Dipartimento di Fisica dell Università di Pisa. Le sue attività coprono tutti i sistemi Unix (proprietari e non). Usa Linux fin dalla prima versione beta ed ha installato il suo primo cluster nel I suoi interessi attuali si concentrano sul calcolo ad alte prestazioni e sullo storage di dati in ambiente Linux. Luigi Genoni l.genoni@oltrelinux.com Segue lo sviluppo di Linux sin dal kernel 0.96, partecipa attivamente allo sviluppo della Linux Standard Base. Sistemista alla Scuola Normale Superiore di Pisa e presso molti altri enti pubblici e privati, ha amministrato professionalmente quasi tutti i sistemi Unix, sia proprietari che free. Si dedica principalmente allo studio ed allo sviluppo di architetture complesse, quali cluster paralleli per il calcolo massivo e seriali per l alta affidabilià dei servizi. Italo Lisi i.lisi@oltrelinux.com Laureato in Informatica all Università di Pisa, ha una esperienza circa quindicennale quale sistemista in ambito Unix. Ha lavorato su sistemi a parallelismo massivo e su architetture a cluster sia orientati al calcolo scientifico che alla realizzazione di servizi di rete. Membro auditore della Linux Standard Base (LSB), ha affrontato fin dal 1995 le tematiche di sviluppo di cluster basati su Linux; nell ambito di diverse associazioni tecnologiche, ha collaborato, per le problematiche computazionali, con progetti di ricerca in diversi settori, dall astrofisica alla fisica delle alte energie. Ha rivestito per 10 anni il ruolo di Responsabile Tecnico per il Calcolo Scientifico presso il CED della Scuola Normale Superiore di Pisa. Attualmente è responsabile del Centro Servizi Informatici presso la Scuola Superiore Sant Anna di Pisa. 32 intermedio