Tag: IaaS

Categories
Insights @en

Building a hosted private cloud with the open source cloud computing infrastructure solution openQRM

Companies have recognized the benefits of the flexibility of their IT infrastructure. However, the recent past has reinforced the concern to avoid the path to the public cloud for reasons of data protection and information security. Therefore alternatives need to be evaluated. With a private cloud one is found, if this would not end in high up-front investments in own hardware and software. The middle way is to use a hosted private cloud. This type of cloud is already offered by some providers. However, there is also the possibility to build it up and run themselves. This INSIGHTS report shows how this is possible with the open source cloud computing infrastructure solution openQRM.

Why a Hosted Private Cloud?

Companies are encouraged to create more flexible IT infrastructure to scale their resource requirements depending on the situation. Ideally, the use of a public cloud is meeting these requirements. For this no upfront investments in own hardware and software are necessary. Many companies dread the way into public cloud for reasons of data protection and information security, and look around for an alternative. This is called private cloud. The main advantage of a private cloud is to produce a flexible self-service provisioning of resources for staff and projects, such as in a public cloud, which is not possible by a pure virtualization of the data center infrastructure. However, it should be noted that investments in the IT infrastructure must be made to ensure the virtual resource requirements by a physical foundation for building a private cloud.

Therefore, an appropriate balance needs to be found that allows a flexible resource obtaining for a self-service, but at the same time must not expect any high investment in the own infrastructure components and without to waive a self-determined data protection and security level. This balance exists in hosting a private cloud at an external (web) hoster. The necessary physical servers are rented on a hoster who is responsible for their maintenance. In order to secure any physical resource requirements, appropriate arrangements should be made with the hoster to use the hardware in time. Alternatives include standby server or similar approaches.

On this external server-/storage-infrastructure the cloud infrastructure software is then installed and configured as a virtual hosted private cloud. For example, according to their needs this allows employees to start own servers for software development and freeze and remove them after the project again. For the billing of the used resources, the cloud infrastructure software is responsible, which provides such functions.

openQRM Cloud

Basically, an openQRM Cloud can be used for the construction of a public and private cloud. This completely based on openQRM’s appliance model and offers fully automated deployments that can be requested by cloud users. For this openQRM Cloud supports all the virtualization and storage technologies, which are also supported by openQRM itself. It is also possible to provide physical systems over the openQRM Cloud.

Based on the openQRM Enterprise Cloud Zones, a fully distributed openQRM Cloud infrastructure can also be build. Thus, several separate data centers may be divided into logical areas or the company topology can be hierarchically and logically constructed safely separated. Moreover openQRM Enterprise Cloud Zones integrates a central cloud and multilingual portal including a Google Maps integration, so an interactive overview of all sites and systems is created.

Structure of the reference environment

For the construction of our reference setup a physical server and multiple public IP addresses are required. There are two options for installing openQRM:

  • Recommended: Configuration of a private class C subnet (192.168.xx/255.255.255.0) in which openQRM is operated. openQRM required an additional public IP address for access from the outside.
  • Option: Install openQRM in a virtual machine. In this variant openQRM controls the physical server and receives the virtual machines from the physical host for subsequent operations of the cloud.

For the assignment of public IP addresses cloud NAT can be used in both scenarios. This openQRM Cloud function will translate the IP addresses of the private openQRM Class C network into public addresses. This requires pre-and post-routing rules on the gateway / router using iptables, configured as follows:

  • iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o br0 -j MASQUERADE
  • iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE
  • o More information on pre-and post-routing with iptables can be found at http://www.karlrupp.net/en/computer/nat_tutorial

For the configuration of complex network environments, the IP management plugin is recommended. This enterprise plugin allows to set any network- and IP address configurations for the managed servers. In the openQRM Cloud, it also provides a mapping of networks to cloud users and groups and also supports the automated VLAN management.

In addition, two bridges are needed:

  • One of the public interface with a public IP address.
  • One for the private interface dpe for which DHCP is configured.

The data in the cloud are later stored in the local storage of the physical server. For this purpose, there are two variants:

Recommended:

  • KVM-Storage LVM Deployment (LVM Logical Volume Deployment)
  • Requires one or more dedicated LVM volume group (s) for the virtual machines. For more complex setups a central iSCSI target or a SAN is recommended.

Option:

  • KVM-Storage BF Deployment (blockfile deployment)
  • Create a directory on the Linux server as
    • /var/lib/kvm-storage/storage1
    • /var/lib/kvm-storage/storage2

      • (The storage directories can be set arbitrarily on the plugin configuration.)

  • For more complex setups, a central NAS for the configured mount points should be used.

At the end iptables must be configured according to the rules above and the desired own safety. After that the installation of openQRM follows. Packages for popular Linux distributions are available at http://packages.openqrm.com. After openQRM has been installed and initialized the configuration follows.

Basic configuration of openQRM

The first step after initialization is editing the „/usr/share/openqrm/plugins/dns/etc/openqrm-plugin-dns.conf“, by changing the default value to the own domain.

Configure domain for the private network
# please configure your domain name for the openQRM network here!
OPENQRM_SERVER_DOMAIN=”oqnet.org”

After that we activate and start the plug-ins via the web interface of the openQRM server. The following plugins are absolutely necessary for this:

DNS Plugin

  • Used for the automated management of the DNS service for the openQRM management network.

DHCPD

  • Automatically manages the IP addresses for the openQRM management network.

KVM Storage

  • Integrates the KVM virtualization technology for the local deployment.

Cloud-Plugin

  • Allows the construction of a private and public cloud computing environment with openQRM.

Further additional plugins are recommended:

Collectd

  • A monitoring system including long-term statistics and graphics.

LCMC

  • Integrates the Linux Cluster Management Console to manage the high availability of services.

High-Availability

  • Enables automatic high availability of appliances.

I-do-it (Enterprise Plugin)

  • Provides an automated documentation system (CMDB).

Local server

  • Integrates existing and locally installed server with openQRM.

Nagios 3

  • Automatically monitors systems and services.

NoVNC

  • Provides a remote web console for accessing virtual machines and physical systems.

Puppet

  • Integrates Puppet for a fully automated configuration management and application deployment in openQRM.

SSHterm

  • Allows secure login via a web shell to the openQRM server and integrates resource

Plugins which offer more comfort in the automatic installation of virtual machines as cloud templates are:

Cobbler

  • Integrates cobbler for automated deploying of Linux system in openQRM.

FAI

  • Integrates FAI for the automated provisioning of Linux systems in openQRM.

LinuxCOE

  • Integrates LinuxCOE for the automated provisioning of Linux systems in openQRM.

Opsi

  • Integrates Opsi for the automated provisioning of Windows systems in openQRM.

Clonezilla/local-storage

  • Integrates Clonezilla for the automated provisioning of Linux and Windows systems in openQRM.

Basic configuration of the host function for the virtual machines

Case 1: openQRM is installed directly on the physical system

Next, the host must be configured to provide the virtual machines. For that an appliance type KVM Storage Host is created. This works as follows:

  • Create appliance
    • Base > Appliance > Create
  • Name: e.g. openQRM
  • Select the openQRM server itself as resource
  • Type: KVM Storage Host

This gives openQRM the information that a KVM storage is to be created on this machine.

Case 2: openQRM is installed in a virtual machine running on the physical system

Using the “local server” plugin the physical system is integrated into openQRM. To this the “openQRM-local-server” integration tool is copied from the openQRM server on the system to be integrated, e.g.

scp /usr/share/openqrm/plugins/local-server/bin/openqrm-local-server [ip-address of the physical system]:/tmp/

After that, it is executed on the system to be integrated:

ssh [ip-address of the physical system]: /tmp/openqrm-local-server integrate -u openqrm -p openqrm -q [ip-address of the openQRM server] -i br0 [-s http/https]

(In this example “br0” is the bridge to the openQRM management network.)

The integration via “local server” creates in openQRM automatically:

  • a new resource
  • a new image
  • a new kernel
  • a new appliance from the sub-components above

Next, the appliance of the currently integrated physical system must be configured to provide the virtual machines. For this the appliance is set as type KVM Storage Host. That works as follows:

  • Edit the appliance
    • Base > Appliance > Edit
  • Type: Set KVM Storage Host

This gives openQRM the information that a KVM storage is to be created on this machine.

Basic configuration of the storage function

Now, the basic configuration of the storage follows. For this purpose, a storage object of a desired type is created. This works like this:

  • Create storage
    • Base > Components > Storage > Create
    Case 1, select the resource of the openQRM server
  • Case 2, select the resource of the integrated physical system
  • Name: e.g. KVMStorage001
  • Select deployment type
    • This depends on the selected type at the beginning: KVM-Storage LVM deployment or directory (KVM-Storage BF deployment)

Preparation of virtual machine images

In order to provide virtual machine (VM) later over the cloud portal as part of finished products, an image for a VM must first be prepared. This works as follows:

  • Creating a new virtual machine with a new virtual disk and install an ISO image on it.
    • Plugins > Deployment > LinuxCOE > Create Templates
    • The created images are automatically stored in an ISO pool which each virtual machine within openQRM can access.

Subsequently a base for the master template is created. This serves as a basis to provide users a product over the order process.

  • Create a new appliance
    • Base > Appliance > Create
  • Create a new resource
    • KVM-Storage virtual machine
      • Create a new VM
      • Make settings
      • Select an ISO image
      • Create
    • Select created resource
  • Create a new image
    • Add image as KVM-Storage volume
    • Select KVM-Storage
    • Select volume group on KVM-Storage
    • Add a new logical volume
    • Select an image for the appliance
    • Edit to set a password (The previously chosen password of the ISO is overridden.)
  • Select kernel
    • From the local disk
    • (LAN boot is also possible)
  • Start appliance
    • The automatic installation can now be tracked over VNC.
    • Further adaptations can be done itself.
    • Please consider
      • Misc > Local-Server > Help >Local VMs („Local-Server for local virtual machines “)

Cleaning up

The created appliance can now be stopped and deleted afterwards. The important point was to create an image that can be used as a master template for the cloud.

The created image using the appliance includes the basic operating system which was created from the ISO image.

Configuration of the openQRM Cloud

We have now finished all preparations to start configuring the openQRM cloud. We find the necessary settings at „Plugin > Cloud > Configuration > Main Config“. All parameters which are adapted here have a direct impact on the behavior of the whole cloud.

Basically an openQRM Cloud can be run with basic settings. Depending on the needs and the own specific situation, adaptations can be make. The area “description” in the right column of the table are helpful.

However, there are parameter which are need to consider regardless of the own use case. These are:

Automatic provisioning (auto_provision)

  • Determines if systems are automatically provisioned by the cloud or if an approval of a system administrator is needed.

Provisioning of physical systems (request_physical_systems)

  • This parameter defines if besides virtual machines even physical hosts can be provisioned by the cloud.

Cloning of images (default_clone_on_deploy)

  • By default the cloud rolls out copies (clones) of an image.

High-availability (show_ha_checkbox)

  • Enables to operate the openQRM cloud including the high-availability of the provided resources.

Billing of the used resources (cloud_billing_enabled)

  • openQRM has an extensive billing system to determine own prices for all resources to get a transparent overview of the running costs.

Cloud product manager (cloud_selector)

  • Enables the product manager to provide users various resources over the cloud portal.

Currency for the settlement of resources (cloud_currency)

  • Determines the local currency with which the resources are to be settled.

Exchange ratio for resources in real currency (cloud_1000_ccus)

  • Determines how many 1000 CCUS (Cloud Computing Units) correspond to a previously fixed real currency.

Resource allocation for groups (resource_pooling)

  • Determines from which host an appointed user group receive their virtual machines.

Creating products for the openQRM Cloud

To provide our users the resources over the cloud portal we have to create products first which define the configuration of a virtual machine. The settings for that we find at „Plugin > Cloud > Configuration > Products“.

The “Cloud product management” is used to create various products which users can choose later to build own virtual machines itself over the cloud portal. Products which are available for us are:

  • Number of CPUs
  • Size of local disks
  • Size of RAM
  • Kernel type
  • Number of network interfaces
  • Pre-installed applications
  • Virtualization type
  • If a virtual machine should be high-available

Over the status line by using +/- each product can be activated or deactivated to show or hide it for the user in the cloud portal.

Please note: Products which are deactivated but are still active within a virtual machine continue to be billed.

To create a new CPU product we select the “CPU” tap and define in the area “Define a new CPU product” our wanted parameter.

The first parameter defines how many CPUs (cores), here 64, our product should have. The second parameter determines the value of the product and how many costs occur per hour during its use. In this example, 10 CCUs per hour for 64 CPUs occurs.

With the arrow keys the order on how the single products are displayed in the cloud portal can be determine. The default value is above one.

Please note: In the cloud portal standard profiles in the sizes „small“, „medium“ and „big“ exist. According to the order the profiles are automatically be determined under the respective products. That means that “small” is always the first value, “medium” the second and “big” the third.

openQRM also allows to order virtual machines with pre-configured software stacks. For this openQRM uses Puppet (Plugins > Deployment > Puppet). Thus, for example, it is possible to order the popular LAMP stack.

If we have configured our product portfolio, it’s the user’s turn to order virtual machines. This is done via the cloud portal.

openQRM Cloud-Portal

To create a new virtual machine (VM) we click on the tap “New”. An input mask follows on which we can create our
VM based on the products the administrator has determined and approved in the backend.

We choose the profile “Big” and a LAMP server. Our virtual machine now consists of the following products:

  • Type: KVM-Storage VM
  • RAM: 1 GB
  • CPU: 64 cores
  • Disk: 8 GB
  • NIC: 1

In addition the virtual machine should be “high-available”. This means, if the VM fails, automatically a substitute machine with exactly the same configuration is started to work on with.

For this configuration we will have to pay 35 CCUs per hour. This is equivalent to 0.04 euros per hour or € 0.84 per day or € 26.04 per month.

If we want to order the virtual machine we select “send”.

Below the tap “Orders” we see all current and past orderings we have made with our user. The status “active” in the first column shows that the machine is already started.

Parallel to this we receive an e-mail including the ip-address, a username and a password, we can use to log into the virtual machine.

The tap “Systems” confirms both information and shows further details of the virtual machine. In addition we have the opportunity to change the systems configuration, pause the virtual machine or to restart. Furthermore the login via a web-shell is possible.

If the virtual machine is not needed any more it can be paused. Alternatively it is possible that the administrator disposes this due to an inactivity of the system or at a specific time.

Creating a virtual machine with the „Visual Cloud Designer“

Besides the “ordinary” way of building a virtual machine, the openQRM Cloud portal enables the user to do that conveniently via drag and drop. Here the „Visual Cloud Designer“ helps, which can be find behind the tap „VCD“.

Using the slider on the left below „Cloud Components” it is possible to scroll between the products. Using the mouse allows to assemble the „Cloud Appliance“ (virtual machine) in the middle with the appropriate products.

Our virtual machine „Testosteron“ we assembled in this case with KVM-Storage, Ubuntu 12.04, 64 CPUs, 1024 MB Ram, 8 GB disk, one NIC, and software for a webserver and the high-availability feature.

With one click on “Check Costs”, openQRM tells us that we will pay 0.03 EUR per hour for this configuration.

To start the ordering process for the virtual machine we click “request”. We get the message that openQRM starts rolling out the resource and we will receive further information into our mailbox.

The e-mail includes, as described above, all access data to work with the virtual machine.

In the cloud portal under “systems” we already see the started virtual machine.

Creating a virtual machine with the „Visual Infrastructure Designer“

Besides the provisioning of single virtual machines the openQRM cloud portal also offers the opportunity to provide complete infrastructures consisting of multiple virtual machines and further components, at one click.

Thus, we use the „Visual Infrastructure Designer“. This can be found in the cloud portal behind the tap “VID”.

Using the “VID” it is possible to build and deploy a complete WYSIWYG infrastructure via drag and drop. For this purpose, it is necessary to create ready profiles with pre-configured virtual machines at first, which include for example webserver, router or gateways. These can be deployed afterwards.

Categories
Insights @de

Aufbau einer Hosted Private Cloud mit der Open-Source Cloud Computing Infrastrukturlösung openQRM

Unternehmen haben die Vorteile der Flexibilisierung der eigenen IT-Infrastruktur erkannt. Dennoch hat die jüngste Vergangenheit die Bedenken bestärkt, den Weg in die Public Cloud aus Gründen des Datenschutzes und der Informationssicherheit zu meiden. Es sind daher Alternativen gefragt. Mit der Private Cloud wäre eine gefunden. Wären dazu nicht hohe Vorabinvestitionen in eigene Hard- und Software notwendig. Ein Mittelweg besteht in der Nutzung einer Hosted Private Cloud. Diese Form der Cloud wird mittlerweile von einigen Providern angeboten. Es besteht aber ebenfalls die Möglichkeit, selbst den Aufbau und den Betrieb zu übernehmen. Dieser INSIGHTS Report zeigt, wie dieses mit der Open-Source Cloud Computing Infrastrukturlösung openQRM möglich ist.

Warum eine Hosted Private Cloud?

Unternehmen sind angehalten ihre IT-Infrastruktur zu flexibilisieren, um ihren Ressourcenbedarf je nach Situation zu skalieren. Der Idealfall stellt hierbei die Nutzung einer Public Cloud dar. Dabei sind keine Vorabinvestitionen in eigene Hard- und Software notwendig. Viele Unternehmen scheuen, aus Gründen des Datenschutzes und der Informationssicherheit, jedoch den Weg in die Public Cloud und schauen sich nach einer Alternative um. Diese nennt sich Private Cloud. Der Hauptvorteil einer Private Cloud besteht dabei in der flexiblen Self-Service Bereitstellung von Ressourcen für Mitarbeiter und Projekte wie in einer Public Cloud, die durch eine reine Virtualisierung der Rechenzentrumsinfrastruktur nicht möglich ist. Jedoch ist für den Aufbau einer Private Cloud zu beachten, dass Investitionen in die eigene IT-Infrastruktur geleistet werden müssen, um den virtuellen Ressourcenbedarf durch einen physikalischen Unterbau zu gewährleisten.

Daher muss ein geeigneter Mittelweg gefunden werden, der einen flexiblen Ressourcenbezug über einen Self-Service ermöglicht, aber zugleich keine hohe Investitionskosten in eigene Infrastrukturkomponenten erwartet und ohne auf ein selbst festgelegtes Datenschutz und -sicherheitsniveau verzichten zu müssen. Dieser Mittelweg besteht im Hosting einer Private Cloud bei einem externen (Web)-Hoster. Die notwendigen physikalischen Server werden über einen Hoster angemietet, der für deren Wartung zuständig ist. Um auch den etwaigen physikalischen Ressourcenbedarf zu sichern, sollten mit dem Hoster entsprechende Absprachen getroffen werden, um die Hardware sehr zeitnah nutzen zu können. Mögliche Alternativen wären Standby-Server oder ähnliche Ansätze.

Auf dieser externen Server-/Storage-Infrastruktur wird anschließend die Cloud-Infrastruktursoftware installiert und zu einer virtuellen gehosteten Private Cloud konfiguriert. Diese erlaubt es Mitarbeitern zum Beispiel je nach Bedarf eigene Server für die Softwareentwicklung zu starten, einzufrieren und nach Beendigung des Projekts wieder zu entfernen. Für die Abrechnung der jeweilig genutzten Ressourcen sorgt die Cloud-Infrastruktursoftware, die über solche Funktionen entsprechend verfügen muss.

openQRM Cloud

Grundsätzlich kann eine openQRM Cloud für den Aufbau einer Public als auch Private Cloud genutzt werden. Diese basiert komplett auf openQRMs Appliance Modell und bietet vollständig automatisierte Deployments die von Cloud Nutzern angefragt werden können. Dazu unterstützt eine openQRM Cloud alle Virtualisierungs- und Speichertechnologien, die auch von openQRM selbst unterstützt werden. Es besteht darüber hinaus die Möglichkeit, physikalische Systeme über die openQRM Cloud bereitzustellen.

Auf Basis der openQRM Enterprise Cloud-Zones lässt sich darüber hinaus eine vollständig verteilte openQRM Cloud Infrastruktur aufbauen. Damit können mehrere voneinander getrennte Rechenzentren in logische Bereiche aufgeteilt oder zum Beispiel die Unternehmenstopologie hierarchisch und logisch sicher voneinander getrennt aufgebaut werden. Zudem integriert openQRM Enterprise Cloud-Zones ein zentrales und mehrsprachiges Cloud-Portal inkl. einer Google Maps Integration, wodurch ein interaktiver Überblick über sämtliche Standorte und Systeme entsteht.

Aufbau der Referenzumgebung

Für den Aufbau unseres Referenz-Setups werden ein physikalischer Server und mehrere öffentliche IP-Adressen benötigt. Für die Installation von openQRM bestehen zwei Möglichkeiten:

  • Empfohlen: Ein privates Class C Subnetz (192.168.x.x/255.255.255.0) konfigurieren in welchem openQRM betrieben wird. openQRM benötigt dann zusätzlich eine öffentliche IP-Adresse für den Zugang von außen.
  • Option: openQRM in einer virtuellen Maschine installieren. Bei dieser Variante steuert openQRM den physikalischen Server und bezieht die virtuellen Maschinen für den späteren Betrieb der Cloud von dem physikalischen Host.

Für die Zuordnung der öffentlichen IP Adressen kann in beiden Szenarien Cloud-NAT eingesetzt werden. Diese openQRM Cloud Funktion übersetzt die IP Adressen des privaten openQRM Class C Netzwerk in öffentliche Adressen. Dies erfordert Post- und Pre-Routing Regeln, die auf dem Gateway/Router mittels IPTables wie folgt konfiguriert werden:

Für die Konfiguration komplexer Netzwerkumgebungen ist das IP-Management Plugin zu empfehlen. Dieses Enterprise Plugin erlaubt es beliebige Netzwerk- und IP-Adress-Konfigurationen für die verwalteten Server vorzunehmen. In der openQRM Cloud bietet es zudem eine Zuordnung von Netzwerken zu Cloud Benutzergruppen und unterstützt darüber hinaus das automatisierte VLAN Management.

Weiterhin werden zwei Bridges benötigt:

  • Eine für die öffentliche Schnittstelle mit einer öffentlichen IP-Adresse.
  • Eine für die private Schnittstelle dpe für die DHCP konfiguriert ist.

Die Daten der Cloud werden später auf dem lokalen Speicher des physikalischen Servers gespeichert. Hierfür bieten sich zwei Varianten:

Empfohlen:

  • KVM-Storage LVM Deployment (LVM Logical Volume Deployment)
  • Benötigt eine oder mehrere dedizierte LVM Volume Group(s) für die virtuellen Maschinen. Für komplexere Setups empfiehlt sich ein zentrales iSCSI Target oder ein SAN zu verwenden.

Option:

  • KVM-Storage BF Deployment (Blockfile Deployment)
  • Erstellen eines Verzeichnis auf dem Linux-Server unter z.B.
    • /var/lib/kvm-storage/storage1
    • /var/lib/kvm-storage/storage2

      • (Die Storage Verzeichnisse lassen sich über die Plugin Konfiguration beliebig einstellen)

  • Für komplexere Setups empfiehlt sich ein zentrales NAS für die konfigurierten Mountpoints zu verwenden.

Am Ende muss IPTables entsprechend der oben genannten Regeln und der gewünschten eigenen Sicherheit konfiguriert werden. Im Anschluss erfolgt die Installation von openQRM. Pakete für die gängigen Linux Distributionen liegen unter http://packages.openqrm.com. Nachdem openQRM installiert und initialisiert wurde folgt dessen Konfiguration.

Basis-Konfiguration von openQRM

Der erste Schritt nach der Initialisierung ist das Editieren der “/usr/share/openqrm/plugins/dns/etc/openqrm-plugin-dns.conf”, indem der Standardwert auf die eigene Domain geändert wird.

Domain für das private Netzwerk konfigurieren:
# please configure your domain name for the openQRM network here!
OPENQRM_SERVER_DOMAIN=”oqnet.org”

Es folgt das Aktivieren und Starten der Plugins über die Weboberfläche des openQRM-Servers. Die folgenden Plugins sind dazu zwingend erforderlich:

DNS Plugin

  • Dient der automatisierten Verwaltung des DNS Service für das openQRM Management-Netzwerk.

DHCPD

  • Verwaltet automatisch die IP-Adressen für das openQRM Management-Netzwerk.

KVM Storage

  • Integriert die KVM Virtualisierungstechnologie für das lokale Deployment.

Cloud-Plugin

  • Ermöglicht den Aufbau einer Private und Public Cloud Computing Umgebung mit openQRM.

Zu den weiteren empfohlenen Plugins gehören:

Collectd

  • Ein Monitoring-System inkl. Langzeitstatistiken und Graphiken.

LCMC

  • Integriert die Linux Cluster Management Console zur Verwaltung der Hochverfügbarkeit einzelner Services.

High-Availability

  • Ermöglicht eine automatische Hochverfügbarkeit der Appliances.

I-do-it (Enterprise Plugin)

  • Bietet eine automatische Systemdokumentation (CMDB).

Local server

  • Integriert bestehende und lokal installierte Server mit openQRM.

Nagios 3

  • Überwacht automatisch Systeme und Services.

NoVNC

  • Bietet eine remote Web-Konsole für den Zugriff auf virtuelle Maschinen und physikalische Systeme.

Puppet

  • Integriert Puppet für ein vollständig automatisiertes Konfigurationsmanagement und Applikationsdeployment in openQRM.

SSHterm

  • Ermöglicht die sichere Anmeldung über eine Web-Shell an den openQRM-Server und integrierte Ressourcen.

Zu den Plugins die mehr Komfort bei der automatischen Installation von virtuellen Maschinen als Cloud Templates bieten gehören:

Cobbler

  • Integriert Cobbler für das automatisierte Bereitstellen von Linux System in openQRM.

FAI

  • Integriert FAI für das automatisierte Bereitstellen von Linux System in openQRM.

LinuxCOE

  • Integriert LinuxCOE für das automatisierte Bereitstellen von Linux System in openQRM.

Opsi

  • Integriert Opsi für das automatisierte Bereitstellen von Windows System in openQRM.

Clonezilla/local-storage

  • Integriert Clonezilla für das automatisierte Bereitstellen von Linux und Windows System in openQRM.

Basis-Konfiguration der Host-Funktion für die virtuellen Maschinen

Fall 1: openQRM ist direkt auf dem physikalischen System installiert

Als Nächstes muss der Host konfiguriert werden, um darüber später die virtuellen Maschinen bereitzustellen. Dazu wird eine Appliance vom Typ KVM Storage Host erstellt. Man geht dazu wie folgt vor:

  • Appliance erstellen
    • Base > Appliance > Create
  • Name: z.B. openQRM
  • Als Ressource den openQRM Server selbst auswählen
  • Typ: KVM Storage Host

Dadurch erhält openQRM die Information, dass auf dieser Maschine ein KVM Storage angelegt werden soll.

Fall 2: openQRM ist in einer VM installiert, die auf dem physikalischen System läuft

Mittels des „local-server“ Plugins wird das physikalische System in openQRM integriert. Dazu wird das „openqrm-local-server“ Integrations-Tool vom openQRM Server auf das zu integrierende System kopiert z.B.

scp /usr/share/openqrm/plugins/local-server/bin/openqrm-local-server [IP-Adresse des physikalischen Systems]:/tmp/

Danach wird es auf dem zu integrierenden System ausgeführt:

ssh [IP-Adresse des physikalischen Systems]: /tmp/openqrm-local-server integrate -u openqrm -p openqrm -q [IP-Adresse des openQRM Server] -i br0 [-s http/https]

(in diesem Beispiel ist „br0“ die Bridge zum openQRM Management Netzwerk)

Die Integration mittels „local-server“ erstellt in openQRM automatisch:

  • eine neue Ressource
  • ein neues Image
  • einen neuen Kernel
  • eine neue Appliance aus den obigen Subkomponenten

Als Nächstes muss die Appliance des gerade integrierten physikalischen Systems konfiguriert werden, um darüber später die virtuellen Maschinen bereitzustellen. Dazu wird die Appliance als Typ KVM Storage Host eingestellt. Man geht dazu wie folgt vor:

  • Appliance editieren
    • Base > Appliance > Edit
  • Typ: KVM Storage Host einstellen

Dadurch erhält openQRM die Information, dass auf dieser Maschine ein KVM Storage angelegt werden soll.

Basis-Konfiguration der Storage-Funktion

Nun folgt die grundsätzliche Konfiguration des Storage. Hierzu wird ein Storage Objekt von einem selbst gewünschten Typ erstellt. Dazu geht man wie folgt vor:

  • Storage erstellen
    • Base > Components > Storage > Create
    Im Fall 1, die Ressource des openQRM Servers auswählen
  • Im Fall 2, die Ressource des integrierten physikalischen Systems auswählen
  • Name: z.B. KVMStorage001
  • Deployment-Typ wählen
    • hängt vom zu Beginn gewählten Typ ab: KVM-Storage LVM Deployment oder Verzeichnis (KVM-Storage BF Deployment)

Vorbereitung eines Images für virtuelle Maschinen

Um später über das Cloud-Portal virtuelle Maschinen (VM) als Teil fertiger Produkte bereitzustellen, muss zunächst ein Image für eine VM vorbereitet werden. Das funktioniert wie folgt:

  • Erstellen einer neuen virtuellen Maschine mit einer neuen virtuellen Festplatte und auf dieser ein ISO installieren.
    • Plugins > Deployment > LinuxCOE > Create Templates
    • Die hier erstellten Images werden automatisch in einem ISO-Pool, der für alle virtuellen Maschinen innerhalb von openQRM verfügbar ist, abgelegt.

Anschließend folgt das Erstellen einer Basis für ein Mastertemplate. Dieses dient als Grundlage, um später den Anwendern ein Produkt über die Cloud anhand eines Bestellvorgangs bereitzustellen.

  • Erstellen einer neuen Appliance
    • Base > Appliance > Create
  • Erstellen einer neuen Ressource
    • KVM-Storage Virtual Machine
      • Neue VM anlegen
      • Einstellungen vornehmen
      • ISO Image auswählen
      • Erstellen
    • Erstellte Ressource auswählen
  • Neues Image erstellen
    • Image als KVM-Storage Volume hinzufügen
    • KVM-Storage auswählen
    • Volume Group auf KVM-Storage auswählen
    • Neues Logical Volume hinzufügen
    • Image für die Appliance auswählen
    • Editieren, um damit ein Passwort zu setzen. (Damit wird das zuvor gewählte Passwort des ISO Image überschrieben.)
  • Kernel auswählen
    • von der lokalen Festplatte
    • (LAN Boot wäre ebenfalls möglich)
  • Appliance starten
    • die automatische Installation kann nun über VNC verfolgt werden.
    • Weitere Anpassungen können nun selbst vorgenommen werden.
    • Und folgendes beachten
      • Misc > Local-Server > Help >Local VMs („Local-Server für Lokale Virtuelle Maschinen“)

Aufräumen

Die erstellte Appliance kann nun gestoppt und anschließend gelöscht werden. Entscheidend hier war, dass wir uns ein Image erstellt haben, das für die Cloud als Mastertemplate genutzt werden kann.

Das über die Appliance erstellte Image enthält das Basis Betriebssystem welches aus dem ISO-Image installiert wurde.

Konfiguration der openQRM Cloud

Wir haben nun alle Vorbereitungen abgeschlossen, um mit der Konfiguration der openQRM Cloud zu beginnen. Die Einstellungen dafür finden wir unter „Plugin > Cloud > Configuration > Main Config“. Sämtliche Parameter, die hier angepasst werden, haben einen direkten Einfluss auf das Verhalten der gesamten Cloud.

Grundsätzlich lässt sich eine openQRM Cloud mit den Standardparametern betreiben. Je nach Bedarf und der eigenen speziellen Situation müssen Anpassungen erfolgen. Hilfreich dazu ist der Bereich „Beschreibungen“ in der rechten Spalte der Tabelle.

Es existieren jedoch einzelne Parameter, die unabhängig von dem eigenen Anwendungsfall in Betracht gezogen werden sollten. Dazu gehören:

Automatische Provisionierung (auto_provision)

  • Legt fest, ob Systeme automatisch durch die Cloud bereitgestellt werden oder ob zunächst eine Freigabe durch den Administrator notwendig ist.

Provisionierung physikalischer Systeme (request_physical_systems)

  • Mit diesem Parameter lässt sich definieren, ob neben virtuellen Maschinen auch physikalische Host über die Cloud bereitgestellt werden sollen.

Klonen der Images (default_clone_on_deploy)

  • Die Cloud rollt standardmäßig Kopien (Klone) eines Images aus.

Hochverfügbarkeit (show_ha_checkbox)

  • Ermöglicht den Betrieb der openQRM Cloud inklusive Hochverfügbarkeit der bereitgestellten Ressourcen.

Abrechnung der genutzten Ressourcen (cloud_billing_enabled)

  • openQRM verfügt über ein umfangreiches Abrechnungssystem, mit dem für sämtliche Ressourcen eigene Preise festgelegt werden können, um einen transparenten Überblick zu den laufenden Kosten zu erhalten.

Cloud Produkt Manager (cloud_selector)

  • Aktiviert den Produkt-Manager, mit dem den Nutzern verschiedene Ressourcen über das Cloud-Portal bereitgestellt werden können.

Währung zur Abrechnung der Ressourcen (cloud_currency)

  • Legt die Landeswährung fest, mit der die Ressourcen abgerechnet werden sollen.

Umrechnungsfaktor für Ressourcen in reale Währung (cloud_1000_ccus)

  • Legt fest, wie viel 1000 CCUS (Cloud Computing Units) in einer zuvor festgelegten realen Währung entsprechen sollen.

Ressourcenzuordnung für Gruppen (resource_pooling)

  • Legt fest, von welchem Host eine bestimmte Benutzergruppe ihre virtuellen Maschinen erhalten darf.

Produkte für openQRM Cloud anlegen

Um unseren Nutzern Cloud Ressourcen über das Cloud-Portal bereitzustellen, müssen vorab Produkte ausgewählt werden, welche über die Konfiguration einer virtuellen Maschine bestimmen. Die Einstellungen dafür nehmen wir unter „Plugin > Cloud > Configuration > Products“ vor.

Unter der „Cloud Produkt Verwaltung“ lassen sich verschiedene Produkte erstellen, die später unter dem Cloud-Portal von dem Nutzer eigenständig zu vollständigen virtuellen Maschinen zusammengebaut werden können. Zu den Produkten die uns dabei zur Verfügung stehen gehören:

  • Anzahl der CPUs
  • Größe der lokalen Festplatte
  • Größe des Arbeitsspeichers
  • Der Typ des Kernel
  • Die Anzahl der der Netzwerkkarten
  • Vorinstallierte Applikationen
  • Typ der Virtualisierung
  • Ob eine virtuelle Maschine hochverfügbar sein soll

Über die Statuszeile können mit +/- die jeweiligen Produkte aktiviert bzw. deaktiviert werden und damit dem Nutzer im Cloud-Portal angezeigt oder vor ihm versteckt werden.

Bitte beachten: Produkte die deaktiviert werden, aber noch innerhalb von virtuellen Maschinen aktiv sind, werden weiterhin abgerechnet.

Um nun ein neues CPU Produkt zu erstellen wählen wir den Reiter „CPU“ und bestimmen in dem Bereich „Hinzufügen eines CPU Produkts“ unsere gewünschten Parameter.

Der erste Parameter bestimmt, wie viele CPUs (Kerne), hier 64, unser Produkt haben soll. Über den zweiten Parameter legen wir fest, welchen Wert dieses Produkt hat und wie viele Kosten entsprechend während seiner Nutzung pro Stunde entstehen. In diesem Beispiel entstehen Kosten von 10 CCUs pro Stunde für 64 CPUs.

Anhand der Pfeiltasten lässt sich die Reihenfolge bestimmen, wie die einzelnen Produkte im Cloud-Portal angezeigt werden. Der Default-Wert ist der an obiger Stelle.

Bitte beachten: Im Cloud-Portal existieren Standard-Profile in den Größen „Small“, „Medium“ und „Big“. Die Profile werden automatisch entsprechend der Reihenfolge unter den jeweiligen Produkten bestimmt. Das bedeutet Small nimmt immer den ersten Wert, Medium den Zweiten und Big den Dritten.

openQRM erlaubt es ebenfalls, die virtuellen Maschinen mit vorkonfigurierten Softwarestacks zu bestellen. Dazu greift openQRM auf Puppet (Plugins > Deployment > Puppet) zurück. Damit ist es möglich zum Beispiel den bekannten LAMP-Stack zu bestellen.

Haben wir unsere Produktpalette fertig konfiguriert, ist der Nutzer an der Reihe, sich seine virtuellen Maschinen zu bestellen. Das erfolgt über das Cloud-Portal.

openQRM Cloud-Portal

Für das Erstellen einer neuen virtuellen Maschine (VM) klicken wir im Reiter auf „Neu“. Es
erscheint die Eingabemaske, in der wir unsere VM anhand der Produkte, die der
Administrator im Admin-Backend festgelegt und freigegeben hat, erstellen können.

Wir entscheiden uns für das Profil „Gross“ und einem LAMP-Server. Unsere virtuelle Maschine besteht damit aus den folgenden Produkten:

  • TYP: KVM-Storage VM
  • RAM: 1 GB
  • CPU: 64 Kerne
  • Festplatte: 8 GB
  • Netzwerkkarte: 1

Darüber hinaus soll diese virtuelle Maschine „Hochverfügbar“ sein. Das bedeutet, wenn diese ausfallen sollte, wird automatisch eine Ersatzmaschine mit exakt derselben Konfiguration hochgefahren, mit der man weiterarbeiten kann.

Für diese Konfiguration werden uns Kosten in Höhe von 35 CCUs pro Stunde entstehen. Das entspricht 0,04Euro pro Stunde bzw. 0,84Euro pro Tag oder 26,04Euro pro Monat.

Wollen wir die virtuelle Maschine bestellen, wählen wir „absenden“.

Unter dem Reiter „Aufträge“ sehen wir alle aktuellen und vergangenen Bestellungen, die wir mit unserem Benutzer getätigt haben. Der Status „active“ in der ersten Spalte zeigt, dass die Maschine bereits hochgefahren ist.

Parallel dazu erhalten wir eine E-Mail mit der IP-Adresse, einem Benutzernamen und Passwort, über die wir uns an der virtuellen Maschine anmelden können.

Der Reiter „Systeme“ bestätigt uns beide Informationen noch einmal und zeigt weitere Informationen zu der virtuellen Maschine. Darüber hinaus haben wir die Möglichkeit, Änderungen an der Systemkonfiguration vorzunehmen, die virtuelle Maschine in den Ruhezustand zu setzen oder neu zu starten. Weiterhin ist der Login über eine Web-Shell möglich.

Die virtuelle Maschine kann, wenn sie nicht mehr benötigt wird pausiert werden. Alternativ besteht die Möglichkeit, dass der Administrator dieses zum Beispiel anhand einer Inaktivität des Systems oder zu einer bestimmten Uhrzeit veranlasst.

Virtuelle Maschine mit dem „Visual Cloud Designer“ erstellen

Neben dem „gewöhnlichen“ zusammenbauen einer virtuellen Maschine, ermöglicht das openQRM Cloud-Portal es dem Benutzer, dieses bequem per Drag-and-Drop zu erledigen. Dabei hilft der „Visual Cloud Designer“, der unter dem Reiter „VCD“ zu finden ist.

Mit dem Schieberegler unter „Cloud Components“ lässt sich zwischen den Produkten auf der linken Seite hin und her scrollen. Mit der Maus lässt sich die „Cloud Appliance“ (virtuelle Maschine) in der Mitte mit den entsprechenden Produkten bestücken.

Unsere virtuelle Maschine „Testosteron“ haben wir in diesem Fall also mit einem KVM-Storage, Ubuntu 12.04, 64 CPUs, 1024 MB Ram, 8 GB Festplatte, einer Netzwerkkarte, Software für einen Webserver und mit der Eigenschaft Hochverfügbarkeit ausgestattet.

Mit einen Klick auf „Check Costs“, sagt uns openQRM, dass wir für diese Konfiguration 0,03 EUR pro Stunde bezahlen würden.

Um den Bestellvorgang für die virtuelle Maschine zu starten klicken wir auf „Request“. Wir erhalten die Meldung, dass openQRM mit dem Ausrollen der Ressource beginnt und wir weitere Informationen im Postfach haben.

Die E-Mail enthält wie bereits oben beschrieben, sämtliche Zugangsdaten, um mit der virtuellen Maschine zu arbeiten.

Im Cloud-Portal unter „Systeme“, sehen wir dann auch bereits die gestartete virtuelle Maschine.

Virtuelle Maschine mit dem „Visual Infrastructure Designer“ erstellen

Neben der Bereitstellung einzelner virtueller Maschinen bietet das openQRM Cloud-Portal zudem die Möglichkeit, vollständige Infrastrukturen, bestehend aus mehreren virtuellen Maschinen und weiteren Komponenten, mit einem Klick bereitzustellen.

Dafür greifen wir auf den „Visual Infrastructure Designer“ zurück. Dieser ist im Cloud-Portal unter dem Reiter „VID“ zu finden.

Über den „VID“ lässt sich per Drag and Drop eine vollständige WYSIWYG Infrastruktur zusammenbauen und direkt ausrollen. Hierzu müssen anhand des „VCD“ oder auf normalem Weg jedoch zunächst fertige Profile mit vorkonfigurierten virtuellen Maschinen z.B. Webserver, Router, oder Gateways erstellt werden, die anschließend provisioniert werden können.

Categories
Comment

The cloud computing world is hybrid! Is Dell showing us the right direction?

With a clear cut, Dell said good bye to the public cloud and align its cloud computing strategy with own OpenStack-based private cloud solutions, including a cloud service broker for other public cloud providers. At first the move comes surprising, but makes sense when you take a closer look at Dell, whose recent past and especially the current market situation.

Dell’s new cloud strategy

Instead of having an own public cloud offering on the market, Dell will sell OpenStack-based private clouds on Dell hardware and software in the future. With the recent acquisition of cloud management technology Enstratius customers will also be able to deploy their resources to more than 20 public cloud provider.

With a new “partner ecosystem”, which currently consists of three providers and that is further expanded in the future, integration opportunities between the partner’s public clouds and private clouds of Dell customers will be offered. The current partner network includes Joyent, ZeroLag and ScaleMatrix. All three are rather small names in the infrastructure-as-a-service (IaaS) market.

Further, Dell also strengthens its consulting business to show customers which workloads and processes could flow into the public cloud.

Thanks Enstratius, Dell becomes a cloud broker

A view on the current public cloud IaaS market shows that Dell is right with its strategy change. All current IaaS providers of all sizes to chafe in the fight for market share against industry leader Amazon Web Services. Since their innovative strength is limited compared to Amazon and most of them to limit themselves, with the exception of Google and Microsoft, to the provision of pure infrastructure resources (computing power, storage, etc.), the chances of success are rather low. Moreover, into a price war with Amazon the fewest should get involved. That can quickly backfire.

Rather than dealing with Amazon and other public IaaS providers in the boxing ring, Dell positioned itself on the basis of Boomi, Enstratius and other previous acquisitions as a supportive force for cloud service providers and IT departments and provides them with hardware, software and more added values.

In particular, the purchase of Enstratius was a good move and let Dell become a cloud service broker. Enstratius is a toolset for managing cloud infrastructures, including the provisioning, management and automation of applications for – currently 23 – public and private cloud solutions. It should be mentioned that Enstratius in addition to managing a single cloud infrastructure also allows the operation of multi-cloud environments. For this purpose Enstratius can be used as a software-as-a-service and installed in on-premise environments in the own data center as a software.

The cloud computing world is hybrid

Does Dell rise in the range of cloud innovators with this change in strategy? Not by a long shot! Dell is anything but a leader in the cloud market. The trumps in their cloud portfolio are entirely due to acquisitions. But, at the end of the day, that does not matter. To be able to take part in the highly competitive public cloud market, massive investment should have been made ​​that would not have been necessarily promising. Dell has been able to focus on his tried and true strengths and these are primarily in the sale of hardware and software, keyword: “Converged Infrastructures” and the consulting business. With the purchase of cloud integration service Boomi, the recent acquisition of Enstratius and the participation in the OpenStack community externally relevant knowledge was caught up to position itself in the global cloud market. In particular, the Enstratius technology will help Dell to diversify the market and take a leading role as a hybrid cloud broker.

The cloud world is not only public or only private. The truth lies somewhere in the middle and strongly depends on the particular use case of a company, which can be divided into public, private as well as hybrid cloud use cases. In the future, all three variants will be represented within a company. Thereby the private cloud does not necessarily have to be directly connected to a public cloud to span a hybrid cloud. IT departments will play a central role in this case, get back more strongly into focus and act as the company’s own IT service broker. In this role, they have the task of coordinating the use of internal and external cloud services for the respective departments to have an overall view of all cloud services for the whole enterprise. For this purpose, cloud broker services such as Dell’s will support.

Categories
Kommentar

Die Cloud Computing Welt ist hybrid! Zeigt uns Dell wo es lang geht?

Dell hat sich mit einem klaren Schnitt aus der Public Cloud verabschiedet und richtet seine Cloud Computing Strategie nun mit eigenen auf OpenStack-basierten Private Cloud Lösungen, inkl. einem Cloud-Broker-Service für Public Clouds anderer Anbieter, aus. Dieser Schritt kommt im ersten Moment überraschend, macht aber Sinn, wenn man Dell, dessen jüngste Vergangenheit, aber vor allem den Markt genauer betrachtet.

Dells neue Cloud Strategie

Anstatt ein eigenes Public Cloud Angebot am Markt zu platzieren, wird Dell in Zukunft OpenStack-basierte Private Clouds auf Dell Hardware und Software verkaufen. Mit der erst kürzlich akquirierten Cloud-Management Technologie von Enstratius sollen Kunden darüber hinaus in der Lage sein, ihre Ressourcen zu mehr als 20 Public Cloud Anbieter zu verteilen.

Mit einem neuen “Partner Ecosystem”, das derzeit aus drei Anbietern besteht, in Zukunft aber weiter ausgebaut wird, sollen Integrationsmöglichkeiten zwischen den Public Clouds dieser Partner und den Private Clouds der Dell Kunden angeboten werden. Zu dem aktuellen Partnernetzwerk gehören Joyent, ZeroLag und ScaleMatrix. Alle drei sind eher kleine Namen im Infrastructure-as-a-Service (IaaS) Markt.

Dell stärkt damit ebenfalls weiter sein Beratungsgeschäft, indem Kunden aufgezeigt werden soll, welche Workloads und Prozesse in die Public Cloud fließen können.

Enstratius macht Dell zum Cloud-Broker

Ein Blick auf den aktuellen IaaS Public Cloud Markt zeigt, dass Dell mit seiner Strategieänderung richtig liegt. Alle aktuellen IaaS Anbieter jeder Größe reiben sich im Kampf um Marktanteile gegen den Branchenprimus Amazon Web Services auf. Da sich deren Innovationskraft im Vergleich zu Amazon jedoch auf ein Minimum beschränkt und sich die meisten, mit Ausnahme von Google und Microsoft, auf das Bereitstellen von reinen Infrastruktur-Ressourcen (Rechnerleistung, Speicherplatz, usw.) beschränken, sind die Erfolgsaussichten eher gering. Auf einen Preiskampf mit Amazon sollten sich zudem die wenigsten einlassen, das kann sehr schnell nach hinten losgehen.

Anstatt sich ebenfalls mit Amazon und den anderen Public IaaS Anbietern in den Ring zu stellen, positioniert sich Dell nun auf Basis von Boomi, Enstratius und weiteren früheren Akquisitionen als unterstützende Kraft für Cloud Service Anbieter und IT-Abteilungen und versorgt diese mit Hardware, Software und weiteren Mehrwerten.

Insbesondere der Kauf von Enstratius war ein guter Schachzug und macht Dell zum Cloud-Service-Broker. Bei Enstratius handelt es sich um ein Toolset zur Verwaltung von Cloud-Infrastrukturen, darunter die Bereitstellung, die Verwaltung und die Automatisierung von Applikation für – aktuell 23 – Public und Private Cloud Lösungen. Zu erwähnen ist, dass Enstratius neben dem Verwalten von einer Cloud-Infrastruktur ebenfalls den Betrieb von Multi-Cloud Umgebungen ermöglicht. Dazu kann Enstratius als Software-as-a-Service genutzt, als auch in on-Premise Umgebungen im eigenen Rechenzentrum als Software installiert werden.

Die Cloud Computing Welt ist Hybrid

Steigt Dell mit diesem Strategiewechsel nun in die Reihe der Cloud-Innovatoren auf? Bei Weitem nicht! Dell ist alles andere als ein führender Anbieter im Cloud Markt. Die Trümpfe im Cloud-Portfolio sind einzig und allein auf Akquisitionen zurückzuführen. Unterm Strich spielt das aber keine Rolle. Um im mittlerweile stark umkämpften Public Cloud Markt ein Wörtchen mitreden zu können, hätten massive Investitionen getätigt werden müssen, die nicht zwangsläufig erfolgsversprechend gewesen wären. Dell hat verstanden sich auf seine altbewährten Stärken zu konzentrieren und die liegen in erster Linie im Verkauf von Hardware und Software, Stichwort “Converged Infrastructures” und dem Beratungsgeschäft. Mit dem Kauf des Cloud-Integrations-Service Boomi, der jüngsten Akquisition von Enstratius und der Beteiligung an der OpenStack Gemeinde wurde extern entsprechendes Wissen eingeholt, um sich im weltweiten Cloud Markt zu positionieren. Insbesondere die Enstratius Technologie wird Dell dabei helfen, sich im Markt zu diversifizieren und als Hybrid Cloud-Broker eine führende Rolle einzunehmen.

Die Cloud Welt ist nicht nur Public oder nur Private. Die Wahrheit liegt irgendwo mittendrin und hängt stark von dem jeweiligen Use Case eines Unternehmens ab, die sich in Public, Private aber auch Hybrid Cloud Use Cases unterteilen. In Zukunft werden innerhalb eines Unternehmens alle drei Varianten vertreten sein. Dabei muss die Private Cloud nicht zwangsläufig direkt mit einer Public Cloud verbunden sein, um eine Hybrid Cloud aufzuspannen. Die IT-Abteilungen werden in diesem Fall eine zentrale Rolle spielen, wieder stärker in den Fokus rücken und als unternehmenseigener IT-Service-Broker auftreten. In dieser Rolle haben sie die Aufgabe, die eingesetzten internen und externen Cloud-Services der jeweiligen Fachabteilungen zu koordinieren, um für das Unternehmen den Gesamtüberblick aller Cloud-Services zu haben. Hierbei werden sie Cloud-Broker Services wie der von Dell unterstützen.

Categories
Analysis

Google Compute Engine: Google is officially in the game

Google officially gets in the battle for market share in the infrastrucuture-as-a-service (IaaS) area. What was only determined for a selected group of customers starting one year ago, the company from Mountain View has now made available for the general public as part of the Google I/O 2013. It’s about their cloud computing offering, Google Compute Engine (GCE).

News about the Google Compute Engine

With App Engine, BigQuery and Cloud Storage, Google has steadily expanded its cloud portfolio since 2008. What was missing was an infrastructure-as-a-service solution that can be used as needed to start virtual machines. The Google Compute Engine (GCE) released Google to its I/O 2012 in a closed beta, to use virtual machines (VM) with the Linux operating system on the Google infrastructure, which is also used by Gmail and other services.

Together with the Google I/O 2013, the GCE has now reached the general availability. Furthermore, Google has launched the Cloud Datastore, a by Google fully managed NoSQL database for non-relational data. Independent from the GCE the service provides automatic scalability, ACID transactions, and SQL-like queries and indexes. In addition, there is a limited preview of the PHP programming language for App Engine. With that Google wants to address developers and users of open source applications such as WordPress. Beyond that, the integration has been improved with other parts of the cloud platform such as Cloud SQL and Cloud Storage. Further, Google looks at the feedback of its users, that it should be possible to develop simple modularized applications on the App Engine. In response, it is now possible to partition applications into individual components. Each with its own scaling, deployment, versioning and performance setting.

More news

Other major announcements include more granular billing, new instance types as well as an ISO 27001 certification:

  • Granular billing: Each instance type is now billed per minute, where 10 minutes will be charged at least.
  • New instance types: There are new micro and small instance types that are meant to process smaller workloads inexpensive and require little processing power.
  • More space: The size of the “Persistent Disks”, which can be connected to a virtual instance have been extended up to 8.000 percent. This means that now a persistent disk can be attached with a size of up to 10 terabytes to a virtual machine within the Compute Engine.
  • Advanced routing: The Compute Engine now supports based on Google’s own SDN (Software Defined Network) opportunities for software-defined routing. With that instances can act as gateways and VPN server. In addition it can be use to develop applications so that they run in the own local network and in the Google cloud.
  • ISO 27001 certification: The Compute Engine, App Engine and Cloud Storage are fully certified with ISO 27001:2005.

Developer: Google vs. Amazon vs. Microsoft

First, the biggest announcement for the Google Compute Engine (GCE) is its general availability. In recent months, the GCE was held up by every news as THE Amazon killer, although it was still in a closed beta, and thus there was no comparison at eye level. The true time reckoning begins now.

Many promise from the GCE that Google creates a real competitor to Amazon Web Services. The fact is that the Google Compute Engine is an IaaS offering and Google due to its core business, have the expertise to build highly scalable infrastructures and to operate them highly available. The Google App Engine also shows that Google knows how to address developers, even if the market narrows here with increasingly attractive alternatives.

A lack of diversification

Having a look at the compute engine, we see instances, storage, and services for the storing and processing of structured and unstructured data (Big Query, SQL Cloud and Cloud Datastore). Whoever sees Google as THE Amazon killer from this point, should scale down its expectations once a little. Amazon has a very diversified portfolio of cloud services that enables to use the Amazon cloud infrastructure. Google needs to tie in with it, but this should not be too difficult, since many Google services are already available. A look at the services of Amazon AWS and the Google Cloud Platform is worthwhile for this reason.

Hybrid operation for applications

Google may not be underestimated in any case. On the contrary, from a first performance comparison between the Google and Amazon cloud, Google emerged as the winner. This lies inter alia in the technologies that Google is constantly improving, and on its global high-performance network. What is particularly striking, Google now offers the possibility to develop applications for a hybrid operation in the own data center and for the Google cloud. This is an unexpected step, since Google have been rather the motto “cloud only”. However, Google has been struggling lately with technical failures similar to Amazon, which does not contribute to the strengthening of trust in Google.

A potshot is the new pricing model. Instances are now charged per minute (at least 10 minutes of use). Amazon and Microsoft still charge their instances per hour. Whether the extension of the “Persistent Disks” up to 10 terabytes will contribute a diversification we will see. Amazon is also under developers regarded as the pioneer among IaaS providers, which will make it not easier for Google to gain market share in this segment. In addition, Google may assume that, next to ordinary users, developers also do not want to play Google’s “service on / off” games.

Amazon and Microsoft are already one step ahead

Where Google with its SaaS solution Google Apps massively tries to penetrate corporate customers for quite some time, the Compute Engine is aimed primarily at developers. Amazon and Microsoft have also begun in this customer segment, but long since begun to make their infrastructures respectively platforms attractive for enterprise customers. Here is still much work for Google, if this customer segment is to be developed, which is inevitably. However, in this area it is about much more than just technology, but about creating trust and to consider organizational issues (data protection, contracts, SLAs, etc.) as valuable.

Google’s problem: volatility

No doubt, Google is by far the most innovative company on our planet. But equally the most volatile and data hungriest. This also developers and especially companies both observed and should ask the question how future-proof the Google cloud portfolio is. If the compute engine is a success, don’t worry about it! But what if it is for Google(!) a non-seller. One remembers the Google Reader, whose user numbers were not sufficient enough for Google. In addition, the compute engine has another KPI, revenue! What does Google do when it’s no longer economic?

Categories
Analysen

Google Compute Engine: Google ist offiziell im Spiel

Nun steigt auch Google offiziell in den Kampf um Marktanteile im Infrastrucuture-as-a-Services (IaaS) Bereich ein. Was seit einem Jahr nur einem ausgewählten Personen- bzw. Kundenkreis bestimmt war, hat das Unternehmen aus Mountain View jetzt im Rahmen der Google I/O 2013 der Allgemeinheit verfügbar gemacht. Die Rede ist von seinem Cloud Computing Angebot, der Google Compute Engine (GCE).

Neuigkeiten zur Google Compute Engine

Mit der Google App Engine, BigQuery und dem Google Cloud Storage hat Google seit 2008 sein Cloud Portfolio stetig ausgebaut. Was noch fehlte war eine Infrastructure-as-a-Service Lösung, mit der virtuelle Maschinen bei Bedarf genutzt werden können. Die Google Compute Engine (GCE) brachte Google zu seiner I/O 2012 in einer geschlossenen Beta auf den Markt, um virtuelle Maschinen (VM) mit dem Linux Betriebssystem auf der Google Infrastruktur, die auch von Google Mail und anderen Services eingesetzt wird, zu nutzen.

Zusammen mit der Google I/O 2013 hat die GCE nun auch den Status der allgemeinen Verfügbarkeit erreicht. Weiterhin hat Google einen Cloud Datastore, eine von Google vollständig verwaltete NoSQL Datenbank für nicht relationale Daten, veröffentlicht. Der von der GCE unabhängige Service bietet eine automatische Skalierbarkeit, ACID Transaktionen sowie SQL-artige Anfragen und Indizes. Weiterhin gibt es eine eingeschränkte Vorschau der Programmiersprache PHP für die App Engine. Damit will Google Entwickler und Nutzer von Open-Source Applikationen wie z.B. WordPress ansprechen. Zudem wurde die Integration mit anderen Teilen der Cloud Plattform wie Google Cloud SQL und Cloud Storage verbessert. Darüber hinaus geht Google auf die Rückmeldung seiner Nutzer ein, dass es möglich sein sollte, Applikationen auf der App Engine einfacher modularisiert zu entwickeln. Als Reaktion darauf ist es nun möglich, Applikationen in einzelne Komponenten zu partitionieren. Jede mit ihrer eigenen skalierungs-, bereitstellungs-, versionierungs- und performance- Einstellung.

Weitere Neuigkeiten

Zu den weiteren größeren Ankündigungen gehören u.a. eine granularere Abrechnung, neue Instanz-Typen sowie eine ISO 27001 Zertifizierung:

  • Genauere Abrechnung: Jeder Instanz-Typ wird nun pro Minute abgerechnet, wobei 10 Minuten mindestens berechnet werden.
  • Neue Instanz-Typen: Es gibt nun neue Micro- und Small Instanz-Typen, die dafür gedacht sind, kostengünstig kleinere Workloads zu verarbeiten, die nur wenig Rechenleistung benötigen.
  • Mehr Speicherplatz: Die Größe der “Persistent Disks”, die mit einer virtuellen Instanz verbunden werden können, wurden um bis zu 8.000 Prozent erweitert. Das bedeutet, dass nun eine Persistent Disk mit einer Größe von bis zu 10 Terabyte an eine virtuelle Maschine der Compute Engine angehängt werden kann.
  • Erweitertes Routing: Die Compute Engine unterstützt nun basierend auf dem eigenen SDN (Software-Defined Networking) Möglichkeiten für das Software-Defined Routing. Damit lassen sich Instanzen als Gateways und VPN-Server einsetzen und Applikationen so entwickeln, dass diese im eigenen lokalen Netzwerk als auch in der Google Cloud laufen.
  • ISO 27001 Zertifizierung: Die Compute Engine, App Engine und Cloud Storage wurden vollständig mit ISO 27001:2005 zertifiziert.

Entwickler: Google vs. Amazon vs. Microsoft

Zunächst, die größte Ankündigung für die Google Compute Engine (GCE) ist ihre allgemeine Verfügbarkeit. In den letzten Monaten wurde die GCE nach jeder Neuigkeit als DER Amazon Killer hochgehalten, obwohl sie sich noch in einer geschlossenen Beta befand und somit kein Vergleich auf Augenhöhe bestand. Die wirkliche Zeitrechnung beginnt jetzt.

Viele versprechen sich von der GCE, dass Google damit einen echten Konkurrenten zu den Amazon Web Services schafft. Fakt ist, das es sich bei der Google Compute Engine um ein IaaS Angebot handelt und Google auf Grund seines Kerngeschäfts über die Expertise, hochskalierbare Infrastrukturen aufzubauen und diese hochverfügbar zu betreiben, verfügt. Die Google App Engine zeigt darüber hinaus, dass Google es versteht, Entwickler anzusprechen, auch wenn sich der Markt hier mit zunehmend attraktiven Alternativen verengt.

Es fehlt die Diversifikation

Schauen wir uns die Compute Engine an, dann sehen wir Instanzen, Speicherplatz, sowie Services für das Speichern und Verarbeiten von strukturierten und unstrukturierten Daten (Big Query, Cloud SQL und Cloud Datastore). Wer Google unter diesen Gesichtspunkten daher als DEN Amazon Killer sieht, sollte seine Erwartungen erst einmal ein wenig herunterschrauben. Amazon hat ein sehr diversifiziertes Portfolio an Cloud Services, mit denen die Amazon Cloud Infrastruktur genutzt werden kann. Daran muss Google erst einmal anknüpfen, was sich allerdings nicht als all zu schwer erweisen dürfte, da viele Google Services bereits vorhanden sind. Ein Blick auf das Serviceangebot von Amazon AWS und der Google Cloud Platform ist aus diesem Grund lohnenswert.

Hybrid Betrieb für Applikationen

Google darf auf keinen Fall unterschätzt werden. Im Gegenteil, aus einem ersten Performance-Vergleich zwischen der Google Cloud Platform und Amazon AWS ging Google als Sieger hervor. Das liegt u.a. an den Technologien, die Google ständig verbessert sowie an seinem weltweiten hochperformanten Netzwerk. Was besonders auffällt, Google bietet nun die Möglichkeit, Applikationen für einen hybrid Betrieb, im eigenen Rechenzentrum und in der Google Cloud, zu entwickeln. Das ist ein unerwarteter Schritt, da bei Google bisher eher die Devise “Cloud only” lautete. Allerdings hat auch Google in letzter Zeit ähnlich wie Amazon mit technischen Ausfällen zu kämpfen gehabt, was nicht zur Stärkung des Vertrauens in Google beiträgt.

Ein Seitenhieb ist das neue Preismodell. Instanzen werden nun pro Minute (mindestens 10 Minuten Nutzung) abgerechnet. Amazon und auch Microsoft rechnen ihre Instanzen derzeit noch pro Stunde ab. Ob die Erweiterung der “Persistent Disks” auf bis zu 10 Terabyte zur Diversifikation beiträgt wird sich zeigen. Amazon gilt auch unter Entwicklern als der Vorreiter unter den IaaS Anbietern, was es für Google nicht einfacher machen wird in diesem Segment (Entwickler) ausreichend Marktanteile zu gewinnen. Außerdem darf Google davon ausgehen, dass neben den gewöhnlichen Nutzern, ebenfalls Entwickler keine Lust auf Googles “Service an/aus” Spielchen haben.

Amazon und Microsoft sind schon einen Schritt voraus

Wo Google mit seiner SaaS Lösung Google Apps seit geraumer Zeit massiv auch Unternehmenskunden angeht, richtet sich die Compute Engine in erster Linie an Entwickler. Amazon und Microsoft haben auch in diesem Kundensegment angefangen, aber längst damit begonnen, ihre Infrastrukturen respektive Plattformen für Unternehmenskunden attraktiver zu machen. Hier wird auf Google noch viel Arbeit zukommen, wenn dieses Kundensegment erschlossen werden soll, was zwangsläufig unumgänglich ist. Allerdings geht es in diesem Bereich um viel mehr als nur Technologien, sondern darum, Vertrauen zu schaffen und organisatorische Themen (Datenschutz, Verträge, SLA, usw.) für wertvoll zu erachten.

Googles Problem: Unbeständigkeit

Keine Frage, bei Google handelt es sich mit Abstand um das innovativste Unternehmen auf unserem Planeten. Aber gleichermaßen auch um das Unbeständigste und Datenhungrigste. Das werden auch Entwickler und speziell Unternehmen beobachtet haben und beide sollten sich die Frage stellen, wie Zukunftssicher das Google Cloud Portfolio überhaupt ist. Wird die Compute Engine ein Erfolg, braucht man sich keine Sorgen machen. Aber was ist, wenn sie für Google(!) zum Ladenhüter wird. Man erinnere sich an den Google Reader, dessen Nutzerzahlen für Google nicht mehr ausreichend genug waren. Hinzu kommt, dass die Compute Engine einen weiteren KPI hat, den Umsatz! Was macht Google, wenn dieser nicht mehr stimmen sollte?!

Categories
Analysis

Rackspace differentiated its IaaS cloud offering with a higher-value support

Rackspace currently does everything it can to fight for market share in the infrastructure-as-a-service (IaaS) area against the Amazon Web Services. After the poor results in Q1/2013 no easy task. As the driving wheel behind the OpenStack movement, the former managed hosting provider attempts to anchor the topic of open source in the cloud and marketed OpenStack as the Linux of the cloud. But Rackspace challenge is not only to prepare well against Amazon. Even from within its own OpenStack rows more and more competitors grow up, all offering the same technology, API and services based on OpenStack. Be mentioned here only big names like HP, IBM and Red Hat. Due to this very similar range of services – what is a homemade problem – it is difficult for Rackspace to differentiate from the competition, on the one hand, the seemingly all-powerful Amazon Web Services, but also Windows Azure and Google, on the other hand the own OpenStack camp. Rackspace now seems to focus on his well-tried and true strengths, their “Fanatical Support” and wants to help businesses and developers intensively in the use of the Rackspace cloud services.

Help on the way to the cloud

Even as a simple managed hosting provider Rackspace has help its customers with infrastructure management. For its OpenStack based cloud-platform the standard support has now been extended. Customers will now also receive support at the application level including debugging of the application that runs on the Rackspace cloud. This means that the interaction with the customer to be significantly enhanced by not only advice the basics, but even developer-specific know-how. It even goes so far that Rackspace engineers analyze the source code of the application on request and make suggestions for an effective use on the Rackspace cloud and in particular with the Rackspace APIs and SDKs, or even help during the complete development. For developers it should be made easier to understand how their own native application works on the Rackspace cloud and OpenStack.

Support as diversification

Now you may think: Support as diversification? In times of self-service and automation in the cloud? Yes exactly, that’s not so far-fetched and not an unwise move. Necessity is the mother of invention. Rackspace has always placed much emphasis on its support, and enjoys an excellent reputation.

Furthermore, one should remember that, despite the fact of self-service and the associated terms of easy receiving resources to build a virtual infrastructure respectively to develop an own cloud-enabled application, cloud computing is not easy! I have recently described that in the article “Cloud Computing ist not simple!” and named Netflix as a very positive example. There are just a few user-companies that have permeated cloud computing such as Netflix who have written with their Simian Army like the Chaos Monkey or the Chaos Gorilla test software for a scalable and highly available operation in the cloud. However, if one looks what huge efforts Netflix makes, which are also associated with costs, cloud computing is not something to take lightly, if you want to use it seriously.

For this reason, it is a logical and for me right step by Rackspace to expand their support and help where it matters in the cloud, the scalable and available development of applications that take into account of the characteristics of the cloud. Whether that is enough to catch up Amazon with big steps I dare to doubt. But within the providers that also rely on OpenStack, it is a good way to differentiate themselves from the competition.

Categories
Analysen

Rackspace differenziert sein IaaS Cloud Angebot mit einem höherwertigen Support

Rackspace setzt derzeit alles daran, um im Kampf um Marktanteile im Infrastructure-as-a-Services (IaaS) Bereich gegen die Amazon Web Services zu Punkten. Nach den schlechten Ergebnissen im Q1/2013 kein leichtes Unterfangen. Als der Antreiber hinter der OpenStack Bewegung, versucht der ehemalige Managed-Hosting Anbieter das Thema Open-Source in der Cloud zu verankern und vermarktet OpenStack als das Linux der Cloud. Rackspace Herausforderung besteht jedoch nicht nur darin, sich gut gegen Amazon aufzustellen. Auch aus den eigenen OpenStack Reihen wachsen nach und nach mehr Mitbewerber, die alle dieselbe Technologie, API und Services auf Basis von OpenStack anbieten. Genannt seien hier nur große Namen wie HP, IBM oder Red Hat. Auf Grund dieses doch zum Teil sehr ähnlichen Angebots von Services – wobei es sich um ein hausgemachtes Problem handelt – ist es für Rackspace schwierig sich von dem Mitbewerb, auf der einen Seite die scheinbar übermächtigen Amazon Web Services aber auch Windows Azure und Google, auf der anderen Seite das eigene OpenStack Lager, zu differenzieren. Rackspace scheint sich nun auf seine altbewährten Stärken, dem “Fanatical Support”, zu konzentrieren und möchte Unternehmen und Entwicklern intensiver bei der Nutzung der Rackspace Cloud Services helfen.

Hilfe auf dem Weg in die Cloud

Bereits als einfacher Managed-Hosting Anbieter hat Rackspace seine Kunden beim Infrastrukturmanagement unterstützt. Für seine OpenStack basierte Cloud Plattform wurde der Standard Support nun erweitert. Kunden sollen ab sofort auch Unterstützung auf Applikationsebene inkl. Debugging der Anwendung erhalten, die auf der Rackspace Cloud betrieben wird. Das bedeutet, dass die Interaktion mit den Kunden deutlich verstärkt werden soll, indem nicht nur die Grundlagen, sondern spezifisches Entwickler Know How vermittelt wird. Das geht sogar soweit, dass Rackspace Ingenieure bei Wunsch den Quellcode der Applikation analysieren und Verbesserungsvorschläge für eine effektivere Nutzung auf der Rackspace Cloud und insbesondere mit den Rackspace APIs und SDKs machen oder sogar bei der vollständigen Entwicklung helfen. Entwicklern soll es damit einfacher gemacht werden, zu verstehen, wie ihre eigene native Applikation auf der Rackspace Cloud bzw. OpenStack funktioniert.

Support zur Differenzierung

Nun mag man denken: Support zur Differenzierung? In Zeiten des Self-Service und der Automatisierung in der Cloud? Ja genau, das ist gar nicht so abwegig und ein gar nicht so unkluger Schachzug. Die Not macht erfinderisch. Rackspace hat schon immer viel Wert auf seinen Support gelegt und genießt hier einen guten Ruf.

Weiterhin sollte man bedenken, dass, trotz des Self-Service und dem damit einhergehenden einfachen Bezug von Ressourcen für den Aufbau einer virtuellen Infrastruktur respektive dem darauf entwickeln einer eigenen Cloud-fähigen Applikation, Cloud Computing nicht einfach ist! Ich habe das erst kürzlich in dem Artikel “Cloud Computing ist nicht einfach!” beschrieben und Netflix als sehr positives Beispiel genannt. Es gibt nur wenige Nutzer-Unternehmen, die Cloud Computing so durchdrungen haben wie Netflix, die sich mit ihrer Simian Army wie dem Chaos Monkey oder dem Chaos Gorilla Test-Software für einen skalierbaren und hochverfügbaren Betrieb in der Cloud geschrieben haben. Wenn man jedoch schaut, was für einen Aufwand Netflix dafür betreibt, mit dem auch Kosten verbunden sind, ist Cloud Computing nicht auf die leichte Schulter zu nehmen, wenn man es ernsthaft einsetzen möchte.

Aus diesem Grund ist es nur ein logischer und für mich richtiger Schritt von Rackspace, seinen Support weiter auszubauen und dort zu unterstützen, wo es bei der Cloud ankommt, der skalierbaren und verfügbaren Entwicklung von Applikationen, die auch die Eigenschaften der Cloud berücksichtigen. Ob das nun reicht, um gegenüber Amazon mit großen Schritten aufzuholen wage ich zu bezweifeln. Aber innerhalb der Anbieter, die ebenfalls auf OpenStack setzen, ist es eine gute Möglichkeit sich von diesem Wettbewerb zu differenzieren.

Categories
Analysis

Enterprise Cloud Portal: T-Systems consolidates its cloud portfolio

With its Enterprise Cloud Portal German Telekom subsidiary T-Systems presents its first cloud service-wide offering for corporate customers. On the portal, companies can inform about the cloud solutions from T-Systems, test them and order directly. The currently offered services include solutions for mobile device management, Dynamic Services for Infrastructure and the Enterprise Marketplace. A look at the site shows that great emphasis was placed on the compatibility with tablets.

Past the IT department

With its cloud portal T-Systems want to enable also non-technical users in large companies to access specific cloud solutions. The cloud provider refers to a study by Gartner, which says that up to 2015, about 35 percent of IT spending are selected and managed outside the IT department. Be mentioned here, for example, marketing, purchasing and accounting.

Mobile Device Management

The mobile device management from the cloud should help businesses in the administration of mobile devices with different operating systems, such as iOS and Android via a standardized web platform. In addition to security settings, control access rights to functions and applications can be made. In case of loss of the device, the data can be deleted remotely. A test of the mobile device management is free for the first four weeks for up to three mobile devices.

Dynamic Services for Infrastructure

For infrastructure-as-a-service (IaaS) two offerings are ready: On the one hand, the “Dynamic Services for Infrastructure” (DSI) from a hosted private cloud. Secondly, the “DSI with vCloud Datacenter Services” as a hybrid variant. The management of the resources does the client itself via a web-based portal or using its own VMware management software. Clear pricing models to make the cost of the infrastructure transparent. Thus, for example, a server from the hosted private cloud costs from 9 cents per hour in the package “Small”. For the hybrid solution the package price for a virtual data center in the smallest version is exactly at 999,84€ per month.

Enterprise Marketplace

The Enterprise Market Place includes, among other things, further IaaS solutions including operating systems for Linux and Windows Server, platform-as-a-service (PaaS) solutions, including Tomcat and Microsoft SQL Server as well as a growing number of software-as-a-service (SaaS) offerings like Doculife, CA Nimsoft TAXOR, TIS, WeSustain, Metasonic, ARAS, Tibco Tibbr, Sugar CRM, Microsoft Enterprise Search and Microsoft Lync. In addition, companies should therefore be given the opportunity to apply a variety of applications highly safe in need-based formats, but also can migrate to host their own applications. The full availability of the Enterprise Market Place is planned for this summer. Currently, there is already a preview on the cloud portal.

Comment

With the Enterprise Cloud Portal T-Systems summarizes his entire cloud portfolio together under one umbrella. I had analyzed “The cloud portfolio of T-Systems” in an article for the German Computerwoche in 2011. At that time the offering was made of single and independent services. However, already at that time I came to the conclusion that T-Systems has a very well sophisticated and well-rounded cloud portfolio. This can be seen now in the consolidated Enterprise Cloud Portal. From SaaS over PaaS to IaaS and other solutions for mobile devices can be found. With it T-Systems is one of the few providers that have a full cloud stack and which is now even bundled into a single portal.

Especially in the Enterprise Marketplace is a lot potential. At this year’s CeBIT, I could take a first look at it which was in my opinion at this time still in an alpha state. Some basic and necessary essential functions for an IaaS offering, automatic scalability and high-availability may be mentioned only, were still missing. But that was in March and I’m assuming that T-Systems has already made ​​more progress here. In addition, I have already heard from a reputable source, that T-Systems/ Telekom will gradually change their cloud infrastructure to OpenStack, which will also give the Enterprise Market Place another boost in compatibility.

Where T-Systems sees an advantage for non-technical users in enterprises, should cause worry lines for IT managers. Indeed, I am also of the opinion that the IT department will become and even need to be a service broker. However, I think it is quite questionable if each department can simply run off and buy IT services externally as desired. Certainly, the blame lies with the IT departments themselves because they have built up a bad reputation over the years and are considered as slow and not innovative. I have philosophized about it here two years ago in detail (cloud computing and the shadow IT).

A certain supervisory authority in the form of a service broker is still necessary, because otherwise it is an uncontrolled proliferation of external services about which one will lose track. This can be controlled, of course, if one obtains the services from a single provider. And that is exactly the goal of T-Systems and its extensive Enterprise Cloud Portal. A customer should explicitly and across departments, refer the services from the T-Systems Cloud in order to avoid sprawl and to keep track. The question is whether this can be set internally by the customers that way. Because there are plenty of other services in the sea.

In the end I would like to address a topic that is currently causing a stir in the end customer market, but offers corporate customers a great advantage. The end-to-end offering of services. T-Systems is due to its situation, to be a subsidiary of Deutsche Telekom, one of the few cloud providers who can offer a service level from the services at application level or even virtual machine level in the data center, including the data line. This enables customers to maintain a continuous Quality-of-Service (QoS) and a comprehensive Service Level Agreement (SLA), which many other cloud providers can not afford.

Categories
Comment

Cloud Computing ist not simple!

Cloud computing promises to be simple. Starting here and there a virtual server and the own virtual cloud infrastructure is ready. Those who think that I’m right with the statement are totally wrong. Virtual servers are only a small component of a virtual infrastructure at a cloud provider. A few virtual machines aren’t a cloud. The complexity sticks in the architecture of the application. And thus in the intelligence that the architect and the software developer included. That this is sometimes not implemented, the one or the other cloud user have showed us more than once impressively. Regularly the same suspects fail when their cloud provider is struggling with himself. Cloud computing ist not simple! I do not mean simple software-as-a-service (SaaS). I am talking about infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS), and here even granularity about the premier class named scalability and high-availability. And that’s what you should understand and fully take into account if you want to use cloud computing successfully, away from the marketing of the cloud providers.

Software-defined Scalability and Software-defined High-Availability

Currently new terms circulating through the IT stratosphere. Software-Defined Networking (SDN) and Software-Defined Data Center (SDD). A SDN introduces another level of abstraction above the network components. Typically, each router and switch has its own local software through which it is supplied with intelligence by programming. The network administrator tells the router, for example, under what conditions which packet should be routed or not. Within a SDN the task of incorporating a local intelligence for each component is eliminated. The intelligence moves one level up into a management layer in which the entire network is designed and each rule is defined centrally for each component. If the design is completed, it will be rolled out across the network components and the network is configured. With a SDN it should be possible to change a complete network design by “push the button” directly without having to touch each individual component.

The idea of ​​the SDN concept must also be taken into account mandatory when using a cloud infrastructure. Because the use of a PaaS, but much more of an IaaS means a lot of self-responsibility. More than you might think at first glance. To start one or two virtual machines does not mean that one uses a virtual cloud infrastructure. There are and will remain two virtual servers. An IaaS provider only provides the components, such as the aforementioned virtual machines, storage, and other services plus APIs with which the infrastructure can be used. Bottom line, to put it simply, an IaaS provider only supplies its customers with the appropriate resources and tools in order to build their own virtual infrastructure respectively own virtual data center on the providers cloud infrastructure.

One must therefore ensure with software (the own application) that the cloud infrastructure scaled if necessary (Software-Defined Scalability, SDS) and in the event of a failure of a cloud infrastructure component a replacement component (eg, virtual machine) is started and is thus replaced (Software-Defined High-Availability, SDHA). The software therefore provides the scalability and high-availability of the virtual cloud infrastructure so that the web application itself is scaled and fail-safe, and uses the character of each cloud provider.

How a cloud computing infrastructure is used almost to perfection shows Netflix impressively.

Cloud Computing ist not simple!

Source: Adrian Cockcroft

Netflix the supreme example

Netflix is the world’s largest cloud service ​​by far. The video streaming service has become responsible for a third of all Internet traffic during peak periods. This user requests must be answered, of course, performant and at any time. Since its launch in 2009 Netflix sets on cloud technologies and has shifted its complete technology stack including the resulting infrastructure to the cloud of the Amazon Web Services in November 2012. Here about 1,000 virtual Linux-based Tomcat Java server and NGINX web server are running. There are also other services such as Amazon Simple Storage Service (S3) and the NoSQL database Cassandra in conjunction with memcached and a distributed memory object caching.

However, this is only one side of the coin. More important is the use of multiple Availability Zones in the Amazon Cloud. Netflix uses a total of three Availability Zones to increase the availability and speed of the own service. Occurs a problem in an Availability Zone, the architecture of the Netflix application is designed that the service can continue to run through the other two. Here Netflix has not relied on the pure marketing promises from Amazon, but developed with the Chaos Gorilla its own software that is testing the stability of the virtual servers Amazon Elastic Compute Cloud (EC2). In short, the failure of a complete EC2 Region or Availability Zone is simulated to ensure that the Netflix service continues to function in an emergency. One of the biggest challenges is in the fact that in the event of an error in an Amazon region, the Domain Name System (DNS) is automatically reconfigured so that Netflix customers do not notice the failure. The different DNS providers APIs make this task not easier. In addition, most have been developed that the settings have to be done manually, which does not make it easier to automate this.

Bottom line, it is to say that Netflix plans ahead for the error case and does not rely on the cloud. Because sometimes something goes wrong in the cloud, as in any ordinary data center. You only need to be prepared for it. Who is more interested in what Netflix makes to reach this state should read “Netflix: The Chaos Monkey and the Simian Army – The model for a good cloud system architecture” (only in German).

Simplicity counts

Maybe I’m asking too much. Finally, cloud computing is a relatively new concept. Nevertheless, Netflix shows impressively that it works. However, when you consider what huge efforts Netflix makes to be successful in the cloud, you just have to say that cloud computing is not simple, and a cloud infrastructure, no matter at which provider, needs to be built with the corresponding architecture. This means, conversely, that the use of the cloud must be more simply in order to achieve the promised cost advantages. Because if one uses cloud computing the right way, it is necessarily not cheaper. In addition to savings in infrastructure costs which are always reckoned up, the other costs as may for the staff with the appropriate skills and the costs for the development of scalable and fault-tolerant applications in the cloud should never be neglected.

The positive sign is that I see first startups on the horizon, who take care of this problem and have set the simple demand of finished cloud resources to their task, without worrying about scalability and high-availability as a user.