NetApp Tech OnTap NetApp Logo
NetApp Tech OnTap
     
【OpenStackとNetAppストレージ】
第2回:
OpenStackとAWS/Azure連携
~ Manilaを使ったデータレプリケーション ~  (2017/01/20)
シェアするNetAppオフィシャルFacebook   ツイート

はじめに

クラウド利用の現実解はハイブリッドクラウドである、 という認識は広まりつつあります。しかし現実的にはオンプレの OpenStack 環境とパブリッククラウドを連携させるソリューションはあまり見当たりません。クラウドを一時的に利用する、 もしくは災害対策用サイトとして利用するにはデータが必要です。しかし、 データの連携方法はいまだにファイル単位のコピー、 もしくはハードディスクのデータセンターへの持ち込みが主流となっています。

OpenStack Manilaはこの1年で大幅に進歩したプロジェクトでした。単なるファイル共有やスナップショット作成、テナント間のアクセス分離だけでなく、リモート拠点へのデータ複製や AZ(Availability Zone) を跨いだDRにも対応しました。オフラインであれば異機種ストレージ間でデータ移行ができるようになり、Ocata リリースではオンラインでのストレージ筐体間データ移行の機能も提案されています。これらの操作は OpenStack の API/CLI から操作が可能で、メーカーや機種固有のAPIを意識する必要はありません。

このような Manila の機能強化により、パブリッククラウドとのデータ連携ができるようになりました。今回はこのデータ連携を具体的にイメージしていただくために、OpenStackとAWS/Azure の連携方法を紹介します。

クラウド(プライベート or パブリック)におけるファイル共有の課題

OpenStack に限らず、 メジャーなパブリッククラウドにおいてもファイル共有サービスは当初実装されていませんでした。自社のアプリケーションやミドルウェアがファイル共有を利用している場合、 この機能の欠落はクラウドへの移行を妨げる要因となります。仮想サーバを立てて自力でファイルサーバに仕立て上げることも可能ですが、 可用性や運用面について課題が残ります。しかし、 ここ数年でようやくサービスが提供されるようになりました。

  OpenStack Manila
    2014年頃から開発が本格化。Libertyリリース(2015年)でファイル共有に関する基本機能が揃う
    2016年のNewtonリリースよりRedHat社によるサポート提供開始。(RHOSP10以降で対応)
  AWS EFS
    2015年にEFS(Elastic File Storage)を発表 (ベータ提供)
    2016年6月に正式リリース (ただし日本リージョンは未対応)
  Azure File Storage
    2014年5月にAzure Files(もしくはAzure File Service) という名称でPreview公開
    2015年10月にAzure File Storageとして一般提供開始を発表

留意点として、 各社それぞれファイル共有サービスのコンセプトが異なるということです。一般的なエンタープライズ用途のためにつくられているわけではなく、 クラウドネイティブなシステム向けに作られていることもあり、 クラウド移行計画を立てる際に既存のファイルサーバと比較して制約を把握しなければなりません。容量上限はどれくらいか、 性能上限が十分か、 SnapshotやVSSで論理バックアップの世代を持てるか、 NFS3.0が使えるか、 など既存の自社アプリケーションをそのまま利用できるかの確認が重要となります。もちろん、 クラウド化のために既存の自社開発アプリケーションやミドルウェア等を作り替えるだけの体力と資金力のある会社であれば気にする必要はありませんが、 そのような会社ばかりではないでしょう。

ネットアップのアプローチ

ネットアップは「データ・ファブリック」という構想をもとに、 クラウドと連携する製品を開発してきました。OpenStack環境でもパブリッククラウドでもONTAPを動作させることで、 オンプレと変わらないファイル共有機能をクラウド環境に提供し、 お客様の悩みを減らすというアプローチをとっています。

(1) OpenStackへのアプローチ

ネットアップはManilaプロジェクトをリードし、 コミュニティに貢献してきました。当時の社内事情もあってManila開発はかなりの部分をMirantis社に委託して進めたのですが、 以下のグラフにあるようにManilaの機能(blueprints)の半分以上はこの2社で作られています。

補足:Manila新機能の実装数(completed blueprints) 2016年12月末時点の総数

http://stackalytics.com/?release=all&module=manila-group&metric=bpc

自社ストレージ用のManilaドライバーを書くだけの企業が多い中で、ネットアップは新機能の開発を積極的に続けてきました。また、ユーザ向けに技術レポートも公開しています。

補足:OpenStackに関連する技術レポート

Manila and Sahara Integration in OpenStack Using NetApp NFS Data in Hadoop and Spark
https://www.netapp.com/us/media/tr-4464.pdf

Business-Critical Applications Built on OpenStack Using Manila on NetApp Storage Systems
http://www.netapp.com/us/media/tr-4410-deploy.pdf (※SUSE, SAP, NetAppの共著)

(2) パブリッククラウドへのアプローチ
このようなOpenStack対応と並行して、 AWS/Azure向けにはONTAP Cloudを開発し、 MarketplaceなどWebから購入できるようにしました。

ONTAP Cloud

    ・CIFS/NFS/iSCSIプロトコル対応
    ・重複排除、 圧縮機能のサポート
    ・Snapshot, SnapRestore, FlexClone, などのデータ保護・複製テクノロジー
    ・SnapMirrorによるブロック差分のデータ保護/複製
    ・EBSの自動追加・削除機能(AWSのみ:使用量に応じたEBSの容量節約機能)

ONTAP がクラウド上のインスタンスとして動作するので、現在利用しているファイルサーバの機能をそのままクラウドで利用でき、操作性・運用性もほとんど変わりません。いくつかの機能(改ざん防止の SnapLock や ONTAP9.1 の新機能の NetApp Volume Encryption など)は使えませんが、冗長性を担保して豊富なデータ保護機能が利用できます。

補足①:
AZ を跨いだ HA 構成をとれば、データロス無しの切り替えが可能です。しかしサーバリソースとデータ量が 2 倍になるのでクラウドではコストに直結してしまいます。そのためシングル構成にして、非同期ミラー(SnapMirror 機能)の送り先をオンプレの FAS シリーズにすることでコストを削減できます。ちなみに ONTAP9.0 からはホワイトボックスサーバ上で動作する ONTAP Select がリリースされたため、ハードウェア資産を持たずに利用できます。

補足②:
ONTAP Cloudに特化したブログもあるので、 是非ご覧ください。
  ブログ:ONTAP Cloudの活用シーンと有用性
    http://www.netapp.com/jp/communities/tech-ontap/jp-tot-201612-ontap9.aspx
また、この ONTAP Cloud 用に新しい OnCommand 製品が登場しました。 OnCommand CloudManager を使うと ONTAP クラウドとオンプレミスの FAS を統一管理できます。以下のデモ動画はオンプレミスのデータを AWS に複製し、さらに Azure にカスケードでデータ複製するまでの操作を紹介しています。コマンド操作もなく、短い動画なので是非ご覧ください。

以下のデモ動画はオンプレミスのデータをAWSに複製し、 さらにAzureにカスケードでデータ複製するまでの操作を紹介しています。コマンド操作もなく、 短い動画なので是非ご覧ください。
  YouTube:Managing data across a hybrid and multi-cloud using ONTAP
    https://www.youtube.com/watch?v=qedaLhUtuYU

  ※ 最新の関連動画はNetApp TechComm TVに掲載されます。
https://www.youtube.com/user/NetAppTechCommTV/search?query=ONTAP+Cloud

AWSとオンプレのファイル共有をManilaでシームレスに連携

ここまではクラウド環境におけるネットアップのファイル共有への取り組みについて説明しました。使い慣れたONTAPをオンプレ仮想環境でもパブリッククラウドでも選択できるようになり、 AWS <-> Azure間のデータ連携も簡単なことが理解いただけたかと思います。

次にManilaとONTAP Cloudの連携について紹介します。

前回のブログ「第1回:NetAppストレージのOpenStack対応状況」でも記載しましたが、 ManilaのバックエンドストレージにNetAppの物理ストレージを使うと、 ManilaによってONTAPをAPI制御することができます。(以下の水色の部分)


※クリックすると拡大します。

まずmanila createとmanila access-allowによりテナントA用にボリュームが切り出され、 アクセス許可 / 拒否の設定ができます。これによりテナントAの複数の仮想サーバ間でCIFS/NFSのファイル共有が可能となります。

次にManilaのレプリケーション機能を使って左下のクラウドにデータ転送します。重要なことは、 AWS上のONTAP CloudはオンプレミスのManilaのバックエンドとして動作するということです。Manilaには2つのAvailability Zone(PrimaryとAWS)が定義されており、 この2つのManilaバックエンドに対してmanila share-replica-createでレプリケーションの関係性を作成することでブロック差分転送によるデータの同期が行われます。重複排除や圧縮の効いているデータは、 その状態を維持したまま複製します。もちろんスナップショットによる論理バックアップも維持されて転送されます。


※クリックすると拡大します。

最後にmanila share-replica-promoteを行います。これによりManilaのバックエンドであるFASストレージは未転送の残りのデータを同期したのちにミラー関係を切断し、 AWS上のONTAP Cloud側をプライマリのファイル共有として利用できるようになります。そしてAWS上でのデータ利用が終了すれば、 データを逆向きに同期してオンプレミスのManilaストレージに戻すことができます。(もちろんこの逆同期もブロック単位の差分転送になります。)

もう少し詳しい操作や挙動を知りたい方は、 以下の情報が参考になります。
  YouTube:NetApp Data Fabric with OpenStack Manila!
    https://www.youtube.com/watch?v=oHrtoH7ge7Q

Manilaのレプリケーション実装を知りたい方は以下もご覧ください。
  Mitakaリリースのレプリケーションデザイン(簡易的な絵があり、 わかりやすい)
    https://wiki.openstack.org/wiki/Manila/design/manila-mitaka-data-replication
  最新のOpenStack管理者ガイド(Replication関連)
    http://docs.openstack.org/admin-guide/shared-file-systems-share-replication.html

ユースケース

NAS上のデータが様々な場所に移動できるようになると無限大の可能性が広がります。いくつか利用例を挙げますが、皆さんもどのような使い方があるか考えてみてください。

【DR用途】
・オンプレミスのファイルサーバをONTAP Cloudにレプリケーション
    → 転送後にONTAP Cloudのインスタンスを停止
・ONTAP Cloud上のデータをオンプレミスのホワイトボックスサーバに転送
    → ホワイトボックスサーバ上ではONTAP Selectが稼働し、 Manilaの制御下に入っている
【計算処理のクラウドオフロード】
・オンプレミスの計算リソースで処理しきれないデータをAWSに転送
    → 計算結果をManilaのReplication機能で逆同期
【クラウド間のデータ移動】
・AWSとAzure上のNASデータを、 Manilaを使って相互にレプリケーション
    → クラウド固有のAPIや、 ストレージベンダー固有のAPIも使うことなくデータ連携

まとめ/次回予告

ユーザ企業はIT戦略を立てる上で、 選択肢を多く持つ必要があります。製品の不具合、 サービス品質の低下、 サポートの質の低下、 いずれもビジネスに影響を与えます。ベンダーロックインやクラウドロックインを嫌う理由の一つはそこにあるのではないでしょうか。ロックインされてITのコントロールを失ってしまった企業は、 競争力のあるIT戦略を立てることは難しいでしょう。

ネットアップは「データ・ファブリック」というスローガンを掲げて、データの管理を売る会社に変革しつつあります。10年後のネットアップはストレージを販売していないかもしれません。今回の記事でNetAppの変化の一部を感じていただけることを期待しています。
次回こそCinder Replicationを書きたいと考えていますが、 日々の案件対応に追われてなかなか進捗がありません。OpenStack案件がある方は是非弊社営業までご連絡ください。優先して検証したいと思います。

FAQ

Q1.
OpenStackコントローラ(Manilaコンポーネント)がプライマリサイトのManila用ストレージと同じ場所にあり、 同時にダウンした場合、 どうなりますか。
A1.
ONTAP CloudはFASストレージと同様にCLIでアクセスできるので、 手動で強制的にPromoteすることができます。しかしイレギュラーな操作になるため、 OpenStackコントローラを別サイトに準備することで切り替えが簡単になります。ベンダー固有のManilaドライバーを利用した場合、 データのレプリケーションはバックエンドストレージの機能によって実現するため、 Manilaはストレージ制御用の通信をするための細い回線があれば十分です。 異なるメーカーのストレージ間でデータ移行するためのManila DataCopy Serviceを利用する場合は、 このDataCopy Serviceは2つのストレージをマウントしてコピーを行うため、 このコンポーネントだけをストレージ筐体の存在する拠点に配置することをお奨めします。

Q2.
切り替え先のONTAP Cloudに対して、 Manilaからファイル共有の設定をすることは可能ですか。
A2.
可能です。Manilaは物理ストレージとONTAP Cloudを区別しません。

Q3.
Manilaには2つのモードがありますが、レプリケーションは両方に対応していますか?
A3.
以前Single SVMと呼ばれていた、Manilaドライバーがファイル共有サーバを管理しないモードに対応しています(現在のマニュアルではno share serversモードと呼ばれているが、現行の呼び方はわかりにくいので注意)。Single SVMは、手動でストレージ上にファイル共有サーバを作成し、ドライバーがファイル共有サーバを作成・削除しません。そしてこの単一のファイル共有サーバを全テナントで共有します。(アクセス制限の設定はテナント単位)

Multi SVMと呼ばれていたshare serversモードは、ドライバーが動的にファイル共有サーバを作成し、テナントのネットワークと同セグ通信するモードです。このレプリケーション対応はまだ先になります。

    https://blueprints.launchpad.net/manila/+spec/share-replication-enhancements-for-dhss
    https://blueprints.launchpad.net/manila/+spec/share-network-multiple-subnets

補足: 
2つのモードの違いについて
    http://docs.openstack.org/admin-guide/shared-file-systems-crud-share.html
    http://docs.openstack.org/admin-guide/shared-file-systems-share-types.html
share servers
    ・Manilaドライバーがファイル共有サーバをhandleする
    ・manila.confでdriver_handles_share_servers = True の設定をする
    ・OpenStackのテナントごとに仮想ファイルサーバが生成される
      (NetAppの場合、 StorageVMが自動生成される)
    ・VLANに対応し、テナントネットワークと同セグ通信加納。(VxLANは非対応)
    ・ファイル共有用のshare_network(テナント専用ネットワーク)をneutronコマンドで作成後、
      manila createで仮想ファイルサーバを作成
no share servers
    ・Manilaドライバーは事前に手動で作成されたファイル共有サーバを利用する
    ・extra_specでdriver_handles_share_servers = False の設定をする
    ・単一のファイル共有サーバをすべてのOpenStackのテナントで共有する
      (NetAppの場合、 StorageVMやLIFなどを手動作成後、 これをManilaの管理下にする)
    ・全テナントは同じIPをめがけて通信する
    ・アクセス制限の設定でテナント間の通信制限をする

井谷 寛(いたに かん)
ネットアップ株式会社
システム技術本部 コンサルティングSE部
コンサルティング システムズ エンジニア

SIerでインフラ全般を学び、 その後はメーカーとSIerを交互に経験。前職ではOpenStackの実装やAWSのシステム運用・構築をしたのちに、 2014年にネットアップに入社。その後はオブジェクトストレージ、 SolidFireなど新しい技術を中心に提案活動を行う。

関連情報

関連情報
【OpenStackとNetAppストレージ】


第1回:
NetAppストレージのOpenStack対応状況
~ OpenStackコンポーネント別の機種選定 ~
第2回:
OpenStackとAWS/Azure連携
~ Manilaを使ったデータレプリケーション ~
第X回
OpenStack Cinderで困ること
~ Cinderの機能不足やストレージ設計上の考慮点 ~
  • 掲載予定

第X回:
NetApp FAS/AFFとCinder & Glance
~ FC/iSCSIではなくNFS構成にするメリット ~
  • 掲載予定

第X回:
SDS+WhiteBoxよりも安価で高速なE/EF-Series
~ スケールアウトはOpenStackにお任せ! ~
  • 掲載予定

第X回:
All Flash Arrayよりも高速で安価なHDDストレージ
  • 掲載予定

第X回:
発想の転換で生まれたクラウド時代のストレージ
~ 設計不要なストレージ、 SolidFire ~
  • 掲載予定

第X回:
CinderのVolume Replicationを触ってみる
~ SolidFireの非同期ミラー構成 ~
  • 掲載予定

第X回:
Newtonで実現されたCinder機能
  • 掲載予定

関連情報
Go further, faster TRUSTe
お問い合わせ   |   購入方法   |   フィードバック   |   採用情報  |   登録   |   プライバシーポリシー   |   © 2017 NetApp