AWS Snowball Edgeが我が家にやってきた。

概要

AWS Snowball Edgeを注文して自家用で使うべく注文した話です。
到着後に技術的に使用する話は別記事になっています

やっと来たSnowball

従来のAWS Snowballは専用のツールでデータを格納してS3とデータを出し入れするだけのストレージでした。
そこにAWS Snowball Edgeが登場。名前は似ているがこれは別物らしい。

NFS対応アップデート登場

AWS Snowball Edge登場当初は、ただのS3互換ローカルストレージでした。
2017年6月のアップデートでNFSサーバとして接続できるFile Interface機能が登場。
NFSサーバとしてローカルストレージにできる!?
申し込もう。

アマゾン時間

2016年内に全リージョンでGAとなるはずだったAWS Snowballなのに来る気配が無い。
2017年春、クローズドで一部パートナー等に出しているという話を聞くも自家用には借りられない。
2017年9月、やっと来た。
アマゾン時間はJSTと9ヶ月の時差があるようです。

申し込めないよSnowball

早速申し込もうとするもTokyoは日本の都道府県ではないと弾かれ申し込めません。
snow11.jpg

東京独立国構想も悪くないね!?
しかしどの都道府県を選択しても同じで申し込めず、サポートへ問い合わせ。

サポートからの返事は…
snow12.jpg

なんと言語設定をEnglishにして申し込んでくれというものでした。
ぶひー!!
(注:本不具合は2018年1月現在、修正済みです)

外人から連絡が><

申し込みを終えると、何やら外人からサポートケースを開かれ横文字で質問が来ました。
sn1.jpg

け!また横文字かよ。
しかも「質問に返答するまでSnowballを出荷しない」と書かれています。
ヤンキーらしいなぁ。
と思いつつ、後にこれに助けられることとなるのでここはおとなしく。

内容はSnowballはこういう仕様だけど、利用用途と環境に問題無いかという申し込みの確認です。
30TB程のデータがあり、スイッチには10Gbps RJ45とSFPポートがあるよと答えると、出荷の準備に入ると連絡が来ました。

大人気のSnowball Edge

しかし待てど暮らせど届かない。マネコンの状況も変化せず1週間。
サポートケースに更新がありました。
sn2.JPG

Snowball Edgeデバイスが大人気ですぐには出荷できないとのこと。
S3へデータを輸送するだけならこの注文をキャンセルして50TBか80TBのSnowballを注文してくれと書かれています。
それでは意味がないですし、来月のJAWS FESTA向けのネタなので急ぎませんから気長に待つことにします。

それは突然に

大人気で出荷できないよと連絡が来た翌日はJAWS-UG長野をリブートしに出かけていました。
長野の支部長と信州盛りの大量に盛られた蕎麦を食べていると、かーちゃんから怒りの電話が。
 「あんたまたアマゾンに何頼んだの。大きい荷物が届いたけど重くて動かせないよ」
と怒っています。

何か注文した記憶はありません。
ん!?!?
まさかとマネコンを開くと。。。

sn3.jpg
配達済みとか書かれています。
どうやらそのようです。長野遠征中につき2日間おあずけとなりました><

普通の宅配便として届くSnowball

日通警備さんとかが警備しながら持ってくるのかなと思いきや、宅配便の荷物として普通に届きました。
日本では西濃運輸さんが担当されているようです。
sn4.jpg

アクティベーションしないと使えませんし、配送は適当でも問題ないのでしょうね。
メソさんのブログによると欧州では玄関先に放置配達されたようですし対面受取なだけ日本はマシかも?

しかも外箱などは無く、筐体へ配達伝票と納品書がそのまま貼り付けられて届きます。
確かに物理的衝撃に強い構造ですから梱包不要でしょうけど、なんか面白いですね。

Eインクは?

上部にはEインクの表示パネルがあり、配達先等が表示されています。
sn5.jpg

電源が無くても光るんですね。背面のバックライト?はずっと光っていました。
しかし西濃運輸さんが非対応なのか、通常の宅配伝票が筐体側面に貼られています。

開封の儀

SnowBall Edgeには3つの扉があります。

上部を開くと電源ケーブルが収納されているのでこれを取り出します。
sn6.jpg
付属品はこれだけです。
ネットワークケーブルは必要な物を自前で準備しなければなりません。

背面を開くとネットワークポートと電源コネクタがあるので、ネットワークケーブルと先ほど取り出した電源ケーブルを接続します。
sn7.jpg
図解で「電源接続時は蓋を上げた状態で使用し閉じるな」と書かれています。

当然ですよね。
sn8.jpg
開けるとこの状態です。
これを閉じて使用したら発熱ですぐに熱暴走することでしょう。

前面を開くと電源スイッチと操作パネルがあります。
sn9.jpg
電源ボタンを押すと動き出します。

中身はHDDだった

ゴゴゴゴゴゴとHDD駆動音らしき音がします。
どうやらSSD等の半導体記憶媒体ではないようです。
衝撃に耐えるのは停止状態のみで良いわけですから、HDDでも要件を満たせますからね。

返却もふつうの宅配便

使用後に電源を切ると、筐体上面のEインクは返送用の宛名ラベルになります。
sn10.jpg

しかし、これまたEインク非対応であります。米国のみのようですね。
同梱されている西濃運輸さんの印字済み伝票を筐体に貼り付けます。
sn11.jpg

あとは普通の宅配便同様、西濃運輸さんへ集荷を依頼します。
いつもの運ちゃんが集荷に来て回収されます。

返却処理には時間がかかる

AWSのデータセンタは非公開のため、西濃運輸さんの拠点へ届けられます。
その後、AWSへ輸送されますがこの一連の処理が完了するまで1週間かかります。
sn15.jpg
処理が完了すると、マネコンのジョブステータスが完了済みとなり終了します。

料金の計算方法

Snowball Edgeは300ドルの基本料金に10日間の利用期間が含まれています。
届いた当日と、集荷された日は利用日に含まれません。
届いた翌日から集荷される前日までが利用期間となります。
よって、今回のように不在なのに家族が受け取ると残念なことになります。
また、送料別途で往復で120ドルかかりますから最低利用料金420ドルと覚えておきましょう。

まとめ

どんな物流なのか楽しみにしていましたが、普通の宅配便で届くことがわかりました。
一般のご家庭にも安心して注文できますね。一家に一台 AWS Snowball Edge.
利用開始後の技術的な話は別記事になっています

続きを読む

AWS Snowball Edge を自家用で使ってみた話

概要

AWS Snowball Edgeが我が家にやってきた。その顛末記。
s0.jpg

目的

AWS Snowball EdgeはAWSと関係なく単なるローカルストレージとして使えること着目し、
NASのデータ退避場所として使用する。データ退避後にNASエンクロージャに入っている
全HDDを交換し、NASの容量増加することを目的とします。

利用開始まで

  • ネットワークへ接続する
    ネットワーク接続はQSFP(40G), SFP+(25G), RJ45(10G)からの択一です。
    付属品は電源ケーブルしかありません。必要なケーブルは自前で準備が必要です。
    ボンディングなどは出来ず、いずれか1つのインタフェースのみ利用可能です。

  • 電源を入れる
    電源を入れると1Uサーバのような音がします。
    最初は高回転で動き出すのでなかなかの轟音です。数分すると静かになります。
    起動中は前面パネルに図解でSnowball Edgeの使い方が表示されています。
    起動完了まで5~6分かかります。

  • Snowball利用環境の準備
    公式サイトからSnowball toolをダウンロードします。(Linux,Mac用などあり)
    次に、AWSマネジメントコンソールへみんな大好きrootアカウントでログインします。
    Snowballサービスの画面に表示されているアンロックコードをメモします。
    マニフェストファイルをダウンロードしてSnowball toolを実行する端末に保存します。

  • Snowballのアンロック
    準備が出来たら端末でアンロックコマンドを実行します。
    Snowball Edgeはアンロックしないと利用できません。初回のみならず起動時に毎回必要です。
    -m にダウンロードしたマニフェストファイルを、-u にアンロックコードを指定します。

コマンド
snowballEdge unlock -i 10.0.0.1 
  -m ./JID20000000-7777-4444-aaaa-099999999999_manifest.bin 
  -u aaaaa-bbbbb-ccccc-ddddd-eeeee
      The Snowball Edge unlock status is: UnlockSnowballResult(status=UNLOCKING)

アンロックまで1分ほど、File Interface (NFSサーバ)が動き出すまで5分ほどかかります。
状態はSnowball Edge筐体の画面表示、またはコマンド実行で確認できます。

コマンド
snowballEdge status -i 10.0.0.1 
  -m ./JID20000000-7777-4444-aaaa-099999999999_manifest.bin 
  -u aaaaa-bbbbb-ccccc-ddddd-eeeee
      Snowball Unlock Status: SUCCESS
      Total Capacity: 90 TB
      Free Space: 90 TB
      S3 Endpoint: http://10.0.0.1:8080

以上で利用開始の準備完了です。

File Interface (NFSサーバ) の起動

起動しただけではS3としてしか使用できませんNFSサーバは手動で有効にします。
これはSnowball Edge筐体を操作して行います。
タッチパネルになっている画面のFileInterfaceを押します。Status の横にある Enable ボタンを押します。
Allowed clients の横にあるプルダウンメニューを押し、Snowball Edge申込時に入力したS3バケット名が選択肢にあるのでこれを選ぶだけです。

snow1.jpg

File Interface の表示が Running になっていればOKです。
これでNFSサーバとして動作するようになりました。

  • 注意事項

納品書と一緒に注意書きが入っていました。
「FileInterfaceとS3 Interfaceは同時に利用しないこと」
とあった。排他処理とかうまくいかないのでしょうね。まぁNFSでしか使わないので。

NFSマウントする

あっさりとNASでマウントできます。

コマンド
mount -o nolock 10.0.0.1:/nas-migration /mnt
df
Filesystem           1K-blocks      Used Available Use% Mounted on
10.0.0.1:/nas-migration
                     9007199254740992         0 9007199254740992   0% /mnt

実容量90TBのはずなのに、表示は見慣れた8EB(エクサバイト)です。EFSと同じですね。
納品書に同梱されていた注意書きに「空き容量のないSnowballへ書き込まないで下さい」とあります。
たぶんエラー対策がされておらず、おかしなことになるのでしょう。

気になったこと

  • まだ荒削りな実装
    書き込んでも書き込んでもNFSとして容量を取得すると使用済み容量0バイト、空き容量8EBのままです。
    使用済み容量はSnowball Edge本体のパネルに表示されているのを見るしか確認方法がありません。
    わざわざ紙の注意書きがあったのはそういうことか。はまった人が多いのでしょうね。

  • 速度が出ない
    NFSで書き込みをすると300Mbps程度しか出ません。30TBのファイルをコピーするのに14日かかる計算です。
    気が遠くなってきました。

トラブル発生

File Interfaceへしばらく書き込んでいると応答しなくなるトラブル発生。

[84182.336191] nfs: server 10.0.0.1 not responding, timed out
[84182.343201] nfs: server 10.0.0.1 not responding, timed out
[84182.349348] nfs: server 10.0.0.1 not responding, timed out

もうこのメッセージは見たくなかった。。。NFSの辛み再び。

NFSで書き込むと、File Interfaceが接続を受け、Snowball Edgeへ非同期で書き込みます。
このタスクが何時間待てど終了しない。このためシャットダウンもできない。

snow2.jpg

File InterfaceをDisableしようとしても書き込みが完了しないのでずっとこの状態です。

電源ボタンを押すとシャットダウン処理が行われます。
しかし、再び電源を投入するとこの状態から復活してもちろん利用不可能状態なのでした。

そしてサポートへ

日本のサポートは有償でないと答えられないという。使えないAWSJに見切りをつけ米国AWSへ。
カスタマーセントリックがきちんとしている米国は親身に対処してくれました。
30/30/30リブートなど様々な方法を教えられ試せど問題は解決せず。

不具合により動作しなかったため返送することなりました。
利用料金は後日$420のクレジットが付与される形で返還されました。

File Interfaceの不具合だった

返却まで数日あったので、不具合の原因究明に向け調査を続けました。

S3 Interfaceは問題ない

Snowball EdgeにはS3のローカルエンドポイントとして接続できる機能もあります。
これで読み書きを行うと問題なく行えます。
やはり原因はFile Interface機能のようです。

マルチバイト文字非対応のFile Interface

その後、ANK文字のみのファイルを書き込む限りはNFSでも問題無いことが確認できた。
日本語ファイル名など、マルチバイト文字を含むファイル名を使用するとFile Intefaceが暴走し使えなくなるという不具合なのだった。

サポートへフィードバック

snow3.jpg

ベーシックサポート(無償)でもちゃんとフィードバックされます。
これが当然ですよね。

利用料金

AWS Snowball Edgeは最初の10日間は300ドルです。これを超えると1日あたり30ドルかかります。
これはウェブサイトにも明記されていますが、送料は明記されておらず返却時に請求されます。
snow4.jpg

東京都内へ発送してもらいましたが、往復送料として120ドル請求されました。
つまり最低利用料金は420ドルということになります。送料が全国一律かは不明です。

結論

上記不具合により目的は達成されませんでした。
用途の都合上、ファイル名を変更することは出来ませんから仕方有りません。
AWS Snowballチームへ不具合をフィードバックしたし改善される日を待つことにします。

日本法人(AWSJ)の問題

使い方などを質問するのに有償サポートが必要なのであれば仕方ないでしょう。しかしです、
買った製品が正しく動作しないことについて連絡しても門前払いするAWSJの対応は問題です。
カスタマーセントリック思考が欠如し迷走するAWSJ。悔い改めよ。

続きを読む

データ管理を軸にしたネットアップの事業戦略とは – 米幹部が解説

また現在、米国で開催(11月27日~12月1日)されているAWS re:Inventでは、NFS Hybrid Service for Amazon Web ServicesとVMware Cloud on AWSに対応することを … ライ氏は「われわれは、AWSとAzure、Google Platform、IBM Cloud、Alibaba Cloudの5つのハイパースケーラーのクラウドベンダーと提携しており、 … 続きを読む

AWS CloudWatch で、Amazon Linux のパフォーマンスとログの監視をしてみる

0.はじめに

Amazon Linuxを利用していますが、
パフォーマンス監視は Zabbix を使って、
ログ監視は特に何も、
という感じでした。

CloudWatch のメトリクスの保存期間も長くなったみたいですし、
運用の手間やリスク、コスト削減も考慮して、
パフォーマンス監視を CloudWatch、
ログ監視を CloudWatch Logs、
にしようかと思います。

1.IAM Role へのポリシーのアタッチ

  1. 以下の IAM ポリシーを作成します。

    • ポリシー名 : GSCloudWatchWriteOnlyAccess ※ 任意
    • 説明 : ※ 任意
    • ポリシードキュメント :
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "Stmt1459146265000",
                "Effect": "Allow",
                "Action": [
                    "cloudwatch:PutMetricData"
                ],
                "Resource": [
                    "*"
                ]
            },
            {
                "Sid": "Stmt1459146665000",
                "Effect": "Allow",
                "Action": [
                    "logs:CreateLogGroup",
                    "logs:CreateLogStream",
                    "logs:PutLogEvents"
                ],
                "Resource": [
                    "arn:aws:logs:*:*:*"
                ]
            }
        ]
    }
    

  2. 作成したポリシーを EC2 インスタンスに割り当てられている IAM Role に付与します。

1.CloudWatch へのメトリクスデータの送信

  1. 色々調べたところ、collectd と その CloudWatch 用プラグインを利用するのが一般的みたいなので、今回はその手順で進めていきます。

  2. collectd をインストールします。

    $ sudo yum -y install collectd
    

  3. collectd の CloudWatch 用プラグインをインストールします。

    $ git clone https://github.com/awslabs/collectd-cloudwatch.git
    $ cd collectd-cloudwatch/src
    $ sudo ./setup.py
    
    Installing dependencies ... OK
    Installing python dependencies ... OK
    Downloading plugin ... OK
    Extracting plugin ... OK
    Moving to collectd plugins directory ... OK
    Copying CloudWatch plugin include file ... OK
    
    Choose AWS region for published metrics:
      1. Automatic [ap-northeast-1]
      2. Custom
    Enter choice [1]: 
    
    Choose hostname for published metrics:
      1. EC2 instance id [i-00484bb5ac67e244d]
      2. Custom
    Enter choice [1]: 
    
    Choose authentication method:
      1. IAM Role [testuekamawindowsserver]
      2. IAM User
    Enter choice [1]: 
    
    Enter proxy server name:
      1. None
      2. Custom
    Enter choice [1]: 
    
    Enter proxy server port:
      1. None
      2. Custom
    Enter choice [1]: 
    
    Include the Auto-Scaling Group name as a metric dimension:
      1. No
      2. Yes
    Enter choice [1]: 
    
    Include the FixedDimension as a metric dimension:
      1. No
      2. Yes
    Enter choice [1]: 
    
    Enable high resolution:
      1. Yes
      2. No
    Enter choice [2]: 
    
    Enter flush internal:
      1. Default 60s
      2. Custom
    Enter choice [1]: 
    
    Choose how to install CloudWatch plugin in collectd:
      1. Do not modify existing collectd configuration
      2. Add plugin to the existing configuration
      3. Use CloudWatch recommended configuration (4 metrics)
    Enter choice [3]: 
    Plugin configuration written successfully.
    Creating backup of the original configuration ... OK
    Replacing collectd configuration ... OK
    Replacing whitelist configuration ... OK
    Stopping collectd process ... NOT OK
    Starting collectd process ... NOT OK
    Installation cancelled due to an error.
    Executed command: '/usr/sbin/collectd'.
    Error output: 'Error: Reading the config file failed!
    Read the syslog for details.'.
    

  4. collectd の起動に失敗しています。collectd の python 用ライブラリが足りないみたいなので、インストールします。

    $ sudo yum -y install collectd-python
    

  5. collectd を起動します。

    $ sudo service collectd start
    

  6. collectd の自動起動の設定をします。

    $ sudo chkconfig collectd on
    $ sudo chkconfig --list | grep collectd
    
    collectd           0:off    1:off    2:on    3:on    4:on    5:on    6:off
    

  7. /etc/collectd.conf の設定を変更します。

    $ sudo cp -frp /etc/collectd.conf /etc/collectd.conf.ORG
    $ sudo vi /etc/collectd.conf
    
    • cpu :

      • LoadPlugin cpu をコメント解除し、以下の設定を行う。
      <Plugin cpu>
              ReportByCpu false
              ReportByState true
              ValuesPercentage true
      </Plugin>
      
    • df :

      • LoadPlugin df をコメント解除し、以下の設定を行う。
      <Plugin df>
      #       Device "/dev/hda1" 
      #       Device "192.168.0.2:/mnt/nfs" 
      #       MountPoint "/home" 
      #       FSType "ext3" 
      #       IgnoreSelected false
              ReportByDevice false
              ReportInodes false
              ValuesAbsolute true
              ValuesPercentage true
      </Plugin>
      
    • load :

      • LoadPlugin load をコメント解除し、以下の設定を行う。
      <Plugin load>
              ReportRelative true
      </Plugin>
      
    • memory :

      • LoadPlugin memory をコメント解除し、以下の設定を行う。
      <Plugin memory>
              ValuesAbsolute true
              ValuesPercentage true
      </Plugin>
      
    • swap :

      • LoadPlugin swap をコメント解除し、以下の設定を行う。
      <Plugin swap>
              ReportByDevice false
              ReportBytes false
              ValuesAbsolute false
              ValuesPercentage true
      </Plugin>
      

  8. /opt/collectd-plugins/cloudwatch/config/whitelist.conf の設定を変更します。以下のメトリクスの中で不要なものがあれば、適当に削除して下さい。

    $ cd /opt/collectd-plugins/cloudwatch/config/
    $ sudo cp -frp whitelist.conf whitelist.conf.ORG
    $ sudo vi whitelist.conf
    
    cpu-.*
    df-root-df_complex-free
    df-root-df_complex-reserved
    df-root-df_complex-used
    df-root-percent_bytes-free
    df-root-percent_bytes-reserved
    df-root-percent_bytes-used
    load--load-relative
    memory--percent-free
    memory--percent-used
    memory--memory-free
    memory--memory-used
    swap--percent-cached
    swap--percent-free
    swap--percent-used
    

  9. collectd を再起動します。

    $ sudo service collectd restart
    

  10. CloudWatch のマネジメントコンソールの左側ペインから、「メトリクス」を選択します。カスタム名前空間の「collectd」→「Host, PluginInstance」→ EC2 インスタンスの ID でフィルタをかけて、設定したメトリクスのデータがあるか確認します。

    • FireShot Capture 165 - CloudWatch Management Console_ - https___ap-northeast-1.console.aws.png

    • FireShot Capture 166 - CloudWatch Management Console_ - https___ap-northeast-1.console.aws.png

    • FireShot Capture 171 - CloudWatch Management Console_ - https___ap-northeast-1.console.aws.png

2.CloudWatch Logs へのログデータの送信

  1. awslogs をインストールします。

    $ sudo yum -y install awslogs
    

  2. /etc/awslogs/awscli.conf の設定を変更します。

    $ sudo cp -frp /etc/awslogs/awscli.conf /etc/awslogs/awscli.conf.ORG
    $ sudo vi /etc/awslogs/awscli.conf
    
    [plugins]
    cwlogs = cwlogs
    [default]
    region = ap-northeast-1
    

  3. /etc/awslogs/awslogs.conf の設定を変更します。

    • apache や nginx の設定もしています。不要であれば、削除して下さい。
    $ sudo cp -frp /etc/awslogs/awslogs.conf /etc/awslogs/awslogs.conf.ORG
    $ sudo vi /etc/awslogs/awslogs.conf
    
    [/var/log/messages]
    datetime_format = %b %d %H:%M:%S
    file = /var/log/messages
    buffer_duration = 5000
    log_stream_name = {instance_id}
    initial_position = start_of_file
    log_group_name = AmazonLinux/var/log/messages
    
    [/var/log/cron]
    datetime_format = %b %d %H:%M:%S
    file = /var/log/cron
    buffer_duration = 5000
    log_stream_name = {instance_id}
    initial_position = start_of_file
    log_group_name = AmazonLinux/var/log/cron
    
    [/etc/httpd/logs/access_log]
    datetime_format = [%a %b %d %H:%M:%S %Y]
    file = /etc/httpd/logs/access_log
    buffer_duration = 5000
    log_stream_name = {instance_id}
    initial_position = start_of_file
    log_group_name = AmazonLinux/etc/httpd/logs/access_log
    
    [/etc/httpd/logs/error_log]
    datetime_format = [%a %b %d %H:%M:%S %Y]
    file = /etc/httpd/logs/error_log
    buffer_duration = 5000
    log_stream_name = {instance_id}
    initial_position = start_of_file
    log_group_name = AmazonLinux/etc/httpd/logs/error_log
    
    [/etc/httpd/logs/ssl_access_log]
    datetime_format = [%a %b %d %H:%M:%S %Y]
    file = /etc/httpd/logs/ssl_access_log
    buffer_duration = 5000
    log_stream_name = {instance_id}
    initial_position = start_of_file
    log_group_name = AmazonLinux/etc/httpd/logs/ssl_access_log
    
    [/etc/httpd/logs/ssl_error_log]
    datetime_format = [%a %b %d %H:%M:%S %Y]
    file = /etc/httpd/logs/ssl_error_log
    buffer_duration = 5000
    log_stream_name = {instance_id}
    initial_position = start_of_file
    log_group_name = AmazonLinux/etc/httpd/logs/ssl_error_log
    
    [/etc/httpd/logs/ssl_request_log]
    datetime_format = [%a %b %d %H:%M:%S %Y]
    file = /etc/httpd/logs/ssl_request_log
    buffer_duration = 5000
    log_stream_name = {instance_id}
    initial_position = start_of_file
    log_group_name = AmazonLinux/etc/httpd/logs/ssl_request_log
    
    [/var/log/nginx/access.log]
    datetime_format = %Y/%m/%d %H:%M:%S
    file = /var/log/nginx/access.log
    buffer_duration = 5000
    log_stream_name = {instance_id}
    initial_position = start_of_file
    log_group_name = AmazonLinux/var/log/nginx/access.log
    
    [/var/log/nginx/backend.access.log]
    datetime_format = %Y/%m/%d %H:%M:%S
    file = /var/log/nginx/access.log
    buffer_duration = 5000
    log_stream_name = {instance_id}
    initial_position = start_of_file
    log_group_name = AmazonLinux/var/log/nginx/backend.access.log
    
    [/var/log/nginx/badactor.log]
    datetime_format = %Y/%m/%d %H:%M:%S
    file = /var/log/nginx/badactor.log
    buffer_duration = 5000
    log_stream_name = {instance_id}
    initial_position = start_of_file
    log_group_name = AmazonLinux/var/log/nginx/badactor.log
    
    [/var/log/nginx/error.log]
    datetime_format = %Y/%m/%d %H:%M:%S
    file = /var/log/nginx/error.log
    buffer_duration = 5000
    log_stream_name = {instance_id}
    initial_position = start_of_file
    log_group_name = AmazonLinux/var/log/nginx/error.log
    

  4. awslogs を起動します。

    $ sudo service awslogs start
    

  5. awslogs の自動起動の設定をします。

    $ sudo chkconfig awslogs on
    $ sudo chkconfig --list | grep awslogs
    
    awslogs            0:off    1:off    2:on    3:on    4:on    5:on    6:off
    

99.ハマりポイント

  • 今回は、凡ミスばかりで本当に自分が嫌になりました…。もう、毎回、何やってんだ…。

  • CloudWatch へのメトリクスデータの送信では、 CloudWatch のカスタム名前空間の「collectd」ではなく、AWS の EC2 のフィルタに表示されると勘違いして、全然ログが出てこないと悩んでいました…。もう、本当馬鹿…。
  • 後、/etc/collectd.conf の設定も結構悩みました。
  • CloudWatch Logs へのログデータの送信では、/etc/awslogs/awscli.conf の設定を /etc/awslogs/awslogs.conf にすると勘違いして、本当に無駄な時間を浪費しました…。

XX.まとめ

以下、参考にさせて頂いたサイトです。
ありがとうございました。

続きを読む

AutoScaling環境においてGitを使わないでEC2を冗長化する方法

制約

Git禁止(協力会社がFTPしか使えないため)

結論

  1. Master Serverを建てる
  2. Master Serverのファイルの更新をlsyncdで監視し、常にS3と同期する
  3. 任意のタイミングでSlave Server(ELB配下の全EC2インスタンス)をS3と同期する

イメージ図

だいたいこんな感じ

AutoScaling環境においてGitを使わないでEC2を冗長化する方法

Master Server編

1. S3バケットを作成する

公式サイトに詳しい方法が書いてあります。
S3 バケットを作成する方法 – Amazon Simple Storage Service

2. AWS CLIを設定する

公式サイトに詳しい方法が書いてあります。
AWS CLI の設定 – AWS Command Line Interface

3. lsyncdをインストールする

EPELリポジトリを利用してインストールします。

$ sudo yum install --enablerepo=epel lsyncd

4. lsyncdの設定を変更する

普通の書き方だとファイル名の末尾に/(スラッシュ)が混入してエラーが出たりうまくsyncしてくれなかったので、
下記のような感じでパースしてあげる必要があります。
komeda-shinjiさんの記事がとても参考になりました。ありがとうございます。

$ sudo vim /etc/lsyncd.conf
/etc/lsyncd.conf

source_dir = "/var/www/source"
s3bucket = "files.hoge.com"
prefix = "source"

snscmd = "echo !!! error "

settings {
    logfile    = "/var/log/lsyncd.log",
    statusFile = "/var/log/lsyncd.status",
    nodaemon = false,
    statusInterval = 1,
    delay = 5,
}

cp = function(event)
  local src_path = event.sourcePathname
  local dst_path = event.targetPathname

  if (string.sub(event.source, -1, -1) == "/") then
      src_path = string.sub(event.source, 1, -2) .. event.pathname
  end
  if (string.sub(event.target, -1, -1) == "/") then
      dst_path = string.sub(event.target, 1, -2) .. event.pathname
  end
  local s3cmd = "aws s3 cp '" .. src_path .. "' '" .. dst_path .. "'"
  local msg_body = "command failed: " .. s3cmd
  local msg = " --message '" ..  string.gsub(msg_body, "'", "\"") .. "'"


  local runcmd = "rc=0 && [ -f '" .. src_path .. "' ] && for try in 1 2 3; do " .. s3cmd .. "; rc=$?; [ $rc -eq 0 ] && break; done || " .. snscmd .. msg .. " || :"
  spawnShell(event, runcmd)
end

rm = function(event)
  local src_path = event.sourcePathname
  local dst_path = event.targetPathname

  if (string.sub(event.source, -1, -1) == "/") then
      src_path = string.sub(event.source, 1, -2) .. event.pathname
  end
  if (string.sub(event.target, -1, -1) == "/") then
      dst_path = string.sub(event.target, 1, -2) .. event.pathname
  end

  local s3cmd = "aws s3 rm '" .. dst_path .. "'"
  local msg_body = "command failed: " .. s3cmd
  local msg = " --message '" ..  string.gsub(msg_body, "'", "\"") .. "'"
  local runcmd = "rc=0 && [ ! -f '" .. src_path .. "' ] && for try in 1 2 3; do " .. s3cmd .. "; rc=$?; [ $rc -eq 0 ] && break; done || " .. snscmd .. msg .. " || :"
  spawnShell(event, runcmd)
end

mv = function(event)
  local src_path = event.o.targetPathname
  local dst_path = event.d.targetPathname

  if (string.sub(event.o.target, -1, -1) == "/") then
      src_path = string.sub(event.o.target, 1, -2) .. event.o.pathname
  end
  if (string.sub(event.d.target, -1, -1) == "/") then
      dst_path = string.sub(event.d.target, 1, -2) .. event.d.pathname
  end
  local s3cmd = "aws s3 mv '" .. src_path .. "' '" .. dst_path .. "'"
  local msg_body = "command failed: " .. s3cmd
  local msg = " --message '" ..  string.gsub(msg_body, "'", "\"") .. "'"

  local runcmd = "rc=0 && [ -f '" .. src_path .. "' ] && for try in 1 2 3; do " .. s3cmd .. "; rc=$?; [ $rc -eq 0 ] && break; done || " .. snscmd .. msg .." || :"
  spawnShell(event, runcmd)
end

s3sync = {
    maxProcesses = 1,
    onCreate = cp,
    onModify = cp,
    onDelete = rm,
--  onMove = mv,
}

sync {
    s3sync,
    source = source_dir,
    target = "s3://" .. s3bucket .. "/" .. prefix,
}

5. lsyncdを起動する

$ sudo /etc/rc.d/init.d/lsyncd start
$ sudo chkconfig lsyncd on
$ /etc/rc.d/init.d/lsyncd status
lsyncd (pid  12345) is running...

6. Sourceを変更する

$ vim /var/www/source/hoge.txt
/var/www/source/hoge.txt
hogehoge

7. Sourceの変更がS3に反映しているか確認する

$ tailf /var/log/lsyncd.log

Slave Server編

1. AWS CLIを設定する

公式サイトに詳しい方法が書いてあります。
AWS CLI の設定 – AWS Command Line Interface

2. S3のSourceをローカルに同期するシェルスクリプトを作成する

$ vim /usr/local/bin/s3sync.sh
/usr/local/bin/s3sync.sh
#!/bin/sh
SOURCE_DIR="/var/www"
S3_BUCKET="files.hoge.com"
PREFIX="source"

TARGET_MASTER="s3://${S3_BUCKET}/${PREFIX}/"
TARGET_LOCAL="${SOURCE_DIR}/${PREFIX}/"

aws s3 sync ${TARGET_MASTER} ${TARGET_LOCAL} --delete

3. 同期スクリプトをEC2インスタンス起動時に実行するように設定する

$ vim /etc/rc.local
/etc/rc.local
s3sync.sh
exit 0

※ちなみに、rc.localに書かれたスクリプトはroot権限で実行されます。

4. 任意のタイミングで同期スクリプトを実行する

 cronするなり、execするなり

ボツ案

Master Server+rsyncパターン

s3Syncパターン

s3fsパターン

NFSパターン

AMIを最新にしてから起動するパターン

続きを読む

StorageGatewayを使ってS3をNFSマウント

EC2にS3をマウントしたい

S3をNFSマウントする方法はいくつかあるものの、どれも面倒だし公式じゃないし(?)不安定そう… :pensive:

と思っていたら、StorageGatewayでそのような機能が公式から提供されていました。
設定にあたり、いくつか迷った箇所があったためこちらにまとめます。

そもそもStorageGatewayとは

公式ドキュメントより

AWS Storage Gateway は、オンプレミスのソフトウェアアプライアンスをクラウドベースのストレージと接続し、お客様のオンプレミスの IT 環境とアマゾン ウェブ サービス (AWS) のストレージインフラストラクチャとの間にデータセキュリティ機能を備えたシームレスな統合を実現するサービスです。

* AWS Storage Gateway とは

なるほど…?:thinking:

<オンプレ または EC2> :left_right_arrow: <StorageGateway> :left_right_arrow: <S3>

的な感じでつなげてくれるサービスって感じでしょうか。
この <StorageGateway> の部分をEC2インスタンスで構築できるようです。

ファイルゲートウェイとは

上の <StorageGateway> の部分がファイルゲートウェイです。
StorageGatewayでは、 ファイルゲートウェイ ・ ボリュームゲートウェイ ・ 仮想テープゲートウェイ を作成することができ、ファイルゲートウェイはそのうちの一種類です。

ファイルゲートウェイの機能とは?:worried:
S3はネットワーク越しに存在しているので、そのままだとアップロードもダウンロードも時間がかかってしまいます。
そこで、間にファイルゲートウェイが入って使用したデータのローカルキャッシュを行い低レイテンシな接続を実現しているようです。

ファイルゲートウェイの要件

要件をもとに、ファイルゲートウェイが何をしているのか探っていきましょう。
* AWS Storage Gateway – 要件
ドキュメントを見ると、ファイルゲートウェイとして最低限必要なものは以下でしょうか。

  • m4.xlarge 以上のインスタンスタイプ
  • 追加で 150GB のキャッシュストレージ
  • 以下のポートについて許可
    • インバウンド : 80番ポート
      クライアントがHTTP経由(というかマネジメントコンソール?)でファイルゲートウェイをアクティベートするためのもの
    • インバウンド : 2049番ポート
      S3をマウントしたいEC2インスタンスからのアクセスを受け付けるもの
      (portmapper や mountd が必要な場合は適宜ドキュメントを参考に他のポートも許可してください)
    • アウトバウンド : 443番ポート
      StorageGatewayのエンドポイントと連携を取るもの。これについてはインターネットに出る必要がある。

箇条書きだとよくわからないので、図にしました。
こんな感じでしょうか。

storahe.png

通信経路などについては 公式のBlackBelt資料 などを参考にしました。

ファイルゲートウェイの作成

とりあえず、動くものを作りましょう。

  1. マネジメントコンソールより [Storage Gateway] を選択
  2. [ゲートウェイの作成] → [ファイルゲートウェイ] → [Amazon EC2] → [インスタンスの起動]
  3. インスタンスの作成
    3.1. 最低でも m4.xlarge が要件となっているため今回は m4.xlarge を選択
    3.2. 外部からアクセスするため 自動割り当てパブリックIP を有効化
    3.3. 追加で 150GB のキャッシュストレージが必要なため 150GB の新しいボリュームを追加
    3.4. 要件で説明したセキュリティグループを適切にアタッチ
    3.5. インスタンス立ち上げ
  4. [次へ] を押し [ゲートウェイに接続] の画面へ
    インスタンスが立ち上がるまで少々待ち、 3.2 でアタッチしたパブリックIPを入力
  5. 作成したゲートウェイを選択し、 [ファイル共有の作成] を選択
  6. マウントしたいS3バケット名を入力し、ファイル共有を作成
  7. 作成後、ステータスが 利用可能 となったら、画面に表示されているコマンドよりマウント
    (例)
$ mkdir /home/ec2-user/gateway
$ sudo mount -t nfs -o nolock 10.0.x.x:/<バケット名> /home/ec2-user/gateway

使ってみる

マウント

$ mkdir gateway
$ sudo mount -t nfs -o nolock 10.0.0.98:/<mybucket> /home/ec2-user/gateway

ファイルゲートウェイにファイルを保存

$ touch sg_test
$ cp sg_test ./gateway/
$ ls ./gateway/
sg_test

S3にファイルがあるか確認

$ aws s3 ls s3://<mybucket>
2017-08-16 23:25:45          0 sg_test

問題なくマウントできていますね :thumbsup:
ファイルゲートウェイに保存後、数十秒〜1分ほどでS3に同期されました。

おわり

かなり手軽にS3をNFSマウントすることができました。
検証したら複数クライアントから同時にマウントすることも可能だったのですが、整合性とれなくなっておかしなことになりかねないので非推奨かと思われます :expressionless:

続きを読む

オンプレのESXi6.0でAWS StorageGatewayを作成2 ~ボリュームゲートウェイ:保管型ボリューム編~

オンプレのESXi6.0でAWS StorageGatewayファイルゲートウェイを作成 ~ボリュームゲートウェイ:保管型ボリューム編~
+ 2017.08.4 create

前回の記事 (オンプレのESXi6.0でAWS StorageGatewayファイルゲートウェイを作成)に続いて保管型ボリューム編です。
保管型ボリュームは対象ボリュームごとスナップショットとしてS3へ保存されます。
データの自動バックアップ等に使えそうです。

ゲートウェイの種類
ファイルゲートウェイ
 ファイルゲートウェイをNFSのマウントポイントとしてS3へデータを保存できます。

ボリュームゲートウェイ
 オンプレミスのアプリケーションサーバーから iSCSI デバイスとしてマウントできます。
 「キャッシュ型ボリューム」と「保管型ボリューム」の2パターンあり
  - キャッシュ型ボリューム
   データをS3に保存し、頻繁にアクセスするデータサブセットのコピーをローカルに保持します。
  - 保管型ボリューム
   データをローカルに保存し、そのデータのポイントインタイムスナップショットをS3に非同期バックアップします。今回はこちらを作成します。

 
仮想テープライブラリ
 Amazon S3 にデータをバックアップして、既存のテープベースのプロセスを使用しながら、Amazon Glacier に保存します。


環境

Hypervisor:ESXi6.0 (サポートされているハイパーバイザーとホストの要件 )
クライアント:CentOS Linux release 7.3.1611 (Core)

ゲートウェイの作成

1. awsコンソール からStorageGatewayを作成

  ボリュームウェイ-保管型ボリュームを選択します。
image.png

2. ESXiのOVAイメージダウンロード

  イメージのダウンロードをポチします。
alt

ダウンロードできたら一旦awsコンソールからは離れてESXi側で仮想マシンを作成します。

3. ESXiの仮想マシンへデプロイ

  3.1新規仮想マシン作成
alt
  OVFファイルまたはOVAファイルから仮想マシンをデプロイを選択
alt
  仮想マシン名を入力し、先ほどダウンロードしたOVAファイルを指定
alt
  データストアの選択
alt
  デプロイオプション ディスクのプロビジョニングはシックを選択
alt
  完了ポチして作成
alt

  • ハードディスク2にアップロードバッファ用とアプリケーションデータ用のディスクを追加します。(最低2つ以上のディスクが必要です。)
    ディスク1と同様にシックプロビジョニングで作成します。

image.png

  • 時刻の同期
    仮想マシンオプションの時刻設定

    • ホストとゲスト時間を同期
      にチェックを入れます
      image.png

ゲートウェイを起動します。
固定IP等設定する場合はコンソールメニューから設定します。
初めてローカルコンソールにログインする場合は、sguser というユーザー名と sgpasswordを使用して VM にログインします。
alt

  
ここでawsコンソールに戻ります。

4. ゲートウェイに接続

  作成したゲートウェイのIPを入力します。
  IPはオンプレ環境のローカルIPで大丈夫です。
alt

5. ゲートウェイのアクティブ化

  タイムゾーン、ゲートウェイ名を入力してアクティブ化します。
image.png

6. ボリュームの作成

  アプリケーションがデータを読み書きするストレージボリュームを作成します。
  ・ゲートウェイ名を選択します。
  ・ディスクIDを選択します。
  ・ボリュームの内容は新規なので「新しい空のボリューム」を選択します。
  ・iSCSIターゲット名を入力します。

image.png

7. CHAP認証の設定

  ボリュームのチャレンジハンドシェイク認証プロトコル (CHAP) の設定は今度にしてここではスキップします。

image.png

8. クライアントOS側の設定

  クライアントのCentosでiSCSIイニシエータパッケージをインストールして設定します。

iscsi-initiator-utils
インストール
# yum install iscsi-initiator-utils
サービス起動
# systemctl enable iscsid.service
# systemctl start iscsid
# service iscsid status
ターゲット検出
/sbin/iscsiadm --mode discovery --type sendtargets --portal 192.168.1.1:3260
192.168.1.1:3260,1 iqn.1997-05.com.amazon:vgw-target1
ターゲットに接続
# /sbin/iscsiadm --mode node --targetname iqn.1997-05.com.amazon:vgw-target1 --portal 192.168.1.1:3260,1 --login
Logging in to [iface: default, target: iqn.1997-05.com.amazon:vgw-target1, portal: 192.168.1.1,3260] (multiple)
Login to [iface: default, target: iqn.1997-05.com.amazon:vgw-target1, portal: 192.168.1.1,3260] successful.
ボリュームのアタッチ確認
# ls -l /dev/disk/by-path
合計 0
lrwxrwxrwx. 1 root root  9  8月  4 16:26 ip-192.168.1.1:3260-iscsi-iqn.1997-05.com.amazon:vgw-target1-lun-0 -> ../../sdb
iscsi設定カスタマイズ
設定編集:タイムアウトを長く取ります。
# vi /etc/iscsi/iscsid.conf
98c98
< node.session.timeo.replacement_timeout = 600
---
> node.session.timeo.replacement_timeout = 120
109c109
< node.conn[0].timeo.noop_out_interval = 60
---
> node.conn[0].timeo.noop_out_interval = 5
115c115
< node.conn[0].timeo.noop_out_timeout = 600
---
> node.conn[0].timeo.noop_out_timeout = 5

再接続
# iscsiadm -m discoverydb -t sendtargets -p 192.168.1.1:3260 -o delete
# iscsiadm --mode node --targetname iqn.1997-05.com.amazon:vgw-target1 --portal 192.168.1.1:3260,1 --login

# echo 600 > /sys/block/sdb/device/timeout
システム再起動(いならいかも・・)
# shutdown -r now
ディスクマウント
ファイルシステム作成
# fdisk /dev/sdb
オプション指定は特になくnコマンドデフォルトで作成
デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdb1            2048   104857599    52427776   83  Linux
# mkfs.xfs /dev/sdb1
UUID確認
# blkid
/dev/sdb1: UUID="3679ed59-a4e3-4f4a-9c70-ae231ea2bc28" TYPE="xfs"
fstabに書き込み
# vi /etc/fstab
UUID=3679ed59-a4e3-4f4a-9c70-ae231ea2bc28 /volumegw               xfs     defaults        0 0

ディレクトリ作成
# mkdir /volumegw

マウント
# mount /volumegw

マウント確認
# df -h
ファイルシス        サイズ  使用  残り 使用% マウント位置
/dev/mapper/cl-root    14G  2.4G   12G   18% /
devtmpfs              487M     0  487M    0% /dev
tmpfs                 497M     0  497M    0% /dev/shm
tmpfs                 497M  6.7M  490M    2% /run
tmpfs                 497M     0  497M    0% /sys/fs/cgroup
/dev/sda1            1014M  229M  786M   23% /boot
tmpfs                 100M     0  100M    0% /run/user/0
/dev/sdb1              50G   33M   50G    1% /volumegw

これでボリュームゲートウェイの作成完了。うぇい
後はファイル作ってテストするなりなんなりと

AWSコンソールからボリュームのスナップショットスケジュールを設定しておけば
/volumegwの自動バックアップがとれますねー

続きを読む