In the first post of this series you could learn something about the basics, advantages and differentiators of Open Telekom Cloud. (You should check out the post before you follow up on this one if not done yet already.) In this continuation I move on with details on how you could make VMs work well on Open Telekom Cloud. The general questions I want to provide answers for remain the same for this part as well:

• Do you wonder how to make use of T-Systems’  Public Cloud (IaaS - Infrastructure as a Service) offering Open Telekom Cloud for your future workloads? Do you wonder as well how you could migrate your existing workloads from another infrastructure like AWS to Open Telekom Cloud?

And just to remember before I proceed with the fun stuff: With this series of posts I do explicitly focus on the general technical considerations to make applications work well on Open Telekom Cloud and take advantage of its benefits. Every cloud adoption project will involve several other phases and implications like analyzing business requirements, efforts to adopt an application that it works well on a Public Cloud, organizational changes and of course cost. All these aspects can be individual and complex and thus will not be touched be me in this blog.

Within this part of this guiding blog series I will first describe the structural elements of the Open Telekom Cloud, what they are, for what they are used and how they fit together. Despite that you will get to read more about OS images, either the public images which are already available on the cloud or own images, that can be uploaded to the cloud.

The elements of the Open Telekom Cloud can be broken down to basically five different building blocks: Compute, Storage, Network, Security and Management. Let’s look at these elements in detail:

1. Compute

An Elastic Cloud Server (ECS) is a computing server that consists of CPUs, memory, images, and Elastic Volume Service (EVS) disks and allows on-demand allocation and elastic scaling. The ECS integrates Virtual Private Cloud (VPC), virtual firewall, and multi-data-copy capabilities to build up an efficient, reliable, and secure computing environment to ensure that your services are running stable and without any interruption. The self-service feature of the ECS allows you to create an ECS by yourself. You are required to pick only a predefined flavor with the matching amount of vCPU-memory image specifications, and login authentication mode. Then, the ECS you requested is allocated within the minimum time required. In addition, you can modify ECS specifications based on your requirements at any time.

Auto-scaling is an event-driven engine that allows automatic, horizontal scaling of EVS instances. To enable Auto-Scaling for a specific use case, four components needs to be defined:

• Auto-Scaling Configuration (Which Image to use?)
• Auto-Scaling Trigger & Actions (What to do when?)
• Elastic Load Balancer (To distribute the traffic)
• Auto-Scaling Group (The combination of the above + basic settings)

The Auto-Scaling configuration describes which image should be deployed once the trigger is hit. This includes the image (either a private or public image) as well as the instance type of the ECS. Please note, that it does not include a network configuration yet - this is done in the Auto-Scaling Set.

For a minimum configuration two trigger points are needed - one to scale-out in cases of high load, one to scale-in when the load lowers. The triggers can be set on CPU, Memory and Network usage bus also be scheduled once or on a regular basis. The trigger action is then to either deploy or reduce a certain number of ECS instances or scale to a specified value.

More or less self-explanatory is the need for a Load Balancer. As Auto-Scaling it the mechanism to utilize horizontal scaling the incoming load/traffic needs to be distributed to the available number of instances. To achieve exactly that effect Elastic Load Balancer is available in Open Telekom Cloud. Used in combination with the Auto Scaling Services newly deployed nodes are even automatically added to the ELB configuration as backend servers.

The Auto-Scaling Group brings the above explained components together and defines the proper environment. This includes foremost the minimum as well as maximum number of instances the specific Auto-Scaling Group may reach. In addition the needed networks and security groups are specified to deploy the ECS instances.

2. Storage and Backups

The Open Telekom Cloud offers a S3-compatible Object Storage Service, where users can store file-based data. The Object Storage is accessible through a HTTP / HTTPS / S3 interface. Object Storage is the only service on the Open Telekom Cloud that can be used stand-alone and does not require a ECS instance. It offers a wide variety of extra attributes that can be defined such as Access Control Lists, Versioning, special functions for static website hosting or black-/white lists for URLs.

Block Storage is available for the ECS as either a system or data disk. It comes in three different flavors of different I/O characteristics: "Common I/O", "High I/O" and "Ultra-High I/O" which are backed up by SATA, SAS or SSD disks. For a normal ECS instance a system disk and up to 10 data disks can be attached.

Through the Volume Backup Service a snapshot of a Elastic Volume can be created. This snapshot is crash-consistent to the current state of the ECS instance volume. From this snapshot either a new volume can be deployed or a restore of the original disk can be triggered.

3. Network

The Virtual Private Cloud (VPC) is the dedicated network environment each user has on Open Telekom Cloud. It is completely isolated from other VPCs, communication between VPCs can only be done through the Internet.  A VPC contains all network definitions, Elastic (Public) IP addresses, Security Groups and load balancing.

As in tradition networks within Open Telekom Cloud and the VPC custom subnets can be created to separate different workloads and ECS instances from each other. With different subnets also the creation of multi-tiers applications or DMZ scenarios are possible to be created. A subnet is always located in one Availability Zone, communication between subnets is possible if it is allowed by the security group.

An Elastic IP address is a public IPv4 address. This address is always connected to a dedicated bandwidth which only applies to outgoing traffic. Incoming traffic is not limited by the bandwidth.

Security Groups are the equivalent of a firewall for each ECS instance running on the Open Telekom Cloud. Rules to allow traffic either for inbound or outbound traffic can be added. Be aware that the default ANY:ANY rule does only apply to the current security group and not all sources. To achieve that a rule with source 0.0.0.0 is needed. To put this in other words - every machine within the same security group has full access to each other unless the default security group is modified.

The Elastic Load Balancer is available to distribute traffic amongst several ECS instances. Several distribution algorithms to distribute the traffic are available, also different check methods for the availability of the server may be selected.

4. Security

The Anti-DDoS service defends against “Distributed Denial-of-Service (DDoS)”-attacks initiated at ISO/OSI-layers 4 through 7. This service protects instances from various kinds of DDoS attacks, such as CC, SYN flood, and UDP flood. The service allows the setting of desired bandwidth, thresholds and access control parameters. In addition dedicated reports and alarming are available.

5. Management

The Cloud Eye Service is the monitoring service of the Open Telekom Cloud. It can be used to monitor different usage parameters like CPU, RAM, Disk or network utilization of ECS instances or network elements like Elastic IPs or Elastic Load Balancer. Based upon threshold values it is also possible to configure alarming rules. Alarming is possible to either an Email address or per SMS to a mobile phone.

How we are going to build our public images within our image factory has been described in a post by Daniela Ebert already. More details about the image factory and the usage of the build public images build where can you find here: https://imagefactory.otc.t-systems.com/. So let me explain you how you can make use of your own images on Open Telekom Cloud in the next step:

The Open Telekom Cloud allows the user to bring their own images and run them as virtual machines. The registration is done in two easy steps:

• uploading the image to the Object Storage Service and
• registering it in the Image Management Service.

As the underlying platform is relying on XEN as Hypervisor, some additional drivers may be needed - depending on the OS type and release - to enable all functions of the platform. Private images, regardless if created through an ECS instance or an image file, are only visible to the local user and nobody else on the platform.

In a first step the image needs to be uploaded to the Object Storage. For access to the Object Storage please refer to the according documentation. For easier management it is recommended to create a separate folder where the images are uploaded to. For images larger than 5 GB multi-part uploads need to be enabled to successfully upload to the platform. To then register the image the Image Management Service on the self-service portal needs to be used. Through the "Create Private Image" Button the dialog for registration is opened. Source can then be either an already installed ECS instance (which needs to be shut down) or a image file from Object Storage. Select the proper image file, a suitable name, the OS type & release and a size for the system disk. This disk size will then be pre-selected when a machine with this image is deployed.  Once the job is submitted, the Open Telekom Cloud will convert the uploaded image file from Object Storage and store it for further usage in the Glance service.

As described above it is also possible to create private images from a ECS instance. This gives the user the possibility to configure a machine to suit his needs and install all needed applications. This ready-made ECS can then be converted to a private image that is being used as basis for further deployments. This is especially useful for the Auto-Scaling Service, where instances with a running application need to be deployed.

While the virtualization layer provides emulated hardware, which is modeling the real hardware, better performance can be achieved by providing a higher abstraction for the interfaces. Driver specifically created for the hypervisor are called paravirtualized drivers. Open Telekom Cloud uses a variant of Xen as hypervisor -- the I/O performance is greatly enhanced by using Xen paravirtualized drivers. For recent Linux distributions, these drivers are easily available -- starting with the Linux Kernel 3.0, the so-called pv_ops Xen drivers work well. For distributions with older kernels, drivers can be compiled using the source from the uvp-tools package. There is a project in OpenBuildService, where sources (under the GNU GPL v2 license) and binaries in form of kernel module packages (KMPs/kmods) for a number of distributions are available. For openSUSE (up to 42.1) and SUSE Linux Enterprise Server (SLES -- up to SLES12 SP1), the pv_ops drivers are not enabled. Instead the drivers from SUSE's xen-kmp should be included in the image. This has been done for all the preloaded images. The Windows images have the Xen drivers included as well.

Open Telekom Cloud provides additional functionality by inserting an agent, uvp-monitor, into the operating system. This agent feeds information to the host to allow the host to collect monitoring data. It also supports operations such as soft shutdown, snapshots and live migration. uvp-monitor for Linux has also been released under the terms of the GNU GPL and is available in source form and as packages for various distribution in the Open Telekom Cloud project in OpenBuildService. The preloaded images already contain uvp-monitor -- both Windows and Linux images. The use of uvp-monitor on Linux is highly recommended -- for Windows it is a precondition to have a supportable Operating System.

Using the web interface (“service console”) to quickly set up an environment is certainly a big step forward in terms of agility if you previously had to order VMs or physical servers from your internal IT department How to perform this even quicker and automated via the APIs of  the Open Telekom Cloud with APIs has been described already in this post.

In about a week I’m going to share with you more about the usage of Open Telekom Cloud for test and development environments.

Open Telekom Cloud Documentation Center 
More Open Telekom Blog blog posts