Tag: Database

Applicatie geschikt maken voor Secure Webhosting

Secure Webhosting heeft zogenoemde profielen ontwikkeld om de hostingomgeving af te stemmen op een bepaald type applicatie. Profielen zijn in essentie sjablonen voor onder meer omgevings- en veiligheidsinstellingen, het aantal webservers, de hoeveelheid werkgeheugen en het aantal CPU’s.

Als onderdeel van de veiligheidsinstellingen zijn er per profiel bepaalde URL’s benoemd als restricted. Toegang tot deze URL’s is enkel mogelijk voor bevoegde gebruikers. U kunt hierbij denken aan een URL voor het inloggen op de beheeromgeving van een applicatie.

De huidige profielen:

  • WordPress Single site
  • WordPress Multisite (MU)
  • Magento 2
  • Laravel
  • PHP Generic*

* Algemeen toepasbaar profiel voor PHP maatwerk applicaties

Voor applicaties die tot deze profielen behoren, gelden onderstaande eisen voor het onderbrengen op het platform van Secure Webhosting:

Mediabestanden in bepaalde folder(s)

Onder mediabestanden verstaan wij bestanden die tijdens het gebruik van de applicatie door gebruikers worden ge-upload of door de applicatie zelf worden gedownload vanaf andere systemen (crawlen, synchroniseren, API-calls etc.).

SecWeb bewaart deze bestanden op het mediafile platform en maakt ze als folder(s) beschikbaar voor webservers. Op die manier worden twee belangrijke eigenschappen van mediafiles gerealiseerd:

  • De mediabestanden zijn direct beschikbaar zijn voor alle webservers, dus niet alleen voor de webserver waar de upload / download plaatsvond.
  • Bij een redeployment van een webserver wordt de oude versie van de webserver vernietigd, maar de mediabestanden blijven bestaan.

De mediafile folders op webservers zijn verschillend per profiel:

WordPress: /wp-content/uploads en /wp-content/cache
Magento: /pub/media
Laravel: ‘Storage’ folder
PHP Generic: onderling af te spreken

Belangrijk: De mediafolders moeten door de webdeveloper worden opgenomen in de .gitignore van de git repository van de applicatie, om te voorkomen dat de inhoud in acceptatie en productie wordt overschreven door de inhoud van een developeromgeving bij een redeployment.

Database op platform met dynamische configuratie

De database van de applicatie wordt op een databaseplatform gehost, gescheiden van de webserver. Dat leidt tot een betere spreiding van de serverbelasting (betere performance) en een verbeterde informatieveiligheid. De parameters voor de databaseverbinding worden door SecWeb automatisch ingevuld in het juiste applicatie-configuratiebestand tijdens het (re)deployen van de webserver. De applicatie moet dit ondersteunen.

Voor standaardapplicaties zoals WordPress en Magento hebben wij dit al geregeld. Voor maatwerkapplicaties maken we hierover afspraken.

E-mail via SMTP (Postfix) of Sendmail

Vanuit de applicatie kan er bij voorkeur gebruik worden gemaakt van SMTP (Postfix) met als toegestaan alternatief Sendmail om e-mailberichten te verzenden. Lees het artikel hierover.

Houd er rekening mee dat er enkele DNS records binnen de DNS omgeving van uw domein verplicht aanwezig moeten zijn om de authenticiteit van e-mailberichten te bewijzen. De benodigde records kunt u vinden in het artikel ‘DNS Omgeving‘.

Sessies niet op webserver opslaan

Omdat er op Secure Webhosting gebruik wordt gemaakt van meerdere webservers, kan sessiedata niet op één specifieke webserver worden opgeslagen. Dan kunnen andere webservers namelijk niet bij die sessiedata.

De sessiedata moet namelijk voor alle webservers beschikbaar zijn. Dit kan (bijvoorbeeld) gerealiseerd worden door de informatie van alle sessies in een database op te slaan.

Hierdoor kan de applicatie altijd de juiste sessiedata ophalen, ongeacht de webserver waar de gebruiker belandt.

Master-slave databasereplicatie

Naast het Percona databasecluster met Galera replicatie heeft Secure Webhosting ook een MariaDB Databasecluster, bestaande uit één Master node en één Slave node.

De Master-slave replicatiemethode komt veel voor bij MySQL databases. De methode gaat uit van één Master server (node) die data leest én schrijft, en één of meer Slave servers (nodes) die uitsluitend data lezen. Data van de Master node wordt asynchroon (na voltooiing van een databasetransactie) gerepliceerd naar de Slave nodes, zodat de dataconsistentie hoger is. Vervolgens bevestigen de Slave nodes de verwerking van de gerepliceerde data aan de Master node, voordat de Master node nieuwe data wegschrijft.

Voordelen van Master-slave replicatie t.o.v. Galera replicatie

  1. Breder inzetbaar door minder restricties op de communicatiewijze tussen applicatie en database (zie verderop in dit artikel).
  2. Eenvoudiger en daardoor beter te onderhouden.
  3. Back-ups van een database kunnen worden gemaakt zonder belasting van de Master node.
  4. Er is geen quorum nodig (een minimaal aantal nodes). Master-slave replicatie werkt al met 2 nodes in plaats van minimaal 3 bij Galera replicatie.
  5. Netwerkstoringen hebben vrijwel geen effect op het herstel van een Master-Slave opzet. 

Nadelen van Master-slave replicatie t.o.v. Galera replicatie

  1. Mogelijk dataverlies bij een crash van de Master node, omdat er gebruik wordt gemaakt van een asynchrone replicatiemethode. 
  2. Minder schaalbaar, omdat uitsluitend de leesverzoeken kunnen worden verdeeld over meerdere nodes. Bij Galera replicatie is het mogelijk om lees- en schrijfverzoeken te verdelen.
  3. In het geval van een storing van de Master node moet een Slave node de Master taak overnemen. Dit proces is geautomatiseerd, maar het kost een aantal seconden. In de tussentijd kunnen storingen op de website zichtbaar zijn.
  4. Iedere extra Slave node leidt tot extra belasting van de Master node, omdat de data op de Master node naar iedere Slave node gekopieerd moet worden. 

Waarom maakt Secure Webhosting gebruik van twee typen Databaseclusters?

Percona clustering met Galera replicatie werkt voor sommige applicaties niet naar behoren, vanwege limitaties.

Zogenaamde DDL Statements (CREATE, ALTER en DROP) zorgen namelijk voor een stop in datareplicatie totdat zijn uitgevoerd op de Master node.

Voor veel applicaties is dat geen probleem. Echter is het zo dat (bijvoorbeeld) Magento deze DDL Statements intensief gebruikt. 

Om die reden is er naast het Percona databasecluster ook een MariaDB databasecluster met Master-Slave replicatie beschikbaar.

Percona databasecluster

Het Percona databasecluster wordt bij Secure Webhosting ingezet om de betrouwbaarheid en beschikbaarheid te verhogen. Het zorgt ervoor dat de database(s) van uw applicatie gespiegeld wordt over meerdere databaseservers. 

Wat is een Percona databasecluster?

Percona XtraDB Cluster is een open-source toepassing voor MySQL. Een cluster bestaat uit ‘nodes’ (servers), waar iedere node dezelfde set aan data bevat. Deze data wordt over de nodes gesynchroniseerd.

Wat zijn de voordelen?

  • Belasting wordt over de servers verdeeld door middel van load balancing. Beschikbaarheid en onderhoudbaarheid zijn hierdoor hoger. 
  • Geen dataverlies bij wegvallen van een databaseserver. Wanneer een server niet bereikbaar is, nemen andere servers het over. De data blijft over alle servers gesynchroniseerd. 
  • Dataconsistentie tussen nodes is hoog, omdat er gebruik wordt gemaakt van semi-synchrone replicatie van data. Wanneer een ‘master’ node een transactie verwerkt, wacht deze met het verwerken van een volgende transactie totdat de master een signaal van de volgende node ontvangt waaruit blijkt dat deze node diezelfde transactie ook verwerkt heeft (en dus over dezelfde data beschikt).

Zijn er limitaties?

  • Datareplicatie werkt alleen met de InnoDB storage engine en (bijvoorbeeld) niet met MyISAM.
  • De datadoorvoer van een cluster wordt gelimiteerd door de zwakste node. Wanneer er één node (om wat voor reden dan ook) vertraagt, vertraagt het gehele cluster. 

Meer informatie over de limitaties is in dit artikel te vinden op de site van MariaDB.