Translated message

A translation of this page exists in English.

全サービスを同時に更新する方式による OpenStack のアップグレード

更新 -


1. 概要

本記事で解説する OpenStack のアップグレード方法では、OpenStack サービスを同時に無効化してからアップグレードを実行し、アップグレードプロセスの完了後に全サービスを有効化する必要があります。この方法は、Red Hat Enterprise Linux OpenStack Platform 5 へのアップグレード方法の中で最も簡単な方法です。
この方法では、すべての OpenStack サービスが停止し、オーケストレーションは一切必要ありません。Red Hat Enterprise Linux バージョン (6.4 から 6.5 へ) のアップグレードの必要がない場合には、仮想マシンのワークロードの稼働状態を維持することができます。
大規模な環境の場合は、このアップグレードにより、データベーススキーマのアップグレード完了までのダウンタイムが長時間に及ぶ可能性があります。あらかじめテスト環境でアップグレード手順のリハーサルを実行し、特定の時間帯にダウンタイムを計画してアップグレードを行うことによって、ダウンタイムによる影響を軽減することができます。

注意

本記事に記載する手順は、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. 全 OpenStack サービスの同時アップグレード

一括でアップグレードを行うには、各ホストで以下の手順を実行してください。


手順 1. ホスト上の OpenStack コンポーネントのアップグレード

  1. openstack-utils パッケージが確実にインストールされていることを確認します。
    # yum install openstack-utils
  2. 全ノードで OpenStack サービスをすべて停止します。このステップは、サービスがどのようにノードに分散されているかによって異なります。
    1 つのノードで実行されている OpenStack サービスをすべて停止するには、そのノードにログインして以下のコマンドを実行します。
    # openstack-service stop
  3. 全パッケージの完全なアップグレードを実行してから、Identity Service 内の期限切れトークンをフラッシュします (データベースの同期の所要時間が短縮される可能性があります)。
    # yum upgrade
    # keystone-manage token_flush
  4. データベースを使用する各サービスのデータベーススキーマをアップグレードします。この操作を行うには、サービスをホストしているノードにログインして以下のコマンドを実行します。
    # openstack-db --service SERVICENAME --update
    SERVICENAME は、サービスのプロジェクト名に置き換えます。たとえば、Idenitity Service のデータベーススキーマをアップグレードするためのコマンドは以下のようになります。
    # openstack-db --service keystone --update


    表 6.  データベースを使用する各 OpenStack サービスのプロジェクト名

    サービス プロジェクト名
    Identity keystone
    Block Storage cinder
    Image Service glance
    Compute nova
    Networking neutron
    Orchestration heat
    Dashboard horizon
  5. 上記の操作によって生成された設定ファイルを確認します。アップグレードされたパッケージには、Red Hat Enterprise Linux OpenStack Platform 5 バージョンのサービスに適した .rpmnew ファイルがインストールされているはずです。


4. 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 です。


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

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


手順 2. 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 ファイルを参照してください。


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

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

警告

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


手順 3. 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 の初期設定が完了したら、次に旧ネットワークエージェントを移行して、ネットワーク設定の更新を完了します。


手順 4. 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 とともに使用しなかった場合、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 プラグインの設定」のセクションを参照してください。


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

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


手順 5. アップグレードを完了するための 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


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

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


手順 6. 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  ]
ファイアウォールは、すでに使用中のモジュールは再読み込みしませんが、それによって、必要なファイアウォールルールが適用されなくなることはないはずです。


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

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


手順 7. アップグレードに向けた手動による 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


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

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 チャンネルを有効にする必要があります。


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

  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 にアップグレードしました。以前データベースサーバーとの対話に使用していたコマンドはすべてそのまま使用することができます。


11. OpenStack の再起動

パッケージのアップグレードで再起動が必要な場合には (例: アップグレードの一環として新規カーネルがインストールされた場合など)、OpenStack サービスが無効な状態のうちに、影響を受けたホストを再起動してください。
OpenStack サービスを再起動するには、各ノードで以下のコマンドを実行します。
# openstack-service start


12. RabbitMQ と QPid

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

Comments