SQL-Clusterinstanznamen für große Projekte

SQL-Clusterinstanznamen für große Projekte

Wir richten zwei Cluster ein. Einen Entwicklungs- und einen Produktionscluster. Der Produktionscluster wird zwei SQL-Instanzen hosten – einen OLTP und einen DW.

Die Entwicklung wird 4 OLTP-Nichtproduktionsumgebungen und mindestens eine DW-Nichtproduktionsumgebung hosten. Wir arbeiten daran, mehr DW-Nichtproduktionsumgebungen und möglicherweise mehr OLTP-Systeme zu erhalten.

Ich denke über ein Benennungsschema wie dieses nach, bei dem PROJ aus drei Initialen für den Projektnamen bestünde.

Entwicklungscluster

  • MSSQLPROJD1\D1 (DEV)
  • MSSQLPROJD2\D2 (TEST)
  • MSSQLPROJD3\D3 (Qualitätssicherung)
  • MSSQLPROJD4\D4 (STAGE)
  • MSSQLPROJD5\D5 (DW)

Prd-Cluster

  • MSSQLPROJP1\P1 (PRD)
  • MSSQLPROJP2\P2 (DW)

Links vom Schrägstrich muss jeder Name netzwerkweit eindeutig sein. Auf jedem Server muss der Instanzname rechts vom Schrägstrich eindeutig sein.

Irgendwelche Gedanken dazu? Ich versuche zu vermeiden, dass die Instanznamen im Verlauf des Projekts von der Realität abweichen – sagen wir, wir ändern, was wir einer bestimmten Umgebung nennen, oder wollen eine Umgebung einem anderen Zweck zuweisen. Dann können wir eine Liste der Zwecke der Instanzen aktualisieren und fertig.

Wie hat sich ein solches System für Sie bewährt? Vielleicht machen Sie es in Ihrem Geschäft anders – erzählen Sie mir davon.

Danke.


rev2

Entwicklungscluster

  • SQLERPD1\D1 (DEV)
  • SQLERPD2\D2 (TEST)
  • SQLERPD3\D3 (Qualitätssicherung)
  • SQLERPD4\D4 (STAGE)
  • SQLERPD10\D10 (DWDev)
  • SQLERPD11\D11 (DWTest)*

Prd-Cluster

  • SQLERPP1\P1 (PRD)
  • SQLERPP10\P10 (DW)

*erhofft, aber derzeit noch nicht spezifiziert.

Antwort1

Es gibt Millionen verschiedener Benennungsstandards, die von Menschen verwendet werden. Es gibt nicht wirklich einen richtigen oder falschen Standard, solange der von Ihnen verwendete Standard in Ihrer Umgebung langfristig funktioniert. Das Schlimmste, was Sie tun müssen, ist, Ihre Benennungskonvention zu ändern, nachdem Sie sich für eine entschieden haben.

Denken Sie darüber nach, wie diese Konvention funktioniert, wenn Sie einen weiteren Dev-Cluster oder einen weiteren Prod-Cluster hinzufügen. Ist die Skalierbarkeit weiterhin gut?


Persönlich verwende ich gerne eine Namenskonvention wie diese. Sie können diese bei Bedarf problemlos mit Site-Namen usw. ändern.

Physische Maschinen:

SQL01A
SQL01B

Der Windows-Clustername:

SQL01

Die virtuellen SQL-Namen:

SQL01V01
SQL01V02\INST1
SQL01V02\INST2

Auf diese Weise können Sie schnell und einfach sehen, zu welchen physischen Maschinen ein virtueller Name gehört, ohne sich dafür beim Server anmelden zu müssen. Und es lässt sich gut skalieren, wenn Sie einen weiteren Cluster hinzufügen, der zu dem wird, was ich unten gezeigt habe. Sie können problemlos weitere Cluster hinzufügen, Sie können jedem Cluster weitere Instanzen hinzufügen, ohne dass die Dinge komplizierter werden.

Physische Maschinen:

SQL02A
SQL02B

Der Windows-Clustername:

SQL02

Die virtuellen SQL-Namen:

SQL02V01
SQL02V02\INST1
SQL02V02\INST2

verwandte Informationen