クライアントサーバ型アプリケーションの AWS 移行-マイグレーション事例

移行の背景・経緯

お客様は中古車販売店で、対象サーバは顧客管理システムとして、2005年前後に導入されたものでした。
商材が自動車という耐久消費財なので、お客様との付き合いは長期にわたるため、オンプレミスのシステムでは、商材よりも先にハードウェアの寿命の方が早く来てしまいます。また、業界的にも IT 投資を増やしていける状況でもなかったということもあり、ハードウェアのサポートが打ち切られても、サードパーティーの保守などを利用してなんとか持ちこたえ、15年間過ごしてきてしまったとのことでした。
このお客様は、中古車販売店の他にも、システム開発や保守の提供を行う会社も経営されている関係で、AWS のクラウドへサーバを P2C(Physical to Cloud) できることを案内できたので、今回の移行作業を実施することになりました。

概要、構成図

■概要

  • サーバー台数:1台
  • サーバーOS:WindowsServer2003R2Std
  • 移行対象システム:クライアントサーバ型アプリケーション

 

■構成図

ネットワーク構成については、各拠点同士は Yamaha で VPN を組んでいて、クラウドとも VPN を接続する構成を検討しましたが、拠点数が多く月額費用がかさむこと、サーバーとのトラフィック自体が暗号化されていることから、セキュリティーグループで拠点の IP アドレスを指定して通信を通すことになりました。

構成図

移行の流れ

ステップ1:移行作業用の IAM ユーザーの作成

移行作業用の IAM ユーザーの場合、アクセスの種類は「AWS マネジメントコンソールへのアクセス」を選択します。

Administrator作成

ポリシーには、[ AdministratorAccess ]ポリシーをアタッチします。

Administratorアタッチ

ステップ2:AWS コンソールで VPC 、サブネットの作成

VPC を作成を作成します。

VPC作成

サブネットを作成します。

サブネット作成

ステップ3: CloudEndure 用の IAM 作成

CloudEndure 用の IAM ユーザーの場合、アクセスの種類は「プログラムによるアクセス」を選択します。

CloudEndure作成

ポリシーには、CloudEndure コンソールに記載のある JSON を貼り付け、専用のポリシーを作成しアタッチします。

CloudEndureアタッチ

ここで発行されるアクセスキー及びシークレットアクセスキーを CloudEndure に登録します。

アクセスキー

ステップ4: CloudEndure のアカウント作成

メールアドレス、パスワードを入力してアカウントを発行します。

CloudEndureアカウント作成

ステップ5: CloudEndure 管理コンソールでプロジェクトの作成、セットアップ

CloudEndure 管理コンソールからプロジェクトを作成します。

CloudEndureコンソール

ステップ6:オンプレミスサーバーへのエージェントインストール

以下のコマンドを、オンプレミスサーバーのコマンドプロンプトに貼り付け、インストールを実行します。

CloudEndureエージェントインストール

ステップ7:データのレプリケーション

エージェントのインストール完了後、 CloudEndure コンソールの「 Machines 」に登録され、レプリケーションが開始します。
データ転送制御のため、クラウド上の CloudEndure サービスと移行元サーバーとで通信を行います。

DataReplicationStart

レプリケーションの進捗は、パーセンテージと容量で確認することができます。
移行元サーバーとレプリケーションサーバー間は、継続的なデータ同期が行われます。

ReplicationSettings

CloudEndure 管理コンソールで [ MACHINE DASHBOARD ] 内のゲージが [ Continuous Data Replication ] の状態になると、レプリケーション終了です。

Replication-Finish2

ステップ8: CloudEndure の管理コンソールからインスタンスを起動

移行元サーバー内に日付と時間を記載したファイルを設置後、 CloudEndure 管理コンソールから [ LAUNCH TARGET MACHINE ] を選択して、インスタンスを起動します。
データ転送を開始すると、移行元サーバーのディスクイメージを受け取る為にレプリケーションサーバーが起動し、移行元サーバーのボリュームと同数の EBS が作成され、移行元サーバーのデータが移行先環境へ転送されます。

CloudEndureコンソール-Launch(TestMode)

ステップ9:起動したサーバーに RDP 接続して動作テストを実施

インスタンス起動後に、起動したインスタンスに RDP 接続し、移行後の状態や動作等などのテストを実施します。
また、起動前に移行元サーバーに設置した日付と時間を記載したファイルの確認を実施します。
RDP 接続後は、Windows のコピーが正規品であり、デバイス数を超えて使われていないことを確認する為に、Windows のライセンス認証を実施する必要があります。

RDP接続してテスト

トラブル

新環境への移行中は、概ね大きな問題は発生することなく進行しましたが、3度下記に示すようなトラブルも発生しました。

オンプレミスサーバへのエージェントインストールの失敗

事象:

CloudEndure のコンソールからインストールエージェントのダウンロードを行い、オンプレミスサーバーのコマンドプロンプトへコマンド ” installer_win.exe -t… “ をペーストして実行したところ、インストールに失敗しました。

原因:

移行対象のサーバーが Windows Server 2003 を搭載しており、.NET Framework3.5 のインストールが必要であった為、発生しました。

解決策:

.NET Framework3.5 を移行対象のサーバーへインストールし、再度コマンドを実行したところ、上手くインストールできました。
今後、同等の OS を搭載したサーバーの移行を検討する場合には、今回の様な .NET Framework のインストールや、既にインストールされている場合は、ソフトウェアのアップデートなどを考慮しておく事で、上記のような問題は起きないと考えています。

CloudEndure でのレプリケーションの失敗

事象:

[ REPLICATION SETTINGS ] の変更を行い、 CloudEndure のコンソールからインスタンスを起動しようとしたところ、移行作業のレプリケーションの途中でエラーが発生し、レプリケーションが開始されませんでした。

原因:

CloudEndure ではレプリケーション前に設定した [ REPLICATION SETTINGS ] の設定がマシン作成後に引き継がれますが、レプリケーション後は作成したマシン毎の個別の設定となるため、マシン作成後に [ REPLICATION SETTINGS ] の設定の変更が生じた場合には [ Setup & Info ] と [ Machines ] の両方の [ REPLICATION SETTINGS ] の変更が必要になるのですが、今回の設定では [ Setup & Info ] のみ設定し、[ Machines ] の設定を行なっていなかったため、エラーが発生し、レプリケーションが開始されませんでした。

解決策:

[ Setup & Info ] の設定と同様に [ Machines ] の [ REPLICATION SETTINGS ] を変更し、再度インスタンスを起動すると、レプリケーションが問題なく開始でき、今回のエラーの解決に至りました。

※以下のパラメータが、[ Setup & Info ] と [ Machines ] の [ REPLICATION SETTINGS ] 設定で一致している必要があります。変更前は[ Setup & Info ] と [ Machines ] で以下のパラメータが異なっていた事から、ターゲットマシンが [ Machines ] の修正前の利用可能な設定やオプションを認識し、レプリケーションを開始していた為、エラーとなりました。

CloudEndure 設定パラメータ

CloudEndure から EC2 インスタンスを起動した際の起動時エラー

事象:

CloudEndure のコンソールからレプリケーションを実行しインスタンスを起動後しようとすると、ステータスチェックが「 Instance connectivity check failed 」となってしまい、インスタンスが起動しませんでした。また、RDP 接続を実施しようとしましたが、接続できず、 ping コマンドにも反応しませんでした。インスタンスのスクリーンショットの取得も試みたところ、ブルースクリーンやOS起動失敗のような画面が表示され、最終的に何度も起動を繰り返す状態が発生しました。

BlueSCREEN[表示されたブルースクリーン]

起動失敗画面[ OS 起動失敗のような画面]

原因:

仮想マシンの変換プロセスで失敗している状況であった為、起動に失敗していました。

解決策:

AWS 自動診断プロセスを AWS サポート側で実施してもらったところ、対象インスタンスの起動及び RDP 接続でも問題なく接続が可能となり、解決に至りました。

※今回の事象について、AWS サポート側からは詳細な原因等についての明確な返答がありませんでした。また、再度同じ現象が発生した場合には、同様にサポートへ依頼をする必要があるとのことでした。

移行後の効果

オンプレミスサーバが故障する不安を抱える必要がなくなり、サーバ設置場所にエアコンの涼しい空気が行くよう配慮する必要もなくなりました。同業他社ではまだ多数の同様システムが動作しているとのことで、今後も要望があれば対応・実施していきます。

まとめ

昨今の情勢に適応した柔軟かつ効果的な利用を促進するクラウドである AWS。その中でもオンプレミスからクラウドへの移行といったマイグレーションにフォーカスを当て、AWS への移行の経緯や実移行に至るまでの準備などの事例をご紹介しました。

 

投稿者プロフィール

わんちゃん
わんちゃん
<インフラエンジニア>
■ AWSエンジニア目指して猛勉強中!
■ 実務や試験学習(.ComMaster、基本情報技術者試験)を通してスキルUPを図っています!
■ AWSサービスのみにフォーカスせず、AWSを利用するために必要となるネットワークやサーバーの知識などについても積極的にブログでの情報発信を行っています。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です