Wolne Dyski dla Systemu Operacyjnego, Szybkie Dyski dla Danych

Przez lata odkrywałem, że ludzie często skłaniają się ku wysoce wydajnym i niezawodnym nośnikom danych dla partycji systemu operacyjnego, ale wybierają wolne, “opłacalne” nośniki dla krytycznych zasobów danych. Jestem zdumiony, jak często to obserwuję i teraz, wraz z pojawieniem się hipernadzorców (hypervisorów), widzę to samo zachowanie powtarzające się tam – potęgujące wcześniej istniejące problemy.

W wielu dzisiejszych systemach mamy do czynienia tylko z jedną macierzą pamięci masowej współdzieloną przez wszystkie komponenty systemu. W tych przypadkach nie napotykamy problemu niezrównoważenia wydajności naszego systemu pamięci masowej. Jest to jedna z dużych zalet tego podejścia i główny powód, dla którego jest ono tak wysoko rekomendowane. Cała wydajność jest we wspólnej puli, a komponenty, które jej potrzebują, mają do niej dostęp.

W wielu przypadkach, czy to w próbie zwiększenia wydajności lub niezawodności, czy z technicznej konieczności, odkrywam, że ludzie rozdzielają macierze pamięci masowej i umieszczają hipernadzorcy i systemy operacyjne na jednej macierzy, a dane na innej. Ale to, co uważam za szokujące, to fakt, że macierze dedykowane dla hipernadzorcy lub systemu operacyjnego są często zadziwiająco duże pod względem pojemności i ekstremalnie wydajne – często obejmując wrzeciona o prędkości 15 000 RPM lub nawet dyski SSD za ogromne pieniądze. Prawie zawsze w konfiguracji RAID 1 (zgodnie z powszechnymi standardami z 1998 roku).

Co należy tu zrozumieć, to że same systemy operacyjne praktycznie nie mają wymagań w zakresie operacji wejścia/wyjścia (I/O) do pamięci masowej. Jest ich niewielka ilość, głównie do logowania systemowego, ale to właściwie wszystko, czego potrzeba. Partycje systemów operacyjnych są prawie całkowicie statyczne. Wymagane komponenty są ładowane do pamięci, głównie podczas uruchamiania systemu, i nie są ponownie dostępne. Nawet w przypadkach, gdy logowanie jest potrzebne, wiele razy logi te są wysyłane do centralnego systemu logowania, a nie do lokalnego obszaru pamięci systemowej, co redukuje lub nawet eliminuje tę potrzebę.

W przypadku hipernadzorców efekt ten jest jeszcze bardziej ekstremalny. Ponieważ hipernadzorcy są znacznie lżejsi i mniej rozbudowani niż tradycyjne systemy operacyjne, zachowują się bardziej jak systemy wbudowane i w wielu przypadkach faktycznie nimi są. Hipernadzorcy są ładowane do pamięci podczas uruchamiania systemu i ich nośnik prawie nigdy nie jest ponownie potrzebny podczas pracy systemu, z wyjątkiem logowania w niektórych przypadkach. Ponieważ hipernadzorcy są małe pod względem fizycznego rozmiaru, nawet całkowity czas potrzebny do odczytu pełnego hipernadzorcy z pamięci masowej jest bardzo mały, nawet na bardzo wolnych nośnikach, ponieważ łączny rozmiar jest bardzo mały.

Z tych powodów wydajność pamięci masowej ma małe lub żadne znaczenie dla systemów operacyjnych, a szczególnie dla hipernadzorców. Różnica między szybką a wolną pamięcią masową wpływa naprawdę tylko na czas uruchamiania systemu, gdzie różnica jednej sekundy lub trzydziestu sekund rzadko byłaby zauważona, jeśli w ogóle. Kiedy ktokolwiek zauważyłby nawet kilka dodatkowych sekund podczas uruchamiania systemu, a w większości przypadków uruchamiania są rzadkimi zdarzeniami mającymi miejsce co najwyżej raz w tygodniu podczas automatycznego, rutynowego ponownego uruchamiania w planowanym oknie konserwacji lub bardzo rzadko, czasami tylko raz na kilka lat, w przypadku systemów, które są zatrzymywane tylko w nagłych przypadkach. Nawet najwolniejszy możliwy do wyobrażenia system pamięci masowej jest znacznie szybszy niż jest to konieczne w tej roli.

Nawet wolna pamięć masowa jest generalnie wielokrotnie szybsza niż jest to konieczne dla działań związanych z logowaniem systemowym. W tych rzadkich przypadkach, gdy logowanie jest bardzo intensywne, mamy wiele możliwości rozwiązania tego problemu. Najbardziej oczywistym i powszechnym rozwiązaniem jest wysyłanie logów do macierzy dyskowej innej niż ta używana przez system operacyjny lub hipernadzorcę. Jest to bardzo łatwe rozwiązanie i ostatecznie bardzo praktyczne w przypadkach, gdy jest to uzasadnione. Innym powszechnym i bardzo użytecznym rozwiązaniem jest po prostu zaniechanie przechowywania logów na lokalnym urządzeniu i wysyłanie ich do zdalnego narzędzia do zbierania logów, takiego jak Splunk, Loggly lub ELK.

Inną główną obawą, jaką większość ludzi ma wobec swoich systemów operacyjnych i hipernadzorców, jest niezawodność. Powszechne jest skupianie większych wysiłków na ochronie tych stosunkowo nieistotnych aspektów systemu, a nie często niezastąpionych danych. Jednak systemy operacyjne i hipernadzorcy są łatwe do przebudowania od zera w razie potrzeby poprzez świeżą instalację i ręczną rekonfigurację gdy konieczne. Szczegóły, które mogłyby zostać utracone, są generalnie stosunkowo proste do odtworzenia.

Nie oznacza to oczywiście, że te systemy plików nie powinny być archiwizowane; oczywiście powinny (w większości przypadków). Ale na wypadek gdyby kopie zapasowe również zawiodły, utrata partycji lub systemu plików systemu operacyjnego rzadko naprawdę oznacza tragedię, a jedynie niedogodność. W prawie wszystkich przypadkach istnieją sposoby na odtworzenie systemu bez dostępu do oryginalnych danych, o ile system plików “danych” jest oddzielny. A ze względu na naturę systemów operacyjnych i hipernadzorców zmiany są rzadkie, więc kopie zapasowe mogą być generalnie mniej częste, ewentualnie wyzwalane ręcznie tylko wtedy, gdy stosowane są aktualizacje!

W wielu nowoczesnych systemach z obszarów DevOps i cloud computingu stało się bardzo powszechne traktowanie systemów plików systemów operacyjnych i hipernadzorców jako całkowicie jednorazowych, ponieważ są one definiowane zdalnie za pomocą obrazu systemowego lub systemu zarządzania konfiguracją. W tych przypadkach, które stają się coraz bardziej powszechne, nie ma potrzeby ochrony danych ani kopii zapasowych, ponieważ cały system jest zaprojektowany tak, aby można go było odtworzyć niemal natychmiast, bez żadnej specjalnej interakcji. System jest w pełni samoreplikujący. To jeszcze bardziej trywializuje potrzebę ochrony systemu plików.

Łącząc to razem, brak potrzeb w zakresie wydajności i brak potrzeb w zakresie ochrony i niezawodności, obsługiwanych przede wszystkim poprzez proste odtwarzanie, mamy system plików systemowych o zupełnie innych potrzebach niż powszechnie zakładamy. Nie oznacza to, że powinniśmy być lekkomyślni w naszym podejściu do pamięci masowej; nadal chcemy unikać awarii pamięci masowej podczas pracy systemu, a niepotrzebna przebudowa jest marnotrawstwem czasu i zasobów, nawet jeśli nie okazuje się katastrofalna. Dlatego ważne jest zachowanie starannej równowagi.

Oczywiście z tych właśnie powodów umieszczanie systemu operacyjnego lub hipernadzorcy na tej samej macierzy co dane jest dziś powszechną praktyką – ponieważ nie ma praktycznie żadnej potrzeby dostępu do pamięci masowej dla plików systemowych w tym samym czasie, gdy odbywa się dostęp do plików danych, więc uzyskujemy doskonałą synergię, uzyskując szybkie czasy uruchamiania dla systemu operacyjnego i brak negatywnego wpływu na czasy dostępu do danych po uruchomieniu systemu. Jest to podstawowy sposób, w jaki projektanci systemów podchodzą dziś do potrzeby efektywnego wykorzystania pamięci masowej.

Gdy system operacyjny lub hipernadzorca musi być oddzielony od macierzy przechowujących dane, co nadal może się zdarzyć z wielu powodów, zazwyczaj dążymy do uzyskania rozsądnej niezawodności przy niskim koszcie. Przy użyciu tradycyjnej pamięci masowej (lokalne dyski) oznacza to stosowanie małych, wolnych, tanich dysków talerzowych do przechowywania systemu operacyjnego, generalnie w prostej konfiguracji RAID 1. Praktycznym przykładem jest użycie dysków SATA 5400 RPM “eco-friendly” w najmniejszych dostępnych rozmiarach. Pobierają mało energii i są bardzo tanie w nabyciu. Dyski SSD i szybkie dyski SAS byłyby unikane, ponieważ kosztują więcej za ochronę, która jest nieistotna, i wydajność, która jest całkowicie marnowana.

W mniej tradycyjnych rozwiązaniach pamięci masowej powszechne jest użycie taniego, gęstego SAN konsolidującego niskopriorytową pamięć masową dla wielu systemów na wspólnych, wolnych macierzach, które nie są replikowane. Jest to skuteczne tylko w większych środowiskach, które mogą uzasadnić dodatkowy projekt architektoniczny i mogą osiągnąć wystarczającą gęstość w procesie konsolidacji pamięci masowej, aby stworzyć niezbędne oszczędności kosztów, ale w większych środowiskach jest to stosunkowo łatwe. Urządzenia bootujące z SAN mogą wykorzystywać bardzo tanie macierze na wielu serwerach, by zaoszczędzić koszty. W przestrzeni wirtualnej mogłoby to oznaczać niskowydajny datastore używany dla wirtualnych dysków systemu operacyjnego i inną, wysoko wydajną pulę dla wirtualnych dysków danych. Miałoby to ten sam efekt, co strategia boot SAN, ale w nowocześniejszym ustawieniu i mogłoby łatwo wykorzystać architekturę SAN pod spodem, by to osiągnąć.

Wreszcie, i co najważniejsze, ogólną zasadą w przypadku hipernadzorców jest instalowanie ich na kartach SD lub pendrive'ach USB, a nie na tradycyjnych nośnikach, ponieważ ich potrzeby w zakresie wydajności i niezawodności są jeszcze znacznie mniejsze nawet niż tradycyjne systemy operacyjne. Normalnie, gdyby napęd tego rodzaju uległ awarii podczas pracy systemu, system nadal działałby bez żadnego problemu, ponieważ napęd nigdy nie jest używany po początkowym uruchomieniu systemu. Problem byłby widoczny dopiero podczas ponownego uruchamiania, i w tym momencie można by użyć zapasowego urządzenia bootującego, takiego jak dodatkowa karta SD lub pendrive USB. Jest to oficjalna rekomendacja dla VMware vSphere, jest często rekomendowana przez przedstawicieli Microsoft dla HyperV i jest oficjalnie obsługiwana przez dostawców OEM HyperV i jest często rekomendowana, ale nie tak szeroko obsługiwana, dla systemów Xen, XenServer i KVM. Użycie kart SD lub napędów USB dla pamięci masowej hipernadzorcy efektywnie zamienia serwer wirtualizacyjny w system wbudowany. Chociaż może to wydawać się nienaturalne administratorom systemów przyzwyczajonym do myślenia o tradycyjnych dyskach jako konieczności dla serwerów, ważne jest, aby pamiętać, że systemy klasy enterprise o wysokiej krytyczności, takie jak routery i przełączniki, działają przez dziesięciolecia i używają dokładnie tej samej strategii z dokładnie tych samych powodów.

Powszechną strategią dla hipernadzorców w tym trybie wbudowanym z kartami SD lub napędami USB jest posiadanie dwóch takich urządzeń, które mogą faktycznie być jedną kartą SD i jednym napędem USB, każde z kopią hipernadzorcy. Jeśli jedno urządzenie ulegnie awarii, uruchomienie z drugiego jest prawie tak skuteczne jak tradycyjny system RAID 1. Ale w odróżnieniu od większości tradycyjnych konfiguracji RAID 1, mamy również stosunkowo łatwy sposób testowania aktualizacji systemowych poprzez aktualizowanie tylko jednego urządzenia bootującego na raz i testowanie procesu przed aktualizacją drugiego, co daje nam niezawodne, dobrze przetestowane zabezpieczenie na wypadek, gdyby aktualizacja wersji poszła nie tak. Ten proces był faktycznie powszechny w dużych systemach UNIX RISC, gdzie urządzenia bootujące były często lokalnymi zestawami RAID 1 w oprogramowaniu obsługującymi podobną praktykę, szczególnie powszechną w środowiskach AIX i Solaris.

Należy również zaznaczyć, że choć to podejście jest najlepszą praktyką w większości scenariuszy hipernadzorców, nie ma tak naprawdę żadnego powodu, dla którego nie mogłoby być zastosowane do pełnych systemów plików systemów operacyjnych, z wyjątkiem tego, że jest to często więcej pracy. Niektóre systemy operacyjne, szczególnie Linux i BSD, są bardzo dobrze przystosowane do instalacji w trybie wbudowanym i mogą być łatwo zaadaptowane do instalacji na karcie SD lub napędzie USB przy odrobinie planowania. To podejście nie jest wcale powszechne, ale nie ma technicznego powodu, dla którego, w odpowiednich okolicznościach, nie byłoby to doskonałe rozwiązanie, z wyjątkiem faktu, że prawie nigdy nie powinno się instalować systemu operacyjnego na sprzęcie fizycznym zamiast na szczycie hipernadzorcy. W tych przypadkach, gdy instalacje fizyczne są konieczne, to podejście jest niezwykle trafne.

Projektując i planując systemy pamięci masowej, pamiętaj, aby zwracać uwagę na to, jak wzorce odczytu i zapisu będą naprawdę wyglądać podczas pracy systemu. I pamiętaj, że pamięć masowa zmieniła się dość dramatycznie od czasu, gdy opracowywano wiele tradycyjnych wytycznych, i nie cała wiedza użyta do ich opracowania ma dziś zastosowanie lub stosuje się w równym stopniu. Myśl nie tylko o tym, które podsystemy pamięci masowej będą próbowały wykorzystać wydajność pamięci masowej, ale także o tym, jak będą ze sobą współdziałać (na przykład, czy dwa systemy nigdy nie żądają dostępu do pamięci masowej jednocześnie, czy też będą regularnie wchodzić w konflikt) i czy ich wydajność dostępu jest ważna. Ogólne funkcje systemu operacyjnego mogą być ekstremalnie wolne na serwerze baz danych bez negatywnego wpływu; jedyne, co ma znaczenie, to szybkość, z jaką można uzyskać dostęp do bazy danych. Nawet dostęp do plików binarnych aplikacji jest często nieistotny, ponieważ po załadowaniu do pamięci pozostają tam, a wydajność pamięci RAM wpływa na bieżącą wydajność.

Nic z tego nie ma sugerować, że oddzielanie podsystemów pamięci masowej systemu operacyjnego i danych od siebie jest zalecane; często nie jest. Pisałem w przeszłości o tym, jak konsolidacja tych podsystemów jest dość często najlepszym sposobem działania i pozostaje to prawdą teraz. Ale istnieje też wiele rozsądnych przypadków, w których rozdzielenie pewnych potrzeb pamięci masowej od siebie ma sens, często w przypadku dużych systemów, gdzie możemy obniżyć koszty, dedykując drogi nośnik do określonych potrzeb i tani nośnik do innych, i w tych przypadkach chcę pokazać, że systemy operacyjne i hipernadzorcy powinny być uważane za najniższy priorytet zarówno pod względem wydajności, jak i niezawodności, z wyjątkiem najbardziej ekstremalnych przypadków.