タグ別アーカイブ: Storage Gateway

memorycraft: Storage Gatewayってなんじゃ?(EC2のCentOSにS3をマウント)

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 = 600node.conn[0].timeo.noop_out_interval = 60node.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:3260iscsid を起動中:                                           [  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 --loginLogging 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/合計 0lrwxrwxrwx 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 -> ../../sdalrwxrwxrwx 1 root root 11  2月 23 17:54 2013 xen-vbd-2049 -> ../../xvde1

/dev/sdaにアタッチされているようです。
これをマウントしてみます。

# mkfs.ext4 /dev/sdake2fs 1.41.12 (17-May-2010)/dev/sda is entire device, not just one partition!Proceed anyway? (y,n) yFilesystem label=OS type: LinuxBlock size=4096 (log=2)Fragment size=4096 (log=2)Stride=0 blocks, Stripe width=0 blocks67108864 inodes, 268435456 blocks13421772 blocks (5.00%) reserved for the super userFirst data block=0Maximum filesystem blocks=42949672968192 block groups32768 blocks per group, 32768 fragments per group8192 inodes per groupSuperblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848Writing inode tables: done                           Creating journal (32768 blocks): doneWriting superblocks and filesystem accounting information: doneThis filesystem will be automatically checked every 23 mounts or180 days, whichever comes first.  Use tune2fs -c or -i to override.# mkdir /mnt/sgw# mount /dev/sda /mnt/sgw# df -hFilesystem            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 -sh1.9G .

ファイル配置も問題ないようです。

また、s3cmdやs3fsのようにファイルリストの取得だけで重くなってしまうことはないようですが、キャッシュボリュームがあるためかも知れません。ファイル総量がキャッシュを超えた時の挙動などはまたの機会に試してみたいと思います。
また、EBSをPIOPSにしたり、EBSOptimizedインスタンスにした場合など、ボトルネックや、冗長化などなど考えると奥が深そうです。
現在のところでは、接続先のS3領域はS3コンソールやAPIからは秘匿されているようです。これらにアクセスできるとまた別の使い方ができるかもしれません。

以上です。

広告