むー、前回の記事から1ヶ月経ってしまったか…。Riakについてドキュメントベースの机上調査をした。前回の記事の最後に「次はバックアップ/リストアを試す」って書いたけど、キャパプラとかハードウェア構成について調査したので、それのまとめについて。ドキュメントの意訳+メモ…。


次のような内容でまとめる。
  1. ハードウェア層
  2. OS層
  3. クラスタの留意点
  4. 負荷分散
  5. ベンチマーク
  6. BitcaskとLevelDB
  7. コンフィグファイル
  8. スケールアウトとスケールアップの手順
  9. 運用上の注意点
1. ハードウェア層
http://docs.basho.com/riak/1.3.1/tutorials/System-Planning/
  • 64ビットCPUアーキテクチャ
  • 最低4GBのメモリ。メモリは最も重要。局所性を活かせるのであれば多くメモリを必要としない。
  • RAID0、SSDを考慮すると良い。IOバウンドになりがちなので。
  • ミラーリング(RAID1)は考えなくて良い。
  • RAID(RAID1?)はやめちゃいな(クラスタ組んでるしいいんじゃない?的な?)。
  • ディスクサイズ重要。
  • ギガビットイーサも考慮にいれて。ネットワークも使うよ。
  • 仮想マシンを使う場合は一番良いインスタンスを使う。同じデータセンタ/リージョンに配置するようにする。
  • クラスタ全体で必要なディスクサイズは次のように計算できる。
    • オブジェクト数 * 平均オブジェクトサイズ * n_val
    • 50,000,000 objects、2,048bytes、n_val = 3の場合 : 50000000 * 2048 * 3 = 307200000000 = 286 GBytes
2. OS層

http://docs.basho.com/riak/1.3.1/cookbooks/Linux-Performance-Tuning/
http://docs.basho.com/riak/1.3.1/cookbooks/File-System-Tuning/
  • IOスケジューラはnoopもしくはdeadlineが良い。
  • ファイルシステムはzfsかxfsを推奨。zfsはプロダクションでは非推奨らしい…。
  • ext4を使うならnoatime, nobarrier, date=writebackをつけるように。
  • noatimeオプションを推奨。
  • open files limitを適切に上げておく。65536とか。ソフトリミット、ハードリミットともに。
  • カーネルパラメータ
    • vm.swappiness = 0
    • net.ipv4.tcp_max_syn_backlog = 40000
    • net.core.somaxconn=4000
    • net.ipv4.tcp_timestamps = 0
    • net.ipv4.tcp_sack = 1
    • net.ipv4.tcp_window_scaling = 1
    • net.ipv4.tcp_fin_timeout = 15
    • net.ipv4.tcp_keepalive_intvl = 30
    • net.ipv4.tcp_tw_reuse = 1
  • 10ギガビットイーサを使っているなら・・・
    • net.core.rmem_default = 8388608
    • net.core.rmem_max = 8388608
    • net.core.wmem_default = 8388608
    • net.core.wmem_max = 8388608
    • net.core.netdev_max_backlog = 10000
  • SWAP
    • スワップをoffるか、riakプロセスがスワップしないようにしとくのが良い。
    • スワップがoffられているなら、メモリ使えなくなると/var/log/riak/erl_crash.dumpを吐いて終了する。
 

3. クラスタの留意点

http://docs.basho.com/riak/1.3.1/references/appendices/Cluster-Capacity-Planning/
  • ノード数
  • リングサイズ/パーティション数
    • ring_creation_size(2の階乗値を設定できる)で決定できる。★この値はあとで変更できない★
    • デフォは64。これは最小クラスタの値。
    • 5ノード以上になるなら、これを増やした方が良い。
    • 1ノードあたりの最小パーティションサイズは10。
    • 中規模クラスタ 8 – 16ノードでは128, 256, 512パーティションくらいが良い。
    • いくつにしたらいいかわからん場合はMLに投げてこいとな…. : http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
  • パーティション
    • パーティションはだいたい同数のkey/valueを保持する。
    • パーティション少なすぎると、クラスタをスケールできる数の上限にすぐ達する。IOの並列数も上限に達する。
    • パーティション大杉だとコンテキストスイッチとIOの競合で過負荷になる。
    • 1ノードあたり、8〜64のパーティションを推奨。
    • これは例えば5ノードのクラスタの場合、最低256パーティション/クラスタもしくは512パーティション/クラスタであるべきことを意味する。
    • 512パーティションの場合、5ノードのクラスタは64ノードまでスケールさせることができる。512 / 64 = 8 partition/nodeになる計算なので。
  • データセンター跨ぎ
    • データセンターまたぎは非推奨
    • マルチDCオプションはRiak Enterpriseを…的な。
4. 負荷分散
http://docs.basho.com/riak/1.3.1/cookbooks/Load-Balancing-and-Proxy-Configuration/
  • VRRPは推奨しない
  • HW, HAProxy, nginx(HTTPのみ)
5. ベンチマーク
    1. Stop one or more nodes normally and restart them after a few moments (simulates rolling-upgrade).
    2. Join two or more nodes to the cluster.
    3. Leave nodes from the cluster (after step #2).
    4. Hard-kill the Riak beam.smp process (i.e., kill -9) and then restart it.
    5. Restart a node.
    6. Hard-stop and destroy a node’s instance and build a new one from backup.
    7. Via networking (firewall, perhaps), partition one or more nodes from the rest of the cluster, and then restore the original configuration.
6. BitcaskとLevelDB
http://docs.basho.com/riak/1.3.1/references/appendices/Bitcask-Capacity-Planning/

↑のページでHWスペックからBitcaskのクラスタのノード数の見積もりができる。
  • Bitcask
    • プロダクションではBitcask推奨
    • 低レイテンシ
    • 高スループット
    • Bitcaskはページキャッシュを使う
    • すべての”keydir”がメモリに乗ってる必要がある
      • たしかにデータ入れまくって実メモリサイズ超えるとOOMで死んだ…★
    • keydirはバケットとキーの連結されたハッシュテーブルになっている
    • セカンダリインデックスは使えない
  • LevelDB
    • LevelDBはBitcaskほど大きなメモリ容量は必要としない。
    • メモリを足すことができないなら、LevelDBを使った方が良いらしい。
    • ※ とりあえずBitcaskでいいやって思ってたからLevelDBについてはあんま調べてない…
7. コンフィグファイル
  • 設定ファイルはデフォルトでよく出来ている。
  • でもちょっと変更が必要。もっとも重要なのはパーティションサイズ(ring_creation_size)。
  •  LevelDBを使っているならIOスレッドプールを調整する。減らすことができる(減らせってこと?)。よくわからん…。
8. スケールアウトとスケールアップの手順
  • スケールアウトとスケールアップの手順はどちらも一緒
      1. ノードを追加/リムーブ/リプレースする : riak-admin cluster join/leave/replace
      2. 確認 : riak-admin cluster plan
      3. コミット : riak-admin cluster commit(やっぱりやめる!って場合は、riak-admin cluster clear)
      4. 再び確認 : riak-admin member-statusとriak-admin ring-statusで確認する。
  • スケールアップ時の留意点
    • ノードを交換するときは同じIP、同じデータを持たせる必要がある。
    • もしムリなら、新しいノードを追加したあとに、riak-admin cluster replace OLDNODE NEWNODEを実行する。
  • スケールアウト時の留意点
    • ノード追加は一個ずつやる必要がある。一度にビャッとやったらダメ。
    • ノードの追加の際、複数個のノードを追加するときは1回のcommitで行う。
9. 運用上の注意点
  • クラスタへのノード追加時
    • 新しいノードすべてが「join」状態になるまで、プランをコミットしちゃだめ。全ノードがjoin状態になってから、新しいノード追加作業をしろってことかな…
  • クラスタからノードを除去する場合
    • riak-admin cluster leaveで除去できる。
    • 残りのノードの負荷、容量とパフォーマンスを監視しながら、一度に1つのノードを削除するを推奨。
    • 1個ずつ除去すること。
  • ノードの変更(ノードの追加/除去?)は軽々しく行わない方が良い。
  • 新しいノードとの間で、データ再配布には時間がかかる。NWとディスクがボトルネックになる。
  • 処理に影響が出ないように、ハンドオフのスループットを制御できる。
    • riak-admin transfer-limit NODE LIMIT
    • これでhandoff_concurrencyに制限をつけることができる。
  • ノードがエラーとかメンテで使えなくなってもleaveはするべきではない。stopすれば良い。
  • エラーが起きりしたら・・・↓
  • http://docs.basho.com/riak/latest/cookbooks/Failure-and-Recovery/
 

ふう….

 

 

3 Responses to Riak 05 システムプランニング

  1. shino より:

    素晴らしいまとめありがとうございます。

    「スケールアウト時の留意点」について、

    http://docs.basho.com/riak/latest/cookbooks/best-practices/#How-to-add-Nodes

    1回の commit で追加したいノードを全部入れる」のが良いです。

    (もし docs.basho.com に1度に1ノードって書いてあったらゴメンナサイ)

  2. Kath より:

    Riakの運営資料を検索して偶然、このblogを拝見しました。すばらしいまとめです。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

Set your Twitter account name in your settings to use the TwitterBar Section.