クラウドへのデータセンター移行チェックリスト
クラウドサービスは、仮想マシンの稼働において高い可用性と信頼性を確保します。多くの企業は、自社の物理データセンターに加え、あるいは自社データセンター内のオンプレミスサーバーの代わりに、クラウドサービスを利用しています。また、自社のオンプレミスデータセンターからクラウドへワークロードを移行することを検討している企業もあります。そして、この この傾向は強まっている、特にパンデミックの影響を受けて。
このブログ記事では、データセンターの移行について定義し、データセンターの移転時に直面しうる複雑さや課題について詳しく解説します。また、移行プロセスを円滑に進めるためのデータセンター移行チェックリストもご紹介します。
データセンターとは何ですか？
データセンターとは、コンピューティング、ストレージ、ネットワークリソースを収容する施設のことです。この施設は、環境面、電力面、ネットワーク面において堅牢な冗長性を備えています。データセンターは、複雑なシステム、アーキテクチャ、ネットワーク構造を有する、極めて複雑かつ技術的に高度な施設の一つです。
データセンターは、民間企業が所有・管理する場合もあれば、公的機関が所有し、コンピュータ／サーバー／ネットワークリソースからなる多くの"ポッド"を民間企業が管理し、様々な組織に提供する場合もあります。データセンターのリソースには様々な複雑さが伴うため、組織がデータセンター間の移行を決定する理由が存在する可能性があります。
データセンターの移行とは？
データセンターの移行とは、ハードウェアを物理的に移動させる、あるいはワークロードを論理的に別の場所へ移行させるプロセスを指します。移行先の場所は、別の物理データセンターでも、パブリッククラウド上の仮想データセンターでもかまいません。
データセンター移行の理由
組織がリソースをあるデータセンターから別のデータセンターへ移行することを決定する理由はいくつかあり、ビジネス上のニーズから技術的なニーズまで多岐にわたります。
ビジネスの観点から言えば、 合併、買収、リソースの適正化、事業規模の縮小、あるいはスケールアウトなど、データセンターの移転が合理的となる理由は多岐にわたります。さらに、組織によっては、高可用性の観点からスケールアウトを図り、ビジネスニーズに応じてリソースを複数のデータセンターに移行させることも考えられます。
技術に関してはデータセンターの技術は絶えず変化し、進化しています。機能や性能を向上させるために、あるデータセンターから別のデータセンターへ移行する技術的な理由があるかもしれません。さらに、組織によっては、リソースのパフォーマンスや耐障害性を向上させるために、複数の地域にリソースを分散させることを決定する場合もあります。
データセンター移行の具体的な理由が何であれ、エンドユーザーがサービス停止やパフォーマンス・サービスの低下を経験することなく、リソースの移行がシームレスに行われるよう、その複雑さやプロセスを慎重に検討する必要があります。
データセンター移行のベストプラクティス
データセンターの移行戦略において実践できるベストプラクティスを見ていきましょう。これらのプラクティスに従うことで、データの可用性やユーザー体験に悪影響を与えることなく、データセンターを円滑に移行することができます。
移行の基準と目標の設定
データセンターの移行に関する基準や目標は、ビジネス上のニーズや、移行によって解決しようとしている課題によって異なります。データセンターの移転が、リソースの一部のみを移行する部分的なものにとどまる場合、すべてのリソースをあるデータセンターから別のデータセンターへ移行する場合とは、移行の全体像が異なってきます。
プロジェクトの技術的な側面だけでなく、ビジネス上の目標についても、その基準と目的を確実に評価してください。これにより、技術的な目標だけでなく、ビジネス上の目標や影響についても十分に検討することが可能になります。
現在のデータセンターリソースをパブリッククラウドに移行する場合はどうでしょうか？
パブリッククラウドかプライベートデータセンターか:データセンターの要件を理解する
組織の間では、パブリッククラウドへより多くのリソースを移行する傾向が強まっています。データセンターの移行とは、プライベートデータセンターから、パブリッククラウドプロバイダーのいずれかを通じてパブリッククラウドへ移行することを意味する場合があります。 Amazon AWS、Microsoft Azure、Google Compute Cloudのいずれかを選択する.
移行ごとに考慮すべき課題は異なります。パブリッククラウドへの移行の場合、当然ながら物理リソースを移動させる必要はなく、仮想リソースや論理リソースのみが対象となります。一方、物理的なプライベートデータセンターから別のプライベートデータセンターへの移行では、物理リソースや資産を移動させる必要がある場合があります。
データセンターからクラウドへの移行が状況を劇的に変える一例として、ネットワーク通信の分野が挙げられます。 Amazon AWS例えば、VLANという概念は存在しません。顧客には、純粋なレイヤー3ネットワークの上にネイティブツールが実装されたオーバーレイネットワークが提供されます。したがって、セグメンテーションにVLANに依存する必要はありません。
パブリッククラウドのネットワークでは、ネットワークポリシーはネットワークレベルではなく、ホスト中心で設定されます。ポリシーの適用は、セキュリティグループを通じてホストレベルで行われます。また、Amazonの場合、VPCをプロビジョニングするとネットワークのサイズは固定されます。したがって、VPCネットワークに対して適切なサイズをプロビジョニングすることは、初期段階で極めて重要であり、データセンターからクラウドへの移行計画を慎重に検討する必要があることを示す好例です。
プライベートデータセンターからの移行においては、基本的にターゲットデータセンターにインフラを1対1で再現し、現在の本番データセンターに存在するリソースをそのまま"型にはめる"ようなアプローチで、ターゲットデータセンターにリソースをプロビジョニングすることができます。
綿密な計画
一般的に言えば、データセンターの移転は、成功させるためにはその重要性を過小評価してはならない大規模な事業です。データセンターの移行が失敗すれば、サービスの中断や、準備不足によるデータ損失につながる可能性があります。 データのバックアップ、顧客の不満、ブランドの評判の低下、そして最終的には、プロセスの適切な計画と準備を怠った組織に実害をもたらすことになる。
データセンター移行チェックリスト
データセンター移行チェックリストに従って、トラブルを回避し、最適な方法でデータセンターを移行しましょう。
1. データセンターの移転計画
データセンターの移行計画には、通常、数週間、場合によっては数ヶ月の準備期間が必要です。データセンターの移行計画には、以下の点を盛り込む必要があります:
既存データセンターおよび新データセンターの現地調査
不可欠な要素として、既存のデータセンターと新しいデータセンターの両方に対する現地調査があります。以下の質問に対する回答が必要です:
- 現在のデータセンターにある物理リソースは移転されるのでしょうか？
- もし答えが"はい"なら、配線やその他の物理的なレイヤー1の接続について、十分に理解されていますか？
- 物理インフラの移行が完了した後、これを対象のデータセンターでも再現することは可能でしょうか？
- 物理リソースを新しいデータセンターに移行しない場合、既存のインフラストラクチャに代わる適切な代替手段は用意されていますか？
すべてを記録する
ストレージ、コンピューティング、ネットワーク、アプリケーション、およびその他のインフラストラクチャ要件を含む、すべてのインフラストラクチャ要件は文書化されていますか？
注:
- ドキュメントが多すぎるくらいの方が、足りないよりはましだ。
- 重要かどうかに関わらず、すべてのラック、ラックの"U"、仮想マシン、ネットワーク、およびアプリケーションについて、確実に文書化してください。
依存関係
- 現在のデータセンター環境において、ターゲットデータセンターにレプリケートする必要がある依存関係は、十分に把握されていますか？
- 現在のデータセンターには、ターゲットのデータセンターに複製する必要がある付帯システムはありますか？
ネットワークには以下が必要です
現在のデータセンターにある既存のアプリケーションについて、新しいデータセンターに移行する際に考慮すべきLANおよびWANに関する事項にはどのようなものがありますか？
プライベートデータセンター
- 新しいデータセンターでプロビジョニングする必要があり、かつ既存のデータセンターで現在使用されているVLANはありますか？
- 現在のデータセンターにおいて、リソースやアプリケーションにはどのようなIPアドレス割り当ての要件がありますか？
- レガシーアプリケーションでは、新しいデータセンターへの移行前に削除する必要があるハードコードされたIPアドレスが使用されていますか？
- WAN IPアドレスに関してどのような懸念事項がありますか？WAN IPアドレスに関するすべての考慮事項は十分に検討されていますか？
- DNSと名前解決はどのように行われるのでしょうか？
- 現在のデータセンターと新しいデータセンターのリソースは並行して稼働し、DNSの移行を円滑に行い、DNSの収束に十分な時間を確保できるでしょうか？
- IP Anycastなどの他のメカニズムを使用して、複数の場所から同じIPプレフィックスをアドバタイズし、BGPやその他のルーティングプロトコルがリンクのコストや健全性に基づいてルーティングを行うようにすることは可能でしょうか？
- 新しい回線の開通に十分なリードタイムを確保できるよう、必要なWAN回線の注文は済んでいますか？一部のISP(インターネットサービスプロバイダー)では、新しい回線の開通に最大90日かかる場合があります。こうした時間的余裕は、データセンターの移行計画に必ず盛り込む必要があります。
パブリッククラウド
- パブリッククラウドにはVLANが存在しないため、ネットワークアクセスの再設計にあたっては、レイヤー2に関する要件を十分に検討する必要があります。
- IPアドレスはいくつ必要ですか？サブネットのサイズはどのくらい必要ですか？AWSのデフォルトは/16のサブネットです。
- ネットワークセキュリティはどのように設定すべきでしょうか？どのようなセキュリティグループを考慮に入れる必要がありますか？
- VPCあたり500のセキュリティグループ制限 – ネットワークに必要なセキュリティグループ数が、この上限を超えることはありませんか？
- 複数のVPCをプロビジョニングする必要がありますか？
- パブリッククラウドに移行する場合、おそらく自動化ツールの変更が必要になるでしょう。これについては検討されていますか？
2. データセンター移行テストのチェックリスト
移行プロセスの全手順を網羅することは難しいかもしれませんが、1回または数回、移行のテスト実行を行うことは有益です。さらに、ネットワーク移行項目などの主要な構成要素を実験環境で段階的に構築することができれば、実際の移行が行われる前に、アプリケーションに関する潜在的な問題などを明らかにするのに役立ちます。
- 移行に関する主なポイントについて、チームの主要メンバーと話し合ってください。
- 実行すべき手順を把握しておきましょう。チェックリストの項目の中には、他の項目を先に完了させる必要があるものが含まれている可能性が高いからです。
- 活用する 実験環境 データセンターの移行をシミュレートするため、ネットワークリソースに加え、アプリケーションのテストやトラブルシューティングも行います。テストは、データセンター移行のチェックリストにおいて重要な項目です。
3. データセンターの移転の実施
計画は完了し、リソースも新しいデータセンターの拠点やパブリッククラウドに配備できる状態になったため、いよいよ移行を実行する段階です。データセンターの移行における考慮事項:
- 引っ越しの各工程について、誰が責任を持つのかを明確にしておきましょう。思い込みで物事を進めてしまい、引っ越しの重要な部分に関する責任の所在が曖昧になってしまうような事態だけは、何としても避けなければなりません。
- 移行プロジェクトに関わる全員と協力して、詳細な行動計画を作成してください。各担当者の役割を明確に書き出してください。
- 関係者の連絡先や電話番号などをすべて把握しておき、データセンターの移転に伴い発生しうる問題への対応に専念できるよう、連絡先を探すのに時間を浪費しないようにしましょう。
- 予備として、追加のベンダー担当者を確保しておいてください。これには、データセンターの担当者、ISP、ネットワークエンジニア、インフラエンジニア、運用エンジニアなどが含まれます。
- 電子メールやバナーページなどを通じて、事前にエンドユーザーへ通知してください。メンテナンスの予定時間を詳細に明記することで、エンドユーザーの不満を最小限に抑えることができます。
- リソースの移行に伴い、エンドユーザーからの問い合わせが殺到する可能性に備え、トリアージ対応チームを準備しておくこと。
4. データセンター移転後の確認事項
データセンターのリソースの移行が完了したら、移行に起因するパフォーマンス上の問題やその他のシステム上の問題を迅速に把握する必要があります。
- 移行後、システムプロセスの整合性とアプリケーションの可用性を検証するため、手動による確認または自動化された手段のいずれかを用いて、このタスクを担当するチームを配置してください。
- 世界中のさまざまな地域からトラフィックを受信している場合は、世界中の異なるエンドポイントからのトラフィックをシミュレートし、名前レコードが変更された際にDNSの収束によって生じる可能性のある地域ごとの差異をテストできるようにしてください。
- アプリケーションのエラーだけでなく、そのパフォーマンスについてもテストを行う。
- パフォーマンスの向上が期待されていた場合、その向上は実現しましたか？
- は パフォーマンスが低下する…これは、移行に関する根本的な問題を示唆しているのでしょうか？
- メンテナンス期間が終了し、システムが正常に動作する見込みとなった時点で、エンドユーザーに通知してください。これにより、エンドユーザーは、現在直面している問題が移行に伴う一時的なものなのか、それとも根本的な問題なのかを判断しやすくなります。
- データセンターの移行に関与した全チームメンバーと事後検討会を行い、移行中に発生した課題を洗い出してください。これにより、将来に向けてより強固なチームを構築できるほか、未然に防げたはずの課題を明らかにし、今後のプロジェクトに活かすことができます。
注:. データセンターのクラウド移行が完了した場合は、必ず クラウドバックアップ戦略 お客様のデータを保護するため。
まとめ
データセンターの移行は、組織が取り組まなければならない最も複雑なプロセスの一つとなり得ます。移行には、移行中にシステムを稼働させたままにするか、あるいは移行後できるだけ早く復旧させるために、システムに対して正確かつ綿密に計画された変更を加える必要があります。
移行が成功すれば、その恩恵は計り知れません。これにより、企業は技術的なニーズに合わせて、より近代的で技術的に高度なデータセンターへと拡張することが可能になります。さらに、リソースを収容するために、組織がデータセンターをクラウドへ移行することも可能になります。いずれの場合も、綿密な計画、テスト、そして周到に練られた計画の実行によって、組織はデータセンター移行という困難な課題を成功させることができます。
移行を開始する前に、データのバックアップを行うことを強くお勧めします。ダウンロード NAKIVO Backup & Replication データセンター内の物理マシンおよび仮想マシンを保護するための無料トライアル。
