Sissejuhatus
Kasutaja seisukohast on infosüsteem täpselt määratletud standardis GOST RV 51987 - "automaatne süsteem, mille tulemuseks on väljundteabe esitamine hilisemaks kasutamiseks." Kui arvestada sisemist struktuuri, siis sisuliselt on iga IS koodis realiseeritud omavahel seotud algoritmide süsteem. Turingi kiriku väitekirja laiemas tähenduses teisendab algoritm (või IS) sisendandmete komplekti väljundandmete kogumiks.
Võiks isegi öelda, et sisendandmete teisendamine on infosüsteemi olemasolu mõte. Vastavalt sellele määratakse IS ja kogu IS kompleksi väärtus sisend- ja väljundandmete väärtuse kaudu.
Sellest lähtuvalt peab projekteerimine algama ja olema andmepõhine, kohandades arhitektuuri ja meetodid vastavalt andmete struktuurile ja olulisusele.
Salvestatud andmed
Disaini ettevalmistamise põhietapp on kõigi töötlemiseks ja salvestamiseks kavandatud andmekogumite omaduste hankimine. Need omadused hõlmavad järgmist:
- Andmemaht;
— teave andmete elutsükli kohta (uute andmete kasv, eluiga, aegunud andmete töötlemine);
— Andmete klassifitseerimine vaatepunktist mõju ettevõtte põhitegevusele (konfidentsiaalsuse, terviklikkuse, kättesaadavuse kolmik) koos finantsnäitajatega (näiteks andmete kadumise maksumus viimase tunni jooksul);
— andmetöötluse geograafia (töötlussüsteemide füüsiline asukoht);
— Iga andmeklassi regulatiivsed nõuded (nt föderaalseadus-152, PCI DSS).
Infosüsteemid
Andmeid mitte ainult ei salvestata, vaid neid töödeldakse (teisendatakse) infosüsteemid. Järgmine samm pärast andmekarakteristikute saamist on infosüsteemide, nende arhitektuuriliste omaduste, vastastikuste sõltuvuste ja infrastruktuuri nõuete kõige täielikum inventuur tavalistes üksustes nelja tüüpi ressursside jaoks:
— protsessori arvutusvõimsus;
- RAM-i maht;
— nõuded andmesalvestussüsteemi mahule ja jõudlusele;
— Nõuded andmeedastusvõrgule (väliskanalid, kanalid IS komponentide vahel).
Sel juhul peavad IS-i osana olema nõuded iga teenuse/mikroteenuse jaoks.
Eraldi tuleb märkida, et korrektse kavandamise jaoks on kohustuslik andmete olemasolu IS-i mõju kohta ettevõtte põhitegevusele IS-i seisaku maksumuse (rubla tunnis) näol.
Ohu mudel
Ohtudest peab olema formaalne mudel, mille eest on plaanis andmeid/teenuseid kaitsta. Lisaks ei hõlma ohumudel mitte ainult konfidentsiaalsuse aspekte, vaid ka terviklikkust ja kättesaadavust. Need. Näiteks:
— füüsilise serveri rike;
— riiuli ülaosa lüliti rike;
— andmekeskuste vahelise optilise sidekanali katkemine;
— kogu toimiva salvestussüsteemi rike.
Mõnel juhul ei kirjutata ohumudelid mitte ainult infrastruktuuri komponentide, vaid ka konkreetsete infosüsteemide või nende komponentide jaoks, näiteks DBMS-i rike koos andmestruktuuri loogilise hävimisega.
Kõik projektisisesed otsused kirjeldamatu ohu eest kaitsmiseks on ebavajalikud.
Regulatiivsed nõuded
Kui töödeldavate andmete suhtes kehtivad reguleerivate asutuste kehtestatud erireeglid, on vajalik teave andmekogumite ja töötlemise/säilitamise reeglite kohta.
RPO/RTO eesmärgid
Mis tahes tüüpi kaitse kavandamine eeldab iga kirjeldatud ohu jaoks sihtandmete kadumise indikaatorite ja teenuse taastamise aja määramist.
Ideaalis peaksid RPO-l ja RTO-l olema seotud andmete kadumise ja seisakutega seotud kulud ajaühiku kohta.
Jagamine ressursikogumiteks
Pärast kogu esialgse sisendteabe kogumist on esimene samm andmekogumite ja IP rühmitamine ohumudelite ja regulatiivsete nõuete alusel kogumiteks. Määratakse erinevate kogumite jaotuse tüüp - programmiliselt süsteemitarkvara tasemel või füüsiliselt.
Näited:
— isikuandmeid töötlev ahel on teistest süsteemidest füüsiliselt täielikult eraldatud;
— Varukoopiaid hoitakse eraldi salvestussüsteemis.
Sel juhul võivad kogumid olla mittetäielikult sõltumatud, näiteks on määratletud kaks arvutusressursside kogumit (protsessori võimsus + RAM), mis kasutavad ühte andmesalvestusbasseini ja ühte andmeedastusressursside kogumit.
Töötlemisvõimsus
Abstraktne, virtualiseeritud andmekeskuse töötlemisvõimsuse nõudeid mõõdetakse virtuaalsete protsessorite (vCPU) arvu ja nende füüsiliste protsessorite (pCPU) konsolideerimissuhte järgi. Sel konkreetsel juhul 1 pCPU = 1 füüsiline protsessori tuum (v.a. Hyper-Threading). VCPU-de arv summeeritakse kõigi määratletud ressursikogumite lõikes (igaühel neist võib olla oma konsolideerimistegur).
Koormatud süsteemide konsolideerimiskoefitsient saadakse empiiriliselt, olemasoleva infrastruktuuri põhjal või pilootinstallatsiooni ja koormustestimise teel. Koormata süsteemide puhul kasutatakse parimat tava. Täpsemalt nimetab VMware keskmiseks suhteks 8:1.
RAM
RAM-i koguvajadus saadakse lihtsa liitmise teel. RAM-i ületellimuse kasutamine ei ole soovitatav.
Salvestusressursid
Ladustamisvajadused saadakse, kui liidetakse lihtsalt kõik basseinid mahu ja jõudluse järgi.
Jõudlusnõuded on väljendatud IOPS-is koos keskmise lugemis-/kirjutussuhtega ja vajadusel maksimaalse vastuse latentsusega.
Teenuse kvaliteedi (QoS) nõuded konkreetsete kogumite või süsteemide jaoks tuleb eraldi täpsustada.
Andmevõrgu ressursid
Andmesidevõrgu nõuded saadakse kõigi ribalaiuse kogumite lihtsalt liitmisel.
Teenusekvaliteedi (QoS) ja latentsusaja (RTT) nõuded konkreetsete kogumite või süsteemide jaoks tuleks täpsustada eraldi.
Andmevõrgu ressursside nõuete raames on välja toodud ka võrguliikluse isoleerimise ja/või krüptimise nõuded ning eelistatud mehhanismid (802.1q, IPSec jne).
Arhitektuuri valik
Selles juhendis ei käsitleta ühtegi muud valikut peale x86 arhitektuuri ja 100% serveri virtualiseerimise. Seetõttu taandub andmetöötluse alamsüsteemi arhitektuuri valik serveri virtualiseerimisplatvormi, serveri vormiteguri ja üldiste serveri konfiguratsiooninõuete valikule.
Valiku põhipunktiks on kindlus klassikalise lähenemisviisi kasutamisel koos andmete töötlemise, salvestamise ja edastamise funktsioonide eraldamisega või konvergentse funktsiooniga.
klassikaline arhitektuur hõlmab intelligentsete väliste alamsüsteemide kasutamist andmete salvestamiseks ja edastamiseks, samas kui serverid annavad ühisesse füüsiliste ressursside kogumisse ainult töötlemisvõimsust ja RAM-i. Äärmuslikel juhtudel muutuvad serverid täiesti anonüümseks, omades mitte ainult oma kettaid, vaid isegi mitte süsteemi identifikaatorit. Sel juhul laaditakse OS või hüperviisor sisseehitatud välkmälukandjalt või välisest andmesalvestussüsteemist (käivitamine SAN-ist).
Klassikalise arhitektuuri raames tehakse valik labade ja nagide vahel eelkõige järgmistel põhimõtetel:
— kulutõhus (keskmiselt on rack-mount serverid odavamad);
— arvutustihedus (labade puhul suurem);
— energiakulu ja soojuse hajumine (teradel on suurem eriühik ühiku kohta);
— Skaleeritavus ja juhitavus (suurte paigalduste puhul nõuavad labad üldiselt vähem pingutust);
- Laienduskaartide kasutamine (labade valik väga piiratud).
Konvergentne arhitektuur (tuntud ka kui hüperkonvergeeritud) hõlmab andmetöötluse ja -salvestuse funktsioonide ühendamist, mis toob kaasa kohalike serveriketaste kasutamise ja sellest tulenevalt loobumise klassikalisest teravormingust. Konvergeeritud süsteemide jaoks kasutatakse kas rack-servereid või klastrisüsteeme, mis ühendavad mitu blade-serverit ja kohalikke kettaid ühes korpuses.
CPU/mälu
Konfiguratsiooni korrektseks arvutamiseks peate mõistma keskkonna või iga sõltumatu klastri koormuse tüüpi.
CPU-ga seotud – protsessori võimsusega piiratud jõudluskeskkond. RAM-i lisamine ei muuda jõudlust (VM-ide arv serveri kohta) midagi.
Mälu seotud - RAM-iga piiratud keskkond. Rohkem RAM-i serveris võimaldab teil serveris käitada rohkem VM-e.
GB / MHz (GB / pCPU) - RAM-i ja protsessori võimsuse tarbimise keskmine suhe selle konkreetse koormuse korral. Saab kasutada etteantud jõudluse jaoks vajaliku mälumahu arvutamiseks ja vastupidi.
Serveri konfiguratsiooni arvutamine
Esiteks peate kindlaks määrama kõik koormuse tüübid ja otsustama, kas kombineerida või jagada erinevad andmetöötluskogumid erinevatesse klastritesse.
Järgmisena määratakse iga määratletud klastri jaoks GB / MHz suhe eelnevalt teadaoleva koormuse juures. Kui koormus pole ette teada, kuid protsessori võimsuskasutuse tasemest on ligikaudne arusaam, saate kasutada standardseid vCPU:pCPU suhteid, et teisendada basseini nõuded füüsilisteks.
Iga klastri jaoks jagage vCPU kogumi nõuete summa koefitsiendiga:
vCPUsum / vCPU:pCPU = pCPUsum – vajalik arv füüsilisi ühikuid. südamikud
pCPUsum / 1.25 = pCPUht – tuumade arv, mis on kohandatud hüperlõime jaoks
Oletame, et on vaja arvutada 190 tuumaga klaster / 3.5 TB RAM. Samal ajal aktsepteerime sihtkoormust 50% protsessori võimsusest ja 75% RAM-ist.
pCPU
190
CPU utiliit
50%
Mem
3500
Mälu utiliit
75%
pesa
tuum
Srv/CPU
Srv Mem
Srv/Mem
2
6
25,3
128
36,5
2
8
19,0
192
24,3
2
10
15,2
256
18,2
2
14
10,9
384
12,2
2
18
8,4
512
9,1
Sel juhul kasutame alati ümardamist ülespoole lähima täisarvuni (=ROUNDUP(A1;0)).
Tabelist selgub, et mitu serverikonfiguratsiooni on sihtindikaatorite jaoks tasakaalustatud:
— 26 serverit 2*6c / 192 GB
— 19 serverit 2*10c / 256 GB
— 10 serverit 2*18c / 512 GB
Nende konfiguratsioonide valik tuleb seejärel teha täiendavate tegurite alusel, nagu termopakett ja saadaolev jahutus, juba kasutatud serverid või hind.
Serveri konfiguratsiooni valimise omadused
Laiad VM-id. Kui on vaja majutada laiaulatuslikke VM-e (võrreldav 1 NUMA-sõlmega või enamaga), on võimalusel soovitatav valida server, mille konfiguratsioon võimaldab sellistel VM-idel jääda NUMA-sõlme. Suure hulga laiade VM-ide puhul on oht klastri ressursside killustumisele ja sel juhul valitakse serverid, mis võimaldavad võimalikult tihedalt paigutada laiu VM-e.
Üksiku rikkega domeeni suurus.
Serveri suuruse valikul lähtutakse ka ühe rikke domeeni minimeerimise põhimõttest. Näiteks kui valite järgmiste vahel:
- 3 x 4*10c / 512 GB
- 6 x 2*10c / 256 GB
Kui kõik muud tingimused on võrdsed, peate valima teise võimaluse, kuna ühe serveri rikke (või hooldamise) korral ei lähe kaotsi mitte 33% klastri ressurssidest, vaid 17%. Samamoodi väheneb õnnetusest mõjutatud VM-ide ja IS-ide arv poole võrra.
Klassikaliste salvestussüsteemide arvutamine jõudluse põhjal
Klassikalised salvestussüsteemid arvutatakse alati halvima stsenaariumi järgi, välistades töövahemälu mõju ja toimingute optimeerimise.
Põhiliste jõudlusnäitajatena võtame kettalt (IOPSdisk) mehaanilise jõudluse:
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS
Järgmisena arvutatakse kettakogumis olevate ketaste arv järgmise valemi abil: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSketas. Kus:
- TotalIOPS – kogu nõutav jõudlus IOPS-is kettakogumist
- RW – lugemistoimingute protsent
- RAID pliiats – RAID-trahv valitud RAID-taseme eest
Lisateavet seadme RAID-i ja RAID-trahvi kohta leiate siit - и и
Saadud ketaste arvu põhjal arvutatakse võimalikud valikud, mis vastavad salvestusmahu nõuetele, sealhulgas mitmetasandilise salvestusega valikud.
SSD-d salvestuskihina kasutavate süsteemide arvutamist käsitletakse eraldi.
Flash-vahemäluga arvutussüsteemide omadused
Flashi vahemälu – kõigi patenteeritud tehnoloogiate üldnimetus välkmälu kasutamiseks teise taseme vahemäluna. Välkmälu kasutamisel arvutatakse salvestussüsteem tavaliselt nii, et see tagab magnetketastelt püsiva koormuse, samal ajal kui tipptaseme teenindab vahemälu.
Sel juhul on vaja mõista koormusprofiili ja salvestusmahtude plokkidele juurdepääsu lokaliseerimise astet. Flash-vahemälu on tehnoloogia väga lokaliseeritud päringutega töökoormuste jaoks ja seda praktiliselt ei saa kasutada ühtlaselt laaditud mahtude jaoks (nt analüüsisüsteemide jaoks).
Madala/keskklassi hübriidsüsteemide arvutamine
Madalama ja keskklassi hübriidsüsteemid kasutavad mitmetasandilist salvestusruumi, kus andmed liiguvad graafiku alusel tasemete vahel. Samal ajal on parimate mudelite mitmetasandilise salvestusploki suurus 256 MB. Need funktsioonid ei võimalda meil pidada mitmetasandilist salvestustehnoloogiat tootlikkuse suurendamise tehnoloogiaks, nagu paljud inimesed ekslikult arvavad. Mitmetasandiline salvestus madala- ja keskklassi süsteemides on tehnoloogia salvestuskulude optimeerimiseks süsteemide puhul, millel on väljendunud koormuse ebaühtlus.
Mitmetasandilise salvestusruumi puhul arvutatakse esmalt ülemise tasandi jõudlus, samal ajal kui alumine salvestustase aitab kaasa ainult puuduvale salvestusmahule. Mitmetasandilise hübriidsüsteemi puhul on mitmetasandilise kogumi jaoks kohustuslik kasutada välkmälu vahemälu tehnoloogiat, et kompenseerida madalama taseme äkitselt kuumenenud andmete jõudluse vähenemist.
SSD kasutamine mitmetasandilises kettakogumis
SSD-de kasutamine mitmetasandilises kettakogumis võib varieeruda sõltuvalt konkreetse tootja välklambi vahemälu algoritmide rakendamisest.
SSD-tasemega kettakogumi salvestuspoliitika üldine tava on kõigepealt SSD.
Kirjutuskaitstud Flash-vahemälu. Kirjutuskaitstud välkmälu puhul on SSD salvestuskihiga kaasas märkimisväärne kirjutiste lokaliseerimine, olenemata vahemälust.
Flash-vahemälu lugemine/kirjutamine. Välkmälu puhul määratakse kirjutusvahemälu suuruseks esmalt maksimaalne vahemälu suurus ja SSD-salvestustasand kuvatakse ainult siis, kui vahemälu maht ei ole kogu lokaliseeritud töökoormuse teenindamiseks piisav.
SSD ja vahemälu jõudlusarvutused tehakse iga kord tootja soovituste põhjal, kuid alati halvima stsenaariumi jaoks.
Allikas: www.habr.com