Terms & Definitions
- 1 Terms & Definitions
- 1.1 Storage System
- 1.2 Storage Pool
- 1.3 Storage Volume
- 1.4 Storage Volume Group
- 1.5 Snapshot Schedules
- 1.6 Host
- 1.7 Host Group
- 1.8 Network Share
- 1.9 Storage Cloud
- 1.10 Storage Quota
- 1.11 Storage System Link
- 1.12 Remote Replica Association
- 1.13 Roles
- 1.14 Permissions
- 1.15 Users
- 1.16 User Groups
- 1.17 Target Port
- 1.18 Sessions
- 1.19 CHAP Authentication
- 1.20 Alerts
- 1.21 Events
- 1.22 Tasks
Terms & Definitions
The following series of definitions are here to lay the ground work and context for the rest of the document. Here we define all the various objects and elements that can be managed via the QuantaStor Manager web interface or via the QuantaStor Remote Management CLI (available for Windows & Linux).
The storage system is the object that represents a QuantaStor server be it a physical bare-metal installed or a VM. Each storage system is comprised of physical disks, fans, enclosures, power supplies and other physical elements of the system as well as all the logical elements including the storage pools, volumes, and network shares associated with the system.
The storage pool is an aggregation of one or more physical disks into a larger entity. Each storage pool has a single RAID type associated with it, and all storage volumes that are created within that storage pool inherit RAID type. For example, if a given storage pool of type RAID1 (mirroring) is made up to two 1TB disks, then there is 1TB of usable storage available to create storage volumes (LUNs) with.
Storage Volumes represent a block device which is presented to the Host as a FC or iSCSI LUN. Each Storage Volume has a unique name and a unique target number and a unique IQN associated with it. Storage Volumes are "thin-provisioned" by default so they do not use up any space within a Storage Pool until the device has been written to.
Storage Volume Group
Often times hosts and virtual machines will be comprised of more than one storage volume. Sometimes one storage volume is dedicated as a boot disk and another as a swap disk. In other cases there are multiple disks utilized to separate out the elements of a database application (index, data, log) into separate storage volumes for improved performance. Whatever the reason, it can become difficult to manage you storage system without a way to group these storage volumes together so that they can be operated on as a single unit. That's what Storage Volume Groups provide. They're simple containers for collecting together an arbitrary set of storage volumes so that they can be cloned, snapshot, or even deleted as a group.
Snapshot schedules are a powerful tool for automatically generating recovery points (snapshots), on a schedule so that you don't have to think about it. The snapshot schedule consists of a list of storage volumes and/or network shares to be snapshot, and a list of days of the week and hours of the day at which the snapshots are to be taken. A 'max snapshots' parameter sets the point at which the oldest snapshot created by the schedule should be cleaned up (default: 10).
A host represents a server, workstation, laptop, or virtual machine that has a software or hardware iSCSI initiator by which it can access storage volumes (iSCSI targets) exposed by the storage system. Hosts are identified by one or more initiator IQNs and IP addresses. We recommend that you identify your hosts by IQN as that has the most flexibility since IP addresses can frequently change, especially if a host is using DHCP to acquire it's IP address.
A host group is an arbitrary collection of hosts that have been grouped together typically because they form a cluster or pool of hosts designated for some purpose. Sometimes they're grouped together by location, but more ofter Host Groups are used to group together hosts that have been formed into a cluster such as a Microsoft Fail-over Cluster / MSCS. In other cases as with VMWare or XenServer multiple hosts can be combined together to form "resource pools" in which the virtual machines can live migrate from one host to another. In all such cases, each host in the group will typically needs access to all the same storage volumes in order to facilitate fail-over and live migration. Host groups make it easy to assign storage to multiple hosts all at once, and you can add and remove hosts from a host group to quickly assign storage to a cluster node or resource pool. This was traditionally a long tedious process with many legacy storage systems as most systems would require that the administrator assign each volume to each host individually. If you have 10 hosts and 100 volumes, that amounts to 1000 storage assignment operations and potentially days of work for a storage administrator. With host groups we make that a snap.. using the same example but with 1 host group representing the 10 hosts and 100 volumes, the storage assignment to the group of 10 hosts can be done in a single operation through QuantaStor manager in less than a minute.
A network share is an NFSv3 network share. Each network share is a separate root directory in a storage pool in which you can store files. If you are using an 'Advanced' storage pool, then you can create snapshots and snapshot schedules for your network share whereas with 'Standard' pools you cannot.
Storage Clouds are essentially virtual storage systems. One of the key unique offerings that QuantaStor brings to storage management, storage clouds make it so that you can give groups of users private storage clouds so that the storage system effectively support multi-tenancy.
Storage quotas go hand-in-hand with storage clouds. Quotas define a set amount of storage that can be provisioned from a Storage Pool from a specific Storage Cloud. More specifically, storage quotas allow you to define the amount of storage that can be thin-provisioned as well as the amount that can be utilized/reserved. The also allow the administrator to set the maximum number of volumes that can be created by a given cloud.
Storage System Link
Storage System Links represent a link between to separate storage systems for use with remote replication. Once a link is established you can replicate a storage volume from one system to another by right-clicking any storage volume and choosing "Create Remote Replica". From there you just need to select the target system and the target storage pool. Any given storage system can have multiple storage system links and the links are bi-directional so you can replicate in either direction.
Remote Replica Association
When you replicate a storage volume from one system to another, a remote replica association object is crated automatically to track the status of the replication operation. If the replication fails for any reason you can use the 'Resync' operation to restart the replication.
There are four (4) predefined roles that come with the initial storage system configuration which include:
- Administrators have full access to manage all aspects of the storage system. They can create new roles, users, storage pools, reconfigure target ports, everything.
- Cloud Administrator
- Cloud administrators are limited to managing just the resources contained within the storage cloud to which they are a member. This includes the storage volumes, snapshot schedules, and hosts within their cloud. Cloud administrators can only view the resources that are within the cloud to which they are a member, all other resources in the system are private and invisible to the cloud admin.
- Cloud User
- Cloud users can only view the resources within their cloud, just like the Cloud Administrator, but they have limited ability to manage storage volumes. More specifically, they can only snapshot, clone, and delete storage volumes they've access rights to. (By default when a user creates a storage volume or other resource they have access rights to modify that resource but the Administrator can add/remove rights afterward).
- System Monitor
- System monitors can only view the objects within the system. This role is useful for creating monitoring agents or for providing people in administrative roles a way of viewing the storage system without being able to change its configuration.
Besides the include roles outlined above, you can create as many custom roles as you like. Each role consists of a list of object action permissions coupled with a scope at which that action can be exercised. For example, there's a permission for "Storage Volume : view" which allows users to view storage volumes. If you add this permission to a role and assign it at a scope of 'system' then the user associated with that role can view all storage volumes in the system. If on the other hand the scope is set to 'user' then the user will only be able to view storage volumes that he/she created. This RBAC system with scoping is unique to QuantaStor & QuantaGrid and is a core technology behind our Storage Clouds.
Permissions are simply a combination of an object and an action. For example here are some of the permissions associated with the Storage Volume object:
- storage volume : view
- storage volume : create
- storage volume : delete
- storage volume : snapshot
- storage volume : clone
- storage volume : restore
- storage volume : assign
- storage volume : unassign
When permissions are assigned to a role there is another element that's added, and that's the permission scope. The permission scope defines at what level the user is allowed to exercise the granted permission. Permission scopes include 'none', 'user', 'cloud', 'system', and 'grid'.
Each user is given a unique user name and password so that they may login and share in managing the storage system, and each users is associated with a specific role. Some roles like the Cloud User and Cloud Administrator are only truly effective when the user is associated with a storage cloud. Once associated with a cloud, cloud users and admins can access, view, or modify resources within that cloud within the permission limits of their role. All other resources in the system are invisible.
Note: Today QuantaStor does not support external authentication mechanisms like Active Directory but that is planned for a future release.
Often times a given group of users will be associated with more than one storage cloud. The user group object represents an arbitrary collection of users and provides a simple way to keep track of groups of users thereby making it easier add large groups of users to/from storage clouds.
The target port represents an NIC or network interface card/port in your storage system. 1Ge ports are common in servers today and most servers typically have 2 x 1Ge ports. The term target port comes from SCSI terminology where the device to be accessed is called a 'target' and the entity accessing the target is called the 'initiator'. Hence the port in the storage system through which a target can be accessed is called a 'target port'. You can add as many target ports to your system as your storage system's PCI bus has room for. Some vendors like Intel sell dual and quad 1Ge port NICs, but if you find yourself needing larger numbers of ports to improve network throughput we suggest looking into adding 10Ge NICs to your QuataStor system.
The session object represents and active iSCSI session between one of your hosts (aka initiator), and a specific storage volume (iSCSI target) in the QuantatStor storage system. Often times there will be more than one session connected to the same target as this forms multiple IO paths giving you improved performance and fail-over capabilities in the event a path is disconnected. You can drop or disconnect a session from within QuantaStor Manager, but keep in mind that many iSCSI initiators will automatically re-establish a new session with the array automatically. To permanently remove access to a volume from a host you'll need to unassign the volume using the 'Assign/Unassign Host Access' option. This appears in the pop-up menu when you right-click on a volume in QuantaStor Manager. You can reassign access rights back to the host so that it can access the volume again at any time.
CHAP stands for Challenge-handshake Authentication Protocol and it provides you with a mechanism by which you can associated a username and a password with a specific iSCSI target / storage volume. CHAP usernames & passwords are completely separate from the username & password that you use with the QuantaStor Manager web GUI. Simply put, the CHAP username and password are just arbitrary values that you make up but they must be at least 12 characters in length. To use CHAP with a specific volume you will need to press the 'Advanced Settings' button in the 'Modify Storage Volume' dialog in QuantaStor Manager. Besides being able to set a storage volume specific CHAP username and password, QuantaStor allows you to set a default CHAP password for all the volumes in a storage cloud and additionally a default CHAP password for all storage volumes you own.
Alerts are simply messages from the system. Some alerts are just informational such as when the system first starts it sends out a message that the system startup completed successfully. Other alerts are warnings or errors indicating something serious has happened like a disk failure that needs to be addressed. Alerts are shown in QuantaStor Manager at the bottom of the screen.
The QuantaStor service generates an event for each change that is made to the system. It is via these events that the QuantaStor Manager web UI is able to keep itself state consistent with the service. You don't see events anywhere as objects within QuantaStor Manager but you can view them using the CLI which can be useful if you're scripting and need to get notified when the system configuration has changed in some way.
Every configuration change to the system is handled via a task. When you create a storage volume or do some other operation with the storage system, you'll notice a new task in the status bar at the bottom of the screen in QuantaStor Manager. Some long running tasks (like batch creation of 300 volumes) can be canceled while they're running. Just right-click the task in the task bar within QuantaStor Manager and choose cancel.