Redis & Redis HA design with Keepalived

Redis & Redis HA design with Keepalived

Toshiki InamiJan 14 20161

Agenda

1. What is NoSQL?

2. What is Redis?

3. Redis HA design

4. Redis HA design @ Arukas

5. Q&A

2

What is NoSQL?

3

NoSQLとは？

● いわゆるビッグデータに対応する為の技術

● 2009年ごろから

● Not Only SQL ◎（Not SQL ☓）

● 水平拡張しやすい、スケールアウトしやすい

● 汎用的なハードを利用できる

● 複雑なデータ構造にも対応

● 2016年1月現在、 225種存在 ( http://nosql-database.org/ )

4

http://nosql-database.org/

What is Redis?

5

Redisの特徴

● イネーブラ型（他のミドルウェアと組み合わせることで高いパフォーマンスを発揮）

● キー・バリュー型

● オンメモリで高速

● アトミックな処理（後ほど説明）

● 様々なデータ型を持つ（後ほど説明）

● 結果整合性（レプリケーションの際にマスタからスレーブに書き込む間は複数のバージョンが存在）

6

Redisの様々なデータ型

● 文字列

"Value"

● リスト(新しい要素を先頭OR末尾に追加)

"Value1","Value2", "Value3"

● セット（文字列の順不同の集合、同じ要素は許容しない）

"Value1", "Value5", "Value6"

● ソート済みセット（スコアの順にならぶ）

"Value1", "Value9", "Value5"スコア１, スコア２, スコア３

● ハッシュ (フィールドとバリューのマップ)

: field1 => Value1

: field2 => Value2

7

Redisの様々なデータ型２

あとは、画像などの BLOB（ Binary Large Object )なども結びつけることが出来る。

=> データストラクチャ・ストアとも呼ばれる

8

アトミックな処理とは

排他制御（同時実行制御）によって更新を処理すること。トランザクションが保証される。

DB

A

B

書き込み

Aがデータの更新しているときは、他のクライアントからの更新はロックされ実行できない。

9

Redis HA design( HA = “High Availability”)

10

● Master / Slave replication の機能で対応　

● ( Redis cluster という分散実装で対応 )

● Redis sentinel サーバーを立てる

RedisのHA（可用性）を高める選択肢として

11





12

Redis Sentinel とは？

- Quorum ベースで redis ノードを定期的に死活監視

具体的には…

- インスタンスに異常が発生した際に、Administrator に通知

- master/slave のインスタンス間でのフェイルオーバーを担当

! Redis ver2.8 & 3.0 に内包されている

! Redis 本家プロジェクトで開発されている、HA（高可用性）を実現するための実装

13

Host1

( 192.168.0.1 )

Redis ( master )

Host2

( 192.168.0.2 )

Redis ( slave )

Redis sentinel図1Host3

( 192.168.0.3 )

Redis Sentinel

死活監視死活監視

死活監視 & replication

14

しかしこれでは100%の可用性を保つためには十分ではない。

15

Redis sentinel図2

Host3( 192.168.0.3 )

Redis Sentinel

死活監視死活監視

Host1( 192.168.0.1 )

Redis ( master )

keepalived（ master ）

Host4( 192.168.0.4 )

haproxy（ master ）

Host5( 192.168.0.5 )

Host2( 192.168.0.2 )

Redis ( slave )

keepalived（ slave ）

haproxy（ slave ）

死活監視 & replication

( 192.168.0.6)VIP

どっちが master か監視どっちが master か監視

16

複雑。。。

17

Redis sentinel

参考になる資料

http://redis.io/topics/sentinel

http://www.101tech.net/2014/08/08/highly-available-redis-cluster/

18

http://redis.io/topics/sentinel





19

Master / Slave replication とは

! Redis インスタンスの slave/masterを SLAVEOF コマンドで切り替えるシンプルな実装

! Redis 同士は replication （複製）するだけで、ルーティングの機能を提供しない。そのため冗長化を行なう際は、他のソフトウェアで補う必要がある

! Redis の死活監視をデフォルトで行っていない。工夫が必要になる

20

Master / Slave replication

Host1

( 192.168.0.1 )

Redis ( master )

Host2

( 192.168.0.2 )

Redis ( master )

21


Host1

( 192.168.0.1 )

Redis ( master )

Host2

( 192.168.0.2 )

Redis ( master )

$ redis-cli SLAVEOF 192.168.0.1

22


Host1

( 192.168.0.1 )

Redis ( master )

Host2

( 192.168.0.2 )

Redis ( slave )Replication

23


Host1

( 192.168.0.1 )

Redis ( master )

Host2

( 192.168.0.2 )

Redis ( slave )Replication

$ redis-cli SLAVEOF no one

24


Host1

( 192.168.0.1 )

Redis ( master )

Host2

( 192.168.0.2 )

Redis ( master )Replication

25

Master / Slave replication の動作の流れ

　1. slave がレプリケーションに参加すると、SYNC コマンドを送り master のバッファ（メモリ上のデータ）をディスクに書き込むよう指示する。

26

3. バックグラウンドでの保存が終了後、master は slave に保存したファイルを送る。そして、slave はそれをディスクに保存し、その後メモリにロードする。

4. master は slave に対して、バッファに存在する全てのコマンドを送る。

　2. master に BGSAVE が走り非同期バックグラウンドでの保存が開始される。その間に受け取ったコマンドはバッファーに保存される。

5. master と slave の replication が完了する





27

そもそもこれはHA（可用性）の向上をめざしているものではない。

28

Redis clusterとは● node同士でgossipプロトコルで生存を確認

● 複数台でデータを分割して保持 ( Partitioning )

● HAのためにあるのではなく、計算量を最大化してリソースを効率よく利用することが目的

● nodeをclusterのネットワークに入れれば、リシャーディングされる

29

redis node

redis node

redis node

redis node

redis node

client client client

Redis cluster

参考になる資料

http://redis.io/topics/cluster-spec

http://redis.io/topics/partitioning

http://redis.shibu.jp/admin/cluster/

https://www.digitalocean.com/community/tutorials/how-to-configure-a-redis-cluster-on-ubuntu-14-04

30

http://redis.io/topics/cluster-spec

http://redis.io/topics/partitioning

https://www.digitalocean.com/community/tutorials/how-to-configure-a-redis-cluster-on-ubuntu-14-04

● Redis Clusterは可用性を高める目的ではなく、Partitioningを利用してリソースを無駄なく利用することに重きをおいている。

● Redis slave/master : シンプルな構成でレプリケーションのみの機能

まとめ

● Redis Sentinel : 手軽にHAを高める目的だが、もしHA100％を実現しようとすると複雑化。オーバーヘッドに繋がる。

31

Redis HA design @ Arukas

32

そもそも可用性を高める目的ではない　=> X

よって、Master/Slaveのreplication をベースに実装◎

Arukasでは…

● Redis Cluster ?

● Redis Sentinel ?

構成が複雑化、そして運用の際にオーバーヘッドになる　=> X

33

Host1

( 192.168.0.1 )

Keepalived ( master )

Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )

Keepalived ( backup )

Redis ( slave )

死活監視

Replication

Layout

34

Tools● Host1 ( redis01.arukas.io )

- OS : Ubuntu14.04 LTS

- Redis : version 2.8.24

- Keepalived: version 1.2.7

- 2core-2GB

● Host2 ( redis02.arukas.io )

- OS : Ubuntu14.04 LTS

- Redis : version 2.8.24

- Keepalived: version1.2.7

- 2core-2GB

35

Btw….What the heck is Keepalived?

36

Keepalivedとは

● 具体的には、主に２つの機能を提供

● Version 1.2.19 - July 07, 2015 for Linux

37

● LVSを使ったロードバランサの機能＋HAの機能を提供する。

- 複数のサーバー間でIPフェイルオーバーを実現し、アプリケーションをサーバーごとに、アクティブ/スタンバイで冗長化をする為

- サービスの稼働状況に応じてロードバランサの設定を変更し、停止しているサービスに対してリクエストが振り分けられないようにすること。

- ロードバランサ自体を冗長化する

■このために VRRP ( Virtual Router Redundancy Protocol )を用いて、Keepalived の backup がパケットを送信し、死活監視をする。そして複数のロードバランサの存在を仮定してIPを一つにまとめる必要があり、VIP ( Virtual IP ) を作成する。

● 今回の使用目的

- アプリケーションの死活監視の為

Keepalived

Host1

( 192.168.0.1 )


(192.168.0.3 )VIP

Host2

( 192.168.0.2 )


38

Keepalived

Host1

( 192.168.0.1 )


(192.168.0.3 )VIP

Host2

( 192.168.0.2 )


VRRPパケットを送り監視

39

Keepalived

Host1

( 192.168.0.1 )


(192.168.0.3 )VIP

Host2

( 192.168.0.2 )


40

41

/etc/keepalived/keepalived.conf

ではもう一度全体のレイアウトを見てみましょう。

42

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

(192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

Layout

43

障害発生パターンとその対応プロセス

● Host1側

- Keepalived ( master ) の突然死

＊ここでは説明を簡易化する目的で、先ほどのレイアウトと同じパターンであることを想定します。勿論、障害発生後にはRedisのmaster/slave、Keepalivedのmaster/backupが入れ替わることも発生します。

- Redis ( master ) の突然死

- Host1 の突然死

● Host2側

- Keepalived ( backup ) の突然死

- Redis ( slave ) の突然死


44

障害発生パターンとその対応プロセス● Host1側




● Host2側




45

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

46

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.3 )


Redis ( slave )

死活監視

Replication

47

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.3 )


Redis ( slave )

死活監視

Replication

48

Host1

( 192.168.0.1 )

Keepalived (backup)

Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

このタイミングでnotify_master が呼

ばれる

49

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( master )

死活監視

Replication

50

notify_master ってなに？

51

Notify script とは

● KeepalivedのVRRPの状態( master / backup / fault )によって、任意のスクリプトを実行できる機能● 謎にドキュメント化されていない

● 種類としては、

- notify_master

- notify_backup

- notify_fault

VRRPの状態が masterの場合呼ばれる

VRRPの状態が backup の場合呼ばれる

VRRPの状態が fault の場合呼ばれる

52

notify_master


/etc/keepalived/notify_master.sh

53



● Host1側




● Host2側




54

っと、Redisが突然死ぬと言っても誰がどのように監視しているのでしょうか？

55

Check script ( vrrp_script ) とは

● Keepalived が任意のスクリプトを定期的に実行してくれる機能

● 謎にドキュメント化されていない

- そのスクリプトはリターン値を明記する必要がある。 0 か 1。

56

- 0 を返した場合 => そのまま継続

- 0 を返した場合 => VRRP が FAULT 状態に変化する


/etc/keepalived/redis_health_check.sh

57


Check script ( vrrp_script ) とは

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

Check script が定期的に実行されてい

る

58


る

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

59


る


る

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

Redis 死亡確認！

60

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

このタイミングでnotify_fault が呼ば

れる

61

notify_fault


/etc/keepalived/notify_fault.sh

62


Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

63

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

64

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

65


ばれる

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( master )

死活監視

Replication

66


● Host1側




● Host2側




67

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

68

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

69

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )

Keepalived ( master)

Redis ( slave )

死活監視

Replication


ばれる

70

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )

Keepalived ( master)

Redis ( master )

死活監視

Replication

71


● Host1側




● Host2側




72

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

73

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

何らかの形でリスタート　Ex. Supervisord

74

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

75

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

このタイミングでnotify_backup が呼

ばれる

76

notify_backup


/etc/keepalived/notify_backup.sh

77


Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

78


● Host1側




● Host2側




79

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

80

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

81


る


る

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

Redis死亡確認！

82

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

83

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.3 )


Redis ( slave )

死活監視

Replication


84

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( master )

死活監視

Replication

85

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( master )

死活監視

Replication


86

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )

Keepalived ( backup)

Redis ( master )

死活監視

Replication


ばれる

87

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

88


● Host1側




● Host2側




89

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

90

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

リブート

91

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( master )

死活監視

Replication

92

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( master )

死活監視

Replication

93

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( master )

死活監視

Replication


ばれる

94

Host1

( 192.168.0.1 )


Redis ( master )

死活監視

( 192.168.0.3 )VIP

Host2

( 192.168.0.2 )


Redis ( slave )

死活監視

Replication

95

96

苦戦した点

● Redisのmaster側のhostをリブートした後に、少ない頻度でレプリケーションがされない

… ”Unable to connect to MASTER: Resource temporarily unavailable Connecting to MASTER no:0”…

- メモリーリークと疑い、redis をアップデート => 失敗

トライしたこと

- Linux kernel overcommit memory の設定を 1 へ変更 => 失敗

- システムのプロセステーブルがいっぱいになっているために fork(2) システムコールが失敗か？ =>いや、いっぱいになっていない

- メモリーまたはスワップ空間が足りないためにシステムコールが失敗か？ => 足りなくない

- ユーザーがそれ以上プロセスの作成を許されていないので失敗？ => そんなことはない

97

苦戦した点

- プロセスのブートオーダーが原因だった！（ Keepalived => Redis という順番）

結局、、、

- リブートした時に Keepalived のnotify_backupが呼ばれた段階では、redis slave of <IP> <PORT>が実行されない。その後Redisが呼ばれ、Connecting to MASTER no:0と出力される。つまり、どこにもレプリケーションが取れていなかった為である

解決策

- update-rc.d -f keepalived remove

- update-rc.d -f keepalived defaults 99

＊Chefを使っている場合は、service リソースの priority の部分で調整する必要あり

Q & A

98

Technology

Redis & Redis HA design with Keepalived