Exemplaren, overname en dienstniveaus

Een database bij ontwikkelen en beproeven heeft één exemplaar. Een database in reguliere productie heeft drie exemplaren op drie verschillende werkers (podAntiAffinityType required), met een apart volume voor het transactielogboek en automatische overname binnen het cluster. Dat vraagt ten minste drie werkers en drie keer de opslag.

Er is één schrijvend exemplaar. De andere exemplaren volgen met asynchrone streaming replicatie, met de certificaten van de beheerfunctie; archive_timeout van 5 minuten begrenst het herstelpunt ook bij verlies van alle exemplaren. Het verlies bij overname is het niet gerepliceerde deel: een aanvaard restrisico, gemeten en begrensd door de melding bij 60 seconden replicatievertraging.

Valt in reguliere productie het schrijvende exemplaar uit, dan neemt de meest bijgewerkte replica automatisch over en schrijft het oude exemplaar niet meer, ook niet na een netwerkscheiding. De dienst voor de schrijvende kant volgt het nieuwe schrijvende exemplaar, en het oude komt terug als replica.

Een database in bedrijfskritische productie krijgt daarnaast een replicacluster van CloudNativePG in de andere cel. Replicatie naar de andere cel bestaat alleen daarvoor, over een gedeclareerde verbinding: een eigen virtueel adres op de verkeersverdeling van de cel met het schrijvende exemplaar geeft TCP 5432 door naar het databaseadres, en TLS eindigt bij de database. Overname gaat volgens het draaiboek, na uitsluiting.

De herstelafspraak voor bedrijfskritische productie volgt de bedrijfsimpactanalyse; de normen van reguliere productie gelden daar niet vanzelf. De dienstbeschrijving legt per dienst schrijfautoriteit, herstelpunt en hersteltijd vast. De reactie op een melding is dan binnen 30 minuten, 24 uur per dag en 7 dagen per week, en het herstel begint binnen 1 uur.

De volumes gebruiken de opslagklasse normaal-blok (prestatielaag ‘normaal’) uit de rechtstreekse koppeling van het applicatiecluster met het opslagcluster, als ReadWriteOnce op RBD. In reguliere productie heeft iedere database daarnaast een apart volume voor het transactielogboek (walStorage). De exemplaren delen het opslagcluster; de scheiding tussen hen loopt via de werkers.

De database erft de foutdomeinen eronder: drie kopieën in drie rekken op het opslagcluster, werkers die over werkerknooppunten en rekken zijn gespreid, en de gehoste besturing op het clusterbeheer. Drie PostgreSQL-exemplaren beschermen dus niet tegen verlies van het opslagcluster of van de hele cel.

Per onderdeel liggen de plaatsing, het gedrag bij uitval en het herstel van de database vast.

Een database start zodra applicatiecluster, opslagkoppeling en beheerfunctie werken; het geheimenbeheer is pas nodig voor de toepassingen. Bij herstel van een cel is de volgorde binnen de dienst: applicatiecluster, beheerfunctie en beeldcatalogus, de database uit haar volumes of de back-up, certificaat, adres en naam, verbinding met het geheimenbeheer, en daarna de toepassingen. Na herstel uit een back-up krijgt het beheeraccount een nieuw wachtwoord en worden alle leases ingetrokken.

De dienstniveaus van de beheerde database per profiel. In reguliere productie is de overname binnen 2 minuten en de overschakeling bij onderhoud binnen 1 minuut; er is geen percentagenorm, wel een maandelijkse meting van de beschikbaarheid van de schrijvende kant, zoals per cluster. De normen gelden voor het platform en zijn toetsbaar in de uitvalproef; de dienstafspraak voor de volledige toepassing volgt uit de bedrijfsimpactanalyse.

In reguliere productie wacht een melding buiten kantoortijd tot kantoortijd. Dat is een aanvaard restrisico, begrensd door de automatische overname met uitsluiting; wie meer vraagt, kiest bedrijfskritische productie.

Een database is in de eerste levering ten hoogste 100 GB, omdat de hersteltijdnorm tot die grootte geldt; groter kan alleen als de dienstbeschrijving een gemeten hersteltijd noemt. De beleidstoetsing controleert de grens.

In het quotum van het team tellen per exemplaar processor, geheugen en datavolume, in reguliere productie ook het logboekvolume, plus één herstelexemplaar ter grootte van de grootste database van het cluster, zodat herstel niet op capaciteit wacht. Het gebruik wordt per database gerapporteerd. De volumes tellen mee in de uitgegeven quota van het opslagcluster, die samen onder 75 procent van de bruikbare capaciteit blijven.

Database-exemplaren draaien met het striktste beveiligingsprofiel en met limieten voor processor en geheugen; in reguliere productie zijn de requests gelijk aan de limieten. Dat geeft scheiding en voorspelbare prestaties.

De dienst groeit met de applicatieclusters. De grenzen zijn de capaciteit van werkervirtualisatie en opslagcluster, en de /26 van het cluster, die werkers, ingangsadres en databaseadressen delen. De groeiroute voor een zware schrijfbelasting is de prestatielaag ‘snel’, als werklastklasse met eigen capaciteitsbeleid.