Skapa en Azure Batch-pool i ett virtuellt nätverk
När du skapar en Azure Batch-pool kan du etablera poolen i ett undernät för ett virtuellt Azure-nätverk som du anger. Den här artikeln beskriver hur du konfigurerar en Batch-pool i ett virtuellt nätverk.
Varför ska jag använda ett virtuellt nätverk?
Beräkningsnoder i en pool kan kommunicera med varandra, till exempel för att köra uppgifter med flera instanser, utan att det krävs ett separat virtuellt nätverk. Noder i en pool kan dock som standard inte kommunicera med någon virtuell dator (VM) som ligger utanför poolen, till exempel licens- eller filservrar.
Om du vill tillåta att beräkningsnoder kommunicerar säkert med andra virtuella datorer, eller med ett lokalt nätverk, kan du etablera poolen i ett undernät i ett virtuellt nätverk.
Förutsättningar
Autentisering. Om du vill använda ett virtuellt Azure-nätverk måste Batch-klient-API:et använda Microsoft Entra-autentisering. Mer information finns i Autentisera Batch-tjänstlösningar med Active Directory.
Ett virtuellt Azure-nätverk. Om du vill förbereda ett virtuellt nätverk med ett eller flera undernät i förväg kan du använda Azure-portalen, Azure PowerShell, Microsoft Azure CLI (CLI) eller andra metoder.
Information om hur du skapar ett Azure Resource Manager-baserat virtuellt nätverk finns i Skapa ett virtuellt nätverk. Ett Resource Manager-baserat virtuellt nätverk rekommenderas för nya distributioner och stöds endast för pooler som använder Konfiguration av virtuella datorer.
Information om hur du skapar ett klassiskt virtuellt nätverk finns i Skapa ett virtuellt nätverk (klassiskt) med flera undernät. Ett klassiskt virtuellt nätverk stöds endast i pooler som använder Cloud Services Configuration.
Viktigt!
Undvik att använda 172.17.0.0/16 för virtuella Azure Batch-poolnätverk. Det är standardvärdet för Docker-bryggnätverket och kan vara i konflikt med andra nätverk som du vill ansluta till det virtuella nätverket. Att skapa ett virtuellt nätverk för Azure Batch-poolen kräver noggrann planering av nätverksinfrastrukturen.
Allmänna krav för virtuella nätverk
Det virtuella nätverket måste finnas i samma prenumeration och region som det Batch-konto som du använder för att skapa din pool.
Det undernät som anges för poolen måste ha tillräckligt med otilldelade IP-adresser för att hantera antalet virtuella datorer som är mål för poolen, tillräckligt för att rymma
targetDedicatedNodes
poolens egenskaper ochtargetLowPriorityNodes
egenskaper. Om undernätet inte har tillräckligt med lediga IP-adresser, allokerar poolen datornoderna partiellt och ett storleksändringsfel inträffar.Om du inte använder förenklad beräkningsnodkommunikation måste du lösa dina Azure Storage-slutpunkter med hjälp av anpassade DNS-servrar som betjänar ditt virtuella nätverk. Mer specifikt, ska URL:er av formen
<account>.table.core.windows.net
,<account>.queue.core.windows.net
och<account>.blob.core.windows.net
vara matchningsbara.Flera pooler kan skapas i samma virtuella nätverk eller i samma undernät (så länge det har tillräckligt med adressutrymme). En enda pool kan inte finnas i flera virtuella nätverk eller undernät.
Viktigt!
Batchpooler kan konfigureras i något av två nodkommunikationslägen. I det klassiska nodkommunikationsläget initierar Batch-tjänsten kommunikation till beräkningsnoderna. Förenklat nodkommunikationsläge är där beräkningsnoderna initierar kommunikation till Batch-tjänsten.
- Ett virtuellt nätverk eller peer-kopplat virtuellt nätverk som ska användas för Batch-pooler bör inte ha överlappande IP-adressintervall med programvarudefinierade nätverk eller routning på beräkningsnoder. En vanlig källa för konflikter är användningen av en containerkörning, till exempel docker. Docker skapar en standardnätverksbrygga med ett definierat undernätsintervall på
172.17.0.0/16
. Tjänster som körs i ett virtuellt nätverk i det standard-IP-adressutrymmet står i konflikt med tjänster på beräkningsnoden, till exempel fjärråtkomst via SSH.
Pooler i konfiguration av virtuell dator
Krav:
- Virtuella nätverk som stöds: Endast Azure Resource Manager-baserade virtuella nätverk.
- Undernäts-ID: När du anger undernätet med hjälp av Batch-API:erna använder du resursidentifieraren för undernätet. Undernät-ID har formatet:
/subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.Network/virtualNetworks/{network}/subnets/{subnet}
- Behörigheter: Kontrollera om dina säkerhetsprinciper eller lås på det virtuella nätverkets prenumeration eller resursgrupp begränsar en användares behörighet att hantera det virtuella nätverket.
- Nätverksresurser: Batch skapar automatiskt fler nätverksresurser i resursgruppen som innehåller det virtuella nätverket.
Viktigt!
För varje 100 dedikerade noder eller lågprioriterade noder skapar Batch en nätverkssäkerhetsgrupp (NSG), en offentlig IP-adress och en lastbalanserare. Dessa resurser begränsas av prenumerationens resurskvoter. För stora pooler kan du behöva begära en kvotökning för en eller flera av dessa resurser.
Nätverkssäkerhetsgrupper för konfigurationspooler för virtuella datorer: Batch-standard
Batch skapar en nätverkssäkerhetsgrupp (NSG) på nätverksgränssnittsnivå för varje distribution av vm-skalningsuppsättningar i en Batch-pool. För pooler som inte har offentliga IP-adresser under kommunikation med simplified
beräkningsnoder skapas inte NSG:er.
För att tillhandahålla nödvändig kommunikation mellan beräkningsnoder och Batch-tjänsten konfigureras dessa NSG:er så att:
- Inkommande TCP-trafik på portarna 29876 och 29877 från Batch-tjänstens IP-adresser som motsvarar BatchNodeManagement.regiontjänsttagg . Den här regeln skapas endast i
classic
poolkommunikationsläge. - Inkommande TCP-trafik på port 22 (Linux-noder) eller port 3389 (Windows-noder) för att tillåta fjärråtkomst för SSH respektive RDP på standardportar. För vissa typer av aktiviteter med flera instanser i Linux, till exempel MPI, kan du behöva tillåta SSH-trafik för IP-adresser i undernätet som innehåller Batch-beräkningsnoder. Vissa MPI-körningar kan kräva start via SSH, som vanligtvis dirigeras på privat IP-adressutrymme. Den här trafiken kan blockeras enligt NSG-regler på undernätsnivå.
- Utgående trafik på port 443 till Batch-tjänstens IP-adresser som motsvarar BatchNodeManagement.regiontjänsttagg .
- Utgående trafik på vilken port som helst till det virtuella nätverket. Den här regeln kan ändras per NSG-regler på undernätsnivå.
- Utgående trafik på vilken port som helst till Internet. Den här regeln kan ändras per NSG-regler på undernätsnivå.
Viktigt!
Var försiktig om du ändrar eller lägger till regler för inkommande eller utgående trafik i Batch-konfigurerade NSG:er. Om kommunikationen till beräkningsnoderna i det angivna undernätet nekas av en NSG anger Batch-tjänsten tillståndet för beräkningsnoderna till oanvändbart. Dessutom bör inga resurslås tillämpas på resurser som skapats av Batch, eftersom detta kan förhindra rensning av resurser till följd av användarinitierade åtgärder som att ta bort en pool.
Nätverkssäkerhetsgrupper för konfigurationspooler för virtuella datorer: Ange regler på undernätsnivå
Om du har en NSG som är associerad med undernätet för Batch-beräkningsnoder måste du konfigurera den här NSG:n med minst de inkommande och utgående säkerhetsreglerna som visas i följande tabeller.
Varning
Batch-tjänstens IP-adresser kan ändras över tid. Därför bör du använda BatchNodeManagement.regiontjänsttagg för NSG-reglerna som anges i följande tabeller. Undvik att fylla I NSG-regler med specifika IP-adresser för Batch-tjänsten.
Säkerhetsregler för inkommande trafik
Konfigurera inkommande trafik på port 3389 (Windows) eller 22 (Linux) endast om du behöver tillåta fjärråtkomst till beräkningsnoderna från externa källor på standard-RDP- respektive SSH-portar. Du kan behöva tillåta SSH-trafik på Linux om du behöver stöd för aktiviteter med flera instanser med vissa MPI-körningar (Message Passing Interface) i undernätet som innehåller Batch-beräkningsnoderna eftersom trafiken kan blockeras enligt NSG-regler på undernätsnivå. MPI-trafik är vanligtvis över privat IP-adressutrymme, men kan variera mellan MPI-körningar och körningskonfiguration. Det är inte absolut nödvändigt att tillåta trafik på dessa portar för att poolberäkningsnoderna ska kunna användas. Du kan också inaktivera standard fjärråtkomst på dessa portar genom att konfigurera poolslutpunkter.
Utgående säkerhetsregler
Måltjänsttagg | Målportar | Protokoll | Kommunikationsläge för pool | Obligatoriskt |
---|---|---|---|---|
BatchNodeManagement.regiontjänsttagg | 443 | * | Förenklad | Ja |
Lagring.regiontjänsttagg | 443 | TCP | Klassisk | Ja |
Utgående till BatchNodeManagement.regiontjänsttaggen krävs i classic
poolkommunikationsläge om du använder Job Manager-uppgifter eller om dina uppgifter måste kommunicera tillbaka till Batch-tjänsten. För utgående till BatchNodeManagement.region i simplified
poolkommunikationsläge använder Batch-tjänsten för närvarande endast TCP-protokoll, men UDP kan krävas för framtida kompatibilitet. För pooler utan offentliga IP-adresser med kommunikationsläge simplified
och med en privat slutpunkt för nodhantering behövs ingen NSG. Mer information om utgående säkerhetsregler för BatchNodeManagement.regiontjänsttagg , se Använda förenklad kommunikation med beräkningsnoder.
Skapa en pool med ett virtuellt nätverk i Azure-portalen
När du har skapat ditt virtuella nätverk och tilldelat det ett undernät kan du skapa en Batch-pool med det virtuella nätverket. Följ de här stegen för att skapa en pool från Azure-portalen:
Sök efter och välj Batch-konton i sökfältet överst i Azure-portalen. Välj ditt Batch-konto. Det här kontot måste finnas i samma prenumeration och region som resursgruppen som innehåller det virtuella nätverk som du tänker använda.
Välj Pooler i det vänstra navigeringsfältet.
I fönstret Pooler väljer du Lägg till.
På sidan Lägg till pool väljer du alternativen och anger informationen för poolen. Mer information om hur du skapar pooler för ditt Batch-konto finns i Skapa en pool med beräkningsnoder. Nodstorlek, dedikerade målnoder och noder med målplats/låg prioritet samt valfria inställningar.
I Virtuellt nätverk väljer du det virtuella nätverk och undernät som du vill använda.
Välj OK för att skapa poolen.
Viktigt!
Om du försöker ta bort ett undernät som används av en pool får du ett felmeddelande. Alla pooler som använder ett undernät måste tas bort innan du tar bort undernätet.
Användardefinierade vägar för tvingad tunneltrafik
Du kan ha krav i din organisation på att omdirigera (tvinga) internetbunden trafik från undernätet tillbaka till din lokala plats för inspektion och loggning. Dessutom kan du ha aktiverat tvingad tunneltrafik för undernäten i ditt virtuella nätverk.
För att säkerställa att noderna i poolen fungerar i ett virtuellt nätverk som har aktiverat tvingad tunneltrafik måste du lägga till följande användardefinierade vägar (UDR) för det undernätet.
För klassiska kommunikationslägespooler:
Batch-tjänsten måste kommunicera med noder för schemaläggning av uppgifter. Om du vill aktivera den här kommunikationen lägger du till en UDR som motsvarar BatchNodeManagement.regiontjänsttagg i den region där batchkontot finns. Ange Typen Nästa hopp till Internet.
Kontrollera att ditt lokala nätverk inte blockerar utgående TCP-trafik till Azure Storage på målport 443 (särskilt URL:er i formuläret
*.table.core.windows.net
,*.queue.core.windows.net
och*.blob.core.windows.net
).
För förenklade kommunikationslägespooler utan att använda en privat slutpunkt för nodhantering:
- Kontrollera att ditt lokala nätverk inte blockerar utgående TCP/UDP-trafik till Azure Batch BatchNodeManagement.regiontjänsttagg på målport 443. För närvarande används endast TCP-protokoll, men UDP kan krävas för framtida kompatibilitet.
För alla pooler:
- Om du använder virtuella filmonteringar granskar du nätverkskraven och ser till att ingen nödvändig trafik blockeras.
Varning
Batch-tjänstens IP-adresser kan ändras över tid. Om du vill förhindra avbrott på grund av ändringar i Batch-tjänstens IP-adress anger du inte IP-adresser direkt. Använd i stället BatchNodeManagement.regiontjänsttagg.