Aerospike Rapid Rebalance
Download as pptx, pdf1 like1,242 views
Aerospike meetup04 Tokyo
Aerospike Rapid Rebalance
- 1. Rapid Rebalance Aerospike v3.8.3 2016/08/02 Aerospike Meetup #4 in Tokyo 上原 誠
- 3. マイグレーションのつらたん(??ω?`) 運用上必ずある”静的なコンフィグ変更”、”ASバージョンアップ”、”ノードメンテナ ンス”で必ずマイグレーションは走ります ? マイグレーション中はレプリケーションファクタがマイナス１ ? マイグレーションの時間が長い(3TBくらいだと20h超え) ? クラスタ内のノード全台にバージョンアップする場合、マイグレーション終了を 待つ必要があるので、所要時間は↑掛けるノード数(5台ノードクラスタだと1週間) ? マイグレーション速度のスレッド調整は手動 ? マイグレーション中の負荷がサービスに若干影響出ることも
- 5. Rapid Rebalance in v3.8.3 in June.
- 8. Intro ? マイグレーションはリンク障害、ノードリスタート時のリバ ランスと同期プロセス ? EEのv3.8.3ではこのマイグレーションが40倍速くなった ※新規ノード追加とかフォーマットされたノード追加、また多 分ノード削除時もRapid対象外。 つまりメンテナンスや障害によるプロセスのリスタートやネッ トワークの瞬断のような一時的な状況をRapid Rebalanceは想定 している。 要約
- 10. High-Level Design ? 受信側から送信側にパーティションのメタデータを送る。 ? 送信側でデータを比較し送る必要があるデータを判断し送る。 この判断にはgenerationかlast-update-timeのいずれかを使っ て判定する。 要約
- 14. Challneges ? ①メタデータを順番通り送るためシーケンス番号を付加しま した。送信側が1つ前のackを確認してから次のバッチを受け 取る。最終番号を管理してる。もし若い番号を受け取っても 処理しない。 ? ②メタデータをレコード単位ではなく128KB単位(バッチ)で送 る ? ③データ量によってはメタデータのやりとりのコストが大き くなるので、RRを使わず従来の方法で送る場合もある 要約
- 15. Implementation ① 送信側から受信側に、開始メッセージ（RRをサポートしている こととそのパーティション内のデータ数を含む）を送る。 ② 受信側は、(Challenge③)を考慮して、RRを使うか否かのackを返 します。 ③ 受信側がRRを利用する場合、メタデータのバッチを生成するた めのproducerとconsumerのスレッドを立てます。 ④ producerスレッドは、対象のパーティション内のデータをス キャンし、メタデータ?バッチを作成し、キューに入れます。
- 16. Implementation ⑤ consumerスレッドは、キューからバッチを取りだし、シーケンス番 号を付けて、送信側に送ります。consumerは、受信側からackが返って くるまでは、次のバッチの処理を開始しません。 ⑥ 並行して、送信側は、受信側がRRをサポートしているかを含んだ開 始メッセージを受け取り、マイグレーションのためのデータのスキャン を開始します。RRがサポートされている場合、メタデータ?キューを ブロックします（ここちょっと詳細不明、1つづつ処理する為？でも キューでしょ？）。 ⑦ 送信側が受信側からのバッチを受け取った後、それをローカルの キューに入れ、受信側にackを返します。 ⑧. 送信側では、バッチの内容を調べ、受信側に送るデータの判断をし ます。
- 20. 検証環境 ? Aerospike Server Spec Aerospike Server x3, Replication Factor 2 OS CentOS6, m3.xlarge, SSD 100GB x3, IOPS 3000 SSD Capacity 900GB(HWM 50%) MEM Capacity 42GB(HWM 60%) Before Binary：aerospike-server-community-3.6.3-el6 After Binary：aerospike-server-enterprise-3.8.4-el6
- 21. 検証環境 ? Client Java Client Library 3.2.4 ? Aerospike Management Console 3.6.9 aerospike-amc-enterprise-3.6.9-el6.x86_64.rpm
- 22. 旧バージョンで試す ※データやスペックなど環境によって結果は変わります。あしからず。 一例として参考にしてもらえればと。 ./run_benchmarks -h xxx.xxx.xxx.xxx -p 3000 -n test -k 100000000 -l 30 -s 1 -o S:1500 -w RU,0 -z 16 約1億件のデータでレプリ込で３００GBの容量 1レコード1500byteでちょっとでかい。。 Let’s Try! プロセスのリスタート実施
- 25. Versionup to v3.8.4 ? １台プロセスをリスタート。１０：５４ ? 1時間15分くらいしてノードイン、12:16にクラスタイン
- 26. versionup to v3.8.4 ? １台プロセスをリスタート。１０：５４ ? 1時間15分くらいしてノードイン、12:16にクラスタイン
- 28. ノードのクラスタイン確認。02:42:26 Let’s Try! バージョンアップ後同じデータに対してプロセスのリスタート実施 Mean of Partitions log absent: Number of partitions not owned by this node sync: Number of non-master partitions owned by this node actual: Number of master partitions owned by this node actual + sync + absent = 4096 partitions for the namespace
- 30. １分１３秒
- 35. １６分０７秒
- 36. ４４倍！ ほう！！
- 40. Rapid Rebalance so good!
- 41. But this is the Enterprise Edition functionality.
- 42. Mr. Braian
- 43. Please also add in a Community Edition.