Optimierung der Serververteilung auf Racks

In einem der Chats wurde mir die Frage gestellt:

— Gibt es etwas zu lesen, wie man Server korrekt in Racks verpackt?

Ich stellte fest, dass ich so einen Text nicht kenne, also habe ich meinen eigenen geschrieben.

Zunächst einmal handelt dieser Text von physischen Servern in physischen Rechenzentren (RZ). Zweitens gehen wir davon aus, dass wir ziemlich viele Server haben: Hunderte bis Tausende, für eine kleinere Anzahl macht dieser Text keinen Sinn. Drittens gehen wir davon aus, dass wir drei Einschränkungen haben: physischen Platz in Racks, Stromversorgung pro Rack und nehmen wir an, die Racks stehen in Reihen, so dass wir einen ToR-Switch für den Anschluss von Servern in angrenzenden Racks verwenden können.

Die Antwort auf die Frage hängt stark davon ab, welchen Parameter wir optimieren und was wir variieren können, um das beste Ergebnis zu erzielen. Zum Beispiel könnte es nötig sein, möglichst wenig Platz zu beanspruchen, um mehr Raum für zukünftiges Wachstum zu lassen. Oder vielleicht haben wir Freiheit bei der Wahl der Rackhöhe, der Leistung pro Rack, der Steckdosen im PDU, der Anzahl der Racks in der Switch-Gruppe (ein Switch für 1, 2 oder 3 Racks), der Kabellängen und der Arbeiten zum Verlegen von Kabeln (das ist entscheidend am Ende der Reihen: bei 10 Racks in einer Reihe und 3 Racks pro Switch müssen Kabel in eine andere Reihe gezogen werden oder Ports im Switch bleiben ungenutzt), usw., usw. Einzelne Geschichten: die Auswahl der Server und die Wahl des RZ, wir gehen davon aus, dass sie bereits gewählt wurden.

Es wäre gut, einige Nuancen und Details zu verstehen, insbesondere den durchschnittlichen / maximalen Stromverbrauch der Server und wie uns der Strom geliefert wird. Wenn wir beispielsweise in Russland eine 230V-Stromversorgung und eine Phase pro Rack haben, dann kann ein 32A-automatische Schaltung ~7kW halten. Angenommen, wir zahlen nominal für 6kW pro Rack. Wenn der Anbieter unseren Verbrauch nur für die Reihe von 10 Racks misst und nicht für jedes Rack, und wenn der automatische Schalter an einem Grenzwert von 7kW steht, dann können wir technisch in einem einzelnen Rack 6.9kW verbrauchen, in einem anderen 5.1kW und alles wird gut sein — ohne Strafe.

In der Regel ist unser Hauptziel die Kostenminimierung. Das beste Kriterium zur Messung ist die Senkung der TCO (total cost of ownership — Gesamteigentumskosten). Sie setzt sich aus folgenden Teilen zusammen:

• CAPEX: Anschaffung der Infrastruktur des RZ, Server, Netzwerkhardware und Verkabelung
• OPEX: Miete des RZ, verbrauchte Elektrizität, Wartung. OPEX hängt von der Lebensdauer ab. Es ist sinnvoll, seine Dauer mit 3 Jahren anzunehmen.

Je nach Größe der einzelnen Teile im gesamten Kuchen müssen wir das Kostspieligste optimieren, während der Rest alle verbleibenden Ressourcen so effizient wie möglich nutzt.

Angenommen, wir haben ein bestehendes Rack, es gibt eine Höhe von H Einheiten (zum Beispiel H=47), Strom pro Rack Prack (Prack=6kW), und wir haben beschlossen, h=2U zwei-Einheiten-Server zu verwenden. Wir entfernen 2..4 Einheiten aus dem Rack für Switches, Patchpanels und Organizer. Das heißt, physisch passt Sh=rounddown((H-2..4)/h) Server in unser Rack (d.h. Sh = rounddown((47-4)/2)=21 Server pro Rack). Wir merken uns dieses Sh.

Im einfachsten Fall sind alle Server im Rack identisch. Insgesamt, wenn wir das Rack füllen, Servern, können wir für jeden Server im Durchschnitt eine Leistung von Pserv=Prack/Sh (Pserv = 6000W/21 = 287W) einplanen. Zum Einfachheit ignorieren wir hier den Stromverbrauch des Switches.

Lassen Sie uns einen Schritt zurücktreten und definieren, was der maximale Verbrauch eines Servers Pmax ist. Wenn wir es sehr einfach und ineffizient betrachten, dann lesen wir, was auf dem Netzteil des Servers steht — das ist es.

Wenn es komplizierter und effizienter ist, greifen wir auf das TDP (Thermal Design Package) aller Komponenten zurück und summieren auf (das ist nicht ganz wahr, aber es geht auch so).

Normalerweise kennen wir das TDP der Komponenten (außer der CPU) nicht, also wählen wir den korrektesten, aber auch kompliziertesten Ansatz (ein Labor ist erforderlich) — wir nehmen einen experimentellen Server in der benötigten Konfiguration und belasten ihn, zum Beispiel mit Linpack (CPU und RAM) und fio (Festplatten), und messen den Verbrauch. Wenn wir das ernsthaft angehen, sollten wir außerdem die wärmsten Bedingungen im kalten Gang während der Tests schaffen, da dies sowohl den Verbrauch der Ventilatoren als auch der CPU beeinflusst. Wir erhalten den maximalen Verbrauch eines bestimmten Servers mit einer bestimmten Konfiguration unter diesen spezifischen Bedingungen bei dieser spezifischen Last. Wir müssen nur bedenken, dass neue Firmware, eine andere Softwareversion oder andere Bedingungen das Ergebnis beeinflussen können.

Zusammengefasst, kehren wir zu Pserv zurück und wie wir es mit Pmax vergleichen können. Das ist eine Frage des Verständnisses, wie die Dienste arbeiten und wie stabil die Nerven Ihres Technikleiters sind.

Wenn wir kein Risiko eingehen möchten, gehen wir davon aus, dass alle Server gleichzeitig ihren maximalen Verbrauch erreichen können. In diesem Moment kann ein einziger Eingang ins Rack bestehen. Die Infrastruktur muss unter diesen Bedingungen den Dienst bereitstellen, daher gilt Pserv ≡ Pmax. Dies ist ein Ansatz, bei dem absolute Zuverlässigkeit entscheidend ist.

Wenn der technische Direktor nicht nur an perfekter Sicherheit, sondern auch an den Finanzen des Unternehmens denkt und mutig genug ist, dann kann man entscheiden, dass

• wir beginnen, unsere Anbieter zu managen, insbesondere das Durchführen von planmäßigen Wartungen zu den Zeiten geplanter Spitzenlasten zu verbieten, um den Ausfall eines Eingangs zu minimieren;
• und/oder unsere Architektur es erlaubt, einen Rack/Einheit/Rechenzentrum zu verlieren, während die Services weiterlaufen;
• und/oder wir die Last gut horizontal auf die Racks verteilen, sodass unsere Services niemals die maximale Verbrauchsrate in einem Rack gleichzeitig erreichen.

Es ist hier sehr nützlich, nicht nur zu spekulieren, sondern den Verbrauch zu überwachen und zu wissen, wie Server in normalen und Spitzenbedingungen tatsächlich Strom verbrauchen. Daher, nach einiger Analyse, fasst der technische Direktor alles zusammen und sagt: „Wir entscheiden durch einen Willensakt, dass der maximal erreichbare Durchschnitt von den Maximalwerten des Serververbrauchs pro Rack **so viel** unter dem maximalen Verbrauch liegt“, bedingt Pserv=0,8*Pmax.

Und dann passen in ein Rack mit 6kW nicht mehr 16 Server mit Pmax = 375W, sondern 20 Server mit Pserv = 375W * 0,8 = 300W. Das sind 25% mehr Server. Das ist eine sehr große Einsparung – denn wir benötigen sofort 25% weniger Racks (da sparen wir auch bei PDU, Switches und Kabeln). Ein ernsthaftes Minus dieser Entscheidung ist, dass wir ständig überwachen müssen, ob unsere Annahmen weiterhin gültig sind. Ob die neue Firmware-Version die Funktionsweise der Lüfter und den Verbrauch nicht wesentlich verändert, ob die Entwicklung mit einem neuen Release plötzlich die Server deutlich effizienter nutzt (sprich, eine höhere Auslastung und einen höheren Verbrauch pro Server erreicht). Denn dann werden auch unsere ursprünglichen Annahmen und Schlussfolgerungen sofort falsch. Das ist ein Risiko, das verantwortungsbewusst angenommen (oder vermieden und dann für offensichtlich unterausgelastete Racks bezahlt) werden muss.

Wichtiger Hinweis – es ist ratsam, Server aus verschiedenen Diensten horizontal auf die Racks zu verteilen, wenn dies möglich ist. Dies ist notwendig, um zu vermeiden, dass eine Partie Server für einen Dienst ankommt und die Racks vertikal mit ihnen gefüllt werden, um die "Dichte" zu erhöhen (weil es einfacher ist). In der Realität führt dies dazu, dass ein Rack mit identischen, gering belasteten Servern eines Dienstes überfüllt ist, während ein anderes Rack mit gleichmäßig hoch belasteten Servern gefüllt ist. Die Wahrscheinlichkeit eines Ausfalls im zweiten Rack ist erheblich höher, da das Lastprofil identisch ist und alle Server gemeinsam in diesem Rack bei erhöhter Last gleich viel Strom verbrauchen.

Kommen wir zurück zur Verteilung der Server in den Racks. Wir haben die physikalischen Beschränkungen des Platzes im Rack und die Einschränkungen der Stromversorgung berücksichtigt; nun betrachten wir auch das Netzwerk. Man kann Switches mit 24/32/48 Ports N verwenden (zum Beispiel haben wir 48-Port ToR-Switches). Glücklicherweise sind die Möglichkeiten begrenzt, wenn man nicht über Breakout-Kabel nachdenkt. Wir betrachten Szenarien, in denen wir einen Switch pro Rack, einen Switch für zwei oder drei Racks in der Gruppe Rnet haben. Ich glaube, dass mehr als drei Racks in einer Gruppe bereits übertrieben ist, da das Verkabelungsproblem zwischen den Racks deutlich ansteigt.

Also verteilen wir die Server entsprechend jedem Netzwerk-Szenario (1, 2 oder 3 Racks in der Gruppe):

Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))

Somit für die Option mit 2 Racks in der Gruppe:

Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 Server pro Rack.

Ähnlich berechnen wir die anderen Optionen:

Srack1 = 20
Srack3 = 16

Und wir sind fast am Ziel. Lassen Sie uns die Anzahl der Racks zur Verteilung aller unserer Server S berechnen (nehmen wir 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

Als nächstes berechnen wir die TCO für jede Option auf der Grundlage der Anzahl der Racks, der erforderlichen Anzahl von Switches, Verkabelung usw. Wir wählen die Option mit der geringeren TCO. Profit!

Es ist zu beachten, dass obwohl die erforderliche Anzahl von Racks für die Optionen 1 und 2 identisch ist, deren Preis unterschiedlich sein wird, da die Anzahl der Switches für die zweite Option halb so groß ist, während die Länge der erforderlichen Kabel größer ist.

P.S. Wenn es die Möglichkeit gibt, die Leistung des Racks und die Höhe des Racks zu variieren, erhöht sich die Variabilität. Aber den Prozess kann man auf das oben Beschriebene reduzieren, indem man einfach verschiedene Optionen durchgeht. Ja, es wird mehr Kombinationen geben, aber trotzdem eine recht begrenzte Anzahl – die Leistung pro Rack kann in Schritten von 1 kW erhöht werden, übliche Racktypen sind in einer begrenzten Anzahl von Größen erhältlich: 42U, 45U, 47U, 48U, 52U. Hier kann die Excel-What-If-Analyse im Data Table-Modus hilfreich sein. Wir schauen uns die erhaltenen Tabellen an und wählen das Minimum aus.

Quelle: habr.com