Now let‘s bring the concept of the “cluster” back in. We could wrap our appserver in the same DynamicCluster we used earlier, although then we’d need to define and configure the load balancer. But another blueprint, the ControlledDynamicWebAppCluster, does this for us. It takes the same dynamiccluster.memberspec, so we can build a fully functional elastic 3-tier deployment of our hello-world-sql application as follows:
{% highlight yaml %} {% read example_yaml/appserver-clustered-w-db.yaml %} {% endhighlight %}
This sets up Nginx as the controller by default, but that can be configured using the controllerSpec key. This uses the same externalized config as in other examples to hide the password.
JBoss is actually the default appserver in the ControlledDynamicWebAppCluster, so because brooklyn.config keys in Brooklyn are inherited by default, the same blueprint can be expressed more concisely as:
{% highlight yaml %} {% read example_yaml/appserver-clustered-w-db-concise.yaml %} {% endhighlight %}
The other nicety supplied by the ControlledDynamicWebAppCluster blueprint is that it aggregates sensors from the appserver, so we have access to things like webapp.reqs.perSec.windowed.perNode. These are convenient for plugging in to policies! We can set up our blueprint to do autoscaling based on requests per second (keeping it in the range 10..100, with a maximum of 5 appserver nodes) as follows:
{% highlight yaml %} {% read example_yaml/appserver-w-policy.yaml %} {% endhighlight %}
Use your favorite load-generation tool (jmeter is one good example) to send a huge volume of requests against the server and see the policies kick in to resize it.