Azure SQL Database Managed Instance wurde Ende 2018 allgemein verfügbar. Seitdem haben viele Organisationen damit begonnen, zu Managed Instance zu migrieren, um die Vorteile einer verwalteten Umgebung zu nutzen. Unternehmen profitieren von verwalteten Backups, vielen integrierten Sicherheitsfunktionen, einer Betriebszeit-SLA von 99,99 % und einer stets aktuellen Umgebung, in der sie nicht mehr für das Patchen von SQL Server oder des Betriebssystems verantwortlich sind.
Eine Größe funktioniert nicht passen immer alle. Managed Instance bietet zwei Ebenen für die Leistung. Der allgemeine Zweck Tier ist für Anwendungen mit typischen Leistungs- und I/O-Latenzanforderungen konzipiert und bietet integrierte HA. Der Geschäftskritische Tier ist für Anwendungen konzipiert, die eine niedrige I/O-Latenz und höhere HA-Anforderungen erfordern. Business Critical stellt außerdem zwei nicht lesbare sekundäre und eine lesbare sekundäre bereit. Die lesbare sekundäre Instanz ist eine großartige Möglichkeit, die Arbeitslast von der primären zu verteilen, wodurch die für die primäre Instanz erforderliche Dienstebene gesenkt werden kann, wodurch die Gesamtausgaben für die Instanz gesenkt werden.
Als Managed Instance zum ersten Mal veröffentlicht wurde, konnten Sie zwischen Gen4- und Gen5-Prozessoren wählen. Gen4 wird immer noch in der Dokumentation beschrieben, aber diese Option ist jetzt größtenteils nicht verfügbar. In diesem Artikel werde ich nur Konfigurationen mit Gen5-Prozessoren behandeln.
Jede Dienstebene unterstützt zwischen 4 und 80 logische CPUs – auch bekannt als virtuelle Kerne oder virtuelle Kerne. Arbeitsspeicher wird mit ca. 5,1 GB pro virtuellem Kern zugewiesen. General Purpose bietet bis zu 8 TB leistungsstarken Azure Blob-Speicher, während Business Critical bis zu 4 TB superschnellen lokalen SSD-Speicher bietet.
Erinnerung
Mit nur 5,1 GB Arbeitsspeicher pro virtuellem Kern könnte eine Instanz mit weniger virtuellen Kernen Probleme haben. Die Optionen für virtuelle Kernkonfigurationen sind 4, 8, 16, 24, 32, 40, 64 und 80 virtuelle Kerne. Wenn Sie für jede der vCore-Optionen rechnen ((number of vCores) × (5.1 GB) ), erhalten Sie die folgenden Kern-/Speicherkombinationen:
4 vCores = 20.4 GB 8 vCores = 40.8 GB 16 vCores = 81.6 GB 24 vCores = 122.4 GB 32 vCores = 163.2 GB 40 vCores = 204.0 GB 64 vCores = 326.4 GB 80 vCores = 408.0 GB
Bei vielen Organisationen, denen ich beim Übergang von lokalen zu verwalteten Instanzen geholfen habe, habe ich eine erhebliche Verringerung des Arbeitsspeichers festgestellt. Typische lokale Konfigurationen wären 4 virtuelle Kerne und 32 GB Arbeitsspeicher oder 8 virtuelle Kerne und 64 GB. Beide machen mehr als 30 % weniger Speicher aus. Wenn die Instanz bereits unter Speicherdruck stand, kann dies zu Problemen führen. In den meisten Fällen konnten wir die lokale Instanz optimieren, um den Speicherdruck vor dem Wechsel zu einer verwalteten Instanz zu verringern, aber in einigen Fällen musste der Kunde eine höhere vCore-Instanz wählen, um den Speicherdruck zu verringern .
Speicherung
Speicher ist etwas schwieriger zu planen und zu berücksichtigen, da mehrere Faktoren berücksichtigt werden müssen. Beim Speicher müssen Sie den Gesamtspeicherbedarf sowohl für die Speichergröße als auch für die E/A-Anforderungen berücksichtigen. Wie viele GB oder TB werden für die SQL Server-Instanz benötigt und wie schnell muss der Speicher sein? Wie viele IOPS und wie viel Durchsatz verwendet die lokale Instanz? Dazu müssen Sie Ihre aktuelle Workload anhand von perfmon berechnen, um durchschnittliche und maximale MB/s zu erfassen, und/oder Snapshots von sys.dm_io_virtual_file_stats erstellen, um die Durchsatzauslastung zu erfassen. Dadurch erhalten Sie eine Vorstellung davon, welche Art von E/A und Durchsatz Sie in der neuen Umgebung benötigen. Mehrere Kunden, mit denen ich zusammengearbeitet habe, haben diesen wichtigen Teil der Migrationsplanung verpasst und sind auf Leistungsprobleme gestoßen, weil sie eine Instance-Ebene ausgewählt haben, die ihre Workload nicht unterstützt.
Dies ist für die Baseline von entscheidender Bedeutung, da es bei lokalen Servern üblich ist, Speicher von einem superschnellen SAN mit hohen Durchsatzfähigkeiten für kleinere virtuelle Maschinen bereitzustellen. In Azure werden Ihre IOPS- und Durchsatzlimits durch die Größe des Computeknotens und im Fall von „Instanz verwalten“ durch die Anzahl der zugewiesenen virtuellen Kerne bestimmt. Für allgemeine Zwecke gilt je nach Dateigröße ein Limit von 30-40.000 IOPS pro Instanz oder 500 bis 12.500 IOPS pro Datei. Der Durchsatz pro Datei basiert auch auf der Größe und reicht von 100 MiB/s für bis zu 128 GB Dateien und bis zu 480 MiB/s für 4 TB und größere Dateien. In Business Critical reichen die IOPS von 5,5 K bis 110 K pro Instanz oder 1.375 IOPS pro virtuellem Kern.
Verbraucher müssen auch den Protokollschreibdurchsatz für die Instanz berücksichtigen. „Allgemein“ beträgt 3 MB/s pro virtuellem Kern mit einem Maximum von 22 MB/s für die Instanz und „Geschäftskritisch“ beträgt 4 MB/s pro virtuellem Kern mit einem Maximum von 48 MB/s für die gesamte Instanz. Nach meiner Erfahrung in der Zusammenarbeit mit Kunden haben viele diese Grenzen für den Schreibdurchsatz weit überschritten. Für einige war es ein Showstopper, und für andere konnten sie ihr System optimieren und modifizieren, um die Last zu verringern.
Neben der Kenntnis des Gesamtdurchsatzes und der E/A-Anforderungen ist die Speichergröße auch an die Anzahl der ausgewählten virtuellen Kerne gebunden. Für allgemeine Zwecke:
4 vCores = 2 TB max
8 - 80 vCores = 8 TB max
Für geschäftskritische Personen:
4 – 16 vCores = 1 TB
24 vCores = 2 TB
32 - 80 vCores = 4 TB
Für allgemeine Zwecke können Sie, sobald Sie 8 virtuelle Kerne erreicht haben, den verfügbaren Speicher maximieren, was gut für diejenigen funktioniert, die nur allgemeine Zwecke benötigen. Aber wenn Sie Business Critical benötigen, können die Dinge herausfordernder sein. Ich habe mit vielen Kunden zusammengearbeitet, die VMs mit 4, 8, 16 und 24 logischen Prozessoren mehrere TB zugewiesen haben. Jeder dieser Kunden müsste mindestens 32 virtuelle Kerne nach oben verschieben, nur um seinen Speicherbedarf zu decken, eine kostspielige Option. Azure SQL-Datenbank hat ein ähnliches Problem mit der maximalen Datenbankgröße, und Microsoft hat eine Hyperscale-Option entwickelt. Wir gehen davon aus, dass dies irgendwann eine Option für verwaltete Instanzen wird, um die Speicherbeschränkungen auf ähnliche Weise anzugehen.
Die Größe von tempdb korreliert auch mit der Anzahl der virtuellen Kerne. Im Tarif „Allgemein“ erhalten Sie 24 GB pro virtuellem Kern (bis zu 1.920 GB) für die Datendateien, mit einer Größenbeschränkung für tempdb-Protokolldateien von 120 GB. Für die Business Critical-Ebene kann tempdb bis zur aktuell verfügbaren Instance-Speichergröße wachsen.
In-Memory-OLTP
Beachten Sie für diejenigen, die derzeit In-Memory-OLTP nutzen (oder dies planen), dass es nur in der Dienstebene „Unternehmenskritisch“ unterstützt wird. Der verfügbare Speicherplatz für In-Memory-Tabellen wird auch durch virtuelle Kerne begrenzt:
4 vCores = 3.14 GB
8 vCores = 6.28 GB
16 vCores = 15.77 GB
24 vCores = 25.25 GB
32 vCores = 37.94 GB
40 vCores = 52.23 GB
64 vCores = 99.90 GB
80 vCores = 131.86 GB
Schlussfolgerung
Bei der Planung einer Migration zu Azure SQL Managed Instance müssen mehrere Überlegungen berücksichtigt werden, bevor Sie sich für eine Migration entscheiden. Zuerst müssen Sie Ihre Arbeitsspeicher-, CPU- und Speicheranforderungen vollständig verstehen, da dies die Größe der Instanz bestimmt. Genauso wichtig ist es, Ihre Speicher-E/A-Anforderungen zu kennen. IOPS und Durchsatz für die allgemeine Ebene sind direkt an virtuelle Kerne und die Größe der Datenbankdateien gebunden. Für Business Critical ist es an die Anzahl der virtuellen Kerne gebunden. Wenn Sie eine sehr E/A-intensive Workload haben, ist Business Critical die attraktivere Serviceebene, da sie höhere IOPS- und Durchsatzzahlen bietet. Die Herausforderung bei Business Critical ist die geringere Speicherkapazität und die Unterstützung von nur 1 TB für die gesamte Instanz mit bis zu 16 virtuellen Kernen.
Bei richtiger Planung und möglicher Dekonsolidierung größerer Instanzen zu kleineren verwalteten Instanzen kann dieses Angebot für viele Unternehmen eine sehr praktikable Migrationsoption sein. Der Reiz liegt in den Vorteilen verwalteter Backups, integrierter Hochverfügbarkeit mit einem SLA von 99,99 %, zusätzlichen Sicherheitsfunktionen und -optionen und der Notwendigkeit, sich keine Gedanken über das Patchen eines Betriebssystems oder einer SQL Server-Instanz machen zu müssen.
