WebSphere Application Server

Concetti, pianificazione e installazione per Edge Components

Versione 6.1
GC13-3367-02
Prima edizione (Maggio 2006)

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.

Copyright International Business Machines Corporation 2006. Tutti i diritti riservati.

Indice

Figure
Informazioni su questa guida
Destinatari
Accessibilità
Convenzioni e terminologia utilizzati in questa guida
Panoramica
Introduzione a WebSphere Application Server Edge Components
Caching Proxy
Load Balancer
Dispatcher
CBR (Content Based Routing)
Site Selector
Cisco CSS Controller
Nortel Alteon Controller
Metric Server
Componenti Edge Components e famiglia di prodotti WebSphere
Tivoli Access Manager
WebSphere Portal Server
WebSphere Site Analyzer
WebSphere Transcoding Publisher
Ulteriori informazioni su Application Server ed Edge Components
Concetti e informazioni sui componenti Edge
Memorizzazione nella cache
Configurazioni di base di Caching Proxy
Caching Proxy inverso (configurazione predefinita)
Caching Proxy diretto
Memorizzazione avanzata nella cache
Cluster Caching Proxy con bilanciamento del carico
Memorizzazione nella cache di contenuti dinamici
Altre funzioni di memorizzazione nella cache
Prestazioni di rete
Hardware di rete
Considerazioni sulla memoria
Considerazioni sul disco rigido
Considerazioni sulla rete
Considerazioni sulla CPU
Architettura di rete
Popolarità di un sito Web e considerazioni su carico del server proxy
Considerazioni sul tipo di traffico
Disponibilità
Bilanciamento del carico
Bilanciamento del carico di più host di contenuti
Bilanciamento del carico di più server proxy inversi
Load Balancer con più server proxy diretti
Supporto failover
CBR (Content Based Routing)
Scenari
Rete B2C (Business-to-Consumer)
Fase 1
Fase 2
Fase 3
Soluzione bancaria B2C (Business-to-Client)
Rete portale Web
Installazione di Edge Components
Requisiti di Edge Components
Prerequisiti hardware e software
Uso dei browser con i moduli di configurazione e amministrazione di Caching Proxy
Uso dei browser con la guida in linea di Load Balancer
Installazione di Edge Components mediante il programma di installazione
Uso del programma di installazione per Windows
Uso del programma di installazione per Linux e UNIX
Installazione di Caching Proxy mediante strumenti di assemblaggio del sistema
Disinstallazione di Caching Proxy mediante gli strumenti di sistema
Installazione di Load Balancer mediante strumenti di assemblaggio del sistema
Installazione per AIX
Prima dell'installazione
Procedura di installazione
Installazione per HP-UX
Prima dell'installazione
Procedura di installazione
Installazione per Linux
Prima dell'installazione
Fasi di installazione
Installazione per Solaris
Prima dell'installazione
Fasi di installazione
Creazione di reti con Edge Components
Creazione di una rete Caching Proxy
Flusso di lavoro
Controllo dei sistemi e del software necessari
Creazione di Server 1 (sistemi Linux e UNIX)
Creazione di Server 1 (sistema Windows)
Configurazione di Server 1
Verifica della rete Caching Proxy
Creazione di una rete Load Balancer
Flusso di lavoro
Controllo dei sistemi e del software obbligatori
Configurazione della rete
Configurazione del Dispatcher
Configurazione mediante riga comandi
Configurazione mediante procedura guidata
Configurazione mediante interfaccia utente grafica (GUI)
Verifica della rete Load Balancer
Appendici

Figure

  1. Caching Proxy che funziona da proxy inverso
  2. Caching Proxy che funziona da proxy diretto
  3. Caching Proxy che funziona da proxy diretto trasparente
  4. Caching Proxy che funge da server proxy per un cluster con bilanciamento del carico
  5. Bilanciamento del carico di più host di contenuti
  6. Bilanciamento del carico di più server proxy inversi e host del contenuto
  7. Utilizzo del Dispatcher per il bilanciamento del carico di più caching proxy.
  8. Utilizzo di un Dispatcher primario e di backup per fornire un accesso a Internet ad alta disponibilità.
  9. Collocazione del Dispatcher di backup su una macchina Caching Proxy.
  10. Uso di un Load Balancer principale e di backup per garantire un'elevata disponibilità dei contenuti Web
  11. Collocazione del Load Balancer di backup su un host di contenuti
  12. Instradamento di richieste HTTP con CBR
  13. Bilanciamento del carico delle richieste HTTP instradate con CBR
  14. Rete B2C (Business-to-Consumer) (Fase 1)
  15. Rete B2C (Business-to-Consumer) (Fase 2)
  16. Rete B2C (Business-to-Consumer) (Fase 3)
  17. Soluzione bancaria B2C (Business-to-Consumer)
  18. Portale Web
  19. Rete dimostrativa Caching Proxy
  20. Rete dimostrativa Load Balancer

Informazioni su questa guida

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.

Destinatari

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.

Accessibilità

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:

Convenzioni e terminologia utilizzati in questa guida

Questa documentazione utilizza le seguenti convenzioni tipografiche e di definizione dei tasti.

Tabella 1. Convenzioni utilizzate in questa guida
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à.

Panoramica

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:

Introduzione a WebSphere Application Server Edge Components

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

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

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:

Dispatcher

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.

CBR (Content Based Routing)

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:

Site Selector

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:

Cisco CSS Controller

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:

Nortel Alteon Controller

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:

Metric Server

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.

Componenti Edge Components e famiglia di prodotti WebSphere

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

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

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

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

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.

Ulteriori informazioni su Application Server ed Edge Components

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:

Concetti e informazioni sui componenti Edge

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:

Memorizzazione nella cache

Prestazioni di rete

Disponibilità

CBR (Content Based Routing)

Memorizzazione nella cache

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:

Configurazioni di base di Caching Proxy

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.

Caching Proxy inverso (configurazione predefinita)

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.

Figura 1. Caching Proxy che funziona da proxy inverso
Questa figura rappresenta la configurazione del proxy inverso di base
Legenda: 1--Client   2--Internet   3--Router/Gateway   4--Caching Proxy   5--Cache   6--Host dei contenuti

In 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.

Caching Proxy diretto

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. Caching Proxy che funziona da proxy diretto
Questa illustrazione rappresenta la configurazione proxy diretto di base

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.

Caching Proxy diretto trasparente (solo sistemi Linux)

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.

Figura 3. Caching Proxy che funziona da proxy diretto trasparente
Questa illustrazione rappresenta la configurazione proxy diretto di base

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.

Memorizzazione avanzata nella cache

Cluster Caching Proxy con bilanciamento del carico

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 ).

Figura 4. Caching Proxy che funge da server proxy per un cluster con bilanciamento del carico
La figura qui riportata illustra il server proxy che funge da sostituto di un cluster con bilanciamento del carico
Legenda: 1--Client   2--Internet   3--Router/Gateway   4--Caching Proxy   5--Cache   6--Load Balancer   7--Host di contenuti

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, 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.

Memorizzazione nella cache di contenuti dinamici

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.

Nota:
le pagine private generate in modo dinamico (quali pagine che visualizzano i contenuti del carrello d'acquisto di un utente) generalmente non potrebbero né dovrebbero essere memorizzate nella cache da Caching Proxy. Caching Proxy può memorizzare nella cache e supportare pagine private solo se configurato per eseguire l'autenticazione e l'autorizzazione, per garantire che tali pagine verranno supportate solo per quegli utenti specifici.

Altre funzioni di memorizzazione nella cache

Caching Proxy offre altre importanti funzioni avanzate di memorizzazione nella cache:

Prestazioni di rete

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:

Hardware di rete

Questa sezione illustra alcune problematiche inerenti l'hardware di rete da tenere in considerazione durante l'introduzione della funzionalità di Caching Proxy nella rete.

Considerazioni sulla memoria

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.

Considerazioni sul disco rigido

È 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.

Considerazioni sulla rete

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.

Considerazioni sulla CPU

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.

Architettura di rete

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.

Popolarità di un sito Web e considerazioni su carico del server proxy

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.

Considerazioni sul tipo di traffico

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.

Disponibilità

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:

Bilanciamento del carico

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.

Bilanciamento del carico di più host di contenuti

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).

Figura 5. Bilanciamento del carico di più host di contenuti
La figura qui riportata illustra il bilanciamento del carico di più host di contenuti
Legenda: 1--Client   2--Internet   3--Router/Gateway   4--Dispatcher   5--Host di contenuti
Nota:
il Dispatcher fornisce tre metodi di inoltro:

Per 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.

Bilanciamento del carico di più server proxy inversi

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).

Figura 6. Bilanciamento del carico di più server proxy inversi e host del contenuto
La figura qui riportata illustra il bilanciamento del carico di più server proxy e host di contenuti
Legenda: 1--Client   2--Internet   3--Router/Gateway   4--Dispatcher   5--server proxy   6--Cache   7--Dispatcher   8--Host di contenuti

Il 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.

Load Balancer con più server proxy diretti

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

Nota:
La funzione proxy trasparente è disponibile solo su sistemi Linux.
Figura 7. Utilizzo del Dispatcher per il bilanciamento del carico di più caching proxy.
Questo grafico illustra il bilanciamento del carico di più proxy

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.

Figura 8. Utilizzo di un Dispatcher primario e di backup per fornire un accesso a Internet ad alta disponibilità.
Questo grafico illustra un Dispatcher primario e uno dibackup per bilanciare il carico di più proxy

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.

Figura 9. Collocazione del Dispatcher di backup su una macchina Caching Proxy.
Questo grafico illustra un Dispatcher primario e uno dibackup per bilanciare il carico di più proxy

Supporto failover

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.

Figura 10. Uso di un Load Balancer principale e di backup per garantire un'elevata disponibilità dei contenuti Web
La figura qui visualizzata illustra l'uso del Dispatcher principale e di backup per garantire un'elevata disponibilità dei contenuti Web
Legenda: 1--Client   2--Internet   3--Router/Gateway   4--Dispatcher principale   5--Dispatcher di backup   6--Host di contenuti

Normalmente, 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.

Figura 11. Collocazione del Load Balancer di backup su un host di contenuti
La figura qui riportata illustra un Dispatcher di backup in esecuzione su un host di contenuti
Legenda: 1--Client   2--Internet   3--Router/Gateway   4--Dispatcher principale   5--Dispatcher di backup e host di contenuti   6--Host di contenuti

CBR (Content Based Routing)

IMPORTANTE: il componente CBR (Content Based Routing) è disponibile su tutte le piattaforme supportate con le seguenti eccezioni:

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.

Figura 12. Instradamento di richieste HTTP con CBR
La figura qui riportata illustra l'instradamento di richieste HTTP con CBR
Legenda: 1--Client   2--Internet   3--Router/Gateway   4--Componenti CBR di Caching Proxy e Load Balancer   5--Cache   6, 7, 8--Host di contenuti

La 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.

Figura 13. Bilanciamento del carico delle richieste HTTP instradate con CBR
La figura qui riportata illustra il bilanciamento del carico di richieste HTTP instradate con CBR
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 Web

La 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).

Scenari

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)

Rete portale Web

Rete B2C (Business-to-Consumer)

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:

Fase 1

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.

Figura 14. Rete B2C (Business-to-Consumer) (Fase 1)
Questa illustrazione rappresenta una rete B2C (Business-to-Consumer) di base di esempio

Fase 2

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.

Figura 15. Rete B2C (Business-to-Consumer) (Fase 2)
Questa illustrazione rappresenta una rete B2C (Business-to-Consumer) di esempio

Fase 3

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.

Figura 16. Rete B2C (Business-to-Consumer) (Fase 3)
Questa illustrazione rappresenta una rete B2C (Business-to-Consumer) di esempio

Soluzione bancaria B2C (Business-to-Client)

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:

Figura 17. Soluzione bancaria B2C (Business-to-Consumer)
Questa illustrazione rappresenta una soluzione bancaria B2C (Business-to-Consumer) di esempio

Rete portale Web

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:

Figura 18. Portale Web
Questa illustrazione rappresenta un portale Web di esempio

Installazione di Edge Components

Questa sezione contiene le procedure per l'installazione di Edge Components.

Questa sezione contiene i seguenti capitoli:

Requisiti di Edge Components

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

Requisiti di Edge Components

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.

Prerequisiti hardware e software

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.

Uso dei browser con i moduli di configurazione e amministrazione di Caching Proxy

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.

Nota:
Su sistemi PowerPC Linux da 64-bit, non sarà possibile accedere ai moduli di Configurazione e amministrazione con il browser Mozilla poiché non è disponibile alcun SDK per questa architettura. In alternativa, è possibile accedere ai moduli di Configurazione e amministrazione da macchine differenti dotate di un browser Web supportato.

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:

  1. Collegarsi a http://plugindoc.mozdev.org
  2. Selezionare la piattaforma dalla sezione "Documentation"
  3. Attenersi alle istruzioni elencate nella sezione "Java Runtime Environment" per aggiornare il plug-in

Uso dei browser con la guida in linea di Load Balancer

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.

Installazione di Edge Components mediante il programma di installazione

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:

Uso del programma di installazione per Windows

Utilizzare il programma di installazione per installare Edge Components sul sistema Windows nel modo seguente:

  1. Verificare che il sistema Windows soddisfi tutti i requisiti hardware e software (Requisiti di Edge Components).
  2. Collegarsi come utente con privilegi di amministratore.
  3. Inserire il CD-ROM Edge Components nell'unità CD-ROM della macchina. Lo strumento LaunchPad si avvia automaticamente.
  4. Fare clic su Avvia l'installazione guidata per WebSphere Application Server - Edge Components. Il programma di installazione si avvia automaticamente. Esso prepara la procedura guidata InstallShield e apre la finestra iniziale.
    Nota:
    Se la macchina non supporta l'opzione Autoplay oppure se l'opzione è disattivata, avviare manualmente programma di installazione eseguendo il file setup.exe ubicato nella directory principale del CD-ROM.
  5. Fare clic su Avanti per proseguire l'installazione. Viene visualizzata la finestra del contratto di licenza software.
  6. Leggere attentamente il documento, quindi fare clic su per accettarne i termini. Viene visualizzata la finestra per la selezione dei componenti.

    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.

  7. Selezionare i componenti da installare.
  8. Per modificare la scelta dei sottocomponenti da installare per un determinato componente, fare clic sul nome del componente per selezionarlo, quindi su Modifica sottocomponenti. Viene visualizzata un'altra finestra per la selezione dei componenti, che mostra i sottocomponenti del componente attivo. Utilizzare le medesime procedure per selezionare i sottocomponenti, oltre che la lingua e il percorso dei componenti da installare.
  9. Utilizzare i menu Lingua corrente per selezionare la lingua o le lingue in cui si desidera installare Edge Components. Le lingue disponibili sono visualizzate nel menu a sinistra. Le lingue selezionate vengono visualizzate nel menu a destra.
  10. Utilizzare la finestra per la selezione dei componenti per verificare il percorso di installazione di Edge Components. È possibile confermare i valori predefiniti o specificare un nuovo percorso facendo clic su Modifica cartella.
    Nota:
    se si seleziona un percorso di installazione diverso da quello predefinito, accertarsi che il nome percorso non contenga spazi, ad esempio, evitare nomi percorso quali C:\My Files\edgeserver\.
  11. Utilizzare la finestra per la selezione dei componenti per verificare che lo spazio a disposizione nel percorso di installazione selezionato sia sufficiente. In caso contrario, fare clic su Modifica cartella e specificare un nuovo percorso di installazione.
  12. Dopo aver selezionato i componenti di Edge Components, il percorso di installazione e le lingue, fare clic su Avanti. Riesaminare le informazioni nella finestra di conferma dell'installazione visualizzata. Per modificare le scelte, fare clic su Indietro per tornare alla finestra di selezione dei componenti e apportare le modifiche necessarie. Dopo aver verificato le selezioni, fare clic su Fine.
  13. Il Programma di installazione del prodotto Edge Components avvia l'installazione dei componenti di Edge Components selezionati e di GSK, se necessario, nel percorso di installazione specificato.
  14. Viene visualizzata la finestra Installazione completata. Se si desidera consultare il file ReadMe di Edge Components, verificare che la casella di controllo Sì, desidero visualizzare il file ReadMe sia selezionata. Il file ReadMe viene visualizzato nel browser predefinito.
  15. Verificare che la casella di controllo Sì, desidero riavviare il computer sia selezionata, quindi fare clic su Fine. Se si decide di visualizzare il file ReadMe, la macchina viene riavviata alla chiusura della finestra del browser che visualizza il file. Altrimenti, il Programma di installazione del prodotto Edge Components viene chiuso immediatamente e la macchina viene riavviata. Tenere presente che è necessario riavviare la macchina prima di poter utilizzare i componenti Edge Components appena installati.

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.

Uso del programma di installazione per Linux e UNIX

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:

  1. Verificare che il server soddisfi tutti i requisiti hardware e software descritti in Requisiti di Edge Components.
  2. Collegarsi come superuser, ossia, nella maggior parte dei casi, root.
  3. Inserire il CD-ROM di Edge Components nell'unità CD-ROM. Se necessario, montare il CD-ROM.
  4. Passare dalla directory di lavoro alla directory principale del CD-ROM.
  5. Richiamare il programma di installazione immettendo il seguente comando:
    # ./install
    Viene visualizzata la finestra iniziale.
  6. Fare clic su Avanti per proseguire l'installazione. Viene visualizzata la finestra del contratto di licenza software.
  7. Leggere attentamente il documento, quindi fare clic su per accettarne i termini. Viene visualizzata la finestra Selezione della lingua.
  8. Selezionare le lingue che dovranno essere supportate da questa installazione di Edge Components. Fare clic su Avanti. Viene visualizzata la finestra per la selezione dei componenti.
  9. Selezionare i componenti da installare.
  10. Fare clic su Avanti. Viene visualizzata la finestra di conferma dell'installazione.
  11. Riesaminare le informazioni nella finestra di conferma dell'installazione. Per modificare le scelte, fare clic su Indietro per tornare alla finestra di selezione dei componenti e apportare le modifiche necessarie. Dopo aver verificato le selezioni, fare clic su Continua.

    Il programma di installazione avvia l'installazione dei componenti Edge Components selezionati e dei pacchetti necessari.

  12. Viene visualizzata la finestra di riepilogo dei risultati dell'installazione. Verificare i risultati, quindi fare clic su Fine.

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:

  1. Fare clic sul pulsante X, nell'angolo in alto a destra del pannello, per chiudere il programma di installazione.
  2. Alla domanda "Uscire?" rispondere .
  3. Riavviare il programma di installazione senza ingrandire e ridurre le dimensioni del pannello.

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.

Installazione di Caching Proxy 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à.

  1. Inserire il CD Edge Components nell'unità CD-ROM e, se necessario, montare l'unità.
  2. Utilizzare root superuser locale.
    su - root
    
    Password: password
  3. Passare alla directory appropriata sul CD.
    cd punto_caricamento/directory_pacchetto/
  4. Installare i pacchetti.

    Su AIX:

    installp -acXd ./nomePacchetto

    Su HP-UX:

    swinstall -s source/ nomePacchetto

    Su Linux:

    rpm -i ./nomePacchetto

    Su Solaris:

    pkgadd -d ./nomePacchetto
Tabella 2. Componenti Caching Proxy
Componente Pacchetti installati (nell'ordine consigliato)
Caching Proxy
  1. gskit7
  2. icu
  3. admin
  4. msg-cp-lang
  5. cp
Documentazione di Edge Components

doc-en_US1

Note:
  1. La documentazione Load Balancer viene fornita in due pacchetti. Il pacchetto doc-en_US comprende la documentazione di Edge Components, compresa la documentazione di Load Balancer, nella directory ../edge/doc/. Il pacchetto della documentazione associato alle installazioni di Load Balancer (Installazione di Load Balancer mediante strumenti di assemblaggio del sistema) installa soltanto la documentazione di Load Balancer in una sottodirectory all'interno della directory ../edge/lb/.
Tabella 3. Nomi file pacchetto AIX, HP-UX e Solaris
Nome pacchetto generico Fileset AIX Fileset HP-UX Nome file Solaris
admin wses_admin.rte WSES-ADMIN WSESadmin
cp wses_cp.base WSES-CP WSEScp
doc wses_doc.en_US WSES-DOC-en_US WSESdocen
gskit7 gskkm.rte gsk7bas gsk7bas
icu wses_icu.rte WSES-ICU WSESicu
msg-cp-lang wses_cp.msg.lang1 .base WSES-cpmlang2 WSEScpmlang3
Note:
  1. Su AIX, la variabile lang fa riferimento a uno dei seguenti codici di lingua: en_US, de_CH, de_DE, es_ES, fr_CA, fr_CH, fr_FR, it_CH, it_IT, ja_JP, Ja_JP, ko_KR, pt_BR, zh_CN, ZH_CN, zh_TW, Zh_TW.
  2. Su HP-UX, la variabile lang fa riferimento a uno dei seguenti codici di lingua: de_DE, en_US, es_ES, fr_FR, it_IT, ja_JP, ko_KR, zh_CN, zh_TW. (HP-UX non supporta il Portoghese Brasiliano (pt_BR).)
  3. Sulla piattaforma Solaris, la variabile lang si riferisce alla sostituzione di uno dei seguenti codici specifici della lingua: br, cn, cw, de, en, es, fr, it, ja, kr.
Tabella 4. Nomi file pacchetto Linux
Nome pacchetto generico Nome file Linux
admin WSES_Admin_Runtime-versione-rilascio1.hardw2.rpm
cp WSES_CachingProxy-versione-rilascio1.hardw2.rpm
doc WSES_Doc_en_US-versione-rilascio1.hardw2.rpm
gskit7 gsk7bas.rpm
icu WSES_ICU_Runtime-versione-rilascio1.hardw2.rpm
msg-cp-lang WSES_CachingProxy_msg_lang3-versione-rilascio1.hardw2.rpm
Note:
  1. versione-rilascio è il rilascio corrente, ad esempio 6.1.0-0
  2. La variabile hardw fa riferimento a i686, s390 o ppc64.
  3. La variabile lang fa riferimento a uno dei seguenti codici di lingua: de_DE, en_US, es_ES, fr_FR, it_IT, ja_JP, ko_KR, pt_BR, zh_CN, zh_TW.

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.

Disinstallazione di Caching Proxy mediante gli strumenti di sistema

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.

Installazione di Load Balancer mediante strumenti di assemblaggio del sistema

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.

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.

Installazione per AIX

Tabella 5 riporta i fileset AIX per Load Balancer e l'ordine di installazione consigliato utilizzando lo strumento di installazione dei pacchetti del sistema.

Tabella 5. Fileset AIX
Componenti Load Balancer Fileset AIX
Base ibmlb.base.rte
Amministrazione (con messaggi)
  • ibmlb.admin.rte
  • ibmlb.msg.lang.admin
Driver unità ibmlb.lb.driver
Licenza ibmlb.lb.license
Componenti Load Balancer (con messaggi)
  • ibmlb.componente.rte
  • ibmlb.msg.lang.lb
Documentazione (con messaggi)
  • ibmlb.doc.rte
  • ibmlb.msg.en_US.doc
Metric Server ibmlb.ms.rte
Note:
  1. Per la variabile component, è possibile sostituire quanto riportato di seguito: disp (dispatcher), cbr (CBR), ss (Site Selector), cco (Cisco CSS Controller) o nal (Nortel Alteon Controller).
  2. La variabile lang fa riferimento a en_US, de_CH, de_DE, es_ES, fr_CA, fr_CH, fr_FR, it_CH, it_IT, ja_JP, Ja_JP, ko_KR, pt_BR, zh_CN, ZH_CN, zh_TW, Zh_TW

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 dell'installazione

Prima di installare Load Balancer per AIX, verificare quanto segue:

Nel momento in cui si disinstalla il prodotto, è possibile scegliere di installare uno o tutti i componenti elencati di seguito:

Procedura di installazione

Per installare Load Balancer per AIX si consiglia di utilizzare SMIT, dal momento che questo garantisce l'installazione automatica di tutti i messaggi.

Uso di SMIT per installare Load Balancer per AIX

  1. Selezionare Software Installation and Maintenance.
  2. Selezionare Install and Update Software.
  3. Selezionare Install and update from latest Available Software.
  4. Immettere l'unità o la directory contenente i fileset.
  5. Nel campo *SOFTWARE to Install, inserire le informazioni appropriate per specificare le opzioni (o selezionare List).
  6. Premere OK.
  7. Completato il comando, premere Done.
  8. Chiudere SMIT selezionando Exit Smit dal menu Exit oppure premere F12. Se si adopera SMITTY, premere F10 per chiudere il programma.

Installazione di Load Balancer dalla riga comandi

  1. Se si esegue l'installazione da un CD, immettere il seguente comando per caricarlo:
    mkdir /cdrom
    
    mount -v cdrfs -p -r /dev/cd0 /cdrom
  2. Fare riferimento alla tabella riportata di seguito per determinare il comando o i comandi da immettere per installare i pacchetti Load Balancer desiderati per AIX:
    Tabella 6. Comandi di installazione AIX
    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
    dove per unità si intende:
  3. Accertarsi che la colonna dei risultati del riepilogo contenga SUCCESS per ciascun componente di Load Balancer che si sta installando (APPLYing). Non proseguire finché tutti i componenti desiderati non verranno installati.
    Nota:
    per creare un elenco di fileset su un'unità specificata, tra cui tutti i cataloghi messaggi disponibili, immettere
    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:

Installazione per HP-UX

In questa sezione viene illustrato come installare Load Balancer su HP-UX mediante il CD del prodotto.

Prima dell'installazione

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.

Procedura di installazione

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.

Tabella 7. Dettagli sull'installazione del pacchetto HP-UX per Load Balancer
Descrizione pacchetto Nome pacchetto HP-UX
Base ibmlb.base
Gestione e messaggi ibmlb.admin ibmlb.nlv-lang
Licenza di Load Balancer ibmlb.lic
Componenti Load Balancer ibmlb.componente
Documentazione ibmlb.doc
Metric Server ibmlb.ms
Note:
  1. La variabile lang fa riferimento a uno dei seguenti codici di lingua: de_DE, es_ES, fr_FR, it_IT, ja_JP, ko_KR, zh_CN, zh_TW.
  2. La variabile componente fa riferimento alla sostituzione di: disp (dispatcher), cbr (CBR), ss (Site Selector), cco (Cisco CSS Controller) o nal (Nortel Alteon Controller).
  3. Il pacchetto della documentazione (ibmlb.doc) 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.

HP-UX non supporta le impostazioni internazionali in Portoghese brasiliano (pt_BR). Le impostazioni internazionali supportate su HP-UX sono:

Istruzioni per l'installazione dei pacchetti

La procedura riportata di seguito illustra le operazioni necessarie al completamento di questa attività.

  1. Utilizzare root superuser locale.
    su - root
    
    Password: password
  2. Per installare i pacchetti, immettere il comando di installazione

    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
  3. Verificare l'installazione dei pacchetti Load Balancer

    Emettere il comando swlist per elencare tutti i pacchetti installati. Ad esempio,

    swlist -l fileset ibmlb
    
    

Istruzioni per la disinstallazione dei pacchetti

Utilizzare il comando swremove per disinstallare i pacchetti. I pacchetti devono essere rimossi nell'ordine inverso rispetto all'installazione. Ad esempio, emettere quanto segue:

Tra i percorsi di installazione di Load Balancer sono inclusi:

Installazione per Linux

In questa sezione viene illustrato come installare Load Balancer su Linux mediante il CD di Edge Components.

Prima dell'installazione

Prima di installare Load Balancer, verificare quanto segue:

Fasi di installazione

  1. Inserire il supporto Edge Components o scaricare il prodotto dal sito Web e installare l'immagine di installazione utilizzando RPM (Red Hat Packaging Manager).

    L'immagine di installazione è un file nel formato lblinux-versione.tar.

  2. Decomprimere il file in una directory temporanea con l'immissione del seguente comando:
    tar -xf lblinux-versione.tar
    Il 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.

  3. Dalla directory su cui risiedono i file RPM, emettere il comando per installare ciascun pacchetto. Ad esempio:
    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.

    Nota:
    almeno uno dei file RPM richiede l'installazione e la registrazione di Java nel database RPM. Se Java è installato ma non è registrato nel database RPM, utilizzare il comando di installazione senza l'opzione delle dipendenze, come segue:
    rpm
    
    -i --nodeps pacchetto.rpm 
  4. Verificare che il prodotto sia installato. Immettere il seguente comando:
    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.

Installazione per Solaris

In questa sezione viene illustrato come installare Load Balancer su Solaris mediante il CD di Edge Components.

Prima dell'installazione

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

Fasi di installazione

  1. Inserire il CD-ROM contenente il software Load Balancer nell'apposita unità.
  2. Al prompt di comandi, immettere:
    pkgadd -d nomepercorso
    dove 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 . È necessario installare i pacchetti prerequisiti (dal momento che l'installazione segue l'ordine alfabetico e non quello dei prerequisiti). Se si immette tutti, rispondere 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.

  3. Verificare che il prodotto sia installato. Digitare i seguenti comandi:
    pkginfo | grep ibm

Tra i percorsi di installazione di Load Balancer sono inclusi:

Creazione di reti con Edge Components

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.

Creazione di una rete Caching Proxy

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:

Figura 19. Rete dimostrativa Caching Proxy
Caching ProxyRete dimostrativa

Flusso di lavoro

Per creare una rete Caching Proxy, eseguire le seguenti procedure nell'ordine descritto:

  1. Controllo dei sistemi e del software necessari.
  2. Creazione di Server 1 (sistemi Linux e UNIX) o Creazione di Server 1 (sistema Windows).
  3. Configurazione di Server 1.
  4. Verifica della rete Caching Proxy.

Controllo dei sistemi e del software necessari

I computer e i componenti software riportati di seguito sono obbligatori:

Creazione di Server 1 (sistemi Linux e UNIX)

Installare e configurare Caching Proxy come indicato di seguito:

  1. Accertarsi che il server soddisfi tutti i requisiti hardware e software.
  2. Collegarsi come superuser, ossia, nella maggior parte dei casi, root.
  3. Installare il componente Caching Proxy.
  4. Creare un'identità e una password dell'amministratore per accedere ai moduli Configurazione e amministrazione immettendo il seguente comando:
    # 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.

  5. Proseguire con Configurazione di Server 1.

Creazione di Server 1 (sistema Windows)

Installare e configurare Caching Proxy come indicato di seguito:

  1. Verificare che i sistemi operativi Windows 2000 e Windows 2003 soddisfino tutti i requisiti hardware e software.
  2. Collegarsi come utente con privilegi di amministratore.
  3. Installare il componente Caching Proxy.
  4. Creare un'identità e una password dell'amministratore per accedere ai moduli Configurazione e amministrazione immettendo il seguente comando:
    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.

  5. Proseguire con Configurazione di Server 1.

Configurazione di Server 1

Dalla stazione di lavoro, effettuare quanto segue:

  1. Avviare un browser Web.
  2. Nel campo Indirizzo del browser, immettere http://server_1, dove server_1 indica il nome host o l'indirizzo IP effettivo della macchina designata come Server 1.
  3. Fare clic su Moduli di Configurazione e amministrazione.
  4. Immettere il nome e la password dell'amministratore. Nel browser vengono visualizzati i moduli di Configurazione e amministrazione.
  5. Fare clic su Configurazione server-->Elaborazione richiesta-->Instradamento richiesta.
  6. Inserire una nuova regola di mappatura dei caratteri jolly prima di quella esistente selezionando il pulsante di opzione Inserisci prima e il valore di indice della regola esistente.
  7. Selezionare Proxy dalla casella a discesa Azione.
  8. Immettere /* nel campo maschera richiesta URL.
  9. Immettere il nome host del sito a cui reindirizzare le richieste HTTP nel campo Indirizzo IP o nome host del server. Far precedere questo valore da http://.
  10. Fare clic su Inoltra.
  11. Creare una regola di mappatura che consenta di accedere ai moduli di Configurazione e amministrazione selezionando il pulsante di opzione Inserisci prima e il valore di indice della regola di mappatura creata al punto 6.
  12. Selezionare Passa dalla casella a discesa Azione.
  13. Immettere /pub/* nel campo maschera URL.
  14. Inserire il percorso dei moduli di Configurazione e amministrazione:
  15. Fare clic su Inoltra.
  16. Fare clic sull'icona Riavviare il server sulla parte superiore del modulo di configurazione.
  17. Proseguire con Verifica della rete Caching Proxy.

Verifica della rete Caching Proxy

Dalla stazione di lavoro, effettuare quanto segue:

  1. Avviare un browser Web.
  2. Immettere http://server_1 nel campo Indirizzo del browser. Le pagine HTML di Server 2 verranno inviate tramite proxy a Server 1 e distribuite al browser Web.
  3. Per accedere ai moduli di Configurazione e amministrazione, immettere http://server_1/pub/ nel campo Indirizzo del browser. Viene visualizzata la home page dei moduli Configurazione e amministrazione.

Creazione di una rete Load Balancer

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.

Figura 20. Rete dimostrativa Load Balancer
Un'illustrazione che rappresenta un client, una nuvola che rappresenta Internet, una macchina Load Balancer e due server collegati localmente con indirizzi identificati.
Nota:
questa configurazione può essere completata utilizzando solo due stazioni di lavoro con il Dispatcher collocato su una delle stazioni di lavoro del server Web. Si tratta di una configurazione in co-locazione.

Flusso di lavoro

Per creare una rete Load Balancer, eseguire le procedure riportate di seguito nell'ordine indicato:

  1. Controllo dei sistemi e del software obbligatori.
  2. Configurazione della rete.
  3. Configurazione del Dispatcher.
  4. Verifica della rete Load Balancer.

Controllo dei sistemi e del software obbligatori

I sistemi e i componenti software riportati di seguito sono obbligatori:

Configurazione della rete

  1. Impostare le stazioni di lavoro in modo che si trovino sullo stesso segmento LAN. Verificare che il traffico di rete tra le tre macchine non debba attraversare router o bridge.
  2. Configurare gli adattatori di rete delle tre stazioni di lavoro. Ad esempio, con la seguente configurazione di rete:
    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
    Ciascuna stazione di lavoro contiene solo una scheda interfaccia di rete Ethernet standard.
  3. Verificare che server1.company.com possa eseguire il ping su server2.company.com e server3.company.com.
  4. Verificare che server2.company.com e server3.company.com possa eseguire il ping su server1.company.com.
  5. Accertarsi che il contenuto sui due server Web (Server 2 e Server 3) sia identico. Ciò può essere eseguito replicando i dati su entrambe le stazioni di lavoro, utilizzando un file system condiviso, ad esempio NFS, AFS o DFS oppure mediante altri strumenti adatti al sito.
  6. Verificare che i server Web su server2.company.com e server3.company.com siano operativi. Utilizzare un browser Web per richiedere le pagine direttamente da http://server2.company.com e http://server3.company.com.
  7. Acquisire un indirizzo IP valido per questo segmento LAN. Si tratta dell'indirizzo fornito ai clienti che intendono accedere al sito. In questo esempio, le informazioni sono le seguenti:
    Nome= www.company.com
    
    IP=9.67.67.104  
  8. Configurare le due stazioni di lavoro del server Web in modo che accettino il traffico di www.company.com.

    Aggiungere un alias di www.company.com all'interfaccia loopback su server2.company.com e server3.company.com.

  9. Eliminare eventuali instradamenti supplementari che potrebbero essere stati prodotti come risultato dell'aggiunta dell'alias all'interfaccia loopback.

    A questo punto, tutte le fasi di configurazione necessarie sulle stazioni di lavoro del server Web sono state portate a termine.

Configurazione del Dispatcher

Con il Dispatcher, è possibile creare una configurazione dalla riga comandi, con la configurazione guidata o mediante l'interfaccia utente grafica (GUI).

Nota:
i valori dei parametri devono essere immessi utilizzando l'alfabeto inglese. Le uniche eccezioni sono rappresentate dai nomi host e dai nomi file.

Configurazione mediante riga comandi

Se si utilizza la riga comandi:

  1. Avviare dsserver sul Dispatcher:

  2. Avviare la funzione executor del Dispatcher:
    dscontrol executor start
  3. Aggiungere l'indirizzo cluster alla configurazione del Dispatcher:
    dscontrol
    
    cluster add www.company.com
  4. Aggiungere la porta del protocollo http alla configurazione del Dispatcher:
    dscontrol port add www.company.com:80
  5. Aggiungere ciascun server Web alla configurazione del Dispatcher:
    dscontrol server add www.company.com:80:server2.company.com
    dscontrol server
    
    add www.company.com:80:server3.company.com
  6. Configurare la stazione di lavoro in modo che accetti il traffico dell'indirizzo cluster:
    dscontrol executor configure www.company.com
  7. Avviare la funzione gestore del Dispatcher:
    dscontrol manager start

    A questo punto, il Dispatcher esegue il bilanciamento del carico in base alle prestazioni del server.

  8. Avviare la funzione advisor del Dispatcher:
    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)

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.

Configurazione mediante procedura guidata

Se si utilizza la configurazione guidata, effettuare quanto segue:

  1. Avviare dsserver sul Dispatcher:

  2. Avviare la funzione della procedura guidata del Dispatcher, dswizard.

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:

Configurazione mediante interfaccia utente grafica (GUI)

Per avviare la GUI, effettuare quanto segue:

  1. Verificare che il processo dsserver sia in esecuzione:
  2. Quindi, effettuare una delle seguenti operazioni:

Verifica della rete Load Balancer

  1. Da un browser Web, andare all'indirizzo http://www.company.com e verificare che sia possibile visualizzare una pagina.
  2. Ricaricare la pagina nel browser Web.
  3. Immettere il comando: dscontrol server report www.company.com:80: . Verificare che somma totale della colonna connessioni dei due server sia 2.

Appendici