 In this demo, we'll see how OpenShift handles auto-scaling. OpenShift has an auto-scaling mechanism built-in when you create an application as a scalable application. And by default, it scales based on number of concurrent connections that are hitting a particular container or gear in OpenShift terms. So let's look at how OpenShift scales by an example. So I will create an application as a scalable application on OpenShift and we'll pump in some load onto that application and see how it scales. Now, before we create an application, I wanted to quickly show you that I have two different nodes just to show that the scaling actually happens across multiple nodes when you have multiple nodes so that if one of the node goes down, the application still runs. So the scalable application not only scales up, it also provides some level of high availability in OpenShift. So I'll show you two nodes here. There is a node 11 and node 12. These two are configured as medium-sized nodes and I am in this varlib OpenShift directory and currently you'll see that this is empty and on both the nodes, node 11 and node 12, the reason I'm showing this directory varlib OpenShift is because this is where the containers are created. This is where the gears are created. And in OpenShift, when you create an application and a gear spins up, the gear gets a unique user ID, a unique Linux user ID and I'll show you that in a minute. Now, having said that, let's create an application now. I'll create an application using a scale application. I'm copying the code from a cool-scale application demo that's available on GitHub. And all I'm doing here is I'm issuing a command to create an app, R-HTC app create. I'm naming the application as ScaleApp and I'm using two cartridges, Jboss EAP, which is the application server and a MongoDB cartridge. And this minus S flag indicates that I'm creating a scalable application. I'm saying I want to create it from the code and I'm copying the code from GitHub. And the last parameter here is I'm choosing a medium-sized node. Just for the sake of to make sure that there is enough capacity for this Jboss EAP app to run, I'm choosing a medium-sized node. So now when I issue this command, this command goes to OpenShift and it starts creating the application. It takes a couple of minutes at this point of time because it's copying the code from GitHub. So it depends on the connection speed between GitHub and the OpenShift node. I'm going to pause this demo for a little while and once the application is created, we'll come back and have a look at it. As you can see, the application just got created and the MongoDB also got added and it's asking me to give permission to copy this application onto my local machine, which I did. Now I should find this application and copy it onto my local machine so you can see the scale application here. Now let me show you a couple of additional things here. On the OpenShift web console, if I look at the list of applications, now there is a scale app and the scale app is using two gears now. The reason is when you create a scale application, the database gets its own gear. It's running in its own medium-sized gear and the application server is also running in its own separate medium-sized gear. So there are two gears that are used and the JVOS EAP gear can scale now from anywhere between 100 to 100 where 100 is the account limits I have. You can also see that there is a web load balancer that frontends this application. It's a HA proxy and we can also look at the HA proxy status page that shows us that this is the HA proxy status gear which shows that there is a single local gear where this application is running along with the HA proxy. Now let's look at where these gears got created, the two containers. We had two nodes, node 11 and node 12. At this point, there is nothing that is happening with the application. The application just got created. So let's look at the varlib open shift folder on node 11. It has nothing in it and let's look at varlib open shift folder on node 12 and it has two gates. So one of these is that gear that runs a HA proxy and the application code and the other one is the one that runs MongoDB. Now let me start adding some load to this application. I'll be using Apache benchmarking tool, and I'm just choosing a couple of places from where I'm going to run this. So starting it at two places and we'll also bring up this application in the browser. So you'll see this application is, the front end is cool. It counts the number of gates or containers that are associated with this application and you will see that as the gates are getting added, it'll show up here on this front end. And these orange boxes that you're seeing here is the load that this application is getting. Now, at the same time, I'll also SSH onto this gear and show you what's happening behind the scenes. I'll use RHC SSH command to get into this gear. Now I'm inside the gear. This is the gear where the HA proxy and the application is running, the single gear. Now let me tell the HA proxy logs. Once the load reaches a point where a single gear cannot handle the load anymore, you'll see that it'll request for additional gates to be created. This will take some time. I will run this a little fast now. As you can see now, a request for new gear came up and this means that one gear is not able to handle the workload and the number of concurrent connections are more than what a single gear can handle. So HA proxy has sent out this add gear request to the broker and the broker will now provision an additional gear. Let me speed up again. See that the new gear is now added successfully and this add gear request has exited with code 0, which means that the gear was added successfully by the broker. Now you'll also see that on the application's front end, this application shows that a new gear got added and the load is being now taken by both the gears that are available. So now HA proxy, which is front-ending these two gears, is distributing the load among these two gears. Now looking at the HA proxy status page, now you'll also find an additional gear and that additional gear is now added. It's ending with 008A and this is not a local gear. The local gear was the first gear and now let's go and see where this got created. So you'll see that on node 12 it still has only two gears and on node 11 there is a new gear that is added and there is 008A. So this is the new gear that got added. Now as the application scales, the gears get evenly distributed across all the available nodes, which means that even if one of the nodes goes down, the application continues to run. So that's the kind of high availability that comes along with the auto-scaling by default. For full HA, you can have multiple HA proxies front-ended by an external load balancer.