Any thoughts on how Google Could or Microsoft Azure handles this?
I'm not sure but I'll try one of those next time I need to start up a server Overseas. I'm using VPSBlocks in Australia because of the failover.
Note that we run all VMs off SANs on our FileMaker hosting services so we are able to migrate VMs to different hardware nodes when there is a failure. For a host not to take care of this for you, and you even potentially lose access to your VM/data, is unacceptable.
This is why everyone should consider using a host with specific FileMaker experience when shopping around. FileMaker Server is not nearly as cut and dry as most Apache, etc. setups, and requires a higher level of hardware specifications and software support.
On my AWS instance, I used the Amazon tools to create a script which runs daily as a System script. The script is four lines long.
It goes something like this:
set AWS_ACCESS_KEY_ID= [key goes here]
set AWS_SECRET_ACCESS_KEY= [key goes here]
was s3 sync "C:\Program Files\FileMaker\FileMaker Server\Data\Backups" s3://mybucketname/myfolder/ --delete
That's it. It syncs my backup folder with an S3 bucket from Amazon.
I will look into the hardware failover situation, so thanks for the heads up about it.
Found this in an AWS forum:
What you should do is issue a STOP command from the command-line/API or use the Management Console to Stop the instance. Once the instance is stopped, all you have to do is just start it again and it will then spawn on a new healthy host. Please note that stopping and starting the instance is different from rebooting an instance so please make sure that you actually stop the instance and not just reboot.
You might also consider making it available in more than one availability zone within your region.
Also, if you are running your it as an EC2 classic instance, you should consider moving to the much more extensible VPC type.
I don't know if there is any one perfect solution for hosting FileMaker, since it really depends on the project and the deployment.
While you may not be able to take advantage of their elastic load balancing with FMS, you could always spin up a warm backup using the failover tools provided in FM 14 and later to keep a backup available and at the ready. That backup server could be in a different zone for redundancy, but would need to be part of the same VPC.
AWS will do what you want, it's just that you have to set it up yourself. Take a look at AWS Auto Scaling to switch instances when needed, and AWS CloudWatch to monitor server health.
I've done some rough experimenting with various instance types on AWS. I posted results here:
If you STOP an instance and have gone with the basic settings, then when you restart the instance, you'll have a different IP address. No big deal, but you'll have to adjust the host settings in that situation.
If you get an elastic IP and associate it with your instance, or if you assign an actual URL to it, then your IP address won't change. Very handy.
Thanks Mike that worked!
This was Amazon's email instruction:
* What do you need to do?
You may still be able to access the instance. We recommend that you replace the instance by creating an AMI of your instance and launch a new instance from the AMI. For more information please see Amazon Machine Images (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) in the EC2 User Guide. In case of difficulties stopping your EBS-backed instance, please see the Instance FAQ (http://aws.amazon.com/instance-help/#ebs-stuck-stopping).
I'll look into the VPC type. One thing about Amazon is they have their own terminology, so Googling "Amazon automatic failover" is a bit useless