Witam,

Czy znacie jakis soft lub pomoce do obliczania tudziez formalnego
potwierdzania dostepnosci (availability) systemow rozproszonych?
W ubezpieczeniach i w technice oblicza sie prawdopodobienstwa choroby
lub uszkodzenia sie jakiegos podzespolu.
Zaczalem sobie powolutku rozpisywac rownanka, ale jesli system jest
zlozony z trzech elementow zaczyna juz byc skomplikowany
do liczenia na papierku.

Moze ktos sie bawil w udowadnianie, ze po czasie T system bedzie
dzialal z jakim tam prawdopodobienstwem.
Albo calkowicie inzyniersko, jak udowodnic, ze dostepnosc
rozproszonego systemu wynosi np. 99.7%.

Pozdrawiam,
Sewryn Habdank-Wojewodzki.

do góry

On Jul 17, 9:40 pm, Seweryn Habdank-Wojewódzki <h...@g...com>
wrote:

> Albo calkowicie inzyniersko, jak udowodnic, ze dostepnosc
> rozproszonego systemu wynosi np. 99.7%.

Co to jest "dostępność rozproszonego systemu"?
Że dostępny jest co najmniej jeden z N węzłów, czy wszystkie?
Co z połączeniami? Bo przecież wszystkie węzły mogą działać ale jeśli
nie działają połączenia między nimi, to działanie systemu może być
niepełne. Czy system, który jest dostępny ale ma niepełną
funkcjonalność (np. można się zalogować do banku i zobaczyć stan
konta, ale nie można zrobić przelewu) liczymy jako 100%? Itd.
Czyli temat jest dosyć złożony.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

Maciej Sobczak wrote:
> On Jul 17, 9:40 pm, Seweryn Habdank-Wojewódzki <h...@g...com>
> wrote:
>
>> Albo calkowicie inzyniersko, jak udowodnic, ze dostepnosc
>> rozproszonego systemu wynosi np. 99.7%.

Bez analizy ryzyka i bez konkretnego poznania co i jak może się popsuć
niezależnie, udowodnienie czegoś jest ciężkie.

No i najpierw w ogóle trzeba mieć jakieś dane nt. niezawodności poszczególnych
komponentów. Z czym bywa różnie. Dla hardware czasem jeszcze coś można dostać,
dla software -- z rzadka. Poważna trudność to common failure modes -- dla
software to np. bug w stosie komunikacyjnym powodujący, że jak przyjdzie jakiś
tam komunikat to stos się wywala. I jeden dobrze rozpropagowany komunikat
wykłada nam cały sytetm z fafset "niezależnych" komponentów.

Tak czy siak potrzeba wiele szacować.

Jako minimum wlicza się wszelkie planowane downtime-y. Jak np. raz na kwartał
system trzeba wyłączyć na 2-3h, ot choćby na planowany upgrade, to mamy już z
góry ograniczenie do max 3 dziewiątek.

W rzeczywistej rzeczywitości to często sprowadza się to do określenia nie
realnej niezawodności tylko gwarantowanej niezawodności. Np. zakładamy, że
prawdopodobieństwo wsytąpienia krytycznego buga w ciągu np 10lat planowanego
działąnia systemu jest wysokie (np. 0.7) ale równocześnie zakładamy, że będzie
on z prawdopodobieństwem 0.9 naprawialny w ciągu 24h a w 0.09 w ciągu 72h, i
tylko pozostałe 0.01 to jakaś paskudztwo wymagające długiej naprawy. Możemy
wtedy napisać że mamy dostępność 9.997. Albo, co tu jest istotne(!) możemy
napisać że jest np. 9.999 albo po prostu 100% -- a czas niedostępności bierzemy
na klatę i na kary umowne za niedostępność powyżej dopuszczalnego limitu.

Pojawiło się całkiem sporo serwisów gwarantujących po prostu dostępność 100% --
a realny czas niedostępności refundują w ramach gwarancji.

Jak ktoś zatem chce mieć realne 4 czy 5 dziewiątek, to niech w umowie
wynegocjuje horrendalne kary umowne i niech umawia się z producentem/dostawcą
któremu nie będzie łatwo umrzeć (biznes który splajtuje w 1 na 3000 przypadków
to zwykle bardzo obiecujący biznes -- więc wielu oferentów może sobie po cichu
założyć, że jak się sypnie to cóż, mamy pecha).

>
> Co to jest "dostępność rozproszonego systemu"?
> Że dostępny jest co najmniej jeden z N węzłów, czy wszystkie?

Jeśli nie jest podane o "dostępność czego i skąd" chodzi, przyjmuje się zwykle,
że chodzi o to, że system jako taki jest zdolny do wykonywania głównego
przetwarzania danych.

> Co z połączeniami? Bo przecież wszystkie węzły mogą działać ale jeśli
> nie działają połączenia między nimi, to działanie systemu może być
> niepełne.

W sensownym systemie wysokiej niezawodności, poza przypadkami trywialnymi[*],
węzły które nie mają połączenia z resztą systemu nie działają. Innymi słowy ma
być jakaś forma kworum. Nno, bywają też systemy, gdzie nie jest potrzebny jeden
spójny obraz wspólnego stanu -- wystarcza, że kiedyś w przyszłości da się go
uspójnić -- ale wtedy połączenia między węzłami nie muszą działać.

[*] przypadek trywialny to np. (pod)system read-only i podobne sytuacje gdzie
można w pełni wykonać przetwarzanie bez dostępu do stanu wspólnego.

> Czy system, który jest dostępny ale ma niepełną
> funkcjonalność (np. można się zalogować do banku i zobaczyć stan
> konta, ale nie można zrobić przelewu) liczymy jako 100%? Itd.
> Czyli temat jest dosyć złożony.

A to owszem :)

pzdr
\SK
--
"Never underestimate the power of human stupidity" -- L. Lang
--
http://www.tajga.org -- (some photos from my travels)

do góry

Witam,

> Co to jest "dostępność rozproszonego systemu"?

Tak jak dostepnosc chmury obliczeniowej czy web serwisu.

> Że dostępny jest co najmniej jeden z N węzłów, czy wszystkie?

Calosc jako okreslona funkcjonalnosc.

> Co z połączeniami? Bo przecież wszystkie węzły mogą działać ale jeśli
> nie działają połączenia między nimi, to działanie systemu może być
> niepełne.

Tak i w zaleznosci od padu okreslonego polaczenia system moze byc
dostepny lub nie.

>Czy system, który jest dostępny ale ma niepełną
> funkcjonalność (np. można się zalogować do banku i zobaczyć stan
> konta, ale nie można zrobić przelewu) liczymy jako 100%?

To nie jest pelna dostepnosc. Mozna takie warianty tez uszczegolowic.

> Itd. Czyli temat jest dosyć złożony.

Wiem.

Pozdrawiam,
Seweryn Habdank-Wojewodzki.

do góry

On Jul 17, 9:40 pm, Seweryn Habdank-Wojewódzki <h...@g...com>
wrote:

> Zaczalem sobie powolutku rozpisywac rownanka, ale jesli system jest
> zlozony z trzech elementow zaczyna juz byc skomplikowany
> do liczenia na papierku.
Jakbys zpodal mi dane, to bym zrobil symulacje MC. Wtedy im
dluzej symulacja trwa, tym dokladniejszy wynik. Liczylem juz w
ten sposob prawdopodobienstwo bardzo skomplikowanych
obiektow, a wyliczenie analityczne byloby karkolomne.
Pozdrawiam

do góry

W dniu 2011-07-18 20:36, Seweryn Habdank-Wojewódzki pisze:
> Witam,
>
>> Co to jest "dostępność rozproszonego systemu"?
>
> Tak jak dostepnosc chmury obliczeniowej czy web serwisu.
>
>> Że dostępny jest co najmniej jeden z N węzłów, czy wszystkie?
>
> Calosc jako okreslona funkcjonalnosc.

Jeśli w ramach funkcjonalności określamy też przepustowość, to sprawa
znów się może skomplikować. System dający się obciążać w połowie
gwarantowanego obciążenia to jak rozumiem niedziałający.

--
Paweł Kierski
n...@p...net

do góry

Witam,

> Bez analizy ryzyka i bez konkretnego poznania co i jak może się popsuć
> niezależnie, udowodnienie czegoś jest ciężkie.

Oczywiscie.

> No i najpierw w ogóle trzeba mieć jakieś dane nt. niezawodności poszczególnych
> komponentów. Z czym bywa różnie. Dla hardware czasem jeszcze coś można dostać,
> dla software -- z rzadka.

No wlasnie. Mam konkretny HW. Domyslnie oni gwarantuja, ze jalowy HW
bedzie dzialal dobrze.
Ale dostawca instaluje OS np. Linux lub Windows. Nie bardzo mam dane,
ale moge przyjac,
ze to bedzie X (OS availability w zaleznosci od HW).

> Poważna trudność to common failure modes -- dla
> software to np. bug w stosie komunikacyjnym powodujący, że jak przyjdzie jakiś
> tam komunikat to stos się wywala. I jeden dobrze rozpropagowany komunikat
> wykłada nam cały sytetm z fafset "niezależnych" komponentów.

Wiem. Wlasnie takie analizy mam - czyli wiadomo co nalezy do SPOF.
Rowniez mam definicje kiedy nasz klient uwaza, ze system lezy nawet
jesli
komunikacja dziala i niektore moduly dzialaja, ale jakas informacja
nie jest dostarczana
i system calosc nie jest sprawna.

> Tak czy siak potrzeba wiele szacować.

Jasne.

> Możemy wtedy napisać że mamy dostępność 9.997. Albo, co tu jest istotne(!) możemy
> napisać że jest np. 9.999 albo po prostu 100% -- a czas niedostępności bierzemy
> na klatę i na kary umowne za niedostępność powyżej dopuszczalnego limitu.

Tak to jest rozwiazanie, ale unikamy takich trikow.

> Pojawiło się całkiem sporo serwisów gwarantujących po prostu dostępność 100% --
> a realny czas niedostępności refundują w ramach gwarancji.

Tak, ale to jest chwyt prawniczy a nie techniczna analiza
zagadnienia :-).

Pozdrawiam,

--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
Professionalism in programming - www.accu.org

do góry

Witam,

> > Calosc jako okreslona funkcjonalnosc.
>
> Jeśli w ramach funkcjonalności określamy też przepustowość, to sprawa
> znów się może skomplikować. System dający się obciążać w połowie
> gwarantowanego obciążenia to jak rozumiem niedziałający.

No tu to mamy ciekawie. Mamy podany konkretny profil jaki ma spelniac
przepustostowosc. Profil uwzglednia nastepujace fakty:

1. Maksymalny pik przepustowosci, ale ma tez podany maksymalny czas
trwania tego piku.

2. Jest tez podany przedzial czasu w ktorym pewien typowy strumien ma
byc obslugiwany, ale jesli w czasie obslugi typowego strumienia pojawi
sie
pik, to "calka sumy piku i normalnego strumienia" nie moze
przekraczac
konkretnej wartosci. Mowiac ogolnie bufory systemu moga sie wysycic,
ale maja czas na oproznianie sie. To jest system w ktorym pamiec nie
jest tania wiec bufory musza byc limitowane :-).

Np. pik 100 moze trwac 30 minut. Typowy strumien 70 musi byc caly czas
obslugiwany. Ale kiedy w konketnym przedziale np. 2 h pojawia sie pik
100,
przez 30 minut to profil moze byc nastepujacy:

100 (30 min), 70 (1 h), 40 (30 min)

Wartosc 40 pojawia sie, aby skompensowc nadwyzke 100 w stosunku do 70
ktora pojawila sie przez 30 minut.

Pozdrawiam,

--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
Professionalism in programming - www.accu.org

do góry

Witam,

> Jakbys zpodal mi dane, to bym zrobil symulacje MC.

Co to znaczy?

Pozdrawiam,

--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
Professionalism in programming - www.accu.org

do góry

W dniu 2011-07-20 10:34, Seweryn Habdank-Wojewódzki pisze:
> Witam,
>
>>> Calosc jako okreslona funkcjonalnosc.
>>
>> Jeśli w ramach funkcjonalności określamy też przepustowość, to sprawa
>> znów się może skomplikować. System dający się obciążać w połowie
>> gwarantowanego obciążenia to jak rozumiem niedziałający.
>
> No tu to mamy ciekawie. Mamy podany konkretny profil jaki ma spelniac
> przepustostowosc. Profil uwzglednia nastepujace fakty:
[...]

No to już samo określenie, jakie jest prawdopodobieństwo utrzymania
wymaganej przepustowości w takich warunkach to niezłe zadanie.

> 1. Maksymalny pik przepustowosci, ale ma tez podany maksymalny czas
> trwania tego piku.

Najprościej pozostawić tylko warunek dla piku (jeśli system nie jest
przygotowany na pik, to nie działa). Wtedy oszacowanie będzie
pesymistyczne.

> 2. Jest tez podany przedzial czasu w ktorym pewien typowy strumien ma
> byc obslugiwany, ale jesli w czasie obslugi typowego strumienia pojawi
> sie
> pik, to "calka sumy piku i normalnego strumienia" nie moze
> przekraczac
> konkretnej wartosci. Mowiac ogolnie bufory systemu moga sie wysycic,
> ale maja czas na oproznianie sie. To jest system w ktorym pamiec nie
> jest tania wiec bufory musza byc limitowane :-).
>
> Np. pik 100 moze trwac 30 minut. Typowy strumien 70 musi byc caly czas
> obslugiwany. Ale kiedy w konketnym przedziale np. 2 h pojawia sie pik
> 100,
> przez 30 minut to profil moze byc nastepujacy:
>
> 100 (30 min), 70 (1 h), 40 (30 min)
>
> Wartosc 40 pojawia sie, aby skompensowc nadwyzke 100 w stosunku do 70
> ktora pojawila sie przez 30 minut.

Tu będzie bardzo ciężkie zadanie. Oprócz prawdopodobieństw różnych
profili danych trzeba uwzględnić prawdopodobieństwa awarii dające takie
a nie inne przepustowości. Np. awaria degradująca przepustowość do 50
może być niezauważona w okresie "relaksacji" (o ile nie padnie element
odpowiedzialny za bufory lub przesyłanie zebranych wcześniej danych
dalej - kolejny warunek). Awaria degradująca przepustowość do 75 będzie
nieistotna poza pikiem (a może również jeśli pokryje się minimalnie
z pikiem). Awaria trwa jakiś czas, piki trwają jakiś czas (z jakimś
pewnie rozkładem...

Strzelam, że końcowy wynik obliczeń dostępności w takim modelu będzie
estymacją z takim rozrzutem, że bezpieczniej przyjąć jako warunek
dostępności po prostu warunek obsługi piku.

--
Paweł Kierski
n...@p...net

do góry