Bevezetés
Az információs rendszert a felhasználó szemszögéből jól meghatározza a GOST RV 51987 - „egy automatizált rendszer, amelynek eredménye a kimeneti információk bemutatása a későbbi használatra”. Ha figyelembe vesszük a belső struktúrát, akkor lényegében bármely IS kódban megvalósított, egymással összefüggő algoritmusok rendszere. A Turing-Church tézis tágabb értelmében egy algoritmus (vagy IS) a bemeneti adatok halmazát kimeneti adatok halmazává alakítja.
Akár azt is mondhatnánk, hogy a bemeneti adatok átalakítása egy információs rendszer létezésének értelme. Ennek megfelelően az IS és a teljes IS komplex értékét a bemeneti és kimeneti adatok értéke határozza meg.
Ez alapján a tervezésnek el kell indulnia és adatvezéreltnek kell lennie, az architektúrát és a módszereket az adatok szerkezetéhez és jelentőségéhez szabva.
Tárolt adatok
A tervezésre való felkészülés egyik kulcsfontosságú szakasza a feldolgozásra és tárolásra tervezett összes adatkészlet jellemzőinek megszerzése. Ezek a jellemzők a következők:
- Adatmennyiség;
— Tájékoztatás az adatok életciklusáról (új adatok növekedése, élettartama, elavult adatok feldolgozása);
— Az adatok osztályozása nézőpontból a vállalat alaptevékenységére gyakorolt hatás (a titoktartás, integritás, elérhetőség hármasa), valamint a pénzügyi mutatók (például az adatvesztés költsége az elmúlt órában);
— Az adatfeldolgozás földrajza (a feldolgozó rendszerek fizikai elhelyezkedése);
— Szabályozási követelmények az egyes adatosztályokra (például Szövetségi törvény-152, PCI DSS).
Információs rendszerek
Az adatokat az információs rendszerek nemcsak tárolják, hanem feldolgozzák (átalakítják). Az adatjellemzők megszerzése után a következő lépés az információs rendszerek legteljesebb leltározása, azok felépítési jellemzői, kölcsönös függőségei és infrastrukturális követelményei a hagyományos egységekben négyféle erőforrás esetében:
— Processzor számítási teljesítménye;
— RAM mennyisége;
— Az adattároló rendszer térfogatára és teljesítményére vonatkozó követelmények;
— Az adatátviteli hálózatra vonatkozó követelmények (külső csatornák, csatornák az IS-komponensek között).
Ebben az esetben minden szolgáltatáshoz/mikroszolgáltatáshoz követelményeknek kell lenniük az IS részeként.
Külön meg kell jegyezni, hogy a helyes tervezés érdekében kötelező az IS-nek a vállalat alaptevékenységére gyakorolt hatására vonatkozó adatok rendelkezésre állása az IS leállási költsége (rubel óránként) formájában.
Fenyegetés modell
A fenyegetések formális modelljének kell lennie, amelytől az adatok/szolgáltatások védelmét tervezik. Ezen túlmenően a fenyegetettségi modell nemcsak a titoktartás szempontjait tartalmazza, hanem az integritást és a rendelkezésre állást is. Azok. Például:
— a fizikai szerver meghibásodása;
— az állvány tetejére szerelt kapcsoló meghibásodása;
— Az adatközpontok közötti optikai kommunikációs csatorna megszakadása;
— A teljes működő tárolórendszer meghibásodása.
Egyes esetekben a fenyegetésmodelleket nem csak infrastruktúra-összetevőkre írják, hanem bizonyos információs rendszerekre vagy azok összetevőire is, például egy DBMS-hiba esetén, amely az adatstruktúra logikai megsemmisítésével jár.
A projekten belül minden olyan döntés, amely a leírhatatlan fenyegetésekkel szembeni védelmet célozza, szükségtelen.
Szabályozási követelmények
Ha a kezelt adatokra a szabályozók által meghatározott speciális szabályok vonatkoznak, az adatállományokról és a feldolgozási/tárolási szabályokról tájékoztatást kell adni.
RPO/RTO célok
Bármilyen típusú védelem megtervezéséhez minden leírt fenyegetés esetében célzott adatvesztési mutatók és cél szolgáltatás-helyreállítási idő szükséges.
Ideális esetben az RPO-nak és az RTO-nak rendelkeznie kell az adatvesztés és az állásidő egységnyi időre eső költségeivel.
Felosztás erőforráskészletekre
Az összes kezdeti bemeneti információ összegyűjtése után az első lépés az adatkészletek és az IP-címek csoportosítása a fenyegetésmodellek és a szabályozási követelmények alapján. A különböző készletek felosztásának típusát meghatározzák - programozottan a rendszerszoftver szintjén vagy fizikailag.
Példák:
— A személyes adatokat feldolgozó áramkör fizikailag teljesen el van választva más rendszerektől;
— A biztonsági másolatokat külön tárolórendszerben tárolják.
Ebben az esetben a készletek nem teljesen függetlenek lehetnek, például két számítási erőforrás készlet van meghatározva (processzor teljesítmény + RAM), amelyek egyetlen adattárolási készletet és egyetlen adatátviteli erőforráskészletet használnak.
Feldolgozási teljesítmény
Absztrakt, a virtualizált adatközpontok feldolgozási teljesítményigényét a virtuális processzorok (vCPU-k) számában és azok fizikai processzorokon (pCPU) való konszolidációs arányában mérik. Ebben a konkrét esetben 1 pCPU = 1 fizikai processzormag (a Hyper-Threading kivételével). A vCPU-k számát a rendszer az összes meghatározott erőforráskészletben összegzi (mindegyiknek saját konszolidációs tényezője lehet).
A terhelt rendszerek konszolidációs együtthatóját empirikusan, a meglévő infrastruktúra alapján, vagy kísérleti telepítéssel és terhelési teszteléssel határozzák meg. A terheletlen rendszerek esetében a „legjobb gyakorlatot” használják. Konkrétan a VMware az átlagos arányt 8:1-ben említi.
véletlen hozzáférésű memória
A teljes RAM-igényt egyszerű összegzéssel kapjuk meg. A RAM túlfizetés használata nem javasolt.
Tárolási erőforrások
A tárolási igényeket úgy kapjuk meg, hogy egyszerűen összegezzük az összes készletet kapacitás és teljesítmény alapján.
A teljesítménykövetelményeket IOPS-ben fejezik ki, kombinálva az átlagos olvasási/írási aránnyal, és szükség esetén a maximális válasz késleltetéssel.
Az egyes készletekre vagy rendszerekre vonatkozó szolgáltatásminőségi (QoS) követelményeket külön kell meghatározni.
Adathálózati erőforrások
Az adathálózati követelmények az összes sávszélesség-készlet egyszerű összegzésével érhetők el.
Az egyes készletekre vagy rendszerekre vonatkozó szolgáltatásminőségi (QoS) és késleltetési (RTT) követelményeket külön kell meghatározni.
Az adathálózati erőforrásokra vonatkozó követelmények részeként a hálózati forgalom elkülönítésére és/vagy titkosítására vonatkozó követelmények, valamint a preferált mechanizmusok (802.1q, IPSec stb.) is szerepelnek.
Építészet kiválasztása
Ez az útmutató nem foglalkozik az x86 architektúrán és a 100%-os szervervirtualizáción kívüli más lehetőségekkel. Ezért a számítási alrendszer-architektúra kiválasztása a kiszolgáló virtualizációs platformjának, a kiszolgáló formai tényezőjének és az általános szerverkonfigurációs követelményeknek a megválasztásán múlik.
A választás kulcsfontosságú pontja a klasszikus megközelítés használatának bizonyossága az adatok feldolgozásának, tárolásának és továbbításának elválasztásával, vagy egy konvergens funkcióval.
klasszikus építészet intelligens külső alrendszerek használatát foglalja magában az adatok tárolására és továbbítására, míg a szerverek csak feldolgozási teljesítményt és RAM-ot adnak a fizikai erőforrások közös készletéhez. Extrém esetben a szerverek teljesen anonimmá válnak, nemcsak saját lemezük van, de még rendszerazonosító sem. Ebben az esetben az operációs rendszer vagy a hypervisor a beépített flash adathordozóról vagy egy külső adattároló rendszerről töltődik be (a rendszerindítás SAN-ról).
A klasszikus építészet keretein belül a pengék és az állványok közötti választás elsősorban a következő elvek alapján történik:
— Költséghatékony (átlagosan a rack-be szerelhető szerverek olcsóbbak);
— Számítási sűrűség (magasabb a pengéknél);
— Energiafogyasztás és hőleadás (a lapátok egységenkénti fajlagos egysége magasabb);
— Skálázhatóság és szabályozhatóság (a lapátok általában kisebb erőfeszítést igényelnek a nagy telepítéseknél);
- Bővítőkártyák használata (nagyon korlátozott választás a pengékhez).
Konvergens architektúra (más néven hiperkonvergált) magában foglalja az adatfeldolgozás és -tárolás funkcióinak kombinálását, ami a helyi szerverlemezek használatához, és ennek következtében a klasszikus blade formai tényező elhagyásához vezet. A konvergens rendszerek esetében vagy rack-kiszolgálókat, vagy fürtrendszereket használnak, amelyek több blade szervert és helyi lemezt kombinálnak egyetlen esetben.
CPU/memória
A konfiguráció helyes kiszámításához meg kell értenie a környezet vagy az egyes független fürtök terhelésének típusát.
CPU kötött – a processzor teljesítménye által korlátozott teljesítményű környezet. A RAM hozzáadása semmit sem változtat a teljesítményen (kiszolgálónkénti virtuális gépek száma).
Memória kötve – RAM által korlátozott környezet. Több RAM a kiszolgálón lehetővé teszi több virtuális gép futtatását a kiszolgálón.
GB / MHz (GB / pCPU) – a RAM és a processzor teljesítményének átlagos aránya ezen a terhelésen. Használható az adott teljesítményhez szükséges memóriamennyiség kiszámítására és fordítva.
Szerver konfigurációs számítás
Először is meg kell határoznia a terhelés minden típusát, és el kell döntenie, hogy a különböző számítási készleteket különböző fürtökbe egyesíti vagy felosztja.
Ezután minden egyes meghatározott klaszter esetében meghatározzuk a GB/MHz arányt előre ismert terhelés mellett. Ha a terhelés nem ismert előre, de hozzávetőlegesen tisztában van a processzorteljesítmény-kihasználtság szintjével, használhatja a szabványos vCPU:pCPU arányokat a készletszükségletek fizikaivá alakításához.
Minden klaszternél ossza el a vCPU-készletigények összegét az együtthatóval:
vCPUsum / vCPU:pCPU = pCPUsum – a szükséges fizikai egységek száma. magok
pCPUsum / 1.25 = pCPUht – a magok száma a Hyper-Threading-hez igazítva
Tegyük fel, hogy ki kell számítani egy fürtöt 190 maggal / 3.5 TB RAM-mal. Ugyanakkor elfogadjuk a processzorteljesítmény 50%-ának és a RAM 75%-ának célterhelését.
pCPU
190
CPU segédprogram
50%
Mem
3500
Mem segédprogram
75%
Foglalat
Mag
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
Ebben az esetben mindig a legközelebbi egész számra felfelé kerekítést használunk (=ROUNDUP(A1;0)).
A táblázatból nyilvánvalóvá válik, hogy több szerverkonfiguráció kiegyensúlyozott a célmutatókhoz:
— 26 szerver 2*6c / 192 GB
— 19 szerver 2*10c / 256 GB
— 10 szerver 2*18c / 512 GB
A konfigurációk kiválasztását ezután további tényezők alapján kell meghozni, mint például a hőcsomag és a rendelkezésre álló hűtés, a már használt szerverek vagy a költségek.
A szerverkonfiguráció kiválasztásának jellemzői
Széles virtuális gépek. Ha széles virtuális gépek (amelyek 1 vagy több NUMA-csomóponthoz hasonlíthatók) hosztolására van szükség, ajánlatos lehetőség szerint olyan kiszolgálót választani, amelynek konfigurációja lehetővé teszi, hogy az ilyen virtuális gépek a NUMA-csomóponton belül maradjanak. Nagyszámú széles virtuális gép esetén fennáll a fürterőforrások széttöredezettségének veszélye, és ebben az esetben olyan kiszolgálókat választanak ki, amelyek lehetővé teszik a széles virtuális gépek minél sűrűbb elhelyezését.
Egyszeri hiba tartomány mérete.
A szerver méretének megválasztása is az egyszeri hibatartomány minimalizálásának elvén alapul. Például, ha a következők közül választ:
- 3 x 4*10c / 512 GB
- 6 x 2*10c / 256 GB
Ha minden más tényező változatlan, akkor a második lehetőséget kell választania, mivel ha egy szerver meghibásodik (vagy karbantartás alatt áll), akkor nem a fürt erőforrásainak 33%-a, hanem 17%-a vész el. Ugyanígy a felére csökken a baleset által érintett virtuális gépek és IS-ek száma.
Klasszikus tárolórendszerek számítása teljesítmény alapján
A klasszikus tárolórendszerek számítása mindig a legrosszabb forgatókönyv szerint történik, kizárva a működési gyorsítótár és a műveletek optimalizálásának hatását.
Alapvető teljesítménymutatóként a mechanikai teljesítményt a lemezről (IOPSdisk) vesszük:
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS
Ezután a lemeztárban lévő lemezek számát a következő képlet segítségével számítjuk ki: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Ahol:
- TotalIOPS – teljes szükséges teljesítmény az IOPS-ben a lemeztárból
- RW – az olvasási műveletek százalékos aránya
- RAID toll – RAID-büntetés a kiválasztott RAID-szinthez
További információ az eszköz RAID-ről és a RAID-büntetésről itt - и и
A kapott lemezek száma alapján kiszámítják a lehetséges opciókat, amelyek megfelelnek a tárolási kapacitás követelményeinek, beleértve a többszintű tárolással rendelkező opciókat is.
Az SSD-t tárolórétegként használó rendszerek számítását külön vizsgáljuk.
A Flash-gyorsítótárral rendelkező számítási rendszerek jellemzői
Flash gyorsítótár – a flash memória második szintű gyorsítótárként való használatára szolgáló összes szabadalmaztatott technológia közös neve. Flash-gyorsítótár használatakor a tárolórendszert általában úgy számítják ki, hogy egyenletes terhelést biztosítson a mágneses lemezekről, míg a csúcsot a gyorsítótár szolgálja ki.
Ebben az esetben meg kell érteni a terhelési profilt és a tárolókötetek blokkjaihoz való hozzáférés lokalizációjának mértékét. A Flash-gyorsítótár olyan technológia, amely nagymértékben lokalizált lekérdezéseket tartalmazó munkaterhelésekhez használható, és gyakorlatilag nem alkalmazható egyenletesen betöltött köteteknél (például elemzőrendszereknél).
Alacsony/középkategóriás hibrid rendszerek számítása
Az alsó és középosztály hibrid rendszerei többszintű tárolást használnak, és az adatok ütemezetten mozognak a szintek között. Ugyanakkor a legjobb modellek többszintű tárolóblokkjának mérete 256 MB. Ezek a funkciók nem teszik lehetővé, hogy a többszintű tárolási technológiát a termelékenység növelésének technológiájának tekintsük, ahogyan azt sokan tévesen hiszik. A többszintű tárolás alacsony és középkategóriás rendszerekben egy olyan technológia, amely optimalizálja a tárolási költségeket olyan rendszerek esetében, ahol a terhelés egyenetlensége van.
Többszintű tárolás esetén először a felső szint teljesítményét számítják ki, míg az alsó szint csak a hiányzó tárolókapacitáshoz járul hozzá. Hibrid többrétegű rendszereknél kötelező a flash gyorsítótár technológia használata a többrétegű poolhoz, hogy kompenzálják az alacsonyabb szintről hirtelen felmelegedett adatok teljesítménycsökkenését.
SSD használata rétegzett lemeztárban
Az SSD-k használata többszintű lemeztárban változatos, attól függően, hogy az adott gyártó milyen konkrét implementációt biztosít a flash-gyorsítótár-algoritmusokhoz.
Az SSD-szintű lemeztár tárolási szabályzatának általános gyakorlata az SSD.
Csak olvasható Flash gyorsítótár. A csak olvasható flash-gyorsítótár esetében az SSD-n lévő tárolóréteg jelentős írási lokalizációval rendelkezik, a gyorsítótártól függetlenül.
Flash gyorsítótár olvasása/írása. Flash-gyorsítótár esetén az írási gyorsítótár mérete először a maximális gyorsítótárméretre van állítva, és az SSD-tárolóréteg csak akkor jelenik meg, ha a gyorsítótár mérete nem elegendő a teljes lokalizált munkaterhelés kiszolgálásához.
Az SSD és a gyorsítótár teljesítményének számításai minden alkalommal a gyártó ajánlásai alapján készülnek, de mindig a legrosszabb esetre.
Forrás: will.com