Kopplingsanläggning

I IBM System/390 och IBM Z stordatorer är en Coupling Facility eller CF en maskinvara eller virtuell maskin som koordinerar flera processorer.

En parallell sysplex är beroende av en eller flera kopplingsmöjligheter (CF). En kopplingsanläggning är en stordatorprocessor (körs i en egen LPAR, med dedikerad fysisk CP, definierad genom Hardware Management Console (HMC)), med minne och speciella kanaler (CF Links), och ett specialiserat operativsystem som kallas Coupling Facility Control Code ( CFCC). Den har inga I/O-enheter, förutom CF-länkarna. Informationen i CF finns helt och hållet i minnet eftersom CFCC inte är ett virtuellt minnesoperativsystem . En CF har vanligtvis ett stort minne – i storleksordningen flera tiotals gigabyte. CF kör ingen applikationsprogramvara.

När det ursprungligen introducerades exekverades CFCC i en separat 9674 stordatorenhet som i huvudsak var en processor utan andra I/O-faciliteter än CF-länkarna. Senare möjliggjorde IBM användningen av en intern kopplingsfacilitet där CFCC körs i en logisk partition ( LPAR ) definierad i standardprocessorkomplex och kommunicerar över interna länkar inom den processorkomplexa hårdvaran. Interna länkar simuleras, medan länkar till en annan processorenhet sker via koppar- eller optiska fiberkablar. Mer än en CF är vanligtvis konfigurerad i ett Sysplex-kluster för tillförlitlighet och tillgänglighet. Återställningsstöd i z/OS operativsystem gör att strukturer kan byggas om i den alternativa CF i händelse av ett fel.

Med stöd av CF: er, skalar ett Sysplex-kluster mycket bra upp till flera hundra processorer (i upp till 32 medlemmar, var och en med upp till 190 processorer) som kör transaktions- och databasapplikationer. Med hjälp av CF-länkarna kan data utbytas direkt mellan CF-minnet och minnet i de anslutna systemen, med hjälp av en direkt minnesåtkomstliknande mekanism, utan att avbryta ett program som körs. System i ett Sysplex-kluster lagrar CF-information i lokalt minne i ett område som kallas en bitvektor. Detta gör det möjligt för dem att lokalt fråga efter kritisk tillståndsinformation för andra system i Sysplex utan att behöva utfärda förfrågningar till CF. System z Architecture innehåller 18 speciella maskininstruktioner och ytterligare hårdvarufunktioner som stöder CF-drift.

Kopplingsanläggningsstrukturer

En CF används för tre syften:

• Låsinformation som delas mellan alla anslutna system
• Cache-information (som för en databas) som delas mellan alla anslutna system (eller bibehåller koherens mellan lokala buffertpooler i varje system).
• Datalistinformation som delas mellan alla anslutna system

Dessa tre syften tillgodoses av tre typer av struktur:

• Låsa
• Cache
• Lista (och varianten Serialized List )

En struktur är en dedikerad del av CF-minnet. Det sägs vara kopplat till av specifika CF-exploaterande applikationer på de kopplade z/OS- systemen. En typisk Parallell Sysplex innehåller flera strukturer av varje typ. Varje programvaruexploatör kan använda flera strukturer av varje typ. Till exempel använder varje Db2 -datadelningsgrupp en låsstruktur, en liststruktur och flera cachestrukturer (en för varje gruppbuffertpool (GBP)).

Struktur duplex

Strukturer kan duplexas över olika CF:er, vilket gör att två kopior av samma struktur kan hållas synkroniserade. Duplex används ofta som en del av en installations drivkraft för att ta bort enskilda felpunkter, i syfte att minska förekomsten och varaktigheten av applikationsavbrott. I händelse av att en CF misslyckas, används den andra kopian av strukturen för att tillgodose alla önskemål.

Förfrågningar om kopplingsanläggning

En begäran till en CF-struktur är av två slag:

• Synkrona (synk) förfrågningar. När ett z/OS- system utfärdar en begäran väntar det på att begäran ska slutföras och snurrar aktivt på en av sina egna processorer. Synkroniseringsförfrågningar är snabba men svarstiden är densamma som det kopplade systemets snurrande CPU-förlust. Så synkroniseringsförfrågningar är relativt dyra i CPU-termer – ur det kopplade systemets perspektiv.
• Asynkrona (asynkrona) förfrågningar. När ett z/OS- system utfärdar en begäran väntar det inte på att begäran ska slutföras. Asynkroniseringsbegäranden är långsammare än synkroniseringsbegäranden (eftersom de har lägre prioritet i CF) men leder inte till att det kopplade systemets processor snurrar.

Att utnyttja z/OS-applikationer utfärdar uttryckligen CF-förfrågningar som synkronisering eller asynkron.

Dynamisk begäran om konvertering

I z/OS Release 2 introducerades den heuristiska algoritmen för Dynamic Request Conversion. Detta använder samplade svarstider för att bestämma om synkroniseringsförfrågningar ska konverteras till Async eller inte. Dessa beslut baseras på sådana kriterier som kopplad processorhastighet. Ju större avståndet är mellan det kopplade z/OS- systemet och CF, desto större sannolikhet kommer förfrågningar att konverteras till Async från Sync.

Asynkroniseringsförfrågningar konverteras aldrig till Sync.

Denna heuristiska algoritm kompletterar en tidigare existerande algoritm som automatiskt (men inte heuristiskt) konverterade förfrågningar, baserat på förhållanden som sökväg upptagen och datastorlek på begäran. Skillnaden är att den nya algoritmen samplar svarstider dynamiskt.

CF:er är unika för S/390, zSeries och System z stordatorer. De är nyckeln till Parallel Sysplex-teknik.

Koppla anläggningsnivåer och utnyttja mjukvarunivåer

CFCC-koden släpps som nivåer, vanligtvis betecknade med deras CFLEVEL. Till exempel tillkännagavs CFLEVEL 15 i april 2007. Varje nivå ger ny funktion och ibland förbättrad prestanda. I de flesta fall kräver den nya funktionen eller prestandaförbättringen en nödvändig version av z/OS och kanske ny funktion i något delsystem (som Db2 ). Ett sådant exempel är Coupling Facility Structure Duplexing. (Ibland är stöd från operativsystemet och undersystemen tillgängligt via PTF:er snarare än en fullständig version.)