The
MDM is the monitoring and configuration agent of
PowerFlex and is used mainly for management. A multi-MDM environment consists of one primary
MDM, while the others function as secondary or
tiebreaker.
The
MDM is used for management which consists of migration, rebuilds, and all system-related functions. No I/Os run through the
MDM.
To support high availability, three or five instances of
MDM run on different servers. In a multi-MDM environment, one
MDM is given the primary role, and the others act as secondary or
tiebreakerMDMs.
The MDM cluster consists of a combination of primary
MDM, secondary
MDMs, and
tiebreakerMDMs. There is also the standby
MDM which is not a part of the cluster.
MDM: An
MDM is any server with the
MDM package installed and it can be given a manager or a
tiebreaker (default) role during installation. This role cannot be changed later without reinstalling the
MDM.
MDMs have a unique
MDM ID, and can be given unique names. Before the
MDM can be part of the cluster, it must be promoted to a standby
MDM.
Standby
MDM and
tiebreaker: An
MDM and a
tiebreaker can be added to a system as a standby. Once added, the standby
MDM or
tiebreaker is attached, or locked, to that specific system. A standby
MDM can be called on to assume the position of a manager
MDM or
tiebreakerMDM according to how it is installed, when it is promoted to be a cluster member.
Manager
MDM: An
MDM that can act as a primary or a secondary in the cluster. Manager
MDMs have a unique system ID, and can be given unique names. A manager can be a standby or a member of the cluster.
TiebreakerMDM: An
MDM whose sole role is to help determine which MDM is the primary. A
tiebreaker can be a standby or a member of the cluster. A
tiebreaker MDM is not a manager. In a three-node cluster, there is one
tiebreaker; in a five-node cluster, there are two
tiebreakers. This ensures that there are always an odd number of
MDMs in a cluster, which guarantees that there is always a majority in electing the primary
MDM.
The following terms are relevant to the
MDM cluster, specifically:
Primary
MDM: The
MDM in the cluster that controls the SDSs and SDCs. The primary
MDM contains and updates the MDM repository, the database that stores the SDS configuration, and how data is distributed between the SDSs in the system. This repository is constantly replicated to the secondary
MDMs, so they can take over with no delay. Every
MDM cluster has one primary
MDM.
Secondary
MDM: An
MDM in the cluster that is ready to take over the primary
MDM role if necessary. In a three-node cluster, there is one secondary
MDM thus allowing for a single point of failure. In a five-node cluster, there are two secondary
MDMs, thus allowing for two points of failure. This increased resiliency is a major benefit to enabling the five-node cluster.
Replica: An
MDM that contains a replica of the
MDM repository. This includes the primary
MDM and any secondary
MDMs in the
MDM cluster.
The following table describes the available cluster modes:
Table 1. MDM cluster modesThis table describes the available
MDM cluster modes.
Cluster mode
Members
Description
Three-node (default)
Primary
MDM
Secondary
MDM
Tiebreaker
Three-node cluster has two copies of the repository, thus can withstand one
MDM cluster failure.
Five-node
Primary
MDM
Two secondary
MDMs
Two
tiebreakers
Five-node cluster has three copies of the repository, thus can withstand two
MDM cluster failures.
Single-node
Primary MDM
Single-node cluster has only one copy of the repository, thus it cannot withstand failure. It is not recommended to use single-node in production systems.
In addition to the cluster members, you can prepare standby managers and
tiebreaker nodes, for a total of thirteen cluster and standby
MDMs.
The
MDM cluster IP address limit is 16 IP addresses, which include all cluster members (primary, secondary, standby
MDM, and standby
tiebreaker).
The following figure illustrates a five-node
MDM cluster:
All members of the
MDM cluster have the same
MDM package installed on them.
MDM cluster creation is done automatically when deploying a system with any of the automated deployment tools.
The following list includes best practices for adding
MDMs to a multiple-rack system:
For a large system with multiple racks, the
MDM cluster members should be distributed in separate racks for resiliency.
The
MDM network requirements described in the
Networking section must also apply to the network connections between the racks.
You can ensure higher resiliency when the rack is shut down for planned or unplanned reasons, especially if fault sets are used. For more information, see
Fault sets.
To ensure users do not shut down the
MDMs by mistake, mark them physically with stickers saying
Do not shutdown: MDM installed here, or add a meaningful prefix\suffix to the hostname of the server where
MDM is installed. For example:
Rack22U32-MDM You can also confirm that a different node in the rack is used per server as shown in the table:
Table 2. Nodes in rackThe following table describes the different nodes in the rack used per server.
Node level
Rack number
MDM role
Top node
1
MDM
Bottom node
2
MDM
Middle node
3
TB
Data is not available for the Topic
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please select whether the article was helpful or not.
Comments cannot contain these special characters: <>()\