DB Networked setup

Note prima dell' installazione

Oplon Application Delivery Controller è un prodotto destinato ad ambienti mission-critical pertanto solo personale che ha effettuato il corso ed ha superato l'esame è autorizzato a certificare l'installazione e manutenzione dei prodotti in esercizio. Tutte le persone certificate sono dotate di patentino di riconoscimento rilasciato da Oplon.

Oplon Application Delivery Controller gestisce la persistenza delle statistiche su Database Relazione in maniera Transazionale. Nella configurazione di default utilizza l'images engine JavaDB Embedded fornito direttamente nella distribuzione Java (JDK). Oltre a JavaDB Embedded Oplon Application Delivery Controller è stato progettato per utilizzare i più diffusi Database Relazionali Transazionali. Di seguito la lista completa dei Database supportati per la storicizzazione delle statistiche:

  1. Oracle

  2. MS SQLServer

  3. MySQL (InnoDB engine)

  4. Postgres

  5. JavaDB embedded (default)

  6. JavaDB Networked

Il modulo di persistenza delle statistiche è stato realizzato per poter essere disaccoppiato dal sistema di bilanciamento. Questa caratteristica permette la realizzazione di diverse architetture in base alle necessità di storicizzazione.

Nell' installazione di default queste funzionalità non sono immediatamente evidenti essendo state volutamente realizzate in modo da creare il minimo impatto nell' installazione di base.

Tipologie di storicizzazione delle statistiche

Ci sono fondamentalmente 2 tipologie di storicizzazione delle statistiche:

  1. Embedded

  2. Networked

Per Embedded si intende l'utilizzo esclusivo del Database di Oplon Application Delivery Controller senza la possibilità di interagire durante il run-time con interrogazioni custom SQL. (N.B. E' possibile passare dalla modalità embedded a networked in qualsiasi momento senza perdita di informazioni)

Per Networked si intende l'utilizzo di un DBMS tra quelli supportati attraverso la rete con l'utilizzo dei driver (JDBC) messi a disposizione dai singoli produttori. Con questa tipologia di storicizzazione è possibile interrogare il Database con proprie query SQL durante il run-time.

Architettura

L'architettura della storicizzazione statistica è stata studiata per avere il minimo impatto sull'elaborazione core (il bilanciamento di carico) dando nel contempo la massima flessibilità di configurazione e un'altissima scalabilità.

E' basata su 3 livelli logici

image1

Questi tre livelli logici da un punto di vista di "Process" di sistema operativo possono essere collassati nella modalità Embedded su 2 "Process". Nella modalità Networked invece saranno al minimo 3 "Process" distinti.

Process di Sistema Operativo in modalità Embedded

image2

Essendo questi servizi raggiungibili attraverso la rete le architetture possibili sono molteplici.

L'architettura preimpostata ha un bassissimo impatto sia nell'installazione sia nel mantenimento e ben si adatta a quelle realtà che hanno bisogno solo di alcuni dati estemporanei a verifica dell'operatività e che non hanno necessità di ulteriori elaborazioni statistiche o di consolidato.

image3

Con l'architettura Embedded le statistiche rimangono all'interno delle singole Istanze e vengono gestite in automatico dal sistema mediatore (Oplon Application Delivery Controller WebCacheBroker).

Nei parametri preimpostati il processo Oplon Application Delivery Controller WebCacheBroker mantiene i dati nel Database Embedded per 2 giorni verificando nel contempo le occupazioni fisiche nel supporto di memorizzazione di massa. Nel caso queste dimensioni superino il GB (1GB) provvederà in automatico alla rigenerazione del DB evitando l'esaurimento delle risorse. Sia il limite dei 2 giorni che il limite di 1GB sono modificabili da parametri (vedi Oplon S.A.A.I. Reference Guide).

Ovviamente essendo dei processi separati Oplon Application Delivery Controller (il produttore delle statistiche) e Oplon WebCacheBroker (il mediatore, Broker) e collegati attraverso la rete sarebbe comunque possibile delocalizzare la storicizzazione su terze macchine, sia nella stessa DMZ sia nel backend. Questa possibilità è sicuramente meglio sfruttata nella modalità di utilizzo di un Database Networked dove sarà possibile eseguire durante il run-time delle query SQL sui dati di traffico.

Nell'immagine di seguito una configurazione su 3 livelli completamente separata tra la produzione delle statistiche, la mediazione (broker) e la storicizzazione su DBMS.

image4

E' possibile raggiungere questo risultato per due distinte motivazioni, la prima è derivata dal disegno architetturale che nasce su tre distinti livelli, la seconda è derivata dalla separazione logica dei dati all'interno dello stesso DBMS. Con Oplon Application Delivery Controller Standard HA e Oplon Application Delivery Controller Enterprise HA è infatti possibile consolidare all'interno dello stesso DB e nelle stesse tabelle i dati provenienti da più Istanze Oplon Application Delivery Controller.

Struttura del Database e creazione tabelle

La persistenza dei dati di traffico nel database statistico viene realizzata attraverso le seguenti tabelle:

  • SESSION_ACTIVITY

    • analisi dell'utilizzo delle sessioni
  • L7_HTTP_HTTPS

    • persistenza delle informazioni di traffico HTTP e HTTPS.
  • L4_TCP_TCPSSL

    • persistenza delle informazioni di traffico TCP e TCP come terminatore SSL
  • L4_DATAGRAM

    • persistenza delle informazioni di traffico UDP e MULTICAST
  • POOL_QUEUES_ACTIVITY

    • analisi dell'utilizzo dei pool di risoluzione delle richieste di servizio
  • INCOMING_QHIGHWATER_LEVEL

    • analisi dell'utilizzo del riempimento della coda delle connessioni entranti
  • WAF_EXEC

    • log delle regole eseguite con esito positivo dal Web Application Firewal
  • DDOS_EXEC

    • log degli attacchi DoS e DDoS
  • DAILY_ALERT

    • log delle notifiche provenienti da Attack Prophecy
  • GUIRT_MASTER

    • log master dell'esecuzione delle tracce GUI Reliability Tool
  • GUIRT_DETAIL

    • log di dettaglio dell'esecuzione degli step delle tracce GUI Reliability Tool

Gli schemi delle tabelle per singolo Database supportato sono contenuti nella directory (LBL_HOME)/legacyBin/DatabasesScript.

In questa directory possiamo trovare rispettivamente:

  • ORACLE_LBLDBTables.sql

    • ORACLE database table creation
  • SQLSERVER_LBLDBTables.sql

    • Microsoft SQL Server database table creation
  • MySQL_LBLDBTables.sql

    • Sun MySQL database table creation
  • POSTGRES_LBLDBTablesCreation.sql

    • Postgres database table creation
  • JavaDB_LBLDBTables

    • Java DB derby

A parte alcune differenze relative alla tipizzazione del formato dei campi, le tabelle , sui diversi database, contengono gli stessi dati. Nelle pagine a seguire verranno descritti dettagliatamente campo per campo i significati delle strutture per poter facilmente creare reports, statistiche, sistemi di fatturazione in base al traffico.

Tabella SESSION_ACTIVITY

Tabella contenente gli snap ad intervalli di 10" dello stato delle sessioni di instradamento.

RECORD_TYPEInt6Tipo di record
VRRP_HOST_NAMEvarchar(4000)Nome dell'host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBERintPort number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico
END_POINTS_GROUPINGvarchar(4000)E' il nome del gruppo di endpoint
DOMAIN_REQUESTvarchar(4000)E' il dominio associato alla sessione
COMMANDvarchar(4000)EMPTY
URI_PATH_REQUESTvarchar(4000)EMPTY
RESPONSE_CODEint0
END_POINT_HOST_NAMEvarchar(4000)Nome dell'host dell'endpoint associato alla sessione
END_POINT_PORT_NUMBERintPort number dell'host dell'endpoint associato alla sessione
END_POINT_URI_PATHvarchar(4000)E' l'URIPath di contesto in elaborazione
USER_IDvarchar(4000)Utilizzo futuro
CLIENT_ADDRESSvarchar(4000)

Il client address riporta l'indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

Se trasmissione a layer 7 HTTP/S ed e' stata impostata la gestione dell'entity X-Forwarded-For (HEADER HTTP) attraverso il parametro xForwardedFor="true" nel

listener in iproxy.xml il valore dell'intera catena IP sara' trasferita.

Ovviamente OPLON puo' assicurare solo l'ultimo elemento della catena essendo gli altri elementi utili solo a scopo statistico essendo popolati da altri strumenti

di infrastruttura come ad esempio i proxy.

es.: 192.168.32.115,192.168.41.10,192.168.43.150

THIS_DATEdateData uniformata ad orario a 00:00:00
THIS_TIMEtimeOra con data uniformata a 01-01-1970
NUMBER_OF_ACTIVE_SESSIONSintE' il numero di sessioni relative alla chiave di raggruppamento (in rosso)

Le chiavi utilizzate sono:

index K1_L7_HTTP_HTTPS ON L7_HTTP_HTTPS (THIS_DATE);

index K2_L7_HTTP_HTTPS ON L7_HTTP_HTTPS (THIS_TIME);

Tabella L7_HTTP_HTTPS

Questa tabella contiene il traffico del protocollo HTTP e HTTPS (SSL).

RECORD_TYPEInt0=HTTP
1=HTTPS
Tipo di record
VRRP_HOST_NAMEvarchar(4000)Nome dell'host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBERintPort number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico
END_POINTS_GROUPINGvarchar(4000)E' il nome del gruppo di endpoint
DOMAIN_REQUESTvarchar(4000)E' il dominio richiesto dal client
COMMANDvarchar(4000)E' il comando HTTP richiesto dal client (GET, POST, etc)
URI_PATH_REQUESTvarchar(4000)Path riferito al dominio richiesto dal client. Questo valore riporta il risultato della richiesta dopo l'azione di rewriting se esistente. E' l'effettiva richiesta che viene effettuata nel backend.
URI_PATH_REQUEST_ORGvarchar(4000)Path originale riferito al dominio richiesto dal client prima di eventuali rewriting
CONTENT_TYPE_REQUESTvarchar(4000)content type in request
CONTENT_TYPE_RESPONSEvarchar(4000)content type in response
RESPONSE_CODEintResponse CODE HTTP inviato dal server al client in risposta alla sua richiesta
END_POINT_HOST_NAMEvarchar(4000)Nome dell'host su cui è stata elaborata la richiesta di servzio
END_POINT_PORT_NUMBERintPort number dell'host su cui è stata elaborata la richiesta di servzio
END_POINT_URI_PATHvarchar(4000)E' l'URIPath di contesto su cui è stata elaborata la richiesta
USER_IDvarchar(4000)

La colonna contiene le informazioni dell'utente profilato e autenticato. Le informazioni sono una somma degli elementi caratteristici di una autenticazione BASIC (Basic Authentication) e della autorizzazione derivante da certificato digitale. Questa colonna contiene rispettivamente:

Se autorizzazione con certificato digitale il Subject con un valore aggiuntivo riportante il Serial Number del certificato es.:

“CN=clientname, OU=clientlob, O=clientcompany, L=clientcountry, ST=clientdistrict, C=IT, SERIAL=1282479557”

Se basic authentication

“BASIC=usr1”

Nel caso siano presenti entrambe le credenziali il valore risultante sara' :

“BASIC=usr1, CN=clientname, OU=clientlob, O=clientcompany, L=clientcountry, ST=clientdistrict, C=IT, SERIAL=1282479557”

CLIENT_ADDRESSvarchar(4000)

Il client address riporta l'indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

Se trasmissione a layer 7 HTTP/S ed e' stata impostata la gestione dell'entity X-Forwarded-For (HEADER HTTP) attraverso il parametro xForwardedFor="true" nel

listener in iproxy.xml il valore dell'intera catena IP sara' trasferita.

Ovviamente OPLON puo' assicurare solo l'ultimo elemento della catena essendo gli altri elementi utili solo a scopo statistico essendo popolati da altri strumenti

di infrastruttura come ad esempio i proxy.

es.: 192.168.32.115,192.168.41.10,192.168.43.150

USER_AGENTvarchar(4000)Valore User-agent nell'HTTP HEADER
COOKIESvarchar(4000)Valore Cookie nell'HTTP HEADER
REFERERvarchar(4000)Valore Referer nell'HTTP HEADER
URI_PARAMETERSvarchar(4000)

Valore con parametri e/o query string.
I parametri, definiti nella URL dal carattere ; e le query string definite daò carattere ? vengono normalizzate in una unico valore separato da &. es.:

/aaa/bbb;c1=aaa&c2=bbb?q1=ccc&q2=dddd

VALORE IN URI_PARAMETERS

c1=aaa&c2=bbb&q1=ccc&q2=dddd

PROTOCOL_VERSIONvarchar(4000)HTTP/1.0
HTTP/1.1
INCOMING_ADDRESSvarchar(4000)Indirizzo locale in cui è stata accettata la connessione
INCOMING_PORT_NUMBERintPorta locale in cui è stata accettata la connessione
THIS_DATEdateData uniformata ad orario a 00:00:00
THIS_TIMEtimeOra con data uniformata a 01-01-1970
COUNTERbigintNumero di operazioni sommate in questo record (se non sono stati modificati i default è il numero di operazioni effettuate nella sua finestra temporale negli ultimi 10”)
RESPONSE_TIMEbigintE' il response time del servizio richiesto (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER). Valore espresso in nanosecondi.
LAP_TIME_AbigintTempo compreso tra la fine della lettura dell'HEADER del client e l'inizio della connessione verso l'endpoint (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER). Valore espresso in nanosecondi.
LAP_TIME_BbigintTempo di connessione all'endpoint (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER). Valore espresso in nanosecondi.
LAP_TIME_CbigintTempo tra la connessione avvenuta all'endpoint e l'inizio della lettura dell'HEADER di risposta. Se il client invia il body è il tempo di trasmissione del body dal client all'endpoint.(Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER) . Valore espresso in nanosecondi.
LAP_TIME_DbigintTempo di lettura dell'Header dell'endpoint (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER). Valore espresso in nanosecondi.
LAP_TIME_EbigintTempo tra la fine della lettura dell'Header e la fine dei dati in risposta (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER). Valore espresso in nanosecondi.
HEADER_LENGTH_FROM_CLIENTbigintE' la lunghezza dell'HEADER di richiesta dei client verso gli endpoint (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER)
BYTES_SENT_FROM_CLIENTbigintTotale trasferito compresa l'HEADER dal client verso gli endpoint (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER)
HEADER_LENGTH_FROM_END_POINTbigintE' la lunghezza dell'HEADER di risposta degli endpoint verso i client (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER)
BYTES_SENT_FROM_END_POINTbigintTotale trasferito compresa l'HEADER dagli endpoint verso i client (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER) relative alla chiave di raggruppamento (in rosso)
SESSIONIDvarchar(100)È un identificatore univoco (hash) generato dall’insieme indirizzo del client + referer
REFERRING_DOMAINvarchar(300)Host name da cui è partita la richiesta
BROWSERvarchar(100)Nome del browser o del client che ha effettuato la richiesta
BROWSER_RELvarchar(100)Release del browser o del client che ha effettuato la richiesta
OSvarchar(100)Sistema operativo da cui è pervenuta la richiesta
OS_RELvarchar(100)Release del sistema operativo da cui è pervenuta la richiesta
DEVICEvarchar(100)Costruttore del device da cui è pervenuta la richiesta
COUNTRY_CODEvarchar(100)Sigla dello stato da cui è pervenuta la richiesta
COUNTRY_DESvarchar(350)Descrizione dello stato da cui è pervenuta la richiesta
INTERNET_ADDRESSvarchar(350)È l’indirizzo del client derivato dal socket se non esiste XFF. Se esiste XFF è il secondo della catena XFF.

Le chiavi utilizzate sono:

index K1_L7_HTTP_HTTPS ON L7_HTTP_HTTPS (THIS_DATE);

index K2_L7_HTTP_HTTPS ON L7_HTTP_HTTPS (THIS_TIME);

Tabella L4_TCP_TCPSSL

Come per la tabella precedente questa tabella contiene i dati di traffico relativo alle attività del connettore TCP e TCP come terminatore SSL. La struttura iniziale è molto simile a quella HTTP/S per differenziarsi poi sui dati di traffico

RECORD_TYPEInt2=TCP
3=SSL
Tipo di record
VRRP_HOST_NAMEvarchar(4000)Nome dell'host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBERintPort number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico
END_POINTS_GROUPINGvarchar(4000)E' il nome del gruppo di endpoint
DOMAIN_REQUESTvarchar(4000)Se WebSocket è l'host richiesto a layer 7
COMMANDvarchar(4000)

Identifica il flusso dei dati:
CLIENT_FLOW dal client verso gli endpoint
ENDPOINT_FLOW dagli endpoint verso i client

WebSocket:
WSCLIENT_FLOW dal client verso gli endpoint
WSENDPOINT_FLOW dagli endpoint verso i client

URI_PATH_REQUESTvarchar(4000)Se WebSocket è l'URIPath richiesto a layer 7
RESPONSE_CODEint0
END_POINT_HOST_NAMEvarchar(4000)Nome dell'host su cui è stata elaborata la richiesta di servzio
END_POINT_PORT_NUMBERintPort number dell'host su cui è stata elaborata la richiesta di servzio
END_POINT_URI_PATHvarchar(4000)Se WebSocket è l'URIPath richiesto a layer 7
USER_IDvarchar(4000)

If a SSL client authentication contains the Subject and the additional values of the certificate bearing the Serial Number eg.:

“CN=clientname, OU=clientlob, O=clientcompany, L=clientcountry, ST=clientdistrict, C=IT, SERIAL=1282479557”

CLIENT_ADDRESSvarchar(4000)

Il client address riporta l'indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

COOKIESvarchar(4000)

Valore univoco associato alla connessione. Questo valore viene popolato con il valore LBLCOLOR per identificare la singola connessione a layer 4. Per l'attivazione del popolamento di questo valore è necessario impostare il parametro distinguishSingleConnection="true" nel paragrafo <bind> del file parametri iproxy.xml

Se WebSocket contiene i cookie della connessione layer 7 HTTP/S

INCOMING_ADDRESSvarchar(4000)Indirizzo locale in cui è stata accettata la connessione
INCOMING_PORT_NUMBERintPorta locale in cui è stata accettata la connessione
THIS_DATEdateData uniformata ad orario a 00:00:00
THIS_TIMEtimeOra con data uniformata a 01-01-1970
COUNTERbigintNumero di operazioni sommate in questo record (se non sono stati modificati i default è il numero di operazioni effettuate nella sua finestra temporale negli ultimi 10”)
BYTES_FORWARDEDbigintE' il numero di bytes scambiati in base al flusso (client>endpoint oppure endpoint>client) relative alla chiave di raggruppamento (in rosso)
START_ADV_TIMEbigintE' il momento in cui viene rilevato il primo buffer/carattere espresso in nanosecondi
END_ADV_TIMEbigintE' il momento in cui viene eseguito il flush dell'ultimo buffer dello stream espresso in nanosecondi
TOTAL_ADV_TIMEbigintE' il tempo totale di forwarding dell'informazione (END_ADV_TIME – START_ADV_TIME) espresso in nanosecondi

Le chiavi utilizzate sono:

index K1_L4_TCP_TCPSSL ON L4_TCP_TCPSSL (THIS_DATE);

index K2_L4_TCP_TCPSSL ON L4_TCP_TCPSSL (THIS_TIME);

Tabella L4_DATAGRAM

Come per la tabella precedente questa tabella contiene i dati di traffico relativo alle attività del connettore TCP e TCP come terminatore SSL. La struttura iniziale è molto simile a quella HTTP/S per differenziarsi poi sui dati di traffico

RECORD_TYPEInt10=UDP
11=MULTICAST
Tipo di record
VRRP_HOST_NAMEvarchar(4000)Nome dell'host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBERintPort number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico
END_POINTS_GROUPINGvarchar(4000)E' il nome del gruppo di endpoint
DOMAIN_REQUESTvarchar(4000)EMPTY
COMMANDvarchar(4000)

Identifica il flusso dei dati

CLIENT_FLOW dal client verso gli endpoint
ENDPOINT_FLOW dagli endpoint verso i client

URI_PATH_REQUESTvarchar(4000)EMPTY
RESPONSE_CODEint0
END_POINT_HOST_NAMEvarchar(4000)Nome dell'host su cui è stata elaborata la richiesta di servzio
END_POINT_PORT_NUMBERintPort number dell'host su cui è stata elaborata la richiesta di servzio
END_POINT_URI_PATHvarchar(4000)EMPTY
USER_IDvarchar(4000)Utilizzo futuro
CLIENT_ADDRESSvarchar(4000)

Il client address riporta l'indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

INCOMING_ADDRESSvarchar(4000)Indirizzo locale in cui è stata accettata la connessione
INCOMING_PORT_NUMBERintPorta locale in cui è stata accettata la connessione
THIS_DATEdateData uniformata ad orario a 00:00:00
THIS_TIMEtimeOra con data uniformata a 01-01-1970
COUNTERbigintNumero di operazioni sommate in questo record (se non sono stati modificati i default è il numero di operazioni effettuate nella sua finestra temporale negli ultimi 10”)
BYTES_FORWARDEDbigintE' il numero di bytes scambiati

Le chiavi utilizzate sono:

index K1_L4_DATAGRAM ON L4_DATAGRAM (THIS_DATE);

index K2_L4_DATAGRAM ON L4_DATAGRAM (THIS_TIME);

Tabella POOL_QUEUES_ACTIVITY

Questa tabella contiene a snap di 10" lo stato di attività dei risolutori di protocollo. La sua interpretazione non può essere utilizzabile come sommatoria delle attività della giornata ma come dato statistico istantaneo nel momento relativo alla data e all'ora riportate sui records. Con questi snap è possibile tracciare su un asse temporale lo stato di attività e quindi i picchi di utilizzazione con uno slice di 10".

Questa tabella contiene due tipi di snap, uno relativo allo stato di attività dei risolutori di protocollo e l'altro relativo allo stato di "committed" dei risolutori di protocollo.

RECORD_TYPEInt4=ACTIVITY
5=COMMITTED
Tipo di record
VRRP_HOST_NAMEvarchar(4000)Nome dell'host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBERintPort number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico
END_POINTS_GROUPINGvarchar(4000)E' il nome del gruppo di endpoint
DOMAIN_REQUESTvarchar(4000)E' il dominio in elaborazione sul risolutore
COMMANDvarchar(4000)EMPTY
URI_PATH_REQUESTvarchar(4000)EMPTY
RESPONSE_CODEint0
END_POINT_HOST_NAMEvarchar(4000)Nome dell'host su cui è stata elaborata la richiesta di servzio
END_POINT_PORT_NUMBERintPort number dell'host su cui è stata elaborata la richiesta di servzio
END_POINT_URI_PATHvarchar(4000)E' l'URIPath di contesto in elaborazione
USER_IDvarchar(4000)Utilizzo futuro
CLIENT_ADDRESSvarchar(4000)

Il client address riporta l'indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

Se trasmissione a layer 7 HTTP/S ed e' stata impostata la gestione dell'entity X-Forwarded-For (HEADER HTTP) attraverso il parametro xForwardedFor="true" nel

listener in iproxy.xml il valore dell'intera catena IP sara' trasferita.

Ovviamente OPLON puo' assicurare solo l'ultimo elemento della catena essendo gli altri elementi utili solo a scopo statistico essendo popolati da altri strumenti

di infrastruttura come ad esempio i proxy.

es.: 192.168.32.115,192.168.41.10,192.168.43.150

THIS_DATEdateData uniformata ad orario a 00:00:00
THIS_TIMEtimeOra con data uniformata a 01-01-1970
NUMBER_OF_BUSY_CONSUMERintE' il numero di consumatori in attività nell'istante THIS_DATE e THIS_TIME relative alla chiave di raggruppamento (in rosso)

Le chiavi utilizzate sono:

index K1_POOL_QUEUES_ACTIVITY ON POOL_QUEUES_ACTIVITY (THIS_DATE);

index K2_POOL_QUEUES_ACTIVITY ON POOL_QUEUES_ACTIVITY (THIS_TIME);

Tabella INCOMING_QHIGHWATER_LEVEL

E' la tabella che registra a snap di 10" il livello di riempimento della coda delle richieste di connessione entranti. Questa tabella è importante perché in relazione al numero di risolutori di protocollo è l'indicatore di un possibile attacco DoS o di risorse insufficienti per elaborare il carico di richieste.

RECORD_TYPEInt7Tipo di record
VRRP_HOST_NAMEvarchar(4000)Nome dell'host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBERintPort number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico
THIS_DATEdateData uniformata ad orario a 00:00:00
THIS_TIMEtimeOra con data uniformata a 01-01-1970
HIGH_WATERintE' il numero di richieste di connessione all'interno della coda prima in attesa di essere elaborate
HIGH_WATER_LEVELfloat

E' il fattore di calcolo derivato da:

(100*HIGH_WATER)/ACT_SESSIONS

HIGH_WATER_WARNING_LEVELfloatE' la soglia in % superata la quale viene spedito un messaggio di avvertimento
HIGH_WATER_DANGER_LEVELfloatE' la soglia in % superata la quale viene spedito un messaggio di pericolo
ACT_SESSIONSintE' l'attuale disponibilità di risolutori di protocollo
MAX_CONCURRENT_SESSIONSintE' il numero massimo di risolutori di protocollo

Le chiavi utilizzate sono:

index K1_INCOMING_QUEUE_HL ON INCOMING_QHIGHWATER_LEVEL (THIS_DATE);

index K2_INCOMING_QUEUE_HL ON INCOMING_QHIGHWATER_LEVEL (THIS_TIME);

Tabella SYSLOG_EVENT

Questa tabella raccoglie tutti i messaggi provenienti da tutti i processi Oplon S.A.A.I.. In ambienti complessi è quindi un utile strumento che, se centralizzato, può essere utilizzato come sistema per rilevare eventuali anomalie di funzionamento.

RECORD_TYPEInt12Tipo di record
VRRP_HOST_NAMEvarchar(4000)E' una stringa separata da @ contenente:
host name@monitor management url@server process name@absolute log dir@date YYYYMMDD@hostname_logfileSuffix
VRRP_PORT_NUMBERint
COOKIESvarchar(4000)E' un valore identificativo del messaggio sempre differente ed univoco per sistema es.: ID=”16231623”
INCOMING_ADDRESSvarchar(4000)Host name
THIS_DATEdateData uniformata ad orario a 00:00:00
THIS_TIMEtimeOra con data uniformata a 01-01-1970
REPETITIONSbigintNumero di ripetizioni dello stesso messaggio
TIME_SEQUENCEbigintSequenza temporale evento
SEVERITYvarchar(4000)ERROR | WARNING | DEBUG | FATAL
JAVA_RELvarchar(4000)Release java
LBL_RELvarchar(4000)Relelase LBL
MESSAGE_GRPvarchar(4000)Nome dell'unita di elaborazione che ha generato il messaggio
HOST_IDvarchar(4000)Nome dell'host che ha generato il messaggio
MESSAGEvarchar(4000)Messaggio
MONITOR_MNG_URLvarchar(4000)
MONITOR_PROCESS_NAMEvarchar(4000)

Le chiavi utilizzate sono:

index K1_SYSLOG_EVENT ON SYSLOG_EVENT (THIS_DATE);

index K2_SYSLOG_EVENT ON SYSLOG_EVENT (THIS_TIME);

NOTE: At the start of the Monitor, the column is set with MONITOR_MNG_URL * UNDEFINED * because he still has not been started in-house theater management. Immediately after the start this column will correctly report the value of management eg.: https://192.168.46.109:54443/WebRegister

NOTE1: For the Monitor process the MONITOR_PROCESS_NAME is set with

  • MONITOR *

Tabella WAF_EXEC

Se Web Application Firewall installato, questa tabella raccoglie il log di tutte le regole eseguite con esito positivo durante il passaggio dei dati.

RECORD_TYPEInt14Tipo di record
VRRP_HOST_NAMEvarchar(350)Nome dell'host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBERintPort number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico
DOMAIN_REQUESTvarchar(3500)Se WebSocket è l'host richiesto a layer 7
CLIENT_ADDRESSvarchar(3500)

Il client address riporta l'indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

THIS_DATEdateData uniformata ad orario a 00:00:00
THIS_TIMEtimeOra con data uniformata a 01-01-1970
COUNTERintNumero di operazioni sommate in questo record (se non sono stati modificati i default è il numero di operazioni effettuate nella sua finestra temporale negli ultimi 10”)
RULE_IDvarchar(100)nome univoco della regola
REQUEST_IDvarchar(100)
ENABLEvarchar(100)

Tipo di abilitazione della regola:

on, off, detect

SCOREintPeso della regola
ACTIONvarchar(100)

Tipo di azione intrapresa:

drop, blacklist_ip ...

DESCRIPTIONvarchar(3500)Descrizione della regola
EXECUTION_QUEUEvarchar(100)runtime / near time
CATEGORYvarchar(100)

Categoria della regola:

Input; Bruteforce; Probing; Info leakage; Authentication; Linked site…

Le chiavi utilizzate sono:

create index K1_WAF_EXEC ON WAF_EXEC (THIS_DATE);

create index K2_WAF_EXEC ON WAF_EXEC (THIS_TIME);

Tabella DDOS_EXEC

Se Web Application Firewall installato, questa tabella raccoglie il log di tutte le regole eseguite con esito positivo durante il passaggio dei dati.

RECORD_TYPEInt15Tipo di record
VRRP_HOST_NAMEvarchar(350)Nome dell'host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBERintPort number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l'istanza di bilanciamento per il consolidamento dei dati di traffico
DOMAIN_REQUESTvarchar(3500)Se WebSocket è l'host richiesto a layer 7
INCOMING_ADDRESSvarchar(3500)Indirizzo locale in cui è stata accettata la connessione
CLIENT_ADDRESSvarchar(3500)

Il client address riporta l'indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

THIS_DATEdateData uniformata ad orario a 00:00:00
THIS_TIMEtimeOra con data uniformata a 01-01-1970
COUNTERintNumero di operazioni sommate in questo record (se non sono stati modificati i default è il numero di operazioni effettuate nella sua finestra temporale negli ultimi 10”)
TUNNELSintnome univoco della regola
QUARANTINE_TIMEbigintTempo di quarantena
QUARANTINE_START_TIMEdatetimeInizio quarantena
QUARANTINE_END_TIMEdatetimeFine quarantena
COUNTRY_CODEvarchar(100)Country code dell’attacco
COUNTRYvarchar(100)Country estesa
SUBNETint1 se attacco proveniente da una subnet; 0 se proveniente da singolo IP
DETECTint1 se rilevato senza azione (detect only); 0 se eseguita azione di mitigazione

Le chiavi utilizzate sono:

create index K1_DDOS_EXEC ON DDOS_EXEC (THIS_DATE);

create index K2_DDOS_EXEC ON DDOS_EXEC (THIS_TIME);

Tabella DAILY_ALERT

Se Web Application Firewall e Attack Prophecy installati, questa tabella raccoglie le notifiche giornaliere di Attack Prophecy.

THIS_DATEdateData uniformata ad orario a 00:00:00
CLIENT_ADDRESSvarchar(100)

Il client address riporta l'indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

COUNTRY_CODEvarchar(100)Country code dell’attacco
COUNTRY_DESvarchar(350)Country estesa
AS_CODEvarchar(100)Codice autonomous system
AS_DESCvarchar(350)Descrizione autonomous system
CATEGORYvarchar(100)

Categoria della regola:

Input; Bruteforce; Probing; Info leakage; Authentication; Linked site…

ALERT_NUMintNumero di alerts

Le chiavi utilizzate sono:

create index K1_DAILY_ALERT ON DAILY_ALERT (THIS_DATE);

Tabella GUIRT_MASTER GUIRT_DETAIL

Le due tabelle GUIRT_MASTER e GUIRT_DETAIL vengono popolate dal modulo GUI Reliability Tool durante l'esecuzione. Queste due tabelle sono correlate in uno a molti ( <- > >) attraverso il join PLAY-ID.

GUIRT_MASTER
PLAY_IDbigintId univoco di esecuzione della traccia (Join con PLAY_ID di GUIRT_DETAIL)
HOST_IDvarchar(512)Identificativo del nodo OPLON GDG (Where)
PROCESS_NAMEvarchar(512)Nome del modulo (es.: G10_LBLGUIPlayer)
TRACK_IDvarchar(512)Nome della traccia assegnato nel form di caricamento del player
START_TIMEdatetimeData ora di inizio esecuzione della traccia
END_TIMEdatetimeData ora di fine esecuzione della traccia
ERRORint0 la traccia non è terminata con errore, 1 la traccia è terminata con errore
GUIRT_DETAIL
PLAY_IDbigintId univoco di esecuzione della traccia (Join con PLAY_ID di GUIRT_MASTER)
TIME_SEQbigintÈ la sequenza temporale dello step. NOTA: Gli step possono essere eseguiti in maniera condizionale e quindi la cronologia del numero dello step può essere diversa dalla sequenza.
STYPEint

Tipo di step:

0=process step, 1=text test 2=image test, 3=end step

ERRORint0 la traccia non è terminata con errore, 1 la traccia è terminata con errore. NOTA: Può succedere che uno step rilevi un errore che però viene corretto da un salto condizionale. In questo caso lo step avrà come ERROR 1 mentra la traccia avrà come ERROR 0
ORIGINAL_SEQintData ora di inizio esecuzione della traccia
ROW_NUMintSe alla traccia in esecuzione è stata assegnata una lista “csv” di sostituzione è il numero della riga della lista in esecuzione.
ROW_COMPUTETIMEbigintTempo impiegato dal sistema per eseguire l’operazione (esempio tempo di compare image o di ricerca di un testo)
ROW_TIMEbigintTempo totale lordo impiegato per eseguire lo step in millisecondi. Questo tempo comprende il tempo di calcolo ROW_COMPUTETIME che deve essere scorporato se si vuole stimare il tempo netto di attesa
MESSAGEvarchar(2000)Messaggio totale
RECORDEDvarchar(2000)Caricato solo se errore. Se test di tipo TEXT contiene il valore registrato da comparare. Se test di tipo immagine contiene il nome del file con l’immagine registrata per comparazione.
PICKEDvarchar(2000)

Caricato solo se errore. Se test di tipo TEXT contiene il valore rilevato. Se test di tipo immagine contiene il nome del file con l’immagine rilevata.

NOTA: Alla rilevazione dell’errore, vengono spedite al sistema 3 immagini: immagine registrata, immagine rilevata e snap del desktop.

Esempio di selezione con Join GUIRT_MASTER e GUIRT_DETAIL per rilevare tutti gli step di confronto immagine che hanno riscontrato un errore di confronto.

SELECT  * from GUIRT_MASTER m

LEFT JOIN GUIRT_DETAIL d ON m.PLAY_ID = d.PLAY_ID

WHERE d.STYPE < >3 and m.ERROR=1 and d.ERROR=1 and STYPE=2

ORDER BY m.START_TIME, m.PLAY_ID, d.TIME_SEQ;

Le immagini vengono trasferite verso il broker che provvede a memorizzarle nella diurectory: (LBL_HOME)/ GUIRTImages/

Il nome del file è composto dal PLAY_ID, sequenza temporale, tipo di immagine: picked, recorded, desktop.

882208199_1534915217334_picked.png

882208199_1534915217334_recorded.png

882208199_1534915217380_desktop.png

Stop del modulo

Prima di modificare i parametri eseguire lo stop del modulo interessato.

Modules >Statistic brokers >Choose the module >Edit

image7

Espandere il pannello General start parameters >Impostare Module start da automatic a manual

image8

image9 Eseguire il save dei parametri ed attendere che il modulo sia in stato di Stopped:

Upload librerie di connessione database

Per caricare le librerie del database eseguire:

Files > External libraries >Import > Scegliere il modulo >Browse >Confirm

image10

Alla conferma la libreria verrà caricata nel nodo selezionato. Se servissero più file di libreria ripetere l'operazione per tutti i file.

Associazione della libreria al modulo

Per associare la libreria del database al modulo che si connette al database eseguire:

Modules >Statistic brokers >Choose the module >Edit

image7

Scegliere il pannello del Sistema operativo interessato e modificare il class path con la/e libreria del database. In questo esempio con la libreria MySQL.

image11

Connessione al DB

Per impostare i parametri di connessione al DB, dipendenti dalla tipologia del DB eseguire:

image7 Modules >Statistic brokers >Choose the module >Edit

image12 Espandere il pannello Webcache basic parameter ed impostare i parametri in dipendenza al DB utilizzato.

La lista dei parametri in dipendenza del DB è di seguito riportata.

DERBY EMBEDDED(es. library: derby.jar derbyclient.jar derbytools.jar)

DBDriver= "org.apache.derby.jdbc.EmbeddedDriver "
DBProtocol= "jdbc:derby: "
DBName= "lib/LBLDBStatistics "
DBDateFormat= "yyyy-MM-dd "
DBTimeFormat= "HH:mm:ss "

DERBY NETWORKED (es. library: derby.jar derbyclient.jar derbytools.jar)

DBDriver="org.apache.derby.jdbc.ClientDriver"
DBProtocol="jdbc:derby:"
DBName="//\_\_\_hostname\_\_\_:\_\_\_portnumber\_\_\_/\_\_\_\_directoryDBName\_\_\_"
DBDateFormat="yyyy-MM-dd"
DBTimeFormat="HH:mm:ss"

MySQL (es. library: mysql-connector-java-5.1.10-bin.jar)

DBDriver="com.mysql.jdbc.Driver"
DBProtocol="jdbc:mysql:"
DBName="//\_\_\_hostname\_\_\_:\_\_\_portnumber\_\_\_/\_\_\_dbname\_\_\_"
DBLogin="root"
DBPassword="adminadmin"
DBDateFormat="yyyy-MM-dd 00:00:00"
DBTimeFormat="1970-01-01 HH:mm:ss"
DBTimeIsDate="true"
DBVarcharLimit="3500"

SQLSERVER (es. library: sqljdbc.jar)

DBDriver="com.microsoft.sqlserver.jdbc.SQLServerDriver"
DBProtocol="jdbc:sqlserver:"
DBName="//\_\_\_hostname\_\_\_:\_\_\_portnumber\_\_\_;Database=\_\_\_dbname\_\_\_"
DBLogin="sa"
DBPassword="adminadmin"
DBDateFormat="yyyy-dd-MM 00:00:00"
DBTimeFormat="1970-01-01 HH:mm:ss"

ORACLE (es. library: ojdbc6)

DBDriver="oracle.jdbc.driver.OracleDriver"
DBProtocol="jdbc:oracle:"
DBName="thin:@\_\_\_hostname\_\_\_:\_\_\_portnumber\_\_\_:\_\_\_dbname\_\_\_"
DBLogin="system"
DBPassword="adminadmin"
DBDateFormat="yyyy-MM-dd 00:00:00"
DBTimeFormat="1970-01-01 HH:mm:ss"
DBSetDateFormat="ALTER SESSION set NLS_DATE_FORMAT = &apos;YYYY-MM-DD HH24:MI:SS&apos;"

POSTGRES (es. library: postgresql-8.4-701.jdbc4.jar)

DBDriver="org.postgresql.Driver"
DBProtocol="jdbc:postgresql:"
DBName="//\_\_\_hostname\_\_\_:\_\_\_portnumber\_\_\_/\_\_\_dbname\_\_\_"
DBLogin="postgres"
DBPassword="adminadmin"
DBDateFormat="yyyy-MM-dd"
DBTimeFormat="HH:mm:ss"

Modifica profondità temporale di storicizzazione

image13 Oplon Application Delivery Controller per parametrizzazione di default storicizza i dati con una profondità temporale di 2 giorni. Per modificare questo comportamento è sufficiente impostare il parametro DBMaxHistoryDays. Se questo parametro viene impostato con un valore minore od uguale a 0 (zero) le statistiche non verranno mai cancellate. È possibile anche impostare profondità temporali diversificate per le diverse tabelle del database.

Verifica dei parametri

Dopo aver eseguito il save provare ad avviare il modulo manualmente

Modules >Statistic brokers >Choose the module >Start

image14

Modules >Statistic brokers >Choose the module >See details

image15

image16 Modules >Statistic brokers >Choose the module >Actions >View logs

image17 Modules >Statistic brokers >Choose the module >Actions >View logs >View log

image18 Cercare nel log "DB Statistics initialization done!"

Ripristinare l'esecuzione automatica ...

Modules >Statistic brokers >Choose the module >Edit

image7

Espandere il pannello General start parameters >Set Module start da manual a automatic

image19

image8

image19

Eseguire il save dei parametri ed attendere che il modulo sia in stato di Running

ORACLE RAC connection string

Per Oracle RAC la stringa di connessione al database statistico deve essere impostata in modo che possa raggiungere i listeners sulle diverse istanze. A tal proposito di seguito un esempio di stringa di connessione con listeners attestati su due hosts rispettivamente: db1 e db2.

**DBName**= "thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST= <db1>)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST= <db2>)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME= <nome_servizio >))) "