今回は、StorageGatewayでS3の領域をVPC内のEC2にマウントしてみたいと思います。
ゲートウェイの作成
StorageGatewayの画面の左ペインに「Deploy a new Gateway on Amazon EC2」というリンクをクリックします。
するとダイアログが立ち上がり、アクティベーションダイアログが起ち上がります。
赤枠の「Launch Gateway AMI」のリンクをクリックします。
StorageGateway用のAMIの説明画面が開きます。
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を入力します。
ここでは、容量は１TB、iSCSIターゲットのIDをmemorycraft-sgwとして最後に「Create Volume」ボタンをクリックします。
するとゲートウェイボリューム作成完了と表示されます。
ここまで出来たらゲートウェイ自体は完了です。
ゲートウェイボリュームをEC2（CentOS）にマウント
次に、作成したゲートウェイボリュームをEC2上のCentOSインスタンスにマウントします。
このボリュームをマウントするためのインスタンスを新たに立ち上げます。
ここから先は、このインスタンスにSSH接続しての設定になります。
StorageGatewayはiSCSIインターフェースなので、このインスタンスをiSCSIイニシエータにするための設定を行います。
まずiSCSIイニシエータツールをインストールして、設定ファイルをStorageGateway用に変更し、起動します。
AWSの資料では、設定は例としてカスタマイズしたほうがよいそうで、それにならって変更します。
実際には用途に応じて適切な値を設定することをお勧めします。
iscsiadmコマンドでネットワーク内のiscsiターゲットを探してみます。
ゲートウェイインスタンスはVPC内で10.0.1.5を設定したため、10.0.1.5を探します。
StorageGatewayで作成したボリュームが見つかりました。
これに接続します。
次に、デバイスとしてアタッチされているか見てみます。
/dev/sdaにアタッチされているようです。
これをマウントしてみます。
おー、ちゃんと1TBがマウントされたようです。
ここに、以前s3syncのときにつかった大量のファイルを置いてみます。
ファイル配置も問題ないようです。
現在のところでは、接続先のS3領域はS3コンソールやAPIからは秘匿されているようです。これらにアクセスできるとまた別の使い方ができるかもしれません。
以上です。
このボリュームをマウントするためのインスタンスを新たに立ち上げます。
ここから先は、このインスタンスに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インスタンスにした場合など、ボトルネックや、冗長化などなど考えると奥が深そうです。
また、EBSをPIOPSにしたり、EBSOptimizedインスタンスにした場合など、ボトルネックや、冗長化などなど考えると奥が深そうです。
現在のところでは、接続先のS3領域はS3コンソールやAPIからは秘匿されているようです。これらにアクセスできるとまた別の使い方ができるかもしれません。
以上です。
