Forced migration from FMS15/mac to FMS15 windows

[cbum]

For security reasons, my institution is requiring me to migrate my FMS15 solution, currently residing on a MacPro in my office, to the IT data center. Since they do not run MacOS, this includes a migration to a hosted windows server running FMS advanced. I no nothing about windows (eg: what is a hosted win server vs simple win server ???) , so I will be totally dependent on the IT staff knowing what they are doing (and they barely know FM, I narrowly escaped having them try to recreate the solution in Access for $$$$$ ...):

Current Environment

·      FileMaker Server Advanced running on local Mac OS12.12 system.

·      RAID-0, Solid State Drives

·      8-Core CPU

·      32gb RAM

·      FileMaker DB is 100gb with additional storage required for temporary files and local DB backups

Proposed Environment

·      Hosted Windows Server running FileMaker Server Advanced

·      4-CPU

·      16gb RAM

·      1tb Storage

 

I have many questions/concerns, but would appreciate feedback on 2 issues:

1. Backups: My understanding is that FM is adamant that no backup system can touch a “live” database file, causing potential corruption. FMS has its own internal backup mechanism, and you point it to some external drive / directory etc, where it creates backups that can then be copied/archived by a system process or third party backup system.

The IT manager I am discussing this with replied the following: "Backups should not be an issue either. We've been using this model on our SQL servers and have not experienced a single issue over many years. They do their backups and we do our own as well."

 

I don't know what the windows server system is doing for backups, but are the FM warnings about letting other backup systems touch live FM files only for 3rd party SW, and system processes are OK? Any specifics I should communicate to the IT guys? Again, I know nothing about how win or win/server does this.

 

2. Performance:  I am obviously worried performance will take a hit, if only from networking.

I am hosting a dozen related files ranging from 1-50 GB, typically 5-10 concurrent local and remote users.

The proposed environment seems less optimized for DB performance - what are the key parameters I should negotiate on? My current 32gb RAM may well be more than what is needed (I don't use any web or go functions, just straight FM clients), but can I determine from the admin console logs/stats how much is really needed? My request for SSDs was immediately shot down, how much can I get from various RAID configs they may or may not agree to?

 

Thanks for any feedback - I am so not looking forward to this...

 

Edited March 18, 2017 by cbum

[Fitch]

It's important that the backups exclude the live database folder. This is non-negotiable. Also anti-virus should exclude the live databases. Turn off screen saver, turn off indexing. Make sure they open up the necessary ports in your firewall. All this and more is documented:

https://fmhelp.filemaker.com/docs/15/en/fms15_getting_started.pdf

Make sure the server meets the specs:

http://www.filemaker.com/products/filemaker-server/server-15-specifications.html

A fast hard drive is extremely important, but fast network is too, so it's possible you may get equal or better performance from your new server. Windows server is actually a very good host for FileMaker. Try to foster a good relationship/partnership with your IT guys. They may have preconceptions about FileMaker based on antiquated information. Good luck!

[Wim Decorte]

With "hosted' they probably mean that it is a virtual machine, not a physical server.  Just ask; there is no shame in asking.  Certainly do ask what they mean by 'hosted'.  Is it a physical or virtual machine in the cloud?  (Amazon AWS, Microsoft Azure,...?).  If it is a cloud machine then all your client connections will become WAN instead of LAN and that could very well impact the user's experience.

If you are worried about performance then make sure you have a performance baseline.  Turn on the FMS stats.log on the 'logging' tab in the FMS admin console.  It is off by default and tracks performance data across the 4 traditional bottlenecks (disk i/o, processor, network throughput and memory).  Safe that file when you cut over to Windows.  That file will give you something measurable to compare against when you do the same monitoring on the new server.  Numbers don't lie.

One thing that I would insist on: since you now have an 8-core machine, I would ask for the same on the new machine.  That is a more important fight than the memory.  The 16GB of RAM is more than enough.

Don't kid yourself on the 'optimized for db performance'.  The Mac Pro is no no way optimized as a database server.  It's beefed up workstation with a waste of GPU power for its role as a server.  Don't use this as an argument with IT, you'll lose all credit.

If this is a virtual machine changes are that they are using a SAN as the disk sub-system and that it is driven off of SSDs anyway.  But ask.

Fitch's point about the backups is absolutely vital.   FMS is not SQL Server and has different requirements for how backups are done.  No 3rd party backup or Anit-virus shoud touch the live files or the backups while they are in progress.

These days, Windows backups are usually done through the Windows Volume Snapshot Service and if it is a virtual machine then often through a snapshot of the whole virtual instance itself.  When you restore from such a snapshot at a minimum:

- the FM files will come back as 'improperly closed' because FMS did not have a chance to put the files in the proper state before the external backup was done

- at worst the FM files will not open again because they will be damaged

The Windows tools can be made safe by integrating them with the FMS admin command line to first pause the files and resume them afterwards.  Not too difficult but requires some work with the IT department.

I mentioned anit-virus: many IT departments will configure AV and insist that 'on-access' scanning is on.  That can lead to all sorts of problem as the AV tries to scan the files every time FMS writes to them.  That should be turned off.  There is a FM knowledge base article that you can use here to give to IT.

 

 

 

[cbum]

thanks guys, great feedback as always.

I do not believe this is a cloud solution, certainly not like AWS, though possibly some institutional "cloud", and they do run virtual machines, I will have to find out if that is what they are planning for the FMS. 

As to backups & AV - I hear you, and hope they will. This may sound silly, simply reflecting my win ignorance, but can the win volume snapshot service be told to ignore specific files or subdirectories, or is it all or nothing? If the former, it should be feasible to tell it to ignore the live DB files and only back up the backup folder, no?

I had not thought about AV - how do I address a possible data-center wide requirement that all drive be under AV control? Are there AV solutions that can run at intervals, coinciding with a script to turns the DB files on and off?

 

Thanks

 

 

Edited March 19, 2017 by cbum

[Wim Decorte]

2 hours ago, cbum said:

can the win volume snapshot service be told to ignore specific files or subdirectories, or is it all or nothing?

All or nothing.  FMS is not VSS-aware so it is not safe to use unless the FM files are first stopped or paused; pausing can be done without disconnecting the clients, through the command line (fmsadmin pause) so it can certainly be automated.

 

2 hours ago, cbum said:

 

I had not thought about AV - hope do I address a possible data-center wide requirement that all drive be under AV control?

AV requirements can be met through scheduled scans that exclude the live files and by picking a schedule time that does not interfere with FMS own backups.

The one thing that can not be on is 'on access' scanning.

 

2 hours ago, cbum said:

ignore the live DB files and only back up the backup folder,

3rd party backup that works at the file level can be made safe that way... provided that it does not run when FMS is doing its own backup.

Mind the progressive backups if you are using those; you can't control when those run.  You can control the interval but they will start when the db engine starts so the exact runtimes are unpredictable from one server reboot to the next.

[cbum]

Yes, I was wondering about the progressive backups as well, but I have not used them so far.

The command line you mention, "fmsadmin pause", is invoked with a FM script, eg at a specific time to coincide with scheduled backups,, or is that something the OS recognizes?

 

c.

 

 

[Wim Decorte]

13 hours ago, cbum said:

The command line you mention, "fmsadmin pause", is invoked with a FM script, eg at a specific time to coincide with scheduled backups,, or is that something the OS recognizes?

 

No, it is not a FM script command, it is an OS command.  So you'd use it in a batch file or a VBscript or a PowerShell scriptl whatever IT is most comfortable with.  In its simplest form (a batch or cmd file) it would look something like this:

fmsadmin pause -y -u soliant -p testing
vssadmin create shadow /For=D:
fmsadmin resume -y -u soliant -p testing

soliant / testing would be the FMS admin console credentials, the /For=D: specifies that the D drive should be snapshot.