AWS Blu Age Blusam

Nei sistemi mainframe (denominati «legacy» nel seguente argomento), i dati aziendali vengono spesso archiviati utilizzando VSAM (Virtual Storage Access Method). I dati vengono archiviati in «record» (matrici di byte), appartenenti a un «set di dati».

Esistono quattro organizzazioni di set di dati:

• KSDS: set di dati con sequenza di tasti: i record sono indicizzati mediante una chiave primaria (non sono consentite chiavi duplicate) e, facoltativamente, chiavi «alternative» aggiuntive. Tutti i valori delle chiavi sono sottoinsiemi dell'array di record byte, ogni chiave è definita da:

  • un offset (in base a 0, 0 è l'inizio del contenuto dell'array di record byte, misurato in byte)

  • una lunghezza (espressa in byte)

  • se tollera o meno valori duplicati

• ESDS: set di dati in sequenza di ingresso: l'accesso ai record avviene per lo più in sequenza (in base all'ordine di inserimento nel set di dati) ma è possibile accedervi utilizzando chiavi alternative aggiuntive;

• RRDS: set di dati Relative Records: i record sono accessibili tramite «salti», utilizzando numeri di record relativi; i salti possono essere eseguiti in avanti o indietro;

• LDS: set di dati lineari: nessun record, semplicemente un flusso di byte, organizzato in pagine. Utilizzato principalmente per scopi interni su piattaforme legacy.

Quando si modernizzano le applicazioni legacy, utilizzando l'approccio di refactoring AWS Blu Age, le applicazioni modernizzate non sono più destinate ad accedere ai dati archiviati in VSAM, preservando al contempo la logica di accesso ai dati. Il componente Blusam è la risposta: consente di importare dati dalle esportazioni di set di dati VSAM legacy, fornisce un'API per l'applicazione modernizzata per manipolarli insieme a un'applicazione web di amministrazione dedicata. Consultare AWS Console di amministrazione Blu Age Blusam.

Nota

Blusam supporta solo KSDS, ESDS e RRDS.

L'API Blusam consente di preservare la logica di accesso ai dati (letture sequenziali, casuali e relative; inserimento, aggiornamento ed eliminazione dei record), mentre l'architettura dei componenti, basata su una combinazione di strategie di caching e archiviazione basata su RDBMS, consente operazioni di I/O ad alto rendimento con risorse limitate.

Infrastruttura Blusam

Blusam si affida a PostgreSQL RDBMS per l'archiviazione dei set di dati, sia per i dati dei record non elaborati che per gli indici delle chiavi (se applicabile). L'opzione preferita è utilizzare il motore compatibile con Amazon Aurora PostgreSQL. Gli esempi e le illustrazioni in questo argomento si basano su questo motore.

Nota

All'avvio del server, il runtime Blusam verifica la presenza di alcune tabelle tecniche obbligatorie e le crea se non possono essere trovate. Di conseguenza, al ruolo utilizzato nella configurazione per accedere al database Blusam devono essere concessi i diritti per creare, aggiornare ed eliminare le tabelle del database (sia le righe che le definizioni delle tabelle stesse). Per informazioni su come disabilitare Blusam, vedere. Configurazione Blusam

Caching

Oltre allo storage stesso, Blusam funziona più velocemente se abbinato a un'implementazione della cache.

Attualmente sono supportati due motori di cache EhCache e Redis, ognuno con il proprio caso d'uso:

• EhCache : cache locale volatile incorporata autonoma

  • NON idoneo per l'implementazione di AWS ambienti gestiti per la modernizzazione del mainframe.

  • In genere viene utilizzato quando un singolo nodo, ad esempio un singolo server Apache Tomcat, viene utilizzato per eseguire le applicazioni modernizzate. Ad esempio, il nodo potrebbe essere dedicato all'hosting di attività di lavoro in batch.

  • Volatile: l'istanza EhCache della cache è volatile; il suo contenuto andrà perso alla chiusura del server.

  • Incorporato: il server EhCache e il server condividono lo stesso spazio di memoria JVM (da tenere in considerazione quando si definiscono le specifiche per la macchina di hosting).

• Redis: cache persistente condivisa

  • Idoneo per l'implementazione di ambienti gestiti per la modernizzazione del AWS mainframe.

  • Utilizzato in genere in situazioni con più nodi, in particolare quando diversi server sono protetti da un sistema di bilanciamento del carico. Il contenuto della cache è condiviso tra tutti i nodi.

  • Il Redis è persistente e non è legato ai cicli di vita dei nodi. È in esecuzione su un computer o servizio dedicato (ad esempio, Amazon ElastiCache). La cache è remota per tutti i nodi.

Blocco

Per gestire l'accesso simultaneo a set di dati e record, Blusam si affida a un sistema di chiusura configurabile. Il blocco può essere applicato a entrambi i livelli: set di dati e record:

• Il blocco di un set di dati a scopo di scrittura impedirà a tutti gli altri client di eseguire operazioni di scrittura su di esso, a qualsiasi livello (set di dati o record).

• Il blocco a livello di record per la scrittura impedirà ad altri client di eseguire operazioni di scrittura solo sul record specificato.

La configurazione del sistema di blocco Blusam deve essere eseguita in base alla configurazione della cache:

• Se EhCache viene scelto come implementazione della cache, non è richiesta alcuna ulteriore configurazione di blocco poiché deve essere utilizzato il sistema di blocco in memoria predefinito.

• Se si sceglie Redis come implementazione della cache, è necessaria una configurazione di blocco basata su Redis, per consentire l'accesso simultaneo da più nodi. La cache Redis utilizzata per i blocchi non deve essere la stessa utilizzata per i set di dati. Per informazioni sulla configurazione di un sistema di blocco basato su Redis, consulta. Configurazione Blusam

Blusam Intrinsics e migrazione dei dati dalla versione precedente

Archiviazione di set di dati: record e indici

Ogni set di dati legacy, una volta importato in Blusam, verrà archiviato in una tabella dedicata; ogni riga della tabella rappresenta un record, utilizzando due colonne:

• La colonna ID numerica, di tipo big integer, è la chiave primaria della tabella e viene utilizzata per memorizzare il Relative Byte Address (RBA) del record. L'RBA rappresenta l'offset in byte dall'inizio del set di dati e inizia da 0.

• La colonna di record dell'array di byte, utilizzata per memorizzare il contenuto del record non elaborato.

Vedi ad esempio il contenuto di un set di dati KSDS utilizzato nell' CardDemo applicazione:

• Questo particolare set di dati ha record a lunghezza fissa, la cui lunghezza è di 300 byte (quindi la raccolta di ID è multipli di 300).

• Per impostazione predefinita, lo strumento pgAdmin utilizzato per interrogare i database PostgreSQL non mostra il contenuto delle colonne dell'array di byte, ma stampa invece un'etichetta [dati binari].

• Il contenuto non elaborato del record corrisponde al set di dati non elaborato esportato dalla versione precedente, senza alcuna conversione. In particolare, non avviene alcuna conversione del set di caratteri; ciò implica che le parti alfanumeriche del record dovranno essere decodificate da applicazioni modernizzate che utilizzano il set di caratteri legacy, molto probabilmente una variante EBCDIC.

Per quanto riguarda i metadati dei set di dati e gli indici delle chiavi: ogni set di dati è associato a due righe nella tabella denominata. metadata Questa è la convenzione di denominazione predefinita. Per informazioni su come personalizzarla, consultaConfigurazione Blusam.

• La prima riga ha il nome del set di dati come valore della colonna del nome. La colonna dei metadati è una colonna binaria che contiene una serializzazione binaria dei metadati generali del set di dati specificato. Per informazioni dettagliate, consultare Attributi generali dei metadati dei set di dati.

• La seconda riga contiene il nome del set di dati con il suffisso __internal' come valore della colonna del nome. Il contenuto binario della colonna di metadati dipende dal «peso» del set di dati.

  • Per set di dati di piccole e medie dimensioni, il contenuto è una serializzazione compressa di:

    • definizione delle chiavi utilizzate dal set di dati; definizione della chiave primaria (per KSDS) e definizioni di chiavi alternative, se applicabile (per KSDS/ESDS)

    • gli indici chiave, se applicabile (KSDS/ESDS con definizioni di chiavi alternative): utilizzati per la navigazione indicizzata dei record; l'indice delle chiavi associa un valore chiave all'RBA di un record;

    • mappa della lunghezza dei record: utilizzata per la navigazione sequenziale/relativa dei record;

  • Per set di dati grandi/molto grandi, il contenuto è una serializzazione compressa di:

    • definizione delle chiavi utilizzate dal set di dati; la definizione della chiave primaria (per KSDS) e le definizioni delle chiavi alternative, se applicabile (per KSDS/ESDS)

Inoltre, gli indici dei set di dati grandi/molto grandi (se applicabile) vengono archiviati utilizzando un meccanismo di impaginazione; le serializzazioni binarie delle pagine indice vengono archiviate come righe di una tabella dedicata (una tabella per chiave del set di dati). Ogni pagina di indici è memorizzata in una riga, con le seguenti colonne:

• id: identificatore tecnico della pagina degli indici (chiave numerica primaria);

• firstkey: valore binario del primo valore di chiave (più basso) memorizzato nella pagina degli indici;

• lastkey: valore binario dell'ultimo valore di chiave (più alto) memorizzato nella pagina degli indici;

• metadati: serializzazione binaria compressa della pagina degli indici (mappatura dei valori chiave ai record). RBAs

Il nome della tabella è una concatenazione del nome del set di dati e del nome interno della chiave, che contiene informazioni sulla chiave, ad esempio l'offset della chiave, se la chiave accetta i duplicati (impostato su true per consentire i duplicati) e la lunghezza della chiave. Ad esempio, consideriamo un set di dati denominato "AWS_LARGE_KSDS» con le due chiavi definite seguenti:

• chiave primaria [offset: 0, duplicati: false, lunghezza: 18]

• chiave alternativa [offset: 3, duplicati: true, lunghezza: 6]

In questo caso, le tabelle seguenti memorizzano gli indici relativi alle due chiavi.

Ottimizzazione del throughput di I/O utilizzando il meccanismo write-behind

Per ottimizzare le prestazioni delle operazioni di inserimento/aggiornamento/eliminazione, il motore Blusam si affida a un meccanismo write-behind configurabile. Il meccanismo si basa su un pool di thread dedicati che gestiscono le operazioni di persistenza utilizzando query di aggiornamento in blocco, per massimizzare il throughput di I/O verso lo storage Blusam.

Il motore Blusam raccoglie tutte le operazioni di aggiornamento eseguite sui record dalle applicazioni e crea lotti di record che vengono inviati per l'elaborazione ai thread dedicati. I lotti vengono quindi salvati sullo storage Blusam, utilizzando query di aggiornamento in blocco, evitando l'utilizzo di operazioni di persistenza atomica e garantendo il miglior utilizzo possibile della larghezza di banda di rete.

Il meccanismo utilizza un ritardo configurabile (il valore predefinito è un secondo) e una dimensione del lotto configurabile (il valore predefinito è 10000 record). Le query di persistenza della build vengono eseguite non appena viene soddisfatta la prima delle due seguenti condizioni:

• Il ritardo configurato è scaduto e il lotto non è vuoto

• Il numero di record nel lotto da trattare raggiunge il limite configurato

Per informazioni su come configurare il meccanismo write-behind, consulta. Proprietà facoltative

Scegliere lo schema di archiviazione corretto

Come mostrato nella sezione precedente, il modo in cui i set di dati vengono archiviati dipende dal loro «peso». Ma cosa è considerato piccolo, medio o grande per un set di dati? Quando scegliere la strategia di archiviazione impaginata anziché quella normale?

La risposta a questa domanda dipende da quanto segue.

• La quantità di memoria disponibile su ciascuno dei server che ospitano le applicazioni modernizzate che utilizzeranno tali set di dati.

• La quantità di memoria disponibile nell'infrastruttura di cache (se presente).

Quando si utilizza uno schema di archiviazione di indici non impaginati, le raccolte complete di indici a chiave e dimensioni dei record verranno caricate nella memoria del server all'ora di apertura del set di dati, per ogni set di dati. Inoltre, se è prevista la memorizzazione nella cache, tutti i record dei set di dati potrebbero essere precaricati nella cache con l'approccio normale, il che potrebbe portare all'esaurimento delle risorse di memoria sul lato dell'infrastruttura della cache.

A seconda del numero di chiavi definite, della lunghezza dei valori delle chiavi, del numero di record e del numero di set di dati aperti contemporaneamente, la quantità di memoria consumata può essere valutata approssimativamente per determinati casi d'uso noti.

Per ulteriori informazioni, consulta Stima dell'impronta di memoria per un determinato set di dati.

Migrazione Blusam

Una volta selezionato lo schema di archiviazione appropriato per un determinato set di dati, lo storage blusam deve essere popolato migrando i set di dati precedenti.

A tal fine, è necessario utilizzare esportazioni binarie non elaborate dei set di dati legacy, senza che venga utilizzata alcuna conversione di set di caratteri durante il processo di esportazione. Quando trasferite le esportazioni di set di dati dal sistema precedente, assicuratevi di non danneggiare il formato binario. Ad esempio, applicate la modalità binaria quando utilizzate FTP.

Le esportazioni binarie non elaborate contengono solo i record. Il meccanismo di importazione non richiede che keys/indexes exports as all keys/indexes venga ricalcolato all'istante dal meccanismo di importazione.

Una volta che l'esportazione binaria di un set di dati è disponibile, esistono diverse opzioni per migrarlo su Blusam:

Nell'ambiente gestito di AWS modernizzazione del mainframe:

• Importa set di dati utilizzando la funzionalità dedicata. Consultare Importa set di dati per Modernizzazione del mainframe AWS le applicazioni.

oppure

• Utilizza la funzione di importazione in blocco dei set di dati. Consulta AWS Riferimento alla definizione del set di dati per la modernizzazione del mainframe e Esempio di formato di richiesta di set di dati per VSAM.

oppure

• Usa uno script groovy per importare set di dati, utilizzando servizi di caricamento dedicati.

Nota

Per ora l'importazione di LargeKSD e LargeeSDS su ambienti gestiti di modernizzazione del mainframe è possibile solo utilizzando script groovy.

Su AWS Blu Age Runtime su Amazon EC2:

• Importa il set di dati utilizzandoAWS Console di amministrazione Blu Age Blusam.

oppure

• Utilizza uno script groovy per importare set di dati, utilizzando servizi di caricamento dedicati.

Importa set di dati utilizzando gli script Groovy

Questa sezione ti aiuterà a scrivere script groovy per importare set di dati precedenti in Blusam.

Inizia con alcune importazioni obbligatorie:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry
import java.util.ArrayList; //used for alternate keys if any

Dopodiché, per ogni set di dati da importare, il codice si basa sul modello dato:

1. crea o cancella un oggetto della mappa

2. riempi la mappa con le proprietà richieste (questo varia a seconda dei tipi di set di dati, vedi sotto per i dettagli)

3. recupera il servizio di caricamento corretto da utilizzare per il tipo di set di dati nel registro dei servizi

4. esegue il servizio, utilizzando la mappa come argomento

Esistono 5 implementazioni del servizio che possono essere recuperate dal registro dei servizi, utilizzando i seguenti identificatori:

• "BluesamKSDSFileLoader": per KSDS di piccole/medie dimensioni

• "BluesamESDSFileLoader"per ESDS di piccole/medie dimensioni

• "BluesamRRDSFileLoader": per RDS

• "BluesamLargeKSDSFileLoader": per KSDS di grandi dimensioni

• "BluesamLargeESDSFileLoader": per ESDS di grandi dimensioni

La scelta tra la versione normale o quella grande del servizio per KSDS/ESDS dipende dalla dimensione dei set di dati e dalla strategia di archiviazione che si desidera applicare. Per informazioni su come scegliere la strategia di archiviazione corretta, consulta. Scegliere lo schema di archiviazione corretto

Per importare correttamente il set di dati in Blusam, è necessario fornire le proprietà appropriate al servizio di caricamento.

Proprietà comuni:

• Obbligatorio (per tutti i tipi di set di dati)

  • «BlueSamManager»: il valore previsto è applicationContext.getBean(BluesamManager.class)

  • «DataSetName»: nome del set di dati, come stringa

  • "inFilePath": percorso per l'esportazione del set di dati precedente, come stringa

  • «recordLength»: la lunghezza del record fissa o 0 per il set di dati a lunghezza di record variabile, come numero intero

• Facoltativo

  • Non supportato per set di dati di grandi dimensioni:

    • «isAppend»: un flag booleano, che indica che l'importazione avviene in modalità append (aggiunta di record a un set di dati blusam esistente).

    • «useCompression»: un flag booleano che indica che la compressione verrà utilizzata per memorizzare i metadati.

  • Solo per set di dati di grandi dimensioni:

    • "indexingPageSizeInMb": la dimensione in megabyte di ogni pagina indice, per ciascuna delle chiavi del set di dati, come numero intero strettamente positivo

Proprietà dipendenti dal tipo di set di dati:

• KSDS/KSDS di grandi dimensioni:

  • mandatory

    • «primaryKey»: la definizione della chiave primaria, utilizzando una chiamata al costruttore. com.netfective.bluage.gapwalk.bluesam.metadata.Key

  • opzionale:

    • «AlternateKeys»: una lista (java.util.List) di definizioni di chiavi alternative, creata utilizzando com.netfective.bluage.gapwalk.bluesam.metadata.Key chiamate al costruttore.

• ESD/ESDS di grandi dimensioni:

  • opzionale:

    • «AlternateKeys»: una lista (java.util.List) di definizioni di chiavi alternative, creata utilizzando com.netfective.bluage.gapwalk.bluesam.metadata.Key chiamate al costruttore.

• ROSSI:

  • nessuna.

Chiamate del costruttore chiave:

• new Key(int offset, int length): crea un oggetto Key, con determinati attributi chiave (offset e length) e non sono consentiti duplicati. Questa variante deve essere utilizzata per definire una chiave primaria.

• new Key(boolean allowDuplicates, int offset, int length): crea un oggetto Key, con determinati attributi chiave (offset e length) e duplicati che consentono il flag.

I seguenti esempi di Groovy illustrano vari scenari di caricamento.

Caricamento di un KSDS di grandi dimensioni, con due chiavi alternative:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry
import java.util.ArrayList;

// Loading a large KSDS into Blusam
def map = [:]
map.put("bluesamManager", applicationContext.getBean(BluesamManager.class));
map.put("datasetName", "largeKsdsSample");
map.put("inFilePath", "/work/samples/largeKsdsSampleExport");
map.put("recordLength", 49);
map.put("primaryKey", new Key(0, 18));
ArrayList altKeys = [new Key(true, 10, 8), new Key(false, 0, 9)]
map.put("alternateKeys", altKeys);
map.put("indexingPageSizeInMb", 25);
def service = ServiceRegistry.getService("BluesamLargeKSDSFileLoader");
service.runService(map);

Caricamento di un record ESDS a lunghezza variabile, senza chiavi alternative:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry

// Loading an ESDS into Blusam
def map = [:]
map.put("bluesamManager", applicationContext.getBean(BluesamManager.class));
map.put("datasetName", "esdsSample");
map.put("inFilePath", "/work/samples/esdsSampleExport");
map.put("recordLength", 0);
def service = ServiceRegistry.getService("BluesamESDSFileLoader");
service.runService(map);

Le esportazioni di set di dati a lunghezza variabile conterranno le informazioni RDW (Record Decriptor Word) obbligatorie per consentire la suddivisione dei record in fase di lettura.

Caricamento di un RRDS a lunghezza di record fissa:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry

// Loading a RRDS into Blusam
def map = [:]
map.put("bluesamManager", applicationContext.getBean(BluesamManager.class));
map.put("datasetName", "rrdsSample");
map.put("inFilePath", "/work/samples/rrdsSampleExport");
map.put("recordLength", 180);
def service = ServiceRegistry.getService("BluesamRRDSFileLoader");
service.runService(map);

Caricamento di set di dati in modalità multischema:

Modalità multischema: in alcuni sistemi legacy, i file VSAM sono organizzati in set di file, che consentono ai programmi di accedere e modificare i dati all'interno di partizioni specificate. I sistemi moderni trattano ogni set di file come uno schema, abilitando un partizionamento dei dati e un controllo degli accessi simili.

Per abilitare la modalità multischema nel application-main.yml file, fare riferimento a. Configurazione Blusam In questa modalità, i set di dati possono essere caricati in uno schema specifico utilizzando un contesto condiviso, che è un registro in memoria per le informazioni di runtime. Per caricare un set di dati in uno schema specifico, aggiungete al nome del set di dati il nome dello schema pertinente.

Caricamento di un file KSDS in uno schema specifico per la modalità multischema:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry
import java.util.ArrayList;
import com.netfective.bluage.gapwalk.rt.shared.SharedContext;

// Loading a KSDS into Blusam
def map = [:]
String schema = "schema1";
String datasetName = schema+"|"+"ksdsSample";
SharedContext.get().setCurrentBlusamSchema(schema);
schema = SharedContext.get().getCurrentBlusamSchema();
map.put("bluesamManager", applicationContext.getBean(BluesamManager.class));
map.put("datasetName", datasetName);
map.put("inFilePath", "/work/samples/ksdsSampleExport");
map.put("recordLength", 49);
map.put("primaryKey", new Key(0, 18));
map.put("indexingPageSizeInMb", 25);
def service = ServiceRegistry.getService("BluesamKSDSFileLoader");
service.runService(map);

Caricamento di un file KSDS di grandi dimensioni in uno schema specifico per la modalità multischema:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry
import java.util.ArrayList;
import com.netfective.bluage.gapwalk.rt.shared.SharedContext;

// Loading a Large KSDS into Blusam
def map = [:]
String schema = "schema1";
String datasetName = schema+"|"+"largeKsdsSample";
SharedContext.get().setCurrentBlusamSchema(schema);
schema = SharedContext.get().getCurrentBlusamSchema();
map.put("bluesamManager", applicationContext.getBean(BluesamManager.class));
map.put("datasetName", datasetName);
map.put("inFilePath", "/work/samples/LargeKsdsSampleExport");
map.put("recordLength", 49);
map.put("primaryKey", new Key(0, 18));
map.put("indexingPageSizeInMb", 25);
def service = ServiceRegistry.getService("BluesamLargeKSDSFileLoader");
service.runService(map);

Inoltre, è possibile utilizzare una voce di configurazione (da impostare nel file di application-main.yml configurazione) per ottimizzare il processo di importazione:

• bluesam.fileLoading.commitInterval: un numero intero strettamente positivo, che definisce l'intervallo di commit per il normale ESDS/KSDS/RRDS meccanismo di importazione. Non si applica alle importazioni di set di dati di grandi dimensioni. Il valore predefinito è 100000.

Configurazione Blusam

La configurazione di Blusam avviene nel file di application-main.yml configurazione (o nel file di application-bac.yml configurazione per la distribuzione autonoma dell'applicazione Blusam Administration Console -- BAC).

Blusam deve essere configurato su due aspetti:

• Configurazione dello storage e dell'accesso alle cache Blusam

• Configurazione del motore Blusam

Configurazione dello storage e dell'accesso alle cache Blusam

Per informazioni su come configurare l'accesso allo storage e alle cache Blusam utilizzando gestori segreti o fonti di dati, vedere. Imposta la configurazione per AWS Blu Age Runtime

Nota

Per quanto riguarda l'accesso allo storage Blusam, le credenziali utilizzate indicheranno un ruolo di connessione, con i relativi privilegi. Affinché il motore Blusam possa funzionare come previsto, il ruolo di connessione deve avere i seguenti privilegi:

• connettersi al database

• create/delete/alter/tronca tabelle e viste

• seleziona/inserisci/elimina/aggiorna le righe nelle tabelle e nelle viste

• eseguire funzioni o procedure

configurazione del motore Blusam

Disabilitazione del supporto Blusam

Innanzitutto, ricordiamo che è possibile disabilitare completamente il supporto Blusam, impostando la proprietà su. bluesam.disabled true Un messaggio informativo verrà visualizzato nei log del server all'avvio dell'applicazione per ricordare a Blusam di disabilitare:

BLUESAM is disabled. No operations allowed.

In tal caso non sono necessarie ulteriori configurazioni su Blusam e qualsiasi tentativo di utilizzare le funzionalità relative a Blusam (a livello di codice o tramite chiamate REST) genererà un'interruzione UnsupportedOperationException nell'esecuzione del codice Java, con un messaggio di spiegazione pertinente sulla disabilitazione di Blusam.

Proprietà del motore Blusam

Le proprietà di configurazione del motore Blusam sono raggruppate sotto il prefisso bluesam key:

Proprietà obbligatorie

• cache: da valutare con l'implementazione della cache scelta. I valori validi sono:

  • ehcache: per l'utilizzo locale di ehcache incorporato. Consultate le limitazioni relative ai casi d'uso riportate sopra.

  • redis: per l'utilizzo della cache Redis remota condivisa. Questa è l'opzione preferita per il caso d'uso gestito di AWS Mainframe Modernization.

  • none: per disabilitare la memorizzazione nella cache dello storage

• persistence: da valutare con pgsql (motore PostgreSQL: versione minima 10.0 — versione consigliata >=14.0

• datasource reference: <persistence engine>.dataSource punterà alla definizione DataSource per la connessione allo storage Blusam, definita altrove nel file di configurazione. Comunemente viene nominato. bluesamDs

Nota

Ogni volta che Redis viene utilizzato come meccanismo di cache, sia per i dati che per i blocchi (vedi sotto), è necessario configurare l'accesso alle istanze Redis. Per informazioni dettagliate, consultare Proprietà della cache Redis disponibili in AWS Blu Age Runtime.

Proprietà facoltative

Blusam Locks: le proprietà sono precedute da locks

• cache: l'unico valore utilizzabile èredis, per specificare che verrà utilizzato il meccanismo di blocco basato su redis (da utilizzare anche quando blusam storage cache è basata su redis). Se la proprietà è mancante o non è impostata suredis, verrà invece utilizzato il meccanismo di blocco in memoria predefinito.

• lockTimeOut: un valore intero lungo positivo, che indica il timeout espresso in millisecondi prima che un tentativo di bloccare un elemento già bloccato venga contrassegnato come fallito. Il valore predefinito è. 500

• locksDeadTime: un valore intero lungo positivo, che rappresenta il tempo massimo, espresso in millisecondi, in cui un'applicazione può contenere un blocco. I lucchetti vengono automaticamente contrassegnati come scaduti e rilasciati dopo tale periodo di tempo. L'impostazione predefinita è; 1000

• locksCheck: una stringa, utilizzata per definire la strategia di controllo del blocco utilizzata dall'attuale gestore blusam lock, sulla rimozione dei blocchi scaduti. Da selezionare tra i seguenti valori:

  • off: non viene eseguito alcun controllo. Sconsigliato, in quanto potrebbero verificarsi blocchi inutili.

  • reboot: i controlli vengono eseguiti al riavvio o all'avvio dell'applicazione. Tutti i blocchi scaduti vengono rilasciati in quel momento. Questa è l'impostazione predefinita.

  • timeout: i controlli vengono eseguiti al riavvio o all'avvio dell'applicazione oppure quando scade un timeout durante un tentativo di bloccare un set di dati. I blocchi scaduti vengono rilasciati immediatamente.

Meccanismo write-behind: le proprietà sono precedute dalla chiave: write-behind

• enabled: true (valore predefinito e consigliato) ofalse, per abilitare o disabilitare il meccanismo write-behind. La disabilitazione del meccanismo avrà un forte impatto sulle prestazioni di scrittura ed è sconsigliata.

• maxDelay: una durata massima per l'attivazione dei thread. Il valore predefinito è (un secondo). "1s" In genere è consigliabile mantenere il valore predefinito, a meno che condizioni specifiche non richiedano l'ottimizzazione di questo valore. In ogni caso, il valore deve essere mantenuto basso (inferiore a 3 secondi). Il formato per la stringa di ritardo è: <integer value><optional whitespace><time unit> dove <time unit> deve essere selezionato tra i seguenti valori:

  • "ns": nanosecondi

  • "µs": microsecondi

  • "ms": millisecondi

  • "s": secondi

• threads: il numero di thread write-behind dedicati. L'impostazione predefinita è. 5 È necessario regolare questo valore in base alla potenza di calcolo dell'host su cui è installato il motore Blusam. Non è importante utilizzare un valore molto più alto, sperando in un aumento delle prestazioni poiché il fattore limitante sarà la capacità dello storage RDBMS di gestire numerose query batch simultanee. I valori consigliati sono generalmente compresi tra 4 e 8.

• batchSize: un numero intero positivo che rappresenta il numero massimo di record in un lotto che verranno inviati a un thread per il trattamento di massa. Il suo valore deve essere compreso tra 1 e 32767. Il valore predefinito è. 10000 L'utilizzo di 1 as value vanifica lo scopo del meccanismo, che è quello di evitare l'uso di query di aggiornamento atomiche; il valore minimo adatto da utilizzare è disponibile. 1000

EhCache Ottimizzazione integrata: le proprietà hanno il prefisso key: ehcache

• resource-pool:

  • size: dimensione della memoria allocata per la cache incorporata, espressa come stringa. Il valore predefinito è "1024MB" (1 gigabyte). Da regolare in base alla memoria disponibile della macchina che ospita il motore Blusam e alla dimensione dei set di dati utilizzati dall'applicazione. Il formato della stringa di dimensioni è: <integer value><optional whitespace><memory unit> dove <memory-unit> deve essere selezionato tra i seguenti valori:

    • B: byte

    • KB: kilobyte

    • MB: megabyte

    • GB: gigabyte

    • TB: terabyte

  • heap: true oppurefalse, per indicare se la cache utilizzerà o meno la memoria heap JVM. L'impostazione predefinita è true (l'opzione più veloce per le prestazioni della cache, ma l'archiviazione della cache consuma la memoria della memoria RAM JVM on-heap). L'impostazione di questa proprietà su false passerà alla memoria Off-Heap, che sarà più lenta a causa degli scambi richiesti con l'heap JVM.

• timeToLiveMillis: La durata (in millisecondi) per la quale una voce della cache rimane nella cache prima di essere considerata scaduta e rimossa. Se questa proprietà non è specificata, le voci della cache non scadranno automaticamente per impostazione predefinita.

Proprietà di configurazione multischema

• multiSchema: false (valore predefinito) o true, per disabilitare o abilitare la modalità Multischema per Blusam - Disponibile a partire dalla versione 4.4.0.

• pgsql:

  • schemas: Un elenco di nomi di schemi che l'applicazione utilizzerà in modalità multischema per Blusam.

  • fallbackSchema: Il nome dello schema di fallback da utilizzare in modalità multischema. Se non viene trovato un set di dati nel contesto dello schema corrente, questo schema verrà utilizzato per le operazioni relative a Blusam su quel set di dati.

Esempio di frammento di configurazione:

dataSource:
  bluesamDs:
    driver-class-name: org.postgresql.Driver
    ...
    ...
bluesam:
  locks:
    lockTimeOut: 700
  cache: ehcache
  persistence: pgsql
  ehcache:
    resource-pool:
      size: 8GB
  write-behind:
    enabled: true
    threads: 8
    batchsize: 5000  
  pgsql:
    dataSource : bluesamDs 

Frammento di configurazione di esempio (con la modalità multi-schema abilitata per Blusam):

dataSource:
  bluesamDs:
    driver-class-name: org.postgresql.Driver
    ...
    ...
bluesam:
  locks:
    lockTimeOut: 700
  cache: ehcache
  persistence: pgsql
  ehcache:
    resource-pool:
      size: 8GB
  write-behind:
    enabled: true
    threads: 8
    batchsize: 5000 
  multiSchema: true 
  pgsql:
    dataSource : bluesamDs
    schemas: 
      - "schema1"
      - "schema2" 
      - "schema3"
    fallbackSchema: schema3

Nota

Gli schemi di metadati Blusam, inclusi gli schemi elencati nel application-main.yml file per la modalità Multischema, vengono creati nel database blusam se non esistono e l'utente dispone di privilegi sufficienti.

Console di amministrazione Blusam

La Blusam Administration Console (BAC) è un'applicazione web, utilizzata per amministrare lo storage Blusam. Per informazioni sul BAC, vedere. AWS Console di amministrazione Blu Age Blusam

Appendice

Attributi generali dei metadati dei set di dati

Elenco generale degli attributi di serializzazione dei metadati dei set di dati:

• nome (del set di dati)

• tipo (KSDS, LargeKSDS, ESDS, LargeESDS o RRDS)

• flag di riscaldamento della cache (se il set di dati deve essere precaricato nella cache all'avvio del server o meno)

• flag di utilizzo della compressione (se memorizzare i record in formato compresso o raw)

• data di creazione

• data dell'ultima modifica

• indicatore di registrazione a lunghezza fissa (se i record del set di dati hanno tutti la stessa lunghezza o meno)

• lunghezza del record: significativa solo per una lunghezza di record fissa

• dimensione della pagina (utilizzata per personalizzare le query sql impaginate utilizzate per precaricare la cache quando necessario)

• dimensione (dimensione del set di dati - lunghezza cumulata dei record)

• ultimo offset (offset, ovvero RBA dell'ultimo record aggiunto al set di dati)

• next offset (prossimo offset disponibile per aggiungere un nuovo record al set di dati)

• se significativa, definizione delle chiavi utilizzate dal set di dati; ogni chiave è definita in base al suo tipo (principale o parte della raccolta di chiavi alternative) e tre attributi:

  • offset: posizione nel record del byte iniziale del valore della chiave;

  • lunghezza: lunghezza in byte del valore della chiave. Quindi il valore chiave è l'array di byte che è il sottoinsieme del record che inizia dalla posizione key offset e finisce nella posizione; key offset + length - 1

  • flag duplicates allowed: indica se la chiave accetta o meno i duplicati (impostato su true per consentire i duplicati).

Stima dell'impronta di memoria per un determinato set di dati

Per set di dati di piccole e medie dimensioni, i metadati (dimensioni e indici per varie chiavi) verranno caricati completamente in memoria. L'allocazione di risorse adeguate per la macchina che ospita il server utilizzato per eseguire applicazioni modernizzate richiede di calcolare il consumo di memoria indotto dai set di dati Blusam, in particolare per quanto riguarda i metadati. Questa sezione fornisce risposte pratiche agli operatori interessati.

Le formule fornite si applicano solo ai set di dati Blusam di piccole e medie dimensioni e non utilizzano la strategia di archiviazione «Large».

Metadati del set di dati Blusam

Per un set di dati Blusam, i metadati sono suddivisi in due parti:

• metadati principali: contiene informazioni globali sul set di dati. L'impronta di memoria di questo può essere considerata trascurabile rispetto ai metadati interni.

• metadati interni: contengono informazioni sulle dimensioni dei record e sugli indici chiave; quando un set di dati non è vuoto, questo è ciò che consuma memoria quando viene caricato nel server delle applicazioni che ospita le applicazioni modernizzate. Le sezioni seguenti descrivono in dettaglio come la memoria consumata cresce con il numero di record.

Calcolo dell'impronta dei metadati interni

Mappa delle dimensioni dei record

Innanzitutto, i metadati interni memorizzano una mappa per contenere la dimensione di ogni record (come numero intero), dato il relativo RBA (indirizzo di byte relativo, memorizzato come numero lungo).

L'impronta di memoria di quella struttura di dati è, in byte: 80 * number of records

Questo vale per tutti i tipi di set di dati.

Indici

Per quanto riguarda gli indici della chiave primaria di KSDS o delle chiavi alternative sia su ESDS che su KSDS, il calcolo dell'impronta dipende da due fattori:

• il numero di record nel set di dati;

• la dimensione della chiave, in byte.

Il grafico seguente mostra la dimensione dell'indice della chiave per record (asse y) in base alla dimensione della chiave (asse x).

La formula corrispondente per valutare l'impronta per un determinato indice chiave di un set di dati è:

index footprint = number of records * ( 83 + 8 (key length / 8))

dove '/' sta per la divisione intera.

Esempi:

• set di dati 1:

  • numero di record = 459 996

  • lunghezza della chiave = 15 quindi (lunghezza della chiave/8) = 1

  • impronta dell'indice = 459 996 * (83 + (8*1)) = 41 859 636 byte (= 39 MB circa)

• set di dati 2:

  • numero di record = 13 095 783

  • lunghezza della chiave = 18 quindi (lunghezza della chiave/8) = 2

  • ingombro dell'indice = 13 095 783 * (83 + (8*2)) = 1 296 482.517 byte (= 1,2 GB circa)

L'impronta totale per un determinato set di dati è la somma di tutte le impronte per tutti gli indici delle chiavi e l'impronta per la mappa delle dimensioni dei record.

Ad esempio, prendendo l'esempio del set di dati 2, che ha una sola chiave, l'impronta globale è:

• Mappa delle dimensioni dei record: 13 095 783 * 80 = 1 047 662 640 byte

• Indici chiave: 1 296 482 517 byte (vedi sopra)

• Ingombro totale = 2 344 145 157 byte (= 2,18 GB circa)