 I have a PHP application here that's running with a MySQL database. I have deployed this into a project which has two separate parts. One is the part for the front end which is named as DB test and the other one is for the database which is running a MySQL database. As you can see, the front end part, the DB test part, it's running on Node 2. Let me also show you what I have in my OpenShift setup. When I do OSC get nodes, you'll see that I have three nodes here. The master itself is acting as a node as well as I have Node 2 and Node 3. Both Node 2 and Node 3 are configured to be for the region primary and you have seen that the front end part is running on Node 2. Now, if I try to scale up this front end by adding additional parts, then OpenShift will make sure that it will distribute those new parts that are getting added between this Node 2 and Node 3. The reason being if one of the nodes goes down for some reason, then you have at least one of the other nodes that is servicing this application. So the application doesn't go down. That's how OpenShift ensures high availability. Now, let us also see these parts from the command line as well. So I have filtered the parts based on the deployment configuration of type DB test. So you can see that there is one part. This is the same as what you have seen on the web console. Now, let's try to scale it up. In order to scale it up, we need to know what the replication controller is for the DB test application. So I'm doing OSC get RC to find all the replication controllers that are running. So we have two different replication controllers. One is for the database part and the other is for the front end. This one for the front end is configured to have just one replica of this front end running at any point of time. So the replication controller is the one that ensures n number of parts that are configured here are running at any point of time. Now, let's use this replication controller and resize it and we'll set the number of replicas to be two instead of one. Let's see what happens. So if you come back to the console now and see there is a... It was in the pending status till now, but now it isn't running. There is an additional part. This was the one that was running before. It was on node two. Now, there is an additional part that got spun up and this is on node three now. Just to show, I'll resize it again to four instead of two and we'll see quickly there are two more additional parts that are being spun up and within no time they start running. So it's as quick as that. So two additional parts got spun up and one of them is on node two and the other one is node three. Command line. So you'll see that there are four parts running. So this is how OpenShift scales up quickly and also it distributes the parts that it is creating across the two nodes so that there is high availability. Now let's try to knock off one of the parts and see what happens and I'm passing it this name 9WRHP. I'm trying to delete that. So let's see what happens. I deleted the part and then now if I see what how many parts are available. I deleted the fourth one but there is another one that got created in its place. So in place of 9WRHP there is a 3T1FM now. Where did it come from? That's because the replication controller dbtest ensures that four parts are available at any point of time. If you do OSC get RC now it is configured to be four. So it makes sure that four parts are always running. Now let me resize this back to say two replicas and see what happens. It is resized. Now if I check the number of parts there are only two parts here and you can see how quickly OpenShift has resized this number of parts.