In einem der Chats wurde mir eine Frage gestellt:
— Gibt es etwas zu lesen, wie man Server richtig in Racks verpackt?
Ich stellte fest, dass ich solchen Text nicht kenne, also schrieb ich meinen eigenen.
Zuerst einmal handelt dieser Text von physischen Servern in physischen Rechenzentren (RZ). Zweitens gehen wir davon aus, dass es genügend Server gibt: Hunderte bis Tausende, für eine geringere Anzahl macht dieser Text keinen Sinn. Drittens gehen wir davon aus, dass wir drei Einschränkungen haben: Der physische Platz in den Racks, die Stromversorgung pro Rack, und nehmen wir an, die Racks stehen in Reihen, sodass wir einen ToR-Switch verwenden können, um Server in benachbarten Racks zu verbinden.
Die Antwort auf die Frage hängt stark davon ab, welchen Parameter wir optimieren und was wir variieren können, um das bestmögliche Ergebnis zu erzielen. Zum Beispiel müssen wir möglicherweise nur den Platz minimieren, um mehr Raum für zukünftiges Wachstum zu lassen. Vielleicht haben wir auch die Freiheit, die Höhe der Racks, die Leistung pro Rack, die Steckdosen im PDU, die Anzahl der Racks in einer Switch-Gruppe (ein Switch für 1, 2 oder 3 Racks), die Länge der Kabel und die Verlegearbeiten zu wählen (das ist kritisch am Ende der Reihen: bei 10 Racks in einer Reihe und 3 Racks pro Switch müssen die Kabel in eine andere Reihe gezogen werden oder Ports im Switch bleiben ungenutzt), usw. usw. Einzelne Geschichten: Auswahl der Server und Auswahl des Rechenzentrums, nehmen wir an, dass diese bereits ausgewählt sind.
Es ist wichtig, einige Nuancen und Details zu verstehen, insbesondere den durchschnittlichen/maximalen Stromverbrauch von Servern und wie uns der Strom bereitgestellt wird. Wenn wir beispielsweise in Russland eine Stromversorgung von 230V und eine Phase pro Rack haben, kann ein 32A-Schutzschalter etwa 7kW halten. Angenommen, wir zahlen nominell für 6kW pro Rack. Wenn der Anbieter unseren Verbrauch nur für eine Reihe von 10 Racks misst und nicht für jedes Rack einzeln, und der Schutzschalter bei etwa 7kW liegt, dann könnten wir technisch gesehen in einem bestimmten Rack 6,9kW verbrauchen, in einem anderen 5,1kW, und es wäre alles in Ordnung — unverfolgt.
Normalerweise besteht unser Hauptziel darin, die Kosten zu minimieren. Das beste Kriterium zur Messung ist die Senkung der TCO (Total Cost of Ownership — Gesamtkosten der Eigentümerschaft). Diese setzt sich aus folgenden Bereichen zusammen:
- CAPEX: Anschaffung der Rechenzentrumsinfrastruktur, Server, Netzwerktechnologie und Verkabelung.
- OPEX: Miete des Rechenzentrums, verbrauchter Strom, Wartung. OPEX hängt von der Lebensdauer ab. Es ist vernünftig, ihn auf 3 Jahre zu schätzen.
Je nachdem, wie groß die einzelnen Teile im gesamten Kuchen sind, müssen wir das Teuerste optimieren, während der Rest alle verbleibenden Ressourcen so effizient wie möglich nutzt.
Angenommen, wir haben ein bestehendes Rechenzentrum, es gibt eine Rackhöhe H in Einheiten (zum Beispiel H=47), Stromversorgung pro Rack Prack (Prack=6kW), und wir haben uns entschieden, h=2U zweiHE-Server zu verwenden. Wir entfernen 2..4 Einheiten aus dem Rack für Switches, Patch-Panels und Organizer. Das bedeutet physisch, dass wir im Rack Sh=rounddown((H-2..4)/h) Server unterbringen können (d.h. Sh = rounddown((47-4)/2)=21 Server pro Rack). Merken wir uns dieses Sh.
Im einfachsten Fall sind alle Server im Rack identisch. Insgesamt, wenn wir das Rack vollstopfen Servern gearbeitet werden., können wir im Durchschnitt Pserv=Prack/Sh an Leistung für jeden Server aufwenden (Pserv = 6000W/21 = 287W). Zur Vereinfachung ignorieren wir hier den Stromverbrauch des Switches.
Lassen Sie uns einen Schritt zurücktreten und definieren, was der maximale Verbrauch eines Servers Pmax ist. Vereinfacht gesagt, sehr ineffizient und ganz sicher, schauen wir, was auf dem Netzteil des Servers steht – das ist es.
Wenn es komplizierter ist, effizienter, nehmen wir die TDP (Thermal Design Power) aller Komponenten und summieren diese (das ist nicht ganz korrekt, aber so kann man es auch tun).
Da wir normalerweise die TDP der Komponenten (außer der CPU) nicht kennen, verfolgen wir den präzisesten, aber auch kompliziertesten Ansatz (Labor erforderlich) – wir nutzen einen experimentellen Server mit der entsprechenden Konfiguration und belasten ihn beispielsweise mit Linpack (CPU und RAM) und fio (Festplatten), um den Verbrauch zu messen. Wenn wir es ernsthaft angehen wollen, sollten wir zudem eine möglichst warme Umgebung im kalten Flur während der Tests schaffen, da dies den Verbrauch der Lüfter und der CPU beeinflusst. Wir erhalten den maximalen Verbrauch eines bestimmten Servers mit einer konkreten Konfiguration unter diesen speziellen Bedingungen und bei dieser bestimmten Last. Beachten Sie einfach, dass ein neues System-Update, eine andere Softwareversion oder andere Bedingungen das Ergebnis beeinflussen können.
Zusammengefasst kehren wir zu Pserv zurück und überlegen, wie wir ihn mit Pmax vergleichen können. Das ist eine Frage des Verständnisses der Funktionsweise von Diensten und davon, wie stark die Nerven Ihres technischen Direktors sind.
Wenn man kein Risiko eingeht, nehmen wir an, dass alle Server gleichzeitig ihre maximale Leistung beanspruchen könnten. In diesem Moment könnte sich ein einziger Eingang im Rechenzentrum ergeben. Die Infrastruktur muss auch unter diesen Bedingungen einen Service bieten, daher gilt Pserv ≡ Pmax. Dies ist ein Ansatz, bei dem Zuverlässigkeit absolut wichtig ist.
Wenn der technische Direktor jedoch nicht nur an perfekter Sicherheit, sondern auch an den Finanzen des Unternehmens interessiert ist und ausreichend mutig ist, kann man zu dem Schluss kommen, dass
- wir beginnen, unsere Anbieter zu managen, insbesondere dass wir geplante Wartungsarbeiten während geplanter Spitzenlastzeiten verbieten, um den Rückgang eines Eingangs zu minimieren;
- und/oder unsere Architektur ermöglicht es, einen Rack/ eine Reihe/ ein Rechenzentrum zu verlieren, während die Services weiterlaufen;
- und/oder wir die Last horizontal über die Racks gut verteilen, sodass unsere Services niemals gleichzeitig auf den maximalen Verbrauch in einem Rack springen.
Es ist sehr nützlich, nicht nur zu spekulieren, sondern den Verbrauch zu überwachen und zu wissen, wie viel Strom Server unter normalen und Spitzenbedingungen tatsächlich verbrauchen. Nach einer gewissen Analyse fasst der Technische Direktor alles zusammen und sagt: „Wir entscheiden willentlich, dass das maximalkonforme Durchschnittsniveau der Serververbräuche pro Rack um **so viel** unter dem maximalen Verbrauch liegt”, vereinfacht gesagt Pserv=0.8*Pmax.
Und dann passen in das 6kW-Rack nicht mehr 16 Server mit Pmax = 375W, sondern 20 Server mit Pserv = 375W * 0.8 = 300W. Das sind also 25% mehr Server. Das ist eine erhebliche Einsparung — denn wir benötigen auch 25% weniger Racks (und damit sparen wir auch bei PDU, Switches und Kabeln). Ein ernsthafter Nachteil dieser Lösung ist, dass wir ständig überwachen müssen, ob unsere Annahmen weiterhin zutreffend sind. Ob die neue Firmware-Version die Funktion der Lüfter und den Verbrauch nicht wesentlich ändert, ob die Entwicklung mit dem neuen Release nicht plötzlich die Server viel effizienter nutzt (sprich, eine höhere Auslastung und einen höheren Verbrauch pro Server erreicht). Denn dann werden sowohl unsere ursprünglichen Annahmen als auch die Schlussfolgerungen sofort falsch. Das ist ein Risiko, das verantwortungsbewusst eingegangen werden muss (oder vermieden werden kann, wobei wir dann für offensichtlich unterausgelastete Racks zahlen müssen).
Wichtiger Hinweis – es ist ratsam, Server von verschiedenen Dienstleistungen horizontal in Racks zu verteilen, wenn möglich. Dies ist notwendig, um Situationen zu vermeiden, in denen eine Charge von Servern für einen Service kommt, und die Racks vertikal mit ihnen gefüllt werden, um die „Dichte“ zu erhöhen (weil das einfacher ist). In der Realität ist es jedoch so, dass ein Rack mit identischen, niedrig belasteten Servern eines Services vollgestopft ist, während ein anderes Rack mit gleichmäßig hoch belasteten Servern gefüllt ist. Die Wahrscheinlichkeit eines Ausfalls des zweiten Racks ist deutlich höher, da das Lastprofil identisch ist, und alle Server in diesem Rack beginnen, bei erhöhter Last gleich viel zu verbrauchen.
Kommen wir zurück zur Verteilung der Server in den Racks. Wir haben die physischen Platzbeschränkungen im Rack und die Einschränkungen der Stromversorgung betrachtet, nun werfen wir auch einen Blick auf das Netzwerk. Es können 24/32/48-Port-Switches N verwendet werden (zu Beispiel haben wir 48-Port-ToR-Switches). Glücklicherweise gibt es nicht viele Optionen, wenn man nicht über Break-out-Kabel nachdenkt. Wir betrachten Szenarien, in denen wir einen Switch pro Rack, einen Switch für zwei oder drei Racks in der Rnet-Gruppe haben. Mehr als drei Racks in einer Gruppe scheinen mir zu viel, da das Kabelmanagement zwischen den Racks deutlich komplexer wird.
Für jedes Netzwerkszenario (1, 2 oder 3 Racks in der Gruppe) verteilen wir die Server auf die Racks:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Für das Szenario mit 2 Racks in der Gruppe:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 Server pro Rack.
Ebenso berechnen wir die anderen Optionen:
Srack1 = 20
Srack3 = 16
Und wir sind fast am Ziel. Lassen Sie uns die Anzahl der Racks für die Verteilung all unserer Server S (nehmen wir 1000 an) berechnen:
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
Im Folgenden berechnen wir die TCO für jede Option basierend auf der Anzahl der benötigten Racks, der erforderlichen Anzahl von Switches, Verkabelung usw. Wir wählen die Option mit der geringsten TCO. Profit!
Beachten wir, dass die erforderliche Anzahl der Racks für die Optionen 1 und 2 gleich ist, ihre Kosten jedoch unterschiedlich sein werden, da die Anzahl der Switches für die zweite Option halb so hoch ist und die Länge der benötigten Kabel länger.
P.S. Wenn es möglich ist, die Leistung pro Rack und die Rackhöhe zu variieren, erhöht sich die Variabilität. Der Prozess kann jedoch auf das oben Beschriebene reduziert werden, indem die Optionen einfach durchgegangen werden. Ja, es wird mehr Kombinationen geben, aber dennoch eine sehr begrenzte Anzahl — die Stromversorgung pro Rack zur Berechnung kann in Schritten von 1 kW erhöht werden, typische Racks sind in einer begrenzten Anzahl von Größen erhältlich: 42U, 45U, 47U, 48U, 52U. Und hier kann die Excel-Wenn-Dann-Analyse im Datenblatt-Modus hilfreich sein. Wir schauen uns die erhaltenen Tabellen an und wählen das Minimum.
Quelle: habr.com
