Home > Storage > PowerStore > Databases and Data Analytics > Dell PowerStore Metro Node with Oracle > Terminology
The following terms are used with metro node:
Back-end port (BE port): Metro node director (or node) ports connect to storage arrays (act as initiators).
Consistency groups: Consistency groups aggregate volumes to enable the management and configuration of a common set of properties for the entire group. Synchronous consistency groups provide a way for metro node to apply rule sets and other properties to a group of volumes in a metro node Local or metro node Metro configuration. When distributed volumes or volumes with global visibility are added to a consistency group, a detach rule must be specified for the consistency group. The rule specified is applied to all volume members of the group and controls I/O behavior on all vols in the group during an inter-cluster link failure.
Continuous availability: The ability to deliver continuously available storage within a local datacenter, and across a campus or metro region.
Data mobility: The ability to move data across different storage arrays within the local datacenter, across a campus or metro region without impacting users.
Director (or node): A director (or node) is the central processing and intelligence of the metro node solution. There are redundant (A and B) directors (or nodes) in each metro node cluster.
Distributed device: A device with global visibility whose mirrors are in different metro node clusters.
Device: A logical construct where a protection scheme of RAID geometry could be applied to one or more extents. Devices can be composed of any combination of extents or other devices as appropriate for a particular RAID geometry. RAID 1 (mirroring) is used when applying protection between two extents in a metro node Local or Metro configuration. Mirrors are created, synchronized, and unmirrored without any disruption to the host. If a RAID 1 mirror is broken in a metro node Local configuration, when the mirror is reestablished, resynchronization will always be a full resynchronization to resilver the mirror. However, if a RAID 1 mirror is broken in a Metro configuration, when the metro or distributed RAID 1 mirror is reestablished, metro node uses the Logging volumes mapping files for incremental rebuilds to heal the mirror.
Engine: An engine consists of two directors (or nodes) and is the unit of scale for the metro node solution.
Extents: A logical construct that metro node uses to divide the underlying storage volume into parts. Usually, the extent is the size of the hosting storage volume.
Front-end port (FE port): Metro node director (or node) ports connect to host initiators (act as targets).
Logging volumes: Logging volumes keep track of any blocks written during an inter-cluster link failure. After a link is restored, the system uses the information in logging volumes to synchronize the distributed devices by sending only changed block regions across the link.
Metadata volume: System volume that contains specific information about the metro node environment such as virtual-to-physical mapping information, devices, extents, high availability options, virtual volumes, system, and cluster configuration settings. Metadata volumes are created during metro node installation and are managed by the metro node system.
Metro node cluster: A collection of engines in one rack, using redundant, private Fibre Channel connections for the cluster interconnect.
Rule sets: Rule set contains several different detachment rules that govern how metro node Metro operates if one of the metro node cluster members becomes unavailable. Rule sets are specified when creating a distributed device, or when creating a Consistency Group. Only one of the rule sets can be configured at a time. Detach rule choices are:
Storage views: A storage view defines the data paths between registered host initiators and metro node FE ports. It also contains the metro node virtual volumes exposed to one or more hosts and assigned LUN IDs.
Storage volume: For metro node, a storage volume is a construct configured from a logical unit of storage presented from a backend array to the metro node BE ports. Before metro node can create the storage volume, it must first claim the exposed storage from the backend array. From the perspective of the backend array connected to the metro node’s BE ports, metro node appears as a host object.
Virtual volume: A logical construct created from the top-level metro node device. Its size is the same as the device. The virtual volume is the logical unit of storage that is exposed from metro node’s FE ports to one or more hosts. The administrator can choose to have metro node take advantage of thin provisioning in the virtual volume, providing the underlying storage array supports thin storage volumes.