Integrations

How another system reaches data that is stored in MooseFS.

MooseFS speaks its own protocol. The software that speaks this protocol is the client. Every other system reaches the data in one of two ways. In the first, a machine mounts the file system and re-serves the mount in a protocol that its own clients already speak. Such a machine is a gateway. In the second, a program links the MooseFS library and becomes a client itself. Each page below describes one of those two ways for one system.

Kubernetes covers a cluster of pods: which parts of a MooseFS instance a node must be allowed to reach, and how a pod mounts its claim. MooseFS CSI driver, the recommended way, lets the driver make the mounts. Node mount and hostPath, the simpler way, gives pods a mount made on the node. Virtualization covers hypervisors, where a virtual machine's disk is a file on a mount. That page also describes what the file inherits from the cluster it is stored in. Proxmox and XCP-ng cover the same questions for each product.

Gateways serve the file protocols that MooseFS does not implement. SMB and CIFS covers a Samba gateway: identity, supplementary groups, and locks that cross between the protocols. NFS covers re-exporting a mount to NFS clients. The Master Server treats the gateway as one client. Access control ends at the gateway. FTP covers an FTP server that is given a path inside a mount. Each session works under the identity that the server logged the session in as.

The mfsio API is the second way: a C library that makes your own program a client, without a mount point and without FUSE.

Deployment describes how to install the client itself. Access control covers what an export lets a client do.