Na jednym z czatów zadano mi pytanie:
— Czy jest coś, co mogę przeczytać na temat prawidłowego pakowania serwerów w szafy?
Zorientowałem się, że nie znam takiego tekstu, więc napisałem własny.
Po pierwsze, ten tekst dotyczy serwerów fizycznych w fizycznych centrach danych (DC). Po drugie, uważamy, że serwerów jest całkiem sporo: setki tysięcy, dla mniejszej liczby ten tekst nie ma sensu. Po trzecie, uważamy, że mamy trzy ograniczenia: fizyczną przestrzeń w szafach, zasilanie każdej szafy i ustawienie szaf w rzędach, abyśmy mogli użyć jednego przełącznika ToR do połączenia serwerów w sąsiednich szafach.
Odpowiedź na pytanie w dużej mierze zależy od tego, jaki parametr optymalizujemy i co możemy zmieniać, aby uzyskać najlepszy wynik. Na przykład musimy po prostu zająć minimum miejsca, aby pozostawić więcej na dalszy rozwój. A może mamy dowolność w doborze wysokości szaf, mocy na szafę, gniazd w PDU, ilości szaf w grupie przełączników (jeden przełącznik na 1, 2 lub 3 szafy), długości przewodów i pracy ciągnącej ( ma to kluczowe znaczenie na końcach rzędów: przy 10 szafach w rzędzie i 3 szafach na przełącznik, konieczne będzie przeciągnięcie przewodów do innego rzędu lub niedostateczne wykorzystanie portów w przełączniku) itp. itp. Osobne historie: wybór serwerów i wybór DC, założymy, że są one wybrane.
Dobrze byłoby zrozumieć niektóre niuanse i szczegóły, w szczególności średnie/maksymalne zużycie serwerów i sposób dostarczania nam prądu. Jeśli więc mamy rosyjski zasilacz o napięciu 230 V i jednej fazie na szafę, wówczas maszyna 32 A może obsłużyć ~7 kW. Załóżmy, że nominalnie płacimy za 6 kW na szafę. Jeśli dostawca mierzy nasze zużycie tylko dla rzędu 10 szaf, a nie dla każdego stojaka, i jeśli maszyna jest ustawiona na warunkową wartość odcięcia 7 kW, to technicznie rzecz biorąc, możemy zużyć 6.9 kW w jednym stojaku, 5.1 kW w drugim i wszystko będzie dobrze - nie podlega karze.
Zwykle naszym głównym celem jest minimalizacja kosztów. Najlepszym kryterium do pomiaru jest redukcja TCO (całkowitego kosztu posiadania). Składa się z następujących elementów:
- CAPEX: zakup infrastruktury DC, serwerów, sprzętu sieciowego i okablowania
- OPEX: wynajem prądu stałego, zużycie energii elektrycznej, konserwacja. OPEX zależy od żywotności. Rozsądnie jest przyjąć, że będą to 3 lata.
W zależności od tego, jak duże są poszczególne elementy całego tortu, musimy zoptymalizować najdroższy i pozwolić reszcie wykorzystać wszystkie pozostałe zasoby tak efektywnie, jak to możliwe.
Załóżmy, że mamy istniejący DC, wysokość szafy wynosi H jednostek (na przykład H=47), energia elektryczna na szafę Prack (Prack=6kW) i zdecydowaliśmy się zastosować dwujednostkowe serwery h=2U. Z stojaka na przełączniki, patch panele i organizery usuniemy 2..4 jednostki. Te. fizycznie w naszej szafie mamy serwery Sh=zaokrąglenie((H-2..4)/h) (tj. Sh=zaokrąglenie((47-4)/2)=21 serwerów na szafę). Pamiętajmy o tym Sz.
W prostym przypadku wszystkie serwery w szafie są identyczne. W sumie, jeśli zapełnimy szafę serwerami, to na każdym serwerze możemy przeznaczyć średnio moc Pserv=Prack/Sh (Pserv=6000W/21=287W). Dla uproszczenia ignorujemy tutaj zużycie przełącznika.
Odejdźmy na bok i ustalmy jakie jest maksymalne zużycie serwera Pmax. Jeśli jest to bardzo proste, bardzo nieskuteczne i całkowicie bezpieczne, to czytamy, co jest napisane na zasilaczu serwera - to jest to.
Jeśli jest to bardziej skomplikowane, wydajniejsze, to bierzemy TDP (pakiet projektowania termicznego) wszystkich podzespołów i podsumowujemy (nie jest to do końca prawdą, ale jest to możliwe).
Zwykle nie znamy TDP komponentów (poza procesorem), więc przyjmujemy najbardziej poprawne, ale i najbardziej złożone podejście (potrzebujemy laboratorium) - bierzemy eksperymentalny serwer o wymaganej konfiguracji i ładujemy go, na przykład za pomocą Linpack (procesor i pamięć) i fio (dyski) mierzymy zużycie. Jeśli podchodzimy do tego poważnie, podczas testów musimy również stworzyć najcieplejsze środowisko w zimnym korytarzu, ponieważ wpłynie to zarówno na zużycie wentylatora, jak i zużycie procesora. Otrzymujemy maksymalne zużycie konkretnego serwera o określonej konfiguracji w tych konkretnych warunkach przy tym konkretnym obciążeniu. Mamy na myśli po prostu to, że nowe oprogramowanie systemowe, inna wersja oprogramowania i inne warunki mogą mieć wpływ na wynik.
Wróćmy więc do Pserv i porównania go z Pmax. To kwestia zrozumienia, jak działają te usługi i jak mocne są nerwy dyrektora technicznego.
Jeśli w ogóle nie podejmiemy żadnego ryzyka, wierzymy, że wszystkie serwery mogą jednocześnie zacząć zużywać maksimum. W tym samym momencie może nastąpić jedno wejście na DC. Nawet w tych warunkach infrastruktura musi świadczyć usługi, więc Pserv ≡ Pmax. Jest to podejście, w którym niezawodność jest absolutnie ważna.
Jeśli dyrektor techniczny myśli nie tylko o idealnym bezpieczeństwie, ale także o pieniądzach firmy i jest na tyle odważny, to możesz tak zdecydować
- Zaczynamy zarządzać naszymi dostawcami, w szczególności zabraniamy planowych konserwacji w godzinach planowanego szczytowego obciążenia, aby zminimalizować spadek na jednym wejściu;
- i/lub nasza architektura pozwala na utratę szafy/rzędu/DC, ale usługi nadal działają;
- i/lub dobrze rozkładamy ładunek poziomo na regałach, dzięki czemu nasze usługi nigdy nie osiągną maksymalnego zużycia w jednym stojaku razem wziętym.
W tym przypadku bardzo przydatne jest nie tylko zgadywanie, ale także monitorowanie zużycia i wiedza, w jaki sposób serwery faktycznie zużywają energię elektryczną w warunkach normalnych i szczytowych. Dlatego po pewnej analizie dyrektor techniczny wyciska wszystko, co ma i mówi: „podejmujemy dobrowolną decyzję, że maksymalna osiągalna średnia maksymalnego zużycia serwera na szafę jest **o wiele** niższa od maksymalnego zużycia”, warunkowo Pserv = 0.8* Pmaks.
A wtedy w szafie o mocy 6 kW nie można już umieścić 16 serwerów o mocy Pmax = 375 W, ale 20 serwerów o mocy Pserv = 375 W * 0.8 = 300 W. Te. 25% więcej serwerów. To bardzo duża oszczędność – wszak od razu potrzebujemy o 25% mniej szaf (oszczędzimy też na listwach PDU, przełącznikach i kablach). Poważną wadą takiego rozwiązania jest to, że musimy stale monitorować, czy nasze założenia są nadal słuszne. Że nowa wersja firmware nie zmienia znacząco pracy wentylatorów i zużycia, że rozwój nagle wraz z nową wersją nie zaczął znacznie wydajniej wykorzystywać serwerów (czytaj: osiągnęły większe obciążenie i większe zużycie na serwerze). Przecież wtedy zarówno nasze początkowe założenia, jak i wnioski natychmiast stają się błędne. Jest to ryzyko, które należy podjąć odpowiedzialnie (lub uniknąć, a następnie zapłacić za wyraźnie niewykorzystane regały).
Ważna uwaga - jeśli to możliwe, powinieneś spróbować rozmieścić serwery z różnych usług poziomo w szafach. Jest to konieczne, aby nie dochodziło do sytuacji, gdy na jedną usługę przyjeżdża jedna partia serwerów, regały są nim upakowane pionowo w celu zwiększenia „zagęszczenia” (bo tak jest łatwiej). W rzeczywistości okazuje się, że jedna szafa jest wypełniona identycznymi serwerami o niskim obciążeniu tej samej usługi, a druga jest wypełniona serwerami o równie dużym obciążeniu. Prawdopodobieństwo drugiego upadku jest znacznie wyższe, ponieważ profil obciążenia jest taki sam i wszystkie serwery razem w tej szafie zaczynają zużywać tę samą ilość w wyniku zwiększonego obciążenia.
Wróćmy do dystrybucji serwerów w szafach. Przyjrzeliśmy się fizycznej przestrzeni w szafie i ograniczeniom mocy, teraz przyjrzyjmy się sieci. Można używać przełączników z portami 24/32/48 N (na przykład mamy 48-portowe przełączniki ToR). Na szczęście nie ma zbyt wielu opcji, jeśli nie myślisz o kablach typu break-out. Rozważamy scenariusze, w których mamy jeden przełącznik na szafę, jeden przełącznik na dwie lub trzy szafy w grupie Rnet. Wydaje mi się, że więcej niż trzy stojaki w grupie to już za dużo, bo... problem okablowania pomiędzy szafami staje się znacznie większy.
Zatem dla każdego scenariusza sieciowego (1, 2 lub 3 szafy w grupie) rozdzielamy serwery pomiędzy szafy:
Srack = min(Sh, zaokrąglenie w dół (Prack/Pserv), zaokrąglenie w dół (N/Rnet))
Zatem dla opcji z 2 stojakami w grupie:
Srack2 = min(21, zaokrąglenie w dół (6000/300), zaokrąglenie w dół (48/2)) = min(21, 20, 24) = 20 serwerów na szafę.
Pozostałe opcje rozważamy w ten sam sposób:
Srack1 = 20
Srack3 = 16
I już prawie jesteśmy na miejscu. Liczymy liczbę stojaków do rozmieszczenia wszystkich naszych serwerów S (niech będzie 1000):
R = łapanka(S / (Srack * Rnet)) * Rnet
R1 = zaokrąglenie (1000 / (20 * 1)) * 1 = 50 * 1 = 50 stojaków
R2 = zaokrąglenie (1000 / (20 * 2)) * 2 = 25 * 2 = 50 stojaków
R3 = zaokrąglenie (1000 / (16 * 3)) * 3 = 25 * 2 = 63 stojaki
Następnie obliczamy TCO dla każdej opcji na podstawie liczby szaf, wymaganej liczby przełączników, okablowania itp. Wybieramy opcję, w której TCO jest niższe. Zysk!
Należy pamiętać, że chociaż wymagana liczba stojaków dla opcji 1 i 2 jest taka sama, ich cena będzie inna, ponieważ liczba przełączników dla drugiej opcji jest o połowę mniejsza, a długość wymaganych kabli jest dłuższa.
PS Jeśli masz możliwość pobawienia się mocą przypadającą na szafę i wysokością szafy, zmienność wzrasta. Ale proces można zredukować do opisanego powyżej, po prostu przeglądając opcje. Tak, kombinacji będzie więcej, ale nadal bardzo ograniczona liczba - moc zasilania szafy do obliczeń można zwiększać w krokach co 1 kW, typowe szafy występują w ograniczonej liczbie standardowych rozmiarów: 42U, 45U, 47U, 48U , 52U. I tutaj analiza typu „co-jeśli” programu Excel w trybie tabeli danych może pomóc w obliczeniach. Przyglądamy się otrzymanym talerzom i wybieramy minimum.
Źródło: www.habr.com