MySQL 冗長化モデル

1. MYSQL 冗長化モデル

2. １章基本設計

3. 1-1 DB（MySQL）の冗長化とは何か  MySQLはMaster・Slaveの構成を行いますが、これは『更新』と『参照』と役割が異なっているだけであり、冗長化とは意味が異なります  プログラム上で『更新』『参照』についてそれぞれの宛先（IP）を役割毎にハードコートしており、どちらか片方に障害が起こるとサービスに影響が出ます ⇒『更新（Master）』『参照（Slave）』を、それぞれ冗長化する必要があります

4. 1-2 冗長化に向けた設計方針  サーバーHW障害に対し、サービスが継続できること  障害時のダウンタイムが限りなくゼロであること ⇒24h/365dサービスを目指すため、ボトルネックを可能な限り減らす  障害発生時には自動的にサービス復帰する ⇒運用の自動化により、運用の安定化及び省力化を目指す  プログラムは障害対応を意識せずにコーディングできること ⇒障害に備えたプログラムコーディングは、コードの肥大化とともにコーディング漏れ等の人的災害も起こりえる  スケールアウトできること ⇒サーバー1台の処理能力がサービススペックの頭打ちにならないように ⇒拡張性を考慮することで、DBがボトルネックにならないように  待機サーバーの数を可能な限り減らし、資産を有効活用する ⇒『備え』の工数を増やしても、稼働のサービスレベルは上がらない

5. 1-3 冗長化を支える技術ミドルウェア役割 MySQL データベースサーバー LVS MySQLサービス自体の死活監視を行い、MySQLを仮想化する Iptables 『MySQLサーバーは生きているが、サービスに問題が有る』場合に、仮想サービス自体から切り離す

6. ２章詳細設計

7. 2-1 全体構成図 LVS#1 LVS#2 Master 稼働 Master 待機 Slave# 1 Slave# 2 仮想IP#1 仮想IP#2

8. 2-2 MySQL仮想化 LVS#1 LVS#2 Master 稼働 Master 待機 Slave# 1 Slave# 2 仮想IP#1 仮想IP#2 クライアントはMySQLにアクセスする際、『LVSが作成した仮想 IP』にアクセスします。 LVSはクライアントからの信号を MySQLに転送します。 LVSはMySQLサーバーの生死判定を定期的に行っております。この処理によって、仮想IPへアクセスされた信号は、現在生きているサーバーへと転送されます。この機能を利用し、『更新』『参照』それぞれのMySQLを仮想化しております。

9. 2-3 MySQL同期処理 LVS#1 LVS#2 Master 稼働 Master 待機 Slave# 1 Slave# 2 仮想IP#1 仮想IP#2 MySQLはレプリケーション処理によって、２つのMySQLサーバーが同一になる機能があります。詳細としては、参照先のMySQLの更新命令を参照元に適用することで、双方が同一になるというものです。現在は下記矢印の向きで更新命令を参照している状態です。上記機能を利用し、 Master（稼働・待機）に更新が入ると、4台のMySQLに適用されますので同一の状態になります。

10. ３章障害対策

11. 3-1 MySQL障害対策/前提 LVS#1 LVS#2 Master 稼働 Master 待機 Slave# 1 Slave# 2 仮想IP#1 仮想IP#2 MySQLの仮想化の最大のポイントとなるのは、『参照先サーバーに障害があった場合は、自分自身の情報は信頼出来ないものとする』事です。つまり『参照元から更新情報が得られない』＝『自分自身の情報は最新でない』という考えです。これを実現するために、『自分自身のレプリケーションになんらかの障害が発生していた』場合、『親からの死活監視に無応答を返す事で、自発的に仮想化から切り離す』処理を行なっております。これはLinuxのファイアーウォール機能である iptablesによって実現しております。

12. 3-1 MySQL障害対策/Slave障害 LVS#1 LVS#2 Master 稼働 Master 待機 Slave# 1 Slave# 2 仮想IP#1 仮想IP#2 Slaveに障害が起こった場合は、『仮想IP=2台』という割り当てから『仮想IP=1台』という形に縮退動作を行います。また、すべてのSlaveに障害が発生した場合は『仮想IP=Master待機』へと割り当てが行われます。

13. 3-2 MySQL障害対策/Master待機障害 LVS#1 LVS#2 Master 稼働 Master 待機 Slave# 1 Slave# 2 仮想IP#1 仮想IP#2 Master待機に障害が発生した場合は、2ステップの縮退動作が行われます。 1. LVSの監視により、『仮想IP#1』から『Master待機』が切り離される 2. Slave#1自身がMaster待機の障害を検知した時点で、LVSの死活監視に応答を返さない処理を行う。これにより、『仮想IP#2』から『Slave#1』が切り離される

14. 3-3 MySQL障害対策/Master稼働障害 LVS#1 LVS#2 Master 稼働 Master 待機 Slave# 1 Slave# 2 仮想IP#1 仮想IP#2 Master稼働に障害が発生した場合は、3ステップの縮退動作が行われます。 1. LVSの監視により、『仮想IP#1』から『Master待機』が切り離される 2. Slave#1自身がMaster待機の障害を検知した時点で、LVSの死活監視に応答を返さない処理を行う。 3. LVSがMaster障害を検知した段階で、『Master待機』を『Master稼働』に昇格させる

15. 3-4 仮想IP冗長化 LVS#1 LVS#2 Master 稼働 Master 待機 Slave# 1 Slave# 2 仮想IP#1 仮想IP#2 LVSはハートビート（VRRP）信号でお互いの生死判定を行います。『稼動系LVS』が死んだ場合は、『待機側LVS』が仮想IP を自分自身に割り当てます。これにより仮想IPは、LVS サーバー2台に障害が発生しない限りサービスを継続することができます。

16. 3-5 MySQLスケールアウト LVS#1 LVS#2 Master 稼働 Master 待機 Slave# 1 Slave# 2 仮想IP#1 仮想IP#2 将来的にサイトへのアクセスが集中し MySQLがボトルネックとなった場合は、参照用仮想IPアドレスにSlave用MySQL を追加することになります。応答するサーバーが増加する為、負荷軽減となります。（スケールアウト） Slave# 3

17. 4章まとめ

18. まとめ DBサーバーは情報が一元集約されるポイントのため、単一障害点かつ高負荷になりやすいです。そのため既存のソリューションでは、あらゆる高負荷に耐えられる筐体を用意する方向に進んでおりました。（スケールアップ）本設計はこの問題点を解消し、かつスケールアウトを確保出来るものとなっております。

19. 以上

MySQL 冗長化モデル

Zaki_XL

MySQL 冗長化モデル