A.0 Considering Alternate Deployment Types

Although Large, Expandable deployments are the best practice recommendation for all but the smallest organizations, other deployment types are supported and might work well in situations that require neither service fault tolerance nor expansion capabilities.

Figure A-1 Filr’s Three Deployment Types

The Difference Is Shared Storage

Expandable deployments involve shared storage; small and non-expandable deployments do not.

No Shared Storage	Shared Storage
One Filr Appliance No fault tolerance—Single Point of Failure Not expandable beyond a single Filr appliance	Multiple Filr Appliances Fault-tolerant Filr services Expandable by adding Filr appliances as needs increase

Why Large, Non-expandable Deployments Are Not a Best Practice

Organizations are often attracted to this deployment type because it looks much simpler on the surface. In all but a few instances, however, they come to regret the decision for the following reasons:

No Fault Tolerance: If the Filr appliance goes down for any reason, Filr services cease.
No Expansion Capabilities: If additional Filr appliance are needed to handle the service load or to offload Net Folder synchronization and content-search indexing, organizations must start over with an expandable deployment.
No Migration: There is no migration path from a small or large, non-expandable deployment to a large, expandable deployment.
Not Best Choice for Proof-of-Concept: Due to network latency and other issues, for proof-of-concept installations, and other test situations, small deployments are much simpler to deploy and actually perform better than large, non-expandable deployments.
Requires the Same VM Resources as Expandable: Except for a network-based NFS or CIFS shared volume for the /vashare mount point, large, non-expandable deployments require the same VM Host resources as single-Filr-appliance, large-expandable deployments.
Single-Appliance, Large, Expandable Deployments: If you want to start small, you can create a single-Filr-appliance deployment with one or two Filrsearch appliances, an SQL database connection, and a shared NFS or CIFS disk (for /vashare).

Nevertheless, large, non-expandable deployments are reliable and supported (see Non-Expandable Deployment—Creating in the Filr 4.1: Installation, Deployment, and Upgrade Guide).

More Deployment-Type Details

As illustrated in Figure A-1, Filr can be deployed in three different ways.

Table A-1 summarizes important comparison points.

Table A-1 Comparing Deployment Types

	Small	Large, Non-Expandable	Large, Expandable
Best Practice Recommendation	Recommended for: Proof of concept Very small organizations with no growth anticipated	Not recommended (see Why Large, Non-expandable Deployments Are Not a Best Practice)	Recommended for all organizations unless a small deployment clearly meets all present and future needs.
Deployment Documentation	All-in-One (Small) Deployment—Creating in the Filr 4.1: Installation, Deployment, and Upgrade Guide	Non-Expandable Deployment—Creating in the Filr 4.1: Installation, Deployment, and Upgrade Guide	This planning guide and the Filr 3.0 Installation and Upgrade Guide.
Deployment Size	One all-in-one appliance	One Filr appliance Two Filr Search appliances Access to a MariaDB, MySQL or MS SQL database, or one PostgreSQL appliance	At least two recommended; one required. Micro Focus has tested up to 10. Two Filr Search appliances Access to a MySQL, MariaDB, or MS SQL database, or one PostgreSQL appliance
Off-loading Processor-Intensive Functions	n/a	n/a	We recommend dedicating one Filr appliance to only content synchronization and indexing.
Expansion to Accommodate Increased Filr-Service Demands	n/a	n/a	In theory, you can add as many Filr appliances as needed. In practice, as with any system, there are limitations external to Filr, such as network bandwidth, hardware limitations, and other constraints that, at some point, become bottlenecks for Filr scalability and performance. Micro Focus’ performance and scale test beds include up to 10 Filr appliances.
Fault Tolerance	n/a	None for Filr Filrsearch appliances are independent and redundant.	Multiple Filr appliances provide continual service access Filrsearch appliances are independent and redundant. Two index servers are sufficient
High Availability	Single point of failure	Single point of failure	With a load balancer deployed, two or more Filr Appliances can be attached to the same shared storage, which in turn can be protected by traditional clustering.
Migration to Large, Expandable	Not supported	Not supported	Expansion is inherent as explained above
User requests per second It isn’t possible to define the number of users that a Filr appliance can service. See Tuning Filr 3 for Performance.	In a lab setting, a single Filr appliance accommodates 762 logged-in users making 42 requests per second with no performance degradation.	In many cases, slightly fewer requests per second than a small appliance.	Load handling per Filr appliance is the same as non-expandable deployments. However, as explained in Expansion to Accommodate Increased Filr-Service Demands, adding Filr appliances expands the capabilities many times.
SQL Database	Integrated	Separate SQL database recommended. PostgreSQL appliance available but not intended for enterprise use.	Separate SQL database recommended. PostgreSQL appliance available but not intended for enterprise use.

An Example of A Large, Expandable Filr Deployment

Figure A-2 illustrates the components and protocols that could be included in a large, expandable Filr deployment.

Figure A-2 Example Components of a Large Expandable Deployment