はじめてのAWS Snowcone – (7) EC2のセットアップ

はじめてのAWS Snowcone – (7) EC2のセットアップ

Clock Icon2021.12.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

しばたです。

本記事ではSnowconeデバイスでEC2インスタンスを利用する方法について解説します。

目次

免責事項

EC2のセットアップ

今回はAWS OpsHubを使いEC2の各種設定を行います。
AWS OpsHubのインストールとデバイスの初期設定については以下の記事を参考にしてください。

以降の作業はAWS OpsHubにサインインした状態からはじめます。

1. コンピューティングの開始

OpsHubではEC2関連の設定は「コンピューティング」としてまとめられています。
デバイス詳細画面の「コンピューティングを開始」欄を選び「使用開始」をクリックします。

するとコンピューティングの画面に遷移し、ここでEC2インスタンスの管理を行うことができます。

ざっくり「 セキュリティグループの無いEC2マネジメントコンソール 」だと思って頂ければ雰囲気は伝わると思います。
いちおう補足しておくと正確には「default」セキュリティグループが存在するのですがSnowconeにおいては全く使いません。セキュリティグループは無いものと考えて大丈夫です。

インスタンス一覧の他に、ストレージボリューム一覧やキーペアの一覧も参照できます。

2. キーペアの作成

通常のEC2と同じ様にSnowconeでもEC2キーペアを作成することができます。
キーペアタブにある「キーペアを作成」をクリックするとキーペアを作れます。

作成と同時に公開鍵をダウンロードできます。
ちなみに鍵はPEM形式です。

3. EC2インスタンスの作成

次にEC2インスタンスを作成します。
インスタンスタブにある「インスタンスを起動」をクリックすると作成ダイアログが表示されるので必要な情報をよしなに設定します。

AMIはジョブの作成時に指定したものから選択可能です。
まずは標準で用意されているAmazon Linux 2イメージを選んでいます。

インスタンスタイプは以前解説した様に以下の3種から選択可能です。

インスタンスタイプ vCPU Memory 同等タイプ 備考
snc1.micro 1 1GB t2.micro 最大2インスタンス
snc1.small 1 2GB t2.small 最大2インスタンス
snc1.medium 2 4GB t2.medium 最大1インスタンス

ネットワーク設定については物理NICの配下に仮想NIC(VNI)を作る形となります。
こちらは環境に応じてIPアドレスを設定してください。今回は静的にIPを割り当てています。

キーペアは前節で作成したものを選びます。
このダイアログから作成することもできますし、AMI作成時にパスワード認証を有効にしているのであればキーなしのインスタンスも作成可能です。

最後に「起動」をクリックするとインスタンスの作成が開始されます。

しばらく待つとインスタンスの状態が「実行中」にかわり利用可能になります。

インスタンスの詳細はこんな感じです。

ストレージボリュームはこんな感じでルートボリュームが増えています。

ちなみに別途ストレージボリュームを追加してEC2に増設(追加アタッチ)することも可能です。

とりあえずEBSの規則に合わせる形でデバイス名は/dev/sdfにしましたが、アタッチされたOS内部からは準仮想化ディスク(/dev/vda)として見える様です。

# 追加ディスクをアタッチしたOS内部でのコマンド実行結果
$ lsblk
NAME     MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda        8:0    0    8G  0 disk
tqsda1     8:1    0    8G  0 part /
mqsda128 259:0    0    1M  0 part
vda      252:0    0  100G  0 disk

「Amazon S3 へのインポート」ジョブの場合EC2が利用可能なストレージの総量は約150GB(157970247680Byte)のみです。
同梱したAMIのサイズは含まれていませんでした。
今回は確認できませんが「ローカルコンピューティングとストレージのみ」ジョブの場合はここが8TBになるのだと予想されます。

EC2インスタンスを試してみる

作成したEC2インスタンスへはSSHでアクセスします。
基本的には前節で作成したキーペアを使った鍵認証をすればOKです。

あとは通常のEC2と同じ様に扱えます。

ちなみにeth034.223.14.128/25なネットワークにある形になっていました。
これがSnowcone内部ネットワーク[1] でVNIへNATしている様です。

1. インスタンスメタデータへのアクセス

EC2からインスタンスメタデータへのアクセスも可能でした。
ざっくり以下の様な結果でした。

# インスタンスメタデータ(v1) が利用可能
$ curl http://169.254.169.254/latest/meta-data/
ami-id
hostname
instance-id
instance-type
local-hostname
local-ipv4
mac
network/
reservation-id
security-groups
public-ipv4

# インスタンス情報は特筆する点なし
$ curl http://169.254.169.254/latest/meta-data/ami-id
s.ami-0e96d810764e93bd4
$ curl http://169.254.169.254/latest/meta-data/instance-id
s.i-811bef5f04eb1a609
$ curl http://169.254.169.254/latest/meta-data/instance-type
snc1.micro

# Private IPが 34.223.14.128/25 で Public IPがVNIのIPに見える形となる
$ curl http://169.254.169.254/latest/meta-data/local-ipv4
34.223.14.193
$ curl http://169.254.169.254/latest/meta-data/public-ipv4
192.168.9.156

# セキュリティグループは default 
$ curl http://169.254.169.254/latest/meta-data/security-groups
default

SnowconeのEC2からはVNIのIPがPublic IPとして見え、現実のGlobal IPとLocal IPが逆転している様になっているのは面白いです。(やっぱりNATしてますね。これは。)

2. EC2からNFSサーバーへのアクセス

EC2からNFSサーバーへのアクセスも可能です。
特別な内部ルートなどは無い様で普通にVNI経由でアクセスします。

# ネットワーク経由でNFSサーバーにアクセス可能
sudo mkdir /mnt/nfs
sudo mount -t nfs 192.168.9.155:buckets/shibata-snowcone-test-2021 /mnt/nfs

マウントした結果はこんな感じ。

# NFSサーバーへばっちりアクセス可能
$ ls -al /mnt/nfs/
total 12492
drwxrwxrwx 1 root       root             68 Dec 25 00:50 .
drwxr-xr-x 3 root       root             17 Dec 25 04:54 ..
-rwxr-xr-x 1 4294967294 4294967294 12788163 Dec 25 00:46 100000-files.zip
drwxr-xr-x 1 4294967294 4294967294      386 Dec 25 01:01 bigfiles
drwxr-xr-x 1 4294967294 4294967294  3400000 Dec 24 21:56 smallfiles

3. 同梱したAMIについて

今回は標準で提供されるAmazon Linux 2イメージの他に

  • 自分で用意したカスタムAmazon Linux 2 AMI
  • CentOS 7 AMI
  • Ubuntu 16.04 AMI

を用意しました。
それぞれを試した結果を以下に記載します。

3-1. カスタムAmazon Linux 2 AMI

原因は調査中ですがこのAMIだとEC2は起動したものの一切接続できない+Pingも通らない状態になりました。
標準で提供されるAMIと区別するためにEBSをgp3にしてたのでですが、おそらくこれが悪かったんだと思います。
(他のAMIは全部gp2で作っており問題なく利用できたため)

3-2. CentOS 7 AMI

特に問題なく利用できました。

3-3. Ubuntu 16.04 AMI

Snowconeで用意したキーペアが使えずAMI作成時のキーペアでログインし利用することができました。
詳しく調べていませんがおそらくcloud-initのどこかでエラーになってるんだと予想しています。

Snowconeデバイスのリソース制限

Snowconeデバイスではコンピューティングに利用可能なリソース上限が決められており、上限を超える様にEC2インスタンスを作成した場合はエラーとなります。

インスタンスの起動に失敗しました: Snowball has insufficient capacity to launch the instance in this request.

リソース上限についてはAWS OpsHubから確認できないものの、Snowball Edge Client(snowballEdgeコマンド)から確認することができます。

# PowerShell 7.2.1環境で実施 (他シェルではjqなどで頑張ってください)
C:\> snowballEdge describe-device --profile my-first-snowcone | ConvertFrom-Json | Select-Object -ExpandProperty DeviceCapacities

Name      : HDD Storage
Unit      : Byte
Total     : 157980389376
Used      : 10737418240
Available : 147242971136

Name      : SSD Storage
Unit      : Byte
Total     : 0
Used      : 0
Available : 0

Name      : vCPU
Unit      : Number
Total     : 3
Used      : 2
Available : 1

Name      : Memory
Unit      : Byte
Total     : 5368709120
Used      : 2147483648
Available : 3221225472

Name      : GPU
Unit      : Number
Total     : 0
Used      : 0
Available : 0

コマンドの結果について細かい解説はしませんが、vCPUの上限が3、メモリの上限が5GBとなっておりSnowconeのデバイス仕様(2vCPU、4GBメモリ)に対しPreload NFS Client(1vCPU、1GBメモリ)の分が上乗せされている[2]のが面白いですね。

これにより

  • Preload NFS Client + EC2インスタンス(snc1.small) x 2
  • Preload NFS Client + Preload DataSync Client

の組み合わせも可能であると見て取れます。
なお、リソースはEC2の状態(起動・停止)によらずEC2を作成した時点で消費されます。

Snowconeのネットワーク構成

最後にSnowconeのネットワーク構成について軽く解説します。

Snowconeのネットワーク構成はLAN1、LAN2の物理NICに加え、各物理NICと紐づく形となる仮想NIC(VNI)を各サービスで利用する形となります。
まあ、これはENIの様なものだと思っていただくのが手っ取り早いでしょう。

VNIだけでなく物理NICと直接マッピングするダイレクトNIC(DNI)も定義可能です。
DNIではMACアドレスのカスタマイズやVLANタグがサポートされているそうです。
こちらはAWS OpsHubからは作成できずCLIを使う必要があります。

それぞれの詳細は以下のドキュメントをご覧ください。

加えて先述の通りSnowcone内部には34.223.14.128/25なネットワークが存在しており、内部ネットワークにあるEC2は相互に通信可能です。

補足1 : NFSサーバーの内部IPアドレス

NFSサーバーもVNIを使っている以上おそらく内部ネットワークに実体となるインスタンスがあるものと予想されます。
ただNFSサーバーの内部IPを知る方法が一切無いため、結局はVNI経由でアクセスするしかありませんでした。

補足2 : DNIの作成例

細かい解説まではしませんがDNIを作成する例を以下に記載します。

まずはCLIでDNIを作成します。
以下の例ではLAN2(RJ45_2 : s.ni-88cabc27426d3c6e7)とEC2インスタンス(s.i-811bef5f04eb1a609)をマッピングしています。

# PowerShell 7.2.1環境でSnowball Edge Clientを使用

# 物理NICのIDを取得 (この例ではLAN2を使う)
C:\> snowballEdge describe-device --profile my-first-snowcone | ConvertFrom-Json | Select-Object -ExpandProperty PhysicalNetworkInterfaces

PhysicalNetworkInterfaceId : s.ni-842025a469b4329e5
PhysicalConnectorType      : RJ45
IpAddressAssignment        : STATIC
IpAddress                  : 192.168.9.150
Netmask                    : 255.255.255.0
DefaultGateway             : 192.168.9.1
MacAddress                 : 8c:0f:6f:xx:xx:xx

PhysicalNetworkInterfaceId : s.ni-88cabc27426d3c6e7
PhysicalConnectorType      : RJ45_2
IpAddressAssignment        : STATIC
IpAddress                  : 192.168.9.160
Netmask                    : 255.255.255.0
DefaultGateway             : 192.168.9.1
MacAddress                 : 8c:0f:6f:xx:xx:xx

# DNIを作成 (最低限の設定のみ)
C:\> snowballEdge create-direct-network-interface --profile my-first-snowcone `
     --instance-id 's.i-811bef5f04eb1a609' `
     --physical-network-interface-id 's.ni-88cabc27426d3c6e7'
{
  "DirectNetworkInterface" : {
    "DirectNetworkInterfaceArn" : "arn:aws:snowball-device:::interface/s.ni-85371eea7a3dd2a51",
    "PhysicalNetworkInterfaceId" : "s.ni-88cabc27426d3c6e7",
    "InstanceId" : "s.i-811bef5f04eb1a609",
    "Driver" : "ixgbevf",
    "MacAddress" : "1a:74:cc:18:d4:b6"
  }
}

# DNIの確認は snowballEdge describe-direct-network-interfaces コマンドを使う
C:\> snowballEdge describe-direct-network-interfaces --profile my-first-snowcone
{
  "DirectNetworkInterfaces" : [ {
    "DirectNetworkInterfaceArn" : "arn:aws:snowball-device:::interface/s.ni-85371eea7a3dd2a51",
    "PhysicalNetworkInterfaceId" : "s.ni-88cabc27426d3c6e7",
    "InstanceId" : "s.i-811bef5f04eb1a609",
    "Driver" : "ixgbevf",
    "MacAddress" : "1a:74:cc:18:d4:b6"
  } ]
}

この時点で当該インスタンスには新しいNIC(通常であればeth1)が生える形となります。

NICが生えたもののまだ未設定の状態ですのでドキュメントあるサンプルをベースにNICの設定をしてやります。

# ドキュメントのサンプルを一部変更しAmazon Linux 2インスタンスで実施
#  * https://docs.aws.amazon.com/snowball/latest/snowcone-guide/snowcone-network-config-ec2.html

# DNIのMACアドレスを設定
DNI_MAC=1a:74:cc:18:d4:b6
# DNIのNIC名を設定。通常は eth1 。
DNI=eth1

# EC2のVNI (通常eth0) の情報を取得し、内部ネットワークの通信はeth0経由になる様にルーティングテーブルを更新 
PRIVATE_IP=$(curl -s http:/169.254.169.254/latest/meta-data/local-ipv4)
PRIVATE_GATEWAY=$(ip route show to match 0/0 dev eth0 | awk '{print $3}')
ROUTE_TABLE=10001
echo from $PRIVATE_IP table $ROUTE_TABLE | sudo tee -a /etc/sysconfig/network-scripts/rule-eth0
echo default via $PRIVATE_GATEWAY dev eth0 table $ROUTE_TABLE | sudo tee -a /etc/sysconfig/network-scripts/route-eth0

# DNI (eth1) の設定ファイルを追加 : この例では DHCP だが環境にあわせてよしなに変更可能
cat << EOF | sudo tee -a /etc/sysconfig/network-scripts/ifcfg-$DNI
DEVICE="$DNI"
NAME="$DNI"
HWADDR="$DNI_MAC"
ONBOOT=yes
NOZEROCONF=yes
BOOTPROTO=dhcp
TYPE=Ethernet
EOF

## 必要があればデバイス名を変更する、とのことだったが今回は実施せず。 : 変更する必要がなかったため
# Rename DNI device if needed.
# CURRENT_DEVICE_NAME=$(LANG=C ip -o link | awk -F ': ' -vIGNORECASE=1 '!/link\/ieee802\.11/ && /'"$DNI_MAC"'/ { print $2 }')
# ip link set $CURRENT_DEVICE_NAME name $DNI

# Networkサービスの再起動
sudo systemctl restart network

結果LAN2を使用するeth1192.168.9.159 (DHCP)が割り当たり利用可能になります。
ちなみにeth0はLAN1を使うVNIであり物理NICをまたぐ形になっているのですが、この様な構成も可能です。

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:ce:2e:d4 brd ff:ff:ff:ff:ff:ff
    inet 34.223.14.193/25 brd 34.223.14.255 scope global dynamic eth0
       valid_lft 3581sec preferred_lft 3581sec
    inet6 fe80::5054:ff:fece:2ed4/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 1a:74:cc:18:d4:b6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.9.159/24 brd 192.168.9.255 scope global dynamic eth1
       valid_lft 259184sec preferred_lft 259184sec
    inet6 fe80::1874:ccff:fe18:d4b6/64 scope link
       valid_lft forever preferred_lft forever

最後にDNIを削除する場合はsnowballEdge delete-direct-network-interfaceコマンドを使います。
(当然ですが事前にEC2側の設定を元に戻してください)

# DNIを削除
C:\> snowballEdge delete-direct-network-interface --profile my-first-snowcone --direct-network-interface-arn "arn:aws:snowball-device:::interface/s.ni-85371eea7a3dd2a51"
The direct network interface has been deleted from your Snowball Edge. You can determine the direct network interfaces available on your Snowball Edge using the describe-direct-network-interfaces command.

終わりに

今回はここまでです。
つぎはPreload DataSync Agentを試す予定です。

脚注
  1. このアドレス帯は 34.208.0.0/12 でEC2用に予約されており、顧客のプライベートネットワークで使われるアドレスが不明な以上AWSが保有するグローバルIPアドレス帯をSnowcon内部で使わざるを得なかったんだと思います ↩︎

  2. おそらくSnowconeには公表されているデバイス仕様を超える真の物理スペックが存在するのでしょう...きっと。 ↩︎

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.