Qumulo FAQs

IN THIS ARTICLE

Outlines how to configure IP failover with Qumulo in AWS

REQUIREMENTS

AWS account

Account limits large enough for 20TB of EBS ST1 and 2TB of EBS GP2

Permission to launch EC2 instances

IAM role associated with your Qumulo Core instances has permission to perform the AssignPrivateIpAddresses, DescribeInstances, and UnassignPrivateIPAddressesactions

Four or more nodes running Qumulo in AWS version 2.9.4 or higher

Command line (qq CLI) tools installed via API & Tools in the Web UI

NOTE: Modifying the type or size of the EBS volumes in the Qumulo AMI will render the software not functional. Please usethe AMI volume layout provided in the original image.

DETAILS

With the release of version 2.9.4, Qumulo Core supports IP failover in AWS using the same floating IP functionality that currently exists with Qumulo's on-prem clusters.

Manage IP Addresses in AWS Console

Log into the AWS Console

Navigate to the EC2 Dashboard

Right click on the instance QQ CLI: Cluster Configuration

Select Networking and click Manage IP Addresses

Click Assign new IP for as many additional IPs you desire on that node

Leave the default Auto-assign option in place

Click Yes, Update

Close the window

Repeat the above steps for each node in the cluster

In order to avoid running up against per-instance secondary IP address limits in AWS, it is recommended that the floating IPs be provisioned evenly across all instances in the cluster.See the IP failover with Qumulo Core article for more details on the recommended number of floating IPs for your cluster size. Presently, only IPv4 addresses are supported.

Assign Secondary IPs as Floating IPs in Qumulo Core

Open a terminal window

Copy the provisioned secondary IPs from the Description tab on the instance listing

Paste the IPs into the following command in your terminal window using a space to separate

qq network_mod_network --network-id 1 --floating-ip-ranges <address-or-range> [<address-or-range> ...]

Repeat the process until all secondary IPs for all nodes are included in the same command above

For example:

qq network_mod_network --network-id 1 --floating-ip-ranges 10.81.14.40 10.81.4.254

Check that the floating IPs have been assigned to your nodes correctly by running the following command

qq network_poll

Each node's DHCP network should have at least one floating IP assigned to it as outlined in the example below:

{ "interface_details": { ... }, "interface_status": { ... }, "network_statuses": [ { "address": "10.81.5.64", "assigned_by": "DHCP", "dns_search_domains": [ ... ], "dns_servers": [ "10.81.13.17" ], "floating_addresses": [ "10.81.14.40" ], "mtu": 9001, "name": "Default", "netmask": "255.255.240.0", "vlan_id": 0 } ], "node_id": 1, "node_name": "...", "update_status": "CHANGES_APPLIED" }

You may notice that the original secondary IP assignments that you made have now changed. Qumulo Core is now using these IPs and will manage their assignments to each node for you. Note that if you un-assign one of the Floating IPs secondary private IP address from an instance, Qumulo Core will attempt to reassign it to the instance. Make sure to remove the floating IP from the Qumulo Core networking configuration before un-assigning the secondary private IP address from a Qumulo Core instance.

You should now be able to mount the cluster via the floating IPs. If the node currently assigned a floating IP fails, the floating IP will be transferred to another node in the cluster and client operations should be able to continue uninterrupted.

RESOLUTION

You should now be able to successfully configure IP failover with Qumulo in AWS

ADDITIONAL RESOURCES

IP failover with Qumulo Core

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to configure SMB3 encryption with Qumulo Core

REQUIREMENTS

Cluster running Qumulo Core 2.14.0 or later

Command line (CLI) tools installed via API & Tools tab

PROCESS

SMB3 introduces encryption to the SMB protocol at a cluster-wide level or at a per-share level. Depending on your environment and workflow, you can configure per-share level encryption instead of the cluster-wide setting so that a client can use encryption against a single share that requires it and connect to a share that does not in the same session.

Keep in mind that while these settings can be controlled, SMB clients can still decide whether or not to encrypt even when encryption is not required.

NOTE: By default, the cluster level setting is set to no encryption and the per-share setting is set to unencrypted.

Interactions between Cluster and Per-share Level Encryption

Cluster-wide encryption can be configured in one of three ways: no encryption, prefer encryption, and require encryption. When cluster-wide encryption is disabled, clients can send unencrypted or encrypted packets unless connected to an encrypted share. If the client is connected to an encrypted share, only encrypted packets are permitted. When cluster level encryption is set to preferred, clients can send either encrypted or unencrypted packets unless they are connecting to an encrypted share, in which case they must send encrypted traffic. If cluster level encryption is required, clients must send only encrypted packets regardless of per-share settings.

The following table details the interactions between cluster level encryption and per-share level encryption:

Cluster Encryption Level

Unencrypted Share

Encrypted Share

No Encryption

Client can send unencrypted or encrypted packets.

Client must send encrypted packets. Unencrypted clients will be disconnected.

Prefer Encryption

Client can send unencrypted or encrypted packets.

Client must send encrypted packets. Unencrypted clients will be disconnected.

Require Encryption

Client must send encrypted packets. Unencrypted clients will be disconnected.

Client must send encrypted packets. Unencrypted clients will be disconnected.

Configure Cluster Level Encryption via QQ CLI

No Encryption: Encryption is disabled and not advertised to clients.

qq smb_modify_settings --encryption-mode NONE

Prefer Encryption: Encryption is enabled. Clients can connect unencrypted.

qq smb_modify_settings --encryption-mode PREFER

Require Encryption: Encryption is required. Clients incapable of encryption will not be able to connect.

qq smb_modify_settings --encryption-mode REQUIRE

Configure Per-share Level Encryption via QQ CLI

Unencrypted: Encryption is disabled. Clients can connect to the share encrypted and unencrypted.

qq smb_mod_share --name SHARE NAME --require-encryption FALSE

Encrypted: Encryption is required. Clients incapable of encryption will not be able to connect.

qq smb_mod_share --name SHARE NAME --require-encryption TRUE

TIP!The share id can be used by replacing --name with --id in the commands above.

Disable SMB3 Negotiation for Performance

Its important to note that a client can decide to encrypt even with the minimal settings configured. Compared to unencrypted configurations, pipelined workflows may see a mild performance degradation of 10% to 15%, while synchronized operations may experience a 50% to 65% drop in performance. Keep in mind that performance is highly workload-dependent so you may see different results.

As we iterate our implementation in later releases, you can expect to see performance results improve. In the meantime, you can avoid this potential performance impact by disabling SMB3 negotiation to prohibit advertising the encryption capability.

To disable SMB3 negotiation, use the following command to remove SMB3 from the supported dialects list:

qq smb_modify_settings --supported-dialects SMB2_DIALECT_2_1

If you need to re-enable SMB3 negotiation, you can run the following to include SMB3 and SMB2.1 in the supported dialects list:

qq smb_modify_settings --supported-dialects SMB2_DIALECT_2_1 SMB2_DIALECT_3_0

RESOLUTION

You should now be able to successfully configure cluster and per-share level encryption for SMB3 with Qumulo Core

ADDITIONAL RESOURCES

QQ CLI: SMB Shares

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to run Qumulo Core in a virtual environment

Install Qumulo Core OVA

Create a virtual cluster

REQUIREMENTS

Software installed to run a VM

Reference the KB article Virtual Machines: Demo clusters in ESXi and vSphere for additional details

Upgrade the VM software before creating the cluster if prompted

Verify that IPv6 is enabled for node to node communication

Qumulo Core OVA downloaded from here

Contact our team for the current password

DETAILS

Install the OVA

Choose File > Import to open the Import Library using VMWare Fusion or another workstation

Select Qumulo_Core_X.X.X.ova for import QQ CLI: Comprehensive List of Commands

Create additional nodes for a cluster by cloning the original VM orimport the same OVA again

Note that you'll need to clone before powering on the VM. Keep in mind that depending on the workstation, cloning may give the nodes identical MAC addresses resulting in only one node being found. If that's the case, please import the OVA for each virtual instance.

A minimum of 4 nodes is required to create a fully functional Qumulo cluster

NOTE:Once multiple VMs are running, they will automatically be discovered and be available to add to your cluster.

Create a Virtual Cluster

Boot up the VM(s)

Acceptthe End User License Agreement and Terms of Service on any one of the nodes when prompted

To Create a Cluster:

Name the cluster

Select the node(s) for the cluster. If any nodes are missing, verify that the VM for the node is currently running and on the same network

Customize your cluster protection level (if available)

Provide an admin password

Click Create Cluster

NOTE: To connect to the virtual clusters Web UI, enter the IP address from any of your nodes into Google Chrome browser session.

RESOLUTION

You should now be able to successfully configure and run a Qumulo Core virtual cluster

ADDITIONAL RESOURCES

Video: Create a Qumulo virtual cluster on a Mac

Video: Create a Qumulo virtual cluster on Windows

Like what you see? Share this article with your network!

IN THIS ARTICLE

Includes a video outlining how to create a Qumulo virtual cluster on a Mac

REQUIREMENTS

VMware installed and running latest software version

Verify that IPv6 is enabled for node to node communication

Qumulo Core OVA downloaded from here

Contact our team for the current password

VIDEO

RESOLUTION

You should now be able to successfully create a virtual cluster running Qumulo Core on a Mac

ADDITIONAL RESOURCES

Virtual Machines: Create a virtual cluster running Qumulo Core

QQ CLI: Comprehensive List of Commands

Like what you see? Share this article with your network!

We here at Qumulo know how important it is to make the right decision for your organization's technology needs. Because of this, we provide a demonstration version of Qumulo Core with limited support from our Qumulo Care team.

IN THIS ARTICLE

Outlines the supported and unsupported hosts, configurations, and environments for OVA demo clusters in ESXi and vSphere

REQUIREMENTS

VMwareESXi or VMware vSphere5.5 or higher

The latest Qumulo Core OVA, a VM file type that is compatible with ESXi and other virtualization products.

DETAILS

With VMware Desktop and VMWare Fusion, you can use our OVA to launcha virtual Qumulo Cluster from anywhere tolearn Qumulo Core's user interface and test our API. Customers are encouraged to runa virtual cluster to experiencethe Qumulo API first hand so that they can test scripts or develop software as needed.

This same OVA for VMWare Desktop can also be imported into a VMware ESXi or Vsphere environment for non-production use to evaluate Qumulo Cores user experience and features includingcluster upgrades, adding nodes to an existing cluster, and much more.

Below are the requirements for using an OVA cluster with VMware ESXi or vSphere, includingthe requirements for the limited support that is currently offered by Qumulo for the free, non-production, virtual demonstration clusters.

Supported Environments and Hosts

ESXihost:

ESXi Host with any of the below Processors:

Intel Xeon E5-1620 to E5-1680 V2 series or newer

Intel Xeon E5-26xx V2 or newer

Intel Xeon E5-48xx V4 series

Intel Xeon E7 V2 through V4 series processors

ESXi Host Memory Requirements:

8GB of RAM Minimum4GB of RAM to meet ESXi 6.5 Requirements plus a minimum of 1GB of RAM per Virtual Qumulo Node in a four-node cluster

Virtual Networking

Standard vSwitch (Virtual Switch) from VMWare

A single VMXNET3 Virtual Network Card per Virtual Node

IPv4 and IPv6 link-local is a requirement for forming a Virtual Cluster. IPv6 may be isolated to a single ESXi host.

Backing Storage

Any Qumulo Cluster over NFS

Local Host Storage of two or more SATA III drives in a RAID 0, RAID5, or better

SSDs are recommended but not required.

NOTE: Qumulo OVAs can be deployed on Vsphere with the "vmware web-client (vca)" option. The "vpxclient" option is not supported.

Unsupported Configurations, VMWare Features, and Environments

Cloning a deployed VM after the VM has been powered on.

Qumulo Core will encode the MAC address the node was first booted with and will not discover other nodes that have the same mac address encoded in their configurations.

Virtual Hardware configuration changes to Virtual Nodes

Virtual Clusters spanning hosts ORrunning Virtual Nodes on more than one host

VMotion (Compute or Storage) of running Virtual Nodes or Virtual Clusters

VMware hardware passthrough technologies VMDirectPath I/O passthrough devices

Keep in mind that occasionally there may be changes to virtual machine, disk images and volumes that will prevent an upgrade from one version of Qumulo Core to the next while running with a virtualized environment.

NOTE:Other storage configurations may function for evaluation purposes but are not supported.

RESOLUTION

You should now be able to successfully utilize Qumulo's OVA for a demonstration cluster in ESXi and vSphere

ADDITIONAL RESOURCES

Video: Create a Qumulo virtual cluster on a Mac

Video: Create a Qumulo virtual cluster on Windows

Virtual Cluster: Create a virtual cluster running Qumulo Core

QQ CLI: Comprehensive List of Commands

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to install the rails, rack the nodes and create a cluster for QC24 and QC40 platforms

REQUIREMENTS

Review Qumulo Safety Instructions

QC Series 1U hardware

Front panel

Rack Rails

Compatible network cables (fiber or twinax with SFP+)

Power Cords

Optional: Rail Kit round hole adapters

For additional guidance on cluster configuration and getting started, reference the Qumulo Installation FAQ article for more details.

TECHNICAL SPECIFICATIONS

QC24 Networking Diagrams

INSTALL THE RAILS

Slide the inner rail in place before installing the rail on the rack.

Verify the front end of the rail.

Place the front of the rail into the holes on the rack using the numbers as a guide.

Hold the lock and place the rear of the rail into the holes using the same numerical placement as the front.

Release to lock the rail in place.

RACK THE NODES

Place node into the rail system by aligning the rails between the node and the rack.

Release the blue button on the side of the node to slide the node and rails into the rack.

Tighten the thumbscrew to secure the node in place.

Attach the network cables (3) using the QC24 Networking Diagrams as a guide and plug in the power cables on the back of the node (5). For additional details, reference the Qumulo's Networking Best Practices article.

Connect any one of the nodes to a display, keyboard and mouse (4).

Turn on the nodes by pressing the power button on the front.

Check that all drive lights (red, blue, green) illuminate before proceeding to create a cluster.

CREATE A CLUSTER

Review the End User License Agreement, check the box to agree and click Submit.

1. Setup Cluster

Name the cluster.

Select the nodes for the cluster .

If any nodes are missing, verify that the node is currently running and on the same network

NOTE: The total capacity for the cluster is dynamically updated at the bottom of the page when selecting nodes.

2. Confirm cluster protection level

The recommended 2 or 3 drive protection level will be selected by default based on the cluster size and node type.

If Customize Protection Levelis displayed, the option is available to increase the resilience of the system by selecting 3 drive protection. Keep in mind that selecting 3 drive protection will result in less capacity for the cluster.

NOTE: The option for selecting the drive protection level is only available at cluster creation and cannot be changed after the fact.

3. Create a password for your admin account

Type in the password for your admin account.

Retype the password to confirm.

Click Create Cluster.

To access the dashboard in the Qumulo Core UIremotely, use any node's IP address to connect via web browser.

RESOLUTION

You should now be able to successfullyinstall the rails, rack the nodes and create a cluster for QC24 and QC40 platforms

ADDITIONAL RESOURCES

Qumulo Safety Instructions

QC Series Data Sheet

Qumulo Installation FAQ

Qumulo's Networking Best Practices

Create a Qumulo Cluster with 2.7.10 and above

Like what you see? Share this article with your network!

The list below reflects qq commands available in version 2.14.2 of Qumulo Core. Certain commands may be unavailable if you are running a previous version and will require upgrading to a later release of Qumulo Core to utilize the API action.

IN THIS ARTICLE

Lists all qq commands available in Qumulo Core and their corresponding API action

REQUIREMENTS

Cluster is in quorum and qfsd process is running on the selected node

Command line (CLI) tools installed via API & Tools in the Web UI

Admin privileges on the Qumulo cluster

COMPREHENSIVE LIST OF COMMANDS

COMMAND

ACTION

qq ad_cancel

Cancel current AD join/leave operation and clear errors

qq ad_clear_cache

Clear the AD ID mapping cache

qq ad_distinguished_name_to_account

Get all account info for a distinguished name

qq ad_expand_groups

Get the SIDs of all the groups (including nested) that the given SIDis a member of

qq ad_gid_to_sids

Get SIDs from GID

qq ad_join

Join an Active Directory Domain

qq ad_leave

Leave an Active Directory Domain

qq ad_list

List Active Directory Configuration

qq ad_poll

Poll Active Directory Configuration

qq ad_sid_to_gid

Get GID from SID

qq ad_sid_to_uid

Get UID from SID

qq ad_sid_to_username

Get AD username from SID

qq ad_uid_to_sids

Get SIDS from UID

qq ad_username_to_sids

Get SIDs from an AD username

qq add_nodes

Add un-configured nodes to a Qumulo Cluster

qq audit_get_config

Get audit configuration

qq audit_get_status

Get audit log status

qq audit_set_config

Change audit configuration

qq auth_add_group

Add a new group

qq auth_add_user

Add a new user

qq auth_assign_role

Assign a user to a role

qq auth_clear_cache

Clear all cached authorization information

qq auth_delete_group

Delete a group

qq auth_delete_user

Delete a user

qq auth_expand_identity

Find equivalent identities and full group membership

qq auth_find_identity

Find all representations of a given identifier

qq auth_get_user_defined_mappings

Get the configured set of AD/LDAP static user defined mappings

qq auth_list_group

List a group

qq auth_list_groups

List all groups

qq auth_list_role

List a role

qq auth_list_roles

List all roles

qq auth_list_user

List a user

qq auth_list_users

List all users

qq auth_mod_group

Modify a group

qq auth_mod_user

Modify a user

qq auth_set_password

Set a user's password

qq auth_set_user_defined_mappings

Replace the configured set of AD/LDAP static identity mappings

qq auth_unassign_role

Unassign a user from a role

qq capacity_history_files_get

Get historical largest file data

qq capacity_history_get

Get capacity history data

qq change_password

Change your password

qq cluster_conf

Get the cluster config

qq cluster_create

Creates a Qumulo Cluster

qq cluster_slot_set_config

Set the attributes for the given cluster slot. Currently only led_pattern may be set.

qq cluster_slots

Get the cluster disk slots status

qq current_activity_get

Get the current sampled IOP and throughput rates

qq dns_get_lookup_overrides

List the configured set of DNS lookup overrides. These rules override any lookup results from the configured DNS servers and serve as static mappings between IP address and hostname

qq dns_resolve_hostnames

Resolve hostnames to IP addresses

qq dns_resolve_ips

Resolve IP addresses to hostnames

qq dns_set_lookup_overrides

Replace the configured set of DNS lookup overrides. These rules override any lookup results from the configured DNS servers and serve as static mappings between IP address and hostname

qq floating_ip_allocation

Get cluster-wide floating IP allocation

qq fs_acl_explain_chmod

Explain how setting a POSIX mode would affect a file's acl

qq fs_acl_explain_posix_mode

Explain the derivation of POSIX mode from afile's ACL

qq fs_acl_explain_rights

Explain how rights are granted to a user for afile. *Note that this command does not discover the user's groups and related identities when computing rights. To provide this information, use the -g argument.

qq fs_create_dir

Create a new directory

qq fs_create_file

Create a new file

qq fs_create_link

Create a new link

qq fs_create_symlink

Create a new symbolic link

qq fs_create_unix_file

Create a new pipe, character device, block device or socket

qq fs_delete

Delete a file system object

qq fs_delete_tree

Delete a file system tree recursively

qq fs_delete_tree_status

Status of a tree-delete job

qq fs_file_get_attr

Get file attributes

qq fs_file_samples

Get a number of sample files from the file system

qq fs_file_set_attr

Set file attributes

qq fs_file_set_smb_attrs

Set SMB extended attributes on the file

qq fs_get_acl

Get file ACL

qq fs_get_permissions_settings

Get permissions settings

qq fs_get_stats

Get file system statistics

qq fs_list_lock_waiters_by_client

List waiting lock requests for a particular client machine

qq fs_list_lock_waiters_by_file

List waiting lock requests for a particular files

qq fs_list_locks

List file locks held by clients.

qq fs_list_named_streams

List all named streams on a file or directory

qq fs_modify_acl

Modify file ACL

qq fs_punch_hole

Create a hole in a region of a file. Destroys all data within the hole.

qq fs_read

Read a file

qq fs_read_dir

Read a directory

qq fs_read_dir_aggregates

Read directory aggregation entries

qq fs_release_nlm_lock

Release an arbitrary NLM byte-range lock range*Only use as a last resort after confirming that the owning process has leaked the lock

qq fs_release_nlm_locks_by_client

Release NLM byte range locks (ALL) held by client*Only use after confirming that the client is dead as a last resort

qq fs_remove_stream

Remove stream from a file or directory

qq fs_rename

Rename a file system object

qq fs_resolve_paths

Resolve file IDs to paths

qq fs_set_acl

Set file ACL

qq fs_set_permissions_settings

Set permissions settings

qq fs_walk_tree

Walk file system tree

qq fs_write

Write data to a file

qq ftp_get_status

Get FTP server status and settings

qq ftp_modify_settings

Set FTP settings

qq get_vpn_keys

Get VPN keys stored in the cluster

qq halt

Halt the server

qq halt_cluster

Halt the cluster

qq help

QQ documentation

qq help file_permissions

Overview for setting, getting, and understanding file permissions.

qq identity_attributes_get

Get attributes related to the given identity.

qq identity_attributes_set

Set attributes related to the given identity.

qq install_vpn_keys

Install VPN keys

qq kerberos_delete_keytab

Delete the Kerberos keytab

qq kerberos_get_keytab

Get the Kerberos keytab

qq kerberos_get_settings

Get the Kerberos settings

qq kerberos_modify_settings

Modify the Kerberos settings

qq kerberos_set_keytab

Set the Kerberos keytab

qq ldap_get_settings

Get LDAP server settings from disk

qq ldap_get_status

Get LDAP client connection states

qq ldap_login_name_to_gid_numbers

Query the LDAP server for the gid numbers for all the groups of which the given login name is a member. This returns a vector of results in the case that the given login name maps to multiple uid numbers.

qq ldap_login_name_to_uid_numbers

Get the uidNumbers from a login name using the LDAP server

qq ldap_set_settings

Set LDAP server settings on disk

qq ldap_uid_number_to_login_name

Get login name from uidNumber using LDAP server

qq ldap_update_settings

Update LDAP server settings on disk

qq login

Log in to qfsd to get REST credentials

qq logout

Remove qfsd REST credentials

qq monitoring_conf

Get monitoring configuration

qq monitoring_status_get

Get current monitoring status

qq network_add_network

Add network configuration

qq network_conf_get

Get cluster-wide network config

qq network_conf_mod

Modify cluster-wide config

qq network_delete_network

Delete network configuration

qq network_get_interface

Get configuration for the specified interface

qq network_get_network

Get configuration for the specified network

qq network_list_connections

Get the list of SMB and NFS protocol connections per node

qq network_list_interfaces

List configurations for interfaces on the cluster

qq network_list_networks

List network configurations

qq network_mod_interface

Modify interface configuration

qq network_mod_network

Modify network configuration

qq network_poll

Poll network status

qq nfs_add_export

Add a new NFS export

qq nfs_delete_export

Delete an export

qq nfs_get_export

Get an export

qq nfs_list_exports

List all NFS exports

qq nfs_mod_export

Modify an export

qq nfs_mod_export_host_access

Modify host access on an export

qq node_chassis_status_get

Get the status of a node chassis

qq node_state_get

Get the operational status of a node

qq nodes_list

List nodes

qq protection_status_get

Get cluster protection status

qq quota_create_quota

Create a directory quota

qq quota_delete_quota

Delete a directory quota

qq quota_get_quota

Get a directory quota

qq quota_list_quotas

List all directory quotas

qq quota_update_quota

Update a directory quota

qq replication_abort_replication

Abort ongoing replication work for the specified source replication relationship

qq replication_add_blackout_window

Add a blackout window to the specified source of the replication relationship

qq replication_authorize

Authorize the specified replication relationship to establish the cluster as the target of the replication

qq replication_create_source_relationship

Create a new replication relationship

qq replication_delete_blackout_windows

Delete blackout windows of the specified source replication relationship

qq replication_delete_source_relationship

Delete the specified source replication relationship

qq replication_delete_target_relationship

Delete the specified target replication relationship

qq replication_get_source_relationship

Get information about the specified source replication relationship

qq replication_get_source_relationship_status

Get current status of the specified source replication relationship

qq replication_get_target_relationship_status

Get current status of the specified target replication relationship

qq replication_get_target_relationship_status

Get current status of the specified target replication relationship

qq replication_link_snapshot_policy

Link a snapshot policy to the specified source replication relationship to replicate snapshots taken by the policy. The replication mode will be set to REPLICATION_SNAPSHOT_POLICY_WITH_CONTINUOUS when linking the first policy, otherwise the existing mode will be preserved. The mode can be modified withthe replication_set_snapshot_policy_replication_mode command or by removing all linked snapshot policies.

qq replication_list_queued_snapshots

List information for all snapshots awaiting replication by the specified source replication relationship.

qq replication_list_source_relationships

List existing source replication relationships

qq replication_list_target_relationship_statuses

List statuses for all existing target replication relationships

qq replication_make_target_writable

Revert target directory to the latest recovery point to ensure that it is in a point-in-time consistent state. Then disconnect the specified target replication relationship, breaking the relationship with the source and making the target directory writable. The revert action may take some time to complete. If the relationship is later reconnected, any changes made to the target directory since the relationship was disconnected will be reverted upon reconnecting.

qq replication_modify_source_relationship

Modify an existing source replication relationship

qq replication_reconnect_target_relationship

Make the target directory read-only and revert any changes made to the targetdirectory since the latest recovery point. Then reconnect the specified targetreplication relationship with its source directory. The revert action may takesome time to complete before replication is resumed.

qq replication_release_queued_snapshot

Release a snapshot queued for replication from the queue of the specified source replication relationship.

qq replication_replicate

Replicate from the source to the target of the specified relationship

qq replication_reverse_target_relationship

Reverse source and target for the specifiedreplication relationship. This operation is initiated on the target cluster. The previous target directory will be made the new source, and the previous source directory will be made the new target. After reversal completes, blackout windows will be reset and the relationship will remain disconnected, where replication will not resume. To resume replication after reversal, configure blackout windows from the new source cluster and reconnect the relationship from the new target cluster.

qq replication_set_snapshot_policy_replication_mode

Set the replication mode of the specified source replication relationship. This command is only for a relationship that has linked snapshot policies.

qq replication_unlink_snapshot_policy

Unlink a linked snapshot policy from the specified source replication relationship. The replication mode will be set to REPLICATION_CONTINUOUS when unlinking the last policy, otherwise the existing mode will be preserved.

qq restart

Restart the entire machine

qq restart_cluster

Restart the cluster

qq restriper_status

Get restriper status

qq set_cluster_conf

Set the cluster config

qq set_monitoring_conf

Update the monitoring config

qq set_node_identify_light

Turn node identification light on or off

qq smb_add_share

Add a new SMB share

qq smb_delete_share

Delete a share

qq smb_get_settings

Get SMB server settings

qq smb_list_share

List a share

qq smb_list_shares

List all SMB shares

qq smb_modify_settings

Set SMB server settings

qq smb_mod_share

Modify a share

qq smb_mod_share_permissions

Modify a share's permissions

qq snapshot_calculate_used_capacity

Get the space used by the specified snapshots

qq snapshot_create_policy

Create a new snapshot scheduling policy

qq snapshot_create_snapshot

Create a new snapshot

qq snapshot_delete_policy

Delete a single scheduling policy

qq snapshot_delete_snapshot

Delete a single snapshot

qq snapshot_diff

List the differences between two snapshots

qq snapshot_file_diff

List changed byte ranges of a file between two snapshots

qq snapshot_get_capacity_used_per_snapshot

Get the approximate amount of space for each snapshot that would be reclaimed if deleted

qq snapshot_get_policy

Get a single policy

qq snapshot_get_policy_status

Get a single snapshot policy status

qq snapshot_get_snapshot

Get a single snapshot

qq snapshot_get_status

Get status of a single snapshot

qq snapshot_get_total_used_capacity

Get the total space consumed by all snapshots

qq snapshot_list_policies

Lists all policies

qq snapshot_list_policy_statuses

List all snapshot policy statuses

qq snapshot_list_snapshots

List all snapshots

qq snapshot_list_statuses

List all snapshot statuses

qq snapshot_modify_policy

Modify an existing snapshot scheduling policy

qq snapshot_modify_snapshot

Modify an existing snapshot

qq ssl_delete_ca_certificate

Delete SSL CA certificate

qq ssl_get_ca_certificate

Get SSL CA certificate

qq ssl_modify_ca_certificate

Set SSL CA certificate

qq ssl_modify_certificate

Set SSL certificates

qq static_ip_allocation

Get cluster-wide static IP allocation

qq time_get

Get time configuration

qq time_list_timezones

List timezones supported by QC

qq time_series_get

Get specified time series data

qq time_set

Set time configuration

qq time_status

Get time configuration status

qq unconfigured

Checks if the node is unconfigured

qq unconfigured_nodes_list

Get the list of unconfigured nodes

qq upgrade_config

List current upgrade prepare config

qq upgrade_config_set

Prepare an upgrade using a file on fs

qq upgrade_status

List current upgrade status

qq version

Print current version information

qq who_am_i

Get information on the current user

NOTE: Once you've accessed a node via ssh,you can see the full list of qq commands by running:

qq -h

RESOLUTION

You should now be able to successfully complete specific API actions on your cluster by utilizing the qq commands in Qumulo Core

ADDITIONAL RESOURCES

QQ CLI: Install Command-Line Tools

QQ CLI: Get Started

Like what you see? Share this article with your network!

IN THIS ARTICLE

Lists the qq commands availablefor cluster configuration in Qumulo Core and their corresponding API action

REQUIREMENTS

Cluster running Qumulo Core

Cluster is in quorum and qfsd process is running on the selected node

The list below reflects the qq commands currently available for cluster configuration and can differ between versions ofQumulo Core. Certain commands may require upgrading to a later release to utilize a specific API action.

Command line (CLI) tools installed via API & Tools in the Web UI

Admin privileges on the Qumulo cluster

COMMANDS FOR CLUSTER CONFIGURATION

COMMAND

ACTION

qq add_nodes

Add un-configured nodes to a Qumulo cluster

qq audit_get_config

Get audit configuration

qq audit_get_status

Get audit log status

qq audit_set_config

Change audit configuration

qq cluster_conf

Get the cluster config

qq cluster_create

Creates a Qumulo Cluster

qq cluster_slot_set_config

Set the attributes for the given cluster slot. Currently only led_pattern may be set.

qq cluster_slots

Get the cluster disk slots status

qq halt

Halt the server

qq halt_cluster

Halt the cluster

qq nodes_list

List nodes

qq restart

Restart a node

qq restart_cluster

Restart the cluster

qq restriper_status

Get restriper status

qq set_cluster_conf

Set the cluster config

qq time_get

Get time configuration

qq time_list_timezones

List timezones supported by QC

qq time_series_get

Get specified time series data

qq time_set

Set time configuration

qq time_status

Get time configuration status

qq unconfigured

Checks if the node is unconfigured

qq unconfigured_nodes_list

Get the list of unconfigured nodes

qq upgrade_config

List current upgrade prepare config

qq upgrade_config_set

Prepare an upgrade using a file on fs

qq upgrade_status

List current upgrade status

qq version

Print current version information

NOTE: Once you've accessed a node via ssh,you can see the full list of qq commands by running:

qq -h

RESOLUTION

You should now be able to successfully use qq commands for cluster configuration to complete specific API actions in Qumulo Core

ADDITIONAL RESOURCES

QQ CLI: Install Command-Line Tools

QQ CLI: Get Started

QQ CLI: Comprehensive list of Commands

Qumulo Core Upgrades via Web UI

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to add a node to an existing Qumulo cluster in GCP

REQUIREMENTS

Google Cloud Platform (GCP) account

Google Deployment Manager API enabled

GCP account limits large enough for the instances and volumes desired

An SSH key-pair for accessing Qumulo instances via SSH

Google Virtual Private Cloud (VPC) with at least one subnet configured in the target region

Instances on the subnet must be able to access the internet (for example, via a NAT gateway)to support Qumulo's Cloud-based Monitoring

IMPORTANT!If you have configured IP failover for your cloud cluster, you must add additional floating IP's prior to adding another node. Reference the Qumulo in GCP: Configure IP Failover article for additional details.

DETAILS

There are two methods of adding nodes to a Qumulo cluster in GCP, depending on how the cluster was originally deployed. The first mechanism is specific to clusters deployed via the GCP Marketplace, and the second uses Deployment Manager Templates and is meant to be used with deployments that were configured directly through Qumulo. If Qumulo originally deployed your cluster, you will need to contact [email protected] for additional assistance to successfully add additional nodes.

Contact your system administrator to confirm which type of deployment you have prior to adding capacity your cluster via the steps below.

GCP Marketplace Deployments

Find the marketplace solution corresponding to your existing GCP Qumulo clusters SKU.

Deploy that same solution: Qumulo in GCP: Build a Multi-Instance Cluster

Set the instance count to however many nodes you want to add

There may be fewer than 4, unlike when auto-clustering

Dont check the automatically cluster you instances checkbox

Fill out the remaining fields as you did when first deployed your cluster, but use a new deployment name. Make sure you choose the same subnet as the existing clusters deployment so the nodes can talk to each other.

Once the deployment completes, note the list of IP addresses.

Add Nodes to the Cluster via the UI

Login to the Qumulo Core Web UI of your existing GCP cluster.

Hover over the Cluster menu and click Add Nodes.

Enter the list of IP addresses into the text box and click Add Selected Nodes to Cluster.

Select Yes to confirm the addition of the selected node(s).

A dialog box will display as the node(s) are configured and added to the cluster.

Once the new node is configured and added, the cluster Overview page will appear with a successful confirmation banner at the top. The newly-configured node(s) will now display in the listing table for the cluster.

NOTE: Existing nodes will retain their numbering once the new node is added.

RESOLUTION

You should now be able to successfullyadd a node to an existing Qumulo cluster in GCP

ADDITIONAL RESOURCES

Qumulo in GCP: Configure IP Failover

Qumulo in GCP: Upgrade an Unconfigured Node

Qumulo in GCP: Deploy an Instance

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to upgrade an unconfigured node for a Qumulo cluster in GCP

REQUIREMENTS

GCP Cluster running Qumulo Core 2.14.0 or above

A .qimg file for the version of software that your new node can be upgraded to via our Product Releases page

GCP Console Access

Command line (QQ CLI) tools installed via API & Tools in the Web UI

DETAILS

One of the perks of hosting your storage in the cloud is the ability to dynamically add more as your storage needs increase. Starting up a new node (a.k.a, launching a deployment) is a simple process and adding the instance to an existing cloud cluster is even easier.

Keep in mind that if this new node uses an older version of Qumulo Core than your cluster, it must be upgraded before you can add it. The process of upgrading a new node is simply a matter of starting the node up and then upgrading it via the QQ CLI as outlined below. Once the node's software version matches the one your deployment uses, you can add it to your cluster.

Launch a New Instance

Navigate to the GCP Marketplace listing for your cluster.

Launch a new instance for that listing in the same VPC and Security Group as the existing cluster. Qumulo in GCP: Build a Multi-Instance Cluster

EnsureAutomatically cluster your instances is unchecked.

Click Deploy.

IMPORTANT! If an image is available with the same version of Qumulo Core used on your cluster, start an instance from this image. Otherwise, choose an image with the closest (older) version.

Upgrade the Nodes via the QQ CLI

Upload the .qimg upgrade file to a location that the new node can access.

Connect to the new node via ssh using its IP address.

ssh admin@node_IP_address

Prepare the upgrade by running the following command using the path to the upgrade image you previously uploaded.

qq upgrade_config_set --path <qimg file path> --target "prepare"

Use the following command to monitor the prepare status until it returns UPGRADE_PREPARED.

qq upgrade_status --monitor

Once you see UPGRADE_PREPARED, run the following command to start the upgrade.

qq upgrade_config_set --path <qimg file path> --target "arm"

The node will restart after a few minutes after completing the upgrade. Check that the upgrade was successful by running the following command and verifying the new version number.

qq version

If the software version on the node matches that of your cluster, you can then proceed to follow the steps provided in Qumulo in GCP: Add a Node to an Existing Cloud Cluster. If the new node is still on an older version, repeat this process with subsequent upgrades until the versions match.

RESOLUTION

You should now be able to successfullyupgrade an unconfigured node for Qumulo cluster in GCP

ADDITIONAL RESOURCES

Qumulo in GCP: Add a Node to an Existing Cloud Cluster

Qumulo in GCP: Deploy an Instance

Like what you see? Share this article with your network!

IN THIS ARTICLE

Provides an overview of Qumulo's Cloud-Based Monitoring and Remote Support

REQUIREMENTS

Cluster running Qumulo Core

Qumulo's Cloud-Based Monitoring enabled

Qumulo's Remote Support enabled & VPN keys installed

Protocols/ports allowed to the following destination hostnames as outlined in the table below:

Feature

Protocol

Ports

Destination

Cloud-Based Monitoring

tcp

443

missionq.qumulo.com

Remote Support

tcp

443

ep1.qumulo.com

Log Uploads

tcp

443

monitor.qumulo.com

Proxy Forwarding [if applicable]

tcp

443

missionq-dumps.s3.amazonaws.com

DETAILS

Qumulo Care offers customers the ability to enable two support features on their Qumulo cluster. Qumulo's Cloud-Based Monitoring enables our team toproactively detect potential problems and Qumulo's Remote Support allows access to your cluster via a VPN connection to troubleshoot and resolve problems remotely.

QQ CLI: Monitoring and VPN

CLOUD-BASED MONITORING

Cloud-Based Monitoring is an internal monitoring tool that allows Qumulos Customer Success team to proactively monitor your cluster. Enabling this feature allows the cluster to send detailed diagnostic data over an encrypted connection. Qumulo has developed a proprietary application that aggregates cluster diagnostic data and sends alerts to our Customer Success team should an issue arise.

REMOTE SUPPORT

Remote Supportgives Qumulos Customer Success team remote access to your cluster for diagnostic purposes only. This leverages industry standard encryption technologies that ensure our connectivity is secure. This feature is typically used when Qumulos Customer Success team is assisting with a code update or diagnostic/troubleshooting at the command line. Utilizing Remote support prevents customers from having to manually run commands and send out bulky diagnostic log packages and can be enabled on an as needed basis.

We highly recommend that you enable both Remote Support and Cloud-Based Monitoring so that our team can provide fast support when you need it the most. Reference Qumulo's Cloud-Based Monitoring and Qumulo's Remote Support articles for additional details on these support features.

RESOLUTION

You should now have an overall understanding of Qumulo Care's Proactive Monitoring

ADDITIONAL RESOURCES

Qumulo's Remote Support

Qumulo's Cloud-Based Monitoring

Cloud-Based Monitoring via Custom Proxy

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to install QQ Command-Line Tools from the Web UI of Qumulo Core

REQUIREMENTS

Cluster running Qumulo Core

Python 2.7

Admin privileges on the Qumulo cluster

DETAILS

Log in to the Qumulo Core Web UI.

SelectAPI & Tools.

Click Download Command-Line Tools button. QQ CLI: Comprehensive List of Commands

Unzip the downloaded file on your computer.

Copy the qumulo_api directory to your home directory to ensure that only you are able to run the qq command on the computer where you are installing. If others need access, copy the qumulo_api directory to one of the following:

Apple and Linux computers - copy to /opt/

Windows - copy toC:\Program Files (x86)\

Lastly, you'll need copy the qumulo_api directory to your system's PATH to use the qq command from any location in the file system while in your CMD prompt or terminal.

Windows

Go to Control Panel, select System, click Advanced System Settings, and selectEnvironmental Variables

Navigate to the System Section and add the following paths toPath Variables

C:\Python27\

C:\Python27\scripts

C:\Program Files (x86)\qumulo_api

Add the .PY Extension to the list of variable values in thePATHEXT section

Exit out of the system properties and browse to C:\Program Files (x86)\qumulo_api

Right click on the qq file and rename it to qq.py

You can now open up a command prompt and interact with a Qumulo cluster from a window workstation or server.

Mac

Open a Terminal window

Run the following command:

sudo nano etc/paths

Enter your password when prompted

Enter the path of the qumulo_api folder at the bottom of the file:

Type control-X to exit

Type Y and hit Enter to save the change

Launch a new Terminal window and run the following command to verify:

echo $PATHS

You can now open up a Terminal window and interact with a Qumulo cluster from a Mac workstation.

For additional details command-line tools, reference the article QQ CLI: Get Started for more information.

RESOLUTION

You should now be able to successfully install QQ Command-Line Tools in Qumulo Core

ADDITIONAL RESOURCES

QQ CLI: Get Started

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to use role-based access control for users and groups in Qumulo Core

REQUIREMENTS

Cluster running Qumulo Core 2.13.5 and above for Administrators role (2.14.0 and above for Web UI configuration)

Cluster running Qumulo Core 2.14.1 and above for Data-Administrators and Observers roles

Command line (CLI) tools installed via API & Tools in the Web UI

Existing Qumulo Administrator privileges

DETAILS

With Qumulo, specific privileges can be granted to any user or group, local or in Active Directory, via role-based access control (RBAC). Assigning any one of the following roles using the Qumulo Core Web UI or QQ CLI will control access so that management responsibilities for the cluster can be shared while still restricting certain actions.

NOTE: Users with a newly assigned rolewill need to re-log in or experience a session timeout for the change to take effect.

Administrators Role

Qumulo Administrators will have full access and control of the cluster.Once a user or group is assigned the Administrators role, they will have the privilege to perform the following actions:

Configure and manage general cluster settings for audit logging, snapshots, replication, quotas, etc. via the Web UI, API, or QQ CLI

Createfiles and directories in the current and all future directories

Read all files and file attributes and list all directories in the current and all future directories

Delete or rename all files and directories in the current and all future directories

Change ownership and permissions for all files and directories in the current and all future directories

Data-Administrators Role

The Data-Administrators role is ideal for API/CLI users. With this role, a user or group will not have access to the Web UI but will have the same file privileges as the Administrators role along with the following:

Read/write permissions for all NFS/SMB/Quotas/Snapshots APIs

Read-only permissions to APIs for local-users

Access to the analytics and miscellaneous fs-related APIs including tree-deletes, permissions modes, and reading/releasing locks (NLM) on files

Observers Role

With the Observers role, you can grant any user or group the privilege to access the Web UI and read-only APIs with a few exceptions (debug APIs and authentication settings). This role is assigned to the "Everyone" group by default on clusters running Qumulo Core 2.14.1 or above.

TIP!If needed, you can assign a user both the Data-Administrators and Observers role to give them the ability to manage the data on your Qumulo cluster via the Web UI without giving them full admin access.

Role Management via the UI

Login to the Qumulo Core Web UI.

Hover over the Cluster menu and click Role Management. QQ CLI: Admins, Users and Groups

Click Add Members for the role you wish to assign.

Use any one of the following trustee inputs to assign the role:

Click Yes, Assign Role.

The new user or group will be added to the list of Administrators, Data-Administrators, or Observers on the Role Management page. To unassign a role, simply click the blue trash can icon on the user or group listing.

Role Management via QQ CLI

To assign a role to a user or group, include the credential information for the trustee in the command below:

qq auth_assign_role --role ROLE --trustee TRUSTEE

Role options include:

administrators

data-administrators

observers

Supported credentials for the trustee include the following:

UID

GID

SID

Local username

Active Directory credentials with DOMAIN\name

auth_id

EXAMPLE: Running the command below would assign the Administrators role to the user with UID 1000.

qq auth_assign_role --role administrators --trustee uid:1000

To unassign a role, include the credential information for the trustee in the command below:

qq auth_unassign_role --role ROLE --trustee TRUSTEE

EXAMPLE: The Observers role would be unassigned to the user with UID 2000 using the command below.

qq auth_unassign_role --role observers --trustee uid:2000

To review the list of users and groups that have role-based access control on your cluster, use the command below:

qq auth_list_roles

RESOLUTION

You should now be able to successfully use role-based access control (RBAC) for users and groups in Qumulo Core

ADDITIONAL RESOURCES

Default File permissions in Qumulo Core

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to add a node to an existing cloud cluster

REQUIREMENTS

Cloud Cluster with Qumulo Core 2.8.6 and above

AWS Console access

Command line (qq CLI) tools installed via API & Tools in the Web UI

IMPORTANT!If you have configured IP failover for your cloud cluster, you must add additional floating IP's prior to adding another node. Reference the Qumulo in AWS: Configure IP Failover article for additional details.

DETAILS

Running a clustered configuration ofQumulo in AWS across 4 or more Qumulo nodes improves performance and increases capacity by providing a minimum of 20TB of raw storage. Larger systems with higher node numbers will have increased storage efficiency dependent on the initial number of nodes used to form the cluster. The process of adding a new node to an existing cloud cluster is incredibly straightforward using the private IPs of the AWS instance.

QQ CLI: Cluster Configuration

Add a node via the UI

In a browser window, enter https:// followed by the Private IPaddress included in the Description tab of the instance listing for any node on the existing cluster

Note: Qumulo is configured with a self-signed certificate by default which may cause your browser to display a warning. This is normal behavior. A custom certificate can be installed at a later time to avoid the warning if needed.At the warning, select ADVANCED and click Proceedto continue.

Login to the Qumulo Core Web UI

Hover over Cluster and select Add Nodes

Enter the IP addresses of the unconfigured nodes you wish to add separating each address with a comma

Click Add Selected Nodes to Cluster

Select Yes to confirm the addition of the selected node(s)

A dialog box will display as the node(s) are configured and added to the cluster

Once the new node is configured and added, the cluster Overview page will appear with a successful confirmation banner at the top. The newly configured node(s) will now display in the listing table for the cluster.

NOTE: Existing nodes will retain their numbering once the new node is added.

Add a node via the CLI

SSH onto one of the nodes using the IP address

Run the following command using theprivate IP addresses from the node(s) that will be added to cluster

Separate multiple IP addresses with a space

qq node_add --node-ips PRIVATE_IP

IMPORTANT! It is not recommended to run a Qumulo cluster in AWS for production data without a replication or backup strategy.

RESOLUTION

You should now be able to successfully add a node to an existing cloud cluster

ADDITIONAL RESOURCES

Qumulo in AWS: Configure IP Failover

Qumulo in AWS: Build a Multi-Instance Cluster with CloudFormation

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to aquire a bearer token for authentication with Qumulo's REST API

REQUIREMENTS

IP Address or URL for cluster running Qumulo Core

Utility or method for placing the API call (Curl)

Access to API & Tools page for reference

DETAILS

Qumulo API endpoints can be divided into three categories:

APIs thatdon'trequire any authentication, like /v1/version

A login API at /v1/session/login, which takes a username and password

APIs take a bearer token returned from the /v1/session/login API

When using Qumulos API, you will need to start an authentication session by logging in. Calling the login API gives you a temporary credential called a bearer token, which is sent along with subsequent API calls as proof that you have been authenticated.

NOTE: Non-admin users can login but may not have access to certain endpoints.

ACQUIRE A BEARER TOKEN

You start an authentication session by calling the /v1/session/login API with a valid username and password as outlined in the example below using curl.

curl -k -X POST https://clusterIPorDNSname:8000/v1/session/login -H "Content-Type: application/json" -d '{"username":"user", "password":"SECRET"}'

Output:

{ "bearer_token": "1:ATwAAABlSnp6MVZvUXhRQUViN2RCYUFVZy9zTElBQWFNVEZBYWljME94R3hBSEpPWWtwdVpad2RrQVFBNEtnZmIgAAAAXU/JXGz/syigeb+FQ5zEzmNtk8L8GtaQ0M3UejImW4k=" }

Bearer tokens can also be obtained from using the interactive API available in Qumulo Core.

Login to the Qumulo Core Web UI.

Click on API & Tools. Qumulo's GitHub Open Source Community

Select Get started by logging in beneath the page introduction to expand the Login section under Session Management.

Type in admin for the username value and the assigned password.

Click Try it!

Confirm successful authentication with a 200 OK response code .

Copy the Bearer Tokenvalue from the API Credentials box.

To ensure another user cannot use your login credentials,click the Clear button in the API Credentials box or reload the page.

IMPORTANT! The bearer token is valid for 10 hours and can be used to make API requests. To continue using the API after 10 hours, you must re-authenticate with your username and password to start a new authentication session.

USE THE BEARER TOKEN

Now that you have a bearer token, calls to API endpoints that require authentication can be requested using the token in the request header.

Reference the example below to see how a bearer token is used to list the nodes in a single node cluster.

curl -k GET https://clusterIPorDNSname:8000/v1/cluster/nodes/ -H "Authorization: Bearer 1:ATwAAABlSnp6MVZvUXhRQUViN2RCYUFVZy9zTElBQWFNVEZBYWljME94R3hBSEpPWWtwdVpad2RrQVFBNEtnZmIgAAAAXU/JXGz/syigeb+FQ5zEzmNtk8L8GtaQ0M3UejImW4k="

Output:

{"id": 1, "node_status": "online", "node_name": "music-1", "uuid": "becee591-23bc-4fec-91de-e4c78fab642e", "label": "f4:52:14:2b:40:30", "model_number": "Q0626", "capacity_in_bytes": "25605032656896", "serial_number": "XXX", "mac_address": "XX:XX:XX"}

TIP! In a UNIX shell like bash, assign the bearer token to a variable so that authentication does not require the full token value from the original login request.See the example below where our bearer token is assigned to the q_prodvariable.

$ q_prod="1:ATwAAABlSnp6MVZvUXhRQUViN2RCYUFVZy9zTElBQWFNVEZBYWljME94R3hBSEpPWWtwdVpad2RrQVFBNEtnZmIgAAAAXU/JXGz/syigeb+FQ5zEzmNtk8L8GtaQ0M3UejImW4k="

curl -k GET https://clusterIPorDNSname:8000/v1/cluster/nodes/ -H "Authorization: Bearer $q_prod"

RESOLUTION

You should now be able to successfully authenticate against Qumulo's REST API.

ADDITIONAL RESOURCES

Getting Started with Qumulo Core REST API

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to configure and use Snapshot Policy Replication in Qumulo Core

REQUIREMENTS

Source cluster running Qumulo Core 2.14.0 or later

Target cluster running Qumulo Core 2.13.5 or later

DETAILS

Snapshot Policy Replication enables you to automatically take snapshots of the data in your replication relationship's target directory, ensuring that even if bad data or changes are inadvertently replicated over to the target, a backup snapshot of the valid data remains. Using this feature, you can link up to ten existing snapshot policies to a replication relationship. Onceyou'veestablished the link, replication will take care of the rest by replicating future snapshots taken by those policies to its target directory.

Once each replication job completes, a new snapshot of the target directory is taken to ensure that the data is consistent on both the source and target clusters and that a snapshot history of the file changes exists. You can specify how long you wish to keep the snapshots, either manually or by setting it to use the same expiration as is configured in the snapshot policy.

NOTE: In order to enable Snapshot Policy Replication, you must have at least one snapshot policy for the directory being replicated already configured on your source cluster. See Snapshots: Per-Directory Snapshots for additional information.

Configure Snapshot Policy Replication

Login to the Web UI.

Hover over the Cluster menu on the Source cluster and selectReplication under the Configurations section in the dropdown.

Replication: NFS ID Mapping

ClickCreate Relationship to create a new replication relationship.

Provide the required details for the source and destination directory paths, as well as the destination IP for your replication cluster.

Select the replication mode you wish to enable:

Continuous Replication: use replication without binding it to a specific snapshot policy. See Replication: Continuous Replication with 2.11.2 and above for further details.

Snapshot Policy Replication: configure replication to replicate only snapshots taken based on the policy (or policies) linked. If no new snapshots from the policies are present, replication will take no action.

Snapshot Policy with Continuous Replication: if no new snapshots are discovered, replication will take an on-demand snapshot and replicate it to the target whenever any changes to the source directory have been detected. This option is recommended for most configurations, as it ensures that data is continuously kept up to date on both source and destination clusters.

Select the snapshot policy of your choice in the Policy drop-down.

Specify the desired snapshot expiration for the target.

Same as policy: snapshots on the target cluster will be deleted on the same schedule as configured in the linked snapshot policy.

Never: snapshots will never be deleted on the target cluster.

Automatically after [DURATION]: snapshots will be deleted after the specified amount of time has elapsed.

Link additional snapshot policies by clicking + Link Snapshot Policyand repeat steps 5-7 for up to 10 policies.

ClickAdd Blackout Window if you wish to configure days or times to suspend the replication process.For additional details, check out the Replication: Blackout Windows article.

Enable the Map Local User/Group IDs to Associated NFS IDs option if you wish to replicate files using locally-owned NFS IDs. See the Replication: NFS ID Mapping article for full details.

Confirm the Enabled box is checkedunder Enable Replicationto activate the replication relationship.

ClickSave Relationship.

Login to the the Web UI of your target cluster and click the See details link in the announcement banner to view the Replication page.

Click the Authorize link in the Status column for the relationship to grant it authorization on the Replication page.

Now that the relationship is established, any new snapshots taken by the linked snapshot policies are automatically queued to be replicated to your target cluster and added to the Status column.

View Snapshot Policy Replication Details

Once a Snapshot Policy Replication relationship has been established, you can easily view the snapshots governed and replicated by it from the Replication Relationships table.

Click themenu underneath the Actions column on the replication relationship listing.

Click View Relationship Details tosee the snapshot policies linked to the selected replication relationship.

A list of queued snapshots is provided in the table below the Linked Snapshot Policies. These snapshots are considered locked by the snapshot policy (and thus cannot be deleted). To prevent a specific snapshot from being replicated via the queue, click theRelease... link provided for the snapshot. This removes it from the replication queue but doesnot delete the snapshot itself. Released snapshots can either be manually deleted or automaticallywhen the snapshot expires. NOTE: If the relationship has a lot of data to replicate (i.e., when it's first created and linked to an existing snapshot policy), it may take some time to complete. During this time, additional snapshots may accrue depending on the frequency of your snapshot policy configuration. These snapshots will queue up until they are replicated, at which point they will vanish from the table.

ADDITIONAL CONSIDERATIONS

Snapshot Policy Replication requires the target cluster to be running Qumulo Core 2.13.5 or later for full functionality. It can be enabled in a replication relationship with a target cluster running an earlier version, but its functionality may be limited:

If the target cluster is running Qumulo Core 2.13.0 or 2.13.1, snapshots taken according to a linked snapshot policy will be replicated to the target but not retained past the next successful continuous or policy-initiated replication job.

If the target cluster is running Qumulo Core 2.13.2 through 2.13.4, snapshots taken according to a linked snapshot policy will be replicated to the target and retained according to the target expiration time defined in the replication relationship. However, the name of snapshots on the target will not reflect the source snapshot policys name nor will the creation time of the target snapshots match the creation time of the replicated source snapshot (instead, the creation time of the snapshot will reflect the time its associated replication job finished on the target).

If the target cluster is on release 2.13.5 or later, all Snapshot Policy Replication functionality is available.

Disconnecting a replication relationship will not stop its linked snapshot policy from continuing to take snapshots.

Reversing a replication relationship will unlink any snapshot policies from the now-target relationship. Any snapshots queued for replication will be unlocked as well. These snapshots will retain the expiration policy originally configured at the time they were replicated.

Reversing a relationship from target to source that previously had linked snapshot policies will re-link those snapshot policies, thus also re-locking them. If the snapshot policy was deleted while the relationship was reversed, itwon'tbe re-linked. If all policies have been deleted, the replication relationship will be set back to Continuous Replication.

When linking a snapshot policy, only new snapshots for that policy will be replicated.By the same token, changing the target expiration period of an existing Snapshot Policy Replication relationship applies only to snapshots taken after the configuration change.

RESOLUTION

You should now be able to successfully use Snapshot Policy Replication in Qumulo Core

ADDITIONAL RESOURCES

Replication: Continuous Replication with 2.11.2 and above

Snapshots: Per-Directory Snapshots

Replication: Blackout Windows

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to use failover and failback with Replication in Qumulo Core 2.12.0 and above

REQUIREMENTS

Admin privileges required

Source and target cluster running the same version of Qumulo Core 2.12.0 or above

If you are running a version of Qumulo Core below 2.12.0, check out the Replication: Failover and Failback with 2.11.4 and below article for details on Qumulo's legacy failover/failback UI.

DETAILS

Failover can come in two forms: planned and unplanned. And while everyone would prefer to only encounter the former, Replication makes recovering from either scenario a breeze.

Planned failover: If you're performing a planned failover, set the source directory on the primary cluster to read-only and wait for a new replication job to start and finish (so that no writes are lost). To make sure that a job has finished, first verify that any blackout windows are disabled and then check the relationship's Recovery Point time to verify that it is after the time that you set the directory to read-only. This processensures that the target directory is in a point-in-time consistent state matching the last source snapshot taken.

Unplanned failover: If the last Replication was incomplete before the primary cluster became unavailable, it may have left the target directory in an indeterminate state with some files truncated or otherwise inconsistent.

In either case, you will need to make the secondary target writable in order to continue making write operations.

Failover to the Secondary Cluster

Follow the instructions below to utilize failover with Replication:

In the secondary cluster's Web UI, hover over the Cluster menu and select Replication.

Click the QQ CLI: Replication menu on the Replication Relationship listing.

Select Make Target Writable.

In the resulting dialog, clickYes, Make Target Writable.

Wait for the directory to be reverted to the last recovery point. ClickDetails to monitor progress.

Once the Status field shows the message depicted below, the target directory is consistent and writable.

Migrate any of the following configuration necessary to the secondary cluster if it doesnt already exist:

NFS exports

SMB shares

AD/LDAP server(s)

Snapshot policies

Quotas

Remount all clients previously connected to the primary cluster that require access to the secondary cluster.

You've successfully performed a failover! You now have two failback options:

Resume replication in the original direction: this option resumes replication leaving the original source and target clusters unchanged. This is a good option if you did not make any writes to the cluster during the failover interval. To continue using this path, follow the steps below inFailback: Re-Enable in the Original Direction.

Resume replication in the reverse direction: this option resumes replication using the original target cluster as the new source. This allows you to retain any writes made to the secondary cluster during the failover. To use this path, follow the steps later in this page underFailback: Re-Enable with Reversed Sync.

Failback: Re-Enable in the Original Direction

If you didn't make any writes to the secondary during the failover (or do not wish to retain any writes thatwere made),Replication can be immediately re-established in the original direction and the writes can be discarded.

You may want to do this if you encountered the following:

The primary cluster came back online before client write traffic was redirected to the secondary cluster

The writes to the secondary cluster were done as part of a failover test or disaster recovery readiness test and can therefore be discarded

To re-enable Replication in this case, follow the steps outlined below:

Log into the secondary cluster's Web UI.

Click the menu on the desired relationship listing and select Reconnect Relationship... on the Replication page.

A dialog will display the current and reconnected relationship diagram. To proceed with the reconnection, click Yes, Reconnect.

Replication will take ownership of the directory and sync the current version of the source directory to the target,overwriting any changes on the target directory.

Note: If you are running Qumulo Core 2.12.4 or below, the initial Replication job after reconnecting the relationship will complete a full tree scan in the Replication directories on both sides to ensure the target is brought up to sync. If you are running 2.12.5 and above, the initial Replication job after reconnecting the relationship will bring both sides up to sync without doing a full tree scan. Files that have been replicated successfully and havent changed since the original Replication will not be re-sent.

Failback: Re-Enable with Reversed Sync

If you wish to retain any writes made to your secondary cluster during the failover, you can temporarily reverse the Replication Relationship. This action is initiated on the target cluster and will result in the previous target directory becoming the new source, and the previous source directory becoming the new target. After reversal completes, the relationship will remain disconnected, where Replication will not resume. To resume Replication after reversal, reconnect the relationship from the new target cluster. Keep in mind thatany changes on the primary (new target) that were made after the last successful Replication will be overwritten.

NOTE: Prior to Qumulo Core 2.13.0, this processreset the relationships blackout windows and the map_local_user_ids_to_nfs_ids flag, requiring users to reconfigure them manually after failback before resuming replication. In version 2.13.0 or higher, these options are restored to their original configuration after failback, so they do not require manual user intervention.

Optional:If you wish to save the data that was written to your primary cluster but not replicated before the primary went down, please take the following steps before you re-enable with reversed sync:

Take a manual snapshot of the affected directories. See our Snapshots: Deep Dive article for more details.

Useqq snapshot_diff to compare the manual snapshot with the last replicated snapshot. (You can find the last replicated snapshot by using qq snapshot_list_snapshots.)

Move the files that were altered since the last fully-replicated snapshot to a different directory (outside of the Replication process).

Once the data has been saved, follow the instructions below to utilize failback with Replication:

Log into the secondary cluster's Web UI.

Hover over the Cluster menu and select Replication on the target cluster.

Click the menu in the Replication Relationship listing.

Select Reverse Relationship....

Enter the IP address and port number of the primary cluster in the Reverse Relationship form.

Click theReverse Relationship button.

Switch to the primary cluster's Web UI. A relationship listing in the reverse direction should be present and show as disconnected.

Still in the primary cluster's Web UI, click the menu and select Reconnect Relationship.

Click Yes, Reconnectto begin replicating from the secondary cluster to the primary cluster.Note:In Qumulo Core 2.12.4 or below, this initial Replication job may take some time; it can vary based on the size of your filesystem. If you are running 2.12.5 or above, the job can take some time depending on the amount of changes made on your filesystem since the last successful Replication. In either case, wait for it to complete so that Replication jobs are shorter before proceeding to the next step.

Discontinue writes to the source directory on the secondary cluster.Note: Click the menu and selectSet Source Directory Read-only... if you are runningQumulo Core 2.12.2 and above.

Start and complete a final Replication job. The final Replication job prior to the cutover should be as small as possible to minimize the duration that no I/O will be allowed into the directory.

Now that the data has been copied to the primary target, you can continue using this new replication relationship, or you can re-establish the original Replication direction.

To re-establish Replication:

In the Web UI, hover over the Cluster menu and select Replication on the primary cluster.

Click the menu and select Make Target Writable to prepare for reversing the relationship again.

Once the relationship is disconnected, click the menu and select Reverse Relationship to make the primary cluster become the source cluster.

Switch to the secondary cluster's Web UI and find the reversed relationship listing in the original direction.

Re-configure your original blackout windows andMap Local User/Group IDs to associated NFS IDs configuration in the relationship (if used).

Click the menu and select Reconnect relationship.

Remount all clients previously connected to the secondary cluster that require access to the primary cluster.

RESOLUTION

You should now be able to successfully utilize failover and failback with Replication in Qumulo Core 2.12.0 and above

ADDITIONAL RESOURCES

Replication: Failover and Failback with 2.11.4 and below

Replication: Continuous Replication with 2.11.2 and above

Replication: Version Requirements and Upgrade Recommendations

Snapshots: Deep Dive

Like what you see? Share this article with your network!

Below you'll find an example of how to serve Active Directory AutoFS maps to Linux clients bound to AD via SSSD. Keep in mind that this is for informational purposes only and is not specific to Qumulo. We do not guarantee the same level of support for the actions outlined below as we do for other features specific to Qumulo Core.

IN THIS ARTICLE

Outlines how to use Active Directory to serve AutoFS maps to Linux clients bound to AD via SSSD

DETAILS

In the example below, we will create an autofs map pointing to the NFS export "tools"from the server qumulo-cluster. This mount point will be available on the Linux clients via automounter at /tools/tools

The example below was tested with Active Directory 2012R2, CentOS 7 and Ubuntu 16.04 and assumes that the Linux client is already successfully bound to Active Directory via SSSD and realmd.

Create the automapper container and the base auto.master object

Use ADSI Edit for the following steps.

Create a new Organizational Unit to store the automapper information.

In this example the OU automapper was created in the root of the Domain

Right click on the automapper OU and create new Object of the type nisMap with the following attributes:

cn = auto.masternisMapName = auto.master

Click finish

Create a pointer object and a map file

Right click once more on automapper and create a second Object of the type nisMap with these attributes:

cn = auto.toolsnisMapName = auto.tools

Click finish

Right click in the auto.tools CN and create and Object of the type nisObject with these attributes:

cn = toolsnisMapName = auto.toolsnisMapEntry = -fstype=nfs qumulo-cluster:/tools

Click finish

To create the mountpoint pointer object, right click on auto.master and create Object of type nisObject with the following attributes:

cn = /tools/nisMapName = auto.masternisMapEntry = auto.tools

The second / is important in cn = /tools/

Parent container of the CN is nisMapName = auto.master

Map is stored in nisMapEntry = auto.tools

NOTE: It is good practice to create one auto.**** CN per mount point, but each mount point CN can have multiple CNs pointing to other exports. For example, we could create a second CN inside of auto.tools pointing to another NFS export in our root domain and these would all be listed via the single CN=/tools/ entry in auto.master.

AutoFS maps for Kerberized SMB mounts (Single Sign On)

In this example we are creating an autofs map called "auto.smb" for a Linux mount point "/smb" which will mount the smb share "smb" being shared by Qumulo cluster "qumulo-cluster"

Note: The initial set up of theautomounter OU and theauto.master entry is the same as the NFS example shown above.

Create an object of "nisMap" type named "auto.smb" inside of the "automapper" OU with the following entries:

cn = auto.smbnisMapName = auto.smb

Right click on the newly created "auto.smb" object and create a new object of the type "nisObject" with the following entries:

cn = smbnisMapName = auto.smbnisMapEntry = -fstype=cifs,vers=2.1,rw,user=$USER,cruid=$USER,sec=krb5,uid=$UID,gid=10000 ://qumulo-cluster/smb

Note: The "gid" value is optional, and will grant any other logged in users the same access level available to that Group assigned to that gidNumber. This might be considered a security liability in some environments.

Right click on the "auto.master" entry and add an object of the "nisObject" type with the following entries:

cn = /smb/nisMapName = auto.masternisMapEntry = auto.smb

Note: The trailing"/" in thecn entry is required.

Prepare Linux Client

In/etc/nsswitch.confappend or create this line:

Automount: files sss

In/etc/sssd/sssd.confmodify this line under the [sssd] section to look like the following:

services = nss, pam, autofs

Add the following empty section below [sssd]:

[autofs]

Add the following lines to the end of your [domain\yourdomain] section:

autofs_provider = adldap_autofs_entry_key = cnldap_autofs_entry_object_class = nisObjectldap_autofs_entry_value = nisMapEntryldap_autofs_map_name = nisMapNameldap_autofs_map_object_class = nisMapldap_autofs_search_base = ou=automapper,dc=yourdomain,dc=com

Note: Replace the bold items with your environment's items

Delete the SSSD cache:

rm -rf /var/lib/sss/db/*

Restart SSSD and autofs:

service sssd restartservice autofs restart

Test that autofs can read maps from Active Directory:

automount -m

Sample Output:

autofs dump map information =========================== global options: none configured Mount point: /tools/ source(s): instance type(s): sss map: auto.tools tools | -fstype=nfs qumulo-cluster:/tools

You should now be able to cd to /tools/toolsto trigger the automount.

RESOLUTION

You should now be able to successfully serve Active Directory AutoFS maps to AD bound Linux clients with SSSD

ADDITIONAL RESOURCES

Join your Qumulo Cluster to Active Directory

QQ CLI: Active Directory

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to add a Qumulo series node to an existing Qumulo on-premise cluster.

REQUIREMENTS

Cluster running Qumulo Core

New QC series, Qumulo P-series, or Qumulo K-series node on site

DETAILS

Once installed and racked, the process of adding a new Qumulo node is incredibly straightforward. Your existing cluster will auto-discover the new unconfigured node and prompt you to add it in the UI of Qumulo Core.

INSTALL & RACK YOUR NEW NODE

Reference the corresponding Quick Start Guide below for details on installing and racking the new node:

Quick Start Guide: QC Series 1U

Quick Start Guide: QC Series 4U

Quick Start Guide: Qumulo K-Series 1U

Quick Start Guide: Qumulo P-Series 2U

UPDATE IP ADDRESSES

Before adding a node, ensure that the quantity of persistent (static) IPs available is equal to or greater than the number of nodes you plan to have in your cluster. You will not be able to add a new node to your cluster if there are not enough static IPs available. Reference the IP Failover with Qumulo Core article for additional details on how to update the IP addresses.

JOIN THE NEW NODE TO YOUR EXISTING CLUSTER

Before joining the node to the cluster, ensure the new node is powered on, running the same version of Qumulo core, and connected to the network.

Login to the Qumulo Core Web UI.

Hover over Cluster and select Add Nodes. IP Failover with Qumulo Core

Select the unconfigured nodes in the table to add to the existing cluster.

Click Add Selected Nodes to Cluster.

Select Yes to confirm the addition of the selected node(s).

A dialog box appears as the node(s) are configured and added to the cluster.

Once the new node is configured and added, the Cluster Overview page will appear with a successful confirmation banner at the top. The Usable storage calculation will update with the additional capacity and the newly-configured node will now display in the listing table for the cluster.

NOTE: Existing nodes retain their numbering once the new node is added.

If no unconfigured nodes are discovered, the following message will display on the Add Nodes page.

Make sure the new nodes are powered on, running the same version of Qumulo Core as existing nodes and connected to the network.Reference Qumulo Core Upgrades via Web UI for additional details on updating versions or email [email protected] for assistance.

RESOLUTION

You should now be able to successfully add a new Qumulo series node to your existing Qumuloon-premise cluster.

ADDITIONAL RESOURCES

Quick Start Guide: QC Series 1U

Quick Start Guide: QC Series 4U

Quick Start Guide: Qumulo K-Series 1U

Quick Start Guide: Qumulo P-Series 2U

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to utilize Qumulo's REST API and 'qsplit'to reduce the time to migrate or replicate data from one cluster to another

REQUIREMENTS

Cluster running Qumulo Core

Command line (CLI) tools installed via API & Tools tab

PROCESS

Migrating and replicating data between storage clusters can be very time-consuming, especially if the data includes deeply-nested objects or large amounts of data. In addition, it can sometimes be slow for replication tools to crawl deep folder hierarchies in order to determine which files have changed, and tools such as rsync can take many hours to synchronize terabytes of data between clusters.

The qsplit sample on GitHub uses the Qumulo REST APIs with some associated instructions to drastically reduce the amount of time needed to migrate or replicate data from one Qumulo cluster to another.You can find the sample here:

Github Qumulo qsplit

Heres a brief description of Github Qumulo qsplit including what it does and how it can be used.

Test Environment

Our source cluster is 4 QC26s i.e. our small model."On the source cluster we used a source path with thousands of small to medium files in a fairly deep hierarchy about 1.5 Tb of data.Our target cluster is 4 QO626.

In addition, four client machines were used with discrete NICs for the rsync work. We could have run separate rsync processes locally or spun up VMs instead for this purpose, but for the experiment our team wanted discrete physical NICs in order to do the transfer. On each client machine we mounted the source cluster and source path and destination path from the target cluster, as well as a share on the source cluster to access the generated bucket file needed by each process.

Use Case

The primary use case for qsplit is to optimize migration of data from a Qumulo cluster by using Qumulo's analytics APIs.

OptimizedMigrationusingdiraggregates/RESTAPIApproach:

Divide a qumulo cluster into N equal partitions(a list of paths). The partitioning is based on the block count, which is obtained from:

fs_read_dir_aggregates

Feed each partition to an rsync client. As an example, you can run the command:

./qsplit.py --host music /music/ --buckets 4

This will create four 'bucket files' (a list of file paths using naming convention) for host 'music' and path '/music/' on the client. See example below where 'n' is # from 1..[# of buckets specified, above it is four]:

qsync_[YYYYMMDDHHMM]_bucket[n].txt

If you do not specify a '--buckets' param it will create a single bucket with all of the file paths for the specified source and path.

Once the files are created you can copy them to different machines/NICs to perform rsyncs in parallel. You could also run the rsyncs on a single machine with separate processes but you'd likely bury the machine NIC with traffic that way.

Copy the results of qsplit/ text files to somewhere client machines can resolve them

ssh to [n] different client machines with separate NICs

Mount the cluster [src] and [dest] on each machine

Oneachmachinerunrsyncinthefollowingfashion:

rsync -av -r --files-from=qsync_[YYYYMMDDHHMM]_bucket[n].txt [src qumulo cluster mount] [target cluster mount]

NOTE that the file paths in the bucket text files are all relative to the path specified when running qsplit. So if you created file paths for '/music/' then that should be your [src cluster mount] point so that the relative file paths can resolve.

Usingtheaboveapproachyoushouldseeasignificantperformanceimprovementoverrunningrsyncinthetraditionalway:

rsync -av -r [src] [dest]

The performance improves for two reasons:

No file crawl needed by rsync because we're passing a filespsec in --files-fromrunning multiple instances of rsync in parallel

In addition by running each instance on a different client machine we avoid burying the NIC for a single machine and keep things nice and busy/active.

Results

We saw about 10x performance improvement over traditional rsync write throughput: 219 MBs vs 19.7 MBs (~ 50 MBs attributable to --files-from option) which is quite a gain over traditional rsync src dest usage. Part of this is attributable IMO to using the files-from option with rsync and discrete file paths, obviating the need for a file crawl. But most of it is due to parallelizing the transfers.

The total transfer time was less than 2 hours for 1.5TB of data. In comparison, I ran rsync the traditional way (rsync src dest) between the same clusters without any file specs or files-from list. It ran overnight and had still not finished when I stopped it.

Using qsplit with tools such as rsync can enable parallelized migration and synchronization from Qumulo clusters to other clusters. We saw great improvement even by splitting the work up into four non-overlapping, equally-sized sets of files, and by avoiding tree crawls for things like change notification. We can also greatly improve the performance of replication scenarios thanks to the Qumulo REST APIs.

RESOLUTION

You should now be able to successfully utilize Qumulo's REST API and qsplit to decrease your migration time and improve the performance of replication scenarios

ADDITIONAL RESOURCES

QQ CLI: Comprehensive List of Commands

Github Qumulo qsplit

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to create NFS Exports with multiple IP restrictions and user mappings

REQUIREMENTS

Cluster running Qumulo Core version 2.7.8 and above to provide a restrictions JSON file.

Cluster running Qumulo Core version 2.12.6 and above for the nfs_mod_export_host_access command

Command line (CLI) tools installed via API & Tools tab

GLOSSARY

UID: User Identity Number (uidNumber) used to identify NFS users

GID: Group Identity Number (gidNumber) used to identify NFS user groups

Host: The IP address of the system running the NFS client software connecting to the Qumulo File System

Subnet: A network segment encompassing multiple hosts

Export: An NFS access mount point to the Qumulo File System as defined by the Qumulo administrator

DETAILS

IP RESTRICTIONS

IP restrictions allow access control to a particular NFS export to only the IP addresses of the hosts on an access list. A range of IP addresses or entire subnets can be specified in the access list and any connection attempts coming from an IP address not covered in the access list will be denied access.

The IP restrictions will be enforced in the order they are written from top to bottom. Once a condition is met then that rule is applied. Be aware of this behavior as you create your list of rules. To prevent unintended results, list IP-specific rules at the top of the list and Subnet-wide rules at the bottom.

USER MAPPING

User Mapping (or User Squashing) is the process of converting the incoming UID of an NFS user into the UID Number specified in the NFS export's settings. When NFS operations are performed on an export with User Mapping enabled, those operations will be performed as the UID/GID specified in the export's settings.

User Mapping is possible for two types of users:

Root or UID 0

All other users / UIDs

Note that Root or UID 0 is the only individual user to whom specific rules can be applied. Every other non-Root UID will be handled by the All set of rules. Using the All value in the user_mapping key, all non-root incoming UID values will be remapped to the desired UID/GID value to ensure consistent file ownership.

ROOT SQUASHING

Whenever an NFS user is logged in as local Root or performs a file operation as a sudoer, UID 0 is sent over NFS as the user identity. This would normally grant the NFS user the same rights as the local Qumulo Admin including the ability to read, delete and modify any object in the File System.

Root Squashing is enabled via the root or 0 value in the user_mapping key. With Root Squashing, this UID is remapped to the desired value to prevent unauthorized root access to an NFS Export, to specific Hosts and Subnets or to ensure consistent file ownership.

Through using IP restrictions, it is possible to create a list that allows specific Hosts to act as Root/Sudoers while restricting all other Hosts.

QQ COMMANDS

The following QQ commands are available to manage NFS exports via the Qumulo API:

Command

Description

qq nfs_add_export

Add a new NFS export

qq nfs_delete_export

Delete an export

qq nfs_get_export

Get an exports details based on ID

qq nfs_list_exports

List all NFS exports

qq nfs_mod_export

Modify an export (2.7.8 or above)

qq nfs_mod_export_host_access

Add, remove, or modify individual host restriction entries (2.12.6 or above)

NOTE: NFS exports with multiple IP and user restrictions applied can only be deleted using the nfs_delete_export --id command.

INSPECT EXPORT RESTRICTIONS

To inspect restrictions from the Qumulo API, use the following qq command:

qq nfs_list_exportsqq nfs_list_exports --export-path /

Example output of qq nfs_list_exports --export-path /:

ID: 1Export Path: /FS Path: /Description: A neat root export.32 bit mode: FalseHost Access:ID Hosts Access Options == ============================ ===================================================1 10.120.252.10 rw, insecure, all_squash, anonlocal=guest 2 10.120.253.20, 10.120.253.21 rw, insecure, no_root_squash 3 10.120.253.0/24 rw, insecure, root_squash, anonuid=994, anongid=994

Note that the option names have been chosen to correspond to equivalent options in a standard /etc/exports configuration. See below for a detailed description of their meanings, also.

Note that, prior to Qumulo Core 2.12.6, this command provided the same information, but formatted it as a JSON object.

MODIFY EXPORT RESTRICTIONS (2.12.6 OR ABOVE)

Note that this command is available in Qumulo Core 2.12.6 and above. For older versions, it is necessary to configure restrictions with a JSON file; see instructions below.

The export restrictions list can be modified with the qq nfs_mod_export_host_access command. This command requires that the export be identified using either the --id or --export-path option, and then a subcommand to add, modify, or remove and entry.

Add a New Entry

The add_entry subcommand will add a new entry, at the specified position. It has the following options, whose names have been chosen to be familiar to those accustomed to /etc/exports:

--hosts 1.1.1.1 fd00:0:0:42::/64

The hosts to which this entry applies. * matches all. May be IP addresses, CIDR masks (e.g. 10.1.2.0/24), or ranges (e.g. 10.2.3.23-47, fd00::42:1fff-c000). Multiple values may be given, separated by spaces.

--insert-after N

Specify which item in the existing list (as displayed in qq nfs_get_export) the new entry should follow. 0 means the beginning of the list. If not specified, the entry is added to the end of the list.

--rw--ro

Specify whether hosts matching this entry should be granted read+write or read-only access. --rw is the default if neither are given.

--no-root-squash--root-squash--all-squash

Specify whether hosts matching this entry should be granted read+write or read-only access. --rw is the default if neither are given.Specify whether, root, everyone, or nobody should be squashed. --no-root-squash is the default if none is given. If --root-squash or --all-squash is specified, the user to map to must also be specified (see below).

--anon-local <username>

Squashed users should be mapped to the local user with the given username. Note that the local guest user is the same as nobody.

--anon-uid ###--anon-gid ###

Squashed users should be mapped to the specified posix UID and GID.

--secure--insecure

Whether or not connections from unprivileged source ports (i.e. those over 1024) are permitted. Note that --secure has little practical security benefit in many environments, and will make access by OSX clients difficult, as they use unprivileged ports by default.

For example, in order to allow read+write access to hosts in the 10.1.42.0/24 subnet with root access squashed to guest (which is the same as nfsnobody):

qq nfs_mod_export_host_access --export-path /export add_entry --hosts 10.1.42.0/24 --root-squash --anon-local guest

Host Access:ID Hosts Access Options == ============ ==========================================1 10.1.42.0/24 rw, insecure, root_squash, anonlocal=guest

Modify an Existing Entry

The modify_entry subcommand can be used to modify any part of an existing entry. The entry to modify is identified by its position, as shown in qq nfs_get_export, which is specified with the --position argument. Otherwise, this command has the same arguments as are given when adding an entry. Any option not specified will be left unchanged.

For example, to broaden the entry created in the previous example to cover all hosts:

qq nfs_mod_export_host_access --export-path /export modify_entry --position 1 --hosts '*'

Remove an Existing Entry

The remove_entry subcommand can be used to remove an entry. The entry to remove is identified by its position, as shown in qq nfs_get_export, which is specified with the --position argument. If the list has only one entry, it is not possible to remove that entry.

For example, to remove the second entry from an exports restrictions:

qq nfs_mod_export_host_access --export-path /export remove_entry -p 2

EXPORT RESTRICTIONS VIA JSON RESTRICTIONS FILE (2.12.5 AND BELOW)

This is the only method available for setting restrictions in Qumulo Core 2.12.5 and before. It works in later versions, but qq nfs_mod_export_host_access should be preferred in most circumstances.

The application of IP restrictions and User mapping rules requires the creation of a JSON file including the following keys to be referenced.

read_only:Input True or false value to determine whether the NFS export is writeable or read-only

host_restrictions: List of IPs and Subnets (individual IPs before subnets) that are allowed access to the export

IPs not covered in any host_restrictions key in the JSON file will be denied access

user_mapping:List of incoming UIDs to be remapped

root - Intercepts only incoming UID 0 and remaps it

all - Every incoming UID will be remapped

none - No UIDs are remapped and only Host restrictions are enforced. If the key value "none" is selected then it is not necessary to add a map_to_user_id key.

map_to_user:Select what user incoming UIDs covered in the user_mapping key will be remapped to. This may be either a local user, or a posix UID. If a UID is given, the map_to_group field must also be specified. This field is a JSON object with the following format:

{"id_type": "LOCAL_USER", "id_value": "<username>"}

{"id_type": "NFS_UID", "id_value": "###"}

map_to_group: Select which posix GID will be applied when the incoming UID is mapped to a posix UID. This field is a JSON object with the following format:

{"id_type": "NFS_GID", "id_value": "###"}

Please note that multiple JSON objects (Groups of complete restriction rules) need to be separated by a comma after the objects closing curly brace as outlined in the example below.

{ "restrictions": [ { "host_restrictions": ["10.120.252.10"], "read_only": false, "user_mapping": "all", "map_to_user": {"id_type": "LOCAL_USER", "id_value": "guest"} }, { "host_restrictions": ["10.120.253.20","10.120.253.21"], "read_only": false, "user_mapping": "none" }, { "host_restrictions": ["10.120.253.0/24"], "read_only": false, "user_mapping": "root", "map_to_user": {"id_type": "NFS_UID", "id_value": "994"}, "map_to_group": {"id_type": "NFS_GID", "id_value": "994"} } ]}

This sample JSON file indicates the following:

Host 10.120.252.10 will have any incoming UID mapped to Local User guest

Host 10.120.253.20 will not be subjected to any UID remapping and use the UID as provided by the NFS client

Subnet 10.20.253.0/24 will have any incoming UID 0 users remapped to UID 994 and GID 994

APPLY THE RESTRICTIONS

Implementing the restrictions to the NFS export(s) can be done in multiple ways. To create an NFS export with restrictions via the API, use the command below.

qq nfs_add_export --export-path / --fs-path / --restrictions /path/to/restrictions.json

To apply a list of restrictions to an existing NFS export, first r etrieve the share ID from the list of exports using the following command:

qq nfs_list_exports

Modify the NFS export using the ID and path to the restricitons.json:

qq nfs_mod_export --id 5 --restrictions /path/to/restrictions.json

The application of a restrictions JSON file requires the use of the qq nfs_mod_export command for 2.7.8 and above. For version 2.7.7 and below, use qq nfs_mod_share to apply the NFS restrictions.

Once the rules have been applied, the JSON file is no longer required and can be deleted or saved elsewhere for your own documentation.

VERIFY NFS RESTRICTIONS

To verify the restriction from an NFS client, use the showmount command below:

showmount -e ip.of.qumulo.node (Or FQDN of cluster)

Example output:

showmount -e 10.120.249.58Exports list on 10.120.249.58:/ Everyone/admin_files 10.220.246.80 10.0.0.0/10/files Everyone/replicate 10.120.253.21 10.120.253.0/24

VERIFY NFS RESTRICTIONS FROM THE QUMULO API

To verify restriction from the Qumulo API, use the following qq command:

qq nfs_list_exports

Example output:

qq nfs_list_exports[ { "description": "", "export_path": "/", "fs_path": "/", "id": "1", "restrictions": [ { "host_restrictions": [], "map_to_user_id": "0", "read_only": false, "user_mapping": "NFS_MAP_NONE" } ] }, { "description": "", "export_path": "/Home", "fs_path": "/users/Home", "id": "7", "restrictions": [ { "host_restrictions": [], "map_to_user_id": "0", "read_only": false, "user_mapping": "NFS_MAP_NONE" } ] }

RESOLUTION

You should now be able successfully create NFS Exports with multiple IP restrictions and user mappings

ADDITIONAL RESOURCES

QQ CLI: NFS Exports

QQ CLI: Admins, Users and Groups

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to deploy an instance of Qumulo in GCP

REQUIREMENTS

Google Cloud Platform (GCP) account

Google Deployment Manager API enabled

GCP account limits large enough for the instances and volumes desired

An SSH key-pair for accessing Qumulo instances via SSH

Google Virtual Private Cloud (VPC) with at least one subnet configured in the target region

Instances on the subnet must be able to access the internet (for example, via a NAT gateway) to support Qumulo's Cloud-based Monitoring

NOTE: Modifying the type or size of the volumes in the Google Marketplace listing will render the software not functional. Please use the default volume configuration available.

DEPLOY AN INSTANCE

Log in to the GCP Marketplace.

Navigate to the Qumulo Listing.

Select the Instance Type you wish to launch and click Launch on Compute Engine. Qumulo in GCP: Upgrade an Unconfigured Node

Fill in the following fields:

Deployment name: input the name of your deployment

Deployment name can only contain lowercase characters, numbers or dashes.

Name must start with a lowercase letter and cannot end with a dash.

The first 15 characters of the deployment name will be used to create a cluster name. If this does not produce a valid NetBIOS name, a default name will be used instead.

The cluster name can be changed after deployment through the Qumulo Web UI.

Instance Count: Enter the number of nodes for the cloud cluster you wish to create

Machine Type: Select the virtual machine type you for each node.

Network: Select the appropriate network selection from the dropdown based on location.

Subnetwork: Select the appropriate subnetwork option from the dropdown based on location.

Public SSH Key: Copy and paste your public SSH key into this field.

Optional configuration settings:

Check the box to Automatically cluster your instances to automatically form a Qumulo cluster in your VPC with the deployed instances.

Check the Protect your Qumulo instances from accidental deletion box to enable deletion protection (Protection=true) and disable auto-deletes (autoDelete=false) for the attached volumes.

Click Deploy.

Once complete, your instance is ready for access via REST, NFS, and SMB using the temporary password provided under Admin password (Temporary). Use the Visit the UI link provided in the Outputs section of the Details view to access the Qumulo Admin Console using admin as the user name and the temporary password provided. Note that the same IP address can be used for NFS or SMB client mount points and REST.

To access the Qumulo Core UI in a browser window, enter https:// followed by the Private IPaddress of the instance listing for any node on the existing cluster.

Note: Qumulo is configured with a self-signed certificate by default which may cause your browser to display a warning. This is normal behavior. A custom certificate can be installed at a later time to avoid the warning if needed.At the warning, select ADVANCED and click Proceedto continue.

Login to the Qumulo Core Web UI with the username admin and the temporary password provided.

IMPORTANT!We highly recommend changing the temporary password by logging into the Qumulo Admin Console, hovering over admin and clicking Change password.

RESOLUTION

You should now be able to successfullydeploy an instance of Qumulo in GCP

ADDITIONAL RESOURCES

Qumulo in GCP: Add a Node to an Existing Cloud Cluster

Qumulo in GCP: Build a Multi-Instance Cluster

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to install a signed valid SSL certificate issued by your Certificate Authority (CA) to your Qumulo cluster

Install the signed SSL Certificate to the cluster

Mac OS X Client Example

REQUIREMENTS

Admin privilegesto your Qumulocluster

SSL Certificate based on your CSR file has been generated by your CA

Reference the article SSL: Generate a Certificate Signing Request for additional details

CA-bundle PEM chainwhich must be ordered in the following format:

$ cat certbundle.pem-----BEGIN CERTIFICATE-----YOUR CERT HERE-----END CERTIFICATE----------BEGIN CERTIFICATE----INTERMEDIATE CA-----END CERTIFICATE----------BEGIN CERTIFICATE-----ROOT CA-----END CERTIFICATE-----

NOTE: In the examples below, sli-q2 is the name of the cluster

PROCESS

Install the signed SSL Certificate

Verify that the certificate and ca-bundle are in PEM formats:

$ file *certbundle.pem: PEM certificateprivate.key: PEM RSA private key

If your key is not an RSA key, you can convert it with the following command:

$ file original.keyoriginal.key: ASCII text$ openssl rsa -in original.key -out private.keywriting RSA key$ file private.keyprivate.key: PEM RSA private key

Logged in as admin, install the certificate using the following qq command:

qq ssl_modify_certificate

See example below:

[~/qumulo_api]$ ./qq --host sli-q2 login -u adminPassword:[~/qumulo_api]$ ./qq --host sli-q2 ssl_modify_certificate -c certbundle.pem -k private.keynull

Mac OS Client Example of importing a CA Cert

Open Keychain Access

Select Login and click Certificates

Drag and drop the CA Cert into the list

Get Info on the Certificate to access settings by clicking the "i" button

Choose Always trust in the dropdown for "When using this certificate"

Check the security in your browser to verify installation

NOTE: Restart your browser to ensure changes take effect

Insecure

Secure

QQ CLI: LDAP and Certificates

RESOLUTION

You should now be able to successfully install a signed SSL Certificate issued by your CA to your Qumulo cluster

ADDITIONAL RESOURCES

SSL: Generate a Certificate Signing Request (CSR)

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to join a Qumulo cluster to Active Directory

REQUIREMENTS

Cluster running Qumulo Core

Details for your domain including Domain name, Domain username, and Domain password

NOTE:Qumulo Core only supports joining a cluster to one Active Directory Domain.

PROCESS

Login to the Qumulo Core Web UI

Hover over theClustermenu and click Active Directory under Authentication and Authorization QQ CLI: Active Directory

Fill in the following mandatory fields:

Domain Name: name of your domain. Example: ad.example.com

Domain Username: the user account or service account you will use to authenticate against the domain

Domain Password: the password for the user account or service account

Fill in the following two optional fields:

NetBIOS name: This is the first portion of the fully qualified domain name. If your Qumulo cluster name is Qumulo and you are joined to the ad.example.com domain, then your NetBIOS name will be Qumulo.

Organizational Unit (OU): If known, this information can be entered and can normally be obtained from your Systems Administrator. If unknown, leave it blank and Qumulo will attempt to join the domain without an OU specified.

Click theYes button to use your AD as your primary time server

Select the option to use Active Directory for POSIX attributes:

Use in environments where 'user objects' in Active Directory are assigned UNIX UID and GID attributes to allow the cluster to properly enforce permissions regardless of the protocol used to access the data

For additional details, see the Using Active Directory for POSIX attributes article

If desired, enter your Base DN(s) in the field provided

Click Join

RESOLUTION

You should now be able to successfully join your Qumulo Cluster to Active Directory

ADDITIONAL RESOURCES

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how toconfigure LDAP in Qumulo Core

REQUIREMENTS

Cluster running Qumulo Core 2.12.1 or later

PROCESS

Enable Qumulo's LDAP service to manage file permissions and reference user UID and GID information in Qumulo Core.

Login as the Qumulo admin account.

Hover over the Clustermenu in the Web UI and click on LDAP. SSL: Install a Signed SSL Certificate

Click Editon the LDAP Configuration screen.

ClickYes underUse LDAP features.

Fill in the following details:

LDAP URI: the URI for the LDAP server.

Base DN: the Distinguished Name from which the LDAP server searches for users.

Bind Username: the username used to log into LDAP services. Note that the username provided must have permission to search within the provided DN.

Bind Password: the password for the username provided.

Encrypt Connection: whether you wish encryption to be used.NOTE:By default, Qumulo requires an encrypted connection to connect to LDAP (either ldaps or startTLS). Disable this option to connect without TLS, potentially exposing credentials over the network.

Specify whether your LDAP deployment uses encryption with the Encrypt Connectionoption. By default, this is enabled.

Click Save.

NOTE: To use encrypted connections, you must install a valid certificate for your LDAP server. See the SSL: Install a Signed SSL Certificate article for additional details.

RESOLUTION

You should now be able to successfully configure LDAP in Qumulo Core.

ADDITIONAL RESOURCES

QQ CLI: LDAP and Certificates

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to connect to multiple networks in Qumulo Core

REQUIREMENTS

Qumulo Core 2.5.2 or above

Command line (CLI) tools installed via API & Tools tab

PROCESS

A Qumulo cluster can be connected to multiple virtual networks using VLAN tagging. In order to configure and manage multiple networks, you will need to use the QQ CLI or the REST API to view and manage multiple networks.

Each node has a single interface labeled bond0 that uses two physical ports that are bonded using either active_backup or LACP. When you create a cluster, networking configurations include:

A single network (named Default") configured with DHCP that uses this bond

A single default gateway that is associated with the bond

You'll need to change some of the default network settings if you're starting from a cluster with the default DHCP configuration. If you've already set up a single static network, you can skip to step 3.

Step 1

Assign a default gateway (if you're in a routable network) by modifying the interface:

qq network_mod_interface --default-gateway 172.16.123.2

Step 2

Set the Default network to use STATIC addressing rather than DHCP:

qq network_mod_network --network-id 1 --assigned-by STATIC --ip-ranges 172.16.123.128-131 --floating-ip-ranges 172.16.123.132-140 --netmask 255.255.255.0 --dns-servers 172.16.123.1 --dns-search-domains qumulo.com

Once you apply this configuration, youll need to log back in using one of the assigned IP addresses

Step 3

Add an additional network:

qq network_add_network --name example --ip-ranges 192.168.0.10-14 --floating-ip-ranges 192.168.0.15-25 --netmask 255.255.255.0 --dns-servers 8.8.8.8 --dns-search-domains qumulo.com --mtu 1500 --vlan-id 200

Floating IPs can only be added in addition to persistent IPs (specified with --ip-ranges) and must be on the same network

If you want to create multiple IP ranges or DNS servers, you'll need to specify the argument multiple times like the example below:

--floating-ip-ranges 192.168.0.15-25 --floating-ip-ranges 192.168.0.35-45

You should now have two networks configured and can repeat the process above to add upto 4096 networks in Qumulo Core.Client machines can mount over SMB or NFS to any of the assigned IP addresses (persistent or floating), and administrators can use any of the IPs for cluster management.

qq network_list_networks[ { "assigned_by": "STATIC", "dns_search_domains": [ "qumulo.com" ], "dns_servers": [ "172.16.123.1" ], "floating_ip_ranges": [ "172.16.123.132-140" ], "id": 1, "ip_ranges": [ "172.16.123.128-131" ], "mtu": 1500, "name": "Default", "netmask": "255.255.255.0", "vlan_id": 0 }, { "assigned_by": "STATIC", "dns_search_domains": [ "qumulo.com" ], "dns_servers": [ "8.8.8.8" ], "floating_ip_ranges": [ "192.168.0.15-25" ], "id": 2, "ip_ranges": [ "192.168.0.10-14" ], "mtu": 1500, "name": "example", "netmask": "255.255.255.0", "vlan_id": 200 }]

To view which IP addresses are assigned to each node, use the following command:

qq network_poll

Viewing and managing multiple networks is not supported in the UI. Once you have multiple networks configured, youll see this banner in the Network Configuration page.

Configuring LACP

NOTE:It is possible to have different MTUs for each VLAN as long as the MTU of the Default VLAN has a value that is equal to or greater than the MTU of all VLANs. Use the following command to set the MTU of the Default VLAN:

sudo qq network_mod_interface --mtu xxx

Once configured, other networks may be assigned an MTU speed that is of equal or smaller value.

RESOLUTION

You should now be able to connect to multiple network in Qumulo Core

ADDITIONAL RESOURCES

Video: Network Configuration

QQ CLI: Networks and IP Addresses

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to check the balance of client connections across your Qumulo cluster

REQUIREMENTS

Cluster running Qumulo Core

Command line (CLI) tools installed via API & Tools tab

DETAILS

For optimal performance, it's important that client connections are evenly distributed across your cluster. To check the balance of client connections on your Qumulo cluster, run the following qq command:

qq network_list_connections

Sample output:

admin@music-4:~$ qq network_list_connections[ { "connections": [ { "network_address": "10.120.248.157", "type": "CONNECTION_TYPE_SMB" },{ "network_address": "10.116.100.79", "type": "CONNECTION_TYPE_NFS" } ], "id": 1 },

NOTE: The output will include the IP address of the client and the protocol the client has connected over

To get a condensed, human readable version of the of the output you can run:

qq network_list_connections --counts

Sample output:

admin@arrakis-1:~$ qq network_list_connections --countsTotal: SMB 70 NFS 30Node1: SMB 17 NFS 8Node2: SMB 17 NFS 7Node3: SMB 18 NFS 6Node4: SMB 18 NFS 9

Using the --counts option will return only the number of SMB and NFS connections to each node without the client IP addresses.

RESOLUTION

You should now be able to successfully check the balance of client connections across your cluster

ADDITIONAL RESOURCES

Video: Network Configuration

QQ CLI: Networks and IP Addresses

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to set a custom MTU size to configure your cluster to utilize jumbo frames

REQUIREMENTS

Cluster running Qumulo Core

IMPORTANT! The suggested values of 1500 and 9000 do not include the packet overhead.Packet drop, fragmentation, or service disruption can occur if you choose an MTU that is incompatible with your networking environment. Please consult your Network Administrator before making any changes to the MTU value.

DETAILS

Qumulo Core provides the ability to setcustom TCP Maximum Transmission Unit (MTU) sizes to configure jumbo frames in the Web UI.

Login to the Web UI

Hover overCluster and selectNetwork Configuration in the dropdown

QQ CLI: Networks and IP Addresses

Click Switch to Static IP

NOTE: Custom MTUs can only be set if Static IPs are used so Switch to Static IP in your Network Configuration if needed for configuration.

Adjust the MTU size based on your networking environment

Presets for 1500 and 9000 (Jumbo Frames) MTUs are provided as well as the option for custom MTU in theCustom box.

ClickSaveonce the desired value has been set

The changes will be propagated throughout the cluster and you will be returned to the Network Configuration screen. Note that you may need to re-login for changes to take effect.

RESOLUTION

You should now be able to successfully configure your cluster to use jumbo frames by adjusting the MTU accordingly

ADDITIONAL RESOURCES

Video: Network Configuration

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to enable IP Failover in Qumulo Core

REQUIREMENTS

Cluster running Qumulo Core

Command line (CLI) tools installed via API & Tools tab

PROCESS

IP Failover is a high-availability feature that allows a node's virtual IP address(es) to be reassigned to other nodes in the cluster should a node go offline for any reason.

In addition to the fixed IP range assigned to a cluster, an administrator can set a floating range of addresses that can be reshuffled amongst online nodes as necessary. When using IP Failover, it is recommended that the cluster's client-facing DNS record be pointed at these floating IPs as opposed to the fixed range.

For example, in a BIND zone, your records may look something like this where 10.101.1.201-204 is the floating range:

QQ CLI: Networks and IP Addresses

Clients mount the cluster using the Qumulo hostname:

mount -t nfs -o rsize=524288,wsize=524288 qumulo:/production/ /production

In a node outage scenario, any IP in the floating range that was assigned to the offline node would move to another available node ensuring that connected clients can continue writing and reading to/from the cluster. Typically the time it takes to fail an IP over to another node will cause only a momentary blip in any running workloads.

Please note that certain connections like SMB will have to re-connect, as they require a new TCP connection. However, the failover is fast enough that most operating systems' retry mechanism can handle it.

You can use the Qumulo Core Web UI or the CLI to set up IP Failover on your Qumulo cluster.

WEB UI

Log in to your cluster's Web UI as 'admin'.

Hoverover the Cluster menu and selectNetwork Configuration.

On the Network Configuration page, click on Edit Static Settings.

In the fields for Persistent IPv4 Addresses and Floating IPv4 Addresses, enter your fixed and floating ranges.

Click Save.

QQ CLI

Using a node's IP address, ssh to the cluster as admin.

ssh [email protected]

Login as root.

sudo -s

Run the following qq command replacing the IP range with your preferred floating range.

qq network_conf_mod --floating-ip-ranges 10.100.1.201-204

Note:We recommendassigning enough floating IP addresses so that each node will have the total number of nodes minus one for the number of floating IP addresses (up to 10 per node). The math to use is (N-1)*N where N is the total number of nodes in the cluster. Assuming many client connections, this best practice could help evenly distribute the connections from the lost node onto the remaining nodes as needed. For example, in a 4 node cluster when 1 node goes offline, its 3 virtual IPs would then float to each of the remaining 3 nodes.

RESOLUTION

You should now be able to successfully configure IP failover in Qumulo Core

ADDITIONAL RESOURCES

Video: Network Configuration

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to move an existing Qumulo cluster to a different network location

REQUIREMENTS

Cluster running Qumulo Core

DETAILS

In the event you need to move your Qumulo cluster to another physical or logical network segment, you will need to clear any existing Static Network settings beforehand to ensure you can create a cluster. Failure to clear these settings prior to moving the cluster will not only prevent the cluster from forming in the new network location, but will block the Web UI and QQ CLI from being reachable. To return the cluster to a healthy state, each individual node would need to be configured via console.

Follow the procedures outlined below via a direct physical console connection to any Qumulo node or via IPMI/ILO remote console session to ensure the transition of your cluster goes smoothly.

Pre-Move Procedure

Log in into the Web UI as Admin via a direct console connection to any node in the cluster at the original network location.

Hover over Cluster and click Network Configuration. QQ CLI: Networks and IP Addresses

Click Switch to DHCP to set the cluster in DHCP mode and disconnect all clients.

Apply your external networking changes / relocate the cluster.

Post-Move Procedure

Log in as Admin to the Web UI via a direct console connection to any node in the cluster at the new network location.

Hover over Cluster and click Network Configuration.

Click Switch to Static IP.

Add your desired network settings for the new location.

Click Saveto set the new network configuration on the cluster.

With these new settings in place, the cluster will form successfully and be accessible to clients in the new network location.

RESOLUTION

You should now be able to successfully move an existing Qumulo cluster to a different network location

ADDITIONAL RESOURCES

Like what you see? Share this article with your network!

IN THIS ARTICLE

Lists the file system and capacity qq commands available in Qumulo Core and their corresponding API action

REQUIREMENTS

Cluster running Qumulo Core

Cluster is in quorum and qfsd process is running on the selected node

The list below reflects the file system and capacity qq commands currently available and can differ between versions ofQumulo Core. Certain commands may require upgrading to a later release to utilize a specific API action.

Command line (CLI) tools installed via API & Tools in the Web UI

Admin privileges on the Qumulo cluster

FILE ANALYTICS OPERATIONS COMMANDS

COMMAND

ACTION

qq capacity_history_files_get

Get historical largest file data

qq capacity_history_get

Get capacity history data

qq current_activity_get

Get current sampled IOP and throughput rates

qq fs_file_samples

Get a number of sample files from the file system

qq fs_get_stats

Get file system statistics

qq time_series_get

Get specified time series data

FILE HANDLING COMMANDS

COMMAND

ACTION

qq fs_acl_explain_chmod

Explain how setting a POSIX mode would affect a file's acl

qq fs_acl_explain_posix_mode

Explain the derivation of POSIX mode from afile's ACL

qq fs_acl_explain_rights

Explain how rights are granted to a user for afile. *Note that this command does not discover the user's groups and related identities when computing rights. To provide this information, use the -g argument.

qq fs_create_dir

Create a new directory

qq fs_create_file

Create a new file

qq fs_create_link

Create a new link

qq fs_create_symlink

Create a new symbolic link

qq fs_create_unix_file

Create a new pipe, character device, block device or socket

qq fs_delete

Delete a file system object

qq fs_delete_tree

Delete a file system tree recursively

qq fs_delete_tree_status

Status of a tree-delete job

qq fs_file_get_attr

Get file attributes

qq fs_file_samples

Get a number of sample files from the file system

qq fs_file_set_attr

Set file attributes

qq fs_file_set_smb_attrs

Change SMB extended attributes on the file

qq fs_get_acl

Get file ACL

qq fs_get_permissions_settings

Get permissions settings

qq fs_list_named_streams

List all named streams on a file or directory

qq fs_modify_acl

Modify file ACL

qq fs_punch_hole

Create a hole in a region of a file. Destroys all data within the hole.

qq fs_read

Read a file

qq fs_read_dir

Read a directory

qq fs_read_dir_aggregates

Read directory aggregation entries

qq fs_remove_stream

Remove stream from a file or directory

qq fs_rename

Rename a file system object

qq fs_resolve_paths

Resolve file IDs to paths

qq fs_set_acl

Set file ACL

qq fs_set_permissions_settings

Set permissions settings

qq fs_walk_tree

Walk file system tree

qq fs_write

Write data to a file

FILE LOCK OPERATIONS COMMANDS

qq fs_list_locks

List file locks held by clients

qq fs_list_lock_waiters_by_client

List waiting lock requests for a particular client machine

qq fs_list_lock_waiters_by_file

List waiting lock requests for a particular files

qq fs_release_nlm_lock

Release an arbitrary NLM byte-range lock range*Only use as a last resort after confirming that the owning process has leaked the lock

qq fs_release_nlm_locks_by_client

Release NLM byte range locks (ALL) held by client*Only use after confirming that the client is dead as a last resort

NOTE: Once you've accessed a node via ssh,you can see the full list of qq commands by running:

qq -h

RESOLUTION

You should now be able to successfully use file system and capacity qq commands to complete specific API actions in Qumulo Core

ADDITIONAL RESOURCES

QQ CLI: Install Command-Line Tools

QQ CLI: Get Started

QQ CLI: Comprehensive list of Commands

Qumulo Core Capacity Trends

Server-Side Tree Delete

Like what you see? Share this article with your network!

IN THIS ARTICLE

Lists the qq commands available for SMB shares in Qumulo Core and their corresponding API action

REQUIREMENTS

Cluster running Qumulo Core

Cluster is in quorum and qfsd process is running on the selected node

The list below reflects the qq commands currently available for SMB shares and can differ between versions ofQumulo Core. Certain commands may require upgrading to a later release to utilize a specific API action.

Command line (CLI) tools installed via API & Tools in the Web UI

Admin privileges on the Qumulo cluster

COMMANDS FOR SMB SHARES

COMMAND

ACTION

qq smb_add_share

Add a new SMB share

qq smb_delete_share

Delete a share

qq smb_get_settings

Get SMB settings.

qq smb_list_share

List a share

qq smb_list_shares

List all SMB shares

qq smb_modify_settings

Set SMB server settings

qq smb_mod_share

Modify a share

qq smb_mod_share_permissions

Modify a share's permissions

NOTE: Once you've accessed a node via ssh,you can see the full list of qq commands by running:

qq -h

RESOLUTION

You should now be able to successfully use qq commands to complete specific API actions for SMB shares in Qumulo Core

ADDITIONAL RESOURCES

QQ CLI: Install Command-Line Tools

QQ CLI: Get Started

QQ CLI: Comprehensive list of Commands

Like what you see? Share this article with your network!

IN THIS ARTICLE

Lists the Active Directory qq commands available in Qumulo Core and their corresponding API action

REQUIREMENTS

Cluster running Qumulo Core

Cluster is in quorum and qfsd process is running on the selected node

The list below reflects theqq commands currently available for Active Directory and can differ between versions ofQumulo Core. Certain commands may require upgrading to a later release to utilize a specific API action.

Command line (CLI) tools installed via API & Tools in the Web UI

Admin privileges on the Qumulo cluster

COMMANDS FOR ACTIVE DIRECTORY

COMMAND

ACTION

qq ad_cancel

Cancel current AD join/leave operation and clear errors

qq ad_clear_cache

Clear the AD ID mapping cache

qq ad_distinguished_name_to_account

Get all account info for a distinguished name

qq ad_expand_groups

Get the SIDs of all the groups (including nested) that the given SIDis a member of

qq ad_gid_to_sids

Get SIDs from GID

qq ad_join

Join an Active Directory Domain

qq ad_leave

Leave an Active Directory Domain

qq ad_list

List Active Directory Configuration

qq ad_name_to_accounts

Get all account info for a sAMAccountName

qq ad_poll

Poll Active Directory Configuration

qq ad_sid_to_account

Get all account info for a SID

qq ad_sid_to_gid

Get GID from SID

qq ad_sid_to_uid

Get UID from SID

qq ad_sid_to_username

Get AD username from SID

qq ad_uid_to_sids

Get SIDS from UID

qq ad_username_to_sids

Get SIDs from an AD username

NOTE: Once you've accessed a node via ssh,you can see the full list of qq commands by running:

qq -h

RESOLUTION

You should now be able to successfully use qq commands to complete specific API actions for Active Directory in Qumulo Core

ADDITIONAL RESOURCES

QQ CLI: Install Command-Line Tools

QQ CLI: Get Started

QQ CLI: Comprehensive list of Commands

Joining your Qumulo Cluster to Active Directory

Like what you see? Share this article with your network!

IN THIS ARTICLE

Lists the qq commands forAdmins, Users and Groups available in Qumulo Core and their corresponding API action

REQUIREMENTS

Cluster running Qumulo Core

Cluster is in quorum and qfsd process is running on the selected node

The list below reflects the qq commands currently available for Admins, Users and Groups and can differ between versions ofQumulo Core. Certain commands may require upgrading to a later release to utilize a specific API action.

Command line (CLI) tools installed via API & Tools in the Web UI

Admin privileges on the Qumulo cluster

COMMANDS FOR ADMINS

COMMAND

ACTION

qq change_password

Change your password

qq login

Log in to qfsd to get REST credentials

qq logout

Remove qfsd REST credentials

qq who_am_i

Get information on the current user

COMMANDS FOR USERS AND GROUPS

COMMAND

ACTION

qq auth_add_group

Add a new group

qq auth_add_user

Add a new user

qq auth_assign_role

Assign a user to a role

qq auth_clear_cache

Clear all cached authorization information

qq auth_delete_group

Delete a group

qq auth_delete_user

Delete a user

qq auth_expand_identity

Find equivalent identities and full group membership.

qq auth_find_identity

Find all representations of a given identifier

qq auth_get_user_defined_mappings

Get the configured set of AD/LDAP static user defined mappings

qq auth_list_group

List a group

qq auth_list_groups

List all groups

qq auth_list_role

List a role

qq auth_list_roles

List all roles

qq auth_list_user

List a user

qq auth_list_users

List all users

qq auth_mod_group

Modify a group

qq auth_mod_user

Modify a user

qq auth_set_password

Set a user's password

qq auth_set_user_defined_mappings

Replace the configured set of AD/LDAP static identity mappings

qq auth_unassign_role

Unassign a user from a role

qq identity_attributes_get

Get attributes related to the given identity.

qq identity_attributes_set

Set attributes related to the given identity.

NOTE: Once you've accessed a node via ssh,you can see the full list of qq commands by running:

qq -h

RESOLUTION

You should now be able to successfully use qq commands to complete specific API actions for Admins, Users and Groups in Qumulo Core

ADDITIONAL RESOURCES

QQ CLI: Install Command-Line Tools

QQ CLI: Get Started

QQ CLI: Comprehensive list of Commands

Creating Qumulo Users and Groups

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to upgrade Qumulo Core via the CLI

REQUIREMENTS

Cluster running Qumulo Core

Clusters running 2.1.1 and above can upgrade via the UI. Reference the article Qumulo Core Upgrades via UI for additional details.

PROCESS

Upload the upgrade file qumulo_core_x.x.x.qimg to any directory on the cluster via a client protocol like NFS or SMB

Connect to a node via ssh using your IP address:

ssh admin@your_IP_address

Become root by running the following command:

sudo -s

Confirm that the upgrade status is IDLE using the command below:

qq upgrade_status

The output should reflect the following:

{ "blocked_reason": "", "details": "", "error_message": "", "error_state": "UPGRADE_ERROR_NO_ERROR", "install_path": "", "is_blocked": false, "state": "UPGRADE_IDLE"}

Prepare the upgrade by running the following command using the path to the .qimg file you uploaded:

qq upgrade_config_set --path /qumulo_core_x.x.x.qimg --target prepare

Issue the following command to monitor the prepare status:

qq upgrade_status --monitor

Proceed once you see the following output:

UPGRADE_PREPARED

Arm the upgrade to begin the installation using the command below:

qq upgrade_config_set --path /qumulo_core_x.x.x.qimg --target arm

NOTE: You will need to re-login after the upgrade completes and the Qumulo process is restarted.

Check that the upgrade was successful by running the following command and verifying the new version number:

qq version

RESOLUTION

You should now be able to successfully upgrade Qumulo Core via CLI

ADDITIONAL RESOURCES

QQ CLI: Comprehensive List of Commands

Qumulo Core Upgrades via UI

Product Releases and Announcements

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to automatically take snapshots on a schedule using the QQ CLI

REQUIREMENTS

Qumulo Core 2.5.2 and above

Command line (CLI) tools installed via API & Tools tab

NOTE: Qumulo Core version 2.6.6 added UI support for creating, editing and deleting Snapshots. See Snapshots: Per-Directory Snapshots for reference.

DETAILS

Below is a list of commands that are available to create and manage snapshot policies:

Create a new snapshot scheduling policy

qq snapshot_create_policy

Delete a single scheduling policy

qq snapshot_delete_policy

List a single policy

qq snapshot_get_policy

List all policies

qq snapshot_list_policies

Modify an existing snapshot scheduling policy

qq snapshot_modify_policy

Each policy can specify the interval to take the snapshot (hourly_or_less, daily, or monthly) and the expiration rule. As an example, lets create a new policy called every_day" that takes a daily snapshot at midnight Pacific and keeps it for 7 days:

qq snapshot_create_policy daily --name every_day --time-to-live 7days --timezone America/Los_Angeles --days-of-week all --at 00:00

The command above will result in the following output:

{ "id": 1, "name": "daily_1", "schedules": [ { "creation_schedule": { "frequency": "SCHEDULE_DAILY_OR_WEEKLY", "hour": 0, "minute": 0, "on_days": [ "SUN", "MON", "TUE", "WED", "THU", "FRI", "SAT" ], "timezone": "America/Los_Angeles" }, "expiration_time_to_live": "7days", "id": 1 } ], "source_file_ids": [ "2" ]}

Note that the time zone field uses a location description from the INIA database. If no time zone is specified, the snapshot schedule will be in UTC. Heres some examples of valid time zones:

America/New_York

America/Chicago

America/Denver

America/Phoenix

America/Los_Angeles

Now lets create an hourly policy, that is only triggered during business hours (Monday-Friday, 8am-6pm Pacific) where the snapshots are kept for 2 days.

qq snapshot_create_policy hourly_or_less --name hourly --timezone America/Los_Angeles --days-of-week MON,TUE,WED,THU,FRI --start-time 08:00 --end-time 18:00 --period 1hours --time-to-live 2days

Running the above command will result in the output below:

{ "id": 5, "name": "Hourly", "schedules": [ { "creation_schedule": { "fire_every": 1, "fire_every_interval": "FIRE_IN_HOURS", "frequency": "SCHEDULE_HOURLY_OR_LESS", "on_days": [ "MON", "TUE", "WED", "THU", "FRI" ], "timezone": "America/Los_Angeles", "window_end_hour": 18, "window_end_minute": 0, "window_start_hour": 8, "window_start_minute": 0 }, "expiration_time_to_live": "2days", "id": 1 } ], "source_file_ids": [ "2" ]}

RESOLUTION

You should now be able to successfully schedule snapshots using the QQ CLI

ADDITIONAL RESOURCES

Video: Create a Snapshot

QQ CLI: Snapshots

INIA database

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how toset an expiration at a specified time to automatically delete a snapshot

REQUIREMENTS

Qumulo Core 2.5.1 or above

Command line (CLI) tools installed via API & Tools tab

NOTE: Qumulo Core version 2.6.6 added UI support for deleting snapshots. See Snapshots: Per-Directory Snapshots for reference.

DETAILS

When you create a snapshot via the qq CLI, you can specify eitherthe time to live or the time (in UTC) at which to delete the snapshot.

Heres an example of creating a snapshot that expires on January 31, 2017 at midnight UTC:

qq snapshot_create_snapshot --expiration 2019-12-31T00:00:00Z

The output of the command will result in:

{ "created_by_policy": false, "directory_name": "1_OnDemand", "expiration": "2019-12-31T00:00:00Z", "id": 1, "in_delete": false, "name": "", "source_file_id": "2", "timestamp": "2019-10-30T15:44:03.206581208Z"}

Below is an example of creating a snapshot that expires in one year:

qq snapshot_create_snapshot --time-to-live 12months

The outputwill include a timestamp correlating to the specified time to live:

{ "created_by_policy": false, "directory_name": "2_OnDemand", "expiration": "2020-10-30T15:45:55.03510729Z", "id": 2, "in_delete": false, "name": "", "source_file_id": "2", "timestamp": "2019-10-30T15:45:55.035125376Z"}

NOTE: All times are expressed in UTC.

If youdon'tspecify an expiration time or time to live, the snapshot will never be automatically deleted.

To change or remove the expiration on existing snapshots, you can use the snapshot ID from the UI. Note that the snapshot ID is the five digit number that is featured at the beginning of the path string (ex.63040_test homedir_test).

Use the specific Snapshot ID with the command:

qq snapshot_modify_snapshot

For example, to set the snapshot to never expireyou would use the following command:

qq snapshot_modify_snapshot -i SNAPSHOT_ID -e ''

To have the snapshot expire in a specific amount of time in the future (1 hour, 1 month, 1 year, etc), you can use the following command:

qq snapshot_modify_snapshot -i SNAPSHOT_ID -t [months,weeks,days,hours,minutes]

RESOLUTION

You should now be able to successfully set the expiration on a snapshot using QQ CLI

ADDITIONAL RESOURCES

Video: Create a Snapshot

QQ CLI: Snapshots

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to view and recover files using Snapshots via Mac OSX, Windows, or the Linux command line

REQUIREMENTS

Qumulo Core 2.5.0 and above

PROCESS

To recover files from a snapshot, you will need to access a hidden directory called .snapshot from a client mounted over SMB or NFS. From there, you will be able to find the files or directories you need.

NOTE: When mounted over SMB, the .snapshot directory is only available at the root of each share.

Mac OSX Finder

In OSX, you will need to navigate directly to the .snapshot folder to open it.

From the Finder menu, select Go > Go to Folder...

Type in the path as /Volumes/ShareName/.snapshot, where ShareName is the name of the Share youre connected to. Note that the .snapshot directory has to be specified from the root of the share.

Youll now see a list of directories, where the directory name is the snapshot ID and the modified date is the time that the snapshot was taken.

Note: If you have "Show hidden files" enabled in Mac OSX, you will see the .snapshot directory but Finder will not let you open it when clicking on the folder. Youll need to provide the path in the Go to Folder menu as outlined above.

Windows

In Windows 7, 8, and 10 you will need to change your view settings to show the .snapshot directory.

From the Folder Options menu, disable the option "Hide protected operating system files" and enable "Show hidden files, folders, and drives."

QQ CLI: Snapshots

Once you've changed the view settings, you can find the .snapshot directory using Explorer or the root directory:

Explorer: Open the mounted drive

Root directory: Open the .snapshot directory

Linux/Mac command line

In the Linux/Mac CLI, the .snapshot directory will not show up when you list a directory's contents but you can navigate to it explicitly. For example, on a Mac CLI, you would type the following:

cd /Volumes/ShareName/.snapshot

Recover FilesInside the .snapshot directory, each snapshot is shown as a directory with the snapshots ID. The modified time on the directory is the time that the snapshot was taken. Heres an example from Mac OSX Finder:

Open to the desired snapshot's directory

Find the file/directory youd like to restore

Copy it to a new location

RESOLUTION

You should now be able to successfully view and recover files using Snapshots via Mac OSX, Windows, or the Linux command line

ADDITIONAL RESOURCES

Previous Versions in Windows with Qumulo Core

Video: Create a Snapshot

Like what you see? Share this article with your network!

IN THIS ARTICLE

Provides an overview of Qumulo's SSD caching in versions 2.8.4 and below of Qumulo Core

REQUIREMENTS

Cluster running Qumulo Core 2.8.4 and below

NOTE: If running Qumulo Core 2.8.5 or above, check out the SSD Caching with 2.8.5 and above article for details on Qumulo's improved FIFO based SSD caching feature available with later versions.

DETAILS

Qumulo Core makes use of SSDs in 2 ways.

80% of SSD capacity serves as a naive read cache

Currently, 80% of the usable SSD capacity (~2.6TB on a 4-node QC24; ~4.2TB on a 4-node QC208) is reserved as a read cache. As of the current release, the heuristics for determining what data is kept in this read cache is naive and unpredictable. It is based on a combination of what data has been written most recently and what data has been expired from SSDs to HDDs.

Read performance is therefore determined by whether the data is in the cache. This is why we supply both cached and uncached read performance measurements.

20% of SSD capacity serves as a buffer to satisfy a burst write workload

Assuming you have already written enough data to fill the 80% of SSD capacity reserved for the read cache (~2.6TB on a QC24), a helpful analogy for the remaining 20% of SSD capacity is a sink and drain:

QQ CLI: Comprehensive List of Commands

Data being written to the cluster comes in through the faucet at a fast speed known as Burst write speed. At the same time, data is expired or drained to HDDs at a slower rate (determined in large part by the speed of HDDs). If data continues to be written to the cluster at a rate that the draincan'tkeep up and the sink fills, further writes will be limited to the speed of the drain. This is known a the Sustained Write speed or in our case, the act of the faucet being turned down so that the sink does not overflow. As soon as the cluster stops receiving writes (the faucet turns off or down), expiration (draining) will continue until the sink is empty (20% of SSD capacity is available again as a cushion for burst writes). Workloads that involve deleting or overwriting data quickly after it is written will enjoy a longer Burst period or a higher Sustained write speed because the cluster will not have to expire (or 'drain') this data.

RESOLUTION

You should now have an overall understanding of Qumulo's SSD caching in versions 2.8.4 and below of Qumulo Core

ADDITIONAL RESOURCES

SSD Caching with 2.8.5 and above

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines the upgrade process for Snapshots in the Qumulo Core 2.5.0 version

REQUIREMENTS

Upgrading to Qumulo Core 2.5.0

DETAILS

With the release of Qumulo Core 2.5.0, all Qumulo clusters now support snapshots. After the software upgrade, a scanner will run in the background to modify old files to the latest on-disk format. Once that process is complete, you will be able to take snapshots.

When you first upgrade to 2.5.0, the Snapshots page in the UI will still look like this:

QQ CLI: Snapshots

Once the scanner is complete, refresh this page and the blue banner will go away. Your cluster is now ready to take snapshots.

What is the scanner doing?

There have been several releases over the years where Qumulo has changed the way we store files on disk. With each of those releases, we included a lazy upgrader where old files are upgraded on the fly when they are read, rather than upgrading the entire file system at once. With the introduction of read-only snapshots, we need a way to ensure that reading an old file doesnt require re-writing the data in a new format.

The scanner goes through the entire file system, upgrading these old files one at a time. Files that were written in the latest format will need to be read but are not changed.

When will the scanner finish?

The speed of the scanner depends on the number of files, the age of the files, and the load on the cluster. For a cluster with a less than 10 million files and a light to medium workload, we expect the scanner to finish in a few days.

For clusters with hundreds of millions of files and a heavy workload, the scanner may take several weeks. In 2.5.1 the speed of the scanner to address these clusters is improved.

What performance impacts can I expect?

While the scanner is running, you can continue to use your cluster as normal. The performance impact of the scanner is minimal.

How can I monitor the progress?

While there is no progress bar, there are a few ways to check on the status of the scanner.

The easiest way is to ask your Customer Success Manager (CSM). For clusters that are connected to Cloud Based Monitoring, they will send a status report on the scanners progress to Qumulo. Your CSM will be able to tell you if the scanner has completed.

From the command line, you can verify if the scanner has completed using the following command:

qq snapshot_list_snapshots

It will return this error until the scanner is complete:

Error 501: snapshot_not_enabled_error: Snapshots are not enabled on this cluster.

Once the scanner is complete, qq snapshot_list_snapshots will return:

{ "entries": []}

RESOLUTION

You should now be able to successfully upgrade to Qumulo Core 2.5.0 and utilize snapshots

ADDITIONAL RESOURCES

Video: Create a Snapshot

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to use the qq CLI to determine Snapshot capacity consumption

REQUIREMENTS

Cluster running Qumulo Core version 2.5.1 or higher

Command line (CLI) tools installed via API & Tools tab

DETAILS

You can use the qq CLI to find out how much capacity is being consumed by all snapshots.

qq snapshot_get_total_used_capacity

This will return the total number of bytes consumed by snapshots.

admin@example-3:~$ qq snapshot_get_total_used_capacity{ "bytes": "513395974144"}

For individual snapshots, theres a different qq command. Unlike other storage systems, this will give you exactly the number of bytes youll get back if you delete that snapshot.Youll need to provide a snapshot ID which you can get from looking in the UI, listing the snapshot directories in the file system, or by running the following qq command:

qq snapshot_list_snapshots

Once you have the Snapshot ID, run the following command specifying the Snapshot ID to get the total number of bytes:

qq snapshot_calculate_used_capacity --ids 5719{ "bytes": "4390166528"}

If you have data that is included in multiple snapshots, you can only reclaim that capacity by deleting all snapshots referencing the data. By using the qq command above, you can see how much youll reclaim if you delete a set of snapshots by providing multiple IDs separated by commas.

admin@example-3:~$ qq snapshot_calculate_used_capacity --ids 5719,5718,5717{ "bytes": "21961039872"}

RESOLUTION

You should now be able to successfully determine Snapshot capacity consumption using the qq CLI

ADDITIONAL RESOURCES

Video: Create a Snapshot

QQ CLI: Snapshots

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to configure and manage Quotas in Qumulo Core

REQUIREMENTS

Cluster running Qumulo Core 2.6.0 and above

DETAILS

Take a modern approach to data capacity management with Qumulos machine intelligent quotas. Quotas are built directly into the file system leveraging the machine intelligence already available in Qumulo Core so that rogue applications and users can be easily managed to enable better-informed provisioning decisions.

Key Features of Qumulos Machine Intelligent Quotas include:

Native Quotasthat are built into the file system which are always up-to-date and in-sync. Benefits include a dramatic reduction in storage administration time and freedom to move pre-existing data and directories between quota domains as needed.

Intelligent Quotasensures that every quota is a policy that executes a set of real-time queries. Unlike traditional systems that require tree-walking of the entire directory structure which can take days to complete, intelligent quotas can be immediately enforced. Benefits of this approach include real-time diagnosis and enforcement of rogue applications and users, along with real-time visibility showing how the storage is allocated at any given point-in-time.

Create a Quota

In the Web UI, navigate to the Sharing menu and select Quotas from the dropdown

Cluster Alerts for Qumulo Github Script

Click the Create Quota button

Type in the path and set the limit in GB, PB, or TB for your Quota

Click Save to create the Quota

You can now manage the Quota you've created on the Quotas listing page. Here you'll be able to see the usage in percent, the path, the used storage amount, and the quota limit for each quota.

The Quotas listing page also provides visibility on the amount of storage currently being used on the cluster, including all quotas.

Quota Used is the sum of used capacity across Quotas

Quota Provisioned is the sum of all quota limits

Keep in mindthat when the parent directory of a Quota also has a Quota provisioned, only the parent Quota is included in the calculation.

TIP! Head on over to Qumulo's GitHub and use the Cluster Alerts for Qumulo script to receive email alerts for the quotas on your cluster.

RESOLUTION

You should now be able to successfully configure and manage Quotas in Qumulo Core

ADDITIONAL RESOURCES

Video: Create a Quota

QQ CLI: Quotas

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how toinitiate server-side deletes of entire file system trees in Qumulo Core

REQUIREMENTS

Cluster running Qumulo Core 2.6.7 and above

Command line (CLI) tools installed via API & Tools tab

Admin privileges on the Qumulo cluster

IMPORTANT:Currently there is no mechanism to stop, pause, or cancel a server-side tree delete once it's started. Double-check the directory path before starting a tree delete to ensure it's accurateor take a snapshot if unsure.

DETAILS

Qumulo Core supports initiating server-side deletes of entire file system trees, aka tree deletes. Tree deletes ensure that you can start a delete jobeasily with a single qq command and know that it will successfully finish. Even if your cluster goes down or experiences transient errors running the process, the delete job will still complete.

Initiate a Tree Delete

Use the following command to start a tree delete of a directory using the path:

qq fs_delete_tree --path /dir/to/delete

Use the following command to start a tree delete of a directory using the ID of the tree root:

qq fs_delete_tree --id ID

Once a tree delete is initiated using one of the commands above, you will need to confirm the directory to ensure the tree delete is correct. Enter one of the prompts below to proceed with the tree delete.

Qumulo Core 2.10.3 and above: I HAVE VALIDATED THE PATH

Qumulo Core 2.10.2 and below: yes

Check the Tree Delete Status

You can check the current status of the tree delete using the ID or directory path with the following qq command:

qq fs_delete_tree_status --path /dir/to/deleteqq fs_delete_tree_status --id ID

NOTE: If the job has finished or if there was never a job assigned to the specified directory, the status will return a 404 error.

Additional Considerations

You will not receive failure by permissions

Tree deletes can delete up toa depth of 1000 directories

If you use tree delete to delete a replication target directory, the replication job will break

No performance guidance is given for how long the delete work will take to complete

RESOLUTION

You should now be able to successfully complete a server-side tree delete in Qumulo Core

ADDITIONAL RESOURCES

QQ CLI: File System

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how Snapshots work within Qumulo Core including:

Snapshots and Storage

Snapshot Deletes

Snapshot Capacity

REQUIREMENTS

Cluster running Qumulo Core 2.5.0 and above

DETAILS

The Qumulo Core file system has an entryfor each version ofevery file. If any data in a file is modified after a snapshot has been taken, we create a new entry for that versionof the file whichpoints to just the new data. This has several benefits including:

Instantaneous snapshots

No storage is consumed when a snapshot is taken

No performance penalty for taking a snapshot

Little to no performance penalty for reading and writing data from the filesystem in the presence of snapshots

New data is written alongside the original.When possible, the new version of the fileshares data with the old. When data is written to a snapshotted file, there will then be two entries stored in the file system as two different versions of the same file. As more data is modified, more file data isadded to this entry.

This allows us to preserve snapshotted data for everything in the Qumulo Core file system including file data, directory entries, creation/modification time, permissions, and more.

Snapshots and Storage

In Qumulo Core, a snapshot is taken instantaneously and no extra storage overhead is needed. The snapshot data then accumulates over time as data in the file system is modified whichallocates new storage space for the data and links it into the file metadata.

Consider the following 4MB file:

Snapshots: Capacity consumption using the QQ CLI

First, the file is filled with 4MB of data and a snapshot is taken

Then, 1MB in the middle of the file is modified

The filesystem allocatesa new 1MB region for the modified data

3MB of the original 4MB of data is shared between both versions of the file

1MB of new data exists in the newest, or live, version of the file

1MB of old data exists only in the snapshotted version of the file

The total storage usage for this file is now 5MB

If that particular 1MB is rewritten again, the existing live data would simply be overwritten without allocating the new space. If a different region of the file is rewritten instead, Qumulo Core will allocate more storage.

Storage usage is driven directly by the workload and data is only duplicated when necessary or on demand. There is no performance penalty for taking a snapshot and little to no performance penalty for reading and writing data from the filesystem in the presence of snapshots.

Snapshot Data Consumption

As highlighted above, Qumulo's snapshots are taken instantly and contain a point-in-time representation of the current state of a directory. These snapshots reference the data present in a directory at the time the snapshot is taken.

When changes are made to a file, they are internally tracked as being different from the latest snapshot which results in different versions of files. Essentially, you have this saved data in two forms:

Saved data stored in a snapshot Live data that has not been saved yet

This creates a lineage of snapshots that are independent of one another. When a snapshot is deleted, we remove the data covered by that snapshot while data referenced in any other snapshot is still retained so that a full representation of a file within other snapshots can be provided. When checking the size of a snapshot, only the data referenced in the snapshot is shown in the output of the command below:

qq snapshot_get_capacity_used_per_snapshot --id SNAPSHOT ID

When data is referenced in more than one snapshot, it is covered. Covered data cannot be released unless all covering snapshots are deleted. This total amount of data, which includes covered data and existing snapshots, is included in the output of the following command:

qq snapshot_get_total_used_capacity

For example. running qq snapshot_get_total_used_capacity says usage is 1319413953331 Bytes (1.2 TB Used).

However, if you were to add up all snapshots currently on the system you haveqq snapshot_get_capacity_used_per_snapshotsaying snapshot usage is 2147483648 Bytes (2 GB Used).

The former is the total snapshot data which includes the data that is covered by snapshots.The latter is the differences or changes to the data stored in each specific snapshot. This does not include the unchanged portions of files if you're looking at each individual snapshot. To see the total covered data, including data no longer present in a snapshot, you can include multiple snapshot ids (comma separated) in theqq snapshot_get_capacity_used_per_snapshot command.

Imagine a scenario where you have a 1TB file that was modified over time:

Snapshot 1: 1099511627776 Bytes (Contains the full 1TB file)Snapshot 2: 1073741824 Bytes (Contains 1GB worth of changes to the 1TB file.)Snapshot 3: 1073741824 Bytes (Contains an additional 1GB worth of changes to the 1TB file.)

If Snapshot 1 is deleted, you end up with 1023GB of data that is covered by Snapshots 2 and 3. The 1023GB of data is not freed up until all the snapshots that reference the file are deleted as well due to the need to retain the data until no snapshot references the file. Without the data that is covered (no longer present in the active snapshots 2, 3), there can be no representation of the full file.

Snapshot Deletes

When you delete a snapshot, it is immediately removed from the list of snapshots and is no longeraccessible. The space consumed by that snapshot is then recovered in a background process thatfrees data blocksthat are no longer used by any snapshot.

Although the snapshot disappears immediately, the background process may take some time to reclaim space for the file system.To monitor progress,you canrun the followingcommand during deletion to track the reclaimed spaceas the snapshot capacity decreases.

qq snapshot_get_total_used_capacity

RESOLUTION

You should now have an overall understanding of how snapshots work within Qumulo Core

ADDITIONAL RESOURCES

Video: Create a Snapshot

Snapshots: Per-Directory Snapshots

QQ CLI: Snapshots

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines TLS security for Replication in Qumulo Core

REQUIREMENTS

Source and target cluster running the same version of Qumulo Core 2.7.0 and above

Note:You can replicate betweenany models of Qumulo hardware, including HPE.

DETAILS

Qumulo Core version 2.7.0 includes some major updates to Qumulos replication feature in regards to the security of your data in transit from cluster to cluster.

Qumulo uses the OpenSSL library with protocol TLS v1.2. All replication protocol traffic between source and target use the encrypted TLS channel.

Client authentication is included as part of the protocol so that both source and target verify their peer connection.

On the initial connection, both source and target persist a fingerprint of the peer certificate and use that to authenticate all subsequent connections.

Upon establishing a replication relationship all subsequent communication between the source and target clusters is secure. This includes prevention of man-in-the-middle attacks.

RESOLUTION

You should now understand TLS security for Replication in Qumulo Core

ADDITIONAL RESOURCES

QQ CLI: Replication

Replication: Continuous Replication

Video: Continuous Replication

Like what you see? Share this article with your network!

IN THIS ARTICLE

Outlines how to utilize Continuous Replication with Qumulo Core 2.11.1 and below

Replication Page Overview

Create a Replication Relationship

Authorize a Replication Relationship

Replicating

Edit or Delete a Replication Relationship

Additional Considerations

REQUIREMENTS

Admin privileges required

Source and target cluster running the same version of Qumulo Core 2.7.3 to 2.11.1 on any model of Qumulo hardware, including HPE

We highly recommend upgrading to the latest version of Qumulo Core to fully utilize Continuous Replication with the additional improvements in functionality and performance we've implemented since the original release.

DETAILS

Continuous Replication creates a copy of the data in a directory on your primary cluster and transfers it to a directory on a second target cluster. While a replication job is running, Qumulo Core takes the latest changes and replicates them without the worry of scheduling them into an existing job. And with the help of snapshots, a point-in-time consistent copy of the source directory is generated on the target cluster.

In Qumulo Core 2.9.2 and above, incremental replication jobs will no longer resend the entire file contents when only part of a file has changed. The replication engine will scan modified files for any changed regions and only send those changes over to the target so that job runtime is proportional to the amount of data changes made.With this change, the throughput statistics in the Replication Job Details UI only include data actually transferred.Unmodified data that does not need to be transferred is reported as Unchanged.

NOTE:The initial replication job after installing 2.9.2 will still send the entire file and the first job may fall back to resending the entire file if the relationship hasnt completed a job since being upgraded to 2.8.8 or later.

Replication Page Overview

In the Web UI, hover over the Cluster menu on the Source Cluster and selectReplication under the Configurations section in the dropdown.

QQ CLI: Replication

A list of Replication relationships will display with the following details:

Status (#):represents the current status of each relationship includingReplicating,Blackout Window,Awaiting Authorization, etc. and displays the number of relationships

Source:specifies the file path of the source directory

Target:specifies the file path of the target directory

Role:indicates whether the cluster is serving in the role of a source or target directory for that particular relationship

Last Attempt:states whether the last replication attempt completed or failed

Recovery Point:displays a timestamp from the last successful Replication on the source cluster and represents the time Qumulo Core took a snapshot of the source directory and started moving data across to the target

Continuous Replication:displays whether the relationship is enabled or disabled

Create a Relationship for Replication

Click the Create Relationship button on the replication page of the Source cluster .

Fill in the following fields:

Source Directory Path: path of the existing directory you wish to replicate

Target Directory Path: path of existing empty directory on the target cluster where you wish to replicate data

Target Address: one of the IP (preferably floating IP) addresses from a node on the target cluster

Port Number: selectthe default port option 3712 or create a custom port configuration

NOTE: Custom port configuration may be necessary to meet enterprise network firewall rules. To override, select the Custom radio button and enter the port number. For questions on custom port configuration, reach out to Qumulo Care for additional information.

Verify that Continuous Replication Enabled is On.

Click Add Blackout Window.

Select the day(s) or timesto suspend replication between the source and target directories.

To add up to 10 additional blackout windows, click the +Add Blackout Window button

For additional details, check out the Replication: Blackout Windows article

Click Save Relationship.

The relationship will now be available on the replication page where you can see the status and manage the replication job. A replication job will not start until the relationship has been authorized on the Target cluster. Continue on to the next section for steps on how toAuthorize a Replication Relationship.

Authorize a Replication Relationship

Log on to the Target cluster.

Click See Details on theauthorization request notificationbanner.

Click Accept on the replication page to authorize the relationship.

IMPORTANT! Replication will not start if you are currently in a blackout window or if Continuous Replication for that relationship is disabled.

Replicating

While a replication job is running, a progress bar will display on the replication page under the status column. Note that the percentage reflects both the number of files to be moved as well as the amount of data to be transferred and is not based solely on the amount of data being replicated.

Click on the Details option to review the Throughput, Run Time, and Data statistics of the current job in progress. Files that have not changed since the previous replication job will be reflected in the Unchanged column and will not be transferred.

NOTE: Qumulo Core versions 2.7.9 and below will display "Replicating" in the status column until the replication job completes. The Details page and Progress bar are not available in these previous releases.

Edit or Delete a Replication Relationship

To Edit an existing Replication relationship, click the pencil icon next to the job on the Source cluster

Note that you cannot edit the source and target directory paths. To make these changes, you must create a new relationship.

Delete a relationship by clicking the trashcan icon on either the Source or Target cluster and confirm by selecting Yes, Delete when prompted

Additional Considerations

Upgrading Qumulo Core while a replication job is running will cause the job in progress to fail. Once both clusters return to a state where replication is possible (same version), Continuous Replication can resume. Please wait until after the replication job completes to perform any upgrades.

Utilizing Continuous Replication will increase load on the cluster and may cause latency delays depending on the applications in use while a job is running.

At the beginning of a replication job, asnapshot is created for the directory. The old snapshot isprogrammatically deleted when it is no longer needed. There will be one reference snapshot used for replication on the cluster at all times.Admins can view the snapshot(s) used for replication along with other policy-based snapshots.

A snapshot is taken of the directory on the target cluster at the conclusion of each successful job. The previous snapshot is then deleted so the directory always contains only the most recent snapshot.

Target directory permissions willbe updated from read/write to read-only when a replication relationship is created. If the relationship is deleted, the permissions will revert to read/write automatically.

A replication relationship that includes the root directory of the target cluster is not permitted. Including the root directory makes the entire target cluster read-only and may prohibit administrative functions such as upgrades.

Continuous Replication does not support replicating local user or group information and will fail if it encounters a file associated with local users or groups.

Qumulo Core supports up to 100 replication relationships.

RESOLUTION

You should now be able to successfully configure and manage Continuous Replication in Qumulo Core 2.11.1 and below

ADDITIONAL RESOURCES

Replication: Continuous Replication with 2.11.2 and above

Replication: Failover and Failback with 2.11.4 and below

Replication: Failover and Failback with 2.12.0 and above

Replication: Version Requirements and Upgrade Recommendations

Replication: Blackout Windows

Like what you see? Share this article with your network!

Changing FTP settings will directly impact the levels of access to the file system on your cluster. Please consider your system environment and workflow processes before enabling this feature.

IN THIS ARTICLE

Outlines how to configure FTP in Qumulo Coreusing the qq CLI orthe Web UI

REQUIREMENTS

Cluster running Qumulo Core version 2.7.5 or above

Command-Line tools installed

DETAILS

The FTP feature can be enabled via the Web UI or the qq CLI (it is disabled by default). Once enabled, all users will have FTP access to the entire file system of your cluster. Configuring specific fields and features for the FTP must be done via the qq CLI and is not supported on the read-only FTP page.

Enable FTP via the Web UI

Login to the Web UI.

Hover over the Sharing menu and click FTP. eXchange Protocol

Toggle the Enabled button to ON to enable FTP.

To disable FTP in the UI, toggle the Enabled button to OFF. Refer to the instructions below to configure FTP using the qq CLI.

Enable FTP via the qq CLI

Enable FTP with the following command:

qq ftp_modify_settings --enabled true

Disable FTP by running the following:

qq ftp_modify_settings --enabled false

With FTP, you can allow FXP (server-to-server transfer) using the command below.

Keep in mind that using FXP can make your server vulnerable to an FTP bounce. Review the article on File eXchange Protocol for additional details on risks and benefits.

qq ftp_modify_settings --check-remote-host false

Monitor FTP via the qq CLI

Once FTP is enabled, you can check server status and settings by utilizing the following command:

qq ftp_get_status

Enable Anonymous Users for FTP

An anonymous user can be enabled and mapped to a local user with version 2.8.5 or above of Qumulo Core. Use the guest account or input the name of the local user in place of guest as outlined with the command below:

qq ftp_modify_settings --anonymous-user-as-local-user guest

To disable the anonymous user and return to default behavior, run the following command:

qq ftp_modify_settings --anonymous-user-none

Active Directory Users for FTP

An Active Directory user can connect to the cluster running Qumulo Core 2.8.6 or above. For example, a user would log in using the DOMAIN\\username syntax as outlined below:

computer:~$ ftp cluster.company.comConnected to cluster.company.com220-| _ | | || | | |_ _ _ __ ___ _ _| | ___| | | | | | | '_ ` _ \| | | | |/ _ \\ \/' | |_| | | | | | | |_| | | (_) | \_/\_\\__,_|_| |_| |_|\__,_|_|\___/ ______ ___________ | ___|_ _| ___ \ | |_ | | | |_/ / | _| | | | __/ | | | | | | \_| \_/ \_|220 Qumulo FTP server ready.Name (cluster:computer): DOMAIN\\username331 Password required.Password:230 Login succeededRemote system type is UNIX.Using binary mode to transfer files.ftp>

Set the User's Home Directory

Qumulo supports setting the home directory for local or Active Directory users via the qq command line . Once this setting is enabled, the user will start in their home directory instead of in the root of the cluster.

To set the local user's home directory, run the following command:

qq auth_mod_user --id localusername --home-directory /home/localusername

To set the AD user's home directory (Qumulo Core 2.13.3 or above), run the command below:

qq identity_attributes_set adusername --home-directory /home/adusername

Note that the user will require traverse rights from the root of the cluster to successfully land in their home directory as outlined above. If the user does not have traverse rights, they will abide by the default behavior and land in the root of the cluster.

Chroot Users

Admins can optionally change the root directory for users to their home directories when they connect via FTPby using the following command in version 2.8.6 or above of Qumulo Core:

qq ftp_modify_settings --chroot-users true

To disable and return to default behavior, run the following command:

qq ftp_modify_settings --chroot-users false

As specified above, if you are configuring a local user,the user will require traverse rights from the root of the cluster to their home directory to successfully connect.

RESOLUTION

You should now be able to successfully configure and utilize FTP in Qumulo Core

ADDITIONAL RESOURCES

FTP: TLS Security

QQ CLI: FTP

File

Like what you see? Share this article with your network!

IN THIS ARTICLE

Includes a video outlining how to create a Quota in Qumulo Core

REQUIREMENTS

Cluster running Qumulo Core version 2.6.0 and above

VIDEO

RESOLUTION

You should now be able to successfully create a Quota in Qumulo Core

ADDITIONAL RESOURCES

Quotas in Qumulo Core

QQ CLI: Quotas

Like what you see? Share this article with your network!

IN THIS ARTICLE

Includes a video outlining how to utilize Continuous Replication in Qumulo Core

REQUIREMENTS

Source and target cluster running the same version of Qumulo Core 2.7.3 and above

Admin privileges required

Note:You can replicate betweenany models of Qumulo hardware, including HPE.

VIDEO

RESOLUTION

You should now be able to successfully utilize Continuous Replication in Qumulo Core

ADDITIONAL RESOURCES

Replication: Continuous Replication

Replication: TLS Security

QQ CLI: Replication

Like what you see? Share this article with your network!

IN THIS ARTICLE

Includes a video outlining how to create a Snapshot in Qumulo Core

REQUIREMENTS

Cluster running Qumulo Core version 2.5.1 or higher

VIDEO

RESOLUTION

You should now be able to successfully create Snapshots in Qumulo Core

ADDITIONAL RESOURCES

Snapshots: Per-Directory Snapshots

QQ CLI: Snapshots

Like what you see? Share this article with your network!