VMware Cloud Products Survey (Slides)

Regarding VMware vCloud Suite components, VMware terminology can be confusing


This presentation tries to clarify some VMware component names and analyse VMware vRealize
Operations in-depth

The vCloud suite includes almost all VMware products, including:
○ Hypervisor: vSphere (ESXi + vCenter )
ESXi: Single-machine Hypervisor 
vCenter : Handles multiple ESXi’s
● Handles vMotion, High Availalability, Load Balancing
○ vCenter Site Recovery Manager 
■ Policy-based disaster recovery and testing for all virtualized applications
Full presentation at:

Preview:

Screen Shot 08-25-16 at 06.25 PM.PNG

Hagia Sophia, Istanbul

Containers vs Hypervisors (Overview)

Containers seem like an interesting technology for many virtualization and cloud scenarios, specially for hosting providers looking to support more virtual machines or service instances in a physical host.

These are the main differences and advantages between containers and hypervisors

  • Physical machine resource usage and scheduling works better than in a Hypervisor because there is only one kernel copy.
    • Same kernel serving all containers
      • sliglthly different kernel versions can be used in the containers
    • OS virtualization instead of physical hardware virtualization
    • Only Linux is supported
  • Better for overcommiting than Hypervisors
    • More containers in a single physisical host
      • less OS copies running
      • More profitable for companies serving hosted applications (SaaS or PaaS)
    • Faster memory and CPU rescheduling from machines consuming resources guaranteed for other machines
      • faster and more transparent than “ballooning” in VMware
      • physical address space is shared by all the containers and handled by a single kernel
        • on a Hypervisor you get one more layer
  • https://coreos.com/
    • Minimal Linux distribution compatible with Containers
    • “CoreOS is designed to give you compute capacity that is dynamically scaled and managed, similar to how infrastructure might be managed at large web companies like Google.”
  • Very large companies like Google use containers and no hypervisors.
  • Solaris & AIX also have [incompatible] Container technology.

I think it has some problems, though:

  • “Overcommiting” is bad for real-time applications,  as events can be delayed and accumulate.
    • “James Bottomley” was really honest about this issue: “This is the way to cheat your customers”
  • The lack of “Windows OS” support can also be a problem for some people. It seems that only Linux distributions are supported.

If you can port to Linux and don’t have too many real-time restrictions, it looks promising.

Apache CloudStack – Overview

Apache CloudStack can be used to deploy a full-featured public or private IaaS cloud. You can use it to manage either a small private cloud containing a few VM hosts or a large-scale public cloud spanning several distributed regions and thousands of machines.

CloudStack is compatible with several hypervisors. This means that you can use it to manage an heterogenous network of VM host providers.

Acording to Apache, these are some of the features it provides:

  • Works with hosts running XenServer/XCP, KVM, Hyper-V, and/or VMware ESXi with vSphere
    • BareMetal (via IPMI)
    • Hyper-V
    • KVM
    • LXC
    • vSphere (via vCenter)
    • Xenserver
    • Xen Project
  • Provides a friendly Web-based UI for managing the cloud
  • Provides a native API
  • May provide an Amazon S3/EC2 compatible API (optional)
  • Manages storage for instances running on the hypervisors (primary storage) as well as templates, snapshots, and ISO images (secondary storage)
  • Orchestrates network services from the data link layer (L2) to some application layer (L7) services, such as DHCP, NAT, firewall, VPN, and so on
  • Set up an on-demand elastic cloud computing service.
  • Allow end-users to provision resources

CloudStack consists of the management server and the cloud infrastructure (resources to be managed). Inside the cloud infrastructure, the resources are grouped using the following terminology:

  • Regions: A collection of one or more geographically proximate zones managed by one or more management servers.
  • Zones: Typically, a zone is equivalent to a single datacenter. A zone consists of one or more pods and secondary storage.
  • Pods: A pod is usually a rack, or row of racks that includes a layer-2 switch and one or more clusters.
  • Clusters: A cluster consists of one or more homogenous hosts and primary storage.
  • Host: A single compute node within a cluster; often a hypervisor.
  • Primary Storage: A storage resource typically provided to a single cluster for the actual running of instance disk images. (Zone-wide primary storage is an option, though not typically used.)
  • Secondary Storage: A zone-wide resource which stores disk templates, ISO images, and snapshots.

About the management server:

  • Provides the web interface for both the adminstrator and end user.
  • Provides the API interfaces for both the CloudStack API as well as the EC2 interface.
  • Manages the assignment of guest VMs to a specific compute resource
  • Manages the assignment of public and private IP addresses.
  • Allocates storage during the VM instantiation process.
  • Manages snapshots, disk images (templates), and ISO images.
  • Provides a single point of configuration for your cloud.

Elastic scaling is one of the offered fetaures:

In a basic network, configuring the physical network is fairly straightforward. In most cases, you only need to configure one guest network to carry traffic that is generated by guest VMs. If you use a NetScaler load balancer and enable its elastic IP and elastic load balancing (EIP and ELB) features, you must also configure a network to carry public traffic.

For some hypervisors you can enable automatic elastic scaling, by speciyfing some performance indicator value thresholds.

http://docs.cloudstack.apache.org/en/master/networking/autoscale_without_netscaler.html