ContentXXL Azure
In diesem Bereich wird erläutert welche Einstellungen Sie in contentXXL treffen müssen, damit contentXXL in der Windows-Azure-Cloud funktionsfähig läuft.
CSCFG. KONFIGURATIONSDATEI
Öffnen Sie die ServiceConfiguration.Cloud.cscfg Konfigurationsdatei mit einem Dateieditor.
Im unteren Bereich finden Sie diese Parameter:
<Setting name="ActiveBlobAccountName" value=" " />
<Setting name="ActiveBlobAccountKey" value="" />
<Setting name="ActiveBlobContainer" value=" " />
<Setting name="ActiveWindowsAzureDriveVHD" value="" />
<Setting name="ActiveWindowsAzureDriveCacheValue" value="20000" />
<Setting name="ActiveWindowsAzureDriveSubDirectory" value=" " />
ACTIVEBLOBACCOUNTNAME
Geben Sie hier Ihren vorher angegebenen Speicherkontennamen ein, in diesem Beispiel wäre dies:
<Setting name="ActiveBlobAccountName" value=" contentxxlstorage" />
ACTIVEBLOBACCOUNTKEY
Drücken Sie „Ansicht“ beim primären Zugriffsschlüssel.
Ein Popup erscheint:
Wählen Sie hier Ihren primären Zugriffsschlüssel aus.
Geben Sie nun Ihren primären Zugriffsschlüssel in den Parameter ein, in diesem Beispiel würde dies so aussehen:
<Setting name="ActiveBlobAccountKey" value="rRk4txTnYZg+sBJpqm7M9Rk7XXXXXXXXXXXXXX" />
ACTIVEBLOBCONTAINER
Geben Sie hier einen Containernamen ein z.B. „contentXXLContainer“
Der BlobContainer fungiert als eine Art „Festplatte“, nur dass diese nicht über einen Buchstaben z.B. „C:\“ angesprochen wird sondern über den Containernamen.
<Setting name="ActiveBlobContainer" value="contentXXLContainer" />
ACTIVEWINDOWSAZUREDRIVEVHD
Geben Sie hier Ihren .VHD Namen ein, auf dem die contentXXL-Installation mitsamt Ihrer Kunden Daten liegt.
<Setting name="ActiveWindowsAzureDriveVHD" value="contentXXLDrive" />
Sie müssen in dem Value kein „.VHD“ mitgeben, dies wird später selbstständig durch contentXXL gesetzt.
Das .VHD File wird mit einer Größe von 225GB auf Windows-Azure erstellt.
ACTIVEWINDOWSAZUREDRIVECACHEVALUE
Geben Sie hier einen Cache-Wert in Megabytes an, dieser Cache-Wert geht von der Instanziierten Größe von dem Windows-Azure-Drive weg.
Dies bedeutet, wenn Sie 25GB als Cache-Wert angeben, können maximal nur 200GB Daten auf dem Windows-Azure-Drive gespeichert werden.
Was ist der Vorteil des Caches?
- Wenn eine Datei das erste Mal abgefragt wird, wird diese Datei vom Blobstorage geholt/abgefragt und angezeigt. Dieses Blobstorage liegt nicht Lokal auf dem aktuell Instanziierten Server, sondern ist auf einem Rechner platziert, dass über das Netzwerk abgefragt wird. Durch diese nicht direkte Verbindung ist immer eine Verzögerung bemerkbar.
- Ist das Caching aktiviert, wird die Datei nachdem Sie das erste Mal geholt wurde, Lokal abgelegt, sodass, wenn die Datei ein zweites Mal abgefragt wird, diese nicht mehr aus dem Blobstorage geholt werden muss.
- Somit sind die Dateien schneller Verfügbar
- Zusätzlich werden hierdurch Transaktionen gespart (Kostenfaktor)
Achtung: Der Cachewert kann nicht verringert werden, dies bedeutet, falls Sie einmal 25 GB als Cache angegeben haben und beim nächsten update Ihres gehosteten Dienstes eine kleinere Cacheanzahl eingeben, bekommen Sie einen Fehler von Microsoft. Der ausgegeben Fehler in der Textdatei lautet „ERROR_CACHE_TOO_SMALL“.
ACTIVEWINDOWSAZUREDRIVESUBDIRECTORY
Dieser Parameter ist optional.
Hier können Sie eine Verzeichnisstruktur hinterlegen wie z.B.: „websites\live\“ auf die der IIS gemappt wird.
Lassen Sie diesen Wert leer, wird der Root-Pfad benutzt z.B.: „F:\“
F:\ steht für das gemountete Windows-Azure-Drive, dies wird später genauer erklären.
<Setting name="ActiveWindowsAzureDriveSubDirectory" value="websites\live\" />
Nach dem abändern der Parameter muss die neue Konfigurationsdatei hochgeladen werden.
Hierfür selektieren Sie Ihre Bereitstellung und drücken in der Menüleiste „Konfigurieren“:
Es erscheint ein Popup:
Suchen Sie hier Ihre veränderte Konfigurationsdatei oder wählen Sie „Aktuelle Konfiguration bearbeiten“ und verändern dort die entsprechenden Werte.
Achtung: Die Rolle wird nach den Änderungen neu initialisiert, dies kann einige Zeit in Anspruch nehmen. Zusätzlich gehen diese Änderungen verloren, wenn Sie die aktuelle Bereitstellung updaten, dies bedeutet, wenn Sie ein neues ContentXXLCloud.cspkg Paket hochladen.
WINDOWS AZURE DRIVE - .VHD - MIT CONTENTXXL
Damit Bestandsanwendungen einfach in die Cloud implementierbar sind und nicht angepasst werden müssen, hat contentXXL für die erst Implementierung in die Windows-Azure-Cloud auf das Windows-Azure-Drive gesetzt.
Das Windows-Azure-Drive ist eine extra Implementierung von Microsoft, dieses Windows-Azure-Drive ist für bereits existierende Anwendungen, die mit dem Dateisystem arbeiten (Dateien speichern, abändern, löschen, etc.), gedacht.
Das Windows-Azure-Drive ist, genauer gesagt, ein gemapptes Netzlaufwerk.
Dieses Netzlaufwerk hat eine .VHD Datei (http://en.wikipedia.org/wiki/VHD_%28file_format%29) im Hintergrund, diese .VHD Datei wird von Microsoft so emuliert wird, dass es dem Benutzer bzw. der Applikation so vorkommt, als würde er mit einem normalen Hard Disk Drive arbeiten, letztendlich ist diese .VHD Datei wiederrum im Blobstorage abgespeichert.
Benutzer können wie gewohnt über den Arbeitsplatz ihre Daten in das Hard Disk Drive ablegen.
Applikationen, die fest mit dem Dateisystem verbunden sind (System.IO Methoden in .NET), müssen hier keine Drittschnittstelle implementieren, z.B. zu einem Blobstorage.
Dadurch, dass die .VHD Datei im Blobstorage liegt, dauern Dateizugriffe länger, da die Daten über das Netzwerk geschickt werden müssen.
Hier spielt das Azure-Drive-Caching eine weitere Rolle, siehe hierzu „4.1. cscfg. Konfigurationsdatei - ActiveWindowsAzureDriveCacheValue“.
Diese Mechanismen sind allesamt von Microsoft implementiert, bzw. werden von Microsoft zur Modifizierung (Caching, Mapping, Emulierung etc.) bereitgestellt.
Damit Sie die „Virtuelle Hard Disk“ benutzten können, legt contentXXL durch die definierten Parameter in Punkt „4.1“ eine .VHD Datei (ActiveWindowsAzureDriveVHD, ActiveWindowsAzureDriveCacheValue) im Blobstorage (ActiveBlobAccountName, ActiveBlobAccountKey, ActiveBlobContainer) an.
Diese .VHD Datei wird nach dem anlegen über eine vorgegebene Schnittstelle von Microsoft als Netzlaufwerk auf dem aktuell instanziierten Server hinzugefügt und somit nutzbar gemacht.
Für nähere Informationen über das Windows-Azure-Storage (Windows-Azure-Drive ist eine abgewandelte Version hiervon) finden Sie unter:
BRINGEN SIE CONTENTXXL IN DIE CLOUD
Da Windows-Azure stateless (http://de.wikipedia.org/wiki/Stateless) arbeitet, müssen Ihre Daten auf einen anderen Weg verfügbar gemacht werden. In den nächsten Abschnitten erklären wir Ihnen wie Sie Ihre Daten in die Windows-Azure-Cloud bekommen.
DATEISYSTEM
Als erstes müssen die Dateien integriert werden, hierfür gibt es ein paar Möglichkeiten.
Möglichkeit 1 – RemoteDesktop – Kleine Datenmasse
Nachdem alle Konfigurationsparameter gesetzt wurden, verbinden Sie sich über die RemoteDesktop-Verbindung auf der aktuellen Rolleninstanz, siehe hierzu Punkt „3.0“.
Öffnen Sie den Arbeitsplatz:
Hier finden Sie nun ein Hard Disk Drive namens „WindowsAzureDrive“, der Hard Disk Drive Buchstabe verändert sich dynamisch und ist in diesem Fall „F:“
Spielen Sie unter diesem Hard Disk Drive Ihre contentXXL-Installation ein (Kopiervorgang von Ihrem Lokalrechner auf die RemoteDesktop-Verbindung).
Diese Methode sollte nur bei kleinen Datenmengen benutzt werden, da bei großen Datenmengen die Verbindung zum Server getrennt werden (Wenn der Server z.B. umgezogen wird oder sich neustartet) kann und somit der Kopiervorgang neu gestartet werden muss, dies könnte in Extremstfällen zu Datenverlust führen.
Das Ergebnis sieht dann in etwa so aus:
Möglichkeit 2 – Dritt-Tool – Große Datenmasse
Da bei größeren Installationen das Kopieren mehrere Stunden dauern kann, gibt es eine zweite Möglichkeit.
Hierfür brauchen Sie ein Dritt-Tool: http://geekswithblogs.net/technetbytes/archive/2011/04/18/144933.aspx
Wählen Sie hier ein Tool aus, dass Ihnen am meisten zusagt, in diesem Beispiel wird der „Azure Storage Explorer“ benutzt: http://azurestorageexplorer.codeplex.com/
Verbinden Sie sich mit dem Tool auf das angelegte Blobstorage:
Navigieren Sie in Ihren angelegten Container, den Sie in den Parametern festgelegt haben und suchen Sie die .VHD Datei.
Nachdem Sie die .VHD Datei gefunden haben, laden Sie diese Datei Lokal auf Ihren Rechner herunter.
Nach Abschluss des Downloads, rufen Sie die Datenträgerverwaltung auf, hierfür wird Windows 7 benötigt.
Fügen Sie die heruntergeladene .VHD an:
Suchen Sie Ihre virtuelle Festplatte:
Und klicken Sie danach auf „OK“
Nachdem die virtuelle Festplatte hinzugefügt wurde, können Sie diese über den Arbeitsplatz verwalten, hier können Sie nun Ihren ganzen Webauftritt hineinkopieren.
Achten Sie darauf, nicht nur das „portaldata“-Verzeichnis zu kopieren, sondern den kompletten Webauftritt.
Nachdem alle Daten auf die virtuelle Festplatte kopiert wurden, entkoppeln Sie die virtuelle Festplatte und laden Sie die fertige .VHD-Datei über das mitgelieferte Tool von contentXXL „UploadPageBlob“ hoch.
Hierzu starten Sie die Applikation.
Geben Sie Ihre Werte in die vorgegebenen TextBoxen ein.
Storage Accountname= ActiveBlobAccountName
Storage PrimaryKey = ActiveBlobAccountKey
Storage Container = ActiveBlobContainer
.VHD Name = Wenn dieses Feld leer bleibt, wird der .VHD Name der ausgewählten Datei verwendet, ansonsten der eigegebene.
Nachdem Sie alle Werte/Parameter eingegeben haben, drücken Sie auf „Start Upload“.
Im unteren Bereich ist eine Fortschrittsanzeige eingeblendet.
Achten Sie nach dem Hochladen darauf, dass die Parameter in der Konfigurationsdatei eventuell angepasst werden müssen, falls sich z.B. der .VHD Name abgeändert hat.
Achtung: Falls der Webauftritt in einem Unterverzeichnis liegt, achten Sie darauf, dass Sie den Konfigurationsparameter „ActiveWindowsAzureDriveSubDirectory“ abändern bzw. setzten.
Die .VHD Datei kann nur überschrieben werden, wenn die aktuelle Bereitstellung gestoppt wurde, da ansonsten die .VHD Datei von der aktuellen Rolleninstanz in Gebrauch ist.
MÖGLICHKEIT 1: Stoppen Sie die Bereitstellung (Siehe 3.3.2). Nachdem die Bereitstellung gestoppt wurde, laden Sie die neue .VHD Datei hoch. Bei einer langsamen Leitung kann dies mehrere Stunden dauern, dies würde bedeuten Ihre Rolleninstanz wäre in dieser Zeit nicht verfügbar.
MÖGLICHKEIT 2: Laden Sie die .VHD Datei unter einem anderen Namen hoch und ändern Sie, nachdem die .VHD Datei hochgeladen wurde, in der Konfigurationsdatei den ActiveWindowsAzureDriveVHD Parameter und laden die Konfigurationsdatei neu hoch.
Bei einem aktiven CMS würden in der Zeit während des Hochladens und abändern, mögliche neue Daten verloren gehen.
MÖGLICHKEIT 3: - .VHD selbst erstellen – Große Datenmasse
Rufen Sie die Datenträgerverwaltung auf, hierfür wird Windows 7 benötigt.
Erstellen Sie danach eine neue virtuelle Festplatte.
Achtung: Eine Small-Instanz in Windows-Azure kann eine maximale Hard Disk Größe von 225 GB verwalten, achten Sie daher darauf, dass Sie bei einer Small-Instanz (aktuelle Einstellung beim contentXXL Paket) diese maximale Größe nicht überschreiten.
Wählen Sie hier Ihren Speicherort aus und geben Sie die maximale Größe.
Das Format der virtuellen Festplatte ist „Feste Größe“.
Nachdem Sie alle Einstellungen getroffen haben drücken Sie auf „OK“.
Nachdem die virtuelle Festplatte erstellt wurde, fügen Sie diese Ihrem System hinzu.
Vielleicht müssen Sie die Festplatte noch Formatieren, belegen Sie diese mit einem MBR oder einer GUID sowie bei Bedarf mit einer NTFS Formatierung.
Nachdem die virtuelle Festplatte hinzugefügt wurde, können Sie diese über den Arbeitsplatz verwalten. Hier können Sie nun Ihren ganzen Webauftritt mit contentXXL hineinkopieren.
Achten Sie darauf, nicht nur das „portaldata“-Verzeichnis zu kopieren, sondern den kompletten Webauftritt.
Nachdem alle Daten auf die virtuelle Festplatte kopiert wurden, entkoppeln Sie die virtuelle Festplatte und laden Sie die fertige .VHD-Datei über das Tool auf das Blobstorage.
Gehen Sie hierzu zu Punkt 4.3.1.2 und laden Sie dort über das mitgelieferte Tool von contentXXL „UploadPageBlob“ die .VHD Datei erneut hoch.
Achtung: Die .VHD Dateien die über die Windows-Azure-Schnittstelle angelegt werden, werden alle mit Nullen initialisiert, dies wird bei der lokalen Variante über die Datenträgerverwaltung ggf. nicht auf die exakt gleiche Weise gemacht. Überprüfen Sie daher nach dem Hochladen der .VHD Datei Ihr Speicherkontingent, ob dies über das Erwartete gestiegen ist, falls nicht ist alles OK.
Falls der Webauftritt in einem Unterverzeichnis liegt, achten Sie darauf, dass Sie den Konfigurationsparameter „ActiveWindowsAzureDriveSubDirectory“ abändern bzw. setzten.
Überprüfen Sie Ihre Konfigurationsparametern „ActiveWindowsAzureDriveVHD“ und „ActiveBlobContainer“, ob dort Werte abgeändert werden müssen, da z.B. die .VHD-Datei nun anders heißt.
Falls bereits eine .VHD Datei existiert und diese überschrieben werden soll, kann dies nur geschehen, wenn die aktuelle Bereitstellung gestoppt wurde, da ansonsten die .VHD Datei von der aktuellen Rolleninstanz in Gebrauch ist.
MÖGLICHKEIT 1: Stoppen Sie die Bereitstellung (Siehe 3.3.2). Nachdem die Bereitstellung gestoppt wurde, laden Sie die neue .VHD Datei hoch. Bei einer langsamen Leitung kann dies mehrere Stunden dauern. Dies würde bedeuten, Ihre Rolleninstanz wäre in dieser Zeit nicht verfügbar.
MÖGLICHKEIT 2: Laden Sie die .VHD Datei unter einem anderen Namen hoch und ändern Sie, nachdem die .VHD Datei hochgeladen wurde, in der Konfigurationsdatei den ActiveWindowsAzureDriveVHD Parameter. Laden die Konfigurationsdatei neu hoch.
Bei einem aktiven CMS würden in der Zeit während des Hochladens und abändern, mögliche neue Daten verloren gehen.
DATENBANK
Um eine bereits erstellte Datenbank in die Windows-Azure-Datenbank zu bekommen, stellt Codeplex ein sehr nützliches Tool zur Verfügung: http://sqlazuremw.codeplex.com/
Windows-Azure bietet leider keine Möglichkeit, eine bereits existierende Datenbank in der Windows-Azure-Datenbank anzuknüpfen. Daher muss eine Bestandsdatenbank mit dem SQLAzureMW Tool integriert werden.
SYSTEM VORAUSSETZUNGEN:
- SQL Server 2008 R2 bits (oder aktuellere)
- BCP Version 10.50.1600.1 (oder aktuellere)
ERKLÄRUNGSVIDEO:
Achtung: Das Tool benutzt den Port 1433, falls dieser Port in Ihrem Unternehmen durch eine Firewall blockiert ist, kann das Tool nicht benutzt werden.
Die Daten, müssen nicht unbedingt in eine neue Datenbank eingefügt werden, die das Tool erstellt, sondern können auch auf eine Bestands Windows-Azure-Datenbank eingefügt werden, diese Daten sollten auf die unter Punkt 3.1 erstellte Datenbank eingefügt werden.
Falls Sie eine komplett neue Instanz von contentXXL erzeugen möchten, verbinden Sie sich, wie in dem Video gezeigt, über das SQL Server Management Studio mit der Windows-Azure-Datenbank und führen Sie das createdatabase_500.sql Script von contentXXL aus.
WEB.CONFIG
Conntectionstring:
<add Kley="connectionstring" value="Server=uok5pw0xi4.database.windows.net;Database=contetnXXL_Database;User ID=User@uok5pw0xi4;Password=password;Trusted_Connection=False;Encrypt=True;"/>
uok5pw0xi4 = Servername (abhängig von Ihrem Servernamen siehe Punkt 2.1)
contentXXL_Database = Datenbankname (abhängig von Ihrem Datenbanknamen siehe Punkt 2.1)
Basedir
<add key="basedir" value="”/>
Dieser Wert bleibt leer, contentXXL setzt diesen Wert selbstständig.
Portaldatadir
<add key="portaldatadir" value=" " / >
Dieser Wert bleibt leer, contentXXL setzt diesen Wert selbstständig.
BASEURLS
Durch die Besonderheit der Staging- und Produktionsbereitstellung in Windows-Azure sollte die Stagingumgebung in Windows-Azure nur zum Testen genommen werden.
Falls es einen Serverfehler gibt, oder einen overload des Servers, zieht dieser selbstständig neu um. Danach bekommt der Server eine neue URL. Diese muss wiederum in contentXXL eingetragen werden. Da man aber nie sagen kann, wann es zu einem reimaging des Servers kommt, sollte diese Bereitstellung nicht als Live-Einsatz angedacht werden, sondern nur zu konkreten Testzwecken.
In einer Produktionsbereitstellung, wird das DNS-Präfix als URL genommen, das unter „Gehosteter Dienst“ eingetragen wurde.
Eine URL könnte dann wie folgt aussehen: http://contentxxl.cloudapp.net/, diese URL bleibt immer gleich, auch wenn es zu einem reimaging des Serves kommt.
Durch diese Gründe, sollte keine Stagingumgebung als Produktiveinsatz benutzt werden.
LIZENSIERUNG
Die laufenden Server in Windows-Azure sind alle stateless, das bedeutet, sie sind unabhängig vom Rest, daher ändert sich nach einem reimaging immer der Servername, daher Lizensiert contentXXL in der Cloud nicht den Servernamen, sondern die angegebene Bereitstellungs-ID.
Die Bereitstellungs-ID finden Sie unter:
Die Bereitstellungs-ID ist einzigartig und zu jeder Bereitstellung unterschiedlich.
Die Bereitstellungs-ID verändert sich nur, falls die Bereitstellung gelöscht wird und eine neue angelegt wird. Falls dies passiert, muss eine neue contentXXL-Lizenz beantragt werden.
Achtung: Das Löschen einer Bereitstellung passiert nicht selbstständig, sondern muss durch Sie händisch ausgeführt werden.
EIGENE IMPLEMENTIERUNGEN
Falls Sie eigene Implementierungen geschrieben haben und diese feste Pfadangaben haben, wie z.B.: „D:\live\Folder\data“, in diesem Fall ist „live“ das Root-Verzeichnis auf das der IIS schaut, tauschen Sie dies durch „Server.Mappath(„~“) + „\Folder\Data“ aus (http://msdn.microsoft.com/de-de/library/system.web.httpserverutility.mappath.aspx)
Dies ist nötig, da das Windows-Azure-Drive einen beliebigen Buchstaben zugewiesen bekommt, der erst während der Laufzeit bekannt ist.
Falls Sie mit Portal.Basedir oder Portal.Portaldatadir arbeiten, müssen Sie nichts abändern.
EIGENE DOMAIN
Da Windows-Azure eine Instanz immer mit http://GUID_Präfix.cloudapp.net bereitstellt und dies Problematiken im Thema CI aufwirft gibt es eine Möglichkeit eine eigene Domain für die bereitgestellt Instanz zu hinterlegen.