Planen der Bereitstellung von Azure Files
Sie können Azure Files auf zwei Arten bereitstellen: entweder durch direktes Einbinden der serverlosen Azure-Dateifreigaben oder durch lokales Zwischenspeichern von Azure-Dateifreigaben mithilfe von Azure-Dateisynchronisierung. Die Überlegungen zur Bereitstellung unterscheiden sich je nach der von Ihnen gewählten Option.
Direktes Einbinden einer Azure-Dateifreigabe: Weil Azure Files entweder Zugriff auf den Server Message Block (SMB) oder das Network File System (NFS) bereitstellt, können Sie Azure-Dateifreigaben lokal oder in der Cloud mithilfe der SMB- oder NFS-Standardclients einbinden, die in Ihrem Betriebssystem verfügbar sind. Da Azure-Dateifreigaben serverlos sind, ist für die Bereitstellung in Produktionsszenarien keine Verwaltung eines Dateiservers oder NAS-Geräts erforderlich. Dies bedeutet, dass Sie keine Softwarepatches anwenden oder physische Datenträger austauschen müssen.
Lokales Zwischenspeichern von Azure-Dateifreigaben mit Azure-Dateisynchronisierung: Die Azure-Dateisynchronisierung ermöglicht Ihnen das Zentralisieren der Dateifreigaben Ihrer Organisation in Azure Files, ohne auf die Flexibilität, Leistung und Kompatibilität eines lokalen Dateiservers verzichten zu müssen. Azure-Dateisynchronisierung transformiert einen lokalen (oder Cloud-) Windows Server-Computer in einen schnellen Cache Ihrer SMB-Azure-Dateifreigabe.
Dieser Artikel befasst sich hauptsächlich mit Bereitstellungsüberlegungen zum Bereitstellen einer Azure-Dateifreigabe, die direkt von einem lokalen oder cloudbasierten Client eingebunden werden soll. Weitere Informationen zum Planen einer Azure-Dateisynchronisierungsbereitstellung finden Sie unter Planung für die Bereitstellung einer Azure-Dateisynchronisierung.
Verfügbare Protokolle
Azure Files bietet zwei Dateisystemprotokolle nach Branchenstandard zum Einbinden von Azure-Dateifreigaben: das Server Message Block (SMB)-Protokoll und das Network File System (NFS)-Protokoll, mit dem Sie das Protokoll wählen können, das für Ihre Workload am besten geeignet ist. Azure-Dateifreigaben unterstützen nicht SMB- und NFS-Protokolle auf derselben Dateifreigabe. Sie können jedoch SMB- und NFS-Azure-Dateifreigaben innerhalb desselben Speicherkontos erstellen. NFS 4.1 wird derzeit nur innerhalb des neuen FileStorage-Speicherkontotyps unterstützt (nur Premium-Dateifreigaben).
Mit sowohl SMB- als auch NFS-Dateifreigaben bietet Azure Files Dateifreigaben in Unternehmensqualität, die entsprechend Ihren Speicheranforderungen hochskaliert werden können und auf die Tausende von Clients gleichzeitig zugreifen können.
| Funktion | SMB | NFS |
|---|---|---|
| Unterstützte Protokollversionen | SMB 3.1.1, SMB 3.0, SMB 2.1 | NFS 4.1 |
| Empfohlenes Betriebssystem |
|
Linux-Kernelversion 4.3 und höher |
| Verfügbare Tarife | Premium, transaktionsoptimiert, heiß, kalt | Premium |
| Abrechnungsmodell | Bereitgestellte Kapazität | |
| Azure DNS-Zonenendpunkte (Vorschau) | Unterstützt | Unterstützt |
| Redundanz | LRS, ZRS, GRS, GZRS | LRS, ZRS |
| Dateisystemsemantik | Win32 | POSIX |
| Authentifizierung | Identitätsbasierte Authentifizierung (Kerberos), Authentifizierung mit gemeinsam verwendeten Schlüsseln (NTLMv2) | Hostbasierte Authentifizierung |
| Autorisierung | Win32-Zugriffssteuerungslisten (Access Control Lists, ACLs) | Berechtigungen im UNIX-Format |
| Groß- und Kleinschreibung | Keine Beachtung von Groß-/Kleinschreibung, Schreibweise wird beibehalten | Groß-/Kleinschreibung beachten |
| Löschen oder Ändern geöffneter Dateien | Nur mit Sperre | Ja |
| Dateifreigabe | Windows-Freigabemodus | Netzwerksperrungs-Manager im Bytebereich (Empfehlung) |
| Unterstützung fester Links | Nicht unterstützt | Unterstützt |
| Unterstützung von symbolischen Verknüpfungen | Nicht unterstützt | Unterstützt |
| Optional über das Internet zugänglich | Ja (nur SMB 3.0 und höher) | Nein |
| Unterstützt FileREST | Ja | Teilmenge: |
| Obligatorische Byte-Bereichssperren | Unterstützt | Nicht unterstützt |
| Empfohlene Byte-Bereichssperren | Nicht unterstützt | Unterstützt |
| Erweiterte/benannte Attribute | Nicht unterstützt | Nicht unterstützt |
| Alternative Datenströme | Nicht unterstützt | – |
| Objektkennungen | Nicht unterstützt | – |
| Analysepunkte | Nicht unterstützt | – |
| Sparsedateien | Nicht unterstützt | – |
| Komprimierung | Nicht unterstützt | – |
| Named Pipes | Nicht unterstützt | – |
| SMB Direct | Nicht unterstützt | – |
| SMB Directory Leasing | Nicht unterstützt | – |
| Volumeschattenkopie | Nicht unterstützt | – |
| Kurze Dateinamen (8.3-Alias) | Nicht unterstützt | – |
| Serverdienst | Nicht unterstützt | – |
| Dateisystemtransaktionen (TxF) | Nicht unterstützt | – |
Verwaltungskonzepte
Azure-Dateifreigaben werden in Speicherkonten bereitgestellt, bei denen es sich um Objekte der obersten Ebene handelt, die einen freigegebenen Speicherpool darstellen. Dieser Speicherpool kann verwendet werden, um mehrere Dateifreigaben sowie andere Speicherressourcen wie Blobcontainer, Warteschlangen oder Tabellen bereitzustellen. Für alle Speicherressourcen, die in einem Speicherkonto bereitgestellt werden, treffen die für dieses Speicherkonto geltenden Grenzwerte zu. Die aktuellen Grenzwerte für ein Speicherkonto finden Sie unter Skalierbarkeits- und Leistungsziele für Azure Files.
Es gibt zwei Haupttypen von Speicherkonten, die Sie für Azure Files-Bereitstellungen verwenden:
- Speicherkonten vom Typ Universell Version 2 (GPv2) : GPv2-Speicherkonten ermöglichen Ihnen die Bereitstellung von Azure-Dateifreigaben auf Standard- bzw. festplattenbasierter Hardware (HDD-basiert). Neben Azure-Dateifreigaben können in GPv2-Speicherkonten auch andere Speicherressourcen wie Blobcontainer, Warteschlangen oder Tabellen gespeichert werden.
- FileStorage-Speicherkonten: FileStorage-Speicherkonten ermöglichen Ihnen die Bereitstellung von Azure-Dateifreigaben auf SSD-basierter Hardware (Premium/Solid State Drive). FileStorage-Konten können nur zum Speichern von Azure-Dateifreigaben verwendet werden. In einem FileStorage-Konto können keine anderen Speicherressourcen (Blobcontainer, Warteschlangen, Tabellen usw.) bereitgestellt werden. Nur FileStorage-Konten können sowohl SMB- als auch NFS-Dateifreigaben bereitstellen.
Es gibt mehrere andere Speicherkontotypen, die Sie möglicherweise im Azure-Portal, in PowerShell oder in der CLI finden. Zwei Speicherkontotypen (BlockBlobStorage- und BlobStorage-Speicherkonten) dürfen keine Azure-Dateifreigaben enthalten. Die anderen beiden Speicherkontotypen, die Sie möglicherweise sehen, sind Universell Version 1 (GPv1) und klassische Speicherkonten. Beide können Azure-Dateifreigaben enthalten. Obwohl GPv1 und klassische Speicherkonten Azure-Dateifreigaben enthalten können, sind die meisten neuen Features von Azure Files nur in GPv2- und FileStorage-Speicherkonten verfügbar. Daher empfiehlt es sich, für neue Bereitstellungen nur GPv2- und FileStorage-Speicherkonten zu verwenden und GPv1- und klassische Speicherkonten zu aktualisieren, wenn diese bereits in Ihrer Umgebung vorhanden sind.
Beim Bereitstellen von Azure-Dateifreigaben in Speicherkonten wird Folgendes empfohlen:
Ausschließliches Bereitstellen von Azure-Dateifreigaben in Speicherkonten mit anderen Azure-Dateifreigaben. Obwohl GPv2-Speicherkonten Ihnen Speicherkonten mit verschiedenen Zwecken ermöglichen, kann das Mischen von Ressourcen ein späteres Beheben von Leistungsproblemen erschweren, weil es bei Speicherressourcen (z. B. Azure-Dateifreigaben und Blobcontainern) gemeinsame Grenzen des Speicherkontos gibt.
Beachten Sie beim Bereitstellen von Azure-Dateifreigaben die IOPS-Einschränkungen eines Speicherkontos. Idealerweise würden Sie Dateifreigaben Speicherkonten 1:1 zuordnen. Das ist jedoch aufgrund von verschiedenen Grenzwerten und Einschränkungen (sowohl von Ihrer Organisation als auch von Azure) vielleicht nicht immer möglich. Wenn es nicht möglich ist, dass nur eine Dateifreigabe in einem Speicherkonto bereitgestellt wird, sollten Sie berücksichtigen, welche Freigaben sehr aktiv sein werden und welche Freigaben weniger aktiv sind, um sicherzustellen, dass die aktivsten Dateifreigaben nicht zusammen im gleichen Speicherkonto gruppiert werden.
Ausschließliches Bereitstellen von GPv2- und FileStorage-Konten und Aktualisieren von GPv1- und klassischen Speicherkonten, wenn sie in Ihrer Umgebung vorhanden sind.
Identität
Für den Zugriff auf eine Azure-Dateifreigabe muss deren Benutzer authentifiziert und für den Zugriff auf die Freigabe autorisiert sein. Dies erfolgt basierend auf der Identität des Benutzers, der auf die Dateifreigabe zugreift. Azure Files unterstützt die folgenden Authentifizierungsmethoden:
- Lokale Active Directory Domain Services (AD DS oder lokale AD DS): Azure Storage-Konten können über Domänenbeitritt – so wie ein Windows Server-Dateiserver oder ein NAS-Gerät – mit einer kundeneigenen Active Directory Domain Services-Instanz verknüpft werden. Sie können einen Domänencontroller lokal, auf einer Azure-VM oder sogar als VM bei einem anderen Cloudanbieter bereitstellen. Azure Files ist unabhängig vom Speicherort des Domänencontrollers. Sobald ein Speicherkonto einer Domäne beigetreten ist, kann der Endbenutzer eine Dateifreigabe mit dem Benutzerkonto einbinden, mit dem er sich bei seinem PC angemeldet hat. Bei der AD-basierten Authentifizierung wird das Kerberos-Authentifizierungsprotokoll verwendet.
- Microsoft Entra Domain Services: Microsoft Entra Domain Services bietet einen von Microsoft verwalteten Domänencontroller, der für Azure-Ressourcen verwendet werden kann. Der Domänenbeitritt Ihres Speicherkontos zu Microsoft Entra Domain Services bietet ähnliche Vorteile wie der Domänenbeitritt zu einem kundeneigenen AD DS. Diese Bereitstellungsoption ist besonders nützlich für Lift-and-Shift-Anwendungsszenarien, die AD-basierte Berechtigungen erfordern. Da Microsoft Entra Domain Services AD-basierte Authentifizierung bereitstellt, verwendet diese Option auch das Kerberos-Authentifizierungsprotokoll.
- Microsoft Entra Kerberos für Hybrididentitäten : Microsoft Entra Kerberos ermöglicht es Ihnen, Microsoft Entra ID zum Authentifizieren von Hybridbenutzeridentitäten zu verwenden. Das sind lokale AD-Identitäten, die mit der Cloud synchronisiert werden. Diese Konfiguration verwendet Microsoft Entra ID, um Kerberos-Tickets für den Zugriff auf die Dateifreigabe mit dem SMB-Protokoll auszugeben. Dies bedeutet, dass Ihre Endbenutzer*innen über das Internet auf Azure-Dateifreigaben zugreifen können, ohne dass eine Netzwerkkonnektivität zu Domänencontrollern von VMs erforderlich ist, die in Microsoft Entra Hybrid und Microsoft Entra eingebunden sind.
- Active Directory-Authentifizierung über SMB für Linux-Clients: Azure Files unterstützt die identitätsbasierte Authentifizierung über SMB für Linux-Clients mithilfe des Kerberos-Authentifizierungsprotokolls über AD DS oder Microsoft Entra Domain Services.
- Azure-Speicherkontoschlüssel: Azure-Dateifreigaben können auch mit einem Azure-Speicherkontoschlüssel bereitgestellt werden. Bei einer solchen Einbindung einer Dateifreigabe wird der Speicherkontoname als Benutzername und der Speicherkontoschlüssel als Kennwort verwendet. Die Verwendung des Speicherkontoschlüssels zum Einbinden der Azure-Dateifreigabe ist praktisch ein Administratorvorgang, weil die eingebundene Dateifreigabe vollständige Berechtigungen für sämtliche Dateien und Ordner auf der Freigabe hat – selbst wenn es bei diesen Zugriffssteuerungslisten gibt. Wenn Sie den Speicherkontoschlüssel zum Einbinden über SMB verwenden, wird das NTLMv2-Authentifizierungsprotokoll verwendet. Wenn Sie beabsichtigen, den Speicherkontoschlüssel für den Zugriff auf Ihre Azure-Dateifreigaben zu verwenden, empfehlen wir die Verwendung von privaten Endpunkten oder Dienstendpunkten, wie im Abschnitt Netzwerk beschrieben.
Für Kunden, die von lokalen Dateiservern migrieren oder neue Dateifreigaben in Azure Files erstellen, die sich wie Windows-Dateiserver oder NAS-Geräte verhalten sollen, ist der Domänenbeitritt des Speicherkontos zum kundeneigenen AD DS die empfohlene Option. Weitere Informationen zum Domänenbeitritt Ihres Speicherkontos zu einem kundeneigenen AD DS finden Sie in der Übersicht zur lokalen Active Directory Domain Services-Authentifizierung über SMB für Azure-Dateifreigaben.
Netzwerk
Das direkte Einbinden Ihrer Azure-Dateifreigabe erfordert oft einige Überlegungen zur Netzwerkkonfiguration, und zwar aus folgenden Gründen:
- Der von SMB-Dateifreigaben zur Kommunikation verwendete Port 445 wird von vielen Organisationen und Internetdienstanbietern (Internet Service Providers, ISPs) für ausgehenden (Internet-) Datenverkehr oft blockiert.
- NFS-Dateifreigaben basieren auf der Authentifizierung auf Netzwerkebene und sind deshalb nur über eingeschränkte Netzwerke zugänglich. Die Verwendung einer NFS-Dateifreigabe erfordert immer eine Ebene von Netzwerkkonfiguration.
Zum Konfigurieren von Netzwerken bietet Azure Files einen öffentlichen Internet-Endpunkt und eine Integration in Azure-Netzwerkfeatures wie Dienstendpunkte, die den öffentlichen Endpunkt auf angegebene virtuelle Netzwerke und private Endpunkte beschränken, wodurch Ihr Speicherkonto eine private IP-Adresse aus einem IP-Adressraum des virtuellen Netzwerks erhält. Für die Nutzung von öffentlichen Endpunkten oder Dienstendpunkten fallen zwar keine zusätzlichen Gebühren an, aber für private Endpunkte gelten die Standarddatenverarbeitungsraten.
Dies bedeutet, dass Sie die folgenden Netzwerkkonfigurationen berücksichtigen müssen:
- Wenn SMB das erforderliche Protokoll ist, und nur von Clients in Azure aus über SMB zugegriffen wird, ist keine spezielle Netzwerkkonfiguration erforderlich.
- Wenn SMB das erforderliche Protokoll ist und der Zugriff von lokalen Clients aus erfolgt, ist eine VPN- oder ExpressRoute-Verbindung von lokal zu Ihrem Azure-Netzwerk erforderlich, wobei Azure Files über private Endpunkte in Ihrem internen Netzwerk verfügbar gemacht wird.
- Wenn das erforderliche Protokoll NFS ist, können Sie entweder Dienstendpunkte oder private Endpunkte verwenden, um das Netzwerk auf angegebene virtuelle Netzwerke einzuschränken. Wenn Sie eine statische IP-Adresse benötigen und/oder Ihre Workload Hochverfügbarkeit erfordert, nutzen Sie einen privaten Endpunkt. Bei Dienstendpunkten kann ein seltenes Ereignis wie z. B. ein zonaler Ausfall dazu führen, dass sich die zugrunde liegende IP-Adresse des Speicherkontos ändert. Während die Daten weiterhin auf der Dateifreigabe verfügbar sind, erfordert der Client eine erneute Bereitstellung der Freigabe.
Weitere Informationen zum Konfigurieren von Netzwerken für Azure Files finden Sie unter Azure Files – Überlegungen zum Netzwerkbetrieb.
Außer der direkten Verbindung mit der Dateifreigabe über den öffentlichen Endpunkt oder eine VPN/ExpressRoute-Verbindung mit einem privaten Endpunkt bietet SMB eine zusätzliche Clientzugriffsstrategie: SMB über QUIC. SMB über QUIC bietet zero-config „SMB VPN“ für SMB-Zugriff über das QUIC-Transportprotokoll. Obwohl Azure Files SMB über QUIC nicht direkt unterstützt, können Sie einen einfachen Cache Ihrer Azure-Dateifreigaben auf einer Windows Server 2022 Azure Edition-VM mithilfe von Azure-Dateisynchronisierung erstellen. Weitere Informationen zu dieser Option finden Sie unter SMB über QUIC mit Azure-Dateisynchronisierung.
Verschlüsselung
Azure Files unterstützt zwei verschiedene Verschlüsselungstypen:
- Verschlüsselung während der Übertragung, die sich auf die Verschlüsselung bezieht, die beim Einbinden/Zugreifen auf die Azure-Dateifreigabe verwendet wird
- Verschlüsselung ruhender Daten, was sich auf die Frage, wie die Daten verschlüsselt werden, wenn sie auf dem Datenträger gespeichert werden, bezieht
Verschlüsselung während der Übertragung
Wichtig
In diesem Abschnitt wird die Verschlüsselung während der Übertragung für SMB-Freigaben behandelt. Ausführliche Informationen zur Verschlüsselung während der Übertragung mit NFS-Freigaben finden Sie unter Sicherheit und Netzwerke.
Standardmäßig ist in allen Azure-Speicherkonten die Verschlüsselung während der Übertragung aktiviert. Das bedeutet Folgendes: Wenn Sie eine Dateifreigabe über SMB einbinden oder über das FileREST-Protokoll darauf zugreifen (z. B. über das Azure-Portal, PowerShell/CLI oder Azure-SDKs), lässt Azure Files die Verbindung nur dann zu, wenn sie über SMB 3.x mit Verschlüsselung oder über HTTPS hergestellt wird. Clients, die SMB 3.x nicht unterstützen, oder Clients, die zwar SMB 3.x, aber nicht die SMB-Verschlüsselung unterstützen, können die Azure-Dateifreigabe nicht einbinden, wenn die Verschlüsselung während der Übertragung aktiviert ist. Weitere Informationen dazu, welche Betriebssysteme SMB 3.x mit Verschlüsselung unterstützen, finden Sie in der Dokumentation zu Windows, macOS und Linux. Alle aktuellen PowerShell-, CLI- und SDK-Versionen unterstützen HTTPS.
Sie können die Verschlüsselung während der Übertragung für ein Azure-Speicherkonto deaktivieren. Wenn die Verschlüsselung deaktiviert ist, lässt Azure Files auch SMB 2.1 und SMB 3.x ohne Verschlüsselung sowie nicht verschlüsselte FileREST-API-Aufrufe über HTTP zu. Der Hauptgrund für die Deaktivierung der Verschlüsselung während der Übertragung ist die Unterstützung einer Legacy-Anwendung, die unter einem älteren Betriebssystem, z. B. Windows Server 2008 R2 oder einer älteren Linux-Distribution, ausgeführt werden muss. Azure Files lässt nur SMB 2.1-Verbindungen innerhalb der gleichen Region zu, in der sich auch die Azure-Dateifreigabe befindet. Ein SMB 2.1-Client außerhalb der Azure-Region der Azure-Dateifreigabe – z. B. ein lokales System oder eine andere Azure-Region – kann nicht auf die Dateifreigabe zugreifen.
Wir empfehlen dringend, sicherzustellen, dass die Verschlüsselung von Daten während der Übertragung aktiviert ist.
Weitere Informationen zur Verschlüsselung während der Übertragung finden Sie unter Vorschreiben einer sicheren Übertragung in Azure Storage.
Verschlüsselung ruhender Daten
Alle in Azure Files gespeicherten Daten werden im Ruhezustand mithilfe der Azure-Speicherdienstverschlüsselung (Storage Service Encryption, SSE) verschlüsselt. Die Speicherdienstverschlüsselung funktioniert ähnlich wie BitLocker unter Windows: Daten werden unterhalb der Dateisystemebene verschlüsselt. Da Daten durch die Codierung auf dem Datenträger unterhalb des Dateisystems der Azure-Dateifreigabe verschlüsselt werden, benötigen Sie keinen Zugriff auf den zugrunde liegenden Schlüssel auf dem Client, um aus der Azure-Dateifreigabe zu lesen oder in diese zu schreiben. Die Verschlüsselung ruhender Daten wird auf SMB- und NFS-Protokolle angewendet.
Standardmäßig werden in Azure Files gespeicherte Daten mit von Microsoft verwalteten Schlüsseln verschlüsselt. Bei von Microsoft verwalteten Schlüsseln ist Microsoft im Besitz der Schlüssel zum Verschlüsseln/Entschlüsseln der Daten und damit dafür verantwortlich, sie in regelmäßigen Abständen zu rotieren. Sie können auch Ihre eigenen Schlüssel selbst verwalten, sodass Sie den Rotationsvorgang steuern können. Wenn Sie Ihre Dateifreigaben mit vom Kunden verwalteten Schlüsseln verschlüsseln, ist Azure Files für den Zugriff auf Ihre Schlüssel autorisiert, um Lese- und Schreibanforderungen von Ihren Clients zu erfüllen. Mit vom Kunden verwalteten Schlüsseln können Sie diese Autorisierung jederzeit widerrufen. Dies bedeutet jedoch, dass die Azure-Dateifreigabe nicht mehr über SMB oder die FileREST-API zugänglich ist.
Azure Files verwendet dasselbe Verschlüsselungsschema wie die anderen Azure-Speicherdienste, z. B. Azure Blob Storage. Weitere Informationen zur Azure-Speicherdienstverschlüsselung finden Sie unter Azure Storage-Verschlüsselung für ruhende Daten.
Schutz von Daten
Azure Files umfasst einen mehrschichtigen Ansatz, um sicherzustellen, dass Ihre Daten gesichert, wiederhergestellt und vor Sicherheitsbedrohungen geschützt werden können. Siehe Übersicht über den Schutz von Daten in Azure Files.
Vorläufiges Löschen
Das vorläufige Löschen ist eine Einstellung auf Speicherkontoebene, die es Ihnen ermöglicht, Ihre Dateifreigabe wiederherzustellen, wenn sie versehentlich gelöscht wurde. Wenn eine Dateifreigabe gelöscht wird, geht sie in einen vorläufig gelöschten Zustand über, anstatt dauerhaft gelöscht zu werden. Sie können den Zeitraum konfigurieren, in dem vorläufig gelöschte Freigaben wiederhergestellt werden können, ehe sie dauerhaft gelöscht werden, und die Löschung der Freigabe während dieses Aufbewahrungszeitraums jederzeit rückgängig machen.
Das vorläufige Löschen ist für neue Speicherkonten standardmäßig aktiviert. Wenn Sie über einen Workflow verfügen, bei dem das Löschen von Dateifreigaben üblich und zu erwarten ist, können Sie sich möglicherweise für einen kurzen Aufbewahrungszeitraum oder die Deaktivierung der Funktion für das vorläufige Löschen entscheiden.
Weitere Informationen zum vorläufigen Löschen finden Sie unter Verhindern eines versehentlichen Löschens von Azure-Dateifreigaben.
Backup
Sie können Ihre Azure-Dateifreigabe mithilfe von Freigabemomentaufnahmen sichern, die schreibgeschützte Zeitpunktwiederherstellungskopien Ihrer Freigaben sind. Momentaufnahmen sind inkrementell, d. h., sie enthalten nur so viele Daten, wie seit der vorherigen Momentaufnahme geändert wurden. Sie können bis zu 200 Momentaufnahmen pro Dateifreigabe machen und diese bis zu zehn Jahre lang aufbewahren. Sie können Momentaufnahmen entweder manuell im Azure-Portal, über PowerShell oder die Befehlszeilenschnittstelle (CLI) machen oder Azure Backup verwenden.
Im Artikel Informationen zum Sichern von Azure-Dateifreigaben finden Sie Informationen zum Planen und Aufbewahren von Momentaufnahmen. Durch die Generationenprinzipfunktionen (grandfather-father-son, GFS) können Sie täglich, wöchentlich, monatlich oder jährlich Momentaufnahmen machen, die jeweils einen eigenen Aufbewahrungszeitraum haben. Azure Backup orchestriert außerdem die Aktivierung des vorläufigen Löschens und übernimmt eine Löschsperre für ein Speicherkonto, sobald eine beliebige Dateifreigabe für die Sicherung konfiguriert ist. Schließlich stellt Azure Backup bestimmte wichtige Überwachungs- und Warnungsfunktionen bereit, durch die Kunden eine konsolidierte Ansicht ihres Sicherungsbestands haben.
Mithilfe von Azure Backup können Sie im Azure-Portal Wiederherstellungen sowohl auf Element- als auch auf Freigabeebene durchführen. Sie müssen lediglich den Wiederherstellungspunkt (eine bestimmte Momentaufnahme), die bestimmte Datei oder das bestimmte Verzeichnis und dann den Speicherort (ursprünglich oder alternativ) auswählen, in dem die Ressourcen wiederhergestellt werden sollen. Der Sicherungsdienst übernimmt das Kopieren der Momentaufnahmedaten und zeigt den Wiederherstellungsfortschritt im Portal an.
Schützen von Azure Files mit Microsoft Defender für Speicher
Microsoft Defender für Storage ist eine Azure-native Ebene der Sicherheitsintelligenz, die potentielle Bedrohungen Ihrer Speicherkonten erkennt. Es bietet umfassende Sicherheit durch die Analyse der Telemetriedaten auf Datenebene und Steuerungsebene, die von Azure Files generiert werden. Es verwendet erweiterte Bedrohungserkennungsfunktionen, die von Microsoft Threat Intelligence unterstützt werden, um kontextuelle Sicherheitsbenachrichtigungen bereitzustellen, einschließlich Schritten zur Entschärfung der erkannten Bedrohungen und zur Verhinderung zukünftiger Angriffe.
Defender für Storage analysiert kontinuierlich den Telemetriedatenstrom, der von Azure Files generiert wird. Bei Erkennung von potenziell schädlichen Aktivitäten werden Sicherheitswarnungen generiert. Diese Benachrichtigungen werden in Microsoft Defender for Cloud zusammen mit den Details der verdächtigen Aktivität sowie den entsprechenden Untersuchungsschritten, Wartungsmaßnahmen und Sicherheitsempfehlungen angezeigt.
Defender für Storage erkennt bekannte Schadsoftware wie Ransomware, Viren, Spyware und andere Schadsoftware, die auf ein Speicherkonto hochgeladen wurden, anhand des vollständigen Dateihashs (nur für die REST-API unterstützt). Dadurch wird verhindert, dass Schadsoftware in die Organisation eindringt und sich auf mehr Benutzer und Ressourcen ausbreitet. Weitere Informationen finden Sie unter Grundlegendes zu den Unterschieden zwischen Malware Scanning und Hash-Reputationsanalyse.
Defender für Storage greift nicht auf die Speicherkontodaten zu und hat keine Auswirkungen auf dessen Leistung. Sie können Microsoft Defender für Storage auf Abonnementebene (empfohlen) oder auf Ressourcenebene aktivieren.
Speicherebenen
Azure Files bietet zwei verschiedene Speichermedientarife – SSD (Solid State Drive) und HDD (Festplattenlaufwerk), sodass Sie Ihre Freigaben an die Leistungs- und Preisanforderungen Ihres jeweiligen Szenarios anpassen können:
SSD (Premium): SSD-Dateifreigaben bieten konsistent hohe Leistung und niedrige Latenz im einstelligen Millisekundenbereich für die meisten E/A-Vorgänge für besonders E/A-intensive Workloads. SSD-Dateifreigaben sind für eine Vielzahl von Workloads wie Datenbanken, Websitehosting und Entwicklungsumgebungen geeignet. SSD-Dateifreigaben können mit den Protokollen SMB(Server Message Block) und NFS (Network File System) verwendet werden. SSD-Dateifreigaben sind im Abrechnungsmodell bereitgestellt v1 verfügbar. SSD-Dateifreigaben bieten eine SLA mit höherer Verfügbarkeit als HDD-Dateifreigaben (weitere Informationen finden Sie unter „Azure Files Premium-Tarif“).
HDD (Standard): HDD-Dateifreigaben bieten eine kostengünstige Speicheroption für universelle Dateifreigaben. HDD-Dateifreigaben sind in den Abrechnungsmodellen bereitgestellt v2 und nutzungsbasierte Bezahlung verfügbar, für neue Bereitstellungen von Dateifreigaben wird jedoch „bereitgestellt v2“ empfohlen. Weitere Informationen zur SLA finden Sie auf der Seite Vereinbarung zum Servicelevel für Azure (unter „Speicherkonto“).
Berücksichtigen Sie bei der Wahl einer Medienebene für Ihre Workload Ihre Leistungs- und Nutzungsanforderungen. Wenn Ihre Workload eine einstellige Latenz erfordert oder Sie lokale SSD-Speichermedien verwenden, ist der Tarif mit SSD-Dateifreigaben wahrscheinlich die beste Lösung. Sollte eine niedrige Latenz nicht so wichtig sein (etwa bei Teamfreigaben, die aus Azure lokal eingebunden oder unter Verwendung der Azure-Dateisynchronisierung lokal zwischengespeichert werden), bieten HDD-Dateifreigaben unter Umständen ein besseres Preis-Leistungs-Verhältnis.
Nachdem Sie eine Dateifreigabe in einem Speicherkonto erstellt haben, können Sie sie nicht direkt auf eine andere Medienebene verschieben. Um beispielsweise eine HDD-Dateifreigabe auf die SSD-Medienebene zu verschieben, müssen Sie eine neue SSD-Dateifreigabe erstellen und die Daten aus Ihrer ursprünglichen Freigabe in eine neue Dateifreigabe im FileStorage-Konto kopieren. Wir empfehlen die Verwendung von AzCopy, um Daten zwischen Azure-Dateifreigaben zu kopieren. Sie können aber auch Tools wie robocopy (Windows) oder rsync (macOS und Linux) verwenden.
Weitere Informationen finden Sie unter Grundlegendes zur Azure Files-Abrechnung.
Redundanz
Um die Daten in Ihren Azure-Dateifreigaben vor Datenverlusten oder Beschädigungen zu schützen, speichert Azure Files beim Schreiben mehrere Kopien der einzelnen Dateien. Je nach Ihren Anforderungen können Sie verschiedene Grade der Redundanz wählen. Azure Files unterstützt derzeit die folgenden Datenredundanzoptionen:
- Lokal redundanter Speicher (LRS) : Bei LRS wird jede Datei in einem Azure-Speichercluster dreimal gespeichert. Dies schützt vor Datenverlusten aufgrund von Hardwarefehlern, z. B. bei einem schadhaften Laufwerk. Bei einem Katastrophenfall wie einem Brand oder einer Überschwemmung in einem Rechenzentrum ist es jedoch möglich, dass alle Replikate in einem Speicherkonto mit LRS verloren gehen oder nicht mehr wiederhergestellt werden können.
- Zonenredundanter Speicher (ZRS): Mit ZRS werden drei Kopien jeder Datei gespeichert. Diese Kopien werden jedoch physisch in drei verschiedenen Speicherclustern in verschiedenen Azure-Verfügbarkeitszonen isoliert. Verfügbarkeitszonen sind eindeutige physische Standorte in einer Azure-Region. Jede Zone besteht aus mindestens einem Rechenzentrum, dessen Stromversorgung, Kühlung und Netzwerkbetrieb unabhängig funktionieren. Ein Schreibvorgang in den Speicher wird erst akzeptiert, wenn die Daten in allen drei Verfügbarkeitszonen in die Speichercluster geschrieben wurden.
- Georedundanter Speicher (GRS): Bei GRS verfügen Sie über zwei Regionen, eine primäre und eine sekundäre Region. Dateien werden dreimal in einem Azure-Speichercluster in der primären Region gespeichert. Schreibvorgänge werden asynchron in eine von Microsoft definierte sekundäre Region repliziert. GRS bietet sechs Kopien Ihrer Daten, die auf zwei Azure-Regionen verteilt sind. Bei einem größeren Notfall, z. B. dem permanenten Verlust einer Azure-Region aufgrund einer Naturkatastrophe oder eines ähnlichen Ereignisses, führt Microsoft ein Failover durch. In diesem Fall wird die sekundäre Region zur primären Region, die alle Vorgänge bedient. Weil die Replikation zwischen der primären und der sekundären Region asynchron ist, gehen die Daten, die noch nicht in die sekundäre Region repliziert wurden, bei einem größeren Notfall verloren. Sie können auch ein manuelles Failover eines georedundanten Speicherkontos ausführen.
- Geozonenredundanter Speicher (GZRS): Sie können sich GZRS wie ZRS vorstellen, jedoch mit Georedundanz. Bei GZRS werden Dateien dreimal in drei verschiedenen Speicherclustern in der primären Region gespeichert. Alle Schreibvorgänge werden dann asynchron in eine von Microsoft definierte sekundäre Region repliziert. Der Failoverprozess für GZRS funktioniert genauso wie bei GRS.
Standard-Azure-Dateifreigaben bis zu 5 TiB unterstützen alle vier Redundanztypen. Standarddateifreigaben über 5 TiB unterstützen nur LRS and ZRS. Azure-Premium-Dateifreigaben unterstützen nur LRS und ZRS.
Speicherkonten der universellen Version 2 (GPv2) bieten zwei weitere Redundanzoptionen, die Azure Files nicht unterstützt: georedundanter Speicher mit Lesezugriff (RA-GRS) und geozonenredundanter Speicher mit Lesezugriff (RA-GZRS). Sie können Azure-Dateifreigaben in Speicherkonten mit diesen Optionen bereitstellen, Azure Files unterstützt jedoch nicht das Lesen aus der sekundären Region. Azure-Dateifreigaben, die in RA-GRS- oder RA-GZRS-Speicherkonten bereitgestellt werden, werden als GRS bzw. GZRS abgerechnet.
Weitere Informationen zu Redundanz finden Sie unter Azure Files-Datenredundanz.
Standard-ZRS-Verfügbarkeit
ZRS für Standardspeicherkonten vom Typ „Universell V2“ steht für eine Teilmenge von Azure-Regionen zur Verfügung.
Premium ZRS-Verfügbarkeit
ZRS für Premium-Dateifreigaben ist für eine Teilmenge von Azure-Regionen verfügbar.
Standard-GZRS-Verfügbarkeit
GZRS ist für eine Teilmenge von Azure-Regionen verfügbar.
Notfallwiederherstellung und Failover
Im Falle eines ungeplanten regionalen Dienstausfalls sollten Sie über einen Notfallwiederherstellungsplan für Ihre Azure-Dateifreigaben verfügen. Informationen zu den Konzepten und Prozessen, die mit dem Failover von Notfallwiederherstellung und Speicherkonten verbunden sind, finden Sie unter Notfallwiederherstellung und Failover für Azure Files.
Migration
In vielen Fällen werden Sie keine ganz neue Dateifreigabe für Ihre Organisation einrichten, sondern stattdessen eine vorhandene Dateifreigabe von einem lokalen Dateiserver oder NAS-Gerät zu Azure Files migrieren. Für den Erfolg der Migration ist es wichtig, die richtige Migrationsstrategie und das richtige Tool für Ihr Szenario auszuwählen.
DerArtikel zur Migrationsübersicht behandelt kurz die Grundlagen und enthält eine Tabelle, die Verweise auf Migrationsleitfäden enthält, die Ihr Szenario wahrscheinlich abdecken.