Sdílet prostřednictvím

Nejčastější dotazy ke službě Azure Files a Synchronizace souborů Azure

  • Článek

Azure Files nabízí plně spravované sdílené složky v cloudu, které jsou přístupné přes standardní protokol SMB (Server Message Block) a protokol NFS (Network File System). Sdílené složky Azure můžete připojit souběžně v cloudovém nebo místním nasazení systémů Windows, Linux a macOS. Sdílené složky Azure můžete také ukládat do mezipaměti na počítačích s Windows Serverem pomocí Synchronizace souborů Azure pro rychlý přístup blízko místa, kde se data používají.

Synchronizace souborů Azure

  • Můžu mít servery připojené k doméně a servery, které nejsou připojené k doméně, ve stejné skupině synchronizace?
    Ano. Skupina synchronizace může obsahovat koncové body serveru, které mají různá členství ve službě Active Directory, i když nejsou připojené k doméně. I když tato konfigurace technicky funguje, nedoporučujeme to jako typickou konfiguraci, protože seznamy řízení přístupu (ACL), které jsou definované pro soubory a složky na jednom serveru, nemusí být možné vynutit jinými servery ve skupině synchronizace. Pro dosažení nejlepších výsledků doporučujeme synchronizovat mezi servery, které jsou ve stejné doménové struktuře služby Active Directory, mezi servery, které jsou v různých doménových strukturách služby Active Directory, ale mají vytvořené vztahy důvěryhodnosti nebo mezi servery, které nejsou v doméně. Doporučujeme, abyste se vyhnuli kombinaci těchto konfigurací.

  • Vytvořil(a) jsem soubor přímo ve sdílené složce Azure pomocí protokolu SMB nebo na portálu. Jak dlouho trvá synchronizace souboru se servery ve skupině synchronizace?

    Změny provedené ve sdílené složce Azure s využitím webu Azure Portal nebo protokolu SMB se okamžitě nerozpoznají a nereplikují jako změny do koncového bodu serveru. Služba Azure Files zatím nemá oznámení o změnách ani zaznamenávání deníku, takže neexistuje způsob, jak při změně souborů automaticky zahájit relaci synchronizace. Synchronizace souborů Azure v systému Windows Server používá zaznamenávání do deníku Windows USN k automatickému zahájení relace synchronizace při změně souborů.

    Pokud chcete zjistit změny ve sdílené složce Azure, Synchronizace souborů Azure má naplánovanou úlohu označovanou jako úloha detekce změn. Úloha detekce změn vytvoří výčet všech souborů ve sdílené složce a pak ho porovná se synchronizovanou verzí daného souboru. Když úloha detekce změn zjistí, že se soubory změnily, Synchronizace souborů Azure zahájí relaci synchronizace. Úloha detekce změn se spouští každých 24 hodin. Vzhledem k tomu, že úloha detekce změn funguje na základě výčtu všech souborů ve sdílené složce Azure, trvá detekce změn ve větších oborech názvů déle než v menších. U rozsáhlých oborů názvů může zjištění, které soubory se změnily, trvat déle než jednou za 24 hodin.

    Pokud chcete okamžitě synchronizovat soubory, které se změnily ve sdílené složce Azure, můžete k ručnímu zahájení detekce změn ve sdílené složce Azure použít rutinu PoweShellu Invoke-AzStorageSyncChangeDetection. Tato rutina je určená pro scénáře, kdy nějaký typ automatizovaného procesu provádí změny ve sdílené složce Azure nebo změny provádí správce (například přesouvání souborů a adresářů do sdílené složky). U změn koncových uživatelů doporučujeme nainstalovat agenta Synchronizace souborů Azure na virtuální počítač IaaS a mít koncové uživatele přístup ke sdílené složce prostřednictvím virtuálního počítače IaaS. Díky tomu se všechny změny rychle synchronizují s jinými agenty, aniž by bylo nutné použít rutinu Invoke-AzStorageSyncChangeDetection. Další informace najdete v dokumentaci Invoke-AzStorageSyncChangeDetection .

    Zkoumáme přidání detekce změn pro sdílenou složku Azure podobnou hodnotě USN pro svazky na Windows Serveru. Pomozte nám určit prioritu této funkce pro budoucí vývoj hlasováním na webu Azure Community Feedback.

  • Co se stane, když se přibližně ve stejnou dobu změní jeden soubor na dvou serverech?
    Konflikty souborů se vytvoří, když soubor ve sdílené složce Azure neodpovídá souboru v umístění koncového bodu serveru (velikost a čas poslední změny se liší).

    Konflikty souborů můžou způsobit následující scénáře:

    • Soubor se vytvoří nebo upraví v koncovém bodu (například Server A). Pokud se stejný soubor změní na jiném koncovém bodu před synchronizací změny na serveru A s tímto koncovým bodem, vytvoří se konfliktní soubor.
    • Soubor existoval ve sdílené složce Azure a umístění koncového bodu serveru ještě před vytvořením koncového bodu serveru. Pokud se velikost souboru nebo čas poslední změny mezi souborem na serveru a sdílenou složkou Azure při vytvoření koncového bodu serveru liší, vytvoří se konfliktní soubor.
    • Databáze synchronizace se znovu vytvořila kvůli poškození nebo dosažení limitu znalostí. Po opětovném vytvoření databáze přejde synchronizace do režimu označovaného jako odsouhlasení. Pokud se velikost souboru nebo čas poslední změny mezi souborem na serveru a sdílenou složkou Azure při odsouhlasení liší, vytvoří se konfliktní soubor.

    Po dokončení počátečního nahrání do sdílené složky Azure Synchronizace souborů Azure nepřepíše žádné soubory ve skupině synchronizace. Místo toho používá jednoduchou strategii řešení konfliktů: uchovává obě změny souborů, které se mění ve dvou koncových bodech současně. Poslední zapsaná změna zachová původní název souboru. Starší soubor (určený lastWriteTime) má název koncového bodu a číslo konfliktu připojené k názvu souboru. Názvem koncového bodu je u koncových bodů serveru název serveru. Pro koncové body cloudu je název koncového bodu Cloud. Název se řídí touto taxonomií:

    <FileNameWithoutExtension-endpointName><>[-#].<Ext>

    Například při prvním konfliktu se z CompanyReport.docx stane CompanyReport-CentralServer.docx, pokud CentralServer je místo, kde došlo ke staršímu zápisu. Druhý konflikt by se jmenoval CompanyReport-CentralServer-1.docx. Synchronizace souborů Azure podporuje 100 konfliktních souborů na soubor. Po dosažení maximálního počtu konfliktních souborů se soubor nebude synchronizovat, dokud nebude počet konfliktních souborů menší než 100.

  • Mám zakázané vrstvení cloudu, proč jsou vrstvené soubory v umístění koncového bodu serveru?
    V umístění koncového bodu serveru můžou existovat dva důvody, proč vrstvené soubory existují:

    • Pokud při přidávání nového koncového bodu serveru do existující skupiny synchronizace zvolíte první možnost oboru názvů pro odvolání nebo možnost odvolat obor názvů pouze pro počáteční režim stahování, soubory se zobrazí jako vrstvené, dokud se nestáhnou místně. Pokud se tomu chcete vyhnout, vyberte možnost vyhnout se vrstveným souborům pro počáteční režim stahování. Pokud chcete soubory ručně odvolat, použijte rutinu Invoke-StorageSyncFileRecall .

    • Pokud bylo na koncovém bodu serveru povolené vrstvení cloudu a pak zakázáno, zůstanou soubory vrstvené, dokud k nim nebudete mít přístup.

  • Proč moje vrstvené soubory nezobrazují miniatury nebo náhledy ve Windows Průzkumník souborů?
    U vrstvených souborů nebudou miniatury a náhledy viditelné na koncovém bodu serveru. Toto chování je očekávané, protože funkce mezipaměti miniatur ve Windows záměrně přeskočí čtení souborů pomocí atributu offline. Při povoleném vrstvení cloudu by čtení vrstvených souborů způsobilo stažení (odvolání).

    Toto chování není specifické pro Synchronizace souborů Azure. Windows Průzkumník souborů zobrazí "šedé X" pro všechny soubory, které mají nastavený atribut offline. Při přístupu k souborům přes PROTOKOL SMB se zobrazí ikona X. Podrobné vysvětlení tohoto chování najdete v tématu Proč se mi nezobrazují miniatury souborů, které jsou označené jako offline?

    Dotazy týkající se správy vrstvených souborů najdete v tématu Správa vrstvených souborů.

  • Proč vrstvené soubory existují mimo obor názvů koncového bodu serveru?
    Před Synchronizace souborů Azure agentem verze 3 Synchronizace souborů Azure zablokoval přesun vrstvených souborů mimo koncový bod serveru, ale na stejném svazku jako koncový bod serveru. Operace kopírování, přesuny nevrstvých souborů a přesuny vrstvených souborů na jiné svazky nebyly ovlivněny. Důvodem tohoto chování bylo implicitní předpoklad, že Průzkumník souborů a další rozhraní API systému Windows mají operace přesunu na stejném svazku téměř okamžité operace přejmenování. To znamená, že přesuny způsobí, že Průzkumník souborů nebo jiné metody přesunu (například příkazový řádek nebo PowerShell) přestanou reagovat, zatímco Synchronizace souborů Azure odvolává data z cloudu. Počínaje Synchronizace souborů Azure agentem verze 3.0.12.0 vám Synchronizace souborů Azure umožní přesunout vrstvený soubor mimo koncový bod serveru. Vyhneme se negativním dopadům, které jsme zmínili, tím, že vrstvený soubor existuje jako vrstvený soubor mimo koncový bod serveru a pak soubor odvoláváme na pozadí. To znamená, že přesuny na stejném svazku jsou okamžité a po dokončení přesunu provedeme veškerou práci, abychom soubor stáhli na disk.

  • Mám problém s Synchronizace souborů Azure na mém serveru (synchronizace, vrstvení cloudu atd.). Mám odebrat a znovu vytvořit koncový bod serveru?

    Ne: Odebrání koncového bodu serveru se nelíbí restartování serveru. Odebrání a opětovné vytvoření koncového bodu serveru je téměř nikdy vhodným řešením pro řešení problémů se synchronizací, vrstvení cloudu nebo jinými aspekty Synchronizace souborů Azure. Odebrání koncového bodu serveru je destruktivní operace. Může dojít ke ztrátě dat v případě, že vrstvené soubory existují mimo obor názvů koncového bodu serveru. Další informace najdete v článku o tom, proč vrstvené soubory existují mimo obor názvů koncového bodu serveru. Nebo může mít za následek nepřístupné soubory pro vrstvené soubory, které existují v oboru názvů koncového bodu serveru. Tyto problémy se nevyřeší při opětovném vytvoření koncového bodu serveru. Vrstvené soubory můžou existovat v rámci oboru názvů koncového bodu serveru, i když jste nikdy neměli povolené vrstvení cloudu. Proto doporučujeme, abyste koncový bod serveru neodebrali, pokud nechcete přestat používat Synchronizace souborů Azure s touto konkrétní složkou nebo jste k tomu výslovně dostali pokyn technikem Microsoftu. Další informace o odebrání koncových bodů serveru najdete v tématu Odebrání koncového bodu serveru.

  • Můžu přesunout synchronizační službu úložiště nebo účet úložiště do jiné skupiny prostředků, předplatného nebo tenanta Microsoft Entra?
    Ano, synchronizační službu úložiště nebo účet úložiště můžete přesunout do jiné skupiny prostředků, předplatného nebo tenanta Microsoft Entra. Po přesunutí synchronizační služby úložiště nebo účtu úložiště musíte aplikaci Microsoft.StorageSync udělit přístup k účtu úložiště. Postupujte následovně:

    1. Přihlaste se k webu Azure Portal a v nabídce služby vyberte Řízení přístupu (IAM ).

    2. Výběrem karty Přiřazení rolí zobrazíte seznam uživatelů a aplikací (instančních objektů), které mají přístup k vašemu účtu úložiště.

    3. Ověřte, jestli se v seznamu zobrazuje Microsoft.StorageSync nebo Hybridní služba Synchronizace souborů (starý název aplikace) s rolí Čtenář a přístup k datům.

      Pokud se služba Microsoft.StorageSync nebo Hybrid Synchronizace souborů Service nezobrazí v seznamu, proveďte následující kroky:

      • Vyberte Přidat.
      • V poli Role vyberte Čtenář a přístup k datům.
      • Do pole Vybrat zadejte Microsoft.StorageSync, vyberte roli a pak vyberte Uložit.

      Poznámka:

      Při vytváření koncového bodu cloudu musí být synchronizační služba úložiště a účet úložiště ve stejném tenantovi Microsoft Entra. Po vytvoření cloudového koncového bodu je možné službu synchronizace úložiště a účet úložiště přesunout do různých tenantů Microsoft Entra.

  • Zachová Synchronizace souborů Azure seznamy ACL na úrovni adresáře nebo souboru NTFS spolu s daty uloženými ve službě Azure Files?

    Od 24. února 2020 se nové a stávající seznamy ACL vrstvené synchronizací souborů Azure zachovají ve formátu NTFS a změny seznamu ACL provedené přímo ve sdílené složce Azure se budou synchronizovat se všemi servery ve skupině synchronizace. Všechny změny seznamů ACL provedených ve sdílených složkách Azure se synchronizují prostřednictvím Synchronizace souborů Azure. Při kopírování dat do služby Soubory Azure se ujistěte, že používáte nástroj pro kopírování, který podporuje potřebnou věrnost ke kopírování atributů, časových razítek a seznamů ACL do sdílené složky Azure , a to buď přes protokol SMB, nebo REST. Při použití nástrojů pro kopírování Azure, jako je AzCopy, je důležité použít nejnovější verzi. V tabulce nástrojů pro kopírování souborů získáte přehled nástrojů pro kopírování Azure, abyste měli jistotu, že můžete zkopírovat všechna důležitá metadata souboru.

    Pokud jste na spravovaných sdílených složkách Synchronizace souborů Azure povolili Službu Azure Backup, můžou být seznamy ACL souborů i nadále obnoveny jako součást pracovního postupu obnovení zálohování. Funguje to buď pro celou sdílenou složku, nebo pro jednotlivé soubory nebo adresáře.

    Pokud používáte snímky jako součást samoobslužného řešení zálohování pro sdílené složky spravované Synchronizace souborů Azure, nemusí se seznamy ACL správně obnovit do seznamů ACL NTFS, pokud byly snímky pořízeny před 24. únorem 2020. Pokud k tomu dojde, zvažte kontaktování podpory Azure.

  • Synchronizuje Synchronizace souborů Azure čas posledního přepisu pro adresáře? Proč se při změně souborů v adresáři neaktualizuje časové razítko změny data?
    Ne, Synchronizace souborů Azure nesynchronizuje lastWriteTime pro adresáře. Služba Soubory Azure navíc při změně souborů v adresáři neaktualizuje časové razítko změny data (LastWriteTime). Toto chování je očekávané.

  • Proč je antivirový software na serveru AFS, který odvolává vrstvené soubory?
    Když uživatelé přistupují k vrstveným souborům, může některé antivirové (AV) software způsobit neúmyslné odvolání souborů. K tomu dochází v případě, že software AV není nakonfigurovaný tak, aby ignoroval vrstvené soubory (ty s atributem RECALL_ON_DATA_ACCESS). Co se stane:

    1. Uživatel se pokusí o přístup k vrstvenému souboru.
    2. Software AV blokuje popisovač pro čtení.
    3. Aplikace AV pak provede vlastní čtení a zkontroluje, jestli soubor neobsahuje viry.

    Tento proces se může zdát, jako by software AV odvolal vrstvené soubory, ale ve skutečnosti se aktivuje pokusem o přístup uživatele. Pokud chcete tomuto problému zabránit, ujistěte se, že dodavatel AV nakonfiguruje svůj software tak, aby ignoroval skenované vrstvené soubory s atributem RECALL_ON_DATA_ACCESS.

  • Může kontrolní software SSL blokovat přístup k serverům AFS? Ujistěte se, že váš kontrolní software SSL (například Zscaler nebo FortiGate) umožňuje přístup k Azure koncovým bodům serveru Synchronizace souborů Azure (AFS). Tyto nástroje kontroly SSL můžou přepsat nastavení brány firewall a selektivně povolit provoz. Pokud chcete tento problém vyřešit, obraťte se na správce sítě. Pomocí příkazu testnet zjistěte, jestli u vašeho serveru AFS dochází k tomuto problému.

Zabezpečení, ověřování a řízení přístupu

  • Jak můžu auditovat přístup k souborům a změny ve službě Azure Files?

    Existují dvě možnosti, které poskytují funkce auditování pro Azure Files:

    • Pokud uživatelé přistupují ke sdílené složce Azure přímo, můžete pomocí protokolů Azure Storage sledovat změny souborů a přístup uživatelů pro účely řešení potíží. Požadavky se protokolují na základě maximálního úsilí.
    • Pokud uživatelé přistupují ke sdílené složce Azure prostřednictvím Windows Serveru, který má nainstalovaného agenta Synchronizace souborů Azure, použijte zásady auditu nebo produkt třetích stran ke sledování změn souborů a přístupu uživatelů na Windows Serveru.

  • Podporuje Azure Files používání výčtu založeného na přístupu (ABE) k řízení viditelnosti souborů a složek ve sdílených složkách SMB v Azure?

    Použití ABE se službou Azure Files se v současné době nepodporuje, ale můžete použít DFS-N se sdílenými složkami Azure SMB.

Ověřování na základě identity

  • Podporuje služba Microsoft Entra Domain Services přístup smb pomocí přihlašovacích údajů Microsoft Entra ze zařízení připojených k nebo zaregistrovaným pomocí Microsoft Entra ID?

    Ne, tento scénář není podporovaný.

  • Můžu použít kanonický název (CNAME) k připojení sdílené složky Azure při ověřování na základě identity?

    Ano, tento scénář je teď podporovaný v prostředích s jednou doménovou strukturou i více doménovými strukturami pro sdílené složky Azure SMB. Azure Files ale podporuje konfiguraci CNAMEs pouze pomocí názvu účtu úložiště jako předpony domény. Pokud nechcete jako předponu použít název účtu úložiště, zvažte místo toho použití oborů názvů DFS.

  • Můžu přistupovat ke sdíleným složkám Azure pomocí přihlašovacích údajů Microsoft Entra z virtuálního počítače v jiném předplatném?

    Pokud je předplatné, pod kterým je sdílená složka nasazená, přidružené ke stejnému tenantovi Microsoft Entra jako nasazení služby Microsoft Entra Domain Services, ke kterému je virtuální počítač připojený k doméně, můžete k sdíleným složkám Azure přistupovat pomocí stejných přihlašovacích údajů Microsoft Entra. Omezení se nevztahuje na předplatné, ale na přidruženého tenanta Microsoft Entra.

  • Můžu povolit službu Microsoft Entra Domain Services nebo místní ověřování AD DS pro sdílené složky Azure pomocí tenanta Microsoft Entra, který se liší od primárního tenanta sdílené složky Azure?

    Ne. Služba Azure Files podporuje pouze integraci služby Microsoft Entra Domain Services nebo místní služby AD DS s tenantem Microsoft Entra, který se nachází ve stejném předplatném jako sdílená složka. Předplatné je možné přidružit pouze k jednomu tenantovi Microsoft Entra. Při použití místní služby AD DS k ověřování by se přihlašovací údaje služby AD DS měly synchronizovat s ID Microsoft Entra, ke kterému je účet úložiště přidružený.

  • Podporuje místní ověřování AD DS pro sdílené složky Azure integraci s prostředím AD DS s více doménovými strukturami?

    Místní ověřování AD DS služby Azure Files se integruje pouze s doménovou strukturou doménové služby, do které je účet úložiště zaregistrovaný. Aby bylo možné podporovat ověřování z jiné doménové struktury, musí mít vaše prostředí správně nakonfigurovaný vztah důvěryhodnosti doménové struktury. Podrobné pokyny najdete v tématu Použití služby Azure Files s více doménovými strukturami Active Directory.

    Poznámka:

    V nastavení s více doménovými strukturami nepoužívejte Průzkumník souborů ke konfiguraci seznamů ACL systému Windows nebo oprávnění NTFS na úrovni kořenového adresáře, adresáře nebo souboru. Místo toho použijte icacls .

  • Existuje nějaký rozdíl v vytvoření účtu počítače nebo přihlašovacího účtu služby, který představuje můj účet úložiště ve službě AD?

    Vytvoření účtu počítače (výchozí) nebo přihlašovacího účtu služby nemá žádný rozdíl v tom, jak funguje ověřování se službou Azure Files. Můžete si vybrat, jak ve svém prostředí AD reprezentovat účet úložiště jako identitu. Výchozí vlastnost DomainAccountType nastavená v Join-AzStorageAccountForAuth rutině je účet počítače. Věk vypršení platnosti hesla nakonfigurovaný ve vašem prostředí AD se ale může lišit pro přihlašovací účty počítače nebo služby a musíte vzít v úvahu aktualizaci hesla identity účtu úložiště ve službě AD.

  • Jak odebrat přihlašovací údaje uložené v mezipaměti pomocí klíče účtu úložiště a odstranit existující připojení SMB před inicializací nového připojení pomocí Microsoft Entra ID nebo ad přihlašovacích údajů?

    Pomocí následujícího dvou kroků odeberte uložené přihlašovací údaje přidružené k klíči účtu úložiště a odeberte připojení SMB:

    1. Spuštěním následujícího příkazu z příkazového řádku systému Windows odeberte přihlašovací údaje. Pokud ho nemůžete najít, znamená to, že jste neuchovali přihlašovací údaje a můžete tento krok přeskočit.

      cmdkey /delete:Domain:target=název_účtu_úložiště.file.core.windows.net

    2. Odstraňte stávající připojení ke sdílené složce. Cestu připojení můžete zadat buď jako písmeno připojené jednotky, nebo storage-account-name.file.core.windows.net cestu.

      net use <drive-letter/share-path> /delete

  • Je možné zobrazit uživatelePrincipalName (UPN) vlastníka souboru nebo adresáře v Průzkumník souborů místo identifikátoru zabezpečení (SID)?

    Průzkumník souborů volání rozhraní RPC API přímo na server (Soubory Azure) k překladu identifikátoru SID do hlavního názvu uživatele (UPN). Azure Files nepodporuje toto rozhraní API, takže v Průzkumník souborů se místo hlavního názvu uživatele (UPN) souborů a adresářů hostovaných ve službě Azure Files zobrazí identifikátor SID vlastníka souboru nebo adresáře. Z klienta připojeného k doméně ale můžete pomocí následujícího příkazu PowerShellu zobrazit všechny položky v adresáři a jejich vlastníka, včetně hlavního názvu uživatele (UPN):

    Get-ChildItem <Path> | Get-ACL | Select Path, Owner

Systém souborů SÍTĚ (NFS v4.1)

  • Kdy mám používat sdílené složky Azure NFS?

    Viz sdílené složky NFS.

  • Návody zálohování dat uložených ve sdílených složkách NFS?

    Zálohování dat do sdílených složek NFS je možné orchestrovat pomocí známých nástrojů, jako je rsync nebo produkty od některého z našich externích partnerů pro zálohování. Několik partnerů zálohování, mezi které patří Commvault, Veeam a Veritas , rozšířili svá řešení, aby fungovala s protokoly SMB 3.x a NFS 4.1 pro Azure Files. Můžete také použít snímky sdílené složky Azure NFS.

  • Můžu migrovat existující data do sdílené složky NFS?

    V rámci oblasti můžete k přesunu dat použít standardní nástroje, jako je scp, rsync nebo SSHFS. Vzhledem k tomu, že sdílené složky Azure NFS je možné přistupovat z několika výpočetních instancí současně, můžete zlepšit rychlost kopírování pomocí paralelních nahrávání. Další informace najdete v tématu Migrace do sdílených složek Azure NFS. Pokud chcete přenést data mimo oblast, připojte se k systému souborů z místního datového centra pomocí sítě VPN nebo ExpressRoute.

  • Můžete spustit IBM MQ (včetně více instancí) ve sdílených složkách Azure NFS?

Snímky sdílených složek

Vytvoření snímků sdílené složky

  • Jsou snímky sdílených složek geograficky redundantní?
    Snímky sdílených složek mají stejnou redundanci jako sdílená složka Azure, pro kterou byly pořízeny. Pokud jste pro svůj účet vybrali geograficky redundantní úložiště, snímek sdílené složky se také ukládá redundantně ve spárované oblasti.

Vyčištění snímků sdílených složek

  • Můžu odstranit sdílenou složku, ale neodstraňovat snímky sdílené složky?
    Ne. Pracovní postup odstranění sdílené složky automaticky odstraní snímky při odstranění sdílené složky.

Fakturace a ceny

  • Co jsou transakce ve službě Azure Files a jak se účtují? K transakcím protokolu dochází pokaždé, když uživatel, aplikace, skript nebo služba komunikuje se sdílenými složkami Azure (zápis, čtení, výpis, odstraňování souborů atd.). Je důležité si uvědomit, že některé akce, které byste mohli vnímat jako jednu operaci, můžou ve skutečnosti zahrnovat více transakcí. U standardních sdílených složek Azure fakturovaných podle modelu průběžných plateb mají různé typy transakcí různé ceny na základě jejich dopadu na sdílenou složku. Transakce nemají vliv na fakturaci sdílených složek úrovně Premium, které se účtují pomocí zřízeného modelu. Další informace najdete v tématu Vysvětlení fakturace.

  • Kolik stojí sdílené snímky?
    Snímky sdílených složek jsou v podstatě přírůstkové. Snímek základní sdílené složky je samotná sdílená složka. Všechny následné snímky sdílené složky jsou přírůstkové a ukládají pouze rozdíl od předchozího snímku sdílené složky. Účtuje se vám jenom změněný obsah. Pokud máte sdílenou složku s 100 GiB dat, ale od posledního snímku sdílené složky se změnilo jenom 5 GiB, ale od posledního snímku sdílené složky se vám účtuje 105 GiB. Další informace o transakčních a standardních poplatcích za výchozí přenos dat najdete na stránce Ceny.

Interoperabilita s jinými službami

  • Můžu pro cluster s podporou převzetí služeb při selhání s Windows Serverem použít sdílenou složku Azure jako určující sdílenou složku?
    Tato konfigurace se v současné době nepodporuje pro Azure Files. Informace o nastavení pomocí úložiště objektů blob v Azure najdete v tématu Nasazení cloudové kopie clusteru pro cluster s podporou převzetí služeb při selhání.

Viz také