Come bilanciare i protocolli

Introduzione

Questo documento descrive le impostazioni di Oplon ADC per bilanciare i protocolli di rete più utilizzati a livello 4 OSI (port forwarding). Il trattamento del protocollo HTTP/S layer 7 OSI non è trattato in questo manuale essendo connaturato in Oplon ADC ed ampiamente descritto nella white paper con le sue molteplici configurazioni e politiche di bilanciamento. Per la trattazione e approfondimento dei singoli parametri si rimanda a Oplon ADC Reference Guide.

Il documento vuole essere un riferimento essendoci per ogni protocollo moltissime varianti di configurazione in dipendenza dell'utilizzo che se ne vuole fare, il risultato che si vuole ottenere e dalle caratteristiche dell'infrastruttura di rete ed i servizi preesistenti.

Le descrizioni dell'evoluzione delle connessioni nei differenti protocolli è volutamente semplificata agli elementi utili per porre in bilanciamento ed in alta affidabilità i servizi erogati con i protocolli presi in considerazione. Per chi volesse approfondire con maggiori dettagli si rimanda alle specifiche originali RFC ed IETF.

Oplon ADC permette di avere per ogni protocollo e/o gruppo di servizi dei parametri diversificati. E' quindi possibile utilizzare in maniera più flessibile differenti servizi di backend attribuendo ad ognuno di essi le proprie caratteristiche di affinità di sessione e calibrare i time-out in relazione alla qualità complessiva del servizio in particolare.

È inoltre possibile utilizzare i template facilitando enormemente la parametrizzazione. I template possono sfruttare un profilo di connessione preesistente modificando solo alcuni parametri e per differenza generano un ulteriore profilo. Oplon ADC crea automaticamente alla partenza alcuni profili utilizzabili da subito senza alcun ulteriore intervento. Anche questi profili possono essere utilizzati come template per crearne dei nuovi profili adattati alle esigenze specifiche. I profili attualmente preimpostati sono: HTTP/S; FTP; RDP con session affinity; RDP senza session affinity; SSH; Telnet;DNS;LDAP; UDP.

In questo documento verranno utilizzati, dove disponibili, i profili preimpostati per maggiore semplicità. Nel capitolo dedicato al protocollo LDAP c'è un esempio di riutilizzo attraverso "template" di parametri derivati da un altro gruppo. Questa tecnica è ovviamente utilizzabile in tutte le occasioni in cui alcuni parametri non dovessero soddisfare le specifiche necessità dell'installazione. Nel capitolo LDAP c'è inoltre un esempio di utilizzo della policy di bilanciamento "FailOver". Anche quest'ultima possibilità è utilizzabile nei protocolli descritti o in altri protocolli personalizzati.

FTP (File Transfer Protocol)

Il protocollo FTP è un protocollo nato per scambiare file tra macchine eterogenee.

Il protocollo distingue due flussi con connessioni indipendenti, il Flusso Comandi ed il Flusso Dati. Per ognuno di questi flussi vengono stabilite delle connessioni indipendenti. L'evoluzione di queste connessioni può avvenire in due modi; Active-mode oppure Passive-mode.

Connessioni FTP Active-mode

L'evoluzione del flusso delle informazioni del protocollo FTP in Active-mode, chiamato anche "client-managed", inizia con il client che invia al server un indirizzo/porta a lui noto al quale il server deve inviare i dati. Nello schema sotto riportato si evidenzia questo tipo di flusso indicando in rosso chi prende l'iniziativa ed instaura la connessione.

Il Client si connette al Server FTP alla porta 21 e spedisce al Server la proposta di indirizzo/porta temporanea (es.6060) a cui il Server deve connettersi per eseguire il comando di trasferimento dati
Il Server risponde con un ACK.
Il Server si connette all'indirizzo/porta temporanea (es.6060) passato in precedenza per eseguire il comando
In dipendenza del comando vengono trasferiti i dati attraverso la connessione instaurata all'indirizzo/porta temporanea (es.6060)

La connessione Active-mode è normalmente l'impostazione di default di un FTP server. Questo tipo di connessione vede i suoi limiti quando siamo in presenza di uno o più Firewall in quanto normalmente in un datacenter solamente alcune porte note sono aperte in uscita. Sul lato client le connessioni in listen sono comunque normalmente disabilitate dal Firewall interno del client rendendo impossibile di fatto la comunicazione.

Per questa ragione è stato sviluppato anche un modo diverso di evoluzione della connessione per poter ovviare a questi limiti: FTP "Passive-mode".

Connessioni FTP Passive-mode In Passive-mode o "server-managed" il flusso della comunicazione inizia con la connessione del Client verso il Server e quest'ultimo risponde al Client con un suo indirizzo/porta prestabiliti su cui il Client può eseguire delle nuove connessioni per poter trasferire il flusso Dati in base al comando utilizzato.

Il Client si connette al Server FTP alla porta 21 e spedisce al Server la proposta di connessione all'indirizzo/porta temporanea (es.6060) a cui il Server dovrebbe connettersi per eseguire il comando di trasferimento dati
Il Server non risponde alla proposta del client e invia la propria proposta di connessione PASV al proprio indirizzo/porta (es.6161) per il trasferimento dati
Il Client con una nuova connessione verso il Server da seguito al comando
Il Server in base al comando spedisce un ACK e da seguito al flusso

Quest'ultimo modo di instaurare il flusso di comunicazione, che vede il Client come colui che prende l'iniziativa ed effettua le connessioni verso il Server, è la soluzione, leggermente più elaborata come vedremo in seguito, che permette ai Datacenter di salvaguardare l'efficienza del protocollo FTP nel trasferimento dei dati e nel contempo salvaguardare scalabilità, alta affidabilità e sicurezza potendo utilizzare indirizzi in NAT (Network Address Translation) a valle di un Firewall. Infatti nel punto [2] il Server FTP può suggerire non solo la porta ma anche un indirizzo a cui collegarsi che può essere diverso dal proprio, ad esempio l'indirizzo in cui è in ascolto Oplon ADC.

A questo proposito di seguito gli schemi di due istanti dello stesso scenario in cui viene fatta la prima richiesta di trasferimento schedulata da Oplon ADC nel ServerA mentre nella successiva immagine viene schedulata nel ServerB.

Il Client si connette al Server FTP alla porta 21 e spedisce al Server la proposta di indirizzo/porta temporanea (es.6060) a cui il Server dovrebbe connettersi per eseguire il comando di trasferimento dati
Oplon ADC, in base alle politiche di instradamento, esegue una connessione al ServerA alla porta 2121
Il ServerA non raccoglie la proposta del Client e risponde con la sua proposta di connessione PASV (passive) all'indirizzo Oplon ADC /porta (es.6161) per il trasferimento dati
Oplon ADC trasferisce l'informazione al Client
Il Client con una nuova connessione verso Oplon ADC (porta 6161) dà seguito al comando
Oplon ADC schedula, in base alle policy di instradamento, la connessione dati verso il ServerA/porta (es.6161)
Il ServerA trasferisce i dati verso Oplon ADC dalla porta 6161
Oplon ADC esegue il forward dei dati verso il Client dalla porta 6161

Di seguito lo schema dello stesso flusso alla seconda richiesta di connessione e trasferimento.

Si può notare che i Listener Dati nei Server A e B non sono sempre presenti ma vengono attivati quando è necessario trasferire dei Dati, i Listener comando invece sono sempre attivi.

I Server FTP di default sono impostati in "Active-mode" e quindi per ottenere questa funzionalità devono essere impostati in "Passive-mode". Verificare il manuale del proprio Server FTP per l'impostazione specifica.

Una considerazione importante è determinata dalla coerenza della informazioni contenute sui ServerA e ServerB ed esposte dai corrispettivi FTP Server. Infatti il bilanciamento del carico di trasmissione non entra nel merito dei contenuti trasportati e quindi le informazioni trattate dai rispettivi Server/Servizi FTP devono essere condivise a livello Storage o con FileSystem di rete, CIFS/NFS, o con Global FileSystem.

Nella pagina successiva si può vedere un esempio di file di configurazione Oplon ADC per ottenere il risultato sopra esposto.

Da interfaccia grafica è sufficiente utilizzare il template, copiarlo sull'istanza desiderata e modificare gli indirizzi e porte su cui si accetteranno le richieste di collegamento.

Per impostare un endpoint grouping preconfigurato è sufficiente andare sul gruppo template FTP e quindi copiarlo nell'istanza desiderata. Una volta copiato sarà sufficiente modificare il numero e gli indirizzi degli endpoint per poterlo utilizzare.

parameters -FTP

Bind listenType-"NAT"
address"192.168.43.141" port"21, 65000-65010"
portForwarding-"true"
osiLayer"4"
protocol-"ftpDATA"
endPointsGrouping"FTP"
transport-"tcp"
          transportSessionAffinity-"true"
          enableVirtualDomain"false"
          enable-"true"/>

endPointsGrouping property groupName"FTP" loadBalancingType"Adaptative" enable"true"
virtualDomain, New1001 enable-"true"
endp property address"192.168.45.141" healthCheck"false" enable"true"
endp property address"192.168.45.143" healthCheck"false" enable"true"

RDP (Remote Desktop Protocol)

I servizi desktop remoti provvedono a fornire molteplici sessioni client erogate da un sistema host.

Questo protocollo trova oggi una concreta applicazione avendo a disposizione notevoli quantità di potenza di calcolo e throughput di rete a costi che rendono competitiva una soluzione desktop centralizzata che prende il nome di VDI (Virtual Desktop Infrastructure).

La centralizzazione del desktop non si propone come una soluzione adatta a tutte le necessità ma con l'aumentare della disponibilità di infrastrutture può oggi essere applicata in moltissime realtà sia Intranet che Extranet.

Sicuramente la centralizzazione offre indubbi vantaggi come, uno tra tutti, la possibilità di porre in alta affidabilità un servizio che, per sua natura, se affidato a strumenti di produttività individuale non potrebbe esserlo per definizione.

Oplon ADC in questo contesto riesce a semplificare in pochi istanti sia aspetti di bilanciamento di carico sia aspetti legati all'alta affidabilità per la fruizione di servizi di Remote Desktop.

Il protocollo RDP inizia con una connessione dove avviene la negoziazione ed evolve con una disconnessione e quindi una nuova connessione risultato della negoziazione.

Nello schema di seguito sono evidenziate in rosso le nuove connessioni.

Il client si connette al server
Negoziazione
Ack e disconnessione
1. (A) Connessione con parametri negoziati
2. (A) evoluzione della connessione
3. (A) evoluzione della connessione...

Da questo semplice schema è immediatamente intuibile che in un'architettura che possa scalare non solo da un punto di vista dell'utilizzo delle risorse ma anche nel perdurare del tempo durante il susseguirsi di successive release lato server e lato Client, è necessario che la fase iniziale di connessione-negoziazione-disconnessione, in un ambiente con più sistemi Terminal-Server, debba avvenire nella stessa macchina della connessione iniziale.

Partendo da questa considerazione nella versione Oplon ADC 9.0 è possibile ottenere due modalità di comportamento differenti in base alle necessità. Un primo comportamento tende a privilegiare il bilanciamento delle connessioni a scapito della persistenza del collegamento ad un punto terminale, un secondo comportamento che invece privilegia la persistenza dell'ultima connessione riagganciando il "terminale" preesistente se ancora attivo.

Per questo motivo è necessario utilizzare il parametro di "session-affinity" e limitarlo per il tempo necessario ad effettuare la prima connessione di negoziazione e la successiva connessione dati.

I due schemi riportano l'evoluzione di un flusso di connessione che, per coerenza di negoziazione, deve avvenire nello stesso server su cui è stata effettuata la prima connessione di negoziazione.

Per ottenere questo risultato è necessario che Oplon ADC si ricordi, almeno per il tempo necessario, di instaurare la connessione presso lo stesso Server su cui è stata effettuata la Connessione di Negoziazione.

Nella pagina successiva si può vedere un esempio di file di configurazione Oplon ADC per ottenere il risultato sopra esposto. Successivamente è possibile vedere un file di configurazione che privilegia la persistenza all'ultima connessione ritornando, nei termini di timeOut della sessione, al medesimo servizio dopo la disconnessione.

Anche in questo caso esistono già dei template utilizzabili direttamente attraverso l'utilità di copy dell'interfaccia HTML 5: Copia e personalizzazione del/i listener

Copia e personalizzazione degli endpoint

RDP example (with session affinity)

Bind 
listenType-"NAT"
description-"Sample RDP with session affinity" 
address-"0.0.0.0" port"3389"
osiLayer"4"
protocol-"rdp-session-affinity"
endPointsGrouping"sample-rdp-mysession-affinity"
transport-"tcp"
transportSessionAffinity-"true"

endPointsGrouping property groupName"sample-rdp-mysession-affinity" enable-"true"
virtualDomain, New1001 enable-"true"
endp address"localhost" port"3389" enable"true"
	endp address"localhost" port"3389" enable"true"

Diversamente da un ambiente con singolo Server in un ambiente posto in bilanciamento non si è sempre sicuri di ritornare sullo stesso server alla richiesta di connessione successiva (volutamente cioè lavorando senza affinità di sessione o involontariamente per scadenza della sessione). In questo caso ci sarebbero alcune considerazioni da fare riguardo il time-out della sessione e la posizione del bilanciatore rispetto lo strato architetturale che rimandiamo per il momento al corso di certificazione necessario per installare Oplon ADC in un ambiente di produzione.

Al riguardo è importante sapere che in una tipica situazione con architettura schermata da un firewall con indirizzi NAT e avere un buon compromesso tra sfruttamento delle risorse e sessioni "terminal-server" spalmate su tutti Server l'RDP Server deve essere impostato in modo che se alcune sessioni non sono più utilizzate perché disconnesse deve essere comandato un log-off per poter liberare risorse.

A questo proposito e scopo il servizio RDP-server (aka terminal-server) mette a disposizione alcuni parametri che permettono di effettuare un log-off automatico in caso di disconnessione oppure impostare un time-out se una connessione non viene utilizzata per un tempo specificato. In ambienti con molti posti di lavoro "centralizzati" questi due parametri permettono di avere sempre sistemi con risorse impegnate solo per le sessioni effettivamente utilizzate.

I parametri sono molto semplici da impostare e di seguito gli snap che permettono di effettuare le modifiche di comportamento.

Percorso:

Control Panel > Administrative Tools > Terminal Services Configuration > RDP-tcp > Sessions, New10

Impostare inoltre:

"Override user settings" = "When session limit is reached or connection is broken:" a "End session"

In situazioni con molti RDP-Client è opportuno impostare anche il time-out per terminale non utilizzato. Il valore del time-out è in relazione al tipo di utilizzo del posto di lavoro e dalle risorse a disposizione. L'esempio riportato di seguito imposta il time-out della sessione a 2 giorni.

Parametri con "rdp-nosession-affinity" "Override user settings" = "End a disconnected session:" a "1 minute" "Active session limit" a "Never" "Idle session limit" a "2 days"
Parametri con "rdp-session-affinity" "Override user settings" = "End a disconnected session:" a "30 minutes" "Active session limit" a "Never" "Idle session limit" a "2 days"

In questa maniera dopo 2 giorni di inattività il Client viene disconnesso e dopo uno o 30 minuti la sessione terminal server, sul server, esegue un logoff e libera le risorse.

Telnet, SSH & SFTP (Secure Shell & Secure File Transfer Protocol)

Secure Shell è un protocollo sicuro per effettuare remote login ed utilizzare altri servizi attraverso la rete.

Questo protocollo, spesso utilizzato per fornire funzionalità di terminale remoto a linea di comando in modalità sicura, è stato studiato per erogare molteplici servizi di comunicazione tra computer come definito dalla RFC 4254 ed in particolare:

"shell" for terminal shells
SFTP and exec requests (including SCP transfers)
"direct-tcpip" for client-to-server forwarded connections
"forwarded-tcpip" for server-to-client forwarded connections

Il protocollo, nella sua forma di utilizzo più comune, utilizza una porta in ascolto in SSL dove a seconda del comando (chiamato Channel ora in avanti come da specifiche RFC 4254) utilizzato possono evolvere in diversi tipi di servizio.

Di seguito la rappresentazione grafica dell'evoluzione della connessione con questo protocollo con evidenziato in rosso la connessione ed il verso.

Il Client SSH si connette al Server alla porta 22
Il Server instaura una connessione sicura
Il Client specifica il Channel e le sue caratteristiche
Evoluzione della connessione con le caratteristiche del Channel

In questa rappresentazione semplificata, ma utile allo scopo del manuale, c'è da notare che una volta stabilita la connessione la stessa evolve all'interno della medesima connessione indipendentemente dal Channel utilizzato. Questo comportamento è molto utile per erogare servizi eterogenei attraverso i firewall e semplifica anche la parametrizzazione di Oplon ADC avendo un unico canale da bilanciare.

Di seguito la rappresentazione grafica dell'evoluzione della connessione SSH in bilanciamento. E' evidenziata in rosso la connessione ed il suo verso.

Il Client si connette a Oplon ADC alla porta 22
Oplon ADC si connette al ServerA, in base alle policy di load-balancing, alla porta 22
Il ServerA, con il servizio SSH in ascolto alla porta 22, risponde e instaura una connessione sicura
Oplon ADC esegue il forward della risposta del ServerA
Il Client specifica il Channel e le sue caratteristiche ad Oplon ADC
Oplon ADC inoltra le specifiche al ServerA
Evoluzione della connessione con le caratteristiche del Channel sul canale instaurato con Oplon ADC
Oplon ADC inoltra l'evoluzione della connessione al ServerA

Di seguito l'evoluzione della connessione alla successiva richiesta di servizio:

Per ottenere questo risultato di fruizione dei servizi SSH in bilanciamento ed in alta affidabilità la parametrizzazione di Oplon ADC è molto semplice. Solo qualche considerazione sul TimeOut. Nello schema di seguito il TimeOut, cioè termine della connessione se non utilizzata, è impostato ad 1 ora. In dipendenza della sicurezza e dal Channel prevalentemente utilizzato si può agire su questo parametro.

Anche in questo caso esistono già dei template utilizzabili direttamente attraverso l'utilità di copy dell'interfaccia HTML 5: Copia e personalizzazione del/i listener

Copia e personalizzazione degli endpoint

iproxy.xml -SSH-SFTP example

Bind listenType-"NAT"
description-"Sample SSH"
address-"0.0.0.0" port"222"
osiLayer"4"
protocol-"ssh"
endPointsGrouping"sample-ssh"
transport-"tcp"
transportSessionAffinity-"true"
enable-"true"

endPointsGrouping property groupName"sample-ssh" enable-"true"
virtualDomain, New1001 enable-"true"
endp property address-"localhost" port-"22" enable-"true"
endp property address-"localhost" port-"22" enable-"true"

LDAP (Lightweight Directory Access Protocol)

Questo protocollo è stato studiato per fornire servizi di directory e si è evoluto nel tempo grazie alla necessità di centralizzare grandi volumi di informazioni di profilo.

Dal punto di vista dell'evoluzione della connessione essendo un protocollo di ultima generazione il bilanciamento non presenta difficoltà di protocollo. L'unica avvertenza è che il prodotto di LDAP Server supporti la funzionalità multimaster o comunque permetta di scalare in maniera orizzontale su più sistemi. Dalla versione Oplon ADC 5.0 è possibile utilizzare anche LDAP server con funzionalità "active-passive" e associando una politica di bilanciamento "FailOver" (vedere documento di white paper per approfondire l'argomento FailOver).

Normalmente un LDAP Server viene utilizzato per effettuare moltissime letture e poche scritture. E' quindi ottimizzato per questo tipo di funzione. In alcune circostanze però può nascere la necessità di implementare una infrastruttura basata su LDAP con necessità elevate di scrittura ed in queste situazioni è opportuno adattare le politiche di bilanciamento come vedremo in seguito.

La porta su cui un LDAP Server sta normalmente in ascolto è la porta TCP 389 e 636 per TCP in SSL su cui evolve l'intera comunicazione. Di seguito l'evoluzione del protocollo con evidenziate in rosso le connessioni. In questi esempi si prende in considerazione la porta 389 ma il concetto rimane valido anche per la porta 636 dove evolve la connessione SSL.

Il client si connette alla porta 389
Il server LDAP instaura la trasmissione
Evoluzione del protocollo

Per poter quindi porre in bilanciamento questo protocollo è necessario avere un motore di forwarding bidirezionale e l'evoluzione del protocollo in ambienti multimaster è di seguito evidenziato nello schema.

Il client si connette alla porta 389 su cui è in ascolto Oplon ADC
Oplon ADC in base alle politiche di bilanciamento esegue il forward della connessione verso il servizio LDAP ServerA
Il servizio LDAP risponde con un ACK a Oplon ADC
Oplon ADC esegue il forward del messaggio di ACK
Evoluzione del protocollo del client verso Oplon ADC
Forward dell'evoluzione del protocollo

Nell'immagine seguente l'evolversi di una nuova connessione e bilanciamento della nuova richiesta sul ServerB.

Come brevemente accennato nell'introduzione queste architetture normalmente vengono utilizzate prevalentemente in lettura ed in queste situazioni il bilanciamento può essere utilizzato senza particolari attenzioni alle politiche di bilanciamento. Cosa diversa è se siamo in presenza di Servizi in multimaster e si ha la necessità di effettuare molte scritture ed immediate riletture. Infatti installazioni multimaster hanno il repository dati replicato per poter sopperire in maniera efficace a failure senza la necessità di utilizzare cluster e repository globali condivisi. Se da un lato questo diminuisce la complessità dell'installazione e del mantenimento, dall'altro, essendo i servizi di replica normalmente asincroni, se il numero di aggiornamenti e scritture dovesse essere molto elevato una lettura istantanea dello stesso dato su un altro nodo potrebbe risultare non consistente.

A questo scopo in entrambe le situazioni è possibile dare una risposta di bilanciamento adeguata utilizzando l'affinità di sessione. E' da mettere in evidenza che normalmente gli LDAP Server sono utilizzati per innumerevoli letture e poche scritture e quindi nel 98% dei casi si utilizzerà un bilanciamento senza affinità di sessione per sfruttare al meglio le potenzialità di questa architettura.

Anche in questo caso esistono già dei template utilizzabili direttamente attraverso l'utilità di copy dell'interfaccia HTML 5: Copia e personalizzazione del/i listener

Copia e personalizzazione degli endpoint

iproxy.xml -LDAP example

Bind listenType-"NAT"
description"LDAP no session affinity"
address-"0.0.0.0" port"389"
endPointsGrouping"ldap-services"
enableVirtualDomain"false"
protocol-"ldap"
transport-"tcp"
osiLayer"4"
enable-"true"

endPointsGrouping property enable-"true" groupName-"ldap-services"
virtualDomain, New1001 enable-"true" virtualDomainName-"default"
endp property address-"localhost" enable-"true" port-"389"
endp property address-"localhost" enable-"true" port-"389"

iproxy.xml -LDAP with session affinity example

Bind listenType-"NAT"
description"LDAP no session affinity"
address-"0.0.0.0" port"389"
endPointsGrouping"ldap-services"
enableVirtualDomain"false"
protocol-"ldap"
transport-"tcp"
transportSessionAffinity-"true"
osiLayer"4"
enable-"true"

endPointsGrouping property enable-"true" groupName-"ldap-services"
virtualDomain, New1001 enable-"true" virtualDomainName-"default"
endp property address-"localhost" enable-"true" port-"389"
endp property address-"localhost" enable-"true" port-"389"

iproxy.xml -LDAP FailOver example

Bind listenType-"NAT"
description"LDAP no session affinity"
address-"0.0.0.0" port"389"
endPointsGrouping"ldap-services-failover"
enableVirtualDomain"false"
protocol-"ldap"
transport-"tcp"
osiLayer"4"
enable-"true"

endPointsGrouping property enable-"true" groupName-"ldap-services-failover" 
         loadBalancingType:"FailOver"
virtualDomain, New1001 enable-"true" virtualDomainName-"default"
endp property address-"localhost" enable-"true" port-"389"
endp property address-"localhost" enable-"true" port-"389"

Database listeners Oracle & Oracle RAC, universal DBMS

I protocolli di trasmissione che consentono lo scambio di informazioni tra i client ed il Database Management System (DBMS) sono generalmente orientati alla connessione.

Anche questi protocolli per Oplon ADC non presentano particolari criticità nel tunneling e nel bilanciamento del traffico.

Quanto descritto in questo paragrafo è utilizzato per il bilanciamento delle connessioni ai listener Oracle RAC e Oracle classico. Gli stessi parametri sono utilizzabili anche per altri Database che, da un punto di vista dell'evoluzione della trasmissione, non si discostano da questi comportamenti.

Le tecniche di bilanciamento del traffico dati per un Database spesso non sono relative al bilanciamento del traffico in senso stretto, fornite anche dal produttore, ma sono orientate al disaccoppiamento del punto di erogazione dalle richieste su uno livello di trasporto "cross" tra le applicazioni per offrire servizi di alta disponibilità, Disaster recovery, sicurezza ed espandibilità durante l'esercizio e, non ultimo, semplicità.

Proprio prendendo ad esempio l'espandibilità (scalabilità) durante l'esercizio, il disaccoppiamento tra client e servizi rende facile inserire ulteriori nodi RAC senza modificare le impostazioni client, cosa assolutamente apprezzata in ambienti enterprise e in ambienti client server distribuiti. Cambiare le impostazioni dei client infatti, diventa molto oneroso, specie se distribuiti (Applicazioni Client server), o comunque operazioni delicate se inserite su application server in produzione.

L'evoluzione del protocollo, da un punto di vista della connessione e trasporto, si può sintetizzare come di seguito:

Il client si connette alla porta 1521
Il listener del DB Server instaura la trasmissione
Evoluzione del protocollo
Scambio informazioni

Nell'immagine di seguito è messo in evidenza il ruolo degli stessi connettori DB client in un ambiente a più livelli dove le connessioni al Database sono effettuate da Application server che a loro volta erogano dei servizi applicativi. Normalmente i DB Client all'interno del Connection Pool già dal loro avvio effettuano la connessione e si mettono a disposizione, già in stato di collegamento effettuato, delle applicazioni che ne fanno richiesta.

Il client si connette al servizio erogato dall'application server
Una connessione DB client del pool esegue la richiesta
Il listener del DB Server instaura la trasmissione
Evoluzione del protocollo
Scambio informazioni tra l'applicazione all'interno dell'Application server, il DB Client del pool e il DB Server
Risultato dell'elaborazione applicativa verso i client applicativi che hanno richiesto il servizio

Nello scenario di seguito si sintetizza l'evoluzione della connessione introducendo lo strato di bilanciamento in maniera completamente trasparente.

Il client si connette al servizio erogato dall'application server
Una connessione DB client del pool esegue la richiesta ad Oplon ADC
Oplon ADC esegue la richiesta verso uno dei due nodi
Il listener del DB Server instaura la trasmissione con Oplon ADC
Oplon ADC risponde al client che ne ha fatto richiesta
Evoluzione del protocollo
Scambio informazioni tra il client e l'applicazione all'interno dell'Application server
L'application server esegue le richieste a Oplon ADC
Oplon ADC inoltra la richiesta al listener del DB server
11.12. scambio informazioni
Mantenimento della connessione anche dopo la chiusura delle attività applicative del client

Proprio per il tipo di protocollo orientato alla connessione, e quindi con il minor numero di connessioni/disconnessioni possibili, è importante assicurare una adeguata ripartizione delle stesse sui nodi alla loro origine. A questo scopo l'utilizzo della policy di bilanciamento "Adaptative" ci assicura in ogni occasione di avere le connessioni ben omogeneizzate su tutti i nodi DB.

Anche in questo caso esistono già dei template utilizzabili direttamente attraverso l'utilità di copy dell'interfaccia HTML 5: Copia e personalizzazione del/i listener

Copia e personalizzazione degli endpoint

iproxy.xml -ORAC example

Bind listenType-"NAT"
description-"ORAC"
address-"0.0.0.0" port"51122"
endPointsGrouping:"ORAC"
enableVirtualDomain"false"
protocol-"ORAC"
transport-"tcp"
transportSessionAffinity"false"
osiLayer"4"
enable-"true"

endPointsGrouping property enable-"true" groupName-"ORAC" loadBalancingType-"Adaptative"
virtualDomain, New1001 enable-"true" virtualDomainName-"default"
endp property address-"localhost" enable-"true" port-"51222"
endp property address-"localhost" enable-"true" port-"51222"

Per tutti gli altri tipi di database (non paritetici) è stato aggiunto nella versione 7.0 il tipo di connessione DBMS. Questa parametrizzazione non si discosta dalla parametrizzazione del protocollo ORACLE/ ORACLE RAC le differenze ovviamente restano nel tipo di bilanciamento che non può essere paritetico e deve quindi orientarsi sul tipo di bilanciamento FailOver. Solo al fallimento della connessione con il server primario verrà tentata una connessione con il server secondario.

Questa soluzione trova il risultato migliore se associata a Oplon Commander in grado di eseguire lo switch dell'operatività dei servizi da un server ad un altro in maniera coordinata all'attività di rete.

iproxy.xml -DBMS example

Bind listenType-"NAT"
description-"DBMS"
address-"0.0.0.0" port"51122"
endPointsGrouping:"DBMS"
enableVirtualDomain"false"
protocol-"DBMS"
transport-"tcp"
transportSessionAffinity"false"
osiLayer"4"
enable-"true"

endPointsGrouping property enable"true" groupName"DBMS" loadBalancingType"FailOver"
virtualDomain, New1001 enable-"true" virtualDomainName-"default"
endp property address-"localhost" enable-"true" port-"51222"
endp property address-"localhost" enable-"true" port-"51222"

Bibliografia

Network Working Group J. Postel Request for Comments: 959 J. Reynolds ISI [http://www.w3.org/Protocols/rfc959/ (opens in a new tab)]
Unix Network Programming, W.Richard Stevens, Prentice-Hall, 1998
Unix System V, Network Programming, Stephen Rago, Addison-Wesley, 2000
Web Proxy Servers, Ari Luotenen, Prentice Hall, 1998
Load Balancing Servers, Firewalls, and Caches, Chandra Kopparapu, Wiley, 2001
Reti di calcolatori, Larry L. Peterson, Bruce S. Davie, Apogeo, 2004
Network Working Group S. Lehtinen Request for Comments: 4250 SSH Communications Security Corp [http://www.ietf.org/rfc/rfc4250.txt (opens in a new tab)]
Network Working Group T. Ylonen Request for Comments: 4251 SSH Communications Security Corp [http://www.ietf.org/rfc/rfc4251.txt (opens in a new tab)]
Network Working Group T. Ylonen Request for Comments: 4252 SSH Communications Security Corp [http://www.ietf.org/rfc/rfc4252.txt (opens in a new tab)]
Network Working Group T. Ylonen Request for Comments: 4253 SSH Communications Security Corp [http://www.ietf.org/rfc/rfc4253.txt (opens in a new tab)]
Network Working Group T. Ylonen Request for Comments: 4254 SSH Communications Security Corp [http://www.ietf.org/rfc/rfc4254.txt (opens in a new tab)]
Network Working Group W. Yeong Request for Comments: 1487 Performance Systems International [http://tools.ietf.org/html/rfc1487 (opens in a new tab)]
Network Working Group W. Yeong Request for Comments: 1777 Performance Systems International [http://tools.ietf.org/html/rfc1777 (opens in a new tab)]

HTTP Compression Layer 2/3 Setup