nkjmkzk.net

Automatic Storage Management（以後ASM）を用いてStorage GRID環境を構築する際、「どういう構成がいいのかな？」という問いにお答えする設計の勘所を紹介します。

サーバ機の選び方

• CPU
  • 特に指定なし。ただしStorage GRIDをデータベース用途でかつDWHに使用する場合は後述の1コアあたりが引き出せるI/O帯域について考慮しておく。
• メモリ
  • ASMが含まれるGrid Infrastructureのみをインストールする場合は最低1.5GByte。
  • Oracle Databaseもインストールする場合は最低2.5GByte。
  • ただしメモリはもちろん多めに搭載が理想的。
  • 4GByte DIMMと8GByte DIMMを比較した場合、4GByte DIMMの方が容量あたりの価格が安価。したがってメモリ総量72GByte程度まででよければ、DIMMを大量にインストールできるスロットを搭載している機種の方が安価に仕上げることができる。
• ローカルディスク
  • 最低空き容量10GByte
  • Oracle DatabaseでDB Smart Flash Cacheを利用する場合はSSDを必要量搭載する。SSDの必要量に関しては、データファイルがDRAM + SSDに載りきる容量であればその容量分調達することが望ましい。また、DB Smart Flash Cacheの容量はDatabase Buffer Cacheの2倍から10倍を推奨。また、DB Smart Flash Cacheを有効化するとその管理領域がBuffer Cacheに割り当てられる。その管理領域のサイズは次の式で見積もり可能。db_flash_cache_size / db_block_size x 100 (RACの場合は200)
• ネットワーク
  • 最低2つのネットワークセグメント(Public, Private)が必要。bondingを考慮すればPublic x 2, Private x 2の合計4ポートの1GbEが必要。
• HBA
  • Fibre Channelを利用する場合はFC HBAを2ポート。iSCSIを利用する場合は2ポートの1GbEまたは10GbEを搭載する。いずれのAdapterでもマルチパスを前提としている。また、iSCSIで10GbEを採用する場合にはこの2ポートをVLANでセグメント分割し、前述のPublic, Privateセグメントと共有することも考えられる。

ストレージ装置の選び方

• アプライアンスかI/Aサーバか？
  • Storage GRIDは特定のストレージ装置に依存しないため、任意のアプライアンスまたはディスクを十分に積んだI/Aサーバで構成することができる。
  • I/Aサーバを採用する場合、OSがLinuxであればiSCSI Enterprise Targetを用いてiSCSI Target化し、OSがSolarisであればZFSのビルトインNFSやCOMSTARを用いてiSCSI Target化、Fibre Channel Target化することができる。
  • 極端に容量の多いストレージシステムや完全にSSDで構成されたストレージシステムを構築するといった特殊な要件がある場合にはI/Aサーバを選択し、それ以外の場合には小型のアプライアンスを採用することが望ましい。
• プロトコル
  • サーバ<–>ストレージ間の通信プロトコルは問わない。現在一般的に利用されているFibre Channel, iSCSI, NFSいずれも選択可能。

• オプション機能
  • ASMは複数のストレージ装置を束ねることができるため、ストレージ装置側でアレイの拡張やエンクロージャの拡張機能は必要ない。
  • スナップショット、レプリケーション等の機能はサーバソフトウェア側で提供されるためストレージ装置には必要ない。
• 必要DISK本数
  • 容量だけでサイジングされているケースも散見されるが、実際には容量要件を満たした上でI/O要件も満たす必要がある。
  • DatabaseでOLTP系サービスの提供を行う場合、重要なのはIOPS能力。このときに必要なDISK本数は次のように計算できる。

  DISK本数 = 一秒あたりのトランザクション処理量 x 5 / DISK1本あたりのIOPS能力

  ＊上記の「x 5」は一般的なトランザクションは1トランザクションあたりおおよそ5IOPSで処理されるという前提で代入している。
  ＊15000RPM DISK1本あたりのIOPS能力の目安は、SAS DISKは80〜110 IOPS、SATA DISKは50 IOPSという感覚。本来は実機で測定しておくのが望ましい。

  • DatabaseでDWH系サービスの提供を行う場合、重要なのはI/O帯域。このときに必要なDISK本数は次のように計算できる。

  DISK本数 = 必要なI/O帯域(MB/s) / 20

  ＊「20」は一般的なSATA DISK一本あたりのI/O帯域(MB/s)。本来は実機で測定しておくのが望ましい。
  ＊また一般的な1CPUコアあたりが引き出せるI/O帯域は200MB/s前後。したがって必要I/O帯域から必要となるCPUコア数も算出しておく必要がある。

ネットワーク構成の組み方

非仮想化環境（ベアメタル）、仮想化環境、iSCSIストレージ使用時、Fibre Channelストレージ使用時それぞれのケースでのネットワーク構成を下図にて紹介します。

• ベアメタル環境 + iSCSIストレージ

• ベアメタル環境 + Fibre Channelストレージ

• 仮想化環境 + iSCSIストレージ

• 非仮想化環境 + Fibre Channelストレージ

DISK構成の組み方

• 台数
  • 完全に内部的に冗長化されたストレージアプライアンスを用いる場合は最低台数1台。ただし万一ストレージ装置が故障した場合、データのロストや可用性が損なわれる可能性がある。
  • 内部が冗長化されていないI/Aサーバ等を用いる場合は最低台数3台。この場合、いずれかのストレージ装置が故障してもデータのロストやストレージシステムの可用性が損なわれることはない。
• H/W RAIDとASM冗長化モード
  • 多くの環境ではH/W RAIDを有効化するのが望ましい。ASMはソフトウェア側で従来RAIDが担っていたストライピングとミラーリングを提供できるため、H/W RAIDを一切用いずにDISKを構成することも可能。しかしそれなりの頻度で発生することが想定されるDISK障害は、発生することを前提に影響を最小限に留める設計を行いたい。DISK障害発生時、ホットスワップ可能なDISKとH/W RAIDを用いていればDISKを交換するだけで保守作業が完結する。ASMの場合は新しいDISKをDISKGROUPに組み込むという操作が発生する。実質はコマンド一発で完了するので決してタフな作業ではないが、既存の保守員の作業スコープを考慮するとDISK障害時はDISKの交換という物理的な作業で完結できる方がよかろうというのが意図。DISK障害はH/W RAIDで対応、ストレージノード障害はASMの冗長化モードで対応という設計。
  • ASMには3つの冗長化モードが存在する。
    • 冗長化なし -> 実効容量率: 1/1
    • 二重冗長化 -> 実効容量率: 1/2
    • 三重冗長化 -> 実効容量率: 1/3
  • 推奨される各H/W RAIDモードは下記の通り。
    • 性能重視の場合：RAID 1 -> 実効容量率: 1/2
    • 容量重視で単一RAIDアレイを構成するディスクが少ない場合：RAID 5 (RAID-Z) -> 実効容量率: (DISK本数 – パリティDISK数)/DISK本数  *単一のRAIDアレイ中のパリティDISKは1本
    • 容量重視で単一RAIDアレイを構成するディスクが多い場合：RAID 6 (RAID-Z2) -> 実効容量率: (DISK本数 – パリティDISK数)/DISK本数  *単一のRAIDアレイ中のパリティDISKは2本
  • 完全に内部的に冗長化されたストレージを用い、かつ、ストレージノード障害は想定リスク外とする場合は「冗長化なし」を選択。内部が冗長化されていないI/Aサーバ等を用いる場合は「二重冗長化」または「三重冗長化」を用いる。
  • H/W RAIDとASM冗長化を含めた実効容量の計算方式は次の通り。

  DISK1本あたりの容量 * 1筐体に収容するDISK本数 * H/W RAID実効容量率 * ストレージノード数 * ASM冗長化モード実効容量率

  • 1ストレージノードにつき2つのRAIDアレイを作成する。これは一方をActive、もう一方をBackupとして利用するため。こうすることで一つのStorage GRIDで本番用領域とバックアップ用領域双方をまかなうことができ、かつ、物理的な記憶媒体を完全に分離することができる。このような構成は賛否両論あるところだが、バックアップを別メディアに保存しつつ調達H/Wを最小限にするという要件であれば、非常に効率の良い構成と言える。

  

• LU(Logical Unit)
  • 原則として1つのRAIDアレイから1つのLUを切り出す。ただし、ASM DISKGROUPを構成するDISKの容量は2TBが上限のため、LUサイズは2TBを上限としそれを超える場合は1LUサイズが2TBを超過しないようにLUを複数作成する。

  

  • 切り出したLU上にパーティションを一つ作成する。これはLUを分割して使うという意図ではなく、パーティションを作成しておくことで3rd PartyのソフトウェアがASM DISKを意図せず傷つけないようにするための措置。

  

• ASM DISKGROUP
  • 各ストレージノードのActive側のRAIDアレイを束ねるDISKGROUPと、Backup側のRAIDアレイを束ねるDISKGROUP をそれぞれ作成する。

  

  • Active側のDISKGROUP内に下記を配置する。
    • ファイルシステム：ACFS(本番環境用)
    • Oracle Database：制御ファイル, オンラインREDOログ, データファイル, SPFILE, Change Tracking File
  • Backup側のDISKGROUP内に下記を配置する。
    • ファイルシステム：ACFS(レプリケート先), ACFSスナップショット
    • Oracle Database：制御ファイル, オンラインREDOログ, アーカイブREDOログ, RMANバックアップ, Flashback log

  

  • 万一、Active側のDISKGROUPが全損するような障害が発生した場合でも、利用するDISKGROUPをActiveからBackupに切り替えることで非常に迅速にリカバリを図ることができる。

Storage GRID設計の際、ヒントになれば幸いです。