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 3.4: 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 3.4: Installation, Deployment, and Upgrade Guide

Non-Expandable Deployment—Creating in the Filr 3.4: 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 MySQL or MS SQL database, or one MySQL appliance

  • At least two recommended; one required. Micro Focus has tested up to 10. (See Expansion.)

  • Two Filr Search appliances

  • Access to a MySQL or MS SQL database, or one MySQL 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, adding Filr appliances expands the capabilities many times.

SQL Database

Integrated

Separate SQL database recommended.

MySQL appliance available but not intended for enterprise use.

Separate SQL database recommended.

MySQL 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