同じ建物内でのサーバーの移動
これが私のシナリオです。私は、自分のオフィス内にある3つのサーバーを（私には知られていない）継承した開発者です。私はまた、サーバーの管理知識が明らかに不足しており、参照ポイントとしてgoogle/ServerFaultを使用して、サーバーの管理者であるという仕事を引き継ぎました。幸いにも、私は実際にはマシンと物理的に接触したり、問題に対処したりする必要はありませんでした。
3つのマシンはすべて同じデータルーム内に配置され、次の目的を果たします。
Machine1-IIS 8.0は多数の内部アプリケーションをホストしていますMachine2-内部アプリケーション用のSQL Server 2008 R2データストアMachine3-Machine2のSQL Server 2008 R2ミラーストア
3つすべてに外部ハードドライブが接続されており、頻繁にバックアップを完了します。
3つすべてが同じ構内の1つのデータルームから別のデータルームに移動する必要があると通知されました。ハードウェアの物理的な移動は完了しません。有能なムーバーによって処理されます。
それぞれの完全なバックアップを完了する以外に、電源スイッチを仮想的にフリックして私の世界の動きを観察する前に、どのような考慮事項を考慮する必要がありますか？
3つすべてを同じ部屋/敷地内に配置するのは理想的とは程遠いことは承知していますが、それはこの質問の範囲を超えています。
本当に興味深い質問、よく聞かれる:)
この移動の前に確認する必要があるいくつかの事項があります。簡単な場合もあれば、難しい場合もあります。
Power-新しい部屋に適切な数の電源コンセントがあるだけでなく、それらが適切なタイプであることを確認します-物理コネクタタイプと同様に、現在の場所でサーバーごとに異なる電力フェーズが可能かどうか単一フェーズの障害から保護してから、それを新しい場所にも複製することを強くお勧めします。
冷却-過熱や潜在的なサーバーのシャットダウンにつながる熱の即時または段階的な蓄積がないことを確認する必要があります。通常、各サーバーが製造元のWebサイトから引き出せる最大電力（ワット単位）または熱（BTU単位）を調べることができます-建物の管理者にこれを知らせ、その場所の冷却が対処することを示す書面による確認を彼らに送ります。
ネットワーキング-これは難しい問題です。新旧の場所で同じ数のポートを複製する必要があるだけでなく、タイプ、速度、最も重要な構成も同じです。この最後のポイントが鍵です-ネットワークのほとんどすべてのポートがほぼ同じであった時代がありました-私はそれらの時代を覚えるのに十分な年齢です！しかし最近では、ポート構成の数と、1つのポートを配置できるネットワーク内の場所は天文学的なものであり、ネットワークの人々がすべてを古いものから新しいものに同一に複製することを確認する必要があります。これを次のように書面で再度入手してください。簡単ではありません。この動きで何か問題が発生した場合、同じではないネットワークポートにお金を投入します。それは常に発生します。
'Other connections'-サーバーに電源とネットワーク以外の接続があるかどうかを知っていますか？おそらく、共有ストレージへのファイバーチャネルリンク、KVM共有管理画面へのリンクがあります。これらのリンクを同じように複製する必要がある場合も同様です。
それ以外は、具体的な質問があれば気軽にここに戻ってください。この動きがうまくいくことを願っています。
他の回答は、移動の技術的な側面をカバーしています。また、他のことも考慮する必要があります。
移動中はアプリケーションがダウンすることをユーザーに知らせてください。影響を受ける人の数を最小限に抑えるために、おそらく勤務時間外に移動をスケジュールする必要があります。
サーバーを起動した後、知識のある人にアプリケーションをテストしてもらいます。アプリケーションが期待どおりに動作することを確認するために、いくつかの健全性チェックを行ってもらいます。
テストの後で、移動が終了したことをユーザーに伝え、問題があるかどうかをユーザーに知らせます。
私たちのフォーマットを「広すぎる」と言い、境界を定めることは非常に困難です。チェックする必要がある最も重要なことは、同じアドレスで実行を継続できるかどうかに関係なく、ネットワークを再構成する必要があるかどうかです。同じアドレスを保持できる場合でも、それらがDHCP経由で構成されていないことを確認し、DHCPサーバーが新しい場所で使用できることを確認します。
補足：すでに述べたように、SQLサーバーとそのミラーを用意することは、理想とはほど遠いものです。ただし、バックアップドライブを同じ場所に置くことは本当に危険です。バックアップを別の物理的な場所に置く必要があります。
他の回答には、移行前の考慮事項があります。ただし、実際の動きをどのように整理するかも計画する必要があります。 MachineがMachine2のミラーであるという事実から、SQL Server 2008 R2データベースの稼働時間は重要な考慮事項のようです。それが鏡であるという事実はあなたに機会を提供します。ミラーが存在する理由は、プライマリサーバーが利用できない場合に利用できるようにするためです。これには、引っ越しを含む、メンテナンスのため利用できないことも含まれます。
計画を立てる：
移動をどのように実行するかについて書面で計画を立てる必要があります。作業の一部を処理する人（ムーバーなど）にこの計画またはその一部を提供できるようにする必要がある場合があります。この計画には、すべての移動前のアクティビティ、実際の移動、および移動後のアクション（機能の検証など）を含める必要があります。
移動の基本：
- 移動Machine（SQL Serverミラー）：完全に機能します。再同期を確認します。
- 移動Machine2：完全に機能します。
- 移動Machine1：完全に機能します。
移動のより詳細な説明：
以下は、Machineを使用してMachine1またはMachine2の接続をテストする2つの方法（パスAおよびB）を含みます。 1つの方法のみを使用する必要があります。これを行う方法、またはどちらを使用する場合でも、質問に含まれていない情報に依存します（たとえば、最終的なマシンの場所の物理的な分離、マシンの物理的なサイズ、ネットワーク/電源コードの長さ、同じ拡張機能の可用性、ネットワークポート構成の類似性、稼働時間のニーズなど）。これらの接続をテストするためにMachineを使用すると、潜在的にMachine2、ただし特にミラーのないMachine1のアップタイムが長くなります。どちらの方法を使用するか、どちらも使用しないかを選択できます。
最初にMachineを移動します。
- Machine1およびMachine2はそのままにしておきます。
- バックアップMachine、次にシャットダウンします
- Get Machine完全に新しい場所に移動しました。
- [パスB：オプションの手順2を使用する場合は使用されません。]すべてのマシンのネットワークと電源の構成が同じ場合：Put Machine where Machine1が計画されていますMachine1向けの接続を使用することになります。
- Get Machineバックアップして実行します。新しい場所で、それがMachine2のミラーとして正常に機能していることを確認します。これにより、すべての問題（電源、ネットワークなど）の構成が新しい場所で機能していることを物理的に確認できます。
- 発生する問題を解決します。
- 続行する前に、MachineがMachine2と完全に再同期していることを確認します。
パスA：（オプション）：
- Machineを使用して、Machine2およびMachine1向けのすべての機能をテストします。
- シャットダウンMachineダウンして、位置/接続を使用するように移動/切り替えMachine2、（verify re-sync）then Machine1（verify re-sync ）。これを行うことを計画した場合、Machineは最初にMachine1またはMachine2による最終使用を目的とした接続で設定されているはずなので、 Machineの最後の場所で最初に設定せず、次に3回変更しますが、他のいずれかのマシンの機能を使用して開始することで2回だけ変更します。
- 続行する前に、MachineがMachine2と完全に再同期していることを確認します。
移動Machine2。
- Machineを使用すると、これがはるかにスムーズになります。
- バックアップMachine2、次にシャットダウンします
- Machine2を新しい場所に移動します。すべての接続を行います
- 発生する問題を解決します。
- 続行する前に、Machine2がMachineと完全に再同期していることを確認します。
[パスB：オプションのステップ＃2でMachineを使用してすべての接続をテストした場合は不要です。現在Machineがある場合Machine1は最終的に：
- シャットダウンMachine。
- 最終的に予定されている場所に移動します（目的の場所以外にMachine1を配置します）。
- 発生する問題を解決します。
- 続行する前に、MachineがMachine2と完全に再同期していることを確認します。
移動Machine1。
- Machine2とMachineの両方を移動したこと（そして実際に接続をテストしたところMachine1はMachineを使用して一時的に）、これは最もスムーズな動きです。
- バックアップMachine1、次にシャットダウンします
- Machine1を新しい場所に移動します。すべての接続を行います
- 発生する問題を解決します。
- Machine1が占めるはずの位置にあるファシリティで何か問題が発生した場合、Machineが配置されているファシリティを使用するオプションがあります。うまくいけば、Machine1の位置にあるすべてのファシリティを、Machineでしばらく使用することで、テストできました（パス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日を過ごします。
他の回答に加えていくつかの考慮事項：
アプリケーションは他のアプリケーションとeでリンクされていますか。 g。ファイルまたはWebサービスの使用による夜間のデータ交換？アプリケーションが利用できない場合、どのような影響がありますか？関連するアプリケーションはこれに対処できますか、またはアプリケーションからの情報がないために失敗したり、誤った結果を生成したりすることはありますか？
ダウンタイムは、ユーザー、会社、またはクライアントにとって許容範囲ですか？それはどれくらいの長さでしょうか？
ロールバックの計画を立てることは良い考えだと思います。すぐに解決できない問題が発生した場合などに使用できます。 g。ネットワークの問題。ハードウェアを元に戻す場合は、ムーバーを使用できるようにしておく必要があります。
アプリケーションが大量のネットワークトラフィックを引き起こし、ネットワークはこれに備えなければなりませんか？リアルタイムアプリケーション（テレビ会議ソフトウェアなど）を使用している場合は、待ち時間が重要になります。
サーバーがある場合、サーバーはサーバーラックに収まる必要があります。
私が言及していないと私が思うことの1つは、サーバーの新しい家の物理的なセキュリティです。以前はどの部屋が使用されていましたか、誰が鍵を持っていますか？適切なセキュリティ（アラームシステム、カメラなど）はありますか？.