Translated message

A translation of this page exists in English.

Warning message

This translation is outdated. For the most up-to-date information, please refer to the English version.

各サービスを個別に更新する方式による OpenStack のアップグレード

更新 -


1. 概要

この方法では、一度に長時間サービスを停止させるのではなく、特定のサービスの停止を段階分けすることができます。たとえば、Compute を旧バージョンで実行する一方で、Identity Service を Red Hat Enterprise Linux OpenStack Platform 5 リリースで稼働させることができます。
長時間を要する可能性のあるアップグレード (例: 大規模な環境における Compute Service のアップグレードなど) は、短時間で完了するアップグレードとは別にスケジュールすることができます。Compute API サービスとコンピュートノードがアップグレードされている間は、関連するサービスは中断されます。

注意

本記事に記載する手順は、Red Hat Enterprise Linux OpenStack Platform の全ドキュメントに適用されているアーキテクチャー命名規則に従っています。この規則について十分理解していない場合は、手順を開始する前にこちらのリンクを参照してください。


2. RHN/CDN チャンネルの設定

本セクションでは、Red Hat Enterprise Linux OpenStack Platform 5 のデプロイに必要なチャンネルおよびリポジトリの設定について説明します。

警告

旧バージョンの Red Hat OpenStack リポジトリは利用可能な状態ですが、Red Hat Enterprise Linux OpenStack Platform 5 のインストールの前に、お使いのシステムからこれらのリポジトリへアクセスできないようにする必要があります。たとえば、CDN の場合、以下のリポジトリは無効にするか、サブスクライブを解除してください。
  • Red Hat OpenStack 1.0 (Essex) -- rhel-server-ost-6-preview-rpms
  • Red Hat OpenStack 2.1 (Folsom) -- rhel-server-ost-6-folsom-rpms
  • Red Hat Enterprise Linux OpenStack Platform 3 (Grizzly) -- rhel-server-ost-6-3-rpms
  • Red Hat Enterprise Linux OpenStack Platform 4 Beta (Havana) -- rhel-6-server-openstack-beta-rpms
  • Red Hat Enterprise Linux OpenStack Platform 4 (Havana) -- rhel-6-server-openstack-4.0-rpms

注意

cloud-init を必要とする、カスタムの Red Hat Enterprise Linux ゲストイメージを作成する場合は、Red Hat Common for RHEL Server チャンネルの使用を推奨します。
Red Hat Enterprise Linux 6 の場合は、以下のコマンドを実行します。
# subscription-manager repos \
    --enable=rhel-6-server-rh-common-rpms


2.1. コンテンツ配信ネットワーク (CDN) チャンネル

コンテンツ配信ネットワークから Red Hat Enterprise Linux OpenStack Platform 5 をインストールすることができます。そのためには、正しいチャンネルを使用するように subscription-manager を設定します。
CDN チャンネルを有効にするには、以下のコマンドを実行します。
# subscription-manager repos --enable=[reponame]
CDN チャンネルを無効にするには、以下のコマンドを実行します。
# subscription-manager repos --disable=[reponame]


表 1.  必須チャンネル

チャンネル リポジトリ名
Red Hat OpenStack 5.0 Beta (RPMS) for Server 6 rhel-6-server-openstack-5.0-rpms
Red Hat Enterprise Linux 6 Server (RPMS) rhel-6-server-rpms


表 2.  任意チャンネル

チャンネル リポジトリ名
RHEL Server Load Balancer (v6 for 64-bit x86_64) rhel-lb-for-rhel-6-server-rpms
Red Hat Enterprise Linux 6 Server - Optional rhel-6-server-optional-rpms
CDN を使用する場合、Red Hat Enterprise Linux OpenStack Platform 5 が正常に機能するように、以下のチャンネルは無効にする必要があります。


表 3.  無効にするチャンネル

チャンネル リポジトリ名
Red Hat CloudForms Management Engine "cf-me-*"
Red Hat CloudForms Tools for RHEL 6 "rhel-6-server-cf-*"
Red Hat Enterprise Virtualization "rhel-6-server-rhev*"
Red Hat Enterprise Linux 6 Server - Extended Update Support (EUS) "*-eus-rpms"
Red Hat Software Collections "rhel-server-rhscl-6-rpms"


2.2. Red Hat Network (RHN) チャンネル

Red Hat Enterprise Linux OpenStack Platform 5 は Red Hat Network (RHN) からインストールすることができます。
RHN 経由でチャンネルを追加するには、以下のコマンドを実行します。
# rhn-channel --add --channel=[reponame]
RHN 経由でチャンネルを削除するには、以下のコマンドを実行します。
# rhn-channel --remove --channel=[reponame]


表 4.  必須チャンネル

チャンネル リポジトリ名
Red Hat OpenStack 5.0 for RHEL 6 Server x86_64 rhel-x86_64-server-6-ost-5
Red Hat Enterprise Linux Server (v6 for 64-bit AMD64 / Intel64) rhel-x86_64-server-6


表 5.  任意チャンネル

チャンネル リポジトリ名
RHEL Server Load Balancer (v6 for 64-bit x86_64) rhel-x86_64-server-lb-6
RHEL Server Optional (v. 6 64-bit x86_64) rhel-x86_64-server-optional-6
MRG Messaging v2 (for RHEL 6 Server x86_64) rhel-x86_64-server-6-mrg-messaging-2


3. サービス別アップグレード

以下の表には、各サービス固有のアップグレード手順と順序をまとめています。


表 6.  サービスのアップグレードの順序と手順

サービス 注記
Identity (keystone)
Red Hat Enterprise Linux OpenStack Platform 4 の Identity Service では、期限切れのトークンは一切完全削除されなかったため、トークンテーブルに期限切れのエントリが多数含まれている可能性があります。このような場合には、データベーススキーマのアップグレードの所要時間が大幅に増大する可能性があります。
Identity データベースのアップグレードを実行する前に keystone-manage token_flush コマンドを使用すると、データベースから期限切れのトークンをフラッシュして問題を軽減することができます。
Identity ホストで以下のコマンドを実行します。
# openstack-service stop keystone
# yum -d1 -y upgrade \*keystone\* python-migrate
# keystone-manage token_flush
# openstack-db --service keystone --update
# openstack-service start keystone
Object Storage (swift)
Object Storage ホストで以下のコマンドを実行します。
# openstack-service stop swift
# yum -d1 -y upgrade \*swift\*
# openstack-service start swift
Block Storage (cinder)
Block Storage ホストで以下のコマンドを実行します。
# openstack-service stop cinder
# yum -d1 -y upgrade \*cinder\* python-migrate
# openstack-db --service cinder --update
# openstack-service start cinder
Image Service (glance)
Image Service ホストで以下のコマンドを実行します。
# openstack-service stop glance
# yum -d1 -y upgrade \*glance\* python-migrate
# openstack-db --service glance --update
# openstack-service start glance
Telemetry (ceilometer)
Telemetry コンポーネントサービスをホストする全ノードで以下のコマンドを実行します。
# openstack-service stop ceilometer
# yum -d1 -y upgrade \*ceilometer\* python-migrate
Telemetry コンポーネントサービスの一覧は、「Telemetry の API およびエージェントの起動」を参照してください。パッケージのアップグレードが完了した後には、Telemetry コンポーネントサービスをホストする全ノードで以下のコマンドを実行して Telemetry Service を再起動します。
# openstack-service start ceilometer
Orchestration (heat)
Orchestration ホストで以下のコマンドを実行します。
# openstack-service stop heat
# yum -d1 -y upgrade \*heat\* python-migrate
# openstack-db --service heat --update
# openstack-service start heat
Dashboard (horizon)
Dashboard ホストで以下のコマンドを実行します。
# yum -y upgrade \*horizon\* \*openstack-dashboard\*


4. Compute Service のアップグレード

セクション 3「サービス別のアップグレード」で説明した手順に従って全コンポーネント (Compute と Networking を除く) のアップグレードが完了したら、次に Compute Service のアップグレードを実行することができます。この操作を開始するには、コントローラーノードで Compute Service をアップグレードする必要があります。このノードは、Compute の制御サービスをホストしています (例: Compute API サービス)。


手順 1. Compute コントローラーのアップグレード

  1. Compute コントローラーノードで実行中の nova サービスをすべて停止します。
    # openstack-service stop nova
    次にそれらの各ノードで nova パッケージをアップグレードします。
    # yum -y upgrade \*nova\* python-migrate
  2. 任意のコントローラーノードでデータベースのアップグレードスクリプトを実行して、Compute のデータベースをアップグレードします。
    # openstack-db --service nova --update
  3. Compute RPC API を Red Hat Enterprise Linux OpenStack Platform 4 のコンピュートノードがまだ認識できるバージョンに上限設定します。そのためには、Compute コントローラーノードで以下のコマンドを実行します。
    # openstack-config --set /etc/nova/nova.conf \
       upgrade_levels compute icehouse-compat
  4. コントローラーノードで以下のコマンドを実行して、コントローラーサービスを再起動します。
    # openstack-service start nova


4.1. libvirt_vif_driver の設定

旧ハイブリッドドライバーは非推奨となったため、アップグレードプロセスの一環として、/etc/nova/nova.conf で正しい libvirt_vif_driver を設定する必要があります。そのためには、Compute API ホストで以下のコマンドを実行してください。
# openstack-config --set /etc/nova/nova.conf \
   DEFAULT libvirt_vif_driver nova.virt.libvirt.vif.LibvirtGenericVIFDriver
次に、各コンピュートノードを設定して、VIF プラギングが失敗した場合にはインスタンスのブートが失敗するようにする必要があります。そのためには、各コンピュートノードで以下のコマンドを実行してください。
# openstack-config --set /etc/nova/nova.conf \
   DEFAULT vif_plugging_is_fatal true
# openstack-config --set /etc/nova/nova.conf \
   DEFAULT vif_plugging_timeout VIFTIMEOUT
VIFTIMEOUT は、VIF プラギングの試行が失敗するまでの待ち時間 (秒単位) に置き換えます。VIFTIMEOUT の推奨値は 300 です。


4.2. コンピュートノードのアップグレード

セクション 4「Compute Service のアップグレード」の手順に従って Compute コントローラーをアップグレードし、セクション 4.1「libvirt_vif_driver の設定」の手順に従って /etc/nova/nova.conflibvirt_vif_driver を正しく設定した後には、コントローラーノードは Red Hat Enterprise Linux OpenStack Platform 5 バージョンの nova を実行しているはずですが、コンピュートノードは、まだ Red Hat Enterprise Linux OpenStack Platform 4 バージョンの nova を実行している状態となります。
これらのノードをアップグレードするには、そこで実行されている全インスタンスをシャットダウンする必要があります。コンピュートノードのアップグレードは以下の手順に従って実行してください。


手順 2. コンピュートノードのアップグレード

  1. nova-compute サービスを disabled に設定して、ノード上で Compute が新規インスタンスのスケジュールを行わないようにします。
    # nova service-disable --reason upgrade NODENAME nova-compute
    NODENAME はアップグレードするコンピュートホストの名前に置き換えます。NODENAME は、Compute が認識済みのホスト名にする必要があります。Compute が認識済みのコンピュートホスト名の一覧を確認するには、以下のコマンドを実行してください。
    # nova service-list --binary nova-compute
  2. ノード上の nova-compute サービスを停止します。
    # openstack-service stop nova-compute
  3. nova パッケージを python-migrate とともにアップグレードします。
    # yum upgrade \*nova\* python-migrate
  4. nova サービスを再起動します。
    # openstack-service restart nova
  5. nova-compute サービスを再度有効にします。
    # nova service-enable NODENAME nova-compute


5. Networking Service のアップグレード

必要に応じて Compute コントローラーをアップグレードした後には、OpenStack Networking を設定する必要があります。この手順を開始するには、Networking コントローラーノードおよび OpenStack Networking Service を実行するその他の全ホストで以下のコマンドを実行します。
# openstack-service stop neutron
# yum -d1 -y upgrade \*neutron\*
次に、Networking コントローラーノードで以下のコマンドを実行します。
# openstack-db --service neutron --update
再起動する前に、Networking Service の追加の設定を手動で行う必要があります。これらの要件については、以下のサブセクションで詳しく解説します。


5.1. Compute Service と Networking Service 間の対話の設定

本リリースの OpenStack Networking Service では、新規インターフェース設定の要求に応答して、Compute Service へアクティブに通知できるようになりました。この設定は、以下の手順に従って行います。


手順 3. neutron と nova の対話の設定

  1. ポートのステータスがアクティブに切り替わった時に neutronnova に通知するように設定します。
    # openstack-config --set /etc/neutron/neutron.conf DEFAULT notify_nova_on_port_status_changes true
  2. neutron が Compute API サービスの新規アドレスを使用するように設定します。
    # openstack-config --set /etc/neutron/neutron.conf DEFAULT nova_url http://COMPUTEAPIADDRESS:8774/v2
  3. neutron に必要な認証情報を提供します。
    # openstack-config --set /etc/neutron/neutron.conf DEFAULT nova_admin_username NOVAADMIN
    # openstack-config --set /etc/neutron/neutron.conf DEFAULT nova_admin_password NOVAPASSWD
    # openstack-config --set /etc/neutron/neutron.conf DEFAULT nova_admin_tenant_id NOVATENANT
    # openstack-config --set /etc/neutron/neutron.conf DEFAULT nova_admin_auth_url KEYSTONEENDPOINT
    • NOVAADMIN は、OpenStack 環境で管理者権限のあるユーザーに置き換えます。

      注意

      『OpenStack のデプロイ: 実習環境 (手動設定)』ガイドの例では、Compute Service 専用に admin ロールを持つ compute というユーザーと、services というテナントを作成します。このユーザーは、NOVAADMIN として適切です。
    • NOVAPASSWD は、NOVAADMIN に対応するパスワードに置き換えます。
    • NOVATENANT は、NOVAADMIN に関連付けられたプライマリテナントの UUID に置き換えます。
    • KEYSTONEENDPOINT は、keystone サービスの管理エンドポイントの URL に置き換えます。
neutronnova 間の対話に関連する利用可能な設定についての詳しい情報は、OpenStack Networking をアップグレードした後に生成される /etc/neutron/neutron.conf.rpmnew ファイルを参照してください。


5.2. OpenStack Networking エージェントの ML2 への移行

OpenStack Networking 用の Open vSwitch (OVS) および LinuxBridge プラグインは、本リリースでは非推奨となりました。このため、以前のバージョンの OpenStack Networking デプロイメントでこれらのいずれかのプラグインを使用していた場合には、アップグレードの完了後にプラグインのデータベースを ML2 に移行する必要があります。本リリースには、この移行を実行することができる python スクリプト (neutron.db.migration.migrate_to_ml2) が含まれています。

警告

このスクリプトを使用して適用されたデータベースの変更は元に戻すことができません。このため、このスクリプトをテストまたは使用する前には、プラグインのデータベースをバックアップしておいてください。
データベースを ML2 に移行する前には、以下の手順に従って、あらかじめ ML2 の初期設定を行う必要があります。


手順 4. ML2 の初期設定

  1. openstack-neutron-ml2 パッケージをインストールします。

    # yum install openstack-neutron-ml2
  2. Networking を ML2 設定ファイル ml2_conf.ini にダイレクトするためのシンボリックリンクを作成します。

    # ln -s /etc/neutron/plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini
  3. ml2_conf.ini ファイルの [ml2] セクションに必要なプラグインの設定を追加します。


    表 7.  ML2 に必要なプラグイン設定

    設定オプション 説明
    mechanism_drivers neutron.ml2.type_drivers 名前空間から読み込むネットワークメカニズムドライバーのエントリポイントのコンマ区切りの順序付きリスト。サポートされている値は localflatvlangre、および vxlan です。
    tenant_network_types テナントネットワークとして割り当てる network_types のコンマ区切りの順序付きリスト。サポートされている値は、openvswitchlinuxbridge、および l2population です。
    type_drivers neutron.ml2.type_drivers 名前空間から読み込むネットワークタイプドライバーのエントリポイントのコンマ区切りリスト。サポートされている値は mechanism_drivers と同じです。
  4. 選択したメカニズムドライバーの必須設定を追加します。ネットワークタイプドライバー (type_drivers) 別の必須設定は、以下の表を参照してください。


    表 8.  ドライバータイプ別の必須設定

    type_driver セクション 設定オプション 説明
    flat [ml2_type_flat] flat_networks フラットなネットワークを作成可能な physical_network 名のリスト。フラットなネットワークに、任意の physical_network 名を割り当てられるようにするには、<literal>*</literal> を使用します。
    gre [ml2_type_gre] tunnel_id_ranges テナントネットワークの割り当てに使用できる GRE トンネリング ID の範囲を列挙した MIN:MAX トンネリングタプルのコンマ区切りリスト
    vlan [ml2_type_vlan] network_vlan_ranges VLAN プロバイダーとテナントネットワークが使用可能な物理ネットワーク名の一覧。この一覧に記載する各名前には、テナントネットワークへの割り当てに使用可能な VLAN タグの範囲を含めることができます。各名前の構文は、physical_network:vlan_min:vlan_max または physical_network の形式にすることができます。
    vxlan (全 2 中の 1) [ml2_type_vxlan] vni_ranges テナントネットワークの割り当てに使用できる VXLAN VNI ID の範囲を列挙した MIN:MAX タプルのコンマ区切りリスト
    vxlan (全 2 中の 2) [ml2_type_vxlan] vxlan_group VXLAN のマルチキャストグループ。未設定の場合には、VXLAN マルチキャストモードが無効になります。

注意

ML2 プラグインの設定についての詳しい説明が必要な場合は、「Modular Layer 2 (ML2) の概要」を参照してください。
ML2 の初期設定が完了したら、次に旧ネットワークエージェントを移行して、ネットワーク設定の更新を完了します。


手順 5. ML2 への移行

  1. neutron.db.migration.migrate_to_ml2 を使用してプラグインのデータベースを移行するには、以下のコマンドを実行します。
    # python -m neutron.db.migration.migrate_to_ml2 PLUGIN mysql://DBADMIN:DBPASS@DBHOST/DBNAME
    • PLUGIN は、使用していた元のプラグインに置き換えます。サポートされている値は linuxbridge および openvswitch です。
    • DBADMIN は、OpenStack Networking データベースの有効な管理ユーザー名 (例: neutron) に置き換えます。
    • DBPASSDBADMIN に対応するパスワードに置き換えます。
    • DBHOST は、OpenStack Networking データベースホストの IP アドレスに置き換えます。
    • DBNAME は OpenStack Networking データベースの名前に置き換えます。デフォルトでは、Packstack により ovs_neutron または neutron_linux_bridge という名前が選択したプラグインに応じて割り当てられます。

    注意

    Networking Service が使用する DBADMINDBPASSDBHOST、および DBNAME の実際の値は、/etc/neutron/neutron.conf[database] セクションに設定されます。具体的には、これらの値は以下の構文で connection の設定値に設定されます。
    connection = mysql://DBADMIN:DBPASS@DBHOST/DBNAME
    オプションのパラメーターには以下が含まれます。
    • --tunnel-type TUNNEL: プラグインがトンネリングを使用するように設定した場合には、このパラメーターを使用してトンネリングデータの移行も行ってください。TUNNEL は設定したトンネリングのタイプに置き換えます。サポートされている値は GRE および VXLAN です。
    • --vxlan-udp-port VXLANPORT: VXLAN トンネリングデータを移行する場合には、このパラメーターを使用して VXLAN トンネルが使用すべき UDP ポートを指定します (それに応じて VXLANPORT を置き換えてください)。このパラメーターを --tunnel-type VXLAN とともに使用しなかった場合には、デフォルトでポート 4789 が使用されます。
  2. プラグインデータベースの移行が完了したら、手動で ML2 プラグインを有効化します。そのためには、まず /etc/neutron/neutron.conf 設定ファイルを開いて、core_plugin パラメーターを ML2 プラグインに設定します。
    core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin
  3. 次に、L3 ルータープラグイン (neutron.services.l3_router.l3_router_plugin.L3RouterPlugin) を service_plugins パラメーターに追加します。
    service_plugins = neutron.services.firewall.fwaas_plugin.FirewallPlugin,neutron.services.l3_router.l3_router_plugin.L3RouterPlugin
    両パラメーターは /etc/neutron/neutron.confDEFAULT セクションにあります。設定ファイルを手動で設定する場合には、各行頭に空白文字が入らないようにしてください。空白文字が入ってしまうと解析エラーが生じて、サービスの正常な機能を妨げる可能性があります。

注意

ML2 プラグインの手動設定についての詳しい説明は、『OpenStack のデプロイ: 実習環境 (手動設定)』⁠「Networking Service プラグインの設定」のセクションを参照してください。


5.3. OpenStack Networking のアップグレードの最終段階

セクション 5.2「OpenStack Networking エージェントの ML2 への移行」に従ってネットワークエージェント ML2 に移行した後には、最終の設定変更を追加して Networking Service のアップグレードを完了することができます。


手順 6. アップグレードを完了するための OpenStack Networking Service の設定

  1. 全 Networking Service エージェントでハートビートを長く設定します。以下のコマンドを実行すると、本リリースの推奨値が設定されます。
    Networking コントローラーノードで以下のコマンドを実行します。
    # openstack-config --set /etc/neutron/neutron.conf DEFAULT agent_down_time 75
    次に、Networking Service エージェントをホストしている各ノードで以下のコマンドを実行します。
    # openstack-config --set /etc/neutron/neutron.conf agent report_interval 30
    上記の設定により、Networking Service は 30 秒ごとにエージェントが停止しているかどうかを確認するようになります。エージェントは、75 秒間到達不可の場合にのみ down 状態と宣言されます。
  2. dnsmasq プロセスを強制終了します (この操作は、DHCP エージェントが機能するために必要です)。
    # killall dnsmasq
  3. OpenStack Networking Service を再起動して、全設定を適用します。そのためには、Networking Service をホストしている全ノードで以下のコマンドを実行してください。
    # openstack-service start neutron


6. インスタンスへのコンソールアクセスを許可するためのファイウォール設定

一部のファイアウォール設定により、アップグレード後にコンソールへアクセスできなくなる可能性があります。そのような問題が発生した場合には、サービスノード上のファイアウォールを設定してコンソールアクセスを許可するようにする必要があります。そのためには以下の手順に従ってください。


手順 7. Compute Service トラフィックを許可するためのファイアウォール設定

  1. Compute Service ホストに root ユーザーとしてログインします。
  2. テキストエディターで /etc/sysconfig/iptables ファイルを開きます。
  3. このファイルに以下の行を追記して、コンソールトラフィックに使用するポートで、TCP トラフィックを許可する INPUT ルールを追加します。
    -A INPUT -p tcp --dport 5900:6900 -j ACCEPT
    新規ルールは、トラフィックを REJECT する INPUT ルールよりも前に記載する必要があります。
  4. /etc/sysconfig/iptables ファイルへの変更を保存します。
  5. iptables サービスを再起動して、変更を有効にします。
    # service iptables restart

注意

以下にあげる例のようなモジュールのアップロードに関するエラーは無視しても問題ありません。
# service iptables restart
   iptables: Setting chains to policy ACCEPT: mangle nat filte[  OK  ]
   iptables: Flushing firewall rules:                         [  OK  ]
   iptables: Unloading modules:  iptable_nat iptable_filter ip[FAILED]t iptable_filter ip_tables
   iptables: Applying firewall rules:                         [  OK  ]
ファイアウォールは、すでに使用中のモジュールは再読み込みしませんが、それによって、必要なファイアウォールルールが適用されなくなることはないはずです。


7. Dashboard の手動によるローカル設定

通常、Red Hat Enterprise Linux OpenStack Platform 5 のサービスは、旧デプロイメントの設定ファイルを使用して実行されます。ただし、Dashboard のファイルは 2 つのバージョン間で大幅に変更されるため、サービスを正常に機能させるには手動で設定する必要があります。


手順 8. アップグレードに向けた手動による Dashboard のローカル設定

  1. 既存の /etc/openstack-dashboard/local_settings ファイルをバックアップします。
  2. /etc/openstack-dashboard/local_settings の内容を local_settings.rpmnew の内容に置き換えます。
  3. バックアップした /etc/openstack-dashboard/local_settings から OPENSTACK_HOSTSECRET_KEY の値を使用して、新しい /etc/openstack-dashboard/local_settings ファイルを更新します。
    バックアップした /etc/openstack-dashboard/local_settings ファイルにその他の必要なデフォルト以外の設定がある場合には、それらの設定も新しい /etc/openstack-dashboard/local_settings ファイルにコピーしてください。
  4. Django 1.5 (またはそれ以降のバージョン) を実行している場合には、local_settings ファイルで ALLOWED_HOSTS が正しく設定されていることを確認する必要があります。ALLOWED_HOSTS には、Dashboard Service と接続する際に使用することのできるホスト名の一覧が記載されています。
    • ユーザーが "http://dashboard.example.com" を使用して Dashboard Service にアクセスする場合には、以下のように設定します。
      ALLOWED_HOSTS=['dashboard.example.com']
    • Dashboard Service をローカルシステムで実行している場合には、以下の設定を使用することができます。
      ALLOWED_HOSTS=['localhost']
    • ユーザーがホスト名の代わりに、またはホスト名に加えて IP アドレスを使用する場合の例は以下のようになります。
      ALLOWED_HOSTS=['dashboard.example.com', '192.168.122.200']

    注意

    ALLOWED_HOSTS の設定についての詳しい説明は Django のマニュアル を参照してください。
  5. Web サーバーを再起動して全変更を適用します。
    # service httpd restart


8. データベースサーバーのアップグレード

Red Hat Enterprise Linux OpenStack Platform 5.0 より、Red Hat Enterprise Linux OpenStack Platform のサポート対象データベースサーバーは MariaDB となりました。Red Hat Enterprise Linux OpenStack Platform 4.0 から Red Hat Enterprise Linux OpenStack Platform 5.0 にアップグレードする際に、データベースサーバーが Red Hat Enterprise Linux 6.5 以前のバージョンを実行するシステムにインストールされている場合には、データベースサーバーを MySQL から MariaDB に手動でアップグレードする必要があります。

重要

以下の手順を実行する前に、データベースサーバーがインストールされているマシンで Red Hat OpenStack 4.0 チャンネルを無効にし、かつ Red Hat OpenStack 5.0 for Server 6 チャンネルを有効にする必要があります。


手順 9. データベースサーバーのアップグレード

  1. Red Hat Enterprise Linux OpenStack Platform 環境の各ノードから、データベースサーバーにアクセスする Red Hat Enterprise Linux OpenStack Platform サービスをすべて停止します。
  2. データベースサーバーがインストールされているシステムでデータベースサーバーを停止します。
    # service mysqld stop
  3. MySQL サーバーのパッケージを削除します。
    # yum -y remove mysql-server
  4. 全パッケージを最新の状態にします。
    # yum -y update
  5. MariaDB サーバーのパッケージをインストールします。
    # yum -y install mariadb-galera-server
  6. データベースサーバーがブート時に起動するように設定します。
    # chkconfig mysqld on
  7. データベースサーバーを起動します。
    # service mysqld start
  8. 内部 mysql データベーススキーマをアップグレードします。プロンプトが表示されたら管理ユーザーのパスワードを入力します。
    # mysql_upgrade -u root -p
  9. Red Hat Enterprise Linux OpenStack Platform 環境の各ノードから、データベースサーバーにアクセスする Red Hat Enterprise Linux OpenStack Platform サービスをすべて起動します。
データベースサーバーを MySQL から MariaDB にアップグレードしました。以前データベースサーバーとの対話に使用していたコマンドはすべてそのまま使用することができます。


9. システムのアップグレードの最終段階

サービスのアップグレードをすべて完了した後には、全システムで完全なパッケージアップグレードを行う必要があります。
  1. システムのアップグレード
    # yum upgrade
    このコマンドにより、全システム上のクライアントパッケージ (例: python-keystoneclientpython-glanceclient などのパッケージ) がアップグレードされるのに加えて、通常は全サポート対象ツールが適切なバージョンとなります。
  2. Compute Service を再起動します (再起動をしなかった場合には、Image クライアントパッケージのアップグレードが原因でエラーが発生します)。

    # service openstack-nova-compute restart
  3. このコマンドを実行することによってシステムに新規カーネルがインストールされた場合には、そのカーネルを有効にするためのリブートをその後にスケジュールしたほうがよいでしょう。


10. RabbitMQ と QPid

RabbitMQ は、Red Hat Enteprise Linux OpenStack Platform 5 の推奨メッセージブローカーとなりました。このため、アップグレードの後に RabbitMQ への移行を行うことをお勧めします。
その手順については https://access.redhat.com/articles/1167113 を参照してください。