Unicenter e' un programma, prodotto da CA che consente la gestione dei sistemi in rete. In particolare vengono gestite le schedulazioni delle applicazioni, la sicurezza, i salvataggi, ...
Unicenter e' disponibile su un'ampia varieta' di sistemi ed ambienti: praticamente su tutti gli ambienti commericiali. Unicenter e' utilizzato generalmente in realta' di ampie dimensioni e complesse. In tali realta' l'utilizzo di uno strumento unico per la gestione dei sistemi e le notevoli funzionalita' relative alla schedulazione delle applicazioni ed al loro controllo sono elementi di notevole importanza.
In questo documento vengono riportate alcune informazioni relative all'amministrazione di CA Unicenter in ambiente Unix.
Lo stato di Unicenter si controlla con il comando unifstat. L'attivazione dei processi si effettua con unistart all. La disattivazione dei processi si effettua con unishutdown all. In realta' ogni singolo componente puo' essere singolarmente attivato o disattivato (eg. unistart sche).
Ogni singola installazione prevede differenti processi relativi a funzionalita' differenti.
Per il la gestione di Unicenter possono essere utilizzati i comandi in linea cautil. Ad esempio con cautil stop autosub si blocca la schedulazione automatica e con cautil status monitor si controlla lo stato del sistema; con cautil list jobset si ottiene l'elenco dei jobset...
Anche il modulo di ENF (che si occupa dell'aggancio con il sistema operativo) ha una serie di comandi di controllo. Sono ad esempio utilizzati comunemente (per governare in modo corretto il modulo di Workload):
enfcontrol JOB TRIGGER EXITMAIN enfcontrol JOB RC EXITMAIN enfcontrol JOB CPUTIME EXITMAIN
L'attivita' piu' significativa che e' possibile svolgere con
Unicenter e' quella della gestione centralizzata e controllata
delle schedulazioni delle applicazioni.
Unicenter permette il controllo dell'andamento delle applicazioni
verificando il codice di ritorno dei ogni singolo programma.
Per poter controllare la corretta riuscita di un programma o di
uno script e' pertanto necessario fare in modo che il programma
(o lo script) restituiscano un codice d'errore al sistema operativo.
Questa e' in effetti l'unico requisito che e' posto alle applicazioni.
Debbono essere quindi disegnate le catene elaborative.
Il modulo di Workload, che
e' brevemente descritto nel seguito nei sui punti principali, si occupa
appunto di sottomettere le corrette catene elaborative e controllarne l'andamento.
Su un sistema centrale, definito server, vengono caricate le schedulazioni delle attivita' che debbono essere seguiti sui diversi sistemi che ospitano le applicazioni, chiamati station.
Le schedulazioni sono composte da JOBSET che hanno un calendario di partenza, legami e vincoli per l'attivazione, ... I JOBSET sono composti da JOB che corrispondono all'attivazione dei singoli programmi. Pertanto nella definizione di un JOB vengono riportati: l'utente con il quale effettuare l'esecuzione, il programma da lanciare, se deve essere lanciato il .profile (o analogo) per il settaggio dell'ambiente, i legami con altri JOB e JOBSET, ...
Con il DEMAND viene posto in schedulazione un jobset
ed entra in stato di START.
Quando tutti i requisiti per la partenza sono soddisfatti partono i vari
JOB. I JOB vengono attivati a seconda dei vincoli che li legano
(che prevedono normalmente attivita' in catene sequenziali).
Un JOB in esecuzione e' in stato di WORKING, un JOB in attesa
di una condizione (tipicamente la fine del JOB precedente) e'
in stato di WPRED.
Il risultato finale di ogni singolo JOB viene controllato: i JOB
che terminano correttamente vanno in stato di COMPLETE,
quelli che riportano un errore vanno in stato di ABEND.
Per rieseguire un JOB andato in ABEND
e' sufficiente dare il comando di SUBMIT. Il comando di
FORCE consente di forzare l'esecuzione
anche di un JOB gia' terminato correttamente.
Naturalmente tali azioni si effettuano quando si e' capita e rimossa
la ragione del malfunzionamento.
Quando tutti i JOB sono terminati correttamente il JOBSET entra
in stato di COMPLETE
Come su tutti gli ambienti che abbiano a che fare con
gli informatici (che e' noto essere dei gran casinisti!)
vi e' un'ampia serie di problematiche tipiche...
Ovviamente e' impossibile citarle tutte, riporto solo quelle
che ritengo piu' interessanti per un amministratore di sistema
(e che non sono gia' state accennate "tra le righe" in precedenza...).
Si tratta di un ambiente complesso e spesso c'e' qualche problemino...
qualche restart non gli fa male ed occhio alle patch!
Unicenter mantiene su database un'ampia serie di informazioni. I database sono diversi (eg. CAIUNIDB, ,CASHDB, SECDB) ed a volte richiedono una qualche gestione... L'importante e' accorgersene in tempo e sapere cosa fare! Ad esempio se si riempe il journal si blocca tutto: il comando cadb_jut ripulisce il journal file.
A volte e' utile selezionare dati dai DB o svolgere operazioni di amministrazione (sono relazionali ed utilizzano l'SQL):
# sql
----------------------------- CA-DB/UNIX ----------------------------
Copyright (C) 1990 Computer Associates International, Inc.
All rights reserved.
Interactive SQL Version 210 Mon Mar 17 17:17:17 1998
SQL: connect to cashdb;
SQL: select nod_name, nod_boot from CA7.NODECORD;
SQL: release;
SQL: quit;
Dall'esempio e' evidente che per entrare in sql il comando e' sql (si esce con quit;).
E' molto difficile trovare documentazione su web...
ma la directory /CAUnicenter/CA/UnicenterNSM/sche/scripts contiene alcuni utili esempi.
Una nota importante: le attivita' di "amministrazione" vanno eseguite "a bocce ferme" ovvero senza utenti connessi alla base dati.
I dettagli interni non interessano a nessuno...
ma poiche' la mia passione sono le architetture di
Database: ne scrivo lo stesso!
L'architettura di CA-DB e' file based. Ogni DB e' costituito da un root file,
da un journal file e da uno o piu' cachefile. La dimensione dei file e' un pagine.
La dimensione massima e' di 65536 pagine.
Un DB e' tipicamente costituito da un table space SYSTEM
e dai table space applicativi (eg. CAICA7DB) ciascuno composto da uno o piu' cachefile.
Il DB contiene tabelle ed indici B-Tree. Le statistiche (eg. caidbck)
riportano in dettaglio il numero di righe di ogni tabella ed i livelli degli indici.
Le modifiche sono protette con il journaling. L'ottimizzatore e' statistico
e le statistiche sono aggiornate solo a richiesta.
I processi che operano sulla base dati sono i dbserver che girano come utente cadb
ed ovviamente "aprono" i file di database:
dbserver 15530 cadb 4u VREG 85,12 30720000 3701 /CAUnicenter/CA/UnicenterNSM/sche/bin/CASHDB.JOUR1 dbserver 15530 cadb 5uR VREG 85,12 819200 3763 /CAUnicenter/CA/UnicenterNSM/sche/bin/CASHDB.ROOT dbserver 15530 cadb 8u VREG 85,12 122880000 3624 /CAUnicenter (/dev/md/dsk/d12) dbserver 15530 cadb 9u VREG 85,12 122880000 3615 /CAUnicenter/CA/UnicenterNSM/sche/bin/CASHFIL1 dbserver 15530 cadb 10u VREG 85,12 122880000 3621 /CAUnicenter/CA/UnicenterNSM/sche/bin/CASHFIL2
Unicenter si integra in modo molto stretto con il sistema
operativo che lo ospita.
Il modulo ENF e' in particolare il componente che
interfaccia il sistema operativo. Si tratta del componente piu'
"delicato" e sui cui e' necessaria porre parecchia attenzione in fase
di installazione. Eventuali incompatibilita' tra le versioni e le patch
del sistema operativo e di tale modulo possono portare anche al panic del
sistema.
In caso di upgrade del sistema operativo e, spesso, anche nel caso di installazione
di una patch e' necessario "reinstallare" il modulo di ENF.
Con la maggior parte dei sistemi Unix si tratta di una normale ricompilazione
del kernel...
Il modulo che si occupa del colloquio tra i demoni di Unicenter tra i diversi sistemi (eg. tra il server di schedulazione e le station) e' il CCI. Naturalmente tale modulo ha difficolta' se la rete sottostante presenta dei problemi. In alcuni casi, dopo che i problemi sulla rete di comunicazione si sono risolti, e' necessario effettuare un restart di tale modulo per ripristinare la comunicazione tra i sistemi controllati da Unicenter.
In alcuni casi il file system su cui e' ospitato Unicenter si esaurisce. Se si esaurisce lui che e' un disco figuriamoci noi!
Il problema e' spesso dovuto ad un file di log. In particolare i file /CAUnicenter/opr/logs/oplog.*
In questo caso l'operativa da seguire e':
Capita... date i comandi:
enfcontrol JOB TRIGGER EXITMAIN enfcontrol JOB RC EXITMAIN enfcontrol JOB CPUTIME EXITMAIN
Per maggiori dettagli leggete questo documento.
Avete installato la sicurezza? C.. vostri!
Qualche volta qualcosa si blocca. Nella maggior parte dei casi giustamente! Pero' siccome poi si deve comunque poter operare sul sistema a volte va sbloccato il tutto con urgenza. I comandi sono:
# Tiro giu secadmin -z # Tiro su secadmin -a secadmin -i all
Data: 30 Marzo 1998
Versione: 1.1.2
Autore: mail@meo.bogliolo.name