Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risoluzione dei problemi relativi al Network Load Balancer

Le informazioni seguenti possono essere utili per risolvere i problemi relativi al Network Load Balancer.

Un target registrato non è in servizio

Se un oggetto richiede più tempo del previsto per inserire lo InService stato, è possibile che i controlli dello stato non siano stati superati. Il target non è in servizio finché non passa un controllo dello stato. Per ulteriori informazioni, consulta Controlli di integrità per i gruppi target di Network Load Balancer.

Verificare che l'istanza non superi i controlli dello stato e quindi verificare le seguenti:

Le richieste vengono instradate ai target.

Verifica quanto segue:

I target ricevono più richieste di controllo dello stato del previsto

I controlli dell'integrità per un Network Load Balancer vengono distribuiti e utilizzano un meccanismo di consenso per determinare lo stato di integrità della destinazione. Pertanto, i target ricevono più del numero di controlli dello stato configurato attraverso l’impostazione HealthCheckIntervalSeconds.

I target ricevono meno richieste di controllo dello stato del previsto

Controlla se net.ipv4.tcp_tw_recycle è abilitato. Questa impostazione è nota per causare problemi con i sistemi di bilanciamento del carico. L'impostazione net.ipv4.tcp_tw_reuse è considerata un'alternativa più sicura.

I target danneggiati ricevono richieste dal sistema di bilanciamento del carico

Ciò si verifica quando tutte le destinazioni registrate non sono integre. Se è presente almeno una destinazione registrata integra, il Network Load Balancer instrada le richieste solo verso tale destinazione.

Quando tutte le destinazioni sono non integre, il Network Load Balancer instrada le richieste verso tutte le destinazioni registrate, con una modalità denominata fail-open. Il Network Load Balancer esegue questa operazione invece di rimuovere tutti gli indirizzi IP dal DNS quando tutte le destinazioni non sono integre e le rispettive zone di disponibilità non dispongono di destinazioni integre a cui inviare le richieste.

Il target non riesce a controllare l'integrità HTTP o HTTPS a causa della mancata corrispondenza dell'intestazione dell’host

L'intestazione dell’host HTTP nella richiesta di controllo dello stato contiene l'indirizzo IP del nodo del sistema di bilanciamento del carico e la porta del listener anziché l'indirizzo IP della destinazione e la porta di controllo dello stato. Se si esegue il mapping delle richieste in ingresso per l’intestazione dell’host, è necessario assicurarsi che i controlli di integrità corrispondano a qualsiasi intestazione dell’host HTTP. Un'altra opzione consiste nell'aggiungere un servizio HTTP separato su una porta diversa e configurare il gruppo di destinazione in modo che utilizzi tale porta per i controlli di integrità. In alternativa, prendere in considerazione l'utilizzo dei controlli di integrità TCP.

Impossibile associare un gruppo di sicurezza a un sistema di bilanciamento del carico

Se il Network Load Balancer è stato creato senza gruppi di sicurezza, non è in grado di supportarli dopo la creazione. Puoi associare un gruppo di sicurezza a un sistema di bilanciamento del carico soltanto durante la creazione. In alternativa, puoi associarlo a un sistema di bilanciamento del carico esistente che è stato originariamente creato con gruppi di sicurezza.

Impossibile rimuovere tutti i gruppi di sicurezza

Se il Network Load Balancer è stato creato con gruppi di sicurezza, deve essere sempre associato almeno un gruppo di sicurezza. Non è possibile rimuovere tutti i gruppi di sicurezza dal sistema di bilanciamento del carico contemporaneamente.

Aumento della metrica TCP_ELB_ Reset_Count

Per ogni richiesta TCP eseguita da un client tramite un Network Load Balancer, viene monitorato lo stato della connessione. Se non vengono inviati dati tramite la connessione dal client o dalla destinazione per un periodo superiore al tempo di inattività, la connessione viene chiusa. Se un client o un target invia i dati dopo la scadenza del tempo di inattività, riceve un pacchetto RST TCP che indica che la connessione non è più valida. Inoltre, se una destinazione diventa non integra, il sistema di bilanciamento del carico invia un RST TCP per i pacchetti ricevuti sulle connessioni client associate alla destinazione, a meno che la destinazione non integra non provochi il fail-open da parte del sistema di bilanciamento del carico.

Se noti un picco nel parametro TCP_ELB_Reset_Count poco prima o subito dopo l'incremento del parametro UnhealthyHostCount, è probabile che i pacchetti RST TCP siano stati inviati perché la destinazione presentava degli errori ma non era stata contrassegnata come non integra. Se noti aumenti persistenti nel parametro TCP_ELB_Reset_Count ma le destinazioni vengano contrassegnate ancora come integre, puoi controllare i log di flusso VPC per i client che inviano dati sui flussi scaduti.

Connessioni scadute per le richieste provenienti da un target al sistema di bilanciamento del carico

Verifica se la conservazione dell'IP client è abilitata sul gruppo di destinazione. Il loopback NAT, noto anche come hairpinning, non è supportato quando è abilitata la conservazione dell'IP client.

Se un'istanza è un client di un load balancer con cui è registrata e ha la conservazione dell'IP del client abilitata, la connessione ha esito positivo solo se la richiesta viene indirizzata a un'istanza diversa. Se la richiesta viene indirizzata alla stessa istanza da cui è stata inviata, la connessione scade perché gli indirizzi IP di origine e di destinazione sono gli stessi. Nota che questo vale per i pod Amazon EKS in esecuzione nella stessa istanza del nodo di lavoro EC2, anche se hanno indirizzi IP diversi.

Se un'istanza deve inviare le richieste a un sistema di bilanciamento del carico registrato, procedere in uno dei seguenti modi:

Diminuzione delle prestazioni durante lo spostamento delle destinazioni verso un Network Load Balancer

Sia i Classic Load Balancer che gli Application Load Balancer utilizzano il multiplexing delle connessioni, al contrario dei Network Load Balancer. Pertanto, le destinazioni possono ricevere più connessioni TCP dietro un Network Load Balancer. Assicurati che i target siano preparati a gestire il volume di richieste di connessione che potrebbero ricevere.

Errori di allocazione delle porte per i flussi di backend

Con PrivateLink traffico o quando la conservazione dell'IP del client è disabilitata, un Network Load Balancer supporta 55.000 connessioni simultanee o circa 55.000 connessioni al minuto verso ogni destinazione univoca (indirizzo IP e porta). Se si superano questi limiti, aumenta la possibilità di errori di allocazione delle porte. È possibile tenere traccia degli errori di allocazione delle porte utilizzando la PortAllocationErrorCount metrica. Puoi tenere traccia delle connessioni attive utilizzando la ActiveFlowCount metrica. Per ulteriori informazioni, consulta CloudWatch metriche per il tuo Network Load Balancer.

Per correggere gli errori di allocazione delle porte, ti consigliamo di aggiungere destinazioni al gruppo di destinazione.

In alternativa, se non riesci ad aggiungere destinazioni al gruppo di destinazione, puoi aggiungere fino a 7 indirizzi IP secondari alle interfacce di rete del load balancer. Gli indirizzi IP secondari vengono assegnati automaticamente dai blocchi CIDR IPv4 delle sottoreti corrispondenti. Ogni indirizzo IP secondario consuma 6 unità di indirizzamento di rete. Tieni presente che dopo aver aggiunto un indirizzo IP secondario non puoi rimuoverlo. L'unico modo per rilasciare gli indirizzi IP secondari è eliminare il load balancer.

Errore intermittente nella creazione della connessione TCP o ritardi nella creazione della connessione TCP

Quando la conservazione dell'indirizzo IP del client è abilitata, un client può connettersi a un indirizzo IP di destinazione diverso utilizzando la stessa porta temporanea di origine. Questi indirizzi IP di destinazione possono provenire dallo stesso sistema di bilanciamento del carico (in diverse zone di disponibilità) quando è abilitato il bilanciamento del carico tra zone o da diversi Network Load Balancer che utilizzano lo stesso indirizzo IP di destinazione e la stessa porta registrati. In questo caso, se queste connessioni vengono indirizzate allo stesso indirizzo IP e alla stessa porta di destinazione, la destinazione vedrà una connessione duplicata, poiché provengono dallo stesso indirizzo IP e dalla stessa porta del client. Ciò comporta errori di connessione e ritardi nello stabilire una di queste connessioni. Ciò si verifica spesso quando si esegue la connessione a più indirizzi IP di Network Load Balancer contemporaneamente, quando viene assegnato un dispositivo NAT davanti al client e lo stesso indirizzo IP di origine e la stessa porta di origine.

È possibile ridurre questo tipo di errore di connessione aumentando il numero di porte temporanee di origine allocate dal client o dal dispositivo NAT oppure aumentando il numero di destinazioni per il load balancer. Consigliamo ai client di modificare la porta di origine utilizzata per la riconnessione dopo questi errori di connessione. Per evitare questo tipo di errore di connessione, se utilizzi un solo Network Load Balancer, puoi considerare di disabilitare il bilanciamento del carico tra zone o, se utilizzi più Network Load Balancer, puoi considerare di non utilizzare lo stesso indirizzo IP e la stessa porta di destinazione registrati in più gruppi di destinazione. In alternativa, puoi prendere in considerazione la disattivazione della conservazione dell'IP del client. Se hai bisogno dell'IP del client, puoi utilizzarlo per recuperarlo utilizzando Proxy Protocol v2. Per ulteriori informazioni su Proxy Protocol v2, vedere. Protocollo proxy

Potenziale errore durante il provisioning del sistema di bilanciamento del carico

L'utilizzo di un indirizzo IP già assegnato o allocato altrove (ad esempio, assegnato come indirizzo IP secondario per un'istanza EC2) potrebbe comportare la presenza di errori in un Network Load Balancer in fase di provisioning. Questo indirizzo IP impedisce la configurazione del sistema di bilanciamento del carico, con conseguente visualizzazione dello stato failed. Per risolvere questo problema, è possibile rimuovere l'allocazione dell'indirizzo IP associato e tentare nuovamente il processo di creazione.

Il traffico è distribuito in modo non uniforme tra le destinazioni

I listener TCP e TLS instradano le connessioni TCP e i listener UDP indirizzano i flussi UDP. Il load balancer seleziona le destinazioni utilizzando un algoritmo di flow hash. Una singola connessione da un client è intrinsecamente persistente.

Se noti che alcune destinazioni sembrano ricevere più traffico di altre, ti consigliamo di esaminare i log di flusso del VPC. Confronta il numero di connessioni univoche per ogni indirizzo IP di destinazione. Mantieni la finestra temporale il più breve possibile, poiché la registrazione di destinazione, la cancellazione e gli obiettivi non integri influiscono su questi numeri di connessione.

La risoluzione dei nomi DNS contiene meno indirizzi IP rispetto alle zone di disponibilità abilitate

Idealmente, il Network Load Balancer fornisce un indirizzo IP per ogni zona di disponibilità abilitata quando è presente almeno un host integro. Quando non sono presenti host integri in una determinata zona di disponibilità e il bilanciamento del carico tra zone è disabilitato, l'indirizzo IP del Network Load Balancer corrispondente a quella zona di disponibilità verrà rimosso dal DNS.

Ad esempio, supponiamo che il Network Load Balancer abbia tre zone di disponibilità abilitate, tutte con almeno un'istanza di destinazione registrata integra.

I pacchetti IP frammentati non vengono indirizzati alle destinazioni

I Network Load Balancer non supportano i pacchetti IP frammentati per il traffico non UDP.

Risolvi i problemi relativi agli obiettivi non integri utilizzando la mappa delle risorse

Se gli obiettivi di Network Load Balancer non superano i controlli di integrità, puoi utilizzare la mappa delle risorse per trovare obiettivi non integri e intraprendere azioni in base al codice del motivo dell'errore. Per ulteriori informazioni, consulta Visualizza la mappa delle risorse di Network Load Balancer.

La mappa delle risorse offre due visualizzazioni: Panoramica e Unhealthy Target Map. La panoramica è selezionata per impostazione predefinita e mostra tutte le risorse del sistema di bilanciamento del carico. Selezionando la visualizzazione Unhealthy Target Map verranno visualizzati solo i target non integri in ciascun gruppo di destinazione associato al Network Load Balancer.

La colonna Gruppi target mostra un riepilogo degli obiettivi integri e non integri per ciascun gruppo target. Questo può aiutare a determinare se tutti gli obiettivi non superano i controlli sanitari o solo obiettivi specifici. Se tutti gli obiettivi di un gruppo target non superano i controlli di integrità, controlla le impostazioni di controllo dello stato del gruppo target. Seleziona il nome di un gruppo target per aprirne la pagina dei dettagli in una nuova scheda.

La colonna Targets mostra il targetID e lo stato attuale dei controlli di integrità per ciascun target. Quando un obiettivo non è integro, viene visualizzato il codice del motivo del fallimento del controllo di integrità. Quando un singolo obiettivo non supera un controllo di integrità, verifica che il bersaglio disponga di risorse sufficienti. Seleziona l'ID di un target per aprirne la pagina dei dettagli in una nuova scheda.

Selezionando Esporta hai la possibilità di esportare la visualizzazione corrente della mappa delle risorse di Network Load Balancer in formato PDF.

Verifica che l'istanza non superi i controlli di integrità e quindi, in base al codice del motivo dell'errore, verifica i seguenti problemi: