Trasferimento dati scaricato da Archiviazione Windows
OdX (Offloaded Data Transfer) di Windows è una funzionalità che velocizza le operazioni di copia e spostamento del server. È disponibile a partire da Windows Server 2012 ed è supportato nei volumi NTFS.
Questo articolo descrive ODX dal punto di vista del dispositivo di archiviazione. Per informazioni relative ai file system e ai minifiltri, vedere Offloaded Data Transfer.For information related to file system and minifilters, see Offloaded Data Transfer.
Panoramica
Anziché copiare grandi quantità di dati durante i trasferimenti di file, Windows ODX ha introdotto un'operazione con token per spostare i dati nei dispositivi di archiviazione. Il file di origine e un file di destinazione possono trovarsi in uno dei percorsi seguenti:
- Nello stesso volume.
- In due volumi diversi che ospitano lo stesso computer.
- In un volume locale e in un volume remoto tramite Server Message Block (SMB2 o SMB3).
- In due volumi in due computer diversi tramite SMB2 o SMB3.
Il processo di un'operazione di copia offload nei dispositivi di archiviazione con supporto per ODX è illustrato nel diagramma seguente.
- L'applicazione di copia invia una richiesta di lettura offload al gestore copie del dispositivo di archiviazione di origine.
- Il gestore di copia di origine restituisce un token. Il token è una rappresentazione dei dati (ROD) da copiare.
- L'applicazione invia una richiesta di scrittura offload con token al gestore copie del dispositivo di archiviazione di destinazione.
- Il gestore di copia dell'array di archiviazione sposta i dati dal dispositivo di origine al dispositivo di destinazione e restituisce il risultato di scrittura dell'offload all'applicazione.
Identificare un'origine e una destinazione con supporto per ODX
Per supportare ODX, gli array di archiviazione devono implementare le specifiche standard T10 correlate per le matrici di archiviazione con supporto per ODX, incluse le operazioni di lettura e scrittura di offload con token. Durante l'enumerazione del dispositivo LUN (un avvio di sistema o un evento plug-and-play), Windows raccoglie o aggiorna le informazioni sulle funzionalità ODX del dispositivo di destinazione di archiviazione seguendo questa procedura.
- Funzionalità di offload per la copia delle query.
- Raccogliere i parametri necessari per le operazioni di offload di copia e le limitazioni.
Per impostazione predefinita, Windows prova prima il percorso ODX per un'operazione di copia se sia l'origine che i LUN di destinazione sono compatibili con ODX. Se il dispositivo di archiviazione non riesce la richiesta ODX iniziale, Windows contrassegna la combinazione del LUN di origine e di destinazione come percorso "non compatibile con ODX" e segue il percorso del codice del file di copia legacy.
Operazioni di lettura/scrittura ODX
Adozione e API sincrone dei comandi
Una richiesta di scrittura offload di grandi dimensioni viene suddivisa usando l'algoritmo seguente per garantire una scrittura di offload sincrona affidabile.
- Se il dispositivo di archiviazione di destinazione non fornisce dimensioni di trasferimento ottimali, impostare le dimensioni di trasferimento ottimali a 64 MB.
- Se la dimensione di trasferimento ottimale impostata dal dispositivo di destinazione è maggiore di 256 MB, impostare le dimensioni di trasferimento ottimali a 256 MB.
- Le dimensioni di trasferimento ottimali specificate dal dispositivo di destinazione di archiviazione sono maggiori di zero e minori di 256 MB.
I comandi SCSI di lettura e offload di offload sincroni riducono la complicazione degli scenari di failover di MPIO e cluster. Windows prevede che il gestore di copia completi i comandi SCSI di lettura/scrittura sincroni di offload entro 4 secondi.
Le applicazioni possono usare LE API DSMTL, DSM IOCTL o SCSI_PASS_THROUGH per interagire con le matrici di archiviazione ed eseguire operazioni di offload di copia. Per evitare il danneggiamento dei dati o l'instabilità del sistema, Windows impedisce alle applicazioni di scrivere direttamente in un volume montato nel file system senza prima ottenere l'accesso esclusivo al volume. Questa restrizione è necessaria a causa della condizione che una scrittura nel volume potrebbe essere in conflitto con le scritture del file system. Quando si verificano conflitti di questo tipo, il contenuto del volume potrebbe essere lasciato in uno stato incoerente.
Operazioni di lettura offload
La richiesta di lettura di offload di un'applicazione può specificare la durata del token (timeout di inattività). Se l'applicazione imposta la durata del token su zero, il timer di inattività predefinito viene usato come durata del token. Il gestore di copie dell'array di archiviazione gestisce e convalida il token in base al valore di timeout di inattività e alle credenziali. L'host Windows limita anche il numero di frammenti di file a 64. Se la richiesta di lettura di offload è costituita da più di 64 frammenti, Windows non riesce la richiesta di offload di copia ed esegue il fallback all'operazione di copia tradizionale.
Dopo aver completato la richiesta di lettura di offload, il gestore di copia prepara una rappresentazione del token di dati (ROD) per il comando receive offload read result. Il campo token di sola lettura specifica la rappresentazione temporizzato dei dati utente e delle informazioni di protezione. Il controller di dominio di sola lettura può essere dati utente in formato "aperto esclusivamente" o "aperto con condivisione". Il gestore di copia può invalidare il token in base all'impostazione dei criteri di sola lettura. Se il controller di dominio di sola lettura è "aperto esclusivamente" per un'operazione di offload di copia, il token di sola lettura può essere invalidato quando il controller di dominio di sola lettura viene modificato o spostato.If the ROD is "open exclusively" for a copy offload operation, the ROD token can be invalidated when the ROD is modified or moved. Se rod è in formato "aperto con condivisione", il token di sola lettura rimane valido quando viene modificato il controller di dominio di sola lettura. Un token di sola lettura è di 512 byte con il formato seguente:
| Dimensioni in byte | Contenuto del token |
|---|---|
| 4 | Tipo di token ROD |
| 508 | ID token di sola lettura |
Poiché il token di sola lettura viene concesso e utilizzato solo dall'array di archiviazione, il formato è opaco, univoco e altamente sicuro. Se il token viene modificato, non convalidato o scaduto, il gestore di copia può invalidare il token durante l'operazione di scrittura offload. Il token di sola lettura restituito dall'operazione di lettura offload ha un valore di timeout inattivo per indicare il numero di secondi che il gestore di copia deve mantenere il token valido per il successivo utilizzo del token write using token.
Offload delle operazioni di scrittura
Dopo che l'applicazione riceve il token di sola lettura dal gestore di copia, invia la richiesta di scrittura di offload con il token di sola lettura al gestore di copia dell'array di archiviazione. Quando un comando di scrittura di offload sincrono viene inviato al dispositivo di destinazione, Windows prevede che il gestore di copia completi il comando entro 4 secondi. Se il comando viene terminato a causa del timeout del comando o di altre condizioni di errore, Windows ha esito negativo. L'applicazione esegue il fallback all'operazione di copia legacy in base al codice di stato restituito.
La richiesta di scrittura offload può essere completata con uno o più comandi Receive Offload Write Result. Se la scrittura di offload viene completata parzialmente, il gestore di copia restituisce con il ritardo stimato e il numero di conteggi di trasferimento per indicare lo stato di avanzamento della copia. Il numero di conteggi di trasferimento specifica il numero di blocchi logici contigui scritti senza errori dall'origine al supporto di destinazione. Il gestore di copia può eseguire operazioni di offload di scrittura in un modello sequenziale o a dispersione/raccolta.
Quando si verifica un errore di scrittura, lo stato di avanzamento della copia conta blocchi logici contigui dal primo blocco logico al blocco di errore. L'applicazione client o il motore di copia riprende la scrittura di offload dal blocco di errori di scrittura. Al termine dell'offload write, il gestore di copia completa il comando Receive ROD Token Information con:
- Ritardo stimato dell'aggiornamento dello stato impostato su zero.
- Avanzamento del conteggio del trasferimento dei dati al 100%.
Se il risultato di scrittura dell'offload di ricezione restituisce lo stesso stato del conteggio dei trasferimenti di dati, Windows non riesce l'operazione di copia all'applicazione dopo quattro tentativi.
Un'applicazione client può anche eseguire l'operazione di scrittura di offload con un token rod noto, ovvero un token rod predefinito con un modello di dati noto e un formato di token. Un'implementazione comune è denominata token zero. Un'applicazione client può usare un token zero per riempire uno o più intervalli di blocchi logici con zeri. Se il token noto non è supportato o riconoscibile, il gestore delle copie non riesce a eseguire l'offload della richiesta di scrittura con "Token non valido". Un token di sola lettura noto è di 512 byte con il formato seguente:
| Dimensioni in byte | Contenuto del token |
|---|---|
| 4 | Tipo di token ROD |
| 2 | Modello noto |
| 506 | ID token di sola lettura |
In una scrittura offload con un token di sola lettura noto, un'applicazione client non può usare una lettura offload per richiedere un token noto. Il gestore di copia verifica e gestisce i token di sola lettura noti in base ai propri criteri.
Parametri di ottimizzazione delle prestazioni dell'implementazione di ODX
Le prestazioni di ODX non dipendono dalla velocità del collegamento di trasporto della rete client-server o della rete di archiviazione (SAN) tra il server e l'array di archiviazione. Il gestore di copia e i server di dispositivi dell'array di archiviazione spostano i dati.
Non tutti i vantaggi dell'offload di copia dalla tecnologia ODX. Ad esempio, il gestore di copia di un array di archiviazione iSCSI a 1 Gbit potrebbe completare una copia di file da 3 GB entro 10 secondi e la velocità di trasferimento dei dati sarà maggiore di 300 MB al secondo. La velocità di trasferimento dei dati supera già la velocità di trasferimento teorica massima dell'interfaccia Ethernet a 1 Gbit.
Inoltre, è possibile che le prestazioni di copia per i file di una determinata dimensione non possano trarre vantaggio dalla tecnologia ODX. Per ottimizzare le prestazioni, l'uso di ODX può essere limitato a una dimensione minima del file e alla lunghezza massima della copia. Nota:
Windows imposta un requisito minimo per le dimensioni dei file per le operazioni di offload di copia a 256 KB nel motore di copia. Se un file è inferiore a 256 KB, il motore di copia esegue il fallback al processo di copia legacy.
L'host Di Windows usa una dimensione massima di trasferimento dei token e un conteggio di trasferimento ottimale per preparare le dimensioni di trasferimento ottimali di un comando SCSI di lettura o scrittura di offload. Le dimensioni totali del trasferimento in numero di blocchi non devono superare le dimensioni massime del trasferimento del token. Se l'array di archiviazione non segnala un numero di trasferimento ottimale, Windows usa 64 MB come conteggio predefinito.
I parametri di lunghezza di trasferimento ottimale e massima specificano il numero ottimale e massimo di blocchi in un descrittore di intervallo. Le applicazioni di offload di copia possono essere conformi a questi parametri per ottenere prestazioni ottimali per il trasferimento di file.
Gestione degli errori ODX e supporto per la disponibilità elevata
Quando un'operazione ODX non riesce una richiesta di copia file, il motore di copia e il file system di Windows (NTFS) esegue il fallback all'operazione di copia legacy. Se l'offload di copia ha esito negativo durante l'operazione di scrittura offload, il motore di copia e NTFS riprende con l'operazione di copia legacy dal primo punto di errore nella scrittura di offload.
Gestione degli errori ODX
ODX usa un algoritmo di gestione degli errori affidabile in base alle funzionalità dell'array di archiviazione. Se l'offload di copia non riesce in un percorso con supporto per ODX, l'host Di Windows prevede che l'applicazione esegni il fallback all'operazione di copia legacy. A questo punto, il motore di copia di Windows ha già implementato il meccanismo di "fallback alla copia tradizionale". Dopo l'errore di offload della copia, NTFS contrassegna il LUN di origine e di destinazione come non compatibile con ODX per tre minuti. Dopo questo periodo di tempo, il motore di copia di Windows ritenta l'operazione ODX. Un array di archiviazione potrebbe usare questa funzionalità per disabilitare temporaneamente il supporto ODX in alcuni percorsi durante situazioni estremamente stressanti.
Failover ODX nelle configurazioni del server MPIO e del cluster
Le operazioni di offload di lettura e scrittura devono essere completate o annullate dallo stesso collegamento di archiviazione (I_T nexus).
Quando si verifica un failover MPIO o un server cluster durante un'operazione di lettura o scrittura sincrona di offload, Windows gestisce il failover come segue:
Se si verifica un failover del percorso MPIO, Windows ritenta il comando ODX non riuscito. Se il comando ha esito negativo di nuovo, Windows:
- Avvia un failover del nodo del server del cluster quando fa parte di un server cluster.
- Rilascia una reimpostazione LUN nel dispositivo di archiviazione e restituisce uno stato di errore di I/O all'applicazione se il failover del server del cluster non è un'opzione.
In una configurazione del server cluster, il servizio di archiviazione cluster esegue il failover al nodo del cluster preferito successivo e quindi riprende il servizio di archiviazione cluster. L'applicazione offload deve essere compatibile con il cluster per poter ripetere il comando di lettura/scrittura di offload dopo il failover del servizio di archiviazione cluster.
Se il comando di lettura o scrittura di offload non è riuscito dopo il failover del percorso MPIO e del nodo del cluster, Windows rilascia una reimpostazione LUN sul dispositivo di archiviazione dopo il failover. Il dispositivo di archiviazione termina tutti i comandi in sospeso e le operazioni in sospeso nel LUN.
Attualmente, Windows non rilascia comandi asincroni di lettura o scrittura SCSI dallo stack di archiviazione.
Modelli di utilizzo ODX
ODX su disco fisico, disco rigido virtuale e disco condiviso SMB
Per eseguire operazioni ODX, il server applicazioni deve avere accesso sia al LUN di origine che al LUN di destinazione con privilegi di lettura/scrittura. L'applicazione copy offload rilascia una richiesta di lettura offload al LUN di origine e riceve un token dal gestore di copia del LUN di origine. Le applicazioni di offload di copia usano il token per emettere una richiesta di scrittura offload nel LUN di destinazione. Il gestore di copia sposta quindi i dati dal LUN di origine al LUN di destinazione attraverso la rete di archiviazione. Il diagramma seguente illustra le destinazioni di origine e destinazione supportate più di base per i trasferimenti di dati scaricati.
Operazione ODX con un server
In una configurazione a server singolo, l'applicazione copy offload rilascia le richieste di lettura e scrittura di offload dallo stesso sistema server.
Il server di origine (o macchina virtuale di origine) ha accesso sia al LUN di origine (VHD o disco fisico) che al LUN di destinazione (VHD o disco fisico). L'applicazione copy offload rilascia una richiesta di lettura di offload al LUN di origine e riceve il token dal LUN di origine. L'applicazione copy offload usa quindi il token per inviare una richiesta di scrittura offload al LUN di destinazione. Il gestore di copia sposta i dati dal LUN di origine al LUN di destinazione all'interno della stessa matrice di archiviazione.
Operazione ODX con due server
Nella configurazione a due server sono presenti due server e più matrici di archiviazione gestite dallo stesso gestore di copia.
- Un server (o macchina virtuale) è l'host del LUN di origine e l'altro server (o macchina virtuale) è l'host del LUN di destinazione. Il server di origine condivide il LUN di origine con il client dell'applicazione tramite il protocollo SMB e il server di destinazione condivide anche il LUN di destinazione con il client dell'applicazione tramite il protocollo SMB. Il client dell'applicazione ha quindi accesso sia al LUN di origine che al LUN di destinazione.
- Gli array di archiviazione di origine e di destinazione vengono gestiti dallo stesso gestore di copia in una configurazione SAN.
- Dal sistema client dell'applicazione, l'applicazione copy offload emette una richiesta di lettura offload al LUN di origine e riceve il token dal LUN di origine e quindi invia una richiesta di scrittura offload con il token al LUN di destinazione. Il gestore di copia sposta i dati dal LUN di origine al LUN di destinazione in due matrici di archiviazione diverse in due posizioni diverse.
Migrazione di dati di grandi dimensioni
La migrazione elevata dei dati è il processo di importazione di una grande quantità di dati, ad esempio record di database, fogli di calcolo, file di testo, documenti analizzati e immagini in un nuovo sistema. La migrazione dei dati potrebbe essere causata da un aggiornamento del sistema di archiviazione, da un nuovo motore di database o da modifiche apportate all'applicazione o al processo aziendale. ODX può essere usato per eseguire la migrazione dei dati da un sistema di archiviazione legacy a un nuovo sistema di archiviazione quando il gestore di copia del nuovo sistema può anche gestire il sistema legacy.
- Un server è l'host del sistema di archiviazione legacy e l'altro è l'host del nuovo sistema di archiviazione. Il server di origine condivide il LUN di origine come client dell'applicazione di migrazione dei dati tramite il protocollo SMB e il server di destinazione condivide il LUN di destinazione come client dell'applicazione di migrazione dei dati tramite il protocollo SMB. Il client dell'applicazione può quindi accedere sia al LUN di origine che a quello di destinazione.
- Il sistema di archiviazione legacy e il nuovo sistema di archiviazione vengono gestiti dallo stesso gestore di copie in una configurazione SAN.
- Dal sistema client dell'applicazione di migrazione dei dati, l'applicazione copy offload rilascia una richiesta di lettura offload al LUN di origine e riceve il token dal LUN di origine. L'applicazione invia quindi una richiesta di scrittura offload con il token al LUN di destinazione. Il gestore di copia sposta i dati dal LUN di origine al LUN di destinazione in due sistemi di archiviazione diversi in due posizioni diverse.
- La migrazione di dati di grandi dimensioni può essere gestita anche con un server nella stessa posizione.
Trasferimento di dati controllato dall'host all'interno di un dispositivo di archiviazione a livelli
Un dispositivo di archiviazione a livelli classifica i dati in diversi tipi di supporti di archiviazione per ridurre i costi, aumentare le prestazioni e risolvere i problemi di capacità. Le categorie possono essere basate su livelli di protezione necessari, requisiti di prestazioni, frequenza di utilizzo e altre considerazioni.
La strategia di migrazione dei dati svolge un ruolo importante nel risultato finale di una strategia di archiviazione a livelli. ODX abilita la migrazione dei dati controllata dall'host all'interno del dispositivo di archiviazione a livelli. L'esempio seguente descrive ODX in un dispositivo di archiviazione a due livelli:
- Il server è l'host del sistema di archiviazione a livelli. Il LUN di origine è il dispositivo di archiviazione Tier1 e il LUN di destinazione è il dispositivo di archiviazione Di livello 2.
- Lo stesso gestore di copia gestisce tutti i dispositivi di archiviazione a livelli.
- Dal sistema server, l'applicazione di migrazione dei dati emette una richiesta di lettura offload al LUN di origine e riceve il token dal LUN di origine. Questa applicazione invia quindi una richiesta di scrittura offload con il token al LUN di destinazione. Il gestore di copia sposta i dati dal LUN di origine al LUN di destinazione in due diversi dispositivi di archiviazione a livelli.
- Al termine dell'attività di migrazione dei dati, l'applicazione elimina i dati dal dispositivo di archiviazione Tier1 e recupera lo spazio di archiviazione.