Archive for category Virtualisierung
EC2 Reserved Instances
Posted by Lars Schenk in Virtualisierung on März 16th, 2009
With “Reserved Instances” Amazon introduced an additional pricing option for EC2 that gives an option to make a one-time payment for an instance to reserve capacity and further reduce hourly usage charges. You may look up the details at: aws.amazon.com/ec2/#pricing.
I have made a rough comparison for the classic “on demand” small instance against the new reserved instance:
On Demand Instance:
$0 + (365*24*$0,10) = $876/year = $73/month
Reserved Instance 1year:
$325 + (365*24*$0,03) = $588/year = $50/month
Saves you $288/year or $24/month.
Reserved Instance 3years:
$500 + (3*365*24*$0,03) = $1288/3years = $430/year = $36/month
Saves you 446 $/year or 37$/month.
Here’s the offical FAQ on using Reserved Instances. And here’s a funny but critically blog post about the “single commandline that can costs you losts of money“. I think Marc Musings is right and I wish that Amazon would improve this because I had the same bad emotions with this “new API feature”. It would basically a good idea to have alerts and/or limits for charges, instances and traffic.
Can’t wait for reserved Instances to be available for the EU region… “in the near future” as Amazon promised… Happy emotions when spending big money with ec2-purchase-reserved-instances-offering!
UPDATE 09-08-21: New Lower Prices for Amazon EC2 Reserved Instances and I’m also happy to see that one of my EC2 instance hit the 500 days uptime mark.
Cloud Computing – DLD09
Posted by Lars Schenk in Video, Virtualisierung on Januar 28th, 2009
If I had to convince a non technical person about Cloud Computing, I would show him this video.
I really enjoyed listening to Dr. Werner Vogels. Dr. Vogels is Vice President & Chief Technology Officer at Amazon.com where he is responsible for driving the company’s technology vision, which is to continuously enhance the innovation on behalf of Amazon’s customers at a global scale.
This vision is why I have moved to EC2/S3 in 2007. I guess, I’ve finally become an Amazon AWS fan boy.
Even if audio is a bit out of sync, it’s worth to listening this long session.
As a developer from the bottom of my heart I like especially this quote: “There is no value in being a system administrator. You do not build a better product by being a better server maintainer.” This is so true, but I wonder how EC2 can free me from typical administration tasks. I still have to maintain my virtual server instances with the whole LAMP stack. Plus I have to think about how to scale horizontally (what to do when I need more virtual server instances).
In contradiction to Amzon’s EC2, Google’s AppEngine promises to free me from doing the admin tasks (no OS/LAMP Stack to maintain) and to solve the scale problem (no Database Replication to set up). AppEngine scales out of the box – the downside is, that it offers a very limited runtime just for you app.
True, a single EC2 instance doesn’t scale out of the box but it also doesn’t limit you in doing what you want to do on your virtual server. With EC2 I have to solve the scaling on my own. For this price I got more freedom.
I’m exited to use and learn about EC2/S3/Storefront each day but I also hope that Google’s AppEngine will offer a wider range of runtime environments in the future. t’s an interesting Cloud-Year 2009! #buzzword
Amazon CloudFront – Content Delivery Network für S3
Posted by Lars Schenk in tech-recipes, Virtualisierung on November 20th, 2008
CloudFront ist eine sinnvolle Erweiterung für Amazon S3: Wenn man S3 bisher als Asset-Server für statische Inhalte eingesetzt hat, so muss man sich für einen Standort entscheiden der möglichst nahe an der Zielgruppe betrieben wird. Ist meine Zielgruppe Europa, so wähle ich den S3 Standort dort und nehme in Kauf, dass User aus USA eine höhre Latenzzeit haben werden.
Mit CloudFront kann ich nun vor meinen öffentlichen S3 noch ein Content Delivery Network vorschalten, dass automatisch meine Inhalte über alle verfügbaren Standorte synchronisert und bei Requests auf meine Inhalte immer die schnellste Verbindung auswählt. Mehr Details zur neuen CloudFront, dem Content Delivery Network von Amazon gibt’s unter aws.amazon.com/cloudfront/ und im original Wortlaut des Developer-Newsletters. Read the rest of this entry »
VMware Fusion2 kostenloses Update für 1.x Kunden
Posted by Lars Schenk in Virtualisierung on September 16th, 2008
Danke VMware – das ist mal ein netter Zug, dass ein Major Release Upgrade kostenlos ist für Bestandskunden. Fusion2 macht auch wirklich einen prima Eindruck. Endlich kann man mehr als nur ein Snapshot pro VM anlegen. Die Auto-Protect Funktion ist dann nur konsequent weitergedacht. Weiter so…
Elastic IP – Statische IPs für virtuelle EC2 Server-Instanzen
Posted by Lars Schenk in Virtualisierung on Mai 23rd, 2008
Bisher gab es bei Amazon’s EC2 den Nachteil, dass jede Server-Instanz eine dynamisch zugewiesene öffentliche IP (“EC2 Public IP Address”) erhalten hat. Es konnte also nicht sichergestellt werden, dass man bei EC2 immer unter der selben IP erreichbar ist und musste DNS Updates machen oder über eine externe statische IP ein Reverse-Proxy in die EC2-Cloud machen um diesen Nachteil zu umgehen.
Amazon hat nun die sog. Elastic IP eingeführt, die genau diesen Nachteil aufhebt.
Man kann sich mit ec2-allocate-address bis zu fünf statische Elastic IPs auf sein EC2-Konto buchen lassen (mehr sind auf Anfrage bei Amazon möglich) und diese an beliebige eigene Instanzen knüpfen. Hierzu sind die aktuellen EC2 Command-Line Tools erforderlich, denn ältere Versionen vor 1.3-19403 2008-02-01 kennen die erforderlichen Befehle zum Verwalten der Elastic IP noch nicht. Testen welche Version installiert ist, kann man mit ec2ver.
Mit ec2-describe-addresses kann man sich anzeigen lassen welche Elastic IPs man bezitzt und welche Elastc IPs an welche Instance gebunden sind. Mit ec2-associate-address kann man eine Elastic IP an eine bestimmte Instanz binden. Somit ist es dann z.B. auch ganz einfach möglich eine ausgefallene Instanz durch eine neue Instanz zu ersetzen (die entweder zuvor paralell mitgelaufen ist oder erst neu hochgefahren wird) ohne dass nach aussen der Wechsel einer IP kommuniziert werden muss. Auch zwischen laufenden Instanzen können so einfach die Elastic IPs ausgetauscht werden. Z.b. wenn man einen Loadbalancer auf einer Small Instance betreibt und diesen nahtlos auf eine Large Instance umziehen lassen möchte. Über die EC2 API oder die Command-Line Tools lässt sich das alles auch wunderbar automatisieren.
Elastic IPs die an eine Instanz gebunden sind, verursachen keine Mehrkosten. Lediglich reservierte aber nicht genutzte Elastic IPs kosten derzeit pro Stunde 1 Cent um einem Horten der knappe IPs vorzubeugen. Die ersten 100 Remaps einer Elastic IP je Monat sind kostenfrei; weitere Remaps werden mit je 10 Cent berechnet. Also eine tolle und faire Erweiterung für EC2.
Wie genau das ganze mit den Elastic IPs geht wird ausführlich in diesem Feature Guide besprochen.
Brainstorming in eigener Sache: Der einzige Nachteil den ich bisher für meinen Anwendungshorizont ausmachen konnte betrifft Nutzer, die wie ich bereits Instanzen betreiben, die vor der Einführung der Elastic IPs über die “EC2 Public IP Address” nach aussen verfügbar/bekannt gemacht wurden. Ich habe die “EC2 Public IP Address” in mein Zonenfile eingetragen und wenn ich nun auf eine Elastic IP umstellen möchte um künftig immer mit der selben IP erreichbar zu sein (unabhängig von der Instanz, und um künftige DNS Updates zu sparen), so verliere ich beim Zuweisen der neuen Elastic IP sofort die “EC2 Public IP Address” unter der die Instanz bisher erreichbar ist. Da es nicht möglich ist, sich eine Elastic IP zu reservieren die bisher als EC2 Public IP Address auf eine eigene Instanz gebunden ist, bleibt einem nichts anderes übrig als für die Dauer des DNS Updates unerreichbar zu bleiben.
Soll eine temporäre Unerreichbarkeit vermieden werden, so müsste man sich dadurch behelfen, dass man Read the rest of this entry »
Google App Engine – Eldorado für Entwickler
Posted by Lars Schenk in Video, Virtualisierung on April 9th, 2008
Google hat eine frühe Version der App Engine vorgestellt (Preview). Es verspricht mir all die Administrativen Task abzunehmen, die ich üblicherweise habe, wenn ich meine Web-Anwendung online bringen will. Ich brauche mich nicht mehr um Server kümmern (seien es klassische RootServer beim Hoster oder virtuelle Server wie z.b. bei EC2). Ich muss mich nicht mehr darum kümmern, wie meine Applikation skaliert. Ich muss also keinen Mechanismus entwicklen wie bei EC2 wo ich meine Server und die Last überwache und ausgefallene Server ersetzte bzw. dynamsch weitere virtutelle Serverinstanzen zuschalten muss wenn mehr Last aufkommt – das alles macht Google App Engine automatisch für mich!
Es entlastet mich als Entwickler von all diesen adminstrativen Tasks die ich überlicherweise beim LAMP Stack habe. Es macht quasi den Administrator in mir arbeitslos und schenkt dem Entwickler in mir die frei gewordene Zeit um mich auf die Anwendung zu konzentrieren.
Teil 1 – Vorstellung der Google App Engine Preview:
Ab 2:50 stellt Kevin Gibbs die Vorteile der App Engine gegenüber dem klassischen LAMP Stack vor. Read the rest of this entry »
VMWare Fusion nicht kompatibel zu VMWare Server 1.x
Posted by Lars Schenk in Linux, Virtualisierung on März 18th, 2008
Ich habe eine VM mit Fusion erstellt, die Debian Etch enthält. Diese soll nun unter VMWare Server 1.x laufen. Die unter Fusion erstellte VM ist aber nicht kompatibel mit VMWareServer 1.x. Ob der neue VMWare Server 2.x, der zZ. in beta ist, mit Fusion erstelte VMs laufen lassen kann, habe ich nicht ausprobiert. Ich habe mit VMWare Converter die mit Fusion erstellte VM in das Format von VMWareServer 1.x gebracht.
Nach dem Konvertieren findet die VM unter VMWare Server nicht mehr das Netzwerk. /etc/network/interfaces ist unter Fusion mit eth0 gelaufen. Unter VMWareServer zeigt die VM mit “ifconfig -a” nur ein eth1 an. Ich habe die also in /etc/interfaces das primary network interface von eth0 auf eht1 geändert. Danach “/etc/ini.d/network restart” und nun läuft es wieder. Muss ich bei Gelegenheit mal genauer schauen, was da schief gelaufen ist – muss wohl irgendwas mit dem vmxnet networking driver sein.
Update: Die VM wurde “geklont” dabei wurde eine neue MAC-Adresse angelegt. Bei Debian ist in der “/etc/udev/rules.d/z25_persistent-net.rules” die alte MAC-Adresse eingetragen. Ich habe die “/etc/udev/rules.d/z25_persistent-net.rules” gelöscht und rebootet. Danach war das interface wieder als eth0 zu verwenden.
Latest comments