SB C&Sの最新技術情報 発信サイト

C&S ENGINEER VOICE

【NetApp】ONTAPの紹介 (FAS/AFF編)

ストレージ / HCI
2020.09.25

こんにちは。SB C&Sで仮想化製品のプリセールスエンジニアをしている笠原です。

企業のITインフラを支えるストレージには非常に多くの要件が求められることはこちらの記事でもご紹介させていただきましたが、NetAppが提供するデータ管理ソフトウエアである ONTAPにはその多くの要件に対応しうるアーキテクチャが備わっています。

データ管理ソフトウエア「ONTAP」

ONTAPはNetAppが創業当初(1992年)から提供しており、ストレージ専用に設計された軽量かつ高パフォーマンスでありながら、ストレージにおいて必要となる各種データ管理機能を搭載したOSです。

当然ながらソフトウエアなので、ハードウエアアプライアンスであるFASやAFF、ASAのみならず、仮想マシンとして動作(ONTAP Select)させたり、クラウド上で動作(Cloud Volumes ONTAP)させたりと、今やさまざまな環境で動作させることができるストレージアプライアンスとなります。

図33.png


本記事では、ハードウエアアプライアンスであるFAS/AFFについて、アーキテクチャを交えて紹介します。ONTAPによって多くのメリットがもたらされることをご理解いただき、ストレージ導入においてぜひFAS/AFFやその他ONTAP製品をご検討いただけると幸いです。

FAS/AFFの特長を整理すると、次のようなことが挙げられます。 

それでは、これらFAS/AFFの特長がどのようなアーキテクチャによって実現されているのかについて順番に紹介します。

高速なデータアクセスを実現

ストレージに求められる要件の中でも重要である「高速性」を、FAS/AFFでは独自の書き込みアーキテクチャやフラッシュデバイスの活用によって実現しています。

独自の書き込みアーキテクチャ

一般的なストレージにおいて、コントローラーから直接ストレージデバイスへデータを書き込む場合、そのストレージデバイスの性能に影響され、データの保存完了までに時間がかかってしまいます。しかしFAS/AFFであればディスクへデータを書き込む前にコントローラー内のNVRAM(※)へデータが書き込まれた時点で書き込み完了の応答を返すので、高速にデータの保存を完了することができます。

(※)内蔵バッテリーにより電源が落ちてもデータロストしない(不揮発性の)高速なフラッシュデバイス

また、HDDを活用したストレージにおいてはデータを書き込む際のHDD内の磁気ヘッドの移動がI/O性能に大きな影響を及ぼしますが、FASであればWAFL(Write Anywhere File Layout)というファイルシステムによって、データをHDDの連続した領域に書き込むため、磁気ヘッドの移動を抑え、高速なI/Oを実現しています。

図34.png

Flash Cache

データをHDDに保管するFASにおいてはコントローラー内のNVMeデバイスを読み取りキャッシュとして使用するFlash Cacheという技術を活用することで高速なデータアクセスを実現しています。なお、データが高速なSSDに保管されるAFFにおいてはFlash Cacheは搭載されていません。

図4.png

Flash Pool

また、SSDとHDDを組み合わせたハイブリッド構成のFASにおいては、SSDを読み取りと上書きにおけるホットデータのキャッシュとして使用するFlash Poolによって、さらに高速なデータアクセスが実現できます。

図5.png

耐障害性に優れた堅牢なアーキテクチャを実装

FAS/AFFではHAペアによるコントローラーの冗長化や、独自のRAIDにより、パフォーマンスを犠牲にせずデータの堅牢性を実現しています。

HAペア

FAS/AFFでは、HAペアと呼ばれる2つのコントローラーによって障害時にも稼働し続けられる仕組みが備わっています。通常時、コントローラーはアクティブ-アクティブ(各コントローラでONTAPが稼働)であり、コントローラー障害時には、もう片方のコントローラーへONTAPが移動(1つのコントローラ上でONTAPが2つ稼働)することで、継続的なデータへのアクセスを実現します。

図6.png

HAペアを構成することによって、コントローラーがクライアントに書き込み完了のサインを返す前に、データはHAペアのもう片方のコントローラーのNVRAMにも書き込まれます。この仕組みにより、どのタイミングで単一障害が起こってもデータロストしない堅牢な書き込みを実現しています。

図3.png

独自RAID

FAS/AFFは、RAID4のようなパリティディスク固定方式のRAIDであるRAID DP(パリティ数:2)やRAID TEC(パリティ数:3)を採用しています。

通常、パリティディスク固定方式のRAIDは、データ保護の観点からは堅牢である反面、書き込み時のパフォーマンスが犠牲となります。下図のように、RAID4ではデータが更新されるたびに、そのストライプ内のパリティが再計算されるためにパリティディスクに負荷が集中してしまい、ボトルネックとなります。

しかし、WAFLを組み合わせることにより、システムメモリでデータが整理された後、個々のブロックを変更するのではなくストライプ(データとパリティのセット)単位でディスクアレイへデータを書き込むので、更新されるブロックが点在することによるパリティ再計算が不要となり、パリティディスクに負荷が集中することもありません。

図7.png

説明の都合上、パリティディスクが1本の場合でご説明しましたが、FAS/AFFでは独自のパリティ計算ロジック(対角パリティ)によるパリティディスクを2本としたRAID-DPをデフォルトで採用し、2重障害に耐えられるアーキテクチャとなっております。さらに、3重障害への対応が必要な場合にはパリティディスク3本とするRAID-TECも選択することができます。

図32.png

このように、FAS/AFFであればパフォーマンスを犠牲にすることなく、堅牢性の高いRAIDを実現しております。

サービスを止めずに構成変更やメンテナンス・リプレースが可能

ストレージを導入する時から将来必要となる容量や性能を正確に見積もることは難しく、後から拡張する際にサービスを止めなければならず拡張を見送る、もしくは別ストレージを導入するといったお話しを伺うことがあります。しかし、初期導入時に将来利用する容量をすべて含めて導入するには非常に多くのコストがかかります。

FAS/AFFであれば、ONTAPによって「ハードウエアコンポーネントを全てソフトウエアによって抽象化すること」や、「複数のHAペアをひとつのストレージシステム(クラスタ)として動作させること」によって容量や性能を後からでもオンラインで変更できます。また、これらの機能や技術を使うことで、無停止のメンテナンスやリプレースも実現可能となっております。

抽象化・クラスタ

下図はFAS/AFFの1つの物理コントローラー内で、コントローラー自身やNIC、ストレージデバイスが抽象化されている様子を表しています。一般的なストレージ製品のようにクライアントへ物理コントローラーをそのまま見せるのではなく、物理コントローラー内で抽象化されたコントローラーであるSVM(Storage Virtual Machine)を見せることで、1つの物理コントローラー内で用途ごとに複数のストレージシステム(例えば、仮想基盤用の共有ストレージとファイルサーバーなど)を作成することができます。

また、物理NICにおいても抽象化されたネットワークインターフェースであるLIF(Logical Interface)を活用します。LIFは物理NICに関連付けられますが、1つの物理NICに対して複数のLIFを割り当てることもでき、IPアドレスを変えずに別の物理NICへ移動させるといったことも可能です。

物理ストレージデバイスについても個々のディスクに直接書き込むのではなく、RAIDが組まれ、複数のRAIDグループをまとめてAggregateという大きなプールにし、そのAggregateからクライアントに提供する領域であるFlexVolumeを切り出すといった構造で抽象化されています。

図9.png

また、このコントローラーを24ノード(12HAペア)まで1つのストレージシステム(クラスタ)として動作させることができます。これにより、例えばユーザーによってファイルサーバーの接続先をHAペアをまたいだクラスタ内の全ての物理コントローラーへ分散することで、大規模な環境に対応でき、管理は1つのシステム(クラスタ)として行うといったことが可能になります。

図10.png

無停止容量変更

物理要素が抽象化されていることによって、HDDやSSDを追加してRAIDを拡張することや、新規RAIDを追加して論理的なストレージプールであるAggregateを拡張することができます。また、クライアントへ提供する領域であるFlexVolumeはいつでも自由に容量の拡張や縮小ができますので、空き容量不足などで導入後に容量の追加が必要になってもクライアントへのサービス提供を止める必要はありません。多く割り当てすぎたFlexVolから他のFlexVolへ容量を割り当てることもできるので、保有リソースを無駄にすることなく有効活用することができます。

図29.png

また、クラスタにコントローラーをオンラインで追加可能なので、容量の拡張とともにパフォーマンスも拡張可能です。

無停止メンテナンス

前述したように、HAペアを構成することで、コントローラー障害時は1つの物理コントローラー上で2つのONTAPを稼働することが可能となります。このONTAPがもう片側の物理コントローラーに移動することを利用し、メンテナンス時にも片側ずつコントローラーをアップデートしていくことができます。

図12.png

無停止リプレース

無停止容量変更の項でクラスタ化することによってオンラインでコントローラーを追加することが可能であることをお伝えしましたが、同様にコントローラーを抜去することも可能です。これにより、既存HAペアに新たにコントローラー(HAペア)とストレージデバイスを追加し、抽象化されたリソース(SVMやデータLIF、FlexVol)を新しく追加したHAペア側にサービスを止めることなく移行できます。つまり、無停止でのリプレースが可能です。

図13.png

優れたデータ保護機能を実装

FAS/AFFにはRAID-DP、RAID-TECといった物理ストレージデバイス障害に備えたアーキテクチャが備わっていることに加え、データを誤って削除してしまったなどのオペレーションミスやサイト障害(システム全損)によるデータ損失に備えた様々なデータ保護の仕組みが備わっています。

それらのデータ保護を実現している仕組みをご説明する前に、WAFLのデータ保持方法について紹介します。

WAFLによって書き込まれるデータには大きく分けて実データと、実データのブロックの位置情報となるメタデータの2種類が存在しています。実データは上書きされることがなく、ボリューム内のデータを更新する際には変更された実データが新規ブロックに書き込まれ、メタデータが保有するブロックの位置情報を更新します。変更元の実データのブロックは後で消去されます。

図14.png

筐体内のデータ保護

ONTAPには、筐体内に「対象データにおける特定時点の状態を保持する機能」としてSnapshotがあります。当然、他社製ストレージにおいてもスナップショット機能を有しているものは多く存在しますが、ONTAPのSnapshotは一瞬かつ容量を消費することなく、さらにパフォーマンスに影響を与えることなく取得できます。

先ほど紹介した通常のWAFLの動きとしては変更されたブロックは消去されますが、Snapshotを取得した場合、取得する時点でのメタデータをSnapshotとして保持し、そのメタデータがポイントするブロックを消去しないようにします。Snapshot取得後も本体ボリュームの挙動は変わらず、変更されたデータは新規ブロックに書き込まれ、メタデータの情報が更新されます。

この仕組みから、小さなメタデータの情報をコピーするだけなので一瞬で取得でき、実データをコピーするわけではないので容量も消費せず、本体ボリュームの挙動(読み取り、書き込み)は変わらないのでパフォーマンスに影響がないことをお分かりいただけると思います。

図15.png

筐体内のデータ復旧

保持しているデータは、ファイルサーバーとして利用した場合には、Windowsクライアントで"以前のバージョン機能"を使ってユーザー自身がSnapshotボリュームからファイルをコピーし、復元することができます。

図16.png

ただし、この復元方法は実データをコピーしているので時間がかかり、(重複排除をしていない場合は)容量も消費してしまいます。ONTAPに搭載されているSnapRestoreと呼ばれるポインタ情報を変更する(元に戻す)機能を使用することで、瞬時にかつ容量を消費せずにボリュームやファイルをSnapshotを取得した時点の状態に復元することが可能です。

図17.png

筐体間のデータ保護

拠点間のデータ保護を想定する場合であれば、筐体内に留まらず筐体外でデータを保管する必要がありますが、ONTAPであれば、ボリュームをLANやWANを経由して筐体間でレプリケーションを行うことが可能です。先ほどご紹介したSnapshotを応用したSnapMirrorという機能が使われます。

SnapMirrorでは、初回はSnapshotの全データをレプリケーションしますが、2回目以降は前回のSnapshotと比較して変更されたブロックのみを転送することでデータ転送量を減らし、高速なレプリケーションが可能です。

図18.png

送信側のボリュームが損失し、SnapMirrorで遠隔地に保存したボリュームの状態にリストアしたい場合は、送信側の管理コンソールであるONTAP System Managerから受信側にあるリストアしたい時点のスナップショットを指定し、リストアを実行することができます。災害などにより送信側であるメインサイトのクラスタが損失した場合には、受信側のボリュームから復旧したクラスタへ再度SnapMirrorを行い、元の状態へとリストアすることができます。

複数のストレージプロトコルに対応

これまでストレージは用途ごとに導入されることが多く、サイロ化してしまっているお客様も多いと思います。FAS/AFFであれば、様々なストレージプロトコルに対応しているため、異なる要件のストレージを統合することが可能です。これによって、ストレージのサイロ化を防ぎ、容量や性能の有効活用が可能です。

例えば、仮想デスクトップ環境では、仮想マシンデータを格納するデータストアと、ユーザープロファイルを格納するファイルサーバーが必要となります。FAS/AFFであれば、NFSでデータストア、CIFSでファイルサーバーを提供することが可能なので、複数のストレージが必要になるといったこともありません。他にも、クラスタ用途などでブロックアクセスによる共有ストレージが必要なアプリケーションサーバーがあれば、これもiSCSIやFCで接続することで、FAS/AFFに統合できます。

図19.png

圧縮や重複排除機能によりデータを効率的に保存

ストレージにデータを保存する際、当然ディスクの容量までしか保存できません。そのため、ONTAPにはディスクへのデータの保存を効率よく行うための機能として、圧縮、重複排除、インラインデータコンパクションが備わっています。

圧縮

ONTAPでは、書き込まれるデータまたはストレージ内部に存在する異なるブロックデータを纏めて圧縮する機能が無償で搭載されています。

ONTAPの圧縮機能は、コンプレッショングループ(設定により8KBか32KBを指定)という小さなグループ単位で圧縮することで、圧縮をするためにコントローラーへかかる負荷を減らしています。データ全体を圧縮してしまうとデータの一部を解凍したい場合にもデータ全体を一度解凍しなければなりませんが、小さなグループごとに圧縮することで、必要なグループだけを解凍することができるという利点もあります。

また、8Kまたは32Kの固定長とすることでファイルサイズを考慮する必要がなく、圧縮時の計算ロジックをシンプルにしています。さらに、グループ内の圧縮率が25%未満と判断された場合は圧縮を行わないことで処理を減らしています。

図20.png

重複排除

ONTAPには同じデータ内容の4Kバイトのブロックがストレージ内部に複数存在する時、1つ残して他を削除する重複排除機能が無償で搭載されています。こちらはデータ圧縮と併用可能です。FASの重複排除はボリューム内で重複するブロックを削除しますが、AFFでは、アグリゲート単位で重複排除することができるので、さらに効率の良いデータ量の削減を実現できます。

図21.png

インラインデータコンパクション

ONTAPではデータを4Kのブロックごとに保存していますが、これは実際のデータの量がごくわずかであってもデータを保存する際ディスク内の4K分消費されてしまうということを意味します。インラインデータコンパクションを利用すると、その僅かなデータを1つのブロックにまとめることができ、データの効率化を図ることができます。こちらも無償で利用することができます。

図22.png

サポートサイトへのログの転送やAIを活用した監視

ONTAPには障害、容量、性能を監視する機能が備わっています。

EMS(Event Management System)

各コントローラーが出力するイベントログは各ONTAP内に保存されています。そのことによって、クラスタ全体のONTAPを管理できるWEBコンソールであるONTAP System ManagerやCLIからストレージシステムの状態を確認することができます。

図23.png

Auto Support

こちらは障害などの任意の監視イベントの情報(EMSの情報含む)をシステム管理者やNetAppや保守ベンダーに自動で通知することができる機能です。Auto Supportにはトラブルの際に調査のため保守ベンダーから依頼されるような情報(ステータスやログなど。詳細はこちらのリンクでご確認いただけます。)が含まれているので、監視においてシステム管理者の負荷が軽減され、保守ベンダーとのやり取りを円滑に行うことができます。

図24.png

Active IQ

こちらはクラウド型のサービスとなりますが、Auto SupportによってNetAppへ送信された情報を元にAIが分析し、リソースの逼迫や障害を事前に予測することができます。こちらの情報はWEBアプリケーションとしてブラウザやスマートフォンのアプリケーションから参照することができます。また、この機能はソフトウエアのアップグレード情報などを自動で管理者に通知することができます。

図25.png

ストレージの場所や機器に依存しないデータ活用を実現

今ではクラウドの利活用は当たり前となり、データをクラウドで利用することが多くなってきていますが、すべてのデータがクラウドだけで利用・生成されているわけではなく、アクセス速度やセキュリティの観点からもまだまだオンプレミスで利用・生成されるデータも多く存在します。NetApp社は、「Data Fabric」というビジョンを掲げ、場所や保管形態に依存せず用途に応じてデータを活用や移動、保存できるプラットフォームを実現しております。このビジョンはFAS/AFFにおいてももちろん反映されていますので、そのうちいくつかを紹介させていただきます。

SnapMirror

先ほど紹介したSnapMirrorは、FAS/AFF以外にも、ONTAPを搭載した仮想アプライアンスであるONTAP selectやクラウド上のインスタンスであるCloud Volumes ONTAP、さらにブロックストレージとなるElement OSを搭載したSolid FireやNetApp HCIにも対応しています。これにより、設置場所や機器に依存しないデータの利活用やバックアップ、DR、アーカイブを実現できます。

また、最近ではコストやセキュリティの課題からデータをクラウドからオンプレミスに戻したいというご要件をお聞きすることがあります。このような場合においても、同じONTAPによって管理されているデータであればSnapMirrorによって容易に戻すことが可能です。

図26.png

FabricPool

他にも、AFFにはFabricPoolという「特定のポリシーに従ってデータをオンプレミスに設置したAFFとパブリッククラウドなどのオブジェクトストレージで保存領域を階層化する機能」があります。例えば、アクセス頻度の高いデータをAFF内のフラッシュデバイスへ保存し、アクセス頻度の低いデータをパブリッククラウドへ移動することによって、AFFを最適なコスト(容量単価)でご利用いただけます。

図27.png

図28.png

※FabricPoolの詳細については以下の記事をご参考ください。

オブジェクトストレージとの自動階層化を実現する『FabricPool』
https://licensecounter.jp/engineer-voice/blog/articles/20200408_fabricpool.html


如何でしたでしょうか。

今回はFAS/AFFのメリットをアーキテクチャや機能の解説を交えて紹介させていただきました。

ONTAPを導入することによって「管理を統合してサイロ化を防ぎつつ、ご要件に応じてデータを自由に配置することができるデータプラットフォームを実現する」ことができます。

デジタルトランスフォーメーションが求められる昨今、如何に「データ」を利活用できるか(しやすいか)が重要となります。今直面している様々なストレージの課題を解決しつつ、将来的な「データ戦略」までをカバレッジできるFAS/AFFをぜひご検討ください。

FAS/AFFをはじめとしたONTAPには非常に多くの特長があり、まだまだ紹介しきれない部分はありますが、NetApp製品の良さが少しでも伝われば幸いです。これからも個々の詳しい技術や機能、構成方法や設定方法についてご紹介していければと思います。

関連記事はこちら

著者紹介

SB C&S株式会社
ICT事業本部 ICT事業戦略・技術本部 技術統括部 第3技術部 2課
笠原 規裕

2018年入社。
西日本エリアにて仮想化製品のプリセールスエンジニアに従事。
最近では仮想基盤のストレージに焦点を当てた検証を粛々と実施。