Jak zbudować najmniej wydajne centrum danych

Co budujesz

Każdy poradnik na tej stronie uczy, jak robić coś poprawnie: polecenia są w odpowiedniej kolejności, opisano prawidłowy wynik oraz typowe błędy. Ten poradnik jest inny. Dzisiaj, czysto hipotetycznie, zaprojektujemy najmniej wydajne centrum danych, jakie mogą wygenerować pieniądze, energia elektryczna i pycha.

Potrzebujemy metryki, więc pożyczymy własną z branży: PUE, Power Usage Effectiveness — całkowita moc obiektu podzielona przez moc, która faktycznie dociera do sprzętu obliczeniowego. Hyperscale datacenter osiąga około 1.1: prawie każdy wat wykonuje użyteczną pracę. Porządna serwerownia korporacyjna osiąga 1.5. Naszym celem jest 4.0 lub więcej, co oznacza, że na każdy wat obliczeń przypadają trzy dodatkowe waty marnowane na nic. Będziemy często odwoływać się do tej liczby, tak jak poważne poradniki odwołują się do kopii zapasowych.

Wybór lokalizacji: kluczowe jest ciepło

Chłodzenie to największy koszt operacyjny w prawdziwym centrum danych, dlatego nasze będzie walczyć z termodynamiką na jej własnym polu bitwy. Idealną lokalizacją jest strych. Z oknem południowym. Najlepiej z świetlikiem ustawionym tak, aby świecił bezpośrednio na serwer, dzięki czemu maszyna otrzymuje zarówno własne ciepło odpadowe, jak i ciepło słoneczne – współpracę rachunku za prąd z gwiazdą.

Zimą chłodzenie odbywa się poprzez otwarcie okna. Prawdziwe centra danych również wykorzystują powietrze zewnętrzne — technika ta nazywa się free cooling i jest poddawana procesom inżynieryjnym, filtrowaniu oraz kontroli wilgotności. My wykorzystamy ją przypadkowo, przez okno, przez które wpada również deszcz, pyłki i co kwartał przynajmniej jeden zagubiony ptak.

Dla osiągnięcia prawdziwego kunsztu należy zainstalować klimatyzator, a następnie umieścić grzejnik elektryczny dwa stopy od jego termostatu, ustawiając go o dwa stopnie cieplej niż docelowa temperatura klimatyzatora. Obie maszyny będą teraz pracować nieprzerwanie, na zawsze, w stanie permanentnego konfliktu. Firma energetyczna wyśle wam kartkę z życzeniami na Boże Narodzenie.

Jeden serwer, duży i ukochany

Redundancja rozmywa zaangażowanie. Nasze centrum danych zawiera dokładnie jeden serwer, a jest on ogromny, ponieważ pojedyncza maszyna z 512 GB RAM sprawia wrażenie infrastruktury, podczas gdy cztery małe sprawiają wrażenie listy zadań do wykonania.

Serwer ma imię. Nie nazwę hosta — imię. Zazwyczaj Gandalf lub Odin. Nie można wycofać Odina z eksploatacji. Odin działa nieprzerwanie od pięciu lat:

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 6.41, 6.38, 6.40

Ta liczba jest powodem do dumy, dlatego robi się jej zrzut ekranu i publikuje w sieci, oraz dlatego każdy atakujący, który zobaczy ten zrzut ekranu, również uzna go za imponujący: 1,847 dni uptime'u oznacza 1,847 dni podatności jądra systemu, których nikt nie załatał. Restartowanie nie wchodzi w grę — restart to sposób na odkrycie, które usługi zostały uruchomione ręcznie w 2021 roku i nigdy nie zostały zapisane jako jednostka systemd. Nikt nie pamięta, które to usługi. Serwer stał się obecnie kluczowym elementem struktury organizacyjnej.

Przechowywanie danych: szybkość i inne sposoby na utratę danych

Dyski są skonfigurowane w RAID 0 w celu uzyskania wydajności. Zero odnosi się do liczby dysków, które mogą ulec awarii. Dla uzyskania maksymalnego efektu należy stworzyć macierz na nośnikach o różnym pochodzeniu: dwa właściwe dyski SSD, jeden zużyty dysk talerzowy i pendrive z konferencji. Macierz jest dokładnie tak niezawodna, jak pendrive z konferencji, co jest zamierzonym projektem.

Kopie zapasowe są obsługiwane przez katalog na tej samej macierzy o nazwie backup_final_v2_REAL, który zawiera archiwum tarball z poprzednim schematem nazewnictwa. Kopie off-site są reprezentowane przez żółtą karteczkę z napisem "skonfiguruj kopie off-site", która technicznie jest przechowywana poza lokalizacją, gdy zabierzesz ją do domu na klapie laptopa.

Prawidłowy wynik to: df raportujący 97% użycia oraz plan radzenia sobie z tym w następnym sprincie.

Sieciowanie: pojedyncza nitka wszystkiego

Serwer DNS działa na tej samej maszynie, więc gdy serwer padnie, zabierze ze sobą rekord DNS, którego użyłbyś do sprawdzenia przyczyny awarii. Nazywa się to konsolidacją.

Firewall został wyłączony w 2021 roku — tymczasowo, aby zdebugować coś. Debugowanie zakończono; firewall nie wrócił. Każdy port na routerze jest przekierowany na serwer "aby zaoszczędzić czas później", a panel administracyjny routera jest dostępny z sieci WAN z fabrycznym hasłem, dla wygody zdalnego zarządzania. Twojego oraz innych.

Serwer działa ostatnio nienaturalnie ciepło, nawet jak na standardy strychu, a top pokazuje, że najbardziej obciążonym procesem jest coś o nazwie xmrig. Zakładamy, że jest to narzędzie monitorujące, którego używamy. Nie zainstalowaliśmy go — pojawiło się samo krótko po przekierowaniu portów, co uznajemy za znak, że ekosystem rozkwita. Monitoruje system przez całą dobę.

Zasilanie dociera przez łańcuch domowych listew zasilających, których łączna długość przekracza odległość do rozdzielni elektrycznej — co jest efektywne w pewnym sensie, ponieważ będziesz często odwiedzać rozdzielnię.

Redundancja poprzez złożoność

Odrzuciwszy redundancję tam, gdzie jest ważna, dodajemy ją tam, gdzie nie jest potrzebna. Strona główna firmy — jeden statyczny plik HTML — jest obsługiwana przez dwunastowęzłowy klaster Kubernetes. Pozwala to osiągnąć to, co inżynierowie nazywają architekturą napędzaną przez CV: strona ładuje się w tym samym czasie 40 ms, w którym dostarczyłby ją nginx, ale może teraz ulec awarii w sposób wymagający konsultanta.

Dla zapewnienia izolacji sam klaster działa wewnątrz maszyny wirtualnej wewnątrz maszyny wirtualnej wewnątrz maszyny wirtualnej, gdzie każda warstwa dodaje bezpieczeństwa w taki sposób, w jaki każda warstwa potrawki turducken dodaje mięsa. Formularz kontaktowy składa się z dziewięciu mikroserwisów. Dwa z nich nigdy nie zostały wywołane. Jeden z nich jest kluczowy dla działania systemu i nikt nie wie który.

Ogrzewanie jako usługa

Nowoczesny serwer przekształca energię elektryczną w obliczenia i ciepło, a my zamierzamy zmaksymalizować ten drugi produkt. Serwer multimedialny bez GPU to klasyczne rozwiązanie: CPU-transcoding pojedynczego strumienia 4K obciąży szesnaście rdzeni i ogrzeje małą sypialnię — grzejnik elektryczny, który jednocześnie odtwarza filmy. Ambitni operator przechodzi na uruchamianie dużego modelu językowego na CPU — grzejnik o 70 miliardach parametrów z interfejsem API, generujący tokeny w tempie, które najlepiej mierzyć sezonowo.

Monitor obserwuje samego siebie

Obserwowalność (observability) jest ważna, więc wdrażamy self-hosted uptime monitor — na tym samym serwerze, który monitoruje. Gdy Odin umiera, monitor umiera wraz z nim, i tu pojawia się elegancki element: żadne alerty nie zostają wygenerowane. Brak alertów oznacza brak incydentów. Brak incydentów oznacza idealny uptime, według pomiarów. Miesięczny raport nigdy nie wyglądał lepiej.

Emaile z alertami, dla kompletności, są przekazywane przez serwer poczty, który również działa na Odin. Pipeline alertowania jest zatem w pełni samowystarczalny, w taki sposób, w jaki wąż pożerający własny ogon jest w pełni nasycony.

Trudna część

Oto sekcja, którą odkładałem. Nic z tego nie jest fikcją. Ukochany, niezastąpiony serwer, RAID 0 z kopiami zapasowymi na tej samej wolumenie, firewall wyłączony "tymczasowo", klaster Kubernetes obsługujący jedną stronę, monitor obserwujący samego siebie — widziałem każdy z tych przypadków w środowisku produkcyjnym. Niektóre z nich widziałem w tym roku. Jeden lub dwa z nich zbudowałem na początku mojej kariery.

Prawdziwa wydajność jest nudna, dlatego przegrywa argumentację w krótkim terminie, ale wygrywa ją w skali dekady: PUE, o którym nigdy nie myślisz, ponieważ ktoś inny zaprojektował je optymalnie. Maszyny dobrane do obciążenia, a nie do wizerunku właściciela. Promień rażenia (blast radius) rozważany przed wybuchem. Kopie zapasowe testowane poprzez przywracanie ich, zgodnie z harmonogramem, z przypomnieniem w kalendarzu i bez heroizmu. Redundancja, która jest nudna — dwie tanie rzeczy wygrywają z jedną wspaniałą w każdym przypadku, w każdej awarii, o której kiedykolwiek otrzymałem powiadomienie.

A najbardziej wydajne centrum danych, jakie możesz prowadzić, to takie, którego nie prowadzisz. VPS przekazuje moc, chłodzenie, redundancję i awarie sprzętowe o 3 rano ludziom, którzy robią to na dużą skalę i w nudny sposób, co jest najwyższym komplementem, jaki może otrzymać infrastruktura — a Tobie zostawia naprawdę zabawną część, czyli uruchamianie własnych usług na jego szczycie, na maszynie, którą możesz pozwolić sobie stracić, co jest jedynym rodzajem sprzętu, na którym należy eksperymentować.

FAQ

Czy powinienem to faktycznie robić?

Nie. Każda sekcja tego poradnika to udokumentowany antywzorzec, który kosztował wiele nieprzespanych weekendów. Jeśli Twoja obecna konfiguracja przypomina więcej niż dwie sekcje, przejdź do ostatniego pytania w tym FAQ — w podanej kolejności, ponieważ kolejność ta stanowi triage.

Jaki jest właściwie dobry PUE?

Hyperscale datacenters osiągają około 1.1, dobrze zarządzana sala korporacyjna osiąga od 1.4 do 1.6, a niechłodzona szafa z konfliktem grzejników może szczerze przekroczyć 3. Nie można sensownie konkurować z 1.1 w domu, co jest cichym argumentem ekonomicznym za wynajmowaniem mocy obliczeniowej od podmiotów, które potrafią to robić.

Czy ogrzewanie budynku serwerami to realna rzecz?

Tak — jeśli robi się to właściwie. Projekty ciepłownictwa miejskiego w kilku krajach przechwytują ciepło odpadowe z centrów danych przez wymienniki ciepła i przesyłają je do domów, zgodnie z projektem, inżynierią i kontraktami. Powyższa satyra nie polega na tym, że ciepło z serwerów może ogrzać pokój; polega na tym, że robi to przez przypadek i nazywa ten przypadek strategią.

Mój serwer już tak wygląda. Co mam zrobić najpierw?

Kopie zapasowe, jeszcze dziś, w miejscu, które nie jest tym serwerem, a następnie testowe przywracanie — nieprzetestowana kopia zapasowa to tylko plotka. Po drugie, poprawki i restart, którego unikasz, w zaplanowanym oknie czasowym, abyś dowiedział się, co się psuje, gdy patrzysz. Po trzecie, rozdziel pojedynczy punkt awarii: przenieś DNS i monitoring poza ten serwer. Reszta może poczekać na spokojniejszy tydzień; te trzy rzeczy nie mogą.