CloudFS Version 8.7.1.0

Table of Contents

1. Overview ..... 6 1.1 Panzura Node Family ..... 6 1.2 Cloud Storage Tier Options ..... 6 1.3 Configuring the node ..... 12
2. Deploying a Panzura CloudFS Cluster ..... 13 2.1 Planning a Deployment ..... 13 2.2 Deploying Panzura CloudFS ..... 13
3. Panzura Architecture ..... 17 3.1 Master and Subordinate Nodes ..... 17 3.2 Configuration Replication ..... 17 3.3 Local and Remote nodes ..... 18 3.4 Node Features ..... 18
4. Clustered Deployments ..... 20 4.1 Sample Deployment ..... 20
5. What's New? ..... 21 5.1 Grafana Cloud Integration ..... 21 5.2 Quarter-Hourly Scheduled Snapshots ..... 21 5.3 Node Decommission and Activation/Deactivation Enhancements ..... 21 5.4 Third-Party Multi-Consumer Audit Streaming ..... 21 5.5 Prewarm Provision updates ..... 22 5.6 Local HA Failover Improvements ..... 22 5.7 Ring Health Check Report ..... 22
6. Key Features and enhancements ..... 23 6.1 Prewarm Provision ..... 23 6.2 Health Check Diagnostics ..... 23 6.3 File Lock Release ..... 23 6.4 Adaptive Snapshot Retention (aka Setting up Snapshots) ..... 23 6.5 Ring Status Management ..... 23 6.6 Regional Store v2 ..... 23 6.7 Enhancements in Grafana dashboard ..... 24 6.8 Storage Class Tier Support in CloudFS ..... 24 6.9 Quota Management ..... 24 6.10 Geofencing Policy ..... 24 6.11 S3 Interface ..... 24 6.12 Time-Series Statistics ..... 24

6.13 Manage Share Access ..... 25 6.14 Support for Role-Based Access Control (RBAC) for System Management ..... 25 6.15 Audit Trail ..... 25 6.16 CloudFS Instant Node ..... 25 6.17 User Auto Scaling ..... 25 6.18 Enhanced regional store ..... 25 6.19 Enhanced Node Decommissioning ..... 25 6.20 Extended RBAC support for OKTA Identity Provider using SAML & OIDC Protocols ..... 26 6.21 UX Dashboard and PZIQ Settings ..... 26 6.22 VM Support for Linux KVM (RHEL 9.4+) ..... 26 6.23 Panzura Global Namespace ..... 26 6.24 Cloud Mirroring ..... 26 6.25 File Locking ..... 27 6.26 Snapshots ..... 28 6.27 Smart Cache ..... 28 6.28 Extended File System ACLs ..... 28 6.29 Scale out Global Deduplication ..... 28 6.30 Enhanced Cloud Diagnostics ..... 28 6.31 Intelligent Symantec NetBackup Integration ..... 28 6.32 High Availability Solution ..... 29 6.33 DR Cloud Recovery ..... 29 6.34 Enterprise AntiVirus Plugin ..... 29 6.35 FIPS ..... 29 7. CloudFS Instant Node ..... 30 7.1 Restore A Node (Recovering a node) ..... 30 7.2 Commission a New Node ..... 33 7.3 Restore VMware virtual machine Hypervisor snapshots ..... 34 8. Panzura Quick Start Guide ..... 38 8.1 Web Browser Requirement ..... 38 8.2 Deployment Mode: One-arm or Inline ..... 38 8.3 Pre-installation Checklist ..... 38 8.4 Site Preparation ..... 40 8.5 Cloud Storage Provider Requirements ..... 42 8.6 Finding the node IP Address ..... 42 8.7 Changing the node IP Address (using the CLI) ..... 42 9. Setting Up the Panzura Node ..... 44 9.1 Node Information ..... 44 9.2 Cloud Provider Information ..... 46

9.3 Bringing Up a Node for the First Time ..... 48 9.4 Accessing the Setup Wizard ..... 49 9.5 Configuration Wizard ..... 49 10. Using the CloudFS Dashboard ..... 50 10.1 Default Dashboard ..... 50 10.2 Manage Dashboards ..... 58 10.3 Adjust the Date Range ..... 58 10.4 Dashboard Explorer ..... 58 11. Using the Panzura CloudFS User Interface ..... 59 11.1 Overview ..... 59 11.2 About CloudFS Map ..... 59 11.3 Using the CloudFS UI ..... 60 12. Configuration ..... 65 12.1 System Settings ..... 65 12.2 Network Settings ..... 68 12.3 Monitoring ..... 78 12.4 Encryption Settings ..... 99 12.5 CloudFS Settings ..... 104 12.6 NFS/SMB Mixed Mode ..... 114 12.7 NFS Settings ..... 116 12.8 Setting up Snapshots ..... 119 12.9 Setting Up Smart Cache ..... 122 12.10 High Availability Settings ..... 126 12.11 Default Auto Prepopulate/Prefetching Features ..... 132 12.12 Active Directory ..... 133 12.13 License Manager ..... 135 12.14 Disk Expansion ..... 151 12.15 Access Control ..... 151 12.16 Geofencing Policy ..... 178 12.17 Quota Management ..... 182 13. Maintenance ..... 186 13.1 Diagnostic Tools ..... 186 13.2 System Operations ..... 193 13.3 ICAP Operations ..... 194 13.4 ICAP Operations ..... 196 13.5 CloudFS Operations ..... 196 13.6 SMB/NFS Operations ..... 198 13.7 System Reset and Cleanup ..... 201

13.8 Master Node Operations ..... 202 14. Notifications Center ..... 216 14.1 Alerts ..... 216 14.2 Audit Trail ..... 216 14.3 View Running Processes ..... 219 15. Panzura Application Programming Interface ..... 220 15.1 Accessing API Syntax Information ..... 220 15.2 API Authentication and Authorization ..... 220 15.3 Web UI API Console ..... 220 15.4 Accessing API Syntax Information ..... 220 15.5 Statistics Collection System ..... 221 15.6 RestAPIs for S3 Interface ..... 224 15.7 Rest APIs for Audit Trail ..... 228 15.8 Rest APIs for Quota Management ..... 230 15.9 Rest APIs for Prewarm Provision ..... 232 15.10 Rest APIs for Geofencing Policy ..... 235 16. CloudFS and Azure AD ..... 238 16.1 Microsoft Azure Active Directory Domain Services (AD DS) ..... 238 16.2 Comparing Active Directory to Azure Active Directory ..... 238 16.3 Leveraging Azure AD for Multi-factor Authentication with Panzura CloudFS ..... 240 17. Additional Information ..... 241 17.1 Windows Users and Files that Are Slow to Open ..... 241 17.2 Updating AWS Credentials on Panzura Nodes ..... 241 17.3 Creating a Microsoft Azure Storage Container ..... 243 17.4 Creating a Vault or Container in the IBM Cloud Object Store ..... 244 17.5 File Access Auditing Support for SMB and NFS Clients ..... 245 17.6 ICAP Best Practices ..... 247 17.7 Revit Best Practices ..... 248

1. Overview

This guide is designed to help administrators effectively manage and optimize the CloudFS environment. CloudFS is a hybrid cloud file services platform that consolidates data storage, enhances collaboration, and ensures data security and resilience. By integrating various storage solutions into a unified system, CloudFS simplifies data management and reduces operational complexity. It provides robust features such as global file synchronization, real-time collaboration, and advanced security measures like encryption and ransomware protection.

Additionally, this guide describes the CloudFS node, which is a critical component of the CloudFS architecture. The CloudFS node acts as a bridge between local storage and cloud storage, enabling seamless data transfer and synchronization. The guide covers detailed instructions on how to deploy and manage CloudFS nodes, including initial setup, configuration, and ongoing maintenance. Administrators will learn best practices for optimizing node performance, ensuring high availability, and troubleshooting common issues to maintain a resilient and efficient CloudFS environment.

1.1 Panzura Node Family

Panzura CloudFS enables organizations to solve growing unstructured data challenges by combining data center performance with the economics, scalability, and durability of cloud storage.

CloudFS delivers unprecedented performance and scale, expanded data center workloads, deployment on any platform and any cloud, automated, centralized management, and unmatched cloud data protection.

• CloudFS Archive: Replaces expensive single site NAS systems with a hybrid cloud storage platform that combines data center performance with the economics, scalability, and durability of the cloud. Archive can replace your entire backup and archive infrastructure with a more resilient, automated solution. It provides business continuity because it appears to users like a local network drive while storing all unstructured data in the cloud. Local performance is provided by high-performance flash and advanced caching algorithms that ensure that every application has the data it needs when it is needed.
• CloudFS NAS: Empowers organizations to break free from the storage status quo and eliminate islands of storage by consolidating their unstructured data to the cloud. Expensive, traditional NAS storage can be eliminated by centralizing unstructured data in the cloud, while keeping active data cached close to users. This modern cloud plus cache model is simpler, faster, and less expensive than deploying traditional primary, backup, and archive storage at each site.
• CloudFS Collaboration: Enables real-time collaboration across the enterprise by consolidating unstructured data to the cloud. Collaboration looks and behaves just like a local, locking NAS or Windows node to users, but is backed by a central cloud data repository and can span hundreds of sites. Byte-range locking, combined with immediate global consistency enables globally distributed users to work together as if they are in the same room. It's simpler, faster, and less expensive than deploying primary, backup, and archive storage at each site, and running WAN optimization over private networks.

1.2 Cloud Storage Tier Options

The following object storage services and products have been validated to work as object storage for Panzura CloudFS. Note: For Panzura CloudFS 7, Data download (per GB) cost may be more than Tiered Cost Savings. Please, check with your Account Manager for more details.

1.3 Configuring the node

After the node is installed, use the web UI for all additional configuration and management. See the installation guide for your Panzura node platform for installation information.

1.3.1 Access the WebUI

1. Enter the node's IP address into your web browser and log in using the default credentials. (See Setting Up the Panzura node $\to$ Gather Information.)
2. The system prompts you to change the admin password.

1.3.2 Navigate the WebUI

You'll find these links on the Home page of the WebUI:

1. CloudFS: Look at the health of the overall node network.
2. Dashboard: Get an overview of system performance.
3. Configuration: Set up the node.
4. Maintenance: Keep the node running smoothly.
5. Notifications: Check on alerts and other notifications

When you open any of the links, they show as tabs at the top of the page. Click the tabs to navigate or click the $\mathbf{X}$ in a tab to close it. For the Configuration and Maintenance tabs, use the side menu to navigate to a section on the page, and then click an icon to reveal the settings within the selected category.

2. Deploying a Panzura CloudFS Cluster

This chapter provides guidelines and suggestions for deploying a Panzura CloudFS cluster, including deploying the nodes, seeding the CloudFS with files and directories, connecting users, and tuning for performance.

2.1 Planning a Deployment

Planning a Panzura deployment involves determining the number and location of nodes, the role that each filter will play, the product models and capacities, and strategy for high availability (HA).

The following sample Panzura deployment for AEC Corporation (aec-example.com) has three working sites-Paris, New York, and London. A Panzura node is physically deployed at each site. Users connect to their local node, see the shared file system, and experience LAN access speeds to the data in the global file system.

The three active Panzura nodes are deployed as follows.

• The node in Los Angeles, la.aec-example.com, is configured as a Master node. Project directory: /cloudfs/la/aec-project-01 An SMB share for the directory: / aec-project-01 User connection to SMB share: \la.aec.com\aec-project-01
• The nodes in the London and Paris offices, london.aec-example.com and london.aec-example.com, are configured as subordinates to the Los Angeles node.

Users at these sites connect to the SMB share 'london.aec.com'aec-project-01 or 'paris.aec.com'aecproject-01. * The Phoenix node is a dedicated standby for the Los Angeles node and is set up using the HA-Local option.

The Amsterdam node is a standby for the London and Paris nodes and is set up using the HA-Global option.

2.2 Deploying Panzura CloudFS

The next sections describe the high-level steps to deploy a multiple-site Panzura CloudFS configuration, such as the one if the previous example. For configuration details, see the following sections:

2.2.1 Step 1: Install and Configure the Panzura nodes

A CloudFS deployment runs on a cluster of globally distributed Panzura nodes, which can be physical or virtual. The nodes are configured on their local networks, attached to DNS, and connected to the cloud back-end.

Install the designated master and each of the subordinates according to the instructions in Setting Up the Panzura node. Following installation, the nodes should all be running and joined to the CloudFS.

Following installation and during normal operations, any updates to the master configuration are automatically replicated to the subordinates. See for a list of replicated information.

2.2.2 Step 2: Seed CloudFS with Files and Directories

It is important to seed CloudFS with project data before users access their local Panzura node for the first time. In preparation for seeding data, create a directory structure that supports both current and future projects. Then upload project data and confirm that each node in the cluster has the same view of the global file system and directory structure.

This process is done on the Master node.

Seed CloudFS with File Data

1. Mount your local Panzura node to your desktop via an SMB share.
2. Create a directory structure that supports current and future project files.
3. Upload project files to the appropriate directories on the node.
4. Wait for the data to synchronize.

5. Mount each of the remote nodes.
6. Confirm that the entire file system can be viewed from each node.
7. Observe CloudFS performance using the ingress and egress rate counters in the Panzura web UI.

Windows Tools for Seeding Data

Microsoft Windows offers GUI and command line tools for migrating data:

1. The Windows Explorer GUI can be used to drag and drop files to the CloudFS SMB share. However, this method of copying files does not preserve file or folder permissions (ACLs).
2. Robocopy (Robust File Copy) is a command-line utility-included with Windows Server 2012 and 2008-used to copy files and preserve file and folder permissions. Robocopy is scriptable, logs the copy process, features retry capabilities, and works around locked files.

Linux Tools for Seeding Data

Linux OS distributions include the rsync tool that can be used to copy files and directories from one server to another over an SSH connection. It is scriptable, preserves file permissions, and copies only new or changed files to the destination folder.

Time It Takes to Seed CloudFS with Data

When files are uploaded to an SMB share on the local Panzura node, the files and metadata are immediately uploaded to the shared cloud storage back-end. The files and metadata become available to all the other nodes in the cluster, which immediately download the metadata and synchronize their file systems. When working with normal amounts of data, the cycle of uploads and downloads is nearly instantaneous and invisible to the end user.

However, when seeding large amounts of data to a node, be aware that it takes time to upload files and file system metadata to the shared cloud storage back-end. The time to complete this upload and download cycle is governed by the speed of the network links connecting the clients to the nodes and the nodes to the shared cloud storage back-end. When data is uploaded to a share on the local node, the PFOS operating system creates a system snapshot to capture the state of the file system and to identify the files that have been created or changed. Before uploading files to the cloud, the data in the files is broken down into smaller chunks of data, called drive files, which are uploaded sequentially to the shared cloud storage back-end. The file data is uploaded first followed by the file system metadata snapshot.

Remote nodes constantly poll the shared cloud storage back-end looking for new metadata snapshots. When new metadata snapshots are found, they are downloaded one by one and applied to the local file system. After the last metadata snapshot is downloaded and applied, the global file system is fully synchronized among all the nodes.

The time required to move data to CloudFS and share the updated file system metadata with all the nodes in the cluster is a function of the following values:

1. $\mathrm{T}1=$ time to transfer files on a LAN from the local file server to the local Panzura node.
2. $\mathrm{T}2=$ time to upload the files (drive files) and the metadata snapshot from the Panzura node to the shared cloud storage back-end.
3. $\mathrm{T}3=$ time to download the metadata snapshot from shared cloud storage to the remote Panzura nodes.

The remote nodes poll the cloud every 30 seconds, so the time to find and begin to download the metadata snapshot is no more than 30 seconds.

The time required to move files between a file server and the Panzura node is governed by the speed of the local area network. Actual network speed is determined by the available bandwidth on the network.

With that in mind, the following formula calculates the minimum amount of time to move data to the Panzura node, and between nodes and the cloud. time $(\sec )=$ amount of data $(\mathrm{GB})\ast 8/$ network speed $(\mathrm{Gb}/\mathrm{s})$ For example, with 100 GB of data and a 1 Gb/s LAN, the calculations are as follows:

1. $\mathrm{T}1=100\ast 8/1=800$ seconds
2. $\mathrm{T}2=100\ast 8/1=800$ seconds
3. $\mathrm{T}3=30$

Thus, the minimum time to upload and share 100 GB of data with a 1 Gb/s LAN is: $\mathrm{T}1+\mathrm{T}2+\mathrm{T}3=800+800+30=1630$ seconds $=27.2$ minutes.

Network connections to the cloud are frequently a lot less than 1 Gb/sec.

2.2.3 Step 3: Connect Users to CloudFS

When CloudFS is running efficiently, it provides fast access to files that are distributed in the global file system. However, it takes time to distribute files to the appropriate nodes. Until files are cached in the local nodes, it appears that the system is running slowly. By design, the decision to cache data is an automated process that is triggered when a user accesses the data. Therefore, users will experience slow system performance as the system becomes balanced and data is cached at the appropriate node.

Also, when a large amount of data is uploaded to CloudFS, users who want to access that data will experience slow access times until the files are downloaded and cached to their local node. Subsequent file access will be fast, and updates to cached files will be shared quickly among all the nodes in the cluster.

Windows Explorer users will experience a delay when viewing a directory with a large number of new files for the first time. Windows Explorer must open every file in the directory before it can display the directory listing. If these files are not yet cached locally, Windows Explorer becomes unresponsive and appears to hang. Once the Panzura node downloads all of the files from that directory to the CloudFS cache, Windows Explorer performs normally.

In all cases, cache policies can be used to prepopulate the cache and improve performance for a particular folder. Even crawling the file folders (reading the files) can be used to populate the cache with data before users connect to the node. It is a common practice for a knowledgeable system administrator to "walk" particular project directories in specific locations ahead of time to improve the local user's first experience by ensuring the files they're likely to use are already cached in the local node.

Connect Users to CloudFS

1. Users mount their local node via SMB.
2. Users browse file directories, then access and update files.
3. Files become cached locally and I/O performance increases.
4. Observe CloudFS performance using the ingress and egress rate counters in the Web UI.

2.2.4 Step 4: Observe CloudFS Performance

PFOS provides tools for monitoring CloudFS. Three counters are used to observe the flow of data through CloudFS: rate of data ingress, rate of data egress, and the synchronization of system snapshots. The ingress and egress counters are viewed from the dashboard in the WebUI. The synchronization counters are viewed from the Diagnostic Tools menu in the web UI.

The following discussion of data flow within CloudFS uses a two-node deployment, with nodes named LOCAL and REMOTE.

Observe Uploads on a Local Panzura node

1. Open the Dashboard page in the Web interface.
2. Copy files to an SMB share on the local node.
3. The ingress rate increases as data is copied to the node.
4. The egress rate increases as drive files and snapshots are copied to the cloud back-end.
5. Only after the drive file uploads are completed will the file system metadata snapshot be uploaded.
6. The egress rate returns to zero after all drive files and snapshots are successfully uploaded.

Observe Downloads on a Remote Panzura node

Open the Dashboard page in the Web interface.

1. The remote node polls the shared cloud back-end storage every 30 seconds for the latest snapshots.
2. The snapshot sequence number of the latest snapshot is compared with the snapshot sequence number of the local metadata snapshot.
3. If the sequence numbers don't match, the node will proceed to download metadata snapshots, one by one, until the sequence numbers match again.
4. The ingress rate increases as the metadata snapshots are downloaded.
5. The ingress rate returns to zero after all the file system metadata snapshots are successfully downloaded.

When completed, the local and remote file systems are synchronized. Confirm that the file system is synchronized across all nodes. To confirm the file system is synchronized, check the Active node Sync Status on the dashboard.

2.2.5 Step 5: Tune CloudFS Performance

PFOS provides an automated, intelligent read cache, Smart Cache, that increases file I/O performance. Over time and through general usage, the system dynamically populates the Smart Cache with hot data from files being read by users. The caching algorithm monitors the frequency of file access, and how recently files were accessed, to determine what data to cache and what data to eject from the cache.

CloudFS performance can be tuned to increase the performance of specific files and directories with the use of cache policies. Cache policies govern what files are cached locally on the node. These policies are also used to pre-populate the cache to guarantee LAN speed access to files before users access them for the first time.

Set Up High Availability Protection

You can protect your cloud file system in the event of a node failure using these high availability (HA) options:

• HA Global: One or more nodes are protected by one or more shared standbys, which can be separated geographically from the nodes they protect.
• HA Local: An active node is protected by a dedicated standby. When the active node fails, the passive standby assumes its identity and takes over operations. HA Local is similar to the methods used by legacy enterprise storage product. In this configuration, an active node is protected by a dedicated, passive standby. When the active node fails, the standby takes over ownership of the file system and the node operations. The following HA Local options are supported:
• Local: The active and standby nodes have different hostnames and IP addresses.
• Local with shared address: The active node and passive standby have an additional shared hostname and IP address, which simplifies the takeover process. (Maximum length of the shared hostname is 15 characters.)

Important HA-Local Notes

When using HA-Local with shared address, only the shared hostname should be joined to Active Directory. The individual nodes in the pair should be configured with the domain (and NetBIOS group) information, but not joined.

The nodes to be used as standby (HA-Local or HA-Global) must not previously have been members of the CloudFS and must not re-use any prior node hostname. A repurposed node must have a new hostname and a new Cloud node ID (CCID) number, which is embedded in the License to Operate (LTO).

See the following sections for more information about HA:

1. For a general overview of the high availability feature, see Overview - Panzura CloudFS.
2. For instructions on setting up HA, see High Availability Settings. Select one of the HA options for configuration mode when using the setup wizard.
3. For instructions on initiating a high availability takeover, including best practices for takeover, see High Availability Operations.
4. We do not support disabling VIP without recreating or configuring the HA-Local set up. The UI has a radio button that can be enabled or disabled. If you disable VIP, VIP is not deleted. This will be fixed in the upcoming releases.
5. If HA-Local with VIP is deleted, the node needs to be rejoined using the original hostname. If this occurs end users should join with the old host name and not the VIP. If the users do not reconnect using the old hostname, there will be a disruption in operations.

3. Panzura Architecture

The Panzura architecture provides a highly scalable, high performance Distributed Cloud File System (CloudFS ${}^{\mathrm{TM}}$ ) that natively integrates with public, private, and dark cloud storage systems. CloudFS supports applications that require global collaboration and file locking, combined with on-premises NAS performance. Services include FIPS-140 certified encryption, deduplication, and snapshots. Enterprises no longer have to plan for local backup and disaster recovery, as all the data and snapshots are in the cloud.

Panzura Nodes are edge appliances that provides local-feeling performance. These virtual machines are reliable, high performance, optimized cloud storage appliances that can manage massive data densities within its scalable file system. The resilient storage subsystem protects data using military-grade encryption, multiple RAID parity protection schemes, efficient user-managed snapshots, and cloud storage.

The node provides local and cloud storage for widely-used file storage protocols, file management technologies, and directory services integration.

1. Network File System (NFS), used by Unix/Linux clients and servers.
2. Server Message Block (SMB), used by Microsoft Windows clients and servers.
3. Microsoft Active Directory (AD).

The nodes can virtualize multiple disk media types within the same file system. Supported media include spinning hard disk drives (HDDs), solid-state drives (SSD), networked WAN-addressable cloud storage, and LAN-addressable NAS node volumes. PFOS serves data to clients with SMB and NFS protocols.

3.1 Master and Subordinate Nodes

The master/subordinate configuration refers to the management relationship between nodes in a cluster deployment.

3.2 Configuration Replication

The configuration details of a Master node are automatically replicated and distributed to all Subordinate nodes. This simplifies the management of the CloudFS deployment. The replicated information includes:

1. Licenses.
2. CloudFS operation mode.
3. nodes that are permitted to participate in the shared CloudFS topology.
4. Encryption certification for accessing data in the cloud between nodes.
5. SMB shares.

6. NFS exports.
7. Drive file size.
8. Schedule filesystem snapshots.
9. Deduplication setting.
10. Data compression setting.
11. Cloud upload order.
12. SMB signing mode.

3.3 Local and Remote nodes

The local node is the node nearest the user on a local LAN. A remote node is one that is physically located in another office, somewhere around the globe. These terms are used when describing the flow of files and metadata within CloudFS, from one node to another node.

Users connect to their local node, have a complete view of the shared file system, and experience LAN access speeds to the data in the global file system.

3.4 Node Features

The Panzura node provides the following features:

Software

• Highly scalable 128-bit transactional object file system.
• Intelligent read and write caching.
• In-band file system Policy Engine.
• User managed snapshots.
• Globally distributed file sharing and locking for SMB.
• High availability.

Hardware

• Global namespace.
• RAID data protection.
• SSD and HDD.

Security

• Microsoft Active Directory (AD) integration.
• Extended file system ACLs.
• Kerberos authentication.
• Key Management Interoperability Protocol (KMIP) support.
• Scalable in-line global deduplication.
• Multi-protocol SMBv3, and NFSv4 file services.
• SMB load balancing.
• Military grade FIPS 140-3 encryption
• Policy-based LAN and WAN bandwidth management.
• SNMPv3 monitoring, traps, and alerting.
• Email alerts for rapid response.
• Online remote monitoring and support.
• High-speed parallelized WAN-optimized cloud IO.
• Multiple cloud topologies (public, hybrid, private).
• Real-time cloud storage diagnostics.
• Full system recovery from the cloud.

• 1GbE and 10GbE NIC support (optical and copper).
• Bandwidth shaping and connection tuning.

4. Clustered Deployments

Geographically dispersed nodes allow users who connect to CloudFS to experience a high-speed file system, regardless of location. Updates to the file system are shared in the background, in near real-time, with all the other nodes in the cluster. Integrated with CloudFS is a global file locking technology, called Global Read Write (GRW), which controls read and write file locking. This technology allows many users and work-sharing applications to leverage global CloudFS without suffering file locking or performance issues.

Within Panzura's distributed cluster architecture, all nodes share access to a common storage cloud. The cloud is the authoritative source of data for all nodes. The Panzura architecture includes technologies to leverage the difference in capacity and manage the aspects of deploying a NAS storage system that operates under this paradigm. Each Panzura node provides LAN performance to CloudFS node by locally caching data while presenting a complete metadata view of the entire DCFS that can span geographically.

4.1 Sample Deployment

The following figure shows a Panzura deployment with three working sites-Los Angeles, London, and Paris-and two sites provisioned for high availability (HA) -Phoenix and Amsterdam. A Panzura node is physically deployed at each site. Users at the three working sites connect to their local node, have a complete view of the shared file system, and experience LAN access speeds to the data in the global file system.

5. What's New?

The following sections describe key features in detail.

5.1 Grafana Cloud Integration

Support for Grafana Cloud Advanced enables customers to securely connect their Grafana Cloud instances to on-premises InfluxDB data hosted on CloudFS nodes. Key enhancements include:

• Grafana Private Data Source (PDC) Integration: Establishes a secure tunnel between Grafana Cloud and your local network without requiring inbound firewall ports to be opened.
• Enhanced Dashboards: Introduces new Traffic Light summary widgets and drill-down capabilities, providing real-time health monitoring for large-scale CloudFS node deployments.
• PDC Agent Lifecycle Management: Allows administrators to start, stop, and monitor the Grafana PDC agent directly from the CloudFS WebUI or through the REST API.

For more details, refer to Grafana and Time-Series Stats Settings

5.2 Quarter-Hourly Scheduled Snapshots

CloudFS supports snapshot scheduling at an interval of 15 -minute. With this enhancement, administrators can schedule snapshots at intervals of 15 minutes within an hour (example: 3:00 PM, 3:15 PM, 3:30 PM, 3:45 PM etc).

For more details, refer to Snapshot Settings.

5.3 Node Decommission and Activation/Deactivation Enhancements

CloudFS administrators can now deactivate (bring a node temporarily down due to catastrophic conditions such as a power outage or transient conditions like a hurricane), activate, and decommission individual nodes from the master node's web UI, providing seamless visibility into the CloudFS ring status.

Key enhancements include:

• The node deactivation process flushes the pending writes during the shutdown.
• Rebooting a decommissioned node now automatically puts it in maintenance mode, preventing it from accidentally rejoining the ring.
• Consolidates the previous "Skip snapshot sync (forced)" and "Shut down node automatically when complete" options into a single, safer action: Skip snapshot sync-up and shut down node, ensuring the decommissioned node is fully taken out of the ring by automatically stopping critical services and shutting down the node.
• Administrators can decommission the offline or deactivated nodes without bringing them back online.

For more details, refer to Ring Status Management.

5.4 Third-Party Multi-Consumer Audit Streaming

CloudFS 8.7.1.0 introduces support for multiple independent third-party audit consumers, enabling several products to receive real-time audit events from the same CloudFS cluster simultaneously.

In previous releases, CloudFS supported only a single RabbitMQ consumer, limiting audit event integration to one third-party application at a time. With this enhancement, multiple vendors - such as Nexus, Varonis, and other supported integrations - can register independently and consume the complete, unfiltered audit event stream without impacting one another.

• Support for multiple concurrent RabbitMQ consumers.

• Independent registration and deregistration for each vendor.
• Dedicated RabbitMQ connection for every registered consumer.
• Consumer isolation ensures that a failure or outage affecting one consumer does not interrupt event delivery to others.
• Each consumer receives the complete, unfiltered audit event stream.
• No audit events are lost or duplicated during normal operation.
• Registering or deregistering one consumer does not disrupt active consumers.

For more details, refer to Audit Settings.

5.5 Prewarm Provision updates

Prewarm Job Scheduling

Using REST APIs, CloudFS administrators can now schedule data prewarm jobs in advance with all existing capabilities (Prewarm Directories, Prewarm File List) and will execute automatically at the specified time, updating its status accordingly.

Prewarm Job Search & Filtering

Search or filter prewarm job history by node, share, submitter, or status via WebUI or REST API endpoint /ps/cfs/api/v1/prewarm/jobdetails with appropriate query parameters. The prewarm jobdetails API and WebUI now support filtering results by status, node name, job ID, submitted by, and CFS share — making it easy to locate specific jobs quickly.

Other updates

• Added option to prewarm Alternate Data Streams (ADS) associated with files.
• Support for UNC and DFS Paths in File list: The prewarm file list upload now supports UNC paths and DFS paths in the uploaded CSV along with CloudFS-native paths. With this enhancement, UNC and DFS paths in the uploaded CSV are automatically converted to their corresponding CloudFS paths before prewarming begins.
• Generated File List CSV Now Includes File Size: The Generate File List (File list generation) feature produces a CSV with two columns: file path and file size to help administrators estimate cache impact and make informed decisions before submitting a prewarm job.
• Configurable prewarm log level: Allows support engineers to enable debug logging via the cfsws.cfg configuration file. Edit the prewarm logging configuration in /opt/pixel8/conf/cfsws.cfg. Set the desired log level (e.g., debug, info, warning, error). Restart the CFSWS service or wait for the configuration to be picked up. Debug-level prewarm logs will now appear in syslog when the log level is set to debug.
• Scheduled job messages include the job_id for easier tracking.

For more details, refer to Prewarm Provision.

5.6 Local HA Failover Improvements

• Non-Disruptive HA Pair Breakup: HA-Local configurations can now be unpaired without disrupting SMB client connectivity. The shared Virtual IP (VIP) remains active on the primary node, allowing users to continue accessing shares without reconnecting clients or rejoining Active Directory. Additionally, when pairing a new LHA node, previously configured VIP settings are automatically detected and pre-populated.
• Abort Manual Failover: Manual HA failovers can now be canceled gracefully while in progress. This provides a safe recovery option if a takeover is initiated unintentionally or is no longer required.

For more details, refer to High Availability Settings.

5.7 Ring Health Check Report

The Health Check API retrieves the health check report for the entire CloudFS ring. With a single API call, it provides a consolidated view of the health status across all nodes, making it ideal for NOC dashboards, automated monitoring, and integration with third-party ITSM and observability platforms. For a consolidated health check report, call the API endpoint via any REST client or automation tool:

• All nodes in the ring: GET /pz/cfs/api/v1/ring/healthcheck.
• A node in the ring: GET /pz/cfs/api/v1/node/healthcheck.

6. Key Features and enhancements

6.1 Prewarm Provision

Large organizations need the ability to manually trigger data hydration to avoid delays and protocol timeouts when data is available in the Cloud but not on the Node.

The Prewarm Provision feature allows CloudFS administrators to ensure that the data is pre-populated on the node from the cloud before users access it. This can be used for HA failover preparation or to pre-populate data for large projects.

For more details, refer to Prewarm Provision. Use the Prewarm Provision REST APIs to perform standard Prewarm API calls.

6.2 Health Check Diagnostics

The health check diagnostics allows administrators to access the system's status and performance and enables them to take appropriate action. For more details, refer to Health Check Diagnostics.

6.3 File Lock Release

File Lock Release allows administrators to reclaim control of files locked by other users, ensuring uninterrupted collaboration. Once released, the file ownership returns to the filesystem owner node and can be claimed by any other users in the CloudFS ring. This option is available on both master node for any file(s) in the global filesystem and subordinate nodes for any file(s) belonging to the shares owned by them.

For more details, refer to File Lock Release.

6.4 Adaptive Snapshot Retention (aka Setting up Snapshots)

Node level Snapshot Retention allows administrators to configure custom snapshot retention for file owner nodes and data owner nodes, reducing metadata growth while preserving global file version availability. It allows data owner node to retain a smaller number of user snapshots than the file owner node. Since all file versions are already preserved on the file owner node, limiting snapshot retention on data owner nodes does not impact access to historical versions. This approach minimizes metadata buildup on data owner (leaf) nodes in large deployments, keeping them lightweight.

While Setting up Snapshots explains how to configure snapshot schedules, Adaptive Snapshot Retention focuses on defining intelligent retention rules to better manage snapshot lifecycles. For more details, refer to Setting up Snapshots.

6.5 Ring Status Management

The Ring Status Management feature provides administrators with a centralized interface to monitor and manage the operational status of all nodes within a CloudFS ring. It allows viewing real-time node states, performing maintenance actions such as temporarily bringing nodes offline (deactivate), and safely decommissioning nodes when required.

For more details, refer to Ring Status Management.

6.6 Regional Store v2

CloudFS deployments with multiple buckets now have enhanced resiliency, allowing data downloads to continue with alternative buckets if the regional bucket is unavailable or replication is halted or not configured.

For more details, refer to Regional Store Setup.

6.7 Enhancements in Grafana dashboard

With this release, the Grafana configuration now leverages a single data source (cfs_scs_stats) for unified access to time-series metrics and simplified dashboard management. A new aggregation slicer empowers users to tailor data granularity from - hourly, daily, weekly, monthly, or yearly for flexible analysis. Additionally, new aggregated charts, including Network I/O, Node Drive File Uploads/Downloads/Deletes, and Managed Capacity Trend, offer improved visualization of performance and capacity trends across selected time ranges.

For more details, refer to Grafana Dashboard enhancements in the Grafana Template JSON file.

6.8 Storage Class Tier Support in CloudFS

The Storage Class configuration feature helps administrators reduce costs and simplify storage management by assigning objects to the appropriate storage class. CloudFS supports configuring following storage class -

• AWS S3 Storage Class
• Azure Storage Class
• Google Cloud Platform (GCP) Storage Class

Refer to License Manager.

6.9 Quota Management

Quota Management feature allows organisations to control and restrict the amount of storage space for individuals and groups to be consumed. By enabling this feature, CloudFS administrators can set defined usage limits, ensure appropriate resource allocation, and maintain stability in a distributed file system environment. It improvises decision-making through proactive monitoring and alerts. For more details, refer to Quota Management.

6.10 Geofencing Policy

Geofencing Policy allows CloudFS administrators to define fine-grained rules that restrict file or folder access at individual nodes within a CloudFS deployment from a live file system, regardless of the Active Directory permissions and Point-In-Time (PIT) snapshots. Once a geofencing rule is applied to a specific node, any user accessing the SMB share through that node will be restricted from reading or writing any content protected by the geofencing rule. For more details, refer to Geofencing Policy.

6.11 S3 Interface

The S3 Interface in CloudFS introduces seamless interoperability between traditional SMB-based file access and standard S3 protocol through S3 API and command-line interfaces like AWS S3. Any buckets and objects created via the CloudFS S3 service are also available through SMB and NFS, appearing as POSIXcompliant files and folders. CloudFS supports global read-write collaboration across both SMB and S3 protocols, additionally providing ability to enable the S3 interface for existing SMB shares.

Manage S3 Interface and use the S3 REST APIs to perform standard S3 API calls into native CloudFS file operations, storing data directly into CloudFS and enabling these objects to benefit from CloudFS-based data services.

6.12 Time-Series Statistics

Time-Series Statistics feature provides native support for an integrated time-series database based on InfluxDB. Organizations can use their monitoring solutions (like Grafana) pointing to this time-series database to visualize real-time system activity, storage performance trends, and overall operational health of the CloudFS deployment.

Enable the InfluxDB Stats from the Time-Series Stats Settings in and manage the InfluxDB-infused Grafana Dashboard.

6.13 Manage Share Access

CloudFS administrators can restrict the share access when creating or updating SMB shares for a specific node. Once specified, these shares are not visible and cannot be mounted on the restricted node. This feature strengthens the organization's ability to support complex enterprise environments, ensuring that share access aligns with business needs, operational boundaries, and security policies. For more details, refer to Manage Share Access.

6.14 Support for Role-Based Access Control (RBAC) for System Management

CloudFS offers seamless Single Sign-On (SSO) integration with leading Identity Providers such as Active Directory Federation Services (ADFS), OKTA, and Microsoft Entra ID. It supports standard authentication protocols including Security Assertion Markup Language (SAML) and OpenID Connect (OIDC), ensuring secure and efficient system management through the web UI. To configure Identity and Access Management (IAM) for CloudFS System Management using RBAC, refer to Access Control.

6.15 Audit Trail

Audit Trail feature in CloudFS offers a unified monitoring view via web UI and API interfaces to capture every transaction of the user and system actions across its deployment. This functionality supports organizational goals such as compliance, user security, and operational accountability by logging critical actions-create, update, and delete-performed by users including administrators, IDP-authenticated users, and those authenticated via Active Directory. Audit Trail offers a centralized, searchable view on the master node, while individual nodes retain their respective audit records, creating a full-spectrum snapshot of user activity across the entire environment. For more details, refer to Audit Trail

6.16 CloudFS Instant Node

The CloudFS Instant Node feature enhances the business continuity needs by saving cloud egress cost while simplifying the processes of node commissioning, restoring, and migrating the nodes.

Using a node's metadata and cache disks, or their Hypervisor snapshot, the node can be restored back in case of any disaster recovery need. In case of tier-1 cloud environments like AWS or Azure, the instance can be even restored on the other availability zones.

New node commissioning in an existing CloudFS deployment can be achieved in much faster way by cloning existing nodes - metadata and cache disks. CloudFS deployment can be migrated over newer infrastructure or cloud environments. For more details, refer to CloudFS Instant Node.

6.17 User Auto Scaling

The maximum number of SMB connections that are allowed is set based on system resources. The Panzura 5700/6700 hardware series limit is 5,000 connections. The limit for all other Panzura hardware series is 3,500 connections. A more granular scaling is applied for VM instances.

6.18 Enhanced regional store

The regional store feature allows subordinate nodes to maintain their own object store bucket configurations, enabling cloud storage to be aligned with preferred provider regions for improved performance and reduced network latency. With the enhanced regional store capability, subordinate nodes are capable of automatically downloading the snapshot from other configured object store bucket whenever the regional (local) bucket becomes inaccessible, ensuring seamless access and operational continuity. For more details, refer to Advance Settings

6.19 Enhanced Node Decommissioning

This feature streamlines infrastructure management by eliminating the manual lock migration task and automating the node decommissioning process. It also enables the file ownership transfer without any dependency on the node's availability with efficient transition. This reduces complexity, human error, and administrative overhead.

6.20 Extended RBAC support for OKTA Identity Provider using SAML & OIDC Protocols

This feature simplifies the user access to login with advanced Single-Sign-On (SSO) capabilities that are integrated with OKTA as an Identity Provider. It enables centralized. IAM (Identity & Access Management), enhanced role-based administration control for the storage management use cases.

6.21 UX Dashboard and PZIQ Settings

The UX Dashboard is a dedicated interface accessible independently of the standard dashboard, which requires administrator credentials. It provides enhanced visibility into user engagement by integrating advanced client experience metrics. This dashboard delivers a comprehensive understanding of user interactions and system efficiency, empowering teams to effectively monitor and optimize the overall customer experience.

PZIQ settings allow you to enable a comprehensive suite of advanced metrics seamlessly integrated into the CloudFS Statistical Collection System (SCS). These metrics are instrumental in enabling the Panzura Support Team to proactively monitor and maintain the health and performance of CloudFS nodes.

6.22 VM Support for Linux KVM (RHEL 9.4+)

CloudFS 8.4 has been qualified on RedHat Enterprise Linux (RHEL) release 9.4, running Linux kernel 5.14.0-427.28.1.el9_4.x86_64 and with appropriate KVM related packaging installed.

Among the KVM related packages are qemu-kvm, libvirt, and libvirt-client. In addition, depending on the environment, some or all of the following packaging: virtinstall, virt-manager, and virt-viewer. See RHEL documentation on virtualization for KVM packaging details.

Panzura provides a CloudFS image in the qcow2 format suitable for deployment as an import disk. CloudFS nodes have been deployed using both the virt-manager application and the virt-install tool, both versioned 4.1.0. The installation procedure using both tools can be found in the installation guide: https://know.panzura.com/deploying-cloudfs-as-a-kvm-virtual-machine The virt-manager application requires a graphical desktop. If the RHEL server on which CloudFS is to be deployed does not have graphics capabilities, then the virtmanager application can be run remotely on another RHEL system or other Linux system that has graphics capabilities and has network connectivity to the RHEL server.

The virt-manager application can be used to manage the CloudFS or any KVM VM, for example view the VM virtual hardware inventory and add new disk devices. It can also be used to view the VM console.

The virt-install tool is a command line utility that can be run from a shell on the RHEL server and provides the necessary options to deploy a CloudFS node. When the virt-manager application cannot be used to manage the CloudFS VM, due to lack of graphical capabilities, the virsh tool can. It provides a rich set of commands to view and manage KVM VMs.

CloudFS runs the QEMU Guest Agent (v9.0.1) which provides VM guest host specific information to KVM tooling.

6.23 Panzura Global Namespace

The Panzura unified namespace is an in-band file system fabric that consists of multiple physical file system instances converged into a single file system metaspace and mounted locally on each node with the root label "CloudFS."

The Panzura unified namespace does not rely on underlying distributed databases and thereby avoids common global namespace limitations that can affect speed, transactional data coherence, write order fidelity, open files, atomic precision, in-band operation, and global snapshots. By contrast, other global namespace architectures require a database process on each storage system and changes to file metadata require complex out-of-band operations.

6.24 Cloud Mirroring

Note: Cloud Mirroring is only applicable from CloudFS8 on. Cloud Mirroring allows you to copy data in real-time from one cloud object store to another cloud object store. Cloud Mirroring allows you to have an exact copy of your dataset.

When Panzura nodes are configured with two clouds, they have a cloud connector. This connects the Rest API to the object store. One cloud object store is labeled as the primary cloud, and the other cloud object store is labeled as the secondary cloud. When you have two clouds and data is being written, data is written to both cloud object stores at the same time. The data is not released from the cache until an MD5 checksum is received and matched to both of the cloud object stores. This ensures that your data gets to each cloud location without data corruption or data loss. When your Panzura node reads, it only reads from the primary cloud object store because it's unnecessary to read from both clouds when the data is identical. Writing to a cloud object store is free, but reading from a cloud object store can become expensive. Panzura nodes will only read from the secondary cloud object store if the primary cloud object store fails. If you have multiple nodes, communication (read and write requests) to each cloud object store occurs at each node location. This ensures that we have consistent data in both cloud object stores.

6.24.1 What triggers a failure?

One hundred and sixty consecutive read or write failures on the same piece of data triggers a cloud failure. If the primary cloud fails, a failure is triggered across the entire CloudFS. An entire CloudFS will not failover to an inconsistent cloud. After a failure occurs, every write and read request is sent to the secondary cloud. With every read and write that occurs, the primary cloud becomes more outdated because it's in failure mode.

While the primary cloud is down, the secondary cloud tracks the data that isn't being written to the primary cloud. When the primary cloud comes back up, your Panzura node detects this and starts writing to both clouds again. In the background, your Panzura node reads from the secondary cloud and writes the data that it missed while it was down to the primary cloud. The primary cloud does not become the primary again until the clouds are consistent again. Your Panzura node cannot absorb a failure until the primary cloud is consistent again.

6.24.2 How do I set up Cloud Mirroring if I'm an existing Panzura customer?

If you configure cloud mirroring as an existing customer that's been operating for some time, your primary and secondary cloud begin to receive write requests for new data, but the node needs to synchronize all of the existing data from the primary cloud to the secondary cloud before they are considered fully synced.

The time that it takes for the secondary cloud to become consistent with the primary cloud depends on the amount of existing data that your primary cloud has stored, the bandwidth allocated for each node to send data to the cloud, and latency. If you have a large amount of data, it could take days, weeks, or months for both of your clouds to become consistent.

You must have the proper bandwidth policy to support Cloud Mirroring. You must talk with your SE or Support representative if you are considering enabling this feature. As a best practice, for all existing and new users, always create a master snapshot before enabling the Cloud Mirroring. Under ideal conditions, Master Snapshot must also be created before any Disaster Recover (DR) to keep the big picture intact and quicken the DR process in case necessary.

To set up Cloud Mirroring, existing Panzura customers must upgrade to an 8.x release and contact support to ensure proper licensing.

6.24.3 Additional Links:

• Cloud Mirroring
• Cloud Mirroring Licensing

6.25 File Locking

CloudFS support several file locking mechanisms. A traditional file lock is a lock issued against a file by a file system, a server, or an application. The lock can consist of extensive application-specific meta information and be written into parts of the file payload and/or its file system metadata.

File coherency locks are file system locks that are issued by applications to arbitrate guaranteed consistency between applications writing/reading to a single file, for example, MSFT Office Application locks.

Opportunistic caching locks are delegated rights that are issued by a file server protocol engine for a remote client to cache a file locally to increase client-side performance. This is not necessarily a guaranteed write lock, because the delegation can be revoked by a file server at any time. Example: Microsoft SMB OPLOCKS.

6.26 Snapshots

Panzura uses snapshots to capture the state of the file system at a given point in time. There are two types of snapshots; system managed, and user managed. The system managed snapshots are used to provide file system consistency between nodes. In a process called syncing, CloudFS takes the changes (deltas) that occur to files and to the file system metadata, captures the delta information in a snapshot, and sends them to the cloud. The metadata portion of these changes is retrieved from the cloud by all other Panzura nodes in the cluster where they are used to update the state of the file system and maintain concurrency. This system updating occurs continuously across all nodes, with each node sending and receiving extremely small metadata snapshot deltas and using them to update the file system.

User managed snapshots are controlled by the administrator to provide file system backups in the shared cloud storage backend. You can schedule automatic snapshot creation or take snapshots on demand. They are visible to the end user so they can be used to retrieve old versions of files without involving IT administration. Panzura guarantees that each node will support more than 10,000 user-managed snapshots.

Panzura recommends creating a user snapshot schedule that meets your business needs while maintaining a reasonable number of snapshots per node when using a multi-node CloudFS configuration.

6.27 Smart Cache

CloudFS supports Smart Cache, which reserves a percentage of local storage to intelligently track hot, warm, and cold file block structures as they are accessed. The cache dramatically increases data availability and I/O performance, because file data-blocks reads have a higher probability of being serviced from local disk than directly from external cloud storage. The cache also increases overall data availability by masking variations in cloud availability. This allows the file system to continue serving I/O and cache-resident data-block reads even when the WAN link to the cloud storage slows or is unavailable, or if the cloud itself is down.

Cache policies govern what data is cached locally on the node. CloudFS provides fine-grained configuration control over caching through the use of policies, rules, and actions that result in improved performance and enhanced cloud storage availability for users. When configuring cache policies, Panzura recommends using the auto cache action with prepopulate enabled. This ensures that files are available in disk cache for end users. Prepopulating makes the data available without forcing a reduction in cache. Pinning allows an administrator to forcefully localize (pin) data in the cache within a node to provide guaranteed LAN speed performance. Because pinning consumes cache space, it should be considered only if needed for performance, with the trade-off between performance and cache space kept in mind.

Data is always protected in the cloud, irrespective of polices rules and pinning. See Smart Cache Settings.

6.28 Extended File System ACLs

The Panzura file system supports extended file system access control lists (ACLs) with full POSIX semantic compliance. For SMB, clients use a native Microsoft method with the Server Message Block (SMB) protocol for reading and writing extended ACLs. PFOS provides the ability to turn SMB signing on or off.

6.29 Scale out Global Deduplication

The node supports enhanced data deduplication within the global file system with high performance, scalability, and system-wide efficiency. The deduplication data architecture and physical layout on disk is optimized for local and global write performance and data addressability.

6.30 Enhanced Cloud Diagnostics

The node provides a robust set of diagnostic and measurement tools for monitoring and understanding the health, status, and performance of the Panzura cloud storage infrastructure and interactions. The cloud diagnostics features include tools to analyze the cloud, while the cloud metrics features present a detailed set of trended graphs to visually display metrics about cloud reads and writes. The system also generates alerts if the cloud becomes unavailable.

6.31 Intelligent Symantec NetBackup Integration

CloudFS supports intelligent integration with Symantec NetBackup, including awareness of the NetBackup data format stream. The system efficiently deduplicates the data stream inline with high optimization ratios. Tivoli TSM, Microsoft Robocopy and Symantec Backup Exec are also supported as cloud backup and cloud archive applications.

6.32 High Availability Solution

The Panzura High Availability (HA) solution consists of the following configuration options:

1. HA Local: An active node is protected by a dedicated standby. When the active node fails, the passive standby assumes its identity and takes over operations. The takeover operation can be automatic or manual. HA Local is similar to the methods used by legacy enterprise storage product. In this configuration, an active node is protected by a dedicated, passive standby. When the active node fails, the standby takes over ownership of the file system and the node operations. The following HA Local options are supported:
2. Local: The active and standby nodes have different hostnames and IP addresses.
3. Local with shared address: The active node and passive standby have an additional shared hostname and IP address, which simplifies the takeover process. This is required for Auto Failover. (Maximum length of the shared hostname is 15 characters.)
4. HA Global: One or more nodes are protected by one or more shared standbys, which can be separated geographically from the nodes they protect.

6.32.1 Auto Failover

HA Local can be configured for Auto Failover. Auto Failover enables either of the nodes in an active-standby pair that have a shared virtual IP (VIP) address to automatically perform a failover.

In an Auto Failover configuration, both the active and standby nodes regularly exchange health and status information. The nodes regularly exchange status information in two ways:

1. Directly over a peer-to-peer connection (SSH)
2. Post status information to the cloud in state files

6.33 DR Cloud Recovery

Full cloud disaster recovery (DR) allows rebuilding and recovery of an entire node from the cloud after a disaster has occurred. In this highly optimized and efficient process, the file system is brought online and established as active from its cloud metadata instances as soon as possible following the disaster. A minimal set of data blocks are recovered from the cloud to bring the system to a state where clients can start using the node, with remaining data downloaded in priority order.

6.34 Enterprise AntiVirus Plugin

Protecting file servers from viruses is an important part of an overall security strategy, and products such as McAfee VirusScan Enterprise and Symantec Protection Engine address this need well. You can install licenses to use these products to automatically scan files with the latest virus definitions.

6.35 FIPS

Note: FIPS is only applicable from CloudFS 8 onwards. Panzura CloudFS is FIPS 140-3 certified. To access this feature, FIPS 140-3 must be enabled or disabled in the command line interface (CLI) of each node. The enable or disable options for FIPS 140-3 mode are set on a per-node basis. Users need to enable or disable all nodes within a cluster at the same time to activate or deactivate FIPS services on a cluster wide basis.

Note: To enable or disable FIPS mode, perform steps 1-4 on each node. ** FIPS must be enabled on the master node, which will then propagate the configuration to the subordinate nodes. However, if FIPS is not already enabled on the subordinate nodes, you must enable it manually on each of them as well.

To access this feature, FIPS 140-3 must be enabled or disabled in the command line interface (CLI) of each node. If you need help with accessing the CLI, see Installing an Existing Key File (CLI).

For more details, refer to the article Enabling or Disabling FIPS 140-3 Mode.

7. CloudFS Instant Node

CloudFS Instant Node enables a significantly faster and more efficient approach to node recovery, new node commissioning, and infrastructure migration. This feature also helps reduce egress costs typically associated with traditional recovery and migration procedures. In the event of a disaster recovery scenario, a CloudFS node can be restored using its metadata and cache disks, or by leveraging a hypervisor snapshot. For cloudbased deployments (e.g., AWS or Azure), the node instance can also be restored in a different availability zone, ensuring higher resiliency and minimal downtime.

New node commissioning within an existing CloudFS deployment can be significantly accelerated by cloning an existing node's metadata and cache disks. Additionally, CloudFS supports seamless migration to newer infrastructure or cloud environments, enabling improved scalability and modernization with minimal operational disruption. The CloudFS Instant Node feature allows rapid recovery of the nodes during events like infrastructure issues, network failures, availability zone outages, or hypervisor problems.

7.1 Restore A Node (Recovering a node)

In the event of a disaster recovery need, a node can be restored using its metadata and cache disks or by utilizing its hypervisor snapshot. To successfully restore a CloudFS node, two key prerequisites are needed belonging to this same node:

1. System configuration backup
2. Metadata and cache disks in healthy state.

CloudFS Metadata and Cache Disks - These SSD disks are provisioned during the CloudFS node deployment time, which are used to store metadata and cache (data) to host the cloud file system locally. For successful disaster recovery of the node, it is critical that these disks remain healthy and up to date, or their recent hypervisor snapshot is available. These disks are necessary to fully restore the CloudFS node back resuming continuity of operations.

If the CloudFS node is deployed on a hypervisor that supports VM-level, time-consistent snapshots-such as VMware ESXi, which quiesces disk I/O before capturing the snapshot-it is recommended to configure hypervisor snapshots. This ensures protection of the metadata and cache disks attached to the CloudFS node, enabling reliable recovery in the event of failure. Please read a further section titled "Restore CloudFS node using Hypervisor snapshot" for more information on this context.

A system configuration backup is a skeleton of the CloudFS node containing different configurations like systems, network, licenses, services etc. which helps restoring the identity of the original node. This backup bundle is encrypted, and its size is hardly in few KBs.

There are two ways to take the system configuration backup:

1. Automated schedule backup: CloudFS node automatically takes its system configuration backup scheduled daily once and uploads to the CSP (Primary Cloud Bucket) and the CMP (Secondary Cloud Bucket) if configured. The system retains latest 10 configuration bundles in CSP/CMP.
2. Manual backup: An administrator, or any user with the appropriate RBAC-granted privileges, can manually initiate an on-demand system configuration backup. Once generated, the configuration bundle can be securely downloaded to their local machine for safekeeping for future node restoration need.

When a node is configured fully, a manual backup can be taken, and it can be used to restore the node to its up-to-date state. It is recommended that you take a manual backup upon any configuration changes are done over the node, for instance, a new SMB share has been created.

Steps for manual backup:

1. Login to the CloudFS UI.
2. Click on the Maintenance -> System Operations -> System Configuration.
3. Click "Generate". To locally save the system configuration, download it after the Generate button changes to Download.

Note: It takes about a couple of minutes to generate an encrypted backup bundle which is hardly in few KB size.

Prerequisites to restore a node:

1. Ensure the metadata and cache disks of the node are available over the same or similar hypervisor platform to restore that node. Notes:

• Read a further section titled "Restore CloudFS node using Hypervisor snapshot" if the node recovery to be done using a hypervisor snapshot.

• In case your destination instance type is different than one where the CloudFS instance was originally configured then you may need to convert the metadata and cache disks into that destination instance platform supported disk type. For instance, originally the CloudFS node was based on VMware VM having VMDK as the metadata and cache disks where the destination platform is Hyper-V, in that case these disks need to be converted to VHD type disks supported by Hyper-V.

2. Make a note of the disks paths indicated by the hypervisor management console. These disks are required to be attached to the CloudFS new node instance where the backed-up node recovery is required to be done.
3. If planning to use a manual configuration backup to restore a node, ensure the system configuration bundle is readily available. If restoring a CloudFS node using the backups available in CSP or CMP, make sure that the cloud credentials and base bucket path are readily available.

Note: There are articles that describe about the details of the prerequisites required and steps to perform the recovery the CloudFS node using CloudFS Instant Node on the supported environments (AWS, Azure, Nutanix, and VMware).

Steps to restore the CloudFS node

1. Login to the Hypervisor Platform (like - vSphere Client, Hyper-V manager, AWS EC2 instance) where the node recovery to be done.
2. Spawn a CloudFS node instance (for example, over VMware, HyperV, EC2 instance) using appropriate CloudFS image that matches the original CloudFS node. Keep this CloudFS software version same as the original CloudFS Node version.
3. Attach the metadata and the cache disks of the CloudFS node to this newly spawned instance.
4. Power on this new CloudFS instance.
5. Note the IP address of the new node and access CloudFS web UI as https://IP_ADDRESS.
6. On selecting Restore A Node option, you get two recovery wizards: From Cloud and From Localhost

• From Cloud: This option can be used to restore the node using one of the system-generated daily backups stored in the CSP/CMP bucket.
• From Localhost: This option can be used to restore the node using a manually taken system configuration backup.

Based on the above selected option, the node restore wizard will prompt for the necessary information. As explained below, network and cloud storage details are additionally prompted if backed-up configuration is not handy.

1. On Network (Client & Cloud) Settings: Select the following and update the appropriate network configuration:

• Shared Network (one-arm) /INLINE
• DHCP / STATIC

2. NTP Configuration

• Use NTP - Enabled

3. Cloud Service Provider: Select the Primary Cloud from the dropdown and provide the details of the cloud service provider, for example - Cloud host IP, access key, secret key, storage class, and the bucket path (mentioned during the initial node configuration).
4. On Select Node, all the nodes available in the CloudFS ring are available with its system configuration backups. By default, the latest backup is auto selected. Select the appropriate backup.
5. On Confirm admin Password, provide the password for the admin user of the node which you want to restore.
6. On Validating Data and Metadata disks, verify that the disks that are attached to node are accurate.
7. On the Network Settings and Time Settings, verify the settings and click Next.

Note: These are the permanent network settings applied to the CloudFS node post restore. 8. On the Restore Configurations Details, verify the selected configuration. Click Proceed on this confirmation page to proceed with restore the selected node. Post restore, the restore environment will reboot automatically resulting into the original node bootup process. Once the node reboots, it automatically resumes the functionality in its original state. 9. By clicking on Cancel, you can navigate back to make any required configuration changes. 10. Post reboot, login to the administration web UI of the CloudFS node and confirm the node status and other statistics. Check notifications panel for the successful restore completion message and any notifications for pending hot patch installations. Verify that the new restored node has the exact configuration as that of the original node like historical data on the Dashboard, system, and network settings in the Configurations tab.

Note: If duplicate hostnames appear due to a hostname case change:

• Select the lowercase hostname, OR
• Select the entry with the latest backup timestamp, as it represents the most recent node configuration.

Restore CloudFS Node Using Hypervisor Snapshot

The CloudFS Instant Node feature allows administrators to restore a CloudFS node using metadata and cache disks recovered from a point-in-time (PIT) hypervisor taken VM snapshot. In virtual environments, such snapshots capture the complete VM state — including data disks, OS disks, and memory — providing a reliable recovery option in the event of node failure or corruption. Restoring the OS disk is not required; only the meta and cache disks are essential for node recovery.

For deployments on virtualization or cloud platforms such as VMware, Hyper-V, AWS, or Azure, it is recommended to: - Configure a daily VM-level snapshot. - Retain the last 2–3 snapshots in rotation to avoid performance degradation. - Schedule snapshots during off-peak hours to minimize system impact.

Important Note: CloudFS node should not be restored using VM in-memory snapshot.

Restoring a CloudFS node using VM in-memory snapshot may cause boot failures or risk overwriting older cloud data. If such a snapshot was reverted, reboot the VM immediately after restoration to ensure successful recovery.

As shown in the image, deselect the option 'Include virtual machine's memory'.

The support for hypervisor snapshot restore is enabled by default, eliminating the need for manual intervention. Once enabled, the data path (DP) service automatically checks for differences in snapshot counts in the cloud and downloads any missing snapshots. This enhancement simplifies the disaster recovery workflow.

Note: When restoring a node from hypervisor snapshot, it may take some time to download the latest uploaded CloudFS snapshots in the CSP / CMP. This depends on:

• Number of snapshots to sync.
• Availability of network bandwidth.

The status can be viewed by logging into the node.

7.2 Commission a New Node

The CloudFS Instant Node feature supports efficiently commission new subordinate node using metadata and cache disks of either belonging to the master or any subordinate node within the same CloudFS ring.

Note: This enhanced feature of new node commissioning only supports active subordinate node creation and not LHA or GHA type nodes. There are two ways to commission a new node:

• New Configuration: This is the legacy way to create a new CloudFS node. Refer to the section "Accessing the Setup Wizard" to perform the steps to configure the CloudFS node with this existing method. For example, $>$ Deploying CloudFS as a KVM Virtual Machine $>$ Panzura CloudFS Setup Wizard section.
• Clone Existing Node: This is the new subordinate node commissioning process using CloudFS Instant Node feature.

Select Option

Prerequisites for Clone Existing Node (i.e.: new node commissioning) method:

1. Select a healthy active node where the snapshot sync status is relatively up-to-date and there are no critical alarms in the CloudFS dashboard.
2. Generate the latest system configuration of the source node. If not, then Generate the latest system configuration from the source node (Web UI > Maintenance $>$ System Operations $>$ System Configuration).
3. Do clone the VM or take VM snapshot to clone the metadata and cache disks from the source CloudFS node using the hypervisor supported disk cloning method. These disks should be available in the destination environment where the new node is to be commissioned.
4. Ensure a unique hostname and network connectivity is available to configure over the newly commissioned node.

Note: For new node commissioning, only License token-based activation option is currently supported. Currently, files-based license option is not supported. 5. Proxy-server configuration: In case, the destination network where the new node is being commissioned has proxy server-based network connection to communicate with cloud (or internet) the do keep this proxy server configuration handy. Note: Disk expansion can only be done after node commissioning is complete. Do not attach any other disks apart from the metadata and cache disks during the commissioning workflow.

Steps to perform new subordinate node commissioning:

1. Login to the destination hypervisor platform (For instance, VMware, Hyper-V, Azure or AWS) where the destination node to be created.

2. Create a new virtual machine of the same CloudFS image version that of the source CloudFS node. For example, source node of version 8.5.1.
3. Attach the cloned meta and cache disks created in above prerequisites (step 3) to this new virtual machine.
4. Power on the new virtual machine.
5. Access this bootstrapped CloudFS instance web UI using the displayed IP address over the booting console - https://ip_address.
6. As shown in the above web UI screenshot, select the option New Node > Clone Existing Node. Click Start.
7. EULA page is launched. Accept the license, provide mandatory fields and click Next.
8. Read the Required information displayed and click Next.
9. On Upload System Configuration page, click Browse. Upload the system configuration bundle downloaded in step 2. Click Next.
10. On the Confirm Node admin Password page, provide the admin password of the source node and click Next.

Note: Make sure you enter admin password of the source node whose disks and configuration being cloned. 11. Validate the metadata and cache disks and click Next. 12. On the Network (Client & Cloud) Settings page, choose between DHCP or static network IP-address settings, primary and optionally secondary DNS server configuration. The source node network configuration can also be referred on this page. 13. Provide hostname to new subordinate node, location and domain controller details and click Next. 14. On Panzura Licensing page, provide the license token and click Next.

Note: In R_8.5.1 release we do not support license file based new node commissioning. Only license token-based registration is supported. 15. On successful registration of license, set NTP settings. Click Next. 16. On the Configuration summary page, all the selected configuration details of the new node are displayed. You can go back and make any required changes if needed. Click Next. 17. On Active Directory Setup, provide the domain controller details and click Finish tostart commissioning process. 18. Post successfully node commission, CloudFS dashboard appears on the web UI. Make a note that, the new node does not reboot but directly gets online and active. Note: Cache policy settings are local to each node and are not copied from the source node during provisioning. After provisioning a new node, the CloudFS administrators must manually verify and configure the Smart Cache policy and other cache-related settings to match the desired configuration. 19. Do run cloudtest to confirm new node connectivity to CSP and CMP cloud storage endpoints. This option can be executed from the web UI maintenance page.

7.3 Restore VMware virtual machine Hypervisor snapshots

Hypervisor Snapshot Restore (HSS) enables administrators to recover a CloudFS node by restoring metadata and cache disks from a point-in-time (PIT) virtual machine snapshot. Hypervisor Snapshot Restore (HSS) enables administrators to recover a CloudFS node by restoring metadata and cache disks from a point-intime (PIT) virtual machine snapshot.

In a virtualized environment, a VM snapshot typically captures the full VM state, including Operating system disks, Metadata disks, and Cache disks. Hypervisor Snapshot Restore (HSS) provides a reliable recovery option for scenarios such as node corruption, configuration issues, or unexpected failures.

When a hypervisor snapshot is restored to an earlier point-in-time, the CloudFS node also rolls back to that earlier state. However, ZFS snapshots that were already uploaded to S3 remain at their most recent state. This creates a mismatch between:

• The restored CloudFS node metadata (older state)
• The ZFS snapshots available in S3 (newer state)

After the restored CloudFS node boots, it detects that newer snapshots exist in S3 and automatically starts a catch-up process to synchronize with the latest available snapshot state.

Example:

1. A VM snapshot is taken at time T1.
2. Additional ZFS snapshots are uploaded to S3 at times T2 and T3.
3. The VM is later restored to snapshot T1.
4. After reboot:
5. CloudFS metadata reflects the state at T1.
6. S3 still contains newer snapshots from T2 and T3.
7. CloudFS starts a catch-up operation to reconcile the restored node with the latest snapshots stored in S3.

HSS is designed to handle rollback-and-recovery scenarios safely by detecting restored snapshot states and ensuring that the node can synchronize correctly with the latest backup data available in object storage.

7.3.1 Operational Considerations

Keep the VM powered off after Snapshot Restore

After restoring a hypervisor snapshot, keep the virtual machine in a powered-off state until the recovery workflow is initiated correctly.

• Risks of automatic power-on after restore.
• Always restore the VM snapshot in a shutdown state.
• Complete recovery validation before powering on the node.
• Allow CloudFS to perform the required catch-up and synchronization process safely.

VM power state during Snapshot Restore

If the point-in-time (PIT) snapshot on the hypervisor was taken with virtual memory included, the VM may automatically return to a powered-on state when the snapshot is restored.

In that case, the VM resumes from the captured memory state instead of starting from a clean shutdown state. This behavior is risky for CloudFS recovery because:

• The node may resume operations with outdated metadata.
• Older snapshot state may overwrite newer snapshot information already stored in S3.
• The required catch-up and synchronization workflow may not complete correctly.
• This can lead to metadata inconsistency and possible data corruption.

How to avoid this issue

• Do not restore snapshots directly into a running state.
• When using HSS workflows, prefer hypervisor snapshots that do not preserve VM memory.
• If the hypervisor platform does not support production-ready, crash-consistent snapshots or checkpoints, take the VM snapshot while the VM is powered off.

7.3.2 Recommended practice

• Complete recovery validation before powering on the node.
• Allow CloudFS to perform the required catch-up and synchronization process safely.

Create hypervisor snapshots without including virtual memory

The following examples show how to create hypervisor snapshots without including virtual memory.

1. VMware snapshot

When creating a VMware snapshot, make sure that the option Include virtual machine's memory is unchecked.

2. Hyper-V checkpoint

When creating a Hyper-V checkpoint, make sure the default checkpoint type is set to Production Checkpoints and that the option Create standard checkpoints if the guest does not support creation of production checkpoints is unchecked.

3. Azure restore point

When creating an Azure restore point, select only Crash Consistent mode. Do not use App Consistent mode, because it can include live memory state.

4. AWS EC2 snapshot

When creating a snapshot on AWS, select an instance-level snapshot to capture the crash-consistent state of the CloudFS node.

8. Panzura Quick Start Guide

8.1 Web Browser Requirement

The Panzura node's WebUI and setup wizard are supported on below mentioned browsers:

8.2 Deployment Mode: One-arm or Inline

The node can be deployed in either of the following modes:

1. One-arm mode: Client and cloud traffic pass through the same interface. Connect LAN1 to clients and to your Cloud Storage Provider (CSP).
2. Inline: Client and cloud traffic use separate interfaces. Connect LAN1 to clients and WAN1 to your CSP. The LAN and WAN ports must be on different subnets.

8.3 Pre-installation Checklist

Before you log onto the node for initial setup using the wizard, see the tables in Gather Information. Filling in a copy of the tables prior to starting the setup wizard on the node can help make the initial deployment process easier and quicker.

The following table lists the information items you will need to enter or select when using the setup wizard. To simplify deployment, you may want to fill out the table before you log onto the node for initial setup using the wizard.

1. Name
2. Email
3. Title | | | Login Credentials for the Node(s) | | | Administrator username and password for the Master node. Default: admin, admin Note: For AWS AMI and Microsoft Azure VM platforms, the node does not have a default password. Instead, the initial password for the admin login comes from one of the following sources:

• AMI: The initial admin password is dynamically generated by encrypting the key file ( $\backslash$*.pem).
• Azure: The password is entered by the user during Azure VM deployment. | | | Note: After initial deployment using the setup wizard, all nodes within the CloudFS require the Master node's admin username and password for login. | | | Operational Mode | |

Function that the node will serve:

1. Master: The managing node for a group of distributed nodes deployed as a CloudFS. All licenses and configuration settings are added to the Master node and automatically propagate to the Subordinate nodes.
2. Subordinate: By default, all nodes are set as Subordinates, and are managed by the designated Master.
3. HA-Local: The node will be a standby for another, active node. The HA-Local node is a dedicated backup for only one other node, and both nodes must be in the same IP subnet.
4. HA-Global: The node will be a backup for n active nodes. The active nodes can be located remotely or in the same subnet as the HAGlobal node.

Type of network deployment (one-arm or inline):

1. Inline: If the cloud traffic and client traffic are on different networks, then this is the recommended deployment option. In an inline deployment, the node is connected to the network by separate LAN and WAN interfaces.
2. One-arm: In a one-arm deployment, the node is connected to the network through a single interface (LAN). The node is not directly in the traffic path between the internal and external networks. Use this method only if the cloud and client traffic are on the same network.

LAN (Client-side) Addresses

The node's IP address can be assigned by DHCP or statically. Tip: Best practice is to use static addressing. For static addressing, gather the following information:

1. node IP address and subnet mask
2. Default gateway
3. Primary DNS
4. Secondary (backup) DNS

WAN (Cloud) Addresses

For inline deployment only:

1. Host IP address and subnet mask of node
2. Default gateway

General Node Settings

node hostname File system name node domain name NTP server address Master node information (used when setting up non-Master nodes):

1. Master node's hostname
2. Login username and password for Master node's WebUI

Hostname/IP address and filesystem name of the active node if this node is an HA-Local standby.

Licenses

You can install Panzura licenses using a license token or individual license files.

1. License Token: A single license token contains the license to operate, along with licenses for additional storage services. During setup, the wizard communicates with the license server to validate the token. This is the simpler method and is recommended for new deployments.
2. Individual License Files: License files apply to individual features. A typical installation requires multiple license files. To obtain a license token or individual license files for your node, please contact Panzura or your Panzura representative.

Cache Sizing

Cloud Storage to Allocate: Estimate how much storage will be moved to the cloud. The default is 1 TB .

Percentage of Cache: Estimate the percentage of cloud-stored data to keep in the node's cache for local access. This depends upon the use case typically $10\%$ is a good starting point.

Virtual Disk Settings *(VM nodes only) For VM platforms, you will need information to assign disk capacity for metadata and cache.

1. Amazon: You will need the private key file, AWS access key and AWS secret key.
2. Azure: Make sure that you added disk capacity when setting up the VM. For information on setting up a VM in Azure, see the installation guide for your Panzura node platform.
3. VMware: You will need the ESX host IP address or hostname, username and password to access the host. The ESX host must be managed by a vCenter/vSphere. The username and password ESX credentials are required to access the vCenter/vSphere server to provide and choose a list of datastores. They are not used to access the host (through SSH).

Cloud Storage Provider (CSP)

Gather the information required for your cloud provider. (See [Cloud Provider Information] (https://know.panzura.com/set-up-the-filer).

8.4 Site Preparation

Panzura nodes use certain protocol ports as part of its normal operation. The firewall through which traffic to or from the node will pass may need to be configured to allow this traffic. The table below lists the protocol ports that Panzura nodes use.

The table in Required Ports lists the protocol ports that Panzura nodes use.

Table Notes

For each protocol port, the table lists the node's physical port (LAN or WAN) on which the traffic is expected, and whether sessions are initiated by the node or by another device:

• In: Session traffic is initiated by another device and received by the node on the indicated port.
• Out: Session traffic is initiated by the node and sent out the indicated port.
• Both: Session traffic may be initiated locally or remotely.

In One-arm mode, local traffic (LAN) and cloud traffic (WAN) uses the LAN port. For this reason, the LAN column applies to both LAN and WAN traffic.

1. A route from the node to the Internet.
2. Access to DNS. SA is located at the following URL: sac connect.panzura.com | | 53/TCP 53/UDP | Out | | Out | DNS | | 80/TCP 443/TCP | | Out | Out | HTTP/HTTPS access to object store in cloud | | 88/TCP 88/UDP | Out | | Out | Kerberos | | 111/TCP 111/UDP 2049/ TCP 2049/UDP 4045/ TCP 4045/UDP | In | | In | Network File System (NFS) protocols: RPC, NFS, and lockd Note: Required only if NFS support will be enabled on the node(s). | | 123/UDP | Out | | Out | Network Time Protocol (NTP) | | 137/UDP 138/UDP 139/ UDP | Out | | Out | NetBIOS (WINS) | | 161/TCP 161/UDP 162/ TCP 162/UDP | Both | | Both | SNMP SNMP traps | | 389/TCP 389/UDP | Both | | Both | LDAP Active Directory (AD) | | 445/TCP 445/UDP | In | | In | SMB file protocol | | 514/UDP | Out | | Out | Syslog Note: Optional. Needed only if the node will send its logs to a remote syslog server. 514 is default port, Port Range 1-65535 is supported. | | 35357/TCP | | Out | Out | HP Cloud object store Note: Required only if |

8.5 Cloud Storage Provider Requirements

Check with your CSP or Panzura Support. See Cloud Provider Information. Node IP Address You will need to navigate to the node's IP address to start the setup wizard. The LAN1 port on physical platform nodes is configured for DHCP by default. If a DHCP server is not available, the node uses the following default addresses:

1. Management (WebUI, CLI, API): 192.168.88.88
2. iDRAC interface: 192.168.88.89 VM platform nodes receive their IP settings from the VM host.

8.6 Finding the node IP Address

On a physical node, do any of the following:

1. Connect to the iDRAC port and log in (admin, admin). Java is required.
2. Connect to the CLI console on the Serial port, $\log$ in (admin, admin), and enter the following command: show mgmt-if-addr On a VM node, see the VM host or VM manager.

8.7 Changing the node IP Address (using the CLI)

If you plan to change the IP address when using the setup wizard, skip this section. Otherwise, to change the node IP address using the CLI:

1. Power on the node.
2. Attach a laptop PC to the node:
3. To use iDRAC, attach a laptop PC to the iDRAC port and open a terminal emulator. Enter console com2 followed by the commands shown in step 3.
4. To use the CLI, attach a laptop PC to the Serial port. Open a terminal emulator and enter the commands shown in step 3.
5. Enter the following commands:
6. cloudfs $>$ enable
7. Password: enable
8. cloudfs@ configure terminal
9. cloudfs(config)@ mgmt-if-mode Static
10. cloudfs(config)@ mgmt-if-addr
11. cloudfs(config)@ exit
12. cloudfs@ write memory
13. cloudfs@ logout

Browser Requirement:

The Panzura node's WebUI is supported only on Google Chrome version 59.03071 or above.

1. Power on the node (if not already on).
2. Use a browser to navigate to the node's management address (WebUI address).

Follow the instructions on the wizard screens. (Make sure to click Help to display the help text!)

1. The Panzura node's WebUI is supported only on Google Chrome version 59.03071 or above.

2. Depending on the node model, the LAN1 interface may have any of the following names: LAN1, bge0, ix0. Likewise, the WAN1 interface may have any of the following names: WAN1, bge1, ix1.
3. If the node includes the optional 10 GB NIC, the 10 GB ports are used for LAN1 and WAN1 instead of the 1 GB ports.
4. If NIC teaming is used, the teamed ports (GB1 and GB2) can both be LAN ports or WAN ports, based on configuration.
5. In inline deployment mode, the LAN and WAN ports must be on different subnets.
6. The capitalization used when first configuring the node host name persists for all CloudFS configuration operations. You cannot change the capitalization at a later time. However, you can change to a different host name.
7. If you are using SMB/CIFS, make sure your AD Server hostname is resolved by your DNS server and reachable on the LAN1 network.
8. Either static or DHCP address assignment is supported. However, for all node platforms, Panzura recommends using a static address.
9. Setup of a physical platform node's IP address requires either a direct Ethernet connection to the node (to the iDRAC port or serial console), or access to the IP subnet of the WebUI IP address.
10. When you deploy an AMI or Azure node, a private IP address is required to access the node's setup wizard. This is because Secure Private Network Mode, which is enabled by default, blocks public IP access. After you disable Private Secure Network Mode from within the wizard, you can change to a public IP address.
11. All WAN accelerators, such as the Riverbed Steelhead and Cisco WAAS, must bypass all Panzura network traffic. This includes all of the following.
12. WAN accelerators must not be in the network path between Panzura nodes.
13. WAN accelerators must not be in the network path between Panzura nodes and the cloud.
14. WAN accelerators must not be in the network path between Panzura nodes and clients.
15. For SMB, the node needs to join the AD domain that enforces the RBAC policies. Enabling a storage device to join the AD domain can be delegated to any user with this privilege. Panzura has found that in most cases, AD administrators tend to manage the devices that can join the AD domain. For this reason, AD administrator credentials are required during initial setup of a node.
16. The Panzura node's WebUI is supported only on Google Chrome version 59.03071 or above.
17. Depending on the node model, the LAN1 interface may have any of the following names: LAN1, bge0, ix0. Likewise, the WAN1 interface may have any of the following names: WAN1, bge1, ix1.
18. If the node includes the optional 10 GB NIC, the 10 BG ports are used for LAN1 and WAN1 instead of the 1 GB ports.
19. If NIC teaming is used, the teamed ports (GB1 and GB2) can both be LAN ports or WAN ports, based on configuration.
20. In inline deployment mode, the LAN and WAN ports must be on different subnets.
21. The capitalization used when first configuring the node host name persists for all CloudFS configuration operations. You cannot change the capitalization at a later time. However, you can change to a different host name.
22. If you are using SMB/CIFS, make sure your AD Server hostname is resolved by your DNS server and reachable on the LAN1 network.
23. Either static or DHCP address assignment is supported. However, for all node platforms, Panzura recommends using a static address.
24. Setup of a physical platform node's IP address requires either a direct Ethernet connection to the node (to the iDRAC port or serial console), or access to the IP subnet of the WebUI IP address.
25. When you deploy an AMI or Azure node, a private IP address is required to access the node's setup wizard. This is because Secure Private Network Mode, which is enabled by default, blocks public IP access. After you disable Private Secure Network Mode from within the wizard, you can change to a public IP address.
26. All WAN accelerators, such as the Riverbed Steelhead and Cisco WAAS, must bypass all Panzura network traffic. This includes all of the following:

• WAN accelerators must not be in the network path between Panzura nodes.
• WAN accelerators must not be in the network path between Panzura nodes and the cloud.
• WAN accelerators must not be in the network path between Panzura nodes and clients.
• For SMB, the node needs to join the AD domain that enforces the RBAC policies. Enabling a storage device to join the AD domain can be delegated to any user with this privilege. Panzura has found that in most cases, AD administrators tend to manage the devices that can join the AD domain. For this reason, AD administrator credentials are required during initial setup of a node.

9. Setting Up the Panzura Node

The setup wizard will guide you through the initial setup and configuration of the node. When completed, your node will have the necessary information to start file services and connect users.

9.1 Node Information

To prepare for installation and deployment of the Panzura node, gather your site's values for the deployment settings listed in this table.

Deployment Setting

End User License Agreement (EULA) and Admin Info

You will need to agree to the EULA, and enter the following contact information:

• Name
• Email

Login Credentials for the node(s)

Administrator username and password for the Master node. Default for most platforms: admin, admin After initial deployment using the setup wizard, all nodes within the CloudFS require the Master node's admin username and password for login. Note: For AWS AMI and Microsoft Azure VM versions of the node, the node does not have a default password. Instead, the initial password for the admin login comes from either of the following sources:

• AMI: The initial admin password is dynamically generated by encrypting the key file (*.pem).
• Azure: The password is entered by the user during Azure VM deployment.

Configuration Mode

Function that the node will serve:

• Master: The managing node for a group of distributed nodes. All licenses and configuration settings are added to the Master node and automatically propagate to the Subordinate nodes.
• Subordinate: By default, all nodes are set as Subordinates, and are managed by the designated Master.
• HA-Local: The node will be a standby for another, active node. The HA-Local node is a dedicated backup for only one other node, and both nodes must be in the same IP subnet.
• HA-Global: The node will be a backup for n active nodes. The active nodes can be located remotely or in the same subnet as the HAGlobal node. Type of network deployment (one-arm or inline):
• Inline: This is the recommended deployment option, provided that the cloud traffic and client traffic are on different networks. In an inline deployment, the node is connected to the network by separate LAN (GB1) and WAN (GB2) interfaces.
• One-arm: In a one-arm deployment, the node is connected to the network through a single interface. The node is not directly in the traffic path between the internal and external networks.

Virtual Disk Settings *(VM nodes only)

For VM platforms, you will need information to assign disk capacity for metadata and cache. You will need the private key file, AWS access key and AWS secret key. Make sure that you added disk capacity when setting up the VM. For information on setting up a VM in Azure, see the installation guide for your Panzura node platform. You will need the ESX host IP address or hostname, username and password to access the host. ESX host must be managed by a vCenter/vSphere. The username and password ESX credentials are required to access the vCenter/vSphere server to provide and choose a list of datastores. They are not used to access the host (through SSH).

• Amazon: You will need the private key file, AWS access key and AWS secret key.
• Azure: Make sure that you added disk capacity when setting up the VM. For information on setting up a VM in Azure, see the installation guide for your Panzura node platform.
• VMware: You will need the ESX host IP address or hostname, username and password to access the host. ESX host must be managed by a vCenter/vSphere. The username and password ESX credentials are required to access the vCenter/vSphere server to provide and choose a list of datastores. They are not used to access the host (through SSH).

Cloud Provider

Gather the information required for your cloud provider, as listed in the table in Cloud Provider Information.

9.2 Cloud Provider Information

Gather the information listed in the following table for your cloud storage provider (CSP).

CSP Settings

Amazon

• S3 bucket path
• S3 access key
• S3 secret key
• S3 bucket name cloud size (TB)
• Cloud host IP address or hostname

AT&T

• Folder name
• User ID
• Subtenant ID Subtenant ID:serviceclass=Policy Policy can be :serviceclass=policy1 or :serviceclass=policy2.

Example:

Subtenant ID:serviceclass=policy2 The policy types are case sensitive, and they all must be lowercase. Refer to AT&T for information regarding policy1 and policy2. Note: Changing this setting requires a reboot of the node.

• Shared secret
• Atmos node name
• Your Atmos (RMG) Resource
• Mgmt Group site node name
• Shared secret
• Cloud size (in TB)

9.3 Bringing Up a Node for the First Time

Power on the node to begin the setup process. After powering on a node, you can use the setup wizard to begin configuration. To access the setup wizard, use a browser to navigate to the node's WebUI IP address.

9.3.1 Static Node IP Address Recommendation

Panzura recommends setting the node's IP address to a static IP address.

9.3.2 Node IP Address Assignment

The LAN ports on physical platform nodes are configured for DHCP by default. If a DHCP server is not available, the node uses the following default addresses:

1. Management (WebUI, CLI, API): 192.168.88.88
2. iDRAC interface: 192.168.88.89

VM platform nodes receive their IP settings from the VM host.

9.3.3 Finding the Node IP Address

You will need to know the node's IP address to access the WebUI and start the setup wizard.

1. VM platforms: If your node is deployed on a virtual machine, obtain the assigned IP address from the management interface on your virtual machine host.
2. Physical platforms: For a physical node platform, you must connect to the console to obtain the address.

Use an Ethernet cable to connect a laptop PC to the iDRAC port on the node. Set the laptop IP address statically to the 192.168.88.00 network. Point your browser to https://192.168.88.89 and log in to the console using the default credentials admin/admin.

The assigned IP address is displayed when you access the console.

1. Either static or DHCP address assignment is supported. However, for all node platforms, Panzura recommends using a static address.
2. Setup of a physical platform node's IP address requires either a direct Ethernet connection to the node (to the iDRAC port), or access to the IP subnet of the WebUI IP address. If you plan to change the IP addresses using the setup wizard, configure your laptop to join the 192.168.88.0 subnet. The node's default WebUI and iDRAC addresses are in this subnet.
3. When you deploy an AMI or Azure node, a private IP address is required to access the node's setup wizard. This is because Secure Private Network Mode, which is enabled by default, blocks public IP access. After you disable Private Secure Network Mode from within the wizard, you can change to a public IP address.

9.4 Accessing the Setup Wizard

Note: Only pertains to Panzura version 7 nodes. After an IP address is assigned to the node, use the Chrome web browser (version 59.03071 or above) to navigate to the node's IP address to log onto the setup wizard, you will see the below screen:

CloudFS introduced two ways to create a node - New Configuration and Clone Existing Node option. It simplifies and offers a cost-effective way to commission subordinate and local HA nodes.

See the Installation Guide for your Panzura node platform for detailed instructions. After you complete the setup wizard, the browser redirects to the node's regular web UI. You have the option to use another wizard (configuration wizard) within the regular web UI. If preferred, you can perform configuration without the configuration wizard.

9.5 Configuration Wizard

The configuration wizard manager opens when you click Continue with Optional Wizards at the end of the setup wizard.

10. Using the CloudFS Dashboard

10.1 Default Dashboard

The default Cloud File System dashboard provides an overview of system resources and activity. This dashboard cannot be modified or deleted, but you can change the time period for the displayed data. See Adjust the Date Range.

Here are the types of information shown on the Dashboard above.

10.1.1 Network Throughput

This chart displays the network throughput for the past hour.

10.1.2 Active Node Status

This chart displays the sync status of other nodes in the CloudFS relative to this one.

10.1.3 Local Events and Global Events

This list displays the critical events that have occurred in the last 5 minutes.

10.1.4 SMB Statistics

This chart displays the SMB Statistics based on CPU and RAM count linked here.

1. The number of connected users is the actual number of actively connected users.
2. Locked files are the total number of open files and folders.
3. File System Error Disconnects are the disconnects that occur due to a client essentially timing out.
4. SMB Error disconnects is due to the SMB process crashing on the server-side (this is less common).
5. Total Disconnects include normal disconnects so for instance clients logging out.
6. And lastly, the limit line is a system enforced limit on the number of connected users.

The goal here is to better show when the customer is reaching the limit and their connected users and allow users to see trends or spikes in the number of disconnects that might indicate that there is an issue with the node.

10.1.5 Cloud IO

This chart displays the Cloud Traffic

10.1.6 Cloud Status

This chart displays the status count for cloud uploads and downloads.

1. Red. Failed $>0$ and succeeded $=0$
2. Yellow. Failed $>0$ and succeeded $>0$
3. Green. Failed $=0$

10.1.7 Local Disk Usage

This chart displays the disk space utilization of a node, categorized by key parameters that indicate how storage is allocated and used.

1. Pinned: Displays the amount of data permanently retained in cache memory.
2. Free: Indicates the free disk space not yet allocated either as cache space or metadata.
3. Dirty: Indicates data that has been modified but not yet uploaded to cloud.
4. Cached: Represents the portion of disk space used for caching frequently accessed data.
5. Metadata: Shows the space consumed by metadata structures managing data. In case of CloudFS node having hybrid disk setup, further metadata classifications are shown:
6. Used Metadata: Indicates the amount of metadata space currently in use.
7. Free Metadata: Display the remaining metadata space available for allocation.
8. Reserved: Displays disk space set aside for system or recovery operations.
9. Orphan Space: Highlights space allocated but not being used by any active data or metadata.

10.1.8 Disk Health

This chart evaluates the overall health of the node's local disks based on space usage and metadata thresholds. It provides a status indicator along with reasons and recommendations.

Possible Status Indicators:

(1) Local disk is healthy

• Sufficient space available for cache and metadata operations.

(2) Node rebuild required

The node is running out of usable data or metadata space due to below potential problems. It is recommended to rebuild the node to reclaim the wasted disk space than adding additional disks. Contact Panzura Support to rebuild a node without affecting the availability.

• Very high metadata or orphan space detected.
• High cloud virtual device leaked space.

(3) Additional disk required

The node is running out of usable cache or metadata space where additional disks are genuinely required to continue the node operation. If no action is taken soon, the node may run out of space and eventually enter into read-only mode.

10.1.9 Global Status

This table displays the following information:

1. Managed Storage: Proportion of storage that is managed and free.
2. Cloud Storage: Proportion of cloud storage that is managed and free.

10.1.10 HA Node Status

The HA Node Status dashlet shows the following information:

• Local HA: Names of the file systems on the Nodes in the active standby pair. The primary Node is the one that initially is the active Node. The asterisk (*) indicates that the Node that is currently active.
• Global HA: Name of the Node that is configured as the standby for Global HA. | | State | The HA state of the file system:
• Ready: Failover is possible.
• Not Ready: Failover is not possible because at least one of the Nodes is currently not meeting criteria for failover. For example, in an Auto Failover configuration, if the active Node's number of dirty snapshots is too high, an automated failover is not allowed.
• Down: The file system is down. | | Auto Failover | State of the Auto Failover feature. |

Auto Failover Details

To display Auto Failover details for an active-standby pair of Nodes, click on a row in the Primary / Secondary column of the HA Node Status dashlet. The Auto Failover Status dialog appears:

In this example, Auto Failover details for active-standby pair cc8 / cc7. The active Node in the pair is cc8.

Active Cleanup

Indicates if an active cleanup is underway following decommissioning.

10.1.11 Scaling and Performance

This chart displays the performance data for the specified interval.

10.1.12 CPU Utilization

This chart displays the status of system resources.

1. CPU: Shows current percent of CPU usage. Colors change from green to red as the load increases.
2. Memory: Show the current percent of memory used. If swap space is being used, the swap space value is also presented. The green box turns red if memory usage reaches $90\%$ or greater or if swap space used is greater than 1 GB .

10.1.13 System Memory

This chart displays the information about the node storage configuration.

10.1.14 Objects To Delete

This chart displays the information about the objects to be deleted.

10.1.15 Objects Deleted

This chart displays the information about the deleted objects.

10.1.16 Managed Capacity

Managed Capacity in CloudFS displays the total the size of active data in the native file system, excluding snapshots in the managed capacity calculations. The chart highlights:

• Monthly peak usage.
• Usage over the last 24 hours.
• Past months' consumption (recorded on the last day of each month).
• Total purchased capacity for comparison with actual usage.

It also displays usage trends up to 5 years, helping with managing current consumption and planning for future capacity needs.

10.1.17 Disk and Raid

This displays the disk and raid information.

10.2 Manage Dashboards

You can define custom dashboards to highlight the statistics of most interest in your environment. The blue area of the control bar at the bottom of the page shows the current dashboard. Click the eye icon to see a summary of the dashboard contents.

10.3 Adjust the Date Range

By default, the dashboard shows data for the past month, but you can change the start date to be any date within the past month. The end date of the range is always the current date.

Change the start date for the dashboard data:

1. Click the calendar icon in the lower left corner of the page.
2. Click a date in the calendar to change the start date.
3. Click Apply to save and change the displayed data.

10.4 Dashboard Explorer

Click Dashboard Explorer in the control bar to open the Explorer panel. The active dashboard is listed along with the default dashboard and any custom dashboards that you have created.

10.4.1 Add a Custom Dashboard

1. Click + in the Dashboard Explorer to add a custom dashboard.
2. Enter a name and description and click Save. The dashboard opens to show a blank canvas where you can add dashlets. Dashlets are individual charts displaying select statistics for selected hosts.
3. Click Add Dashlet to add to your dashboard.
4. Select the host, chart type, and stats. The available stats and the number of stats you can select depend on the selected chart type.
5. Click Apply to view the added dashlet.
6. Click Save to save the settings.
7. Add additional dashlets as you like. You can drag and drop to arrange dashlets on the canvas.

10.4.2 Edit and Delete Dashboards

You can rearrange the contents of your dashboard or modify individual dashlets.

1. Rearrange. To rearrange the dashlets, open the dashboard and use drag and drop.
2. Modify or delete a dashlet. To modify a dashlet, click the dotted icon in the dashlet. Click Edit to change the host, chart, or stats settings, or click Delete to remove the dashlet. In both cases, you're prompted to save the changes. Click Save to keep the changes or Discard to revert to the previous settings.
3. Delete a dashboard. Open the Dashboard Explorer and click the trashcan icon for the dashboard.

11. Using the Panzura CloudFS User Interface

This chapter describes the CloudFS Map view, which lets you see the health of the overall file network.

11.1 Overview

The CloudFS UI provides a graphical view of all the configured nodes. It displays the current status and allows you to step back in time to see behavior of various statistics.

The following figure shows the CloudFS UI. The UI includes a map image of the geographical area containing the nodes along with custom controls.

11.2 About CloudFS Map

When the map is loaded initially (or the CloudFS tab is clicked), the zoom level is adjusted automatically and centered to show all the node markers on the map. You can zoom in and out, pan, change between satellite and map view, or do other map functions.

The map image shows the nodes based on their site location entered in the System Settings section of the WebUI. You can specify a location using address, city, or latitude/longitude. The map places markers on the map at the correct location.

11.2.1 Location of nodes on Map

The location of each node is derived from the information entered in Location field on the Configuration > System Settings > System Info page (System Settings). The node uses the specified location to obtain the corresponding latitude and longitude and stores the information for use in the CloudFS UI. In some cases, however, this process doesn't work. For example, if the node is in a private cloud, the address might not be translated into latitude and longitude and the node might not be displayed in the correct location on the map.

In this situation, you can obtain the latitude and longitude independently (from a site such as http://www.latlong.net/Show-Latitude-Longitude.html), and specify the values in the Location field on the System Settings page.

The setting must be entered in the format given in the following example, including the square brackets. After the entry is saved, the node is able to use the values to place the node on the map.

11.3 Using the CloudFS UI

You can do the following with the CloudFS UI:

1. Select nodes.
2. Select visualization options.
3. Select a date range.
4. Event and Alert Playback Bar.
5. View statistics information.
6. View alert information.

11.3.1 Select Nodes

Click Select nodes in the lower right corner of the CloudFS UI to select the nodes to include in the visualization.

11.3.2 Select Visualization Options

Click View in the lower right section of the CloudFS UI to show the available visualization options:

1. Alert: Select to include alerts in the visualization. See View Alert Information.
2. Stats: Select to include statistics in the display.
3. Individual stats. Select checkboxes for the items you want to include. See View Statistics.

11.3.3 Select a Date Range

By default, the dashboard shows data for the past month, but you can change the start date to be any date within the past month. The end date of the range is always the current date.

1. Click the calendar icon in the lower left corner of the page.
2. Click a date in the calendar to change the start date.

3. Click Apply to save and change the displayed data.

11.3.4 Event and Alert Playback Bar

The playback bar allows you to move through the date range you specified to view statistics and alert information during that period.

1. Play/Stop: Click to start or stop playback.
2. Loop: Click this icon and then click the Play icon to start a looping playback. Click the Loop icon again to stop the looping.
3. Handle: Use the handle to move through the time period manually.
4. Alert markers: These indicate alerts that occurred at particular times during the playback period.

11.3.5 View Statistics

Click the icon in the upper left corner of the CloudFS UI to display statistics for the nodes in your visualization. Click a node name to display the statistics for that node. To select the types of statistics displayed for the nodes, use the checkboxes in the View > System Statistics popup (located in the lower right corner of the window).

The statistics are for the time shown in the playback bar. If you keep the Statistics window open and run a playback, you'll see the statistics change during the playback period.

You can also view statistics by hovering over a location on the map and clicking the node name.

11.3.6 View Alert Information

If you enabled Alerts in System Stats popup, orange alert markers are shown in the playback bar. Each indicates alerts that occurred at that point during the playback period.

Click a marker to display a list of alerts that occurred at that time.

Alert Details

Severity: Critical Policy ID: LICENSE.X1.7 Category: License Description: License AS-FGC is expiring in 1 day Cause: Alert when a license is within 1 day of expiration Resolution: On the WebUI, check Configuration, License Manager to review any expiring licenses. If the issue still persists, contact Panzura Technical Support.

Last alerted: 14:09:06 | 5-Aug-2025

List of Event Occurrence

Click an alert message to view additional details about the alert.

12. Configuration

12.1 System Settings

To assign settings related to system identity and operation, navigate to the following page in the node's web UI: Configuration > System Settings.

Notes on Configuration Mode (node role)

Each deployment must have at least one master node. (By default, all nodes are masters and maintain their own security and configuration. When you add a subordinate, you must specify the master that will manage it.)

All configuration settings on the master are automatically propagated to the subordinates. After setting up the hostname and IP address information during installation, you do not need to configure any additional settings on the subordinates.

If you have two masters in the same CloudFS list, ensure that their encryption certificates are always the same, as all systems in the same CloudFS list must have the same encryption certificates

Caution: Every time a subordinate reboot or the master configuration changes, the configuration of the subordinate is updated. If you change a node from a master to a subordinate, the current configuration is overwritten with the configuration from the new master. This can cause loss of user access to SMB/CIFS shares.

12.1.1 Configuration Mode

12.1.2 System Info

12.1.3 Advanced

12.1.4 Server Timeout

12.1.5 Time and Date Settings

12.1.6 Client Protocol Settings

Choose the file sharing protocols to be supported by the node:

• SMB only: Supports storage of files accessed using SMB/CIFS. SMB/CIFS is commonly used within Microsoft Windows network domains to access files.
• NFS only: Supports storage of files accessed using NFS. NFS is used by Unix/Linux-based systems.
• SMB-NFS-both: Supports storage of files accessed by either SMB/CIFS or NFS.

Note: Client / File Protocol Settings can be modified during CloudFS installation. Note: This option is not recommended because it can make it difficult to determine which protocol the specific files belong to and could result in access or permissions issues. If you must include both SMB and NFS, make sure that the two types of files are stored in separate directories. Also, avoid configuring shared directories that would allow NFS write access to a share path where global collaboration can take place.

Enable NFS/Enable SMB

Enable the client protocols that you are using.

12.1.7 Support Assistant

12.1.8 Core Dump Settings

12.2 Network Settings

To view or assign network settings, navigate to the following page in the CloudFS web UI: Configuration > Network Settings. Note: If you use the Command Line Interface (CLI) to perform initial configuration, some IP settings are already configured. You can use this page to change them if necessary.

12.2.1 Network Setting Options

The following table describes the network settings you can configure.

DHCP - Assign automatically via DHCP server. Other settings disabled. Static - Assign static IP addresses:

• IP Address: IP + subnet mask and default gateway
• Hostname: Node hostname (read-only)
• Domain: Node domain name
• Primary/Secondary DNS: Preferred and backup DNS
• Enable Jumbo Frame: Enable/disable jumbo frames (see Jumbo Frame Support)

Note: One-Arm uses GB1 for client + object storage. Inline uses GB1 (client) and GB2 (LAN).

12.2.2 Interface Settings

Set the configuration for the GB1 interface:

12.2.3 Deployment Mode

Choose One-Arm (default) or Inline. If you choose Inline, this section displays the following additional settings for the GB2 interface and static route table.

12.2.4 Network Hosts

Click Add Network Host to add a host to the local hostname file for address resolution without the use of an external DNS server. A host can be another node, a Windows domain node, or another system on the network.

Specify the following for each host, and click Add:

• Host name (fully qualified domain name [FQDN])
• IP Address

Add or remove additional entries as needed. To remove an entry, select its checkbox and click Delete. If you need to modify an entry, delete the existing entry and then add a new one.

Note: The capitalization used when first configuring the node host name persists for all CloudFS configuration operations. You cannot change the capitalization at a later time; however, you can change to a different host name.

12.2.5 Static Routes

If you select the Inline network configuration option, use this section to enter static routes for the GB2 interface. To add a route, click Add Static Route and enter the following information:

• IP Address: IP address for the route table entry. To configure a default route, enter 0.0.0.0.
• Netmask: Subnet mask assigned to the interface (format x.x.x.x). To configure a default route, enter 0.0.0.0.
• Gateway IP: IP address of the network gateway. Click Add to add the entry to the static routes table displayed on the page. To remove an entry, select its checkbox and click Delete. Add or remove additional entries as needed.

12.2.6 NIC Teaming Settings

12.2.7 Cloud Bandwidth Limits

You can configure independent bandwidth policies for both the primary cloud and if installed the secondary cloud. Default bandwidth limits for upload and download in megabits per second (Mbps) can be independently configured for both the primary and secondary cloud. A bandwidth policy can only be configured for a secondary or mirrored cloud if a secondary cloud license has been installed. The node will tune communication with the cloud based on configured values. More granular bandwidth limit policies can be configured for each cloud based on time periods, which allows restrictions to bandwidth consumption during specific periods. For example, bandwidth limits for upload and download can be configured to impose different limits for workdays vs weekends.

12.2.8 iDRAC Settings

12.2.9 Proxy Server Settings

12.2.10 Node Modes and Network Ports

Network ports on the nodes are defined as follows:

• LAN: Connects to the client side. This port is used by SMB/CIFS or NFS clients to access data on the node. For nodes configured with a single network connection, also referred to as a One-ARM deployment, cloud traffic will also use this interface.
• WAN: Connects to the cloud side. This port is used for cloud network traffic. For nodes with two network connections, also referred to as an In-Line deployment.

Note: Depending on the node model, the LAN1 interface may have any of the following names: LAN1, bge0, ix0. Likewise, the WAN1 interface may have any of the following names: WAN1, bge1, ix1.

The node can be deployed in the network in either of the following modes:

One-Arm Mode

The node is connected to the network through a single interface, GB1. The node is not directly in the traffic path between the internal and external networks.

Note: If you change the IP address of the interface through which you logged onto the web UI, your management session is terminated as soon as you click Save.

Inline Mode

The node is connected to the network by separate LAN (GB1) and WAN (GB2) interfaces. When using inline mode, make sure that the two networks, GB1 and GB2, are on different subnets and that the DNS server is not on the GB2 (WAN network). Because GB2 is intended only for cloud traffic, if the DNS server is on the WAN network, the internal firewall blocks the DNS traffic. This is the preferred method.

12.2.11 Required Ports

The following table lists the protocol ports that Panzura Nodes use for operation.

For each protocol port, the table lists the node's physical port (LAN or WAN) that receives and sends traffic and whether sessions are initiated by the node or by another device.

1. In: Session traffic is initiated by another device and received by the node on the indicated port.
2. Out: Session traffic is initiated by the node and sent out of the indicated port.
3. Both: Session traffic might be initiated locally or remotely.

Note: Support Assistance is optional but recommended. To use Support Assistance,

• A route from the node to the Internet.
• Access to DNS. SA URLs:
• sacconnect.panzur a.com
• sacconnectstatic.p anzura.com Diagnostic logs may be automatically uploaded using:
• sadownload.panz ura.com | | 443/TCP | | Out | Out | Licensing. Panzura uses token licenses which decrypt to a central license server:
• support2.pixel8n etworks.com | | 53/TCP 53/UDP | Both | | Both | DNS | | 80/TCP 443/TCP | | Out | Out | HTTP/HTTPS access to object store in cloud | | 111/TCP 111/UDP 2049/TCP 2049/UDP 4045/TCP 4045/UDP | In | | In | Network File System (NFS) protocols: RPC, NFS, and lockd. Note: Required only if NFS support is enabled. | | 135/TCP | Out | | Out | RPC (Remote Procedure Call) Associated with Microsoft Windows RPC Endpoint Mapper service. | | 49152-65535/TCP | Out | | Out | RPC randomly allocated high TCP ports. | | 123/UDP | Out | | Out | Network Time Protocol (NTP) | | 137/UDP 138/UDP 139/UDP | Out | | Out | NetBIOS (WINS) |

• data.panzura.com
• s3.panzura.com
• es.panzura.com UK:
• datauk.panzura.c om |

12.2.12 Jumbo Frame

Enabling jumbo frames can improve performance in high-speed (gigabit Ethernet or higher speed) networks; however, they only work if fully supported on network devices and they increase CPU and memory load on the node. Make sure that you understand the use of jumbo frames before enabling this feature.

12.2.13 Inline Mode (LAN and WAN on separate NICs)

To switch to 10GbE:

1. deploy-mode inline
2. configure-network lan ix0
3. configure-network wan ix1

To switch to 1GbE:

1. deploy-mode inline
2. configure-network lan bge0
3. configure-network wan bge1

12.2.14 NIC Teaming Settings

Teaming is supported for PCI and on-board NICs. The interfaces that are available for NIC teaming are identified with icons, illustrating the RJ45 ports. On physical (not virtual) nodes, NIC teaming allows you to aggregate multiple network interfaces into one virtual interface for link aggregation and failover.

• LACP-Switch Dependent mode: combines multiple interfaces for increased throughput. Must be connected to a switch that supports and is configured for Active Link Aggregation Control Protocol (LACP). LACP distributes traffic bi-directionally while also responding to the failure of individual links. LACP balances outgoing traffic across the active ports based on protocol header information and accepts incoming traffic from any active port. It does not load balance on a per packet basis.

Note: PZOS 8.0 REQUIRES that the switch configuration is "Active LACP." The exact hashing algorithm used from the switch side may be selected by the user.

• Failover-Switch Independent mode: allows traffic to continue to flow in the event of a link failure, provided that one member of the aggregated network interface has an operational link. When the second member becomes available again, the link team is automatically reconstituted. Failover and recovery are transparent to the end user, but the failure and recovery information is written to the appropriate log.

Note: If you use the Command Line Interface (CLI) to perform initial configuration, some IP settings are already configured. You can use this page to change them if necessary.

The following rules apply to NIC teaming:

• NIC teaming is supported only on physical nodes (not virtual nodes). Configured NIC teams persist and do not need to be reconfigured when the node reboots or is upgraded.
• You can use NIC teaming with high availability active/standby configurations.
• The interfaces for a NIC team must have the same maximum speed ( 10 Gb or 1 Gb ). They can be on the same NIC or different NICs. For reliability, it is a best practice to team across different NICs if possible.
• NIC teaming is supported in inline or one-arm mode. In one-arm the following are supported:
• 2ea 1GbE ports or
• 2ea 10GbE ports

In inline mode, the following are supported:

• 2ea 1GbE ports for the client (LAN) or cloud (WAN) side
• 2ea 10 GbE ports for the client or cloud side
• You can configure the specific Ethernet interfaces to team using the web UI or CLI.
• You can create a NIC team on the client side, cloud side, or both.
• It is possible to change the assignment of an interface from cloud side to client side or vice versa. To do this, first remove the interface from its current assignment by changing its Teaming Mode to None - Single Interface. This makes the interface available for selection on the other side.
• If your configuration uses the Dell iDRAC Express for out of band management, note that it shares the network interface with the node and that iDRAC does not support NIC Teaming. It is possible to upgrade the iDRAC to iDRAC Enterprise, which uses a dedicated network port. This upgrade can be purchased directly from Dell.

Hover over a colored icon to display details about the current configuration. (See "NIC Teaming" in Network Setting Options.)

Starting in CloudFS 8, due to use of FreeBSD 12, enforcement of LACP configuration is strict. Any mismatched LACP configuration may require reconfiguring your switch to maintain uninterrupted operation. For CloudFS 7 and earlier, LACP configuration enforcement is not strict, and mismatched configuration with your switch did not cause interruption of traffic.

The following are the configuration steps:

1. Select the teaming mode for the client side, cloud side, or both.
2. Select a port for Interface 1. When you make your selection, the available ports for Interface 2 are presented.
3. Select the Interface 2 port. If possible, select team members on different cards to improve reliability.
4. When you have finished configuring the client side, cloud side, or both, click Submit to save the configuration. NIC teaming is now operational, and icon colors on the page are updated to represent the team configuration. To view the current status of configured NIC teams, navigate to Maintenance > Diagnostics Tools and run the show interface command.

Note: When you configure a team, the icon colors are updated after the configuration is saved. To use the CLI instead, you can configure NIC teaming using the following configuration commands.

12.2.15 One-Arm Mode (LAN and WAN on the same NIC)

First, make sure the deployment mode (deploy-mode) is one-arm mode (default mode). To switch to 10 GbE one arm: deploy-mode onearm configure-network lan ixi To switch to 10 GbE one-arm failover (switch independent; does not need switch config): deploy-mode onearm configure-network lan ixi ixi failover To switch to 1 GbE one arm: deploy-mode onearm configure-network lan bge0 To switch to 1 GbE one-arm failover (switch independent; does not need switch config) deploy-mode onearm configure-network lan bge0 bge1 failover

Notes:

• The default TCP congestion algorithm has been changed to Cubic.
• This has been shown to have performance improvement for WAN and LAN traffic for larger latency environments, while maintaining performance for other traffic.
• Customers using virtual cloud instances, or with clients with high latency connections, may see some improvements.

12.3 Monitoring

To view or assign network settings, navigate to the following page in the CloudFS Web UI Configuration > Monitoring.

12.3.1 Syslog Settings

12.3.2 Email Server Settings

Note: When OAuth (Microsoft 365) is selected, the following fields are forced and become read-only:

• SMTP Server $\to$ smtp.office365.com
• SMTP Port $\to 587$
• Use encryption $\to$ On (STARTTLS)

12.3.3 Email Alert Settings

12.3.4 SNMP Settings

12.3.5 SNMP Users

12.3.6 Audit Settings

This CloudFS enhancement expands the Audit configuration framework to provide greater flexibility while preserving existing functionality and ensuring compatibility with future enhancements. It extends File Access Auditing support for both NFS and SMB clients by introducing a more customizable audit configuration that supports multiple audit vendors and destinations.

12.3.7 Key Capabilities

• Multi-vendor audit integration
• Supports simultaneous integration with Panzura Data Services, syslog, and multiple third-party audit solutions such as Varonis and Nexus.
• Multiple concurrent RabbitMQ consumers
• Enables multiple third-party products to receive real-time audit events simultaneously from the same CloudFS cluster.
• Previously, only a single RabbitMQ consumer could be registered at a time.
• Each vendor (for example, Nexus and Varonis) registers independently and receives the complete, unfiltered audit event stream without impacting other consumers.
• Independent consumer operation
• Multiple named consumers operate concurrently using independent RabbitMQ connections.
• Consumer isolation ensures that a failure affecting one vendor does not interrupt event delivery to others.
• No audit events are lost or duplicated during normal operation.
• Registering or deregistering one consumer does not affect the operation of other consumers.
• Flexible audit configuration
• Supports customized audit policies for multiple audit log destinations.
• Allows different tracked actions to be configured for each destination, enabling audit behavior to be tailored to specific operational and compliance requirements.

For example, Panzura Data Services must track eight+ (8+) audit actions (read, write, modify, open, close, mkdir, etc.); however, the syslog server only needs to receive two types of actions (open, close).

This audit configuration feature replaces configuration via AS-Audit and AS-Varonis licenses. This functionality now uses standard Panzura configuration which duplicates and enhances the existing functionality and allows the configuration to be propagated from master to subordinate.

Note: AS-Audit and AS-Varonis licenses are no longer required, any existing licenses will be ignored after upgrade. Click here for Audit license configuration for CloudFS versions prior to 8.2 . The Local Audit Settings exist primarily to allow overwriting the master Audit Settings when necessary. From the Audit Settings screen, you are able to see both cluster and local settings, regardless of whether you are viewing as a master or subordinate.

Note: If you are a subordinate, you will not be able to edit your cluster settings.

Scope and Inheritance

On the master node, you can configure both Ring (cluster-wide) and Local settings. If both configurations exist, use the Scope drop-down list to switch between them when viewing or modifying settings. By default, the master node displays the Ring scope because it represents the cluster-wide configuration.

On a subordinate node, the Master scope provides a read-only view of the configuration inherited from the master node. If local settings are configured for the subordinate node, the Scope drop-down list defaults to Local.

Note:

• When you open the Master node web UI, the Scope displays "Ring" configuration first and displays "local" if changed.
• The configuration for a Scope is not set if the field information is default. Configurations once set can be updated but cannot be deleted from the UI.
• If multiple scopes are saved, then they will be implemented if they are available in the following hierarchy. a. Local b. Master on Subordinate node / Ring on Master node

Register a Third Party Vendor with CloudFS

To register Third party vendors with CloudFS, call the POST /psapi/rabbitMQSettings api with the vendor name and RabbitMQ connection details in the request. After a vendor is registered, its name appears in the vendor list when you add a vendor in Configuration $>$ Monitoring $>$ Audit Settings $>$ Third Party Vendor Support.

If auditing is enabled for a third-party vendor that is not registered with RabbitMQ, audit events for that vendor cannot be delivered and are discarded, but alerts are displayed in CloudFS Notification Center. To resolve this issue, register the vendor by calling POST /psapi/RabbitMQSettings. If third-party auditing is not required, remove the vendor from the Third-Party Vendor Support section.

Configure Audit Settings

1. Log in to the CloudFS Master Node WebUI using admin credentials or an RBAC user with the required access to the Monitoring section.
2. Navigate to Configuration $>$ Monitoring $>$ Audit Settings section.
3. In Panzura Data Services section: a. Select the Scope.

• If you are setting the scope on the Master node, then the Scope options are Ring and Local.
• If you are setting the scope on the Subordinate node, then the Scope options are Master and Local. To inherit Audit settings from the master node, toggle Inherited from Master on. b. If you are setting the ring scope on the Master node, then the Push to Subordinate(s) option is displayed. Select this option to push the settings to all the subordinate nodes in the ring (you don't have to go and explicitly set the same on each node). c. To generate audit logs, toggle Generate PDS Audit Log on. If the Push to Subordinate(s) option is on and Generate PDS Audit Log is on, then all the nodes will start generating audit events. d. Select User Actions to enable or disable specific functions for users. e. You can Include Files and Exclude Files as required. f. Click Save.

4. In Audit Syslog section: a. Select the Scope.

• If you are setting the scope on the Master node, then the Scope options are Ring and Local.
• If you are setting the scope on the Subordinate node, then the Scope options are Master and Local. To inherit Audit settings from the master node, toggle Inherited from Master on. b. If you are setting the ring scope on the Master node, then the Push to Subordinate(s) option is displayed. Select this option to push the settings to all the subordinate nodes in the ring (you don't have to go and explicitly set the same on each node). c. To generate audit logs, toggle Generate PDS Audit Log on. If the Push to Subordinate(s) option is on and Generate PDS Audit Log is on, then all the nodes will start generating audit events. d. Select User Actions to enable or disable specific functions for users. e. Provide Syslog Server name and Syslog Server Port details. f. You can Include Files and Exclude Files as required. g. Click Save.

5. In Third Party Vendor Support (used for integrations) section: a. Select the Scope.

• If you are setting the scope on the Master node, then the Scope options are Ring and Local.
• If you are setting the scope on the Subordinate node, then the Scope options are Master and Local. To inherit Audit settings from the master node, toggle Inherited from Master on. b. To add a new Third Party vendor, click Add. c. In the Add Third Party Vendor Support window: d. Select Vendor Name. If you do not find the vendor name that you are looking for, ensure that the vendor is registered with CloudFS. For details, refer Register a Third Party Vendor with CloudFS. e. Select User Actions to enable or disable specific functions for users. f. You can Include Files and Exclude Files as required. g. If you are setting the ring scope on the Master node, then the Push to Subordinate(s) option is displayed. Select this option to push the settings to all the subordinate nodes in the ring (you don't have to go and explicitly set the same on each node). h. To generate audit logs, toggle Generate PDS Audit Log on. If the Push to Subordinate(s) option is on and Generate PDS Audit Log is on, then all the nodes will start generating audit events. i. To generate a third-party log, toggle Generate Third Party Log on. j. Click Save.

The table lists the registered vendors and their settings. Administrators can edit or delete a vendor as required.

System Settings Network Settings Monitoring Encryption Settings CloudFS Settings SMB/S3 Settings SMB/NFS Mixed Mode NFS Settings Snapshot Settings Smart Cache Settings High Availability Active Directory License Manager Disk Expansion Geofencing Policy Access Control Quota Management

SNMP Users Data Services Settings

12.3.8 UX Dashboard & PZIQ Settings

Audit alert categories

Alerts displayed in the Notification Center:

• SYS.AUDIT.TP1.1 - Raised when audit event delivery to a configured third-party vendor is failing. The alert includes the vendor name and the consecutive failure count.
• SYS.AUDIT.TP2.1 - Raised when a vendor is enabled for third-party audit but RabbitMQ is not configured. The alert includes the vendor name and the number of dropped audit events.

12.3.8 UX Dashboard & PZIQ Settings

UX Dashboard

The UX dashboard is an additional dashboard available outside of the standard administrator credentials. It includes improved user metrics from a client experience metrics script in the customer environments.

To enable the UX dashboard, navigate to the following page in the CloudFS web UI:

To access the UX dashboard:

1. Link to access the UX dashboard - https://dist/dashboard.html
2. You are logged in to UX dashboard with "Advanced dashboard" view by default.

By clicking on the "Advance dashboard", you can switch the view to Standard dashboard. Advance dashboard view includes -

Note: When there is no data available in the node, the charts on the PZIQ dashboard appear empty.

Standard dashboard view includes -

Note: When there is no data available in the node, the charts on the PZIQ dashboard appear empty.

PZIQ settings

PZIQ settings refers to a set of additional metrics for the CloudFS Statistical Collection System (SCS). These metrics aid the Panzura Support Team in monitoring the health of CloudFS nodes.

The PZIQ is a tool used to monitor the CloudFS node. The table below lists the additional objects in the Panzura node Management Information Base (MIB) available when PZIQ settings are enabled.

PZIQ settings is enabled by default but can be disabled if required. Contact Panzura Support either by logging in to portal or by sending an email to [email protected] for more information or to disable PZIQ settings.

The PZIQ metrics is available on the know.panzura knowledge portal for reference.

12.3.9 Grafana and Time-Series Stats Settings

Multi-dashboard drill-down architecture ( 3 JSON files), multiple ring support, Grafana Cloud support, executive overview, traffic light summary, metadata stats, configurable column visibility.

The Time-Series Stats Settings feature enables the export of CloudFS data to a time-series database called InfluxDB, enabling seamless integration of CloudFS with monitoring tools like Grafana for visualization through pre-configured dashboards.

Organizations can use their monitoring solutions (like Grafana) pointing to this CloudFS time-series database to visualize real-time system activity, storage performance trends, and overall operational health of their CloudFS deployment.

The multi-dashboard drill-down architecture includes:

• Grafana Cloud support: Dashboards are now compatible with Grafana Cloud in addition to self-hosted Grafana instances. Connect Grafana Cloud (or any self-hosted Grafana instance) to CloudFS for real-time and historical monitoring of all systems, storage, network, cloud, SMB, and replication metrics.
• Multiple ring support: Users can now monitor multiple rings simultaneously via data source selection.
• Cross-dashboard navigation: Click-through drill-down from overview to ring to node level.
• Multi-dashboard architecture: Replaced the single-file dashboard with three interconnected dashboards providing a drill-down approach from estate overview to individual node metrics. Dashboard structure:
• Executive Overview dashboard: New top-level summary optimized for wall-mounted displays. Deployed using CloudFS_Executive_Overview.json.
• Ring Level Details dashboard: Statistics and detailed metrics for a selected ring. Deployed using CloudFS_Ring_Details.json.
• Node Level Details dashboard: Statistics and detailed metrics for a selected node. Deployed using CloudFS_Node_Details.json.
• Aggregation: Aggregated charts enable data visualization and analysis across configurable aggregation levels (Hourly, Daily, Weekly, Monthly, and Yearly) for a selected date range. Chart titles automatically indicate the selected aggregation level, and the selected date range must align with the chosen aggregation granularity to display data correctly. List of aggregated charts:
• Node Level Stats - Network >> Network I/O
• Node Level Stats - Network >> Node Drive Files Uploads Downloads Deletes
• CloudFS Ring Level Stats - Storage >> Managed Capacity Trend (This chart is displayed for the master node and is not affected by Node or Operations slicers. As Hourly aggregation is not supported for this chart, selecting it will display no data.)
• Traffic light summary widget: At-a-glance node health counts (red/amber/green).
• Configurable column visibility: Configurable table column visibility allows administrators to customize table views by showing or hiding selected columns using a column selector. The Cols: CloudFS Nodes Status filter is available on the Ring Level Details and Node Level Details view, while the Cols: Ring Level Disk Stats filter is available on the Ring Level Details view, enabling users to display only the columns most relevant to their analysis.

Available Dashboards for Grafana

Prerequisites

Enable InfluxDB Stats:

1. Log in to the CloudFS Master Node WebUI using admin credentials or an RBAC user with the required access to the Monitoring section.
2. Navigate to Configuration $>$ Monitoring $>$ Grafana & Time-Series Stats Settings section.
3. In the Time-Series Stats Settings section, toggle Enable InfluxDB Stats option to ON and click Save.
4. Click Get Credentials to configure this InfluxDB data source in your monitoring tool, such as a Grafana dashboard. Copy the URL and user credentials.

If you are using the Grafana on-premises version:

• Ensure that Grafana is installed in the CloudFS environment.
• Ensure that Enable InfluxDB Stats is ON.
• Ensure that the URL and user credentials are copied from the Get Credentials section. These details are required to configure this InfluxDB data source in the Grafana dashboard.

If you are using the Grafana Cloud version:

• Set up a Grafana Private Data Source Connect (PDC) connector on the Grafana Cloud platform. a. Log in to .grafana.net with valid credentials and required permissions. b. Navigate to Connections $\to$ Private data source connect and click Create New Network. c. Enter a valid name for Private data source connect. d. Go to the Configuration Details tab. e. In the Choose your installation method section, select the $>$ Binary option. f. In the Use a PDC signing token section, edit the Token Name field if required and select an Expiration date as per the token validity requirements. g. Click Create Token. Copy and store the token when it appears. h. In the Deploy the PDC agent on your private network section, copy and store the values of Cluster and hosted-grafana-id.

Warning:

• During this procedure, it is recommended to use the data source names provided by Panzura.
• Ensure that the value added via the UI matches the value mentioned in the JSON file.
• CloudFS_Grafana_Dashboard=v4.0.1 include three JSON template files. When re-importing these templates, choose Overwrite to update the existing dashboards instead of creating duplicate copies.
• Templates released before CloudFS_Grafana_Dashboard=v4.0.1 can coexist with earlier versions, so they do not need to be overwritten.

Create a Dashboard in Grafana

1. CONFIGURE THE DATA SOURCES

Note: This section does not apply to CloudFS_Grafana_Dashboard-v1.0.2. If you are using this template version, see Configure InfluxDB data sources for template CloudFS_Grafana_Dashboard-v1.0.2 instead.

On Grafana on-premise version:

1. In Grafana Dashboard, go to Connections $>$ Data Sources.
2. Click + Add new data source and then select InfluxDB.
3. Add a new data source with the name cfs_scs_stats:
4. Select Query Language as Flux.
5. In the Http section, add the Url that was copied from the Enable InfluxDB Stats procedure.
6. Set the Timeout as 300 seconds.
7. In the Auth section:
8. Enable the Basic Auth option. In the Basic Auth Details section, add the User and Password details that were copied from the Enable InfluxDB Stats procedure.
9. To continue using the CloudFS-generated SSL certificate, enable Skip TLS Verify.
10. To configure access using authorized CA-signed certificates, enable With CA Cert. Copy and paste the CA-signed certificate details in the CA Cert field in TLS/SSL Auth Details. For details about CA certificates, refer to the Install a CA-signed Certificate section in How to generate Self Signed and CA-signed Web Certificate.
11. In the InfluxDB Details section:
12. In Organization, enter panzura.
13. In Token, add the Password that was copied from the Enable InfluxDB Stats procedure.
14. In Default Bucket, enter cfs_scs_stats.
15. Click Save & test. If the test is not successful, verify that the details added match this procedure. If it still fails after verification, contact Panzura Support.

On Grafana Cloud version:

1. Log in to <username>.grafana.net with valid credentials and all required permissions.
2. Navigate to Connections $\to$ Data sources.

3. Click the Add new data source button and select InfluxDB under the Time series databases category.
4. Rename the data source; it is recommended to use the naming format provided by Panzura.
5. Enter the URL obtained from the Get Credentials button on the Master Node.
6. Select Product as InfluxDB OSS 2.x and Query language as Flux.
7. Enable the Auth and TLS/SSL Settings toggle.
8. Select the Basic Authentication tab and enter the Username and Password obtained from the Get Credentials button on the Master Node, and enable the With Credentials toggle.
9. Activate the Skip TLS Verify toggle.
10. In the Database settings section, enter Organization as panzura, Default bucket as cfs_scs_stats, and Password obtained from the Get Credentials button on the Master Node as the Token.
11. Select the Private data source connect created for the CloudFS ring.
12. IMPORT THE DASHBOARD TEMPLATE IN GRAFANA

Download the template JSON files for the Grafana Dashboard. Right-click the link and save the json file on your machine. If you are using the same JSON file to create another dashboard, change the UID.

Import the JSON file:

1. In Grafana, go to Dashboards and click New $>$ Import.
2. In Import dashboard:
3. Upload the template JSON file. If you are using the same JSON file to create another dashboard, change the UID.
4. Change the Name of the dashboard as appropriate, e.g. CloudFS Dashboard.
5. Select cfs_scs_stats as the default data source for this dashboard.
6. Click Import. On successful import, a new dashboard is created and displayed.

Monitor Grafana Dashboard with CloudFS statistics

In Grafana, go to Dashboards and select the dashboard that you created, e.g. CloudFS Dashboard. In the sample Grafana Dashboard using the template CloudFS_Grafana_Dashboard-v4.0.2.zip:

1. Open the CloudFS Executive Overview dashboard. This dashboard provides a high-level, display-optimized view of ring-wise health, capacity utilization, node counts, and overall operational status across the environment. Select all available rings to populate the full summary for all rings simultaneously.
2. To view the CloudFS Ring Level Details dashboard, follow any of these steps:

• Click on the Ring ID on the dashboard.
• In Select Data Source/Rings, select the Ring and then click Ring Level Details.
• Click Ring Level Detail and then select the Ring.

This dashboard provides detailed visibility into a selected ring, including ring summary metrics, node health distribution, traffic-light status indicators, and interactive filtering for rapid issue identification. 3. To view the CloudFS Node Level Details dashboard, follow any of these steps:

• Click on the Node ID on the dashboard.
• In Select Data Source/Rings, select the Ring and then click Node Level Details.
• Click Node Level Detail, select the Ring, and then select the Node.

This dashboard provides detailed node-level operational metrics and health information, enabling administrators to monitor performance, resource utilization, and diagnose issues on individual nodes.

Note:

• It is recommended to begin your monitoring session on the Executive Overview page.
• Each ring requires a corresponding data source to be configured.
• The Ring ID displayed throughout the dashboards is derived from the name assigned to that data source.

A compact summary widget at the top of the CloudFS Nodes Status panel displays total node counts in three color-coded categories:

Note:

• Color thresholds are aligned with per-row color coding in the node table, ensuring consistency between summary counts and the detailed view.
• Node level status precedence: Critical (Red) $>$ Warning (Amber) $>$ Healthy (Green).
• Status filters are interactive. Click on Total Nodes, Good, Warning, or Critical to filter the CloudFS Node Status table according to the selected status.

Configure InfluxDB data sources for template CloudFS_Grafana_Dashboard-v1.0.2

1. Configure the data sources:
2. In Grafana Dashboard, go to Connections $>$ Data Sources.
3. Click + Add new data source and then select InfluxDB.
4. Add a new data source with the name cfs_scs_stats:
5. Select Query Language as InfluxQL.
6. In the Http section, add the Url that was copied from the Enable InfluxDB Stats procedure.
7. Set the Timeout as $300$ seconds.
8. In the Auth section: A. Enable the Basic Auth option. In the Basic Auth Details section, add the User and Password details that were copied from the Enable InfluxDB Stats procedure. B. To continue using the CloudFS-generated SSL certificate, enable Skip TLS Verify. C. To configure access using authorized CA-signed certificates, enable With CA Cert. Copy and paste the CA-signed certificate details in the CA Cert field in TLS/SSL Auth Details. For details about CA certificates, refer to How to generate Self Signed and CA-signed Web Certificate.
9. In the InfluxDB Details section: A. In Database, enter cfs_scs_stats. B. Add the User and Password details that were copied from the Enable InfluxDB Stats procedure.
10. Click Save & test. If the test is not successful, verify that the details added match this procedure. If it still fails after verification, contact Panzura Support.
11. Add a new data source with the name cfs_scs_stats-flux: i. Select Query Language as Flux. ii. In the Http section, add the Url that was copied from the Enable InfluxDB Stats procedure. iii. Set the Timeout as $300$ seconds.

iv. In the Auth section:

• Enable the Basic Auth option. In the Basic Auth Details section, add the User and Password details that were copied from the Enable InfluxDB Stats procedure.
• To continue using the CloudFS-generated SSL certificate, enable Skip TLS Verify.
• To configure access using authorized CA-signed certificates, enable With CA Cert. Copy and paste the CA-signed certificate details in the CA Cert field in TLS/SSL Auth Details. For details about CA certificates, refer to How to generate Self Signed and CA-signed Web Certificate. v. In the InfluxDB Details section: A. In Organization, enter panzura. B. In Token, add the Password that was copied from the Enable InfluxDB Stats procedure. C. In Default Bucket, enter cfs_scs_stats. vi. Click Save & test. If the test is not successful, verify that the details added match this procedure. If it still fails after verification, contact Panzura Support.

2. Return to step # 2. Import the Dashboard template to continue with the creation of a Dashboard in Grafana.

12.3.10 Simple Network Management Protocol

Simple Network Management Protocol (SNMP) is an Internet Standard protocol that allows customers to monitor networked devices through a single tool. Devices that support SNMP include routers, modems, switches, and servers. SNMP monitors values exported by the SNMP agent and allows push notifications, which are traps in SNMP language. The two components of SNMP include SNMP agents and SNMP managers. An SNMP agent is a software on a managed device. The software allows the SNMP manager to communicate with the device using SNMP. The SNMP manager is an external software that queries, receives events, and gets responses from devices. A managed device implements an SNMP interface for node-specific information.

A Management Information Base (MIB) is a collection of information organized hierarchically. These are accessed using a protocol such as SNMP. MIBs are created by Managed Device vendors (Panzura), and they are stored on the device. MIBs must be provided to the SNMP manager so it knows how to translate the MIB values from the managed device. MIBs use a hierarchical namespace that contains object identifiers (OID). An OID identifies a variable that can be read using SNMP.

There are two transaction types: polling and traps. When polling occurs, the SNMP manager sends an SNMP request to a managed device at the default polling interval, which is 120 seconds. The managed device then responds with an SNMP response status. The second type of transaction is a trap or push notification. SNMP managers are always ready to receive a trap from a managed device. In order to receive and translate a trap from a managed device, the managed device must be configured to send traps to the manager, and the SNMP manager must be provided with a trap MIB from the managed device.

The following are the three versions of SNMP security:

1. Version 1: Plain text authentication.
2. Version 2: Improved authentication. Community strings are still transmitted over the wire in clear, plain text.
3. Version 3: Provides the following three levels of authentication:

• NoAuthNoPriv - Users who use this level don't have authentication or privacy when they send and receive messages.
• AuthNoPriv - This level requires users to authenticate but does not encrypt sent or received messages.
• AuthPriv - This level is the most secure. Authentication is required and sent and received messages are encrypted.

You can download the MIB zip archive using the following URL: https://docs.panzura.com/PANZURA_SNMP.tgz After downloading the MIB archive, decompress it and load files into your SNMP manager. This download is also available by selecting Maintenance $>$ System Operations $>$ Download MIB . To configure the SNMP settings on a Panzura node:

1. Log in to your Panzura node.
2. Select Configuration $>$ Monitoring $>$ SNMP Users $>$ SNMP Settings.
3. In the Read Community String field, enter the community string for read-only communication between the node and SNMP manager. Note: If you specify a custom community string, the public community string is disabled.

4. In the Recipient IP field, enter the SNMP manager IP (this is where we send traps).
5. In the Recipient Community String, enter the SNMP manager associated with community strings.
6. In the SNMP Trap Threshold Settings field, Enter the usage thresholds (percent) that will trigger SNMP trap messages.

To edit a trap:

1. Log in to your Panzura node.
2. Select Configuration $>$ Monitoring $>$ SNMP Users $>$ SNMP Settings.
3. In the SNMP Trap Thresholds section, select Actions $>$ Edit SNMP Trap.

To add an SNMP user:

1. Log in to your Panzura node.
2. Select Configuration $>$ SNMP Users.
3. Click the Add button.

The following table displays the SNMP traps that Panzura Supports:

12.3.11 Syslog Message Categories

When using syslog to monitor for events needing attention, Panzura recommends monitoring for LOG_EMERG, LOG_ALERT, and LOG_CRIT.

1. LOG_EMERG and LOG_ALERT messages typically represent conditions requiring immediate attention.

2. LOG_CRIT events represent events that can become EMERG or ALERT if not addressed.

The following table provides a list of Syslog message categories.

12.3.12 Panzura MIB Objects

The Panzura node MIB provides access to the following types of system information and statistics:

• node ID, CloudFS version, and hostname
• Visibility into caching:
• Hot, warm, and cold for automated caching
• Hot, warm, cold for pinned files
• Cache hits/misses for automated caching
• Cache hits/misses for pinned
• Cloud statistics
• Number of drive files uploaded to cloud
• Number of drive files downloaded
• Number of upload failures
• Number of download failures
• SMB users
• Total number of SMB users currently connected to the node
• Total number of files locked by SMB users currently connected
• CloudFS local configuration
• Mode of node: master/subordinate
• Hostname of master node
• Local system snapshot information
• Latest system snapshot generated reference #
• Latest system snapshot uploaded to cloud reference #
• Date and time when the latest master snapshot was successfully generated
• CloudFS remote configuration
• Remote node hostnames
• Latency from node to remote node
• Remote node up or down
• Down means there is no communication

• Remote snapshot information from all other nodes
• Latest snapshot reference # synchronized from the specified remote node
• The latest snapshot reference # uploaded by the specified remote node

12.3.13 MIB Download*

The following table lists the objects in the Panzura Node Management Information Base (MIB).

12.3.14 Monitoring Recommendations for CPU Load

The amount of CPU load placed on a node is measured in terms of the number of processes that are ready to run and, in the queue, awaiting CPU resources. These are the recommended thresholds by model. (CPU load is measured by OID .1.3.6.1.4.1.32853.1.3.1.1.1.)

12.3.15 VM nodes

For nodes operating in virtualized environments, such as VMware ESXi or Amazon Web Services (AWS), first determine the number of CPU cores assigned to the node. When 4 cores are assigned, use the values given for the 28xx models.

For a larger number of cores, scale the values upward. For example, a node operating within AWS can have 8 cores. To scale the values, first divide the number of cores by 4 to get 2 . Next, multiply this by the values for the 28xx models. The CPU load recommendations become $(2\ast 320=640),(2\ast 400=800)$, and $(2\ast 800=1600)$.

12.4 Encryption Settings

To upload pre-created certificates, navigate to the Configuration $>$ Encryption section. You can upload the following types of certificates:

1. Encryption certificate: The encryption certificate is used to encrypt data that is sent to the cloud and decrypt data that is received from the cloud. You can use the default certificate provided by Panzura (not recommended) or use a custom certificate. When a custom certificate is loaded, it is visible in the list of encryption certificates. You can activate the custom certificate by clicking Activate in the Action column.
2. Web certificate: The web certificate is presented when an administrator accesses the node web interface. You can upload a custom certificate to replace the default X. 509 PEM web authentication certificate.

The next subsections provide additional information about how certificates are used.

12.4.1 System Management

Web certificates are used when the administrator manages the node via a Web browser. This is a normal HTTPS security mechanism for guaranteeing the authenticity of a remote system, in this case the node. The node ships with a default X. 509 PEM web certificate issued and signed by Panzura. You can install a new replacement certificate through the web UI.

12.4.2 Data Encryption

The encryption certificate is used to encrypt data sent to the cloud and decrypt data that is read from the cloud. Each node ships with a default data encryption certificate (P12 formatted) that is issued and signed by Panzura.

The security web UI provides administrators with the ability to manage encryption certificates with flexibility, but care must be taken when doing this because nodes are fundamentally designed to share cloud data across multiple nodes, geographies, locations, and groups of users.

After a customer-issued certificate is loaded, it is displayed in the certificate list. You can select and activate any certificate, as described in this section. The following restrictions apply:

1. All cloud nodes operating in a common single CloudFS must use the same encryption certificate for global read-write collaboration to operate successfully. Unpredictable data access and client IO experiences can occur if this certificate topology is not implemented.
2. Although multiple encryption certificates can be loaded, each Panzura node uses one active certificate for all data operations. Multiple certificates cannot be active.
3. When a different certificate is activated, the system uses the new active certificate to encrypt all new data while using older certificates, no longer active, to decrypt data that was encrypted with those certificates.
4. You can delete a certificate only if it has never been activated. If the certificate has ever been used it must remain on the node.

12.4.3 Node-to-node Communication

During normal operation a node will communicate securely with other active nodes within a CloudFS. For security reasons this communication takes place using an SSH key pair. To change this key pair from the default shipped with the node, follow these steps.

Notes:

• Perform this procedure during a maintenance window across all nodes, including HA standby.
• If you use this procedure to change the key, then you must perform step 3 on any new node you add to the CloudFS.

To perform this procedure, port 443 must be open between nodes.

12.4.4 Key Management Interoperability Protocol Support

Panzura CloudFS supports Key Management Interoperability Protocol (KMIP). You use a KMIP server to manage KMIP certificates, including those for Panzura nodes. Only master nodes can interact with a KMIP server.

Communication with the KMIP server requires a mutually authenticated SSL session. You must upload the certificate authority (CA) certificate (the one that signed the KMIP server's server certificate) and client certificate for a KMIP server. Only one certificate of each type can be uploaded.

To upload another certificate, you must delete the certificate of that type that was previously uploaded. After uploading the KMIP related certificates, you can register encryption certificates.

12.4.5 Standard KMIP Port

IANA.org has assigned port 5696 for use by KMIP servers and clients. Your KMIP server documentation will state if it uses a different port number. The EMC RSA Data Protection Manager uses port 443 for KMIP communication.

12.4.6 Installing an Existing Key File (CLI)

If you plan to use an existing key file and want to use the CLI to do so, use the following steps.

1. Make a note of the IP address of the master node. In a multi-master configuration, select a specific master node to be the designated key master for the purposes of this change. For the purposes of this procedure all other master nodes are treated the same as Subordinate nodes.

Change the pairing key on the master node:

1. Use SSH to log in to the master node as admin. The cloudfs $>$ prompt appears. cloudfs>
2. Type enable and enter "enable" as the password, as prompted. The prompt changes to cloudfs#. cloudfs> enable password: enable cloudfs#
3. Use the show pairing-key command to display the current pairing signature and then use the regenerate-pairing-key command to create the new key. The second show key-signature command shows that the regenerated key is different from the original key. The value of the key signature can range from 2-43 characters, depending on the version of software that the node is running. cloudfs# show pairing=key value:zBCD3fyYegWr+vf9eFge6vExk+pfIPHkCcdYZO9hp0 cloudfs# regenerate=pairing=key cloudfs# show key=signature value:fGHEIK6MyEmRiGkDr+vf9eFge6vExk+pIEMsstO9qr4 cloudfs#

Change the pairing key on all other nodes, including and HA standby nodes.

1. Use SSH to log in to the master node as admin. The cloudfs> prompt appears. cloudfs>
2. Type enable and enter "enable" as the password, as prompted. The prompt changes to cloudfs#. cloudfs> enable password: enable cloudfs#
3. Enter the resync-pairing-key command to specify the pairing key. Include the IP address of the master node and the admin password. If your nodes are using valid signed web certificates, use the secure option. If your nodes are using the default unsigned web certificate, use the insecure option. cloudfs# resync=pairing=key master=ip=address password secure cloudfs# or cloudfs# resync=pairing=key master=ip=address password insecure cloudfs#
4. Run the check-master-key-pair-sync command to verify that the key on the master and Subordinate nodes are the same.

If the prompt returns with no output, the command is successful and the keys are identical: cloudfs# check=master=key=pair=sync

cloudfs# If the following error occurs, the sync was unsuccessful and you must rerun the resync-masterpairing-key command and then the check-master-key-pair-sync command: ERROR:keysync not done.

Repeat for all remaining Subordinate nodes.

12.4.7 Encryption Settings

12.4.8 Authentication Keys

12.4.9 Web Certificate Settings

12.4.10 KMIP Server Settings

Configure connection to a Key Management Interoperability Protocol (KMIP) server and to manage KMIP certificates. (See Key Management Interoperability Protocol Support.)

Specify the following for connection to a KMIP server, and click Save:

12.4.11 KMIP Certificates

Use this section to upload CA and client certificates (X. 509 PEM format).

1. Select the certificate type (CA or Client) and click Choose File to specify the file.
2. Click Upload. Following upload, the certificate is listed in the KMIP Certificates area as "KMIP Server CA Certificate" or "KMIP Client Certificate".
3. Click to create and register a certificate. Specify a name for the certificate and click Create and Register. This action creates a self-signed certificate that lasts for five years (RSA 2048-bit encryption). The full certificate name is the hostname of the cloud node with the creation date appended. The created certificate will be registered on the KMIP server.

12.4.12 Create and Register Encryption Certificates

Create and register encryption certificates. Click Create, enter the information, then click Register.

12.4.13 Retrieve Encryption Certificate from KMIP Server

Specify the certificate and private key name, and click Retrieve to retrieve the certificate from the KMIP server. The certificate is added to the Encryption Certificates list in this section. For example, if you previously registered the certificate mycert, enter mycert-cert and my-cert-key and click Retrieve.

Note: If you have a master-master configuration, any retrieve operation should be done to all masters.

12.4.14 Generating a Self-signed Web Certificate

1. You can download openssl binaries from http://www.openssl.org/ and install them on Windows or Linux. For Linux, check the distribution for the install package. Open a command prompt (or terminal if you are using Linux) and issue the following command. #openssl req =s509 =nodes =days 365 =newkey rsa:2048 =keyout ccl.pem =out ccl.pem This will create a certificate named cc1.pem that will be used to upload from the web UI. When the certificate is uploaded and activated, the web UI will refresh with the self-signed certificate.
2. Click Apply to activate the certificate and deactivate the previously active certificate.

If you already have a certificate signed by a third party to convert into X. 509 PEM, open a text editor and paste the keys from the certificates for the certificate chain in the following order, and save as a PEM file.

• Private.key
• Domain.crt: For domain certificate
• Intermediate.crt: For the Intermediate certificate
• Root.crt: For the Root certificate

12.4.15 Generating a Self-signed Encryption Certificate

1. You can download openssl binaries from http://www.openssl.org/ and install them on Windows or Linux. For Linux, check the distribution for the install package. Use the following command to generate a private key if one does not exist. #openssl genrsa =des3 =out cloudfs.key 2048 Because keys are sensitive information, make sure you store them carefully and encrypt them using a strong passphrase and cipher. You can use the DES, Triple DES, IDEA, or 128, 192, or 256-bit AES symmetric ciphers by adding des, des3, idea, aes 128 , aes 192 , or aes 256 flag to the command line. The default is triple DES (des3).
2. To create a self-signed certificate using the private key that you generated, use the following command: #openssl req =new =s509 =out cloudfs.crt =key cloudfs.key The process prompts you for details to create a Distinguished Name (DN). Some fields have a default value, which you can change as needed. If you enter a

period (.), the field is left blank. The default values are read from the openssl.cfg file. For Common Name, specify the fully qualified domain name (FQDN) of the controller, for example, cc.panzura.com. You can leave the email address, optional company name and challenge password fields blank.

• Country Name (2 letter code) [US]: US
• State or Province Name (full name) []: California
• Locality Name (eg, city) []: San Jose
• Organization Name (eg, company) []: Panzura Inc
• Organizational Unit Name (eg, section) []: Support
• Common Name (eg, YOUR name) []: cc.panzura.com
• Email Address []:

3. Issue the next command to bundle the p12. The command reads the encoded certificate and key and exports to a single PKCS#12 file. By default, the key will be encrypted with triple DES and you will be prompted for an export password (which may be blank). #openssl pkcs12 =export -in cloudfs.crt =inkey cloudfs.key =out cloudfs.p12 =name "Friendly Name" Notes: You can concatenate the root certificate and any other certificates in the chain into a single file (for example, root.crt) and included in the PKCS#12 file as follows: #openssl pkcs12 =export -in cloudfs.crt =inkey cloudfs.key =certfile root.crt =out cloudfs.p12
4. In the node web UI, click Browse under Encryption Certificates to upload the CC1.p12 file, and then select it. Click Apply to activate the certificate and deactivate the previously active certificate.

12.5 CloudFS Settings

To view or assign CloudFS settings, navigate to the following page in the node's web UI Configuration > Distributed CloudFS Use this page to view and configure settings for file storage into the cloud, provided that you have installed a cloud storage license. For information on adding a cloud storage license, see File Access Auditing Support for SMB and NFS Clients.

Deletion from or modification of a node could result in loss of data. For this reason, deletion and editing are not supported in the web UI. Be careful when adding a node. If you enter incorrect information (or need to delete a node), you must work with Panzura Support either by logging in to portal or by sending an email to correct the information or perform the delete operation.

12.5.1 Configure nodes in CloudFS

Specify the list of nodes that are subordinate to this node. This option is configurable only on a node that is a master. The table lists the hostname of the node, the domain name, and the HA mode (active or standby). Click Add Node to add a Subordinate node to the distributed node group.

1. Enter the hostname of the Subordinate node. The hostname must be an FQDN.
2. Enter the domain name. The domain name must be a valid DNS domain.
3. If you are configuring HA-Global, indicate whether this node will be an active or standby system. Set the mode to Active, unless you are configuring an HA standby node. See Encryption Settings for instructions on configuring a standby node.
4. Enter the File System name.
5. Click Add.

SMB Version Support

SMB support is disabled by default. When you enable it, SMBv1, SMBv2, and SMBv3 support all are enabled by default. CloudFS supports the following SMB versions:

SMB Version Used for a Client Session

The SMB version the node uses for a session with a client depends on the SMB version supported by the client. The highest (and most secure) version supported by the client is used by the node. For example, if a client supports SMBv2 but not SMBv3, the node uses SMBv2 for sessions with that client.

SMBv1 is an unsecure version of SMB. Environments that no longer require SMBv1 can disable it with this setting. Microsoft originally made SMBv1 available in the mid-1990s as an IP-capable network communications protocol for use between Windows clients and file servers.

In 2013 Microsoft announced its intent to remove SMBv1 from future products, since it was superseded by later SMB versions. The node continues to provide SMBv1 support for those legacy clients who request to use it.

Supported SMB Features

CloudFS supports the following SMB features:

1. SAMBA 4.5 (SMB server for FreeBSD)
2. SMB encryption 3.0.2, 3.1.1 (AES-128-GCM)
3. Backward compatibility with SMB 1.0 (has no encryption)
4. Leases (file not directory)
5. Secure negotiate
6. Large MTU ( 9000 bytes)
7. Durable file handles
8. Re-authentication

The maximum path length in Windows is 1024 characters. The maximum path length in Unix is 4 K characters. The default maximum read size is 1 MB . If you enable the GRW feature, the maximum path length for Windows and Unix is limited to 1024 characters. The current CloudFS version does not support the following SMB version 3.1.1 features:

1. Persistent file handles across system resets
2. Hyper-V
3. Transparent failover
4. Scale out
5. Directory leases

12.5.2 SMB Shares

The SMB Shares in CloudFS allow users to access and share files stored in cloud storage using the SMB protocol. This section consists of adding details of Share Target Path, Manage Share Access, and S3 Interface.

SMB Settings

SMB Shares

SMB Configuration

SMB Shares

Search

Manage SMB Shares. To add a new SMB Share, click Add. For HA Local with a shared DNS hostname or shared IP address, access SMB shares only through the shared hostname or IP. Using the original node's IP address or hostname is not allowed. $\square$ Share Name $\diamond$ Share Path $\diamond$ Access Restrict ed 53 Gateway Actions $\square$ s3testshare1 /cloudfs/new-r ON - 9001 $\square$ s3testshare111 /cloudfs/new-r snaptest-M2-S ON - 9002 $\square$ s3testshare8 /cloudfs/new-r ON - 9004 $\square$ s3testshare112 /cloudfs/new-r ON - 9003 $\square$ s3testshare115 /cloudfs/new-r ON - 9999 $\square$ s3testshare116 /cloudfs/snapt ON - 9200 e...

12.5.3 Manage Share Access

Enterprise organizations often deploy CloudFS across multiple sites, regions, or business units, each with unique access requirements. Traditionally, ensuring that shares are only visible from specific nodes required complex workarounds or separate configurations.

The Manage Share Access feature transforms this experience by offering:

• Seamless Operational Isolation: Ensures that shares are only visible where needed, greatly reducing the chance of unintended access and enhancing overall data security.
• Effortless Multi-Site Management: Allows customers to confidently manage a unified CloudFS ring while easily maintaining site- or region-specific share visibility.
• Improved Compliance and Security: Helps meet regional or contractual restrictions by controlling data exposure even when user credentials might otherwise permit access.
• Flexible Administration: Enable administrators to easily configure, update, and enforce node-based share access without altering the share definitions or Active Directory permissions.

Using the CloudFS web UI, administrators can restrict the share access when creating or updating SMB shares for a specific node. Once specified, these shares are not visible and cannot be mounted on the restricted node.

Note:

• Applying share access restrictions will restart the SMB server on the applicable nodes. It is recommended to perform this action during off-hours to avoid disrupting any active workloads on these node(s).
• If a nested share with access restrictions already exists for some of the ring nodes, then to ensure consistent access control, apply either similar access restrictions to this share, or configure a Geofencing Policy to protect the subset of file system that requires restricted access.

Create a new SMB Share with access restrictions

1. Log in to the CloudFS Master Node WebUI using admin credential or RBAC user having required access to SME/S3 Settings.
2. Navigate to Configuration $>$ SMB/S3 Settings $>$ SMB Shares.
3. Click Add to manage share access for the selected share.
4. Provide the share name and target path. Select the node(s) you want to restrict share access.

Note: SMB share access restriction is only applicable to the node(s) other than the node mentioned in the Share Target Path. 5. Click Add, and then Save the configuration. 6. After the Share is created, WebUI will display the list of restricted nodes under Access Restricted.

Add SMB Shares

Share path should begin with /cloudfs and include the complete Universal Naming Convention (UNC) path to the target directory you want to share.

Manage Share Access

Select a different node instead of the one mentioned in the Share Target Path.

The newly created share will not be visible from restricted node. The restriction setting will be saved on each node in the configuration file located at /mnt/data/pixel8.cfg

Update SMB Manage Share Access

1. Log in to the CloudFS master node WebUI.
2. Navigate to Configuration $>$ SMB/S3 Settings $>$ SMB Shares.
3. Click the Edit icon of the desired share and update the details as applicable.
4. Select/deselect the node(s) to manage access, then click Done and Save the configuration.

Edit SMB Shares

Share path should begin with /cloudfs and include the complete Universal Naming Convention (UNC) path to the target directory you want to share.

Share Name s3testshare8

Share Target Path /cloudfs/new-ring10/s3share1/sh

Manage Share Access

Select a different node instead of the one mentioned in the Share Target Path.

Select Node(s)

Node(s) To Restrict Share Access

S3 Gateway Access

Valid Port range is from 9001 to 10000. S3 Gateway Port 9004

CANCEL

DONE

Delete SMB Manage Share Access

1. Log in to the CloudFS master node WebUI.
2. Navigate to Configuration > SMB/S3 Settings > SMB Shares.
3. To delete a SMB Share, either click the Deleted icon or select the share and then click Delete.

12.5.4 S3 Interface Access

As more organizations adapt to cloud-native applications, there's an increasing need to collaborate and manage unstructured data across both traditional file-based (SMB/NFS) and modern cloud-native (S3) applications. As a result, organizations often must implement additional object storage systems, adding complexity and operational costs. CloudFS S3 Interface enables seamless collaboration across CloudFS multi-protocol environment, including SMB, NFS, and S3 offering a unified, modern approach to managing unstructured data.

The SMB share data can be accessed using the standard S3 protocol through the S3 API and command-line interfaces like AWS S3. Any buckets and objects created via the CloudFS S3 service are also available through SMB and NFS, appearing as POSIX-compliant files and folders. CloudFS supports global read-write collaboration across both SMB and S3 protocols. Additionally, CloudFS provides the ability to enable the S3 interface for existing SMB shares. This feature utilizes CloudFS features such as data deduplication, compression, and replication for data managed through the S3 interface.

A CloudFS S3 service can be enabled either on a new SMB share or an existing share by providing a port number that is in the range of 9001 to 10000 . In a collaboration mode, it can be accessed from any node to create a bucket and upload an object to the SMB share.

Note: Ensure that the associated port number is enable in your firewall configuration. The S3 Interface is accessible from both WAN and LAN networks and can upload and download data from any node within the CloudFS deployment. In case of mixed protocols-based access, the top-level directories within SMB share map to S3 buckets where Subdirectories map to S3 object paths. Files within these directories map to S3 objects.

CloudFS S3 supports single file uploads up to a maximum size of 5 GB. For larger files, S3 multi-part upload feature is supported and does not impose any size limitations.

Note: While using multipart upload, ensure that the connection remains live by updating the timeout The S3 Interface is SSL-only enabled and uses CloudFS generated SSL Certificate by default. Based on requirement, to configure CA-signed certificates, refer How to generate Self Signed and CA-signed Web Certificate.

The access key and secret key of CloudFS S3 users are mapped to their Identity and Access Management system (IAM) credentials-such as those from Active Directory-ensuring consistent authentication and access control across protocols. Set up appropriate ACL for users and groups as only users with required permissions for a Share should be used. Other users will be authenticated but will not be able to manage the share as required. To access a specific share via a specific node by providing the user's AD credentials, request for an access key and secret key. An Access key session validity is associated with the user's AD session validity. The same access key can be renewed if the session is expired.

Warning: The Geofencing Policy and Manage Share Access in SMB Shares features can restrict user access. If access to shared data is limited by either of these features, users will also be restricted from accessing the data via both S3 and SMB protocols.

Create a new S3 Interface

1. Log in to the CloudFS master Node WebUI using admin credential or RBAC user having required access to SME/S3 Settings.
2. Navigate to Configuration > SMB/S3 Settings > SMB Shares.
3. Click Add for new share or edit for existing share.
4. For a new share, provide the Share name and Share Target Path. Ensure that Share Path begins with /cloudfs and includes the complete Universal Naming Convention (UNC) path to the target directory you want to share.
5. Enable S3 Interface toggle option.
6. Specify a Port number within the valid range of 9001 to 10000 . If the chosen port is already in use, select another available port and try again. Note: Ensure that this port number is enabled in your firewall configuration.
7. Click Add.
8. Save the configuration to enable S3 and SMB protocols for the share.

To configure access to S3 Interface with authorized CA-signed certificates, refer How to generate Self Signed and CA-signed Web Certificate.

Access the S3 Interface

To access a specific share on a node, use the CloudFS REST API with the user's Active Directory (AD) credentials to obtain a temporary access key and secret key. The CloudFS S3 Interface supports two implicit user authentication mechanisms:

1. Kerberos Authentication (Recommended & Default):
2. The system uses the Kerberos Ticket-Granting Ticket (TGT) for authentication.
3. The granted access key and secret key pair remain valid according to the "Maximum lifetime for user ticket renewal" policy defined in your Active Directory configuration.
4. Default Lifetime: 7 days (configurable in AD up to a maximum of 999 days).
5. Post-Expiry: Users must request a new key pair via the REST API once the existing pair expires.
6. NTLMv2 Authentication:
7. The access key and secret key remain valid until the user's AD password expires.
8. Recommended use case: This method is suitable for IoT or application-side usage where Kerberos may be less practical.

To modify these settings in the Windows AD environment, follow the steps below.

1. Open Group Policy Management.
2. Right-click the relevant Domain Policy (for example, Default Domain Policy) and select Edit.
3. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Kerberos Policy. Double-click Maximum lifetime for user ticket and Maximum lifetime for user ticket renewal to modify the values. Set the desired values and click OK.

Refer to the article for more details which is applicable to all the Windows Server versions. Note: These policy changes apply to all users in the AD domain and not to any specific individual user. The following example illustrates authentication using NTLM through a cURL command: Sample request:

$ curl =X POST https://<ipaddress>:9001/admin/v1/auth \
-=H "Content=Type: application/json" \
-d '("username":"as3user?", "password":"abcd123#","share":"mys3s1","Kerberos":false)';

Sample response:

("accessKey":"u1qVPT4XhapyqRoq2RT7RdTo4DCNNaUVSTCBjceq","nt1m":
("success":true),"secretKey":"jeVUmrmgvhaS1z0r82G8PCao7Tzr3AHJ1bALZHLL" )

Delete User Request To delete an existing user and remove the Kerberos token and session, use the following command:

$ curl =X DELETE https://<ipaddress>:9001/admin/v1/auth?user=as3user7 \
-=H "Content=Type: application/json" \
-d '("username":"as3user?", "password":"abcd123#", "share":"mys3s1", "Kerberos":false)';

Update an existing S3 Interface

1. Click the Edit icon of the desired share and enable/disable S3 Interface or change the port number.
2. Update as required. Enable/disable S3 Interface or change the port number.
3. Save the configuration.

Delete an existing S3 Interface

1. Select one or multiple shares and then click Delete.

Note: If a share is deleted, all the secret and access keys generated for accessing the same will no longer be valid. 2. Save the configuration.

12.5.5 SMB Configuration

Access-Based Enumeration

SMBv3 Hide CloudFS Share

Global Real-Time Collaboration

Select whether to enable Access-Based Enumeration (ABE). ABE is an administrative capability available to environments using Microsoft clients with shared files and folders. When enabled, users see only the files and folders they have permission to access. If a user does not have read permission for a specific folder, Windows hides the folder from the user's view. For example, ABE allows you to limit users to see only their personal home directory when they access the home directories shared folder.

Disables/enables support for SMB 3.1.1. (See SMB Version Support.) Hide root shares. Note: To create a new share when this option is enabled (root shares are hidden), you can do either of the following:

1. Temporarily disable this option (Hide CloudFS Share), to make the / cloudfs root share visible, add the new share, then re-enable this option.
2. Mount \hostname\ADMIN$. This mounts the /cloudfs folder. Then create the new share. Make sure to follow the recommended folder hierarchy described above under Share Target Path.

Enables Global Real-Time Collaboration:

1. Click Add Application.
2. Enter a name to identify the application. The application name is for user reference only. The node identifies the application by file extension.
3. Enter the file extension for the application file type (example: .xlsx). Use spaces to separate multiple extensions.
4. Click Save to save and start the collaboration process.

You can also select one or more entries from the Global Real-Time Collaboration list and do the following:

1. Edit Application. Edit an entry.
2. Import Application. Import an application file that was exported from another node.
3. Enable/Disable. Enable or disable global real-time collaboration.
4. Delete to remove selected entries.
5. Export/Import. Export shares the settings with others. Import uses settings exported from another node.

GEOPAK Cross-site Collaboration

Enables support for multiple users across different sites using GEOPAK. To enable cross-site collaboration for GEOPAK, select Geopak from the application list, click More and selected Enabled Selected. Click Save. |

GEOPAK Cross-site Collaboration

This option enables support for multiple users across different sites using GEOPAK. In cross-site configurations the application requires the ability to communicate and coordinate where each user is making edits. Byte-range locking makes this possible. The Read File Consistency feature described above can be used to enable byte range locking for GEOPAK.

Global Real-Time Collaboration Recommendations

Panzura recommends using the Global Real-Time Collaboration option selectively, because it adds additional operations for the node. With many cross-site collaborative users opening numerous files, the network traffic to handle read consistency and additional load on the node's CPU should be closely monitored.

When a file is open on a CloudFS node, other clients connected to the same filer won't see the updated file's write time until the file is closed. This is done to optimize performance. However, clients connected to other nodes in the ring will see the updated write time. If you want all clients to see the updated write time immediately, you can contact Panzura support to include the following SMBD configuration change: smbd getinfo ask sharemode $=$ No

12.6 NFS/SMB Mixed Mode

The purpose of this chapter is to instruct the user on how to configure mixed mode for CloudFS. Follow the steps outlined in this document in sequential order unless otherwise noted.

12.6.1 CloudFS NFS/SMB Mixed Mode Details

There are two new configuration variables needed for mixed mode configuration:

• Mapping Type
• Currently three choices:
• hash
• auto-rid
• AD/LDAP
• ID Mapping Range
• Integer range (1-2147483648), system-wide

12.6.2 Mapping Type

The mapping algorithm is a system-wide parameter and is used to select which mechanism to map Windows SIDs to and from UNIX UID/GID entries. The current mechanism is called "hash" and is the default selection. For mixed mode, use "autorid" for the mechanism.

To support existing installs that do not intend to use mixed mode, Panzura suggests using "hash" as the default selection. Changing this parameter after the system has been in use may cause file access permission issues. Panzura recommends modification at the time of initial install only.

12.6.3 Panzura CloudFS 8.2.1.0 Features a New Mapping Type: AD/LDAP

AD/LDAP is intended for customer sites that are using LDAP services via Microsoft Active Directory (AD). These services are provided by the RFC2307 extensions to AD.

This configuration is often used by organizations that have a significant heterogeneous installation of Microsoft Windows and UNIX/Linux systems and wish to maintain a centralized control over user authentication and identity management.

In this case, the AD administrator is responsible for assigning a valid UID and GID to each user and group that will be accessing files from the Panzura CloudFS system. It is not strictly necessary for the UNIX/Linux clients to be joined to the AD domain, however it can make client configuration with winbind or SSSD easier.

12.6.4 ID Mapping Range

The mapping range is a system-wide parameter used to assign a UID/GID number for each SID that is presented to the system. Each SID represents a single security principle, such as a user or built-in system services. Each SID is mapped to a single number using the mapping algorithm, so the range must be large enough to accommodate the number of users it is expected to serve.

Warning: Changing this value after the initial configuration may cause users to lose ownership of their files. This value is not editable for the hash mapping type. For mixed mode, you must reserve some of the range for NFS clients that have UID's that are local to the client machine. The NFS clients and CloudFS must share the same range and the same mapping algorithm in order for the IDs to be mapped properly across systems. So, you must reserve some amount of space for wellknown IDs and local security principles.

Since it is not possible to determine this automatically, the system administrator must have the means to block off a range of IDs to be reserved for the clients. Most UNIX systems begin to allocate local IDs at roughly #1000; however, this is system dependent. A range of (20000-24999999) may be a reasonable default, but this should be adjustable to accommodate individual customer environments.

12.6.5 Reserved Mapping Range

This range is used to map users or groups that are either local IDs or built-in accounts. This range must not overlap the mapping range. It may span a range smaller than the start of the mapping range or larger than the end of the mapping range.

12.6.6 Additional Information

To configure mixed mode properly, it is necessary that all NFS clients use Active Directory for ID services. It is not necessary to enable LDAP or RFC2307 directory services.

You must also configure NFS clients using winbind and use the same mapping type and range as configured in CloudFS. This ensures that the mapping representing a user login is constant between both NFS and SMB clients. Additionally, this ensures that file ownership and file permissions are correct and constant.

Kerberos authentication/encryption is not required. NFSv4 is not required but is necessary for NFS clients that wish to display or modify ACLs. Warning: Mixed mode use is intended for NAS type workflows and is not compatible with simultaneous GRW access.

12.6.7 Configuring Mixed Mode for CloudFS

1. From the Configuration screen in the CloudFS web UI, select SMB/NFS Mixed Mode from the navigation menu on the left side of the screen.
2. Select Auto-rid from the Mapping Type drop-down menu.
3. You may enter desired values in the Start and End fields or leave the default values as displayed on the screen.
4. Click Save to apply the changes.
5. Select SMB/S3 Settings from the navigation menu on the left side of the screen.
6. Add an SMB share by entering your desired information in the following sections:

• Share Name
• Share Target Path

7. Click Add to apply the changes.
8. Select NFS Settings from the navigation menu on the left side of the screen.
9. Add an NFS share by entering your desired information in the following sections:

• Use Network (on/off toggle)
• Filesystems
• Exports
• Host Network
• Permission
• Root Access
• Description

10. Click Add to apply the changes.
11. Click Save.

Notes:

• For information on using NFS mixed mode with SSSD, go to https://panzura.cloud.answerhub.com/articles/2253/using-nfs-mixed-mode-with-sssd.html.
• For information on troubleshooting CloudFS mixed mode issues, click https://panzura.cloud.answerhub.com/articles/1935/cloudfs-mixed-mode-trouble-shooting-guide.html.
• Changing the ID mapping method after initial configuration can cause unexpected side effects such as loss of file access or permissions issues, as well as file ownership issues.
• Currently, it is not possible to convert an existing Panzura CloudFS installation from normal operation to mixed mode operations consult with customer support.
• For enhanced security, using Kerberos for NFS exports is recommended.
• The use of NFSv4 is also recommended, as it allows for the use of fine-grained file permission control using NFSv4 ACLs.

12.6.8 Configuration Wizard

Only pertains to Panzura CloudFS? The configuration wizard manager opens when you click Continue with Optional Wizards at the end of the setup wizard. See the wizard's online help for details.

12.7 NFS Settings

To configure Network File System (NFS) settings, navigate to the following section Configuration > NFS. The NFS settings determine which NFS clients or subnets can access the data stored on the node. Clients use NFS to mount storage on the node. In addition to the host access control settings, the file system on the client is used to determine which users have permission to access individual files and directories in CloudFS.

• The NFS settings are active only if NFS is licensed and one of the NFS options is selected under the system settings. See https://know.panzura.com/systemsettings.
• The locking protocols for NFSv3 and NFSv4 are different. NFSv3 uses a network lock manager, whereas NFSv4 includes built-in file locking. To avoid compatibility issues, Panzura recommends keeping NFSv3 and NFSv4 on different exports. If you must use NFSv3 and NFSv4 on the same export, be aware that file range locking only works within NFSv3 or NFSv4, not between the two versions.
• Using NFSv3 with the nolock option is recommended when there is no concurrent file access from multiple clients and you want to continue using NFSv3.
• To use NFS on Windows, use nolock and fileaccess 777 . These are required for file write permissions.
• Windows 7, Windows 8, Windows 2012, and Windows 2012 R2 are not compatible with NFSv4 and therefore are not able to connect using the protocol. NFSv3 is recommended.
• In some cases, the NFS access control settings apply only to the NFSv3 mountd protocol.
• When a sub-directory is exported, if other sub-directories on the same filesystem (including the filesystem mount point itself) were previously mounted, the client might still be able to access the mount point. But the new mount access to the previous exported directories will be denied.
• For NFSv4, if any of the sub-directories was exported, the parent filesystem is also exported. So if /cloudfs//dir1 is exported, the client will be able to mount / cloudfs/ with NFsv4 if it is enabled.
• On the CloudFS node, the sysctl parameter vfs.nfsd.inodes32b needs to be set to 1 in order for the NFS server to use 32-bit inode numbers in calls like list directory. If not set, then 32-bit applications running from the NFS mountpoint at the client would fail. Please set below configuration on the CloudFS node and restart NFS daemon. Please contact the Panzura support team to get this configuration done. $ sysctl vfs.nfsd.inodes32b=1

12.7.1 Sample NFS Configurations

Example 1: Provide Maximum Access

In the following example, maximum access to the file system is provided for the specified network.

Filesystem Configuration

• Filesystem: /cloudfs/f01-cs
• Use Network: enabled
• Host/Network: 10.0.0.0/#
• Exports: (no directory specified)
• Permission: Read-write
• Root Access: Yes
• Alldirs Mount: Yes

The path /cloudfs/f01-cs is exported to network 10.0.0.0/#.

Example 2: Provide Granular Access

In the following example, access to a particular directory is provided for a particular host.

Filesystem Configuration

• Filesystem: /cloudfs/f01-cs
• Use Network: disabled
• Host/Network: 10.1.2.3
• Exports: dir1
• Permission: Read-write
• Root Access: No

• Alldirs Mount: No

The path /cloudfs/f01-ca/dir1 is exported to host 10.1.2.3.

Sample Mount Commands

If NFS is used for application that is not sensitive to IO errors, and user wants a better experience when the NFS server is temporarily unavailable. Only use the intr option for Linux kernel version 2.6.25 or prior. sudo mount -t nfs -o rw,bg,vers=3,tcp,raise=1048576,weise=1048576 10.0.0.92:/cloudfs/f01-ca /dir1

If NFS is used for IO error sensitive workloads, such as database workloads, do not use intr. Notice that the following command also specifies:

• the use of NFSv4 (vers=4) instead of NFSv3 (vers=3).
• hard as it serves its own distinct purpose (avoiding silent IO errors when the server is briefly unreachable).

To support NFSv4, you must enable it in the NFSv4 Settings section, as shown in the following table. sudo mount -t nfs -o rw,bg,nointr,hard,vers=4,tcp,raise=1048576,weise=1048576 10.0.0.92:/cloudfs/f01-ca /dir1

Note: The intr/nointr option for the following has been deprecated:

• Linux kernel version 2.6.25 onwards
• Red Hat KB (RHEL 6+) onwards

Host/Network Format for Export

The Use Network option controls the format for exported IP addresses.

Use Network selected:

Configure a network using either of the following formats:

1. ip-address netmask
2. ip-address/netmask-length

Examples:

1. 10.1.1.0 $\mathrm{255.255.255.0}$
2. $10.1.1.0/24$

Use Network not selected: Specify one or more hostnames or IP addresses. Use a space between each hostname or IP address as a delimiter.

12.7.2 NFS Exports

12.7.3 Netgroup Settings

12.7.4 NFSv4 Settings

12.8 Setting up Snapshots

This section explains how to configure snapshots. Using the default snapshot schedule is recommended, however if your environment requires a different schedule, review this section before making changes.

All snapshots consume a small amount of storage space. It is important to balance the need for snapshots with the total amount of storage consumed by snapshots to ensure proper operation for end users. In extreme cases when these two factors are not balanced, end users will experience reduced system performance.

Snapshots are among the most space efficient available and consume a minimal amount of space. The size of a snapshot is a function of two factors: the rate at which end users create or change files, and the total size of all file changes.

CloudFS nodes can be deployed in a wide range of use cases and configurations. For the cross-site collaboration use case, the snapshot schedule of a node can affect other nodes within the same CloudFS. This is due to the metadata associated with each snapshot being shared across all nodes.

If the total space of the snapshot metadata on a node is large, it can affect the amount of available disk cache on other nodes, the result being an increase in the eviction rate of cached user data on the other nodes. To guard against this, some storage space was set aside for this purpose when the size of the nodes was assessed.

For multi-node deployments, an additional option is available on subordinate node to manage snapshot retention for that node. The Node Specific Snapshot Policy allows customized snapshot retention periods for file owner as well as data owner node. When enabled, it allows data owner node to retain a smaller number of user snapshots than the file owner node. This approach reduces snapshot metadata growth on data owner (leaf) nodes, reduces cache pressure without impacting access to file versions, as all versions are preserved on the file owner. This is more beneficial in large deployment with active workload.

To be able to use the Windows Previous Version capability, it is suggested to schedule a snapshot with 1,000 - 2,000 snapshots. If you have business reasons for needing to maintain hourly snapshots over an extended period of time, it is recommended that you use the -snapshot directory to recover files instead. Contact Panzura Support to confirm that your node has sufficient PRC for end-user data and the large number of snapshots.

Use the smb-add-gcfg $\mathbf{pz}$ allow browse snapshots=yes maintenance command to allow browsing of the -snapshot directory for each share. For more information, see smb-add_ggfg in Diagnostic Tools.

The snapshot schedule provides the ability to define the number of snapshots to retain. For example, the schedule below specifies the most current 24 hourly snapshots be retained. When a new hourly snapshot is taken, the oldest hourly snapshot is removed.

When a new snapshot schedule is enabled, periodically check the disk cache utilization of all nodes within the same CloudFS to ensure there are no negative effects. Should any occur, modify the schedule or contact Panzura Support either by logging in to portal or by sending an email.

12.8.1 Snapshot Settings

The snapshot settings have the following default values. The settings are described in detail in the table below.

1. Number of Yearly snapshots to keep: 1
2. Number of Monthly snapshots to keep: 11
3. Number of Weekly snapshots to keep: 3
4. Number of Daily snapshots to keep: 6
5. Number of Hourly snapshots to keep: 24
6. Number of Quarter-Hourly Snapshots To Keep: 4

Panzura cloud nodes are capable of 10 K snapshots when deployed with the cross-site collaboration feature disabled. The node must be properly sized to ensure sufficient space is available for both snapshots and end-user activity.

After setting values, click Save.

12.8.2 Node Snapshot Settings

12.8.3 How to Enable the Node Specific Snapshot Policy

1. Log in to the CloudFS subordinate node Web UI using administrator credentials or an RBAC user with Snapshot Settings access.
2. Navigate to Configuration $>>$ Snapshot Settings $>>$ Node Snapshot Settings, enable Node Specific Snapshot Policy, click Confirm on the pop-up warning, and click Save. Warning: It is recommended to use this feature on a data node. Once the number of snapshots is set to a lower value, restoring older Point-InTime file versions via this node will no longer be supported. However, they will still be accessible from the file-owner node that keeps a longer snapshot history.
3. Update the parameters as needed, then click Save to apply the changes. When the Node Specific Snapshot Policy, toggle is enabled, it applies only to the current node and does not synchronize with the master node. When disabled, the snapshot settings automatically synchronizes with the master node configuration.

Snapshot Settings

Node Snapshot Settings

Snapshot Manager

Node Snapshot Settings

Configure Node Snapshot Settings. Enable Scheduled Snapshots

Number of Yearly Snapshots to Keep 1

Number of Weekly Snapshots to Keep 3

Number of Hourly Snapshots to Keep 24

Hourly Schedule i

AM $\begin{array}{llllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll

12.8.5 Snapshot Manager

12.9 Setting Up Smart Cache

https://know.panzura.com/setting-up-smart-cache

To configure Smart Cache settings, navigate to the Configuration $>$ Smart Cache section. The node supports Smart Cache, which is designed to provide LAN speed access to data stored in the cloud. Cache policies allow you to select specific files and data blocks to be continuously cached locally in the node. Cache policies act on local or remote file systems and provide automated caching, or pinning, of file data. You can create one cache policy for each file system, and each policy can have multiple rules within the policy.

Panzura recommends using the auto cache action with prepopulate enabled. This ensures that files are available in disk cache for end users. Prepopulating makes the data available without forcing a reduction in cache.

Pinning allows an administrator to forcefully localize (pin) data in the cache within a node to provide guaranteed LAN speed performance. Because pinning consumes cache space, it should be considered only if needed for performance, with the trade-off between performance and cache space kept in mind.

12.9.1 Cache Settings

12.9.2 Cache Policies

Smart Cache Setting Policy Parameters

Description

12.9.3 Policy Configuration Example

In the following example, a Smart Cache policy (also called a data locality policy) is configured.

1. First, click the Add Policy button.
2. It will prompt the following window. Name the policy, click the Add button. For example, it is called Policy-1.

3. The new page appears as shown in the image. To create a new rule, click the Add Rule button.
4. A window will appear. For example, add the following rule: /homedir/sampledir/*. Click Add button. This rule locally caches all files in the /homdir/ sampledir/ folder.

Note:

This section is meant only as an example. Your configuration may contain more rules, depending on the content to be cached locally.

5. After configuring rules and adding them to a policy, click Save to save the changes.

12.9.4 Setting Up Cache Policies

Follow this process to set up cache policies. Details are in the following table.

1. Click Add Policy.
2. Add a policy name, select the filesystem, and verify the default action. Panzura recommends that you keep the default action as auto-cache and then use rules to assign pinning. Click Add. The policy is added.
3. Click the arrow to the left of the policy, if needed, to display additional settings.
4. Click Add Filesystem if you want to add another filesystem to the policy. Select the filesystem and default action and click Add. A filesystem can be included in at most one policy, so your choices are limited to filesystems that have not yet been assigned to a policy. You can also edit or delete a filesystem entry from the table.
5. Click Add Rule to add a rule to the policy. See details in the following table. Rules are considered in the listed order. Use the Up and Down arrows to change order.

12.9.5 Policy Location (Which Node Is It On?)

If you have multiple nodes in the cloud file system, the Filesystem drop-down list has multiple entries. In this case, you must decide where to apply the policy: to the local node's file system, or to a remote node's file system on this local node. For example, assume that you have nodes at site A and B. You are working from site A, but the data of interest is on site B. For the policy, select the node B file system from the drop-down. Then when data is written to the remote file system, it is also localized on node A.

12.10 High Availability Settings

Panzura CloudFS High Availability (HA) maintains continuity of SMB and NFS file services when a node in a CloudFS ring becomes unavailable. Local HA (LHA) pairs an active node with a designated standby node that share a common Virtual IP (VIP) address or DNS hostname. If the active node goes down, the standby node can take over that identity so client connections are restored with minimal disruption.

To configure High Availability settings, navigate to the following page in the Panzura CloudFS web UI: Configuration > High Availability.

12.10.1 Panzura node HA Solutions

The following HA solutions are supported:

1. HA Local: An active node is protected by a dedicated standby. When the active node fails, the passive standby assumes its identity and takes over operations. HA Local is similar to the methods used by legacy enterprise storage product. In this configuration, an active node is protected by a dedicated, passive standby. When the active node fails, the standby takes over ownership of the file system and the node operations. The following HA Local options are supported:
2. Local: The active and standby nodes have different hostnames and IP addresses.
3. Local with shared address: The active node and passive standby have an additional shared hostname and IP address, which simplifies the takeover process. (Maximum length of the shared hostname is 15 characters.)
4. HA Global: One or more nodes are protected by one or more shared standbys, which can be separated geographically from the nodes they protect.

12.10.2 Sample HA Deployment

Consider a Panzura deployment with three working sites-Los Angeles, London, and Paris-and two sites provisioned for high availability (HA)—Phoenix and Amsterdam. A Panzura node is physically deployed at each site. Users at the three working sites connect to their local node, have a complete view of the shared file system, and experience LAN-speed access to data in the global file system.

In this example, the HA configuration is as follows:

1. HA-Global: The node in Amsterdam protects both subordinates in London and Paris, as well as the master node in LA.
2. HA-Local: The node in Phoenix is dedicated to protecting the master node in Los Angeles.

The following HA-Local deployment options are supported:

1. Local: The active and standby nodes have different hostnames and IP addresses.
2. Local with shared address: The active node and passive standby have an additional shared hostname and IP address, which simplifies the takeover process. (Maximum length of the shared hostname is 15 characters.)

12.10.3 Best Practices

• When configuring the shared VIP or DNS hostname, ensure the auto-failover feature flag is disabled. Auto failover is not currently supported.
• Confirm that all nodes in the ring are up, running, and healthy before enabling a shared VIP on the master node and before removing a shared VIP on the master node.
• Before setting up Local HA on a shared VIP for an existing master node, confirm that all nodes in the ring are up, running, and healthy.

12.10.4 Status Information Exchanged by the Active and Standby Nodes

The Active and Standby nodes (peers) exchange information in order to make a coordinated decision on triggering a takeover. The following information is exchanged between the two peers, over an SSH connection that is automatically established between the two nodes when the HA pair is configured:

1. Cloud status: Determined by a configured number of upload/download failures over a period of time.
2. File system status: Status of the file system (based on number of metaslab errors encountered).
3. Import status: Based on whether the node successfully imports the file system after a reboot (either forced or unscheduled).
4. Critical process failed: Triggers failover if all remaining retries for a process fail.
5. Snapshot sync status: Determines eligibility for a failover based on snapshot sync status. If the snapshot sync status is 50 or more snapshots behind, failover is not allowed.
6. Scheduled reboot: If the active node is scheduled to reboot, HA takes this into account and does not perform a failover when the rebooting node goes offline during its reboot.
7. State change: Used to figure out whether the takeover is impending.

12.10.5 Setting Up HA

HA can be configured either during initial setup using the setup wizard, or later using the management web UI.

HA operations that are:

• Supported: LHA failover abort
• Not Supported: GHA failover abort, Auto failover

Configuring Local HA for an Existing Active Node

Note: Before configuring Local HA for the master node with a shared VIP, confirm that every node in the ring is active, up, and healthy.

1. From the configuration wizard, set Configuration Mode to HA Local and enter the Master Node Hostname so the node can register and retrieve cluster configuration, including licenses.
2. Under Peer-to-Peer Authentication Key, upload the peer-to-peer authentication key for the pairing and confirm it uploads successfully.
3. Under Role, select HA Local, then provide the Master Node Name details.
4. Provide the Active Node Name to be used for the HA configuration.
5. If a Shared DNS Hostname is provided during configuration, it is applied to the active node. The active node must then be rejoined to the Active Directory domain for the change to take effect.

Removing Local HA Without Disrupting Active SMB I/O

1. Go to Configuration > High Availability.
2. Select the HA pair to remove, then click Unpair.
3. Review the warning dialog and click $\mathbf{OK}$ to confirm.

Note: The Preserve VIP option is enabled by default. Leave the Remove VIP checkbox unchecked so HA protection is removed while SMB clients continue accessing shares through the existing VIP hostname - no Active Directory changes or client reconnection are required.

Replacing Local HA Without Removing the VIP

To replace the standby node in an existing pairing while keeping the shared VIP intact, follow the Unpair procedure in 'Removing Local HA Without Disrupting Active SMB I/O' section with Remove VIP left unchecked. This detaches the current standby node while the shared VIP remains active on the master node. A new standby node can then be paired to the preserved VIP using the configuration steps in Configuring Local HA for an Existing Active Node section.

Migrating Local HA to Another Platform (Removing the Shared VIP)

Two migration paths are available, depending on whether the environment can tolerate removing the VIP immediately or requires a temporary preservation period. READY TO REMOVE THE VIP DURING UNPAIR

1. Unpair the HA configuration and select the Remove VIP option. Follow the instructions provided by the wizard.

Unpair HA Configuration

Remove VIP node01-pn2o-vip/10.64.84.200 from active node node01-pn2o. Warning: This will unpair the HA configuration and remove the VIP from the active node.

• HA protection will be removed
• SMB clients using the VIP hostname will lose connectivity
• The node must be rejoined to Active Directory
• Clients must reconnect using the node's original hostname
• This may cause application disruption

Do you wish to proceed? 2. Set up the new LHA VM on the target platform (for example, a cloud platform), then perform node configuration.

VIP PRESERVATION NEEDED BEFORE DOWNTIME

Use this path when the VIP cannot be removed immediately and needs to remain active until a scheduled downtime window.

1. Preserve the shared VIP and continue running the I/O workload on the shared VIP.
2. Remove the preserved VIP. Contact Panzura Support to perform this operation.

3. Set up the new LHA VM on the target platform (for example, a cloud platform) and configure HA as required.

ABORTING A STUCK FAILOVER

1. Monitor the failover logs under Maintenance $>$ High Availability (HA) $>$ Takeover Status. If the failover operation appears stuck, click Abort.
2. Confirm the abort when prompted. As part of the failover-abort procedure, the administrator must consent to rebooting the standby node; the node may temporarily disconnect from the UI and will reconnect automatically after reboot.

12.11 Default Auto Prepopulate/Prefetching Features

The following prefetching operations occur automatically.

Folder Prefetching Based on Ownership Change

The node prefetches a folder whenever ownership of the folder changes from one node to another.

1. This prefetching remains in effect for a folder for 3 days after ownership of the folder changes.
2. This new type of prefetching is performed automatically.
3. Prefetching continues until there have been no ownership changes for 3 days.
4. We recommend users to 'Enable Auto Prepop' by default for a good experience and more robustness.

Automatic File Caching

The node automatically caches both read and written data:

1. Written data is automatically cached.
2. Read data that is not already cached is cached.

Automatic Block Prefetch

When a user requests a file, the node immediately prefetches the remaining blocks of the file. By automatically prefetching the file's blocks, the node provides rapid access to users who likely will require access to more of the file's blocks before finishing with the file.

File Block Grouping

Another optimization feature that the node automatically employs is file block grouping. File group blocking groups blocks based on either or both of the following:

1. Filename. The blocks are in the same file.
2. Time when the blocks are saved. Blocks of any files that are saved at around the same time are grouped into the same block files.

Adjacent Block Prefetching

For further optimization, when a drive file is downloaded, the blocks saved immediately before and after the requested file also are downloaded.

1. The last block to be saved before a block of the requested file was saved also is downloaded.
2. Likewise, the first block to be saved after a block of the requested file is saved also is downloaded.

12.11.1 Sample Rules

The following table shows some examples of rule use cases and the rules used to implement them.

12.11.2 Escape Characters

To use a special character reserved for policy rule matching as part of a string, use an escape character: Sys:* This rule matches Sys* but does not match Sys#. For example, if you enter *.xls and then select Pinned as the action, the rule pins all files with a .xls extension.

12.11.3 Rule Actions

Each rule includes an action that the file performs when the rule is matched:

1. Auto Cache: This is the standard behavior of the node. The node will evict blocks of a file as needed to accommodate new data.
2. Deny: When this action is selected, the creation of files with names matching the glob expression is not allowed for that file system.
3. Do Not Cache: This action effectively applies a 'first out' policy to the data. Data is cached but will be evicted first before other data if space is required in the node, regardless of the type of data.
4. Pinned: Applies a 'last out' policy to data. It avoids evicting data unless the cache is full and new priority data is being ingested. Pinned data will be evicted only as a last resort after other data to maintain normal operations.
5. Not Replicated: Causes the data not to be copied to the cloud. This creates an unprotected scratch or temp space and should be used cautiously since the data is temporary.

12.12 Active Directory

12.12.1 SMB/CIFS File System Security

CloudFS file system security is compatible with and adheres to the Microsoft SMB/CIFS architecture. Files and directories can have user permissions or group permissions known as Active Directory security ACLs.

The security ACL information is made available via Microsoft Active Directory network queries between the client, the Active Directory Forest, and the node. This relationship is established and initiated during the client login to the node.

12.12.2 Joining a Microsoft Active Directory Domain

The node is designed to participate in Microsoft Active Directory Enterprise Forest topologies and therefore does not support an SMB workgroup-only authentication model (an SMB network with no Active Directory Domain node).

An internal DNS server should be accessible to the node during the Active Directory join process. The node will try to understand the Active Directory topology during the join process and locate many Active Directory servers within the domain. These servers will be used as potential candidates during the join process.

The process of joining a node to an Active Directory domain will populate key domain security ACLs within the default BUILTIN groups. This facilitates global read-write SMB/CIFS file sharing access throughout the Panzura unified namespace for each node in CloudFS (such as ..\cloudfs\cc1, ..\cloudfs\cc2, ..\cloudfs\cc3).

By default, the Active Directory groups 'Domain Admins' and 'Domain Users' are members of the Active Directory BUILTIN groups. If additional domain ACL security is needed, these can be modified after successfully joining the Active Directory domain.

For SMB, the node needs to join the AD domain that enforces the RBAC policies. Enabling a storage device to join the AD domain can be delegated to any user with this privilege. Panzura has found that in most cases, AD administrators tend to manage the devices that can join the AD domain. For this reason, AD administrator credentials are required during initial setup of a node.

12.12.3 WebUI Authentication Using Active Directory

If the node has joined an Active Directory domain, you can set up your AD domain node to allow authentication to the Panzura node using Active Directory credentials without additional setup in the Panzura node. To use this feature, add the following two groups to the AD domain node: priv_panzura_admins , priv_panzura_users.

Set the group scope to Global and group type to Security. Users assigned to either of these groups can then log in to the Panzura node using their AD credentials. Both of the following username formats are accepted: username@domainname domainname\username To join the Active Directory domain that you configured, navigate to the node Web UI Configuration > Active Directory > Active Directory Configuration. Enter the required AD information and click Configuration > Active Directory > Join Active Directory Domain. Enter your Domain Administrator credentials and click the Join button. The page displays the name of the domain node (if configured) and the current Active Directory domain status.

If you are joining an Active Directory Read Only Domain Controller, see Adding a Read Only Domain Controller. To remove the node from an Active Directory Domain, navigate to Configuration > Active Directory > Join Active Directory Domain, enter your Domain Administrator credentials, and click the Detach button.

12.12.4 Active Directory Configuration

12.12.5 Join Active Directory Domain

12.13 License Manager

To add, activate, or deactivate other licenses on the node, navigate to the following section: Configuration > License. The system identifier shown near the top of the page is unique to each node and is used to generate and request licenses. You can also specify settings for file access auditing, as described in File Access Auditing Support for SMB and NFS Clients and Antivirus and Malware Scanning. For AMI nodes running within a public cloud to be added to a CloudFS configuration, installation of an AMI Interoperability license on all other nodes is required. Contact Panzura Support to obtain the licenses.

12.13.1 Managing Licenses

Panzura licenses can be installed using either of the following methods:

• License token: This the simpler method and is the default for deployments in which Secure Private Network Mode is disabled. A single 34-character token provided by Panzura is required. You enter this token either while running the setup wizard or in the Web UI as described here.
• Individual license files: This method is the only method supported for Secure Private Network Mode. Individual license files keyed uniquely to the node are installed.

Panzura license files are not the same thing as either cloud storage provider (CSP) licenses, or peer-to-peer authentication key files. CSP licenses are issued by your CSP and authenticate access to your cloud storage. Peer-to-peer key files authenticate peer-to-peer communication among all nodes that have the same master Node (including the master Node itself).

12.13.2 Installed Licenses Module

Perform the following operations as applicable to the license type, token-based or individual license-based licenses:

Add License

Upload a valid license file.

1. A pop-up is displayed as Upload License.
2. Click Choose File to locate the license file.
3. Click Add to make the license available for activation.

Edit License

Modify the license details.

1. Select the license to be edited.
2. Click Edit and update the details to be modified.

Reload License

You can reload the license file.

1. Select the license from the list.
2. Click Reload to help license change take the effect.

Activate License

You can change the license status which is in 'New' or 'Deactive' status.

1. Select the license from the list which is in 'Deactive' status.
2. Click Activate to enable the license and take the effect.

Deactivate License

You can change the license status that is currently in 'Active' status.

1. From the list, select the license in 'Active' status.
2. Click Deactivate to disable the license.

Note: Licenses with 'New' status cannot be deactivated. A license must be in 'Active' status to be deactivated.

Delete License

You can delete the license using 'Delete' option.

1. From the list, select the license to be deleted.
2. Click 'Delete'. Click 'Confirm' on the confirmation box.

The license is deleted from the list. Note: Managed Capacity licenses must be purchased in whole TB increments, starting with a minimum of 25 TB . Subsequent purchases can be 5 TB or more (for example, $5\mathrm{TB},6\mathrm{TB},12$ or 100 TB ) up to $100,000\mathrm{TB}$. For further assistance, contact Panzura Support either by logging in to portal or by sending an email to [email protected].

12.13.3 Activate License Token

Use this option to add additional license tokens to the existing ones, or to override specific components of an existing license with a separate token. You can create and upload the required token through this option. Provide the following details and click 'Activate'.

1. License Token 2. CSP size 3. Unit 4. Cloud Type

12.13.4 S3 API Signature Version

When an API request is made with details such as the access key, secret key, payload, and headers, a security signature is generated. This signature is then used to validate the request, after which the request is processed and a response is returned."

Provide the following details and click Confirm. CSP Provider Name: Bucket Name: Path: Select the signature version: V2 or V4

CMP

Provider Name: Bucket Name: Path: Select the signature version: V2 or V4

12.13.5 S3 Storage Class (Configure S3 Storage Class)

Organizations had to manage storage class tiering outside of CloudFS, making the process complex, time-consuming, and potentially cost-ineffective. The Storage Class configuration feature helps administrators reduce costs and simplify storage management by assigning objects to the appropriate storage class.

Note: In CloudFS, the objects once created cannot be modified. When a file is updated or changed, CloudFS generates new objects to represent the modified portions while retaining the original objects as-is. The newly created objects are uploaded using the active storage class configured at the time of the update, while unchanged objects remain in their original storage class. By default, AWS uses Intelligent-Tiering, whereas Azure and GCP use their respective default storage classes. This behavior is consistent across all the supported cloud providers.

Important rules with respect to overriding the storage tiering in CloudFS:

1. You can change or override the tier in any point of time.
2. After changing the tier, the new data will be navigated to the new tier selected and the existing data will remain in the previous storage tier itself.

CloudFS supports following storage class:

• AWS S3 Storage Class
• Azure Storage Class
• Google Cloud Platform (GCP) Storage Class

Note: Storage Class can only be configured for cloud provider at node level (for CSP and CMP), not for snapshot or file level.

AWS S3 Storage Class

Amazon S3 storage offers different access tiers for storing the data in a most cost-effective manner based on the business usecase. The access tiers options available in Amazon storage class:

1. Standard (S3 Standard)
2. Intelligent Tiering (S3 Intelligent Tiering)
3. Infrequent Access (S3 Standard-IA)
4. Glacier Instant Retrieval (S3 Glacier Instant Retrieval)

AWS pricing details are available at: https://aws.amazon.com/s3/pricing/

Configure AWS S3 Storage Class

1. Login to CloudFS master node master node web UI using administrator credentials or RBAC user having write access to License Manager.
2. Click on Configuration tab.
3. Navigate to License Manager > S3 Storage Class. Provide appropriate details and click Confirm.

CSP

• Provider Name - AWS
• Bucket Name
• Path
• Storage Class - Standard, Intelligent Tiering, Infrequent Access, Glacier Instant Retrieval (Select the storage class from the dropdown).

S3 Storage Class

S3 Storage Class

CSP Provider Name Amazon

Bucket Name

python-sanity-bucket

Path

automated-pipes-csp

Storage Class

Intelligent Tiering

CONFIRM

Edit AWS S3 Storage Class

1. Select the respective AWS license.

2. Click EDIT, select the required 'Storage Class'.

Edit License

Warning! This operation may reboot the system, stop all current read/write operations, delete all data stored in the storage and clear all reporting statistics.

PATH automated-pipes-csp

CLOUD HOST IP/NAME https://s3.us-west-2.amazonaws.

S3 ACCESS KEY AKIA5HRPSHPGKX4WUYWF

S3 SECRET KEY Required

BUCKET python-sanity-bucket

S3 API SignatureVersion V4

Storage Class Intelligent Tiering SSE-KMS

Azure Storage Class

Azure storage class option is provided to manage and save costs for customer expansion storage needs. It is helpful to organize data based on how frequently the storage tiers are accessed.

The Azure storage offers different access tiers for storing the blob data in a most cost-effective manner based on the usage. The table states the options available in Azure storage class: 1. Hot 2. Cool 3. Cold 4. Archive

These tiers are also known as online tiers and have latency in milliseconds with hot tier having least and cold tier having highest latency. Azure pricing details are available at: https://azure.microsoft.com/en-us/pricing/details/storage/blobs/

Configure Azure storage class

1. Login to CloudFS master node master node web UI using administrator credentials or RBAC user having write access to License Manager.
2. Click on the Configuration tab.
3. Select License Manager > S3 Storage Class.
4. You will see the following details on the S3 Storage Class. Provide appropriate details and click Confirm. CSP

• Provider Name - Azure (non-editable)

• Container Name
• Path
• Storage Class - Hot, Cool, Cold (Select the storage class from the dropdown).

CMP

• Provider Name - Azure
• Container Name
• Path * Storage Class Hot, Cool, Cold (Select the value from the dropdown).

5. Navigate to storage account of Microsoft Azure (Home > Storage accounts). 6. Verify that the appropriate "Access tier" is applied to the objects which are getting uploaded to the cloud.

HOME CONFIGURATION 8

S3 API Signature Version

S3 Storage Class

S3 Storage Class

S3 Storage Class

CSP Provider Name Azure Container Name vscontainer Path auto1 Storage Class Cold CMP Provider Name Azure Container Name vscontainer Path auto2 Storage Class Cool

Note: A new storage class option called "Default" is introduced for Azure. User having Azure general purpose V1 Storage accounts must use the "Default" storage class option to deploy a CloudFS node. This "Default" storage class is applicable only for Azure Cloud CSP and CMP licenses.

After CloudFS nodes are configured, navigate to Configuration > License Manager > Storage Class, the "Default" storage class option must be selected for both CSP and CMP (if CMP is present) if the user has an Azure V1 Storage Account.

In the context of a general purpose V2 storage account, when the user selects the 'Default' storage class from the CloudFS UI, the blob is uploaded to the access tier that has been set by the user on their Azure storage account.

Google Cloud Platform (GCP) storage class

The GCP storage offers different access tiers for storing the data in a most cost-effective manner based on the business usecase. The access tiers options available in GCP storage class are:

1. Standard storage: Is best for data that is frequently accessed ("hot" data), as well as data that is stored for only brief periods of time.
2. Nearline storage: Offers a cost-effective, durable solution for infrequently accessed data, perfect for monthly analysis, backups, and archival needs.
3. Coldline storage: Delivers ultra-low-cost, durable storage for quarterly-access data, balancing higher access fees with minimal at-rest costs.
4. Archive storage: Offers ultra-low-cost, durable cloud storage with millisecond access, ideal for yearly-access data, backups, and disaster recovery.

For more details on the storage tiering and pricing, refer to Storage classes. CONFIGURE GCP STORAGE CLASS

1. Login to CloudFS master node web UI using administrator credentials or RBAC user having write access to License Manager.
2. Click on Configuration tab.
3. Navigate to License Manager > S3 Storage Class. You will see the following details on the S3 Storage Class and click Confirm: CSP

• Provider Name - Google
• Container Name
• Path

• Storage Class - Default, Standard, Nearline, Coldline and Archive (Select the storage class from the dropdown).

Note: The "Default" storage class option is used to retain the storage class that is already configured at the bucket level in the Google Cloud Console. When this option is selected in CloudFS, no override is applied from the CloudFS UI. Instead, CloudFS continues to use the storage class defined directly in the Google Cloud bucket configuration. This ensures consistency between CloudFS and the native Google Cloud settings, allowing administrators to manage storage policies centrally from the GCP Console.

Refer to the section How to verify storage class set to the buckets for more details.

EDIT THE STORAGE CLASS

1. Login to CloudFS master node web UI using administrator credentials or RBAC user having write access to License Manager.
2. Click on Configuration tab.
3. Navigate to License Manager > Installed License Modules and choose the GCP license.
4. Click Edit, update the required 'Storage Class' and click 'Done'.

HOW TO VERIFY STORAGE CLASS SET TO THE BUCKETS

To verify whether the storage class of a bucket has been successfully set, you can perform the validation using both the gcloud command-line tool and the Google Cloud console.

Using the gcloud CLI, run the following command: gcloud storage buckets describe gs://<CSP/CMP bucket name> ==format="get (storageClass)". This command retrieves the current storage class of the specified bucket. The output should display the storage class value associated or set to the bucket. For example, if you have set the storage class to "NEARLINE", the command's output should return 'NEARLINE'.

You can also verify this using the Google Cloud console. Navigate to Storage > Browser, select the relevant CSP/CMP bucket, and open the Configuration tab. Under Default storage class, ensure that the displayed value matches the configured storage class. This confirms that the bucket's storage class update has taken effect.

Edit License

Warning! This operation may reboot the system, stop all current read/write operations, delete all data stored in the storage and clear all reporting statistics.

PATH

ACCESS KEY

SECRET KEY

Required

BUCKET NAME kshou

Default Standard Nearline CANDLE DONE Coldline Archive

The subordinate node should also reflect the same changes made on the master node. Navigate to storage account of Google Cloud (Home), locate for the object and verify that the appropriate "Access tier" is applied to the objects which are getting uploaded to the cloud.

12.13.6 Antivirus and Malware Scanning

This section describes how to configure McAfee VirusScan Enterprise and Symantec Protection Engine for antivirus and malware scanning.

McAfee VirusScan Enterprise 8.8 with VirusScan Enterprise for Storage

You can configure a node to use McAfee VirusScan Enterprise (VSE) 8.8 for antivirus and malware scanning. When installing the ICAP license on the node, you are prompted for configuration information.

Enter the IP address of the McAfee scanner into the Hostname setting of the ICAP license. No other setting changes are required. If you have multiple scanners and want to load balance between them, enter the IP addresses in the Hostname setting as a comma-separated list.

By default, the ICAP license scans files when a read or write occurs. If you do not want to scan on writes, enter no for Scan Fon Write. After the settings are configured, select the checkbox for the ICAP license and then activate the license at the top of the License Manager page. This will enable virus scanning immediately. If you need to change the settings later, enter new values and click Activate Selected at the top of the License Manager page. It is not necessary to deactivate the license to make configuration changes.

Symantec Protection Engine for Network Attached Storage 8.2.1 and above.

You can configure a node to use Symantec Protection Engine for antivirus and malware scanning. When installing the ICAP license on the node, you are prompted for configuration information.

Enter the IP address of the Symantec scanner into the Hostname setting of the ICAP license and verify that Deny on Error is set to no. If you have multiple scanners and want to load balance between them, enter the IP addresses in the Hostname setting as a comma-separated list.

By default, the ICAP license scans files when a read or write occurs. If you do not want to scan on writes, enter no for Scan on Write. After the settings are configured, select the checkbox for the ICAP license and then activate the license at the top of the License Manager page. This will enable virus scanning immediately. If you need to change the settings later, enter new values and click Activate Selected at the top of the License Manager page. It is not necessary to deactivate the license to make configuration changes.

12.13.7 Managing Configuration Changes

When you change configuration settings, the settings are in a pending state until you save them. The list of pending changes is shown on the right side of the Web UI window.

The category is shown along with the number and type of pending changes. You can review the changes before saving. To manage configuration changes:

• SAVE: Save all pending changes.
• CANCEL CHANGES: Discard all pending changes.

12.13.8 Advance Settings

Regional Store Setup

Without regional store support, CloudFS utilizes same object store bucket for master and subordinate nodes regardless of their geographical regions. In such deployments, nodes may experience network latency and high cloud cost. The regional store support enables individual or group of subordinate nodes to do data upload and download from/to with its overridden dedicated cloud object store bucket.

The CloudFS nodes in regional bucket enabled- setup automatically detects replication failure across the buckets and seamlessly continue the node operation by syncing the data and metadata from the remote object store bucket wherever it is.

This per-node bucket mapping is configured through license settings, allowing nodes to interact with regionally optimized storage for improved performance and reduced latency.

The following diagrams illustrates how active nodes automatically download snapshots from other configured object store buckets when the dedicated bucket becomes inaccessible or replication between buckets is interrupted.

PANZURA

When a user connected to Subordinate-4 attempts to access "qtr_report.xlsx", the system first checks the local bucket (Bucket 3). If the file is not found locally, due to broken replication, it automatically retrieves the file from the data owner's bucket (Bucket 1).

The retrieved file is made available in read-only mode to maintain data consistency and prevent conflicts.

To configure the regional store:

1. Log in to the CloudFS subordinate node web UI using administrator credentials or RBAC user with write access to License Manager.
2. Navigate to Configuration -> License Manager -> Advance Settings.
3. A toggle button is introduced called as "Regional Store Setup". Enable it. Use the same toggle button to disable the regional store bucket.

Note:

a. When you enable the toggle button, the CSP and the CMP licenses which are replicated from the master node can be overridden for that subordinate node. On a subordinate node, either the same master node CSP/CMP license can be edited to chose different regional store properties OR a completely new regional store license can be installed having type different than master node (For example, master has AWS S3 type bucket store and subordinate node needs Azure bucket store). b. Before enabling the regional store toggle option, the buckets that are configured with the master and subordinates must be in-sync with each other.

Edit regional store:

1. Log in to the CloudFS subordinate node web UI using administrator credentials or RBAC user with write access to License Manager.
2. Navigate to Configuration -> License Manager -> Installed License Modules.
3. Select CSP (or CMP) license you want to change the bucket and click Edit.
4. If the buckets are in the same region, change the Bucket Name. If the buckets are in the different regions, change the Cloud Host Name and Bucket Name. Click Done.

Note:

1. If a subordinate node is switching to a new bucket, the data on the existing bucket must be manually copied to the new bucket before editing the regional store configuration.
2. In case of updating the cloud access credentials or expiry of the credentials (access key id and secret key), contact Panzura Support to restart the supporting services.
3. Regional Store allows deployment of multiple regional store buckets without enabling replication between them. However, when replication is not configured, ensure that the CMP is set up before enabling the regional bucket. CMP is supported only when replication is enabled across the buckets.

Configure new license with regional store is enabled

Using the regional store feature, you can configure different buckets in the cloud region. Add the new license of the cloud service provider and inactivate the existing cloud service provider. At a time only single bucket should be active for the subordinate node to upload the data.

1. Navigate to License Manager -> Installed License Modules -> Add.
2. The status on the license is New.
3. Upload the license of the cloud service provider you want to configure. Click Add.
4. Deactivate the existing cloud service provider license.
5. Edit the new license with the appropriate values in the fields and click Done.
6. Navigate to the S3 Storage Class option. Verify all the details are displayed with new license.

Deactivate the new license

1. Navigate to License Manager -> Installed License Modules. Inactivate the license you want to discontinue.
2. Navigate to License Manager -> Advanced Settings and disable the toggle button "Regional Store".
3. Reboot the node. This ensures that all the subordinate nodes are matched with the previous configuration.

Note: After the Regional Store Setup is enabled on the subordinate node, any changes in CSP/CMP license on the master node won't be applied to that subordinate node.

LHA/GHA nodes configuration

When the Regional Store toggle is enabled on a subordinate node with a standby node: In the event of an active node failure, the standby node is expected to inherit all configurations of the active node and assume the active role. This automatic configuration transfer does not include Regional Store settings. To configure Regional Store support on the LHA/GHA node, you need to manually set it up, which also involves adding new buckets through the "Installed Licenses Modules" section.

12.14 Disk Expansion

Use this section to discover new disks that were added to your node (physical or virtual). If you have a physical node, go to the License Manager section and activate the disk license or licenses before you proceed.

In the Disk Expansion section, the table lists all of the discovered and provisioned disks. A status line above the table indicates whether the status of all the disks is $OK$.

To discover and provision disks:

• Discover New. If you have installed an SSD expansion pack for your physical node, or new disks have been added to your VM node deployment, click this button to initiate a discovery. When discovery is complete, the nodes that have been discovered but not provisioned are shown as READY in the State column. Note: If you have a physical node, it will also periodically check for new SSDs.
• Configure New. Initiate the configuration process. Review the drive configuration and make any needed changes. If needed, click Unconfigure New to unconfigure a disk that has never been placed into use. Unconfigure cannot be used with disks that have been provisioned and added to the node.
• Provision. Put the new drives into service. You cannot undo this process, so make sure that the configuration is correct. When provisioning is complete, verify that the disks are now in the ONLINE state and ready for use. Note: The CFS deployment is supported only on Azure SSD v2 with a sector size of 512 bytes.

12.15 Access Control

This section is dedicated for administrators to configure Identity and Access Management (IAM) for CloudFS System Management using RBAC (User Role Based Access Control). Manage integration with external identity providers, set up user roles, and establish authorization rules for mapping roles to Active Directory groups.

Access Control

Identity Provider Prerequisites

12.15.1 Identity Providers Prerequisites

Identity Providers Prerequisites feature is introduced to fulfill the requirement to get metadata details of the node and Assertion Consumer Service (ACS) URLs to configure the Identity Providers with CloudFS. This enables seamless integration with external identity providers, allows the definition of user roles, and supports the creation of authorization rules that map these roles to corresponding Active Directory groups.

You can access the Identity Providers Prerequisites by navigating to Configuration > Access Control.

List of supported Identity Providers:

• Microsoft Entra ID
• OKTA
• Active Directory Federation Services (ADFS)

List of protocols supported along with Identity Providers:

• Security Assertion Markup Language (SAML)
• Open ID Connect (OIDC)

12.15.2 Identity Services

An Identity Service defines the connection to an external identity provider for authentication and authorization. You can configure and perform operations on the Identity Providers added in CloudFS:

Add Identity Provider

1. Login to CloudFS web UI.
2. Navigate to Configuration > Access Control > Identity Services.

To add Identity Service, refer to the Parameters table below for details of each Identity Providers:

Add Identity Service as Entra ID - OIDC

Add Identity Service

Add Identity Service as OKTA - OIDC

Add Identity Service

CANCEL ADD

Add Identity Service as ADFS - SAML

Add Identity Service

Note: To configure another Identity Services, click on ADD.

Parameters:

When configuring an Identity Service in CloudFS, provide the following details.

12.15.3 Configure Identity Providers

The following Identity Providers can be configured with CloudFS for System Management RBAC using:

• Microsoft Entra ID
• Using OpenID Connect (OIDC) protocol
• Okta
• Using Security Assertion Markup Language (SAML) protocol
• Using OpenID Connect (OIDC) protocol
• Active Directory Federation Services (ADFS)
• Using Security Assertion Markup Language (SAML) protocol

Microsoft Entra ID and Open ID Connect (OIDC)

CloudFS is now integrated within Microsoft Entra ID with Open ID Connect (OIDC) protocol for authentication and authorization. This will improve access control, enable Single Sign-on (SSO) capabilities, secure user authentication and manage user roles, and permissions effectively.

Prerequisites required from CloudFS webUI for Microsoft Entra ID application

A sign-in redirect URI should be generated in CloudFS web UI which can be added while registering the application in Entra ID. Perform the following steps to generate a redirect URI:

1. Login to CloudFS master node using the using admin credentials.
2. Navigate to Configuration $>$ Access Control $>$ Identity Provider Prerequisites.
3. Select the "Entra ID - OIDC" from the drop-down. Copy the Sign-in redirect URI using the copy icon and save it for later.

Following parameters are required to be added in CloudFS webUI to configure the Microsoft Entra ID:

• Application ID, also known as Client ID
• Directory ID also known as Tenant ID
• Client Secret Key

Steps to integrate Microsoft Entra ID using OIDC with CloudFS for System Management: This section is divided into sub-parts:

A. Register the application

1. Login to Microsoft Azure portal. Navigate to the Microsoft Entra ID dashboard and register new application by selecting " + Add $>$ App registration".
2. Provide the following details on the Register an application page and click Register:

1. Note the Application (client) ID and Directory (tenant) ID. This IDs are required in CloudFS web UI Add Identity Service.
2. On the same page, click Add a certificate or secret link to create a new client secret token. Navigate to Client Secrets $>+$ New Client Secret.
3. Provide a description and select the appropriate expiry period from Add a client secret dropdown. Note the Client secrets value.

B. Fetch user details for Microsoft Entra ID application:

CloudFS requires email id, family name, token expiry, and group details to authorize allowed resources from CloudFS and add in the group and optional claims. To configure group and optional claims, perform the following steps:

1. Navigate to Token Configuration.
2. Click " + Add group claims".
3. Select 'Groups assigned to the application' option.
4. Customize token properties by type $>$ ID - Select Group ID.
5. Click Add.
6. Click " + Add optional claim".
7. Select Token type $>$ ID.
8. Claim - Select 'email', 'family_name', and 'given_name'.
9. Click Add.

C. Configure API permission to grant admin consent to MSFT

1. Navigate to API permissions $>+$ Add a permission.
2. On the Request API permission:
3. Select Microsoft Graph from 'All API' dropdown.
4. Select group from the 'Select permissions' dropdown.
5. Select the Group.Read.All from Permissions.
6. Click Add permission.
7. Click 'Grant admin consent for MSFT'

D. Assign groups and users to Microsoft Entra ID application

After the application is registered, you may need to assign users or groups to the application. Refer to the following links for more detailed steps. Manage Microsoft Entra groups and group membership Manage users and groups assignment to an application

With all these steps, now there is Relying Party trust between CloudFS node and Microsoft Entra ID with custom rule in-place.

E. Add Identity Service as Microsoft Entra ID - OIDC in CloudFS webUI:

1. Login to CloudFS master node using admin credentials.
2. Navigate to Configuration > Access Control > Identity Provider.
3. Click Add to configure the Identity Service by providing the Application (Client) ID, Directory (Tenant) ID, and Client Secret value obtained in prerequisites steps. Enable the 'Default Identity Provider' toggle if required.

F. Configure role:

1. Navigate to Access Control > Roles Configuration. Click Add to configure roles.
2. Provide Role name, Description and select group from Configuration / Maintenance drop-down and provide full or read-only access to the selected resources.
3. Click Grant and then Add Role. You can edit and delete the role. Refer to for more details. G. Configure Authorization Rules

When creating Authorization Rules, it can be performed by either one of the following users:

• Localhost admin - This user must manually enter the exact group name.
• SSO user (with access control permission) - This user has the option to either search for the group name or enter it manually.

Add Authorization Rules

Select Identity Service MS Entra ID US West Exact Group Name octo Select Roles Filesystem Engineer, System... - CANCEL ADD

Add Authorization Rules

Select Identity Service MS Entra ID US West Use Exact Group Full Name Search Group Name pzs Select Group pzsqa Select Roles System Engineer CANCEL ADD

II. Login using SSO user Access the CloudFS node using the SSO user credentials using FQDN only. After successfully logging in to the master node, the Sign-in redirect URI of the other node(s) in that ring (as mentioned in prerequisites) must be added to the application's list of the redirect URIs.

Okta

The user access to login with advance Single-Sign-On (SSO) capabilities that are integrated with an Identity Provider are simplified using Okta. This enables centralized Identity and Access Management (IAM), enhances security controls, and reduces administrative workload for managing access.

Okta serves as the directory service, eliminating the need for bind user credentials or domain details. Configuration requires only the Okta domain name and an API token, through which CloudFS can fetch users and groups directly.

Prerequisites required to configure Okta:

1. A default access policy with rules.

2.

Add Claim

Name IOTClaim

Include in token type ID Token Always Value type Groups Filter (1) Only include groups that meet the following condition. Matches regex $\bullet$ *

Disable claim $\square$ Disable claim Include in (1) Any scope $\square$ The following scopes:

Add an IDT claim.

Perform the following steps to note the URLs for SAML and OIDC protocols.

1. Login to CloudFS node.
2. Navigate to Configuration $>$ Access Control $>$ Identity Provider Prerequisites .
3. Select OKTA - SAML from the dropdown. Keep a note of the metadata and ACS URLs.
4. Navigate to Configuration $>$ Access Control $>$ Identity Provider Prerequisites.
5. Select OKTA - OIDC from the dropdown. Keep a note of the ACS URL.

Steps to configure CloudFS in OKTA using SAML protocol:

1. Login to OKTA.
2. Navigate to Application $>$ Create App Integration. Select one from the following protocols as per the requirements.
3. Select SAML 2.0 and perform the following steps: a. In Create SAML integration $>$ General Settings, provide the details. Click Next. b. In Configure SAML > SAML settings, provide the following and click Next. Metadata and ACS URLs noted in the above procedure: c. Name ID format d. Application username - Select 'Email' e. Attribute statements - Provide the details from Windows account

• Name - http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
• Value - user.Email
• Group Attribute Statements:
• Name - http://schemas.microsoft.com/ws/2008/06/identity/claims/role

• Value - matches regex f. On the Feedback, select the option as This is an internal app that we have created. Click Finish. You are now navigated to the Applications window. g. Under the Sign on tab, SAML 2.0, you can see the details of the application added. Copy the URL.

Steps to configure CloudFS in OKTA using OIDC protocol:

1. Login to OKTA.
2. Navigate to Application > Create App Integration. Select one from the following protocols as per the requirements.
3. Select OIDC and perform the following steps: a. Navigate to Applications > Applications > Create App Integration. Select OIDC - OpenID Connect and click Next. b. On the New Web App Integration > General Settings, provide the following and click Save:

* App integration name - Provide a name to the application
* Logo (optional)
* Proof of possession
* Grant type - Use by default settings
* Sign-in redirect OKIs - Provide the URL from the CloudFS UI.
* Assignments - Select "Allow everyone in your organization to access".
* Enable immediate access - Select the "Enable immediate access with Federation Broker Mode".

Perform the following steps by logging in to CloudFS webUI:

1. Login to CloudFS node. Navigate to Configuration > Access Control > Roles configuration.
2. Click Add. Provide the following details:
3. Role name - Provide role name.
4. Description - Provide role description.
5. Configure Permissions - Choose any one permission and click Add Role to create the role.
6. Select any one from - Full Access or Read - only Access options.
7. Navigate to Configuration > Access Control > Authorization Rules.
8. Click Add. Provide the following details:
9. Select Identity Service from the dropdown.
10. Search Group Name - Search for the "Domain Users" group.

11. Select Group - Domain Users in dropdown
12. Select Roles - Select the appropriate role
13. Click Add.

Assign to People from OKTA

1. Login to OKTA and navigate to OKTA application.
2. Click on Applications > Applications > Assignments Tab.
3. On Assignments tab, click Assign > Assign to People and assign it to the appropriate OKTA user and group.

Okta configuration during upgrade and downgrade

When upgrading from CloudFS version 8.4.1 to 8.6.1.0 and later, the administrators must configure the Okta integration in the CloudFS webUI by providing the following details: Okta API Token - Generate this from the Okta console under Security > API. Okta Domain Name - The registered domain associated with your Okta organization. These settings enable CloudFS to directly authenticate and retrieve user and group information from Okta, removing the dependency on Active Directory (AD) credentials.

In case of a downgrading to version 8.4.1 or earlier, reconfigure the previous authentication settings by specifying following details to restore the AD-based authentication. * Directory Server details * Bind User credentials * AD Domain Name

Active Directory Federation Services (ADFS) and Security Assertion Markup Language (SAML)

It is important to set up 'Relying Party Trust' in ADFS in order to enable secure, federated authentication for external applications such as CloudFS. This allows ADFS to provide authentication tokens to trusted applications, enabling Single Sign-On (SSO), secure claims-based access control, and seamless integration between identity providers and relying on applications.

When using "ADFS-SAML", the system relies on Active Directory Federation Services (ADFS) for SSO, enabling users to log into CloudFS using their Active Directory credentials.

Note: The CloudFS node must be resolvable from the ADFS server using its Fully Qualified Domain Name (FQDN) rather than its IP address. Perform the following steps to establish Relying Party Trust between the CloudFS node and ADFS.

1. Click on Access Control > Identity Services.
2. Copy the file to the ADFS host.
3. Go to the ADFS Console.
4. Open Add Relying party trust wizard.
5. Select Claims aware, Click Start.

12.15.3 Configure Identity Providers

6. Select Data Source, select Import Data about the relying party from a file and provide the CloudFS SAML metadata file downloaded from the CloudFS web UI.

Add Relying Party Trust Wizard

Select Data Source

7. In next couple of steps through wizard, provide the 'unique' name while specifying the 'Display Name' in ADFS, and further. Select Permit Everyone as a "access control policy" and close the ADFS wizard.

Add Relying Party Trust

• 167/250 - Copyright © Panzura, LLC. 2020 | panzura.com

8. In the ADFS console, select Relying Party Trust and entry for trust that we created should be shown, click on Edit Claim Issuance Policy.

Edit Claim Issuance Policy for Sellsoft Issuance Transform Rules The following transform rules specify the claims that will be sent to the relying party.

Order Rule Name 1 Sellsoft Claim Rule Issued Claims <See claim rule> Add Rule... Edit Rule... Remove Rule... OK Cancel Apply

1. Click 'Add Rule'.

Add Transform Claim Rule Wizard

Select Rule Template

• Previous Next > Cancel

10. In the 'Add Transform Claim Rule Wizard', select Send Claims Using a Custom Rule as a "Claim rule template". Click Next.
11. Provide the 'unique' Claim rule name, the following required custom rule and click Finish.

Note: Custom Rule

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
    Issuer == "AD AUTHORITY";
    issue:store = "Active Directory",
    types = {"http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
        "http://schemas.xmlsoap.org/claims/CommonName",
        "http://schemas.microsoft.com/ws/2008/06/identity/claims/role",
        "http://schemas.microsoft.com/2012/12/certificatecontext/extension/subjectkeyidentifier"},
    query = "userPrincipalName, sAMAccountName, displayName, tokenGroups, employeeID; {0}",
    param = c.Value);}

Edit Identity Service

1. Click on Access Control > Identity Services.

   

2. Select the Identity Service that needs to be modified, click 'EDIT'.

3. Update the required parameters, click 'UPDATE'.

Delete Identity Service

1. Click on Access Control > Roles Configuration.

2. Select the 'Identity Service' to be deleted and click 'DELETE' to confirm the deletion.

   

12.15.4 Role Configuration

Role-Based Access Control (RBAC) in CloudFS enables secure authentication and authorization capabilities via the CloudFS web interface, ensuring granular access control. RBAC ensures that access to administrative functionalities is strictly controlled based on predefined user roles. This framework guarantees that only authorized personnel can access, manage, and configure various aspects of CloudFS, thereby significantly reducing security risks and ensuring adherence to regulatory standards.

Key Features of RBAC:

• Authentication: Users must be authenticated before accessing CloudFS administration via the Web UI, ensuring that only verified individuals can gain access
• Single Sign-On: By integrating with customer's Active Directory deployment for Single Sign-on (SSO), access to Cloud WebUI is simplified and secure.
• Authorization: Access permissions are managed based on assigned roles, aligning user capabilities with their specific responsibilities.
• Role Definitions: Customizable roles, such as administrators, operators, and viewers, clearly define the level of access and operational capabilities assigned to each user.
• Granular Control: RBAC offers precise control over which users can execute specific administrative tasks and view certain configurations, limiting access to only what is necessary.
• Enhanced Security: By restricting administrative access to authorized users, RBAC fortifies the overall security of CloudFS deployments, minimizing the potential for unauthorized actions.

Benefits of Implementing RBAC in CloudFS:

• Improved Security: Only authorized personnel can access sensitive administrative functions, significantly reducing the risk of unauthorized access.
• Regulatory Compliance: By enforcing strict access controls, RBAC helps ensure compliance with security and privacy regulations.
• Simplified Management: Role-based assignments streamline managing user access and permissions, making it easier for administrators to maintain secure environments.

This feature enhances overall security, compliance, and manageability of CloudFS making it a valuable addition to any deployment. Microsoft Entra Domain Services (Microsoft Entra DS) offers a streamlined, managed domain solution tightly integrated with Microsoft Entra ID. This enables organizations to manage CloudFS nodes efficiently without the need to deploy traditional Active Directory Domain Controllers. Even when Microsoft Domain Services are not configured, CloudFS relies on Active Directory for authentication. Additionally, CloudFS supports Single Sign-On through Microsoft Entra ID, and if your domain resides within Microsoft Entra ID, it is fully compatible with CloudFS. For more details, refer to the article.

Available Operations for Role Configuration:

Administrators can define access for the following operations:

Configurations

• Access Control
• Active Directory
• CloudFS Settings
• Disk Expansion
• Encryption Settings
• Geofencing Policy
• High Availability
• License Manager
• Monitoring
• NFS Settings
• Network Settings
• Quota Management
• SMB/NFS Mixed Mode
• SMB/S3 Settings
• Smart Cache Settings
• Snapshot Settings
• System Settings

Maintenance

• Diagnostic Tools
• System Operations
• CloudFS Operations
• SMB/NFS Operations
• System Reset and Cleanup
• Master Node Operations
• Subordinate Node Operations
• ICAP Operations
• High Availability (HA)

Note: Listing of operations depends on license activation and on the nature of the CloudFS node. For example, if the node is LHA, then "High Availability (HA)" will be listed.

Note: While configuring the "Role", the "permissions" for the operations from the "Maintenance" category will always be "Full Access," while operations from the "Configuration" category will have either "Full Access" or "Read-Only Access."

Add Role

1. Click on Access Control Roles Configuration (If another "Role" needs to be configured then Click on "ADD").

Add Role

2. Provide the name and description for the "Role". 3. Choose one or more Configuration/Maintenance Operations from the list.

For each selected operation, specify the level of access: 4. Read-Only Access: Users with this permission should view the settings but cannot modify them. 5. Full Access: Users with this permission should both view and modify the settings. 6. Click on "ADD ROLE"

Example of Role Configuration

Consider the following example: The 'System Config Role' has full access for 'System Setting' and 'System Operations'.

1. Role Name: "System Config Role"
2. Assigned Operations:
3. Configuration $->$ System Settings: Full Access
4. Maintenance $->$ System Operation: Full Access

Edit Role

1. Click on Access Control > Roles Configuration.
2. Select the Role that needs to be modified. Click 'EDIT'.
3. Administrator can add or delete permissions for the selected role.
4. To add permission, click the dropdown (Configurations/Maintenance) and choose the operations you need.
5. To delete a permission, click the relevant 'Actions' icon.
6. Click on 'UPDATE ROLE' once done.

NOTE: Role must have at least one permission.

Delete Role

1. Click on Access Control -> Roles Configuration.
2. Select the role to be deleted and click 'DELETE' to confirm the deletion.

12.15.5 Authorization Rules

Authorization Rules allow administrators to control which roles are assigned to specific Active Directory (AD) groups within CloudFS. By mapping roles to AD groups, the system ensures that users inherit the appropriate permissions defined by those roles. These roles should include different levels of access, such as ReadOnly or Full Access to various CloudFS operations. This is a crucial step in managing user access via SAML SSO, ensuring that AD group members have the correct permissions when accessing the system.

Only authorized Active Directory users should add or edit these authorization rules, providing an extra layer of security. In case the currently logged-in user is not the Bind DN User responsible for managing the directory server, the interface will prompt for SSO credentials of the Bind User.

Add Authorization Rules

1. Click on Access Control > Authorization Rules Note:(To configure another Authorization Rule, click Add.
2. Select Identity Service's alias name from the list.
3. Enter minimum three characters of the AD group name you wish to assign roles.
4. Click "Search" to populate the list of matching AD groups.
5. The 'Select group' field will get populated with the list of AD groups, Select the desired AD group from the list.
6. In the Select Roles dropdown, choose one or more roles to be assigned to the selected group.
7. Once all the fields are filled, click "ADD" to save the rule.

Example of Authorization Rules Configuration

Consider the following example:

1. Select Identity Service: "Sellsoft AD".
2. Search Group Name: sys, click on SEARCH.
3. Select Group name: "System Config Grp".
4. Select Roles: "System Config Role".
5. Click ADD.

This will allow members of the 'System Config Grp' AD group to access CloudFS with the permissions defined under the 'System Config Role'.

Edit Rule

1. Click on Access Control -> Authorization Rules.

Authorization Rules Authorization Rules

Group ☐ New ☑ New ☐ New ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ Group ☐ Identity Service ☐ ☐ Role(s) Sellsoft AD Network Config RA ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ Group ☐ Identity Service ☐ ☐ Role(s) Sellsoft AD Network Config RA ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

2. Select the Domain from the dropdown, click 'Log In'
3. Enter valid AD user details.
4. To check the logged-in user, click on 'information' icon, and scroll down to verify logged-in user and role.
5. Here the 'user' has been provided 'full access' to 'System Settings' in 'Configuration', only that operation is available.
6. Here the 'user' has been provided 'full access' to 'System Operations' in 'Maintenance', that operation is available.

Note: If 'localhost' is selected, provide CloudFS username and password.

12.16 Geofencing Policy

Global organizations must comply with region-specific regulations like GDPR compliance. This often demands strict data residency enforcement and controlled access to sensitive information based on geographic location.

Scenarios where organizations may require geofence:

• One of the defense departments needs to enforce data sovereignty by blocking classified documents from being downloaded on non-US locations.
• A global design firm has offices across different continents. Due to regulatory requirements, they need to restrict their early-stage prototype files from appearing in specific geographic location
• A Pharma company shares their clinical trial data with their labs across regions, but it needs to block these files from appearing in the outsourced labs.

Geofencing Policy allows CloudFS administrators to define fine-grained rules that restrict file or folder access at individual nodes within a CloudFS deployment from a live file system, regardless of the Active Directory permissions and Point-In-Time (PIT) snapshots.

Once a geofencing rule is applied to a specific node, any user accessing the SMB share through that node will be restricted from reading or writing any content protected by the geofencing rule.

The Geofencing Policy rules are managed centrally from the feature in the CloudFS master node WebUI and automatically propagated to all subordinate nodes without requiring system restarts, ensuring real-time enforcement across CloudFS environments.

Note:

• The Geofencing Policy feature supports SMB and S3 protocols, and does not support NFS protocol.
• Geofencing policy rules prevent unauthorized data access initiated by user requests. Administrative operations such as prewarming may allow data to be placed/ cached on the node restricted by geofencing policies. To ensure consistent enforcement, do not prewarm data mentioned in the Geofencing policy rules on the restricted nodes. Even if you prewarm such data on a restricted node, geofencing policy rules will prevent access to that data from restricted node.

The section of a share to be restricted can be defined using geofencing rule. Each Geofence rule is defined for a specific SMB share with the intent to restrict access to a given path pattern from one or more specified CloudFS nodes.

• Nodes that are not specified in the rule can access the share.
• A Geofence rule is not applicable to the owner node of the share, i.e., the node on which this share exists.
• The path pattern is defined using PCRE (Perl-Compatible Regular Expressions), allowing flexible and precise matching.
• By default, the Caseless pattern matching flag is ON. If you want to perform a case-sensitive match, then turn off this flag.
• More Info: You can refer to https://regex101.com/ website and PCRE regex flavor to verify your path patterns against expected restrictions.
• Examples of the path pattern used for restriction: a. Scenario: Restrict access to all content within directory finance of share share $Y$.

Description: Need to restrict access to all content within directory finance of share shareY (Full Path: /cloudfs/nodeX/shareY/finance) from CloudFS node nodeA.

Details:

• Restrict access to: All content within directory finance
• Share: share $Y$
• Patterns:
• Full Path: /cloudfs/nodeX/shareY/finance
• Relative path: finance/

• Restrict access from: nodeA

Result: With this rule enabled, if a user accesses any files within the finance directory mounted through nodeA, e.g. /nodeA/shareY/finance/report.pdf, then its access will be denied. b. Scenario: Restrict access to only pdf extension files within a directory

Description: Need to restrict access to only pdf extension files within a directory finance of share shareY (Full Path: /cloudfs/nodeX/shareY/finance) from CloudFS node nodeA. Details:

• Restrict access to: All PDF files within directory finance
• Share: share $Y$
• Patterns:
• Full Path: /cloudfs/nodeX/shareY/finance
• Relative path: finance/:+.pdf
• Restrict access from: nodeA

Result: With this rule enabled, users will be restricted from accessing all the PDF files within the finance directory. The rest of the files will be accessible. c. More examples:

To configure a Rule over the node(s), ensure that the SMB share for which the rule is applied exists.

Warning:

• Creation or update of Geofencing Rules will restart the SMB server on all CloudFS nodes, which may disrupt active SMB sessions. To minimize the impact, it is recommended to perform this operation during off-hours.
• In SMB Shares, the S3 Interface Access and Manage Share Access features can restrict user access. If access to shared data is limited by either of these features, users will also be restricted from accessing the data via both S3 and SMB protocols.

12.16.1 Add Geofencing Rule

1. Login to CloudFS master node web UI using administrator credentials or RBAC user having required access to Geofencing Policy.
2. Click Configuration > Geofencing Policy > Geofencing Rules > Add.
3. Select the Share on which the restrictions are to be applied. Once selected, the Base Path for the share is displayed.
4. Add the file or folder path or the Relative Path Pattern (Pearl Compatible RE Regex). You can also construct and use the path using https://regex101.com/ site.
5. Disable the Case-sensitive Pattern Matching toggle if the pattern matching should be case-sensitive.
6. In Restrict access on Node(s), select the nodes from which the access is to be restricted.
7. Add a unique Description for this Geofencing rule.

8. Click Add. The Rule is enabled by default. It can be disabled from Geofencing Rules section.

Note: In a CloudFS deployment, maximum 64 geofence rules can be added, irrespective of their status (enabled / disabled). To add more, delete the disabled rules and replace it with new ones.

Add Geofencing Rule

Define a Geofencing Rule to prevent access to specific files or folders on selected nodes. Enter a path pattern (PCRE regular expression) to define which paths should be restricted.

Warning:This will restart the SMB server on all CloudFS nodes, which may disrupt active SMB sessions. To minimize the impact, it is recommended to perform this operation during off-hours. Do you wish to proceed?

Share richa-share2

Base Path /cloudfs/sub-NEipBv-0/hello/ Relative Path Pattern (PCRE Regex) .exe Caseless Pattern Matching Full Path Pattern /cloudfs/sub-NEipBv-0/hello/.exe

Restrict Access on Node(s) master-KRtWc4

Description Exclude access to all executables

12.16.2 Edit a Rule

Select the rule that you would like to Edit and update the the details as required.

12.16.3 Test a Geofencing Rule

The TEST option enable administrators to validate the rules REGEX against certain file/folder which are intended to be fenced.

1. Login to CloudFS master node web UI using administrator credentials or RBAC user having required access to Geofencing Policy.
2. Click Geofencing Rule $>$ Test.
3. Add the Full Path or Folder Path.
4. Select the node for which the path is to be restricted in Test for Node.
5. Click Test.
6. "Found Matching Geofencing Rules" indicates the specified file or path is geofenced from the selected test node, and matching rule(s) are displayed.
7. "No matching Geofencing rule(s) found" indicates that there is no Geofence rule for the specified file or path from the selected test node.

12.16.4 Delete a Rule

1. Login to CloudFS master node web UI using administrator credentials or RBAC user having required access to Geofencing Policy.
2. From the list of Geofence rules, select the rule(s) you want to delete and then click Delete. Click Confirm to finalize the selection and proceed with deletion.

12.16.5 Example of how a Geofence Rule works

Geofencing Rules are defined in Configuration > Geofencing Policy.

Edit Geofencing Rule

Enter a path pattern (PCRE regular expression) to define which paths should be restricted. 1 A Warning:This will restart the SMB server on all CloudFS nodes, which may disrupt active SMB sessions. To minimize the impact, it is recommended to perform this operation during off-hours. Do you wish to proceed?

Share text Base Path /cloudfs/vd-qa-86-gf-m/ Relative Path Pattern (PCRE Regpo) $\rightarrow$ txt Caseless Pattern Matching Full Path Pattern /cloudfs/vd-qa-86-gf-m/.+txt

Restrict Access on Node(s) vd-qa-86-gf-s1, vd-qa-86-gf... Description Block all text files

In Panzura Data Services > Audit, the access denials triggered by geofencing policies are recorded in the PDS Audit report with a status of Failure in the Status column.

12.17 Quota Management

Organizations using distributed file systems like CloudFS often face challenges with uncontrolled file-system consumption by certain users or teams, which can lead to unexpected capacity over usage impacting cost and performance. For example, Big universities may want to limit file system quota for their students.

Quota Management feature empowers organizations to curb the file-system usage by certain user(s) and/or group(s), optimize system usage without overprovisioning, and ensure that critical business units always have the space to operate. This feature helps minimize the need for constant manual oversight while enabling informed decision-making through visibility and alerts. The allocated quota is applied at the user-level or group-level - whichever is less will be displayed, along with current usage. The CloudFS administrators are alerted about quota thresholds when the usage exceeds $80\%$ (not configurable) of the allocated quota.

The Quota Management feature delivers:

• Centralized Control: Administrators can enforce file system quota for intended users and groups from a central point, providing fine-grained control aligned with organizational structures.
• Fair Usage Enforcement: Prevents file system exhaustion caused by disproportionate consumption.
• Capacity Planning: Supports efficient capacity planning based on the number of users & their file system requirements.
• Proactive Monitoring: Admins receive timely alerts as users approach quota limits, allowing proactive management.
• User Self-Visibility: Users get clear visibility into max quota available for their account.
• Audit and Compliance Support: Detailed reporting allows organizations to meet governance and reporting obligations.
• Prompt Access Restriction: Provision to revoke the data access to any user or group without requiring the domain controller (AD) side changes.

12.17.1 Quota Policy

A Quota Policy is configured using CloudFS master node web UI and is enforced across all nodes, regardless of the node to which a user connects. Once a user or group exceeds their allocated quota, all subsequent write operations are blocked, ensuring centralized control and effectively limiting file system usage across the global file system.

• Quota Policies allow administrators to add, modify, or remove quota, helping manage and control the capacity assigned to users or groups. When a quota is fully utilized, further 'write' operations across the file system are blocked.
• Reports allow administrators to download a consolidated view of current usage and allocated quota for users or groups in CSV format and display:
• Total Capacity - The total Managed Capacity available.
• Used Capacity - The amount of capacity currently used across the system.

• Allocated Quota - The capacity allocated to the AD user/group.

If the quota is set for group as well as the user belonging to that group, then quota that is consumed first will be effective. If a user belongs to multiple groups, usage is always accounted to their primary AD group.

To access a Quota Policy:

1. Login to CloudFS master node web UI using administrator credentials or RBAC user having required access to Quota management.
2. Navigate to Configuration $>$ Quota Management.

Add Quota to user/group

1. Click Quota Policies > Add and select Apply Quota to User/Group.
2. Search User or Group name for which quota is to be set.
3. Note: If User/Group is not present in AD, a message is displayed "No result found. Enter a valid AD user or group name and try again." If too many matching Users/Groups found, a message is displayed as "Multiple entries found. Refine the input to obtain a precise result."
4. Select intended User/Group displays a list of users and groups.
5. Provide the quota value in the Allocate Quota in GB and click Add.

Note: Adding two users with the same AD username is not supported.

To set bulk quota policy to user/group

1. Select the Set bulk quota to Users/Groups.
2. To download the CSV template, click Download from the NOTE: Download the CSV template, pre-filled with sample data for reference.
3. Populate the CSV file with the following details and click Import.

4. Select the appropriate CSV file and click Open.

Note: To apply the quota policy, ensure the CSV file is in the correct format. If not, the system will return an error: "Invalid Bulk Quota Policy create request."

Important points for CSV import:

• Keep the column headings intact and add the records in CSV file.
• Avoid adding blank cells in the CSV file.
• Column A must contain valid User/Group ID; otherwise, the import will fail with "User/Group not found".
• If the CSV includes invalid entries, only valid records will be processed, along with their applied quota policies.
• The administrators will receive an error: "The CSV import failed", with detailed information and the option to download the error log containing unimported entries.

Edit Quota Policies for user/group

1. Click Quota Policies > Users/Groups or use Search User/Group Name field.
2. Select a specific User/Group and click Edit. Provide the details mentioned in the table below and click Update.

Delete Quota Policies for User(s)/Group(s)

1. Click Quota Policies > Select Users/Groups or use Search User/Group Name.
2. Select specific User(s)/Group(s) and click Delete.
3. A confirmation message is displayed. Click Confirm to delete.

Bulk delete Quota for all Users/Groups

1. Click Quota Policies.
2. Select checkbox of the first column. This selects all the Users/Groups on that page.
3. Click Delete. A confirmation message is displayed.

Important points to note:

1. When adding or editing the quota policy, if the allocated quota to a specific User/Group is below the current used capacity, that User/Group's members will not be able to write further across the file system.
2. If the Allocated Quota exceeds the Managed Capacity, you will receive a warning: "The Allocated Quota has exceeded the Managed Capacity. Consider increasing it for future usage. Contact Panzura Support for assistance.
3. Ensure snapshot synchronization across all nodes to enforce allocated quotas and prevent resource overutilization.
4. Contact Panzura Support either by logging in to portal or by sending an email to [email protected] to when you need to update the Quota policy when the CloudFS master node is down.

12.17.2 Report

Reports provide a consolidated view for tracking managed capacity usage and allocated quotas by user or groups.

Quota Management

Quota Policies

Reports

Reports

A consolidated view for tracking capacity usage and allocated quotas per user and / or groups.

Select Report Type

Users Groups Both Users and Groups

The Quota Policies report is exported in CSV format.

13. Maintenance

13.1 Diagnostic Tools

The Panzura node provides diagnostic tools for troubleshooting. To use the node's troubleshooting tools, navigate to the following page: Maintenance > Diagnostics.

13.1.1 Packet captures

Capture packets on the Ethernet ports. Select to capture all packets or restrict the capture to TCP or UDP packets. The captured packets are saved into a file that can be downloaded and sent to Technical Support.

13.1.2 Run Diagnostic tools

Execute network, node-specific, and cloud diagnostic commands. In the Command Type, select a command. Click Run to see a description of parameters for the command and add applicable parameters. If there are no required parameters, clicking Run executes the command. The results are displayed on the screen.

Diagnostic Tool Commands

The following table lists the diagnostic tool commands.