|
LED
|
Significato
|
|
?
|
Collegato
|
|
?
|
Non monitorato
|
|
?
|
Drenaggio
|
|
?
|
Non in linea
|
|
?
|
Standby
|
|
?
|
Non collegato
|
|
?
|
Stato della ricerca
|
|
?
|
Server reali non autorizzati o con licenza superata
|
|
Opzione
|
Descrizione
|
|
In linea
|
Tutti i Real Server assegnati online riceveranno il traffico in base alla politica di bilanciamento del carico impostata nella scheda Base.
|
|
Drenaggio
|
Tutti i Real Server assegnati come Drain continueranno a servire le connessioni esistenti, ma non accetteranno nuove connessioni. La spia di stato lampeggia in verde/blu mentre è in corso il drenaggio. Una volta che le connessioni esistenti di si sono chiuse naturalmente, i Real Server andranno offline e l'indicatore di stato sarà blu fisso. È possibile visualizzare queste connessioni anche navigando nella sezione Navigazione > Monitor > Stato.
Il comportamento di scarico può essere modificato nella scheda Impostazioni avanzate.
|
|
Non in linea
|
Tutti i Real Server impostati come Offline saranno immediatamente messi offline e non riceveranno alcun traffico.
|
|
Standby
|
Tutti i server reali impostati come Standby rimarranno offline fino a quando TUTTI i server del gruppo Online non supereranno i controlli di Server Health Monitor. In questo caso, il traffico viene ricevuto dal gruppo Standby in base alla politica di bilanciamento del carico. Se un server del gruppo Online supera il controllo dello stato di salute del server, questo server Online riceverà tutto il traffico e il gruppo Standby smetterà di riceverlo.
|
|
Opzione
|
Descrizione
|
|
Connessioni minime
|
Il bilanciatore di carico tiene traccia del numero di connessioni correnti a ciascun Real Server. Il Real Server con il minor numero di connessioni riceve la nuova richiesta successiva.
|
|
Il più veloce
|
Il criterio di bilanciamento del carico più veloce calcola automaticamente il tempo di risposta di tutte le richieste per server, livellato nel tempo. La colonna Peso calcolato contiene il valore calcolato automaticamente. L'inserimento manuale è possibile solo quando si utilizza questo criterio di bilanciamento del carico.
|
|
Cookie persistente
|
Layer 7 Affinità/persistenza della sessione
La modalità di bilanciamento del carico basata sull'elenco IP viene utilizzata per ogni prima richiesta. L'ADC inserisce un cookie nelle intestazioni della prima risposta HTTP. Successivamente, l'ADC utilizza il cookie del client per instradare il traffico verso lo stesso server back-end. Questo cookie viene utilizzato per la persistenza quando il client deve andare ogni volta allo stesso server back-end. Il cookie scade dopo 2 ore e la connessione viene bilanciata in base a un algoritmo basato su un elenco di IP. Questo tempo di scadenza è configurabile tramite jetPACK.
|
|
Round Robin
|
Round Robin è comunemente utilizzato nei firewall e nei bilanciatori di carico di base ed è il metodo più semplice. Ogni server reale riceve una nuova richiesta in sequenza. Questo metodo è adatto solo quando è necessario bilanciare il carico delle richieste ai server in modo uniforme; un esempio potrebbe essere quello dei server web di ricerca. Tuttavia, quando è necessario bilanciare il carico in base al carico dell'applicazione o al carico del server, o anche per garantire l'utilizzo dello stesso server per la sessione, il metodo Round Robin è inappropriato.
|
|
IP Bound
|
Cookie di Affinità/Persistenza di sessione di livello 3.
In questa modalità, l'indirizzo IP del client costituisce la base per selezionare il Real Server che riceverà la richiesta. Questa azione garantisce la persistenza. I protocolli HTTP e Layer 4 possono utilizzare questa modalità. Questo metodo è utile per le reti interne in cui la topologia della rete è nota e si può essere sicuri che non ci siano "super proxy" a monte. Con il Layer 4 e i proxy, tutte le richieste possono sembrare provenienti da un unico client e quindi il carico non sarebbe uniforme. Con HTTP, le informazioni dell'intestazione (X-Forwarder-For) vengono utilizzate quando sono presenti per far fronte ai proxy.
|
|
Elenco IP
|
La connessione al Real Server inizia utilizzando "Least connections", quindi l'affinità di sessione è ottenuta in base all'indirizzo IP del client. Per impostazione predefinita, l'elenco viene mantenuto per 2 ore, ma può essere modificato con un jetPACK.
|
|
Elenco IP condiviso basato su
|
Questo tipo di servizio è disponibile solo quando la modalità di connettività è impostata su Ritorno diretto al server. È stato aggiunto principalmente per il supporto del bilanciamento del carico VMware.
|
|
Cookie persistente
|
Layer 7 Affinità/persistenza della sessione
La modalità di bilanciamento del carico basata sull'elenco IP viene utilizzata per ogni prima richiesta. L'ADC inserisce un cookie nelle intestazioni della prima risposta HTTP. Successivamente, l'ADC utilizza il cookie del client per instradare il traffico verso lo stesso server back-end. Questo cookie viene utilizzato per la persistenza quando il client deve andare ogni volta allo stesso server back-end. Il cookie scade dopo 2 ore e la connessione viene bilanciata in base a un algoritmo basato su un elenco di IP. Questo tempo di scadenza è configurabile tramite jetPACK.
|
|
Cookie di sessione ASP classico
|
Active Server Pages (ASP) è una tecnologia lato server di Microsoft. Con questa opzione selezionata, l'ADC manterrà la persistenza della sessione sullo stesso server se un cookie ASP viene rilevato e trovato nell'elenco dei cookie conosciuti. Quando viene rilevato un nuovo cookie ASP, il carico viene bilanciato utilizzando l'algoritmo Least Connections.
|
|
Cookie di sessione ASP.NET
|
Questa modalità si applica ad ASP.net. Con questa modalità selezionata, l'ADC manterrà la persistenza della sessione sullo stesso server se un cookie ASP.NET viene rilevato e trovato nel suo elenco di cookie conosciuti. Quando viene rilevato un nuovo cookie ASP, il carico viene bilanciato utilizzando l'algoritmo Least Connections.
|
|
Cookie di sessione JSP
|
Java Server Pages (JSP) è una tecnologia lato server di Oracle. Con questa modalità selezionata, l'ADC manterrà la persistenza della sessione sullo stesso server se un cookie JSP viene rilevato e trovato nell'elenco dei cookie conosciuti. Quando viene rilevato un nuovo cookie JSP, il carico viene bilanciato utilizzando l'algoritmo Least Connections.
|
|
Cookie di sessione JAX-WS
|
I servizi web Java (JAX-WS) sono una tecnologia lato server di Oracle. Con questa modalità selezionata, l'ADC manterrà la persistenza della sessione sullo stesso server se un cookie JAX-WS viene rilevato e trovato nel suo elenco di cookie conosciuti. Quando viene rilevato un nuovo cookie JAX-WS, il carico viene bilanciato utilizzando l'algoritmo Least Connections.
|
|
Cookie di sessione PHP
|
Personal Home Page (PHP) è una tecnologia open-source sul lato server. Selezionando questa modalità, l'ADC manterrà la persistenza della sessione sullo stesso server quando viene rilevato un cookie PHP.
|
|
Persistenza dei cookie RDP
|
Questo metodo di bilanciamento del carico utilizza il cookie RDP creato da Microsoft e basato su nome utente/dominio per fornire persistenza a un server. Il vantaggio di questo metodo è che la connessione al server può essere mantenuta anche se l'indirizzo IP del client cambia.
|
|
Basato su cookie-ID
|
Un nuovo metodo molto simile a "PhpCookieBased" e ad altri metodi di bilanciamento del carico, ma che utilizza CookieIDBased e cookie RegEx h=[^;]+
Questo metodo utilizzerà il valore impostato nel campo note del Real Server "ID=X;" come valore del cookie per identificare il server. Si tratta quindi di una metodologia simile a CookieListBased, ma utilizza un nome di cookie diverso e memorizza un valore di cookie univoco, non l'IP criptato, ma l'ID del server reale (letto al momento del caricamento).
Il valore predefinito è CookieIDName="h"; tuttavia, se esiste un valore di override nella configurazione delle impostazioni avanzate del server virtuale, utilizzare questo valore. NOTA: se questo valore è impostato, sovrascriviamo l'espressione del cookie di cui sopra per sostituire h= con il nuovo valore.
L'ultimo punto è che se arriva un valore di cookie sconosciuto che corrisponde a uno degli ID del server reale, si deve selezionare quel server; altrimenti, si usa il metodo successivo (delegare).
|
|
Opzione
|
Descrizione
|
|
Nessuno
|
In questa modalità, il Real Server non viene monitorato ed è sempre attivo e funzionante correttamente. L'impostazione Nessuno è utile per le situazioni in cui il monitoraggio disturba un server e per i servizi che non dovrebbero partecipare all'azione di fail-over dell'ADC. È un modo per ospitare sistemi inaffidabili o legacy che non sono primari per le operazioni H/A. Utilizzare questo metodo di monitoraggio con qualsiasi tipo di servizio.
|
|
Eco Ping/ICMP
|
In questa modalità, l'ADC invia una richiesta di echo ICMP all'IP del server di contenuti. Se viene ricevuta una risposta echo valida, l'ADC considera il Real Server attivo e funzionante e il traffico verso il server continua. Inoltre, manterrà il servizio disponibile su una coppia H/A. Questo metodo di monitoraggio è utilizzabile con qualsiasi tipo di servizio.
|
|
Connessione TCP
|
In questa modalità, viene stabilita una connessione TCP al Real Server, che viene immediatamente interrotta senza inviare alcun dato. Se la connessione riesce, l'ADC ritiene che il Real Server sia attivo e funzionante. Questo metodo di monitoraggio è utilizzabile con qualsiasi tipo di servizio; attualmente i servizi UDP non sono adatti al monitoraggio della connessione TCP.
|
|
ICMP non raggiungibile
|
L'ADC invia un controllo dello stato di salute UDP al server e contrassegna il Real Server come non disponibile se riceve un messaggio ICMP di porta non raggiungibile. Questo metodo può essere utile quando è necessario verificare se una porta di servizio UDP è disponibile su un server, come la porta 53 del DNS.
|
|
PSR
|
In questa modalità, una connessione TCP viene inizializzata come spiegato nel metodo ICMP Unreachable. Dopo l'inizializzazione della connessione, viene richiesta una connessione RDP Layer 7. Se il collegamento viene confermato, l'ADC considera il Real Server funzionante. Se il collegamento viene confermato, l'ADC ritiene che il Real Server sia attivo e funzionante. Questo metodo di monitoraggio è utilizzabile con qualsiasi terminal server Microsoft.
|
|
200 OK
|
In questo metodo, viene inizializzata una connessione TCP al Real Server. Dopo che la connessione è riuscita, l'ADC invia al Real Server una richiesta HTTP. Si attende una risposta HTTP e si controlla il codice di risposta "200 OK". L'ADC considera il Real Server attivo e funzionante se riceve il codice di risposta "200 OK". Se l'ADC non riceve un codice di risposta "200 OK" per qualsiasi motivo, compresi i timeout, la mancata connessione e altri motivi, l'ADC considera il Real Server non disponibile. Questo metodo di monitoraggio è valido solo per i tipi di servizio HTTP e HTTP accelerato. Se si utilizza un tipo di servizio Layer 4 per un server HTTP, è possibile utilizzarlo se SSL non è in uso sul Real Server o è gestito in modo appropriato dalla funzione "Content SSL".
|
|
DICOM
|
Viene inizializzata una connessione TCP al Real Server in modalità DICOM e al momento della connessione viene effettuata una "Richiesta di associazione" di Echoscu al Real Server. Una conversazione che include un "Associate Accept" dal server dei contenuti, un trasferimento di una piccola quantità di dati seguito da un "Release Request" e da un "Release Response" conclude con successo il monitor. Se il monitoraggio non si conclude con successo, il Real Server viene considerato inattivo per qualsiasi motivo.
|
|
Definito dall'utente
|
Qualsiasi monitor configurato nella sezione Monitoraggio del server reale apparirà nell'elenco.
|
|
Opzione
|
Descrizione
|
|
Da parte di Host
|
La cache per host si basa sull'applicazione per nome di host. Per ogni dominio/nome host esiste una cache separata. Questa modalità è ideale per i server web che possono servire più siti web a seconda del dominio.
|
|
Per Servizio Virtuale
|
La cache per servizio virtuale è disponibile quando si sceglie questa opzione. Esisterà una sola cache per tutti i domini/nomi di host che passano attraverso il servizio virtuale. Questa opzione è un'impostazione specializzata per l'uso con più cloni di un singolo sito.
|
|
Opzione
|
Descrizione
|
|
Spento
|
Disattivare la compressione per il servizio virtuale
|
|
Compressione
|
Se selezionata, questa opzione attiva la compressione per il servizio virtuale selezionato. L'ADC comprime dinamicamente il flusso di dati al client su richiesta. Questo processo si applica solo agli oggetti che contengono l'intestazione content-encoding: gzip. Un esempio di contenuto è HTML, CSS o JavaScript. È inoltre possibile escludere alcuni tipi di contenuto utilizzando la sezione Esclusioni globali.
|
|
Opzione
|
Descrizione
|
|
No SSL
|
Il traffico dalla sorgente all'ADC non è crittografato.
|
|
Tutti
|
Carica tutti i certificati disponibili per l'uso
|
|
Predefinito
|
Questa opzione comporta l'applicazione di un certificato creato localmente chiamato "Default" al lato browser del canale. Utilizzare questa opzione per testare l'SSL quando non è stato creato o importato.
|
|
Opzione
|
Descrizione
|
|
No SSL
|
Il traffico dall'ADC al Real Server non è criptato. La selezione di un certificato sul lato browser significa che "No SSL" può essere scelto sul lato client per fornire il cosiddetto "SSL Offload".
|
|
Qualsiasi
|
L'ADC agisce come client e accetta qualsiasi certificato presentato dal Real Server. Il traffico dall'ADC al Real Server è crittografato quando si seleziona questa opzione. Utilizzare l'opzione "Qualsiasi" quando viene specificato un certificato sul lato del servizio virtuale, per ottenere il cosiddetto "SSL Bridging" o "SSL Re-Encryption".
|
|
SNI
|
SNI, o Server Name Indication, è un'estensione del protocollo di rete TLS che consente al client di indicare il nome dell'host a cui sta tentando di connettersi all'inizio del processo di handshaking . Questa impostazione consente all'ADC di presentare più certificati sullo stesso indirizzo IP virtuale e sulla stessa porta TCP.
|
|
Predefinito
|
I certificati autofirmati generati appaiono qui.
|
|
Opzione
|
Descrizione
|
|
Proxy inverso
|
Reverse Proxy è il valore predefinito e utilizza la compressione e la cache quando viene usato con il Layer 7. Al livello 4, il reverse proxy funziona senza cache o compressione. In questa modalità, l'ADC agisce come reverse proxy e diventa l'indirizzo sorgente visto dai Real Server.
|
|
Ritorno diretto del server
|
Il Direct Server Return o DSR, noto anche come DR - Direct Routing, consente al server dietro il bilanciatore di carico di rispondere direttamente al client, bypassando l'ADC sulla risposta. Il DSR è adatto solo per l'uso con il bilanciamento del carico di livello 4. Pertanto, la cache e la compressione non sono disponibili con il DSR. Pertanto, la cache e la compressione non sono disponibili con questa opzione.
Questa modalità può essere utilizzata solo con i tipi di servizio TCP, UDP e TCP/UDP.
I criteri di persistenza del bilanciamento del carico sono inoltre limitati a Connessioni minime, Elenco IP condiviso, Round Robin e Elenco IP.
 L'utilizzo di DSR richiede anche l'esecuzione di modifiche al Real Server. Consultare la sezione Modifiche al Real Server.
|
|
NAT
|
Per impostazione predefinita, l'ADC utilizza l'indirizzo IP dell'ADC come indirizzo IP di origine e i Real Server inviano la risposta all'ADC per restituirla al Cliente. Questo va bene in quasi tutte le circostanze, ma ci sono scenari in cui il Real Server ha bisogno di vedere l'indirizzo IP di origine del Client e non dell'ADC.
Quando si applica la modalità NAT, l'ADC riceve la richiesta in entrata e la invia al Real Server dopo aver modificato l'indirizzo IP di origine in quello del Virtual Service (indirizzo VIP).
Questa modalità può essere utilizzata solo con i seguenti criteri di bilanciamento del carico:
 |
|
Porta d'ingresso
|
La modalità gateway consente di instradare tutto il traffico attraverso l'ADC, permettendo ai Real Server di essere instradati attraverso l'ADC verso altre reti tramite i servizi virtuali o le interfacce hardware dell'ADC. L'uso del dispositivo come gateway per i Real Server è ideale quando si opera in modalità multi-interfaccia.
I criteri di persistenza del bilanciamento del carico sono inoltre limitati a Connessioni minime, Elenco IP condiviso, Round Robin e Elenco IP.
Questo metodo richiede che il Real Server imposti il suo gateway predefinito sull'indirizzo dell'interfaccia locale dell'ADC (eth0, eth1, ecc.). Consultare la sezione Modifiche del Real Server.
Si noti che la modalità Gateway non supporta il failover in un ambiente cluster.
|
|
Opzione
|
Descrizione
|
|
Nessuno
|
Quando non c'è un'intestazione Proxy o non è supportata dal tipo di servizio corrente.
|
|
Rimuovere
|
Rimuove l'intestazione Proxy dal pacchetto TCP.
|
|
In avanti
|
Inoltra l'intestazione Proxy al server
|
|
Opzione
|
Descrizione
|
|
Versione 1
|
Formato basato sul testo, facile da implementare e da debuggare.
Fornisce informazioni di base sulla connessione del client, tra cui IP di origine, IP di destinazione, porta di origine e porta di destinazione.
La linea di protocollo viene aggiunta all'inizio della connessione TCP, rendendola leggibile all'uomo ma leggermente meno efficiente in termini di prestazioni rispetto ai formati binari.
|
|
Versione 2
|
Formato binario, progettato per migliorare le prestazioni e l'efficienza.
Estende le informazioni che possono essere trasmesse sulla connessione, supportando dati aggiuntivi come la famiglia di indirizzi e le informazioni specifiche del protocollo.
Garantisce una migliore compatibilità con i moderni protocolli e funzionalità di rete, compreso il supporto per IPv6 e i protocolli di trasporto oltre il TCP.
|
|
Opzione
|
Descrizione
|
|
IP di base (predefinito)
|
Utilizza l'indirizzo eth0 o IP di base dell'ADC come IP di origine della richiesta.
|
|
IP virtuale
|
Utilizza l'IP virtuale del servizio.
|
|
<indirizzo IP>
|
Consente di specificare un indirizzo IP che fa parte dell'ADC. Potrebbe trattarsi di un'interfaccia di rete diversa o di un VIP diverso.
|
|
Opzione
|
Descrizione
|
|
Persistenza guidata
|
Questa è la selezione predefinita.
Ogni volta che l'utente visita la sessione di persistenza, questa viene estesa.
Con un utilizzo di 24 ore, è possibile che lo scarico non avvenga mai.
Tuttavia, se il numero di connessioni al server reale raggiunge lo 0, il drenaggio termina, le sessioni di persistenza vengono eliminate e tutti i visitatori vengono ribilanciati alla prossima connessione.
|
|
Migrare i visitatori
|
Sessione persistente ignorata alla nuova connessione (comportamento precedente al 2022)
Le nuove connessioni TCP (che facciano parte o meno di una sessione esistente) vengono sempre effettuate a un server reale online.
Se la sessione di persistenza era a un server reale in esaurimento, viene sovrascritta.
Il servizio virtuale ignorerà di fatto la persistenza delle nuove connessioni, che saranno bilanciate su un nuovo server.
|
|
Sessioni di pensionamento
|
Sessioni persistenti non estese.
Le connessioni degli utenti in arrivo vengono assegnate al server desiderato, ma la loro sessione di persistenza non viene estesa. Pertanto, una volta superata la durata della sessione di persistenza, saranno trattate come nuove connessioni e spostate su un altro server.
|
