„Információs rendszerek üzemeltetése - Számolós feladatok kidolgozása” változatai közötti eltérés
A VIK Wikiből
jav. szekció |
Nincs szerkesztési összefoglaló |
||
15. sor: | 15. sor: | ||
#: [[Információs_rendszerek_üzemeltetése_(IRÜ)_-_Vizsgakérdések#Rendelkez.C3.A9sre_.C3.A1ll.C3.A1sok]] | #: [[Információs_rendszerek_üzemeltetése_(IRÜ)_-_Vizsgakérdések#Rendelkez.C3.A9sre_.C3.A1ll.C3.A1sok]] | ||
# 31536 / 4 = 7884 mp | # 31536 / 4 = 7884 mp | ||
# Karbantartási idő = ( Frissítési idő + Teszt idő + Visszakozz-idő + Visszakozz-teszt idő ) * (biztonsági szorzó [2..3]) [ | # Karbantartási idő = ( Frissítési idő + Teszt idő + Visszakozz-idő + Visszakozz-teszt idő ) * (biztonsági szorzó [2..3]) [https://www.tmit.bme.hu/sites/default/files/IRU_2016_4_Serv_deskt.pdf] | ||
#: ( 20 + 25 + 15 + 25 ) * [2..3] = 170-255 perc | #: ( 20 + 25 + 15 + 25 ) * [2..3] = 170-255 perc | ||
# Legalább 25 + 15 = 40 perccel a határidő lejárta előtt | # Legalább 25 + 15 = 40 perccel a határidő lejárta előtt | ||
#: Frissítésre szánt idő=Karbantartási idő – visszakozz-idő – sikerességi teszt [ | #: Frissítésre szánt idő=Karbantartási idő – visszakozz-idő – sikerességi teszt [https://www.tmit.bme.hu/sites/default/files/IRU_2016_4_Serv_deskt.pdf] | ||
# Redundáns szerverek használata | # Redundáns szerverek használata | ||
A lap jelenlegi, 2016. április 24., 20:22-kori változata
Rendelkezésre állás
1. feladat
Spórolós Kft.-nél, ahol 0 a redundancia, te vagy a rendszergazda.
- Három kilences rendelkezésre állásnál hány másodperc lehet a kiesés? (Egy év 31536000 másodpercből áll)
- Mennyi a negyedéves ablak, ha nincs tervezett leállás?
- A legkomplexebb szerver frissítési ideje 20p, a visszakozz ideje 15p, a tesztelés meg 25p. Mennyi időt szánsz a karbantartásra?
- Ha látod, hogy nem fog sikerülni a tesztelés, mikor kezded el a visszakozást?
- Mivel látod, hogy nem fogsz beleférni az időkeretbe, milyen használható ötlettel állsz elő a vezetésnél?
- Megoldás
- 31536000 * ( 1 - 0.999 ) = 31536 mp
- 31536 / 4 = 7884 mp
- Karbantartási idő = ( Frissítési idő + Teszt idő + Visszakozz-idő + Visszakozz-teszt idő ) * (biztonsági szorzó [2..3]) [1]
- ( 20 + 25 + 15 + 25 ) * [2..3] = 170-255 perc
- Legalább 25 + 15 = 40 perccel a határidő lejárta előtt
- Frissítésre szánt idő=Karbantartási idő – visszakozz-idő – sikerességi teszt [2]
- Redundáns szerverek használata
2. feladat
A következő feladat és megoldás a hivatalos diából származik: http://medialab.bme.hu/targy_fileok/VITMA314/Slide/IRU_2013_Ism_Hal_Serv_deskt_1.pdf
Háromfős IT csapatával egy rendszert üzemeltet, amelyben 4 szerver és 30 desktop gép van. A vezetés rossz pénzügyi politikája miatt a rendszer nem redundáns.
- Három kilences rendelkezésre állást feltételezve, éves átlagban (egy év 31 536 000 másodpercből áll) mennyi ideig megengedhető, hogy ne működjön a rendszer?
- Tervezetlen leállás nincs a rendszerben. Ez esetben mekkora a negyedéves szerver-karbantartási ablak?
- A legkomplexebb szerveren a frissítési idő 20 perc. A régi rendszer visszaállítása 15 percet vesz igénybe. A rendszer akármilyen állapotban történő tesztelésére 10 perc kell.
- Mennyi időt tervez ennek a szervernek a karbantartására?
- Ha látszik, hogy nem sikerül a frissítés, mikor kezdi a visszakozzt?
- Három kilences rendelkezésre állás = az idő 99,9%-ában jó, 100% - 99,9%-ában (0,001) rossz.
- 31 536 000 * 0,001 = 31 536 másodperc (~ 8 és ¾ óra)
- Nincs tervezetlen leállás -> az előző pontban kiszámolt a tervezett leállás (karbantartás) egy évben
- Negyedéves: 31 536 / 4 = 7884 másodperc
- (~ 2 óra 11 perc)
-
- 20 perc update + 10 perc teszt + 15 perc visszakozz + 10 perc teszt = 55 perc - szorozva 2..3 közötti számmal, a biztonság kedvéért.
- De maximum a karbantartási ablak (2 óra 11 perc)!
- A karbantartási ablak vége előtt 15 perc (visszakozz) + 10 perc (teszt) = 25 perccel
- 20 perc update + 10 perc teszt + 15 perc visszakozz + 10 perc teszt = 55 perc - szorozva 2..3 közötti számmal, a biztonság kedvéért.
Biztonsági mentés
- Feladat
Inkrementális mentéses feladat (10p): 3TB adat, napi 20% változás, vasárnap full mentés.
- mennyi adatot mentünk le 4 hét alatt?
- 200GB/órás sebességű eszközökkel az egyes napokon meddig tart a mentés?
- hány eszközt használjunk a mentéshez, ha azt akarjuk, hogy mindig beleférjen 8 órába?
- hány média kell az összes mentéshez, ha minden mentés külön médiára megy és a kapacitásuk 500GB?
- max hány média kell egy adott időpontra való visszaállításhoz?
- Megoldás
- Inkrementális mentést alkalmazunk, ezért hétfőtől szombatig minden nap: 3000*0.2=600 GB adat. Mivel 6 ilyen nap van: 6*600=3600.
- Hozzávesszük a vasárnapi teljes mentést: 3000 GB Tehát a héten összesen 3600+3000 = 6600GB.
- Mivel 4 hét volt a kérdés, ezért: 4*6600 = 26400 GB.
- Hozzávesszük a vasárnapi teljes mentést: 3000 GB Tehát a héten összesen 3600+3000 = 6600GB.
- Hétfőtől szombatig minden nap: 3 óra. Vasárnap: 15 óra.
- 2 eszközt, a vasárnap miatt.
- Ez a kérdés nem volt egyértelmű, ezért a vizsga közben mondták, hogy konkrétan az a) feladat beli mentésre gondolnak.
- Hétfőtől szombatig minden nap 2 média szükséges -> 12 média
- Vasárnap 6 média kell. Tehát egy héten 18 média kell.
- Mivel 4 hét van, ezért 4*18=72 média szükséges összesen.
- Legrosszabb eset, amikor a legtöbb média kell: szombat. Ekkor vissza kell állítani az elöző vasárnapi mentést, valamint a hétköznapi mentéseket is. Ez 6+6*2= 18 médiát takar.
Jitter
- Feladat
24 frames/s-es video szolgáltatás. 24 Mbit/s-es vonalon. SLS 0.25 sec-es max késleltetést garantál. A hálózat 0.05 sec-es késleltetést ad max.
- Mekkora buffer szükséges?
- Mekkora jitter-buffer kell, ha 1000 felhasználónk van, akinek átlag 20%-a használja egyidejűleg a szolgáltatást?
- Megoldás
- ( SLS - hálózati)* átviteli sebesség = ( 0.25s - 0.05s ) * 24Mb/s = 4.8Mb
- 4.8Mb * 1000 = 4800Mb
A második megoldásnál javítás szerint azért 1000, mert annyi emberre vállaltuk a szolgáltatást nem 200-ra.