Azure Stack HCI-workloads plannen

Voltooid

Nadat u hebt gecontroleerd of Azure Stack HCI geschikt is voor het hosten van uw workload, moet u rekening houden met de vereisten van uw infrastructuur, met inbegrip van berekenings-, opslag- en netwerkonderdelen. Deze overwegingen zijn afhankelijk van de workload, dus voor een scenario zoals dat van Contoso, moet u rekening houden met de afzonderlijke prestatievereisten van Microsoft SQL Server en VDI.

Azure Stack HCI plannen

Algemene overwegingen bij de planning voor een Azure Stack HCI-implementatie zijn:

  • Het aantal fysieke servers per cluster. Dit getal moet tussen 1 en 16 zijn.
  • Het aantal foutdomeinen per cluster. Elk knooppunt in een Opslagruimten Direct-cluster is standaard één foutdomein.
  • Het aantal en het type processors per server. De eerste van deze waarden bepaalt het aantal kernen en de laatste bepaalt hun snelheid.
  • De hoeveelheid en het type geheugen per server, inclusief of het PMEM moet worden gebruikt.
  • Schijfprestaties, met inbegrip van de bijbehorende configuratie voor lagen en cache.
  • Het aantal, de typen en de mogelijkheden van uw netwerkadapters.
  • Het Azure-abonnement waarin u uw Azure Stack HCI-implementatie registreert, omdat er lopende kosten gelden voor Azure Stack HCI-clusters, afhankelijk van het type Azure-abonnement.

Het plannen van overwegingen met betrekking tot opslagprestaties en capaciteit zijn onder andere:

  • Het aantal en de typen schijven, waaronder HDD's, SSD's en NVMe.
  • Tolerantieniveaus van Opslagruimten Direct.
  • De configuratie van lagen en opslaan in cache.

Enkele andere netwerkfactoren die u moet overwegen:

  • Of u nu netwerkswitches wilt gebruiken of schakelloos wilt gaan (kleine clusters kunnen een volledig mesh-netwerk gebruiken om servers met elkaar te verbinden zonder switches)
  • Fysieke bekabelingsvereisten voor adapters (geschakeld versus switchloos)
  • De netwerkswitches per cluster en eigendom daarvan

Andere overwegingen zijn van toepassing op stretched clusters, met inbegrip van het aantal servers dat elke site vereist en de modus van de clusterconfiguratie. De twee modi zijn:

  • Actief-passieve modus, waarin een aangewezen primaire site unidirectioneel repliceert naar een andere site die noodherstelmogelijkheden biedt.
  • Actief-actiefmodus, waarin twee sites hun respectieve volumes unidirectioneel naar elkaar repliceren, waardoor failovermogelijkheden worden geboden als een van beide sites uitvalt. De modus actief-actief helpt de kosten voor bedrijfscontinuïteit te minimaliseren omdat u geen toegewezen site voor herstel na noodgevallen nodig hebt.

Uw beoogde workloads zijn van invloed op al deze factoren. De eerder besproken use-cases zijn een basis voor het identificeren van een optimale Azure Stack HCI-hardwareconfiguratie. De Azure Stack HCI-catalogus bevat een lijst met alle Azure Stack HCI-oplossingen die door andere leveranciers worden aangeboden en die zijn goedgekeurd door Microsoft.

Azure Stack HCI-hostopslag plannen

Eenvoudig gezegd moet het plannen van Azure Stack HCI-hostopslag het optimale evenwicht tussen tolerantie, capaciteit en prestaties van Opslagruimten Direct identificeren. Er is echter een uitdaging; het maximaliseren van een van deze kenmerken heeft doorgaans een negatieve invloed op ten minste één van de andere twee. Het verhogen van de tolerantie vermindert bijvoorbeeld de bruikbare capaciteit, hoewel de resulterende prestaties kunnen variëren afhankelijk van het tolerantietype.

Stations

Opslagruimten Direct ondersteunt harde schijven (HDD's), SSD's (solid-state drive) en NVMe-schijven (Non-Volatile Memory Express), met inbegrip van PMEM. De keuze van het type station is rechtstreeks van invloed op de opslagprestaties vanwege verschillen in prestatiekenmerken tussen elk type en het cache-mechanisme.

Cache van Opslagruimten Direct

Over het algemeen wijst Opslagruimten Direct stations toe aan een van de twee categorieën op basis van het stationstype: capaciteit of cache.

  • Capaciteitsstations bieden de onbewerkte opslag voor het cluster en zijn doorgaans trager en beter dan cachestations.
  • Cachestations worden gebruikt om lees- en schrijfbewerkingen te versnellen naar tragere capaciteitsstations.

In clusters met meerdere typen stations, wijst Opslagruimten Direct automatisch alle snelste typen stations toe aan de cache en gebruikt de resterende stations voor capaciteit. U kunt handmatig in de cache opslaan in scenario's waarin de standaardconfiguratie geen optimale prestaties levert.

Symmetrie van stations

Opslagruimten Direct werkt op de optimale manier wanneer elke server exact hetzelfde aantal en type stations heeft. Over het algemeen moet u uw Opslagruimten Direct-cluster op een zodanige manier configureren dat:

  • Alle servers hebben hetzelfde type station.
  • Alle servers hebben hetzelfde aantal stations per type.
  • Alle stations hebben hetzelfde model en dezelfde firmware-versie.
  • Alle stations van hetzelfde type hebben dezelfde grootte.

Het is goed voor het aantal stations dat tijdelijk verschilt tijdens storingen of tijdens het toevoegen of verwijderen van stations. Er is ook enige flexibiliteit met de stationsmodellen en grootten; U kunt bijvoorbeeld een mislukt station niet vervangen door hetzelfde model. Als de stations echter te verschillend zijn, kunt u eindigen met gestrande capaciteit of ongelijke prestaties.

Cluster- en poolquorum

In een failovercluster is het termenquorum het aantal clusteronderdelen dat beschikbaar moet zijn om dat cluster online te kunnen blijven. Deze onderdelen kunnen de clusterknooppunten omvatten en, optioneel, een witness. De term witness geeft een resource aan die uitsluitend is toegewezen voor het tot stand brengen en onderhouden van quorum.

Met Opslagruimten Direct zijn er twee verschillende quorummechanismen:

  • Clusterquorum, dat werkt op het clusterniveau en is gebaseerd op stemmen van knooppunten en een witness. Opslagruimten Direct biedt geen ondersteuning voor Schijfwitness, waarbij Cloud Witness en de bestandssharewitness worden verlaten als de twee haalbare opties.
  • Pool-quorum, dat werkt op het niveau van de opslaggroep, en is gebaseerd op stemmen van knooppunten en opslagtolerantie. Als u de quorumconfiguratie van een groep wilt optimaliseren tijdens de implementatie van Opslagruimten Direct, moet u ervoor zorgen dat er een overeenkomende opslagconfiguratie in elk clusterknooppunt is.

Volumes

Met Opslagruimten Direct kunt u met volumes stations in de opslaggroep groeperen om de optimale combinatie van fouttolerantie, schaalbaarheid en prestatievereisten te verkrijgen. Bij het plannen van Opslagruimten Direct-volumes moet u rekening houden met het volgende:

  • Aantal volumes per cluster: Om de opslagprestaties te optimaliseren, moet het aantal volumes per server een veelvoud zijn van het aantal servers per cluster.

  • Bestandssysteem: Het wordt aangeraden om reFS (Resilient File System) te gebruiken voor Opslagruimten Direct-volumes.

    Als voor uw workload een functie is vereist die nog niet door ReFS wordt ondersteund, kunt u in plaats daarvan NTFS-volumes gebruiken voor die workload (u kunt ReFS- en NTFS-volumes in hetzelfde cluster hebben).

  • Volumegrootte: de grootte van een volume op een Azure Stack HCI-cluster mag niet groter zijn dan 64 TB.

  • Reservecapaciteit: Als u het gebruik van schijfruimte wilt optimaliseren, kunt u het equivalent van één capaciteitsstation per server opzij zetten, maximaal vier stations per cluster.

  • Tolerantietype: Volumetolerantie is het primaire mechanisme waarmee gegevens in de opslaggroep worden beschermd tegen hardwareproblemen, zoals schijf- of serverfouten. De keuze van het tolerantietype is afhankelijk van de workload.

    • Gebruik spiegeling voor volumes die de prestaties moeten maximaliseren voor workloads met strikte latentievereisten of die grote hoeveelheden gemengde willekeurige IOPS uitvoeren, zoals Microsoft SQL Server-databases of prestatiegevoelige Hyper-V-VM's.
    • Gebruik dubbele pariteit voor volumes die de capaciteitsefficiëntie moeten maximaliseren en voor workloads met minder veeleisende I/O-vereisten, zoals bestandsservers of Virtual Desktop Infrastructure (VDI).
    • Gebruik pariteit met versnelling op basis van spiegeling om de prestaties en capaciteit te verdelen voor workloads die grote, sequentiële schrijfbewerkingen uitvoeren, zoals back-upsoftware.
    • Gebruik geneste tolerantie op clusters met twee servers waarop productieworkloads worden uitgevoerd om tolerantie toe te voegen aan een stationsfout die optreedt terwijl één server offline is. U kunt geneste spiegeling of pariteit met versnelling op basis van spiegeling gebruiken, afhankelijk van uw workload.

Azure Stack HCI-hostnetwerken plannen

In de eenvoudigste termen omvat het plannen van hostnetwerken in Azure Stack HCI het identificeren van de adapter- en fysieke switchconfiguratie die u gaat gebruiken. Daarnaast zijn overwegingen voor stretched clusters onder andere de netwerkpoortvereisten en -latentie tussen sites.

Overwegingen voor fysiek netwerk

Klanten moeten er minimaal voor zorgen dat:

  • Ze gebruiken een compatibele Azure Stack HCI-switch.
  • Ze kennen de IP-subnetten en VLAN's voor beheer, opslag en rekenverkeer.

Andere netwerkvereisten, zoals het Data Center Bridging, kunnen ook nodig zijn om te integreren in uw netwerkvereisten voor uw oplossing (meer hierover later).

Network ATC

Netwerk-ATC is een nieuwe service die helpt bij het implementeren en onderhouden van de hostnetwerkconfiguratie en is alleen beschikbaar in Azure Stack HCI. Netwerk-ATC biedt de volgende voordelen:

  • Vereenvoudigt de implementatie van hostnetwerken in het hele cluster
  • Implementeert de meest recente best practices die door Microsoft zijn gevalideerd
  • Houdt alle hostnetwerkconfiguraties gesynchroniseerd binnen het cluster
  • Onjuiste configuraties van beheerders herstellen om configuratiedrift te voorkomen
  • Stroomlijnt de clusteruitbreiding, waardoor nieuwe servers precies zoals de andere servers worden geïmplementeerd

Met Network ATC vermindert u de hostconfiguratie tot één opdracht of gebruikersinterface (via Windows Beheer Center).

RDMA

RDMA is een belangrijke netwerktechnologie die communicatie met hoge doorvoer en lage latentie biedt waarmee netwerkverkeer van de CPU's wordt offload, waardoor cpu-tijd wordt vrijgemaakt voor actieve workloads. Azure Stack HCI-configuraties kunnen gebruikmaken van een van de twee algemene RDMA-technologieën:

  • (Aanbevolen) Internet-Wide Area RDMA Protocol (iWarp) via TCP/IP, met TCP die stroombeheer en congestiebeheer biedt
  • RDMA via Converged Ethernet (RoCE) via UDP/IP, met Data Center Bridging (DCB)

Als u niet zeker weet welke technologie u moet gebruiken, raden we u aan iWARP te gebruiken, omdat het eenvoudiger is om te configureren.

Plannen voor software-gedefinieerde netwerken

Azure Stack HCI bevat SDN (Software Defined Networking), dat netwerkservices kan leveren op uw bestaande VLAN-infrastructuur (Virtual Local Area Network), en uw netwerken virtualiseert en netwerkservices biedt op de gevirtualiseerde netwerken.

SDN-scenario's voor traditionele VLAN-netwerken:

  • Microsegmentatie: klanten kunnen ACL-beleid (Security Access Control List) toepassen om hun workloads te beschermen tegen externe en interne aanvallen.
  • Quality of Service (QoS): klanten kunnen QoS-beleid toepassen om te voorkomen dat één toepassings- of workload-VM de volledige bandbreedte van hun HCI-clusterknooppunten opspoort.
  • SLB (Software Load Balancing): klanten kunnen SLB implementeren om klantnetwerkverkeer gelijkmatig over meerdere resources te verdelen. Met SLB kunnen meerdere servers dezelfde workload hosten, waardoor hoge beschikbaarheid en schaalbaarheid mogelijk zijn. Het biedt ook NAT-services (Network Address Translation).

SDN-scenario's voor gevirtualiseerde netwerken:

  • Netwerkvirtualisatie: klanten kunnen hun eigen IP-netwerken meenemen en workloads inrichten op deze netwerken.
  • Microsegmentatie: klanten kunnen ACL-beleid (Security Access Control List) toepassen om hun workloads te beschermen tegen externe en interne aanvallen.
  • Quality of Service (QoS): klanten kunnen QoS-beleid toepassen om te voorkomen dat één toepassing of workload-VM de volledige bandbreedte van hun cluster verbruikt.
  • Software Load Balancing (SLB):klanten kunnen Software Load Balancing implementeren om klantnetwerkverkeer gelijkmatig over meerdere resources te verdelen. Met softwaretaakverdeling kunnen meerdere servers dezelfde workload hosten, waardoor hoge beschikbaarheid en schaalbaarheid mogelijk zijn. Het biedt ook NAT-services (Network Address Translation).
  • Virtuele apparaten: klanten kunnen hun eigen virtuele apparaten van derden gebruiken, zoals firewalls, inbraakdetectieapparaten, load balancers en meer, en deze koppelen aan de gevirtualiseerde netwerken.
  • Verbinding maken iviteit van externe netwerken: klanten kunnen SDN-gateways gebruiken om connectiviteit te bieden van hun gevirtualiseerde netwerken naar externe netwerken. SDN biedt connectiviteit met on-premises netwerken via internet of via toegewezen netwerken. Het biedt ook connectiviteit tussen gevirtualiseerde netwerken en fysieke netwerken op dezelfde locatie.

SDN heeft drie infrastructuuronderdelen en u kunt ervoor kiezen om sommige of allemaal te implementeren op basis van uw behoeften.

  • Netwerkcontroller: dit is het primaire onderdeel van SDN. Netwerkcontroller is het gecentraliseerde besturingsvlak voor SDN. Het ontvangt beleid van het beheervlak en configureert het gegevensvlak met het beleid. Met netwerkcontroller kunnen klanten netwerkservices zoals microsegmentatie en QoS beheren voor traditionele VLAN-netwerken en gevirtualiseerde netwerken.
  • Software Load Balancer (SLB):dit in het infrastructuuronderdeel dat verantwoordelijk is voor het leveren van de taakverdeling en NAT-mogelijkheden voor workloads op traditionele VLAN-netwerken en gevirtualiseerde netwerken.
  • Gateways: dit zijn de infrastructuuronderdelen die verantwoordelijk zijn voor het bieden van connectiviteit tussen virtuele netwerken en externe netwerken.

Test uw kennis

1.

Wat is het minimum aantal servers in een Azure Stack HCI-cluster?

2.

Wat doet Network ATC?