Dans l'un des chats, on m'a posé la question :
— Y a-t-il quelque chose à lire sur la manière de bien emballer les serveurs dans les racks ?
J'ai compris que je ne connaissais pas ce type de texte, alors j'ai écrit le mien.
Tout d'abord, ce texte concerne les serveurs physiques dans des centres de données physiques (CDP). Deuxièmement, supposons que nous avons un grand nombre de serveurs : des centaines à des milliers, pour un nombre moindre, ce texte n'a pas de sens. Troisièmement, considérons que nous avons trois limites : l'espace physique dans les racks, l'alimentation électrique par rack, et admettons que les racks sont disposés en rangées, ce qui nous permet d'utiliser un switch ToR pour connecter les serveurs dans des racks adjacents.
La réponse à la question dépend fortement de quel paramètre nous optimisons et ce que nous pouvons varier pour obtenir le meilleur résultat. Par exemple, nous devons simplement occuper un minimum d'espace pour laisser plus de place à la croissance future. Ou peut-être avons-nous la liberté de choisir la hauteur des racks, la puissance par rack, le nombre de prises dans le PDU, le nombre de racks dans un groupe de switches (un switch pour 1, 2 ou 3 racks), la longueur des câbles et les travaux d'installation (c'est critique aux extrémités des rangées : avec 10 racks dans une rangée et 3 racks sur un switch, il faudra tirer des câbles vers une autre rangée ou sous-utiliser les ports sur le switch), etc., etc. Des histoires distinctes : le choix des serveurs et le choix du CDP, nous allons considérer qu'ils sont déjà choisis.
Il serait utile de comprendre certains détails et nuances, en particulier la consommation moyenne / maximale des serveurs, et comment l'électricité nous est fournie. Ainsi, si nous avons une alimentation russe de 230V et une phase par rack, alors un disjoncteur de 32A peut supporter ~7kW. Supposons que nous payons nominalement pour 6kW par rack. Si le fournisseur mesure notre consommation uniquement pour une rangée de 10 racks, et non pour chaque rack, et si le disjoncteur est réglé pour couper à environ 7kW, alors techniquement, nous pouvons consommer 6.9kW dans un rack, 5.1kW dans un autre, et tout ira bien — sans pénalité.
En général, notre objectif principal est de minimiser les coûts. Le meilleur critère de mesure est la réduction du TCO (total cost of ownership - coût total de possession). Il se compose des éléments suivants :
- CAPEX : achat de l'infrastructure du CDP, des serveurs, des équipements réseau et câblage
- OPEX : location du CDP, électricité consommée, entretien. L'OPEX dépend de la durée de vie. Il est raisonnable de supposer qu'il est égal à 3 ans.
Selon la taille des différentes parties du gâteau global, nous devons optimiser ce qui est le plus coûteux, tandis que le reste peut utiliser toutes les ressources restantes de la manière la plus efficace possible.
Supposons que nous avons déjà un Data Center existant, une hauteur de rack H unités (pour cet exemple H=47), puissance par rack Prack (Prack=6kW), et nous avons décidé d'utiliser des serveurs de 2U de hauteur h. Nous allons retirer 2 à 4 unités du rack pour des commutateurs, des panneaux de brassage et des organiseurs. Par conséquent, physiquement, nous pouvons installer Sh=rounddown((H-2..4)/h) serveurs dans le rack (c’est-à-dire Sh = rounddown((47-4)/2)=21 serveurs par rack). Retenons ce Sh.
Dans le cas le plus simple, tous les serveurs du rack sont identiques. Au total, si nous remplissons le rack serveurs très chargés, nous pouvons en moyenne attribuer une puissance Pserv=Prack/Sh (Pserv = 6000W/21 = 287W) à chaque serveur. Pour simplifier, nous ignorons ici la consommation du commutateur.
Faisons un pas de côté et déterminons ce qu'est la consommation maximale du serveur Pmax. Pour le dire simplement, de manière très inefficace et tout en étant complètement sûr, regardez ce qui est écrit sur l'alimentation du serveur — c'est ça.
Si nous voulons être plus précis, plus efficace, nous prenons le TDP (package de conception thermique) de tous les composants et nous les additionnons (ce n'est pas tout à fait vrai, mais cela peut fonctionner).
Habituellement, nous ne connaissons pas le TDP des composants (sauf pour le CPU), donc nous adoptons l'approche la plus correcte, mais aussi la plus complexe (un laboratoire est nécessaire) — nous prenons un serveur expérimental avec la configuration souhaitée et le chargeons, par exemple, avec Linpack (CPU et mémoire) et fio (disques), et mesurons la consommation. Si nous abordons cela sérieusement, nous devons également créer l'environnement le plus chaud dans le couloir froid pendant les tests, car cela influence la consommation des ventilateurs ainsi que celle du CPU. Nous obtenons la consommation maximale d'un serveur spécifique avec une configuration spécifique dans ces conditions particulières et sous cette charge spécifique. Gardez simplement à l'esprit qu'un nouveau firmware, une autre version du logiciel, ou d'autres conditions peuvent influencer le résultat.
En résumé, revenons à Pserv et à la façon dont nous pouvons le comparer à Pmax. Cela soulève la question de la compréhension du fonctionnement des services et de la robustesse nerveuse de votre directeur technique.
Si nous ne voulons vraiment pas prendre de risques, alors nous considérons que tous les serveurs peuvent commencer à consommer leur maximum en même temps. À ce moment-là, une seule entrée peut se former dans le Data Center. L'infrastructure, dans ces conditions, doit fournir le service, donc Pserv ≡ Pmax. C'est une approche où la fiabilité est absolument essentielle.
Si le directeur technique pense non seulement à la sécurité idéale, mais aussi aux intérêts financiers de l'entreprise et qu'il est suffisamment audacieux, on peut en déduire que
- nous commençons à gérer nos fournisseurs, en interdisant notamment de réaliser une maintenance planifiée durant les périodes de pointe attendues afin de minimiser les chutes d'un serveur;
- et/ou notre architecture permet de perdre un rack/rangée/datacenter, tout en maintenant les services opérationnels;
- et/ou nous répartissons bien la charge horizontalement entre les racks, de sorte que nos services ne rencontrent jamais une consommation maximale simultanée dans un seul rack.
Il est très utile non seulement de spéculer, 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. Ainsi, après une certaine analyse, le directeur technique résume tout ce qu'il a et déclare : « Par décision arbitraire, nous acceptons que la moyenne maximale atteignable des pics de consommation des serveurs par rack soit **telle ou telle** en dessous de la consommation maximale », conditionnellement Pserv = 0,8 * Pmax.
Et alors, dans un rack de 6 kW, il ne pourra plus accueillir 16 serveurs avec Pmax = 375 W, mais 20 serveurs avec Pserv = 375 W * 0,8 = 300 W. Soit 25 % de serveurs en plus. C'est une très grande économie — car nous aurons aussi besoin de 25 % de racks en moins (et il y a aussi des économies à réaliser sur les PDU, les switchs et les câbles). Un inconvénient sérieux de cette solution est qu'il faut surveiller en permanence que nos hypothèses restent valables. Que la nouvelle version du firmware ne modifie pas de manière substantielle le fonctionnement des ventilateurs et la consommation, que le développement n'a pas commencé à utiliser les serveurs de manière beaucoup plus efficace (entendez par là avoir une charge et une consommation plus élevées sur le serveur). Car alors, nos hypothèses initiales et conclusions deviennent immédiatement incorrectes. C'est un risque qu'il faut accepter de manière responsable (ou éviter et alors payer pour des racks manifestement sous-utilisés).
Remarque importante : il est conseillé d'essayer de répartir les serveurs de différents services horizontalement entre les racks, si possible. Cela permet de prévenir les situations où un lot de serveurs pour un seul service arrive, et les racks sont remplis verticalement pour augmenter la "densité" (car c'est plus simple). En réalité, cela signifie qu'un rack est rempli de serveurs à faible charge du même service, tandis qu'un autre est rempli de serveurs à forte charge. La probabilité de défaillance du second est nettement plus élevée, car le profil de charge est identique, et tous les serveurs de ce rack commencent à consommer la même quantité en raison de l'augmentation de la charge.
Revenons à la répartition des serveurs dans les racks. Nous avons examiné les limitations physiques en termes d'espace dans le rack et les contraintes d'alimentation, passons maintenant au réseau. On peut utiliser des commutateurs de 24/32/48 ports N (dans notre exemple, des commutateurs ToR à 48 ports). Heureusement, il n'y a pas beaucoup d'options, à moins de penser aux câbles break-out. Nous considérons les scénarios où nous avons un commutateur par rack, un commutateur pour deux ou trois racks dans le groupe Rnet. Je pense que plus de trois racks dans un groupe est déjà excessif, car le problème de câblage entre les racks devient beaucoup plus important.
Donc, pour chaque scénario réseau (1, 2 ou 3 racks dans le groupe), nous répartissons les serveurs entre les racks :
Srack = min(Sh, rounddown(Prack / Pserv), rounddown(N / Rnet))
Ainsi, pour le cas avec 2 racks dans le groupe :
Srack2 = min(21, rounddown(6000 / 300), rounddown(48 / 2)) = min(21, 20, 24) = 20 serveurs par rack.
Nous calculons de la même manière les autres options :
Srack1 = 20
Srack3 = 16
Et nous sommes presque à la cible. Calculons le nombre de racks nécessaires pour répartir tous nos serveurs S (prenons 1000) :
R = roundup(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 sur la base du nombre de racks, du nombre nécessaire de commutateurs, du câblage, etc. Nous choisissons l'option où le TCO est le plus bas. Profit !
Notons que bien que le nombre de racks nécessaires pour les options 1 et 2 soit identique, leur coût sera différent, car le nombre de commutateurs pour la seconde option est deux fois moindre, tandis que la longueur des câbles nécessaires est plus grande.
P.S. Si vous avez la possibilité de jouer sur la puissance et la hauteur du rack, la variabilité augmente. Mais le processus peut être réduit à ce qui est décrit ci-dessus en parcourant simplement les options. Oui, il y aura plus de combinaisons, mais elles resteront tout de même assez limitées — l'alimentation pour le calcul peut être augmentée par pas de 1 kW, et les racks standards existent en un nombre limité de dimensions : 42U, 45U, 47U, 48U, 52U. Pour cela, l'analyse What-If d'Excel en mode Data Table peut être utile. Regardez les tableaux obtenus et choisissez le minimum.
Source : habr.com
