Levering til filshare

For nedstrøms systemer som leser filer fra et lokalt Windows-filsystem, for eksempel et fagsystem på en on-premises server, kan leveringen gå til en Azure Files-fildeling i stedet for droppsonen i Blob Storage. Azure File Sync replikerer fildelingen til deres Windows Server, slik at vedleggene dukker opp som vanlige filer i en lokal NTFS-mappe.

Navnekonvensjonen og .metadata.json-metadatafilen er identiske med droppsonen (se navnekonvensjonen). Nedstrøms systemer ser samme flate uansett hvilket leveringsmål utrullingen bruker. Hvert leveringsmål gjelder per utrulling: en tenant leverer enten til droppsonen eller til fildelingen, ikke begge.

Slik fungerer det

1. Workeren skriver vedlegget og metadatafilen til fildelingen med sin managed identity. Leveringsloggen registrerer Delivered når filen er skrevet til fildelingen.
2. Azure File Sync oppdager endringen og synkroniserer den ned til servermappen (server endpoint) på deres Windows Server.
3. Deres system leser filene fra den lokale mappen som fra et hvilket som helst filsystem.

Uten lagringsnøkler

Hele kjeden autentiserer med managed identities. Ingen lagringsnøkler, SAS-tokens eller connection strings finnes på deres server eller noe annet sted i løsningen:

Lagringskontoen har nøkkeltilgang avskrudd, så nøkkelbaserte tilganger er ikke bare ubrukte, de er umulige.

Leveringstakt

Delivered i leveringsloggen betyr at filen er skrevet til fildelingen. Videre transport til serveren går på File Syncs egen synkroniseringstakt: endringer skrevet direkte til fildelingen oppdages av en planlagt endringsdeteksjonsjobb som som standard kjører inntil én gang i døgnet. Trenger dere raskere fremover-propagering, kan driftspartneren trigge endringsdeteksjon på en hyppigere plan. Regn uansett med at leveringen til serveren er asynkron og intervallstyrt, i tillegg til pipelinens eget leveringsintervall.

Onboarding av deres server

Driftspartneren provisjonerer fildelingen, Storage Sync Service, sync-gruppen og cloud endpointet. Det som gjenstår, skjer på deres server og avtales i onboardingen:

1. En støttet Windows Server-versjon med utgående HTTPS-tilgang (port 443) til Azure, og nok diskplass til en full kopi av fildelingens innhold.
2. Serveren må ha en system-tildelt managed identity: for en Azure VM aktiveres den på VM-en, for en on-premises server via Azure Arc (Azure Connected Machine-agenten).
3. Installer Azure File Sync-agenten (versjon 20 eller nyere) og registrer serveren mot utrullingens Storage Sync Service.
4. Driftspartneren oppretter server endpointet (koblingen mellom en lokal mappe og sync-gruppen) og aktiverer managed identity-konfigurasjonen for den registrerte serveren, som gir serverens identitet tilgangen til fildelingen.

Oppbevaring og sletting

Fildelingen og servermappen er samme datasett, holdt synkront av File Sync. Den automatiske slettingen etter retentionDays gjelder kun droppsonen i Blob Storage, ikke fildelingen: her styrer dere oppbevaringen selv. Sletter dere en fil lokalt etter behandling, synkroniseres slettingen tilbake til fildelingen. Leveringslogg-posten består uansett og hindrer at samme vedlegg lastes ned på nytt.

Nettverk med nettverksisolasjon

Med tilvalget nettverksisolasjon aktivert er lagringskontoens offentlige endepunkt avskrudd, og workeren når fildelingen via et privat endepunkt i utrullingens VNet (se nettverksisolasjon). Deres server må da nå fildelingen og Storage Sync Service over en privat nettverkssti (VPN eller ExpressRoute med privat DNS), som settes opp som del av onboardingen. Uten tilvalget, som er standard også i produksjon, beholdes de offentlige, RBAC-sikrede endepunktene, der serveren kun trenger utgående HTTPS.