20121115 オープンソースでハイアベイラビリティ!...
DESCRIPTION
オープンソースでハイアベイラビリティ! ~クラスタ管理の設計構築ハウツー&エンジニア思考力~ http://www.pasonatech.co.jp/event/index.jsp?mode=2&d=on&no=3649TRANSCRIPT
これから求められるサーバ構築オープンソースでハイアベイラビリティ!
~クラスタ管理の設計構築ハウツー&エンジニア思考力~
年齢 35歳(いつのまにか…)職業 株式会社ハートビーツ MSP事業部
運用エンジニア
活動 Linux-HA Japan Project日本Unboundユーザ会執筆活動Etc...
岩崎 のぼる Noboru Iwasaki
PROFILE
AGENDA
・どのようなサーバが運用されているか ・従来のサーバ構築思想にプラスされるハイアベイラビリティ(HA)思考 ・とめられないサーバのクラスタ構築 ・常に付きまとうコストと可用性のバランス ・HAなインフラ時代のサーバ環境 ・復旧を重視したサーバのクラスタ構築 ・HA技術動向のこれから ・事例紹介 ・要件によってによりソリューションを正しく選択すること
どのようなサーバが運用されているか
止められるサーバ 止められないサーバ
● 社内業務用サーバ(休日対応)● 企業ホームページ● 無料提供しているサービス● Β公開状態のサービス● 定期的なメンテナンスを決めて
いるサービス
● ショッピングサイト● 情報収集サーバ● ソーシャルゲームサーバ● 金融系決済サーバ● 医療システム系サーバ
etc...
止められるサーバの運用
■メリット ・計画的に停止させてメンテナンスを行うことができる ・アプリケーションのバージョンアップ対応が安易にできる ・運用コストを低価格にできる場合が多い
■デメリット ・止まってしまう場合があるので止められる運用になっている場合が多い ・収益性の高いサービスを提供している場合停止時間の損失が増える ・止まっている最中はどうしても不便をユーザに強いる事になる
止められないサーバの運用
■メリット ・サービス自体の収益性を最大限に引き出せる ・「いつアクセスしても使用できる」ため比較的リピーター率が高い ・かっこいい(と思っている人が居ます)
■デメリット ・規模が大きくなると停止した際の損失額が大きい(○○万円/分とか) ・アプリケーションのバージョンアップが困難 ・運用コストが止められるサーバに比べて高くなる傾向がある
本音
どのようなサービスにしろ落とさず運用可能なものがいい。
■課題・ハードウェアやソフトウェアの障害・OS自体のバージョンアップ・スケールアップ・環境の移設等々
High Availability(ハイアベイラビリティ)
可用性=継続してシステムが稼働できる能力の度合いを示すもの。一般的には1年間での稼働率を基準とする。◆表現方法 可用性が高い=非稼働時間が少ない 可用性が低い=非稼働時間が多い
稼働率(かどうりつ)
平均故障間隔(MTBF)平均故障間隔(MTBF)+平均修理時間(MTTR)
=
稼働率(かどうりつ)
稼働率 年間停止時間99.9999% 32秒99.999% 5分15秒99.99% 52分34秒99.9% 8時間46分99% 3日と15時間36分
稼働率は予測不可能
・起きていない障害の故障時間は予測不可能・起きていない障害の修復時間は予測不可能
稼働率は、実績から算出するものですので、「このシステムを導入すれば稼働率は○○くらいになります」とは言ってはいけません。「このシステムを導入して稼働率が○○%から○○%になった実績があります」と言い方を変えましょう。
可用性を向上させる思考
① 落ちない・壊れない環境を構築する② 壊れたら困るサーバの予備を用意しておく③ 複数稼働させておいて壊れたら切り替える
可用性を向上させる思考
① 落ちない・壊れない環境を構築する② 壊れたら困るサーバの予備を用意しておく③ 複数稼働させておいて壊れたら切り替える
無理
データの取り扱い
・定期的なバックアップを取る・常に新しいデータを共有するためレプリケーションをする
可用性を高めるには?(重要)
① 落ちないサーバを目指すのをやめる。② 可用性を高めるソフトウェアの導入。③ サーバ障害の早期発見④ 復旧に必要な業務の定義(運用改善)
可用性を高めるソフトウェア
●KeepAlived+LVS- VRRPによる相互死活監視- L4層での仮想IP付け替えによるフェイルオーバー- LVSによるロードバランシング機能
● Pacemaker+Heartbeat+DRBD- Heartbeatによる相互死活監視- Pacemakerによるリソース監視- DRBDによるデータのリアルタイムレプリケーション (+遠隔地へのデータレプリケーション可能)
止められないサーバのクラスタ構築
KeepAlived+LVS KeepAlived+LVS
Web Web Web Web
DB(更新+参照) DB(参照)
network
障害が起きても止まらない構成を考える
仮想IP振り分け
負荷分散クラスタ
DNSラウンドロビン
止められないサーバのクラスタ構築KeepAlived+LVSを用いたクラスタ構成の特徴
■機能 ・サービスのヘルスチェック機能(シェルスクリプト) ・仮想IPアドレスの制御 ・複数あるサーバへのラウンドロビン(負荷分散機能)
■特徴 ・障害発生時ダウンタイムが極めて少ない ・適用できる構成に制限がある(後述) ・サーバ構成が複雑になりがちで、運用コストが高い傾向がある
止められるサーバのクラスタ構築
Pacemaker Pacemaker
Web Web
DB DB
network
障害が起きた際の挙動を考える
アクティブサーバ スタンバイサーバ
仮想IP 仮想IP
DRBDによるリアルタイムデータ同期
こんな構成もあります。1:nのフェイルオーバークラスタも視野に入れる
DRBDによるリアルタイムデータ同期
サーバA
Pacemaker
Webサーバ
DBサーバ
Postfix
サーバB
Pacemaker
Webサーバ
DBサーバ
Postfix
サーバC
Pacemaker
Webサーバ
DBサーバ
Postfix
ストレージ
Pacemaker
iSCSI
ストレージ
Pacemaker
iSCSI
止められるサーバのクラスタ構築Pacemaker+DRBDを用いたクラスタ構成の特徴
■機能 ・サービスのヘルスチェック機能(Open Cluster Framework) ・仮想IPアドレスの制御 ・サービスの挙動制御(起動制御・ステータス変更制御等)
■特徴 ・障害発生時ダウンタイムがある程度発生する(サービス起動時間) ・適用できる構成に制限が少ない(後述) ・サーバ構成が単純で、運用コストが安い
疑問:どっちの構成が良いの?答え:場合によってどちらが適切かを判断する (どちらが優れているというようなものではありません。)
■KeepAlived+LVSを考える ・全てのサービスに対応するのは難しい ・負荷分散の要件があるか ・要求されている運用コストとの兼ね合い(サーバ台数も多くなりがち)■Pacemaker+DRBDを考える ・ダウンタイムの許容範囲 ・サービスの継続性よりデータの安全性を優先するか ・低コストを要求されているか
サーバ障害の早期発見■早期発見のために必要な要素 ・サーバの死活監視 ・サーバのリソース状況の監視(CPUやメモリ使用量等々)
・サービスの死活監視(ApacheやMySQL等ミドルウェア)
・サービスの動作状態の監視(正常な値を返すか?)
・全ての監視項目で異常が発生した場合のアラート通知
これ本当に大事です。どんなサービスを構築するにしても必ず意識してください。
サービスが落ちる前に異常を検知することが重要!
Cactiによるリソース監視◆監視できるもの・SNMP対応・CPU・メモリ・ネットワーク負荷・サービスの負荷
Nagiosによるアラート通知◆機能・死活監視・アラート通知
スクリプトによる死活監視ができるため、結構なんでも通知可能。
まとめ
・Hight Availabilityは、オープンソースでも実務レベルで構築可能 ・構築したシステムの稼働率をちゃんと把握しておくことが重要 ・KeepAlived+LVSは、止められないサービスに適している ・Pacemaker+DRBDは、データ保護に適している ・クラスタシステムに加えてCactiによるリソース監視も重要 ・異常が見られたらNagiosのような監視ソフトでアラート通知 ・自分自身の人間的な生活を維持するために真剣に考える
・サービスが落ちる前に異常を検知することが重要! (大事な事なのでもう一度言いました。)
事例紹介
人材募集
株式会社ハートビーツでは、新しいことや変化を前向きに捉え、柔軟に楽しむことができる人材を募集しています。
■弊社の良いところ・一日中PCの前に座ってるので椅子がそこそこ良い!(これ重要)
・学歴不問。意欲がある人を応援します。・いろんな先生がたくさんいます。社員教育に注力・実力がちゃんと評価されます。・いろんなものが見えます。(見たくないものも見えます)
興味がある方は後の座談会でこっそり声をかけて下さい。
Facebookページがあるので是非「いいね!」してください。更新を担当している弊社女性社員が笑顔になります。
※「○○以外はしたくない」という信念のある方は 多分辛くなると思うのでご注意ください。
ご静聴ありがとうございました。