Un cluster IBM® WebSphere Application Server di grandi dimensioni
è composto di server HTTP e proxy di front end con un'utilità di bilanciamento del carico che invia le richieste ai diversi componenti
del cluster.
Limitazione: Per creare ed utilizzare un cluster di
application server, è necessario disporre di
IBM WebSphere Application Server Network
Deployment (ND), non associato a
IBM Rational Asset Manager.
È possibile scalare WebSphere Application Server sia verticalmente che
orizzontalmente. Utilizzare un server di database dedicato e un server di file. Il grado in cui
WebSphere Application Server può essere scalato e il numero di server
che è possibile utilizzare dipende dal tipo e dalla grandezza delle richieste server e dal numero di asset.
- IBM HTTP Server
- Il primo livello è il server HTTP, che gestisce le richieste dai client Web
e alleggerisce l'application server nel provvedere al contenuto statico. Fornisce un URL logico che racchiude applicazioni ausiliari,
ad esempio l'applicazione IBM Rational Asset Manager, l'applicazione Guida
di Rational Asset Manager e l'applicazione di sviluppo basato su asset di
Rational Asset Manager. Tenere presente che nelle configurazioni di grandi dimensioni,
viene distribuito un server di cache di fronte al server HTTP.
- Utilità di bilanciamento del carico
- L'utilità di bilanciamento del carico distribuisce il carico in più sistemi. Se si dispone di più server HTTP, è necessario utilizzare un'utilità di bilanciamento del carico.
Per le distribuzioni
di dimensioni moderate, utilizzare un'utilità di bilanciamento del carico basata su software, ad esempio
Edge Component. Per le distribuzioni più grandi, che supportano un numero elevato di utenti simultanei, utilizzare un'utilità di bilanciamento del carico
basata su hardware.
- Proxy di cache
- Un sistema proxy di cache di inoltro archivia i dati delle applicazioni per i client di una
cache e riduce il carico degli altri sistemi server. Se il server Rational Asset Manager
supporta un numero moderato di utenti simultanei, è necessario utilizzare un solo sistema proxy di inoltro. Se il server Rational Asset Manager
supporta un numero elevato di utenti simultanei, potrebbero essere necessari più sistemi proxy.
- Application Server
- Il file Rational Asset Manager EAR
è composto da due file WAR: il repository e il file dell'applicazione Web e il file dei servizi Web. Distribuire il file
Rational Asset Manager EAR
in ogni istanza WebSphere Application Server
di un cluster. Rational Asset Manager inoltre include la Guida e i file WAR di
IBM Rational Unified Process (RUP);
non è necessario distribuire questi file WAR. Se non è richiesta un'alta disponibilità per la Guida e le funzioni di supporto
RUP, distribuirle su una singola istanza
WebSphere Application Server
o su un contenitore WebSphere Application Server esterno.
- Rational Asset Managerapplicazione
- Il repository
Rational Asset Manager
è progettato per le ricerche e il richiamo dei dati, quindi l'archiviazione dei dati consente di effettuare
ricerche di dati, esplorazioni di risorse utente e download di asset in modo efficace. A questo fine, ogni istanza server Rational Asset Manager genera un indice locale degli asset e un
indice locale delle risorse utente.
Tali indici ottimizzano le prestazioni delle ricerche, riduce il carico del database e migliorano la scalabilità dell'ambiente cluster. Le prestazioni delle directory dell'indice locale possono risultare migliori di quelle di un indice condiviso tra più nodi.
- Server di database
- Gli elementi più importanti da considerare per la scelta di un hardware di
database sono il numero di dischi nella macchina e lo schema
RAID utilizzato dalla macchina. Un array RAID dovrebbe contenere almeno da 6 a 10
unità per ogni processore. Anche se la memoria è un elemento importante, non c'è una differenza significativa tra le configurazioni server
di database con
4GB e 8GB di memoria per 1000 utenti e 50.000 asset.
- I requisiti di spazio su disco dei database dipendono da diversi fattori:
il numero di asset, il numero di risorse utente per ciascun asset, il numero di spazi di team, il numero di ruoli, il numero di revisioni, il numero di tipi
di asset, il numero di utenti, la quantità di transazioni sul server (metriche utente) e la quantità di discussioni nei forum.
- Server di file
- Gli asset devono essere condivisi tra più istanze
WebSphere Application Server.
Utilizzare un sistema file di accesso simultaneo. Rational Asset Manager accede a questi file solo durante
il caricamento, i download, l'indicizzazione delle risorse utente e durante l'esecuzione di modifiche importanti al modello
Rational Asset Manager che richiedono un aggiornamento del manifest dell'asset.
Topologie di clustering
Il clustering consiste nel combinare un gruppo di macchine in un'entità
logica a cui è possibile fare riferimento come se fosse una sola macchina. Questa sezione descrive diverse configurazioni cluster e i vantaggi e gli svantaggi
principali di ciascuna di esse.
- Clustering orizzontale
- Il clustering orizzontale, a volte definito
scaling out, consiste nell'aggiungere macchine fisiche per aumentare le prestazioni o la capacità di un pool di cluster. Generalmente, la scalabilità orizzontale aumenta la disponibilità delle applicazioni nel cluster
in cambio di un numero più elevato di attività di gestione.
Il clustering orizzontale può aggiungere funzionalità
e una maggiore velocità effettiva alle applicazioni nel cluster; utilizzare questo tipo di
clustering nella maggior parte delle istanze.
- Clustering verticale
- Il
clustering verticale, a volte definito
scaling up, consiste nell'aggiungere istanze di
WebSphere Application Server alla stessa macchina. La scalabilità
verticale è utile se si desidera usufruire di risorse inutilizzate in server SMP di grandi dimensioni. È possibile utilizzare il clustering
verticale per creare più processi JVM che, insieme, possano utilizzare tutta la potenza di elaborazione disponibile.
- Clustering ibrido orizzontale e verticale
- Il clustering ibrido è una combinazione del clustering
verticale e orizzontale. In questa configurazione, diverse configurazioni
hardware sono membri dello stesso cluster. Le macchine di grandi dimensioni, con più capacità, possono contenere più istanze di
WebSphere Application Server;
le macchine di dimensioni inferiori possono essere incluse in un cluster orizzontale e contenere solo un'istanza di
WebSphere Application Server.
- Quando si utilizza
il clustering verticale, si consiglia di essere prudenti. L'unico modo per determinare la configurazione più appropriata
per il proprio ambiente e applicazione è ottimizzare una singola istanza di un application server per velocità effettiva e prestazioni, quindi
aggiungerla a un cluster ed aggiungere in modo incrementale ulteriori membri del cluster. Verificare le prestazioni e la velocità effettiva
dopo l'aggiunta di ogni membro al cluster. Quando si configurare una topologia di scalabilità verticale, monitorare sempre l'utilizzo della memoria con attenzione;
non superare la quantità di spazio utente indirizzabile o la quantità di memoria fisica sulla macchina.
Scalabilità
La scalabilità indica il livello di semplicità nell'espansione di un sito. Il numero di utenti, asset e community per
una determinata installazione di Rational Asset Manager
deve essere in grado di espandere il sito per supportare un carico in aumento. Il carico in aumento può provenire da diverse fonti,
ad esempio l'aggiunta di nuovi team o dipartimenti all'insieme di utenti Rational Asset Manager
i l'importazioni di grandi insiemi di asset storici in Rational Asset Manager.
La scalabilità
è una considerazione architettonica sulla quale si basa la progettazione dell'architettura.
Un miglioramento alla scalabilità aggiungendo hardware
al sistema, potrebbe influenzare negativamente le prestazioni e la velocità effettiva.
La scelta tra
scaling up (clustering verticale) e scaling down (clustering verticale) generalmente dipende dalle preferenze, il costo e la natura
dell'ambiente. Tuttavia i problemi di recupero dell'applicazione possono influire sulle preferenze personali.
- Lo scaling up implementa la scalabilità verticale in un piccolo numero di macchine con molti processori e
una grande quantità di memoria di spazio utente indirizzabile.
Questa situazione può avere uno SPOF (single points of failure) importante perché l'ambiente è composto
da poche macchine di grandi dimensioni.
- Lo scaling out
utilizza un numero più elevato di macchine più piccole. In questo scenario, è improbabile che l'arresto di un solo piccolo server
comporti la completa interruzione dell'applicazione. Tuttavia, lo scaling out comporta più attività di gestione.
Disponibilità
Definita anche tolleranza agli errori, la disponibilità è la capacità di un sistema
di fornire una continuità operativa in presenza di componenti e sistemi con errori.
Le decisioni architettoniche, ad esempio la scelta fra scalabilità orizzontale e verticale e l'uso di utilità di bilanciamento del carico
di backup (ovvero i dispatcher), possono influenzare la disponibilità dell'applicazione Rational Asset Manager.
Considerare la disponibilità per tutte le risorse condivise, le reti e i sistemi di archiviazione su disco che costituiscono l'ambiente
Rational Asset Manager.
In presenza di una progettazione con tolleranza degli errori, se un'applicazione o un server si arresta, gli altri membri del cluster
continueranno ad essere disponibili per i client.
Esistono due categorie di failover: failover server e failover sessione.
Quando si verifica il failover server, le sessioni presenti nel membro del cluster con errori, andranno perdute (ad esempio un utente sarà
costretto ad effettuare nuovamente l'accesso) ma i servizi continueranno ad essere disponibili ai client. Nei failover sessione, le sessioni esistenti
verranno recuperate dagli altri membri del cluster come se il membro del cluster non avesse subito alcuna interruzione
(anche se è possibile che l'ultima transazione non venga recuperata).
Rational Asset Manager supporta la configurazione di infrastrutture ridondanti con supporto del failover server.