Anslutningslägen och krav
I den här artikeln beskrivs de anslutningslägen som är tillgängliga för Azure Arc-aktiverade datatjänster och deras respektive krav.
Anslutningslägen
Det finns flera alternativ för graden av anslutning från din Azure Arc-aktiverade datatjänstmiljö till Azure. Eftersom dina krav varierar beroende på affärspolicy, myndighetsreglering eller tillgängligheten för nätverksanslutning till Azure kan du välja mellan följande anslutningslägen.
Med Azure Arc-aktiverade datatjänster kan du ansluta till Azure i två olika anslutningslägen:
- Direktansluten
- Indirekt ansluten
Anslutningsläget ger dig flexibiliteten att välja hur mycket data som skickas till Azure och hur användarna interagerar med Arc-datastyrenheten. Beroende på vilket anslutningsläge som väljs kan vissa funktioner i Azure Arc-aktiverade datatjänster vara tillgängliga eller inte.
Om Azure Arc-aktiverade datatjänster är direkt anslutna till Azure kan användarna använda Azure Resource Manager-API:er, Azure CLI och Azure Portal för att använda Azure Arc-datatjänsterna. Upplevelsen i direkt anslutet läge liknar hur du skulle använda andra Azure-tjänster med etablering/avetablering, skalning, konfiguration och så vidare, allt i Azure Portal. Om Azure Arc-aktiverade datatjänster indirekt är anslutna till Azure är Azure Portal en skrivskyddad vy. Du kan se inventeringen av SQL-hanterade instanser och PostgreSQL-servrar som du har distribuerat och information om dem, men du kan inte vidta åtgärder på dem i Azure Portal. I det indirekt anslutna läget måste alla åtgärder vidtas lokalt med hjälp av Azure Data Studio, lämpliga CLI- eller Kubernetes-inbyggda verktyg som kubectl.
Dessutom kan Microsoft Entra-ID och rollbaserad åtkomstkontroll i Azure endast användas i direkt anslutet läge eftersom det finns ett beroende av en kontinuerlig och direkt anslutning till Azure för att tillhandahålla den här funktionen.
Vissa Azure-anslutna tjänster är bara tillgängliga när de kan nås direkt, till exempel Container Insights och säkerhetskopiering till bloblagring.
| Indirekt ansluten | Direktansluten | Anslut aldrig | |
|---|---|---|---|
| Beskrivning | Indirekt anslutet läge erbjuder de flesta hanteringstjänster lokalt i din miljö utan direkt anslutning till Azure. En minimal mängd data måste skickas till Azure endast i inventerings- och faktureringssyfte. Den exporteras till en fil och laddas upp till Azure minst en gång per månad. Ingen direkt eller kontinuerlig anslutning till Azure krävs. Vissa funktioner och tjänster som kräver en anslutning till Azure är inte tillgängliga. | Direktanslutet läge erbjuder alla tillgängliga tjänster när en direktanslutning kan upprättas med Azure. Anslutningar initieras alltid från din miljö till Azure och använder standardportar och protokoll som HTTPS/443. | Inga data kan skickas till eller från Azure på något sätt. |
| Aktuell tillgänglighet | Tillgängligt | Tillgängligt | Stöds inte för närvarande. |
| Vanliga användningsfall | Lokala datacenter som inte tillåter anslutning till eller från dataområdet i datacentret på grund av affärs- eller regelefterlevnadsprinciper eller av problem med externa attacker eller dataexfiltrering. Typiska exempel: Finansiella institutioner, hälsovård, myndigheter. Edge-platsplatser där gränsplatsen vanligtvis inte har anslutning till Internet. Typiska exempel: olje-/gas- eller militärfälttillämpningar. Gränsplatsplatser som har tillfälliga anslutningar med långa perioder av avbrott. Typiska exempel: arenor, kryssningsfartyg. |
Organisationer som använder offentliga moln. Vanliga exempel: Azure, AWS eller Google Cloud. Edge-platsplatser där Internetanslutning vanligtvis finns och tillåts. Vanliga exempel: butiker, tillverkning. Företagsdatacenter med mer tillåtande principer för anslutning till/från dataområdet i datacentret till Internet. Vanliga exempel: Icke-reglerade företag, små och medelstora företag |
Verkligt "luftgapade" miljöer där inga data under några omständigheter kan komma eller gå från datamiljön. Typiska exempel: topphemliga statliga anläggningar. |
| Så här skickas data till Azure | Det finns tre alternativ för hur fakturerings- och inventeringsdata kan skickas till Azure: 1) Data exporteras från dataregionen genom en automatiserad process som har anslutning till både den säkra dataregionen och Azure. 2) Data exporteras från dataregionen genom en automatiserad process i dataregionen, kopieras automatiskt till en mindre säker region och en automatiserad process i den mindre säkra regionen laddar upp data till Azure. 3) Data exporteras manuellt av en användare i den säkra regionen, hämtas manuellt från den säkra regionen och laddas upp manuellt till Azure. De första två alternativen är en automatiserad kontinuerlig process som kan schemaläggas att köras ofta, så det finns minimal fördröjning i överföringen av data till Azure som endast omfattas av den tillgängliga anslutningen till Azure. |
Data skickas automatiskt och kontinuerligt till Azure. | Data skickas aldrig till Azure. |
Funktionstillgänglighet efter anslutningsläge
| Funktion | Indirekt ansluten | Direktansluten |
|---|---|---|
| Automatisk hög tillgänglighet | Stöds | Stöds |
| Självbetjäningsetablering | Stöds Använd Azure Data Studio, lämpliga CLI- eller Kubernetes-inbyggda verktyg som Helm, kubectleller , eller ocanvänd Azure Arc-aktiverad Kubernetes GitOps-etablering. |
Stöds Förutom alternativen för att skapa indirekt anslutet läge kan du även skapa via Azure Portal, Azure Resource Manager-API:er, Azure CLI- eller ARM-mallar. |
| Elastisk skalbarhet | Stöds | Stöds |
| Billing | Stöds Faktureringsdata exporteras regelbundet och skickas till Azure. |
Stöds Faktureringsdata skickas automatiskt och kontinuerligt till Azure och återspeglas nästan i realtid. |
| Lagerhantering | Stöds Inventeringsdata exporteras regelbundet ut och skickas till Azure. Använd klientverktyg som Azure Data Studio, Azure Data CLI eller kubectl för att visa och hantera inventering lokalt. |
Stöds Inventeringsdata skickas automatiskt och kontinuerligt till Azure och återspeglas nästan i realtid. Därför kan du hantera inventeringen direkt från Azure Portal. |
| Automatiska uppgraderingar och korrigeringar | Stöds Datakontrollanten måste antingen ha direkt åtkomst till Microsoft Container Registry (MCR) eller så måste containeravbildningarna hämtas från MCR och skickas till ett lokalt, privat containerregister som datakontrollanten har åtkomst till. |
Stöds |
| Automatisk säkerhetskopiering och återställning | Stöds Automatisk lokal säkerhetskopiering och återställning. |
Stöds Förutom automatisk lokal säkerhetskopiering och återställning kan du även skicka säkerhetskopior till Azure Blob Storage för långsiktig kvarhållning utanför platsen. |
| Övervakning | Stöds Lokal övervakning med hjälp av Grafana- och Kibana-instrumentpaneler. |
Stöds Förutom lokala övervakningsinstrumentpaneler kan du även skicka övervakningsdata och loggar till Azure Monitor för att övervaka flera platser i stor skala på ett och samma ställe. |
| Autentisering | Använd lokalt användarnamn/lösenord för datakontrollant och instrumentpanelsautentisering. Använd SQL- och Postgres-inloggningar eller Active Directory (AD stöds inte för närvarande) för anslutning till databasinstanser. Använd Kubernetes-autentiseringsprovidrar för autentisering till Kubernetes-API:et. | Förutom eller i stället för autentiseringsmetoderna för det indirekt anslutna läget kan du också använda Microsoft Entra-ID. |
| Rollbaserad åtkomstkontroll (RBAC) | Använd Kubernetes RBAC i Kubernetes API. Använd SQL och Postgres RBAC för databasinstanser. | Du kan använda Microsoft Entra ID och Azure RBAC. |
Anslutningskrav
Vissa funktioner kräver en anslutning till Azure.
All kommunikation med Azure initieras alltid från din miljö. Detta gäller även för åtgärder som initieras av en användare i Azure Portal. I så fall finns det i praktiken en uppgift som står i kö i Azure. En agent i din miljö initierar kommunikationen med Azure för att se vilka uppgifter som finns i kön, kör uppgifterna och rapporterar tillbaka status/slutförande/misslyckas till Azure.
| Typ av data | Riktning | Obligatoriskt/valfritt | Tilläggskostnader | Läge krävs | Anteckningar |
|---|---|---|---|---|---|
| Containeravbildningar | Microsoft Container Registry –> kund | Obligatoriskt | Nej | Indirekt eller direkt | Containeravbildningar är metoden för att distribuera programvaran. I en miljö som kan ansluta till Microsoft Container Registry (MCR) via Internet kan containeravbildningarna hämtas direkt från MCR. Om distributionsmiljön inte har någon direkt anslutning kan du hämta avbildningarna från MCR och skicka dem till ett privat containerregister i distributionsmiljön. När du skapar kan du konfigurera skapandeprocessen så att den hämtas från det privata containerregistret i stället för MCR. Detta gäller även för automatiserade uppdateringar. |
| Resursinventering | Kundmiljö –> Azure | Obligatoriskt | Nej | Indirekt eller direkt | En inventering av datakontrollanter, databasinstanser (PostgreSQL och SQL) sparas i Azure i faktureringssyfte och även för att skapa en inventering av alla datakontrollanter och databasinstanser på ett ställe som är särskilt användbart om du har mer än en miljö med Azure Arc-datatjänster. När instanser etableras, avetableras, skalas ut/in, skalas upp/ned uppdateras inventeringen i Azure. |
| Telemetridata för fakturering | Kundmiljö –> Azure | Obligatoriskt | Nej | Indirekt eller direkt | Användning av databasinstanser måste skickas till Azure i faktureringssyfte. |
| Övervaka data och loggar | Kundmiljö –> Azure | Valfritt | Kanske beroende på datavolym (se Priser för Azure Monitor) | Indirekt eller direkt | Du kanske vill skicka lokalt insamlade övervakningsdata och loggar till Azure Monitor för att aggregera data i flera miljöer på en plats och även använda Azure Monitor-tjänster som aviseringar, med hjälp av data i Azure Machine Learning osv. |
| Rollbaserad åtkomstkontroll i Azure (Azure RBAC) | Kundmiljö –> Azure –> Kundmiljö | Valfritt | Nej | Endast direkt | Om du vill använda Azure RBAC måste anslutningen upprättas med Azure hela tiden. Om du inte vill använda Azure RBAC kan lokala Kubernetes RBAC användas. |
| Microsoft Entra-ID (framtid) | Kundmiljö –> Azure –> Kundmiljö | Valfritt | Kanske, men du kanske redan betalar för Microsoft Entra-ID | Endast direkt | Om du vill använda Microsoft Entra-ID för autentisering måste anslutningen upprättas med Azure hela tiden. Om du inte vill använda Microsoft Entra-ID för autentisering kan du använda Active Directory Federation Services (AD FS) (ADFS) via Active Directory. Väntar på tillgänglighet i direkt anslutet läge |
| Säkerhetskopiering och återställning | Kundmiljö –> Kundmiljö | Obligatoriskt | Nej | Direkt eller indirekt | Säkerhetskopierings- och återställningstjänsten kan konfigureras för att peka på lokala lagringsklasser. |
| Azure-säkerhetskopiering – långsiktig kvarhållning (framtid) | Kundmiljö –> Azure | Valfritt | Ja för Azure Storage | Endast direkt | Du kanske vill skicka säkerhetskopior som tas lokalt till Azure Backup för långsiktig kvarhållning av säkerhetskopior utanför platsen och föra dem tillbaka till den lokala miljön för återställning. |
| Etablerings- och konfigurationsändringar från Azure Portal | Kundmiljö –> Azure –> Kundmiljö | Valfritt | Nej | Endast direkt | Etablerings- och konfigurationsändringar kan göras lokalt med hjälp av Azure Data Studio eller lämpligt CLI. I direkt anslutet läge kan du även etablera och göra konfigurationsändringar från Azure Portal. |
Information om internetadresser, portar, kryptering och proxyserverstöd
| Tjänst | Port | URL | Riktning | Anteckningar |
|---|---|---|---|---|
| Helm-diagram (endast direktanslutet läge) | 443 | arcdataservicesrow1.azurecr.io |
Utgående | Etablerar Azure Arc-datastyrenhetens bootstrapper- och klusternivåobjekt, till exempel anpassade resursdefinitioner, klusterroller och klusterrollbindningar, hämtas från ett Azure Container Registry. |
| Api:er för Azure Monitor 1 | 443 | *.ods.opinsights.azure.com*.oms.opinsights.azure.com*.monitoring.azure.com |
Utgående | Azure Data Studio och Azure CLI ansluter till Azure Resource Manager-API:erna för att skicka och hämta data till och från Azure för vissa funktioner. Se Azure Monitor-API:er. |
| Azure Arc-databehandlingstjänst 1 | 443 | *.<region>.arcdataservices.com 2 |
Utgående |
1 Krav beror på distributionsläge:
- För direktläge måste kontrollantpodden i Kubernetes-klustret ha utgående anslutning till slutpunkterna för att skicka loggar, mått, inventering och faktureringsinformation till Azure Monitor/Data Processing Service.
- För indirekt läge måste den dator som körs
az arcdata dc uploadha den utgående anslutningen till Azure Monitor och Data Processing Service.
2 För tilläggsversioner fram till och med den 13 februari 2024 använder du san-af-<region>-prod.azurewebsites.net.
Azure Monitor-API:er
Anslutning från Azure Data Studio till Kubernetes API-servern använder Kubernetes-autentiseringen och krypteringen som du har upprättat. Varje användare som använder Azure Data Studio eller CLI måste ha en autentiserad anslutning till Kubernetes-API:et för att utföra många av de åtgärder som rör Azure Arc-aktiverade datatjänster.
Ytterligare nätverkskrav
Dessutom kräver resursbryggan Arc-aktiverade Kubernetes-slutpunkter.