SLA, jako umowa między usługodawcą, a klientem może zawierać szereg uzgodnień dot. jakości usług. Jedną z nich jest, moim zdaniem bardzo ważna, definicja planowego downtime‘u.
Czym jest planowy downtime? Jest to czas, najczęściej w środku nocy, jaki jest wymagany przez administratorów systemów do instalacji nowego oprogramowania czy łatania już istniejącego, zmian konfiguracyjnych sprzętu i oprogramowania, które wymagają ponownego rozruchu i inne elementy, które w znaczny sposób zakłócą pracę serwisów, za które płaci klient (co oznacza obniżenie czasu dostępności usług).
Wiemy, że nasze systemy wymagają downtime’u od czasu do czasu. W przypadku Microsoftu, jest to min. raz w miesiącu (tzw. patch Tuesday), kiedy ukazują się krytyczne bądź ważne poprawki do systemów i aplikacji, które najczęściej wymagają restartu “łatanego” systemu. Przy założeniu, że byłoby to 10 minut w skali miesiąca na restart jednej maszyny daje to całkiem przyzwoity poziom 99.97717% dostępności w skali roku. To jest jednak sytuacja idealna, kiedy łatamy tylko system operacyjny. Gorzej jeśli po drodze mamy jeszcze Exchange, SQL, IIS i inne systemy. Czas potrzebny do zainstalowania wszystkich poprawek sięga wtedy 20 minut, 30 minut, etc, a nasz czas dostępności coraz bardziej się kurczy, a wydłuża się czas, kiedy aplikacja klienta nie działa.
Co zatem robić w przypadku, kiedy musimy poprawki instalować, a jednocześnie musimy zapewnić określoną przez SLA i bardzo wyżyłowaną dostępność na poziomie 99.99%? Można poradzić sobie dwojako: poprzez odpowiednią klauzulę w umowie o poziomie usług albo poprzez rozwiązania techniczne (clustering).
Opcja pierwsza dla klienta końcowego wygląda dość kuriozalnie: system nie działa, ale o tym wiem i się na to zgodziłem (planowy downtime) albo system nie działa, ale się na to nie godziłem (nieplanowany downtime) - tak czy inaczej, w obu przypadkach usługa kliencka jest niedostępna. To tak, jak kupić samochód i godzić się, że co miesiąc nasz silnik się wyłączy na 5 minut (lepiej byśmy nie byli wtedy na autostradzie).
Zawieranie klauzuli planowego downtime‘u w umowie SLA jest wg. mnie po prostu nieeleganckie i wprost pokazuje, że firma tnie koszty i nie chce inwestować w rozwiązania zapewniające ciągłą dostępność (jak wspomniany przeze mnie wyżej clustering). Jeśli jednak, usługodawcy zdecydują się na wykorzystanie technik HA (high availability), mogą szczycić się w umowach z klientami poziomem 5*9, czyli 99,999%, gdzie 0,001% jest już jedynie współczynnikiem ryzyka.
A co mają zrobić administratorzy i menedżerowie IT? Zasiąść za arkuszem kalkulacyjnym i zobaczyć czy ich firmę stać na rozwiązania HA i kiedy poniesiony koszt się zwróci. A zapewniam, prędzej czy później się zwróci.
Dlatego powazne klastry buduje sie na Linuksie lub Uniksie - tam nie ma “patch Tuesday” a wiekszosci systemow nie trzeba restartowac po instalacji wiekszosci poprawek, najczesciej wystarczy restart uslugi, co zdecydowanie minimalizuje czas kiedy jest ona niedostepna.
@ptashek
Hmmm … ale w przypadku restartu usługi efekt jest ten sam … no chyba ze na Linux \ Unix usluga w trakcie restartu nadal jest dostepna - to bylby przelom w technologi HA. Moze niedlugo dojedziemy do stanu w ktorym usluga w stanie STOP bedzie dostepna - byloby super.
Wspomaniales o klastrach - w przypadku konfiguracji klastrowych “patch Tuesday” przewaznie nie ma wplywu na dostepnosc uslugi. Po prostu patchuje sie kolejne nody klastra a pozostale utrzymuja usluge.
Tak że jakoś to co napisałes jakos sie nijak ma do tego o czym pisze Michal :).
Może z klastrami to zły przykład, ale sam przyznasz że systemy uniksowe trzeba restartować o wiele rzadziej. Ja zastanawiam nad tym od kiedy czytałem, że lotnisko Heathrow stoi na Windows i że doszło tam do zawieszenia systemu z powodu “nie wykonania restartu raz na 30 dni” - to cytat z jakiegoś portalu.
Z mojego skromnego doświadczenia wynika że sytuacje takie jak ta:
(…) doszło tam do zawieszenia systemu z powodu “nie wykonania restartu raz na 30 dni” - to cytat z jakiegoś portalu. (…)
Są wynikiem beztroski developerów i aplikacji działających na OS a nie samego OS. Wycieki pamięci, sterowniki drukarek nigdy nie zwalniające pamięci albo restartujące explorer.exe przy każdym wydruku i takie tam inne … codzinność w wielu środowiskach …
@Tomek: czytajac pomiedzy liniami, z tego to co Mariusz i ptashek napisali, to ze jak zainstalujesz Linuxa czy Unix’a to mozesz sobie usiasc za biurkiem i do konca zycia prawie nic nie robic… Nie jestem adminem ani jednego ani drugiego, przynajmniej nie na tyle, by moc zabierac zdanie w tej dyskusji, ale wydaje mi sie to bledne.
Bzdury.
Nie można naraz wymagać dużej liczby dziewiątek i niskich opłat.
To zawsze jest balans.
Obiecywanie 99.99% nawet przy sensownym HA (klastry/NLB, sensowna infrastruktura sieciowa, sensowna serwerownia, z nadmiarową klimą, zasilaniem itp) jest ryzykowne. Chyba że piszemy o samej infrastrukturze, i to w obrębie LAN. Bo aplikacje (tak jak Tomek Onyszko pisał) są trudne w utrzymaniu.
Prawie żaden operator sieci szkieletowych nie da więcej niż 99%, zwłaszcza na coś więcej link ze swojego datacenter do swojego routera brzegowego (jeśli da to zazdroszczę. I podaj jego nazwę — przyda się do projektów :).
@ziembo: ale przeciez nikt nie pisze, ze 5×9 ma byc tanie
Byloby to jawne psucie rynku
@Tomek: Usluga nie jest dostepna ale restart uslugi trwa znacznie krocej niz restart calego systemu. Restart w swiecie Linuksa czy Uniksa jest wymagany jedynie w przypadku podmiany jadra systemu, co akurat w przypadku rozwiazan HA robi sie rzadko, lub wrecz wcale. Nawet sterowniki mozna podmieniac “na zywca”.
p.s.: Inne nody utrzymuja usluge, pod warunkiem, ze mamy klaster gdzie kazda koncowka funkcjonuje jako failover a dana usluga jest jedyna serwowana przez caly klaster. Taki stan jest raczej rzadkoscia w produkcji, chyba, ze mowimy o klastrach 2. nodowych.
@Michal: “jak zainstalujesz Linuxa czy Unix’a to mozesz sobie usiasc za biurkiem i do konca zycia prawie nic nie robic” - sprobuj, spodoba Ci sie
Michał,
cały cykl wynurzeń o SLA zacząłeś od swoich problemów z web hostingiem. I to AFAIR tanim hostingiem. i w tym sensie wolę środowisko gdzie mam zaplanowane (i ustalone ze mną) przerwy niż takie gdzie się ściemnia i jeśli środowiska sam dodatkowo nie monitoruję to dowolny … przejdzie (ale SLA
liczone jest całościowo.
@ziembor:
Tak, caly cykl “wynurzen” o SLA zaczalem faktycznie od moich problemow z hostingiem. Zaczalem pisac jak byc powinno i nie powinno, dochodzac powoli do ogolnych wnioskow na temat jakosci szeroko pojetych uslug IT.
Ten wpis nijak jednak odnosi sie do moich poprzednich postow na temat SLA poza wspolna cecha: tematem. W tym poscie nie pisze jednak o tanich prodiverach hostingu, nawet nie nawiazuje do poprzednich postow. Pomimo, ze poruszaja jeden temat nie maja ciaglosci jako takiej.
Moge jedynie pogratulowac spostrzegawczosci i dobrej pamieci
ok.
@ptashek
(…)
Restart w swiecie Linuksa czy Uniksa jest wymagany jedynie w przypadku podmiany jadra systemu, co akurat w przypadku rozwiazan HA robi sie rzadko, lub wrecz wcale. Nawet sterowniki mozna podmieniac “na zywca”.
(…)
Nie musisz mi tlumaczyc
moze to wydaje sie dziwne ale jak pracowalem z takimi systemami :).
(…)Inne nody utrzymuja usluge, pod warunkiem, ze mamy klaster gdzie kazda koncowka funkcjonuje jako failover a dana usluga jest jedyna serwowana przez caly klaster. Taki stan jest raczej rzadkoscia w produkcji, chyba, ze mowimy o klastrach 2. nodowych. (…)
Hmmm … mi sie wydaje ze to jest tylko kwestia odpowiedniego zaplanowania klastra i rozlozenia uslug na nim z wiedza ze musisz miec mozliwosc wyjecia jednego noda na potrzebny maitanance … nie wyobrazam sobie inaczej. W koncu czasami moze sie cos stac z jednym nodem i wszystkie uslugi musza byc nadal dostepne. Patchowanie w takim srodowisku to po prostu szczegolny przypadek okienka maitanance. Musi byc mozliwosc wylaczenia z klastra jednego noda z zachowaniem ciaglosci dostepnosci do uslug.