|
|
| (927 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | The QuantaStor Administrators Guide is intended for all administrators and cloud users who plan to manage their storage using QuantaStor Manager as well as for those just looking to get a deeper understanding of how the QuantaStor Storage System Platform (SSP) works. | + | [[Category:admin_guide]] |
| − | == Storage System Management Operations ==
| + | The QuantaStor Administrator Guide is intended for all IT administrators working to setup or maintain a QuantaStor system or grid of systems as well as for those just looking to get a deeper understanding of how the QuantaStor software defined storage platform works. |
| | | | |
| − | When you initially connect to QuantaStor manager you'll see a toolbar (aka ribbon bar) at the top of the screen and a stack view / tree view on the left hand side of the screen. By selecting different areas of the tree view (Storage Volumes, Hosts, etc) the ribbon view . tool bar will change accordingly to indicate the operations available for that section. The following diagram shows these two sections:
| + | == Administrator Guide Topic Links == |
| | | | |
| − | [[File:qs_scrn_tree.png|Main Tree View & Ribbon-bar / Toolbar]] | + | [[Web UI Definition]] |
| | | | |
| − | Note also that you can right-click on the title-bar for each stack item in the tree view to access a pop-up menu, and you can right-click on any object anywhere in the UI to access a context sensitive pop-up menu for that item.
| + | [[Navigation for Dialog Access]] |
| | | | |
| − | === License Management ===
| + | [[Navigation using Right Click for Dialog Access]] |
| | | | |
| − | === Recovery Manager ===
| + | [[Storage System]] |
| | | | |
| − | === Upgrade Manager ===
| + | [[Grid Configuration]] |
| | | | |
| − | === System Checklist ===
| + | [[License Management]] |
| | | | |
| − | === System Hostname & DNS management === | + | === Hardware Configuration === |
| | | | |
| − | == Physical Disk Management ==
| + | [[Network Port Configuration]] |
| | | | |
| − | === Identifying physical disks in an enclosure ===
| + | [[Physical Disk/Device Management]] |
| | | | |
| − | === Scanning for physical disks ===
| + | [[Hardware Controller & Enclosure Management]] |
| − | When new disks have been added to the system you can scan for new disks using the command. To access this command from the QuantaStor Manager web interface simply right-click where it says 'Physical Disks' and then choose scan for disks. Disks are typically named sdb, sdc, sdd, sde, sdf and so on. The 'sd' part just indicates SCSI disk and the letter uniquely identifies the disk within the system. If you've added a new disk or created a new Hardware RAID Unit you'll typically see the new disk arrive and show up automatically but the rescan operation can explicitly re-execute the disk discovery process.
| + | |
| | | | |
| − | == Hardware Controller & Enclosure Integration ==
| + | [[Multipath Configuration]] |
| − | QuantaStor has custom integration modules 'plug-ins' for a number of major RAID controller cards which monitor the health and status of your hardware RAID units, disks, enclosures, and controllers. When a disk failure occurs within a hardware RAID group, QuantaStor detects this and sends you an email through the QuantaStor alert management system. Note that QuantaStor also has software RAID support for RAID levels 1,5,6 & 10 so you do not need a hardware RAID card but hardware RAID can boost performance and offer you additional RAID configuration options. Also, you can use any RAID controller that works with Ubuntu Server, but QuantaStor will only detect alerts and discover the configuration details of those controllers for which there is a QuantaStor hardware controller plug-in.
| + | |
| − | Note that the plug-in discovery logic is triggered every couple of minutes so in some cases you will find that there is a small delay before the information in the web interface is updated.
| + | |
| | | | |
| − | As of QuantaStor v2.x there is hardware plug-in support for the following controllers:
| + | === Storage Provisioning === |
| − | * LSI 3ware 9750
| + | |
| − | * LSI 3ware 9690SA
| + | |
| − | * LSI MegaRAID / DELL PERC
| + | |
| − | ** LSI MegaRAID 9240, 9260, 9261, 9265, 9280, 9285
| + | |
| − | * Adaptec 5xxx & 6xxx Series
| + | |
| − | * HP SmartArray P400 / others
| + | |
| − | * Fusion IO
| + | |
| | | | |
| − | More RAID controller support is planned for 2012 including:
| + | [[Storage Pool Management]] |
| − | * Adaptec 6xxx series
| + | |
| − | * Areca
| + | |
| | | | |
| − | === Adaptec RAID integration ===
| + | [[Storage Volume Management]] |
| − | Adaptec controller integration requires the arcconf utility to be installed and located at /opt/osnexus/quantastor/raid-tools and there is a script in that same directory called adaptec-arcconf-install.sh which you can run to install the CLI. Once installed the Adaptec controller and associated disks and units will show up in the web interface within a minute. QuantaStor also has integrated management for Adaptec MaxCache SSD caching.
| + | |
| | | | |
| − | === Fusion IO integration ===
| + | [[Network Share Management]] |
| − | The Fusion IO integration requires that the following packages are installed:
| + | |
| − | *fio-util_2.2.0.82-1.0_amd64.deb
| + | |
| − | *iomemory-vsl-2.6.35-22-server_2.2.0.82-1.0_amd64.deb
| + | |
| | | | |
| − | Once installed the Fusion IO control and logic devices will automatically show up in the Hardware Controller & Enclosure view within QuantaStor Manager.
| + | [[Cloud Containers/NAS Gateway]] |
| | | | |
| − | === LSI 3ware 9750 & 9690SA integration === | + | === Security, Alerting & Upgrades === |
| | | | |
| − | LSI does an excellent job keeping their 3ware Linux drivers current and integrated with new revisions of the Linux kernel so generally there is no need to do any driver installation as part of configuring QuantaStor for use with your LSI 3ware card. The QuantaStor plug-in for LSI 3ware cards utilizes the tw_cli command line tool and there is a script located under /opt/osnexus/quantastor/raid-tools which will automate its installation. Here's how to do that:
| + | [[Call-home/Alert Management]] |
| − | <pre>
| + | |
| − | cd /opt/osnexus/quantastor/raid-tools
| + | |
| − | sudo lsi3warecli-install.sh
| + | |
| − | </pre>
| + | |
| | | | |
| − | After the tw_cli tool is installed you should verify that it is working properly by running this command:
| + | [[Security Configuration]] |
| − | <pre>
| + | |
| − | sudo /opt/osnexus/quantastor/raid-tools/tw_cli show
| + | |
| − | </pre>
| + | |
| − | If you see your controller listed then it is working properly.
| + | |
| | | | |
| − | If you're concerned about the driver version for your 3ware card, note that the driver is called 3w_sas so you can run this command at the console to see which driver version is running:
| + | [[Upgrade Manager]] |
| − | <pre>
| + | |
| − | sudo modinfo 3w_sas
| + | |
| − | </pre>
| + | |
| | | | |
| − | As of version 1.5.1 QuantaStor supports create/delete/identify hardware RAID units, rescan controller, disk remove/identify, and some other commands all within the QuantaStor manager web interface. This makes it easier to setup and manage your storage system without having to utilize the 3ware BIOS and tw_cli CLI directly.
| + | === Snapshots & Replication === |
| | | | |
| − | Note that if you arbitrarily remove a disk that was being utilized by a 3ware RAID unit, you cannot simply plug it back into the storage system and use it again. 3ware writes configuration data on the disk in what's called a Disk Control Block (DCB) and this needs to be scrubbed before you can use the disk again as a hot spare or within another unit. There is a great article written [http://www.finnie.org/2010/06/07/howto-delete-a-3ware-dcb/ here] on how to scrub the DCB on a disk so that you can use it again with your LSI 3ware controller. Formatting the disk in another system will also suffice. You can then add it back into the old system and designate it as a spare, and if you have a unit that is degraded it will automatically adopt the spare and begin rebuilding the unit back to a fully fault tolerant status. Of course if you pulled the disk because it was faulty you'll want to dispose of it properly and or return it back to the manufacturer for a warranty replacement.
| + | [[Snapshot Schedules]] |
| | | | |
| − | === LSI MegaRAID / DELL PERC integration ===
| + | [[Backup Policies]] |
| | | | |
| − | MegaRAID 92xx series and the DELL PERC H800 controller have been integrated with QuantaStor as of v1.5.2 and newer. To enable the hardware controller integration logic you'll first need to run a script at the console, and then you'll also want to make sure you have the latest firmware. Other MegaRAID controllers will work with QuantaStor but are not yet on our HCL and may not integrate properly with QuantaStor.
| + | [[Remote-replication (DR)]] |
| − | To get started, first login to your QuantaStor system at the console. You'll need to make sure that your system is network connected with internet access as it will be downloading some necessary files and packages. Next, run the following two commands to install:
| + | |
| − | <pre>
| + | |
| − | cd /opt/osnexus/quantastor/raid-tools
| + | |
| − | sudo lsimegaraid-install.sh
| + | |
| − | </pre>
| + | |
| − | That's all there is to it. It will take a couple of minutes for the QuantaStor service to detect that the MegaRAID CLI is now installed but then you'll see the hardware configuration show up automatically in the web interface. The other thing is that this script will have upgraded the megaraid_sas driver included with QuantaStor. As such you must restart the system using the "Restart Storage System" option in the QuantaStor web management interface.
| + | |
| | | | |
| − | Also, new firmware is required to use the larger 3TB drives so it is recommended that you visit the Dell or LSI web site and download the latest firmware for you RAID controller. Here's an example of how to upgrade your MegaRAID (or DELL PERC) firmware using the MegaCli64 CLI which you'll find located under /opt/MegaRAID/MegaCli/MegaCli64 after running the install script.
| + | === Cluster Configuration === |
| | | | |
| − | <pre>
| + | [[HA Cluster Setup (JBODs)]] |
| − | root@quantastor:/opt/MegaRAID/MegaCli# ./MegaCli64 -AdpFwFlash -f FW1046E.rom -a0
| + | |
| | | | |
| − | Adapter 0: PERC H800 Adapter
| + | [[HA Cluster Setup (external SAN)]] |
| − | Vendor ID: 0x1000, Device ID: 0x0079
| + | |
| | | | |
| − | FW version on the controller: 2.0.03-0772
| + | [[Scale-out_Block_Setup_(ceph)|Scale-out Block Setup (ceph)]] |
| − | FW version of the image file: 2.100.03-1046
| + | |
| − | Download Completed.
| + | |
| − | Flashing image to adapter...
| + | |
| − | Adapter 0: Flash Completed.
| + | |
| | | | |
| − | Exit Code: 0x00
| + | [[Scale-out Object Setup (ceph)|Scale-out Object Setup (ceph)]] |
| − | </pre>
| + | |
| | | | |
| − | As of QuantaStor v2.5 the MegaRAID integration now includes management of LSI CacheCade 2.0.
| + | [[Scale-out File Setup (ceph)|Scale-out File Setup (ceph)]] |
| | | | |
| − | === HP SmartArray RAID integration === | + | === Optimization === |
| − | Like the LSI 3ware integration, the integration with the HP SmartArray series of HP RAID controllers is also handled through their CLI interface, the HP Array Configuration Utility (ACU) CLI, or hpacucli for short. An installation script is available under /opt/osnexus/quantastor/raid-tools called hpacucli-install.sh which will automate the download and installation of the HP ACU CLI. Once installed the HP hardware RAID configuration information will show up in QuantaStor automatically within a couple of minutes.
| + | |
| − | Here's how to install the HP ACU CLI to activate the plug-in:
| + | |
| − | <pre>
| + | |
| − | cd /opt/osnexus/quantastor/raid-tools
| + | |
| − | sudo hpacucli-install.sh
| + | |
| − | </pre>
| + | |
| − | HP does not distribute the hpacucli in Ubuntu/Debian Linux package format so the installation of the cli requires a few downloads and a couple of additional linux packages to be installed. All of this is automated by the script shown above (hpacucli-install.sh) but note that it will take a few minutes.
| + | |
| | | | |
| − | == Managing Storage Pools ==
| + | [[Performance Tuning]] |
| | | | |
| − | Storage pools combine or aggregate one or more physical disks (SATA, SAS, or SSD) into a single pool of storage from which storage volumes (iSCSI targets) can be created. Storage pools can be created using any of the following RAID types including RAID0, RAID1, RAID5, RAID6, or RAID10. Choosing the optimal RAID type depends on your the I/O access patters of your target application, number of disks you have, and the amount of fault-tolerance you require. (Note: Fault tolerance is just a way of saying how many disks can fail within a storage pool or (aka RAID group before you lose data.) As a general guideline we recommend using RAID10 for all virtualization solutions and databases. RAID10 performs very well with sequential IO and random IO but is a bit more expensive since 1/2 the storage is used for fault tolerance. For archival storage or other similar workloads RAID6 and RAID5 are good choices. If you decide to use RAID6/5 with virtualization or other workloads that can produce a fair amount of random IO, we strongly recommend that you use a RAID controller with a batter backup unit/write back cache so that the RAID write penalty can be minimized.
| + | [[Performance Monitoring]] |
| | | | |
| − | === RAID Levels === | + | === System Internals === |
| − | RAID1 & RAID5 allow you have one disk fail without it interrupting disk IO. When a disk fails you can remove it and you should add a spare disk to the 'degraded' storage pool as soon as possible to in order to restore it to a fault-tolerant status. You can also assign spare disks to storage pools ahead of time so that the recovery happens automatically. RAID6 allows for up to two disk to fail and will keep running whereas RAID10 can allow for one disk failure per mirror pair. Finally, RAID0 is not fault tolerant at all but it is your only choice if you have only one disk and it can be useful in some scenarios where fault-tolerance is not required. Here's a breakdown of the various RAID types and their pros & cons.
| + | |
| | | | |
| − | * '''RAID0''' layout is also called 'striping' and it writes data across all the disk drives in the storage pool in a round robin fashion. This has the effect of greatly boosting performance. The drawback of RAID0 is that it is not fault tolerant, meaning that if a single disk in the storage pool fails then all of your data in the storage pool is lost. As such RAID0 is not recommended except in special cases where the potential for data loss is non-issue.
| + | [[QuantaStor systemd Services]] |
| − | * '''RAID1''' is also called 'mirroring' because it achieves fault tolerance by writing the same data to two disk drives so that you always have two copies of the data. If one drive fails, the other has a complete copy and the storage pool continues to run. RAID1 and it's variant RAID10 are ideal for databases and other applications which do a lot of small write I/O operations.
| + | |
| − | * '''RAID5''' achieves fault tolerance via what's called a parity calculation where one of the drives contains an XOR calculation of the bits on the other drives. For example, if you have 4 disk drives and you create a RAID5 storage pool, 3 of the disks will store data, and the last disk will contain parity information. This parity information on the 4th drive can be used to recover from any data disk failure. In the event that the parity drive fails, it can be replaced and reconstructed using the data disks. RAID5 (and RAID6) are especially well suited for audio/video streaming, archival, and other applications which do a heavy sequential write I/O operations (such as reading/writing large files) and are not as well suited for database applications which do heavy amounts of small random write I/O operations or with large file-systems containing lots of small files with a heavy write load.
| + | |
| − | * '''RAID6''' improves upon RAID5 in that it can handle two drive failures but it requires that you have two disk drives dedicated to parity information. For example, if you have a RAID6 storage pool comprised of 5 disks then 3 disks will contain data, and 2 disks will contain parity information. In this example, if the disks are all 1TB disks then you will have 3TB of usable disk space for the creation of volumes. So there's some sacrifice of usable storage space to gain the additional fault tolerance. If you have the disks, we always recommend using RAID6 over RAID5. This is because all hard drives eventually fail and when one fails in a RAID5 storage pool your data is left vulnerable until a spare disk is utilized to recover your storage pool back to a fault tolerant status. With RAID6 your storage pool is still fault tolerant after the first drive failure. (Note: Fault-tolerant storage pools (RAID1,5,6,10) that have suffered a single disk drive failure are called '''degraded''' because they're still operational but they require a spare disk to recover back to a fully fault-tolerant status.)
| + | |
| − | * '''RAID10''' is similar to RAID1 in that it utilizes mirroring, but RAID10 also does striping over the mirrors. This gives you the fault tolerance of RAID1 combined with the performance of RAID10. The drawback is that half the disks are used for fault-tolerance so if you have 8 1TB disks utilized to make a RAID10 storage pool, you will have 4TB of usable space for creation of volumes. RAID10 will perform very well with both small random IO operations as well as sequential operations and it is highly fault tolerant as multiple disks can fail as long as they're not from the same mirror-pairing. If you have the disks and you have a mission critical application we '''highly''' recommend that you choose the RAID10 layout for your storage pool.
| + | |
| | | | |
| − | In many cases it is useful to create more than one storage pool so that you have both basic low cost fault-tolerant storage available from perhaps a RAID5 storage pool, as well as a highly fault-tolerant RAID10 or RAID6 storage pool available for mission critical applications.
| + | [[QuantaStor Configuration Files]] |
| | | | |
| − | Once you have created a storage pool it will take some time to 'rebuild'. Once the 'rebuild' process has reached 1% you will see the storage pool appear in QuantaStor Manager and you can begin to create new storage volumes.
| + | [[QuantaStor Shell Utilities]] |
| − | <blockquote>
| + | |
| − | WARNING: Although you can begin using the pool at 1% rebuild completion, your storage pool is not fault-tolerant until the rebuild process has completed.
| + | |
| − | </blockquote>
| + | |
| − | | + | |
| − | == Target Port Configuration ==
| + | |
| − | Target ports are simply the network ports (NICs) through which your client hosts (initiators) access your storage volumes (aka targets). The terms 'target' and 'initiator' are SCSI terms that are synonymous with 'server' and 'client' respectively. QuantaStor supports both statically assigned IP addresses as well as dynamically assigned (DHCP) addresses. If you selected automatic network configuration when you initially installed QuantaStor then you'll have one port setup with DHCP and the others are likely offline.
| + | |
| − | We recommend that you always use static IP addresses unless you have your DHCP server setup to specifically assign an IP address to your NICs as identified by MAC address. If you don't set the target ports up with static IP addresses you risk the IP address changing and losing access to your storage when the dynamically assigned address expires.
| + | |
| − | To modify the configuration of a target port first select the tree section named "Storage System" under the "Storage Management" tab on the left hand side of the screen. After that, select the "Target Ports" tab in the center of the screen to see the list of target ports that were discovered. To modify the configuration of one of the ports, simply right-click on it and choose "Modify Target Port" from the pop-up menu. Alternatively you can press the "Modify" button in the tool bar at the top of the screen in the "Target Ports" section.
| + | |
| − | Once the "Modify Target Port" dialog appears you can select the target port type for the selected port (static), enter the IP address for the port, subnet mask, and gateway for the port. You can also set the MTU to 9000 for jumbo packet support, but we recommend that you get your network configuration up and running with standard 1500 byte frames as jumbo packet support requires that you custom configure your host side NICs and network switch with 9K frames as well.
| + | |
| − | | + | |
| − | === NIC Bonding / Trunking ===
| + | |
| − | | + | |
| − | QuantaStor supports NIC bonding, also called trunking, which allows you to combine multiple NICs together to improve performance and reliability. If combine two or more ports together into a virtual port you'll need to make sure that all the bonded ports are connected to the same network switch. There are very few exceptions to this rule. For example, if you have two networks and 4 ports (p1, p2, p3, p4) you'll want to create two separate virtual ports each bonding two NIC ports (p1, p2 / p3, p4) together and each pair connected to a separate network (p1, p2 -> network A / p3, p4 -> network B). This type of configuration is highly recommended as you have both improved bandwidth and have no single point of failure in the network or in the storage system. Of course you'll need your host to have at least 2 NIC ports and they'll each need to connect to the separate networks. For very simple configurations you can just connect everything to one switch but again, the more redundancy you can work into your SAN the better.
| + | |
| − | | + | |
| − | By default, QuantaStor v2 uses Linux bonding mode-0, a round-robin policy. This mode provides load balancing and fault tolerance by transmitting packets in sequential order from the first available interface through the last. QuantaStor will also support LACP 802.3ad Dynamic Link aggregation. Currently this requires changing Linux configuration files.
| + | |
| − | * [[Changing Network Bonding Mode | Enable LACP Port Bonding]]
| + | |
| − | | + | |
| − | === 10GbE NIC support ===
| + | |
| − | | + | |
| − | QuantaStor works with all the major 10GbE cards from Chelsio, Intel and others. We recommend the Chelsio N320E cards and you can use NIC bonding in conjunction with 10GbE to further increase bandwidth. If you are using 10GbE we recommend that you designate your slower 1GbE ports as iSCSI disabled so that they are only used for management traffic. | + | |
| − | | + | |
| − | == Remote-Replication Configuration ==
| + | |
| − | | + | |
| − | Remote replication allows you to copy a volume or network share from one QuantaStor storage system to another and is a great tool for migrating volumes and network shares between systems and for using a remote system as a DR site.
| + | |
| − | Remote replication is done asynchronously which means that changes to volumes and network shares on the original/source system are not kept in lock step with the copy on the remote storage system. Rather, the changes from the source system are replicated periodically to the target system, typically every hour or perhaps nightly using a replication schedule.
| + | |
| − | Once a given set of the volumes and/or network shares have been replicated from one system to another the subsequent periodic replication operations send only the changes and all information sent over the network is compressed to minimize network bandwidth and encrypted for security.
| + | |
| − | | + | |
| − | === Creating a Storage System Link ===
| + | |
| − | | + | |
| − | The first step in setting up remote replication between two systems is to create a Storage System Link between the two. This is accomplished through the QuantaStor Manager web interface by selecting the 'Remote Replication' tab, and then pressing the 'Create Storage System Link' button in the tool bar to bring up the the dialog. To create a storage system link you must provide the IP address of the remote system and the admin username and password for that remote system. You must also indicate the local IP address that the remote system will utilize for communication between the remote and local system. If both systems are on the same network then you can simply select one of the IP addresses from one of the local ports but if the remote system is in the cloud or remote location then most likely you will need to specify the external IP address for your QuantaStor system. Note that the two systems communicate over ports 22 and 5151 so you will need to open these ports in your firewall in order for the QuantaStor systems to link up properly.
| + | |
| − | | + | |
| − | === Creating a Remote Replica ===
| + | |
| − | | + | |
| − | Once you have a Storage System Link created between two systems you can now replicate volumes and network shares in either direction. Simply login to the system that you want to replicate volumes from, right-click on the volume to be replicated, then choose 'Create Remote Replica'. Creating a remote replica is much like creating a local clone only the data is being copied over to a storage pool in a remote storage system. As such, when you create a remote-replica you must specify which storage system you want to replicate too (only systems which have established and online storage system links will be displayed) and which storage pool within that system should be utilized to hold the remote replica. If you have already replicated the specified volume to the remote storage system then you can re-sync the remote volume by choosing the remote-replica association in the web interface and choosing 'resync'. This can also be done via the 'Create Remote Replica' dialog and then choose the option to replicate to an existing target if available.
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | == Alert Settings ==
| + | |
| − | | + | |
| − | QuantaStor allows you to thin-provision storage and over provision storage but that feature comes with the associated risk of running out of disk space. As such, you will want to make sure that you configure and test your alert configuration settings in the Alert Manager. The Alert Manager allows you to specify at which thresholds you want to receive email regarding low disk space alerts for your storage pools. It also let's you specify the SMTP settings for routing email.
| + | |
| − | | + | |
| − | [[File:qs_scrn_alert_manager.png|Drop Session Dialog]]
| + | |
| − | | + | |
| − | == Managing Hosts ==
| + | |
| − | | + | |
| − | Hosts represent the client computers that you assign storage volumes to. In SCSI terminology the host computers ''initiate'' the communication with your storage volumes (target devices) and so they are called initiators. Each host entry can have one or more initiators associated with it and the reason for this is because an iSCSI initiator (Host) can be identified by IP address or IQN or both at the same time. We recommend using the IQN (iSCSI Qualified Name) at all times as you can have login problems when you try to identify a host by IP address especially when that host has multiple NICs and they're not all specified.
| + | |
| − | | + | |
| − | === Managing Host Groups ===
| + | |
| − | | + | |
| − | Sometimes you'll have multiple hosts that need to be assigned the same storage volume(s) such as with a VMware or a XenServer resource pool. In such cases we recommend making a Host Group object which indicates all of the hosts in your cluster/resource pool. With a host group you can assign the volume to the group once and save a lot of time. Also, when you add another host to the host group, it automatically gets access to all the volumes assigned to the group so it makes it very easy to add nodes to your cluster and manage storage from a group perspective rather than individual hosts which can be cumbersome especially for larger clusters.
| + | |
| − | | + | |
| − | == Managing Snapshot Schedules ==
| + | |
| − | | + | |
| − | Snapshot schedules enable you to have your storage volumes automatically protected on a regular schedule by creating snapshots of them. You can have more than one snapshot schedule, and each schedule can be associated with any storage volumes even those utilized in other snapshot schedules. In fact, this is something we recommend. For storage volumes containing critical data you should create a snapshot schedule that makes a snapshot of your volumes at least once a day and we recommend that you keep around 10-20 snapshots so that you have a week or two of snapshots that you can recover from. A second schedule that creates a single snapshot on the weekend of your critical volumes is also recommended. If you set that schedule to retain 10 snapshots that will give you over two months of historical snapshots from which you can recover data from.
| + | |
| − | | + | |
| − | === Near Continuous Data Protection (N-CDP) ===
| + | |
| − | | + | |
| − | What all this boils down to is a feature we in the storage industry refer to as continuous data protection or CDP. True CDP solutions allow you to recover to any prior point in time at the granularity of seconds. So if you wanted to see what a storage volume look like at 5:14am on Saturday you could look at a 'point-in-time' view of that storage volume at that exact moment. Storage systems that allow you to create large number of snapshots thereby giving you the ability to roll-back or recover from a snapshot that was created perhaps every hour are referred to as NCDP or "near continuous data protection" solutions, and that's exactly what QuantaStor is. This NCDP capability is achieved through snapshot schedules, so be sure to set one up to protect your critical volumes and network shares.
| + | |
| − | | + | |
| − | == Managing Sessions ==
| + | |
| − | | + | |
| − | The list of active iSCSI sessions with the storage system can be found by selecting the 'Storage System' tree-tab in QuantaStor Manager then selecting the 'Sessions' tab in the center view. Here's a screenshot of a list of active sessions as shown in QuantaStor Manager.
| + | |
| − | | + | |
| − | [[File:qs_session.png|640px|Session List]]
| + | |
| − | | + | |
| − | === Dropping Sessions ===
| + | |
| − | | + | |
| − | To drop an iSCSI session, just right-click on it and choose 'Drop Session' from the menu.
| + | |
| − | | + | |
| − | [[File:qs_session_drop.png|640px|Drop Session Dialog]]
| + | |
| − | | + | |
| − | Keep in mind that some initiators will automatically re-establish a new iSCSI session if one is dropped by the storage system. To prevent this, just unassign the storage volume from the host so that the host cannot re-login.
| + | |
| − | | + | |
| − | == Managing Storage Volumes ==
| + | |
| − | Each storage volume is a unique iSCSI device or 'LUN' as it is often referred to in the storage industry. The storage volume is essentially a disk drive on the network (the SAN) that you can assign to any host in your environment.
| + | |
| − | | + | |
| − | === Creating Storage Volumes ===
| + | |
| − | Storage volumes can be provisioned 'thick' or 'thin' which indicates whether the storage for the volume should be fully reserved (thick) or not (thin). As an example, a 100GB storage volume in a 1TB storage pool will only use 4KB of disk space in the pool when it is initially created leaving .99TB of disk space left over for use with other volumes and additional volume provisioning. In contrast, if you choose 'thick' provisioning by unchecking the 'thin provisioning' option then the entire 100GB will be pre-reserved. The advantage there is that that volume can never run out of disk space due to low storage availability in the pool but since it is reserved up front you will have 900GB free in your 1TB storage pool after it has been allocated so you can end up using up your available disk space fairly rapidly using thick provisioning.
| + | |
| − | | + | |
| − | === Deleting Storage Volumes ===
| + | |
| − | | + | |
| − | There are two separate dialogs in QuantaStor manager for deleting storage volumes. If you press the the "Delete Volume(s)" button in the ribbon bar you will be presented with a dialog that will allow you to delete multiple volumes all at once and you can even search for volumes based on a partial name match. This can save a lot of time when you're trying to delete a multiple volumes. You can also right-click on a storage volume and choose 'Delete Volume' which will bring up a dialog which will allow you to delete just that volume.
| + | |
| − | If there are snapshots of the volume you are deleting they are not deleted rather, they are promoted. For example, if you have snapshots S1, S2 of volume A1 then the snapshots will become root/primary storage volumes after A1 is deleted. Once a storage volume is deleted all the data is gone so use extreme caution when deleting your storage volumes to make sure you're deleting the right volumes. Technically, storage volumes are internally stored as files on a ext4 or btrfs filesystem so it is possible that you could use a filesystem file recovery tool to recover a lost volume but in generally speaking you would need to hire a company that specializes in data-recovery to get this data back.
| + | |
| − | | + | |
| − | === Resizing Storage Volumes ===
| + | |
| − | | + | |
| − | === Creating Snapshots ===
| + | |
| − | | + | |
| − | QuantaStor snapshots are probably not like any snapshots you've used with any other storage vendor on the market. Some key features of QuantaStor volume snapshots include:
| + | |
| − | | + | |
| − | * massive scalability
| + | |
| − | ** create hundreds of snapshots in just seconds
| + | |
| − | * supports snapshots of snapshots
| + | |
| − | ** you can create snapshots of snapshots of snapshots, ad infinitum.
| + | |
| − | * snapshots are R/W by default, read-only snapshots are also supported
| + | |
| − | * snapshots perform extremely well even when large numbers exist
| + | |
| − | * snapshots can be converted into primary storage volumes instantly
| + | |
| − | * you can delete snapshots at any time and in any order
| + | |
| − | * snapshots are 'thin', that is they are a copy of the meta-data associated with the original volume and not a full copy of all the data blocks.
| + | |
| − | | + | |
| − | All of these advanced snapshot capabilities make QuantaStor ideally suited for virtual desktop solutions, off-host backup, and near continuous data protection (NCDP). If you're looking to get NCDP functionality, just create a 'snapshot schedule' and snapshots can be created for your storage volumes as frequently as every hour.
| + | |
| − | | + | |
| − | To create a snapshot or a batch of snapshots you'll want to select the storage volume that you which to snap, right-click on it and choose 'Snapshot Storage Volume' from the menu.
| + | |
| − | | + | |
| − | If you do not supply a name then QuantaStor will automatically choose a name for you by appending the suffix "_snap" to the end of the original's volume name. So if you have a storage volume named 'vol1' and you create a snapshot of it, you'll have a snapshot named 'vol1_snap000'. If you create many snapshots then the system will increment the number at the end so that each snapshot has a unique name.
| + | |
| − | | + | |
| − | === Creating Clones ===
| + | |
| − | | + | |
| − | Clones represent complete copies of the data blocks in the original storage volume, and a clone can be created in any storage pool in your storage system whereas a snapshot can only be created within the same storage pool as the original. You can create a clone at any time and while the source volume is in use because QuantaStor creates a temporary snapshot in the background to facilitate the clone process. The temporary snapshot is automatically deleted once the clone operation completes. Note also that you cannot use a cloned storage volume until the data copy completes. You can monitor the progress of the cloning by looking at the Task bar at the bottom of the QuantaStor Manager screen. In contrast to clones, snapshots are created near instantly and do not involve data movement so you can use them immediately.
| + | |
| − | | + | |
| − | === Restoring from Snapshots ===
| + | |
| − | | + | |
| − | If you've accidentally lost some data by inadvertently deleting files in one of your storage volumes, you can recover your data quickly and easily using the 'Restore Storage Volume' operation. To restore your original storage volume to a previous point in time, first select the original, the right-click on it and choose "Restore Storage Volume" from the pop-up menu. When the dialog appears you will be presented with all the snapshots of that original from which you can recover from. Just select the snapshot that you want to restore to and press ok. Note that you cannot have any active sessions to the original or the snapshot storage volume when you restore, if you do you'll get an error. This is to prevent the restore from taking place while the OS has the volume in use or mounted as this will lead to data corruption.
| + | |
| − | <pre>
| + | |
| − | WARNING: When you restore, the data in the original is replaced with the data in
| + | |
| − | the snapshot. As such, there's a possibility of loosing data as everything that
| + | |
| − | was written to the original since the time the snapshot was created will be lost.
| + | |
| − | Remember, you can always create a snapshot of the original before you restore it
| + | |
| − | to a previous point-in-time snapshot.
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | === Converting a Snapshot into a Primary ===
| + | |
| − | | + | |
| − | A primary volume is simply a storage volume that's not a snapshot of any other storage volume. With QuantaStor you can take any snapshot and make it a primary storage very easily. Just select the storage volume in QuantaStor Manager, then right-click and choose 'Modify Storage Volume' from the pop-up menu. Once you're in the dialog, just un-check the box marked "Is Snapshot?". If the snapshot has snapshots of it then those snapshots will be connected to the previous parent volume of the snapshot. This conversion of snapshot to primary does not involve data movement so it's near instantaneous. After the snapshot becomes a primary it will still have data blocks in common with the storage volume it was previously a snapshot of but that relationship is cleared from a management perspective.
| + | |
| − | | + | |
| − | == IO Tuning ==
| + | |
| − | QuantaStor has a number of tunable parameters in the /etc/quantastor.conf file that can be adjusted to better match the needs of your application. That said, we've spent a considerable amount of time tuning the system to efficiently support a broad set of application types so we do not recommend adjusting these settings unless you are a highly skilled Linux administrator.
| + | |
| − | The default contents of the /etc/quantastor.conf configuration file are as follows:
| + | |
| − | <pre>
| + | |
| − | [device]
| + | |
| − | nr_requests=2048
| + | |
| − | scheduler=deadline
| + | |
| − | read_ahead_kb=512
| + | |
| − | | + | |
| − | [mdadm]
| + | |
| − | chunk_size_kb=256
| + | |
| − | parity_layout=left-symmetric
| + | |
| − | | + | |
| − | [btrfs]
| + | |
| − | nodatasum=false
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | There are tunable settings for device parameters, md array chunk-size and parity configuration settings, as well as some settings for btrfs. These configuration settings are read from the configuration file dynamically each time one of the settings is needed so there's no need to restart the quantastor service. Simply edit the file and the changes will be applied to the next operation that utilizes them. For example, if you adjust the chunk_size_kb setting for mdadm then the next time a storage pool is created it will use the new chunk size. Other tunable settings like the device settings will automatically be applied within a minute or so of your changes because the system periodically checks the disk configuration and updates it to match the tunable settings.
| + | |
| − | Also, you can delete the quantastor.conf file and it will automatically use the defaults that you see listed above.
| + | |
| − | | + | |
| − | == Troubleshooting ==
| + | |
| − | | + | |
| − | | + | |
| − | === Resetting the admin password ===
| + | |
| − | | + | |
| − | If you forget the admin password you can reset it by logging into the system via the console or via SSH and then run these commands:
| + | |
| − | <pre>
| + | |
| − | sudo -i
| + | |
| − | cd /opt/osnexus/quantastor/bin
| + | |
| − | service quantastor stop
| + | |
| − | ./qs_service --reset-password=newpass
| + | |
| − | service quantastor start
| + | |
| − | </pre>
| + | |
| − | In the above example the new password for the system is set to 'newpass' but you can change that to anything of your choice.
| + | |
| − | | + | |
| − | === Storage pool creation fails at 16% ===
| + | |
| − | | + | |
| − | Many motherboards include onboard RAID support which in some cases can conflict with the software raid mechanism QuantaStor utilizes. There's an easy fix for this, simply remove the driver using these two commands after logging in via the console as 'qadmin':
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | sudo apt-get remove dmraid
| + | |
| − | sudo update-initramfs -u
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | Here are a couple of articles that go into the problem in more detail [http://www.righteoushack.net/?p=197 here] and [http://superuser.com/questions/102086/how-to-build-initrd-without-dmraid-driver-on-ubuntu-9-10 here].
| + | |
| − | | + | |
| − | The two commands noted above removes the dmraid driver that linux utilizes to communicates with the RAID chipset in your BIOS. Once removed the devices will no longer be locked down so the software RAID mechanism we utilize (mdadm) is then unable to use the disks.
| + | |
| − | | + | |
| − | == PagerDuty ==
| + | |
| − | | + | |
| − | PagerDuty is an alarm aggregation and dispatching service for system administrators and support teams. It collects alerts from your monitoring tools, gives you an overall view of all of your monitoring alarms, and alerts an on duty engineer if there's a problem.
| + | |
| − | | + | |
| − | Quantastor can be setup to trigger PagerDuty alerts when Quantastor encounters an alert that is of severity "Error", "Warning", or "Critical". Getting setup only requires a few simple steps (internet connection required).
| + | |
| − | | + | |
| − | After logging into your PagerDuty account click on the "Services" tab along the top.
| + | |
| − | | + | |
| − | From here click on the "Add New Service" button.
| + | |
| − | | + | |
| − | For the "Service Name" field I would recommend something that describes the box that is being monitored. Also make sure to select "Generic API System" under service type. After everything is set click "Add Service".
| + | |
| − | | + | |
| − | Everything on the PagerDuty side should now be setup. Copy the "Service API Key" for later use.
| + | |
| − | | + | |
| − | Open the web interface for the Quantastor system. Right click on the desired storage system, and select "Alert Manager".
| + | |
| − | | + | |
| − | In the text box titled "PagerDuty.com Service Key" paste the service key from before. Then click on "Apply".
| + | |
| − | | + | |
| − | To test if the system is working select generate test alert. Make sure to select a severity level of "Error", "Warning", or "Critical" and then click okay. If everything is setup correctly a test alert should now be generated and sent to PagerDuty.
| + | |
| − | | + | |
| − | Below is what the alert will look like in PagerDuty:
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | == Librato Metrics ==
| + | |
| − | | + | |
| − | test2
| + | |
The QuantaStor Administrator Guide is intended for all IT administrators working to setup or maintain a QuantaStor system or grid of systems as well as for those just looking to get a deeper understanding of how the QuantaStor software defined storage platform works.
