Accéder aux mêmes données dans différents environnements
Suggérer des modifications
PDF
Cette section décrit les tâches à effectuer pour accéder aux mêmes données dans différents environnements de calcul. Dans la plateforme Domino MLOps, les environnements de calcul sont appelés « plans de données ». Suivez les tâches décrites dans cette section si vos données résident sur un volume NetApp dans un plan de données, mais que vous devez y accéder dans un autre plan de données. Ce type de scénario est souvent appelé « éclatement » ou, lorsque l’environnement de destination est le cloud, « éclatement du cloud ». Cette capacité est souvent nécessaire lorsqu’il s’agit de gérer des ressources de calcul limitées ou sursouscrites. Par exemple, si votre cluster de calcul sur site est sursouscrit, vous souhaiterez peut-être planifier les charges de travail vers le cloud où elles pourront être démarrées immédiatement.
Il existe deux options recommandées pour accéder à un volume NetApp qui réside dans un plan de données différent. Ces options sont décrites dans les sous-sections ci-dessous. Choisissez l’une de ces options en fonction de vos besoins spécifiques. Les avantages et les inconvénients des deux options sont décrits dans le tableau suivant.
| Option | Avantages | Inconvénients |
|---|---|---|
Option 1 - Cache |
- Flux de travail simplifié - Possibilité de mettre en cache un sous-ensemble de données en fonction des besoins - Possibilité de réécrire les données à la source - Aucune copie distante à gérer |
- Augmentation de la latence lors de l'accès initial aux données à mesure que le cache est hydraté. |
Option 2 - Miroir |
- Copie complète du volume source - Aucune latence accrue due à l'hydratation du cache (une fois l'opération de mise en miroir terminée) |
- Doit attendre que l'opération de mise en miroir soit terminée avant d'accéder aux données - Doit gérer une copie à distance - Aucune possibilité de réécrire sur la source |
Option 1 - Créer un cache d'un volume résidant dans un plan de données différent
Avec"Technologie NetApp FlexCache" , vous pouvez créer un cache d'un volume NetApp qui réside dans un plan de données différent. Par exemple, si vous disposez d’un volume NetApp dans votre plan de données local et que vous devez accéder à ce volume dans votre plan de données AWS, vous pouvez créer un cache du volume dans AWS. Cette section décrit les tâches à effectuer pour créer un cache d’un volume NetApp résidant dans un plan de données différent.
Créer un volume FlexCache dans l'environnement de destination
|
Si l’environnement de destination est votre centre de données sur site, vous créerez le volume FlexCache sur votre système ONTAP sur site. Si l'environnement de destination est AWS, vous créerez le volume FlexCache sur votre instance Amazon FSx ONTAP . |
Tout d’abord, vous devez créer un volume FlexCache dans l’environnement de destination.
Nous vous recommandons d'utiliser BlueXP pour créer le volume FlexCache . Pour créer un volume FlexCache avec BlueXP, suivez les instructions décrites dans le"Documentation sur la BlueXP volume caching" .
Si vous préférez ne pas utiliser BlueXP, vous pouvez utiliser ONTAP System Manager ou l' ONTAP CLI pour créer le volume FlexCache . Pour créer un volume FlexCache avec System Manager, reportez-vous aux instructions décrites dans le"Documentation ONTAP" . Pour créer un volume FlexCache avec l'interface de ligne de commande ONTAP , reportez-vous aux instructions décrites dans le"Documentation ONTAP" .
Si vous souhaitez automatiser ce processus, vous pouvez utiliser le"API BlueXP" , le"API REST ONTAP" , ou le"Collection Ansible ONTAP" .
|
|
System Manager n'est pas disponible dans Amazon FSx ONTAP. |
Exposer le volume FlexCache à Domino
Ensuite, vous devez exposer le volume FlexCache à la plate-forme Domino MLOps. Pour exposer le volume FlexCache à Domino, suivez les instructions décrites dans la sous-section « Exposer les volumes NFS existants qui n'ont pas été provisionnés par Trident» du"Section « Exposer les volumes NetApp existants à Domino »" de cette solution.
Désormais, vous pourrez monter le volume FlexCache lors du lancement de tâches et d’espaces de travail dans le plan de données de destination, comme indiqué dans les captures d’écran suivantes.
Avant de créer le volume FlexCache
Après avoir exposé le volume FlexCache à Domino
Option 2 - Répliquer un volume résidant dans un plan de données différent
Avec"Technologie de réplication de données NetApp SnapMirror" , vous pouvez créer une copie d'un volume NetApp qui réside dans un plan de données différent. Par exemple, si vous disposez d’un volume NetApp dans votre plan de données local et que vous devez accéder à ce volume dans votre plan de données AWS, vous pouvez créer une copie du volume dans AWS. Cette section décrit les tâches à effectuer pour créer une copie d’un volume NetApp résidant dans un plan de données différent.
Créer une relation SnapMirror
Tout d’abord, vous devez créer une relation SnapMirror entre votre volume source et un nouveau volume de destination dans l’environnement de destination. Notez que le volume de destination sera créé dans le cadre du processus de création de la relation SnapMirror .
Nous vous recommandons d'utiliser BlueXP pour créer la relation SnapMirror . Pour créer une relation SnapMirror avec BlueXP, suivez les instructions décrites dans le"Documentation de BlueXP replication" .
Si vous préférez ne pas utiliser BlueXP, vous pouvez utiliser ONTAP System Manager ou ONTAP CLI pour créer la relation SnapMirror . Pour créer une relation SnapMirror avec le Gestionnaire système, reportez-vous aux instructions décrites dans le"Documentation ONTAP" . Pour créer une relation SnapMirror avec l'interface de ligne de commande ONTAP , reportez-vous aux instructions décrites dans le"Documentation ONTAP" .
Si vous souhaitez automatiser ce processus, vous pouvez utiliser le"API BlueXP" , le"API REST ONTAP" , ou le"Collection Ansible ONTAP" .
|
|
System Manager n'est pas disponible dans Amazon FSx ONTAP. |
Rompre la relation SnapMirror
Ensuite, vous devez rompre la relation SnapMirror afin d’activer le volume de destination pour l’accès aux données. Attendez que la réplication initiale soit terminée avant d’effectuer cette étape.
|
|
Vous pouvez déterminer si la réplication est terminée ou non en vérifiant l'état du miroir dans BlueXP, ONTAP System Manager ou l'interface de ligne de commande ONTAP . Une fois la réplication terminée, l'état du miroir sera « snapmirrored ». |
Nous vous recommandons d'utiliser BlueXP pour rompre la relation SnapMirror . Pour rompre une relation SnapMirror avec BlueXP, suivez les instructions décrites dans le"Documentation de BlueXP replication" .
Si vous préférez ne pas utiliser BlueXP, vous pouvez utiliser ONTAP System Manager ou ONTAP CLI pour rompre la relation SnapMirror . Pour rompre une relation SnapMirror avec le Gestionnaire système, reportez-vous aux instructions décrites dans le"Documentation ONTAP" . Pour rompre une relation SnapMirror avec l'interface de ligne de commande ONTAP , reportez-vous aux instructions décrites dans le"Documentation ONTAP" .
Si vous souhaitez automatiser ce processus, vous pouvez utiliser le"API BlueXP" , le"API REST ONTAP" , ou le"Collection Ansible ONTAP" .
Exposer le volume de destination à Domino
Ensuite, vous devez exposer le volume de destination à la plate-forme Domino MLOps. Pour exposer le volume de destination à Domino, suivez les instructions décrites dans la sous-section « Exposer les volumes NFS existants qui n'ont pas été provisionnés par Trident» du"Section « Exposer les volumes NetApp existants à Domino »" de cette solution.
Désormais, vous pourrez monter le volume de destination lors du lancement de tâches et d’espaces de travail dans le plan de données de destination, comme indiqué dans les captures d’écran suivantes.
Avant de créer une relation SnapMirror
Après avoir exposé le volume de destination à Domino