こんにちは、サイオステクノロジー プロダクト開発部 宇野です。
最近のLifeKeeper for Linuxでは、ほとんどの共有ストレージをサポート可能とすることを目標に掲げて、プランニングし開発計画を進めています。
LifeKeeper for Linuxは共有ストレージに対してSCSI Reservation（スカジーリザベーション）を標準IO Fencing（アイオーフェンシング）機能として採用してきました。
しかし、SCSI Reservationはストレージの種類によっては、期待した通りの動作とならないといったケースがあります。そのためそれぞれのストレージとLifeKeeperの組み合わせでテストを行い、正常に動作することが確認できたもののみを「認定済みストレージ」としてサポートしてまいりました。
ただし、私達としても市場に存在する全てのストレージをテストすることはできず、結果的に動作確認が行われていないストレージ(未サポートストレージ)が存在してしまいます。
そのため、ストレージの機能に依存しない、どのようなストレージであってもサポート可能なIO Fencing機能の導入を目指しています。
この計画を私たちは“Any Storage”と呼んでいます。本記事では、これまでのフェンシング機能の紹介と、今後のストレージを使用したIO Fencingの展望についてご紹介いたします。
LifeKeeper標準IO Fencing機能“SCSI Reservation”について
まずは既存のLifeKeeper for LinuxのIO Fencingについて紹介します。LifeKeeper for Linuxは非常に古くからSCSI ReservationによるIO Fencingを行っていることが知られています。リリース当初から利用されていますので、20年以上の動作実績があります。
SCSI Reservationの最大の特徴は、SCSIコマンドによるReserve（予約）機能です。LifeKeeperではアクティブノード側でSCSI コマンドによって共有ディスクをReserveし、他のノードからのアクセスを制限します。コミュニケーションパスの全断など通信障害が発生した場合は、両ノードでReserveをして先にReserveしたノードがアクティブノードとなり、他のノードは強制再起動する排他制御を行います。これらの機能はSCSIコマンドを使用したLow Levelでの制御となりますので、高い堅牢性を保つことが可能です。以下の項目では、実際の具体的なSCSI Reservation処理について紹介します。
LifeKeeper for Linuxでは、クラスターノード間でデータを共有するために、以下のように各ノードから接続できる共有ディスクを利用します。その際、スタンバイ側からのアクセスによるデータ破損を避けるために、以下のようにアクティブノードからSCSIコマンドを使用して、利用するLU（Logical Unit ＝ 論理ユニット）をReserveします。
上記のようにアクティブノードからReserveすることでスタンバイノードからのアクセスをブロックすることが可能となります。Linuxが標準で使用するファイルシステム(ext2,ext3,ext4,xfs)はクラスタファイルシステムではないため、クラスターノードからの両系同時アクセスをサポートしていません。サポートしていないファイルシステムでの同時アクセスを行うと、データの整合性が取れずにデータ破壊につながります。そのためLifeKeeper for Linuxでは、上記のような仕組みを使用して、同時アクセスできない仕組みを取り入れています。
ただしLifeKeeper for Linuxはクラスターシステムなので、ノード間のコミュニケーションが行えなくなり（コミュニケーションパスの全断）スプリットブレイン（両ノードでのリソース起動）を引き起こすような挙動となります。SCSI Reservationはこのように危険な状況とならないよう、以下のような挙動を行い、両ノードの起動による同時アクセスが発生しない対策を行っています。
参考：Blog記事【スプリットブレイン対策！新機能Storage Quorum/Witness のメリット】https://bcblog.sios.jp/storage-quorum/
Reservation Conflictが発生してから強制シャットダウンの処理は同時アクセスを防ぐため即座に行われます。特にログの書き込みを保証する挙動も行わないため、一連の挙動についてログへの出力が発生しないこともあります。
このようにLifeKeeper for LinuxではSCSI ReservationによるIO Fencingを行いますが、SCSI コマンドによるReserve 処理はストレージによって利用できない場合があります。そのため、LifeKeeper for Linuxではサポート済みストレージ情報をWebにて公開しています。ストレージを選択する場合は以下のページからサポート情報があるかどうか確認してからご利用ください。
http://jpdocs.us.sios.com/alllinux.php（最新の「サポートストレージ一覧」をご確認ください）
SCSI Reservation のデメリット
LifeKeeper の標準IO Fencing機能は、上記のような挙動を長年にわたり採用しており、とても堅牢な機能として認識いただいていますが、序盤で述べたように全てのストレージで利用できる機能という保証がありません。新機能の採用が目覚ましいストレージ業界から新しいストレージが発表される毎に、SCSI Reservationが利用可能かどうか確認する必要がありました。
そのため近年では、ストレージに依存しないIO Fencingをサポートすることで、リリースしたばかりのストレージであってもすぐに利用できるよう機能の追加をしてきました。以下からは、ストレージに依存しないIO Fencing機能”Quorum/Witness（クォーラム/ウィットネス）”について紹介します。
Quorum/Witness によるIO Fencing
Quorum/Witnessの採用
SCSI Reservation のデメリットであったストレージ依存からの脱却を目的に、ストレージに依存しないIO FencingとしてSCSI Reservationの次に開発がすすめられたのがQuorum/Witness機能です。2011年にリリースしてから9年目となります。
Quorum/WitnessはそれぞれQuorumチェックとWitnessチェックを行うことで、ノードの正常性の確認を行います。Quorumチェックでは自ノードが正常なのか（リソースを稼働しても良いか）どうかの判定を行います。Witnessチェックでは疎通確認が行えなくなった対象ノードの正常性を確認することで、自ノードでリソースを起動して良いのかのセカンドオピニオンとします。Quorum/Witnessには、2018年に新たに加わったStorage modeを含め、現在3種類のモードがあります。
・Majority mode
・TCP remote mode
・Storage mode
Quorum/Witnessについては以下のマニュアルから詳細を確認いただけます。
【Quorum/Witness】http://jpdocs.us.sios.com/Linux/9.3.2/LK4L/TechDoc/index.htm#configuration/lifekeeper_io_fencing/quorum_witness.htm
採用をお勧めしているMajority modeとStorage modeについてそれぞれ紹介します。
Majority mode
Majority modeは、障害発生時にコミュニケーションパスを通じて疎通確認を行い、Quorum チェックを行うモードです。Majority modeはストレージに対するReserve処理は行いませんので、SCSI Reservationが利用できないストレージ向けのIO Fencing機能として利用できます。ただしMajority modeは3台以上のノードを必要とするため、2ノードクラスターの場合Witness Serverが必要となります。
実際の障害が発生した際には、全ノードがQuorumチェックで過半数の確認が取れない場合はQuorumチェックに失敗したと判定されて、初期設定（QUORUM_LOSS_ACTION=fastkill）に従いノードの強制シャットダウンが発生します。
Quorumチェックの後はセカンドオピニオンとして、Witness Serverを経由して通信が取れなくなった対象ノードのステータスを確認します（Witnessチェック）。通信の出来なくなった対象ノードが正常に稼働していることを確認した場合フェイルオーバーは行われません。対象ノードの正常起動が確認できなかった場合は、フェイルオーバーしてサービスの再開を試みます。
以下から、各障害での挙動についてケース毎に紹介します。
ケース1はノード間のコミュニケーションが全断した場合の挙動です。相互のノードで疎通確認を行い、各自のノードの正常性を確認します。その後相手ノードの正常性を確認して、相互に安全性が確認できたため、リソースの切り替えは抑止されます。
ケース2は、アクティブノードで障害が発生した場合の挙動です。Quorum/Witness チェックはスタンバイノード側でのみ行われます。Witnessチェックで相手ノードの正常性が確認できないため、スタンバイノードがサービスを再開させるためリソースを起動させます。
ケース3はアクティブノードのネットワークが全断した場合の挙動です。Quorumチェックが取れなかったアクティブノードは初期設定に従い（QUORUM_LOSS_ACTION=fastkill）自ノードを強制シャットダウンします。スタンバイノードではWitnessチェックで正常性を確認できず、フェイルオーバーを開始します。
Storage mode
Storage modeは2ノードでもQuorum/Witnessが利用できるよう2018年にリリースされた3番目のQuorum/Witnessのモードとなります。Majority modeと同様に、SCSI Reservationがサポートされていないストレージを利用する場合の代替えIO Fencing機能として利用可能です。
自ノードの正常性確認はノード毎の共有ストレージ（Quorumデバイス）に正常であればQuorumチェックに成功したと判定してそのまま稼働します。正常でないと判定した場合は、Quorumチェックに失敗したと判定されて、初期設定に従い（QUORUM_LOSS_ACTION=fastkill）強制シャットダウンが発生します。Witnessチェックでは通信の出来なくなった対象ノードが正常に稼働していることを確認します。対象ノードのQuorumデバイスへのデータ更新が定期的に実施されているかどうかで正常性の確認をします。更新されていることを確認出来たら対象ノードが正常と判定されリソースの切り替えは行われません。更新が確認できない場合は対象ノードが異常と判断されフェイルオーバーが発生します。
以下から各障害での挙動についてケース毎に紹介します。
ケース1はノード間のコミュニケーションが全断した場合の挙動です。相互のノードでQuorumチェックを行い各自のノードの正常性を確認します。その後対象ノードの正常性を確認して、相互に安全性が確認できたため、リソースの切り替えは抑止されます。
ケース2は、アクティブノードで障害が発生した場合の挙動です。Quorum/Witness チェックはスタンバイノード側でのみ行われます。WitnessチェックでアクティブノードのQuorumへの更新が確認できず、相手ノードが正常とは判定できないため、スタンバイノードがサービスを起動します。
ケース３はアクティブノードのネットワークが全断した場合の挙動です。Storage modeは共有ストレージとして、共有ディスデバイスの他に、NFS ServerやAmazon S3もQuorumデバイスとして利用可能です。Quorumデバイスへの接続がネットワーク経由で行うことを前提としたケースが対象となります。ネットワーク障害によりQuorumチェックが取れなかったアクティブノードは初期設定に従い（QUORUM_LOSS_ACTION=fastkill）自ノードを強制シャットダウンします。スタンバイノードではWitnessチェックで正常性を確認できず、フェイルオーバーを開始します。
Quorum/Witnessのデメリット
上記で紹介したQuorum/WitnessはAny Storageで利用可能なIO Fencing機能といえますが、これらの機能はSCSI Reservationのように共有ディスクに対してロック処理を行うような挙動は行いません。そのためユーザーは、スタンバイノードから共有ディスクへのアクセスが行えてしまいます。SCSI Reservationと比較してもQuorum/Witnessはデータ保護という観点で不安が残ります。そのため、次の計画ではストレージに依存せずに、スタンバイノードからのアクセスも制限する機能を考えることとなりました。
LifeKeeper for Linux v9.4.0でのIO Fencing新機能
さてここでは、直前で予告したように、ストレージに依存せずにスタンバイノードからのアクセスも制限する新しいIO Fencing機能を紹介したいと思います。
現在VMware vSphere （ヴイエムウェアブイスフィア）で利用可能なVMDKによる共有ディスクを対象としたIO Fencibg機能 “VMDK 共有ストレージ” の開発が進められています。次期リリースを予定しているLifeKeeper for Linux v9.4.0での機能追加に向けて日々テストを繰り返しているところです。VMDK 共有ストレージ機能は、SCSI Reservationと同様にアクティブノード以外からのアクセスを制限する機能を設ける仕様となる予定です。
Quorum/Witness によるIO Fencing機能はアクティブノードがマウントした状態でスタンバイノードから共有ディスクへのアクセス（手動でのマウント）を行おうとしたとき、アクセスが出来てしまいます。これは各機能別に紹介したような挙動以外の想定外の状態に陥った場合に、両系からのマウントが発生し、データ破損を引き起こす可能性が残されていることを示しています。しかし次期リリース予定のVMDK 共有ストレージ機能では、スタンバイノードからのアクセスも制限可能な SCSI Reservationにも匹敵する堅牢なIO Fencing機能を持ち合わせています。
上記の表にあるように、新しいVMDK 共有ストレージは、SCSI ReservationやQuorum/Witness でデメリットとなっていたポイントをカバーできるように構成されています。VMDKなのでvSphere環境限定の機能となりますが、SCSI Reservationと同等の堅牢性を保ちながら、ストレージへの汎用性も高いといえます。
VMDK 共有ストレージ機能の具体的には以下のような挙動を前提に開発が進められています。まだリリース前となりますので詳細は含めませんが、以下のような挙動を想定しています。
１.VMDKの共有ディスクリソースはVM起動時オフラインで起動します。
２.リソースのrestore時にアクティブノードで共有ディスクがオンラインとなります。
３.異常時はvSphereのVMFSを経由して相手ノードの状態を確認します。相手ノードがオンラインの場合はrestoreをしても自ノードでのオンライン化に失敗します。そのため、ノード間通信障害（コミュニケーションパスの全断）が発生しても両系でのオンラインは行われません。
この機能が加われば、vSphere環境ではストレージの制限なく利用いただく事が可能となります。リリースの時期はまだお伝え出来ませんが、リリースまで今しばらくお待ちください。
お問合せ
ご不明点や「もっと詳しい話を聞いてみたい」等ございましたらご気軽にお問合せください。
