Considerations regarding Network File System (NFS), or another remote filesystem / NAS technology

Owned by Carlos Osorio
Nov 12, 2020
3 min read


SUMMARY

May 30, 2016

The Snare Server has been designed with local physical disk storage in mind, using a single partition that houses critical data paths. These design considerations can result in significant performance impacts if care is not taken when venturing outside the Snare Server recommended hardware configuration, and implementing custom storage strategies, particularly when NAS/NFS is introduced.

In particular, in order of criticality:

  • It is recommended that the /data directory, and all subdirectories be located on the same partition.

    The Snare Server has been designed to assume that all paths are located on physical media, and have an equal availability profile. If one or more directories have been moved to a remote SAN/NFS server, network interruptions or a problem in the remote file server, will potentially result in event loss, and/or an unresponsive user interface, that may require a server reboot, or service restart.

  • It is recommended that the /data/SnareArchive directory be located on local storage.

    The SnareArchive directory holds the Snare Server's data archive; and the Snare Server utilises this archive as a database storage sink. The software contained within the /data/SnareUI and /data/Snare directories provides functionality analogous to a database query engine. Separating out the database storage source files, from the actual query engine itself, is generally sub-optimal from a resource management perspective. On an operational server, the SnareArchive directory will represent the highest disk-utilisation on the system; as such, it is an obvious target to attach to a remote SAN system. Consequences of such a migration may include slower objective regeneration. In general, collection issues are less likely; the data will pool within the SnareTransition directory until the SnareArchive mount is available.

  • It is highly recommended that the /data/SnareArchive and /data/SnareTransition directories should be located on the same partition.

    The Snare Server migrates files from SnareTransition to SnareArchive on a regular basis. When these two directories are on the same filesystem partition, the migration is extremely quick - the underlying operating system does not have to actually transfer files from one point to the other - it merely updates the file 'inode', which is an extremely quick process, with only a few bytes of data migrated.

    When the SnareArchive and SnareTransition directories are on separate partitions, the files that are migrated from one to the other, must be physically transferred across. In situations where one of those directories is network mounted, the file will be copied in its entirety across the network.

    In situations where both directories are network mounted, but on separate partitions, the network transfer is likely to be twice as costly. Since the software governing migration of files between SnareTransition and SnareArchive operates on the assumption that both paths are on the same partition, it may not allocate adequate CPU resources to the task, if the paths are on separate partitions.

  • It is highly recommended that the /data/SnareTransition directory be either located on local storage, or on storage systems that have a extremely high uptime/availability.

    The SnareTransition directory holds the most recently collected data from the Snare Server collection subsystem. An interruption in directory availability for this path will stop, and potentially terminate, Snare Server collection.

  • It is highly recommended that the /data/SnareUI, /data/SnareApp and /data/Snare (including the /data/Snare/MetaData directory) be located on local disk, with other local operating-system-critical paths such as /etc, /var, /usr and so on.

    /data/SnareUI, /data/SnareApp and /data/Snare contain the core Snare Server collection subsystem, and user interface. An availability interruption for these directories will result in an unresponsive user interface, and potentially a loss of collection.

In general terms, when attempting to use remote storage systems with the Snare Server, it is recommended that:

  • NFS is preferred over SMB/Windows. SMB-style configurations do not have the correct permission structure to support Snare Server data, operationally.

  • Hard mounts should be used, rather than soft mounts.