Introductie
Een informatiesysteem vanuit het oogpunt van de gebruiker is goed gedefinieerd in GOST RV 51987 - "een geautomatiseerd systeem, waarvan het resultaat de presentatie is van uitvoerinformatie voor later gebruik." Als we naar de interne structuur kijken, is elke IS in wezen een systeem van onderling verbonden algoritmen, geïmplementeerd in code. In de brede zin van de Turing-Church-stelling transformeert een algoritme (of IS) een reeks invoergegevens in een reeks uitvoergegevens.
Je zou zelfs kunnen zeggen dat de transformatie van invoergegevens de betekenis is van het bestaan van een informatiesysteem. Dienovereenkomstig wordt de waarde van de IS en het gehele IS-complex bepaald door de waarde van invoer- en uitvoergegevens.
Op basis hiervan moet het ontwerp starten en datagestuurd zijn, waarbij architectuur en methoden worden afgestemd op de structuur en betekenis van de data.
Opgeslagen informatie
Een belangrijke fase bij de voorbereiding op het ontwerp is het verkrijgen van de kenmerken van alle datasets die gepland zijn voor verwerking en opslag. Deze kenmerken omvatten:
- Datavolume;
— Informatie over de levenscyclus van data (groei van nieuwe data, levensduur, verwerking van verouderde data);
— Classificatie van gegevens vanuit het gezichtspunt impact op de kernactiviteiten van het bedrijf (de triade van vertrouwelijkheid, integriteit, beschikbaarheid) samen met financiële indicatoren (bijvoorbeeld de kosten van gegevensverlies in het afgelopen uur);
— Geografie van gegevensverwerking (fysieke locatie van verwerkingssystemen);
— Regelgevende vereisten voor elke gegevensklasse (bijvoorbeeld Federal Law-152, PCI DSS).
Informatie Systemen
Gegevens worden niet alleen opgeslagen, maar ook verwerkt (getransformeerd) door informatiesystemen. De volgende stap na het verkrijgen van de datakarakteristieken is de meest complete inventarisatie van informatiesystemen, hun architecturale kenmerken, onderlinge afhankelijkheden en infrastructuurvereisten in conventionele eenheden voor vier soorten bronnen:
— rekenkracht van processor;
— Hoeveelheid RAM;
— Eisen voor het volume en de prestaties van het gegevensopslagsysteem;
— Eisen aan het datatransmissienetwerk (externe kanalen, kanalen tussen IS-componenten).
In dit geval moeten er vereisten zijn voor elke dienst/microservice als onderdeel van de IS.
Afzonderlijk moet worden opgemerkt dat voor een correct ontwerp de beschikbaarheid van gegevens over de impact van de IS op de kernactiviteiten van het bedrijf in de vorm van de kosten van IS-downtime (roebels per uur) verplicht is.
Bedreigingsmodel
Er moet een formeel model van bedreigingen zijn waartegen data/diensten moeten worden beschermd. Bovendien omvat het dreigingsmodel niet alleen aspecten van vertrouwelijkheid, maar ook integriteit en beschikbaarheid. Die. Bijvoorbeeld:
— Storing van de fysieke server;
— Storing van de top-of-the-rack-schakelaar;
— Verstoring van het optische communicatiekanaal tussen datacentra;
— Uitval van het gehele operationele opslagsysteem.
In sommige gevallen worden dreigingsmodellen niet alleen geschreven voor infrastructuurcomponenten, maar ook voor specifieke informatiesystemen of hun componenten, zoals een DBMS-storing met logische vernietiging van de datastructuur.
Alle beslissingen binnen het project om te beschermen tegen een onbeschreven dreiging zijn onnodig.
Regelgevende vereisten
Als de gegevens die worden verwerkt, onderworpen zijn aan speciale regels die zijn vastgesteld door toezichthouders, is informatie over datasets en regels voor verwerking/opslag vereist.
RPO/RTO-doelen
Voor het ontwerpen van elk type bescherming zijn doelindicatoren voor gegevensverlies en doelservicehersteltijd voor elk van de beschreven bedreigingen vereist.
Idealiter zouden RPO en RTO gepaard moeten gaan met kosten van gegevensverlies en downtime per tijdseenheid.
Verdeling in resourcepools
Nadat alle initiële invoerinformatie is verzameld, is de eerste stap het groeperen van datasets en IP in pools op basis van dreigingsmodellen en wettelijke vereisten. Het type verdeling van verschillende pools wordt bepaald - programmatisch op systeemsoftwareniveau of fysiek.
Voorbeelden:
— Het circuit dat persoonsgegevens verwerkt, is fysiek volledig gescheiden van andere systemen;
— Back-ups worden opgeslagen op een apart opslagsysteem.
In dit geval kunnen de pools onvolledig onafhankelijk zijn; er worden bijvoorbeeld twee pools van computerbronnen gedefinieerd (processorvermogen + RAM), die gebruik maken van een enkele gegevensopslagpool en een enkele gegevenstransmissiebronpool.
Rekenkracht
Samenvatting: de verwerkingskrachtvereisten van een gevirtualiseerd datacenter worden gemeten in termen van het aantal virtuele processors (vCPU's) en hun consolidatieverhouding op fysieke processors (pCPU). In dit specifieke geval is 1 pCPU = 1 fysieke processorkern (exclusief Hyper-Threading). Het aantal vCPU's wordt opgeteld over alle gedefinieerde resourcegroepen (die elk hun eigen consolidatiefactor kunnen hebben).
De consolidatiecoëfficiënt voor belaste systemen wordt empirisch verkregen, gebaseerd op bestaande infrastructuur, of door middel van proefinstallaties en belastingtests. Voor onbelaste systemen wordt gebruik gemaakt van ‘best practice’. Concreet noemt VMware de gemiddelde verhouding 8:1.
Оперативная память
De totale RAM-vereiste wordt verkregen door eenvoudige optelling. Het gebruik van RAM-overabonnement wordt niet aanbevolen.
Opslagbronnen
Opslagvereisten worden verkregen door eenvoudigweg alle pools op te tellen op basis van capaciteit en prestaties.
Prestatievereisten worden uitgedrukt in IOPS gecombineerd met een gemiddelde lees/schrijfverhouding en indien nodig een maximale responslatentie.
Quality of Service (QoS)-vereisten voor specifieke pools of systemen moeten afzonderlijk worden gespecificeerd.
Gegevensnetwerkbronnen
De datanetwerkvereisten worden verkregen door eenvoudigweg alle bandbreedtepools op te tellen.
Quality of Service (QoS) en latentie (RTT) vereisten voor specifieke pools of systemen moeten afzonderlijk worden gespecificeerd.
Als onderdeel van de vereisten voor datanetwerkbronnen worden ook vereisten voor isolatie en/of encryptie van netwerkverkeer en voorkeursmechanismen (802.1q, IPSec, etc.) aangegeven.
Architectuur selectie
Deze gids bespreekt geen andere keuze dan x86-architectuur en 100% servervirtualisatie. Daarom komt de keuze voor de architectuur van het computersubsysteem neer op de keuze van het servervirtualisatieplatform, de servervormfactor en de algemene serverconfiguratievereisten.
Het belangrijkste keuzepunt is de zekerheid van het gebruik van een klassieke benadering met scheiding van functies voor het verwerken, opslaan en verzenden van gegevens, of een convergente benadering.
klassieke architectuur omvat het gebruik van intelligente externe subsystemen voor het opslaan en verzenden van gegevens, terwijl servers alleen verwerkingskracht en RAM bijdragen aan de gemeenschappelijke verzameling fysieke bronnen. In extreme gevallen worden servers volledig anoniem en hebben ze niet alleen hun eigen schijven, maar zelfs geen systeemidentificatie. In dit geval wordt het besturingssysteem of de hypervisor geladen vanaf ingebouwde flashmedia of vanaf een extern gegevensopslagsysteem (opstarten vanaf SAN).
Binnen het raamwerk van de klassieke architectuur wordt de keuze tussen blades en racks voornamelijk gemaakt op basis van de volgende principes:
— Kosteneffectief (gemiddeld zijn rackgemonteerde servers goedkoper);
— Computerdichtheid (hoger voor blades);
— Energieverbruik en warmteafvoer (lamellen hebben een hogere specifieke eenheid per eenheid);
— Schaalbaarheid en beheersbaarheid (blades vereisen over het algemeen minder inspanning voor grote installaties);
- Gebruik van uitbreidingskaarten (zeer beperkte keuze voor blades).
Convergente architectuur (ook gekend als hypergeconvergeerd) omvat het combineren van de functies van gegevensverwerking en -opslag, wat leidt tot het gebruik van lokale serverschijven en, als gevolg daarvan, het verlaten van de klassieke blade-vormfactor. Voor geconvergeerde systemen worden rackservers of clustersystemen gebruikt, waarbij meerdere bladeservers en lokale schijven in één geval worden gecombineerd.
CPU/geheugen
Om de configuratie correct te berekenen, moet u het type belasting voor de omgeving of elk van de onafhankelijke clusters begrijpen.
CPU-gebonden – een omgeving die qua prestaties beperkt is door processorkracht. Het toevoegen van RAM verandert niets aan de prestaties (aantal VM's per server).
geheugen gebonden – omgeving beperkt door RAM. Met meer RAM op de server kunt u meer VM's op de server draaien.
GB / MHz (GB / pCPU) – de gemiddelde verhouding tussen het RAM-verbruik en het processorvermogen door deze specifieke belasting. Kan worden gebruikt om de benodigde hoeveelheid geheugen voor een bepaalde prestatie te berekenen en omgekeerd.
Berekening van de serverconfiguratie
Eerst moet u alle soorten belasting bepalen en beslissen of u verschillende computerpools wilt combineren of verdelen in verschillende clusters.
Vervolgens wordt voor elk van de gedefinieerde clusters de GB/MHz verhouding bepaald bij een vooraf bekende belasting. Als de belasting niet vooraf bekend is, maar er wel een globaal inzicht is in het niveau van het energieverbruik van de processor, kunt u standaard vCPU:pCPU-verhoudingen gebruiken om poolvereisten om te zetten in fysieke vereisten.
Deel voor elk cluster de som van de vCPU-poolvereisten door de coëfficiënt:
vCPUsum / vCPU:pCPU = pCPUsum – vereist aantal fysieke eenheden. kernen
pCPUsum / 1.25 = pCPUht – aantal cores aangepast voor Hyper-Threading
Laten we aannemen dat het nodig is om een cluster met 190 cores / 3.5 TB RAM te berekenen. Tegelijkertijd accepteren we een beoogde belasting van 50% processorkracht en 75% RAM.
pCPU
190
CPU-gebruik
50%
Mem
3500
Mem-hulpprogramma
75%
Stopcontact
Kern
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
In dit geval gebruiken we altijd de afronding naar boven op het dichtstbijzijnde gehele getal (=ROUNDUP(A1;0)).
Uit de tabel wordt duidelijk dat verschillende serverconfiguraties in evenwicht zijn voor de doelindicatoren:
— 26 servers 2*6c / 192 GB
— 19 servers 2*10c / 256 GB
— 10 servers 2*18c / 512 GB
De keuze voor deze configuraties moet vervolgens worden gemaakt op basis van aanvullende factoren, zoals het thermische pakket en de beschikbare koeling, reeds gebruikte servers of de kosten.
Kenmerken van het kiezen van een serverconfiguratie
Brede VM's. Als het nodig is om brede VM's te hosten (vergelijkbaar met 1 NUMA-knooppunt of meer), wordt aanbevolen om indien mogelijk een server te selecteren met een configuratie die het mogelijk maakt dat dergelijke VM's binnen het NUMA-knooppunt blijven. Bij een groot aantal brede VM's bestaat het gevaar van fragmentatie van clusterbronnen, en in dit geval worden servers geselecteerd waarmee brede VM's zo dicht mogelijk kunnen worden geplaatst.
Domeingrootte met enkele fout.
De keuze van de servergrootte is ook gebaseerd op het principe van het minimaliseren van het enkele storingsdomein. Bijvoorbeeld bij het kiezen tussen:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
Als alle overige omstandigheden gelijk blijven, moet u de tweede optie kiezen, aangezien wanneer een server uitvalt (of wordt onderhouden), niet 33% van de clusterbronnen verloren gaat, maar 17%. Op dezelfde manier wordt het aantal VM’s en IS’s dat door het ongeval wordt getroffen gehalveerd.
Berekening van klassieke opslagsystemen op basis van prestaties
Klassieke opslagsystemen worden altijd berekend op basis van het worst case scenario, waarbij de invloed van de operationele cache en optimalisatie van de bedrijfsvoering buiten beschouwing wordt gelaten.
Als basisprestatie-indicatoren nemen we mechanische prestaties van de schijf (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS
Vervolgens wordt het aantal schijven in de schijvenpool berekend met behulp van de volgende formule: = TotaalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPS-schijf. Waar:
- TotaalIOPS – totale vereiste prestaties in IOPS van de schijvenpool
- RW – percentage leesbewerkingen
- RAID-pen – RAID-boete voor het geselecteerde RAID-niveau
Lees hier meer over Device RAID en RAID Penalty - и и
Op basis van het resulterende aantal schijven worden mogelijke opties berekend die voldoen aan de vereisten voor opslagcapaciteit, inclusief opties met opslag op meerdere niveaus.
De berekening van systemen die SSD als opslaglaag gebruiken, wordt afzonderlijk beschouwd.
Kenmerken van rekensystemen met Flash Cache
Flash-cache – een algemene naam voor alle eigen technologieën voor het gebruik van flash-geheugen als cache op het tweede niveau. Bij gebruik van een flash-cache wordt het opslagsysteem doorgaans berekend op een constante belasting van magnetische schijven, terwijl de piek wordt opgevangen door de cache.
In dit geval is het noodzakelijk om het belastingsprofiel en de mate van lokalisatie van toegang tot blokken met opslagvolumes te begrijpen. Flash-cache is een technologie voor workloads met sterk gelokaliseerde queries, en is praktisch niet toepasbaar voor uniform geladen volumes (zoals voor analysesystemen).
Berekening van hybride systemen uit het lage en middensegment
Hybride systemen uit de lagere en middenklasse maken gebruik van opslag op meerdere niveaus, waarbij gegevens volgens een schema tussen niveaus worden verplaatst. Tegelijkertijd is de grootte van het opslagblok met meerdere niveaus voor de beste modellen 256 MB. Deze kenmerken laten ons niet toe om gelaagde opslagtechnologie te beschouwen als een technologie voor het verhogen van de productiviteit, zoals veel mensen ten onrechte denken. Opslag op meerdere niveaus in systemen uit de lage en middenklasse is een technologie voor het optimaliseren van de opslagkosten voor systemen met uitgesproken ongelijkmatige ladingen.
Bij gelaagde opslag worden eerst de prestaties van de bovenste laag berekend, terwijl wordt aangenomen dat de onderste opslaglaag alleen bijdraagt aan de ontbrekende opslagcapaciteit. Voor een hybride systeem met meerdere lagen is het verplicht om flash-cachetechnologie te gebruiken voor de pool met meerdere lagen om de prestatievermindering door plotseling verhitte gegevens van het lagere niveau te compenseren.
Een SSD gebruiken in een gelaagde schijvenpool
Het gebruik van SSD's in een schijvenpool met meerdere niveaus kent variaties, afhankelijk van de specifieke implementatie van flash-cache-algoritmen door een bepaalde fabrikant.
De algemene praktijk van het opslagbeleid voor een schijvenpool met een SSD-niveau is SSD eerst.
Alleen-lezen Flash-cache. Voor een alleen-lezen flashcache wordt de opslaglaag op de SSD geleverd met aanzienlijke lokalisatie van schrijfbewerkingen, ongeacht de cache.
Flash-cache lezen/schrijven. In het geval van flash-cache wordt de schrijfcachegrootte eerst ingesteld op de maximale cachegrootte, en verschijnt de SSD-opslaglaag alleen wanneer de cachegrootte onvoldoende is om de gehele gelokaliseerde werklast te bedienen.
SSD- en cacheprestatieberekeningen worden telkens gemaakt op basis van de aanbevelingen van de fabrikant, maar altijd voor het worst case scenario.
Bron: www.habr.com