Astra Control Center를 설정합니다
Astra Control Center를 설치하고, UI에 로그인하고, 암호를 변경하면 라이센스를 설정하고, 클러스터를 추가하고, 인증을 설정하고, 스토리지를 관리하고, 버킷을 추가할 수 있습니다.
Astra Control Center에 대한 라이센스를 추가합니다
Astra Control Center를 설치할 때 포함된 평가판 라이센스가 이미 설치되어 있습니다. Astra Control Center를 평가하는 경우 이 단계를 건너뛸 수 있습니다.
Astra Control UI 또는 를 사용하여 새 라이센스를 추가할 수 있습니다 "Astra Control API를 참조하십시오".
Astra Control Center 라이센스는 Kubernetes CPU 유닛을 사용하여 CPU 리소스를 측정하고, 모든 관리되는 Kubernetes 클러스터의 작업자 노드에 할당된 CPU 리소스를 고려합니다. 라이센스는 vCPU 사용량을 기준으로 합니다. 라이선스 계산 방법에 대한 자세한 내용은 을 참조하십시오 "라이센싱".
설치가 라이센스 CPU 유닛 수를 초과하여 증가할 경우, Astra Control Center를 통해 새 애플리케이션을 관리할 수 없습니다. 용량이 초과되면 경고가 표시됩니다. |
기존 평가판 또는 전체 라이센스를 업데이트하려면 을 참조하십시오 "기존 라이센스를 업데이트합니다". |
-
새로 설치된 Astra Control Center 인스턴스에 액세스합니다.
-
관리자 역할 권한.
-
A "NetApp 라이센스 파일" (NLF)
-
Astra Control Center UI에 로그인합니다.
-
계정 * > * 라이센스 * 를 선택합니다.
-
라이센스 추가 * 를 선택합니다.
-
다운로드한 라이센스 파일(NLF)으로 이동합니다.
-
라이센스 추가 * 를 선택합니다.
계정 * > * 라이센스 * 페이지에는 라이센스 정보, 만료 날짜, 라이센스 일련 번호, 계정 ID 및 사용된 CPU 단위가 표시됩니다.
평가판 라이센스가 있고 데이터를 AutoSupport로 전송하지 않는 경우, Astra Control Center에 장애가 발생할 경우 데이터 손실을 방지하기 위해 계정 ID를 저장해야 합니다. |
Astra Control을 사용하여 클러스터 관리를 위한 환경을 준비합니다
클러스터를 추가하기 전에 다음 전제 조건이 충족되어야 합니다. 또한 자격 검사를 실행하여 클러스터를 Astra Control Center에 추가할 준비가 되었는지 확인하고 클러스터 관리를 위한 역할을 생성해야 합니다.
-
Pod가 백엔드 스토리지와 상호 작용할 수 있도록 클러스터의 작업자 노드에 적절한 스토리지 드라이버가 구성되어 있는지 확인합니다.
-
귀사의 환경은 을(를) 충족합니다 "구현할 수 있습니다" Astra Trident 및 Astra Control Center용.
-
개인 CA(인증 기관)를 참조하는 kubeconfig 파일을 사용하여 클러스터를 추가하는 경우 에 다음 줄을 추가합니다
cluster
kubeconfig 파일의 섹션. 이를 통해 Astra Control이 클러스터를 추가할 수 있습니다.insecure-skip-tls-verify: true
-
Astra Trident의 한 버전입니다 "Astra Control Center에서 지원합니다" 설치됨:
가능합니다 "Astra Trident 구축" Astra Trident 연산자(수동 또는 제어 차트 사용) 또는 를 사용합니다 tridentctl
. Astra Trident를 설치 또는 업그레이드하기 전에 을 검토하십시오 "지원되는 프런트엔드, 백엔드 및 호스트 구성".-
* Astra Trident 스토리지 백엔드가 구성됨 *: Astra Trident 스토리지 백엔드가 하나 이상 있어야 합니다 "구성됨" 클러스터에서.
-
* Astra Trident 스토리지 클래스가 구성됨 *: Astra Trident 스토리지 클래스가 하나 이상 있어야 합니다 "구성됨" 클러스터에서. 기본 스토리지 클래스가 구성된 경우 기본 주석이 있는 유일한 스토리지 클래스인지 확인합니다.
-
* Astra Trident 볼륨 스냅샷 컨트롤러 및 볼륨 스냅샷 클래스 설치 및 구성 *: 볼륨 스냅샷 컨트롤러가 되어야 합니다 "설치되어 있습니다" 따라서 Astra Control에서 스냅샷을 생성할 수 있습니다. Astra Trident가 하나 이상 있어야 합니다
VolumeSnapshotClass
있습니다 "설정" 관리자의 경우.
-
-
* Kubecon무화과 액세스 가능 *: 에 액세스할 수 있습니다 "기본 클러스터 kubecononfig" 그것입니다 "설치하는 동안 를 구성했습니다".
-
* ONTAP credentials *: Astra Control Center를 사용하여 앱을 백업 및 복원하려면 ONTAP 시스템에 ONTAP 자격 증명과 고급 사용자 및 사용자 ID가 설정되어 있어야 합니다.
ONTAP 명령줄에서 다음 명령을 실행합니다.
export-policy rule modify -vserver <storage virtual machine name> -policyname <policy name> -ruleindex 1 -superuser sys export-policy rule modify -vserver <storage virtual machine name> -policyname <policy name> -ruleindex 1 -anon 65534
-
* Rancher 전용 *: Rancher 환경에서 애플리케이션 클러스터를 관리할 때 Rancher가 제공하는 kubecon무화과 파일에서 애플리케이션 클러스터의 기본 컨텍스트를 수정하여 Rancher API 서버 컨텍스트 대신 컨트롤 플레인 컨텍스트를 사용합니다. 따라서 Rancher API 서버의 부하가 줄어들고 성능이 향상됩니다.
자격 검사를 실행합니다
다음 자격 검사를 실행하여 클러스터를 Astra Control Center에 추가할 준비가 되었는지 확인합니다.
-
Astra Trident 버전을 확인합니다.
kubectl get tridentversions -n trident
Astra Trident가 있으면 다음과 유사한 출력이 표시됩니다.
NAME VERSION trident 23.XX.X
Astra Trident가 없으면 다음과 유사한 출력이 표시됩니다.
error: the server doesn't have a resource type "tridentversions"
Astra Trident가 설치되지 않았거나 설치된 버전이 최신 버전이 아닌 경우 계속하기 전에 Astra Trident의 최신 버전을 설치해야 합니다. 을 참조하십시오 "Astra Trident 문서" 를 참조하십시오. -
Pod가 실행 중인지 확인합니다.
kubectl get pods -n trident
-
스토리지 클래스가 지원되는 Astra Trident 드라이버를 사용하고 있는지 확인합니다. 공급자 이름은 이어야 합니다
csi.trident.netapp.io
. 다음 예를 참조하십시오.kubectl get sc
샘플 반응:
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE ontap-gold (default) csi.trident.netapp.io Delete Immediate true 5d23h
클러스터 역할 kubecononfig를 생성합니다
Astra Control Center에 대한 제한된 사용 권한이나 확장된 사용 권한 관리자 역할을 만들 수도 있습니다. 이미 의 일부로 kubecononfig를 구성했으므로 Astra Control Center 설정에 필요한 절차는 아닙니다 "설치 프로세스".
다음 시나리오 중 하나가 사용자 환경에 적용되는 경우 이 절차를 통해 별도의 kubecononfig를 생성할 수 있습니다.
-
관리하는 클러스터에 대한 Astra Control 권한을 제한하려고 합니다
-
여러 개의 컨텍스트를 사용하며 설치 중에 구성된 기본 Astra Control kubecononfig를 사용할 수 없거나, 단일 컨텍스트의 제한된 역할은 사용자 환경에서 작동하지 않습니다
절차 단계를 완료하기 전에 관리하려는 클러스터에 대해 다음 사항을 확인해야 합니다.
-
kubbtl v1.23 이상이 설치되었습니다
-
Astra Control Center를 통해 추가하고 관리하려는 클러스터에 kubctl 액세스를 허용합니다
이 절차를 수행하려면 Astra Control Center를 실행 중인 클러스터에 kubectl을 액세스할 필요가 없습니다. -
활성 컨텍스트에 대한 클러스터 관리자 권한으로 관리하려는 클러스터에 대한 활성 kubecononfig입니다
-
서비스 계정 생성:
-
라는 서비스 계정 파일을 생성합니다
astracontrol-service-account.yaml
.필요에 따라 이름 및 네임스페이스를 조정합니다. 여기에서 변경한 경우 다음 단계에서 동일한 변경 사항을 적용해야 합니다.
astracontrol-service-account.yaml
+
apiVersion: v1 kind: ServiceAccount metadata: name: astracontrol-service-account namespace: default
-
서비스 계정 적용:
kubectl apply -f astracontrol-service-account.yaml
-
-
Astra Control에서 클러스터를 관리할 수 있는 충분한 권한을 가진 다음 클러스터 역할 중 하나를 생성합니다.
-
* 제한된 클러스터 역할 *: 이 역할에는 Astra Control에서 클러스터를 관리하는 데 필요한 최소 권한이 포함되어 있습니다.
단계를 위해 확장합니다
-
을 생성합니다
ClusterRole
호출되는 파일(예:astra-admin-account.yaml
.필요에 따라 이름 및 네임스페이스를 조정합니다. 여기에서 변경한 경우 다음 단계에서 동일한 변경 사항을 적용해야 합니다.
astra-admin-account.yaml
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: astra-admin-account rules: # Get, List, Create, and Update all resources # Necessary to backup and restore all resources in an app - apiGroups: - '*' resources: - '*' verbs: - get - list - create - patch # Delete Resources # Necessary for in-place restore and AppMirror failover - apiGroups: - "" - apps - autoscaling - batch - crd.projectcalico.org - extensions - networking.k8s.io - policy - rbac.authorization.k8s.io - snapshot.storage.k8s.io - trident.netapp.io resources: - configmaps - cronjobs - daemonsets - deployments - horizontalpodautoscalers - ingresses - jobs - namespaces - networkpolicies - persistentvolumeclaims - poddisruptionbudgets - pods - podtemplates - podsecuritypolicies - replicasets - replicationcontrollers - replicationcontrollers/scale - rolebindings - roles - secrets - serviceaccounts - services - statefulsets - tridentmirrorrelationships - tridentsnapshotinfos - volumesnapshots - volumesnapshotcontents verbs: - delete # Watch resources # Necessary to monitor progress - apiGroups: - "" resources: - pods - replicationcontrollers - replicationcontrollers/scale verbs: - watch # Update resources - apiGroups: - "" - build.openshift.io - image.openshift.io resources: - builds/details - replicationcontrollers - replicationcontrollers/scale - imagestreams/layers - imagestreamtags - imagetags verbs: - update # Use PodSecurityPolicies - apiGroups: - extensions - policy resources: - podsecuritypolicies verbs: - use
-
(OpenShift 클러스터에만 해당) 의 끝에 다음을 추가합니다
astra-admin-account.yaml
파일 또는 뒤에 있습니다# Use PodSecurityPolicies
섹션:# OpenShift security - apiGroups: - security.openshift.io resources: - securitycontextconstraints verbs: - use
-
클러스터 역할 적용:
kubectl apply -f astra-admin-account.yaml
-
-
* 확장된 클러스터 역할 *: 이 역할에는 Astra Control에서 관리할 클러스터에 대한 확장된 권한이 포함됩니다. 여러 컨텍스트를 사용하고 설치 중에 구성된 기본 Astra Control kubecononfig를 사용할 수 없거나 단일 컨텍스트의 제한된 역할을 사용할 수 없는 경우 이 역할을 사용할 수 있습니다.
다음 사항을 참조하십시오 ClusterRole
일반 Kubernetes의 예는 단계입니다. 사용자 환경에 대한 지침은 Kubernetes 배포 문서를 참조하십시오.
단계를 위해 확장합니다
-
을 생성합니다
ClusterRole
호출되는 파일(예:astra-admin-account.yaml
.필요에 따라 이름 및 네임스페이스를 조정합니다. 여기에서 변경한 경우 다음 단계에서 동일한 변경 사항을 적용해야 합니다.
astra-admin-account.yaml
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: astra-admin-account rules: - apiGroups: - '*' resources: - '*' verbs: - '*' - nonResourceURLs: - '*' verbs: - '*'
-
클러스터 역할 적용:
kubectl apply -f astra-admin-account.yaml
-
-
클러스터 역할에 대한 클러스터 역할 바인딩을 서비스 계정에 생성합니다.
-
을 생성합니다
ClusterRoleBinding
파일을 호출했습니다astracontrol-clusterrolebinding.yaml
.필요에 따라 서비스 계정을 생성할 때 수정된 모든 이름과 네임스페이스를 조정합니다.
astracontrol-clusterrolebinding.yaml
+
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: astracontrol-admin roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: astra-admin-account subjects: - kind: ServiceAccount name: astracontrol-service-account namespace: default
-
클러스터 역할 바인딩을 적용합니다.
kubectl apply -f astracontrol-clusterrolebinding.yaml
-
-
토큰 암호 생성 및 적용:
-
라는 토큰 비밀 파일을 만듭니다
secret-astracontrol-service-account.yaml
.secret-astracontrol-service-account.yaml
apiVersion: v1 kind: Secret metadata: name: secret-astracontrol-service-account namespace: default annotations: kubernetes.io/service-account.name: "astracontrol-service-account" type: kubernetes.io/service-account-token
-
토큰 암호 적용:
kubectl apply -f secret-astracontrol-service-account.yaml
-
-
토큰 암호를 에 추가하여 서비스 계정에 추가합니다
secrets
배열(다음 예제의 마지막 줄):kubectl edit sa astracontrol-service-account
apiVersion: v1 imagePullSecrets: - name: astracontrol-service-account-dockercfg-48xhx kind: ServiceAccount metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"astracontrol-service-account","namespace":"default"}} creationTimestamp: "2023-06-14T15:25:45Z" name: astracontrol-service-account namespace: default resourceVersion: "2767069" uid: 2ce068c4-810e-4a96-ada3-49cbf9ec3f89 secrets: - name: astracontrol-service-account-dockercfg-48xhx - name: secret-astracontrol-service-account
-
교체 서비스 계정 암호를 나열합니다
<context>
올바른 설치 상황:kubectl get serviceaccount astracontrol-service-account --context <context> --namespace default -o json
출력의 끝은 다음과 유사합니다.
"secrets": [ { "name": "astracontrol-service-account-dockercfg-48xhx"}, { "name": "secret-astracontrol-service-account"} ]
의 각 요소에 대한 인덱스입니다
secrets
어레이는 0으로 시작합니다. 위의 예에서 의 인덱스입니다astracontrol-service-account-dockercfg-48xhx
는 0이고 의 인덱스입니다secret-astracontrol-service-account
1입니다. 출력에서 서비스 계정의 인덱스 번호를 기록해 둡니다. 다음 단계에서는 이 인덱스 번호가 필요합니다. -
다음과 같이 kubecononfig를 생성합니다.
-
을 생성합니다
create-kubeconfig.sh
파일. 대치TOKEN_INDEX
다음 스크립트의 시작 부분에 올바른 값이 있습니다.create-kubeconfig.sh
# Update these to match your environment. # Replace TOKEN_INDEX with the correct value # from the output in the previous step. If you # didn't change anything else above, don't change # anything else here. SERVICE_ACCOUNT_NAME=astracontrol-service-account NAMESPACE=default NEW_CONTEXT=astracontrol KUBECONFIG_FILE='kubeconfig-sa' CONTEXT=$(kubectl config current-context) SECRET_NAME=$(kubectl get serviceaccount ${SERVICE_ACCOUNT_NAME} \ --context ${CONTEXT} \ --namespace ${NAMESPACE} \ -o jsonpath='{.secrets[TOKEN_INDEX].name}') TOKEN_DATA=$(kubectl get secret ${SECRET_NAME} \ --context ${CONTEXT} \ --namespace ${NAMESPACE} \ -o jsonpath='{.data.token}') TOKEN=$(echo ${TOKEN_DATA} | base64 -d) # Create dedicated kubeconfig # Create a full copy kubectl config view --raw > ${KUBECONFIG_FILE}.full.tmp # Switch working context to correct context kubectl --kubeconfig ${KUBECONFIG_FILE}.full.tmp config use-context ${CONTEXT} # Minify kubectl --kubeconfig ${KUBECONFIG_FILE}.full.tmp \ config view --flatten --minify > ${KUBECONFIG_FILE}.tmp # Rename context kubectl config --kubeconfig ${KUBECONFIG_FILE}.tmp \ rename-context ${CONTEXT} ${NEW_CONTEXT} # Create token user kubectl config --kubeconfig ${KUBECONFIG_FILE}.tmp \ set-credentials ${CONTEXT}-${NAMESPACE}-token-user \ --token ${TOKEN} # Set context to use token user kubectl config --kubeconfig ${KUBECONFIG_FILE}.tmp \ set-context ${NEW_CONTEXT} --user ${CONTEXT}-${NAMESPACE}-token-user # Set context to correct namespace kubectl config --kubeconfig ${KUBECONFIG_FILE}.tmp \ set-context ${NEW_CONTEXT} --namespace ${NAMESPACE} # Flatten/minify kubeconfig kubectl config --kubeconfig ${KUBECONFIG_FILE}.tmp \ view --flatten --minify > ${KUBECONFIG_FILE} # Remove tmp rm ${KUBECONFIG_FILE}.full.tmp rm ${KUBECONFIG_FILE}.tmp
-
Kubernetes 클러스터에 적용할 명령을 소스 하십시오.
source create-kubeconfig.sh
-
-
(선택 사항) kubeconfig의 이름을 클러스터의 의미 있는 이름으로 바꿉니다.
mv kubeconfig-sa YOUR_CLUSTER_NAME_kubeconfig
다음 단계
이제 필수 구성 요소가 충족되었는지 확인했으므로 이제 수행할 준비가 되었습니다 클러스터를 추가합니다.
클러스터 추가
앱 관리를 시작하려면 Kubernetes 클러스터를 추가하고 이를 컴퓨팅 리소스로 관리합니다. Kubernetes 애플리케이션을 검색하려면 Astra Control Center용 클러스터를 추가해야 합니다.
관리를 위해 Astra Control Center에 다른 클러스터를 추가하기 전에 먼저 Astra Control Center에서 클러스터를 관리하는 것이 좋습니다. 메트릭 및 문제 해결을 위해 Kubemetrics 데이터 및 클러스터 관련 데이터를 전송하려면 관리 중인 초기 클러스터가 필요합니다. |
-
클러스터를 추가하기 전에 필요한 를 검토 및 수행합니다 선행 작업.
-
대시보드 또는 클러스터 메뉴에서 이동합니다.
-
리소스 요약의 * 대시보드 * 에서 클러스터 창에서 * 추가 * 를 선택합니다.
-
왼쪽 탐색 영역에서 * 클러스터 * 를 선택한 다음 클러스터 페이지에서 * 클러스터 추가 * 를 선택합니다.
-
-
열리는 * Add Cluster * (클러스터 추가 *) 창에서 를 업로드합니다
kubeconfig.yaml
의 내용을 파일 또는 붙여 넣습니다kubeconfig.yaml
파일.를 클릭합니다 kubeconfig.yaml
파일에는 클러스터 자격 증명 1개에 대한 * 만 포함되어야 합니다 *.직접 만드는 경우 kubeconfig
파일에서 * 하나의 * 컨텍스트 요소만 정의해야 합니다. 을 참조하십시오 "Kubernetes 문서" 을 참조하십시오kubeconfig
파일. 을 사용하여 제한된 클러스터 역할에 대해 kubecon무화과를 생성한 경우 위의 프로세스이 단계에서는 과베토화과를 업로드하거나 붙여 넣으십시오. -
자격 증명 이름을 제공하십시오. 기본적으로 자격 증명 이름은 클러스터 이름으로 자동 채워집니다.
-
다음 * 을 선택합니다.
-
이 Kubernetes 클러스터에 사용할 기본 스토리지 클래스를 선택하고 * Next * 를 선택합니다.
ONTAP 스토리지가 지원하는 Astra Trident 스토리지 클래스를 선택해야 합니다. -
정보를 검토하고 모든 것이 정상적으로 나타나면 * 추가 * 를 선택합니다.
클러스터가 * 검색 * 상태로 전환되고 * 정상 * 으로 변경됩니다. 이제 Astra Control Center로 클러스터를 관리하고 있습니다.
Astra Control Center에서 관리할 클러스터를 추가한 후 모니터링 연산자를 구축하는 데 몇 분이 걸릴 수 있습니다. 그 전까지는 알림 아이콘이 빨간색으로 바뀌고 * 모니터링 에이전트 상태 확인 실패 * 이벤트를 기록합니다. Astra Control Center가 올바른 상태를 획득하면 문제가 해결되므로 이 문제를 무시할 수 있습니다. 몇 분 이내에 문제가 해결되지 않으면 클러스터로 이동하여 를 실행합니다 oc get pods -n netapp-monitoring 시작점으로 사용됩니다. 문제를 디버깅하려면 모니터링 운영자 로그를 확인해야 합니다.
|
ONTAP 스토리지 백엔드에서 인증을 설정합니다
Astra Control Center는 ONTAP 백엔드를 인증하는 두 가지 모드를 제공합니다.
-
* 자격 증명 기반 인증 *: 필요한 권한이 있는 ONTAP 사용자의 사용자 이름 및 암호입니다. ONTAP 버전과의 호환성을 최대화하려면 admin 또는 vsadmin과 같이 미리 정의된 보안 로그인 역할을 사용해야 합니다.
-
* 인증서 기반 인증 *: Astra Control Center는 백엔드에 설치된 인증서를 사용하여 ONTAP 클러스터와 통신할 수도 있습니다. 클라이언트 인증서, 키 및 신뢰할 수 있는 CA 인증서를 사용해야 합니다(권장).
나중에 기존 백엔드를 업데이트하여 한 가지 인증 유형에서 다른 방법으로 이동할 수 있습니다. 한 번에 하나의 인증 방법만 지원됩니다.
자격 증명 기반 인증을 사용합니다
Astra Control Center에는 클러스터 범위에 대한 자격 증명이 필요합니다 admin
ONTAP 백엔드와 통신합니다. 과 같이 미리 정의된 표준 역할을 사용해야 합니다 admin
. 이를 통해 향후 Astra Control Center 릴리스에서 사용할 기능 API를 노출할 수 있는 향후 ONTAP 릴리스와 향후 호환될 수 있습니다.
사용자 지정 보안 로그인 역할은 Astra Control Center에서 생성 및 사용할 수 있지만 권장되지 않습니다. |
백엔드 정의의 예는 다음과 같습니다.
{ "version": 1, "backendName": "ExampleBackend", "storageDriverName": "ontap-nas", "managementLIF": "10.0.0.1", "dataLIF": "10.0.0.2", "svm": "svm_nfs", "username": "admin", "password": "secret" }
백엔드 정의만 자격 증명이 일반 텍스트로 저장되는 곳입니다. 백엔드의 생성 또는 업데이트는 자격 증명에 대한 지식이 필요한 유일한 단계입니다. 따라서 Kubernetes 또는 스토리지 관리자가 수행할 수 있는 관리자 전용 작업입니다.
인증서 기반 인증을 사용합니다
Astra Control Center는 인증서를 사용하여 신규 및 기존 ONTAP 백엔드와 통신할 수 있습니다. 백엔드 정의에 다음 정보를 입력해야 합니다.
-
clientCertificate
: 클라이언트 인증서. -
clientPrivateKey
: 연결된 개인 키. -
trustedCACertificate
: 신뢰할 수 있는 CA 인증서입니다. 신뢰할 수 있는 CA를 사용하는 경우 이 매개 변수를 제공해야 합니다. 신뢰할 수 있는 CA가 사용되지 않으면 이 작업을 무시할 수 있습니다.
다음 유형의 인증서 중 하나를 사용할 수 있습니다.
-
자체 서명된 인증서
-
타사 인증서입니다
자체 서명된 인증서를 사용하여 인증을 활성화합니다
일반적인 워크플로에는 다음 단계가 포함됩니다.
-
클라이언트 인증서 및 키를 생성합니다. 생성 시 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=<common-name>"
-
유형의 클라이언트 인증서를 설치합니다
client-ca
ONTAP 클러스터의 키입니다.security certificate install -type client-ca -cert-name <certificate-name> -vserver <vserver-name> security ssl modify -vserver <vserver-name> -client-enabled true
-
ONTAP 보안 로그인 역할이 인증서 인증 방법을 지원하는지 확인합니다.
security login create -user-or-group-name vsadmin -application ontapi -authentication-method cert -vserver <vserver-name> security login create -user-or-group-name vsadmin -application http -authentication-method cert -vserver <vserver-name>
-
생성된 인증서를 사용하여 인증을 테스트합니다. ONTAP 관리 LIF> 및 <vserver name>를 관리 LIF IP 및 SVM 이름으로 바꿉니다. LIF의 서비스 정책이 으로 설정되어 있는지 확인해야 합니다
default-data-management
.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>
-
이전 단계에서 얻은 값을 사용하여 Astra Control Center UI에 스토리지 백엔드를 추가합니다.
타사 인증서로 인증을 활성화합니다
타사 인증서가 있는 경우 다음 단계를 사용하여 인증서 기반 인증을 설정할 수 있습니다.
-
개인 키와 CSR을 생성합니다.
openssl req -new -newkey rsa:4096 -nodes -sha256 -subj "/" -outform pem -out ontap_cert_request.csr -keyout ontap_cert_request.key -addext "subjectAltName = DNS:<ONTAP_CLUSTER_FQDN_NAME>,IP:<ONTAP_MGMT_IP>”
-
CSR을 Windows CA(타사 CA)로 전달하고 서명된 인증서를 발급합니다.
-
서명된 인증서를 다운로드하고 이름을 'ONTAP_signed_cert.crt'로 지정합니다.
-
Windows CA(타사 CA)에서 루트 인증서를 내보냅니다.
-
이 파일의 이름을 지정합니다
ca_root.crt
이제 다음 세 개의 파일이 있습니다.
-
* 개인 키 *:
ontap_signed_request.key
(이 키는 ONTAP의 서버 인증서에 해당하는 키입니다. 서버 인증서를 설치하는 동안 필요합니다.) -
* 서명된 인증서 *:
ontap_signed_cert.crt
(ONTAP에서 _server certificate_라고도 함) -
* 루트 CA 인증서 *:
ca_root.crt
(ONTAP에서 _server-ca certificate_라고도 합니다.)
-
-
이러한 인증서를 ONTAP에 설치합니다. 생성 및 설치
server
및server-ca
ONTAP의 인증서.YAML의 샘플을 확장합니다
# Copy the contents of ca_root.crt and use it here. security certificate install -type server-ca Please enter Certificate: Press <Enter> when done -----BEGIN CERTIFICATE----- <certificate details> -----END CERTIFICATE----- You should keep a copy of the CA-signed digital certificate for future reference. The installed certificate's CA and serial number for reference: CA: serial: The certificate's generated name for reference: === # Copy the contents of ontap_signed_cert.crt and use it here. For key, use the contents of ontap_cert_request.key file. security certificate install -type server Please enter Certificate: Press <Enter> when done -----BEGIN CERTIFICATE----- <certificate details> -----END CERTIFICATE----- Please enter Private Key: Press <Enter> when done -----BEGIN PRIVATE KEY----- <private key details> -----END PRIVATE KEY----- Enter certificates of certification authorities (CA) which form the certificate chain of the server certificate. This starts with the issuing CA certificate of the server certificate and can range up to the root CA certificate. Do you want to continue entering root and/or intermediate certificates {y|n}: n The provided certificate does not have a common name in the subject field. Enter a valid common name to continue installation of the certificate: <ONTAP_CLUSTER_FQDN_NAME> You should keep a copy of the private key and the CA-signed digital certificate for future reference. The installed certificate's CA and serial number for reference: CA: serial: The certificate's generated name for reference: == # Modify the vserver settings to enable SSL for the installed certificate ssl modify -vserver <vserver_name> -ca <CA> -server-enabled true -serial <serial number> (security ssl modify) == # Verify if the certificate works fine: openssl s_client -CAfile ca_root.crt -showcerts -servername server -connect <ONTAP_CLUSTER_FQDN_NAME>:443 CONNECTED(00000005) depth=1 DC = local, DC = umca, CN = <CA> verify return:1 depth=0 verify return:1 write W BLOCK --- Certificate chain 0 s: i:/DC=local/DC=umca/<CA> -----BEGIN CERTIFICATE----- <Certificate details>
-
암호 없는 통신을 위해 동일한 호스트에 대한 클라이언트 인증서를 생성합니다. Astra Control Center는 이 프로세스를 사용하여 ONTAP와 통신합니다.
-
ONTAP에서 클라이언트 인증서 생성 및 설치:
YAML의 샘플을 확장합니다
# Use /CN=admin or use some other account which has privileges. openssl req -x509 -nodes -days 1095 -newkey rsa:2048 -keyout ontap_test_client.key -out ontap_test_client.pem -subj "/CN=admin" Copy the content of ontap_test_client.pem file and use it in the below command: security certificate install -type client-ca -vserver <vserver_name> Please enter Certificate: Press <Enter> when done -----BEGIN CERTIFICATE----- <Certificate details> -----END CERTIFICATE----- You should keep a copy of the CA-signed digital certificate for future reference. The installed certificate’s CA and serial number for reference: CA: serial: The certificate’s generated name for reference: == ssl modify -vserver <vserver_name> -client-enabled true (security ssl modify) # Setting permissions for certificates security login create -user-or-group-name admin -application ontapi -authentication-method cert -role admin -vserver <vserver_name> security login create -user-or-group-name admin -application http -authentication-method cert -role admin -vserver <vserver_name> == #Verify passwordless communication works fine with the use of only certificates: curl --cacert ontap_signed_cert.crt --key ontap_test_client.key --cert ontap_test_client.pem https://<ONTAP_CLUSTER_FQDN_NAME>/api/storage/aggregates { "records": [ { "uuid": "f84e0a9b-e72f-4431-88c4-4bf5378b41bd", "name": "<aggr_name>", "node": { "uuid": "7835876c-3484-11ed-97bb-d039ea50375c", "name": "<node_name>", "_links": { "self": { "href": "/api/cluster/nodes/7835876c-3484-11ed-97bb-d039ea50375c" } } }, "_links": { "self": { "href": "/api/storage/aggregates/f84e0a9b-e72f-4431-88c4-4bf5378b41bd" } } } ], "num_records": 1, "_links": { "self": { "href": "/api/storage/aggregates" } } }%
-
Astra Control Center UI에 스토리지 백엔드를 추가하고 다음 값을 제공합니다.
-
* 클라이언트 인증서 *: ONTAP_TEST_CLIENT.PEM
-
* 개인 키 *: ontap_test_client.key
-
* 신뢰할 수 있는 CA 인증서 *: ONTAP_signed_certt. CRT
-
스토리지 백엔드를 추가합니다
기존 ONTAP 스토리지 백엔드를 Astra Control Center에 추가하여 리소스를 관리할 수 있습니다.
Astra Control에서 스토리지 클러스터를 스토리지 백엔드로 관리하면 PVS(영구적 볼륨)와 스토리지 백엔드 간의 연결 및 추가 스토리지 메트릭을 얻을 수 있습니다.
자격 증명 또는 인증서 인증 정보를 설정한 후 기존 ONTAP 스토리지 백엔드를 Astra Control Center에 추가하여 리소스를 관리할 수 있습니다.
-
왼쪽 탐색 영역의 대시보드에서 * backends * 를 선택합니다.
-
추가 * 를 선택합니다.
-
스토리지 백엔드 추가 페이지의 기존 사용 섹션에서 * ONTAP * 를 선택합니다.
-
다음 중 하나를 선택합니다.
-
* 관리자 자격 증명 사용 *: ONTAP 클러스터 관리 IP 주소와 관리 자격 증명을 입력합니다. 자격 증명은 클러스터 전체의 자격 증명이어야 합니다.
여기에 자격 증명을 입력한 사용자에게는 가 있어야 합니다 ontapi
ONTAP 클러스터의 ONTAP System Manager에서 활성화된 사용자 로그인 액세스 방법입니다. SnapMirror 복제를 사용하려는 경우 액세스 방법이 있는 "admin" 역할의 사용자 자격 증명을 적용하십시오ontapi
및http
, 소스 및 대상 ONTAP 클러스터 모두에서. 을 참조하십시오 "ONTAP 설명서에서 사용자 계정을 관리합니다" 를 참조하십시오. -
* 인증서 사용 *: 인증서를 업로드합니다
.pem
파일, 인증서 키입니다.key
파일 및 인증 기관 파일(옵션)을 선택합니다.
-
-
다음 * 을 선택합니다.
-
백엔드 세부 정보를 확인하고 * 관리 * 를 선택합니다.
백엔드가 에 나타납니다 online
목록의 상태로 요약 정보를 표시합니다.
백엔드가 표시되도록 페이지를 새로 고쳐야 할 수 있습니다. |
버킷을 추가합니다
Astra Control UI 또는 를 사용하여 버킷을 추가할 수 있습니다 "Astra Control API를 참조하십시오". 애플리케이션과 영구 스토리지를 백업하려는 경우나 클러스터 간에 애플리케이션을 클론 복제하려는 경우에는 오브젝트 저장소 버킷 공급자를 추가하는 것이 중요합니다. Astra Control은 이러한 백업 또는 클론을 정의한 오브젝트 저장소 버킷에 저장합니다.
애플리케이션 구성과 영구 스토리지를 동일한 클러스터에 클론 복제하려는 경우 Astra Control에 버킷이 필요하지 않습니다. 애플리케이션 스냅샷 기능에는 버킷이 필요하지 않습니다.
-
Astra Control Center에서 관리하는 클러스터에서 연결할 수 있는 버킷입니다.
-
버킷에 대한 자격 증명.
-
다음 유형의 버킷:
-
NetApp ONTAP S3
-
NetApp StorageGRID S3
-
Microsoft Azure를 참조하십시오
-
일반 S3
-
AWS(Amazon Web Services) 및 GCP(Google Cloud Platform)는 일반 S3 버킷 유형을 사용합니다. |
Astra Control Center는 Amazon S3를 일반 S3 버킷 공급자로 지원하지만, Astra Control Center는 Amazon의 S3 지원을 주장하는 모든 오브젝트 저장소 공급업체를 지원하지 않을 수 있습니다. |
-
왼쪽 탐색 영역에서 * Bucket * 을 선택합니다.
-
추가 * 를 선택합니다.
-
버킷 유형을 선택합니다.
버킷을 추가할 때 올바른 버킷 공급자를 선택하고 해당 공급자에 적합한 자격 증명을 제공합니다. 예를 들어, UI에서 NetApp ONTAP S3를 유형으로 받아들이고 StorageGRID 자격 증명을 받아들이지만, 이 버킷을 사용한 이후의 모든 애플리케이션 백업 및 복원이 실패합니다. -
기존 버킷 이름과 선택적 설명을 입력합니다.
버킷 이름과 설명은 나중에 백업을 생성할 때 선택할 수 있는 백업 위치로 나타납니다. 이 이름은 보호 정책 구성 중에도 표시됩니다. -
S3 엔드포인트의 이름 또는 IP 주소를 입력합니다.
-
자격 증명 선택 * 에서 * 추가 * 또는 * 기존 * 사용 탭을 선택합니다.
-
추가 * 를 선택한 경우:
-
Astra Control의 다른 자격 증명과 구별되는 자격 증명의 이름을 입력합니다.
-
클립보드의 내용을 붙여 넣어 액세스 ID와 비밀 키를 입력합니다.
-
-
기존 사용 * 을 선택한 경우:
-
버킷에 사용할 기존 자격 증명을 선택합니다.
-
-
-
를 선택합니다
Add
.버킷을 추가하면 Astra Control이 기본 버킷 표시기로 하나의 버킷을 표시합니다. 사용자가 만든 첫 번째 버킷이 기본 버킷이 됩니다. 양동이 추가될 때 나중에 결정할 수 있습니다 "다른 기본 버킷을 설정합니다".
다음 단계
Astra Control Center에 로그인하고 클러스터를 추가했으므로 이제 Astra Control Center의 애플리케이션 데이터 관리 기능을 사용할 준비가 되었습니다.