Tag: Infrastructure

Categories
Services @de

Cloudcat – Ein Enterprise Tomcat in der Cloud

MuleSoft hat mit Cloudcat kürzlich einen Tomcat-Webserver vorgestellt, der als Service in der Cloud von Amazon oder GoGrid betrieben werden kann. Dieser Artikel stellt Cloudcat und seine Funktionen vor.

Cloudcat stellt Softwareentwicklern und Softwaretestern ein virtuelles 32-bit und 64-bit Image für Amazon EC2 (AMI) bzw. GoGrid (GSI) bereit, mit denen Web-Anwendungen innerhalb der Cloud erstellt und getestet werden können. Cloudcat beinhaltet einen für Linux (Redhat/GoGrid und Ubuntu/EC2) komplett vorkonfigurierten Apache Tomcat sowie einen MySQL Server.

Unterschiede zwischen Amazon EC2 und GoGrid

Cloudcat bietet neben dem Tomcat und MySQL Server weitere Funktionen, die nachfolgend beschrieben werden.

Administrationskonsole für Tomcat

Mit der Browser basierten Administrationskonsole können sämtliche Tomcat Instanzen von einer zentralen Stelle aus überwacht und verwaltet werden, dazu gehören auch das Erkennen der installierten Server und die Erstellung logischer Server-Gruppen. Die Konsole dient zur Bereitstellung, der Überwachung der Performance und und der Diagnose der Tomcat Applicationen. Weiterhin können damit alle Tomcat Instanzen konfiguriert und ferngesteuert werden.

Detaillierte Funktionen der Administrationskonsole:

  • Überblick über alle Tomcat Instanzen und die Laufzeitumgebung der Anwendungen
  • Fernzugriff auf die Tomcat Instanzen zum Starten und Stoppen der Anwendungen
  • Zentralisierte Verwaltung aller Anwendungen und Versionen
  • Vollständiges Audit der Serveraktivitäten und Auswertung der Serverlogs
  • Userverwaltung inkl. Sicherheitsmodell

Tomcat Konfigurationsmanagement

Mit Cloudcat können Konfigurationsprofile erstellt werden. Dabei handelt es sich um eine Reihe von Konfigurationsdateien die in einem Schritt auf mehrere Tomcat Instanzen angewendet werden können. Das sorgt für eine konsistente Konfiguration über mehrere Instanzen hinweg. Darüber hinaus können die Umgebungsvariablen (wie z.B. JAVA_OPTS, CATALINA_BASE, etc.) auf jeden einzelnen Tomcat Server angeschaut und modifiziert werden.

Bearbeiten der Konfigurationsdateien auf einem Tomcat Server.

Erstellen eines Konfigurationsprofiles für mehrere Server.

Neustart von einem oder mehreren Tomcat Servern.

Detaillierte Funktionen des Konfigurationsmanagement:

  • Betrachten und Ändern der Tomcat Konfiguration und Umgebungseinstellungen.
  • Erstellen von Konfigurationsprofilen für komplexe Anwendungen.
  • Neustart der Tomcat Instanzen per Fernzugriff.

Anwendungsbereitstellung auf dem Tomcat

Mit Cloudcat können Anwendungen schnell innerhalb der Tomcat Umgebung bereitgestellt werden. Weiterhin steht ein Versionsmanagement zur Verfügung, mit dem mehrere Versionen einer Anwendung verwaltet werden können.

Detaillierte Funktionen der Anwendungsbereitstellung:

  • Deployment einer war-Datei vom Cloudcat Repository für einen Server oder eine Gruppe von Server.
  • Erstellen von Paketen für das Deployment von mehreren war-Datein für einen Server oder eine Gruppe von Server.
  • Echtzeitstatus und historischer Überblick der Deployments aller Anwendungen.
  • Möglichkeiten zum Roll-Back von bereits durchgeführten Deployments.

Tomcat Überwachung und Diagnose

Cloudcat verfügt über eine Vielzahl von Möglichkeiten zur Diagnose und Überwachung der Performance von Web Anwendungen innerhalb des Tomcats.

Detaillierte Funktionen zur Überwachung und Diagnose:

  • Überblick über alle wichtigen Informationen des Systems, wie die aktuelle Speicherauslastung, Informationen zum Betriebssystem oder Systemeinstellungen.
  • Echtzeitstatistiken der Anwendungen, wie der aktuelle Status, Aktivitäten, Einsatz der Datenbanken oder Anzahl der Zugriffe pro Session.
  • Zugriff und Auswertung der Serverlogs per Fernzugriff.
  • Überblick zu Informationen des Systemverhaltens in Echtzeit. Dazu gehören u.a. die aktuell laufenden Threads oder der Status der Konnektoren.
  • Überwachung des Serverstatus, dazu gehören Tests bzgl. der Datenquellen, Arbeitsspeicher, Dateierstellung und Test der Anwendungen.

Quelle

Categories
Tutorials @de

Installation einer Private Cloud mit OpenNebula

Dieser Artikel beschreibt das Einrichten einer Private Cloud mit OpenNebula auf Ubuntu. Die Infrastruktur besteht dabei aus drei physikalischen Maschinen. Einem Front-End und zwei Nodes, auf denen die virtuellen Maschinen ausgeführt werden. Auf den Nodes muss zusätzlich eine Bridge konfiguriert werden, damit die virtuellen Maschinen das lokale Netzwerk erreichen können. Für das Einrichten der Brigde siehe den Bereich Bridging.

Installation

Auf dem System für das Front-End installieren wir OpenNebula mit folgendem Befehl:

sudo apt-get install opennebula

Für jeden Node installieren wir den OpenNebula-Node:

sudo apt-get install opennebula-node

Um später die SSH Schlüssel zu kopieren, benötigt der oneadmin (wird von OpenNebula erstellt) ein Passwort. Dazu führen wir auf jeder Maschine folgenden Befehl aus:

sudo passwd oneadmin

Nachfolgend müssen die Namen für node01 und node02 entsprechend der eigenen Installation angepasst werden.

Nun kopieren wir den SSH Schlüssel des oneadmin auf jeden Node und in die Datei authorized_keys des Front-Ends.

sudo scp /var/lib/one/.ssh/id_rsa.pub oneadmin@node01:/var/lib/one/.ssh/authorized_keys
sudo scp /var/lib/one/.ssh/id_rsa.pub oneadmin@node02:/var/lib/one/.ssh/authorized_keys
sudo sh -c "cat /var/lib/one/.ssh/id_rsa.pub >> /var/lib/one/.ssh/authorized_keys"

Der SSH Schlüssel jedes Nodes muss in die Liste der bekannten Hosts unter /etc/ssh/ssh_known_hosts auf dem Front-End hinzugefügt werden. Nun muss die SSH Session beendet werden und der SSH Schlüssel von ~/.ssh/known_hosts nach /etc/ssh/ssh_known_hosts kopiert werden.

sudo sh -c "ssh-keygen -f .ssh/known_hosts -F node01 1>> /etc/ssh/ssh_known_hosts"
sudo sh -c "ssh-keygen -f .ssh/known_hosts -F node02 1>> /etc/ssh/ssh_known_hosts"

Diese Schritte erlauben dem oneadmin SCP ohne ein Passwort oder manuellen Eingriff zu nutzen, um eine Image auf den Nodes bereitzustellen.

Auf dem Front-End muss ein Verzeichnis zum Speichern der Images für die virtuellen Maschinen erstellt und dem oneadmin Zugriff auf das Verzeichnis gegeben werden.

sudo mkdir /var/lib/one/images
sudo chown oneadmin /var/lib/one/images/

Nun kann eine virtuelle Maschine in das Verzeichnis /var/lib/one/images kopiert werden.

Eine virtuelle Maschine auf Basis von Ubuntu kann mit dem vmbuilder erstellt werden, siehe dazu JeOS and vmbuilder.

Konfiguration

Der OpenNebula Cluster kann nun konfiguriert werden. Weiterhin können virtuelle Maschinen dem Cluster hinzugefügt werden.

Auf dem Front-End geben wir dazu folgenden Befehl ein:

onehost create node01 im_kvm vmm_kvm tm_ssh
onehost create node02 im_kvm vmm_kvm tm_ssh

Als nächstes erstellen wir eine Template-Datei mit dem Namen vnet01.template für das virtuelle Netzwerk:

NAME = "LAN"
TYPE = RANGED
BRIDGE = br0
NETWORK_SIZE = C
NETWORK_ADDRESS = 192.168.0.0

Die NETWORK_ADDRESS sollte dem eigenen lokalen Netzwerk entsprechen.

Mit dem onevnet Befehl fügen wir das virtuelle Netzwerk OpenNebula hinzu:

onevnet create vnet01.template

Jetzt erstellen wir eine Template-Datei für eine virtuelle Maschine mit dem Namen vm01.template:

NAME = vm01

CPU = 0.5
MEMORY = 512

OS = [ BOOT = hd ]

DISK = [
source = "/var/lib/one/images/vm01.qcow2",
target = "hda",
readonly = "no" ]

NIC = [ NETWORK="LAN" ]

GRAPHICS = [type="vnc",listen="127.0.0.1",port="-1"]

Mit dem Befehl onevm starten wir die virtuelle Maschine:

onevm submit vm01.template

Mit dem Befehl onevm list können wir weitere Informationen über die gestarteten virtuellen Maschinen abfragen. Mit dem Befehl onevm show vm01 erhalten wir detaillierte Informationen zu einer bestimmten virtuellen Maschine.

Quelle

Categories
Analysen

Eigenschaften einer Cloud Platform

Ich habe bisher einige Cloud Computing Plattformen, darunter openQRM, OpenNebula oder OpenECP vorgestellt und ein paar weitere werden noch folgen. Daher erläutere ich in diesem Artikel die grundsätzlichen Eigenschaften die eine Cloud Plattform (meiner Meinung nach) hat bzw. haben sollte.

1. Zunächst sollten ausreichend virtualisierte Serverressourcen zur Verfügung stehen. Weiterhin müssen, (vor allem dann) wenn sich mehrere Kunden auf einem System befinden, jedem Kunden diese virtualisierten Serverressourcen garantiert werden und die einzelnen virtuellen Instanzen isoliert und damit vollständig von einander getrennt betrieben werden.

2. Zum Bereitstellen von umfangreichen Enterprise-Class-Services wie z.B. hohe Verfügbarkeit, Systemwiederherstellungen nach Datenverlusten, automatische Skalierung während Lastspitzen und Ressourcenoptimierungen muss eine große (unbegrenzte) Menge an virtualisierten Serverressourcen vorhanden sein.

3. Für ein zustandsbehaftetes Lifecycle Management, wozu Snapshots, schnelles Cloning (duplizieren) und eine dynamische Versorgung mit Ressourcen über große Server Infrastrukturen gehören, wird ein virtualisierter Cloud Speicher benötigt.

4. Für die Anpassung der virtuellen Topologie – durch das Hinzufügen weiterer Netzwerkfunktionen für Sicherheit, Routing, Load Balancing, Application Firewalls, Protokol Optimierung, etc. in den OSI Schichten 3 bis 7 – und die Möglichkeit die jeweiligen (Teil)-Netzwerke auf Multi-Kunden Systemen zu isolieren und Ressourcen zu garantieren, werden virtuelle Netzwerk Ressourcen benötigt.

5. Es müssen umfangreiche und offene APIs zur Kontrolle sämtlicher Ressourcen vorhanden sein, damit Cloud Computing Anbieter ihren Kunden die vollständige Kontrolle über deren privaten virtuellen Rechenzentren anbieten können.

6. Die Cloud Plattform muss für allen gängigen Virtualisierungs-Plattformen vollständige Kompatibilität bieten und jede virtuelle Maschine unterstützen, um u.a. einen Vendor Lock-in zu vermeiden. Des Weiteren müssen Funktionen für die Migration von virtuellen Maschinen zwischen unterschiedlichen Virtualisierungs-Technologien (P2V, V2P und V2V) vorhanden sein.

7. Zu guter letzt sollte die Cloud Plattform auf Open Source basieren, um eine größtmögliche Kompatibilität zu allen möglichen Clouds aufzuweisen und um einfach adaptiert und angenommen zu werden.

Categories
Services @de

OpenECP

Sam Johnston hat mit OpenECP (Open Elastic Computing Platform) einen Fork von Enomalys ECP entwickelt und veröffentlicht, den ich in diesem Artikel vorstelle.

Bei OpenECP handelt es sich um einen Open Source Fork von Enomaly’s Elastic Computing Platform (ECP), welche im November 2009 kommerzialisiert wurde. Der Fork beinhaltetdabei die vollständige ECP und behebt darüber hinaus einige schwerwiegende Sicherheitslücken.

OpenECP ist eine Web basierte Management Plattform für Linux basierte Hypervisor, einschließlich KVM und Xen und kann dafür genutzt werden um Public und Privat Cloud Computing Umgebungen aufzubauen.

OpenECP soll immer frei verfügbar sein, weshalb es unter die Affero General Public License v3 gestellt wurde.

Funktionen

  • Unterstützung von Xen, KVM, Qemu, OpenVZ und Amazon EC2
  • Unterstützung von mehreren OpenECP Server
  • REST Web Service API
  • Ein Dashboard zur Auswertung und Steuerung (Last-Ausgleich)
  • Automatisiertes Deployment von virtuellen Maschinen

Screenshots

OpenECP Cluster Manager

OpenECP Repository

OpenECP User Manager

Quelle

Vielen Dank auch an Andre Westbunk

Categories
Services @de

Enomaly's Elastic Computing Platform

Enomaly’s Elastic Computing Platform (ECP) dient Internet Carriern, Hosting-Providern und deren Kunden dazu, die Stärken von Cloud Computing, wie Flexibilität und Kosteneinsparungen zu nutzen. Mit ECP können vollständige Cloud Computing Plattformen verwaltet und Infrastrukturen on-Demand bereitgestellt werden. Weitere Möglichkeiten bestehen in der dynamischen Versorgung mit Ressourcen und der Skalierung nach Bedarf.

Enomaly’s Elastic Computing Platform bietet folgende Funktionen:

Unbegrenzte Skalierbarkeit
Mit der ECP Architektur können große Cloud Plattformen über mehrere Rechenzentren in unterschiedlichen geographischen Regionen hinweg aufgebaut werden.

Eigene Konfigurationsmöglichkeiten für die optimale Anpassung an das Unternehmen
Unternehmen können, unterstützt durch eine Echtzeit-Überwachung, sowie umfangreichen Befehls- und Kontrollmöglichkeiten, ihre Cloud Infrastrukturen bzgl. Lastspitzen entsprechend anpassen.

Sicherheit trotz mehrerer unterschiedlicher Nutzer auf einer Plattform
Auf Basis von sehr fein granular einstellbaren Zugriffskontrollen kann ein Benutzer den Zugriff auf die Cloud Plattform (für Multi-User) so einstellen, dass nur die jeweils eigenen Ressourcen eingesehen und verwaltet werden können. Darüber hinaus kann ein Anbieter eine unbegrenzte Anzahl von VLANs für jeden Kunden erstellen und damit das Netzwerk zwischen mehreren Kunden so aufteilen und die Teilnetzwerke so isolieren, dass jedem Kunden innerhalb der Cloud die Privatsphäre seiner Daten garantiert wird. Ein Quota System schützt die Cloud gegen den Missbrauch.

Automatisierte Versorgung mit Ressourcen
ECP verfügt über eine Regelbasis zur automatischen Versorgung mit Ressourcen und kann damit den optimalen Standort einer virtuellen Anwendung bestimmen. Dazu stellt ECP sicher, dass ein Node einem optimalen physikalischen als auch virtuellen Standort zugeordnet ist. Weiterhin ist ECP in der Lage, ein offline Image einer virtuellen Maschine zu ändern, um den Speicherplatz, die Vernetzung, den Zustand des Clusters, etc. für schnelle Deployments und Off-Site Migrationen vorzunehmen.

Integration in vorhandene Infrastrukturen
ECP verfügt über eine API, mit der Benutzer die Verwaltung ihrer Cloud Infrastruktur automatisieren können, um z.B. externe SLAs oder andere Systeme für die Verwaltung zu integrieren. Darüber hinaus stellt ECP eine Back-Office API bereit, mit der weitere Systeme zur Ressourcenversorgung und Abbrechnung von (anderen) Anbietern integriert und administrative Aufgaben automatisiert werden können.

Integration von ECP im Rechenzentrum

Quelle

Categories
Services @de

Die Xen Cloud Platform

In diesem Artikel stelle ich die Xen Cloud Platform (XCP) vor, die im August 2009 erstmals veröffentlicht wurde. Dabei handelt es sich um eine Initiative, mit der eine vollständige Open Source Lösung auf Basis einer von der Industrie unterstützenden API für Cloud Anbieter zur Verfügung stehen soll. Mit einer XCP Infrastruktur sollen andere Open Source Projekte wie z.B. Eucalyptus, Convirture, OpenNebula, OpenXenCenter, Xen VNC Proxy, und Nimbus in der Lage sein den Xen Hypervisor besser nutzen zu können, in dem die neue API speziell auf das Cloud Computing ausgerichtet ist.

Die Xen Cloud Platform versteht sich als eine Kombination der Eigenschaften der Xen Virtualisierung Platform (Mobilität, Offenheit, Isolation und der Möglichkeit mehrere Instanzen parallelen auszuführen) mit neuen und verbesserten Speicher-, Sicherheits- und Netzwerk- Virtualisierungstechnologien. Damit soll eine Vielzahl von virtuellen Infrastruktur Cloud Services angeboten werden können. Darüber hinaus werden Anforderungen bzgl. der Sicherheit, Verfügbarkeit, Performance und Isolation von Hybrid Clouds erfüllt.

Aktuelle Funktionen

  • Xen 3.4.1
  • Linux 2.6.27 Kernel
  • Windows PV Treiber, Microsoft Zertifiziert
  • XAPI Enterprise-class Management Tool Stack
    • Lebenszyklus einer virtuellen Maschine: Live Snapshots, Checkpoint, Migration
    • Ressourcen Pools: Sichere Neuverteilung (Live), Autokonfiguration, DR
    • Host Konfiguration: Flexibles Speichermanagement, Netzwerkbetrieb, Power Management
    • Verfolgen von Ereignissen: Fortschritt, Benachrichtigung
    • Sichere Kommunikation durch SSL
    • Möglichkeit für Upgrades und Patching
    • Überwachung und Benachrichtung bzgl. der Perfomance in Echtzeit
  • Unterstützung von Single-Root I/O Virtualization
  • Installation des Host per CD-ROM und Netzwerk
  • Vollständige “xe” Kommandozeile und Web Service API
  • Openvswitch
  • Fehlertoleranz (Marathon FT products)
  • VNC Console Proxy und Web Front-End
  • Unabhängiges Front-End

Roadmap für XCP 1.0

  • VSwitch Integration
    Mehrere Nutzer einer Netzwerkinfrastruktur; Übernahme der Firewall- und Routingregeln von migrierten virtuellen Maschinen; Flexible Überwachung des Datenverkehrs von virtuellen Ports
  • Netchannel 2 Integration
    Verbesserung der Skalierbarkeit der Xen Vernetzung auf größeren Systemen; Beschleunigung des Datenverkehrs zwischen virtuellen Maschinen
  • Single-Root I/O Virtualization (SR-IVO) Vernetzung
    Xen unterstützt bereits SR-IVO Netzwerkkarten, allerdings müssen diese noch manuell konfiguriert werden.
  • Starten der Gast Systeme von SR-IOV Host-Bus-Adapters (HBAs)
  • Libvirt bindings
  • Native Unterstützung für das Open Virtualization Format (OVF)
  • DMTF (Distributed Management Task Force) Standards für Virtualisierung und Cloud
  • Intelligente Fehlerbehebung um die Auswirkungen von Hardware-Fehlern zu minimieren
  • Unterstützung von Web-basierten Management mehrere Nutzer für unterschiedliche Anbieter wie z.B. Eucalyptus, Enomaly oder OpenNebula
  • Verbesserung der Skalierbarkeit des Managements für die Verwaltung von mehr als 1.000 Xen-Hosts
  • Zusammenschluss von günstigen lokalen Speicher durch die Integration von DRDB und Parallax
  • Oracle Cluster File System 2 (ocfs2) Integration

Quelle

Xen Cloud Platform

Categories
Tutorials @de

Erste Schritte mit Amazon EC2 – Windows

Dieses Tutorial beschreibt das Einrichten einer virtuellen Instanz mit einem Windows Server 2008 AMI (Amazon Machine Image) auf Basis der Amazon Elastic Compute Cloud (Amazon EC2). Dazu gehören die vollständige Einrichtung der Instanz und der anschließende Zugriff per Remote Desktop Verbindung von einem Windows 7 Computer.

Voraussetzungen

  • Amazon Web Service Account
  • Amazon EC2 ist für den Account bereits aktiviert
  • RDP Client

Auswahl, Einrichten und Starten der Instanz

Zuerst öffnen wir die Webseite der Amazon Web Services und melden uns dort an.

Anschließend starten wir die AWS Management Console für EC2.

Hier klicken wir auf Launch Instance.

Ein weiteres Fenster öffnet sich, in dem bereits fertig vor-konfigurierte Amazon Machine Images (AMIs) von Amazon angezeigt werden. Hier wählen wir das erste AMI – Getting Started on Microsoft Windows Server 2008 (AMI Id: ami-a4698bcd)

Nun wählen wir folgende Konfiguration:

  • Number of Instances: 1
  • Availability Zone: No Preference
  • Instance Type: Small (m1.small 1.7 GB)

Als erweiterte Konfiguration wählen wir:

  • Kernel ID: Use Default
  • RAM Disk ID: Use Default
  • Monitoring: Nein

Anschließend erstellen wir ein Schlüsselpaar, hier mit dem Namen clouduser_key und speichern es auf unserem Rechner.

Im nächsten Schritt konfigurieren wir die Firewall, indem wir für unsere AMI eine Security Group erstellen. Die Standardvorgabe ist der externe Zugriff auf die Ports 3389 (RDP), MS SQL Server (1433) und 80 (HTTP). Die Freigaben für den Port 80 und 1433 habe ich entfernt, da wir sie in diesem Fall nicht benötigen. Wir geben der Security Group einen Namen, hier Security_Group_2 und eine Beschreibung, hier RDP_Only und wählen continue.

Danach erhalten wir eine Zusammenfassung unserer Konfiguration, wo wir mittels Launch unsere Instanz starten.

Über Your instances are now launching kommen wir zur Console zurück.

Dort sehen wir, dass unsere soeben erstellte Instanz aktiv ist und wir uns nun mit ihr verbinden können. Dazu notieren wir uns zunächst den Namen in der Spalte Public DNS.

Verbinden mit der Instanz

Um uns mit der Instanz zu verbinden öffnen wir zunächst die Datei mit unserem erstellten Private Key und kopieren den gesamten Inhalt inkl. der Kommentare —–BEGIN RSA PRIVATE KEY—– und —–END RSA PRIVATE KEY—–.

Nun gehen wir zurück zur AWS Management Console, klicken mit der rechten Maustaste auf die Instanz und wählen Get Windows Password

In das Feld Private Key* fügen wir den privaten Schlüssel inkl. der Kommentare —–BEGIN RSA PRIVATE KEY—– und —–END RSA PRIVATE KEY—– ein.

Nach dem Klick auf Decrypt Password wird uns der Benutzername und das Passwort für die Anmeldung an unserer Instanz angezeigt.

Jetzt öffnen wir die Remote Desktop Verbindung und tragen dort den Public DNS Namen ein.

Nach dem Klick auf Verbinden geben wir den Benutzernamen und das Passwort, das wir oben erhalten haben, ein.

Die Verbindung wird hergestellt.

Nun müssen wir noch das Zertifikat unserer Instanz akzeptieren.

Wir sind mit unserer Instanz verbunden.

Beenden der Instanz

Um die Instanz wieder zu beenden gehen wir zurück zu der AWS Management Console klicken mit der rechten Maustaste auf die Instanz und wählen Terminate.

Nach dem Bestätigen wird die Instanz beendet.

In der AWS Management Console ist am gelben Punkt zu sehen, dass die Instanz beendet wird. Das benötigt ein wenig Zeit.

Categories
Tutorials @de

Erste Schritte mit Amazon EC2 – Linux

Dieses Tutorial beschreibt das Einrichten einer virtuellen Instanz mit einem Fedora Linux AMI (Amazon Machine Image) auf Basis der Amazon Elastic Compute Cloud (Amazon EC2). Dazu gehören die vollständige Einrichtung der Instanz und der anschließende Zugriff per SSH von einem Windows 7 Computer.

Voraussetzungen

Auswahl, Einrichten und Starten der Instanz

Zuerst öffnen wir die Webseite der Amazon Web Services und melden uns dort an.

Anschließend starten wir die AWS Management Console für EC2.

Hier klicken wir auf Launch Instance.

Ein weiteres Fenster öffnet sich, in dem bereits fertig vor-konfigurierte Amazon Machine Images (AMIs) von Amazon angezeigt werden. Hier wählen wir das erste AMI – Getting Started on Fedora Core 8 (AMI Id: ami-b232d0db)

Nun wählen wir folgende Konfiguration:

  • Number of Instances: 1
  • Availability Zone: No Preference
  • Instance Type: Small (m1.small 1.7 GB)

Als erweiterte Konfiguration wählen wir:

  • Kernel ID: Use Default
  • RAM Disk ID: Use Default
  • Monitoring: Nein

Anschließend erstellen wir ein Schlüsselpaar, hier mit dem Namen clouduser_key und speichern es auf unserem Rechner.

Im nächsten Schritt konfigurieren wir die Firewall, indem wir für unsere AMI eine Security Group erstellen. Die Standardvorgabe ist der externe Zugriff auf die Ports 22 (SSH) und 80 (HTTP). Die Freigabe für den Port 80 habe ich entfernt, da wir sie in diesem Fall nicht benötigen. Wir geben der Security Group einen Namen, hier Security_Group_1 und eine Beschreibung, hier SSH_Only und wählen continue.

Danach erhalten wir eine Zusammenfassung unserer Konfiguration, wo wir mittels Launch unsere Instanz starten.

Über Your instances are now launching kommen wir zur Console zurück.

Dort sehen wir, dass unsere soeben erstellte Instanz aktiv ist und wir uns nun mit ihr verbinden können. Dazu notieren wir uns zunächst den Namen in der Spalte Public DNS.

Verbinden mit der Instanz

Um uns mit der Instanz zu verbinden starten wir zunächst PuTTYgen und laden uns über Load den privaten Schlüssel den wir uns oben erstellt haben.

Wenn dieser geladen ist, klicken wir auf Save private Key und ignorieren das Fenster mit der Passphrase!

Jetzt öffnen wir unseren PuTTY SSH Client und tragen den Public DNS Namen in das Feld Host Name. Der Port 22 (SSH) ist der Standardwert.

Wir navigieren im PuTTY SSH Client auf der linken Seite zu dem Punkt SSH >> Auth. Dort laden wir bei dem Punkt Authentication parameters unseren oben mit PuTTYgen erzeugten privaten Schlüssel.

Nach einem klick auf Open wird eine Verbindung zu unserer Instanz hergestellt.

Dort melden wir uns mit dem Benutzer root an. Nun können wir mit unserer erstellten Linux Instanz arbeiten.

Beenden der Instanz

Um die Instanz wieder zu beenden gehen wir zurück zu der AWS Management Console klicken mit der rechten Maustaste auf die Instanz und wählen Terminate.

Nach dem Bestätigen wird die Instanz beendet.

In der AWS Management Console ist am gelben Punkt zu sehen, dass die Instanz beendet wird. Das benötigt ein wenig Zeit.

Categories
Tutorials @de

Ein Cloud Desktop mit openQRM

Nachdem ich eyeOS in zwei Artikeln ausführlich vorgestellt habe, möchte ich in diesem Artikel eine weitere interessante Möglichkeit aufzeigen, einen persönlichen Cloud Desktop zu nutzen. Dazu dient das von mir ebenfalls schon vorgestellte Cloud Management Tool openQRM, auf dessen Portal Webseite (http://www.openqrm-portal.de) ich die Idee (von Matt Rechenburg beschrieben) entdeckt habe.

Cloud Desktops wie auch Desktop-Virtualisierung sind für mich die Megatrends der Zukunft, die bei jedem auf der Roadmap stehen sollten!

Um uns einen Cloud Desktop mit openQRM zu erstellen gehen wir wir folgt vor:

1. Bestellen einer Cloud Appliance von openQRM

Zunächst legt man sich einen Account unter https://demo.openqrm.com und erstellt einen neuen Cloud-Request.

2. Installation von vncserver und Gnome auf der Cloud Appliance

Die Pakete vnc4server, xorg und gnome müssen per apt-get auf der Cloud Appliance wie folgt installiert werden.

root@cloud-91-1-x:~# apt-get install tightvncserver vnc4server xorg gnome

3. Erstellen eines VNC Users

Mit dem Befehl adduser wird ein neuer Benutzer erstellt.

root@cloud-91-1-x:~# adduser matt
Adding user `matt' ...
Adding new group `matt' (1001) ...
Adding new user `matt' (1001) with group `matt' ...
Creating home directory `/home/matt' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for matt
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [y/N] y
root@cloud-91-1-x:~#

Danach mit dem su Befehl zum eben erstellten Benutzer wechseln.

root@cloud-91-1-x:~# su - matt
matt@cloud-91-1-x:~$

4. Erstellen einer VNC Passwortdatei

Mit dem vnc4passwd Tool wird eine neue VNC Passwortdatei erzeugt.

matt@cloud-91-1-x:~$ vnc4passwd
Password:
Verify:
matt@cloud-91-1-x:~$

5. Erstellen eines xstartup Skript

Für den automatischen Start einer Gnome Session nach dem VNC-Login muss eine xstartup Datei im .vnc/ Verzeichnis angelegt werden.

matt@cloud-91-1-x:~$ vi .vnc/xstartup
matt@cloud-91-1-x:~$ cat .vnc/xstartup
#!/bin/sh

xrdb $HOME/.Xresources
xsetroot -solid grey
gnome-session &

matt@cloud-91-1-x:~$

Die Datei muss nun noch ausführbar gemacht werden.

matt@cloud-91-1-x:~$ chmod -x
matt@cloud-91-1-x:~$ .vnc/xstartup

6. Start des vncserver

Nun muss der vncserver gestartet werden.

matt@cloud-91-1-x:~$ tightvncserver
xauth: creating new authority file /home/matt/.Xauthority

Creating default startup script /home/matt/.vnc/xstartup
Starting applications specified in /home/matt/.vnc/xstartup
Log file is /home/matt/.vnc/cloud-91-1-x:1.log

7. Verbindung mit dem Cloud Desktop herstellen

Mit einem vncviewer Tool (Linux/Windows) kann man sich nun mit dem Befehl vncviewer[IP-Adresse der Cloud-Appliance]:1 mit dem Gnome Desktop in der Cloud verbinden.

matt@matt-laptop:~$ vncviewer x.x.x.x:1

Nach der Anmeldung steht ein vollständiger Gnome Desktop in der Cloud zur Verfügung.

Quelle

Your Desktop in the Cloud (DE)

Categories
Tutorials @de

Skalierung eines Cluster mit Amazon EC2

Dieses Beispiel zeigt welche Komponenten erstellt und konfiguriert werden müssen, um einen Mini Cluster innerhalb eines privaten Netzwerks unter der Verwendung von NIS und NFS aufzubauen. Zusätzlich werden externe Amazon EC2 Nodes per VPN mit dem Server verbunden und am Ende der Cluster mittels der Sun Grid Engine (SGE) aufgebaut.

Architektur

Folgende technische Voraussetzungen werden benötigt:

  • Das private Netzwerk darf nur über ein VPN erreichbar sein, damit die Nodes die sich darin befinden vollständig isoliert sind.
  • Der Server muss NFS, NIS und VPN unterstützen.
  • Die internen Nodes müssen den NFS und NIS Dienst automatisch vom Server starten.
  • Die externen Nodes sind von Amazon EC2.
  • Die externen Nodes müssen automatisch eine Verbindung in das VPN aufbauen und den NFS und NIS Dienst vom Server starten.

Auf Basis dieser Anforderungen werden 3 Images benötigt.

  • 2 Xen Images – einen Server und einen internen Node
  • 1 Amazon Machine Image (AMI) von Amazon EC2 mit derselben Konfiguration wie der interne Node.

Die Konfigurationen sehen in diesem Beispiel wie folgt aus:

Server

  • Private IP-Adresse: eth0 10.1.1.99
  • Öffentliche IP-Adresse: eth1 147.96.1.100
  • Hostname: oneserver

Xen Node (lokal)

  • Private IP-Adresse: eth0 10.1.1.55
  • Hostname: local01

Amazon EC2 Node (IP-Adress Bereich: 10.1.1.100 bis 10.1.1.254)

  • VPN IP-Adresse: tap0 10.1.1.100 (wird durch den VPN Server vergeben)
  • Öffentliche IP-Adresse: eth0 – wird automatisch von Amazon vergeben
  • Hostname: workernode0

Konfiguration

Konfiguration der Images

Nun wird eine Kopie des Image erstellt und die /etc/hostname und /etc/network/interfaces für den Server (oneserver) editiert. Eine weitere Kopie des Image dient als Node, die oben genannten Dateien müssen für diesen ebenfalls angepasst werden. Nach dem unmount der Images werden diese mit Xen gestartet. Für die Konfiguration von NFS und NIS helfen die beiden nachfolgend verlinkten Howtos.

Bei der Konfiguration des VPN Server ist darauf zu achten, dass alle Clients die Zertifikate doppelt verwenden können. Das liegt daran, da keine separaten Amazon EC2 Instanzen erstellt werden sollen und es sich bei den EC2 Instanzen daher um dieselben handelt. Dazu muss in der Konfigurationsdatei von OpenVPN /etc/openvpn/server.conf in Zeilt “duplicate-cn” eingefügt werden. Die Konfiguration von OpenVPN findet nur auf dem Server statt. Eine Howto für die Konfiguration von OpenVPN ist unter dem folgenden Link zu finden.

Für das Erstellen eines Amazon Machine Images wird der Befehl bundle benötigt, dazu kann der lokale Node genutzt werden. Weiterhin muss der VPN Client und die Sun Grid Engine installiert und konfiguriert werden. Auf dem schnellsten Wege sollte das funktionieren, indem eine Kopie des lokalen Node erstellt und konfiguriert wird, anschließend wird es mit dem Befehl ec2-bundle-image gebündelt.

Während des Boot-Vorgangs wird nun noch ein Skript benötigt, in welchem der IP-Adressbereich von OpenVPN für die Amazon EC2 Instanzen von 10.1.1.100 bis 10.1.1.254 reserviert wird. die Konfiguration erfolgt in der /etc/hosts auf dem Server (oneserver).

EC2 Konfiguration mit OpenNebula

Nach der Konfiguration werden nun die Templates benötigt, um die Maschinen zu starten. Für alle lokalen Maschinen wie den oneserver und die Nodes wird jeweils ein Template benötigt, für die EC2 Maschinen reicht ein Template aus.

clouduser@machine:bin$ ec2-describe-images
IMAGE ami-e4a94d8d one-w2/image.manifest.xml 587384515363 available private i386 machine
IMAGE ami-cdb054a4 sge-dolphin/image.manifest.xml 587384515363 available private i386 machine
IMAGE ami-d8b753b1 sge-parrot/image.manifest.xml 587384515363 available private i386 machine
IMAGE ami-dcb054b5 sge-squirrel/image.manifest.xml 587384515363 available private i386 machine

Auf Basis des Images “ami-dcb054b5” wird das EC2 Template erstellt.

CPU=1

MEMORY=1700

EC2=[ AMI="ami-dcb054b5", KEYPAIR="gsg-keypair", ELASTICIP="75.101.155.97", INSTANCETYPE="m1.small", AUTHORIZED_PORTS="22-25"]

REQUIREMENTS = 'HOSTNAME = "ec2"'

Deployment und Tests

Um den Test zu starten muss zunächst OpenNebula gestartet und der EC2 Host hinzugefügt werden.

clouduser@machine:one$ one start
oned and scheduler started
lgonzalez@machine:one$ onehost create ec2 im_ec2 vmm_ec2
lgonzalez@machine:one$ onehost list
HID NAME RVM TCPU FCPU ACPU TMEM FMEM STAT
0 ec2 0 0 100 on

Als nächstes wird die EC2 Instanz gestartet.

clouduser@machine:one$ onevm create ec2.template
ID: 0

Die virtuelle Maschine wird später automatisch auf Amazon EC2 bereitgestellt.

clouduser@machine:one$ onevm list
ID NAME STAT CPU MEM HOSTNAME TIME
0 one-0 pend 0 0 00 00:00:05
lgonzalez@machine:one$ onevm list
ID NAME STAT CPU MEM HOSTNAME TIME
0 one-0 boot 0 0 ec2 00 00:00:15

Mittels onevm show id können alle Informationen eingesehen werden.

clouduser@machine:one$ onevm show 0
VID : 0
AID : -1
TID : -1
UID : 0
STATE : ACTIVE
LCM STATE : RUNNING
DEPLOY ID : i-1d04d674
MEMORY : 0
CPU : 0
PRIORITY : -2147483648
RESCHEDULE : 0
LAST RESCHEDULE: 0
LAST POLL : 1216647834
START TIME : 07/21 15:42:47
STOP TIME : 01/01 01:00:00
NET TX : 0
NET RX : 0

....: Template :....
CPU : 1
EC2 : AMI=ami-dcb054b5,AUTHORIZED_PORTS=22-25,ELASTICIP=75.101.155.97,INSTANCETYPE=m1.small,KEYPAIR=gsg-keypair
IP : ec2-75-101-155-97.compute-1.amazonaws.com
MEMORY : 1700
NAME : one-0
REQUIREMENTS : HOSTNAME = "ec2"

In diesem Beispiel ist die EC2 Instanz über die Adresse ec2-75-101-155-97.compute-1.amazonaws.com zu erreichen.

Nun muss geprüft werden, ob alle virtuellen Maschinen im Cluster gestartet sind. Es existiert eine lokale virtuelle Maschine auf Basis von Xen (local01) und eine von Amazon EC2 (workernode0).

oneserver:~# qstat -f
queuename qtype used/tot. load_avg arch states
----------------------------------------------------------------------------
all.q@local01 BIP 0/1 0.05 lx24-x86
----------------------------------------------------------------------------
all.q@workernode0 BIP 0/1 0.04 lx24-x86
----------------------------------------------------------------------------

Um den Cluster zu testen können ein paar Jobs mittels qsub an die Sun Grid Engine geschickt werden.

oneserver:~# qsub test_1.sh; qsub test_2.sh;

Nun ist zu sehen, welche Jobs im Hybrid Cluster geplant und gestartet sind.


clouduser@oneserver:~$ qstat -f
queuename qtype used/tot. load_avg arch states
----------------------------------------------------------------------------
all.q@local01 BIP 0/1 0.02 lx24-x86
----------------------------------------------------------------------------
all.q@workernode0 BIP 0/1 0.01 lx24-x86
----------------------------------------------------------------------------
############################################################################
- PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS
############################################################################
1180 0.00000 test_1.sh clouduser qw 07/21/2008 15:26:09 1
1181 0.00000 test_2.sh clouduser qw 07/21/2008 15:26:09 1

clouduser@oneserver:~$ qstat -f
queuename qtype used/tot. load_avg arch states
----------------------------------------------------------------------------
all.q@local01 BIP 1/1 0.02 lx24-x86
1181 0.55500 test_2.sh clouduser r 07/21/2008 15:26:20 1
----------------------------------------------------------------------------
all.q@workernode0 BIP 1/1 0.07 lx24-x86
1180 0.55500 test_1.sh clouduser r 07/21/2008 15:26:20 1
----------------------------------------------------------------------------

Es können beliebig viele externe Amazon EC2 Instanzen automatisch zum Cluster als Nodes hinzugefügt werden und damit die Skalierbarkeit dynamisch erhöht werden.

Quelle