同じ建物内でのサーバーの移動

私のシナリオは次のとおりです。私は、自分のオフィス内にある3つのサーバーを（知らないうちに）継承した開発者です。また、サーバー管理の知識と参照ポイントとしてのgoogle / ServerFaultが明確に欠けているサーバーの管理者であるという仕事も引き継ぎました。幸運なことに、私は実際にマシンと物理的に接触したり、常に「機能した」だけの問題に対処したりする必要はまったくありませんでした。

3台のマシンはすべて同じデータルーム内にあり、次の目的を果たします。

Machine1-多数の内部アプリケーションをホストするIIS 8.0-内部アプリケーション用の
Machine2SQL Server 2008 R2データストア
Machine3-SQL Server 2008 R2のミラーストアMachine2

3つすべてには、頻繁にバックアップを完了する外部ハードドライブが接続されています。

私は、3つすべてが同じ施設内のあるデータルームから別のデータルームに移動する必要があることを知りました。ハードウェアの物理的な移動は完了しません。これは有能なムーバーが処理します。

それぞれの完全なバックアップを完了する以外に、電源スイッチを仮想的にフリックして自分の世界が動くのを見る前に、どのような考慮事項が必要ですか？

^{同じ部屋/敷地内に3つすべてを配置するのは理想的とはほど遠いことは承知していますが、この質問の範囲を超えています。}

本当に興味深い質問、よく尋ねられた:)

この移動の前に確認する必要があることがいくつかあります。簡単なものと難しいものがあります。

電源 -新しい部屋に適切な量の電源コンセントがあるだけでなく、適切なタイプであることを確認します-物理コネクタタイプのように、現在の場所でサーバーごとに異なる電源フェーズを許可して単相障害から保護する場合は、それを新しい場所でも複製することを強くお勧めします。

冷却 -過熱やサーバーのシャットダウンの原因となる熱の即時または段階的な蓄積がないことを確認する必要があります。通常、各サーバーがメーカーのウェブサイトから引き出すことができる最大電力（ワット）または熱（BTU）を調べることができます-ビル管理者にこれを知らせ、その場所の冷却が対処することを示す書面で確認をもらいます。

ネットワーク -これは難しいものです-古い場所と新しい場所の間で同じ数のポートを複製する必要があるだけでなく、その種類、速度、そして最も重要な構成も複製します。この最後のポイントが重要です-ネットワーク内のほとんどすべてのポートがほぼ同等であった時代がありました-私はそれらの時代を覚えるのに十分な年齢です！しかし最近では、ポート構成の数と、1つのポートが存在できるネットワーク内の場所は天文学的なものであるため、ネットワークの人々が古いものから新しいものまですべて同一であることを確認する必要があります。簡単ではありません。この動きで何かがうまくいかない場合、私はお金を入れて、ネットワークポートが同一ではないことになります、それは常に起こります。

「その他の接続」 -サーバーに電源とネットワーク以外の接続があるかどうかを知っていますか？おそらく、共有ストレージへのファイバーチャネルリンク、共有管理画面へのKVMリンクがあります。これらを同じように複製する必要がある場合も同様です。

それ以外に、より具体的な質問があればここに戻って来てください。

他の回答は、移動の技術的な側面をカバーしています。また、他のいくつかのことを考慮する必要があります。

ユーザーが移動中にアプリケーションがダウンすることを確認してください。影響を受ける人の数を最小限に抑えるために、おそらく勤務時間外に移動をスケジュールする必要があります。

サーバーを立ち上げた後、知識のある人にアプリケーションをテストしてもらいます。アプリケーションが期待どおりに動作することを確認するために、健全性チェックを行ってもらいます。

テスト後、移動が終了したことをユーザーに伝え、問題があるかどうかをユーザーに知らせます。

私たちのフォーマットに対して「広すぎる」と言って境界線を引くことは非常に困難です。確認する必要がある最も重要なことは、ネットワークが同じアドレスで実行し続けることができるかどうかにかかわらず、ネットワークを再構成する必要があるかどうかです。同じアドレスを保持できる場合でも、それらがDHCP経由で構成されていないこと、および/またはDHCPサーバーが新しい場所で利用できることを確認してください。

サイドノート：既に述べたように、SQLサーバーとそのミラーを持つことは理想からはほど遠い。ただし、バックアップドライブを同じ場所に置くことは非常に危険です。バックアップを別の物理的な場所に置く必要があります。

他の答えには、移動前の考慮事項があります。ただし、実際の移動を整理する方法も計画する必要があります。Machine3はMachine2のミラーであるという事実から、SQL Server 2008 R2データベースではアップタ​​イムが重要な考慮事項のように見えます。それが鏡であるという事実はあなたに機会を提供します。ミラーが存在する理由は、プライマリサーバーが利用できない場合に利用できるようにするためです。これには、移動を含むメンテナンスのために利用できないことが含まれます。

計画を立てる：
移動の実行方法について書面で計画を立てる必要があります。この計画またはその一部を、作業の一部を処理する人（ムーバーなど）に提供できる必要がある場合があります。この計画には、すべての移動前のアクティビティ、実際の移動、および移動後のアクション（機能の検証など）を含める必要があります。

移動の基本：

1. Machine3（SQL Serverミラー）の移動：完全に機能するようにします。再同期を確認します。
2. Machine2を移動する：完全に機能するようにします。
3. Machine1の移動：完全に機能するようにします。

移動の詳細な説明：

以下は、使用の二つの方法（経路A及びB）を含むmachine3にするための接続テストするためのMachine1および/またはMACHINE2を。1つのメソッドのみを使用する必要があります。それを行う方法、またはどちらを使用する場合でも、質問に含まれていない情報（最終的なマシンの場所の物理的な分離、マシンの物理的なサイズ、ネットワーク/電源コードの長さ、同じ拡張機能の可用性、ネットワークポート構成の類似性、稼働時間のニーズなど）。使用machine3には、これらの接続をテストすることは、潜在的に、より高い稼働率できMACHINE2が、特に用のMachine1ないミラーを有していません。どちらの方法を使用するか、どちらも使用しないかを選択できます。

1. 最初にMachine3を移動します。

   • ままのMachine1とMACHINE2を今の場所に。
   • バックアップmachine3に、それをシャットダウン
   • 取得machine3には完全に新しい場所に移動します。
   • [パスB：オプションのステップ＃2を使用しようとしている場合は使用されません]すべてのマシンのネットワークと電源構成が同一である場合：入れmachine3にのMachine1がために意図接続使用して終了することが計画されているがのMachine1を。
   • 取得machine3にバックアップして実行しています。新しい場所で、それがMachine2のミラーとして正常に機能していることを確認します。これにより、すべての問題（電源、ネットワークなど）の構成が新しい場所で機能していることを物理的に検証できます。
   • 発生する問題を解決します。
   • 先に進む前に、Machine3がMachine2と完全に再同期されていることを確認します。

2. パスA：（オプション）：

   • 使用machine3にするためのものすべての設備をテストするためにMACHINE2とのMachine1を。
   • Machine3をシャットダウンし、Machine2の位置/接続を使用して（再同期の確認）、Machine1（再同期の確認）に移動/切り替えます。あなたがこれを行うことを計画している場合、machine3には、最初にで最終用途のために意図接続で設定されているはずのMachine1またはMACHINE2、あなたがのために最後の場所で最初にそれを設定しないようにmachine3にし、それを3回変更するが、唯一の2他のマシンの機能を使用して開始します。
   • 先に進む前に、Machine3がMachine2と完全に再同期されていることを確認します。

3. Machine2を移動します。

   • あなたの練習machine3には、これがよりスムーズにする必要があります。
   • Machine2をバックアップしてからシャットダウンします
   • Machine2を新しい場所に移動します。すべての接続を行います
   • 発生する問題を解決します。
   • 続行する前に、Machine2がMachine3と完全に再同期されていることを確認します。

4. [パスB：オプションのステップ＃2 でMachine3とのすべての接続をテストした場合は不要]これで、Machine1が終了するMachine3がある場合：

   • Machine3をシャットダウンします。
   • 最終的に予定されている場所（Machine1を配置する予定の場所から）に移動します。
   • 発生する問題を解決します。
   • 先に進む前に、Machine3がMachine2と完全に再同期されていることを確認します。

5. Machine1を移動します。

   • 両方移動したMACHINE2とmachine3に（できれば実際の接続試験のMachine1を有することによって使用するmachine3には、一時的にそれらを使用する）、これは動きの滑らかでなければなりません。
   • Machine1をバックアップしてからシャットダウンします
   • Machine1を新しい場所に移動します。すべての接続を行います
   • 発生する問題を解決します。
   • Machine1が占有する予定の施設で何か問題が発生した場合、Machine3が現在配置されている施設を使用するオプションがあります。マシン3でしばらく使用することで、マシン1の位置にあるすべての施設を既にテストできたことを願っています（パスAまたはパスB）。

サーバーのIPのいずれかが変更され、DNS解決を介してSQLボックスに接続される場合、移動と同時にDNSレコードの変更をスケジュールする必要があります。

イントラネットソフトウェアとデータベースについて知っておくべきこと：

• イントラネットソフトウェアは、IP、NetBIOS、またはDNSを介してSQL Serverに接続しますか？
• イントラネットソフトウェアで使用されるSQL Serverユーザーアカウントの認証は、IPからのトラフィックに制限されていますか？
• 会社の従業員は、スプレッドシートまたはレポートツールからSQL Serverに直接アクセスしますか？アクセスする場合、DSNをどのように定義しますか？

まったく同じIPを取得できない場合、または最終的に別のサブネットにアクセスする場合は、SQLサーバーに接続するアプリのソースコードまたは構成ファイルを変更するためのアクセスが必要になります。アドホックレポート作成のために、文書化されていない直接のSQLアクセスに依存している可能性があります。

「災害復旧」サーバーを活用してください。本番サーバーの移動中に負荷を処理するには、それらに切り替えます。適切に構成されたDR機器を使用すると、多くのダウンタイム（最大15分）が発生することなく、1日の中で移動できます。災害復旧サーバーは、運用サーバーと同じ方法で構成する必要があるため。DR機器がない場合は、入手することを強くお勧めします。

このように考えてください。コルベットがチューニングされている間に、ミニバンを使って一日を過ごしてください。

言及されていないと思うことの1つは、サーバーの新しいホームの物理的なセキュリティです。前に使用した部屋は何で、誰が鍵を持っていますか？適切なセキュリティ（アラームシステム、カメラなど）がありますか。

他の答えに加えていくつかの考慮事項：

• アプリケーションは、ファイルやWebサービスを使用した夜間のデータ交換などによって他のアプリケーションにリンクされていますか？アプリケーションが利用できない場合の結果は何ですか？関連するアプリケーションはこれに対処できますか、それともアプリケーションの情報不足のために失敗したり、間違った結果を生成したりしますか？

• ダウンタイムは、ユーザー、会社、さらにはクライアントにとって受け入れられますか？どのくらいの長さですか？

• ロールバックの計画を立てることは良い考えだと思います。ネットワークの問題など、すぐには解決できない問題の場合に使用できます。おそらく、ハードウェアを戻す場合に備えてムーバーを使用可能にしておく必要があります。

• あなたのアプリケーションは高いネットワークトラフィックを引き起こし、ネットワークはこれに備える必要がありますか（おそらくアドレスとファイアウォールの問題よりも問題の可能性ははるかに低いでしょう）？リアルタイムアプリケーション（ビデオ会議ソフトウェアなど）がある場合、レイテンシが重要になります。

• サーバーがある場合は、サーバーラックに収まる必要があります。