13 運用タスク #

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

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

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

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を展開します。

「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.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)でもサイズを指定できます。

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

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '2TB:'
db_devices:
  size: ':2TB'

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

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

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

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

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

cephuser@adm > ceph orch osd rm stop OSD_SERVICE_ID

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

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

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

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

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

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

root@master # ceph-salt update

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

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/ceph/ceph:latest

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

cephuser@adm > ceph-salt update

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

cephuser@adm > ceph orch upgrade status

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

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

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

cephuser@adm > ceph -W cephadm

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

cephuser@adm > ceph orch upgrade stop