LoginSignup
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@mizutan(Yasuko Mizutani)

Portworx稼働中 OCP3.11クラスターへのworkerノード追加

Posted at

はじめに

IBM Cloud Pak for Data (CP4D)は、ストレージプロバイダーとして、Portworxをサポートしています。
リソースが不足してきた等の理由で、workerノードの追加が必要になることがありますが、実際、workerノードの追加をしようとした時、そのノードにPortworx用の追加のRawディスクは必要なのかといった疑問が生じました。そこで、特に追加のRawディスクに着目してworkerノードの追加を実機で検証してみました。

検証環境

  • Red Hat OpenShift Container Platform (OCP) 3.11
  • RHEL 7.6
  • Portworx Enterprise Edition 2.5.5.0 (CP4D同梱)

px-cluster.png

サーバー vCPU Memory OS Disk 追加Disk#1 追加Disk#2 OS ホスト名 IP Address
workerノード 1 16vCPU 64GByte 200G 300G 100G RHEL7.6 w-1.example.localdomain 192.168.81.65
workerノード 2 16vCPU 64GByte 200G 300G 100G RHEL7.6 w-2.example.localdomain 192.168.81.66
workerノード 3 16vCPU 64GByte 200G 300G 100G RHEL7.6 w-3.example.localdomain 192.168.81.67

Portworxの状態

こちらの手順でセットアップしたテスト用環境です。
IBM Cloud Pak for Data: Portworx ストレージのセットアップ

限定的なテスト用途での環境のため、CP4Dの要件を一部満たしていないことをご了承ください。

CP4DでPortworxを使用する時の要件については、以下の記述があります。

  • 最小で 3 つのストレージ・ノードが必要です。各ストレージ・ノードに以下が必要です。
    • 最小で 1 TB のフォーマットされていないロウ・ディスク
    • キーと値のデータベース用の、さらに 100 GB のフォーマットされていないロウ・ディスク

さらに、次の要件も満たす必要があります。
アプリケーション・ストレージ用に指定された各計算ノードに少なくとも 1 TB の未フォーマットのロウ・ディスクと、メタデータ・ストレージ用に少なくとも 100 GB の未フォーマットのロウ・ディスク。すべての計算ノードでロウ・ディスクのデバイス名が同じでなければなりません。

以下のコマンドでPortworxをインストールしました：

Usage:
px-install.sh [-reg-sec] -pp Always -R <registry-url>/<repository or suffix>  install <device_for_metadata>

インストール実行時のコマンド：
px-install.sh -pp Always -R docker-registry.default.svc:5000/kube-system install /dev/sdc

Portworxストレージはデフォルトで/dev/sdbになっていますが、px-install.sh内のパラメーターDEFAULT_STOREで指定可能です。
この結果、次のような構成になっています。

  • /dev/sdb : Portworxストレージデバイス
  • /dev/sdc : メタデータデバイス
# kubectl exec $PX_POD -n kube-system -- /opt/pwx/bin/pxctl status
Status: PX is operational
License: IBM Cloud Pak for Data
Node ID: 31ca65fc-b99f-4543-9b5a-426616b5c15e
        IP: 192.168.81.67
        Local Storage Pool: 1 pool
        POOL    IO_PRIORITY     RAID_LEVEL      USABLE  USED    STATUS  ZONE    REGION
        0       LOW             raid0           300 GiB 37 GiB  Online  default default
        Local Storage Devices: 1 device
        Device  Path            Media Type              Size            Last-Scan
        0:1     /dev/sdb        STORAGE_MEDIUM_MAGNETIC 300 GiB         20 Dec 21 16:52 UTC
        total                   -                       300 GiB
        Cache Devices:
        No cache devices
        Metadata Device:
        1       /dev/sdc        STORAGE_MEDIUM_MAGNETIC
Cluster Summary
        Cluster ID: px-cluster-65f5582a-5643-40e7-a988-81d4fa38b329
        Cluster UUID: 35a9e214-3808-4a6e-b5e0-d2c87035e77d
        Scheduler: kubernetes
        Nodes: 3 node(s) with storage (3 online)
        IP              ID                                      SchedulerNodeName               StorageNode     Used    Capacity        Status  StorageStatus   Version         Kernel                       OS
        192.168.81.65      722c5972-3826-46f6-918e-cf93ecbdb25b    w-1.example.localdomain     Yes             37 GiB  300 GiB         Online  Up              2.5.5.0-bef5691 3.10.0-1127.el7.x86_64       Red Hat Enterprise Linux Server 7.6 (Maipo)
        192.168.81.66      390db093-1874-49f4-b943-8775470fa935    w-2.example.localdomain     Yes             37 GiB  300 GiB         Online  Up              2.5.5.0-bef5691 3.10.0-1127.el7.x86_64       Red Hat Enterprise Linux Server 7.6 (Maipo)
        192.168.81.67      31ca65fc-b99f-4543-9b5a-426616b5c15e    w-3.example.localdomain     Yes             37 GiB  300 GiB         Online  Up (This node)  2.5.5.0-bef5691 3.10.0-1127.el7.x86_64       Red Hat Enterprise Linux Server 7.6 (Maipo)
Global Storage Pool
        Total Used      :  112 GiB
        Total Capacity  :  900 GiB

また、既存の3ノードがKVDBクラスターのメンバーとなっています。

# kubectl exec $PX_POD -n kube-system -- /opt/pwx/bin/pxctl service kvdb members
Kvdb Cluster Members:
ID                                      PEER URLs                               CLIENT URLs                     LEADER  HEALTHY DBSIZE
31ca65fc-b99f-4543-9b5a-426616b5c15e    [http://portworx-1.internal.kvdb:9018]  [http://192.168.81.67:9019]        false   true    1.6 MiB
390db093-1874-49f4-b943-8775470fa935    [http://portworx-3.internal.kvdb:9018]  [http://192.168.81.66:9019]        true    true    1.6 MiB
722c5972-3826-46f6-918e-cf93ecbdb25b    [http://portworx-2.internal.kvdb:9018]  [http://192.168.81.65:9019]        false   true    1.6 MiB

メタデータデバイスとは

Portworxの内部KVDBデータと、ジャーナルやタイムスタンプデータなどのPortworxメタデータのために使用されます。

This metadata drive will be used for storing internal KVDB data as well as Portworx metadata such as journal or timestamp data.

Portworxの内部KVDBとは

バージョン２以降、ビルトインの内部KVDBと共にPortworxをインストールできます。Portworxは自動的にクラスター内の３ノードで構成される内部KVDBクラスターをデプロイします。

[Portworx公式: Internal KVDB] (https://docs.portworx.com/concepts/internal-kvdb/)

こちらがわかりやすかったので以下に引用しておきます。

Portworx のキー/値ストアは、Portworx クラスターの実態に関する唯一の情報源です。 このキー/値ストアを使用できない場合は、Portworx クラスターを操作してデータにアクセスしたりデータを保管したりすることはできません。 Portworx データベースを使用できない場合は、既存のデータは変更も削除もされません。

キー/値ストアをセットアップするには、以下の選択肢があります。

  • Portworx のインストール時にキー/値データベース (KVDB) を自動的にセットアップする
  • Databases for etcd サービス・インスタンスをセットアップする

Portworx KVDB の使用

Portworx のインストール時に、ワーカー・ノードに接続されている追加のローカル・ディスク上のスペースを使用するキー/値データベース (KVDB) を自動的にセットアップします。

Portworx に含まれている内部キー/値データベース (KVDB) を使用することで、Portworx メタデータをクラスター内部に保持し、Portworx に保管するオペレーショナル・データとメタデータを一緒に保管することが可能になります。 内部 Portworx KVDB の一般情報については、Portworx の資料を参照してください。

追加用wokerノード

追加用workerノードの構成として、次の３種類の追加ディスク構成を試しました。
追加ディスク以外はすべて同じ構成・設定です。

Case# サーバー vCPU Memory OS Disk 追加Disk#1 追加Disk#2 OS ホスト名 IP Address
1 workerノード 4 16vCPU 64GByte 200G なし なし RHEL7.8 w-4.example.localdomain 192.168.81.68
2 workerノード 4 16vCPU 64GByte 200G 300G なし RHEL7.8 w-4.example.localdomain 192.168.81.68
3 workerノード 4 16vCPU 64GByte 200G 300G 100G RHEL7.8 w-4.example.localdomain 192.168.81.68

注) 既存workerノードと同じRHEL7.6で構築していましたが、OCPクラスターへの追加の準備作業中に意図せずRHEL7.8になってしまいました。

検証手順

  1. 追加用workerノードを準備します。参照：OCP3.11 ホストの準備
    Portworxについて何も考慮する必要はありません。通常の新規workerノードと同じ準備だけが必要です。

  2. (Case#2,3の場合) 追加用workerノードに追加ディスクを接続します。

  3. OCPクラスターに追加用workerノードを追加します。参照：OCP3.11 ホストの追加

  4. 追加された新規workerノードでPortworxが稼働していることを確認します。

PortworxはDaemonSetとしてデプロイされているため、クラスターへ新規ノードが追加されると自動的にそのノードにpodが追加されます。

DaemonSet

検証結果

Case#1: Rawディスクを１つも持たないworkerノードの追加

こちらのとおり、今回のOCP 3.11では、Rawディスクを１つも持たないworkerノードを追加したところ、自動的にストレージなしのノードとしてPortworxクラスターに追加されました。KVDBクラスターのメンバーは既存の３つのworkerノードのままです。

下のpxctl statusコマンドのアウトプット Cluster SummaryでNodes: 3 node(s) with storage (3 online), 1 node(s) without storage (1 online)となっていることを確認できます。

ストレージなしのノードについて ノードにストレージ・デバイスがないが、ノードに Portworx がインストールされている場合、そのノードはストレージなし のノードと見なされます。ストレージ・ノードとストレージなしのノードの両方がライセンスでカウントされます。OpenShift® v4.5 または v4.6 では、Portworx をインストールする前に、計算ノードに px/storageless=true のラベルを付けて、ノードをストレージなしにすることができます。例えば、oc label nodes node1 node2 px/storageless=true のようにします。OpenShift v3.11 では、ローカルのフォーマットされていないデバイスがない計算ノードは、自動的にストレージなしのノードとみなされます。 
# kubectl exec $PX_POD -n kube-system -- /opt/pwx/bin/pxctl status
Status: PX is operational
License: IBM Cloud Pak for Data
Node ID: 31ca65fc-b99f-4543-9b5a-426616b5c15e
	IP: 192.168.81.67 
 	Local Storage Pool: 1 pool
	POOL	IO_PRIORITY	RAID_LEVEL	USABLE	USED	STATUS	ZONE	REGION
	0	LOW		raid0		300 GiB	37 GiB	Online	default	default
	Local Storage Devices: 1 device
	Device	Path		Media Type		Size		Last-Scan
	0:1	/dev/sdb	STORAGE_MEDIUM_MAGNETIC	300 GiB		16 Dec 21 19:23 UTC
	total			-			300 GiB
	Cache Devices:
	No cache devices
	Metadata Device: 
	1	/dev/sdc	STORAGE_MEDIUM_MAGNETIC
Cluster Summary
	Cluster ID: px-cluster-65f5582a-5643-40e7-a988-81d4fa38b329
	Cluster UUID: 35a9e214-3808-4a6e-b5e0-d2c87035e77d
	Scheduler: kubernetes
	Nodes: 3 node(s) with storage (3 online), 1 node(s) without storage (1 online)
	IP		ID					SchedulerNodeName		StorageNode	Used	Capacity	Status	StorageStatus	Version		Kernel				OS
	192.168.81.65	722c5972-3826-46f6-918e-cf93ecbdb25b	w-1.example.localdomain	Yes		37 GiB	300 GiB		Online	Up		2.5.5.0-bef5691	3.10.0-1127.el7.x86_64		Red Hat Enterprise Linux Server 7.6 (Maipo)
	192.168.81.66	390db093-1874-49f4-b943-8775470fa935	w-2.example.localdomain	Yes		37 GiB	300 GiB		Online	Up		2.5.5.0-bef5691	3.10.0-1127.el7.x86_64		Red Hat Enterprise Linux Server 7.6 (Maipo)
	192.168.81.67	31ca65fc-b99f-4543-9b5a-426616b5c15e	w-3.example.localdomain	Yes		37 GiB	300 GiB		Online	Up (This node)	2.5.5.0-bef5691	3.10.0-1127.el7.x86_64		Red Hat Enterprise Linux Server 7.6 (Maipo)
	192.168.81.68	75e0425f-79bc-4faa-a94b-49ff5eb2dec5	w-4.example.localdomain	No		0 B	0 B		Online	No Storage	2.5.5.0-bef5691	3.10.0-1127.19.1.el7.x86_64	Red Hat Enterprise Linux Server 7.8 (Maipo)
Global Storage Pool
	Total Used    	:  111 GiB
	Total Capacity	:  900 GiB


# kubectl exec $PX_POD -n kube-system -- /opt/pwx/bin/pxctl service kvdb members
Kvdb Cluster Members: 
ID					PEER URLs				CLIENT URLs			LEADER	HEALTHY	DBSIZE
31ca65fc-b99f-4543-9b5a-426616b5c15e	[http://portworx-1.internal.kvdb:9018]	[http://192.168.81.67:9019]	false	true	1.6 MiB
390db093-1874-49f4-b943-8775470fa935	[http://portworx-3.internal.kvdb:9018]	[http://192.168.81.66:9019]	false	true	1.6 MiB
722c5972-3826-46f6-918e-cf93ecbdb25b	[http://portworx-2.internal.kvdb:9018]	[http://192.168.81.65:9019]	true	true	1.6 MiB

Case#2: Rawディスクを１つだけ持つworkerノードの追加

１つのRawディスクを持っている場合のデバイス名はこのシステムでは/dev/sdbとなっています。

# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   200G  0 disk
tqsda1   8:1    0     1G  0 part /boot
tqsda2   8:2    0   7.9G  0 part
mqsda3   8:3    0 191.1G  0 part /
sdb      8:16   0   300G  0 disk
sr0     11:0    1  1024M  0 rom

１つのRawディスク(/dev/sdb)を持つworkerノードを追加したところ、今回のPortworx環境では/dev/sdbはストレージデバイスとなっているため、このデバイスはストレージデバイスとして認識され、ストレージありのノードとしてPortworxクラスターに追加されました。KVDBクラスターのメンバーは既存の３つのworkerノードのままです。

下のpxctl statusコマンドのアウトプット Cluster SummaryでNodes: 4 node(s) with storage (4 online)となっていることを確認できます。

ちなみに、Rawディスクについて、Portworxはデバイス名で判断し、サイズには影響を受けないようです。/dev/sdbとして100GBのRawディスクを持つノードを追加した場合でも同様の結果（100GBのデバイスがストレージデバイスとなる）になりました。

# kubectl exec $PX_POD -n kube-system -- /opt/pwx/bin/pxctl status
Status: PX is operational
License: IBM Cloud Pak for Data
Node ID: 31ca65fc-b99f-4543-9b5a-426616b5c15e
        IP: 192.168.81.67
        Local Storage Pool: 1 pool
        POOL    IO_PRIORITY     RAID_LEVEL      USABLE  USED    STATUS  ZONE    REGION
        0       LOW             raid0           300 GiB 37 GiB  Online  default default
        Local Storage Devices: 1 device
        Device  Path            Media Type              Size            Last-Scan
        0:1     /dev/sdb        STORAGE_MEDIUM_MAGNETIC 300 GiB         21 Dec 21 09:46 UTC
        total                   -                       300 GiB
        Cache Devices:
        No cache devices
        Metadata Device:
        1       /dev/sdc        STORAGE_MEDIUM_MAGNETIC
Cluster Summary
        Cluster ID: px-cluster-65f5582a-5643-40e7-a988-81d4fa38b329
        Cluster UUID: 35a9e214-3808-4a6e-b5e0-d2c87035e77d
        Scheduler: kubernetes
        Nodes: 4 node(s) with storage (4 online)
        IP              ID                                      SchedulerNodeName               StorageNode     Used    Capacity        Status  StorageStatus   Version         Kernel                               OS
        192.168.81.65      722c5972-3826-46f6-918e-cf93ecbdb25b    w-1.example.localdomain     Yes             37 GiB  300 GiB         Online  Up              2.5.5.0-bef5691 3.10.0-1127.el7.x86_64               Red Hat Enterprise Linux Server 7.6 (Maipo)
        192.168.81.66      390db093-1874-49f4-b943-8775470fa935    w-2.example.localdomain     Yes             37 GiB  300 GiB         Online  Up              2.5.5.0-bef5691 3.10.0-1127.el7.x86_64               Red Hat Enterprise Linux Server 7.6 (Maipo)
        192.168.81.67      31ca65fc-b99f-4543-9b5a-426616b5c15e    w-3.example.localdomain     Yes             37 GiB  300 GiB         Online  Up (This node)  2.5.5.0-bef5691 3.10.0-1127.el7.x86_64               Red Hat Enterprise Linux Server 7.6 (Maipo)
        192.168.81.68      15db9486-958e-438a-9fb5-699df99a1862    w-4.example.localdomain     Yes             12 GiB  300 GiB         Online  Up              2.5.5.0-bef5691 3.10.0-1127.19.1.el7.x86_64  Red Hat Enterprise Linux Server 7.8 (Maipo)
Global Storage Pool
        Total Used      :  124 GiB
        Total Capacity  :  1.2 TiB

# kubectl exec $PX_POD -n kube-system -- /opt/pwx/bin/pxctl service kvdb members
Kvdb Cluster Members:
ID                                      PEER URLs                               CLIENT URLs                     LEADER  HEALTHY DBSIZE
31ca65fc-b99f-4543-9b5a-426616b5c15e    [http://portworx-1.internal.kvdb:9018]  [http://192.168.81.67:9019]        false   true    1.6 MiB
390db093-1874-49f4-b943-8775470fa935    [http://portworx-3.internal.kvdb:9018]  [http://192.168.81.66:9019]        false   true    1.6 MiB
722c5972-3826-46f6-918e-cf93ecbdb25b    [http://portworx-2.internal.kvdb:9018]  [http://192.168.81.65:9019]        true    true    1.6 MiB

Case#3: 既存workerノードと同じデバイス名で、２つのRawディスクを持っているworkerノードの追加

２つのRawディスクを持っている場合のデバイス名は、既存のworkerノードと同様、このシステムでは/dev/sdbと/dev/sdcとなっています。

# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   200G  0 disk
tqsda1   8:1    0     1G  0 part /boot
tqsda2   8:2    0   7.9G  0 part [SWAP]
mqsda3   8:3    0 191.1G  0 part /
sdb      8:16   0   300G  0 disk
sdc      8:32   0   100G  0 disk
sr0     11:0    1  1024M  0 rom

２つのRawディスクを持つworkerノードを追加したところ、Case#2の１つのRawディスク(/dev/sdb)を持つworkerノードの追加と同じ結果になりました。今回のPortworx環境では/dev/sdbはストレージデバイスとなっているため、/dev/sdbのデバイスがストレージデバイスとして認識され、ストレージありのノードとしてPortworxクラスターに追加されました。KVDBクラスターのメンバーは既存の３つのworkerノードのままです。

下のpxctl statusコマンドのアウトプット Cluster SummaryでNodes: 4 node(s) with storage (4 online)となっていることを確認できます。

# kubectl exec $PX_POD -n kube-system -- /opt/pwx/bin/pxctl status
Status: PX is operational
License: IBM Cloud Pak for Data
Node ID: 31ca65fc-b99f-4543-9b5a-426616b5c15e
        IP: 192.168.81.67
        Local Storage Pool: 1 pool
        POOL    IO_PRIORITY     RAID_LEVEL      USABLE  USED    STATUS  ZONE    REGION
        0       LOW             raid0           300 GiB 37 GiB  Online  default default
        Local Storage Devices: 1 device
        Device  Path            Media Type              Size            Last-Scan
        0:1     /dev/sdb        STORAGE_MEDIUM_MAGNETIC 300 GiB         21 Dec 21 11:14 UTC
        total                   -                       300 GiB
        Cache Devices:
        No cache devices
        Metadata Device:
        1       /dev/sdc        STORAGE_MEDIUM_MAGNETIC
Cluster Summary
        Cluster ID: px-cluster-65f5582a-5643-40e7-a988-81d4fa38b329
        Cluster UUID: 35a9e214-3808-4a6e-b5e0-d2c87035e77d
        Scheduler: kubernetes
        Nodes: 4 node(s) with storage (4 online)
        IP              ID                                      SchedulerNodeName               StorageNode     Used    Capacity        Status  StorageStatus   Version         Kernel                               OS
        192.168.81.65      722c5972-3826-46f6-918e-cf93ecbdb25b    w-1.example.localdomain     Yes             37 GiB  300 GiB         Online  Up              2.5.5.0-bef5691 3.10.0-1127.el7.x86_64               Red Hat Enterprise Linux Server 7.6 (Maipo)
        192.168.81.66      390db093-1874-49f4-b943-8775470fa935    w-2.example.localdomain     Yes             37 GiB  300 GiB         Online  Up              2.5.5.0-bef5691 3.10.0-1127.el7.x86_64               Red Hat Enterprise Linux Server 7.6 (Maipo)
        192.168.81.67      31ca65fc-b99f-4543-9b5a-426616b5c15e    w-3.example.localdomain     Yes             37 GiB  300 GiB         Online  Up (This node)  2.5.5.0-bef5691 3.10.0-1127.el7.x86_64               Red Hat Enterprise Linux Server 7.6 (Maipo)
        192.168.81.68      0768e59e-0ea9-48b8-a9de-08a198c23a57    w-4.example.localdomain     Yes             12 GiB  300 GiB         Online  Up              2.5.5.0-bef5691 3.10.0-1127.19.1.el7.x86_64  Red Hat Enterprise Linux Server 7.8 (Maipo)
Global Storage Pool
        Total Used      :  124 GiB
        Total Capacity  :  1.2 TiB

# kubectl exec $PX_POD -n kube-system -- /opt/pwx/bin/pxctl service kvdb members
Kvdb Cluster Members:
ID                                      PEER URLs                               CLIENT URLs                     LEADER  HEALTHY DBSIZE
31ca65fc-b99f-4543-9b5a-426616b5c15e    [http://portworx-1.internal.kvdb:9018]  [http://192.168.81.67:9019]        false   true    1.6 MiB
390db093-1874-49f4-b943-8775470fa935    [http://portworx-3.internal.kvdb:9018]  [http://192.168.81.66:9019]        true    true    1.6 MiB
722c5972-3826-46f6-918e-cf93ecbdb25b    [http://portworx-2.internal.kvdb:9018]  [http://192.168.81.65:9019]        false   true    1.6 MiB

しかしながら、追加したノードの2つ目のRawディスク/dev/sdcがメタデータデバイスとして使用されているかどうかは確認できませんでした(確認方法を知らないためです)。

なお、内部KVDBクラスターは３ノード構成なので、既存のKVDBクラスターのメンバーが正常稼働している限り、追加したノードがメンバーとして入れ替わることはありません。
試しに、既存のノードの１つ192.168.81.67をshutdownして様子を見たところ、shutdownしたノードに替わって追加したノード192.168.81.68がKVDBクラスターのメンバーになることを確認できました。

# kubectl exec $PX_POD -n kube-system -- /opt/pwx/bin/pxctl service kvdb members
Kvdb Cluster Members:
ID                                      PEER URLs                               CLIENT URLs                     LEADER  HEALTHY DBSIZE
390db093-1874-49f4-b943-8775470fa935    [http://portworx-3.internal.kvdb:9018]  [http://192.168.81.66:9019]        true    true    1.6 MiB
722c5972-3826-46f6-918e-cf93ecbdb25b    [http://portworx-2.internal.kvdb:9018]  [http://192.168.81.65:9019]        false   true    1.6 MiB
0768e59e-0ea9-48b8-a9de-08a198c23a57    [http://portworx-1.internal.kvdb:9018]  [http://192.168.81.68:9019]        false   true    1.6 MiB

まとめ

OCP3.11クラスター上のPortworx環境にworkerノードを追加すると、

  • 追加されたworkerノードは、追加作業なしにPortworxクラスターに加わります。
  • 追加されたworkerノードに、Portworxストレージデバイスとして設定されたデバイス名を持つRawディスクがあれば、そのデバイスがストレージデバイスとして使用され、ストレージありのノードとしてPortworxクラスターに追加されます。
  • 追加されたworkerノードに、Portworxストレージデバイスとして設定されたデバイス名を持つRawディスクがなければ、ストレージなしのノードとしてPortworxクラスターに追加されます。
  • 追加されたworkerノードに、メタデータデバイスとして設定されたデバイス名を持つRawディスクがあってもなくても、(既存の内部KVDBクラスターのメンバーが正常稼働している限りは) 内部KVDBクラスターのメンバーとはなりません。
2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?