ワーカーノードを準備する
Kubernetes クラスター内のすべてのワーカーノードは、ポッド用にプロビジョニングしたボリュームをマウントできる必要があります。ワーカーノードを準備するには、ドライバーの選択に基づいて、NFS、iSCSI、NVMe/TCP、または FC ツールをインストールする必要があります。
適切なツールの選択
複数のドライバーを組み合わせて使用している場合は、ドライバーに必要なすべてのツールをインストールする必要があります。Red Hat Enterprise Linux CoreOS (RHCOS) の最近のバージョンには、ツールがデフォルトでインストールされています。
"NFSツールをインストールする"使用している場合: ontap-nas、 ontap-nas-economy、 ontap-nas-flexgroup、または azure-netapp-files。
"iSCSIツールをインストールする"使用している場合: ontap-san、 ontap-san-economy、 solidfire-san。
"NVMeツールをインストールする"Nonvolatile Memory Express(NVMe)over TCP(NVMe/TCP)プロトコルに `ontap-san`を使用している場合。
|
|
NetAppでは、NVMe/TCPにはONTAP 9.12以降を推奨しています。 |
FC および FC-NVMe SAN ホストの設定の詳細については、"FCおよびFC-NVMe SANホストの構成方法"を参照してください。
"FCツールをインストールする" sanType を ontap-san(SCSI over FC)で使用している場合 fcp。
考慮すべき点: * SCSI over FCはOpenShiftおよびKubeVirt環境でサポートされています。* SCSI over FCはDockerではサポートされていません。* iSCSI自己修復はSCSI over FCには適用されません。
"SMB ボリュームのプロビジョニングの準備"使用している場合: `ontap-nas`SMBボリュームをプロビジョニングします。
ノードサービス検出
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はiSCSI自己修復を5分ごとに実行します:
-
必要な iSCSI セッション状態と現在の iSCSI セッション状態を*識別*します。
-
必要な修復を特定するには、希望する状態と現在の状態を*比較*します。Tridentは修復の優先順位と修復を先取りするタイミングを決定します。
-
現在のiSCSIセッション状態を目的のiSCSIセッション状態に戻すために必要な*修復を実行*します。
|
|
自己修復アクティビティのログは、それぞれのDaemonsetポッド上の `trident-main`コンテナにあります。ログを表示するには、Tridentのインストール時に `debug`を「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以前とともに使用している場合は、 `/etc/iscsi/iscsid.conf`でCHAP認証アルゴリズムがMD5に設定されていることを確認してください。安全なFIPS準拠のCHAPアルゴリズムSHA1、SHA-256、およびSHA3-256は、Element 12.7で利用できます。
sudo sed -i 's/^\(node.session.auth.chap_algs\).*/\1 = MD5/' /etc/iscsi/iscsid.conf
-
iSCSI PVを使用するRHEL/Red Hat Enterprise Linux CoreOS(RHCOS)で動作するワーカーノードを利用する場合、インラインスペースの再利用を実行するために、
discardStorageClass内で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の場合、iSCSIデーモンを起動する前に `iscsiadm`でターゲットポートを検出する必要があります。iSCSIデーモンが起動するためです。 `open-iscsi`または、 `iscsi`サービスを修正して `iscsid`を自動的に起動することもできます。
iSCSI self-healingを設定または無効にする
以下のTrident iSCSI自己修復設定を構成して、古いセッションを修正できます:
-
iSCSI自己修復間隔:iSCSI自己修復が呼び出される頻度を決定します(デフォルト:5分)。小さい数値を設定すると実行頻度が高くなり、大きい数値を設定すると実行頻度が低くなるように設定できます。
|
|
iSCSI自己修復間隔を0に設定すると、iSCSI自己修復が完全に停止します。iSCSI自己修復を無効にすることは推奨しません。iSCSI自己修復が意図したとおりに動作していない特定のシナリオ、またはデバッグ目的の場合にのみ無効にする必要があります。 |
-
iSCSI自己修復待機時間:iSCSI自己修復が異常なセッションからログアウトして再度ログインを試行するまでの待機時間を決定します(デフォルト:7分)。大きい数値に設定すると、正常でないと判断されたセッションはログアウトされるまでの待機時間が長くなり、その後再度ログインが試行されます。また、小さい数値に設定すると、ログアウトしてから再度ログインするまでの時間が短くなります。
iSCSI自己修復設定を構成または変更するには、helmのインストールまたはhelmの更新中に `iscsiSelfHealingInterval`および `iscsiSelfHealingWaitTime`パラメータを渡します。
次の例では、iSCSI自己修復間隔を3分にし、自己修復待ち時間を6分にします:
helm install trident trident-operator-100.2506.0.tgz --set iscsiSelfHealingInterval=3m0s --set iscsiSelfHealingWaitTime=6m0s -n trident
iSCSI自己修復設定を構成または変更するには、tridentctlのインストールまたは更新中に `iscsi-self-healing-interval`および `iscsi-self-healing-wait-time`パラメータを渡します。
次の例では、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は、パスがダウンした場合にNVMeがパスを放棄しないようにするために `ctrl_device_tmo`の値を変更します。この設定は変更しないでください。 |
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)上のワーカーノードを利用する場合、インラインスペースリクレームを実行するために、
discardStorageClassで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
SMB ボリュームのプロビジョニングの準備
`ontap-nas`ドライバーを使用してSMBボリュームをプロビジョニングできます。
|
|
ONTAP オンプレミスクラスタ用の ontap-nas-economy SMB ボリュームを作成するには、SVM で NFS と SMB/CIFS プロトコルの両方を設定する必要があります。これらのプロトコルのいずれかを設定しないと、SMB ボリュームの作成が失敗します。
|
|
|
autoExportPolicy は SMB ボリュームではサポートされません。
|
SMB ボリュームをプロビジョニングする前に、次のものが必要です。
-
Linux コントローラー ノードと、Windows Server 2022 を実行する少なくとも 1 つの Windows ワーカー ノードを備えた Kubernetes クラスター。Trident は、Windows ノード上で実行されているポッドにマウントされた SMB ボリュームのみをサポートします。
-
Active Directory のクレデンシャルを含む少なくとも 1 つの Trident シークレット。シークレットを生成するには
smbcreds:kubectl create secret generic smbcreds --from-literal username=user --from-literal password='password'
-
Windows サービスとして構成された CSI プロキシ。 `csi-proxy`を設定するには、Windows 上で実行されている Kubernetes ノード用の"GitHub:CSI Proxy"または"GitHub:Windows用CSIプロキシ"を参照してください。
-
オンプレミス ONTAP の場合、必要に応じて SMB 共有を作成するか、 Trident に作成させることができます。
SMB 共有は Amazon FSx for ONTAP に必要です。 SMB 管理共有は、"Microsoft管理コンソール" 共有フォルダスナップインまたは ONTAP CLI のいずれかを使用して、2 つの方法のいずれかで作成できます。ONTAP CLI を使用して SMB 共有を作成するには:
-
必要に応じて、共有のディレクトリ パス構造を作成します。
`vserver cifs share create`コマンドは、共有の作成中に -path オプションで指定されたパスをチェックします。指定されたパスが存在しない場合、コマンドは失敗します。
-
指定された SVM に関連付けられた SMB 共有を作成します:
vserver cifs share create -vserver vserver_name -share-name share_name -path path [-share-properties share_properties,...] [other_attributes] [-comment text]
-
共有が作成されたことを確認します:
vserver cifs share show -share-name share_name
詳細については、"SMB共有を作成する"を参照してください。
-
-
バックエンドを作成するときは、SMB ボリュームを指定するために以下を構成する必要があります。すべての FSx for ONTAP バックエンドの設定オプションについては、"FSx for ONTAP 設定オプションと例"を参照してください。
パラメータ 概要 例 smbShare次のいずれかを指定できます:Microsoft Management ConsoleまたはONTAP CLIを使用して作成されたSMB共有の名前、TridentがSMB共有を作成できるようにする名前、またはパラメータを空白のままにしてボリュームへの共通共有アクセスを防止できます。このパラメータは、オンプレミスONTAPではオプションです。このパラメータは、Amazon FSx for ONTAPバックエンドでは必須であり、空白にすることはできません。
smb-sharenasType* `smb`に設定する必要があります。*nullの場合、デフォルトは `nfs`です。
smbsecurityStyle新しいボリュームのセキュリティ スタイル。SMB ボリュームの場合は、 `ntfs`または `mixed`に設定する必要があります。
ntfsまたはmixedSMB ボリューム用unixPermissions新しいボリュームのモード。SMB ボリュームの場合は空のままにする必要があります。
""