結論
AWSのRDSで、設定一つでHA構成が出来ちゃうのってすごいよね
っていうのを再認識するための記事になってます
高可用性（HA: High Availability）って何？
簡単に言うと 「システムが止まらない」 事です。
ATMが24時間使えることっていうのは当たり前なようで大変なことなんですね。
この前、ETCの障害がありましたが、ああいうの見るとインフラエンジニアは胃がきゅっとなるそうで。
この記事で学ぶこと
今回はオンプレミス環境でのHA構成を一から構築してみます。
毎回「何がシングルポイント（単一障害点）になるか？」を見つけて、
対策を追加していく過程を体験できます。
最後には「AWSのRDSがいかに簡単か」が実感できるはずです。
オンプレミスとクラウド(PaaS)
- オンプレミス：自社でサーバやルータなど購入して管理する
- クラウド：管理をお任せ
例えば、完全閉域網でAWS等を利用できない時はオンプレミス環境を作る必要があります。
よほどの事がないと最近は無いかもしれませんが。
今回の目的
今回は、オンプレミスで高可用なDBサーバを構築するというシミュレーションをします。
めったにやらない事をなぜやるか？
いかにAWSやGCPが楽なのかというのを知るために。
AWSやGCPがこれから説明する構成という訳じゃないです。あしからず。
構築していく
構築→どこが故障するとダメかを考えます。
シングルポイント、単一障害点が無くなるまでこれを繰り返します。
1. とりあえずDBサーバを構築
はい、ルータがあって、L2スイッチをとりあえず置きました。
その下にDBサーバがありますね。MySQLでもPostgreSQLでもなんでもいいです。
そして、SSDが 一枚 です。
この構成のシングルポイントを考えます。
シングルポイント
はい、皆さんの想像通りです。
SSDが死んでしまうとサービスが停止します。
2. RAID10+Standby構成にする
SSD1枚では戦えないことが分かったので、5枚さします。
RAID10構成はRAID1+RAID0を組み合わせた構成のことです。
ストライピング(RAID0)
データを分割することで並列にデータ書き込みが出来るので高速化を図れます
ミラーリング(RAID1)
データをコピーして保存します。
その分遅くなりますが、RAID0構成でその分を補います。
RAID10が故障に強い理由
データが以下のように保存されます：
- Drive1: データA, Drive2: データAのコピー
- Drive3: データB, Drive4: データBのコピー
→ 同時に最大2台故障(例えばDrive1,3)してもサービスが継続可能です。
故障しても大丈夫か
2-1. SSD:Aが故障した場合
この場合A'が生きているので、読み書きは続行可能です。
また、予備のStandbyが即座にAへ成り代わります。
その間に新しいSSDへ交換してStandby用にしてしまえばOKです
シングルポイント
はい、これで大丈夫。とはいきません。
L2SW--サーバ間のケーブルがシングルポイントになります。
（他にもあるけど、気づいた人はちょっと待ってくださいね）
3. Bonding（active-backup）設定を入れる
2本のケーブルをつなぎ、1本の論理的なインターフェースとして動作させます。
故障しても大丈夫か
Bonding設定をいれると1本が死んでも、もう片方が生きていればOKです。
NIC(Network Interface Card)も分けます。（こういうのです）
この場合、eth0,4でBonding設定を入れます。
そうすることでNIC自体が死んでしまった時でも動作するようになるからです。
NICが死ぬって中々遭遇しないかもしれませんが。
シングルポイント
はいこれで安心、ではないですね。
L2SWが一台だと、これが壊れたらせっかく色々やったのにすべてパァです。
そろそろ面倒だなと思ってきましたか？HA構成って大変です。
4. NW機器を冗長構成にする
- Routerを追加し、VRRP(Virtual Router Redundancy Protocol)で一つのRouterに見せかける
- VIP(Virtual IP Address)が設定されて、Masterが死ぬとBackupがMaster昇格する
- L2SWを追加、お互いを接続し、VirtualChassisというので一個のSwitchに見せかける 1
- これで一台が死んでも片方が接続できるという状態
故障しても大丈夫か
4-1. L2SW故障時
右側のL2SWが生きてるので、経路としては通るので問題なし。
本当は経路の死活監視用のプロトコルや経路計算のプロトコルとか複雑なのがあってこうなる（はず）
インフラエンジニアの人にこんな絵を描いたら怒られるかもしれない
4-2. Routerの故障
4-1とそこまで変わりません。
とりあえず問題なさそうですね。
シングルポイント
まぁ、お察しの通りですがDBサーバ自体です。（システムダウンとか、筐体が壊れたとか）
5. DBサーバを２台構成にする
DBサーバ自体にもVRRPが適用され、DBサーバ用のVIPも設定します。
ちょっと見づらいかもしれないけど、こんなイメージ。
VIP1はルータのデフォルトゲートウェイ、VIP2はDBのサービスポートになります。
サーバ間でつながってる２本の線はレプリケーション用、要するにDB間でデータをコピーするために直接つながってる線です。
これもBonding設定を入れます。
これだけでサーバに4ポート必要となります。
故障しても大丈夫か
割愛。
筐体は生きてるけど、アプリケーションが落ちた場合、CPUの負荷が100%になった場合など
Pacemakerとかいい感じにアプリが処理してくることにしましょう。
そのためにはSTONITHっていうので相手をシャットダウンさせたり、再起動させるようなボードがあります。
HPだとiLO、富士通だとiRMCとか呼ばれてます。
シングルポイント
そうですね、電源冗長が出来ていないですね！
コンセントが一本でもぬけたら死にますね！
電源も冗長しましょう（電源ポートが一個しかないNW機器やサーバもあります）
さらにサーバルームの電源もAとBとか2系統あるので別系統に刺さないと、大本が落ちたらみんな死んじゃうから注意ですねー。
さらに言うと電源冗長があったとしても、ひとつのデータセンターにまとめておいていると大震災や火事などの災害時にサービス断となりますね。
別の離れたところに同じ構成を置く必要がある、と言われるかもしれません。
何としてもサービスを止めてはいけないような場合ですが。
AWS RDSでの設定
じゃあ、どのくらいRDSだと簡単なのかというと、この設定だけです。(MySQL選択時)
AZも分かれており、災害でデータセンターが壊れたとしてもスタンバイ系が生きてるのでサービスが継続できます。
複雑な配線もありません。
まとめ
どうですか、HA構成を取るためだけに様々な工夫や機能を駆使していきました。 疲れた 面白いでしょう。
今回はサービス網だけを考えてますが、実際は監視網も構築するのでもっと線がいっぱい必要になるかと思います。
遠隔からサーバやルータに入るための線だったり、ZABBIXなど監視サービスが見るための線ですね。
私はネットワークインフラについては素人か初心者レベルなので、詳しい人が見たらもっと改善点が出てくるかもしれませんね。
面白いと思った方はインフラエンジニアの素養があります。
RDSのマルチAZって設定するだけでHA構成になるんだから凄いですよね。
もっとシンプルなのかもしれませんけどね。
-
VirtualChassisってJuniper社のSWでの名称でした。CiscoだとStackとか言うらしい。ヤマハでもスタック ↩