ニンブルストレージをOpenStack環境で使う場合の設計指針

テクニカルレポート
ニンブルストレージをOpenStack環境で
使う場合の設計指針
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
1
目次
OpenStackの概要 .............................................................................................................................................................. 3
クラウドの定義 ........................................................................................................................................................... 3
OpenStackのサービス ............................................................................................................................................... 4
OpenStackにおけるニンブルストレージの価値 ............................................................................................... 5
OpenStackブロックストレージサービス(Cinder)の統合 ............................................................................ 5
ニンブルストレージCinderドライバーの機能............................................................................................. 6
設計時に考慮するポイント ........................................................................................................................................ 7
基盤の設計 ..................................................................................................................................................................... 7
ストレージサービスレベルの設計に関する考慮事項 .............................................................................. 9
高度なストレージサービスの設計 ................................................................................................................... 12
付録 ...................................................................................................................................................................................... 17
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
2
OpenStackの概要
クラウドの定義
NIST (National Institute of Standards and Technology：アメリカ国立標準技術研究所)
のガイドラインでは、クラウドコンピューティングプラットフォームは以下の特性を持つ
サービスオファリングとして定義されています。

オンデマンドのセルフサービス：エンドユーザーがセルフサービスポータルを通し
てインフラストラクチャーリソースを利用できなければなりません。

幅広いネットワークアクセス：このプラットフォームでは、従来のネットワーク仮
想化つまりSDN (software defined networking)が提供するネットワークリソースの
オーケストレーションを行い、それを利用できなければなりません。

リソースプーリング：このプラットフォームでは、コンピュートリソースとスト
レージリソースを論理リソースプールに集約できなければなりません。

迅速な拡張性：このプラットフォームでは、エンドユーザーの需要に応じてリソー
スプールを動的にスケーリングできなければなりません。また逆に、使用されてい
ないリソースを解放できなければなりません。

測定可能なサービス：このプラットフォームは、リソース使用状況を測定する機能、
および使用量に基づいてショーバック(コストの提示)またはチャージバック(課金)
を提供する機能を備えていなければなりません。
これらの要件は、すべてOpenStackクラウドコンピューティングプラットフォームにより解
決できます。OpenStackは、世界規模での開発者およびクラウドコンピューティング技術者
の協力により生まれた、パブリッククラウドおよびプライベートクラウドのためのユビキ
タスなオープンソースプラットフォームです。このプロジェクトの目標は、実装が容易で
拡張性が高く、あらゆるタイプのクラウドで利用できる豊富な機能を備えたソリューション
を実現することです。このプロジェクトは一連の相互に関連するプロジェクトで構成され、
各プロジェクトでクラウドインフラストラクチャーのためのさまざまなコンポーネントが作
成されています。
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
3
OpenStackのサービス
OpenStackダッシュボード(Horizon)：クラウド管理者およびユーザー用のWebベースの管理
ポータル。役割ベースのアクセス制御(RBAC)およびマルチテナンシー機能が組み込まれてい
ます。
OpenStackアイデンティティサービス(Keystone)：ユーザーアクセス管理とアクセス許可、
サービスとそれぞれのAPIポイントのカタログという2つの主要機能を持つアイデンティティ
サービス。
OpenStackイメージサービス(Glance)：パブリックまたはプライベートクラウドのインスタ
ンスイメージ、またはオペレーティングシステムのインストレーションISOのイメージリポ
ジトリー。VMware仮想マシンディスク(VMDK)、Microsoft仮想ハードディスク(VHD)、Amazon
Webサービス(AWS) AMI、ISO、QCOW2などさまざまなフォーマットをサポートしています。
OpenStackコンピュート(Nova)：物理ホストおよびさまざまなハイパーバイザーテクノロ
ジー(KVM、Xen、VMware vSphereなど)をサポートするコンピュートリソースの抽象化。
OpenStackネットワーキング(Neutron)：物理的、仮想化対応、およびソフトウェア定義の
ネットワーキングテクノロジーを利用するネットワーク抽象化レイヤー。
OpenStackオブジェクトストレージ(Swift)：GlanceのISOおよびインスタンスイメージの最
終的な永続的ストレージ/リポジトリーとして機能する、ローカルDAS(Direct Attached
Storage：直接接続されたストレージ)により供給されるオブジェクトベースのストレージ。
OpenStackブロックストレージ(Cinder)：クラウドインスタンス用の永続性があり高性能な
ストレージを提供する、iSCSIプロトコルに基づくブロックベースのストレージ。
オーケストレーションモジュール(Heat)：インスタンスまたはアプリケーションスタック
の迅速なプロビジョニングのための、「Infrastructure as code」テンプレートベースの
オーケストレーションツール。
遠隔測定モジュール(Ceilometer)：リソース使用量の測定およびチャージバックサービス。
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
4
OpenStackサービスの詳細については、『OpenStack Administration Guide』を参照してく
ださい。
OpenStackにおけるニンブルストレージの価値
ニンブルストレージのCASL™ (Cache Accelerated Sequential Layout)アーキテクチャーは、
OpenStackの実装に最適なストレージプラットフォームです。アダプティブフラッシュテク
ノロジーによる読み込みおよび書き込みの最適化、アプリケーション統合データ保護、容量、
性能、およびクラスタリングの柔軟なスケーラビリティを実現します。CASLはOpenStackコ
ントローラーおよびリソースノードのストレージ基盤として機能するため、クラウドプロバ
イダー(プライベートまたはパブリック)はサービスオファリングを差別化してエンドユー
ザーに提供することができます。
1. ニンブルボリュームによりイメージサービスリポジトリーを構成することで、Ephem
eralインスタンスの読み込みおよび書き込み性能を向上させることができます。ま
た、ニンブルのスペース効率に優れたスナップショットおよびレプリケーションに
より、重要なクラウドイメージをバックアップできます。
2. OpenStackブロックストレージ(Cinder)の統合により、ニンブルはインスタンスの永
続性のあるブロックストレージのバックエンドとして機能することができます。ス
ナップショットおよびクローンの処理はオフロードされます。
3. OpenStackコントローラーおよびデータベースノードをニンブルボリュームによって
提供することも可能です。これにより、動作状態の柔軟な維持が可能になり、設定
ミスやOpenStackのアップグレード失敗から簡単にリカバリーできます。
OpenStackブロックストレージサービス(Cinder)の統合
ニンブルは、CinderドライバーによりOpenStackブロックストレージサービスと完全に統合
され、クラウドインスタンスに永続的なブロックストレージを提供します。
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
5
ニンブルストレージCinderドライバーの機能
ボリューム操作

ボリュームの作成/削除

ボリュームの接続/切断

スナップショットの作成/削除

スナップショットからのボリュームの作成

ボリュームの統計の取得

ボリュームへのイメージのコピー

イメージへのボリュームのコピー

ボリュームのクローニング

ボリュームの拡張
ボリュームの統計/属性

ドライバーバージョン

空き容量

領域の予約(%)

総容量

ボリュームバックエンド
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
6
マルチテナンシー

802.1QのVLANカプセル化を使用してテナントごとにストレージデータトラフィック
を分離

Cinderタイプによるストレージプールの分離
設計時に考慮するポイント
基盤の設計
可用性およびスケーラビリティに優れた高性能なOpenStackクラウドプラットフォームを構
築するには、堅実なインフラストラクチャーコンポーネント基盤を構築することが不可欠で
す。OpenStackコントローラーはクラウドプラットフォームの中核をなし、すべてのユー
ザーおよびアプリケーションリソース要求を担い、すべての共有サービスに対する通信の
オーケストレーションを行います。また、バックエンドデータベースと連携して、すべての
リソース要求、リソース状態、およびプラットフォームレベルのすべてのメタデータ情報を
保存します。
OpenStackコントローラー
OpenStackコントローラーノードでの障害発生時にネットワークロードバランサーによって
使用可能なノードに要求をリダイレクトできるようにするために、尐なくとも2個のOpenSta
ckコントローラーノードを使用することを推奨します。ニンブルのスペース効率に優れたス
ナップショットを活用すると、保護レイヤーをさらに付加し、コントローラーノードを迅速
にリカバリーできます。
 物理ホストにより構成されるコントローラーノードは、Boot-from-SAN構成により、
それ自体のOSおよびコントローラーサービスをニンブルボリュームで実行できます。
 仮想マシンにより構成されるコントローラーノードは、それ自体のOSおよびコント
ローラーサービスを、ニンブルボリュームにより構成されるクラスター構成のハイ
パーバイザーファイルシステム(ニンブルボリュームにより構成されるVMFSデータス
トア上のVMDKなど)で実行できます。
MySQLデータベース
MySQLバックエンドデータベースの単一障害点を防ぐために、複数の方法を使用できます。
 アクティブ/スタンバイ構成と同期レプリケーション

アクティブ/アクティブ構成と同期レプリケーション
複数のノードが同時に書き込みを実行しようとした場合に生じるデータベースデッドロック
を防ぐために、アクティブ/スタンバイ構成による方法を使用することを推奨します。MySQL
データベースを設計する際は、ニンブルとオラクル社が共同で作成した『Best Practices
Guide』に従ってください。
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
7
ニンブルボリュームコレクションに関する推奨事項
コントローラーおよびデータベースボリュームは、同じニンブルボリュームコレクションに
配置してください。これにより、組み込みのスナップショットスケジュールまたは手動によ
り、すべてのボリュームのスナップショットを同時に取得できます。この方法には以下のよ
うな利点があります。




OpenStackインフラストラクチャー全体の動作状態をキャプチャーできます。これに
より、アップグレード失敗や設定ミスによってサービスが停止した場合に、プラッ
トフォーム全体を正常に動作することがわかっている状態にロールバックできます。
ハードウェアの問題によってノード障害が発生した場合、ボリューム上に環境が構
成されているので、コントローラー環境またはデータベース環境を新しいサーバー
ノードまたは代替サーバーノードにプロビジョニングして、即座にサービスをリカ
バリーできるため、サービスやデータベースの再インストールは不要です。
アップグレードの準備として、ニンブルのゼロコピー・クローンをインスタンス化
し、アップグレードテストを行うことができます。例えば、コントローラーノード2
に、最新のスナップショットからクローニングされたブートボリュームを保持でき
ます。新たなOpenStackリリースアップグレードを使用してクローンからブートする
ようノードを設定することにより、互換性およびアップグレードの潜在的な問題を
テストできます。元のボリュームを使用してノードをブートすれば、アップグレー
ドをロールバックできます。
組み込みのニンブルWANレプリケーションにより、OpenStackクラウドプラット
フォームに災害復旧保護機能を実装できます。データセンターで計画的な停止また
は計画外の停止が発生した場合は、レプリケートされたOpenStack環境のスナップ
ショットコピーを瞬時にプロビジョニングし、ビジネス継続性を維持できます。
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
8
Glanceイメージリポジトリーの高速化
デフォルトでは、OpenStackイメージサービス(Glance)は、インスタンスイメージつまりISO
ファイルをローカルのオペレーティングシステムディレクトリー(/var/lib/glance/images)
に保存するよう設定されています。この単純な設計では、Ephemeralインスタンスをイメー
ジリポジトリーから直接ブートできます。これらのタイプのインスタンスの性能は、リポジ
トリーを構成しているストレージに大きく左右されます。また、クラウドインスタンスベー
スのOSイメージおよびカスタムイメージを保護するために、リポジトリーの定期的なバック
アップが必要です。すなわち、ニンブルボリュームによりイメージサービスリポジトリーを
バックアップする必要があります。イメージサービスのバックエンドストレージとして機能
するニンブルボリュームを使用すると、スクラッチスペースの高速化により、多数のEpheme
ralインスタンスを迅速にブートできます。また、ニンブルの効率的なスナップショットで
は、すべてのイメージを頻繁にバックアップすることが可能です。
ストレージサービスレベルの設計に関する考慮事項
インフラストラクチャー基盤を設計したら、次のステップではストレージサービスレベルの
オファリングを設定します。すべてのアプリケーションおよび用途のニーズでストレージ性
能、容量、およびデータ保護に求められる要件は同じわけではありません。OpenStackの
Cinderサービスでは、ストレージサービスレベルの設計に高い柔軟性がもたらされます。以
下は、マルチバックエンドCinder機能(OpenStackのGrizzlyリリース以降に導入された機能)
を活用して、差別化されたストレージサービスオファリングを設計するためのリファレンス
モデルです。
基本層：
一般に、サーバーノードにはローカルDASストレージが搭載されています。このようなスト
レージはオファリングの基本層として機能でき、大容量または高性能であることが求められ
ない用途に適しています。ローカルDASを集約してLVMボリュームを作成し、このLVMボ
リュームによって、ネイティブLVM Cinderドライバーを通してCinderボリュームを構成でき
ます。
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
9
プレミアム(共有)：
高容量かつ高性能であることが求められるアプリケーションの場合、ニンブルボリュームで
構成されたLVMボリュームとLVMのCinderボリュームドライバーによりプレミアム層を構成で
きます。これにより、VG内の1個のニンブルボリュームという小規模な構成から開始し、容
量ニーズの増加に応じて複数のボリュームにまたがるよう動的に拡張できます。CASLでは、
フラッシュと大容量ディスクを融合したニンブルのアダプティブフラッシュプラットフォー
ムを活用することで、読み込みおよび書き込み処理が最適化されます。ニンブルボリューム
により構成されるLVMボリュームグループを使用すると、高い性能と容量が組み込まれるだ
けでなく、無停止拡張とスケーラビリティが容易に実現されます。
高性能(専用)：
非常に厳しい性能要件が求められるアプリケーションの場合、ニンブルのCinderドライバー
により専用のCinderボリュームを割り当てることができます。この層では、専用のCinderニ
ンブルボリューム(OS用)から、またアプリケーションデータ用に接続された1つ以上の
Cinderニンブルボリュームを使用して、インスタンスをブートできます。さらに、ネイティ
ブのニンブルCASLスナップショット、クローン、およびレプリケーションテクノロジーとIn
foSight™の分析レポート機能を個々のインスタンスレベルできめ細かく適用できます。ニン
ブルCinderの統合によりすべての機能を有効化した場合、オファリングのこの層をストレー
ジサービスの最上位層として分類できます。
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
10
以下の表に、各ストレージサービスレベルで有効化される主な使用ケースと、それぞれで有
効化される機能セットをまとめます。
サービス層
基本層
Cinderストレージの構成要素
ローカルサーバーDASによるV
G (LVM Cinderドライバー)
機能
 共有ストレージプール
プレミアム(共有)
ニンブルストレージボリュー
ムによるVG (LVM Cinderドラ
イバー)

ニンブルストレージのCinder
ボリューム(Nimble Cinderド
ライバー)

高性能(専用)





テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
データ量の削減(ニンブルイン
ライン圧縮)
LVMレベルのスナップショット
LVMレベルのボリュームの完全
コピー
データ量の削減(ニンブルイン
ライン圧縮)
セルフサービスインスタンス
のスナップ、リストア、およ
びクローン
o インスタンスボリュー
ムレベルでのスペース
効率の高いスナップ
ショット
o ニンブルCASLのゼロコ
ピー・クローンによる
インスタンスの高速ク
ローニング
InfoSightによるインスタンス
レベルでの容量および性能分
析とディスクやCPUの余裕のレ
ポート
その他の高度な機能について
は、「高度なストレージサー
ビスの設計」を参照のこと
11
高度なストレージサービスの設計
ニンブルのCinder統合機能によって一連の機能を付加することで、エンドユーザーアプリ
ケーションへの価値の提供において、ストレージオファリングの最上位層をさらに差別化で
きます。


ストレージのマルチテナンシー
マルチパス機能

インスタンスの高速クローニングのオフロード
ストレージのマルチテナンシー
ニンブルのiSCSIデータインターフェースでは、802.1QのVLANタギングがサポートされます。
各データインターフェースには、特定のVLANに関連付けられた専用または共有サブネットを
設定できます。この機能は、ニンブルCinderドライバーの「サブネット」オプションを使用
することで活用できます。以下は、テナントへのトラフィックを処理する専用データイン
ターフェースの作成手順概要です。
マルチパス機能
マルチパス機能を使用すると、OpenStack Novaノードおよびニンブルアレイ両方の使用可能
なすべてのネットワークインターフェースに渡ってI/O処理を実行できるようになり、イン
スタンスボリュームの性能がさらに向上します。マルチパス機能は、ニンブルボリュームに
より構成されるLVM VGと、インスタンスに接続された個々のCinderニンブルボリュームの両
方に対して設定できます。以下の手順概要に、OpenStack環境でマルチパス機能を有効にす
るために必要な作業を示します。
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
12
*注意* ニンブルボリュームにより構成されるLVM VGの場合は、VG自体でマルチパス機能が
動作するため、手順3をスキップできます。個々のインスタンスには利点が透過的に継承さ
れます。
インスタンスの高速クローニングのオフロード
ゼロコピー・クローンテクノロジーを活用することにより、インスタンスレベルのクローニ
ングをニンブルアレイにオフロードできます。各クローンでは、追加のディスクスペースを
使用することなく、同じ性能、容量、およびデータ保護機能が提供されます。これを有効に
するには、インスタンスをCinderニンブルボリュームからブートし、次にクローニングの
ソースとして機能するインスタンスボリュームスナップショットを作成する必要があります。
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
13
手順1：クラウドイメージをソースとして使用してボリュームを作成
手順2：ボリュームスナップショットを作成
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
14
手順3：インスタンスを起動し、作成するクローン数を指定
手順4：インスタンスからデータブロックを複製することなく、アレイレベルのクローンが
瞬時に作成可能に
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
15
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
16
付録
A.1 ニンブルCinderドライバーのインストール
ドライバーの配置
OpenStackコントローラーノードの以下のディレクトリーに「nimble.py」を配置します。
/usr/lib/python2.6/site-packages/cinder/volume/drivers/
単一バックエンドCinder構成
/etc/cinder/cinder.confファイルの[DEFAULT]セクションの下に以下の行を追加します。
#Nimble Cinder configurations
san_ip=<IP address of Nimble array/group>
san_login=admin <Nimble account login with minimum “power user” privilege if RBA
C is used>
san_password=<password of admin account for nimble array>
volume_driver=cinder.volume.drivers.nimble.NimbleISCSIDriver
volume_backend_name=Nimble-Cinder
注意：「volume_backend_name」は、単一バックエンドCinder構成では必要ありません。
ただし、将来的なマルチバックエンドCinder構成への移行時に問題が発生するのを防ぐた
め、指定することを推奨します。
OpenStackコントローラーノードのCLIで、ボリュームタイプとしてニンブルバックエンドを
作成し、このタイプラベルをCinderバックエンドに関連付けてから、サービスを再起動しま
す。
# cinder type-create Nimble-Cinder
# cinder type-key Nimble-Cinder set volume_backend_name=Nimble-Cinder
注意：「openstack-cinder-*」はRed Hat OpenStackディストリビューションに固有です。
一般に、オープンソースディストリビューションの場合は「cinder-volume」のみです。
#service openstack-cinder-scheduler restart
#service openstack-cinder-api restart
#service openstack-cinder-volume restart
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
17
A.2 マルチバックエンドCinderの実装
OpenStack HorizonでAdmin (管理)タブに移動し、Volumes (ボリューム)を選択します。次
に、定義されているサービスレベルオファリングに基づいてボリュームタイプを定義します。
/etc/cinder/cinder.conf構成ファイルを以下のように編集して、各ボリュームタイプを対
応するドライバーおよびドライバーオプションに関連付けます。
enabled_backends=nimble-cinder,nimble-lvm
[Nimble-Cinder]
san_ip=<management IP of Nimble array or group>
san_login=<admin user for the Nimble array>
san_password=<admin password for the Nimble array>
volume_driver=cinder.volume.drivers.nimble.NimbleISCSIDriver
volume_backend_name=Nimble-Cinder
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
18
[DAS-LVM]
volume_group=<name of LVM volume group backed by local DAS>
volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name=DAS-LVM
[Nimble-LVM]
volume_group=<name of LVM volume group backed by Nimble volume>
volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name=Nimble-LVM
A.3 マルチパス機能
1.
2.
3.
4.
Cinderを使用して新しいボリュームを作成します。
このボリュームをVMに接続します。
「iscsiadm -m node」を使用して、新しいボリュームのiqnを特定します。
iscsiadm -m node -T <target_iqn> -p 172.17.2.75 --op update node.session.nr_se
ssions -v 4
a. 例：iscsiadm -m node -T <target_iqn>iqn.2007-11.com.nimblestorage:volume
-81c6d336-e770-4d25-99b9-1aabc9b87a9d-v4161c23a56cef8c7.00000002.17af3af
d -p 172.17.2.75 --op update node.session.nr_sessions -v 4
b. これにより、デバイスへの4つのiSCSI接続/パスが確立されます。
5. /etc/init.d/iscsi restart
6. multipath –ll
# iscsiadm -m session
tcp:[2] 10.12.61.154:3260,2460 iqn.2007-11.com.nimblestorage:volume-75c1f2e3-e2a54f16-b8cb-97cc8867d469-v4161c23a56cef8c7.00000003.17af3afd
tcp:[3] 10.12.61.154:3260,2460 iqn.2007-11.com.nimblestorage:volume-75c1f2e3-e2a54f16-b8cb-97cc8867d469-v4161c23a56cef8c7.00000003.17af3afd
tcp:[4] 10.12.61.154:3260,2460 iqn.2007-11.com.nimblestorage:volume-75c1f2e3-e2a54f16-b8cb-97cc8867d469-v4161c23a56cef8c7.00000003.17af3afd
tcp:[5] 10.12.61.154:3260,2460 iqn.2007-11.com.nimblestorage:volume-75c1f2e3-e2a54f16-b8cb-97cc8867d469-v4161c23a56cef8c7.00000003.17af3afd
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
19
# multipath -ll
mpathc (2c9d9a9f9ae79ccf36c9ce900fd3aaf17) dm-2 Nimble,Server
size=3.0G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
|- 7:0:0:0 sdd 8:48 active ready running
|- 4:0:0:0 sdf 8:80 active ready running
|- 5:0:0:0 sde 8:64 active ready running
`- 6:0:0:0 sdc 8:32 active ready running
A.4 OpenStackイメージサービスのオフロード
1. ストレージシステムのiSCSIディスカバリーIPアドレスを特定します。
iscsiadmを使用してボリュームを検出します。
[root@TS-Training-OS-01 ~]# iscsiadm -m discovery -t sendtargets -p discovery_IP
2. 適切なボリュームへの接続を確立します。
[root@TS-Training-OS-01 ~]# iscsiadm --mode node --targetname iqn.2007-11.com.nim
blestorage:jan-openstack-glance-v2057ea2dd8c4465b.00000027.f893ac76 --portal disc
overy_ip:3260 –login
3. ボリュームに接続したら、fdisk -lを使用して新しいディスクを特定します。以下の例
では、/dev/sdcです。mkfsを使用してext4内のディスクをフォーマットします。
[root@TS-Training-OS-01 ~]# mkfs.ext4 -b 4096 /dev/sdc
4. デバイスのフォーマット後、マウントポイントを作成し、それに対するアクセス許可を
変更します。
[root@TS-Training-OS-01 ~]# mkdir /mnt/glance
[root@TS-Training-OS-01 ~]# chmod 777 /mnt/glance
5. リブート後に自動的に/dev/sdcを/mnt/glanceにマウントするようfstabを設定します。
以下の行を/etc/fstabに追加します。
/dev/sdc
/mnt/glance
ext4
defaults
0
0
6. 以下のコマンドを実行して、/dev/sdcを/mnt/glanceにマウントします。
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
20
[root@TS-Training-OS-01 ~]# mount /dev/sdc /mnt/glance
7. 「/etc/glance/glance-api.conf」ファイルを更新し、ニンブルボリュームにより構成
される、新たにマウントされたファイルシステムにリポジトリーがリダイレクトされる
ようにします。
# ============ Filesystem Store Options ========================
# Directory that the Filesystem backend store
# writes image data to
#filesystem_store_datadir=/var/lib/glance/images/
filesystem_store_datadir=/mnt/glance/
8. glance-apiサービスを再起動します。glanceにより新たにアップロードされたイメージ
がコントローラーの/mnt/glanceの下に配置されます。
[root@TS-Training-OS-01 ~]# service openstack-glance-api restart
Nimble Storage Japan
〒108-0075 東京都港区港南2-16-1 品川イーストワンタワー４F
電話：03-6890-8337
| Eメール：[email protected]
| URL: www.nimblestorage.com
© 2015 Nimble Storage, Inc.、Nimble Storage、InfoSight、CASL、SmartStack、およびNimbleConnectは米国
Nimble Storage, Inc.の米国における商標または登録商標です。他の商標はすべて、それぞれの所有者に帰属し
ます。TR-OPS-1114
nmblpg012(150309)
テクニカルレポート：ニンブルストレージをOpenStack環境で使う場合の設計指針
21

Download Report