• admin@kibc
• 14 października 2021
• Brak komentarzy

Określenie “nasze usługi są w chmurze” to zwieńczenie trendu w technologiach informatycznych, który narzuca rozdział między fizycznym urządzeniem (hardware), a oprogramowaniem na nim uruchomionym (software). Trend ten wynika z wolności jaką programistom daje uwolnienie programu od ograniczeń wynikających ze specyfikacji fizycznego urządzenia, na którym program jest uruchomiony. Co prawda koszt tego stanu rzeczy to mniejsza efektywność energetyczna czy obliczeniowa dzisiejszych programów, ale to odrębny problem. Rzeczywistość chmurowa powoduje jednak, że zapominamy o ograniczeniach wynikających z fizycznej infrastruktury stojącej za tymi rozwiązaniami. A dla pewnych zastosowań jest to podejście krótkowzroczne.

Niezawodność systemów informatycznych

Jeśli decydujemy się na zbudowanie własnej infrastruktury IT to warto zastanowić się nad jej awaryjnością. Spójrzmy co w tym temacie mają do powiedzenia właściciele farm serwerów. Zaczynając od macierzy dyskowych i serwerów tworzących klastry dla wirtualizacji, poprzez przemysłowe UPSy, a kończąc na generatorach z kołem zamachowym zapewniających rezerwę energii na czas potrzebny do włączenia generatorów dieslowskich. Wszystkie te rozwiązania zapewniają ciągłość usług w obliczu nawet wielu jednoczesnych awarii różnych podzespołów.

Metody projektowania infrastruktury o wysokiej niezawodności (małe prawdopodobieństwo awarii) lub lepiej, wysokiej gotowości (niskie prawdopodobieństwo oraz jak najkrótszy czas przestoju), mają swoje źródło w technologiach rakietowych rozwijanych tuż po zakończeniu drugiej wojny światowej. Podstawą ich jest obserwacja, że niezawodność dowolnego systemu technicznego można opisać analogią do łańcucha – jest on tak mocny (niezawodny) jak najsłabsze ogniwo. Opisuje to proste równanie:
Rs = R1 x R2 x R3
gdzie Rs to niezawodność systemu (tj. prawdopodobieństwo bezawaryjnej pracy – od 0 do 100%) składającego się z trzech elementów niezbędnych do jego pracy. Nieważne jak doskonałe będą R1 i R2 – jeśli R3 będzie bardzo awaryjny to niezawodność całości będzie zbliżona.
Z zależności tej wynika kilka podstawowych faktów:
Im większy system (dłuższe równanie niezawodności) tym gorsza jego niezawodność
Należy skupić się na najbardziej awaryjnych elementach systemu, aby go udoskonalić
Można to zrobić poprzez dodanie elementów zapasowych (aby awaria najsłabszych komponentów nie oznaczała awarii całości).

Dostępność i niezawodność systemu

Niezawodność systemu, tj. prawdopodobieństwo jego bezawaryjnej pracy w zadanym odcinku czasu nie jest miarą, którą łatwo przełożyć na język kosztów, zysków czy strat. Pojęciem bardziej przystępnym jest gotowość techniczna, czyli procent z danego czasu eksploatacji, gdy system będzie sprawny. Np. gotowość 90% na rok oznacza, że przez 876 godzin w ciągu roku nasz system nie będzie działał. W zależności od zastosowań może to być wartość do zaakceptowania lub nie. Niestety aby obliczyć gotowość techniczną należy zastosować techniki symulacyjne, które wymagają, oprócz informacji o częstości awarii urządzeń w systemie – także czas potrzebny na ich naprawę, bądź wymianę. Analiza taka określana jest w skrócie jako RAM (Reliability, Availability, Maintainability) z dodatkowymi literami na końcu oznaczającymi bezpieczeństwo (safety – RAMS) lub częstotliwość przeglądów (inspectability RAMI).

Tego typu analiza jest obowiązkowa w dużych przedsięwzięciach infrastrukturalnych, np. w branży oil&gas, czy w międzynarodowych projektach naukowych (np. ITER, CTA Observatory). Wymaga znajomości statystyki i zasad modelowania niezawodności, więc główne nakłady finansowe to wykwalifikowana kadra oraz specjalistyczne oprogramowanie. Oczywiście obecnie na rynku jest wiele możliwości zlecenia takiej analizy na zewnątrz. Najważniejsze to świadomość, że projekt infrastruktury IT powinien uwzględniać miary niezawodności czy gotowości technicznej, gdyż błędy projektowe w tych zagadnieniach tylko częściowo można nadrobić dobrym oprogramowaniem.