Whitepaper: Kostenvergleich einer SharePoint 2010 Infrastruktur – (Teil 1 – AWS)

Übersicht

Bei der Kostendarstellung, muss man darauf achten, dass sowohl bei Amazon, wie auch bei einem Provider, der Benutzer bzw. die Firma die Windows Lizenzen einbringen muss. Dies geschieht normalerweise entweder durch Lizenzmobilität oder durch den SPLA Vertrag bei dem Hostingprovider.

Bei der Lizenzmobilität muss darauf geachtet werden dass dieses in aller Regel nur in einem Volumenlizenzvertrag durch den Kunden geregelt ist. Es müssen dann die jeweiligen Serverlizenzen und Benutzerlizenzen vorgehalten werden.

Die Nutzung durch den SPLA Vertrag bei einem Hostingprovider beinhaltet in aller Regel die notwendigen Serverlizenzen wie auch Benutzerlizenzen. Die notwendigen Benutzerlizenzen werden in einer Regel im Vertrag einzeln ausgewiesen. Es gibt aber auch Verträge, in denen nur die Serverlizenzen ausgewiesen sind.

Bei Microsoft AZURE sind in aller Regel die Microsoft Windows Server Lizenzen enthalten. Dies muss aber von Produkt zu Produkt einzeln betrachtet werden. Generell sind beim Microsoft AZURE keine Benutzerlizenzen enthalten.

Die Möglichkeit, über Office 365 Benutzerlizenzen zu erwerben, bietet nicht die Option, diese bei Microsoft AZURE oder einem anderen Onlinedienst bzw. klaut Dienst, einzusetzen. Die Office 365 Benutzerlizenzen sind nur bei einer lokalen Infrastruktur (private cloud, on-premises) nutzbar.

Für die Lizenzbetrachtung wird am Ende dieses Dokuments ein eigenes Kapitel vorhanden sein. In den ersten Kapiteln werden nur die Infrastrukturkosten evaluiert.

Die notwendige SharePoint-Infrastruktur wird als Beispiel mit einem klassischen Intranet sowie einen Extranet bzw. Internet Zugang beschrieben. Diese Infrastruktur besteht in diesen Beispielen pauschal für alle Anbieter aus zwei TMG 2010 (Applikationsfirewall), vier Content Server, zwei Applikationsserver, zwei SQL Datenbankserver und zwei Active Directory Server. Die gespeicherte Datenmenge wird als Migration betrachtet, d.h. beim Start der Infrastruktur werden 500 GB Daten importiert, welche monatlich im Intranet mit 250 GB konsumiert werden und im Extranet mit 100 GB. Nicht betrachtet wird die Datenmenge derzeit für ein Backup oder für RBS (Remote Blob Storage).

In der folgenden Tabelle werden die Voraussetzungen bzw. die Empfehlungen von Microsoft aus dem Whitepaper dargestellt. Diese Tabelle wird einheitlich als Grundlage für weitere Kalkulationen genommen.

Tier/role Scenario Processor RAM Hard disk
Web/Application Tier All 64-bit, 4 core 8 GB 80 GB
Database server Small deployment 64-bit, 4 core 8 GB 80 GB
Database server Medium deployment 64-bit, 8 core 16 GB 80 GB
Domain controller All 64-bit, 4 core 8 GB 80 GB

Tabelle 1: Minimum system requirements for SharePoint Server roles and tiers (source AMAZON)

Aus meiner Erfahrung halte ich allerdings diese Empfehlungen teilweise als zu gering. Zumindest was die Festplatten angeht. Je nachdem, wie ein System eingerichtet wurde, sind heutige Updates und der notwendige Speicherplatz größer. Wenn bei einer Installation nicht explizit die Standardverzeichnisse von der Systemplatte verschoben werden (das ist die 80 GB HDD), dann hat das System eigentlich keinen Platz mehr zum Arbeiten. Alleine bei dem großen SQL Server bleiben nach Abzug der Auslagerungsdatei “nur noch” 64 GB Speicherplatz übrig, wenn dann noch einige temporäre Dateien die Festplatte belegen, was nach häufigen Updates und Patchen inzwischen zum Alltag geworden ist, wird es langsam knapp für das System.

Bei den SharePoint Servern besteht die größte Gefahr zusätzlich aus den Indexdateien der SharePoint Suchkomponenten sowie des SharePoint / IIS Caches.

Daher kann diese Tabelle keinesfalls als Empfehlung gelten, sondern dient ausschließlich als Kalkulationsreferenz. Am Ende des Artikels werde ich eine Hardware Liste einbringen, wie ich sie häufig benutze.

 

Kostendarstellung AMAZON

Wie in der Einleitung vermerkt, hat Amazon ein Whitepaper veröffentlicht. Dieses stammt aus dem Februar 2012. Als Referenz hat Amazon die eigene IT Abteilung genannt, die Microsoft SharePoint auf Amazon Web Services selbst betreibt.

Amazon beschreibt in seinem Whitepaper einer Infrastruktur welche zusätzliche Komponenten benötigt, die aber nicht durch Amazon geliefert werden. Dazu gehört zum Beispiel eine sichere Datenleitung zwischen der eigenen Firma und der Amazon Cloud. Hierfür wird ein 3rd Partie Tool empfohlen. Diese VPN-Leitung ist zum Beispiel notwendig, um eine sichere Replikation von Active Directory zu gewährleisten. Das Tool muss als zusätzliche Gateway Komponente bei Amazon Web Services hinzu gerechnet werden, das bedeutet zwei zusätzliche virtuelle Server. Zur Erhöhung der Sicherheit, empfiehlt Amazon zusätzliche IP Datennetze, die als private Netzwerke implementiert werden.

Die kommerzielle Komponente bei Amazon Web Service für die virtuellen Server sind die Amazon EC2 Produkte. Diese cloud Produkte ermöglichen einen dynamischen Wachstum der Infrastruktur.

Die Amazon EC2 Produkte werden in der folgenden Tabelle mit normalen Windows Server verglichen und dargestellt.

Tier Applicable Amazon EC2 instance type and range AMI to use
Web front end Extra Large (m1.xl) Windows Server 2008 R2 + IIS
Application server Extra Large: High Memory Quad Extra Large (m2.xl–m2.4xl) Windows Server 2008 R2
Database server High Memory Quadruple Extra Large (m2.4xl) Optimized SQL Server 2008 R2 AMIs from Microsoft
Domain controller Extra Large (m1.xl) Windows Server (in the role of a domain controller)

Tabelle 2: Mapping minimum system requirements to AMIs and Windows instance types (source: AMAZON)

 AWS Funktionen

(Basierend auf den Informationen von Amazon; Quelle: http://aws.amazon.com/de/ec2/#features)

Amazon EC2 verfügt über zahlreiche leistungsstarke Funktionen zum Errichten von skalierbaren, fehlerresistenten Anwendungen der Enterprise-Klasse. Dazu zählen:

Amazon Elastic Block Store

Amazon Elastic Block Store (EBS) bietet beständigen Speicher für Amazon EC2-Instanzen. Amazon EBS-Datenträger ermöglichen die Speicherung außerhalb der Instanz, die unabhängig vom Status einer Instanz besteht. Amazon EBS-Datenträger sind hochverfügbar, äußerst zuverlässig und können als Boot-Partition einer Amazon EC2-Instanz genutzt oder als Standard-Blockgerät an eine laufende Amazon EC2-Instanz angehängt werden. Bei Verwendung als Boot-Partition können Amazon EC2-Instanzen angehalten und anschließend neu gestartet werden. So zahlen Sie nur für die verwendeten Speicherressourcen und behalten den Instanz-Zustand bei. Amazon EBS-Datenträger bieten eine erheblich verbesserte Beständigkeit als lokale Amazon EC2-Instanzspeicher, da Amazon EBS-Datenträger automatisch am Backend (in einer Availability Zone) repliziert werden. Kunden, die eine noch bessere Beständigkeit wünschen, können die Funktion von Amazon EBS nutzen, mit der konsistent zeitpunktgesteuerte Snapshots der Datenträger erstellt und dann in Amazon S3 gespeichert werden. Die Snapshots werden automatisch in mehreren Availability Zones repliziert. Diese Snapshots können als Startpunkt für neue Amazon EBS-Datenträger verwendet werden und Ihre Daten langfristig schützen. Die Snapshots können außerdem einfach an Kollegen oder andere AWS-Entwickler weitergegeben werden. Weitere Informationen zu dieser Funktion finden Sie unter Amazon Elastic Block Store.

 

Mehrere Standorte

Amazon EC2 ermöglicht das Ablegen von Instanzen an mehreren Standorten. Amazon EC2-Standorte bestehen aus Regionen und Availability Zones. Availability Zones sind eigenständige Standorte, die so entwickelt wurden, dass sie von Fehlern in anderen Availability Zones isoliert sind. Sie bieten eine kostengünstige Netzwerkverbindung mit geringer Verzögerungszeit zu anderen Availability Zones in derselben Region. Indem Instanzen in separaten Availability Zones gestartet werden, können Sie Ihre Anwendungen vor den Fehlern eines einzelnen Standortes schützen. Regionen bestehen aus mindestens einer Availability Zone, sind geografisch verteilt und befinden sich in unterschiedlichen geografischen Zonen oder Ländern. Die Zusage der Amazon EC2-Dienstgütevereinbarung sieht eine Verfügbarkeit von 99,95 % für jede Amazon EC2-Region vor. Amazon EC2 ist gegenwärtig in acht Regionen verfügbar: USA Ost (Nord-Virginia), USA West (Oregon), USA West (Nordkalifornien), EU (Irland), Asien-Pazifik (Singapur), Asien-Pazifik (Tokio), Südamerika (Sao Paulo) und AWS GovCloud.

 

Elastic IP Addresses

Elastic IP Addresses sind statische IP-Adressen, die für dynamisches Cloud-Computing entwickelt wurden. Eine Elastic IP Address ist mit Ihrem Konto und nicht mit einer bestimmten Instanz verbunden. Sie haben die Kontrolle über diese Adresse, bis Sie sich explizit dafür entscheiden, sie freizugeben. Anders als bei herkömmlichen statischen IP-Adressen können Sie mit Elastic IP Addresses Fehler bei einer Instanz oder einer Availability Zone maskieren, indem Sie Ihre öffentlichen IP-Adressen an eine beliebige Instanz Ihres Kontos programmatisch umleiten. Sie müssen auf keinen Datentechniker warten, der Ihren Host neu konfiguriert oder ersetzt, oder darauf warten, dass sich DNS auf alle Ihre Kunden verteilt. Amazon EC2 ermöglicht Ihnen das Umfahren von Problemen mit Ihrer Instanz oder Software, indem Ihre “Elastic IP Address” schnell an eine Ersatz-Instanz umgeleitet wird. Darüber hinaus haben Sie die Möglichkeit, den Reverse DNS Eintrag Ihrer Elastic IP Addresses zu konfigurieren, indem Sie dieses Formular ausfüllen.

 

Amazon Virtual Private Cloud

Amazon VPC stellt eine sichere und nahtlose Brücke zwischen der vorhandenen IT-Infrastruktur eines Unternehmens und der AWS-Cloud dar. Amazon VPC ermöglicht Großunternehmen die Verbindung ihrer vorhandenen Infrastruktur mit isolierten AWS-Rechenressourcen über ein Virtual Private Network (VPN). Außerdem können sie ihre vorhandenen Verwaltungsfunktionen wie Sicherheitsdienste, Firewalls und Erkennungssysteme von Eindringlingen erweitern, um auch die AWS-Ressourcen einzubeziehen. Weitere Informationen finden Sie unter Amazon Virtual Private Cloud.

 

Amazon CloudWatch

Der Webservice Amazon CloudWatch bietet die Überwachung von AWS-Cloud-Ressourcen und beginnt bei Amazon EC2. Sie erhalten Einsicht in die Ressourcenauslastung, betriebliche Leistung sowie allgemeine Anforderungsmuster. Dazu zählen auch Kennzahlen wie die CPU-Auslastung, Lese- und Schreibvorgänge auf Speichermedien und der Netzwerkverkehr. Sie können für Ihre metrischen Daten Statistiken abrufen, Grafiken anzeigen und Alarme einrichten. Um Amazon CloudWatch zu nutzen, wählen Sie einfach die Amazon EC2-Instanzen aus, die Sie überwachen möchten. Sie können auch Ihre eigenen Daten für Geschäfts- oder Anwendungsmetriken bereitstellen. Amazon CloudWatch beginnt dann damit, Daten zusammenzutragen und zu speichern, die über die Web-Service-APIs oder Befehlszeilen-Tools abgerufen werden können. Weitere Informationen finden Sie unter Amazon CloudWatch.

 

Auto Scaling

Auto Scaling ermöglicht die automatische Skalierung der Amazon EC2-Kapazität nach oben oder nach unten entsprechend den von Ihnen festgelegten Bedingungen. Wenn Auto Scaling angewendet wird, können Sie dafür sorgen, dass die Anzahl der von Ihnen verwendeten Amazon EC2 Instances bei Anforderungsspitzen nahtlos nach oben skaliert wird, um die Leistung beizubehalten. Während eines Anforderungstiefs wird automatisch nach unten skaliert, um die Kosten gering zu halten. Auto Scaling eignet sich besonders für Anwendungen, bei denen es stündlich, täglich oder wöchentlich zu Unterschieden in der Verwendung kommt. Auto Scaling wird durch Amazon CloudWatch aktiviert und über die Gebühren für Amazon CloudWatch abgedeckt. Es fallen keine zusätzlichen Gebühren an. Weitere Informationen finden Sie unter Auto Scaling.

 

Elastic Load Balancing

Elastic Load Balancing verteilt automatisch den eingehenden Anwendungsverkehr über mehrere Amazon EC2-Instanzen. Somit kann eine noch höhere Fehlertoleranz erreicht werden: Die Lastverteilungs-Kapazität wird nahtlos an den Anwendungsverkehr angepasst. Elastic Load Balancing erkennt innerhalb eines Pools Instanzen mit schlechtem Zustand und leitet den Datenverkehr automatisch auf Instanzen mit gutem Zustand um, bis die Instanzen mit dem schlechten Zustand wiederhergestellt wurden. Sie können Elastic Load Balancing innerhalb einer Availability Zone oder auf mehreren Zonen aktivieren, um so eine noch konsistentere Anwendungsleistung zu erhalten. Amazon CloudWatch kann genutzt werden, um bestimmte Betriebskennzahlen von Elastic Load Balancing zu erfassen, wie z. B. die Anfrageanzahl und die Anfrageverzögerung. Neben den Gebühren für Elastic Load Balancing fallen keine weiteren Kosten an. Weitere Informationen finden Sie unter Elastic Load Balancing.

 

High Performance Computing (HPC) Clusters

In diesem Artikel nicht beschrieben, da kein Angebot in Irland bzw. innerhalb der EU.

 

VM Import

VM Import ermöglicht Ihnen, auf einfache Weise Images virtueller Maschinen von Ihrer gegenwärtigen Umgebung in Amazon EC2 Instanzen zu importieren. VM Import ermöglicht Ihnen, Ihre existierenden Investitionen für virtuelle Maschinen zur Erfüllung Ihrer Erfordernisse für IT-Sicherheit, Konfigurationsverwaltung und Compliance zu nutzen, indem Sie diese virtuellen Maschinen als verwendungsbereite Instanzen nahtlos in Amazon EC2 einbringen. Dieses Angebot ist ohne zusätzliche Kosten in den standardmäßigen Nutzungsgebühren für Amazon EC2 und Amazon S3 inbegriffen. Weitere Informationen über VM Import.

Kalkulation mit AMAZON Preisen

Zur Kalkulation mit AMAZON Preisen, wurde ein offizielles Excelsheet von Amazon genommen. Dieses ist unter http://d36cz9buwru1tt.cloudfront.net/Amazon_EC2_Cost_Comparison_Calculator_042810.xls zu finden und nennt sich “Amazon EC2 Kostenvergleichsrechner”. Auszug aus der Beschreibung:

“Mit diesem Kostenvergleichsrechner im Microsoft Excel-Format können Sie die direkten wirtschaftlichen Vorteile (oder Kosten) von Cloud-Computing quantifizieren. Die Tabelle gibt Ihnen einen Ausgangspunkt, sodass Sie die standardmäßige Vorlage verwenden oder sie entsprechend den besonderen Gegebenheiten in Ihrem Unternehmen anpassen können, um die jährlichen Kosten von Amazon EC2 im Vergleich zu Rechenressourcen in angemieteten Rechenzentren oder am eigenen Standort zu ermitteln. Das zugehörige Handbuch (http://d36cz9buwru1tt.cloudfront.net/User%20Guide_Amazon_EC2_Cost_Comparison_Calculator_042810.pdf) bietet Ihnen detaillierte Erläuterungen zur Verwendung dieses Tools.”

Verwendung des Amazon Sheets

Sobald man das Sheet geöffnet hat (nicht vergessen, die Datei zu speichern und dann die Makros zu aktivieren), wird man meiner Meinung erst einmal geblendet, wie “günstig” Amazon doch im Vergleich zur eigenen IT ist.

Lokale Kosten bei über 2,5 Mio. US Dollar im Vergleich zu “nur” etwas über 200 Tsd. US Dollar bei Amazon. Erst beim scrollen erfährt man mehr über die “Effekthascherei”. Hier werden nämlich 300 Linux Instanzen mit einer Nutzung von 75% und 700 Instanzen als “bei Bedarf” gekennzeichnet.

Das in einer Firma für eine eigene IT Infrastruktur nur 75% der Laufzeit die Server verfügbar sein sollen, halte ich jetzt für ein Gerücht, aber das Kostenspiel wird eigentlich durch die Darstellung der “stillen Reserven” schön gerechnet. Wenn ich nämlich diese Reserven auf 0 setze und die Verfügbarkeit der normalen Instanzen auf 100% (24 Stunden / 7 Tage), ergibt sich folgendes Rechenbeispiel.

 

Das sieht doch schon ganz anders aus, oder? Fast eine Schnapszahl mit etwas über 777 Tsd. US Dollar lokale Infrastruktur, im Vergleich zu knapp 220 Tsd. US Dollar bei Amazon.

Bei beiden Varianten bitte auch die “Co-Location” betrachten, da dies die “Outsourcing” Variante bei einem Hosting Dienstleister ist.

SharePoint Beispielkalkulation mit dem AMAZON Sheet

Nachdem wir nun durch die zweiten Zahlen wieder etwas ernüchtert sind, wollen wir uns der eigentlichen Aufgabe zuwenden, der Kalkulation für eine SharePoint Infrastruktur.

Die Änderung des Sheets in die vorher definierten Serverbeispiele ist schnell gemacht.

Es wurde mit Absicht noch kein Datentransfer berechnet bzw. eingetragen, um eine relativ saubere Kalkulation von “Bestandskosten” zu erhalten. Immerhin ist benötigter Speicher flüchtig, nicht aber notwendige Server für den laufenden Betrieb. Selbstverständlich wurde das Betriebssystem auf Windows geändert.

Auf dem ersten Blick sieht das gar nicht mehr so “furchteinflößend” aus. Knapp 160 Tsd. Lokale IT Kosten im Vergleich zu knapp 128 Tsd. US Dollar Amazon Kosten.

Nun füge ich die Speicherdaten hinzu. 500 GB Bestandsdaten als monatliche Migration, damit diese sofort und ohne Hochfahrkurve vorhanden sind und einer 250 GB laufenden Transferrate. Die 500 GB sind zu vernachlässigen, auch wenn diese monatlich hoch geladen werden, denn diese Kosten bei keinem Anbieter etwas. Anders ist der ausgehende Datentransfer, dieser kostet immer etwas. Es ist in dem Sheet nicht möglich, zwischen Datentransfer innerhalb der Infrastruktur, also zwischen SQL Datenbank und Webserver und vom SharePoint Web Frontend Server zu unterscheiden. Trotzdem ist nur eine geringfügige Kostensteigerung zu erkennen. Der Speicher wurde durch die Anzahl der Instanzen dividiert um die Mengen zu erhalten.

Somit stehen hier folgende Kosten fest:

  • Lokale IT Infrastruktur: ca. 160 Tsd. US Dollar
  • AMAZON Web Services: ca. 130 Tsd. US Dollar
  • Co-Location: 80 Tsd. US Dollar

Meiner Meinung nach, ein doch sehr interessantes Zwischenergebnis, welches nun mit Microsoft AZURE verglichen werden soll.

The short URL of the present article is: http://wp.me/p1MQAv-uE

Tagged with:

Filed under: AzureCloudInfrastructureOffice 365 Grid