Esittely
Tietojärjestelmä käyttäjän näkökulmasta on määritelty hyvin GOST RV 51987:ssä - "automaattisessa järjestelmässä, jonka tulos on lähtötietojen esittäminen myöhempää käyttöä varten." Jos tarkastelemme sisäistä rakennetta, niin pohjimmiltaan mikä tahansa IS on koodiin toteutettu toisiinsa yhdistettyjen algoritmien järjestelmä. Turing-Churchin teesin laajassa merkityksessä algoritmi (tai IS) muuntaa joukon syöttödataa joukoksi lähtötietoa.
Voidaan jopa sanoa, että syöttötietojen muuntaminen on tietojärjestelmän olemassaolon tarkoitus. Vastaavasti IS:n ja koko IS-kompleksin arvo määritetään tulo- ja lähtödatan arvon kautta.
Tämän perusteella suunnittelun tulee alkaa ja olla datalähtöistä, räätälöimällä arkkitehtuuri ja menetelmät datan rakenteeseen ja merkitykseen.
Tallennetut tiedot
Keskeinen vaihe suunnittelun valmistelussa on kaikkien käsittelyyn ja varastointiin suunniteltujen tietokokonaisuuksien ominaisuuksien saaminen. Näitä ominaisuuksia ovat mm.
- Tietojen määrä;
— Tiedot tietojen elinkaaresta (uusien tietojen kasvu, elinikä, vanhentuneiden tietojen käsittely);
— Tietojen luokittelu näkökulmasta vaikutus yrityksen ydinliiketoimintaan (luottamuksellisuuden, eheyden, käytettävyyden kolmikko) sekä taloudelliset indikaattorit (esimerkiksi tietojen katoamisen kustannukset viimeisen tunnin aikana);
— Tietojenkäsittelyn maantiede (käsittelyjärjestelmien fyysinen sijainti);
— Sääntelyvaatimukset kullekin tietoluokalle (esimerkiksi Federal Law-152, PCI DSS).
Tietojärjestelmä
Tietoja ei vain tallenneta, vaan tietojärjestelmät myös käsittelevät (muuntavat). Seuraava vaihe tietojen ominaisuuksien hankkimisen jälkeen on täydellisin luettelo tietojärjestelmistä, niiden arkkitehtonisista ominaisuuksista, keskinäisistä riippuvuuksista ja infrastruktuurivaatimuksista tavanomaisissa yksiköissä neljälle resurssityypille:
— Prosessorin laskentateho;
— RAM-muistin määrä;
— Tietojen tallennusjärjestelmän määrää ja suorituskykyä koskevat vaatimukset;
— Tiedonsiirtoverkkoa koskevat vaatimukset (ulkoiset kanavat, kanavat IS-komponenttien välillä).
Tässä tapauksessa jokaiselle palvelulle/mikropalvelulle on asetettava vaatimukset osana IS:tä.
Erikseen on syytä huomata, että oikean suunnittelun kannalta tietojen saatavuus IS:n vaikutuksesta yrityksen ydinliiketoimintaan IS:n seisokkien kustannusten muodossa (ruplaa tunnissa) on pakollista.
Uhkamalli
Uhista tulee olla muodollinen malli, jolta dataa/palveluita suunnitellaan suojaamaan. Lisäksi uhkamalli sisältää luottamuksellisuuden lisäksi myös eheyden ja saatavuuden. Nuo. Esimerkiksi:
— fyysisen palvelimen vika;
— Telineen yläosan kytkimen vika;
— Tietokeskusten välisen optisen viestintäkanavan häiriö;
— Koko toimivan varastointijärjestelmän vika.
Joissakin tapauksissa uhkamalleja ei kirjoiteta vain infrastruktuurikomponenteille, vaan myös tietyille tietojärjestelmille tai niiden komponenteille, kuten DBMS-vika, jossa tietorakenne tuhoutuu loogisesti.
Kaikki hankkeessa tehdyt päätökset suojautua kuvailemattomalta uhalta ovat tarpeettomia.
Sääntelyvaatimukset
Jos käsiteltäviin tietoihin sovelletaan sääntelyviranomaisten vahvistamia erityisiä sääntöjä, vaaditaan tietoja tietokokonaisuuksista ja käsittely-/säilytyssäännöistä.
RPO/RTO-tavoitteet
Minkä tahansa suojauksen suunnittelu edellyttää tavoitetietojen häviämisindikaattoreita ja tavoitepalvelun palautumisaikaa kullekin kuvatulle uhille.
Ihannetapauksessa RPO:lla ja RTO:lla pitäisi olla siihen liittyvät tiedon menettämisestä ja seisokeista aiheutuvat kustannukset aikayksikköä kohti.
Jako resurssiryhmiin
Kun kaikki alustavat syöttötiedot on kerätty, ensimmäinen askel on ryhmitellä tietojoukot ja IP pooleihin uhkamallien ja sääntelyvaatimusten perusteella. Eri poolien jaon tyyppi määritetään - ohjelmallisesti järjestelmäohjelmistotasolla tai fyysisesti.
Esimerkkejä:
— Henkilötietoja käsittelevä piiri on täysin fyysisesti erotettu muista järjestelmistä;
— Varmuuskopiot tallennetaan erilliseen tallennusjärjestelmään.
Tässä tapauksessa poolit voivat olla epätäydellisesti riippumattomia, esimerkiksi määritellään kaksi laskentaresurssien poolia (prosessorin teho + RAM), jotka käyttävät yhtä tietovarastoa ja yhtä tiedonsiirtoresurssipoolia.
Prosessointiteho
Tiivistelmä, virtualisoidun datakeskuksen prosessointitehovaatimuksia mitataan virtuaalisten prosessorien (vCPU) lukumäärällä ja niiden yhdistämissuhteella fyysisiin prosessoreihin (pCPU). Tässä nimenomaisessa tapauksessa 1 pCPU = 1 fyysinen prosessoriydin (paitsi Hyper-Threading). VCPU:iden määrä lasketaan yhteen kaikista määritellyistä resurssipoolista (joilla jokaisella voi olla oma konsolidointitekijänsä).
Kuormitettujen järjestelmien konsolidointikerroin saadaan empiirisesti, olemassa olevan infrastruktuurin perusteella tai pilottiasennuksella ja kuormitustestauksella. Kuormittamattomissa järjestelmissä käytetään "parasta käytäntöä". Erityisesti VMware mainitsee keskimääräiseksi suhteeksi 8:1.
Käyttömuisti
RAM-muistin kokonaistarve saadaan yksinkertaisella summauksella. RAM-muistin ylitilauksen käyttöä ei suositella.
Tallennusresurssit
Varastointivaatimukset saadaan laskemalla yhteen kaikki poolit kapasiteetin ja suorituskyvyn mukaan.
Suorituskykyvaatimukset ilmaistaan IOPS:nä yhdistettynä keskimääräiseen luku/kirjoitussuhteeseen ja tarvittaessa maksimivasteen latenssiin.
Palvelun laatuvaatimukset (QoS) tietyille pooleille tai järjestelmille on määriteltävä erikseen.
Tietoverkon resurssit
Tietoverkkovaatimukset saadaan yksinkertaisesti summaamalla kaikki kaistanleveyspoolit.
Palvelun laatu (QoS) ja latenssi (RTT) -vaatimukset tietyille poolille tai järjestelmille on määriteltävä erikseen.
Osana tietoverkkoresursseja koskevia vaatimuksia ilmoitetaan myös verkkoliikenteen eristämistä ja/tai salausta koskevat vaatimukset ja suositellut mekanismit (802.1q, IPSec jne.).
Arkkitehtuurin valinta
Tässä oppaassa ei käsitellä muita vaihtoehtoja kuin x86-arkkitehtuuri ja 100 % palvelimen virtualisointi. Siksi tietojenkäsittelyn osajärjestelmän arkkitehtuurin valinta riippuu palvelimen virtualisointialustan, palvelimen muototekijän ja yleisten palvelimen kokoonpanovaatimusten valinnasta.
Valinnan avainkohta on varmuus käyttää klassista lähestymistapaa, jossa tietojen käsittelyn, tallennuksen ja siirron toiminnot on erotettu toisistaan tai konvergentti.
klassista arkkitehtuuria sisältää älykkäiden ulkoisten alijärjestelmien käytön tietojen tallentamiseen ja lähettämiseen, kun taas palvelimet lisäävät vain prosessointitehoa ja RAM-muistia yhteiseen fyysisten resurssien pooliin. Äärimmäisissä tapauksissa palvelimista tulee täysin anonyymejä, ja niillä ei ole vain omia levyjä, mutta ei edes järjestelmätunnistetta. Tässä tapauksessa käyttöjärjestelmä tai hypervisor ladataan sisäänrakennetulta flash-medialta tai ulkoisesta tallennusjärjestelmästä (käynnistetään SAN:sta).
Klassisen arkkitehtuurin puitteissa valinta terien ja telineiden välillä tehdään ensisijaisesti seuraavien periaatteiden perusteella:
— Kustannustehokas (keskimäärin telineeseen asennettavat palvelimet ovat halvempia);
— Laskennallinen tiheys (korkeampi terien osalta);
— Energiankulutus ja lämmönpoisto (terien ominaisyksikkö yksikköä kohti on suurempi);
— Skaalautuvuus ja hallittavuus (terät vaativat yleensä vähemmän vaivaa suurissa asennuksissa);
- Laajennuskorttien käyttö (erittäin rajoitettu valikoima teriä).
Konvergentti arkkitehtuuri (tunnetaan myös hyperkonvergoitunut) sisältää tietojenkäsittelyn ja tallennuksen toimintojen yhdistämisen, mikä johtaa paikallisten palvelinlevyjen käyttöön ja sen seurauksena perinteisestä korttimuodosta luopumiseen. Konvergoiduissa järjestelmissä käytetään joko telinepalvelimia tai klusterijärjestelmiä, jotka yhdistävät useita korttipalvelimia ja paikallisia levyjä yhdessä kotelossa.
CPU / Muisti
Määrityksen laskemiseksi oikein sinun on ymmärrettävä ympäristön tai kunkin itsenäisen klusterin kuormitustyyppi.
CPU sidottu – ympäristö, jonka suorituskykyä rajoittaa prosessorin teho. RAM-muistin lisääminen ei muuta mitään suorituskyvyn kannalta (VM:ien määrä palvelinta kohti).
Muisti sidottu – RAM-muistin rajoittama ympäristö. Enemmän RAM-muistia palvelimella voit ajaa enemmän virtuaalikoneita palvelimella.
GB / MHz (GB / pCPU) – RAM-muistin ja prosessorin tehon kulutuksen keskimääräinen suhde tällä kuormalla. Voidaan käyttää laskemaan tarvittava määrä muistia tietylle suorituskyvylle ja päinvastoin.
Palvelimen konfigurointilaskenta
Ensin sinun on määritettävä kaikentyyppiset kuormitukset ja päätettävä eri laskentaryhmien yhdistämisestä tai jakamisesta eri klustereiksi.
Seuraavaksi kullekin määritellylle klusterille määritetään GB/MHz-suhde ennalta tunnetulla kuormalla. Jos kuormitusta ei tiedetä etukäteen, mutta prosessorin tehonkäyttötasosta on karkea käsitys, voit käyttää tavallisia vCPU:pCPU-suhteita muuntaaksesi poolivaatimukset fyysisiksi.
Jaa kunkin klusterin vCPU-varannon summa kertoimella:
vCPUsum / vCPU:pCPU = pCPUsum – tarvittava määrä fyysisiä yksiköitä. ytimet
pCPUsum / 1.25 = pCPUht – Hyper-Threadingille säädettyjen ytimien määrä
Oletetaan, että on tarpeen laskea klusteri, jossa on 190 ydintä / 3.5 TB RAM-muistia. Samalla hyväksymme tavoitekuormituksen 50 % prosessorin tehosta ja 75 % RAM:sta.
pCPU
190
CPU käyttö
50%
Mem
3500
Mem-apuohjelma
75%
Pistorasia
Ydin
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
Tässä tapauksessa käytämme aina pyöristystä ylöspäin lähimpään kokonaislukuun (=ROUNDUP(A1;0)).
Taulukosta käy ilmi, että useita palvelinkokoonpanoja on tasapainotettu kohdeindikaattoreille:
— 26 palvelinta 2*6c / 192 Gt
— 19 palvelinta 2*10c / 256 Gt
— 10 palvelinta 2*18c / 512 Gt
Näiden kokoonpanojen valinta on sitten tehtävä lisätekijöiden, kuten lämpöpaketin ja käytettävissä olevan jäähdytyksen, jo käytettyjen palvelimien tai kustannusten perusteella.
Palvelinkokoonpanon valinnan ominaisuudet
Leveät VM:t. Jos on tarpeen isännöidä leveitä virtuaalikoneita (verrattavissa 1 NUMA-solmuun tai useampaan), on suositeltavaa, jos mahdollista, valita palvelin, jonka kokoonpano sallii tällaisten virtuaalikoneiden pysymisen NUMA-solmun sisällä. Suuri määrä leveitä virtuaalikoneita on vaarana klusteriresurssien pirstoutumisesta, ja tällöin valitaan palvelimet, jotka mahdollistavat leveiden virtuaalikoneiden sijoittamisen mahdollisimman tiheään.
Yhden virheen verkkotunnuksen koko.
Palvelimen koon valinta perustuu myös yksittäisen virhealueen minimoimisen periaatteeseen. Esimerkiksi kun valitset seuraavista:
- 3 x 4*10c / 512 Gt
- 6 x 2*10c / 256 Gt
Jos kaikki muut asiat ovat samat, sinun on valittava toinen vaihtoehto, koska kun yksi palvelin epäonnistuu (tai sitä ylläpidetään), klusterin resursseista ei katoa 33 %, vaan 17 %. Samalla tavalla onnettomuuteen vaikuttaneiden virtuaalikoneiden ja IS:ien määrä puolittuu.
Klassisten tallennusjärjestelmien laskenta suorituskyvyn perusteella
Klassiset tallennusjärjestelmät lasketaan aina pahimmalla mahdollisella skenaariolla, poissulkemalla toiminnallisen välimuistin ja toimintojen optimoinnin vaikutus.
Suorituskyvyn perusindikaattoreina otamme mekaanisen suorituskyvyn levyltä (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS
Seuraavaksi levyvaraston levyjen määrä lasketaan seuraavalla kaavalla: = TotalIOPS * ( RW + (1 – RW) * RAIDPen) / IOPS-levy. Missä:
- TotalIOPS – vaadittu kokonaissuorituskyky IOPS:ssä levyvarannosta
- RW – lukutoimintojen prosenttiosuus
- RAID kynä – RAID-rangaistus valitulle RAID-tasolle
Lue lisää Device RAIDista ja RAID Penaltysta täältä - и и
Tuloksena saadun levymäärän perusteella lasketaan mahdolliset vaihtoehdot, jotka täyttävät tallennuskapasiteettivaatimukset, mukaan lukien vaihtoehdot, joissa on monitasoinen tallennus.
SSD:tä tallennuskerroksena käyttävien järjestelmien laskentaa tarkastellaan erikseen.
Laskentajärjestelmien ominaisuudet Flash-välimuistilla
Flash-välimuisti – yleinen nimi kaikille patentoiduille tekniikoille, joilla flash-muistia käytetään toisen tason välimuistina. Flash-välimuistia käytettäessä tallennusjärjestelmän lasketaan yleensä tarjoavan tasaisen kuormituksen magneettilevyiltä, kun taas piikin palvelee välimuisti.
Tässä tapauksessa on tarpeen ymmärtää kuormitusprofiili ja tallennustilalohkoihin pääsyn lokalisointiaste. Flash-välimuisti on tekniikka työkuormille, joissa on erittäin lokalisoituja kyselyitä, ja sitä ei käytännössä voida soveltaa tasaisesti ladatuissa määrissä (kuten analytiikkajärjestelmissä).
Alemman ja keskitason hybridijärjestelmien laskenta
Alemman ja keskiluokan hybridijärjestelmät käyttävät monitasoista tallennusta, jossa data liikkuu tasojen välillä aikataulun mukaan. Samaan aikaan parhaiden mallien monitasoisen tallennuslohkon koko on 256 Mt. Nämä ominaisuudet eivät salli meidän pitää porrastettua tallennustekniikkaa tuottavuutta lisäävänä teknologiana, kuten monet ihmiset virheellisesti uskovat. Monitasoinen varastointi matalan ja keskiluokan järjestelmissä on tekniikka, jolla optimoidaan varastointikustannukset järjestelmissä, joissa kuormituksen epätasaisuus on selvä.
Porrastetussa tallennustilassa ylimmän tason suorituskyky lasketaan ensin, kun taas alimman tason katsotaan vain lisäävän puuttuvaa tallennuskapasiteettia. Hybridi-monitasojärjestelmässä on pakollista käyttää flash-välimuistitekniikkaa monitasoisessa poolissa, jotta voidaan kompensoida alemmalta tasolta äkillisesti kuumennetun datan suorituskyvyn heikkeneminen.
SSD:n käyttäminen porrastetussa levyvarastossa
SSD-levyjen käyttö monitasoisessa levyvarastossa vaihtelee riippuen tietyn valmistajan flash-välimuistialgoritmien erityisestä toteutuksesta.
SSD-tason levyvaraston tallennuskäytäntöjen yleinen käytäntö on SSD ensin.
Vain luku - Flash-välimuisti. Vain luku -tilassa olevan flash-välimuistin tapauksessa SSD-levyn tallennuskerros sisältää merkittävän kirjoitusten lokalisoinnin välimuistista riippumatta.
Lue/kirjoita Flash-välimuisti. Flash-välimuistin tapauksessa kirjoitusvälimuistin koko asetetaan ensin välimuistin enimmäiskokoon, ja SSD-tallennustaso näkyy vain, kun välimuistin koko ei riitä palvelemaan koko lokalisoitua työkuormaa.
SSD- ja välimuistin suorituskykylaskelmat tehdään joka kerta valmistajan suositusten perusteella, mutta aina pahimman mahdollisen skenaarion mukaan.
Lähde: will.com