How to balance network protocols

Back

Questo documento descrive le impostazioni di LBL®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 LBL®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 LBL®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.

LBL®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. LBL®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.

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

  1. 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
  2. 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
  3. Il Client con una nuova connessione verso il Server da seguito al comando
  4. 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 LBL®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 LBL®ADC nel ServerA mentre nella successiva immagine viene schedulata nel ServerB.

  1. 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
  2. LBL®ADC, in base alle politiche di instradamento, esegue una connessione al ServerA alla porta 2121
  3. Il ServerA non raccoglie la proposta del Client e risponde con la sua proposta di connessione PASV (passive) all’indirizzo LBL®ADC /porta (es.6161) per il trasferimento dati
  4. LBL®ADC trasferisce l’informazione al Client
  5. Il Client con una nuova connessione verso LBL®ADC (porta 6161) dà seguito al comando
  6. LBL®ADC schedula, in base alle policy di instradamento, la connessione dati verso il ServerA/porta (es.6161)
  7. Il ServerA trasferisce i dati verso LBL®ADC dalla porta 6161
  8. LBL®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 LBL®ADC per ottenere il risultato sopra esposto.

ATTENZIONE:

Il server FTP Microsoft, dopo aver impostato il range di porte è NECESSARIO riavviare il servizio da Services, NON è sufficiente riavviare il servizio dal pannello Internet Information Services. Deve essere riavviato il servizio.

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

endPointsGrouping groupName=”FTP” loadBalancingType=”Adaptative” enable=”true”

virtualDomain enable=”true”

endp address=”192.168.45.141″ healthCheck=”false” enable=”true”

endp address=”192.168.45.143″ healthCheck=”false” enable=”true”

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”/>

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.

LBL®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.

  1. Il client si connette al server
  2. Negoziazione
  3. Ack e disconnessione
  4. (A) Connessione con parametri negoziati
  5. (A) evoluzione della connessione
  6. (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 LBL®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 LBL®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 LBL®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 groupName=”sample-rdp-mysession-affinity” enable=”true”

virtualDomain 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 LBL®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 =>

Adminitrative Tools =>

Terminal Services Configuration =>

RDP-tcp =>

Sessions

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.

  1. Il Client SSH si connette al Server alla porta 22
  2. Il Server instaura una connessione sicura
  3. Il Client specifica il Channel e le sue caratteristiche
  4. 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 LBL®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.

  1. Il Client si connette a LBL®ADC alla porta 22
  2. LBL®ADC si connette al ServerA, in base alle policy di load-balancing, alla porta 22
  3. Il ServerA, con il servizio SSH in ascolto alla porta 22, risponde e instaura una connessione sicura
  4. LBL®ADC esegue il forward della risposta del ServerA
  5. Il Client specifica il Channel e le sue caratteristiche ad LBL®ADC
  6. LBL®ADC inoltra le specifiche al ServerA
  7. Evoluzione della connessione con le caratteristiche del Channel sul canale instaurato con LBL®ADC
  8. LBL®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 LBL®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 -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 groupName=”sample-ssh” enable=”true”

virtualDomain enable=”true”

endp address=”localhost” port=”22″ enable=”true”

endp 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 comuque permetta di scalare in maniera orizzontale su più sistemi. Dalla versione LBL®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.

  1. Il client si connette alla porta 389
  2. Il server LDAP instaura la trasmissione
  3. 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.

  1. Il client si connette alla porta 389 su cui è in ascolto LBL®ADC
  2. LBL®ADC in base alle politiche di bilanciamento esegue il forward della connessione verso il servizio LDAP ServerA
  3. Il servizio LDAP risponde con un ACK a LBL®ADC
  4. LBL®ADC esegue il forward del messaggio di ACK
  5. Evoluzione del protocollo del client verso LBL®ADC
  6. 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 -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 enable=”true” groupName=”ldap-services”

virtualDomain enable=”true” virtualDomainName=”default”

endp address=”localhost” enable=”true” port=”389″

endp address=”localhost” enable=”true” port=”389″

iproxy -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 enable=”true” groupName=”ldap-services”

virtualDomain enable=”true” virtualDomainName=”default”

endp address=”localhost” enable=”true” port=”389″

endp address=”localhost” enable=”true” port=”389″

iproxy -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 enable=”true” groupName=”ldap-services-failover”

loadBalancingType=”FailOver”

virtualDomain enable=”true” virtualDomainName=”default”

endp address=”localhost” enable=”true” port=”389″

endp 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 LBL®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:

  1. Il client si connette alla porta 1521
  2. Il listener del DB Server instaura la trasmissione
  3. Evoluzione del protocollo
  4. 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.

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

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

  1. Il client si connette al servizio erogato dall’application server
  2. Una connessione DB client del pool esegue la richiesta ad LBL®ADC
  3. LBL®ADC esegue la richiesta verso uno dei due nodi
  4. Il listener del DB Server instaura la trasmissione con LBL®ADC
  5. LBL®ADC risponde al client che ne ha fatto richiesta
  6. Evoluzione del protocollo
  7. Scambio informazioni tra il client e l’applicazione all’interno dell’Application server
  8. L’application server esegue le richieste a LBL®ADC
  9. LBL®ADC inoltra la richiesta al listener del DB server
  10. 11.12. scambio informazioni

13. 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 -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 enable=”true” groupName=”ORAC” loadBalancingType=”Adaptative”

virtualDomain enable=”true” virtualDomainName=”default”

endp address=”localhost” enable=”true” port=”51222″

endp 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 LBL®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 enable=”true” groupName=”DBMS” loadBalancingType=”FailOver”

virtualDomain enable=”true” virtualDomainName=”default”

endp address=”localhost” enable=”true” port=”51222″

endp address=”localhost” enable=”true” port=”51222″

Bibliografia

  1. Network Working Group J. Postel Request for Comments: 959 J. Reynolds ISIhttp://www.w3.org/Protocols/rfc959/
  2. Unix Network Programming, W.Richard Stevens, Prentice-Hall, 1998
  3. Unix System V, Network Programming, Stephen Rago, Addison-Wesley, 2000
  4. Web Proxy Servers, Ari Luotenen, Prentice Hall, 1998
  5. Load Balancing Servers, Firewalls, and Caches, Chandra Kopparapu, Wiley, 2001
  6. Reti di calcolartori, Larry L. Peterson, Bruce S. Davie, Apogeo, 2004
  7. Network Working Group S. Lehtinen

Request for Comments: 4250 SSH Communications Security Corp

http://www.ietf.org/rfc/rfc4250.txt

  1. Network Working Group T. YlonenRequest for Comments: 4251 SSH Communications Security Corphttp://www.ietf.org/rfc/rfc4251.txt
  2. Network Working Group T. YlonenRequest for Comments: 4252 SSH Communications Security Corphttp://www.ietf.org/rfc/rfc4252.txt
  3. Network Working Group T. YlonenRequest for Comments: 4253 SSH Communications Security Corp

http://www.ietf.org/rfc/rfc4253.txt

  1. Network Working Group T. YlonenRequest for Comments: 4254 SSH Communications Security Corphttp://www.ietf.org/rfc/rfc4254.txt
  2. Network Working Group W. Yeong

Request for Comments: 1487 Performance Systems International

http://tools.ietf.org/html/rfc1487

  1. Network Working Group W. YeongRequest for Comments: 1777 Performance Systems Internationalhttp://tools.ietf.org/html/rfc1777

Sei interessato alle nostre soluzioni?