2.1 Topologia
Il numero delle istanze di ogni sottosistema principale e dei modi in cui possono essere collegate è potenzialmente elevato. Non tutti i possibili layout sono supportati. È importante comprendere non solo le diverse possibilità, ma anche il motivo per cui alcune configurazioni sono da preferire rispetto ad altre.
2.1.1 Configurazione minima
La configurazione logica più semplice dell'applicazione utente è rappresentata da un'installazione "uno di tutto", costituita da un albero per l'Identity Vault, un'istanza del motore e dei driver di Identity Manager e un'istanza di JBoss su cui viene eseguita una singola istanza dell'applicazione utente. In termini di implementazione fisica, in teoria è possibile eseguire tutto ciò su un unico computer, ma in pratica non è consigliabile per vari motivi, principalmente di sicurezza, gestibilità e prestazioni. Nel decidere il numero di computer necessari per un'installazione reale, è necessario prendere in considerazione come minimo i componenti seguenti:
- Server Novell Audit: è il componente in cui vengono catturate le informazioni relative agli eventi (ed eventualmente molti altri tipi di informazioni) derivanti dall'ambiente dell'applicazione utente in fase di runtime. Può inoltre svolgere una doppia funzione come archivio permanente per altre applicazioni utilizzate nella società. Per vari motivi, è probabile che non si collocheranno altri componenti importanti del sistema di Identity Manager (ad esempio, JBoss o l'Identity Vault) nello stesso computer del server di revisione.
- Identity Vault: si tratta di un componente ad alto traffico per il quale sono necessarie ottime prestazioni e scalabilità. Con tutta probabilità, l'Identity Vault verrà installato in un computer dedicato. In altri termini, probabilmente non si desidererà che un altro sistema ad alto traffico, ad esempio JBoss con una distribuzione dell'applicazione utente, venga eseguito insieme all'Identity Vault sullo stesso computer.
- Database: se questa istanza di MySQL (o di un altro database supportato) è anche il database di Novell Audit, verrà probabilmente collocata in un computer dedicato. Tenere presente che questo componente viene utilizzato dall'applicazione utente per svolgere le funzioni seguenti:
- Come archivio permanente per i dati di configurazione del portale
- Come archivio permanente per le informazioni di stato relative ai workflow in corso (se è installato il modulo di provisioning)
- Facoltativamente, come archivio di registrazione per Novell Audit.
- JBoss: per motivi di prestazioni e capacità, questo componente verrà probabilmente eseguito su un computer dedicato.
Sulla base a queste considerazioni, è consigliabile la configurazione minima seguente su tre computer:
2.1.2 Configurazione ad alta disponibilità
La gestione in cluster per consentire un'elevata disponibilità/capacità verrà trattata dettagliatamente in una sezione successiva di questo capitolo. Per il momento, ecco alcune informazioni:
- Identity Manager consente un'alta disponibilità dell'Identity Vault, del motore e dei driver attraverso meccanismi di installazione multinodo e di memorizzazione condivisa descritti nel capitolo relativo all'alta disponibilità della Guida all'amministrazione di Identity Manager. Per informazioni complete sulla configurazione di tale tipo di sistema su SuSE Linux, vedere l'articolo disponibile all'indirizzo:
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10093317.htm (in lingua inglese)
- L'alta disponibilità dell'applicazione utente è resa possibile attraverso la gestione in cluster di JBoss. È possibile configurare un cluster JBoss in modo tale che su ogni nodo venga eseguita un'istanza dell'applicazione utente. Le istanze saranno tutte coeguali (peer). Non avviene, tuttavia, alcuna replica delle sessioni attraverso le istanze. Ogni istanza è responsabile della propria unità di lavoro e non concluderà una sessione avviata su un nodo fratello.
- Il failover automatico non è supportato (per i motivi appena illustrati), ma è possibile la ripresa di un workflow interrotto dopo la perdita di un nodo del cluster, se viene attivato un nuovo nodo con lo stesso ID del motore di workflow di quello disattivato. In questo caso, la ripresa del workflow interrotto avviene automaticamente, non appena viene avviato il nuovo motore di workflow.
Per una trattazione più dettagliata di questi argomenti, vedere Sezione 2.4, Gestione in cluster.
2.1.3 Vincoli di progettazione
In generale, i due vincoli architetturali più importanti da tenere presente sono i seguenti:
- Nessuna istanza dell'applicazione utente può essere utilizzata (ricerca/interrogazione, aggiunta di utenti e così via) per più di un container utenti. Inoltre, una volta associato un container utenti all'applicazione, tale associazione viene considerata permanente.
- Nessun driver dell'applicazione utente può essere associato a più di un'applicazione utente, tranne nel caso di applicazioni utente installate su nodi fratelli dello stesso cluster JBoss. In altre parole, non è supportata la mappatura uno-a-molti dei driver alle applicazioni utente.
Il primo vincolo comporta un alto grado di incapsulamento nella progettazione dell'applicazione utente.
Si supponga di avere la struttura organizzativa seguente:
Durante l'installazione dell'applicazione utente, viene chiesto di specificare il container utente di primo livello che l'installazione deve essere individuare nell'Identity Vault. In questo caso, si potrà specificare ou=Marketing,o=ACME o in alternativa ou=Finance,o=ACME. Non è possibile specificare entrambi. Tutte le ricerche e le interrogazioni relative all'applicazione utente (e i login dell'amministratore) verranno eseguite nell'ambito del container specificato.
NOTA:in teoria, si potrebbe specificare un ambito o=ACME per comprendere Marketing e Finance, ma in un'organizzazione di grandi dimensioni con molti container ou (anziché due soli relativi a Marketing e Finance), non sarebbe probabilmente una soluzione pratica.
È ovviamente possibile creare due installazioni indipendenti dell'applicazione utente (che non condividono alcuna risorsa), una per Marketing e l'altra per Finance. Ogni installazione dovrà avere il suo database e il suo driver dell'applicazione utente appropriatamente configurato e ogni applicazione utente dovrà essere amministrata separatamente, eventualmente con temi univoci.
Se è effettivamente necessario collocare Marketing e Finance nello stesso ambito per un'unica installazione dell'applicazione utente, sono possibili due strategie. Una consiste nell'inserire un nuovo oggetto container (ad esempio ou=MarketingAndFinance) nella gerarchia, al di sopra dei due nodi affini, e quindi puntare al nuovo container come radice dell'ambito. L'altra strategia consiste nel creare una replica filtrata (un tipo speciale di albero eDirectory) che combina le parti necessarie dell'albero ACME originale e quindi puntare l'applicazione utente al container radice della replica. Per ulteriori informazioni sulle repliche filtrate, consultare la Novell eDirectory Administration Guide (Guida all'amministrazione di Novell eDirectory).
In caso di domande su un particolare layout di sistema, contattare il rappresentante Novell per assistenza o consulenza.