Pagpapakilala
Ang isang sistema ng impormasyon mula sa pananaw ng gumagamit ay mahusay na tinukoy sa GOST RV 51987 - "isang awtomatikong sistema, ang resulta kung saan ay ang pagtatanghal ng impormasyon ng output para sa kasunod na paggamit." Kung isasaalang-alang natin ang panloob na istraktura, kung gayon sa esensya ang anumang IS ay isang sistema ng magkakaugnay na mga algorithm na ipinatupad sa code. Sa malawak na kahulugan ng Turing-Church thesis, binabago ng isang algorithm (o IS) ang isang set ng input data sa isang set ng output data.
Maaaring sabihin ng isa na ang pagbabago ng data ng pag-input ay ang kahulugan ng pagkakaroon ng isang sistema ng impormasyon. Alinsunod dito, ang halaga ng IS at ang buong IS complex ay tinutukoy sa pamamagitan ng halaga ng input at output data.
Batay dito, ang disenyo ay dapat magsimula at batay sa data, na umaayon sa arkitektura at mga pamamaraan sa istraktura at kahalagahan ng data.
Naka-imbak na data
Ang isang mahalagang yugto sa paghahanda para sa disenyo ay ang pagkuha ng mga katangian ng lahat ng set ng data na binalak para sa pagproseso at pag-iimbak. Kabilang sa mga katangiang ito ang:
- Dami ng data;
— Impormasyon tungkol sa ikot ng buhay ng data (paglago ng bagong data, habang-buhay, pagproseso ng hindi napapanahong data);
- Pag-uuri ng data mula sa punto ng view epekto sa pangunahing negosyo ng kumpanya (ang triad ng pagiging kumpidensyal, integridad, availability) kasama ng mga financial indicator (halimbawa, ang halaga ng pagkawala ng data sa huling oras);
- Heograpiya ng pagproseso ng data (pisikal na lokasyon ng mga sistema ng pagproseso);
— Mga kinakailangan sa regulasyon para sa bawat klase ng data (halimbawa, Federal Law-152, PCI DSS).
Sistema ng Impormasyon
Ang data ay hindi lamang nakaimbak, ngunit naproseso din (nabago) ng mga sistema ng impormasyon. Ang susunod na hakbang pagkatapos makuha ang mga katangian ng data ay ang pinakakumpletong imbentaryo ng mga sistema ng impormasyon, ang kanilang mga tampok na arkitektura, interdependencies at mga kinakailangan sa imprastraktura sa mga maginoo na yunit para sa apat na uri ng mga mapagkukunan:
— Kapangyarihan sa pag-compute ng processor;
- Dami ng RAM;
— Mga kinakailangan para sa dami at pagganap ng sistema ng pag-iimbak ng data;
— Mga kinakailangan para sa network ng paghahatid ng data (mga panlabas na channel, mga channel sa pagitan ng mga bahagi ng IS).
Sa kasong ito, dapat mayroong mga kinakailangan para sa bawat serbisyo/microservice bilang bahagi ng IS.
Hiwalay, kinakailangang tandaan na, para sa tamang disenyo, ang pagkakaroon ng data sa epekto ng IS sa pangunahing negosyo ng kumpanya sa anyo ng gastos ng IS downtime (rubles kada oras) ay sapilitan.
Modelo ng pananakot
Dapat mayroong isang pormal na modelo ng mga banta kung saan ito ay binalak na protektahan ang data/mga serbisyo. Bukod dito, kasama sa modelo ng pagbabanta hindi lamang ang mga aspeto ng pagiging kumpidensyal, kundi pati na rin ang integridad at kakayahang magamit. Yung. Halimbawa:
— Pagkabigo ng pisikal na server;
— Pagkabigo ng top-of-the-rack switch;
— Pagkagambala ng optical communication channel sa pagitan ng mga data center;
— Pagkabigo ng buong operating system na imbakan.
Sa ilang mga kaso, ang mga modelo ng pagbabanta ay isinulat hindi lamang para sa mga bahagi ng imprastraktura, kundi pati na rin para sa mga partikular na sistema ng impormasyon o kanilang mga bahagi, tulad ng isang pagkabigo ng DBMS na may lohikal na pagkasira ng istraktura ng data.
Ang lahat ng mga desisyon sa loob ng proyekto upang maprotektahan laban sa isang hindi inilarawang banta ay hindi kailangan.
Mga kinakailangan sa regulasyon
Kung ang data na pinoproseso ay napapailalim sa mga espesyal na panuntunang itinatag ng mga regulator, kinakailangan ang impormasyon tungkol sa mga set ng data at mga panuntunan sa pagproseso/imbakan.
Mga target ng RPO/RTO
Ang pagdidisenyo ng anumang uri ng proteksyon ay nangangailangan ng pagkakaroon ng target na data loss indicator at target na oras ng pagbawi ng serbisyo para sa bawat isa sa mga inilarawang banta.
Sa isip, ang RPO at RTO ay dapat na may kaugnay na mga gastos sa pagkawala ng data at downtime bawat yunit ng oras.
Dibisyon sa mga pool ng mapagkukunan
Pagkatapos kolektahin ang lahat ng paunang impormasyon sa pag-input, ang unang hakbang ay ang pagpangkatin ang mga set ng data at IP sa mga pool batay sa mga modelo ng pagbabanta at mga kinakailangan sa regulasyon. Ang uri ng paghahati ng iba't ibang pool ay tinutukoy - sa pamamagitan ng program sa antas ng software ng system o pisikal.
Примеры:
— Ang pagpoproseso ng circuit ng personal na data ay ganap na pisikal na nakahiwalay sa iba pang mga sistema;
— Ang mga backup ay iniimbak sa isang hiwalay na sistema ng imbakan.
Sa kasong ito, ang mga pool ay maaaring hindi ganap na independyente, halimbawa, dalawang pool ng mga mapagkukunan ng computing ay tinukoy (processor power + RAM), na gumagamit ng isang solong data storage pool at isang solong data transmission resource pool.
Kapangyarihang magproseso
Abstract, ang mga kinakailangan sa pagpoproseso ng kapangyarihan ng isang virtualized na data center ay sinusukat sa mga tuntunin ng bilang ng mga virtual processor (vCPU) at ang kanilang consolidation ratio sa mga pisikal na processor (pCPU). Sa partikular na kaso na ito, 1 pCPU = 1 pisikal na core ng processor (hindi kasama ang Hyper-Threading). Ang bilang ng mga vCPU ay pinagsama-sama sa lahat ng tinukoy na resource pool (bawat isa ay maaaring magkaroon ng sarili nitong consolidation factor).
Ang consolidation coefficient para sa mga load system ay nakukuha sa empirically, batay sa kasalukuyang imprastraktura, o sa pamamagitan ng pilot installation at load testing. Para sa mga di-load na sistema, ginagamit ang "pinakamahusay na kasanayan". Sa partikular, binanggit ng VMware ang average na ratio bilang 8:1.
Operative memory
Ang kabuuang kinakailangan ng RAM ay nakuha sa pamamagitan ng simpleng pagsusuma. Ang paggamit ng RAM oversubscription ay hindi inirerekomenda.
Mga mapagkukunan ng imbakan
Ang mga kinakailangan sa imbakan ay nakukuha sa pamamagitan lamang ng pagsasama-sama ng lahat ng mga pool ayon sa kapasidad at pagganap.
Ang mga kinakailangan sa pagganap ay ipinahayag sa IOPS na sinamahan ng isang average na read/write ratio at, kung kinakailangan, isang maximum na latency ng pagtugon.
Ang mga kinakailangan sa Quality of Service (QoS) para sa mga partikular na pool o system ay dapat tukuyin nang hiwalay.
Mga mapagkukunan ng network ng data
Ang mga kinakailangan sa network ng data ay nakukuha sa pamamagitan lamang ng pagbubuod ng lahat ng bandwidth pool.
Ang mga kinakailangan sa Quality of Service (QoS) at latency (RTT) para sa mga partikular na pool o system ay dapat tukuyin nang hiwalay.
Bilang bahagi ng mga kinakailangan para sa mga mapagkukunan ng network ng data, ipinapahiwatig din ang mga kinakailangan para sa paghihiwalay at/o pag-encrypt ng trapiko sa network at mga gustong mekanismo (802.1q, IPSec, atbp.).
Pagpili ng arkitektura
Ang gabay na ito ay hindi sumasaklaw sa mga pagpipilian maliban sa x86 architecture at 100% server virtualization. Samakatuwid, ang pagpili ng computing subsystem architecture ay bumaba sa pagpili ng server virtualization platform, server form factor, at pangkalahatang server configuration requirements.
Ang pangunahing punto ng pagpili ay ang katiyakan ng paggamit ng isang klasikal na diskarte na may paghihiwalay ng mga function ng pagproseso, pag-iimbak at pagpapadala ng data o isang convergent.
klasikal na arkitektura nagsasangkot ng paggamit ng mga matatalinong panlabas na subsystem para sa pag-iimbak at pagpapadala ng data, habang ang mga server ay nag-aambag lamang ng kapangyarihan sa pagproseso at RAM sa karaniwang pool ng mga pisikal na mapagkukunan. Sa matinding mga kaso, ang mga server ay nagiging ganap na hindi nagpapakilala, hindi lamang nagkakaroon ng kanilang sariling mga disk, ngunit hindi kahit isang system identifier. Sa kasong ito, ang OS o hypervisor ay na-load mula sa built-in na flash media o mula sa isang external na data storage system (boot mula sa SAN).
Sa loob ng balangkas ng klasikal na arkitektura, ang pagpili sa pagitan ng mga blades at rack ay pangunahing ginawa batay sa mga sumusunod na prinsipyo:
— Cost-effective (sa karaniwan, ang mga rack-mount server ay mas mura);
— Computational density (mas mataas para sa mga blades);
— Pagkonsumo ng enerhiya at pagkawala ng init (ang mga blades ay may mas mataas na partikular na yunit bawat yunit);
— Scalability at controllability (ang mga blades sa pangkalahatan ay nangangailangan ng mas kaunting pagsisikap para sa malalaking pag-install);
- Paggamit ng mga expansion card (napakalimitadong pagpipilian para sa mga blades).
Convergent na arkitektura (o kilala bilang hyperconverged) ay nagsasangkot ng pagsasama-sama ng mga function ng pagproseso at pag-iimbak ng data, na humahantong sa paggamit ng mga lokal na disk ng server at, bilang kinahinatnan, ang pag-abandona sa klasikong blade form factor. Para sa mga converged system, ginagamit ang alinman sa mga rack server o cluster system, na pinagsasama ang ilang mga blade server at mga lokal na disk sa isang kaso.
CPU/Memorya
Upang wastong kalkulahin ang pagsasaayos, kailangan mong maunawaan ang uri ng pagkarga para sa kapaligiran o bawat isa sa mga independiyenteng kumpol.
Nakatali sa CPU – isang kapaligiran na limitado sa pagganap ng kapangyarihan ng processor. Ang pagdaragdag ng RAM ay hindi magbabago ng anuman sa mga tuntunin ng pagganap (bilang ng mga VM bawat server).
Memory bound - kapaligiran na limitado ng RAM. Ang mas maraming RAM sa server ay nagpapahintulot sa iyo na magpatakbo ng higit pang mga VM sa server.
GB / MHz (GB / pCPU) – ang average na ratio ng pagkonsumo ng RAM at kapangyarihan ng processor ng partikular na load na ito. Maaaring gamitin upang kalkulahin ang kinakailangang halaga ng memorya para sa isang naibigay na pagganap at vice versa.
Pagkalkula ng configuration ng server
Una, kailangan mong tukuyin ang lahat ng uri ng load at magpasya sa pagsasama-sama o paghahati ng iba't ibang computing pool sa iba't ibang cluster.
Susunod, para sa bawat isa sa mga tinukoy na kumpol, ang GB / MHz ratio ay tinutukoy sa isang pag-load na alam nang maaga. Kung ang pag-load ay hindi alam nang maaga, ngunit mayroong isang magaspang na pag-unawa sa antas ng paggamit ng kapangyarihan ng processor, maaari mong gamitin ang karaniwang mga ratio ng vCPU:pCPU upang i-convert ang mga kinakailangan sa pool sa mga pisikal.
Para sa bawat cluster, hatiin ang kabuuan ng mga kinakailangan sa vCPU pool sa coefficient:
vCPUsum / vCPU:pCPU = pCPUsum – kinakailangang bilang ng mga pisikal na unit. mga core
pCPUsum / 1.25 = pCPUht – bilang ng mga core na inayos para sa Hyper-Threading
Ipagpalagay natin na kinakailangang kalkulahin ang isang kumpol na may 190 core / 3.5 TB ng RAM. Kasabay nito, tumatanggap kami ng target na load na 50% ng lakas ng processor at 75% ng RAM.
pCPU
190
CPU util
50%
Mem
3500
Mem utility
75%
Saksakan
Ubod
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
Sa kasong ito, palagi kaming gumagamit ng pag-round up sa pinakamalapit na integer (=ROUNDUP(A1;0)).
Mula sa talahanayan, malinaw na ang ilang mga pagsasaayos ng server ay balanse para sa mga target na tagapagpahiwatig:
— 26 na server 2*6c / 192 GB
— 19 na server 2*10c / 256 GB
— 10 na server 2*18c / 512 GB
Ang pagpili sa mga pagsasaayos na ito ay dapat gawin batay sa mga karagdagang salik, gaya ng thermal package at available na paglamig, mga server na nagamit na, o gastos.
Mga tampok ng pagpili ng configuration ng server
Malawak na mga VM. Kung kinakailangan na mag-host ng malalawak na VM (maihahambing sa 1 NUMA node o higit pa), inirerekomenda, kung maaari, na pumili ng server na may configuration na nagpapahintulot sa mga naturang VM na manatili sa loob ng NUMA node. Sa malaking bilang ng malalawak na VM, may panganib ng pagkakapira-piraso ng mga mapagkukunan ng kumpol, at sa kasong ito, pinipili ang mga server na nagbibigay-daan sa mga malalawak na VM na mailagay nang siksik hangga't maaari.
Single failure na laki ng domain.
Ang pagpili ng laki ng server ay nakabatay din sa prinsipyo ng pagliit ng solong kabiguan na domain. Halimbawa, kapag pumipili sa pagitan ng:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
Ang lahat ng iba pang mga bagay ay pantay, dapat mong piliin ang pangalawang opsyon, dahil kapag ang isang server ay nabigo (o pinananatili), hindi 33% ng mga mapagkukunan ng kumpol ang nawala, ngunit 17%. Sa parehong paraan, ang bilang ng mga VM at IS na apektado ng aksidente ay hinahati.
Pagkalkula ng mga klasikong sistema ng imbakan batay sa pagganap
Ang mga klasikong sistema ng imbakan ay palaging kinakalkula gamit ang pinakamasamang sitwasyon, hindi kasama ang impluwensya ng cache ng pagpapatakbo at pag-optimize ng mga operasyon.
Bilang mga pangunahing tagapagpahiwatig ng pagganap, kinukuha namin ang mekanikal na pagganap mula sa disk (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS
Susunod, ang bilang ng mga disk sa disk pool ay kinakalkula gamit ang sumusunod na formula: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. saan:
- TotalIOPS – kabuuang kinakailangang pagganap sa IOPS mula sa disk pool
- RW – porsyento ng mga operasyong nabasa
- RAIDpen – RAID na parusa para sa napiling antas ng RAID
Magbasa pa tungkol sa Device RAID at RAID Penalty dito - и и
Batay sa nagresultang bilang ng mga disk, ang mga posibleng opsyon ay kinakalkula na nakakatugon sa mga kinakailangan sa kapasidad ng imbakan, kabilang ang mga opsyon na may multi-level na imbakan.
Ang pagkalkula ng mga system gamit ang SSD bilang storage layer ay isinasaalang-alang nang hiwalay.
Mga tampok ng pagkalkula ng mga system na may Flash Cache
flash-cache – isang karaniwang pangalan para sa lahat ng pagmamay-ari na teknolohiya para sa paggamit ng flash memory bilang pangalawang antas ng cache. Kapag gumagamit ng flash cache, ang sistema ng imbakan ay karaniwang kinakalkula upang magbigay ng tuluy-tuloy na pagkarga mula sa mga magnetic disk, habang ang peak ay inihahatid ng cache.
Sa kasong ito, kinakailangan upang maunawaan ang profile ng pag-load at ang antas ng lokalisasyon ng pag-access sa mga bloke ng mga volume ng imbakan. Ang flash cache ay isang teknolohiya para sa mga workload na may lubos na naka-localize na mga query, at halos hindi naaangkop para sa mga volume na na-load nang pantay-pantay (gaya ng para sa mga analytics system).
Pagkalkula ng mga low-end/mid-range na hybrid system
Gumagamit ang mga hybrid system ng mas mababa at panggitnang klase ng multi-level na storage na may data na gumagalaw sa pagitan ng mga antas sa isang iskedyul. Kasabay nito, ang laki ng multi-level na bloke ng imbakan para sa pinakamahusay na mga modelo ay 256 MB. Ang mga tampok na ito ay hindi nagpapahintulot sa amin na isaalang-alang ang tiered storage technology bilang isang teknolohiya para sa pagtaas ng produktibo, tulad ng maraming tao na nagkakamali sa paniniwala. Ang multi-level na storage sa mga low- at middle-class system ay isang teknolohiya para sa pag-optimize ng mga gastos sa storage para sa mga system na may malinaw na hindi pantay na pagkarga.
Para sa tiered storage, ang performance ng pinakamataas na tier ay kinakalkula muna, habang ang ibabang tier ng storage ay itinuturing na nag-aambag lamang sa nawawalang kapasidad ng storage. Para sa isang hybrid na multi-tier system, ipinag-uutos na gumamit ng teknolohiya ng flash cache para sa multi-tier pool upang mabayaran ang pag-drawdown ng pagganap para sa biglang pinainit na data mula sa mas mababang antas.
Paggamit ng SSD sa isang Tiered Disk Pool
Ang paggamit ng mga SSD sa isang multi-level na disk pool ay may mga pagkakaiba-iba, depende sa partikular na pagpapatupad ng mga flash cache algorithm ng isang partikular na tagagawa.
Ang pangkalahatang kasanayan ng patakaran sa storage para sa isang disk pool na may antas ng SSD ay SSD muna.
Read Only Flash Cache. Para sa isang read-only na flash cache, ang storage layer sa SSD ay may kasamang makabuluhang localization ng writes, anuman ang cache.
Basahin/Isulat ang Flash Cache. Sa kaso ng flash cache, ang laki ng write cache ay unang nakatakda sa maximum na laki ng cache, at ang SSD storage tier ay lilitaw lamang kapag ang laki ng cache ay hindi sapat upang maserbisyuhan ang buong localized na workload.
Ginagawa ang mga kalkulasyon sa pagganap ng SSD at cache sa bawat oras batay sa mga rekomendasyon ng gumawa, ngunit palaging para sa pinakamasamang sitwasyon.
Pinagmulan: www.habr.com