|
|||||||
|
|||||||
|
|
Campo
|
Descrizione
|
|
Indirizzo IP
|
Inserisci un nuovo indirizzo IP virtuale per essere il punto di ingresso di destinazione per l'accesso al Real Server. Questo IP è dove gli utenti o le applicazioni punteranno per accedere all'applicazione con bilanciamento del carico.
|
|
Subnet Mask/Prefix
|
Questo campo è per la subnet mask relativa alla rete su cui si trova l'ADC
|
|
Porto
|
La porta d'ingresso utilizzata quando si accede al VIP. Questo valore non deve necessariamente essere lo stesso del Real Server se usi il Reverse Proxy.
|
|
Nome del servizio
|
Il nome del servizio è una rappresentazione testuale dello scopo del VIP. È facoltativo, ma ti consigliamo di fornirlo per chiarezza.
|
|
Tipo di servizio
|
Ci sono molti diversi tipi di servizio disponibili per voi da selezionare. I tipi di servizio Layer 4 non possono usare la tecnologia flightPATH.
|
|
Campo
|
Descrizione
|
|
Attività
|
Il campo Attività può essere usato per mostrare e cambiare lo stato del server reale bilanciato.
Online - Indica che il server è attivo e sta ricevendo richieste bilanciate
Offline - Il server è offline e non riceve richieste
Drenaggio - Il server è stato messo in modalità di drenaggio in modo che la persistenza possa essere scaricata e il server spostato in uno stato offline senza influenzare gli utenti.
Standby - Il server è stato messo in uno stato di standby
|
|
Indirizzo IP
|
Questo valore è l'indirizzo IP del Real Server. Deve essere preciso e non deve essere un indirizzo DHCP.
|
|
Porto
|
La porta di destinazione di accesso sul Real Server. Quando si utilizza un reverse proxy, questo può essere diverso dalla porta d'ingresso specificata sul VIP.
|
|
Ponderazione
|
Questa impostazione di solito è configurata automaticamente dall'ADC. Puoi cambiarla se vuoi cambiare la ponderazione della priorità.
|
|
Opzione
|
Descrizione
|
|
Cluster
|
Cluster è il ruolo predefinito per l'ADC all'installazione, e la colonna Primary/Mode indicherà la modalità in cui è attualmente in esecuzione. Quando hai una coppia HA di apparecchi ADC nel tuo centro dati, uno di essi mostrerà Active e l'altro Passive
|
|
Manuale
|
Il ruolo Manual permette alla coppia ADC di funzionare in modalità Active-Active per diversi indirizzi IP virtuali. In questi casi, la colonna Primary conterrà una casella accanto ad ogni unico Virtual IP che può essere spuntata per Active o lasciata deselezionata per Passive.
|
|
Stand-Alone
|
L'ADC sta agendo come un dispositivo stand-alone e non è in modalità High Availability. Come tale, la colonna Primary indicherà Stand-alone.
|
|
LED
|
Significato
|
|
l
|
Online
|
|
l
|
Failover-Standby. Questo servizio virtuale è hot-standby
|
|
l
|
Indica che un "secondario" sta aspettando un "primario".
|
|
l
|
Il servizio ha bisogno di attenzione. Questa indicazione può derivare da un Real Server che fallisce un controllo dello stato di salute o è stato cambiato manualmente in Offline. Il traffico continuerà a fluire ma con una capacità ridotta del Real Server
|
|
l
|
Offline. I server di contenuto non sono raggiungibili, o nessun server di contenuto abilitato
|
|
l
|
Trovare lo stato
|
|
l
|
IP virtuali non concessi in licenza o concessi in licenza superati
|
|
Tipo di servizio
|
Porta/Protocollo
|
Strato di servizio
|
Commento
|
|
Layer 4 TCP
|
Qualsiasi porta TCP
|
Livello 4
|
L'ADC non altera alcuna informazione nel flusso di dati ed esegue il bilanciamento standard del traffico secondo la politica di bilanciamento del carico
|
|
Livello 4 UDP
|
Qualsiasi porta UDP
|
Livello 4
|
Come con il Layer 4 TCP, l'ADC non altera alcuna informazione nel flusso di dati ed esegue il bilanciamento standard del traffico secondo la politica di bilanciamento del carico
|
|
Layer 4 TCP/UDP
|
Qualsiasi porta TCP o UDP
|
Livello 4
|
È ideale se il vostro servizio ha un protocollo primario come UDP ma ricadrà su TCP. L'ADC non altera alcuna informazione nel flusso di dati ed esegue il bilanciamento standard del traffico secondo la politica di bilanciamento del carico
|
|
DNS
|
TCP/UDP
|
Livello 4
|
Usato per bilanciare il carico dei server DNS.
|
|
HTTP
|
Protocollo HTTP o HTTPS
|
Livello 7
|
L'ADC può interagire, manipolare e modificare il flusso di dati utilizzando flightPATH.
|
|
FTP
|
Protocollo per il trasferimento di file
|
Livello 7
|
Usare connessioni di controllo e dati separate tra client e server
|
|
SMTP
|
Protocollo semplice di trasferimento della posta
|
Livello 4
|
Da usare per il bilanciamento del carico dei server di posta
|
|
POP3
|
Protocollo dell'ufficio postale
|
Livello 4
|
Da usare per il bilanciamento del carico dei server di posta
|
|
IMAP
|
Protocollo di accesso ai messaggi Internet
|
Livello 4
|
Da usare per il bilanciamento del carico dei server di posta
|
|
RDP
|
Protocollo desktop remoto
|
Livello 4
|
Da usare per il bilanciamento del carico dei server Terminal Services
|
|
RPC
|
Chiamata di procedura remota
|
Livello 4
|
Usare quando si bilanciano i sistemi di carico usando chiamate RPC
|
|
RPC/ADS
|
Exchange 2010 RPC statico per il servizio di rubrica
|
Livello 4
|
Da usare per il bilanciamento del carico dei server Exchange
|
|
RPC/CA/PF
|
Exchange 2010 RPC statico per accesso client e cartelle pubbliche
|
Livello 4
|
Da usare per il bilanciamento del carico dei server Exchange
|
|
DICOM
|
Imaging digitale e comunicazioni in medicina
|
Livello 4
|
Usare quando si bilanciano i server che usano i protocolli DICOM
|
|
LED
|
Significato
|
|
l
|
Collegato
|
|
£
|
Non monitorato
|
|
l
|
Drenaggio di
|
|
l
|
Offline
|
|
l
|
Standby
|
|
l
|
Non collegato
|
|
l
|
Trovare lo stato
|
|
l
|
Server reali non licenziati o con licenza superata
|
|
Opzione
|
Descrizione
|
|
Online
|
Tutti i Real Server assegnati online riceveranno il traffico secondo la politica di bilanciamento del carico impostata nella scheda Base.
|
|
Scarico
|
Tutti i Real Server assegnati come Drenaggio continueranno a servire le connessioni esistenti ma non accetteranno nuove connessioni. La luce di stato lampeggerà verde/blu mentre il drenaggio è in corso. Una volta che le connessioni esistenti si sono chiuse naturalmente, i Real Server andranno offline e la luce di stato sarà blu fissa. Puoi anche visualizzare queste connessioni navigando nella sezione Navigazione > Monitor > Stato.
|
|
Offline
|
Tutti i Real Server impostati come Offline saranno immediatamente messi offline e non riceveranno alcun traffico.
|
|
Standby
|
Tutti i Real Server impostati come Standby rimarranno offline fino a quando TUTTI i server del gruppo Online non falliranno i controlli del Server Health Monitor. Il traffico viene ricevuto dal gruppo Standby secondo la politica di bilanciamento del carico quando questo accade. Se un server del gruppo Online passa il controllo del Server Health Monitor, questo server Online riceverà tutto il traffico, e il gruppo Standby smetterà di ricevere il traffico.
|
|
Opzione
|
Descrizione
|
|
Il più veloce
|
La politica di bilanciamento del carico più veloce calcola automaticamente il tempo di risposta per tutte le richieste per server livellato nel tempo. La colonna Calculated Weight contiene il valore calcolato automaticamente. L'inserimento manuale è possibile solo quando si usa questa politica di bilanciamento del carico.
|
|
Round Robin
|
Round Robin è comunemente usato nei firewall e nei bilanciatori di carico di base ed è il metodo più semplice. Ogni Real Server riceve una nuova richiesta in sequenza. Questo metodo è appropriato solo quando è necessario bilanciare il carico di richieste ai server in modo uniforme; un esempio potrebbe essere il look-up dei server web. Tuttavia, quando è necessario bilanciare il carico in base al carico dell'applicazione o al carico del server, o anche assicurarsi di utilizzare lo stesso server per la sessione, il metodo Round Robin è inappropriato.
|
|
Meno connessioni
|
Il bilanciatore di carico terrà traccia del numero di connessioni correnti a ciascun Real Server. Il Real Server con il minor numero di connessioni riceve la nuova richiesta successiva.
|
|
IP Bound
Affinità/Persistenza di sessione del livello 3
|
In questa modalità, l'indirizzo IP del client costituisce la base per selezionare quale Real Server riceverà la richiesta. Questa azione fornisce persistenza. I protocolli HTTP e Layer 4 possono utilizzare questa modalità. Questo metodo è utile per le reti interne dove la topologia di 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 apparire come se provenissero da un solo client, e come tali, il carico non sarebbe uniforme. Con HTTP, l'informazione dell'intestazione (X-Forwarder-For) viene utilizzata quando presente per far fronte ai proxy.
|
|
Lista IP basata su
Affinità/Persistenza di sessione del livello 3
|
La connessione al Real Server inizia usando "Least connections" quindi, l'affinità di sessione è ottenuta in base all'indirizzo IP del client. Un elenco è mantenuto per 2 ore per impostazione predefinita, ma questo può essere cambiato utilizzando un jetPACK.
|
|
Cookie di sessione
Layer 7 Affinità/Persistenza della sessione
|
Questa modalità è il metodo di persistenza più popolare per il bilanciamento del carico HTTP. In questa modalità, l'ADC utilizza il bilanciamento del carico basato su liste IP per ogni prima richiesta. Inserisce un cookie nelle intestazioni della prima risposta HTTP. Dopo di che, l'ADC usa il cookie del client per instradare il traffico allo stesso server back-end. Questo cookie viene utilizzato per la persistenza quando il client ha bisogno di andare allo stesso server back-end ogni volta. Il cookie scade una volta chiusa la sessione.
|
|
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. Dopo di che, l'ADC usa 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 di back-end. Il cookie scade dopo 2 ore, e la connessione sarà bilanciata secondo un algoritmo IP List Based. Questo tempo di scadenza è configurabile usando un jetPACK.
|
|
Cookie di sessione - Classico cookie di sessione ASP
|
Active Server Pages (ASP) è una tecnologia Microsoft lato server. Con questa opzione selezionata, l'ADC manterrà la persistenza della sessione sullo stesso server se un cookie ASP viene rilevato e trovato nella sua lista di cookie conosciuti. Al rilevamento di un nuovo cookie ASP, sarà bilanciato il carico utilizzando l'algoritmo Least Connections.
|
|
Cookie di sessione - Cookie di sessione ASP.NET
|
Questa modalità si applica a 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 nella sua lista di cookie conosciuti. Al rilevamento di un nuovo cookie ASP, sarà bilanciato il carico utilizzando l'algoritmo Least Connections.
|
|
Cookie di sessione - JSP Session Cookie
|
Java Server Pages (JSP) è una tecnologia Oracle lato server. Con questa modalità selezionata, l'ADC manterrà la persistenza della sessione sullo stesso server se un cookie JSP viene rilevato e trovato nella sua lista di cookie conosciuti. Al rilevamento di un nuovo cookie JSP, sarà bilanciato il carico utilizzando l'algoritmo Least Connections.
|
|
Cookie di sessione - Cookie di sessione JAX-WS
|
Java web services (JAX-WS) è una tecnologia Oracle lato server. Con questa modalità selezionata, l'ADC manterrà la persistenza della sessione allo stesso server se un cookie JAX-WS viene rilevato e trovato nella sua lista di cookie conosciuti. Al rilevamento di un nuovo cookie JAX-WS, il carico sarà bilanciato utilizzando l'algoritmo Least Connections.
|
|
Cookie di sessione - PHP Session Cookie
|
Personal Home Page (PHP) è una tecnologia open-source lato server. Con questa modalità selezionata, l'ADC manterrà la persistenza della sessione sullo stesso server quando viene rilevato un cookie PHP.
|
|
Cookie di sessione - persistenza del cookie RDP
|
Questo metodo di bilanciamento del carico utilizza il cookie RDP creato da Microsoft basato su nome utente/dominio per fornire persistenza a un server. Il vantaggio di questo metodo significa che è possibile mantenere una connessione a un server 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 usando CookieIDBased e cookie RegEx h=[^;]+
Questo metodo userà il valore impostato nel campo note del Real Server "ID=X;" come valore del cookie per identificare il server. Questo, quindi, significa che è una metodologia simile a CookieListBased ma usa un nome di cookie diverso e memorizza un valore di cookie unico, non l'IP criptato, ma l'ID del Real Server (letto al momento del caricamento).
Il valore predefinito è CookieIDName="h"; tuttavia, se c'è un valore di override nella configurazione delle impostazioni avanzate del server virtuale, usa invece questo. NOTA: sovrascriviamo l'espressione del cookie di cui sopra per sostituire h= con il nuovo valore se questo valore è impostato.
L'ultimo bit è che se arriva un valore di cookie sconosciuto e corrisponde a uno degli ID del server reale, dovrebbe selezionare quel server; altrimenti, usa il metodo successivo (delegare).
|
|
Lista IP condivisa basata su
|
Questo tipo di servizio è disponibile solo quando la modalità di connettività è impostata su Gateway o Direct Server Return. È stato aggiunto principalmente per il supporto al bilanciamento del carico VMware.
|
|
Opzione
|
Descrizione
|
|
Nessuno
|
In questa modalità, il Real Server non viene monitorato ed è sempre attivo e funzionante correttamente. L'impostazione None è utile per le situazioni in cui il monitoraggio sconvolge un server e per i servizi che non dovrebbero partecipare all'azione di fail-over dell'ADC. È un percorso 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 ICMP echo all'IP del content server. 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
|
Una connessione TCP viene fatta al Real Server e immediatamente interrotta senza inviare alcun dato in questa modalità. 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, e i servizi UDP non sono attualmente appropriati per il monitoraggio della connessione TCP.
|
|
ICMP irraggiungibile
|
L'ADC invierà un controllo di salute UDP al server e contrassegnerà il Real Server come non disponibile se riceve un messaggio ICMP port unreachable. Questo metodo può essere utile quando è necessario controllare se una porta di servizio UDP è disponibile su un server, come la porta DNS 53.
|
|
RDP
|
In questa modalità, una connessione TCP si inizializza 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 ritiene che il Real Server sia attivo e funzionante. Questo metodo di monitoraggio è utilizzabile con qualsiasi terminal server Microsoft.
|
|
200 OK
|
In questo metodo, una connessione TCP si inizializza al Real Server. Dopo che la connessione ha successo, 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 viene ricevuto il codice di risposta "200 OK". Se l'ADC non riceve un codice di risposta "200 OK" per qualsiasi motivo, inclusi timeout, mancata connessione e altri motivi, l'ADC segna il Real Server non disponibile. Questo metodo di monitoraggio è valido solo per l'uso con i tipi di servizio HTTP e HTTP accelerato. Se un tipo di servizio Layer 4 viene utilizzato per un server HTTP, è utilizzabile se SSL non è in uso sul Real Server o gestito in modo appropriato dalla funzione "Content SSL".
|
|
DICOM
|
Una connessione TCP si inizializza al Real Server in modalità DICOM, e una "Associate Request" di Echoscu viene fatta al Real Server sulla connessione. Una conversazione che include un "Associate Accept" dal content server, un trasferimento di una piccola quantità di dati seguito da un "Release Request", poi "Release Response" conclude con successo il monitor. Se il monitor non si conclude con successo, allora il Real Server è considerato inattivo per qualsiasi motivo.
|
|
Definito dall'utente
|
Qualsiasi monitor configurato nella sezione Monitoraggio del server reale apparirà nell'elenco.
|
|
Opzione
|
Descrizione
|
|
Per ospite
|
La cache per host è basata sull'applicazione per hostname. Una cache separata esisterà per ogni dominio/nome di host. 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. Solo una cache esisterà per tutti i domini/nomi di host che passano attraverso il servizio virtuale. Questa opzione è un'impostazione specialistica per l'uso con più cloni di un singolo sito.
|
|
Opzione
|
Descrizione
|
|
Off
|
Disattivare la compressione per il servizio virtuale
|
|
Compressione
|
Quando è 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 include HTML, CSS o Javascript. Puoi anche escludere certi tipi di contenuto usando la sezione Global Exclusions.
|
|
Opzione
|
Descrizione
|
|
No SSL
|
Il traffico dalla sorgente all'ADC non è criptato.
|
|
Tutti
|
Carica tutti i certificati disponibili per l'uso
|
|
Default
|
Questa opzione ha come risultato l'applicazione di un certificato creato localmente chiamato "Default" al lato del browser del canale. Usa questa opzione per testare SSL quando non ne è stato creato o importato uno.
|
|
AnyUseCert
|
Utilizzare qualsiasi certificato presente sull'ADC che l'utente ha caricato o generato
|
|
Opzione
|
Descrizione
|
|
No SSL
|
Il traffico dall'ADC al Real Server non è criptato. La selezione di un certificato sul lato del browser significa che "No SSL" può essere scelto lato client per fornire ciò che è noto come "SSL Offload".
|
|
Qualsiasi
|
L'ADC agisce come un client e accetta qualsiasi certificato presentato dal Real Server. Il traffico dall'ADC al Real Server è criptato quando questa opzione è selezionata. Usa l'opzione "Any" quando un certificato è specificato sul lato del servizio virtuale, fornendo ciò che è noto come "SSL Bridging" o "SSL Re-Encryption".
|
|
SNI
|
L'ADC agisce come un client e accetterà qualsiasi certificato presentato dal Real Server. Il traffico dall'ADC al Real Server è criptato se questo è selezionato. Usa l'opzione "Any" quando un certificato è specificato sul lato Virtual Service, fornendo ciò che è noto come "SSL Bridging" o "SSL Re-Encryption". Scegliete questa opzione per abilitare SNI sul lato server.
|
|
AnyUseCert
|
Tutti i certificati che hai generato o importato nell'ADC appaiono qui.
|
|
Opzione
|
Descrizione
|
|
Proxy inverso
|
Reverse Proxy è il valore predefinito e funziona a Layer7 con compressione e caching. E a Layer4 senza caching o compressione. In questa modalità, il tuo ADC agisce come un reverse proxy e diventa l'indirizzo sorgente visto dai Real Server.
|
|
Ritorno diretto al server
|
Direct Server Return o DSR come è ampiamente conosciuto (DR - Direct Routing in alcuni circoli) permette al server dietro il bilanciatore di carico di rispondere direttamente al client bypassando l'ADC sulla risposta. DSR è adatto solo per l'uso con il bilanciamento del carico a livello 4. Pertanto, il caching e la compressione non sono disponibili con questa opzione scelta.
Questa modalità può essere usata solo con i tipi di servizio TCP, UDP e TCP/UDP.
Il bilanciamento del carico al livello 7 non funziona con questo DSR. Inoltre, non c'è alcun supporto di persistenza diverso dall'IP List Based. Il bilanciamento del carico SSL/TLS con questo metodo non è ideale in quanto il supporto di persistenza Source IP è l'unico tipo disponibile. Il DSR richiede anche modifiche al Real Server per essere fatto. Si prega di fare riferimento alla sezione Modifiche al server reale.
|
|
Gateway
|
La modalità gateway consente di instradare tutto il traffico attraverso l'ADC, permettendo ai Real Server di essere indirizzati attraverso l'ADC ad altre reti tramite le macchine virtuali ADC o le interfacce hardware. L'utilizzo del dispositivo come dispositivo gateway per i Real Server è ideale quando si esegue in modalità multi-interfaccia.
Il bilanciamento del carico al livello 7 con questo metodo non funziona in quanto non c'è alcun supporto di persistenza oltre a quello basato sull'elenco IP. Questo metodo richiede che il Real Server imposti il suo gateway predefinito all'indirizzo dell'interfaccia locale dell'ADC (eth0, eth1, ecc.). Fai riferimento alla sezione Modifiche del Real Server.
Si prega di notare che la modalità Gateway non supporta il failover in un ambiente cluster.
|
