Seagate Corvault Configuration - Revision history

Qadmin: /* Logical Volume Creation */

2026-01-22T01:40:59Z

Logical Volume Creation

← Older revision		Revision as of 01:40, 22 January 2026
Line 38:		Line 38:

	The first thing to consider is how many logical volumes (LUNs) to create per ADAPT pool. Making more LUNs will generally improve performance and concurrency as the filesystems (OpenZFS, Ceph) will be able to send more IO concurrently when you have more devices. This is because more devices equals more VDEVs in scale-up configurations and more OSDs in scale-out configurations. In practice we recommend dividing up each ADAPT pool into 16, 24, or 32x LUNs. QuantaStor makes this easy when you create the logical volumes via QuantaStor as it will automatically calculate the maximum size for the volumes in order to use up all the available space in the ADAPT pool.		The first thing to consider is how many logical volumes (LUNs) to create per ADAPT pool. Making more LUNs will generally improve performance and concurrency as the filesystems (OpenZFS, Ceph) will be able to send more IO concurrently when you have more devices. This is because more devices equals more VDEVs in scale-up configurations and more OSDs in scale-out configurations. In practice we recommend dividing up each ADAPT pool into 16, 24, or 32x LUNs. QuantaStor makes this easy when you create the logical volumes via QuantaStor as it will automatically calculate the maximum size for the volumes in order to use up all the available space in the ADAPT pool.

			* Note - In scale-up configurations using many Corvaults (eg 10x) you'll want something like 16x LUNs per ADAPT pool in order to keep the device count under 500. 500 devices isn't a hard limit but device count can impact boot speed and failover speed and fewer devices per pool makes it easier to manage.

	* Note - In scale-out configurations note that more OSDs means more RAM and CPU requirements. Generally speaking, allocate 1.5GHz and 4GB of RAM to each OSD. So choosing 32x LUNs per ADAPT pool will require about double the CPU and RAM as going with 16x LUNs per ADAPT pool but it will also roughly double the performance.		* Note - In scale-out configurations note that more OSDs means more RAM and CPU requirements. Generally speaking, allocate 1.5GHz and 4GB of RAM to each OSD. So choosing 32x LUNs per ADAPT pool will require about double the CPU and RAM as going with 16x LUNs per ADAPT pool but it will also roughly double the performance.

Qadmin: /* Logical Volume Creation */

2026-01-22T01:38:21Z

Logical Volume Creation

← Older revision		Revision as of 01:38, 22 January 2026
Line 37:		Line 37:
	=== Logical Volume Creation ===		=== Logical Volume Creation ===

	The first thing to consider is how many logical volumes (LUNs) to create per ADAPT pool. Making more LUNs will generally improve performance and concurrency as the filesystems (OpenZFS, Ceph) will be able to send more IO concurrently when you have more devices. This is because more devices equals more VDEVs in scale-up configurations and more OSDs in scale-out configurations. In practice we recommend dividing up each ADAPT pool into 16, 24, or 32x LUNs. In scale-out configurations note that more OSDs means more RAM and CPU requirements. Generally speaking, allocate 1.5GHz and 4GB of RAM to each OSD. So choosing 32x LUNs per ADAPT pool will require about double the CPU and RAM as going with 16x LUNs per ADAPT pool.		The first thing to consider is how many logical volumes (LUNs) to create per ADAPT pool. Making more LUNs will generally improve performance and concurrency as the filesystems (OpenZFS, Ceph) will be able to send more IO concurrently when you have more devices. This is because more devices equals more VDEVs in scale-up configurations and more OSDs in scale-out configurations. In practice we recommend dividing up each ADAPT pool into 16, 24, or 32x LUNs. QuantaStor makes this easy when you create the logical volumes via QuantaStor as it will automatically calculate the maximum size for the volumes in order to use up all the available space in the ADAPT pool.

			* Note - In scale-out configurations note that more OSDs means more RAM and CPU requirements. Generally speaking, allocate 1.5GHz and 4GB of RAM to each OSD. So choosing 32x LUNs per ADAPT pool will require about double the CPU and RAM as going with 16x LUNs per ADAPT pool but it will also roughly double the performance.

	* Note - For very large scale-out configurations fewer LUNs per Corvault translates to greater scalability. For example, 100x Corvaults each delivering 32x LUNs equates to 3200x OSDs in the cluster. Keeping your scale-out clusters under 4000 OSDs will make them easier to manage.		* Note - For very large scale-out configurations fewer LUNs per Corvault translates to greater scalability. For example, 100x Corvaults each delivering 32x LUNs equates to 3200x OSDs in the cluster. Keeping your scale-out clusters under 4000 OSDs will make them easier to manage.

Qadmin: /* Seagate Corvault Disk Group (DG) and Pool Creation */

2026-01-22T01:35:56Z

Seagate Corvault Disk Group (DG) and Pool Creation

← Older revision		Revision as of 01:35, 22 January 2026
Line 32:		Line 32:

	The Corvault units have a concept of a DG and a Pool but in practice these are generally one-to-one with each DG being used by a single pool. We recommend dividing the Corvault into two ADAPT Pools with 53x HDDs per pool when using 4U106 Corvaults and with 42x HDDs per pool when using the 5U84 Corvaults. When creating a pool you'll get the opportunity to select a ADAPT layout, we generally use the 16k+2m layout as that provides the most capacity with 88% usable. Note also that you'll need to allocate at least one virtual hot-spare in each Corvault Pool, we generally set this to 2x virtual spares per Pool. Note that this is not a specific drive that's a spare as the data is distributed across all the drives in an ADAPT pool but when a drive fails this virtual spare's worth of space will be used to fully repair the Pool to 100%. In many cases we find that the ADAPT pools are already configured when the system arrives. If you see that there are two ADAPT pools in 16k+2m layout already configured on your system then you can skip this step and move onto logical volume creation.		The Corvault units have a concept of a DG and a Pool but in practice these are generally one-to-one with each DG being used by a single pool. We recommend dividing the Corvault into two ADAPT Pools with 53x HDDs per pool when using 4U106 Corvaults and with 42x HDDs per pool when using the 5U84 Corvaults. When creating a pool you'll get the opportunity to select a ADAPT layout, we generally use the 16k+2m layout as that provides the most capacity with 88% usable. Note also that you'll need to allocate at least one virtual hot-spare in each Corvault Pool, we generally set this to 2x virtual spares per Pool. Note that this is not a specific drive that's a spare as the data is distributed across all the drives in an ADAPT pool but when a drive fails this virtual spare's worth of space will be used to fully repair the Pool to 100%. In many cases we find that the ADAPT pools are already configured when the system arrives. If you see that there are two ADAPT pools in 16k+2m layout already configured on your system then you can skip this step and move onto logical volume creation.

			[[File:qs_wiki_seagatecv_pool.png\|870x870px]]

	=== Logical Volume Creation ===		=== Logical Volume Creation ===

Qadmin: /* Multipath Verification */

2026-01-22T01:27:02Z

Multipath Verification

← Older revision		Revision as of 01:27, 22 January 2026
Line 47:		Line 47:
	# Verify Corvault LUNs appear as new block devices.		# Verify Corvault LUNs appear as new block devices.

	== ~~Multipath Verification~~ ==		== Summary ==

	~~Verify that each~~ Corvault ~~LUN has multiple paths:~~		The Seagate Corvault units can be thought of as smart JBODs as they have a layer of fault-tolerance and durability built-in. This built-in durability does not negate the need for having fault-tolerance at the QuantaStor level. We recommend choosing at minimum a single parity layout (RAIDZ1, with RAIDZ2 recommended) in scale-up configurations and a double-parity layout (EC 4k+2m) at minimum in scale-out configurations.

	~~```bash~~
	~~multipath~~ -ll

Qadmin: /* Disk Discovery */

2026-01-22T01:24:33Z

Disk Discovery

← Older revision		Revision as of 01:24, 22 January 2026
Line 39:		Line 39:
	* Note - For very large scale-out configurations fewer LUNs per Corvault translates to greater scalability. For example, 100x Corvaults each delivering 32x LUNs equates to 3200x OSDs in the cluster. Keeping your scale-out clusters under 4000 OSDs will make them easier to manage.		* Note - For very large scale-out configurations fewer LUNs per Corvault translates to greater scalability. For example, 100x Corvaults each delivering 32x LUNs equates to 3200x OSDs in the cluster. Keeping your scale-out clusters under 4000 OSDs will make them easier to manage.

	=== ~~Disk~~ Discovery ===		=== Volume Assignment & Discovery ===

	In QuantaStor:		When you create your Corvault logical volumes via the QuantaStor External Systems module it will also allow you to assign those to specific QuantaStor hosts. QuantaStor will automatically take care of configuring the volume to SAS host address for you within the Corvault units. After they've been assigned navigate to the Physical Disks section in the QuantaStor WUI then:

	# Navigate to '''Storage System → Physical Disks'''.		# Navigate to '''Storage System → Physical Disks'''.
	# Click '''Rescan Disks'''.		# Click '''Rescan Disks'''.
	# Verify Corvault LUNs appear as new block devices.		# Verify Corvault LUNs appear as new block devices.

	~~{{Note\|~~
	~~Corvault LUNs will appear as external SAN disks, not JBOD devices.~~
	}}

	== Multipath Verification ==		== Multipath Verification ==

Qadmin: /* Logical Volume Creation */

2026-01-22T01:21:59Z

Logical Volume Creation

← Older revision		Revision as of 01:21, 22 January 2026
Line 35:		Line 35:
	=== Logical Volume Creation ===		=== Logical Volume Creation ===

	~~Logical Device Sizing~~		The first thing to consider is how many logical volumes (LUNs) to create per ADAPT pool. Making more LUNs will generally improve performance and concurrency as the filesystems (OpenZFS, Ceph) will be able to send more IO concurrently when you have more devices. This is because more devices equals more VDEVs in scale-up configurations and more OSDs in scale-out configurations. In practice we recommend dividing up each ADAPT pool into 16, 24, or 32x LUNs. In scale-out configurations note that more OSDs means more RAM and CPU requirements. Generally speaking, allocate 1.5GHz and 4GB of RAM to each OSD. So choosing 32x LUNs per ADAPT pool will require about double the CPU and RAM as going with 16x LUNs per ADAPT pool.

	* Note - ~~Use~~ fewer, ~~larger volumes rather than many small volumes for optimal QuantaStor performance and management simplicity~~.		* Note - For very large scale-out configurations fewer LUNs per Corvault translates to greater scalability. For example, 100x Corvaults each delivering 32x LUNs equates to 3200x OSDs in the cluster. Keeping your scale-out clusters under 4000 OSDs will make them easier to manage.

	=== Disk Discovery ===		=== Disk Discovery ===

Qadmin: /* Seagate Corvault Disk Group (DG) and Pool Creation */

2026-01-22T01:15:24Z

Seagate Corvault Disk Group (DG) and Pool Creation

← Older revision		Revision as of 01:15, 22 January 2026
Line 31:		Line 31:
	=== Seagate Corvault Disk Group (DG) and Pool Creation ===		=== Seagate Corvault Disk Group (DG) and Pool Creation ===

	The Corvault units have a concept of a DG and a Pool but in practice these are generally one-to-one with each DG being used by a single pool. We recommend dividing the Corvault into two ADAPT Pools with 53x HDDs per pool when using 4U106 Corvaults and with 42x HDDs per pool when using the 5U84 Corvaults. When creating a pool you'll get the opportunity to select a ADAPT layout, we generally use the 16k+2m layout as that provides the most capacity ~~and~~ 88% usable. Note also that you'll need to allocate at least one virtual hot-spare in each Corvault Pool, we generally set this to 2x virtual spares per Pool. Note that this is not a specific drive that's a spare as the data is distributed across all the drives in an ADAPT pool but when a drive fails this virtual spare's worth of space will be used to fully repair the Pool to 100%. In many cases we find that the ADAPT pools are already configured when the system arrives. If you see that there are two ADAPT pools in 16k+2m layout already configured on your system then you can skip this step and move onto logical volume creation.		The Corvault units have a concept of a DG and a Pool but in practice these are generally one-to-one with each DG being used by a single pool. We recommend dividing the Corvault into two ADAPT Pools with 53x HDDs per pool when using 4U106 Corvaults and with 42x HDDs per pool when using the 5U84 Corvaults. When creating a pool you'll get the opportunity to select a ADAPT layout, we generally use the 16k+2m layout as that provides the most capacity with 88% usable. Note also that you'll need to allocate at least one virtual hot-spare in each Corvault Pool, we generally set this to 2x virtual spares per Pool. Note that this is not a specific drive that's a spare as the data is distributed across all the drives in an ADAPT pool but when a drive fails this virtual spare's worth of space will be used to fully repair the Pool to 100%. In many cases we find that the ADAPT pools are already configured when the system arrives. If you see that there are two ADAPT pools in 16k+2m layout already configured on your system then you can skip this step and move onto logical volume creation.

	=== Logical Volume Creation ===		=== Logical Volume Creation ===

Qadmin: /* Multipath-Path Connectivity */

2026-01-22T01:13:39Z

Multipath-Path Connectivity

← Older revision		Revision as of 01:13, 22 January 2026
Line 16:		Line 16:

	=== Multipath-Path Connectivity ===		=== Multipath-Path Connectivity ===

			Multipath connectivity is the preferred way to connect your Corvaults to the QuantaStor storage servers. Note how HBA1 connects to each IO Module (IOM) and HBA2 also connects to both IOMs. This is important as it ensures connectivity in the event of an IOM failure. This is also important due to the way QuantaStor does IO fencing via SCSI3 Persistent Reservations (WERO mode).

	[[File:qs_wiki_seagatecv_multipath.png\|870x870px]]		[[File:qs_wiki_seagatecv_multipath.png\|870x870px]]

Qadmin: /* Single-Path Connectivity */

2026-01-22T01:11:01Z

Single-Path Connectivity

← Older revision		Revision as of 01:11, 22 January 2026
Line 10:		Line 10:

	=== Single-Path Connectivity ===		=== Single-Path Connectivity ===
	~~[[File:qs_wiki_seagatecv_singlepath.png\|870x870px]]~~

	Single path connectivity will provide 48Gb (4x SAS lanes at 12Gb) of throughput to the Corvault which will deliver about 5GB/sec. We generally recommend going with a multi-path configuration but if your cluster is connecting to a large number of Corvaults such as 8x or 10x then you may not have enough SAS ports across your HBAs to connect to them all twice to enable multi-pathing. In those cases single-path is fine.		Single path connectivity will provide 48Gb (4x SAS lanes at 12Gb) of throughput to the Corvault which will deliver about 5GB/sec. We generally recommend going with a multi-path configuration but if your cluster is connecting to a large number of Corvaults such as 8x or 10x then you may not have enough SAS ports across your HBAs to connect to them all twice to enable multi-pathing. In those cases single-path is fine.

			[[File:qs_wiki_seagatecv_singlepath.png\|870x870px]]

	=== Multipath-Path Connectivity ===		=== Multipath-Path Connectivity ===

Qadmin: /* Single-Path Connectivity */

2026-01-22T01:10:46Z

Single-Path Connectivity

← Older revision		Revision as of 01:10, 22 January 2026
Line 12:		Line 12:
	[[File:qs_wiki_seagatecv_singlepath.png\|870x870px]]		[[File:qs_wiki_seagatecv_singlepath.png\|870x870px]]

			Single path connectivity will provide 48Gb (4x SAS lanes at 12Gb) of throughput to the Corvault which will deliver about 5GB/sec. We generally recommend going with a multi-path configuration but if your cluster is connecting to a large number of Corvaults such as 8x or 10x then you may not have enough SAS ports across your HBAs to connect to them all twice to enable multi-pathing. In those cases single-path is fine.

	=== Multipath-Path Connectivity ===		=== Multipath-Path Connectivity ===