AWSにStorageGatewayというサービスがあります。
このStorageGatewayは、オンプレミスのデータをS3へ直接保存するための接続サービスですが、EC2の世界でも
利用することができます。
今回は、StorageGatewayでS3の領域をVPC内のEC2にマウントしてみたいと思います。
○ゲートウェイの作成
StorageGatewayの画面の左ペインの「Deploy a new Gateway on Amazon EC2」というリンクをクリックします。
そうすると、アクティベーションダイアログが起ち上がるので、赤枠の「Launch Gateway AMI」のリンクを
クリックします。
StorageGateway用のAMIの説明画面が開くので、「Continue」ボタンをクリックします。
AMIの選択画面になり、「1-Click Launch」と「Launch with EC2 Console」のタブがあるので選択し、
TokyoリージョンのAMIをクリックします。
料金表を見るとGatewayインスタンスはxlargeから使用可能のようです。
そうすると確認画面が表示されるので、「Continue」をクリックします。
先ほど「Launch with EC2 Console」を選んだので、EC2のダイアログが起ち上がります。
一番グレードの低いxlargeを選択し、今回はVPCのprivateサブネットを選択します。
あとは、通常通りに進んでいきます。
ここではプライベートIPを10.0.1.5に割り当てます。
そのまま次へ進むと、EBSボリュームの設定画面が表示されます。
StorageGatewayではストレージボリューム以外にもキャッシュやバッファ用のボリュームが必要です。
ここで追加することも可能ですが、今回はこのまま進み、後から追加することにします。
セキュリティグループのところでは、後でiscsiを使用するため、このインスタンスをマウントするEC2から
iscsiインターフェスでマウントするためデフォルトポート3260をセキュリティグループに含めます。
また、設定作業用のSSHポートも開けておきます。
・22 10.0.0.0/16
・3260 10.0.0.0/16
後はそのまま進み、インスタンスが起ち上がったらEIPを付与します。
VPCの場合でもアクティベーションに使用するので、一時的にEIPを付与しておきます。
ここで、先ほどのStrageGatewayの画面に戻り、IPアドレス欄にEIPを入力して、「Proceed to Activation」を
クリックします。
そうすると、StrageGatewayのコンソールにゲートウェイのVMの設定が表示されます。
タイムゾーンを選択し、Gatewayの名前を入力して「Activate My Storage Gateway」をクリックします。
そうすると、以下のような画面になり、ゲートウェイが表示されます。
次に、キャッシュとバッファ用のEBSを作成し、ゲートウェイインスタンスにアタッチします。
（インスタンス作成の時に同時に行なっても構いません）
StorageGatewayの画面に戻り、「Create Volume」をクリックするとダイアログが現れるので、
キャッシュボリュームとアップロードバッファのデバイスをそれぞれ選択します。
今回はキャッシュボリュームに20GB、バッファボリュームに10GBのボリュームを割り当てます。
「Next」をクリックすると、このキャッシュとバッファのボリュームのそれぞれ使用容量のアラームの設定画面が
表示されるので、適宜設定していきます。
今回はデフォルトのままメールアドレスを入力し次へ進みます。
そうすると、ゲートウェイ用ボリュームの設定になります。
ここでは実際に使用するファイルストレージとしての容量とiSCSIのターゲットのエンドポイントを決めるIDを
入力します。
今回容量は1TB、iSCSIターゲットのIDをmemorycraft-sgwとして最後に「Create Volume」ボタンを
クリックします。
そうするとゲートウェイボリューム作成完了と表示されます。
ここまでできたらゲートウェイ自体は完了です。
○ゲートウェイボリュームをEC2（CentOS）にマウント
次に、作成したゲートウェイボリュームをEC2上のCentOSインスタンスにマウントします。
このボリュームをマウントするためのインスタンスを新たに立ち上げます。
ここから先は、このインスタンスにSSH接続しての設定になります。
StorageGatewayはiSCSIインターフェースなので、このインスタンスをiSCSIイニシエータにするための設定を
行います。
まずiSCSIイニシエータツールをインストールして、設定ファイルをStorageGateway用に変更し、起動します。
AWSの資料では、設定は例としてカスタマイズした方が良いそうで、それにならって変更します。
実際には用途に応じて適切な値を設定することをお勧めします。
# yum install -y iscsi-initiator-utils
# vim /etc/iscsi/iscsid.conf
~
node.session.timeo.replacement_timeout = 600
node.conn[0].timeo.noop_out_interval = 60
node.conn[0].timeo.noop_out_timeout = 600
~
# /etc/init.d/iscsi start
iscsiadmコマンドでネットワーク内のiscsiターゲットを探してみます。
ゲートウェイインスタンスはVPC内で10.0.1.5を設定したため、10.0.1.5を探します。
# iscsiadm --mode discovery --type sendtargets --portal 10.0.1.5:3260
iscsid を起動中: [ OK ]
10.0.1.5:3260,1 iqn.1997-05.com.amazon:memorycraft-sgw
StorageGatewayで作成したボリュームが見つかりましたので、これに接続します。
# iscsiadm --mode node --targetname iqn.1997-05.com.amazon:memorycraft-sgw --portal 10.0.1.5:3260,1 --login
Logging in to [iface: default, target: iqn.1997-05.com.amazon:memorycraft-sgw, portal: 10.0.1.5,3260] (multiple)
Login to [iface: default, target: iqn.1997-05.com.amazon:memorycraft-sgw, portal: 10.0.1.5,3260] successful.
次に、デバイスとしてアタッチされているか確認してみます。
# ls -l /dev/disk/by-path/
合計 0
lrwxrwxrwx 1 root root 9 2月 23 18:09 2013 ip-10.0.1.5:3260-iscsi-iqn.1997-05.com.amazon:memorycraft-sgw-lun-0 -> ../../sda
lrwxrwxrwx 1 root root 11 2月 23 17:54 2013 xen-vbd-2049 -> ../../xvde1
/dev/sdaにアタッチされているようなので、これをマウントしてみます。
# mkfs.ext4 /dev/sda
ke2fs 1.41.12 (17-May-2010)
/dev/sda is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
67108864 inodes, 268435456 blocks
13421772 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
8192 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 23 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
# mkdir /mnt/sgw
# mount /dev/sda /mnt/sgw
# df -h
Filesystem Size Used Avail Use% マウント位置
/dev/xvde1 6.0G 2.6G 3.1G 47% /
none 3.7G 0 3.7G 0% /dev/shm
/dev/sda 1008G 200M 957G 1% /mnt/sgw
1TBがマウントされたことが確認出来ました。
ここに、以前s3syncの際に利用した大量のファイルを置いてみます。
# cd /mnt/sgw/
# git clone https://github.com/mirrors/perl.git
# git clone https://github.com/apache/cassandra.git
# git clone https://github.com/v8/v8.git
# git clone https://github.com/symfony/symfony.git
# git clone https://github.com/torvalds/linux.git
# tree -L 2 .
.
|-- cassandra
| |-- CHANGES.txt
(略)
| `-- tools
|-- linux
| |-- COPYING
(略)
| `-- virt
|-- perl
| |-- AUTHORS
(略)
| `-- x2p
(略)
| `-- utils
|-- symfony
| |-- CHANGELOG-2.0.md
(略)
| `-- src
`-- v8
|-- AUTHORS
(略)
`-- tools
# du -sh
1.9G .
ファイル配置も問題ないようです。
また、s3cmdやs3fsのようにファイルリストの取得だけで重くなってしまうことはないようですが、
キャッシュボリュームがあるためかも知れません。
ファイル総量がキャッシュを超えた時の挙動などはまたの機会に試してみたいと思います。
また、EBSをPIOPSにしたり、EBSOptimizedインスタンスにした場合など、ボトルネックや、
冗長化など考えると奥が深そうです。
現在のところ、接続先のS3領域はS3コンソールやAPIからは秘匿されているようです。
これらにアクセスできるとまた別の使い方ができるかもしれません。
こちらの記事はなかの人（memorycraft）監修のもと掲載しています。
元記事は、こちら
