Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Azure NetApp Files REST API för objekt möjliggör objektbaserad åtkomst till data som lagras i Azure NetApp Files volymer. Med den här funktionen kan program komma åt samma datauppsättning med både filbaserade protokoll (NFS/SMB) och objekt-API:er (S3-kompatibla) utan att duplicera eller migrera data.
Med den här enhetliga åtkomstmodellen kan befintliga filbaserade data användas direkt i analys-, AI- och moderna programarbetsflöden utan att det krävs separata lagringssystem, lösningar för dataöversättning eller datakopior.
Viktiga begrepp
Buckets
En bucket representerar en mappad vy av en katalog i en volym och fungerar som startpunkt för objektbaserad åtkomst.
- Hinkar är kopplade till volymer.
- Om du tar bort en volym tas dess tillhörande lagringsbehållare bort permanent.
Objekt
Varje fil i den mappade kataloghierarkin representeras som ett objekt.
- Objektnamn härleds från filsökvägar i förhållande till den mappade katalogen.
- Objektåtgärder fungerar direkt på filinnehåll.
Så här fungerar REST-API:et för objekt
Azure NetApp Files mappar en katalog inom en volym till en objekt bucket, vilket gör det möjligt för program och tjänster som använder objektbaserade åtkomstmönster att interagera med filbaserade data.
- En katalogsökväg, inklusive volymens rot, kan göras tillgänglig som en bucket.
- Kataloger representeras som logiska prefix i en bucket.
- Varje fil representeras som ett objekt.
- Objektsökvägar motsvarar direkt filsystemsökvägar.
- Kataloggränser representeras med avgränsare
/. - Objektåtgärder kan läsa, skriva och räkna upp data.
- Objektåtgärder översätts till motsvarande filsystemåtgärder.
Den här mappningen gör det möjligt för program att använda objekt-API:er för att interagera med data som förblir lagrade som filer.
Översikt över arkitektur
Följande diagram illustrerar samtidig fil- och objektåtkomst till samma Azure NetApp Files datauppsättning:
I den här modellen:
- NAS-klienter och -program får åtkomst till data med hjälp av NFS eller SMB.
- Objektklienter får åtkomst till samma data via objektets REST API.
- Analys- och AI-tjänster (till exempel Azure Databricks, Microsoft Fabric och Azure AI services) integreras med Azure NetApp Files med hjälp av objektbaserad åtkomst.
- Data lagras i Azure NetApp Files-volymer.
Arbetsflöde för objektåtkomst
På en övergripande nivå följer åtkomst till objekt-REST-API:et detta flöde:
- En bucket skapas från en katalog inom en Azure NetApp Files volym.
- Program och tjänster ansluter med objektbaserade API:er.
- Objektåtgärder (till exempel läsning, skrivning och lista) översätts till filsystemåtgärder.
- Rest API för objekt autentiserar begäranden med hjälp av åtkomstnycklar och utvärderar filåtkomst med hjälp av den konfigurerade personifierade identiteten.
- Data returneras till klienten utan att dupliceras eller flyttas.
Det här arbetsflödet gör att program kan komma åt data med hjälp av objekt-API:er medan den underliggande lagringen fortsätter att fungera som ett filsystem.
Säkerhet och behörigheter
Object REST API introducerar behörigheter på bucketnivå, som är de primära åtkomstkontrollerna för Object REST API. Bucketkonfigurationen definierar också den filsystemsidentitet som används för att utge sig för att vara någon annan vid åtkomst till data via objekt-REST-API:t. Befintliga NAS-filbehörigheter fortsätter att tillämpas baserat på den personifierade identiteten.
- Behörigheter för lagringsbehållaren anger om klienter för objekt-REST API:t har skrivskyddad åtkomst eller läs- och skrivåtkomst till lagringsbehållaren.
- Autentiseringsidentitet och filsystemauktoriseringsidentitet är separata begrepp:
- S3-åtkomstnycklar autentiserar klienten till bucketen.
- Bucketens konfigurerade personifierade identitet avgör vilka filer och kataloger som kan nås.
- Varje bucket konfigureras med en personifierad filsystemidentitet:
- NFS-volymer använder ett användar-ID (UID) och grupp-ID (GID).
- SMB-volymer använder ett användarkonto.
- Volymer med dubbla protokoll använder antingen UID/GID eller användarkonton beroende på den konfigurerade säkerhetsstilen.
- Rest API för objekt begär åtkomst till data med hjälp av den konfigurerade personifierade identiteten. Standardfilbehörigheter och ACL:er på den Azure NetApp Files volymen fortsätter att tillämpas för den identiteten.
- Användare kan bara komma åt de filer och kataloger som den konfigurerade personifierade identiteten redan har behörighet att komma åt via standardbehörigheter för NFS eller SMB. Bucketåtkomst beviljar inte automatiskt åtkomst till alla objekt i den mappade katalogen eller volymen.
- Befintliga NAS-ACL:er och filbehörigheter är fortfarande auktoritativa för objekt-REST API-åtkomst. Rest-API:et för objekt kringgår eller ersätter inte befintliga NAS-åtkomstkontroller.
- Filåtkomst via SMB- och NFS-protokoll fortsätter att använda sina befintliga autentiserings- och auktoriseringsmodeller utan ändringar.
- Säker kommunikation med objektets REST API kräver TLS-certifikat som konfigurerats för objektets REST API-slutpunkt.
Åtgärder som stöds
- ListBucket
- ListObjects/ListObjectsV2
- Hämta objekt
- PutObject
- Ta bort objekt
- HeadObject
Vanliga scenarier
REST-API:et för objekt möjliggör nya arbetsbelastningsscenarier för Azure NetApp Files.
Dataanalys och AI
Ett datateknikteam måste analysera en stor datamängd som redan lagras i en Azure NetApp Files volym. I stället för att kopiera datamängden till en separat objektlagringstjänst ansluter teamet direkt med hjälp av objektbaserade verktyg och börjar bearbeta data på plats. Den här metoden möjliggör snabbare registrering av analysarbetsflöden samtidigt som lagringsduplicering minimeras.
Hybridprogram och moderniserade program
Program som kräver både filbaserad och objektbaserad åtkomst kan köras på samma datauppsättning utan att underhålla flera kopior. Detta möjliggör samexistens mellan äldre program och moderna tjänster, vilket möjliggör gradvis modernisering utan att störa befintliga arbetsbelastningar.
Databearbetningskedjor
Datapipelines kan mata in, transformera och bearbeta datauppsättningar med hjälp av objektbaserade verktyg medan data lagras i Azure NetApp Files. Detta stöder integrering med ett brett ekosystem av verktyg och tjänster som är beroende av objektbaserade åtkomstmönster.
Krav och överväganden
Tänk på följande krav och begränsningar när du använder rest-API:et för Azure NetApp Files-objektet:
- Bucketar är knutna till volymer och tas bort när volymen tas bort.
- Bucketar stöds med lågfrekvent åtkomst och stora volymer.
- Bucketar stöds inte på Azure NetApp Files-cachevolymer.
- Buckets kräver en volym med befintliga data. Tomma volymer stöds inte.
- Certifikatets livscykelhantering krävs för att upprätthålla säker åtkomst till objektets REST API-slutpunkt.
- Du ansvarar för att underhålla livscykeln för bucketcertifikat.
- Aktivera diagnostikloggning på alla Azure Key Vaults för att säkerställa att spårningsloggar är tillgängliga för säkerhetsundersökningar.
- Konfigurera listor över nätverksåtkomstkontroll (ACL: er) för att begränsa Azure Key Vault åtkomst till auktoriserade nätverk, inklusive virtuella NetApp-nätverk och auktoriserade virtuella kundnätverk.
- Överväg att använda separata Azure Key Vaults för certifikat och S3-autentiseringsuppgifter för att anpassa till säkerhetsrutiner med minst privilegier.
- Separera Azure Key Vault åtkomstprinciper för certifikat och S3-autentiseringsuppgifter, om möjligt, för att upprätthålla tydliga drifts- och säkerhetsgränser.
Note
Rest-API:et för objekt ger objektbaserad åtkomst till fildata men ändrar inte hur data lagras fysiskt. Objektbaserad åtkomst styrs av mekanismer för bucketkonfiguration och objektåtkomst, medan filåtkomst fortsätter att följa SMB- och NFS-behörighetsmodeller.