こんにちは。先日、Red Hat Tech Night のライトニングトークでラボ環境にOpenShift on OpenStack が欲いと呟いた、ソリューションアーキテクトの荒木です。
今回は、以前の記事で紹介したArchitecture Design Patternsに、新たに、パターンを追加致しましたので、紹介します。
今回作成したパターンは、RHOSP上で、ファイル共有サービス(manila)機能を有効にするものです。 パターンの詳細は、こちら「企業プライベートIaaS ファイル共有サービス(CephFS NFS-ganesha) 構成」
ファイル共有サービス
OpenStackで実装されているファイル共有サービス(manila)は、文字通り、VMインスタンスに対して、ファイル共有サービスを提供するものです。 manila project wiki
manilaは、ファイル共有サービスそのものの提供に加えて、ファイル共有サービス利用に必要となるAPI群を提供します。例えば、ボリュームの作成／削除や、アクセス許可といった、ストレージそのものへの設定操作を抽象化しています。
尚、実データの読み書きや、データの可用性（RAID等を使用したデータの冗長化）については、バックエンドのストレージの機能に委ねられています。
manila アーキテクチャ概要
VMインスタンス( ユーザ）から、ファイル共有サービスへのアクセスを図示すると、下記のようになります。
- VMインスタンスは、controller ノード上のNFS-ganesha と、NFS v4 で接続します。
- NFS-ganesha は、CephFSで、ceph-osd とデータのやり取りをします。
その他、各種、ファイル共有領域にの作成といった管理操作に関するリクエストは、manila api によって処理され、manila share service によって、ストレージ上の領域が管理される動作となります。
ADP構成のポイント
今回の構成では、下記のポイントがあります。
- ファイル共有サービスのストレージバックエンドをceph としている
- データアクセストラヒック専用ネットワークを用意している
RHOSPのストレージバックエンド
ADP構成では、Red Hat Ceph Storage を RHOSP全体のストレージバックエンドとして使用する構成となっています。ファイル共有サービスのデータ領域についても、Ceph Storage に集約する構成となります。
主な機能と、Ceph Storage のI/F をまとめると下記のようになります。
| 機能/機構 | Ceph I/F | 備考 |
|---|---|---|
| Block Volume ( cinder ) | librbd | |
| Block Volume Backup ( cinder-backup ) | librbd | デフォルトはSwift |
| Image ( glance ) | librbd | デフォルトはSwift |
| nova boot-disk | librbd | デフォルトはcompute のローカル |
| meterling ( ceilometer ) | librados | gnocchi のバックエンド |
| Object Store ( swift ) | librados | ADPでは、rados は未組込 |
| File Shareing ( manila ) | libcephFS | nfs-ganesha - CephFS 間は、ネイティブ |
ネットワーク構成
ネットワークの接続は、下記の図のようになります。
図の"StorageNFS(紫線)"が、クライアントと、NFS-ganesha との通信で使用されるネットワークとなります。これは、製品ドキュメントで紹介されているネットワーク構成をそのまま踏襲した接続方法となっています。
尚、StorageNFS は、プロバイダーネットワークとして構築され、VMインスタンスは、StorageNFS のVLANへNICを接続し、アクセスする形となります。
構築時の注意点
構築方法の詳細は、ADP をご確認いただければと思いますが、オーソドックスな構築パターンと比べて、幾つか、特殊な機能を使用しているので、簡単に紹介します。
- カスタムのロール定義
- ネットワーク定義の拡張
overcloud deploy コマンド
overcloud deploy コマンドは、下記となります。
time openstack overcloud deploy --verbose \ --templates /usr/share/openstack-tripleo-heat-templates \ -n /usr/share/openstack-tripleo-heat-templates/network_data_ganesha.yaml \ -r /home/stack/templates/roles_data.yaml \ -e /home/stack/templates/global-config.yaml \ -e /home/stack/templates/cloud-names.yaml \ -e /home/stack/templates/scheduler_hints_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \ -e /home/stack/templates/overcloud_images.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-bond-with-vlans.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-management.yaml \ -e /home/stack/templates/network-environment.yaml \ -e /home/stack/templates/ips-from-pool-all.yaml \ -e /home/stack/templates/ceph-storage-environment.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-mds.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml \ --timeout 210 \ --ntp-server ntp.nict.jp \ --log-file ./overcloud_deploy.log \ --stack $stack_name
テンプレートを指定する場合、通常は、-e オプションの後に、読み込ませる yamlファイルを指定しますが、今回は、-n オプションと、-r オプションを用いて、特殊な定義をしています。
- それぞれのオプションの意味
- -n : overcloud のネットワーク構成を、デフォルトから上書きする場合に指定 ... 今回は、StorageNFS セグメントの定義
- -r : node の役割(compute , controller ...etc) を、拡張する場合に指定 ... 今回は、ControllerStorageNfs というカスタムロールを定義
ロール(役割)は、製品として予め定義されています(compute , controller , swift ...etc) 。これらのロール定義の作用は、overcloudを構築する際に、node(物理マシン)に対して、どのOpenStackのコンポーネントを配置するかというマップ情報となります。使い方を例えると、デフォルトで、「controllerノードの機能として定義されている、SwiftStorage 機能を、切り離して、swift専用のロールを定義する」という様になります。この例が期待するところは、オブジェクトストレージサービスをcontroller から分離する事で、controllerが、3台配置が上限である点に対して、SwiftStorage機能をより多い台数で構成できることです。
カスタムロールの詳細は、RHOSP director がもつ機能 をご覧ください。
(注意)カスタムロールは、極端な使い方をすれば、全ての機能を単一のロールに集約したり、逆に、全ての機能を別々のnode に分解したりもできうる仕組みですが、任意の構成が実際に構築できることと、その構成サポートされるか否かは別の問題となりますので、カスタムロールを使用して機能の配置を検討される場合は、Red Hat までご相談ください。
manila の使用感
manila の使い方を紹介する動画を用意しましたので、こちらも合わせてご覧ください。
まとめ
今回は、ADP の新しいパターンとして、ファイル共有サービス（デフォルトでは無効化されている）機能を有効化した構成を紹介しました。機能を拡張／カスタマイズする上で、標準的なオプション意外に、"-n" でネットワーク定義を拡張したり、"-r" でロールを拡張／変更したりする方法について、ここで簡単に紹介しました。
おわりに
カスタムロール(-r)や、コンポーサーブルネットワーク(-n) は、比較的、最近実装された機能となりますが、使いなれる事によって、より構成の自由度が上がるため、より自分好み（要件にそった）OpenStack 環境を構築する上では、重要なテクニックであると思います。
他方、RHOSP で新しい構成を為す場合、以前は、度重なるトライ＆エラー(社内では、『素振り』と呼んでいます(笑))を伴うのが常なのですが、今回はとてもスムーズに進めることができました。
CEPHFS VIA NFS BACK END GUIDE FOR THE SHARED FILE SYSTEM SERVICEように、構成方法に関する情報がきちんと用意されるようになった現在は、数年前の圧倒的に情報が不足していた時期と比べて、製品の品質と安定度が向上してきているのだなと実感しました。