Quand un serveur cloud doit laisser place à une machine entière

Ce que le passage règle, et ce qu'il laisse

Une machine à un seul locataire retire le voisin de l'ordonnanceur. Elle ne réécrit pas une requête lente, ne crée pas l'index manquant, et ne raccourcit pas le trajet jusqu'à la salle. Quelques secondes de gêne en haut de l'heure sont ordinaires sur un hôte partagé. Déménager pour cette pointe achète souvent une machine que vous ne remplirez pas. Relevez la pointe métier, intervalle d'une ou dix secondes, sur au moins cinq jours ouvrés. Gardez la sauvegarde de nuit dans un fichier à part. Deux mesures alignées avec le p95 : placez le loyer à côté de la facture cloud. Une seule mesure : augmentez la VM et recommencez la même fenêtre la semaine suivante.

Les noms de facture, les colonnes du suivi

Un serveur cloud est le plus souvent une machine KVM. D'autres locataires sont sur l'hôte. L'invité voit le steal : le vCPU était prêt, ce temps a été donné à quelqu'un d'autre. Le disque est souvent un volume réseau, les IOPS suivent un palier ou un crédit. La mémoire a un plafond. Le balloon peut rendre à l'hôte des pages momentanément libres. Entre serveur dédié et serveur cloud, ces trois colonnes disent s'il y a quelqu'un d'autre.

Un VPS se classe d'abord en machine virtuelle ou en conteneur. La forme virtuelle reprend la colonne steal, avec un plafond en général plus bas. Le conteneur n'a pas de st. Le bridage CPU se lit dans nr_throttled et throttled_usec du fichier cpu.stat du contrôleur CPU. Lisez ce bridage comme un quota atteint. Entre VPS et serveur dédié, la coupe est celle-ci : le VPS reste une part. Le dédié, ici le bare metal, remet l'ordonnanceur à un client. Sur le système hôte, le steal reste près de 0. Les disques sont les NVMe de ce châssis. La mémoire, ce sont les barrettes de cette machine ; la capacité se choisit à la commande.

Le voisin apparaît dans le steal

Le steal est le temps où l'invité voulait tourner et où l'hôte tenait le CPU. vmstat le montre en st, top en %st. Dans Prometheus, prenez le rate de node_cpu_seconds_total en mode steal, puis la moyenne par cœur. Quelques secondes : un pic du voisin. La VM reste. La lecture qui compte : le steal monte plusieurs fois vers 10 % ou plus, tient des minutes, votre temps user et système n'explique pas tout, et le p95 de l'API suit. Ajouter des vCPU sur un hôte déjà plein allonge souvent la file.

L'autre pointe se note à part. User plus système presque saturés et steal proche de zéro : vous avez consommé les cœurs. Augmentez d'abord le CPU cloud. Si le steal revient aux mêmes heures, l'hôte est la limite. La ligne des 10 % aide à lire. Elle n'est pas une règle d'alerte. Budget de latence serré : baissez-la. Traitement par lots qui peut attendre : relevez-la. Ce qui doit tenir ensemble, ce sont plusieurs jours ouvrés et un p95 dans le même sens.

Sur un conteneur, un bridage qui continue alors que le quota est déjà au maximum du plan se juge comme le steal. Sur le système hôte d'une machine entière, le steal doit rester près de zéro. Si vous lancez ensuite vos propres invités, ils peuvent afficher du steal : c'est votre partage des 32 cœurs.

Le working set a passé le plafond

Le working set, ce sont les pages que la charge retouche sans cesse. Linux place la mémoire libre en cache. Un MemAvailable bas avec une latence stable, c'est en général du cache. Un graphique « mémoire à 90 % » justifie mal un déménagement.

Notez la mesure quand, aux heures d'activité, ceci arrive ensemble. si et so dans vmstat restent au-dessus de zéro. Les défauts majeurs montent avec la latence de la base. Le journal noyau montre un OOM. Le pool que vous voulez dépasse déjà la mémoire de la VM, et la grille du fournisseur n'a pas de palier supérieur utilisable. Le balloon comprime un invité qui ne paraît pas plein, parce que l'hôte a repris des pages. Vérifiez le balloon avant d'appeler cela un working set.

Un working set autour de 32 Go, sans swap et sans OOM, se règle par un palier mémoire cloud plus grand. Quand le working set est déjà au maximum que ce cloud vend, viennent les deux tailles fixes : 128 Go ou 256 Go de DDR4-3200 ECC RDIMM. Aucune barrette n'est ajoutée après la commande. Partez de la pointe, plus une marge pour le système et le cache de pages. Si 128 Go ne contiennent pas l'ensemble, la machine de 256 Go est à $592 par mois. Si aucune des deux ne suffit, ce matériel ne le contiendra pas non plus.

La file disque retient les commits

Quand la base ralentit, lisez la file du volume de données avant la carte réseau. iostat -xz 1 donne aqu-sz, la profondeur moyenne, et w_await, l'attente en écriture. L'OLTP dépend du fsync au commit. Les mégaoctets séquentiels d'une sauvegarde n'expliquent pas l'après-midi.

En pointe, aqu-sz souvent au-dessus de 1, w_await dans les dizaines de millisecondes, temps de commit du journal lent qui suit : la file tient la base. Le débit en Mo/s peut rester modeste. Les volumes réseau ajoutent des crédits d'IOPS. Crédits vides : l'attente saute, puis revient quelques heures plus tard. Même heure chaque jour, un redémarrage du processus ne change rien. Si vous avez déjà le palier d'IOPS le plus haut et que l'attente se répète les jours ouvrés, la limite est le stockage partagé.

Disque plein la nuit et w_await calme le jour : déplacez la sauvegarde. Attente basse, mais verrous ou parcours complets : corrigez le SQL. Sur NVMe, un %util proche de 100 se lit mal comme saturation. Après le passage, gardez la profondeur de file et l'attente en écriture.

La latence qui vient surtout de la distance restera après la disparition du steal. Les machines sont à Tokyo, au Japon. Le chemin vers le Japon et le chemin vers une région lointaine sont deux sujets. Verrous, index absents et appels inter-régions sont hors de ces trois mesures.

Relever les chiffres sur la machine actuelle

Vous pouvez terminer ceci avant toute commande. Les commandes prélèvent. Le jugement reste à côté.

1. 1
   Cinq pointes de jours ouvrés

   Lancez vmstat 1. Gardez us, sy, st, si, so. Exportez le p95 de la même fenêtre. Rangez l'heure de sauvegarde à part.

2. 2
   Séparer cache et working set

   Lisez MemAvailable à côté du pool et de l'usage réel en pointe. Conservez la ligne OOM. Sur un conteneur, lisez aussi le plafond mémoire.

3. 3
   Seulement le disque de données

   iostat -xz 1. Notez aqu-sz et w_await du volume de données, à côté du commit dans le journal lent.

4. 4
   Trois lignes, puis la décision

   Une ligne par mesure : présente ou non, quels jours, p95 dans le même sens. Deux oui mènent à la page de configuration. Un oui : vous redimensionnez la VM et vous remesurez.

vmstat 1
iostat -xz 1

Dans vmstat, us est le temps utilisateur, sy le système, id l'inactivité, wa l'attente disque, st le steal. si et so sont le swap entrant et sortant. Sur un conteneur, ajoutez le delta de nr_throttled. Sans cette colonne, ne concluez pas sur le CPU.

Où les courbes doivent tomber sur une machine entière

Quand deux mesures tiennent, vérifiez que le matériel les absorbe. Le CPU est un AMD EPYC 7543P, 32 cœurs / 64 threads, 2,8–3,7 GHz. Un locataire utilise ce processeur. Sur le système hôte, le steal doit rester près de zéro. Le steal de vos propres invités ne décrit que le partage de ces 32 cœurs.

Mémoire : 128 Go à $465 par mois, ou 256 Go à $592, en DDR4-3200 ECC RDIMM. Choisissez selon le working set de pointe. S'il tient dans 128 Go, prenez 128 Go.

Les disques partent en 2 × 1 To NVMe, sans RAID matériel, chaque disque en accès direct. La capacité utile se lit comme 2 To. Une file venue d'un volume réseau baisse en général une fois les écritures sur le NVMe local. Si elle ne baisse pas, regardez le SQL, ou si un disque ne suffit pas. Vous pouvez ajouter jusqu'à deux disques de 2 To à $83 par mois chacun, toujours en accès direct. Ils ne rejoignent pas un groupe tout seuls. Un RAID logiciel, si vous voulez la redondance, ramène l'utile vers 1 To. Les sauvegardes restent hors de la machine.

Le débit commence à 250 Mbit/s, trafic non compté. Une file disque est une attente de stockage. Passez à 1 Gbit/s (+$251 par mois) ou 2 Gbit/s (+$749) quand le port 250 Mbit/s est lui-même plein, pas parce que le fsync est lent. Une IPv4 est incluse. Les adresses supplémentaires coûtent $2 par mois l'unité, jusqu'à 256 sur le serveur, vendues une par une. Ubuntu 24.04 est un choix sans supplément. Windows Server Standard ajoute $21 par mois, Datacenter $27. Linux en SSH, Windows en RDP.

Le loyer mensuel est le prix du châssis, plus le nombre de disques fois 83, plus le palier de débit, plus le nombre d'IPv4 supplémentaires fois 2, plus le système. Le montant dû est ce loyer mensuel multiplié par le nombre de mois. Mois, trimestre, semestre et année utilisent ce produit. Il n'y a pas de frais d'installation. Les serveurs sont à Tokyo, au Japon. Si seule la file disque tient, et que CPU et mémoire sont calmes, montez d'abord le volume cloud à son palier haut avant de le comparer à une machine qui part de $465 par mois. Un working set léger et une file courte restent en général plus adaptés sur la VM. Quand deux mesures tiennent, ouvrez la page de configuration et choisissez 128 Go ou 256 Go.