ワーカーノードを準備する
Kubernetes クラスター内のすべてのワーカーノードは、ポッド用にプロビジョニングしたボリュームをマウントできる必要があります。ワーカーノードを準備するには、ドライバーの選択に基づいて、NFS、iSCSI、NVMe/TCP、または FC ツールをインストールする必要があります。
適切なツールの選択
複数のドライバーを組み合わせて使用している場合は、ドライバーに必要なすべてのツールをインストールする必要があります。 Red Hat Enterprise Linux CoreOS (RHCOS) の最近のバージョンには、ツールがデフォルトでインストールされています。
"NFSツールをインストールする"使用している場合: ontap-nas 、 ontap-nas-economy 、 ontap-nas-flexgroup 、 azure-netapp-files 、 gcp-cvs 。
"iSCSIツールをインストールする"使用している場合: ontap-san 、 ontap-san-economy 、 solidfire-san 。
"NVMeツールをインストールする"使用している場合 `ontap-san`不揮発性メモリ エクスプレス (NVMe) over TCP (NVMe/TCP) プロトコル用。
|
|
NetApp は、 NVMe/TCP にはONTAP 9.12 以降を推奨しています。 |
参照"FCおよびFC-NVMe SANホストの構成方法"FC および FC-NVMe SAN ホストの構成の詳細については、こちらをご覧ください。
"FCツールをインストールする"使用している場合 ontap-san`sanTypeを使用 `fcp(SCSI over FC)。
考慮すべき点: * SCSI over FC は、OpenShift および KubeVirt 環境でサポートされています。 * SCSI over FC は Docker ではサポートされていません。 * iSCSI 自己修復は SCSI over FC には適用されません。
ノードサービス検出
Trident は、ノードが iSCSI または NFS サービスを実行できるかどうかを自動的に検出しようとします。
|
|
ノード サービス検出では検出されたサービスを識別しますが、サービスが適切に構成されていることは保証されません。逆に、検出されたサービスが存在しない場合でも、ボリュームのマウントが失敗することは保証されません。 |
Trident は、検出されたサービスを識別するためにノードのイベントを作成します。これらのイベントを確認するには、次のコマンドを実行します。
kubectl get event -A --field-selector involvedObject.name=<Kubernetes node name>
Trident は、 Tridentノード CR 上の各ノードに対して有効になっているサービスを識別します。検出されたサービスを表示するには、次のコマンドを実行します。
tridentctl get node -o wide -n <Trident namespace>
NFSボリューム
オペレーティング システムのコマンドを使用して NFS ツールをインストールします。起動時に NFS サービスが起動されていることを確認します。
sudo yum install -y nfs-utils
sudo apt-get install -y nfs-common
|
|
ボリュームをコンテナに接続するときに障害が発生しないように、NFS ツールをインストールした後、ワーカー ノードを再起動します。 |
iSCSIボリューム
Trident は、 iSCSI セッションを自動的に確立し、LUN をスキャンし、マルチパス デバイスを検出し、フォーマットして、ポッドにマウントできます。
iSCSI 自己修復機能
ONTAPシステムの場合、 Trident は5 分ごとに iSCSI 自己修復を実行して次の処理を実行します。
-
必要な iSCSI セッション状態と現在の iSCSI セッション状態を 識別 します。
-
希望する状態と現在の状態を*比較*して、必要な修復箇所を特定します。 Trident は、修理の優先順位と修理を先取りするタイミングを決定します。
-
現在の iSCSI セッション状態を目的の iSCSI セッション状態に戻すために必要な 修復を実行 します。
|
|
自己修復活動のログは、 `trident-main`それぞれの Daemonset ポッド上のコンテナー。ログを表示するには、設定が必要です `debug`Trident のインストール中に「true」に設定します。 |
Trident iSCSI の自己修復機能は、次のような事態を防ぐのに役立ちます。
-
ネットワーク接続の問題が発生した後に発生する可能性のある、古いまたは異常な iSCSI セッション。セッションが古い場合、 Trident はログアウトしてからポータルとの接続を再確立するまで 7 分間待機します。
たとえば、ストレージ コントローラ上で CHAP シークレットがローテーションされ、ネットワークの接続が失われた場合、古い (stale) CHAP シークレットが残る可能性があります。自己修復機能はこれを認識し、セッションを自動的に再確立して更新された CHAP シークレットを適用します。 -
iSCSIセッションが見つかりません
-
不足しているLUN
-
Tridentをアップグレードする前に考慮すべき点*
-
ノードごとの igroup (23.04 以降で導入) のみが使用されている場合、iSCSI 自己修復により SCSI バス内のすべてのデバイスの SCSI 再スキャンが開始されます。
-
バックエンド スコープの igroup (23.04 以降は非推奨) のみが使用されている場合、iSCSI 自己修復により、SCSI バス内の正確な LUN ID の SCSI 再スキャンが開始されます。
-
ノードごとの igroup とバックエンド スコープの igroup が混在して使用されている場合、iSCSI 自己修復により、SCSI バス内の正確な LUN ID の SCSI 再スキャンが開始されます。
iSCSIツールをインストールする
オペレーティング システムのコマンドを使用して iSCSI ツールをインストールします。
-
Kubernetes クラスター内の各ノードには一意の IQN が必要です。 これは必須の前提条件です。
-
RHCOSバージョン4.5以降、またはその他のRHEL互換Linuxディストリビューションを使用している場合は、
solidfire-san`ドライバーとElement OS 12.5以前を使用している場合は、CHAP認証アルゴリズムがMD5に設定されていることを確認してください。 `/etc/iscsi/iscsid.confElement 12.7 では、安全な FIPS 準拠の CHAP アルゴリズム SHA1、SHA-256、および SHA3-256 が利用できます。sudo sed -i 's/^\(node.session.auth.chap_algs\).*/\1 = MD5/' /etc/iscsi/iscsid.conf
-
iSCSI PVでRHEL/Red Hat Enterprise Linux CoreOS (RHCOS)を実行するワーカーノードを使用する場合は、 `discard`インライン スペース再利用を実行するには、StorageClass の mountOption を使用します。参照 "Red Hat ドキュメント"。
-
最新バージョンにアップグレードしたことを確認してください。
multipath-tools。
-
次のシステム パッケージをインストールします。
sudo yum install -y lsscsi iscsi-initiator-utils device-mapper-multipath
-
iscsi-initiator-utils のバージョンが 6.2.0.874-2.el7 以降であることを確認します。
rpm -q iscsi-initiator-utils
-
スキャンを手動に設定します:
sudo sed -i 's/^\(node.session.scan\).*/\1 = manual/' /etc/iscsi/iscsid.conf
-
マルチパスを有効にする:
sudo mpathconf --enable --with_multipathd y --find_multipaths n
確保する /etc/multipath.conf`含む `find_multipaths no`下 `defaults。 -
確実に `iscsid`そして `multipathd`実行中:
sudo systemctl enable --now iscsid multipathd
-
有効化して起動
iscsi:sudo systemctl enable --now iscsi
-
次のシステム パッケージをインストールします。
sudo apt-get install -y open-iscsi lsscsi sg3-utils multipath-tools scsitools
-
open-iscsi のバージョンが 2.0.874-5ubuntu2.10 以降 (bionic の場合) または 2.0.874-7.1ubuntu6.1 以降 (focal の場合) であることを確認します。
dpkg -l open-iscsi
-
スキャンを手動に設定します:
sudo sed -i 's/^\(node.session.scan\).*/\1 = manual/' /etc/iscsi/iscsid.conf
-
マルチパスを有効にする:
sudo tee /etc/multipath.conf <<-EOF defaults { user_friendly_names yes find_multipaths no } EOF sudo systemctl enable --now multipath-tools.service sudo service multipath-tools restart確保する /etc/multipath.conf`含む `find_multipaths no`下 `defaults。 -
確実に `open-iscsi`そして `multipath-tools`有効になっていて実行中である:
sudo systemctl status multipath-tools sudo systemctl enable --now open-iscsi.service sudo systemctl status open-iscsi
Ubuntu 18.04では、ターゲットポートを次のように検出する必要があります。 `iscsiadm`始める前に `open-iscsi`iSCSI デーモンを起動します。あるいは、 `iscsi`サービスを開始する `iscsid`自動的に。
iSCSI 自己修復を構成または無効にする
古いセッションを修正するには、次のTrident iSCSI 自己修復設定を構成できます。
-
iSCSI 自己修復間隔: iSCSI 自己修復が呼び出される頻度を決定します (デフォルト: 5 分)。小さい数値を設定すると実行頻度が高くなり、大きい数値を設定すると実行頻度が低くなるように設定できます。
|
|
iSCSI 自己修復間隔を 0 に設定すると、iSCSI 自己修復は完全に停止します。 iSCSI 自己修復を無効にすることはお勧めしません。iSCSI 自己修復が意図したとおりに動作していない場合やデバッグ目的の場合など、特定のシナリオでのみ無効にしてください。 |
-
iSCSI 自己修復待機時間: 異常なセッションからログアウトして再度ログインを試行するまでに iSCSI 自己修復が待機する時間を決定します (デフォルト: 7 分)。大きい数値に設定すると、正常でないと判断されたセッションはログアウトされるまでの待機時間が長くなり、その後再度ログインが試行されます。また、小さい数値に設定すると、ログアウトしてから再度ログインするまでの時間が長くなります。
iSCSI自己修復設定を構成または変更するには、 `iscsiSelfHealingInterval`そして `iscsiSelfHealingWaitTime`Helm のインストールまたは Helm の更新中のパラメータ。
次の例では、iSCSI 自己修復間隔を 3 分、自己修復待機時間を 6 分に設定します。
helm install trident trident-operator-100.2506.0.tgz --set iscsiSelfHealingInterval=3m0s --set iscsiSelfHealingWaitTime=6m0s -n trident
iSCSI自己修復設定を構成または変更するには、 `iscsi-self-healing-interval`そして `iscsi-self-healing-wait-time`tridentctl のインストールまたは更新中のパラメータ。
次の例では、iSCSI 自己修復間隔を 3 分、自己修復待機時間を 6 分に設定します。
tridentctl install --iscsi-self-healing-interval=3m0s --iscsi-self-healing-wait-time=6m0s -n trident
NVMe/TCPボリューム
オペレーティング システムのコマンドを使用して NVMe ツールをインストールします。
|
|
|
sudo yum install nvme-cli sudo yum install linux-modules-extra-$(uname -r) sudo modprobe nvme-tcp
sudo apt install nvme-cli sudo apt -y install linux-modules-extra-$(uname -r) sudo modprobe nvme-tcp
インストールの検証
インストール後、次のコマンドを使用して、Kubernetes クラスター内の各ノードに一意の NQN があることを確認します。
cat /etc/nvme/hostnqn
|
|
Tridentは `ctrl_device_tmo`パスがダウンした場合に NVMe がパスを放棄しないようにするための値。この設定は変更しないでください。 |
SCSI over FCボリューム
Tridentでファイバ チャネル (FC) プロトコルを使用して、 ONTAPシステム上のストレージ リソースをプロビジョニングおよび管理できるようになりました。
前提条件
FC に必要なネットワークとノードの設定を構成します。
ネットワーク設定
-
ターゲット インターフェイスの WWPN を取得します。参照 "network interface show"詳細についてはこちらをご覧ください。
-
イニシエーター (ホスト) 上のインターフェースの WWPN を取得します。
対応するホスト オペレーティング システム ユーティリティを参照してください。
-
ホストとターゲットの WWPN を使用して FC スイッチのゾーニングを構成します。
詳細については、それぞれのスイッチベンダーのドキュメントを参照してください。
詳細については、次のONTAPドキュメントを参照してください。
FCツールをインストールする
オペレーティング システムのコマンドを使用して FC ツールをインストールします。
-
FC PVでRHEL/Red Hat Enterprise Linux CoreOS (RHCOS)を実行するワーカーノードを使用する場合は、 `discard`インライン スペース再利用を実行するには、StorageClass の mountOption を使用します。参照 "Red Hat ドキュメント"。
-
次のシステム パッケージをインストールします。
sudo yum install -y lsscsi device-mapper-multipath
-
マルチパスを有効にする:
sudo mpathconf --enable --with_multipathd y --find_multipaths n
確保する /etc/multipath.conf`含む `find_multipaths no`下 `defaults。 -
確実に `multipathd`実行中:
sudo systemctl enable --now multipathd
-
次のシステム パッケージをインストールします。
sudo apt-get install -y lsscsi sg3-utils multipath-tools scsitools
-
マルチパスを有効にする:
sudo tee /etc/multipath.conf <<-EOF defaults { user_friendly_names yes find_multipaths no } EOF sudo systemctl enable --now multipath-tools.service sudo service multipath-tools restart確保する /etc/multipath.conf`含む `find_multipaths no`下 `defaults。 -
確実に `multipath-tools`有効になっていて実行中:
sudo systemctl status multipath-tools