Knowledge

[Sonja_Bauernfeind]

Qlik Sense Enterprise on Windows is reliant on the availability and performance of its server cluster share, where the Qlik Sense apps are stored. 

In some instances, the file storage maybe not be compatible with the requirements of Qlik Sense, and this can lead to app corruption.

An example of this may be a Distributed File System (DFS) managed share with replication enabled, which can have side effects such as app corruption, apps being removed from disk, and/or not correctly replicated.

Environment:

Qlik Sense Enterprise on Windows, all versions

In a Qlik Sense Enterprise on Windows site, a file share is used to store the binary app data including the data models and dashboard sheets. It can be located on one of the nodes in the Sense site or located on a dedicated file server for better resilience and performance. 

Note: Each Qlik Sense Enterprise on Windows site require its own file share with its own set of binaries, archives, extensions, etc. If two mirrored environments are configured to use the same files in only one share, besides potentially experiencing file locking issues, the Qlik Sense database will not have the correct references (metadata) pertaining to the information stored in the share. So you will have two Qlik Sense environments updating files on the shares and which are not aware of updates performed by the other environment(s). Performing such action is highly unsupported and will cause malfunction.

See Qlik Sense for Administrators: Persistence for more details on requirements for a file share. 
In the case of DFS managed shares, the replication feature on file level can lead to inconsistency with the Qlik Sense apps stored on disk. 

SAN vs. NAS:

Provided that the requirements detailed in this document are met, Qlik Sense will not know the difference between one and the other, but choosing the wrong storage solution can result in bad performance and instability that can be very difficult to troubleshoot.

When your storage is on-premise, Qlik recommends relying on enterprise SAN solutions that can be managed and configured according to your needs. A NAS is better suited for serving files to client machines, while a SAN can be relied upon by multiple servers to give adequate throughput and latency to large blocks of storage. These are typically set up with a fiber channel backbone that can sustain the demand of a large and busy Qlik Sense environment. 

For Virtual Private Cloud (VPC) deployments, be aware of multiple instance types and what type of workloads they are suitable for. A Windows-based File Server will run better in a Storage-Optimised virtual machine than a general purpose instance. Consider using block storage services instead of Windows-based, to take advantage of scaling and resilience offered by those providers. 

Performance: For any network storage resource, the network backbone throughput and latency will directly influence performance of all file-based operations performed by the Qlik Sense platform on the configured file shares. Examples: first-time loading of apps from file share into Engine memory; saving and refreshing of app changes; log archiving, etc. 

For Windows-hosted file shares, the sizing of the File Server machine will directly influence performance of those file shares. Using Administrative Shares instead of UNC paths can severely impact performance, upwards of 50% and causing other issues, such as File Locking.

BAD path example: \\FILESERVER\C$\QlikSenseServiceCluster

GOOD path examples: \\FILESERVER\QlikSenseServiceCluster or \\FILESERVER\QlikDataFiles 

It is recommended to remove / disable Administrative shares to prevent unauthorised access to resource and potentially avoid configuration issues between these shares and Qlik Client Managed products. 

Qlik recommends a maximum latency of 4ms between Qlik Sense servers and any file shares. 10Gbit networking is recommended, considering many parallel file read/write operations can be requested from multiple file share clients (Qlik Sense servers).

Note: Qlik cannot verify support for all storage vendors and Qlik recommends that customers test their preferred infrastructure. In the event of an issue arising that is attributed to storage, Qlik Support may request that customers attempt to replicate the issue on a Windows hosted file share.

Deployment Examples:

Conventional Windows File Share (on-premise)

A windows host is used to serve a file share with storage from local disks (NAS) or SAN.

 

Resilience: 

• Use virtualization (e.g. VMware) for the file share OS and benefit from features in the platform to keep the node up or return to use quickly (RTO of 4 hours is simple here)
• If available, using Windows clustering to provide HA for a file share. (requires AD and suitable SAN)
• Otherwise, backup and restore

Tested by Qlik.

Conventional Windows file share but hosted in AWS

As above but using Amazon EBS volumes mounted to Windows

Resilience: 

• Use virtualization (VMware) for the file share OS ie benefit from features in the platform to keep the node up or return to use quickly (RTO of 4 hours is simple here)
• If available, using windows clustering to provide HA for a file share. (requires AD and suitable SAN)
• Otherwise, backup and restore
• Amazon EBS volumes feature snapshot capabilities to aid restore process and the failover process can be automated to have a rapid recovery. EBS volumes can be mounted to new instances quickly

Tested by Qlik.

SMB file share served by a Physical NAS

A physical NAS device server an SMB share, such as:

• NetApp ONTAP 8.2
• Dell Fluid FS
• FreeNAS

Resilience: 

• High availability handled by the individual hardware vendor 

Protocol support: 

• SMB 3.0 required, older versions have known security issues
• TLS cipher match between client and server required
• Opportunistic Locking (op_lock) enabled on SMB server