Carrier Grade Linux (CGL)

Tradizionalmente, le reti di telecomunicazioni sono state costruite su piattaforme proprietarie, incontrando varie richieste specifiche dal punto di vista di disponibilità, affidabilità, efficienza e tempo di risposta del servizio. Tali sistemi sono composti di hardware altamente specifico, sistema operativo, middleware e altre tecnologie e interfacce proprietarie. Approcci di questo tipo all’architettura del sistema hanno favorito una chiusura da parte di un unico fornitore, causando una limitazione di flessibilità e di “libertà” nella progettazione, e hanno prodotto piattaforme molto costose da estendere e mantenere. Oggi, i service provider hanno come oggetto di discussione l’abbassamento dei costi, mentre si stanno ancora conservando le caratteristiche delle piattaforme per fornire applicazioni di servizio mission-critical. L’obiettivo attuale è, quindi, la necessità di spostarsi dalle architetture specializzate proprietarie e spingersi verso approcci e procedure di costruzione commercial-of-the-shelf (COTS). Come risultato, i sistemi legati ad un proprietario non offrono a lungo andare un approccio produttivo, a causa del loro costo elevato nell’acquisto, nel mantenimento e nella scalabilità. Per questo l’industria si sta muovendo da sistemi proprietari a piattaforme open, basate su standard industriali comuni.

Figura 28: Dual Star

Carrier Grade Linux (CGL) è al centro del movimento verso architetture open, la cui proposta ha inizio con l’idea che i servizi di comunicazione saranno distribuiti, usando piattaforme open standard carrier-grade. Un kernel Linux con caratteristiche carrier- grade è un componente essenziale per la costruzione di tali piattaforme e architetture, proposto dal gruppo di lavoro CGL, che include oltre tre dozzine di rappresentanti tra venditori di piattaforme, fornitori di distribuzione Linux e di componenti di rete.

Nei prossimi paragrafi verranno descritte le funzionalità offerte dal sistema operativo Carrier Grade Linux, per ogni requisito preposto al raggiungimento da parte di questo standard.

Figura 30: Carrier Grade Linux

4.2.1 Availability

Il requisito di Availability (Disponibilità) contiene una collezione di richieste che indirizza la robustezza di un singolo nodo di calcolo, che, in caso di clustering, può evitare di diventare un singolo punto di fallimento. Ciò che un singolo nodo richiede può essere categorizzato con i seguenti punti:

• Ridondanza

• Monitoraggio

• Software robusto

Operazioni on-line

Le operazioni on-line danno la possibilità al sistema di continuare a fornire un servizio mentre il software oppure l’hardware viene sostituito o aggiornato: ad esempio, il ripristino di un file system ha bisogno del riavvio del sistema. Tuttavia, CGL richiede che sia possibile “smontare” forzatamente un file system, permettendo la riparazione e la reinstallazione senza il reboot, contribuendo significativamente ad una continua disponibilità del servizio.

Ridondanza

Un sistema altamente disponibile deve essere composto da componenti ridondanti e deve trarre profitto dall’adozione di hardware ridondante, in modo tale da garantire il funzionamento del sistema anche se un componente fallisce. Ridondanza nelle porte di rete e di fibre channel migliorano rispettivamente la disponibilità della rete e dei dischi. Invece, la ridondanza dei componenti di memoria non può essere possibile, ma vengono usati dei metodi di rilevazione e di correzione dell’errore per nascondere guasti nella singola cella di memoria; CGL richiede il supporto Error Correction Code (ECC).

Monitoraggio

Una rapida individuazione di guasti hardware o software richiedono un monitoraggio delle condizioni del sistema, necessario anche ad effettuare dei controlli predittivi per quei componenti che sono in procinto di raggiungere uno stato di fallimento. CGL propone un meccanismo di Non-Intrusive Monitoring of Processes e uno di Memory Overcommit Actions: il primo solleva comportamenti anomali da parte di un processo, come la morte di un processo, e inizializza un’azione, come la creazione di un nuovo processo; il secondo monitora l’uso della memoria del sistema e controlla l’attività del processo, nel caso in cui l’utilizzo della memoria supera una certa soglia.

La robustezza del software non implica soltanto elevati livelli di qualità del sistema operativo, del middleware e di applicazioni, ma include anche le funzionalità per il mantenimento e l’aggiornamento del software, senza ridurre l’efficienza del sistema. Inoltre, la possibilità di correzione “al volo” comporta una modifica del processo senza terminarlo; un sistema di controllo del ciclo di CPU abilita l’individuazione di un comportamento anomalo di un processo, attraverso il settaggio di soglie, e scopre problemi come loop infiniti. Per massimizzare il tempo di attività, è importante minimizzare il tempo in cui un sistema è in stato off-line: in questo contesto, il Fast Restart Linux Bypassing BIOS tiene conto del tempo impiegato a riavviare un sistema, servendosi di un metodo per raggirare il firmware del BIOS. Invece, il Boot Image Fallback Mechanism definisce un meccanismo che abilita un sistema a tornare indietro su una precedente immagine di boot, in caso di fallimento catastrofico.

4.2.2 Clustering

Il gruppo di lavoro CGL ha condotto uno studio sull’uso dei cluster, secondo il quale si è appreso che nessun modello singolo di clustering è capace di incontrare le necessità di tutte le applicazioni carrier. Così CGL ha adottato un approccio più generale, definendo i componenti funzionali di un High Availability Cluster (HAC), i cui requisiti si basano sulla scalabilità, sul consolidamento del server e sull’High Performance Computing (HPC).

Figura 31: Modello di clustering CGL

Un cluster CGL di alta disponibilità è caratterizzato da un insieme di due o più nodi di calcolo, tra i quali un’applicazione può migrare in dipendenza di un meccanismo di failover. I servizi carrier-grade devono mantenere un’attività di almeno “5-nines” e un servizio fallito deve essere riavviato in un lasso di tempo inferiore al secondo per sostenere una continuità nell’operazione. Se venisse impiegato un cluster condiviso o no, esso fornisce comunque i seguenti vantaggi:

• Evita che un nodo sia un unico punto di fallimento: in caso di errori hardware, il nodo guasto può essere rimpiazzato o riparato, senza incidere sul servizio in grado di funzionare.

• Permette che un aggiornamento software o del kernel possa essere completato su ogni nodo separatamente, senza incidere sulla disponibilità del servizio.

• Isola i nodi guasti dal cluster e fa in modo che il servizio possa continuare ad utilizzare i restanti nodi sani.

• Rende possibile un incremento della capacità, in seguito ad un aumento del carico/traffico.

I requisiti di clustering CGL sono strutturati intorno alle interfacce offerte da standard del livello middleware, attraverso delle API, come ad esempio il Service Availability Forum (SAF).

4.2.3 Serviceability

CGL garantisce l’efficienza del servizio attraverso una serie di caratteristiche utili e necessarie a mantenere in piedi un sistema. Alcuni tipi di sistemi di telecomunicazione, inclusi server di gestione e di segnalazione e gateway, che devono avere la capacità di essere gestiti e monitorati da remoto, hanno una gestione robusta del software per le installazioni e i vari aggiornamenti, e hanno meccanismi per catturare e analizzare informazioni sui fallimenti. I sistemi CGL supportano standard di gestione remota, quali Simple Network Management Protocol (SNMP), Common Information Model (CIM) e Web-Based Enterprise Management (WBEM). Gli standard di gestione locale include una IPMI e una Hardware Platform Interface (HPI) del SAF. Debugger, dumper del kernel e dell’applicazione, trigger di sorveglianza e strumenti per l’analisi di controllo sono utili per rilevare e isolare fallimenti in un sistema. Il monitoraggio diagnostico di controlli della temperatura, delle ventole, dei flussi di potenza, dei mezzi di memorizzazione, della rete, delle CPU e della memoria hanno bisogno di una rapida individuazione e di una diagnosi del guasto.

4.2.4 Performance

CGL ingloba quei requisiti chiave per un sistema operativo, abilitati a descrivere un grado elevato di performance e scalabilità. Le funzionalità utilizzate per questi scopi comprendono il supporto per il symmetric multiprocessing (SMP) e la simultaneous multithreading technology (SMT), fornendo una comunicazione efficiente e di bassa latenza.

4.2.5 Standard

Un obiettivo dell’iniziativa CGL per raggiungere alta affidabilità, disponibilità, efficienza (RAS) e portabilità dell’applicazione riguarda la volontà di inglobare degli standard industriali maturi e ben definiti, comuni e rilevanti per l’ambiente carrier- grade. L’importanza degli standard open sta nel fatto che essi sono liberamente accessibili da qualsiasi persona e organizzazione e, inoltre, la loro evoluzione è parte del contributo di un’ampia comunità di sviluppatori. Il gruppo del CGL è attivamente impegnato con organizzazioni standard riconosciute, come Linux Standard Base (LSB) e il Service Availability Forum (SAF). Tali organizzazioni stanno producendo standard e specifiche che si occupano di RAS e di portabilità dell’applicazione, con la necessità di supportare applicazioni di comunicazione altamente disponibili. Il CGL 4.0 suggerisce il bisogno, in conformità al Linux Standard Base (LSB) vers. 3.2, di assicurare una distribuzione che abbia il supporto per lo stesso livello di compatibilità dell’applicazione come viene richiesto dallo standard LSB.

Il Carrier Grade Linux può utilizzare delle interfacce di SA Forum per applicazioni su cluster e per la gestione della piattaforma. Inoltre, in continuità con le precedenti versioni, il CGL 4.0 aggiunge diversi requisiti conformi allo standard POSIX, basati su IEEE 1003.1-2001 e utili ad incrementare la portabilità delle applicazioni su ambienti Linux. Oltre a questi si aggiunge una varietà di standard per la rete, per la comunicazione e per i bisogni della piattaforma: Stream Control Transfer Protocol (SCTP), protocolli Internet (IPv4/IPv6), Mobile Internet Protocol (MIPv6), Simple Network Management Protocol (SNMP), Intelligent Platform Management Interface (IPMI), IEEE 801.Q (LAN virtuale), Diameter, Common Information Model (CIM), Web-Based Enterprise Management (WBEM), Advanced Configuration & Power Interface (ACPI) e PCI Express. Con la speranza che molti standard industriali open diventeranno maturi col tempo, il CGL Working Group li valuterà in considerazione di versioni future dei requisiti CGL. L’adozione di tutti questi standard porterà dei benefici per gli sviluppatori delle applicazioni e per i fornitori di soluzioni e farà crescere il livello di popolarità dell’ambiente Linux nell’industria delle comunicazioni.

4.2.6 Hardware

Per restare competitivi nell’industria delle telecomunicazioni, i componenti hardware, basati su standard, modulari e COTS, vengono impiegati insieme al software open, includendo sistemi operativi, middleware e applicazioni. Un obiettivo del CGL Working Group è promuovere la migrazione dell’industria di telecomunicazioni dalle piattaforme hardware proprietarie all’hardware Commercial Off The Shelf, in modo da assicurare che l’ambiente Linux fornisca un supporto adeguato a tali piattaforme COTS. La parte dei requisiti in CGL 4.0 riguardanti l’hardware identifica un insieme di piattaforme hardware largamente in uso, per le quali definisce, inoltre, il supporto necessario al sistema operativo, applicato al kernel Linux, alle interfacce del kernel e agli strumenti software. Le funzionalità descritte includono il supporto per blade server, per interfacce di gestione dell’hardware e per eventi di sostituzione “a caldo” di blade.

Al fine di affrontare la necessità di gestire sistemi carrier-grade attraverso meccanismi hardware out-of-band, sono stati anche descritti alcuni metodi di gestione, come quelli trovati nell’Intelligent Platform Management Interface (IPMI). Inoltre, i sistemi siffatti richiedono alta performance e interconnessioni di prestazioni elevate all’interno e tra i nodi del sistema: per questo sono stati inseriti il supporto PCI Express Device Hot Plug, il meccanismo iSCSI Initiator Support e iSCSI Target Discovery. Considerando la diversità delle piattaforme hardware utilizzate in un ambiente carrier-grade, queste specifiche non definiscono requisiti per ogni tipologia di piattaforma industriale, bensì per una generica, accompagnata da una sezione di linee guida di implementazione per architetture specifiche.

4.2.7 Security

Nello sviluppo di un modello di minaccia per un sistema Carrier Grade Linux è necessario considerare le principali differenze che caratterizzano un ambiente di telecomunicazioni da un ambiente di calcolo general-purpose.

• I sistemi CGL sono configurati attraverso interfacce utente customizzate.

• I sistemi CGL sono tipicamente configurati senza accesso alla shell.

• Gli amministratori sono fidati e competenti.

La minaccia più grande per l’ambiente di telecomunicazioni è, quindi, l’accesso non autorizzato a interfacce di gestione e di controllo da parte di terzi, che possono ottenere dei diritti, corrompendo il sistema operativo o una delle sue applicazioni. Una minaccia potenziale già grave può crescere nel momento in cui le applicazioni hanno bisogno di colpire diversi piani di sicurezza. Molti servizi di sicurezza possono essere gestiti da remoto dall’utente finale: ad esempio, gli ISP permettono ai clienti di creare nuove caselle di posta con pochi e semplici click su una pagina web. Funzioni come questa creano una serie di nuovi rischi, come un’eventuale deviazione non autorizzata di mail e chiamate telefoniche e uno sfruttamento di vulnerabilità nel software per saltare da un piano di sicurezza ad un altro.

La mitigazione di questi rischi richiederà che gli utenti di questi sistemi siano correttamente autenticati e autorizzati e che l’informazione, in viaggio tra i piani, passi attraverso interfacce, proteggendola da accessi non autorizzati.