システム基盤移行・移設方法論
事例紹介#1
業種 | システム重要度 | システム移行期間 | 移行サービス停止時間 |
製造業 | 高 | 3ヶ月 | 4時間 |
顧客様の物理老朽化に従い、データセンターにあるシステムをクラウドへ移行と考えます。当社は顧客様と一緒にクラウド選定から、システムのクラウド移行を計画し、移行・移設作業を行います。
システム全体は50台VM構成規模で、移行当日システムサービス停止時間は4時間以内に守って、無事に移行が完了させます。
事例紹介#2
業種 | システム重要度 | システム移行期間 | 移行サービス停止時間 |
物流業 | 高 | 6ヶ月 | 24時間 |
顧客様の会社方針に従い、従来通りデータセンターに作るプライベートクラウドからAlicloudに移行を行います。当社はクラウド基盤の構成を設計し、全部システムはクラウドに移行する計画を策定し、移行・移設作業を行います。
20+個システムに対する全体的に60台サーバ構成規模で、移行全体のシステムサービス停止時間は合計24時間以内に守って、無事に移行が完了させます。
基盤移行・移設方法論
移行・移設:基本方針
顧客様のご要件を満たすための基本方針として、当社が重要だと考えている内容は以下の3点です。
次項以降でそれぞれの内容について説明します。
移行・移設の進め方
当社では、過渡期におけるL2拡張やクラウドへの移行といったシステム構成の変化に起因するリスクを軽減し、本番移行・移設を確実に実施するために、「十分なテスト期間を確保すること」がプロジェクトを成功に導くための重要なポイントだと考えています。
「十分なテスト期間を確保し、移行・移設を確実に実施するための進め方」について、当社の基本方針を以下に示します。
✓ 本番移行前に移行対象のOSを事前に複製し(移設対象サーバについてはダミーOSを構築)、移行元のシステムと並行稼動させることによって、新規運用基盤との連携やシステム間の連携等、移行先の環境内に閉じた形で実施可能な連携テストを事前に確認しておく
✓ システム間の依存関係・連携関係が強い基盤を、可能な限り同じタイミングで本番移行・移設し、L2拡張を経由する拠点間のシステム連携を最小限とすることで、本番移行・移設時にしか確認できないテスト項目を削減する
移行・移設スケジュールの検討方法
本プロジェクトでは多数のサーバが移行・移設対象となることから、停止許容時間等の制約により、段階的な移行・移設が必要になると認識しています。「どのような単位で」、「いつ」、「何回に分けて移行・移設していくべきか」といった、段階的な移行・移設について、当社の基本方針を以下に示します。
✓ システム間の依存関係・連携関係が強い基盤を可能な限り同じタイミングで移行・移設するために、長時間の停止を伴い実施可能なタイミングが限られる「移設」対象機器との依存関係・連携関係を中心にグルーピングを行い、移行・移設単位を決定する
✓ 移設対象が含まれるグループについては、移設に合わせて本番移行を行うこととし、本番移行・移設の約2週間~4週間前にリハーサルを実施できるよう、OSの複製や運用管理ツールを事前に導入する
✓ 当該グループの移行対象サーバ数が多く、1回の停止許容時間内でOSの複製が収まらないことが想定される場合には、数回に渡る段階的な事前移行を計画する
✓ 上記を大方針とし、海外利用等停止タイミングの個別調整が必要なシステムについては、移転計画にて別途スケジュールを検討する
(図解)移転全体スケジュール検討の例
前述の基本方針に則った移転全体スケジュールの検討例を以下に示します。
(図解)本番システム停止時間
前述の移転スケジュールにおける本番システムの停止時間について具体例を以下に示します。
実績に基づいた移行・移設方式
当社では、顧客様の現状の課題とご要件を十分に理解した上で、本プロジェクトの重要性や短工期という制約を考慮し、実績ある手法・方式に基づき、リスクを最小化することが重要だと考えています。
特に、事前に環境を複製しリハーサルが実施できる「移行」とは異なって、リハーサルが実施できない「移設」に関しては本番での失敗が許されないことから、事前のリスク対策によっていかに安全かつ確実に実施できるかがポイントになると考えています。
当社では、多くの移転実績から体系化された「移転フレームワーク」を活用して、現状調査、及び計画書、手順書の作成を効率的に実施し、安全かつ確実な移設を実現します。
移行・移設:実現方法
本章では、前述の基本方針に則って当社が提案する移行・移設の実現方法について、下記4つの観点で説明します。
タイトル |
概要 |
3.1. 実現方法サマリ | 当社が考える移行・移設全体の進め方をフェーズごとのタスク、スケジュール等の観点で要約します |
3.2. 移転計画 | 移転計画の進め方や移行・移設の基本方式、及び計画段階で想定されるリスクとその対応策を記載します |
3.3. 移行作業 | 移行作業の検討の進め方や、P2V/V2Vの方式/手順、事前検証や移行リハーサルの実施内容について記載します |
3.4. 移設作業 | 移設作業検討の進め方や、移設当日の作業内容や、移設に伴い想定されるリスクとその対応策を記載します |
移行・移設:実現方法サマリ
本プロジェクトにおいて当社が考える移行・移設全体の進め方について、フェーズごとのタスク、全体スケジュール、システム全体構成の現状と最終形のそれぞれの観点で要約します。
タイトル |
概要 |
3.1.1. 移行・移設の一連の流れ | 本プロジェクトにおける移行・移設の進め方を、「移転計画」、「移行作業」、「移設作業」の3つに分類し、当社が各フェーズで実施すべきと考えるタスクを記載しています |
3.1.2. テスト・リハーサル方針 | 当社が本番切替時のリスクを軽減させるためのテスト・リハーサルの方針として現時点で想定しているタイミングや確認内容について記載しています |
移行・移設の一連の流れ
当社が考える「移行・移設の一連の流れ」を図示します。各タスクの詳細記載します。
テスト・リハーサル方針
当社では、本番切替時のリスクを軽減させるためのテスト・リハーサルの方針として、以下に図示する5つのタイミングでテスト、及びリハーサルを行うことを想定しています。どのタイミングにおいてもアプリケーション動作確認は可能ですが、特に下記①、②、⑤のテストについては顧客様と共同実施を想定しており、ご協力(※)をお願いします。
移転計画
本節では、移転計画フェーズにおいて、「どのようなタスクをどのように進めるべきか」という移転計画の進め方や移行・移設の実現方式、及び各タスクを行う上で想定されるリスクとその対応策を記載します。
タイトル |
概要 |
3.2.1. 移転計画の進め方 | 移転計画フェーズにおいて、どのようなタスクをどのように進めるべきか、各タスクの目的と概要、検討を進めるための手順と検討上のポイントを記載しています |
3.2.2. 実現方式案 | 移行・移設の基本方式や移転を行う基盤の単位、移転スケジュールといった移転計画について、現時点で想定している内容を記載しています |
移転計画の進め方
当社が考える、移転計画全体のタスクと基盤チームタスクとの関係、基盤チームと授受すべき情報を図示します。
移行作業
本節では、移行作業フェーズにおける検討の進め方の方式/手順、事前検証や移行リハーサルの実施内容、移行作業時に想定されるリスクとその対応策について記載します。
タイトル |
概要 |
3.3.1. 移行作業の進め方 | どのような情報をインプットに、どのような手順で検討を進めるべきか、という移行作業の進め方と、各タスクの検討ポイントについて記載しています |
3.3.2. 実現方式案 | 事前検証の実施内容やP2V/V2Vの方式/手順、データ移行の方式/手順、移行リハーサルで実施する動作確認の内容について記載しています |
3.3.3. 想定されるリスクと対応策 | 一連の移行作業を行う上で、想定されるリスクとその軽減策/対応策を記載しています |
移行作業の進め方
当社が考える、移行作業全体のタスクを以下に図示します。
お問い合わせとご相談は下記の方法でご連絡ください。
連絡先:021-64739299
e-mai:info.hp@cn.nssol.nipponsteel.com