NetApp Tech OnTap NetApp Logo
NetApp Tech OnTap
     
【OpenStackとNetAppストレージ】
第1回:
NetAppストレージのOpenStack対応状況
~ OpenStackコンポーネント別の機種選定 ~
シェアするNetAppオフィシャルFacebook   ツイート

はじめに

近年、一般企業への普及が始まったOpenStackですが、専任のエンジニアを置けない企業にはまだ敷居が高いのが現状です。このシリーズでは、これから勉強を始める方やネットの情報では難しすぎると感じている方向けにわかりやすくOpenStackをお伝えしたいと考えています。そしてクラウドを作る側の人には製品選定の手間を省けるよう、Cinder / Manilaの検証レポートや設計上の注意、Blueprint上の新機能なども紹介する予定です。
第1回はOpenStackコンポーネントを軸として、ネットアップ製品のポートフォリオを簡単に紹介します。

データの種類に合ったストレージ選定

ストレージの選定やデータの管理を考える際は、まず大きくデータを2種類に分けて考える必要があります。

  1.) クラウド基盤を構成・維持するために必要なデータ
  2.) 利用者が生成するデータ
これらのデータを単一のストレージ機種で全てカバーすることもできますが、用途に応じて適したストレージを選ぶことが一般的です。

クラウド基盤用のデータは極端に大きくなるわけではないので、特別なハードウェアを使わずミドルウェアの機能による冗長性の担保を検討することが多くなります。OpenStackの管理データベースにMySQLを使えばMySQL Replicationで複製できます。もしくは使い慣れている商用クラスタソフトを利用しても良く、安価に済ませるのであればDRBDとCorosyncやPacemakerを組み合わせることでデータ保護だけでなく耐障害性を向上させるアプローチもあります。(OpenStackの本家サイトに情報が充実しています。)

  Keepalived : http://docs.openstack.org/ha-guide/intro-ha-arch-keepalived.html
  Pacemaker : http://docs.openstack.org/ha-guide/intro-ha-arch-pacemaker.html

利用者が生成するデータは前者のデータと比較にならないほど大きくなるため、経済性と性能の観点でストレージを選定することになります。最近ではホワイトボックスサーバ+SDS(ストレージソフトウェア製品)の組み合わせを検討されるお客様が増えており、まさに増大するデータへの対応と性能の担保が大きな課題であることの現れかと思います。ところが実際にSDSを導入したお客様の声を聞くと、新たな課題に苦労されていることもあるようです。

  例1:ストレージソフトウェアは安価であったが、重複排除や圧縮機能が無いのでサーバーコストが嵩んでしまった。
  例2:SwiftなどでReplicationのデータ保持数を増やすと、必要なサーバ台数がうなぎ上りになった。
  例3:Replicationをやめてerasure codingにするとCPUネックで性能が出ず、高価なサーバを買うことになった。
  例4:DISKだけ増強したいが、CPUとメモリのセットでノード増設しなければならなかった。
  例5:運用が大変。 ログ解析だけで1日つぶれてしまう。
  例6:災害対策用にレプリケーション機能を使おうとしたら、容量節約効果を解除してリモート転送していた。
          (回線費用とDR先のストレージ容量が想定外に増えてしまった。)
  例7:SnapshotやCloneを作るとCinderのI/O性能が劣化し、性能を維持するためにサーバ台数が多くなった。

このような点にも注意し、ストレージの選定を進めていく必要があります。

OpenStackとNetAppストレージの対応

前置きが長くなりましたが、主テーマであるストレージ製品とOpenStackコンポーネントの対応についてご説明します。(OpenStackのコンポーネントの説明は他のサイトに詳しく記載があるので省略します。)

tot-openstack-and-netapp-storage-1

Manila対応

Manilaに対応しているのはNAS機能のあるFAS/AFFシリーズとなります。ユーザが実行するManilaコマンドはONTAP(=FAS/AFFシリーズのOS)用のManilaドライバーによってONTAP APIに変換されます。ファイル共有を作成するManilaコマンドを実行すると、物理ストレージのFASから仮想NASストレージ(Storage VM)が切り出されます。共有の作成やアクセス制限の設定などのManilaコマンドもONTAP API経由で仮想NASストレージ(Storage VM)に設定が反映されます。ONTAPはManilaの2つのモード(全テナントで単一の仮想ストレージを使うShare Serversモードと、テナント毎に専用の仮想ストレージを作り、テナントネットワークのL2セグメントにストレージが足を伸ばすNo Share Serversモード)の両方に対応します。

参考: 各ストレージ製品のManila対応状況 (OpenStack Communityで公開)
Manilaドライバー: http://docs.openstack.org/mitaka/config-reference/shared-file-systems/drivers.html

また、ドライバー毎に機能差がありますので、機種選定の際には以下を確認することをお奨めします。

参考: Manilaドライバーの機能比較
http://docs.openstack.org/developer/manila/devref/share_back_ends_feature_support_mapping.html
上記サイトより一部抜粋

Nova対応

ここでいうNova対応とはCinderを使わない実装を指します。Cinderを使わない場合、通常はハイパーバイザーの内蔵DISK(/var/lib/nova/instances下)にOSブートイメージが格納されますが、ここに外部のブロックストレージをFC/iSCSIでマウントして冗長性や耐障害性を外部ストレージに任せる使い方です。FAS/AFFシリーズ、SolidFireシリーズ、E/EFシリーズはこのような使い方が可能です。しかしブロックストレージは扱いが面倒で管理も煩雑になるため、FASを使っているお客様はNFSでマウントして使うことが多いようです。NFSで利用すれば、ハイパーバイザー障害時はnovaコマンド(nova evacuate <省略> --on-shared-storage)を使って別のハイパーバイザーに仮想サーバを引っ越しすることができます。

Cinder対応

Cinderはcinder-volumeとcinder-backupの2つを分けて記載します。VolumeドライバーとBackupドライバーの対応状況は以下から確認できますので、初めての方は参考になると思います。

参考: 各ストレージ製品Cinder対応状況 (OpenStack Communityで公開)
Volumeドライバー: http://docs.openstack.org/mitaka/config-reference/block-storage/volume-drivers.html
Backupドライバー: http://docs.openstack.org/mitaka/config-reference/block-storage/backup-drivers.html

VolumeドライバーとしてCinderに対応しているのはFAS/AFFシリーズ、SolidFireシリーズ、E/EFシリーズの3種類となります。このうちGlanceからCinderへのOSイメージ展開でコピーオフロード機能を使えるのはFAS/AFFシリーズのみとなります。残り2種類(オブジェクトストレージのStorageGRID Webscaleと、クラウドにデータバックアップするためのAltaVault)はCinderのバックアップ先ストレージとして機能します。StorageGRID WebscaleはS3とSwiftのAPIにも対応しており、Swift用のCinder Backupドライバーを使うことができます。AltaVaultはデータの受け口としてCIFS/NFSを提供するため、NFS用のCinder Backupドライバーを利用できます。AltaVaultに格納されたデータは重複排除・圧縮・暗号化した後にリモート拠点のオブジェクトストレージにデータを自動で転送されます。この転送先はSwiftやStorageGRID Webscaleだけでなく、Amazon S3互換ストレージにも対応します。パブリッククラウドであればAmazon/Azure/Google、国内ではIIJ GIOクラウドのオブジェクトストレージにも対応しており、被災時には別に用意したAltaVaultを使ってデータを復旧することができます。NFS用のCinder Backupドライバーを使えばFASストレージもバックアック先に利用できます。ローカル拠点とリモート拠点にFASストレージを置いて非同期ミラー(SnapMirror)で複製する運用も可能です。また、「POSIX file systems backup driver」を使えば他のブロックストレージもCinderのバックアップ先として利用できます。

参考: Cinderドライバーの機能比較
https://wiki.openstack.org/wiki/CinderSupportMatrix

Swift対応

Swiftはサーバ内蔵DISKで実装するのが一般的ですが、安価なSAN/DASストレージ(E/EFシリーズ)をマウントして使うと多くのメリットが生まれます。NASでの実装も可能で、エントリーモデルのFAS2500/2600シリーズに10TBのNL-SASドライブを大量に搭載して、Swiftサーバにその領域をマウントさせるような使い方となります。SwiftサーバはAPIの処理とデータの受け口のみに専念させ、データの保存と耐障害性は外部ストレージの機能を活用することでReplicationは1つ(=冗長性無し)にすることが可能です。これにより容量効率が向上し、サーバーの台数削減と低スペックサーバの採用が可能となります。このような使い方であればSolidFireもSwiftバックエンドに利用できるのですが、All Flash Arrayなので高価になってしまい、あまり推奨しておりません。(Hybrid Arrayのほうが向いています。) StorageGRID WebscaleはSwift APIが使えるので、Swiftの代替として利用できます。

Glance対応

Glanceのバックエンドストレージも数は少ないですがいくつかの選択肢があります。(ローカルファイルシステム(含むNFS)、オブジェクトストレージ(Swift)、Cinder、CephRDB、http、VMware ESX、Sheepdog)

参考: 各ストレージ製品のGlance対応状況 (OpenStack Communityで公開)
Glanceドライバー: http://docs.openstack.org/mitaka/config-reference/image-service/backends.html

私の周囲のOpenStackユーザの間では、オブジェクトストレージとローカルファイルシステム(NFSマウント)、そしてCinderで運用している管理者が多く見受けられます。オブジェクトストレージを利用している管理者の感想として、イメージの共有やユーザからのアップロード管理方法としては機能的に優れている一方で、仮想サーバの作成(Glanceのイメージ適用)は非常に時間がかかる傾向がある、という声を耳にします。解決策としてGlanceのキャッシュ機能を使って2回目以降の処理を高速化しているようですが、それでも満足のいく結果は得られていないようです。

OpenStack適合表

弊社の製品群がどこに最適なのかを記したのが以下となります。製品名を軸にしてOpenStackコンポーネントを当てはめたので、機種選定の際に参考にしてください。コスト面や管理性なども加味して4段階で記載しています。(機能としての○×ではありません。)

◎ 性能面、機能面、コスト面すべてで最適
○ 利用は問題ないが、少し割高になる組み合わせ。もしくは性能面ではベストではない。
△ もったいない使い方、もしくは運用上の制約(使い勝手や性能面)に注意が必要
× 機能としてそもそもNG、もしくは利用できるが制約が多い、コストが高すぎる

次回について

今回はOpenStackをとりまくデータの取り扱いについて解説しました。次回はCinderにフォーカスして、ブロックストレージの実装上の課題やその解決策について記載する予定です。来月には次期バージョンのNewtonもリリースされるので、期待の新機能、Cinder Volumeのstorage live migrationについても掲載予定です。

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

SIerでインフラ全般を学び、その後はメーカーとSIerを交互に経験。前職ではOpenStackの実装やAWSのシステム運用・構築をしていたが、2014年にNetAppに入社。その後はオブジェクトストレージ、SolidFireなど新しい技術を中心に提案活動を行う。写真はパートナー向けのセミナーでOpenStackについて説明している時のもの。

関連情報

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


第1回:
NetAppストレージのOpenStack対応状況
~ OpenStackコンポーネント別の機種選定 ~
第2回:
OpenStack Cinderで困ること
~ Cinderの機能不足やストレージ設計上の考慮点 ~
  • 掲載予定

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

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

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

第6回:
クラウド事業者から生まれた革新的ストレージ
~ 設計不要でストレスフリーなSolidFire ~
  • 掲載予定

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

第8回:
Manila ファイル共有をリモートサイトに複製
~ Share Replication機能の紹介 ~
  • 掲載予定

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

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