みなさまこんにちは！ネットワールドSEの長岡です。
Part1から引き続き、「BlueXP backup and recovery」をAWS環境で使ってオンプレのデータをバックアップしてみた！ということでご紹介していきたいと思います。
前回はBlueXPにログイン編でした。
Part2ではConnector作成編で行こうと思います。
Connectorの説明はこちら
オンプレNetAppとAWSの仲介役の役割になります。
BlueXPを使って何かをやる場合、ほとんどのケースでこのConnectorが必要になると思います。
Connectorさえできれば、ほとんど勝ったも同然です。
Connectorを制する者はBlueXPを制すと言っても過言ではありません(笑)
Connectorを立てる場所は、クラウドかオンプレを選ぶことができます。
AWSだとEC2インスタンスとして、オンプレだとLinuxサーバを用意してそこにインストールすることになります。
今回はAWS上に立てていこうと思います。
EC2のLinuxを用意しておく必要はなく、BlueXPからデプロイすることが可能です。
BlueXP画面上部の「Connector」を押すと、このような画面が表示されるので、
「Create your first Connector」を押していきましょう。
クラウドプロバイダを選択します。今回はAWSで。
どんどん行きましょう。
ガンガン行こうぜ。誰も俺を止められない。
という気持ちを抑えて、一旦ここで止まりましょう。
ここではこの後の工程で使うIAMロールについての説明が記載されております。
英語だし読んでもあんまりわからないんですけど・・・という方のためにサクッとここでやった流れを書いていきます。
まずAWSマネジメントコンソールにログインし、IAMのポリシーに移動しましょう。
ポリシーの作成から先ほど一旦止まったBlueXPの画面に書いてある文字たちをコピー&ペーストし、ポリシーを作成します。
IAMポリシーができました。
次にIAMロールを作成していきます。
BlueXPの説明画面はこちら。とにもかくにもやってみよう。
AWSマネジメントコンソールのIAM → ロールに移動しましょう。
ロールを作成から手順通りに作っていきます。
IAMロールができました。
IAMポリシーを作って、IAMロールを作る。
IAMポリシーを作って、IAMロールを作る。
大事なことなので2回言いました。
ここで失敗談を1つ。
AWSのIAMポリシーにはデフォルトで「AdministratorAccess」というものがあります。
検証初期の頃に権限回りでハマりたくなかった私は、ここで選択するIAMポリシーを「AdministratorAccess」にしておりました。
メーカーがこうしろって言ってるやつって、どうせ必要最低限の権限なんでしょ？？
Administrator・・・素敵な響き。最強っぽい。神っぽい。
これならハマる気がしない、よしこれで行っちゃおう！
・・・こうして後々リストアがなぜかうまくできなくて大ハマりしました(笑)
原因はここで指定するIAMポリシーの権限だったようで、キチンと指定の手順、権限で進めたところ解決しましたので、郷に入っては郷に従えということで、自滅したSEの独り言でした。
ではIAMロールもできたことですので、Connectorの作成に戻っていきましょう！
Connectorを作るリージョン、権限回りを指定していきます。
ちなみにリージョンは日本ではTokyoのみになります。
クレデンシャルは任意の名前でよし。
RoleARNかAWSキーを選択できます。今回はRoleARNで進めていきます。
Role ARNは、作成したIAMロールの画面に記載がありますので、それをコピペします。
Connectorの名前、Connector Role、AWS Managed Encryptionを決める画面。
名前は任意。（EC2インスタンス名になります）
Connector Roleは先ほど作ったRoleとは別物です。
自分で予め作成しておくことも可能ですが、ここでは自動で作ってもらいます。
VPC、サブネットなどを決めていきます。
Proxyを使う場合はここで指定します。
1つでも通らないURLがあるとデプロイが失敗しますので、Proxy環境の場合はこちらのドキュメントをよくご確認ください。
（検証はProxyなしです）
セキュリティグループを作る or 選ぶ画面。
検証なのでここではゆるゆるで行っちゃいます。
最後の確認画面。ドキドキ・・・
作成中。大体10分以内には終わる印象です。
成功するとこんな画面になります。
ちなみに失敗するとこんな画面になります。
落ち着いて再チャレンジしましょう。
EC2インスタンスは残り続けてしまいますので、AWSマネジメントコンソールからEC2に移動して、失敗したConnectorを消すことを忘れずに。
EC2インスタンスを見ますと、しっかりできております。
検証ではパブリックIPを付与しておりますので、EC2 Instance ConnectからConnectorへログインすることもできます。
ログインするとこんな感じです。
Ubuntuのようですね。
普段この画面を使うことはありませんが、何か起きた時のサポート対応で、この画面からログ採取を求めらることはありますので、何かしらの方法で繋げる手段は確保しといたほうがよさそうです。
パブリックIPがなくても、ConnectorのプライベートIPにSSHで繋がる環境があれば、
Tera Termなどで接続も可能です。
その場合ユーザ名はrootは使えず、"ubuntu"になるようです。
パスワード認証は無く、デプロイ時に指定したキーペアで認証になりますので、
予め入手しといたほうがよさそうです。
それではPart2はここまでで、次回Part3はバックアップ編をお送りしようと思います。
ありがとうございました。
過去作はこちら。
Part1
