2 つのクラスターを設定します。1 つは開発用、もう 1 つは本番用です。本番環境では、OLTP と DW の 2 つの SQL インスタンスをホストします。
開発では、4 つの OLTP 非本番環境と少なくとも 1 つの DW 非本番環境をホストします。私たちは、より多くの DW 非本番環境と、おそらくより多くの OLTP システムを取得することに取り組んでいます。
私は、PROJ がプロジェクト名の 3 つの頭文字になるような命名スキームを検討しています。
開発クラスター
- MSSQLPROJD1\D1 (開発)
- MSSQLPROJD2\D2 (テスト)
- MSSQLPROJD3\D3 (品質保証)
- MSSQLPROJD4\D4 (ステージ)
- MSSQLPROJD5\D5 (DW)
Prd クラスター
- MSSQLPROJP1\P1 (PRD)
- MSSQLPROJP2\P2 (DW)
スラッシュの左側にある各名前は、ネットワーク全体で一意である必要があります。各サーバーでは、スラッシュの右側にあるインスタンス名が一意である必要があります。
これについて何かご意見はありますか? プロジェクトの進行に伴ってインスタンス名が現実から外れないようにしています。たとえば、特定の環境の呼び方を変更したり、環境の目的を変更したりする場合などです。その後、インスタンスの目的のリストを更新して、作業を完了できます。
このような計画はあなたにとってどのようにうまくいきましたか? おそらくあなたのお店では別の方法で物事を行っているのでしょう。それについて教えてください。
ありがとう。
改訂2
開発クラスター
- SQLERPD1\D1 (開発版)
- SQLERPD2\D2 (テスト)
- SQLERPD3\D3 (品質保証)
- SQLERPD4\D4 (ステージ)
- SQLERPD10\D10 (DWDev)
- SQLERPD11\D11 (DWテスト)*
Prd クラスター
- SQLERPP1\P1 (PRD)
- SQLERPP10\P10 (DW)
*期待はしていますが、現時点では仕様は決まっていません。
答え1
人々が使用する命名規則は無数にあります。使用する規則が自分の環境で長期的に機能する限り、正しい規則や間違った規則というものは実際にはありません。命名規則を選んだ後で変更しなければならないのは、最悪の事態です。
考慮すべき点は、別の開発クラスター、または別の本番クラスターを追加した場合に、この規則がどのように機能するかということです。引き続き適切に拡張できますか?
個人的には、このような命名規則を使用するのが好きです。必要に応じて、サイト名などで簡単に変更できます。
物理マシン:
SQL01A
SQL01B
Windows クラスター名:
SQL01
SQL 仮想名:
SQL01V01
SQL01V02\INST1
SQL01V02\INST2
こうすることで、サーバーにログオンして確認しなくても、仮想名がどの物理マシンに属しているかをすばやく簡単に確認できます。また、別のクラスターを追加すると、以下に示すようなスケールにうまく拡張されます。クラスターを簡単に追加でき、複雑な手順を踏むことなく、任意のクラスターにインスタンスを追加できます。
物理マシン:
SQL02A
SQL02B
Windows クラスター名:
SQL02
SQL 仮想名:
SQL02V01
SQL02V02\INST1
SQL02V02\INST2