Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:
Azure SQL Managed Instance
Dieser Artikel hilft Ihnen bei der Ermittlung der geeigneten Subnetzgröße und des IP-Adressbereichs für Azure SQL Managed Instance.
Übersicht
Azure SQL Managed Instance besteht aus Dienstkomponenten, die auf einer dedizierten Gruppe isolierter virtueller Computer gehostet werden, die in einer oder mehreren virtuellen Computergruppen (VM) gehostet werden, die von einem virtuellen Cluster gehostet und in einem virtuellen Azure-Netzwerk bereitgestellt werden.
Ein virtueller Cluster, der einem einzelnen Subnetz in einem virtuellen Netzwerk zugeordnet ist, kann eine oder mehrere von SQL Managed Instance hosten. Die Anzahl der Instanzen, die im Subnetz bereitgestellt werden können, hängt von der Größe des Subnetzes (dem Subnetzbereich) ab.
Wenn Sie eine von SQL verwaltete Instanz erstellen, weist Azure die Anzahl der virtuellen Computer basierend auf der ausgewählten Dienstebene zu. Da diese virtuellen Computer Ihrem Subnetz zugeordnet sind, benötigen sie IP-Adressen. Azure kann mehr virtuelle Computer zuweisen, um eine hohe Verfügbarkeit während regulärer Vorgänge und Wartung von Diensten sicherzustellen. Die Anzahl der erforderlichen IP-Adressen in einem Subnetz ist normalerweise größer als die Anzahl der SQL Managed Instance in diesem Subnetz.
Bestimmen der Subnetzgröße
Planen Sie die Subnetzgröße für die Bereitstellungen verwalteter Instanzen sorgfältig.
Gemäß dem Design benötigt jede SQL Managed Instance mindestens 32 IP-Adressen in einem Subnetz. Sie können bei der Definition der IP-Adressbereiche für das Subnetz die Subnetzmaske /27 (Mindestgröße) verwenden.
Verwenden Sie die folgende Liste der Überlegungen, wenn Sie die Größe Ihres Subnetzes bestimmen:
- Überlegungen im Zusammenhang mit Instanzen:
- Die Anzahl der verwalteten SQL-Instanzen
- Die Dienstebene der Instanzen
- Überlegungen zu virtuellen Clustern:
- Hardwarekonfigurationen
- Konfigurationen des Wartungsfensters
- Überlegungen im Zusammenhang mit Verwaltungsvorgängen:
- Pläne zum Hoch- oder Herunterskalieren oder zum Ändern der Dienstebene, der Hardwarekonfiguration oder des Wartungsfensters
Verwenden Sie die folgenden Parameter, um eine Berechnung zu erstellen:
- Azure benötigt fünf IP-Adressen im Subnetz für den eigenen Bedarf.
- Jede VM-Gruppe weist sechs weitere Adressen zu.
- Die Anzahl der Adressen, die von jeder verwalteten SQL-Instanz verwendet werden, hängt von der Dienstebene ab.
- Die verwaltete SQL Managed Instance mit allgemeinem Zweck verwendet drei Adressen.
- Die unternehmenskritische SQL Managed Instance verwendet fünf Adressen.
- Jede Skalierungsanforderung verdoppelt vorübergehend die Anzahl der Adressen, die für die Instanz zugeordnet sind, die skaliert wird.
Wichtig
Das Ändern des Subnetzadressbereichs wird nicht unterstützt, wenn Ressourcen im Subnetz vorhanden sind. Aus diesem Grund ist es besser, größere Subnetze anstelle kleinerer Subnetze zu verwenden, um zukünftige Probleme zu vermeiden.
Instanz mit einer bereitstellungsbasierten Bereitstellung
Die folgende Tabelle zeigt die Anzahl der IP-Adressen, die für eine einzelne Instanz in einem Subnetz erforderlich sind, das auf jeder Dienstebene bereitgestellt wird:
| Dienstebene | Azure-Nutzung1 | VM-Gruppennutzung2 | Instanznutzung | Zonenredundanz (ZR) | Insgesamt3 |
|---|---|---|---|---|---|
| Universell | 5 | 8 | 2 | 0 | 15 |
| Unternehmenskritisch | 5 | 8 | 5 | 2 | 18 (20 mit ZR) |
1 Von Azure verwendete Adressen werden für alle Instanzen im Subnetz freigegeben.
2 Adressen, die von der VM-Gruppe verwendet werden, werden für Instanzen freigegeben, die innerhalb derselben Gruppe platziert sind.
3 Die Gesamtanzahl der von der Instanz verwendeten Adressen. Zusätzliche IP-Adressen werden zugewiesen, wenn Zonenredundanz für Instanzen auf der Business Critical-Dienstebene aktiviert ist.
Das Hinzufügen von Instanzen zum Subnetz erhöht die Anzahl der von der Instanz verwendeten Adressen und erhöht daher die Gesamtanzahl der Adressen.
Subnetze mit mehreren Instanzen
Die Formel in diesem Abschnitt berechnet die Anzahl der Adressen, die für mehrere Instanzen in einem Subnetz erforderlich sind. Die Formel berücksichtigt das Potenzial, während einer nachfolgenden Instanz neue VM-Gruppen zu erstellen oder zu aktualisieren, sowie das Wartungsfenster und die Hardwareanforderungen virtueller Cluster.
Verwenden Sie die folgende Formel, um die Gesamtanzahl der IP-Adressen basierend auf der Anzahl der Instanzen zu berechnen:
5 + (gp * 4) + (bc * 10) + (bc_zr * 2) + (vmg * 8) Dabei gilt Folgendes:
- gp = Anzahl der General Purpose-Instanzen
- bc = Anzahl der geschäftskritischen Instanzen
- bc_zr = Anzahl der zonenredundanten geschäftskritischen Instanzen
- vmg = Anzahl verschiedener VM-Gruppen
In der folgenden Liste werden die in der Formel verwendeten Zahlen erläutert:
- 5 Anzahl der von Azure reservierten IP-Adressen
- 4 Adressen pro General Purpose-Instanz (2 für die erste Bereitstellung, 2 für einen eventuellen Skalierungsvorgang)
- 10 Adressen pro Business Critical-Instanz (5 für die erste Bereitstellung, 5 für einen eventuellen Skalierungsvorgang)
- 8 Adressen pro VM-Gruppe
Wichtig
Da es eine Beschränkung auf die Anzahl virtueller Computer gibt, die einer Gruppe beitreten können, kann ein Mangel an Speicherplatz in einer vorhandenen Gruppe dazu führen, dass eine VM-Gruppe mit identischen Spezifikationen erstellt wird. Es ist möglich, dass ein Subnetz mit einer großen Anzahl von Instanzen mehrere VM-Gruppen mit derselben Konfiguration hat, die 9 VM-Gruppen überschreiten.
Beispiel 1
Sie planen, drei universelle und zwei geschäftskritische verwaltete Instanzen im selben Subnetz bereitzustellen. Alle Instanzen verfügen über das gleiche Wartungsfenster, werden in derselben Hardwarekonfiguration ausgeführt, und keines ist zonenredundant.
Durch das Substituieren dieser Werte in die Formel wird die folgende Formel zurückgegeben: 5 + (3 * 4) + (2 * 10) + 0 + (1 * 8) = 45
Da IP-Bereiche in Zweierpotenzen definiert sind, benötigt Ihr Subnetz einen minimalen IP-Bereich von 64 (2^6), um 45 IP-Adressen zu unterstützen, für diese Implementierung. Reservieren Sie das Subnetz mit der Subnetzmaske /26.
Beispiel 2
Sie planen die Bereitstellung von insgesamt sieben Instanzen im selben Subnetz, vier allgemeine und drei geschäftskritische Instanzen. Drei sind Entwicklungs-/Testinstanzen, die auf Standard-Serie-Hardware mit einem Standardwartungsfenster (VM-Gruppe 1) ausgeführt werden, während die verbleibenden vier in der Produktion sind und auf Premium-Serienhardware mit einem Wochenendwartungsfenster (VM-Gruppe 2) ausgeführt werden. Zwei der Business-Critical-Instanzen sind zonenredundant.
Durch das Substituieren dieser Werte in die Formel wird die folgende Formel zurückgegeben: 5 + (4 * 4) + (3 * 10) + (1 * 2) + (2 * 8) = 69
Da IP-Bereiche in Potenzen von 2 definiert sind, benötigt Ihr Subnetz einen mindestens benötigten IP-Bereich von 128 (2^7), um die 69 IP-Adressen zu unterstützen, für diese Bereitstellung. Sie müssen das Subnetz mit der Subnetzmaske /25 reservieren.
Achtung
Obwohl Sie Instanzen in einem Subnetz bereitstellen können, das kleiner als die berechnete Größe ist, können Sie dadurch verhindern, dass Sie Instanzen hinzufügen oder Skalierungs- und Wartungsvorgänge abschließen, die temporäre IP-Adressen erfordern. Um Dienstunterbrechungen zu vermeiden, reservieren Sie ein größeres Subnetz als das Minimum, und planen Sie zukünftiges Wachstum, zusätzliche VM-Gruppen und temporäre Erhöhungen der IP-Nutzung während bestimmter Vorgänge.
Updateszenarien
Bei einem Skalierungsvorgang erfordern Instanzen vorübergehend zusätzliche IP-Kapazität, die von der Dienstebene abhängt.
Die folgende Tabelle zeigt die temporäre Anzahl zusätzlicher IP-Adressen, die für einen Skalierungsvorgang erforderlich sind, für den keine neue VM-Gruppe erstellt werden muss:
| Dienstebene | Szenario | Zusätzliche Adressen |
|---|---|---|
| GP | Skalieren von virtuellen Kernen | 2 |
| GP | Skalieren des Speichers | 0 |
| GP | Wechseln zu unternehmenskritisch | 5 |
| V. Chr | Skalieren von virtuellen Kernen | 5 |
| V. Chr | Skalieren des Speichers | 5 |
| V. Chr | Wechseln zu universell | 2 |
Vorgänge, die zum Erstellen einer neuen VM-Gruppe führen, z. B. das Ändern eines Hardwaregenerierungs- oder Wartungsfensters, erfordern zusätzliche 6 permanente Adressen für die neue Gruppe.