Dynamic volume provisioning on Red Hat OpenShift

In this scenario, you’ll learn about Portworx Enterprise StorageClass parameters and deploy a demo application that uses RWO (ReadWriteOnce) Persistent Volumes provisioned by Portworx Enterprise, and see how Portworx makes them highly available.

To connect to the console, click on the OpenShift Console tab above.

We can then log in with the following credentials:

Username: kubeadmin Password: kubeadmin_password

In this step, we will deploy our Portworx BBQ application that uses MongoDB and an RWO persistent volume.

In the Terminal tab of the Instruqt webpage, run the following commands to provision Portworx BBQ.

When all of the pods are running with a 1/1 Ready state, press CTRL+C to exit.

Click on the PX-BBQ tab next to the Terminal tab at the top of the screen. Since you just deployed the application, you may see an Nginx error - if you do, click on the refresh icon next to the words "PX-BBQ" on the tab.

Click the "Menu" icon, and select "Login". Enter the username guest@portworx.com and the password guest. Next, click on "Menu" again and select "Order". Select a main dish, two sides, and a drink - then click on the "Place Order" button. The order history page appears - click on the hyperlink to your order number, and make sure your order is correct!

Switch back to the Terminal tab and use the following command to inspect the MongoDB volume and look at the Portworx parameters configured for the volume:

You can see that the HA parameter is set to 3 - this means we have three replicas of the persistent volume, as we declared in the StorageClass that we created.

You can also notice that these three replicas are spread out across our three worker nodes as shown in the Replica sets on nodes section of the pxctl output, and that all three replicas are in sync by observing the Replication Status output which shows Up.

Finally, you can see in the Volume consumers section that our mongo-0 pod is the consumer of the volume, which shows that MongoDB is using our volume to store its data!

To look at the MongoDB entry generated by your order, first get a bash shell on the MondoDB pod:

Then, let’s connect to MongoDB using mongosh:

And finally, let’s query for the order you placed earlier:

You should see your order in the database! Finally, let’s exit from our exec into the MongoDB pod:

In this step, you saw how Portworx can dynamically provision a highly available ReadWriteOnce persistent volume for your application, and you got to order up some delicious BBQ from Portworx!

Great, we’ve got our Portworx BBQ application up and running on highly available PVs, but what happens when the worker node hosting the active replica dies unexpectedly? How will our application react?

First, let’s observe where the MongoDB pod is running (note the NODE column):

Next, let’s get the worker node running the MongoDB pod into a variable:

We will now debug the node:

Chroot to the host

And finally, reboot the OpenShift worker node hosting the running MongoDB pod:

We can watch our MongoDB pod get deleted and recreated. Note the NODE column as the pod gets evicted and recreated; the node name will change and the pod will be rescheduled on a node in a different AZ:

Press CTRL-C to exit the watch command once you see the MongoDB pod has successfully restarted.

Now that we have a fresh copy of our MongoDB pod running, let’s check the information in our MongoDB collection again to make sure your order is still there!

Again, exec into the freshly created MongoDB pod:

Then connect to MongoDB using mongosh:

And finally, query for the order you placed earlier:

Finally, let’s exit from our exec into the MongoDB pod:

To finish making sure our application is healthy, click on the PX-BBQ tab, and click the refresh icon next to the "PX-BBQ" tab name. Use the menu to nagivate to "Order History". You can see that your order for Portworx BBQ is still there!

Click the Next button to continue