Site icon CormacHogan.com

Can Storage Policies be used with VIC?

The answer is an emphatic yes. One can absolutely use storage policies with vSphere Integrated Containers (VIC). However, there is currently no way to specify a policy at the docker CLI when creating a container (at this time). Therefore one would have to deploy the VCH, then deploy the container, and then finally modify the storage policy as appropriate. My understanding is that consideration is being given to a way to do this at deployment time, but at the present, it involves a number of steps. Let’s discuss them in turn.

First off, the containers would need to be deployed on a datastore that can consume policies. Let’s take vSAN as an example. When deploying the VCH (Virtual Container Host) you must specify the container-store. At the moment, this defaults to the same as the image-store, but this should change going forward. Now that the image-store is a vsanDatastore, then containers are also deployed to the vsanDatastore, with a default policy. Here is the complete deployment of the VCH, where the image-store (and conversely the container-store) is specified as a vsanDatastore:

root@photon-NaTv5i8IA [ /workspace/vic ]# ./vic-machine-linux create \
--bridge-network Bridge-DPG --image-store vsanDatastore  \
-t 'administrator@vsphere.local:VMware123!@10.27.51.103' \
--compute-resource Mgmt
INFO[2016-11-01T12:16:29Z] ### Installing VCH ####
INFO[2016-11-01T12:16:29Z] Generating certificate/key pair \
- private key in ./virtual-container-host-key.pem
INFO[2016-11-01T12:16:29Z] Validating supplied configuration
INFO[2016-11-01T12:16:29Z] vDS configuration OK on "Bridge-DPG"
INFO[2016-11-01T12:16:29Z] Firewall status: DISABLED on \
"/CNA-DC/host/Mgmt/10.27.51.10"
INFO[2016-11-01T12:16:29Z] Firewall status: DISABLED on \
"/CNA-DC/host/Mgmt/10.27.51.8"
INFO[2016-11-01T12:16:29Z] Firewall status: DISABLED on \
"/CNA-DC/host/Mgmt/10.27.51.9"
INFO[2016-11-01T12:16:29Z] Firewall configuration OK on hosts:
INFO[2016-11-01T12:16:29Z]   "/CNA-DC/host/Mgmt/10.27.51.10"
INFO[2016-11-01T12:16:29Z]   "/CNA-DC/host/Mgmt/10.27.51.8"
INFO[2016-11-01T12:16:29Z]   "/CNA-DC/host/Mgmt/10.27.51.9"
INFO[2016-11-01T12:16:30Z] License check OK on hosts:
INFO[2016-11-01T12:16:30Z]   "/CNA-DC/host/Mgmt/10.27.51.10"
INFO[2016-11-01T12:16:30Z]   "/CNA-DC/host/Mgmt/10.27.51.8"
INFO[2016-11-01T12:16:30Z]   "/CNA-DC/host/Mgmt/10.27.51.9"
INFO[2016-11-01T12:16:30Z] DRS check OK on:
INFO[2016-11-01T12:16:30Z]   "/CNA-DC/host/Mgmt/Resources"
INFO[2016-11-01T12:16:31Z] Creating virtual app "virtual-container-host"
INFO[2016-11-01T12:16:31Z] Creating appliance on target
INFO[2016-11-01T12:16:31Z] Network role "external" is sharing NIC with "management"
INFO[2016-11-01T12:16:31Z] Network role "client" is sharing NIC with "management"
INFO[2016-11-01T12:16:35Z] Uploading images for container
INFO[2016-11-01T12:16:35Z]      "bootstrap.iso"
INFO[2016-11-01T12:16:35Z]      "appliance.iso"
INFO[2016-11-01T12:16:38Z] Registering VCH as a vSphere extension
INFO[2016-11-01T12:16:46Z] Waiting for IP information
INFO[2016-11-01T12:17:01Z] Waiting for major appliance components to launch
INFO[2016-11-01T12:17:09Z] Initialization of appliance successful
INFO[2016-11-01T12:17:09Z]
INFO[2016-11-01T12:17:09Z] vic-admin portal:
INFO[2016-11-01T12:17:09Z] https://10.27.51.18:2378
INFO[2016-11-01T12:17:09Z]
INFO[2016-11-01T12:17:09Z] DOCKER_HOST=10.27.51.18:2376
INFO[2016-11-01T12:17:09Z]
INFO[2016-11-01T12:17:09Z] Connect to docker:
INFO[2016-11-01T12:17:09Z] docker -H 10.27.51.18:2376 --tls info
INFO[2016-11-01T12:17:09Z] Installer completed successfully
root@photon-NaTv5i8IA [ /workspace/vic ]#

Let’s take a look at the VCH storage policy. We can clearly see that it is using the default storage policy for Virtual SAN.

Next, lets deploy a container. In this example, we will deploy an Ubuntu image and drop into a bash shell:

root@photon-NaTv5i8IA [ /workspace/vic ]# docker -H 10.27.51.18:2376 --tls run \
-it ubuntu bash
Unable to find image 'ubuntu:latest' locally
Pulling from library/ubuntu
a3ed95caeb02: Pull complete
6bbedd9b76a4: Pull complete
fc19d60a83f1: Pull complete
de413bb911fd: Pull complete
2879a7ad3144: Pull complete
668604fde02e: Pull complete
Digest: sha256:312986132029d622ae65423ca25d3a3cf4510de25c47b05b6819d61e2e2b5420
Status: Downloaded newer image for library/ubuntu:latest
root@6c8d6a4add24:/#
root@6c8d6a4add24:/# ls
bin  boot  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  \
run  sbin  srv  sys  tmp  usr  var
root@6c8d6a4add24:/#

Let’s take a look at what this looks like from a storage policy perspective. Remember, one of the great benefits of VIC is that we get full visibility into our container, as it looks just like a VM:

We can clearly see that this “container as a VM” has been deployed to the vSAN datastore and has also picked up the default vSAN datastore policy. Now we can easily go in and edit the settings of this “container as a VM” and change the policy of its VMDK to something else. For example, I can set this to a non-default policy called FTT=1, even though it achieves the same availability as the default policy. Now if I look at the compliance state, I see two policies:

The reason why we see two policies is because the default policy is still associated with the VM Home object, but the VMDK object now has the new FTT=1 policy. This can be seen in greater detail if we navigate to the Monitor > Policies view, and look at the physical placement of the VMDK object, as shown here:

So there you have it. As a vSphere admin, not only do you have full visibility into the “containers as VMs” deployed via VIC, but you can also make VIC containers highly available from a storage persistent perspective. You can do this by deploying these containers on a storage system that is policy driven, such as vSAN. And you can then modify the policies according to your requirements.

Exit mobile version