Virtualigita datumcentro-dezajno

Virtualigita datumcentro-dezajno

Enkonduko

Informsistemo el la vidpunkto de la uzanto estas bone difinita en GOST RV 51987 - "aŭtomatigita sistemo, kies rezulto estas la prezento de eligo-informoj por posta uzo." Se ni konsideras la internan strukturon, tiam esence ajna IS estas sistemo de interligitaj algoritmoj efektivigitaj en kodo. En larĝa signifo de la Turing-Church-tezo, algoritmo (aŭ IS) transformas aron de enirdatenoj en aron de produktaĵdatenoj.
Oni eĉ povus diri, ke la transformo de enigaĵoj estas la signifo de la ekzisto de informsistemo. Sekve, la valoro de la IS kaj la tuta IS-komplekso estas determinita tra la valoro de enigo kaj produktaĵdatenoj.
Surbaze de tio, dezajno devas komenciĝi kaj esti datenmovita, tajlorante arkitekturon kaj metodojn al la strukturo kaj signifo de la datenoj.

Stokitaj datumoj
Ŝlosila etapo en preparo por dezajno estas akiri la karakterizaĵojn de ĉiuj datumserioj planitaj por prilaborado kaj stokado. Ĉi tiuj karakterizaĵoj inkluzivas:
- Volumo de datumoj;
— Informoj pri la vivociklo de datumoj (kresko de novaj datumoj, vivdaŭro, prilaborado de malnoviĝintaj datumoj);
— Klasifiko de datumoj el la vidpunkto efiko sur la kerna komerco de la firmao (la triado de konfidenco, integreco, havebleco) kune kun financaj indikiloj (ekzemple, la kosto de datumperdo en la lasta horo);
— Geografio de datumtraktado (fizika loko de prilaboraj sistemoj);
— Reguligaj postuloj por ĉiu datumklaso (ekzemple, Federal Law-152, PCI DSS).

Informaj Sistemoj

Datumoj ne nur estas stokitaj, sed ankaŭ prilaboritaj (transformitaj) per informsistemoj. La sekva paŝo post akiro de la datumkarakterizaĵoj estas la plej kompleta inventaro de informsistemoj, iliaj arkitekturaj trajtoj, interdependecoj kaj infrastrukturaj postuloj en konvenciaj unuoj por kvar specoj de rimedoj:
— Komputilpovo de procesoro;
— Kvanto de RAM;
— Postuloj por la volumo kaj agado de la datumstokada sistemo;
— Postuloj por la reto de transdono de datumoj (eksteraj kanaloj, kanaloj inter IS-komponentoj).
En ĉi tiu kazo, devas ekzisti postuloj por ĉiu servo/mikroservo kiel parto de la IS.
Aparte, necesas rimarki, ke por ĝusta dezajno, la havebleco de datumoj pri la efiko de la IS sur la kerna komerco de la kompanio en la formo de la kosto de IS-malfunkcio (rubloj por horo) estas deviga.

Modelo de minaco

Devas ekzisti formala modelo de minacoj, de kiu oni planas protekti datumojn/servojn. Krome, la minaca modelo inkluzivas ne nur aspektojn de konfidenco, sed ankaŭ integrecon kaj haveblecon. Tiuj. Ekzemple:
— Fiasko de la fizika servilo;
— Fiasko de la supro-de-la-rako-ŝaltilo;
— Interrompo de la optika komunika kanalo inter datencentroj;
— Fiasko de la tuta funkcia stokada sistemo.
En kelkaj kazoj, minacmodeloj estas skribitaj ne nur por infrastrukturkomponentoj, sed ankaŭ por specifaj informsistemoj aŭ iliaj komponentoj, kiel ekzemple DBMS-fiasko kun logika detruo de la datenstrukturo.
Ĉiuj decidoj ene de la projekto por protekti kontraŭ nepriskribita minaco estas nenecesaj.

Reguligaj postuloj

Se la prilaboritaj datumoj estas submetitaj al specialaj reguloj establitaj de regulistoj, necesas informoj pri datumaj aroj kaj reguloj pri prilaborado/stokado.

RPO/RTO-celoj

Dezajni ajnan tipon de protekto postulas havi celajn datumojn perdan indikilojn kaj celservan reakiro tempon por ĉiu el la priskribitaj minacoj.
Ideale, RPO kaj RTO devus havi rilatajn kostojn de datumperdo kaj malfunkcio po unuotempo.

Virtualigita datumcentro-dezajno

Divido en rimedojn

Post kolekti ĉiujn komencajn enigajn informojn, la unua paŝo estas grupigi datumajn arojn kaj IP en naĝejojn bazitajn sur minacmodeloj kaj reguligaj postuloj. La speco de divido de diversaj naĝejoj estas determinita - programe sur la sistema programaro-nivelo aŭ fizike.
ekzemploj:
— La cirkvito prilaboranta personajn datumojn estas tute fizike apartigita de aliaj sistemoj;
— Rezervoj estas stokitaj en aparta stokada sistemo.

En ĉi tiu kazo, la naĝejoj povas esti nekomplete sendependaj, ekzemple, du naĝejoj de komputikresursoj estas difinitaj (procesoro-potenco + RAM), kiuj uzas ununuran datumstokadon kaj ununuran datumtranssendon-rimedon.

Pretiga potenco

Virtualigita datumcentro-dezajno

Resume, la pretigpotencpostuloj de virtualigita datencentro estas mezuritaj laŭ la nombro da virtualaj procesoroj (vCPUoj) kaj ilia firmiĝoproporcio sur fizikaj procesoroj (pCPU). En ĉi tiu aparta kazo, 1 pCPU = 1 fizika procesora kerno (ekskludante Hyper-Threading). La nombro da vCPUoj estas sumigita tra ĉiuj difinitaj rimedgrupoj (ĉiu el kiuj povas havi sian propran firmiĝfaktoron).
La firmiĝokoeficiento por ŝarĝitaj sistemoj estas akirita empirie, surbaze de ekzistanta infrastrukturo, aŭ per pilotinstalaĵo kaj ŝarĝtestado. Por malŝarĝitaj sistemoj, "plej bona praktiko" estas uzata. Specife, VMware citas la mezan rilatumon kiel 8:1.

Funkcia memoro

La totala RAM-postulo estas akirita per simpla sumado. Uzado de RAM-troabono ne estas rekomendita.

Stokaj rimedoj

Stokadpostuloj estas akiritaj per simple sumado de ĉiuj naĝejoj laŭ kapacito kaj efikeco.
Efikecpostuloj estas esprimitaj en IOPS kombinitaj kun meza legado/skriba rilatumo kaj, se necese, maksimuma responda latenteco.
Postuloj pri Kvalito de Servo (QoS) por specifaj naĝejoj aŭ sistemoj devas esti precizigitaj aparte.

Rimedoj de datumoj

La datumretaj postuloj estas akiritaj per simple sumado de ĉiuj bendolarĝaj naĝejoj.
Postuloj pri Kvalito de Servo (QoS) kaj latenteco (RTT) por specifaj naĝejoj aŭ sistemoj devus esti precizigitaj aparte.
Kiel parto de la postuloj por datenretresursoj, postuloj por izolado kaj/aŭ ĉifrado de rettrafiko kaj preferataj mekanismoj (802.1q, IPSec, ktp.) ankaŭ estas indikitaj.

Elekto de arkitekturo

Ĉi tiu gvidilo ne diskutas alian elekton ol x86-arkitekturo kaj 100% servila virtualigo. Tial, la elekto de komputika subsistem-arkitekturo venas malsupren al la elekto de servila virtualigplatformo, servila formofaktoro, kaj ĝeneralaj servilaj konfiguraciopostuloj.

La ŝlosila elekto estas la certeco uzi klasikan aliron kun apartigo de funkcioj pri prilaborado, stokado kaj elsendado de datumoj aŭ konverĝa.

klasika arkitekturo implikas la uzon de inteligentaj eksteraj subsistemoj por stokado kaj elsendado de datenoj, dum serviloj kontribuas nur pretigpotencon kaj RAM al la komuna aro de fizikaj resursoj. En ekstremaj kazoj, serviloj fariĝas tute anonimaj, havante ne nur siajn proprajn diskojn, sed eĉ ne sisteman identigilon. En ĉi tiu kazo, la OS aŭ hiperviziero estas ŝarĝita de enkonstruita fulmmedio aŭ de ekstera datuma stokado-sistemo (ŝargo de SAN).
En la kadro de klasika arkitekturo, la elekto inter klingoj kaj rakoj estas farita ĉefe surbaze de la sekvaj principoj:
— Kostefika (averaĝe, rak-muntaj serviloj estas pli malmultekostaj);
— Komputila denseco (pli alta por klingoj);
— Energia konsumo kaj varmodissipado (klingoj havas pli altan specifan unuon po unuo);
— Skalebleco kaj kontrolebleco (klingoj ĝenerale postulas malpli da penado por grandaj instalaĵoj);
- Uzo de ekspansiokartoj (tre limigita elekto por klingoj).
Konverĝa arkitekturo (ankaŭ konata kiel hiperkonverĝis) implikas kombini la funkciojn de datumtraktado kaj stokado, kio kondukas al la uzo de lokaj servilaj diskoj kaj, kiel sekvo, la forlaso de la klasika klinga formo-faktoro. Por konverĝaj sistemoj, aŭ rakserviloj aŭ aretsistemoj estas uzitaj, kombinante plurajn klingoservilojn kaj lokajn diskojn en ununura kazo.

CPU/Memoro

Por ĝuste kalkuli la agordon, vi devas kompreni la tipon de ŝarĝo por la medio aŭ ĉiu el la sendependaj aretoj.
CPU ligita - medio limigita en rendimento per procesora potenco. Aldono de RAM ne ŝanĝos ion rilate rendimenton (nombro da VM-oj per servilo).
Memoro ligita - medio limigita de RAM. Pli da RAM sur la servilo permesas al vi ruli pli da VM-oj sur la servilo.
GB / MHz (GB / pCPU) - la averaĝa proporcio de konsumo de RAM kaj procesoro-potenco per ĉi tiu aparta ŝarĝo. Povas esti uzata por kalkuli la bezonatan kvanton da memoro por donita agado kaj inverse.

Kalkulo de agordo de servilo

Virtualigita datumcentro-dezajno

Unue, vi devas determini ĉiujn specojn de ŝarĝo kaj decidi pri kombinado aŭ dividado de malsamaj komputilaj naĝejoj en malsamaj aretoj.
Poste, por ĉiu el la difinitaj aretoj, la rilatumo GB / MHz estas determinita ĉe ŝarĝo konata antaŭe. Se la ŝarĝo ne estas konata anticipe, sed estas malglata kompreno pri la nivelo de procesoro-potencuzo, vi povas uzi normajn vCPU:pCPU-proporciojn por konverti naĝejojn en fizikajn postulojn.

Por ĉiu areto, dividu la sumon de la postuloj de la naĝejo de vCPU per la koeficiento:
vCPUsum / vCPU:pCPU = pCPUsum - postulata nombro da fizikaj unuoj. kernoj
pCPUsum / 1.25 = pCPUht - nombro da kernoj alĝustigitaj por Hyper-Threading
Ni supozu, ke necesas kalkuli areton kun 190 kernoj / 3.5 TB da RAM. Samtempe, ni akceptas cel-ŝarĝon de 50% de procesora potenco kaj 75% de RAM.

pCPU
190
CPU-utilo
50%

memoro
3500
Mem utileco
75%

socket
kerna
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

En ĉi tiu kazo, ni ĉiam uzas rondigon al la plej proksima entjero (=ROUNDUP(A1;0)).
De la tabelo evidentiĝas, ke pluraj servilaj agordoj estas ekvilibrigitaj por la celindikiloj:
— 26 serviloj 2*6c / 192 GB
— 19 serviloj 2*10c / 256 GB
— 10 serviloj 2*18c / 512 GB

La elekto de ĉi tiuj agordoj devas tiam esti farita surbaze de pliaj faktoroj, kiel ekzemple termika pakaĵo kaj disponebla malvarmigo, serviloj jam uzitaj aŭ kosto.

Trajtoj de elektado de servila agordo

Larĝaj VMs. Se necesas gastigi larĝajn VM-ojn (kompareblan al 1 NUMA-nodo aŭ pli), oni rekomendas, se eble, elekti servilon kun agordo, kiu permesas al tiaj VM-oj resti ene de la NUMA-nodo. Kun granda nombro da larĝaj VM-oj, ekzistas danĝero de fragmentiĝo de clusterresursoj, kaj en ĉi tiu kazo, serviloj estas elektitaj kiuj permesas larĝajn VMs esti metitaj kiel eble plej dense.

Ununura malsukcesa domajna grandeco.

La elekto de servilgrandeco ankaŭ estas bazita sur la principo de minimumigado de la ununura fiaska domajno. Ekzemple, kiam vi elektas inter:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
Ĉiuj aliaj aferoj egale, vi devas elekti la duan opcion, ĉar kiam unu servilo malsukcesas (aŭ estas konservita), ne 33% de la amasrimedoj estas perditaj, sed 17%. De la sama maniero, la nombro da VM-oj kaj IS-oj trafitaj de la akcidento estas duonigita.

Kalkulo de klasikaj stokaj sistemoj bazitaj sur rendimento

Virtualigita datumcentro-dezajno

Klasikaj stokaj sistemoj ĉiam estas kalkulitaj per la plej malbona kazo, ekskludante la influon de la funkcia kaŝmemoro kaj optimumigo de operacioj.
Kiel bazaj agado-indikiloj, ni prenas mekanikan agadon de la disko (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS

Poste, la nombro da diskoj en la disko estas kalkulita per la sekva formulo: = TotalIOPS * (RW + (1 –RW) * RAIDPen) / IOPSdisko. Kie:
- TotalIOPS - totala bezonata rendimento en IOPS de la disko-poolo
- RW – procento de legaj operacioj
- RAID-plumo - RAID-puno por la elektita RAID-nivelo

Legu pli pri Device RAID kaj RAID Penalty ĉi tie - Tenada rendimento. Unua parto. и Tenada rendimento. Dua parto. и Tenada rendimento. Parto tri

Surbaze de la rezulta nombro da diskoj, eblaj opcioj estas kalkulitaj, kiuj plenumas la postulojn pri stokado, inkluzive de ebloj kun plurnivela stokado.
La kalkulo de sistemoj uzantaj SSD kiel la stokan tavolon estas konsiderata aparte.
Trajtoj de kalkulaj sistemoj kun Flash Cache

flash-kaŝmemoro - komunnomo por ĉiuj proprietaj teknologioj por uzi fulmmemoron kiel dunivelan kaŝmemoron. Dum uzado de fulmdeponejo, la stokadsistemo estas kutime kalkulita por disponigi stabilan ŝarĝon de magnetaj diskoj, dum la pinto estas servita per la kaŝmemoro.
En ĉi tiu kazo, necesas kompreni la ŝarĝan profilon kaj la gradon de lokalizo de aliro al blokoj de stokaj volumoj. Fulma kaŝmemoro estas teknologio por laborkvantoj kun tre lokalizitaj demandoj, kaj estas preskaŭ neaplikebla por unuforme ŝarĝitaj volumoj (kiel ekzemple por analizaj sistemoj).

Kalkulo de malaltaj/mezintervalaj hibridaj sistemoj

Hibridaj sistemoj de la malsuperaj kaj mezaj klasoj uzas plurnivelan stokadon kun datumoj moviĝantaj inter niveloj laŭ horaro. Samtempe, la grandeco de la plurnivela stokado por la plej bonaj modeloj estas 256 MB. Ĉi tiuj funkcioj ne permesas al ni konsideri gradan stokadoteknologion teknologio por pliigi produktivecon, kiel multaj homoj erare kredas. Plurnivela stokado en malaltaj kaj mezklasaj sistemoj estas teknologio por optimumigi stokadkostojn por sistemoj kun prononcita ŝarĝa malebeneco.

Por gradigita stokado, la rendimento de la supra parto estas kalkulita unue, dum la malsupra parto de stokado estas konsiderata kiel nur kontribuanta al la mankanta stokado. Por hibrida plurtavola sistemo, estas devige uzi fulmkaŝmemorteknologion por la plurtavola naĝejo por kompensi por la rendimentomalaltiĝo por subite varmigitaj datenoj de la pli malalta nivelo.

Uzante SSD en Tired Disk Pool

Virtualigita datumcentro-dezajno

La uzo de SSDoj en plurnivela diskpoolo havas variojn, depende de la specifa efektivigo de fulmaj kaŝmemoralgoritmoj de antaŭfiksita produktanto.
La ĝenerala praktiko de stokadopolitiko por diskpool kun SSD-nivelo estas SSD unue.
Nur Lega Flash Cache. Por nurlegebla fulma kaŝmemoro, la stoka tavolo sur la SSD venas kun grava lokalizo de skribaĵoj, sendepende de la kaŝmemoro.
Legu/Skribu Flash Cache. En la kazo de fulma kaŝmemoro, la skriba kaŝmemorgrandeco unue estas agordita al la maksimuma kaŝmemorgrandeco, kaj la SSD-stokado-nivelo aperas nur kiam la kaŝmemorgrandeco estas nesufiĉa por servi la tutan lokalizitan laborkvanton.
Kalkuloj de rendimento de SSD kaj kaŝmemoro estas faritaj ĉiufoje surbaze de la rekomendoj de la fabrikanto, sed ĉiam por la plej malbona kazo.

fonto: www.habr.com

Aldoni komenton