Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Azure NetApp Files spiegato: SAP HANA, HPC, VDI e confronto con Azure Files (Doppiaggio IA)

Transcript

Azure NetApp Files spiegato: SAP HANA, HPC, VDI e confronto con Azure Files (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: Pronti per dieci giorni di Microsoft Ration 65, Copilot, EA,
0:04
Speaker 2: Azure e le persone che danno forma al futuro del lavoro?
0:07
Speaker 2: Questo gennaio, M365 contorna e puntiamo ancora più. In alto.
0:12
Speaker 2: Unitevi a noi per sessioni dal vivo, demo concrete e
0:15
Speaker 2: conoscenze pratiche da MVP ed esperti del settore da tutto
0:17
Speaker 2: il mondo. Niente slide generiche, niente gergo infinito. Affrontiamo le
0:22
Speaker 2: sfide reali. Copilot Studio, agenti IAA, Fabric Sicurezza, Governance e Automazione.
0:29
Speaker 2: Che siate professionisti IT, sviluppatori o leader aziendali, ci sono
0:32
Speaker 2: sessioni pensate per voi. Con dieci giorni interi potrete esplorare
0:37
Speaker 2: molteplici tecnologie e connettervi con una community globale. Seguite le
0:41
Speaker 2: dirette e portate intuizioni pratiche nella vostra organizzazione. Gennaio 2027.
0:45
Speaker 2: Dieci giorni. Un'unica community Microsoft. Le iscrizioni sono aperte. Assicuratevi
0:53
Speaker 2: il vostro posto oggi. Il sito m365com. net... Iscrivetevi ora su m365con. net.
1:03
Speaker 2: Ci vediamo dal vivo a gennaio. Azure offre già molte
1:06
Speaker 2: opzioni di archiviazione. Blob, file, disco. Quindi perché esiste Azure
1:10
Speaker 2: NetApp Files? È la prima domanda che le persone pongono
1:12
Speaker 2: quando ne sentono parlare ed è legittima. Microsoft continua ad
1:15
Speaker 2: aggiungere servizi di storage e sembra che ogni trimestre appaia
1:17
Speaker 2: una nuova opzione. Allora perché un'altra ancora? Il punto è questo.
1:20
Speaker 2: La maggior parte dello storage Azure gestisce bene l'uso generale.
1:23
Speaker 2: Web app, condivisioni file, backup, le attività quotidiane che fanno
1:26
Speaker 2: funzionare un'azienda. Ma alcuni carichi di lavoro non rientrano in
1:28
Speaker 2: questo schema. hanno bisogno di una velocità incredibile. Prestazioni costanti
1:32
Speaker 2: sotto pressione, senza potersi permettermi di secondi extra di ritardo.
1:35
Speaker 2: Azure NetApp Files è costruito appositamente per quei carichi di lavoro.
1:39
Speaker 2: Alla fine di questo episodio saprete esattamente cos'è NF, quando
1:42
Speaker 2: usarlo e quando preferire qualcosa di più semplice. Vedremo cosa
1:45
Speaker 2: sia realmente i tre casi d'uso principali in cui eccelle
1:48
Speaker 2: e come si confronta con Azure Files. Partiamo da una
1:50
Speaker 2: semplice definizione. Cos'è effettivamente Azure NetApp Files? Azure NetApp Files
1:55
Speaker 2: è un servizio di archiviazione file aziendale gestito ad alte
1:58
Speaker 2: prestazioni che vive direttamente in Azure. Non si tratta di
2:00
Speaker 2: un add- on di terze parti o di qualcosa da aggiungere
2:02
Speaker 2: in seguito. È un servizio Microsoft di prima parte, completamente
2:05
Speaker 2: integrato nel portale Azure. Ma cosa lo distingue? Sotto il
2:08
Speaker 2: cofano funziona con la tecnologia NetApp, lo stesso sistema di
2:11
Speaker 2: archiviazione che alimenta i data center on- premise da decenni. NetApp
2:14
Speaker 2: si occupa di archiviazione file aziendale fin dagli anni 90.
2:17
Speaker 2: Sanno cosa significa gestire i dati in modo veloce e affida.
2:20
Speaker 2: Microsoft ha collaborato con loro per portare tale competenza in
2:22
Speaker 2: Azure come servizio gestito. Cosa significa per voi? ANF supporta
2:26
Speaker 2: sia i protocolli SMB che NFS fin da subito. Carichi
2:29
Speaker 2: di lavoro Windows, carichi di lavoro Linux li gestisce entrambi.
2:32
Speaker 2: Non devi scegliere l'uno o l'altro. Lo stesso volume può
2:35
Speaker 2: servire a entrambi i tipi di client, se necessario. Le
2:37
Speaker 2: prestazioni sono il suo vero punto di forza. Parliamo di
2:39
Speaker 2: latenza sotto il millisecondo e throughput massiccio. Non è abbastanza veloce.
2:43
Speaker 2: È davvero incredibilmente veloce. Con analogie. Se Azure Files è
2:47
Speaker 2: l'affidabile berlina di famiglia che ti porta dove devi andare,
2:49
Speaker 2: Azure NetApp Files è l'auto sportiva costruita per la velocità,
2:52
Speaker 2: seguita diversamente da qualsiasi ingresso. È la parte migliore che
2:55
Speaker 2: è completamente gestita. Nessun aggiornamento a server, nessuna soluzione AR.
2:58
Speaker 2: Crei semplicemente un volume, scegli il tuo livello di prestazione
3:00
Speaker 2: e inizi a usarlo. Azzurri e NetApp si occupano del resto.
3:03
Speaker 2: Ma perché ti servirebbe un'auto sportiva per lo store? Esaminiamo
3:06
Speaker 2: i problemi che lo storage normale non può risolvere. I
3:09
Speaker 2: problemi che lo storage normale non può risolvere. La maggior
3:12
Speaker 2: parte dello storage cloud gestisce bene i lati quotidiani. App web,
3:15
Speaker 2: condivisioni file, backup. Per la maggior parte delle persone è sufficiente.
3:18
Speaker 2: Non serve un motore di Formula 1 per andare a
3:19
Speaker 2: fare la spesa. Tuttavia alcuni carichi di lavoro sono diversi.
3:22
Speaker 2: Pensali come atleti esigenti che hanno bisogno di ogni millisecondo
3:24
Speaker 2: e non possono permettersi di aspettare. Ecco il problema. L'alta
3:27
Speaker 2: latenza distrugge le prestazioni del database. Qualche millisecondo in più
3:30
Speaker 2: su una scrittura di log può rallentare un intero sistema
3:32
Speaker 2: di transazioni. Un basso throughput soffoca le simulazioni trasformando lavori
3:36
Speaker 2: che dovrebbero richiedere ore in giorni. Anche gli ops incoerenti
3:38
Speaker 2: sono un problema. Frustrano soprattutto gli utenti VDI. Un minuto,
3:41
Speaker 2: tutto va bene. Quello dopo il desktop va rilento perché
3:44
Speaker 2: lo storage non riesce a stare al passo. Lascia che
3:45
Speaker 2: ti faccio un esempio concreto. Un backup di un database
3:48
Speaker 2: SAP HANA da 2,33 byte su storage normale potrebbe richiedere un'ora.
3:51
Speaker 2: È un'ora di attesa e potenziali problemi. Su Azure NetApp
3:54
Speaker 2: Files lo stesso backup si completa in due minuti. Non
3:57
Speaker 2: è un errore di battitura a 2.000. Il problema non
3:59
Speaker 2: è che Azure Files sia scadente. È un ottimo servizio
4:01
Speaker 2: per ciò per cui è stato progettato, ma ottimizzato per
4:03
Speaker 2: i costi, non per le massime prestazioni. Offre una velocità
4:06
Speaker 2: soddisfacente a un prezzo ragionevole ed è perfetto per la
4:08
Speaker 2: maggior parte dei carichi di lavoro, ma non per tutti.
4:09
Speaker 2: Azure NetApp Files con una costa da cura. È creato
4:11
Speaker 2: per carichi di lavoro che non possono scendere a compromessi
4:13
Speaker 2: su velocità costate. Quando ogni millisecondo conta, ha neffa la risposta. Quindi,
4:17
Speaker 2: chi ha davvero bisogno di questo tipo di prestazioni? Iniziamo
4:19
Speaker 2: con uno dei maggiori utilizzatori, Sapana. Caso d'uso numero uno, Sapana.
4:23
Speaker 2: Parliamo di Sapana. Se non lavorni nel mondo dei database
4:26
Speaker 2: aziendali potresti non avermi sentito parlare, ma è uno dei
4:29
Speaker 2: carichi di lavoro più esigenti che puoi eseguire nel cloud.
4:31
Speaker 2: È un database in memory, che significa che mantiene tutti
4:33
Speaker 2: i suoi dati nella RAM per maggiore velocità. Tuttavia, anche
4:36
Speaker 2: se i dati risiedono in memoria, HANA ha comunque bisogno
4:38
Speaker 2: di uno storage ultraveloce per log, backup e snapshot. Queste
4:41
Speaker 2: operazioni di scrittura devono avvenire in modo rapida e fiafida.
4:43
Speaker 2: Se lo storage non è all'altezza, l'intero database rallenta. Ecco
4:45
Speaker 2: perché a Zornet App Files è certificato SAP. È presente
4:49
Speaker 2: nella directory ufficiale dell'hardware SAP HANA, il che significa che
4:52
Speaker 2: è stato testato e approvato da SAP stessa HANA. è
4:55
Speaker 2: una cosa da poco. SAP non certifica una soluzione di
4:57
Speaker 2: storage qualsiasi. La testano accuratamente solo quelle che superano i
5:01
Speaker 2: test e entrano nelle leggi. Di che tipo di prestazioni
5:03
Speaker 2: stiamo parlando? Latenza costantemente inferiore a millisecondo e fino a 4,5
5:07
Speaker 2: giga al secondo di throughput per volume. Per contestualizzare, il
5:11
Speaker 2: requisito minimo di SAP per le scritture dei log di
5:13
Speaker 2: HANA è una latenza inferiore a un millisecondo e NF
5:15
Speaker 2: si posiziona comodamente sotto tale soglia. Questo è importante perché
5:18
Speaker 2: una latenza superiore a un millisecondo può rallentare le transazioni
5:21
Speaker 2: del database. quando elabora i migliaia di transazioni al secondo
5:24
Speaker 2: ogni millisecondo in più conta. Microsoft ha persino creato uno
5:27
Speaker 2: strumento di distribuzione speciale chiamato Application Volume Group per HANA.
5:31
Speaker 2: Ottimizza il layout dei volumi distribuendoli su più endpoint di storage,
5:34
Speaker 2: così nessun singolo endpoint diventa un collo di bottiglia. Immaginalo
5:37
Speaker 2: come avere più corsie su un'autostrada invece di una strada stretta.
5:41
Speaker 2: E vale la pena parlare anche di numeri backup. Un
5:43
Speaker 2: backup HANA di 2,33 GB in circa due minuti su ANF.
5:46
Speaker 2: Su uno storage tradizionale lo stesso backup potrebbe richiedere dai
5:48
Speaker 2: 30 ai 60 minuti. Non è solo una comodità, cambia
5:51
Speaker 2: ciò che è possibile fare con le tue finestre di backup.
5:53
Speaker 2: Anche l'aspetto dei costi è interessante. Grazie ai livelli di
5:56
Speaker 2: servizio flessibili, puoi adattare le prestazioni esattamente alle esigenze di
5:58
Speaker 2: ANA senza sovradimensionare. Non paghi per capacità extra solo per
6:01
Speaker 2: ottenere il throughput di cui hai bisogno. SAP è un
6:04
Speaker 2: caso d'uso importante, ma ANF alimenta anche un tipo di
6:06
Speaker 2: carico di lavoro molto diverso, il calcolo ad alte prestazioni.
6:10
Speaker 2: Calcolo ad alte prestazioni, HPC. Il calcolo ad alte prestazioni
6:13
Speaker 2: copre molti ambiti. Simulazioni, rendering, modellazione finanziaria, ricerca scientifica, qualsiasi
6:18
Speaker 2: cosa in cui si eseguono massicci lavori paralleli su centinaia
6:21
Speaker 2: o addirittura migliaia di nodi di calcolo. Questi carichi di
6:23
Speaker 2: lavoro hanno esigenze molto specifiche. Richiedono un accesso condiviso ai
6:26
Speaker 2: file con throughput elevato e bassa latenza. Più nodi devono
6:29
Speaker 2: leggere e scrivere gli stessi set di dati contemporaneamente. Se
6:32
Speaker 2: lo storage non riesce a stare al passo, i nodi
6:33
Speaker 2: di calcolo restano inattivi in attesa dei dati. E il
6:36
Speaker 2: tempo di calcolo inattivo è denaro sprecato. Azure NetApp Files
6:39
Speaker 2: offre fino a 652.000 IOPS con una latenza inferiore a
6:42
Speaker 2: 2 millisecondi nei test di Benchmark. Si tratta di un
6:45
Speaker 2: numero elevato di operazioni di input- output ed è abbastanza veloce
6:48
Speaker 2: ad evitare che lo storage diventi un collo di bottiglia.
6:50
Speaker 2: Per set di dati molto grandi esiste la funzionalità dei
6:52
Speaker 2: volumi di grandi dimensioni. Supporta capacità fino a 2 petabyte
6:55
Speaker 2: per volume. Si tratta di 2000 terabyte in un singolo volume.
6:59
Speaker 2: Pensate a cosa significhi per un team di ricerca che
7:00
Speaker 2: lavora con i nomi output di simulazione o per uno
7:03
Speaker 2: studio che renderizza un lungometraggio. Poi c'è la modalità breakthrough.
7:06
Speaker 2: Spinge il throughput fino a 50 gigabit al secondo da
7:08
Speaker 2: un singolo volume di grandi dimensioni. Una larghezza di banda
7:10
Speaker 2: sufficiente per spostare rapidamente i nomi. Ecco un esempio reale.
7:14
Speaker 2: Automazione della progettazione elettronica o EDA nel settore della progettazione
7:17
Speaker 2: di chip. Aziende come NVIDIA e AMD eseguono migliaia di
7:20
Speaker 2: simulazioni simultaneamente per verificare il design dei chip prima della produzione.
7:24
Speaker 2: Ogni simulazione legge e scrive dati condivisi. Il sistema di
7:27
Speaker 2: archiviazione deve gestire tale carico concorrente senza rallenta. ANF è
7:30
Speaker 2: progettato esattamente per questo modello. Quindi perché non usare semplicemente
7:33
Speaker 2: Azure Files per questo? Perché Azure Files ha limiti di
7:35
Speaker 2: throughput a livello di file, pari a 300 MB al
7:37
Speaker 2: secondo in uscita per file. Ciò significa che anche se
7:40
Speaker 2: il backend di archiviazione ha più capacità, un sicuro file
7:42
Speaker 2: di grandi dimensioni non può superare tale limite ANF non
7:44
Speaker 2: ha limiti a livello di file. Ogni file può saturare
7:46
Speaker 2: la connessione di rete. Per i carichi di lavoro che
7:48
Speaker 2: gestiscono file di simulazione di grandi dimensioni, questa è fondamentale.
7:51
Speaker 2: Le linee guida di Microsoft raccomandano ANF per carichi di
7:54
Speaker 2: lavoro HPC fino a circa 4000 core e 6,5 giga
7:57
Speaker 2: al secondo di throughput. Oltre tale soglia, potrebbe essere necessaria
8:01
Speaker 2: un'architettura diversa, ma per la stragrande maggioranza degli scenari HPC,
8:04
Speaker 2: ANF è la soluzione ideale. Terzo caso d'uso principale, infrastruttura
8:07
Speaker 2: desktop virtuale, dove l'esperienza utente è tutto. Infrastruttura desktop virtuale
8:12
Speaker 2: è un Ora parliamo di qualcosa con cui quasi tutti
8:15
Speaker 2: hanno a che fare, l'esperienza desktop. L'infrastruttura desktop virtuale o
8:18
Speaker 2: VDI significa ospitare desktop Windows nel cloud. Si pensi ad
8:21
Speaker 2: Azure Virtual Desktop o Citrix. Invece di far girare un
8:24
Speaker 2: PC completo sulla propria scrivania, il desktop risiede su un
8:27
Speaker 2: server remoto e ci sconnette da lontano. Ecco la sfida.
8:30
Speaker 2: Profili utente e i dati delle app devono essere archiviati
8:32
Speaker 2: centralmente e accessibili rapidamente. Ogni volta che qualcuno accede, il
8:35
Speaker 2: profilo deve caricarsi insieme impostazioni, file e dati delle applicazioni.
8:39
Speaker 2: Se l'archiviazione è lenta, l'accesso è lento e gli accessi
8:41
Speaker 2: lenti rendono gli utenti insoddisfatti molto rapidamente. Ed è qui
8:44
Speaker 2: che NF fa una vera differenza. Tempi di caricamento lenti
8:46
Speaker 2: dei profili sono stati realmente la principale nelle distribuzioni VD
8:49
Speaker 2: per anni. Gli utenti fanno il confronto con il loro
8:51
Speaker 2: vecchio desktop locale. Se la versione cloud sembra più lenta,
8:54
Speaker 2: se ne accorgono immediatamente. Azure NetApp Files risolve questo problema
8:57
Speaker 2: con IOPS elevati e bassa latenza, e non parlo di
8:59
Speaker 2: miglioramenti teorici. I risultati nel mondo reale mostrano tempi di
9:03
Speaker 2: accesso che scendono da 20-30 secondi a meno di 5
9:05
Speaker 2: secondi quando le aziende passano da Azure Files ad NF
9:08
Speaker 2: per l'archiviazione dei profili. Questo è il tipo di miglioramento
9:11
Speaker 2: che gli utenti percepiscono almeno. Perché funziona così bene? Perché
9:14
Speaker 2: ANF supporta fino a 450.000 IOPS per volume. Ciò conta
9:18
Speaker 2: quando centinaia di utenti si collegano tutti insieme al mattino.
9:21
Speaker 2: È la cosiddetta logon stop. Tutti arrivano alle 9 e, improvvisamente,
9:25
Speaker 2: ogni profilo deve caricarsi simultaneamente. Un sistema di storage che
9:28
Speaker 2: non gestisce tale concorrenza rallenterà tutti. ANF la gestisce. C'è
9:32
Speaker 2: un'altra funzione incredibilmente utile per la VDA. ANF supporta fino
9:36
Speaker 2: a 205 snapshot per volume. Ciò significa che puoi epristinare
9:39
Speaker 2: istantaneamente il profilo di un utente allo stato di ieri.
9:42
Speaker 2: Se il profilo di qualcuno si corrompe o un aggiornamento
9:44
Speaker 2: crea problemi, non devi ripristinare dal backup. Basta puntare allo
9:47
Speaker 2: snapshot di ieri ed è fatto. Ciò fa risparmiare ore
9:49
Speaker 2: di assistenza tecnica. Anche l'affidabilità gioca un ruolo importante. ANF
9:53
Speaker 2: offre un SLA di disponibilità del 99,9%. Per implementazioni VDE
9:57
Speaker 2: critiche dove il downtime significa perdita di produttività, tale livello
10:00
Speaker 2: di affidabilità è essenziale. Ecco un aspetto psicotico che potresti
10:02
Speaker 2: non aspettare. Poiché ANF è così veloce, puoi usare macchine
10:05
Speaker 2: virtuali più piccole ed economiche ottenendo comunque ottime prestazioni. Lo
10:08
Speaker 2: storage gestisce il lavoro pesante così non deve farlo il calcolo.
10:11
Speaker 2: Questo può compensare parte del costo dello storage premium. Ora
10:14
Speaker 2: conosci tre pilastri SAP, HPC e VDE? Ma come si
10:17
Speaker 2: confronta ANF con il suo cugino Azure Files e Come
10:20
Speaker 2: si confronta Azure NetApp Files con Azure Files? Dunque, sia
10:23
Speaker 2: Azure NetApp Files che Azure Files sono file share gestiti
10:26
Speaker 2: in Azure. Ciò significa che non devi aggiornare server né
10:28
Speaker 2: sostituire hardware. La vera differenza sta nelle prestazioni e nel prezzo.
10:32
Speaker 2: Confrontiamo i numeri pur. Azure Files Premium arriva a 100.000
10:35
Speaker 2: IOPS per share, sufficienti per molti carichi di lavoro. Ma
10:39
Speaker 2: ANF raggiunge 450.000 IOPS per volume, oltre 4 volte quel limite.
10:43
Speaker 2: Quando esegui carichi di lavoro, che richiedono un accesso simultaneo intensivo,
10:46
Speaker 2: quel di vario contadino, la latenza racconta una storia simile.
10:50
Speaker 2: Azure Files standard viaggia sui 10 millisecondi, mentre la versione
10:52
Speaker 2: premium scende a 2-3 millisecondi. È un dato rispettabile, ma
10:56
Speaker 2: ANF offre una latenza sul millisecondo circa 0,5 millisecondi nel
10:59
Speaker 2: tier ultra. È la differenza tra uno storage che è
11:02
Speaker 2: un fattore secondario e uno storage che è praticamente invisibile.
11:05
Speaker 2: Trueput è dove il divario si fa ancora più ampio.
11:07
Speaker 2: Azure Files ha limiti a livello di file, 300 MBs
11:10
Speaker 2: in uscita e 200 MBs in entrata per file. Quindi
11:14
Speaker 2: anche se il tuo backend ha più capacità, un singolo
11:16
Speaker 2: file grande non può superare quel limite. ANF non ha
11:19
Speaker 2: limiti a livello di file. Ogni file può sfruttare tutto
11:21
Speaker 2: il throughput consentito dalla rete. La dimensione massima è la share.
11:25
Speaker 2: Azure Files arriva al massimo a 100 TB per share.
11:27
Speaker 2: ANF arriva fino a 2 più B con i volumi
11:29
Speaker 2: di grande dimensione. Si tratta di 20 volte la capacità.
11:32
Speaker 2: Quindi quando usare l'uno o l'altro. Azure Files è la
11:34
Speaker 2: scelta giusta per la condivisione di file generica, le condivisioni dipartimentali,
11:37
Speaker 2: le destinazioni di backup e i carichi di lavoro sensibili
11:38
Speaker 2: ai costi. Considerabile la berlina. Fidabile e conveniente fa il
11:42
Speaker 2: suo dovere. ANF è pensato per carichi di lavoro in
11:44
Speaker 2: cui la latenza e il throughput sono critici. SAP HANA
11:46
Speaker 2: Oracle SQL Server HPC VDI qualsiasi scenario in cui una
11:49
Speaker 2: latenza inferiore al millisecondo e un numero elevato di IOPS
11:51
Speaker 2: fanno davvero la differenza nelle prestazioni dell'applicazione ora parliamo di
11:54
Speaker 2: costi Azure Files è più economico per la maggior parte
11:57
Speaker 2: dei casi d'uso ed è una scelta deliberata tuttavia NF
11:59
Speaker 2: può effettivamente far risparmiare denari in scenari specifici se ti
12:01
Speaker 2: consente di utilizzare VM più piccole perché l'archiviazione è più
12:04
Speaker 2: veloce risparmi sui costi di calcolo si evita il sovradimensionamento
12:07
Speaker 2: della capacità solo per ottenere un throughput sufficiente risparmi sui
12:10
Speaker 2: costi di archiviazione quindi il quadro di costi totali non
12:12
Speaker 2: è sempre immediato c'è una funzionalità che cambia completamente l'equazione
12:15
Speaker 2: dei costi Il livello di servizio flessibile. Il livello di
12:19
Speaker 2: servizio flessibile ottimizza le prestazioni. Ecco una funzionalità che cambia
12:22
Speaker 2: l'equazione di costo. Tradizionalmente i pool di capacità ANF avevano
12:25
Speaker 2: un rapporto fisso. Più grande era il pool, maggiore era
12:28
Speaker 2: il throughput e più piccolo era il pool, minore era
12:30
Speaker 2: il throughput. Sembra ragionevole in superficie ma creava un problema reale.
12:34
Speaker 2: Immagina di avere un piccolo database, diciamo non terabyte, che
12:36
Speaker 2: necessita di un throughput elevato per funzionare correttamente. Con il
12:39
Speaker 2: vecchio modello dovevi sovradimensionare la capacità solo per ottenere prestazioni sufficienti.
12:43
Speaker 2: Potresti aver acquistare 64 TB di archiviazione sul livello standard
12:46
Speaker 2: solo per ottenere il throughput di cui quel TB ha
12:48
Speaker 2: realmente bisogno e con gli altri 63 TB inutilizzati. Stai
12:51
Speaker 2: pagando per uno spazio che non utilizzi. Non è efficiente,
12:53
Speaker 2: non è economico. Il livello di servizio flessibile cambia completamente
12:56
Speaker 2: la stessa. Disaccoppi la capacità dal throughput, due manopole indipendenti
12:59
Speaker 2: invece di una. Decidi quante archiviazioni ti serve separatamente e
13:02
Speaker 2: quante prestazioni ti servono. Non devono necessariamente quelli. Quindi ora
13:05
Speaker 2: puoi avere un pulldown TB con 1 GB al secondo
13:08
Speaker 2: di throughput. Con il vecchio modello, con le stesse prestazioni
13:11
Speaker 2: sul livello standard, avrebbero richiesto 64 TB di capacità. È
13:15
Speaker 2: una differenza di 64.1. Con il livello di servizio flessibile
13:18
Speaker 2: paghi esattamente ciò di cui hai bisogno. I risparmi sui
13:20
Speaker 2: costi sono reali. In molti scenari si parla del 30%
13:22
Speaker 2: preceso in più rispetto all'utilizzo del livello ultra per le
13:24
Speaker 2: stesse prestazioni. E questo prima di considerare i sconti sulla
13:27
Speaker 2: capacità riservata. Lo scenario di disaster recovery rende tutto ancora
13:30
Speaker 2: più chiaro. Supponiamo che ti servano 100 TB di capacità
13:33
Speaker 2: per un sito DDR, ma non ti serve un throughput
13:35
Speaker 2: elevato finché non avviene un failover effettivo. Con il vecchio
13:38
Speaker 2: modello avresti dovuto eseguire provisioning per le prestazioni di cui
13:40
Speaker 2: potresti aver bisogno. Con il livello di servizio flessibile paghi
13:43
Speaker 2: solo per la capacità, un throughput di base di 128
13:46
Speaker 2: MB al secondo, e nulla più. Quando si verifica un
13:49
Speaker 2: failover aumenti il throughput su richiesta. Una volta terminato lo
13:53
Speaker 2: riduci dopo un periodo di raffreddamento di 24 ore. A
13:56
Speaker 2: proposito di scalabilità puoi aumentare il throughput quando serve entro
13:58
Speaker 2: certi limiti e dopo 24 ore puoi ridurlo. È perfetto
14:02
Speaker 2: per gestire picchi di carico, elaborazioni di fine mese, finestre
14:04
Speaker 2: di migrazione e picchi stagionali senza pagare permanentemente per quella
14:07
Speaker 2: capacità extra. Questa funzionalità è attualmente disponibile in anteprima in
14:10
Speaker 2: tutte le regioni NF. È una delle aggiunte più richieste
14:13
Speaker 2: dal servizio e sta già cambiando il modo in cui
14:15
Speaker 2: i clienti considerano i costi di archiviazione. Questo è il
14:17
Speaker 2: livello di servizio flessibile in Synth. Un semplice cambiamento che
14:20
Speaker 2: risolve un grande problema. Sezioni di collegamento mettendo tutto in tesi.
14:23
Speaker 2: Ecco il momento della rivelazione. Azure NetApp Files non compete
14:27
Speaker 2: con Azure File. Colma una specifica lacuna prestazionale. una lacuna
14:30
Speaker 2: importante per i carichi di lavoro giusti. Ora, quei tre
14:32
Speaker 2: casi d'uso che abbiamo trattato, SAP HANA, HPC e WDA,
14:35
Speaker 2: hanno tutti una cosa in comune. Richiedono un accesso ai
14:38
Speaker 2: file coerente a bassa latenza ad alto throughput. Questo è
14:40
Speaker 2: il filo conduttore che dici tu. Che si tratti di
14:42
Speaker 2: una transazione di database, un lavoro di simulazione o un
14:45
Speaker 2: utente che accede al proprio desktop, l'archiviazione deve rispondere senza esitazione,
14:50
Speaker 2: senza attese. Il livello di servizio flessibile rende tali prestazioni necessarie.
14:54
Speaker 2: Invece di sovradimensionare la capacità non necessaria, paghi solo per
14:56
Speaker 2: ciò che utilizzi. Ciò cambia l'intera economia dell'archiviazione ad alte prestazioni.
15:01
Speaker 2: Rende la velocità accessibile. Oltre a ciò, ANF si integra
15:03
Speaker 2: con il resto dell'ecosistema Azure. Utilizza Azure AD per il
15:06
Speaker 2: controllo degli accessi. Gli snapshot gestiscono i backup e la
15:09
Speaker 2: replica copre il disaster recovery. Non è uno strumento isolato,
15:12
Speaker 2: è parte della piattaforma più ampia. Il vero potere risiede
15:15
Speaker 2: nella combinazione, non in una singola funzionalità. Prestazioni, flessibilità e
15:18
Speaker 2: semplicità gestita insieme. Utilizza un'archiviazione di livello enterprise senza i
15:21
Speaker 2: costi generali tipici. Pensa ad ANF come lo strumento specializzato
15:25
Speaker 2: nella tua cassa di attività. Non lo usi per tutto,
15:27
Speaker 2: ma quando...