すべてにご挨拶。
この記事では、「鉄」MSCSクラスターを仮想サーバーに変換した経験を説明します。
私たちのクラスターは2008年から稼働しており、重要なタスクを含む多くのタスクが蓄積されており、新しいサーバーを作成するのは非現実的でした。 さらに、使い古された機器が故障しそうでした。 私たちにとって、たった一つの方法しかありませんでした-VMwareのデータセンターでのサーバー仮想化。 そして、私にとってタスクは設定されました-クラスタリングから逃れるために。 ネットワークに関する多くの情報を調べたが、適切な段階的な指示が見つからなかったため、自分で作成することにしました。
初期状態は次のとおりです。
- Windows 2003 Enterprise Edition SP2上のMSCSクラスター。 Active \ Passiveモードの2つのノード。
- クラスタモードのSQL Server 2005 Standard Edition
- クラスターモードではなく、IIS上のいくつかのWWW / FTPサイト。 32のWebサイトのそれぞれには、1つのIPアドレスクラスターリソースがあります。 大まかに言って、追加のIPがネットワークカードにハングアップしました。 サイトはイントラネットでのみ機能しました。
- 9個の論理データディスク、152個のファイル共有リソース、すべてのデータはディスクアレイに保存されます。
- 構成されたタスクスケジューラを介して、業界固有のいくつかのプログラムが起動されました。
サーバーの準備とテストのために、仮想の「実験室」を作成しました。
クラスターのアクティブノードの仮想コピー、ドメインコントローラーの仮想コピー、すべてテストするWindows 7を搭載した通常のコンピューターの3つのコンピューターを分離された仮想ネットワークに接続しました。 SQLデータベース、www / ftpサイト、ネットワークフォルダー、およびクォーラムディスクを備えたいくつかのディスクは、事前にVMDKに変換されました。
マシンを起動し、実際のネットワークと同じTCP / IPパラメーターでネットワークカードを構成します。 ディスクをサーバーに接続し、適切な文字を割り当てて、再起動します。 その後、クラスターが起動します。 ちなみに、シングルノードモードでは、クラスターはすぐに動作を開始しましたが、特に仮想環境ではこのような構成が正しく動作しないリスクがあるため、クラスターは必要なくなりました。
次に、ネットワークカードの設定とネットワークリソースの設定を次のように保存する必要があります。 クラスタサービスを削除した後、それらを手動で復元する必要があります。 以前にnetshコマンドを使用してTCP / IP設定のダンプを準備しました。 「net share」コマンドを使用してネットワークリソースを再作成する予定でした。 ネットワークボールの設定をバックアップする方法があるかもしれませんが、見つけられませんでした。
そのため、ip.cfgおよびshares.txtファイル（ネット共有コマンドリスト）があります。 障害が発生した場合にロールバックするために、スナップショットを作成します。
クラスター解除を開始
- バーチャルコピーを開始すると、2番目のクラスターノードは使用できなくなります。 Evict Nodeチームで削除します。
このようなメッセージが表示される場合がありますが、ここではオプションなしで[OK]をクリックします。
- 次に、SQLを構成します。 正常に起動するために必要です。 インターネットにある手順では、データベースのコピーを作成し、クラスター化されたインスタンスを削除してから、スタンドアロンインスタンスをインストールすることをお勧めします。 レジストリを介してより簡単な方法を見つけました：
ブランチを削除する
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SQL Server \ MSSQL.1 \クラスター
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SQL Server \ MSSQL.2 \クラスター
キーを変更する
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SQL Server \ MSSQL.1 \ Setup \ SqlCluster = 0
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SQL Server \ MSSQL.2 \ Setup \ SqlCluster = 0
SQL Server構成マネージャーで、サービスを自動実行に設定します。
- サービスWWW Publishing Service、自動実行用のタスクスケジューラが含まれています。 以前は、アクティブノードでのみ手動で開始されていました。
- クラスターから最後のノードを削除します。 その後、IPアドレスやファイル共有などのクラスターリソースはシステムから完全に削除されます。
- ユーザーがネットワークフォルダーを通常どおり操作できるように、レジストリを再度編集します。
レジストリキーHKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ LanmanServer \ Parameters
値が1のDWORDパラメーター「DisableStrictNameChecking」を追加します
- ネットワーク設定を復元します。
Netsh exec c：\ ip.cfg
- テキストファイルshares.txtからネットワークリソースを復元します。 コマンドをコピーして、cmdに貼り付けるだけです。 コウモリのニックネームを作成しようとしましたが、リソースの説明にロシア語の文字を表示する際に問題がありました。
- サーバーを再起動します。 その後、ラボ内のすべてのftp-、www-、share-resourcesの動作を確認します。
すべてが正常である場合、仮想サーバーは通常のネットワークに移行する準備ができています。
移行について簡単に
ここのニュアンスは異なる場合がありますが、原則は同じです。鉄クラスターを無効にし、リソースと設定を新しいサーバーに転送して有効にする必要があります。 私の場合、リソースはIPアドレス、論理データドライブ、ネットワークボールです。
ネットワークとADから鉄クラスターを完全に削除しなかったため、障害が発生した場合にすべてを戻すことができました。
私たちの行動：
- ネットワークとドライブから鉄クラスターを切断します。 IPアドレスは解放されます。
- データの合計量は1.5 TBであるため、すべてのディスクを一度にVMDKに転送することはできず、情報は常に更新されます。 それらを一時的にRDMとして仮想サーバーに接続し、移行中のダウンタイムを削減することにしました。 経験からわかるように、電源を切ったマシンに接続することをお勧めします。 開始後、これらのディスクに古いクラスターと同じ文字を割り当てる必要があります。たとえば、ドライブSから開始されたSQLサーバーベースがあります。
- 一般的なネットワークに仮想サーバーを含め、再起動します。
再起動後、FTP、WWWサービス、およびSQLは正常に機能しました。 すべてのアクションに1時間弱かかりました。
しばらくして、一部のユーザーが古いクラスター名を使用してログインできない場合、ネットワークボールでグリッチが発生しました。 可能な修正：
- 指示のパラグラフ5への準拠を確認してください。
- クラスタ名の古いWINSサーバーエントリを削除する
- ADでMSCSクラスターを展開すると、最初と2番目のノードのアカウントに加えて、クラスター名を持つ3番目のアカウントが作成されます。その説明は「サーバークラスター仮想ネットワーク名アカウント」です。 このアカウントは無効にする必要があります。
- DNSでは、最初のノードのクラスターの名前にエイリアスが作成されます。
現時点では、仮想サーバーは正常に動作しています。 グリッチは観察されません。 これで、2015年の新年バージョンを安全に祝うことができます。ご清聴ありがとうございました。