目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Enterprise Storage 7.1マニュアル / 導入ガイド / 古いリリースからのアップグレード / SUSE Enterprise Storage 6から7.1へのアップグレード
適用項目 SUSE Enterprise Storage 7.1

10 SUSE Enterprise Storage 6から7.1へのアップグレード

 

この章では、SUSE Enterprise Storage 6をバージョン7.1にアップグレードする手順について説明します。

アップグレードには次のタスクが含まれます。

  • Ceph NautilusからPacificへのアップグレード。

  • RPMパッケージを介してCephのインストールと実行を行う環境から、コンテナ内で実行する環境への切り替え。

  • DeepSeaを完全に消去し、ceph-saltとcephadmで置き換え。

警告
警告

この章のアップグレード情報は、DeepSeaからcephadmへのアップグレードに「のみ」適用されます。SUSE CaaS Platform上にSUSE Enterprise Storageを展開する場合は、この章の手順を使用しないでください。

重要
重要

6より古いバージョンのSUSE Enterprise Storageからのアップグレードはサポートされていません。まず、最新バージョンのSUSE Enterprise Storage 6にアップグレードしてから、この章の手順を実行する必要があります。

10.1 アップグレード実行前の確認事項

 

アップグレードの開始前に、必ず以下のタスクを完了させてください。このタスクはSUSE Enterprise Storage 6のライフタイムのどの時点でも実行できます。

10.1.1 考慮すべきポイント

 

アップグレードの前に以下のセクションを熟読して、実行する必要があるすべてのタスクを十分に理解してください。

  • リリースノートの確認.リリースノートには、旧リリースのSUSE Enterprise Storageからの変更点に関する追加情報が記載されています。リリースノートを参照して以下を確認します。

    • 使用しているハードウェアに特別な配慮が必要かどうか

    • 使用しているソフトウェアパッケージに大幅な変更があるかどうか

    • インストールのために特別な注意が必要かどうか

    リリースノートには、マニュアルに記載できなかった情報が記載されています。また、既知の問題に関する注意も記載されています。

    SES 7.1のリリースノートはhttps://www.suse.com/releasenotes/を参照してください。

    release-notes-sesをSES 7.1リポジトリからインストールすると、ローカルディレクトリ/usr/share/doc/release-notesにリリースノートが置かれます。https://www.suse.com/releasenotes/でオンラインのリリースノートも利用できます。

  • パートII「Cephクラスタの展開」を参照して、ceph-saltとCephオーケストレータについて理解してください。特に、サービス仕様に記載されている情報は重要です。

  • クラスタのアップグレードには長い時間がかかることがあります。所要時間は、1台のマシンのアップグレード時間xクラスタノード数です。

  • 最初にSalt Masterをアップグレードし、その後DeepSeaをceph-saltとcephadmに置き換える必要があります。少なくとも、すべてのCeph Managerがアップグレードされるまで、cephadmオーケストレータモジュールの使用を開始することはできません。

  • NautilusのRPMを使用する環境からPacificのコンテナ環境へのアップグレードは、一度に行う必要があります。これは、一度に1つのデーモンではなく、ノード全体を一度にアップグレードすることを意味します。

  • コアサービス(MON、MGR、OSD)のアップグレードは、順序立てて進めます。アップグレードの間も、各サービスは利用可能です。ゲートウェイサービス(メタデータサーバ、Object Gateway、NFS Ganesha、iSCSI Gateway)については、コアサービスのアップグレード後に再展開する必要があります。次に示すサービスごとに、ある程度のダウンタイムが発生します。

    • 重要
      重要

      メタデータサーバとObject Gatewaysについては、ノードをSUSE Linux Enterprise Server 15 SP1からSUSE Linux Enterprise Server 15 SP3にアップグレードする際にダウンします。ダウン状態はアップグレード手続きの最後にサービスが再展開されるまで続きます。特に注意が必要なのは、メタデータサーバとObject GatewaysをMON、MGR、OSDなどと同じ場所に配置している場合です。この場合、クラスタのアップグレードが完了するまでこれらのサービスを利用できない可能性があります。これが問題となる場合は、これらのサービスをアップグレード前に別のノードに分けて展開することを検討してください。そうすれば、ダウンタイムは最小限で済みます。この場合、ダウンする期間はクラスタ全体のアップグレード中ではなく、ゲートウェイノードのアップグレード中になります。

    • NFS GaneshaとiSCSI Gatewaysについては、SUSE Linux Enterprise Server 15 SP1からSUSE Linux Enterprise Server 15 SP3へアップグレードする手続きの中で、ノードがリブートしている間にダウンします。また、各サービスがコンテナ化モードで再展開する際にも一時的にダウンします。

10.1.2 クラスタ設定とデータのバックアップ

 

SUSE Enterprise Storage 7.1へのアップグレードを開始する前に、すべてのクラスタ設定とデータをバックアップすることを強くお勧めします。すべてのデータをバックアップする方法については、https://documentation.suse.com/ses/6/single-html/ses-admin/#cha-deployment-backupを参照してください。

10.1.3 前回のアップグレード手順の確認

 

以前にバージョン5からアップグレードした場合は、バージョン6へのアップグレードが正常に完了していることを確認します。

/srv/salt/ceph/configuration/files/ceph.conf.importというファイルが存在することを確認します。

このファイルはSUSE Enterprise Storage 5から6へのアップグレード中に、engulfプロセスにより作成されます。configuration_init: default-importオプションは/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.ymlに設定されます。

configuration_initがまだdefault-importに設定されている場合、クラスタはその設定ファイルとしてceph.conf.importを使用しています。これは、/srv/salt/ceph/configuration/files/ceph.conf.d/にあるファイルからコンパイルされるDeepSeaのデフォルトのceph.confではありません。

したがって、ceph.conf.importでカスタム設定を調べ、可能であれば、/srv/salt/ceph/configuration/files/ceph.conf.d/にあるファイルのいずれかに設定を移動する必要があります。

その後、/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.ymlからconfiguration_init: default-import行を削除してください。

10.1.4 クラスタノードのアップデートとクラスタのヘルスの確認

 

SUSE Linux Enterprise Server 15 SP1とSUSE Enterprise Storage 6のすべての最新のアップデートがすべてのクラスタノードに適用されていることを確認してください。 

# zypper refresh && zypper patch
ヒント
ヒント

クラスタノードの更新の詳細については、https://documentation.suse.com/ses/6/html/ses-all/storage-salt-cluster.html#deepsea-rolling-updatesを参照してください。

更新が適用されたら、Salt Masterを再起動し、新しいSaltモジュールを同期して、クラスタヘルスを確認します。 

root@master # systemctl restart salt-master.service
root@master # salt '*' saltutil.sync_all
cephuser@adm > ceph -s

10.1.4.1 非セキュアクライアントの無効化

 

Nautilus v14.2.20以降、非セキュアクライアントがクラスタに参加できることを通知する新しいヘルス警告が導入されました。この警告はデフォルトで「オン」になっています。Cephダッシュボードには、クラスタがHEALTH_WARNステータスで表示されます。コマンドラインは、クラスタのステータスを次のように確認します。 

 cephuser@adm > ceph status
 cluster:
   id:     3fe8b35a-689f-4970-819d-0e6b11f6707c
   health: HEALTH_WARN
   mons are allowing insecure global_id reclaim
 [...]

この警告は、Ceph Monitorが、パッチが適用されていない古いクライアントがクラスタに接続することを引き続き許可していることを意味します。これにより、クラスタのアップグレード中も既存のクライアントが引き続き接続できるようになりますが、対処する必要のある問題があることを警告します。クラスタとすべてのクライアントが最新バージョンのCephにアップグレードされたら、次のコマンドを実行して、パッチが適用されていないクライアントを禁止します。 

cephuser@adm > ceph config set mon auth_allow_insecure_global_id_reclaim false

10.1.5 ソフトウェアリポジトリとコンテナイメージへのアクセス確認

 

各クラスタノードがSUSE Linux Enterprise Server 15 SP3とSUSE Enterprise Storage 7.1のソフトウェアリポジトリとコンテナイメージのリポジトリにアクセスできることを確認してください。

10.1.5.1 ソフトウェアリポジトリ

 

すべてのノードがSCCに登録されている場合、zypper migrationコマンドによるアップグレードが可能です。詳細については、https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-upgrade-online.html#sec-upgrade-online-zypperを参照してください。

ノードがSCCに登録されていない場合は、すべての既存のソフトウェアリポジトリを無効化し、次に示す各エクステンションにPoolリポジトリとUpdatesリポジトリの両方を追加してください。

  • SLE-Product-SLES/15-SP3

  • SLE-Module-Basesystem/15-SP3

  • SLE-Module-Server-Applications/15-SP3

  • SUSE-Enterprise-Storage-7.1

10.1.5.2 コンテナイメージ

 

すべてのクラスタノードはコンテナイメージのレジストリにアクセスできる必要があります。多くの場合、registry.suse.comのパブリックSUSEレジストリを使用します。必要なイメージは次のとおりです。

  • registry.suse.com/ses/7.1/ceph/ceph

  • registry.suse.com/ses/7.1/ceph/grafana

  • registry.suse.com/ses/7.1/ceph/prometheus-server

  • registry.suse.com/ses/7.1/ceph/prometheus-node-exporter

  • registry.suse.com/ses/7.1/ceph/prometheus-alertmanager

もしくは、たとえばエアギャップ環境で展開したい場合などは、ローカルレジストリを設定し、正常なコンテナイメージのセットが利用できることを確認してください。ローカルなコンテナイメージのレジストリを設定する方法の詳細については、7.2.10項 「コンテナレジストリの使用」を参照してください。

10.2 Salt Masterのアップグレード

 

Salt Masterのアップグレードプロセスを以下に示します。

  1. 基礎となるOSをSUSE Linux Enterprise Server 15 SP3にアップグレードします。

    • すべてのノードがSCCに登録されているクラスタの場合は、zypper migrationコマンドを実行します。

    • 手動で割り当てられたソフトウェアリポジトリを含むクラスタの場合は、zypper dupコマンドを実行した後、rebootコマンドを実行します。

  2. 誤って使用しないように、DeepSeaステージを無効化します。/srv/pillar/ceph/stack/global.ymlに次の内容を追加します。 

    stage_prep: disabled
stage_discovery: disabled
stage_configure: disabled
stage_deploy: disabled
stage_services: disabled
stage_remove: disabled

    ファイルを保存し、変更を適用します。 

    root@master # salt '*' saltutil.pillar_refresh

  3. registry.suse.comのコンテナイメージではなく、ローカル環境に設定したレジストリを使用している場合は、/srv/pillar/ceph/stack/global.ymlを編集して、DeepSeaがどのCephコンテナイメージとレジストリを使用するか指定します。たとえば、192.168.121.1:5000/my/ceph/imageを使用する場合は、次に示す内容を追加します。 

    ses7_container_image: 192.168.121.1:5000/my/ceph/image
ses7_container_registries:
  - location: 192.168.121.1:5000

    レジストリの認証情報を指定する必要がある場合は、ses7_container_registry_auth:ブロックを追加します。次に例を示します。 

    ses7_container_image: 192.168.121.1:5000/my/ceph/image
ses7_container_registries:
  - location: 192.168.121.1:5000
ses7_container_registry_auth:
  registry: 192.168.121.1:5000
  username: USER_NAME
  password: PASSWORD

    ファイルを保存し、変更を適用します。 

    root@master # salt '*' saltutil.refresh_pillar

  4. 既存の設定を取り込みます。 

    cephuser@adm > ceph config assimilate-conf -i /etc/ceph/ceph.conf

  5. アップグレードステータスを確認します。クラスタの設定によって、出力は異なる場合があります。 

    root@master # salt-run upgrade.status
The newest installed software versions are:
 ceph: ceph version 16.2.7-640-gceb23c7491b (ceb23c7491bd96ab7956111374219a4cdcf6f8f4) pacific (stable)
 os: SUSE Linux Enterprise Server 15 SP3

Nodes running these software versions:
 admin.ceph (assigned roles: master, prometheus, grafana)

Nodes running older software versions must be upgraded in the following order:
 1: mon1.ceph (assigned roles: admin, mon, mgr)
 2: mon2.ceph (assigned roles: admin, mon, mgr)
 3: mon3.ceph (assigned roles: admin, mon, mgr)
 4: data4.ceph (assigned roles: storage, mds)
 5: data1.ceph (assigned roles: storage)
 6: data2.ceph (assigned roles: storage)
 7: data3.ceph (assigned roles: storage)
 8: data5.ceph (assigned roles: storage, rgw)

10.3 MON、MGR、OSDノードのアップグレード

 

Ceph Monitor、Ceph Manager、OSDのノードを一度にアップグレードしてください。サービスごとに、次の手順に従います。

  1. OSDノードを採用する前に、OMAPデータのアカウンティングを改善するために、OSDノードのフォーマット変換を実行する必要があります。フォーマット変換を実行するには、管理ノードで次のコマンドを実行します。 

    cephuser@adm > ceph config set osd bluestore_fsck_quick_fix_on_mount true

    OSDノードは、採用が完了すると自動的に変換されます。

    注記
    注記

    関連するハードディスクに含まれるOMAPデータの量によっては、変換に数分から数時間かかる場合があります。詳細については、https://docs.ceph.com/en/latest/releases/pacific/#upgrading-non-cephadm-clustersを参照してください。

  2. アップグレードするノードがOSDノードの場合、アップグレード中にOSDがoutとマークされることを避けるため、次のコマンドを実行します。 

    cephuser@adm > ceph osd add-noout SHORT_NODE_NAME

    SHORT_NODE_NAMEはノードの略称で置き換えます。この名称がceph osd treeコマンドの出力に表示されます。たとえば、以下の入力はホスト名の略称がses-min1とses-min2の場合です。 

    root@master # ceph osd tree
ID   CLASS  WEIGHT   TYPE NAME       STATUS  REWEIGHT  PRI-AFF
 -1         0.60405  root default
-11         0.11691      host ses-min1
  4    hdd  0.01949          osd.4       up   1.00000  1.00000
  9    hdd  0.01949          osd.9       up   1.00000  1.00000
 13    hdd  0.01949          osd.13      up   1.00000  1.00000
[...]
 -5         0.11691      host ses-min2
  2    hdd  0.01949          osd.2       up   1.00000  1.00000
  5    hdd  0.01949          osd.5       up   1.00000  1.00000
[...]

  3. 基礎となるOSをSUSE Linux Enterprise Server 15 SP3にアップグレードします。

    • クラスタのノードがすべてSCCに登録されている場合は、zypper migrationを実行します。

    • 手動で割り当てられたソフトウェアリポジトリを含むクラスタノードの場合は、zypper dupを実行した後、rebootコマンドを実行します。

  4. ノードの再起動後、Salt Master上で以下のコマンドを実行して、ノード上のすべての既存のMONデーモン、MGRデーモン、OSDデーモンをコンテナ化します。 

    root@master # salt MINION_ID state.apply ceph.upgrade.ses7.adopt

    MINION_IDはアップグレードするミニオンのIDで置き換えます。Salt Master上でsalt-key -Lコマンドを実行することで、ミニオンIDのリストを取得できます。

    ヒント
    ヒント

    「導入」の進捗状況を確認するには、Cephダッシュボードを確認するか、Salt Master上で以下のコマンドのいずれかを実行します。 

    root@master # ceph status
root@master # ceph versions
root@master # salt-run upgrade.status

  5. OSDノードをアップグレード中の場合、導入が正常に完了した後でnooutフラグの設定を解除してください。 

    cephuser@adm > ceph osd rm-noout SHORT_NODE_NAME

10.4 ゲートウェイノードのアップグレード

 

次に、個別のゲートウェイノード(Sambaゲートウェイ、メタデータサーバ、Object Gateway、NFS Ganesha、iSCSI Gateway)をアップグレードしてください。各ノードに基礎となるOSをSUSE Linux Enterprise Server 15 SP3にアップグレードしてください。

  • クラスタのノードがすべてSUSE Customer Centerに登録されている場合は、zypper migrationコマンドを実行してください。

  • 手動で割り当てられたソフトウェアリポジトリを含むクラスタノードの場合は、zypper dupコマンドを実行した後、rebootコマンドを実行してください。

この手順はクラスタの一部であるが、まだ役割を割り当てていないノードにも適用します(割り当てたかどうか不明な場合は、Salt Master上でsalt-key -Lコマンドを実行してホストのリストを取得し、salt-run upgrade.statusコマンドの出力と比較してください)。

クラスタ内のすべてのノードでOSがアップグレードされたら、次の手順はceph-saltパッケージをインストールしてクラスタ設定を適用することです。ゲートウェイサービスそのものは、アップグレード処理の最後にコンテナ化モードで再展開されます。

注記
注記

メタデータサーバとObject Gatewayサービスは、SUSE Linux Enterprise Server 15 SP3へのアップグレードが始まると利用できなくなります。この状態はアップグレード処理の最後にサービスが再展開されるまで続きます。

10.5 ceph-saltのインストールと、クラスタ設定の適用

 

ceph-saltのインストールとクラスタ設定の適用を開始する前に、次のコマンドを実行してクラスタとアップグレードステータスを確認してください。 

root@master # ceph status
root@master # ceph versions
root@master # salt-run upgrade.status

  1. DeepSeaが作成したrbd_exporterとrgw_exporterというcron jobを削除します。Salt Master上でrootとしてcrontab -eコマンドを実行し、crontabを編集します。以下の項目が存在する場合は削除します。 

    # SALT_CRON_IDENTIFIER:deepsea rbd_exporter cron job
*/5 * * * * /var/lib/prometheus/node-exporter/rbd.sh > \
 /var/lib/prometheus/node-exporter/rbd.prom 2> /dev/null
# SALT_CRON_IDENTIFIER:Prometheus rgw_exporter cron job
*/5 * * * * /var/lib/prometheus/node-exporter/ceph_rgw.py > \
 /var/lib/prometheus/node-exporter/ceph_rgw.prom 2> /dev/null

  2. 次のコマンドを実行して、DeepSeaからクラスタ設定をエクスポートします。 

    root@master # salt-run upgrade.ceph_salt_config > ceph-salt-config.json
root@master # salt-run upgrade.generate_service_specs > specs.yaml

  3. DeepSeaをアンインストールし、ceph-saltをSalt Masterにインストールします。 

    root@master # zypper remove 'deepsea*'
root@master # zypper install ceph-salt

  4. Salt Masterを再起動し、Saltモジュールを同期します。 

    root@master # systemctl restart salt-master.service
root@master # salt \* saltutil.sync_all

  5. DeepSeaのクラスタ設定をceph-saltにインポートします。 

    root@master # ceph-salt import ceph-salt-config.json

  6. クラスタノード通信用のSSHキーを作成します。 

    root@master # ceph-salt config /ssh generate
    ヒント
    ヒント

    DeepSeaからクラスタ設定がインポートされたことを確認し、欠落している可能性のあるオプションを指定します。 

    root@master # ceph-salt config ls

    クラスタ設定の詳細については7.2項 「クラスタプロパティの設定」を参照してください。

  7. 設定を適用し、cephadmを有効化します。 

    root@master # ceph-salt apply

  8. ローカルのコンテナレジストリURLやアクセス資格情報を提供する必要がある場合は、7.2.10項 「コンテナレジストリの使用」の手順に従ってください。

  9. registry.suse.comのコンテナイメージではなく、ローカルに設定したレジストリを使う場合は、次のコマンドを実行してどのコンテナイメージを使用するかをCephに伝えます。 

    root@master # ceph config set global container_image IMAGE_NAME

    例: 

    root@master # ceph config set global container_image 192.168.121.1:5000/my/ceph/image

  10. SUSE Enterprise Storage 6のceph-crashデーモンを停止し、無効化します。これらのデーモンの新しくコンテナ化された形式は、後ほど自動的に起動します。 

    root@master # salt '*' service.stop ceph-crash
root@master # salt '*' service.disable ceph-crash

10.6 監視スタックのアップグレードと導入

 

以下の手順によって、監視スタックのすべてのコンポーネントを導入します(詳細については第16章 「監視とアラート」を参照してください)。

  1. オーケストレータを一時停止します。 

    cephuser@adm > ceph orch pause

  2. Prometheus、Grafana、Alertmanagerがどのノードで実行されている場合でも(デフォルトではSalt Masterノード)、以下のコマンドを実行します。 

    cephuser@adm > cephadm adopt --style=legacy --name prometheus.$(hostname)
cephuser@adm > cephadm adopt --style=legacy --name alertmanager.$(hostname)
cephuser@adm > cephadm adopt --style=legacy --name grafana.$(hostname)
    ヒント
    ヒント

    registry.suse.comのデフォルトコンテナイメージレジストリを実行していない場合は、各コマンドで使用するイメージを指定する必要があります。以下に例を示します。 

    cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7.1/ceph/prometheus-server:2.32.1 \
  adopt --style=legacy --name prometheus.$(hostname)
cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7.1/ceph/prometheus-alertmanager:0.21.0 \
  adopt --style=legacy --name alertmanager.$(hostname)
cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7.1/ceph/grafana:7.5.12 \
 adopt --style=legacy --name grafana.$(hostname)

    必要なコンテナイメージと各バージョンを16.1項 「カスタムイメージまたはローカルイメージの設定」に一覧にします。

  3. 「すべての」ノードからNode-Exporterを削除します。Node-Exporterのマイグレーションは不要です。specs.yamlファイルが適用された際にコンテナとして再インストールされます。 

    > sudo zypper rm golang-github-prometheus-node_exporter

    または、管理ノードでSaltを使用して、すべてのノードからNode-Exporterを同時に削除することもできます。 

    root@master # salt '*' pkg.remove golang-github-prometheus-node_exporter

  4. DeepSeaからエクスポートしておいたサービス仕様を適用します。 

    cephuser@adm > ceph orch apply -i specs.yaml
    ヒント
    ヒント

    デフォルトのコンテナイメージレジストリregistry.suse.comを実行していないが、ローカルコンテナレジストリを実行している場合は、Node-Exporterを展開する前に、Node-Exporterの展開にローカルレジストリのコンテナイメージを使用するようにcephadmを設定します。そうでない場合は、この手順を安全にスキップして、次の警告を無視してもかまいません。 

    cephuser@adm > ceph config set mgr mgr/cephadm/container_image_node_exporter QUALIFIED_IMAGE_PATH

    サービスを監視するすべてのコンテナイメージが、Node-Exporterのものだけでなく、ローカルレジストリをポイントしていることを確認します。この手順は、Node-Exporterに対してのみ行う必要がありますが、この時点でローカルレジストリをポイントするようにcephadmのすべてのモニタリングコンテナイメージを設定することをお勧めします。

    このように設定しないと、モニタリングサービスの新規展開と再展開では、デフォルトのcephadm設定が使用され、サービスを展開できなくなったり(エアギャップ環境の展開の場合)、バージョンが混在したサービスが展開されたりする可能性があります。

    ローカルレジストリのコンテナイメージを使用するようにcephadmを設定する方法については、16.1項 「カスタムイメージまたはローカルイメージの設定」を参照してください。

  5. オーケストレータを再開します。 

    cephuser@adm > ceph orch resume

10.7 ゲートウェイサービスの再展開

 

10.7.1 Object Gatewayのアップグレード

 

SUSE Enterprise Storage 7.1においてObject Gatewayは常にレルムに設定されます。これにより、将来的なマルチサイトが可能になります(詳細については21.13項 「マルチサイトObject Gateway」を参照してください)。SUSE Enterprise Storage 6でシングルサイトのObject Gateway設定を使用している場合は、以下の手順に従ってレルムを追加してください。マルチサイト機能を使う予定がない場合は、レルム、ゾーングループ、ゾーンの名前にdefaultを使用してもかまいません。

  1. 新しいレルムを作成します。 

    cephuser@adm > radosgw-admin realm create --rgw-realm=REALM_NAME --default

  2. 必要に応じて、デフォルトのゾーンとゾーングループの名前を変更します。 

    cephuser@adm > radosgw-admin zonegroup rename \
 --rgw-zonegroup default \
 --zonegroup-new-name=ZONEGROUP_NAME
cephuser@adm > radosgw-admin zone rename \
 --rgw-zone default \
 --zone-new-name ZONE_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME

  3. マスターゾーングループを設定します。 

    cephuser@adm > radosgw-admin zonegroup modify \
 --rgw-realm=REALM_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME \
 --endpoints http://RGW.EXAMPLE.COM:80 \
 --master --default

  4. マスターゾーンを設定します。このとき、systemフラグが有効なObject GatewayユーザのACCESS_KEYとSECRET_KEYが必要になります。通常はadminユーザが該当します。ACCESS_KEYとSECRET_KEYを取得するには、radosgw-admin user info --uid admin --rgw-zone=ZONE_NAMEを実行します。 

    cephuser@adm > radosgw-admin zone modify \
 --rgw-realm=REALM_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME \
 --rgw-zone=ZONE_NAME \
 --endpoints http://RGW.EXAMPLE.COM:80 \
 --access-key=ACCESS_KEY \
 --secret=SECRET_KEY \
 --master --default

  5. アップデートされた設定をコミットします。 

    cephuser@adm > radosgw-admin period update --commit

Object Gatewayサービスをコンテナ化するには、8.3.4項 「Object Gatewayの展開」に記載されている仕様ファイルを作成し、適用します。 

cephuser@adm > ceph orch apply -i RGW.yml

10.7.2 NFS Ganeshaのアップグレード

 
重要
重要

NFS Ganeshaは、NFSバージョン4.1以降をサポートしています。NFSバージョン3はサポートしていません。

Ceph Nautilusを実行する既存のNFS Ganeshaサービスから、Ceph Octopusを実行するNFS Ganeshaコンテナにマイグレートする方法を次で説明します。

警告
警告

以下の情報は、コアとなるCephサービスのアップグレードに成功していることを前提としたものです。

NFS Ganeshaはデーモンごとの追加設定を保存し、RADOSプールに設定をエクスポートします。設定済みのRADOSプールは、ganesha.confファイルのRADOS_URLSブロックのwatch_url行で確認できます。デフォルトでは、このプールはganesha_configと名付けられます。

マイグレーションを試みる前に、RADOSプールにあるエクスポートおよびデーモン設定オブジェクトのコピーを作成することを強くお勧めします。設定されたRADOSプールを見つけるには、次のコマンドを実行します。 

cephuser@adm > grep -A5 RADOS_URLS /etc/ganesha/ganesha.conf

RADOSプールの内容を一覧にするには、次のコマンドを実行します。 

cephuser@adm > rados --pool ganesha_config --namespace ganesha ls | sort
  conf-node3
  export-1
  export-2
  export-3
  export-4

RADOSオブジェクトをコピーするには、次のコマンドを実行します。 

cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > OBJS=$(rados $RADOS_ARGS ls)
cephuser@adm > for obj in $OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 40K
drwxr-xr-x 2 root root 4.0K Sep 8 03:30 .
drwx------ 9 root root 4.0K Sep 8 03:23 ..
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node3
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-1
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-2
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-3
-rw-r--r-- 1 root root 358 Sep 8 03:30 export-4

ノードごとに既存のNFS Ganeshaサービスを停止して、cephadmが管理するコンテナに置き換える必要があります。

  1. 既存のNFS Ganeshaサービスを停止および無効化します。 

    cephuser@adm > systemctl stop nfs-ganesha
cephuser@adm > systemctl disable nfs-ganesha

  2. 既存のNFS Ganeshaサービスが停止すると、cephadmを用いてコンテナ内に新しいサービスを展開できます。そのためには、service_idを記述したサービス仕様を作成する必要があります。このIDはこの新しいNFSクラスタの特定、配置仕様にホストとして記載された、マイグレーション先ノードのホスト名の特定、設定済みNFSエクスポートオブジェクトを含むRADOSプールとネームスペースの特定に使用されます。次に例を示します。 

    service_type: nfs
service_id: SERVICE_ID
placement:
  hosts:
  - node2
  pool: ganesha_config
  namespace: ganesha

    配置仕様の作成の詳細については、8.2項 「サービス仕様と配置仕様」を参照してください。

  3. 配置仕様を適用します。 

    cephuser@adm > ceph orch apply -i FILENAME.yaml

  4. ホストでNFS Ganeshaデーモンが実行されていることを確認します。 

    cephuser@adm > ceph orch ps --daemon_type nfs
NAME           HOST   STATUS         REFRESHED  AGE  VERSION  IMAGE NAME                                IMAGE ID      CONTAINER ID
nfs.foo.node2  node2  running (26m)  8m ago     27m  3.3      registry.suse.com/ses/7.1/ceph/ceph:latest  8b4be7c42abd  c8b75d7c8f0d

  5. NFS Ganeshaノードごとに、これらの手順を繰り返します。ノードごとに別々のサービス仕様を作成する必要はありません。各ノードのホスト名を既存のNFSサービス仕様に追加し、再適用すれば十分です。

既存のエクスポートは次の2つの方法でマイグレートできます。

  • Cephダッシュボードを使用して、手動で再作成と再適用を行う方法。

  • デーモンごとのRADOSオブジェクトの内容を、新しく作成されたNFS Ganesha共通設定に手動でコピーする方法。

手順 10.1: エクスポートをNFS Ganesha共通設定ファイルに手動コピーする
 

  1. デーモンごとのRADOSオブジェクトのリストを確認します。 

    cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > DAEMON_OBJS=$(rados $RADOS_ARGS ls | grep 'conf-')

  2. デーモンごとのRADOSオブジェクトのコピーを作成します。 

    cephuser@adm > for obj in $DAEMON_OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 20K
drwxr-xr-x 2 root root 4.0K Sep 8 16:51 .
drwxr-xr-x 3 root root 4.0K Sep 8 16:47 ..
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-nfs.SERVICE_ID
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node3

  3. ソートとマージを行って、エクスポートを単一のリストにします。 

    cephuser@adm > cat conf-* | sort -u > conf-nfs.SERVICE_ID
cephuser@adm > cat conf-nfs.foo
%url "rados://ganesha_config/ganesha/export-1"
%url "rados://ganesha_config/ganesha/export-2"
%url "rados://ganesha_config/ganesha/export-3"
%url "rados://ganesha_config/ganesha/export-4"

  4. 新しいNFS Ganesha共通設定ファイルを書き込みます。 

    cephuser@adm > rados $RADOS_ARGS put conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID

  5. NFS Ganeshaデーモンに通知します。 

    cephuser@adm > rados $RADOS_ARGS notify conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID
    注記
    注記

    このアクションによって、デーモンは設定を再ロードします。

サービスのマイグレートに成功すると、NautilusベースのNFS Ganeshaサービスを削除できるようになります。

  1. NFS Ganeshaを削除します。 

    cephuser@adm > zypper rm nfs-ganesha
Reading installed packages...
Resolving package dependencies...
The following 5 packages are going to be REMOVED:
  nfs-ganesha nfs-ganesha-ceph nfs-ganesha-rados-grace nfs-ganesha-rados-urls nfs-ganesha-rgw
5 packages to remove.
After the operation, 308.9 KiB will be freed.
Continue? [y/n/v/...? shows all options] (y): y
(1/5) Removing nfs-ganesha-ceph-2.8.3+git0.d504d374e-3.3.1.x86_64 .................................................................................................................................................................................................................................................................................................[done]
(2/5) Removing nfs-ganesha-rgw-2.8.3+git0.d504d374e-3.3.1.x86_64 ..................................................................................................................................................................................................................................................................................................[done]
(3/5) Removing nfs-ganesha-rados-urls-2.8.3+git0.d504d374e-3.3.1.x86_64 ...........................................................................................................................................................................................................................................................................................[done]
(4/5) Removing nfs-ganesha-rados-grace-2.8.3+git0.d504d374e-3.3.1.x86_64 ..........................................................................................................................................................................................................................................................................................[done]
(5/5) Removing nfs-ganesha-2.8.3+git0.d504d374e-3.3.1.x86_64 ......................................................................................................................................................................................................................................................................................................[done]
Additional rpm output:
warning: /etc/ganesha/ganesha.conf saved as /etc/ganesha/ganesha.conf.rpmsave

  2. Cephダッシュボードから古いクラスタ設定を削除します。 

    cephuser@adm > ceph dashboard reset-ganesha-clusters-rados-pool-namespace

10.7.3 メタデータサーバのアップグレード

 

MON、MGR、OSDとは異なり、メタデータサーバをインプレース導入することはできません。その代わり、Cephオーケストレータを使用して、コンテナ内に再展開する必要があります。

  1. ceph fs lsコマンドを実行して、ファイルシステムの名前を取得します。以下に例を示します。 

    cephuser@adm > ceph fs ls
name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]

  2. 8.3.3項 「メタデータサーバの展開」に記載されている、新しいサービス仕様ファイルmds.ymlを作成します。そのために、ファイルシステムの名前をservice_idとして使用して、MDSデーモンを実行するホストを指定します。以下に例を示します。 

    service_type: mds
service_id: cephfs
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

  3. ceph orch apply -i mds.ymlコマンドを実行して、サービス仕様を適用し、MDSデーモンを起動します。

10.7.4 iSCSI Gatewayのアップグレード

 

iSCSI Gatewayをアップグレードするには、Cephオーケストレータを使用してコンテナ内に再展開する必要があります。複数のiSCSI Gatewayを使用している場合はサービスのダウンタイムを短縮するために、iSCSI Gatewayを1つずつ再展開する必要があります。

  1. 各iSCSI Gatewayノードで実行されている既存のiSCSIデーモンを停止し無効化するには、次のコマンドを実行します。 

    > sudo systemctl stop rbd-target-gw
> sudo systemctl disable rbd-target-gw
> sudo systemctl stop rbd-target-api
> sudo systemctl disable rbd-target-api

  2. 8.3.5項 「iSCSI Gatewayの展開」に記載されている、iSCSI Gateway用のサービス仕様を作成します。そのためには、既存の/etc/ceph/iscsi-gateway.cfgファイルからpool、trusted_ip_list、api_*という設定を取得する必要があります。SSLサポートを有効にしている場合(api_secure = true)、SSL証明書(/etc/ceph/iscsi-gateway.crt)とキー(/etc/ceph/iscsi-gateway.key)も必要です。

    例として、/etc/ceph/iscsi-gateway.cfgが以下の内容を含む場合を考えます。 

    [config]
cluster_client_name = client.igw.ses-min5
pool = iscsi-images
trusted_ip_list = 10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202
api_port = 5000
api_user = admin
api_password = admin
api_secure = true

    この場合、次のようなサービス仕様ファイルiscsi.ymlを作成する必要があります。 

    service_type: iscsi
service_id: igw
placement:
  hosts:
  - ses-min5
spec:
  pool: iscsi-images
  trusted_ip_list: "10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202"
  api_port: 5000
  api_user: admin
  api_password: admin
  api_secure: true
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
    DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
    [...]
    -----END CERTIFICATE-----
  ssl_key: |
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
    /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
    [...]
    -----END PRIVATE KEY-----
    注記
    注記

    pool、trusted_ip_list、api_port、api_user、api_password、api_secureの設定は、/etc/ceph/iscsi-gateway.cfgファイルの内容とまったく同じです。ssl_certとssl_keyの値は、既存のSSL証明書とキーファイルからコピーできます。これらの設定が適切にインデントされていることを確認してください。また、ssl_cert:行とssl_key:行の末尾に「パイプ文字」(|)があることを確認してください(上記のiscsi.ymlファイルの内容を参照してください)。

  3. ceph orch apply -i iscsi.ymコマンドを実行して、サービス仕様を適用し、iSCSI Gatewayデーモンを起動します。

  4. 既存の各iSCSIゲートウェイノードから古いceph-iscsiパッケージを削除します。 

    cephuser@adm > zypper rm -u ceph-iscsi

10.8 アップグレード後のクリーンアップ

 

アップグレードの完了後に、以下のクリーンアップ手順を実行してください。

  1. 現在のCephバージョンをチェックして、クラスタのアップグレードに成功しているかを確認します。 

    cephuser@adm > ceph versions

  2. 古いOSDがクラスタに参加していないことを確認します。 

    cephuser@adm > ceph osd require-osd-release pacific

  3. 必要に応じて、既存のプールのpg_autoscale_modeを設定します。

    重要
    重要

    SUSE Enterprise Storage 6のプールはpg_autoscale_modeがデフォルトでwarnに設定されています。そのため、配置グループ数が最適でない場合に警告メッセージが出ますが、警告のみで自動拡張は行われません。SUSE Enterprise Storage 7.1のデフォルト設定では、新しいプールのpg_autoscale_modeオプションはonに設定されるため、配置グループは自動拡張が実際に行われます。手順に従ってアップグレードを行っても、既存プールのpg_autoscale_modeは、自動では変更されません。設定をonに変更して自動拡張を活用したい場合は、17.4.12項 「配置グループの自動拡張の有効化」の手順を参照してください。

    詳細については、17.4.12項 「配置グループの自動拡張の有効化」を参照してください。

  4. Luminousより前のバージョンのクライアントを拒否します。 

    cephuser@adm > ceph osd set-require-min-compat-client luminous

  5. バランサモジュールを有効化します。 

    cephuser@adm > ceph balancer mode upmap
cephuser@adm > ceph balancer on

    詳細については、29.1項 「バランサ」を参照してください。

  6. 必要に応じてテレメトリモジュールを有効にします。 

    cephuser@adm > ceph mgr module enable telemetry
cephuser@adm > ceph telemetry on

    詳細については、29.2項 「テレメトリモジュールの有効化」を参照してください。