Working with Storage Pools
Storage pools are used to aggregate disk storage into a large pool of storage that can be conveniently allocated and shared by volumes. The Storage Pools tab is where you view and manage all the storage pools.
A storage pool is an aggregated set of storage comprised of one or more underlying storage devices. It is comprised of devices (object and block storage, or VMDKs) created during the Add Disk Device process, or imported. The storage on these devices is aggregated into a unified pool of storage that can be managed and deployed as a single pool. Each pool provides storage which is then allocated for use into volumes.
- 1 1. Storage Pool Grid
- 2 2. Creating a Storage Pool
- 3 3. Expanding a Pool
- 4 4. Importing a Pool
- 5 5. Deleting a Pool
- 6 6. Creating a Read Cache
- 7 7. Creating a Write Log
- 8 8. Adding an Automated Hot Spare
- 9 9. Refreshing Pool List
- 10 10. Using Navigation Pane
- 11 11. Viewing Overview Chart
- 12 12. Managing Pool Details
1. Storage Pool Grid
The Storage Pool Grid displays the list of storage pools in a tabular grid format. The volume table has the following fields.
Field | Description |
|---|---|
Storage Pool | It shows the name of the storage pool. |
Status | It shows the current status of the pool. Based on the status, it shows the following types of indicators:
|
% Used | It shows the percentage of available storage used. |
Free Space | It shows the amount of free space available for use in gigabytes. |
Total Space | It shows the total amount of space in the pool, in gigabytes. |
Dedup % | It shows the percentage of Deduplication |
2. Creating a Storage Pool
Before creating the Storage Pool, you will need to have created several EBS volumes for Amazon EC2 based SoftNAS instance and several VHDs for VMware based SoftNAS VM. These EBS volumes or VHDs provide the underlying storage for SoftNAS storage pools. Whenever a volume or VHD is added, it begins as a raw disk which means that the disk has no partitions.
Before you assign disk devices to a storage pool, you must partition the disks.
OR
The Storage Pools panel will be displayed with the list of all the existing storage pools that are already allocated.
The Add Storage Pool dialog will be displayed. A standard pool is used by our patented original SNAP HA™ methodology will be implemented, replicating your block storage across two nodes, with minute by minute updates to ensure parity.
Enter the name for the storage pool that you wish to create in the Pool Name text entry box.
Some example storage pool naming schemes might include:
Generic naming: naspool1, naspool2, ...
Disk-type naming: SAS1, SAS2, SATA1, SATA2
Use-case naming: OS1, OS2, Exchange1, SQLData1, UserData1, Geology, Accounting, IT, R&D, QA, Corp01, etc.
Select the redundancy level from the RAID Level drop down list.
If you are using hardware RAID at the disk controller level and have a single data disk presented to SoftNAS for your storage pool, then you may not need software RAID - in such case, select No RAID/JBOD, as the RAID is implemented at a lower level and have no need for software RAID.
Select the disks for which you wish to allocate to this storage pool.
Each of the devices show the Disk Availability status as Available for Use. This implies that these disks are already partitioned. New disk devices must be partitioned before use.
In the Choose Pool Options step, check the box in the Forced Creation field if you wish to overwrite any older pools on the disks that you have selected.
If any of the disk devices you choose have been used as a part of another storage pool in the past (e.g., one that was deleted), you must use the Forced Creation option to overwrite the previous data in order to use the disk in a different pool (a precaution to prevent accidental data loss).
Sync Mode is an important decision, directly affecting either performance or data integrity. Buurst's ZFS based solution provides a great deal of protection to ensure that your data is fully protected, but in a fail-over situation, default settings can potentially result in uncached write bursts not being committed to the target volumes. Sync Mode is one way to prevent this from occurring. Depending on your requirements, choose the required Sync Mode:
standard:
This is the default option. For use cases where performance and data integrity are of equal importance, this is the best option. Synchronous file system transactions (fsync, O_DSYNC, O_SYNC, etc) are written out (to the intent log) and then secondly all devices written are flushed to ensure the data is stable (not cached by device controllers).
always:
For the ultra-cautious, every file system transaction is written and flushed to stable storage by a system call return. This obviously has a big performance penalty. However, if data loss of any kind is unacceptable for your use case, this should be your choice.
disabled:
Synchronous requests are disabled. File system transactions only commit to stable storage on the next DMU transaction group commit which can be many seconds. This option gives the highest performance. However, it is very dangerous as ZFS is ignoring the synchronous transaction demands of applications such as databases or NFS. Setting sync=disabled on the currently active root or /var file system may result in out-of-spec behavior, application data loss and increased vulnerability to replay attacks. This option does NOT affect ZFS on-disk consistency. Administrators should only use this when these risks are understood.
Another way to safeguard against data loss without compromising performance is to create a write log, or ZIL. Buurst strongly recommends this option for improved performance and data integrity assurance. For in-depth instructions on how to configure a ZIL/write log, see Configuring Read Cache and Write Log. Creating a write log is also covered briefly in a section below.
The new storage pool is created and is ready for use.
You can expand an existing storage pool by adding additional RAID arrays to the pool.
You cannot add devices to an existing RAID array - you must add a new array to create a larger storage aggregate.
Buurst best practice when expanding a pool is to always use disks of the same type as the original disks used to create the pool. Using a mix of different disk types with different performance characteristics can cause performance discrepancies for the pool.
To do so, simply follow the steps given below:
The additional storage will be added to the selected pool.