With FH (FusionHub) running as a AWS VM, there remains a few hurdles for automated setup of a new FH instance.
You are required to instantiate a new FH VM instance from a private AMI provided by PepWave. That is okay but you are still required to instantiate the VM, manually login though the FH management portal and specify 1) Timezone 2) Networking meta data including PepVPN configuration 3) FH license information.
In all cases, it is likely that an AWS ASG (auto-scaling group) would be used to ensure at least one AWS FH instance is running at all times. If the FH stops responding to an AWS health check (e.g. ping), then an ASG can be configured to terminate the stuck or missing VM and create a new VM.
It would be best if the meta-data listed above could be ‘passed’ to the VM instance creation via the USER DATA. User Data is used at VM start up to help configure things for unattended high availability. Creating an AMI image of a configured/running FH VM and using that custom AMI for VM instantiation does not work. Could be for any number of reasons but I’m guessing it is license related.
While I’m testing AWS FH with a evaluation license, I would expect this use case to come up in normal DevOps activities. Having to manually deactivate a FH license via the InControl2 website is going to be an obstacle under AWS.
ASG support is on our roadmap.
To allow ASG invoke a new FH without go through the initial setup, a new FH will connect to InControl2 to request a license (FH will pass your account information to InControl2). If your account has un-occupied FH license, the license will push to FH and mark the license occupied. If you only have 1 FH license, this license will push to the new FH once the old FH is offline in InControl2 (i.e. migrate the license to the new instance).
What do you think?
In your deployment, do you need multiple instances of FH (and load balance those instances)? or just for HA purpose?
Hi - I can’t imagine trying to load balance a FH, at least not in the AWS ‘load balancer’ sense.
At the very least, a FH needs to have the ability to be configured via an AWS “Launch Configuration” object. The launch configuration configuration includes specifying security group(s), AZ, and User Data. User Data is where you need to accept FH configuration specific information such as license key, time zone, etc. This is all the domain of the AWS administrator of the FH VM’s. It could be a ASG (auto scaling group), AWS CLI, CloudFormation script, etc that creates a new FH VM.
And yes, the ‘use case’ of a single FH license in a HA (high availability) scenario needs to be considered. So if a ‘single use’ FH goes down and is re-started by AWS, then the FH startup needs to keep re-trying it’s ‘license check’ with InControl2 until it succeeds. Even better, would be for the license check to be deferred or cached locally. Having a dependency of FH needing Incontrol2 in order to boot up is not good, from a HA perspective.
Thanks for your feedback. I will make sure your opinions are discussed during FH feature discussion.
As mentioned, this feature is on the roadmap without any release time yet but should not be far away. Stay tunes.