Fault-Tolerant, czyli czym HA jest a czym nie …

Przedstawiam kolejną część referatu o budowaniu systemów wysokiej dostępności.

Fault-Tolerant, czyli czym HA jest a czym nie …

Fault-Tolerant (pol. Odporny na awarie) to zasady projektowania i budowania środowisk bardzo podobne do tych stosowanych w koncepcji Wysokiej Dostępności. Podstawowe różnice pojawiają się w osiąganym celu czyli poziomie niezawodności. Dla środowisk wysoko-dostępnych osiągnięcie celu niezawodnościowego następuje już wówczas kiedy czas RTO (ang. Recovery Time Objective – gwarantowany czas przywrócenia działania usługi) jest znacznie mniejszy od RTO osiąganego dla standardowo niezabezpieczonego środowiska. Zazwyczaj RTO dla środowisk HA jest rzędu minut albo nawet sekund, bardzo rzadko dziesiątek minut. Całkowicie inaczej sprawa ma się ze środowiskami FT, gdzie jedyny akceptowany czas RTO jest bliski 0 i praktycznie nieakceptowalny powyżej pojedynczych sekund. Tak więc systemy HA dopuszczają pewną niewielką niedostępność usługi, w szczególności ich restartowanie, mocno zależną od jej charakteru. Dla systemów FT jakakolwiek niedostępność jest praktycznie nieakceptowalna. Dodatkowo tzw. planowana niedostępność związana zazwyczaj z czynnościami administracyjnymi (patchowanie, upgrade sprzętu, itp.) jest dla środowisk HA całkowicie dopuszczalna i nikt nie uwzględnia ich w projektowaniu. Dla systemów FT bardzo często także planowane niedostępności są nieakceptowalne, z tego powodu projektowane są w taki sposób aby wyeliminować także takie działania. Konsekwencją tak przyjętych założeń dla FT i HA jest znacznie większy koszt zaprojektowania oraz implementacji środowisk FT względem HA.

Infrastruktura, czyli dotknięcie sedna sprawy …

Jak już zostało to wspomniane infrastruktura informatyczna składa się z warstw (podobnie jak ogry czy cebula). Każda niższa warstwa świadczy usługi dla warstw wyższych. Z tego powodu każdą z warstw możemy rozpatrywać jako osobne przypadki dla których będziemy stosować wszystkie ogólne założenia. Oczywiście takie podejście ma swoje ograniczenia ponieważ każda z warstw musi być odpowiednio “gruba” aby technicznie można było ją objąć tymi zasadami. Dla przykładu serwer z systemem operacyjnym będziemy traktowali jako całą warstwę , aplikację jako kolejną warstwę. Nie ma sensu rozdzielać systemu operacyjnego na warstwy np. warstwa TCP/IP, warstwa VFS czy warstwa zarządzania pamięcią wirtualną bo technicznie jest to całość. Takie podejście ma także i zalety. Podstawową jest to iż potencjalnie jeszcze bardziej zwiększamy niezawodność całego środowiska ze względu na to iż w specyficznych przypadkach (a nie jest ich tak mało) całość środowiska będzie odporna na awarię więcej niż jednego elementu o ile kolejne awarie pojawią się w innych warstwach infrastruktury.

C.D.N.