止まらないLinuxシステムを構築する_高信頼性クラスタ入門

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

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

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

公開自己紹介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などの商用製品も複数経験

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

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

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

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

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

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

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

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

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

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

公開 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ミリ秒

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

公開信頼性、稼働率の計算は掛け算 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

公開 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ミリ秒

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

公開 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」も同時に販売開始

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

公開ミラーディスク作成

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

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

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

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

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

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

公開実例、質問など

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

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

公開参考資料 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/

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

止まらないLinuxシステムを構築する_高信頼性クラスタ入門

止まらないLinuxシステムを構築する_高信頼性クラスタ入門

More Decks by koedoyoshida

Other Decks in Technology

Featured

Transcript