Windows管理者は、Windowsサーバーのクローンを作成する方法に問題があることを確認しました。どうやら、クローンされたサーバーの一部は、OSレベルで同じSIDになってしまいます。 MicrosoftはSIDが重複しているサーバーをサポートしていないと聞きました。したがって、これらのサーバーのSIDを変更する必要があります。
それがSQL Serverにどのように影響するか知りたいです。何か案は?クラスタ化されたデータベースサーバーにどのような影響がありますか?
SIDはそのままにしておきます。 Mark Russinovichがいくつかの掘り下げを行った結果、「SIDの重複==悪い」と判明したため、NewSIDは廃止されました。過去10年間に私たち全員が頭蓋骨にぶつかってしまったラインは、単なるナンセンスの負荷です。
Markの最新のブログエントリ The Machine SID Duplication Myth を参照してください。
NewSIDを使用してマシンのSIDを変更するとSQL Serverが壊れる(そしてそれを修正する方法)
どうやら、クローンされたサーバーの一部は、OSレベルで同じSIDになってしまいます。
クローンされたすべてのシステムが同じSIDを持っていると推測すると危険です。 GhostWalkはSIDを再生成します。最初のクローンイメージでsysprepを使用すると、将来のシステムでも節約できます。
SQL Serverをインストールした場合SIDを変更しないでください。悪いことが起こります。
現在Microsoftが所有しているツール NewSID またはsysprepを使用します。これは、ファイルをすべてコピーせずにウィンドウを再インストールするようなものです。
2台のコンピューターを同じSIDの同じドメインに参加させることはできないと思います。サーバーがドメイン上にある必要があるため、クラスター化されたSQL Serverはチャンスに耐えられないと思います。
データベースがMicrosoft分散トランザクションコーディネーターを使用してリモートトランザクションを実行する場合、クローンされたマシンも同じMSDTC IDを持っていることに注意してください。これはSIDではなく、NewSIDによって変更されません。
これはイベントビューアに表示されます。
ローカルMS DTCは、サーバー上のMS DTCがローカルMS DTCと同じ一意のIDを持っていることを検出しました。これは、2つのMS DTCが互いに通信できないことを意味します。この問題は通常、サポートされていない複製ツールを使用してシステムの1つが複製された場合に発生します。 MS DTCでは、SYSPREPなどのサポートされている複製ツールを使用してシステムを複製する必要があります。コマンドプロンプトから「msdtc -uninstall」を実行してから「msdtc -install」を実行すると、問題が解決します。注: 'msdtc -uninstall'を実行すると、システムですべてのMS DTC構成情報が失われます。
私はそれを次のように解決します:
msdtc -uninstall
数分待ってから
msdtc -install
sc config msdtc start= auto
sc start msdtc
Sysinternals NewSIDを使用できます: http://technet.Microsoft.com/en-us/sysinternals/bb897418.aspx
SQLでコンピューター名を変更します。
use master
sp_dropserver '<old computer name>'
GO
sp_addserver '<new computer name>', local
GO
sp_helpserver -- will show you the new computer name
次に、SQLサーバーサービスを再起動します。
システムのクローンを作成するためにサポートされている唯一の方法は、sysprepを使用することです。 SQLサーバーを複製しない理由はたくさんあります。
-Microsoft CSSではサポートされていません。
-SQLは、名前が変更されるまで正しく機能しません。
-あなたがレポートサービスを持っている場合、それは同様にホースになります。
-システムサービスアカウントとネットワークサービスアカウントは新しいSIDとパスワードを取得するため、これらをサービスアカウントとして使用した場合、いくつかの問題があります。
-SQL Serverは、この形式で適切なローカルグループをいくつか作成します。 SQLServer2005MSSQLUser $$ MSSQLSERVER。これらの名前を変更することはサポートされていません
状況を正すために、私は-
クラスターを解除し、システムを再構築し、SQLをインストールし、新しいクラスターを作成し、再構築されていないサーバーでバックアップを実行します。その後、停止し、そのバックアップを新しいクラスターに復元し、アプリケーションを新しいクラスターにポイントして、残りを再構築しますサーバーと新しいクラスターに追加します
-代わりに(おそらくより簡単)新しい名前で新しいサーバーを構築しないでください(これにより、あらゆるタイプのSIDの潜在的な問題が解決されます)。その後、クラスターを中断し、SQLをクラスターに結合し、そのボックスにフェールオーバーしてから、プロセスを繰り返します。ダウンタイムがなく、バックアップ/復元の必要もありません(とにかく、そうすることをお勧めします)。 zznode1、zznode2、およびクラスター名を使用してzznode3を作成し、それをクラスターに参加させるのは、クラスター内ではノードが参照されないため、簡単です。お役に立てば幸いです。