Inledning
Ett informationssystem från användarens synvinkel är väl definierat i GOST RV 51987 - "ett automatiserat system, vars resultat är presentationen av utdatainformation för efterföljande användning." Om vi betraktar den interna strukturen, så är i huvudsak varje IS ett system av sammankopplade algoritmer implementerade i kod. I en vid mening av Turing-Church-avhandlingen omvandlar en algoritm (eller IS) en uppsättning indata till en uppsättning utdata.
Man skulle till och med kunna säga att omvandlingen av indata är meningen med att det finns ett informationssystem. Följaktligen bestäms värdet av IS och hela IS-komplexet genom värdet av in- och utdata.
Utifrån detta ska design starta och vara datadrivet, skräddarsy arkitektur och metoder till datans struktur och betydelse.
Lagrade data
Ett viktigt steg i förberedelserna för design är att erhålla egenskaperna hos alla datamängder som planeras för bearbetning och lagring. Dessa egenskaper inkluderar:
- Datavolym;
— Information om datas livscykel (tillväxt av nya data, livslängd, bearbetning av föråldrade data).
— Klassificering av uppgifter ur synvinkel påverkan på företagets kärnverksamhet (triaden av konfidentialitet, integritet, tillgänglighet) tillsammans med finansiella indikatorer (till exempel kostnaden för dataförlust under den senaste timmen);
— Geografi för databehandling (fysisk placering av bearbetningssystem).
— Regulatoriska krav för varje dataklass (till exempel Federal Law-152, PCI DSS).
Informationssystem
Data lagras inte bara, utan bearbetas (transformeras) också av informationssystem. Nästa steg efter att ha erhållit dataegenskaperna är den mest kompletta inventeringen av informationssystem, deras arkitektoniska egenskaper, ömsesidigt beroende och infrastrukturkrav i konventionella enheter för fyra typer av resurser:
— Processorns datorkraft;
— Mängd RAM;
— Krav på datalagringssystemets volym och prestanda.
— Krav på dataöverföringsnätet (externa kanaler, kanaler mellan IS-komponenter).
I detta fall måste det finnas krav för varje tjänst/mikrotjänst som en del av IS.
Separat är det nödvändigt att notera att för korrekt design är tillgången på data om inverkan av IS på företagets kärnverksamhet i form av kostnaden för IS-avbrottstid (rubel per timme) obligatorisk.
Hotmodell
Det måste finnas en formell modell av hot från vilken det är planerat att skydda data/tjänster. Dessutom inkluderar hotmodellen inte bara aspekter av konfidentialitet, utan också integritet och tillgänglighet. De där. Till exempel:
— Fel på den fysiska servern;
— Fel på omkopplaren överst i racket;
— Avbrott i den optiska kommunikationskanalen mellan datacenter.
— Fel i hela det operativa lagringssystemet.
I vissa fall skrivs hotmodeller inte bara för infrastrukturkomponenter, utan också för specifika informationssystem eller deras komponenter, till exempel ett DBMS-fel med logisk förstörelse av datastrukturen.
Alla beslut inom projektet för att skydda mot ett obeskrivet hot är onödiga.
Tillsynskrav
Om uppgifterna som behandlas omfattas av särskilda regler som fastställts av tillsynsmyndigheter krävs information om datamängder och regler för behandling/lagring.
RPO/RTO-mål
Att utforma alla typer av skydd kräver att man har måldataförlustindikatorer och målåterställningstid för vart och ett av de beskrivna hoten.
Helst bör RPO och RTO ha tillhörande kostnader för dataförlust och stillestånd per tidsenhet.
Indelning i resurspooler
Efter att ha samlat in all initial ingångsinformation är det första steget att gruppera datamängder och IP i pooler baserat på hotmodeller och regulatoriska krav. Typen av uppdelning av olika pooler bestäms - programmatiskt på systemprogramvarunivå eller fysiskt.
Exempel:
— Kretsen som behandlar personuppgifter är helt fysiskt separerad från andra system;
— Säkerhetskopieringar lagras på ett separat lagringssystem.
I detta fall kan poolerna vara ofullständigt oberoende, till exempel definieras två pooler av datorresurser (processorkraft + RAM), som använder en enda datalagringspool och en enda dataöverföringsresurspool.
Process kraft
Sammanfattning, processorkraftskraven för ett virtualiserat datacenter mäts i termer av antalet virtuella processorer (vCPU) och deras konsolideringsförhållande på fysiska processorer (pCPU). I det här specifika fallet är 1 pCPU = 1 fysisk processorkärna (exklusive Hyper-Threading). Antalet vCPU:er summeras över alla definierade resurspooler (som var och en kan ha sin egen konsolideringsfaktor).
Konsolideringskoefficienten för belastade system erhålls empiriskt, baserat på befintlig infrastruktur, eller genom pilotinstallation och lasttestning. För olastade system används "best practice". Specifikt citerar VMware det genomsnittliga förhållandet som 8:1.
Operativt minne
Det totala RAM-behovet erhålls genom enkel summering. Att använda RAM-överabonnemang rekommenderas inte.
Lagringsresurser
Lagringskrav erhålls genom att helt enkelt summera alla pooler efter kapacitet och prestanda.
Prestandakraven uttrycks i IOPS kombinerat med ett genomsnittligt läs/skrivförhållande och, om nödvändigt, en maximal svarslatens.
Kvalitetskrav (QoS) för specifika pooler eller system måste specificeras separat.
Datanätverksresurser
Datanätverkskraven erhålls genom att helt enkelt summera alla bandbreddspooler.
Quality of Service (QoS) och latenskrav (RTT) för specifika pooler eller system bör specificeras separat.
Som en del av kraven på datanätverksresurser anges också krav på isolering och/eller kryptering av nätverkstrafik och föredragna mekanismer (802.1q, IPSec, etc.).
Arkitekturval
Den här guiden täcker inte andra val än x86-arkitektur och 100 % servervirtualisering. Därför beror valet av datorundersystemsarkitektur på valet av servervirtualiseringsplattform, serverformfaktor och allmänna serverkonfigurationskrav.
Det viktigaste valet är säkerheten i att använda ett klassiskt tillvägagångssätt med separation av funktioner för bearbetning, lagring och överföring av data eller en konvergent sådan.
klassisk arkitektur involverar användningen av intelligenta externa delsystem för att lagra och överföra data, medan servrar endast bidrar med processorkraft och RAM till den gemensamma poolen av fysiska resurser. I extrema fall blir servrar helt anonyma och har inte bara sina egna diskar, utan inte ens en systemidentifierare. I det här fallet laddas operativsystemet eller hypervisorn från inbyggda flashmedia eller från ett externt datalagringssystem (start från SAN).
Inom ramen för klassisk arkitektur görs valet mellan blad och ställ främst utifrån följande principer:
— Kostnadseffektiv (i genomsnitt är rackmonterade servrar billigare);
— Beräkningstäthet (högre för blad).
— Energiförbrukning och värmeavledning (bladen har en högre specifik enhet per enhet).
— Skalbarhet och kontrollerbarhet (blad kräver i allmänhet mindre ansträngning för stora installationer).
- Användning av expansionskort (mycket begränsat val för blad).
Konvergent arkitektur (också känd som hyperkonvergerade) innebär att kombinera funktionerna för databehandling och lagring, vilket leder till användningen av lokala serverdiskar och, som en konsekvens, övergivande av den klassiska bladformfaktorn. För konvergerade system används antingen rackservrar eller klustersystem, som kombinerar flera bladservrar och lokala diskar i ett enda fall.
CPU/minne
För att korrekt beräkna konfigurationen måste du förstå typen av belastning för miljön eller vart och ett av de oberoende klustren.
CPU bunden – en miljö som är begränsad i prestanda av processorkraft. Att lägga till RAM kommer inte att förändra någonting när det gäller prestanda (antal virtuella datorer per server).
Minnesbunden – miljö begränsad av RAM. Mer RAM på servern gör att du kan köra fler virtuella datorer på servern.
GB / MHz (GB / pCPU) – det genomsnittliga förhållandet mellan förbrukning av RAM och processorkraft vid denna speciella belastning. Kan användas för att beräkna den nödvändiga mängden minne för en given prestanda och vice versa.
Beräkning av serverkonfiguration
Först måste du bestämma alla typer av belastning och bestämma dig för att kombinera eller dela upp olika beräkningspooler i olika kluster.
Därefter, för vart och ett av de definierade klustren, bestäms GB / MHz-förhållandet vid en belastning som är känd i förväg. Om belastningen inte är känd i förväg, men det finns en grov förståelse för nivån på processorkraftutnyttjande, kan du använda standard vCPU:pCPU-förhållanden för att omvandla poolkrav till fysiska.
För varje kluster, dividera summan av vCPU-poolkraven med koefficienten:
vCPUsum / vCPU:pCPU = pCPUsum – erforderligt antal fysiska enheter. kärnor
pCPUsum / 1.25 = pCPUht – antal kärnor justerat för Hyper-Threading
Låt oss anta att det är nödvändigt att beräkna ett kluster med 190 kärnor / 3.5 TB RAM. Samtidigt accepterar vi en målbelastning på 50 % av processorkraften och 75 % av RAM-minnet.
pCPU
190
CPU-användning
50%
MINNE
3500
Mem nytta
75%
Socket
Kärna
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
I det här fallet använder vi alltid avrundning uppåt till närmaste heltal (=ROUNDUP(A1;0)).
Från tabellen blir det uppenbart att flera serverkonfigurationer är balanserade för målindikatorerna:
— 26 servrar 2*6c / 192 GB
— 19 servrar 2*10c / 256 GB
— 10 servrar 2*18c / 512 GB
Valet av dessa konfigurationer måste sedan göras baserat på ytterligare faktorer, såsom värmepaket och tillgänglig kylning, redan använda servrar eller kostnad.
Funktioner för att välja en serverkonfiguration
Breda virtuella datorer. Om det är nödvändigt att vara värd för breda virtuella datorer (jämförbart med 1 NUMA-nod eller fler), rekommenderas det, om möjligt, att välja en server med en konfiguration som tillåter sådana virtuella datorer att stanna inom NUMA-noden. Med ett stort antal breda virtuella datorer finns det risk för fragmentering av klusterresurser och i det här fallet väljs servrar som gör att breda virtuella datorer kan placeras så tätt som möjligt.
Enstaka fel domänstorlek.
Valet av serverstorlek bygger också på principen att minimera domänen för enstaka fel. Till exempel när du väljer mellan:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
Allt annat lika måste du välja det andra alternativet, eftersom när en server misslyckas (eller underhålls) går inte 33 % av klusterresurserna förlorade, utan 17 %. På samma sätt halveras antalet VM och IS som drabbats av olyckan.
Beräkning av klassiska lagringssystem baserat på prestanda
Klassiska lagringssystem beräknas alltid med det värsta scenariot, exklusive påverkan av operationscachen och optimering av operationer.
Som grundläggande prestandaindikatorer tar vi mekanisk prestanda från disken (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS
Därefter beräknas antalet diskar i diskpoolen med hjälp av följande formel: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Var:
- TotalIOPS – total erforderlig prestanda i IOPS från diskpoolen
- RW – procentandel av läsoperationerna
- RAIDpen – RAID-straff för den valda RAID-nivån
Läs mer om Device RAID och RAID Penalty här - и и
Baserat på det resulterande antalet diskar beräknas möjliga alternativ som uppfyller kraven på lagringskapacitet, inklusive alternativ med flernivålagring.
Beräkningen av system som använder SSD som lagringslager beaktas separat.
Funktioner i beräkningssystem med Flash Cache
Flash-cache – ett gemensamt namn för all proprietär teknologi för att använda flashminne som en andra nivås cache. När man använder en flashcache beräknas lagringssystemet vanligtvis ge en jämn belastning från magnetiska skivor, medan toppen betjänas av cachen.
I det här fallet är det nödvändigt att förstå belastningsprofilen och graden av lokalisering av åtkomst till block med lagringsvolymer. Flash-cache är en teknik för arbetsbelastningar med mycket lokaliserade frågor och är praktiskt taget otillämplig för enhetligt laddade volymer (som för analyssystem).
Beräkning av low-end/mid-range hybridsystem
Hybridsystem av lägre och medelklass använder flernivålagring med data som flyttas mellan nivåerna enligt ett schema. Samtidigt är storleken på flernivålagringsblocket för de bästa modellerna 256 MB. Dessa funktioner tillåter oss inte att betrakta nivåbaserad lagringsteknik som en teknik för att öka produktiviteten, vilket många felaktigt tror. Flernivåförvaring i låg- och medelklasssystem är en teknik för att optimera lagringskostnaderna för system med uttalade lastojämnheter.
För nivålagring beräknas prestandan för den översta nivån först, medan den nedre nivån av lagring endast anses bidra till den saknade lagringskapaciteten. För ett hybrid flerskiktssystem är det obligatoriskt att använda flash-cache-teknik för flerskiktspoolen för att kompensera för prestandaminskningen för plötsligt uppvärmd data från den lägre nivån.
Använda en SSD i en nivåbaserad diskpool
Användningen av SSD:er i en diskpool på flera nivåer har variationer, beroende på den specifika implementeringen av flash-cache-algoritmer av en given tillverkare.
Den allmänna praxisen för lagringspolicy för en diskpool med en SSD-nivå är SSD först.
Lässkyddad Flash-cache. För en skrivskyddad flashcache kommer lagringslagret på SSD:n med betydande lokalisering av skrivningar, oavsett cache.
Läs/skriv Flash-cache. När det gäller flashcache ställs först skrivcachestorleken in på maximal cachestorlek och SSD-lagringsnivån visas endast när cachestorleken är otillräcklig för att betjäna hela den lokala arbetsbelastningen.
SSD- och cacheprestandaberäkningar görs varje gång baserat på tillverkarens rekommendationer, men alltid i värsta fall.
Källa: will.com