Konfigurera lagring för Azure Application Consistent Snapshot-verktyget
Artikel
Den här artikeln innehåller en guide för att konfigurera Azure Storage som ska användas med verktyget Azure Application Consistent Snapshot (AzAcSnap).
Konfigurera antingen en systemhanterad identitet (rekommenderas) eller generera tjänstens huvudnamns autentiseringsfil.
När du validerar kommunikationen med Azure NetApp Files kan kommunikationen misslyckas eller överskrida tidsgränsen. Kontrollera att brandväggsregler inte blockerar utgående trafik från systemet som kör AzAcSnap till följande adresser och TCP/IP-portar:
(https://)management.azure.com:443
(https://)login.microsoftonline.com:443
Du måste generera ett eget självsignerat certifikat och sedan dela innehållet i PEM-filen (Privacy Enhanced Mail) med Microsoft Operations så att det kan installeras på lagringsserverdelen så att AzAcSnap kan autentiseras säkert med ONTAP.
Kombinera PEM och KEY till en enda PKCS12-fil som krävs av AzAcSnap för certifikatbaserad autentisering till ONTAP.
Testa PKCS12-filen med hjälp curl av för att ansluta till en av noderna.
Microsoft Operations tillhandahåller lagringsanvändar- och lagrings-IP-adressen vid tidpunkten för etableringen.
Aktivera kommunikation med lagring
I det här avsnittet beskrivs hur du aktiverar kommunikation med lagring. Använd följande flikar för att korrekt välja den lagringsserverdel som du använder.
Det finns två sätt att autentisera till Azure Resource Manager med antingen en systemhanterad identitet eller en tjänsthuvudnamnsfil. Alternativen beskrivs här.
Systemhanterad identitet i Azure
Från AzAcSnap 9 är det möjligt att använda en systemhanterad identitet i stället för ett huvudnamn för tjänsten för drift. Med den här funktionen undviker du behovet av att lagra autentiseringsuppgifter för tjänstens huvudnamn på en virtuell dator (VM). Följ dessa steg för att konfigurera en hanterad Azure-identitet med hjälp av Azure Cloud Shell:
I en Cloud Shell-session med Bash använder du följande exempel för att ange gränssnittsvariablerna på rätt sätt och tillämpa dem på den prenumeration där du vill skapa den hanterade Azure-identiteten. Ange SUBSCRIPTION, VM_NAMEoch RESOURCE_GROUP till dina platsspecifika värden.
Skapa den hanterade identiteten för den virtuella datorn. Följande kommandouppsättningar (eller visar om den redan har angetts) den virtuella AzAcSnap-datorns hanterade identitet:
az vm identity assign --name "${VM_NAME}" --resource-group "${RESOURCE_GROUP}"
Hämta huvud-ID:t för att tilldela en roll:
PRINCIPAL_ID=$(az resource list -n ${VM_NAME} --query [*].identity.principalId --out tsv)
Tilldela rollen Deltagare till huvud-ID:t:
az role assignment create --assignee "${PRINCIPAL_ID}" --role "${ROLE}" --scope "${SCOPE}"
Valfri RBAC
Det går att begränsa behörigheterna för den hanterade identiteten med hjälp av en anpassad rolldefinition i rollbaserad åtkomstkontroll (RBAC). Skapa en lämplig rolldefinition för den virtuella datorn för att kunna hantera ögonblicksbilder. Du hittar exempel på behörighetsinställningar i Tips och råd om hur du använder verktyget Azure Application Consistent Snapshot.
Tilldela sedan rollen till huvud-ID:t för den virtuella Azure-datorn (visas även som SystemAssignedIdentity):
az role assignment create --assignee ${PRINCIPAL_ID} --role "AzAcSnap on ANF" --scope "${SCOPE}"
Generera en tjänsthuvudnamnsfil
I en Cloud Shell-session kontrollerar du att du är inloggad på den prenumeration där du vill associeras med tjänstens huvudnamn som standard:
az account show
Om prenumerationen inte är korrekt använder du az account set kommandot:
az account set -s <subscription name or id>
Skapa ett huvudnamn för tjänsten med hjälp av Azure CLI, som du ser i det här exemplet:
az ad sp create-for-rbac --name "AzAcSnap" --role Contributor --scopes /subscriptions/{subscription-id} --sdk-auth
Kommandot bör generera utdata som det här exemplet:
Det här kommandot tilldelar automatiskt rollen RBAC-deltagare till tjänstens huvudnamn på prenumerationsnivå. Du kan begränsa omfånget till den specifika resursgrupp där dina tester skapar resurserna.
Klipp ut och klistra in utdatainnehållet i en fil med namnet azureauth.json som lagras i samma system som azacsnap kommandot. Skydda filen med lämpliga systembehörigheter.
Kontrollera att JSON-filens format är exakt enligt beskrivningen i föregående steg, med URL:erna omgivna inom dubbla citattecken (").
Viktigt!
Från AzAcSnap 10 använder kommunikationen med Azure Large Instance Storage REST API via HTTPS. Versioner före AzAcSnap 10 använder CLI via SSH.
Rest-API för Azure Large Instance via HTTPS
Kommunikation med lagringsserverdelen sker via en krypterad HTTPS-kanal med hjälp av certifikatbaserad autentisering. Följande exempelsteg ger vägledning om hur du konfigurerar PKCS12-certifikatet för den här kommunikationen:
Generera PEM- och KEY-filerna.
CN är lika med SVM-användarnamnet och ber Microsoft Operations om det här SVM-användarnamnet.
I det här exemplet använder svmadmin01 vi som svm-användarnamn och ändrar detta efter behov för din installation.
Generating a RSA private key
........................................................................................................+++++
....................................+++++
writing new private key to 'svmadmin01.key'
-----
Mata ut innehållet i PEM-filen.
Innehållet i PEM-filen används för att lägga till klientcertifikatet i SVM.
! Skicka innehållet i PEM-filen till administratören för Microsoft BareMetal Infrastructure (BMI).
Filen svmadmin01.p12 används som värde för certificateFile i avsnittet aliStorageResource i AzAcSnap-konfigurationsfilen.
Testa PKCS12-filen med curl.
När de har fått bekräftelse från Microsoft Operations har de tillämpat certifikatet på SVM för att tillåta certifikatbaserad inloggning och sedan testa anslutningen till SVM.
I det här exemplet använder vi PKCS12-filen svmadmin01.p12 för att ansluta till SVM-värden "X.X.X.X" (den här IP-adressen tillhandahålls av Microsoft Operations).
Dessa instruktioner gäller för versioner före AzAcSnap 10 och vi uppdaterar inte längre det här avsnittet av innehållet regelbundet.
Kommunikation med lagringsserverdelen sker via en krypterad SSH-kanal. Följande exempelsteg ger vägledning om hur du konfigurerar SSH för den här kommunikationen:
Ändra filen /etc/ssh/ssh_config.
Se följande utdata, som innehåller MACs hmac-sha raden:
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# GSSAPIKeyExchange no
# GSSAPITrustDNS no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
Protocol 2
# Cipher 3des
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-
cbc
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd
MACs hmac-sha
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
Använd följande exempelkommando för att generera ett privat/offentligt nyckelpar. Ange inget lösenord när du genererar en nyckel.
ssh-keygen -t rsa –b 5120 -C ""
Kommandots cat /root/.ssh/id_rsa.pub utdata är den offentliga nyckeln. Skicka det till Microsoft Operations så att verktygen för ögonblicksbilder kan kommunicera med lagringsundersystemet.