Comments
Description
Transcript
パフォーマンスと可用性に関するEMC CLARiXのベスト
EMC CONFIDENTIAL – INTERNAL USE ONLY EMC CONFIDENTIAL – INTERNAL AND PARTNER USE ONLY DNELETE IF THIS IS A PUBLIC DOCUMENT EMC CONFIDENTIAL – INTERNAL USE ONLY EMC CONFIDENTIAL – INTERNAL AND PARTNER USE ONLY DELETE IF THIS IS A PUBLIC DOCUMENT パフォーマンスと可用性に関する EMC CLARiX のベスト・ プラクティス: リリース 29.0 ファームウェア・アップデート ベスト・プラクティス US ホワイトペーパー翻訳版 P/N PART NUMBER A EMC EMC ジャパン株式会社 東京都渋谷区代々木2-1-1 新宿マインズタワー 〒151-0053 http://japan.emc.com Copyright © 2008, 2009 EMC Corporation.不許複製。 2009 年 10 月 発行 EMC Corporation は、この資料に記載される情報が、発効日時点で正確であるとみなします。情報 は予告なく変更されることがあります。 この資料に記載されている情報は、「現状優先」の条件で提供されます。EMC Corporation は、こ の資料に記載される情報に関する、どのような内容についても表明保証条項を設けず、特に、商 品性や特定の目的に対する適応性に対する黙示の保証はいたしません。 この資料に記載される、いかなる EMC ソフトウェアの使用、複製、頒布も、当該ソフトウェア・ ライセンスが必要です。 最新の EMC 製品名については、EMC.com で EMC Corporation の商標を参照してください。 他のすべての名称ならびに製品についての商標は、それぞれの所有者の商標または登録商標です。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス P/N h5773.3 2 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 目次 このホワイト・ペーパーの使用方法 10 第1章 一般的なベスト・ プラクティス 13 第2章 ホストのベスト・ プラクティス 15 パフォーマンス 15 アプリケーションの設計 15 I/O タイプ 15 アプリケーションのバッファリングとコンカレンシー 17 ボリューム・マネージャ 17 HBA 19 ファイル・システム 20 可用性 第3章 PowerPath 24 その他の MPIO（マルチパス I/O）アプリケーション 25 ALUA 25 キューイング、コンカレンシー、queue-full（QFULL） 27 ストレージ・ネットワーク・アダプタと HBA 28 ネットワークのベスト・プラクティス 33 パフォーマンス 33 iSCSI LAN 可用性 第4章 24 33 34 FC SAN 34 iSCSI LAN 34 ストレージ・システムのベスト・プラクティス 37 パフォーマンス 37 フロントエンド・ポート 37 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 3 目次 ストレージ・プロセッサ 41 書き込みキャッシュの構成 42 ヴォールト・ドライブ 43 ロード・バランシング 45 バックエンドの考慮事項 46 RAID グループ 49 バインド 54 LUN のプロビジョニング 55 仮想プロビジョニングとシン LUN 62 ストレージ・デバイス 67 可用性 71 RAID グループのプロビジョニング 71 LUN のプロビジョニング 73 ドライブの操作とプランニング 74 LUN マイグレーション 74 第 5 章 ストレージ・システムの サイズ設定および パフォーマンス・ プランニング 81 はじめに 81 容量 81 ヴォールト・ドライブ 81 実際のドライブ容量 82 パリティまたはミラーリングによる保護 82 パフォーマンス 82 経験則 82 ランダム I/O 82 シーケンシャル I/O 84 ランダムおよびシーケンシャルの混在 I/O 84 パフォーマンス見積もり手順 84 パフォーマンス・ニーズと容量ニーズの解決 86 サイズ設定の例 86 手順 1：ワークロードを決定する 86 手順 2：必要な I/O ドライブ負荷を決定する 87 手順 3：必要なドライブ数を決定する 87 手順 4：ストレージ・システムの数とタイプを決定する 87 その他の考慮事項 88 4 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 図 図 1 Plaid の種類 18 図 2 63 ブロック・メタデータ・エリアでのアライメントの 誤りの影響 22 図 3 ハイブリッドのストライプ metaLUN 58 図 4 metaLUN のストレージの初期分散 60 図 5 RAID グループ・セットと metaLUN でのデータ・ フェンシングの例 図 6 metaLUN のベース LUN のスタック 61 62 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 5 図 6 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 表 表 1 ALUA とアクティブ/パッシブ・フェイルオーバー 準拠の OS 26 表 2 iSCSI ポートごとの VLAN の最大数 35 表 3 iSCSI ポートの帯域幅と IOPS 38 表 4 CX4 の SP ごとの iSCSI ポート最大数 39 表 5 ファイバ・チャネル・ポートの帯域幅 39 表 6 SP 1 つあたりのファイバ チャネル ポートの最大数 40 表 7 16 個の FC フロントエンド・ポートの CX4-480 41 表 8 CX4 ファミリの特性 42 表 9 FLARE 29 での最大のキャッシュ割り当て 43 表 10 CX4 の推奨されるキャッシュ設定 43 表 11 ヴォールト・ドライブの最大ホスト I/O ロード 44 表 12 ホット・スペアのプロビジョニングの例 49 表 13 MetaLUN ストライプ・マルチプライア 59 表 14 ストレージ・システムごとのシン・プロビジョニング・ ストレージ・プール数 63 表 15 シン・プロビジョニング・ストレージ・プールの ストレージ・デバイスの構成 64 表 16 ストレージ・プールのストレージ・ドライブ割り当ての 推奨値 65 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 7 表 表 17 シン LUN プロビジョニングの推奨事項 66 表 18 CLARiX の EFD の構成 68 表 19 EFD の容量 68 表 20 RAID 5 の EFD 再構築速度 70 表 21 LCC 障害とプロビジョニング 72 表 22 FLARE 29 の Low、Medium、High のマイグレーション 速度 75 表 23 FLARE 29 の ASAP マイグレーション速度のデフォルト 設定 75 表 24 経済的なミラーおよびパリティ RAID ファイバ・ チャネル・ハード・ディスク・ドライブの再構築速度 76 表 25 ASAP ミラーおよびパリティ RAID ファイバ・ チャネル・ハード・ディスク・ドライブの 再構築速度（負荷がない場合） 77 表 26 ASAP ハード・ディスク・ドライブの再構築速度の 調整 77 表 27 RAID グループ・サイズ別のパリティ RAID 再構築 速度 77 表 28 ミラーおよびパリティ RAID ファイバ・チャネル・ イコライズ再構築速度 表 29 ドライブ・タイプ別の小さいブロックのランダム I/O 78 83 表 30 ドライブ・タイプ別の大きいブロックのランダム 帯域幅 83 表 31 CX4 の最適なドライブ数 86 表 32 サイズ設定の見積もり計算結果 87 8 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス このドキュメントについて ® このドキュメントについて ® このドキュメントでは、EMC CLARiX CX4 シリーズのストレージ・システムで高いパフォーマンスと可用性を実 現するためのベスト・プラクティスについて検討します。CLARiX の可用性とパフォーマンスに影響する要素を、ホ スト、ネットワーク、ストレージ・システムのレベルで説明します。 推奨事項が複数提示される場合もあります。どの推奨事項に従うかは、使用しているアプリケーションによって異な ります。たとえば、ストレージ・システムを構成するときは、可用性とパフォーマンスのどちらがより重要かを判断 し、それに従ってシステムをプロビジョニングすることが必要な場合があります。 このホワイト・ペーパーの内容に不明な点がある場合は、ホワイト・ペーパー「EMC CLARiiON Storage System Fundamentals for Performance and Availability」を参照してください。「EMC CLARiiON Storage System Fundamentals for Performance and Availability」は、この「パフォーマンスと可用性に関する EMC CLARiX のベス ト・プラクティス」と同じ構成であるため、簡単に参照できます。一般的なストレージ・システムや CLARiX スト レージ・システムに精通していない場合は、「EMC CLARiiON Storage System Fundamentals for Performance and Availability」を一読することをお勧めします。 「サイズ設定の例」セクションでは、パフォーマンスと容量に応じて CLARiX ストレージ・システムのサイズを設定 する方法について説明します。このセクションは、EMC のセールスおよび技術の専門スタッフが使用できるソフト ウェア・ツールの代わりとなるものではありません。 このドキュメント全体を通じて、http://japan.emc.com/およびPowerlinkから入手できる EMC のホワイト・ペーパー が参照先として示されています。これらのドキュメントを参照して、ベスト・プラクティスおよびその効果について 理解を深めることをお勧めします。 ® このバージョンの「パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス」は、FLARE リリー ス 29.0 ファームウェアに適用されます。このリビジョンでは、次の内容が加筆および修正されています。 CLARiX のスピン・ダウン機能 8 Gb/秒ファイバ・チャネル・フロントエンド・ポート 10 Gb/秒 iSCSI フロントエンド・ポート LUN 縮小機能 VLAN タグ機能 Virtual Provisioning™拡張機能 LUN マイグレーション速度の変更 その他の修正 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 9 このドキュメントについて このドキュメントでは、ドライブという用語は、機械的なハード・ディスク・ドライブと EFD（エンタープライ ズ・フラッシュ・ドライブ）の両方を指します。EFD は、不揮発性のメモリ・ベースのドライブであり、IT 業界で は半導体ディスク（SSD）と呼ばれる場合もあります。機械式ドライブと EFD はよく似ています。ただし、相違点 もいくつかあり、このドキュメントではそれらの相違点について説明しています。また、このホワイト・ペーパーの 巻末にある用語集には、EMC に固有の用語が掲載されています。 調整用パラメータとソフトウェアの機能は FLARE のリビジョンによって異なることに注意してください。古いパラ メータを使用してホスト、ネットワーク、ストレージ・システムを調整すると、機能しないか、予期せぬ結果になる 場合があります。CLARiX CX3 以前の CLARiX シリーズのストレージ・システムについてガイダンスが必要な場合は、 Powerlinkから入手できるホワイト・ペーパー「EMC CLARiiON Best Practices for Fibre Channel Storage: CLARiiON Release 26 Firmware Update」を参照してください。 このホワイト・ペーパーの使用方法 このホワイト・ペーパーは、チュートリアルとしても、参照用としても使用できます。参照用として使用するには、 まず、どのサブシステム（ホスト、ネットワーク、CLARiX のいずれか）を最適化するか決定します。次に、参照し たい内容が、パフォーマンスか、可用性か、その両方かを判断し、関連するセクション全体を読んでください。 このホワイト・ペーパーは、以下の各セクションに分かれており、ストレージ・システム内の 3 つのサブシステムに ついて、ストレージに関連するパフォーマンスおよび可用性のベスト・プラクティスを検討しています。また、スト レージ・システムのサイズの設定方法に関するセクションもあります。 ホストのベスト・プラクティス ホストのパフォーマンスのベスト・プラクティス ホストの可用性のベスト・プラクティス ネットワークのベスト・プラクティス SAN のパフォーマンスのベスト・プラクティス SAN の可用性のベスト・プラクティス CLARiX ストレージ・システム CLARiX のパフォーマンスのベスト・プラクティス CLARiX の可用性のベスト・プラクティス ストレージ・システムのサイズ設定およびパフォーマンス・プランニング：ワークロード用にストレージ・シス テムを構成する際の考慮事項 これらのセクションのベスト・プラクティスの中には、ストレージ・システム全体のパフォーマンスや可用性に影響 するものもあります。 対象読者 このドキュメントの対象読者は、CLARiX CX4 および AX4 シリーズのストレージを実装する際の最も効果的なアプ ローチについて助言を必要とする技術担当者です。ホスト（サーバ）およびストレージ・システム・ネットワーク （SAN、iSCSI LAN、DAS）の基礎を理解していることと、CLARiX ストレージ・システムの基盤に関する知識が必要 です。 10 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス このドキュメントについて 関連資料 以下のホワイト・ペーパーはhttp://japan.emc.com/および Powerlink から入手可能です。 「An Introduction to EMC CLARiiON CX4 Disk-Drive Spin Down Technology」 「An Introduction to EMC CLARiiON and Celerra Unified Storage Platform Storage Device Technology」 「Best Practice Considerations for CLARiiON CX3 FC/iSCSI Storage Systems」 「CLARiiON Global Hot Spares and Proactive Sparing」 「EMC CLARiX 非対称アクティブ/アクティブ機能（ALUA）」 「EMC CLARiiON Best Practices for Fibre Channel Storage: CLARiiON Release 26 Firmware Update」 「EMC CLARiiON High Availability (HA) — Best Practices Planning」 「EMC CLARiiON MetaLUNs」 「EMC CLARiiON Storage Solutions: Microsoft Exchange 2007 — Best Practices Planning」 「EMC CLARiiON Storage System Fundamentals for Performance and Availability」 「UltraFlex テクノロジーを実装した EMC CLARiX CX4 シリーズの概要」 「Using diskpar and diskpart to Align Partitions on Windows Basic and Dynamic Disks」 以下の製品ドキュメントは Powerlink から入手可能です。 「EMC Navisphere Analyzer Administrator’s Guide」 「EMC Networked Storage Topology Guide」 「EMC PowerPath Version 5.2 Product Guide」 「Installation Roadmap for CLARiiON Storage Systems」 「Native Multipath Failover Based on DM-MPIO for v2.6.x Linux Kernel and EMC Storage Arrays」 「Navisphere Command Line Interface (CLI) Reference」 Navisphere Manager バージョン 6.29 オンライン・ヘルプ 「VMware ESX Server Using EMC CLARiiON Storage Systems TechBook」 「CX4 モデル 960 システム ハードウェアと操作方法の概要」 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 11 このドキュメントについて 12 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 第1章 一般的なベスト・ プラクティス 大規模で複雑なコンピュータ・ベースのシステムを設計、構成、調整する際に、簡単に答が出ることはめったにあり ませんが、ストレージ・システムから最適なパフォーマンスと可用性を得るための一般的なベスト・プラクティスを 以下に示します。 マニュアルを読む。 最新のファームウェアをインストールする。 ワークロードについて理解する。 問題を迅速に解決する。 デフォルトの設定を使用する。 マニュアルを読む：ホワイト・ペーパー「UltraFlex テクノロジーを実装した EMC CLARiX CX4 シリーズの概要」と、 使用している CX4 モデルの「ハードウェアと操作方法の概要」を読んで、CLARiX のハードウェアについて理解して ください（たとえば、CLARiX CX4-960 の概要については、「CX4 モデル 960 システム ハードウェアと操作方法の 概要」を参照してください）。また、Navisphere Manager バージョン 6.29 オンライン・ヘルプを参照して、CLARiX のソフトウェアについて理解してください。疑問に対する回答の多くが、ここで見つかります。ヘルプ情報は、 CLARiX ストレージ・システムで直接参照でき、Powerlinkからダウンロードできます。「EMC CLARiiON Storage System Fundamentals for Performance and Availability」でも、CLARiX の機能に関する背景知識が得られます。 最新のファームウェアをインストールする：ファームウェア・リリースとパッチ・レベルは最新の状態を維持してく ださい。また、CLARiX の定期的に発行されるリリース・ノートで、常に最新情報を得てください。リリース・ノー トには、ハードウェアとソフトウェアのリビジョンおよびそれらの効果に関する最新情報が記載されています。これ により、EMC が認識している最高レベルのパフォーマンスと可用性が保証されます。堅実なアップグレード・ポリ シーを設定し、CLARiX の無停止アップグレード（NDU）を使用してアップグレードして、ワークロードに悪影響を 及ぼすことなく、最新のパッチ・レベルを維持してください。Powerlinkから入手できる「CLARiX ソフトウェア・ アップデート（標準）」の手順に従って、CLARiX のファームウェアを最新のリビジョンに更新してください。 ワークロードについて理解する：ベスト・プラクティスを実装するには、ストレージ・システムのワークロードにつ いて理解する必要があります。ホスト・アプリケーションの知識も必要です。ワークロードの要件がストレージ・シ ステムのパフォーマンス能力を超えると、パフォーマンスのベスト・プラクティスを適用してもほとんど効果がない ことを覚えておいてください。また、システム・パフォーマンスの履歴を残しておくことも重要です。パフォーマン ス値を把握してたうえでベスト・プラクティスを適用し、結果を評価することで、時間と労力を大幅に節約できます。 最後に、ワークロードや全体的なシステム構成の変化に注意して、全体的なパフォーマンスへの影響を理解できるよ ® うにしてください。EMC では、Navisphere Analyzer を使用してパフォーマンスを監視および分析することをお勧 めします。Analyzer を使用して監視すると、履歴比較をするうえでベースラインとなるパフォーマンス値が得られま す。この情報により、パフォーマンスが予期せず変化した場合に早期に警告を発することができます。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 13 一般的なベスト・プラクティス 問題を迅速に解決する：ストレージ・システムでは、継続的な自己監視が行われます。また、アラートや警告、一元 的で包括的なログやレポートを生成するように構成できます。プロアクティブに、一般的な問題を処理してください。 後に深刻な問題が発生しないように、定期的にログを確認し、システム・レポートを生成して確認する必要がありま す。また、ドライブ障害などのアラートや警告に対して、適切な措置で迅速に対応する方法を理解しておいてくだ さい。 デフォルトの設定を使用する：CLARiX ストレージ・システムを最大限に活用するために、すべてのワークロードを 調整する必要はありません。CLARiX では、デフォルトの構成設定で、最大限のワークロードおよびストレージ・シ ステムの構成に対応できる高レベルのパフォーマンスと可用性が得られます。疑問がある場合は、デフォルト設定を 使用してください。また、変更を行うときは、構成設定とプロビジョニングは控えめに見積もってください。 14 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ホストのベスト・プラクティス 第2章 ホストのベスト・ プラクティス ホストのベスト・プラクティスでは、ストレージ・システムに接続されているサーバ・クラスのコンピュータのソフ トウェアおよびハードウェアの構成と、それらがストレージ・システム全体のパフォーマンスと可用性に与える影響 について説明します。 パフォーマンス アプリケーションの設計 ホスト・アプリケーションの設計、構成、実行によって、システム全体の動作が決まります。Microsoft Exchange や Oracle など、多くの重要なアプリケーションには、パフォーマンスと可用性の機能が統合されています。多くの場合、 アプリケーションの構成や調整を適切に行うと、ネットワークやストレージ・システムを調整した場合よりもパ フォーマンスが大幅に向上します。 I/O タイプ システムのアプリケーションの運用設計（いつ、どのように使用するか）は、ストレージ・システムの負荷に影響し ます。I/O の特徴を理解することは、どのベスト・プラクティスを適用するか判断するうえで重要です。アプリケー ションのワークロードによって生成される I/O には、次のような特徴があります。 シーケンシャルとランダム 書き込みと読み取り 大きいブロック・サイズと小さいブロック・サイズ 安定的と突発的 シーケンシャル I/O とランダム I/O アプリケーションの I/O には次の 3 種類があります。 シーケンシャル ランダム 混在 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 15 ホストのベスト・プラクティス CLARiX の書き込みと読み取りの効率は、ワークロードが主にシーケンシャル I/O かランダム I/O かによって異なり ます。ランダムとは、ストレージ内の連続していない位置に対して逐次読み取りまたは書き込みを行うことです。尐 量のランダム I/O では、大容量のシーケンシャル I/O よりもストレージ・システムのリソースが多く使用されます。 ランダム I/O の特徴は、スループットが高いことです。シーケンシャル I/O のみを実行するアプリケーションは、 ランダムまたは混在の I/O を実行するアプリケーションよりも帯域幅が大きくなります。両方の I/O タイプのワーク ロードを処理するには、分析を行い、帯域幅とスループットのトレードオフを検討し、両方を最適化できるようにす る必要があります。 アプリケーションごとに実行される I/O のタイプを理解し、定量化する必要があります。シーケンシャル I/O とラン ダム I/O のいずれについても、ベスト・プラクティスが十分に認識されています。I/O タイプがわかれば、ワーク ロードに適用するベスト・プラクティスが決まります。 書き込み I/O と読み取り I/O 書き込みでは読み取りの場合よりも CLARiX のリソースが多く消費されます。書き込みキャッシュへの書き込みは、 両方の SP（ストレージ・プロセッサ）にミラーリングされます。RAID グループに対する書き込み時にパリティを書 き込むと、SP の CPU ではパリティを計算する必要があります。パリティは、ディスクに書き込まれる冗長性情報で す。ミラーRAID グループ（RAID 1 および 1/0）への書き込みには、書き込むデータのコピーが 2 つ必要です。 通常、読み取りでは CLARiX のリソースの消費は比較的尐なくなります。キャッシュにデータが見つかった場合 （キャッシュ・ヒット）の読み取りでは、必要となるリソースは最も尐なく、スループットは最大になります。ただ し、キャッシュにデータのない場合（キャッシュ・ミス）の読み取りでは、データをドライブから取得する必要があ るので、レスポンス・タイムがはるかに長くなります。ランダム I/O で特徴づけられるワークロードでは、キャッ シュ・ミスの比率が最も高くなります。読み取り処理がキャッシュ・ヒットかキャッシュ・ミスかによって、読み取 り処理のスループットに影響します。 一般的に、シーケンシャル I/O で特徴づけられるワークロードでは、帯域幅が最大になります。シーケンシャル・ラ イト処理の SP およびドライブ・オーバーヘッドはランダム・ライト処理と比べて低くなります。先読み取り技術を 使用するシーケンシャル・リード処理では、キャッシュ・ヒットの可能性がランダム・リード処理より高くなります。 アプリケーションで実行される書き込みと読み取りの比率を理解し、定量化する必要があります。アプリケーション で実行される書き込みと読み取りの比率がわかれば、ワークロードに適用するベスト・プラクティスが決まります。 大きいブロック・サイズの I/O と小さいブロック・サイズの I/O どの I/O にも固定および可変のリソース・コストがあります。リソース・コストは主に I/O サイズによって決定され ます。このホワイト・ペーパーの目的上、16 KB までの I/O を小とみなし、64 KB より大きい I/O を大とみなします。 CLARiX で大きい I/O を実行すると、小さい I/O よりも帯域幅が大きくなります。大きい RAID グループまたは大き い metaLUN が大容量 I/O の宛先である場合は、バックエンド・バスの速度がパフォーマンスを制限する要因となる 場合があります。 オンライン・トランザクション処理（OLTP）など、小さいブロックのランダム・アクセス・アプリケーションは、 通常はシーケンシャル I/O よりアクセス時間が大幅に長くなります。このタイプの I/O は、1 秒あたりのドライブの 最大処理数（IOPS）によって制限されます。OLTP などの高スループット・ワークロード用に設計する際は、この ドキュメントで推奨しているバス・ベースの帯域幅ではなくドライブ・ベースの IOPS レートを使用することが重要 です。 CLARiX ストレージ・システムでは、I/O が特定のサイズに達すると、書き込みのキャッシュとプリフェッチはバイ パスされます。デフォルトでは、このパラメータ（［Write Aside］サイズ）の値は 2048 ブロックです。プリフェッ チの値（［Prefetch Disable］サイズ）は 4097 ブロックです。これらの値は、Navisphere Secure CLI で変更できま す。大きなリクエストを使用するか小さなシーケンシャル・リクエストに分割するかは、アプリケーション、および アプリケーションとそのキャッシュとの相互作用によって決まります。 アプリケーションで実行される I/O サイズ、つまりサイズの分散を理解することが重要です。これによって、ワーク ロードに適用するベスト・プラクティスが決まります。 16 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ホストのベスト・プラクティス 安定的 I/O と突発的 I/O ストレージ・システムに対する I/O トラフィックには、安定的（定期的）なものと突発的（単発的）なものがありま す。トラフィックのパターンは、長期に渡って単発的だった後に安定的になるなど、時間の経過によって変わる場合 もあります。「業務時間中」にランダム・アクセス・アプリケーション用に構成されているストレージ・システムで、 業務時間終了後のバックアップやバッチ処理の際にシーケンシャル・パフォーマンスが必要になることは珍しくあり ません。一例として、OLTP システムの動作は、通常の運用時は突発的ですが、夜間のバックアップ時には安定的に なります。 ストレージ・システムのパフォーマンスのマージンをバースト（スパイクとも呼ぶ）に備えて確保しておく必要があ ります。この確保したマージン（特に書き込みキャッシュ）は、バーストの「最悪の場合」に対応するために必要で す。そうしておかないと、ビジーな時間帯にスパイクが発生した場合、ユーザーのレスポンス・タイムに悪影響が出 ることがあります。 アプリケーションで実行される I/O のタイプを理解し、定量化する必要があります。I/O のパターン、I/O パターンが 変化するタイミング、I/O パターンの有効期間がわかれば、ワークロードに適用するベスト・プラクティスが決まり ます。 アプリケーションのバッファリングとコンカレンシー 多くのアプリケーションでは、独自に I/O バッファリングを実行してファイル・アップデートを併合します。 Microsoft Exchange、Microsoft SQL Server、Oracle など完成度の高い製品では、アプリケーション・バッファリン グを使用して I/O をインテリジェントに管理し、レスポンス・タイムを短縮します。たとえば、一部のデータベース では、自動的、定期的にインデックスを作成し直すことにより、レスポンス・タイムを短縮します。 多数の具体的なアプリケーションのバッファ構成（キャッシュ構成とも呼ぶ）の詳細については、Powerlink で参照 できます。たとえば、ホワイト・ペーパー「EMC CLARiiON Storage Solutions: Microsoft Exchange 2007 - Best Practices Planning」では、該当アプリケーションのキャッシュ構成について具体的に説明しています。 アプリケーションのコンカレンシー（並列化）により、ホストは複数のドライブを同時にビジーにしておくことがで きます。この機能により、複数の Microsoft Exchange データベースのランダム I/O 用であっても、大きい I/O を複数 の RAID グループに分散させることでメリットを得ている広帯域幅アプリケーション内であっても、ストレージ・シ ステムが最も効率的に利用されます。アプリケーションのコンカレンシーでは、アプリケーション内で単一のオブ ジェクトまたはテーブル行に対して同時に読み取りや更新を行うための、複数の競合する要件に対応します。上書き、 繰り返し不可能な読み取り（以前に変更された値の読み取り）、ブロックは、努めて回避されます。I/O のコンカ レンシーが高いほど、システムのパフォーマンスは向上します。アプリケーションは、コンカレンシーを内部で調整 するように構成できます。コンカレンシー構成のベスト・プラクティスについては、ワークロード・アプリケー ションの構成ドキュメントを参照してください。 ボリューム・マネージャ ホストのボリューム・マネージャがパフォーマンスに及ぼす最大の効果は、CLARiX LUN のストライピング方法と関 係があります。使用される技法は、Plaid または Stripe on Stripe としても知られています。次の 3 つの異なる Plaid 技法があります。 専用 RAID グループ マルチシステム クロス 次の図は、3 つの Plaid 技法を示しています。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 17 ホストのベスト・プラクティス Host Volume B Host Volume C Host Volume D Host Volume A SP A SP A RAID Group 10 SP B SP B RAID Group 11 A. Plaid with Dedicated RAID Groups SP A SP A B. Multisystem Plaid SP B RAID Group 10 SP B RAID Group 11 C. Cross Plaid 図1 Plaid の種類 専用 RAID グループ 単一の LUN または metaLUN にサービスを提供できるのは、一度に 1 つのストレージ・プロセッサのみです。図 1の 構成 A は、両方の SP に広帯域幅の負荷を分散できる Plaid を示しています。 CLARiX SP へのアクティブ・パスをそれぞれ完全に作動させるには、各 SP のホスト上に HBA（ホスト・バス・ア ダプタ）が 1 つずつ必要です。たとえば、SP A の 2 つのポートおよび SP B の 2 つのポートを介して I/O を同時に行 う場合、最大の帯域幅を実現するためにはホスト上に 4 つ以上の単一ポート HBA が必要です。 マルチシステム 図 1の構成 B は、拡張したストレージ・システムを示しています。この構成は、ファイル・システムのサイズと帯域 幅の要件により、このような設計が可能な場合にのみ推奨されます。ソフトウェア・アップグレード、または 1 つの ストレージ・システムにおけるコンポーネント障害による書き込みキャッシュの無効化などのストレージ・システム 障害は、ファイル・システム全体に悪影響を及ぼすことに注意してください。マルチシステム Plaid の候補の良い例 として、1 つのストレージ・システムの書き込み帯域幅の制限を超える帯域幅を必要とする 30 TB の情報システム・ データベースがあります。 クロス Plaid 複数のホスト・ボリュームが同じ CLARiX RAID グループから構築されることは珍しくありません（クロス Plaid、図 1 の構成 C）。この設計の原理は、いずれか 1 つのボリューム・グループに対して突発的に発生したランダム・アク ティビティを多数のドライブに分散させることです。欠点は、ボリューム間の対話が非常に困難であることです。た だし、クロス Plaid は次の場合に有効です。 I/O サイズが小さく（8 KB 以下）ランダムにアクセスされる場合。 ボリュームで、同じ時間帯ではなく、1 日の異なる時間にバーストが発生する場合。 Plaid で実行すべきこと ホスト・マネージャ・ストライプの深度（ストライプ・エレメント）を CLARiX LUN のストライプ・サイズに設 定します。ストライプ・サイズの整数倍の値を使用してください。ただし、ストライプ・エレメントは 1 MB 以 下にしておくことをお勧めします。たとえば、CLARiX のストライプ・サイズが 512 KB の場合、ホスト・スト ライプ・エレメントは 512 KB または 1 MB にします。 便宜上、ホスト・マネージャ・ストライプは CLARiX のベース LUN から構築してください。metaLUN からは構 築しないでください。 別々の RAID グループの LUN を使用してください。グループの構成（ストライプ・サイズ、ドライブ数、RAID タイプ、ドライブ・タイプなど）はすべて同じである必要があります。 18 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ホストのベスト・プラクティス Plaid で避けるべきこと パリティを必要とするホスト・ベースの RAID 実装（RAID 3、5、6 など）の使用は避けてください。この実装 を使用すると、ストレージ・システムの方が効果的に処理できるパリティ保護にホスト・リソースが消費され ます。 同じ RAID グループから複数の LUN を一緒にストライプしないでください。これは大規模なドライブ・シークの 原因となります。1 つの RAID グループの複数の LUN を組み合わせる場合は、ストライピングを使用せずに、連 続した LUN を連結します。 ホスト・ストライプ・エレメントを CLARiX RAID ストライプ・サイズよりも小さく設定しないようにしてくだ さい。 異なる RAID タイプ、ストライプ・サイズ、大きく異なるドライブ数の RAID グループからの LUN を一緒に Plaid 処理しないでください。大きな障害にはなりませんが、結果にむらが出る可能性があります。 広帯域幅用の Plaid Plaid は、次のような複数の理由により広帯域幅アプリケーションで使用されます。 Plaid はストレージ・システムに対するコンカレンシー（パラレル・アクセス）を増大します。 Plaid では複数のホスト HBA および CLARiX SP が 1 つのボリュームにサービスを提供できます。 非常に大きいボリュームは、複数の CLARiX システムで分割できます。 コンカレンシーの増大 Plaid は、アプリケーションがシングル・スレッドの場合に便利です。アプリケーション I/O サイズがボリューム・ マネージャ・ストライプを満たす場合、ボリューム・マネージャはボリューム・コンカレンシーを構成する LUN に アクセスできます。 Plaid と OLTP OLTP アプリケーションは、分析が困難であり、ホット・スポットに悩まされています。ホット・スポットとは、ド ライブ使用率が平均より高い RAID グループです。Plaid は複数のハード・ディスク・ドライブに I/O を分散させる効 果的な方法です。ドライブの数が多いことは、複数のドライブがビジー状態になる可能性のあるアプリケーションに 役立ちます。 一部のボリューム・マネージャでは、小さなホスト・ストライプ（16～64 KB）が推奨されています。ストライピン グされた RAID タイプを使用する CLARiX LUN の場合、小さなホスト・ストライプは適用しません。OLTP の場合、 ボリューム・マネージャのストライプ・エレメントは CLARiX ストライプ・サイズ（通常、128～512 KB）に設定す る必要があります。OLTP 用の Plaid の主な代償は、ほとんどのユーザーが最終的にクロス Plaid を使用することです。 HBA ホスト接続に使用するネットワーク・トポロジーは、システムの目的によって異なります。パフォーマンスの面でも 可用性の面でも、常に複数の HBA を使用することをお勧めします。HBA によるパフォーマンスへの主な効果は、マ ルチパス化に使用することで得られます。複数のパスを使用すると、ストレージ・システム管理者は、複数の CLARiX リソース間でロード・バランシングを行うことができます。24ページの「PowerPath」セクションで、 CLARiX のマルチパス機能について説明します。 ストレージ・システムを調整するときは、HBA とそのドライバの動作を考慮してください。HBA ファームウェア、 使用した HBA ドライバ・バージョン、およびホストのオペレーティング・システムはすべて、最大 I/O サイズや、 ストレージ・システムで発生するコンカレンシーの程度に影響する可能性があります。EMC サポート・マトリック ス・サービスで、ドライブおよびファームウェアに推奨される設定が提供されています。それらの推奨事項を満たし た設定を行う必要があります。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 19 ホストのベスト・プラクティス HBA ポートはそれぞれ、スイッチ上で、HBA と通信相手の SP ポートを含む別々のゾーンで構成する必要がありま す。EMC では、単一イニシエータのゾーニング戦略をお勧めします。 ファイル・システム ホストのファイル・システムを適切に構成すると、ストレージ・システムのパフォーマンスに大きなプラスの効果が 出る場合があります。ストレージは、ボリューム・マネージャとオペレーティング・システムを使用してファイル・ システムに割り当てることができます。ホストのファイル・システムで、複数のホストからストレージへの共有アク セスをサポートできます。 ファイル・システムのバッファリング ファイル・システムをバッファリングすると、ストレージ・システムの負荷が軽減されます。アプリケーション・レ ベルのバッファリングの方が、ファイル・システムのバッファリングよりも通常は効率的です。ストレージ・システ ムのパフォーマンスを向上させるためには、バッファリングを最大限利用する必要があります。 ただし、次のような場合は、バッファリング拡張のメリットはありません。 アプリケーション・レベルのバッファリングを適用済みの場合 大容量メモリ・モデルのホスト アプリケーション・レベルのバッファリングとファイル・システムのバッファリングがホスト上で相反する動作をし ないことを確認してください。アプリケーション・レベルのバッファリングでは、アプリケーション（Oracle など） の方が、オペレーティング・システムよりインテリジェントに I/O をバッファできるとされています。また、ファイ ル・システムの I/O が結合されていない方がアプリケーションの I/O 応答時間が短縮されると見込まれています。 ホスト・メモリに常駐しているファイル・システムの容量を知っておく必要があります。64 ビットのオペレー ティング・システムでは、ホストのメイン・メモリは最大で 128 GB です。このような大容量メモリ・モデルのホス トでは、ファイル・システム全体がバッファ可能です。メモリ内にファイル・システムがあると、読み取り I/O （バッファ済みの可能性あり）のレスポンス・タイムが大幅に短縮されます。書き込み I/O ではライト・スルー機能 を使用して、コミットされたデータの保全性を保証する必要があります。 ファイル・システムの結合 ファイル・システムを結合すると、CLARiX から広帯域幅を得ることができます。ほとんどのシーケンシャル・アク セス処理では、（可能な場合は）最大連続、および最大物理ファイル・システム設定を使用して、ファイル・システ ムの結合を最大化します。これによってストレージ・システムの I/O サイズが拡大し、帯域幅の向上に役立ちます。 たとえば、バックアップ・プログラムでこの技法を使用し、64 KB の書き込みをフル・ストライプ・ライトに結合す ることができます。フル・ストライプ・ライトは、書き込みキャッシュをバイパスできる場合のパリティ RAID グ ループで非常に効率的です。 ファイル・システムの I/O サイズ アプリケーションやストレージ・システムに合わせてファイル・システムの I/O サイズを調整すると、パフォーマン スにプラスの効果が出る場合があります。 最小 I/O サイズ：アプリケーションとファイル・システムの最小 I/O サイズが相反していないことを確認してくださ い。ファイル・システムは、最小 I/O エクステント・サイズに合わせて構成できます。これは、ストレージ・システ ムに与えられる、これ以上分割できない最小のリクエスト・サイズです。典型的な値は 4 KB、8 KB、16 KB、64 KB のいずれかです。ファイル・システムのエクステント・サイズよりも小さいサイズで I/O を実行するアプリケー ションでは、不要なデータ移動や読み取り-変更-書き込みのアクティビティが発生します。 raw パーティションとして構成されているストレージは、ファイル・システムの I/O サイズによってリクエスト・サ イズが制限されないため、この制約はありません。 20 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ホストのベスト・プラクティス 最小 I/O サイズの最適な設定を決定する際の推奨事項については、ワークロードのアプリケーションとオペレー ティング・システムのファイル・システム双方のドキュメントを参照してください。 最大 I/O サイズ：大量のデータを迅速に移動することが目的の場合、大きい I/O サイズ（64 KB 以上）が役立ちます。 ストレージ・システムでは、キャッシュ内のシーケンシャル・ライト処理を RAID グループのフル・ストライプに効 率よく結合できるだけではなく、大量のシーケンシャル・リード処理の事前読み取りも効果的に行うことができます。 さらに、大きい I/O サイズは、ストライプ・トポロジーに従って小さいサイズに分割されるので、ホスト・ベースの ストライプから満足できる帯域幅を取得するうえで重要です。 ファイル・システムの断片化：ストレージ容量の使用率が高い場合は、ファイル・システムの最適化によってパ フォーマンスを向上できます。断片化したファイル・システムでは、シーケンシャル・リード/ライト処理の機会が 減尐するため、ストレージ・システムのスループットが減尐します。断片化したファイル・システムでは、ハード・ ディスク・ドライブ上にデータが連続して配置されている場合と比べて、ハード・ディスク・ドライブによるシーク の頻度が高くなり、シーク範囲も大きくなります。一般的に、ファイル・システムの使用時間が長いほど、断片化は 進行します。 ドライブの容量が 80%を超え始めると、断片化によるパフォーマンスの低下は顕著になります。この場合、データ を小さいフラグメントに分割しない限り、書き込みのための連続したドライブ領域を見つけることは困難になります。 ファイル・システムの断片化の状態を監視することにより、断片化を予防してください。また、使用しているファイ ル・システムに合った最適化ツールを使用して、ファイル・システムを定期的に最適化してください。 デフラグ・ツール EMC で特に推奨しているデフラグ・ツールはありません。ファイル・システムの断片化は、ストレージ・システム の動作に関係なく発生します。デフラグ・ツールのアクションは、単にストレージ・システムによる I/O として処理 されます。 デフラグ・ツールを使用する前に、ファイル・システムの安全を確保するために、完全バックアップを実行すること が賢明です。ツール・ベースのファイル・システム最適化に代わる効果的な方法としては他に、別の LUN に対して ファイル・レベルのコピーを行うことや、ファイル・システムのバックアップとリストアを実行することがあります。 ファイル・システムのアライメント ファイル・システムを RAID グループのストライピングによってアライメントすることで、遅延が減尐し、スルー プットが増加します。ただし、アライメントによる恩恵が得られるのは、特定のタイプの I/O のみです。ファイル・ システムを誤ってアライメントすると、次の 2 点でパフォーマンスに悪影響があります。 アライメントの誤りは、ドライブ・クロッシングの原因となります。 アライメントの誤りにより、キャッシュされていない大きな書き込みをストライプに合わせてアライメントする ことが困難になります。 ドライブ・クロッシングでは、1 つの I/O が 2 つのドライブに分割されます。これは、アライメントの誤りで最も多 いケースです。I/O を分割すると、所要時間が長くなります。正しくアライメントされたファイル・システムでは、 I/O が単一のドライブで迅速に処理されます。ドライブ操作がキャッシュによってバッファされている場合でも、 キャッシュからのフラッシュに時間がかかるようになり、問題が出る場合があります。性質上ドライブへのアクセス が必要なランダム・リード処理にも影響があります。直接的な影響（2 台のドライブからデータが返されるのを待機 しなければならない）と、間接的な影響（RAID グループのドライブが必要以上にビジーになる）があります。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 21 ホストのベスト・プラクティス 図 2に一般的な例を示します。Intel ベースのシステムは、BIOS によって書き込まれたメタデータのためにアライ メントが誤っています。正しくアライメントされたシステムでは、64 KB の書き込みは、単一のドライブで処理され ます。 64 KB Write Split into 31.5 KB and 32.5 KB I/Os to Disk 64 KB Element Size Disk 0 Disk 1 Disk 2 Disk 3 Metadata User Data 図2 63 ブロック・メタデータ・エリアでのアライメントの誤りの影響 ワークロードの I/O タイプとサイズを知っておくことは、アライメントのメリットを理解するうえで重要です。デー タ転送のタイプおよびサイズは、アプリケーションによって異なります。 パーティションを正しくアライメントすると、ブロック・サイズが 16 KB 以上のランダム I/O の比率が高い場合に、 レスポンス・タイムに大きなプラスの効果があります。主に 4 KB I/O が主流のワークロードでは、アライメントか ら得られるメリットはわずかです。複数のブロック・サイズをサポートするデータベース（Oracle、SQL Server、 IBM UDB/DB2）などのアプリケーションでは、大きめ（8 KB および 16 KB）のブロック・サイズを使用した場合に、 パフォーマンスにアライメントによるプラスの効果が見られます。 ストライプ・エレメント・サイズがデフォルトの 64 KB である場合、64 KB より大きいすべての I/O でドライブ・ク ロッシングが発生します。クロッシングの数を最小限にするために、パーティションをストライブ境界にアライメン トできます。特定のファイル・システムまたはアプリケーションでアライメントを調整したアドレス領域の使用が推 奨されており、また、オフセットが宣言されている場合は、ホスト・オペレーティング・システムのドライブ・ユー ティリティを使用してパーティションを調整することを推奨します。Navisphere LUN のバインド・オフセット機能 は、レイヤード・アプリケーションの同期速度に悪影響を与える場合があるため、注意して使用する必要があります。 ファイル・システムのアライメント手順 ホスト・オペレーティング・システムのファイル・システムのアライメントを実行する際の詳細および手順は、 Powerlink で参照できます。Microsoft ベースのファイル・システムについては、ホワイト・ペーパー「CX4 モデル 960 システム ハードウェアと操作方法の概要」を参照してください。VMware のアライメントについては、 「VMware ESX Server Using EMC CLARiiON Storage Systems TechBook」が適しています。Linux の場合は、まず man ページにある手順に従って fdisk ユーティリティを使用して、パーティション・テーブルをアライメントします。 Microsoft ベースのファイル・システムのアライメント・プロシージャ Microsoft Windows Server 2008 では、パーティションは OS によって 1 MB にオフセットされています。この場合の アライメントは、通常ストレージ・システムで使用される 2 の累乗のストライプ・エレメント・サイズに適していま す。また、Windows Server 2008 では、デフォルトで、小さいドライブには 2 の累乗の小さい方のオフセットが使用 されることに注意してください。 Microsoft Windows Server 2003 SP1 以降をアライメントするには、DiskPart コマンド・ユーティリティを使用し ます。ベーシック・ディスクをアライメントするには、次のように align パラメータを使用してパーティションを作成 します。 22 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ホストのベスト・プラクティス diskpart> create partition primary align = 1024 これにより、パーティションはセクタ 2048 から始まります。ドライブをアライメントしたら、NTFS フォーマット の前に、パーティションにドライブ名を割り当てます。DiskPart コマンドの使用方法については、Microsoft Windows Server 2003 または 2008 のドキュメントを参照してください。 align コマンドは、ダイナミック・ディスクには使用できません。DiskPart コマンド・ユーティリティを使用する必 要があります。 Linux ファイル・システムのアライメント・プロシージャ 以下の fdisk を使用するプロシージャでは、LUN のすべての使用可能容量を利用して、第 2 の Linux ファイル sda または sdc のファイル・システム LUN に、正しくアライメントされたパーティションが 1 つ作成されます。この例 では、次のパーティションが作成されます。 /dev/nativedevicename プロシージャは次のとおりです。 fdisk /dev/nativedevicename # sda and sdc n # 新規パーティション p # プライマリ 1 # パーティション 1 <Enter> # 第 1 シリンダ=1 <Enter> # 最終シリンダのデフォルト x # エキスパート・モード b # 開始ブロック 1 # パーティション 1 128 # ストライプ・エレメント=128 w # 書き込み Linux ファイル・システムの非常に大きい LUN のアライメント 2 TB を超える、正しくアライメントされたパーティションを作成するには、GPT（GUID パーティション・テーブ ル）ドライブ・パーティション・スキームを使用する必要があります。GPT は、EFI（Extensible Firmware Interface）イニシアティブの一部です。GPT では、従来の MBR（マスター・ブート・レコード）パーティション・ スキームより柔軟なメカニズムでドライブをパーティション化できます。 デフォルトでは、GPT パーティションは 34 ブロック分誤ってアライメントされます。Linux では、parted ユーティ リティを使用して GPT パーティションを作成およびアライメントします。 次のプロシージャは、2 TB を超えるパーティションの作成方法を説明しています。この例では、/dev/sdx という パーティションが作成されます。mkpart コマンドによって、2.35 TB のパーティションが 1 MB の開始オフセット にアライメントされます。 GPT パーティションの作成方法は次のとおりです。 # parted /dev/sdb GNU Parted 1.6.19 Using /dev/sdb パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 23 ホストのベスト・プラクティス (parted) mklabel gpt (parted) p Disk geometry for /dev/sdb:0.000-2461696.000 megabytes Disk label type:gpt Minor Start End Filesystem Name Flags (parted) mkpart primary 1 2461696 (parted) p Disk geometry for /dev/sdb:0.000-2461696.000 megabytes Disk label type:gpt Minor Start 1 End Filesystem Name Flags 1.000 2461695.983 (parted) q # mkfs.ext3 /dev/sdb1 # mkfs を使用してファイル・システムをフォーマット 可用性 PowerPath フェイルオーバーとは、I/O 障害を検出して I/O をバックアップ I/O パスに自動的に転送することです。ホスト常駐の ® EMC PowerPath ソフトウェアでは、フェイルオーバー、マルチパス I/O 機能、自動ロード・バランシング、暗号化 が統合されます。ソフトウェア更新中にホスト・アクセスを継続できるスイッチによるシングル接続システムか、ま たは完全な冗長システムかにかかわらず、OS で使用可能な場合は、PowerPath をお勧めします。 PowerPath の概要および考慮事項については、Powerlink から入手できる最新リビジョンの「EMC PowerPath Product Guide」を参照してください。 ポート・ロード・バランシング PowerPath を使用すると、ホストから複数の SP ポートを介して LUN に接続できます。これをマルチパスと呼びま す。PowerPath はロード・バランシング・アルゴリズムによりマルチパス LUN を最適化します。複数のロード・バ ランシング・アルゴリズムが提供されています。ポート・ロード・バランシングでは、使用可能なすべてのチャネル に I/O ワークロードが均等に分配されます。転送されるバイト数とキューの深さを調整するデフォルトのアルゴリズ ムである ClarOpt を推奨します。 CLARiX に接続されているホストには、マルチパスによるメリットがあります。直接接続のマルチパスには、2 つ以 上の HBA が必要です。SAN マルチパスにも 2 つ以上の HBA が必要です。HBA はそれぞれ、複数の SP ポートに ゾーニングされている必要があります。マルチパスには次の利点があります。 同一の SP でのポートからポートへのフェイルオーバーにより、均等なシステム負荷を維持。 SP ポート間およびホスト HBA 間でのポート・ロード・バランシング。 ホストからストレージ・システムへの広帯域幅による接続（使用したパスと同数の HBA がホストにあることが 前提です）。 PowerPath では、使用可能なすべてのアクティブ・パス間でのロード・バランシングが可能な一方で、次のような損 失もあります。 一部のホスト CPU リソースは、正常な運用時およびフェイルオーバー時の両方に使用される。 ホストからのアクティブ・パスおよびパッシブ・パスはすべてイニシエータ・レコードを必要とするが、イニシ エータの数はシステムごとに制限される。 24 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ホストのベスト・プラクティス アクティブ・パスは、フェイルオーバーにするまでの時間を増大させる場合がある（PowerPath は、SP から SP へと LUN をトレスパスする前に、複数のパスを試す）。 これらの要因のため、アクティブ・パスの数は、ゾーニングにより、ホストが接続された各ストレージ・システム SP の HBA ごとに 2 つのストレージ・システム・ポートに限定する必要があります。ストレージ・システム・ポート を共有する他のホストからの I/O のバーストが予測不能で、かつ深刻な問題となるような環境の場合は、例外です。 その場合は、HBA ごとに 4 つのストレージ・システム・ポートを使用する必要があります。 PowerPath の構成および使用法の詳細については、Powerlink から入手できる「EMC PowerPath Version 5.2 Product Guide」を参照してください。 その他の MPIO（マルチパス I/O）アプリケーション PowerPath 以外のアプリケーションでも、MPIO 機能を実行できます。これらのアプリケーションは、PowerPath と 同様に動作しますが、全機能を備えているわけではなく、PowerPath ほど CLARiX と密接に統合しません。 Microsoft Multi-Path I/O MS Windows Server 2008 で実装された Microsoft Multi-Path I/O（MPIO）のマルチパス機能は、PowerPath と似てい ますが、もっと制限されています。MPIO の機能には、フェイルオーバー、フェイルバック、ラウンド・ロビン・パ ス、加重パス、I/O キューの深さの管理が含まれます。使用可能な MPIO 機能およびその実装状況については、使用 している Microsoft Server OS のドキュメントを参照してください。 Linux MPIO Linux MPIO は、デバイス・マッパー（dm）で実装されます。PowerPath と類似した、ただし制限されたマルチパス 機能を提供します。デバイス・マッパーの MPIO 機能は、Linux のリリースとリビジョンによって異なります。デバ イス・マッパーの詳細および構成方法については、Powerlink から入手できる「Native Multipath Failover Based on DM-MPIO for v2.6.x Linux Kernel and EMC Storage Arrays Configuration Guide」を参照してください。 ALUA ALUA（非対称論理ユニット・アクセス）を使用すると、一部のフロントエンド障害とバックエンド障害がホストに 与える影響を緩和できます。この機能は、CLARiX ストレージ・プロセッサの一方または両方にトレスパスなしで I/O のストリーミングを許可することによってパスを管理でき、I/O ルーティングに関する SCSI SPC-3 標準に準拠し ています。ALUA の機能と利点についての詳細は、Powerlink から入手できるホワイト・ペーパー「EMC CLARiX 非 対称アクティブ/アクティブ機能（ALUA）」に記載されています。 ホストに関する考慮事項 PowerPath バージョン 5.1 以降は、ALUA 準拠のリリースです。お使いの PowerPath のバージョンが 5.1 以降である ことを確認し、ホストの準拠状況については26ページの表 1を参照してください。 PowerPath では、最適パス間でロード・バランシングが行われます。非最適パスが使用されるのは、元のすべての最 適パスで障害が発生した場合のみです。たとえば、オーナー権を持っていた SP への最適パスで障害が発生すると、 I/O は非最適パス経由でピア SP に送信されます。パスまたはストレージ・プロセッサで障害が発生すると、LUN の オーナー権を変更するためのトレスパスが開始されます。つまり、非最適パスが最適パスになり、最適パスは非最適 パスになります。 マルチパスのアプリケーションやリビジョンがすべて ALUA に準拠しているわけではありません。使用している MPIO のリビジョンまたは他のネイティブ・ホスト・ベースのフェイルオーバー・アプリケーションが ALUA と相互 運用可能であることを確認してください。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 25 ホストのベスト・プラクティス ALUA を使用できるホスト上で PowerPath を構成するときは、フェイルオーバー・モード 4 を使用します。この モードでは、CLARiX は非対称アクティブ/アクティブ操作用に構成されます。これには、LUN のオーナー権にかか わらず、I/O を LUN に送信できるというメリットがあります。フェイルオーバー・モード 1～4 のそれぞれの詳細に ついては、Powerlink から入手できるホワイト・ペーパー「EMC CLARiiON Asymmetric Active/Active Feature (ALUA) -- A Detailed Review」を参照してください。 OS に関する考慮事項 ALUA の機能を利用するには、ホスト・ソフトウェアが ALUA に準拠していることが必要です。A/P（アクティブ/ パッシブ）コントローラによるネイティブ・フェイルオーバーは、複数のオペレーティング・システムによってサ ポートされています。表 1に、一般的なオペレーティング・システムの現在の ALUA 準拠状況を示します。 表1 ALUA とアクティブ/パッシブ・フェイルオーバー準拠の OS オペレーティング・システム PowerPath と ALUA Native と ALUA PowerPath と A/P Native と A/P MS Windows Server 2008 ○ ○ ○ × W2K3 PP 5.1 以降 × ○ × Win2K PP 5.1 以降 × ○ × HP-UX 11i v1 および v2 PP 5.1.1 以降 × ○ ○（LVM） HP-UX 11i v3 PP 5.1.1 以降 ○ × × Solaris 9/10 PP 5.1 以降 ○ ○ ○ Linux（RH および SuSE） ○ SLES 10 SP1 RHEL 4.6、5.4 ○ ○ AIX × × ○ AIX 5.3 以上 VMware ESX 3.x VMware ESX 4.x × × ○ × ○ ○ PP/VE 5.4 以降 PP/VE 5.4 以降 PowerPath と ALUA：ALUA 機能は、特定の PowerPath リリースを各オペレーティング・システムとともに使用し たときに提供されます。 Native と ALUA：ALUA 機能は、各オペレーティング・システムを単独で使用したときに提供されます（PowerPath は必須ではありません）。 PowerPath と A/P：標準のアクティブ/パッシブ・フェイルオーバー（ALUA ではない）は、PowerPath を各オペ レーティング・システムとともに使用したときに提供されます（PowerPath は、trespass コマンドを発行して SP LUN のオーナー権を変更することによって、代替パスを有効にします）。 Native と A/P：標準のアクティブ/パッシブ・フェイルオーバー（ALUA ではない）は、各オペレーティング・シス テムを単独で使用したときに提供されます（OS は、trespass コマンドを発行して代替パスを有効にします）。 パフォーマンスに関する考慮事項 最適パスは、通常の運用に使用されるパスです。最適パスのパフォーマンスは、ALUA の影響を受けません。 パフォーマンスが影響を受けるのは、非最適パスです。 非最適パスを介して受信したホスト I/O 要求は、ターゲット LUN のオーナー権を持たないストレージ・プロセッサ によって受け取られます。次に、これらの要求は、LUN のオーナー権を持つピア・ストレージ・プロセッサに転送 されます。オーナー権を持つストレージ・プロセッサは、要求を直接受け取ったかのように I/O を実行します。I/O が完了すると、データまたは ACK がピア経由で転送され、ホストに返されます。 26 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ホストのベスト・プラクティス ストレージ・プロセッサからピア・ストレージ・プロセッサへ、またその逆のリダイレクトは、I/O レスポンス・タ イムを悪化させます。遅延の長さは、ストレージ・システムとストレージ・プロセッサの全般的なワークロード、お よび I/O のサイズによって異なります。非最適パスを使用した場合、最大 IOPS は 10～20%低下し、帯域幅は最大 50%減尐します。 ALUA パフォーマンスの監視 最適パス経由で受け取った要求と非最適パス経由で受け取った要求の統計をとるためのパフォーマンス値が、多数創 られています。これらのパスの使用状況は、Navisphere Analyzer を使用して監視できます。また、あらゆるパス上 の全 I/O を監視するパフォーマンス値もあります。これらのパフォーマンス値からは、パスの使用率とパフォーマン スの差異を把握できます。Navisphere Analyzer の使用方法については、Powerlink から入手できる「EMC Navisphere Analyzer Administrator’s Guide」を参照してください。 キューイング、コンカレンシー、queue-full（QFULL） 通常、リクエストのコンカレンシーが高いことは望ましく、高いリソース使用率につながります。ただし、ストレー ジ・システムのキューが一杯になると、queue-full（QFULL）フロー制御コマンドが返されます。CX4 フロント エンドのポート・ドライバでは次の 2 つの状態において QFULL ステータス・コマンドが返されます。 ポートでのコンカレント・ホスト・リクエストの事実上の最大数が 1600（ポート・キューの上限）を超えた場合。 特定の LUN のリクエストの合計数が（14×（LUN 内のデータ・ドライブの数））+ 32 の場合。 QFULL に対するホストの応答は HBA によって異なりますが、通常はアクティビティが 1 秒以上中断されます。これ が繰り返し発生した場合、スループットに重大な影響を与えることがまれにあります。 ベスト・プラクティスである 1600 というポート・キューの制限で、バースト・マージンは十分です。ほとんどの設 置環境では、ポートにアクセスする各 HBA の負荷を合計し、HBA LUN の設定を適切に調整することにより、最大負 荷が決定されます（一部のオペレーティング・システム・ドライバでは、個々の LUN 設定に関係なく、グローバ ル・レベルで HBA コンカレンシーを制限することができます）。多数のホスト、HBA、LUN、およびパスで構成さ れる複雑なシステムでは、負荷シナリオの最悪ケース（本番環境で発生する可能性はほとんどありません）を計算す ることが困難な場合があります。この場合、HBA にはデフォルト設定を使用し、QFULL 状態の可能性がある場合は、 Navisphere Analyzer（リリース 24 以降）を使用して、次の手順に従いシステムのキューが一杯であるかどうかを判 断します。Navisphere Analyzer の使用方法については、「EMC Navisphere Analyzer Administrator’s Guide」を参照 してください。 HBA のキューの深さを設定すると、通常は、LUN によって QFULL が発生する可能性が排除されます。たとえば、 RAID 5（4+1）デバイスでは、ポートで QFULL が発行される前に 88 個のパラレル・リクエスト（（14×4）+32） が必要です。HBA のキューの深さの設定が 32 の場合、制限値に到達することはありません。一般的な例外には RAID 1（または RAID 1/0（1+1））があります。たとえば、HBA のキューの深さのデフォルト設定が、同じホスト が所有する大きな metaLUN 用のさらに大きいコンカレンシーをサポートするために大きい値（64 など）に変更され た場合、RAID 1 デバイスは 46 リクエスト（（1×14）+32）に限定されているため、queue-full 状態に達する可能性 があります。 ドライブのキューの深さの結果として QFULL が発生することはありません。 ポートの統計は Navisphere Analyzer 用に収集されます。このデータには SP 上の個々のポートについて役立つ統計 がいくつか含まれています。 Port queue-full – ポートのキューのオーバーフロー（約 2048 リクエスト）に起因して発行された QFULL 信号の 数を示すカウンタが追加されました。 1 ポートあたりの帯域幅と IOPS パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 27 ホストのベスト・プラクティス 用途 ストレージ・システムに接続されているすべてのホスト、およびそれらがアクセスする LUN を考慮してください。 必要に応じて HBA スロットルを設定し、各 LUN へのコンカレント・リクエストを制限してください。オペレー ティング・システムによっては、HBA あたり、またはターゲットあたりの未処理のリクエスト数合計をグローバル に制限することができます。合計がポートのキューの制限値を超えないように、ポートを共有するホストの HBA ス ロットルを設定します。同じ SP 上の複数のポートを介した 1 つの LUN へのマルチパスでは、ポートのキューの制 限値を超える場合があることを覚えておいてください。 コンカレンシーが高い可能性があり、パフォーマンス上の問題が発生する場合は、Navisphere Analyzer で報告され るポート統計で queue-full がないか確認し、必要に応じて HBA スロットルを減らしてください。 ストレージ・ネットワーク・アダプタと HBA ホストは、ファイバ・チャネル HBA を使用してファイバ・チャネル・ストレージ・ネットワークに接続します。 NIC（ネットワーク・インタフェース・カード）、iSCSI HBA、TOE（TCP/IP オフロード・エンジン）と iSCSI ドラ イバによって、ホストは iSCSI ストレージ・ネットワークをサポートするために Ethernet ネットワークに接続しま す。HBA、NIC、TOE は、ホストの I/O バス帯域幅を共有します。 ホスト・バス ネットワーク・アダプタの全帯域幅がホストの I/O バス・ハードウェアでサポートされていることを確認してくださ い（ホストの I/O バスは、周辺バスと呼ばれることもあります）。ホストのバスの数、分布、速度を知っておくこと は、ホスト内のボトルネックを回避するうえで重要です。 4 Gb 以上の速度のファイバ・チャネルと 10 Gb の Ethernet ネットワーク・アダプタを使用できる場合は、小規模な 従来のホストの I/O バス帯域幅をネットワーク・アダプタより小さくすることができます。また、ホスト I/O バス上 に複数のアダプタが存在する場合、これらのアダプタは使用可能なバス帯域幅を共有します。アダプタに必要な帯域 幅の合計が、ホストで使用可能なバス帯域幅を超える場合があります。 ネットワーク・アダプタのポートとバスの比率を知っておく必要があります。1 つのホストで複数の内部バスを使用 できます。ネットワーク・アダプタを受け入れるバス・スロットのバスへの分配方法は、必ずしも明確ではありま せん。ネットワーク・アダプタの数と、ホストの個々のバスにそれぞれ接続されているネットワーク・アダプタごと のポート数を確認してください。ネットワーク・アダプタは、高速（66 MHz 超）で幅広い（64 ビット）PCI、PCI-X、 および 4 レーン（x4）以上の PCI Express（PCIe）1.1 または 2.0 のホスト・バスに接続されます。どのような場合 も、ボトルネックを避けるために、ホスト I/O バスの帯域幅は、ネットワーク・アダプタの最大帯域幅の合計より大 きくする必要があります。 HBA 可用性を高めるためには、2 つの HBA 接続を使用して、ストレージ・ネットワークへ、または直接接続の場合はス トレージ・システムへ、デュアル・パスを提供する必要があります。 冗長 HBA を使用することはベスト・プラクティスの 1 つです。マルチポート（デュアルまたはクワッド）または複 数のシングル・ポート HBA を使用できます。複数のシングル・ポート HBA を使用すると、ポートやパスの障害を切 り分けることができ、パフォーマンスが向上する場合があります。マルチポート HBA を使用すると、コンポーネン トのコストが軽減され、ポートを効率的に管理できます。これによってパフォーマンスが向上する場合があります。 たとえば、マルチポート HBA は、使用可能な I/O バス・スロットの尐ないホストに便利です。マイナス面は、マル チポート HBA が複数のポートに対する単一障害点となることです。シングル・ポート HBA では、障害が発生しても 影響を受けるのは 1 つのポートだけです。HBA は、パフォーマンスと可用性を確保するために、別個のホスト・バ スに配置する必要もあります。バスが 1 個だけ、またはバス・スロットの数が限られている小規模なホストの場合は、 これが不可能なこともあります。この場合は、マルチポート HBA が唯一の選択肢となります。 28 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ホストのベスト・プラクティス 必ず、ストレージ・ネットワークの最大帯域幅以上の速度の HBA を使用してください。従来の 1 Gb/秒または 2 Gb/秒 の HBA を、4 Gb/秒以上の SAN への接続に使用しないでください。FC SAN を使用すると、ネットワーク・パスの 速度が、HBA の最初に接続されたスイッチか、直接接続した場合のストレージ・システムのフロントエンド・ポー トのいずれか遅い方の速度まで低下します。帯域幅を最大にする場合は、これによってネットワーク全体のボトル ネックとなることがあります。 最後に、一般的には製造元の最新の HBA ファームウェアおよびドライバを使用すると、パフォーマンスと可用性に プラスの効果があります。各ストレージ・システムに固有の HBA の手順および構成設定については、「CLARiiON Procedure Generator」（Powerlink からインストール可能）を参照してください。 NIC（ネットワーク・インタフェース・カード）、TOE（TCP/IP オフロード・エンジン）、iSCSI HBA（ホスト・ バス・アダプタ） NIC、TOE、iSCSI HBA の 3 つのホスト・デバイスによって、ホストは iSCSI SAN に接続されます。各デバイスの 違いとして、コスト、ホスト CPU の利用率、機能（セキュリティなど）が挙げられます。同じサーバで、iSCSI ス トレージ・システムへのパスに NIC と HBA の両方を使用することはできません。 NIC は、ホストを Ethernet ネットワークに接続する典型的な方法です。ホスト上でソフトウェア iSCSI イニシエー タによってサポートされています。 Ethernet ネットワークでは、共通デバイスの最低速度が自動検知されます。低速の NIC を使用すると、ストレージ・ ネットワークの帯域幅にボトルネックが発生する場合があります。可能な場合は、使用可能な Ethernet ネットワー クの帯域幅以上の速度の NIC を使用してください。従来の 10 Mb/秒または 100 Mb/秒の NIC は、1 Gb/秒以上の Ethernet ネットワークへの iSCSI SAN 接続には使用しないでください。 TOE は、より高速な NIC です。TOE には、TCP パケットの区分化、チェックサムの計算、またオプションでホスト CPU から自身への IPSec（セキュリティ）オフロードを処理するための、オンボード・プロセッサが含まれていま す。これにより、ホスト CPU を、アプリケーション処理専用に使用できます。 一般的に、iSCSI HBA は、最も拡張性の高いインタフェースです。iSCSI HBA では、TCP/IP および iSCSI の処理は HBA にオフロードされます。これによってホスト CPU の利用率が低減されます。iSCSI HBA では、iSCSI ターゲッ トをブート・オフすることもできます。これは、ディスクレスのホスト起動を検討する際に重要な考慮事項です。 HBA は、通常はセキュリティなど追加のサービスにも対応します。 iSCSI HBA、TOE、NIC のうちどれを使用するかは、ワークロードを処理する際のホストの CPU の利用率によって 決まります。小規模なホストや、CPU の利用率が高いホストでは、TOE または iSCSI HBA を使用すると、ホストの CPU の利用率を下げることができます。ただし、HBA や TOE を使用すると、ワークロードのレスポンス・タイムが 長くなる場合があります。また、iSCSI HBA や TOE は、通常の NIC に比べてコストがかかります。大規模なホスト や、CPU の利用率が高くても影響を受けないホストでは、通常の NIC をお勧めします。iSCSI SAN では、ホスト上 の iSCSI プロトコルをサポートする NIC を使用する必要があります。適切なドライバのサポートについては、NIC の 製造元に確認してください。 可用性を確保するためには、冗長な NIC、iSCSI HBA、TOE を使用する必要があります。NIC は、シングル・ポート でもマルチポートでも構いません。マルチポート NIC または複数の NIC を使用しているホストを、マルチホーム・ ホストと呼びます。通常、NIC または NIC ポートはそれぞれ、別々のサブネット上に構成されます。理想的には、複 数の NIC をプロビジョニングする場合は、それぞれ別々のホスト・バスに配置する必要があります。バスが 1 個だ け、またはバス・スロットの数が限られている小規模なホストの場合や、オンボード・ホスト NIC が使用されている 場合は、これが不可能なこともあります。 すべての NIC でパフォーマンス・レベルが同じとは限りません。このことは、ホスト・オンボード（メインボード） の NIC、10 Gb/秒の NIC、10 Gb/秒の HBA に特に当てはまります。互換性に関する最新情報については、ELN（ELab Interoperability Navigator、http://elabnavigator.EMC.com）から入手できる「EMC サポート・マトリックス」 （ESM）を参照してください。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 29 ホストのベスト・プラクティス 最後に、製造元の最新の iSCSI イニシエータ、NIC、TOE、iSCSI HBA ファームウェアおよびドライバを使用すると、 パフォーマンスと可用性にプラスの効果があります。各ストレージ・システムに固有の NIC と TOE の手順および構 成設定については、「CLARiiON Procedure Generator」（Powerlink からインストール可能）を参照してください。 30 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ホストのベスト・プラクティス パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 31 ホストのベスト・プラクティス 第3章 ネットワークのベスト・ プラクティス ネットワークのベスト・プラクティスでは、ホストをストレージ・システムに接続している iSCSI およびファイバ・ チャネルのネットワーク・インフラストラクチャのソフトウェアおよびハードウェアの構成と、それらがストレー ジ・システム全体のパフォーマンスおよび可用性に与える影響について説明します。 ストレージ・システム・ネットワークの概要およびネットワーク・パフォーマンスの考慮事項については、Powerlink から入手できる「EMC Networked Storage Topology Guide」を参照してください。 パフォーマンス iSCSI LAN ジャンボ・フレーム ネットワークでサポートされている場合は、ジャンボ・フレームを使用して帯域幅を拡大することをお勧めします。 ジャンボ・フレームには、断片化なしで（ペイロード・サイズによっては尐量の断片化で）通常のフレームに比べて 多くの iSCSI コマンドと大きい iSCSI ペイロードを含めることができます。ジャンボ・フレームを使用する場合は、 ストレージ・システムへのパスにあるすべてのスイッチおよびルータがジャンボ・フレームをサポートし、処理でき る必要があり、また、ジャンボ・フレーム用に構成する必要があります。 iSCSI 使用上の注意 iSCSI の使用には、次の一般的な推奨事項が適用されます。 高性能リモート・レプリケーションなど、広帯域幅が必要なアプリケーションには、iSCSI は推奨されません。 可能な場合はストレージ・トラフィックに専用の LAN を使用するか、ストレージ・トラフィックを独自の仮想 LAN（VLAN）に分離してください。 ホストには、EMC によってサポートされる iSCSI イニシエータの最新バージョン、および最新バージョンの NIC ドライバを使用してください。 イニシエータからターゲットまでのパスにあるすべてのネットワーク・デバイスで、iSCSI 1 Gb/秒（GigE） ポートおよび 10 Gb/秒（10 GigE）ポートを Ethernet 全二重に合わせて構成してください。 イニシエータからターゲットまでのパスではできるだけ CAT6 ケーブルを使用することにより、GigE および 10 GigE の Ethernet 速度での動作の整合性を確保してください。 長距離の転送または低電源のサーバを含むネットワークでは、ジャンボ・フレームおよび TCP フロー制御を使 用してください。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 33 ネットワークのベスト・プラクティス 広帯域幅の読み取りワークロードには、SP iSCSI ポートと GigE SAN 上の NIC の割合として 1:1 を使用してく ださい。10 GigE SAN では、iSCSI ポートの NIC に対する割合をもっと高くできます。 ホストへの Ethernet 接続が、ホスト NIC の帯域幅以上の速度であることを確認してください。 CLARiX への Ethernet 接続が、CLARiX の iSCSI FlexPort の帯域幅以上の速度であることを確認してください。 ネットワーク遅延 帯域幅とスループットの速度は、ネットワークの状態および遅延によって異なります。 ネットワーク競合、非効率なルーティング、VLAN の構成ミスなどが iSCSI のパフォーマンスに悪影響を与えること がよくあります。最善の iSCSI 接続と SAN パフォーマンスを確保するためには、iSCSI トラフィックを扱うネット ワークをプロファイルし、継続的に監視することが重要です。一般的には、単純なネットワーク・トポロジーが最高 のパフォーマンスを提供します。 遅延は、iSCSI システム・パフォーマンスに大きく影響する場合があります。ホストから CLARiX までの距離が増す と、200 km（125 マイル）につき約 1 ミリ秒の遅延が発生します。この遅延は、シーケンシャル I/O ワークロードを サポートする WAN に顕著な影響を及ぼします。たとえば、40 MB/秒、64 KB の単一のストリームは 200 km の距離 では平均 25 MB/秒になります。これら長距離のシーケンシャル I/O ワークロードで最大の帯域幅を維持するには、 ストリームの数を増やすことをお勧めします。 可用性 FC SAN ホストとストレージ・システムの間にデュアル・パスまたはマルチパスが必要です。これには、冗長 HBA、堅牢な ファブリック実装、管理のポリシーおよび手順に厳密に従うこと、ストレージ・システムへのデュアル接続が含まれ ます。PowerPath のようなパス管理ソフトウェアと、ホスト上のダイナミック・マルチパス・ソフトウェア（代替パ スへのフェイルオーバーとロード・バランシングを可能にするため）を推奨します。 デバイスのファン・インのために、テープなど狭帯域幅のデバイスや、使用率が低く、古くて低速のホストは、エッ ジ・スイッチまたはダイレクタ・ブレードに接続してください。 iSCSI LAN 冗長性と構成 ホストとストレージ・システムの冗長な通信を確保するために、デュアル Ethernet ネットワークをお勧めします。 分離 iSCSI トラフィックには専用のストレージ・ネットワークを使用することをお勧めします。専用のストレージ・ネッ トワークを使用しない場合は、iSCSI トラフィックを別の物理 LAN、別の LAN セグメント、仮想 LAN（VLAN）のい ずれかに分離する必要があります。 Ethernet インフラストラクチャの複数の物理 LAN とは対照的に、VLAN では、複数の仮想 LAN を作成できます。こ れにより、情報の論理的な分離を維持しながら、複数のネットワークで同じ物理ネットワークを共有できます。FLARE リリース 29.0 以降では、1 Gb/秒および 10 Gb/秒の iSCSI インタフェースで VLAN タグ機能（IEEE 802.1q）がサ ポートされています。Ethernet のスイッチ・ベースの VLAN は、FLARE のすべてのリビジョンでサポートされてい ます。 互換性のあるネットワーク・スイッチをサポートする VLAN タグ機能により、iSCSI トラフィックは通常の LAN ト ラフィックと分離されます。これにより、ブロードキャスト・ドメインの範囲が縮小するため、SAN のパフォー マンスが向上します。VLAN および VLAN タグ機能の詳細については、Powerlink から入手できるホワイト・ペー パー「VLAN Tagging and Routing on EMC CLARiiON」を参照してください。 34 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ネットワークのベスト・プラクティス 次の表は、iSCSI ごとにアクティブにすることのできる VLAN の数を示しています。 表2 iSCSI ポートごとの VLAN の最大数 iSCSI ポートごとの VLAN の最大数 iSCSI FlexPort の速度 VLAN の最大数 1 Gb/秒 2 10 Gb/秒 8 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 35 ネットワークのベスト・プラクティス 36 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ホストのベスト・プラクティス 第4章 ストレージ・システムの ベスト・プラクティス ストレージ・システムのベスト・プラクティスでは、CLARiX CX4 シリーズおよび AX4 シリーズのストレージ・シ ステムのソフトウェアおよびハードウェアの構成と、それらがストレージ・システム全体のパフォーマンスおよび可 用性に与える影響について説明します。 ストレージ・システムの概要については、ホワイト・ペーパー「UltraFlex テクノロジーを実装した EMC CLARiX CX4 シリーズの概要」を参照してください。 パフォーマンス フロントエンド・ポート CX4 シリーズの全モデルに、iSCSI と FC の両方のフロントエンド・ポートが付随しています。フロントエンド・ ポートは、UltraFlex I/O モジュールに配置されています。各モジュールには、同じタイプ（iSCSI または FC）のポー トが 2 つ以上あります。 iSCSI ポート すべての CX4 モデルで、最大 1 Gb/秒で動作する GigE iSCSI ポートが、標準構成の一部として提供されています。 iSCSI 通信で IOPS を最大化するには、10 GigE iSCSI ポートを、より高速の 10 Gb/秒の Ethernet ネットワークに接 続します。10 GigE iSCSI ポートはアップグレードとして入手できます。10 GigE iSCSI ポートは FLARE 29.0 以降 でサポートされています（詳細については、「ネットワークのベスト・プラクティス」の章を参照）。 GigE iSCSI ポートは、銅線ケーブルで接続します。CAT6 を推奨します。10 GigE iSCSI ポートは、オプティカル・ ケーブルで接続します。フル・スピードで動作させるには、50 m 以下でショートウェーブ・オプティカル OM2、 380 m 未満で OM3 を推奨します。 iSCSI フロントエンド・ポートは、Ethernet のすべての速度を自動検知することはできません。CLARiX iSCSI ポー トでは、10 Mb/秒の接続はサポートされていません。Ethernet ストレージ・ネットワークのインフラストラクチャが 100 Mb/秒のスイッチとコンポーネントを使用して設計されている場合は、GigE ポートは 100 Mb/秒で動作します。 10 GigE iSCSI ポートは、自動検知で速度が低下することはなく、10 Gb/秒でのみ動作します。Ethernet の速度と構 成のサポート状況については、ESM を確認してください。 ストレージ・システムは、あるホストの iSCSI ポートと別のホストのファイバ・チャネル・ポートに同時に接続でき ます。ただし、1 つのストレージ・システムを、単一のホストのファイバ・チャネル・データ・ポートと iSCSI デー タ・ポートに接続することはできません。また、NIC と iSCSI HBA の両方を使用して、サーバを同じストレージ・ システムに接続することもできません。これらのポートとその機能の詳細については、ホワイト・ペーパー「Best Practice Considerations for CLARiiON CX3 FC/iSCSI Storage Systems」を参照してください。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 37 ストレージ・システムのベスト・プラクティス iSCSI 処理には、ファイバ・チャネル処理よりも多くの SP CPU リソースが必要です。ワークロードが、キャッ シュ・ヒット率の高い小さい I/O リクエストで構成されている場合、SP CPU の利用率が高くなる可能性があります。 このことは、10 GigE iSCSI に特に該当します。トランザクション・レートが最大級のワークロードには、ファイ バ・チャネル接続をお勧めします。 CX4 シリーズのモデルには、それぞれ 2 つ以上の GigE UltraFlex iSCSI I/O コントローラ・モジュールが、SP 1 つに つき 1 つずつ備えられています。1 つの UltraFlex iSCSI コントローラで 2 つの iSCSI ポートを動作させます。この 2 つのポートは、コントローラの総帯域幅と IOPS を共有します。両方のポートを同時に使用した場合、書き込み帯域 幅は、ポート間で均等には共有されません。次の表は、iSCSI ポートで使用可能な IOPS と帯域幅を示しています。 表3 iSCSI ポートの帯域幅と IOPS GigE iSCSI 両方のポート 単一のポート 読み取り 220 110 書き込み 158 110 読み取り 30,000 15,000 書き込み 15,000 11,000 帯域幅（MB/秒） IOPS GigE iSCSI 読み取りの場合、コントローラは、最大 Gb/秒の帯域幅まで両方のポートを同時に動作させることができます。書き 込みの場合は異なります。両方のポートがアクティブなとき、ポートごとに使用可能な書き込み帯域幅は、単一ポー トの速度の倍ではありません。 64k より大きいサイズの iSCSI I/O を処理するときは、ホストとネットワーク、またはストレージ・システムの実装 方法によって制限が課される場合があります。iSCSI パフォーマンスはブロック・サイズとワークロードによって決 定されます。1 Gb/秒のネットワーク上の大きなブロックおよびシーケンシャル・ワークロードの場合、帯域幅は iSCSI ポートごとに約 100 MB/秒のポートの機能によって制限されます。ドライブが 240 台の RAID 5（CX4-240 と CX4-480、SP 1 つにつき iSCSI ポート 2 つ）上で読み取りと書き込みの比率が 2:1 の小さいブロックのランダム・ ワークロードの場合、iSCSI ポートは約 20,000 のフロントエンド IOPS に直線的に拡張します。iSCSI のスループッ トは、この範囲で FC のパフォーマンスに従います。ドライブが 120 台の CX4-120 は、この範囲の中間に位置しま す。十分な数のドライブでドライブのボトルネックが回避される場合、SP 1 つあたり iSCSI ポート 3 つの CX4-960 は、約 30,000 のフロントエンド IOPS に直線的に拡張します。さらに高速にするためには、FC 接続を使用すること をお勧めします。帯域幅のワークロードが大きくなると予測される場合は、ファイバ・チャネルを使用してください。 10 GigE iSCSI 10 Gb/秒の iSCSI ポートでは、1 Gb/秒のポートより多くの IOPS が提供されます。また、より多くの VLAN ポート がサポートされます。これらのポートは、多数の iSCSI ホストで単一のポートを共有する場合に便利です。広帯域幅 のワークロードの場合は、8 Gb/秒のファイバ・チャネル・フロントエンド・ポートを使用することをお勧めします。 追加ポート すべてのモデルで、追加の iSCSI ポートを構成できます。iSCSI ポートを追加すると、構成可能なファイバ・チャネ ル・ポートの数が減尐します。 38 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス 表4 CX4 の SP ごとの iSCSI ポート最大数 iSCSI ポートの最大数 CX4-120 CX4-240 CX4-480 CX4-960 GigE のみ 8 12 12 16 GigE と 10 GigE 4 6 6 6 または 8 GigE のみ 2 2 4 4 用途 最高のパフォーマンスを達成するためには、すべてのフロントエンド・ポートで負荷を均等に分散してください。本 番ワークロードの場合、ストレージ・システムのポートのフロントエンド帯域幅は、両方の SP でほぼ同じにするこ とが理想的です。ワークロードの帯域幅のニーズを両方の SP 間で分割すると、SP 使用率が減尐します。この結果、 レスポンス・タイムが短縮されます。帯域幅のバランスを調整するには、SP 間で LUN をトレスパスするか、ホスト にフロントエンド接続を追加することが必要な場合があります。可用性を高めるためには、ストレージ・システム上 の各 SP に対してホストからのフロントエンド・ポート接続が常に 1 つ以上ある状態にする必要があります。 ポートの追加は、より広い範囲の構成においてストレージ・システムの帯域幅のパフォーマンスを最大限にするため に役立ちます。メモリの帯域幅は同じままなので、以前の SP の最大値は増加しません（詳細については、42ページ の表 8を参照）。 小さなブロックのランダム・ワークロードの場合、追加のバスとポートがあってもパフォーマンスに違いが生じるこ とはほとんどありません。 FC ポート すべての CX4 モデルで、最大 4 Gb/秒で動作するファイバ・チャネル・ポートが、構成の一部として提供されていま す。8 Gb/秒の UltraFlex ファイバ・チャネル・ポートは、アップグレードとして入手できます。8 Gb/秒のポートを インストールするには、FLARE リビジョン 29.0 以降が必要です。 ファイバ・チャネル・ポートを 4 Gb/秒以上の速度の SAN に接続することにより、使用可能な帯域幅を最大化でき ます（「ネットワークのベスト・プラクティス」の章を参照）。 ファイバ・チャネル・ホストと iSCSI ホストへの接続は、同時にサポートされます。ただし、1 つのホストは、1 つ のストレージ・システムの FC ポートか iSCSI ポートのいずれかにのみ接続できます。両方のタイプに同時に接続す ることはできません。これらのポートとその機能の詳細については、ホワイト・ペーパー「Best Practice Considerations for CLARiiON CX3 FC/iSCSI Storage Systems」を参照してください。 すべての CX4 モデルに、SP 1 つにつき 2 つ以上のファイバ・チャネル・ポートがあります。また、追加オプション として、ポートを追加できます。ホストのフロントエンド接続を追加すると、ストレージ・ネットワークで必要な ファイバ・チャネル・スイッチの数を減らすことができます。使用可能な帯域幅はすべて全ポートに分散する必要が あります。可用性を高めるためには、ストレージ・システムのピア SP に対してホストからのフロントエンド FC ポート接続が常に 1 つ以上ある状態にする必要があります。 FC ポートの帯域幅を最大限に活用するには、4 Gb/秒以上の速度の FC SAN が必要です。標準の CX4 FC ポートの帯 域幅機能は次のとおりです。 表5 ファイバ・チャネル・ポートの帯域幅 FC ポートの速度 FC ポートあたりの 帯域幅（MB/秒） 4 Gb/秒 360 8 Gb/秒 700 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 39 ストレージ・システムのベスト・プラクティス 用途 8 Gb/秒のファイバ・チャネル・フロントエンド・ポートでは広帯域幅を使用できることに注目してください。8 Gb/秒 のフロントエンド・ポートを使用すると、ストレージ・システムに接続する SAN スイッチ・ポートの数を減らすこ とができます。たとえば、4 Gb/秒のフロントエンド・ポート 2 つを結合して 1 つの 8 Gb/秒ポートにすることができ ます。この 1 つのポートで、約 1400 GB/秒の全二重処理が可能です。全二重では、デュアル 8 Gb/秒チャネル・モ ジュールの両方のポートを最大の帯域幅でアクティブにすることはできません。 4 Gb/秒のポートを 1 Gb/秒または 2 Gb/秒の FC インフラストラクチャを持つ SAN に接続すると、CX4 の 4 Gb/秒の FC ポートはその速度で動作します。8 Gb/秒の FC ポートは、2 または 4 Gb/秒の FC SAN に接続した状態では、帯 域幅のパフォーマンスが低下します。8 Gb/秒の FC ポートは、自動検知によって 1 Gb/秒に低下することはありません。 追加のファイバ・チャネル・ポート すべてのモデルで、追加のファイバ・チャネル・ポートを構成できます。ファイバ・チャネル・ポートを追加すると、 構成可能な iSCSI ポートの数が減尐します。CX4-960 を除くすべての CX4 モデル上のバックエンド・ポートの数は 固定されています。表 8に詳細を示します。 表 6は、SP 1 つあたりのフロントエンド・ファイバ・チャネル・ポートの最大数を示しています。たとえば、CX4-480 フロントエンド FC ポートの最大数は 12 です。この最大値は、1 つの SP 上で 8 Gb FC フロントエンド・ポート 4 つと 4 Gb フロントエンド FC ポート 8 つを組み合わせた場合です。 表6 SP 1 つあたりのファイバ チャネル ポートの最大数 FC ポートの 最大数 CX4-120 CX4-240 CX4-480 CX4-960 12 8 12 16 または 20* * CX4-960 ドライブ拡張イネーブラをインストールした場合 拡張例は、ポートの追加を説明する際に役立つ場合があります。CX4-480 には、SP ごとに UltraFlex I/O スロットが 5 つずつあります。この最大構成では、各 SP 上で、5 つの使用可能な UltraFlex I/O スロットのうち 4 つが一杯にな るだけです。 ベースライン構成では、SP 1 つにつき 3 つの I/O スロットが使用されます。ベースラインの CX4-480 は、8 つのフ ロントエンド FC ポート（SP 1 つにつき 4 つ）、8 つのバックエンド FC ポート（SP 1 つにつき 4 つ）、4 つのフ ロントエンド iSCSI ポート（SP 1 つに付き 2 つ）で構成されます。この構成では、4 つの I/O スロット（SP 1 つに つき 2 つ）を CX4-480 の最大構成である 12 個の FC ポートに拡張可能です。ベースライン構成には、最大構成であ る 8 つの FC バックエンド・ポート（SP 1 つにつき 4 つ）がすでに含まれています。 2 つの空きスロットそれぞれに、追加の FC ポートを 4 つずつ取り付けることができます。これにより、CX4-480 は、 最大の FC ポート構成（ベースラインの 8 つのフロントエンド FC ポート（SP 1 つにつき 4 つ）と、アドインとして SP ごとに 8 つの追加 FC フロントエンド・ポートの、合計 24 個の FC フロントエンド・ポート（SP 1 つにつき 12 個）） で構成されます。表 7に、最終構成を示します。この表に示すのは、最大限にプロビジョニングされたストレージ・ システムではないことに注意してください。 40 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス 表7 16 個の FC フロントエンド・ポートの CX4-480 ストレージ・プロセッサ EMC の CX4 ラインのストレージ・システムは、容量と機能が前の世代とは異なります。一般的に、次のような違い があります。 SP CPU が高速のマルチコアになり、キャッシュ・メモリが増加 メイン・メモリが増加 サポート対象のハード・ディスク・ドライブ数が増加 新しい大容量のファイバ・チャネル・ハード・ディスク・ドライブ、大容量でエネルギー効率の高い SATA ハー ド・ディスク・ドライブ、ソリッド・ステート EFD ハード・ディスク・ドライブをサポート 4 Gb/秒のファイバ・チャネル、1 Gb/秒の iSCSI ポートを標準とし、8 Gb/秒のファイバ・チャネルや 10 Gb/秒 の iSCSI へのアップグレードを含む複数の構成オプション ほとんどのモデルに複数の 4 Gb/秒のファイバ・チャネル・バックエンド・バス（CX4-120 は例外） CX4 ファミリのストレージ・プロセッサの特性を表 8に示します。モデル・ベースの依存性を持つ機能を解決するに は、この表を参照してください。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 41 ストレージ・システムのベスト・プラクティス 表8 CX4 ファミリの特性 コンポーネント/接続 CX4-120 CX4-240 CX4-480 CX4-960 SP ごとのプロセッサ・ 1 アーキテクチャ デュアル・コア・ プロセッサ 1.2 GHz×1 デュアル・コア・ プロセッサ 1.6 GHz×1 デュアル・コア・ プロセッサ 2.2 GHz×1 クワッド・コア・ プロセッサ 2.33 GHz×2 SP あたりの物理メモリ 3 GB 4 GB 8 GB 16 GB SP あたりのバックエンド 2 4-Gb/秒の FC ポート数 1 2 4 4 または 8 ストレージ・システムあたり の最大ドライブ数 120 240 480 960 ストレージ・システムあたり の最小ドライブ数 5 5 5 5 ストレージ・システムあたり の最大ホット・スペア数 115 235 475 955 ストレージ・システムあたり の最大イニシエータ数 512 1024 2048 8192 ストレージ・システムあたり の最大 H/A ホスト数 128 256 256 512 ストレージ・システムあたり の最大 LUN 数 1024 2048 4096 8192 ストレージ・システムあたり の最大 RAID グループ数 60 120 240 480 RAID グループあたりの最大 ドライブ数 16 16 16 16 RAID グループあたりの最大 LUN 数 512 512 512 512 3 書き込みキャッシュの構成 CLARiX のキャッシュは、高度に構成可能です。読み取りキャッシュと書き込みキャッシュの割り当ては、個々のワー クロードのパフォーマンスが最適になるように調整できます。CX4 シリーズには、以前の CLARiX より大容量の キャッシュがあります。 読み取りキャッシュと書き込みキャッシュに使用できる SP メモリの量は、CLARiX のモデルによって異なります。 パフォーマンスを最適にするには、キャッシュに使用可能なすべてのメモリを常に読み取りキャッシュと書き込み キャッシュに割り当ててください。 1 CX4 シリーズの全モデルには 2 つの SP が搭載されます。 アプリケーションは、フロントエンド FC ポートでのみ使用できます。 3 8 バックエンド・バスにはイネーブラ・ソフトウェアが必要です。 2 42 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス 必要に応じて、ストレージ・システムのすべてのメモリを書き込みキャッシュとして使用するように割り当てること ができます。表 9は、最大限のキャッシュ割り当てを示しています。ストレージ・システムの書き込みキャッシュは、 システム障害が発生しても書き込みキャッシュの内容が失われないように、SP 間でミラーリングされます。書き込 みキャッシュを 1 回割り当てると、両方の SP に適用されます。このミラーリングにより、書き込みキャッシュを割 り当てると、割り当て量の 2 倍が消費されます（2 つの SP にそれぞれ、メモリから同じ量が割り当てられます）。 たとえば、250 MB の書き込みキャッシュを割り当てた場合、500 MB のシステム・メモリが消費されます。 読み取りキャッシュはミラーリングされません。読み取りキャッシュ用にメモリを割り当てると、一方の SP にのみ 割り当てられます。このため、2 つの SP は、書き込みキャッシュの容量は常に同じですが、読み取りキャッシュの 容量は異なる場合があります。使用可能な SP メモリを効率的に使用するには、実際には両方の SP に同容量の読み 取りキャッシュを割り当てることをお勧めします。 表9 FLARE 29 での最大のキャッシュ割り当て CX4-120 CX4-240 CX4-480 CX4-960 最大ストレージ・システム・キャッシュ容量（MB） 1196 2522 8996 21520 最大ストレージ・システム書き込みキャッシュ容量（MB） 598 1261 4498 10760/6000* SP ごとの最大読み取りキャッシュ容量（MB） 598 1261 4498 10760 * CX4-960 の書き込みキャッシュ容量は、2 Gb/秒の DAE 0 が取り付けられている場合は尐なくなります。 キャッシュ割り当ての推奨事項 一般的に、使用可能なキャッシュ・メモリが 2 GB 以下のストレージ・システムでは、メモリの 20%を読み取り キャッシュに使用し、残りを書き込みキャッシュに使用します。これより大容量のキャッシュ構成の場合は、読み取 りキャッシュ用に約 1 GB を確保しつつ、書き込みキャッシュに使用するメモリを最大化してください。具体的な推 奨事項は次のとおりです。 表10 CX4 の推奨されるキャッシュ設定 CX4 の推奨されるキャッシュ設定 CX4-120 CX4-240 CX4-480 CX4-960 書き込みキャッシュ（MB） 498 1011 3600 9760 読み取りキャッシュ（MB） 100 250 898 1000 合計キャッシュ（MB） 598 1261 4498 10760 ヴォールト・ドライブ CLARiX CX4 の DAE0 の最初の 5 ドライブ（0～4）は、障害に備えて確保されている書き込みキャッシュ、スト レージ・システムのオペレーティング・システムのファイル、PSM（Persistent Storage Manager）、FLARE 構成 データベースを含むシステム・ドライブです。AX シリーズでは最初の 4 ドライブがこの目的のために確保されてい ます。これらのドライブは、システム・ドライブとも呼ばれます。 システム・ドライブは、システム上の他のドライブと同様に使用できます。ただし、ストレージ・システムのファイ ルが含まれているため、有効容量はデータ・ドライブより尐なめです。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 43 ストレージ・システムのベスト・プラクティス ヴォールト・ドライブの容量 CX4 シリーズのヴォールト・ドライブでは、ドライブごとの容量の約 62 GB をシステム・ファイルに使用します。 ヴォールト・ドライブは、互いにバインドして 1 つまたは複数の RAID グループにしてください。これは、ヴォール ト・ドライブをヴォールト以外のドライブとバインドした場合、グループ内のすべてのドライブの容量が、ヴォール ト・ドライブの容量に合わせて縮小されるからです。 ヴォールトと PSM に対する影響 ヴォールトの最初の 4 ドライブには SP のオペレーティング・システムが含まれます。ストレージ・システムの起動 後は、オペレーティング・システムのファイルのアクセス頻度は低くなります。ストレージ・システムの OS のパ フォーマンスを最適にするには、迅速なアクセスが必要です。このパフォーマンスを確実にするために、ヴォールト にはエンタープライズ向け（ファイバ・チャネル、SAS、EFD）のドライブを使用することをお勧めします。 ヴォールトの最初の 3 ドライブには、PSM と FLARE 構成データベースが含まれています。PSM と FLARE 構成デー タベースは、重要なストレージ・システムの状態情報を保存するために使用します。SP から PSM へのアクセスは軽 量ですが、Navisphere Manager のコマンドに対する応答が遅延しないように、ドライブに遅延なくアクセスできる 必要があります。 ヴォールト・ドライブは、5 台すべてがキャッシュ・ヴォールトに使用されます。キャッシュ・ヴォールトは、 キャッシュがダンプしているときや、リカバリ後にドライブに再ロードおよびフラッシュされているときにのみ使用 されます。CX4 シリーズの永続キャッシュでは、このイベントはまれにしか発生しません。ただし、この期間中は、 これらのドライブに対するホストの I/O 応答が遅くなります。 ヴォールト・ドライブは、汎用的なファイル・サービスのような、中程度のホスト I/O ロードに使用できます。これ らのドライブは、次の表に示す用途に限定してください。 表11 ヴォールト・ドライブの最大ホスト I/O ロード 最大 IOPS 最大帯域幅 （MB/秒） ファイバ・チャネル 100 10 SAS 100 10 SATA 50 5 1500 60 ヴォールト・ハード・ ディスク・ドライブのタイプ EFD 一般的に、LUN プロビジョニングを計画するときは、使用可能な複数の RAID グループにビジーな LUN を均等に分 散してください。LUN をプロビジョニングすると、ヴォールト・ドライブで構成される RAID グループでは、これら の RAID グループの帯域幅が完全には使用できないとみなされます。ヴォールト・ドライブ上の LUN の帯域幅使用 率は、すでにビジーな LUN とドライブを共有する場合と同様に計画してください。これが CLARiX のヴォールト・ ドライブ使用率に相当します。 FLARE リビジョン 28.5 から、EFD および SATA ドライブをヴォールト・ドライブとして構成できます。SATA ドラ イブと EFD には、ファイバ・チャネルおよび SAS ドライブと同じ容量制限があります（前述の「ヴォールト・ドラ イブ」セクションを参照）。 ドライブが異なれば、帯域幅や IOPS の制限も異なります。EFD の帯域幅と IOPS は、機械式ハード・ディスク・ド ライブを上回ります。ファイバ・チャネルまたは SAS ドライブの IOPS と帯域幅は、SATA ドライブを上回ります。 そのため、SATA ヴォールト・ドライブで構成される RAID グループ上のビジーな LUN はプロビジョニングしないこ とが重要です。ただし、EFD をヴォールト・ドライブとして使用すると、これらのドライブを含む RAID グループに 対するワークロードの要求が高いユーザーLUN をプロビジョニングできます。ヴォールト・ドライブを使用して ユーザーのワークロードをサポートする場合は、常に注意が必要です。表 11にある推奨値を大きく超えないように してください。 44 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス たとえば、均等にビジーな 5 つの LUN をプロビジョニングする必要があるとします。これらの LUN を、3 つの RAID グループに割り当てる必要があります。1 つの RAID グループは、必然的にヴォールト・ドライブで構成され ています。新しい LUN のうち 2 つを、ヴォールト・ドライブ以外の RAID グループ 2 つにそれぞれ配置します（合 計 4 つの LUN）。1 つの新しい LUN を、ヴォールト・ドライブの RAID グループに配置します。その理由は、新し い LUN がプロビジョニングされる前に、ヴォールト・ドライブから構築された RAID グループでは、ビジーな LUN が CLARiX からすでにプロビジョニングされているからです。 AX4-5 以前の CLARiX ストレージ・システムに関する推奨事項 AX4-5 以前の CLARiX システムに関しては、前述の CX4 に関する考慮事項が適用されます。リザーブ LUN プール、 クローン、ミラーLUN は、ヴォールト・ドライブ上には配置しないでください。また、レスポンス・タイム重視の データをヴォールト・ドライブに配置するのは避けてください。 書き込みキャッシュの可用性が向上していない CLARiX では、ヴォールト・ドライブに障害が発生すると、通常は、 これらのドライブ上のアクティビティの再構築が必要になり、書き込みキャッシュが無効になります。この状況で、 これらのドライブ上にあるデータに対してレスポンス・タイム重視のアクセスが必要な場合は、Navisphere の HA ヴォールト・オプションをクリアする必要があります。HA ヴォールトを無効にすると、ヴォールト・ドライブの再 構築中にキャッシュが有効なままとなりますが、キャッシュ・データの保護は多尐弱まります。このことは、ヴォー ルトで SATA ドライブを使用しているシステムで特に重要です。これらのドライブの再構築やキャッシュの再有効化 には長い時間がかかるためです。 ロード・バランシング ストレージ・システムのリソースに必要なワークロードを、使用可能なストレージ・システムのリソースすべてに均 等に分散すると、パフォーマンス上のメリットがあります。このバランシングは、次のような複数のレベルで達成で きます。 ストレージ・システムのフロントエンド・ポート間の I/O のバランシングは、ポートやゾーニングをホストに慎 重に割り当てたうえで、主に PowerPath によって実行されます。詳細については、「PowerPath」セクションを 参照してください。 ストレージ・プロセッサ間のバランシングは、必要なワークロードを予測したうえで、LUN プロビジョニングに よって実行されます。詳細については、「LUN のプロビジョニング」セクションを参照してください。 バックエンド・ポート間のバランシングは、パフォーマンス、容量、可用性に関するワークロードの要件を予測 したうえで、RAID グループ作成によって実行されます。詳細については、「RAID グループのバス・バランシン グ」セクションを参照してください。 フェイルバック 万が一 SP に障害が発生すると、その SP が所有する LUN は、ホスト・マルチパス・アプリケーションによって、障 害を逃れたピア SP にトレスパスされます。障害に関連するトレスパスが発生すると、障害を逃れた SP 上の負荷が 増えるため、パフォーマンスが低下する場合があります。フェイルバックとは、トレスパスされた LUN のオーナー 権を元のオーナーである SP に戻すことです。 パフォーマンスを最適にするには、障害に関連するトレスパスの後に、LUN のオーナー権が元のオーナーである SP に迅速かつ完全に（自動または手動で）リストアされるようにします。 PowerPath をホストにインストールすると、フェイルバックは自動プロセスになります。ホスト OS では、PowerPath なしでも自動フェイルバックがサポートされる場合があります。たとえば、HP-UX ではフェイルバックをネイティ ブでサポートします。フェイルバック機能のサポートの有無と方法を確認するには、ホスト OS のドキュメントを参 照してください。PowerPath がインストールされていない場合で、ホスト OS でのフェイルバックのサポートもない 場合は、フェイルバックは手動プロセスになります。自動でない場合は、元のレベルのパフォーマンスを確保するた めに、トレスパス後に手動フェイルバックを実行するために必要なポリシーと手順を整えておく必要があります。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 45 ストレージ・システムのベスト・プラクティス フェイルバックの詳細、およびトレスパスの効果については、Powerlink から入手できるホワイト・ペーパー「EMC CLARiiON High Availability (HA) — Best Practices Planning」を参照してください。 バックエンドの考慮事項 バックエンドは、バックエンド・バスとドライブで構成されます。DAE あたりのドライブの数、DAE からバスへの 接続、RAID タイプ（ミラーまたはパリティ）、ディスクの種類（ファイバ・チャネル、SAS、SATA、EFD）、お よびドライブにおける LUN 情報の分散がすべてシステム・パフォーマンスに影響します。 UltraPoint DAE UltraPoint™とは、CLARiX CX4 および CX3 シリーズのストレージ・システムに付随の DAE2P、DAE3P、DAE4P CLARiiON DAE を指します（Navisphere では、UltraPoint DAE はタイプ DAE-2P として表示されます）。UltraPoint は、4 Gb/秒のポイント・ツー・ポイントのファイバ・チャネル DAE です。UltraPoint は、4 Gb/秒または 2 Gb/秒の ハード・ディスク・ドライブをホストできます。 DAE2 とは、以前の CLARiX CX シリーズに付随の 2 Gb/秒のファイバ・チャネル DAE を指します。DAE2-ATA は、 以前の CLARiX モデルで PATA ドライブとともに使用されていた従来の 2 Gb/秒の DAE です。 高いパフォーマンスと可用性を確保するために、CLARiX CX4 シリーズのストレージ・システムの 4 Gb/秒のインタ フェースに対応する UltraPoint DAE とハード・ディスク・ドライブのみを使用することをお勧めします。 CLARiX CX4 で 2 Gb/秒のドライブまたは 2 Gb/秒の速度の DAE を使用すると、接続されている CX4 バス（SP ごと に 1 つずつの 2 つのループ）は 2 Gb/秒の速度に設定されます。4 Gb/秒の DAE とその 4 Gb/秒のハード・ディス ク・ドライブはすべて、遅い方の 2 Gb/秒のバス速度で動作します。バス上のパフォーマンスは、特に広帯域幅の ワークロードで、悪影響を受けます。2 Gb/秒のドライブを 4 Gb/秒のバスに取り付けたら、Navisphere の「バック エンド・バス・スピード・リセット・ウィザード」を使用して再構成を完了してください。再構成を完了するには、 両方の SP を同時に再起動する必要があります。 CLARiX FC CX3 および CX4 のハード・ディスク・ドライブは、2 Gb/秒での動作に適しています。2 Gb/秒に適した ハード・ディスク・ドライブのパーツ番号については、EMC の担当営業までお問い合わせください。ネイティブの 4 Gb/秒の DAE は、2 Gb/秒のドライブが取り付けられている場合は、2 Gb/秒のバックエンド・バス速度で運用でき ます。SATA ハード・ディスク・ドライブは、4 Gb/秒で動作する 4 Gb/秒対応の DAE に取り付けた場合にのみ動作 します。 CLARiX CX4 のベスト・プラクティスのパフォーマンスの数値は、特に明記しない限り、4 Gb/秒のバックエンド・ バスと 4 Gb/秒のハード・ディスク・ドライブで生成されます。バックエンド・バスの一部または全部が 2 Gb/秒で 動作している場合は、公表されている帯域幅が得られないことがあります。 帯域幅とハード・ディスク・ドライブのホスト・オプションが増加されたほかに、UltraPoint では、可用性が旧バー ジョンの DAE より強化されました。UltraPoint DAE では、障害を単一のハード・ディスク・ドライブに切り分ける ことができます。UltraPoint DAE は、DAE 内のスイッチを使用してドライブにアクセスします。これにより、 CLARiX では、オンラインになる前、またはエラーが検出されたときに、ハード・ディスク・ドライブを個々にテス トできます。 UltraPoint 以外の DAE または 2 Gb/秒のハード・ディスク・ドライブを CLARiX CX4 ストレージ・システムとともに 使用する際に推奨されるアプローチは次のとおりです。 ストレージ・システムがサービスから切り離されたら、可能であれば DAE2 を UltraPoint DAE と交換します。 UltraPoint 以外の DAE をすべて、同じ低速の 2 Gb/秒 CX4 バックエンド・バスに分離します。 2 Gb/秒インタフェースのハード・ディスク・ドライブをすべて、低速の 2 Gb/秒のバックエンド・バス上にある 独自の DAE に分離します。 46 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス 2 Gb/秒のインタフェースのハード・ディスク・ドライブを 4 Gb/秒のインタフェースのハード・ディスク・ドラ イブと混在させずに LUN をプロビジョニングします。 2 Gb/秒のドライブとバックエンド・ループを使用している LUN を、広帯域幅を必要としないワークロードに割 り当てます。 DAE をストレージ・システムに追加する前に、計画を立ててください。構成済みの DAE のバスまたはエンクロー ジャの数は、DAE をプロビジョニングした後は簡単に変更できません。バス X エンクロージャ Y として構成されて いる DAE で RAID グループと LUN が作成されている場合は、バスとエンクロージャのアドレスを変更すると、スト レージ・システムで RAID グループおよびその LUN を認識できなくなります。バスまたはエンクロージャのアドレ スを変更し、LUN のデータを保持するには、LUN マイグレーションが必要です。 ホット・スペア ホット・スペアは、障害が発生したドライブの代わりに使用するハード・ディスク・ドライブです。プロアクティ ブ・スペアとは、ドライブに障害の可能性があるときにホット・スペアを自動的に起動することです。CLARiX のプ ロアクティブ・スペアでは、指定されているグローバル・ホット・スペアのプールから、ホット・スペアを自動的に 選択します。慎重にプロビジョニングすることにより、交換用のドライブが取り付けられるまで、使用可能容量を効 率的に使用でき、最適なパフォーマンスが確保されます。そうしないと、あまり適していないホット・スペアが代替 使用される可能性があります。たとえば、ファイバ・チャネル RAID グループの障害ハード・ディスク・ドライブの スペアとして、SATA ハード・ディスク・ドライブが自動的に選択され、その結果パフォーマンスが低下する可能性 があります。 ドライブに障害が発生したときに、適切なタイプ、サイズのホット・スペアが構成されていない場合は、再構築は行 われません。障害ドライブを含む RAID グループは、ドライブが交換されるまで、パフォーマンスが低下した状態に なります。その後、障害ドライブの RAID グループが、RAID レベルに従って、パリティまたはミラー・ドライブか ら再構築されます。 ホット・スペアの選択プロセスでは、次の条件が使用されます。 ドライブ・タイプ - どんなハード・ディスク・ドライブでもホット・スペアの役割を果たすことができます。た だし、EFD は例外です。EFD は、EFD のホット・スペアとしてのみ使用できます。プロアクティブ・ホット・ スペアでは、RAID 0 タイプのグループに構成されているドライブはサポートされません。 障害ドライブの使用中の容量 - 交換アルゴリズムでは、障害ドライブの LUN の容量を収容可能な最小容量のホッ ト・スペアを使用しようとします。 ホット・スペアの場所 - 障害ドライブと同じバックエンド・バス上にあるホット・スペアが、容量が同程度の他 のドライブより優先されます。タイプ、速度、容量が適切なホット・スペアが、交換対象となるハード・ディス ク・ドライブと同じバス上に配置されていることを確認してください。DAE の標準的なラック構成では、隣接し 合う DAE 間で冗長バックエンド・バスが交互に切り替わり、最初の DAE がバス 0、次の DAE がバス 1 となり ます。標準的なラック構成が使用されていない場合は、バスの接続を常に確認する必要があります。ホット・ス ペアをプロビジョニングするときは、ストレージ・システムのバックエンド・バスの数と、ストレージ・システ ムの DAE へのバス接続を確認してください。 ホット・スペアをプロビジョニングするストレージ・システムで、ドライブのタイプが混在している場合（ファイ バ・チャネルと SATA の両方がある場合など）、ドライブ速度が混在している場合（10k rpm と 15k rpm など）、サ イズが混在している場合（300 GB と 1 TB など）は、ドライブのタイプや速度ごとにホット・スペアを 1 つ以上ず つ設定します。ホット・スペアは、代行する可能性のある最大容量のドライブの代わりとして十分な機能を持つタイ プと速度のものを使用する必要があります。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 47 ストレージ・システムのベスト・プラクティス ホット・スペアを選択する際は、次のような優先順位があります。 1） 使用中の容量 2） ホット・スペアの場所 3） ドライブ・タイプ 使用中の容量が、ホット・スペア選択の際の最も重要な基準です。使用中の容量は、ドライブの容量ではなく LUN に依存します。障害ドライブの使用中の LUN 容量は、予測不可能です。これによって思いも寄らないホット・スペ アが選択される場合があります。たとえば、障害ドライブと同一で、同じ DAE にあるホット・スペア・ドライブで はなく、別のバス上にあるサイズの小さいホット・スペアが自動的に選択される可能性があります。これが発生する のは、サイズの小さいリモートのホット・スペアのフォーマット後の容量（選択基準の最上位）の方が、同一のロー カルのホット・スペアよりも障害ドライブの LUN の使用中容量との一致率が高いためです。 最後に、可用性確保のためには、ドライブ 30 台ごとに 1 つ以上ずつのホット・スペアが必要です。タイプ、速度、 容量が混在しているストレージ・システムでは、ホット・スペアと障害ハード・ディスク・ドライブが確実に一致す るように、より多くのホット・スペア（比率が低くなる）が必要な場合があります。これにより、障害ハード・ディ スク・ドライブが交換されるまでの間、パフォーマンスが最適になります。 ホット・スペアのベスト・プラクティス 以下にホット・スペアのベスト・プラクティスについてまとめます。 ストレージ・システム上のハードウェアの速度、最大限必要な容量、タイプごとに、1 つ以上ずつのホット・ス ペアを用意します。 ホット・スペアは、交換対象となるドライブを含むバスと同じバスに配置します。 ホット・スペアとデータ・ハード・ディスク・ドライブの比率を 1:30（DAE 2 つにつきホット・スペア 1 つ）以 上に維持します。 EFD ストレージ・デバイスは、他の EFD デバイスのホット・スペアとしてのみ使用できます。 ホット・スペアの詳細については、Powerlink から入手できるホワイト・ペーパー「CLARiiON Global Hot Spares and Proactive Sparing」を参照してください。 ホット・スペアの例 以下は、ホット・スペアの可用性の例です。ある顧客が CX4-240（2 つの冗長バックエンド・バス）を所有していま す。ストレージ・システムには DAE が 4 つ（0～3）あります。このストレージ・システムを、次のハード・ディス ク・ドライブでプロビジョニングします。 7.2k rpm、1 TB SATA ハード・ディスク・ドライブ 14 台を、単一の、14 ハード・ディスク・ドライブの RAID 6 グループ（12+2）で構成 15k rpm、300 GB のファイバ・チャネル・ハード・ディスク・ドライブ 40 台を、8 つの、5 ハード・ディスク・ ドライブの RAID 5 グループ（4+1）で構成 このストレージ・システムのプロビジョニングを完了するには、ホット・スペアを何個使用する必要があるでしょう か。ホット・スペアはどこに配置すればよいでしょう。これらの質問の答えを次に示します。 48 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス ホット・スペア用にストレージ・システムを構成 以下の表は、可用性を確保するためのストレージ・システムのホット・スペア・プロビジョニングをまとめたもの です。 表12 ホット・スペアのプロビジョニングの例 DAE バックエンド・ バス ヴォールト・ ドライブ データ・ ドライブ ホット・スペア 合計 DAE ドライブ数 DAE0 0 5×FC 10×FC 0 15 DAE1 1 0 14×SATA 1×SATA 15 DAE2 0 0 15×FC 0 15 DAE3 0 0 10×FC 1×FC 11 FC データ・ドライブの合計 49 FC ホット・スペアの合計 1 SATA ドライブの合計 14 SATA ホット・スペアの合計 1 全ドライブの合計 65 DAE0 では、300 GB、15k rpm のファイバ・チャネル・ハード・ディスク・ドライブが 15 台構成されています。こ れらのハード・ディスク・ドライブのうち 5 台はヴォールトで使用されます。ホット・スペアは、ヴォールトではプ ロビジョニングされません（これにより、バス 0 上の DAE0 のハード・ディスク・ドライブは合計 15 台になります）。 DAE1 をバス 1 上に構成し、7.2k rpm、1 TB の SATA ハード・ディスク・ドライブ 10 台でプロビジョニングします。 さらに、7.2k rpm、1 TB の SATA ホット・スペア 1 個でプロビジョニングします。SATA データ・ドライブのバスで、 タイプ、速度、容量がデータ・ドライブと同一である SATA ホット・スペアがプロビジョニングされることを確認し ます（これにより、バス 1 上の DAE1 のハード・ディスク・ドライブは合計 11 台になります）。 DAE2 をバス 0 上に構成し、15 台のファイバ・チャネル・ハード・ディスク・ドライブでプロビジョニングします （これにより、DAE2 のハード・ディスク・ドライブは合計 15 台になります）。 DAE3 をバス 0 上に構成します。これは標準外のラック構成です。これを 10 台のファイバ・チャネル・ハード・ ディスク・ドライブでプロビジョニングします。さらに、15k rpm、300 GB のファイバ・チャネル・ホット・スペ ア 1 個でプロビジョニングします（バス 0 上の DAE3 のハード・ディスク・ドライブは合計 11 台になります）。タ イプ、速度、容量がファイバ・チャネル・データ・ドライブと同一であるファイバ・チャネル・ホット・スペアがバ ス 0 でプロビジョニングされ、DAE0 および DAE2 のそれぞれ 15 台のドライブと、DAE3 の 10 台のドライブの「ス ペア」となります。ファイバ・チャネル・ドライブ数とホット・スペア数の比率は 30:1 以上です。ただし、DAE1 の SATA ホット・スペアを考慮に入れると、ホット・スペアとデータ・ドライブの全体の比率は 30:1 より低くなり ます。 RAID グループ RAID レベルごとに、リソース使用率、パフォーマンス、データ保護に独自の特性があります。特定のワークロード に関して、特定の RAID レベルが、他の RAID レベルに比べてパフォーマンス上明らかに優位な場合があります。 構成可能な RAID グループの数は、CX4 ストレージ・システム・モデル上でホストできるドライブの最大数によって 異なります。 CLARiX ストレージ・システムは RAID レベル 0、1、3、5、6、1/0 をサポートしています。各 RAID レベルのパ フォーマンスと可用性については、ホワイト・ペーパー「EMC CLARiiON Fibre Channel Storage Fundamentals」を 参照してください。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 49 ストレージ・システムのベスト・プラクティス RAID グループと I/O ブロック・サイズ パフォーマンスを最適にするために、RAID グループのストライプ・サイズを、I/O ブロック・サイズに合わせてアラ イメントしてください。これは、大きいブロックのランダム・ワークロードやキャッシュを使用しない（LUN 用に キャッシュが無効になっている）操作に使用する RAID グループで特に重要です。ストライプ・サイズを「均等」に しても、小さいブロックのランダム・アクセスやシーケンシャル・アクセスには影響はありません。アライメントに より、I/O ブロック・サイズは、ストライプ・サイズまたはストライプ・サイズの倍数に一致します。このアライ メントは、I/O サイズがわかっていて、I/O サイズがそれほど多様でない場合に最も効果的です。 一般的に、これによって RAID グループのストライプ・サイズは 2 の累乗になります。例は（2+1）、（4+4）、 （8+2）などです。I/O ブロック・サイズが大きく、ストライプのサイズが適切でない場合は、単一のドライブ上で I/O が次のストライプにラップします。これによって I/O が遅延します。たとえば、6 ドライブ（3+3）の RAID 1/0 グループでは、ストライプは 192 KB（3×64 KB）です。I/O ブロック・サイズが 256 KB の場合は、1 ドライブ分、 次のストライプにラップします。広帯域幅で大きなブロックのランダム I/O では、これはあまり最適とは言えません。 RAID 容量使用率の特性 RAID レベルが異なれば、容量使用率のレベルも異なります。RAID グループのタイプと RAID グループで使用するド ライブの数を決定するには、動作状態およびデグレード状態で必要な容量、可用性、パフォーマンスと、使用可能な ドライブ数を考慮する必要があります。 パリティ RAID グループの場合、RAID グループにおけるデータ対パリティの割合は、選択した RAID レベルによっ て異なります。この割合は、グループ内の、パリティ専用でデータ・ストレージとしては使用しないドライブ数を表 します。データ対パリティの割合は、RAID グループ内のドライブの数によって異なります。グループ内のドライブ の最大構成数は 16 です。最小構成数は RAID レベルによって異なります。データ対パリティの割合が低いと、ドラ イブ数が最小の場合のパリティ RAID グループの有用性が制限されます。たとえば、4 ドライブの RAID 6 グループ （2+2）は推奨されません。 パリティ RAID レベル 3 および 5 の場合は、パリティ専用の RAID グループのドライブの相当する容量は 1 です。パ リティ RAID レベル 6 の場合は、相当する容量は 2 です。RAID 5 グループおよび RAID 6 グループでは、パリティ専 用のドライブはありません。これらの RAID レベルでは、全ドライブの一部がパリティによって消費されます。 RAID 3 には、専用のパリティ・ドライブが 1 台あります。 ストレージ・システムをプロビジョニングするときは、パリティ RAID グループ・タイプと RAID グループ・サイズ の関係を理解しておくことが重要です。RAID グループ内のドライブ数が増加すると、RAID グループ内のパリティ 専用のドライブ容量の割合が減尐します。これは、使用可能なドライブの効率的かつ経済的な使用方法です。 ミラーRAID グループの場合、RAID グループのストレージ容量はグループ内のドライブの総容量の半分です。 RAID 0 は特殊なケースです。RAID レベル 0 の場合、RAID グループのストレージ容量はグループ内のフォーマット 済みドライブの総容量です。RAID レベル 0 では、容量使用率は最高になりますが、データはまったく保護されま せん。 要約すれば、使用可能なドライブ容量の一部は可用性を維持するために使用されます。ストレージ・システムのドラ イブをパリティ・タイプの RAID グループとして構成すると、ミラー・タイプの RAID グループよりも高い割合で、 取り付けられているドライブの容量をデータ・ストレージに使用できます。パリティ RAID グループが大きいほど、 パリティ・ストレージの割合のペナルティは小さくなります。ただし、RAID のタイプをプロビジョニングする際は、 ストレージの容量に加えて、パフォーマンスと可用性を考慮する必要があります。 RAID のパフォーマンス特性 RAID レベルが異なれば、RAID のタイプおよび RAID グループ内のドライブ数によって、パフォーマンスと可用性が 異なります。特定のワークロードには、特定の RAID タイプおよび RAID グループ・サイズが、他に比べて適してい ます。 50 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス RAID 0 を使用する状況 業務上重要なデータには、RAID 0 を使用しないことをお勧めします。 RAID 0 グループは、再構築の時間がビジネス・プロセスに影響しない状況で、高速（特に書き込み速度）、低コス トの容量を必要とする、重要でないデータに使用できます。RAID 0 グループに関する情報は、保護されているスト レージでバックアップまたは複製を済ませている必要があります。RAID 0 には、冗長性はまったくありません。 RAID 0 グループに関しては、プロアクティブ・ホット・スペアは無効です。RAID 0 グループで 1 台のドライブに障 害が発生すると、グループのデータが完全に失われます。復旧不可能なメディア障害が発生すると、データの一部が 失われる可能性があります。RAID 0 グループの用途には、スクラッチ・ドライブや一時ストレージなどが考えられ ます。 RAID 1 を使用する状況 RAID 1 の使用はお勧めしません。RAID 1 グループは拡張できません。シングル・ミラーの RAID グループの代わり として RAID 1/0（1+1）グループを使用してください。 RAID 3 を使用する状況 大きいブロックのシーケンシャル・リード処理を特徴とするワークロードの場合、RAID 3 が他の RAID レベルより も数 MB/秒上回る帯域幅を複数提供します。RAID 3 は、次の条件でより広範な読み取り帯域幅を実現します。 バックエンド・ループごとのドライブの数が尐ない場合など、ドライブによってボトルネックが引き起こされる 場合。 シーケンシャル・ストリームが 2 MB よりも大きい場合。 ファイル・システムが断片化されていないか、未フォーマット・ストレージを使用している場合。 ブロック・サイズが 64 KB 以上の場合。 RAID 3 は、ディスク・バックアップ・アプリケーションで効果的に使用できます。この場合は、RAID グループを （4+1）または（8+1）として構成します。使用するバックアップ・ストリームは 1 つの LUN につき 5 つ以内にして ください。 一般的には、RAID 3 より RAID 5 を使用することをお勧めします。RAID 3 は、ランダム・ライト処理時にパリ ティ・ドライブでボトルネックを生じる可能性があるので、高度にシーケンシャルな I/O ワークロードでのみ使用し てください。また、複数の RAID 3 グループがバックエンド・バス上でシーケンシャル・リード処理を実行している 場合、バスはすぐにボトルネックになり、パフォーマンスは RAID 5 と変わらなくなります。 RAID 5 を使用する状況 RAID 5 は、メッセージング、データ・マイニング、中程度のパフォーマンスのメディア・サービス、および DBA （データベース管理者）が効率よく先読み後書き方式を使っている RDBMS 実装環境に向いています。ホスト OS お よび HBA が 64 KB 以上の転送を処理する能力がある場合は、RAID 5 が最適です。次のアプリケーションは、RAID 5 に適しています。 ギガバイトあたりの IOPS の要件が適度なランダム・ワークロード 書き込みがワークロードの 30%以下の高パフォーマンス・ランダム I/O アクセスがシーケンシャルな DSS データベース（販売記録で統計分析を実行） レコード・サイズが 64 KB よりも大きく、アクセスがランダムな RDBMS テーブルスペース（写真など、バイナ リ・コンテンツのある社員の記録） RDBMS ログ・アクティビティ メッセージング・アプリケーション ビデオ/メディア パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 51 ストレージ・システムのベスト・プラクティス RAID 6 を使用する状況 RAID 6 では、パリティ RAID グループでのメディア障害およびドライブの同時二重障害に対する保護が強化されて います。RAID 5 と同様なパフォーマンスですが、追加のパリティ計算用の追加のストレージが必要です。この追加 のストレージは、RAID グループにデータ・ストレージとしては使用できないドライブを追加することを意味します。 RAID 6 は、パリティ・ドライブを追加するオーバーヘッドよりも信頼性を強化するニーズが重要な場合に、RAID 5 の代わりに使用できます。 RAID 6 グループには 4～16 のドライブを含めることができます。小さいグループは 6 ドライブ（4+2）まで、中規 模のグループは 12 ドライブ（10+2）までで、それ以上が大きいグループです。小さいグループの場合はストリーム もスムーズに行われます。ただし、小さいランダム・ライト処理は、デステージの速度が遅く、システム書き込み キャッシュの効率に悪影響を及ぼす可能性があります。中サイズのグループは、シーケンシャルとランダムの両方の ワークロードで優れたパフォーマンスを提供します。最適な RAID 6 グループは 10 ドライブ（8+2）および 12 ドラ イブ（10+2）サイズです。 RAID 6 グループ・サイズを選択する場合、パリティに対するデータの割合は重要な考慮事項です。RAID 6 グループ 1 つごとに、2 ドライブに相当するユーザー容量が削減されます。さらに、追加のパリティ計算により、I/O パフォー マンスに影響があります。たとえば、5 ドライブの RAID 5（4+1）グループを同じユーザー・データ容量にするため には、同容量のドライブで構成される 6 ドライブの RAID 6（4+2）グループに移行する必要があります。 RAID 6 と RAID 5 および RAID 1/0 のパフォーマンスの比較 ランダム・ワークロードの場合、同じ数のドライブを使用したときの読み取り処理に関しては、RAID 6 と RAID 5 で パフォーマンスに違いはありません。ランダム・ライト処理は異なります。RAID 5 を超える追加のパリティ・ドラ イブにより、RAID 6 のバックエンド・ワークロードは書き込みで 50%増大します。これは、ドライブの数の拡張と ともに、CLARiX でのパフォーマンスに影響します。さらに、RAID 6 の追加のオーバーヘッドは、RAID 5 よりも早 くフル・キャッシュ状態を引き起こす可能性があります。ただし、ワークロードが強制フラッシュなしでキャッシュ からデステージできる限り、ホストのレスポンス・タイムの観点からは RAID 5 と RAID 6 は同様な動作になります。 同数のドライブでのシーケンシャル・ワークロードの場合、読み取りパフォーマンスはほとんど同じです。シーケン シャル・ライト処理のワークロードは RAID 6 のパフォーマンスでは約 10%低くなります。 ただし、RAID 6 では、グループ内の任意のドライブにおけるドライブの二重障害に耐えることができます。これに より、可用性は RAID 1/0 よりも高くなります。RAID 1/0 のプライマリ・ドライブとそのミラー・ドライブの障害は、 RAID 1/0 グループにとって致命的です。RAID 6 は容量と可用性の面で RAID 1/0 より優れていますが、RAID 1/0 は、 小さいブロックの書き込みパフォーマンスがどんなパリティ RAID タイプよりも優れています。 ドライブの二重保護により、RAID 6 グループは、可用性が高いため、デフォルトの（High）優先度の再構築に適し ています。単一の共有バスによって再構築速度にボトルネックが発生すると仮定すると、大きい RAID 6 グループは、 大きい RAID 5 グループとほぼ同じ速度で再構築されます。中型サイズの RAID 6 グループは、同じ数のデータ・ド ライブを含む RAID 5 グループよりも約 10%長い時間が再構築に必要です。小さなサイズの RAID 6 グループでは、 同じサイズの RAID 5 グループと比べて 25%長い時間がかかります。RAID グループが複数のバスに分散されている 場合は、グループのサイズにかかわらず、RAID 5 の方が速度の面で RAID 6 より優れています。 他の RAID レベルとは異なり、FLARE リビジョン 29.0 以前では、RAID 6 グループの最適化はサポートされていません。 RAID 6 の経験則 10 ドライブ（8+2）と 12 ドライブ（10+2）の RAID 6 グループでは、データ対パリティの比率が適切であるほ か、IOPS 能力、およびストリーミングの特性もあります。これらのグループ・サイズは、候補として最初に考 慮する必要があります。 16 ドライブ（14+2）のグループでは、RAID 6 のデータ対パリティの比率が最適であり、ランダム・ワークロー ドの拡張が最も効果的に行われます。ただし、8 ドライブ（6+2）、10 ドライブ（8+2）、12 ドライブ（10+2） の RAID 6 グループと比べて、シーケンシャル・ストリームの実行で劣ります。 52 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス 6 ドライブの RAID 6（4+2）グループでは、5 ドライブの RAID 5（4+1）グループに比べて、使用可能な IOPS が 20%多くなります。読み取り/書き込みの合計がドライブの容量を超えない場合は、これを（4+1）の代わりに 使用することを検討できます。これが該当しない場合は、（6+2）を使用してください。 交換のための選択を行う場合は、特にランダム・ライト処理に関して、RAID 5 を上回る RAID 6 のオーバーヘッ ドを考慮する必要があります。10 ドライブの RAID 6（8+2）グループでは、5 ドライブ（4+1）の RAID 5 グ ループ 2 つに比べて、対応できるランダム・ライト処理が尐なくなります。 RAID 6 グループは「バス・バランシング」に適しています。10 ドライブ（8+2）のグループは、別々のバス上 にある 2 つの DAE に均等に分散させることができます（DAE あたり 5 ドライブ）。12 ドライブ（10+2）のグ ループは、別々のバス上にある 3～4 つの DAE に均等に分散させることができます。 RAID 1/0 を使用する状況 RAID 1/0 は、小さい、ランダムかつ書き込み集中型の I/O を使用するワークロードで最適なパフォーマンスを提供し ます。書き込み集中型ワークロードの操作は、30%以上のランダム・ライト処理で構成されます。ランダムな小さな I/O ワークロードの例を次に示します。 高速トランザクション OLTP 大規模なメッセージング・インストール リアルタイムのデータ/下取りレコード 頻繁に更新される口座残高などの小さいレコードを格納する RDBMS データ・テーブル RAID 1/0 は、特定のデグレーデッド・モードにおいても性能を発揮します。これらのモードには、書き込みキャッ シュが無効になっている場合や、RAID グループでドライブ障害が発生した場合が該当します。RAID 1/0 レベルのグ ループ（3+3）および（4+4）は、容量とパフォーマンスのバランスがよく取れています。 RAID グループのバス・バランシング ストレージ・システムで、使用中のハード・ディスク・ドライブをできるだけ多くのバックエンド・バスに、できる だけ均等に分散すると、パフォーマンス上のメリットがあります。 極端なケースとしては、RAID グループのハード・ディスク・ドライブをそれぞれ別々のバックエンド・バスに配置 することが挙げられます（これを垂直プロビジョニングと呼ぶ場合があります）。ストレージ・システムのバック エンド構成を考えると、多くの場合、これは実用的ではありません。すべてのストレージ・システム・モデルに、こ のような分散を行うためのバックエンド・リソースがあるわけではありません。最後に、この方法でのプロビジョ ニングは、設定と保守に時間がかかるため、お勧めできません。 より簡単で実用的な方法として、RAID グループを複数のバックエンド・バスにできるだけ均等に分散させることを お勧めします。ラウンド・ロビンの順序で、各 RAID グループを別々のバス上に定義します（これを水平プロビジョ ニングと呼びます）。大きい RAID グループや、最高の可用性を確保するために使用する RAID 1/0 グループでは、 以下で説明するように、2 つのバックエンド・バスに分散させることからメリットが得られます。 たとえば、CX4-960 には、ストレージ・プロセッサごとに 8 つのバックエンド・バスがあり、システムに配置される ストレージは同一の I/O、つまり、すべてランダム I/O またはすべてシーケンシャル I/O であると予測されます。最初 に同じサイズの 8 つの RAID グループと、予測される IOPS ロードが必要な場合は、ストレージ・プロセッサのバス ごとに RAID グループを 1 つずつ配置します。 このルールの例外は、ワークロードが同一ではない場合です。その場合は、使用可能なバスのサブセットを、各 I/O タイプに対応しているドライブ用に使用できます。たとえば、あるバスのセットでランダム I/O を処理し、別のセッ トでシーケンシャル・ロードを処理します。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 53 ストレージ・システムのベスト・プラクティス ドライブのデュアル・オーナー権 ハード・ディスク・ドライブの両方のストレージ・システム SP によるデュアル・オーナー権が、CLARiX CX4 でサ ポートされています。すべてのハード・ディスク・ドライブがデュアル・ポートで、両方の SP から同時に I/O を受 け入れることができます。 デュアル・オーナー権では、シングル・オーナー権よりドライブの動作が予測しにくくなる場合があります。任意の ドライブにリクエストを発行するときに、各 SP はある程度独立して動作します。デュアル・オーナー権では、ドラ イブのキュー使用深度が深くなる場合があります。これにより、シングル・オーナー権よりレスポンス・タイムが長 くなることがあります。しかし、デュアル・オーナー権は特定の状況では効果的です。たとえば、大きいドライブ・ プールに metaLUN を作成するときは、バックエンド・バスに負荷を均等に分散させるために、デュアル・オーナー 権が必要な場合があります。 まとめると、ドライブにはシングル・オーナー権が好ましいものの、データの分散によって最大限のスループットが 必要な場合は、デュアル・オーナー権でドライブを構成できます。 バインド パフォーマンスと可用性を向上させるためにドライブをバインドする方法はいくつかあります。方法は、バインドを 行う RAID グループのタイプ（パリティまたはミラー）によって異なります。 次のバインドの推奨事項を実装するには、Navisphere CLI（Command Line Interface）、具体的には creatrg コマン ドに精通している必要があります。CLI コマンドの詳細については、EMC Powerlink から入手できる「Navisphere Command Line Interface (CLI) Reference」を参照してください。 複数の DAE にわたるバインド 同じバックエンド・バス上の複数の DAE にわたってドライブをバインドすると、可用性に関して若干のメリットが あります。このメリットは RAID の構成によって異なり、どの場合も違いはわずかです。 パリティ RAID グループ（RAID 3、RAID 5、RAID 6） パリティ RAID グループをバインドして、各ドライブが別々の DAE に入るようにしても、パフォーマンスの向上に はつながりませんが、データの可用性は多尐向上します。このようなバインドは、非常に複雑で時間がかかるため、 可用性を極めて高くする必要がある場合は RAID 1/0 を使用してください。 ミラーRAID グループ（RAID 1、RAID 1/0） RAID 1/0 グループを 3 つ以上の DAE でバインドしても、メリットはありませんが、有害なわけでもありません。 複数のバックエンド・バスにわたるバインド CX4-120 と AX4-5 を除くすべての CX4 モデルに、DAE に接続するためのデュアル・バックエンド FC ループが 1 セット以上あります。各 RAID グループは、1 つのバスのドライブで構成される場合も、両方のバスのドライブで構 成される場合も、すべてのバスのドライブで構成される場合もあります。DAE の標準的なラック構成では、隣接し 合う DAE 間でバスが交互に切り替わり、DPE つまり最初の DAE がバス 0、次の DAE がバス 1 となります。 パリティ RAID グループ 10 基以上のドライブで構成されるパリティ・グループは、2 つのバスにわたってバインドできるため、再構築時間の 短縮につながります。たとえば、2 番目の DAE が別のバス上にある場合は、10 ドライブ構成の RAID 5 をある DAE から 5 ドライブ選び、残りをその上の DAE から 5 ドライブ選んでバインドします。 54 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス Navisphere CLI を使用した複数バス間のバインド 複数のバスにまたがって RAID グループをバインドするには、Navisphere CLI を使用して RAID グループを構成する か、専用の LUN を定義する必要があります（Navisphere ウィザードでは、これは自動的に実行されません）。 Navisphere CLI では、ドライブを指定する際に、createrg コマンドまたは bind コマンドの指定に基づいて、プライ マリ 0、ミラー0、プライマリ 1、ミラー1 といった順序で作成されます。ドライブは、Bus_Enclosure_Disk という 記法で指定されます。次の例では、各バス上のエンクロージャから先頭の 2 ドライブがバインドされます。 Navicli –h <ip アドレス> createrg 55 0_1_0 1_1_0 0_1_1 1_1_1 DAE0 ドライブとのバインド 完全な電源障害が発生した場合は、SPS（スタンバイ電源装置）によって、バッテリ駆動電源が SP およびヴォール ト・ドライブを含むエンクロージャに供給されます。これにより、ストレージ・システムは、書き込みキャッシュの 内容をドライブに保存できるようになります。 ただし、ヴォールト以外のストレージ・システム DAE への電源供給は保持されません。ストレージ・システムが再 起動すると、BV（バックグラウンド・べリファイ）処理を使用して、未処理の I/O を持つ LUN がチェックされます。 これにより、電源障害時に進行していて不完全に終わった書き込みがなかったことを確認します。 BV は優先度を指定する操作です。この操作によって、ストレージ・システムが、ASAP、High、Medium、Low の速 度でロードされます。その方法は、再構築操作のストレージ・システムへの影響とほぼ同じですが、ドライブ速度は 再構築の場合の約半分です。BV のデフォルトの優先度は Medium です。この設定では、特に SP 障害からのリカバ リ時は、本番ワークロードにはほどほどの効果しかありません。 ヴォールト・エンクロージャ（CLARiX のモデルにより、DPE、エンクロージャ 0、最初の DAE のいずれか）内のド ライブおよびヴォールト・エンクロージャ外のドライブとバインドされている LUN では、再構築が必要となる場合 があります。 起動時の再構築を防ぐには、ヴォールト・エンクロージャ内またはそれ以外のエンクロージャ内にあるすべてのドラ イブでグループを作成します。グループを分割する場合は、次のガイドラインに従います。 RAID 1 のグループを、ヴォールト・エンクロージャとその他の DAE の双方にまたがって分割しない。 RAID 5 の場合は、ヴォールト・エンクロージャ外に 2 つ以上のドライブがあることを確認する。 RAID 6 の場合は、ヴォールト・エンクロージャ外に 3 つ以上のドライブがあることを確認する。 RAID 1/0 の場合は、最低 1 つのミラー（プライマリ・ドライブとセカンダリ・ドライブの双方のペア）がヴォー ルト・エンクロージャ外となるようにする。 LUN のプロビジョニング LUN は、物理 RAID グループ上にオーバーレイされている論理構造です。基盤となる RAID グループおよびそのドラ イブと同様に、ストレージ・システム上で LUN をプロビジョニングする際は、ワークロードのプライマリ I/O タイ プ、容量の要件、LUN の使用率を考慮する必要があります。49ページの「RAID グループ」セクションが、さまざま なタイプおよび容量の RAID グループを作成する際のパフォーマンスへの影響を理解するうえで役立ちます。 大容量の LUN や LUN の拡張が必要な場合は、56ページの「MetaLUN」セクションを参照してください。 I/O タイプ別の LUN のプロビジョニング ランダム I/O を特徴とするワークロード環境では、使用可能なドライブと構成済みの RAID グループを考慮して、効 果的な数の RAID グループにワークロードの LUN を分散させることが賢明です。 シーケンシャル I/O を特徴とするワークロードでは、ワークロードの LUN を分散させる RAID グループの数をできる 限り抑えて、RAID グループが同じタイプの I/O を実行し続けるようにすると効果的です。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 55 ストレージ・システムのベスト・プラクティス ストレージ・システムで複数の I/O タイプが処理されている場合は、別々の I/O タイプをサポートしている LUN をで きる限り離しておく必要があります。つまり、可能であれば、主にランダム I/O のワークロードをサポートしている LUN を、主にシーケンシャル I/O のワークロードをサポートしている LUN と同じ RAID グループには配置しないで ください。 使用率別の LUN のプロビジョニング ストレージ・システム内のアクティブな RAID グループはすべて使用率が同じくらいであることが理想です（LUN と は、1 つ以上の RAID グループ上に構築された、ホストが認識できる論理構成であり、RAID グループの使用率を生 成します）。これは、ストレージ・システムのリソースの最も効率的な使用法ですが、これが該当することはまれで す。常に、一部の LUN がホット LUN になり、残りの LUN は本質的にアイドルになる場合があります。ホット LUN とは、ワークロードに関与している LUN のことです。ホット LUN により、基盤となる RAID グループのドライブ使 用率が、ストレージ・システム上で同様のタスクを実行する RAID グループの平均よりも大幅に高くなります。スト レージ・システムのパフォーマンスを最適にするには、ストレージ・システム全体で RAID グループのドライブ使用 率を均等にする必要があります。 Navisphere Analyzer では、ストレージ・システム全体での LUN の分散方法を決定するための、ドライブ使用率に関 する情報が提供されます。Navisphere Analyzer の使用方法については、Powerlink から入手できる「EMC Navisphere Analyzer Administrator’s Guide」を参照してください。 複数の LUN で 1 つの RAID グループが共有されている場合は、使用率の高い LUN を使用率の低い LUN に合わせる ことによって使用率を平均化するか、平均的な使用率の LUN を RAID グループ上の他の平均的な使用率の LUN と合 わせることによってストレージ・システム上の LUN の全体的な RAID グループ使用率を平均化します。ワークロー ドが主としてランダムである場合は、平均化は、容量、可用性、パフォーマンスの要件を満たすための効果的な数の RAID グループにわたって行われます。ワークロードがシーケンシャルである場合は、平均化は、容量、可用性、パ フォーマンスの要件を満たすためのできる限り尐数の RAID グループにわたって行われます。 LUN を分散させるもう 1 つの方法は、使用するタイミング別です（一時的な割り当て）。すべての LUN が一貫して アクティブとなっているわけではありません。たとえば、営業日のワークロードを午前 8 時から午後 8 時までサポー トしている LUN は、この時間帯の使用率が最も高くなります。この時間帯外は、使用率が低いか、アイドル状態に なっている可能性があります。全体的な使用率を平均化するには、同じ RAID グループに、24 時間のうち別の時間帯 にアクティブになる LUN を配置します。 同じワークロードの使用率の高い複数の LUN を同じ RAID グループに一緒に配置する必要がある場合は、RAID グ ループ上に隣り合わせ（間に別の LUN が入っていない状態）で配置します。これにより、ドライブのシーク距離 （時間）が最短になり、これらの使用率の高い LUN の間で最適なパフォーマンスが得られます。この操作を行うには、 Navisphere CLI が必要です。 MetaLUN マルチ RAID グループ metaLUN では、ドライブを追加することによって、使用可能な IOPS が増加します。 MetaLUN は、単一の RAID グループでホストされている LUN で、ストレージ容量が増加している LUN のプロビ ジョニングにも対応しています。 作成方法を含む metaLUN の詳細については、ホワイト・ペーパー「EMC CLARiiON MetaLUNs: Concepts, Operations, and Management」を参照してください。 CLARiX ストレージ・システムでは、metaLUN は RAID グループの上のレイヤーとして実装されます。機能的には、 ホスト上のボリューム・マネージャのアプリケーションに似ています。ただし、metaLUN とボリューム・マネー ジャの間には重要な違いがあります。 56 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス 単一の SCSI ターゲットと多数の SCSI ターゲット ボリューム・マネージャ・ストライプを作成するには、ホストが LUN のすべてのコンポーネントにアクセスできる ようにする必要があります。metaLUN を作成するには、1 つの SCSI LUN のみをホストにマップします。metaLUN を構成する複数の LUN は、ホストでは認識されません。このことは、次の場合に管理者にとってメリットがあります。 OS の制約によりホストで使用可能な LUN が制限されている場合。 ホストに LUN を追加することにより、SCSI デバイスの番号が再設定される場合。デバイス・エントリをク リーンアップするためには、カーネル再構築が必要になる場合がよくあります。 これらの場合、ボリューム・マネージャの代わりに metaLUN を使用すると、ホストでの管理が単純化されます。 ボリューム・マネージャが存在しない場合 オペレーティング・システムのすべてにボリューム・マネージャ・サポートがあるわけではありません。MSCS （Microsoft Cluster Services）を使用する Microsoft Windows Server 2000/2003 クラスタは、ダイナミック・ディスク を利用できません。この場合は、metaLUN を使用すると、拡張可能なボリューム、ストライプ・ボリューム、連結 ボリュームを、これらのシステムに提供できます。 ボリュームのレプリケーション CLARiX レイヤー製品（SnapView™、MirrorView™、SAN Copy™）を使用してストレージ・システムでボリューム をレプリケーションする場合、使用可能なイメージでは、スプリットを一貫して処理する必要があります。 metaLUN はレプリケーションを単純化します。 ボリューム・アクセスの共有 ストライプ・ボリュームまたは連結ボリュームでホスト間の共有アクセスを有効にする必要があるが、ボリューム・ マネージャで共有アクセスが許可されない場合は、metaLUN を使用できます。metaLUN は両方のホストのストレー ジ・グループに配置されます。 ストレージ・プロセッサの帯域幅 ボリューム・マネージャのボリュームと metaLUN の重要な違いは、metaLUN は 1 つの CLARiX ストレージ・システ ム上の 1 つのストレージ・プロセッサによって、すべて処理されることです。ボリュームが異なる SP 上の LUN で 構成されることができるので、1 つのボリュームに非常に広い帯域幅が必要な場合は、ボリューム・マネージャが最 適なアプローチです。ボリューム・マネージャでは、多数のストレージ・プロセッサの総帯域幅でストレージにアク セスできます。 ボリューム・マネージャとコンカレンシー 「広帯域幅用の Plaid」のセクションで指摘したとおり、ホスト・ストライプ・ボリュームを使用すると、複数のボ リューム・ストライプ・セグメントで構成されるリクエストのマルチスレッドと同じ効果があります。これにより、 ストレージ・システムへのコンカレンシーが増大します。コンポーネント LUN の多重送信はストレージ・システム で実行されるので、metaLUN ではマルチスレッドの効果はありません。 metaLUN の使用法と推奨事項 metaLUN には、ストライプ、コンカチネーション、ハイブリッドの 3 つのタイプがあります。このセクションでは、 一般的な推奨事項を記載します。詳細については、metaLUN の作成および各タイプの利点の比較などを説明した後 述のサブセクションを参照してください。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 57 ストレージ・システムのベスト・プラクティス metaLUN は次の場合に使用します。 ストレージの大規模な統合が必要な場合（ボリュームごとに多数のドライブが必要） LUN 拡張が必須の場合 metaLUN の構成時には、コンポーネント LUN タイプ、metaLUN タイプ、ストライプ・マルチプライアを選択でき ます。 コンポーネント LUN タイプ metaLUN に含める LUN をバインドするとき、バインドする LUN のタイプは、metaLUN に必要な I/O パターンを反 映する必要があります。RAID タイプごとに、このホワイト・ペーパーで推奨したものに I/O パターンを一致させて ください。 コンポーネント LUN をバインドするときは、次の推奨事項が適用されます。 metaLUN での使用のために LUN をバインドする際は、必ずデフォルトのストライプ・エレメント・サイズ （128 ブロック）を使用します。 読み取りおよび書き込みキャッシュを必ず有効にします。デフォルトの設定を使用します。 コンポーネント LUN のライト・アサイド・サイズがデフォルトの 2048 であることを確認します。 4 ドライブ（3+1）以上の RAID 5 グループを使用します。 4 ドライブ（2+2）以上の RAID 1/0 グループを使用します。 将来的に RAID グループを拡張する見込みがある場合は、8 ドライブ（6+2）の RAID 6 グループを使用します。 ストライプの割り当ての調整のためにコンポーネント LUN オフセットを使用しないようにしてください。 metaLUN には独自のオフセット値があります。 metaLUN タイプ 通常、ストライプ metaLUN コンポーネントは、最も予測可能なパフォーマンスを提供するため、可能な限り使用し てください。1 つの LUN の metaLUN へのコンカチネーションは便宜上提供されていますが、パフォーマンスを重視 しないボリュームの拡張に適している可能性があります。 10 GB 10 GB 10 GB + 10 GB 20 GB 20 GB 20 GB 20 GB ハイブリッドの metaLUN では、コンカチネーションとストライプを組み合わせています。このアプローチは、スト ライプ拡張のコストに対応するために使用します。ストライプ metaLUN を、別のストライプ・コンポーネントとの コンカチネーションにより拡張できます。これにより、ストライプ・コンポーネントの予測可能なパフォーマンスが 確保され、既存のデータを再度ストライプせずにストライプ metaLUN を拡張できます（再度ストライプする操作の 実行中は、パフォーマンスに影響します）。この点については、図 3を参照してください。 80 GB – original striped metaLUN + 40 GB striped component 図3 ハイブリッドのストライプ metaLUN 理想的には、拡張ストライプ・セットの LUN は、元のストライプ・コンポーネントと同じ RAID タイプとジオメト リの RAID グループに分散します。これを行う最も直接的な方法は、ベース・コンポーネントと同じ RAID グループ を使用する方法です。領域が使用可能になるように、まず RAID グループが拡張されます。 58 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス metaLUN ストライプ・マルチプライア ストライプ・マルチプライアは、metaLUN ストライプ・セグメントのサイズを次のように決定します。 metaLUN ストライプ・セグメント・サイズ=ストライプ・マルチプライア×ベース LUN ストライプ・サイズ metaLUN ストライプ・セグメント・サイズは、任意のコンポーネント LUN で受信する最大の I/O です。 広帯域幅パフォーマンスおよびランダム・アクセスでは、約 1 MB の metaLUN ストライプ・エレメントが必要です。 さらに、基になる RAID グループを拡張することもできます。metaLUN ストライプ・エレメントが、拡張コンポー ネント LUN にフル・ストライプを書き込むのに十分な大きさであることを確認してください。 ストライプ・マルチプライアを設定するには、次の規則に従います。 RAID 0 を使用している場合を除き、コンポーネント LUN をホストする RAID グループの構成には、4 つ以上の ドライブを含むグループを使用します。 選択したグループ・サイズに有効なドライブ数を決定します。たとえば、6 ドライブ（3+3）の RAID 1/0 は 3 で す。5 ドライブ（4+1）の RAID 5 は 4 です。 有効なドライブ数のマルチプライアを、metaLUN ストライプ・マルチプライアの表から選択します。 表13 MetaLUN ストライプ・マルチプライア コンポーネント RAID グループの 有効なドライブ metaLUN ストライプ・ マルチプライア metaLUN ストライプ・ エレメント 2 8 1024 3 6 1152 4 4 1024 5–7 3 960 – 1344 8 2 1024 確かでない場合は、metaLUN ストライプ・マルチプライアにはデフォルトの 4 を使用してください。 metaLUN アライメント・オフセット metaLUN で SnapView または MirrorView を使用する場合は、metaLUN アライメント・オフセット値をゼロのままに します。ディスク・ユーティリティを使用し、パーティション・オフセットの調整を行います。 metaLUN および再構築 metaLUN の RAID グループで 1 台のドライブに障害が発生すると、metaLUN が再構築されるまで、metaLUN の全 体的なパフォーマンスに悪影響があります。通常、SATA ドライブと FC ドライブでは、正常な運用時に（個々の RAID グループ上の LUN に比べて）マルチ RAID グループ metaLUN で使用可能な IOPS が増えるという利点の方が、 コンポーネント RAID グループのうちの 1 つでまれにドライブ障害があった場合などに発生する再構築ペナルティを 上回ります。ASAP 再構築の場合、metaLUN のスループットの低下率は、RAID グループの再構築に必要なドライブ が metaLUN のすべてのドライブの幅に占めるパーセンテージによって概算できます。ただし、再構築の設定が High、 Medium、または Low の場合、RAID グループの構築自体で発生する劣化は 10%未満で、metaLUN 全体は本番速度と ほぼ同じ速度で実行されます。 metaLUN 拡張戦略 長期的な拡張計画での metaLUN の使用の戦略は複数あります。戦略を作成するには、まず目的を特定します。次の セクションで説明するアプローチの目的は次のとおりです。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 59 ストレージ・システムのベスト・プラクティス 本来なら多数のドライブに分散したランダム・データの局所的なバーストの分散 良好なシーケンシャル/帯域幅パフォーマンス 容量の効率的な使用 デバイスの柔軟な拡張 これらの目的は、metaLUN ユーザーの大半に当てはまります。 拡張モデルの初期構成 このソリューションの初期設定の規則は図 4に示されています。規則は、次のとおりです。 初期展開の容量に必要なドライブを配置する。 適度なサイズの RAID グループを作成する。 RAID 1/0 には 4 台または 6 台のドライブ（3+3）を使用する。 RAID 5 または RAID 3 には 5 台のドライブ（4+1）を使用する。 RAID 6 には 10 台のドライブ（8+2）を使用する。 RAID グループを 4～8 つのグループのセットに編成する（必要なランダム I/O の比率が高い場合は、使用する 1 セットあたりのグループ数を増やします）。 各 metaLUN が所属する RAID グループ・セットを決定する。 metaLUN サイズを RAID グループ・セット内の RAID グループの数で割ることにより、各計画 metaLUN のコン ポーネント LUN サイズを決定する。 セット内の各 RAID グループの metaLUN ごとにコンポーネント LUN を作成する。 それぞれのセットのすべての RAID グループに分散した LUN から metaLUN を形成する。図 4は、metaLUN の セットおよびその RAID グループ・セットの例です。 MetaLUNs 1.1 TB 4 RAID groups, each 5-disk RAID 5 1.1 TB Useable Base LUN Size MetaE: 200 GB 50 GB * 4 LUNS MetaF: 500 TB 125 GB * 4 LUNS MetaG: 200 GB 50 GB * 4 LUNS MetaH: 200 GB 50 GB * 4 LUNS Group 1 Group 3 Group 2 Group 4 Each RAID group hosts 4 component LUNs, 1 for each metaLUN 図4 metaLUN のストレージの初期分散 図 5では、各 metaLUN は RAID グループごとに 1 つの LUN で構成されていることに注意してください。各 LUN の 負荷はそのセットのすべての RAID グループに均等に分散されます。ただし、他の RAID グループ・セットからはこ れらの metaLUN へのデータ・アクセスはできません。 では、RAID グループ・セットを使用する理由は何でしょうか。metaLUN がそのセットの外に拡張することを認めな いようにすれば、ドライブ・レベルでの影響を制御するフェンシングのレベルを決定できます。たとえば、1 つの RAID グループ・セットは多数のファイル・サーバ用であり、別の RAID グループ・セットは RDBMS データ・テー ブルに使用し、RAID 1 グループの普通のペアは RDBMS ログ・デバイスとして使用できます。この点については、 図 5を参照してください。 60 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス 4 x 8-disk RAID 1/0 1.1 TB Useable R 10 MetaLUNs 1.1 TB Base LUN Size MetaA: Oracle1 63 GB * 4 LUNS MetaB: Oracle 2 113 GB * 4 LUNS MetaC: TEMP, RBS 70 GB * 4 LUNS MetaD: Staging 50 GB * 4 LUNS R 5 MetaLUNs 1.1 TB Base LUN Size MetaE: NFS Share 1 50 GB * 4 LUNS MetaF: NFS Share 2 125 GB * 4 LUNS MetaG: Oracle Archive 50 GB * 4 LUNS MetaH: Dumps 50 GB * 4 LUNS 4 x 5-disk RAID 5 1.1 TB Useable These 4 LUNS make 1 meta (D) Logs 1 Logs 2 RAID 1 pairs exposed as normal LUNs A RAID group with 4 component LUNs 図5 RAID グループ・セットと metaLUN でのデータ・フェンシングの例 図 5に示した例では、NFS 共有 metaLUN へのアクセスによって、Oracle サーバの独自のデータ・テーブルまたはロ グへのアクセスが妨げられることはありません。 MetaLUN の拡張 次のステップでは、拡張の戦略を設定します。拡張の目的は次のとおりです。 多数のドライブ間でデータの分散を維持する 容量を効率良く使用する これらの目的を達成するためのアプローチは次のとおりです。 metaLUN の容量が予測可能な場合、セット内の既存の RAID グループにドライブを追加します。 metaLUN のセットの RAID グループで拡張 LUN をバインドします。 拡張 LUN を新しいストライプ・コンポーネントとして metaLUN に追加します。 MetaLUN のベース LUN スタックまたはベース LUN のローテーション RAID グループ 1 セットから複数の metaLUN を作成する場合は、各 metaLUN のベース LUN の RAID グループを ローテーションします。ローテーションを行うと、各 metaLUN のベース LUN は、metaLUN を構成する RAID グ ループとは別の RAID グループに配置されます。これを行うと、すべての metaLUN の RAID グループに I/O ロード が均等に分散されます。一例として、A～D の 4 つの metaLUN が、RAIDGroup1、RAIDGroup2、RAIDGroup3、 RAIDGroup4 というラベルの付いた 4 つの RAID グループを使用して LUN 上に作成されている場合があります。最 初の metaLUN（Meta A）のベース LUN を、RAIDGroup1 に定義します。2 番目の metaLUN（Meta B）のベース LUN を、RAIDGroup2 に定義します。Meta C のベース LUN を RAIDGroup3 に定義します。MetaLUN D のベース LUN を RAIDGroup4 に定義します。図 6で、この例を説明します。各色のストライプは、異なる metaLUN を表しま す。各メタのベース LUN は異なる RAID グループにあります。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 61 ストレージ・システムのベスト・プラクティス Meta A Meta B Meta C Meta D MetaLUN Base LUN RAIDGroup1 RAIDGroup2 RAIDGroup3 RAIDGroup4 図6 metaLUN のベース LUN のスタック metaLUN 内の LUN のローテーションの逆を、LUN の垂直ストライピングと呼びます。垂直ストライピングでは、す べてのベース LUN が同じ RAID グループに配置されます。metaLUN 内では、LUN の垂直ストライピングは避けてく ださい。垂直ストライピングでは、すべての LUN のメタデータが同じ RAID グループに配置されます。多くの場合、 これによって RAID グループの 1 台のドライブの使用率が非常に高くなります。また、大きい I/O やシーケンシャル I/O によって、垂直にストライピングされた RAID グループの複数の広範囲に分離された領域にリクエストが送信さ れる場合があります。この結果、リクエストごとのドライブ・シークが多くなり、RAID グループ上のすべての LUN のレスポンス・タイムが増加します。 LUN の縮小 従来の LUN および metaLUN では、容量を縮小して、未使用のストレージ容量を再利用する場合があります。このプ ロセスを LUN の縮小と呼びます。LUN の縮小は、FLARE のリビジョンに依存する機能です。FLARE リビジョン 29.0 以降で使用できます。LUN の縮小は、Microsoft Server 2008 オペレーティング・システム以降が搭載されてい るホストでのみサポートされます。 LUN の縮小は、ホスト・ボリュームの縮小と LUN ボリュームの縮小の 2 段階のプロセスです。ホスト・ボリューム の縮小は、MS のサーバ・ホストから、ディスク管理機能を使用して実行されます。LUN ボリュームの縮小は、ホス ト上でユーザーが指定し、CLARiX 上で実行されます。どちらのステップも、ワークロードが存在する状態で実行で きます。LUN ボリュームの縮小ステップでは、「DISKRAID.EXE」アプリケーションをホストにインストールする 必要があります。これは、最初のステップ後に自動的に行われます。LUN の縮小の実行には数秒（1 分未満）必要 です。 LUN の縮小の前にファイル・システムのデフラグを実行して、LUN の容量を統合する必要があります。これにより、 最大量の LUN を縮小できます。 LUN を縮小すると、LUN の基盤となる RAID グループが断片化された状態のままになる場合があります。LUN の縮 小によって得られる RAID グループの容量を最大限にするには、RAID グループのデフラグが必要な場合があります。 FLARE リビジョン 29.0 以前では、RAID 6 グループのデフラグはサポートされていません。つまり、RAID 6 の LUN を縮小後は、RAID 6 グループ上の領域を全部は使用できなくなる場合があります。RAID 6 グループをデフラグする 際の推奨事項については、「RAID グループ」セクションを参照してください。 仮想プロビジョニングとシン LUN 仮想プロビジョニングは、LUN のシン・プロビジョニングに対応しています。シン LUN では、1 つのアプリケー ションに対して、物理的に利用可能な容量以上のストレージを提供することができます。物理的に利用できないスト レージを提供することにより、ストレージ・システムの過剰プロビジョニングや容量の使用率低下を回避できます。 最終的にシン LUN への物理ストレージの追加が必要になった場合、容量は、システム停止を伴わずに自動的にスト レージ・プールから追加されます。また、ストレージ・プールの容量は、プールのシン LUN に影響することなく、 システムを停止せずに差分追加できます。 仮想プロビジョニングは、ライセンス付与が可能な機能であり、FLARE リビジョン 28.0 以降が必要です。 シン LUN のプロビジョニングは、Navisphere を使用して、Navisphere CLI でも利用可能なコマンドを使用して実行 します。 62 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス シン・プロビジョニングされた LUN は、大部分を自動的に維持できます。これにより、ストレージ・システムを維 持するうえで必要な管理処理が合理化され、軽減されます。ストレージ・プールを適切にプロビジョニングする計画 に初期投資すれば、シン LUN のパフォーマンス、容量使用率、可用性が継続的に最適になります。 概念上、シン・プロビジョニングされたストレージ・プールは、従来のドライブの RAID グループ構成上にオーバー レイされているファイル・システムです。このファイル・システムにより、シン・プロビジョニングされた LUN の パフォーマンスと容量使用率にオーバーヘッドが生じます。また、シン・プロビジョニングでは、可用性をストレー ジ・プール・レベルで考慮する必要があります（従来の LUN では、可用性は RAID グループ・レベル）。より高い レベルのパフォーマンス、可用性、容量使用率が必要なワークロードでは、引き続き従来の LUN を使用してください。 従来の LUN と同様に、ストレージ・プール・ドライブの数および容量と、予想される LUN 数およびワークロードの 要件とのバランスを図る必要があります。一般的には、従来の LUN に関連するベスト・プラクティスがすべてシン LUN に適用されます。まずは、推奨される初期プール・サイズから始めて、推奨される増分サイズで拡張して、後 述の「ガイドライン」セクションに示す推奨される最大プール・サイズを大きく超えないようにすることをお勧めし ます。 仮想プロビジョニングの詳細については、Powerlink から入手できるホワイト・ペーパー「EMC CLARiiON Virtual Provisioning」を参照してください。 ストレージ・プールの作成 パフォーマンスを最適にするためには、尐数の同種のシン・ストレージ・プールを、多数のストレージ・デバイスで 作成します。同種のプールとは、ドライブを最初に割り当てたときの各ドライブのタイプ、速度、サイズが同じもの です。 ストレージ・プールの数 ストレージ・システムごとのストレージ・プールの数はモデルによって異なります。表 14に、CLARiX のモデルごと の最大数を示します。 表14 ストレージ・システムごとのシン・プロビジョニング・ストレージ・プール数 CLARiX モデル ストレージ・システム ごとのシン・ストレージ・ プールの最大数 CX4-120 20 CX4-240 40 CX4-480 40 CX4-960 60 ストレージ・プールのサイズ ストレージ・プール内のドライブの最大数は、ストレージ・システムのモデルによって異なります。RAID 5 を使用 すると、プール内のデバイス数は最小になります。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 63 ストレージ・システムのベスト・プラクティス 表15 シン・プロビジョニング・ストレージ・プールのストレージ・デバイスの構成 CLARiX モデル RAID 5 の最小 プール・サイズ （ドライブ数） 最大 プール・サイズ （ドライブ数） 全プール内の最大 合計ドライブ数 （ドライブ数） CX4-120 3 40 80 CX4-240 3 80 160 CX4-480 3 120 240 CX4-960 3 240 360 プールを作成する際の推奨事項は次のとおりです。 シン・ストレージ・プールには、ファイバ・チャネル・ハード・ディスク・ドライブをお勧めします（全体的な パフォーマンスと可用性が高いため）。 プールを作成する際は、タイプ、速度、サイズが同じストレージ・デバイスを使用してください。特に、ファイ バ・チャネルと SATA ハード・ディスク・ドライブを同じプールで使用しないでください。 通常は、プールには RAID 5 レベルを使用することをお勧めします。これにより、プール・ストレージ・デバイ ス数ごとのユーザー・データ容量が最大になります。プールが SATA ドライブで構成されていて、最終的に合 計ドライブ数が 80 を超える場合は、RAID 6 を使用します。大容量（500 GB 超）ドライブで構成されるプール では、RAID 6 を使用する必要があります。 最初は、実用的な最大数のハード・ディスク・ドライブでプールをプロビジョニングします。RAID 5 プールの 場合は、最初のドライブ割り当てで 5 つ以上のドライブと、5 で均等に割り切れる容量を使用します。RAID 6 プールの最初の割り当てには、8 で均等に割り切れる容量を使用します。 – RAID 5 プール用に 15 ドライブを指定する場合 - 仮想プロビジョニングによって 5 ドライブ（4+1）の RAID グループが 3 つ作成されます。これが最適なプロビジョニングです。 – RAID 5 プール用に 18 ドライブを指定する場合 - 仮想プロビジョニングによって 5 ドライブ（4+1）の RAID グループが 3 つと、3 ドライブ（2+1）の RAID グループが 1 つ作成されます。このプロビジョニングはあ まり最適ではありません。 – RAID 6 プール用に 10 ドライブを指定する場合 - 仮想プロビジョニングによって 10 ドライブ（8+2）の RAID グループが 1 つ作成されます。追加のグループを作成できないため、標準より大きくなります。RAID グ ループがそれぞれ同じサイズであるため、これは許容されます。 シン LUN プールでは、サブスクライブ容量は、LUN に割り当て済みの容量です。システムを設計するときは、 予想されるサブスクライブ容量が、ストレージ・システムのプールで許容されている最大ドライブ数によって提 供される容量を超えないことを確認してください。 ストレージ・プールの拡張 パフォーマンスを最適にするために、ストレージ・プールの拡張は頻繁には行わず、プールのストレージ・デバイス の元の特性を維持して、効果的な最大限の拡張を行ってください。 プールを拡張する際の推奨事項は次のとおりです。 ［%フルのしきい値］パラメータ（デフォルトは 70%）を、プール・サイズと、アプリケーションによる容量消 費速度に合わせて調整します。小容量のドライブのみで構成されるプールでは、使用可能容量が短時間で消費さ れます。このタイプのプールでは、アラートの閾値を小さくする必要があります。容量の消費速度が遅い、大容 量のプールでは、大きい閾値を使用する必要があります。たとえば、最大サイズのプールの場合、［%フルのし きい値］パラメータの初期値として 85%をお勧めします。 プールを拡張する際は、元のプールと同じタイプ、同じ速度のハード・ディスク・ドライブを使用します。 64 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス プールを拡張する際は、1 回の増分サイズを大きくしてください。RAID レベル 5 のプールの場合は、追加する ドライブ数を、5 で均等に割り切れる、5 以上の数にします。RAID 6 プールは、8 で割り切れるドライブ数ずつ 拡張してください。 プール内のハード・ディスク・ドライブの最終的な最大数は控えめにしてください。ストレージ・デバイス数の 尐ないプールを多数使用した方が、ストレージ・デバイス数の多いプールを尐数使用した場合より可用性が向上 します。 拡張ドライブは、ハード・ディスク・ドライブの最初の割り当てと同じ容量である必要はありません。ただし、拡張 に使用するすべてのドライブの容量を同じにして、全体的な容量使用率を最大限にすることをお勧めします。 ストレージ・プールの作成および拡張のガイドライン 表 16は、バランスのとれた RAID 5 ベースのストレージ・プールを迅速に作成および拡張するための推奨事項を示し ています。ワークロードごとに、容量、パフォーマンス、可用性の要件が大幅に異なることに注目してください。前 述の各セクションの情報を使用して、個々の要件に対応するように、これらの推奨事項をカスタマイズすることが必 要な場合もあります。 たとえば、RAID 5 の最小プール・サイズは 3 ドライブと指定されていますが、5 ドライブを使用するとパフォー マンスと容量使用率が向上し、推奨値以上（5 で均等に割り切れる数）では、パフォーマンスと容量使用率がさらに 向上します。 表16 ストレージ・プールのストレージ・ドライブ割り当ての推奨値 CLARiX モデル 推奨される RAID 5 の初期 プール・サイズ （ドライブ数） 推奨される増分 RAID 5 拡張 （ドライブ数） 推奨される RAID 5 の最大 プール・サイズ （ドライブ数） 推奨されるストレージ・ システムごとのシン・ ストレージ・プール （プール数） CX4-120 5 5 20 5 CX4-240 10 10 40 10 CX4-480 20 20 60 30 CX4-960 20 20 80 50 シン LUN の作成 従来の LUN に対する一般的な推奨事項がシン LUN にも適用されます（55ページの「LUN のプロビジョニング」セク ションを参照）。 作成可能な最大容量のシン LUN は 14 TB です。 ストレージ・システムで作成されたシン LUN の数は、ストレージ・システムの LUN ホスト予算の合計から差し引か れます。ストレージ・プールごとに多数のシン LUN が作成可能です（表 17）。表内で、「最大ストレージ・システ ム LUN（全タイプ）」の列は、従来の LUN、metaLUN、スナップショット LUN、シン LUN を示します。ホストで 認識できる LUN の最大数は、表内で別個に示されています。作成済み、または作成予定の LUN の数およびタイプに 注意してください。多数のシン LUN で構成される尐数のシン・プールを使用すると、ストレージ・システムのホス トで認識可能な最大数の LUN の大部分に簡単に対応できます。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 65 ストレージ・システムのベスト・プラクティス 表17 シン LUN プロビジョニングの推奨事項 CLARiX モデル 最大ストレージ・ システム LUN （全タイプ） ホストで認識 可能な LUN の 最大数 ストレージ・ プールごとのシン LUN の最大数 CX4-120 1636 1024 512 CX4-240 1636 1024 1024 CX4-480 5220 4096 2048 CX4-960 6244 4096 2048 シン LUN はトレスパスしないでください。シン LUN の SP オーナー権を変更すると、パフォーマンスに悪影響が生 じる場合があります。シン LUN のトレスパス後も、シン LUN の独自の情報は元のオーナーである SP の制御下に残 ります。トレスパスされた LUN の I/O は、引き続き元のオーナーである SP によって処理されます。この結果、両方 の SP を使用して I/O が処理されることになります。1 つの I/O で両方の SP を使用すると、I/O の所要時間が長くな ります。最終的には、CLARiX の ALUA 機能により、トレスパスされたシン LUN とその独自情報はいずれも新しい オーナーである SP の単独制御下でリンクされる場合があります。ただし、それまでの間、レスポンス・タイムは長 くなります。 転送速度重視のワークロードでシン LUN の使用を計画する場合は、シン LUN に必要なストレージを事前に割り当て る必要があります。この事前割り当てにより、プールのシン LUN 内でシーケンシャル・アドレス指定が行われ、帯 域幅のパフォーマンスが高くなります。事前割り当てにはいくつかの方法があります。従来の LUN から移行する方 法、ファイル・システムの完全フォーマットを実行する方法、ホスト・ファイル・システム内からファイル書き込み を実行する方法、ホスト・アプリケーション内から単一の Oracle テーブルを作成する方法などです。また、同時に 実行可能な事前割り当ては、ストレージ・プールごとに 1 つだけです。1 つのプールで複数のシン LUN を同時に事 前割り当てすると、SP の全体的なパフォーマンスが低下する場合があります。 プール内で作成されるシン LUN ごとに、固定容量のオーバーヘッドが関連づけられています。作成予定の LUN の数 （特に割り当て容量の小さいプールの場合）を考慮に入れてください。 シン LUN は、いずれもストレージ・プールを起源とするメタデータとユーザー・データの両方で構成されています。 シン LUN のメタデータは、プールのユーザー・データ容量から差し引かれる容量オーバーヘッドです。どんなサイ ズのシン LUN でも、約 3 GB のプール容量が消費されます。1 GB をわずかに上回る容量がメタデータに、最初の 1 GB のプール容量がユーザー・データに使用されます。追加の 1 GB のプール容量は、使用量の増加を予測して、最 初の GB が消費される前にプリフェッチされます。これで合計約 3 GB になります。このメタデータの割り当て量は、 最小規模から最大規模（2 TB 超のホストに依存）の LUN まで、ほぼ同じです。LUN のユーザー容量が増加すると、 ユーザー・データの最初の 1 GB から追加のメタデータが割り当てられます。 消費される容量を見積もるには、次の経験則に従います。 消費容量=（ユーザー消費容量×0.02）+3 GB たとえば、500 GB のユーザー・データ（ユーザー消費容量）が書き込まれているシン LUN では、513 GB（（500 GB×0.02）+3 GB）がプールから消費されます。 プールをプロビジョニングするときは、メタデータ容量を事前に計画します。それぞれ 10 個の LUN で構成される 2 つのプールを使用すると、20 個の LUN で構成される 1 つのプールより、プールの容量使用率が高くなります。数テ ラバイトのプールでは、メタデータに使用されるプール容量の割合が 1%未満になるため、問題にはなりません。小 容量のプールでは、メタデータで使用される容量の割合が大きくなる場合があります。メタデータによる使用容量と、 計画されている LUN 数に合った初期ユーザー・データに対応できるように、十分な初期容量でプールを作成してく ださい。また、作成済みのシン LUN には十分な容量を割り当ててください。これにより、プール容量の使用率が最 大限の割合になります。 66 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス ストレージ・デバイス CLARiX CX4 シリーズおよび AX4 シリーズでは、以下のタイプのストレージ・デバイスがサポートされています。 ファイバ・チャネル 15k rpm および 10k rpm のハード・ディスク・ドライブ SAS 15k rpm のハード・ディスク・ドライブ SATA 7.2k rpm および 5.4k rpm のハード・ディスク・ドライブ EFD これらのストレージ・デバイスは、パフォーマンスや可用性の特性がそれぞれ異なり、ワークロードに対する適性に も多尐の違いがあります。すべてのストレージ・デバイスが、CX4 および AX4 の全モデルでサポートされているわ けではありません。 ファイバ・チャネルおよび SAS ドライブ・ストレージ 回転速度 15k rpm のファイバ・チャネル・ハード・ディスク・ドライブおよび SAS ハード・ディスク・ドライブを 使用すると、ランダム・リード/ライト要求の処理時間が短縮され、シーケンシャル・リード/ライト処理の帯域幅が 増加します。これらのタイプのドライブは、レスポンス・タイムの要件が厳しいワークロードで要求時間を維持する 必要がある場合に使用します。 SATA ドライブ・ストレージ 7.2k rpm SATA ドライブがワークロードにどの程度適しているかを判断するには、ワークロードのアクセス・タイプ の知識が必要です。SATA ドライブは、容量が大きいため経済的ですが、FC ハード・ディスク・ドライブや SAS ハード・ディスク・ドライブのような高パフォーマンス、高可用性の特性はありません。SATA ドライブを使用する 場合は、次の推奨事項を考慮する必要があります。 シーケンシャル・リード処理の場合：SATA ドライブのパフォーマンスは FC ハード・ディスク・ドライブのパ フォーマンスとほぼ同じ。 ランダム・リード処理の場合：キューの深さが増すと、SATA ドライブのパフォーマンスは FC ドライブに比べ て低下。 シーケンシャル・ライト処理の場合：SATA ドライブのパフォーマンスは FC のパフォーマンスと同等。 ランダム・ライト処理の場合：キューの深さが増すと、SATA ドライブのパフォーマンスは低下。 7.2k rpm の SATA ドライブに加えて、5.4k rpm の 1 TB SATA ドライブもあります。これらのハード・ディスク・ド ライブは、容量が大きく、省電力で、大容量ストレージを提供します。これらのドライブのフル DAE（15 ハード・ ディスク・ドライブ）のみがプロビジョニング可能です。 まとめると、SATA ドライブは、デューティ・サイクルの制限のため、高速での継続的なランダム・ワークロードに は推奨されません。ただし、SATA ドライブには、シーケンシャル・ワークロード用の実用的なオプションがあります。 EFD（エンタープライズ・フラッシュ・ドライブ）ストレージ EFD は、半導体ベースのストレージ・デバイスです。従来の機械式ハード・ディスクに比べてレスポンス・タイム が非常に短く、高いスループットを提供します。適切な状況下では、非常に高いスループットを提供できます。EFD のメリットを十分に活用するためには、特殊なプロパティを考慮に入れて、最適なワークロードと組み合わせる必要 があります。 EFD は、FLARE のリビジョンに依存する機能です。EFD のサポートには、FLARE リビジョン 28.0 以降が必要です。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 67 ストレージ・システムのベスト・プラクティス EFD は、高度にコンカレントな、小さいブロックの、読み取り集中型のランダム I/O ワークロードで最適なパフォー マンスを発揮します。従来のハード・ディスクと比較した場合の容量および EFD のプロビジョニング制限により、 用途が中程度の容量の LUN に制限される場合があります。一般的に、EFD で最大級のパフォーマンスが発揮される のは、LUN が次のような状態の場合です。 ドライブ使用率が 70%を超えている キューの長さ（ABQL）が 12 を超えている 平均レスポンス・タイムが 10 ミリ秒を超えている I/O の読み取り/書き込み比が 60%以上 I/O ブロック・サイズが 16 KB 以下 EFD の詳細については、Powerlink から入手できるホワイト・ペーパー「An Introduction to EMC CLARiiON and Celerra Unified Storage Platform Storage Device Technology」を参照してください。 構成要件 EFD の構成要件には、ハード・ディスクと異なる点がいくつかあります。使用に際しては、次のプロビジョニング 制限が課されます。 EFD は SATA ハード・ディスク・ドライブを含む DAE には取り付けできません。ファイバ・チャネル・ハー ド・ディスク・ドライブとは DAE を共有できます。 EFD には独自のホット・スペアが必要です。他のタイプのドライブを EFD のホット・スペアとして使用するこ とはできません。また、EFD をハード・ディスク・ドライブのホット・スペアとして使用することもできません。 可用性を最適にするには、ホット・スペアとすべてのハード・ディスク・ドライブ・タイプとの比率を最小の 1:30 に維持しながら、1 つ以上の EFD ホット・スペアを使用可能にしておくことが重要です。 EFD は、EFD ベースの RAID グループを含む LUN で構成される metaLUN にのみ含めることができます。 現在、EFD は、EMC の CLARiX ストレージ・システムで、次のユニット数オーダー制限で使用可能です。大き い数値がサポートされています。大規模な EFD 設置環境のリソース使用率の要件については、EMC のパフォー マンス・スタッフに問い合わせてください。 表18 CLARiX の EFD の構成 CLARiX モデル 最小 EFD 最大 EFD CX4-120～CX4-240 2 60 CX4-480～CX4-960 2 120 容量に関する考慮事項 表 19に、デバイスごとの EFD の容量を示します。ストレージ・システム・メタデータにより、バインドされた容量 がフォーマットされた容量よりわずかに尐ないことに注目してください。 表19 EFD の容量 公称容量 （GB） バインドされた 容量（GB） 73 66.60 200 183.41 400 366.76 68 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス CLARiX の使用可能なすべての RAID レベルが、EFD で使用できるハード・ディスク・ドライブによってサポートさ れています。RAID レベルおよび RAID グループ・サイズごとに、ユーザー・データの容量は異なりますが、RAID 5 グループのユーザー・データ容量の比率が、EFD に対するデータ保護も含めて最大です。 EFD ベースの LUN の容量は、ワイド RAID グループまたは metaLUN と呼ばれることもある拡張 RAID グループを使 用することによって、CLARiX モデルで使用可能な最大数の EFD まで拡張できます。CLARiX RAID グループ内の EFD またはハード・ディスクの最大数は 16 個です。 I/O に関する考慮事項 EFD がワークロードにどの程度適しているかを判断するには、必要な容量、I/O タイプ、ブロック・サイズ、アクセ ス・タイプの知識が必要です。また、EFD ストレージ・デバイス独自の機能をさらによく利用するには、アプリ ケーション・スレッド化モデルを十分に理解する必要があります。 EFD では、非常に高い IOPS と短いレスポンス・タイムを提供できます。小さいブロックのランダム・リード処理の パフォーマンスは特に優れており、高いコンカレントなワークロードに特に適しています。小さいブロックとは、4 KB または 4 KB の小さい倍数です。「高度にコンカレント」とは、EFD ベースの RAID グループごとのスレッド数が 32 以上という意味です。 多くの半導体ベースのストレージ・デバイスと同様に、EFD のキャッシュされていない書き込みパフォーマンスは 読み取りパフォーマンスより遅いことに注意してください。EFD のパフォーマンスを最大限に活用するには、書き 込みより読み取り I/O の比率が大幅に大きいワークロードで使用することをお勧めします。 EFD とパリティ RAID 5 グループをデフォルトの設定で使用する際は、次の I/O タイプの推奨事項を考慮してください。 シーケンシャル・リード処理の場合：4 つ以上のスレッドを保証できる場合、EFD で大きいブロックのシーケン シャル・リード処理を行うときの帯域幅は、最大でファイバ・チャネル・ハード・ディスク・ドライブの倍にな ります。これは、EFD には機械式ドライブのようなシーク時間がないためです。 ランダム・リード処理の場合：EFD のランダム・リード処理のパフォーマンスは、CLARiX ストレージ・デバイ スの中で最高です。理想的なブロック・サイズである 4 KB 以下の場合は、スループットは特に高くなります。 ブロック・サイズがこの理想値を超えると、スループットは低下します。 シーケンシャル・ライト処理の場合：シングル・スレッドの書き込み帯域幅では、EFD はファイバ・チャネル・ ハード・ディスク・ドライブより幾分遅くなります。高いコンカレンシーが保証されている場合は、帯域幅が ファイバ・チャネルより幾分大きくなります。 ランダム・ライト処理の場合：EFD のランダム・ライト処理のパフォーマンスは、ファイバ・チャネル・ハー ド・ディスク・ドライブより優れています。4 KB のブロック・サイズを使用した高度にコンカレントなアクセス では、スループットは特に高くなります。ブロック・サイズが大きくなると、スループットは低下します。 最大のスループットを達成するには、高度にコンカレントなワークロードが必要です。ただし、これには、EFD RAID グループを 2 つ以上の LUN にパーティション化するか、SP 間で RAID グループを共有することが必要になる 場合があります。SP 間で RAID グループを共有することは、ハード・ディスク・ベースのベスト・プラクティスと は対照的です。これを使用するには、I/O について深く理解することが必要です。 キャッシュに関する考慮事項 デフォルトで、EFD ベースの LUN では、読み取り/書き込みキャッシュがいずれもオフに設定されています。前述の 各セクションで説明したパフォーマンスは、EFD ベースの LUN のデフォルトのキャッシュ・オフ構成に適用されま す。ただし、適切に動作する特定のワークロードでは、キャッシュ・オン操作でメリットが得られる場合があります。 適切に動作するワークロードでは、キャッシュが飽和状態になるリスクはありません。 特に、小さいブロックのシーケンシャル I/O ベースのワークロードの場合は、キャッシュ・オン操作でメリットが得 られます。たとえば、書き込みキャッシュを結合してフル・ストライプ・ライトを行うことにより、シーケンシャ ル・ライト処理のパフォーマンスを向上させることができます。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 69 ストレージ・システムのベスト・プラクティス ランダム・ライト処理を行うアプリケーションは、EFD でキャッシュを使用する場合と使用しない場合でパフォー マンスへの影響が異なる場合があります。書き込みキャッシュをオンにすると、ホストから見た EFD の書き込みパ フォーマンスは、ハード・ディスク・ドライブ・ベースの書き込みパフォーマンスと同じになります。ただし、バッ クエンド・スループットは、適切にプロビジョニングした場合は、ハード・ディスク・ドライブより高くなります。 キャッシュを使用する操作の対象として、小さいブロックのシーケンシャルなデータベース・ログの書き込みなどが あります。 RAID グループに関する考慮事項 EFD のパフォーマンスおよびストレージ・システム・リソース使用率プロファイルは、RAID グループ・プロビジョ ニングの従来のルールとは異なります。 RAID 5 は、パフォーマンスと可用性が高いため、EFD に最適な RAID レベルです。使用可能なユーザー・データ容 量と公称容量の比率の点で、最も経済的でもあります。 EFD を含むグループでは、RAID グループのサイズに制限はありません。フロントエンド・ポート、SP CPU、個々 のワークロードの I/O に特有のバックエンド・バス使用率など他の要素も、CLARiX 用に EFD を構成する際の重要な 考慮事項です。 一般的に、小さいブロックのランダム I/O ワークロードの場合は、IOPS が必要数に達するまで、または必要な容量 に達するまで、EFD を RAID グループに追加します。大きいブロックのランダムおよびシーケンシャル I/O の場合は、 （4+1）や（8+1）といった小規模な運用が好まれます。これは、ストライプ・サイズが均等であり、キャッシュされ ていない I/O によってフル・ストライプ・ライトが利用される場合があるためです。 EFD が広帯域幅の場合、バックエンド・バスのリソース使用率のバランスを図ることが重要になります。バス帯域 幅の使用率は、同じストレージ・システム・バックエンド・バス上のすべてのストレージ・デバイスに影響します。 EFD の使用率増加によってバス使用率が上昇すると、他のストレージ・デバイスの I/O 要求で使用できる帯域幅が減 尐します。 従来のハード・ディスク・ドライブを使用した RAID グループのバス・バランシングのベスト・プラクティスが、EFD に直接適用されます（「RAID グループのバス・バランシング」セクションを参照）。バックエンド・バスごとの EFD の最大数は、EFD ベースの RAID グループの LUN の構成方法と、アプリケーションで必要な帯域幅によって異なり ます。EFD ベースの RAID グループの LUN に 1 つの SP がアクセスしている場合、使用可能な帯域幅は約 360 MB/秒 です。また、パーティション化されている RAID グループの LUN を両方の SP が所有している場合は、使用可能な帯 域幅は 720 MB/秒です（この帯域幅の分散は、ファイバ・チャネル・ドライブと同じです）。 EFD の再構築 EFD RAID グループの再構築は、主に使用可能なバックエンド・バスの帯域幅による影響を受けます。 RAID グループ内のすべての EFD が同じバックエンド・バス上にある場合、再構築速度はファイバ・チャネルの速度 と同じです（「再構築」セクションを参照）。 パリティ RAID グループの EFD が、使用可能な複数のバックエンド・バスに可能な限り均等に分散されている場合、 再構築速度は、表 20に示すとおりです。 表20 RAID 5 の EFD 再構築速度 優先度 パリティ RAID の速度（MB/秒） Low 2 Medium 6 High 13 ASAP 160 70 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス 使用可能なバス帯域幅の大部分が EFD ASAP 再構築で消費される可能性があることに注目してください。ストレー ジ・システム上の別の場所で、帯域幅に依存するアプリケーションが実行されている場合は、再構築の際に、経済的 な High（デフォルト）、Medium、Low のいずれかの優先度を選択してください。 時間の経過による EFD パフォーマンスの変化 EFD では、いつまでも同じパフォーマンスが維持されるわけではありません。EFD の IOPS 速度は、ドライブが新 しいときの方が、一定期間使用した後よりも高速です。時間の経過とともに EFD のパフォーマンスが低下すること は、ファイル・システムの削除によって解放された容量の再利用方法から生じる副作用です。このドキュメントで経 験則として使用しているパフォーマンス値は、長期に渡って使用してきた EFD の幅広い I/O プロファイルによって 最終的に達成可能な、控えめに見たドライブごとの IOPS 値です。 可用性 可用性とは、ハードウェアまたはソフトウェアに障害が発生した場合（デグレーデッド状態またはモードとも呼ばれ る）に、アプリケーションやデータへのユーザー・アクセスを提供できる、ストレージ・システムの機能のことです。 CLARiX CX4 シリーズのような中規模システムは、単一障害時にデータへのアクセスを提供できるため、可用性の高 いシステムとして分類されます。多くの場合、デグレーデッド・モードでのパフォーマンスは、通常運用時より低く なります。CLARiX の構成を次のように最適化すると、デグレーデッド・モードでのパフォーマンスを向上できます。 RAID グループのプロビジョニング シングル DAE/マルチ DAE プロビジョニング シングル DAE プロビジョニングは、RAID グループの配置を単一の DAE 内に制限することです。これは、水平プロ ビジョニングと呼ぶ場合もあります。シングル DAE プロビジョニングは、Navisphere で RAID グループをプロビ ジョニングする際のデフォルトの方法です。便利で可用性が高いため、シングル DAE プロビジョニングはほとんど の CLARiX RAID グループで使用されます。この標準に従うストレージ管理者は、次のセクションは飛ばして構いま せん。 マルチ DAE プロビジョニングでは、2 つ以上の DAE を使用します。これは、垂直プロビジョニングと呼ぶ場合もあ ります。マルチ DAE プロビジョニングを使用する理由の 1 つは、トポロジーの要件を満たすことです。ある DAE 内 に、必要な RAID トポロジーを構成できるだけのドライブが残っていない場合に、他の DAE からドライブを選択し ます。アレイ・モデルとドライブの配置によって、この構成は複数のバスにまたがる場合とそうでない場合があり ます。 マルチ DAE プロビジョニングは、特にバスの動作に関連するパフォーマンスの要件を満たす目的でも使用できます。 RAID グループは、複数のバスを持つストレージ・システム・モデル上の複数のバスに並列してアクセスできるよう に、意図的に複数の DAE にまたがって構成されます。このような構成を使用するのは次の場合です。 帯域幅の目的が明確に定義されており、負荷を慎重に分散させる必要がある場合 ホスト・アクティビティのバーストによってバスのボトルネックが発生することがわかっている場合 RAID グループで書き込みキャッシュが頻繁にデステージされることにより、ホストの読み取りに支障が出る場合 バスで大きいブロックの I/O 要求が頻繁に行われることにより、小さいブロックの I/O レスポンス・タイムに支 障が出る場合 以前の CLARiX では、リンク・コントローラ・カード（LCC）の障害が発生すると、次に説明するマルチ DAE プロ ビジョニングを使用して、一部の設計者が LUN の可用性を向上させました（LCC は、ドライブのトレイを SP のバ スに接続するデバイスです）。リリース 26 から、新しいメカニズム（次に説明）により、可用性を確保しながら、 同時にデータ保護を維持し、障害によるパフォーマンスへの影響を軽減できるようになりました。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 71 ストレージ・システムのベスト・プラクティス リリース 26 より前は、LUN の自動フェイルオーバー機能（PowerPath トレスパスなどを使用）のない構成で、LCC 障害が発生すると接続が失われる場合に、マルチ DAE プロビジョニングを使用して可用性を向上させていました。 接続が失われることは、その結果としてパフォーマンスが低下することや、RAID データ保護が失われることよりも 大きな問題とみなされていました。マルチ DAE プロビジョニングにより、LCC 障害が発生してもホスト・トレスパ スなしでデータを維持するのに十分なドライブ数を確保することで、フェイルオーバーが回避されていました。RAID 5 の場合、「十分なドライブ数」を確保するには、障害時に失われるドライブが 1 台以下であることが必要で、RAID 10 の場合は、ミラー・ペアごとに失われるドライブが 1 台以下であることが必要でした。ただし、影響を受ける RAID グループは、LCC 修復時のホット・スペアまたは元のドライブへの再構築操作により、パフォーマンスが大幅に低 下する可能性がありました。また、フェイルオーバーは回避されても、完全保護は、再構築が完了するまでリストア されませんでした。使用できるホット・スペアが不十分な場合は、完全なデータ保護が達成されるのは、LCC 障害 が修復された後になってからでした。このトレード・オフにより、データ保護より可用性が優先されました。 LCC 障害が発生した場合、十分なドライブを持たないマルチ DAE RAID グループと、すべてのシングル DAE RAID グループでは、ホスト・トレスパスを使用して（手動で、または自動フェイルオーバーにより）操作を続行する必要 がありました。ピア SP がドライブに引き続き完全アクセスできたため、再構築は回避されました。この戦略では、 可用性よりデータ保護が優先されました。この場合のリスクは、ホストのフェイルオーバー機能のないサイトで LUN 接続が失われることでした。 リリース 26 からは、LCC 障害のある SP で、シングル DAE RAID グループと、使用可能なドライブ数が不十分なマ ルチ DAE RAID グループの両方に関して、オーナー権、可用性、データ保護が維持されます。このことは、新しい内 部 SP リクエスト転送機能によって可能になりました。これにより、ホスト・トレスパスやフロントエンド・パスの 変更なしに、トラフィックをピア SP に分散させることができます。このような場合、再構築ではなくバックグラ ウンド・べリファイ（BV）によってデータの冗長性が維持され、すべてのドライブがオンラインのままになります。 ただし、障害後もドライブ数が十分なマルチ DAE RAID グループでは、引き続き、LCC 修復時にホット・スペアま たは元のドライブへの再構築を行うことによって、データの冗長性が維持されます。さまざまな場合について、以下 にまとめます。 表21 LCC 障害とプロビジョニング タイプ FLARE のリビジョン リカバリ処理 シングル DAE 26 より前 バックグラウンド・べリファイ（BV）（SP トレスパス） マルチ DAE 26 より前 再構築（ドライブ数が十分、トレスパスなし） または BV（ドライブ数が不十分、SP トレスパス） シングル DAE 26 以降 BV（リクエスト転送） マルチ DAE 26 以降 再構築（ドライブ数が十分、トレスパスなし） または BV（リクエスト転送） リクエスト転送によるデータ保護と可用性のメリットがあるため、通常は、シングル DAE RAID グループのプロビ ジョニングをお勧めします。パフォーマンス上の理由でマルチ DAE RAID グループをプロビジョニングする場合は、 LCC 障害時にリクエスト転送を利用するように構成することをお勧めします。この構成は、ドライブをグループ化 することによって行います。RAID 5 には、バスごとに 2 台以上、RAID 6 にはバスごとに 3 台以上のドライブが必要 です。また、RAID 10 では、同じバス上にミラー・ペアがそれぞれ必要です。 72 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス LCC 障害が発生した場合、BV とリクエスト転送がホストのレスポンス・タイムに影響すること、また、障害中に、 分散したアプリケーションの負荷に比例してピア SP の使用率が増加することが予想できます。デフォルトの Medium 設定で BV が呼び出される RAID 5 のケースでは、ピア SP が過負荷になっていない場合は I/O の分散コストが小さい ため（通常の読み取りで約 0.5 ミリ秒）、パフォーマンスの低下はほとんど限定的です。RAID 10 の LUN で、BV 中 に読み取りのレスポンス・タイムが著しく長くなった場合は、所要時間を短縮するために、速度を一時的に High ま たは ASAP に上げることが必要な場合があります。LCC を修復すると、リクエスト転送は自動的に通常の動作に戻 り、BV は必要に応じて分散なしで続行します。 ディスクの省電力化（ディスク・ドライブ・スピン・ダウン） ディスク・ドライブ・スピン・ダウンを使用すると、RAID グループに 30 分間アクセスがなかった場合に RAID グ ループ内のドライブをスピン・ダウンし、ドライブをアイドル状態にすることにより、電力が節約されます。アイド ル状態では、ドライブは回転しないため、消費電力が減尐します（RAID グループで 30 分以上アイドル状態が続い た場合、消費電力は 60%節約されます）。ドライブがスピン・ダウン（アイドル）モードになっている LUN に対し て I/O 要求が行われた場合、I/O 要求を実行するには、ドライブをスピン・アップする必要があります。RAID グルー プがアイドル状態でいる時間に制限はありません。ストレージ・システムでは、アイドル状態の RAID グループが完 全な動作に戻る準備ができているかどうかを定期的に確認します。この確認が失敗した RAID グループは再構築され ます。 スピン・ダウン機能を使用するには、Navisphere 内または Navisphere CLI から RAID グループをプロビジョニング して、この機能に対応していることが EMC によって認定されているドライブを選択する必要があります。スピン・ ダウンは、ストレージ・システムまたは個々の RAID グループのレベルで構成できます。ストレージ・システム・レ ベルでの構成をお勧めします。ストレージ・システム・レベルのスピン・ダウンでは、バインドされていないドライ ブおよびホット・スペアが自動的にアイドル状態になります。 EMC では、開発、テスト、トレーニングをサポートするストレージ・システムに、スピン・ダウンをお勧めします。 これらのホストは夜間にアイドル状態になる傾向があるためです。また、ホストをバックアップするストレージ・シ ステムにもスピン・ダウンをお勧めします。 ホスト・アプリケーションでは、RAID グループがスタンバイ状態になっている LUN に対して初めて I/O 要求を行っ たときは、レスポンス・タイムが長くなります。ドライブのスピン・アップにかかる時間は 2 分未満です。ストレー ジ・システム管理者は、この点と、アプリケーションが待機可能かどうかを考慮して、RAID グループでディスク・ ドライブ・スピン・ダウン機能を有効にするかどうかを決定する必要があります。 ディスク・ドライブ・スピン・ダウン機能の詳細については、Powerlink から入手できるホワイト・ペーパー「An Introduction to EMC CLARiiON CX4 Disk-Drive Spin Down Technology」を参照してください。 LUN のプロビジョニング LUN の可用性は、LUN の RAID グループで提供される基盤となる可用性と、キャッシュおよび SP の可用性に基づい ています（「RAID グループ」セクションが、さまざまなタイプおよび容量の RAID グループを作成する際の可用性 への影響を理解するうえで役立ちます）。ただし、ワークロードのリカバリ・データを複数の RAID グループ上の LUN に分散させると、システムの全体的な可用性を向上できます。また、再構築に必要な時間を短縮することによ り、パフォーマンスを向上することもできます。 可能な場合は、クローンやログ・ファイルなどのリカバリ・データを、アプリケーションの LUN はサポートしてい ない RAID グループがサポートしている LUN 上に配置してください。アプリケーションのインスタンスが複数存在 する場合は、ログ LUN を、該当するインスタンスのアプリケーションおよびアプリケーション・データから分離し ます。アプリケーションの LUN とは別の RAID グループ上にある LUN にアプリケーションのリカバリ・データを配 置すると、アプリケーションのリカバリ時間が短縮されます。これは、リカバリ・データが直ちに使用可能であり、 ドライブの再構築などの遅延による影響を受けないためです。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 73 ストレージ・システムのベスト・プラクティス ドライブの操作とプランニング CLARiX では、ユーザーにメリットがあるものの、ドライブや SP のリソースを大量に消費するサービスをいくつか 実行します。 LUN のマイグレーションや再構築にかかる時間と、これらの操作がシステムのリソースやホスト・アクセスのレス ポンス・タイムに及ぼす影響の間にはトレードオフがあります。事前にプランニングすることにより、ホストのパ フォーマンスへの悪影響を軽減したり、マイグレーションや再構築に必要な時間を短縮することができます。本番環 境では、これらの目標は互いに矛盾します。 LUN の管理 CLARiX には、システムの全体的なパフォーマンスに影響するリソースが 3 つあります。SP（ストレージ・プロセッ サ）CPU、バックエンド・バス、RAID グループ・ドライブです。LUN のマイグレーションや再構築の所要時間と、 これらのリソースとのバランスを取る必要があります。 ドライブ操作の処理時間に影響する主な要素は、次のとおりです。 優先度：Low、Medium、High、ASAP（As Soon As Possible） バックグラウンドのワークロード：ストレージ・システム使用率 基盤となる LUN RAID グループのタイプ：ミラーまたはパリティ RAID グループのハード・ディスク・ドライブのタイプ：ドライブの rpm 速度およびインタフェース（ファイ バ・チャネルか SATA か、など） 優先度は、操作の処理時間に大きく影響し、したがってシステムのパフォーマンスにも大きく影響します。LUN の マイグレーションおよび再構築には、4 つの優先度（Low、Medium、High、ASAP）があります。 Low、Medium、High では、システムのリソースが経済的に使用されますが、長時間かかります。優先度を ASAP に すると、操作は最短の時間で完了します。ただし、ドライブにかかる負荷が大きくなり、SP CPU の負荷が増加しま す。これらのドライブのホスト I/O パフォーマンスに悪影響があります。 EMC では、High、Medium、Low の設定を使用することをお勧めします。ホスト・データへのコンカレント・アクセ スがリカバリ時間より優先される状況では、ASAP ではなく High を使用してください。 LUN マイグレーション LUN マイグレーション機能は、LUN の RAID グループのトポロジーを変更したり、ホット LUN を使用率の低い RAID グループに移動したり、LUN の容量を変更したりする場合に使用します。 LUN マイグレーションの速度は、FLARE のリビジョンによって異なります。FLARE リビジョン 29.0 から、Medium および High で実行されるマイグレーションの速度は大幅に上昇し、ASAP の速度は低下しました。ASAP の速度低 下により、バックグラウンドのワークロードにより多くのリソースが提供されます。デフォルトでは、FLARE 29.0 の LUN マイグレーションでは、書き込みキャッシュがバイパスされます。ターゲット LUN のライト・アサイド・パ ラメータの値を増やすことにより、帯域幅をさらに広げることができます。これによって書き込みキャッシュが有効 になります。書き込みキャッシュが有効になっている LUN マイグレーションは、アクティブなワークロードのある 本番環境にはお勧めできません。 最後に、FLARE 29.0 の LUN マイグレーションでは、高速バインドを使用して、新しいターゲット LUN の未使用の 残容量が初期化されます。これは、別個にゼロ初期化を実行する以前のバージョンの FLARE とは異なります。 Low、Medium、High の LUN マイグレーション Low、Medium、High の優先度は、本番ワークロードのパフォーマンスにはほとんど影響しません。これらの経済的 な優先度では、非常に大きいブロックで、定期的でシーケンシャルな転送が行われます。 74 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス 次の表は、15k rpm のファイバ・チャネル・ドライブの経験則によるマイグレーション速度を示しています。 表22 FLARE 29 の Low、Medium、High のマイグレーション速度 優先度 速度（MB/秒） Low 1 Medium 13 High 35 経済的な転送速度は、マイグレーション中もパフォーマンスに悪影響を与えずに本番ワークロードが引き続き実行さ れるように、意図的に制限されています。 ASAP マイグレーション デフォルト・キャッシュ設定の ASAP LUN マイグレーションは注意して使用する必要があります。システムのパ フォーマンスに悪影響が生じる場合があります。EMC では、マイグレーション時間が重要でない場合は、High の優 先度で実行することをお勧めします。 ASAP 設定では、I/O の間隔が最小限になるようにマイグレーション I/O が実行されます。SP 自体で作業をする場合 は、I/O 間の遅延はごくわずかです。結果は、ソースおよびターゲットのハード・ディスク・ドライブに対して大き いワークロードを実行している高パフォーマンスのホストと同様です。このワークロードには、ソース LUN からター ゲット LUN への大きいブロックのシーケンシャル・コピーという特性があります。 FLARE 29.0 以降では、LUN マイグレーションの I/O 書き込みサイズは、LUN ライト・アサイドのデフォルト値 （1088 KB）より大きくなっています。ターゲット LUN のライト・アサイド値を 3072 以上に変更すると、マイグ レーションを 4 倍高速にできます。ターゲット LUN のライト・アサイド値は、Navisphere CLI を使用して変更でき ます。LUN マイグレーションを開始後にターゲット LUN で変更することはできません。 ストレージ・システムでワークロードを処理中に、書き込みキャッシュを使用して ASAP マイグレーションを実行す ると、強制的なキャッシュ・フラッシュが行われる場合があります。強制的なキャッシュ・フラッシュは、ストレー ジ・システム全体のパフォーマンスに悪影響を及ぼします。ASAP マイグレーションのデフォルトの設定で、キャッ シュの輻輳を回避できます。現在、同時に実行可能な ASAP マイグレーションは SP ごとに 2 つまでです。ただし、 これを行う場合は、SP 使用率やバス帯域幅などのシステム・リソースを注意して監視する必要があります。 ソースとターゲットの LUN をサポートする、基盤となる RAID グループの構成も、マイグレーションの速度に影響 します。RAID タイプ、ドライブ・タイプ、ドライブ数、ハード・ディスクの速度もマイグレーションの速度に影響 します。ASAP マイグレーションに影響する最大で最も単純な要因は、基盤となる RAID グループがミラー、パリ ティのどちらの RAID グループかと、グループ内のドライブの台数です。 次の表は、RAID 1/0（3+3）グループと RAID 5（4+1）を含み、デフォルトの書き込みキャッシュ・オフの設定に なっている 15k rpm ファイバ・チャネル・ドライブと 15k rpm SAS ドライブの、ASAP の「経験則による」マイグ レーション速度を示しています。 表23 FLARE 29 の ASAP マイグレーション速度のデフォルト設定 マイグレーション ミラーRAID の速度（MB/秒） パリティ RAID の速度（MB/秒） 92 55 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 75 ストレージ・システムのベスト・プラクティス 小さいソース LUN から大きいターゲット LUN への LUN マイグレーションは、内部で、2 つのステップで実行されま す。まず、既存の容量が新しいターゲットに移行されます。次に、標準のバインド・アルゴリズムを使用して、新し い容量が初期化されます。ターゲット LUN の RAID グループを共有している LUN は、マイグレーションと初期化の 両方の悪影響を受けることに注意してください。 基本的な ASAP マイグレーション時間の計算 次の式を使用して、LUN マイグレーションに必要な時間を見積もります。 時間：LUN マイグレーションの所要時間 ソース LUN 容量：ソース LUN の GB 単位のサイズ マイグレーション速度：選択するマイグレーション優先度に応じて表 22または表 23から求めた、ソース LUN か らターゲット LUN へのコピー速度 ターゲット LUN の容量：ターゲット LUN の GB 単位のサイズ 初期化速度：新しい追加ストレージを初期化する MB/秒単位の速度（ASAP の場合は表 23、それ以外では省略） 時間=（ソース LUN 容量×マイグレーション速度） 再構築 再構築を行うと、LUN の RAID グループの障害ドライブを、ホット・スペアから作成した正常なドライブに交換でき ます。障害ドライブを含む RAID グループには、1 つまたは複数の LUN をバインドすることができます。この交換を 行うには、適切なタイプおよびサイズのホット・スペアが必要です。 適切なホット・スペアがない場合、RAID グループは、障害ドライブが交換されるまで、パフォーマンスが低下した 状態になります。その後、障害ドライブの RAID グループが、RAID レベルに従って、パリティまたはミラー・ドラ イブから再構築されます。 再構築は、再構築とイコライズの 2 段階のプロセスです。障害ドライブを交換後に行われます。再構築ステップでは、 RAID グループ上のすべての LUN が再構築されます。LUN の再構築は、優先度を指定する操作です。指定可能な優 先度は、ASAP、High、Medium、Low です。再構築時間は、再構築の優先度、適切なホット・スペアの有無と場所、 ドライブ・タイプ、ドライブ・サイズ、ワークロード、RAID グループのタイプなど、多くの要因によって決まります。 障害ドライブ交換後に行われるイコライズ・ステップでは、ホット・スペアが交換後のドライブにコピーされます。 Low、Medium、High の優先度は、本番ワークロードのパフォーマンスにはほとんど影響しません。表 24は、RAID 5（4+1）グループと RAID 1/0（3+3）グループを含む 15k rpm ファイバ・チャネル・ドライブの経験則による再構 築速度を示しています。 表24 経済的なミラーおよびパリティ RAID ファイバ・チャネル・ハード・ディスク・ドライブの再構築速度 優先度 パリティ RAID の速度（MB/秒） Low 2 Medium 6 High 13 経済的な転送速度は、再構築中もパフォーマンスに悪影響を与えずに本番ワークロードが引き続き実行されるように、 意図的に制限されています。 ASAP では、再構築が最小の時間で完了します。ASAP 再構築では、RAID グループへの他の I/O のパフォーマンスに 悪影響が出る場合があります。大規模な RAID グループの再構築を行った場合も、同じバスを共有している他の I/O に影響が出る場合があります。EMC では、再構築時間が重要でない場合は、High の優先度で実行することをお勧め します。 76 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス ASAP 再構築の速度は、RAID タイプ、ハード・ディスク・ドライブのタイプ、RAID グループに含まれるドライブの 数（パリティ RAID の場合）に依存します。また、ドライブの場所にも依存します。パリティ・グループを ASAP で 再構築する場合、グループ内のすべてのドライブを高速で使用するため、総帯域幅が FC バスの最大帯域幅に近づく か、最大帯域幅に達する可能性があります。すべてのドライブが 1 つのバス上にある場合は、再構築速度はバス帯域 幅によって制限されることがあります。 表 25は、RAID タイプ別の速度を示しています。 表25 ASAP ミラーおよびパリティ RAID ファイバ・チャネル・ハード・ディスク・ドライブの再構築速度（負荷がない場合） ミラーRAID の速度（MB/秒） パリティ RAID 5 の速度（MB/秒） 83 73 再構築 次の表は、ハード・ディスク・ドライブ・タイプの速度調整を示しています。 表26 ASAP ハード・ディスク・ドライブの再構築速度の調整 ハード・ディスク・ドライブのタイプ 再構築速度の乗数 15k rpm ファイバ・チャネル 1.0 15k rpm SAS 1.0 10k rpm ファイバ・チャネル 1.54 7.5k rpm SATA 1.33 EFD 0.7 パリティ・タイプの RAID 6 グループは、ドライブの数が同じパリティ・タイプ RAID 5 グループよりも、再構築に 長い時間がかかります。前述したバス制限により、この時間の違いは、RAID グループに含まれるドライブの数が多 いほど尐なくなります。通常は、複数のバックエンド・バスに分散されていない限り、大きいパリティ RAID グルー プの方が、小さいグループより構築に時間がかかります。すべてのドライブが 1 つのバックエンド・バス上にある場 合は、次の表を参考にして、RAID グループのサイズが再構築速度に与える影響を計算します。この表の値を、表 25 の再構築速度の代わりに使用してください。 表27 RAID グループ・サイズ別のパリティ RAID 再構築速度 RAID グループ・サイズ （ドライブ数） RAID 5MB/秒 RAID 6MB/秒 6 ≤9 66.0 62.0 40.0 50.0 ≤ 12 32.0 30.0 ≥ 15 25.0 23.0 この表の値は、平均値です。LUN の基盤となる RAID グループのプロビジョニングによって、再構築速度は上下しま す。たとえば、複数のバックエンド・バス上にドライブがある LUN は、ドライブが 1 つのバス上にある LUN よりも 再構築時間が短くなります。 再構築にホット・スペアが使用される場合は、イコライズ処理が追加で行われ、障害のあるドライブが置き換えられ てホット・スペアがそれにコピーされます。15k rpm ファイバ・チャネル・ハード・ディスク・ドライブを使用した 場合の、すべての再構築優先度のイコライズ速度を次の表に示します。この速度は、他の要因には影響されません。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 77 ストレージ・システムのベスト・プラクティス 表28 ミラーおよびパリティ RAID ファイバ・チャネル・イコライズ再構築速度 ミラーRAID の速度（MB/秒） パリティ RAID の速度（MB/秒） 82 82 イコライズ 基本的な再構築時間の計算 次の式を使用して、再構築に必要な時間を見積もります。 時間：再構築にかかる時間 障害ハード・ディスク・ドライブの容量：RAID グループの容量使用率×ハード・ディスク・ドライブのサイズ （GB） 再構築速度：優先度が ASAP の場合は、表 25の時間、それ以外の場合は表 27の時間 ハード・ディスク・ドライブのタイプによる速度調整：速度調整については表 26を参照 イコライズ速度：ホット・スペアが障害ドライブの交換用ドライブにコピーされる速度 時間=（（障害ハード・ディスク・ドライブの容量×再構築速度）×ドライブのタイプによる速度調整）+（（障害 ハード・ディスク・ドライブの容量×イコライズ速度）×ドライブのタイプによる速度調整）） 再構築には再構築とイコライズの 2 つの部分があることに注意してください。障害ハード・ディスク・ドライブの手 動交換は、イコライズの前に実行する必要があります。再構築後、RAID グループは完全な機能で動作し、パフォー マンスが低下した状態ではなくなります。第 2 のステップであるイコライズは、障害ドライブの交換によって開始さ れる、自動のバックグラウンド・プロセスです。 ASAP 再構築の計算例 完全にバインドされ、使用率も高い 400 GB、10k rpm の、7 ドライブ（6+1）の RAID 5 ファイバ・チャネル・グ ループ・ドライブを、優先度 ASAP で再構築するには何時間かかるでしょうか。障害ハード・ディスク・ドライブは 迅速に交換されて、シームレスにイコライズできるとします。LUN が同じバスおよびエンクロージャ上のすべての ドライブとバインドされているとすると、再構築時間は次の式で求めることができます。 時間=（（障害ハード・ディスク・ドライブの容量×再構築速度）×ドライブのタイプによる速度調整）+（（障害 ハード・ディスク・ドライブの容量×イコライズ速度）×ドライブのタイプによる速度調整）） 4.8 時間=（（400 GB×（1/66.0）MB/秒）×1024 MB/GB×（1/3600）秒/時間×1.54））+（400 GB×（（1/82.0） MB/秒×1024 MB/GB×（1/3600）秒/時間））×1.54） パラメータは次のとおりです。 時間：再構築にかかる時間単位の長さ 障害ハード・ディスク・ドライブの容量：400 GB 再構築速度：66.0 MB/秒（「表 27 RAID グループ・サイズ別のパリティ RAID 再構築速度」を参照。これが 5 ドライブの RAID 5（4+1）の場合、再構築速度は表 25を参照） ドライブのタイプによる速度調整：10k rpm ファイバ・チャネルの場合は 1.54（表 26を参照） イコライズ速度：82.0 MB/秒（表 28を参照） 78 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのベスト・プラクティス ASAP 再構築時のパフォーマンスの維持 アプリケーションのパフォーマンスに対する ASAP 再構築の効果は、ワークロードの内容に依存します。次の 3 つの 効果を考慮する必要があります。 再構築ドライブの使用率 バス帯域幅の使用率 相対的なドライブ・キューの競合 再構築中の RAID グループと I/O を実行しているすべてのアプリケーションが低速になります。再構築では、パリティ・ グループ内の各グループに対して、最大 8 つの I/O が同時に送信されます。このグループがミラーである場合は、残 りのミラーに対して 8 つの I/O が送信されます。大容量の再構築読み取りに時間がかかり、キューが長い場合、レス ポンス・タイムも長くなります。 帯域幅使用率は、同じバス上のすべてのドライブに影響します。バス使用率が上昇すると、他のプロセスで使用でき る帯域幅が減尐します。パリティ RAID グループのすべてのドライブが同じバス上にある場合、RAID グループのサ イズとドライブ・タイプによっては、使用可能なバス帯域幅の大部分が ASAP 再構築によって消費されることがあり ます。大きい RAID グループを再構築すると、使用可能なバス帯域幅がすべて消費される可能性があります。スト レージ・システム上の別の場所で、帯域幅に依存するアプリケーションが実行されている場合は、RAID グループを 複数のバスに分散させる必要があります。 相対キューで、本番と再構築の間にドライブの競合が見られる場合があります。再構築とイコライズの処理では、読 み取りや書き込みのキャッシュ・サブシステムは使用せず、複数の大量の I/O が同時に送信されます。ホスト I/O の 動作は、ソース・パターンまたはキャッシュ使用量によって異なる場合があります。シーケンシャル・ライト処理は、 ドライブごとに複数のスレッドがあることや、再構築処理と競合する大きい結合ブロック・サイズがあることにより、 キャッシュからデステージします。シーケンシャル・ライト処理と再構築を同時に行うと、それぞれの速度が同様に 低下します。シーケンシャル・リード処理では、通常、ドライブごとに同様のパラレル・スレッドの負荷は生成され ません。さらに、ワークロードの競合により、ドライブでの連続性が低下します。そのため、LUN のバックアップ のようなシーケンシャル・リード処理の実行速度は、ASAP 再構築中は、ASAP 再構築が実行されていない場合より 大幅に遅くなります。 再構築している RAID グループ上にアクティブなシーケンシャル・リード処理のワークロードがある場合は、競合に より、このセクションの各表で説明した速度より ASAP 再構築速度が遅くなります。ASAP 再構築中のストレージ・ システムのパフォーマンスは、ホスト読み取り用にプリフェッチ変数の値を大きくすることによって維持できます。 1 つのオプションは、プリフェッチ・マルチプライアを 32 に、セグメント・マルチプライアを 4 に変更することで す。たとえば、64 KB のシーケンシャル・リード・ストリームでは、一度に 2 MB が 256 KB のチャンクでプリ フェッチされ、再構築中の読み取り速度が大幅に上昇します。もちろん、通常の操作でこれらのドライブにアクセス している他のプロセスも、シーケンシャル・リード処理への偏りの影響を受けます。 ワークロードで ASAP 再構築のパフォーマンスへの悪影響を許容できない場合は、再構築の優先度を High、Medium、 Low のいずれかに設定してください。再構築速度は ASAP よりも低下しますが、High 設定でも本番のワークロード と再構築の競合は時間にして 10%のみです。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 79 ストレージ・システムのベスト・プラクティス 80 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ホストのベスト・プラクティス 第5章 ストレージ・システムの サイズ設定および パフォーマンス・ プランニング ストレージのサイズを設定するには、容量要件を満たす正しい数のドライブを計算し、パフォーマンス要件を満たす 正しい数のドライブと正しいストレージ・システムを決定する必要があります。この章では、ワークロードに合わせ てストレージ・システムを構成する際の主な考慮事項について説明します。この章は、セールス・サポートを提供す る EMC のセールスおよび技術の専門スタッフが使用できるソフトウェア・ツールの代わりとなるものではありません。 はじめに ストレージ・システムを構成する際は、常にワークロードを第一に考慮する必要があります。ワークロードの要件は、 容量とパフォーマンスとして大まかに定義できます。ワークロードのピーク時の要件を満たすように十分なストレー ジ容量と 1 秒あたりの I/O（IOPS）を用意しておくことが重要です。さらに、パフォーマンスのサイズ設定とプラン ニングでは、容量とパフォーマンスが計画的に、または予期せず縮退する場合を考慮に入れる必要があります。 容量 まず、RAID タイプとドライブ・グループ・サイズを特定します。この計算は、パリティ RAID タイプの容量に影響 します。ドライブ数がわかったら、パフォーマンス関連の計算を行うことができます。EMC 担当者は、ツールを使 用して、供給されたシステムの正確な有効容量を決定します。これらのツールでは、ヴォールト・ドライブ、CLARiX ストレージ・システム上の各セクタに格納される拡張冗長データ、ホット・スペアなど、最終的な容量に影響する数 多くの要因が考慮に入れられます。 ヴォールト・ドライブ CLARiX の最初の 5 つのドライブには、ヴォールトが含まれています。ヴォールト・ドライブは、システム上の他の ドライブと同様に使用できます。しかし、ヴォールト・ドライブでは、有効容量が他のドライブより尐なくなります。 ヴォールト以外の他のドライブとバインドした場合、グループ内のすべてのドライブが、ヴォールト・ドライブと同 じ容量になるように計算されます。そのため、ヴォールト・ドライブは 1 つまたは複数のグループにまとめた方が、 容量使用率の点で効率的です。ヴォールト・ドライブのパフォーマンスに関する考慮事項については、81ページの 「ヴォールト・ドライブ」を参照してください。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 81 ストレージ・システムのサイズ設定およびパフォーマンス・プランニング 実際のドライブ容量 一部のオペレーティング・システムではバイナリ番号体系に基づいて容量が報告されるので、実際にアクセスできる 容量が報告値と異なる場合があります。ドライブ・メーカーの間では、ギガバイトは 1,000,000,000 バイト（十進法 に基づくギガバイト）とみなされます。コンピュータ OS では、二進法（バイナリ）が使用される場合があり、バイ ナリ方式のギガバイトは 1,073,741,824 バイトになります。 また CLARiX では、冗長性情報を格納するため、512 バイトのセクタごとに追加の 8 バイトが使用されます。このよ うにセクタが 520 バイトになったため、有効容量はその分縮小します。 たとえば、146 GB のドライブの場合は、フォーマットされたデータ容量は約 133 GB、400 GB のドライブでは フォーマットされたデータ容量は約 367 GB です。 パリティまたはミラーリングによる保護 パリティまたはミラーリングを使用してドライブ障害からデータを保護する場合も、ストレージの有効容量が縮小し ます。ミラーリングでは、データ保護を確実にするために、常にストレージ容量全体の 50%を使用する必要があり ます。これを保護容量オーバーヘッドと呼びます。 たとえば、16 ドライブの RAID 1/0（8+8）には、ハード・ディスク・ドライブ 8 台という保護容量オーバーヘッド があります。16 台中 8 台のドライブがストレージ用であり、残りの 8 台が保護のオーバーヘッドです。この RAID 1/0 グループが、フォーマットされた 146 GB（未フォーマット時）の 15k rpm ファイバ・チャネル・ドライブで構 成されているとします。この RAID グループの有効容量は約 1.04 TB です。実際の有効容量と、フォーマットとミ ラーリングを考慮に入れない場合に想定されるおよそ 2.3 TB（16×146 GB）の違いに注目してください。 パリティ RAID の保護容量オーバーヘッドに割り当てられている領域の比率は、グループに含まれているドライブ数 と使用されるパリティ RAID のタイプによって決まります。パリティ RAID 3 および RAID 5 のドライブ 1 台の容量 は、ドライブの合計のオーバーヘッドに相当します。RAID 6 のオーバーヘッドは、ドライブ 2 台分に相当します。 たとえば、5 ドライブの RAID 5（4+1）グループのオーバーヘッド比率は 20%です。これは、ストレージ用ドライブ 4 台と、パリティ用ドライブ 1 台分のオーバーヘッドに相当します。この RAID 5 グループが、フォーマットされた 400 GB（未フォーマット時）の 15k rpm ファイバ・チャネル・ドライブで構成されているとします。フォーマット とパリティを考慮に入れると、この RAID グループの総有効容量は約 1.4 TB です。 パフォーマンス パフォーマンスのプランニングまたは予測は、多くの知識を必要とする技術です。ワークロードのスレッド化モデル、 I/O のタイプ（ランダムまたはシーケンシャル）、I/O のサイズ、ドライブのタイプはすべて、観察対象パフォーマン スに影響を与えます。パフォーマンスに影響を与える要因についての詳細は、ホワイト・ペーパー「EMC CLARiX Fibre Channel Storage Fundamentals」に記載されています。 経験則 パフォーマンスの見積もりでは、最初に経験則を使用して、ドライブあたりの IOPS およびドライブあたりの MB/秒 を求めます。この計算には、表 29に示すガイドライン値を使用してください。これは、実際よりは低めの値で、意 図的に簡略化した基準です。RAID グループのレスポンス・タイム（ドライブごと）、帯域幅、スループットの見積 もりでは、I/O タイプ（ランダム、シーケンシャル、混在）、I/O サイズ、使用しているスレッド・モデルを考慮する 必要があります。これは正確なパフォーマンス見積もりのための開始点に過ぎず、経験則に基づく評価は設計の規模 を簡単に知るためのものであるという点に注意してください。より正確な方法が EMC 担当者向けに用意されています。 ランダム I/O データベース・アプリケーションやオフィス・オートメーション・システムで使用するような小さいブロック（要求 1 つにつき 16 KB 以下）のランダム I/O では、通常、平均レスポンス・タイムが 20 ミリ秒以下のスループットが必 要です。ドライブ・キューの深さが平均的な 1 または 2 である場合は、ドライブごとのスループット速度を次のよう に想定します。 82 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのサイズ設定およびパフォーマンス・プランニング 表29 ドライブ・タイプ別の小さいブロックのランダム I/O ドライブ・タイプ IOPS ファイバ・チャネル 15k rpm 180 SAS 15k rpm 180 ファイバ・チャネル 10k rpm 140 SATA 7.2k rpm 80 SATA 5.4k rpm 40 EFD 2500 ほとんどの設置環境では複数のスレッドがアクティブになりますが、レスポンス・タイムを 20 ミリ秒未満に抑える ことが望まれます。控えめに値を見積もるため、レスポンス・タイムを重視するアプリケーションでは、FC ドライ ブまたは SAS ドライブあたりの IOPS を 3 分の 1 と仮定して計算を実行してください。ランダム I/O のサイズが 16 KB より大きい場合は、IOPS 速度が規則的に低下します。適切に動作するシーケンシャル・アクセスの場合は、大きな I/O サイズであっても、FC ドライブまたは SAS ドライブの速度が提示されている IOPS の倍以上になることがあり ます。 たとえば、あるシングル・スレッド・アプリケーションが、ドライブに対する未処理の I/O 要求を一度に 1 つ持って いるとします。このアプリケーションが 10k rpm ドライブから 8 KB のランダム・リード処理を行っている場合は、I/O あたり 8 ミリ秒で 125 IOPS を達成できます。これと同じアプリケーションは、サイズの等しい同時スレッド 12 個を 使用してドライブを読み取る場合、I/O あたり 50 ミリ秒で 240 IOPS を達成できます。 レスポンス・タイムを最適にするための設計を行うときは、ドライブのスループットを、表 30に示すスループット 値の約 70%に制限してください。最適なスループットは、レスポンス・タイムとキューの深さの上限を緩和するこ とによって達成できます。50 ミリ秒を超えるレスポンス・タイムと、8 以上のドライブ・キューの深さが許可されて いる場合、表のドライブ・スループットは、ドライブあたり 50%拡大できます。 64 KB～512 KB のランダム要求の場合、ドライブの動作は、通常は IOPS ではなく帯域幅（MB/秒）単位で測定され ます。ブロック・サイズが拡大すると、ドライブごとの帯域幅も拡大します。キューの深さ 1 で、ドライブごとの帯 域幅が以下の場合について考えます。 表30 ドライブ・タイプ別の大きいブロックのランダム帯域幅 ドライブ・タイプ 64 KB（MB/秒） 512 KB（MB/秒） ファイバ・チャネル 15k rpm 8.0 32.0 SAS 15k rpm 8.0 32.0 ファイバ・チャネル 10k rpm 6.0 24.0 SATA 7.2k rpm 4.0 16.0 SATA 5.4k rpm 2.5 12.0 EFD 100 100 スレッド数が帯域幅に大きく影響することに注目してください。シングル・スレッドの 5 ドライブ（4+1）の RAID 5 LUN がランダムな 64 KB パターンを継続的に読み取っている場合、ドライブごとのキューの深さはわずか 0.2 であ り、8 MB/秒の帯域幅がスピンドル・アクティビティの合計に適用されます。一方で、16 スレッドの 64 KB のランダ ム・リード・パターンでは約 60 MB/秒を達成できます。 提示されている速度で同時に駆動可能なドライブ数は、ストレージ・システムの使用可能なバックエンド帯域幅に よって制限されます。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 83 ストレージ・システムのサイズ設定およびパフォーマンス・プランニング シーケンシャル I/O シングル・スレッドのシーケンシャル I/O を実行している 64 KB 以上のブロック・サイズの場合、RAID グループの ストライピングにより、帯域幅はドライブ・タイプに依存しなくなります。控えめな設計見積もりとして、ドライブ あたり 30 MB/秒を使用してください。 環境によっては、チューニングによってドライブの帯域幅を大幅に向上できます。たとえば、16 KB のキャッシュ・ ページ・サイズと、プリフェッチ・マルチプライア 16、セグメント・マルチプライア 16 を使用すると、5 ドライブ の RAID 5（4+1）でドライブあたり 50 MB/秒を達成できます。複数のスレッドを使用する場合、これら 5 台のドラ イブはバックエンド・バスの帯域幅（約 360 MB/秒）を超えることができます。これにより、バスを共有している他 のアプリケーションに悪影響が生じる場合があることに注意してください。 ランダムおよびシーケンシャルの混在 I/O 負荷が混在している場合、純粋なシーケンシャル帯域幅は、ランダム負荷のヘッドの移動によって大幅に低下します。 シーケンシャル IOPS が追加されるため、ランダム IOPS の低下率は最小限です。シーケンシャル・ストリーム帯域 幅は表 30の値を使用して、ランダム負荷は表 29の IOPS の 50%の値を使用して、概算できます。プリフェッチを大 きめの値で設定すると（プリフェッチ・マルチプライア 16、セグメント・マルチプライア 16）、シーケンシャル帯 域幅は向上しますが、ランダム IOPS は低下します。ランダム負荷のキューの深さを増やすと、IOPS は向上します が、シーケンシャル・ストリームの帯域幅は低下します。 パフォーマンス見積もり手順 簡単な見積もり手順は次のとおりです。 ワークロードを決定します。 ドライブ負荷を決定します。 必要なドライブ数を決定します。 ストレージ・システムの数とタイプを決定します。 ワークロードの決定 ワークロードの決定は、多くの場合、見積もり手順の中で最も難しい部分です。提案されたシステムの負荷はもち ろん、既存の負荷さえも把握していない人は尐なくありません。しかし、可能な限り正確な予測を立てることは非常 に重要です。そのため、何らかの性能見積もりを行うことが必要となります。 見積もりの対象には、総 IOPS だけでなく、読み取りと書き込みがそれぞれ負荷に占める割合も含める必要がありま す。また、主な I/O サイズも決定する必要があります。 ドライブ負荷の決定 表 29に示す IOPS 値はドライブごとの IOPS です。ホストの I/O 負荷に基づくドライブ IOPS 数を決定するには、パ リティ操作またはミラーリング操作用に次のような調整を加えます。 パリティ RAID 5 および 3：ドライブ IOPS=読み取り IOPS + 4×書き込み IOPS パリティ RAID 6：ドライブ IOPS=読み取り IOPS + 6×書き込み IOPS ミラーリング RAID：ドライブ IOPS=読み取り IOPS + 2×書き込み IOPS たとえば、4 ドライブの RAID 1/0（2+2）グループがあり、I/O にランダム・リード処理とライト処理がそれぞれ 50%ずつ混在し、ホスト IOPS の合計が 10,000 の場合は、次のようになります。 IOPS = 0.5×10,000 + 2×（0.5×10,000） IOPS = 15,000 84 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのサイズ設定およびパフォーマンス・プランニング 帯域幅を計算するにあたり、大容量 I/O またはシーケンシャル I/O によって LUN ストライプを満たすことが予想され る場合は、次のアプローチに従って、書き込み負荷を RAID マルチプライアで増大させます。 パリティ RAID 5 および 3：ドライブ MB/秒=読み取り MB/秒+書き込み MB/秒×（1 +（1÷（グループ内の ユーザー・データ・ドライブ数））） パリティ RAID 6：ドライブ MB/秒=読み取り MB/秒+書き込み MB/秒×（1 +（2÷（グループ内のユー ザー・データ・ドライブ数））） ミラーリング RAID：ドライブ MB/秒=読み取り MB/秒+書き込み MB/秒×2 たとえば、RAID 5 グループのサイズが 4+1（グループごとにユーザー・データ・ドライブが 4 台）であり、読み取 り負荷が 100 MB/秒、書き込み負荷が 50 MB/秒の場合は、次のようになります。 ドライブ MB/秒= 100 MB/秒+ 40 MB/秒×（1 +（1/4）） ドライブ MB/秒= 150 MB/秒 必要なドライブ数の計算 ストレージ・システム内のドライブ数を決定するには、パフォーマンス関連の計算とストレージ容量関連の計算を両 方行います。 パフォーマンス容量 合計の IOPS（または帯域幅）を、ドライブあたりの IOPS 値（小さいブロックのランダム I/O の場合は表 29、大き いブロックのランダム I/O の場合は表 30を参照）で割ります。その結果、提案の I/O 負荷に対応するために必要なド ライブのおおよその数が得られます。16 KB（32 KB まで）より大きく 64 KB より小さい主な I/O サイズを指定して ランダム I/O のパフォーマンスを計算する場合は、ドライブ数を 20%増やしてください。ブロック・サイズが 64 KB を超えるランダム I/O では、帯域幅の制限にも対応する必要があります。この作業は、EMC プロフェッショナルの 助言の下で行うことをお勧めします。 ストレージ容量 ストレージ容量の要件を満たすために必要なドライブ数を計算します。提案される I/O 負荷に必要なドライブ数は、 ストレージ容量要件を満たすために必要となるドライブ数と等しいことが理想的です。ドライブのフォーマット後の 容量は、未フォーマット時より小さいことを覚えておいてください。パフォーマンス容量とストレージ容量の見積も りのうち、大きい方のドライブ数を使用します。 また、ヴォールトには 5 台のドライブが必要であり、30 ドライブ（小数点以下は四捨五入）ごとにホット・スペア を 1 つ追加することが賢明です。計算を簡単にするために、動作パフォーマンスを計算する場合は、ヴォールトと ホット・スペアのドライブ数を計算に含めないでください。 合計ドライブ数 合計ドライブ数の概数= RAID グループ IOPS÷（ハード・ディスク・ドライブ・タイプの IOPS）+大容量ランダム I/O の調整+ホット・スペア+ヴォールト たとえば、4,000 IOPS を実行するものとしてあらかじめ計算され、I/O が 16 KB のランダム要求であり、グループに 対して指定されているハード・ディスク・ドライブが 7.2k rpm の SATA ドライブであるアプリケーションの場合は、 次のようになります（表 29を参照）。 合計ドライブ数の概数= 4,000÷80 + 0 +（（4,000÷80）÷30）+ 5 合計ドライブ数の概数= 57 ストレージ・システムの数とタイプの計算 ドライブ数を見積もったら、パフォーマンス、容量、およびバリューをクライアントに提供するストレージ・システ ムと一致させる必要があります。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 85 ストレージ・システムのサイズ設定およびパフォーマンス・プランニング ドライブ数がクライアントの要件に最も一致するストレージ・システムを選択します。必要なドライブ数を効果的に サポートするストレージ・システムの数を決定するには、ドライブ数を、CX4 の最大ドライブ数（42ページの表 8を 参照）で割ります。 IOPS パフォーマンスを最適にするための、ストレージ・システムに最適なファイバ・チャネル・ドライブ数を表 31 に示します。すべて SATA ドライブの設置環境を検討する場合は、ストレージ・システムの最大ドライブ数（CX4480 の場合は 480）を使用します。展開するストレージ・システムのタイプと数を決定するには、必要なドライブ数 を、表 31に示すドライブ数で割ります。高パフォーマンスのストレージ・システムでは、より複雑な分析が必要で あり、この単純な例では対応できません。高パフォーマンス、高可用性のストレージ・システムの構成については、 EMC プロフェッショナルに問い合わせてください。 表31 CX4 の最適なドライブ数 最適なファイバ・チャネル・ドライブ数 CX4-120 CX4-240 CX4-480 CX4-960 120 240 335 500 ストレージ・システム数 ストレージ・システム数=ドライブ数の概数÷ストレージ・システムのドライブ最大数 たとえば、約 135 ドライブが必要な高パフォーマンス・ストレージ・システムの場合は、次のようになります。 ストレージ・システム数= 135÷240 ストレージ・システム数= 1（CLARiX CX4-240 ソリューション） パフォーマンス・ニーズと容量ニーズの解決 システム内のドライブ数は、パフォーマンスと容量のニーズに基づいて決定されます。前述の計算方法では、パフォー マンス要件を満たすために必要なドライブ数の最小値が算出されます。 容量要件を満たすために必要なドライブ数を算出するには、さまざまなドライブ・サイズに基づいた別の見積もりを 行う必要があります。最終的な使用ドライブ数を決定するには、パフォーマンス要件と容量要件の両方を満たすドラ イブ数を補間によって算出します。 サイズ設定の例 以下に、前述の手順に基づいたサイズ設定の例を示します。 手順 1：ワークロードを決定する ワークロードを正確に把握することは、最初に行うべき最も重要な手順です。ワークロードに誤りやあいまいな点がある と、サイズ設定の計算に支障をきたし、最終的なシステムがクライアントのニーズに適合しなくなる可能性があります。 次の例は、サイズの見積もりに必要な最小ワークロード要件に基づいています。 クライアントはオブジェクト・データベースに関するストレージ要件を抱えており、アプリケーションはランダム I/O を実行します。プロファイルは次のとおりです。 70%がランダム・リード処理 30%がランダム・ライト処理 主要 I/O サイズは 16 KB 合計ホスト IOPS は 20,000 必要な有効容量は 35 TB 86 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス ストレージ・システムのサイズ設定およびパフォーマンス・プランニング このクライアントは価格を重視しているため、大容量のパリティ RAID が理想的です。ただし、書き込み比率 （30%）が十分に高いため、RAID 1/0 も検討対象になります。 手順 2：必要な I/O ドライブ負荷を決定する 検討対象の 3 種類の RAID、つまり RAID 5、RAID 6、および RAID 1/0 について、IOPS を計算します。 ドライブ負荷は次のとおりです。 RAID 5（8+1）：0.7×20,000 + 4×0.3×20,000 = 38,000 ドライブ IOPS RAID 6（8+2）：0.7×20,000 + 6×0.3×20,000 = 50,000 ドライブ IOPS RAID 1/0（8+8）：0.7×20,000 + 2×0.3×20,000 = 26,000 ドライブ IOPS IOPS に基づいて判断すると、この手順では RAID 1/0 が最適な選択肢です。 手順 3：必要なドライブ数を決定する 15,000 rpm の FC ドライブを想定し、ホット・スペア数とヴォールト・ドライブ数を合計に含めたうえで、各 RAID タイプに必要なハード・ディスク・ドライブ数を算出します。パフォーマンス容量は、IOPS をドライブあたりの IOPS で割った値です。 RAID 5（8+1）：38,000÷180 +（（38,000÷180）÷30）+5 = 211 + 7+ 5 =合計 223 ドライブ RAID 6（8+2）：50,000÷180 +（（50,000÷180）÷30）+ 5 = 278 + 11 +5 =合計 292 ドライブ RAID 1/0（8+8）：28,000÷180 +（（28,000÷180）÷30）+ 5 = 156 + 5 +5 =合計 166 ドライブ ドライブ数に基づいて判断すると、この場合は RAID 1/0 が最適な選択肢です。 パフォーマンス要件を満たすために必要なドライブ数の計算には、ストレージ要件を満たすうえで必要なドライブ数 を使用します。この計算には、データ・ドライブ数のみ使用し、ヴォールト・ドライブとホット・スペア・ドライブ の数は含めないでください。フォーマット済み容量が 268 GB の 300 GB FC ドライブを想定すると、次のようにな ります。 RAID 5（8+1）：8÷9×211×268 = 50.3 TB RAID 6（8+2）：8÷10×278×268 = 59.6 TB RAID 1/0（8+8）：½×156×268 = 20.9TB 容量に基づいて判断すると、この手順では RAID 5 が最適な選択肢です。 手順 4：ストレージ・システムの数とタイプを決定する 手順 3 までの結果は、表 32に示すとおりです。この表は、ストレージ・システムを決定する過程で RAID オプ ションを比較する目的で使用されます。 表32 サイズ設定の見積もり計算結果 RAID タイプ ドライブ負荷（IOPS） パフォーマンス容量（ドライブ数） ストレージ容量（TB） 合計ドライブ数 RAID 5 38,000 211 50.3 223 RAID 6 50,000 278 59.6 292 RAID 1/0 28,000 156 20.9 166 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 87 ストレージ・システムのサイズ設定およびパフォーマンス・プランニング 算出されたパフォーマンス容量、ストレージ容量、合計ドライブ数、その他の要件にどの CLARiX モデルが最も適合 するかを特定します。 この例では、RAID 5 を採用した CX4-240 が最適な候補です。RAID 5 ソリューションとしては、データ用ドライブを 211 個、ホット・スペアを 7 個、ヴォールト（およびアーカイブ領域）用ドライブを 5 個にすると妥当です。バック アップ用の SATA ドライブが 15 個含まれた DAE を追加すると、最終的なドライブ数は 238 になります。 クローン、スナップ、またはミラーに関する要件が追加される場合は、より大容量の CX4-480 に RAID 5 ソリュー ションを移動する必要が生じます。 その他の考慮事項 場合によっては、RAID 1/0 ソリューションと RAID 6 ソリューションが選択されなかった理由、およびこれらのソ リューションを有力な選択肢にする方法について簡潔に説明すると効果的です。 RAID 1/0 ソリューションには、クライアントのシステムに必要な IOPS が備わっています。しかし、必要なストレー ジ容量を満たしていないため、最終的には選択されませんでした。RAID 1/0 がクライアントのストレージ容量要件 を満たすには、300 個以上の FC ドライブが必要です。そのためには、これらのドライブを収容するために CX4-480 が必要となります。 RAID 6 ソリューションは、クライアントのストレージ容量要件を満たすだけでなく、RAID 5 ソリューションと比較 して、より強力なデータの安全性も提供します。それにもかかわらず選択されなかったのは、IOPS と合計ドライブ 数が多く、より大規模な CLARiX CX4-480 が必要となるためです（クライアントは価格重視であることがわかって います）。ただし、データ増大、クローン、スナップ、ミラーに関する要件が追加された場合は、RAID 6 ソリュー ションも有力な選択肢になります。 CLARiX モデルを最終的に選択するには、さまざまな要因を考慮することが必要となります。容量、パフォーマンス、 可用性、データ増大、コスト関連のすべての目標を考慮に入れる必要があります。この例では、CLARiX モデルを決 定する際に検討すべき最も重要な要因を示しました。 88 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 用語集 「わたしがことばを使うとき、そのことばは、わたしが選んだとおりの意味になるのだ。それ以上 でもそれ以下でもない」 -- ハンプティ・ダンプティ「鏡の国のアリス」（1871）ルイス・キャロル著 10 GbE — 10 ギガビット/秒の Ethernet プロトコル。 ABQL — 平均ビジー・キュー長（ドライブあたり）。 AFR — 年間障害率。 ALUA — 非対称論理ユニット・アクセス・プロトコル。 American National Standards Institute（米国規格協会） — 世界的に認知されている標準化団体。 ANSI — American National Standards Institute（米国規格協会）。 BIOS — 基本入出力システム。 BURA — データ・ストレージ・セキュリティ・ドメインのバックアップ、リカバリ、アーカイブ。 BV — バックグラウンド・ベリファイ。 ® CAS — EMC Centera で実装される、コンテンツ・アドレス・ストレージ・オブジェクト・ベースのストレージ。 CIFS — Common Internet File System。 CLI — コマンド・ライン・インタフェース。 CMI — 構成管理インタフェース。 Common Internet File System — Microsoft Windows のファイル共有プロトコル。 CPU — Central Processing Unit（中央演算処理装置）。 CRM — カスタマー・リレーションシップ・マネージメント。 DAE — ドライブ・アレイ・エンクロージャ。 DAS — 直接接続ストレージ。 DBMS — データベース管理システム。 DPE — ディスク・プロセッサ・エンクロージャ。 DR — 災害復旧。 DSS — 意思決定支援システム。 EFD — エンタープライズ・フラッシュ・ドライブ。 ERP — エンタープライズ・リソース・プランニング。 ESM — EMC サポート・マトリックス。 Ethernet — ローカル・エリア・ネットワーク経由の高速帯域幅接続のための技術。IEEE 802.3 規格。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 89 用語集 FC — ファイバ・チャネル。 FCIP — IP 経由のファイバ・チャネル・トラフィック。 FCP — SCSI ファイバ・チャネル・プロトコル。 FLARE — Fibre Logic Array Runtime Environment。CLARiX のオペレーティング・システム。 GB — ギガバイト。 GB/秒 — 1 秒あたりのギガバイト数。 Gb/秒 — 1 秒あたりのギガビット数。 GbE— ギガビット Ethernet（1 Gb/秒の Ethernet）。 GHz — ギガヘルツ。 GigE — 1 Gb/秒の Ethernet。 GMT — グリニッジ標準時。 GUI — グラフィカル・ユーザー・インタフェース。 HA — 高可用性、または可用性が高いこと。 HBA — ホスト・バス・アダプタ。ファイバ・チャネル・ネットワーク・インタフェース・アダプタ。 HP-UX — Hewlett-Packard Corporation 独自のバージョンの UNIX OS。 HVAC — 暖房、換気、空調。 Hz — ヘルツ。 ICA — イメージ・コピー・アプリケーション。 IETF — インターネット技術タスクフォース。 IEEE — Institute of Electrical and Electronics Engineers（米国電気電子技術者協会）。 iFCP — FC デバイスで IP ネットワークをファブリック・スイッチ・インフラストラクチャとして使用できるプロト コル。 IHAC — I Have A Customer。 IOPS — 1 秒あたりの入出力動作。 IP — インターネット・プロトコル。 IPSec — インターネット・プロトコル・セキュリティ。 iSCSI — インターネット SCSI プロトコル。ストレージ・システム上でドライブに SCSI コマンドを送信するための 規格。 ISL — スイッチ間リンク。ネットワーク内の 2 つ以上のスイッチを接続。 ISO — International Organization for Standardization（国際標準化機構）。 IT — 情報テクノロジー。また、コンピュータ・システムを管理する部門。 JBOD — Just a Bunch Of Disks（単なるディスクの集合）。 KB — キロバイト。 Kb — キロビット。 Kb/秒 — 1 秒あたりのキロビット数。 KB/秒 — 1 秒あたりのキロバイト数。 90 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 用語集 LAN — ローカル・エリア・ネットワーク。 LBA — 論理ブロック・アドレス。 LCC — リンク・コントロール・カード。 Linux — ハードウェアに依存しないオープン・システムのオペレーティング・システム環境。 LUN — 論理ユニット番号。 LVM — 論理ボリューム・マネージャ。 MAN — メトロポリタン・エリア・ネットワーク。 MB — メガバイト。 MB/秒 — 1 秒あたりのメガバイト数。 Mb — メガビット。 Mb/秒 — 1 秒あたりのメガビット数。 MetaLUN — 複数の LUN オブジェクトをストライプまたはコンカチネートすることによって構築される LUN オブ ジェクト。 MHz — メガヘルツ。 MirrorView — CLARiX の災害復旧アプリケーション。 MPIO — Microsoft Multi-Path I/O。 MR3 書き込み — RAID 5 のストライプ全体がキャッシュに収集され、一度に書き込まれるときに、CLARiX RAID エンジンで実行されるアクション。 MTBF — 平均故障間隔。 MTTDL — 平均データ消失間隔。 MTTR — 平均障害修復時間。 NAS — ネットワーク接続型ストレージ。 Native Command Queuing — ドライブ・ベースの I/O 実行最適化技術。 Navisphere — CLARiX のリソース管理システム・ソフトウェア。 Navisphere Analyzer — CLARiX のパフォーマンス分析システム・ソフトウェア。 NCQ — Native Command Queuing。 Network File System — UNIX/Linux のファイル共有プロトコル。 NDU — 無停止アップグレード。 NFS — Network File System。 NIC — ネットワーク・インタフェース・カード。 OS — オペレーティング・システム。 OLTP — オンライン・トランザクション処理システム。 PATA — パラレル ATA ディスク I/O プロトコル。 PB — ペタバイト。 PC — パーソナル・コンピュータ。 PCI Express — コンピュータ・ベースのシステムで使用されるバス・プロトコル。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 91 用語集 PCIe — PCI Express。 PDU — 配電器。 Powerlink — パスワード保護されている顧客およびパートナー向けの EMC エクストラネット。 PowerPath — EMC のホスト・ベースのマルチパス・アプリケーション。 PSM — Persistent Storage Manager。 PV リンク — HP-UX 物理ボリューム・リンク。 QA — 品質保証。 QFULL — キュー・フル。 QoR — 結果品質。 QoS — サービス品質。 RAID — Redundant Array of Independent Disks。 RAID グループ — RAID レベルが同じ 2～16 台のドライブを論理的に関連づけたもの。 RAID レベル — 容量を拡大しパフォーマンスを向上させるとともにフォールト・トレランスを提供するドライブの 構成。 raw ドライブ — ファイル・システムのないハード・ディスク・ドライブ。 RDBMS — リレーショナル・データベース管理システム。 Recovery Time Objective（目標復旧時間） — 障害後にシステムを完全動作にリストアするまでの予想時間。 Rpm — 1 分あたりの回転。 RPQ — Request for Product Qualifier（製品認定依頼書）。 RTO — Recovery Time Objective（目標復旧時間）。 RV — 回転振動。 SAN — ストレージ・エリア・ネットワーク。 SAN Copy — CLARiX のストレージ・システムからストレージ・システムへのコピー・アプリケーション。 SAP — ソフトウェア企業 SAP AG 製のエンタープライズ・リソース・プランニング・アプリケーション。 SAS — シリアル接続 SCSI。 SATA — シリアル ATA ディスク I/O プロトコル。 SCSI — Small Computer System Interface。 SLA — Service Level Agreement（サービス・レベル契約）。測定可能なレベルのサービスまたはリソースへのアク セスを規定した、サービス・プロバイダと顧客との間の契約。 SLIC — 小型 I/O カード。 Small Computer System Interface — ホストとドライブを物理的に接続し、データを転送するための、一連の規格。 SnapView — CLARiX のポイント・イン・タイム・コピー・アプリケーション。 SP — ストレージ・プロセッサ。 SPE — ストレージ・プロセッサ・エンクロージャ。 SPS — スタンバイ電源装置。 SSD — ソリッド・ステート・ディスク。 92 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 用語集 TB — テラバイト。 TCP — Transmission Control Protocol。IP とともに使用して Ethernet ネットワークでデータを送受信するプロトコル。 TCP/IP — インターネットおよび他の同様のネットワークで使用する通信プロトコルのペア。 TCP/IP オフロード・エンジン — Ethernet ネットワークに接続する、コプロセッサ・ベースのホスト・コンポーネント。 TOE —TCP/IP オフロード・エンジン。 UER — 復旧不可能なエラー率。 UNIX — オープン・システムのオペレーティング・システム環境。 UPS — 無停電電源装置。 VLAN — 仮想ローカル・エリア・ネットワーク。 VLAN タグ機能 — VLAN を分割するためのメカニズム。 VM — 仮想マシン。 VMware — EMC の仮想マシン・アプリケーション・ファミリ。 WAN — ワイド・エリア・ネットワーク。 WCA — 書き込みキャッシュの可用性。 Windows — Microsoft 独自のオペレーティング・システム環境。 Wintel — Intel のハードウェア・アーキテクチャと Microsoft Windows オペレーティング・システムに基づいている コンピュータを示す業界用語。 World Wide Name — ファイバ・チャネル/SAS ストレージ・ネットワークでの一意な識別子。 WORM — Write Once/Read Many。 WWN — World Wide Name。 アクティブ-アクティブ — 冗長コンポーネントがアクティブで動作中。 アクティブ-パッシブ — 冗長コンポーネントがスタンバイ動作モードで待機中。 アタッチメント — ドライブ・ハードウェア・コネクタまたはインタフェース・プロトコル。CLARiX では、ファイ バ・チャネル、SAS、SATA のいずれか。 アプリケーション・ソフトウェア — ある機能を実行するプログラムまたは関連するプログラムのグループ。 アレイ — ストレージ・システム。 イコライズ — 障害が発生した RAID グループのドライブと交換したドライブに対してホット・スペアからデータを コピーすること。 意思決定支援システム — 「データ・マイニング」アクティビティに使用するデータベース・アプリケーション。 イニシエータ — iSCSI クライアント。 インターネット技術タスクフォース — TCP/IP プロトコルを標準化する国際機関。 インターネット・プロトコル — TCP とともに使用して Ethernet ネットワーク経由でデータを転送するプロトコル。 ウォーターマーク — キャッシュ使用率の設定ポイント。 ヴォールト — CLARiX のシステム・ファイルおよびキャッシュ・ダンプを保存するための、DAE0 のドライブ上の特 殊な領域。 エッジ・スイッチ — コア・エッジ構成の SAN の周辺に配置されているファイバ・チャネル・スイッチ。 エンタープライズ・フラッシュ・ドライブ — SSD タイプのドライブを表す EMC 用語。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 93 用語集 エンタープライズ・リソース・プランニング — 組織の在庫を管理し、ビジネス・プロセスを統合するアプリケー ション。 エンタープライズ・システム — ビジネス組織全体のニーズをサポートするストレージ・システム。 オーナー権 — LUN I/O の SP 管理。 大きいブロック — 容量が 64 KB を超える I/O 動作。 オペレーティング環境 — オペレーティング・システム。 オペレーティング・システム — アプリケーションやリソース管理を制御する、コンピュータ上のソフトウェア。 オンライン・トランザクション処理 — 小規模な読み取り/書き込みを多数処理している 1 つ以上のデータベースでサ ポートされているマルチ・ユーザー・システム。 回転待ち時間 — ディスク・ドライブが読み取りヘッドの下の必要なセクタを回転させるのに要する時間。 書き込みキャッシュ — ホストに ACK を迅速に提供し、バックグラウンドで後からデータをディスクにデステージす ることにより、ホストの書き込み I/O レスポンス・タイムを向上させることのみを目的としているキャッシュ・メ モリ。 カスタマー・リレーションシップ・マネージメント — 顧客を引きつけ、獲得するためのアプリケーション。 仮想プロビジョニング — 論理的なアドレス・スペースを任意の物理アドレスに明示的にマップすること。例：アプ リケーションに対して、物理的に割り当てられている容量よりも多くの容量を提供すること。 仮想マシン — サーバ・ハードウェア環境をエミュレートするソフトウェア・アプリケーション。 可用性 — 障害発生後にコンピュータ・ベースのシステムを継続して運用すること。 環境 — コンピュータのハードウェア・プラットフォーム、システム・ソフトウェア、アプリケーション。 ギガバイト — 10 億バイト、または 1,000 メガバイト。 ギガビット — 10 億ビット。 ギガヘルツ — 1 秒ごとに 10 億回（1,000,000,000 Hz）。 基本入出力システム — オペレーティング・システム・ソフトウェアをロードして実行できるように、ホストを既知 の状態に設定するファームウェア。 キャッシュ — 読み取り/書き込みデータをバッファして、ホストがドライブにアクセスする回数を減らすために、ス トレージ・システムによって使用されるメモリ。 キャッシュ・ヒット — ホストから書き込まれたデータやホストから要求されたデータがキャッシュで見つかった場 合にキャッシュ・ヒットが発生し、ドライブ要求の待機時間を短縮。 キャッシュ・ページ・サイズ — 1 つのキャッシュ・ページの容量。 キャッシュ・ミス — ホストから要求されたデータがキャッシュにないため、ドライブ要求が必要。 キュー・フル — ポートまたは LUN のキューがエントリを受け入れられないことを示す、ホストに送信される iSCSI プロトコル・シグナル。 許可 — リクエストがリソースへのアクセスを許可されているかどうかを判断すること。 強制フラッシュ — 書き込みキャッシュ全体をクリアするために、ドライブに対して高い優先度でデータを書き込む こと。 キロバイト — 1,000 バイト。 キロビット — 1,000 ビット。 クライアント — クライアント/サーバ・アーキテクチャの一部。ホストと通信するユーザー・コンピュータまたはア プリケーション。 94 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 用語集 クライアント/サーバ — サービスの消費者（クライアント）と提供者（ホスト）の間のネットワーク・アーキテク チャ。 グラフィカル・ユーザー・インタフェース — モニタに表示されるオブジェクトを使用してソフトウェア・プログラ ムと通信できるインタフェース。 クローン — ソース LUN の正確なコピー。 結果品質 — 技術的プロセスまたは実装の評価で使用される用語。 結合 — キャッシュされた小さい I/O を結合して、ドライブに対する大きい I/O にすること。 コア — CPU チップ上に共存するプロセッサ・ユニット。 コア・スイッチ — SAN のアーキテクチャの中間に配置されている、数百個のポートを持つ大規模なスイッチまたは ダイレクタ。 高可用性 — システムに単一の障害がある場合にデータにアクセスできること。 小型 I/O カード — CX4 UltraFlex I/O モジュールの総称。ファイバ・チャネルまたは iSCSI。 国際標準化機構 — 標準化を管理する国際機関。 コマンド・ライン・インタフェース — ユーザーがテキスト・ベースのコマンドを使用してアプリケーションまたは オペレーティング・システムと通信できるインタフェース。 コンカレント I/O — 共有リソース上で複数の I/O 要求が同時にアクティブになっている状態。 再構築 — パリティまたはミラーリングから、障害ドライブのデータを再構築すること。 最適パス — ホストから LUN への、通常動作の I/O パス。 サービス時間 — ドライブまたはリソースで 1 つの I/O の実行に要する時間。 サービス品質契約 — システムまたはネットワークの、定義済みの保証されたパフォーマンス・レベル。 シーケンシャル I/O — アドレスおよびサイズのパターンにより、データ領域全体に、アドレス数を単調に増加させな がらシリアル・アクセスする結果となる一連の I/O 要求。 シェルフ — DAE。 システム・ソフトウェア — コンピュータの管理に使用するオペレーティング・システムおよびアプリケーション。 使用可能容量 — シン LUN プール内の、シン LUN に割り当てられていない容量。 障害 — システムのハードウェア・コンポーネント内の不具合。 障害 — ソフトウェア・プログラムの操作におけるエラー。 障害モード — 障害の原因、または障害の原因となるプロセスを開始するイベント。 冗長性 — ストレージ・システムが、バックアップ・コンポーネントまたはデータ保護メカニズムを使用して、障害 後にデータ・アクセス処理を続行できること。 ショート・ストローキング — RAID グループの一部のみを使用する LUN パフォーマンス最適化技術。 使用率 — リソースの使用量の測定値。 シリアル ATA – CLARiX で使用するディスク I/O アタッチメント。 シリアル接続 SCSI - データをドライブに移動するための、ポイント・ツー・ポイント・シリアル・プロトコル。 信頼性 — ストレージ・システムが、長期に渡り、ストレスを受けながらも、ハードウェアやソフトウェアの障害な しに動作できること。 スタック — レイヤード・プロトコル。 ストライプ — RAID グループ内の多数のドライブに、ストレージのシーケンシャル・チャンクを分散させること。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 95 用語集 ストライプ・エレメント — 1 つのストライプ・デバイスに割り当てられている容量。 ストライプ・サイズ — RAID グループ・ストライプの有効容量。 ストライプ・クロッシング — バックエンド I/O がストライプ全体に含まれていない場合に、複数のストライプを使 用するストライプ・クロッシングが発生する。 ストライプ幅 — RAID グループ・ストライプ内のハード・ディスク・ドライブ数。 ストレージ・アレイ — ストレージ・システム。 ストレージ・エリア・ネットワーク — ドライブを共有する目的で設計および構築されたネットワーク。 ストレージ・オブジェクト — 読み取り/書き込み両方のデータ・アクセスをサポートする論理構成または物理デバイス。 ストレージ・システム — 情報やアプリケーションを安全かつ経済的に格納するための、複数のハード・ディスク・ ドライブ、キャッシュ、インテリジェンスを含むシステム。 ストレージ・プール — 読み取り/書き込み両方のデータ・アクセスをサポートする、ドライブの論理構成。 ストレージ・プロセッサ — CPU とメモリを含む、CLARiX のアーキテクチャの論理的部分。 ストレージ・プロセッサ・エンクロージャ — CLARiX ストレージ・プロセッサを含む、物理的なラックマウント・ キャビネット。ドライブは含まれない。 ストローク — ディスク・プラッタでのハード・ディスク・ドライブの読み取り/書き込みヘッドの動き。 スイッチ — ポート間に専用の帯域幅を提供し、ストレージ・ネットワーク・デバイス間で機能を切り替える、レイ ヤー2 デバイス。 スナップショット — 特定の時点での LUN の状態のバックアップ・コピー。 スパイク — ストレージ・システムで、負荷が突然、急激に、大幅に増加すること。 スピン・ダウン — 非アクティブなハード・ディスク・ドライブを、省電力の「スリープ」モードに設定すること。 スピンドル — ハード・ディスク・ドライブのコンポーネント。ディスク・プラッタが取り付けられている軸。ハー ド・ディスク・ドライブのことをスピンドルと呼ぶ場合もある。 スループット — 一定時間あたりの I/O のパフォーマンスの測定値。通常は 1 秒あたりの I/O（IOPS）で測定される。 スレッド — 1 つの独立した I/O 要求。他の要求と並列して実行される場合もある。 セクタ — ハード・ディスク・ドライブ上のアドレス指定可能な最小ユニット。1 セクタには 512 バイトのデータが 含まれる。 先行読み取り — 「プリフェッチ」を参照。 ソリッド・ステート・ディスク — データ・ストレージに不揮発性半導体メモリを使用するドライブ。 帯域幅 — ストレージ・システムのパフォーマンスの測定値（MB/秒単位）。 ダーティ・ページ — ストレージにまだ書き込まれていないキャッシュ・ページ。 ダンプ — キャッシュ・イメージをヴォールトにコピーすること。 小さいブロック — 16 KB までの I/O 動作。 ディスク・アレイ・エンクロージャ — 最大 15 台の CLARiX ドライブを含むラックマウント・エンクロージャ。 ディスク・コントローラ — ハード・ディスク・ドライブを制御する、マイクロプロセッサ・ベースの電子機器。 ディスク・クロッシング — アドレスとサイズが原因でディスク内で複数のストライプ・エレメントにアクセスする I/O。これにより、バックエンド I/O が 1 つではなく 2 つになる。 ディスク・プラッタ — ハード・ディスク・ドライブのコンポーネント。磁気データを保存する円形ディスク。 ディスク・プロセッサ・エンクロージャ — CLARiX ストレージ・プロセッサおよびドライブを含むキャビネット。 96 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 用語集 データ — コンピュータによって処理または保存される情報。 データ・センター — コンピュータ・システム、ストレージ・システム、および関連するコンポーネントを格納する ための設備。 データ・マイニング・アプリケーション — データ内でパターン、トレンド、関係を見つける目的でデータベースの 内容を分析するデータベース・アプリケーション。 データ・リンク — サイトからサイトへのデジタル通信接続。 データ・ウェアハウス — DSS 機能をサポートする、関連するデータベースのコレクション。 デグレーデッド・モード — 障害後に運用を続けている状況。パフォーマンス低下の可能性がある。 デステージ — キャッシュからドライブへのデータの移動。 テラバイト — 1 兆バイトまたは 1,000 ギガバイト。 トポロジー — システム・コンポーネント、サブシステム、システムの各部の配列および内部での関係。 ドライブ — データの読み取り/書き込みが可能なハードウェア・コンポーネント。通常はハード・ディスク・ドライ ブだが、EFD も使用可能。 トラック — ハード・ディスク・ドライブ・プラッタ上のリング状の領域。ここでデータが整理および保存される。 トレイ — DAE。 トレスパス — 障害やコマンドにより、SP LUN のオーナー権がマルチパスによって変更されること。 認証 — 送信元を確認するために通信の ID を検証すること。 ネーム・サーバ — ファイバ・チャネルや IP を含む、シンボリック・アドレスとネットワーク・アドレスの変換を行 うプロセス。 ネットワーク — 互いにリンクされている 2 台以上のコンピュータまたはコンピュータ・ベースのシステム。 ネットワーク・インタフェース・カード — Ethernet ネットワークに接続するホスト・コンポーネント。 ネットワーク・エレメント — ネットワークを実装する際に使用するデバイス。通常はスイッチまたはルータ。 配電器 — データ・センターの電力トランクをストレージ・システムに接続する CLARiX コンポーネント。 バイト — コンピュータの 8 ビット。 バインド — 複数のドライブを関連づけて RAID グループを作成すること。 バースト — ピークを十分に定義している場合に、時間の経過とともに非常に変わりやすくなる、または定期的に変 わりやすくなる、I/O の特性。 バス — デバイス間またはコンポーネント間でデータをやり取りするための、コンピュータ・システム内部のチャネル。 バックアップ — 元のドライブに障害が発生した場合に備えて、第 2 の、通常はパフォーマンスが比較的低いドライ ブにデータをコピーすること。 バックエンド — SP からバックエンド・バスおよびドライブまでの、CLARiX のアーキテクチャの論理的部分。 バックエンド I/O — ストレージ・プロセッサとドライブの間の、バックエンド・バスを介した I/O。 バックエンド・バス — ストレージ・プロセッサをドライブに接続する、CLARiX のファイバ・チャネル・バス。 バックグラウンド・ベリファイ — 障害回避のための、CLARiX による LUN のパリティ・セクタの自動読み取りおよ びその内容の検証。 バッファリング — 他のデバイスまたはプロセスでデータを受信して処理する準備ができるまで、一時的な領域に データを保持すること。データ・フローを最適化するための処理。 パラレル ATA — 従来の CLARiX で使用されていたディスク I/O プロトコル。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 97 用語集 非最適パス — ホストから LUN への、ALUA のフェイルオーバーI/O パス。 ビジー時間 — 1 日のうちで I/O が最も発生する時間。 非対称論理ユニット・アクセス — 業界標準のマルチパス・プロトコル。 ビット — データの最小単位。0 または 1 の単一のバイナリ値。 品質保証 — 保証されているパフォーマンスと可用性を検証する部門、またはポリシーと手順。 ファイバ・チャネル — シリアル・データ転送プロトコル。ANSI X3T11 ファイバ・チャネル規格。 ファイル — データのコレクション。 ファイル・システム — コンピュータ・ファイルの整理および管理のために OS で使用するシステム。 ファイラー — ファイル共有プロトコルを使用して共有ストレージにアクセスする NAS ファイルサーバ。 ファン・イン — ストレージ・システムの尐数のポートに多数のホストを接続すること。 ファン・アウト — ストレージ・システムの尐数のポートを多数のホストに接続すること。 フェイルバック — 障害を修正後に元のデータ・パスをリストアすること。 フェイルオーバー — 元のパスに障害が発生したため代替パスを使用すること。 フォールト・トレランス — ハードウェアまたはソフトウェアの障害後にシステムの運用を継続できること。 復旧不可能なエラー率 — ハード・ディスク・ドライブのビット・エラーの信頼性メトリック。 部門システム — ビジネス組織内の単一部門のニーズをサポートするストレージ・システム。 フラッシュ — 書き込みキャッシュ内のデータをドライブに書き込むプロセス。 プラットフォーム — DSS や OLTP など、システムをサポートするハードウェア、システム・ソフトウェア、アプリ ケーション・ソフトウェア。 プリフェッチ — 現在の読み取りのほかに、将来使用することを予測していくつかのブロックを読み取り、キャッ シュしておくキャッシュ方法。 ブロードバンド — データや音声の通信に使用する、広帯域幅のネットワークおよびインタフェース。 ブロック — ハード・ディスク・ドライブ上のアドレス指定可能な最小ユニット。512 バイトのデータが含まれる。 プロトコル — デバイス通信の仕様。 フロントエンド — ホストから SP までの通信ポートを含む CLARiX のアーキテクチャの論理的部分。 米国電気電子技術者協会 — 国際的な標準化団体。 平均故障間隔 — デバイスまたはシステムが故障なしで動作する平均時間。 平均障害修復時間 — 障害修復に必要と予測される時間。 平均データ消失間隔 — RAID グループのデータ消失の原因となる障害が発生する時期の統計的予測。 ページ — キャッシュの割り当てユニット。 ペタバイト — 1,000 兆バイトまたは 1,000 テラバイト。 ヘッド・クラッシュ — 読み取り/書き込みヘッドがディスク・プラッタと接触する、致命的なハード・ディスク・ド ライブ障害。 ヘルツ — 1 秒ごとに 1 回。 ポート — ストレージ・システムと他のコンピュータおよびデバイスとの間のインタフェース・デバイス。また、ド ライブとバスの間のインタフェース。 98 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 用語集 飽和状態 — I/O をこれ以上追加するとシステムのレスポンス・タイムが大幅に長くなるが、スループットは追加され ない程度までストレージ・システムのリソースがロードされている状態。 ホスト — ネットワーク経由でストレージ・システムにアクセスするサーバ。 ホット・スペア — 障害ドライブを自動的に交換するためにストレージ・システムで使用できるスペア・ドライブ。 ボトルネック — 最大容量で動作しているプロセス内のリソース。プロセス全体の速度低下の原因となる。 ボリューム — LUN。 マルチスレッド — 同時 I/O スレッド。 マルチパス — LUN 間に複数のホスト I/O パスがあること。 ミラー — 既存のデータのレプリカ。 無停止アップグレード — アプリケーションを実行中に、アプリケーションのパフォーマンスへの影響を最小限にと どめてシステム・ソフトウェアをアップグレードすること。 メガビット — 100 万ビット。 メガバイト — 100 万バイトまたは 1,000 キロバイト。 メガヘルツ — 1 秒あたり 100 万サイクル（1,000,000 Hz）。 メタデータ — 他のデータを説明または特徴づけるためのデータ。 メディア — データの保存に使用する、ハード・ディスク・ドライブの磁気面。 メモリ・モデル — メモリを使用したスレッドの対話方法の説明。 ライト・アサイド — 書き込みキャッシュのバイパス。RAID エンジンによって書き込みが直ちにディスクに対して ディスパッチされる。 ライト・アサイド・サイズ — 特定の LUN のキャッシュに書き込まれる最大の要求サイズ（ブロック単位）。 ランダム I/O — ファイル・システムやパーティションの広範囲に分散された場所に書き込まれる I/O。 リクエスト・サイズ — ファイル・システム内の、ドライブから実際に読み取られるブロックのサイズ。 リッチ・メディア — 受信者によるアクティブな参加に対応するワークロード。対話式メディアとも呼ばれる。 リレーショナル・データベース管理システム — Oracle、DB2、Sybase、SQL Server など、通常ストレージ・シス テムでホストされるデータベース。 ループ — 同じ番号のバックエンド・バスに対する SP A と SP B の共有接続。 レイヤード・アプリケーション — レイヤード・アプリケーション。 レイヤード・アプリケーション — CLARiX のアプリケーション・ソフトウェア。 レガシー・システム — 最新のハードウェアやソフトウェアを持たない古いストレージ・システム。 レスポンス・タイム — ホストから測定した、I/O 完了の累積時間を含むパフォーマンスの測定値。 ローカル・エリア・ネットワーク — 地理的に狭い範囲に広がっているコンピュータ・ネットワーク。 ロード・バランシング — 使用可能な複数のリソースにデータや処理を均等に分散させること。 論理ブロック・アドレス — ドライブのセクタの SCSI ブロック・アドレスへの割り当て。 論理ボリューム・マネージャ — Microsoft Logical Disk Manager のような、ホスト・ベースのストレージ仮想化アプ リケーション。 論理ユニット番号 — I/O 動作のアドレス指定先のSCSIプロトコル・エンティティ。 ユーザー — アプリケーション・ソフトウェアを操作する個人。 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティス 99 用語集 読み取り/書き込みヘッド — ディスク・プラッタに情報を記録したり、ディスク・プラッタから情報を読み取ったり する、ハード・ディスク・ドライブのコンポーネント。 読み取りキャッシュ — 読み取り I/O の向上専用のキャッシュ・メモリ。 ワイド・エリア・ネットワーク — 地理的に広範囲、場合によっては世界中に広がっているコンピュータ・ネット ワーク。 ワイヤ速度 — プロトコルやソフトウェアのオーバーヘッドがない場合の、ハードウェア上のデータ転送の最大帯域 幅。「ワイヤ・スピード」とも呼ばれる。 ワークロード — 一連のアプリケーション・タスクを実行するためにストレージ・システムに提供されている I/O 要 求のパターンの特性。I/O サイズ、アドレス・パターン、読み取りと書き込みの比率、コンカレンシー、突発性など が該当する。 割り当て容量 — シン LUN に現在割り当てられている物理的な容量の合計。 100 パフォーマンスと可用性に関する EMC CLARiX のベスト・プラクティス: リリース 29.0 ファームウェア・アップデートのベスト・プラクティ ス