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
- Download your Docker Engine from this URL (stable version): Get Docker for Mac (stable)
- 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.
- 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.
- Assume that your machine is empty for Docker engine.
- Install and Run Docker. Double click Docker.img that you have downloaded earlier to start the installation.
- Check Docker version that is now running on your Mac after the installation is completed.
- Let’s start with your basic application. Let’s do nginx web server using docker.
- Check your http://localhost first to check the status.
- 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).
- Check your http://localhost now to check the status.
- 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
- 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
- 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.
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.
- Create a directory for the project in your Mac.
- Create a docker compose file. This will include wordpress and mysql to create a simple blog website.
- Now, build the project using the command $ docker-compose up -d
- Check whether the images already installed and run. Using docker images and docker ps command.
- Finally, test to open the wordpress in your browser. Because we put the configuration in port 8000, then we will open http://localhost:8000
- Do the installations of wordpress using the UI wizard, then finally open the created site.
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
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
- 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).
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).
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!”
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.
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