Redigera

Dela via

Azure Local-arkitektur med tre noder för lagring utan växel

Azure Stack HCI
Azure Arc
Azure Key Vault
Azure Blob Storage
Azure Monitor
Microsoft Defender for Cloud

Den här artikeln är en del av en serie som bygger på referensarkitekturen Azure Local-baslinje. För att effektivt distribuera Azure Local med hjälp av en växellös lagring med tre noder design är det viktigt att förstå baslinjearkitekturen. Den här processen omfattar att bekanta dig med alternativen för klusterdesign för de fysiska noder som levererar lokala funktioner för beräkning, lagring och nätverk. Den här kunskapen hjälper dig att identifiera nödvändiga ändringar för en lyckad distribution. Vägledningen i den här artikeln gäller även för en växellös lagring med två noder distribution och gör nödvändiga justeringar för fall där antalet fysiska noder minskar från tre till två.

Den växellösa nätverksdesignen för lagring tar bort kravet på nätverksväxlar för lagringsklass för att ansluta de nätverkskortportar som används för lagringstrafik. Noder ansluts i stället direkt med hjälp av ethernet-kablar mellan länkar. Den här konfigurationen används ofta i detaljhandels-, tillverknings- eller fjärrkontorsscenarier. Den här konfigurationen är också lämplig för mindre gränsanvändningsfall som inte har eller kräver omfattande datacenternätverksväxlar för lagringsreplikeringstrafik.

Den här referensarkitekturen ger arbetsbelastningsoberoende vägledning och rekommendationer för att konfigurera Azure Local som en flexibel infrastrukturplattform för att distribuera och hantera virtualiserade arbetsbelastningar. Mer information om arbetsbelastningsarkitekturmönster som är optimerade för att köras på Azure Local finns i innehållet som finns under Lokala Azure-arbetsbelastningar navigeringsmenyn.

Den här arkitekturen är en startpunkt för en lokal Azure-instans med tre noder som använder en nätverksdesign utan lagring. Arbetsbelastningsprogram som distribueras på en lokal Azure-instans bör vara väldefinierade. Den här metoden omfattar distribution av flera instanser för hög tillgänglighet för kritiska arbetsbelastningstjänster och implementering av lämpliga BCDR-kontroller (affärskontinuitet och haveriberedskap), till exempel regelbundna säkerhetskopieringar och redundansfunktioner för haveriberedskap. För att fokusera på HCI-infrastrukturplattformen utesluts dessa arbetsbelastningsdesignaspekter avsiktligt från den här artikeln. Mer information om riktlinjer och rekommendationer för de fem grundpelarna i Azure Well-Architected Framework finns i tjänstguiden Azure Local Well-Architected Framework.

Artikellayout

Arkitektur Designbeslut Well-Architected Framework-metod
▪ Arkitekturdiagram
▪ Potentiella användningsfall
▪ Distribuera det här scenariot
▪ designval för kluster
▪ Nätverk
▪ Kostnadsoptimering
▪ Prestandaeffektivitet

Dricks

GitHub-logotypen Den här referensimplementeringen beskriver hur du distribuerar en azure lokal lösning med tre noder med hjälp av en ARM-mall och parameterfil.

Arkitektur

diagram som visar en Lokal Azure-instans med tre noder som använder en växellös lagringsarkitektur och har dubbla ToR-växlar för extern anslutning.

Mer information om dessa resurser finns i Relaterade resurser.

Potentiella användningsfall

Använd den här designen och designerna som beskrivs i referensarkitektur för Azure Local-baslinjen för att uppfylla följande krav för användningsfall:

  • Distribuera och hantera arbetsbelastningar med hög tillgänglighet (HA) virtualiserade eller containerbaserade gränsarbetsbelastningar som distribueras på en enda plats för att göra det möjligt för affärskritiska program och tjänster att fungera på ett motståndskraftigt, kostnadseffektivt och skalbart sätt.

  • Den växellösa nätverksdesignen för lagring tar bort kravet på att distribuera nätverksväxlar för lagringsklass för att ansluta de nätverkskortportar som används för lagringstrafiken.

  • Du kan använda den växellösa nätverksdesignen för lagring för att minska kostnaderna för anskaffning och konfiguration av lagringsklassnätverksväxlar för lagringstrafik, men det ökar antalet nätverkskortportar som krävs i de fysiska noderna.

Arkitekturkomponenter

Arkitekturresurserna förblir i huvudsak oförändrade från referensarkitekturen för baslinjen. Mer information finns i plattformsresurser och plattformsstödresurser används för lokala Azure-distributioner.

Designval för kluster

När du fastställer alternativen för klusterdesign läser du referensarkitekturen för -baslinjen. Använd dessa insikter och Azure Local Sizer Tool för att skala en lokal Azure-instans enligt arbetsbelastningskraven.

När du använder den växellösa lagringsdesignen är det viktigt att komma ihåg att ett kluster med tre noder är den maximala storlek som stöds. Den här begränsningen är en viktig faktor för dina val av klusterdesign eftersom du måste se till att arbetsbelastningens kapacitetskrav inte överskrider de fysiska kapacitetsfunktionerna i specifikationerna för klustret med tre noder. Eftersom du inte kan utföra en gest med tilläggsnoder för att expandera ett lagringsväxellöst kluster utöver tre noder är det mycket viktigt att förstå kraven på arbetsbelastningskapacitet i förväg och planera för framtida tillväxt. På så sätt kan du se till att din arbetsbelastning inte överskrider lagrings- och beräkningskapaciteten under den förväntade livslängden för maskinvaran för den lokala Azure-instansen.

Försiktighet

Den maximala klusterstorleken som stöds för den växellösa nätverksarkitekturen för lagring är tre fysiska noder. Tänk på den här gränsen under klusterdesignfasen, till exempel att inkludera kraven på nuvarande och framtida tillväxtkapacitet för din arbetsbelastning.

Nätverksdesign

Nätverksdesign syftar på den övergripande ordningen för fysiska och logiska komponenter i nätverket. I en växellös konfiguration med tre noder för Azure Local är tre fysiska noder direkt anslutna utan att använda en extern växel för lagringstrafik. Dessa direktlänkade Ethernet-anslutningar förenklar nätverksdesignen genom att minska komplexiteten eftersom det inte finns något krav på att definiera eller tillämpa lagringskvalitet för tjänst- och prioriteringskonfigurationer på växlarna. De tekniker som ligger till grund för förlustfri RDMA-kommunikation, till exempel explicit överbelastningsmeddelande (ECN), prioritetsflödeskontroll (PFC) eller tjänstkvalitet (QoS) som krävs för RoCE v2 och iWARP, behövs inte. Den här konfigurationen stöder dock högst tre noder, vilket innebär att du inte kan skala klustret genom att lägga till fler noder efter distributionen.

Not

Den här växellösa arkitekturen för lagring med tre noder kräver sex portar för nätverkskort som tillhandahåller redundanta länkar för alla nätverksinsikter. Ta hänsyn till detta om du planerar att använda en liten formfaktormaskinvara SKU, eller om det finns begränsat fysiskt utrymme i serverchassit för extra nätverkskort. Mer information finns i din partner för maskinvarutillverkare.

Topologi för fysiskt nätverk

Den fysiska nätverkstopologin visar de faktiska fysiska anslutningarna mellan noder och nätverkskomponenter. Anslutningarna mellan noder och nätverkskomponenter för en växellös Azure Local-distribution med tre noder är:

  • Tre noder (eller servrar):

    • Varje nod är en fysisk server som körs på Azure Stack HCI OS.

    • Varje nod kräver totalt sex nätverkskortportar: fyra RDMA-kompatibla portar för lagring och två portar för hantering och beräkning.

  • Lagringstrafik:

    • Var och en av de tre noderna är sammankopplade via dubbla dedikerade fysiska nätverkskortportar för lagring. Följande diagram illustrerar den här processen.

    • Lagringsnätverkskortportarna ansluter direkt till varje nod med hjälp av Ethernet-kablar för att skapa en fullständig nätnätverksarkitektur för lagringstrafiken.

    • Den här designen ger länkredundans, dedikerad låg svarstid, hög bandbredd och högt dataflöde.

    • Noder i HCI-klustret kommunicerar direkt via dessa länkar för att hantera lagringsreplikeringstrafik, även kallad öst-västlig trafik.

    • Den här direktkommunikationen eliminerar behovet av extra nätverksväxlingsportar för lagring och tar bort kravet på att tillämpa QoS- eller PFC-konfiguration för SMB Direct- eller RDMA-trafik på nätverksväxlarna.

    • Kontakta maskinvarutillverkarens partner eller NIC-leverantör (Network Interface Card) om du vill ha några rekommenderade operativsystemdrivrutiner, versioner av inbyggd programvara eller inställningar för inbyggd programvara för nätverkskonfiguration med växellös anslutning.

  • Dubbla ToR-växlar (Top-of-Rack):

    • Den här konfigurationen är växellös för lagringstrafik men kräver fortfarande ToR-växlar för den externa anslutningen. Den här anslutningen kallas nord-syd-trafik och omfattar avsikten för klusterhantering hantering och arbetsbelastningen beräkning avsikter.

    • Överlänkarna till växlarna från varje nod använder två nätverkskortportar. Ethernet-kablar ansluter dessa portar, en till varje ToR-växel, för att tillhandahålla länkredundans.

    • Vi rekommenderar att du använder dubbla ToR-växlar för att tillhandahålla redundans för serviceåtgärder och belastningsutjämning för extern kommunikation.

  • Extern anslutning:

    • De dubbla ToR-växlarna ansluter till det externa nätverket, till exempel det interna företagsnätverket, och använder din gränsnätverksenhet, till exempel en brandvägg eller router, för att ge åtkomst till de utgående URL:er som krävs.

    • De två ToR-växlarna hanterar nord-syd-trafiken för Azure Local-instansen, inklusive trafik som rör hanterings- och beräkningssyften.

      Diagram över en lokal Azure-instans med tre noder med växellös lagringsarkitektur och dubbla ToR-växlar för extern anslutning.

Topologi för logiskt nätverk

Topologin för det logiska nätverket ger en översikt över hur nätverksdata flödar mellan enheter, oavsett deras fysiska anslutningar. I följande lista sammanfattas den logiska konfigurationen för en växellös Azure Local-instans med tre noder:

  • Dubbla ToR-växlar:

    • Innan klusterdistributionen måste de två ToR-nätverksväxlarna konfigureras med nödvändiga VLAN-ID:n och MTU-inställningar (maximum transmission unit) för hanterings- och beräkningsportarna. Mer information finns i fysiska nätverkskrav eller be din SWITCH-maskinvaruleverantör eller systemintegratörspartner (SI) om hjälp.

  • Azure Local tillämpar nätverksautomatisering och avsiktsbaserad nätverkskonfiguration med hjälp av Network ATC-tjänsten.

    • Nätverks-ATC är utformat för att säkerställa optimal nätverkskonfiguration och trafikflöde med hjälp av nätverkstrafik avsikter. Nätverks-ATC definierar vilka portar för fysiskt nätverkskort som används för de olika nätverkstrafikavsikterna (eller typerna), till exempel för klustret hantering, arbetsbelastning beräkningoch kluster lagring avsikter.

    • Avsiktsbaserade principer förenklar kraven på nätverkskonfiguration genom att automatisera nodnätverkskonfigurationen baserat på parameterindata som anges som en del av distributionsprocessen för azure-lokala moln.

  • Extern kommunikation:

    • När noderna eller arbetsbelastningen behöver kommunicera externt genom att komma åt företagets LAN, Internet eller en annan tjänst dirigerar de med de dubbla ToR-växlarna. Den här processen beskrivs i föregående fysisk nätverkstopologi avsnittet.

    • När de två ToR-växlarna fungerar som Layer 3-enheter hanterar de routning och ger anslutning bortom klustret till gränsenheten, till exempel din brandvägg eller router.

    • Avsikten för hanteringsnätverket använder det virtuella gränssnittet Converged Switch Embedded Teaming (SET), som gör att klusterhanterings-IP-adressen och kontrollplansresurserna kan kommunicera externt.

    • För avsikten med beräkningsnätverket kan du skapa ett eller flera logiska nätverk i Azure med specifika VLAN-ID:n för din miljö. Arbetsbelastningsresurserna, till exempel virtuella datorer, använder dessa ID:n för att ge åtkomst till det fysiska nätverket. De logiska nätverken använder de två fysiska nätverkskortportarna som konvergeras med set för beräknings- och hanteringssyften.

  • Lagringstrafik:

    • Noderna kommunicerar direkt med varandra för lagringstrafik med hjälp av de fyra direktanslutna Ethernet-portarna per nod, som använder sex separata icke-utfällbara (eller Layer 2) nätverk för lagringstrafiken.

    • Det finns ingen standardgateway konfigurerad på de fyra portarna för lagringsavsiktsnätverkskort i Azure Stack HCI-operativsystemet.

    • Varje nod har åtkomst till S2D-funktioner i klustret, till exempel fysiska fjärrdiskar som används i lagringspoolen, virtuella diskar och volymer. Åtkomst till dessa funktioner underlättas via SMB Direct RDMA-protokollet över de två dedikerade lagringsnätverkskortportarna som är tillgängliga i varje nod. SMB Multichannel används för återhämtning.

    • Den här konfigurationen säkerställer tillräcklig dataöverföringshastighet för lagringsrelaterade åtgärder, till exempel att upprätthålla konsekventa kopior av data för speglade volymer.

      diagram som visar den logiska nätverkstopologin för en lokal Azure-instans med tre noder.

KRAV för IP-adress

För att distribuera en växellös konfiguration med tre noder för Azure Local med dubbla länkar för lagringssammankopplingarna kräver klusterinfrastrukturplattformen att du allokerar minst 20 x IP-adresser. Fler IP-adresser krävs om du använder en VM-installation som tillhandahålls av maskinvarutillverkarens partner, eller om du använder mikrosegmentering eller programvarudefinierat nätverk (SDN). Mer information finns i Granska IP-kraven för lagringsreferensmönster med tre noder för Azure Local.

När du utformar och planerar IP-adresskrav för Azure Local ska du komma ihåg att ta hänsyn till ytterligare IP-adresser eller nätverksintervall som behövs för din arbetsbelastning utöver de som krävs för Azure Local-instansen och infrastrukturkomponenterna. Om du planerar att använda Azure Kubernetes Services (AKS) på Azure Local kan du läsa AKS som aktiveras av Azure Arc-nätverkskraven.

Överväganden

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Viktig

Granska de Well-Architected Framework-överväganden som beskrivs i referensarkitekturen Azure Local-baslinje.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

Kostnadsoptimeringsöverväganden omfattar:

  • Växellösa kluster kopplas samman jämfört med växelbaserade klusteranslutningar. Den växellösa anslutningstopologin består av anslutningar mellan dubbla portar eller redundantaRDMA-kompatibla nätverkskortportar i varje nod för att bilda ett fullständigt nät. Varje nod har två direkta anslutningar till varannan nod. Även om den här implementeringen är enkel stöds den bara i kluster med två noder eller tre noder. En lokal Azure-instans med fyra eller fler noder kräver att lagring växlas nätverksarkitektur. Du kan använda den här arkitekturen för att lägga till fler noder efter distributionen, till skillnad från den växellösa lagringsdesign som inte stöder åtgärder för tilläggsnoder.

Prestandaeffektivitet

Prestandaeffektivitet är arbetsbelastningens förmåga att skala för att uppfylla användarnas krav på ett effektivt sätt. Mer information finns i Översikt över grundpelare för prestandaeffektivitet.

Prestandaeffektivitetsöverväganden omfattar:

  • Du kan inte öka skalan (eller utföra en tilläggsnodåtgärd) för ett befintligt HCI-kluster med tre noder utan att distribuera om klustret och lägga till extra nätverksfunktioner som nätverksväxlar, portar och kablar för lagringstrafik och de andra nödvändiga noderna. Tre noder är den maximala klusterstorleken som stöds för den växellösa nätverksdesignen för lagring. Ta med den här begränsningen i klusterdesignfasen för att säkerställa att maskinvaran kan stödja framtida kapacitetstillväxt för arbetsbelastningar.

Distribuera det här scenariot

Mer information om hur du utformar, skaffar och distribuerar en lokal Azure-lösning finns i avsnittet Distribuera det här scenariot i referensarkitekturen Azure Local-baslinje.

Använd följande mall för distributionsautomatisering som ett exempel på hur du distribuerar Azure Local med hjälp av den växellösa arkitekturen för lagring med tre noder.

Dricks

GitHub-logotypen Distributionsautomatisering: Den här referensmallen beskriver hur du distribuerar en azure lokal lösning med tre noder med hjälp av en ARM-mall och parameterfil.

Nästa steg

Produktdokumentation:

Produktdokumentation för specifika Azure-tjänster:

Microsoft Learn-moduler: