Chapitre 1.3 — Anatomie d’un VPS

⏱️ TL;DR — Un VPS, c’est une part d’une grosse machine physique découpée par un hyperviseur en machines virtuelles isolées. Chacune a ses ressources : des vCPU (cœurs de calcul), de la RAM (mémoire vive de travail), un disque (SSD/NVMe, stockage persistant), une IP publique (son adresse sur Internet), de la bande passante (débit) et une distribution Linux (le système). Comprendre à quoi sert chaque ressource, c’est savoir dimensionner sans surpayer ni étouffer son app, et diagnostiquer quand ça coince (« c’est le CPU, la RAM ou le disque ? »).

🎯 Objectifs

• Expliquer ce qu’est un VPS et le rôle de la virtualisation.
• Nommer et comprendre chaque ressource : vCPU, RAM, disque, IP, bande passante.
• Savoir quelle ressource limite quel type de charge.
• Poser les bases pour dimensionner (chapitre suivant) et diagnostiquer (Partie 14).

D’où vient un VPS ? La virtualisation

Dans un datacenter, le fournisseur possède des serveurs physiques très puissants. Plutôt que de te louer une machine entière (cher, souvent surdimensionné), il la découpe en plusieurs machines virtuelles grâce à un hyperviseur (KVM le plus souvent). Chaque VM — ton VPS — croit être une machine complète et isolée : elle a son propre système, ses processus, son réseau, et ne voit pas ses voisines.

L’isolation est la clé : contrairement au mutualisé (où tu partages un OS avec les voisins), ton VPS a son propre noyau et son propre système. Ce qui se passe chez le voisin ne casse pas ton système. Les ressources, elles, sont allouées (parfois partagées) : c’est ce qu’on détaille.

Les ressources, une par une

Le vCPU — la puissance de calcul

Le processeur exécute les instructions. Sur un VPS, on parle de vCPU (virtual CPU) : des cœurs attribués à ta VM. Plus tu as de vCPU, plus tu peux faire de calcul en parallèle (répondre à plusieurs requêtes, builder, compresser, chiffrer).

• Ce qui consomme du CPU : le rendu SSR, le build (next build), le traitement d’images, le chiffrement TLS, la compression, les calculs applicatifs.
• Symptôme de manque : le load average grimpe, les réponses ralentissent, le build traîne. (On mesure ça en Partie 14.)
• Distinction utile : vCPU dédié (garantis pour toi) vs partagé/burst (bon marché, mais performance variable si les voisins sont gourmands).

La RAM — la mémoire de travail

La mémoire vive est l’espace temporaire et rapide où vivent les programmes en cours d’exécution. Ton app Node, la base de données, Nginx : tout ce qui tourne occupe de la RAM.

• Ce qui consomme de la RAM : chaque processus Node (Next.js peut être gourmand), une base de données (Postgres met en cache en RAM), les caches applicatifs, chaque connexion.
• Symptôme de manque : c’est le plus brutal. Quand la RAM est pleine, le noyau Linux invoque l’OOM killer (Out Of Memory) qui tue un processus pour survivre — souvent le tien. L’app disparaît sans crier gare. (Runbook « OOM » en Partie 16.)
• Filet de sécurité : le swap (voir plus bas), qui déborde sur le disque — utile mais lent.

Le disque — le stockage persistant

Le disque garde les données même éteint : ton code, la base de données, les fichiers uploadés, les logs, le système. Aujourd’hui, c’est du SSD ou du NVMe (bien plus rapide qu’un vieux disque mécanique).

• Deux dimensions comptent : la capacité (combien de Go) et la vitesse d’entrées/sorties (les IOPS : à quelle vitesse on lit/écrit).
• Ce qui consomme du disque : la base qui grandit, les logs qui s’accumulent (piège classique : un disque qui se remplit silencieusement de logs jusqu’à la panne), les uploads, les images Docker, les sauvegardes locales.
• Symptôme de manque : disque plein = pannes en cascade (la base ne peut plus écrire, les logs non plus, l’app tombe). On surveille avec df -h. (Runbook « disk full » en Partie 16.)

L’IP publique — l’adresse sur Internet

Ton VPS a une (ou plusieurs) adresse IP publique : son numéro de téléphone sur Internet. C’est vers elle que le DNS fera pointer ton nom de domaine (Partie 6).

• IPv4 (ex. 203.0.113.10) : la classique, en pénurie, parfois facturée en supplément.
• IPv6 (ex. 2001:db8::1) : la nouvelle génération, abondante ; à activer aussi.
• Une IP fixe est indispensable en prod : elle ne change pas, le DNS peut donc pointer dessus durablement.

La bande passante — le débit

C’est le débit de données entre ton VPS et Internet, et le volume transféré par mois. Servir des vidéos, des images lourdes ou beaucoup de trafic consomme de la bande passante.

• Beaucoup de fournisseurs offrent un débit correct et un volume généreux (voire « illimité » sous conditions), mais lis les petites lignes (au-delà d’un seuil, le débit peut être bridé).
• Pour du contenu lourd et distribué mondialement, on met souvent un CDN devant le VPS (Partie 15).

La distribution — le système d’exploitation

Enfin, ton VPS fait tourner une distribution Linux que tu choisis à la création : Ubuntu Server LTS ou Debian dans ce cours (voir chapitre 1.4). C’est la couche logicielle sur laquelle tout le reste du cours s’installe.

Le swap : la rallonge (lente) de la RAM

Le swap est un espace sur le disque que Linux utilise comme rallonge de RAM quand la mémoire vive est pleine. Ça évite le crash immédiat (l’OOM killer), mais c’est beaucoup plus lent que la vraie RAM : si ton serveur swappe en permanence, il rame. Le swap est un filet de sécurité, pas une solution au manque de RAM. Sur un petit VPS, en configurer un peu est une bonne idée (Partie 5).

Récapitulatif : quelle ressource pour quel symptôme ?

💡 Réflexe — Quand « le serveur est lent », ne devine pas : identifie la ressource en cause. htop (CPU + RAM), df -h (disque), un coup d’œil au réseau. On ne règle bien un problème de perf qu’après avoir nommé le goulot. C’est le thème de la Partie 14.

⚠️ Piège — Sous-estimer la RAM et surveiller le disque trop tard. Deux pannes de débutant : (1) un petit VPS avec trop peu de RAM, où Postgres + Node + le build se battent pour la mémoire et où l’OOM killer tue l’app ; (2) un disque qui se remplit de logs pendant des semaines jusqu’à saturation, provoquant une panne totale qui semble « sortie de nulle part ». Les deux se préviennent (RAM adaptée + swap, logrotate + monitoring du disque).

🔒 Sécurité — L’isolation du VPS te protège des voisins, mais pas d’Internet. Avoir sa propre machine virtuelle isolée ne veut pas dire qu’elle est sécurisée : elle est exposée telle quelle. L’isolation est fournie par l’hyperviseur ; le durcissement (pare-feu, SSH, MàJ) reste entièrement à ta charge (Partie 5).

🧭 Sur FormaCampus — Pour héberger front Next.js + API Symfony + Postgres, l’équipe raisonne ressource par ressource : le SSR de Next et le rendu PDF nocturne mangent du CPU → prévoir plusieurs vCPU ; Postgres et les process Node aiment la RAM → viser confortable et ajouter un peu de swap ; la base + les uploads de cours + les logs grossissent → un disque avec de la marge et logrotate ; les vidéos de cours pèsent lourd → un CDN devant plutôt que tout servir depuis le VPS. Ils partent sur une taille moyenne, quitte à grossir ensuite (le scaling vertical d’un VPS est simple, voir Partie 15).

✏️ Exercices

Exercice 1 — Associe la panne à la ressource. Pour chaque symptôme, quelle ressource est probablement en cause ? (a) Le site répond mais très lentement pendant un build. (b) L’app Node disparaît soudainement, un message Killed dans les logs. (c) La base refuse d’écrire, « No space left on device ».

Exercice 2 — Explique à un non-technique. En une ou deux phrases chacun, explique la différence entre RAM et disque, puis entre vCPU dédié et vCPU partagé.

🧠 Quiz de révision

Chapitre suivant : Choisir & dimensionner — quel fournisseur, quelle distribution, quelle taille pour ton projet.