Comments
Description
Transcript
データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成
データの偏りに基づいたOracle FS1-2 ストレージの構成方法：アレイ構成における 新しい最重要メトリック Oracleホワイト・ペーパー | 2015年2月 概要 ............................................................................. 1 IT環境における一般的なデータ・アクセス・パターン .................................. 3 OLTPトランザクション・データ .................................................. 3 ビジネス・インテリジェンスおよびデータウェアハウスのデータ ..................... 3 金融サービス .................................................................. 4 電気通信処理 .................................................................. 4 仮想デスクトップ・インフラストラクチャ ......................................... 5 SPC-1ベンチマーク ............................................................. 5 アクセス・パターンから得られる教訓............................................. 5 データの偏りの詳細 ............................................................... 6 偏りの定義 .................................................................... 6 偏り転換点（収穫逓減点） ...................................................... 7 フラッシュ容量の計算：最上層から最下層へのロールダウン ............................ 8 各層のサイジング .............................................................. 8 ライト・ペナルティの計算 ...................................................... 9 クール化期間 .................................................................... 10 クール化曲線 ................................................................. 11 Oracle Databaseのデータ・クール化に関する考慮事項 ............................. 11 データ成長率 .................................................................... 12 ストレージ・メディア・タイプの経済性（ビジネス価値） ............................. 13 Oracle FS1-2の概要 .............................................................. 14 結論 ............................................................................ 17 概要 ある特定数のIOPSを達成するために特定のタイプのドライブがいくつ必要になるかを算出すること は、以前は簡単でした。データ・ボリュームが1つのタイプのメディアにのみ存在していたため、ス トレージ管理者は、必要になる総IOPSを1つのハード・ディスク・ドライブ（HDD）が達成できるIOPS で割ることで、必要になる最少のドライブ数をすぐに把握できました。さまざまな読取り/書込み比 率やRAIDタイプに応じて少し補足すれば計算は完了しました。 しかし、自動階層化されたハイブリッド・アレイの出現によって、この従来の単純な問題は大きく 複雑化しました。現在、ストレージの意思決定者と管理者は、"最大4タイプのメディアのうち、nn.nnn のホストIOPSを達成するために必要になる容量はどの程度で、それらの異なるタイプのメディアを どのように組み合わせるのが最適か"といった疑問を解決する必要があります。また、それぞれの層 でRAIDタイプが異なる場合があるため、特定のメディア上に存在する特定のデータに対して、RAID ライト・ペナルティを適用する必要があります。さらに、ホット・データ（頻繁にアクセスされる データ）は常に変わるため、常に移動します。 もっとも重大な疑問は、"ホット・データはどの程度の割合で存在するか、どの程度保持してどこに 保存すべきか"です。この疑問の背景に、すべてのデータが同様にアクセスされるわけではないとい う事実があります。非常にアクティブなデータもあれば、比較的アクティブでないデータや、完全 にコールド状態の（まったくアクセスされない）データもあります。このデータ配置は静的なモデ ルではありません。データ・ブロックは常に変化しています。クールな状態の（アクセス頻度が下 がっている）ブロックやホットな状態の（アクセス頻度が上がっている）ブロックもあれば、状態 が変わらないブロックもあります。課題は、どのデータ・ブロックがどの状態にあるかを把握し、 各ブロックを最適なメディアに配置して、優れた費用対効果と効率性によってパフォーマンス要件 やビジネス要件を満たすことです。しかし、すべてに当てはまることですが、言うは易く行うは難 しです。 ある特定のデータ・ブロック・セット内でのデータ・アクセス密度、つまり使用頻度の差異は偏り （Skew）と呼ばれます。偏りの単純な定義としては、次のような状況を表します。一般的に、あるア プリケーションに関連するデータのごく一部が、総容量に対して発行されるI/Oの大部分に対応しま す。この偏差が大きくなるほど、偏りも大きくなります。 ほぼすべてのワークロードで、かなりのデータの偏りが発生します。ストレージ・メディアのパ フォーマンスや容量のコストに大きな差があることを考慮すると、アプリケーション・データの偏 1 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック りを理解することは非常に重要です。なぜこれまで、1つのタイプのメディアにすべてのデータが保 存されてきたのでしょうか。このような対応では一般的に容量を多くすることに注意が払われるこ とになります。その一方で、低度のI/Oパフォーマンスで十分なコールド・データ（アクセス頻度の 少ないデータ）を保存するために、高価な高パフォーマンス・メディアをプロビジョニングするこ とを強いられます。 ストレージ戦略でデータに非常に大きなI/Oの偏りがあることが考慮されていなければ、不必要に費 用のかかるオーバープロビジョニング状態になることは避けられず、さらに予期されない、または 計画外のピーク・ワークロードを処理できなくなる可能性もあります。これらのいずれかまたは両 方が発生すれば、エンドユーザーの満足度が低下し、おそらくはキャリア・パスも制限されます。 このホワイト・ペーパーは、データの偏りと、それによるストレージ戦略の影響について理解しよ うとするストレージ管理者およびITエグゼクティブを対象としています。このホワイト・ペーパー では、複数の業界での一般的なデータ・アクセス・パターンを示し、"偏り転換点"の概念について 説明し、各層のサイジング方法について述べ、データ・クール化率とデータ成長率について情報を 提供します。さらに、このホワイト・ペーパーでは、サブLUN自動階層化とQuality of Service Plus （QoS Plus）機能を組み合わせた概念について紹介します。QoS Plusは、Oracle FS1-2 Flash Storage Systemで導入された機能です。QoS Plusは、データの偏りとビジネス価値に基づいてデータの配置 方法を動的に管理することを目的に設計されています。 2 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック IT環境における一般的なデータ・アクセス・パターン 本項のデータ・アクセス・パターンの例では、データの偏りの重要性と、パフォーマンスや容量の コストにデータの偏りがどう影響するかについて示します。偏りの詳細については、このホワイト・ ペーパーの"データの偏りの詳細"で説明します。 OLTPトランザクション・データ OLTP環境では、トランザクション中のデータはホット状態、請求月のデータはウォーム状態（出荷、 在庫補充、日常業務データの保存など）であり、それ以外は、月/四半期/年に一度のレポートを実 行するまでコールド状態（読取り専用）です。その後、データは完全にコールド状態になり、トラ ンザクション・データの99.99%がまったく更新されなくなります。例外的に、リバース・トランザ クションや修正トランザクションが発生しますが、そのようなケースは稀です。トランザクション 中のデータ・アクセスはランダムであり、その後、請求サイクル終了後にデータが古くなるにつれ て、データ・アクセスは順次的になる傾向があります。このような順次アクセスがトランザクショ ンと同時に発生する場合もあります。 純粋なOLTPトランザクション・データの場合、全体的な偏りは大きくなります。トランザクション の多くは終了後すぐに、FoursquareやPayPal、あるいはクレジット・カードやデビット・カードに よって即座に決済され、販売主の手から離れて、金融サービス業界の手に渡ります。平均的なデー タ・クール化期間は約30日間です。したがって、1年全体を通して見ると、任意の時点でホット状態 の可能性があるデータは12分の1です。つまり、全データのうちホット状態のデータは8.3%しかあり ません。この割合でも、実際のホット・データ量としては高すぎる可能性があります。30日の期間 内で原子的なトランザクションが適度に均等に分散していると仮定した場合、トランザクションか ら月次請求期間までの平均間隔は15日にしかならないからです。おそらく、ホット・データの基準 としては4.15%がより適切です。この割合の仮定として、すべてのユーザーが1年の間に少なくとも1 回トランザクションを実行することとして総容量が算出されています。ただし、実際には帳簿上に 休眠中のアカウント（最終的には販売主によって除去されるアカウント）が存在するため、実際の 容量はさらに増大します。このホワイト・ペーパーでは、さまざまな除去の期間のバイアスについ ては考慮していません。 ビジネス・インテリジェンスおよびデータウェアハウスのデータ このデータは通常、トランザクション・アクティビティによって作成された後、今時点でデータウェ アハウス内に保管されているデータです。レポート目的や分析で使用される性質があり、大半のア クセスが順次的になります。データは古くなるにつれてアクセス頻度が下がり、関係性が薄くなっ ていきます。1年後には、ほぼ完全にコールド状態になります。全体的な偏りは中程度から小程度で す。ウェアハウスでのデータの保管やアクセスの期間が長くなるほど、偏りは小さくなります。こ れは、Oracle ExadataおよびOracle Exalogicの得意とする領域です。Oracle Exadataの極めて優れ た内部帯域幅と高い並列度、およびOracle Exalogicによる大量データの迅速で効率的な分析能力が 役に立ちます。 アレイがコールド・トランザクション・データ用のディスク・アーカイブとしても機能しない限り、 このユースケースでは自動階層化による十分な効果は得られません。 3 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック 金融サービス 金融サービス・トランザクションの大部分（ごく限られたケースの頻度の高い売買を除く）は、照 会、預金、ATMサービス、クレジット・カード/デビット・カード処理における要求払い口座（DDA） トランザクション（電子形式のDDA）です。 トランザクション実行中のデータはホット状態です。また、そのトランザクションを送信し銀行が 日次キャッシュ・ポジションを終了して各店舗の全残高を更新した日の後にも、再びホット状態に なるときがあります。月に一度、紙または電子媒体による取引明細書を作成する際、および月次報 告を行う際に、一時的に大量のアクティビティが発生します。四半期および年に一度のレポートは、 生データから抽出された一部のデータに対して実行されます。このデータは通常、別のボリューム に保管されて異なるアプリケーションで使用されるため、（実行される場所は異なるけれども）よ り多くのホット・スポットが形成されます。 カード利用残高の請求と支払いを行う必要があるため、請求サイクルに従って3日ごとに10分の1の データがホット状態になります。一般的に、クレジット・カードまたはデビット・カード上の最下 位の桁またはチェックサム用の桁に基づいて、10分の1のデータが抽出されます。その他の10分の9 のデータは、世界のどこかにあるデータセンターのディスク・ドライブに埋もれた意味のない哀れ な状況から救出されることを待ちながら、孤独な時間を過ごします。支払いの処理は到着時に行わ れるためランダムですが、概して、30日間の会計月に基づいて、1日あたり30分の1のデータにアク セスします。これらのステップの後に、読取り専用のレポート生成と分析問合せのアクティビティ に移ります。 全体的な偏りは大きく、最初の30～45日間は複数回アクセスされるためデータは高いウォーム状態 で維持され、その後コールド状態に変わります（平均15日で次の請求期間に移り、15～30日で月に 一度のレポート作成段階に移ります）。これは、やや長いデータ・クール化期間と見なすことがで きます。重要なこととして、45日は1年の約9分の1であり、任意の時点におけるデータを100%として 1年間で表すと仮定すれば、全データの9分の1がかなりアクティブな状態にあり、そのデータの約半 分が非常にアクティブな状態にあります。 電気通信処理 電気通信の中核を占めるコール詳細レコード（CDR）処理アプリケーションは、世界でもっとも要求 の厳しいアプリケーションの1つです。コールが発生すると、CDRがスイッチによって収集され保存 されます。CDRは1日に1回、メイン処理システムに送信され、その後、請求修正処理（BRP）が開始 されるまでそのシステムに保管されます。BRPは1か月に10回実行されます。各処理の実行時間は3日 間であり、処理対象は請求先電話番号の最下位の数字に基づいて抽出されます。そのため、3日間の サイクルのそれぞれで、月次データの10分の1にアクセスします。その他の10分の9のデータは休眠 中で、日の目を見るときを待っています。 通話料金請求の際には、一時的に大量のアクティビティが発生します。海外通信事業者への支払いが 計算されますが、その際に、複雑な国際無線通話であれば、5か国の10の事業者にまたがる場合もあり ます。このような通話だけでも、大量の新規データが生成され、さらに電話の加入者に対する請求書 の作成処理も行われます。請求書が送信され最終的には支払いが行われます。この処理が、最後の大 量のメインライン・アクティビティ発生につながります。金融サービスと同様に、このアクティビティ はひと月にわたってほぼ均等に分散されるため、毎日、データの30分の1がホット状態になります。こ の後、CDRおよびBRPがアーカイブされ、抽出されたデータが後の分析やレポートのためにデータウェ アハウスに移動されるか、その他の目的で特定の大規模な政府関係機関に送信されます。 4 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック 全体的な偏りは大きく、データ・クール化期間は金融サービスと同様に、45日から60日程度のやや 長い期間になります。アクティビティの比率も金融サービスと同様になります。 仮想デスクトップ・インフラストラクチャ 仮想デスクトップ・インフラストラクチャ（VDI）は、オール・フラッシュ・アレイ（AFA）が必須 ソリューションであると言われる典型例です。しかし、本当にそうなのか検証が必要です。これま でVDIの問題は、ほぼすべての従業員がほぼ同じ時間に仕事場に姿を現し、ワークステーションを起 動する"ブート・ストーム"であると常に言われてきました。数百人のユーザーが突然、同時に同じ ディスク・セットから同じゴールデン・イメージにアクセスしようとします。ブート時に使用され る512バイトの読取りが、大規模なディスクの過負荷状態とトラフィックの混雑を引き起こします。 1台のラップトップが2分でWindowsを起動できる場合、同じディスク・セット上の100人のユーザー の起動は100分、いや50分かかるでしょうか。何分であろうとも、それでは長すぎます。 全体的な偏りは非常に大きく、おそらく大規模VDIインストールの99%に達します。 SPC-1ベンチマーク SPC-1のI/Oの96%は、データの5.5%にしかアクセスしません。これは、自動階層化の世界ではもはや 意味のないベンチマークです。この理由は以下のとおりです。 数百台の146GB HDDを基盤とした構成は、もはや現実的ではありません。現在では、たとえばOracle FS1-2での非常に高速な400GB SLCフラッシュ・ドライブ数台と、その他の4TB NL_SASドライブを基 盤とした構成が利用されます。4TB NL_SASドライブのコストは$0.25/GBで、高パフォーマンスSLCフ ラッシュ・ドライブの30分の1です。NL_SASドライブは、大容量かつ非常に低い$/GBを実現し、400GB SLCフラッシュ・ドライブには高IOPSという良さがあります。SPC-1は2014年で終焉を迎えたと言え るでしょう。 アクセス・パターンから得られる教訓 前述のアクセス・パターンの例から、いくつかの結論を導き出すことができます。 VDIの例では、代替ソリューションとして、読取りに最適化された安価なeMLCフラッシュ上にブー ト・イメージを配置できます。1,000人のユーザーがいる場合、ブート・イメージの配置のために必 要になる容量は1TBの約半分（つまり500GB）です。この容量があれば、ゴールデン・ブート・イメー ジとすべての共有アプリケーション（Microsoft Exchange、SharePoint、DLLライブラリなど）を収 容できます。 VDI環境のユーザー・データに関しては、"マイ・ドキュメント"、"マイ・スキャン"、"マイ・ピク チャ"などへのユーザーあたりの持続的なI/O速度について検討します。一般的に受け入れられる統 計値として、おそらくユーザーあたり4 IOPS/秒くらいが現実的です。ユーザーあたり4 IOPS/秒で あれば、フラッシュはソリューションとして推奨されません。また、共有データ・ディレクトリに ついても検討してください。共有データ・ディレクトリでは、ユーザーの生産性を損なわないよう に、容量と十分なパフォーマンスとのバランスを図る必要があります。ユーザーがWordに段落を入 力し、スペルの修正を行い、Excelに複雑な式（5つの埋込みIF文とデバッグで構成される式）を入 力した後に保存アイコンをクリックしてディスクI/Oを引き起こすような場合もあります。実際のと ころ、持続的なユーザーIOPSは非常に低く、オール・フラッシュ・アレイを購入する必要はまった くありません。500GB程度のフラッシュLUNをOracle FS1-2上に割り当てるだけでよいため、5分の1 以下のコストで済みます。 5 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック アクセス・パターンの例からわかる重要な教訓は次のとおりです。本当にホットなデータは全体の4 ～6%の範囲にあり、おそらく全I/Oの80～90%がこの範囲に該当します。差分変更レプリケーション・ テクノロジーにより測定された過去の調査によれば、顧客データの変更率は一定の割合を示し、保 護されるボリューム・セット内に含まれる全データの3～5%に収まることがわかっています。このこ とから、新しいホット・データはおそらく4～6%程度であると仮定されます。 多層化されたファイル・システムやアーカイブ・マネージャ（オラクル製品の場合はStorageTek Storage Archive Manager）の過去20年以上の実績では、アーカイブ・クラス・データに対する頻繁 に変更される新しいホット・データの割合は3～5%です。このことにより、SSDレベルのパフォーマ ンスを必要とする本当にホットなデータは、データ・セット全体のわずかな割合で構成されること が実証されます。また、このことは、オール・フラッシュ・アレイがおそらく良いアイデアではな いことの裏付けにもなっています。フラッシュレベルのパフォーマンスが不要な95%のデータに対し てフラッシュレベルのコストを支払うことになるからです。言い方を変えれば、"容量の少ないフ ラッシュが大きな効果を発揮する"のです。 データ・アクセス・パターンの例は注意喚起のための情報であり、高価なフラッシュ・ストレージで 賢く管理することもできます。これはまさにOracle FS1-2 Flash Storage Systemが実行することで、 隠れた突然の請求やソフトウェア容量のペナルティが発生することはありません。Oracle FS1-2 Flash Storage Systemは、パフォーマンスとビジネス・インテリジェンスを両立させた史上初のアレイです。 データの偏りの詳細 偏りは大きくも小さくもなります。ストレージの意思決定者は、"構成するフラッシュ・ストレージ の最適な容量はどの程度か"、および、"必要なメトリックは何で、それらのメトリックはどうすれ ば取得できるか"、について考察する必要があります。これらの疑問に答えるには、偏りのメトリッ クを定義して、それらのメトリックの計算方法を考察し、さらにフラッシュの追加に対する"収穫逓 減の法則"の適用方法についても考察する必要があります。目標は、ホットでないデータに対してフ ラッシュを過剰に構成することなく、良い成果を得るために十分なフラッシュを構成することです。 偏りの定義 偏りについては、特定の容量に対する非線形のディスク・アクセスを説明するための、共通的に用 いられる公認の定義は存在しません。偏りが大きいほど、ディスク・アクセスの傾向が一様ではな くなります。より便利な別の用語によって、偏りを数値で表現できます。その用語とは"偏り転換点 "です。これは、I/Oのパーセンテージと、それらのI/Oがアクセスする対象の総容量に対するパーセ ンテージを足した値が1になる時点として定義されます。次に例を挙げます。85%のIOPSが15%の容量 内に収まる場合、結果は0.85 + 0.15 = 1になります。この場合の偏り転換点が85%となります1。こ れは単純ですが、偏りを考察するための有益な方法です。いずれかの値がわかっていれば、ユーザー はもう一方の値を求めて、ティアゼロSSDストレージの必要容量を簡単に算出できます。 現時点で、偏り転換点を明示的に計算するツールや、特定のアプリケーションまたはアプリケーショ ン・セットでの偏りを正確に計算するツールはありません。このホワイト・ペーパーの前項では、一 般的なワークロードに基づいて、偏りの合理的な仮定値を示しました。ストレージの意思決定者は、 アプリケーション内のデータの流れを考慮して、この仮定を検証できます。仮定が前述の境界の内部 にある場合（つまりホット・データが3～6%の場合）、おそらくこれで問題ありません。仮定が境界か -------------------------------------------------1 偏り転換点（収穫逓減点）はここでは特定の1つの値として表されていますが、実際の環境では、この点の周り に集まる大小の複数の値の範囲を表します。そのため、偏り転換点は、ビジネスにとって高い価値を生み出す フラッシュ・ストレージ容量を計算するための合理的な出発点であると考えてください。 6 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック ら大きく外れる場合は、最終的な構成の設計を行う前に、仮定を再評価する必要があります。 偏り転換点（収穫逓減点） 図1に偏り転換点（収穫逓減点）のグラフを示します。左下隅はIOPS 0%、容量0%の時点を表し、右 上隅はIOPS 100%、容量100%の時点を表します。この2つの評価値を加えた値は（例では0.85と0.15） 0～2の範囲に収まります。左側の曲線部（緑の矢印）は、SSD容量を少し追加するだけでパフォーマ ンスに大きく影響する（SSDの有用性が高い）領域を表します。右側に進むと（青の矢印）、データ・ アクセスのIOPSが非常に小さくなるため、SSD追加の有効性は低下します。収穫逓減点とは、容量の パーセンテージとIOPSのパーセンテージの合計が1になる点です。かならずしも完璧な時点ではあり ませんが、SSD容量の追加をやめるべき時点に非常に近いものとして使用できます。 図1：偏り転換点のグラフ この時点でデータの大部分がコールド状態であり、ほとんどIOPSを消費していないことは明白です。 ここで、"大半のデータがホット状態ではない場合に、すべてのデータをオール・フラッシュ・アレ イ（AFA）に配置することは合理的か"、という重要な疑問に戻ると、この答えは、合理的ではない、 ということになります。コールド状態または微妙にホットなデータを高価なフラッシュ・メディア に配置することは投資の無駄であり、その投資は企業の他の分野に割り当てた方が良いでしょう。 多くのAFAベンダーは、統合された重複排除および圧縮の機能が、その製品がよりお手頃になる"秘 伝のソース"だと宣伝しています。変化の激しいホットなOLTPのデータ量を5分の1に削減することに はおそらく多くのコストがかかりますが、それでも良ければ導入してください。さらに追い打ちを かけるようですが、アクティブなデータに対して重複排除や再ハイドレートが常に実行されること から、パフォーマンスに何らかの影響があります。また、AFAベンダーが販売しようとしている"デー タ・シートのパフォーマンス"にも影響があります。 データ量が5分の1に削減されると、当然ながらストレージ・コストも5分の1に削減されます。しか し、4TB容量のHDDとフラッシュ・メモリのコストには30倍の差があります。ほとんどのケースで90% のデータがコールド状態でありフラッシュレベルのパフォーマンスを必要としていないことを考慮 すれば、95%のデータでコストが30分の1になることと比較して、100%のデータでコストが5分の1に なる方を選択する人はいないでしょう。数字が明白に示してくれます。 この偏り転換点の例では、生成されるIOPSの85%をフラッシュ上で実行する場合に、総容量の15%に 相当するフラッシュをプロビジョニングすれば十分であることになります。前述のとおり、実際の 7 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック 環境では、収穫逓減点はもっと極端になる傾向にあります。観測されるI/Oの偏りの大部分は、デー タの3～6%の範囲で表されます。（SPC-1ベンチマークのように）収穫逓減点が95%程度になることも 珍しくありません。容量の少ないフラッシュが大きな効果を発揮するのです。 フラッシュ容量の計算：最上層から最下層へのロールダウン フラッシュ層と下位の複数の層の両方に必要となる容量を見積もるための基本的な方法は、各層で 吸収する必要のあるI/O総量（層吸収率）を確認して、各層に必要となるストレージ容量を計算する ことです。たとえば、ある環境の偏り転換点が80%で、必要となるIOPS総量が50,000の場合、最上層 ではそのI/Oの約80%（40,000 IOPS）を吸収する必要があります。その後の低パフォーマンスの層で は、残りの20%（10,000 IOPS）に対処する必要があります。複数の層から成る場合、ユーザーは残 りの20%のうちの80%（つまり16%）のI/Oを次の層に割り当てます。このプロセスを最下層に達する まで繰り返します。 各層のサイジング 各層のサイジングを行うために、フラッシュとHDDにおけるパフォーマンスの違いを理解することが 役に立ちます。表1の数値は、最近観測されたテスト結果であり、複数のワークロードの平均を表し ます。これらはデータ・シートの値（実環境のアプリケーション・パフォーマンスを表していない 値）ではありません。アプリケーション・インタフェースではなくドライブ・インタフェースで測 定された、テスト環境での実験上の単一ドライブのパフォーマンスを表します。ブロック・サイズ は4Kから8Kの範囲にあります。RAIDライト・ペナルティは以下に挙げるようにRAIDタイプによって 異なります。 表1： メディア・タイプ（ドライブごと） IOPS2 コメント SLC SSD 15,000 70%読取り、30%書込み eMLC SSD 9,000 90%読取り パフォーマンス重視型HDD 225～250 70%読取り、30%書込み 容量重視型HDD 90～100 70%読取り、30%書込み 読取り/書込み比率は、"ホストIOPS"と比較した"バックエンドIOPS"の実際値を計算するのに不可欠 です。以下で説明するように、さまざまなRAIDタイプで読取り-変更-書込みのオーバーヘッド（RAID ライト・ペナルティ）が課されるためです。このRAIDライト・ペナルティを考慮に入れる必要があ ります。 RAIDタイプ RAID 10 RAID IO 2 -------------------------------------------------2 上記のIOP値は、ホストで測定されたSAN接続ストレージのさまざまなワークロードにわたって達成可能な値の 代表値です。一般的にフラッシュ製品のデータ・シートにはもっと高い値が記載されていますが、その値は単 一の空のドライブをカスタムの実験環境でテストした場合の結果であり、実際のアプリケーション環境で実現 されるものではありません。 8 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック RAID 5 4 RAID 6 6 ほとんどのOLTPワークロードの読取り/書込み比率は80%/20%か70%/30%です。ただし、NFSネットワー クを経由したファイル送信などの一部のワークロードでは、バックエンドの読取り/書込み比率は 50%/50%程度になり、この場合は大きなRAIDライト・ペナルティが課されます。 ホスト向けの必要なNFS操作を実行するには、ディスクIOPSの増強が必要になります。そのほかに、 読取りに対する書込みの比率が高いアプリケーションとして、一部のVDI実装や多数のメール・サー バーが挙げられます。 あらゆるタイプのフラッシュで読取り処理を高速に実行できますが、書込みについては、SLCタイプ のフラッシュ・ドライブが優れている一方で、eMLCフラッシュ・ドライブは優れていないことに注 意してください。 ライト・ペナルティの計算 以下の単純な例では、ある特定のアプリケーションで、層ごとに必要になるIOPSと容量の計算方法 を示します。偏り転換点を80%、読取り/書込み比率を80%/20%と仮定します。以下の計算式は、フラッ シュ・プール内部の必要フラッシュ容量と、下位の層で必要となるその他のストレージ容量を計算 する方法を示すものです。 計算式 0.80 * 50000 = 40,000 IOPS：偏り因子が80%の場合に、最上層のフラッシュ層内部で必要となるIOPS。 残りの10,000 IOPSについては、次のルールが適用されます。残りのIOPSの80%のデータ配置をすぐ 次の層に割り当てます。このプロセスを最下層に達するまで繰り返します。 すぐ次の層には残りの10,000 IOPSが割り当てられ、次のように吸収されます。 (0.8 * 10000) = 8,000 IOPS：パフォーマンス重視型SAS (0.2 * 10000) = 2,000 IOPS：容量重視型SAS ライト・ペナルティを適用する前の各層のIOPSは以下のようになります。 フラッシュ：40,000IOPS パフォーマンス重視型SAS：8,000IOPS 容量重視型SAS：2,000IOPS 合計：50,000IOPS ライト・ペナルティ 上記の計算は一見すると適切であり、必要な50,000 IOPSが3層のすべてに分散されています。しかし、 RAIDライト・ペナルティがあるため、アレイでの実際の実行内容を正確に表したものではありません。 ストレージの意思決定者がこのRAIDライト・ペナルティ因子の重要性を理解するには、容量が4TBのHDD による事実上の書込みIOPSを考慮する必要があります。仮定として、読取りIOPSが1秒に903回発生するも -------------------------------------------------3 100、110、120などの意見もあり、この値はシーク距離とドライブ内でキューイングされるコマンド数によって 変わります。このモードは前述のとおり控えめな値です。推奨される対応策として、予想値を代替の方法より 9 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック のとします。その場合、RAID 6を使用すると、書込みIOPSは15という実に低い値になります（6倍のペナ ルティを適用）。バックエンドのディスク負荷はホスト駆動型I/Oよりも高くなり、驚くほど高い負荷に なることもよくあります。バックエンドに負荷がかかるということは、必要になる正確なスピンドル数 の計算にライト・ペナルティが含まれることを意味します。この例では書込みは約20%を占めるため、ホ スト・アプリケーションから送信される50,000 IOPSよりも多いバックエンドIOPSが必要になります。 バックエンドの計算 バックエンドの計算方法は以下のとおりです。 SSD層： (0.8 * 40,000) + (2 * 0.2 * 40,000) = 32,000 + 16,000 = 48,000 IOPS：RAID 10を使用したSSD 層の場合（この例では400GB SLC）、または (0.8 * 40,000) + (4 * 0.2 * 40,000) = 32,000 + 32,000 = 64,000 IOPS：RAID 5を使用する場合 （最初に計算したホストの40,000 IOPSと比較して特に高い） HDD層： 以下のRAID 6の例では、10Kの2.5インチHDDを使用しています。 (0.8 * 8,000) + (6 * 0.2 * 8,000) = 6,400 + 9,600 = 16,000 IOPS：パフォーマンス重視型SAS でRAID 6を使用する場合 (0.8 * 2,000) + (6 * 0.2 * 2,000) = 1,600 + 2,400 = 4,000 IOPS：容量重視型SASでRAID 6を使 用する場合 常識的な修正点 これらの例が示すとおり、最下層ではIOPSがほとんど吸収されません。容量重視型ディスクの処理 速度は非常に遅いため、このことは想定内です。ただし、Oracle FS1-2の場合、4TBの容量重視型ディ スクの粒度は大きく、80TBものディスクを利用できます。大容量のディスクが不要な場合は、別の パフォーマンス重視型HDDのトレイを追加して、エンタープライズの要件に対応する十分な容量を確 保することが解決策になります。 クール化期間 単純な経験則として、クール化期間が短いほど、偏り転換点は高くなります。たとえば、データが 30日以内にクール状態になる場合は、データが60～90日以上の期間でクール状態になる場合と比較 して、ある特定時点でホット状態にあるデータ・ブロック数が少なくなります。前述のとおり、一 般的にクール化期間が長期化するのは、レポートや請求、分析などのために、データが後で処理さ れるためです。このような後処理ルーチンは基本的に読取り専用の機能であり、その場合はOracle FS1-2の1.6TB eMLCフラッシュ・ドライブを利用するのが最適です。eMLCドライブの読取り速度はSLC フラッシュとほぼ同じですが、容量ベースでは約50%のコストで済み、ドライブ・フットプリントあ たりの保存可能データ量は4倍になります。クール化期間は多くの場合、クール化曲線によってグラ フィカルに表現できます。この曲線については、以下の項で説明します。 も低く抑えて、実際には高いパフォーマンスを発揮できるようにします。 10 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック クール化曲線 クール化曲線は多くの場合、時間が経つにつれてアクセス密度が双曲的に低下する滑らかな曲線と して描かれます。ただし、実際にこうなることはありません。トランザクション・データの場合、 トランザクション完了後にアクセス密度が急低下しますが、後になって、たとえば30日の請求期間 中に再びアクティブになります。ほとんどのアレイ・ベンダーの自動階層化アルゴリズムは、この ような予期されない振る舞いによって混乱に陥り、その結果、データがあまりにも速く下層まで降 格され、それ以降、データが再びホット状態になったときにパフォーマンスの問題が発生すること になります。しかし、Oracle FS1-2ではこのような事態になりません。自動階層化されたフラッシュ・ アーキテクチャには、実環境で観測される振る舞いも設計に組み込まれているからです。 図2：クール化曲線のグラフ 前述の電気通信と金融サービスのアクセス・パターンの両方で、やや長いクール化期間になります （45～60日またはそれ以上）。少ない容量のSLCフラッシュに対して書込み頻度の高い初期のトラン ザクションを保存した後、Oracle FS1-2によって、クール状態になった完了後のトランザクション をeMLCフラッシュに移行できます。この方法では、SLCのみの実装と比較して低いコストかつ小さな フットプリントによって、アプリケーションに対してクール化期間全体でフラッシュレベルのパ フォーマンスを実現できます。以下の項に示す修正後のクール化曲線は、データの"再ホット化"の シナリオを視覚的に表現した例となっています。 Oracle Databaseのデータ・クール化に関する考慮事項 1つのフラッシュ層から成る初期の第1世代自動階層化アレイを導入した企業は、しばしばOracle Databaseの深刻なパフォーマンス問題に悩まされています。この問題は、アレイがトランザクショ ン・データをSLCフラッシュから容量重視型HDDに直接移行する際に発生します。ユーザーが月また は四半期に一度のレポートを作成する時期や、ビジネス分析を実行する時期になると、パフォーマ ンスが極度に低下します。これは、あるベンダーが顧客に対して、解決策としてトランザクション・ データベースの自動階層化を無効にするように指示し始めたことから、大きな問題につながりまし た。大容量eMLCフラッシュ・ドライブを利用するOracle FS1-2の場合は、移行されたデータでもフ ラッシュレベルの読取りパフォーマンスが維持され、レポート処理が影響を受けることはありませ ん。これはOracle FS1-2の独自機能であり、後処理のレポート作成や分析で広範囲にアクセスされ るトランザクション・データベースに対して活用される機能です。 11 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック 図3：請求サイクルを適用したクール化曲線のグラフ ほとんどのクール化曲線はこのように滑らかな曲線として描かれますが、実環境でもそのようにな るのでしょうか。おそらくは違うでしょう。データのクール化や再ホット化は、もっと急激に荒々 しく起きる傾向にあります。たとえば、四半期に一度のレポートを作成する際に、ゆっくりと開始 されてその後加速するということはなく、急激に開始されます。その際に、適切なデータがその場 にある必要があります。たしかに、複数のレポートがすべて同時に実行されるわけではなく、ある 程度の傾斜時間はありますが、それは滑らかにはなりません。クール化と再ホット化のサイクルを より適切に表現すると、以下のようになります。 図4：ビジネス・サイクルでのクール化のグラフ ここからわかることは、自動階層化アレイに迅速な学習機能が必要であり、実際のビジネスでのデー タ利用状況によってデータ移行にバイアスを適用する機能をサポートしなければならないことです。 Oracle FS1はまさにこの機能をQoS-Plusによってサポートしています。QoS-Plusは、頻度ベースの 自動階層化と、オラクルが特許を保有するQoSを組み合わせた機能です。QoS-Plusを複数のフラッ シュ層で一緒に使用することで、大容量で低コストのeMLCベースのフラッシュ層にホット・データ を降格できます。そのため、請求処理によって再ホット化されたり、金融レポート処理が発生する 場合に、高価なSLCフラッシュのコストをかけずに、アプリケーションで非常に高速なフラッシュ読 取り率の恩恵を受けられます（これらの再ホット化はほぼすべて読取り処理です）。 データ成長率 データ成長率も、大部分のホットI/Oの保存に必要になるフラッシュ容量を見積もる際に有用なメト リックの1つです。新しいデータは当然ながらホット・データになるでしょう。たとえば、30TBのデー タがあり、1年に20%ずつ成長することが見込まれる場合、1年あたり6TB（1日あたり約16.4GB）を追 加することになります。平均的なクール化期間が60日であれば、986GB（約1TB）のデータがホット 12 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック 状態になる可能性が高くなります。これは全体の3.3%に相当します。3.3%というのは最小値に近い ものの、実用的な境界仮定値の範囲に収まっています。 ストレージ・メディア・タイプの経済性（ビジネス価値） 今日入手できるストレージの1GBあたりのコストには30倍の違いがあり、メディア上のI/Oあたりの コストには27倍の違いがあります。このことから明らかにわかるメッセージは、企業にとって、もっ とも費用対効果の高く、しかもパフォーマンス、待機時間、および帯域幅に関するビジネス目標を 達成できるデータ保存用メディアを利用することが不可欠だということです。以下の表は、このホ ワイト・ペーパーの執筆時点でOracle FS1-2に使用されているメディアの容量とIOPSに関する相対 コストについて示したものです。 表1： メディア・タイプ $/IOPS $/GB 300GB HDD 10K RPM SAS 2.5インチ $1.92 $1.60 900 GB HDD 10K RPM SAS 2.5インチ $3.09 $0.86 4TB HDD 7,200 RPM SAS 3.5インチ $11.20 $0.25 400GB SLC SSD SAS 2.5インチ $0.41 $7.50 1.6 TB eMLC SSD SAS 2.5インチ $1.23 $4.50 この価格対性能比の表をグラフィカルに表現すると以下のようになります。 図5：メディア・タイプ別の価格の違い 13 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック 容量コストとパフォーマンス・コストにおけるこのような驚くべき違いを活用するための唯一の方 法は、ストレージ・アレイで使用される管理フレームワークが、高いパフォーマンスおよび低い $/IOPSを必要とするホット・データと、大容量および最高の$/GBを必要とするコールド・データを 区別することです。このかつてないほど頻繁に変化するアクセス密度の組合せは常に進化していく ため、これを区別する機能は、アレイで暗黙的に実現される必要があります。従来のアクセス・パ ターンの見直しだけでは十分ではありません。価値の低い"ジャンク"データがよりコストの高い層 に昇格され、高いビジネス価値を持つデータが犠牲になることも十分にありえます。これは、バッ ク・ミラーを見ながら車を運転しようとしているようなものです。カリフォルニア州北部の国道101 号線や東海岸の95号線でそのような実験をすると面白いでしょう。どのような結果になるか考えて みてください。アクセス頻度の履歴だけでは、ビジネス価値を持続させるための解決策にはなりま せん。 データの価値と参照頻度に基づいて、複数の層のデータ移動にバイアスを適用する機能が必要です。 また、I/Oタイプ（ランダムか順次的か、読取りバイアスか書込み中心か）についても考慮する必要 があります。たとえば、非常に順次的なI/Oには容量重視型メディアが適しており、このタイプのア クセス・パターンにはフラッシュは不要です。読取り中心のデータはeMLC読取り最適化フラッシュ に保存すれば上手く行きます。このフラッシュはSLCフラッシュよりも大幅に低コストで、その密度 は4倍を超えます。これまでの説明から、Oracle FS-1で以下のすべての変数が考慮されていること は驚きではないでしょう。これは純粋で単純な経済性の問題です。 1層のアレイでは、どれほど処理が速くとも、もっとも高価な層に（その層のみに）コールド・デー タが保存されるため、コストははるかに高くつきます。 重複排除では、入念に設計されたハイブリッド・アレイにより達成可能な30倍という$/GBの範囲 には及びません。そのため、重複排除というのはマーケティング上の作り話になっています。 低パフォーマンスHDDのオーバープロビジョニングにより、アレイの平均的な稼働期間（3～5年） におけるフットプリント、電力、および冷却のコストが大幅に増加します。初期取得コストがお そらく高くなることは言うまでもありません。 最後の疑問は次のとおりです。"なぜ企業は、コールド・データをフラッシュ上に保存するか、HDD をオーバープロビジョニングして、数百台のドライブによる問題を解消しないのか"。その答えは、 そうすべきではないから、それだけです。今日入手できる中でもっともインテリジェントで費用対 効果の高いディスク・アレイである新しいOracle FS1-2フラッシュ・ストレージ・アレイについて 詳しく見てみましょう。このアレイでは、必要な場所で優れたパフォーマンスが発揮され、必要な ときの（常に必要ですが）予算は抑えられます。ビジネス価値によるバイアスを適用した自動階層 化を行う組込みのデータ管理ソフトウェア（QoS Plus）が付属しており、追加費用なしで使用でき ます。そのため、"容量税"や"成功税"はかからず、隠れた突然の請求が発生することはありません。 高い価値を享受できるだけです。 Oracle FS1-2の概要 Oracle FS1-2はハイブリッド自動階層化ストレージ・アレイであり、パフォーマンス重視型と容量 重視型の両方のフラッシュSSD（SLCフラッシュとeMLCフラッシュ）、およびパフォーマンス重視型 HDDと容量重視型HDD（2.5インチSAS-2と3.5インチSAS-2）で構成されます。最大912TBのフラッシュ・ ディスクのスケーラビリティを持ち、最大のアップタイムとデータ可用性を実現するエンタープラ イズ・クラス機能を装備するように設計されています。 14 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック 1秒未満のフェイルオーバー能力 ウォーム・スタート・テクノロジーによるエラーからの高速リカバリと中断なしのファームウェ ア・アップグレード シングル・ポイント障害（SPOF）なし プリエンプティブ・コピー（ドライブ・エラー・リカバリ情報やその他の差し迫った障害の兆候 を使用した、差し迫ったディスク障害の検出（オラクルが開発）） SSD"計器"（SSDの残りの耐用期間） T10保護情報（T10 PI）による、発見されにくいデータ破損の検出 シン・プロビジョニングとコピー・サービス - すべてソフトウェアに付属する機能であり、追加 費用なしで利用可能 同期および非同期の動作モードでのレプリケーション・オプション：ファン・イン/ファン・アウ ト、マルチホップ、双方向の各トポロジ。すべて、一貫したアプリケーション・リカバリ・オプ ションとともに提供されます。4 Quality of Service Plus（QoS Plus）機能では、使用パターン（I/Oアクセス頻度）が考慮されて いますが、同時にデータの重要性が高い（ビジネス価値が高い）、低い（ビジネス価値が低い）、 中程度のいずれであるかを識別し、キューを管理して自動階層化の決定にバイアスを適用するアル ゴリズムも利用しています。さらに、I/Oタイプ（ランダムか順次的か、読取り操作か書込み操作か） も利用しています。その結果、サブLUN階層化アプローチを使用して、$/IOPおよび$/GBの観点から、 もっとも費用対効果の高いメディアに適応的かつ自動的にデータが移動されます。価値の低いデー タは低コストのHDDメディアに配置され、価値が高く重要なホット・データはパフォーマンス重視型 メディアに配置されます。 さらに、Oracle FS1-2システムは、Hybrid Columnar CompressionなどのOracle Database機能もサ ポートしています。Hybrid Columnar Compressionは、物理ストレージを追加しなくて済むように、 最大30倍の圧縮率によって効率化します。HCCの圧縮率が30倍であることと、パフォーマンス重視型 メディアと容量重視型メディアの$/GBのコストに30倍の差があることを組み合わせると、発生する ストレージ・コストにおける全体的なコスト削減幅は、実に900倍にもなります。次のような単純な 問題を考察してみてください。ほぼすべてのデータで偏りの値が大きいことがわかっている場合に、 高コストのフラッシュ・メディアに100%のデータを保存しようと思うでしょうか（多くのオール・ フラッシュ・アレイ（AFA）ベンダーは重複排除によりデータが5分の1になると約束していますが、 これが実際に達成されることはほとんどありません）。それとも、GBあたりのコストを900分の1に 削減できるメディアに95%のデータを保存し、オラクルのAdvanced Compression Option（ACO）を使 用して"カタログ価格"が3分の1のフラッシュに5%のデータを保存しようと思うでしょうか。この場 合、追加の利点としてデータの自動最適化（ADO）により、データが古くなったときに、最適なHCC 圧縮スキームがデータベースにより自動的に起動されます。数字が明白に示しているとおり、後者 のケースでは、データ管理が完全に自動化されるため、はるかに高いビジネス価値が得られます。 -------------------------------------------------4 レプリケーション・ソフトウェアは、FS1で唯一ライセンス提供されるソフトウェアです。他のデータ管理機能 はすべて標準的に付属しており、追加費用なしで利用できます。 15 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック これは、オラクルだけが提供できる機能です。 Oracle Databaseの一機能であるデータの自動最適化のサポートに加えて、ITおよびユーザーの効率 性をさらに高めるためのOracle Enterprise ManagerおよびOracle VM Storage Connect機能のプラ グインも用意されています。Oracle FS1-2システムのデータ・シートに追加情報が記載されていま す。 オラクルが提供する複数の機能が融合され、互いに組み合わされて提供されるところが、Oracle Red Stackの基本的な優位性です。 16 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック 結論 このホワイト・ペーパーで説明した実証に基づくデータとIOPS計算手法によって、ストレージの意 思決定者はOracle FS1-2自動階層化アレイを強い確信を持って構成できるようになります。Oracle FS1-2自動階層化アレイは、企業の長年にわたる投資を保護し、ユーザーが期待する以上の成果を出 し、過度に積極的なデータ降格によるパフォーマンス問題を回避するように設計されています。い ずれの層にも容量を即座に追加できます。追加した容量は、アプリケーションや手動の多層間デー タ移行要件に影響を及ぼさずに、Oracle FS1-2 Flash Storage Systemによって自動的に利用されま す。 複数の実環境の観測や、数学的に正当な見積もり手段に基づけば、ある任意の時点でデータがホッ ト状態にある確率の範囲は、最小で3%以下、最大で6%以上であると合理的に見積もることができま す。この見積もり範囲は、最終的なアレイ構成を洗練していくための出発点として適しています。 企業のすべてのデータを同じ層（フラッシュ、高パフォーマンスHDD、またはその他のオプション） に配置することは、経済性の観点ではほぼ誤った判断であると言えます。ハード・ドライブを大幅 にオーバープロビジョニングしている企業や、オール・フラッシュの導入を選択した企業は、最終 的にはパフォーマンスに対して過度なコストを支払い、このテクノロジーでは適合しない問題を解 決しようとして、誤って高価なリソースを割り当てることになります。 また、QoS Plusは、頻度ベースの多層化に対して、ビジネス価値とI/O構造によるバイアスを適用し ます。これは、単純に利用頻度から判断する場合とは異なり、データの場所およびその結果として のパフォーマンス特性をビジネス・ニーズと整合させることのできる業界初の機能です。複数のフ ラッシュ層により、クール化期間が長く、あるいは均一ではないアプリケーションに対して、費用 対効果の高いフラッシュレベルのパフォーマンスを一貫してもたらすことができます。 Oracle FS1-2 Flash Storage Systemは、この市場においてもっともインテリジェントで費用対効果 に優れた自動階層化アレイです。このハイブリッド・アレイを使用すれば、企業が何に対して対価 を払うかを事前に把握することができ、"成長税"や"成功税"を支払うことはありません。 ハードウェア上で稼働するソフトウェアの開発チームとともにそのハードウェアを開発できる場合、 その成果が、ばらばらの部品を集めたものよりもはるかに優れたものになるのは明確です。それが、 オラクルだけが提供できるOracle Red Stackなのです。 17 データの偏りに基づいたOracle FS1-2ストレージの構成方法：アレイ構成における新しい最重要メトリック データの偏りに基づいたOracle FS1-2 Copyright © 2015, Oracle and/or its affiliates. All rights reserved. ストレージの構成： アレイ構成における最重要メトリック 本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は一切間違いがない ことを保証するものではなく、さらに、口述による明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての 2015年2月 黙示的な保証を含み、いかなる他の保証や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、 Oracle Corporation World Headquarters 500 Oracle Parkway 本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、 いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。 OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。 Redwood Shores, CA 94065 IntelおよびIntel Xeon はIntel Corporation の商標または登録 商標です。 すべてのSPARC商標 はライセンス に基づいて 使用され る SPARC U.S.A. International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録 お問い合わせ窓口 Oracle Direct 0120-155-096 oracle.com/jp/direct 商標です。UNIXは、The Open Groupの登録商標です。0114