Piattaforma universale standard-based
5.1 Architecture (R)Evolution
5.1.2 Sistema operativo
Il progetto del Carrier Grade Linux (CGL) consiste nel distribuire un ambiente di sistema operativo Linux, basato sui concetti di robustezza, portabilità ed efficienza di costo. Gli aspetti del sistema operativo rilevanti per i requisiti carrier-grade includono:
• High Availability: questo comprende il supporto per ridurre il tempo di fermo di un sistema, grazie alle funzionalità di riavvio veloce e alla minimizzazione del tempo totale di inizializzazione/reboot. Inoltre, la presenza di meccanismi per migliorare il kernel e monitorare le applicazioni facilitano un migliore e tempestivo rilevamento di errori. Un alto livello di disponibilità comporta anche un supporto per aggiornamenti “al volo” del software di sistema, includendo funzionalità di versioning, come Dynamic Link Libraries, demoni e driver di componenti dinamicamente caricabili.
• Serviceability: i meccanismi per conseguire tale requisito includono il supporto per il debugging e il tracing del sistema, e il dump dell’immagine del kernel e
dell’applicazione. Tutte queste funzioni devono anche essere accessibili durante e prima il boot del sistema operativo per favorire l’utilizzo di una rete che assicuri un lavoro di manutenzione off-site. Questo comporta diverse richieste sulle operazioni del piano di controllo della rete, inglobando un supporto hardware di basso livello per accedere allo stato precendente al riavvio.
• Standards compliance: la direzione comune dei NEP segue la linea concorde agli standard POSIX, identificando il supporto desiderato per protocolli standard comuni e per le estensioni dei protocolli stessi (ad esempio le implementazioni per l’instradamento di pacchetti IP).
• Hardware support: l’impiego di componenti hardware basati su standard modulari commercial-off-the-shelf comporta, di conseguenza, una interconnessione dell’ambiente Linux verso tali piattaforme.
• Security: vengono adottare opportune misure di sicurezza, che includono accounting e cifratura dei dati, ma anche avvio sicuro del sistema e politiche di gestione dei diritti per l’accesso degli utenti.
• Performance: questa area include il supporto per un modello real-time altamente efficiente e quantificabile (per esempio politiche di scheduling e miglioramenti di latenza), in aggiunta ai meccanismi per ottimizzare l’efficienza del multiprocessing. In maniera più generale il requisito di base consiste nel sostenere un’elevata densità di subscriber per ogni nodo, coinvolgendo CPU multicore al fine di accelerare l’elaborazione del protocollo.
• Long Term Support: la durata della vita dei prodotti può variare dai cinque ai dieci anni.
5.1.3 Middleware
Il livello middleware della Carrier Grade Platform è composta da diverse aree funzionali al di sopra del sistema operativo, che comprendono servizi ad alta
sono basati sulle specifiche dello standard SAForum, relative alla Application Interface Specification (AIS) e alla Hardware Platform Interface (HPI), le due interfacce che interagiscono rispettivamente con i servizi applicativi e con il livello fisico.
I requisiti di disponibilità possono essere così alti da raggiungere i 7-nines, che si traducono in un downtime per anno di 3 secondi; per ottenere questi livelli, i servizi applicativi devono essere costruiti al di sopra della piattaforma carrier-grade, in modo tale che il software dell’applicazione è al corrente dei servizi HA forniti, ma, nello stesso tempo, non è strettamente legato all’hardware sottostante. A livello fisico, le risorse ridondanti vengono utilizzate per prevenire interruzioni di servizio dovute a guasti hardware, gestiti da meccanismi del livello middleware oppure da sistemi intelligenti di protezione dei componenti.
I servizi di High Availability forniti dalle funzionalità del livello middleware aiutano a raggiungere i seguenti obiettivi:
• Avviare e fermare i processi applicativi del sistema.
• Supervisionare i componenti hardware e i processi dell’applicazione.
• Gestire gli stati e le applicazioni del sistema, includendo azioni di ripristino in casi di fallimento.
La replicazione dello stato è il meccanismo in grado di raggiungere un modello hot stand-by attraverso l’utilizzo della tecnica del checkpointing. Un’applicazione è responsabile di ogni replicazione di stato, necessaria ad accelerare i cambiamenti e a ridurre le interruzioni del servizio durante tali passaggi. Le applicazioni hanno, quindi, bisogno di definire i dati che recuperano lo stato, e determinano quando la copia dello stato può aver luogo.
La seguente lista comprende una parte significativa dei domini di HA, messi a disposizione dalle specifiche di SAForum:
• Un framework di gestione della disponibilità definisce le API per controllare il ciclo di vita del software applicativo, come la registrazione e la deregistrazione, il monitoraggio delle condizioni, la segnalazione degli errori. Il software del livello middleware, che fornisce questa interfaccia, agisce insieme alle risorse
ridondanti all’interno del cluster, per offrire un sistema fault-tolerant e per eseguire funzioni come l’assegnamento di stati HA e la gestione dei fallimenti.
• Supporto per diversi modelli di ridondanza, come N+1, 2N, N+M.
• Rapido recupero e failover, in caso di guasti.
• Servizio di messaging: definisce un’interfaccia di comunicazione per i processi all’interno dello stesso nodo o tra diversi, grazie ad un’entità logica che esegue un’istanza di calcolo isolata.
• Servizio di eventi: quando un evento viene pubblicato, tutti i clienti “abbonati” ricevono il messaggio.
• Interfaccia del servizio per l’appartenenza al cluster: fornisce la possibilità di conoscere la visione completa dell’informazione dinamica, riguardante l’appartenenza ad un cluster, che consiste in un insieme di nodi, ognuno col proprio identificatore unico.
• Servizi di checkpoint: specifica un’interfaccia per un meccanismo in grado di memorizzare incrementalmente e recuperare i dati dello stato dell’applicazione.
• Astrazione della gestione dei componenti hardware attraverso la HPI.
• Supporto per aggiornamento live del software, del firmware e del sistema operativo.
• Installazione e aggiornamento del servizio con minima interruzione.
• Avvio deterministico e affidabile del cluster, in cooperazione con il sistema operativo e l’hardware.
• Considerazioni di sicurezza.
• Gestione della distribuzione del carico di lavoro.
Per raggiungere l’obiettivo di avere una piattaforma carrier-grade vista come un prodotto stand-alone, c’è la necessità di inserire una funzionalità di gestione e configurazione. Le parti principali di questa funzionalità sono le seguenti:
• Gestione della configurazione dell’hardware.
• Funzioni per la gestione amministrativa dell’hardware, compresi controlli diagnostici e d’inventario dell’hardware.
• Sviluppo del software negli ambienti di esecuzione.
• Configurazione del software da eseguire su nodi specifici all’interno del cluster.
• Controllo di avvio e di chiusura per il sistema e per i singoli nodi del cluster.
• Bilanciamento del carico di lavoro sul cluster.
Attualmente lo standard SAForum ha completato la specifica delle interfacce offerte nel linguaggio di programmazione C. Poiché le applicazioni dei NEP, oltre a tale linguaggio, vengono sempre più scritte in Java in ambiente J2EE, gli sviluppi delle interfacce dello standard seguiranno questa direzione.