Dela via

Nätverk

  • Artikel

När du skapar och hanterar Azure Service Fabric-kluster tillhandahåller du nätverksanslutning för dina noder och program. Nätverksresurserna omfattar IP-adressintervall, virtuella nätverk, lastbalanserare och nätverkssäkerhetsgrupper. I den här artikeln får du lära dig metodtips för dessa resurser.

Granska Nätverksmönster för Azure Service Fabric för att lära dig hur du skapar kluster som använder följande funktioner: Befintligt virtuellt nätverk eller undernät, statisk offentlig IP-adress, intern lastbalanserare eller intern och extern lastbalanserare.

Infrastrukturnätverk

Maximera den virtuella datorns prestanda med accelererat nätverk genom att deklarera enableAcceleratedNetworking-egenskapen i Resource Manager-mallen. Följande kodfragment är ett NetworkInterfaceConfigurations för vm-skalningsuppsättningar som möjliggör accelererat nätverk:

"networkInterfaceConfigurations": [
  {
    "name": "[concat(variables('nicName'), '-0')]",
    "properties": {
      "enableAcceleratedNetworking": true,
      "ipConfigurations": [
        {
        <snip>
        }
      ],
      "primary": true
    }
  }
]

Service Fabric-kluster kan etableras i Linux med accelererat nätverk och Windows med accelererat nätverk.

Accelererat nätverk stöds för SKU:er i Azure Virtual Machine Series: D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2 och Ms/Mms. Accelererat nätverk har testats med hjälp av Standard_DS8_v3 SKU den 23-23-23 för ett Service Fabric Windows-kluster och med Standard_DS12_v2 den 29-29-2019 för ett Service Fabric Linux-kluster. Observera att accelererat nätverk kräver minst 4 vCPU:er.

Om du vill aktivera accelererat nätverk i ett befintligt Service Fabric-kluster måste du först skala ut ett Service Fabric-kluster genom att lägga till en VM-skalningsuppsättning för att utföra följande steg:

  1. Etablera en NodeType med accelererat nätverk aktiverat
  2. Migrera dina tjänster och deras tillstånd till den etablerade NodeType med accelererat nätverk aktiverat

Utskalning av infrastruktur krävs för att aktivera accelererat nätverk i ett befintligt kluster, eftersom aktivering av accelererat nätverk på plats skulle orsaka avbrott, eftersom det kräver att alla virtuella datorer i en tillgänglighetsuppsättning stoppas och frigörs innan accelererat nätverk aktiveras på ett befintligt nätverkskort.

Klusternätverk

  • Service Fabric-kluster kan distribueras till ett befintligt virtuellt nätverk genom att följa stegen som beskrivs i Service Fabric-nätverksmönster.

  • Nätverkssäkerhetsgrupper (NSG:er) rekommenderas för nodtyper för att begränsa inkommande och utgående trafik till klustret. Se till att de nödvändiga portarna öppnas i NSG:n.

  • Den primära nodtypen, som innehåller Service Fabric-systemtjänsterna, behöver inte exponeras via den externa lastbalanseraren och kan exponeras av en intern lastbalanserare

  • Använd en statisk offentlig IP-adress för klustret.

Nätverkssäkerhetsregler

De regler som beskrivs härnäst är det rekommenderade minimumet för en typisk konfiguration. Vi inkluderar även vilka regler som är obligatoriska för ett driftkluster om valfria regler inte önskas. Det möjliggör en fullständig säkerhetslåsning med nätverkspeering och jumpbox-begrepp som Azure Bastion. Om du inte öppnar de obligatoriska portarna eller godkänner IP/URL:en förhindras korrekt drift av klustret och stöds kanske inte.

Inkommande

Prioritet Namn Port Protokoll Källa Mål Action Obligatorisk
3900 Azure Portal 19080 TCP ServiceFabric Alla Tillåt Ja
3910 Klient-API 19000 TCP Internet Alla Tillåt Nej
3920 SFX + Klient-API 19080 TCP Internet Alla Tillåt Nej
3930 Kluster 1025-1027 TCP VirtualNetwork Alla Tillåt Ja
3940 Efemära 49152-65534 TCP VirtualNetwork Alla Tillåt Ja
3950 Program 20000-30000 TCP VirtualNetwork Alla Tillåt Ja
3960 RDP 3389 TCP Internet Valfri Neka Nej
3970 SSH 22 TCP Internet Valfri Neka Nej
3980 Anpassad slutpunkt 443 TCP Internet Valfri Neka Nej

Mer information om de inkommande säkerhetsreglerna:

  • Azure-portalen. Den här porten används av Service Fabric-resursprovidern för att fråga efter information om klustret för att kunna visas i Azure-hanteringsportalen. Om den här porten inte är tillgänglig från Service Fabric-resursprovidern visas ett meddelande som "Noder hittades inte" eller "UpgradeServiceNotReachable" i Azure-portalen och din nod- och programlista visas tom. Det innebär att om du vill ha insyn i klustret i Azure-hanteringsportalen måste lastbalanseraren exponera en offentlig IP-adress och din NSG måste tillåta inkommande 19080-trafik. Den här porten rekommenderas för utökade hanteringsåtgärder från Service Fabric-resursprovidern för att garantera högre tillförlitlighet.

  • Klient-API. Klientanslutningsslutpunkten för API:er som används av PowerShell.

  • SFX + Klient-API. Den här porten används av Service Fabric Explorer för att bläddra i och hantera klustret. Den används av de vanligaste API:erna som REST/PowerShell (Microsoft.ServiceFabric.PowerShell.Http)/CLI/.NET på samma sätt.

  • Kluster. Används för kommunikation mellan noder.

  • Tillfälliga. Service Fabric använder en del av dessa portar som programportar och de återstående är tillgängliga för operativsystemet. Det mappar också det här intervallet till det befintliga intervallet som finns i operativsystemet, så för alla ändamål kan du använda de intervall som anges i exemplet här. Kontrollera att skillnaden mellan start- och slutportarna är minst 255. Du kan stöta på konflikter om den här skillnaden är för låg eftersom det här intervallet delas med operativsystemet. Om du vill se det konfigurerade dynamiska portintervallet kör du netsh int ipv4 show dynamicport tcp. Dessa portar behövs inte för Linux-kluster.

  • Program. Programmets portintervall bör vara tillräckligt stort för att täcka slutpunktskravet för dina program. Det här intervallet bör vara exklusivt från det dynamiska portintervallet på datorn, dvs. intervallet ephemeralPorts enligt konfigurationen. Service Fabric använder dessa portar när nya portar krävs och tar hand om att öppna brandväggen för dessa portar på noderna.

  • RDP. Valfritt om RDP krävs från Internet eller VirtualNetwork för jumpbox-scenarier.

  • SSH. Valfritt om SSH krävs från Internet eller VirtualNetwork för jumpbox-scenarier.

  • Anpassad slutpunkt. Ett exempel för ditt program för att aktivera en internettillgänglig slutpunkt.

Kommentar

För de flesta regler med Internet som källa bör du överväga att begränsa till ditt kända nätverk, helst definierat av CIDR-block.

Utgående

Prioritet Namn Port Protokoll Källa Mål Action Obligatorisk
4010 Resursprovider 443 TCP Alla ServiceFabric Tillåt Ja
4020 Ladda ned binärfiler 443 TCP Alla AzureFrontDoor.FirstParty Tillåt Ja

Mer information om de utgående säkerhetsreglerna:

  • Resursprovider. Anslut mellan UpgradeService- och Service Fabric-resursprovidern för att ta emot hanteringsåtgärder som ARM-distributioner eller obligatoriska åtgärder som val av startnod eller uppgradering av primär nodtyp.

  • Ladda ned binärfiler. Uppgraderingstjänsten använder adressen download.microsoft.com för att hämta binärfilerna, den här relationen behövs för installation, omavbildning och körningsuppgraderingar. I scenariot med en "endast intern" lastbalanserare måste ytterligare en extern lastbalanserare läggas till med en regel som tillåter utgående trafik för port 443. Du kan också blockera den här porten efter en lyckad installation, men i det här fallet måste uppgraderingspaketet distribueras till noderna eller så måste porten öppnas under den korta tidsperioden, därefter krävs en manuell uppgradering.

Använd Azure Firewall med NSG-flödesloggen och trafikanalys för att spåra anslutningsproblem. ARM-mallen Service Fabric med NSG är ett bra exempel att starta.

Kommentar

Standardreglerna för nätverkssäkerhet bör inte skrivas över eftersom de säkerställer kommunikationen mellan noderna. Nätverkssäkerhetsgrupp – Så här fungerar den. Ett annat exempel är utgående anslutning på port 80 som krävs för att kontrollera listan över återkallade certifikat.

Vanliga scenarier som behöver ytterligare regler

Alla ytterligare scenarier kan omfattas av Azure-tjänsttaggar.

Azure DevOps

De klassiska PowerShell-uppgifterna i Azure DevOps (tjänsttagg: AzureCloud) behöver klient-API-åtkomst till klustret, exempel är programdistributioner eller operativa uppgifter. Detta gäller inte endast ARM-mallar, inklusive ARM-programresurser.

Prioritet Namn Port Protokoll Källa Mål Action Riktning
3915 Azure DevOps 19000 TCP AzureCloud Alla Tillåt Inkommande

Uppdatera Windows

Bästa praxis för att korrigera Windows-operativsystemet är att ersätta OS-disken med automatiska os-avbildningsuppgraderingar, ingen ytterligare regel krävs. Patch Orchestration-programmet hanterar uppgraderingar på den virtuella datorn där Windows Uppdateringar tillämpar operativsystemkorrigeringar. Detta behöver åtkomst till Download Center (tjänsttagg: AzureUpdateDelivery) för att ladda ned uppdateringsbinärfilerna.

Prioritet Namn Port Protokoll Källa Mål Action Riktning
4015 Windows-uppdateringar 443 TCP Alla AzureUpdateDelivery Tillåt Utgående

API Management

Integreringen av Azure API Management (tjänsttagg: ApiManagement) behöver klient-API-åtkomst för att fråga efter slutpunktsinformation från klustret.

Prioritet Namn Port Protokoll Källa Mål Action Riktning
3920 API Management 19080 TCP ApiManagement Alla Tillåt Inkommande

Programnätverk

  • Om du vill köra Windows-containerarbetsbelastningar använder du öppet nätverksläge för att underlätta kommunikation mellan tjänster.

  • Använd en omvänd proxy, till exempel Traefik eller omvänd Service Fabric-proxy för att exponera vanliga programportar som 80 eller 443.

  • För Windows-containrar som finns på luftgapade datorer som inte kan hämta baslager från Azure-molnlagring åsidosätter du beteendet för främmande lager med hjälp av flaggan --allow-nondistributable-artifacts i Docker-daemon.

Nästa steg