Disponibilità elevata e bilanciamento del carico dei connettori e delle applicazioni di rete privata
Questo articolo illustra il funzionamento della distribuzione del traffico con la distribuzione del proxy di applicazione. Informazioni su come il traffico viene distribuito tra utenti e connettori, oltre a suggerimenti per ottimizzare le prestazioni del connettore. Informazioni sul flusso del traffico tra connettori e server app back-end, con raccomandazioni per il bilanciamento del carico tra più server back-end.
Distribuzione del traffico tra connettori
Connessione ors stabiliscono le connessioni in base ai principi per la disponibilità elevata. Non esiste alcuna garanzia che il traffico venga distribuito uniformemente tra i connettori e non esista alcuna affinità di sessione. Tuttavia, l'utilizzo varia e le richieste vengono inviate in modo casuale alle istanze del servizio proxy dell'applicazione. Di conseguenza, il traffico viene in genere distribuito quasi uniformemente tra i connettori. Il diagramma e i passaggi illustrano come vengono stabilite le connessioni tra utenti e connettori.
- Un utente in un dispositivo client tenta di accedere a un'applicazione locale pubblicata tramite il proxy dell'applicazione.
- La richiesta passa attraverso un'istanza di Azure Load Balancer per determinare quale istanza del servizio proxy dell'applicazione deve accettare la richiesta. Sono disponibili decine di istanze per accettare le richieste per tutto il traffico nell'area. Questo metodo consente di distribuire uniformemente il traffico tra le istanze del servizio.
- La richiesta viene inviata a bus di servizio.
- bus di servizio segnali a un connettore disponibile. Il connettore preleva quindi la richiesta da bus di servizio.
- Nel passaggio 2, le richieste passano a diverse istanze del servizio proxy di applicazione, quindi è più probabile che le connessioni vengano effettuate con connettori diversi. Di conseguenza, i connettori vengono usati quasi uniformemente all'interno del gruppo.
- Il connettore passa la richiesta al server back-end dell'applicazione. L'applicazione invia quindi la risposta al connettore.
- Il connettore completa la risposta aprendo una connessione in uscita all'istanza del servizio da cui proviene la richiesta. La connessione viene quindi chiusa immediatamente. Per impostazione predefinita, ogni connettore è limitato a 200 connessioni in uscita simultanee.
- La risposta viene quindi passata di nuovo al client dall'istanza del servizio.
- Le richieste successive dalla stessa connessione ripetono i passaggi.
Un'applicazione ha spesso molte risorse e apre più connessioni durante il caricamento. Ogni connessione esegue i passaggi da allocare a un'istanza del servizio. Se la connessione non è associata a un connettore, selezionare un nuovo connettore disponibile.
Procedure consigliate per la disponibilità elevata dei connettori
A causa del modo in cui il traffico viene distribuito tra i connettori per la disponibilità elevata, è essenziale avere sempre almeno due connettori in un gruppo di connettori. Tre connettori sono preferibili per fornire un buffer aggiuntivo tra i connettori. Per determinare il numero corretto di connettori necessari, seguire la documentazione sulla pianificazione della capacità.
Posizionare i connettori in connessioni in uscita diverse per evitare un singolo punto di errore. Se i connettori usano la stessa connessione in uscita, un problema di rete con la connessione influisce su tutti i connettori che lo usano.
Evitare di forzare il riavvio dei connettori quando si è connessi alle applicazioni di produzione. In questo modo, potrebbe influire negativamente sulla distribuzione del traffico tra connettori. Il riavvio dei connettori causa l'indisponibilità di più connettori e forza le connessioni al connettore disponibile rimanente. Il risultato è un uso non uniforme dei connettori inizialmente.
Evitare tutte le forme di ispezione inline sulle comunicazioni TLS (Transport Layer Security) in uscita tra connettori e Azure. Questo tipo di ispezione inline causa una riduzione del flusso di comunicazione.
Assicurarsi di mantenere gli aggiornamenti automatici in esecuzione per i connettori. Se il servizio Updater del connettore di rete privato è in esecuzione, i connettori vengono aggiornati automaticamente e ricevono l'aggiornamento più recente. Se non viene visualizzato il servizio di aggiornamento del connettore nel server, è necessario reinstallare il connettore per ottenere gli aggiornamenti.
Flusso del traffico tra connettori e server applicazioni back-end
Un'altra area chiave in cui la disponibilità elevata è un fattore importante è la connessione tra i connettori e i server back-end. Quando un'applicazione viene pubblicata tramite il proxy dell'applicazione Microsoft Entra, il traffico dagli utenti alle applicazioni passa attraverso tre hop:
- L'utente si connette all'endpoint pubblico del servizio proxy dell'applicazione Microsoft Entra in Azure. La connessione viene stabilita tra l'indirizzo IP client di origine (pubblico) del client e l'indirizzo IP dell'endpoint proxy dell'applicazione.
- Il connettore di rete privata esegue il pull della richiesta HTTP del client dal servizio proxy dell'applicazione.
- Il connettore di rete privata si connette all'applicazione di destinazione. Il connettore usa il proprio indirizzo IP per stabilire la connessione.
Considerazioni sul campo intestazione X-Forwarded-For
In alcune situazioni ,ad esempio il controllo, il bilanciamento del carico e così via, la condivisione dell'indirizzo IP di origine del client esterno con l'ambiente locale è un requisito. Per soddisfare i requisiti, il connettore di rete privata Microsoft Entra aggiunge il campo di intestazione X-Forwarded-For con l'indirizzo IP client di origine (pubblico) alla richiesta HTTP. Il dispositivo di rete appropriato (servizio di bilanciamento del carico, firewall) o il server Web o l'applicazione back-end può quindi leggere e usare le informazioni.
Procedure consigliate per il bilanciamento del carico tra più server applicazioni
Il bilanciamento del carico è importante quando il gruppo di connettori assegnato all'applicazione proxy dell'applicazione ha due o più connettori. Il bilanciamento del carico è importante anche quando si esegue l'applicazione Web back-end in più server.
Scenario 1: l'applicazione back-end non richiede la persistenza della sessione
Lo scenario più semplice è quello in cui l'applicazione Web back-end non richiede la persistenza della sessione (persistenza della sessione). Un'istanza dell'applicazione back-end gestisce le richieste utente nella server farm. È possibile usare un servizio di bilanciamento del carico di livello 4 e configurarlo senza affinità. Alcune opzioni includono bilanciamento del carico di rete Microsoft e Azure Load Balancer o un servizio di bilanciamento del carico di un altro fornitore. In alternativa, configurare una strategia dns (Domain Name System) round robin.
Scenario 2: l'applicazione back-end richiede la persistenza della sessione
In questo scenario, l'applicazione Web back-end richiede la persistenza della sessione (persistenza della sessione) durante la sessione autenticata. L'istanza dell'applicazione back-end gestisce le richieste utente. Le richieste dell'oggetto vengono eseguite nello stesso server della server farm. Questo scenario può essere più complesso perché il client stabilisce in genere più connessioni al servizio proxy dell'applicazione. Le richieste su connessioni diverse potrebbero arrivare a connettori e server diversi nella farm. Poiché ogni connettore usa il proprio indirizzo IP per questa comunicazione, il servizio di bilanciamento del carico non può garantire la persistenza della sessione in base all'indirizzo IP dei connettori. L'affinità IP di origine non può essere usata neanche. Ecco alcune opzioni per lo scenario 2:
Opzione 1: basare la persistenza della sessione su un cookie di sessione impostato dal servizio di bilanciamento del carico. Questa opzione è consigliata perché consente di distribuire il carico in modo più uniforme tra i server back-end. Richiede un servizio di bilanciamento del carico di livello 7 con questa funzionalità e in grado di gestire il traffico HTTP e terminare la connessione TLS. È possibile usare app Azure gateway (affinità di sessione) o un servizio di bilanciamento del carico di un altro fornitore.
Opzione 2: basare la persistenza della sessione nel campo intestazione X-Forwarded-For. Questa opzione richiede un servizio di bilanciamento del carico di livello 7 con questa funzionalità e in grado di gestire il traffico HTTP e terminare la connessione TLS.
Opzione 3: Configurare l'applicazione back-end per non richiedere la persistenza della sessione.
Per comprendere i requisiti di bilanciamento del carico dell'applicazione back-end, vedere la documentazione del fornitore di software.