パパが亡くなったので、　実家の会社にあるラック2台 Xenserver を　AWS リフトしてみた

お父さんにたのまれ、　零細企業に構築されたクラスターラック2台を無償で構築し、２０年のサーバをAWSにリフトシフトした話。
※ApplicationMigrationService,ServermigrationService などさまざまな機能がありますが、まずは基本的な作業がいまだにできるということを前提にした記事です。これらの機能についてはまた別の記事で！
※ただいま本件でのサイトは移行確認中のため（実際にはEC2とオンプレで切り替えて運用していることがあります。ただしAWSでのEC2の不都合などは発生していないことを踏まえてお断りさせていただきます。）

前提環境

要件　（母親 : 「ラックマウントうるさいから静かにして」）

あなたはソリューションアーキテクトです。　父の会社を継承するために、オフィスを縮小します。
サーバラック２棟に収まった「ハイパーバイザ」「iSCSI/NFS」と「RAID」と「ファイルサーバ」さらには
毎月　固定IP８回線にかかる費用を　抑えて欲しい。
ただし、会社のメールは閉じられた環境からのアクセスにして欲しいです。

★★ ラックのファンが全力でうるさいので　コスト効率よく、運用できる＆職場を静かにしなさい。★★

むずいな・・・

条件

 移行先   : AWS (Tokyo region)
って　SGにする
 仮想環境 : Citrix Xenserver 6.5 + SP1　＜EOL＞
      VM : Ubuntu 12.04LTS , 14.04LTS, CentOS ... などなど
 作業PC : Windows 10 [WInSCP , Gitbash, Chrome , AWS CLI]
      HDD: VM Export 作成ストレージ

　　やりたいこと

    1. S3にVMImport & Export でデータを格納しAMIを作成する
    2. EC2
    3. （記事を分けます）Route53(6ドメイン) をお名前.comから移動する
    4. （記事を分けます） VPNGateway(零細企業だと要相談)→　フレッツ固定IPで接続する＆AWS WorkMailにする

できるのか？　

公式AWS の　サイトにリンクたどりつく
- Citrix のページにいってみてね・・・という不安なリンクが！？
  - Citrix — Importing and Exporting VMs on the Citrix website.
- - 参考: https://docs.aws.amazon.com/vm-import/latest/userguide/vmimport-image-import.html
あまりに古すぎて　Xenserver(2021年時点の記事では 8.x の移行程度)　
- →「やってダメなら考える」というアジャイルの考え方でトライしてみる
- - 参考： https://docs.citrix.com/en-us/xencenter/current-release/vms-exportimport.html
  - 参考：　　https://docs.citrix.com/en-us/xencenter/current-release/vms-exportimport.html

移行してみる

　Windows 10 で以下の作業を大まかに記載します。

1. Xenserver client から　対象のVMを選び、それぞれ　と作成していきます。
        CreateSnapShot　→　SnapshotsList　→　ExportFile (OVA+VHD)　
2. 作業PC（windows）に格納する。
    作成したOVA ファイルを　出力するには　マシンのVHDサイズが必要になるので外付けHDDなどを用意しましょう。
3. ファイルはS3に転送する
    AWS CLI から　vmexport するために、マシンにインストールしておきましょう。　作業のためにIAMやクレデンシャルなども用意します。

IAM を準備する

## 移行ポリシ作っておく
aws iam  create-role --role-name vmimport --assume-role-policy-document file://trust-policy.json
aws iam put-role-policy --role-name vmimport --policy-name vmimport --policy-document file://role-policy.json

S3 バケット作る

　※　 S3 バケットとアクセスポリシは　ユーザからのアップロードができることだけなのでこちらは割愛します
ポイント： vmimport 後コンバータがSTSアクセスできるようにしておくこと。（ブロックしてるとNGになる）
 ## --> Bucket policy

S3 へファイルを転送（15+40Gib で　1h from 光回線）

aws s3 cp  /d/server.ek.221/5b******-a605-4b1e-9d3e-******2cb.vhd s3://*****-disk-images/
aws s3 cp  /d/server.ek.221/a1******-33ab-47db-9a57-******3be.vhd s3://*****-disk-images/
aws s3 cp  /d/server.ek.221/server.ek.221.ovf s3://ctsj-disk-images/

準備: S3に配置したVMImport をするための　VHD を指定するためのメタ情報をJSON形式で作成
（S3バケット上に import/server.ek.221 といフォルダを作って作業しました。　server.ek.221 は　弊社の移行サーバの名称なので任意で良いです）

[
    {
      "Description": "First disk",
      "Format": "vhd",
      "UserBucket": {
          "S3Bucket": "*****-disk-images",
          "S3Key": "import/server.ek.221/5b******-a605-4b1e-9d3e-******2cb.vhd"
      }
    },          
    {
      "Description": "Second disk",
      "Format": "vhd",
      "UserBucket": {
          "S3Bucket": "*****-disk-images",
          "S3Key": "import/server.ek.221/a1******-33ab-47db-9a57-******3be.vhd"
      }
    }
  ]

aws ec2 import-image --description "ek.220" --disk-containers file://containers-ek.json

### おまけ：　インポートを「進捗確認する方法」　と「途中で止める方法」　※ import-ami-id をそれぞれ読み替えてください。
## [NOTE:Status] aws ec2 describe-import-image-tasks --import-task-ids import-ami-030175bba8ec254be
## [NOTE:Cancel] aws ec2 cancel-import-task --import-task-id import-ami-030175bba8ec254be
#ID=
#aws ec2 describe-import-image-tasks --import-task-ids $ID

※※ vm import した際のコマンド
- （冗長的ですが、こちらの　ImportTaskIdをメモしておくことで、aws ec2 のimport タスクのコマンドの利用が可能になります。）

## AMI名　（ImportTaskId）をメモしておくこと。　EC2/AMIの中からどれかわからないくなる。　またAMIにラベルを後でつけてもよい
    {
        "Description": "ek.220",
        "ImportTaskId": "import-ami-03017******ec254be",
        "Progress": "1",
        "SnapshotDetails": [
            {
                "Description": "First disk",
                "DiskImageSize": 0.0,
                "Format": "VHD",
                "UserBucket": {
                    "S3Bucket": "*****-disk-images",
                    "S3Key": "5b******43-a605-4b1e-9d3e-******c2cb.vhd"
                }
            },
            {
                "Description": "Second disk",
                "DiskImageSize": 0.0,
                "Format": "VHD",
                "UserBucket": {
                    "S3Bucket": "*****-disk-images",
                    "S3Key": "a1******-33ab-47db-9a57-******3be.vhd"
                }
            }
        ],
        "Status": "active",
        "StatusMessage": "pending"
    }

AMI が作成された状態を確認 (すみません・・・Importしたイメージを作成助詞しまったため差し替えます)
作成されたAMIから　EC2を通常のインスタンス作成同様にVPC上に起動させます。
- EC2 の作り方なのでこちらは、割愛します。
AMIから作成したEC2　（起動なるか！？）
正常起動の確認

成功です！
- ※こちらの作業を台数分　コツコツと移行します。

サーバの起動確認　（Webサイトとして成立しています）　 :

サンプル: 家業ECサイトです。おもにサーバのラックやサーバ製品を販売しています）

　総括：　できる！うごく！感動した！

- 大体以降は1台　XenserverのExportから(20分)、S3転送（30h）、VMImport（１０分）　くらいでした。

なにがすごいのか？　ただのVMImport ではないのか？

サポート範囲外のVMImportも動いたところ、移行ができればOSのアップグレードは手段として可能です！
- Xenserver のサポートは切れているが・・・（自己責任ではあるがTRYの価値あり）
  - - 参考：　https://docs.aws.amazon.com/ja_jp/vm-import/latest/userguide/prerequisites.html
- 移行したのはXenserver6.5 のため　（何年前のEOL）なVMが　EC2で普通にリフトマイグレーションできたこと。　
- 当然と言えば当然ですが、VMは　OVF形式フォーマットで出力し。そのVMイメージは　しっかりEC2として成り立ちます。
- 通信はできるのか？　（はい！　こちらをご覧ください。実家の家業ECサイトです。おもにサーバのラックやサーバ製品を販売しています）

移行後のポイント

「AWSの請求が600円から1万円になったでござる」　
- ※ AMI / Snapshot確保の場合は、費用に注意
  - Snapshot 単体ではアーカイブにすることで維持費を削減できますが、VMImportするとAMIが作成され
    - [AMI]---> [Snapshot] の関係で保持、ハンドリングされるためSnapshot単体のアーカイブができません。　
    - 復旧やバックアップ戦略を除いた場合、 Snapshot とAMIは削除するか、OVFイメージとVMImportメタファイル（JSON）をS3にアーカイブすることをお勧めします。
- 低レベルインスタンスでもEC2や運用は可能ですが、そこで費用を抑えたにもかかわらずSnapshotの削除とAMIはインスタンス起動後にどこまで利用するか計画しましょう。
- ラックからの移行で　８台のマシンを移行して、EC2運用をはじめないままひとまずSnapshotを保持したままで大体　予想外の金額となりました。
- 新しい機能「Snapshotをゴミ箱へ」　は、Snapshotを削除というよりも、保持したまま論理削除的に見えない状態（除外する）なので、こちらもこちらで　Snapshotの維持費用がかかります。

感想: AWS は7Rに衝撃を受ける話

「マイクロサービスにできないサーバ移行はダサい」と思っていた過去

AWSの７Rに出会う前、大槻が思っていたAWSにリフト＆シフト　は　「オンプレからかっこいいマイクロサービスにすること」
仕事で　コンテナ・クラウド・DevOpsといろいろやっているものの、そのままEC2に移し替えるのは勿体無いなと思っていた過去があります。

AWSは「選択肢を提供している」

その７R「６Rから VMWare on AWS」のリロケートという言葉をニュースで耳にした時に
　「え！　Retainもいいの！？」から
移行にはさまざまな考えや方式がある。ダサいカッコいいだけではなく、事業をどう継続化させモダイズの一歩「どうシフトに導くか」などを考える手段を提供してくれます。
選択肢を残してくれるということは、古いオンプレ環境や　零細企業にあった　ラックにあるハイパーバイザ（保証がきれてる）からAWSへの移行が簡単におこなえる。
選択肢が提供されるということは、可能性を伸び代にすることができるということです。企業の大小に限らず、「やってダメなら考える」がトライできる。この考え方、ちょっと素晴らしいですよね。
　※「AWSは選択肢を提供してくれる　素晴らしい話」
- そのあたりの記事　大槻手前味噌ですが　仕事で re:invent 行った時の記事が〜　ググると出てきます.

参考）　 Amazon Web Services ブログ '移行パス（クラウド移行戦略）をワークショップで策定する' より

- 参考: https://aws.amazon.com/jp/blogs/news/migrationpath-workshop/!

皆様も「父の意思」を受け継ぐ時が来たらこちらの記事きっとお役に立つはずです

ぜひ、Xenserverからの移行や　古いハイパーバイザからの移行にこまねいていたら、こちらの記事がお役に立てれば光栄です。若干端折っている部分があるので、コメントいただければ　アドバイスや補足いたします。

以上！