Procesory, pamięć, karty IO, czyli o wnętrznościach słowa dwa …

 W końcu udało mi się dokończyć drugi z referatów, więc mogę spokojnie publikować kolejne odcinki sagi. W chwili obecnej referaty dostępują korekty wewnętrznej i jeśli wszystko pójdzie dobrze zostaną wysłane do organizatorów. Tak więc zapraszam na dalszą część.

Procesory, pamięć, karty IO, czyli o wnętrznościach słowa dwa …

Obszar procesorów, pamięci czy podsystemu IO, jest obszarem na który jako administratorzy czy specjaliści wdrażający rozwiązania wysoko-dostępne praktycznie nie mamy żadnego wpływu. Dokładniej to wpływ ten jest bardzo mocno ograniczony poprzez stosowanie określonych architektur sprzętowych w których ilość procesorów czy kanałów pamięci/IO jest z góry narzucona. Nie bez znaczenia maja także możliwości finansowe naszego sponsora. Nie od dziś wiadomo że im sprzęt ma większe możliwości czy mechanizmy niezawodnościowe tym jego cena bardziej szybuje w górę. Jeśli jednak nie jesteśmy ograniczeni w możliwych wyborach sprzętu to ponownie powinniśmy pamiętać o zasadzie eliminacji SPOF. Tym razem w wydaniu serwerowym zalecenia wyglądają następująco: serwer powinien posiadać o jeden procesor więcej (najlepiej liczony jako socket) niż wymaga aplikacja/usługa – w przypadku uszkodzenia jednego z nich na poziomie testów POST może być on zwyczajnie wyłączony (ang. blacklisting); ze względu na koszta nie stosuje się mirroringu pamięci RAM za to kości pamięci powinny być obowiązkowo wyposażone w korekcję błędów ECC, a ilość obsadzonych banków pamięci, analogicznie jak w przypadku procesorów, powinna być o jeden większa niż wymaga tego usługa/aplikacja – dzięki temu uszkodzenie pojedynczej kości pamięci wyłączy (dzięki mechanizmowi blacklistingu w procedurach POST) jeden „nadmiarowy” bank pamięci finalnie nie uszczuplając posiadanych zasobów. Pozostaje jeszcze sprawa poprawnego obsadzenia kart IO, szczególnie w przypadku stosowania mechanizmów wielościeżkowości dla dysków czy sieci LAN opisanych wcześniej. W tym przypadku warto zweryfikować czy karty instalowane są na niezależnych magistralach/mostkach PCI dostępnych w serwerze. Dzięki temu problemy z daną magistralą czy mostkiem PCI nie powinny wpłynąć na dostępność naszej usługi. Oczywiście nie każda architektura czy nawet klasa sprzętu ma opisane tu możliwości, tak więc podczas wyboru możemy traktować to jako jedno z kryteriów porównawczych.

Serwery, klastry, farmy i inne zwierzęta …

Jak pozabezpieczamy sobie już niższe warstwy infrastruktury: zasilanie, pamięć masową, sieci LAN oraz SAN to w końcu przychodzi czas na zajęcie się sprawami wyższych warstw czyli serwery i aplikacje. W warstwach tych sprawa trochę się niestety komplikuje. Wprawdzie w dalszym ciągu powinniśmy projektować środowisko zgodnie z zasadą eliminacji SPOF lecz spoglądając od strony usługi/aplikacji a nie samej warstwy. Po pierwsze warstwy systemu operacyjnego i serwera fizycznego nie mogą być rozdzielane (zastosowane wirtualizacji zmienia to założenie), po drugie jeśli przeanalizuje się funkcjonalność wielu usług/aplikacji to nagle może okazać się że wszystko co do tej pory robiliśmy jest całkowicie (albo prawie) niepotrzebne i tylko sztucznie zwiększa koszta związane z wdrożeniem infrastruktury. Ale dlaczego? Postaram się finalnie to wytłumaczyć. Tak więc do dyspozycji mamy dwa a dokładniej trzy rodzaje technik zabezpieczania: klastry systemowe, farmy balansowane oraz klastry aplikacyjne. Z punktu widzenia infrastruktury zarówno farmy jak i klastry aplikacyjne są do siebie bardzo podobne i często traktowane jako wspólny obszar.
Klastry to grupa komputerów świadczących określone usługi zbudowana w taki sposób że nawzajem dublują swoje funkcje. Farmy czy klastry aplikacyjne to grupa komputerów świadczących określone usługi zbudowane w taki sposób że wszystkie komputery jednocześnie świadczą tą sama usługę ale dla innego klienta czy transakcji. Podstawowa różnica pomiędzy farmą a klastrem aplikacyjnym jest w poziomie “świadomości” samej aplikacji w świadczeniu usługi wysoko-dostępnej. W terminologii klastrowej występuje szereg specyficznych dla tego gatunku informatyki pojęć, m.in: węzeł klastra – komputer wchodzący w skład infrastruktury klastra; interkonekt klastrowy – bezpośrednie połączenie węzłów klastra służące wymianie informacji potrzebnych do poprawnego działania klastra; heartbeat -  zbiór metod odpowiedzialnych za weryfikację poprawności działania środowiska klastrowego; splitbrain – stan w którym każdy z węzłów (lub pewna część) klastra utracił wiarygodną informację o statusie działania/dostępności pozostałych węzłów klastra (sytuacja występuje zazwyczaj w przypadku utraty kanału komunikacyjnego dla heartbeat’u); quorum – obiekt/zasób krytyczny o współdzielonym dostępie z węzłów klastra umożliwiający osiągnięcie większości w trakcie elekcji w sytuacji splitbrain; elekcja – działanie mające na celu wyłonienie wyłącznie jednego reprezentanta mającego świadczyć daną usługę w przypadku wystąpienia sytuacji splitbrain lub innej awarii; fencing – mechanizm mający na celu odizolowanie od infrastruktury współdzielonej węzła klastra w przypadku wystąpienia sytuacji splitbrain lub innej awarii tego węzła; usługa klastrowa – zbiór zasobów wymaganych do poprawnej pracy usługi informatycznej lub aplikacji, zasoby mogą być dostarczane explicite poprzez odpowiednią konfigurację klastra (np. zasoby dyskowe, adresy IP, dane) lub są zasobami domyślnymi (np. procesor, pamięć ram, itp.); współdzielone zasoby dyskowe – pamięć masowa występująca jako jeden z zasobów usługi klastrowej dzięki której możliwe jest uruchomienie usługi na różnych węzłach klastra w takim samym środowisku uruchomieniowym, z tymi samymi danymi; usługa balansowana – usługa informatyczna lub aplikacja działająca na farmie balansowanej skonfigurowana w taki sposób aby od strony klienta była widoczna tak jakby pracowała na pojedynczym serwerze; RIP – “Real IP” – adres usługi działającej na serwerach farmy, zazwyczaj nie biorący udziału w bezpośredniej komunikacji klienta z usługą; VIP – “Virtual IP” adres wirtualny usługi balansowanej; balansowanie obciążenia – metody/strategie przekierowywania ruchu sieciowego związanego z usługa balansowaną w taki sposób aby zapewnić równomierne obciążenie serwerów farmy (skalowanie poziome wydajności usługi).
Klaster aplikacyjny, jak już to zostało wcześniej wspomniane, od strony infrastruktury jest łudząco podobny do farmy, w rzeczywistości jest odmianą farmy z mechanizmami balansowania obciążenia czy zapewnienia wysokiej-dostępności obsługiwanymi całkowicie po stronie aplikacji (w większym lub mniejszym stopniu). Dla przykładu balansowanie obciążenia może być realizowane za pomocą mechanizmów przekazywania zadań do wykonania w obrębie klastra czy pobierania zadań do wykonania z “centralnego” repozytorium zadań. Mechanizmy wysoko-dostępne mogą być realizowane poprzez cykliczne odwoływanie się klientów usługi do kolejnych zdefiniowanych adresów serwerów klastra – w ten sposób można także realizować jedną ze strategii balansowania obciążenia w przypadku obsługi jednoczesnej wielu klientów czy transakcji/żądań – czy poprzez odpytywanie serwerów/usługi monitorującej dostępność serwerów klastra. Jako że obszar ten dotyczy samej istoty rzeczy/funkcjonalności usługi to każda implementacja jest specyficzna dla danej usługi i bardzo trudno opisywać tu każdy z możliwych scenariuszy, w końcu każdy projektant aplikacji może sobie wymyślić nowy.
Wróćmy więc do klastrów systemowych i farm balansowanych. Podstawowym kryterium w wyborze jednej z dwóch możliwości jest charakter działania usługi/aplikacji. W przypadku usług które w naturalny sposób mogą być skalowane w poziomie, czyli wszystkich usług silnie wielowątkowych i słabo zależnych od wspólnych danych lub nie wymagających transakcyjności w dostępie do tych danych, jedynym sensownym rozwiązaniem jest farma balansowana. Na skrajnym biegunie funkcjonalnym mamy aplikacje silnie transakcyjne, silnie zależne od dostępu do wspólnych danych czy wręcz o ograniczonej wielowątkowości. Wszystkie te rodzaje aplikacji ze względów czysto technicznych umieszcza się na klastrach systemowych. Klastry takie z punktu widzenia działającej aplikacji zachowują się jak pojedynczy serwer który w razie awarii jest automatycznie podmieniany na inny działający w klastrze. Jako że “podmiana” ta jest realizowana automatycznie, więc drugi węzeł musi cały czas działać i w najprostszym przypadku oczekiwać na przejęcie usługi. Z tego powodu aplikacja działająca w środowisku klastrowym musi być tak zaprojektowana i skonfigurowana aby podmiana serwera posiadającego unikalne cechy takie jak: hostname, hostid, prywatne adresy ip, itp., była dla tej aplikacji całkowicie obojętna i przeźroczysta. Niestety nie wszystkie aplikacje spełniają te wymagania. W takim wypadku z pomocą przychodzi nam wirtualizacja i uruchomienie wirtualnego hosta jako usługi klastrowej. Wymienione wcześniej unikalne cechy każdego z węzłów klastra nie mają tu zastosowania, środowisko wirtualne zawsze jest takie same bez względu na to na jakim węźle klastra obecnie usługa pracuje.

C.D.N.