I have been reading through the QlikView 11 SR2 release notes and read that QlikTech states that network storage devices other than "Microsoft Windows" based shares are not supported (release note details copied below). I would like to know if anyone has performed any research into incompatabilities between QlikView Server and various Network Storage types. Our Network Storage devices are configured with Microsft Windows based folders & directories. We can manage the security of these directories from Microsoft windows computers, however, the Network Storage Devices and utility manager device not a Microsoft product.
I am posting about this because my deployment of QVS 11 SR1 has numerous reload tasks where which call QVWs, which interact with files and QVDs on an high quality high speed Network Storage device. We have encountered issues with some of our reload tasks based and have troubleshot for some time. The issues seem to point to the QlikView server not releasing the locks on some files before the next step in processing and then the reload task fails.
2.3 QlikView Server, QlikView Publisher and Management Console
· Network Storage Devices other than Microsoft Windows based shares are known to cause system instability and are not currently supported.
This has always been a limitation with QV and the response has always been "don't do it". My limited understanding is that NAS implementations are not always fully compatible with the fairly sophisticated IO that QV server performs.
As Rob said, this problem has been around for quite some time (I first encountered it back on 10 SR1). As I understand it, Qlikview utilises a feature called partial file locking which only appears to be implemented on Microsoft Windows based shares (and is generally not implemented on unix based storage).
The issue manifested itself for us with the entire QVS hanging every couple of hours (10 SR1, SR3). As soon as we moved the mounted QVS folders off unix based NAS shares, the problem went away. Our temporary work around was to mount the Unix based network storage as a LUN in the server, and then expose that as a Windows based share in order to gain the partial file locking capability required by the QVS. In addition to the performance hit, the obvious downside of this is that we introduce a single point of failure (the windows server hosting the share), and that manual intervention is required for failover scenarios (as we need to remount the storage in another Windows based server if we lose the server hosting the share for some reason).