Dans les systèmes ASA r2, les volumes sont toujours présents, mais ils sont créés automatiquement lors de la création des unités de stockage. Les unités de stockage (LUN ou espaces de noms NVMe) sont provisionnées directement dans les volumes créés automatiquement dans les zones de disponibilité de stockage (SAZ). Cette conception élimine le besoin de gestion manuelle des volumes et rend le provisionnement plus direct et rationalisé pour les charges de travail par blocs telles que les bases de données Oracle.

Les unités de stockage associées (LUN ou espaces de noms NVMe) sont normalement colocalisées dans une seule zone de disponibilité de stockage (SAZ). Par exemple, une base de données qui nécessite 10 unités de stockage (LUN) aurait généralement toutes les 10 unités placées dans la même SAZ pour des raisons de simplicité et de performance.

Dans ASA r2, les politiques et les planifications de snapshots sont appliquées au niveau du groupe de cohérence, qui est une construction logique regroupant plusieurs LUN ou espaces de noms NVMe pour une protection coordonnée des données. Un ensemble de données composé de 10 LUN ne nécessiterait qu'une seule stratégie de snapshot si ces LUN font partie du même groupe de cohérence.

Les groupes de cohérence garantissent des opérations d'instantané atomiques sur tous les LUN inclus. Par exemple, une base de données résidant sur 10 LUN, ou un environnement d'application basé sur VMware composé de 10 systèmes d'exploitation différents, peut être protégé comme un seul objet cohérent si les LUN sous-jacents sont regroupés dans le même groupe de cohérence. Si elles sont placées dans des groupes de cohérence différents, les instantanés peuvent ne pas être parfaitement synchronisés, même s'ils sont planifiés en même temps.

Dans certains cas, un ensemble de LUN apparentées peut devoir être divisé en deux groupes de cohérence différents en raison des exigences de récupération. Par exemple, une base de données peut comporter quatre LUN pour les fichiers de données et deux LUN pour les journaux. Dans ce cas, un groupe de cohérence de fichiers de données avec 4 LUN et un groupe de cohérence de journal avec 2 LUN pourraient être la meilleure option. La raison est la récupération indépendante : le groupe de cohérence des fichiers de données pourrait être restauré sélectivement à un état antérieur, ce qui signifie que les quatre LUN seraient ramenés à l’état de l’instantané, tandis que le groupe de cohérence des journaux avec ses données critiques resterait intact.

Les politiques et opérations SnapMirror , tout comme les opérations de snapshot, sont exécutées sur le groupe de cohérence et non sur le LUN.

Le regroupement des LUN apparentées dans un seul groupe de cohérence vous permet de créer une seule relation SnapMirror et de mettre à jour toutes les données contenues en une seule mise à jour. Comme pour les instantanés, la mise à jour sera également une opération atomique. La destination SnapMirror garantirait la présence d'une réplique unique à un instant donné des LUN sources. Si les LUN étaient répartis sur plusieurs groupes de cohérence, les répliques pourraient être cohérentes ou non entre elles.

Bien que la QoS puisse être appliquée sélectivement à des LUN individuels, il est généralement plus facile de la configurer au niveau du groupe de cohérence. Par exemple, tous les LUN utilisés par les invités dans un serveur ESX donné pourraient être placés dans un seul groupe de cohérence, puis une politique QoS adaptative ONTAP pourrait être appliquée. Il en résulte une limite d'IOPS par Tio à auto-ajustement qui s'applique à tous les LUN.

De même, si une base de données nécessitait 100 000 IOPS et occupait 10 LUN, il serait plus facile de définir une seule limite de 100 000 IOPS sur un seul groupe de cohérence que de définir 10 limites individuelles de 10 000 IOPS, une sur chaque LUN.

Il existe certains cas où la répartition des LUN sur plusieurs groupes de cohérence peut s'avérer bénéfique. La raison principale est le découpage des contrôleurs. Par exemple, un système de stockage HA ASA r2 peut héberger une seule base de données Oracle nécessitant la pleine capacité de traitement et de mise en cache de chaque contrôleur. Dans ce cas, une conception typique consisterait à placer la moitié des LUN dans un seul groupe de cohérence sur le contrôleur 1, et l'autre moitié des LUN dans un seul groupe de cohérence sur le contrôleur 2.

De même, pour les environnements hébergeant de nombreuses bases de données, la répartition des LUN sur plusieurs groupes de cohérence peut garantir une utilisation équilibrée du contrôleur. Par exemple, un système HA hébergeant 100 bases de données de 10 LUN chacune pourrait attribuer 5 LUN à un groupe de cohérence sur le contrôleur 1 et 5 LUN à un groupe de cohérence sur le contrôleur 2 par base de données. Cela garantit une charge symétrique lors de la mise en service de bases de données supplémentaires.

Aucun de ces exemples n'implique cependant un ratio LUN/groupe de consistance de 1:1. L’objectif reste d’optimiser la gestion en regroupant logiquement les LUN apparentées dans un groupe de cohérence.

Un exemple où un ratio LUN/groupe de cohérence de 1:1 est pertinent est celui des charges de travail conteneurisées, où chaque LUN peut en réalité représenter une seule charge de travail nécessitant des politiques de snapshot et de réplication distinctes et doit donc être gérée individuellement. Dans de tels cas, un ratio de 1:1 peut être optimal.