Page tree
Skip to end of metadata
Go to start of metadata

Guidelines


Full support for scaled applications is not available at this time. FusionReactor can monitor these applications, however there are currently some limitations and guidelines detailed below. We are working to rectify these issues.

The -Dfrlicense.deactivateonshutdown=true and -Dfrshutdownaction=remove properties do not currently work as desired. This is due to that fact that currently OpenShift do not seem to cleanly shut down scaled gears when they are removed and these shutdown properties are not correctly executed by FusionReactor.
As such it is currently necessary to manually:

  • Deactivate/delete old activations in ODL otherwise you may run out of activations on your license.
  • Delete 'dead' FusionReactor instances from the Enterprise Dashboard.

This issue has been raised with OpenShift and we are currently working to resolve it so that both of these processes are automatic as intended.

It should be noted that HAProxy will attempt to contact the index page of each application instance every two seconds as part of its health-check routine. As such you will notice this activity on your request history tables and graphs. If this is undesirable or causing too much ' noise' in your monitoring it is possible to tweak this heartbeat cycle by using the method on this page:

However if the interval is set as too long this may adversely impact the how the load balancing algorithm works in high-load situations.

Due to the way scaling works in OpenShift, each newly added gear is a direct copy of your first and will have a new instance of FusionReactor. The below methods all use the approach of directing FusionReactor instances (on new gears) to register with the Enterprise Dashboard of a primary FusionReactor or FusionReactor Administrator instance. In this way you can visit the different instances of FusionReactor by following the links on the Enterprise Dashboard.

 

The following methods all use the standard FusionReactor Openshift installation as a blueprint. Please refer to the following pages for these instructions.

Deployment Methods


Deploy FusionReactor as you would for a non-scaled application

The first method is to deploy FusionReactor as you would for a non-scaled application and have newly created instances of FusionReactor register themselves back to the Enterprise Dashboard 'primary' instance on the first gear.
 

Append the following properties to the pre_start_<server_name> action-hook file:

-Dfrregisterhostname=${OPENSHIFT_GEAR_DNS} -Dfrregisterwith=http://Administrator:<primary-instance-password>@<application-url>/fusionreactor
-Dfrlicense.deactivateonshutdown=true -Dfrshutdownaction=remove

The first two properties allow for FusionReactor instances on newly created gears to register with the Enterprise Dashboard of the 'primary' FusionReactor instance. The final two properties cause FusionReactor instances to deactivate their licenses and de-register with their Enterprise Dashboard when their host gear is shut down.

  • Due to the design of scaled applications, it is currently not possible to bypass the HAProxy load-balancer to reliably access the first gear and thus the 'primary' instance of FusionReactor. This is a limitation and something that has been raised with OpenShift.
  • Once an application scales beyond 3 gears, requests to the first gear are slowly phased out by HAProxy until finally being shut off entirely so as to free more resources for the load balancer. This combined with the above issue means that it becomes harder to directly access the 'primary' FusionReactor instance and eventually impossible to do so. For applications that will scale more than 3 gears, it is advisable to use one of the other methods listed below. 

 

Create a separate non-scaling application on another gear

This method involves creating another application on your domain and using this to only run an instance of FusionReactor. You can then register all application FusionReactor instances to the Enterprise Dashboard of the primary instance. As previously, the following properties must be appended to the JAVA_OPTIONS string inside the pre_start_<server-name> action-hook file:

-Dfrregisterhostname=${OPENSHIFT_GEAR_DNS} -Dfrregisterwith=http://Administrator:<fram-password>@<fr-application-url>/fusionreactor
-Dfrlicense.deactivateonshutdown=true -Dfrshutdownaction=remove

This method will require you to consume another gear on your domain/account, this means you would have less (free or total) gears available for your main application to scale. If your application is required to scale past 2 gears it may be better to use one of the two methods below instead.

Create a separate application on another OpenShift account

This method is the same as above but rather than create another FusionReactor application on the same domain/account as your deployed application, you can create another 'basic' OpenShift Online account, On this account you can run a web container and use this to run only a primary FusionReactor instance, allowing your application FusionReactor instances to register back to this one.
 

Register all instances back to a local FusionReactor Administrator

This approach is similar to the previous two but instead directs all application instances to register back to a an instance of FusionReactor Administrator (FRAM) that is running outside of the OpenShift platform, and is publicly addressable. As previously the following properties must be appended to the JAVA_OPTIONS string inside the pre_start_<server-name> action-hook file:

-Dfrregisterhostname=${OPENSHIFT_GEAR_DNS} -Dfrregisterwith=http://Administrator:<fram-password>@<fram-instance-url>/fusionreactor
-Dfrlicense.deactivateonshutdown=true -Dfrshutdownaction=remove

The only issues with this approach are:

  1. A requirement to publicly expose machine running your instance of FusionReactor Adminstrator.
  2. There will be a latency delay when receiving Enterprise Dashboard state information from the managed instances.
  • No labels