Rene Buest is Gartner Analyst covering Infrastructure Services & Digital Operations. Prior to that he was Director of Technology Research at Arago, Senior Analyst and Cloud Practice Lead at Crisp Research, Principal Analyst at New Age Disruption and member of the worldwide Gigaom Research Analyst Network. Rene is considered as top cloud computing analyst in Germany and one of the worldwide top analysts in this area. In addition, he is one of the world’s top cloud computing influencers and belongs to the top 100 cloud computing experts on Twitter and Google+. Since the mid-90s he is focused on the strategic use of information technology in businesses and the IT impact on our society as well as disruptive technologies.
Rene Buest is the author of numerous professional technology articles. He regularly writes for well-known IT publications like Computerwoche, CIO Magazin, LANline as well as Silicon.de and is cited in German and international media – including New York Times, Forbes Magazin, Handelsblatt, Frankfurter Allgemeine Zeitung, Wirtschaftswoche, Computerwoche, CIO, Manager Magazin and Harvard Business Manager. Furthermore Rene Buest is speaker and participant of experts rounds. He is founder of CloudUser.de and writes about cloud computing, IT infrastructure, technologies, management and strategies. He holds a diploma in computer engineering from the Hochschule Bremen (Dipl.-Informatiker (FH)) as well as a M.Sc. in IT-Management and Information Systems from the FHDW Paderborn.
AWS Elastic Beanstalk is an even easier way for developer to quickly deploy and manage applications in the AWS cloud. They can upload their application, and Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring. At the same time, with Elastic Beanstalk, a developer retain full control over the AWS resources powering his application and can access the underlying resources at any time. Elastic Beanstalk leverages AWS services such as Amazon EC2, Amazon S3, Amazon Simple Notification Service, Elastic Load Balancing, and Auto-Scaling to deliver the same highly reliable, scalable, and cost-effective infrastructure that hundreds of thousands of businesses depend on today.
The first release of Elastic Beanstalk is built for Java developers using the familiar Apache Tomcat software stack which ensures easy portability for the application. There is no additional charge for Elastic Beanstalk – you only pay for the AWS resources needed to store and run the applications.
AWS Elastic Beanstalk Functionality
To deploy Java applications using Elastic Beanstalk, do following:
Create a application as you normally would using any editor or IDE (e.g. Eclipse).
Package a deployable code into a standard Java Web Application Archive (WAR file).
Upload the WAR file to Elastic Beanstalk using the AWS Management Console, the AWS Toolkit for Eclipse, the web service APIs, or the Command Line Tools.
Deploy the application. Behind the scenes, Elastic Beanstalk handles the provisioning of a load balancer and the deployment of the WAR file to one or more EC2 instances running the Apache Tomcat application server.
Within a few minutes you will be able to access the application at a customized URL (e.g. http://myapp.elasticbeanstalk.com/).
Once an application is running, Elastic Beanstalk provides several management features such as:
Easily deploy new application versions to running environments (or rollback to a previous version).
Access built-in CloudWatch monitoring metrics such as average CPU utilization, request count, and average latency.
Receive e-mail notifications through Amazon Simple Notification Service when application health changes or application servers are added or removed.
Access Tomcat server log files without needing to login to the application servers.
Quickly restart the application servers on all EC2 instances with a single command.
With Elastic Beanstalk, developers retain full control over the AWS resources powering their application, and can perform a variety of functions by simply adjusting default configuration settings from the Elastic Beanstalk management console, including:
Selecting the most appropriate Amazon EC2 instance type that matches the CPU and memory requirements of their application
Choosing from several available database and storage options such as Amazon RDS, Amazon SimpleDB, Microsoft SQL Server, or Oracle.
Enabling login access to Amazon EC2 instances for immediate and direct troubleshooting
Quickly improving application reliability by running in more than one Availability Zone
Enhancing application security by enabling HTTPS protocol on the load balancer
Adjusting JVM settings and passing environment variables
Running other application components, such as a memory caching service, side-by-side in Amazon EC2
Adjust Auto-Scaling settings to control the metrics and thresholds used to determine when to add or remove instances from an environment
Bereits im Oktober 2010 startete das TClouds Projekt (Trustworthy Clouds). Ein von der EU mit 7,5 Millionen Euro gefördertes Projekt. Das Gesamtvolumen des Projekts beträgt ca. 10,5 Millionen Euro und ist auf einen Zeitraum von drei Jahren ausgelegt.
Das Projektziel ist die Entwicklung eines Prototyp einer vertrauenswürdigen, zuverlässigen sowie transparenten Cloud Computing Infrastruktur. Damit soll die Verarbeitung personenbezogener und sensibler Firmendaten in der Cloud ermöglicht werden. Der Forschungsschwerpunkt besteht in der Gestaltung einer sicheren Cloud Computing Umgebung, die den europäischen Datenschutzanforderungen entspricht. Dabei sollen allerdings auf die Vorteile des Cloud Computing wie Kosteneinsparungen, Skalierbarkeit und Hochverfügbarkeit nicht verzichtet werden. Während des Projekts sollen zudem weitere neue offene Sicherheitsstandards sowie neue Cloud Computing Management Komponenten entwickelt werden.
Die TClouds Infrastruktur soll dabei in zwei Szenarien praktisch überprüft werden. Ein Test findet mit dem italienischen Krankenhaus San Raffaele in Mailand für den Gesundheitsbereich statt. Der andere Test erfolgt mit dem portugiesischen Energieversorger Energias de Portugal sowie dem Elektronikunternehmen EFACEC im Bereich von intelligenten Stromnetzen. In beiden Szenarien wird das Datenschutz und Datensicherheitsniveau der Cloud Computing Infrastruktur und der jeweiligen Anwendungen je nach Art und Sensibilität der zu verarbeiteten Daten durch entsprechende Methoden umgesetzt.
Der Ablauf des TClouds Projekts umfasst vier unabhängig geführte Aktivitäten und zwölf eng integrierte Arbeitspakete.
Aktivität A1
Legal and Business Foundations for Cross-border Computing
A1 ist zuständig für die rechtliche und regulatorische Beratung, die Folgenabschätzung bzgl. des Datenschutzes für grenzüberschreitende Clouds und tragfähige Geschäftsmodelle für Cloud-Anbieter.
Aktivität A2
Trustworthy Internet-scale Computing Platform
A2 ist verantwortlich für die TClouds Plattform. Diese Plattform umfasst vertrauenswürdige individuelle Clouds, die entweder auf erweiterte commodity Clouds oder auf erprobte (gestärkte) Cloud Computing Software basieren.
Aktivität A3
Benchmark Application & User-centric Evaluation
A3 ist verantwortlich für die Bereitstellung der Smart Power Grid und Home Healthcare Cloud Computing Szenarien sowie der selbst Erprobung und Verbesserung durch Endbenutzer und dem fachlichen Feedback von Experten.
Aktivität A4
Programme Management and Dissemination
A4 ist verantwortlich für die umfassende und wirksame Verbreitung sowie die ordnungsgemäße Verwaltung der Software, die dafür sorgt, dass alle Ergebnisse zeitnah und qualitativ hochwertig bereitgestellt werden und Konflikte nicht zu Störungen führen.
Weitere Informationen sind unter http://www.tclouds-project.eu zu finden.
TCLOUDS puts its focus on privacy protection in cross-border infrastructures and on ensuring resilience against failures and attacks. TCLOUDS aims to build prototype internet-scale ICT infrastructure which allows virtualised computing, network and storage resources over the Internet to provide scalability and cost-efficiency.
In prototype development, it is a priority to address the challenges of cross-border privacy, end-user usability, and acceptance that are essential for widespread acceptance of such an infrastructure.
Facts
Start date: 2010-10-01
End date: 2013-09-30
Duration: 36 months
Project cost: € 10.536.129,00
Project funding: € 7.500.000,00
Mission of TClouds
To develop an advanced cloud infrastructure that can deliver computing and storage that achieves a new level of security, privacy, and resilience yet is cost-efficient, simple, and scalable.
To change the perceptions of cloud computing by demonstrating the prototype infrastructure in socially significant application areas: energy and healthcare.
Motivation
State-of-the-art cloud computing enables seamless access to services and global availability of information, but inherent risks severely limit the application of this technology.
In a cloud environment, pertinent data is accessed via information and communications technology (ICT) using remote hardware instead of being stored only on a local server or computer. The benefits of increased storage at reduced cost allow information to be made readily available.
However, the current cloud computing model comes with perceived risks concerning resilience and privacy. There are three fundamental trends in ICT whose risks mutually reinforce each other:
the push towards an Internet of Services – most services are provided on the web as a platform;
cost pressures drive a migration of ICT into so-called Infrastructure clouds;
growing importance of ICT as the critical “nervous system” for socially relevant „smart“ infrastructures – such as healthcare, energy, environmental monitoring, or mobility.
Protecting data and services in the cloud is important to governments,organizations and enterprises across all industries, including healthcare, energy utilities, and banking. Thus, the perceived security and dependability risks of cloud computing are limiting its application.
The TClouds project targets cloud computing security and minimization of the widespread concerns about the security of personal data by putting its focus on privacy protection in cross-border infrastructures and on ensuring resilience against failures and attacks.
Objectives
Trustworthy Clouds (TClouds) aims to build a prototype Internetscale ICT infrastructure which allows virtualized computing, network, and storage resources over the Internet to provide scalability and cost-efficiency. The following objectives contribute to achieving the overall goal:
Identifying and addressing the legal and business implications and opportunities of a widespread use of infrastructure clouds, contributing to building a regulatory framework for enabling resilient and privacy-enhanced cross-border infrastructure clouds.
Defining an architecture and prototype for securing infrastructure clouds by providing security enhancements that can be deployed on top of commodity infrastructure clouds (as a cloudof-clouds) and assessing the resilience and privacy benefits of security extensions of existing clouds.
Providing resilient middleware for adaptive security on the cloud-of-clouds. The TClouds platform will provide tolerance and adaptability to mitigate security incidents and unstable operating conditions for a range of applications running on such clouds-of-clouds.
To demonstrate TClouds, scientists will prototype two scenarios involving critical IT- systems:
A smart energy grid with Portugal’s leading energy and solution providers Energias de Portugal and EFACEC: TClouds will show how such energy-preserving systems can be migrated to a cloud infrastructure while increasing their resilience, privacy protection and tolerance against both hackers and hardware failures.
A patient-centric home healthcare service with San Raffaele Hospital in Milano, Italy, will remotely monitor, diagnose and assist patients outside a hospital setting. TClouds will demonstrate how the quality of in-home healthcare can be improved cost-efficiently without reducing privacy.
Strategy
The work plan of TClouds encompasses four independently managed Activities and twelve tightly integrated Work Packages.
Activity A1:
Legal and Business Foundations for Cross-border Computing
A1 is responsible for legal and regulatory guidance, the privacy impact assessment for cross-border clouds, and viable business models for cloud providers.
Activity A2:
Trustworthy Internet-scale Computing Platform
A2 is responsible for the TClouds platform. This platform includes trustworthy individual clouds that are based either on extending commodity clouds or on strengthening cloud operation software.
Activity A3:
Benchmark Application & User-centric Evaluation
A3 is responsible for delivering the Smart Power Grid and Home Healthcare cloud scenarios as well as self-evaluation and self improvement through end-user and expert feedback.
Activity A4:
Programme Management and Dissemination
A4 is responsible for wide and effective dissemination as well as the proper programme management that ensures timely and high-quality delivery of all results while mitigating emerging conflicts.
Source and more information at http://www.tclouds-project.eu.
Der CloudOps Summit 2010 am 17.03.2011 will den Focus auf den Betrieb und die Architektur von Cloud Computing Infrastrukturen legen und eine Brücke zwischen den bislang oft Marketing-getriebenen Angeboten hin zum Betrieb und den Architekten solcher Lösungen schlagen. Unter dem Motto “Run your Cloud” wollen die Veranstalter besonders das Thema “Betrieb von dynamischen und cloud-basierten Infrastrukturen” in den Vordergrund stellen und die Teilnehmer zu einer intensiven Diskussion einladen.
Nach einer Serie von Lightning Talks von 5 bis 7 Minuten Länge, sollen die Teilnehmer im Rahmen von 4 Workshop-Tracks mit jeweils 2 Vorträgen die Gelegenheit haben, die Themen zu vertiefen. Die Workshop-Tracks sind wie folgt strukturiert:
Track 1 – Management
Datenschutz/Datensicherheit
Compliance
Strategien
Nachhaltigkeit
Dieser Track wird den Schwerpunkt auf Themen legen, mit den sich heute die Vorstände und IT-Strategen befassen müssen, um für einen erfolgreichen und nachhaltigen Einsatz von Cloud Computing im Unternehmen vorbereitet zu sein. Auch wird hier Raum für die Diskussion wirtschaftlichen und ökonomischen Aspekte und der damit verbundenen Chancen des Cloud Computing Paradigmas für Unternehmen sein.
Track 2 – Operations
Anbieter/Lösungen/Tools
Herausforderungen bei der Umsetzung
Migration
Im Operationstrack wollen die Veranstalter die Diskussion auf Erfahrungen bei Durchführung von konkreten Cloud Computing Projekten diskutieren und besonders auf Hindernisse, Herausforderungen und Werkzeuge eingehen. Ein weiterer Schwerpunkt wird die Migration existierender Anwendungen sein.
Track 3 – Architecture
Best Practices/Methoden
Standards/Zertifizierung
Open Source
Dieser Track soll Diskussionen um die Standardisierung und ‘Best Practices’ von Cloud Computing Lösungen und Architekturen umfassen und auch auf damit verbundene Themen wie Stacks, Plattformen und Open Source eingehen.
Track 4 – Investors/Startups
Elevator Pitches
Im Rahmen der Elevator Pitches wird ausgesuchten Startups die Gelegenheit gegeben sich und Ihre Cloud Computing Lösungen oder Projekte vorzustellen. Die Veranstalter wollen so die Chancen des Cloud Computing aufzeigen und entsprechende Firmen und Produkte präsentieren, die allen auf dem Weg in die Clouds begleiten werden.
Weitere Informationen und die Anmeldung sind auf http://cloudops.cloudcontrolled.com zu finden.
Die Amazon Web Services haben am gestrigen Donnerstag neue Premium Support Angebote vorgestellt und angekündigt eine 50-prozentige Preissenkung auf den bestehenden Premium Support zu erlassen.
Für Entwickler wurde ein Bronze Support Angebot vorgestellt. Es bietet Unterstützung an Werktagen mit einer Reaktionszeit von 12 Stunden. Die Kosten betragen dabei 49 Dollar pro Monat.
Ein neuer Platinum Tarif richtet sich an Großunternehmen, welcher eine 15-minütige Reaktionszeit für kritische Fragen bietet. Dazu gehört ebenfalls ein Account Manager, der über ein breites AWS Fachwissen verfügt und die Kunden im Bedarfsfall individuell hinsichtlich ihrre Bedürfnisse berät und damit als primäre Anlaufstelle bei AWS dient. Der Platinum Support kostet mehr als 15.000 Dollar pro Monat oder 10 Prozent der monatlichen AWS Nutzungsentgelte des Kunden.
Der Silver Support bietet für über 100 Dollar pro Monat oder für 5 Prozent der monatlichen AWS Nutzungsentgelte des Kunden einen Support an Werktagen inkl. einer Reaktionszeit von 4 Stunden.
Mit dem Gold Support steht eine 24/7 Support Hotline mit einer Reaktionszeit von ca. 1 Stunde zur Verfügung. Dieser kostet mehr als 400 Dollar pro Monat oder 5 bzw. 10 Prozent der monatlichen AWS Nutzungsentgelte des Kunden. Der Prozentsatz wird entsprechend dem genutzten Volumen verringert.
Weiterhin steht ein kostenloser Basic Support bereit. Dieser bietet Zugriff auf ein Ressource Center, FAQs, Foren und ein „Service Health Dashboard“.
…, on the contrary, it initially creates problems! Especially if you want to provide yourself as a provider of Cloud Computing services.
It is a misconception, if you think, that the construction of a private cloud implies, that you no longer have to take care about the high availability of your infrastructure (physical machines, virtual machines, master-slave replication, hot standby, etc.).
Because: The Cloud will make it on their own!
Be careful!!!The Cloud is preparing a (private) cloud operator initially more problems than you think.
A cloud does not work by itself. It must be developed and equipped with intelligence. This applies to the construction of a private cloud as well as for the use of a public cloud offering (in the case of IaaS). Scripts must be written and new software must might be developed, which is distributed over the cloud. It is also important to read the white paper of the respective providers. Build up know how(!) and understand how the cloud works to use it for your own needs. Another possibility is, of course, to obtain advice from professionals (in addition).
There is no different, for example by using a public cloud offering of the Amazon Web Services. If an instance A has a problem, it can suddenly no longer be attainable, like any normal physical server as well. Now you might think: „I just take an instance B as a backup for instance A!“ „And then?“ One might think that the instance B automatically takes over the tasks of the instance A. It’s not that simple! Scripts etc., must ensure that the instance B is to assume the duties of instance A, if A suddenly is no longer available. Of course Instance B must also be prepared!
Here for example, the important content of the instance A, including all configurations, etc. can be stored in an EBS (Elastic Block Store) and not in the local instance store. Afterwards a script must ensure that the instance B is powered up automatically with the configurations and all the data from the EBS, if the instance A is no longer available.
The Cloud just gives us, in the area of Infrastructure as a Service, the capabilities to get the (infinite) number of resources out of a quasi-infinite pool of resources, at that time when we need them. We thus receive a highly scalable virtual private data center from the provider. This means, conversely for the operator of a Cloud (private, public), that he must hold that amount of physical resources as well, so that the requested virtual resources can be provided at any time and that sufficient resources are always available to the users.
Eine Ubuntu Enterprise Cloud kann aus zwei, bzw. bis zu hunderten oder sogar tausenden physikalischen bestehen. Es ist daher wichtig, die möglichen Topologien zu verstehen, die auf Basis der vorhandenen physikalischen Maschinen aufzubauen sind.
1 physikalisches System (Nicht für den produktiven Einsatz empfohlen)
Dies ist die einfachste mögliche Konfiguration. Dabei werden der CLC/Walrus/CC/SC und NC alle gemeinsam auf einer einzigen Maschine betrieben. Diese Konfiguration unterscheidet sich nicht von allen anderen möglichen. Der einzige Unterschied besteht darin, dass der Netzwerkverkehr hierbei nicht durch das lokale Netzwerk übertragen wird.
1. Maschine A: CLC/Walrus/CC/SC/NC
Beispiel Konfiguration (für ein bestehendes LAN)
Netzwerk Konfiguration:
Netzwerk: 192.168.1.0/24
DHCP und DNS Server: 192.168.1.2
UEC Server: 192.168.1.4
/etc/network/interfaces auf dem UEC Server
iface eth0 inet manual
auto br0
iface br0 inet static
address 192.168.1.4
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.2
# dns-* options are implemented by the resolvconf package, if installed
# these are google's dns servers
dns-nameservers 8.8.8.8 8.8.4.4
# this setting could be "local" if you all your local hosts
# were named something like a.localdomain b.localdomain c.localdomain etc
dns-search localdomain
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off
VNET_PUBINTERFACE="br0" # must match the br definition above
VNET_PRIVINTERFACE="br0" # must match the br definition above
VNET_MODE="MANAGED-NOVLAN"
VNET_SUBNET="172.19.0.0" # ips from this range are bound to $VNET_PRIVINTERFACE:priv
VNET_NETMASK="255.255.0.0"
VNET_DNS="192.168.1.2" # what DNS server nodes are given
# v - should be ips on the LAN, not in use anywhere, and excluded from the DHCP server
VNET_PUBLICIPS="192.168.1.100-192.168.1.110"
Sollten das Netzwerk nach der Konfiguration nicht starten helfen die folgenden Befehle beim Korrigieren.
sudo stop eucalyptus CLEAN=1
sudo /etc/init.d/eucalyptus-nc stop
# fix the config file here
sudo start eucalyptus CLEAN=1
sudo /etc/init.d/eucalyptus-nc start
Der Parameter CLEAN sorgt dafür, dass sich das Netzwerk nicht bei jedem Neustart resetet. Es sollte darauf geachtet werden, dass kein System auf die ETH0 Schnittstelle gebunden ist. Um sicherzugehen, dass man mit einer sauberen Konfiguration arbeiten kann, ist ein Neustart des gesamten Systems. Wurde die PRIV Schnittstelle falsch konfiguriert, werden die Nodes ihre DHCP-Antworten von dem LAN-DHCP-Server anstelle des privaten CC-DHCP-Server erhalten.
Mindestens 2 physikalische Systeme
Bei dieser Konfiguration werden alle Verwaltungskomponenten für den Benutzer wie CLC und Walrus, sowie die Verwaltungskomponenten für das Backend wie der CC und SC auf einer gemeinsamen Maschine installiert. Der NC für das Hosting der virtuellen Maschinen erhält eine eigene physikalische Maschine.
Bei dieser Konfiguration werden die Verwaltungskomponenten für den Benutzer wie CLC und Walrus auf eine physikalische Maschine, sowie die Verwaltungskomponenten für das Backend wie der CC und SC auf einer weiteren zweiten Maschine installiert. Der NC für das Hosting der virtuellen Maschinen wird auf eine dritte physikalische Maschine installiert.
Bei dieser Konfiguration erhalten der CLC und Walrus jeweils eine eigene physikalische Maschine. Auf die dritte Maschine werden der CC und SC installiert. Für den NC wird eine vierte physikalische Maschine eingesetzt.
Für diese Konfiguration werden der CLC und der Walrus auf einer gemeinsamen Maschine konfiguriert. Auf eine dritte Maschine werden der CC1 sowie der SC1 installiert. Für den NC1 kommt eine eigene Maschine zum Einsatz. Um die Performance der Cloud zu erhöhen und die Last besser zu verteilen, werden auf einer vierten Maschine ein CC2 und ein SC2 konfiguriert. Auf eine fünfte Maschine wird ein NC2 installiert, der anschließend seine Ressourcen von dem CC2 und SC2 erhält.
Cloud Computing bringt finanzielle Vorteile, definitiv! Für Nutzer, genau so wie für Anbieter von Public Cloud Services.
Anbieter sollten jedoch zwei Dinge beachten. Für bspw. einen Anbieter wie die Amazon Web Services (AWS) lohnt sich das Cloud Computing Modell nur, wenn zwei Fälle vorhanden sind: Das eine sind die „Economies of Scale“ (Skaleneffekte) und das zweite „Eine Gleichverteilung der Kunden“.
Economies of Scale: Ein Anbieter benötigt viele Kunden, damit die Infrastruktur so gut ausgelastet wird, damit sich die Investitionen lohnen.
Eine Gleichverteilung der Kunden: AWS Kunden verteilen sich auf die unterschiedlichsten Branchen mit den unterschiedlichsten Kerngeschäften. Es wäre für AWS fatal, nur Kunden aus einem Branchenzweig, bspw. aus dem Bereich der Webshops, zu haben. Man könnte davon ausgehen, dass in diesem bestimmten Fall die AWS Infrastruktur zu Weihnachten zusammenbrechen würde. Im schlimmsten Fall würde sogar der Amazon Webshop davon betroffen sein. Wobei wir uns ziemlich sicher sein können, dass Amazon sich die eine oder andere Ressource reserviert hat. 😉
Der „Trick“ besteht also darin, u.a. die Lasten immer gleichmäßig über die Zeit zu verteilen und bspw. nicht viele hoch performante Jobs von mehrere Kunden zur selben Zeit auszuführen zu lassen.
Was also nicht passieren darf ist, dass Kunde A, B, C, D, E und Kunde F Ressourcen hungrige Jobs parallel ausführen wollen. Es wäre dagegen besser wenn die Infrastruktur immer gleichmäßig durch die Kunden innerhalb der 24h eines Tages belastet wird.
Dieses Tutorial zeigt Schritt für Schritt, wie eine openQRM Cloud auf CentOS 5.5 so eingerichtet wird, dass damit anschließend physikalische Windows Systeme deployed werden können. Für dieses Tutorial werden dazu zwei physikalische Systeme benötigt.
1. Los geht es mit einer neuen CentOS 5.5 Installation
Während der Installation des Systems nehmen wir eine manuelle Partitionierung vor und erstellen 3 Partitionen:
1. primary ext3 mounted at / (the rootfs)
2. primary swap
3. primary “lvm” (wird zum Speichern des Server-Image benötigt)
An dieser Stelle ist es wichtig zu beachten, ein benutzerspezifisches Partitionsschema zu wählen und eine dedizierte Partition zu erstellen, auf der später die Server-Images gespeichert werden. (/dev/hda3). Bei der Paketauswahl selektieren wird zudem das “Gnome Desktop Environment”. Weitere Software wird nicht benötigt.
Wichtig: SELinux und die Firewall müssen deaktiviert werden!
Wenn die Installation abgeschlossen ist, starten wir das System neu und melden uns an.
Die folgende Konsolenausgabe zeigt die exakte CentOS Version. Alle Konsolenbefehle in diesem Tutorial werden des Weiteren mit „root“ ausgeführt.
Um die Änderungen zu übernehmen, starten wir das Netzwerk neu.
[root@cloud network-scripts]# /etc/init.d/network restart
Shutting down interface eth0: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0:
[ OK ]
[root@cloud network-scripts]#
Nun hinterlegen wir die statische IP-Adresse (in unserem Fall “192.168.88.6″) und den Hostname (in unserem Fall “cloud”) in der /etc/hosts. Der Hostname darf hierbei nicht in der ersten Zeile zusammen mit 127.0.0.1 stehen!
[root@cloud ~]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
192.168.88.6 cloud
::1 localhost6.localdomain6 localhost6
[root@cloud ~]#
3. Vorbereiten des Speicherplatz für die Server-Images
Nun bereiten wir die dedizierte Partition so vor, dass sie zusammen mit lvm genutzt werden kann. Anschließend erstellen wir eine Logical Volume Group “vol”.
Nach der Installation starten wir den mysqld service.
[root@cloud ~]# /etc/init.d/mysqld start
Initializing MySQL database: Installing MySQL system tables...
100521 14:44:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
100521 14:44:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
OK
Filling help tables...
100521 14:44:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
100521 14:44:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
OK
To start mysqld at boot time you have to copy
support-files/mysql.server to the right place for your system
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h cloud password 'new-password'
Alternatively you can run:
/usr/bin/mysql_secure_installation
which will also give you the option of removing the test
databases and anonymous user created by default. This is
strongly recommended for production servers.
See the manual for more instructions.
You can start the MySQL daemon with:
cd /usr ; /usr/bin/mysqld_safe &
You can test the MySQL daemon with mysql-test-run.pl
cd mysql-test ; perl mysql-test-run.pl
Please report any problems with the /usr/bin/mysqlbug script!
The latest information about MySQL is available on the web at
http://www.mysql.com
Support MySQL by buying support/licenses at http://shop.mysql.com
[ OK ]
Starting MySQL: [ OK ]
[root@cloud ~]#
Nun prüfen wir, dass wir uns mit der Datenbank verbinden können.
[root@cloud ~]# mysql
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 2
Server version: 5.0.77 Source distribution
Type 'help;' or 'h' for help. Type 'c' to clear the buffer.
mysql> quit
Bye
[root@cloud ~]#
Und fügen mysqld zu den init Startskripten mittels chkconfig hinzu.
openQRM wird in diesem Tutorial aus den Sourcen erstellt. Diese sind in dem Subversion Repository des openQRM Projects verfügbar. Für die Installation sind hier lediglich ein Subversion Client und “make” notwendig. Diese sollten also installiert werden.
Nun müssen die openQRM Sourcen aus dem SVN Repository ausgecheckt werden.
[root@cloud ~]# svn co https://openqrm.svn.sourceforge.net/svnroot/openqrm openqrm
....
A openqrm/trunk/src/rpm/README
A openqrm/trunk/src/rpm/openqrm-entire.spec
A openqrm/branches
A openqrm/tags
Checked out revision 1996.
[root@cloud ~]#
Wir wechseln in das src/ Verzeichnis.
[root@cloud ~]# cd openqrm/trunk/src/
[root@cloud src]#
Alle Ergebnisse der Kompilierung werden vom openQRM-Build System automatisch gecached. Um sicherzustellen, dass alle Komponenten richtig erstellt wurden, kann “make” einfach erneut ausgeführt werden.
[root@cloud src]# make
Checking requirements for the compilation phase
openqrm-server requires: make, gcc, portmap, rsync, zlib-devel, wget, tar, bzip2, unzip, patch
found make installed
found gcc installed
found portmap installed
found rsync installed
found zlib-devel installed
found wget installed
found tar installed
found bzip2 installed
found unzip installed
found patch installed
openqrm-plugin-aoe-storage requires:
openqrm-plugin-aws requires:
openqrm-plugin-citrix requires:
openqrm-plugin-cloud requires:
openqrm-plugin-collectd requires:
openqrm-plugin-dhcpd requires:
openqrm-plugin-dns requires:
openqrm-plugin-equallogic-storage requires:
openqrm-plugin-highavailability requires:
openqrm-plugin-image-shelf requires:
openqrm-plugin-iscsi-storage requires:
openqrm-plugin-kvm requires:
openqrm-plugin-kvm-storage requires:
openqrm-plugin-linux-vserver requires:
openqrm-plugin-linuxcoe requires:
openqrm-plugin-local-server requires:
openqrm-plugin-local-storage requires:
openqrm-plugin-lvm-storage requires:
openqrm-plugin-nagios2 requires:
openqrm-plugin-nagios3 requires:
openqrm-plugin-netapp-storage requires:
openqrm-plugin-nfs-storage requires:
openqrm-plugin-puppet requires:
openqrm-plugin-sanboot-storage requires:
openqrm-plugin-solx86 requires:
openqrm-plugin-sshterm requires:
openqrm-plugin-tftpd requires:
openqrm-plugin-tmpfs-storage requires:
openqrm-plugin-vbox requires:
openqrm-plugin-vmware-esx requires:
openqrm-plugin-vmware-server requires:
openqrm-plugin-vmware-server2 requires:
openqrm-plugin-windows requires:
openqrm-plugin-xen requires:
openqrm-plugin-xen-storage requires:
openqrm-plugin-zabbix requires:
openqrm-plugin-zfs-storage requires:
Checking for required components to compile openQRM finished successfully
if [ -d ./thirdparty ]; then mkdir -p ../buildtmp; cp -aR ./thirdparty/* ../buildtmp/; fi
-> found component gpxe (undionly.kpxe.0.9.9.tgz) already downloaded
-> found component kvm-nic-bios (kvm-nic-bios-1.1.tgz) already downloaded
-> found component openqrm-client.windows (openQRM-Client-4.6.1-setup.exe) already downloaded
-> found component sshterm-component (openqrm-plugin-sshterm-components-1.0.tgz) already downloaded
Creating the default initrd-template
-> found component busybox (busybox-1.14.2.tar.bz2) already downloaded
-> Found busybox-1.14.2/_install/bin/busybox already in the build-cache
-> Skipping compilation, taking the ready built component from the cache
-> found component pciutils (pciutils-3.1.4.tar.gz) already downloaded
-> Found pciutils-3.1.4/pcimodules already in the build-cache
-> Skipping compilation, taking the ready built component from the cache
-> found component dropbear (dropbear-0.52.tar.gz) already downloaded
-> Found dropbear-0.52/dropbear already in the build-cache
-> Skipping compilation, taking the ready built component from the cache
Adding /sbin/portmap to default initrd-template
Adding /sbin/rpc.statd to default initrd-template
Adding /bin/bash to default initrd-template
Adding /usr/bin/rsync to default initrd-template
Adding /usr/bin/wget to default initrd-template
Adding /sbin/modprobe to default initrd-template
Adding /sbin/depmod to default initrd-template
Adding /sbin/insmod to default initrd-template
Adding /sbin/lsmod to default initrd-template
Adding /sbin/mke2fs to default initrd-template
Adding /sbin/sfdisk to default initrd-template
Adding /sbin/udevd to default initrd-template
Adding /lib/udev/vol_id to default initrd-template
-> found component gpxe (undionly.kpxe.0.9.9.tgz) already downloaded
-> found component kvm-nic-bios (kvm-nic-bios-1.1.tgz) already downloaded
-> found component openqrm-client.windows (openQRM-Client-4.6.1-setup.exe) already downloaded
-> found component sshterm-component (openqrm-plugin-sshterm-components-1.0.tgz) already downloaded
-> found component adodb (adodb498.tgz) already downloaded
-> found component jquery (jquery-1.3.2.tgz) already downloaded
-> found component js-interface (interface_1.2.zip) already downloaded
-> found component openqrm-client.centos.i386 (openqrm-client.4.6.1.centos.i386.tgz) already downloaded
-> found component openqrm-client.centos.x86_64 (openqrm-client.4.6.1.centos.x86_64.tgz) already downloaded
-> found component openqrm-client.debian.i386 (openqrm-client.4.6.1.debian.i386.tgz) already downloaded
-> found component openqrm-client.debian.x86_64 (openqrm-client.4.6.1.debian.x86_64.tgz) already downloaded
-> found component openqrm-client.ubuntu.i386 (openqrm-client.4.6.1.ubuntu.i386.tgz) already downloaded
-> found component openqrm-client.ubuntu.x86_64 (openqrm-client.4.6.1.ubuntu.x86_64.tgz) already downloaded
-> found component openqrm-initrd-template.centos.i386 (openqrm-initrd-template.4.6.1.centos.i386.tgz) already downloaded
-> found component openqrm-initrd-template.centos.x86_64 (openqrm-initrd-template.4.6.1.centos.x86_64.tgz) already download
-> found component openqrm-initrd-template.debian.i386 (openqrm-initrd-template.4.6.1.debian.i386.tgz) already downloaded
-> found component openqrm-initrd-template.debian.x86_64 (openqrm-initrd-template.4.6.1.debian.x86_64.tgz) already download
-> found component openqrm-initrd-template.ubuntu.i386 (openqrm-initrd-template.4.6.1.ubuntu.i386.tgz) already downloaded
-> found component openqrm-initrd-template.ubuntu.x86_64 (openqrm-initrd-template.4.6.1.ubuntu.x86_64.tgz) already download
[root@cloud src]#
Nun führen wir “make install” aus.
[root@cloud src]# make install
include/
include/openqrm-plugin-local-storage-functions
bin/
....
Creating the openqrm-client boot-service package
[root@cloud src]#
Am Ende initialisieren und starten wir openQRM mittels “sudo make start”.
[root@cloud src]# make start
Checking the requirements for RedHat based systems ...
openqrm-server requires: httpd, php, php-mysql, php-soap, mysql, syslinux, screen, procmail, openssl
-> found httpd installed
NOTICE: Trying to automatically install php ...
Loaded plugins: fastestmirror
....
Checking for required components finished successfully
Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.88.6 for Server
[ OK ]
First startup detected. Running initialization.
Looking for syslinux/pxelinux.0...found: /usr/lib/syslinux/pxelinux.0
Creating custom apache config.../etc/httpd/conf.d/openqrm-httpd.conf
Checking /usr/share/openqrm/etc/openqrm-server.conf for OP[ OK ]B_PROTOCOL=https..Reloading httpd:
Adding password for user openqrm
Initializing dropbear...
Will output 1024 bit rsa secret key to '/usr/share/openqrm/etc/dropbear/dropbear_rsa_host_key'
Generating key, this may take a while...
Public key portion is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgmOa49UMeOPqid06cR96yfRD/SQ98J1REpLKyyJ518iFFQyGKb9j2quZD+8FfKYt6rgFgS6
kGw95qJf6lqYc/rIH5ezcl4bVCn0Zo9pQkTyF496+iAp6AbPOX9KfBivu+5KWc7sfxOiDWGErPhzTGSkvjxwDAu2PkXAvTjUHMhhXxLk= root@cloud
Fingerprint: md5 de:cc:34:cb:2b:e5:b1:3d:50:dd:cc:f0:b5:ca:e9:e5
Adding public key to /root/.ssh/authorized_keys...
Starting the openQRM-server ver. 4.6.
Initialization complete. Please configure your openQRM Server at: http://192.168.88.6/openqrm/
-> User: openqrm -> Password: openqrm
[root@cloud src]#
“make start” führt zusätzlich eine Check-Routine aus, die überprüft, dass alle Abhängigkeiten für die Einwandfreie Nutzung von openQRM vorhanden sind. Ggf. nicht vorhandene Pakete werden automatisch installiert.
Während des ersten Starts wird der openQRM Server initialisiert. Nachdem openQRM vollständig installiert wurde, kann nun die Konfiguration mittels der Weboberfläche vorgenommen werden.
7. Konfiguration von openQRM
Wir melden uns am openQRM Server per http://ip-adresse/openqrm an. Der Benutzer und das Passwort sind jeweils “openqrm”. Nach der Konfiguration sollten diese Daten geändert werden.
Als erstes wählen wir als Netzwerkkarte die Bridge Schnittstelle für das openQRM Management.
Als Datenbank für das openQRM Backend wählen wir “myslq”.
Anschließend konfigurieren wir die Verbindungsinformationen für die Datenbank.
openQRM ist nun vollständig konfiguriert.
Wir werden automatisch zum Datacenter Dashboard weitergeleitet.
8. Erstellen eines Windows Image
Mit dem Plugin-Manager müssen wir als nächstes die folgenden Plugins aktivieren und starten:
dhcpd
tftpd
sanboot-storage
windows
cloud
Anschließend wechseln wir nach Base >> Components >> Create >> Storage. Dort erstellen wir einen neuen Speicher vom Typ “Sanboot-Storage (iSCSI)” und wählen den openQRM Server als Ressource.
Wir geben dem Storage Server einen Namen und speichern diesen.
Die Liste der verfügbaren Speicher sind nun wie folgt aus.
Wir klicken auf den “Mgmt” Button des neu erstellten “sanboot” Storage Server.
Hier wählen wir die Volume Group “vol”.
Nun erstellen wir ein neues Volume mit dem Namen “windowsxp″. Die Größe muss etwas größer sein als die der lokalen Festplatte des Systems, das verwendet wird, um das Image zu erstellen.
In unserem Tutorial verwenden wir eine 40 GB große lokale Festplatte, um ein Windows System zu installieren und zu einem LUN auf ein iSCSI-Target zu übertragen. Das Volume das wir erstellen hat eine Größe von 41GB und ist damit ein wenig Größer als die eigentliche physikalische Festplatte.
Mittels der Konsole würden wir wie folgt vorgehen:
Installation von Windows auf der lokalen Festplatte des zweiten Systems
In diesem Tutorial verwenden wir Windows XP Professional und nutzen exakt die GPXE Anweisungen von http://etherboot.org/wiki/sanboot/winxp. Wir nutzen dazu eine frische Windows Installation und nehmen keine Partitionierung der Festplatte vor.
Achtung:
Es wird „Install local + Transfer to iSCSI Lun“ verwendet, da Windows XP es nicht unterstützt, direkt auf einem iSCSI-Target installiert zu werden. Neuere Windows Version wie bspw. Windows 7 können dagegen direkt auf einem iSCSI-Target installiert werden, siehe dazu http://etherboot.org/wiki/sanboot/iscsi_install
Nachdem Windows installiert wurde, fügen wir die “iSCSI Boot” Unterstützung hinzu. Dazu gehen wir auf die Webseite http://etherboot.org/wiki/sanboot/winnt_iscsi und laden dort die für Windows passende „Initiator 2.x boot-buildxxx-arch/lang.exe“ herunter. In unserem Fall i386/X86 EN.
Wir speichern die Datei auf unserem Desktop.
Wir führen die Datei aus und folgen den Anweisungen.
Nun laden wir den Windows SAN Boot Configuration Driver von http://etherboot.org/wiki/sanboot/winnt_sanbootconf herunter.
Die ZIp-Datei beinhaltet den SAN Boot Treiber. Wir entpacken den Inhalt auf unseren Desktop.
Nun starten wir den sanbootconf Installer und folgen den Anweisungen.
Nach der Windows Installation starten wir das System neu und konfigurieren den Systemstart im BIOS so, dass das System vom Netzwerk aus (pxe-boot) gestartet werden kann. Anschließend wird das System nun innerhalb von openQRM als neue „idle“ Ressource vom Typ “Physical System” gestartet.
Wenn sich das System im Status „idle“ befindet müssen wir die folgenden Schritte vornehmen, um den Festplatteninhalt des physikalischen Windows Systems auf das iSCSI LUN zu übertragen:
1. Starten eines nc Listener auf dem logischen Windows Volume
[root@cloud ~]# ls /dev/mapper/vol-windowsxp
/dev/mapper/vol-windowsxp
[root@cloud ~]# nc -l 12345 | dd of=/dev/mapper/vol-windowsxp
# this command won't return but listen on port 12345 to submit data
# which it reads bitwise from the network port to /dev/mapper/vol-windowsxp
2. Mittels des “openqrm login” Befehl anmelden
Here the syntax of the “openqrm login” comand:
Wir müssen hierbei beachten, dass die Shell in diesem Fall über keine PATH Umgebung verfügt. Die Befehle müssen daher unter der Angabe des vollständigen Pfads ausgeführt werden.
Der folgende Befehl dient dazu, die lokale Festplatte der Windows Installation zu identifizieren.
bash-3.2# cat /proc/partitions
major minor #blocks name
8 0 39082680 sda
8 1 39070048 sda1
bash-3.2# /sbin/fdisk -l /dev/sda
Disk /dev/sda: 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 4864 39070048+ 7 HPFS/NTFS
bash-3.2#
3. dd und nc gemeinsam nutzen
Um den Festplatteninhalt remote auf das logische Volume zu übertragen, nutzen wir die Kombination von dd und nc.
Abhängig von der Größe der Festplatte und der Geschwindigkeit des Netzwerks, kann dieser Vorgang ein Weile dauern.
Auf dem openQRM Server kann der Befehl „kill -USR1 [pid-of-dd-process]“ genutzt werden, um zu sehen, wie viele Bytes dd bereits übertragen hat.
..
78165360+0 records in
78165360+0 records out
40020664320 bytes (40 GB) copied, 6322.11 seconds, 6.3 MB/s
[root@cloud ~]#
Nun führen für „sync“ aus, um sicherzustellen, dass alle Bits auf das logische Volume übertragen wurden.
[root@cloud ~]# sync
[root@cloud ~]#
9. Vorbereiten des Windows Image
Wir schalten die Ressource die sich im Zustand „idle“ befindet herunter (die Windows Installation auf der lokalen Festplatte), entfernen die Festplatte und starten sie über das Netzwerk neu.
Es sollte darauf geachtet werden, das die Bootreihenfolge auf „Network Boot only“ steht.
Wenn das System neu gestartet ist und sich im Status „idle“ befindet, erstellen wir erneut in logisches „Image“ in openQRM.
Wir wechseln dazu nach Base >> Components >> Create >> Image und wählen den “Sanboot” Storage Server.
Anschließend geben wir dem Image einen Namen und wählen das “windowsxp″ Volume als das Root-Device.
Die Liste der verfügbaren Images sind nun wie folgt aus.
Nun erstellen wir eine „Appliance“. Dazu wechseln wir zu Base >> Appliance >> Create und wählen die Ressource „idle“.
Wir nennen die „Appliance“ windowsxp, wählen den “default” kernel und das “windowsxp” Image und speichern die Appliance.
Wir starten die „Appliance“.
Das folgende Video auf YouTube zeigt den Systemstart des Windows Systems von dem iSCSI Storage Server.
Das Windows Image ist damit nun deployed und funktionsfähig. Nun müssen wir das Image so konfigurieren, damit es mittels openQRM verwaltet werden kann.
Dazu erstellen wir auf dem Windows Image im ersten Schritt einen Windows Benutzer mit dem Namen „root“.
Als nächstes muss der openQRM Client auf dem Windows Image installiert werden. Dazu öffnen wir einen Web-Browser und melden uns an den openQRM Server an.
Anschließend gehen wir zu Plugins >> Deployment >> Windows >> About
Hier laden wir den Windows openQRM-Client herunter.
Wir starten die openQRM-Client Installationsroutine und folgen den Anweisungen.
Now please run “gpedit.msc” and add the permission to “remote shutdown” to user “root”.
Wichtig: Sollte die Windows Firewall aktiviert sein, muss der TCP Port 22 geöffnet werden.
10. openQRM Cloud Konfiguration
Nun wechseln wir nach Plugins >> Cloud >> Configuration >> Main Config und konfigurieren die folgenden Punkte:
cloud_admin_email > eine valide E-Mail Adresse
auto_provision → true
external_portal_url → (optional) externe URL zu einem Cloud Portal
request_physical_systems → false
auto_give_ccus → 100
show_disk_resize → (optional) true
show_private_image → true
cloud_currency → (optional) auf US oder Euro setzen
cloud_1000_ccus → Wie viele 1000 CCUs wie viel US/Euro entsprechen
Für alle weiteren Konfigurationspunkte können die Standardwerte genommen werden. Speichern nicht vergessen!
Der folgende Screenshot zeigt die Hauptseite zur Konfiguration der Cloud.
Als nächstes müssen die Cloud Produkte mittels des „Cloud-Selector“ konfiguriert werden.
Dazu gehen wir nach Plugins >> Cloud >> Configuration >> Products >> Kernel und erstellen ein neues „Windows“ Kernel Produkt.
Das sieht dann wie im folgenden Screenshot aus.
Nun erstellen wir ein „Memory“ Produkt. Dieses muss den exakt verfügbaren Speicher aufweisen, das auf dem zweiten physikalischen System verfügbar ist. (Das System, welches das Windows Image deployed.) In diesem Tutorial verwenden wir ein System mit 3008 MB physikalischen Arbeitsspeicher. Dieser muss entsprechend angepasst werden.
Das sieht dann wie im folgenden Screenshot aus.
Nun erstellen wir ein “Physical System”.
Das sieht dann wie im folgenden Screenshot aus.
Der nächste Schritt besteht darin, der Cloud mitzuteilen, welche Images den Cloud Benutzern angezeigt werden sollen. Dazu wechseln wir nach Plugins >> Cloud >> Configuration >> Private Images und wählen in den Checkboxen „All“ für das „windowsxp “ Image.
Nun erstellen wir einen oder mehrere Cloud Benutzer. Hierfür gehen wir nach Plugins >> Cloud >> User und fügen einen neuen Benutzer inkl. einer gültigen E-Mail Adresse hinzu. Als Cloud Administrator kann man sich mit jedem beliebigen Cloud Benutzer anmelden, indem man auf den Namen des Cloud Benutzers klickt.
Die Liste der Cloud Benutzer sieht im Anschluss wie folgt aus.
Das openQRM Portal sieht nach einem erfolgreichen Login dann wie folgt aus.
Wir klicken auf den 2ten Tab mit dem Namen „Visual Cloud Designer“.
Der Virtual Cloud Designer zeigt alle verfügbaren Komponenten innerhalb der Cloud an. Mittels Drag and Drop kann nun eine eigene Cloud Appliance konstruiert werden.
Anschließend sollten die Kosten (stündlich, täglich, moantlich) für die Appliance betrachtet werden.
Mit einem einzigen Klick kann die Appliance der Cloud hinzugefügt werden.
Für das Cloud Deployment erstellt openQRM automatisch ein LVM Snapshot für das ursprüngliche Windows Image. Das bedeutet, dass es sich bei der (remote) Festplatte des Windows Image eigentlich um ein LVM Snapshot handelt. Im Storage Manager ist das Cloud Volume daher mit einem „s“ (Snapshot) gekennzeichnet.
Auf der Konsole verwendet man dazu den folgenden Befehl:
Mit Appforce, Siteforce, VMforce, ISVforce und Heroku hat salesforce.com fünf neue Cloud Plattform Services für die Erstellung von Cloud 2-Apps vorgestellt. Force.com 2 beseitigt dabei Hardware- und Softwarekomplexität und ermöglicht Unternehmen und ISVs, Anwendungsentwicklungsprojekte zu beschleunigen.
Appforce – Kollaborative Apps für verschiedene Abteilungen
Appforce hilft Unternehmen leistungsfähige und skalierbare Apps für alle Abteilungen zu erstellen. Nutzer können Formulare anlegen, Reports anpassen, Unternehmensprozesse visuell abbilden und gleichzeitig sicher stellen, dass diese messbar und prüffähig sind. Und sie können über Salesforce Chatter zusammenarbeiten.
Siteforce – Pixelgenaue Erstellung von Webseiten ohne Code
Die Erstellung von Webseiten ist oft langwierig und mühsam und fordert kontinuierlich neue Landing Pages, Produkte und Kampagnen. Zusätzlich stehen Entwickler heute vor der Herausforderung, soziale, mobile und Echtzeit-Funktionen zu integrieren. Siteforce gibt Anwendern die Werkzeuge an die Hand, um einfache Änderungen vornehmen zu können. Web-Entwickler haben die Möglichkeit, schnell leistungsstarke Seiten zu liefern. Siteforce macht es einfach, in Echtzeit Seiten zu entwerfen, Inhalte zu verwalten und vorgefertigte Komponenten wiederzuverwenden.
VMforce – Der Weg für Java-Entwickler in die Cloud
VMforce, die salesforce.com-Partnerschaft mit VMware, ermöglicht es 6 Millionen Java-Entwicklern, ihre bestehende Java-Expertise sowie die Vorteile des Cloud Computings einzusetzen und neue, mobile und soziale Echtzeit-Anwendungen für Unternehmen in der Cloud zu erstellen. Mit VMforce können Entwickler ihre Java-Anwendungen direkt auf Force.com laufen lassen, die beliebten Java-Entwicklungsumgebungen Spring Framework und Eclipse IDE nutzen und offene Standards, wie zum Beispiel JPA für die Entwicklung von Javaanwendungen für Unternehmen verwenden. VMforce ist derzeit für ausgewählte Kunden als Beta-Programm verfügbar.
Heroku – Die Ruby Cloud Application-Plattform
Heroku ist die führende Ruby Platform-as-a-service, die von Beginn an in einer offenen Umgebung erstellt wurde, um die Vorteile der Programmiersprache nutzen zu können. Ruby ist die führende Sprache für die Erstellung einer neuen Generation von Apps. Diese sind sozial, kollaborativ und ermöglichen Echtzeit-Zugang zu Informationen über mobile Endgeräte. Heroku ist heute Grundlage für mehr als 105.000 Apps.
ISVforce – Ermöglicht ISVs die Erstellung und Bereitstellung von multi-tenant Cloud-Apps
ISVforce bietet ISVs umfassende Services für Anwendungsentwicklung, Tests und Bereitstellung, automatische Upgrade-Möglichkeiten, den AppExchange-Marktplatz für Cloud Apps sowie eine Echtzeit-Konsole zur Überwachung der Nutzung durch Kunden. ISVforce legt all diese Services hinter jede ISV App. Führende ISVs wie Blackboard, BMC und CA nutzen ISVforce um Anwendungen zu erstellen und zu liefern.
