A propos de la réplication de partage de fichiers

Répliquez les partages de fichiers par zone entre différentes zones ou régions à des fins de reprise après sinistre, d'accès à faible latence, de distribution de contenu et de tests.

Créez des partages de fichiers répliqués en lecture seule dans une autre zone à des fins de reprise après sinistre, d'accès à faible latence pour les équipes dispersées, de diffusion de contenu dans des hubs régionaux ou de tests. Vous pouvez créer des répliques de vos partages de fichiers zonaux dans une autre zone de la même région géographique. Avec la fonction de réplication, vous pouvez conserver une copie en lecture seule de votre partage de fichiers dans une autre zone. Le partage de réplique est mis à jour à partir du partage source selon une planification que vous spécifiez. La réplique en lecture seule peut aider à fournir un accès à faible latence aux équipes et applications distribuées en plaçant les données plus près des consommateurs. La réplication peut améliorer la distribution de contenu pour les équipes internationales en créant des hubs régionaux permettant de télécharger plus rapidement les programmes d'installation, la documentation et les médias. Les répliques peuvent faire exploser la capacité lors d'événements de pointe tels que les lancements de produits ou les campagnes mondiales. Vous pouvez utiliser des répliques pour la maintenance, le test des modifications et les essais de migration sans perturber les charges de travail principales. Vous pouvez les utiliser comme copies isolées pour les audits et les conservations légales sans impact sur la production. La réplication permet également de récupérer les données en cas d'incident sur le site principal, lorsque les données deviennent inaccessibles ou qu'une application tombe en panne.

Sélectionner la disponibilité Les clients disposant d'un accès spécial pour prévisualiser la nouvelle offre de partage de fichiers régional peuvent utiliser le profil rfs pour créer des partages de fichiers avec une disponibilité régionale. Lorsque vous créez des partages de fichiers avec disponibilité régionale, les données sont automatiquement répliquées dans toute la région; vous n'avez donc pas besoin de configurer des paires de réplication au sein de la même région. La réplication interrégionale des partages de fichiers régionaux n'est pas prise en charge dans cette version.

Présentation du processus de réplication

Après avoir créé un partage de fichiers, vous pouvez configurer la réplication.

Lorsqu'un partage de répliques est créé, la première réplique contient les données de l'intégralité du partage. Par la suite, seules les modifications survenues après la réplication précédente sont ajoutées.

Vous pouvez créer un partage de réplique dans une autre zone de la même région. Vous pouvez également créer une réplique dans une autre région de la même zone géographique, si vous disposez d'un autre VPC dans la région cible. La réplication intergéographique n'est pas prise en charge.

Ce tableau montre les régions métropolitaines qui peuvent se reproduire les unes les autres dans chaque géographie. Chaque zone géographique est une colonne distincte.
Amériques	Europe	Asie Pacifique
Dallas, TX / `us-south` Montréal / `ca-mon` Sao Paulo / `br-sao` Toronto / `ca-tor` Washington, DC / `us-east`	-Francfort / `eu-de` -Londres / `eu-gb` -Madrid / `eu-es`	Chennai / `in-che` Mumbai / `in-mum` Osaka / `jp-osa` Sydney / `au-syd` Tokyo / `jp-tok`

Lorsque vous créez votre partage de fichiers de réplique dans une autre zone de la même région, le partage de répliques hérite du type de chiffrement et de la clé du partage de fichiers source. Le chiffrement ne peut pas être modifié.

Lorsque vous répliquez votre partage de fichiers dans une autre région, la réplique doit correspondre au type de chiffrement dont dispose le partage source. Cependant, il n'hérite pas du chiffrement de la source. En d'autres termes, si le partage de source est chiffré à l'aide de clés gérées par le fournisseur, la réplique doit également disposer d'un chiffrement géré par le fournisseur. Si le partage de source est chiffré avec une clé gérée par le client, la réplique doit également être chiffrée avec une clé gérée par le client. Cependant, il n'est pas nécessaire qu'il s'agisse de la même clé. Lorsque vous créez la réplique, indiquez le nom de ressource cloud (CRN) de la clé que vous souhaitez utiliser.

En fonction de la planification de la réplication, le service extrait les données du partage de fichiers source vers le partage de fichiers de réplique. Vous pouvez choisir la fréquence de synchronisation des modifications du partage source vers le partage de réplique. Vous pouvez spécifier une planification de réplication horaire, quotidienne, hebdomadaire ou mensuelle. Les réplications doivent être programmées à au moins 15 minutes d'intervalle.

Bien que vous ne puissiez pas créer d'instantanés d'un partage réplique manuellement ou par programme, les instantanés du partage d'origine sont copiés sur le partage réplique lors de la prochaine synchronisation programmée. Si un partage source avec des instantanés est répliqué, les instantanés de partage répliqués correspondants sont créés avec des noms générés par le système, au lieu d'hériter des noms d'instantanés du partage source. Étant donné que les instantanés répliqués partagent l'empreinte digitale de la source, vous pouvez utiliser cette dernière pour établir une corrélation entre les instantanés.

Lorsque vous effectuez une réplication entre des régions, les données traversent les limites VPC. Pour la réplication zonale des partages de fichiers, les VPC et les partages de fichiers doivent tous deux appartenir au même compte, et vous devez mettre en place des autorisations de service à service entre les services de fichiers des deux régions.

Les données sont chiffrées en transit alors qu'elles se déplacent entre les partages de fichiers. Les frais de transfert de données entre les deux partages de fichiers sont calculés à l'aide d'un taux fixe en incréments de Go. Les frais sont basés sur la quantité de données qui a été transférée pendant toute la période de facturation.

Lorsque vous répliquez des données d’une région à l’autre, tenez compte des lois locales en matière de résidence des données, car le transfert transfrontalier de données peut avoir des implications juridiques.

La réplication est une opération asynchrone et n'est pas instantanée. Vous pouvez utiliser les informations de synchronisation de réplication pour voir la durée du processus de réplication et la vitesse de transfert. En consultant les informations de synchronisation de réplication, vous pouvez ajuster votre planification de réplication et équilibrer vos coûts avec la fréquence à laquelle vous avez besoin d'actualiser les données sur la réplique. En affichant les journaux de travail et les débits de transfert, vous pouvez également déterminer si la taille des données à transférer est adaptée à la fenêtre de réplication.

Vous devez disposer d'une capacité inutilisée suffisante dans votre partage de fichiers pour que la réplication puisse s'effectuer. Au cours du processus de réplication, les nouvelles données de la source sont copiées sur le volume de réplique. Les anciennes données ne sont pas écrasées immédiatement, mais supprimées après la fin de l'opération de copie. Par exemple, si votre partage a une capacité de 95 % et que le taux de changement est de 10 %, le réplica risque de ne pas avoir assez d'espace pour contenir les changements. Si la réplique ne dispose pas de suffisamment d'espace pour contenir les mises à jour, le processus de réplication échoue. Vous pouvez surveiller la capacité du partage de fichiers dans la console et configurer des alertes pour l'utilisation. Pour plus d'informations, voir Surveillance des métriques pour File Storage for VPC.

Les données du partage de réplique sont en lecture seule. Vous pouvez obtenir un accès en lecture/écriture aux données de deux manières :

Basculement vers le site de réplication: les opérations de lecture/écriture sur le partage de fichiers source sont suspendues et une copie finale des données du partage de fichiers est transférée vers le partage répliqué. La réplique devient accessible en lecture et en écriture, et une relation de réplication inverse est établie. Le partage du fichier source d'origine devient désormais le partage répliqué et est défini en lecture seule. Le service commence alors à extraire les données du nouveau partage de fichiers source.

Si un partage de fichier source est compromis, les partages de répliques constituent un bon moyen de rétablir les opérations. Le basculement vers un partage répliqué permet de garantir la continuité de vos services.

Lorsque vous lancez la reprise en ligne, vous pouvez spécifier ce qui se passe dans la relation de réplication si le processus de reprise en ligne arrive à expiration ou échoue. Cette option est généralement utilisée lorsque vous devez respecter une contrainte de durée pendant laquelle votre partage de fichiers peut rester hors ligne. Vous devez indiquer ce que vous souhaitez faire si l'opération arrive à expiration ou si la réplication échoue en raison du site d'origine, qui est dégradé ou indisponible.
- Si le site source n'est pas disponible en raison d'une maintenance planifiée, vous pouvez choisir de conserver la relation de réplication. La réplication reprend comme prévu lorsque le site source d'origine est à nouveau opérationnel.
- Dans une situation de reprise après incident, vous pouvez choisir de fractionner les volumes pour mettre le partage de réplique en ligne dès que possible. Cependant, dans ce cas, vous ne disposez peut-être pas des données les plus récentes et vous devrez peut-être synchroniser manuellement l'état dans votre application. Etant donné que la relation de réplication est coupée, vous devez à nouveau configurer la réplication lorsque le site d'origine redevient opérationnel.
Supprimer la relation de réplication-Dans ce cas, vous fractionnez les deux partages et créez deux partages de fichiers indépendants. Les deux partages sont accessibles en lecture / écriture et les données ne sont plus synchronisées entre les deux. Dans l 'API, cette opération est connue sous le nom d'opération split de réplication. La suppression de la relation de réplique est permanente, vous ne pouvez pas la rétablir entre les deux partages. Toutefois, vous pouvez créer de nouvelles répliques dans la même zone ou dans d'autres zones de la même région.

La suppression de la relation de réplication ou la reprise sur le serveur secondaire n'a pas lieu lorsqu'une autre opération est en cours sur le partage de fichiers source ou de serveur secondaire. (Un exemple d'une telle opération est le développement de la taille de partage de fichiers.) L'opération de fractionnement ou de basculement reste en attente jusqu'à ce que l'autre opération soit terminée.

Cas d'utilisation

Vous pouvez utiliser la réplication pour résoudre les problèmes de reprise après incident. La réplication répond aux scénarios suivants :

Reprise après incident suite à un incident d'application.

Dans ce scénario, l'application que vous exécutez échoue. Les données ne sont pas affectées, mais l'application n'est plus opérationnelle. Vous pouvez effectuer un basculement, ce qui entraîne la mise au repos des données et leur envoi dans une autre zone. Les instances de serveur virtuel de cette zone peuvent être configurées pour prendre en charge l'exécution de l'application pendant la réparation des serveurs principaux.
Reprise après sinistre suite à une défaillance de l'infrastructure d' IBM Cloud.

Dans ce scénario, la zone de disponibilité IBM Cloud dans laquelle votre application s’exécute devient inutilisable. Vous devez démarrer votre application sur le site de réplication aussi rapidement que possible et utiliser les données répliquées lors de la dernière opération de réplication. Vous pouvez lancer la reprise en ligne avec l'option split pour rendre le volume de réplique indépendant. La réplication est arrêtée.
Faciliter l'entretien régulier de vos applications.

Utilisez la réplication pour faciliter certaines tâches administratives telles que les mises à niveau avec une plus grande disponibilité. Migrer les données entre deux zones pouvant exécuter différents niveaux de code d'application. L'exécution indépendante de deux environnements peut permettre une plus grande flexibilité dans votre processus de déploiement.
Migration de données ou extension géographique.

Vous pouvez utiliser la réplication pour migrer facilement des données entre deux régions MZR. Une fois vos données répliquées, vous pouvez supprimer la relation de réplication et votre partage de fichiers de réplique devient disponible avec vos données prêtes à être utilisées indépendamment dans la nouvelle région.

Etapes suivantes

Créez un partage de fichiers répliqué dans la console, à partir de l'interface de programmation, avec l'API ou Terraform.

Si vous souhaitez mettre en place une réplication entre différentes régions, vous devez d'abord établir des autorisations de service à service entre les services de fichiers des deux VPC.

Si vous souhaitez créer un partage de réplique dans une autre région où vous utilisez une solution KMS différente, établissez des autorisations de service à service entre le service de fichiers et le KMS cible.
Vérifiez que la réplication fonctionne en vérifiant le statut de la réplication et les informations de synchronisation de la réplication. Le système interroge le dernier statut de synchronisation toutes les 15 minutes.
Utiliser le partage de fichiers de réplique-Si le partage de fichiers principal échoue ou devient indisponible pour une raison quelconque, vous pouvez basculer sur le partage de fichiers de réplique. Lorsque vous effectuez la reprise en ligne, le partage de réplique devient le nouveau partage de fichiers principal, avec une fonction de lecture et d'écriture.
Redémarrez la réplication avec le partage de fichiers d'origine comme planifié lors de sa remise en ligne. Dans ce cas, vous pouvez continuer à utiliser le site de réplique comme site principal ou revenir au site d'origine.