【第12回】 Linux/OSS エバンジェリスト古賀政純の 『オープンソース・Linux超入門』 システム要件において検討すべき点 その2

Linuxシステムの OS領域やデータ領域を守るRAIDを検討する

バックエンドで利用されるデータベースサーバーの多くはRAIDコントローラーを搭載しますが、そもそもRAIDコントローラーは、なぜ必要なのでしょうか？

RAIDといってもRAIDレベルによって特性が異なりますが、一般的にディスク障害に対するOS領域の保護は、RAIDが設定されます。これらのOS領域の保護以外にも、大規模な外部ストレージでもデータ消失を防ぐためのRAIDレベルが設定されます。RAIDコントローラーを搭載していないサーバーでは、当然ですが、ハードウェアによってRAIDを構成することはできません。

OSは、RAIDを構成しないと物理的に1つのディスクにインストールされます。ハードウェアのRAIDコントローラーを搭載せずに複数のディスクを使ってOS領域の保護を実現するには、OSが提供するソフトウェアRAIDを設定する必要があります。しかし、ソフトウェアRAIDは、障害発生時の運用が煩雑になる場合が多く、あまりお勧めできません。

RAIDを構成せずに、1台のハードディスクドライブにOSをインストールした場合、このディスクに障害が発生すると、当然OSは停止してしまい、サービスが停止してしまいます。データベースサーバーなどでは、共有ディスク内のデータベースへのアクセスの整合性を確保し、サービスの再起動を適切に行うために、共有ディスクへの接続と切断を適切に行えるHAクラスターなどを構成します。しかし、HAクラスターノードを構成する物理サーバー単体の可用性も高く保つ必要があるため、OS領域は、RAIDによる冗長構成をとるのが一般的で す。RAIDには、RAID 1、RAID1+0、RAID 5、RAID 6、あるいはそれらを組み合わせたものなどが採用されます。

RAIDコントローラー配下の複数の物理ディスクをひとまとめにしたものを「論理ディスク」または「論理ボリューム」と呼びます。Linux OSからは、論理ディスクが一つのハードディスクとして見えます。RAID 1やRAID 5、RAID 6などを構成した論理ディスクは、OSから1つのディスクとして見えますが、ディスク障害が発生しても、RAIDコントローラーの機能により、論理ディスクは正常に稼動します。そのため、Linux OSは、正常に稼働することができます。

そして、サーバーが稼動した状態で、障害が発生したディスクを交換すれば、RAIDコントローラーは、新しく交換した物理ディスクにデータを自動的に書き込み、障害前と同じ状態に戻ります。このとき重要な点は、新しく物理ディスクを交換した復旧時は、Linux OS側で管理者がなにも操作しなくてもよいということです。Linux OS側に、物理ディスクの交換に関するログが残りますが、Linux OS側でなにか復旧のための操作を行う必要はありません。

RAIDレベルにおける耐障害性、ディスクの入出力性能、最低限必要なディスク本数などについては、以下のURLが参考になりますので、RAIDレベルの決定の際は、参考にしてください。

https://h50146.www5.hpe.com/products/servers/proliant/support/old/support_01/support01_03_06.html

意外と知られていないRAID要件とLinuxの追加ドライバー

BL460c Gen9は、オンボードでRAIDコントローラーを持っており、さらにRAIDコントローラー上に作成した論理ボリュームにOSをインストールすることができます。ベンダーによって様々ですが、通常、RAIDコントローラーでは、RAIDモードと非RAIDモード（AHCIモード等）が存在し、RAID構成でインストールするのか、非RAID構成でインストールするのかを決める必要があります。

また、RAIDレベル（ミラーリングのRAID 1、ストライピングのRAID 0など）をいくつにするのかも決定しなければなりません。今回のケースでは、バックエンドシステムとなる物理サーバーのBL460c Gen9に搭載できるLinux OS用のディスク本数は2本ですので、ディスク2本を使ったミラーリング構成によりOS領域を保護することになります。Linuxに限った話ではありませんが、OSをRAIDコントローラー配下の論理ボリュームにインストールする場合は、Linux OSがRAIDコントローラーをサポートしているかどうかを確認する必要があります。

ここで、注意しなければならないことは、RAIDコントローラーの種類によっては、追加のドライバーを組み込まないとRAID構成が組めない場合もあるということです。

意外に知られていないのは、ベンダーが提供する「ローエンドのRAIDコントローラー向けの擬似RAID用の追加のドライバー」の存在です。擬似RAIDとは、ローエンドのRAIDコントローラーなどにおいて、ドライバー内のRAIDエンジンを使用し、サーバーに搭載されたCPUを使ってパリティ計算などを行うソフトウェアRAID方式です。

このような擬似RAIDを構成するコントローラーを採用した場合、Linux OSのインストーラのみでは、内蔵のハードディスクドライブをRAIDモードで認識しない場合があります。例えば、HPE SmartArray B120iやHPE SmartArray B140iなどの擬似RAIDコントローラーがそれに相当します。擬似RAIDコントローラーの場合は、ベンダーからdd形式のドライバーディスケットイメージが提供されていますので、Linuxをインストールする際に、そのdd形式のイメージをロードすることによって、内蔵のハードディスクドライブをRAIDモードで認識させることが可能です。

インストーラでロード可能な擬似RAID用のドライバーディスケットイメージの入手先（SmartArray B140iとSLES 12での組み合わせの場合）：

https://h20566.www2.hpe.com/hpsc/swd/public/detail?sp4ts.oid=7271228&swItemId=MTX_9a39aca035ba45139b3725eaf0&swEnvOid=4175

HAクラスター環境における検討項目

データベースを稼働させるバックエンドシステムでは、通常、HAクラスターソフトウェアを導入し、高可用性クラスターを構成するのが一般的です。LinuxサーバーにおいてHAクラスターを構成する場合は、システムの障害発生時における復旧目標時間などで利用者と合意が得られることが大前提です。この前提のもとで、HAクラスターソフトウェアのサポート要件などを確認する必要があります。

HAクラスターソフトウェアにおいては、サポートされるOSのバージョンだけでなく、Linuxのカーネルバージョン、ファイルシステム、外部ストレージの動作認定などを確認する必要があります。HAクラスターソフトウェアの種類やバージョンによって、サポートされるOSの種類とバージョン、ファイルシステム、外部ストレージが異なるため、HAクラスターソフトウェアのリリース情報やサポート構成情報を確認します。

また、HAクラスターの場合は、障害が発生した場合の問題の切り分け作業が必要になることが少なくありません。例えば、

ハードウェアのファームウェアに問題があるのか、

LinuxのOSに標準搭載されているドライバーやベンダー提供の監視エージェントに問題があるのか、

ミドルウェア側に問題があるのかなど、

OSのカーネルやミドルウェア内部の解析が行われます。

そのため、ハードウェア、Linux OS、HAクラスターソフトウェアに関する問題の切り分け窓口がバラバラになると、問題解決に膨大な時間を要しますので、ハードウェア、Linux、HAクラスターソフトウェア等のミドルウェアについては、問題切り分け窓口を一元化しておくことをお勧めします。

さらに、HAクラスターソフトウェアを導入するバックエンドシステムの場合、稼働させるアプリケーション（今回の場合は、PostgreSQL、NFS、Samba、Postfix）がHAクラスターソフトウェアにどこまで対応しているかを確認しなければなりません。最近のHAクラスターソフトウェアは、有名なオープンソースソフトウェアを標準でサポートしていますが、アプリケーションの運用に関する要件によっては、個別でサービスの起動、停止、監視に関するスクリプト等を作りこむ必要もあります。そのため、HAクラスターソフトウェアによって、当該アプリケーションをどのように稼働させるのか、GUIツールやコマンドライン等、どういった障害復旧手順が可能なのかも確認しなければなりません。

このように、バックエンドシステムにおいて、特にHAクラスター環境の場合は、システムを構成する際の事前の検討項目が多いため、注意が必要です。

HAクラスターソフトウェアを稼働させるバックエンドシステムは、単にハードウェアとOSとアプリケーションの対応状況を確認するだけでなく、様々な情報源を駆使し、あらゆる視点でシステム構成を検討しなければならないことが理解できたかと思います。

次回は、「フロントエンドシステムのハードウェア選定、Ubuntu Serverにおける仮想化やコンテナの検討」についてご紹介します。お楽しみに。