SQL Server gehört in vielen Unternehmen zu den zentralen Plattformen für geschäftskritische Anwendungen, Transaktionssysteme, Datenanalyse und Business Intelligence. Gleichzeitig steigen die Anforderungen an Performance, Verfügbarkeit, Skalierbarkeit und Datensicherheit.
Für Unternehmen, die ihre SQL-Server-Workloads nicht vollständig in eine Public Cloud verlagern möchten, stellt sich deshalb die Frage, wie sich eine leistungsfähige lokale Infrastruktur mit modernen Azure-Technologien verbinden lässt.
Azure Local bietet dafür eine interessante Plattform. SQL Server kann auf virtuellen Maschinen innerhalb einer Azure-Local-Umgebung betrieben werden. Dadurch lassen sich lokale Datenverarbeitung, Hyperconverged Infrastructure und Azure-Integration miteinander verbinden.
Microsoft unterstützt SQL Server auf Azure Local unter anderem für OLTP-Workloads, Data Warehouse und Business Intelligence sowie KI- und Advanced-Analytics-Szenarien.
Was ist Azure Local?
Azure Local ist Microsofts aktuelle Plattform für Azure-basierte Infrastruktur in kundeneigenen und verteilten Umgebungen.
Die Lösung ermöglicht es Unternehmen, Workloads auf eigener Infrastruktur auszuführen und gleichzeitig Azure-Technologien für Management, Governance, Monitoring und weitere Funktionen einzusetzen.
Der Begriff Azure Stack HCI ist in diesem Zusammenhang weiterhin relevant, insbesondere bei älteren Installationen, Dokumentationen und technischen Architekturen. Für aktuelle Bereitstellungen und die aktuelle Produktbezeichnung sollte jedoch Azure Local verwendet werden.
Für SQL Server ist besonders interessant, dass Datenbank-Workloads auf virtuellen Maschinen innerhalb der Azure-Local-Umgebung ausgeführt werden können. Dabei werden sowohl Windows Server als auch Linux als Gastbetriebssysteme unterstützt.
Warum SQL Server auf Azure Local betreiben?
SQL Server benötigt eine Infrastruktur, die nicht nur ausreichend Rechenleistung bereitstellt, sondern auch Speicher, Netzwerk, Hochverfügbarkeit und zuverlässige Wiederherstellungsmechanismen berücksichtigt.
Eine Azure-Local-Umgebung kann diese Komponenten in einer hyperkonvergenten Infrastruktur zusammenführen.
Dabei profitieren Unternehmen insbesondere von:
- lokaler Datenverarbeitung
- zentralem Azure-Management
- hoher Verfügbarkeit
- konsolidierten SQL-Server-Workloads
- flexibler Virtualisierung
- Integration in hybride IT-Architekturen
- Möglichkeiten für Backup und Disaster Recovery
- Unterstützung moderner Daten- und Analyse-Workloads
Microsoft beschreibt Azure Local ausdrücklich als Plattform für SQL Server und Storage Spaces Direct und nennt dabei sowohl Hochverfügbarkeit als auch den Betrieb geschäftskritischer Datenbanken als zentrale Szenarien.
SQL Server auf virtuellen Maschinen mit Azure Local
SQL Server wird auf Azure Local typischerweise innerhalb virtueller Maschinen betrieben.
Dadurch können mehrere Datenbank-Workloads innerhalb derselben Infrastruktur konsolidiert werden.
Beispielsweise können unterschiedliche Anwendungen jeweils eigene virtuelle Maschinen erhalten:
- ERP-Datenbank
- CRM-Datenbank
- Produktionsdatenbank
- Reporting-Datenbank
- Business-Intelligence-Workloads
- Entwicklungs- und Testumgebungen
Je nach Auslastung und Architektur können zusätzliche virtuelle Maschinen bereitgestellt werden.
Diese Konsolidierung kann dazu beitragen, die vorhandenen Hardware-Ressourcen effizienter zu nutzen und unterschiedliche Workloads voneinander zu trennen.
Performance: Was entscheidet über die Geschwindigkeit von SQL Server?
Eine leistungsfähige Plattform allein garantiert noch keine optimale SQL-Server-Performance.
Die tatsächliche Performance hängt unter anderem von folgenden Faktoren ab:
- CPU-Leistung
- Arbeitsspeicher
- Storage-Latenz
- IOPS
- Netzwerk
- Datenbankdesign
- Indexierung
- Abfrageoptimierung
- Konfiguration der virtuellen Maschinen
- SQL-Server-Konfiguration
- Workload-Profil
Gerade bei geschäftskritischen Datenbanken sollte deshalb nicht nur die Anzahl der CPU-Kerne betrachtet werden.
Für SQL Server ist beispielsweise die Storage-Performance besonders wichtig. Hohe I/O-Lasten können eine Datenbank erheblich ausbremsen, selbst wenn ausreichend CPU und RAM vorhanden sind.
Microsoft stellt deshalb eigene Werkzeuge für Monitoring und Performance Tuning von SQL Server auf Azure Local bereit.
Storage Spaces Direct und SQL Server
Azure Local basiert unter anderem auf softwaredefiniertem Storage.
Storage Spaces Direct ermöglicht es, lokalen Speicher mehrerer Server zu einem gemeinsam verwalteten Speicherpool zusammenzuführen.
Für SQL Server bietet dieses Modell interessante Möglichkeiten, da Datenbanken und virtuelle Maschinen auf einer hochverfügbaren Infrastruktur betrieben werden können.
Bei einer konkreten SQL-Server-Implementierung müssen allerdings Workload, I/O-Muster, Kapazität, Latenz und Redundanz gemeinsam betrachtet werden.
Eine Datenbank mit hoher Transaktionslast benötigt beispielsweise andere Storage-Eigenschaften als eine weniger kritische Reporting-Datenbank.
Hochverfügbarkeit für SQL Server
Bei geschäftskritischen Datenbanken reicht es nicht aus, lediglich einen leistungsfähigen Server bereitzustellen.
Ein Hardwarefehler darf nicht automatisch zum längeren Ausfall der Anwendung führen.
Azure Local kann gemeinsam mit Windows Server Failover Clustering und den nativen SQL-Server-Hochverfügbarkeitsfunktionen eingesetzt werden.
Microsoft nennt dabei insbesondere:
- Windows Server Failover Clustering
- Always On Availability Groups
- Always On Failover Cluster Instances
- Azure Cloud Witness
Diese Technologien adressieren unterschiedliche Ebenen der Hochverfügbarkeit.
Always On Availability Groups auf Azure Local
Always On Availability Groups gehören zu den wichtigsten SQL-Server-Technologien für Hochverfügbarkeit und Disaster Recovery.
Mit Availability Groups können Datenbanken von einer primären Instanz auf sekundäre Replikate repliziert werden.
In einer Azure-Local-Umgebung können Availability Groups beispielsweise innerhalb eines Clusters für Hochverfügbarkeit eingesetzt werden. Für Disaster-Recovery-Szenarien können Replikate auch über unterschiedliche Cluster oder Standorte verteilt werden.
Microsoft empfiehlt für geeignete Szenarien synchrone Replikation bei räumlich nahen Replikaten mit niedriger Latenz und asynchrone Replikation bei weiter entfernten Replikaten.
Welche Konfiguration sinnvoll ist, hängt von den Anforderungen an RPO und RTO ab.
Was bedeutet RPO?
Das Recovery Point Objective beschreibt, wie viel Datenverlust im schlimmsten Fall akzeptiert werden kann.
Beispiel:
Wenn ein Unternehmen ein RPO von fünf Minuten definiert, sollte die Architektur darauf ausgelegt sein, im Fehlerfall höchstens etwa fünf Minuten an Daten zu verlieren.
Was bedeutet RTO?
Das Recovery Time Objective beschreibt, wie schnell ein System nach einem Ausfall wieder verfügbar sein muss.
Je geringer RTO und RPO sein sollen, desto anspruchsvoller wird die technische Architektur.
Always On Failover Cluster Instance
Neben Availability Groups unterstützt SQL Server auch Failover Cluster Instances.
Eine FCI schützt eine komplette SQL-Server-Instanz und kann bei einem Ausfall auf einen anderen Clusterknoten wechseln.
Auf Azure Local basiert eine FCI auf der gemeinsam genutzten Storage-Infrastruktur von Storage Spaces Direct.
Die Entscheidung zwischen Availability Groups und FCI sollte anhand der Anwendung und der gewünschten Schutzebene getroffen werden.
Disaster Recovery für SQL Server auf Azure Local
Hochverfügbarkeit und Disaster Recovery sind nicht dasselbe.
Hochverfügbarkeit soll einen Ausfall möglichst schnell abfangen.
Disaster Recovery beschäftigt sich dagegen mit größeren Störungen, beispielsweise:
- Ausfall eines gesamten Standorts
- schwerwiegende Hardwareprobleme
- Ransomware
- Datenkorruption
- Verlust wichtiger Infrastruktur
- größere Netzwerkstörungen
Microsoft empfiehlt für SQL Server auf Azure Local einen mehrschichtigen Ansatz, bei dem der Schutz der Infrastruktur mit den nativen SQL-Server-Funktionen kombiniert wird.
Mögliche Bausteine sind:
- Always On Availability Groups
- Failover Cluster Instances
- Log Shipping
- Backups
- Azure Site Recovery
- Azure Backup
- Replikation
Welche Kombination sinnvoll ist, hängt von RPO, RTO, Datenmenge und Geschäftsanforderungen ab.
Backup ist kein Ersatz für Hochverfügbarkeit
Ein häufiger Fehler bei der Planung besteht darin, Backup und Hochverfügbarkeit gleichzusetzen.
Eine Availability Group kann einen Ausfall abfangen.
Ein Backup ermöglicht dagegen die Wiederherstellung von Daten nach einem logischen Fehler, einer Beschädigung oder einem anderen Szenario, in dem ein Failover nicht ausreicht.
Deshalb sollte ein professionelles SQL-Server-Konzept immer beide Ebenen berücksichtigen.
Microsoft nennt für SQL Server auf Azure Local unter anderem Azure Backup und SQL Server Managed Backup to Azure als mögliche Bestandteile einer Backup-Strategie.
Monitoring und Performance Tuning
Ein SQL-Server-Cluster sollte nicht erst dann überwacht werden, wenn Benutzer über langsame Anwendungen berichten.
Wichtige Kennzahlen sind unter anderem:
- CPU-Auslastung
- RAM-Nutzung
- Storage-Latenz
- IOPS
- Transaktionsdurchsatz
- Wait Statistics
- Query Performance
- Datenbankwachstum
- TempDB-Nutzung
- Netzwerk
- Failover-Ereignisse
Durch kontinuierliches Monitoring lassen sich Performance-Probleme häufig erkennen, bevor sie zu einem größeren Problem für die Anwendung werden.
Microsoft stellt für SQL Server auf Azure Local entsprechende Monitoring- und Performance-Tuning-Werkzeuge bereit.
SQL Server für OLTP, Data Warehouse und Business Intelligence
Azure Local eignet sich nicht nur für klassische SQL-Server-Anwendungen.
Microsoft nennt ausdrücklich mehrere Workload-Kategorien:
OLTP
Online Transaction Processing ist typisch für:
- ERP-Systeme
- CRM-Systeme
- Warenwirtschaft
- Produktionssysteme
- Buchhaltung
- E-Commerce
Hier stehen schnelle Transaktionen, geringe Latenzen und hohe Verfügbarkeit im Vordergrund.
Data Warehouse
Bei Data-Warehouse-Systemen werden große Datenmengen analysiert und für Berichte und Auswertungen aufbereitet.
Hier spielen insbesondere Storage-Durchsatz, CPU, RAM und die Struktur der Abfragen eine wichtige Rolle.
Business Intelligence
SQL Server auf Azure Local kann auch als Teil einer BI-Architektur eingesetzt werden.
Dabei können operative Datenbanken und analytische Workloads je nach Architektur getrennt oder miteinander integriert werden.
Microsoft nennt Data Warehouse und Business Intelligence ausdrücklich als unterstützte SQL-Server-Workload-Szenarien auf Azure Local.
SQL Server und KI auf Azure Local
Moderne Datenplattformen müssen zunehmend auch Anforderungen an künstliche Intelligenz und Advanced Analytics erfüllen.
Microsoft nennt für SQL Server auf Azure Local ausdrücklich KI und Advanced Analytics über große Datenmengen als mögliches Workload-Szenario.
Der Vorteil einer lokalen Verarbeitung kann insbesondere dann interessant sein, wenn große Datenmengen bereits lokal vorhanden sind.
Allerdings sollte nicht jede KI-Anwendung automatisch lokal betrieben werden.
Vor einer Entscheidung müssen unter anderem Datenvolumen, Modellgröße, GPU-Anforderungen, Latenz, Datenschutz und Betriebsmodell betrachtet werden.
Azure Arc und SQL Server
Die Verbindung mit Azure endet nicht bei der Infrastruktur.
Azure Arc ermöglicht zusätzliche Management- und Monitoring-Funktionen für SQL Server in hybriden Umgebungen.
Microsoft beschreibt Arc-enabled SQL Server auf Azure Local als Möglichkeit, SQL-Server-Umgebungen über Azure zentraler sichtbar und verwaltbar zu machen.
Dazu gehören unter anderem Funktionen für die Überwachung und Verwaltung von Availability Groups sowie Backup- und Recovery-Szenarien.
Damit kann SQL Server auf Azure Local stärker in eine übergreifende Hybrid-Cloud-Strategie eingebunden werden.
Azure Local und Azure Resource Manager
Azure Local bietet eine Azure-konsistente Managementerfahrung.
Für die Bereitstellung können unter anderem Azure Portal und Azure Resource Manager verwendet werden. Microsoft dokumentiert auch die Bereitstellung von Azure Local über Azure Resource Manager Templates.
Das ist insbesondere für Unternehmen interessant, die ihre Infrastruktur stärker automatisieren und standardisieren möchten.
Infrastructure-as-Code-Ansätze können dabei helfen, wiederholbare Bereitstellungen und konsistente Konfigurationen umzusetzen.
Was muss bei der Hardware beachtet werden?
Die Hardware ist ein entscheidender Bestandteil einer Azure-Local-Umgebung.
Für produktive SQL-Server-Workloads sollte nicht einfach irgendein Server eingesetzt werden.
Microsoft verweist auf den Azure Local Catalog und validierte beziehungsweise für entsprechende Workloads geeignete Systeme.
Bei der Planung sollten unter anderem berücksichtigt werden:
- CPU
- RAM
- NVMe- und SSD-Konfiguration
- Storage-Kapazität
- Netzwerkbandbreite
- Redundanz
- Clustergröße
- erwartete IOPS
- Datenbankwachstum
- Backup-Kapazität
Die Dimensionierung sollte immer auf Basis der tatsächlichen SQL-Server-Workloads erfolgen.
Azure Local oder klassische SQL-Server-Infrastruktur?
Azure Local ist nicht automatisch für jede SQL-Server-Umgebung die beste technische Lösung.
Ein klassischer SQL-Server auf dedizierter Hardware kann beispielsweise für bestimmte Workloads sinnvoll sein.
Azure Local bietet dagegen Vorteile, wenn mehrere Anforderungen gleichzeitig erfüllt werden sollen:
- Virtualisierung
- Hyperconverged Infrastructure
- hohe Verfügbarkeit
- lokale Workloads
- Azure-Integration
- zentrale Verwaltung
- hybride Szenarien
Die Entscheidung sollte deshalb nicht anhand eines einzelnen Performance-Wertes getroffen werden.
Azure Local vs. SQL Server in der Public Cloud
Auch die Frage „lokal oder Cloud?“ lässt sich nicht pauschal beantworten.
| Kriterium | SQL Server auf Azure Local | SQL Server in der Public Cloud |
|---|---|---|
| Infrastruktur | Kundeneigene Umgebung | Cloud-Anbieter |
| Datenstandort | Lokal steuerbar | Cloud-Rechenzentrum |
| Latenz zu lokalen Systemen | Häufig sehr gering | Netzwerkabhängig |
| Hardwarebetrieb | Unternehmen/Partner | Cloud-Anbieter |
| Azure-Integration | Ja | Nativ |
| Skalierung | Abhängig von Infrastruktur | Sehr flexibel |
| Lokale Workloads | Sehr gut geeignet | Abhängig von Netzwerk und Architektur |
| Hybrid Cloud | Sehr gut geeignet | Ebenfalls möglich |
| Investition in Hardware | Erforderlich | Nicht erforderlich |
Für viele Unternehmen muss die Antwort deshalb nicht „Azure Local oder Azure“ lauten.
Eine hybride Architektur kann sinnvoller sein.
Wann eignet sich SQL Server auf Azure Local?
Die Plattform kann insbesondere für Unternehmen interessant sein, die:
- geschäftskritische SQL-Server-Workloads lokal betreiben
- hohe Verfügbarkeit benötigen
- bestehende Virtualisierungsumgebungen modernisieren möchten
- mehrere SQL-Server-Workloads konsolidieren möchten
- geringe Latenz benötigen
- Daten aus Compliance-Gründen lokal verarbeiten müssen
- Azure-Technologien in ihre lokale Infrastruktur integrieren möchten
- hybride Disaster-Recovery-Szenarien benötigen
Vor einer Einführung sollte jedoch eine detaillierte Analyse der bestehenden Workloads durchgeführt werden.
Wie sollte ein Azure-Local-SQL-Server-Projekt geplant werden?
Eine professionelle Planung sollte mehrere Phasen umfassen.
1. Workload-Analyse
Zunächst werden Datenbanken, Anwendungen, Abhängigkeiten und Performance-Anforderungen erfasst.
2. Performance-Baseline
CPU, RAM, Storage, IOPS, Latenz und Query Performance sollten vor der Migration dokumentiert werden.
3. Zielarchitektur
Anschließend wird festgelegt, welche SQL-Server-Instanzen und Datenbanken auf Azure Local betrieben werden.
4. Hochverfügbarkeit
RPO und RTO bestimmen, welche HA- und DR-Technologien benötigt werden.
5. Backup und Recovery
Backups müssen nicht nur eingerichtet, sondern auch regelmäßig getestet werden.
6. Monitoring
Ein kontinuierliches Monitoring sollte bereits vor dem produktiven Betrieb geplant werden.
7. Migration
Microsoft unterstützt die Bereitstellung von SQL Server auf Azure Local und stellt entsprechende Dokumentation für Installation, Performance, Hochverfügbarkeit und Azure-Hybridservices bereit.
Häufige Fragen zu SQL Server auf Azure Local
Kann SQL Server auf Azure Local betrieben werden?
Ja. Microsoft unterstützt SQL Server auf virtuellen Maschinen innerhalb von Azure Local. Unterstützt werden unter anderem Windows Server und Linux als Gastbetriebssysteme.
Ist Azure Stack HCI dasselbe wie Azure Local?
Azure Local ist die aktuelle Produktbezeichnung. Azure Stack HCI ist weiterhin als Begriff in älteren Dokumentationen, bestehenden Umgebungen und technischen Zusammenhängen zu finden. Bei neuen Projekten sollte die aktuelle Microsoft-Terminologie verwendet werden.
Ist SQL Server auf Azure Local hochverfügbar?
Azure Local kann zusammen mit Windows Server Failover Clustering und SQL-Server-Technologien wie Always On Availability Groups und Failover Cluster Instances für hochverfügbare SQL-Server-Architekturen eingesetzt werden.
Unterstützt Azure Local Always On Availability Groups?
Ja. Always On Availability Groups können auf SQL Server-Instanzen in Azure-Local-VMs für Hochverfügbarkeit und Disaster Recovery eingesetzt werden.
Kann SQL Server auf Azure Local für große Datenbanken verwendet werden?
Azure Local kann für geschäftskritische SQL-Server-Workloads eingesetzt werden. Ob eine konkrete Datenbank für die Plattform geeignet ist, hängt von Datenmenge, I/O-Profil, CPU- und RAM-Bedarf sowie den Anforderungen an Verfügbarkeit und Recovery ab.
Unterstützt Azure Local SQL Server auf Linux?
Ja. Microsoft dokumentiert SQL Server auf Azure Local sowohl auf virtuellen Maschinen mit Windows Server als auch mit Linux.
Wie wird SQL Server auf Azure Local gesichert?
Je nach Anforderungen können unter anderem SQL-Server-eigene Backup-Mechanismen, Azure Backup, SQL Server Managed Backup to Azure und weitere Lösungen eingesetzt werden. Die konkrete Auswahl sollte an RPO, RTO und die Anforderungen der jeweiligen Anwendung angepasst werden.
Kann Azure Local für Disaster Recovery genutzt werden?
Ja. Azure Local unterstützt verschiedene Disaster-Recovery-Ansätze. SQL Server kann dabei unter anderem Always On Availability Groups, Log Shipping und weitere SQL-native Technologien einsetzen.
Ist Azure Local schneller als ein herkömmlicher SQL Server?
Eine pauschale Aussage ist nicht möglich. Die tatsächliche SQL-Server-Performance hängt von CPU, RAM, Storage, Netzwerk, Datenbankdesign, Query Performance und Workload ab. Azure Local bietet eine Plattform für leistungsfähige und hochverfügbare SQL-Server-Workloads, garantiert aber nicht automatisch eine bestimmte Performance.
Wann lohnt sich SQL Server auf Azure Local?
Interessant kann die Lösung insbesondere dann sein, wenn SQL Server lokal betrieben werden soll, gleichzeitig aber Virtualisierung, hohe Verfügbarkeit, zentrale Verwaltung und Azure-Integration benötigt werden.
Fazit
SQL Server auf Azure Local verbindet lokale Infrastruktur mit modernen Azure-Technologien.
Für Unternehmen mit geschäftskritischen Datenbanken kann die Plattform interessant sein, wenn hohe Verfügbarkeit, lokale Datenverarbeitung, Virtualisierung und eine Integration in hybride Azure-Umgebungen gleichzeitig benötigt werden.
Dabei sollte die Architektur nicht ausschließlich auf maximale Performance ausgerichtet werden. Ebenso wichtig sind Storage, Netzwerk, Hochverfügbarkeit, Backup, Disaster Recovery, Monitoring und die definierten RPO- und RTO-Ziele.
Azure Local bietet dafür eine flexible Infrastrukturplattform. SQL Server stellt mit Always On Availability Groups, Failover Cluster Instances und weiteren Funktionen die notwendigen Möglichkeiten für Datenbank-Hochverfügbarkeit und Disaster Recovery bereit. Azure Arc kann zusätzlich dabei helfen, SQL Server stärker in eine zentrale Azure-Managementstrategie einzubinden.
Für Unternehmen, die ihre SQL-Server-Infrastruktur modernisieren und gleichzeitig lokale Kontrolle mit den Möglichkeiten von Microsoft Azure verbinden möchten, kann Azure Local deshalb ein sinnvoller Bestandteil einer hybriden IT-Architektur sein.
