技術Topics
SCSKのAWSマイグレーションに関する技術情報をご紹介いたします。
SCSKのAWSマイグレーションに関する技術情報をご紹介いたします。
前回「CloudMigration基礎:手法とステップ」ということで開始いたしましたが、以降は実例を記載していこうと思います。なにごとにおいても事前調査・事前準備ということで設計行為が必須となり、Migrationも同様です。また方式・ツールの差異はあれども、大体やることは一緒です。そこで今回は『エージェント方式：CloudEndureMigration』『エージェントレス方式：VMImport』を例に「CloudMigrationにおける事前調査・事前準備」における勘所を記載していこうと思います。
CloudMigration基礎については、以下の3回で投稿してまいります。
①CloudMigration基礎:手法とステップ
②CloudMigration基礎:実例-事前調査・事前準備編 ：☆彡今回ここ
③CloudMigration基礎:実例-移行作業編
Migration案件は全体として以下ステップを踏むことになります。
要件確認については、『要求される全体日程』や『システムとしての移行可能時間帯・時間枠：停止可能時間枠』『移行単位（システムごとやサーバごと）』『移行予算』などといった要求事項・制約事項・条件を明確にするとともに、『各種実務を担当する人の役割』の明確化など確認・実施しなければならないことは多いですが、当投稿では割愛いたします。但し、事前調査結果との突合せ・Fitgap、結果が、移行方式を含めた移行設計に結実しますので、重要なステップであることは理解しておいていただけると幸いです。
まず、以下を参照ください。
CloudMigrationはツール・手法の違いはあれど、
ことで共通しています。このため、事前調査は、①移行対象サーバ ②ネットワーク環境 に対して行うこととなります。（③Cloud環境という観点もありますが ネットワーク環境含め細かいところはサイジングやセキュリティグループなどインフラ設計の領域になりますので、最低限のことのみ記載します）
①移行対象サーバのチェックポイント
基本的には「サーバ・機器一覧」「サーバ・機器仕様」を頂くことになります。
必要な情報は以下の通りです。
移行後に適応するインスタンスタイプが選択できるかを確認します
移行後のストレージサービス、タイプの決定並びに移行所要時間の測定に利用します
ディスク情報と重複しますが、、例えばOS上のRAID類似機能（Windows：スパンボリューム、Linux：LVM）が構成されていないか、NFSなどのリモートストレージ情報を確認することも重要です。（移行対象にならなかったり、関連性を調べることは重要）
移行後にどのようなAWSサブネット構成にするか等の設計に利用します
移行ツールによっては追加でプログラム導入が必要になるため、取得の必要があります。
任意ですが、ソフトウェア導入情報の補完を兼ねます。
移行ツールによってはOSのFW機能が移行プロセスを阻害する可能性があるため、現状把握のために利用します。また、パブリッククラウド移行後は基本的にセキュリティグループでの制御が中心となるため、設定の移管の可能性を検討するための材料となります。
移行作業（パブリッククラウドに展開後のOS設定まで含む）に必須の情報となります。
任意ですが、よくあるのはcronやtask、JP1などのジョブ実行設定情報。移行したら動作してしまったといった移行時トラブル防止のため
サーバ概要情報～ネットワーク情報くらいまでなら採取できるが顧客の環境仕様によってはトラブルになる場合がある
②ネットワーク環境のチェックポイント
基本的には「ネットワーク物理構成図」「ネットワーク論理構成図」「その他FW・プロキシ設定資料」を頂くことになります。
必要な情報は以下の通りです。
移行もさることながら、AWSのネットワーク構成をどうするかにも関わります。ネットワークポリシーやネットワーク帯域など各種確認することも多いですが、提供されたら一読するようにしましょう。
移行ツールはInternet/WANを介する形式を前提としています。場合により穴あけを依頼する必要もありますので、事前に構成、設定を確認するとともに、今後の依頼内容を明確にすることをお勧めします。
移行ツールはInternet/WANを介する形式を前提としています。場合によりプロキシ設定追加を依頼するケースもありますので、事前に構成、設定を確認するとともに、今後の依頼内容を明確にすることをお勧めします。
移行にあたってのネットワーク構成変更が必要になるので最低限こちらは確認するようにしましょう。
まず、VMImportにおける事前準備の作業工程については以下の通りとなります。
作業No1～11については、一般的なAWSの契約、設定内容となるため、割愛します。
作業No17～18については、オンプレミスなど移行元環境に依存する内容のため、割愛します。
では、No12～16まで具体的なイメージとともに説明していきます。
No12～No16については、VMImportを実行するための、作業環境および移行元ファイルを保管するための環境準備作業となります。
No12 IAMユーザのアクセスキー作成（VMImport用）
・No2で作成したIAMユーザで、アクセスキーを発行してください。なお、当該IAMユーザに割当てるロールやポリシはadministratorAccess相当のものとしてください。
No13 ポリシの作成（VMImport用）
・①IAMより「ロール」を作成します。一般的なユースケースは「EC2」とし、この時点では「ポリシ」は割り当てずにまず作成してください。名前は「vmimport」としてください。
・②作成した「ロール」を開き、「インラインポリシーの追加」から「ポリシー」を作成してください。ポリシーの内容は以下の通りです。名前は「vmimport」としてください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ec2:CopySnapshot",
"ec2:Describe*",
"ec2:ModifySnapshotAttribute",
"ec2:RegisterImage"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::s3b-ova"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::s3b-ova/*"
}
]
}
※上記s3b-ovaは、ImportするOVAを補完するS3Bucket名です。任意で修正してください
・③作成した「ロール」を開き、「信頼関係」タブに移動し、「信頼関係の編集」をクリックして、以下のようにポリシードキュメントを書き直してください。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "vmie.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:Externalid": "vmimport"
}
}
}
]
}
※こちらを実施すると、信頼されたエンティティが「ID プロバイダー vmie.amazonaws.com」となります。
No14 SecurityGroup作成（VMImport用）
・No15で作成するVMImportのワーカーEC2に接続、作業するためのSecurityGroupを作成してください。基本的には、VMImportのワーカーに接続するためのIPアドレスからSSHやRDPアクセスできればよいです。
No15 VMImport用インスタンス作成、初期設定
①EC2をデプロイします。EC2はWindowsでもLinuxでも問題はありませんが、VMImportではawscliコマンドを利用しますので、「Amazon Linux 2」を選択することをお勧めします。その際の注意事項は以下の通りです。
・サブネットは移行サブネットとすること
・自動割り当てパブリックIPは「有効」とすること。※VPNなどない場合
・セキュリティグループはNo14のものを割り当てること
②インスタンスが起動したらSSH(Windows構築の場合はRDP)接続し、初期設定として、以下を実施してください。
・aws configure コマンドで、No12で発行したアクセスキーを割当
#aws configure AWS Access Key ID [****************THW3]:入力、Enter AWS Secret Access Key [****************WYfE]:入力、Enter Default region name [ap-northeast-1]:リージョンを入力、Enter Default output format [json]:jsonと入力、Enter
・移行で利用する「containers.json」ファイルを作成する。参考は以下
[
{
"Description":"",
"Format":"ova",
"UserBucket":{
"S3Bucket":"s3b-ova",
"S3Key":"xxxx"
}
}
]
※s3b-ovaは任意のBucket名としてください
※S3Keyのxxxxは移行の際に修正すればよいですが、ovaファイル名を記載します。
No16 S3Bucket作成・アクセス確認
・①AWSマネジメントコンソールからS3Bucketを作成してください。
・②VMImport用インスタンスから以下の通りコマンド実行し、アクセス可能なことを確認ください。
#aws s3 ls s3:// 2020-10-27 10:40:44 s3b-ova
※御覧の通り作成されているBucketが表示されると思います。
※表示されない場合、No9 S3Endpoint作成・アタッチが実施漏れしている場合があります。見直してください。
No17～No18 についてはそれぞれの環境に依存しますが、元環境がVMware:vSphereの場合、VIClientやWebClientからのExportは、ブラウザやツールの仕様・制約上、仮想マシンのサイズによっては失敗する可能性があります。このため、可能であればVMWarePowerCLIを導入の上、export-vappコマンドからovaで取得できるようにしておくことが推奨されます。
AzureやCitrixなど別プラットフォームの場合でも同様のことが起こる可能性もありますが、それぞれのベンダに確認の上、環境準備するようにしてください。
まず、CloudEndureにおける事前準備の作業工程については以下の通りとなります。
作業No1～11については、一般的なAWSの契約、設定内容となるため、割愛します。
作業No18～19については、オンプレミスなど移行元環境に依存する内容のため、割愛します。
では、No12～17まで具体的なイメージとともに説明していきます。
No12 CloudEndureサブスクライブ
・①AWS管理コンソールから「AWS MarketPlace」に移動します。移動後に「製品を検出」からCloudEndureで検索し、「CloudEndureMigration」を選択します。
・②CloudEndureMigrationへたどり着いたら、「Continue to Subscribe」をクリックし、続いて表示される画面で、「Having issues signing up for your product? 」から「Click here」をクリックし、サブスクライブ画面へ移動します。
・③サブスクライブ画面からメールアドレス、パスワード等必要事項入力・チェックの上「comtinue」をクリックします。
・④設定したメールアドレスに「CloudEndure」からメールが届くので、そちらに従い、処理を継続、CloudEndureサイトにログインします。
表示From：no-reply@cloudendure.com To:yuuzou.tokumaru@scsk.jp Title:Complete your CloudEndure Migration account registration Thank you for your request to set up a free CloudEndure Migration account using the email address yuuzou.tokumaru@scsk.jp. Please confirm your account request to complete registration. Regards, CloudEndure, an AWS Company Any questions? Contact AWS support.
※CloudEndureMigrationは各メールアドレスに対してサブスクリプションされます。いくつかの顧客の移行を１アカウントで兼ねることも可能です
※サブスクリプションにより、90日間利用可能となります。有効期限が切れるまでは、再サブスクリプションは不要です。
No13 ポリシの設定（CE用）
・①AWSコンソールよりIAMに移動し、「ポリシー」から新規にCloudEndure用ポリシーを作成してください。ポリシーの内容は以下の通りです。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:*/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "RunInstances"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:*/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateVolume"
}
}
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": [
"ec2:RevokeSecurityGroupIngress",
"ec2:DetachVolume",
"ec2:AttachVolume",
"ec2:DeleteVolume",
"ec2:TerminateInstances",
"ec2:StartInstances",
"ec2:RevokeSecurityGroupEgress",
"ec2:StopInstances"
],
"Resource": [
"arn:aws:ec2:*:*:dhcp-options/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringLike": {
"ec2:ResourceTag/Name": "CloudEndure*"
}
}
},
{
"Sid": "VisualEditor3",
"Effect": "Allow",
"Action": [
"ec2:RevokeSecurityGroupIngress",
"ec2:DetachVolume",
"ec2:AttachVolume",
"ec2:DeleteVolume",
"ec2:TerminateInstances",
"ec2:StartInstances",
"ec2:RevokeSecurityGroupEgress",
"ec2:StopInstances"
],
"Resource": [
"arn:aws:ec2:*:*:dhcp-options/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringLike": {
"ec2:ResourceTag/CloudEndure creation time": "*"
}
}
},
{
"Sid": "VisualEditor4",
"Effect": "Allow",
"Action": [
"ec2:DisassociateAddress",
"ec2:CreateDhcpOptions",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:DeregisterImage",
"ec2:DeleteSubnet",
"ec2:DeleteSnapshot",
"ec2:ModifyVolumeAttribute",
"ec2:CreateVpc",
"ec2:AttachInternetGateway",
"ec2:GetConsoleScreenshot",
"ec2:GetConsoleOutput",
"elasticloadbalancing:DescribeLoadBalancers",
"ec2:CreateRoute",
"ec2:CreateInternetGateway",
"ec2:CreateSecurityGroup",
"ec2:CreateSnapshot",
"ec2:ModifyVpcAttribute",
"ec2:ModifyInstanceAttribute",
"ec2:ReleaseAddress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AssociateDhcpOptions",
"ec2:ImportKeyPair",
"ec2:CreateTags",
"ec2:RegisterImage",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:CreateRouteTable",
"ec2:DetachInternetGateway",
"iam:ListInstanceProfiles",
"ec2:AllocateAddress",
"ec2:ReplaceNetworkAclAssociation",
"ec2:CreateVolume",
"kms:ListKeys",
"ec2:Describe*",
"ec2:DeleteVpc",
"iam:GetUser",
"ec2:CreateSubnet",
"ec2:AssociateAddress",
"ec2:DeleteKeyPair",
"ec2:CreateNetworkAclEntry"
],
"Resource": "*"
},
{
"Sid": "VisualEditor5",
"Effect": "Allow",
"Action": [
"ec2:RevokeSecurityGroupIngress",
"mgh:CreateProgressUpdateStream",
"kms:Decrypt",
"kms:Encrypt",
"ec2:RevokeSecurityGroupEgress",
"ec2:DeleteDhcpOptions",
"ec2:RunInstances",
"kms:DescribeKey",
"kms:CreateGrant",
"ec2:DeleteNetworkAclEntry",
"kms:ReEncrypt*",
"kms:GenerateDataKey*"
],
"Resource": [
"arn:aws:mgh:*:*:progressUpdateStream/*",
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:key-pair/*",
"arn:aws:ec2:*:*:dhcp-options/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:network-acl/*",
"arn:aws:ec2:*:*:placement-group/*",
"arn:aws:ec2:*:*:vpc/*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*::image/*",
"arn:aws:ec2:*:*:snapshot/*",
"arn:aws:kms:*:*:key/*"
]
},
{
"Sid": "VisualEditor6",
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"mgh:ImportMigrationTask",
"mgh:AssociateCreatedArtifact",
"mgh:NotifyMigrationTaskState",
"mgh:DisassociateCreatedArtifact",
"mgh:PutResourceAttributes"
],
"Resource": [
"arn:aws:mgh:*:*:progressUpdateStream/*/migrationTask/*",
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*::network-interface/*",
"arn:aws:ec2:*:*:dhcp-options/*",
"arn:aws:ec2:*::snapshot/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*::image/*"
]
},
{
"Sid": "VisualEditor7",
"Effect": "Allow",
"Action": "ec2:Delete*",
"Resource": [
"arn:aws:ec2:*:*:route-table/*",
"arn:aws:ec2:*:*:dhcp-options/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:internet-gateway/*"
],
"Condition": {
"StringLike": {
"ec2:ResourceTag/Name": "CloudEndure*"
}
}
},
{
"Sid": "VisualEditor8",
"Effect": "Allow",
"Action": "ec2:Delete*",
"Resource": [
"arn:aws:ec2:*:*:dhcp-options/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringLike": {
"ec2:ResourceTag/CloudEndure creation time": "*"
}
}
}
]
}
※名前は特に指定はありませんが、「cloudendurepolicy」とでもしてください
No14 IAMユーザの作成（CE用）
・①AWSコンソールよりIAMに移動し、「ユーザー」から新規にCloudEndureユーザを作成します。
アクセスの種類は「プログラムによるアクセス」を設定し、アクセス許可の設定では「既存のポリシーを直接アタッチ」を選択の上、No13で作成のポリシーを割り当てしてください。
・②ユーザの作成をクリックすると、アクセスキーとシークレットキーが発行されます。こちらのキーをファイルダウンロードしておいてください。
No15 SecurityGroup作成（CE用）
・①CloudEndureインスタンスのSecurityGroupを作成します。CloudEndureインスタンスのデータ同期で利用されるポートは「TCP 1500」となります。ソースはインターネット経由でデータ同期かVPN/WAN経由でデータ同期かにもよりますが、事前に確認ください。
※インターネット経由同期の場合は、移行元のインターネット接続時のグローバルIPになると思います。
※VPN/WAN経由同期の場合は、移行元のプライベートIPやプライベートサブネットなどで搾れると思います。
No16 CloudEndureProject作成
・①ブラウザで「cloudendure.com」に接続し、「Login」をクリックしてCloudEndureSaasにログインします。※ログインID、パスワードはNo12で設定したものを利用します
・②ログイン後、「CreateProject」をクリックし、CloudEndureプロジェクトを作成します。
CloudEndureプロジェクトは１つの移行単位と考えてください。
・③プロジェクト作成後、プロジェクトの「AWS CREDENTIALS」からNo14で作成したアクセスキー、シークレッキーを入力し、Saveをクリックします
こちらにより、CloudEndureプロジェクトと、対応するAWS環境（AWSアカウント）が確定します
No17 CloudEndureインスタンス設定
・①CloudEndureプロジェクトの「REPLICATION SETTINGS」からCloudEndureインスタンスの設定ができますので、以下の通り設定してください。ここでは最低限以下の設定をすることとします
必須：Replication Servers：CloudEndureインスタンスやEC2変換で一時的に利用されるインスタンスタイプや、所属するサブネット、セキュリティグループを設定することができます。また、データ同期時にVPNを利用するか、DISKの暗号化を設定することができます。
任意：Staging Area Disks：CloudEndureインスタンスやEC2変換で一時的に利用されるインスタンスに紐づけるEBSのタイプを選択できます。コストや移行性能を鑑み設定してください
任意：Staging Area Tags：CloudEndureインスタンスのNameなどのtagを設定できます。何もしなければ「Cloud Endure～～」のようなデフォルト設定が実装されます
任意：Network Bandwidth Throttling：データ同期時にネットワーク帯域を設定することができます。あまり設定することもないですが、InternetやVPN/WANの性能と業務影響鑑み必要に応じて設定することをお勧めします。
ここまでで、CloudEndureの準備作業は完了です。CloudEndureエージェントを1台でもインストールすると、No17の設定に従い、CloudEndureが起動されてきます。
No18～No19 については移行元環境に依存しますが、移行開始（CloudEndureエージェントインストール）時に慌てふためくよりは、、ということで事前に準備しておくことをお勧めします。。
No18 事前確認・前提機能インストール
・Windows、Linuxに限らずCloudEndureエージェントインストールの前提条件があります。下記参考に事前確認、必要に応じ事前インストールしてください。Windowsであれば.NET Framework、Linuxであればカーネルにマッチしたkernel-develなどが必要になります。
Installation Requirements for Windows Source Machines
※CentOS/RHELにおいては、CloudEndureエージェントインストール時にyumで自動的に前提パッケージがインストールされるのですが古いCentOSやRHELでCloudEndureエージェントインストールを試みた際、KernelとKernel-Headersはインストールされていたので飛ばされましたが、Kernel-develがインストールされておらず、インストレーション内でyumからKernel-develをインストールしに行った際に、Kernel<Kernel-develというバージョン不一致が発生し、その後のインストールプロセスが失敗しました。結果としては手動でkernelバージョンにマッチしたkernl-develをwgetでインストールして回避しました。
No19 インターネット疎通確認・必要であればインターネット疎通設定
・CloudEndureにおいては、移行元マシンもすべてInternetアクセスが可能である必要があります。意外とこの辺見過ごされがちなのですが、移行元マシンにProxyが設定されてない、Proxy自体にCloudEndureサイトが登録されてない、そもそもProxyソフトによってはProxy利用するために移行元マシンの認証設定を入れておかないといけないetc、いろいろあります。変更作業をお客様のネットワーク・セキュリティチームに依頼に必要となる場合があるので事前にインターネット疎通確認・疎通検証はしておくことを強く推奨する次第です。
ここまでいかがでしたでしたでしょうか？事前調査・事前準備も大変ですよね。やること・検討することが多いです。
なので、
事前調査：なるべく自動化・定型化し、はやくかつ正確に行う。分析（および移行方式の決定と移行設計）と事前準備にリソースを割けるようにするのが重要
事前準備：調整、依頼することも含め早めに着手しておくのが重要。
と言えるかと思います。
次回は、『③CloudMigration基礎:実例-移行作業編』ということで、VMImportとCloudEndureを利用してのCloudMigration（EC2立ち上げ・OS設定）作業について投稿を予定しています。
このサイトをシェアする
ツイート