Ubuntu14.04でNFSv4を動かしてみる

ゴール nfs-server nfs-client というホスト名の Ubuntu 14.04 のサーバを2台用意し、nfs-server サーバに Network File System バージョン 4(以下 NFSv4) を構築、nfs-client サーバからマウントしてみる。 NFSv4 サーバを構築 まずは nfs-server に NFSv4 サーバを構築します。 必要なパッケージのインストール NFS サーバに必要な nfs-kernel-server パッケージをインストールします。 nfs-kernel-server は NFSv3 にも対応しているようですが、今回は NFSv4 として利用します。 共有ディレクトリを作成 次に共有ディレクトリを作成します。 今回は /tmp/no_root_squash /tmp/root_squash /etc を共有します。 ディレクトリが存在しない /tmp 以下のディレクトリを作成します。 共有ディレクトリを bind mount する NFSv3 では export するディレクトリごとに export していましたが、NFSv4 では擬似的に 1 ディレクトリにまとめ(pseudo

HTTP ベンチマークツール wrk についてメモ

モダンな HTTP ベンチマークツール wkr の簡単な使い方についてメモ。 wrk の特徴は以下。 C で書かれている マルチコア CPU を 活かした高負荷をかけられる スレッドと epoll/kqueue のイベントドリブンを活用して負荷をスケールさせる(NOTICE ファイルを読むと Redis Event Library(ae event loop) を拝借しているようです) Lua スクリプトで HTTP クライアントの処理や実行結果のレポートをカスタマイズできる Installing wrk in CentOS 6 まずはビルドに必要なパッケージをインストールします。 openssl-devel をインストールしていないと、make 時に以下のようなエラーが発生します。 次にソースコードから wrk をビルドします。 Usage 上の例では 12 スレッド(-t12) 同時 400 コネクション(-c400) 負荷は 30 秒かける(-d30s) リクエストヘッダー “User-Agent: MyBrowser” を送信(-H”User-Agent: MyBrowser”) 通信は5秒でタイムアウト(–timeout 5)

Redisのレイテンシを計測

やりたいこと Redis に TCP でコマンドを投げた時 DNS Lookup Initial Connection Request Sent Waiting(TTFB) Content Download というような流れで処理される。 この一連の流れでRedis の内部処理にかかった Waiting(TTFB) を除く通信の時間を計測する方法をメモ。 通信のレイテンシ Redis には疎通確認向けのコマンド PING がある。クライアントがこのコマンドを実行すると、サーバーは PONG を返すだけ。 このコマンドに対してサーバー(Redis)の処理は極めて軽微なため、PING を実行してから PONG がかえってくるまでの時間をレイテンシとみなして計測するのが次のコマンド。 上の例で言えば 103 回 PING を実行し(samples) レイテンシの 最短(min)/最長(max)/平均(avg) がそれぞれ 0ms/2ms/0.18ms となる。 AWS ElastiCache Redisでは AZ をまたぐと同一 AZ での通信に比べてレイテンシが10倍だったりするので、レイテンシを何としても切り詰めたいときは  1コマンド1リクエストとせず Mass Insert を利用してリクエスト回数を減らす マルチ AZ Redis クラスターを諦めて 同一

S3にBasic認証付きリクエストをすると400:Bad Requestになる

nginx で S3 にリバースプロキシしたサイトで、特定の URL 配下にしらーっとBasic認証を追加したら、S3 のリソースの取得が”400 : Bad Request” でことごとく失敗していた。 現象を再現させる まずはこの動きを確認してみる S3を用意 バケットを作成し、オブジェクトを public-read の ACL つきて PUT する。 public read が付いているので、anonymous user も GET できる。 Basic 認証付きでリクエスト 次に Basic 認証付きでリクエストしてみる みごとに 400 Bad Request エラーが発生した。 nginx での解決 nginx の解決策としては S3 にプロキシする際に Authorization ヘッダーを取っ払えばOK nginx_http_proxy_module には proxy_unset_header というディレクティブはなく、proxy_set_header でヘッダーの値をブランクにすると、そのヘッダーフィールドはプロキシされなくなる。

Varnishのレスポンスヘッダーにサーバ情報を含める

Load Balancer – Varnish(複数台) – Origin Server(複数台) というような構成の時に リクエストを処理した Varnish サーバ Varnish にコンテンツを返したオリジンサーバ と言った情報をデバッグ目的で Varnish のレスポンスヘッダーに含める方法をメモ。 ヘッダーに含められる情報 Varnish Server Varnish サーバに関しては、以下の情報が取得可能 server.ip Varnish サーバの IP アドレス server.port/std.port(server.ip) Varnish サーバのポート番号 server.hostname Varnish サーバのホストネーム server.identity プロセス起動時に -i オプションで指定するID。デフォルトはホストネーム 最後の identify は CentOS の場合 /etc/sysconfig/varnish の DAEMON_OPTS を修正すれば良い。 -i varnish-3.0.6 の箇所が追加部分。 Origin Server オリジンサーバに関しては、以下の情報が取得可能 backend.ip オリジンサーバのIPアドレス backend.name オリジンサーバの

[AWS]マルチAZなElastiCache Redisの永続性についてメモ

Redis のデータを永続化させるには RDB : point in time スナップショット AOF : write ahead logging(WAL) の2種類の方法がある。 AWS ElastiCache Redis で Multi-AZ かつ自動フェイルオーバーなレプリケーショングループを組んでいる Redis での動きをメモ。 このようなレプリケーショングループの作り方は次のURLを参照 http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/AutoFailover.html Redis の RDB と AOF について RDB について RDB は point-in-time にダンプしたファイル。 通常の Redis であれば SAVE または BGSAVE(バックグランドで非同期に処理)コマンドで作成するが ElastiCache ではこれらコマンドは無効化されている。 ElastiCache では作成された RDB ファイルはスナップショットとして利用可能。 スナップショットファイルの作成は Replication Group 設定画面のバックアップ系設定で行う。 ElastiCache ではキャシュ処理とスナップショット作成のような管理機能がメモリーを奪い合わないように reserved-memory

Varnish4でエラーページをカスタマイズする

vcl_backend_error と vcl_synth の2種類のエラー Varnish3 でエラーページをカスタマイズにはサブルーチン vcl_error 内でゴニョゴニョやればよかった。 Varnish4 では バックエンドサーバで発生したエラーはサブルーチン vcl_backend_error で処理 VCL 内で synth キーワード(3.* 時代の error)を使って生成された synthetic object はサブルーチン vcl_synth で処理 するように変わった。 例えば、オリジンサーバで 500 番台系のシステムエラーが発生した場合のメッセージは、昔ながらの vcl_synth を修正しても何も変わらず、 vcl_backend_error でカスタマイズしなければいけない。 違いのわかる設定例 この2種類のエラーの違いを実際に確認してみる。 利用する default.vcl は次のもの。 オリジンサーバは localhost:8080 に設定。このサーバは落としておいて、backend fetch が失敗して 500 番台を返すようにしておく。 また、 http://HOST:PORT/404 という URL にアクセスすると、 synth(status_code, reason) で synthetic object を生成して

Varnish3のヘルスチェック結果をCLIから確認

Varnish 3 で複数台のサーバーをロードバランシングしていた時に、各サーバのヘルスチェック結果を確認する方法メモ。 確認には varnishlog と varnishadm を使う。 サーバ構成 server1(localhost:8001), server2(localhost:8002), server3(localhost:8003) という3台のサーバをラウンドロビンでロードバランスする。 Varnish3の設定 probe ディレクティブでヘルスチェック条件を定義 /healthcheck に GET し(url)、直近 5 回のアクセスで(window) 3 回以上 200 OK なら(threshold) healthy とみなすことにする。 server1-3 server1 は常に 200 OK を返すようにする server2 は程よくエラーになってほしいので 1/3 の確率で 200 OK, 404 Not Found, 500 Internal Server Error のいずれかを返すようにする。 server2 の実装例 server3 は常に落としておく。 varnishlog でリアルタイムモニター

Varnishのストレージバックエンドを複数指定する

Varnish の storage backend について キャッシュサーバの Varnish ではキャッシュの保存先として malloc(キャッシュが RAM に収まる限りは高速だが、RAM からあふれるとスワップアウトして非常に遅くなる) file(mmap で仮想メモリを割り当て。HDD のような disk I/O が遅いデバイスでは非常に遅い) persistent (Varnish 4 から非推奨されたので割愛) の3種類から選べる。 チューニングのページには When choosing storage backend, the rule of thumb is to use malloc if your cache will be contained entirely or mostly in memory, while the file storage backend performs far better

Ansibleのコールバックプラグインを使ってみる

Ansible にはコールバックプラグインというのがあり、プレイブックの実行終了や異常終了などの各種イベントをフックして特別な処理を仕掛けることができる。 なかなか便利な機能だと思うけど、ポインター的なドキュメントしか存在せず、自分でコールバックプラグインを作りたければ、既存のプラグインのコード読めみたいな書き方しかされていない。 プレイブックを実行し、hipchat コールバックプラグインでチャットループに実行結果を通知するところまでをメモ。 ping するだけのプレイブックの作成 まずは Ansible プレイブックの作成。 localhost に対して ping を実行するだけのプレイブックを作成する。 hosts ファイル プロビジョン対象。 今回はローカルホストに対して実行する。 ping するだけのプレイブック ping モジュールを呼び出して、ターゲットに ping を実行する。 プレイブックを実行 面白くもなんともないが、プレイブックは無事実行終了。 コールバックプラグイン連携 次に hipchat のコールバックプラグインと連携し、hipchat のチャットルームにプレイブックの実行結果を通知させる。 hipchat の API を取得 hipchat 管理画面から Group Admin -> API とたどり、API TOKEN を発行する。 Ansible のコールバック設定 設定ファイル ansible.cfg でコールバックプラグインの場所を指定する。 今回は /tmp/callback_plugins/ 以下とする。 ansible.cfg ファイルは ANSIBLE_CONFIG