Skip to main content
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Considérations relatives à la création de relations SnapMirror en cascade et avec fanout pour FlexGroups

Contributeurs
PDF

Considérations et restrictions de prise en charge à prendre en compte lors de la création de relations SnapMirror en cascade et avec fanout pour les volumes FlexGroup.

Considérations relatives à la création de relations en cascade

  • Chaque relation peut être une relation entre clusters ou intra cluster.

  • Tous les types de règles asynchrones, y compris les mises en miroir, les miroirs et les coffres-forts, sont pris en charge pour les deux relations.

  • Seules les stratégies async-mirror « MirrorAlsnapshots », et non « MirrorLatest », sont prises en charge.

  • Les mises à jour simultanées des relations XDP en cascade sont prises en charge.

  • Prend en charge la suppression de A à B et de B à C et la resynchronisation de A à C ou la resynchronisation de C à A.

  • Les volumes FlexGroup a et B prennent également en charge la mise en service lorsque tous les nœuds exécutent ONTAP 9.9.1 ou une version ultérieure.

  • Les opérations de restauration à partir des volumes FlexGroup B ou C sont prises en charge.

  • Les transferts sur les relations FlexGroup ne sont pas pris en charge, tandis que la destination est la source d'une relation de restauration.

  • La destination d'une restauration FlexGroup ne peut pas être la destination d'une autre relation FlexGroup.

  • Les opérations de restauration de fichiers FlexGroup ont les mêmes restrictions que les opérations régulières de restauration de FlexGroup.

  • Tous les nœuds du cluster dans lequel résident les volumes FlexGroup B et C doivent exécuter ONTAP 9.9.1 ou une version ultérieure.

  • Toutes les fonctionnalités d'expansion et d'expansion automatique sont prises en charge.

  • Dans une configuration en cascade telle Que A à B à C, si Les Relations SnapMirror entre A et B et C ont un nombre différent de relations SnapMirror composants, une opération d'abandon de la source n'est pas prise en charge pour la relation SnapMirror entre B et C.

  • System Manager ne prend pas en charge les relations en cascade, quelle que soit la version de ONTAP.

  • Lors de la conversion d'un ensemble A à B en C de la relation FlexVol en une relation FlexGroup, vous devez d'abord convertir le B en C hop.

  • Toutes les configurations en cascade FlexGroup pour les relations avec les types de règles pris en charge par LE PROTOCOLE REST sont également prises en charge par les API REST dans des configurations FlexGroup en cascade.

  • À l'instar des relations FlexVol, la cascade FlexGroup n'est pas prise en charge par le système snapmirror protect commande.

Considérations relatives à la création de relations de fanout

  • Deux ou plusieurs relations de fanout FlexGroup sont prises en charge ; par exemple, A à B, A à C, avec un maximum de 8 pieds de fanout.

  • Chaque relation peut être intercluster ou intracluster.

  • Les mises à jour simultanées sont prises en charge pour les deux relations.

  • Toutes les fonctionnalités d'expansion et d'expansion automatique sont prises en charge.

  • Si les segments « fan out » de la relation comportent différents nombres de relations SnapMirror constitutifs, une opération d'abandon de la source n'est pas prise en charge pour les relations A à B et A à C.

  • Tous les nœuds du cluster où résident la source et la destination FlexGroups doivent exécuter ONTAP 9.9.1 ou une version ultérieure.

  • Tous les types de règles asynchrones actuellement pris en charge pour FlexGroup SnapMirror sont pris en charge dans les relations de type « fan out ».

  • Vous pouvez effectuer les opérations de restauration de B à C FlexGroups.

  • Toutes les configurations en mode « fan out » avec types de règles pris en charge par le REST sont également prises en charge pour les API REST dans les configurations en mode « fan out » de FlexGroup.