Gli ASP: come il sistema divide i dischi

Su un IBM i non si sceglie su quale disco mettere una libreria. Il sistema distribuisce i dati su tutte le unità dell'insieme a cui appartengono, e lo fa da solo. La domanda che segue è: quale insieme?

La risposta è l'ASP, Auxiliary Storage Pool, che nell'interfaccia grafica IBM chiama disk pool: una definizione software di un gruppo di unità disco, che non corrisponde per forza alla loro disposizione fisica. È l'unico livello di scelta che il sistema lascia su dove finiscono i dati, e per questo è anche l'unico strumento che si ha per isolarli.

I tipi di ASP

IBM li divide in due: l'ASP di sistema e gli ASP utente. Gli ASP utente a loro volta sono di base o indipendenti, e i due si comportano in modo diverso.

Un ASP di base riceve il numero da chi lo crea; a un ASP indipendente si dà un nome, e il numero lo assegna il sistema.

L'ASP di sistema più tutti gli ASP di base formano quello che la documentazione chiama SYSBAS: significa «tutto tranne gli ASP indipendenti».

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

SYSDISKSTAT ha una riga per unità disco: PERCENT_USED è quanto è occupata quell'unità.

Gli ASP di base

Sono 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:

• ASP di libreria: contiene librerie, documenti e certi tipi di oggetto.
• ASP senza librerie: non contiene librerie, ma solo tre tipi di oggetto: journal, journal receiver e file di salvataggio. La libreria dell'oggetto deve stare nell'ASP di sistema; lo spazio dell'oggetto, e tutto quello che gli si aggiunge dopo, sta nell'ASP utente.

CRTSAVF FILE(SAVFLIB/DSTSAV) ASP(4)

Il traboccamento

Quando un ASP di base si riempie, i dati traboccano nell'ASP di sistema: l'ASP passa nello stato overflowed. Il lavoro continua, ma l'isolamento e la protezione che l'ASP doveva dare si perdono.

Riportare gli oggetti traboccati nel loro ASP, senza IPL, si fa così:

1. si trovano gli oggetti traboccati: DSPOBJD con DETAIL(*FULL) e OUTPUT(*OUTFILE) su ogni libreria dell'ASP, e nel file di uscita il campo ODOASP vale 1 per quelli traboccati;
2. si salvano su un supporto di appoggio;
3. si cancellano (journal, journal receiver e file fisici chiedono passi in più prima della cancellazione);
4. si controlla che l'ASP non sia più traboccato: in QSYSOPR arriva un messaggio che lo dice.

Per gli ASP di base si può anche abilitare il recupero automatico del traboccamento, dalla gestione dei dischi di System i Navigator.

La difesa è la soglia di occupazione, che ogni ASP ha e che di serie vale il 90%. Si cambia dagli strumenti di servizio: STRSST, opzione 3 (Work with disk units), opzione 2 (Work with disk configuration), opzione 3 (Work with ASP threshold). Il messaggio arriva in QSYSOPR, ed è utile solo se qualcuno guarda quella coda: è il motivo per cui nel capitolo sui messaggi si consiglia di creare QSYSMSG.

Su un ASP senza librerie conviene anche tenere d'occhio la crescita dei singoli oggetti: IBM indica il parametro MAXRCDS di CRTSAVF e THRESHOLD di CRTJRNRCV.

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 rendono disponibili e non disponibili. 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)

All'IPL non entra in gioco: è al momento di renderlo disponibile che il sistema controlla che ci siano tutte le sue unità disco. Finché non è disponibile, i suoi dati non sono raggiungibili.

L'operazione non è istantanea, e IBM dice da che cosa dipende. Se la maggior parte dei dati utente sta nell'iASP e SYSBAS contiene soprattutto il sistema operativo, i tempi sono i più brevi; se molti dati restano in SYSBAS, renderlo disponibile richiede più lavoro, perché le informazioni del database vanno fuse con quelle del gruppo. Dopo uno spegnimento anomalo conta anche la ricostruzione dei percorsi di accesso, che si può limitare con CHGRCYAP.

Si spostano. In un cluster, un iASP associato a un dispositivo commutabile si sposta da un sistema all'altro senza IPL: lo si rende non disponibile su un nodo e disponibile sull'altro. I dati appartengono all'iASP, non alla macchina, ed è per questo che è il mattone dell'alta disponibilità su questa piattaforma. Esistono anche la copia su un secondo sito (cross-site mirroring) e FlashCopy.

Non traboccano. Un iASP pieno non trabocca nell'ASP di sistema: se lo facesse perderebbe la sua indipendenza. Quando si avvicina alla soglia bisogna aggiungere unità disco o cancellare oggetti.

Sono un database a sé. Ogni gruppo di iASP è un database relazionale separato, con la sua voce nell'elenco dei database relazionali:

WRKRDBDIRE

Dall'esterno ci si collega indicando quel nome; da un job sul sistema serve invece dire esplicitamente che si vuole lavorare lì dentro.

Un job vede l'iASP solo con SETASPGRP

Un job non vede le librerie di un iASP finché non imposta il suo gruppo di ASP.

SETASPGRP ASPGRP(IASPPROD)

Da quel momento le librerie dell'iASP fanno parte dello spazio dei nomi delle librerie del thread, insieme a quelle dell'ASP di sistema e degli ASP di base, e si possono nominare con la sintassi normale LIBRERIA/OGGETTO. Prima non ci sono.

Che cosa non ci può stare

Un iASP non può contenere tutto. Fra i tipi di oggetto che IBM elenca come non ammessi ci sono i profili utente (*USRPRF), le liste di autorizzazione (*AUTL), le descrizioni di dispositivo, linea e controllore, le schedulazioni (*JOBSCD), i documenti e le cartelle (*DOC, *FLR). Librerie, file, programmi, code di job e di messaggi, journal e journal receiver invece sì.

La protezione e i guasti

La protezione a specchio si configura per ASP: si possono proteggere uno, alcuni o tutti.

Un ASP separato serve a contenere che cosa va ripristinato, non a evitare il fermo. Gli iASP in qualche caso riescono anche a isolare il guasto di un'unità al loro interno, e per gli ASP indipendenti spenti si possono avviare la protezione a specchio o a parità senza portare il sistema in DST.

Quando conviene

I journal receiver in un ASP separato sono il caso d'uso classico: crescono in fretta, e un ASP senza librerie esiste proprio per tenerli fuori dall'ASP di sistema. IBM usa lo stesso esempio per gli iASP: un gruppo con l'ASP primario per i dati e i journal, e un ASP secondario per i receiver.

Un iASP ha senso quando c'è, o ci sarà, una soluzione di alta disponibilità, ma anche su un sistema solo: per tenere spenti dati che servono di rado, accorciare l'IPL e il RCLSTG, salvare e ripristinare per ASP, separare i dati di un'applicazione o di un gruppo di utenti.

Non per andare più veloci. Dentro un ASP il sistema distribuisce i dati su tutte le sue unità: dividere i dischi in più ASP dà a ciascuno meno unità su cui distribuire. Se lo scopo è la velocità, la divisione va misurata, non data per scontata.

Non senza qualcuno che guardi le soglie. Un ASP di base che nessuno sorveglia 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, NUMBER_OF_DISK_UNITS,
       DEC(100 - (DEC(TOTAL_CAPACITY_AVAILABLE, 19, 0) * 100
                  / NULLIF(TOTAL_CAPACITY, 0)), 5, 1) AS PERCENTUALE_USATA,
       STORAGE_THRESHOLD_PERCENTAGE AS SOGLIA
  FROM QSYS2.ASP_INFO
 ORDER BY ASP_NUMBER

ASP_INFO è una vista con una riga per ASP. Non porta una percentuale di occupazione già pronta: porta la capacità totale e quella libera, in megabyte, e la percentuale si calcola. NUMBER_OF_DISK_UNITS conta una coppia di unità a specchio come un'unità sola. ASP_TYPE vale SYSTEM, USER, PRIMARY, SECONDARY o UDFS.

STORAGE_THRESHOLD_PERCENTAGE è la soglia: raggiunta quella, il sistema manda CPF0907 per l'ASP di sistema e CPI0953 per un ASP utente. Metterla accanto alla percentuale reale dice non solo quanto è pieno un ASP, ma quanto manca al punto in cui qualcuno se ne accorgerà.

Esempio. I numeri sono inventati, per mostrare come si legge: un ASP 2 di base al 87% con la soglia al 90% è a tre punti dal primo messaggio in QSYSOPR; se la riga dice 95% e la soglia è ancora 90%, il messaggio è già partito, e se nessuno l'ha visto l'ASP può essere vicino al traboccamento.

Rilasci. WRKDSKSTS e gli strumenti di servizio ci sono su qualunque rilascio. Le pagine IBM citate qui sotto sono quelle di 7.5. QSYS2.SYSDISKSTAT e QSYS2.ASP_INFO fanno parte degli IBM i Services: 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 crea e cancella un ASP indipendente, e la sua descrizione di dispositivo, senza passare dagli strumenti di servizio.

Fonti

• IBM: Types of disk pools
• IBM: Basic disk pools
• IBM: Contrasting basic and independent disk pools
• IBM: Working with nonlibrary user ASPs e Creating objects in a nonlibrary user ASP
• IBM: Recovering an overflowed user ASP e Resetting an overflowed user ASP without an IPL
• IBM: Changing the storage threshold for an ASP
• IBM: Reducing the time to vary on independent disk pools
• IBM: Benefits of independent disk pools e Disk pool groups
• IBM: User databases on independent ASPs
• IBM: Set ASP Group (SETASPGRP) e Configure Device ASP (CFGDEVASP)
• IBM: Supported and unsupported object types
• IBM: How mirrored protection works
• IBM: ASP_INFO view e SYSDISKSTAT view