Template:ClusteredHACommon: Difference between revisions
| (28 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Site Cluster Configuration == | == Site Cluster Configuration == | ||
[[File:qs_heartbeat_rings.png]] | [[File:qs_heartbeat_rings.png|thumb|600px]] | ||
The Site Cluster represents a group of two or more systems that have an active heartbeat mechanism which is used to activate resource fail-over in the event that a resource (storage pool) goes offline. Site Clusters should be comprised of QuantaStor systems which are all in the same location but could span buildings within the same site. The heartbeat expects a low latency connection and is typically done via dual direct Ethernet cable connections between a pair of QuantaStor systems but could also be done with Ethernet switches in-between. | |||
After the heart-beat rings are setup (Site Cluster) the HA group can be created for each pool and virtual IPs created within the HA group. All SMB/NFS/iSCSI access must flow through the virtual IP associated with the Storage Pool in order to ensure client up-time in the event of an automatic or manual fail-over of the pool to another system. | After the heart-beat rings are setup (Site Cluster) the HA group can be created for each pool and virtual IPs created within the HA group. All SMB/NFS/iSCSI access must flow through the virtual IP associated with the Storage Pool in order to ensure client up-time in the event of an automatic or manual fail-over of the pool to another system. | ||
[[File:osn_clustered_san_config.png| | [[File:osn_clustered_san_config.png|600px]] | ||
<!-- Section needs to be moved to an Admin Guide or other location | <!-- Section needs to be moved to an Admin Guide or other location | ||
| Line 16: | Line 18: | ||
* A virtual IP address can be assigned to the QuantaStor grid for management and automatic master node grid election. | * A virtual IP address can be assigned to the QuantaStor grid for management and automatic master node grid election. | ||
:: [[File:qs_site_grid_ip.png|600px]] | :: [[File:qs_site_grid_ip.png|600px]] | ||
:: The host that owns that virtual IP is automatically elected as the QuantaStor grid master node. The master node is responsible for broadcasting updates to keep all nodes up to date with current configuration data across the grid. Assigning a grid IP to a QuantaStor grid is optional. The grid master node is pinned in such configurations to the current node until the administrator manually selects a new | :: The host that owns that virtual IP is automatically elected as the QuantaStor grid master node. The master node is responsible for broadcasting updates to keep all nodes up to date with current configuration data across the grid. Assigning a grid IP to a QuantaStor grid is optional. The grid master node is pinned in such configurations to the current node until the administrator manually selects a new system to act as the master node by right-clicking on the grid object in the WUI and choosing 'Set Master Node...'. Only the subset of nodes that one would want to potentially be the grid master should be added to the Site Cluster. | ||
* A virtual IP address can be assigned to a Gluster volume to that virtual IP failover occurs automatically for NFS/SMB connections to the scale-out network share. | * A virtual IP address can be assigned to a Gluster volume to that virtual IP failover occurs automatically for NFS/SMB connections to the scale-out network share. | ||
:: [[File:qs_site_gluster_ip.png|600px]] | :: [[File:qs_site_gluster_ip.png|600px]] | ||
:: In these configurations all | :: In these configurations all system nodes which are used to provide storage to the Gluster volume should be members of the Site Cluster. | ||
-- Move Section --> | -- Move Section --> | ||
| Line 26: | Line 28: | ||
--> | --> | ||
=== Grid Setup === | === Grid Setup === | ||
[[File:Strg Sys Grid Menu.jpg|thumb|512px|Create a grid and add systems to the grid.]] | |||
Both systems must be in the same grid before the Site Cluster can be created. Grid creation takes less than a minute and the buttons to create the grid and additional systems to the grid are in the ribbon bar. QuantaStor systems can only be members of a single grid at a time but up to 64 systems can be added to a grid which can contain multiple independent Site Clusters. | Both systems must be in the same grid before the Site Cluster can be created. Grid creation takes less than a minute and the buttons to create the grid and additional systems to the grid are in the ribbon bar. QuantaStor systems can only be members of a single grid at a time but up to 64 systems can be added to a grid which can contain multiple independent Site Clusters. | ||
=== Site Cluster Network Configuration === | === Site Cluster Network Configuration === | ||
| Line 38: | Line 39: | ||
* Each Management and Data network must be on separate subnets to allow for proper routing of requests from clients and proper failover in the event of a network failure. | * Each Management and Data network must be on separate subnets to allow for proper routing of requests from clients and proper failover in the event of a network failure. | ||
To change the configuration of the network ports to meet the above requirements please see the section on [[ | To change the configuration of the network ports to meet the above requirements please see the section on [[https://wiki.osnexus.com/index.php?title=Network_Ports Network Ports]]. | ||
==== Heartbeat Networks must be Dedicated ==== | ==== Heartbeat Networks must be Dedicated ==== | ||
The network subnet used for heartbeat activity should not be used for any other purpose besides the heartbeat. Using the above example, the network of 10.3.x.x/16 and 10.4.x.x/16 are being used for the heartbeat traffic. Traffic for client communication such as NFS/iSCSI traffic to the | The network subnet used for heartbeat activity should not be used for any other purpose besides the heartbeat. Using the above example, the network of 10.3.x.x/16 and 10.4.x.x/16 are being used for the heartbeat traffic. Traffic for client communication such as NFS/iSCSI traffic to the system via the storage pool virtual IP (see next section) must be on a separate network, for example, 10.111.x.x/16. Mixing the HA heartbeat traffic with the client communication traffic can cause a false-positive failover event to occur. | ||
[[File:Create Site Clstr Cnfg.jpg|thumb|256px|Create the Site Cluster]] | |||
=== Creating the Site Cluster === | === Creating the Site Cluster === | ||
The Site Cluster name is a required field and can be set to anything you like, for example '''ha-pool-cluster'''. The location and description fields are optional. Note that all of the network ports selected are on the same subnet with unique IPs for each node. These are the IP addresses that will be used for heartbeat communication. Client communication will be handled later in the Creating a Virtual IP in the Storage Pool HA Group section. | The Site Cluster name is a required field and can be set to anything you like, for example '''ha-pool-cluster'''. The location and description fields are optional. Note that all of the network ports selected are on the same subnet with unique IPs for each node. These are the IP addresses that will be used for heartbeat communication. Client communication will be handled later in the Creating a Virtual IP in the Storage Pool HA Group section. | ||
=== Dual Heartbeat Rings | '''Navigation:''' High-availability VIF Management --> Site Clusters --> Site Cluster --> Create Site Cluster ''(toolbar)'' | ||
=== Dual Heartbeat Rings Advised === | |||
Any cluster intended for production deployment | '''Any cluster intended for production deployment should have at least two heartbeat Cluster Rings configured.''' Configurations using a single heartbeat Cluster Ring are fragile and are only suitable for test configurations not intended for production use. Without dual rings in place, it is very easy for a false positive failover event to occur, making any network changes likely to activate a fail-over inadvertently. | ||
After creating the Site Cluster, an initial Cluster Ring will exist. Create a second by | After creating the Site Cluster, an initial Cluster Ring will exist. Create a second by clicking the 'Add Cluster Ring' button from the toolbar. | ||
'''Navigation:''' High-availability VIF Management --> Site Clusters --> Site Cluster --> Add Cluster Ring ''(toolbar)'' | |||
[[File: | [[File:Add Cluster Ring - Web.jpg|712px]] | ||
Latest revision as of 19:37, 8 January 2024
Site Cluster Configuration
The Site Cluster represents a group of two or more systems that have an active heartbeat mechanism which is used to activate resource fail-over in the event that a resource (storage pool) goes offline. Site Clusters should be comprised of QuantaStor systems which are all in the same location but could span buildings within the same site. The heartbeat expects a low latency connection and is typically done via dual direct Ethernet cable connections between a pair of QuantaStor systems but could also be done with Ethernet switches in-between.
After the heart-beat rings are setup (Site Cluster) the HA group can be created for each pool and virtual IPs created within the HA group. All SMB/NFS/iSCSI access must flow through the virtual IP associated with the Storage Pool in order to ensure client up-time in the event of an automatic or manual fail-over of the pool to another system.
Grid Setup
Both systems must be in the same grid before the Site Cluster can be created. Grid creation takes less than a minute and the buttons to create the grid and additional systems to the grid are in the ribbon bar. QuantaStor systems can only be members of a single grid at a time but up to 64 systems can be added to a grid which can contain multiple independent Site Clusters.
Site Cluster Network Configuration
Before beginning, note that when you create the Site Cluster it will automatically create the first heartbeat ring (Cluster Ring) on the network that you have specified. This can be a direct connect private network between two systems or the ports could be connected to a switch. The key requirement is that the name of the ports used for the Cluster Ring must be the same. For example, if eth0 is the port on System A with IP 10.3.0.5/16 then you must configure the matching eth0 network port on System B with an IP on the same network (10.3.0.0/16), for example 10.3.0.7/16.
- Each Highly Available Virtual Network Interface requires Three IP Addresses be configured in the same subnet: one for the Virtual Network Interface and one for each Network Device on each QuantaStor Storage System.
- Both QuantaStor systems must have unique IP address for their Network devices.
- Each Management and Data network must be on separate subnets to allow for proper routing of requests from clients and proper failover in the event of a network failure.
To change the configuration of the network ports to meet the above requirements please see the section on [Network Ports].
Heartbeat Networks must be Dedicated
The network subnet used for heartbeat activity should not be used for any other purpose besides the heartbeat. Using the above example, the network of 10.3.x.x/16 and 10.4.x.x/16 are being used for the heartbeat traffic. Traffic for client communication such as NFS/iSCSI traffic to the system via the storage pool virtual IP (see next section) must be on a separate network, for example, 10.111.x.x/16. Mixing the HA heartbeat traffic with the client communication traffic can cause a false-positive failover event to occur.
Creating the Site Cluster
The Site Cluster name is a required field and can be set to anything you like, for example ha-pool-cluster. The location and description fields are optional. Note that all of the network ports selected are on the same subnet with unique IPs for each node. These are the IP addresses that will be used for heartbeat communication. Client communication will be handled later in the Creating a Virtual IP in the Storage Pool HA Group section.
Navigation: High-availability VIF Management --> Site Clusters --> Site Cluster --> Create Site Cluster (toolbar)
Dual Heartbeat Rings Advised
Any cluster intended for production deployment should have at least two heartbeat Cluster Rings configured. Configurations using a single heartbeat Cluster Ring are fragile and are only suitable for test configurations not intended for production use. Without dual rings in place, it is very easy for a false positive failover event to occur, making any network changes likely to activate a fail-over inadvertently.
After creating the Site Cluster, an initial Cluster Ring will exist. Create a second by clicking the 'Add Cluster Ring' button from the toolbar.
Navigation: High-availability VIF Management --> Site Clusters --> Site Cluster --> Add Cluster Ring (toolbar)
