準備
瞭解如何準備使用ONTAP 支援不支援的SAN驅動程式來設定支援功能的後端。ONTAP對於所有ONTAP 的不支援端點、Astra Trident至少需要指派一個集合體給SVM。
請記住、您也可以執行多個驅動程式、並建立指向一個或多個驅動程式的儲存類別。例如、您可以設定 san-dev
使用的類別 ontap-san
驅動程式與 san-default
使用的類別 ontap-san-economy
一、
您所有的Kubernetes工作節點都必須安裝適當的iSCSI工具。請參閱 "請按這裡" 以取得更多詳細資料。
驗證
Astra Trident提供兩種驗ONTAP 證功能來驗證支援的後端。
-
認證型:ONTAP 對具備所需權限的使用者名稱和密碼。建議使用預先定義的安全登入角色、例如
admin
或vsadmin
以確保與ONTAP 更新版本的最大相容性。 -
憑證型:Astra Trident也能ONTAP 使用安裝在後端的憑證與某個叢集進行通訊。在此處、後端定義必須包含用戶端憑證、金鑰及信任的CA憑證(建議使用)的Base64編碼值。
使用者也可以選擇更新現有的後端、選擇從認證移至憑證型、反之亦然。如果*同時提供認證資料和憑證*、Astra Trident將預設使用憑證、同時發出警告、從後端定義中移除認證資料。
啟用認證型驗證
Astra Trident需要SVM範圍/叢集範圍管理員的認證資料、才能與ONTAP 該後端進行通訊。建議使用預先定義的標準角色、例如 admin
或 vsadmin
。這可確保與未來ONTAP 的支援版本保持前瞻相容、因為未來的Astra Trident版本可能會使用功能API。您可以建立自訂的安全登入角色、並與Astra Trident搭配使用、但不建議使用。
後端定義範例如下所示:
{ "version": 1, "backendName": "ExampleBackend", "storageDriverName": "ontap-san", "managementLIF": "10.0.0.1", "dataLIF": "10.0.0.2", "svm": "svm_nfs", "username": "vsadmin", "password": "secret", }
請記住、後端定義是唯一以純文字儲存認證的位置。建立後端之後、使用者名稱/密碼會以Base64編碼、並儲存為Kubernetes機密。建立/更新後端是唯一需要知道認證資料的步驟。因此、這是一項純管理員操作、由Kubernetes /儲存管理員執行。
啟用憑證型驗證
新的和現有的後端可以使用憑證、並與ONTAP 該後端通訊。後端定義需要三個參數。
-
用戶端憑證:用戶端憑證的Base64編碼值。
-
用戶端私密金鑰:關聯私密金鑰的Base64編碼值。
-
信任的CACertifate:受信任CA憑證的Base64編碼值。如果使用信任的CA、則必須提供此參數。如果未使用信任的CA、則可忽略此問題。
典型的工作流程包括下列步驟。
-
產生用戶端憑證和金鑰。產生時、請將Common Name(CN)(一般名稱(CN))設定為ONTAP 驗證身分。
openssl req -x509 -nodes -days 1095 -newkey rsa:2048 -keyout k8senv.key -out k8senv.pem -subj "/C=US/ST=NC/L=RTP/O=NetApp/CN=admin"
-
將信任的CA憑證新增ONTAP 至整個叢集。這可能已由儲存管理員處理。如果未使用信任的CA、請忽略。
security certificate install -type server -cert-name <trusted-ca-cert-name> -vserver <vserver-name> ssl modify -vserver <vserver-name> -server-enabled true -client-enabled true -common-name <common-name> -serial <SN-from-trusted-CA-cert> -ca <cert-authority>
-
在ONTAP 支援叢集上安裝用戶端憑證和金鑰(步驟1)。
security certificate install -type client-ca -cert-name <certificate-name> -vserver <vserver-name> security ssl modify -vserver <vserver-name> -client-enabled true
-
確認ONTAP 支援的不安全登入角色
cert
驗證方法。security login create -user-or-group-name admin -application ontapi -authentication-method cert security login create -user-or-group-name admin -application http -authentication-method cert
-
使用產生的憑證測試驗證。以ONTAP Management LIF IP和SVM名稱取代<SfManagement LIF>和<vserver name>。
curl -X POST -Lk https://<ONTAP-Management-LIF>/servlets/netapp.servlets.admin.XMLrequest_filer --key k8senv.key --cert ~/k8senv.pem -d '<?xml version="1.0" encoding="UTF-8"?><netapp xmlns="http://www.netapp.com/filer/admin" version="1.21" vfiler="<vserver-name>"><vserver-get></vserver-get></netapp>'
-
使用Base64編碼憑證、金鑰和信任的CA憑證。
base64 -w 0 k8senv.pem >> cert_base64 base64 -w 0 k8senv.key >> key_base64 base64 -w 0 trustedca.pem >> trustedca_base64
-
使用從上一步取得的值建立後端。
$ cat cert-backend.json { "version": 1, "storageDriverName": "ontap-san", "backendName": "SanBackend", "managementLIF": "1.2.3.4", "dataLIF": "1.2.3.8", "svm": "vserver_test", "clientCertificate": "Faaaakkkkeeee...Vaaalllluuuueeee", "clientPrivateKey": "LS0tFaKE...0VaLuES0tLS0K", "trustedCACertificate": "QNFinfO...SiqOyN", "storagePrefix": "myPrefix_" } $ tridentctl create backend -f cert-backend.json -n trident +------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +------------+----------------+--------------------------------------+--------+---------+ | SanBackend | ontap-san | 586b1cd5-8cf8-428d-a76c-2872713612c1 | online | 0 | +------------+----------------+--------------------------------------+--------+---------+
更新驗證方法或旋轉認證資料
您可以更新現有的後端、以使用不同的驗證方法、或是旋轉其認證資料。這兩種方法都可行:使用使用者名稱/密碼的後端可更新以使用憑證;使用憑證的後端可更新為使用者名稱/密碼。若要這麼做、請使用更新的 backend.json
包含所需執行參數的檔案 tridentctl backend update
。
$ cat cert-backend-updated.json { "version": 1, "storageDriverName": "ontap-san", "backendName": "SanBackend", "managementLIF": "1.2.3.4", "dataLIF": "1.2.3.8", "svm": "vserver_test", "username": "vsadmin", "password": "secret", "storagePrefix": "myPrefix_" } #Update backend with tridentctl $ tridentctl update backend SanBackend -f cert-backend-updated.json -n trident +------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +------------+----------------+--------------------------------------+--------+---------+ | SanBackend | ontap-san | 586b1cd5-8cf8-428d-a76c-2872713612c1 | online | 9 | +------------+----------------+--------------------------------------+--------+---------+
當您旋轉密碼時、儲存管理員必須先更新ONTAP 使用者的密碼(位於BIOS)。接著是後端更新。在循環憑證時、可將多個憑證新增至使用者。然後更新後端以使用新的憑證、之後可從ONTAP 該叢集刪除舊的憑證。 |
更新後端不會中斷對已建立之磁碟區的存取、也不會影響之後建立的磁碟區連線。成功的後端更新顯示Astra Trident可以與ONTAP 該後端通訊、並處理未來的Volume作業。
指定igroup
Astra Trident使用igroup來控制其所配置的磁碟區(LUN)存取。系統管理員在指定後端的igroup時有兩種選擇:
-
Astra Trident可自動建立及管理每個後端的igroup。如果
igroupName
未包含在後端定義中、Astra Trident會建立名為的igrouptrident-<backend-UUID>
在SVM上。如此可確保每個後端都有專屬的igroup、並處理Kubernetes節點IQN的自動新增/刪除作業。 -
或者、也可以在後端定義中提供預先建立的igroup。您可以使用來完成此作業
igroupName
組態參數。Astra Trident會將Kubernetes節點IQN新增/刪除至預先存在的igroup。
適用於具有的後端 igroupName
定義 igroupName
可以使用刪除 tridentctl backend update
使用Astra Trident自動處理igroup。這不會中斷對已附加至工作負載之磁碟區的存取。未來的連線將使用建立的igroup Astra Trident來處理。
針對每個獨特的Astra Trident執行個體指定igroup是最適合Kubernetes管理員和儲存管理員的最佳實務做法。「csi Trident」可自動新增及移除igroup的叢集節點IQN、大幅簡化其管理。在Kubernetes環境中使用相同的SVM(以及Astra Trident安裝)時、使用專屬的igroup可確保對Kubernetes叢集所做的變更不會影響與其他叢集相關的igroup。此外、也必須確保Kubernetes叢集中的每個節點都有唯一的IQN。如上所述、Astra Trident會自動處理IQN的新增與移除。重複使用主機間的IQN可能會導致主機彼此誤用、並拒絕存取LUN的不良情況。 |
如果將Astra Trident設定為使用「csi資源配置程式」、則Kubernetes節點IQN會自動新增至igroup或從其中移除。當節點新增至Kubernetes叢集時、 trident-csi
示範集部署Pod (trident-csi-xxxxx
)在新增的節點上、登錄可附加磁碟區的新節點。節點IQN也會新增至後端的igroup。當節點封鎖、排放及從Kubernetes刪除時、類似的一組步驟可處理刪除IQN。
如果Astra Trident並未以csi資源配置程式的形式執行、則必須手動更新igroup、以包含Kubernetes叢集中每個工作節點的iSCSI IQN。加入Kubernetes叢集的節點IQN必須新增至igroup。同樣地、從Kubernetes叢集移除的節點IQN也必須從igroup移除。
使用雙向CHAP驗證連線
Astra Trident可以使用雙向CHAP驗證iSCSI工作階段 ontap-san
和 ontap-san-economy
驅動程式:這需要啟用 useCHAP
選項。設定為時 `true`Astra Trident將SVM的預設啟動器安全性設定為雙向CHAP、並從後端檔案設定使用者名稱和機密。NetApp建議使用雙向CHAP來驗證連線。請參閱下列組態範例:
{ "version": 1, "storageDriverName": "ontap-san", "backendName": "ontap_san_chap", "managementLIF": "192.168.0.135", "svm": "ontap_iscsi_svm", "useCHAP": true, "username": "vsadmin", "password": "FaKePaSsWoRd", "igroupName": "trident", "chapInitiatorSecret": "cl9qxIm36DKyawxy", "chapTargetInitiatorSecret": "rqxigXgkesIpwxyz", "chapTargetUsername": "iJF4heBRT0TCwxyz", "chapUsername": "uh2aNCLSd6cNwxyz", }
。 useCHAP 參數是布林選項、只能設定一次。預設值設為假。將其設為true之後、您就無法將其設為假。
|
此外 useCHAP=true
、 chapInitiatorSecret
、 chapTargetInitiatorSecret
、 chapTargetUsername`和 `chapUsername
欄位必須包含在後端定義中。執行建立後端後端之後、即可變更機密資訊 tridentctl update
。
運作方式
透過設定 useCHAP
為真、儲存管理員指示Astra Trident在儲存後端上設定CHAP。這包括下列項目:
-
在SVM上設定CHAP:
-
如果SVM的預設啟動器安全性類型為無(預設設定)和、則磁碟區中沒有已存在的預先存在LUN、Astra Trident會將預設安全性類型設為
CHAP
並繼續設定CHAP啟動器和目標使用者名稱和機密。 -
如果SVM包含LUN、Astra Trident將不會在SVM上啟用CHAP。如此可確保不限制存取SVM上已存在的LUN。
-
-
設定CHAP啟動器和目標使用者名稱和機密;這些選項必須在後端組態中指定(如上所示)。
-
管理在中新增的init1
igroupName
在後端中提供。如果未指定、則預設為trident
。
建立後端之後、Astra Trident會建立對應的 tridentbackend
將CHAP機密與使用者名稱儲存為Kubernetes機密。由Astra Trident在此後端上建立的所有PV、都會掛載並附加於CHAP上。
旋轉認證資料並更新後端
您可以更新中的CHAP參數來更新CHAP認證 backend.json
檔案:這需要更新CHAP機密並使用 tridentctl update
命令以反映這些變更。
更新後端的CHAP機密時、您必須使用 tridentctl 以更新後端。請勿透過CLI/ONTAP UI更新儲存叢集上的認證資料、因為Astra Trident無法接受這些變更。
|
$ cat backend-san.json { "version": 1, "storageDriverName": "ontap-san", "backendName": "ontap_san_chap", "managementLIF": "192.168.0.135", "svm": "ontap_iscsi_svm", "useCHAP": true, "username": "vsadmin", "password": "FaKePaSsWoRd", "igroupName": "trident", "chapInitiatorSecret": "cl9qxUpDaTeD", "chapTargetInitiatorSecret": "rqxigXgkeUpDaTeD", "chapTargetUsername": "iJF4heBRT0TCwxyz", "chapUsername": "uh2aNCLSd6cNwxyz", } $ ./tridentctl update backend ontap_san_chap -f backend-san.json -n trident +----------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +----------------+----------------+--------------------------------------+--------+---------+ | ontap_san_chap | ontap-san | aa458f3b-ad2d-4378-8a33-1a472ffbeb5c | online | 7 | +----------------+----------------+--------------------------------------+--------+---------+
現有的連線不會受到影響;如果SVM上的Astra Trident更新認證、它們將繼續保持作用中狀態。新連線將使用更新的認證資料、而現有連線仍保持作用中狀態。中斷舊PV的連線並重新連線、將會使用更新的認證資料。