úvod
Informační systém z pohledu uživatele je dobře definován v GOST RV 51987 - „automatizovaný systém, jehož výsledkem je prezentace výstupních informací pro následné použití“. Pokud vezmeme v úvahu vnitřní strukturu, pak je v podstatě jakýkoli IS systémem vzájemně propojených algoritmů implementovaných v kódu. V širokém smyslu teze Turing-Church algoritmus (nebo IS) transformuje sadu vstupních dat na sadu výstupních dat.
Dalo by se dokonce říci, že transformace vstupních dat je smyslem existence informačního systému. V souladu s tím je hodnota IS a celého komplexu IS určena prostřednictvím hodnoty vstupních a výstupních dat.
Na základě toho musí začít návrh a musí být řízen daty, přičemž architektura a metody musí být přizpůsobeny struktuře a významu dat.
Uložená data
Klíčovou fází přípravy návrhu je získání charakteristik všech datových sad plánovaných pro zpracování a uložení. Mezi tyto vlastnosti patří:
- objem dat;
— Informace o životním cyklu dat (nárůst nových dat, životnost, zpracování zastaralých dat);
— Klasifikace údajů se specifikacemi dopad na hlavní podnikání společnosti (triáda důvěrnosti, integrity, dostupnosti) spolu s finančními ukazateli (například náklady na ztrátu dat za poslední hodinu);
— Geografie zpracování dat (fyzické umístění systémů zpracování);
— Regulační požadavky pro každou datovou třídu (například federální zákon-152, PCI DSS).
Informační systémy
Data jsou nejen ukládána, ale také zpracovávána (transformována) informačními systémy. Dalším krokem po získání datových charakteristik je nejúplnější soupis informačních systémů, jejich architektonických prvků, vzájemných závislostí a požadavků na infrastrukturu v konvenčních jednotkách pro čtyři typy zdrojů:
— výpočetní výkon procesoru;
— množství paměti RAM;
— Požadavky na objem a výkon systému ukládání dat;
— Požadavky na síť pro přenos dat (externí kanály, kanály mezi komponenty IS).
V tomto případě musí existovat požadavky na každou službu/mikroslužbu jako součást IS.
Samostatně je nutné poznamenat, že pro správný návrh je povinná dostupnost údajů o dopadu IS na hlavní byznys společnosti v podobě nákladů na odstávky IS (rubly za hodinu).
Model ohrožení
Musí existovat formální model hrozeb, před kterými se plánuje ochrana dat/služeb. Model hrozeb navíc zahrnuje nejen aspekty důvěrnosti, ale také integritu a dostupnost. Tito. Například:
— Selhání fyzického serveru;
— Selhání přepínače v horní části stojanu;
— narušení optického komunikačního kanálu mezi datovými centry;
— Selhání celého provozního skladovacího systému.
V některých případech jsou modely hrozeb psány nejen pro komponenty infrastruktury, ale i pro konkrétní informační systémy nebo jejich komponenty, např. selhání DBMS s logickou destrukcí datové struktury.
Všechna rozhodnutí v rámci projektu na ochranu před nepopsanou hrozbou jsou zbytečná.
Regulační požadavky
Pokud zpracovávané údaje podléhají zvláštním pravidlům stanoveným regulačními orgány, jsou vyžadovány informace o souborech údajů a pravidlech zpracování/ukládání.
RPO/RTO cíle
Návrh jakéhokoli typu ochrany vyžaduje mít indikátory cílové ztráty dat a cílové doby obnovení služby pro každou z popsaných hrozeb.
V ideálním případě by RPO a RTO měly mít spojené náklady na ztrátu dat a výpadky za jednotku času.
Rozdělení do zdrojů
Po shromáždění všech počátečních vstupních informací je prvním krokem seskupení souborů dat a IP do skupin na základě modelů hrozeb a regulačních požadavků. Určuje se typ rozdělení různých poolů – programově na úrovni systémového softwaru nebo fyzicky.
Příklady:
— Okruh zpracovávající osobní údaje je zcela fyzicky oddělen od ostatních systémů;
— Zálohy jsou uloženy na samostatném úložném systému.
V tomto případě mohou být fondy neúplně nezávislé, například jsou definovány dva fondy výpočetních zdrojů (výkon procesoru + RAM), které využívají jeden fond pro ukládání dat a jeden fond zdrojů pro přenos dat.
Procesní výkon
Abstrakt, požadavky na výpočetní výkon virtualizovaného datového centra jsou měřeny z hlediska počtu virtuálních procesorů (vCPU) a jejich konsolidačního poměru na fyzických procesorech (pCPU). V tomto konkrétním případě 1 pCPU = 1 fyzické jádro procesoru (kromě Hyper-Threadingu). Počet vCPU se sčítá ve všech definovaných fondech zdrojů (každý z nich může mít svůj vlastní konsolidační faktor).
Konsolidační koeficient pro zatížené systémy se získá empiricky na základě existující infrastruktury nebo prostřednictvím pilotní instalace a zátěžového testování. U nezatížených systémů se používá „nejlepší praxe“. Konkrétně VMware uvádí průměrný poměr 8:1.
Operační paměť
Celkový požadavek na RAM se získá jednoduchým sečtením. Použití nadměrného odběru RAM se nedoporučuje.
Úložné prostředky
Požadavky na úložiště se získají jednoduchým sečtením všech fondů podle kapacity a výkonu.
Požadavky na výkon jsou vyjádřeny v IOPS v kombinaci s průměrným poměrem čtení/zápis a v případě potřeby s maximální latencí odezvy.
Požadavky na kvalitu služby (QoS) pro konkrétní fondy nebo systémy musí být specifikovány samostatně.
Zdroje datové sítě
Požadavky na datovou síť se získají jednoduchým sečtením všech fondů šířky pásma.
Požadavky na kvalitu služby (QoS) a latenci (RTT) pro konkrétní fondy nebo systémy by měly být specifikovány samostatně.
V rámci požadavků na zdroje datové sítě jsou uvedeny také požadavky na izolaci a/nebo šifrování síťového provozu a preferované mechanismy (802.1q, IPSec atd.).
Výběr architektury
Tato příručka nepojednává o žádné jiné volbě než architektuře x86 a 100% virtualizaci serverů. Volba architektury výpočetního subsystému proto závisí na volbě platformy virtualizace serveru, faktoru provedení serveru a obecných požadavcích na konfiguraci serveru.
Klíčovým bodem volby je jistota použití klasického přístupu s oddělením funkcí zpracování, ukládání a přenosu dat nebo konvergentní.
klasické architektury zahrnuje použití inteligentních externích subsystémů pro ukládání a přenos dat, zatímco servery přispívají pouze výpočetním výkonem a RAM do společného fondu fyzických zdrojů. V extrémních případech se servery stávají zcela anonymními a nemají pouze vlastní disky, ale dokonce ani systémový identifikátor. V tomto případě je operační systém nebo hypervizor načten z vestavěného flash média nebo z externího systému pro ukládání dat (boot ze SAN).
V rámci klasické architektury je volba mezi blade a racky primárně založena na následujících principech:
— Cenově efektivní (v průměru jsou servery pro montáž do racku levnější);
— Výpočetní hustota (vyšší pro lopatky);
— Spotřeba energie a rozptyl tepla (lopatky mají vyšší měrnou jednotku na jednotku);
— Škálovatelnost a ovladatelnost (lopatky obecně vyžadují menší úsilí pro velké instalace);
- Použití rozšiřujících karet (velmi omezený výběr pro blade).
Konvergentní architektura (také známý jako hyperkonvergovaný) zahrnuje kombinaci funkcí zpracování a ukládání dat, což vede k použití lokálních serverových disků a v důsledku toho k opuštění klasického blade form factoru. Pro konvergované systémy se používají buď rackové servery, nebo clusterové systémy, které kombinují několik blade serverů a lokálních disků v jednom případě.
CPU/paměť
Chcete-li správně vypočítat konfiguraci, musíte pochopit typ zatížení pro prostředí nebo každý z nezávislých clusterů.
Vázaný na CPU – prostředí omezené výkonem procesoru. Přidání RAM nezmění nic z hlediska výkonu (počet virtuálních počítačů na server).
Vázaná na paměť – prostředí omezené RAM. Více paměti RAM na serveru umožňuje provozovat více virtuálních počítačů na serveru.
GB / MHz (GB / pCPU) – průměrný poměr spotřeby RAM a výkonu procesoru při dané konkrétní zátěži. Lze použít k výpočtu potřebného množství paměti pro daný výkon a naopak.
Výpočet konfigurace serveru
Nejprve musíte určit všechny typy zátěže a rozhodnout se o kombinaci nebo rozdělení různých výpočetních fondů do různých clusterů.
Dále se pro každý z definovaných shluků určí poměr GB/MHz při předem známé zátěži. Pokud zatížení není předem známo, ale existuje přibližná znalost úrovně využití výkonu procesoru, můžete použít standardní poměry vCPU:pCPU k převodu požadavků fondu na fyzické.
Pro každý cluster vydělte součet požadavků fondu vCPU koeficientem:
vCPUsum / vCPU:pCPU = pCPUsum – požadovaný počet fyzických jednotek. jádra
pCPUsum / 1.25 = pCPUht – počet jader upravený pro Hyper-Threading
Předpokládejme, že je nutné počítat cluster se 190 jádry / 3.5 TB RAM. Zároveň akceptujeme cílové zatížení 50 % výkonu procesoru a 75 % RAM.
pCPU
190
využití CPU
50%
Mem
3500
Nástroj Mem
75%
Zásuvka
Jádro
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
V tomto případě vždy používáme zaokrouhlení nahoru na nejbližší celé číslo (=ROUNDUP(A1;0)).
Z tabulky je zřejmé, že několik konfigurací serveru je vyváženo pro cílové indikátory:
— 26 serverů 2*6c / 192 GB
— 19 serverů 2*10c / 256 GB
— 10 serverů 2*18c / 512 GB
Výběr těchto konfigurací pak musí být proveden na základě dalších faktorů, jako je tepelný balíček a dostupné chlazení, již použité servery nebo cena.
Funkce výběru konfigurace serveru
Široké virtuální počítače. Pokud je nutné hostovat široké virtuální počítače (srovnatelné s 1 uzlem NUMA nebo více), doporučuje se, pokud je to možné, vybrat server s konfigurací, která takovým virtuálním počítačům umožňuje zůstat v uzlu NUMA. Při velkém počtu širokých virtuálních počítačů existuje nebezpečí fragmentace prostředků clusteru a v tomto případě se vybírají servery, které umožňují umístění širokých virtuálních počítačů co nejhustěji.
Velikost domény s jedním selháním.
Volba velikosti serveru je také založena na principu minimalizace domény jednoho selhání. Například při výběru mezi:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
Pokud jsou všechny ostatní věci stejné, musíte zvolit druhou možnost, protože když jeden server selže (nebo je udržován), neztratí se 33 % prostředků clusteru, ale 17 %. Stejně tak je počet VM a IS zasažených havárií poloviční.
Výpočet klasických úložných systémů na základě výkonu
Klasické úložné systémy jsou vždy počítány s použitím nejhoršího scénáře, s vyloučením vlivu provozní cache a optimalizace operací.
Jako základní ukazatele výkonu bereme mechanický výkon z disku (IOPSdisk):
– 7.2 k – 75 IOPS
– 10 k – 125 IOPS
– 15 k – 175 IOPS
Dále se počet disků v diskové oblasti vypočítá pomocí následujícího vzorce: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Kde:
- TotalIOPS – celkový požadovaný výkon v IOPS z diskové oblasti
- RW – procento operací čtení
- RAID pero – Pokuta RAID pro vybranou úroveň RAID
Přečtěte si více o RAID zařízení a penalizaci RAID zde - и и
Na základě výsledného počtu disků jsou vypočítány možné varianty splňující požadavky na kapacitu úložiště, včetně variant s víceúrovňovým úložištěm.
Výpočet systémů využívajících SSD jako úložnou vrstvu je uvažován samostatně.
Vlastnosti výpočetních systémů s Flash Cache
flash-cache – společný název pro všechny proprietární technologie pro použití flash paměti jako mezipaměti druhé úrovně. Při použití flash mezipaměti je úložný systém obvykle vypočítán tak, aby poskytoval stálé zatížení z magnetických disků, zatímco vrchol je obsluhován mezipamětí.
V tomto případě je nutné porozumět profilu zatížení a stupni lokalizace přístupu k blokům úložných svazků. Flash cache je technologie pro pracovní zátěže s vysoce lokalizovanými dotazy a je prakticky nepoužitelná pro jednotně načtené svazky (například pro analytické systémy).
Výpočet hybridních systémů nižší a střední třídy
Hybridní systémy nižší a střední třídy využívají víceúrovňové úložiště s přesuny dat mezi úrovněmi podle plánu. Velikost víceúrovňového úložného bloku u nejlepších modelů je přitom 256 MB. Tyto vlastnosti nám neumožňují považovat technologii vrstveného úložiště za technologii pro zvýšení produktivity, jak se mnoho lidí mylně domnívá. Víceúrovňové úložiště v systémech nízké a střední třídy je technologie pro optimalizaci nákladů na úložiště pro systémy s výraznou nerovnoměrností zatížení.
U vrstveného úložiště se nejprve vypočítá výkon horní vrstvy, zatímco se má za to, že spodní vrstva úložiště pouze přispívá k chybějící úložné kapacitě. Pro hybridní vícevrstvý systém je povinné používat technologii flash cache pro vícevrstvý fond, aby se kompenzoval pokles výkonu pro náhle zahřátá data z nižší úrovně.
Použití SSD v Tired Disk Pool
Použití SSD ve víceúrovňovém diskovém fondu se liší v závislosti na konkrétní implementaci algoritmů flash cache daným výrobcem.
Obecná praxe zásad úložiště pro diskový fond s úrovní SSD je SSD jako první.
Flash Cache pouze pro čtení. U flash cache pouze pro čtení přichází úložná vrstva na SSD s významnou lokalizací zápisů bez ohledu na mezipaměť.
Čtení/zápis mezipaměti Flash. V případě flash mezipaměti je velikost mezipaměti pro zápis nejprve nastavena na maximální velikost mezipaměti a vrstva úložiště SSD se objeví pouze v případě, že velikost mezipaměti není dostatečná pro obsluhu celé lokalizované zátěže.
Výpočty výkonu SSD a mezipaměti se provádějí pokaždé na základě doporučení výrobce, ale vždy pro nejhorší scénář.
Zdroj: www.habr.com