10 Replies Latest reply on Aug 21, 2012 1:42 PM by wimdecorte

    FileMaker Server Failover techniques

    PowerSlave

      Hi everybody ,

       

      I have recently placed a purchase order for a 2U 2node server system (2 servers hot swappable in a rack mound, each with 2 Xeon CPU's , 2 SSD drives with RAID, 2 failover power supplies etc). The reason for this is our FileMaker solution is running a complex billing engine that has (PHP) clients logging in to review data based on complex queries, and we cannot afford it to go down or go slow, and full redundancy will be required.

      This database runs quite well on it's current server, but we are looking at around 100 concurrent PHP users at maximum peak time in the not too distant future , so I guess I'm trying to future-proof our platform.

      My question is , has anybody had this type of setup where one server can clone another server ? I know there are software packages out there that can clone, however what is the situation of hosted databases by FileMaker Server ? I'ts my understanding that the database files should NEVER be touched while being hosted, and I was wondering if this issue would cause a problem with the cloning situation.

      Has anyone tried this kind of setup before (excluding VMWare , not an option as we need FileMaker Support if things go wrong) , and if you have, what are your experiences ?

       

      Regards, Lee.

        • 1. Re: FileMaker Server Failover techniques
          wimdecorte

          To the best of my knowledge, deployments on VMware are fully supported by FMI.

           

          When you use cloning software / machine state backup software most likely it will be using the underlying Windows Volume Snapshot Service.  Be aware that FMS is not VSS aware.  That means that while the snapshot will look ok but if you try to restore the FMS files from it, they will improperly closed at least, damaged in the worst case (I've seen that happen).

           

          There are FM-based approaches like the one from WorldSync that lets you synchronize two running instances of FMS.  I presented this kind of high-availability approach in my 2010 Devcon presentation on Disaster Recovery.

          1 of 1 people found this helpful
          • 2. Re: FileMaker Server Failover techniques
            PowerSlave

            Last year I was considering putting FMS on a VM and infact I use my FBA version of FMS12 on out citrix VM server for testing (live is dedicated). However the server guide for FMS 12 talks a lot on the VM subject but warns to do it "at your own discression". It does not state that it is not supported.

            KB Answer ID: 6594 in the knowledge base states that it is not a certified environment, and I was warned last year by FMI Australia that they could not provide support for our server If I chose to do it.

             

            I am fully aware of the VSS, antivirus and indexing issues with FMS files & MS Windows, got caught many years ago (FMS5).

             

            FMI has been good to sort out issues for me in the past so I decided I wanted to keep the support, and ditched the idea of VMWare hosting our live FMS production server.

             

            Both of the servers will have their own licenced copy of FMS and MS WINDOWS, just different ip addresses.I'm hoping that if the live server dies, we just change the IP address of the secondary , and open the DB's in the admin console. The most downtime should be a few minutes. It's mainly the web server that needs to be down for as long as possible.

             

            The DB is a financial billing solution that turns over $8M pa (and rapidly growing) , with potentially hundreds or even thousands of web users (currently around 40 and runs fast even on our old server with 50 other DB's and 55 FMP users.) , so it needs to be ROBUST & FAST. The most number of FMP clients on the new server will be around 5-6, and are not an issue.

            A technique that I was looking at was the incremental backup feature of FMS12, and copying the datestamped folders using a batch script to the secondary FMS on a regular schedule (into the databases folder). Then incase of an emergency we shut the primary down for repair, change the ip address of the backup server to what the faulty one was and open the files on the  FMS Admin console. To users using web access, worst case is they have to login again. FMP clients should still connect using fmp shortcuts using ip address.

             

            This is not as nice setup as a VMWare setup, and does require brief user intervention for recovery, but I think it may work.

            What are your thoughts ?

            • 3. Re: FileMaker Server Failover techniques
              wimdecorte

              Much will depend on the size of the solution and the progressive backup interval length.  You'll probably want to keep that interval as short as you can, but you need to be absolutely certain that you can finish the copy to the other machine before the interval kicks in.  You absolutely do not want to interfere with the progressive backup mechanism itself.

               

              You also would need to spend enough time in error trapping and handling / notifications when anything in that copy process fails.  Otherwise you risk not having something valid to restore on the other server.

               

              Have you looked into SyncDek?  It allows for syncing and would also double as an audit log if you need it.

               

              To a large extent the question needs to be asked of the business: how long can they be without the system and how much data are they willing to lose. If those then are hard commitments that you need to make you will be able to tell them how much money that will cost.  Setting up the basic mechanism is relatively easy, making it foolproof is where the time and money will be spent.

              • 4. Re: FileMaker Server Failover techniques
                ch0c0halic

                PowerSlave may not have analyzed the worst case,

                 

                From your description I can't tell for sure what deployment setup you are using. If this is a two computer deployment, FMS with a WPE client, then your process needs expanding.

                 

                When switching from one FMS to another the WPE located on the client computer will NOT connect to it. Regardless of changing the FMS IP address.

                 

                When the WPE client is deployed to by the FMS it gets both the IP and a computer identifier. If the FMS is replaced the WPE client will not have the proper identification and will not talk to the new FMS. This prevents computer spoofing.

                 

                After changing the IP of the new FMS you will have to also un-install WPE from the client computer so as to remove the first FMS identifiers, then reinstall the WPE client, then redeploy on FMS to the (now unattached) WPE client.

                • 5. Re: FileMaker Server Failover techniques
                  PowerSlave

                  No , both servers will be running as single machine deployments. The backup server will not be seen from the outside world as our router will be forwarding web traffic to the main server (it's just there as a standby server, if you wish). If the main server goes down, changing the ip address of the backup server to the main server's ip will then expose the web of the backup server to the outside world. This is not exactly "server cloning" , but in theory it should be ok.

                  • 6. Re: FileMaker Server Failover techniques
                    PowerSlave

                    Syncdek sounds like a good addition to this setup, I won't have to worry about copying the progessive backup. I'm going to look into this early next week as it may be the best option.

                    • 7. Re: FileMaker Server Failover techniques
                      wimdecorte

                      A somewhat better approach than changing IP addresses (which FMS does not like at all) is to use DNS names.  If all users connect to a DNS name instead of an IP address then you don't have to switch IP addresses and potentially endure an FMS reboot to make it stick.  DNS name changes happen outside of the servers an it generally doesn't take a lot of time to trickle through.

                      • 8. Re: FileMaker Server Failover techniques
                        DavidJondreau

                        We use a service called dynDNS which enables us 1) to give clients a branded domain name ( client.dyndns.info ) that 2) forwards to whatever the actual IP address is ( a 192.168, a general address ( 263.31.etc ), or a another name ( wingforward.pointinspace.com) ). So if we need to switch servers we change the settings at dyndns and it happens instantly. It's $20/ year and worth 10x that.

                        • 9. Re: FileMaker Server Failover techniques
                          PointInSpace

                          We use a service called dynDNS which enables us 1) to give clients a

                          branded domain name ( client.dyndns.info ) that 2) forwards to whatever

                          the actual IP address is ( a 192.168, a general address ( 263.31.etc ),

                          or a another name ( wingforward.pointinspace.com) ). So if we need to

                          switch servers we change the settings at dyndns and it happens

                          instantly. It's $20/ year and worth 10x that.

                           

                           

                           

                          Note that DNS load balancing/failover isn't always a great method.  This

                          is because DNS records have a TTL (time to live) where they remain

                          cached in other DNS servers until expiration.  While you can set the

                          expiration time in your DNS server, not all downstream servers (read:

                          AOL) necessarily respect your setting and sometimes force it to up to 24

                          hours.

                           

                               - John

                           

                          --

                          • 10. Re: FileMaker Server Failover techniques
                            wimdecorte

                            PointInSpace wrote:

                            Note that DNS load balancing/failover isn't always a great method.  This

                            is because DNS records have a TTL (time to live) where they remain

                            cached in other DNS servers until expiration.  While you can set the

                            expiration time in your DNS server, not all downstream servers (read:

                            AOL) necessarily respect your setting and sometimes force it to up to 24

                            hours.

                             

                             

                            Which isn't a problem at all if you manage your own DNS inside your LAN.  That's the scenario that I was referring to.