QuantaStor Internal Architecture - Revision history

Qadmin at 20:23, 21 March 2019

2019-03-21T20:23:55Z

← Older revision		Revision as of 20:23, 21 March 2019
Line 20:		Line 20:

	[[File:pool.png\|300px]]		[[File:pool.png\|300px]]

			== System Internals ==

			QuantaStor systems are accessible via SSH with the default user name of 'qadmin' with a default password of 'qadmin' once logged into the system you'll be able to view the internal Linux based filesystem used for the boot/system device.

			=== Key Internal Directories ===

			==== Storage Pools ====
			Within a QuantaStor system all storage pools which are local to the system are visible under /mnt/storage-pools/qs-POOLID/ where POOLID is the UUID of the Storage Pool. Custom data processing may be done by adding scripts or 3rd party applications (typically backup agents) to QuantaStor to then backup or process the data in a given storage pool directly. The [[+ Integration Guide Overview\|Integration Guide]] has more information on some of the applications that have been integrated with QuantaStor.

			==== Internal Directory Usage ====
			The QuantaStor installation process is comprised of several packages (qstorservice, qstormanager, etc) but the primary areas used by the system are /var/opt/osnexus/ and /opt/osnexus/. Additionally, service scripts and some configuration files are stored in /etc/. QuantaStor has a number of CLI utilities available within the platform, most of which start with qs- and the main QuantaStor management CLI is just called 'qs'.

Qadmin at 20:12, 21 March 2019

2019-03-21T20:12:40Z

← Older revision		Revision as of 20:12, 21 March 2019
Line 9:		Line 9:
	QuantaStor's built-in storage grid technology enables multiple QuantaStor servers to be combined together so that they can be managed as one. Grid formation is done by creating a Storage Grid on a first QuantaStor server and then adding additional QuantaStor servers to the grid in a batch or one at a time. Once a Storage Grid is formed a number of advanced features are enabled like Remote Replication, Clustering, and more. No additional software is required to manage a grid of systems as all management functions for all systems are linked. QuantaStor's grid technology maintains a distributed configuration database that spans all systems so that configuration changes made to any system are communicated to all systems within a few seconds. QuantaStor internally maintains this information in a Sqlite database and uses an encrypted SOAP (XML based) protocol for communication between nodes to communicate configuration changes throughout a given Storage Grid. Each Storage Grid has what is referred to as a Primary Node or a Master Node. This is the system that is responsible for communicating update events to Secondary nodes within a given Storage Grid. Any system within a Storage Grid may be elected as a Primary/Master node by using the 'Set Grid Master' dialog in the Web UI or by updating this via the QS CLI or QS REST API. Automatic election of a new Primary/Master node is accomplished by adding a floating "gridIP" interface to the grid.		QuantaStor's built-in storage grid technology enables multiple QuantaStor servers to be combined together so that they can be managed as one. Grid formation is done by creating a Storage Grid on a first QuantaStor server and then adding additional QuantaStor servers to the grid in a batch or one at a time. Once a Storage Grid is formed a number of advanced features are enabled like Remote Replication, Clustering, and more. No additional software is required to manage a grid of systems as all management functions for all systems are linked. QuantaStor's grid technology maintains a distributed configuration database that spans all systems so that configuration changes made to any system are communicated to all systems within a few seconds. QuantaStor internally maintains this information in a Sqlite database and uses an encrypted SOAP (XML based) protocol for communication between nodes to communicate configuration changes throughout a given Storage Grid. Each Storage Grid has what is referred to as a Primary Node or a Master Node. This is the system that is responsible for communicating update events to Secondary nodes within a given Storage Grid. Any system within a Storage Grid may be elected as a Primary/Master node by using the 'Set Grid Master' dialog in the Web UI or by updating this via the QS CLI or QS REST API. Automatic election of a new Primary/Master node is accomplished by adding a floating "gridIP" interface to the grid.

	=== System Communication ===		== System Communication ==

	Every API call to a QuantaStor system, irrespective of protocol or client (WUI, CLI, REST API, SOAP, etc) is authenticated and authorized on every time. QuantaStor is session-less but does have an authentication token system. Communication between QuantaStor systems uses the WSDL SOAP protocol and all API calls are auto-forwarded to the appropriate system within the grid to execute any given operation/task. QuantaStor systems perform resource locking to ensure that multiple tasks/operations can be queued and executed with the necessary resources become available. When using the QuantaStor CLI it will block and wait for a given operation to complete and then print the results of the QuantaStor server side task. To have the CLI run in a non-blocking mode like the Web UI the --async flag may be passed to the CLI.		Every API call to a QuantaStor system, irrespective of protocol or client (WUI, CLI, REST API, SOAP, etc) is authenticated and authorized on every time. QuantaStor is session-less but does have an authentication token system. Communication between QuantaStor systems uses the WSDL SOAP protocol and all API calls are auto-forwarded to the appropriate system within the grid to execute any given operation/task. QuantaStor systems perform resource locking to ensure that multiple tasks/operations can be queued and executed with the necessary resources become available. When using the QuantaStor CLI it will block and wait for a given operation to complete and then print the results of the QuantaStor server side task. To have the CLI run in a non-blocking mode like the Web UI the --async flag may be passed to the CLI.

Qadmin at 20:12, 21 March 2019

2019-03-21T20:12:26Z

← Older revision		Revision as of 20:12, 21 March 2019
Line 1:		Line 1:
	This section provides an overview of the terminology used in the QuantaStor storage model and how elements of the model relate.		This section provides an overview of the terminology used in the QuantaStor storage model and how elements of the model relate.

			== Storage System ==

			A QuantaStor server is a physical or virtual server with the QuantaStor operating system installed on it. You'll also see it referred to via other terms like "node", "QuantaStor box", or just "system" for short. A group of systems combined to form a grid is called a Storage Grid.

	== Storage Grid Technology ==		== Storage Grid Technology ==

	QuantaStor's built-in storage grid technology enables multiple QuantaStor servers to be combined together so that they can be managed as one. Grid formation is done by creating a Storage Grid on a first QuantaStor server and then adding additional QuantaStor servers to the grid in a batch or one at a time. Once a Storage Grid is formed a number of advanced features are enabled like Remote Replication, Clustering, and more. No additional software is required to manage a grid of systems as all management functions for all systems are linked. QuantaStor's grid technology maintains a distributed configuration database that spans all systems so that configuration changes made to any system are communicated to all systems within a few seconds.		QuantaStor's built-in storage grid technology enables multiple QuantaStor servers to be combined together so that they can be managed as one. Grid formation is done by creating a Storage Grid on a first QuantaStor server and then adding additional QuantaStor servers to the grid in a batch or one at a time. Once a Storage Grid is formed a number of advanced features are enabled like Remote Replication, Clustering, and more. No additional software is required to manage a grid of systems as all management functions for all systems are linked. QuantaStor's grid technology maintains a distributed configuration database that spans all systems so that configuration changes made to any system are communicated to all systems within a few seconds. QuantaStor internally maintains this information in a Sqlite database and uses an encrypted SOAP (XML based) protocol for communication between nodes to communicate configuration changes throughout a given Storage Grid. Each Storage Grid has what is referred to as a Primary Node or a Master Node. This is the system that is responsible for communicating update events to Secondary nodes within a given Storage Grid. Any system within a Storage Grid may be elected as a Primary/Master node by using the 'Set Grid Master' dialog in the Web UI or by updating this via the QS CLI or QS REST API. Automatic election of a new Primary/Master node is accomplished by adding a floating "gridIP" interface to the grid.

			=== System Communication ===

			Every API call to a QuantaStor system, irrespective of protocol or client (WUI, CLI, REST API, SOAP, etc) is authenticated and authorized on every time. QuantaStor is session-less but does have an authentication token system. Communication between QuantaStor systems uses the WSDL SOAP protocol and all API calls are auto-forwarded to the appropriate system within the grid to execute any given operation/task. QuantaStor systems perform resource locking to ensure that multiple tasks/operations can be queued and executed with the necessary resources become available. When using the QuantaStor CLI it will block and wait for a given operation to complete and then print the results of the QuantaStor server side task. To have the CLI run in a non-blocking mode like the Web UI the --async flag may be passed to the CLI.

	[[File:grid.png\|600px]]		[[File:grid.png\|600px]]

	== Storage ~~System~~ ==		== Storage Pools ==

	A QuantaStor ~~server is referred to as~~ a Storage ~~System but you'll also see~~ it ~~referred~~ to ~~via other terms like "node" in the context of~~ Storage ~~Grids or clusters~~. ~~A group of systems combined~~ to ~~form~~ a ~~grid is called~~ a ~~Storage Grid~~.		Storage Pools are formed out of one or more SSD or HDD disk devices. QuantaStor supports both scale-up style Storage Pools (ZFS based) and scale-out style Storage Pools (Ceph based). Once a Storage Pool is created, storage may be provisioned from it. Each pool type allows for provisioning of specific types of storage. ZFS based Storage Pools allow one to provision both file storage (Network Shares), and block storage (Storage Volumes). Ceph based Storage Pools are each specific to a storage type (File, Block or Object), but these scale-out Storage Pools can share a common group of disks within the scale-out cluster.

	[[File:pool.png:300px]]		[[File:pool.png\|300px]]

Qadmin: /* Storage Grid Technology */

2019-03-21T19:41:01Z

Storage Grid Technology

← Older revision		Revision as of 19:41, 21 March 2019
Line 5:		Line 5:
	QuantaStor's built-in storage grid technology enables multiple QuantaStor servers to be combined together so that they can be managed as one. Grid formation is done by creating a Storage Grid on a first QuantaStor server and then adding additional QuantaStor servers to the grid in a batch or one at a time. Once a Storage Grid is formed a number of advanced features are enabled like Remote Replication, Clustering, and more. No additional software is required to manage a grid of systems as all management functions for all systems are linked. QuantaStor's grid technology maintains a distributed configuration database that spans all systems so that configuration changes made to any system are communicated to all systems within a few seconds.		QuantaStor's built-in storage grid technology enables multiple QuantaStor servers to be combined together so that they can be managed as one. Grid formation is done by creating a Storage Grid on a first QuantaStor server and then adding additional QuantaStor servers to the grid in a batch or one at a time. Once a Storage Grid is formed a number of advanced features are enabled like Remote Replication, Clustering, and more. No additional software is required to manage a grid of systems as all management functions for all systems are linked. QuantaStor's grid technology maintains a distributed configuration database that spans all systems so that configuration changes made to any system are communicated to all systems within a few seconds.

	[[File:grid.png:600px]]		[[File:grid.png\|600px]]


	== Storage System ==		== Storage System ==

Qadmin at 19:40, 21 March 2019

2019-03-21T19:40:25Z

← Older revision		Revision as of 19:40, 21 March 2019
Line 4:		Line 4:

	QuantaStor's built-in storage grid technology enables multiple QuantaStor servers to be combined together so that they can be managed as one. Grid formation is done by creating a Storage Grid on a first QuantaStor server and then adding additional QuantaStor servers to the grid in a batch or one at a time. Once a Storage Grid is formed a number of advanced features are enabled like Remote Replication, Clustering, and more. No additional software is required to manage a grid of systems as all management functions for all systems are linked. QuantaStor's grid technology maintains a distributed configuration database that spans all systems so that configuration changes made to any system are communicated to all systems within a few seconds.		QuantaStor's built-in storage grid technology enables multiple QuantaStor servers to be combined together so that they can be managed as one. Grid formation is done by creating a Storage Grid on a first QuantaStor server and then adding additional QuantaStor servers to the grid in a batch or one at a time. Once a Storage Grid is formed a number of advanced features are enabled like Remote Replication, Clustering, and more. No additional software is required to manage a grid of systems as all management functions for all systems are linked. QuantaStor's grid technology maintains a distributed configuration database that spans all systems so that configuration changes made to any system are communicated to all systems within a few seconds.

			[[File:grid.png:600px]]


	== Storage System ==		== Storage System ==
Line 9:		Line 12:
	A QuantaStor server is referred to as a Storage System but you'll also see it referred to via other terms like "node" in the context of Storage Grids or clusters. A group of systems combined to form a grid is called a Storage Grid.		A QuantaStor server is referred to as a Storage System but you'll also see it referred to via other terms like "node" in the context of Storage Grids or clusters. A group of systems combined to form a grid is called a Storage Grid.

	[[File:pool.png]]		[[File:pool.png:300px]]

	~~[[File~~:~~grid.png~~]]

Qadmin at 19:39, 21 March 2019

2019-03-21T19:39:46Z

← Older revision		Revision as of 19:39, 21 March 2019
Line 1:		Line 1:
	~~The QuantaStor Software Defined Storage platform implements a layered architecture for IO which leverages many storage components you would typically find in~~ an ~~enterprise Linux server deployment. The following diagram illustrates~~ the ~~key layers~~ in ~~some detail to give you a better understanding~~ of ~~how~~ the ~~system is designed~~.		This section provides an overview of the terminology used in the QuantaStor storage model and how elements of the model relate.

	~~[[File:pool.png]]~~		== Storage Grid Technology ==

	~~[[File:~~grid.~~png]]~~		QuantaStor's built-in storage grid technology enables multiple QuantaStor servers to be combined together so that they can be managed as one. Grid formation is done by creating a Storage Grid on a first QuantaStor server and then adding additional QuantaStor servers to the grid in a batch or one at a time. Once a Storage Grid is formed a number of advanced features are enabled like Remote Replication, Clustering, and more. No additional software is required to manage a grid of systems as all management functions for all systems are linked. QuantaStor's grid technology maintains a distributed configuration database that spans all systems so that configuration changes made to any system are communicated to all systems within a few seconds.

	== ~~Filesystem Support~~ ==		== Storage System ==

	QuantaStor ~~storage pools can be created on top of two filesystem types, ZFS and XFS, where ZFS~~ is ~~the default. Almost all production deployments~~ as ~~of mid-2014 are using ZFS which is~~ a ~~fast mature enterprise filesystem that is used broadly across the Fortune 500. BTRFS was introduced as an experimental storage pool type into QuantaStor v1 in 2010~~ but to ~~date it has not matured enough for production deployments. ZFS~~ in ~~QuantaStor is based on~~ the ~~[http://zfsonlinux~~.~~org/ ZFS on Linux (ZoL)] port~~ of ~~the enterprise filesystem which OSNEXUS~~ is a ~~contributor to~~.		A QuantaStor server is referred to as a Storage System but you'll also see it referred to via other terms like "node" in the context of Storage Grids or clusters. A group of systems combined to form a grid is called a Storage Grid.

	~~== Hardware RAID Support ==~~		[[File:pool.png]]

	[[File:~~qs_hwarch~~.png]]		[[File:grid.png]]

	Hardware RAID controllers generally far outperform software RAID5/RAID6 for write performance when combined with NVRAM cache in the controller because of the high performance of the hardware RAID's resilient write back cache. Most modern RAID controllers have at least 1GB of DDR3 protected cache so for most workloads it this provides a significant performance boost for sequential workloads like media playback, archive, and other large scale big data deployements. QuantaStor has deep integration with all major HBAs and RAID controllers (LSI, Adaptec, HP, etc) so that you can pick software RAID, hardware RAID or a hybrid of the two to match the storage appliance architecture with the needs of you applications. QuantaStor's HBA and RAID hardware integration modules allow you to configure, maintain, and monitor the health of your system from top to bottom without having to resort to BIOS configuration or command line configuration utilities.

	To configure the hardware controller layer of your system simply choose the 'Hardware Controllers & Enclosures' section of the web management interface. Internally QuantaStor integrates with the hardware controllers by calling APIs or communicating with the hardware via drivers or utilities to monitor and manage the hardware.

	~~== Performance Tuning ==~~

	QuantaStor allocates and configures the various layers of a storage pool to optimize for performance. In some cases tuning for one type of application may not be as ideal for another so our default configuration is tuned to deliver good performance for a broad set of workloads. In some cases though it may be beneficial to select one of our preset IO profiles for your storage pool to match your application type. IO profiles determine factors such as read-ahead and stripe size and can be changed via the 'Modify Storage Pool..' dialog in the web management interface. Custom IO profiles can also be developed by adding new entries to /etc/qs_io_profiles.conf and restarting the QuantaStor core service (service quantastor restart).

Qadmin at 19:28, 21 March 2019

2019-03-21T19:28:01Z

← Older revision		Revision as of 19:28, 21 March 2019
Line 1:		Line 1:
	The QuantaStor Software Defined Storage platform implements a layered architecture for IO which leverages many storage components you would typically find in an enterprise Linux server deployment. The following diagram illustrates the key layers in some detail to give you a better understanding of how the system is designed.		The QuantaStor Software Defined Storage platform implements a layered architecture for IO which leverages many storage components you would typically find in an enterprise Linux server deployment. The following diagram illustrates the key layers in some detail to give you a better understanding of how the system is designed.

	[[File:~~qs_ioarch~~.png]]		[[File:pool.png]]

			[[File:grid.png]]

	== Filesystem Support ==		== Filesystem Support ==

Qadmin: /* Filesystem Support */

2015-03-23T22:45:45Z

Filesystem Support

← Older revision		Revision as of 22:45, 23 March 2015
Line 5:		Line 5:
	== Filesystem Support ==		== Filesystem Support ==

	QuantaStor storage pools can be created on top of two filesystem types, ZFS and XFS, where ZFS is the default.		QuantaStor storage pools can be created on top of two filesystem types, ZFS and XFS, where ZFS is the default. Almost all production deployments as of mid-2014 are using ZFS which is a fast mature enterprise filesystem that is used broadly across the Fortune 500. BTRFS was introduced as an experimental storage pool type into QuantaStor v1 in 2010 but to date it has not matured enough for production deployments. ZFS in QuantaStor is based on the [http://zfsonlinux.org/ ZFS on Linux (ZoL)] port of the enterprise filesystem which OSNEXUS is a contributor to.
	Almost all production deployments as of mid-2014 are using ZFS which is a fast mature enterprise filesystem that is used broadly across the Fortune 500. BTRFS was introduced as an experimental storage pool type into QuantaStor v1 in 2010 but to date it has not matured enough for production deployments. ZFS in QuantaStor is based on the [http://zfsonlinux.org/ ZFS on Linux (ZoL)] port of the enterprise filesystem which OSNEXUS is a contributor to.

	== Hardware RAID Support ==		== Hardware RAID Support ==

Qadmin: /* Hardware RAID Support */

2015-03-23T22:36:44Z

Hardware RAID Support

← Older revision		Revision as of 22:36, 23 March 2015
Line 12:		Line 12:
	[[File:qs_hwarch.png]]		[[File:qs_hwarch.png]]

	Hardware RAID controllers generally far outperform software ~~RAID~~ for write performance when combined with ~~a battery backup unit~~ because the RAID ~~controller can safely complete a write once it has been stored in the battery backed~~ write cache. Most modern RAID controllers have at least 1GB of DDR3 protected cache so for most workloads it provides a significant performance boost. QuantaStor has deep integration with all major RAID controllers (LSI, Adaptec, HP, etc) so that it can configure and monitor the health of your system from top to bottom without having to resort to BIOS configuration or command line configuration utilities. To configure the hardware ~~RAID~~ layer of your system simply choose the 'Hardware Controllers & Enclosures' section of the web management interface. Internally QuantaStor integrates with the hardware controllers by calling APIs or communicating with the hardware via ~~CLI~~ utilities to monitor and manage the hardware. You can use RAID controllers which we do not have an integration module for but the various hardware specific objects shown above in blue will not be discovered and displayed in the web management interface.		Hardware RAID controllers generally far outperform software RAID5/RAID6 for write performance when combined with NVRAM cache in the controller because of the high performance of the hardware RAID's resilient write back cache. Most modern RAID controllers have at least 1GB of DDR3 protected cache so for most workloads it this provides a significant performance boost for sequential workloads like media playback, archive, and other large scale big data deployements. QuantaStor has deep integration with all major HBAs and RAID controllers (LSI, Adaptec, HP, etc) so that you can pick software RAID, hardware RAID or a hybrid of the two to match the storage appliance architecture with the needs of you applications. QuantaStor's HBA and RAID hardware integration modules allow you to configure, maintain, and monitor the health of your system from top to bottom without having to resort to BIOS configuration or command line configuration utilities.

			To configure the hardware controller layer of your system simply choose the 'Hardware Controllers & Enclosures' section of the web management interface. Internally QuantaStor integrates with the hardware controllers by calling APIs or communicating with the hardware via drivers or utilities to monitor and manage the hardware.

	== Performance Tuning ==		== Performance Tuning ==

	QuantaStor allocates and configures the various layers of a storage pool to optimize for performance. In some cases tuning for one type of application may not be as ideal for another so our default configuration is tuned to deliver good performance for a broad set of workloads. In some cases though it may be beneficial to select one of our preset IO profiles for your storage pool to match your application type. IO profiles determine factors such as read-ahead and stripe size and can be changed via the 'Modify Storage Pool..' dialog in the web management interface. Custom IO profiles can also be developed by adding new entries to /etc/qs_io_profiles.conf and restarting the QuantaStor core service (service quantastor restart).		QuantaStor allocates and configures the various layers of a storage pool to optimize for performance. In some cases tuning for one type of application may not be as ideal for another so our default configuration is tuned to deliver good performance for a broad set of workloads. In some cases though it may be beneficial to select one of our preset IO profiles for your storage pool to match your application type. IO profiles determine factors such as read-ahead and stripe size and can be changed via the 'Modify Storage Pool..' dialog in the web management interface. Custom IO profiles can also be developed by adding new entries to /etc/qs_io_profiles.conf and restarting the QuantaStor core service (service quantastor restart).

Qadmin: /* Filesystem Support */

2015-03-23T22:31:27Z

Filesystem Support

← Older revision		Revision as of 22:31, 23 March 2015
Line 5:		Line 5:
	== Filesystem Support ==		== Filesystem Support ==

	QuantaStor storage pools can be created on top of ~~three different~~ filesystem types, XFS, ~~BTRFS, and~~ ZFS.		QuantaStor storage pools can be created on top of two filesystem types, ZFS and XFS, where ZFS is the default.
	Almost all production deployments as of mid-~~2013~~ are using ~~XFS~~ which is a fast mature filesystem that is used broadly in the ~~enterprise~~. BTRFS was introduced into QuantaStor in 2010 but ~~as only matured recently but it's adoption is increasing due~~ to it~~'s advanced feature set which includes snapshots and compression~~. ZFS in QuantaStor is based on the [http://zfsonlinux.org/ ZFS on Linux (ZoL)] port of the enterprise filesystem ~~and will be introduced into QuantaStor v3.6 in June/2013. ZFS~~ is ~~similar~~ to ~~BTRFS but is more mature than BTRFS and has some advanced features (like deduplication) which BTRFS currently lacks~~.		Almost all production deployments as of mid-2014 are using ZFS which is a fast mature enterprise filesystem that is used broadly across the Fortune 500. BTRFS was introduced as an experimental storage pool type into QuantaStor v1 in 2010 but to date it has not matured enough for production deployments. ZFS in QuantaStor is based on the [http://zfsonlinux.org/ ZFS on Linux (ZoL)] port of the enterprise filesystem which OSNEXUS is a contributor to.

	== Hardware RAID Support ==		== Hardware RAID Support ==