Principi del Sysplex parallelo
Un Parallel Sysplex® è un insieme di sistemi z/OS® che utilizzano in modo cooperativo determinati componenti hardware e software per ottenere un ambiente di elaborazione dei carichi di lavoro ad alta disponibilità.
- Il sysplex di base è stato introdotto nel 1990.
- Il Sysplex parallelo è stato introdotto nel 1994 con l'aggiunta della Struttura di accoppiamento.
- Riduzione/eliminazione di singoli punti di guasto all'interno del server, delle LPAR e dei sottosistemi
- Miglioramento della disponibilità delle applicazioni
- Un'immagine di sistema singola
- Bilanciamento dinamico delle sessioni
- Instradamento dinamico delle transazioni
- Capacità scalabile
Componenti di Sysplex parallelo
Un Sysplex parallelo è un insieme di sistemi che hanno tutti accesso alla stessa o a più strutture di accoppiamento. Mentre un sysplex di base è un'entità reale, con un nome definito (il nome del sysplex), un sysplex parallelo è più concettuale. Non esiste un unico luogo che mantenga il nome del Parallel Sysplex e un elenco dei sistemi in esso contenuti. I componenti di un Parallel Sysplex sono numerosi:
- Coupling Facility
- Un componente chiave di qualsiasi Sysplex parallelo è l'infrastruttura della struttura di accoppiamento (CF). In un Sysplex parallelo, i Complessi di processori centrali (CPC) sono collegati attraverso il CF. Il CF è costituito da hardware e microcodice specializzato (codice di controllo) che fornisce servizi ai sistemi di un sysplex. Una FC viene eseguita in un proprio LPAR. Le aree di memoria CF sono assegnate per l'uso specifico di chi sfrutta la CF. Queste aree sono chiamate strutture. Esistono tre tipi di struttura:
- Lock: per la serializzazione dei dati con elevata granularità. I blocchi sono utilizzati, ad esempio, da IRLM per i database IMS DB e IBM® MQ e da CICS® quando si utilizza DFSMS VSAM RLS.
- Cache: per memorizzare i dati e mantenere le informazioni sulla coerenza del pool di buffer locali. Le cache sono utilizzate, ad esempio, da DFSMS per la condivisione dei cataloghi, dai database RACF®, dai database IBM MQ, dai database VSAM e OSAM per IMS e da CICS quando si utilizza DFSMS VSAM RLS. Le cache contengono voci di directory e voci di dati opzionali
- Elenco: Per le code condivise e le informazioni sullo stato condiviso. Le strutture di elenco utilizzate da CICS includono le tabelle di dati delle strutture di accoppiamento (CFDT), i contatori denominati, l'archiviazione temporanea condivisa CICS e lo stato della regione CICSPlex® SM.
Il componente XES (Cross-System Extended Services) di z/OS consente alle applicazioni e ai sottosistemi di sfruttare la funzione di accoppiamento.
Le caratteristiche di alta disponibilità di Parallel Sysplex si basano sulla capacità di spostare senza interruzioni le strutture da una CF all'altra, consentendo di mettere offline una CF per il servizio senza impattare i sistemi che la utilizzano. Tutti i Sysplex paralleli devono avere almeno due CF e queste CF devono essere accessibili a tutti i membri del sysplex.
- Set di dati di coppia
- z/OS richiede che un set di dati (e un set di dati alternativo è consigliato per la disponibilità) sia condiviso da tutti i sistemi del Parallel Sysplex. z/OS memorizza le informazioni relative al Parallel Sysplex, ai sistemi, ai gruppi XCF e ai loro membri, nel dataset sysplex couple.
- XCF
I servizi XCF (Cross System Coupling Facility) consentono ai programmi autorizzati di un sistema di comunicare con programmi dello stesso sistema o di altri sistemi. Se un sistema si guasta, i servizi XCF consentono di riavviare i lavori batch e i task avviati su un altro sistema idoneo del sysplex.
I componenti dell'applicazione sono definiti in XCF e sono consapevoli dell'esistenza di altri componenti che supportano l'applicazione. Se un componente si guasta, XCF informa automaticamente gli altri componenti. Per ulteriori informazioni su XCF, vedere Concetti di XCF nella programmazione di z/OS MVS : Guida ai servizi Sysplex.
I nodi di un sysplex utilizzano gli XCF Communication Services (XCF) per eseguire il coordinamento tra gli stack TCP/IP del sysplex, per scoprire quando vengono avviati nuovi stack TCP/IP e per sapere quando uno stack TCP/IP viene interrotto o lascia il gruppo XCF (in seguito a un guasto). Queste informazioni sono essenziali per automatizzare lo spostamento delle applicazioni e per consentire a sysplex Distributor di prendere decisioni intelligenti sulla gestione dei carichi di lavoro. I messaggi di comunicazione XCF possono essere trasportati attraverso una struttura di accoppiamento o direttamente attraverso una connessione IBM Enterprise Systems Connection (ESCON) o IBM Fibre Channel (FICON®).
- logger di sistema
- z/OS System Logger offre una funzionalità di registrazione generalizzata per salvare e richiamare i record di registro. Fornisce un singolo syslog che combina tutte le informazioni provenienti da tutti i sistemi del sysplex. Gli sfruttatori di System Logger includono OPERLOG, per il syslog a livello di sysplex, LOGREC, per le informazioni sugli errori a livello di sysplex, e CICS, che scrive i suoi record di log DFHLOG e DFHSHUNT in Logger.
- z/OS responsabile del carico di lavoro
- Un componente di z/OS che offre la possibilità di eseguire più carichi di lavoro contemporaneamente all'interno di un'immagine z/OS o tra più immagini.
Rete parallela Sysplex
L'obiettivo generale della progettazione di un ambiente Sysplex parallelo ad alta disponibilità è quello di creare un ambiente in cui la perdita di un singolo componente non influisca sulla disponibilità dell'applicazione. Per ottenere un'elevata disponibilità e superare automaticamente i guasti del sistema o del sottosistema all'interno di un Parallel Sysplex, è necessario evitare di legare un'applicazione a un singolo indirizzo di rete fisso. Ci sono diversi modi per farlo:
- VIPA (indirizzamento IP virtuale)
- Tradizionalmente, un indirizzo IP è associato a un collegamento fisico e, sebbene i guasti nei collegamenti intermedi della rete possano essere reinstradati, gli endpoint sono punti di guasto. VIPA è stato introdotto per fornire connessioni di rete a tolleranza di errore a uno stack di sistema TCP/IP per z/OS. Ciò consente di definire un'interfaccia virtuale non associata a componenti hardware e sempre disponibile. Per la rete di routing il VIPA appare come un indirizzo host collegato indirettamente a z/OS. I server dei nomi sono configurati per restituire il VIPA dello stack TCP/IP, non dell'interfaccia fisica. Se l'interfaccia fisica si guasta, vengono inviati aggiornamenti dinamici del percorso per aggiornare le tabelle di routing IP e utilizzare un percorso alternativo; le connessioni IP non vengono interrotte ma recuperate in modo non distruttivo attraverso le interfacce fisiche rimanenti.Esistono due versioni di VIPA:
- Statico VIPA
- VIPA dinamico (DVIPA)
Un VIPA statico è un indirizzo IP associato a un particolare stack TCP/IP. Utilizzando l'ARP takeover o un protocollo di routing dinamico, ad esempio OSPF, le VIPA statiche possono consentire alle comunicazioni delle applicazioni z/OS di continuare a non essere influenzate da guasti alle interfacce di rete. Mentre una singola interfaccia di rete è operativa su un host, la comunicazione con le applicazioni sull'host persiste. Il VIPA statico non richiede il sysplex (comunicazioni XCF) perché non richiede il coordinamento tra gli stack TCP/IP.
I VIPA dinamici (DVIPA) possono essere definiti su più stack e spostati automaticamente da uno stack TCP/IP all'altro nel sysplex. Uno stack è definito come stack primario o proprietario, mentre gli altri sono definiti come stack di backup. Solo lo stack primario viene reso noto alla rete IP.
Gli stack TCP/IP in un sysplex si scambiano informazioni sui DVIPA, sulla loro esistenza e sulla loro posizione attuale, e gli stack sono costantemente al corrente del funzionamento degli stack partner. Se lo stack proprietario lascia il gruppo XCF, ad esempio a causa di un guasto, uno degli stack di backup prende automaticamente il suo posto e assume la proprietà del DVIPA. La rete vede solo un cambiamento nelle tabelle di routing o nell'adattatore che risponde alle richieste ARP. Le applicazioni associate a questi DVIPA sono attive sui sistemi di backup, fornendo un hot standby e un'alta disponibilità per i servizi. Gli indirizzi DVIPA identificano le applicazioni indipendentemente dalle immagini del sysplex su cui vengono eseguite e consentono a un'applicazione di mantenere la propria identità quando viene spostata tra le immagini di un sysplex.
- Distributore Sysplex
- Un distributore Sysplex fornisce la gestione del carico di lavoro delle connessioni all'interno di un sysplex. Bilancia i carichi di lavoro e gli accessi tra i sistemi che implementano più istanze di applicazioni concorrenti, ognuna delle quali condivide l'accesso ai dati. Il Sysplex Distributor consente di distribuire un carico di lavoro IP a più istanze server all'interno del sysplex senza richiedere modifiche ai client o all'hardware di rete e senza ritardi nella configurazione delle connessioni. Con Sysplex Distributor, è possibile implementare un VIPA dinamico come un singolo indirizzo IP visibile in rete, utilizzato per un insieme di host che appartengono allo stesso cluster sysplex. Un client sulla rete IP vede il cluster sysplex come un unico indirizzo IP, indipendentemente dal numero di host nel cluster.
Utilizzando la gestione interna del carico di lavoro in un ambiente z/OS, quando viene ricevuta una richiesta di connessione TCP per un determinato indirizzo DVIPA distribuito, la decisione su quale istanza dell'applicazione serve quella particolare richiesta viene presa dal Sysplex Distributor in esecuzione nello stack TCP/IP configurato come stack di routing. Il Sysplex Distributor dispone di informazioni sulla capacità in tempo reale (dal sysplex workload manager) e può utilizzare le informazioni QoS del Service Policy Agent. Di conseguenza, la gestione interna del carico di lavoro non richiede hardware esterno speciale. Tuttavia, tutti i messaggi in entrata nel DVIPA distribuito devono prima transitare nello stack di routing prima di essere inoltrati all'istanza applicativa appropriata.
- condivisione porta
- La condivisione delle porte è un metodo per distribuire il carico di lavoro delle applicazioni IP all'interno di una LPAR z/OS. Il TCP/IP consente di ascoltare più ascoltatori sulla stessa combinazione di porta e interfaccia. Il carico di lavoro destinato a questa applicazione può essere distribuito tra il gruppo di server in ascolto sulla stessa porta. La condivisione delle porte non si basa su un'implementazione attiva di Sysplex Distributor; funziona anche senza Sysplex Distributor. Tuttavia, è possibile utilizzare la condivisione delle porte in aggiunta al funzionamento di Sysplex Distributor.z/OS supporta due modalità di condivisione delle porte:
- SHAREPORT
- SHAREPORTWLM
SHAREDPORT, se specificato nell'istruzione PORT, le connessioni client in arrivo per questa porta e interfaccia sono distribuite dallo stack TCP/IP tra gli ascoltatori, utilizzando un metodo di distribuzione round-robin ponderato basato sulle frazioni di efficienza di accettazione del server (SEF) degli ascoltatori che condividono la porta. Il SEF è una misura dell'efficienza dell'applicazione server, calcolata a intervalli di circa un minuto, nell'accettare nuove richieste di connessione e nel gestire la coda di arretrati.
SHAREPORTWLM può essere utilizzato al posto di SHAREPORT. Simile a SHAREPORT, SHAREPORTWLM fa sì che le connessioni in arrivo vengano distribuite tra un insieme di ascoltatori TCP. Tuttavia, a differenza di SHAREPORT, la selezione degli ascoltatori si basa su raccomandazioni specifiche del server WLM, modificate dai valori SEF di ciascun ascoltatore. Queste raccomandazioni vengono acquisite a intervalli di circa un minuto da WLM e riflettono la capacità dell'ascoltatore di gestire il lavoro supplementare.
- z/OS Communications Server risorse generiche
- le risorse generiche di z/OS Communications Server forniscono un'unica immagine di sistema di un'applicazione, indipendentemente dalla sua posizione nel sysplex. Un utente accede all'applicazione utilizzando il nome generico della risorsa dell'applicazione e z/OS Communications Server determina l'istanza effettiva dell'applicazione in base a criteri di prestazioni e carico di lavoro. Ciò consente di aggiungere, rimuovere e spostare le istanze dell'applicazione senza alcun impatto sull'utente.
Per ulteriori informazioni sull'uso delle risorse generiche di z/OS Communications Server in CICS, vedere Configurazione delle risorse generiche di z/OS Communications Server.