Practic, fiecare specialist IT se confruntă cu situația când este necesar să se calculeze disponibilitatea sistemului și, dat fiind că acesta este ușor, nu este suficient. Astăzi vom vorbi despre cum să facem un calcul aproximativ, dar destul de practic.
Să începem cu definițiile conceptelor de bază. În primul rând, pentru a înțelege cât de mare ar trebui să fie o pregătire pentru diferite clase de sisteme, este necesar să înțelegeți termenii de bază. Cum este gata sistemul?
Gradul de pregătire al sistemului este descris prin factorul de disponibilitate, în timp ce este o cantitate fără dimensiuni și nu poate fi mai mare de 1
Apropo, de ce deranjează calcularea pregătirii sistemului? Și cum să înțelegem coeficientul rezultat? Este clar că o abordare mai aprofundată și mai detaliată, cu un număr mare de indicatori, va oferi rezultate mai precise, dar este de obicei necesar să se obțină date despre sistemul existent sau propus care ne-ar permite să începem munca practică.
De fapt, coeficientul obținut reflectă intervalul de timp pe care sistemul îl poate "permite" să stea inactiv pentru o perioadă de timp.
Cum putem calcula acest coeficient? Conform GOST 27.002-89 factorul de disponibilitate este „probabilitatea ca subiectul este în stare de funcționare, la un moment arbitrar, alta decât perioadele programate în care obiectul de aplicare nu este furnizat la destinație“ [1]. La rândul său, starea de funcționare în conformitate cu GOST 27.002-89 - o „stare a obiectului, în care valorile parametrilor care caracterizează capacitatea de a îndeplini funcțiile predeterminate corespunzătoare cerințelor și (sau) de proiectare (proiectare) documentația tehnică“ [2]. În general, aceasta poate fi scrisă după cum urmează:
- - factor de disponibilitate a sistemului (Kg)
- - timpul total al obiectului în stare de funcționare
- - timpul de recuperare total al obiectului
Dar unde să obțineți acești indicatori de timp pentru a calcula coeficientul? De obicei, specialiștii IT au date foarte diferite - numărul de servere, procesoare, memorie etc. De fapt, pentru a găsi parametrii potriviți, trebuie să faceți următoarele:
- Desenați o schemă arhitecturală a sistemului
- Transformați-o la o logică
- Împărțiți în module cu conexiune serială / paralelă a componentelor
- Calculați gradul de pregătire pentru module
- Efectuați un calcul de pregătire pentru sistem în ansamblul său
Deci, să arătăm acești pași.
Schema arhitecturală a sistemului este un set de obiecte (echipamente) incluse în schemă, împreună cu comunicările lor. Unul dintre diagramele care descriu arhitectura sistemului este prezentat clar în figura următoare:
Fig.1. O diagramă care reflectă arhitectura sistemului
Figura 2 ilustrează procesul de transformare de la un tip de sistem la altul.
Fig.2. Convertiți o schemă de arhitectură într-una logică și împărțiți-o în module
De obicei se crede că cu cât este mai mare disponibilitatea sistemului, cu atât este mai bine - este în întregime logică. De asemenea, se crede că, dacă sistemul este duplicat, atunci disponibilitatea sistemului va fi de două ori mai mare.
Totuși, acest lucru nu este cazul. Logica acestei propuneri este clar: nu a existat un singur sistem - a devenit de două, de 2 ori mai mult decât elementele, iar dacă unul cade, celălalt „sprijin“ - prin urmare, disponibilitatea sistemului ar trebui să fie de două ori mai mult.
Ne-am promis să nu aglomerați articolul cu concluzii greoaie ale formulelor, așa că le dăm mai jos doar pentru a ilustra raționamentul nostru. Principalul lucru este că calculul ia în considerare modul în care obiectele (echipamentele) sunt conectate în interiorul sistemului. Pentru o conexiune serială sau paralelă, pregătirea este tratată diferit, ceea ce afectează în final rezultatul final pentru întregul sistem.
Probabilitatea funcționării fără defecțiuni a sistemului se calculează astfel:
- pentru conexiune serială
- pentru conectare paralelă
De exemplu, presupuneți că disponibilitatea unui singur server este 0.99. În cazul unui cluster, factorul de disponibilitate al sistemului va fi, conform formulelor, 0,9999:
Trebuie remarcat faptul că disponibilitatea nu a crescut de 2 ori, dar cu 2 ordine de mărime, i. E. a devenit mai bun de 100 (!) de ori.
Să luăm în considerare un exemplu, pe care l-am arătat mai devreme în Fig.1. Să presupunem că pentru fiecare element există deja valori ale lui K, astfel încât calcularea factorului de disponibilitate pentru fiecare modul este destul de simplă:
De asemenea, pe baza acestor formule, se poate observa că:
Factorul de disponibilitate a sistemului nu poate fi mai mare decât cea mai mică disponibilitate între componentele sistemului în cazul unei conexiuni seriale.
Atunci când se creează un cluster, disponibilitatea sistemului crește de cel puțin 10 ori, cu condiția ca Kg a elementului să fie mai mare de 0,9.
Astfel, rezultatul este obținut:
Să revenim la întrebarea de la începutul articolului: ce înseamnă acest număr? Tabelul de mai jos arată corespondența dintre factorul de disponibilitate și timpul de mers în gol al sistemului.
Tabelul 1. Conformitatea disponibilității și a timpului de inactivitate
Astfel, rezultatul obținut al factorului de disponibilitate de la exemplul din imagine înseamnă că timpul total de oprire a întregului sistem într-un an va fi de 2,8 minute. Dacă luăm în considerare un alt exemplu descris în acest articol, prezența unui server cu Kr = 0.99 a însemnat un sistem simplu de 3.65 zile. Adăugarea unui alt server în cluster a redus perioada de downtime la 52 de minute.
Deci, rata de disponibilitate va indica momentul în care afacerea încetează să primească suport pentru serviciile sale din sistemul informatic. Aici trebuie să înțelegem în mod clar că următoarele date ar trebui să fie obținute din timpul de întrerupere a sistemului primite:
- Cati bani vor pierde afacerea in lipsa de sprijin din partea IT pentru timpul estimat? Faptul este că, în funcție de specificul producției / afacerii, lipsa suportului poate avea un impact foarte puternic asupra afacerilor și aproape că nu afectează. De exemplu, pentru un mare furnizor de telecomunicații sau o bancă, oprirea sistemului de facturare începe imediat să producă pierderi uriașe. Dar pentru unele industrii nu se va întâmpla nimic în mod special "teribil" - în special în cazul în care procesul direct de producție este controlat de oameni, iar sistemele informatice procesează numai informații secundare.
- Luați în considerare pierderile indirecte (deteriorarea imaginii, trecerea clienților către concurenți sau respingerea serviciilor etc.).
Aici este necesar să se înțeleagă în mod clar, decizia privind nivelul necesar de pregătire este luată de afaceri, nu de IT. Ce înseamnă asta? Aceasta înseamnă că, în mod ideal, CIO oferă liderilor de afaceri un tabel în care sunt marcate următoarele coloane:
- Disponibilitate (diferite opțiuni sau niveluri)
- Timpii inactivi care corespund acestor coeficienți
- Câți bani aveți nevoie pentru a achiziționa - pentru a ajunge la un anumit nivel
- O coloană goală pe care afacerea trebuie să o umple: cât de mult
Acces limitat
Pentru a citi versiunea completă a articolului, trebuie să vă conectați ca utilizator înregistrat.
A plăcut 4 persoane
Orice reproducere este interzisă.
Orice reproducere este interzisă.
Editura "Expert RP" SRL, Rusia, 196608, Pușkin, Leningradskaya Str. d. 10
Articole similare
Trimiteți-le prietenilor: