ここで完全に明確に説明できない場合はお許しください。意図的ではありません。私は現在、マネージャーのように行動しなければならない非常に小さな会社の上級レベルの開発者です。
とにかく、話は、SQL Server 2008 Standard を搭載した 2 台の古い Dell サーバーが「クラスター」にあるということです。それが何を意味するのかまだ 100% 明確ではないので、引用符で囲みました。私たちは 2 台の新しいブレード サーバーを持っており、既存のデータベースを新しいハードウェアに移動したいと考えています。
さて、ここで問題があります。ダウンタイムをほとんどまたはまったく発生させずにこれを実行する必要があります。パッシブ ノードを削除してから、新しいサーバーの 1 つを導入できると言われています。しかし、これは危険な手順であるとも言われています。何か問題が起きてクラスターが停止すると、アクティブ サーバーが復旧できず、何も残らない可能性があるからです。
これをどう処理すべきか、何か考えをお持ちの方はいらっしゃいますか? 成功を確実にする唯一の方法は、少なくとも 1 日のダウンタイムを設けて、新しいハードウェア上に新しいクラスターを立ち上げ、データベースを 1 つずつ移行することだと言われています。
[編集] この質問にまだ関連しているので、もう 1 つ質問を追加したいと思います。クラスターからマシンを削除することは可能ですか。次に、削除したノードをアクティブ マシンとして新しいクラスターを作成し、そこに新しいサーバーを追加します。何か問題が発生した場合に備えて、新しいマシンが交換される間、古いクラスターを効果的に保持しますか。
答え1
ダウンタイムはほとんどまたは全くない
現時点では、高可用性が必要なエンタープライズを実行する必要があるため、あまり役に立ちませんが、この状況で最も明らかに使用される機能は、クラスターに最大 16 個のノードを配置できることです。したがって、この場合は、さらに 2 つのノードを追加し、不要になったノードを削除するだけで済みます。ハードウェアをアップグレードするときに、バージョンをアップグレードすることを検討してください。
... しかし、これは危険なステップだとも言われています。何か問題が起きてクラスターが停止し、アクティブ サーバーが復旧できずに何も残らなくなる可能性があるからです。
何でも起こり得ます。サーバー 208 sql 2008 フェールオーバー クラスターが突然停止するのを見たことはありませんが、理論的には可能です。ノードのアップグレード中はアクティブ ノードが「停止」しないので、停止するものは何もありません。クラスターは、フェールオーバーの可能性のない 1 つのノードで実行されているだけです。妥当な最悪のシナリオは、古いノードが何らかの理由で停止し、交換ノードが追加されないことです。この場合、サーバーが追加されない原因となっている問題が解決されるまで、フェールオーバー機能なしで実行されることになります。
成功を確実にする唯一の方法は、少なくとも 1 日間のダウンタイムを設けて、新しいハードウェア上に新しいクラスターを立ち上げ、データベースを 1 つずつ移行することだと言われています。
おそらく、それが作業者の成功を確実にする唯一の方法でしょう。私は「クラスタの移動に1日のダウンタイムがかかるなら、そもそもクラスタリングする理由は何でしょうか？2台のマシンを購入し、1台をそのままにして、その可用性を実現できます」という素朴な質問をします。要するに、実際にクラスタを扱った経験があり、関連する技術を理解している人を見つける必要があります。特別な問題がないと仮定します（たとえば、会社がいくつかのほとんどクラスター上で実行されるクラスター対応ソフトウェア) 既存の稼働中のクラスターにハードウェアを交換/追加するには、ダウンタイムが 1 日かかると言うのは、ほとんどのプロの Microsoft 管理者にとって恥ずかしいことだと思います。
答え2
まず、質問の最後にある推奨戦略は、私も推奨する方法ですが、それが選択肢ではないため、私はこのように対処します。クラスターについて混乱しているようですが、基本的に両方のサーバーに SQL とクラスター サービスがインストールされており、クラスター サービス経由のコマンドを使用して、SQL を 1 つのサーバーから別のサーバーに「ロール」できます。私があなたの立場であれば、提案どおりに実行します。つまり、すべてのサービスを 1 つのノードにロールし、2 番目のノードをクラスターから削除し、新しいサーバーの 1 つをクラスター ノードとして追加し、すべてのサービスを新しいクラスター ノードにロールし、2 番目の新しいノードを追加し、2 番目の古いノードをクラスターから削除します。
** クラスター サービスやクラスター化された SQL インストールに詳しくない方が、ライブ システムでこれを実行しようとすると、非常に悪い結果になる可能性があることに注意してください。計画された 1 日のダウンタイムよりもはるかに悪い結果になります。クラスターの経験があるコンサルタントを雇うか、それが不可能な場合は、プロセスを徹底的にテストできるテスト環境をセットアップすることをお勧めします。
ここクラスターにノードを追加する手順へのリンクです。
答え3
ハードウェアを再度使用する場合を除き、古いクラスターを壊す必要はまったくありません。次のことをお勧めします。
- 新しいブレードで新しいクラスターを作成する
- 新しいクラスターにSQLをインストールし、ドライブ文字、パス、ポート、インスタンス名（該当する場合）を同じままにします。
- インストール後、ログインとジョブを取得するために、古いSQLサーバーから新しいSQLサーバーにマスターとmsdbデータベースを復元/置き換えます。または、古いサーバーでジョブをスクリプト化してsp_help_revloginsを使用します。
- データを最新の状態にするために、古いサーバーから新しいサーバーにデータベースをログ転送またはミラーリングします。
これにより、新しいインスタンスが古いインスタンスと同じ状態になり、OS と SQL が新規インストールされます。新しいクラスターに切り替えるには、古いインスタンスの名前が INSTA で、新しいインスタンスの名前が INSTB であると仮定して、次の操作を実行します。
- 古いSQLインスタンスをオフラインにする
- 新しいサーバー上のデータベースを回復する
- Active DirectoryのDNSからINSTA DNSレコードを削除する
- Active Directory DNSにINSTBを指す新しいCNAME（エイリアス）DNSレコードを作成します。
これが完了すると、アプリケーションは SQL インスタンスの古い名前に接続しますが、新しいサーバーに接続されます。DNS の変更を高速化するために、すべてのアプリケーション サーバーで「ipconfig /flushdns」を実行する必要がある場合があります。古い名前に ping を実行して、いつポイントが戻るかを確認してください。ロールバックが必要な場合に備えて、古いクラスターを保持できるため、この方法をカットオーバーに使用します。SQL Server ネットワーク名パラメーターを別のものに変更するまで、古い SQL インスタンスを起動することはできませんが、それが完了したら、ロールバックする場合は DNS エイリアスを古いものに戻すだけです。
答え4
ハードウェアの詳細がわからず、これが機能するかどうかはわかりませんが、古いパッシブ ノードのイメージを新しいサーバーにコピーすることをお勧めします。Acronis など、新しいハードウェアにイメージを配置できるものを使用すると、基本的にパッシブ ノードを新しいハードウェアに移動できます。そこに移動したら、電源を入れて、正常に機能していることを確認し (できる限り)、新しいハードウェアへのフェールオーバーを試行します。問題が発生する可能性は多数ありますが、Jim B が述べたように、新しいハードウェアに正常にフェールオーバーするか、機能せずに古いハードウェアに戻らなければならない可能性が高くなります。機能する場合は、他のノードでプロセスを繰り返すことができます。機能しない場合は、古いパッシブ ノードの電源を入れ直し (破壊する必要はありません)、別の方法を試すことができます。