Dans l'un des chats, on m'a posé une question:
- Et il y a quelque chose à lire, comment emballer correctement les serveurs dans des racks?
J'ai réalisé que je ne connaissais pas un tel texte, alors j'ai écrit le mien.
Premièrement, ce texte concerne les serveurs physiques dans les centres de données physiques (DC). Deuxièmement, nous pensons qu'il y a beaucoup de serveurs: des centaines ou des milliers, pour un plus petit nombre ce texte n'a pas de sens. Troisièmement, nous pensons que nous avons trois limiteurs: l'espace physique dans les racks, l'alimentation du rack et laisser les racks se tenir en rangées, afin que nous puissions utiliser un commutateur ToR pour connecter les serveurs dans les racks voisins.
La réponse à la question dépend grandement du paramètre que nous optimisons et de ce que nous pouvons varier afin d'obtenir le meilleur résultat. Par exemple, il suffit de prendre un minimum d'espace pour en laisser plus pour une croissance future. Ou peut-être que nous avons la liberté de choisir la hauteur des racks, la puissance par rack, les prises dans la PDU, le nombre de racks dans un groupe de commutateurs (un commutateur pour 1, 2 ou 3 racks), la longueur des fils et le travail de traction (cela est critique à la fin des rangées: avec 10 racks d'affilée et 3 racks sur l'interrupteur, vous devrez tirer les fils dans une autre rangée ou sous-utiliser les ports de l'interrupteur), etc., etc. Histoires distinctes: sélection du serveur et sélection DC, nous supposons qu'elles sont sélectionnées.
Il serait intéressant de comprendre certaines nuances et détails, en particulier la consommation moyenne / maximale des serveurs et la façon dont nous sommes alimentés en électricité. Donc, si nous avons une alimentation russe de 230 V et une phase par rack, une machine de 32 A peut contenir environ 7 kW. Supposons que nous payons nominalement 6 kW par rack. Si un fournisseur mesure notre consommation uniquement pour une série de 10 racks, et non pour chaque rack, et si la machine est à une coupure conventionnelle de 7 kW, alors techniquement, nous pouvons engloutir 6,9 kW dans un rack séparé, dans un autre 5,1 kW et tout ira bien - pas punissable.
Généralement, notre objectif principal est de minimiser les coûts. Le meilleur critère de mesure est la réduction du TCO (coût total de possession). Il se compose des pièces suivantes:
- CAPEX: acquisition d'infrastructure DC, de serveurs, de matériel réseau et de câblage
- OPEX: location DC, électricité consommée, maintenance. OPEX dépend de la durée de vie. Il est raisonnable de supposer qu'il est égal à 3 ans.
Selon la taille des pièces individuelles dans la tarte entière, nous devons optimiser la plus chère et laisser le reste utiliser toutes les ressources restantes aussi efficacement que possible.
Supposons que nous ayons un DC existant, il y a une hauteur de rack d'unités H (par exemple, H = 47), de l'électricité vers le rack P du
rack (P
rack = 6 kW), et nous avons décidé d'utiliser des serveurs à deux unités h = 2U. Nous retirons 2 à 4 unités du rack aux commutateurs, panneaux de brassage et organisateurs. C'est-à-dire physiquement, nous avons S
h = arrondi ((H-2..4) / h) serveurs dans notre rack (c'est-à-dire S
h = arrondi ((47-4) / 2) = 21 serveurs par rack). N'oubliez pas que c'est S
h .
Dans le cas simple, tous les serveurs du rack sont identiques. Au total, si nous martelons le rack avec des serveurs, alors sur chaque serveur nous pouvons dépenser en moyenne la puissance P
serv = P
rack / S
h (P
serv = 6000 W / 21 = 287 W). Par souci de simplicité, nous ignorons ici la consommation des commutateurs.
Nous faisons un pas de côté et déterminons quelle est la consommation maximale du serveur P
max . Si c'est très simple, très inefficace et complètement sûr, alors nous lisons ce qui est écrit sur l'alimentation du serveur - c'est tout.
Si c'est plus compliqué, plus efficace, alors nous prenons le TDP (package de conception thermique) de tous les composants et résumons (ce n'est pas très vrai, mais cela peut être le cas).
Habituellement, nous ne connaissons pas les composants TDP (sauf pour le CPU), nous adoptons donc l'approche la plus correcte, mais aussi la plus difficile (nous avons besoin d'un laboratoire) - nous prenons un serveur expérimental de la configuration requise et le chargeons, par exemple, avec Linpack (CPU et mémoire) et fio (disques) mesurer la consommation. Si vous le prenez au sérieux, vous devez également créer l'environnement le plus chaud dans le couloir froid pendant les tests, car cela affectera à la fois la consommation du ventilateur et la consommation du processeur. Nous obtenons la consommation maximale d'un serveur spécifique avec une configuration spécifique dans ces conditions spécifiques sous cette charge spécifique. Nous voulons simplement dire que le nouveau firmware du système, une autre version du logiciel, d'autres conditions peuvent affecter le résultat.
Au total, nous revenons à P
serv et comment le comparer avec P
max . Il s'agit de comprendre comment fonctionnent les services et à quel point vos nerfs sont forts chez votre technicien.
Si vous ne le risquez pas du tout, nous pensons que tous les serveurs peuvent immédiatement commencer à consommer leur maximum. En même temps, une entrée vers le DC peut être formée. Infra dans ces conditions devrait fournir un service, donc P
serv ≡ P
max . Il s'agit d'une approche où la fiabilité est absolument cruciale.
Si le technicien pense non seulement à une sécurité parfaite, mais aussi à l'argent de l'entreprise et est assez courageux, alors nous pouvons décider
- nous commençons à gérer nos fournisseurs, en particulier, nous interdisons la maintenance planifiée au moment de la charge de pointe prévue pour minimiser la baisse d'une entrée;
- et / ou notre architecture vous permet de perdre le rack / ligne / DC, et les services continuent de fonctionner;
- et / ou nous répartissons bien la charge horizontalement sur les racks, de sorte que nos services n'atteindront jamais la consommation maximale dans un seul rack tous ensemble.
Il est très utile ici non seulement de deviner, mais de surveiller la consommation et de savoir comment les serveurs consomment réellement de l'électricité dans des conditions normales et de pointe. Par conséquent, après quelques analyses, le techdir comprime tout ce qu'il possède et dit: «nous acceptons volontairement que la moyenne maximale réalisable de la consommation maximale de serveur par rack est ** tellement ** inférieure à la consommation maximale», conditionnellement P
serv = 0,8 * P
max .
Et puis pas 16 serveurs avec P
max = 375W, mais 20 serveurs avec P
serv = 375W \ * 0.8 = 300W, montez dans un rack 6kW. C'est-à-dire 25% de serveurs en plus. Il s'agit d'une très grande économie - après tout, nous avons immédiatement besoin de 25% de racks en moins (nous économisons également sur les PDU, les commutateurs et les câbles). Un sérieux inconvénient d'une telle décision - il est nécessaire de surveiller en permanence que nos hypothèses sont toujours vraies. Que la nouvelle version du firmware ne change pas de manière significative le fonctionnement des ventilateurs et la consommation, que le développement d'une nouvelle version n'a soudainement pas commencé à utiliser le serveur beaucoup plus efficacement (lire, nous avons eu plus de charge et plus de consommation sur le serveur). Après tout, nos hypothèses et conclusions initiales deviennent immédiatement incorrectes. C'est un risque qui doit être pris de manière responsable (ou évité puis payé pour des racks évidemment sous-chargés).
Une note importante - vous devriez essayer de distribuer les serveurs de différents services sur des racks horizontalement, si possible. Ceci est nécessaire pour que les histoires ne se produisent pas lorsqu'un lot de serveurs pour un service arrive, les racks sont bouchés verticalement avec lui pour augmenter la "densité" (car c'est plus facile). En réalité, il s'avère qu'un rack est rempli des mêmes serveurs à faible charge d'un service, et que l'autre est également à forte charge. La probabilité d'une chute de la seconde est beaucoup plus élevée, car le profil de charge est le même et tous les serveurs réunis dans ce rack commencent à consommer la même quantité en raison d'une charge accrue.
Revenons à la distribution des serveurs dans les racks. Nous avons examiné les limitations physiques de l'espace rack et des limitations d'alimentation, et jetons maintenant un œil au réseau. Vous pouvez utiliser des commutateurs sur les ports N 24/32/48 (par exemple, nous avons des commutateurs ToR à 48 ports). Heureusement, il n'y a pas beaucoup d'options si vous ne pensez pas aux câbles de dérivation. Nous considérons les scénarios lorsque nous avons un commutateur par rack, un commutateur vers deux ou trois racks dans le groupe R
net . Il me semble que plus de trois racks du groupe, c'est déjà trop, car le problème du câblage entre les racks devient beaucoup plus important.
Ainsi, pour chaque scénario de réseau (1, 2 ou 3 racks dans un groupe) nous répartissons le serveur en racks:
Rack S = min (S
h , rounddown (P
rack / P
serv ), rounddown (N / R
net ))
Ainsi, pour l'option avec 2 racks du groupe:
Rack S
2 = min (21, arrondi (6000/300), arrondi (48/2)) = min (21, 20, 24) = 20 serveurs par rack.
De même, nous considérons les options restantes:
Rack S
1 = 20
Rack S
3 = 16
Et nous y sommes presque. Nous comptons le nombre de racks pour la distribution de tous nos serveurs S (soit 1000):
R = arrondi (S / (
rack S * R
net )) * R
netR
1 = arrondi (1000 / (20 * 1)) * 1 = 50 * 1 = 50 racks
R
2 = arrondi (1000 / (20 * 2)) * 2 = 25 * 2 = 50 racks
R
3 = arrondi (1000 / (16 * 3)) * 3 = 21 * 3 = 63 racks
Ensuite, nous considérons le TCO pour chaque option en fonction du nombre de racks, du nombre requis de commutateurs, du câblage, etc. Nous choisissons l'option où le TCO est moindre. Profit!
Notez que bien que le nombre requis de racks pour les options 1 et 2 soit le même, leur prix sera différent, car le nombre de commutateurs pour la deuxième option est deux fois moins élevé et la longueur des câbles requis est plus longue.
PS S'il y a une possibilité de jouer la puissance sur un rack et une hauteur de rack, la variabilité augmente. Mais le processus peut être réduit à ce qui précède, il suffit de trier les options. Oui, il y aura plus de combinaisons, mais toujours un nombre très limité - la puissance du rack pour le calcul peut être augmentée par incréments de 1 kW, les racks typiques sont d'un nombre limité de tailles: 42U, 45U, 47U, 48U, 52U. Et ici, l'analyse What-If d'Excel en mode Table de données peut aider à calculer. Nous regardons les plaques reçues et sélectionnons le minimum.