Grid Configuration: Difference between revisions

From OSNEXUS Online Documentation Site
Jump to navigation Jump to search
← Older editNewer edit →
VisualWikitext
mNo edit summary
m Rewrite from the product: document all six Storage System Grid operations with new screenshots, correct the false claim that duplicate user accounts resolve by grid-master precedence (only admin does; User/UserGroup/Role merge keep-superset so both survive), explain the four names for the grid master role, document that Force is required to remove a Ceph cluster member, add the 12 grid CLI commands including grid-merge/grid-split, and drop the QuantaStor 5 video (QSTOR-12352)
Line 1: Line 1:
[[Category:admin_guide]]
[[Category:admin_guide]]
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 (DR)|remote replication]] and the clustered pool configurations.


A 'Storage Grid' combines multiple QuantaStor systems so that they can be managed as one. Storage Grid technology is built into the QuantaStor platform and requires no additional software to install or maintain. The act of logging into any QuantaStor system in a grid enables the management of the entire grid of QuantaStor systems (assuming that access is granted). A QuantaStor system can only be part of one grid, but each grid may contain any number of storage clusters, each with multiple storage pools.  
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.


{| class="wikitable"
! Section !! Covers
|-
| [[#The Grid Master|The Grid Master]] || The coordinating member, what it does, and what happens if it is lost
|-
| [[#Creating a Grid|Creating a Grid]] || Turning a standalone system into a one-member grid
|-
| [[#Adding a System|Adding a System]] || Joining a system, and what merges when it joins
|-
| [[#Renaming a Grid|Renaming a Grid]] || The grid's own name and description
|-
| [[#Changing the Grid Master|Changing the Grid Master]] || Electing a different coordinator
|-
| [[#Removing a System|Removing a System]] || Taking a member out, including Ceph members
|-
| [[#Deleting a Grid|Deleting a Grid]] || Dissolving the grid, and what survives
|-
| [[#Managing a Grid from the CLI|Managing a Grid from the CLI]] || The twelve <code>qs</code> grid commands
|}


''' OSNEXUS Videos '''
{{Navigation|Storage Management &rarr; Storage Systems ''(section)'' &rarr; Storage System Grid ''(toolbar group)''}}
* [[Image:youtube_icon.png|50px|link=https://www.youtube.com/watch?v=MeX9rAmskvo]] [https://www.youtube.com/watch?v=VpfcjZDO3Ys Covers QuantaStor 5 Storage Grid Setup. [10:58]]


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)'''.


{{Template:GridSetupProceedure}}
[[File:grid_overview.png|thumb|right|800px|A three-member grid. The tree header carries the grid name and the member list marks the 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:
 
{| class="wikitable"
! 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"
|-
| <code>qs grid-get</code> output || <code>Master Node ID</code>
|}
 
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.''' 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|Changing the Grid Master]]'''.
 
== Creating a Grid ==
 
{{Navigation|Storage Management &rarr; Storage Systems ''(section)'' &rarr; Storage System Grid ''(toolbar group)'' &rarr; Create 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 <code>-</code>, <code>_</code> and <code>.</code>
 
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 ==
 
{{Navigation|Storage Management &rarr; Storage Systems ''(section)'' &rarr; Storage System Grid ''(toolbar group)'' &rarr; Add System}}
 
[[File:grid_add_system.png|thumb|right|500px|Joining a system needs its IP address and its own admin credentials.]]
 
* '''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.
 
=== 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 <code>admin</code> account.''' Duplicate <code>admin</code> 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 ==
 
{{Navigation|Storage Management &rarr; Storage Systems ''(section)'' &rarr; Storage System Grid ''(toolbar group)'' &rarr; Modify Grid}}
 
[[File:grid_modify.png|thumb|right|459px|The grid's name and description.]]
 
'''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 ==
 
{{Navigation|Storage Management &rarr; Storage Systems ''(section)'' &rarr; Storage System Grid ''(toolbar group)'' &rarr; Set Grid Master}}
 
[[File:grid_set_master.png|thumb|right|459px|Electing a different member as the primary coordinator.]]
 
* '''Storage System''' -- the member to elect as the primary coordinator for synchronizing grid configuration state.
* '''Force''' -- carries the force flag through to the operation. Use it when a normal election will not proceed.
 
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.
 
== Removing a System ==
 
{{Navigation|Storage Management &rarr; Storage Systems ''(section)'' &rarr; Storage System Grid ''(toolbar group)'' &rarr; Remove System}}
 
[[File:grid_remove_system.png|thumb|right|459px|Removing a member. Force is required for a Ceph cluster member.]]
 
* '''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 <code>admin</code> 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 ==
 
{{Navigation|Storage Management &rarr; Storage Systems ''(section)'' &rarr; Storage System Grid ''(toolbar group)'' &rarr; Delete 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]].
 
{| class="wikitable"
! Command !! Purpose
|-
| [[QuantaStor CLI Command Reference#grid-create|<code>qs grid-create</code>]] || Create a grid on this system
|-
| [[QuantaStor CLI Command Reference#grid-get|<code>qs grid-get</code>]] || Show the grid, its master, and its members
|-
| [[QuantaStor CLI Command Reference#grid-modify|<code>qs grid-modify</code>]] || Change the grid name or description
|-
| [[QuantaStor CLI Command Reference#grid-add|<code>qs grid-add</code>]] || Add a system by IP address
|-
| [[QuantaStor CLI Command Reference#grid-remove|<code>qs grid-remove</code>]] || Remove a member
|-
| [[QuantaStor CLI Command Reference#grid-set-master|<code>qs grid-set-master</code>]] || Elect a different grid master
|-
| [[QuantaStor CLI Command Reference#grid-delete|<code>qs grid-delete</code>]] || Dissolve the grid
|-
| [[QuantaStor CLI Command Reference#grid-merge|<code>qs grid-merge</code>]] || Merge another grid into this one
|-
| [[QuantaStor CLI Command Reference#grid-split|<code>qs grid-split</code>]] || Split members out into a separate grid
|-
| [[QuantaStor CLI Command Reference#grid-assoc-list|<code>qs grid-assoc-list</code>]] || List grid associations
|-
| [[QuantaStor CLI Command Reference#grid-assoc-get|<code>qs grid-assoc-get</code>]] || Show one system's grid association
|-
| [[QuantaStor CLI Command Reference#grid-send-supportlogs|<code>qs grid-send-supportlogs</code>]] || Collect and send support logs for the whole grid
|}
 
Building a three-member grid from the first system:
 
<pre style="font-size: smaller">
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
</pre>
 
Confirming the result -- <code>grid-get</code> reports the grid and its <code>Master Node ID</code>, and <code>system-list</code> shows the members:
 
<pre style="font-size: smaller">
qs grid-get
qs system-list
</pre>
 
<code>grid-merge</code> and <code>grid-split</code> 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
 
----
<small>''Verified against QuantaStor 6.9.0.''</small>

Revision as of 04:11, 3 September 2026

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
Navigation: Storage Management → Storage Systems (section) → Storage System Grid (toolbar group)

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).

A three-member grid. The tree header carries the grid name and the member list marks the 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. 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

Navigation: Storage Management → Storage Systems (section) → Storage System Grid (toolbar group) → Create 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

Navigation: Storage Management → Storage Systems (section) → Storage System Grid (toolbar group) → Add System
Joining a system needs its IP address and its own admin credentials.
  • 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.

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

Navigation: Storage Management → Storage Systems (section) → Storage System Grid (toolbar group) → Modify Grid
The grid's name and description.

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

Navigation: Storage Management → Storage Systems (section) → Storage System Grid (toolbar group) → Set Grid Master
Electing a different member as the primary coordinator.
  • Storage System -- the member to elect as the primary coordinator for synchronizing grid configuration state.
  • Force -- carries the force flag through to the operation. Use it when a normal election will not proceed.

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.

Removing a System

Navigation: Storage Management → Storage Systems (section) → Storage System Grid (toolbar group) → Remove System
Removing a member. Force is required for a Ceph cluster member.
  • 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

Navigation: Storage Management → Storage Systems (section) → Storage System Grid (toolbar group) → Delete 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

Verified against QuantaStor 6.9.0.

Retrieved from "https://wiki.osnexus.com/index.php?title=Grid_Configuration&oldid=27543"