ディスクアレイコントローラは、物理ディスクドライブを管理し、それらを論理ユニットとしてコンピュータに提示する装置です。多くの場合、ハードウェアRAIDを実装しているため、 RAIDコントローラと呼ばれることもあります。また、追加のディスクキャッシュを提供する場合もよくあります。
ディスクアレイコントローラは、しばしば曖昧にディスクコントローラと略されるが、これは内部ディスクドライブの動作を管理する回路を指す場合もある。
ディスクアレイコントローラは、フロントエンドインターフェースとバックエンドインターフェースを提供する。
単一のコントローラでも、バックエンド通信とフロントエンド通信で異なるプロトコルを使用する場合があります。多くのエンタープライズコントローラは、フロントエンドにFC、バックエンドにSATAを使用しています。
現代のエンタープライズアーキテクチャでは、ディスクアレイコントローラ(ストレージプロセッサ、またはSP [ 1 ]とも呼ばれる)は、ストレージエリアネットワーク(SAN)やネットワーク接続ストレージ(NAS)サーバーに配置されたディスクアレイなどの物理的に独立したエンクロージャの一部です。
これらの外付けディスクアレイは通常、RAIDコントローラ、ディスクドライブ、電源、管理ソフトウェアが統合されたサブシステムとして購入されます。高度な機能を提供するのはコントローラの役割です(ベンダーによって呼び方は異なります)。

シンプルなディスクアレイコントローラは、 PCI / PCIe拡張カードとして、あるいはマザーボードに内蔵される形で、コンピュータ内部に搭載できます。このようなコントローラは通常、物理的なスペースを節約するために、ホストバスアダプタ(HBA)機能を内蔵しています。そのため、RAIDアダプタと呼ばれることもあります。
2007年2月現在 Intelは、よりハイエンドなマザーボードに独自のMatrix RAIDコントローラを統合し始め、4つのデバイスと追加の2つのSATAコネクタを制御し、合計6つのSATA接続( 各3Gbps)を実現しました。下位互換性のために、2つのATAデバイス(100Mbps)を接続できるIDEコネクタも1つ 搭載されています。
ハードウェアRAIDコントローラは以前から存在していましたが、当初は高価なパラレルSCSIハードドライブが必要で、サーバーやハイエンドコンピューティング市場を対象としていました。SCSIテクノロジーの利点としては、1つのバス上に最大15台のデバイスを接続できること、独立したデータ転送、ホットスワップ、そしてはるかに高いMTBFなどが挙げられます。
1997年頃、ATAPI-4(およびそれに伴うUltra-DMAモード。これによりCPU使用率を抑えながら高速データ転送が可能になった)の登場に伴い、最初のATA RAIDコントローラがPCI拡張カードとして登場した。これらのRAIDシステムは、高価なSCSIドライブに投資することなくRAIDの耐障害性を求めるユーザー向けに、一般消費者市場に普及した。
高速な民生用ドライブの登場により、SCSIよりも低コストでRAIDシステムを構築することが可能になった。しかし、ほとんどのATA RAIDコントローラには、パリティ計算用の専用バッファや高性能なXORハードウェアが搭載されていない。そのため、ATA RAIDはほとんどのSCSI RAIDコントローラに比べて性能が劣る。さらに、停電などで書き込みが中断された場合、バッテリーバックアップがないとデータの安全性が損なわれる。
ハードウェアRAIDコントローラは既に構築されたRAIDボリュームを提供するため、オペレーティングシステムは各コントローラの完全な構成と構築を必ずしも実装する必要はありません。多くの場合、オープンソースのソフトウェアドライバには基本的な機能のみが実装され、拡張機能はハードウェアメーカーがバイナリブロブを通じて直接提供します。
通常、RAIDコントローラは、オペレーティングシステムが起動する前にカードBIOSを通じて完全に構成でき、オペレーティングシステムが起動した後は、各コントローラのメーカーから独自の構成ユーティリティが提供されます。これは、各コントローラの正確な機能セットがメーカーや製品ごとに異なる可能性があるためです。イーサネットのネットワークインターフェイスコントローラは、通常、サードパーティのツールを必要とせずに、 Unixのifconfigなどの一般的なオペレーティングシステムのパラダイムを通じて完全に構成および保守できますが、RAIDコントローラの各メーカーは通常、サポートすると判断した各オペレーティングシステム用に独自のソフトウェアツールを提供し、ベンダーロックインを保証し、信頼性の問題につながります。[ 2 ]
例えば、FreeBSDでは、 Adaptec RAID コントローラの構成にアクセスするには、 Linux 互換レイヤーを有効にし、Adaptec の Linux ツールを使用する必要があり、 [ 3 ]特に長期的な視点で見ると、セットアップの安定性、信頼性、セキュリティが損なわれる可能性があります。[ 2 ]ただし、これはコントローラに大きく依存し、ドライバを作成するための適切なハードウェア ドキュメントが利用可能かどうかによって決まります。一部のコントローラには、構成ユーティリティのオープンソース バージョンがあり、たとえばFreeBSD 8.0 (2009) 以降[ 4 ] [ 5 ]および/ 2015 以降[ 6 ]で利用可能ですmfiutilが、それぞれが独自のデバイス ドライバのみをサポートしており、後者の事実がコードの肥大化につながっています。mptutilmpsutilmprutil
他のオペレーティングシステムの中には、任意の RAID コントローラとインターフェースするための独自の汎用フレームワークを実装し、RAID ボリュームの状態を監視するツール、LED 点滅によるドライブ識別の容易化、アラーム管理、ホットスペアディスクの指定、カード BIOS に再起動することなくオペレーティングシステム内からRAID のデータ消去を行う ツールを提供しているものもあります。たとえば、これは2005 年にOpenBSDが、ボリュームの状態を提供し、LED/アラーム/ホットスペア制御、および健全性監視用のセンサー (ドライブセンサーを含む) を可能にするbio( 4 ) 擬似デバイスドライバとbioctlユーティリティで採用したアプローチです。 [ 7 ]このアプローチは、その後 2007 年にNetBSDにも採用され、拡張されました。[ 8 ]
bioctlでは、各コントローラを同じ方法でツールがサポートできるように、機能セットは意図的に最小限に抑えられています。コントローラの初期設定はカード BIOS を介して実行されることを想定していますが、[ 7 ]初期設定後は、bioctl が実現しようとしているように、すべての日常的な監視と修復は統一された汎用ツールで可能になるはずです。