Tweet
Tweet

Slide 1

Slide 1 text

公開 止まらないLinuxシステムを構築する! 高信頼性クラスタ入門 2024年4月24日 サイバートラスト株式会社 吉田

Slide 2

Slide 2 text

公開 • 自己紹介 • HAクラスタそもそも何がうれしいの？ • クラスタのパターン • サーバーの部品とSPOFについて • クラスタの種類と機能 • 実例 • Cloud対応 • Appendix Agenda

Slide 3

Slide 3 text

公開 自己紹介 サイバートラスト株式会社社員 MIRACLE LINUX Users Meetup 主催 Python Software Foundation Managing members 2021- 一般社団法人PyCon JP Association 理事

Slide 4

Slide 4 text

公開 自己紹介2 サイバートラスト MIRACLE CLUSTERPRO担当 クラスタ製品を2000年代、前職から20年以上構築/サポートなど担当 クラスタの経験 Linux/Win/UNIXのHAクラスタ,主にCLUSTERPRO、他商用、OSSクラスタ Windows NT4.0 + CLUSTERPRO 4.0頃から LinuxはMIRACLELINUX2.1+CLUSTERPRO LE/SEから OSSはHeartbeat(現Pacemaker)/DRBDあたりから HP-UXでのMC/ServiceGuardなどの商用製品も複数経験

Slide 5

Slide 5 text

公開 止まらないLinuxシステムを構築する!高信頼性 クラスタ入門 クラウド、オンプレどちらの環境でも障害は不意にやっ てきます。 そんなときもサービスを継続提供するためのHAクラス タ。 今回は高信頼性を実現するクラスタの考え方の基本から、 具体的にLinuxクラスタを設計/構築するコツについて解 説します!

Slide 6

Slide 6 text

公開 HAクラスタそもそも何がうれしいの？ • 人が見ていない夜間や休日といったときに障害が発生 しても自動復旧できる • 障害即、サービス全停止とならないようにできる • サーバで故障、障害発生でも一時的な中断だけで、 サービス継続できる • 障害から自動で復旧できる • (インフラ)エンジニア、サービス提供者が(ある程度) 安心を得ることができる これには導入するだけでは駄目、きちんと設計/構築/テ ストが必要。今日は入門編です。

Slide 7

Slide 7 text

公開 可用性、信頼性を確保するいくつかの方法 負荷分散クラスター 負荷分散クラスターはWebサーバーでよく利用され、構 成としては以下のようなものになります。

Slide 8

Slide 8 text

公開 可用性、信頼性を確保するいくつかの方法 HAクラスター HAとは『High Availablility(高可用性)』の略です。『Availability(可用性)』と はシステムが継続的に稼動できる能力のことを言いますが、HAクラスターによ りその能力を高めることができます。 HAクラスターはDBサーバーなど高信頼が必要なサーバでよく利用され、構成 としては以下のようなものになります。

Slide 9

Slide 9 text

公開 現在のサーバー利用について • クラウドが流行しています。 • でもオンプレへの回帰も始まっています。 • どちらにせよサーバは安定して動いて欲しいですよ ね？

Slide 10

Slide 10 text

公開 クラウドなら大丈夫? • クラウドなら大丈夫？そんなことはありません。 • オンプレなら安心？そんなこともありません。 • ハードウェア含め壊れるときは壊れます。

Slide 11

Slide 11 text

公開 高い可用性を持つサーバを自分たちで準備する Webサーバなどであれば、Webサーバ複数台でのロード バランシングをするのがよいです。 ただし、ロードバランサー自体がダウンすることもあり ます。 DNSロードバランシングという方法もありますが… 故障した/つながらないサーバのIPを案内されたユーザ は...

Slide 12

Slide 12 text

公開 DBなどクリティカルなサーバ HAクラスタがおすすめです。 書き込んだデータを確実に保持して欲しい 24時間365日稼働して欲しい 大災害などでも確実に稼働して欲しい(BCP/DR) といった要望に応えられます。

Slide 13

Slide 13 text

公開 可用性、信頼性を向上する方法 • HAクラスタ • ロードバランサー • マネージドサービス 社内サービスの場合にはマネージドサービスやクラウド にまかせるにはネットワーク(帯域や課金含め) 難しいことが多くあります。 HA,ロードバランサーはクラウドでも構築可能ですし、 提供されているパターンもあります。

Slide 14

Slide 14 text

公開 クラウドの信頼性 例:AWS EC2インスタンス（「シングルEC2インスタンス」）に ついて、AWSは、月次請求期間に おいて、シングル EC2インスタンスを少なくとも99.5%のインスタンスレ ベル稼働率で 利用可能にするため、商業上合理的な努力 を払うものとする https://aws.amazon.com/jp/compute/sla/

Slide 15

Slide 15 text

公開 99.5%の信頼性とは…年間で２日弱停止 稼働率と停止時間 稼働率 年間 四半期 月間 週間 24時間 90％ 36.53日 9.13日 73.05時間 16.80時間 2.40時間 95% 18.26日 4.56日 36.53時間 8.40時間 1.20時間 99% 3.65日 21.9時間 7.31時間 1.68時間 14.40分 99.5% 1.83日 10.98時間 3.65時間 50.40分 7.20分 99.9% 8.77時間 2.19時間 43.83分 10.08分 1.44分 99.95% 4.38時間 65.7分 21.92分 5.04分 3.20秒 99.99% 52.60分 13.15分 4.38分 1.01分 8.64秒 99.995% 26.30分 6.57分 2.19分 30.24秒 4.32秒 99.999% 5.26分 1.31分 26.30秒 6.05秒 864.00ミリ秒

Slide 16

Slide 16 text

公開 リージョンレベルSLA すべての稼働中のインスタンスが同一リージョン内の2 つ以上のAZ（特定のリージョン にAZが1つしかない場 合には少なくとも2つのリージョン）に同時に配備され ているAmazon EC2について、AWSは、月次請求期間 において、各AWSリージョンのAmazon EC2を少なく とも99.99%の月間稼働率で利用可能にするため、商業 上合理的な努力を払 うものとする（「リージョンレベル SLA」）。

Slide 17

Slide 17 text

公開 信頼性、稼働率の計算は掛け算 SPOFが複数ある直列パターンでは そのような部品が増えるごとに稼 働率が下がる=信頼性が落ちる それぞれの部品やサービスの信頼 性が強く要求される 並列パターンであれば、相互補完 可能などれかの部品やサービスが 動作していれば良いので、各部品 やサービスへの要求が下がって、 トータルの信頼性が向上する。 実際のシステムはこの組み合わせ サーバ稼働率の合成直列 0.99 0.99 0.99 0.99 0.99*0.99*0.99*0.99=0.96059601 サーバ稼働率の合成並列 0.99 0.99 1-(1-0.99)*(1-0.99)= 0.9999

Slide 18

Slide 18 text

公開 99.99%の信頼性とは…年間で1時間弱停止 稼働率と停止時間 稼働率 年間 四半期 月間 週間 24時間 90％ 36.53日 9.13日 73.05時間 16.80時間 2.40時間 95% 18.26日 4.56日 36.53時間 8.40時間 1.20時間 99% 3.65日 21.9時間 7.31時間 1.68時間 14.40分 99.5% 1.83日 10.98時間 3.65時間 50.40分 7.20分 99.9% 8.77時間 2.19時間 43.83分 10.08分 1.44分 99.95% 4.38時間 65.7分 21.92分 5.04分 3.20秒 99.99% 52.60分 13.15分 4.38分 1.01分 8.64秒 99.995% 26.30分 6.57分 2.19分 30.24秒 4.32秒 99.999% 5.26分 1.31分 26.30秒 6.05秒 864.00ミリ秒

Slide 19

Slide 19 text

公開 サーバーの構成要素ハードウェア サーバーを構成する要素として、CPUやメモリ、ディスクだけでなくマザー ボードや電源ユニット、冷却ファンが挙げられます。また、LANやFC(Fibre Channel)、RAID 等拡張ボードを追加していたら、それらもサーバーを構成す る要素となります。故障する頻度(耐久性)に違いはあれど『クラスタ』の考え 方では、これらすべては『いつかは故障するもの』として扱います。 ※RAIDは複数のディスクを組み合わせて耐障害性や性能を高める技術ですが、 RAIDコントローラ自体の障害を想定する必要があります。

Slide 20

Slide 20 text

公開 サーバの構成要素 ソフトウェア 次にソフトウェアの観点ではどうでしょうか。まずは OS(Operating System)自体の障害です。OSのバグ(プ ログラム的な不具合)やセキュリティの脆弱性に起因す るような障害などが考えられます。また、Webサイトの 機能を提供するようなアプリケーションについても、バ グやセキュリティの脆弱性など同様の障害は考えられま す。他にはWebサイトへの急激なアクセス増加による高 負荷状態も障害として想定しておく必要があります。

Slide 21

Slide 21 text

公開 ネットワーク 1台のサーバーに対してハードウェア、ソフトウェアそれぞれの観点でどのよ うな障害が起こりえるのか見てみましたがこれで終わりではありません。アク セスしてくるユーザーをつなぐネットワークまわりについても視野を広げる必 要があります。 まずはサーバーと繋がっているネットワーク機器やケーブルの障害です。ケー ブルの障害とは多くの場合、ケーブルの断線を意味します。また、高性能な ネットワーク機器になると専用のOSが稼働しているため、OSのバグやセキュ リティの脆弱性に起因する障害も加味する必要があります。クラウドはイン ターネット回線を提供している回線業者側のネットワーク障害も想定しておく 必要があります。

Slide 22

Slide 22 text

公開 SPOFと冗長化 『Single Point Of Failure』 日本語だと『単一障害点』と いう言い方になりますが、よ く『SPOF』なんて略称が用い られます。そもそもSPOFとは、 『障害が発生するとシステム 全体がダウンしてしまうよう な箇所』のことを言います。 ここでポイントとなるのが障 害が発生した箇所が『単一』 であることです。 この場合どこがSPOFになるで しょう？

Slide 23

Slide 23 text

公開 SPOFと冗長化 実はこの図で示されているパーツのほぼ全 てがSPOFとなっています。 HDDは複数個ありRAIDコントローラで冗 長化されているので、HDD自体はSPOFと いう扱いになりませんが、それ以外は SPOFという扱いです。「冷却ファンは2 つあるじゃないか！」とツッコミがあるか もしれませんが、「各CPUに対して冷却 ファンは1つ」であるとすれば、それは SPOFとなります。冷却ファンが故障すれ ばCPUが冷却できなくなり、CPUが熱暴走 で動かなくなってしまいます。結果として システムダウンに陥ってしまうというわけ です。

Slide 24

Slide 24 text

公開 PCサーバの冗長化の方法 パーツによって冗長化の手段が異なるのでひとつひとつ見ていきましょう。 (PCサーバーで一般的に用いられる技術を中心に解説していきます。) CPU ： マザーボードとOSが対応していれば、障害が発生したCPUを切り離し、 残ったCPUでOSの稼働を継続させることができます。ただ、最近のPCサー バーでは対応していないものも多いようです。 メモリ ： メモリミラーリング機能を搭載しているマザーボードであれば、複 数のメモリで冗長化が可能です。ただし、OSから認識できる容量はメモリの搭 載容量の半分になります。 HDD ： 複数のHDDでRAID(ミラーリングなど) を構成することで冗長化が可 能です。一般的にはRAIDコントローラに複数のHDDを接続し、RAIDを構成し ます。 RAID0(ストライピング)は信頼性が下がりますので冗長性の面からはお勧めし ません。サーバではRAID5,RAID1での運用が多いです。 ソフトウェアRAIDは安価ですが、Linuxでは冗長化上も扱いが難しいことが多 く、復旧も簡単なハードウェアRAIDをお勧めします。

Slide 25

Slide 25 text

公開 PCサーバの冗長化の方法 拡張ボード(LAN/FC) ： 複数のインターフェースを束ねて仮想的に1つものと して扱う技術 ※ があります。複数の拡張ボードを用意し、各ボードのイン ターフェースを束ねることでボード障害に対応することができます。 ※LANの場合、チーミングやボンディングと言います。またFCに関してはマル チパスI/Oやデバイスマッパーマルチパスと言います。この辺りはOS文化の違 いでしょうが、細かい解説は割愛します。 電源ユニット ： 電源ユニットを複数搭載することで冗長化することができま す。 DCに設置し、別々の２系統から電源を取るのがおすすめです。 オフィスビルなどの場合、これにUPS(無停電電源装置)をプラスして停電対策 を行っていることが多いです。一時的な停電や瞬断の対策としてUPSは非常に 効果的です。 冷却ファン ： 風の流れる方向に2つの冷却ファンを配置することで冗長化でき ます。片方が止まっても、もう片方のファンで風を届けることができます。

Slide 26

Slide 26 text

公開 SPOFを無くすには？ 実はまだ冗長化できていないコンポーネン ト(SPOF となっている箇所)があります。 マザーボードやRAIDコントローラ、それに OSです。ここまでくると1台のサーバーで は解決できません。 OS上で動くアプリケーションに関しては各 アプリケーションの仕様に依存しますが、1 つのOS内でアプリケーションそのものが冗 長化されていることはほとんどありません ので、OSやその上で動くものは全て冗長化 できないものとして扱います。 マザーボードを含めほぼ全てのコンポーネ ントを冗長化したフォールトトレラント サーバというものがありますが、やはりOS 部分はSPOFとなってしまいます。

Slide 27

Slide 27 text

公開 ソフトウェア的な問題 SPOF • アプリケーションの問題(segfault) • Busyやポートあふれ等で、サービス接続できない • プロセス/サーバ応答が極端に遅くなる、停止する • OS(PANIC)

Slide 28

Slide 28 text

公開 どんな障害点があるか？ クラスタシステムでは構成や考慮する深さにも寄ります が20～30弱程度考える必要がある障害点があります。

Slide 29

Slide 29 text

公開 障害箇所例 共有ディスクコントローラ 故障:一部/全部 FC-SW故障:一部/全部 SCSI/FCバス:断線 FCHBA:故障 インタコネクトLAN パブリックLAN 電源ユニット:故障 商用電源:系統故障 本体UPS アレイ(共有ディスク)UPS UPS用LAN CPU故障:一部/全部 メモリ故障:一部/全部 ローカルディスク:一部障 害、ディスクフルなど RAIDコントローラ障害 NIC障害 OS:サービスの動作異常／ 停止、ユーザ空間のストー ル、PANIC発生 AP:プロセス消失、機能停 止、スローダウン GPU／ディスプレイ

Slide 30

Slide 30 text

公開 障害点への対応 障害点とその対応を全部紹介していくと時間が足りない ので、よくあるポイントを紹介 まず基本として先ほども挙げた電源やRAID: 単体サーバの可用性向上としても効果的、クラスタでも もちろんやった方がベター

Slide 31

Slide 31 text

公開 冗長電源 電源障害対策、2系統から電源が取れる。だいたい中級 以上のサーバだと選べます。 意外と忘れがちなのとして商用電源 UPS無しだと商用電源が落ちたら即座に全部落ちます 自前UPSという手もありますが、2系統取れるDC等に置 きましょう。 自社サーバルームとかだと年一度の法定点検でサーバ停 止とかもよくありますね。

Slide 32

Slide 32 text

公開 RAID RAID1(ミラーリング)やRAID5を採用することが多い RAID0(ストライピング)は性能は出ますが、耐障害性は 単体より悪化するので避けましょう。 (ゲームマシンとかで性能を追求ならあり、でもサーバ 向きでは無い) RAID10:ストライピング+ミラーリング。性能と耐障害 性を両立、お金あるならこれ（容量コストは…）。 最近だとサーバでもSSDも選べる。SSDでRAID10まで 必要？

Slide 33

Slide 33 text

公開 クラスタソフトウェアを入れるだけで対応回避 できる障害 サーバの単体故障 HDD,LAN,マザーボード、メモリ、CPU、サーバ 電源、OS Panicなど 逆に言えばLANやシステムディスク,電源の耐障害性は ここで割り切る手もある。 RAIDは有った方がいい。バックアップから再構築 は手間と時間 (ansibleやkickstartなどで自動化して割り切る手 もある)

Slide 34

Slide 34 text

公開 クラスタソフトウェアを導入すればあとはOK? 実はそうではありません！ • 構成を注意して組まないとSPOFは発生します。 • その部品、部分が壊れたらサービス、業務が停止して しまいます！

Slide 35

Slide 35 text

公開 共有ディスクのRAIDコントローラ 共有ディスクのRAIDコントローラが一つしかないので それが故障で業務/サービス停止 このパターンはよくあるので、安い共有ストレージは要 注意 共有Storageへのアクセスに使用するSANスイッチが1 台しかないこともこれが壊れたら… クラスタ用の共有ディスク装置はRAIDコントローラ2 系統あるものを強く推奨 ミラーディスク構成(後述)で対応する方法もある

Slide 36

Slide 36 text

公開 スイッチングHUBが冗長化されていない 冗長できるスイッチングハブはお高い 特にオンプレの場合は、予算に余裕が無くても NIC2portは準備 サービス用のネットワーク（ハートビートネットワーク 兼用）とは別にミラーディスクコネクト用やメンテナン ス用別ネットワーク（二系統目のハートビート）を組ん でそこからもアクセス出来るようにしておくのがおすす め サービス用ネットワークが落ちても別系統で状態確認や クラスタの通信ができます

Slide 37

Slide 37 text

公開 ルータが一つしかない これもスイッチと同様。 特にDR構成を組む場合はインターコネクト用に別ネッ トワークを組んで そちら経由でもサーバ間が通信できるようにしておくの を強くおすすめします。 DRでなければ、クライアントへの通信は最悪落ちても 問題は無いですが、 ネットワーク健全性(NP解決)をルータへのping監視など で一つだけ対象にしているとルータメンテナンスで (ルータ側で冗長されておらず、SPOFとなっていた場 合)サーバダウンとなることがあります。

Slide 38

Slide 38 text

公開 具体的なクラスタソフトウェア Linuxで使用できるクラスタソフトウェアはいろいろあ ります。 OSSの例 Corosync / Pacemaker / DRBD Corosyncは、クラスタ管理プログラムであり、定期的 にハートビート通信を送信することによって、クラスタ を構成するマシンの稼働状態を監視します。 Pacemakerは、リソース管理プログラムであり、障害発 生を検知することによって、管理するサービスを待機系 のマシンへフェイルオーバします。 CorosyncとPacemakerを組合せることで、Linux上で、 HAクラスタを実現する事が可能です。 DRBDは、ストレージをネットワーク経由でミラーリン グするソフトウェアです。

Slide 39

Slide 39 text

公開 商用クラスタ製品の例 MIRACLE CLUSTERPRO 共有ディスク構成、ミラーディスク構成両方に対応 AWSなどクラウド構成にも対応！ https://www.cybertrust.co.jp/clp/

Slide 40

Slide 40 text

公開 MIRACLE CLUSTERPRO X Linux OS「MIRACLE LINUX 9.2」および「AlmaLinux 9.2」に対応した高可 用性クラスタリングソフトウェアの最新版「MIRACLE CLUSTERPRO X （ミ ラクル クラスタープロ エックス） 5.1」を、2024 年 3 月 6 日より販売開始 します。また、シングルサーバーの可用性向上を実現する「MIRACLE LINUX HA」の最新版および AlmaLinux OS（以下、AlmaLinux）の日本語による技 術サポートを提供する OS サポートをバンドルした「MIRACLE CLUSTERPRO X 5.1 for AlmaLinux」、「MIRACLE HA for AlmaLinux」 も同時に販売開始

Slide 41

Slide 41 text

公開 クラスタの基本解説 CLUSTERPROをベースに話しますが、他のクラスタソ フトウェアでもある程度同様に考えることができます。

Slide 42

Slide 42 text

公開 HAクラスターの構成 HAクラスターの構成は主に、共有ディスク型とミラー ディスク型の2種類です。 組み合わせたハイブリッドディスク型というのもありま す。 それぞれに利点(と引き換えのコスト)があります。

Slide 43

Slide 43 text

公開 ミラーディスク型 業務データを2台のサーバーのディスク間でミラーリングするこ とで、フェールオーバー後も同一データにアクセスできるように する方式です。ミラーリングとは、稼働系でデータの書き込み要 求が発生した場合に、ローカルディスクにデータを書き込むと同 時にネットワークを介して待機系のローカルディスクにデータを 書き込む機能 主な利点:比較的低コスト、部品が少ないので、設計も比較的楽。

Slide 44

Slide 44 text

公開 共有ディスク型 HAクラスターを構築するサーバーから物理的に接続さ れた共有ディスクにデータを格納することで、フェール オーバー後も同一データにアクセスできるようにする方 式です。一方のサーバーが共有ディスクの特定領域を利 用している場合、もう一方からはアクセスできません。 利点:データ書き込みにおける性能劣化が無いため、 データベースサーバー等、データ書き込み量が多いシス テムで良く利用されています。

Slide 45

Slide 45 text

公開 ハイブリッドディスク型 共有ディスク型とミラーディスク型を組み合わせた、遠隔クラスターに最適な 構成です。メインサイトでは共有ディスク型クラスターのように振る舞うため、 メインサイト内の局所的な障害(アプリケーション障害/IaaS障害等)はサイト内 でフェールオーバーすることで業務継続が可能です。 サイト間ではCLUSTERPROのミラーリング機能により共有ディスクのデータ をミラーリング可能なため、メインサイトの全てのサーバーがダウンしたとき にバックアップサイトにフェールオーバーすることで、最新データをもとに業 務の継続が可能です。また、バックアップサイトは、メインサイトと同様に共 有ディスク型クラスター構成をとることも、共有ディスクを使用せずにサー バー1台の構成で、内蔵ディスクへミラーリングする構成をとることも可能で す。

Slide 46

Slide 46 text

公開 ミラーディスクのモード:同期ミラーリング ・同期モード:リアルタイムでミラーリングするモードです。 同期モードでは、業務アプリケーションなどからの書き込み要求に対し て、現用系/待機系サーバーの両方のローカルディスクに書き込みが完了 した後に完了通知を戻します。そのため、クラスターサーバー間のデー タは完全に一致することが保証されます。 ・OSのWrite命令はミラーディスクドライバ(ミラーコネクト)経由で ネットワーク経由での待機系の書き込みが正常終了すると戻る。 ・もちろん稼働系の書き込みも並列で 実施、両方正常終了でWrite命令終了

Slide 47

Slide 47 text

公開 ミラーディスクのモード:非同期ミラーリング ・非同期モード:ベストエフォートでミラーリングするモードです。 業務アプリケーションなどからの書き込み要求に対して、現用系サー バーのローカルディスク書き込みと、待機系サーバーへの転送データの 蓄積が完了したタイミングで完了通知を戻します。ネットワーク速度が 遅い場合も同期待ちによる書き込み性能低下が発生しません。 ただし、待機系サーバーへのデータ転送が完了していない状態で、現用 系サーバーが電源断などにより異常停止した場合、一時的な領域に蓄積 したデータが失われることがあります。

Slide 48

Slide 48 text

公開 実際に構築してみる MIRACLELINUX 9.2とMIRACLE CLUSTERPRO X ミラーディスク構成 ・ハードウェア:2式 NIC２系統 システムディスクとミラー用ディスク ・OSインストール https://www.miraclelinux.com/distribution/download システムディスクに最小限のインストール 各NIC(計4)に固定IPアドレスを振る ・OSインストール後疎通確認

Slide 49

Slide 49 text

公開 OSインストール 今回の例ではMIRACLE LINUX9.2をインストール

Slide 50

Slide 50 text

公開 NIC/ネットワーク２系統/疎通確認

Slide 51

Slide 51 text

公開 クラスタ構築 • MIRACLE CLUSTERPRO 評価版申し込み • https://www.cybertrust.co.jp/linux-oss/evaluation/ • 手順に沿ってインストール/構築 • https://www.miraclelinux.com/support/mcpx5 • インストール • ライセンス登録 • SELinuxの設定 • (SNMP設定) • OSファイアウォールの設定 • WebUIからクラスタ構築を実施

Slide 52

Slide 52 text

公開 WebUI Cluster WebUI には、 http://<インストールしたサーバーの IP アドレス>>:29003/ からアクセス

Slide 53

Slide 53 text

公開 インタコネクト(2系統のハートビート)を設定 (ミラーディスクを使用するためのMDC設定) ネットワークは１系統でも構築はできますが…

Slide 54

Slide 54 text

公開 (NP解決などの設定) NP(ネットワークパーティション)解決:ルータなど常時疎通可能なIPを(複数)指定 (ルータがSPOFにならないように注意):無指定や他の方法でも構築可能

Slide 55

Slide 55 text

公開 グループ/モニタ この後設定でもOK

Slide 56

Slide 56 text

公開 モニタリソース HAクラスターの保護対象となる業務が健全に実行できているかを監視します。 監視対象の異常を検出した場合には、業務を継続するために必要な回復動作を 行います(グループリソースの再起動やフェールオーバーなど) 。 モニタリソースの監視対象には、グループリソース(アプリケーションやフロー ティングIPアドレスなど)に加えて、業務の実行や業務へのアクセスに必要とな る資源(ネットワークやOSなど)を指定することができます。 モニタリソースによっては、待機系サーバーでも監視を行っており、待機系 サーバーの異常を検出し通報します。これによって、待機系サーバーで業務が 起動・実行できる状態であるかを監視できます。

Slide 57

Slide 57 text

公開 ハートビート HAクラスターの基本的な機能の一つに、クラスター内の他のサーバーの死活監 視があります。HAクラスターにおいて相手サーバーの死活監視を行う仕組みの ことをハートビートと呼びます。 サーバーの電源断などによってハートビートが遮断された場合には、フェール オーバーなどの回復動作を行います。 ハートビートの経路には、ネットワークのほかに共有ディスクなどを利用する ことができます。ネットワーク以外の経路を組合わせて複数のハートビートを 構成することによって、個々の資源の障害の影響を受けにくくなり、より障害 に強いHAクラスターにすることができます。

Slide 58

Slide 58 text

公開 ネットワークパーティション ネットワークパーティションは、クラスターサーバー間の全ての通信路に障害 が発生し、クラスターサーバーがネットワーク的に分断されてしまう状態のこ とです。ネットワークパーティションのことを「スプリットブレイン」と呼ぶ 場合もあります。 ネットワークパーティションに対応できていないHAクラスターでは、通信路の 障害とサーバーの障害を区別できず、共有ディスクなどの同一資源に複数の サーバーからアクセスしてデータ破壊を引き起こす場合があります。

Slide 59

Slide 59 text

公開 NP(ネットワークパーティション)解決 ネットワークパーティションの対策としては、「ハートビート」の欄で述べた 複数種類のハートビートの使用によってネットワークパーティションが発生し にくい環境にすることが大切です。それでもネットワークパーティションが発 生した場合の対策としてネットワークパーティション(NP)解決を設定すること が可能です。 例えば、PING方式によるネットワークパーティション解決では、ネットワーク パーティションであるかを判別するとき、各サーバーがクライアントからのア クセス経路にあるネットワーク装置と疎通確認を行います。 疎通可能なサーバーは、自分が業務継続するべきサーバー＝現用系と判断して フェールオーバーを行います。一方で疎通不可なサーバーは、自分がネット ワーク的に分断されたと判断してシャットダウンします。これによって共有 データの破壊を防止します。

Slide 60

Slide 60 text

公開 クラスタ構成情報チェック

Slide 61

Slide 61 text

公開 クラスタ開始(最小初期状態)

Slide 62

Slide 62 text

公開 フェイルオーバーグループ作成

Slide 63

Slide 63 text

公開 フェールオーバーグループ フェールオーバーグループは、HAクラスター内のある一つの独立した業務を実 行するために必要な資源の集まりのことで、フェールオーバーを行う単位にな ります。 業務を実行するために必要な資源をまとめることによって、HAクラスターの設 定や運用が容易になります。業務の起動・停止、フェールオーバーなどを一連 の操作として扱えるようになります。 HAクラスターは、フェールオーバーグループおよびグループリソースが現用系 サーバーで起動している状態を維持するために必要な制御を行います。これに よって、クライアントから見たときに、宛先やデータが変わることなく業務に アクセスすることができます。

Slide 64

Slide 64 text

公開 クラスタに対応するようにリソースの起動/停止 ﾊｰﾄﾋﾞｰﾄ ②アプリケーション停止 ③フローティングIPアドレス無効化 ④ミラー/共有ディスク切離 ⑤ミラー/共有ディスク接続 ⑥フローティングIPアドレス有効化 ⑦アプリケーション開始 ①障害検出 待機系 現用系 クラスタソフト クラスタソフト 引き継ぐ業務(リソース) ✓アプリケーション ✓フローティングIPアドレス ✓パーティション（データ）

Slide 65

Slide 65 text

公開 ミラーディスク(または共有ディスク)準備 ◼ ミラーディスク:クラスタパーティションは1024MB 必要 Diskを確保しパーティションで分割

Slide 66

Slide 66 text

公開 ミラーディスク作成

Slide 67

Slide 67 text

公開 フローティングIPリソースとexecリソース作成

Slide 68

Slide 68 text

公開 クラスタ起動 ここまでの設定が成功すれば、 最低限のクラスタとしての構成が完成

Slide 69

Slide 69 text

公開 クラスタソフトウェアを入れた上で考慮しなけ ればならない障害を検知するモニタを作成 ・AP障害対応/AP監視 クラスタソフトウェアのオプションがあればそれを利用 するのがお勧め DB監視など シェルスクリプトなどで自作することも可能 対象AP向けの最低限のプログラムスキルが必要

Slide 70

Slide 70 text

公開 信頼性向上のため、チューニング ・execリソースの改善 特に一定時間で終了するようにするのが大切 ・モニタ(監視/自動復旧設定) 同じサーバで何回再起動するか別サーバへフェイルオー バーか、組み合わせか、なにもしない(監視だけ)か ・各モニタの監視機能調整 どの深さまで監視するか 例えばOSハングアップ監視など パフォーマンスとのトレードオフ ・NP解決やハートビートの冗長化 ルータがSPOFになることも(NP解決/PING監視は複数で) 複数ネットワークでサーバ間通信(特にDR)

Slide 71

Slide 71 text

公開 OSSの組み合わせとCLUSTERPROなどの商用 製品の場合何が違うのなにがメリットなのか？ 機能面や一般的な使い勝手の面はやはり商用製品が強い わかりやすいWebなどの設定UIや表示など ハイブリッドディスクなど高度な機能もある DB監視などよく必要とされる機能 MySQL, PostgreSQL, 商用DB用の監視機能 Webサービスの監視機能 サーバ自己監視機能 hangup監視、IO監視など ミラーディスク機能やハイブリッドディスクもある 商用サポートで構築時やフェイルオーバー発生時含めた 調査も安心できる

Slide 72

Slide 72 text

公開 クラウドでの例 AWSにおけるHAクラスター構成 https://jpn.nec.com/clusterpro/blog/20200929.ht ml

Slide 73

Slide 73 text

公開 実例、質問など

Slide 74

Slide 74 text

公開 MIRACLE CLUSTERPRO X システムの障害を監視し、障害発生時には健全なサーバーに業務を引き継ぎ、 高可用性を実現する日本電気株式会社（以下、NEC）製の HA クラスタリング ソフトウェア「CLUSTERPRO X」とサイバートラストの Linux OS 「MIRACLE LINUX」を組み合わせたパッケージ製品です。「CLUSTERPRO」 は、21 年連続国内シェア No.1 の実績を誇り ※1 、Windows および Linux のどちらの OS でも動作し、OSS をはじめとしたさまざまなアプリケーション のクラスター化による可用性の向上を実現します。

Slide 75

Slide 75 text

公開 MIRACLE HA MIRACLE CLUSTERPROの姉妹製品 自動障害復帰機能を備え、障害を検知すると OS 再起動・アプリケーション再 起動をして、シングルサーバーの業務サービスを復帰させる、廉価 HA ソ リューション製品です。障害、メンテナンスによるサービス停止時間を最低限 に抑え、ビジネス継続性を高める仕組みを多数取り込んでいます。 クラウド基盤/仮想化基盤において、MIRACLE LINUX HA / MIRACLE HA for AlmaLinux を利用することで、クラウド基盤/仮想基盤の HA 機能で検知しな いソフトウェア障害を回避することが可能です。

Slide 76

Slide 76 text

公開 参考資料 HAクラスター入門 https://jpn.nec.com/clusterpro/blog_introduction.h tml MIRACLE CLUSTERPRO X5 技術情報 https://www.miraclelinux.com/support/mcpx5 MIRACLE CLUSTERPRO X https://www.cybertrust.co.jp/clp/ MIRACLE LINUX HA / MIRACLE HA for AlmaLinux https://www.cybertrust.co.jp/miracle-linux/ha/

Slide 77

Slide 77 text

公開 信頼とともに 留意事項 本資料に記載されている会社名、製品名、サービス名は、当社または各社、各団体の商標もしくは登録商標です。 その他本資料に記載されているイラスト・ロゴ・写真・動画・ソフトウェア等は、当社または第三者が有する知的財産権やその 他の権利により守られております。 お客様は、当社が著作権を有するコンテンツについて、特に定めた場合を除き、複製、改変、頒布などをすることはできません。 本資料に記載されている情報は予告なしに変更されることがあります。また、時間の経過などにより記載内容が不正確となる場 合がありますが、当社は、当該情報を更新する義務を負うものではありません。