Dans l'un des chats, on m'a posé une question :
— Y a-t-il quelque chose que je puisse lire sur la façon de regrouper 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 existe un grand nombre de serveurs : des centaines de milliers ; pour un plus petit nombre, ce texte n'a pas de sens. Troisièmement, nous considérons que nous avons trois contraintes : l'espace physique dans les racks, l'alimentation électrique par rack et laisser les racks en rangées afin de pouvoir utiliser un commutateur ToR pour connecter des serveurs dans des racks adjacents.
La réponse à la question dépend fortement du paramètre que nous optimisons et de ce que nous pouvons faire varier pour obtenir le meilleur résultat. Par exemple, il suffit de prendre un minimum d'espace afin d'en laisser davantage pour une croissance ultérieure. Ou peut-être avons-nous la liberté de choisir la hauteur des racks, la puissance par rack, les prises dans le PDU, le nombre de racks dans un groupe d'interrupteurs (un interrupteur pour 1, 2 ou 3 racks), la longueur des fils et le travail de traction ( c'est critique aux extrémités des rangées : avec 10 racks d'affilée et 3 racks par switch, il faudra tirer les fils vers une autre rangée ou sous-utiliser les ports du switch), etc., etc. Histoires séparées : sélection des serveurs et sélection des DC, nous supposerons qu'ils sont sélectionnés.
Il serait bon de comprendre certaines nuances et détails, en particulier la consommation moyenne/maximale des serveurs et la manière dont l'électricité nous est fournie. Ainsi, si nous disposons d'une alimentation russe de 230 V et d'une phase par rack, alors une machine de 32 A peut gérer ~ 7 kW. Disons que nous payons nominalement 6 kW par rack. Si le fournisseur mesure notre consommation uniquement pour une rangée de 10 racks, et non pour chaque rack, et si la machine est réglée sur une coupure conditionnelle de 7 kW, alors techniquement nous pouvons consommer 6.9 kW dans un seul rack, 5.1 kW dans un autre et tout ira bien - pas punissable.
Notre objectif principal est généralement de minimiser les coûts. Le meilleur critère à mesurer est la réduction du TCO (coût total de possession). Il est composé des pièces suivantes :
- CAPEX : achat d'infrastructure DC, de serveurs, de matériel réseau et de câblage
- OPEX : location DC, consommation électrique, maintenance. OPEX dépend de la durée de vie. Il est raisonnable de supposer que ce sera 3 ans.
En fonction de la taille des éléments individuels dans le gâteau global, nous devons optimiser les éléments les plus chers et laisser les autres utiliser toutes les ressources restantes aussi efficacement que possible.
Disons que nous avons un DC existant, qu'il y a une hauteur de rack de H unités (par exemple, H=47), de l'électricité par rack Prack (Prack=6 kW), et que nous avons décidé d'utiliser des serveurs à deux unités h=2U. Nous retirerons 2 à 4 unités du rack pour les commutateurs, les panneaux de brassage et les organisateurs. Ceux. physiquement, nous avons des serveurs Sh=rounddown((H-2..4)/h) dans notre rack (c'est-à-dire Sh = rounddown((47-4)/2)=21 serveurs par rack). Souvenons-nous de ce Sh.
Dans le cas simple, tous les serveurs d'un rack sont identiques. Au total, si nous remplissons un rack de serveurs, alors sur chaque serveur nous pouvons dépenser en moyenne la puissance Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Par souci de simplicité, nous ignorons ici la consommation des commutateurs.
Faisons un pas de côté et déterminons quelle est la consommation maximale du serveur Pmax. Si c'est très simple, très inefficace et totalement sûr, alors nous lisons ce qui est écrit sur l'alimentation du serveur - c'est tout.
Si c’est plus complexe et plus efficace, alors nous prenons le TDP (package de conception thermique) de tous les composants et le résumons (ce n’est pas très vrai, mais c’est possible).
Habituellement, nous ne connaissons pas le TDP des composants (à l'exception du CPU), nous adoptons donc l'approche la plus correcte, mais aussi la plus complexe (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) , on mesure la consommation. Si nous prenons cela au sérieux, nous devons également créer l'environnement le plus chaud dans le couloir froid pendant les tests, car cela affectera à la fois la consommation des ventilateurs et celle du processeur. Nous obtenons la consommation maximale d'un serveur spécifique avec une configuration spécifique dans ces conditions spécifiques et sous cette charge spécifique. Nous voulons simplement dire qu'un nouveau micrologiciel système, une version logicielle différente et d'autres conditions peuvent affecter le résultat.
Revenons donc à Pserv et comment nous le comparons avec Pmax. Il s’agit de comprendre le fonctionnement des services et la solidité des nerfs de votre directeur technique.
Si nous ne prenons aucun risque, nous pensons que tous les serveurs peuvent simultanément commencer à consommer leur maximum. Au même moment, une entrée dans le DC peut se produire. Même dans ces conditions, l'infra doit fournir un service, donc Pserv ≡ Pmax. Il s’agit d’une approche où la fiabilité est absolument importante.
Si le directeur technique ne pense pas seulement à la sécurité idéale, mais aussi à l’argent de l’entreprise et est assez courageux, alors vous pouvez décider que
- Nous commençons à gérer nos fournisseurs, en particulier, nous interdisons la maintenance programmée aux heures de pointe de charge prévue afin de minimiser la baisse d'un intrant ;
- et/ou notre architecture vous permet de perdre un rack/rangée/DC, mais 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.
Ici, il est très utile non seulement de deviner, mais aussi 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 directeur technique presse tout ce qu'il a et dit : « nous prenons la décision volontaire que la moyenne maximale réalisable de la consommation maximale du serveur par rack est **tellement** inférieure à la consommation maximale », conditionnellement Pserv = 0.8* Pmax.
Et puis un rack de 6kW ne peut plus accueillir 16 serveurs avec Pmax = 375W, mais 20 serveurs avec Pserv = 375W * 0.8 = 300W. Ceux. 25% de serveurs en plus. Il s'agit d'une très grosse économie - après tout, nous avons immédiatement besoin de 25 % de racks en moins (et nous économiserons également sur les PDU, les commutateurs et les câbles). Un sérieux inconvénient d’une telle solution est que nous devons constamment vérifier que nos hypothèses sont toujours correctes. Que la nouvelle version du firmware ne modifie pas de manière significative le fonctionnement des ventilateurs et la consommation, que le développement soudain avec la nouvelle version n'a pas commencé à utiliser les serveurs beaucoup plus efficacement (lire : ils ont atteint une plus grande charge et une plus grande consommation sur le serveur). Après tout, nos hypothèses et nos conclusions initiales deviennent alors immédiatement incorrectes. C'est un risque qui doit être pris de manière responsable (ou évité et payer pour des racks manifestement sous-utilisés).
Remarque importante : vous devriez essayer de répartir les serveurs de différents services horizontalement sur les racks, si possible. Ceci est nécessaire pour éviter que des situations ne se produisent lorsqu'un lot de serveurs arrive pour un service, les racks en sont emballés verticalement pour augmenter la « densité » (car c'est plus facile ainsi). En réalité, il s'avère qu'un rack est rempli de serveurs identiques à faible charge du même service, et l'autre est rempli de serveurs à charge tout aussi élevée. La probabilité d'une deuxième chute est nettement 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 de l'augmentation de la charge.
Revenons à la répartition des serveurs en racks. Nous avons examiné l'espace physique du rack et les limitations de puissance. Examinons maintenant le réseau. Vous pouvez utiliser des commutateurs avec des ports 24/32/48 N (par exemple, nous avons des commutateurs ToR à 48 ports). Heureusement, il n’existe pas beaucoup d’options si l’on ne pense pas aux câbles break-out. Nous envisageons des scénarios où nous avons un commutateur par rack, un commutateur pour deux ou trois racks dans le groupe Rnet. Il me semble que plus de trois racks dans un 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 réseau (1, 2 ou 3 racks dans un groupe), nous répartissons les serveurs parmi les racks :
Srack = min(Sh, arrondi(Prack/Pserv), arrondi(N/Rnet))
Ainsi, pour l'option avec 2 racks dans un groupe :
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 serveurs par rack.
Nous considérons les options restantes de la même manière :
Srack1 = 20
Srack3 = 16
Et nous y sommes presque. Nous comptons le nombre de racks pour répartir tous nos serveurs S (soit 1000) :
R = rafle (S / (Srack * Rnet)) * Rnet
R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 racks
R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 racks
R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 racks
Ensuite, nous calculons 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 inférieur. Profit!
Notez que même si le nombre de racks requis pour les options 1 et 2 est 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 Si vous avez la possibilité de jouer avec la puissance par rack et la hauteur du rack, la variabilité augmente. Mais le processus peut être réduit à celui décrit ci-dessus en parcourant simplement les options. Oui, il y aura plus de combinaisons, mais toujours un nombre très limité - l'alimentation électrique du rack pour le calcul peut être augmentée par pas de 1 kW, les racks typiques sont disponibles dans un nombre limité de tailles standard : 42U, 45U, 47U, 48U , 52U. Et ici, l’analyse What-If d’Excel en mode Tableau de données peut aider aux calculs. Nous regardons les assiettes reçues et choisissons le minimum.
Source: habr.com