SwarmFS can coexist with other applications running on the same Linux server, although SwarmFS expects to have sole ownership of its assigned ports and resources. SwarmFS can be deployed onto the same Linux server as the Content Gateway, or it can run on its own dedicated operating system instance. Note the following for your planning:

• Stateless: SwarmFS is stateless, so each process stores no run-time configuration outside of volatile RAM locally, with the exception of a basic configuration file read on startup (see https://perifery.atlassian.net/wiki/spaces/public/pages/2443810580). Should a process fail or restart, any incomplete operations that it was processing are lost, and it restarts clean and stateless.

• Multiple Active: There is no limit to the number of SwarmFS servers that can be online at any time: multiple SwarmFS processes can be active running on different servers simultaneously. SwarmFS running on different servers can be configured identically and present the same object view as other active running SwarmFS. SwarmFS servers can be added and removed independently of the others, and any single SwarmFS server going offline has no effect on other running instances.

• Performance: The job of an NFS server is to keep data and metadata well stored and to move it efficiently; the job of an NFS client is to translate and adapt the NFS protocol to the local environment efficiently, which is more challenging. Client performance is complex, driven by the performance of servers and drives, as well as the efficiency of networking, caching, and data structures. Many areas affect the throughput achievable, from writing data using an NFS client through the ingest in Swarm Storage to the ability to be read by a Swarm client: 
  
  

Planning the SwarmFS Environment