Running your Docker in Production Environment using VMware vSphere Integrated Containers – (Part 1)

In this tutorial, after explaining about running Docker in my Mac. Now, it’s time to move those dockers on your laptop to production environment. In VMware, we will utilise vSphere ESXi as the production grade virtualisation technology as the foundation of the infrastructure.

In production environment, lot of things need to be considered. From availability, manageability, performance, reliability, scalability, security (AMPRSS). This AMPRSS considerations can be easily achieved by implementing docker container from your development environment (laptop) to the production environment (vSphere ESXi). One of the concern of docker technology is the containers share the same kernel and are therefore less isolated than real VMs. A bug in the kernel affects every container.

vSphere Integrated Containers Engine will allow developers familiar with Docker to develop in containers and deploy them alongside traditional VM-based workloads on vSphere clusters, and allowing for these workloads to be managed through the vSphere UI in a way familiar to existing vSphere admins.

Docker itself is far less capable than actual hypervisor. It doesn’t come with HA, live migration, hardware virtualization security, etc. VIC (VMware Integrated Containers) brings the container paradigm directly to the hypervisor, allowing you to deploy containers as first-class citizens. The net result is that containers inherit all of the benefits of VMs, because they are VMs. The Docker image, once instantiated, becomes a VM inside vSphere. This solves security as well as operational concerns at the same time.

But these are NOT traditional VMs that require for example 2TB and take 2 minutes to boot. These are usually as big as the Docker image itself and take a few seconds to instantiate. They boot from a minimal ISO which contains a stripped-out Linux kernel (based on Photon OS), and the container images and volumes are attached as disks.

The ContainerVMs are provisioned into a “Virtual Container Host” which is just like a Swarm cluster, but implemented as logical distributed capacity in a vSphere Resource Pool. You don’t need to add or remove physical nodes to increase or decrease the VCH capacity, you simply re-configure its resource limits and let vSphere clustering and DRS (Distributed Resource Scheduler) handle the details.

The biggest benefit of VIC is that it helps to draw a clear line between the infrastructure provider (IT admin) and the consumer (developer/ops). The consumer wins because they don’t have deal with managing container hosts, patching, configuring, etc. The provider wins because they can leverage the operational model they are already using today (including NSX and VSAN).

Developers will continue to develop dockers and IT admin will keep managing VMs. The best of both worlds.

It also can be combined with other enterprise tool to manage the Enterprise environment, such as vRealize Operations, vRealize Log Insight, Virtual SAN, VMware NSX, vRealize Automations.

In this post, I will utilise these technologies from VMware:

  • vSphere ESXi 6 U2 as the number one, well-known and stable production grade Virtualisation Technology.
  • vCenter 6 U2 as the Virtualisation central management and operation tool.
  • vSphere Integrated Containers as the Enterprise Production Ready container runtime for vSphere, allowing developers familiar with Docker to develop in containers and deploy them alongside traditional VM-based workloads on vSphere clusters. Download from here: The vSphere Integrated Containers Engine
  • VMware Admiral as the Container Management platform for deploying and managing container based applications. Provides a UI for developers and app teams to provision and manage containers, including retrieving stats and info about container instances. Cloud administrators will be able to manage container hosts and apply governance to its usage, including capacity quotas and approval workflows. Download from here: Harbor
  • VMware Harbor as an enterprise-class registry server that stores and distributes Docker images. Have a UI and functionalities usually required by an enterprise, such as security, identity, replication, and management. Download from here: Admiral

This is the diagram block for those components:

As you can see in the diagram above vSphere Integrated Containers is comprised of three main components, all of which are available as open source on github. With these three capabilities, vSphere Integrated Containers will enable VMware customers to deliver a production-ready container solution to their developers and app teams.

 

*to be continued in part 2.

Kind Regards,
Doddi Priyambodo

Running your First Cloud Native Applications using Docker Container in Mac

As previous post, I will elaborate about Cloud Native Applications. But before that, I will post some basic concepts about Docker as the Container technology for Cloud Native Applications approach.

Docker is an open platform for developing, shipping, and running applications. Docker enables you to separate your applications from your infrastructure so you can deliver software quickly. With Docker, you can manage your infrastructure in the same ways you manage your applications. By taking advantage of Docker’s methodologies for shipping, testing, and deploying code quickly, you can significantly reduce the delay between writing code and running it in production.

If you are still confused about description of Docker, Microservices, Cloud Native Applications technology means. You can read it in here: http://bicarait.com/2016/05/31/microservices-cloud-native-applications/ 

In this post, I will start with the basic on how to run your first application in Docker that will be provisioned in your Mac laptop. Then, I will do that also in vSphere Integrated Container and also VMware Photon Platform.


Let’s Start the first Chapter: INSTALLATION 

  1. Download your Docker Engine from this URL (stable version): Get Docker for Mac (stable)
  2. Actually there are two approach to run docker on your Mac. The 1st one is to utilise Docker for Mac (which we will do this), and the second one is to utilise Docker Toolbox. The difference is in Docker for Mac approach, we will utilise HyperKit as lightweight virtualisation technology to run the container. Docker Toolbox will utilise Virtualbox as the virtualisation technology.
  3. Actually you can run both Docker for Mac and Docker Toolbox approach at the same time in your MacOS, but there are several things that you need to do, such as create different environment (set and unset command). I will not elaborate that in this post.
  4. Assume that your machine is empty for Docker engine.Docker Tutorial
  5. Install and Run Docker. Double click Docker.img that you have downloaded earlier to start the installation.screen-shot-2016-10-31-at-15-29-46
  6. Check Docker version that is now running on your Mac after the installation is completed.screen-shot-2016-10-31-at-15-34-06
  7. Let’s start with your basic application. Let’s do nginx web server using docker.
  8. Check your http://localhost first to check the status.screen-shot-2016-10-31-at-15-54-28
  9. Basically, docker will try to run the source of your application locally. But if docker can not find it, then it will search through the public repository (default configuration is docker hub).screen-shot-2016-10-31-at-15-55-21
  10. Check your http://localhost now to check the status.screen-shot-2016-10-31-at-15-56-03
  11.  Check the status of the docker using  docker ps command. If you want to stop the web server, do docker stop webserver and start the web by docker start webserver
  12. If you want to stop and remove the container, use the command docker rm -f webserver. If you want to delete the local images do the command docker rmi nginx. But before that, you can list the local images using docker images.screen-shot-2016-10-31-at-16-00-14
  13. If you want to use another docker repository other than https://hub.docker.com or do a file sharing from your Mac to your docker engine, you can also configure that in the Docker for Mac menu.screen-shot-2016-10-31-at-16-17-40

Let’s Continue with the second Chapter: BOARDING YOUR APPS 

For this example we will utilise Docker Compose to run WordPress in an isolated environment. Compose is a docker tool for running multi containers environment. We will create a compose file, and then execute the YAML file using docker-compose command.

  1. Create a directory for the project in your Mac.
  2. screen-shot-2016-11-01-at-18-51-10Create a docker compose file. This will include wordpress and mysql to create a simple blog website.screen-shot-2016-11-01-at-18-53-49
  3. Now, build the project using the command $ docker-compose up -d
  4. screen-shot-2016-11-01-at-18-56-35Check whether the images already installed and run. Using docker images and docker ps command.
  5. screen-shot-2016-11-01-at-19-02-49Finally, test to open the wordpress in your browser. Because we put the configuration in port 8000, then we will open http://localhost:8000
  6. Do the installations of wordpress using the UI wizard, then finally open the created site.screen-shot-2016-11-01-at-19-01-32

 

Kind Regards,
Doddi Priyambodo

VMware Photon Platform or vSphere Integrated Container

Cloud Native Applications implementation using container technology is hardly to ignore if you want to keep up with this culture of agile and fast innovations. VMware have two approaches to support for this initiative. Either to use vSphere Integrated Container approach or VMware Photon Platform approach.

So, what are the differences? In Summary:

  • If you want to run both containerized and traditional workloads in production side by side on your existing infrastructure, VIC is the ideal choice. VIC extends all the enterprise capabilities of vSphere without requiring additional investment in retooling or re-architecting your existing infrastructure.
  • If you are looking at building an on-prem, green field infrastructure stack for only running containerized workloads, and also would like a highly available and scalable control plane, an API-driven, automated DevOps environment, plus multi-tenancy for creation and isolation resources, Photon Platform is the way to go.

In this couple of weeks, I will elaborate more about this cloud native applications. Please wait for my next posts.

So, these are the plan:
1. Run Docker Apps in the laptop (for my case, I will use Mac)
We will utilise: Mac OS, Docker, Swarm.
2. Run Docker Apps in vSphere Integrated Container
We will utilise: VMware vSphere, vCenter, Photon OS, Harbor, Admiral.
3. Run Docker Apps in VMware Photon Platform
We will utilise: VMware vSphere, Photon Controller, Photon OS, Kubernetes

 

Kind Regards,
Doddi Priyambodo

Physical CPU (pCPU) and Virtual CPU (vCPU) Ratio in VMware vSphere ESXi Environment

I have some testings couple of times about this. In a Business Critical Applications, Telco Workloads Applications (Network Function Virtualisation (NFV)), or High CPU intensive applications (without high up and down intensity of CPU workloads), it is always recommended to do dimensioning of 1 vCPU compare to 1 pCPU. Regardless we have the performance benefit from Hyperthread technology around 25% because of the scheduling enhancement from intel processor.

For IT workloads (such as email, web apps, normal apps, etc) we can give better ratio such as 1 pCPU to 4 vCPU or even 1:10 or I also see some 1:20 of the production environments. Due to the VMs will not burst at the same time with a stable and long transactions per second.

These are some tests that I have for Network Function Virtualisation platform, we are pushing one of Telco workloads applications (messages) using Spirent as performance load tester to our VNF (telco VM) which run on the intel servers.

Known Fact for Host and VM during the Test:

  • Configuration of the Host = 20 cores x 2.297 GHz = 45,940 MHz
  • Configuration of the VM = 10 vCPU x 2.297 GHz = 22,297 MHz
  • Only 1 VM is powered on in the host (for testing purpose only to avoid contention)

Observation of Host CPU performance:

  • Max Host during Test Performance (Hz)= 12,992 MHz of total 45,940 MHz
  • Max Host during Test Performance (%)= 28.27 % of total 45,940 MHz

Observation of VM CPU performance:

  • Max VM during Test Performance (Hz)= 12,367 MHz of total 22,297 MHz
  • Max VM during Test Performance (%)= 53.83 % of total 22,297 MHz

Conclusion:

  • Percentage calculation is the same result as MHz calculation. Means, if we calculate percentage usage with total MHz then the result will be MHz usage.
  • CPU clock speed that will be needed by VNF vendor can be calculated based on MHz or percentage calculation, as long as the functionality is considered as apple to apple comparison (need to consider the number of modules/functionality).
  • From performance wise observation, this will also give better view that for NFV workloads, 1 to 1 mapping dimensioning is reflected between vCPU and pCPU —> 10 vCPU is almost the same as 10 pCPU (from MHz calculations usage scenario).

Notes:
Physical CPU is physical cores that is resides in the servers. Virtual CPU is logical cores that is resides in the VMs (can benefit the hyper thread technology).

 

Kind Regards,
Doddi Priyambodo

Why Smaller vCPU is better than Bigger vCPU in a fully probable contention environment

In VMware vSphere environment, why Smaller vCPU is better than Bigger vCPU (if the workloads only require few vCPU) in a fully probable contention environment?

To explain this further let’s take an example of a four pCPU host that has four VMs, three with 1 vCPU and one with 4 vCPUs. At best only the three single vCPU VMs can be scheduled concurrently. In such an instance the 4 vCPU VM would have to wait for all four pCPUs to be idle. In this example the excess vCPUs actually impose scheduling constraints and consequently degrade the VM’s overall performance, typically indicated by low CPU utilization but a high CPU Ready figure.

So, always start with smaller vCPU and then add extra vCPU later on if needed based on your observation about the workload.

This reference post also share a very good description why too many vCPU will give poor performance to your Virtual Machine: http://www.gabesvirtualworld.com/how-too-many-vcpus-can-negatively-affect-your-performance/

Conclusion: “Right Size Your VMs!”

 

Kind Regards,
Doddi Priyambodo

Why do we need to Virtualize our Oracle Database

Usually customer would like to expand the benefits that they already achieved using virtualization (financial, business and operational benefits of virtualization within its operating environment) to another level. For example to Business Critical Applications such as Oracle Database, thereby reaping the many benefits and advantages through its adoption of this infrastructure.

Customer aims to achieve the following benefits:

  • Effectively utilise datacenter resources, as in traditional physical servers a lot of database server only utilize 30% of the resources.
  • Maximise availability of the Oracle environment at lower cost, as virtualization can give another layer of high availability.
  • Rapidly deploy Oracle database servers for development, testing & production, as virtualization can have templates and automation.
  • Maximise uptime during planned maintenance, as virtualization can give the ability to move database to another machine without any downtime for the workload.
  • Minimise planned and unplanned downtime, as virtualization can give better disaster recovery avoidance and disaster recovery actions.
  • Automated testing and failover of Oracle datacenter environments for disaster recovery and business continuity.
  • Achieve IT Compliance, as we have better monitoring systems, audit mechanism, policy enforcement, and asset managements.
  • Minimise Oracle datacenter costs for floor space, energy, cooling, hardware and labour, as some physical servers can be consolidated into just several physical servers. This will give customer a better TCO/ROI compare to physical servers approach.

 

Kind Regards,
Doddi Priyambodo

 

 

Update sequence for vSphere 6.0 and its compatible VMware products

Following our technical discussion regarding upgrade VMware environments, actually I already wrote about this topic in different thread  in this blog. But, I would like to emphasise again by using another KB from VMware. VMware has made available certain releases to address critical issues and architectural changes for several products to allow for continued interoperability:

  • vCloud Connector (vCC)
  • vCloud Director (vCD)
  • vCloud Networking and Security (VCNS, formerly vShield Manager)
  • VMware Horizon View
  • VMware NSX for vSphere (NSX Manager)
  • vCenter Operations Manager (vCOPs)
  • vCenter Server / vCenter Server Appliance
  • vCenter Infrastructure Navigator (VIN)
  • vCenter Site Recovery Manager (SRM)
  • vCenter Update Manager (VUM)
  • vRealize Automation Center (vRA, formerly known as vCloud Automation Center)
  • vRealize Automation Application Services (vRAS, formerly vSphere AppDirector)
  • vRealize Business, IT Cost Management (ITBM, formerly VMware IT Business Management)
  • vRealize Configuration Manager (VCM, formerly vCenter Configuration Manager)
  • vRealize Hyperic
  • vRealize Log Insight (vRLI)
  • vRealize Operations Manager (vROPs, formerly known as vCenter Operations Manager, vCOPs)
  • vRealize Orchestrator (vRO, formerly vCenter Orchestrator)
  • vSphere Big Data Extension (BDE)
  • vSphere Data Protection (VDP)
  • vSphere Replication (VR)
  • vSphere ESXi
  • vShield Edge / NSX Edge
  • vShield App / NSX Logical Firewall (NSX LFw)
  • vShield Endpoint / NSX Guest Introspection and Data Security (NSX Guest IDS)
This article only encompasses environments running vSphere and/or vCloud Suite 6.0 and VMware products compatible with vSphere 6.0.

In an environment with vSphere 6.0 and its compatible VMware products, perform the update sequence described in the Supported Update Sequence table.

Supported Update Sequence

Continue reading Update sequence for vSphere 6.0 and its compatible VMware products

VMware vSphere® Metro Storage Cluster Recommended Practices for VMware vSphere 6.0

Some of my customers ask about Metro Storage Cluster configuration for VMware Deployment to achieve better availability of their precious data. There is a very good resource from Duncan Epping (one of VMware most respectful technologist). One of the topic is the Requirement and Constraints from VMware technology perspective. Well, this is the explanation taken from the whitepaper.

Technical Requirements and Constraints

Due to the technical constraints of an online migration of VMs, the following specific requirements, which are listed in the VMware Compatibility Guide, must be met prior to consideration of a stretched cluster implementation:

  • Storage connectivity using Fibre Channel, iSCSI, NFS, and FCoE is supported.
  • The maximum supported network latency between sites for the VMware ESXiTM management networks is 10ms round-trip time (RTT).
  • vSphere vMotion, and vSphere Storage vMotion, supports a maximum of 150ms latency as of vSphere 6.0, but this is not intended for stretched clustering usage.
  • The maximum supported latency for synchronous storage replication links is 10ms RTT. Refer to documentation from the storage vendor because the maximum tolerated latency is lower in most cases. The most commonly supported maximum RTT is 5ms.
  • The ESXi vSphere vMotion network has a redundant network link minimum of 250Mbps.The storage requirements are slightly more complex. A vSphere Metro Storage Cluster requires what is in effect a single storage subsystem that spans both sites. In this design, a given datastore must be accessible—that is, be able to be read and be written to—simultaneously from both sites. Further, when problems occur, the ESXi hosts must be able to continue to access datastores from either array transparently and with no impact to ongoing storage operations.

Reference:
Download the complete document from here: vmware-vsphere-metro-storage-cluster-recommended-practices-white-paper (http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-vsphere-metro-storage-cluster-recommended-practices-white-paper.pdf)

 

Kind Regards,
Doddi Priyambodo

Description about My VMware Home Lab in MacBook Pro

I just want to write this, as a personal note for me. Since I always forget when someone ask me this question about my Personal VMware Home Lab that I used to do some researches on-premise.

As described earlier in this post: http://bicarait.com/2015/09/12/penjelasan-mengenai-my-computer-home-lab-untuk-vmware-technology/
Currently I am adding another Home Lab for my research and demo to VMware customers.

MacBook Pro Retina 15-inch, OS X El Capitan (10.11.6), Quad Core 2.5 GHz Intel i7, 16 GB Memory, NVIDIA GeForce GT750M 2GB, 1 TB Flash Storage.

Detail Components:

  • I am using VMware Fusion Professional Version 8.1.1 to create Nested Virtualisation.
  • Control Server is using CentOS Linux 7 (control01.lab.bicarait.com)
    Function: NTP (ntpd), DNS (bind), LDAP (openldap), DHCP (dhcpd)
    IP: 172.16.159.142
    Username: root, Password: VMware1!
  • Shared Storage is using Openfiler 2.6 (storage01.lab.bicarait.com)
    Access: https://172.16.159.139:446/
    Username: openfiler, Password: password
    iSCSI: iqn.2006-01.com.openfiler:tsn.a7cd1aac2554 – “fusiondisk (/mnt/fusiondisk/)” using volume name “fusioniscsi1” size 100 GB – /dev/fusiondisk/fusioniscsi1 – iSCSI target: 172.16.159.139 port 3260 – datastore: ds_fusion_01
  • Virtualisation for Management Cluster is using ESXi 6.0 U2 (esxi01.lab.bicarait.com)
    IP: 172.16.159.141 (vmkernel management)
    Username: root, Password: VMware1!
  • Virtualisation for Payload Cluster is using ESXi 6.0 U2 (esxi02.lab.bicarait.com & esxi03.lab.bicarait.com)
    IP: 172.16.159.151 & 172.16.159.152 (vmkernel management)
    Username: root, Password: VMware1!
  • vCenter is using vCenter Appliance 6.0 U2 (vcsa01.lab.bicarait.com)
    IP: https://172.16.159.150/vsphere-client
    Username: administrator@vsphere.local, Password: VMware1!
  • Virtual Machines to Play with:
    PhotonVM01 – IP:  DHCP – Username: root, Password: VMware1!

This is the screenshot of my fusion environment:

screen-shot-2016-11-03-at-15-32-42

screen-shot-2016-11-04-at-15-11-52

 

Kind Regards,
Doddi Priyambodo

Kebutuhan Minimum dari VMware vCenter Appliance 6.x

I know that you can find this requirements in the Knowledge Based, I just want to write this again to remind me. Because I got a lot of this question from my customer.

Resource
Requirement
Disk storage on the host machine
Embedded Platform Services Controller:
  • Tiny: 120GB
  • Small: 150GB
  • Medium: 300GB
  • Large: 450GB
External Platform Services Controller:
  • Tiny: 86GB
  • Small: 108GB
  • Medium: 220GB
  • Large: 280GB
External Platform Services Controller Appliance:
  • Tiny: 30GB
  • Small: 30GB
  • Medium: 30GB
  • Large: 30GB
Memory in the vCenter Server Appliance

Platform Services Controller Only: 2GB Ram

All components on one Appliance.

  • Tiny: 8GB RAM
  • Small: 16GB RAM
  • Medium: 24GB RAM
  • Large: 32GB RAM
CPUs in the vCenter Server Appliance

Platform Services Controller Only: 2 CPUs

All components on one Appliance.

  • Tiny: 2 CPUs
  • Small: 4 CPUs
  • Medium: 8 CPUs
  • Large: 16 CPUs
Notes:
  • Tiny Environment (up to 10 Hosts, 100 Virtual Machines)
  • Small Environment (up to 100 Hosts, 1,000 Virtual Machines)
  • Medium Environment (up to 400 Hosts, 4,000 Virtual Machines)
  • Large Environment (up to 1,000 Hosts, 10,000 Virtual Machines)