目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Enterprise Storage 7.1マニュアル / 運用と管理ガイド / クラスタの運用 / 運用タスク
適用項目 SUSE Enterprise Storage 7.1

13 運用タスク

13.1 クラスタ設定の変更

既存のCephクラスタの設定を変更するには、次の手順に従います。

  1. 現在のクラスタの設定をファイルにエクスポートします。

    cephuser@adm > ceph orch ls --export --format yaml > cluster.yaml
  2. 設定が記載されたファイルを編集し、関連する行を更新します。仕様の例については、第8章 「cephadmを使用して残りのコアサービスを展開する13.4.3項 「DriveGroups仕様を用いたOSDの追加」を参照してください。

  3. 新しい設定を適用します。

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

13.2 ノードの追加

Cephクラスタに新しいノードを追加するには、次の手順に従います。

  1. SUSE Linux Enterprise ServerとSUSE Enterprise Storageを新規ホストにインストールします。詳細については、第5章 「SUSE Linux Enterprise Serverのインストールと設定を参照してください。

  2. ホストを既存のSalt MasterのSalt Minionとして設定します。詳細については、第6章 「Saltの展開を参照してください。

  3. 新しいホストをceph-saltに追加し、cephadmにホストを認識させます。たとえば、次のコマンドを実行します。

    root@master # ceph-salt config /ceph_cluster/minions add ses-min5.example.com
    root@master # ceph-salt config /ceph_cluster/roles/cephadm add ses-min5.example.com

    詳細については、7.2.2項 「Salt Minionの追加」を参照してください。

  4. ceph-saltにノードが追加されたことを確認します。

    root@master # ceph-salt config /ceph_cluster/minions ls
    o- minions ................................................. [Minions: 5]
    [...]
      o- ses-min5.example.com .................................... [no roles]
  5. 新しいクラスタホストに設定を適用します。

    root@master # ceph-salt apply ses-min5.example.com
  6. 新しく追加したホストがcephadm環境に属していることを確認します。

    cephuser@adm > ceph orch host ls
    HOST                   ADDR                    LABELS   STATUS
    [...]
    ses-min5.example.com   ses-min5.example.com

13.3 ノードの削除

ヒント
ヒント: OSDの削除

削除しようとしているノードがOSDを実行している場合、まずOSDを削除してからそのノード上でOSDが実行されていないことを確認してください。OSDを削除する方法の詳細については、13.4.4項 「OSDの削除」を参照してください。

クラスタからノードを削除するには、次の手順に従います。

  1. node-exportercrashを除くすべてのCephサービスタイプについて、ノードのホスト名をクラスタの配置仕様ファイル(cluster.ymlなど)から削除します。詳細については、8.2項 「サービス仕様と配置仕様」を参照してください。たとえば、ses-min2という名前のホストを削除する場合、すべてのplacement:セクションから、- ses-min2という記載をすべて削除します。

    この状態から

    service_type: rgw
    service_id: EXAMPLE_NFS
    placement:
      hosts:
      - ses-min2
      - ses-min3

    次のように変更してください。

    service_type: rgw
    service_id: EXAMPLE_NFS
    placement:
      hosts:
      - ses-min3

    変更内容を設定ファイルに適用します。

    cephuser@adm > ceph orch apply -i rgw-example.yaml
  2. cephadm環境からノードを削除します。

    cephuser@adm > ceph orch host rm ses-min2
  3. ノードがcrash.osd.1crash.osd.2というサービスを実行している場合、ホスト上で次のコマンドを実行してサービスを削除します。

    root@minion > cephadm rm-daemon --fsid CLUSTER_ID --name SERVICE_NAME

    例:

    root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.1
    root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.2
  4. 削除したいミニオンからすべての役割を削除します。

    cephuser@adm > ceph-salt config /ceph_cluster/roles/tuned/throughput remove ses-min2
    cephuser@adm > ceph-salt config /ceph_cluster/roles/tuned/latency remove ses-min2
    cephuser@adm > ceph-salt config /ceph_cluster/roles/cephadm remove ses-min2
    cephuser@adm > ceph-salt config /ceph_cluster/roles/admin remove ses-min2

    削除したいミニオンがブートストラップミニオンの場合、ブートストラップの役割も削除する必要があります。

    cephuser@adm > ceph-salt config /ceph_cluster/roles/bootstrap reset
  5. 1つのホストからすべてのOSDを削除したら、そのホストをCRUSHマップから削除します。

    cephuser@adm > ceph osd crush remove bucket-name
    注記
    注記

    バケット名はホスト名と同じであるはずです。

  6. これで、クラスタからミニオンを削除できるようになります。

    cephuser@adm > ceph-salt config /ceph_cluster/minions remove ses-min2
重要
重要

障害イベント中で、削除しようとしているミニオンが永続的な電源オフ状態である場合、Salt Masterからノードを削除する必要があります。

root@master # salt-key -d minion_id

その後、pillar_root/ceph-salt.slsからノードを手動で削除します。このファイルは通常、/srv/pillar/ceph-salt.slsに置かれています。

13.4 OSDの管理

このセクションではCephクラスタにOSDを追加、消去、削除する方法を説明します。

13.4.1 ディスクデバイスの一覧

すべてのクラスタノード上のディスクデバイスが使用中か未使用かを確認するには、次のコマンドを実行してディスクを一覧にしてください。

cephuser@adm > ceph orch device ls
HOST       PATH      TYPE SIZE  DEVICE  AVAIL REJECT REASONS
ses-master /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vdb  hdd  8192M  387836 False locked, LVM detected, Insufficient space (<5GB) on vgs
ses-min2   /dev/vdc  hdd  8192M  450575 True

13.4.2 ディスクデバイスの消去

ディスクデバイスを再利用するには、まず内容を消去する必要があります。

ceph orch device zap HOST_NAME DISK_DEVICE

例:

cephuser@adm > ceph orch device zap ses-min2 /dev/vdc
注記
注記

unmanagedフラグが設定されておらず、以前OSDを展開した際にDriveGroupsまたは--all-available-devicesオプションを使用していた場合、消去後にcephadmが自動的にこれらのOSDを展開します。

13.4.3 DriveGroups仕様を用いたOSDの追加

「DriveGroups」では、CephクラスタのOSDのレイアウトを指定します。レイアウトは単独のYAMLファイルで定義します。このセクションでは、例としてdrive_groups.ymlを使用します。

管理者は、相互に関連するOSDのグループ(HDDとSSDの混成環境に展開されるハイブリッドOSD)を手動で指定するか、同じ展開オプション(たとえば、同じオブジェクトストア、同じ暗号化オプション、スタンドアロンOSDなど)を共有する必要があります。デバイスが明示的に一覧にされないようにするため、DriveGroupsでは、ceph-volumeインベントリレポートで選択した数個のフィールドに対応するフィルタ項目のリストを使用します。cephadmでは、これらのDriveGroupsを実際のデバイスリストに変換してユーザが調べられるようにするコードを提供します。

OSDの仕様をクラスタに適用するには、次のコマンドを実行します。

cephuser@adm > ceph orch apply osd -i drive_groups.yml

アクションのプレビューを確認する場合や、アプリケーションをテストする場合には、--dry-runオプションを付加したceph orch apply osdコマンドを使用できます。次に例を示します。

cephuser@adm > ceph orch apply osd -i drive_groups.yml --dry-run
...
+---------+------+------+----------+----+-----+
|SERVICE  |NAME  |HOST  |DATA      |DB  |WAL  |
+---------+------+------+----------+----+-----+
|osd      |test  |mgr0  |/dev/sda  |-   |-    |
|osd      |test  |mgr0  |/dev/sdb  |-   |-    |
+---------+------+------+----------+----+-----+

--dry-runの出力が想定通りなら、--dry-runオプションを外して再度コマンドを実行するだけです。

13.4.3.1 アンマネージドOSD

DriveGroups仕様と一致する、利用可能なすべてのクリーンディスクデバイスは、クラスタに追加すると自動的にOSDとして使用されます。この動作を「マネージド」モードと呼びます。

「マネージド」モードを無効化するには、unmanaged: true行を関連する仕様に追加してください。次に例を示します。

service_type: osd
service_id: example_drvgrp_name
placement:
 hosts:
 - ses-min2
 - ses-min3
encrypted: true
unmanaged: true
ヒント
ヒント

すでに展開済みのOSDを「マネージド」モードから「アンマネージド」モードに切り替えるには、13.1項 「クラスタ設定の変更」で説明した手順の中でunmanaged: true行を追加してください。

13.4.3.2 DriveGroups仕様

DriveGroups仕様ファイルの例を次に示します。

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  drive_spec: DEVICE_SPECIFICATION
db_devices:
  drive_spec: DEVICE_SPECIFICATION
wal_devices:
  drive_spec: DEVICE_SPECIFICATION
block_wal_size: '5G'  # (optional, unit suffixes permitted)
block_db_size: '5G'   # (optional, unit suffixes permitted)
encrypted: true       # 'True' or 'False' (defaults to 'False')
注記
注記

かつてのDeepSeaで「encryption」と呼ばれていたオプションは、「encrypted」に名前が変更されました。SUSE Enterprise Storage 7にDriveGroupに適用する場合は、サービス仕様にこの新しい用語が使われているかを確認してください。さもなければ、ceph orch apply操作は失敗します。

13.4.3.3 一致するディスクデバイス

次のフィルタを使用して指定を記述できます。

  • ディスクモデル別。

    model: DISK_MODEL_STRING
  • ディスクベンダー別。

    vendor: DISK_VENDOR_STRING
    ヒント
    ヒント

    DISK_VENDOR_STRINGは必ず小文字で入力してください。

    ディスクモデルとディスクベンダーの詳細を取得するには、次のコマンドの出力を確認してください。

    cephuser@adm > ceph orch device ls
    HOST     PATH     TYPE  SIZE DEVICE_ID                  MODEL            VENDOR
    ses-min1 /dev/sdb ssd  29.8G SATA_SSD_AF34075704240015  SATA SSD         ATA
    ses-min2 /dev/sda ssd   223G Micron_5200_MTFDDAK240TDN  Micron_5200_MTFD ATA
    [...]
  • ディスクが回転型かどうか。SSDとNVMeドライブは回転型ではありません。

    rotational: 0
  • OSDで使用可能な「すべての」ドライブを使用してノードを展開します。

    data_devices:
      all: true
  • また、一致するディスクの数を制限します。

    limit: 10

13.4.3.4 サイズによるデバイスのフィルタリング

ディスクデバイスをサイズでフィルタできます(正確なサイズ、またはサイズの範囲)。size:パラメータには、次の形式の引数を指定できます。

  • '10G' -正確にこのサイズのディスクを含めます。

  • '10G:40G' - この範囲内のサイズのディスクを含めます。

  • ':10G' - サイズが10GB以下のディスクを含めます。

  • '40G:' - サイズが40GB以上のディスクを含めます。

例 13.1: ディスクサイズによる一致
service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '40TB:'
db_devices:
  size: ':2TB'
注記
注記: 引用符が必要

区切り文字「:」を使用する場合は、サイズを引用符で囲む必要があります。そうしないと、「:」記号は新しい設定のハッシュであると解釈されます。

ヒント
ヒント: 単位のショートカット

ギガバイト(G)の代わりに、メガバイト(M)やテラバイト(T)でもサイズを指定できます。

13.4.3.5 DriveGroupsの例

このセクションでは、さまざまなOSDセットアップの例を示します。

例 13.2: 単純なセットアップ

この例では、同じセットアップを使用する2つのノードについて説明します。

  • 20台のHDD

    • ベンダー: Intel

    • モデル: SSD-123-foo

    • サイズ: 4TB

  • 2台のSSD

    • ベンダー: Micron

    • モデル: MC-55-44-ZX

    • サイズ: 512GB

対応するdrive_groups.ymlファイルは次のようになります。

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: MC-55-44-XZ

このような設定は単純で有効です。問題は、管理者が将来、別のベンダーのディスクを追加することがあっても、それらのディスクが含まれない点です。この設定を向上させるには、ドライブのコアプロパティのフィルタを減らします。

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

前の例では、回転型デバイスはすべて「データデバイス」として宣言し、非回転型デバイスはすべて「共有デバイス」(wal、db)として使用します。

2TBを超えるドライブが常に低速のデータデバイスであることがわかっている場合は、サイズでフィルタできます。

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '2TB:'
db_devices:
  size: ':2TB'
例 13.3: 詳細セットアップ

この例では、2つの別個のセットアップについて説明します。20台のHDDで2台のSSDを共有するセットアップと、10台のSSDで2台のNVMeを共有するセットアップです。

  • 20台のHDD

    • ベンダー: Intel

    • モデル: SSD-123-foo

    • サイズ: 4TB

  • 12台のSSD

    • ベンダー: Micron

    • モデル: MC-55-44-ZX

    • サイズ: 512GB

  • 2つのNVMe

    • ベンダー: Samsung

    • モデル: NVME-QQQQ-987

    • サイズ: 256GB

このようなセットアップは、次のような2つのレイアウトで定義できます。

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ
service_type: osd
service_id: example_drvgrp_name2
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  vendor: samsung
  size: 256GB
例 13.4: 不均一なノードを使用した詳細セットアップ

前の例では、すべてのノードに同じドライブがあることを想定しています。ただし、常にこれが当てはまるとは限りません。

ノード1~5:

  • 20台のHDD

    • ベンダー: Intel

    • モデル: SSD-123-foo

    • サイズ: 4TB

  • 2台のSSD

    • ベンダー: Micron

    • モデル: MC-55-44-ZX

    • サイズ: 512GB

ノード6~10:

  • 5つのNVMe

    • ベンダー: Intel

    • モデル: SSD-123-foo

    • サイズ: 4TB

  • 20台のSSD

    • ベンダー: Micron

    • モデル: MC-55-44-ZX

    • サイズ: 512GB

レイアウトに「target」キーを使用して、特定のノードをターゲットに設定できます。Saltのターゲット表記を使用すると、内容をシンプルに保つことができます。

service_type: osd
service_id: example_drvgrp_one2five
placement:
  host_pattern: 'node[1-5]'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

続いて以下を設定します。

service_type: osd
service_id: example_drvgrp_rest
placement:
  host_pattern: 'node[6-10]'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo
例 13.5: エキスパートセットアップ

前の事例はすべて、WALとDBが同じデバイスを使用することを想定していました。ただし、WALを専用のデバイスに展開することもできます。

  • 20台のHDD

    • ベンダー: Intel

    • モデル: SSD-123-foo

    • サイズ: 4TB

  • 2台のSSD

    • ベンダー: Micron

    • モデル: MC-55-44-ZX

    • サイズ: 512GB

  • 2つのNVMe

    • ベンダー: Samsung

    • モデル: NVME-QQQQ-987

    • サイズ: 256GB

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo
wal_devices:
  model: NVME-QQQQ-987
例 13.6: 複雑な(可能性が低い)セットアップ

次のセットアップでは、以下を定義してみます。

  • 1つのNVMeを利用する20台のHDD

  • 1台のSSD (db)と1つのNVMe (wal)を利用する2台のHDD

  • 1つのNVMeを利用する8台のSSD

  • 2台SSDスタンドアロン(暗号化)

  • 1台のHDDはスペアで、展開しない

使用するドライブの概要は次のとおりです。

  • 23台のHDD

    • ベンダー: Intel

    • モデル: SSD-123-foo

    • サイズ: 4TB

  • 10台のSSD

    • ベンダー: Micron

    • モデル: MC-55-44-ZX

    • サイズ: 512GB

  • 1つのNVMe

    • ベンダー: Samsung

    • モデル: NVME-QQQQ-987

    • サイズ: 256GB

DriveGroupsの定義は次のようになります。

service_type: osd
service_id: example_drvgrp_hdd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: NVME-QQQQ-987
service_type: osd
service_id: example_drvgrp_hdd_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ
wal_devices:
  model: NVME-QQQQ-987
service_type: osd
service_id: example_drvgrp_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: NVME-QQQQ-987
service_type: osd
service_id: example_drvgrp_standalone_encrypted
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
encrypted: True

ファイルが上から下へ解析されると、HDDが1台残ります。

13.4.4 OSDの削除

クラスタからOSDノードを削除する前に、クラスタの空きディスク容量が、削除予定のOSDディスクの容量以上であることを確認してください。OSDを削除すると、クラスタ全体のリバランスが発生することに注意してください。

  1. IDを取得して、削除するOSDを特定します。

    cephuser@adm > ceph orch ps --daemon_type osd
    NAME   HOST            STATUS        REFRESHED  AGE  VERSION
    osd.0  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
    osd.1  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
    osd.2  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
    osd.3  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
  2. クラスタから1つ以上のOSDを削除します。

    cephuser@adm > ceph orch osd rm OSD1_ID OSD2_ID ...

    例:

    cephuser@adm > ceph orch osd rm 1 2
  3. 削除操作の状態をクエリすることができます。

    cephuser@adm > ceph orch osd rm status
    OSD_ID  HOST         STATE                    PG_COUNT  REPLACE  FORCE  STARTED_AT
    2       cephadm-dev  done, waiting for purge  0         True     False  2020-07-17 13:01:43.147684
    3       cephadm-dev  draining                 17        False    True   2020-07-17 13:01:45.162158
    4       cephadm-dev  started                  42        False    True   2020-07-17 13:01:45.162158

13.4.4.1 OSD削除の中止

OSDの削除をスケジュールした後、必要に応じて削除を停止できます。次のコマンドを実行すると、OSDの初期状態がリセットされ、キューから削除されます。

cephuser@adm > ceph orch osd rm stop OSD_SERVICE_ID

13.4.5 OSDの交換

さまざまな理由でOSDディスクを交換しなければならないことがあります。例:

  • OSDディスクに障害が発生しているか、SMART情報によると間もなく障害が発生しそうで、そのOSDディスクを使用してデータを安全に保存できなくなっている。

  • サイズの増加などのため、OSDディスクをアップグレードする必要がある。

  • OSDディスクのレイアウトを変更する必要がある。

  • 非LVMからLVMベースのレイアウトに移行することを計画している。

IDを維持したままOSDを交換するには、次のコマンドを実行します。

cephuser@adm > ceph orch osd rm OSD_SERVICE_ID --replace

例:

cephuser@adm > ceph orch osd rm 4 --replace

OSDの交換は、OSDがCRUSH階層から永久に削除されることがなく、代わりにdestroyedフラグが割り当てられることを除けば、OSDの削除と同じです(詳細については、13.4.4項 「OSDの削除」を参照してください)。

destroyedフラグは、次回OSDを展開した際に再利用するOSD IDを特定するために使用されます。新しく追加されたディスクがDriveGroups仕様と一致する場合、そのディスクには交換されたディスクのOSD IDが割り当てられます(詳細については、13.4.3項 「DriveGroups仕様を用いたOSDの追加」を参照してください)。

ヒント
ヒント

--dry-runオプションを付加すると、実際の交換は行われませんが、通常発生する手順をプレビューします。

注記
注記

障害後にOSDを交換する場合は、配置グループのディープスクラブをトリガすることを強くお勧めします。詳しくは「17.6項 「配置グループのスクラブ」」を参照してください。

次のコマンドを実行して、ディープスクラブを開始します。

cephuser@adm > ceph osd deep-scrub osd.OSD_NUMBER
重要
重要: 共有デバイスの障害

DB/WALの共有デバイスに障害が発生した場合は、障害が発生したデバイスを共有するすべてのOSDの交換手順を実行する必要があります。

13.5 新しいノードへのSalt Masterの移動

Salt Masterのホストを新しいものに交換する必要がある場合、次の手順に従います。

  1. クラスタ設定をエクスポートし、エクスポートされたJSONファイルをバックアップします。詳細については、7.2.14項 「クラスタ設定のエクスポート」を参照してください。

  2. 古いSalt Masterがクラスタで唯一の管理ノードでもある場合、/etc/ceph/ceph.client.admin.keyring/etc/ceph/ceph.confを新しいSalt Masterに手動で移動します。

  3. 古いSalt Masterノードで、Salt Masterのsystemdサービスを停止し無効化します。

    root@master # systemctl stop salt-master.service
    root@master # systemctl disable salt-master.service
  4. 古いSalt Masterノードがすでにクラスタ内に存在しない場合、Salt Minionのsystemdサービスも停止し無効化します。

    root@master # systemctl stop salt-minion.service
    root@master # systemctl disable salt-minion.service
    警告
    警告

    古いSalt MasterノードがいずれかのCephデーモン(MON、MGR、OSD、MDS、ゲートウェイ、監視)を実行している場合は、salt-minion.serviceの停止と無効化を行わないでください。

  5. SUSE Linux Enterprise Server 15 SP3を新しいSalt Masterにインストールします。手順は第5章 「SUSE Linux Enterprise Serverのインストールと設定を参照してください。

    ヒント
    ヒント: Salt Minionの移行

    Salt Minionを新しいSalt Masterへ簡単に移行するには、各Minionから元のSalt Masterの公開鍵を削除します。

    root@minion > rm /etc/salt/pki/minion/minion_master.pub
    root@minion > systemctl restart salt-minion.service
  6. salt-masterパッケージをインストールし、該当する場合は、新しいSalt Masterにsalt-minionパッケージをインストールします。

  7. 新しいSalt Masterノードにceph-saltをインストールします。

    root@master # zypper install ceph-salt
    root@master # systemctl restart salt-master.service
    root@master # salt '*' saltutil.sync_all
    重要
    重要

    次の手順に進む前に、3つすべてのコマンドを実行したか確認してください。これらのコマンドはべき等です。つまり、同じコマンドを複数回実行しても問題ありません。

  8. 新しいSalt Masterをクラスタに取り込みます。手順は7.1項 「ceph-saltのインストール」7.2.2項 「Salt Minionの追加」7.2.4項 「管理ノードの指定」を参照してください。

  9. バックアップしたクラスタ設定をインポートして適用します。

    root@master # ceph-salt import CLUSTER_CONFIG.json
    root@master # ceph-salt apply
    重要
    重要

    インポートする前に、エクスポートされたCLUSTER_CONFIG.jsonファイルに記載されたSalt Masterのminion idの名前を変更します。

13.6 クラスタノードの更新

ローリングアップデートを定期的に適用して、Cephクラスタノードを最新の状態に保ちます。

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

最新のソフトウェアパッケージのパッチをクラスタに適用する前に、クラスタのすべてのノードが関連するリポジトリにアクセスできることを確認します。必要なリポジトリの完全なリストについては、10.1.5.1項 「ソフトウェアリポジトリ」を参照してください。

13.6.2 リポジトリのステージング

クラスタノードにソフトウェアリポジトリを提供するステージングツール(SUSE Manager、RMT (Repository Management Tool)など)を使用する場合、SUSE Linux Enterprise ServerとSUSE Enterprise Storageの両方の「更新」リポジトリのステージが同じ時点で作成されていることを確認します。

ステージングツールを使用して、パッチレベルがfrozenまたはstagedのパッチを適用することを強く推奨します。これにより、クラスタに参加している新しいノードと、クラスタですでに動作しているノードが確実に同じパッチレベルになるようにします。また、新しいノードがクラスタに参加する前に、クラスタのすべてのノードに最新のパッチを適用する必要がなくなります。

13.6.3 Cephサービスのダウンタイム

設定によっては、更新中にクラスタノードが再起動される場合があります。Object Gateway、Samba Gateway、NFS Ganesha、iSCSIなど、サービスの単一障害点があると、再起動されるノードに存在するサービスからクライアントマシンが一時的に切断される場合があります。

13.6.4 更新の実行

すべてのクラスタノードでソフトウェアパッケージを最新バージョンに更新するには、次のコマンドを実行します。

root@master # ceph-salt update

13.7 Cephの更新

cephadmに対して、Cephを更新して各バグフィックスリリースを適用するように指示できます。Cephサービスの自動更新は、推奨される順番を尊重します。つまり、まずはCeph ManagerとCeph Monitorから開始し、その後、Ceph OSD、メタデータサーバ、Object Gatewayなどのその他のサービスに進みます。クラスタの利用を継続できることをCephが示すまで、各デーモンは再起動されません。

注記
注記

以下の更新手順では、ceph orch upgradeコマンドを使用します。以下の手順は、ある製品バージョンのCephクラスタを更新する方法を詳細に説明したもので(たとえば、保守更新)、クラスタをある製品バージョンから別の製品バージョンにアップグレードする方法を説明したものではないことに注意してください。

13.7.1 更新の開始

更新を開始する前に、すべてのノードが現在オンラインであり、クラスタが正常な状態であることを確認してください。

cephuser@adm > cephadm shell -- ceph -s

特定のCephリリースに更新するには、次のコマンドを使用します。

cephuser@adm > ceph orch upgrade start --image REGISTRY_URL

例:

cephuser@adm > ceph orch upgrade start --image registry.suse.com/ses/7.1/ceph/ceph:latest

ホスト上でパッケージをアップグレードします。

cephuser@adm > ceph-salt update

13.7.2 更新の監視

更新が進行中かどうかを確認するには、次のコマンドを実行します。

cephuser@adm > ceph orch upgrade status

更新が進行中であれば、Cephの状態出力でプログレスバーを確認できます。

cephuser@adm > ceph -s
[...]
  progress:
    Upgrade to registry.suse.com/ses/7.1/ceph/ceph:latest (00h 20m 12s)
      [=======.....................] (time remaining: 01h 43m 31s)

cephadmのログを監視することもできます。

cephuser@adm > ceph -W cephadm

13.7.3 更新のキャンセル

更新処理はいつでも中止できます。

cephuser@adm > ceph orch upgrade stop

13.8 クラスタの停止または再起動

場合によっては、クラスタ全体を停止または再起動しなければならないことがあります。実行中のサービスの依存関係を入念に確認することをお勧めします。次の手順では、クラスタの停止と起動の概要を説明します。

  1. OSDにoutのマークを付けないようCephクラスタに指示します。

    cephuser@adm > ceph osd set noout
  2. 次の順序でデーモンとノードを停止します。

    1. ストレージクライアント

    2. ゲートウェイ(たとえば、NFS Ganesha、Object Gateway)

    3. メタデータサーバ

    4. Ceph OSD

    5. Ceph Manager

    6. Ceph Monitor

  3. 必要に応じて、保守タスクを実行します。

  4. ノードとサーバをシャットダウンプロセスの逆の順序で起動します。

    1. Ceph Monitor

    2. Ceph Manager

    3. Ceph OSD

    4. メタデータサーバ

    5. ゲートウェイ(たとえば、NFS Ganesha、Object Gateway)

    6. ストレージクライアント

  5. nooutフラグを削除します。

    cephuser@adm > ceph osd unset noout

13.9 Cephクラスタ全体の削除

ceph-salt purgeコマンドを実行すると、Cephクラスタ全体が削除されます。複数のCephクラスタを展開している場合は、ceph -sコマンドでレポートされるクラスタがパージされます。これにより、異なる設定をテストする際にクラスタ環境をクリーンにすることができます。

誤って削除されることがないよう、オーケストレーションは、セキュリティ対策が解除されているかどうかをチェックします。次のコマンドを実行して、セキュリティ対策を解除してCephクラスタを削除できます。

root@master # ceph-salt disengage-safety
root@master # ceph-salt purge