Lösungsszenarien Azure

Transcrição

Microsoft Azure
Lösungsszenarien
31.12.2014, v1.0.44 , [email protected]
Disclaimer
Die in diesem Dokument beschriebenen Lösungsszenarien stellen eine Orientierungshilfe dar und sind
nicht als im Detail validierte Lösungskonzepte zu verstehen. Die gemachten Angaben zu
Aufwendungen und Kosten entsprechen den persönlichen Erfahrungen des Autors und basieren auf
Preisen und Plattformversionen, die im Dezember 2014 gültig waren. Vor der Implementierung eines
der beschriebenen Konzepte sind die zum gegebenen Zeitpunkt gültigen Quelldokumentationen und
Best Practice-Empfehlungen von Microsoft zu konsultieren und die zu erwartenden Kosten aufgrund
der aktuellen Preislisten zu bestimmen. Alle Preisangaben verstehen sich zzgl. MWSt.
Inhalt
Microsoft Azure Lösungsszenarien ........................................................................................................................... 1
1:
Backup-DC auf Azure..........................................................................................................................................2
2:
Zentrale Dateidienste auf Azure mit dezentralem BranchCache ...............................................................6
3:
Hybrid Cloud Storage (StorSimple) ................................................................................................................ 10
4:
Backup nach Azure (verschiedene Varianten: Windows Server, SQL Server, DPM, 3rd-Party) ......... 14
5:
SQL Server HA (Availability Groups auf Azure oder hybrid mit lokalen Servern kombiniert) ............ 18
6:
SharePoint auf Azure IaaS mit optionaler On-Prem Datenhaltung ........................................................ 22
7:
Autoskalierende Websites ............................................................................................................................... 26
8:
SAP auf Azure .................................................................................................................................................... 30
9:
Oracle Dev & Test ............................................................................................................................................. 33
10: ADFS auf Azure IaaS für On-Prem AD-Forests ........................................................................................... 36
11:
DirSync/AAD Sync auf Azure IaaS für On-Prem Forests........................................................................... 39
12: BI und Reporting für mobile Anwender sowie als ISV-Saas-Angebot (SQL Server Reporting
Services in Azure IaaS) ..................................................................................................................................... 42
13: Globaler WAN/LAN -Interconnect via Azure Virtual Networks ............................................................... 45
14: Migration von Hyper-V und VMware VMs in Azure Virtual Machines .................................................. 48
15: Schnelles Wiederherstellen virtueller Server (Azure Site Recovery) ......................................................... 51
16: Offline Files via Windows Server File Sharing auf Azure IaaS .................................................................. 54
17: Publizieren interner Webapplikationen für externe Nutzer (AAD Application Proxy)......................... 57
31.12.14, v1.0.44
-1-
Microsoft Azure Lösungsszenario
1: Backup-DC auf
Azure
Ziel, Kundennutzen
Ein Firmennetzwerk ist gegen die Folgen des Ausfalls eines oder
mehrerer Domänencontroller zu schützen.
Ausgangslage, Herausforderung


Ausgangslage A
Ein Firmennetzwerk verfügt nur über einen einzigen Domänencontroller. Fällt dieser aus, ist es u.U.
während eines längeren Zeitraums – bis zu Wiederherstellung aus einer Datensicherung - nicht
mehr möglich, die Netzwerkressourcen der Firma zu nutzen.
Ausgangslage B
Ein Firmennetzwerk verfügt nur an einem einzigen physischen Standort über Domänencontroller
(mehrere redundante). Diese redundanten Server schützen sich zwar gegenseitig gegen den
Ausfall eines einzigen Servers. Ist aber der ganze Firmenstandort von einem Ausfall tangiert – z.B.
bei einem Brand – ist die Autorisierungsinfrastruktur über einen längeren Zeitraum nicht nutzbar.
Dies betrifft auch externe Benutzer bzw. das temporäre Arbeiten an einem Ausweichstandort.
31.12.14, v1.0.44
-2-
Lösungsszenario
Als Ergänzung zu dem oder den internen Domänencontroller(n) wird ein weiterer solcher Server als
virtuelle Maschine auf Microsoft Azure betrieben. Die Integration in das lokale physische
Firmennetzwerk findet via stehende VPN-Verbindung nach Azure statt.
Im Pannenfall kann der auf Azure betriebene Domänencontroller entweder die führende Rolle für das
Firmennetzwerk übernehmen oder lässt sich aus dessen Daten ein neuer lokaler Domänencontroller
erzeugen.
Argumente für dieses Szenario


Das Bereitstellen und integrieren zusätzlicher Domänencontroller ist auf Azure wesentlich
kostengünstiger als in der firmeninternen Infrastruktur.
Bei Ausfall eines Firmenstandorts ist man mit auf Azure betriebenen Servern - z.B. dem zentralen
Domänencontroller - ortsunabhängig und kann eine Ausweichinfrastruktur an nahezu jedem
beliebigen Standort aufbauen.
Lösungsarchitektur
Verwendete Azure-Dienste



Azure VM
Azure Storage (Page Blobs, für OS Disk)
Azure Virtual Network mit Site-to-Site-VPN in das physische lokale Netzwerk
31.12.14, v1.0.44
-3-
Kosten
Azure Betriebskosten (Beispiel)
Als repliziertes Reservesystem genügt i.d.R. eine Maschine des Typs A1 (Basic, 1 Prozessorkern, 1.75GB
RAM, nur ein Betriebssystemdisk) mit nur lokaler Speicherredundanz:




Azure VM
CHF
642.-- p.a.
Azure Storage (127GB, lokal redundant)
73.-- p.a.
Azure Virtual Network Gateway (VNet ist gratis, nur GW kostet)
313.-- p.a.
Bandbreitennutzung (5GB inbegriffen p.m.)
vernachlässigbar
Total ca.
CHF
1'028.-- p.a.
Da diese Backup-Maschine nicht zwingend 7x24 laufen muss, können die Kosten weiter optimiert
werden, indem die Maschine nur periodisch für einige Stunden eingeschaltet wird (z.B. einmal
wöchentlich, je nach Häufigkeit der Änderungen in der Domäne). Dies wirkt sich auf die erste
Kostenposition aus (z.B. Reduktion auf ca. CHF 100.-- p.a., wenn die Maschine nur einen Tag in der
Woche läuft).
Implementierungsaufwand
Zu erwartender Implementierungsaufwand (exkl. Planung, bei bestehender Internetanbindung,
vorhandenen lokalen Servern und vorhandener Azure-Subscription): ca. 2 Stunden.
Der Aufbau des S2S-VPN-Tunnels kann u.U. Rechercheaufwand generieren, ist aber grundsätzlich
schnell realisiert. Wenn kundenseitig ein Firewall-Produkt im Einsatz ist, das entweder von Microsoft
unterstützt ist oder für welches der Kunde oder der Partner das notwendige Know-how hat, fallen
hierfür keine nennenswerten Aufwendungen an. Es ist ein IPsec IKEv2-Tunnel einzurichten, der die von
Azure vorgegebenen Spezifikationen erfüllt. Azure VPN-Tunnels verwenden gängige StandardParameterwerte.
31.12.14, v1.0.44
-4-
Technik
Implementierungsschritte (Übersicht)





Azure Storage Account für die vhd der VM anlegen und gewünschte Redundanz/Kosten
einstellen.
Ein Azure Virtual Network anlegen (mit Option Site-to-Site-VPN, bestehenden lokalen DC als
DNS-Server registrieren).
Gateway im Azure VNet erzeugen und Site-to-Site-VPN-Tunnel einrichten.
Neue Azure VM mit fixer IP im Azure VNet erzeugen.
Neue Azure VM zum Domänencontroller in der bestehenden Domäne erheben.
Integrationsmöglichkeiten
Die Verbindung zum virtuellen Domänencontroller auf Azure findet für die bestehenden Serverdienste
transparent via IP-Routing (über den Site-to-Site-VPN-Tunnel) statt. Alle Integrationsmöglichkeiten
eines Domänencontrollers sind so nutzbar wie wenn dieser im lokalen Netzwerk betrieben würde.
Weitergehende Informationsquellen

http://azure.microsoft.com/en-us/documentation/articles/virtual-networks-install-replica-activedirectory-domain-controller/
Die technische Dokumentation zu den verwendeten Azure-Diensten ist hier zu finden:
http://azure.microsoft.com/en-us/documentation/.
31.12.14, v1.0.44
-5-
2: Zentrale
Dateidienste auf Azure
mit dezentralem
BranchCache
Ziel, Kundennutzen


Keine individuellen VPN- oder DirectAccess-Verbindungen in das Firmennetzwerk sind mehr
notwendig. Durch den Wegfall dieser Notwendigkeit sinken sowohl die Unterhaltskosten als auch
die Kosten für Infrastrukturkomponenten.
Für verschiedene Firmenstandorte wird eine zentrale, konsolidierte Dateiserver-Infrastruktur
bereitgestellt. Diese erübrigt das Betreiben dezentraler Dateiserver an verschiedenen
Firmenstandorten und erlaubt es, eine zentrale Dateiablage an einem einzigen Ort mit geringerem
Aufwand zu verwalten.


Dateien auf internen Dateiservern, die via Netzwerkshares genutzt werden, können von entfernten
Standorten oder ab mobilen Geräten nur via vorherigen Aufbau einer VPN- oder DirectAccessVerbindung genutzt werden. Das Verwalten der Zugangsinfrastruktur für VPN oder DirectAccess
ist potentiell aufwendig und fehleranfällig.
Verschiedene Firmenstandorte verfügen über je separate Dateiablagen auf Dateiservern, die
untereinander nicht oder nur sehr aufwendig integrierbar und abgleichbar sind.
31.12.14, v1.0.44
-6-
Lösungsszenario
Auf Microsoft Azure wird ein hochverfügbarer, zugänglicher Dateiserver zentral für die ganze Firma
betrieben. Jeder Firmenstandort oder auch einzelnen Windows-Clients können via VPN-Tunnels zum
virtuellen Azure-Netzwerk, in welchem der Dateiserver läuft, Verbindung aufnehmen. Das Bereitstellen
der VPN-Infrastruktur und das Gewährleisten der Plattformverfügbarkeit werden als Managed Service
durch Azure sichergestellt.
Die Zugriffszeiten auf die zentral gespeicherten Dateien werden verringert, indem der Windows-Dienst
BranchCache eingesetzt wird. Dieser kennt zwei Betriebsmodelle:


Hosted: am dezentralen Firmenstandort läuft ein Caching-Server.
Distributed: die dezentralen Clients an einem bestimmten Standort haben individuelle Caches, die
automatisch untereinander geteilt werden.
Die Leistung von BranchCache kann mit jener von OneDrive for Business verglichen werden, wobei hier
die Active Directory-Domänenfunktionalität in vollem Umfang zur Verfügung steht. Andererseits
können die BranchCache-Daten nur auf Windows-Clients genutzt werden.
Hosted Cache Mode:
Distributed Cache Mode:


Kosteneinsparung (Wartungsaufwand und Infrastruktur) durch Wegfall der im firmeninternen
Netzwerk zu pflegenden VPN-/DirectAccess-Infrastruktur.
Global verfügbare zentrale Dateiserverinfrastruktur, die sich auf von Microsoft verwaltete,
hochverfügbare Kommunikationszugänge (VPN) stützt.
31.12.14, v1.0.44
-7-
Lösungsarchitektur
Das Lösungsszenario stützt sich auf eine in einem Azure Virtual Network betrieben VM. Das Azure
VNet ist per VPN-Tunnel an die lokale Netzwerkinfrastruktur angebunden. Alternativ können WindowsClients direkt VPN-Verbindungen in das Azure VNet herstellen.
Zur Realisierung des 99.95% SLA wäre ein Cluster mit hochverfügbarem Dateidienst aufzubauen.
Windows Server Failover Clustering ist zwar technisch realisierbar, derzeit aber seitens Microsoft erst
zur Abbildung von SQL Server AlwaysOn Availability Groups unterstützt.
Eine weitere Realisierungsvariante für Hochverfügbarkeit der Windows Dateidienste könnten sich die
derzeit als Preview verfügbaren Azure-Fileshares (SMB 2.1) anbieten.




Azure Storage
Azure VM
Azure Virtual Network
Kosten
Die Dimensionierung der virtuellen Maschine auf Azure richtet sich nach Datenmenge, Benutzerzahl
und den zu erwartenden Nutzungsszenarien. Ein Beispiel:





1 Azure VM (Standard A2)
CHF
Azure Storage für OS (1x127GB, lokal redundant)
Azure Storage für Daten (2TB, georedundant)
Bandbreitennutzung (500GB downstream p.m.)
1'560.-- p.a.
73.-- p.a.
2'043.-- p.a.
313.-- p.a.
693.-- p.a.
Total ca.
4'682.-- p.a.
CHF
Die Storage-Kosten werden nur für den effektiv belegten Platz pro Abrechnungsperiode verrechnet.
31.12.14, v1.0.44
-8-
Bei bestehender Internetanbindung, vorhandenen lokalen Servern und vorhandener AzureSubscription ist die Azure-seitige Bereitstellung in zwei bis vier Stunden realisierbar (exkl. Planung und
Datentransfer auf den neuen Fileserver).
Technik
1.
2.
3.
4.
5.
6.
7.
Azure Storage Account für die vhd der VM anlegen und gewünschte Redundanz/Kosten
einstellen.
Ein Azure Virtual Network anlegen, dies sowohl mit Option Site-to-Site-VPN als auch Point-toSite-VPN (für mobile Windows-Clients). Für Point-to-Site müssen die VPN-Endpunkte an den
Firmenstandorten (i.d.R. die Firewalls) IKEv2 und dynamisches Routing unterstützen. Im Azure
VNet die lokalen DNS-Server registrieren.
Neue Azure VM mit fixer IP im Azure VNet erzeugen.
Die neue Azure VM in die Firmendomäne einbinden.
Die neue Azure VM mit Dateidiensten und BranchCache konfigurieren.
BranchCache auf Servern und/oder Clients an den Firmenstandorten einrichten.
Die Verbindung zum virtuellen Dateiserver auf Azure findet für die bestehenden Server und Clients der
Firma transparent via IP-Routing (über den Site-to-Site-VPN-Tunnel ab einem Firmenstandort oder
über eine Point-to-Site-VPN-Verbindung ab einem mobilen Windows-Client) statt. Alle
Integrationsmöglichkeiten des Dateiservers sind so nutzbar wie wenn dieser im lokalen Netzwerk
betrieben würde.
Mit BranchCache wird verhindert, dass jede Datei direkt via Internetverbindung (und somit potentiell
langsam) ab dem auf Azure betriebenen Dateiserver geöffnet wird. Stattdessen werden die einmal
heruntergeladenen Dateien lokal in einem Cache gehalten und aktualisiert.

BranchCache Technical Overview: http://www.microsoft.com/enus/download/details.aspx?id=10276
31.12.14, v1.0.44
-9-
3: Hybrid Cloud
Storage (StorSimple)
Ziel, Kundennutzen
Eine kostengünstige, einfach zu administrierende und mit geringem
Aufwand skalierbare Speicherlösung. Sie macht Inhalte automatisch
hochverfügbar, ist in kurzer Zeit wiederherstellbar und komprimiert
und archiviert wenig genutzte alte Inhalte automatisch.
Die Lösung vermeidet es, stets mehr physischen Datenspeicher
bereitstellen zu müssen.
Lokal verwalteter persistenter Speicherplatz in SANs und anderen Speichersystemen ist teuer,
insbesondere wenn er hochverfügbar und mit kurzen RTO-Werten für Disaster Recovery zu versehen
ist. Das Bereinigen, Komprimieren, Archivieren und Sichern von stetig wachsenden Datenablagen ist
komplex und aufwendig.
31.12.14, v1.0.44
- 10 -
Lösungsszenario
Azure Storage erlaubt als Primärspeicher sowohl Hochverfügbarkeit als auch tiefe RTO-Werte. Aber
auch als sekundäre Ablage für Archive und dergleichen bietet sich Azure aufgrund der sehr geringen
Kosten für Speicherplatz, verbunden mit hoher Qualität und Flexibilität, an.
Azure Storage unterstützt ein sehr grosse Zahl an Lösungsszenarien. V.a. an grosse Unternehmen
richtet sich das Szenario auf der Basis der StorSimple-Appliance (sie ist nur via Enterprise Agreement
erhältlich). Es resultiert in minimalem Verwaltungsaufwand und maximaler Flexibilität.
StorSimple wird hierbei zwischen den internen Applikationsdiensten des Unternehmens und Microsoft
Azure platziert. Die Appliance stellt eine lokale SAN-Infrastruktur zur Verfügung, deren Inhalte
differenziert und für die Applikationen transparent nach Azure ausgelagert werden können. Der lokal
zur Verfügung gestellte Speicherplatz bleibt hierbei begrenzt, Azure Storage dient als sekundäres
Overflow-Medium für wenig benötigte oder archivierbare Inhalte. Das lokale Bereitstellen von nach
Azure ausgelagerten Inhalten geschieht bei Bedarf automatisch und für die Nutzer transparent.
Dieses Tiering ist mit jenem der Windows Server Storage Spaces (2012+) vergleichbar, aber wesentlich
einfacher und letztlich kostengünstiger implementierbar.



Für die Nutzer transparentes Datenmanagement (Deduplikation, Kompression, Backup,
Versionierung, Archivierung, Verschlüsselung).
Automatisch skalierendes Speicherplatzangebot ohne manuelles Einrichten von Disks bei
wachsendem Platzbedarf (Altes und wenig Genutztes wird transparent ausgelagert).
Niedrige Kosten für persistenten Speicher mit hoher Verfügbarkeit und tiefer RTO.
31.12.14, v1.0.44
- 11 -
Lösungsarchitektur
Beispiel einer SharePoint Server Farm:
StorSimple verwendet neben der physischen Appliance auch eine virtuelle Appliance auf Azure. Diese
nutzt folgende Dienste:



Azure Storage Account
Azure Compute Role (Virtual Machine)
Kosten
Azure Betriebskosten
Die StorSimple 8100 Appliance enthält 15 TB lokale Speicherkapazität, wovon 800GB auf SSD liegen. Sie
kostet derzeit ca. USD 100'000.--. Dazu ist eine jährliche Subscription für Azure Storage (Block-Blobs)
für entweder 50TB oder 100TB (sechsfach georedundant) via ein Enterprise Agreement zu ergänzen.
Da das StorSimple-Gerät als Blackbox vorkonfiguriert ausgeliefert wird und nur an die lokale
Netzwerkinfrastruktur anzupassen ist, ist der Implementierungsaufwand sehr gering (< 1 Tag exkl.
Planung).
31.12.14, v1.0.44
- 12 -
Technik









Azure Storage Account anlegen und gewünschte Redundanz/Kosten einstellen.
Neue Azure-Dienstinstanz vom Typ "StorSimple Manager" (Storage Services) erstellen.
StorSimple-Servicekey (symmetrischer Registrierungsschlüssel) aus dem Azure-Portal abrufen.
Das StorSimple-Gerät konfigurieren (lokale Netzwerkeinbindung) und in Azure registrieren (nur
per PowerShell).
StorSimple-Gerätesetup vornehmen (via Azure-Portal).
Einen ersten Volumecontainer erstellen und konfigurieren.
Ein erstes Volume im neuen Volumecontainer erstellen.
Das neue Volume initialisieren, formatieren und konfigurieren.
Einen Sicherungsjob erstellen.
Weitere Details gemäss http://msdn.microsoft.com/de-de/library/dn772410.aspx.
Die StorSimple-Appliance stellt iSCSI-Devices im lokalen Netzwerk zur Verfügung.
StorSimple stellt einen einen RBS-Adapter (Remote BLOB Storage) für SharePoint zur Verfügung.




StorSimple Hybrid Cloud Storage: http://www.microsoft.com/en-us/servercloud/products/storsimple/
StorSimple 8000 Series Datasheet: http://download.microsoft.com/download/E/2/1/E21B7C166D43-4E4A-B2EC-EEB284047F87/StorSimple_8000_Series_Datasheet.pdf
StorSimple Pricing: http://storsimple.seagate.com/sites/dealr/files/Xyratex_Price_List.pdf
StorSimple at Seagate: http://storsimple.seagate.com/storsimple-solution-family
31.12.14, v1.0.44
- 13 -
4: Backup nach Azure
(verschiedene
Varianten: Windows
Server, SQL Server,
DPM, 3rd-Party)
Ziel, Kundennutzen
Datensicherungen mit geringem Aufwand off-site lagern hochverfügbar und mit hoher Ausfallredundanz.
Datensicherungen sollen schnell an jedem beliebigen Ort verfügbar
gemacht werden können (z.B. bei Aufbau einer Notinfrastruktur an
einem neuen Ort nach einem Hausbrand).
Das Wiederherstellen einzelner Dateien ist schnell und ohne
komplexe Softwarekonfiguration abzuwickeln.



Datensicherungen sind mit beträchtlichem Aufwand physisch getrennt vom primären Speicherort
zu lagern.
Im Wiederherstellungsfall sind die physischen Medien u.U. erst mit zeitlicher Verzögerung und
geografisch nicht unmittelbar am gewünschten Ort verfügbar.
Für das Wiederherstellen einzelner Dateien aus einer Datensicherung sind u.U. lange laufende
Prozesse (Tape-Verarbeitung) bzw. spezifische Softwarelösungen notwendig.
31.12.14, v1.0.44
- 14 -
Lösungsszenario
Ein Azure Storage Account, der als Backupmedium eingesetzt wird, erfüllt die obigen typischen
Ansprüche an Backups.
Das Ergänzen des Storage Accounts um den Azure Backup Service ergänzt dies um eine
Managementfunktion, die ohne lokale Infrastruktur spezifische Inhalte wiederherstellen kann (z.B.
einzelne Dateien bestimmter Versionen). Hierbei erfolgt die Verarbeitung von Backup-Sets Azure-seitig
ohne aufwendigen Download grosser Datenmengen.
Der Datensicherungsprozess wird mit lokaler Standardsoftware ausgeführt.
Betriebssystemkomponenten von Windows Server, SQL Server und System Center Data Protection
Manager sind in ihren aktuellen Versionen in der Lage, Datensicherungen direkt in Azure Storage
Accounts abzulegen. Dritthersteller - z.B. cloudberrylab.com - unterstützen dieses Szenario ebenfalls.




Hochverfügbare Datenspeicherung mit automatisch skalierendem Speicherplatz ohne aufwendige
Konfigurationsarbeiten.
Kostengünstige Speicherlösung hoher Qualität (sechsfach georedundant, 99.9% verfügbar).
Managed Service der Wiederherstellungsaufträge werden ohne lokale Softwareinstallation
abgewickelt.
Verfügbarkeit der Datensicherungen an jedem internetzugänglichen Punkt der Erde.
31.12.14, v1.0.44
- 15 -
Lösungsarchitektur
Microsoft Azure
Portal
Anmeldung
Abrechnung
Microsoft Azure
Backup-Dienst
Registrierung
Sicherung/
Wiederherstellung
Eingangsmodul
Windows
Server
2012 R2
Eingangsbenutzeroberfl
Windows Server
2012 R2 Sicherung
(erweiterbar)
Azure BackupAgent
IT-Mitarbeiter


Azure Storage
Azure Backup
Kosten
Die reinen Speicherkosten liegen zwischen CHF 0.25 (lokale Dreifachredundanz innerhalb eines Data
Centers) und CHF 1.20 (sechsfache Georedundanz) pro GB p.a. für den effektiv belegten Speicherplatz.
Wird der Azure Backup Dienst verwendet (Azure-seitige Verwaltungsdienste), so fallen CHF 1.85 pro GB
p.a. an (die ersten 5GB pro Monat sind kostenlos).
Beide Szenarien lassen sich bei bestehender Internetanbindung, vorhandenen lokalen Servern und
vorhandener Azure-Subscription in einer Stunde realisieren (exkl. Planung).
31.12.14, v1.0.44
- 16 -
Technik
Nur mit Azure Storage, z.B. aus SQL Server:




Container im Azure Storage Account anlegen.
Storage-URL und Speicherschlüssel notieren.
Standard-Backupjob in SQL Server einrichten unter Verwendung der Storage-URL und des
Speicherschlüssels für die Angabe des Speichermediums.
Mit Azure Backup, aus Windows Server:





Azure Backup-Dienstinstanz anlegen.
Managementzertifikat erzeugen und in Azure Backup bereitstellen.
Azure Backup-Agent herunterladen.
Azure Backup-Agent auf Windows Server installieren und Backupjobs konfigurieren.
31.12.14, v1.0.44
- 17 -
5: SQL Server HA
(Availability Groups
auf Azure oder hybrid
mit lokalen Servern
kombiniert)
Ziel, Kundennutzen
Auch mit begrenzten Budgets und IT-Verwaltungsressourcen soll
eine SQL Server-Konfiguration hochverfügbar und fehlertolerant
betrieben werden können.
Für das Einrichten hochverfügbarer SQL Server-Konfigurationen sind AlwaysOn Availability Groups zwar
kostengünstiger realisierbar als Clusterlösungen. Sie bedingen aber weiterhin separate, zur Erreichung
von echter Hochverfügbarkeit geografisch getrennte Serverinstanzen, was beträchtliche Investitionen
und entsprechenden Verwaltungsaufwand nach sich zieht.
31.12.14, v1.0.44
- 18 -
Lösungsszenario
SQL Server AlwaysOn Availability Groups lassen sich unter Einbezug von Azure VMs kostengünstig und
mit hoher Qualität entweder vollständig Cloud-gestützt (alle Server laufen auf Azure) oder hybrid (z.B.
indem zu einem lokalen Server ein weiterer auf Azure ergänzt wird) realisiert werden.
Die lokale Netzwerkinfrastruktur ist hierfür nach Azure zu verlängern, indem dort zuerst ein Azure
Virtual Network aufgebaut wird. Dieses wird über einen VPN-Tunnel an das lokale Netzwerk
angebunden.



Kostengünstige Realisierung von Hochverfügbarkeit für SQL Server.
Wegfall der Notwendigkeit von zusätzlicher Hardware oder geografisch verteilten SQL ServerInstallationen innerhalb des Betriebs.
Die Storage-Kosten werden nur für den effektiv belegten Platz pro Abrechnungsperiode
verrechnet.
Lösungsarchitektur
Beispiel einer hybriden Architektur:



Azure Storage
Azure VM
31.12.14, v1.0.44
- 19 -
Kosten
Anzahl und Dimensionierung der virtuellen Maschine auf Azure richtet sich nach den Anforderungen
der zu realisierenden SQL Server Availability Group.
Beispiel einer einzelnen SQL Server-Instanz mittlerer Grösse:





1 Azure VM (SQL Server Enterprise Basic A3 mit
4 Prozessorkernen und 7 GB RAM,
inkl. SQL Server-Lizenzen)
CHF
15'570.-- p.a.
73.-- p.a.
Azure Storage für Daten (500GB, lokal redundant)
292.-- p.a.
313.-- p.a.
Bandbreitennutzung (mehrheitlich upstream)
vernachlässigbar
Total ca.
CHF
16'248.-- p.a.
Bei bestehender Internetanbindung, vorhandenen lokalen Servern und vorhandener AzureSubscription ist die Azure-seitige Bereitstellung von ein bis drei Servern in zwei bis drei Stunden
realisierbar (exkl. Planung).
Das Konfigurieren der Availability Group ist in dieser Schätzung nicht enthalten, dieser Aufwand ist der
gleiche wie wenn das Konzept lokal realisiert wird.
31.12.14, v1.0.44
- 20 -
Technik






Azure Storage Account für die vhd der VM anlegen und gewünschte Redundanz einstellen.
Azure Virtual Network anlegen, dies mit Option Site-to-Site-VPN. Im Azure VNet die lokalen DNSServer registrieren.
Neue Azure VM(s) mit fixer IP im Azure VNet erzeugen.
Neue Azure VMs(9 in die Firmendomäne einbinden.
Die neue(n) Azure VMs mit SQL Server als Availability Group konfigurieren.
Die Verbindung zu dem oder den virtuellen Servern auf Azure findet für die bestehenden Server und
Clients der Firma transparent via IP-Routing statt (über den Site-to-Site-VPN-Tunnel ab einem
Firmenstandort). Alle Integrationsmöglichkeiten des oder der SQL Server-Maschinen sind so nutzbar
wie wenn diese im lokalen Netzwerk betrieben würden.

HA/DR für SQL Server in Azure VMs: http://msdn.microsoft.com/en-us/library/azure/jj870962.aspx
31.12.14, v1.0.44
- 21 -
6: SharePoint auf
Azure IaaS mit
optionaler On-Prem
Datenhaltung
Ziel, Kundennutzen
SharePoint-Serverfarmen sollen agiler und skalierbarer und mit
weniger lokalem Hardware- und Unterhaltsaufwand betreibbar sein.
Optional soll die Speicherung eines Teils der Daten der SharePointFarm lokal im Betrieb des Kunden (z.B. in der Schweiz) bleiben. Die
SharePoint-Dienste selbst können auf Azure laufen.
Als Kundennutzen soll sich einstellen:
 Tiefere Betriebskosten
 Höhere Agilität (verändertes Nutzungsszenario für SharePoint)
 Bessere Skalierbarkeit (Anpassung der Plattformleistung an
grössere/kleinere Datenmengen und Nutzerzahlen)
Das Betreiben und Unterhalten von SharePoint-Serverfarmen ist komplex und aufwendig. Bei
veränderlicher Nutzung sind für die Optimierung einer Serverfarm u.U. auch Änderungen an den
Serverplattformen notwendig (z.B. durch Hinzufügen zusätzlicher Server für spezifische SharePointDienste).
31.12.14, v1.0.44
- 22 -
Lösungsszenario
SharePoint-Serverfarmen lassen sich vollumfänglich in Azure VMs betreiben. Hierbei können sie bei
Bedarf auch automatisch skalieren, indem einzelne Farm-Mitgliedserver automatisch aus- oder
eingeschaltet werden bei verändertem Bedarf.
Über eine VPN-Anbindung an ein lokales Firmennetz können Content-Datenbanken der SharePointFarm auch auf lokalen SQL Server-Instanzen in der internen Netzwerkinfrastruktur des Kunden gehalten
werden. Dies kann unter der Voraussetzung, dass die VPN-Verbindung nach Azure eine Latenz <50ms
hat (ggf. ist Azure ExpressRoute zu prüfen hierfür), auch mit direkter Datenbankanbindung und ohne
Nutzung von BCS erfolgen.



Einfacher und flexibler Umbau der SharePoint-Farm bei veränderten Bedürfnissen, ohne
Hardware-Komponenten planen oder beschaffen zu müssen.
Kosteneinsparung durch automatische Skalierung der SharePoint-Serverinstanzen aufgrund
aktueller Nutzung oder auf der Basis von Zeitplänen.
Keine Notwendigkeit für Datenspeicherung in der Cloud.
Lösungsarchitektur



Azure Storage
Azure VM
31.12.14, v1.0.44
- 23 -
Kosten
Die Dimensionierung der virtuellen Maschinen auf Azure richtet sich nach den Detailbedürfnissen der
SharePoint-Farm.
Ein Beispiel einer 99.95% verfügbaren, vollständig in Azure betriebenen Farm mit insgesamt neun
Servern (2x Active Directory, 3x SQL Server, 4x SharePoint):








2 Azure VMs Standard A1 (DC: 1 Core/1.75GB RAM)
CHF
2 Azure VMs Standard A5 (SQL: 2 Core/14GB RAM)
1 Azure VMs Basic A0 (SQL Witness: 1 Core/768MB RAM)
4 Azure VM Standard A2 (SharePoint, 2 Core/3.5GB RAM)
Total ca.
CHF
1'560.-- p.a.
5'750.-- p.a.
174.-- p.a.
6'241.-- p.a.
657.-- p.a.
2'043.-- p.a.
313.-- p.a.
139.-- p.a.
16'877.-- p.a.
SharePoint-Lizenzen sind in dieser Zusammenstellung nicht enthalten, Windows Server- und SQL
Server-Lizenzen hingegen schon.
Die Storage-Kosten werden nur für den effektiv belegten Platz pro Abrechnungsperiode verrechnet.
Bei bestehender Internetanbindung, vorhandenen lokalen Servern (Domäne) und vorhandener AzureSubscription ist die Azure-seitige Bereitstellung mit dem neuen Wizard in zwei Stunden möglich (exkl.
Planung).
Das Konfigurieren der SharePoint-Farm ist in dieser Schätzung nicht enthalten, dieser Aufwand ist der
gleiche wie wenn das Konzept lokal realisiert wird.
31.12.14, v1.0.44
- 24 -
Technik



Erzeugen der vollständigen SharePoint-Farm inkl. Domänencontroller und SQL Servern per Wizard
auf dem neuen Azure-Portal (portal.azure.com).
Azure Virtual Network rekonfigurieren und optional an das lokale Netzwerk anbinden (S2STunnel).
SharePoint-Farm per RDP in den VMs konfigurieren, mit den üblichen Werkzeugen (nicht Azurespezifisch).
Firmenstandort). Alle Integrationsmöglichkeiten des oder der SQL Server-Maschinen sind so nutzbar
wie wenn diese im lokalen Netzwerk betrieben würden.
Auf diesem Weg sind z.B. weitere Content-Datenbanken interner SQL Server-Instanzen oder interne
BCS-Verbindungen zu solchen realisierbar.

SharePoint auf Azure IaaS: http://msdn.microsoft.com/en-us/library/azure/dn275955.aspx
31.12.14, v1.0.44
- 25 -
7: Autoskalierende
Websites
Ziel, Kundennutzen
Websites sind so zu betreiben, dass nur die für aktuelle notwendige
Kapazität bereitzustellenden Ressourcen Kosten erzeugen und
keine Überkapazitäten zu tragen sind. Die Kosten des Betriebs
grosser Webplattformen sind beträchtlich zu senken.
Das Unterhalten der Webserverinfrastruktur für Websites mit unregelmässig auftretendem, teils sehr
hohem Verkehrsaufkommen, ist beträchtlich. Sowohl mit betriebsinterner Infrastruktur als auch bei
Outsourcing zu einem Hoster ist in der Regel die potentielle Maximalkapazität bereitzustellen bzw. zu
bezahlen.
31.12.14, v1.0.44
- 26 -
Lösungsszenario
Azure stellt drei Szenarien für den Betrieb von Websites zur Verfügung, die obigen Zielsetzungen
genügen:

Szenario A
Azure Websites als Platform-as-a-Service (PaaS) Angebot bedingen den geringsten Aufwand für
Inbetriebnahme und Unterhalt und sind bezüglich Konfiguration und Ressourcenbereitstellung
höchst agil einsetzbar. Sie eignen sich v.a. für Windows-basierende Web Applikationen auf in
einem Applikationsframework oder CMS von Microsoft oder einem Drittanbieter (v.a. auch Open
Source).

Szenario B
Azure Cloud Services (Web und Worker Roles) stellen vorkonfigurierbare virtuelle Maschinen zur
Verfügung, die trotz des VM-Charakters nur minimale Verwaltungsaufgaben verlangen. Cloud
Services erlauben insbesondere den Betrieb von ASP.Net-Applikationen auf IIS und ermöglichen
es im Gegensatz zu Azure Websites, in die Serverkonfiguration einzugreifen.

Szenario C
Mit Azure Virtual Machines werden Webserverfarmen (Windows- oder Linux-basierend) mit
gleicher Architektur bereitgestellt und gepflegt, wie dies auch in einem Firmennetzwerk erfolgen
würde. Die Wartungsaufgaben sind somit die gleichen wie beim Betrieb eigener Server. Hingegen
erlaubt die Azure-Plattform das automatische hinzufügen oder entfernen von FarmMemberservern und ermöglicht so die Kostenoptimierung bei unregelmässiger Nutzlast. Überdies
bietet die Plattform- und Speicherarchitektur von Azure Hochverfügbarkeit und tiefe RTO zu sehr
günstigen Konditionen bei sehr hoher Qualität. VMs kommen vor allem dort zum Einsatz, wo
proprietäre CMS oder andere durch die Varianten a) und b) nicht unterstützte
Softwarekomponenten benötigt werden.
Jede der drei beschriebenen Subvarianten bietet grosse Flexibilität bei geringerem Wartungsaufwand
und tieferen Kosten als in lokalem/gehostetem Betrieb.
31.12.14, v1.0.44
- 27 -
Lösungsarchitektur



Szenario A
Azure Websites laufen grundsätzlich isoliert und sind nicht via eine Firmendomäne bzw. ein
Firmennetzwerk zugreifbar. Hingegen kann einer Azure Website Zugang zu einem Azure Virtual
Network und über dieses auch auf firmeninterne Ressourcen gewährt werden (bei Aufbau eines
Site-to-Site-VPN-Tunnels).
Szenario B
Azure Cloud Services (hier v.a. Web Roles) laufen wie Azure Websites isoliert, können aber auf
Ressourcen in Azure Virtual Networks und via diese auf interne Firmenressourcen zugreifen.
Szenario C
Azure VMs, auf welchen Webserver betrieben werden, laufen in der Regel in Azure Virtual
Networks und sind auch in Firmendomänen und -netzwerke integrierbar.



Szenario A: Azure Website
Szenario B: Azure Cloud Service (Web Role, Worker Role)
Szenario C: Azure Virtual Machine
Jede der drei Varianten verwendet zudem:


Azure Storage
Azure Virtual Network (Optional für a) und b))
Kosten
Vergleich der drei Subvarianten für eine Farm von vier Maschinen (2 Cores/3.5GB RAM, keine extensive
Disknutzung) mit 99.95% Verfügbarkeit bei 7x24x365-Betrieb:



Szenario A: CHF 6'444.-- p.a.
Szenario B: CHF 5'160.-- p.a.
Szenario C: CHF 4'776.-- p.a.
In jedem Szenario sinken die Kosten proportional zum applizierten Skalierungsfaktor (z.B. 50% der
Kosten während eines Abrechnungszyklus in welchem nur zwei Maschinen laufen).
Das Bereitstellen jeder der drei Plattformen ist grundsätzlich in einer Stunde möglich (exkl. Planung).
Der Hauptaufwand des Aufbaus und der Integration der Websites ist abhängig von der zu
realisierenden Implementierung.
Der Aufbau des optionalen S2S-VPN-Tunnels kann u.U. Rechercheaufwand generieren, ist aber
grundsätzlich schnell realisiert. Wenn kundenseitig ein Firewall-Produkt im Einsatz ist, das entweder von
Microsoft unterstützt ist oder für welches der Kunde oder der Partner das notwendige Know-how hat,
fallen hierfür keine nennenswerten Aufwendungen an. Es ist ein IPsec IKEv2-Tunnel einzurichten, der
die von Azure vorgegebenen Spezifikationen erfüllt. Azure VPN-Tunnels verwenden gängige StandardParameterwerte.
31.12.14, v1.0.44
- 28 -
Technik




Azure Website erzeugen mit gewünschtem CMS und benötigter Redundanz (Anzahl Instanzen).
Optional Azure Virtual Network einrichten, mit Dienst integrieren und S2S-VPN-Tunnel zur lokalen
Infrastruktur aufbauen.
CMS konfigurieren und nutzen.
Die ersten zwei Varianten können auf Ressourcen in Azure Virtual Networks und via diese auf
firmeninterne Ressourcen zugreifen, nicht aber umgekehrt.
Die dritte Variante ist via IP-Routing für Applikationen und Nutzer transparent in Firmennetzwerke
integrierbar.
31.12.14, v1.0.44
- 29 -
8: SAP auf Azure
Ziel, Kundennutzen
Eine SAP-Infrastruktur kann mittels virtueller Maschinen auf Azure
IaaS schnell, sicher, agil und sehr flexibel in Betrieb genommen
werden. SAP unterstützt diese Lösungsarchitektur und hilft seinen
so auch, Infrastruktur- und Wartungskosten zu senken.
Die Komponenten einer SAP-Infrastruktur sind komplex und umfangreich. Das Bereitstellen und
Unterhalten einer entsprechenden Serverumgebung ist mit beträchtlichem Aufwand verbunden.
Neben dem Produktivbetrieb stellen auch der Test von Upgrades eine Herausforderung dar: Im Idealfall
wird die bestehende SAP-Lösungsplattform in vollem Umfang repliziert, um alle Abhängigkeiten
validieren zu können. Dies bedingt das interne Erzeugen oder Kopieren virtueller Server mit
entsprechendem Bedarf an Speicherplatz und weiteren technischen Ressourcen. Da eine solche
Bereitstellung nur temporär benötigt wird, lässt sich eine entsprechende Investition nur eingeschränkt
amortisieren und ist somit sehr teuer.
31.12.14, v1.0.44
- 30 -
Lösungsszenario
Eine SAP-Produktions- oder Testinfrastruktur wird auf Azure IaaS mit Azure Virtual Machines
bereitgestellt. Diese Bereitstellung kann auch als Kopie bestehender produktiver Applikationen und
Daten erfolgen.




Die temporäre oder permanente Bereitstellung auf Azure bedingt keine Investition. Es sind keine
Komponenten zu beschaffen, die nach der Bereitstellung nicht mehr benötigt werden.
Die bereitgestellte Infrastruktur kann agil an veränderte Rahmenbedingungen angepasst werden,
indem im laufenden Betrieb Serverressourcen ausgeweitet oder reduziert werden. Die
Betriebskosten der Azure-Plattform fallen hierbei immer nur für die effektiv verwendeten
Ressourcen an.
Wird die SAP-Infrastruktur nicht 7x24 benötigt, lassen sich die laufenden Kosten weiter reduzieren,
indem Serverressourcen ausserhalb der Produktionszeiten automatisch reduziert oder
ausgeschaltet werden.
Anders als derzeit noch bei vielen anderen ERP-Lösungen unterstützt SAP den Betrieb ihrer
Applikationen auf Azure offiziell.
Lösungsarchitektur
Folgende Lösungen sind von SAP für Azure zertifiziert:




SAP Business Suite (SQL Server/Oracle/SAP ASE auf Windows Server)
SAP Business All-in-One (SQL Server/Oracle/ SAP ASE auf Windows Server)
SAP NetWeaver Application Server ABAP (SQL Server/Oracle/ SAP ASE auf Windows Server)
SAP HANA Developer Edition (SUSE Linux)
Als Client-Plattform können sowohl via VPN angebundene Workstations ausserhalb von Azure als auch
Sessions auf RDS-Hosts, die auf Azure VMs laufen, zum Einsatz kommen. RDS auf Azure ist nur für
Shared Desktop unterstützt und via SPLA zu lizenzieren (RDS SAL, weitere Applikationen).



Azure Storage
Azure Virtual Network (mit oder ohne S2S-Anbindung)
Azure Virtual Machine
Kosten
Es bietet sich eine Vielzahl an technischen Lösungsarchitekturen mit entsprechend unterschiedlichen
Kosten an.
Die Minimalkonfiguration, eine A5-Maschine (zwei Prozessorkerne, 14 GB RAM) erzeugt Betriebskosten
von CHF 202.-- pro Monat, zzgl. Speicherplatzbedarf.
31.12.14, v1.0.44
- 31 -
Alle grösseren Maschinentypen (A5-A9, D11-D14) sind ebenfalls unterstützt. Für SAP HANA Developer
Edition ist A7 oder A8 verlangt.
Die Gesamtkosten einer vollständigen SAP-Infrastruktur auf Azure sind abhängig von der zu
implementierenden Lösung und Architektur.
Folgende Kostenfaktoren sind seitens Azure in die Kalkulation mit einzubeziehen:






Azure Storage (auch für die jeweiligen 127GB OS-Disk pro VM)
Azure Virtual Network Gateway (nur wenn S2S-VPN-Tunnel genutzt wird, CHF 313.-- p.a.)
Azure Virtual Machines
Downstream Bandbreitennutzung über 5GB p.m.
SAP-Lizenzen (nicht im Maschinenpreis enthalten)
Allfällige Client-Lizenzen auf RDS-Hosts in Azure (via SPLA zu beschaffen)
Das Erzeugen der Azure-Infrastruktur ist - exkl. Planung - in zwei Stunden realisierbar. Der
Hauptaufwand entsteht durch den Aufbau und die Konfiguration der SAP-Dienste.
Technik



Azure Virtual Network anlegen, optional S2S-VPN-Tunnel einrichten.
Azure Virtual Machines als SAP-Hosts anlegen.
Firmenstandort). Alle Integrationsmöglichkeiten des oder der SAP-Hosts sind so nutzbar wie wenn
diese im lokalen Netzwerk betrieben würden.


MSDN - Using SAP on Azure VMs: https://msdn.microsoft.com/en-us/library/azure/dn745892.aspx
SAP Notes zu Azure: http://blogs.msdn.com/b/saponsqlserver/archive/2014/05/28/sap-notesaround-azure-released.aspx
31.12.14, v1.0.44
- 32 -
9: Oracle Dev & Test
Ziel, Kundennutzen
Für Versionsupgrades und Test neuer Konfigurationen und
Lösungen ist eine temporäre Oracle-Infrastruktur schnell und zu
geringen Kosten temporär bereitzustellen. Die bestehende interne
IT-Infrastruktur soll hiervon nicht tangiert werden.
In umfangreichen Lösungen sind Oracle-Infrastrukturen typischerweise komplex und umfangreich. Für
Tests vor Versionswechseln ist das Bereitstellen einer solchen Infrastruktur mit beträchtlichem Aufwand
verbunden, wenn nicht die produktive Plattform tangiert werden soll.
Im Idealfall wird die bestehende Lösungsplattform in vollem Umfang repliziert, um alle Abhängigkeiten
validieren zu können. Dies bedingt das interne Erzeugen oder Kopieren virtueller Server mit
entsprechendem Bedarf an Speicherplatz und weiteren technischen Ressourcen. Da eine solche
Bereitstellung nur temporär benötigt wird, lässt sich eine entsprechende Investition nur eingeschränkt
amortisieren und ist somit sehr teuer.
31.12.14, v1.0.44
- 33 -
Lösungsszenario
Eine Oracle-Testinfrastruktur wird auf Azure IaaS mit Azure Virtual Machines bereitgestellt. Diese
Bereitstellung kann auch als Kopie der produktiven Applikationen und Daten erfolgen. Neben
Serverkomponenten lassen sich auch virtuelle Clients und weitere Dienste einbinden, um eine
realitätsnahe Umgebung bereitzustellen.





Dem komplexen Lizenzmodell für Oracle muss auf Azure keine Rechnung getragen werden: Die
Oracle-Lizenzkosten sind im Azure-Mietpreis der jeweiligen Maschinentypen für Oracle enthalten.
Durch das Pay-per-Use-Modell (eine ausgeschaltete oder aufgehobene Maschine erzeugt weder
Miet- noch Lizenzkosten) bietet sich Azure insbesondere auch für fluktuierenden und temporären
Oracle-Bedarf an. Es müssen keine dedizierten Oracle-Lizenzverträge abgeschlossen werden.
Die temporäre oder permanente Bereitstellung auf Azure bedingt keine Investition. Es sind keine
Komponenten zu beschaffen, die nach der Bereitstellung nicht mehr benötigt werden.
Die bereitgestellte Infrastruktur kann agil an veränderte Rahmenbedingungen angepasst werden,
indem im laufenden Betrieb Serverressourcen ausgeweitet oder reduziert werden. Die
Betriebskosten der Azure-Plattform fallen hierbei immer nur für die effektiv verwendeten
Ressourcen an.
Wird die Oracle-Infrastruktur nicht 7x24 benötigt, lassen sich die laufenden Kosten weiter
reduzieren, indem Serverressourcen ausserhalb der Produktionszeiten automatisch reduziert oder
ausgeschaltet werden.
Oracle unterstützt den Betrieb ihrer Lösungen auf Azure offiziell.
Lösungsarchitektur
Als Client-Plattform können sowohl via VPN angebundene Workstations ausserhalb von Azure als auch
Sessions auf RDS-Hosts, die auf Azure VMs laufen, zum Einsatz kommen. RDS auf Azure ist nur für
Shared Desktop unterstützt und via SPLA zu lizenzieren (RDS SAL, weitere Applikationen).



Azure Storage
Azure Virtual Network (mit oder ohne S2S-Anbindung)
31.12.14, v1.0.44
- 34 -
Kosten
Für Oracle werden Maschinen ab A2 (zwei Prozessorkerne, 3.5GB RAM) vorausgesetzt. Dieser
Maschinentyp kostet ab CHF 100.-- p.m.
Die Gesamtkosten einer vollständigen Oracle-Infrastruktur auf Azure sind abhängig von der zu
implementierenden Lösung und Architektur.






SAP-Lizenzen (nicht im Maschinenpreis enthalten)
Das Erzeugen der Azure-Infrastruktur ist - exkl. Planung - in ein, zwei Stunden realisierbar. Der
Hauptaufwand entsteht durch den Aufbau und die Konfiguration der Oracle-Dienste.
Technik



Azure Virtual Network anlegen, optional S2S-VPN-Tunnel aufbauen.
Azure Virtual Machines als Oracle-Hosts anlegen.
Firmenstandort). Alle Integrationsmöglichkeiten des oder der Oracle-Hosts sind so nutzbar wie wenn
diese im lokalen Netzwerk betrieben würden.

http://azure.microsoft.com/de-de/campaigns/oracle/
31.12.14, v1.0.44
- 35 -
10: ADFS auf Azure
IaaS für On-Prem ADForests
Ziel, Kundennutzen
Eine Single-SignOn-Implementierung für Office 365 (oder einen
anderen SaaS-Dienst) soll ohne zusätzliche Hardware oder neue
virtuelle Server, die on-premises zu betreiben sind realisiert werden.
Eine Office 365-Implementierung ist bisher ohne oder nur auf Replikationsbasis (DirSync/AAD Sync) mit
der internen Active Directory-Infrastruktur des Kunden verbunden. Es wird eine stärkere Integration mit
echtem Single-SignOn angestrebt. Z.B. um auch Applikationen die automatische Validierung gegen die
Office 365-Dienste zu ermöglichen, ohne dass eine Benutzerinteraktion notwendig wird (erneute
Eingabe von Anmeldedaten).
31.12.14, v1.0.44
- 36 -
Lösungsszenario
Die ADFS-Komponenten - vier virtuelle Serversysteme - werden als Azure VMs in einem Azure Virtual
Network aufgebaut. Das VNet wird mittels Site-to-Site-VPN-Tunnel an die bestehende interne
Infrastruktur des Kunden angebunden. Die Hochverfügbarkeit der ADFS-Infrastruktur wird durch das
99.95%-SLA von Azure gewährleistet.



Die missionskritische Komponente ADFS einer Single-SignOn-Infrastruktur kann kostengünstig und
hochverfügbar, bei minimalem Konfigurationsaufwand, auf Azure realisiert und betrieben werden.
Der Kunde erhält transparenten Zugang zu Office 365 und weiteren Diensten via Single-SignOn,
gesteuert durch die bestehende interne Infrastruktur. Dies ohne den Preis neuer interner Server.
Für die auf Azure zu betreibenden VMs und Dienste sind keine neuen Lizenzen zu beschaffen, die
Lizenzkosten sind in den Azure-Mietkosten enthalten.
Lösungsarchitektur
Auf Azure werden je zwei ADFS Federation Server und zwei ADFS Proxies (Web Application Proxy auf
Windows Server 2012 R2) betrieben und in die bestehende interne Active Directory-Domäne integriert.



Azure Storage
Azure Virtual Network mit S2S-VPN-Anbindung
31.12.14, v1.0.44
- 37 -
Kosten
Die zwei benötigten Dienste (ADFS Federation Server, ADFS/WAP Proxy Server) werden je doppelt
implementiert, um das Azure-SLA von 99.95% zu erreichen:




CHF
6'240.-- p.a.
292.-- p.a.
313.-- p.a.
70.-- p.a.
Total ca.
6'915.-- p.a.
CHF
Die Implementierung der obigen Infrastruktur ist in einem halben bis ganzen Arbeitstag realisierbar
(exkl. Planung).
Technik





Azure Virtual Network anlegen und S2S-VPN-Tunnel aufbauen.
Azure Virtual Machines anlegen, als Availability Sets konfigurieren und in die lokale Domäne
einbinden.
ADFS-Dienste konfigurieren.
Öffentliche Endpunkte (SSL) freigeben.
Die Verbindung zur ADFS-Infrastruktur auf Azure findet für die bestehenden internen Serverdienste
und Clients transparent via IP-Routing (über den Site-to-Site-VPN-Tunnel) statt. Alle
Integrationsmöglichkeiten von Windows-Servern sind identisch dazu nutzbar wie wenn diese im lokalen
Netzwerk betrieben würden.

Technet: https://technet.microsoft.com/library/dn509539.aspx
31.12.14, v1.0.44
- 38 -
11: DirSync/AAD Sync
auf Azure IaaS für OnPrem Forests
Ziel, Kundennutzen
Für die Nutzung von Office 365 und anderen SaaS-Diensten sollen
die Anmeldedaten und Berechtigungsgruppen bestehender Active
Directory-Forests verwendet werden, indem diese aus Azure Active
Directory (für Office 365) repliziert werden. Dies ist ohne intern zu
installierende Dienste oder neue Maschinen zu realisieren.
Die Verbindung bestehender Identifikations- und Autorisierungslösungen in Active Directory mit Office
365 findet in der Regel unter Verwendung eines Synchronisationsdienstes wie FIM, DirSync, AAD Sync
oder AAD Connect statt.
Je nach Grösse eines Unternehmens und Häufigkeit von Passwortänderungen und Kontosperrungen
sind auch diese Dienste als missionskritisch zu bezeichnen und entsprechend hochverfügbar
auszulegen.
Diese Dienste sind allerdings nicht in einer Farmkonfiguration betreibbar, weshalb deren Einrichtung in
einer internen physischen Infrastruktur teure Hochverfügbarkeitskonzepte verlangt (z.B. auf
Virtualisierungsebene, durch georeplizierte Speichermedien o.ä.).
31.12.14, v1.0.44
- 39 -
Lösungsszenario
Der Betrieb eines Synchronisationsdienstes wie AAD Sync auf einer Azure VM erlaubt die Nutzung der
hohen Qualität und Verfügbarkeit von Microsoft Azure. Speichermedien können implizit georedundant
genutzt werden, Unterhalt und Verfügbarkeit auch von Einzelmaschinen (ohne Availability Sets) sind
von hoher Qualität.



Betriebsaufwand und -kosten einer Synchronisationslösung sind auf Azure tiefer als on-premises.
Die Verfügbarkeit ist bei geringen Kosten besser.
Die Wiederherstellung findet im Katastrophenfall sehr schnell und ohne eigene Investition statt.
Lösungsarchitektur
Für diese Lösung wird in einem via S2S-VPN-Tunnel angebundenen Azure Virtual Network ein
Member-Server der internen AD-Domäne betrieben. Auf diesem wird die FIM/DirSync/AAD Sync/AAD
Connect-Lösung installiert. Sie kommuniziert einerseits mit einem internen AD-Controller, andererseits
mit dem AAD-Zielforest (i.d.R. unter Office 365).



Azure Storage
Azure Virtual Network mit S2S-VPN-Anbindung
31.12.14, v1.0.44
- 40 -
Kosten




CHF
6'240.-- p.a.
292.-- p.a.
313.-- p.a.
70.-- p.a.
Total ca.
6'915.-- p.a.
CHF
Dieses Szenario lässt sich in ca. zwei Stunden realisieren (exkl. Planung).
Technik




Azure Virtual Network anlegen und S2S-VPN-Tunnel aufbauen.
Azure Virtual Machine anlegen und in die lokale Domäne einbinden.
AAD Sync installieren und konfigurieren (bzw. DirSync oder AAD Connect).
Die Verbindung zum virtuellen Server auf Azure findet für die bestehenden Dienste und Server der
Firma transparent via IP-Routing statt (über den Site-to-Site-VPN-Tunnel ab einem Firmenstandort).
Alle Integrationsmöglichkeiten des Servers sind so nutzbar wie wenn dieser im lokalen Netzwerk
betrieben würde.
31.12.14, v1.0.44
- 41 -
12: BI und Reporting
für mobile Anwender
sowie als ISV-SaasAngebot (SQL Server
Reporting Services in
Azure IaaS)
Ziel, Kundennutzen
Eine auch ausserhalb des Intranets verfügbare Reporting-Lösung ist
in einer hochverfügbaren Infrastruktur bereitzustellen. Dies bei nur
minimaler lokaler Infrastruktur und mit geringem Wartungsaufwand.
SQL Server Reporting Services bieten alle Vorzüge von Reporting-Lösungen, die sich direkt interaktiv
via Webbrowser oder als Komponente einer vertikalen Softwarelösung nutzen lassen. Die Plattform
verlangt allerdings, wenn sie hochverfügbar und via öffentliches Internet zur Verfügung zu stellen ist,
eine komplexe Serverinfrastruktur mit beträchtlichem Wartungsaufwand.
Eine weitere Herausforderung bzw. Chance stellt die Plattform für ISVs dar, die Reporting in ihren
Standardlösungen als Software-as-a-Service-Angebot integrieren wollen.
Lösungsszenario
SQL Server Reporting Services lassen sich in Azure Virtual Machines betreiben.
Die Publikation der für Anwender zugänglichen Dialoge und Dienste kann hierbei via öffentliches
Internet (SSL-geschützte Kommunikation über einen Endpunkt der Azure VMs) oder via VPN (Point-toSite-VPN-Verbindung in ein Azure VNet ab mobilen Windows Clients) erfolgen.
31.12.14, v1.0.44
- 42 -




Diese Lösung bringt hohe Verfügbarkeit und Flexibilität bei relativ geringem zusätzlichem
Wartungsaufwand.
Es entfällt die Notwendigkeit, eigene Server in einer internen Infrastruktur mit einer verteilten
Farmkonfiguration zu betreiben.
Es ist nicht in eine SQL Server-Lizenzbeschaffung zu investieren. Die SQL Server-Images auf Azure
enthalten die SQL Server-Lizenzen in ihren Mietkosten. Es werden nur die effektiv genutzten
Dienste abgerechnet, d.h. bei fluktuierender Nutzerzahl ist keine Über- oder Unterlizenzierung in
Kauf zu nehmen.
Bei Nutzung der BI/Reporting-Plattform nur zu bestimmten Tageszeiten oder nur an bestimmten
Wochentagen lassen sich die Kosten durch automatisches Herunterfahren der VMs weiter
optimieren.
Lösungsarchitektur
Für die Platzierung der Serverdienste stehen zwei Varianten im Vordergrund:

Betrieb sowohl von SSRS als auch der Datenbankdienste in Azure:

Betrieb nur von SSRS in Azure, Verbleib der auszuwertenden Datenquellen im Intranet:
Auch für die Client-Integration bieten sich mehrere Varianten an:


Client-Zugang via öffentlichen SSL-Port der Azure VMs (Reporting Server von SSRS)
Client-Zugang via VPN-Tunnel in das Azure Virtual Network



Azure Storage
Azure Virtual Network, je nach Szenario mit S2S-VPN-Anbindung
Azure Virtual Machines (SQL Server-Image inkl. SQL Server-Lizenzierung)
31.12.14, v1.0.44
- 43 -
Kosten
Für SQL Server Reporting Services wird der Maschinentyp A4 empfohlen (acht Prozessorkerne, 14 GB
RAM).
Ein Szenario mit zwei solchen Maschinen (Availability Set mit 99.95% Verfügbarkeit) bei Datenhaltung
on-premises (Verbindung via S2S-VPN-Tunnel) ergibt sich folgendes Kostenschema:




2 Azure VM (SQL Standard in Standard-VM A4)
CHF
Total ca.
CHF
24'511.-- p.a.
146.-- p.a.
313.-- p.a.
70.-- p.a.
25'040.-- p.a.
Dieses Kostenmodell geht davon aus, dass für SSRS keine weiteren Datendisks verwendet werden.
Dieses Szenario lässt sich in zwei Stunden realisieren (exkl. Planung und SSRS-Konfiguration).
Technik




Azure Virtual Network anlegen, optional S2S-VPN-Tunnel aufbauen.
Azure Virtual Machine (SQL Server Template) anlegen, optional in die lokale Domäne einbinden,
als Availability Set konfigurieren.
SSRS einrichten.
Die Verbindung zu den virtuellen Servern auf Azure findet für die bestehenden Dienste und
Applikationen der Firma bei Vorhandensein des Site-to-Site-VPN-Tunnels transparent via IP-Routing
statt. Alle Integrationsmöglichkeiten des Servers sind so nutzbar wie wenn diese im lokalen Netzwerk
betrieben würden.

MSDN: https://msdn.microsoft.com/en-us/library/azure/jj823132.aspx
31.12.14, v1.0.44
- 44 -
13: Globaler WAN/LAN
-Interconnect via
Azure Virtual
Networks
Ziel, Kundennutzen
Für die Verbindung global verteilter physischer Firmenstandorte ist
eine Verbindungsinfrastruktur im Sinne einer Backbone-Infrastruktur
zu schaffen. Routing, Filtering usw. soll auf diesem Backbone
unabhängig von den einzelnen Standort-Endpunkten verwaltet
werden können. Die globalen Verbindungen sollen potentiell auch
die Verbindungsgeschwindigkeit verbessern.
Global verteilte Standorte sind mit einem Netzwerk direkter VPN-Tunnels zwischen jeweils zwei
Standorten untereinander verbunden. Bei einer grossen Anzahl zu verbindender Punkte kann dies
komplex zu administrieren sein.
Vorzuziehen ist eine Verbindungsinfrastruktur, die an jedem physischen Standort nur eine - lokal
administrierbare - VPN-Verbindung auf ein Backbone-Trassee verlangt. Die Verwaltung der
Verbindungspfade unter den Standorten, des zugelassenen Netzwerkverkehrs usw. lässt sich so
organisatorisch und technisch isolieren.
Lösungsszenario
Jeder physische Standort wird mit einem Azure Virtual Network in einem geografisch nahegelegenen
Azure-Data Center durch einen Site-to-Site-VPN-Tunnel verbunden. Die regionalen Azure Virtual
Networks werden global untereinander verbunden. Routen und Filter zwischen den VNets werden
dazu verwenden, den Datenverkehr zwischen den angebundenen Standorten losgelöst von den
individuellen VPN-Endpunkte zu verwalten und zu steuern.
31.12.14, v1.0.44
- 45 -



Jeder physische Standort hat nur eine VPN-Verbindung global einheitlicher Konfiguration zu
verwalten.
Die Interkonnektion zwischen den Standorten ist unabhängig von den lokalen VPN-Endpunkten
steuerbar (z.B. durch die globale IT-Organisation anstatt durch das jeweils regionale IT-Team).
Interregionaler und interkontinentaler Datenverkehr läuft auf der Microsoft-internen
Netzwerkinfrastruktur zwischen den Azure-Data Centers mit hoher Geschwindigkeit und niedriger
Netzwerk-Latenz.
Lösungsarchitektur
Ein Azure Virtual Network lässt sich in seiner Standardversion mit bis zu zehn VPN-Endpunkten (Siteto-Site-VPN-Tunnel) verbinden. Neben physischen Standorten können auch andere Azure Virtual
Networks angebunden werden.

31.12.14, v1.0.44
- 46 -
Kosten
Pro Azure Virtual Network kann ein Gateway erzeugt werden, dessen Betriebsstunden in Rechnung
gestellt werden.
Bei 7x24x365-Betrieb kostet ein Standard-Gateway (Endpunkt von bis zu zehn VPN-Tunnels, 80Mbps
Durchsatz) ca. CHF 300.-- p.a. High Performance Gateways mit bis zu 30 VPN-Tunnels und 200 Mbps
werden zu CHF 3'960.-- p.a. berechnet.
Nur ausgehender Datenverkehr aus einem VNet erzeugt Bandbreitenkosten. Verkehr zwischen VNets
in verschiedenen Data Centers ist rabattiert und kostet für die Data Centers in den USA und in Europa
CHF 0.0317 pro GB (Asien: CHF 0.0813/GB, Südamerika: 0.1445/GB).
Ein Azure Virtual Network ist (exkl. Planungsaufwand) in einer Stunde eingerichtet. Mittels Import
vorbereiteter Konfigurationsdateien kann der Aufwand weiter reduziert werden.
Der Aufbau eines S2S-VPN-Tunnels an einen physischen Endpunkt kann u.U. Rechercheaufwand
generieren, ist aber grundsätzlich schnell realisiert. Wenn kundenseitig ein Firewall-Produkt im Einsatz
ist, das entweder von Microsoft unterstützt ist oder für welches der Kunde oder der Partner das
notwendige Know-how hat, fallen hierfür keine nennenswerten Aufwendungen an. Es ist ein IPsec
IKEv2-Tunnel mit dynamischem Routing einzurichten, der die von Azure vorgegebenen Spezifikationen
erfüllt. Azure VPN-Tunnels verwenden gängige Standard-Parameterwerte.
Technik




Azure Virtual Network erzeugen (ggf. pro Region eines)
Gateway in jedem VNet erzeugen (liefert die öffentliche IP-Adresse des VNets)
Site-to-Site-VPN-Tunnels zwischen Standorten und zwischen VNets einrichten.
Routen und Filter konfigurieren pro Subnet der VNets.
Die Verbindungen über die Azure-VNet-Infrastruktur werden mittels herkömmlichem IP-Routing
gesteuert und sind für die bestehenden Server, Clients und Dienste an den physischen Standorten
transparent. Sie erlauben jede auch in physischen Netzwerken mögliche Integration von Diensten.
31.12.14, v1.0.44
- 47 -
14: Migration von
Hyper-V und VMware
VMs in Azure Virtual
Machines
Ziel, Kundennutzen
Virtuelle Maschinen, die an einem Firmenstandort unter Hyper-V
oder VMware betrieben werden, sind aus Kapazitätsgründen oder
zur Verbesserung ihrer Verfügbarkeit und Systemleistung auf eine
alternative Plattform auszulagern. Die Maschinenkonfiguration soll
unverändert erhalten bleiben und es soll kein Neuaufbau der
Maschinen notwendig werden.
Virtuelle Maschinen, die auf physischen Hyper-V- oder VMware-Hosts laufen, sind den verfügbaren
physischen Ressourcen unterworfen. Bei knappem Speicherplatz, zu wenigen Prozessorkernen oder
dergleichen bedingt der Ausbau der Virtualisierungs-Infrastruktur Investitionen und komplexen
Konfigurationsaufwand.
31.12.14, v1.0.44
- 48 -
Lösungsszenario
Bestehende virtuelle Maschinen auf Hyper-V und VMware können mittels Transfer ihrer virtuellen Disks
nach Azure verschoben werden. Im Fall von VMware werden die entsprechenden Disks mittels
Microsoft Virtual Machine Converter in das vhd-Format konvertiert.



Azure bietet eine besser skalierbare und mit weniger Wartungsaufwand betreibbare Plattform für
virtuelle Maschinen.
Durch den Transfer von Diskdateien bleiben die Maschinenkonfigurationen erhalten.
Auch Netzwerkanbindungen der transferierten virtuellen Maschinen können ohne substantielle
Neukonfiguration weiterhin genutzt werden, indem diese in Azure Virtual Networks identischer IPRanges integriert werden.
Lösungsarchitektur
Nach dem Transfer der virtuellen Disk werden die virtuellen Maschinen auf deren Basis als Azure VMs
erzeugt und direkt in eine Azure VNet eingebunden.



Azure Storage
31.12.14, v1.0.44
- 49 -
Kosten
Die Betriebskosten auf Azure richten sich nach Anzahl, Grösse und Betriebsstunden der transferierten
VMs.





Technik





Disks bestehender VMs kopieren (verlangt i.d.R. Downtime).
Disks ggf. in das vhd-Format konvertieren (Microsoft Virtual Machine Converter).
Disks nach Azure hochladen.
Azure Virtual Network passender Spezifikation erzeugen und per Site-to-Site-VPN-Tunnel mit
dem lokalen physischen Netzwerk verbinden.
Aus den hochgeladenen Disks neue Azure Virtual Machines erzeugen und in das VNet einbinden.
Die Verbindung zu den virtuellen Servern auf Azure findet für die bestehenden Dienste und
Applikationen der Firma bei Vorhandensein des Site-to-Site-VPN-Tunnels transparent via IP-Routing
statt. Alle Integrationsmöglichkeiten des Servers sind so nutzbar wie wenn diese im lokalen Netzwerk
betrieben würden.

Microsoft Virtual Machine Converter:
http://www.microsoft.com/en-us/download/details.aspx?id=42497
31.12.14, v1.0.44
- 50 -
15: Schnelles
Wiederherstellen
virtueller Server
(Azure Site Recovery)
Ziel, Kundennutzen
Virtuelle Server die auf Hyper-V oder VMware betrieben werden,
sind im Katastrophenfall (Disaster Recovery) wiederherzustellen.
Hierzu sollen sie im produktiv Betrieb laufend repliziert werden,
damit Sie bei Ausfall der lokalen VM zeitnah wieder in Betrieb
genommen werden können, ohne eine Datensicherung
wiederherstellen zu müssen.
Wenn eine lokal betriebener virtueller Server oder gar dessen Host ausfällt, ist die Wiederherstellung
aus einer Datensicherung oft ein langwieriger Prozess, der einen zu langen Betriebsunterbruch zur
Folge hat.
31.12.14, v1.0.44
- 51 -
Lösungsszenario
Mittels Azure Site Recovery lassen sich lokal betriebene virtuelle Server in eine auf Azure laufende
Kopie replizieren. Das Replikationsintervall kann hierbei 30 Sekunden bis 15 Minuten betragen, d.h. die
Kopie des produktiv laufenden internen Servers wird in diesem Zeitintervall aktualisiert. Zusätzlich zu
diesem Replikationsintervall können Recovery Points während mehreren Stunden gespeichert werden.
Virtuelle Server können sowohl unter Verwendung von Virtual Machine Manager als auch direkt aus
Hyper-V und VMware geschützt werden mit den entsprechenden, durch Azure zur Verfügung
gestellten und lokal zu installierenden Agents.




Kurzzyklische Replikation virtueller Server nach Azure, dadurch jederzeitige Wiederherstellbarkeit
des aktuellen VM-Zustands bei Ausfall des lokalen Servers.
Hohe Verfügbarkeit (99.9%) der Recovery-Infrastruktur auf Azure.
Integration replizierter VMs auf Azure in Azure Virtual Networks, die via Site-to-Site-VPN-Tunnel
mit dem lokalen Netzwerk verbindbar sind. Dadurch können die auf Azure wiederhergestellten
Maschinen aus dem Intranet unmittelbar und für Applikationen und Anwender transparent
weiterverwendet werden.
Einfacher Failover-Prozess via Azure-Portal (One-Click-Failover).
Lösungsarchitektur
Nach einer initialen Replikation einer virtuellen Maschine wird die Differenz der virtuellen Disks
kurzzyklisch nachrepliziert. Lokal ist SCVMM eine Option, aber nicht notwendig.




Azure Storage
Azure Recovery Services (Site Recovery Vault)
31.12.14, v1.0.44
- 52 -
Kosten
Die Betriebskosten auf Azure richten sich nach Anzahl, Grösse und Betriebsstunden der transferierten
VMs.



Azure Storage für die durch Azure Site Recovery geschützten virtuellen Disks
Azure Site Recovery (CHF 49.-- pro geschützte Maschine und Monat)
Technik






Azure Storage Account erzeugen.
Azure Site Recovery Vault erzeugen.
VMM/Hyper-V/VMware-Agent zusammen mit Verbindungs-Konfigurationsdatei (Schlüssel)
herunterladen und auf dem Virtualisierungshost installieren.
Lokalen Host in Azure Site Recovery registrieren.
In Azure Site Recovery eine Protection Group unter Angabe von Storage Account und zu
verwendendem VNet anlegen.
Zu schützende Maschinen auswählen und Job starten.
Wird ein Failover durchgeführt, geht die replizierte Maschine auf Azure mit dem Namen der zuvor lokal
betriebenen Maschine online und wird via VNet und S2S-VPN-Tunnel im DNS der bestehenden ADDomäne neu registriert. Dadurch verläuft der Failover für die Nutzer weitestgehend transparent und
bedingt keine weitere Konfigurationsänderung.
Die Verbindung zu den virtuellen Servern auf Azure nach einem Failover findet für die bestehenden
Dienste und Applikationen der Firma bei Vorhandensein des Site-to-Site-VPN-Tunnels transparent via
IP-Routing statt. Alle Integrationsmöglichkeiten des Servers sind so nutzbar wie wenn diese im lokalen
Netzwerk betrieben würden.

Technet Walkthrough (Variante mit SCCM):
http://blogs.technet.com/b/systemcenter/archive/2014/07/01/microsoft-azure-site-recovery-yourdr-site-in-microsoft-azure.aspx
31.12.14, v1.0.44
- 53 -
16: Offline Files via
Windows Server File
Sharing auf Azure IaaS
Ziel, Kundennutzen
Dateien aus Windows-Fileshares sollen auch offline auf WindowsClients genutzt werden können. Dies ist ohne interne physische
Serverinfrastruktur zu realisieren, jedoch volle Active DirectorySteuerung (Group Policies usw.) unterstützen und somit keine SaaSDienste (OneDrive for Business o.ä.) in Anspruch nehmen.
Ein Unternehmen will keine eigene Server-Infrastruktur physisch betreiben, aber trotzdem mobil mit
gemeinsam bearbeiteten Dokumenten arbeiten können. OneDrive for Business kommt aus spezifischen
Gründen nicht in Frage, z.B. weil die volle Funktionalität von Active Directory, NTFS oder ReFS,
Deduplikation, Ordnersynchronisation o.ä. zur Pflege der Dateiablage benötigt wird. Windows Offline
Files sind deshalb das bevorzugte Konzept.
31.12.14, v1.0.44
- 54 -
Lösungsszenario
Windows File Services werden mittels Azure Virtual Machines bereitgestellt. Die Windows-Clients
können sich mit Point-to-Site-VPN-Tunnels direkt mit der Azure-seitigen Netzwerkinfrastruktur
verbinden und in dieser mit Windows Offline Files arbeiten.



Keine eigene physische Serverinfrastruktur notwendig.
Mobile Offline-Nutzung von Dateien auf Windows Clients ohne Inanspruchnahme eines SaaSAngebots das nicht die gewünschte Filesharing-Funktionalität aufweist.
Wartungsarme, hochverfügbare und bei oszillierendem Bedarf automatisch skalierende
Betriebsplattform.
Lösungsarchitektur
Für die Anbindung der Windows-Clients wird ein durch Azure bereitgestellter individueller Point-toSite-VPN-Tunnel aufgebaut.



Azure Storage
31.12.14, v1.0.44
- 55 -
Kosten





2 Azure VM (1xA1 Basic, 1xA2 Basic)
CHF
1'790.-- p.a.
146.-- p.a.
1'022.-- p.a.
313.-- p.a.
70.-- p.a.
Total ca.
3'341.-- p.a.
CHF
Diese Konfiguration verzichtet auf das 99.95% SLA für die VMs, indem jeder Dienst nur mit einer
Instanz betrieben wird. Die Datenspeicherung findet trotzdem sechsfach redundant und mit 99.9% SLA
statt.
Die obige Konfiguration lässt sich (exkl. Planung in zwei bis vier Arbeitsstunden realisieren.
Es wird kein Site-to-Site-VPN-Tunnel aufgebaut. Für die Point-to-Site-VPN-Tunnels der WindowsClients stellt das Azure-Portal eine Installationsdatei zur Verfügung.
Technik






Azure Storage Account für die vhds der VMs anlegen und gewünschte Redundanz/Kosten
einstellen.
Ein Azure Virtual Network anlegen (mit Option Point-to-Site-VPN).
Gateway im Azure VNet erzeugen und Point-to-Site-Konfiguration vornehmen (Zertifikat).
Neue Azure VMs im Azure VNet erzeugen.
Domäne und File Services konfigurieren.
VPN-Clients auf den Windows-Maschinen installieren.
Die Windows-Clients können die im Azure VNet angebotenen Dienste so nutzen, wie in einem
physischen lokalen Netzwerk bzw. wie in einer herkömmlichen VPN-Infrastruktur. Für die auf den
Clients betriebenen Applikationen ist die Azure-Infrastruktur transparent.
31.12.14, v1.0.44
- 56 -
Microsoft Azure Lösungsszenario:
17: Publizieren interner
Webapplikationen für
externe Nutzer (AAD
Application Proxy)
Ziel, Kundennutzen
Browserbasierte Anwendung, die im Intranet und mit interner
Datenhaltung zu betreiben sind (IIS-Anwendungen, SharePointSites, OWA lokaler Exchange Organisationen, usw.) sind externen
Benutzern auf sicherem Weg zur Verfügung zu stellen. Hierfür
sollen sie keinen direkten internen Netzwerkzugang benötigen und
ist auf eine komplexe Proxy-Infrastruktur zu verzichten.
Das Publizieren interner Applikationen an externe Benutzer verlangt in der Regel komplexe ProxyKonfigurationen in der DMZ sowie faktisch direkten Zugang zum Intranet auch für externe Benutzer.
Dieser Zugang ist sowohl für Identifikation und Autorisierung (Active Directory) als auch für die
Nutzung der Webapplikation notwendig.
31.12.14, v1.0.44
- 57 -
Lösungsszenario
Mit dem Azure Active Directory-Application Proxy können interne Web-Applikationen kontrolliert und
geschützt an externe Benutzer publiziert werden, ohne Proxydienste in der DMZ einrichten zu müssen
und ohne den externen Benutzern Zugang zum Intranet zu gewähren.
Der AAD Application Proxy stützt sich auf den AAD Proxy Connector, der auf dem internen
Applikationshost installiert wird und die gewünschte Applikation publiziert. Die Zugangskontrolle zur
Applikation findet nicht via das interne Active Directory sondern aus Azure Active Directory heraus statt.
Dieses ist ausserhalb des Firmennetzwerks verfügbar. Es wird aus dem internen Active Directory mittels
Replikation (AAD Sync, AAD Connect) alimentiert.
Alle im Internet genutzten Dienste (Applikation, AAD Identifikation und Autorisierung) werden via PushVerfahren zur Verfügung gestellt, weshalb kein Zugang ins Intranet gewährt werden muss für externe
Benutzer.


Publizieren interner Webapplikationen ohne Öffnen von Firewallports.
Kein Zugang zum Intranet für externe Benutzer notwendig.
Lösungsarchitektur

Azure Active Directory Premium mit AAD Application Proxy
31.12.14, v1.0.44
- 58 -
Kosten
Um den AAD Application Proxy nutzen zu können, wird eine Azure Active Directory Premium-Lizenz
benötigt. Diese kostet pro externen Benutzer CHF 67.-- p.a.
Für das Nutzen von AAD Application Proxy ist zunächst eine Azure Active Directory-Infrastruktur zu
alimentieren. Hierfür wird typischerweise die Synchronisation mit AAD Sync oder AAD Connect aus
dem internen Active Directory aufgebaut. Anschliessend können interne Applikationen nach AAD
publiziert und dort mit Berechtigungen verwaltet werden.
Exkl. Planung kann dieser Prozess in einem halben Tag für eine Applikation umgesetzt werden.
Technik




Azure Active Directory-Forest erzeugen und konfigurieren.
AAD-Benutzer einrichten oder per AAD Sync (AAD Connect) aus internem AD synchronisieren.
Für eine Applikation den AAD Application Proxy einrichten.
Applikationsberechtigungen konfigurieren.
Die AAD-Infrastruktur erlaubt auf ähnlichem Weg auch die Integration mit externen SaaS-Diensten.
Hierbei wird z.B. via AAD gesteuert, welche Benutzer mit einem durch die Firma verwalteten Konto
Zugang zu GoToMeeting oder Facebook erhalten.

TechNet: http://blogs.technet.com/b/ad/archive/2014/06/10/public-preview-of-azure-adapplication-proxy.aspx
31.12.14, v1.0.44
- 59 -

Lösungsszenarien Azure

Transcrição

Documentos relacionados

Pressemitteilung Virtual Reality in neuer Qualität Imsys stellt neue

Windows Server 2008 Virtualisierung

Netzwerktechnik CHS Villach Mag. Rainer Swatek Dauer: 2

DynamIk Für IHr UntErnEHmEn.

visionapp Platform Management Suite Most Recently Used List

Virtual Reality Open Lab Day

ONLINE-FARMER IM VIRTUELLEN SPORTTRIKOT

Überblick zu den Editionen von SQL Server 2008 R2

SharePoint 2016 On-Premises und in der Cloud

Bericht über eine Migration von NT SBS auf Windows 2003