これから求められるサーバ構築
オープンソースでハイアベイラビリティ!
   ~クラスタ管理の設計構築ハウツー&エンジニア思考力~
PROFILE

      岩崎 のぼる               Noboru Iwasaki


 年齢   35歳(いつのまにか…)
 職業   株式会社ハートビーツ MSP事業部
      運用エンジニア


 活動   Linux-HA Japan Project
      日本Unboundユーザ会
      執筆活動
      Etc...
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によるデータのリアルタイムレプリケーション
      (+遠隔地へのデータレプリケーション可能)
止められないサーバのクラスタ構築
              障害が起きても止まらない構成を考える


                               network          DNSラウンドロビン


                               仮想IP振り分け

   負荷分散クラスタ   KeepAlived+LVS              KeepAlived+LVS




    Web               Web                   Web              Web


                  DB(更新+参照)               DB(参照)
止められないサーバのクラスタ構築
     KeepAlived+LVSを用いたクラスタ構成の特徴
■機能
 ・サービスのヘルスチェック機能(シェルスクリプト)
 ・仮想IPアドレスの制御
 ・複数あるサーバへのラウンドロビン(負荷分散機能)


■特徴
 ・障害発生時ダウンタイムが極めて少ない
 ・適用できる構成に制限がある(後述)
 ・サーバ構成が複雑になりがちで、運用コストが高い傾向がある
止められるサーバのクラスタ構築
           障害が起きた際の挙動を考える

                     network
      アクティブサーバ                        スタンバイサーバ


          仮想IP                          仮想IP

         Pacemaker              Pacemaker

            Web                       Web

            DB                        DB

                 DRBDによるリアルタイムデータ同期
こんな構成もあります。
       1:nのフェイルオーバークラスタも視野に入れる
      サーバA                    サーバB                   サーバC

     Pacemaker               Pacemaker             Pacemaker

     Webサーバ                  Webサーバ                Webサーバ

     DBサーバ                   DBサーバ                 DBサーバ

      Postfix                 Postfix                Postfix




                 Pacemaker               Pacemaker

                   iSCSI                   iSCSI

                 ストレージ                   ストレージ


                      DRBDによるリアルタイムデータ同期
止められるサーバのクラスタ構築
      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のような監視ソフトでアラート通知
 ・自分自身の人間的な生活を維持するために真剣に考える


 ・サービスが落ちる前に異常を検知することが重要!
   (大事な事なのでもう一度言いました。)
事例紹介
人材募集




株式会社ハートビーツでは、新しいことや変化を前向きに捉え、柔軟に楽しむこと
ができる人材を募集しています。

■弊社の良いところ                          Facebookページがあるので
・一日中PCの前に座ってるので椅子がそこそこ良い!(これ重要)   是非「いいね!」してください。
・学歴不問。意欲がある人を応援します。                更新を担当している弊社女性社員が笑顔になります。
・いろんな先生がたくさんいます。社員教育に注力
・実力がちゃんと評価されます。
・いろんなものが見えます。(見たくないものも見えます)       ※「○○以外はしたくない」という信念のある方は
                                    多分辛くなると思うのでご注意ください。

興味がある方は後の座談会でこっそり声をかけて下さい。
ご静聴ありがとうございました。

20121115 オープンソースでハイアベイラビリティ! ~クラスタ管理の設計構築ハウツー&エンジニア思考力~