Even though a single server installation of Filr is recommended only for proof of concepts and small installations the telemetry being received show that about 80% of Filr installations are single server. Unfortunately, there is no supported way to move from a single server to a large, or large clustered installation. Working with Micro Focus we have come up with a way to move between the two. This process has been refined and stream-lined from the presentation we gave at the 2018 Open Horizon Summit in Berlin to make it as easy as possible to undertake.
There are a number of reasons why you may have a single server installation of Filr; it is easier to install one server than multiple servers or you may have just set it up as a proof of concept, but as is so often the case, it evolved into a production system. So why move from a single server installation?
There are a number of reasons why you should consider using a large clustered Filr system as your production environment:
- Scalability. The documentation states that “With a few exceptions, small deployments are only suitable for proof-of-concept”. Typically, the few exceptions are for smaller sites with limited resources and only a few users. With a clustered deployment you can handle hundreds of thousands of users.
- Performance. With separate servers handling different components of Filr the performance for your users can increase.
For instance, you can have a dedicated node just for doing file synchronisation and leave the other web nodes just with the job of handling the users. Or you could have dedicated nodes for handling mobile and desktop users. - High availability. If Filr is a mission critical application within your organisation then it is important that you can deliver a highly available environment, with a clustered install you can deliver multiple web front-ends, multiple indexers and a clustered database, all which ensure that the environment will continue running if a server shuts down.
If you are not using Personal Storage you could always just set up a large clustered system from scratch with the same settings as the existing system. You could import the same users and expose the same file system, however there are many things that would not carry across.
Most importantly any shares, or comments, that you had created would not be there, and any existing links in emails to documents in Filr would be invalid, and of course all existing Mobile and Desktop clients would need to be reconfigured.
The process
This is the step by step guide to what you need to do to migrate. The process is straight forward, but does involve some downtime for your users.
- Backup/snapshot the existing appliance. The process that we have come up with is non-invasive, and does not alter the existing appliance in any way but it is always best to be on the safe side.
At the end of the migration the original server will be unaltered and can be run up again should it need to be, but do take a backup just in case.
If you are doing a snapshot then bear in mind that if the data disk is flagged as independent then it will be excluded from the snapshot, in which case it may just be easier to clone the appliance. - Patch the existing Filr appliance to the latest version (fig 1). This is important as it can be dangerous running appliances that are at different versions.
Telemetry again shows that about 50% of customers that are on 3.x have not patched to the most recent version. Just think about all those new features and security patches you are missing out on.
If you are unsure on how to do this have a look at the last issue of the magazine, Robin covered how to set up the online update there.
Figure 1: Filr patches to be applied - As a clustered install needs a shared area you will need to create an NFS or CIFS share to use as the shared clustered drive, call it vashare. This will be used to store communal files used by all nodes. Typically, unless you are using personal storage, this should be a relatively small size.
If you are creating an NFS share then set it up with recommended clustered settings for Filr of rw and no_root_squash.
If you are using a Windows share then you will also need to create a user that Filr can use to access the share and don’t forget to give them rights to it. To simplify things, maybe use the Filr Proxy user that is used for accessing Net Folder Servers. - Import a search appliance and patch it to the latest level in the same way that you patched the existing appliance. Do not be alarmed if the number of patches to apply is different to the single server appliance as different appliances have different patches. Login as vaadmin to configure the search appliance as you normally would for a cluster. This is covered in Section 8 of the Filr Installation documentation.
Make sure that you enable SSH on this appliance as it will be needed when the index files are copied over later. - If you are planning on using the database appliance then:
Create a database appliance patched to latest version
Configure it as covered in the documentation for a clustered installation
If possible, we would advise to avoid using the database appliance. The reason is that you cannot cluster it. Instead build either a clustered MySQL/Maria environment, or, if possible, use an existing database environment.
If you have an existing MS SQL environment, and wish to use that, then it is possible to migrate your existing MySQL database across to MS SQL, this is covered in section 11 in the Filr Maintenance Best Practice guide. - Stop Filr on the existing single server appliance by logging in to the existing server’s console as root and typing:
rcfilr stop
This will shut down the Filr web application but leave MySQL and other processes running. Shutting down Filr will mean that there will be no additional changes to the databases or file system. At this point your users will be unable to use Filr.
- To move the existing database, from the existing Filr appliance type:
mysqldump -u filr -p<password> filr | mysql -u filr -p<password> -h <address of new db> filr
Depending on the size of the database, this may take a while. The main factor in the size of the database is the number of files that are exposed.
- You could recreate the index from scratch but it is quicker to copy over the existing index to the search appliance. To copy the existing Index use:
scp -rp /vastorage/search/lucene/* root@<address of new search>:/vastorage/search
Yes; that is a slightly different path from that used on the search appliance as to that used on the single server appliance. The r is to do a recursive copy of the directory and the p is to keep the existing permissions.
If you wish to have a pair of appliances (for high availability) and copy the index across a second time to the second appliance. - Next you need to copy directories from existing the vastorage/filr to vashare/filr on the NFS/CIFS drive
On the existing appliance mount the vashare drive
If using a NFS share then use: - Now we are ready to swap out the web appliance so power down the old appliance. You will be able to decommission it in a few days when you are sure that the migration has been successful.
- Add a new Web appliance as if it is the second appliance on a cluster using the IP address from the original appliance, so there is no need to reconfigure firewalls and so on.
Configure in the normal way for a clustered appliance, using the shared storage the files were copied over to.
Patch the appliance to the latest patch level
Set all the appliance specific settings (on the 9443 port) as they were previously - Test and confirm it works
All the settings from the administration console will have carried across. Also shares and comments.
If there is a problem, and it cannot be resolved, power down all the new appliances and power up the old one, your users can continue running Filr as they did before.
Optionally, deactivate SSH services on the search appliance if you do not need them - You should then consider adding any additional nodes to give you the scalability/high availability that you might have wanted. Remember you will need a load balancer in front of the web nodes.
mount <nfs server>:/vashare /mnt
If using CIFS then use
mount -t cifs -o username=<win user> //<serveraddress>/vashare /mnt
Once it is mounted copy the files withcp -rp /vastorage/{filr,conf} /mntThis will just copy the two directory structures we need to the shared area.
Conclusion
While many Filr installations would benefit from being upsized for the reasons given remember that this process is not supported: though both Filr Development and Support have said that they see no issues with it. We suspect that if you have a problem then Support will endeavour to assist you, albeit on a best effort basis.
This article was first published inOHM Issue 42, p8-10.
Co-author: Robin Redgrave