3.2.2. Block Storage 上のノードの置き換え
リソースが不足しているか、または異常が発生したノードからブロックを置き換える場合は、新しいノードに置き換えることができます。
以下のコマンドを実行します。
以下のコマンドを実行して、heketi からゾーンおよびクラスター情報を取得します。
# heketi-cli topology info --user=<user> --secret=<user key>
- --user
- heketi ユーザー
- --secret
- 指定されたユーザーのシークレットキー
- クラスター ID およびゾーン ID を取得したら、Adding New Nodes を参照して新規ノードを追加します。
次のコマンドを実行してデバイスを追加します。
# heketi-cli device add --name=<device name> --node=<node id> --user=<user> --secret=<user key>
- --name
- 追加するデバイスの名前
- --node
- 新たに追加されたノードの ID
以下に例を示します。
# heketi-cli device add --name=/dev/vdc --node=2639c473a2805f6e19d45997bb18cb9c --user=admin --secret=adminkey Device added successfully
新規ノードとその関連デバイスを heketi に追加した後に、障害が発生したまたは不要なノードを heketi から削除できます。
heketi からノードを削除するには、以下のワークフローに従います。
- ノードの無効化 (オフラインにしてノードの使用の禁止する)
- ノードの置き換え (ノードとその関連デバイスすべてを Heketi から削除する)
- デバイスの削除 (Heketi ノードからデバイスを削除する)
- ノードの削除 (Heketi 管理からのノードを削除する)
以下のコマンドを実行して、heketi からノード一覧を取得します。
#heketi-cli node list --user=<user> --secret=<user key>
以下に例を示します。
# heketi-cli node list --user=admin --secret=adminkey Id:05746c562d6738cb5d7de149be1dac04 Cluster:607204cb27346a221f39887a97cf3f90 Id:ab37fc5aabbd714eb8b09c9a868163df Cluster:607204cb27346a221f39887a97cf3f90 Id:c513da1f9bda528a9fd6da7cb546a1ee Cluster:607204cb27346a221f39887a97cf3f90 Id:e6ab1fe377a420b8b67321d9e60c1ad1 Cluster:607204cb27346a221f39887a97cf3f90
以下のコマンドを実行して、heketi から削除する必要があるノードのノード情報を取得します。
# heketi-cli node info <nodeid> --user=<user> --secret=<user key>
以下に例を示します。
# heketi-cli node info c513da1f9bda528a9fd6da7cb546a1ee --user=admin --secret=adminkey Node Id: c513da1f9bda528a9fd6da7cb546a1ee State: online Cluster Id: 607204cb27346a221f39887a97cf3f90 Zone: 1 Management Hostname: dhcp43-171.lab.eng.blr.redhat.com Storage Hostname: 10.70.43.171 Devices: Id:3a1e0717e6352a8830ab43978347a103 Name:/dev/vdc State:online Size (GiB):499 Used (GiB):100 Free (GiB):399 Bricks:1 Id:89a57ace1c3184826e1317fef785e6b7 Name:/dev/vdd State:online Size (GiB):499 Used (GiB):10 Free (GiB):489 Bricks:5
以下のコマンドを実行して、heketi からノードを無効にします。これにより、ノードがオフラインになります。
# heketi-cli node disable <node-id> --user=<user> --secret=<user key>
以下に例を示します。
# heketi-cli node disable ab37fc5aabbd714eb8b09c9a868163df --user=admin --secret=adminkey Node ab37fc5aabbd714eb8b09c9a868163df is now offline
以下のコマンドを実行して、Heketi からノードとその関連デバイスをすべて削除します。
#heketi-cli node remove <node-id> --user=<user> --secret=<user key>
以下に例を示します。
# heketi-cli node remove ab37fc5aabbd714eb8b09c9a868163df --user=admin --secret=adminkey Node ab37fc5aabbd714eb8b09c9a868163df is now removed
以下のコマンドを実行して、heketi ノードからデバイスを削除します。
# heketi-cli device delete <device-id> --user=<user> --secret=<user key>
以下に例を示します。
# heketi-cli device delete 0fca78c3a94faabfbe5a5a9eef01b99c --user=admin --secret=adminkey Device 0fca78c3a94faabfbe5a5a9eef01b99c deleted
以下のコマンドを実行して、Heketi 管理からノードを削除します。
#heketi-cli node delete <nodeid> --user=<user> --secret=<user key>
以下に例を示します。
# heketi-cli node delete ab37fc5aabbd714eb8b09c9a868163df --user=admin --secret=adminkey Node ab37fc5aabbd714eb8b09c9a868163df deleted
いずれかの gluster Pod で以下のコマンドを実行して、障害のあるノードを新しいノードに置き換えます。
以下のコマンドを実行して、block-hosting-volume 配下でホストされるブロックボリュームの一覧を取得します。
# gluster-block list <block-hosting-volume> --json-pretty
以下のコマンドを実行して、ブロックボリュームをホストするサーバーの一覧を取得し、後で使用できるように GBID および PASSWORD の値を保存します。
# gluster-block info <block-hosting-volume>/<block-volume> --json-pretty
以下のコマンドを実行して、障害のあるノードを新しいノードに置き換えます。
# gluster-block replace <volname/blockname> <old-node> <new-node> [force]
以下に例を示します。
{ "NAME":"block", "CREATE SUCCESS":"192.168.124.73", "DELETE SUCCESS":"192.168.124.63", "REPLACE PORTAL SUCCESS ON":[ "192.168.124.79" ], "RESULT":"SUCCESS" } Note: If the old node is down and does not come up again then you can force replace: gluster-block replace sample/block 192.168.124.63 192.168.124.73 force --json-pretty { "NAME":"block", "CREATE SUCCESS":"192.168.124.73", "DELETE FAILED (ignored)":"192.168.124.63", "REPLACE PORTAL SUCCESS ON":[ "192.168.124.79" ], "RESULT":"SUCCESS" }
注記次の手順は、置き換えるブロックがまだ使用中の場合にのみ実行されます。
ブロックボリュームが現在マウントされていない場合は、この手順を省略します。ブロックボリュームがアプリケーションで使用されている場合は、イニシエーター側でマッパーデバイスをリロードする必要があります。
イニシエーターノードとターゲット名を特定します。
イニシエーターノードを把握するには、以下を実行します。
# oc get pods -o wide | grep <podname>
ここで、podname は、ブロックボリュームがマウントされる Pod の名前です。
以下に例を示します。
# oc get pods -o wide | grep cirros1 cirros1-1-x6b5n 1/1 Running 0 1h 10.130.0.5 dhcp46-31.lab.eng.blr.redhat.com <none>
ターゲット名を把握するには、以下を実行します。
# oc describe pv <pv_name> | grep IQN
以下に例を示します。
# oc describe pv pvc-c50c69db-5f76-11ea-b27b-005056b253d1 | grep IQN IQN: iqn.2016-12.org.gluster-block:87ffbcf3-e21e-4fa5-bd21-7db2598e8d3f
イニシエーターノードで以下のコマンドを実行して、マッパーデバイスを把握します。
# mount | grep <targetname>
マッパーデバイスを再読み込みします。
# multipath -r mpathX
以下に例を示します。
# mount | grep iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a/dev/mapper/mpatha on /var/lib/origin/openshift.local.volumes/plugins/kubernetes.io/iscsi/iface-default/192.168.124.63:3260-iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a-lun-0 type xfs (rw,relatime,seclabel,attr2,inode64,noquota) # multipath -r mpatha
イニシエーターで以下のコマンドを実行し、古いポータルからログアウトします。
# iscsiadm -m node -T <targetname> -p <old node> -u
以下に例を示します。
# iscsiadm -m node -T iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a -p 192.168.124.63 -u Logging out of session [sid: 8, target: iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a, portal: 192.168.124.63,3260] Logout of [sid: 8, target: iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a, portal: 192.168.124.63,3260] successful.
新しいノードを再検出するには、以下のコマンドを実行します。
# iscsiadm -m discovery -t st -p <new node>
以下に例を示します。
# iscsiadm -m discovery -t st -p 192.168.124.73 192.168.124.79:3260,1 iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a 192.168.124.73:3260,2 iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a
以下を実行して新しいポータルにログインします。
認証の認証情報を更新します (ステップ 11ii の GBID および PASSWORD を使用)
# iscsiadm -m node -T <targetname> -o update -n node.session.auth.authmethod -v CHAP -n node.session.auth.username -v <GBID> -n node.session.auth.password -v <PASSWORD> -p <new node ip>
新しいポータルにログインします。
# iscsiadm -m node -T <targetname> -p <new node ip> -l
以下に例を示します。
# iscsiadm -m node -T iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a -o update -n node.session.auth.authmethod -v CHAP -n node.session.auth.username -v d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a -n node.session.auth.password -v a6a9081f-3d0d-4e8b-b9b0-d2be703b455d -p 192.168.124.73 # iscsiadm -m node -T iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a -p 192.168.124.73 -l
有効にしたホストボリュームが正常に置き換えられ、実行されているかどうかを確認するには、イニシエーターで以下のコマンドを実行します。
# ll /dev/disk/by-path/ip-* | grep <targetname> | grep <“new node ip”>
gluster ブロックの永続ボリューム (PV) を新しい IP アドレスで更新してください。
PV は定義によって不変であるため、PV を編集することはできません。つまり、PV の古い IP アドレスを変更できません。この問題を回避する手順 (新しい PV を作成し、ストレージデバイスで古い PV 定義を削除) を含むドキュメントが作成されました。Red Hat ナレッジベースソリューションの Gluster block PVs are not updated with new IPs after gluster node replacement を参照してください。
