Rzecz o serwerach

Na moment oderwiemy się od tematyki czysto DDI i powiemy sobie kilka słów o systemach serwerowych i sposobach zarządzania nimi w średnich przedsiębiorstwach.

Narzędzi do zarządzania systemami jest wiele. Różnią się one możliwościami, konfiguracją, dostępnością oraz co najważniejsze ceną. Niestety większość mniejszych przedsiębiorstw zmuszona jest do zarządzania serwerami manualnie – bez użycia narzędzi zewnętrznych lub z użyciem narzędzi opartych o darmowe licencje.

Istnieje cała masa oprogramowania darmowego, które doskonale spełnia swoja rolę także w dużych korporacjach. Na szczególną uwagę zasługuje oprogramowanie do wirtualizacji Bare-metal np. Ubuntu MAAS. Swoją rolę odgrywają także systemy monitoringu Nagios, platformy Datalake Hadoop, platformy konteneryzacji docker/hive/kubernetes, Apache spark, czy popularne serwisy Apache WWW, MySQL, Firebird nie mówiąc o całych systemach operacyjnych typu Linux/BSD.

Oprogramowanie to jest z powodzeniem używane i zapewnia wysoki poziom niezawodności. Nie zawiera jednak jednak niezwykle istotnej rzeczy – wsparcia. Niektóre z projektów oczywiście umożliwiają jego wykupienie, jednak co do zasady ideą oprogramowania OpenSource jest dostarczenie funkcjonalności AS-IT-IS. W dużych korporacjach podział na mniejsze teamy odpowiedzialne za swoją działkę jest dużo bardziej granularny. Dlatego duży nacisk kładzie się także na dostarczenie wsparcia do oferowanych produktów/integracji.

W odniesieniu do serwerów – małe firmy używają oczywiście słabszego sprzętu. Nie mogą sobie najczęściej pozwolić na zakup rozwiązań z wysokiej półki np. serwerów blade, macierzy duplikowanych np. NetApp. Większość małych firm zadowala się pojedynczym serwerem z którego wykonywane są kopie zapasowe bez redundancji. Oznacza to, że w razie awarii usługa jest niedostępna i należy akceptować fakt Downtime jako ryzyko.

Na poziomie serwera możliwe jest oczywiście zapewnienie pewnej niezawodności np. w postaci macierzy RAID dla dysków. Mamy tu do wyboru różne poziomy niezawodności od 10 (RAID 0 łączenie przestrzeni dysków celem zwiększenia szybkości oraz RAID 1 – mirror), 3-way-mirror (RAID 1 dla 3 dysków) , RAID 5 (wymaga minimum trzech dysków z czego zawsze jeden może ulec awarii) RAID 6 – wymaga minimum 4 dysków i w zależności od ilości dysków awarii może ulec 2 lub więcej dysków). Wybór rozwiązanie RAID podyktowany jest koniecznością zapewnienia kompromisu między bezpieczeństwem a wydajnością. Wydajność jest coraz niższa im wyższe bezpieczeństwo dlatego najczęściej stosowanym rozwiązaniem jest RAID 1 lub RAID 10 gdzie ze względu na brak tzw. informacji o parzystości łatwiejsze jest ewentualne odzyskiwanie danych.

Kolejnym zabezpieczeniem na jakie mogą sobie pozwolić małe firmy jest redundancja na poziomie zasilania wraz z odpowiednim urządzeniem UPS. Serwery umożliwiają instalację zasilaczy redundantnych n+1 co znaczy że nawet gdy ulegnie awarii jeden z modułów drugi zapewnia działanie całego serwera.

W tym miejscu warto także wspomnieć o redundancji rozumianej w kontekście dostępu do samego serwera – redundancji portów sieciowych. Obecnie bardzo często stosowaną techniką jest ich agregacja – najczęściej przy użyciu protokołu LACP (Link Agregation Control Protocol) . Pozwala ona na konfigurację połączenia aktywnego po obu stronach, zwiększenie przepustowości z jednoczesnym zwiększeniem niezawodności – oba linki dokonują transferu danych jako aktywne a jednocześnie w przypadku awarii jednego z nich łączność jest w dalszym ciągu utrzymana. Większość szanującego się sprzętu sieciowego zapewnia obsługę protokołu LACP (Cisco/Juniper, etc). Sprawa z systemami operacyjnymi jest nieco bardziej skomplikowana gdyż agregacja zależy tu np. od sterownika karty w systemie, od architektury rozwiązania (np. wirtualizacja ). Windows Server 2012 i wyżej zapewnia tzw. Network Card Teaming w oparciu o LACP, w przypadku systemów Linuks jest to czasem kwestia instalacji modułu bondingu do kernela i konfiguracji pliku /etc/network/interfaces (tu w zależności od wersji może to wyglądać różnie).

W tej sytuacji nie sposób nie wspomnieć o interfejsach dedykowanych do zarządzania serwerem – BMI (Board Management Interface). Są to dedykowane interfejsy na płycie głównej umożliwiające zarządzanie nawet wyłączonymi serwerami, instalację oprogramowania czy uzyskanie informacji o konfiguracji. W zależności od producenta płyty głównej rozwiązanie może być darmowe lub płatne. Np. IPMI stosowane w płytach Intel/Supermicro jest darmowe i posiada pełną funkcjonalność, natomiast oprogramowanie iDRAC dla serwerów DELL występuje jako Basic i Enterprise i tylko werjsa płatna ma konsolę do zdalnej instalacji systemu oraz zarządzania. HP ma swoje ILO, Lenovo IMM itd.

Niestety redundancja kończy się w tym miejscu. Komponenty takie jak CPU, czy pamięć nawet gdy procesorów jest więcej a pamięć jest dystrybuowana – podłączone są do jednej płyty głównej która w razie awarii odcina wszystko.

W tym miejscu dochodzimy do wyższego poziomu redundancji, który możliwy jest do zapewnienia poprzez instalację klastrów czyli dwóch lub więcej maszyn (najlepiej identycznych lub przynajmniej – z punktu widzenia Hyper-v Clustering – o procesorach tego samego vendora) pełniących jedną funkcję. O klastrach w kolejnym artykule.