Vai al contenuto

Pianificazione per la distribuzione

Quanti server di sessione è necessario distribuire? Quanti server MSS? Esistono altre considerazioni di cui tenere conto? In questa sezione viene illustrato come ottimizzare la distribuzione del server di sessione e del server MSS.

Ridimensionamento e alta disponibilità

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?

Ridimensionamento

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.

Alta disponibilità

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 più livelli in tutte le aree dei sistemi, la sua descrizione esula dall'ambito 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à.

Dimensionamento dei server di sessione

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.

Dimensionamento dei server MSS

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.

Utilizzo dei sistemi di bilanciamento del carico

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.
  • 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.

La sezione Progetto per una distribuzione ad alta disponibilità fornisce i valori consigliati per ciascuna di queste impostazioni.

Opzioni TLS

Per gestire i protocolli TSL 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.

TLS con il Single Sign-On X.509

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.

Terminal ID Manager

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.

Opzioni di distribuzione

È possibile distribuire i server di sessione in uno dei modi seguenti:

  1. Utilizzando il metodo tradizionale, basato sull'installazione di ciascun server di sessione su un server dedicato

  2. 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.

Informazioni sulle interruzioni dei servizi

Nota

Quando si valutano le opzioni di distribuzione, tenere presente che HACloud è costituito da più servizi: il server di sessione, MSS e i relativi componenti aggiuntivi, Terminal ID Manager e Metering (Analisi). Di default, MSS, Terminal ID Manager e Metering (Analisi) vengono eseguiti contemporaneamente in un unico processo ma possono essere configurati in modo da essere eseguiti in processi separati. Il server di sessione HACloud viene sempre eseguito nel proprio processo.

Quando il server di sessione viene arrestato, tutte le sessioni host su tale server vengono chiuse. Gli utenti che avevano eseguito il login a tale server devono eseguire nuovamente l'autenticazione al riavvio del server o al reindirizzamento a un nuovo server.

In questa tabella vengono descritti gli effetti sulle funzionalità per l'utente finale quando i servizi non sono disponibili o sono stati riavviati.

Azione Server inattivo Server riavviato
MSS
Login No
Creazione di nuove sessioni host No
Utilizzo di sessioni host esistenti
Riconnessione a sessioni host esistenti Sì (escluse le sessioni SSH)
Modifica di sessioni No Sì (è necessario eseguire nuovamente il login)
Registrazione/modifica di macro utente No
Terminal ID Manager
Connessione a sessione host che richiede un ID No
Connessione a sessione host che non richiede un ID
Server di analisi
Creazione di nuove sessioni host No*
Utilizzo di sessioni host esistenti

*Se la proprietà metering.host.required è impostata su false, è possibile creare nuove sessioni.

Se un server di sessione viene arrestato, tutte le sessioni di tutti gli utenti connessi tramite il sistema di bilanciamento del carico a tale server di sessione andranno perse. Ciascun utente dovrà eseguire il login a un altro server di sessione (tramite il sistema di bilanciamento del carico) e avviare nuove sessioni.