Creare una architettura in grado di gestire la scalabilità orizzontale del framework As.Up
Assunti iniziali:
Il registro di sistema è centralizzato (server CDO).
Il server CDO è l'unico elemento critico del sistema
Nella fase iniziale, si ipotizza che tutti gli application server che costituiscono il cluster As.UP sono uguali e ognuno di essi implementa tutti i servizi.
Deve essere possibile l'hot deployment, cioè l'aggiunta e l'eliminazione di un nodo del cluster senza dover riavviare il sistema. L'unico nodo non eliminabile è il server CDO.
Note di implementazione:
Ogni sessione As.UP è identificata da un ContestID e da un oggetto Job
Un Job gira sempre e solo sulla istanza di As.UP su cui è stato creato. Non è prevista per ora la possibilità di spostare un Job da una istanza all'altra.
Un Job utilizza tendenzialmente servizi locali all'istanza As.UP su cui sta girando.
Non sono previsti meccanismi di business continuity. Se una istanza As.Up si blocca, si bloccano anche tutti i job attivi su quella istanza.
Servizi con implementazione remota:
SystemManager (il registro oggetti però è unico e gestito da CDO).
JobManager
ProgramManager
Logica di load balancing
Ogni istanza di As.UP ha un indice di carico, calcolato in funzione del carico di lavoro attivo su quella istanza. E' previsto un servizio che torna il valore del carico istantaneo.
In fase di avvio di una nuova sessione, il SystemManager assegna un ID univoco che verrà usato per identificare la sessione.
Ad ogni nuova sessione viene creato un job. La creazione del job viene demandata ad uno qualsiasi dei JobManager attivi e registrati sulla rete OSGI come servizi ad accesso remoto (sicuramente uno per ogni istanza di As.UP). La logica seguita dal JobManager per creare il Job è la seguente:
Il JobManager riceve una richiesta di creazione del Job
Ricevuta la richiesta, il JobManager determina l'indice di carico locale e controlla se nella rete ci sono altre macchine con indice di carico inferiore.
Se esiste una istanza As.UP meno carica, la richiesta di creazione del Job viene inviata al JobManager attivo su quella istanza.
Se l'istanza più scarica è quella locale, il Job Manager crea il Job.
Al Job creato dal JobManager viene assegnato un ID univoco che oltre a identificare il lavoro identifica anche l'istanza di As.UP su cui quel lavoro è stato creato. Ad esempio, i primi n caratteri del nome univoco del job potrebbero essere il codice univoco dell'istanza As.UP.
Analogo meccanismo vale per l'esecuzione di programmi. Ogni richiesta ad uno qualsiasi dei ProgramManager registrati, sarà poi cura del ProgramManager che riceve la prima richiesta capire se la richiesta deve essere eseguita da lui o girata ad un ProgramManager attestato su una istanza As.Up meno carica.
Una volta identificato il ProgramManager che dovrà soddisfare la richiesta e l'istanza di As.UP su cui è attestato, tutti i servizi utlizzati dal programma per la sua esecuzione saranno locali.
Creare una architettura in grado di gestire la scalabilità orizzontale del framework As.Up
Assunti iniziali:
Note di implementazione:
Servizi con implementazione remota:
Logica di load balancing