|
|
| (33 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| | | | |
| − | == SNMP Agent Configuration ==
| |
| − | QuantaStor v3.10.1 and newer comes with an SNMP agent so that you can remotely monitor your system via SNMP and get notified of system alerts via the SNMP trap mechanism.
| |
| − |
| |
| − | === SNMP MIB ===
| |
| − |
| |
| − | The full [http://www.osnexus.com/storage/snmpagent/QUANTASTOR-SYS-STATS.mib SNMP MIB for QuantaStor] can be found [http://www.osnexus.com/storage/snmpagent/QUANTASTOR-SYS-STATS.mib here].
| |
| − |
| |
| − | === qs-util SNMP Utility Commands ===
| |
| − |
| |
| − | The qs-util command line utility has a number of helper commands to make enabling SNMP and verifying the configuration easier. Here's a list of those commands, you can also run 'qs-util' at the console to see a full list of these commands. Note that you must run many of these commands as root so be sure to do a 'sudo -i' before running them.
| |
| − |
| |
| − | <pre>
| |
| − | SNMP Commands
| |
| − | qs-util snmpenable : Configures the SNMP agent to startup automatically at system startup.
| |
| − | qs-util snmpdisable : Configures the SNMP agent to not start automatically at system startup (default).
| |
| − | qs-util snmpactivate : Turns on the SNMP agent
| |
| − | qs-util snmprestart : Restarts the SNMP service and agent
| |
| − | qs-util snmpwalkall : Walks the entire SNMP mib
| |
| − | qs-util snmpwalkvolumes : Walks the volumes via the SNMP mib
| |
| − | qs-util snmpwalkalerts : Walks the alerts via the SNMP mib
| |
| − | qs-util snmpmib : Displays the contents of the SNMP mib
| |
| − | </pre>
| |
| − |
| |
| − | === Enabling the SNMP Agent ===
| |
| − | By default the QuantaStor SNMP agent is turned off but you can enable it at the console with a couple of commands:
| |
| − |
| |
| − | <pre>
| |
| − | sudo qs-util snmpenable
| |
| − | sudo qs-util snmpactivate
| |
| − | </pre>
| |
| − |
| |
| − | The snmpenable command sets up the appliance so that the SNMP agent will start automatically when the appliance boots up. The snmpactivate command will startup the snmpd and qs_snmpagent services. You must also install the snmp package which contains the snmpwalk and snmpget utilities you can use for testing the agent.
| |
| − |
| |
| − | <pre>
| |
| − | sudo apt-get install snmp
| |
| − | </pre>
| |
| − |
| |
| − | === Configuring the SNMP Agent user account ===
| |
| − |
| |
| − | You must edit the /etc/snmp/snmpd.conf configuration file to contain the plain text username and password for the account that will be used for communication between the SNMP agent and the QuantaStor core services. We recommend creating a 'snmpuser' account with the 'System Monitor' role so that even if someone gets the plain text password for the SNMP agent they still cannot make configuration changes to the appliance.
| |
| − | If you are not logged into the web management interface you can create a new management user account at the command line like so:
| |
| − |
| |
| − | <pre>
| |
| − | qs user-add snmpuser snmppass "System Monitor" server=localhost,admin,password
| |
| − | </pre>
| |
| − |
| |
| − | In the /etc/snmp/snmpd.conf file you will see lines in there that look like this:
| |
| − |
| |
| − | <pre>
| |
| − | createUser snmpuser MD5 snmppass DES
| |
| − | group nmsGroup usm snmpuser
| |
| − | </pre>
| |
| − |
| |
| − | Edit 'nano /etc/snmp/snmpd.conf' those to match the new user account username and password you gave in the previous step. For example, replace 'snmpuser' with the username of the account you created via the QuantaStor manager web interface, and replace 'snmppass' with the password you gave to that account. When the SNMP agent starts up, it will use the credentials for the first createUser entry in the snmpd.conf file for all communication with the QuantaStor service. So even if you have multiple createUser entries in the snmpd.conf file like "admin" but the first createUser entry is "snmpuser" then "snmpuser" credentials are used for all the SNMP agent to qs_service communication.
| |
| − |
| |
| − | Now it is time to restart the SNMP daemon and agent like so:
| |
| − | <pre>
| |
| − | sudo qs-util snmprestart
| |
| − | </pre>
| |
| − |
| |
| − | === Testing the SNMP Agent ===
| |
| − |
| |
| − | Now that you have the SNMP agent enabled with an account associated with it, now it's time to test it to make sure it is working. To do this, use the qs-util commands for doing an SNMP walk, for example:
| |
| − |
| |
| − | <pre>
| |
| − | qs-util snmpwalkvolumes snmpuser snmppass
| |
| − | qs-util snmpwalkalerts snmpuser snmppass
| |
| − | qs-util snmpwalkall snmpuser snmppass
| |
| − | </pre>
| |
| − |
| |
| − | Alternatively you can run a snmpwalk like so:
| |
| − |
| |
| − | <pre>
| |
| − | snmpwalk -v 3 -u snmpuser -a MD5 -A snmppass -x DES -X "snmppass" -l authPriv localhost QUANTASTOR-SYS-STATS::storageVolume
| |
| − | </pre>
| |
| − |
| |
| − | Be sure to replace snmpuser and snmppass with the user account you setup and specified in the /etc/snmp/snmpd.conf configuration file. If you're not able to get any data from the snmpwalk commands, try running a simple qs command to verify that the credentials are correct for the account like so:
| |
| − | <pre>
| |
| − | qs alert-list server=localhost,snmpuser,snmppass
| |
| − | </pre>
| |
| − | If that doesn't work then either the quantastor service is not running (service quantastor start) or the user account username or password isn't correct.
| |
| − |
| |
| − | === Configuring SNMP Agent Trap Settings ===
| |
| − | The alerts within QuantaStor have a severity of error, warning or informational and via the /etc/qs_snmptrapd.conf configuration file you can turn off these categories of alerts to fit your needs. In general you should not ever ignore error messages but it may be handy to disable informational alerts in some cases. Here's the default contents of the /etc/qs_snmptrapd.conf file. Note that if you delete it, the SNMP agent will automatically re-create it for you with the defaults:
| |
| − |
| |
| − | <pre>
| |
| − | poll-interval=120
| |
| − | ignore-error-alerts=false
| |
| − | ignore-warn-alerts=false
| |
| − | ignore-info-alerts=false
| |
| − | </pre>
| |
| − |
| |
| − | If you make any changes to this file, be sure to restart the agent like so.
| |
| − | <pre>
| |
| − | service snmpagent restart
| |
| − | </pre>
| |
| − | Or you can restart both the agent and SNMP service like so:
| |
| − | <pre>
| |
| − | qs-util snmprestart
| |
| − | </pre>
| |
| − |
| |
| − | === Testing SNMP Trap Settings ===
| |
| − | By default the SNMP agent only pushes out traps every 120 seconds so you will have to wait awhile for the trap to be generated after you raise a test alert. QuantaStor only raises traps for Alert objects, so anything that you see in the Alert status bar in the web interface or see in 'qs alert-list' will be sent out as traps. Traps are only sent a single time and the agent keeps track of what alerts have been sent by writing the alert UUIDs to '/var/log/qs_snmpraisedtraps.dat'. If you delete that file then all the alerts will be raised again after the agent restarts. To generate a test alert which will be converted into an SNMP trap use this command:
| |
| − |
| |
| − | <pre>
| |
| − | qs alert-raise --message="snmp test message" --alert-severity=warning --server=localhost,admin,password
| |
| − | </pre>
| |
| − |
| |
| − | After you create the test alert you can then look in the log to see if it has been raised:
| |
| − |
| |
| − | <pre>
| |
| − | qs-showlog -snmp
| |
| − | </pre>
| |
| − |
| |
| − | An easier way to do that is to leave the log open with a 'tail -f /var/log/qs_snmpagent.log' then hit Ctrl-C to stop monitoring the log once you see the trap generated. By default the /etc/snmp/snmpd.conf file is configure to only raise traps to the local host. To raise traps outside of the local host you'll need to add additional lines to the snmpd.conf file like this:
| |
| − |
| |
| − | <pre>
| |
| − | trap2sink 127.0.0.1 public
| |
| − | trap2sink 192.168.10.123 public
| |
| − | trap2sink 10.10.50.134 public
| |
| − | </pre>
| |
| − |
| |
| − | You can also monitor traps using the snmptrapd utility like so:
| |
| − |
| |
| − | <pre>
| |
| − | snmptrapd -P -F "%02.2h:%02.2j TRAP%w.%q from %A %v %W\n"
| |
| − | </pre>
| |
| − |
| |
| − | == IO Tuning ==
| |
| − |
| |
| − | === ZFS Performance Tuning ===
| |
| − |
| |
| − | One of the most common tuning tasks that is done for ZFS is to set the size of the ARC cache. If your system has less than 10GB of RAM you should just use the default but if you have 32GB or more then it is a good idea to increase the size of the ARC cache to make maximum use of the available RAM for your storage appliance. Before you set the tuning parameters you should run 'top' to verify how much RAM you have in the system. Next, run this command to set the amount of RAM to some percentage of the available RAM. For example to set the ARC cache to use a maximum of 80% of the available RAM, and a minimum of 50% of the available RAM in the system, run these, then reboot:
| |
| − | <pre>
| |
| − | qs-util setzfsarcmax 80
| |
| − | qs-util setzfsarcmax 50
| |
| − | </pre>
| |
| − |
| |
| − | Example:
| |
| − | <pre>
| |
| − | sudo -i
| |
| − | qs-util setzfsarcmax 80
| |
| − | INFO: Updating max ARC cache size to 80% of total RAM 1994 MB in /etc/modprobe.d/zfs.conf to: 1672478720 bytes (1595 MB)
| |
| − | qs-util setzfsarcmin 50
| |
| − | INFO: Updating min ARC cache size to 50% of total RAM 1994 MB in /etc/modprobe.d/zfs.conf to: 1045430272 bytes (997 MB)
| |
| − | </pre>
| |
| − |
| |
| − |
| |
| − | To see how many cache hits you are getting you can monitor the ARC cache while the system is under load with the qs-iostat command:
| |
| − |
| |
| − | <pre>
| |
| − | qs-iostat -af
| |
| − |
| |
| − | ZFS Adaptive Replacement Cache (ARC) / read cache statistics
| |
| − |
| |
| − | Name Data
| |
| − | ---------------------------------------------
| |
| − | hits 1099360191
| |
| − | misses 65808011
| |
| − | c_min 67108864
| |
| − | c_max 1045925888
| |
| − | size 26101960
| |
| − | arc_meta_used 11552968
| |
| − | arc_meta_limit 261481472
| |
| − | arc_meta_max 28478856
| |
| − |
| |
| − | ZFS Intent Log (ZIL) / writeback cache statistics
| |
| − |
| |
| − | Name Data
| |
| − | ---------------------------------------------
| |
| − | zil_commit_count 25858
| |
| − | zil_commit_writer_count 25775
| |
| − | zil_itx_count 12945
| |
| − | </pre>
| |
| − |
| |
| − | === Pool Performance Profiles ===
| |
| − |
| |
| − | Read-ahead and request queue size adjustments can help tune your storage pool for certain workloads. You can also create new storage pool IO profiles by editing the /etc/qs_io_profiles.conf file. The default profile looks like this and you can duplicate it and edit it to customize it.
| |
| − |
| |
| − | <pre>
| |
| − | [default]
| |
| − | name=Default
| |
| − | description=Optimizes for general purpose server application workloads
| |
| − | nr_requests=2048
| |
| − | read_ahead_kb=256
| |
| − | fifo_batch=16
| |
| − | chunk_size_kb=128
| |
| − | scheduler=deadline
| |
| − | </pre>
| |
| − |
| |
| − | If you edit the profiles configuration file be sure to restart the management service with 'service quantastor restart' so that your new profile is discovered and is available in the web interface.
| |
| − |
| |
| − | === XFS Tuning Parameters ===
| |
| − |
| |
| − | 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
| |
| − | </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.
| |
| − |
| |
| − | == 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).
| |
| − |
| |
| − | === Adding a New Service in PagerDuty ===
| |
| − |
| |
| − | {|
| |
| − | |-
| |
| − | |
| |
| − | [[File:pagerDutySetup1.png|400px]]
| |
| − | |
| |
| − | After logging into your PagerDuty account click on the "Services" tab along the top.
| |
| − | From here click on the "Add New Service" button.
| |
| − |
| |
| − | This service is what all of the Quantastor alerts will be kept under. This will keep the alerts separate from the other programs that may be sending their alerts to PagerDuty.
| |
| − | |-
| |
| − | |
| |
| − | [[File:pagerDutySetup2.png|400px]]
| |
| − | |
| |
| − | For the "Service Name" field I would recommend something that describes the box or grid that is being monitored. Also make sure to select "Generic API System" under service type. Quantastor uses PagerDuty's API to post the alert to PagerDuty. After everything is set click "Add Service".
| |
| − | |-
| |
| − | |
| |
| − | [[File:pagerDutySetup3.png|400px]]
| |
| − | |
| |
| − | Everything on the PagerDuty side should now be setup. Copy the "Service API Key" and set it aside. This key is the input parameter to tell Quantastor where to post the alert.
| |
| − | |}
| |
| − |
| |
| − | === Adding PagerDuty to Quantastor ===
| |
| − |
| |
| − | {|
| |
| − | |-
| |
| − | |
| |
| − | [[File:pagerduty3.png|400px]]
| |
| − | |
| |
| − | Open the web interface for the Quantastor system. Right click on the storage system or grid, and select "Alert Manager".
| |
| − | |-
| |
| − | |
| |
| − | [[File:pagerduty2.png|400px]]
| |
| − | |
| |
| − | In the text box titled "PagerDuty.com Service Key" paste the service key from before. Then click on "Apply".
| |
| − | |-
| |
| − | |
| |
| − | [[File:pagerduty1.png|400px]]
| |
| − | |
| |
| − | 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.
| |
| − | |}
| |
| − |
| |
| − |
| |
| − | === Example Alerts ===
| |
| − |
| |
| − | When Quantastor sends an alert to PagerDuty it also sends a list of details to make solving the issue easier. These details include:
| |
| − | * The serial number of the system
| |
| − | * The startup time of the system
| |
| − | * The location
| |
| − | * The title of the alert
| |
| − | * The version of the Quantastor service
| |
| − | * The time at which the alert was sent
| |
| − | * The name of the system
| |
| − | * The id of the system
| |
| − | * The current firmware version
| |
| − | * The severity of the alert
| |
| − |
| |
| − |
| |
| − | {|
| |
| − | |-
| |
| − | |
| |
| − | [[File:pagerduty5.png|400px]]
| |
| − | |
| |
| − | [[File:pagerduty4.png|400px]]
| |
| − | |}
| |
| − |
| |
| − | == Librato Metrics ==
| |
| − |
| |
| − | Metrics takes away the headaches of traditional server based monitoring solutions that take time to set up, require investments in hardware and take effort to maintain. Metrics is delivered as a service so you don't have to worry about storage, reliability, redundancy, or scalability.
| |
| − |
| |
| − | === Setup for Librato Metrics ===
| |
| − |
| |
| − | {|
| |
| − | |-
| |
| − | |
| |
| − | [[File:MetricsAccount.png|700px]]
| |
| − | |
| |
| − | To post data to Librato Metrics you first must have a Librato Metrics account, which can be created through their website at https://metrics.librato.com. Next you will want to go to your account settings page. This is where you will find your username (email used to create the account) and your API token. This token will be used to post data. At this screen you can do other things such as change your password, or generate a new API token.
| |
| − | |-
| |
| − | |
| |
| − | [[File:ApiTokenSettings.png|700px]]
| |
| − | |
| |
| − | When you create the API token, make sure that it is set to "Full Access". This will allow us to create the different Instruments and Dashboards.
| |
| − | |-
| |
| − | |
| |
| − | [[File:MetricsSettings.png|700px]]
| |
| − | |
| |
| − | The next step is to configure Quantastor to post data to Librato Metrics using the same API token. Right click on the storage system you wish to post data, and select the Librato Metrics settings. In the dialog that appears set your username as the email you use to log into Librato Metrics. Paste the token from the Librato Metrics site into the token field. The post interval allows you to change how often Quantastor will send data to Librato Metrics. The default value is 60 seconds. Click "OK", and Quantastor should begin posting data.
| |
| − | |}
| |
| − |
| |
| − | === Viewing the Metrics ===
| |
| − |
| |
| − | To view the data you will first sign into your Librato Metrics account. After signing in click on the "Metrics" tab along the top. This will bring you to a list of all the metrics that have been posted to your account. Quantastor uses a naming convention of:
| |
| − | "<storage system/grid name> - <gauge name>"
| |
| − |
| |
| − | Quantastor creates the following gauges:
| |
| − |
| |
| − | {|
| |
| − | |- valign="top"
| |
| − | |
| |
| − | Metrics
| |
| − | |- valign="top"
| |
| − | |
| |
| − | * CPU Load Average
| |
| − | * Storage Pool Free Space
| |
| − | * Storage Pool Reads Per Sec
| |
| − | * Storage Pool Read kB Per Sec
| |
| − | * Storage Pool Writes Per Sec
| |
| − | * Storage Pool Write kB Per Sec
| |
| − | |- valign="top"
| |
| − | |
| |
| − | Instruments
| |
| − | |- valign="top"
| |
| − | |
| |
| − | * Storage Pool Read:Write
| |
| − | * Storage Pool Read:Write kBps
| |
| − | |}
| |
| − |
| |
| − | === Examples ===
| |
| − |
| |
| − | {|
| |
| − | |-
| |
| − | |
| |
| − | The picture on the left shows an example of a gauge Metric. This graph is the CPU load averages Metric. In the top right corner of the graph you can change the window of time that is currently being viewed.
| |
| − |
| |
| − | To the right of that is an example of an Instrument. An Instrument is a combination of of different Metrics. In this Instrument the Storage Pool Read kBps and Write kBps have been combined into one graph.
| |
| − | |-
| |
| − | |
| |
| − | [[File:metricsCPU.png|400px]] [[File:MetricsInstrument.png|400px]]
| |
| − | |}
| |
| − |
| |
| − | == Gladinet Enterprise Configuration (Secure Private Dropbox-like Solution) ==
| |
| − | Gladinet Enterprise is Dropbox-like software that allows you to store the data on a local SAN/NAS appliance like your QuantaStor SDS appliance. Gladinet provides remote secure access to folder and files for your users via an "M:" drive (default). Gladinet works much like Dropbox(tm) and adds advanced features like encryption on-the-wire and at rest, user management, and team folders. With all the data stored securely in your datacenter on your QuantaStor appliance(s) you can also ensure physical security of the data and deploy appliances for high security deployments to meet government standards like HIPAA compliance.
| |
| − |
| |
| − | === QuantaStor Configuration ===
| |
| − | Setup up QuantaStor to be used with Gladinet was very simple. Here are the steps to getting everything setup:
| |
| − |
| |
| − | #Create a user account to be used by Gladinet via the QuantaStor web management interface under the '''Users & Groups''' section. In the example below you can see that we created a user named 'gladinet' in QuantaStor and then we use that for configuring Gladinet.
| |
| − | #Create a ''network share'' in the ''storage pool'' you would like to use.
| |
| − | ##When you create the share, be sure to check the '''Enable CIFS/SMB Access''' option.
| |
| − | ##In the '''CIFS/SMB Advanced Settings''' section click on the 'None' setting for the ''gladinet'' or other user account that you created and set it as a '''Valid User'''.
| |
| − | #Finally, verify that you can access the ''network share'' using this user account from your Windows host before configuring it in Gladinet. After you have verified connectivity you can disconnect from the share in Windows.
| |
| − |
| |
| − | === Navigation to Attach Local Storage ===
| |
| − |
| |
| − | This part of the guide just covers the configuration of the storage so we've skipped a few of the other steps that come before this if you're installing Gladinet Enterprise from scratch. When you see this storage configuration screen, please follow these steps to complete the configuration of Gladinet for use with your QuantaStor appliance. If you've already installed Gladinet you'll need to navigate to the '''Attache Local Storage''' section. Note, the title '''Attach Local Storage''' shown in Gladinet is something of a misnomer as this section covers connecting to NAS storage and local filesystems.
| |
| − |
| |
| − | #Navigate to the Management Console
| |
| − | #Select Collaboration from the left hand menu
| |
| − | #Select the Storage Manager tab from the top menu
| |
| − | #Click on Attach Local Storage link in the upper right
| |
| − |
| |
| − | [[File:attachLocalStorage.png|1024px]]
| |
| − |
| |
| − | === Creating Storage Attachment ===
| |
| − | Once the '''Attach Local Storage''' dialog appears, follow these steps to connect to your QuantaStor ''network share''.
| |
| − | #The '''Root Folder Name''' is an arbitrary friendly name by which the storage share will be referred to in Gladinet.
| |
| − | #For the '''Local Storage Location''' provide the full SMB path to the CIFS share. In the example my '''network share''' was named '''test''' when we created it in the QuantaStor appliance so here we refer to it via the IP address of the QuantaStor appliance and the share name like so ''\\hostname\sharename''.
| |
| − | #For the '''Username''' enter the QuantaStor user that was given access to the share, in this example we created a user in the QuantaStor appliance named '''gladinet'''. Also make sure to put a '\' in front so it doesn't use your local Windows server's domain as part of the username.
| |
| − | #The password is the password to the QuantaStor user account; in this example it is the password to the '''gladinet''' user.
| |
| − | #Make sure to select both check-boxes and then click '''Create'''. QuantaStor is Linux based so Gladinet needs this information to properly interface with Samba based shares. Also, we want all access to the QuantaStor appliance to flow through the '''gladinet''' user account we're specifying here.
| |
| − |
| |
| − | [[File:attachDialog.png]]
| |
| − |
| |
| − | == Nagios Integration / Support ==
| |
| − |
| |
| − | This article has some good detail on setting up [http://askubuntu.com/questions/145518/how-do-i-install-nagios Nagios] but the installation requires running just a couple of commands:
| |
| − |
| |
| − | <pre>
| |
| − | sudo apt-get update
| |
| − | sudo apt-get install -y nagios3
| |
| − | </pre>
| |
| − |
| |
| − | When installing Nagios for use with QuantaStor note that you must adjust the default port number for apache to something other than port 80 which conflicts with the QuantaStor web management service. For more information on changing the apache port numbers, please see this [http://www.cyberciti.biz/faq/linux-apache2-change-default-port-ipbinding/ article] which has more detail. To change the port numbers edit '/etc/apache2/ports.conf' and modify the default port number of 80 something like to 8001 and 443 to 4431. Finally, restart apache with 'service apache2 restart'.
| |
| − |
| |
| − | After the port number has been changed you can then access Nagios via your web browser at the new port number like so:
| |
| − |
| |
| − | <pre>
| |
| − | http://your-appliance-ip-address:8001/nagios3/
| |
| − | </pre>
| |
| − |
| |
| − | == Zabbix Integration / Support ==
| |
| − |
| |
| − | To enable the Zabbix agent directly within your QuantaStor appliance you'll need to install the agent as per the Zabbix documentation on how to install into Ubuntu Server 12.04 (Precise) which can be found [https://www.zabbix.com/documentation/2.0/manual/installation/install_from_packages here].
| |
| − |
| |
| − | Here is a quick summary of the commands to run as detailed on the [https://www.zabbix.com/documentation/2.2/manual/installation/install#installing_zabbix_daemons Zabbix web site]:
| |
| − | <pre>
| |
| − | sudo -i
| |
| − | wget http://repo.zabbix.com/zabbix/2.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_2.0-1precise_all.deb
| |
| − | dpkg -i zabbix-release_2.0-1precise_all.deb
| |
| − | apt-get update
| |
| − | apt-get install zabbix-server-mysql zabbix-frontend-php
| |
| − | </pre>
| |
| − |
| |
| − | Note that Zabbix uses the apache2 web server for its web management interface. Apache uses port 80 by default which conflicts with the Tomcat service QuantaStor uses for its web management interface. As such, you must edit the /etc/apache2/ports.conf file to change the default port numbers. For example you can change 80 to 8001 and 443 to 4431, then restart the apache service with 'service apache2 restart'.
| |
| − | This will eliminate the port conflict with the QuantaStor manager web interface. For more information on changing the apache port numbers, please see this [http://www.cyberciti.biz/faq/linux-apache2-change-default-port-ipbinding/ article] which has more detail.
| |
| − |
| |
| − | After the port number has been changed you can then access Nagios via your web browser at the new port number like so:
| |
| − |
| |
| − | <pre>
| |
| − | http://your-appliance-ip-address:8001/zabbix/
| |
| − | </pre>
| |
| − |
| |
| − | == Security Configuration ==
| |
| − |
| |
| − | === Change Your Passwords ===
| |
| − |
| |
| − | One of the most important steps in the configuration of a new QuantaStor appliance is to just change the admin password for the appliance to something other than the default. You'll want to start by logging into the console using the 'qadmin' account and 'qadmin' password. Next type 'passwd' and change the password from 'qadmin' to something else. Next you'll want to login to the web management interface and change the 'admin' account password from 'password' to something else.
| |
| − |
| |
| − | === Port Lock-down via IP Tables configuration ===
| |
| − |
| |
| − | QuantaStor comes with non-encrypted port 80 / http access to the appliance enabled. For more secure installations it is recommended that port 80 and non-essential services are blocked. To disable port 80 access run this command:
| |
| − | <pre>
| |
| − | sudo qs-util disablehttp
| |
| − | </pre>
| |
| − | To re-enable port 80 access use:
| |
| − | <pre>
| |
| − | sudo qs-util enablehttp
| |
| − | </pre>
| |
| − | Note that the web management interface will still be accessible via https on port 443 after you disable http access.
| |
| − |
| |
| − | === Changing the SSL Key for QuantaStor Web Management Interface ===
| |
| − |
| |
| − | The SSL key provided with QuantaStor is a common self-signed SSL key that is pre-generated and included with all deployments. This is generally OK for most deployments on private networks but for increased security it is recommended to generate a new SSL keystore for the Apache Tomcat server used to serve the QuantaStor web management interface.
| |
| − |
| |
| − | ==== Keystore Password Selection ====
| |
| − | '''IMPORTANT NOTE''' You must set the password for the keystore to 'changeit' (without the quotes) as this is the default password that Tomcat uses to unlock the keystore. If you do not want to use the default password ('changeit') you can select a password of your choice but you will also need to manually edit the connector section of the /opt/osnexus/quantastor/tomcat/conf/server.xml file to add a line containing the keystore password (example: keystorePass="YOURPASSWORD"). Here's an example of what that will look like if you select the password "YOURPASSWORD".
| |
| − |
| |
| − | <pre>
| |
| − | <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
| |
| − | maxThreads="150" scheme="https" secure="true"
| |
| − | keystoreFile="/opt/osnexus/quantastor/tomcat/conf/keystore"
| |
| − | keystorePass="YOURPASSWORD"
| |
| − | clientAuth="false" sslProtocol="TLS" />
| |
| − | </pre>
| |
| − |
| |
| − | ==== New Keystore Generation ====
| |
| − |
| |
| − | To generate a new keystore you'll need to do the following steps.
| |
| − |
| |
| − | * Login to QuantaStor via the console or via SSH then generate a keystore using the keytool utility. It will prompt you to enter a bunch of data including name, company, location, etc. This will produce a new .keystore file in the current directory. Remember to use the default Tomcat 'changeit' password for the keystore unless you plan to edit the /opt/osnexus/quantastor/tomcat/conf/server.xml file to add your custom keystore password.
| |
| − | <pre>
| |
| − | keytool -genkey -alias tomcat -keyalg RSA -validity 365
| |
| − | </pre>
| |
| − | * Next, backup the original keystore file and then overwrite the original with your newly generated keystore file:
| |
| − | <pre>
| |
| − | cp /opt/osnexus/quantastor/tomcat/conf/keystore ./keystore.qs.conf
| |
| − | cp .keystore /opt/osnexus/quantastor/tomcat/conf/keystore
| |
| − | mv .keystore keystore.custom
| |
| − | </pre>
| |
| − | * Finally, restart tomcat services so that the new key is loaded.
| |
| − | <pre>
| |
| − | service tomcat restart
| |
| − | </pre>
| |
| − |
| |
| − | '''IMPORTANT NOTE''' If you are using Firefox as your browser, you must clear the browser history in order to clear the old cached key information. If you don't clear the history you'll see that the "Confirm Security Exception" button will be greyed out and you won't be able to login to your QuantaStor appliance via https. IE and Chrome do not have this issue.
| |
| − |
| |
| − | That's the whole process. Here's an example of what we enter into these fields as OSNEXUS Engineering, you'll want to put your own company name and other details here:
| |
| − |
| |
| − | <pre>
| |
| − | keytool -genkey -alias qs-tomcat -keyalg RSA -validity 365
| |
| − |
| |
| − | Enter keystore password:
| |
| − | Re-enter new password:
| |
| − | What is your first and last name?
| |
| − | [Unknown]: OSNEXUS
| |
| − | What is the name of your organizational unit?
| |
| − | [Unknown]: OSNEXUS Engineering
| |
| − | What is the name of your organization?
| |
| − | [Unknown]: OSNEXUS, Inc.
| |
| − | What is the name of your City or Locality?
| |
| − | [Unknown]: Bellevue
| |
| − | What is the name of your State or Province?
| |
| − | [Unknown]: Washington
| |
| − | What is the two-letter country code for this unit?
| |
| − | [Unknown]: US
| |
| − | Is CN=OSNEXUS, OU=OSNEXUS Engineering, O="OSNEXUS, Inc.", L=Bellevue, ST=Washington, C=US correct?
| |
| − | [no]: yes
| |
| − | </pre>
| |
| − |
| |
| − | == Internal SAS Device Multi-path Configuration ==
| |
| − | If your appliance is dual-path connected to a SAS JBOD or has an internal SAS expander with SAS disks you have the option of setting up multiple paths to the SAS devices for redundancy and in some cases improved performance. If you are not familiar with ZFS or using the Linux shell utilities we strongly recommend getting help with these steps from customer support.
| |
| − | === Multi-path Configuration with RAID Controllers ===
| |
| − | If you are using a RAID controller it will internally manage the multiple paths to the device automatically so there is no additional configuration required except to make sure that you have two cables connecting the controller to the SAS expander.
| |
| − | === Multi-path Configuration with HBAs ===
| |
| − | For appliances with SAS HBAs there are some additional steps required to setup the QuantaStor appliance for multipath access. Specifically, you must add entries to the /etc/multipath.conf file then restart the multipath services.
| |
| − | ==== Configuring the /etc/multipath.conf File ====
| |
| − | QuantaStor being Linux based uses the DMMP (Device Mapper Multi-Path) driver to manage multipathing. The multipath service can be restarted at any time at the command line using the command 'service multipath-tools restart'. Configuration of this service is managed via the configuration file located at /etc/multipath.conf which contains a set of rules indicating which devices (identified by Vendor / Model) should be managed by the multipath service and which should be ignored. The base configuration is setup so that no multipath management is done for SAS devices as this is the most common and simplest configuration mode. To enable multipath management you must add a section to the 'blacklist_exceptions' area of the file indicating the vendor and model of your SAS devices. The vendor model information for your SAS devices can be found using this command 'grep Vendor /proc/scsi/scsi'. To summarize:
| |
| − |
| |
| − | * grep Vendor /proc/scsi/scsi
| |
| − | ** Returns the vendor / model information for your SAS devices
| |
| − | * nano /etc/multipath.conf
| |
| − | ** Add a section to the blacklist_exceptions area for your SAS device, example (note the use of a wildcard '*') :
| |
| − |
| |
| − | device {
| |
| − | vendor "SEAGATE"
| |
| − | model "ST33000*"
| |
| − | }
| |
| − |
| |
| − | * service multipath-tools restart
| |
| − | ** Restarts the multipath service
| |
| − | * multipath -ll
| |
| − | ** Shows your devices with multiple paths to them
| |
| − |
| |
| − | === Pool Configuration ===
| |
| − |
| |
| − | Once all the above is done you'll need to go into the QuantaStor web management interface and choose 'Scan for Disks' to make the new device mapper paths appear. If you have already created a storage pool using standard paths rather than the /dev/mapper/mpath* paths then you'll need to run a zpool export/import operation to re-import the pool using the device mapper paths. To do this you will need to first do a 'Stop Storage Pool' then at the command line / console you'll need to run these commands:
| |
| − | * zpool export qs-POOLID
| |
| − | * zpool import -d /dev/mapper qs-POOLID
| |
| − | Note that you must replace qs-POOLID with the actual ID of the storage pool. You can also get this ID by running the 'zpool status' command.
| |
| − |
| |
| − | === Troubleshooting Multipath Configurations ===
| |
| − | * Only Single Path
| |
| − | ** If you only see one path to your device but the multipath driver is recognizing your device by displaying it in the output of 'multipath -ll' then you may have a cabling problem that is only providing the appliance with a single path to the device.
| |
| − | * No Paths Appear
| |
| − | ** If you don't see any devices in the output of 'multipath -ll' then there's probably something wrong with the device entry you added to the multipath.conf file into the blacklist_exceptions for your particular vendor/model of SAS device. Double check the output from 'cat /proc/scsi/scsi' to make sure that you have a correct rule added to the multipath.conf file.
| |
| − |
| |
| − | == Samba v4 / SMB3 Support ==
| |
| − |
| |
| − | QuantaStor versions 3.8.2 and newer have support for Samba v4 but an additional configuration step is required to upgrade your system from the default Samba server (Samba v3.6.3) to Samba v4. The command you need to run as root at the console/SSH is:
| |
| − |
| |
| − | <pre>
| |
| − | sudo samba4-install
| |
| − | </pre>
| |
| − |
| |
| − | It will ask you a few questions about your Active Directory configuration. Your answers might look similar to these (note you must use the default 'dc' mode, we do not yet support the other modes). Note also that you must provide a strong password for the domain 'Administrator password' or the script will fail and you'll need to retry using the procedure outlined below.
| |
| − |
| |
| − | <pre>
| |
| − | Realm [UNASSIGNED-DOMAIN]: osnexus.net
| |
| − | Domain [osnexus]:
| |
| − | Server Role (dc, member, standalone) [dc]:
| |
| − | DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]:
| |
| − | DNS forwarder IP address (write 'none' to disable forwarding) [192.168.0.1]: none
| |
| − | Administrator password:
| |
| − | Retype password:
| |
| − | </pre>
| |
| − |
| |
| − |
| |
| − | If you make a mistake and need to reconfigure the AD configuration settings just re-run the installer and it will prompt you again to enter the AD configuration settings. In some cases you will have to uninstall samba4, and cleanup the remnants of the failed install, then try again like so:
| |
| − |
| |
| − | <pre>
| |
| − | sudo -i
| |
| − | apt-get remove samba4
| |
| − | rm -rf /opt/samba4
| |
| − | samba4-install
| |
| − | </pre>
| |
| − |
| |
| − | As of 12/19/2013 we only support the default 'dc' mode and have not yet complete testing of the other modes, namely 'standalone' and 'member'. After the installation completes you can run this command to verify that the samba4 services are running:
| |
| − |
| |
| − | <pre>
| |
| − | service samba4 status
| |
| − | smbstatus -V
| |
| − | </pre>
| |
| − |
| |
| − | Starting in QuantaStor v3.9 the samba4-install script will turn off the enforcement of strong passwords but you can manually adjust it meet your company's security requirements by running this command. For strong passwords you'd want a minimum password length of 10 with the complexity requirement turned 'on' rather than 'off'. Note also that any existing user 'local' user accounts will need to have their passwords re-applied when you upgrade to Samba4, but that does not apply to AD accounts. If you have strong passwords enabled and a given user has a password that is not strong left over from a prior config then it will block the login when they attempt to access it from their Windows host.
| |
| − |
| |
| − | <pre>
| |
| − | samba-tool domain passwordsettings set --min-pwd-length=1 --complexity=off
| |
| − | </pre>
| |
| − |
| |
| − | If you have any questions please feel free to contact us at support (at) osnexus.com or via the Community Support Forum.
| |
| − |
| |
| − | == Custom Scripting / Application Extensions ==
| |
| − |
| |
| − | QuantaStor has script call-outs which you can use to extend the functionality of the appliance for integration with custom applications. For example, you may have an application which needs to be notified before or after a storage pool starts or stops. Or you may have need to call a script before an automated snapshot policy starts in order to quiesce applications.
| |
| − |
| |
| − | ==== Security Issues ====
| |
| − |
| |
| − | Scripts are called from the root user account so you must be careful to not allow anyone but the root user to have write access to create files under /var/opt/osnexus/custom. By default the scripts directory has permissions '755'. Your scripts should be configured with file permissions using the command 'chmod 755 scriptname.sh' to prevent non-root user accounts from modifying the scripts. Additionally, if you have sensitive information like a plain text password in your custom script be sure to set the permissions to 700 rather than 755 so only the root user account can read the script.
| |
| − |
| |
| − | ==== Timeouts ====
| |
| − |
| |
| − | Scripts must complete within 120 seconds; scripts taking longer are automatically terminated.
| |
| − |
| |
| − | === Where to install custom scripts ===
| |
| − |
| |
| − | Custom script call-outs are hard-wired to specific file names and must be placed in the custom scripts
| |
| − | directory '/var/opt/osnexus/custom' within your QuantaStor appliance. If you have a grid of
| |
| − | appliances you'll need to install your script onto all of the appliances.
| |
| − |
| |
| − | Custom Scripts Directory:
| |
| − | <pre>
| |
| − | /var/opt/osnexus/custom
| |
| − | </pre>
| |
| − |
| |
| − | === Storage System Custom Scripts ===
| |
| − |
| |
| − | Scripts related to the startup / shutdown of the appliance.
| |
| − |
| |
| − | ==== system-poststart.sh ====
| |
| − |
| |
| − | The system poststart script is only called one time when the system boots up. If the management services are
| |
| − | restarted it will check against the timestamp in /var/opt/osnexus/quantastor/qs_lastreboot an only call the
| |
| − | system-poststart.sh script if it has changed. If you want your poststart script to run every time the
| |
| − | management service is restarted you can just delete the qs_lastreboot file in your script.
| |
| − |
| |
| − | ==== system-prestop.sh ====
| |
| − |
| |
| − | Called when the user initiates a shutdown or a restart via the web management interface (or CLI). Note that
| |
| − | if the admin bypasses the normal shutdown procedure and restarts the appliance at the console
| |
| − | using 'reboot' or 'shutdown -P now' or similar command your script won't get called.
| |
| − |
| |
| − | === Storage Pool Custom Scripts ===
| |
| − |
| |
| − | If you have custom applications running within the appliance which need to attach/detach from
| |
| − | the pool or specific directories within a given storage pool these scripts may be helpful to you.
| |
| − |
| |
| − | ==== pool-poststart.sh ====
| |
| − |
| |
| − | Called just after a storage pool is started. The UUID of the pool is provided as an input arguement to the
| |
| − | script as '--pool=<POOLUUID>'. You can use 'qs pool-get <POOLUUID> --server=localhost,admin,password --xml' to get more detail about the storage pool from
| |
| − | within your script. The --xml flag is optional, and you'll need to provide the correct admin password.
| |
| − |
| |
| − | ==== pool-prestop.sh ====
| |
| − |
| |
| − | Called just before the pool is stopped.
| |
| − |
| |
| − | === Snapshot & Replication Schedule Custom Scripts ===
| |
| − |
| |
| − | ==== schedule-prestart.sh ====
| |
| − |
| |
| − | Called just before the a snapshot or replication schedule is triggered / executed. This script is helpful for calling over to applications like databases to tell it to flush writes to prepare for the database to have a snapshot image taken of it. Snapshots are atomic but snapshots taken of multiple volumes or network shares are not atomic as a group. That's where this script can help guide an application spanning multiple Storage Volumes (LUNs) to flush and briefly quiesce IO to give you atomicity across volume snapshots for your application.
| |
