Quanti server di sessione è necessario distribuire? Quanti server MSS? Quale metodo di autenticazione si sta utilizzando? Esistono altre considerazioni di cui tenere conto? In questa sezione viene illustrato come ottimizzare la distribuzione del server di sessione e del server MSS.
In questa sezione:
Prima di iniziare la distribuzione, è necessario definire il metodo di autenticazione che si desidera utilizzare. L'autenticazione convalida l'identità dell'utente in base ad alcune credenziali, ad esempio una combinazione nome utente/password o un certificato client. L'autorizzazione viene quindi utilizzata per determinare a quali sessioni può accedere ciascun utente.
L'autenticazione e l'autorizzazione sono fornite da MSS in una distribuzione HACloud. Vedere Autenticazione e autorizzazione.
Determinare il numero server di sessione e di server MSS necessari per soddisfare le proprie esigenze è la prima attività da eseguire per pianificare la distribuzione. Indipendentemente dalle esigenze, Host Access for the Cloud può essere distribuito per fornire capacità e alta disponibilità.
Sebbene ogni soluzione dipenda da esigenze specifiche, è possibile consultare Progetto per una distribuzione ad alta disponibilità per avere indicazioni per una distribuzione scalabile e ad elevata disponibilità.
Le domande principali a cui è necessario rispondere sono:
Qual è il numero massimo di sessioni host che verranno utilizzate simultaneamente?
Quanti utenti utilizzeranno il sistema?
Quale livello di disponibilità del sistema è necessario per far fronte a un eventuale errore nelle diverse aree che lo compongono?
Il ridimensionamento consente a un sistema di gestire carichi di lavoro di varie dimensioni. Per aumentare la capacità, su un sistema può essere utilizzato lo scaling up (ridimensionamento verticale), mediante l'utilizzo di un server più potente, o lo scaling out (ridimensionamento orizzontale) mediante l'aggiunta di più server o nodi.
Ognuna di queste tecniche comporta dei compromessi di cui tener conto:
Lo scaling up è più semplice perché sono presenti meno server, ma aumenta il rischio di un errore di notevole entità nel caso in cui un server non risponda.
Lo scaling out implica l'utilizzo di più server ma, poiché i rischi vengono ripartiti su molti server, la mancata disponibilità di uno di essi avrà effetto su un numero inferiore di utenti.
Per aumentare la capacità, si consiglia pertanto lo scaling out mediante l'aggiunta di più server o nodi, in ragione della maggiore resilienza.
L'alta disponibilità (High availability, HA) è la capacità del sistema di continuare a fornire i servizi quando si verifica un errore in un punto qualsiasi dello stesso. L'alta disponibilità viene ottenuta mediante l'aggiunta della ridondanza ai principali componenti del sistema.
NOTA:In questa guida viene illustrato come garantire l'alta disponibilità dei principali servizi di Host Access for the Cloud. Tuttavia, poiché l'alta disponibilità si basa sulla ridondanza implementata a molti livelli in tutte le aree dei sistemi, la sua descrizione esula dallo scopo di questo documento.
L'alta disponibilità in Host Access for the Cloud viene ottenuta mediante:
La distribuzione di un numero di server di sessione e di server MSS sufficiente per fornire la capacità necessaria, implementando inoltre capacità aggiuntiva (libera) per gli errori
L'implementazione della corretta quantità di capacità aggiuntiva affinché, nel caso di restituzione di errore da parte di un server e di failover del carico di lavoro sui server rimanenti, il funzionamento di questi ultimi non venga compromesso dall'ulteriore carico
L'utilizzo di sistemi di bilanciamento del carico per distribuire il carico di lavoro e indirizzare gli utenti ad altri server in caso di errore
Replica dei dati tra i server MSS che viene condotta dalla gestione in cluster MSS
Per una descrizione di come soddisfare questi requisiti, vedere Progetto per una distribuzione ad alta disponibilità.
Il numero di server di sessione necessari è determinato dal numero di sessioni host simultanee che si intende eseguire. Le sessioni host generano un maggior carico sul server di sessione rispetto agli utenti, pertanto in questa sezione si farà riferimento a scenari relativi al numero di sessioni host richieste, anziché al numero di utenti.
|
Numero di sessioni simultanee dell'host |
Numero di server di sessione richiesti |
|---|---|
|
Fino a 3.000 |
2 server di sessione |
|
Oltre 3.000 |
(Numero di sessioni host richieste)/2.000 + 1 (un minimo di tre) |
Un server a sessione singola supporta 2000 sessioni host simultanee.
Un server di sessione include capacità aggiuntiva integrata per gestire 1.000 sessioni host aggiuntive in caso di failover.
Per l'alta disponibilità è necessario un minimo di due server di sessione.
Il numero di server MSS richiesto dipende dal numero di utenti simultanei.
|
Numero di utenti simultanei |
Numero di server MSS richiesti |
|---|---|
|
Fino a 30.000 |
3 server MSS |
|
Oltre 30.000 |
(Numero di utenti necessari)/10.000 +1 (deve essere un numero dispari) |
Un solo server MSS supporta 10.000 utenti simultanei.
Un server MSS dispone di una capacità aggiuntiva integrata per ospitare ulteriori 5.000 utenti, in caso di failover.
Per l'alta disponibilità sono necessari almeno 3 server MSS.
Per l'alta disponibilità è richiesto un numero dispari di server MSS a causa della necessità di un quorum del database.
È possibile distribuire i server di sessione in uno dei modi seguenti:
Utilizzando il metodo tradizionale, basato sull'installazione di ciascun server di sessione su un server dedicato
Utilizzando Docker per eseguire ciascun server di sessione in un container. Docker offre una serie di vantaggi, inclusa maggiore flessibilità per il numero di server di sessione che è possibile eseguire su un singolo server. Per ulteriori informazioni, vedere Utilizzo di Docker.
Sarà necessario implementare sistemi di bilanciamento del carico sia per i server di sessione che per i server MSS. Sono disponibili delle impostazioni comuni che sarà utile conoscere:
Algoritmo di bilanciamento del carico - Questo algoritmo determina a quale server inviare il nuovo traffico. Si consiglia di utilizzare l'impostazione "Least Connections" (Connessioni minime) o un'impostazione analoga. Verificare che questa impostazione consenta di distribuire correttamente il carico è essenziale per la stabilità complessiva del sistema. Se il sistema di bilanciamento del carico non è configurato correttamente o il suo funzionamento non è efficace, si corre il rischio di sovraccaricare i singoli server disponibili.
Persistenza della sessione (affinità/sessioni permanenti) - È la possibilità di inviare lo stesso utente allo stesso server in seguito a più richieste. Il server di sessione e MSS sono applicazioni stateful, che richiedono l'abilitazione delle sessioni permanenti nei propri sistemi di bilanciamento del carico. Questo argomento verrà affrontato di seguito.
Endpoint per la verifica dello stato - Si tratta dell'URL nel servizio di destinazione che viene utilizzato per determinare se l'istanza è integra e deve rimanere in servizio. Ciascun tipo di server fornisce il proprio URL di verifica dello stato.
Nella sezione Progetto per una distribuzione ad alta disponibilità sono riportati i valori delle impostazioni consigliate per ciascun sistema di bilanciamento del carico.
Per gestire i protocolli TSL/SSL in un sistema di bilanciamento del carico, sono disponibili tre opzioni tipiche. L'opzione prescelta varia in base alle esigenze.
Con le prime due opzioni è necessario installare il proprio certificato nel sistema di bilanciamento del carico. Con la terza opzione, ossia il metodo pass-through TLS, per il sistema di bilanciamento del carico non è richiesto alcun certificato. Il progetto per l'implementazione della disponibilità elevata utilizza il bridging TLS per garantire protezione TLS in tutte le fasi, assicurando al contempo la persistenza basata sui cookie. Le opzioni disponibili includono:
Interruzione/offloading TLS - Questa opzione termina la connessione HTTPS sul sistema di bilanciamento del carico e ristabilisce una nuova connessione HTTP tra il sistema di bilanciamento del carico e il servizio.
Bridging TLS (nuova cifratura) - Questa opzione termina la connessione HTTPS sul sistema di bilanciamento del carico e ristabilisce una nuova connessione HTTPS tra il sistema di bilanciamento del carico e il servizio. In questo modo viene assicurata protezione TLS dall'inizio alla fine, consentendo contemporaneamente al sistema di bilanciamento del carico di utilizzare un cookie per assicurare la persistenza della sessione.
Pass-through TLS (obbligatorio per X.509) - Il sistema di bilanciamento del carico agisce da proxy per la connessione TLS senza decifrarla. Lo svantaggio di questa opzione consiste nel fatto che, poiché non è possibile utilizzare cookie, la persistenza deve essere garantita basandosi sull'indirizzo IP di origine o in modo analogo.
Quando si utilizza l'autenticazione X.509, i sistemi di bilanciamento del carico di Host Access for the Cloud e di MSS richiedono il pass-through TLS, in quanto i certificati client devono essere inviati ai server nel sistema backend. Poiché il pass-through TLS è obbligatorio, per la persistenza della sessione sarà necessario utilizzare un metodo non basato su cookie, come l'indirizzo IP di origine, sia per il sistema di bilanciamento del carico del server MSS che per quello del server di sessione. Questo è necessario perché con il metodo pass-through di TLS, il sistema di bilanciamento del carico non può decifrare la connessione per impostare o persino visualizzare un cookie.
Su ciascun server MSS in un cluster viene eseguito un servizio di conteggio. Per l'alta disponibilità del servizio di conteggio è necessario disporre di almeno tre server MSS. Ciò garantisce il funzionamento dei client di emulazione anche se un server non è disponibile. Vedere Configurazione del conteggio.
Attualmente, Terminal ID Manager non supporta l'alta disponibilità. È possibile configurare un server passivo, tuttavia lo stato degli ID non verrà replicato dal server attivo. Se il server attivo non è disponibile, sarà comunque possibile accedere al server passivo ma gli ID non manterranno il loro stato attuale. Vedere Configurazione di Terminal ID Manager.