Transfert de données déchargé de Windows Storage

Le transfert de données déchargé de Windows (ODX) est une fonctionnalité qui accélère les opérations de copie et de déplacement des serveurs. Elle est disponible à partir de Windows Server 2012 et est prise en charge sur les volumes NTFS.

Cet article décrit ODX du point de vue d’un périphérique de stockage. Pour obtenir des informations relatives aux systèmes de fichiers et aux minifiltres, veuillez consulter la section Transferts de données déchargés.

Vue d’ensemble

Plutôt que de copier de grandes quantités de données lors des transferts de fichiers, Windows ODX a introduit une opération de déplacement de données par jeton sur les périphériques de stockage. Le fichier source et un fichier de destination peuvent être dans l’un des emplacements suivants :

• Sur le même volume.
• Sur deux volumes différents hébergés par la même machine.
• Sur un volume local et un volume distant via Server Message Block (SMB2 ou SMB3).
• Sur deux volumes sur deux machines différentes via SMB2 ou SMB3.

Le processus d’une opération de copie déchargée sur des périphériques de stockage compatibles ODX est illustré dans le diagramme suivant.

1. L’application de copie envoie une demande de lecture déchargée au gestionnaire de copie du périphérique de stockage source.
2. Le gestionnaire de copie source renvoie un jeton. Le jeton est une représentation des données (ROD) à copier.
3. L’application envoie une demande d’écriture déchargée avec le jeton au gestionnaire de copie du périphérique de stockage de destination.
4. Le gestionnaire de copie de la matrice de stockage déplace les données du périphérique source vers le périphérique de destination et renvoie le résultat de l’écriture déchargée à l’application.

Identifier une source et une destination compatibles ODX

Pour prendre en charge ODX, les matrices de stockage doivent implémenter les spécifications standard T10 associées aux matrices de stockage compatibles ODX, y compris les opérations de lecture et d’écriture déchargées avec jetons. Lors de l’énumération du périphérique LUN (un démarrage du système ou un événement de plug-and-play), Windows collecte ou met à jour les informations de compatibilité ODX du périphérique cible de stockage via les étapes suivantes.

1. Requête de compatibilité de copie déchargée.
2. Collecte des paramètres nécessaires pour les opérations de copie déchargée et des limitations.

Par défaut, Windows tente d’abord le chemin ODX pour une opération de copie si les LUN source et destination sont compatibles ODX. Si le périphérique de stockage échoue à la requête ODX initiale, Windows marque la combinaison des LUN source et destination comme un chemin « non compatible ODX » et suit le chemin de code de copie de fichier hérité.

Opérations de lecture/écriture ODX

Adoption de commandes synchrones et API

Une demande d’écriture déchargée importante est divisée à l’aide de l’algorithme suivant pour garantir une écriture déchargée synchrone robuste.

• Si le périphérique de stockage cible ne fournit pas une taille de transfert optimale, définissez la taille de transfert optimale à 64 Mo.
• Si la taille de transfert optimale définie par le périphérique cible est supérieure à 256 Mo, définissez la taille de transfert optimale à 256 Mo.
• La taille de transfert optimale spécifiée par le périphérique cible de stockage est supérieure à zéro et inférieure à 256 Mo.

Les commandes SCSI de lecture et d’écriture déchargées synchrones réduisent la complication des scénarios de MPIO et de basculement de cluster. Windows s’attend à ce que le gestionnaire de copie termine les commandes SCSI de lecture/écriture déchargées synchrones dans un délai de 4 secondes.

Les applications peuvent utiliser les API FSCTL, DSM IOCTL ou SCSI_PASS_THROUGH pour interagir avec les matrices de stockage et exécuter des opérations de copie déchargée. Pour éviter la corruption de données ou l’instabilité du système, Windows restreint les applications à écrire directement sur un volume monté par le système de fichiers sans obtenir d’abord un accès exclusif au volume. Cette restriction est nécessaire en raison de la condition qu’une écriture sur le volume pourrait entrer en collision avec les écritures du système de fichiers. Lorsque de telles collisions se produisent, le contenu du volume pourrait être laissé dans un état incohérent.

Opérations de lecture déchargées

La demande de lecture déchargée d’une application peut spécifier la durée de vie du jeton (délai d’inactivité). Si l’application définit la durée de vie du jeton à zéro, le délai d’inactivité par défaut est utilisé comme durée de vie du jeton. Le gestionnaire de copie de la matrice de stockage conserve et valide le jeton en fonction de sa valeur de délai d’inactivité et des informations d’identification. L’hôte Windows limite également le nombre de fragments de fichiers à 64. Si la demande de lecture déchargée comporte plus de 64 fragments, Windows échoue la demande de copie déchargée et revient à l’opération de copie traditionnelle.

Après avoir terminé la demande de lecture déchargée, le gestionnaire de copie prépare une représentation des données (jeton ROD) pour la commande de résultat de lecture déchargée. Le champ du jeton ROD spécifie la représentation instantanée des données utilisateur et des informations de protection. Le ROD peut être des données utilisateur au format « ouvert exclusivement » ou « ouvert avec partage ». Le gestionnaire de copie peut invalider le jeton en fonction de son paramètre de politique ROD. Si le ROD est « ouvert exclusivement » pour une opération de copie déchargée, le jeton ROD peut être invalidé lorsque le ROD est modifié ou déplacé. Si le ROD est au format « ouvert avec partage », le jeton ROD reste valide lorsque le ROD est modifié. Un jeton ROD fait 512 octets avec le format suivant :

Taille en octets	Contenu du jeton
4	Type de jeton ROD
508	ID de jeton ROD

Étant donné que le jeton ROD est accordé et consommé uniquement par la matrice de stockage, son format est opaque, unique et hautement sécurisé. Si le jeton est modifié, non validé ou expiré, le gestionnaire de copie peut invalider le jeton lors de l’opération d’écriture déchargée. Le jeton ROD renvoyé à partir de l’opération de lecture déchargée comporte une valeur de délai d’inactivité pour indiquer le nombre de secondes pendant lesquelles le gestionnaire de copie doit conserver le jeton valide pour la prochaine utilisation d’écriture avec jeton.

Opérations d’écriture déchargées

Après que l’application reçoit le jeton ROD du gestionnaire de copie, elle envoie la demande d’écriture déchargée avec le jeton ROD au gestionnaire de copie de la matrice de stockage. Lorsqu’une commande d’écriture déchargée synchrone est envoyée au périphérique cible, Windows s’attend à ce que le gestionnaire de copie termine la commande dans un délai de 4 secondes. Si la commande est terminée en raison d’un délai d’attente ou d’autres conditions d’erreur, Windows échoue la commande. L’application revient à l’opération de copie héritée en fonction du code de statut renvoyé.

La demande d’écriture déchargée peut être complétée avec une ou plusieurs commandes de résultat d’écriture déchargée. Si l’écriture déchargée est partiellement terminée, le gestionnaire de copie renvoie le délai estimé et le nombre de comptes de transfert pour indiquer la progression de la copie. Le nombre de comptes de transfert spécifie le nombre de blocs logiques contigus qui ont été écrits sans erreur du support source au support de destination. Le gestionnaire de copie peut effectuer des écritures déchargées dans un modèle séquentiel ou en mode scatter/gather.

Lorsqu’une erreur d’écriture se produit, les comptes de progression de copie comptabilisent les blocs logiques contigus du premier bloc logique au bloc d’erreur. L’application cliente ou le moteur de copie reprend l’écriture déchargée à partir du bloc d’erreur d’écriture. Lorsque l’écriture déchargée est terminée, le gestionnaire de copie termine la commande d’informations du jeton ROD avec :

• Le délai estimé de mise à jour de l’état défini à zéro.
• La progression du compte de transfert de données à 100 %.

Si le résultat de l’écriture déchargée renvoie la même progression du compte de transfert de données, Windows échoue l’opération de copie vers l’application après quatre nouvelles tentatives.

Une application cliente peut également effectuer l’opération d’écriture déchargée avec un jeton ROD bien connu, qui est un jeton ROD prédéfini avec un modèle de données et un format de jeton connus. Une implémentation courante est appelée un jeton zéro. Une application cliente peut utiliser un jeton zéro pour remplir une ou plusieurs plages de blocs logiques avec des zéros. Si le jeton bien connu n’est pas pris en charge ou n’est pas reconnu, le gestionnaire de copie échoue la demande d’écriture déchargée avec « Jeton invalide ». Un jeton ROD bien connu fait 512 octets avec le format suivant :

Taille en octets	Contenu du jeton
4	Type de jeton ROD
2	Modèle bien connu
506	ID de jeton ROD

Dans une écriture déchargée avec un jeton ROD bien connu, une application cliente ne peut pas utiliser une lecture déchargée pour demander un jeton bien connu. Le gestionnaire de copie vérifie et conserve les jetons ROD bien connus en fonction de sa propre politique.

Paramètres d’optimisation des performances de l’implémentation ODX

Les performances d’ODX ne dépendent pas des vitesses de liaison de transport du réseau client-serveur ou du réseau de stockage (SAN) entre le serveur et la matrice de stockage. Le gestionnaire de copie et les serveurs de périphériques de la matrice de stockage déplacent les données.

Toutes les copies déchargées ne bénéficient pas de la technologie ODX. Par exemple, le gestionnaire de copie d’une matrice de stockage iSCSI de 1 Gbit pourrait terminer une copie de fichier de 3 Go en 10 secondes, et le débit de transfert de données sera supérieur à 300 Mo par seconde. Le débit de transfert de données dépasse déjà la vitesse de transfert maximale théorique de l’interface Ethernet de 1 Gbit.

De plus, il est possible que les performances de copie pour les fichiers d’une certaine taille ne bénéficient pas de la technologie ODX. Pour optimiser les performances, l’utilisation d’ODX peut être limitée à une taille de fichier minimale et à des longueurs de copie maximales autorisées. Remarque :

• Windows définit une exigence de taille de fichier minimale pour les opérations de copie déchargée à 256 Ko dans le moteur de copie. Si un fichier fait moins de 256 Ko, le moteur de copie revient au processus de copie hérité.

• L’hôte Windows utilise une taille de transfert maximale de jeton et un nombre de transferts optimal pour préparer la taille de transfert optimale d’une commande SCSI de lecture ou d’écriture déchargée. La taille de transfert totale en nombre de blocs ne doit pas dépasser la taille de transfert maximale de jeton. Si la matrice de stockage ne signale pas un nombre de transferts optimal, Windows utilise 64 Mo comme nombre par défaut.

Les paramètres de longueur de transfert optimale et maximale spécifient le nombre optimal et maximal de blocs dans un descripteur de plage. Les applications de copie déchargée peuvent respecter ces paramètres pour obtenir des performances de transfert de fichiers optimales.

Gestion des erreurs ODX et prise en charge de la haute disponibilité

Lorsqu’une opération ODX échoue à une demande de copie de fichier, le moteur de copie et le système de fichiers Windows (NTFS) reviennent à l’opération de copie héritée. Si la copie déchargée échoue au milieu de l’opération d’écriture déchargée, le moteur de copie et NTFS reprennent avec l’opération de copie héritée à partir du premier point d’échec dans l’écriture déchargée.

Gestion des erreurs ODX

ODX utilise un algorithme robuste de gestion des erreurs conforme aux fonctionnalités de la matrice de stockage. Si la copie déchargée échoue dans un chemin compatible ODX, l’hôte Windows s’attend à ce que l’application revienne à l’opération de copie héritée. À ce stade, le moteur de copie Windows a déjà implémenté le mécanisme de « retour à la copie traditionnelle ». Après l’échec de la copie déchargée, NTFS marque les LUN source et destination comme non compatibles ODX pendant trois minutes. Après l’écoulement de ce délai, le moteur de copie Windows retente l’opération ODX. Une matrice de stockage pourrait utiliser cette fonctionnalité pour désactiver temporairement la prise en charge d’ODX dans certains chemins lors de situations très stressantes.

Basculement ODX dans les configurations MPIO et serveurs de cluster

Les opérations de lecture et d’écriture déchargées doivent être terminées ou annulées à partir de la même liaison de stockage (I_T nexus).

Lorsqu’un basculement MPIO ou de serveur de cluster se produit pendant une opération de lecture ou d’écriture déchargée synchrone, Windows gère le basculement comme suit :

• Si un basculement de chemin MPIO se produit, Windows retente la commande ODX échouée. Si la commande échoue à nouveau, Windows :

  • Initie un basculement de nœud de serveur de cluster lorsqu’il fait partie d’un serveur de cluster.
  • Émet une réinitialisation de LUN vers le périphérique de stockage et renvoie un statut d’échec d’E/S à l’application si le basculement du serveur de cluster n’est pas une option.

• Dans une configuration de serveur de cluster, le service de stockage de cluster bascule vers le nœud de cluster préféré suivant, puis reprend le service de stockage de cluster. L’application de copie déchargée doit être compatible avec le cluster pour pouvoir retenter la commande de lecture/écriture déchargée après le basculement du service de stockage de cluster.

Si la commande de lecture ou d’écriture déchargée a échoué après le basculement de chemin MPIO et de nœud de cluster, Windows émet une réinitialisation de LUN vers le périphérique de stockage après le basculement. Le périphérique de stockage met fin à toutes les commandes en attente et aux opérations en cours sur le LUN.

Actuellement, Windows n’émet pas de commandes SCSI de lecture ou d’écriture déchargées asynchrones depuis la pile de stockage.

Modèles d’utilisation ODX

ODX entre disque physique, disque dur virtuel et disque partagé SMB

Pour effectuer des opérations ODX, le serveur d’applications doit avoir accès à la fois au LUN source et au LUN de destination avec des privilèges de lecture/écriture. L’application de copie déchargée émet une demande de lecture déchargée au LUN source et reçoit un jeton du gestionnaire de copie du LUN source. Les applications de copie déchargée utilisent le jeton pour émettre une demande d’écriture déchargée au LUN de destination. Le gestionnaire de copie déplace ensuite les données du LUN source vers le LUN de destination via le réseau de stockage. Le diagramme suivant illustre les cibles source et destination prises en charge les plus élémentaires pour les transferts de données déchargés.

Opération ODX avec un serveur

Dans une configuration à un serveur, l’application de copie déchargée émet les demandes de lecture et d’écriture déchargées à partir du même système serveur.

Le serveur source (ou la machine virtuelle source) a accès à la fois au LUN source (VHD ou disque physique) et au LUN de destination (VHD ou disque physique). L’application de copie déchargée émet une demande de lecture déchargée au LUN source et reçoit le jeton du LUN source. L’application de copie déchargée utilise ensuite le jeton pour émettre une demande d’écriture déchargée au LUN de destination. Le gestionnaire de copie déplace les données du LUN source vers le LUN de destination au sein de la même matrice de stockage.

Opération ODX avec deux serveurs

Dans la configuration à deux serveurs, il y a deux serveurs et plusieurs matrices de stockage gérées par le même gestionnaire de copie.

• Un serveur (ou une machine virtuelle) est l’hôte du LUN source, et l’autre serveur (ou machine virtuelle) est l’hôte du LUN de destination. Le serveur source partage le LUN source avec le client de l’application via le protocole SMB, et le serveur de destination partage également le LUN de destination avec le client de l’application via le protocole SMB. Le client de l’application a ainsi accès à la fois au LUN source et au LUN de destination.
• Les matrices de stockage source et destination sont gérées par le même gestionnaire de copie dans une configuration SAN.
• Depuis le système client de l’application, l’application de copie déchargée émet une demande de lecture déchargée au LUN source et reçoit le jeton du LUN source, puis émet une demande d’écriture déchargée avec le jeton vers le LUN de destination. Le gestionnaire de copie déplace les données du LUN source vers le LUN de destination entre deux matrices de stockage différentes situées à deux emplacements différents.

Migration massive de données

La migration massive de données est le processus d’importation d’une grande quantité de données telles que des enregistrements de base de données, des feuilles de calcul, des fichiers texte, des documents numérisés et des images vers un nouveau système. La migration de données peut être causée par une mise à niveau du système de stockage, un nouveau moteur de base de données, ou des changements dans l’application ou le processus métier. ODX peut être utilisé pour migrer des données d’un système de stockage hérité vers un nouveau système de stockage lorsque le gestionnaire de copie du nouveau système peut également gérer le système hérité.

• Un serveur est l’hôte du système de stockage hérité, et l’autre serveur est l’hôte du nouveau système de stockage. Le serveur source partage le LUN source en tant que client de l’application de migration de données via le protocole SMB, et le serveur de destination partage le LUN de destination en tant que client de l’application de migration de données via le protocole SMB. Le client de l’application a ainsi accès à la fois au LUN source et au LUN de destination.
• Le système de stockage hérité et le nouveau système de stockage sont gérés par le même gestionnaire de copie dans une configuration SAN.
• Depuis le système client de l’application de migration de données, l’application de copie déchargée émet une demande de lecture déchargée au LUN source et reçoit le jeton du LUN source. L’application émet ensuite une demande d’écriture déchargée avec le jeton vers le LUN de destination. Le gestionnaire de copie déplace les données du LUN source vers le LUN de destination entre deux systèmes de stockage différents situés à deux emplacements différents.
• La migration massive de données pourrait également être opérée avec un seul serveur au même emplacement.

Transfert de données contrôlé par l’hôte au sein d’un périphérique de stockage hiérarchisé

Un périphérique de stockage hiérarchisé catégorise les données en différents types de supports de stockage pour réduire les coûts, améliorer les performances et résoudre les problèmes de capacité. Les catégories peuvent être basées sur les niveaux de protection nécessaires, les exigences de performance, la fréquence d’utilisation et d’autres considérations.

La stratégie de migration des données joue un rôle important dans le résultat final d’une stratégie de stockage hiérarchisé. ODX permet la migration des données contrôlée par l’hôte au sein du périphérique de stockage hiérarchisé. L’exemple suivant décrit ODX dans un périphérique de stockage à deux niveaux :

• Le serveur est l’hôte du système de stockage hiérarchisé. Le LUN source est le périphérique de stockage de niveau 1, et le LUN de destination est le périphérique de stockage de niveau 2.
• Le même gestionnaire de copie gère tous les périphériques de stockage hiérarchisés.
• Depuis le système serveur, l’application de migration de données émet une demande de lecture déchargée au LUN source et reçoit le jeton du LUN source. Cette application émet ensuite une demande d’écriture déchargée avec le jeton vers le LUN de destination. Le gestionnaire de copie déplace les données du LUN source vers le LUN de destination à travers deux périphériques de stockage de niveau différents.
• Lorsque la tâche de migration des données est terminée, l’application supprime les données du périphérique de stockage de niveau 1 et récupère l’espace de stockage.