DTU, vCore & Co: Wie du Azure SQL richtig skalierst

Wer mit Azure SQL beginnt, steht früh vor Entscheidungen mit weitreichenden Folgen. Es geht nicht nur darum, wie viel Leistung eine Datenbank aktuell benötigt, sondern auch darum, wie sie in Zukunft wachsen kann und welche Kosten dabei entstehen. Skalierung ist daher mehr als ein technisches Thema, sie ist ein strategischer Faktor. Die Wahl des passenden Modells beeinflusst Performance, Kosten und die Flexibilität bei neuen Anforderungen. Wer vorausschauend plant, spart langfristig Geld, reduziert Komplexität und vermeidet aufwendige Migrationen.

Auswahl des richtigen Modells

Beim Erstellen einer Azure SQL-Datenbank steht man zunächst vor der Qual der Wahl: DTU, vCore, Managed Instance, elastisch oder dediziert, serverless oder provisioniert? Azure SQL bietet verschiedene Betriebsmodelle, die sich in Flexibilität, Kostenstruktur und Funktionsumfang unterscheiden. Jedes Modell bringt eigene Vor- und Nachteile mit. Die richtige Wahl hängt von Anforderungen wie Performance, Kostenkontrolle, Kompatibilität und Skalierbarkeit ab. Dabei bezahlt man bei Azure SQL für die Datenbank und nicht für den Server, sofern man nicht die Resourcen zwischen den Datenbanken teilen möchte.

Im Folgenden schauen wir uns die beiden wichtigsten Modelle genauer an: DTU und vCore.

Das DTU-Modell (Database Transaction Unit) fasst CPU, Arbeitsspeicher und I/O in festen Leistungspaketen zusammen. Es ist besonders für den schnellen Einstieg geeignet, da keine aufwendige Konfiguration von CPU, Arbeitsspeicher oder Speicherplatz notwendig ist. Alle Ressourcen werden im Paket bereitgestellt und müssen nicht einzeln ausgewählt werden.

Für kleinere Anwendungen oder Proof-of-Concepts ist dieses Modell oft ausreichend. Allerdings bleibt die tatsächlich genutzte Leistung schwer einschätzbar, was die Planung bei wachsenden Anforderungen erschwert. Trotzdem kann auch eine Datenbank mit DTU-Modell mit seinen Anforderungen einfach mitwachsen.

Das vCore-Modell schafft hier mehr Transparenz. CPU, Arbeitsspeicher und Speicherplatz können individuell konfiguriert werden. Dadurch ist eine gezielte Ressourcenplanung möglich, und moderne Hardware-Generationen wie Gen5 oder M-Serie stehen zur Verfügung. Mit dem Azure Hybrid Benefit lassen sich zudem vorhandene on-premise SQL Server Lizenzen nutzen, was die Kosten deutlich senken kann. Die Auswahl ist zwar aufwendiger, bietet aber mehr Kontrolle über Performance und Ausgaben.

Sowohl das DTU- als auch das vCore-Modell geben zunächst nur an, wie viele vCores und wie viel Arbeitsspeicher einer Datenbank zur Verfügung stehen. Was diese Angaben jedoch nicht verraten: Wie schnell tatsächlich auf den Speicher zugegriffen werden kann. Die I/O-Performance, gemessen in IOPS (Input/Output Operations per Second), ist ein entscheidender Faktor für die Gesamtleistung, wird aber nicht direkt durch die vCore- oder DTU-Zahl bestimmt. Hier lohnt sich ein genauer Blick auf die IOPS-Limits der jeweiligen Betriebsmodi und Service-Tiers, denn insbesondere zwischen Standard und Premium gibt es deutliche Unterschiede, die sich auf die Performance auswirken können.

In der Praxis empfiehlt es sich, zunächst mit dem DTU-Modell zu starten, um schnell produktiv zu werden. Auch ist der Einstieg mit dem DTU-Modell die preisgünstigste Option. Die niedrigste Stufe Basic ist bereits ab 5 Euro pro Monat verfügbar, während bei vCore die niedrigste Stufe mit General Purpose bei 345 Euro pro Monat beginnt. Auch ist die Skalierung auf die nächsten DTU-Stufen unkompliziert und ohne Downtime möglich.

Bei wachsender Auslastung oder besonderen Anforderungen sollte der Wechsel zum vCore-Modell frühzeitig in Betracht gezogen werden. Dieser ist auch im laufenden Betrieb möglich, erfordert jedoch gegebenenfalls eine kurze Downtime. Wer im DTU-Modell die Grenze von 200 DTU überschreitet oder mit dem Premium-Tier liebäugelt, sollte prüfen, ob das vCore-Modell nicht bereits jetzt die bessere und kostengünstigere Option ist.

Auch ist ein Mix-and-Match möglich. Im gleichen Azure SQL Server können sowohl DTU- als auch vCore-Datenbanken betrieben werden. Das ermöglicht eine flexible Anpassung an unterschiedliche Anforderungen, ohne gleich die gesamte Infrastruktur umstellen zu müssen. Bedenke hierbei aber trotzdem, wann ein separater Azure SQL Server zur logischen Trennung sinnvoll ist, statt alles in einen Server zu packen. Das kann z.B. bei unterschiedlichen Sicherheitsanforderungen oder Compliance-Vorgaben der Fall sein.

Skalierungsoptionen im DTU-Modell

Das DTU-Modell bietet verschiedene Betriebsmodi, die sich in Leistung und Kosten unterscheiden. Die DTU für Basic, Standard und Premium sind dabei nicht immer gleich, bedeutet eine 150 DTU in Standard ist nicht gleich einer 150 DTU in Premium. Diese unterscheiden sich in der Leistung, die sie bieten. So hat eine Standard-DTU eine andere Leistung als eine Premium-DTU was sich z.B. auf die IOPS auswirkt. Wer also eine IO-intensive Anwendung hat, sollte darauf achten, dass die gewählte DTU-Stufe auch die benötigte IOPS-Leistung bietet.

Im DTU-Modell variiert die IOPS-Leistung je nach Stufe (Basic, Standard, Premium) zwischen 1 und 25 IOPS pro DTU. Für viele Standardanwendungen ist das ausreichend, doch bei datenintensiven Workloads werden schnell Grenzen erreicht.

Skalierungsoptionen im vCore-Modell

Innerhalb des vCore-Modells stehen verschiedene Compute-Tiers zur Verfügung:

• Provisioned eignet sich besonders für Szenarien mit stabiler und vorhersehbarer Auslastung, da die Ressourcen fest zugewiesen werden und somit eine hohe Planungssicherheit bieten.

• Serverless ist optimal für variable Workloads, da die Datenbank bei Inaktivität automatisch pausiert und bei Bedarf skaliert. Diese Option empfiehlt sich vor allem für Entwicklungsumgebungen oder Anwendungen mit unregelmäßiger Nutzung. Wer hier also z.B. Nachts keinen Betrieb hat und bei wem die Datenbank nur 12 Stunden am Tag aktiv ist, halbiert die Kosten durch Serverless im Vergleich zu Provisioned.

Auch beim vCore-Modell gibt es Unterschiede zwischen den Betriebsmodi:

• General Purpose verwendet Shared Storage und eignet sich für die meisten Anwendungen, da es eine gute Balance zwischen Kosten und Leistung bietet. Die IOPS-Leistung ist hier auf 320 IOPS pro vCore begrenzt, was für viele Standardanwendungen ausreichend ist.

• Business Critical nutzt lokale SSDs und ermöglicht deutlich höhere IOPS, was besonders für transaktionsintensive Systeme vorteilhaft ist. Die IOPS Leistung liegt hier bei 4.000 IOPS pro vCore, was eine hohe Performance für datenintensive Anwendungen bietet.

• Hyperscale bietet mit Remote Storage, hoher Skalierbarkeit, schnellen Snapshots und Replikaten eine Lösung für besonders anspruchsvolle Szenarien und ermöglicht eine nahezu unbegrenzte Skalierung. Die IOPS-Leistung ist hier nahezu unbegrenzt, was es ideal für sehr große Datenbanken macht, die hohe Anforderungen an Performance und Skalierbarkeit stellen.

Managed Instances bieten nahezu den vollständigen Funktionsumfang eines klassischen SQL Servers, einschließlich SQL Agent, Linked Server und CLR. Sie eignen sich besonders für Migrationen aus lokalen Umgebungen, bei denen möglichst wenig an der bestehenden Architektur geändert werden soll.

Elastische Pools: Flexibilität und Effizienz für mehrere Datenbanken

Elastic Pools ermöglichen es, mehrere Datenbanken gemeinsam auf eine definierte Kapazität zugreifen zu lassen. Das funktioniert sowohl im DTU- als auch im vCore-Modell. Im DTU-Modell wird die Gesamtleistung in eDTUs angegeben, im vCore-Modell in dedizierten vCores und RAM. Besonders bei Anwendungen mit vielen Mandanten oder stark schwankender Last pro Datenbank ist das effizienter als Einzelinstanzen.

Dabei können beliebig viele Elastic Pools erstellt werden, die jeweils eine eigene Kapazität haben. Die harte Limitierung, wie viele Elastic Pools pro Azure SQL Server erstellt werden können, hängt von der Summe der eDTUs oder vCores über alle Pools ab. Diese dürfen nicht höher sein als die maximale Kapazität des Azure SQL Servers.

Ein großer Vorteil ist die automatische Lastverteilung: Datenbanken können sich bei Bedarf mehr Leistung aus dem Pool nehmen, solange andere weniger verbrauchen. Das reduziert Überprovisionierung und spart Kosten. Gleichzeitig lassen sich Grenzwerte pro Datenbank definieren, um einzelne Datenbanken zu schützen. Im vCore-Modell profitieren Nutzer zusätzlich vom Azure Hybrid Benefit und moderner Hardwareauswahl. Diese Flexibilität hat jedoch auch ihren Preis: Elastic Pools sind in der Regel teurer als Einzelinstanzen, bieten aber eine bessere Ressourcennutzung und Kosteneffizienz bei mehreren Datenbanken. Hier gilt es herauszufinden, ob die Last soweit schwankt, dass sich ein Elastic Pool lohnt.

Wenn Skalierung an Grenzen stößt

Jedes Modell stößt irgendwann an seine Grenzen. Mehr Leistung zu buchen reicht dann nicht mehr aus, denn auch der Skalierungs-Slider im Azure Portal hat irgendwann ein Ende. In solchen Fällen sind architektonische Anpassungen notwendig.

Sharding ist eine bewährte Methode für horizontale Skalierung. Dabei werden Daten gezielt auf mehrere Datenbanken verteilt, etwa nach Tenant, Region oder Funktionsbereich. Sowohl der Partitioning Key als auch die zu verteilenden Tabellen lassen sich flexibel festlegen.

Read-Only-Replikate bieten eine effektive Möglichkeit, die Hauptdatenbank zu entlasten. Sie eignen sich besonders für Anwendungen mit vielen Lesezugriffen wie Dashboards, Reporting oder APIs. In Business Critical oder Premium-Tiers lassen sich diese Replikate unkompliziert einrichten und sorgen für hohe Verfügbarkeit sowie geringe Latenz.

Ein Auto-Scaling gibt es nur beim Serverless-Mode. Bei den anderen Modellen muss die Skalierung manuell oder automatisiert über Skripte erfolgen. Dies kann z.B. über Azure Functions, Logic Apps oder Azure Automation realisiert werden.

Best Practices

Ein häufiger Fehler besteht darin, zu lange beim DTU-Modell zu bleiben. Sobald die Performance nicht mehr ausreicht, sollte nicht nur die DTU-Stufe erhöht werden. Es lohnt sich auch zu prüfen, ob ein Wechsel zum vCore-Modell sinnvoll ist. Dort lassen sich Ressourcen gezielt planen und durch den Azure Hybrid Benefit oft kostengünstiger betreiben. Auch klingt Hyperscale oder Business Critical wie etwas, was man sich aus Kostengründen nicht leisten kann. Diese Tiers können sich aber durchaus lohnen, wenn die Anwendung hohe Anforderungen an Performance und Skalierbarkeit stellt oder auch in Verbindung mit Elastic Pools, bei dem die Kosten durch mehrere Datenbanken geteilt werden.

Für Multitenancy-Szenarien bieten Elastic Pools in der Regel die bessere Lösung. Sie ermöglichen eine faire Ressourcennutzung und senken gleichzeitig die Betriebskosten. Bei Anwendungen mit vielen Lesezugriffen empfiehlt es sich, frühzeitig Read-Only-Replikate einzuplanen, besonders für Reporting- oder Analysezwecke, und diese richtig zu skalieren. Wie so oft gilt: Es wird mehr gelesen als geschrieben. Daher sollte die Datenbank so ausgelegt sein, dass sie auch bei hoher Last performant bleibt.

Ein weiterer Tipp ist, Sharding nicht erst dann einzuführen, wenn die Datenbank an ihre Grenzen stößt. Wer dieses Prinzip von Anfang an berücksichtigt, kann später einfacher skalieren.

Wie bei allen Resourcen in Azure, sollte Azure SQL über Infrastructure as Code verwaltet werden. Somit lassen sich auch Änderungen an der Architektur nachvollziehen und automatisiert umsetzen. Mit Tools wie Bicep lässt sich hier sehr einfach zwischen den verschiedenen Modellen wechseln und die Infrastruktur anpassen.

resource sqlDatabaseDtu 'Microsoft.Sql/servers/databases@2022-02-01-preview' = {
  name: '${sqlServer.name}/mydatabase'
  properties: {
    maxSizeBytes: 2147483648 // 2 GB
  }
  sku: {
    name: 'S0' // Standard S0 Tier = 10 DTU
    tier: 'Standard' // Standard Tier
    capacity: 10 // 10 DTU
  }
}

resource sqlDatabaseVcore 'Microsoft.Sql/servers/databases@2022-02-01-preview' = {
  name: '${sqlServer.name}/mydatabase-vcore'
  properties: {
    maxSizeBytes: 5368709120 // 5 GB
  }
  sku: {
    name: 'GP_Gen5_2' // General Purpose Gen5 with 2 vCores
    tier: 'GeneralPurpose' // General Purpose Tier
    family: 'Gen5' // Gen5 Hardware
    capacity: 2 // 2 vCores
  }
}

Fazit

Skalierung mit Azure SQL ist mehr als einfach nur mehr Leistung bereitzustellen. Entscheidend ist die Wahl des passenden Modells, ein fundiertes Verständnis der technischen Grenzen und eine vorausschauende Architekturplanung. Das DTU-Modell eignet sich für den schnellen Einstieg und das vCore-Modell bietet maximale Kontrolle. Wer langfristig erfolgreich skalieren möchte, sollte sowohl technische als auch strategische Aspekte im Blick behalten.

Wie hast du deine Azure SQL-Strategie bisher geplant und wo siehst du aktuell die größten Herausforderungen bei der Skalierung?

Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.