Microsoft Azure Lösungsszenarien

Transkript

1 Microsoft Azure Lösungsszenarien , v1.0.44, 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 : Backup-DC auf Azure : Zentrale Dateidienste auf Azure mit dezentralem BranchCache : Hybrid Cloud Storage (StorSimple) : Backup nach Azure (verschiedene Varianten: Windows Server, SQL Server, DPM, 3rd-Party) : SQL Server HA (Availability Groups auf Azure oder hybrid mit lokalen Servern kombiniert) : SharePoint auf Azure IaaS mit optionaler On-Prem Datenhaltung : Autoskalierende Websites : SAP auf Azure : Oracle Dev & Test : ADFS auf Azure IaaS für On-Prem AD-Forests : DirSync/AAD Sync auf Azure IaaS für On-Prem Forests : BI und Reporting für mobile Anwender sowie als ISV-Saas-Angebot (SQL Server Reporting Services in Azure IaaS) : Globaler WAN/LAN -Interconnect via Azure Virtual Networks : Migration von Hyper-V und VMware VMs in Azure Virtual Machines : Schnelles Wiederherstellen virtueller Server (Azure Site Recovery) : Offline Files via Windows Server File Sharing auf Azure IaaS : Publizieren interner Webapplikationen für externe Nutzer (AAD Application Proxy) , v

2 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 , v

3 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 , v

4 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 p.a. Azure Storage (127GB, lokal redundant) p.a. Azure Virtual Network Gateway (VNet ist gratis, nur GW kostet) p.a. Bandbreitennutzung (5GB inbegriffen p.m.) vernachlässigbar Total ca. CHF 1' 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 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 Standard- Parameterwerte , v

5 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 Die technische Dokumentation zu den verwendeten Azure-Diensten ist hier zu finden: , v

6 Microsoft Azure Lösungsszenario 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. Ausgangslage, Herausforderung 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 DirectAccess- Verbindung 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 , v

7 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: Argumente für dieses Szenario 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 , v

8 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 Windows- Clients 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. Verwendete Azure-Dienste Azure Storage Azure VM Azure Virtual Network Kosten Azure Betriebskosten (Beispiel) 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 1' p.a. Azure Storage für OS (1x127GB, lokal redundant) p.a. Azure Storage für Daten (2TB, georedundant) 2' p.a. Azure Virtual Network Gateway (VNet ist gratis, nur GW kostet) p.a. Bandbreitennutzung (500GB downstream p.m.) p.a. Total ca. CHF 4' p.a. Die Storage-Kosten werden nur für den effektiv belegten Platz pro Abrechnungsperiode verrechnet , v

9 Implementierungsaufwand Bei bestehender Internetanbindung, vorhandenen lokalen Servern und vorhandener Azure- Subscription ist die Azure-seitige Bereitstellung in zwei bis vier Stunden realisierbar (exkl. Planung und Datentransfer auf den neuen Fileserver). 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 Standard- Parameterwerte. Technik Implementierungsschritte (Übersicht) 1. Azure Storage Account für die vhd der VM anlegen und gewünschte Redundanz/Kosten einstellen. 2. Ein Azure Virtual Network anlegen, dies sowohl mit Option Site-to-Site-VPN als auch Point-to- Site-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. 3. Gateway im Azure VNet erzeugen und Site-to-Site-VPN-Tunnel einrichten. 4. Neue Azure VM mit fixer IP im Azure VNet erzeugen. 5. Die neue Azure VM in die Firmendomäne einbinden. 6. Die neue Azure VM mit Dateidiensten und BranchCache konfigurieren. 7. BranchCache auf Servern und/oder Clients an den Firmenstandorten einrichten. Integrationsmöglichkeiten 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. Weitergehende Informationsquellen BranchCache Technical Overview: Die technische Dokumentation zu den verwendeten Azure-Diensten ist hier zu finden: , v

10 Microsoft Azure Lösungsszenario 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. Ausgangslage, Herausforderung 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 , v

11 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. Argumente für dieses Szenario 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 , v

12 Lösungsarchitektur Beispiel einer SharePoint Server Farm: Verwendete Azure-Dienste StorSimple verwendet neben der physischen Appliance auch eine virtuelle Appliance auf Azure. Diese nutzt folgende Dienste: Azure Storage Account Azure Virtual Network 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' 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. Implementierungsaufwand 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) , v

13 Technik Implementierungsschritte (Übersicht) 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 Integrationsmöglichkeiten 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. Weitergehende Informationsquellen StorSimple Hybrid Cloud Storage: StorSimple 8000 Series Datasheet: StorSimple Pricing: StorSimple at Seagate: Die technische Dokumentation zu den verwendeten Azure-Diensten ist hier zu finden: , v

14 Microsoft Azure Lösungsszenario 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. Ausgangslage, Herausforderung 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 , v

15 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. Argumente für dieses Szenario 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 , v

16 Lösungsarchitektur Microsoft Azure Portal Anmeldung Abrechnung Microsoft Azure Backup-Dienst Registrierung Sicherung/ Wiederherstellung Windows Server 2012 R2 Eingangsmodul Eingangsbenutzeroberfl Windows Server 2012 R2 Sicherung (erweiterbar) Azure Backup- Agent IT-Mitarbeiter Verwendete Azure-Dienste Azure Storage Azure Backup Kosten Azure Betriebskosten 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). Implementierungsaufwand Beide Szenarien lassen sich bei bestehender Internetanbindung, vorhandenen lokalen Servern und vorhandener Azure-Subscription in einer Stunde realisieren (exkl. Planung) , v

17 Technik Implementierungsschritte (Übersicht) Nur mit Azure Storage, z.b. aus SQL Server: Azure Storage Account anlegen und gewünschte Redundanz/Kosten einstellen. 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 Storage Account anlegen und gewünschte Redundanz/Kosten einstellen. 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. Weitergehende Informationsquellen Die technische Dokumentation zu den verwendeten Azure-Diensten ist hier zu finden: , v

18 Microsoft Azure Lösungsszenario 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. Ausgangslage, Herausforderung 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 , v

19 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. Argumente für dieses Szenario Kostengünstige Realisierung von Hochverfügbarkeit für SQL Server. Wegfall der Notwendigkeit von zusätzlicher Hardware oder geografisch verteilten SQL Server- Installationen innerhalb des Betriebs. Die Storage-Kosten werden nur für den effektiv belegten Platz pro Abrechnungsperiode verrechnet. Lösungsarchitektur Beispiel einer hybriden Architektur: Verwendete Azure-Dienste Azure Storage Azure VM Azure Virtual Network , v

20 Kosten Azure Betriebskosten (Beispiel) 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' p.a. Azure Storage für OS (1x127GB, lokal redundant) p.a. Azure Storage für Daten (500GB, lokal redundant) p.a. Azure Virtual Network Gateway (VNet ist gratis, nur GW kostet) p.a. Bandbreitennutzung (mehrheitlich upstream) vernachlässigbar Total ca. CHF 16' p.a. Implementierungsaufwand Bei bestehender Internetanbindung, vorhandenen lokalen Servern und vorhandener Azure- Subscription 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. 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 Standard- Parameterwerte , v

21 Technik Implementierungsschritte (Übersicht) 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 DNS- Server registrieren. Gateway im Azure VNet erzeugen und Site-to-Site-VPN-Tunnel einrichten. 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. Integrationsmöglichkeiten 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. Weitergehende Informationsquellen HA/DR für SQL Server in Azure VMs: Die technische Dokumentation zu den verwendeten Azure-Diensten ist hier zu finden: , v

22 Microsoft Azure Lösungsszenario 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 SharePoint- Farm 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) Ausgangslage, Herausforderung 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 SharePoint- Dienste) , v

23 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 SharePoint- Farm 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. Argumente für dieses Szenario 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 Verwendete Azure-Dienste Azure Storage Azure VM Azure Virtual Network , v

24 Kosten Azure Betriebskosten (Beispiel) 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 1' p.a. 2 Azure VMs Standard A5 (SQL: 2 Core/14GB RAM) 5' p.a. 1 Azure VMs Basic A0 (SQL Witness: 1 Core/768MB RAM) p.a. 4 Azure VM Standard A2 (SharePoint, 2 Core/3.5GB RAM) 6' p.a. Azure Storage für OS (9x127GB, lokal redundant) p.a. Azure Storage für Daten (2TB, georedundant) 2' p.a. Azure Virtual Network Gateway (VNet ist gratis, nur GW kostet) p.a. Bandbreitennutzung (100GB downstream p.m.) p.a. Total ca. CHF 16' 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. Implementierungsaufwand Bei bestehender Internetanbindung, vorhandenen lokalen Servern (Domäne) und vorhandener Azure- Subscription 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. 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 Standard- Parameterwerte , v

25 Technik Implementierungsschritte (Übersicht) 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 (S2S- Tunnel). SharePoint-Farm per RDP in den VMs konfigurieren, mit den üblichen Werkzeugen (nicht Azurespezifisch). Integrationsmöglichkeiten 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. Auf diesem Weg sind z.b. weitere Content-Datenbanken interner SQL Server-Instanzen oder interne BCS-Verbindungen zu solchen realisierbar. Weitergehende Informationsquellen SharePoint auf Azure IaaS: Die technische Dokumentation zu den verwendeten Azure-Diensten ist hier zu finden: , v

26 Microsoft Azure Lösungsszenario 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. Ausgangslage, Herausforderung 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 , v

27 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 Farm- Memberservern 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. Argumente für dieses Szenario Jede der drei beschriebenen Subvarianten bietet grosse Flexibilität bei geringerem Wartungsaufwand und tieferen Kosten als in lokalem/gehostetem Betrieb , v

28 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. Verwendete Azure-Dienste 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 Azure Betriebskosten (Beispiel) 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' p.a. Szenario B: CHF 5' p.a. Szenario C: CHF 4' 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). Implementierungsaufwand 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 Standard- Parameterwerte , v

29 Technik Implementierungsschritte (Übersicht) Azure Storage Account anlegen und gewünschte Redundanz/Kosten einstellen. 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. Integrationsmöglichkeiten 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 , v

30 Microsoft Azure Lösungsszenario 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. Ausgangslage, Herausforderung 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 , v

31 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. Argumente für dieses Szenario 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). Verwendete Azure-Dienste 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 pro Monat, zzgl. Speicherplatzbedarf , v

32 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 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) Implementierungsaufwand Das Erzeugen der Azure-Infrastruktur ist - exkl. Planung - in zwei Stunden realisierbar. Der Hauptaufwand entsteht durch den Aufbau und die Konfiguration der SAP-Dienste. 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 Standard- Parameterwerte. Technik Implementierungsschritte (Übersicht) Azure Storage Account anlegen und gewünschte Redundanz/Kosten einstellen. Azure Virtual Network anlegen, optional S2S-VPN-Tunnel einrichten. Azure Virtual Machines als SAP-Hosts anlegen. Integrationsmöglichkeiten 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 SAP-Hosts sind so nutzbar wie wenn diese im lokalen Netzwerk betrieben würden. Weitergehende Informationsquellen MSDN - Using SAP on Azure VMs: SAP Notes zu Azure: , v

33 Microsoft Azure Lösungsszenario 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. Ausgangslage, Herausforderung 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 , v

34 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. Argumente für dieses Szenario 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). Verwendete Azure-Dienste Azure Storage Azure Virtual Network (mit oder ohne S2S-Anbindung) Azure Virtual Machine , v

35 Kosten Azure Betriebskosten Für Oracle werden Maschinen ab A2 (zwei Prozessorkerne, 3.5GB RAM) vorausgesetzt. Dieser Maschinentyp kostet ab CHF p.m. Die Gesamtkosten einer vollständigen Oracle-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 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) Implementierungsaufwand 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. 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 Standard- Parameterwerte. Technik Implementierungsschritte (Übersicht) Azure Storage Account anlegen und gewünschte Redundanz/Kosten einstellen. Azure Virtual Network anlegen, optional S2S-VPN-Tunnel aufbauen. Azure Virtual Machines als Oracle-Hosts anlegen. Integrationsmöglichkeiten 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 Oracle-Hosts sind so nutzbar wie wenn diese im lokalen Netzwerk betrieben würden. Weitergehende Informationsquellen , v

36 Microsoft Azure Lösungsszenario 10: ADFS auf Azure IaaS für On-Prem AD- Forests 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. Ausgangslage, Herausforderung 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) , v

37 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. Argumente für dieses Szenario 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. Verwendete Azure-Dienste Azure Storage Azure Virtual Network mit S2S-VPN-Anbindung Azure Virtual Machine , v

38 Kosten Azure Betriebskosten (Beispiel) 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: 4 Azure VM (Standard A2) CHF 6' p.a. Azure Storage für OS (4x127GB, lokal redundant) p.a. Azure Virtual Network Gateway (VNet ist gratis, nur GW kostet) p.a. Bandbreitennutzung (50GB downstream p.m.) p.a. Total ca. CHF 6' p.a. Implementierungsaufwand Die Implementierung der obigen Infrastruktur ist in einem halben bis ganzen Arbeitstag realisierbar (exkl. Planung). 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 Standard- Parameterwerte. Technik Implementierungsschritte (Übersicht) Azure Storage Account anlegen und gewünschte Redundanz/Kosten einstellen. 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. Integrationsmöglichkeiten 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. Weitergehende Informationsquellen Technet: , v

39 Microsoft Azure Lösungsszenario 11: DirSync/AAD Sync auf Azure IaaS für On- Prem 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. Ausgangslage, Herausforderung 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.ä.) , v

40 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. Argumente für dieses Szenario 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). Verwendete Azure-Dienste Azure Storage Azure Virtual Network mit S2S-VPN-Anbindung Azure Virtual Machine , v

41 Kosten Azure Betriebskosten (Beispiel) 4 Azure VM (Standard A2) CHF 6' p.a. Azure Storage für OS (4x127GB, lokal redundant) p.a. Azure Virtual Network Gateway (VNet ist gratis, nur GW kostet) p.a. Bandbreitennutzung (50GB downstream p.m.) p.a. Total ca. CHF 6' p.a. Implementierungsaufwand Dieses Szenario lässt sich in ca. zwei Stunden realisieren (exkl. Planung). 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 Standard- Parameterwerte. Technik Implementierungsschritte (Übersicht) Azure Storage Account anlegen und gewünschte Redundanz/Kosten einstellen. 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). Integrationsmöglichkeiten 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 , v

42 Microsoft Azure Lösungsszenario 12: BI und Reporting für mobile Anwender sowie als ISV-Saas- Angebot (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. Ausgangslage, Herausforderung 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-to- Site-VPN-Verbindung in ein Azure VNet ab mobilen Windows Clients) erfolgen , v

43 Argumente für dieses Szenario 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 Verwendete Azure-Dienste Azure Storage Azure Virtual Network, je nach Szenario mit S2S-VPN-Anbindung Azure Virtual Machines (SQL Server-Image inkl. SQL Server-Lizenzierung) , v

44 Kosten Azure Betriebskosten 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 24' p.a. Azure Storage für OS (2x127GB, lokal redundant) p.a. Azure Virtual Network Gateway (VNet ist gratis, nur GW kostet) p.a. Bandbreitennutzung (50GB downstream p.m.) p.a. Total ca. CHF 25' p.a. Dieses Kostenmodell geht davon aus, dass für SSRS keine weiteren Datendisks verwendet werden. Implementierungsaufwand Dieses Szenario lässt sich in zwei Stunden realisieren (exkl. Planung und SSRS-Konfiguration). 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 Standard- Parameterwerte. Technik Implementierungsschritte (Übersicht) Azure Storage Account anlegen und gewünschte Redundanz/Kosten einstellen. 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. Integrationsmöglichkeiten 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. Weitergehende Informationsquellen MSDN: , v

45 Microsoft Azure Lösungsszenario 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. Ausgangslage, Herausforderung 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 , v

46 Argumente für dieses Szenario 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. Verwendete Azure-Dienste Azure Virtual Network , v

47 Kosten Azure Betriebskosten 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 p.a. High Performance Gateways mit bis zu 30 VPN-Tunnels und 200 Mbps werden zu CHF 3' 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 pro GB (Asien: CHF /GB, Südamerika: /GB). Implementierungsaufwand 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 Implementierungsschritte (Übersicht) 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. Integrationsmöglichkeiten 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 , v

48 Microsoft Azure Lösungsszenario 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. Ausgangslage, Herausforderung 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 , v

49 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. Argumente für dieses Szenario 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 IP- Ranges 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. Verwendete Azure-Dienste Azure Storage Azure Virtual Network Azure Virtual Machine , v

50 Kosten Azure Betriebskosten Die Betriebskosten auf Azure richten sich nach Anzahl, Grösse und Betriebsstunden der transferierten VMs. 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 p.a.) Azure Virtual Machines Downstream Bandbreitennutzung über 5GB p.m. Allfällige Client-Lizenzen auf RDS-Hosts in Azure (via SPLA zu beschaffen) Technik Implementierungsschritte (Übersicht) 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. Integrationsmöglichkeiten 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. Weitergehende Informationsquellen Microsoft Virtual Machine Converter: , v

51 Microsoft Azure Lösungsszenario 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. Ausgangslage, Herausforderung 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 , v

52 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. Argumente für dieses Szenario 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. Verwendete Azure-Dienste Azure Storage Azure Recovery Services (Site Recovery Vault) Azure Virtual Network Azure Virtual Machine , v

53 Kosten Azure Betriebskosten Die Betriebskosten auf Azure richten sich nach Anzahl, Grösse und Betriebsstunden der transferierten VMs. Folgende Kostenfaktoren sind seitens Azure in die Kalkulation mit einzubeziehen: Azure Storage für die durch Azure Site Recovery geschützten virtuellen Disks Azure Virtual Network Gateway (nur wenn S2S-VPN-Tunnel genutzt wird, CHF p.a.) Azure Site Recovery (CHF pro geschützte Maschine und Monat) Technik Implementierungsschritte (Übersicht) 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 AD- Domäne neu registriert. Dadurch verläuft der Failover für die Nutzer weitestgehend transparent und bedingt keine weitere Konfigurationsänderung. Integrationsmöglichkeiten 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. Weitergehende Informationsquellen Technet Walkthrough (Variante mit SCCM): , v

54 Microsoft Azure Lösungsszenario 16: Offline Files via Windows Server File Sharing auf Azure IaaS Ziel, Kundennutzen Dateien aus Windows-Fileshares sollen auch offline auf Windows- Clients genutzt werden können. Dies ist ohne interne physische Serverinfrastruktur zu realisieren, jedoch volle Active Directory- Steuerung (Group Policies usw.) unterstützen und somit keine SaaS- Dienste (OneDrive for Business o.ä.) in Anspruch nehmen. Ausgangslage, Herausforderung 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 , v

55 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. Argumente für dieses Szenario Keine eigene physische Serverinfrastruktur notwendig. Mobile Offline-Nutzung von Dateien auf Windows Clients ohne Inanspruchnahme eines SaaS- Angebots 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-to- Site-VPN-Tunnel aufgebaut. Verwendete Azure-Dienste Azure Storage Azure Virtual Network Azure Virtual Machine , v

56 Kosten Azure Betriebskosten 2 Azure VM (1xA1 Basic, 1xA2 Basic) CHF 1' p.a. Azure Storage für OS (2x127GB, lokal redundant) p.a. Azure Storage für Daten (1TB, georedundant) 1' p.a. Azure Virtual Network Gateway (VNet ist gratis, nur GW kostet) p.a. Bandbreitennutzung (50GB downstream p.m.) p.a. Total ca. CHF 3' p.a. 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. Implementierungsaufwand 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 Windows- Clients stellt das Azure-Portal eine Installationsdatei zur Verfügung. Technik Implementierungsschritte (Übersicht) 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. Integrationsmöglichkeiten 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 , v

57 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, SharePoint- Sites, 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. Ausgangslage, Herausforderung Das Publizieren interner Applikationen an externe Benutzer verlangt in der Regel komplexe Proxy- Konfigurationen 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 , v

58 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 Push- Verfahren zur Verfügung gestellt, weshalb kein Zugang ins Intranet gewährt werden muss für externe Benutzer. Argumente für dieses Szenario Publizieren interner Webapplikationen ohne Öffnen von Firewallports. Kein Zugang zum Intranet für externe Benutzer notwendig. Lösungsarchitektur Verwendete Azure-Dienste Azure Active Directory Premium mit AAD Application Proxy , v