ESXi の ローカルストレージ上のVMパフォーマンス

ホスト内部のディスクは、ESXi のドキュメントではローカルストレージと呼ばれています。

ESXi のドキュメント: vSphere ストレージ

このローカルストレージ上に仮想マシンを格納した場合に、仮想マシンのパフォーマンスが低く困っていました。

具体的には、１つの仮想マシンが多くのディスク書込を実行した場合、同じホスト上にある他の仮想マシンが一時停止したような状態になってしまいます。

調べてみると、以下の Knowledge Base を見つけました。

Slow ESX/ESXi performance caused by misconfigured local storage or SAN array (1006602)

「パフォーマンスが低くなる場合に、ホストで write-back cache が設定されているか確認してください」という内容です。

私の環境でも write-back cache が設定されていませんでした。

write-back とは、RAID の write policy の１つで、RAID コントローラに搭載されているキャッシュを使用して書込性能を向上させる仕組みです。これを使用する場合、予期しない電源断などの異常時にデータ損失を防ぐため、RAIDコントローラにバッテリバックアップが搭載されていることを確認しておく必要があります。

以下のページでは、write-back／write-through の比較、ESXi で write-back が重要になる理由が説明されており、とても参考になりました。

Solving Slow Write Speeds When Using Local Storage on a vSphere Host

To compensate for write-through scenarios, a server will often use it’s own RAM to assist in the caching process.

write-through の状況を補うために、多くの場合、サーバは自身の RAM をキャッシング・プロセスを補助するために使用するでしょう。

The ESX hypervisor does not steal memory to perform this caching, and thus has to wait on disk directly when write-through is used. Remember, the hypervisor is designed to be as lightweight and non invasive as possible, and caching large writes into memory would require that the hypervisor either 1) have larger amounts of memory assigned to it, or 2) steal from the resources normally reserved for VM workloads.

ESX ハイパーバイザは、このキャッシングを実行するためにメモリを steal しません。そのため write-through が使用されている時、直接ディスクを待たなければなりません。ハイパーバイザは、可能な限り軽量・非侵襲であるようにデザインされていることを忘れないで下さい。多数の書込をメモリにキャッシュすることは、ハイパーバイザが１）それにアサインする多くのメモリを持つか、２）本来 VM のワークロードのために予約されたリソースから steal することを必要とするでしょう。

Cyberduck から S3 へアップロード時のパーミッション

Cyberduck から S3 へファイルをアップロードした際に、自動的に Everyone へ閲覧許可が設定されてしまい、Bucket Policies でアクセス制限をコントロールしたい場合に、不便に感じていました。

例えば Bucket Policies で、特定のIPアドレスからのみアクセスを許可していても、ファイルに Everyone の閲覧許可がされていると、そちらが優先されてしまいます。

アップロード時のパーミッション設定が、Cyberduck の環境設定には見つからなかったのですが、ドキュメントに説明がありました。

$ defaults write ch.sudo.cyberduck s3.bucket.acl.default private

上記の設定をすることで、Everyone への閲覧許可が自動的に設定されなくなります。

EC2 のインスタンスで chef-client が UndefinedConversionError

EC2 のインスタンスに chef-client をインストールして使っていたのですが、user-data を設定したインスタンスだけ、chef-client がエラーになってしまいます。

エラーメッセージは以下のようなもの。

FATAL: Encoding::UndefinedConversionError: "\x8B" from ASCII-8BIT to UTF-8

確認してみたところ、json への変換部分でエラーになっている模様。

lib/chef/node.rb

    # Serialize this object as a hash
    def to_json(*a)
      result = {
        "name" => name,
        "chef_environment" => chef_environment,
        'json_class' => self.class.name,
        "automatic" => automatic_attrs,
        "normal" => normal_attrs,
        "chef_type" => "node",
        "default" => default_attrs,
        "override" => override_attrs,
        #Render correctly for run_list items so malformed json does not result
        "run_list" => run_list.run_list.map { |item| item.to_s }
      }
      result["_rev"] = couchdb_rev if couchdb_rev
      result.to_json(*a)
    end

result の中身で "\x8B" が入っているところを探すと、userdata の部分にありました。

{ ... "userdata"=>"\x1F\x8B ... }

どうやら、user-data を作成する際に圧縮をしていたため、userdata にバイナリのデータが入っていたことが原因のようです。

CloudInit のページを参考に、user-data を圧縮していたのですが、16KB のサイズ制限を超えているわけでもないので、圧縮しないことで回避することにしました。

user-data の内容は、Node の Attribute に含まれていて、chef-server で Attribute を表示するためなどの目的で、json へ変換しているのですね。