Proserveshowcase

Hoe bouw je een schaalbare en veilige website? #2

In de eerste blog over de nieuwe Proserve-website gingen we in op de opbouw van de website conform drie gestelde requirements. In deze tweede beschrijven we hoe we de continuïteit van de website borgen. Op basis van vier additionele requirements zijn wijzigingen in de architectuur doorgevoerd die zorgen voor de gewenste continuïteit.

Requirement 4: Draag zorg voor een hoog beschikbare omgeving.

De nieuwe Proserve-website is enkelvoudig uitgevoerd. Hoewel de onderliggende infrastructuur hoog beschikbaar is, is de Drupal-omgeving dat niet. Een issue in de software of het besturingssysteem kan dus leiden tot het uitvallen van een component. En de uitval van een enkel component kan leiden tot het uitvallen van de volledige omgeving. Dit maakt de omgeving kwetsbaar.

Het inbouwen van redundantie is de oplossing voor dit probleem. Door te zorgen dat elk component dubbel is uitgevoerd, kan er een component uitvallen zonder dat dit de dienstverlening verstoort. Een ander belangrijk voordeel van redundantie is dat het onderhoud zonder downtime mogelijk maakt. Niet alleen is dit goed voor de continuïteit van de dienstverlening, maar ook voor de kosten. Op deze manier is immers onderhoud binnen kantooruren mogelijk.

Redundantie stopt niet bij enkel het dubbel uitvoeren. De applicatie moet ook om kunnen gaan met meerdere instanties. MySQL heeft een dergelijke functionaliteit ingebouwd. Door de databases in master-master-opstelling te plaatsen, worden beide databases qua inhoud gelijk gehouden.

De firewall ondersteunt ook native high-availability. Eén node wordt actief gebruikt, de andere staat stand-by en neemt zonder downtime de diensten over als de eerste firewall niet langer functioneert.

Webservices ondersteunen zelf geen redundantie. Verkeer naar een IP-adres komt uit op een webserver. Om meerdere webservers te kunnen gebruiken (horizontale schaalbaarheid) is een loadbalancer nodig. In deze opstelling zijn we uitgegaan van keepalived loadbalancers. We kiezen altijd voor een loadbalancingcluster, omdat je met één loadbalancer alleen het Single Point of Failure verplaatst.

Requirement 5: Draag zorg voor een RTO van zes uur en een RPO van 24 uur.

De omgeving is hoogbeschikbaar gemaakt, maar een calamiteit kan altijd plaatsvinden. Denk bijvoorbeeld aan datacorruptie. Om te voorkomen dat data verloren gaat, maken we dagelijks een back-up van alle (volledige) virtuele machines. Een restore van een virtuele machine, inclusief inhoud, is daardoor uit te voeren met maximaal een dag aan dataverlies. Hiermee voldoen we aan de RPO-vereisten.

Onze Cloud server back up maakt een veiligheidskopie van de volledige virtuele machine. Bij een restore kan deze direct gestart worden vanuit deze kopie. De hersteltijd is zo erg laag en hangt alleen af van het moment waarop de restore gestart wordt. De SLA is daarom leidend. Met de Business SLA welke 24x7 support met gegarandeerde responsetijden biedt, gekoppeld aan de Veeam-back-ups, behalen we de RTO van zes uur.

Voor een database is het van belang dat deze in zijn geheel wordt geback-upt zonder dat er wijzigingen aangebracht zijn gedurende de back-up. De server moet daarom, zij het voor een zeer beperkte tijd, ‘bevroren’ worden. Om dit uit te kunnen voeren, is een agent in de virtuele server nodig. Proserve heeft gekozen voor de Enterprise DB back up om back-ups te maken van de databases. Hiermee zorgen we voor consistente back-ups die eenvoudig teruggezet kunnen worden.

Requirement 6: Draag zorg voor een disaster recovery-mogelijkheid.

Bij disaster recovery is het altijd van belang te bepalen tegen welk type ‘ramp’ je beschermd wil zijn. In dit geval is dat het uitvallen van een volledig datacenter. Zoals hiervoor beschreven, is de data al in een ander datacenter veiliggesteld door de back-up. Als we deze back-up nodig hebben, dan zijn resources nodig.

Bij Proserve bestaat de mogelijkheid om stand-by resources af te nemen tegen een gereduceerd tarief. Hiervoor wordt CPU, memory en diskcapaciteit in een ander datacenter gereserveerd, mocht er sprake zijn van een calamiteit. We kozen ervoor om slechts voor de minimale configuratie resources te reserveren, om zodoende de kosten te drukken.

Via een transitnetwerk kunnen we het externe IP-adres van de website routeren naar een ander datacenter. We plaatsten een additionele firewall die voorgeconfigureerd werd om het verkeer af te leveren bij de webserver die hersteld kan worden. Dat voorkomt handmatige herconfiguratie in het geval van een calamiteit en zorgt er daarmee voor dat de website sneller weer beschikbaar is.

Requirement 7: De RPO mag maximaal 2,5 uur zijn.

De website is actief gemaakt over twee datacenters heen. Dit is mogelijk doordat Proserve loadbalancers heeft in twee datacenters (waarvan er één datacenter niet hetzelfde datacenter is als waar de servers staan) die we in kunnen zetten voor onze diensten. Daarmee is het mogelijk om het webverkeer te spreiden over twee datacenters. Voor de firewalls en de MySQL-databases is synchronisatie nodig. Deze synchronisatie kan via een site-to-site VPN (geconfigureerd op de firewalls) of via een intern VLAN verlopen. Wij kozen voor dit laatste om garanties op het gebied van latency te kunnen bieden.

Naast de technische wijzigingen is ook gekozen voor de hoogste SLA – Continuity Critical, wat de benodigde responsetijden biedt om de vereiste RTO te realiseren.

Hiermee is de omgeving redundant uitgevoerd, gespreid over twee datacenters, beveiligd tegen externe dreigingen en voorzien van de benodigde dienstverlening. Daarmee gaven we invulling aan alle gestelde requirements. Niet iedere website heeft de features nodig als hierboven beschreven. Dat geldt ook voor onze eigen website. We kozen echter voor deze aanpak om te laten zien hoe requirements invloed hebben op het design van een omgeving en hoe wij vervolgens samen met klanten een passende oplossing zoeken waarbij requirements, techniek en financiën hand in hand gaan.

Architectuur van de eindsituatie.