狠狠撸

パブリッククラウドへの業務システム移行検証
- 第2回 -
株式会社シイエヌエス
基盤システム事業部
COPYRIGHT (C)CNS Co., Ltd. All rights reserved.

目次
1.はじめに
2.検証内容のおさらい
3.検証の実施と考察
4.想定外の結果の解説
5.今後の検証課題
6.次回について

1.はじめに

1.はじめに
?今回は前回示したパブリッククラウド(AWS)へのシステム移行方法に基づき、
各種検証を実施しました。
?検証では仮想マシンをパブリッククラウド(AWS)への移行手順や、発生した問
題などを紹介します。
COPYRIGHT (C)CNS Co., Ltd. All rights reserved. 4

?移行検証を実施する前に前回示した移行方法?観点のおさらいをします。
右記の3つのフェーズに対して5つの検証を実施します。
フェーズ毎の検証イメージは以降の資料に示します。
※オープン仮想化フォーマット(以降、OVFと記す。)

検証方法?観点～移行先環境～
①AWS環境構築の検証
AWS上に仮想マシンを移行するため
の環境作りの検証を行います。
②OVFインポートの検証
AWS上にOVFをインポートをする検
証を行います。
社員
VGW
Private
Subnet
東京リージョン
OVF

検証方法?観点～移行作業～
③SSHログインの検証
作業端末からAWS上の仮想マシン
へSSHログインするために必要な設定
を行います。
④サーバ内設定の検証
AWS上でアプリケーションを動作させ
るために必要な設定変更を行います。
社員
VGW
Private
Subnet
仮想マシン

検証方法?観点～移行完了後～
ブラウザ表示
⑤アプリケーションの動作確認
DBからの情報取得に問題がないか
社員
VGW
Private
Subnet
仮想マシン
HTTPリクエスト
⑤アプリケーションの動作確認

3.検証の実施

3.検証の実施～移行先環境～
移行先環境フェーズの検証の目的は
OVFのAWS環境へのインポートを目
的とします。
OVFインポートする前段として
『①AWS環境構築の検証』を実施し
ます。
社員
VGW
Private
Subnet
OVF

3.検証の実施～①AWS環境構築の検証～
1）S3バケットの作成
VM Importを使用して仮想マシンをインポートするため、イメージ格納先としてAmazon S3 バケットが必要とな
ります。
このため、本検証ではイメージ格納用として新規のバケットを作成しております。

2）VM Import サービスロールの作成
VM Import機能を用いてAmazon S3 バケットからイメー
ジのインポートを実施する場合、特定の操作を実行するため
にロールが必要となります。
vmimportという名前のロールを作成し、このロールをVM
Importが引き受けることを信頼関係ポリシードキュメントで指
定し、IAM ポリシーをロールにアタッチさせます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "vmie.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals":{
"sts:Externalid": "vmimport"
}
}
}
]
}
aws iam create-role --role-name vmimport --assume-role-policy-document file://trust-policy.json
trust-policy.jsonファイルのサンプル
AWS CLIのcreate-role コマンドにてロール(vmimport)にアクセス権限を付与します。この際、上記のjsonファイルをパラメータに指定します。

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::sp-ikou"
]
},
※右に続く
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::sp-ikou/*"
]
},
{
"Effect": "Allow",
"Action":[
"ec2:ModifySnapshotAttribute",
"ec2:CopySnapshot",
"ec2:RegisterImage",
"ec2:Describe*"
],
"Resource": "*"
}
]
}
role-policy.jsonファイルを作成して、
イメージが格納されるS3バケットを指定します。
aws iam create-role --role-name vmimport --assume-role-policy-document file://trust-policy.json
role-policy.jsonファイルのサンプル
AWS CLIのcreate-roleコマンドにてロール(vmimport)にポリシーをアタッチします。この際、上記のjsonファイルをパラメータに指定します。

3.検証の実施～②OVFインポートの検証～
1）イメージのAmazon S3バケットへのアップロード
AWS マネジメントコンソールより、Amazon S3バケットにイメージファイルをアップロードします。

2）VMのインポートの実施
Amazon S3へイメージファイルアップロード後、AWS CLI
を用いてイメージをインポートします。
import-imageコマンドを用いることでインポートはタスク化
されAWSで実行できるAMI形式に変換されます。
[
{
"Description": "test",
"Format": “vmdk",
"UserBucket": {
"S3Bucket": "sp-ikou",
"S3Key": “/SP_PROMO_2/SP_PROMO_2-disk1.vmdk"
}
}]
aws ec2 import-image --description "test" --license-type BYOL --disk-containers file://containers.json
containers.jsonファイルのサンプル
AWS CLIのimport-imageコマンドにてOVFをAMI形式に変換します。この際、上記のjsonファイルをパラメータに指定します。

3）AMI形式変換状況の確認
describe-import-image-tasksコマンドを用いることでイメージのAMI形式への変換状況を確認することが出来ます。
# StatusがcompletedになればAMI形式への変換が完了したことになります。

4）EC2インスタンスの作成と起動
作成したAMIを用いて新規にEC2インスタンスの作成を実施します。
※ここではEC2インスタンスの作成方法の詳細は割愛します。
作成したEC2インスタンスが初期化から2つのチェックを経て起動したことを確認しました。
起動完了!!

3.検証の実施～移行作業～
移行作業フェーズの検証の目的は
AMI形式に変換したファイルを読み込
みEC2インスタンスが正常に起動するこ
とを目的とします。
この検証では、移行時にありがちな以
下の対応忘れの場合、どのような挙動
となるかも確認してみました。
?VMware Tools のアンインストール
?ネットワークのDHCP 設定
社員
VGW
Private
Subnet
仮想マシン

3.検証の実施～③SSHログインの検証～
1）EC2インスタンスの接続情報の確認
SSHログインを実施するため、DNS名もしくはIPアドレスを確認します。
# 今回はDNS名にてSSHログインが可能か確認するようにします。

3.検証の実施～③SSHログインの検証～
2）SSHログインの確認
ターミナルツールを用いてSSHログインをDNS名にて実施
※移行元の環境でイメージを作成する前に
ネットワークをdhcp仕様に変更していないた
めSSH接続できないと予測してましたが、す
んなり接続出来てしまった。

3.検証の実施～④サーバ内設定の検証～
1）ネットワーク設定の確認
ネットワークインターフェースの設定を固定IPのまま移行した場合でも、SSH接続が可能であった。
ネットワークインターフェースの設定がどのように変化したか？どのような仕組で接続可能となったか確認しました。
想定外の結果①
オンプレミス環境の仮想マシンのインターフェース名がeno16777984であったのに対して移行後に
eth0に差し替わった。
また、差し替わったインターフェース(eth0)の構成がdhcpとして起動していることが分かった。

3.検証の実施～④サーバ内設定の検証～
2）VMware Toolsの状態確認
VMware Toolsをアンインストールしないまま移行した場合でも、インスタンスが正常に起動した。
移行後のVMware Toolsがどのようになったかを確認しました。
想定外の結果②
仮想マシンで稼働するサービスのVMware Toolsのアンインストールを実施しない状況であっても移行
後にVMware Toolsが削除されることでvmtoolsdが起動しない状況となったことが分かった。

3.検証の実施～移行完了後～
ブラウザ表示
移行完了後フェーズは、オンプレミス
環境のVMと同じ動作確認方法を用
いて同じ結果が得られることを確認する
ことが目的とします。
社員
VGW
Private
Subnet
仮想マシン
HTTPリクエスト
⑤アプリケーションの動作確認?比較

3.検証の実施～⑤アプリケーションの動作確認～
1）アプリケーションの動作確認
移行後OSが正常に起動したため、次にアプリケーションの動作確認を実施しました。
確認はオンプレミス環境の仮想マシンに用いた確認方法と同一の方法である
DBの内容を参照するjspを実行することで同じ結果が得られるかを確認します。
jspを実行して確認した結果、オンプレミス環
境の仮想マシンと同じ結果が得られたことで、
移行先であるAWS環境においても
正常に動作していることが分かった。

検証を終えて～考察～
1）検証での問題点はあったか？
大きな問題は発生しなかった???
ガイドラインに従っていないVM環境を移行した場合、AWS移行後のシステムへの接続は出来ないと考えていたため、
移行検証および移行後検証が(うまくいったという)想定外の結果となったことについては、『なぜ？』の疑問符がつく。
もしかしたら、AWSは誰でも犯しうるちょっとしたミス(ガイドラインに従っていない操作)を考慮して、正常な移行サービ
スを提供するように作成されているように思われる。
たとえば、OVFからAMIへ変換時にAWS上で正常動作させるための作業をしていたり、OS初回起動時に対して各
種の不整合を解決させることを行っていると推察します。
今回の移行検証にて想定していない事象については、『4.想定外の結果の解説』に提起します。

検証を終えて～考察～
2）今後の課題は見えたか？
課題はありそう???
今回検証で用いた移行前のVM環境は非常に単純な構成である。
VM Import機能を用いた単純な移行検証はこれで十分と言えるが、ちょっと複雑な構成の場合の移行については
以下のような課題があり、今後の検証課題として検討しなければならない。
たとえば、複数のNICを持つシステムを移行する場合、どのようにしなければならないのか？
たとえば、複数のディスクを持つシステムを移行する場合、どのようにしなければならないのか？
たとえば、AMI変換時に何が行われているのか？
たとえば、AWS移行後にOSのサービスの数に変化があるがその正体はなにか？
たとえは、移行はしたが、アクセス制御方法は何があって何が最適なのか？
etc…
上記のような課題については、『5.今後の検証課題』に提起します。

1）もともとのネットワークインターフェイス構成ファイル(ifcfg-eno16777984)が無くなる。
オンプレミス環境の仮想マシンのネットワークインターフェース名がeno16777984であったのに対して、
AWS移行後のネットワークインターフェース名がeth0となる。
/etc/sysconfig/network-scripts/ifcfg-eno16777984が削除されていることが判明した、
その代わりに/etc/sysconfig/network-scripts/ifcfg-eth0が新たに生成されており、
中身を確認するとdhcp仕様となっている。
このため、移行後の環境に対して接続が可能となったが、仮に移行前に同じインターフェース名(eth0)にして、ガイドラ
インに従わない方法(固定IPのまま)で移行した場合も、Importの際に設定が自動的に変更されdhcpを参照するよ
うになる。

2）VMware toolsが消えている。
ガイドラインに従わずVMware toolsを導入したままのイメージで、AWSへ移行を実施した場合、vmtoolsdが起動
していないこととVMware toolsがアンインストールされていることが判明した。
本来であれば、ガイドラインにしたがって、VMware toolsは事前に除去する必要があったがどこかのタイミングで除去
されている様子であり、AMIの作成時かOS初回起動時に行われたと推測している。
また、vmtoolsdが起動していない反面、クラウド移行により追加されたサービスが複数あることが判明している。正式
な調査は実施していが、以下のcloud関連のサービスが増えていると考えている。
?cloud-init-local.service
?cloud-init.service
?cloud-config.service
?cloud-final.service

1）複数のNICを持つシステムを移行する場合、どのようにしなければならないのか？
複数のNICが必要な場合はENIを利用するらしい。
複数のNICが必要な場合は、ENI(Elastic Network Interfaces)を利用する。
2つ目以降のNICのIPアドレスを指定する必要がある場合は、ENIを作成するときに指定しておく。
オンプレミスで利用していた設定ファイルを修正する場合は、MACアドレスの設定値に注意が必要です。
オンプレミス環境とは仮想NICのMACアドレスが変わってしまうため、MACアドレスの設定が行われている場合は削除
またはコメントアウトしておく必要がある。
こちらに関しては、次回以降の検証課題とする。

2）複数のディスクを持つシステムを移行する場合、どのようにしなければならないのか？
containers.jsonの記述を変更することで出来るらしい。
移行時に用いたimport-imageコマンドを実行する際に
containers.jsonファイルを指定します。
このcontainers.jsonの記述内容を変更
(2つめのイメージを追加)することで対応が可能になる。
こちらに関しては、次回以降の検証課題とする。
[
{
"Description": "First disk",
"Format": "vmdk",
"UserBucket": {
"S3Bucket": "my-import-bucket",
"S3Key": "/SP_PROMO_2/SP_PROMO_2-disk1.vmdk"
}
},
{
"Description": "Second disk",
"Format": "vmdk",
"UserBucket": {
"S3Bucket": "my-import-bucket",
"S3Key": "/SP_PROMO_2/SP_PROMO_2-disk2.vmdk"
}
}
]
複数ディスクを持つ場合のcontainers.jsonファイルのサンプル

狠狠撸

パブリッククラウドへのシステム基盘移行について(第2回)

Recommended

More Related Content

Similar to パブリッククラウドへのシステム基盘移行について(第2回) (20)

パブリッククラウドへのシステム基盘移行について(第2回)