Questa edizione si applica a:
e a tutte le release e modifiche successive se non diversamente specificato in nuove edizioni.
Ordinare le pubblicazioni mediante il rappresentante IBM o gli uffici IBM del proprio paese.
Questo guida, Informazioni di base, pianificazione e installazione per WebSphere Application Server Edge Components, è un'introduzione ai componenti Edge Components di WebSphere Application Server. Esso contiene delle panoramiche generali sui prodotti, discussioni dettagliate sulla funzionalità dei componenti fondamentali, scenari edge-of-the-network, informazioni sull'installazione e sulla configurazione iniziale e reti dimostrative.
Il documento Informazioni di base, pianificazione e installazione per WebSphere Application Server Edge Components è stato scritto per amministratori di sistema e di rete esperti, che abbiamo una certa familiarità con i sistemi operativi e con la fornitura di servizi Internet. Non è richiesta esperienza di WebSphere Application Server o di Edge Components di WebSphere Application Server.
Le funzioni di accessibilità consentono a un utente con svantaggi fisici, quali una mobilità o una vista limitata, di utilizzare agevolmente prodotti software. Si tratta delle principali funzioni di accessibilità contenute in WebSphere Application Server, Versione 6.1:
Questa documentazione utilizza le seguenti convenzioni tipografiche e di definizione dei tasti.
Convenzione | Significato |
---|---|
Grassetto | Quando si fa riferimento alle interfacce utente grafiche (GUI, Graphical User Interfaces), il grassetto evidenzia menu, voci di menu, etichette, pulsanti, icone e cartelle. Inoltre, può essere utilizzato per enfatizzare i nomi di comandi che, altrimenti, verrebbero confusi con il testo circostante. |
A spaziatura fissa | Indica il testo da inserire davanti a un prompt di comandi. Inoltre, indica il testo su video, gli esempi di codice ed estratti di file. |
Corsivo | Indica i valori delle variabili che l'utente deve inserire (ad esempio, il nome sostituire nomeFile con il nome effettivo di un file). Il corsivo viene inoltre utilizzato per enfatizzare un concetto ed evidenziare i titoli di manuali. |
Ctrl-x | Dove x è il nome di un tasto, indica una sequenza di caratteri di controllo. Ad esempio, Ctrl-c indica: tenere premuto il tasto Ctrl e contemporaneamente premere il tasto c. |
Invio | Indica il tasto etichettato con la parola Invio, Enter, Return o con una freccia verso sinistra. |
% | Rappresenta il prompt della shell dei comandi in ambiente Linux e UNIX per un comando che non richiede privilegi root. |
# | Rappresenta il prompt della shell dei comandi in ambiente Linux e UNIX per un comando che richiede privilegi root. |
C:\ | Rappresenta il prompt dei comandi in ambiente Windows. |
Immissione di comandi | Quando si invita l'utente a "immettere" o "inserire" un comando, digitare il comando e premere Invio. Ad esempio, l'istruzione "Immettere il comando ls" indica: digitare ls al prompt dei comandi e premere Invio. |
[ ] | Racchiude le voci facoltative nelle descrizioni della sintassi. |
{ } | Racchiude gli elenchi da cui è necessario scegliere una voce nelle descrizioni della sintassi. |
| | Separa le voci in un elenco di opzioni racchiuse tra parentesi { } nelle descrizioni della sintassi. |
... | I puntini di sospensione nelle descrizioni della sintassi indicano che è possibile ripetere la voce precedente una o più volte. Negli esempi, indicano che le informazioni sono state omesse dall'esempio per motivi di brevità. |
Questa sezione introduce i componenti Edge Components di WebSphere Application Server, ossia Caching Proxy e Load Balancer e ne descrive l'integrazione con Application Server. Definisce inoltre i componenti di Caching Proxy e Load Balancer. In più, introduce altri prodotti correlati della famiglia WebSphere.
Questa sezione contiene i seguenti capitoli:
WebSphere è un software per l'infrastruttura Internet che consente alla aziende di sviluppare, distribuire e integrare applicazioni e-business di nuova generazione come le applicazioni specifiche per e-commerce B2B (business-to-business). Il software middleware WebSphere supporta vari tipi di applicazioni aziendali, dalla semplice pubblicazione su Web all'elaborazione di transazioni su scala aziendale.
Come base della piattaforma WebSphere, WebSphere Application Server offre una serie completa di middleware che consente all'utente di progettare, implementare, distribuire e gestire applicazioni aziendali. Si tratta di applicazioni di vario tipo, dalla semplice vetrina di un sito Web alla modifica completa dell'infrastruttura informatica di un'azienda.
Funzioni che richiedono un impiego intensivo del processore, quali la personalizzazione, conferiscono vantaggi competitivi alle attività e-business. Tuttavia, confinando abitualmente queste funzioni sui server centrali, si corre il rischio di non poterle adeguare correttamente alle effettive proporzioni di Internet. Di conseguenza, con l'aggiunta costante di nuove applicazioni Web, l'infrastruttura Internet di un'azienda può crescere notevolmente, sia in termini di ambito che di impatto. Inoltre, l'affidabilità e la sicurezza sono fattori di vitale importanza per l'e-business. Anche una minima interruzione del servizio può causare perdite rilevanti.
I componenti di Edge Components (in precedenza Edge Server) sono stati ora integrati nell'offerta WebSphere Application Server. I componenti di Edge Components possono essere utilizzati insieme a WebSphere Application Server per controllare l'accesso dei client ai server Web e per consentire alle aziende di offrire un miglior servizio ai clienti che accedono ai contenuti basati su Web tramite Internet o mediante un rete intranet aziendale. Grazie all'uso di Edge Components è possibile ridurre la congestione sul Web, aumentare la disponibilità dei contenuti e migliorare le prestazioni del server Web. Come il nome stesso suggerisce, Edge Components viene normalmente eseguito su macchine molto vicine (in termini di configurazione di rete) nell'area che segna il limite tra una rete intranet aziendale e Internet.
WebSphere Application Server include Caching Proxy e Load Balancer Edge Components.
IMPORTANTE: Caching Proxy è disponibile su tutte le installazioni Edge Components, con le seguenti eccezioni:
Caching Proxy riduce l'utilizzo della larghezza di banda e migliora la velocità e l'affidabilità di un sito Web fornendo un nodo POP (point-of-presence) per uno o più server di contenuti back-end. Caching Proxy è in grado di memorizzare nella cache e supportare contenuti statici e contenuti generati in modo dinamico da WebSphere Application Server.
Caching Proxy può essere configurato come server proxy inverso (configurazione predefinita) p come server proxy diretto, fornendo in questo modo sia un punto di presenza su una rete che un server di rete interno associato alle richieste e ai tempi di risposta. Per ulteriori informazioni sulle configurazioni inverse e dirette, fare riferimento a Configurazioni di base di Caching Proxy.
Il server proxy intercetta le richieste dati da un client, richiama le informazioni necessarie dalle macchine su cui risiedono i contenuti e restituisce il contenuto al client. Nella maggior parte dei casi, si tratta di richieste per documenti memorizzati sui server Web (noti anche come server di origine o host di contenuti) che vengono distribuiti mediante il protocollo HTTP (Hypertext Transfer Protocol). Tuttavia, è possibile configurare il server proxy in modo da gestire altri protocolli, quali FTP (File Transfer Protocol) e Gopher.
Il server proxy memorizza il contenuto che può essere archiviato in una cache locale prima di distribuirlo al richiedente. Tra i contenuti memorizzabili nella cache sono inclusi pagine Web e file JSP (JavaServer Pages) contenenti informazioni generate dinamicamente ma che di rado subiscono delle modifiche. La memorizzazione nella cache consente al server proxy di soddisfare le successive richieste degli stessi contenuti prelevandoli direttamente dalla cache locale, ossia una procedura molto più veloce rispetto a quella che prevede di richiamarli nuovamente dall'host dei contenuti.
I plug-in di Caching Proxy aumentano la funzionalità di server proxy.
È possibile estendere ulteriormente le funzioni di Caching Proxy scrivendo moduli plug-in personalizzati in un'interfaccia di programmazione (API). L'API è un'interfaccia flessibile, facile da utilizzare e indipendente dalla piattaforma. Il proxy esegue una sequenza di operazioni per ciascuna richiesta client elaborata. Un'applicazione plug-in modifica o sostituisce una fase all'interno del flusso di elaborazione delle richieste, come l'autenticazione di un client o il filtro di una richiesta. La potente interfaccia Transmogrify, ad esempio, consente di accedere ai dati HTTP e di sostituire o trasformare URL e contenuti Web. I plug-in possono modificare o sostituire fasi di elaborazione designate; inoltre, è possibile richiamare più di un plug-in per una specifica fase.
Load Balancer crea sistemi edge-of-network, ai limiti della rete, che gestiscono il traffico di rete, riducendo la congestione e bilanciando il carico su diversi altri servizi e sistemi. Load Balancer consente di selezionare siti, gestire carichi di lavoro, valutare affinità di sessione ed eseguire failover trasparenti.
Load Balancer viene installato tra i server Internet e back-end dell'azienda, che possono essere host di contenuti o macchine Caching Proxy. Load Balancer funge da singolo nodo POP (point-of-presence) aziendale su Internet, anche se l'azienda dovesse utilizzare più server back-end a causa di una forte domanda o di una notevole quantità di contenuti. È inoltre possibile garantire l'elevata disponibilità installando un Load Balancer di backup, che assuma il controllo in caso di errore temporaneo di quello principale.
Load Balancer intercetta le richieste dati dai client e inoltra ciascuna richiesta al server attualmente ritenuto il più adatto a soddisfarle. In altre parole, bilancia il carico delle richieste in entrata tra una serie definita di macchine che supportano lo stesso tipo di richieste. Load Balancer può distribuire le richieste a molti tipi di server, tra cui macchine WebSphere Application Server e Caching Proxy. Il bilanciamento del carico può essere personalizzato per una particolare applicazione o piattaforma mediante advisor personalizzati. Sono disponibili advisor destinati a scopi speciali, per ottenere informazioni per il bilanciamento del carico di WebSphere Application Server.
Se il componente CBR (Content Based Routing) viene installato insieme a Caching Proxy, le richieste HTTP e HTTPS possono essere distribuite anche in base agli URL o ad altre caratteristiche stabilite dall'amministratore, eliminando la necessità di memorizzare contenuti identici su tutti i server back-end. Il componente Dispatcher può inoltre offrire la stessa funzione per le richieste HTTP.
Il bilanciamento del carico migliora la disponibilità e la scalabilità di un sito Web organizzando in cluster, in modo trasparente, i server di contenuti, tra cui server HTTP, server delle applicazioni e server proxy, ossia server di contenuti sostitutivi. La disponibilità può essere ottenuta mediante parallelismo, bilanciamento del carico e supporto failover. Quando un server subisce un guasto, l'attività commerciale non si interrompe. La scalabilità di un'infrastruttura viene di gran lunga migliorata dal momento che la potenza dell'elaborazione back-end può essere aggiunta in modo trasparente.
Supporto per IPv6: il supporto per lo schema di indirizzamento IP esteso di IPv6 è disponibile con "Load Balancer per IPv4 e IPv6." Load Balancer per IPv4 e IPv6 è un'immagine di installazione separata costituita esclusivamente dal componente Dispatcher. Questo tipo di installazione fornisce il bilanciamento del carico per il traffico IPv4 e IPv6 ai server configurati nella rete che utilizzano l'inoltro del pacchetto basato su MAC di Dispatcher'. È importante disinstallare la precedente versione di Load Balancer prima di installare Load Balancer per IPv4 e IPv6. Due versioni di Load Balancer non possono essere presenti sulla stessa macchina. (Consultare Dispatcher per una breve panoramica del componente Dispatcher).
Load Balancer prevede i seguenti componenti:
Per tutti i servizi Internet, quali HTTP, FTP, HTTPS e Telnet, il componente Dispatcher esegue il bilanciamento del carico tra i server della LAN o della WAN. Per i servizi HTTP, Dispatcher può eseguire il bilanciamento del carico di server in base al contenuto URL della richiesta client.
Il componente Dispatcher consente di gestire in modo stabile ed efficiente una rete ampia e scalabile di server. Con il Dispatcher, è possibile collegare molti server in modo da farli sembrare un solo server virtuale. Quindi il sito sembrerà avere un unico indirizzo IP.
Se si sta utilizzando un'installazione Load Balancer per IPv4 e IPv6, vedere il capitolo relativo alla distribuzione di Dispatcher su Load Balancer per IPv4 e IPv6 nella Guida alla gestione per WebSphere Application Server Load Balancer, che include le informazioni sulle limitazioni e le differenze di configurazione.
Per i servizi HTTP e HTTPS, il componente CBR (Content Based Routing) esegue il bilanciamento del carico per i server in base al contenuto della richiesta client. Questo componente lavora in associazione con il componente Application Server Caching Proxy.
IMPORTANTE: il componente CBR (Content Based Routing) è disponibile su tutte le piattaforme supportate con le seguenti eccezioni:
In alternativa, per questo tipo di installazione è possibile utilizzare il metodo di inoltro cbr del componente Load Balancer' Dispatcher per consentire l'instradamento basato sul contenuto di richieste HTTP e HTTPS senza utilizzare Caching Proxy. Consultare Guida alla gestione per Load Balancer di WebSphere Application Server per ulteriori informazioni.
Load Balancer per IPv4 e IPv6 supporta esclusivamente il metodo di inoltro mac del componente' Dispatcher. I metodi di inoltro nat e cbr non sono supportati.
Il componente Site Selector migliora un sistema di bilanciamento del carico facendo in modo che funzioni come un nodo POP (point-of-presence) per la rete e che esegua il bilanciamento del carico delle richieste in entrata eseguendo la mappatura dei nomi DNS sugli indirizzi IP. Insieme a Metric Server, Site Selector può monitorare il livello di attività su un server, rilevare un server che sta elaborando un carico inferiore rispetto agli altri e individuare un server in errore.
Questo componente è supportato su tutte le installazioni di Edge Components, con la seguente eccezione:
Il componente Cisco CSS Controller genera delle metriche di misurazione del carico dei server e le invia a uno switch Cisco CSS che le utilizzerà per selezionare i server, ottimizzare i carichi di lavoro e aumentare la tolleranza agli errori.
Questo componente è supportato su tutte le installazioni di Edge Components, con la seguente eccezione:
Il componente Nortel Alteon Controller genera delle metriche di misurazione del carico dei server e le invia a uno switch Nortel Alteon che le utilizzerà per selezionare i server, ottimizzare i carichi di lavoro e aumentare la tolleranza agli errori.
Questo componente è supportato su tutte le installazioni di Edge Components, con la seguente eccezione:
IL componente Metric Server è in esecuzione come daemon su un server con bilanciamento del carico e fornisce informazioni relative ai carichi di sistema sui componenti Load Balancer.
La famiglia IBM WebSphere è stata ideata per aiutare gli utenti a realizzare concretamente i loro progetti e-business. Si tratta di un set di prodotti software in grado di aiutare gli utenti a sviluppare e gestire siti Web con prestazioni elevate e integrare siti Web con sistemi informativi aziendali non Web, nuovi o preesistenti.
La famiglia WebSphere comprende WebSphere Application Server, tra cui Edge Components e altro software della linea WebSphere che si integra perfettamente con WebSphere Application Server migliorandone le prestazioni. Per una panoramica di WebSphere Application Server e dei relativi componenti, consultare Introduzione a WebSphere Application Server Edge Components.
Tivoli Access Manager (in precedenza Tivoli Policy Director) è disponibile separatamente. Questo prodotto consente di controllare gli accessi, proteggere a livello centralizzato le applicazioni Web esistenti e offrire l'accesso a numerose risorse Web mediante una sola autenticazione. Un plug-in Caching Proxy utilizza il framework di sicurezza di Access Manager, consentendo al server proxy di adoperare i servizi di autorizzazione e autenticazione integrati di Access Manager.
WebSphere Portal Server (disponibile separatamente) offre un framework in grado di affrontare problemi associati ai portali relativamente a presentazione, sicurezza, scalabilità e disponibilità. Mediante Portal Server, le aziende potranno creare portali personalizzati in grado di soddisfare le esigenze di dipendenti, business partner e clienti. Gli utenti potranno collegarsi al portale e ricevere pagine Web personalizzate che consentiranno loro di entrare in contatto con altri utenti e accedere alle informazioni e alle applicazioni desiderate. Questo singolo punto di accesso personalizzato a tutte le risorse necessarie riduce il sovraccarico di informazioni, accelera la produttività e incrementa l'uso del sito.
WebSphere Portal Server è in esecuzione in un cluster di WebSphere Application Server per assicurare scalabilità e affidabilità. Il componente Application Server Load Balancer può inoltre essere utilizzato per ottenere un ulteriore bilanciamento del carico e un'elevata disponibilità.
WebSphere Site Analyzer (disponibile separatamente) consente alle aziende di prevenire problemi relativi a capacità e prestazioni. Con Site Analyzer, è possibile utilizzare i log di Caching Proxy e Load Balancer e altri supporti utili per prevedere un aumento delle richieste di risorse mediante il monitoraggio, l'analisi e la creazione di report sull'uso del sito Web. Inoltre, con i componenti di Site Analyzer, gli utenti che devono installare e aggiornare Edge Components potranno usufruire di un valido aiuto per gestire e memorizzare configurazioni, attivare Edge Components da remoto, visualizzare e documentare eventi.
WebSphere Transcoding Publisher (disponibile separatamente) può convertire una pagina Web in modo da visualizzarla su un dispositivo mobile, come un telefono con dotato di accesso a Internet, tradurre i contenuti Web nella lingua preferita dall'utente (richiamando WebSphere Translation Server) e convertire linguaggi di markup. Transcoding Publisher aumenta le capacità di Caching Proxy poiché consente di supportare il contenuto per diversi utenti e dispositivi. Dopo aver ricevuto i contenuti da un server Web, è possibile configurare l'interfaccia Transmogrify di Caching Proxy per richiamare Transcoding Publisher e convertire i dati e contrassegnarli, per memorizzarli nella cache e utilizzarli in futuro. Sull'interfaccia di post-autenticazione di Caching Proxy, Transcoding Publisher verifica che sul server proxy i requisiti del dispositivo corrispondano a quelli dell'utente e, in caso affermativo, invia il contenuto prelevandolo dalla cache del server proxy.
La documentazione riportata di seguito, specifica per WebSphere Application Server Edge Components, è disponibile presso il centro informazioni di Edge Components.
Altra documentazione relativa a WebSphere Application Server è disponibile alla pagina delle librerie di WebSphere Application Server.
Le informazioni relative al supporto Technote su Edge Components sono disponibili alla pagina del supporto di WebSphere Application Server.
Di seguito è riportato un elenco di siti Web utili per ottenere informazioni su Edge Components o altro materiale correlato:
Questa sezione include informazioni dettagliate che mettono in risalto alcune delle funzionalità offerte dai componenti Edge. Consultare Introduzione a WebSphere Application Server Edge Components per una panoramica del componente Caching Proxy di Application Server.
Questa sezione contiene i seguenti capitoli:
La funzionalità di memorizzazione nella cache di Caching Proxy consente di ridurre notevolmente l'utilizzo della larghezza di banda della rete e di offrire agli utenti finali un servizio molto più veloce e affidabile. Ciò è possibile grazie alla memorizzazione nella cache eseguita dai collegamenti peer e dai server di backend che ripartiscono il carico di lavoro del server proxy. Caching Proxy è in grado di memorizzare nella cache contenuti statici e contenuti generati in modo dinamico da WebSphere Application Server. Al fine di ottenere una funzione di memorizzazione nella cache ancora più potente, Caching Proxy può lavorare anche con il componente Application Server, Load Balancer. Consultare Introduzione a WebSphere Application Server Edge Components per un'introduzione a questi sistemi.
IMPORTANTE: Caching Proxy è disponibile su tutte le installazioni Edge Components, con le seguenti eccezioni:
Caching Proxy può essere configurato come server caching proxy inverso (configurazione predefinita) o come server caching proxy diretto. Se utilizzato da host di contenuto, Caching Proxy viene configurato come server caching proxy inverso, ubicato tra Internet e gli host di contenuto dell'azienda. Se utilizzato dai provider di accesso a Internet, Caching Proxy viene invece configurato come server caching proxy diretto, tra un client e Internet.
Quando si utilizza una configurazione di proxy inverso, le macchine di Caching Proxy sono ubicate tra Internet e gli host di contenuto dell'azienda. Come sostituto, server proxy intercetta le richieste degli utenti provenienti da Internet, le inoltra all'host di contenuti appropriato, memorizza nella cache i dati restituiti e li distribuisce agli utenti su Internet. La memorizzazione nella cache consente a Caching Proxy di soddisfare le successive richieste, relative al medesimo contenuto, direttamente dalla cache, un metodo molto più veloce rispetto a quello che prevede di richiamarlo nuovamente dall'host di contenuti. Le informazioni possono essere memorizzate nella cache in base alla data di scadenza, alla dimensione della cache e alla data prevista per il loro aggiornamento. Tempi di download più veloci per gli accessi alla cache corrispondono a una maggiore qualità del servizio per i clienti. La Figura 1 illustra questa funzionalità fondamentale di Caching Proxy.
Legenda: 1--Client 2--Internet 3--Router/Gateway 4--Caching Proxy 5--Cache 6--Host dei contenutiIn questa configurazione, il server proxy (4) intercetta le richieste i cui URL contengono il nome dell'host di contenuti ( 6). Quando un client (1) richiede un file X, la richiesta passa attraverso Internet (2) ed entra nella rete interna dell'azienda mediante il gateway Internet ( 3). Il server proxy intercetta la richiesta e ne genera una nuova con il proprio indirizzo IP e quello di origine e la invia all'host di contenuti (6).
L'host di contenuti restituisce il file X al server proxy anziché inviarlo direttamente all'utente finale. Se il file è memorizzabile nella cache, il Caching Proxy lo copia nella propria cache (5) prima di inviarlo all'utente finale. L'esempio più rilevante di contenuto memorizzabile nella cache è rappresentato dalle pagine Web statiche; tuttavia Caching Proxy consente di memorizzare nella cache e di supportare anche i contenuti dinamici generati da WebSphere Application Server.
L'accesso a Internet degli utenti finali può non essere efficiente. Ogni utente che utilizza un determinato file da un server Web genera la stessa quantità di traffico sulla rete e mediante il gateway Internet del primo utente che ha utilizzato il file, anche se il file non è stato modificato. La soluzione consiste nell'installare un Caching Proxy diretto sul gateway.
Quando si utilizza una configurazione di proxy diretto, le macchine di Caching Proxy sono ubicate tra il client e Internet. Caching Proxy inoltra la richiesta di un client agli host del contenuto su Internet, memorizza nella cache i dati richiamati e distribuisce i dati richiamati sul client.
Figura 2 illustra la configurazione Caching Proxy diretta. I browser dei client (sulle macchine 1) sono configurati per indirizzare le richieste al caching proxy diretto (2), configurato per intercettare le richieste. Quando un utente finale richiede il file X memorizzato sull'host del contenuto (6), il caching proxy diretto intercetta la richiesta, genera una nuova richiesta con il proprio indirizzo IP come indirizzo di origine e invia la nuova richiesta mediante il router dell'azienda (4) su Internet (5).
In questo modo, il server di origine restituisce il file X al caching proxy diretto piuttosto che direttamente all'utente finale. Se la funzione di memorizzazione nella cache del Caching Proxy diretto è abilitata, Caching Proxy determina se il file X può essere memorizzato nella cache controllandone le impostazioni nell'intestazione di restituzione, come ad esempio la data di scadenza e un'indicazione se il file è stato generato dinamicamente. Se il file può essere memorizzato nella cache, il Caching Proxy ne memorizza una copia nella cache (3) prima di inviarlo all'utente finale. Per impostazione predefinita, la memorizzazione nella cache è abilitata e il Caching Proxy diretto utilizza una cache di memoria; tuttavia, è possibile configurare altri tipi di memorizzazione nella cache.
Per la prima richiesta del file X, il Caching Proxy diretto non migliora di molto l'efficienza dell'accesso a Internet. In realtà, il tempo di risposta per il primo utente che accede al file X è probabilmente inferiore rispetto al tempo che si avrebbe senza il caching proxy diretto, in quanto è necessario più tempo perché il Caching Proxy diretto elabori il pacchetto di richieste originale ed esamini l'intestazione del file X relativamente alle informazioni sulla memorizzazione nella cache una volta ricevuto il file. L'utilizzo del caching proxy diretto porta a dei vantaggi quando altri utenti richiedono successivamente il file X. Il Caching Proxy diretto controlla che la propria copia memorizzata nella cache del file X sia ancora valida (ovvero che non sia scaduta) ed eventualmente lo utilizza direttamente dalla cache, senza inoltrare le richiestra su Internet all'host del contenuto.
Anche se il Caching Proxy diretto rileva che un file richiesto è scaduto, il proxy non necessariamente riutilizzare il file dall'host del contenuto. Invece invia un messaggio di controllo di stato speciale all'host del contenuto. Se l'host indica che il file non è stato modificato, il caching proxy diretto può consegnare la versione memorizzata nella cache all'utente richiedente.
La configurazione del Caching Proxy diretto in questo modo è detta proxy diretto, in quantoCaching Proxy opera per conto dei browser, inoltrando le richieste agli host del contenuto via Internet. I vantaggi dell'utilizzo di un proxy diretto con la memorizzazione nella cache sono di due tipi:
Il Caching Proxy può utilizzare diversi protocolli di trasferimento di rete, compreso HTTP (Hypertext Transfer Protocol, FTP (File Transfer Protocol) e Gopher.
Una variazione di Caching Proxy diretto è un Caching Proxy trasparente. In questo ruolo, il Caching Proxy esegue le stesse funzioni di un Caching Proxy diretto di base, ma le esegue senza che il client si accorga della sua presenza. La configurazione trasparente di Caching Proxy è supportata solo su sistemi Linux.
Nella configurazione descritta in Caching Proxy diretto, ogni browser del client viene configurato separatamente in modo da indirizzare le richieste a un determinato Caching Proxy diretto. la presenza di una tale configurazione può diventare sconveniente, specialmente per un numero elevato di macchine client. Il Caching Proxy supporta diverse alternative che semplificano la gestione. Una possibilità consiste nel configurare il Caching Proxy per il proxy trasparente come illustrato in Figura 3. Come con il Caching Proxy diretto regolare, il Caching Proxy trasparente viene installato su una macchina del gateway, ma i browser del client non sono configurati per indirizzare le richieste a un Caching Proxy diretto. I client non sono a conoscenza della presenza di un proxy nella configurazione. Invece, è configurato un router che intercetta le richieste dei client e le indirizza al Caching Proxy trasparente. Quando un client su una di queste macchine, detto 1, richiede il file X memorizzato sull'host del contenuto (6), il router (2) invia la richiesta al Caching Proxy. Caching Proxy genera una nuova richiesta con il proprio indirizzo IP come indirizzo di origine e la invia mediante il router (2) su Internet (5). Quando il file X arriva, il Caching Proxy lo memorizza nella cache come appropriato (in base alle condizioni descritte in Caching Proxy diretto) e lo invia al client richiedente.
Per le richieste HTTP, un'altra possibile alternativa a conservare le informazioni di configurazione proxy su ciascun browser consiste nell'utilizzare la configurazione proxy automatica disponibile in diversi browser, tra cui Netscape Navigator versione 2.0 e superiore e Microsoft Internet Explorer versione 4.0 e superiore. In questo caso, viene creata una o più configurazione automatica del proxy centrale (proxy automatic configuration, PAC) e vengono configurati i browser in modo da fare riferimento a una di queste configurazione piuttosto che alle informazioni di configurazione del proxy locale. Il browser invia automaticamente una notifica delle modifiche apportate alla PAC e regola l'utilizzo del proxy di conseguenza. Ciò non solo elimina la necessità di mantenere informazioni sulle configurazioni separate su ogni browser, ma semplifica anche il reindirizzamento delle richieste quando un server proxy diventa non disponibile.
Una terza alternativa consiste nell'utilizzare il meccanismo Web Proxy Auto Discovery (WPAD) disponibile in alcuni browser, come Internet Explorer versione 5.0 e superiore. Quando si abilita questa funzione sul browser, questo individua automaticamente un server proxy conforme a WPAD sulla rete e vi indirizza le richieste Web. Non è necessario conservare i file di configurazione proxy centrale in questo caso. Caching Proxy è conforme a WPAD.
Al fine di fornire una funzionalità di memorizzazione nella cache più avanzata, utilizzare Caching Proxy insieme al componente Load Balancer. Mediante l'integrazione di funzioni di memorizzazione nella cache e di bilanciamento del carico, è possibile creare un'infrastruttura con prestazioni Web estremamente gestibile ed efficiente.
La Figura 4 illustra in che modo è possibile combinare Caching Proxy con Load Balancer per distribuire contenuti Web in modo efficiente anche in caso di forte domanda. In questa configurazione, il server proxy (4) è configurato per intercettare le richieste i cui URL contengono il nome host di un cluster di host di contenuti (7) con bilanciamento del carico da parte di Load Balancer (6 ).
Legenda: 1--Client 2--Internet 3--Router/Gateway 4--Caching Proxy 5--Cache 6--Load Balancer 7--Host di contenutiQuando un client (1) richiede un file X, la richiesta passa attraverso Internet (2) ed entra nella rete interna dell'azienda mediante il gateway Internet ( 3). Il server proxy intercetta la richiesta, ne genera una nuova con il proprio indirizzo IP e quello di origine e la invia a Load Balancer all'indirizzo del cluster. Load Balancer utilizza il proprio algoritmo di bilanciamento del carico per determinare l'host di contenuti in quel momento più adatto a soddisfare la richiesta per il file X. Tale host restituisce il file X al server proxy anziché inviarlo tramite Load Balancer. Il server proxy decide se memorizzarlo nella cache e distribuirlo all'utente finale nella stessa modalità precedentemente descritta.
La funzionalità avanzata di memorizzazione nella cache viene fornita anche dal plugin Dynamic Caching di Caching Proxy. Quando utilizzato insieme a WebSphere Application Server, Caching Proxy è in grado di memorizzare nella cache, supportare e invalidare contenuto dinamico sotto forma di JSP (JavaServer Page) e risposte servlet generate da WebSphere Application Server.
In genere, il contenuto dinamico con una scadenza indefinita deve essere contrassegnato con l'opzione "non eseguire la memorizzazione nella cache", dal momento che la logica standard che gestisce le scadenze delle informazioni registrate nella cache basandosi sul tempo non garantisce che tali informazioni verranno opportunamente eliminate. La logica del plugin Dynamic Caching che gestisce le scadenze basandosi sugli eventi consente al server proxy di memorizzare nella cache anche contenuti con scadenza indefinita. La memorizzazione nella cache di questo tipo di contenuto sulle unità terminali della rete esonera gli host di contenuti dal richiamare ripetutamente un server delle applicazioni per soddisfare le richieste provenienti dai client. Questo offre i seguenti vantaggi:
La memorizzazione nella cache delle risposte servlet è ideale per le pagine Web generate in modo dinamico che scadono in base alla logica dell'applicazione o a un evento, ad esempio un messaggio proveniente da un database. Sebbene la durata di questo tipo di pagine sia limitata, il valore relativo alla durata dell'attività non può essere impostato al momento della creazione poiché non si può sapere in anticipo quale sarà il trigger di scadenza. Quando il valore relativo alla durata dell'attività di queste pagine è impostato su zero, gli host di contenuti andranno incontro a elevate probabilità di errore quando supportano contenuto dinamico.
La responsabilità per la sincronizzazione della cache dinamica di Caching Proxy e Application Server è condivisa da entrambi i sistemi. Ad esempio, una pagina Web pubblica, creata in modo dinamico da un'applicazione dedicata alle previsioni del tempo, può essere esportata da Application Server e memorizzata nella cache da Caching Proxy. Caching Proxy può quindi distribuire i risultati dell'esecuzione dell'applicazione a molti utenti fino a quando non verrà informato che la pagina non è più valida. I contenuti presenti nella cache di risposte servlet di Caching Proxy sono considerati validi finché server proxy non elimina una voce dalla cache, perché congestionata o perché il timeout predefinito dalla direttiva ExternalCacheManager nel file di configurazione di Caching Proxy non raggiunge la scadenza, o finché Caching Proxy non riceve un messaggio di invalida che indica di eliminare il contenuto dalla cache. I messaggi di invalidazione che hanno origine da WebSphere Application Server a cui appartengono i contenuti vengono propagati a ciascun Caching Proxy configurato.
Caching Proxy offre altre importanti funzioni avanzate di memorizzazione nella cache:
Le prestazioni di rete sono positivamente influenzate dall'introduzione della funzionalità di Caching Proxy. Utilizzare Caching Proxy da solo o insieme a Load Balancer per migliorare le prestazioni della rete. Consultare Introduzione a WebSphere Application Server Edge Components per un'introduzione a questi sistemi.
Le prestazioni di Caching Proxy all'interno di un'azienda solo valide in base alla qualità dell'hardware su cui il componente è in esecuzione e all'architettura globale del sistema in cui viene eseguito. Per ottimizzare le prestazioni di rete, conformare l'hardware e l'architettura di rete complessiva alle caratteristiche dei server proxy.
Anche la configurazione e l'amministrazione di base del software Caching Proxy e l'ottimizzazione a livello di sistema operativo contribuiscono enormemente alle prestazioni di Caching Proxy. Per ottenere prestazioni migliori, è possibile apportare varie modifiche alla configurazione tra cui la regolazione di direttive di registrazione, regole di mappatura, plug-in, valori di timeout, valori di configurazione della cache e valori di thread attivi. I dettagli sulla configurazione del software Caching Proxy sono illustrati nel Guida alla gestione per Caching Proxy.
È possibile effettuare molte modifiche alla configurazione del sistema operativo, anche per migliorare le prestazioni; tra queste, sono incluse l'ottimizzazione di TCP e ARP, l'aumento dei limiti dei descrittori file, la sincronizzazione degli orologi di sistema, l'ottimizzazione di schede di rete e il rispetto di alcune norme durante l'esecuzione delle attività di amministrazione del sistema.
IMPORTANTE: Caching Proxy è disponibile su tutte le installazioni Edge Components, con le seguenti eccezioni:
Questa sezione illustra alcune problematiche inerenti l'hardware di rete da tenere in considerazione durante l'introduzione della funzionalità di Caching Proxy nella rete.
La quantità di memoria da dedicare al server proxy è notevole. Caching Proxy può adoperare 2 GB di spazio indirizzo virtuale quando si configura una cache in memoria di grandi dimensioni. La memoria è necessaria anche per il kernel, le librerie condivise e i buffer di rete. Perciò, è possibile che un server proxy richieda 3 o 4 GB di memoria fisica. Notare che una cache in memoria è significativamente più veloce rispetto a una semplice cache su disco e questa modifica alla configurazione da sola può determinare un miglioramento delle prestazioni.
È importante poter disporre di una grossa quantità di spazio su disco sulla macchina su cui è installato Caching Proxy, in particolar modo quando si utilizzano le cache su disco. Le operazioni di lettura e scrittura sul disco rigido rappresentano un processo gravoso per il computer. Sebbene le procedure di I/O di Caching Proxy siano efficienti, le limitazioni meccaniche del disco rigido possono ridurre le prestazioni quando Caching Proxy è configurato per utilizzare una cache su disco. Il colli di bottiglia di I/O sul disco possono essere attenuati rispettando alcune norme, quali l'uso di più dischi rigidi per file di log e dispositivi cache semplici e adoperando unità disco con tempi di ricerca, velocità rotazionale e velocità di trasferimento più celeri.
I requisiti di rete, quali velocità, tipo e numero di schede di rete, oltre che velocità delle connessioni di rete al server proxy influiscono sulle prestazioni di Caching Proxy. Normalmente, l'uso di due schede di rete su una macchina server proxy, una per il traffico in entrata e l'altra per il traffico in uscita, migliora le prestazioni. È probabile che una sola scheda di rete possa raggiungere il suo limite massimo semplicemente con il traffico di richieste e risposte HTTP. Inoltre, le schede di rete dovrebbero avere una capacità di almeno 100 MB ed essere sempre configurate per operazioni full-duplex. Questo perché la negoziazione automatica tra l'apparecchiatura di instradamento e di commutazione potrebbe causare alcuni errori e ostacolare la velocità di trasmissione. Infine, la velocità delle connessioni di rete è un fattore molto importante. Ad esempio, non si può pretendere di supportare un elevato carico di richieste e raggiungere la velocità di trasmissione ottimale se la connessione alla macchina Caching Proxy è una linea T1 satura.
La CPU (Central Processing Unit) di una macchina Caching Proxy può trasformarsi in un fattore limitante. La potenza della CPU influisce sul tempo da essa impiegato a elaborare le richieste mentre il numero di CPU nella rete incide sulla scalabilità. È importante che i requisiti di CPU del server proxy si accordino con l'ambiente, in particolare per modellare il carico massimo delle richieste che dovranno essere supportate dal server proxy.
Per le prestazioni complessive, è generalmente vantaggioso proporzionare l'architettura e non soltanto aggiungere singole componenti hardware. Non ha importanza quanto hardware verrà aggiunto a una singola macchina, poiché anch'esso presenta un livello massimo di prestazioni.
Questa sezione illustra le problematiche inerenti l'architettura di rete da tenere in considerazione durante l'introduzione della funzionalità di Caching Proxy nella rete.
Nel caso di un sito Web molto visitato, la richiesta di contenuti può essere di gran lunga superiore rispetto a quella che potrebbe realmente soddisfare un solo server proxy e ciò rallenta i tempi di risposta. Per ottimizzare le prestazioni di rete, considerare l'introduzione di macchine Caching Proxy organizzate in cluster e sottoposte a bilanciamento del carico o l'uso di un'architettura cache condivisa con RCA (Remote Cache Access) nell'architettura di rete complessiva.
Un modo per proporzionare l'architettura prevede di organizzare in cluster i server proxy e utilizzare il componente Load Balancer per bilanciare il carico tra loro. L'organizzazione in cluster dei server proxy è una soluzione vantaggiosa non solo per quanto riguarda le prestazioni e la scalabilità ma anche per motivi di ridondanza e affidabilità. Un unico server proxy rappresenta un singolo punto di errore; in caso di guasto o di inaccessibilità a causa di un problema di rete, gli utenti non potranno accedere al sito Web.
Considerare inoltre un'architettura cache condivisa con RCA. Questo tipo di architettura distribuisce la cache virtuale totale tra più server Caching Proxy che normalmente utilizzano un protocollo intercache come ICP (Internet Cache Protocol) o CARP (Cache Array Routing Protocol). RCA è progettato per ottimizzare i rapporti di accesso alla cache in cluster, fornendo una cache virtuale di grandi dimensioni.
Mediante l'uso di una matrice RCA di server proxy anziché di un unico Caching Proxy autonomo o di un cluster di macchine Caching Proxy autonome, è possibile migliorare le prestazioni. Più che altro, il miglioramento delle prestazioni avviene grazie all'aumento della dimensione totale della cache virtuale, che porta al massimo il rapporto di accesso alla cache e riduce al minimo eventuali incoerenze e latenze della cache. Con RCA, nella cache si trova solo una copia di uno specifico documento. Con un cluster di server proxy, la dimensione totale della cache viene aumentata, ma è probabile che più server proxy otterranno e memorizzeranno nella cache le stesse informazioni. Il rapporto totale degli accessi alla cache non viene quindi aumentato.
RCA è generalmente utilizzato in scenari che prevedono la memorizzazione su host di elevati volumi di contenuti aziendali. Tuttavia, i vantaggi offerti da RCA non si limitano a implementazioni aziendali di grandi dimensioni. Se il carico della rete richiede un cluster di server di cache e se la maggior parte delle richieste è rappresentata da accessi alla cache, considerare l'uso di RCA. A seconda dell'impostazione della rete, RCA non migliora sempre le prestazioni di un'azienda a causa di un aumento del numero di connessioni TCP utilizzate da un client al momento della configurazione di RCA. Questo avviene perché un membro RCA non deve solo supportare gli URL con un elevato numero di accessi ma deve anche inoltrare richieste ad altri membri o cluster se riceve una richiesta di un URL con un basso numero di accessi. Ciò significa che un determinato membro di una matrice RCA potrebbe avere più connessioni TCP aperte di quante ne avrebbe se funzionasse come server autonomo.
I principali contributi al miglioramento delle prestazioni derivano dalle capacità di memorizzazione nella cache di Caching Proxy. Tuttavia, la cache del server proxy può diventare un collo di bottiglia se non è configurata correttamente. Per stabilire la migliore configurazione della cache, è necessario un lavoro considerevole per analizzare le caratteristiche del traffico. Il tipo, la dimensione, la quantità e gli attributi del contenuto influiscono sulle prestazioni del server proxy in termini di tempo impiegato per richiamare i documenti dai server di origine e caricarli sul server. Quando si conosce il tipo di traffico che Caching Proxy dovrà archiviare o inviare dalla propria cache, è possibile scomporre in fattori tali caratteristiche al momento della configurazione del server proxy. Ad esempio, il fatto di sapere che l'80% degli oggetti è costituito da immagini (*.gif o *.jpg) della dimensione di circa 200 KB, può contribuire a ottimizzare i parametri di cache e stabilirne la dimensione. Inoltre, sapere che la maggior parte del contenuto è costituito da pagine dinamiche personalizzate, non adatte a essere memorizzate nella cache, è ugualmente pertinente all'ottimizzazione di Caching Proxy.
L'analisi delle caratteristiche del traffico consente di determinare se l'uso di una cache in memoria o di una cache su disco possa ottimizzare le prestazioni della cache. Inoltre, se si ha familiarità con le caratteristiche del traffico di rete, è possibile determinare se il miglioramento delle prestazioni dipende dall'uso della funzione di cache dinamica di Caching Proxy.
Le cache su disco sono ottimali per siti che presentano notevoli quantità di informazioni da memorizzare nella cache. Ad esempio, se un sito presenta una notevole quantità di contenuto (superiore a 5 GB) e il rapporto accessi alla cache va dall'80 al 90%, si consiglia di utilizzare una cache su disco. Tuttavia, è noto che l'uso di una cache in memoria (RAM) consente di ottenere una maggiore velocità e che in molti scenari è possibile esclusivamente per siti di grandi dimensioni. Ad esempio, se gli accessi alla cache di Caching Proxy non sono considerati molto importanti o se si utilizza una configurazione della cache condivisa, è più pratico utilizzare una cache in memoria.
Caching Proxy può memorizzare nella cache e invalidare contenuti dinamici (risultati servlet e JSP) generati dalla cache dinamica di WebSphere Application Server, fornendo un'estensione virtuale della cache di Application Server in cache basate sulla rete. La possibilità di memorizzare nella cache il contenuto generato dinamicamente migliora le prestazioni di rete in un ambiente in cui sono presenti numerose richieste per pagine Web pubbliche prodotte dinamicamente, che scadono in base alla logica dell'applicazione o a un evento, quale un messaggio di un database. La durata di una pagina è limitata, tuttavia non è possibile introdurre un trigger di scadenza al momento della sua creazione; perciò, gli host che non presentano una funzione di cache e di invalida devono designare questo tipo di pagine come se la durata dell'attività avesse un valore pari a zero.
Se queste pagine generate dinamicamente vengono richieste più di una volta da uno o più utenti durante il loro periodo di validità, la cache dinamica consente di ripartire il carico di lavoro e quindi di ridurre le richieste che altrimenti verrebbero inoltrate agli host di contenuti della rete. L'uso della cache dinamica migliora anche le prestazioni di rete offrendo una risposta più veloce agli utenti eliminando i ritardi sulla rete e riducendo l'utilizzo della larghezza di banda grazie a un numero minore di passaggi su Internet.
Il componente Load Balancer di Application Server, associato a un host di contenuti, quale WebSphere Application Server, o al componente Caching Proxy di Application Server, consente di migliorare la disponibilità e la scalabilità della rete. (Consultare Introduzione a WebSphere Application Server Edge Components per un'introduzione a questi componenti di Edge Components.) Load Balancer è un prodotto utilizzato nelle reti aziendali e deve essere installato tra il server Internet e il server back-end. Load Balancer funge da singolo POP (point-of-presence) aziendale su Internet, anche se l'azienda dovesse utilizzare più server back-end a causa di una forte domanda o di una notevole quantità di contenuti.
Un'elevata disponibilità si ottiene mediante il bilanciamento del carico e il supporto failover.
IMPORTANTE: Caching Proxy è disponibile su tutte le installazioni Edge Components, con le seguenti eccezioni:
Il bilanciamento del carico migliora la disponibilità e la scalabilità di un sito Web organizzando in cluster server proxy e server delle applicazioni, in modo trasparente. La scalabilità di un'infrastruttura IT viene di gran lunga migliorata dal momento che la potenza dell'elaborazione back-end può essere aggiunta in modo trasparente.
Una forte domanda può essere soddisfatta duplicando il contenuto su più host; in tal caso però sarà necessario trovare un modo per bilanciare il carico tra le varie macchine. Il servizio DNS (Domain Name Service) può offrire un bilanciamento del carico round-robin di base, che tuttavia in molte condizioni non funziona in modo ottimale.
Una soluzione più sofisticata per bilanciare il carico tra più host di contenuti è quella che prevede l'uso del componente Dispatcher di Load Balancer, come illustrato nella Figura 5. In questa configurazione, tutti gli host di contenuti (le macchine contrassegnate col numero 5) memorizzano lo stesso contenuto. Gli host vengono definiti in modo da formare un cluster con bilanciamento del carico mentre a una delle interfacce di rete della macchina Load Balancer (4) vengono assegnati un nome host e un indirizzo IP dedicati al cluster. Quando un utente finale che utilizza la macchina contrassegnata col numero 1 richiede il file X, la richiesta passa attraverso Internet (2) ed entra nella rete interna dell'azienda mediante il gateway Internet (3). Il Dispatcher intercetta la richiesta poiché il proprio URL è mappato sul nome host e sull'indirizzo IP del Dispatcher. Il Dispatcher determina quale host di contenuti nel cluster è attualmente il più adatto a supportare la richiesta, quindi inoltra la richiesta a quell'host, che, quando il metodo di inoltro MAC è configurato, restituisce il file X direttamente al client (ossia, il file X non passa attraverso Load Balancer).
Legenda: 1--Client 2--Internet 3--Router/Gateway 4--Dispatcher 5--Host di contenutiPer impostazione predefinita, il Dispatcher usa un bilanciamento del carico simile al tipo round-robin del servizio DNS, ma riesce a risolvere molte delle inefficienze del servizio DNS. A differenza di DNS, individua la mancata disponibilità o l'inaccessibilità di un host di contenuti, ma non continua ad indirizzare i client a un host di contenuti non disponibile. Inoltre, individuando nuove connessioni attive e terminate, tiene conto dell'effettivo carico degli host di contenuti. È inoltre possibile ottimizzare il bilanciamento del carico attivando i componenti gestore e advisor di Load Balancer, che individuano lo stato di un host di contenuti con maggiore accuratezza e includono informazioni più dettagliate nel processo decisionale relativo al bilanciamento del carico. Il gestore consente di assegnare carichi differenti in base ai diversi fattori del processo decisionale, quindi di personalizzare ulteriormente il bilanciamento del carico di un sito.
Il componente Dispatcher di Load Balancer può eseguire il bilanciamento del carico anche per più macchine Caching Proxy. Nel caso di un sito Web molto visitato, la richiesta di contenuti può essere di gran lunga superiore rispetto a quella che potrebbe soddisfare un solo server proxy e ciò può ridurne le prestazioni.
È possibile disporre di più sistemi Caching Proxy che eseguono funzioni proxy per un solo host di contenuti (simile alla configurazione illustrata nella Figura 1), ma se il sito è visitato da un numero di utenti tale da richiedere più server proxy, probabilmente saranno necessari più host di contenuti i cui carichi siano bilanciati da Load Balancer. La Figura 6 illustra questa configurazione. Il Dispatcher contrassegnato col numero 4 bilancia il carico di due server proxy (5) mentre il Dispatcher contrassegnato col numero 7 bilancia il carico di un cluster di tre host di contenuti (8).
Legenda: 1--Client 2--Internet 3--Router/Gateway 4--Dispatcher 5--server proxy 6--Cache 7--Dispatcher 8--Host di contenutiIl nome host del cluster del Dispatcher, contrassegnato col numero 4, è il nome host che appare negli URL del contenuto Web dell'azienda (ossia, il nome del sito Web visualizzato su Internet). Il nome host del cluster del Dispatcher, contrassegnato col numero 7, non è visibile su Internet, quindi è possibile assegnargli un valore a scelta. Ad esempio, per l'azienda ABC Corporation, un nome host adeguato per il Dispatcher, contrassegnato col numero 4, potrebbe essere www.abc.com, mentre per il Dispatcher, contrassegnato col numero 7, potrebbe essere http-balancer.abc.com.
Si supponga che un browser, che risiede su una delle macchine client contrassegnata col numero 1, debba accedere a un file X memorizzato sui server di contenuti contrassegnati col numero 8. La richiesta HTTP passa attraverso Internet (2) ed entra nella rete interna dell'azienda dal gateway (3). Il router indirizza la richiesta al Dispatcher, contrassegnato col numero 4, che la inoltra al server proxy (5), in quel momento considerato il più adatto a gestirla, in base all'algoritmo di bilanciamento del carico. Se il server proxy dispone di un file X nella cache (6), lo restituisce direttamente al browser, ignorando il Dispatcher contrassegnato col numero 4.
Se il server proxy non dispone di una copia del file X nella cache, crea una nuova richiesta con il proprio nome host nel campo origine dell'intestazione e la invia al Dispatcher contrassegnato col numero 7. Load Balancer determina quale host di contenuti (8) è attualmente in grado di soddisfare la richiesta, quindi la indirizza a tale destinazione. L'host di contenuti richiama il file X dalla memoria e lo restituisce direttamente al server proxy, ignorando il Dispatcher contrassegnato col numero 7. Il server proxy memorizza il file X nella cache, se necessario, e lo inoltra al browser, ignorando il Dispatcher contrassegnato col numero 4.
Se si fornisce l'accesso a Internet a un numero elevato di clienti, questi possono generare una domanda di accesso a Internet maggiore di quella che un unico proxy possa fornire. Nel momento in cui il Caching Proxy viene sovraccaricato di richieste, i client possono avere tempi di risposta peggiore di quelli relativi a un accesso a Internet diretto. Inoltre, se il Caching Proxy riporta un errore o diventa non disponibile a causa di un errore di rete, l'accesso a Internet diventa impossibile. La soluzione consiste nell'installare più macchine di Caching Proxy e utilizzare il dispatcher di Load Balancer per bilanciare il carico tra questi.
Senza il Dispatcher, è possibile fornire un proxy trasparente con più macchine Caching Proxy solo se i router possono indirizzare lo stesso tipo di traffico a più di un Caching Proxy; non tutti i router supportano questa funzione. È possibile fornire un servizio proxy diretto regolare su più macchine Caching Proxy senza il Dispatcher, ma è necessario configurare esplicitamente i browser del client in modo che utilizzino una delle macchine del Caching Proxy come proxy primario. Se il Caching Proxy riporta un errore, diventa sovraccarico o inaccessibile, gli utenti finali non potranno più accedere a Internet. Per evitare questa situazione, è possibile creare un file PAC (proxy automatic configuration), come descritto in Caching Proxy diretto trasparente (solo sistemi Linux), che indica al browser di eseguire il failover su uno o più caching proxy secondari. Un file PAC non risolve la necessità di bilanciare il carico tra le macchine del Caching Proxy; tuttavia se un Caching Proxy riceve molte più richieste di un altro, le sue prestazioni vengono ridotte, implicando tempi di risposta più lunghi per i client del browser. Per tutti i client che verificano questo calo delle prestazioni, è necessario configurare un numero quasi uguale al numero di browser perutilizzare ogni Caching Proxy e tenere traccia della distribuzione manualmente in modo da poter conservare il carico anche se vengono aggiunti o rimossi i browser.
La Figura 7 illustra una configurazione di rete in cui il carico del Dispatcher bilancia un cluster di macchine di Caching Proxy. Una delle interfacce di rete della macchina del Dispatcher è configurata in modo da avere un nome host e un indirizzo IP dedicati per il cluster. I browser del client sono configurati per indirizzare le richieste Internet al nome host del cluster. Quando ad esempio un browser su una delle macchine del client contrassegnato come 1 deve accedere al file X su un host del contenuto (7), questo indirizza la richiesta al nome host o all'indirizzo del cluster, dove il Dispatcher (2) la intercetta e la invia al Caching Proxy appropriato (3). Il Caching Proxy crea una nuova richiesta, la inoltra mediante il gateway dell'azienda (5) e su Internet (6) e, se possibile, memorizza il file restituito nella cache (4), come descritto più dettagliatamente in Caching Proxy diretto
Il Dispatcher rileva quando una delle macchine Caching Proxy non è disponibile e indirizza automaticamente le richieste a un'altra macchina. Ciò consente di arrestare una macchina Caching Proxy per la manutenzione senza interrompere l'accesso a Internet. Il Dispatcher ha numerose opzioni di configurazione che è possibile utilizzare per controllare i fattori da considerare quando si prendono decisioni relative al bilanciamento del carico. È inoltre possibile installare programmi Dispatcher ausiliari sulle macchine Caching Proxy per monitorarne lo stato e restituire le informazioni al Dispatcher. Per maggiori dettagli, fare riferimento al manuale WebSphere Application Server Load Balancer - Guida alla gestione. L'utilizzo di più macchine Caching Proxy introduce una possibile inefficienza in quanto più di un Caching Proxy può memorizzare nella cache lo stesso file se diversi client richiedono il file mediante macchine differenti. Per eliminare la ridondanza, è possibile configurare l'accesso alla cache remoto (RCA, remote cache access), che consente a tutti i proxy in un gruppo definito di condividere il contenuto delle proprie cache. I proxy nel gruppo RCA utilizzano tutti lo stesso algoritmo per determinare il Caching Proxy responsabile per un determinato URL. Quando un Caching Proxy intercetta un URL per cui non è responsabile, invia la richiesta al Caching Proxy appropriato. Il Caching Proxy responsabile esegue le operazioni necessarie a soddisfare la richiesta, richiamandole dalla cache o inoltrando la richiesta all'host del contenuto rilevante e memorizzando nella cache il file restituito. Il Caching Proxy responsabile invia quindi il file al Caching Proxy originale, che lo distribuisce all'utente finale richiedente.
Nel gruppo RCA, se il Caching Proxy responsabile per un determinato URL riporta un errore, allora il Caching Proxy originale, che ha ricevuto la richiesta client, accederà direttamente all'host del contenuto (o a un server Caching Proxy di backup, se definito). Ciò implica che gli utenti possano accedere ai file fino a che almeno un Caching Proxy in un gruppo RCA funziona correttamente.
Questa configurazione soddisfa una domanda elevata di accesso a Internet utilizzando il Dispatcher per bilanciare il carico di richieste su più macchine Caching Proxy. Un possibile problema sta nel fatto che il Dispatcher è un unico punto di errore. Se riporta un errore o diventa non disponibile a causa di un errore di rete, i client del browser non possono raggiungere i Caching Proxy o Internet. La soluzione consiste nel configurare un altro Dispatcher in modo che funzioni come backup per il Dispatcher primario, come illustrato nella Figura 8.
In questa figura è riportato un browser in esecuzione su una delle macchine contrassegnate con 1 che di solito indirizza la richiesta per un file X al Dispatcher primario (2), che a sua volta indirizza la richiesta al Caching Proxy (4) selezionato in base ai criteri di bilanciamento del carico del Dispatcher. Il Caching Proxy crea una nuova richiesta, la indirizza mediante il gateway dell'azienda (6) su Internet (7) all'host del contenuto (8) e memorizza il file X restituito nella cache (5) se possibile (per una descrizione più dettagliata di questa parte del processo, fare riferimento a Caching Proxy diretto).
In questa configurazione, il Dispatcher di backup (3) non esegue il bilanciamento del carico se quello primario è operativo. I Dispatcher primario e di backup tengono traccia dello stato l'uno dell'altro scambiando periodicamente messaggi detti heartbeat. Se il Dispatcher di backup rileva che quello primario ha riportato un errore, allora si assume automaticamente la responsabilità di bilanciare il carico intercettando le richieste dirette al nome host e all'indirizzo IP del Dispatcher primario. Inoltre è possibile configurare due Dispatcher che saranno in grado di garantirsi reciprocamente un'elevata disponibilità. In questo caso, ognuno di essi esegue attivamente il bilanciamento del carico per un cluster separato di caching proxy, funzionando simultaneamente da backup per l'altro dispatcher. Per maggiori informazioni, fare riferimento a WebSphere Application Server Load Balancer - Guida alla gestione.
Il Dispatcher generalmente non utilizza molte risorse di memoria o di elaborazione, quindi è possibile eseguire altre applicazioni sulla macchina del Dispatcher. Se è necessario ridurre al minimo i costi inerenti l'apparecchiatura, è addirittura possibile eseguire il Dispatcher di backup sulla stessa macchina di Caching Proxy. La Figura 9 illustra una tale configurazione, in cui il Dispatcher di backup viene eseguito sulla stessa macchina (3) del Caching Proxy.
Load Balancer funge da unico POP (point-of-presence) per gli host di contenuti di un'azienda. Ciò costituisce un vantaggio dal momento che si potrà pubblicizzare il nome e l'indirizzo host del cluster anziché il nome e l'indirizzo di ciascun host di contenuti; inoltre il livello di protezione contro attacchi occasionali sarà più efficace e il sito Web avrà un aspetto più omogeneo. Per aumentare ulteriormente la disponibilità di un sito Web, configurare un altro Load Balancer che funga da backup del Load Balancer principale, come illustrato nella Figura 10. Se uno dei Load Balancer subisce un guasto o non è disponibile a causa di un problema di rete, gli utenti finali saranno comunque in grado di raggiungere gli host di contenuti.
Legenda: 1--Client 2--Internet 3--Router/Gateway 4--Dispatcher principale 5--Dispatcher di backup 6--Host di contenutiNormalmente, un browser in esecuzione su una delle macchine contrassegnate col numero 1 indirizza le proprie richieste per un file X al nome host del cluster mappato sul Load Balancer principale (4). Il Dispatcher instrada la richiesta all'host di contenuti (6) selezionato in base ai criteri di bilanciamento del carico del Dispatcher. L'host di contenuti invia il file X direttamente al browser, instradandolo mediante il gateway aziendale (3) su Internet (2), ignorando Load Balancer.
Il Dispatcher secondario (5) non esegue il bilanciamento del carico finché quello principale è operativo. Il Dispatcher principale e quello di backup controllano reciprocamente il proprio stato scambiandosi periodicamente dei messaggi noti come heartbeat. Se il Dispatcher di backup rileva un errore in quello principale, si assume la responsabilità di bilanciare il carico intercettando le richieste indirizzate al nome host e all'indirizzo IP del cluster principale.
Inoltre, è possibile configurare due Dispatcher che saranno in grado di garantirsi reciprocamente un'elevata disponibilità. In questo caso, ciascuno esegue attivamente il bilanciamento del carico per un cluster di host di contenuti separato, fungendo contemporaneamente da backup per l'altro. (Sulle installazioni Load Balancer per IPv4 e IPv6, viene supportata l'elevata disponibilità semplice, ma non quella reciproca).
Il Dispatcher generalmente non utilizza molte risorse di memoria o di elaborazione, quindi è possibile eseguire altre applicazioni sulla macchina Load Balancer. Se si desidera ridurre al minimo i costi inerenti l'apparecchiatura, è addirittura possibile eseguire il Dispatcher di backup su una delle macchine del cluster su cui questo sta eseguendo il bilanciamento del carico. La Figura 11 illustra questo tipo di configurazione, in cui il Dispatcher di backup è in esecuzione su uno degli host di contenuti (5) nel cluster.
Legenda: 1--Client 2--Internet 3--Router/Gateway 4--Dispatcher principale 5--Dispatcher di backup e host di contenuti 6--Host di contenutiIMPORTANTE: il componente CBR (Content Based Routing) è disponibile su tutte le piattaforme supportate con le seguenti eccezioni:
In alternativa, per questo tipo di installazione è possibile utilizzare il metodo di inoltro cbr del componente Load Balancer' Dispatcher per consentire l'instradamento basato sul contenuto di richieste HTTP e HTTPS senza utilizzare Caching Proxy. Consultare Guida alla gestione per Load Balancer di WebSphere Application Server per ulteriori informazioni.
Load Balancer per IPv4 e IPv6 supporta esclusivamente il metodo di inoltro mac del componente' Dispatcher. I metodi di inoltro nat e cbr non sono supportati.
Il componente Load Balancer di Application Server, unito al componente Caching Proxy di Application Server, consente di distribuire le richieste a più server back-end sui cui risiedono contenuti differenti. (Consultare Introduzione a WebSphere Application Server Edge Components per un'introduzione a questi componenti di Edge Components.)
Se il componente CBR (Content Based Routing) di Load Balancer viene installato insieme a Caching Proxy, le richieste HTTP possono essere distribuite in base all'URL o ad altre caratteristiche determinate dall'amministratore, eliminando la necessità di memorizzare contenuti identici su tutti i server back-end.
L'uso si CBR è adatto particolarmente ai server Web che devono eseguire varie e numerose funzioni o offrire diversi tipi di servizi. Ad esempio, il sito Web di un rivenditore in linea deve visualizzare il catalogo, in gran parte composto da contenuto statico, e accettare gli ordini, il che implica l'esecuzione di un'applicazione interattiva, come uno script CGI (Common Gateway Interface), per accogliere i numeri degli articoli e le informazioni relative agli utenti. Spesso, è preferibile disporre di due serie diverse di macchine, che eseguono funzioni distinte, e utilizzare CBR per instradare i vari tipi di traffico a macchine differenti. Allo stesso modo, un'azienda può utilizzare CBR per offrire un miglior servizio ai clienti abituali del sito Web rispetto ai visitatori occasionali, instradando le richieste dei primi a server Web di gran lunga più potenti.
CBR instrada le richieste in base a regole personalizzate. Il tipo più comune è la regola di contenuto, che indirizza le richieste in base al nome del percorso nell'URL. Ad esempio, l'azienda ABC Corporation può scrivere delle regole che indirizzano le richieste per l'URL http://www.abc.com/catalog_index.html a un cluster di server e le richieste per l'URL http://www.abc.com/orders.html a un altro cluster. Inoltre, esistono regole che instradano le richieste a seconda dell'indirizzo IP del client che le ha inviate o in base ad altre caratteristiche. Per ulteriori informazioni, consultare i capitoli della Guida alla gestione per WebSphere Application Server Load Balancer sulla configurazione di CBR e sulle funzioni di Load Balancer e CBR avanzate. Per le definizioni di sintassi delle regole, consultare l'appendice della Guida alla gestione per WebSphere Application Server Load Balancer sui tipi di regole CBR.
La Figura 12 illustra una configurazione di tipo semplice in cui il componente CBR di Load Balancer e Caching Proxy sono installati sulla macchina contrassegnata col numero 4 e instradano le richieste a tre host di contenuti (6, 7 e 8) su cui risiedono contenuti differenti. Quando un utente finale che utilizza la macchina contrassegnata col numero 1 richiede il file X, la richiesta passa attraverso Internet (2) ed entra nella rete interna dell'azienda mediante il gateway Internet (3). Il server proxy intercetta la richiesta e la inoltra al componente CBR sulla stessa macchina, che analizza l'URL della richiesta e determina l'host di contenuti 6 su cui risiede il file X. Il server proxy genera una nuova richiesta per il file X e, se la funzione di memorizzazione nella cache è attivata, determina se il file ha i requisiti necessari per essere memorizzato nella cache quando l'host 6 lo restituisce. Se il file è memorizzabile nella cache, il server proxy ne memorizza una copia nella propria cache (5), quindi lo invia all'utente finale. L'instradamento di altri file funziona nello stesso modo: le richieste per il file Y passano all'host di contenuti 7 mentre quelle per il file Z vanno all'host di contenuti 8.
Legenda: 1--Client 2--Internet 3--Router/Gateway 4--Componenti CBR di Caching Proxy e Load Balancer 5--Cache 6, 7, 8--Host di contenutiLa Figura 13 illustra una configurazione più complessa eventualmente adatta a un rivenditore al dettaglio in linea. Il componente CBR di Load Balancer e il server proxy sono installati sulla stessa macchina contrassegnata col numero 4 e instradano le richieste a due macchine Load Balancer. La macchina Load Balancer contrassegnata col numero 6 esegue il bilanciamento del carico di un cluster di host di contenuti (8) su cui risiede la maggior parte del contenuto statico del catalogo del rivenditore laddove la macchina Load Balancer contrassegnata col numero 7 esegue il bilanciamento del carico di un cluster di server Web che gestiscono gli ordini (9).
Quando un utente finale che utilizza la macchina contrassegnata col numero 1 accede all'URL del catalogo del rivenditore, la richiesta passa attraverso Internet (2) ed entra nella rete interna dell'azienda mediante il gateway Internet (3). Il server proxy intercetta la richiesta e la inoltra al componente CBR sulla stessa macchina, che analizza l'URL e determina che la macchina Load Balancer contrassegnata col numero 6 deve gestire quell'URL. Il server proxy crea una nuova richiesta di accesso e la invia a Load Balancer, che determina quale host di contenuti, tra quelli contrassegnati col numero 8, è al momento il più adatto a supportare la richiesta (in base ai criteri stabiliti). L'host di contenuti inoltra i contenuti del catalogo direttamente al server proxy, ignorando Load Balancer. Come nell'esempio precedente, il server proxy determina se il contenuto è memorizzabile nella cache e lo memorizza nella propria cache (5), se necessario.
L'utente finale invia un ordine accedendo all'URL apposito del rivenditore, presumibilmente mediante un collegamento ipertestuale nel catalogo. La richiesta viaggia sullo stesso percorso della richiesta di accesso al catalogo; l'unica differenza è che il componente CBR sulla macchina 4 la instrada alla macchina Load Balancer contrassegnata con il numero 7. Load Balancer la inoltra ai server Web più adatti contrassegnati col numero 9, che rispondono direttamente al server proxy. Dal momento che le informazioni relative agli ordini vengono generate in modo dinamico, è probabile che il server proxy non le memorizzerà nella cache.
Legenda: 1--Client 2--Internet 3--Router/Gateway 4--Componente CBR di Caching Proxy e Load Balancer 5--Cache 6, 7--Load Balancer 8--Host di contenuti 9--Server WebLa funzione CBR di Load Balancer supporta affinità di cookie. Questo vuol dire che l'identità del server che ha supportato la prima richiesta dell'utente finale viene registrata in un pacchetto di dati speciale (un cookie) incluso nella risposta del server. Quando l'utente finale accede di nuovo allo stesso URL, entro un determinato intervallo di tempo ben definito, e la richiesta include il cookie, CBR la instrada al server originale anziché riapplicare le proprie regole standard. Questo generalmente migliora i tempi di risposta, se il server ha memorizzato le informazioni sull'utente finale, che non dovranno essere richieste nuovamente (ad esempio, un numero di carta di credito).
Questa sezione descrive gli scenari aziendali che utilizzano Edge Components di IBM WebSphere Application Server. Si tratta di soluzioni solide e verificate dal punto di vista strutturale, in grado di offrire prestazioni, disponibilità, scalabilità e affidabilità eccellenti.
Questa sezione contiene i seguenti capitoli:
Rete B2C (Business-to-Consumer)
Soluzione bancaria B2C (Business-to-Client)
Un sito Web e-commerce di base prevede una rete B2C (Business-to-Consumer). Durante la prima fase di crescita in Internet, le aziende di solito si preoccupano solo di assicurarsi una presenza sul Web. Le informazioni sull'azienda e i cataloghi dei prodotti vengono convertiti in formato digitale e resi disponibili sul sito. Gli acquisti sono possibili mediante indirizzi e-mail, numeri di telefono/fax e moduli automatici. Un vero e proprio acquisto in linea, tuttavia, non è ancora disponibile. Tutte le transazioni hanno una latenza intrinseca dal momento che per elaborare l'ordine sarà sempre necessario l'intervento umano.
Nella seconda fase, le aziende eliminano questa latenza e semplificano le operazioni di vendita implementando carrelli d'acquisto sicuri per consentire l'acquisto diretto in linea. La sincronizzazione con i database del magazzino e l'integrazione con i sistemi bancari sono fondamentali per completare queste transazioni. I prodotti non disponibili non potranno essere venduti né addebitati sul conto dei clienti. Allo stesso modo, un prodotto non potrà essere prelevato dall'inventario e inviato a un cliente finché non si verifica una transazione finanziaria valida.
Nella terza fase, il sito Web dell'azienda si evolve in un sito con presentazione dinamica, in cui un utente inizia ad assumere le sembianze di un cliente abituale a cui viene fornito un contenuto personalizzato.
il seguente scenario comprende sia Load Balancer che Caching Proxy.
IMPORTANTE: Caching Proxy è disponibile su tutte le installazioni Edge Components, con le seguenti eccezioni:
La Figura 14 illustra un piccolo sito Web commerciale progettato per offrire un'efficiente ricerca nel catalogo. Tutte le richieste dei client passano attraverso il firewall e arrivano a un Dispatcher che le instrada a un cluster di server proxy con cache attive che fungono da server sostitutivi dei server Web. I Metric Server vengono situati insieme al server proxy per fornire i dati sul bilanciamento del carico al Dispatcher. Questa disposizione diminuisce il carico di rete sui server Web e li isola dal contatto diretto con Internet.
La Figura 15 illustra la seconda fase dell'evoluzione di un sito Web commerciale progettato per offrire un'efficiente ricerca nel catalogo e carrelli d'acquisto veloci e sicuri per potenziali clienti. Tutte le richieste dei clienti vengono instradate alla sezione di rete appropriata da un Dispatcher, che le separa in base al protocollo Internet. Le richieste HTTP vengono inviate al sito Web statico mentre le richieste HTTPS alla rete di acquisto. Il sito Web principale, statico, è ancora supportato da un cluster di server proxy con cache attive che fungono da sostituti dei server Web. Questa parte della rete riflette la rete della prima fase.
La porzione riservata all'e-commerce del sito Web è anch'essa supportata da un cluster di server proxy. Tuttavia, i nodi Caching Proxy vengono potenziati con numerosi moduli plug-in. La sincronizzazione SSL viene eseguita da una scheda hardware crittografico mentre l'autenticazione viene eseguita mediante il plug-in Access Manager (in precedenza Policy Director). Un plug-in Dynamic Caching riduce il carico di lavoro su WebSphere Application Server, memorizzando i dati comuni. Un plug-in sul server delle applicazioni invalida gli oggetti nella Dynacache, se necessario.
Tutte le applicazioni del carrello d'acquisto vengono collegate al database utilizzato per autenticare l'utente. In questo modo, l'utente non dovrà inserire le informazioni personali una seconda volta, una per l'autenticazione, l'altra per l'acquisto.
Questa rete suddivide il traffico in base all'utilizzo del client, eliminando l'autenticazione SSL e i carrelli d'acquisto e-commerce, gravosi per il processore, dal sito Web principale. Questo sito a doppia traccia consente all'amministratore di rete di ottimizzare i vari server in modo da offrire prestazioni eccellenti in base al ruolo del server nella rete.
La Figura 16 illustra la terza fase dell'evoluzione di una rete B2C (Business-to-Consumer), in cui la parte Web statica adotta un metodo di presentazione dinamica. Il cluster di server proxy è stato potenziato per supportare la memorizzazione nella cache di contenuto Web dinamico e assemblare frammenti di pagina scritti per soddisfare il protocollo ESI (Edge Side Includes). Anziché utilizzare i meccanismi di inclusione lato server per creare pagine Web sui server di contenuti e propagare queste pagine, specifiche dei client e non memorizzabili, a tutta la rete, il meccanismo ESI consente di assemblare le pagine da contenuti memorizzati nella cache sulle macchine terminali della rete, riducendo perciò il consumo di larghezza di banda e i tempi di risposta.
I meccanismi ESI sono fondamentali in questa terza fase, dove ciascun client riceve una home page personalizzata dal sito Web. I blocchi di creazione di queste pagine vengono richiamati da una serie di WebSphere Application Server. I server delle applicazioni contenenti logica aziendale importante e collegati a database protetti sono isolati da un firewall.
La Figura 17 illustra un'efficiente soluzione di banca in linea simile alla soluzione di rete B2C (Business-to-Consumer) descritta in Rete B2C (Business-to-Consumer). Tutte le richieste client passano attraverso il firewall al Dispatcher e questo separa il traffico in base al protocollo Internet. Le richieste HTTP passano a un cluster di server proxy con cache attive che fungono da server sostitutivi dei server Web. I Metric Server sono situati insieme ai server proxy per fornire i dati sul bilanciamento del carico al Dispatcher. Questa disposizione diminuisce il carico di rete sui server Web e crea un buffer aggiuntivo tra questi e Internet.
Le richieste HTTPS vengono inviate a una rete protetta progettata per fornire ai client informazioni finanziarie personali e consentire transazioni bancarie in linea. Un cluster di server proxy potenziati garantisce la scalabilità del sito. Questi server proxy supportano la memorizzazione nella cache di contenuto Web dinamico e assemblano frammenti di pagina scritti per soddisfare il protocollo ESI (Edge Side Includes). Una scheda hardware crittografico gestisce le sincronizzazioni SSL, riducendo in modo significativo il carico di elaborazione dell'host del server proxy, mentre un Access Manager (in precedenza Policy Director) gestisce l'autenticazione dei client.
Un insieme di cluster di server delle applicazioni distribuisce l'elaborazione di richieste, separando la logica aziendale, contenuta in componenti EJB, da questi livelli di presentazione, contenuti in servlet e file JSP. Ognuno di questi cluster viene gestito da un server di sessione separato.
il seguente scenario comprende sia Load Balancer che Caching Proxy.
IMPORTANTE: Caching Proxy è disponibile su tutte le installazioni Edge Components, con le seguenti eccezioni:
La Figura 18 illustra una rete portale Web progettata per supportare un volume di traffico consistente e al tempo stesso fornire contenuto personalizzato a ciascun client. Per ridurre al minimo il carico di elaborazione sui vari server, nessuna parte della rete trasporta traffico SSL. Dal momento che il portale non distribuisce dati significativi, la sicurezza non è un fattore di rilievo. Per quanto riguarda i database contenenti impostazioni, ID e password dei client, è importante che rimangano discretamente protetti e inalterati; tuttavia questo requisito non deteriora le prestazioni della parte restante del sito Web.
Tutte le richieste client passano attraverso il firewall e arrivano a un Dispatcher che bilancia il carico di rete tra un cluster di server proxy con cache attive che fungono da server sostitutivi dei server Web. I Metric Server sono situati insieme ai server proxy per fornire i dati sul bilanciamento del carico al Dispatcher.
Il sito Web dinamico effettivo è un cluster di server delle applicazioni che genera frammenti ESI che vengono inoltrati ai server proxy per l'assemblaggio. Date le minori problematiche in termini di sicurezza, ciascun server delle applicazioni esegue tutte le funzioni necessarie per costruire il sito Web. Tutti i server delle applicazioni sono identici. Se uno dei server delle applicazioni subisce un guasto, il server di sessione può instradare le richieste ad altri server, garantendo un'elevata disponibilità all'intero sito. Questa configurazione consente inoltre un rapido potenziamento del sito Web in caso di traffico eccessivo, ad esempio, se il portale deve ospitare un evento particolare. Server proxy e server delle applicazioni supplementari possono essere configurati velocemente sul sito.
Tutti i contenuti statici, quali file di immagine e testo standard vengono memorizzati su server Web separati, in modo da poter essere aggiornati in caso di necessità senza rischiare di corrompere i più complessi server delle applicazioni.
il seguente scenario comprende sia Load Balancer che Caching Proxy.
IMPORTANTE: Caching Proxy è disponibile su tutte le installazioni Edge Components, con le seguenti eccezioni:
Questa sezione contiene le procedure per l'installazione di Edge Components.
Questa sezione contiene i seguenti capitoli:
Installazione di Edge Components mediante il programma di installazione
Installazione di Caching Proxy mediante strumenti di assemblaggio del sistema
Installazione di Load Balancer mediante strumenti di assemblaggio del sistema
In questo argomento viene fornito un collegamento ai requisiti hardware e software per Edge Components e vengono descritte le istruzioni per utilizzare i browser Web con i moduli di Caching Proxy Configurazione e amministrazione e la guida in linea di Load Balancer.
Per informazioni sui requisiti hardware e software supportati per Edge Components WebSphere Application Server, Versione 6.1, collegarsi alla pagina Web al seguente indirizzo: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Installazione SDK: Java 2 SDK viene installato automaticamente con Load Balancer su tutte le piattaforme.
Requisiti browser minimi
Per configurare Caching Proxy mediante i moduli di configurazione e di amministrazione, il browser deve avere le seguenti caratteristiche:
Per sistemi Linux e UNIX: per le versioni consigliate dei browser Mozilla e Firefox, fare riferimento al seguente sito Web e seguire i link alla pagina Web del software supportato: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Per sistemi Windows: per le versioni consigliate dei browser Internet Explorer, Mozilla e Firefox, fare riferimento al al seguente sito Web e seguire i link alla pagina Web del software supportato: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
RESTRIZIONE: se il numero degli elementi espansi è tale da non poter essere contenuto nella finestra del browser, è possibile che la barra di scorrimento verticale a sinistra del modulo di amministrazione non venga visualizzata. Per questo motivo, gli elementi espansi alla fine dell'elenco non saranno accessibili dalla finestra di visualizzazione del browser. Per risolvere il problema, limitare il numero degli elementi espansi nel menu a sinistra. Se il numero di questi elementi è molto esteso, chiuderne alcuni finché non sarà possibile visualizzare gli elementi situati alla fine dell'elenco nella finestra del browser.
Per vedere correttamente i moduli, il sistema operativo che attualmente visualizza il modulo (quello su cui risiede il browser) deve contenere i set di caratteri appropriati per la lingua in cui è scritto. L'interfaccia browser, tuttavia, non deve essere necessariamente nella stessa lingua dei moduli.
Ad esempio, una versione cinese del server proxy è in esecuzione su un sistema Solaris 9. Un browser Mozilla con un'interfaccia in lingua inglese viene caricato sull'host Solaris. Questo browser può essere utilizzato localmente per modificare i moduli di Configurazione e amministrazione. (I moduli vengono inviati al browser con il set di caratteri utilizzato dal server proxy -- in questo caso, un set di caratteri cinesi; tuttavia, se il browser e il sistema operativo alla base non sono correttamente configurati per visualizzare il set di caratteri inviato dal server proxy, è possibile che i moduli non vengano visualizzati nel modo appropriato.)
In alternativa, se una stazione di lavoro Windows con supporto per la lingua cinese è disponibile per collegarsi in remoto al server proxy, è possibile caricare una versione in cinese del browser Netscape sulla stazione di lavoro Windows e utilizzare questo browser per inserire i valori nei moduli. Questa seconda soluzione ha il vantaggio di mantenere un'interfaccia nella stessa lingua dell'amministratore.
I set di caratteri specifici per sistemi operativi influiscono notevolmente sulla visualizzazione delle varie lingue, in particolar modo i caratteri DBCS (Double-Byte Character Set) nei browser. Ad esempio, uno specifico set di caratteri cinesi su AIX non è identico allo stesso set di caratteri sulle piattaforme Windows. Questo crea alcune irregolarità nell'aspetto del testo HTML e delle applet Java nei moduli di Configurazione e amministrazione. Per ottenere un aspetto migliore, si consiglia di utilizzare i browser in esecuzione su sistemi operativi Windows.
Note relative al browser Mozilla 1.4 su S/390 e PowerPC
Per poter visualizzare correttamente i moduli di amministrazione, il plug-in Java installato su Mozilla 1.4 deve essere aggiornato alla versione 1.4.2 o superiore. Utilizzare le seguenti operazioni per aggiornare il plug-in:
Per utilizzare la guida in linea di Load Balancer, il browser deve supportare:
L'uso di un browser che non supporta tali requisiti, può causare la formattazione errata delle pagine e l'esecuzione non corretta delle funzioni.
In questo argomento sono contenute le istruzioni per installare Edge Components mediante il programma di installazione.
Java 2 SDK viene installato automaticamente con Load Balancer su tutte le piattaforme.
Dopo l'installazione, gli script contenuti nel pacchetto Caching Proxy tentano di avviare il server proxy utilizzando la configurazione predefinita. Se la porta 80 è già in uso, ad esempio da parte di un altro server, non sarà possibile avviare il server proxy.
IMPORTANTE: Caching Proxy è disponibile su tutte le installazioni Edge Components, con le seguenti eccezioni:
Utilizzare il programma di installazione per installare Edge Components sul sistema Windows nel modo seguente:
se Edge Components è già installato, la finestra delle opzioni di gestione viene visualizzata prima della finestra di selezione dei componenti. Selezionare il pulsante di opzione Modifica, quindi fare clic su Avanti. Viene visualizzata la finestra per la selezione dei componenti.
Limitazione: l'utilizzo del tasto Tab nella finestra dell'accordo di licenza consente di passare dall'opzione Accetto e l'opzione Non accetto e viceversa. Tuttavia, non è possibile utilizzare questo tasto per passare ai pulsanti Indietro, Avanti o Annulla. Per passare a queste opzioni di navigazione, utilizzare i tasti Maiusc+Tab. Inoltre, il tasto Invio funziona solo per i tasti di navigazione ed è necessario utilizzare la barra spaziatrice per selezionare le opzioni Accetto o Non accetto.
Se si sta effettuando l'installazione da CD, è possibile utilizzare il programma di installazione per installare Edge Components sui sistemi Linux e UNIX nel modo seguente:
# ./installViene visualizzata la finestra iniziale.
Il programma di installazione avvia l'installazione dei componenti Edge Components selezionati e dei pacchetti necessari.
Limitazione: l'utilizzo del tasto Tab nella finestra dell'accordo di licenza consente di passare dall'opzione Accetto e l'opzione Non accetto e viceversa. Tuttavia, non è possibile utilizzare questo tasto per passare ai pulsanti Indietro, Avanti o Annulla. Per passare a queste opzioni di navigazione, utilizzare i tasti Maiusc+Tab. Inoltre, il tasto Invio funziona solo per i tasti di navigazione ed è necessario utilizzare la barra spaziatrice per selezionare le opzioni Accetto o Non accetto.
Su Red Hat Linux 3.0 Update 3: quando si esegue il programma di installazione per i componenti Edge, i pulsanti non funzioneranno se il pannello della GUI viene ingrandito e poi ripristinato. Per risolvere il problema, effettuare quanto segue:
Su sistemi Linux e UNIX: se il programma di setup è utilizzato per installare i componenti Edge, allora il programma di disinstallazione della GUI può essere utilizzato per disinstallare i componenti Edge. Tuttavia, il programma di disinstallazione della GUI dei componenti Edge non può essere utilizzato per disinstallare un pacchetto di aggiornamento installato mediante i comandi nativi. È necessario prima disinstallare il pacchetto di aggiornamento mediante i comandi nativi (ovvero i comandi del sistema operativo) e poi disinstallare i componenti mediante il programma di disinstallazione della GUI.
Per informazioni sull'utilizzo dei comandi nativi, fare riferimento a Installazione di Caching Proxy mediante strumenti di assemblaggio del sistema e a Installazione di Load Balancer mediante strumenti di assemblaggio del sistema.
In questo argomento sono contenute le istruzioni per installare Caching Proxy mediante gli strumenti di assemblaggio del sistema.
Dopo l'installazione, gli script contenuti nel pacchetto Caching Proxy tentano di avviare il server proxy utilizzando la configurazione predefinita. Se la porta 80 è già in uso, ad esempio da parte di un altro server, non sarà possibile avviare il server proxy.
IMPORTANTE: Caching Proxy è disponibile su tutte le installazioni Edge Components, con le seguenti eccezioni:
Utilizzando il sistema di installazione dei pacchetti della piattaforma in uso, installare i pacchetti nell'ordine elencato in Tabella 2. La procedura riportata di seguito illustra i passi tipici necessari al completamento di questa attività.
su - root Password: password
cd punto_caricamento/directory_pacchetto/
Su AIX:
installp -acXd ./nomePacchetto
Su HP-UX:
swinstall -s source/ nomePacchetto
Su Linux:
rpm -i ./nomePacchetto
Su Solaris:
pkgadd -d ./nomePacchetto
Componente | Pacchetti installati (nell'ordine consigliato) |
---|---|
Caching Proxy |
|
Documentazione di Edge Components |
doc-en_US1 |
Note:
|
Il pacchetto della documentazione contiene soltanto la lingua Inglese. Le versioni tradotte della documentazione di Edge Component si trovano sul sito Web al seguente indirizzo: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Per disinstallare i pacchetti:
Su AIX:
installp -u nomePacchetto
Per disinstallare tutti i pacchetti Caching Proxy, utilizzare il comando:
installp -u wses
Su HP-UX:
swremove nomePacchetto
Per eseguire query sui pacchetti Caching Proxy installati, utilizzare il comando:
swlist | grep WSES
I pacchetti devono essere rimossi nell'ordine inverso rispetto all'installazione.
Su Linux:
rpm -e nomePacchetto
Per eseguire query sui pacchetti Caching Proxy installati, utilizzare il comando:
rpm -qa |grep -i wses
I pacchetti devono essere rimossi nell'ordine inverso rispetto all'installazione.
Su Solaris:
pkgrm nomePacchetto
Per eseguire query sui pacchetti Caching Proxy installati, utilizzare il comando:
pkginfo | grep WSES
I pacchetti devono essere rimossi nell'ordine inverso rispetto all'installazione.
Questo argomento descrive l'installazione di Load Balancer su sistemi AIX, HP-UX, Linux e Solaris:
In base al tipo di installazione, non sono forniti tutti i pacchetti di Load Balancer elencati in questa sezione.
L'ordine consigliato per l'installazione dei pacchetti è leggermente differente per le installazioni di Load Balancer per IPv4 e IPv6. È importante notare che il pacchetto del componente di gestione deve essere installato in seguito al pacchetto del componente dispatcher. L'ordine consigliato per l'installazione dei pacchetti per Load Balancer per IPv4 e IPv6 mediante gli strumenti di sistema è: base, licenza, componente dispatcher, gestione, documentazione e Metric Server
Se si sta eseguendo la migrazione da una precedente versione di Load Balancer, o se si sta reinstallando un sistema operativo, prima di procedere all'installazione, salvare tutti i file di configurazione o i file script precedenti di Load Balancer.
Se si scollega una macchina dopo aver installato Load Balancer, riavviare tutti i servizi Load Balancer al successivo collegamento.
Tabella 5 riporta i fileset AIX per Load Balancer e l'ordine di installazione consigliato utilizzando lo strumento di installazione dei pacchetti del sistema.
Componenti Load Balancer | Fileset AIX |
---|---|
Base | ibmlb.base.rte |
Amministrazione (con messaggi) |
|
Driver unità | ibmlb.lb.driver |
Licenza | ibmlb.lb.license |
Componenti Load Balancer (con messaggi) |
|
Documentazione (con messaggi) |
|
Metric Server | ibmlb.ms.rte |
Il pacchetto della documentazione contiene soltanto la lingua Inglese. Le versioni tradotte della documentazione di Edge Component si trovano sul sito Web al seguente indirizzo: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Prima di installare Load Balancer per AIX, verificare quanto segue:
installp -u ibmlbaltrimenti, per le versioni precedenti, immettere quanto segue:
installp -u ibmndPer disinstallare determinati fileset, elencarli invece di indicare il nome del pacchetto ibmlb.
Nel momento in cui si disinstalla il prodotto, è possibile scegliere di installare uno o tutti i componenti elencati di seguito:
Per installare Load Balancer per AIX si consiglia di utilizzare SMIT, dal momento che questo garantisce l'installazione automatica di tutti i messaggi.
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
Pacchetti | Comandi |
---|---|
Base | installp -acXgd unità ibmlb.base.rte |
Amministrazione (con messaggi) | installp -acXgd unità ibmlb.admin.rte ibmlb.msg.lingua.admin |
Driver unità | installp -acXgd unità ibmlb.lb.driver |
Licenza | installp -acXgd unità ibmlb.lb.license |
Componenti di Load Balancer (con msg). Tra i componenti sono inclusi: Dispatcher, CBR, Site Selector, Cisco CSS Controller e Nortel Alteon Controller |
installp -acXgd device ibmlb.componente.rte ibmlb.msg.lingua.lb |
Documenti (con messaggi) | installp -acXgd unità ibmlb.doc.rte ibmlb.msg.en_US.lb |
Metric Server | installp -acXgd unità ibmlb.ms.rte |
installp -ld unità
Se si esegue l'installazione da un CD, per disinstallare il CD, immettere il seguente comando:
unmount /cdrom
Verificare che il prodotto sia stato installato immettendo il seguente comando
lslpp -h | grep ibmlb
Se il prodotto è stato installato completamente, questo comando restituisce quanto segue:
ibmlb.base.rte
ibmlb.admin.rte
ibmlb.lb.driver
ibmlb.lb.license
ibmlb.componente.rte
ibmlb.doc.rte
ibmlb.ms.rte
ibmlb.msg.lingua.admin
ibmlb.msg.en_US.doc
ibmlb.msg.lingua.lb
Tra i percorsi di installazione di Load Balancer sono inclusi:
In questa sezione viene illustrato come installare Load Balancer su HP-UX mediante il CD del prodotto.
Prima di avviare la procedura di installazione, verificare di essere in possesso dell'autorizzazione root per installare il software.
Se è già stata installata una precedente versione, disinstallarne la copia prima di installare la versione aggiornata. Per prima cosa, accertarsi di avere arrestato sia l'executor che il server. Quindi, per disinstallare Load Balancer, consultare Istruzioni per la disinstallazione dei pacchetti.
La Tabella 7 visualizza un elenco di nomi di pacchetti di installazione per Load Balancer e l'ordine necessario per installarli mediante lo strumento di installazione pacchetti del sistema.
HP-UX non supporta le impostazioni internazionali in Portoghese brasiliano (pt_BR). Le impostazioni internazionali supportate su HP-UX sono:
La procedura riportata di seguito illustra le operazioni necessarie al completamento di questa attività.
su - root Password: password
Immettere il comando di installazione
swinstall -s /origine nome_pacchetto
in cui source è il percorso directory assoluto di ubicazione del pacchetto e nome_pacchetto è il nome del pacchetto.
Ad esempio, il comando riportato di seguito installa il pacchetto di base di Load Balancer (ibmlb.base), se l'installazione avviene dalla root del CD
swinstall -s /origine ibmlb.base
Per installare tutti i pacchetti di Load Balancer emettere il seguente comando (se si esegue l'installazione della directory root del CD):
swinstall -s /origine ibmlb
Emettere il comando swlist per elencare tutti i pacchetti installati. Ad esempio,
swlist -l fileset ibmlb
Utilizzare il comando swremove per disinstallare i pacchetti. I pacchetti devono essere rimossi nell'ordine inverso rispetto all'installazione. Ad esempio, emettere quanto segue:
swremove ibmlbPer disinstallare un singolo pacchetto (ad esempio, Cisco CSS Controller)
swremove ibmlb.cco
Tra i percorsi di installazione di Load Balancer sono inclusi:
In questa sezione viene illustrato come installare Load Balancer su Linux mediante il CD di Edge Components.
Prima di installare Load Balancer, verificare quanto segue:
rpm -e nomePacchettoDurante la disinstallazione, invertire l'ordine utilizzato per l'installazione, verificando che i pacchetti di amministrazione vengano disinstallati per ultimi.
L'immagine di installazione è un file nel formato lblinux-versione.tar.
tar -xf lblinux-versione.tarIl risultato prevede il gruppo di file riportato di seguito con estensione .rpm:
Dove --
Il pacchetto della documentazione contiene soltanto la lingua Inglese. Le versioni tradotte della documentazione di Edge Component si trovano sul sito Web al seguente indirizzo: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
rpm -i pacchetto.rpm
Sistemi Red Hat Linux: a causa di un problema noto con Red Hat Linux, sarà necessario eliminare i file RPM _db* o si verificherà un errore.
È importante installare i pacchetti nell'ordine illustrato nel seguente elenco di pacchetti obbligatori per ciascun componente.
rpm -i --nodeps pacchetto.rpm
rpm -qa | grep ibmlb
L'installazione dell'intero prodotto genera il seguente output:
Tra i percorsi di installazione di Load Balancer sono inclusi:
Per disinstallare i pacchetti, eseguire le operazioni di installazione del pacchetto nell'ordine inverso, verificando che i pacchetti di amministrazione vengano disinstallati per ultimi.
In questa sezione viene illustrato come installare Load Balancer su Solaris mediante il CD di Edge Components.
Prima di avviare la procedura di installazione, verificare di aver effettuato il collegamento come root e di aver disinstallato eventuali versioni precedenti del prodotto.
Per eseguire la disinstallazione, verificare di aver arrestato tutti gli executor e i server. Quindi, immettere il seguente comando:
pkgrm Nomepacchetto
pkgadd -d nomepercorsodove per -d nomepercorso si intende il nome dell'unità CD-ROM o la directory sul disco rigido dove risiedono i pacchetti; ad esempio: -d /cdrom/cdrom0/.
Di seguito è riportato un elenco dei pacchetti visualizzati e l'ordine di installazione consigliato.
Il pacchetto della documentazione (ibmlbdoc) contiene soltanto la lingua Inglese. Le versioni tradotte della documentazione di Edge Component si trovano sul sito Web al seguente indirizzo: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Se si desidera installare tutti i pacchetti, è sufficiente immettere tutti e premere Invio. Se si desidera installare solo alcuni componenti, immettere il nome o i nomi corrispondenti ai pacchetti da installare, separati da uno spazio o da una virgola, quindi premere Invio. Verrà richiesto di modificare le autorizzazioni sulle directory o file esistenti. È sufficiente premere Invio o rispondere sì. È necessario installare i pacchetti prerequisiti (dal momento che l'installazione segue l'ordine alfabetico e non quello dei prerequisiti). Se si immette tutti, rispondere sì a tutti i prompt e l'installazione verrà completata con successo.
Se si desidera installare soltanto il componente Dispatcher con la documentazione e Metric Server, è necessario installare i seguenti pacchetti: ibmlbbase, ibmlbadm, ibmlblic, ibmdisp, ibmlbdoc e ibmlbms.
pkginfo | grep ibm
Tra i percorsi di installazione di Load Balancer sono inclusi:
Questa sezione illustra le procedure per creare reti dimostrative di base utilizzando Edge Components. Queste reti non sono destinate ad ambienti di produzione. Il processo di configurazione iniziale di una rete può chiarire molti concetti "edge-of-network" a quegli amministratori che non hanno ancora acquisto familiarità con il prodotto. Per una descrizione completa di tutte le funzioni dei componenti e per informazioni più dettagliate sulla configurazione, consultare Guida alla gestione per Caching Proxy e Guida alla gestione per Load Balancer.
Le procedure consentono a qualunque sistema supportato dal componente di essere utilizzato su qualsiasi nodo.
Questa sezione contiene i seguenti capitoli:
Creazione di una rete Caching Proxy.
Creazione di una rete Load Balancer.
La Figura 19 mostra una rete del server proxy di base che utilizza tre sistemi collocati su tre nodi di rete. Questa rete collega il server proxy a un host di contenuti dedicato (IBM HTTP Server), che risiede su Server 2, dove il server proxy supporta l'host. Questa configurazione è rappresentata in modo visivo dalla rete Internet situata tra la stazione di lavoro e Server 1.
IMPORTANTE: Caching Proxy è disponibile su tutte le installazioni Edge Components, con le seguenti eccezioni:
Per creare una rete Caching Proxy, eseguire le seguenti procedure nell'ordine descritto:
I computer e i componenti software riportati di seguito sono obbligatori:
Installare e configurare Caching Proxy come indicato di seguito:
# htadm -adduser /opt/ibm/edge/cp/server_root/protect/webadmin.passwd
Quando richiesto, specificare il nome utente, la password e il nome reale dell'amministratore nel programma htadm.
Installare e configurare Caching Proxy come indicato di seguito:
cd "Programmi\IBM\edge\cp\server_root\protect" htadm -adduser webadmin.passwd"
Quando richiesto, specificare il nome utente, la password e il nome reale dell'amministratore nel programma htadm.
Dalla stazione di lavoro, effettuare quanto segue:
Dalla stazione di lavoro, effettuare quanto segue:
La Figura 20 illustra una rete Load Balancer di base con tre stazioni di lavoro collegate localmente mediante il metodo di inoltro MAC del componente Dispatcher, per bilanciare il traffico Internet tra due server Web. La configurazione è simile a quella utilizzata per bilanciare il traffico di altre applicazioni UDP stateless o TCP.
Per creare una rete Load Balancer, eseguire le procedure riportate di seguito nell'ordine indicato:
I sistemi e i componenti software riportati di seguito sono obbligatori:
Stazione di lavoro | Nome | Indirizzo IP |
---|---|---|
1 | server1.company.com | 9.67.67.101 |
2 | server2.company.com | 9.67.67.102 |
3 | server3.company.com | 9.67.67.103 |
Netmask = 255.255.255.0 |
Nome= www.company.com IP=9.67.67.104
Aggiungere un alias di www.company.com all'interfaccia loopback su server2.company.com e server3.company.com.
ifconfig lo0 alias www.company.com netmask 255.255.255.0
ifconfig lo0:1 www.company.com 127.0.0.1 up
A questo punto, tutte le fasi di configurazione necessarie sulle stazioni di lavoro del server Web sono state portate a termine.
Con il Dispatcher, è possibile creare una configurazione dalla riga comandi, con la configurazione guidata o mediante l'interfaccia utente grafica (GUI).
Se si utilizza la riga comandi:
dscontrol executor start
dscontrol cluster add www.company.com
dscontrol port add www.company.com:80
dscontrol server add www.company.com:80:server2.company.com
dscontrol server add www.company.com:80:server3.company.com
dscontrol executor configure www.company.com
dscontrol manager start
A questo punto, il Dispatcher esegue il bilanciamento del carico in base alle prestazioni del server.
dscontrol advisor start http 80
A questo punto, il Dispatcher garantisce che le richieste client non verranno inviate a un server Web in errore.
La configurazione di base, con i server collegati localmente, è ora completa.
IMPORTANTE: con l'installazione di Load Balancer per IPv4 e IPv6, la sintas si del comando Dispatcher (dscontrol) è identica, ma con un'eccezione importante. Il delimitatore dei comandi dscontrol è il simbolo chiocciola (@) e non i due punti (:). (È stato necessario definire un delimitatore diverso dai due punti perché nel formato IPv6 tale simbolo si utilizza nello schema di indirizzamento).
Ad esempio (dal precedente esempio di configurazione di Dispatcher)
dscontrol port add www.company.com@80
dscontrol server add www.company.com@80@server2.company.com
dscontrol server add www.company.com@80@server3.company.com
Per maggiori informazioni, se si sta utilizzando un'installazione Load Balancer per IPv4 e IPv6, vedere il capitolo relativo alla distribuzione di Dispatcher su Load Balancer per IPv4 e IPv6, che include le informazioni sulle limitazioni e le differenze di configurazione, nella Guida alla gestione per WebSphere Application Server Load Balancer.
Se si utilizza la configurazione guidata, effettuare quanto segue:
dsserver
La procedura guidata illustra nei dettagli come creare una configurazione di base del componente Dispatcher. Inoltre, pone delle domande relativamente alla rete e fornisce le istruzioni su come impostare un cluster del Dispatcher per bilanciare il traffico di un gruppo di server.
La configurazione guidata contiene i seguenti pannelli:
Per avviare la GUI, effettuare quanto segue:
dsserver