Comment dimensionner un serveur (la plupart des gens ont besoin de moins qu'ils ne le pensent)

Personne n'arrive en demandant une machine plus petite. Les gens arrivent avec une facture cloud et une image mentale de la taille que la charge de travail doit avoir, parce que la facture leur annonce un gros chiffre chaque mois depuis des années. Le chiffre est réel. La taille qu'il sous-entend ne l'est presque jamais.

Votre facture n'est pas votre charge de travail

Une facture au compteur mesure ce qui vous a été alloué et facturé, pas ce que vos processus ont touché. Avec le temps, vous cessez de dimensionner d'après la charge de travail et commencez à dimensionner d'après la facture, parce que la facture est le seul chiffre devant vous. La plupart des charges de travail qui arrivent chez nous utilisent une fraction de ce qu'elles paient.

Alors avant de chiffrer quoi que ce soit, nous vous demandons d'aller regarder. Pas la facture. La machine.

Les trois commandes qui remettent la facture à sa place

free -m : êtes-vous vraiment limité par la RAM ?

La mémoire est la ressource que les gens surachètent le plus souvent, parce qu'en manquer paraît catastrophique. Lancez ceci sur votre machine actuelle et lisez la colonne available, pas used. Le cache n'est pas de la consommation.

$ free -m
               total        used        free      shared  buff/cache   available
Mem:           64157       11238        1002         418       51917       52104

Soixante-quatre gigaoctets provisionnés. Onze utilisés. Cinquante-deux disponibles, dont la plupart garés en cache récupérable. C'est une machine qui se croit une charge de travail de 64 GB et qui est en réalité une charge de 16 GB avec un cache disque en bonne santé.

df -h : à quel point « plein » est-il plein

L'autre achat réflexe est le stockage. Demandez au disque ce qu'il contient plutôt que ce pour quoi il a été vendu.

$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  1.8T  240G  1.5T  14% /

Deux téraoctets provisionnés, quatorze pour cent utilisés. Ce n'est pas un problème de stockage, c'est une habitude de stockage. Le chiffre dont vous avez besoin est le montant utilisé plus une courbe de croissance réaliste, pas la taille de la dernière machine que quelqu'un a achetée.

Charge CPU et steal sur un vrai pic

Échantillonnez votre CPU sur une fenêtre réellement chargée, pas un mardi après-midi au calme. Sur une instance de cloud partagé, surveillez la colonne %steal : c'est le temps où votre charge de travail voulait un cœur et où l'hyperviseur l'a donné à un voisin.

$ mpstat 1 3
CPU    %usr   %sys  %iowait  %steal   %idle
all   22.10   3.40     0.80    6.20    67.50

Soixante-sept pour cent d'inactivité au pic, et 6,2 pour cent du temps perdu en steal par-dessus. Sur du bare metal, cette colonne steal affiche 0.00, tous les jours, parce que vos cœurs sont vos cœurs. Une partie du calcul dont vous pensez avoir besoin n'est même pas de la charge de travail.

La marge n'est pas une machine plus grosse

L'objection habituelle est : mais j'ai besoin de place pour les pics. Vous en avez besoin, et vous l'avez déjà. Sur du matériel qui vous appartient, la marge pour les pics est déjà là, parce que la capacité vide est dans la machine que vous avez. Personne ne compte votre pic. Cela signifie que vous dimensionnez sur la consommation réelle plus une marge honnête, et la marge est gratuite au lieu d'être une raison d'acheter la taille au-dessus.

Au compteur, la peur du pic est rationnelle, parce que le pic a un prix. Supprimez le compteur et la peur cesse d'être une ligne sur la facture. Vous pouvez dimensionner sur ce que vous consommez.

Pourquoi notre outil plaide pour plus petit

Notre Sizing Desk vend à la baisse à dessein. Donnez-lui une charge de travail qui sonne lourd avec des réponses d'usage honnêtes et il tamponnera la proposition NOUS VOUS AVONS DIMENSIONNÉ À LA BAISSE et chiffrera quand même le Reference Build. Le message qu'il imprime est délibéré : les charges de travail comme la vôtre arrivent en général en cherchant une machine plus grosse, vos réponses d'usage disent que le Reference Build porte déjà plus de marge que ce que vous avez décrit, c'est donc cela que nous avons chiffré.

Ce n'est pas de la modestie. C'est de l'arithmétique de fidélisation. Un client bien dimensionné tourne confortablement et reste des années, et la façon la plus simple de garder un client est de ne pas lui survendre dès le départ.

Une chaîne de magasins de réparation fait tourner son ERP sur une de ces machines. Bien dimensionnée, sans histoire, ennuyeuse comme l'infrastructure devrait l'être.

Quand vous avez vraiment besoin de plus

Parfois les chiffres disent d'aller plus gros, et alors nous le faisons. Les signaux sont réels, pas imaginés : votre mémoire available se resserre vraiment au pic, votre disque se remplit réellement, votre %idle est bas quand ça compte. Nous bâtissons de grandes machines uniques, jusqu'à quatre sockets, tout ce que le travail mérite.

Relevez vos trois chiffres, puis laissez l'outil essayer de vous vendre moins. S'il vous dimensionne à la baisse, ce n'est pas un tour de passe-passe. C'est toute la méthode qui fonctionne.