W jednym z czatów zadano mi pytanie:
— Czy jest coś do przeczytania na temat właściwego pakowania serwerów w szafach?
Zdałem sobie sprawę, że nie wiem nic na ten temat, więc napisałem swoją wersję.
Po pierwsze, ten tekst dotyczy serwerów fizycznych w fizycznych centrach danych (DC). Po drugie, zakładamy, że mamy wystarczającą liczbę serwerów: setki lub tysiące, dla mniejszej ilości ten tekst nie ma sensu. Po trzecie, zakładamy, że mamy trzy ograniczenia: fizyczne miejsce w szafach, zasilanie na szafę i niech szafy stoją w rzędach, dzięki czemu możemy użyć jednego przełącznika ToR do podłączenia serwerów w sąsiednich szafach.
Odpowiedź na to pytanie zależy od tego, jaki parametr optymalizujemy i co możemy zmieniać, aby uzyskać najlepszy rezultat. Na przykład, być może musimy zająć jak najmniej miejsca, aby zostawić więcej na przyszły rozwój. A może mamy swobodę wyboru wysokości szaf, mocy na szafę, gniazdek w PDU, liczby szaf w grupie przełączników (jeden przełącznik na 1, 2 lub 3 szafy), długości kabli i prac związanych z ich prowadzeniem (to jest krytyczne na końcach rzędów: przy 10 szafach w rzędzie i 3 szafach na przełącznik trzeba będzie ciągnąć kable do innego rzędu lub niewykorzystywać portów w przełączniku), itd., itd. Oddzielne kwestie to: wybór serwerów i wybór DC, przyjmijmy, że zostały one już dokonane.
Dobrze byłoby zrozumieć niektóre niuanse i szczegóły, w szczególności średnie/maksymalne zużycie serwerów oraz sposób, w jaki dostarczane jest nam zasilanie. Tak więc, jeśli mamy rosyjskie zasilanie 230V i jedną fazę na szafę, to automat 32A może utrzymać ~7kW. Załóżmy, że nominalnie płacimy za 6kW na szafę. Jeśli dostawca mierzy nasze zużycie tylko dla rzędu z 10 szafami, a nie dla każdej szafy, i jeśli automat jest ustawiony na poziomie teoretycznie 7kW, to technicznie możemy w pojedynczej szafie pobierać 6.9kW, w innej 5.1kW i wszystko będzie w porządku — niewykrywalnie.
Zwykle naszym głównym celem jest minimalizacja wydatków. Najlepszym wskaźnikiem do pomiaru jest obniżenie TCO (całkowity koszt posiadania). Składa się on z następujących elementów:
- CAPEX: zakup infrastruktury DC, serwerów, sprzętu sieciowego i okablowania
- OPEX: wynajem DC, zużycie energii, serwis. OPEX zależy od okresu eksploatacji. Rozsądnie przyjąć, że wynosi on 3 lata.
W zależności od tego, jak duże są poszczególne kawałki w ogólnym cieście, musimy zoptymalizować to, co najbardziej kosztowne, a reszta niech wykorzystuje wszystkie pozostałe zasoby jak najbardziej efektywnie.
Załóżmy, że mamy już istniejące centrum danych, mamy wysokość szafy H jednostek (dla przykładu H=47), moc na szafę Prack (Prack=6kW), a zdecydowaliśmy się użyć serwerów 2U h=2U. Usuniemy 2..4 jednostek ze szafy na przełączniki, panele krosowe i organizatory. Tzn. fizycznie w naszej szafie mieści się Sh=rounddown((H-2..4)/h) serwerów (tzn. Sh = rounddown((47-4)/2)=21 serwer na szafę). Zapamiętajmy to Sh.
W prostym przypadku wszystkie serwery w szafie są identyczne. Zatem, jeśli zapełnimy szafę serwerami, to na każdy serwer będziemy mogli średnio przeznaczyć moc Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Dla uproszczenia ignorujemy tutaj zużycie przełącznika.
Zróbmy krok w bok i określmy, czym jest maksymalne zużycie serwera Pmax. Mówiąc bardzo prosto, bardzo nieefektywnie i całkowicie bezpiecznie, to czytamy, co jest napisane na zasilaczu serwera — to właśnie ono.
Jeśli mówimy o bardziej skomplikowanej kwestii, bardziej efektywnie, to bierzemy TDP (thermal design package) wszystkich komponentów i sumujemy (to nie jest do końca prawda, ale można tak zrobić).
Zwykle nie znamy TDP komponentów (oprócz CPU), dlatego przyjmujemy najbardziej poprawne, ale także najbardziej skomplikowane podejście (potrzebne jest laboratorium) — bierzemy eksperymentalny serwer o wymaganej konfiguracji i obciążamy go, na przykład Linpackiem (CPU i pamięć) oraz fio (dyski), mierzymy zużycie. Jeśli podchodzimy do tego poważnie, trzeba także stworzyć najbardziej ciepłe środowisko w zimnym korytarzu podczas testów, ponieważ ma to wpływ zarówno na zużycie wentylatorów, jak i na zużycie CPU. Uzyskujemy maksymalne zużycie konkretnego serwera w konkretnej konfiguracji w tych konkretnych warunkach pod tym konkretnym obciążeniem. Po prostu miejmy na uwadze, że nowa wersja oprogramowania, inna wersja oprogramowania, inne warunki mogą wpłynąć na wynik.
Wracając do Pserv, jak porównać go z Pmax. To pytanie dotyczy zrozumienia działania usług i tego, jak mocne nerwy ma twój dział techniczny.
Jeśli nie chcemy ryzykować, załóżmy, że wszystkie serwery mogą nagle zacząć pobierać swój maksymalny udział. W tym samym momencie mogą zostać podłączone jednocześnie do centrum danych. Infrastruktura w tych warunkach powinna zapewniać usługi, stąd Pserv ≡ Pmax. To podejście, w którym absolutnie kluczowa jest niezawodność.
Jeśli dyrektor techniczny myśli nie tylko o idealnym bezpieczeństwie, ale także o finansach firmy i jest wystarczająco odważny, można stwierdzić, że
- zaczynamy zarządzać naszymi dostawcami, a w szczególności zabraniać przeprowadzania planowej konserwacji w momentach przewidywanego szczytu obciążenia, aby zminimalizować spadek jednego wejścia;
- i/lub nasza architektura pozwala na utratę stelaża/rzędów/DCS, a usługi nadal działają;
- i/lub dobrze rozkładamy obciążenie poziomo na stelażach, dlatego nasze usługi nigdy nie skaczą do maksymalnego zużycia w jednym stelażu wszystkie razem.
W tym przypadku bardzo ważne jest, aby nie tylko zgadywać, ale monitorować zużycie i wiedzieć, jak w rzeczywistości serwery pobierają energię w normalnych i szczytowych warunkach. Dlatego po pewnej analizie dyrektor techniczny zwęża wszystko, co ma, i mówi: „przyjmujemy decyzją, że maksymalnie osiągalne średnie z maksymalnych zużyć serwerów na stelaż wynosi **tyle-czy-ile** mniej niż maksymalne zużycie”, umownie Pserv=0.8*Pmax.
I wtedy w stelażu na 6 kW mieści się już nie 16 serwerów z Pmax = 375 W, a 20 serwerów z Pserv = 375 W * 0.8 = 300 W. To oznacza 25% więcej serwerów. To bardzo duża oszczędność — potrzebujemy mniej stelaży o 25% (a tam również oszczędzimy na PDU, switchach i kablach). Poważnym minusem takiego rozwiązania jest to, że musimy na bieżąco monitorować, czy nasze założenia nadal są prawdziwe. Czy nowa wersja oprogramowania nie zmienia w znaczący sposób pracy wentylatorów i zużycia, czy rozwój nagle z nowym wydaniem nie zaczął wykorzystywać serwerów znacznie efektywniej (czytaj — osiągnięto większe obciążenie i większe zużycie na serwer). W przeciwnym razie nasze początkowe założenia i wnioski natychmiast stają się fałszywe. To ryzyko, które należy odpowiedzialnie podejmować (lub unikać, a wtedy płacić za oczywiście niedoładowane stelaże).
Ważna uwaga — warto starać się rozdzielać serwery z różnych usług w szafach poziomo, jeśli to możliwe. Jest to potrzebne, aby uniknąć sytuacji, w której jedna partia serwerów dla jednej usługi przychodzi, a szafy są pionowo zapełnione w celu zwiększenia 'gęstości' (ponieważ jest to prostsze). W rzeczywistości okazuje się, że jedna szafa jest wypełniona identycznymi, mało obciążonymi serwerami jednej usługi, a inna — identycznie wysokoobciążonymi. Prawdopodobieństwo awarii drugiej jest znacznie wyższe, ponieważ profil obciążenia jest taki sam, a wszystkie serwery razem w tej szafie zaczynają zużywać podobnie dużo w wyniku zwiększonego obciążenia.
Wracając do rozdziału serwerów w szafach. Rozważyliśmy fizyczne ograniczenia dotyczące miejsca w szafie oraz ograniczenia związane z zasilaniem, teraz przyjrzyjmy się sieci. Można używać przełączników na 24/32/48 portów N (dla przykładu mamy przełączniki ToR na 48 portów). Na szczęście możliwości nie jest zbyt wiele, jeśli nie myślimy 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. Uważam, że więcej niż trzy szafy w grupie to już przesada, ponieważ problem okablowania między szafami staje się znacznie większy.
Zatem dla każdego scenariusza sieciowego (1, 2 lub 3 szafy w grupie) rozdzielamy serwery po szafach:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Zatem dla opcji z 2 szafami w grupie:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 serwerów na szafę.
Analogicznie obliczamy pozostałe opcje:
Srack1 = 20
Srack3 = 16
I jesteśmy prawie na celu. Liczymy liczbę szaf do rozdzielenia wszystkich naszych serwerów S (niech będzie 1000):
R = roundup(S / (Srack * Rnet)) * Rnet
R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 szaf
R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 szaf
R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 szafy
Następnie obliczamy TCO dla każdej opcji na podstawie liczby szaf, wymaganej liczby przełączników, okablowania itd. Wybieramy tę opcję, gdzie TCO jest mniejsze. Zysk!
Zauważmy, że chociaż wymagana liczba szaf dla opcji 1 i 2 jest taka sama, ich cena będzie różna, ponieważ liczba przełączników w drugim wariancie jest dwukrotnie mniejsza, a długość wymaganych kabli jest większa.
P.S. Jeśli istnieje możliwość zabawy z mocą szafki i wysokością szafki, zmienność się zwiększa. Ale proces można sprowadzić do powyżej opisanego, po prostu przeglądając opcje. Tak, kombinacji będzie więcej, ale wciąż będzie to dość ograniczona liczba — zasilanie na szafkę można zwiększać co 1 kW, typowe szafki występują w ograniczonej liczbie rozmiarów: 42U, 45U, 47U, 48U, 52U. A tutaj w obliczeniach może pomóc analiza scenariuszy Excela w trybie Tabeli danych. Patrzymy na uzyskane tabelki i wybieramy minimum.
Źródło: habr.com
