クイックスタート：5分でRDMディスクをマップする
深夜2時のサーバー室を想像してみてください。SQL ServerがI/Oタイムアウトエラーを出し続けています。VMFSレイヤーを経由せずに、SANから仮想マシン（VM）へ直接LUNをマップする必要があります。これは、迅速に対応するための標準的な手順です。
1. NAA IDの特定
vSphereのGUIで探すのは時間の無駄です。数十台のディスクはどれも同じに見えてしまうからです. ESXiホストにSSH接続し、次のコマンドを使用してデバイスを正確にリストアップします：
esxcli storage core device list | grep -A 1 "Display Name:"naa.600...で始まる長い文字列が表示されます。このコードをコピーしてください。これが、使用するディスクの「身分証明書」となります。
2. ポインターファイルの作成
RDMは実のところ、「案内役」として機能する.vmdkファイルです。データ自体は含まず、I/Oコマンドを物理ディスクに転送するだけです。VMが格納されているディレクトリに移動し、次のコマンドを実行します：
# 物理モード（完全パススルー）を使用する
vmkfstools -z /vmfs/devices/disks/naa.600123456789... /vmfs/volumes/Datastore_Data/SQL_VM/rdm_disk_01.vmdk3. 仮想マシンへのディスク追加
- VMを右クリックし、[設定の編集]を選択します。
- [新規デバイスの追加]で、[既存のハードディスク]を選択します。
- 先ほど作成した
rdm_disk_01.vmdkファイルを直接指定します。
これで完了です。仮想マシン内のOSは、ディスクを直接接続された物理SCSIデバイスとして認識するようになります。
解説：なぜVMFSではなくRDMを使うのか？
8台のESXiホストクラスターを管理する実務において、私は柔軟性の観点から常に従来のVMDKファイルを優先しています。しかし、RDMは以下の3つの具体的なケースにおける「切り札」となります。
高度な制御を必要とするアプリケーション
ストレージ管理ソフトウェアやバックアップソフトの中には、特定のSCSIコマンドを介してSANのコントローラーと直接通信する必要があるものがあります。VMFSレイヤーは、システム保護のためにこれらのコマンドをブロックすることがよくあります。RDM（物理モード）は、これらのコマンドが障壁なく通過できるように扉を開きます。
クラスターの構築 (WSFC)
異なるホスト間にまたがるVMでWindows Server Failover Clusterを構築する場合、クォーラムディスクまたは共有ストレージが必要です。**SCSI-3 Persistent Reservations**をサポートするためには、RDMがほぼ必須の選択肢となります。
巨大なデータの管理
20〜30TBに達するデータベースの場合、VMFSをフォーマットしてVMDKファイルを作成すると、管理者はメタデータのスキャン時間に不安を感じることがあります。RDMは、このデータをVMwareのファイルシステムから完全に切り離すのに役立ちます。
物理モード (pRDM) vs 仮想モード (vRDM)
ここでの混同は、スナップショットのエラーやvMotionの失敗を招くことがよくあります。
- 物理モード (
-z): 最高のパフォーマンス。ESXiはSCSIコマンドにほとんど介入しません。注意：このモードでは仮想マシンのスナップショットを作成できません。 - 仮想モード (
-r): ESXiが一部を仮想化します。このモードでは、物理ディスクにマッピングしたまま、仮想マシンのスナップショットやクローン作成が可能です。
I/Oの最適化：RDMを鈍足にさせないために
RDMは魔法の杖ではありません。パスの設定を誤れば、速度は依然として低いままです。現在のRDMとVMFS 6の差は、CPUオーバーヘッドの面でわずか1〜3%程度です。
パス選択ポリシー (PSP)を確認してください。Dell UnityやNetAppなどのSANを使用している場合は、HBAカードの帯域幅を最大限に活用するために、Round Robinに変更してください：
# 通信経路を最適化するためにRound Robinに切り替える
esxcli storage nmp device set --device naa.600... --psp VMW_PSP_RR実戦経験
以前、深刻なボトルネックが発生していたデータベース案件を対応したことがあります。RDMに切り替えたところ、ディスク遅延（Disk Latency）が50msから5msへと激減しました。秘訣はRDMの方が速いということではなく、その仮想マシンがSAN上の専用LUNを所有できたことにあります。同じデータストア上の他の20台の仮想マシンとキューの深さ（Queue Depth）を争う必要がなくなったのです。
重要な注意事項：
- vMotion: 仮想マシンを別のホストに移動することは可能です。条件は、移動先ホストに全く同じNAA IDのLUNがマップされていることです。
- Storage vMotion時の注意: 注意を怠ると、データ移行中にVMwareがRDMファイルを通常のVMDKファイルに自動的に変換してしまうことがあります。
- 容量の拡張: ストレージ側でLUNサイズを増やした場合、ESXiで
Rescan Storageを実行する必要があります。OSに新しい容量を認識させるために、VMの再起動が必要になる場合もあります。
結論として：RDMを乱用しないでください。VMFSレイヤーをバイパスする必要がある場合や、クラスターを構成する場合にのみ使用してください。残りの90%のニーズにおいては、管理の柔軟性に優れたVMFSが依然として最善の選択肢です。
