Jaką pojemność NVMe powinien mieć domowy serwer aplikacji?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How Much NVMe Capacity Should a Home App Pool Have? - Zima Store Online

W przypadku wielu serwerów domowych 512 GB to praktyczna pojemność bazowa puli aplikacji NVMe, ale właściwy rozmiar wynika z pojemności woluminów trwałych, baz danych, obrazów, logów, aktualizacji, migawek oraz ilości wolnego miejsca, którą zamierzasz zachować. Niewielki stos z odpowiednio kontrolowanymi logami może zmieścić się na 256 GB, natomiast serwer zdjęć, kilka baz danych, maszyny wirtualne lub intensywne zmiany danych aplikacji mogą sprawić, że bezpieczniejszym wyborem będzie 1 TB lub więcej. Dobieraj rozmiar puli na podstawie zmierzonego tempa wzrostu, a nie liczby aplikacji widocznych w panelu.

Uwzględnij każdy element zajmujący miejsce w puli aplikacji

Pula aplikacji rzadko zawiera wyłącznie pliki binarne aplikacji. Obrazy kontenerów, warstwy zapisywalne, woluminy trwałe, pliki baz danych, miniatury, indeksy wyszukiwania, pamięci podręczne pakietów, tymczasowe eksporty i logi mogą trafić na to samo urządzenie NVMe, chyba że celowo umieścisz je gdzie indziej.

Praktyczny przewodnik po pamięci masowej Dockera pokazuje, że wykorzystanie miejsca przez kontenery obejmuje obrazy, warstwy i woluminy, co oznacza, że samo zliczanie rozmiarów obrazów zaniży wymagania puli. Woluminy trwałe mogą być znacznie większe niż kontenery, które z nich korzystają.

Mierz bieżące wykorzystanie puli aplikacji według kategorii, a nie na podstawie łącznego rozmiaru katalogu: obrazy i pamięć podręczna kompilacji, bazy danych, trwałe dane aplikacji, miniatury i indeksy, logi, pliki tymczasowe oraz migawki. Taki spis ułatwia prognozowanie przyszłego wzrostu i pokazuje, które dane można przenieść do pamięci masowej o większej pojemności.

Jeśli obecny stos zajmuje mniej niż połowę puli 256 GB, a jego wzrost jest powolny, nie ma powodu od razu przechodzić na wieloterabajtowe NVMe. Jeśli bazy danych, miniatury lub usługi intensywnie zapisujące dane szybko się rozrastają, początkowa pojemność powinna uwzględniać ten wzrost jeszcze przed zainstalowaniem kolejnej aplikacji.

Trzymaj multimedia i kopie zapasowe poza szybką warstwą aplikacji

NVMe ma największą wartość w przypadku wrażliwych na opóźnienia danych aplikacji: baz danych, metadanych, indeksów, dysków maszyn wirtualnych, warstw kontenerów i często używanych małych plików. Duże biblioteki filmów, ukończone archiwa zdjęć, repozytoria kopii zapasowych oraz inne duże dane przetwarzane sekwencyjnie zwykle nie muszą zajmować tej samej, droższej szybkiej warstwy.

Trwałą pamięcią kontenerów łatwiej zarządzać, gdy traktuje się ją w sposób jawny. Przewodnik po woluminach Dockera wyjaśnia, jak woluminy przechowują stan poza nietrwałą warstwą kontenera, dzięki czemu można zdecydować, które dane aplikacji zasługują na miejsce na NVMe, a które powinny trafić do większej puli pamięci masowej.

Przewodnik konfiguracji ZimaSpace dotyczący oddzielenia danych rozruchowych od danych aplikacji wyznacza kolejną przydatną granicę: serwer domowy łatwiej odbudować, gdy pliki systemu operacyjnego, stan aplikacji i duże dane użytkownika mają jasno określone role.

Jeśli pula aplikacji stale się zapełnia, ponieważ z wygody przechowywane są w niej multimedia, pobrane pliki lub archiwa kopii zapasowych, nie rozwiązuj problemu wyłącznie przez zakup większego dysku NVMe. Przenieś duże dane do warstwy przeznaczonej do przechowywania dużych ilości danych, a następnie dobierz pojemność NVMe do danych, które rzeczywiście korzystają z niskich opóźnień.

Zostaw miejsce na obrazy, aktualizacje i zmiany pamięci podręcznej kompilacji

Stosy kontenerów rosną nawet wtedy, gdy aktywna baza danych się nie powiększa. Pobierane są nowe obrazy, stare wersje pozostają do czasu ich usunięcia, zatrzymane kontenery się gromadzą, a pamięć podręczna kompilacji może przetrwać zakończenie testów. Podczas aktualizacji przez pewien czas mogą być potrzebne jednocześnie zarówno stare, jak i nowe zestawy obrazów.

Aktualny przewodnik dotyczący rozliczania miejsca na dysku przez Dockera rozdziela obrazy, kontenery, woluminy i pamięć podręczną kompilacji, dzięki czemu można zobaczyć miejsce możliwe do odzyskania. To właściwy sposób oceny, czy niemal pełna pula wymaga większego sprzętu, czy po prostu lepszego zarządzania cyklem życia danych.

Nie dobieraj rozmiaru puli aplikacji tak, aby po normalnej aktualizacji była zapełniona w 95 procentach. Zostaw wystarczająco dużo nieprzydzielonego miejsca na wymianę obrazów, konserwację baz danych, operacje systemu plików i tymczasowe powielenie danych podczas aktualizacji. Dokładny zapas może się różnić, ale pula bez miejsca operacyjnego jest już zbyt mała.

W przypadku niewielkiego, dobrze zarządzanego stosu 256 GB może wystarczyć. Dla typowego serwera domowego, w którym obrazy i aplikacje będą z czasem zmieniane, 512 GB to bezpieczniejsza pojemność bazowa, ponieważ zapewnia miejsce na te zmiany bez zamieniania każdej aktualizacji w konieczność sprzątania.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Logi i pliki tymczasowe mogą zaburzyć plan pojemności szybciej niż aplikacje

Rozrost logów to jeden z najłatwiejszych sposobów, aby pozornie niewielki stos aplikacji zapełnił pulę NVMe. Gadatliwy kontener może zapisywać dane nieprzerwanie przez wiele tygodni, a nieudane zadania, tryby debugowania, analiza multimediów lub narzędzia do pobierania mogą tworzyć pliki tymczasowe znacznie większe niż ich standardowe dane aplikacji.

Przewodnik dotyczący logowania kontenerów wyjaśnia, dlaczego retencja logów wymaga jawnej kontroli, zamiast zakładania, że logi pozostaną niewielkie. Planowanie pojemności powinno obejmować zasady rotacji i przechowywania logów, a nie tylko zakup większego dysku SSD.

Artykuł ZimaSpace dotyczący rozwiązywania problemu zapełniania pamięci hosta przez logi Dockera pokazuje konsekwencje operacyjne sytuacji, w której nieograniczona ścieżka zapisu współdzieli miejsce z usługami wymagającymi, aby system plików pozostał zapisywalny.

Zanim przejdziesz z 512 GB na 1 TB, przez miesiąc obserwuj katalogi, które powiększają się najszybciej. Jeśli za większość wzrostu odpowiadają logi lub dane tymczasowe, najpierw popraw zasady ich przechowywania. Jeśli rosną prawidłowe bazy danych, indeksy, miniatury i dyski maszyn wirtualnych, większa pula rozwiązuje właściwy problem.

Dobierając pojemność, uwzględnij trwałość zapisu i odzyskiwanie po awarii

Pula aplikacji często jest intensywniej obciążana zapisami niż archiwum multimediów. Bazy danych aktualizują strony, logi są dopisywane, kontenery zastępują warstwy, pamięci podręczne często się zmieniają, a migawki lub dyski maszyn wirtualnych mogą generować długotrwałe zapisy. Przy wyborze NVMe należy więc uwzględnić trwałość zapisu i charakterystykę cieplną, a nie tylko deklarowaną maksymalną prędkość.

Recenzja dysku SSD NVMe przeznaczonego do serwerów NAS traktuje trwałość jako kluczową cechę w przypadku pamięci głównej i obciążeń związanych z buforowaniem. Szerszy wniosek zakupowy jest taki, aby dopasować klasę dysku do ilości danych aplikacji, które z czasem są wielokrotnie nadpisywane.

Tworzenie kopii lustrzanej zmienia również dostępną pojemność. Dwa identyczne urządzenia NVMe w konfiguracji lustrzanej zapewniają mniej więcej pojemność jednego dysku przed uwzględnieniem narzutu systemu plików i zarezerwowanego wolnego miejsca, więc „dwudyskowa pula aplikacji 1 TB” nie oznacza automatycznie 2 TB dostępnej przestrzeni. Układ redundancji określ przed zakupem pojemności.

Przechowuj kopię zapasową aplikacji poza pulą NVMe. Szybka pamięć masowa nie zastępuje kopii umożliwiających odzyskanie danych. Jeśli pula ulegnie awarii lub dane aplikacji zostaną uszkodzone, konfiguracje, bazy danych i woluminy trwałe muszą dać się przywrócić z innego urządzenia lub lokalizacji.

Traktuj 256 GB, 512 GB, 1 TB i 2 TB jako przedziały decyzyjne, a nie sztywne zasady

Wybierz 256 GB tylko w przypadku celowo niewielkiej puli aplikacji: kilku lekkich usług, umiarkowanych baz danych, kontrolowanych logów oraz niewielkiej aktywności związanej z kompilowaniem lub maszynami wirtualnymi. Taka pojemność może dobrze się sprawdzić, gdy duże dane są przechowywane gdzie indziej, a użytkownik jest gotowy monitorować ilość wolnego miejsca.

Traktuj 512 GB jako domyślną pojemność planistyczną dla typowego hosta aplikacji domowych z kilkoma kontenerami, normalnymi zmianami obrazów, kilkoma bazami danych, pulpitami nawigacyjnymi, danymi w stylu Home Assistant oraz zapasem na aktualizacje. To zalecenie dotyczące pojemności, a nie twierdzenie, że każdy stos zajmie tyle samo miejsca.

Przejdź na 1 TB, gdy plan obejmuje miniatury i indeksy zdjęć, wiele baz danych, pamięci podręczne pakietów, dyski maszyn wirtualnych, zadania kompilacji lub kilka lat rozwoju aplikacji. Wybierz 2 TB lub więcej tylko wtedy, gdy dane szybkiej warstwy są rzeczywiście duże. Jeśli o wyborze tej pojemności decydują multimedia, pobrane pliki lub archiwa kopii zapasowych, najpierw ponownie przeanalizuj projekt podziału na warstwy.

ZimaBoard 2 może obsługiwać NVMe przez złącze rozszerzeń PCIe i sprawdza się w kompaktowych konfiguracjach hostów aplikacji, natomiast ZimaCube 2 staje się bardziej odpowiedni, gdy niezależnie uzasadnione są szybsze rozszerzenie SSD, intensywniejsza wielozadaniowość lub większy system pamięci masowej. Platformę wybierz dopiero po określeniu pojemności puli aplikacji i ścieżki jej rozwoju, a nie wcześniej.