Grid Configuration
A Storage Grid joins several QuantaStor systems so you manage them as one. Log in to any member and you administer the whole grid from that session -- create a pool on another system, replicate between members, move a policy -- without connecting to each appliance separately. Grid membership is also the prerequisite for features that span systems, including remote replication and the clustered pool configurations.
A system belongs to at most one grid at a time. A grid can hold any number of systems, and within it any number of storage clusters, each with their own pools.
| Section | Covers |
|---|---|
| The Grid Master | The coordinating member, what it does, and what happens if it is lost |
| Creating a Grid | Turning a standalone system into a one-member grid |
| Adding a System | Joining a system, and what merges when it joins |
| Renaming a Grid | The grid's own name and description |
| Changing the Grid Master | Electing a different coordinator |
| Removing a System | Taking a member out, including Ceph members |
| Deleting a Grid | Dissolving the grid, and what survives |
| Managing a Grid from the CLI | The twelve qs grid commands
|
All six grid operations live in the Storage System Grid toolbar group: Create Grid, Modify Grid, Add System, Delete Grid, Set Grid Master and Remove System. The tree header shows the grid name in brackets, and the Storage Systems list marks the coordinating member (grid master).
The Grid Master
One member is the grid master: it coordinates configuration state across the grid, acting as the conduit through which members learn about each other's objects. The overhead is small -- this is a coordination role, not a data path, and storage I/O never flows through it.
The same role appears under four different names, which is worth knowing when reading dialogs and command output:
| Where | What it is called |
|---|---|
| Storage Systems list | (grid master) beside the member name |
| Toolbar button | Set Grid Master |
| Set Grid Master dialog | "primary coordinator system" |
qs grid-get output |
Master Node ID
|
You do not need to connect to the grid master to manage the grid -- any member gives you the whole grid. Management operations may feel more responsive when run against the master, because operations that need coordination do not have to be relayed.
If the grid master is lost, storage keeps serving but grid management degrades unless you have a Grid VIF configured which will automatically elect another node as the new grid master. Pools stay online and clients keep their connections, because the master is not in the data path. Management operations that require coordination will fail until a new master is elected -- see Changing the Grid Master.
Creating a Grid
Run this on the system that will be the first member. It becomes a one-member grid and that system becomes the initial grid master. Supply a Name for the grid, and optionally a description.
Names may contain alphanumeric characters and the characters -, _ and .
Creating the grid changes nothing about the system's storage. It is a management-plane operation: pools, volumes and shares are untouched.
Adding a System
- Storage System IP Address -- the system to join. Reach it from the system you are running this on.
- Admin Username / Admin Password -- credentials on the system being added, not on the grid you are adding it to. QuantaStor authenticates against the remote system to establish the join, so these are its own local administrator credentials.
Run this from a member of the grid you want to grow.
The system being added must not already belong to another grid. If it does, the join is refused with "This node is already a member of grid '<name>', cannot join grid '<name>'".
Forcing a join of an already-gridded system merges the two grids. The force flag overrides that guard, and the operation then becomes a merge -- every system in the other grid is brought in, not just the one you named. That is a much larger change than adding one appliance, and it is the same operation as qs grid-merge. If a merge is what you want, use grid-merge, where the intent is explicit.
What merges when a system joins
Joining merges management objects across the grid: users, user groups and roles all become grid-wide, so an account created on one member is usable on all of them.
The merge keeps the superset -- nothing is deleted. Users, user groups and roles are merged such that objects are added or updated but never removed, and matching is by object identity rather than by name. Two accounts that happen to share a name, created independently on two systems, therefore both survive as separate accounts. There is no name-based precedence and nothing is discarded.
The one exception is the admin account. Duplicate admin accounts are reconciled by name: the grid master's copy is kept and the others are removed. The practical consequence is the one to plan for -- after joining, the grid master's admin password becomes the admin password on the newly added system. If you are joining a system whose admin password differs, expect to use the master's password afterwards.
(Note: this section describes the merge behaviour of the shipping release. If you rely on account layout across a join, verify the result on a test grid before doing it in production.)
Renaming a Grid
Modify Grid changes the grid's Name and Description and nothing else. The name is what appears in the tree header, so it is worth setting to something that identifies the site or purpose rather than leaving a generated value.
The grid name is separate from the member system names. Renaming the grid does not rename any system, and renaming a system does not change the grid name -- see Storage System for renaming a member.
Changing the Grid Master
- Storage System -- the member to elect as the primary coordinator for synchronizing grid configuration state.
- Force -- promotes the selected member even when the normal election cannot complete.
Use this to move the coordinator role deliberately -- before taking the current master down for maintenance, for instance -- and to recover grid management after a master is lost.
When Force is needed. A normal election coordinates with the existing master and, in a grid with a grid-management virtual interface, moves that interface to the new master. If that step fails -- which is what happens when the member cannot reach the current master -- the operation is refused and nothing changes. Selecting Force makes QuantaStor promote the member directly instead, without that coordination.
So the ordinary reason to reach for Force is the one that matters most: the current master is unreachable and you need to promote a surviving member to get grid management back. It is not a retry switch for an election that failed for some other reason.
Because a forced promotion skips coordination with the existing master, only use it when you are confident the old master is genuinely down. Forcing a promotion while the old master is still running and merely unreachable from this member leaves two systems believing they coordinate the grid and will take a minute or two for the nodes to sort.
Removing a System
- Storage System -- the member to remove.
- Force -- required when the selected system is a Ceph cluster member. Without it the operation is refused with "The selected System is a Ceph cluster member and the Force option must be selected to remove." The guard exists because removing a Ceph member from the grid separates it from the cluster it participates in; requiring Force makes that deliberate rather than accidental.
A removed system becomes standalone again and keeps its own pools, volumes and shares. It also keeps the grid-derived admin password if its admin account was reconciled during the join -- removal does not restore the password it had beforehand.
Before removing a member, move or retire anything that depends on the grid: replication relationships to other members, and cluster membership if the system participates in a clustered pool or a Ceph cluster.
Deleting a Grid
Deleting the grid dissolves the management relationship and returns every member to standalone operation.
Storage is not affected. Pools, volumes and shares stay where they are and stay online -- this removes grid membership, not data. What you lose is single-pane management and anything that depended on membership, so replication relationships between former members and any cross-system cluster configuration must be dealt with first.
Managing a Grid from the CLI
Twelve commands cover the grid. The full argument list for each is in the QuantaStor CLI Command Reference.
| Command | Purpose |
|---|---|
qs grid-create |
Create a grid on this system |
qs grid-get |
Show the grid, its master, and its members |
qs grid-modify |
Change the grid name or description |
qs grid-add |
Add a system by IP address |
qs grid-remove |
Remove a member |
qs grid-set-master |
Elect a different grid master |
qs grid-delete |
Dissolve the grid |
qs grid-merge |
Merge another grid into this one |
qs grid-split |
Split members out into a separate grid |
qs grid-assoc-list |
List grid associations |
qs grid-assoc-get |
Show one system's grid association |
qs grid-send-supportlogs |
Collect and send support logs for the whole grid |
Building a three-member grid from the first system:
qs grid-create --name=qs-grid qs grid-add --node-ipaddress=10.0.8.111 --node-username=admin --node-password=aAbBcCdD qs grid-add --node-ipaddress=10.0.8.112 --node-username=admin --node-password=aAbBcCdD
Confirming the result -- grid-get reports the grid and its Master Node ID, and system-list shows the members:
qs grid-get qs system-list
grid-merge and grid-split have no toolbar equivalent and are the way to reorganise existing grids -- merging two grids into one, or splitting members out into their own. Both change membership for several systems at once, so plan them against a test grid first.
Troubleshooting
A member shows offline. Check that grid communication reaches it: the members must be able to talk to each other on the grid port, and a firewall rule or a changed IP address on the management interface will break that. See Network Ports for the port configuration and the Use Preferred Grid Port IP setting on Storage System Modify, which pins grid traffic to a chosen interface on systems with several networks.
A member shows a warning that will not clear. Some changes park a system in a warning state until it is restarted. If a member reports that a restart is required, the state persists until the reboot happens -- it is not a transient condition that clears itself.
Management operations fail but storage is fine. This is the signature of a lost or unreachable grid master, since the master coordinates configuration but carries no data. Elect a new master with Set Grid Master.
Related pages
- Storage System -- individual member configuration, renaming, and the preferred grid port setting
- Configure Member Standby -- taking a member out of service without removing it from the grid
- License Management -- licensing across grid members
- Network Ports -- the network configuration grid communication depends on
- Remote-replication (DR) -- replication between grid members
- HA Cluster Setup (JBODs) -- clustered pools within a grid
- Security Configuration -- users and roles, which become grid-wide on join
Verified against QuantaStor 6.9.0.