Aféierung
En Informatiounssystem aus der Siicht vum Benotzer ass gutt definéiert am GOST RV 51987 - "en automatiséierte System, d'Resultat vun deem ass d'Presentatioun vun Ausgangsinformatioun fir spéider Benotzung." Wa mir déi intern Struktur betruechten, dann ass am Wesentlechen all IS e System vun interkonnektéierten Algorithmen, déi am Code implementéiert sinn. An engem breede Sënn vun der Turing-Kierch Dissertatioun transforméiert en Algorithmus (oder IS) eng Rei vun Inputdaten an eng Rei vun Ausgangsdaten.
Et kéint souguer soen datt d'Transformatioun vun Inputdaten d'Bedeitung vun der Existenz vun engem Informatiounssystem ass. Deementspriechend gëtt de Wäert vum IS an dem ganzen IS Komplex duerch de Wäert vun Input- an Outputdaten bestëmmt.
Baséierend op dësem, muss den Design ufänken an dategedriwwe sinn, d'Architektur a Methoden un d'Struktur an d'Bedeitung vun den Daten upassen.
Gespäichert Donnéeën
Eng Schlësselstadium an der Virbereedung fir den Design ass d'Eegeschafte vun all Datesets, déi fir d'Veraarbechtung a Lagerung geplangt sinn, ze kréien. Dës Charakteristiken enthalen:
- Datevolumen;
- Informatioun iwwer de Liewenszyklus vun Daten (Wuesstem vun neien Donnéeën, Liewensdauer, Veraarbechtung vun alen Donnéeën);
- Klassifikatioun vun Daten aus der Siicht Impakt op d'Kärgeschäft vun der Firma (d'Triad vu Vertraulechkeet, Integritéit, Disponibilitéit) zesumme mat finanzielle Indikatoren (zum Beispill d'Käschte vum Dateverloscht an der leschter Stonn);
- Geographie vun Daten Veraarbechtung (kierperlech Lag vun Veraarbechtung Systemer);
- Reguléierungsfuerderunge fir all Dateklass (zum Beispill Federal Law-152, PCI DSS).
Informatiounssystemer
D'Donnéeë ginn net nëmme gespäichert, awer och duerch Informatiounssystemer veraarbecht (transforméiert). De nächste Schrëtt no der Erhaalung vun den Datencharakteristiken ass de komplettsten Inventar vun Informatiounssystemer, hir architektonesch Fonctiounen, Interdependenzen an Infrastrukturfuerderunge a konventionell Eenheeten fir véier Aarte vu Ressourcen:
- Prozessor Rechenkraaft;
- Betrag vum RAM;
- Ufuerderunge fir de Volume an d'Leeschtung vum Datelagerungssystem;
- Ufuerderunge fir den Datenübertragungsnetz (extern Kanäl, Kanäl tëscht IS Komponenten).
An dësem Fall mussen et Ufuerderunge fir all Service/Mikroservice als Deel vum IS sinn.
Separat ass et néideg ze notéieren datt d'Disponibilitéit vun Donnéeën iwwer den Impakt vum IS op de Kärgeschäft vun der Firma a Form vun de Käschte vun IS Downtime (Rubelen pro Stonn) obligatoresch ass.
Gefor Modell
Et muss e formelle Modell vu Gefore sinn, aus deem et geplangt ass Daten / Servicer ze schützen. Ausserdeem enthält de Bedrohungsmodell net nëmmen Aspekter vu Vertraulechkeet, awer och Integritéit an Disponibilitéit. Déi. Zum Beispill:
- Feeler vum kierperleche Server;
- Feeler vum Top-of-the-Rack Schalter;
- Ënnerbriechung vum opteschen Kommunikatiounskanal tëscht Datenzenteren;
- Ausfall vum ganze operationelle Späichersystem.
A verschiddene Fäll sinn Bedrohungsmodeller net nëmme fir Infrastrukturkomponenten geschriwwe ginn, awer och fir spezifesch Informatiounssystemer oder hir Komponenten, sou wéi e DBMS-Feeler mat logescher Zerstéierung vun der Datestruktur.
All Entscheedungen am Projet fir géint eng onbeschriwwe Bedrohung ze schützen sinn onnéideg.
Regulatioun Ufuerderunge
Wann d'Donnéeën, déi veraarbecht ginn, ënner spezielle Reegele vun de Regulateuren ënnerleien, ass Informatioun iwwer Datesets a Veraarbechtungs-/Späicherregelen erfuerderlech.
RPO/RTO Ziler
Design vun all Typ vu Schutz erfuerdert Zildatenverloschtindikatoren an Zilservice Erhuelung Zäit fir jiddereng vun de beschriwwene Bedrohungen.
Idealerweis sollten RPO an RTO assoziéiert Käschte vum Dateverloscht an Ausdauer pro Eenheet Zäit hunn.
Divisioun an Ressource Poolen
Nodeems Dir all déi initial Inputinformatioun gesammelt hutt, ass den éischte Schrëtt Datesets an IP a Poolen ze gruppéieren baséiert op Bedrohungsmodeller a reglementaresche Ufuerderunge. D'Aart vun der Divisioun vu verschiddene Poole gëtt bestëmmt - programmatesch um System Software Niveau oder kierperlech.
Beispiller:
- De Circuit, déi perséinlech Donnéeën veraarbecht ass komplett kierperlech vun anere Systemer getrennt;
- Backups ginn op engem separaten Späichersystem gespäichert.
An dësem Fall kënnen d'Pools onkomplett onofhängeg sinn, zum Beispill, zwee Poole vu Rechenressourcen sinn definéiert (Prozessorkraaft + RAM), déi eng eenzeg Datenspeicherpool an eng eenzeg Datenübertragungsressource Pool benotzen.
Veraarbechtung Muecht
Abstrakt, d'Veraarbechtungskraaftfuerderunge vun engem virtualiséierte Rechenzentrum gi gemooss wat d'Zuel vu virtuelle Prozessoren (vCPUs) ugeet an hire Konsolidéierungsverhältnis op kierperleche Prozessoren (pCPU). An dësem bestëmmte Fall, 1 pCPU = 1 kierperlech Prozessor Kär (ausser Hyper-Threading). D'Zuel vun de vCPUs gëtt iwwer all definéiert Ressourcepools zesummegefaasst (jidderee kann säin eegene Konsolidéierungsfaktor hunn).
De Konsolidatiounskoeffizient fir belaaschte Systemer gëtt empiresch kritt, baséiert op existéierend Infrastruktur, oder duerch Pilotinstallatioun a Lasttest. Fir entlaaschte Systemer gëtt "best practice" benotzt. Speziell zitéiert VMware den Duerchschnëttsverhältnis als 8: 1.
RAM
Den Total RAM Noutwendegkeete gëtt duerch einfach Summatioun kritt. Benotzt RAM Iwwerabonnement ass net recommandéiert.
Stockage Ressourcen
D'Späicherefuerderunge ginn kritt andeems Dir all Pools einfach duerch Kapazitéit a Leeschtung summéiert.
D'Leeschtungsfuerderunge ginn an IOPS ausgedréckt kombinéiert mat engem duerchschnëttleche Lies-/Schreifverhältnis an, wann néideg, eng maximal Äntwertlatenz.
Qualitéit vum Service (QoS) Ufuerderunge fir spezifesch Poolen oder Systemer musse separat spezifizéiert ginn.
Daten Ressourcen Ressourcen
D'Datennetzfuerderunge ginn kritt andeems Dir einfach all d'Bandbreedpools summéiert.
Qualitéit vum Service (QoS) a Latenz (RTT) Ufuerderunge fir spezifesch Poolen oder Systemer solle separat spezifizéiert ginn.
Als Deel vun den Ufuerderunge fir Datennetzressourcen ginn och Ufuerderunge fir Isolatioun an / oder Verschlësselung vum Netzverkéier a bevorzugte Mechanismen (802.1q, IPSec, etc.) uginn.
Architektur Auswiel
Dëse Guide diskutéiert keng aner Wiel wéi x86 Architektur an 100% Servervirtualiséierung. Dofir kënnt d'Wiel vun der Informatik-Subsystemarchitektur erof op d'Wiel vun der Servervirtualiséierungsplattform, Serverformfaktor an allgemeng Serverkonfiguratiounsufuerderunge.
De Schlësselpunkt vun der Wiel ass d'Sécherheet vun enger klassescher Approche mat Trennung vu Funktiounen vun der Veraarbechtung, der Lagerung an der Iwwerdroung vun Daten oder enger konvergenter.
klassesch Architektur involvéiert d'Benotzung vun intelligenten externen Ënnersystemer fir Daten ze späicheren an ze vermëttelen, während Serveren nëmmen d'Veraarbechtungskraaft an de RAM zum gemeinsame Pool vu kierperleche Ressourcen bäidroen. An extremen Fäll ginn d'Server komplett anonym, net nëmmen hir eegen Disken, awer och net e Systemidentifizéierer. An dësem Fall gëtt den OS oder den Hypervisor aus agebaute Flash Medien oder vun engem externen Datelagerungssystem gelueden (Boot vum SAN).
Am Kader vun der klassescher Architektur ass d'Wiel tëscht Blades a Racken haaptsächlech op de folgende Prinzipien baséiert:
- Käschten-effikass (am Duerchschnëtt, Rack-Mount Serveren si méi bëlleg);
- Berechnungsdicht (méi héich fir Blades);
- Energieverbrauch an Wärmevergëftung (Klingen hunn eng méi héich spezifesch Eenheet pro Eenheet);
- Skalierbarkeet a Kontrollbarkeet (Klingen erfuerderen allgemeng manner Effort fir grouss Installatiounen);
- Benotzung vun Expansioun Kaarte (ganz limitéiert Wiel fir Blades).
Konvergent Architektur (och bekannt als hyperkonvergéiert) involvéiert d'Kombinatioun vun de Funktiounen vun der Dateveraarbechtung a Lagerung, wat zu der Verwäertung vu lokalen Serverdisken féiert an als Konsequenz d'Verloossung vum klassesche Bladeformfaktor. Fir konvergéiert Systemer ginn entweder Rackserver oder Clustersystemer benotzt, déi verschidde Bladeserveren a lokalen Disken an engem eenzege Fall kombinéiert.
CPU / Erënnerung
Fir d'Konfiguratioun richteg ze berechnen, musst Dir d'Zort vun der Laascht fir d'Ëmwelt oder all eenzel vun den onofhängege Cluster verstoen.
CPU gebonnen - en Ëmfeld limitéiert an Leeschtung duerch Prozessor Muecht. RAM derbäi ännert näischt wat d'Performance ugeet (Zuel vu VMs pro Server).
Erënnerung gebonnen - Ëmfeld limitéiert duerch RAM. Méi RAM op de Server erlaabt Iech méi VMs op de Server ze lafen.
GB / MHz (GB / pCPU) - den duerchschnëttleche Verhältnis vum Verbrauch vu RAM a Prozessorkraaft duerch dës speziell Laascht. Kann benotzt ginn déi néideg Betrag vun Erënnerung fir eng Leeschtung ze berechnen a Vize versa.
Server Configuratioun Berechnung
Als éischt musst Dir all Zorte vu Laascht bestëmmen an entscheeden iwwer d'Kombinatioun oder d'Divisioun vu verschiddene Rechenpools a verschidde Cluster.
Als nächst gëtt fir jiddereng vun den definéierte Stärekéip de GB / MHz Verhältnis bei enger Belaaschtung bestëmmt am Viraus. Wann d'Laascht net am Viraus bekannt ass, awer et ass e graff Verständnis vum Niveau vun der Prozessorkraaftverbrauch, kënnt Dir Standard vCPU benotzen: pCPU Verhältnisser fir Poolfuerderungen a kierperlech ze konvertéieren.
Fir all Stärekoup, deelt d'Zomm vun de vCPU Pool Ufuerderunge mam Koeffizient:
vCPUsum / vCPU:pCPU = pCPUsum - erfuerderlech Zuel vu kierperlechen Eenheeten. Kären
pCPUsum / 1.25 = pCPUht - Unzuel vun de Käre fir Hyper-Threading ugepasst
Loosst eis unhuelen datt et néideg ass e Stärekoup mat 190 Kären / 3.5 TB RAM ze berechnen. Zur selwechter Zäit akzeptéiere mir eng Zilbelaaschtung vu 50% vun der Prozessorkraaft an 75% vum RAM.
pCPU
190
CPU util
50%
Erënnerung
3500
Mem Utility
75%
Socket
Kär
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
An dësem Fall benotze mir ëmmer d'Ronn op déi nootste ganz Zuel (=ROUNDUP(A1;0)).
Aus der Tabell gëtt et offensichtlech datt verschidde Serverkonfiguratiounen fir d'Zilindikatoren ausgeglach sinn:
- 26 Serveren 2 * 6c / 192 GB
- 19 Serveren 2 * 10c / 256 GB
- 10 Serveren 2 * 18c / 512 GB
D'Wiel vun dëse Konfiguratiounen muss dann op Basis vun zousätzleche Faktoren gemaach ginn, sou wéi thermesch Package a verfügbare Killmëttel, Server scho benotzt oder Käschten.
Features fir e Serverkonfiguratioun ze wielen
Breet VMs. Wann et néideg ass, breet VMs ze hosten (vergläichbar mat 1 NUMA Node oder méi), ass et recommandéiert, wa méiglech, e Server mat enger Konfiguratioun ze wielen déi et erlaabt datt esou VMs am NUMA Node bleiwen. Mat enger grousser Zuel vu breet VMs besteet d'Gefor vu Fragmentatioun vu Clusterressourcen, an an dësem Fall gi Serveren ausgewielt, déi et erlaben datt breet VMs esou dicht wéi méiglech plazéiert ginn.
Single Echec Domain Gréisst.
D'Wiel vun der Servergréisst baséiert och op de Prinzip fir den eenzege Feeler-Domain ze minimiséieren. Zum Beispill, wann Dir tëscht:
- 3 x 4*10c / 512 GB
- 6 x 2*10c / 256 GB
All aner Saache sinn gläich, Dir musst déi zweet Optioun wielen, well wann ee Server klappt (oder ënnerhale gëtt), ginn net 33% vun de Clusterressourcen verluer, awer 17%. Am selwechte Wee gëtt d'Zuel vun de VMen an ISs, déi vum Accident betraff sinn, halbéiert.
Berechnung vun klassesch Stockage Systemer baséiert op Leeschtung
Klassesch Späichersystemer ginn ëmmer mat dem schlëmmste Fall Szenario berechent, ausser den Afloss vum operationelle Cache an Optimisatioun vun Operatiounen.
Als Basisleistungsindikatoren huelen mir mechanesch Leeschtung vun der Disk (IOPSdisk):
- 7.2k - 75 IOPS
- 10k - 125 IOPS
- 15k - 175 IOPS
Als nächst gëtt d'Zuel vun den Disken am Disk Pool mat der folgender Formel berechent: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Wou:
- Total IOPS - total erfuerderlech Leeschtung am IOPS vum Disk Pool
- RW - Prozentsaz vun liesen Operatiounen
- RAID Pen - RAID Strof fir de gewielten RAID Niveau
Liest méi iwwer Device RAID an RAID Penalty hei - и и
Baséierend op der resultéierender Unzuel vun Disken, ginn méiglech Optiounen berechent, déi d'Späicherkapazitéit Ufuerderunge entspriechen, dorënner Optiounen mat Multi-Level-Späichere.
D'Berechnung vu Systemer mat SSD als Späicherschicht gëtt getrennt ugesinn.
Fonctiounen vun Berechnung Systemer mat Flash Cache
flash-cache - e gemeinsame Numm fir all propriétaire Technologien fir Flash Memory als zweeten Niveau Cache ze benotzen. Wann Dir e Flash Cache benotzt, gëtt de Späichersystem normalerweis berechent fir eng stänneg Belaaschtung vu magnetesche Placken ze bidden, während de Peak vum Cache servéiert gëtt.
An dësem Fall ass et néideg de Laaschtprofil an de Grad vun der Lokaliséierung vum Zougang zu Block vu Späichervolumen ze verstoen. Flash Cache ass eng Technologie fir Aarbechtslaascht mat héich lokaliséierten Ufroen, an ass praktesch net applicabel fir eenheetlech gelueden Volumen (wéi fir Analytiksystemer).
Berechnung vun niddereg-Enn / Mëtt-Gamme Hybrid Systemer
Hybrid Systemer vun den ënneschten a Mëttelklassen benotzen Multi-Niveau Späichere mat Daten, déi tëscht Niveauen op engem Zäitplang bewegen. Zur selwechter Zäit ass d'Gréisst vum Multi-Level Späicherblock fir déi bescht Modeller 256 MB. Dës Fonctiounen erlaben eis net d'Tiered Storage Technologie als Technologie fir d'Produktivitéit ze erhéijen, sou wéi vill Leit falsch gleewen. Multi-Level Stockage an niddereg- a Mëttelklass Systemer ass eng Technologie fir Optimisatioun vun Stockage Käschten fir Systemer mat ausgeschwat Laascht Ongläichheet.
Fir tiered Späichere gëtt d'Performance vun der ieweschter Tier als éischt berechent, während den ënneschten Tier vun der Späichere als nëmmen zu der fehlend Späicherkapazitéit bäidroen. Fir e Hybrid Multi-Tier System ass et obligatoresch Flash Cache Technologie fir de Multi-Tier Pool ze benotzen fir d'Performance Ofsenkung fir plötzlech erhëtzt Daten aus dem ënneschten Niveau ze kompenséieren.
Benotzt eng SSD an engem Tiered Disk Pool
D'Benotzung vun SSDs an engem Multi-Level Disk Pool huet Variatiounen, ofhängeg vun der spezifescher Implementatioun vu Flash Cache Algorithmen vun engem bestëmmten Hiersteller.
D'allgemeng Praxis vun der Späicherpolitik fir en Disk Pool mat engem SSD Niveau ass SSD éischt.
Liesen Nëmmen Flash Cache. Fir e Read-only Flash Cache kënnt d'Späicherschicht op der SSD mat bedeitende Lokaliséierung vu Schreiwen, onofhängeg vum Cache.
Liesen / Schreiwen Flash Cache. Am Fall vu Flash-Cache gëtt d'Schreif-Cache-Gréisst fir d'éischt op déi maximal Cache-Gréisst gesat, an d'SSD-Späichertier erschéngt nëmme wann d'Cachegréisst net genuch ass fir déi ganz lokaliséiert Aarbechtslaascht ze servéieren.
SSD- a Cache-Performance-Berechnungen ginn all Kéier op Basis vun den Empfehlungen vum Hiersteller gemaach, awer ëmmer fir de schlëmmste Fall Szenario.
Source: will.com