- Why Edgenexus?
- Try
- Products
- Solutions
- Applications
- Resources
COMPARE
READ
WATCH
SEE
Alliances and Partners
- Support
Esercitazione sull'unità di prova del bilanciatore di carico/ADC ALB-X
(ADC Application Delivery Controller)
Richiedi il tuo test drive qui
Indice dei contenuti
Ci auguriamo che la vostra esperienza con il bilanciatore di carico ALB-X sia piacevole e che abbiate a disposizione una configurazione realistica con cui giocare.
-
Nell'ambito di questo test drive abbiamo preconfigurato alcuni servizi di esempio per rendervi subito operativi.
-
Ospitiamo questa configurazione su Azure, ma non preoccupatevi, non è necessario avere un account Azure e inoltre è GRATIS.
-
Siete invitati a riconfigurare l'appliance per provarla sui vostri server.
Ecco alcune parole che vi aiuteranno a navigare nell'interfaccia utente e a ottenere il massimo dal vostro giro di prova, quindi allacciate le cinture di sicurezza....
Una volta effettuata la registrazione per il test drive di ALB-X, vi verrà presentato un URL unico per accedere alla GUI di ALB-X dal vostro browser web. Se possibile, si consiglia di utilizzare il browser Google Chrome.
- Si noti che l'accesso alla GUI avviene tramite una porta non standard :27376, in modo che la porta HTTPS standard :443 sia disponibile per l'allocazione come servizio bilanciato.
- Non preoccupatevi se vi viene presentato un avviso di sicurezza SSL: la connessione di gestione è protetta per impostazione predefinita da un certificato locale.
Per l'implementazione dal vivo sei libero di caricare il tuo certificato per confermare l'autenticità della connessione di gestione.
Quando ti viene richiesto, inserisci il tuo nome utente e la tua password unici per questa sessione di test drive (ti sono stati inviati nell'e-mail).
Configurazione del test drive di Azure
- Azure utilizza la mappatura delle porte NAT 1:1 per fornire l'accesso dallo spazio degli indirizzi IP pubblici di Internet all'indirizzo IP privato interno.
-
L'indirizzo IP configurato automaticamente sull'appliance load balancer utilizza un indirizzo IP privato di Azure.
-
Naturalmente, è possibile configurare Azure per aprire e NAT altre porte per servizi aggiuntivi.
-
Per questa demo sono state aperte solo le porte 80, 443 e 27376 (per la GUI).
ALB-X Test Drive Servizi precompilati
Poiché si tratta di un test drive personalizzato, abbiamo pre-popolato gli IP-Services con alcuni servizi che puoi provare subito. Ai fini del test drive abbiamo reso disponibili i contenuti di server reali su due server web pubblicamente disponibili:
- L'ALB-X è in grado di utilizzare il DNS per risolvere i nomi agli indirizzi IP pubblici. Ognuno di questi siti ha testi/immagini che mostrano quale sito ha servito il contenuto, in modo da poter vedere il processo di bilanciamento del carico in azione.
Abbiamo predisposto per voi 4 servizi dimostrativi:
|
Nome
|
Porto
|
Accessibilità
|
|---|---|---|
|
Bilanciamento del carico delle connessioni minime HTTP
|
80
|
http://yoururl
|
|
Offload HTTPS
|
443
|
https://yoururl
|
|
Persistenza basata su cookie
|
601
|
http://yoururl/601/
|
|
Riscrittura del test del corpo
|
602
|
http://yoururl/?602
|
Servizio sulla porta 80 - bilanciamento del carico delle connessioni HTTP minime
Il primo servizio è un bilanciatore di carico del server web di base sulla porta 80 che utilizza la nostra politica di bilanciamento del carico "con meno connessioni" verso 2 "server reali".
- Utilizzare il browser per aprire una connessione HTTP allo stesso indirizzo IP pubblico utilizzato per l'accesso alla gestione dell'ALB-X e si dovrebbe ottenere qualcosa di simile al seguente ritorno.
Servizio sulla porta 443 - Offloading SSL
Il secondo servizio è sulla porta 443. In questo caso, il bilanciatore di carico esegue la crittografia, talvolta chiamata "offload" SSL.
- Per la demo di prova abbiamo utilizzato il certificato SSL predefinito, per cui quando ci si connette a questo canale viene visualizzato lo stesso avviso di sicurezza nel browser.
Non esitate a caricare il vostro certificato SSL e ad applicarlo al servizio, vedi istruzioni più avanti. Una volta superata l'eccezione di sicurezza, si vedrà lo stesso contenuto visualizzato nel browser.
Reindirizzamento da HTTP a HTTPS
La prima cosa che possiamo vedere e che utilizza flightPATH è il reindirizzamento da HTTP a HTTPS.
Si tratta di una funzione spesso utilizzata per garantire che il traffico web venga servito tramite una connessione sicura.
- Abbiamo preconfigurato una regola flightPATH e l'abbiamo applicata al canale HTTP della porta 80 per cercare le richieste che hanno una stringa di query di: /?secure
/?secure
Se flightPATH vede questa "condizione", agirà sul traffico e restituirà un reindirizzamento 302 al browser per dirgli di eseguire un'altra richiesta GET a HTTPS://your.original.request.location che in questo caso sarà lo stesso indirizzo IP pubblico del servizio ma sul canale 443.
Si potrebbe dare un'occhiata a come è configurata la regola flightPATH.
Per farlo, fare clic sulla scheda Libreria a sinistra e selezionare flightPATH.
Facendo clic sulla voce "Forza HTTPS - quando la stringa di query è sicura" , si può vedere la schermata
- "Condizione" è Stringa di query contiene sicuro
O
- "Azione" è Redirect 302 https://$host$$path$$querystring$ ($ sono variabili utili che si possono usare nelle azioni delle regole)
Persistenza dei cookie e utilizzo del server in base al percorso
Come avrai visto, le connessioni sono state finora distribuite su entrambi i server reali: ecco perché le immagini vengono restituite sia dal server 1 sia dal server 2. Questo perché la politica di bilanciamento del carico predefinita è “meno connessioni”, che cercherà di mantenere un numero pari di connessioni a tutti i server configurati per un servizio.
- RICORDA: tutti gli oggetti di una pagina web, come immagini, video, JS, avranno ciascuno una richiesta GET separata al server web. Questo comportamento potrebbe non essere compatibile con l'applicazione, che potrebbe richiedere "persistenza" o "appiccicosità".
Per i servizi HTTP questo può essere ottenuto applicando uno speciale cookie di sessione che il browser presenterà in tutte le richieste successive a quel servizio, normalmente per il periodo della "sessione".
- Per dimostrarlo, abbiamo configurato il servizio 'interno' 601 per il bilanciamento del carico basato sui cookie di sessione ALB. Come abbiamo detto, poiché il servizio 601 non è direttamente accessibile dall'esterno della rete Azure, abbiamo utilizzato una regola flightPATH per indirizzare il traffico verso questo servizio.
La regola flightPATH esamina il percorso richiesto e se è /601/ invia il traffico al servizio che gira sulla porta 601. Ecco i dettagli di questa regola flightPATH.
Questa regola flightPATH mostra come il traffico possa essere inviato a un altro servizio in base al percorso; si tratta di uno strumento potente per la manipolazione del traffico o la gestione dei contenuti.
È possibile vedere la configurazione del VIP sulla porta 601:
- Ora provate ad aggiungere il percorso /601/ all'IP pubblico "http://myurl/601/", dovreste ottenere un risultato simile a questo:
http://myurl/601/
Si può notare che tutto il contenuto viene servito dal server 1 - si può controllare gli strumenti di sviluppo del browser e si vedrà che è stato impostato un cookie chiamato jnAccel=.
Riscrittura dei percorsi e valutazione delle RegEx
Poiché il server reale non ha alcun contenuto nel percorso /601/ , dobbiamo rimuoverlo dalla richiesta, altrimenti otterremo un errore 404 (che possiamo anche nascondere usando flightPATH).
- Questo è stato fatto applicando un'altra regola flightPATH chiamata "Rimuovi il percorso 601" al servizio in esecuzione sulla porta :601.
Anche qui cerchiamo 601 nel percorso come condizione per attivare questa regola.
- In questo caso utilizziamo la funzione di valutazione, che si avvale dell'espressione regolare per consentire la creazione di una nuova variabile manipolando una variabile di sistema esistente, in questo caso il valore Path originale che abbiamo visto.
Quindi creiamo il NewPath estraendo solo i dati dopo il prefisso di percorso /601/.
L'azione consiste nel riscrivere il percorso utilizzando $NewPath1$ e $querystring$, se presenti.
Sostituzione del testo del corpo HTML
Nell'altro esempio di servizio che utilizza la porta :602 , mostriamo come sia possibile manipolare anche il contenuto HTML e non solo l'intestazione HTTP.
- Invece di usare un percorso per indirizzare il traffico che arriva sulla porta 80 a usare il servizio 602, abbiamo usato la querystring /?602. - "http://myurl/?602"
http://myurl/?602
Se si inserisce nel browser l'indirizzo IP pubblico dell'ALB-X di prova e si aggiunge /?602 , si ottiene il seguente risultato.
È possibile vedere una riga di testo aggiuntiva in arancione che indica che -
- "Questo testo è stato aggiunto da flightPATH".
Ciò si ottiene mediante 2 regole flightPATH.
La regola seguente, applicata alla porta 80, cerca un valore di stringa di query pari a 602 e invia tutte le richieste corrispondenti al servizio in esecuzione sulla porta 602.
Applicata al servizio in esecuzione sulla porta :602 è una regola flightPATH che esegue una funzione "Body Replace Last" alla ricerca del tag body di chiusura
</body>
e sostituirlo con
<font face=’Arial’ size=’6′ color=’orange’><center>This text has been added by flightPATH</center></font></body>
In questo caso non è richiesta alcuna condizione o valutazione, quindi la funzione si applica a tutto il traffico che passa attraverso il servizio.
Si spera che possiate vedere come altre strutture possano essere combinate per eseguire una manipolazione intelligente del traffico HTTP e queste sono solo la punta dell'iceberg di ciò che flightPATH può fare.
Sperimentate voi stessi e saremo lieti di conoscere le vostre esigenze specifiche.
Controlli sullo stato di salute del server reale
La prossima cosa che vedremo è il controllo dello stato di salute del server. È fondamentale applicare il giusto tipo di controllo dello stato di salute a un servizio per consentire un rilevamento affidabile dello stato di salute dei server di back end, in modo da garantire che il traffico dei clienti venga inviato solo ai server operativi.
Quando si crea un nuovo servizio, è necessario definire un insieme di parametri predefiniti. Per il monitoraggio del server si utilizza il controllo dello stato di salute della connessione TCP. L'opzione Monitoraggio server si trova nella scheda Base del servizio da configurare.
Sebbene questo sia un punto di partenza ragionevole, si raccomanda vivamente di configurare e applicare a un servizio un controllo di salute più affidabile; abbiamo reso super facile creare controlli di salute HTTP personalizzati.
- Il controllo dello stato di salute si trova in "Libreria / Monitor del server reale".
Nel Test Drive abbiamo aggiunto un terzo Real Server Monitor per mostrare un esempio di controllo della salute della risposta HTTP.
HTTP 200 OK Metodo di monitoraggio
200OK Utilizza una richiesta HTTP GET alla posizione della pagina configurata per il controllo e si assicura che venga restituita una risposta di stato 200OK.
Non cerca alcun contenuto specifico, ma si limita a verificare che un server web sia in esecuzione sulla porta e sia in grado di servire la pagina richiesta.
- Si tratta di un monitoraggio migliore rispetto alla Connessione TCP, in quanto opera a livello 7 controllando che l'applicazione sia in esecuzione, ma non controlla la risposta specifica del contenuto restituito.
Come si può vedere sopra, abbiamo applicato questo monitor al servizio in esecuzione sulla porta 601.
Metodo di monitoraggio delle risposte HTTP
Il monitor NLS configurato nel Test Drive utilizza il controllo HTTP Response.
A tale scopo, si definisce la posizione specifica della pagina (può essere l'URL completo, se sono necessarie le intestazioni dell'host) e si definisce il contenuto (una stringa di testo) che deve essere presente nei dati restituiti dal server/applicazione.
Si tratta di un test di gran lunga migliore, poiché la pagina deve essere presente e il contenuto specifico deve essere disponibile.
- Se l'applicazione è collegata a un database di back end, è bene che lo stato dei contenuti recuperati nella pagina di controllo dello stato di salute dipenda dalle risposte in tempo reale del database piuttosto che dal contenuto statico del server web di front end.
Si può notare che il monitor è stato applicato al servizio in esecuzione sulla porta:602.
È possibile modificare il testo nel campo Contenuto richiesto per questo controllo di salute e si vedrà che i server diventano rossi per indicare che non hanno superato il controllo di salute. Riportare il contenuto richiesto al valore corretto e i server torneranno verdi.
Intervallo di monitoraggio
Nella scheda avanzata è possibile manipolare la frequenza, il time out e così via per l'operazione di controllo dello stato di salute di quel servizio.
Per il test drive abbiamo impostato l'intervallo di monitoraggio su 3 secondi con un time out di 2 secondi.
Il conteggio di uscita dal monitoraggio è impostato su 3, quindi deve fallire nel ricevere 3 risposte consecutive prima di contrassegnare il server come irraggiungibile.
- Con un conteggio Monitor In di 2, devono esserci 2 risposte consecutive di successo prima che il server venga rimesso in servizio. Si tratta di valori ragionevoli da utilizzare nella maggior parte dei casi.
HTTPS e certificati SSL
Sempre più siti web utilizzano l'HTTPS e all'inizio del 2017 la percentuale si è spostata a favore dell'HTTPS.
La maggior parte delle applicazioni aziendali richiede una protezione attraverso la crittografia, quindi è abbastanza sicuro che sarà necessario utilizzare i certificati su ALB-X e l'implementazione di un bilanciatore di carico con HTTPS è un modo rapido e semplice per proteggere l'accesso alle applicazioni non crittografate.
- L'ALB-X ha un certificato privato installato di default, chiamato "default", che viene usato per consentire la connettività HTTPS alla GUI di gestione. Abbiamo applicato questo certificato al servizio Test Drive :443 HTTPS configurato sul servizio virtuale o sul lato client.
Il servizio è configurato per l'offload SSL e quindi il lato Real Server è configurato per No SSL.
Caricamento/importazione del certificato
È possibile caricare i propri certificati firmati sull'ALB-X utilizzando il menu Certificati SSL nella sezione Libreria.
Come evidenziato nei campi di immissione del testo, il certificato deve essere in formato PKCS#12 per essere importato in ALB-X.
- Questo tipo di certificato contiene la chiave privata ed è protetto da una password che viene richiesta al momento dell'importazione.
Il nome (che non deve contenere spazi) assegnato al certificato al momento dell'importazione sarà quello che apparirà nei menu a tendina di selezione del certificato nella scheda Servizio IP di base.
Crittografia del server reale
Se i server reali richiedono la ricrittografia SSL/TLS, l'opzione più sensata da selezionare è "Qualsiasi" dal menu a tendina Certificato SSL del server reale.
- Ciò significa che l'ALB-X accetterà qualsiasi certificato presentato dai server reali come valido.
SNI (Indicazione del nome del server)
Con la scarsità di indirizzi IP pubblici e il fatto che in Azure è possibile configurare un solo VIP, è utile poter supportare più domini sicuri / URL host attraverso un unico servizio virtuale e questo è possibile su ALB-X perché supportiamo l'SNI.
- Per utilizzare SNI è sufficiente selezionare tutti i certificati necessari dalla casella a discesa Virtual Service SSL Certificate. Ogni clic selezionerà o deselezionerà il certificato come parte dell'elenco SNI.
Sul lato Real Server, se i servizi vengono ricrittografati e ospitati su server comuni, richiederanno l'SNI per la corretta identificazione e negoziazione del servizio, quindi l'opzione SNI deve essere selezionata nel menu a tendina del Certificato SSL Real Server.
Applicazioni
ALB-X supporta la distribuzione di caratteristiche e funzionalità aggiuntive acquistando e scaricando applicazioni dal nostro App Store per la distribuzione all'interno dell'ambiente containerizzato ALB-X.
- I primi due add-on chiave disponibili sono un Web Application Firewall e un Global Server Load Balancing per la ridondanza automatizzata del data center e il failover/bilanciamento del carico del cloud ibrido.
Abbiamo allestito 2 test drive separati in Azure dove è possibile vedere questa funzionalità in funzione, quindi vi invitiamo a controllarli se siete interessati.
Autenticazione
ALB-X supporta la pre-autenticazione in combinazione con un server MS AD (Microsoft Active Directory) / LDAP.
- Siete liberi di esplorare questa funzionalità se avete accesso a un server MS AD / LDAP pubblicamente accessibile (utilizzate LDAP). La guida online dell'ALB-X illustra la configurazione di questa funzione.
Questa funzionalità è una popolare sostituzione del prodotto TMG di Microsoft, ormai in disuso.
Monitoraggio dell'utilizzo dell'apparecchio e delle connessioni
La sezione del menu dedicata alla visualizzazione offre la possibilità di vedere lo stato di connessione e lo stato di salute del server reale in tempo reale (Stato) o come tendenza nel tempo (Cronologia).
- Qui si trovano anche i registri W3C e di sistema. È inoltre possibile creare widget personalizzati da visualizzare nella Dashboard. Vi invitiamo a dare un'occhiata alle varie opzioni presenti in questa sezione.
Sistema
Qui si trovano le opzioni di configurazione relative alle funzioni del sistema, come l'impostazione di data e ora, l'abilitazione degli avvisi e-mail, la concessione di licenze al prodotto, la scelta della modalità di registrazione e dell'invio dei log, il riavvio e il riavvio del dispositivo, la configurazione di SNMP e l'aggiunta di altri utenti di gestione, ecc.
Avanzato
Nel menu avanzato è possibile eseguire il backup e il ripristino della configurazione e anche caricare le configurazioni dei modelli jetPACK.
- È possibile modificare il comportamento del protocollo HTTP comune ed eseguire l'aggiornamento del software e scaricare altri pacchetti software dalla libreria cloud.
Infine, c'è una sezione dedicata alla risoluzione dei problemi in cui abbiamo semplificato il download di un pacchetto di file di supporto, l'esecuzione di PING di rete e l'esecuzione di varie tracce di sistema e catture di pacchetti di rete.
Grazie.
- Vi auguriamo di godervi il vostro test drive dell'ALB-X.
Saremo lieti di rispondere a tutte le vostre domande all'indirizzo pre-sales@edgenexus.io.
Non ci creda sulla parola - faccia una prova gratuita
Hardware, software o anche la tua immagine online completa di un ambiente di prova completo.
Facci sapere di cosa hai bisogno qui
Copyright © 2021 Edgenexus Limited.