Gli ASP: come il sistema divide i dischi

Su un IBM i non si sceglie su quale disco mettere una libreria. Il sistema distribuisce ogni oggetto su tutte le unità disponibili, e lo fa da solo. La domanda che segue è: tutte le unità di che cosa?

La risposta è l'ASP — Auxiliary Storage Pool, in italiano un insieme di unità di memoria ausiliaria. È l'unico livello di scelta che il sistema lascia su dove finiscono fisicamente i dati, e per questo è anche l'unico strumento che si ha per isolarli.

Uno o più insiemi

Un ASP è un gruppo di unità disco trattato come uno spazio solo. Dentro un ASP la distribuzione è automatica; fra ASP diversi non c'è nessuna comunicazione: sono compartimenti.

Ne esistono tre categorie, e non sono varianti dello stesso oggetto — si comportano in modo diverso.

L'ASP di sistema più tutti gli ASP di base formano quello che la documentazione chiama SYSBAS. È un termine che si incontra spesso e vale la pena riconoscerlo: significa "tutto tranne gli ASP indipendenti".

L'unità 1 dell'ASP 1 è la load source, il disco da cui il sistema parte. Sta lì e non si sposta.

WRKDSKSTS

SELECT ASP_NUMBER, UNIT_NUMBER, UNIT_TYPE,
       DEC(PERCENT_USED, 5, 1) AS PERCENTUALE
  FROM QSYS2.SYSDISKSTAT
 ORDER BY ASP_NUMBER, PERCENT_USED DESC

Gli ASP di base

Sono la forma più antica e la più semplice: un insieme di dischi in più, sempre acceso, sempre attaccato a questa macchina. Un oggetto ci finisce perché qualcuno lo ha deciso al momento di crearlo.

CRTLIB LIB(ARCHIVIO) ASP(2)
CRTJRNRCV JRNRCV(JRNLIB/RCV0001) ASP(3)

Un ASP di base può essere di due tipi, e la distinzione è netta:

• ASP di libreria — contiene librerie e tutto quello che ci sta dentro. È la forma normale oggi.
• ASP senza librerie — non contiene librerie, ma solo alcuni tipi di oggetto: journal receiver, file di salvataggio e documenti. È la forma storica, nata esattamente per il caso d'uso più diffuso: tenere i journal receiver fuori dall'ASP di sistema perché, crescendo, non lo riempiano.

Il traboccamento

Questo è il comportamento che sorprende, e che vale la pena conoscere prima di incontrarlo.

Quando un ASP di base si riempie, il sistema non si ferma e non rifiuta la scrittura: gli oggetti traboccano nell'ASP di sistema. Il lavoro continua, e il compartimento che si era costruito con cura non esiste più.

La difesa è la soglia di occupazione, che ogni ASP ha e che si imposta dagli strumenti di servizio (STRSST, gestione delle unità disco). Superata la soglia, il sistema manda un messaggio a QSYSOPR — che è utile solo se qualcuno guarda quella coda, ed è il motivo per cui nel capitolo sui messaggi si consiglia di creare QSYSMSG.

Gli ASP indipendenti

Gli iASP sono un'altra cosa, non un ASP di base con un numero più alto. Le differenze che contano sono quattro.

Si accendono e si spengono. Un iASP è un dispositivo, con una descrizione di dispositivo, e va reso disponibile:

VRYCFG CFGOBJ(IASPPROD) CFGTYPE(*DEV) STATUS(*ON)
WRKCFGSTS CFGTYPE(*DEV) CFGD(IASPPROD)

Finché è spento, il suo contenuto non esiste per il sistema. L'accensione non è istantanea: il tempo cresce con il numero di oggetti contenuti, perché il database deve ricostruire i riferimenti incrociati. Su un iASP grande sono minuti, e vanno messi in conto nei tempi di ripartenza.

Si spostano. È la ragione per cui esistono. Un iASP può essere staccato da una macchina e attaccato a un'altra — fra partizioni, fra sistemi in cluster, o replicato a distanza. È il mattone su cui è costruita l'alta disponibilità su questa piattaforma: i dati stanno nell'iASP, e in caso di guasto è l'iASP a cambiare padrone, non i dati a essere copiati nel momento peggiore.

Non traboccano. A differenza degli ASP di base, un iASP pieno è pieno: le operazioni che richiedono spazio falliscono, con un errore. È un comportamento peggiore da subire e migliore da governare, perché il problema si manifesta invece di nascondersi.

Hanno un database proprio. Un iASP compare come base di dati relazionale separata:

WRKRDBDIRE

Dall'esterno ci si collega indicando quel nome, e da un job sul sistema serve invece dire esplicitamente che si vuole lavorare lì dentro. È il punto in cui quasi tutti inciampano la prima volta.

Il gotcha: SETASPGRP

Un job non vede le librerie di un iASP finché non entra nel suo gruppo di ASP.

SETASPGRP ASPGRP(IASPPROD)

Da quel momento le librerie dell'iASP sono raggiungibili e possono stare nella lista librerie del job; prima, semplicemente non esistono.

Che cosa non ci può stare

Un iASP non può contenere tutto. I profili utente restano in SYSBAS, e con loro gli oggetti di sistema e la configurazione: sono cose che appartengono alla macchina, non ai dati che si spostano fra macchine.

La protezione è per ASP

Specchiatura e RAID si configurano per unità, e quindi in pratica per ASP: ogni insieme può avere il proprio livello di protezione.

Da qui discende il vero motivo per cui isolare i dati serve. Se un'unità non protetta si guasta, si perde l'ASP a cui appartiene, non l'intero sistema: gli altri restano. Perdere un ASP di dati significa ripristinare quell'ASP; perdere l'ASP di sistema significa ricostruire la macchina.

Quando conviene, e quando no

Ha senso tenere i journal receiver in un ASP separato: crescono in fretta, e il loro riempimento non deve toccare il sistema. Ha senso isolare i dati di un'applicazione con requisiti propri di conservazione o di ripristino. Ha senso un iASP quando c'è, o ci sarà, una soluzione di alta disponibilità: senza iASP quella strada si percorre in altri modi, tutti più laboriosi.

Non ha senso creare ASP per andare più veloci. Il ragionamento intuitivo — "separo i dati pesanti così non si disturbano" — è quasi sempre sbagliato su questa piattaforma, perché il sistema guadagna prestazioni distribuendo su più bracci possibili. Dividere dieci dischi in due ASP da cinque dà a ciascun carico metà dei bracci di prima.

Non ha senso creare ASP senza aver deciso chi guarda le soglie. Un compartimento che nessuno sorveglia è un compartimento che prima o poi trabocca, e a quel punto si è pagata la complicazione senza avere l'isolamento.

Guardare la situazione

WRKDSKSTS
STRSST

SELECT ASP_NUMBER, ASP_TYPE, ASP_STATE,
       TOTAL_CAPACITY_AVAILABLE, PERCENT_USED
  FROM QSYS2.ASP_INFO
 ORDER BY ASP_NUMBER

Rilasci. WRKDSKSTS e gli strumenti di servizio ci sono su qualunque rilascio. QSYS2.SYSDISKSTAT e QSYS2.ASP_INFO fanno parte degli IBM i Services, aggiunti in rilasci diversi e ampliati nel tempo: se una query risponde SQL0204 — oggetto non trovato — quella vista non c'è su questo sistema, e le stesse informazioni restano disponibili a schermo. Il comando CFGDEVASP, che crea e cancella un ASP indipendente senza passare dagli strumenti di servizio, è più recente degli iASP stessi: dove non esiste, la configurazione si fa da STRSST.