Waar een website draait

Geschreven voor: Beheerder

Een CoreCP-website staat niet op "een server". Hij heeft vijf diensten — zijn webserver, zijn database, zijn mailopslag, zijn nameservers en zijn back-updoel — en elk daarvan wordt afzonderlijk op een machine geplaatst. Meestal komen alle vijf op dezelfde machine terecht en denk je er nooit over na. Deze pagina gaat over de keren dat je dat wél doet.

Alleen beheerders zien dit. Resellers en eindgebruikers zien nooit, en hoeven nooit te zien, welke machine hen bedient. Dat is bewust: welke klant op welke machine staat, is een plattegrond van het platform.

Een plaatsing bekijken

Paneel — open een hostingaccount en ga naar Plaatsing. Je ziet één regel per dienst: de rol, de machine, en of die actief is, wordt ingericht, of aan het verhuizen is.

Shell — hetzelfde antwoord:

corecp-panel bindings list --account demo --config /etc/corecp-panel/panel.yaml

ACCOUNT  WEBSITE            ROLE  NODE               STATE   SINCE
demo     (account default)  web   stck1.corecp.dev   active  2026-08-08 21:07
demo     (account default)  db    stck1.corecp.dev   active  2026-08-08 21:07
demo     shop.example.com   web   stck2.corecp.dev   active  2026-08-08 21:12

(account default) is het antwoord voor elke website van dat account die geen eigen regel heeft. shop.example.com heeft er wel één, dus zijn webserver staat op de andere machine — de rest van die website volgt nog steeds het account.

Hoe een nieuw account geplaatst wordt

Heeft de website een eigen plaatsing voor die dienst? Die wint.
Zo niet: de standaardplaatsing van het account.
Zo niet: het beleid van de plaatsingspool waarin het pakket van de klant inplant.

Er zijn drie beleidsvormen. Minste websites is de standaard en degene om aan te houden zolang je groeit: het is het getal dat het paneel exact kent, en het is het getal dat volgend jaar voorspelt. Laagste belasting rangschikt op de laatste meting van de machines, en een machine zónder recente meting komt ná elke gemeten machine — "we weten het niet" hoort niet te winnen van "we hebben 0,2 gemeten". Willekeurig bestaat voor het geval je geen enkel verband wilt tussen de volgorde waarin klanten binnenkomen en waar ze landen.

Je kunt altijd eerst vragen:

corecp-panel bindings plan --account demo --roles web,db --config …

ROLE  NODE              SOURCE  WHY
web   stck2.corecp.dev  policy  fewest websites (14) in server group eu-west
db    stck2.corecp.dev  policy  fewest websites (14) in server group eu-west

Dit verandert niets. Het antwoord noemt óók elke machine die is overwogen en waarom die afviel, zodat "waarom niet stck3" te beantwoorden is zonder te gokken.

Plaatsingspools

Een pool is de verzameling machines waarop een pakket mag inplannen — een locatie, een tier, een generatie hardware. Het is niet hetzelfde als een node-groep: een node-groep bepaalt wie een machine mag zien, een pool bepaalt wat erop landt.

corecp-panel bindings groups create eu-west --org corecp --strategy least_websites
corecp-panel bindings groups list --config …

Wil je een machine langzaam leegmaken, zet hem dan op draining. Alles wat er staat blijft bediend; er komt niets nieuws bij.

corecp-panel bindings groups set eu-west --draining --config …

Een pool waar nog een pakket naar wijst, kun je niet verwijderen — en de weigering noemt de pakketten:

2 package(s) still schedule into this server group (Basic, Pro) — point them
somewhere else first; deleting it would leave provisioning with nowhere to place

De regels die het paneel niet laat overtreden

Het weigert wanneer	Omdat
de machine die rol niet draagt	de plaatsing zou perfect kloppen en de site zou niets serveren
een nameserver-set minder dan twee machines zou hebben	één gepubliceerde NS ziet er gezond uit tot die machine herstart
een back-up op de machine met de data zou komen	een kopie op dezelfde schijf is geen back-up
je een rol weghaalt die een machine nog bedient	verhuis de klanten er eerst af
je een pool verwijdert die een pakket nog gebruikt	provisioning zou later stilletjes stukgaan

En twee dingen waarvoor het waarschuwt in plaats van weigert, omdat het afwegingen zijn en geen fouten:

Webserver en database op verschillende machines, met een traag pad ertussen. Elke query op elke pagina betaalt dat getal. Het paneel meet het vanaf de machine zelf — niet vanaf het paneel, want dan meet je iets heel anders — en waarschuwt boven ongeveer 2 ms.
Een mailmachine zonder reverse-naam bij zijn adres. Grote providers filteren post van zulke adressen weg.

Web en database samen is de standaard; splitsen is een besluit, geen upgrade.

Eén machine, meerdere resellers

Een machine hoort bij één nodegroep. Een klant hoort bij een realm — het root-realm, of dat van een reseller. Dat zijn twee verschillende dingen, en ze hoeven niet gelijk te zijn: dat is precies wat gedeelde hosting is. stck1 kan in de root-groep staan en tegelijk de klanten van drie resellers bedienen.

Dat werkte een tijd niet. De machine telde mee als derde eigendomsvraag bij élke accountgebonden aanroep — mail, DNS, FTP, bestanden, back-ups, WordPress — dus zodra een klant in het realm van een reseller zat, kreeg zij 403 node_out_of_scope op haar eigen website. Eén machine kon daardoor precies één realm bedienen. Sinds 10 augustus 2026 is plaatsing weer wat het hoort te zijn: een beheerdersvraag.

Wie	Wordt beoordeeld op de machine?
beheerder, serverbeheerder	ja — een machine buiten je toewijzing is buiten je bevoegdheid
reseller	alleen bij het aanmaken van een account: waar landt het nieuwe account?
eindgebruiker	nooit

Er is niets ruimer geworden. Wie je bereikt, is nog steeds bepaald door het account zelf: het moet in jouw realm staan én van jou of van een klant van jou zijn. Wat verdween is een vraag die resellers en eindgebruikers nooit hadden mogen krijgen, omdat ze het antwoord toch niet te zien krijgen (zie het kader bovenaan deze pagina).

Paneel — Fleet → machines toont de groep van een machine; Klanten toont het realm van een klant. Ze staan bewust niet op hetzelfde scherm, want het zijn niet dezelfde vraag.

Shell — op de paneelmachine, rechtstreeks uit de database, omdat er geen scherm is dat de twee naast elkaar zet:

ssh root@panel1.corecp.dev sudo -u postgres psql -d corecp_panel -c \
  "SELECT n.fqdn, o.name AS node_group FROM node n
     JOIN organization o ON o.id = n.organization_id ORDER BY n.fqdn"

       fqdn       | node_group
------------------+------------
 stck1.corecp.dev | CoreCP

ssh root@panel1.corecp.dev sudo -u postgres psql -d corecp_panel -c \
  "SELECT a.username, o.name AS realm, p.email AS owner
     FROM account a JOIN node n ON n.id = a.node_id
     LEFT JOIN organization o ON o.id = a.organization_id
     LEFT JOIN panel_user p ON p.id = a.owner_user_id
    WHERE n.fqdn = 'stck1.corecp.dev'
      AND a.username IN ('demo','test200','test300') ORDER BY a.username"

 username |      realm       |      owner
----------+------------------+------------------
 demo     | Reseller Test BV | owner@test100.nl
 test200  | Reseller Test BV | owner@test200.nl
 test300  | CoreCP           | owner@test300.nl

Drie accounts, één machine, twee realms. Zo hoort het eruit te zien — en dat is precies wat de testset van scripts/seed-fixtures.sh neerzet, zie De testset gebruiken.

Eén dienst naar een andere machine verhuizen

Verhuizen kopieert klantdata en verandert wat een website beantwoordt, dus je moet het expliciet bevestigen.

corecp-panel bindings move <binding-id> --to stck2.corecp.dev --confirm --wait 600

Je ziet elke stap:

move 1091ad55-… — web of shop.example.com for demo
  stck1.corecp.dev → stck2.corecp.dev, done
  STEP               STATE  DETAIL
  preflight          done   stck2.corecp.dev carries the web role and answers
  account_on_target  done   created demo on stck2.corecp.dev
  export_source      done   demo-web-20260808T210709Z.tar
  transfer           done   4823040 bytes to stck2.corecp.dev
  import_target      done   imported on stck2.corecp.dev
  verify_target      done   stck2.corecp.dev answered 200 for shop.example.com
  cutover            done   2 address record(s) now point at stck2.corecp.dev
  activate           done   stck2.corecp.dev now serves the web role
  drain_source       done   stck1.corecp.dev no longer serves shop.example.com; …
  cleanup            done   staged archives removed

verify_target haalt de site op bij de nieuwe machine, op zijn eigen naam, voordat er iets omgezet wordt. Kan die machine hem niet serveren, dan stopt de verhuizing daar en merkt de klant er niets van.

Als hij halverwege stopt

Er gaat niets verloren en er zit niets vast. De oude machine bleef bedienen tot cutover, en de binding staat weer op active waar hij stond. Kijk naar de stap die faalde, los op wat die noemt, en ga verder:

corecp-panel bindings moves --state failed --config …
corecp-panel bindings resume <move-id> --wait 600 --config …

Hervatten, niet opnieuw proberen. Hij gaat verder bij de eerste stap die niet af is; het werk dat al gedaan is, wordt niet nog eens gedaan.

Een mailverhuizing wacht met opzet

Een mailverhuizing eindigt in paused, niet in done. Post die de oude machine al aangenomen heeft, staat op de oude machine, en elke mailserver ter wereld houdt het oude MX-record vast tot zijn TTL verlopen is. Daarom blijft de oude mailopslag vier uur leesbaar en staat de binding op draining. Hervat de verhuizing daarna en de oude sessies worden beëindigd.

paused betekent hier wachtend, zoals bedoeld. Het is geen storing.

Wat een verhuizing nooit doet

Nooit een zone herschrijven die iemand anders host. Hosten wij de DNS niet, dan vertelt de verhuizing welk record je moet aanpassen en blijft de oude machine bedienen tot je dat doet.
Nooit configuratiebestanden van je klanten bewerken. Betekent het splitsen van web en database dat DB_HOST in wp-config.php moet veranderen, dan zégt de verhuizing dat en laat hij het bestand met rust.
Nooit iets weggooien dat van een klant is. De oude machine stopt met het serveren van de site; de bestanden blijven staan, en de stap noemt het commando waarmee je ze weghaalt.

Het pad tussen twee machines meten

corecp-panel bindings rtt stck1.corecp.dev stck2.corecp.dev --config …

stck1.corecp.dev → stck2.corecp.dev: 0.31 ms over 5 samples

Gemeten door de agent op de eerste machine, die verbinding maakt met de tweede — niet vanaf het paneel, dat twintig milliseconden van beide vandaan kan staan en je dan niets vertelt over het pad ertussen. Standaard poort 22, tenzij je met --port een andere noemt; de eigen poort van de agents staat bewust alleen open voor het paneel, dus die timen betekent een firewall timen.

De assistent vragen

De assistent kan beantwoorden "op welke machine staat de site van deze klant" en "welke verhuizingen lopen er". Hij kan een verhuizing niet starten, hervatten of annuleren — dat is een beheerdershandeling met een bevestiging, en niet iets om tussen twee zinnen van een gesprek te doen.