デジタルプラクティス Vol.9 No.2 (Apr. 2018)

Software Defined Storage 分散ストレージにおけるデータ可用性/保護の実装と実機検証に基づく提言

斎藤 彰宏1  南 聖二1  岡野 一恵1  倉前 裕成1

1日本アイ・ビー・エム(株)

Software Defined Storage(SDS)は,コモディティサーバを利活用することで,ストレージ機能を実現する新しい技術分野である.市場からの注目度が高く,著しい速度での技術革新が進んでいる.一方で従来のストレージ専用機器と比較してデータ可用性/保護について不十分な点があり,高信頼性が求められる企業の基幹システムへの導入には障壁がある.筆者らはこれまで実業務で多くの試行錯誤を繰り返しており,その中で蓄積された実績と経験を踏まえ,データ複製技術等の適切な活用で不足は補えることを,障害分析(CFIA)と実機での概念実証により確認した.読者の皆様が本稿をSDS導入設計の検討の手引書として利用いただくことにより,SDSの導入を円滑かつ適正に実施いただくための手助けになることを企図している.

1.はじめに

Software Defined Storage (SDS)は2017年現在,市場で注目度の高い技術分野の1つである.市場調査では半数以上の企業で導入を検討しており[1],今後の年間平均成長率は30%以上と予測されている[2].一方で信頼性が低いとの指摘も多い[3].現時点でのSDS採用は非基幹業務での利用が中心[1]だが,今後の基幹システムへの導入において,信頼性への不安は大きな障壁になると考える.筆者らは多くのプロジェクトでSDSの導入と設計を行っており[4],その経験から有効性が実証されたノウハウを本稿としてまとめた.

まずSDSのデータ可用性/保護機能を評価し,課題点を明確化する.次にSDSのデータ可用性/保護の手法を提言し,構造解説と概念実証としての検証結果をまとめる.最後に本稿で提言した手法が前述の課題の解決を評価し,設計における可用性/保護方法選択の基準を提示する.なお,SDSは技術進歩がきわめて早く,特定の技術や製品バージョンを前提とした記述は,適宜更新が難しい論文では内容が早々に陳腐化することが避けられない.本稿は読者の有用性に配慮し,また宣伝を避ける意図もあり,可能な限り特定の技術に特化した記述を避けている.また本稿は筆者らの個人的な見解であり,所属する団体,組織の意見を代表するものではない.

2.SDSのデータ保護構造と課題点

本稿におけるSDSは複数のコモディティサーバの内蔵ストレージを利用する分散ストレージを指す.

SDSを構成するディスクやノードが障害で失われたときに,データロストを回避しサービスを継続提供する機能は,「ノード冗長性」として大部分のSDSに実装されている.ノードに収納されたデータは,他ノードにもコピー(ミラー)されており,1ノードが障害で失われても,ほかのノードのデータによって業務の継続が可能である.データの冗長は,2ノード間でのデータ複製が主流である.一方でストレージ専用機器では,コントローラの冗長と,RAID (Redundant Arrays of Independent Disks) および内部経路冗長として実装されることが一般的である(図 1).

図1 SDSの冗長方式 右:ストレージ専用機器冗長方式

2.1 スナップショット機能の技術構造

ストレージ専用機器やSDS技術には,特定時点のデータをイメージとして保存する「スナップショット機能」が実装されている場合が多い.ストレージ専用機器のスナップショット方式は,大きく分類するとRedirect-On-Write(ROW),Copy-On-Write(COW),Clone/Split Mirror,COW with Background Copy(COW with BC)の4方式が一般的である[5](図 2, 図 3).

図2左のCopy-On-Write(COW)は,スナップショットのためのストレージ領域(スナップショットポインタと追加変更データ領域)を確保した上で,スナップショット実施時点でデータのメタデータとしてストレージ上のロケーション情報をスナップショットポインタ領域に格納する.その後データ領域が更新されたときには更新前に変更前データを追加変更データ領域に複製した後でデータ領域の更新を行う方式になる.ボリュームポインタ領域への複製とデータ領域の更新の仕組みから「Copy-On-Write」と呼ばれる.

図2 左:Copy-On-Write, 右:Redirect-On-Write
図3 左:Clone/Split Mirror, 右:COW with BC

図2右のRedirect-On-Write(ROW)は,COWと類似した技術で,スナップショットのためのストレージ領域(スナップショットポインタと追加変更データ領域)を確保する点は同じである.COWと異なるのはデータ更新の反映プロセスであり,データ領域への変更は追加変更データ領域への新規書き込みとして実装し,データ領域への変更は行わない.この仕組みから「Redirect-On-Write」と呼ばれる.Copy-On-Writeと比較してデータ更新の仕組みが単純のため,スナップショット実施によるストレージ性能劣化を抑えることができるのが利点である.ROWとCOWに共通する弱点は元データの一部をスナップショットのデータ維持に利用する構造のため,元データが破損したときはデータを復元できない.したがって故障などの障害に有効な保護対策ではない.

図3左のClone/Split Mirrorは,データの完全同一コピーを作成する方式で,スナップショットのためのストレージ領域はデータ領域と同一容量の複製データ領域の確保を必要とする.通常時にデータ領域が更新されたときには,データ領域と複製データ領域を同じときに更新する同期状態で運用し,スナップショット実施時点で,複製データ領域を切り離す.スナップショット実施後のデータ更新は,データ領域のみに行い,複製データ領域には反映しない方式になる.データ領域の完全な複製(クローン)を必要とし,スナップショットは複製データ領域を切り離す(スプリット)仕組みから,「Clone/Split Mirror」と呼ばれる.

図3右のCOW with Background Copy(COW with BC)は,COWと Clone/Split Mirrorのハイブリッドである.スナップショットのためのストレージ領域はClone/Split Mirrorと同じくデータ領域と同一容量の複製データ領域の確保を必要とする.通常時にデータ領域が更新されたときには,データ領域のみデータ更新を行い,スナップショット実施時点で,データのメタデータとしてストレージ上のロケーション情報をスナップショットポインタ領域に格納し,データ領域と複製データ領域を同期する.スナップショット実施後にデータ領域と複製データ領域の同期が完了するまでの間に,データ更新が発生した場合は,更新前に変更前データを追加変更データ領域に複製した後でデータ領域の更新を行う方式になる.このデータ方式はCOWに近く,「COW with Background Copy」と呼ばれる.

Clone/Split MirrorとCOW with BCは故障で元データが消失した場合も元データを復旧できる.したがって故障時にもデータ保護可能な対策である.

2.2 SDSのデータ可用性/保護の評価

SDSとストレージ専用機器のデータ可用性/保護の実装の分析と評価を行う.比較の方法として特定保護対象への影響度を表現する構成要素障害影響分析手法(CFIA:Component Failure Impact Analysis)を利用した[6].部品故障は原則として単体故障を想定しているが,ハードディスク(ディスク)に関しては,データロストに直結する故障による障害影響の大きさから複数同時故障も想定することとする.この場合の複数とは2個以上の個数を指すが,その具体的な数はストレージやSDSの技術に依って異なることに注意が必要である.たとえばRAID5技術で構成されたストレージの場合にはハードディスクの同時故障は1個までしか許容できないため,複数ディスク故障とは「2個以上」を意味する.RAID6技術で構成されたストレージの場合にはハードディスクの同時故障は2個まで許容できるため,複数ディスク故障とは「3個以上」を意味する.SDSの場合も同様であり,ノード冗長性として2ノード間でのデータ複製を行っている場合には同時故障は1個までしか許容できないため,複数ディスク故障とは「2個以上」を意味する.3ノード間でのデータ複製を行っている場合ハードディスクの同時故障は2個まで許容できるため,複数ディスク故障とは「3個以上」を意味している.

またハードディスクの同時故障が問題になる範囲にも注意が必要である.ストレージ専用機器では同一のRAIDアレイ内におけるハードディスクの同時故障を指している.SDSの場合は異なるSDSノードのハードディスクが故障する場合を指している.一般的なSDSのデータ可用性実装を確認するために調査会社におけるSDSのレポート[7]で「Sample Vendors and Products」として取り上げられている16のSDS技術について,実装されているスナップショット方式を確認した.技術方式が確認できたのは16のうち10技術であり,その中で8つはCOWもしくはROWであり,残りはCOW with BCを実装していた.この結果からSDSの大部分(8割)のスナップショットは,故障などの障害に有効な保護対策になっていないと判断した.

表1の通り,SDSのデータ可用性/保護レベルは一部のストレージ(ROW, COW)と同等である.SDSを含めたこの3方式は網掛け部分(赤)の「ディスク(2個同時故障)」と「データ破損」においては,ストレージにおいて致命的な問題となる「完全データロスト」の発生が不可避である.これは前述のように上記理由による故障時は元データが利用不可能になるため,元データをデータ維持に利用する構造のスナップショット方式では,データを復元できなくなるためであり,構造上データロストの回避は不可能である.

表1 SDSデータ可用性/保護機能の構成要素障害影響分析による評価

3.可用性/保護充足と概念実証

SDSのデータ可用性/保護における課題を充足する3つの方法を提案する.1つ目は,SDS自体の複製機能(レプリケーション)を使う方法,2つ目はネットワーク経由ファイルバックアップ,3つ目はイメージバックアップである.これらの提案に実現性を確認するため実機での概念実証を行った.なお本章のみ具体的な製品・技術名を一部に記載するが,これは宣伝を意図した記載ではなく,読者がSDS導入に際して同様の検証を行う際に,比較する有用性に配慮した上での記載意図である.なお,各検証でサーバの仕様(CPU等)が異なるのは実機検証で利用したSDS技術の推奨するサーバ仕様に合わせるためでありデータ保護の検証結果には直接影響する差異ではない.

3.1 レプリケーションによるデータ保護

SDSクラスタ間でデータの複製を行うレプリケーション機能は一部のSDSで実装されている[7].別のSDSクラスタに複製を取得することでデータの保護を行う.常に完全な複製を取得するSynchronous(同期),非同期に反映するAsynchronous (非同期)に分類できる.図4において,Site A と Site Bが異なるロケーションに配置される場合には,サイト間の通信帯域が不足する可能性がある.特に同期ではSite BのSDSクラスタにデータ変更が反映されるまでSite Aの元データのI/O処理が完了しないため,パフォーマンス劣化が発生するリスクも存在する.また保護可能な対象は最新データに限定され,特定のデータの保護には利用できない.世代管理は対向クラスタにおいてスナップショットを使用するなど,複数方式を併用する必要がある[8],[9].

図4 左:SDS 右:ストレージ機器レプリケーション

3.1.1 実機検証結果と考察

実際のSDS技術としてSpectrum Scale(GPFS:General parallel File System)[10]環境でネットワーク非同期レプリケーションの検証を行った(図5).本検証ではWAN越しに遠隔地のSDSクラスタに対し複製を行う想定で,WANエミュレータによって遅延のある細い回線を再現している[11].検証結果からは,転送スレッド数が大きな影響を与えることが分かった.表2の通り,標準設定の4から8スレッドへの変更で転送性能が6倍弱と顕著な改善効果が確認できた.WAN環境ではネットワークの遅延によって待ち時間が増加するため,できるだけ多くの転送セッションを並行実行し,転送効率を向上することが効果的である.一部のSDSではファイル単位転送が実装されているため,動画のような大ファイル・オブジェクトでは並列転送は有効ではない.検証は,実利用環境とサイズを合わせたファイルを用意することを推奨する.

図5 Asynchronous レプリケーション検証環境
表2 Asynchronous レプリケーション検証結果

実機検証前に机上でサイジングと設計を実施する場合の考慮点は以下の3点である.1つ目は同期の場合データ更新量と同等程度の回線帯域を用意すること,2つ目は必要な実効転送帯域に対し回線の帯域および遅延の特性を踏まえ,必要な実効転送帯域の2倍程度のWAN回線準備を目安にすること,3つ目に一部のSDSは,レプリケーション時に変更ファイルを検知するため,スキャン時間や負荷を含めたサイジング上の配慮が必要となる.

3.2 ネットワーク経由複製データ保護

バックアップサーバからデータプレーン経由でファイルのデータ複製を取得する方法である(図6).大部分のSDSは主インタフェース,もしくは補助インタフェースとしてCIFS,NFSなどの汎用ファイル共有プロトコルを提供しているため,このファイル共有経路を利用して,ネットワーク経由でのファイルバックアップを実装可能である.

図6 SDSネットワーク経由バックアップ構造
3.2.1 実機検証結果と考察

実際のSDS製品としてSpectrum Scale(GPFS)[10]環境でネットワーク経由ファイル増分バックアップの実機検証を行った(図7).

図7 ネットワーク経由バックアップ検証環境

本検証では表3の通り2テープドライブ環境では秒間40MBの複製速度が確認できた.4テープドライブ環境では,SDSからのファイル読み込み性能がボトルネックになり性能向上結果は得られなかった.本方式でバックアップを取得する場合には,SDSからのファイル読み込み性能の確保が必須である.SDSデータプレーンのネットワーク共有プロトコルでのファイル読み込みが秒間40MB程度の場合は,2テープドライブ構成が適当である.それ以上の速度が必要な場合は,データプレーンのファイル読み取り性能を向上した上で,秒間20MBあたり1ドライブの目安でテープドライブを追加することが机上での概算サイジングの目安として妥当である.机上サイジングの注意点は3点で,1つ目はバックアップサーバとSDSデータプレーン間の通信帯域がボトルネックにならないように10Gb Ethernetなど十分な通信帯域を用意すること.2つ目は前回バックアップからの変更検知のため,スキャン時間を考慮することである.3つ目はファイルサイズで今回検証した環境では1ファイル750KBで検証を行ったが,平均ファイルサイズが本検証と大きく変わる場合は,性能上の考慮が必要である.筆者らの経験上では平均ファイルサイズが100KB以上の場合,本検証結果と大きな違いはないが,平均ファイルサイズが100KB以下の場合は本結果以下の性能になる可能性が高い.

表3 ネットワーク経由バックアップ検証結果

3.3 イメージバックアップデータ保護

SDSのデータプレーンを通して,スナップショット先のボリュームをrawデバイスとしてマッピングし,イメージデータとして複製を取得する方法である(図8). iSCSI, Fibre Channelなどのブロックデバイスのプロトコルを提供しているSDSで利用可能な方法となる.イメージバックアップはファイル単位のバックアップより複製速度が速い一方で,構造上,差分や増分での複製が難しく,フルバックアップで取得することが必要になる.イメージバックアップにおける大容量データの複製ではテープドライブを増やすことで,取得速度を高める必要がある.筆者の経験上,複製速度はLTO7 1テープドライブあたり秒間200MB程度が上限になる.したがって10TBのデータを9時間で複製するためには2テープドライブ並列複製が必要になる.数十ドライブ以上のテープドライブ並列はシステム実装上現実的とは言えないため,現実にはこの方法で100TB以上のバックアップは難しい.また複数ボリュームを束ねて単一仮想ストレージとして提供するSDSの場合は,ブロックレベルのデータ複製でSDSの構成情報と不整合を発生させないように,I/Oの一時保留や変更ブロックの追跡について考慮が必要である.製品・技術では構成情報を含めて格納データ出力する機能を実装している場合は,整合性はSDS側で確保されるので特別な考慮は不要である.

図8 SDSイメージバックアップ構造

3.3.1 実機検証結果と考察

実際のSDS技術としてXIV/Spectrum Accelerate環境[12],[13]で実機検証を行った(図9).結果は表4で,5テープドライブまで性能向上が確認でき,秒間1,200MBのバックアップが可能だった.ただし5ドライブの時点で性能向上率は若干鈍化しており,それ以上のドライブ追加は,顕著な性能向上結果は得られないと考えられる.またイメージバックアップではSDSデータプレーンからの高速ファイル読み込みが前提である.SDSデータプレーンからのファイル読み取り性能が秒間300MB程度の場合はLTO7 1ドライブが適切,それ以上の場合は1ドライブあたり秒間200~300MB程度の目安でドライブを追加するのが適切である.注意は3点で,1つ目はバックアップサーバとSDSデータプレーン間の通信がボトルネックにならないように,十分な通信帯域を用意すること.2つ目はバックアップサーバのリソースがボトルネックにならないように余裕を持ったサイジングを行うこと.3つ目はこの方法ではバックアップサーバは,SDSからの読み込みとテープ装置への書き込みの両方を同時に行う構造から転送速度の2倍の負荷がかかるため,物理サーバの追加(スケールアウト)を検討すべきことである.

図9 SDSイメージバックアップ検証環境
表4 イメージバックアップの実機検証結果

5.SDS可用性/保護充足と評価

第2章で用いた構成要素障害影響分析(CFIA)により, SDSデータ可用性/保護の充足手法の評価を行う.各評価基準は表1と同一である.前述の通りSDSの標準的なデータ可用性/保護機能には,特定の障害パターンで完全データロストが発生する欠点があった.前章はその欠点を補完する方法を提言したが,表5の通り,網掛け部分(赤)の SDSの課題であったディスク複数同時故障とデータ破損時の完全データロストが,各充足方法では解決している.この結果で各方法によるSDSデータ可用性/保護能力充足の有効性を示すことができた.

表5 SDSデータ可用性/保護充足手法の構成要素障害影響分析による評価

単純化した簡易な計算になるが,ハードディスクの平均故障間隔を100万時間,ハードディスク100本,2ノード間でのデータ複製で構成されたSDSを想定した場合 ハードディスク1本あたりの年間故障率は約0.9%, 年間100本中1本も故障しない確率は41.3%になる.年間100本中1本故障する確率は36.7%であり,合算すると年間故障1本以下である78.0%の確率では,SDSのデータ保護の範疇である.逆に言えば22%の確率で2本以上のハードディスク故障が発生するためSDSのデータ保護の範疇外になり,本稿が提示した追加のデータ保護対策が有効である.

ただし,この計算は故障したハードディスクが代替え,交換されない状態で1年間運用されるという想定下の計算である.実際の運用ではハードディスクの故障は放置されることはなく,故障が判明した時点で早急な代替え・交換作業を行うことが一般的であるため,1本目の故障ハードディスクで代替え・交換作業が完了するまでの間に2本目のハードディスクが故障する確率は,実際には22%より低い値になる.

SDSを含むストレージのデータ可用性/保護の実装検討は,システム設計に大きく影響を与えるため,SDS導入プロジェクトの早期に検討・決定すべき事項である.しかし現状ではSDSのデータ可用性/保護についての検討ノウハウやアセットが不足しているため,上流工程でシステム設計を担当するコンサルタントやアーキテクトがSDSに関する技術判断を行うのが非常に難しい.システム設計段階で間違った実装を選択した場合,その後の構築・導入の局面において,その修正に大きな負担がかかる.あるいは修正が行えないまま欠陥のあるシステムが完成してしまうリスクも高くなる.筆者は,コンサルタントやアーキテクトがシステム設計で適切なアーキテクチャ選択を行う上で,その手助けになるようにSDSデータ可用性/保護の選定基準についてアーキテクト,コンサルタントが参照するReference Architectureの一部としてArchitecture Decisionのアセットを作成した(表6).

表6 SDSデータ可用性/保護方法に関するアーキテクチャ決定アセット

SDSについて実装レベルまでの知識を得るのが困難なITアーキテクトにも利用可能になるように,可能な範疇で分かりやすいIT用語やロジックで記述しており,簡易的ではあるが判断基準の根拠にできることを心がけている.

6.まとめ

SDSは2017年現在,非常に注目を集めており,今後の成長が期待される技術分野である<第1章>.一方で,SDSのデータ可用性/保護技術については不足と考える人が多い.代表的なSDSのデータ可用性/保護技術は「ディスクおよびノード冗長性」と「スナップショット機能」だが,この方法には障害時の完全データロストの可能性が存在する<第2章>.「レプリケーションによるデータ保護」「ネットワーク経由複製によるデータ保護」「イメージバックアップによるデータ保護」は,SDSのデータ可用性/保護技術の欠点を充足する有効な方法であり,その実現性・有効性および実装上の性能基礎数値は実機による概念実証で確認できた<第3章>.これらの充足方法を適切に選択することによりSDSのデータ可用性/保護機能の不足を充足することが可能である<第4章>.

実務家としての業務経験を通じて,筆者らはSDSの障害時のデータ保護においては,ストレージ専用機器と比較して不足があるという気づきを得ていたが,本稿での考察を通して,それを裏付けることができた.クラウドなどIT基盤が大きなイノベーション時期に差し掛かっている2010年代において,ストレージにも「Software Defined Storage」という大きな可能性を有する技術転機が訪れている.SDSにおいてはデータ可用性・保護の課題と不安の克服が普及の分水嶺になると筆者らは考えている.ストレージ専用機器においては数十年のノウハウや設計アセットが整備されているのに対して,SDSでは製品や特定バージョン限定の不十分なガイドやFAQしか存在せず,設計指針となるドキュメントがないこと,また歴史の浅さから実績のあるデータ可用性・保護方法も整備されていないため,実導入では現場で設計のやり直しや実装のTrial and errorを繰り返さなくてはならないことが多く,納期や要件が厳しい基幹業務プロジェクトでの実装が困難なのが実情である.その経験から本稿は製品に特化せずSDSの導入検討で上流工程から利用可能で,実機検証結果も含めて手法を提案,立証した点において,過去のドキュメントに存在しなかった新規性と,実際の現場で利用できる有用性を重視した構成の解説論文になっている.読者の皆様が今後SDSを検討および設計,導入される際に,本稿が少しでもその手助けになれば幸いである.

参考文献
斎藤彰宏(正会員)saitoha@jp.ibm.com

1995年日本アイ・ビー・エム(株)入社.2017年現在システムズ・ハードウェア事業本部所属.クラウドマイスター上席エンジニア.

南 聖二(非会員)SAINT@jp.ibm.com

1989年日本アイ・ビー・エム(株)入社.2017年現在システムズ・ハードウェア事業本部所属.ストレージ・テクニカル・セールス.

岡野一恵(非会員)KOKANO@jp.ibm.com

1997年日本アイ・ビー・エム(株)入社.2017年現在システムズ・ハードウェア事業本部所属.Software Defined Infrastructureテクニカル・セールス.

倉前裕成(非会員)E35236@jp.ibm.com

2012年日本アイ・ビー・エム(株)入社.2017年現在システムズ・ハードウェア事業本部所属.システムズアーキテクト.

投稿受付:2017年8月30日
採録決定:2017年11月28日
編集担当:山川 聡(日本電気(株))