Page History

Descrizione generale

In questa sezione è descritta l'architettura tecnologica di riferimento per l'erogazione dei servizi applicativi di U-GOV.
Il sistema informativo U-GOV è composto da un framework applicativo comune ed una serie di moduli applicativi, specifici per le differenti aree e processi dell'Ateneo (si veda Architettura Logica).

A livello di layer tecnologici, l'infrastruttura applicativa è quella riportata nel seguente diagramma:

...

• DBMS: Oracle Database server 10.2.0.3 18.x Standard Edition (o superiore).
• Web Server, Servlet ed EJB Container: Oracle Container for Java (OC4J) contenuto all'interno di Oracle Application Server (OAS) 10.1.3.3 Standard Edition o Standard Edition One.Web Server: Oracle HTTP Server (OHS) contenuto all'interno di Oracle Application Server (OAS) 10.1.3.3 Standard Edition o Standard Edition One.Red Hat JBoss EAP 7.x (o superiore)
  
  

Componenti infrastrutturali

Alle Ai componenti di base sono necessarie necessari alcuni servizi esterni di supporto:

• Identity provider, LDAP server o Identity provider (Shibboleth, WSOpenID, ecc.) per la gestione dell'autenticazione.
• Load Balancer per il bilanciamento del carico utente su più Web Server.
  L'infrastruttura completa di U-GOV è riassunta nel seguente diagramma:

Image Removed

U-GOV: Schema infrastrutturale

Organizzazione delle componenti all'interno del container OC4J

All'interno della stessa installazione OAS, è possibile avere più istanze distinte di OC4J (JEE Container) in grado di ospitare installazioni distinte del prodotto: questo è utile per avere in ambienti separati le installazioni di diversi atenei, ambiente di test e di produzione, ecc.
All'interno di ogni istanza dell'OC4J, vengono distribuiti i moduli di U-GOV come mostrato dal seguente schema:

Image Removed
Layout delle componenti applicative all'interno del container OC4J

U-GOV: Schema complessivo

Scenari di installazione

Il disegno dell'ambiente di produzione dipende in larga parte dalla dimensione dell'Ateneo e quindi dal numero degli utilizzatori del servizio, dalla quantità dei moduli applicativi a disposizione dell'Ateneo e dal livello di servizio richiesto. Devono inoltre essere considerati gli aspetti di integrazione con l'infrastruttura tecnologica ed i servizi già presenti in Ateneo.
Tali vincoli possono generare differenti soluzioni tecnologiche che l'Ateneo che intende installare U-GOV presso la sua sede può adottare, differenti sia per la dimensione (numero e tipologia di server), sia per il layout infrastrutturale.
Si riportano, a solo scopo illustrativo, i due estremi di layout tecnologico possibili per l'esercizio dell'applicazione U-GOV.

Soluzione minimale

L'infrastruttura hw minimale per il funzionamento del sistema U-GOV si compone di:

• 1 Application Server:

...

• Java container: Oracle Container for Java (OC4J)
• Web Server: Oracle HTTP Server

• JBoss (versione 7.x)
• 1 Database Server: Oracle DB Server 18.x
• 1

...

• Idp Shibbolet o Server

...

• ldap
• La scalabilità dell'infrastruttura può avvenire esclusivamente mediante la sostituzione dei server con altri più potenti. Non c'è protezione dai guasti.

Soluzione scalabile

Per implementare una infrastruttura di produzione in grado si sostenere l'erogazione del servizio in termini di disponibilità e di scalabilità dello stesso, devono essere utilizzate tecniche di scalabilità orizzontale e tecniche per l'alta disponibilità (gestione del fail-over).
Per garantire la scalabilità in termini di capacità di calcolo dell'infrastruttura, il metodo che viene proposto è quello di adottare una server-farm in bilanciamento di carico, ovvero una batteria di server applicativi di medie dimensioni, sui quali viene distribuito il carico applicativo mediante un sistema di bilanciamento.

...

L'implementazione di tale soluzione richiede la presenza di una componente di bilanciamento di carico (Load Balancer), esterna ai sistemi applicativi. Questa deve essere in grado di distribuire connessioni TCP destinate ad un IP-address:port verso i server della farm ed essere in grado di determinare lo stato di carico dei server e dei servizi applicativi residenti. Deve anche poter garantire la
session affinity, ovvero riconoscere e trattare la sessione applicativa di un singolo utente, per tutta la sua durata, in modo da dirigerla sullo stesso application server fisico.

Relativamente alle implementazioni della componente DB server, si suggerisce una configurazione in alta disponibilità, composta da un gruppo (cluster) di 2 sistemi hardware, sui quali viene installato un software specializzato in grado di identificare lo stato di funzionamento dei sistemi e di migrare i servizi Oracle a seguito di guasti o malfunzionamenti di uno dei due. Le configurazioni dei cluster possono essere active-active, active-passive o RAC. Tali soluzioni di cluster sono disponibili per la maggior parte dei sistemi operativi.

Requisiti generali per l'infrastruttura tecnologica U-GOV

Database Server

• Schema Oracle (la dimensione dipende dai moduli U-GOV installati) su una istanza Oracle DataBase Server rel. 10.2.0.3 18.x con character set AL32UTF8 (tali schema, non avendo requisiti particolari, possono anche essere ospitati su una istanza Oracle preesistente).
• Sistema operativo del db-server: uno qualsiasi tra quelli certificati da Oracle.

Application Server

• Oracle JBoss Application Server rel. 10.1.3.5 Standard Edition, o Standard Edition One. Nello specifico il tipo di licenze OAS suggerita da CINECA a seconda delle caratteristiche dell'ambiente da installare sono:
  • Oracle Application Server 10.1.3.5 Standard Edition One, indicata per server con massimo due CPU socket. A causa di alcuni limiti di questa licenza, essa non è indicata nel caso di installazioni che vogliano sfruttare la componente Oracle Web Cache delle suite OAS come bilanciatore di carico.
  • Oracle Application Server 10.1.3.5 Standard Edition, indicata per server con massimo quattro CPU socket.
  (EAP 7.x)
• Il sistema operativo andrà scelto tra quelli certificati Oracle. Il CINECA ha scelto, per la propria Server Farm, il sistema operativo SuSE Linux SLES 10.RedHat.

LDAP Server

• Qualsiasi soluzione che supporti la versione 3 del protocollo LDAP (es: Open Ldap versione 2.3. 32 o superiore). Non richiede una installazione dedicata al servizio.

Sistema di bilanciamento di carico

• Come da descrizione precedente.

Caratteristiche dei sistemi Hardware

Come premesso, il dimensionamento dell'infrastruttura hardware dipende fortemente dalla installazione ipotizzata per l'Ateneo, dal numero degli utenti, dal tipo dei moduli installati e dalla numerosità dei dati e delle transazioni gestite. Come riferimento generale, si suggeriscono le seguenti configurazioni minime per le differenti componenti descritte.

Application Server:

• Server con processore dual-socket dual-core (Intel, AMD) multicore Intel o AMD di ultima generazione;
• Min. 8GB RAM (opzionali 16GB per una installazione multimodulo/multi OC4J);
• Disco interno (sistema operativo e OAS, applicazione): >=36GB.

Fare in ogni caso riferimento al proprio referente commerciale Oracle per i dettagli sulle licenze.

Database Server:

• Server con processore dual-socket dual-core (Intel, AMD) multicore Intel o AMD di ultima generazione;
• Min. 8GB RAM (opzionali 16GB), Min. 2 interfacce di rete;
• Disco interno (sistema operativo, software DB): >=36GB;
• Disco per i dati del DB: dipendente dalla installazione (sistemi disco interni o esterni).

Load-balancer:
Le implementazioni di tale componente possono essere realizzate mediante soluzioni con hardware dedicato (appliance), router, linux-box con LVS, o mediante altri prodotti software. Per la particolare criticità della componente, si suggerisce una soluzione in
alta disponibilità.Nota: LVS Linux Virtual Server: è una soluzione di bilanciamento di carico basata su un modulo del kernel Linux.http://www.linuxvirtualserver.org

LDAP Server:

• Server con processore (Intel, AMD) di ultima generazione;
• Min. 4GB RAM;
• Disco interno (sistema operativo, software LDAP): >=36GB.