WEBVTT

00:00:00.210 --> 00:00:07.130
Bereit für 10 Tage voller Microsoft 365, Co-Pilot, KI, Azure und den Menschen, die die Zukunft der Arbeit gestalten, halten.

00:00:07.870 --> 00:00:11.510
Diesen Januar ist die M365-Con zurück und wir legen noch eins drauf.

00:00:11.710 --> 00:00:12.010
Always.

00:00:12.870 --> 00:00:17.970
Seien Sie bei Live-Sessions, Praxis-Demos und Expertenwissen von MVPs und Branchenprofis weltweit dabei, dabei.

00:00:18.830 --> 00:00:21.210
Keine generischen Folien, kein endloses Buzzword-Bingo.

00:00:22.070 --> 00:00:23.390
Wir gehen echte Herausforderungen an.

00:00:23.730 --> 00:00:28.490
Co-Pilot Studio, KI-Agenten, Fabric, Sicherheit, Governance und Automatisierung.

00:00:28.490 --> 00:00:34.070
Ob IT-Profi, Entwickler oder Führungskraft, wir haben Sessions, die genau auf Sie zugeschnitten sind.

00:00:34.310 --> 00:00:39.910
An 10 vollen Tagen können Sie Technologien erkunden und sich mit einer globalen Community vernetzen.

00:00:40.930 --> 00:00:44.250
Schauen Sie live zu und nehmen Sie praktische Erkenntnisse mit in Ihr Unternehmen.

00:00:45.150 --> 00:00:48.950
Januar 2027, 10 Tage, eine Microsoft-Community.

00:00:49.390 --> 00:00:50.510
Die Registrierung ist jetzt geöffnet.

00:00:51.910 --> 00:00:54.090
Sichern Sie sich noch heute Ihren Platz.

00:00:54.510 --> 00:00:55.290
Ihren Platz.

00:00:55.290 --> 00:00:58.610
Besuchen Sie mtrainer 5.6chan.net.

00:01:00.150 --> 00:01:02.910
Melden Sie sich jetzt auf m365.com.net an.

00:01:03.010 --> 00:01:04.530
Wir sehen uns live im Januar.

00:01:05.330 --> 00:01:07.290
Azure bietet bereits zahlreiche Speicheroptionen.

00:01:07.450 --> 00:01:08.370
Blob, Files, Disk.

00:01:09.330 --> 00:01:11.050
Warum gibt es also überhaupt Azure Net App Files?

00:01:11.530 --> 00:01:14.210
Das ist die erste Frage, die Leute stellen und sie ist absolut berechtigt.

00:01:14.790 --> 00:01:18.570
Microsoft fügt ständig neue Speicherdienste hinzu, fast als gäbe es jedes Quartal eine neue Option.

00:01:18.990 --> 00:01:19.710
Warum also eine weitere?

00:01:19.990 --> 00:01:20.410
Hier ist der Punkt.

00:01:20.410 --> 00:01:23.110
Die meisten Azure-Speicherdienste bewältigen allgemeine Anforderungen.

00:01:23.630 --> 00:01:27.370
Web-Apps, Dateifreigaben, Backups, die alltäglichen Dinge, die ein Geschäft am Laufen halten.

00:01:27.870 --> 00:01:29.530
Aber manche Workloads passen nicht in dieses Schema.

00:01:29.890 --> 00:01:31.330
Sie benötigen extrem hohe Geschwindigkeiten.

00:01:31.630 --> 00:01:35.090
Konsistente Leistung unter Last, bei der jede Millisekunde Verzögerung zählt.

00:01:35.910 --> 00:01:38.530
Azure Net App Files wurde speziell für solche Workloads entwickelt.

00:01:38.530 --> 00:01:44.330
Am Ende dieser Folge wissen Sie genau, was ANF ist, wann Sie es nutzen und wann Sie bei etwas Einfacherem bleiben sollten.

00:01:45.410 --> 00:01:49.030
Wir klären, was es ist, nennen die drei Hauptanwendungsfälle und vergleichen es mit Azure Files.

00:01:49.950 --> 00:01:51.350
Beginnen wir mit einer einfachen Definition.

00:01:52.350 --> 00:01:53.890
Was Azure Net App Files eigentlich ist?

00:01:54.990 --> 00:01:59.350
Azure Net App Files ist ein verwalteter Hochleistungs-Enterprise-Dateispeicher-Dienst direkt in Azure.

00:02:00.210 --> 00:02:02.870
Das ist kein dritter Anbieter-Add-on oder etwas, das Sie nachträglich hinzufügen.

00:02:03.450 --> 00:02:06.490
Es ist ein First-Party-Microsoft-Dienst, der vollständig in das Azure-Portal integriert ist.

00:02:06.490 --> 00:02:09.770
Das unterscheidet es aber. Unter der Haube läuft es mit Net App-Technologie.

00:02:10.830 --> 00:02:13.770
Dasselbe Speichersystem, das seit Jahrzehnten lokale Rechenzentren antreibt.

00:02:14.430 --> 00:02:17.330
Net App bietet schon seit den 1990er Jahren Enterprise-Dateispeicherungen.

00:02:17.890 --> 00:02:19.450
Sie verstehen schnelle und zuverlässige Daten.

00:02:20.130 --> 00:02:24.070
Microsoft ging eine Partnerschaft ein, um diese Expertise als verwalteten Dienst nach Azure zu bringen.

00:02:24.810 --> 00:02:25.490
Was bedeutet das für Sie?

00:02:25.950 --> 00:02:29.130
ANF unterstützt ab Werk sowohl SMB- als auch NFS-Protokolle.

00:02:29.610 --> 00:02:32.170
Windows Workloads, Linux Workloads ist beherrscht beides.

00:02:32.870 --> 00:02:34.130
Sie müssen sich nicht für das andere entscheiden.

00:02:34.130 --> 00:02:36.890
Dasselbe Volume kann bei Bedarf beide Arten von Clients bedienen.

00:02:37.390 --> 00:02:38.810
Bei der Performance sticht es wirklich hervor.

00:02:39.270 --> 00:02:41.850
Wir sprechen von Latenzzeiten unter einer Millisekunde und massiven Durchsatz.

00:02:42.250 --> 00:02:42.790
Nicht schnell genug.

00:02:43.470 --> 00:02:44.530
Es ist wirklich rasend schnell.

00:02:45.490 --> 00:02:46.030
Hier ist ein Verdeichen.

00:02:46.410 --> 00:02:49.190
Wenn Azure-Files die zuverlässige Familienkutsche ist, die Sie ans Ziel bringt,

00:02:49.270 --> 00:02:54.150
dann ist Azure Net App-Files der Sportwagen, ähm, auf Geschwindigkeit ausgelegt und mit einem Handling wie nichts anderes in der Garten.

00:02:54.490 --> 00:02:55.790
Und das Beste daran ist vollständig verwaltet.

00:02:56.170 --> 00:02:57.670
Kein Patchen von Servern, kein Hardware-Austausch.

00:02:58.130 --> 00:03:01.470
Sie erstellen einfach ein Volume, wählen Ihre Performance-Stufe und können loslegen.

00:03:01.470 --> 00:03:03.310
Azure und Net App kümmern sich um den Rest.

00:03:03.650 --> 00:03:05.270
Aber warum braucht man einen Sportwagen für den Speicher?

00:03:05.570 --> 00:03:07.690
Schauen wir uns die Probleme an, die normaler Speicher nicht lösen kann.

00:03:09.560 --> 00:03:11.480
Die Probleme, die herkömmlicher Speicher nicht lösen kann.

00:03:12.080 --> 00:03:14.340
Die meisten Cloud-Speicher bewältigen die tägliche IT-Problem-Rost.

00:03:14.760 --> 00:03:16.260
Web-Apps, Dateifreigaben, Backups.

00:03:16.860 --> 00:03:17.740
Die meisten Leute reicht das aus.

00:03:18.040 --> 00:03:20.200
Man braucht keinen Formel-1-Motor, um zum Supermarkt zu fahren.

00:03:20.880 --> 00:03:22.020
Aber manche Workloads sind anders.

00:03:22.500 --> 00:03:26.160
Dellen Sie sich diese wie anspruchsvolle Athleten vor, die jede Millisekunde brauchen und es sich nicht leisten können zu warten.

00:03:26.460 --> 00:03:26.900
Hier ist das Problem.

00:03:26.900 --> 00:03:33.220
Ein paar zusätzliche Millisekunden beim Schreiben eines Logs können ein ganzes Transaktionssystem verlangsamen.

00:03:33.640 --> 00:03:37.340
Geringer Durchsatz drosselt Simulation und lässt Jobs, die Stunden dauern, sollten Tage in Anspruch nehmen.

00:03:37.800 --> 00:03:39.200
Inkonsistente EOPs sind ein weiteres Problem.

00:03:39.540 --> 00:03:40.920
Das frustriert VDI-Benutzer am meisten.

00:03:41.440 --> 00:03:42.460
In einer Minute ist alles in Ordnung.

00:03:42.820 --> 00:03:44.980
Im nächsten Moment hängt der Desktop, weil der Speicher nicht hinterherkommt.

00:03:45.380 --> 00:03:46.720
Lassen Sie mich ein konkretes Beispiel geben.

00:03:47.120 --> 00:03:51.440
Ein 2,3-Tilby-Backup einer SAP-HANA-Datenbank auf herkömmlichem Speicher kann eine Stunde dauern.

00:03:51.960 --> 00:03:53.440
Das ist eine Stunde Wartung potenzieller Problem.

00:03:53.440 --> 00:03:56.780
Mit Azure NetApp Files ist dasselbe Backup in zwei Minuten fertig.

00:03:57.440 --> 00:03:58.440
Kein Tippfehler, zwei Minuten.

00:03:59.020 --> 00:04:00.600
Das Problem ist nicht, dass Azure Files schlecht wäre.

00:04:01.200 --> 00:04:05.220
Es ist ein großartiger Dienst für seinen Einsatzzweck, aber er ist auf Kosten optimiert, nicht auf Spitzenleistung.

00:04:05.720 --> 00:04:09.360
Bietet eine ausreichende Geschwindigkeit zu einem vernünftigen Preis, was für die meisten Workloads gut ist, aber eben nicht fad.

00:04:09.600 --> 00:04:10.920
Azure NetApp Files schließt diese Lücke.

00:04:11.480 --> 00:04:14.500
Es wurde für Workloads entwickelt, die keine Kompromisse bei Geschwindigkeit oder Konsistenz eingehen.

00:04:14.820 --> 00:04:16.780
Wenn jede Millisekunde zählt, ist ANF die Antwort.

00:04:17.260 --> 00:04:18.820
Wer braucht also wirklich diese Art von Performance?

00:04:19.260 --> 00:04:20.840
Beginnen wir mit einem der größten Anwender.

00:04:21.040 --> 00:04:21.800
SAP HANA.

00:04:21.800 --> 00:04:31.180
Wenn Sie nicht in der Welt der Unternehmensdatenbanken zu Hause sind, haben Sie vielleicht noch nichts davon gehört, aber es ist einer der anspruchsvollsten Workloads, die man in der Cloud betreibt.

00:04:31.520 --> 00:04:33.140
SAP HANA ist eine In-Memory-Datenbank.

00:04:33.380 --> 00:04:35.740
Das bedeutet, dass sie zur Geschwindigkeitssteigerung alle Daten im Rahmen speichert.

00:04:36.080 --> 00:04:40.700
Doch obwohl die Daten im Arbeitsspeicher liegen, benötigt HANA ultraschnellen Speicher für Protokolle, Backups und Snapshots.

00:04:41.020 --> 00:04:42.820
Diese Schreibvorgänge müssen schnell und zuverlässig erfolgen.

00:04:43.180 --> 00:04:45.240
Wenn der Speicher nicht mithalten kann, verlangsamt sich die gesamte Daten.

00:04:45.620 --> 00:04:48.060
Deshalb ist Azure NetApp Files von SAP zertifiziert.

00:04:48.060 --> 00:04:54.780
Es ist im offiziellen SAP HANA-Hardware-Verzeichnis gelistet, was bedeutet, dass es von SAP selbst getestet und freigegeben wurde.

00:04:55.340 --> 00:04:55.980
Das ist keine Kleinigkeit.

00:04:56.440 --> 00:04:58.560
SAP zertifiziert nicht einfach irgendeine Speicherlösung.

00:04:59.340 --> 00:05:02.000
Sie testen gründlich und nur die Lösungen, die bestehen, kommen auf die Liste.

00:05:02.540 --> 00:05:03.860
Von welcher Art von Leistung sprechen wir hier?

00:05:04.480 --> 00:05:09.380
Konstante Latenzzeiten unter einer Millisekunde und bis zu 4,5 GB pro Sekunde Durchsatz pro Volume.

00:05:09.380 --> 00:05:17.200
Um das einzuordnen, SAPs Mindestanforderung für HANA-Lock-Schreibvorgänge liegt bei unter einer Millisekunde Latenz und ANF liegt komfortabel unter diesem Schwellenwert.

00:05:18.000 --> 00:05:21.680
Das ist wichtig, da eine Latenz von über einer Millisekunde Datenbanktransaktionen verlangsamen kann.

00:05:22.560 --> 00:05:26.100
Wenn Sie Tausende von Transaktionen pro Sekunde verarbeiten, summiert sich jede zusätzliche Millisekunde.

00:05:26.600 --> 00:05:30.180
Microsoft hat sogar ein spezielles Bereitstellungstool namens Application Volume Group für HANA entwickelt.

00:05:30.180 --> 00:05:36.440
Es optimiert das Volume-Layout, indem es Sie über mehrere Speicherendpunkte verteilt, sodass kein einzelner Endpunkt zum Flaschenhals wird.

00:05:37.200 --> 00:05:40.360
Stellen Sie es sich wie mehrere Spuren auf einer Autobahn anstelle einer schmalen Straße vor.

00:05:40.860 --> 00:05:42.320
Und die Backup-Zahlen sind ebenfalls erwähnenswert.

00:05:42.880 --> 00:05:45.960
Ein 2,3 TB HANA-Backup ist auf ANF in etwa 2 Minuten ab.

00:05:46.500 --> 00:05:49.540
Auf herkömmlichem Speicher könnte dasselbe Backup 30 bis 60 Minuten dauern.

00:05:50.220 --> 00:05:53.160
Das ist nicht nur praktisch, es verändert, was mit Ihren Backup-Fenstern möglich ist.

00:05:53.640 --> 00:05:54.740
Auch die Kostenseite ist interessant.

00:05:55.040 --> 00:05:59.880
Mit flexiblen Service-Levels können Sie die Leistung exakt an die Bedürfnisse von HANA anpassen, ohne Überprovisionierung.

00:06:00.400 --> 00:06:03.160
Sie zahlen nicht für zusätzliche Kapazitäten, um den benötigten Durchsatz zu erhalten.

00:06:03.940 --> 00:06:09.200
SAP ist ein großer Anwendungsfall, aber ANF unterstützt auch eine ganz andere Art von Arbeitslast, High-Performance Computing.

00:06:10.140 --> 00:06:11.760
High-Performance Computing, HPC

00:06:11.760 --> 00:06:14.440
High-Performance Computing deckt ein weites Feld ab.

00:06:15.340 --> 00:06:18.040
Simulationen, Rendering, Finanzmodellierung, wissenschaftliche Forschung.

00:06:18.480 --> 00:06:22.360
Alles, wo Sie massiv parallele Jobs über hunderte oder tausende von Rechenknoten ausführen.

00:06:23.160 --> 00:06:25.120
Diese Arbeitslasten haben einen ganz spezifischen Bedarf.

00:06:25.500 --> 00:06:28.200
Sie benötigen gemeinsamen Dateizugriff mit hohem Durchsatz und niedriger Latenz.

00:06:28.200 --> 00:06:31.380
Mehrere Knoten müssen gleichzeitig dieselben Datensätze lesen und schreiben.

00:06:31.880 --> 00:06:35.200
Wenn Ihr Speicher nicht mithalten kann, warten Ihre Rechenknoten untätig auf Daten.

00:06:35.780 --> 00:06:37.380
Und ungenutzte Rechenzeit ist verschwendetes Geld.

00:06:38.640 --> 00:06:44.360
Azure NetApp Files liefert in Benchmark-Tests bis zu 56.000 IOPS bei unter 2 Millisekunden Latenz.

00:06:44.980 --> 00:06:46.940
Das sind viele Ein-Slash-Ausgabe-Operationen.

00:06:47.040 --> 00:06:49.640
Und es ist schnell genug, dass der Speicher selten noch zum Flaschenhals wird.

00:06:49.640 --> 00:06:53.220
Für wirklich große Datensätze gibt es die Funktionen für große Volumes.

00:06:53.620 --> 00:06:56.160
Es unterstützt Kapazitäten von bis zu 2 Petabyte pro Volume.

00:06:56.600 --> 00:06:58.400
Das sind 2000 Terabyte in einem einzigen Volume.

00:06:58.860 --> 00:07:02.260
Überlegen Sie, was das für ein Forschungsteam bedeutet, das mit riesigen Simulationsergebnissen arbeitet.

00:07:02.560 --> 00:07:04.640
Oder für ein Medienstudio, das ein Medienstudio, das ein Spielfilm macht.

00:07:04.740 --> 00:07:05.780
Dann gibt es noch den Breakthrough-Modus.

00:07:06.140 --> 00:07:09.520
Er steigert den Durchsatz auf bis zu 50 Gigabit pro Sekunde aus einem einzigen großen Volume.

00:07:09.860 --> 00:07:12.200
Das ist genug Bandbreite, um enorme Datensätze schnell zu verschieben.

00:07:12.200 --> 00:07:13.560
Hier ist ein Beispiel aus der Praxis.

00:07:14.220 --> 00:07:18.020
Electronic Design Automation, kurz EDA, in der Chip-Design-Industrie.

00:07:18.960 --> 00:07:22.180
Unternehmen wie NVIDIA und AMD führen tausende von Simulationen gleichzeitig aus,

00:07:22.260 --> 00:07:24.080
um Chip-Designs vor der Fertigung zu verifizieren.

00:07:24.600 --> 00:07:26.440
Jede Simulation liest und schreibt gemeinsam, benutzt du dann.

00:07:26.980 --> 00:07:29.800
Das Speichersystem muss diese gleichzeitige Last bewältigen, ohne langsamer zu werden.

00:07:30.300 --> 00:07:31.880
ANF ist genau für dieses Muster ausgelegt.

00:07:32.360 --> 00:07:33.980
Warum also nicht einfach Azure Files dafür wenden?

00:07:34.320 --> 00:07:36.600
Weil Azure Files Durchsatzbeschränkungen auf Dateiebene hat.

00:07:36.740 --> 00:07:38.720
300 Megabyte pro Sekunde Egress pro Datei.

00:07:38.780 --> 00:07:41.320
Das bedeutet, selbst wenn ihr Speicher-Backend mehr Kapazität hat,

00:07:41.320 --> 00:07:43.680
kann eine einzelne große Datei dieses Limit nicht überschreiten.

00:07:44.060 --> 00:07:45.420
ANF hat keine Begrenzung auf Dateien.

00:07:45.780 --> 00:07:47.540
Jede Datei kann die Netzwerkverbindung auslassen.

00:07:47.980 --> 00:07:50.960
Bei Workloads, die mit großen Simulationsdateien arbeiten, ist dieser Unterschied entscheidend.

00:07:51.880 --> 00:07:58.300
Microsoft empfiehlt ANF für HPC-Workloads bis zu etwa 4000 Kernen und 6,5 Gigabyte pro Sekunde Durchsatz.

00:07:59.500 --> 00:08:02.300
Darüber hinaus benötigen sie möglicherweise eine andere Architektur,

00:08:02.440 --> 00:08:05.080
aber für die große Mehrheit der HPC-Szenarien ist ANF ideal.

00:08:05.960 --> 00:08:10.280
Dritter wichtiger Anwendungsfall, Virtual Desktop Infrastructure, wo die Benutzererfahrung alles ist.

00:08:10.280 --> 00:08:12.600
Virtual Desktop Infrastructure, VDI

00:08:12.600 --> 00:08:15.600
Lassen Sie uns nun über etwas sprechen, das fast jeden betrifft.

00:08:15.840 --> 00:08:16.820
Die Desktop-Erfahrung.

00:08:17.300 --> 00:08:21.080
Virtual Desktop Infrastructure oder VDI bedeutet, Windows-Desktops in der Cloud zu hosten.

00:08:21.540 --> 00:08:23.140
Denken Sie an Azure Virtual Desktop oder Citrix.

00:08:23.920 --> 00:08:26.020
Anstatt einen vollständigen PC auf Ihrem Schreibtisch zu betreiben,

00:08:26.140 --> 00:08:28.760
befindet sich der Desktop auf einem Server irgendwo und Sie verbinden sich remote damit.

00:08:29.300 --> 00:08:30.060
Hier liegt die Herausforderung.

00:08:30.620 --> 00:08:33.620
Benutzerprofile und App-Daten müssen zentral gespeichert und schnell abrufbar sein.

00:08:33.620 --> 00:08:36.640
Jedes Mal, wenn sich jemand anmeldet, muss das Profil geladen werden.

00:08:36.940 --> 00:08:38.460
Einstellungen, Dateien, Anwendungsdaten.

00:08:39.220 --> 00:08:43.220
Wenn dieser Speicher langsam ist, ist die Anmeldung langsam und langsame Anmeldungen machen Benutzer sehr schnell unzufrieden.

00:08:43.660 --> 00:08:45.140
Und hier macht ANF einen echten Unterschied.

00:08:45.820 --> 00:08:49.580
Lange Ladezeiten für Profile sind seit Jahren die häufigste Beschwerde bei VDI-Bereitstellung.

00:08:50.120 --> 00:08:52.140
Benutzer vergleichen sie mit ihrem alten lokalen Desktop.

00:08:52.140 --> 00:08:55.380
Und wenn die Cloud-Version sich langsamer anfühlt, bemerken sie das sofort.

00:08:56.020 --> 00:08:59.020
Azure NetApp-Files löst dies mit hohen IOPs und geringer Latenz.

00:08:59.020 --> 00:09:01.040
Und ich spreche hier nicht von theoretischen Verbesserungen.

00:09:01.940 --> 00:09:06.480
Praxisergebnisse zeigen, dass die Anmeldezeiten von 20 bis 30 Sekunden auf unter 5 Sekunden sinken,

00:09:06.540 --> 00:09:09.700
wenn Unternehmen für ihre Profilspeicherung von Azure Files auf ANF umsteigen.

00:09:10.300 --> 00:09:12.220
Das ist die Art von Verbesserung, die Benutzer tatsächlich spüren.

00:09:12.540 --> 00:09:13.400
Warum funktioniert das so gut?

00:09:13.760 --> 00:09:17.300
Weil ANF bis zu 450.000 IOPs pro Volume unterstützt.

00:09:17.780 --> 00:09:21.020
Das ist wichtig, wenn sich morgens Hunderte von Benutzern gleichzeitig anmelden.

00:09:21.700 --> 00:09:22.540
Das nennt man Logonstorm.

00:09:22.980 --> 00:09:24.040
Alle kommen um 9 Uhr an.

00:09:24.460 --> 00:09:26.720
Und plötzlich müssen alle Profile gleichzeitig geladen werden.

00:09:26.720 --> 00:09:30.300
Ein Speichersystem, das diese Parallelität nicht bewältigt, bremst alle aus.

00:09:30.960 --> 00:09:31.820
ANF bewältigt das.

00:09:32.500 --> 00:09:34.340
Es gibt mal ein weiteres Feature, das für VAUD nützlich ist.

00:09:35.160 --> 00:09:37.660
ANF unterstützt bis zu 250 Snapshots pro Volume.

00:09:38.160 --> 00:09:41.460
Das bedeutet, Sie können das Profil eines Benutzers sofort auf den Stand von gestern zurücksetzen.

00:09:41.960 --> 00:09:44.860
Wenn ein Profil beschädigt wird oder ein fehlerhaftes Update-Probleme verursacht,

00:09:44.920 --> 00:09:46.420
müssen Sie nicht aus einem Backup wiederherstellen.

00:09:46.800 --> 00:09:48.840
Sie verweisen einfach auf den Snapshot von gestern und das war's.

00:09:49.060 --> 00:09:50.420
Das spart Stunden an Supportzeit.

00:09:50.860 --> 00:09:52.440
Und der Zuverlässigkeitsfaktor ist ebenfalls wichtig.

00:09:53.100 --> 00:09:55.720
ANF bietet eine Verfügbarkeits-SLA von 9,99%.

00:09:55.720 --> 00:09:59.720
Bei geschäftskritischen VDI-Bereitstellungen, wo Ausfallzeiten Produktivitätsverluste bedeuten,

00:09:59.800 --> 00:10:01.240
ist dieses Maß an Zuverlässigkeit unerlässlich.

00:10:01.540 --> 00:10:03.020
Hier ist ein Kostenaspekt, den Sie vielleicht nicht erwarten.

00:10:03.440 --> 00:10:06.600
Da ANF so schnell ist, können Sie tatsächlich kleinere, günstigere, virtuelle Maschinen verwenden

00:10:06.600 --> 00:10:07.880
und erhalten dennoch eine gute Leistung.

00:10:08.220 --> 00:10:10.620
Der Speicher übernimmt die Hauptarbeit, sodass die Rechenleistung entlastet wird.

00:10:11.020 --> 00:10:13.040
Das kann einen Teil der Kosten für den Prämenspeicher ausgleichen.

00:10:13.840 --> 00:10:16.240
Sie kennen nun die drei Säulen, SAP, HPC, VDI.

00:10:17.040 --> 00:10:19.660
Doch wie schlägt sich ANF im Vergleich zu seinem Pendant Azure Files?

00:10:20.100 --> 00:10:22.660
Wie Azure NetApp Files im Vergleich zu Azure Files abschneidet.

00:10:22.660 --> 00:10:26.400
Sowohl Azure NetApp Files als auch Azure Files sind verwaltete Dateifreigaben in Azure.

00:10:26.940 --> 00:10:29.000
Das bedeutet, Sie müssen keine Serverpatchen oder Hardware ersetzen.

00:10:29.720 --> 00:10:31.480
Der eigentliche Unterschied liegt in Leistung und Preis.

00:10:32.280 --> 00:10:33.160
Vergleichen wir die reinen Zahlen.

00:10:33.800 --> 00:10:36.560
Azure Files Premium ist auf 100.000 EOPS pro Freigabe begrenzt,

00:10:36.620 --> 00:10:38.080
was für viele Workloads völlig ausreicht.

00:10:38.840 --> 00:10:41.560
ANF erreicht jedoch bis zu 450.000 EOPS pro Volume,

00:10:41.680 --> 00:10:43.040
mehr als das Vierfache dieser Obergrenze.

00:10:43.480 --> 00:10:46.280
Wenn Sie Workloads ausführen, die einen hohen gleichzeitigen Zugriff erfordern,

00:10:46.340 --> 00:10:47.600
macht dieser Unterschied wirklich etwas aus.

00:10:47.600 --> 00:10:49.440
Bei der Latenz zeigt sich ein ähnliches Bild.

00:10:49.940 --> 00:10:52.000
Azure Files Standard liegt bei etwa 10 Millisekunden

00:10:52.000 --> 00:10:54.160
und Premium senkt dies auf 2 bis 3 Millisekunden.

00:10:54.860 --> 00:10:58.400
Das ist respektabel, aber ANF liefert eine Latenz im Sub-Millisekunden-Bereich

00:10:58.400 --> 00:11:00.340
etwa 0,5 Millisekunden im Ultratier.

00:11:00.780 --> 00:11:03.160
Das ist der Unterschied zwischen einem Speicher, der ein kleiner Faktor ist,

00:11:03.220 --> 00:11:04.600
und einem, der im Grunde unsichtbar bleibt.

00:11:05.120 --> 00:11:06.800
Beim Durchsatz wird der Unterschied noch deutlicher.

00:11:07.700 --> 00:11:09.480
Azure Files hat Obergrenzen auf Dateiebene.

00:11:09.700 --> 00:11:13.580
300 MB pro Sekunde ausgehend und 200 MB pro Sekunde eingehend pro Datei.

00:11:13.580 --> 00:11:15.800
Selbst wenn Ihr Backend mehr Kapazität bietet,

00:11:15.980 --> 00:11:18.340
kann eine einzelne große Datei dieses Limit nicht überschreiten.

00:11:18.820 --> 00:11:20.400
ANF hat keine Begrenzungen auf Dateiebene.

00:11:20.800 --> 00:11:23.240
Jede Datei kann so viel Durchsatz nutzen, wie das Netzwerk zulässt.

00:11:23.780 --> 00:11:24.780
Wie sieht es mit der Maximalfreigabe?

00:11:25.200 --> 00:11:27.320
Azure Files ist auf 100 TB pro Freigabe begrenzt.

00:11:27.820 --> 00:11:29.660
ANF geht mit großen Volumes bis zu 2 PB.

00:11:30.260 --> 00:11:31.540
Das ist die 20-fache Kapazität.

00:11:32.120 --> 00:11:33.100
Also wann setzen Sie was ein?

00:11:33.520 --> 00:11:35.940
Azure Files ist die richtige Wahl für allgemeine Dateifreigaben,

00:11:36.020 --> 00:11:38.700
Abteilungsfreigaben, Backup-Ziele und kostensensible Workloads.

00:11:39.300 --> 00:11:40.280
Stellen Sie sich in einer Limousine vor.

00:11:40.840 --> 00:11:42.320
Zuverlässig, erschwinglich erledigt die Arbeit.

00:11:42.320 --> 00:11:45.660
ANF ist für Workloads gedacht, bei denen Latenz und Durchsatz entscheidend sind.

00:11:46.180 --> 00:11:49.000
SAP, HANA, Oracle, SQL Server, HPC, VDI.

00:11:49.480 --> 00:11:51.940
Jedes Szenario, in dem Sub-Millisekunden-Latenz und hohe IOPs

00:11:51.940 --> 00:11:53.500
einen echten Unterschied bei der Anwendungsleistung machen.

00:11:54.080 --> 00:11:55.100
Kommen wir nun zu den Kosten.

00:11:55.520 --> 00:11:58.040
Azure Files ist für die meisten Anwendungsfälle günstiger und das ist beabsichtig.

00:11:58.500 --> 00:12:00.680
ANF kann jedoch in bestimmten Szenarien tatsächlich Geld sparen.

00:12:01.400 --> 00:12:04.480
Wenn Sie dadurch kleinere VMs verwenden können, weil der Speicher schneller ist,

00:12:04.660 --> 00:12:05.600
sparen Sie Rechenkosten.

00:12:06.660 --> 00:12:09.660
Wenn es eine Überbereitstellung von Kapazität nur für ausreichend Durchsatz verhindert,

00:12:09.660 --> 00:12:10.600
sparen Sie Speicherkosten.

00:12:10.600 --> 00:12:13.140
Das Gesamtbild der Kosten ist also nicht immer direkt ersichtlich.

00:12:13.520 --> 00:12:15.600
Es gibt eine Funktion, die die Kostenrechnung grundlegend verändert.

00:12:16.260 --> 00:12:17.360
Die flexible Serviceebene.

00:12:18.300 --> 00:12:20.840
Die flexible Serviceebene sorgt für eine leistungsgerechte Dimension.

00:12:21.340 --> 00:12:22.880
Hier ist eine Funktion, die die Kostenrechnung verändert.

00:12:23.460 --> 00:12:26.140
Traditionell hatten ANF-Kapazitätspools ein festes Verhältnis.

00:12:26.640 --> 00:12:28.700
Je größer Ihr Pool, desto mehr Durchsatz erhielten Sie.

00:12:29.160 --> 00:12:30.880
Je kleiner der Pool, desto geringer war der Durchsatz.

00:12:31.600 --> 00:12:34.140
Das klingt oberflächlich betrachtet vernünftig, führt aber zu einem echten Problem.

00:12:34.580 --> 00:12:36.240
Stellen Sie sich vor, Sie haben eine kleine Datenbank.

00:12:36.240 --> 00:12:39.040
Sagen wir ein Täter weit, die für den wahlungsgemäßen Betrieb jedoch einen hohen Durchsatz bildet.

00:12:39.040 --> 00:12:42.900
Nach dem alten Modell mussten Sie Kapazität übermäßig bereitstellen, nur um genügend Leistung zu erhalten.

00:12:43.400 --> 00:12:47.460
Sie mussten eventuell 64 TB Speicher auf der Standardebene kaufen, nur um den Durchsatz zu erzielen,

00:12:47.540 --> 00:12:50.420
den 1 TB eigentlich benötigt, während die restlichen 63 TB leer blieben.

00:12:50.960 --> 00:12:52.440
Sie bezahlen für Speicherplatz, den Sie nicht nutzen.

00:12:52.760 --> 00:12:54.140
Das ist weder effizient noch kostennützig.

00:12:54.460 --> 00:12:56.180
Die flexible Serviceebene ändert das Grundlegen.

00:12:56.700 --> 00:12:58.220
Sie entkoppelt Kapazität von Durchsatz.

00:12:58.620 --> 00:13:00.080
Zwei unabhängige Stellschrauben statt einer.

00:13:00.760 --> 00:13:03.880
Sie entscheiden, wie viel Speicher Sie benötigen und separat wie viel Leistung Sie brauchen.

00:13:03.880 --> 00:13:05.100
Sie müssen nicht übereinstimmen.

00:13:05.540 --> 00:13:08.900
Sie können also jetzt einen 1 TB poolen mit 1 GB pro Sekunde Durchsatz haben.

00:13:09.840 --> 00:13:14.500
Nach dem alten Modell hätte die gleiche Leistung auf der Standardebene 64 TB Kapazität erfordert.

00:13:15.020 --> 00:13:16.340
Das ist ein Unterschied von 64 zu 1.

00:13:16.720 --> 00:13:19.300
Mit der flexiblen Serviceebene zahlen Sie genau für das, was Sie benötigen.

00:13:19.600 --> 00:13:20.660
Die Kosteneinsparungen sind real.

00:13:21.060 --> 00:13:25.700
In vielen Szenarien sparen Sie 30% oder mehr im Vergleich zur Nutzung der Ultraebene für dieselbe Leistung.

00:13:26.140 --> 00:13:28.600
Und das, bevor Sie Rabatte für reservierte Kapazitäten einberechnen.

00:13:29.100 --> 00:13:31.140
Das Disaster Recovery Szenario macht dies noch deutlicher.

00:13:31.140 --> 00:13:34.380
Nehmen wir an, Sie benötigen 100 TB Kapazität für einen DR-Standort.

00:13:34.720 --> 00:13:37.280
Aber Sie benötigen erst bei einem tatsächlichen Failover viel Durchsatz.

00:13:37.820 --> 00:13:41.160
Nach dem alten Modell müssten Sie die Leistung bereitstellen, die Sie eines Tages benötigen können.

00:13:41.720 --> 00:13:44.220
Mit dem flexiblen Servicelevel zahlen Sie nur für die Kapazität.

00:13:44.840 --> 00:13:47.720
128 MB pro Sekunde Basisdurchsatz und sonst nichts.

00:13:48.460 --> 00:13:51.320
Wenn ein Failover eintritt, skalieren Sie den Durchsatz bei Bedarf nach oben.

00:13:52.000 --> 00:13:55.280
Wenn es vorbei ist, skalieren Sie ihn nach einer 24-stündigen Abkühlphase wieder herunter.

00:13:55.900 --> 00:13:56.780
Apropos Skalierung.

00:13:57.000 --> 00:14:00.980
Sie können den Durchsatz bei Bedarf innerhalb der Grenzen erhöhen und nach 24 Stunden wieder sinken.

00:14:01.580 --> 00:14:07.880
Das ist ideal für Lastspitzen, Monatsabschlussarbeiten, Migrationsfenster und saisonale Peaks, ohne dauerhaft für extra Kapazität zu zahlen.

00:14:08.620 --> 00:14:11.460
Diese Funktion ist derzeit als Vorschau in allen ANF-Regionen verfügbar.

00:14:12.080 --> 00:14:16.740
Es ist eine der am häufigsten angefragten Erweiterungen und verändert bereits, wie Kunden über Speicherkosten denken.

00:14:17.380 --> 00:14:19.040
Das ist das flexible Servicelevel in aller Kürzen.

00:14:19.500 --> 00:14:21.240
Eine einfache Änderung, die ein großes Problem löst.

00:14:22.000 --> 00:14:23.200
Verbindungsabschnitt alles zusammengefasst.

00:14:23.200 --> 00:14:24.680
Also hier ist der Aha-Moment.

00:14:25.560 --> 00:14:27.580
Azure NetApp Files konkurriert nicht mit Azure Files.

00:14:28.240 --> 00:14:31.500
Es schließt eine spezifische Leistungslücke, die für die richtigen Workloads entscheidend ist.

00:14:32.180 --> 00:14:36.880
Die drei Anwendungsfälle, die wir besprochen haben, SAP, HANA, HPC, VDI, haben alle eines gemeinsam.

00:14:37.300 --> 00:14:40.060
Sie benötigen konsistenten, latenzarmer Hochgeschwindigkeitsdateizugriff.

00:14:40.280 --> 00:14:41.720
Das ist der rote Faden, der sich durch alle zieht.

00:14:42.180 --> 00:14:49.740
Ob Datenbanktransaktion, Simulationsjob oder Benutzeranmeldung am Desktop, der Speicher muss ohne Verzögerung liefern.

00:14:50.340 --> 00:14:50.960
Kein langes Faden.

00:14:51.500 --> 00:14:53.540
Das flexible Servicelevel macht diese Leistung bezahlbar.

00:14:54.140 --> 00:14:57.760
Anstatt nicht benötigte Kapazität überzubereitstellen, zahlen sie nur für das, was sie tatsächlich nutzen.

00:14:58.240 --> 00:15:00.540
Das verändert die gesamte Wirtschaftlichkeit von Hochleistungsspeichern.

00:15:01.080 --> 00:15:02.080
Es macht Schnelligkeit zugänglich.

00:15:02.400 --> 00:15:05.120
Darüber hinaus integriert sich ANF in das restliche Azure-Ökosystem.

00:15:05.720 --> 00:15:07.420
Es nutzt Azure ID für die Zugriffskontrolle.

00:15:07.760 --> 00:15:11.040
Snapshots übernehmen Backups und die Replikation deckt die Disaster Recovery ab.

00:15:11.320 --> 00:15:13.700
Es ist kein isoliertes Tool, sondern Teil der breiteren Plattform.

00:15:14.140 --> 00:15:16.740
Die wahre Stärke liegt in der Kombination, nicht in einem einzelnen Feature.

00:15:16.740 --> 00:15:19.740
Leistung, Flexibilität und verwaltete Einfachheit.

00:15:19.840 --> 00:15:22.940
Sie erhalten Enterprise-Speicher ohne den Enterprise-Aufwand, Aufwand.

00:15:23.500 --> 00:15:26.020
Betrachten Sie ANF als das Spezialwerkzeug in Ihrem Speicherwerkzeugkasten.

00:15:26.340 --> 00:15:27.340
Wir nutzen es nicht für alles, aber wenn...

00:15:27.340 --> 00:15:28.840
...

00:15:28.840 --> 00:15:30.640
...

00:15:30.640 --> 00:15:31.480
...

00:15:31.480 --> 00:15:32.540
...