Con il crescere delle minacce che arrivano dalla Rete, spesso guidate da precise volontà criminali, firewall e gateway assumono un ruolo chiave nell’infrastruttura di quelle aziende che offrono servizi su Internet. Juniper Networks, uno dei principali produttori di apparati di rete, ha presentato la serie SRX 5000, un Service Gateway con un importante record di throughput: ben 120 GB/s. Per saperne di più abbiamo fatto qualche domanda a Umberto Pirovano, Systems Engineer Manager di Juniper Networks Italia.
Juniper è tra i principali protagonisti del mercato degli apparati di rete. Tra le ultime novità, avete presentato due nuovi Services Gateway: lo SRX 5600 e il fratello maggiore lo SRX 5800. Quali sono le principali novità di questi due apparati?
I Juniper Networks SRX 5000 sono i primi modello basati sulla Dynamic Services Architecture?, un’architettura modulare e altamente estensibile in grado di accrescere le prestazioni dei servizi di sicurezza e la capacità di throughput e connettività di rete.La Dynamic Services Architecture, anche se basata su un design di chassis, è completamente differente da un’architettura a chassis tradizionale. Invece di fornire semplicemente un backplane veloce, la Dynamic Services Architecture include anche la gestione e il piano di controllo necessari per incorporare le singole blade in una soluzione unitaria. Invece di impiegare blade e card differenziate, la Dynamic Services Architecture aggiunge ogni nuova scheda in un pool di risorse crescente e queste risorse possono quindi essere utilizzate (quando necessario) per processare in modo ottimale il traffico di rete e dei servizi richiesti.
Gli amministratori non devono più configurare le schede aggiuntive per attivare nuovi servizi. Aumentando la capacità computazionale del sistema si mantiene lo stato di sistema unico, quindi l’architettura consente un’espansione delle funzionalità di rete e sicurezza senza alcun costo amministrativo.Il parallelismo estremo del progetto SRX 5000 consente di raggiungere performance uniche mantenendo la semplicità di gestione necessaria al contenimento dei costi di gestione.
Visto che JunOS deriva da FreeBSD, qual è la vostra posizione riguardo l’open source? Ci sono alcuni componenti di JunOS già a codice aperto? C’è possibilità per il futuro di vedere allargarsi la base di codice rilasciato come open source?
La prima generazione di sistemi operativi per dispositivi di rete era costituita da un’architettura monolitica: questi sistemi operativi giravano in uno spazio di memoria flat, adottavano meccanismi di multitasking cooperativo per la gestione di packet switching, protocolli di routing e management. Ciascun processo continuava a occupare la CPU fino a che non la rilasciava volontariamente. Lo scopo era quello di tenerli leggeri e moderati nell’utilizzo delle risorse (CPU e memoria) all’epoca molto costosi. Il rovescio della medaglia era l’impossibilità di avere fault isolation e separazione delle risorse dedicati ai processi con conseguente scarsa scalabilità e una stabilità sempre più difficile da raggiunger con il crescere delle funzionalità richieste.A metà degli anni ’90 Juniper si è posta sul mercato come pioniere per una nuova architettura di dispositivi di routing basata sulla separazione completa tra il piano di forwarding e il piano di controllo: ASIC veloci, a performance garantite e robusti si occupano del packet forwarding mentre un sistema operativo modulare basato su standard e assolutamente affidabile si occupa di tutti i processi di controllo. Il primo sistema operativo di seconda generazione è stato il JunOS che utilizzava (e utilizza tutt’ora) FreeBSD come base per il kernel.
Ora si sta aprendo la strada per la terza generazione di sistemi operativi di rete nella quale tenendo fermi i capisaldi di modularità, separazione tra piano di controllo, piano di forwarding e piano dei servizi si punta alla continuità delle operations in modo che eventuali fallimenti nel codice di routing così come l’upgrade dei sistemi non impattino sullo stato di rete.
Il kernel software di Junos e l’infrastruttura sono stati pesantemente modificati per realizzare features avanzate e uniche quali la replica degli stati, il nonstop active routing e l’aggiornamento software in-service, tutte feature non esistenti nel sistema operativo donor (FreeBSD). Nonostante ciò i fondamenti di Junos possono ancora essere sincronizzati con il repository originale di FreeBSD per giovarsi delle novità, nuovi driver e nuovi sviluppi, consentendo agli ingegneri Juniper di concentrarsi sulle funzionalità specifiche di rete.
Un’interessante implicazione della modularità verticale è la possibilità di strutturare e documentare il codice per fornire interfacce per connettere codice di terze parti (API). La Partner Solution Development Platform fornisce API e tool di sviluppo a clienti e partner Juniper in tutto il mondo. PSDP consente a clienti e integratori di partecipare allo sviluppo del sistema operativo adattandolo perfettamente alle proprie necessità, in particolare per sviluppare applicazioni avanzate o confidenziali. Il grado di sviluppo può variare da cambiamenti minori ad un packet processing completamente customizzato.
Accanto alle API un’ampia scriptabilità consente l’automazione di tutti i processi di gestione e controllo dei sistemi.
Il Juniper Networks Software Developer’s Kit (SDK) rapresenta uno dei punti di eccellenza del codice di Junos e riflette l’innovazione che è intrinseca nella filosofia aziendale di Juniper.
Proprio come il codice open source FreeBSD fu il sistema operativo “donatore” del software Junos, con l’SDK di Juniper Networks, il software JunOS è ora una piattaforma aperta a tutti gli sviluppatori.
Nel recente passato Pradeep Sindhu, che di Juniper è fondatore attuale CTO, ha avuto modo di criticare Cisco, riguardo la loro politica di avere un sistema operativo per ogni linea di prodotto. Juniper, invece, propone lo stesso sistema a bordo di tutti i suoi prodotti. Sicuri che un unico sistema operativo sia la scelta migliore anche quando gli apparati hanno funzioni significativamente diverse?
Credo che la risposta alla domanda precedente racchiuda molti punti utili a chiarire gli intendimenti di Pradeep Sindhu: un sistema operativo completamente modulare consente un livello di scalabilità ineguagliabile, un’adattabilità a moduli hardware specializzati per i compiti più onerosi e adatti a garantire performance in qualunque situazione di esercizio. Una rigida disciplina di rilascio (una release la seconda settimana del secondo mese di ogni quarto) e beta testing (il rilascio di una release coincide con l’inizio del beta test della versione successiva con piena documentazione delle nuove features), un unico repository binario, sono tutte caratteristiche che garantiscono un’esperienza univoca su tutti i sistemi Junos di Juniper Networks a vantaggio di una maggiore stabilità, la semplificazione delle operazioni e la riduzione degli errori umani.
Probabilmente è troppo presto per chiedere, ma la domanda è d’obbligo: state già lavorando ai prossimi modelli?
La famiglia degli SRX 5000 è solo la prima di una nuova serie di device. A presto nuovi annunci che allargano la famiglia dei Service Gateway ad alte prestazioni di Juniper Networks.
