-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.nask.pl!news.nask.org.pl!news.uni-
stuttgart.de!news-2.dfn.de!news.dfn.de!newsfeed.straub-nv.de!zen.net.uk!dedekin
d.zen.co.uk!newsfeed.neostrada.pl!unt-exc-01.news.neostrada.pl!unt-spo-a-01.new
s.neostrada.pl!news.neostrada.pl.POSTED!not-for-mail
Date: Mon, 18 Jul 2011 13:53:15 +0200
From: Sebastian Kaliszewski <s...@r...this.informa.and.that.pl>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
Newsgroups: pl.comp.lang.c,pl.comp.programming
Subject: Re: Dostepnosc systemu - metody formalne
References: <9...@y...googlegroups.com>
<2...@n...googlegroups.com>
In-Reply-To: <2...@n...googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <5...@b...softax.pl>
Lines: 76
Organization: Telekomunikacja Polska
NNTP-Posting-Host: 83.18.189.42
X-Trace: 1310990401 unt-rea-b-01.news.neostrada.pl 3495 83.18.189.42:45911
X-Complaints-To: a...@n...neostrada.pl
Xref: news-archive.icm.edu.pl pl.comp.lang.c:295579 pl.comp.programming:191607
[ ukryj nagłówki ]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)
Następne wpisy z tego wątku
- 18.07.11 18:36 Seweryn Habdank-Wojewódzki
- 19.07.11 11:51 Mariusz Marszałkowski
- 19.07.11 15:21 Paweł Kierski
- 20.07.11 08:24 Seweryn Habdank-Wojewódzki
- 20.07.11 08:34 Seweryn Habdank-Wojewódzki
- 20.07.11 08:35 Seweryn Habdank-Wojewódzki
- 20.07.11 13:07 Paweł Kierski
- 20.07.11 13:21 Mariusz Marszałkowski
- 21.07.11 17:03 Seweryn Habdank-Wojewódzki
- 21.07.11 21:29 Mariusz Marszałkowski
- 22.07.11 17:58 Seweryn Habdank-Wojewódzki
- 22.07.11 21:11 Mariusz Marszałkowski
- 23.07.11 04:16 A.L.
- 23.07.11 08:50 Mariusz Marszałkowski
- 23.07.11 16:21 A.L.
Najnowsze wątki z tej grupy
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
Najnowsze wątki
- 2024-11-25 Karty przedpłacone (podarunkowe) Google Play - pytanie do korzystających
- 2024-11-26 wina Tóska
- 2024-11-26 Rewolucja/Rewelacja!
- 2024-11-25 grupa ożyła ;)
- 2024-11-24 Być jak Clint
- 2024-11-24 Rura kanalizacja konceptu Franke = problem
- 2024-11-25 Wrocław => Lead Java EE Developer <=
- 2024-11-25 Warszawa => Business Development Manager - Network and Network Securit
- 2024-11-25 Kraków => Programista Full Stack (.Net Core) <=
- 2024-11-25 Lublin => Senior PHP Developer <=
- 2024-11-25 Karlino => Konsultant wewnętrzny SAP (FI/CO) <=
- 2024-11-25 Warszawa => ECM Specialist / Consultant <=
- 2024-11-25 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2024-11-25 Warszawa => Senior Frontend Developer (React + React Native) <=
- 2024-11-25 Lublin => Inżynier Serwisu Sprzętu Medycznego <=