Sven's SharePoint Woche

Neuer TechNet Artikel zum Thema "SharePoint Farm auf Azure"

2013-04-17T08:40:18Z

Unter dem Titel "SharePoint 2013 on Windows Azure Infrastructure Services" ist ein neues Dokument auf TechNet veröffentlicht worden. Die Beschreibung des Dokuments ist "This document provides guidance on how to deploy and operate a MIcrosoft SharePoint 2013 Server farm on Windows Azure Infrastructure Services" und genau das trifft es auch.

In dem Dokument wird die Konfiguration der notwendigen Azure Komponenten wie Netzwerk und Speicher beschrieben. Auch die Erstellung der Server wird erläutert.

Vortrag auf dem ShareCamp 2013

2013-04-14T05:47:00Z

Gestern war der erste Tag des diesjährigen ShareCamp. Mein Vorschlag für einen Vortrag zum Thema "SharePoint Farm auf AzureVM" wurde als einer der Vorträge angenommen. Im letzten Slot des Tages um 17Uhr fanden sich dann auch tatsächlich rund 20 Zuhörer ein, um meinen Vortrag zu hören.

Das Thema, eine Entwicklungs- und Demoumgebung auf Azure zu betreiben wurde allgemein sehr interessiert aufgenommen und als möglicher Weg bewertet. Die am Ende des Vortrags aufkommende Diskussion hat allerdings auch gezeigt, dass es die ein oder anderen Bedenken hinsichtlich des Einsatzes für eine produktive Umgebung gab. Die Argumente bezogen sich überwiegend auf die möglicherweise anfallenden Kosten.

An dieser Stellen vielen Dank an alle Teilnehmer. Ich hoffe, ich konnte ein wenig dazu beitragen, dass das herumschleppen von Rechenzentren durch Entwickler und Consultants bald der Vergangenheit angehört. Das schont den Rücken und ist auch sicherer hinsichtlich Verfügbarkeit und Performance ;-)

Die Präsentation und die Scripte können hier heruntergeladen werden: http://sdrv.ms/157l6Rd

Viel Spaß mit SharePoint und AzureVM.

Reicht das MSDN Abonnement aus? - Rechenzeit

2013-02-04T15:14:48Z

Im letzten Beitrag habe ich ja das Thema Speicherplatz betrachtet. Diesmal soll es um das Thema Rechenzeit gehen.

Wie bereits ausgeführt, stehen mir im Rahmen meines MSDN Abonnements 1500 Stunden einer kleinen Serverinstanz zur Verfügung. Wird das für meine Entwicklungsumgebung reichen?

Folgende Server habe ich für meine Entwicklungsumgebung vorgesehen:

Ein Domänen Controller (DC01)
Ein SQL-Server (SQL01)
Ein SharePoint Server (APP01)
Evtl. einen OWA-Server (APP02)

Folgende virtuelle Hardware steht unter Windows Azure zur Verfügung:

Für den DC01 sollte eine kleine Instanz ausreichen, den SQL01 würde ich als mittlere Instanz auslegen. Für APP01 sollte es schon eine große Instanz sein, wesentlich mehr bekommt solch ein Server bei mit lokal auch nicht. Beim APP02 bin ich mir noch unschlüssig, muss man sehen (dank Skalierung kann ich das ja in Ruhe ausprobieren).

In meinem Beispiel ergibt sich also für die Berechnung der Rechenzeit:

Server	= Instanzen
DC01	1
SQL01	2
APP01	4
Summe	7

Also würde das Kontingent meines Abonnements mit Faktor 7 pro Stunde belasten. Also ist mein Kontingent von 1500 Stunden (1500 / (7*24) ) nach ca. 8,9 Tagen erschöpft. Hm, was mache ich den restlichen Monat? Das ist das Ergebnis, das ich von dem einen oder anderen Kollegen bisher gehört habe. Nun habe ich aber etwas gelernt, was ich hier gerne zu bedenken geben möchte: Dies ist klassische Hosting Denke. Cloud geht anders.

Im klassischen Hosting miete ich eine feste Leistung, ob ich sie aktuell benötige oder eben auch nicht. Bei Cloud Services nehmen ich meine Services dann in Anspruch, wann ich sie benötige und nur in der benötigten Menge.

Deshalb fällt meine Rechnung etwas anders aus:

Mein Arbeitsmonat hat ca. 21 Arbeitstage. Wenn ich besonders fleißig bin, arbeite ich jeden Tag 10 Stunden. Das macht also 210 Stunden. Wenn ich meine Entwicklungsumgebung nur in der Zeit laufen lasse, in der ich auch arbeite, ergibt sich daraus eine Rechenzeit von 210 Stunden x Faktor 7 = 1470 Stunden. Ganz schön knapp. Aber mal ehrlich, wer von uns benötigt seine Entwicklungsumgebung an jedem Arbeitstag für volle zehn Stunden?

Also wäre vielleicht sogar noch Luft, um mir einen zweiten APP Server zu gönnen, den ich unabhängig vom Rest der Farm hinzufüge oder nicht.

Grundvoraussetzung für den Betrieb meiner Entwicklungsumgebung wird also das Hoch- und Runterfahren bei Bedarf sein.

Reicht das MSDN Abonnement aus? - Speicherplatz

2013-02-04T08:37:00Z

Unter http://www.windowsazure.com/de-de/pricing/member-offers/msdn-benefits/ kann man sich informieren, welche Dienste in welcher Menge in einem MSDN Abonnement enthalten sind. Ich selbst habe ein Abonnement "Visual Studio Ultimate mit MSDN".

Die für den Betrieb meiner SharePoint Farm relevanten Größen sind wohl

Cloud-Dienste, virtuelle Computer, mobile Services und Webseiten und
Speicher

Daraus ergibt sich für mich 1500 Stunden Rechenzeit einer kleinen Serverinstanz, 45 GB Speicherplatz lokal und 45 GB Speicherplatz der geografisch Redundant ist. So, was fange ich jetzt damit an?

Zwei mal 45 GB Speicher hört sich erst einmal nach nicht sehr viel an. Ist es auch nicht, wenn da nicht die Tatsache wäre, dass es sich hierbei um den effektiv belegten Speicher handelt. Heißt also, dass mein SQL-Server zwar z.B. zwei Daten-Disks á 50GB haben kann, der für das Abonnement relevant gemessenen Speicher sich auf den tatsächlich belegten Speicher bezieht.

Daraus ergibt sich also die Möglichkeit, 90GB Speicherplatz in Azure effektiv zu nutzen.
Als "Spielwiese" verwende ich eine 3-Monate Testversion von Azure. Diese zeigt aktuell eine Speichernutzung von 14,34GB.

Der Speicher verteilt wie folgt sich auf vier Server:

Domain Controller
OS Disk: 30GB
Data-Disk: 10GB
SQL-Server
OS-Disk: 30GB
Data-Disk: 50GB
Data-Disk: 50GB
SharePoint Server
OS-Disk: 30GB
Data-Disk: 50GB
OWA-Server
OS-Disk: 30GB
Data-Disk: 50GB (nicht verwendet)

Das ergibt also eine Größe an VHDs von 330GB.

Alle Server sind lauffähig konfiguriert, Allerdings fehlt noch Visual Studio auf dem SharePoint Server.

Für meine "produktive" Entwicklungsumgebung plane ich, zwei Speicherkonten anzulegen. Einer wird die geografische Replikation aktiviert haben, der andere nicht. Durch die Geografische Replikation werden die VHDs in ein zweites Rechenzentrum repliziert, was die Datensicherheit nochmal erhöht. Sicherlich eine interessente Funktionalität für den Betrieb produktiver Umgebungen (NACH dem Preview Status), für meine Entwicklungsumgebung aber nur hinsichtlich des Verfügbaren Gesamtspeichers interessant.
Meine aktuelle Überlegung ist, den SQL-Server in den georeplizierten Speicher zu legen und die anderen Server in den lokalen Speicher. Das kann man natürlich auch andersherum machen, ist aber auch nicht entscheidend. Interessanter ist es IMHO, den SQL-Server auf den zweiten Speicher zu legen, um ggf. auch mal größere Datenmengen ablegen zu können.

Speicherplatz ist nach meinem Dafürhalten also in ausreichender Menge vorhanden. Aber was ist mit der Rechenzeit? Hierzu wird es zeitnah einen eigenen Blog Post geben ;-)

Das Für und Wider der SharePoint Farm auf Azure

2013-02-01T11:47:00Z

Natürlich stelle ich mir selbst die Frage, die ich auch von vielen Kollegen gestellt bekomme, ob der Betrieb der eigenen Entwicklungsumgebung auf Azure überhaupt praktikabel ist. Und natürlich habe ich mir eine eigene Liste des Für und Wider gemacht und die einzelnen Punkte für mich bewertet.

Das Argument, das am häufigsten gegen eine Entwicklerfarm auf Azure genannt wird, ist das leidige Thema "Internetperformance und -verfügbarkeit". In Zeiten von UMTS und LTE halte ich aber selbst diesen Punkt für kein "no-go". In vielen Fällen stellen die Kunden eine Internetverbindung über LAN oder WLAN für den eigenen Rechner bereit. Sollte das nicht der Fall sein, nutze ich einen UMTS-Router (Kollegen sind auch schon mit LTE-Routern ausgestattet). Damit bleibt dann natürlich noch ein Restrisiko, das gebe ich gerne zu. Aber nun drehe ich den Spieß um, uns sage Euch, warum genau hier die Farm in der Cloud einen Mehrwert bietet: Wenn ich keine Verbindung mit meinem Rechner ins Internet bekomme, muss mir halt der Kunde einen Rechner mit Internet-Zugang bereitstellen. Und dieser Rechner benötigt außer einem Browser und der Möglichkeit, RDP zu nutzen: Nichts. Sogar RDP ließe sich über "Web Access für Remotedesktop" in der SharePoint Farm eliminieren.

Die zwei für mich wichtigsten Argumente für eine Entwicklungsumgebung basierend auf Azure sind

Sicherheit
1. Konzept bedingt liegen meine VHDs auf Azure wesentlich sicherer, als auf einer internen oder externen Festplatte meines Laptops
2. Ich komme jederzeit an meine SharePoint Farm, unabhängig ob ich gerade vor meinem eigenen Laptop sitze, an einem kundeneigenen Rechner oder sogar mit dem Surface RT auf dem Sofa.
  Reeller Einsatz: Mein Laptop ist zur Reparatur und ich habe kein Ersatzgerät. Voraussetzung ist natürlich der Internetzugang ;)
Skalierbarkeit
1. Ich habe die Möglichkeit, Farm Szenarien aufzubauen, die ich lokal nicht gehostet bekomme. Beispiele hierfür sind Load balanced Frontend Server, eine eigene MySite Farm usw.
2. Wenn ich mal eine Demo machen möchte, egal für einen Kunden oder bei einem Vortrag, kann ich bei Bedarf einfach die Leistung meiner Server anpassen. Ich kann also meinen App Server eben mal von "Large" auf "Extra Large" drehen (also von 4 Core / 7 GB auf 8 Core / 14 GB), wenn nötig und später natürlich einfach wieder zurück.

Eine sehr gute Technische Resource zu diesem Thema ist sicherlich Deployment Considerations for SharePoint 2013 on Windows Azure Virtual Machines

Ich will kein Packesel mehr sein

2013-01-30T10:38:00Z

Als entwickelnder SharePoint Consultant schleppe ich, wie die meisten meiner Kollegen auch, ein kleines Rechenzentrum mit mir herum. Der Grund ist ganz einfach: SharePoint Entwicklung findet direkt auf SharePoint statt. Also benötigen wir eine komplette SharePoint Farm, die wir virtualisiert auf unseren Laptops und Notebooks installiert haben.

Mein aktuelles Notebook (i7, 16GB RAM, 120GB SSD, 500GB HDD) bringt es ohne Zusatz Akku auf knapp 4kg.

Insgesamt bringt es mein Rucksack damit auf (sehr) knappe 8kg, damit dürfte ich ihn eigentlich nicht als Handgepäck mit ins Flugzeug nehmen.

Da aktuell eine Erneuerung der Hardware ansteht, stellt sich natürlich die Frage nach einem adäquaten Nachfolger.

Während sich die Nicht-Entwickler um mich herum über die neuen, schicken Ultrabooks (mit Touch und so) freuen oder sogar mit Tablets und Convertibles liebäugeln, schaue ich mir wieder die großen und schweren Notebooks mit ihren backsteinartigen Netzteilen an .

Doch damit ist jetzt Schluss!

"We're all in!", also ich auch.
Ich installiere mir jetzt meine Entwicklungsumgebung auf Azure. In meiner MSDN-Subscription (Ultimate) ist ein entsprechendes Kontingent enthalten.

Wie ich meine Farm einrichte, warum ich das so mache wie ich es mache und wie letztendlich meine Erfahrungen sind, werde ich in den nächsten Posts hier auf meinem Blog berichten.