Referensarkitektur för Azure Local-baslinje

Den här baslinjereferensarkitekturen ger arbetsbelastningsoberoende vägledning och rekommendationer för att konfigurera Azure Local, version 23H2, version 2311 och senare infrastruktur för att säkerställa en tillförlitlig plattform som kan distribuera och hantera virtualiserade och containerbaserade arbetsbelastningar med hög tillgänglighet. Den här arkitekturen beskriver resurskomponenterna och alternativen för klusterdesign för de fysiska noder som tillhandahåller lokala funktioner för beräkning, lagring och nätverk. Den beskriver också hur du använder Azure-tjänster för att förenkla och effektivisera den dagliga hanteringen av Azure Local.

Mer information om arbetsbelastningsarkitekturmönster som är optimerade för att köras på Azure Local finns i innehållet i Lokala Azure-arbetsbelastningar navigeringsmenyn.

Den här arkitekturen är en startpunkt för hur du använder nätverksdesignen för lagringsväxlar för att distribuera en lokal Azure-instans med flera noder. De arbetsbelastningsprogram som distribueras på en lokal Azure-instans bör vara väldefinierade. Väldefinierade arbetsbelastningsprogram måste distribueras med flera instanser eller hög tillgänglighet för kritiska arbetsbelastningstjänster och ha lämpliga BCDR-kontroller (affärskontinuitet och haveriberedskap). Dessa BCDR-kontroller omfattar 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

Mer information finns i Relaterade resurser.

Potentiella användningsfall

Vanliga användningsfall för Azure Local är möjligheten att köra arbetsbelastningar med hög tillgänglighet (HA) på lokala platser eller gränsplatser, vilket ger en lösning för att hantera arbetsbelastningskrav. Du kan:

• Tillhandahålla en hybridmolnlösning som distribueras lokalt för att hantera datasuveränitet, reglering och efterlevnad eller svarstidskrav.

• Distribuera och hantera HA-virtualiserade eller containerbaserade gränsarbetsbelastningar som distribueras på en enda plats eller på flera platser. Den här strategin gör det möjligt för affärskritiska program och tjänster att fungera på ett motståndskraftigt, kostnadseffektivt och skalbart sätt.

• Minska den totala ägandekostnaden (TCO) med hjälp av lösningar som är certifierade av Microsoft, molnbaserad distribution, centraliserad hantering samt övervakning och aviseringar.

• Tillhandahålla en centraliserad etableringsfunktion med hjälp av Azure och Azure Arc för att distribuera arbetsbelastningar på flera platser konsekvent och säkert. Verktyg som Azure-portalen, Azure CLI eller IaC-mallar (infrastruktur som kod) använder Kubernetes för containerisering eller traditionell arbetsbelastningsvirtualisering för att skapa automatisering och repeterbarhet.

• Följ strikta krav på säkerhet, efterlevnad och granskning. Azure Local distribueras med en härdad säkerhetsstatus som konfigurerats som standard, eller säker som standard. Azure Local innehåller certifierad maskinvara, säker start, TPM (Trusted Platform Module), virtualiseringsbaserad säkerhet (VBS), Credential Guard och framtvingade Principer för Windows Defender-programkontroll. Den integreras också med moderna molnbaserade säkerhets- och hothanteringstjänster som Microsoft Defender för molnet och Microsoft Sentinel.

Scenarioinformation

Följande avsnitt innehåller mer information om scenarier och potentiella användningsfall för den här referensarkitekturen. De här avsnitten innehåller en lista över affärsfördelar och exempel på resurstyper för arbetsbelastningar som du kan distribuera i Azure Local.

Använda Azure Arc med Azure Local

Azure Local integreras direkt med Azure med hjälp av Azure Arc för att sänka TCO och driftkostnaderna. Azure Local distribueras och hanteras via Azure, vilket ger inbyggd integrering av Azure Arc genom distribution av Azure Arc-resursbryggan komponent. Den här komponenten installeras under HCI-klusterdistributionsprocessen. Azure Local-klusternoder registreras med Azure Arc för servrar som en förutsättning för att initiera den molnbaserade distributionen av klustret. Under distributionen installeras obligatoriska tillägg på varje klusternod, till exempel Livscykelhanteraren, Microsoft Edge-enhetshantering samt telemetri och diagnostik. Du kan använda Azure Monitor och Log Analytics för att övervaka HCI-klustret efter distributionen genom att aktivera Insights för Azure Local. Funktionsuppdateringar för Azure Local släpps regelbundet för att förbättra kundupplevelsen. Uppdateringar styrs och hanteras via Azure Update Manager-.

Du kan distribuera arbetsbelastningsresurser som virtuella Azure Arc-datorer (VM: er), Azure Arc-aktiverade Azure Kubernetes Service (AKS)och Azure Virtual Desktop-sessionsvärdar som använder Azure-portalen genom att välja en anpassad plats för lokal Azure-instans som mål för arbetsbelastningsdistributionen. Dessa komponenter tillhandahåller centraliserad administration, hantering och support. Om du har aktiv Software Assurance på dina befintliga Kärnlicenser för Windows Server Datacenter kan du minska kostnaderna ytterligare genom att tillämpa Azure Hybrid-förmånen på azure-lokala datorer, virtuella Windows Server-datorer och AKS-kluster. Den här optimeringen hjälper dig att effektivt hantera kostnader för dessa tjänster.

Azure- och Azure Arc-integrering utökar funktionerna i azure local virtualiserade och containerbaserade arbetsbelastningar så att de omfattar:

• virtuella Azure Arc-datorer för traditionella program eller tjänster som körs på virtuella datorer på Azure Local.

• AKS på Azure Local för containerbaserade program eller tjänster som drar nytta av att använda Kubernetes som orkestreringsplattform.

• Azure Virtual Desktop för att distribuera dina sessionsvärdar för Azure Virtual Desktop-arbetsbelastningar på Azure Local (lokalt). Du kan använda kontroll- och hanteringsplanet i Azure för att initiera skapandet och konfigurationen av värdpoolen.

• Azure Arc-aktiverade datatjänster för containerbaserad Azure SQL Managed Instance eller en Azure Database for PostgreSQL-server som använder Azure Arc-aktiverad AKS som finns på Azure Local.

• Azure Arc-aktiverat Azure Event Grid-tillägg för Kubernetes för att distribuera Event Grid-koordinatorn och Event Grid-operatorn komponenter. Den här distributionen möjliggör funktioner som Event Grid-ämnen och prenumerationer för händelsebearbetning.

• Azure Arc-aktiverad maskininlärning med ett AKS-kluster som distribueras på Azure Local som beräkningsmål för att köra Azure Machine Learning. Du kan använda den här metoden för att träna eller distribuera maskininlärningsmodeller vid gränsen.

Azure Arc-anslutna arbetsbelastningar ger förbättrad Azure-konsekvens och automatisering för lokala Azure-distributioner, till exempel automatisering av gästoperativsystemkonfiguration med Azure Arc VM-tillägg eller utvärdering av efterlevnad av branschregler eller företagsstandarder via Azure Policy-. Du kan aktivera Azure Policy via Azure-portalen eller IaC-automatisering.

Dra nytta av azure local-standardsäkerhetskonfigurationen

Azure Locals standardsäkerhetskonfiguration ger en djupgående strategi för att förenkla kostnaderna för säkerhet och efterlevnad. Distributionen och hanteringen av IT-tjänster för detaljhandels-, tillverknings- och fjärrkontorsscenarier medför unika säkerhets- och efterlevnadsutmaningar. Att skydda arbetsbelastningar mot interna och externa hot är avgörande i miljöer som har begränsat IT-stöd eller brist på eller dedikerade datacenter. Azure Local har standardsäkerhetshärdning och djupintegrering med Azure-tjänster som hjälper dig att hantera dessa utmaningar.

Azure Local-certifierad maskinvara säkerställer inbyggd säker start, Unified Extensible Firmware Interface (UEFI) och TPM-stöd. Använd dessa tekniker i kombination med VBS- för att skydda dina säkerhetskänsliga arbetsbelastningar. Du kan använda BitLocker-diskkryptering för att kryptera startdiskvolymer och lagringsdirigeringsvolymer i vila. SMB-kryptering (Server Message Block) ger automatisk kryptering av trafik mellan servrar i klustret (i lagringsnätverket) och signering av SMB-trafik mellan klusternoderna och andra system. SMB-kryptering hjälper också till att förhindra reläattacker och underlättar efterlevnad av regelstandarder.

Du kan registrera lokala Azure-datorer i Defender för molnet för att aktivera molnbaserad beteendeanalys, hotidentifiering och reparation, aviseringar och rapportering. Hantera lokala Azure-datorer i Azure Arc så att du kan använda Azure Policy för att utvärdera deras efterlevnad av branschregler och företagsstandarder.

Komponenter

Den här arkitekturen består av fysisk servermaskinvara som du kan använda för att distribuera Lokala Azure-instanser på lokala platser eller gränsplatser. För att förbättra plattformsfunktionerna integreras Azure Local med Azure Arc och andra Azure-tjänster som tillhandahåller stödresurser. Azure Local tillhandahåller en elastisk plattform för att distribuera, hantera och använda användarprogram eller affärssystem. Plattformsresurser och -tjänster beskrivs i följande avsnitt.

Plattformsresurser

Arkitekturen kräver följande obligatoriska resurser och komponenter:

• Azure Local är en lösning för hyperkonvergerad infrastruktur (HCI) som distribueras lokalt eller på gränsplatser med hjälp av fysisk servermaskinvara och nätverksinfrastruktur. Azure Local tillhandahåller en plattform för att distribuera och hantera virtualiserade arbetsbelastningar som virtuella datorer, Kubernetes-kluster och andra tjänster som aktiveras av Azure Arc. Lokala Azure-instanser kan skalas från en distribution med en nod till högst sexton noder med hjälp av verifierade, integrerade eller premiummaskinvarukategorier som tillhandahålls av OEM-partner (Original Equipment Manufacturer).

• Azure Arc är en molnbaserad tjänst som utökar hanteringsmodellen baserat på Azure Resource Manager till Azure Local och andra platser som inte är Azure. Azure Arc använder Azure som kontroll- och hanteringsplan för att möjliggöra hantering av olika resurser, till exempel virtuella datorer, Kubernetes-kluster och containerbaserade data- och maskininlärningstjänster.

• Azure Key Vault är en molntjänst som du kan använda för att lagra och komma åt hemligheter på ett säkert sätt. En hemlighet är allt som du vill begränsa åtkomsten till, till exempel API-nycklar, lösenord, certifikat, kryptografiska nycklar, autentiseringsuppgifter för lokal administratör och BitLocker-återställningsnycklar.

• Molnvittne är en funktion i Azure Storage som fungerar som ett kvorum för redundanskluster. Azure Local-klusternoder använder det här kvorumet för röstning, vilket garanterar hög tillgänglighet för klustret. Lagringskontot och vittneskonfigurationen skapas under distributionsprocessen för det lokala Azure-molnet.

• Update Manager är en enhetlig tjänst som är utformad för att hantera och styra uppdateringar för Azure Local. Du kan använda Update Manager för att hantera arbetsbelastningar som distribueras på Azure Local, inklusive uppdateringsefterlevnad för gästoperativsystem för virtuella Windows- och Linux-datorer. Den här enhetliga metoden effektiviserar korrigeringshanteringen i Azure, lokala miljöer och andra molnplattformar via en enda instrumentpanel.

Plattformsstödande resurser

Arkitekturen innehåller följande valfria stödtjänster för att förbättra plattformens funktioner:

• Monitor är en molnbaserad tjänst för att samla in, analysera och agera på diagnostikloggar och telemetri från molnet och lokala arbetsbelastningar. Du kan använda Monitor för att maximera tillgängligheten och prestandan för dina program och tjänster via en omfattande övervakningslösning. Distribuera Insights för Azure Local för att förenkla skapandet av regeln övervaka datainsamling (DCR) och snabbt aktivera övervakning av lokala Azure-instanser.

• Azure Policy är en tjänst som utvärderar Azure och lokala resurser. Azure Policy utvärderar resurser genom integrering med Azure Arc med hjälp av egenskaperna för dessa resurser för affärsregler, som kallas principdefinitioner, för att fastställa efterlevnad eller funktioner som du kan använda för att tillämpa VM-gästkonfiguration med hjälp av principinställningar.

• Defender for Cloud är ett omfattande säkerhetshanteringssystem för infrastruktur. Det förbättrar säkerhetsstatusen för dina datacenter och ger avancerat skydd mot hot för hybridarbetsbelastningar, oavsett om de finns i Azure eller någon annanstans och i lokala miljöer.

• Azure Backup är en molnbaserad tjänst som tillhandahåller en enkel, säker och kostnadseffektiv lösning för att säkerhetskopiera dina data och återställa dem från Microsoft Cloud. Azure Backup Server används för att säkerhetskopiera virtuella datorer som distribueras på Azure Local och lagra dem i säkerhetskopieringstjänsten.

• Site Recovery är en haveriberedskapstjänst som tillhandahåller BCDR-funktioner genom att göra det möjligt för företagsappar och arbetsbelastningar att redundansväxla om det uppstår ett haveri eller avbrott. Site Recovery hanterar replikering och redundans för arbetsbelastningar som körs på fysiska servrar och virtuella datorer mellan deras primära plats (lokalt) och en sekundär plats (Azure).

Designval för kluster

Det är viktigt att förstå kraven på arbetsbelastningsprestanda och återhämtning när du utformar en lokal Azure-instans. Dessa krav omfattar mål för återställningstid (RTO) och målmål för återställningspunkt (RPO), beräkning (CPU), minne och lagringskrav för alla arbetsbelastningar som distribueras på den lokala Azure-instansen. Flera egenskaper hos arbetsbelastningen påverkar beslutsprocessen och omfattar:

• Arkitekturfunktioner för central bearbetningsenhet (CPU), inklusive funktioner för maskinvarusäkerhetsteknik, antalet processorer, GHz-frekvensen (hastighet) och antalet kärnor per CPU-socket.

• GPU-krav (Graphics Processing Unit) för arbetsbelastningen, till exempel för AI eller maskininlärning, slutsatsdragning eller grafikrendering.

• Minnet per nod eller mängden fysiskt minne som krävs för att köra arbetsbelastningen.

• Antalet fysiska noder i klustret som är mellan 1 och 16 noder i skala. Det maximala antalet noder är tre när du använder nätverksarkitektur utan lagring.

  • För att upprätthålla beräkningsåterhämtningen måste du reservera kapacitet för minst N+1-noder i klustret. Den här strategin möjliggör noddränering för uppdateringar eller återställning efter plötsliga avbrott som strömavbrott eller maskinvarufel.

  • För affärskritiska eller verksamhetskritiska arbetsbelastningar bör du överväga att reservera kapacitet för N+2-noder för att öka återhämtning. Om två noder i klustret till exempel är offline kan arbetsbelastningen förbli online. Den här metoden ger återhämtning för scenarier där en nod som kör en arbetsbelastning går offline under en planerad uppdateringsprocedur och resulterar i att två noder är offline samtidigt.

• Krav på lagringsåterhämtning, kapacitet och prestanda:

  • Återhämtning: Vi rekommenderar att du distribuerar tre eller flera noder för att aktivera trevägsspegling, som innehåller tre kopior av data, för infrastrukturen och användarvolymerna. Trevägsspegling ökar prestanda och maximal tillförlitlighet för lagring.

  • Capacity: Den totala nödvändiga användbara lagringen efter feltolerans, eller kopior, beaktas. Det här antalet är cirka 33% av det råa lagringsutrymmet på dina diskar på kapacitetsnivå när du använder trevägsspegling.

  • Prestanda: Indata-/utdataåtgärder per sekund (IOPS) för plattformen som avgör lagringsdataflödesfunktionerna för arbetsbelastningen multiplicerat med programmets blockstorlek.

För att utforma och planera en lokal Azure-distribution rekommenderar vi att du använder storleksverktyget Azure Local och skapar en New Project- för storleksändring av dina HCI-kluster. Om du använder storleksverktyget måste du förstå dina arbetsbelastningskrav. När du överväger antalet och storleken på de virtuella arbetsbelastningsdatorer som körs i klustret bör du överväga faktorer som antalet virtuella processorer, minneskrav och nödvändig lagringskapacitet för de virtuella datorerna.

Storleksverktyget Inställningar avsnittet vägleder dig genom frågor som rör systemtypen (Premier, Integrerat system eller Verifierad nod) och processorfamiljealternativ. Det hjälper dig också att välja dina återhämtningskrav för klustret. Se till att:

• Reservera minst N+1 noder eller en nod i klustret.

• Reservera kapacitet för N+2-noder i klustret för extra återhämtning. Med det här alternativet kan systemet motstå ett nodfel under en uppdatering eller annan oväntad händelse som påverkar två noder samtidigt. Det säkerställer också att det finns tillräckligt med kapacitet i klustret för att arbetsbelastningen ska kunna köras på de återstående onlinenoderna.

Det här scenariot kräver trevägsspegling för användarvolymer, vilket är standard för kluster som har tre eller flera fysiska noder.

Utdata från storleksverktyget för Azure Local är en lista över rekommenderade maskinvarulösnings-SKU:er som kan tillhandahålla nödvändig arbetsbelastningskapacitet och krav på plattformsåterhämtning baserat på indatavärdena i Sizer Project. Mer information om tillgängliga OEM-maskinvarupartnerlösningar finns i Azure Local Solutions Catalog. Kontakta den maskinvarulösningsleverantör eller systemintegreringspartner som du föredrar för att hjälpa till med rightsize-lösningens SKU:er för att uppfylla dina krav.

Fysiska diskenheter

Lagringsdirigering stöder flera typer av fysiska diskenheter som varierar i prestanda och kapacitet. När du utformar en lokal Azure-instans kan du samarbeta med din valda maskinvaru-OEM-partner för att fastställa de lämpligaste fysiska diskenhetstyperna för att uppfylla kapacitets- och prestandakraven för din arbetsbelastning. Exempel är snurrande hårddiskar (HDD) eller SSD-enheter (Solid State Drives) och NVMe-enheter. Dessa enheter kallas ofta flash-enheter, eller lagring av beständigt minne (PMem), som kallas lagringsklassminne (SCM).

Plattformens tillförlitlighet beror på prestanda för kritiska plattformsberoenden, till exempel fysiska disktyper. Se till att välja rätt disktyper för dina behov. Använd flashlagringslösningar som NVMe- eller SSD-enheter för arbetsbelastningar som har höga prestanda eller krav på låg latens. Dessa arbetsbelastningar omfattar men är inte begränsade till hög transaktionsdatabastekniker, AKS-produktionskluster eller verksamhetskritiska eller affärskritiska arbetsbelastningar som har lagringskrav med låg svarstid eller högt dataflöde. Använd all-flash-distributioner för att maximera lagringsprestanda. All-NVMe enhets- eller all-SSD-enhetskonfigurationer, särskilt i liten skala, förbättrar lagringseffektiviteten och maximerar prestanda eftersom inga enheter används som cachenivåFör mer information, se All-flash-baserad lagring.

För allmänna arbetsbelastningar kan en hybridlagringskonfiguration, till exempel NVMe-enheter eller SSD:er för cachelagring och HÅRDDISKar för kapacitet, ge mer lagringsutrymme. Kompromissen är att snurrande diskar har lägre prestanda om din arbetsbelastning överskrider den cachearbetsuppsättningen, och hårddiskar har en lägre genomsnittlig tid mellan felvärdet jämfört med NVMe- och SSD-enheter.

Prestandan för klusterlagringen påverkas av den fysiska diskenhetstypen, som varierar beroende på prestandaegenskaperna för varje enhetstyp och den cachelagringsmekanism som du väljer. Den fysiska diskenhetstypen är en integrerad del av design och konfiguration av lagringsdirigering. Beroende på kraven för azure-lokala arbetsbelastningar och budgetbegränsningar kan du välja att maximera prestanda, maximera kapaciteteneller implementera en konfiguration av typen blandad enhet som balanserar prestanda och kapacitet.

Lagringsdirigering ger en inbyggd, beständig, i realtid, läsning, skrivning, cache på serversidan som maximerar lagringsprestanda. Cachen ska vara storleksanpassad och konfigurerad för att hantera den arbetsuppsättningen för dina program och arbetsbelastningar. Virtuella lagringsdirigeringsdiskar, eller volymer, används i kombination med klusterdelade volymer (CSV) minnesintern läscache för att förbättra Hyper-V prestanda, särskilt för obufferderad indataåtkomst till virtuella hårddiskar (VHD) eller VHDX-filer (virtuell hårddisk v2).

Nätverksdesign

Nätverksdesign är det övergripande arrangemanget för komponenter i nätverkets fysiska infrastruktur och logiska konfigurationer. Du kan använda samma portar för fysiska nätverkskort (NIC) för alla kombinationer av hanterings-, beräknings- och lagringsnätverkssyften. Att använda samma NIC-portar för alla avsiktsrelaterade syften kallas för en fullständigt konvergerad nätverkskonfiguration.

Även om en fullständigt konvergerad nätverkskonfiguration stöds är den optimala konfigurationen för prestanda och tillförlitlighet för lagringssyftet att använda dedikerade nätverkskortportar. Den här baslinjearkitekturen ger därför exempel på vägledning för hur du distribuerar en lokal Azure-instans med flera noder med hjälp av nätverksarkitekturen för lagringsväxlar med två nätverkskortportar som konvergeras för hanterings- och beräkningsavsikter och två dedikerade nätverkskortportar för lagringsavsikten. Mer information finns i Nätverksöverväganden för molndistributioner av Azure Local.

Den här arkitekturen kräver två eller flera fysiska noder och upp till högst 16 noder i skala. Varje nod kräver fyra nätverkskortsportar som är anslutna till två ToR-växlar (Top-of-Rack). De två ToR-växlarna ska kopplas samman via MLAG-länkar (multi-chassis link aggregation group). De två nätverkskortportar som används för lagringsavsiktstrafiken måste ha stöd för RDMA (Remote Direct Memory Access). Dessa portar kräver en minsta länkhastighet på 10 Gbit/s, men vi rekommenderar en hastighet på 25 Gbit/s eller högre. De två nätverkskortportar som används för hanterings- och beräkningssyften konvergeras med hjälp av SET-teknik (Switch Embedded Teaming). SET-teknik ger funktioner för länkredundans och belastningsutjämning. Dessa portar kräver en minsta länkhastighet på 1 Gbit/s, men vi rekommenderar en hastighet på 10 Gbit/s eller högre.

Topologi för fysiskt nätverk

Följande fysiska nätverkstopologi visar de faktiska fysiska anslutningarna mellan noder och nätverkskomponenter.

Du behöver följande komponenter när du utformar en Azure Local-distribution med flera nodlagringsväxlar som använder den här baslinjearkitekturen:

• Dubbla ToR-växlar:

  • Dubbla ToR-nätverksväxlar krävs för nätverksåterhämtning och möjligheten att underhålla eller tillämpa uppdateringar av inbyggd programvara på switcharna utan att orsaka avbrott. Den här strategin förhindrar en enskild felpunkt (SPoF).

  • De dubbla ToR-växlarna används för lagring, eller öst-väst, trafik. Dessa växlar använder två dedikerade Ethernet-portar som har specifika VLAN(Storage Virtual Local Area Networks) och trafikklasser för prioritetsflödeskontroll (PFC) som har definierats för att tillhandahålla förlustfri RDMA-kommunikation.

  • Dessa växlar ansluter till noderna via Ethernet-kablar.

• Två eller flera fysiska noder och upp till högst 16 noder:

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

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

  • Storage använder de två dedikerade RDMA-kompatibla nätverkskortportarna som ansluter med en sökväg till var och en av de två ToR-växlarna. Den här metoden ger redundans för länkvägar och dedikerad prioriterad bandbredd för SMB Direct-lagringstrafik.

  • Hantering och beräkning använder två nätverkskortportar som ger en sökväg till var och en av de två ToR-växlarna för redundans för länksökväg.

• Extern anslutning:

  • Dubbla ToR-växlar ansluter till det externa nätverket, till exempel ditt interna företags-LAN, för att ge åtkomst till de utgående URL:er som krävs med hjälp av gränsnätverksenheten. Den här enheten kan vara en brandvägg eller router. Dessa växlar dirigerar trafik som går in och ut ur Azure Local-instansen eller nord-syd-trafik.

  • Extern trafikanslutning mellan nord och syd stöder avsikten för klusterhantering och beräkningsavsikter. Detta uppnås genom att använda två växelportar och två portar för nätverkskort per nod som konvergeras via switch embedded teaming (SET) och en virtuell växel inom Hyper-V för att säkerställa återhämtning. Dessa komponenter fungerar för att tillhandahålla extern anslutning för virtuella Azure Arc-datorer och andra arbetsbelastningsresurser som distribueras i de logiska nätverk som skapas i Resource Manager med hjälp av Azure-portalen, CLI eller IaC-mallar.

Topologi för logiskt nätverk

Topologin för det logiska nätverket visar en översikt över hur nätverksdata flödar mellan enheter, oavsett deras fysiska anslutningar.

En sammanfattning av den logiska konfigurationen för den här baslinjearkitekturen för flera nodlagringsväxlar för Azure Local är följande:

• Dubbla ToR-växlar:

  • Innan du distribuerar klustret måste de två ToR-nätverksväxlarna konfigureras med nödvändiga VLAN-ID:n, maximala inställningar för överföringsenheter och konfiguration av datacenterbryggning för hantering, beräkningoch lagring portar. Mer information finns i fysiska nätverkskrav för Azure Local, eller be leverantören av växelmaskinvara eller SI-partnern om hjälp.

• Azure Local använder metoden Network ATC för att tillämpa nätverksautomatisering och avsiktsbaserad nätverkskonfiguration.

  • 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 fysiska nätverkstopologi avsnitt.

  • 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 konvergerade virtuella SET-teamets gränssnitt, vilket 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 hjälp av ett SET-team för beräknings- och hanteringssyften.

• Lagringstrafik:

  • De fysiska noderna kommunicerar med varandra med hjälp av två dedikerade nätverkskortportar som är anslutna till ToR-växlarna för att ge hög bandbredd och återhämtning för lagringstrafik.

  • SMB1 och SMB2 lagringsportar ansluter till två separata icke-utfällbara nätverk (eller Layer 2). Varje nätverk har ett specifikt VLAN-ID konfigurerat som måste matcha växelportkonfigurationen på ToR-växlarnas standardlagrings-VLAN-ID:n: 711 och 712.

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

  • Varje nod kan komma åt lagringsdirigeringsfunktioner 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 via de två dedikerade lagringsnätverkskortportarna som är tillgängliga i varje nod. SMB Multichannel används för återhämtning.

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

Krav för nätverksväxel

Dina Ethernet-växlar måste uppfylla de olika specifikationer som krävs av Azure Local och anges av Institute of Electrical and Electronics Engineers Standards Association (IEEE SA). Till exempel används lagringsnätverket för RDMA via RoCE v2 eller iWARPför distributioner med flera noder. Den här processen kräver IEEE 802.1Qbb PFC för att säkerställa förlustfri kommunikation för -lagringstrafikklassen. Dina ToR-växlar måste ge stöd för IEEE 802.1Q för VLAN och IEEE 802.1AB för Link Layer Discovery Protocol.

Om du planerar att använda befintliga nätverksväxlar för en lokal Azure-distribution läser du lista över obligatoriska IEEE-standarder och specifikationer som nätverksväxlarna och konfigurationen måste tillhandahålla. När du köper nya nätverksväxlar läser du lista över maskinvaruleverantörscertifierade switchmodeller som stöder krav för Azure Local-nätverk.

KRAV för IP-adress

I en distribution med flera noder för lagringsväxlar ökar antalet IP-adresser som behövs med tillägg av varje fysisk nod, upp till högst 16 noder i ett enda kluster. Om du till exempel vill distribuera en konfiguration med två noder av Azure Local kräver klusterinfrastrukturen att minst 11 x IP-adresser allokeras. Fler IP-adresser krävs om du använder mikrosegmentering eller programvarudefinierade nätverk. Mer information finns i Granska IP-adresskrav för lagringsreferenser med två 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 distribuera AKS på Azure Local kan du läsa AKS som aktiveras av Azure Arc-nätverkskraven.

Övervakning

Om du vill förbättra övervakning och aviseringar aktiverar du Monitor Insights på Azure Local. Insikter kan skalas för att övervaka och hantera flera lokala kluster med hjälp av en Azure-konsekvent upplevelse. Insights använder klusterprestandaräknare och händelseloggkanaler för att övervaka viktiga lokala Azure-funktioner. Loggar samlas in av dcr som konfigureras via Monitor och Log Analytics.

Insikter för Azure Local skapas med hjälp av Monitor och Log Analytics, vilket säkerställer en alltid up-to- datum, skalbar lösning som är mycket anpassningsbar. Insikter ger åtkomst till standardarbetsböcker med grundläggande mått, tillsammans med specialiserade arbetsböcker som skapats för övervakning av viktiga funktioner i Azure Local. Dessa komponenter tillhandahåller en övervakningslösning i nästan realtid och möjliggör skapande av grafer, anpassning av visualiseringar via aggregering och filtrering samt konfiguration av anpassade hälsoaviseringsregler för resurser.

Uppdateringshantering

Lokala Azure-instanser och distribuerade arbetsbelastningsresurser, till exempel virtuella Azure Arc-datorer, måste uppdateras och korrigeras regelbundet. Genom att regelbundet tillämpa uppdateringar ser du till att din organisation har en stark säkerhetsstatus och att du förbättrar den övergripande tillförlitligheten och supporten för din egendom. Vi rekommenderar att du använder automatiska och periodiska manuella utvärderingar för tidig identifiering och tillämpning av säkerhetskorrigeringar och OS-uppdateringar.

Infrastrukturuppdateringar

Azure Local uppdateras kontinuerligt för att förbättra kundupplevelsen och lägga till nya funktioner. Den här processen hanteras via versionståg, som levererar nya baslinjeversioner kvartalsvis. Baslinjeversioner tillämpas på lokala Azure-instanser för att hålla dem uppdaterade. Förutom regelbundna uppdateringar av baslinjebygget uppdateras Azure Local med månatliga uppdateringar av operativsystemsäkerhet och tillförlitlighet.

Update Manager är en Azure-tjänst som du kan använda för att tillämpa, visa och hantera uppdateringar för Azure Local. Den här tjänsten tillhandahåller en mekanism för att visa allaAzure Local-instanser över hela infrastrukturen och gränsplatserna med hjälp av Azure-portalen för att tillhandahålla en centraliserad hanteringsupplevelse. Mer information finns i följande resurser:

• Om information om lokal azure-version

• lokal livscykeltakt i Azure

• Granska uppdateringsfaser i Azure Local

• Använda Azure Update Manager för att uppdatera Azure Local

Det är viktigt att regelbundet söka efter nya uppdateringar av drivrutiner och inbyggd programvara, till exempel var tredje till sjätte månad. Om du använder en Premier-lösningskategoriversion för din lokala Azure-maskinvara uppdateras Solution Builder-tilläggspaketet integreras med Update Manager för att ge en förenklad uppdateringsupplevelse. Om du använder verifierade noder eller en integrerad systemkategori kan det finnas ett krav på att ladda ned och köra ett OEM-specifikt uppdateringspaket som innehåller den inbyggda programvaran och drivrutinsuppdateringarna för maskinvaran. Om du vill ta reda på hur uppdateringar tillhandahålls för maskinvaran kontaktar du maskinvaru-OEM- eller SI-partnern.

Uppdatering av gästoperativsystem för arbetsbelastning

Du kan registrera virtuella Azure Arc-datorer som distribueras på Azure Local med hjälp av Azure Update Manager (AUM) för att tillhandahålla en enhetlig uppdateringshantering med hjälp av samma mekanism som används för att uppdatera de fysiska noderna i Azure Local-klustret. Du kan använda AUM för att skapa konfigurationer för gästunderhåll. Dessa konfigurationer styr inställningar, till exempel inställningen Starta om omstart om det behövs, schemat (datum, tider och upprepningsalternativ) och antingen en dynamisk (prenumeration) eller en statisk lista över de virtuella Azure Arc-datorerna för omfånget. De här inställningarna styr konfigurationen för när os-säkerhetskorrigeringar installeras i den virtuella arbetsbelastningsdatorns gästoperativsystem.

Ö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.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Översikt över tillförlitlighetspelare.

Identifiera potentiella felpunkter

Varje arkitektur är känslig för fel. Du kan förutse fel och vara förberedd med åtgärder med analys av felläge. I följande tabell beskrivs fyra exempel på potentiella felpunkter i den här arkitekturen:

Mer information finns i Rekommendationer för att utföra fellägesanalys.

Tillförlitlighetsmål

I det här avsnittet beskrivs ett exempelscenario. En fiktiv kund med namnet Contoso Manufacturing använder den här referensarkitekturen för att distribuera Azure Local. De vill uppfylla sina krav och distribuera och hantera arbetsbelastningar lokalt. Contoso Manufacturing har ett internt servicenivåmål på 99,8% som affärs- och programintressenter är överens om för sina tjänster.

• Ett serviceavtal på 99,8% drifttid eller tillgänglighet resulterar i följande perioder av tillåten driftstopp eller otillgänglighet för de program som distribueras med virtuella Azure Arc-datorer som körs på Azure Local:

  • Varje vecka: 20 minuter och 10 sekunder

  • Varje månad: 1 timme, 26 minuter och 56 sekunder

  • Kvartalsvis: 4 timmar, 20 minuter och 49 sekunder

  • Årligen: 17 timmar, 23 minuter och 16 sekunder

• För att hjälpa till att uppfylla SLO-målenimplementerar Contoso Manufacturing principen om minsta behörighet (PoLP) för att begränsa antalet Administratörer för lokala Azure-instanser till en liten grupp betrodda och kvalificerade personer. Den här metoden hjälper till att förhindra driftstopp på grund av oavsiktliga eller oavsiktliga åtgärder som utförs på produktionsresurser. Dessutom övervakas säkerhetshändelseloggarna för lokala Active Directory Domain Services-domänkontrollanter (AD DS) för att identifiera och rapportera ändringar i användarkontogruppmedlemskap, så kallade lägga till och ta bort åtgärder, för Azure Local Instance-administratörer grupp med hjälp av en SIEM-lösning (Security Information Event Management). Övervakning ökar tillförlitligheten och förbättrar säkerheten för lösningen.

  Mer information finns i Rekommendationer för identitets- och åtkomsthantering.

• Strikta procedurer för ändringskontroll finns för Contoso Manufacturings produktionssystem. Den här processen kräver att alla ändringar testas och verifieras i en representativ testmiljö innan de implementeras i produktion. Alla ändringar som skickas till den veckovisa processen för ändringsrekommendationer måste innehålla en detaljerad implementeringsplan (eller länk till källkod), risknivåpoäng, en omfattande återställningsplan, testning och verifiering efter lanseringen och tydliga framgångskriterier för en ändring som ska granskas eller godkännas.

  Mer information finns i rekommendationer för säkra distributionsmetoder.

• Månatliga säkerhetskorrigeringar och kvartalsvisa baslinjeuppdateringar tillämpas på Azure Local-produktionsinstansen först när de har verifierats av förproduktionsmiljön. Uppdateringshanteraren och den klustermedvetna uppdateringsfunktionen automatiserar processen med att använda vm-direktmigrering för att minimera stilleståndstiden för affärskritiska arbetsbelastningar under de månatliga serviceåtgärderna. Standardrutiner för Contoso Manufacturing kräver att säkerhets-, tillförlitlighets- eller baslinjeversionsuppdateringar tillämpas på alla produktionssystem inom fyra veckor efter utgivningsdatumet. Utan den här principen kan produktionssystem ständigt inte hålla sig aktuella med månatliga operativsystem och säkerhetsuppdateringar. Inaktuella system påverkar plattformens tillförlitlighet och säkerhet negativt.

  Mer information finns i Rekommendationer för att upprätta en säkerhetsbaslinje.

• Contoso Manufacturing implementerar dagligen, veckovisa och månatliga säkerhetskopieringar för att behålla de senaste 6 x dagarna av dagliga säkerhetskopieringar (måndagar till lördagar), de senaste 3 x varje vecka (varje söndag) och 3 x månatliga säkerhetskopieringar, där varje söndag vecka 4 behållas för att bli säkerhetskopior i månad 1, månad 2 och månad 3 med hjälp av ett rullande kalenderbaserat schema som dokumenteras och kan granskas. Den här metoden uppfyller Contosos tillverkningskrav för en lämplig balans mellan antalet tillgängliga dataåterställningspunkter och minskar kostnaderna för lagringstjänsten för säkerhetskopiering på annan plats eller i molnet.

  Mer information finns i rekommendationer för att utforma en strategi för haveriberedskap.

• datasäkerhetskopierings- och återställningsprocesser testas för varje affärssystem var sjätte månad. Den här strategin garanterar att BCDR-processer är giltiga och att verksamheten skyddas om en datacenterkatastrof eller en cyberincident inträffar.

  Mer information finns i rekommendationer för att utforma en strategi för tillförlitlighetstestning.

• De operativa processer och procedurer som beskrivs tidigare i artikeln och rekommendationerna i tjänstguiden för Well-Architected Framework för Azure Localgör det möjligt för Contoso Manufacturing att uppfylla sina 99,8% SLO-mål och effektivt skala och hantera distributioner av lokala azure- och arbetsbelastningar på flera tillverkningsplatser som distribueras runt om i världen.

  Mer information finns i Rekommendationer för att definiera tillförlitlighetsmål.

Redundans

Överväg en arbetsbelastning som du distribuerar på en enda lokal Azure-instans som en lokalt redundant distribution. Klustret ger hög tillgänglighet på plattformsnivå, men du måste distribuera klustret i ett enda rack. För affärskritiska eller verksamhetskritiska användningsfall rekommenderar vi att du distribuerar flera instanser av en arbetsbelastning eller tjänst över två eller flera separata lokala Azure-instanser, helst på separata fysiska platser.

Använd branschstandardmönster med hög tillgänglighet för arbetsbelastningar som tillhandahåller aktiv/passiv replikering, synkron replikering eller asynkron replikering, till exempel SQL Server Always On. Du kan också använda en teknik för extern nätverksbelastningsutjämning (NLB) som dirigerar användarbegäranden över flera arbetsbelastningsinstanser som körs på lokala Azure-instanser som du distribuerar på separata fysiska platser. Överväg att använda en partner extern NLB-enhet. Eller så kan du utvärdera alternativen för belastningsutjämning som stöder trafikroutning för hybridtjänster och lokala tjänster, till exempel en Azure Application Gateway-instans som använder Azure ExpressRoute eller en VPN-tunnel för att ansluta till en lokal tjänst.

Mer information finns i Rekommendationer för att utforma redundans.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

Säkerhetsöverväganden omfattar:

• En säker grund för Den lokala Azure-plattformen: Azure Local är en säker produkt som standard som använder verifierade maskinvarukomponenter med TPM, UEFI och Säker start för att skapa en säker grund för Azure Local-plattformen och arbetsbelastningssäkerheten. När du distribuerar med standardsäkerhetsinställningarna har Azure Local Windows Defender Application Control, Credential Guard och BitLocker aktiverat. För att förenkla delegering av behörigheter med hjälp av PoLP använder du inbyggda rollbaserade RBAC-roller (Azure Local) till exempel Azure Local Administrator för plattformsadministratörer och Azure Local VM-deltagare eller Azure Local VM Reader för arbetsbelastningsoperatorer.

• Standardsäkerhetsinställningar: azure local security default tillämpar standardsäkerhetsinställningar för din lokala Azure-instans under distributionen och aktiverar driftkontroll för att hålla noderna i ett känt bra tillstånd. Du kan använda standardinställningarna för säkerhet för att hantera klustersäkerhet, driftkontroll och säkra kärnserverinställningar i klustret.

• Säkerhetshändelseloggar: vidarebefordran av azure-lokala syslog- integreras med säkerhetsövervakningslösningar genom att hämta relevanta säkerhetshändelseloggar för att aggregera och lagra händelser för kvarhållning i din egen SIEM-plattform.

• Skydd mot hot och sårbarheter: Defender för molnet skyddar din Lokala Azure-instans från olika hot och sårbarheter. Den här tjänsten hjälper till att förbättra säkerhetsstatusen för din lokala Azure-miljö och kan skydda mot befintliga och föränderliga hot.

• Hotidentifiering och -reparation: Microsoft Advanced Threat Analytics identifierar och åtgärdar hot, till exempel de som riktar sig mot AD DS, som tillhandahåller autentiseringstjänster till Azure Local Instance-noder och deras vm-arbetsbelastningar för Windows Server.

• Nätverksisolering: Isolera nätverk om det behövs. Du kan till exempel etablera flera logiska nätverk som använder separata VLAN och nätverksadressintervall. När du använder den här metoden kontrollerar du att hanteringsnätverket kan nå varje logiskt nätverk och VLAN så att Azure Local-instansnoder kan kommunicera med VLAN-nätverken via ToR-växlar eller gatewayer. Den här konfigurationen krävs för hantering av arbetsbelastningen, till exempel att tillåta infrastrukturhanteringsagenter att kommunicera med gästoperativsystemet för arbetsbelastningen.

  Mer information finns i Rekommendationer för att skapa en segmenteringsstrategi.

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:

• molnbaserad faktureringsmodell för licensiering: Azure Local-priser följer faktureringsmodellen för månadsprenumeration med ett fast pris per fysisk processorkärna i en lokal Azure-instans. Extra användningsavgifter tillkommer om du använder andra Azure-tjänster. Om du äger lokala kärnlicenser för Windows Server Datacenter Edition med aktiv Software Assurance kan du välja att byta ut dessa licenser för att aktivera prenumerationsavgifter för azure-lokala instanser och virtuella Windows Server-datorer.

• automatisk vm-gästkorrigering för virtuella Azure Arc-datorer: Den här funktionen hjälper till att minska kostnaderna för manuell korrigering och tillhörande underhållskostnader. Den här åtgärden hjälper inte bara till att göra systemet säkrare, utan även optimerar resursallokering och bidrar till total kostnadseffektivitet.

• Kostnadsövervakningskonsolidering: Om du vill konsolidera övervakningskostnaderna använder du Insights för Azure Local och korrigerar med hjälp av Update Manager för Azure Local. Insights använder Monitor för att tillhandahålla omfattande mått och aviseringsfunktioner. Livscykelhanterarens komponent i Azure Localintegreras med Update Manager för att förenkla uppgiften att hålla dina kluster uppdaterade genom att konsolidera uppdateringsarbetsflöden för olika komponenter till en enda upplevelse. Använd Monitor och Update Manager för att optimera resursallokering och bidra till total kostnadseffektivitet.

  Mer information finns i Rekommendationer för att optimera personaltiden.

• Inledande arbetsbelastningskapacitet och tillväxt: När du planerar din lokala Azure-distribution bör du överväga din ursprungliga arbetsbelastningskapacitet, återhämtningskrav och framtida tillväxtöverväganden. Överväg att använda en växlingslös arkitektur med två eller tre noder för lagring, till exempel om du tar bort behovet av att skaffa nätverksväxlar i lagringsklass. Att skaffa extra nätverksväxlar för lagringsklass kan vara en dyr komponent i nya distributioner av lokala Azure-instanser. I stället kan du använda befintliga växlar för hanterings- och beräkningsnätverk, vilket förenklar infrastrukturen. Om din arbetsbelastningskapacitet och återhämtningsbehov inte behöver skalas utöver en konfiguration med tre noder kan du överväga om du kan använda befintliga växlar för hanterings- och beräkningsnätverken och använda trenodsarkitektur för lagringsväxellös för att distribuera Azure Local.

  Mer information finns i rekommendationer för att optimera komponentkostnader.

Driftskvalitet

Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Översikt över grundpelare för driftskvalitet.

Överväganden för driftskvalitet omfattar:

• Förenklad etablering och hantering som är integrerad med Azure: Den molnbaserade distributionen i Azure innehåller ett guidedrivet gränssnitt som visar hur du skapar en lokal Azure-instans. På samma sätt förenklar Azure processen med att hantera lokala Azure-instanser och virtuella Azure Arc-datorer. Du kan automatisera den portalbaserade distributionen av den lokala Azure-instansen med hjälp av ARM-mallen. Den här mallen ger konsekvens och automatisering för att distribuera Azure Local i stor skala, särskilt i gränsscenarier som butiker eller tillverkningsplatser som kräver en Lokal Azure-instans för att köra affärskritiska arbetsbelastningar.

• Automation-funktioner för virtuella datorer: Azure Local tillhandahåller en mängd olika automatiseringsfunktioner för att hantera arbetsbelastningar, till exempel virtuella Azure Arc-datorer, med automatiserad distribution av virtuella Azure Arc-datorer med hjälp av Azure CLI-, ARM- eller Bicep-mallar, med virtual machine OS-uppdateringar med Azure Arc-tillägg för uppdateringar och Azure Update Manager- för att uppdatera varje Lokal Azure-instans. Azure Local tillhandahåller även stöd för hantering av virtuella Azure Arc-datorer med hjälp av Azure CLI och virtuella datorer som inte är Azure Arc- med hjälp av Windows PowerShell. Du kan köra Azure CLI-kommandon lokalt från en av de lokala Azure-datorerna eller fjärransluta från en hanteringsdator. Integrering med Azure Automation och Azure Arc underlättar en mängd olika scenarier för extra automatisering för VM-arbetsbelastningar via Azure Arc-tillägg.

  Mer information finns i rekommendationer för att använda IaC.

• Automation-funktioner för containrar på AKS: Azure Local tillhandahåller en mängd olika automatiseringsfunktioner för hantering av arbetsbelastningar, till exempel containrar, i AKS. Du kan automatisera distributionen av AKS-kluster med hjälp av Azure CLI. Uppdatera AKS-arbetsbelastningskluster med hjälp av Azure Arc-tillägget för Kubernetes-uppdateringar. Du kan också hantera Azure Arc-aktiverade AKS- med hjälp av Azure CLI. Du kan köra Azure CLI-kommandon lokalt från en av de lokala Azure-datorerna eller fjärransluta från en hanteringsdator. Integrera med Azure Arc för en mängd olika scenarier för extra automatisering för containerbaserade arbetsbelastningar via Azure Arc-tillägg.

  Mer information finns i rekommendationer för att aktivera automatisering.

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:

• Arbetsbelastningslagringsprestanda: Överväg att använda verktyget DiskSpd för att testa prestandafunktioner för arbetsbelastningslagring i en lokal Azure-instans. Du kan använda verktyget VMFleet för att generera belastning och mäta prestanda för ett lagringsundersystem. Utvärdera om du bör använda VMFleet- för att mäta prestanda för lagringsundersystem.

  • Vi rekommenderar att du upprättar en baslinje för prestanda för dina lokala Azure-instanser innan du distribuerar produktionsarbetsbelastningar. DiskSpd använder olika kommandoradsparametrar som gör det möjligt för administratörer att testa klustrets lagringsprestanda. Huvudfunktionen i DiskSpd är att utfärda läs- och skrivåtgärder och prestandamått för utdata, till exempel svarstid, dataflöde och IOPS.

    Mer information finns i rekommendationer för prestandatestning.

• Återhämtning av arbetsbelastningslagring: Överväg fördelarna med lagringsåterhämtning, effektivitet och prestanda för användning (eller kapacitet). Planering för Lokala Azure-volymer omfattar att identifiera den optimala balansen mellan återhämtning, användningseffektivitet och prestanda. Det kan vara svårt att optimera den här balansen eftersom maximerande av en av dessa egenskaper vanligtvis har en negativ effekt på en eller flera av de andra egenskaperna. Ökad återhämtning minskar den användbara kapaciteten. Därför kan prestandan variera beroende på vilken återhämtningstyp som valts. När återhämtning och prestanda är prioriteten, och när du använder tre eller flera noder, använder standardlagringskonfigurationen trevägsspegling för både infrastruktur och användarvolymer.

  Mer information finns i rekommendationer för kapacitetsplanering.

• Optimering av nätverksprestanda: Överväg optimering av nätverksprestanda. Som en del av din design måste du inkludera beräknad allokering av nätverkstrafikbandbredd när du fastställer din optimal nätverksmaskinvarakonfiguration.

  • Om du vill optimera beräkningsprestanda i Azure Local kan du använda GPU-acceleration. GPU-acceleration är fördelaktigt för högpresterande AI- eller maskininlärningsarbetsbelastningar som omfattar datainsikter eller slutsatsdragning. Dessa arbetsbelastningar kräver distribution på gränsplatser på grund av överväganden som datagravitation eller säkerhetskrav. I en hybriddistribution eller lokal distribution är det viktigt att ta hänsyn till dina krav på arbetsbelastningsprestanda, inklusive GPU:er. Den här metoden hjälper dig att välja rätt tjänster när du utformar och skaffar dina lokala Azure-instanser.

    Mer information finns i Rekommendationer för att välja rätt tjänster.

Distribuera det här scenariot

Följande avsnitt innehåller en exempellista över uppgifter på hög nivå eller ett vanligt arbetsflöde som används för att distribuera Azure Local, inklusive nödvändiga uppgifter och överväganden. Den här arbetsflödeslistan är endast avsedd som en exempelguide. Det är inte en fullständig lista över alla nödvändiga åtgärder, som kan variera beroende på organisatoriska, geografiska eller projektspecifika krav.

scenario: Det finns ett projekt- eller användningsfallskrav för att distribuera en hybridmolnlösning på en lokal plats eller gränsplats för att tillhandahålla lokal beräkning för databehandlingsfunktioner och en önskan att använda Azure-konsekvent hantering och fakturering. Mer information beskrivs i avsnittet potentiella användningsfall i den här artikeln. De återstående stegen förutsätter att Azure Local är den valda lösningen för infrastrukturplattformen för projektet.

1. Samla in arbetsbelastnings- och användningsfallskrav från relevanta intressenter. Med den här strategin kan projektet bekräfta att funktionerna och funktionerna i Azure Local uppfyller kraven på arbetsbelastningsskala, prestanda och funktionalitet. Den här granskningsprocessen bör omfatta förståelse för arbetsbelastningsskala eller storlek och nödvändiga funktioner som virtuella Azure Arc-datorer, AKS, Azure Virtual Desktop eller Azure Arc-aktiverade datatjänster eller Azure Arc-aktiverad Machine Learning-tjänst. Arbetsbelastningens RTO- och RPO-värden (tillförlitlighet) och andra icke-funktionella krav (prestanda/belastningsskalbarhet) ska dokumenteras som en del av det här steget för insamling av krav.

2. Granska azure local sizer-utdata för den rekommenderade maskinvarupartnerlösningen. Det här utdata innehåller information om den rekommenderade fysiska servermaskinvarans märke och modell, antalet fysiska noder och specifikationerna för processor-, minnes- och lagringskonfigurationen för varje fysisk nod som krävs för att distribuera och köra dina arbetsbelastningar.

3. Använd storleksverktyget Azure Local för att skapa ett nytt projekt som modellerar arbetsbelastningstypen och skalar. Det här projektet innehåller storleken och antalet virtuella datorer och deras lagringskrav. Den här informationen matas in tillsammans med alternativ för systemtyp, önskad CPU-familj och dina återhämtningskrav för hög tillgänglighet och feltolerans för lagring, enligt beskrivningen i föregående klusterdesignval avsnittet.

4. Granska Azure Local Sizer-utdata för den rekommenderade maskinvarupartnerlösningen. Den här lösningen innehåller information om den rekommenderade fysiska servermaskinvaran (märke och modell), antalet fysiska noder och specifikationerna för processor-, minnes- och lagringskonfigurationen för varje fysisk nod som krävs för att distribuera och köra dina arbetsbelastningar.

5. Kontakta oem- eller SI-maskinvarupartnern för att ytterligare kvalificera lämpligheten för den rekommenderade maskinvaruversionen jämfört med dina arbetsbelastningskrav. Om det är tillgängligt använder du OEM-specifika storleksverktyg för att fastställa OEM-specifika maskinvarustorlekskrav för de avsedda arbetsbelastningarna. Det här steget omfattar vanligtvis diskussioner med oem- eller SI-maskinvarupartnern för de kommersiella aspekterna av lösningen. Dessa aspekter omfattar offerter, tillgänglighet för maskinvara, ledtider och eventuella professionella tjänster eller mervärdestjänster som partnern tillhandahåller för att hjälpa till att påskynda projekt- eller affärsresultaten.

6. Distribuera två ToR-växlar för nätverksintegrering. För lösningar med hög tillgänglighet kräver HCI-kluster att två ToR-växlar distribueras. Varje fysisk nod kräver fyra nätverkskort, varav två måste vara RDMA-kompatibla, vilket ger två länkar från varje nod till de två ToR-växlarna. Två nätverkskort, en ansluten till varje växel, konvergeras för utgående nord-syd-anslutning för beräknings- och hanteringsnätverken. De andra två RDMA-kompatibla nätverkskorten är dedikerade för lagringen öst-västlig trafik. Om du planerar att använda befintliga nätverksväxlar kontrollerar du att växlarnas märke och modell finns på den godkända listan över nätverksväxlar som stöds av Azure Local.

7. Arbeta med oem- eller SI-maskinvarupartnern för att ordna leverans av maskinvaran. SI-partnern eller dina anställda måste sedan integrera maskinvaran i ditt lokala datacenter eller din gränsplats, till exempel rackning och stapling av maskinvara, fysiskt nätverk och strömförsörjningsenhetskablar för de fysiska noderna.

8. Utföra distributionen av den lokala Azure-instansen. Beroende på din valda lösningsversion (Premier-lösning, integrerat system eller verifierade noder) kan antingen maskinvarupartnern, SI-partnern eller dina anställda distribuera Azure Local-programvaran. Det här steget börjar med att registrera de fysiska noderna i Azure Stack HCI OS i Azure Arc-aktiverade servrar och sedan starta distributionsprocessen för det lokala Azure-molnet. Kunder och partner kan skicka en supportbegäran direkt till Microsoft i Azure-portalen genom att välja ikonen Support + Felsökning eller genom att kontakta sin OEM- eller SI-maskinvarupartner, beroende på typen av begäran och maskinvarulösningskategorin.

   Dricks

   Azure Stack HCI OS, version 23H2 systemreferensimplementering visar hur du distribuerar en växlad multiserverdistribution av Azure Local med hjälp av en ARM-mall och parameterfil. Du kan också Bicep-exemplet visar hur du använder en Bicep-mall för att distribuera en lokal Azure-instans, inklusive dess kravresurser.

9. Distribuera arbetsbelastningar med hög tillgänglighet på Azure Local med hjälp av Azure-portalen, CLI eller ARM + Azure Arc-mallar för automatisering. Använd den anpassade platsen resursen i det nya HCI-klustret som målregion när du distribuera arbetsbelastningsresurser som virtuella Azure Arc-datorer, AKS, Azure Virtual Desktop-sessionsvärdar eller andra Azure Arc-aktiverade tjänster som du kan aktivera via AKS-tillägg och containerisering på Azure Local.

10. Installera månatliga uppdateringar för att förbättra säkerheten och tillförlitligheten för plattformen. För att hålla dina lokala Azure-instanser uppdaterade är det viktigt att installera Microsofts programuppdateringar och oem-drivrutiner för maskinvara och uppdateringar av inbyggd programvara. Dessa uppdateringar förbättrar säkerheten och tillförlitligheten för plattformen. Update Manager tillämpar uppdateringarna och tillhandahåller en centraliserad och skalbar lösning för att installera uppdateringar i ett enda kluster eller flera kluster. Kontakta oem-maskinvarupartnern för att fastställa processen för att installera uppdateringar av maskinvarudrivrutiner och inbyggd programvara eftersom den här processen kan variera beroende på vilken typ av maskinvarulösning du väljer (Premier-lösning, Integrerat system eller Verifierade noder). Mer information finns i Infrastrukturuppdateringar.

Relaterade resurser

• Design av hybridarkitektur
• Azure-hybridalternativ
• Automation i en hybridmiljö
• Azure Automation State Configuration
• Optimera administrationen av SQL Server-instanser i lokala miljöer och miljöer med flera moln med hjälp av Azure Arc

Nästa steg

Produktdokumentation:

• Azure Stack HCI OS version 23H2 versionsinformation
• AKS på Azure Local
• Azure Virtual Desktop för Azure Local
• Vad är lokal Azure-övervakning?
• Skydda vm-arbetsbelastningar med Site Recovery på Azure Local
• översikt över Monitor
• Översikt över ändringsspårning och inventering
• översikt över Update Manager
• Vad är Azure Arc-aktiverade datatjänster?
• Vad är Azure Arc-aktiverade servrar?
• Vad är säkerhetskopieringstjänsten?

Produktdokumentation för mer information om specifika Azure-tjänster:

• Lokala Azure-
• Azure Arc
• Key Vault-
• Azure Blob Storage-
• Övervaka
• Azure Policy
• Azure Container Registry
• Defender för Cloud
• Site Recovery-
• Säkerhetskopiering

Microsoft Learn-moduler:

• Konfigurera
• Utforma din webbplatsåterställningslösning i Azure
• Introduktion till Azure Arc-aktiverade servrar
• Introduktion till Azure Arc-aktiverade datatjänster
• Introduktion till AKS-
• Skalningsmodelldistribution med Machine Learning var som helst – Tech Community Blog
• Realizing Machine Learning var som helst med AKS och Azure Arc-aktiverad Machine Learning – Tech Community Blog
• Maskininlärning på AKS-hybrid och Stack HCI med Hjälp av Azure Arc-aktiverad maskininlärning – Tech Community Blog
• Introduktion till Kubernetes-beräkningsmål i Machine Learning-
• Håll dina virtuella datorer uppdaterade
• Skydda dina inställningar för virtuella datorer med automationstillståndskonfiguration
• Skydda dina virtuella datorer med hjälp av Säkerhetskopiering