Levenscyclus van een applicatiecluster

Een applicatiecluster gaat in vijf stappen in gebruik. Een status Available bewijst niet dat toegang, opslag, isolatie en herstel werkelijk werken; daarom geeft de acceptatie het team pas toegang na positieve en negatieve proeven en een werkende noodroute.

Een cluster wordt pas opgeleverd als alle beleidspakketten voldoen, de beveiligingsvoorzieningen zijn aangesloten en de proef langs het gebruikerspad slaagt. Een onvolledige levering wordt hervat vanaf de mislukte stap, zonder dubbele onderdelen.

De acceptatie van clusters als dienst gebruikt de testtoepassing van het eerste applicatieteam en toont aan: een levering zonder handmatige stap, met de levertijd tegen de nulmeting en een normtijd van 4 uur; een update zonder onderbreking van een toepassing met twee exemplaren, gemeten op fouten en antwoordtijd; dat het team de standaardinrichting niet kan wijzigen en geen naamruimte kan aanmaken; weigering en melding van een niet-gedeclareerde verbinding, van een teambeleid dat alles toestaat, van uitgaand verkeer naar een niet-toegestane bestemming en van een werker van een ander cluster; dat een naamruimte de geheimen van een andere niet ophaalt en een cluster geen certificaat voor een ander krijgt; weigering van niet-ondertekende software, ook in een naamruimte zonder label; de rechten en de noodtoegang per profiel; en herbouw en beëindiging zonder restanten.

Capaciteit en naamruimten wijzigen via een wijzigingsvoorstel op de dienstbeschrijving, zonder nieuwe aanvraag per beheerdomein. Uitbreiden is een standaardwijziging; verkleinen van werkers of opslag gebeurt binnen het onderhoudsvenster en pas na controle dat de resterende capaciteit volstaat.

De onderdelen van de standaardinrichting komen uit de gecontroleerde spiegel, met handmatige goedkeuring van installatieplannen; de beheerfunctie van de beheerde database komt via de toelatingsroute. De softwarestapel van een applicatiecluster staat in de tabel.

Productfuncties van de dienst clusters als dienst waarvan de ondersteuning niet vastligt, zijn acceptatiecriteria, elk met een terugvaloptie.

Clusterbeheer, multicluster engine, werkervirtualisatie en gastclusters draaien alleen in door de leverancier ondersteunde combinaties, ook tijdens een upgrade; een andere versie wordt niet vrijgegeven. Een gastcluster krijgt nooit een hogere minorversie dan het clusterbeheer en de werkervirtualisatie, en een overgang begint ten minste drie maanden vóór het einde van de ondersteuning.

Een platformversie gaat eerst naar de leeromgeving en dan per cel naar het vlootcluster (multicluster engine en vlootbeheer), het basisdienstencluster, het clusterbeheer (eerst de multicluster engine, dan OpenShift), de werkervirtualisatie en ten slotte de gehoste clusters per uitrolgolf: de proefgroep, golf 1 en golf 2, ieder in zijn onderhoudsvenster. Het opslagcluster volgt zijn eigen ritme. Een gehost cluster volgt pas als de multicluster engine zijn nieuwe versie ondersteunt; het vlootbeheer werkt dan besturing en werkers bij, en daarna de operators van de standaardinrichting.

Een update gaat na de leeromgeving eerst naar de proefgroep of, voor het clusterbeheer, naar cel 1, en pas na ten minste 5 werkdagen per uitrolgolf verder of naar cel 2; alleen de spoedroute wijkt daarvan af. Een cluster wordt alleen bijgewerkt naar vrijgegeven versies, in zijn onderhoudsvenster, en ten minste ieder half jaar.

Updates van besturing en werkers gebeuren in vaste wekelijkse vensters van 4 uur op werkdagen; de tijden staan in de opslagplaats Catalogus en het team kiest een venster uit het aanbod. De clusters van één dienst in bedrijfskritische productie hebben hun vensters per cel op verschillende dagen. Een update wacht zo ten hoogste 7 dagen.

Bij een update wordt eerst de besturing bijgewerkt en worden daarna de werkers één voor één vervangen, niet ter plekke bijgewerkt: er komt eerst één nieuwe werker bij, daarna verdwijnt een oude. Een update van de besturing wordt niet teruggedraaid, maar bij problemen met de procedure van de leverancier voltooid of hersteld; werkers worden pas vervangen als de besturing op de nieuwe versie gezond is. Is een nieuwe werker na 20 minuten niet gezond, dan stopt de vervanging.

In reguliere en bedrijfskritische productie heeft iedere toepassing ten minste twee exemplaren op verschillende werkers en een PodDisruptionBudget, zodat onderhoud geen onderbreking geeft. Een update van besturing en werkers verloopt zonder onderbreking van zo’n toepassing, gemeten op fouten en antwoordtijd gedurende de hele update.

Bij beëindiging maakt het platform een laatste back-up en verwijdert het de koppelingen, de volumes, de opslagkoppeling en de definitie; identiteiten, rollen en geheimen worden ingetrokken. Daarna verwijst geen inventaris meer naar het cluster en staat er op de werkervirtualisatie geen object van het cluster meer. Back-ups volgen hun bewaartermijn, en de sleutel voor de clustergegevens blijft bewaard tot de back-ups weg zijn.

Er is geen percentagenorm voor de beschikbaarheid. Per profiel ligt vast wat het platform levert (reactie, hersteldoelen en bij bedrijfskritische productie overname) en wat het meet: de beschikbaarheid van API en applicatie-ingang per cluster per maand. De grens voor onderbreking en gegevensverlies per toepassing komt uit de bedrijfsimpactanalyse.

Het clusterbeheer groeit in de fasen van de tabel, van de leeromgeving tot de gespecialiseerde diensten.

De dienst clusters als dienst groeit in de fasen van de tabel.

Platformbeheer is eindverantwoordelijk voor de dienst; tot de overdracht bouwt het ontwikkelteam sjabloon, standaardinrichting en draaiboeken. Het applicatieteam is eigenaar van toepassingen, gegevens, dienstbeschrijving en opslagplaats. Netwerk, opslag, identiteiten en PKI blijven bij hun beheerdomein; het platform vraagt ze aan via de automatisering, niet per ticket. Vóór productie heeft de dienst een vastgelegde taakverdeling, een dreigingsmodel en beproefde draaiboeken, en platformbeheer werkt het ontwerp per cel uit in een detailontwerp.

Voor het applicatiecluster bestaan de draaiboeken in de tabel, grotendeels geautomatiseerd en in de opslagplaats Draaiboeken. Vóór de overdracht voeren de beheerders ze aantoonbaar zelf uit.