Nejčastější dotazy ke službě Azure Files

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ých nebo místních nasazeních Windows, Linuxu a macOS. Sdílené složky Azure můžete také ukládat do mezipaměti na počítačích Windows Serveru pomocí Synchronizace souborů Azure pro rychlý přístup blízko místa, kde se data používají.

Synchronizace souborů Azure


  • 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) definované pro soubory a složky na jednom serveru nemusí být možné vynutit jinými servery ve skupině synchronizace. Pro nejlepší výsledky doporučujeme synchronizaci 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 které mají vytvořeny vztahy důvěryhodnosti, nebo mezi servery, které nejsou v doméně. Doporučujeme, abyste se vyhnuli použití kombinace těchto konfigurací.

  • Změny provedené ve sdílené složce Azure pomocí protokolu Azure Portal smb se okamžitě nezjektou a nereplikují jako změny koncového bodu serveru. Azure Files ještě neobsahuje oznámení o změně ani ukládání do deníku, takže neexistuje způsob, jak automaticky zahájit relaci synchronizace při změně souborů. Na Windows Serveru používá Synchronizace souborů Azure deník Windows USN k automatickému zahájení relace synchronizace při změně souborů.

    Aby bylo možné zjistit změny sdílené složky Azure, Synchronizace souborů Azure naplánovanou úlohu nazývanou úloha detekce změn. Úloha detekce změn vytvoří výčet všech souborů ve sdílené sdílené složky a pak ji porovná s verzí synchronizace pro tento soubor. 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 tak, že výčtem všech souborů ve sdílené složky Azure funguje, trvá detekce změn ve větších oborech názvů déle než v menších oborech názvů. U velkých oborů názvů může trvat déle než jednou za 24 hodin, než se zjistí, které soubory se změnily.

    Pokud chcete okamžitě synchronizovat soubory, které se změnily ve sdílené složky Azure, můžete rutinu PowerShellu Invoke-AzStorageSyncChangeDetection použít k ruční inicializaci detekce změn ve sdílené složky Azure. Tato rutina je určená pro scénáře, kdy nějaký typ automatizovaného procesu provádí změny ve sdílené složky Azure nebo změny provádí správce (například přesun souborů a adresářů do sdílené složky). V případě změn koncových uživatelů doporučujeme nainstalovat na virtuální počítač IaaS agenta Synchronizace souborů Azure a získat koncovým uživatelům přístup ke sdílené složky 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žívat Invoke-AzStorageSyncChangeDetection rutinu. Další informace najdete v dokumentaci k Invoke-AzStorageSyncChangeDetection .

    Poznámka

    Rutina PowerShellu Invoke-AzStorageSyncChangeDetection dokáže rozpoznat maximálně 10 000 položek. Další omezení najdete v dokumentaci k Invoke-AzStorageSyncChangeDetection .

    Poznámka

    Změny provedené ve sdílené složce Azure pomocí REST ne aktualizují čas poslední změny protokolu SMB a synchronizace se na změnu nebude poohlédněte.

    Zkoumáme přidání detekce změn pro sdílené složky Azure podobné 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.


  • Synchronizace souborů Azure používá jednoduchou strategii řešení konfliktů: obě změny souborů, které se mění ve dvou koncových bodech, zachováme současně. Při poslední zapsané změně se zachová původní název souboru. Starší soubor (určený parametrem LastWriteTime) má název koncového bodu a ke názvu souboru je připojeno číslo konfliktu. U koncových bodů serveru je název koncového bodu název serveru. U koncových bodů cloudu je název koncového bodu Cloud. Název se řídí touto taxonomií:

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

    Pokud například došlo ke staršímu zápisu, CompanyReport.docx první konflikt CompanyReport-CentralServer.docx centrálního serveru. Druhý konflikt by se pojmenoval 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 synchronizace souboru nezdaří, dokud počet konfliktních souborů nebude menší než 100.


  • Existují dva důvody, proč mohou v umístění koncového bodu serveru existovat vrstvené soubory:

    • 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ů odvolání nebo pro počáteční režim stahování vyberete pouze obor názvů odvolání, budou se soubory zobrazovat jako vrstvené, dokud se stáhnou místně. Pokud se tomu chcete vyhnout, vyberte možnost Vyhnout se vrstvených souborům pro počáteční režim stahování. Pokud chcete soubory odvolat ručně, použijte rutinu Invoke-StorageSyncFileRecall .

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


  • U vrstvené soubory nebudou miniatury a náhledy viditelné na koncovém bodu serveru. Toto chování se očekává, protože funkce mezipaměti miniatur v Windows záměrně přeskočí čtení souborů s atributem offline. Pokud je vrstvení cloudu povolené, čtení prostřednictvím vrstvené soubory by způsobilo jejich stažení (odvolání).

    Toto chování není specifické pro Synchronizace souborů Azure, Windows Explorer 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č mi nezískaly miniatury souborů označených jako offline?

    Pokud máte dotazy ohledně správy vrstvené soubory, přečtěte si, jak spravovat vrstvené soubory.


  • Před Synchronizace souborů Azure verze 3 zablokovala Synchronizace souborů Azure vrstvené soubory 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é na jiné svazky nebyly ovlivněny. Důvodem tohoto chování byl implicitní předpoklad, že rozhraní Průzkumník souborů a další rozhraní Windows API mají, že operace přesunu na stejném svazku jsou (téměř) okamžité operace přejmenování. To znamená, že Průzkumník souborů nebo jiné metody přesunu (například příkazový řádek nebo PowerShell) budou při odvolání dat z cloudu Synchronizace souborů Azure nereagují. Počínaje Synchronizace souborů Azure agentem verze 3.0.12.0 vám Synchronizace souborů Azure umožní přesunout vrstvené soubory mimo koncový bod serveru. Negativním účinkům, které jsme zmínili dříve, se vyhneme tím, že vrstveným souborům umožníme, aby existoval jako vrstvený soubor mimo koncový bod serveru, a pak soubor odvoláme na pozadí. To znamená, že přesuny na stejném svazku jsou okamžité, a po dokončení přesunu soubor na disk odvolali.

  • Ne: Odebrání koncového bodu serveru není jako restartování serveru. Odebrání a opětovné vytvoření koncového bodu serveru téměř nikdy není vhodným řešením problémů se synchronizací, vrstvením cloudu nebo jinými aspekty Synchronizace souborů Azure. Odebrání koncového bodu serveru je destruktivní operace. V případě, že vrstvené soubory existují mimo obor názvů koncového bodu serveru, může dojít ke ztrátě dat. Další informace najdete v tématu , proč existují vrstvené soubory mimo obor názvů koncového bodu serveru. Nebo to může vést k nedostupným souborům pro vrstvené soubory, které existují v oboru názvů koncového bodu serveru. Tyto problémy se při opětovném vytvoření koncového bodu serveru nevyřeší. Vrstvené soubory mohou existovat v rámci oboru názvů koncového bodu serveru, i když jste nikdy neměli povolené vrstvení cloudu. Proto doporučujeme koncový bod serveru neodebírat, pokud nechcete přestat používat Synchronizace souborů Azure s touto konkrétní složek nebo pokud k tomu není výslovně instruován technik Microsoftu. Další informace o odebrání koncových bodů serveru najdete v tématu Odebrání koncového bodu serveru.


  • Ano, službu synchronizace úložiště nebo účet úložiště je možné přesunout do jiné skupiny prostředků, předplatného nebo tenanta Azure AD. Po přesunu služby synchronizace úložiště nebo účtu úložiště musíte aplikaci Microsoft.StorageSync poskytnout přístup k účtu úložiště (viz Synchronizace souborů Azure má přístup k účtu úložiště).

    Poznámka

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

  • Od 24. února 2020 budou nové a existující seznamy ACL vrstvené podle Synchronizace souborů Azure zachovány ve formátu NTFS a úpravy seznamu ACL provedené přímo ve sdílené složky Azure se budou synchronizovat se všemi servery ve skupině synchronizace. Všechny změny v seznamech ACL provedené v Azure Files se synchronizují prostřednictvím Synchronizace souborů Azure. Při kopírování dat do Azure Files se ujistěte, že ke kopírování atributů, časových razítek a seznamu ACL do sdílené složky Azure používáte nástroj pro kopírování, který podporuje potřebnou "věrnost", a to buď přes protokol SMB, nebo REST. Při používání nástrojů pro kopírování v Azure, jako je AzCopy, je důležité použít nejnovější verzi. Projděte si tabulku nástrojů pro kopírování souborů a získejte přehled o nástrojích pro kopírování Azure, abyste měli přehled o tom, že můžete zkopírovat všechna důležitá metadata souboru.

    Pokud jste povolili Azure Backup spravovaných sdílených složek synchronizace souborů, můžete seznamy ACL souborů i nadále obnovovat v rámci pracovního postupu obnovení zálohy. To funguje buď pro celou složku, nebo pro jednotlivé soubory/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é synchronizací souborů, seznamy ACL nemusí být správně obnoveny do seznamu ACL systému souborů NTFS, pokud byly snímky pořízeny před 24. únorem 2020. Pokud k tomu dojde, zvažte kontaktování Podpora Azure.


  • Ne, Synchronizace souborů Azure nesynchronní LastWriteTime pro adresáře.

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

  • 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, Azure Storage protokoly se dají použít ke sledování změn souborů a přístupu uživatelů. Tyto protokoly je možné použít pro účely řešení potíží a požadavky jsou protokolovány na základě nejlepšího úsilí.
    • pokud uživatelé přistupují ke sdílené složce Azure prostřednictvím serveru Windows s nainstalovaným agentem Synchronizace souborů Azure, sledujte změny souborů a přístup uživatelů na Windows serveru pomocí zásad auditu nebo produktu třetích stran.

Služba AD DS & ověřování Azure služba AD DS

  • Ne, tento scénář není podporován.

  • Pokud je předplatné, pod kterým je nainstalovaná sdílená složka, přidruženo ke stejnému tenantovi služby Azure AD jako nasazení Azure služba AD DS, ke kterému je připojený virtuální počítač, můžete ke sdíleným složkám Azure přistupovat pomocí stejných přihlašovacích údajů Azure AD. Omezení je uloženo v předplatném, ale na přidruženém tenantovi služby Azure AD.

  • Ne, soubory Azure podporují jenom Azure služba AD DS nebo místní služba AD DS integraci s klientem služby Azure AD, který se nachází ve stejném předplatném jako sdílená složka. K tenantovi služby Azure AD může být přidruženo pouze jedno předplatné. Toto omezení se vztahuje na metody ověřování Azure služba AD DS i místní služba AD DS. Pokud používáte místní služba AD DS pro ověřování, musí se přihlašovací údaje služba AD DS synchronizovat do Azure AD , ke kterému je přiřazený účet úložiště.

  • Místní služba AD DS ověřování souborů Azure se integruje jenom s doménovou strukturou doménové služby, ke 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. Způsob registrace souborů Azure v služba AD DS téměř stejný jako běžný souborový server, kde se v služba AD DS vytvoří identita (účet pro přihlášení k počítači nebo službě) v rámci ověřování. Jediným rozdílem je, že registrovaný hlavní název služby (SPN) účtu úložiště končí řetězcem "file.core.windows.net", který se neshoduje s příponou domény. Projděte si správce domény a zjistěte, jestli je pro povolení více doménových struktur v důsledku jiné přípony domény potřeba nějaká aktualizace zásad Směrování přípon. Níže uvádíme příklad konfigurace zásad Směrování přípon.

    Příklad: Pokud mají uživatelé v doménové struktuře doménu, kde se má připojit ke sdílené složce s účtem úložiště registrovaným pro doménu v doménové struktuře B, nebude tato akce automaticky fungovat, protože instanční objekt účtu úložiště nemá příponu odpovídající příponě jakékoli domény v doménové struktuře A. Tento problém můžeme vyřešit ruční konfigurací pravidla směrování přípon z doménové struktury A na doménovou strukturu B pro vlastní příponu "file.core.windows.net". Nejdřív je nutné přidat novou vlastní příponu do doménové struktury B. Ujistěte se, že máte příslušná oprávnění správce ke změně konfigurace, a pak postupujte podle těchto kroků:

    1. Přihlášení k doméně počítače připojené k doménové struktuře B
    2. Otevřete konzolu domény a vztahy důvěryhodnosti služby Active Directory.
    3. Klikněte pravým tlačítkem na domény a vztahy důvěryhodnosti služby Active Directory.
    4. Klikněte na vlastnosti.
    5. Klikněte na Přidat.
    6. Přidat "file.core.windows.net" jako přípony hlavního názvu uživatele (UPN)
    7. Kliknutím na tlačítko použít a pak na OK zavřete průvodce.

    Dále přidejte pravidlo Směrování přípon na doménovou strukturu A, aby se přesměroval na doménovou strukturu B.

    1. Přihlášení k doméně počítače připojené k doménové struktuře A
    2. Otevřete konzolu domény a vztahy důvěryhodnosti služby Active Directory.
    3. Klikněte pravým tlačítkem na doménu, ke které chcete získat přístup ke sdílené složce, a pak klikněte na kartu důvěry a vyberte doménu doménové struktury B z odchozích vztahů důvěryhodnosti. Pokud jste nenakonfigurovali důvěryhodnost mezi dvěma doménovými strukturami, musíte nejdřív nastavit vztah důvěryhodnosti.
    4. Klikněte na vlastnosti... pak "Směrování přípon názvů"
    5. Ověřte, jestli se nezobrazuje přípona *. file.core.windows.net. Pokud ne, klikněte na aktualizovat.
    6. Vyberte *. file.core.windows.net a pak klikněte na povolit a použít.
  • Vytvoření účtu počítače (výchozí) nebo přihlašovacího účtu služby nemá žádný rozdíl nad tím, jak ověřování funguje se soubory Azure. Můžete si vybrat, jak vyjádřit účet úložiště jako identitu ve vašem prostředí služby AD. Výchozí DomainAccountType sada v rutině Join-AzStorageAccountForAuth je počítačový účet. Doba vypršení platnosti hesla nakonfigurovaná ve vašem prostředí služby AD se ale může lišit pro účet počítače nebo přihlašovací účet služby a Vy musíte vzít v úvahu, abyste si aktualizovali heslo své identity účtu úložiště ve službě AD.

  • Pomocí dvou kroků níže můžete odebrat uložené přihlašovací údaje přidružené k klíči účtu úložiště a odebrat připojení SMB:

    1. spusťte následující rutinu v Windows Cmd.exe pro odebrání přihlašovacích údajů. Pokud ho nemůžete najít, znamená to, že jste jeho přihlašovací údaje netrvali a tento krok můžete přeskočit.

      cmdkey/Delete: doména: cíl = úložiště-účet-name.file.core.windows.net

    2. Odstraní existující připojení ke sdílené složce. Cestu pro připojení můžete zadat buď jako písmeno připojené jednotky, nebo jako cestu storage-account-name.file.core.windows.net.

      NET USE < Drive-písmeno_jednotky/Share-Path > /DELETE

Systém souborů NFS (NFS verze 4.1)

Sdílet snímky

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


  • Snímky sdílené složky 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ě, váš snímek sdílené složky se také ukládá redundantním způsobem do spárované oblasti.

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


  • Pokud máte na sdílené složce snímky aktivních složek, nemůžete sdílenou složku odstranit. Pomocí rozhraní API můžete odstranit snímky sdílené složky společně se sdílenou složkou. Můžete také odstranit snímky sdílené složky i sdílenou složku v Azure Portal.

Fakturace a ceny


  • Snímky sdílené složky jsou přírůstkové. Základní snímek sdílené složky je samotný podíl. Všechny následné snímky sdílené složky jsou přírůstkové a ukládají pouze rozdíly z 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ěnila pouze 5 GiB, snímek sdílené složky spotřebovává pouze 5 dalších GiB a účtuje se vám 105 GiB. Další informace o cenách a za standardní výstupních operací najdete na stránce s cenami.

Viz také