검색

스토리지 리소스 관리 및 할당

download PDF
Red Hat OpenShift Data Foundation 4.11

스냅샷 및 복제를 포함하여 OpenShift Data Foundation에서 핵심 서비스 및 호스팅 애플리케이션에 스토리지를 할당하는 방법에 대한 지침입니다.

Red Hat Storage Documentation Team

초록

이 문서에서는 Red Hat OpenShift Data Foundation에서 핵심 서비스 및 호스팅 애플리케이션에 스토리지를 할당하는 방법을 설명합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견을 보내 주십시오. 개선할 내용에 대해 알려주십시오. 피드백을 보내주시려면 다음을 확인하십시오.

  • 특정 문구에 대한 간단한 의견 작성 방법은 다음과 같습니다.

    1. 문서가 Multi-page HTML 형식으로 표시되는지 확인합니다. 또한 문서 오른쪽 상단에 피드백 버튼이 있는지 확인합니다.
    2. 마우스 커서를 사용하여 주석 처리하려는 텍스트 부분을 강조 표시합니다.
    3. 강조 표시된 텍스트 아래에 표시되는 피드백 추가 팝업을 클릭합니다.
    4. 표시된 지침을 따릅니다.
  • 보다 상세하게 피드백을 제출하려면 다음과 같이 Bugzilla 티켓을 생성하십시오.

    1. Bugzilla 웹 사이트로 이동합니다.
    2. 구성 요소 섹션에서 설명서를 선택합니다.
    3. 설명 필드에 문서 개선을 위한 제안 사항을 기입하십시오. 관련된 문서의 해당 부분 링크를 알려주십시오.
    4. 버그 제출을 클릭합니다.

1장. 개요

이 문서를 읽고 Red Hat OpenShift Data Foundation에서 핵심 서비스 또는 호스팅 애플리케이션에 스토리지를 생성, 구성 및 할당하는 방법을 알아보십시오.

2장. 스토리지 클래스

OpenShift Data Foundation Operator는 사용 중인 플랫폼에 따라 기본 스토리지 클래스를 설치합니다. 이 기본 스토리지 클래스는 Operator가 소유하고 제어하며 삭제하거나 수정할 수 없습니다. 그러나 사용자 정의 스토리지 클래스를 생성하여 다른 스토리지 리소스를 사용하거나 애플리케이션에 다른 동작을 제공할 수 있습니다.

참고

외부 모드 OpenShift Data Foundation 클러스터에서는 사용자 정의 스토리지 클래스가 지원되지 않습니다.

2.1. 스토리지 클래스 및 풀 생성

기존 풀을 사용하여 스토리지 클래스를 생성하거나 이를 생성하는 동안 스토리지 클래스에 대한 새 풀을 생성할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 로그인한 후 OpenShift Data Foundation 클러스터가 Ready 상태에 있는지 확인합니다.

절차

  1. 스토리지StorageClass 를 클릭합니다.
  2. 스토리지 클래스 생성을 클릭합니다.
  3. 스토리지 클래스 이름설명을 입력합니다.
  4. 회수 정책은 기본 옵션으로 Delete 로 설정됩니다. 이 설정을 사용하십시오.

    회수 정책을 스토리지 클래스에서 Retain 으로 변경하면 PVC(영구 볼륨 클레임)를 삭제한 후에도 PV(영구 볼륨) 상태가 Released 상태로 유지됩니다.

  5. 볼륨 바인딩 모드는 기본 옵션으로 WaitForConsumer 로 설정됩니다.

    Immediate 옵션을 선택하면 PVC를 생성할 때 PV가 즉시 생성됩니다.

  6. 영구 볼륨 프로비저닝에 사용되는 플러그인인 RBD Provisioner 를 선택합니다.
  7. 목록에서 기존 스토리지 풀 을 선택하거나 새 풀을 생성합니다.

    참고

    기본 풀에서 2방향 복제 데이터 보호 정책을 사용하는 것은 지원되지 않습니다. 그러나 추가 풀을 생성하는 경우 양방향 복제를 사용할 수 있습니다.

    새 풀 생성
    1. 새 풀 생성을 클릭합니다.
    2. 풀 이름 을 입력합니다.
    3. 데이터 보호 정책으로 2-way-Replication 또는 3-way-Replication 을 선택합니다.
    4. 데이터를 압축 해야 하는 경우 압축 활성화를 선택합니다.

      압축을 사용하면 애플리케이션 성능에 영향을 줄 수 있으며, 데이터를 이미 압축하거나 암호화할 때 유용할 수 있습니다. 압축을 활성화하기 전에 기록된 데이터는 압축되지 않습니다.

    5. 생성을 클릭하여 새 스토리지 풀을 생성합니다.
    6. 풀이 생성되면 완료 를 클릭합니다.
  8. 선택 사항: 암호화 활성화 확인란을 선택합니다.
  9. 생성을 클릭하여 스토리지 클래스를 생성합니다.

2.2. 영구 볼륨 암호화의 스토리지 클래스

PV(영구 볼륨) 암호화를 통해 테넌트(애플리케이션) 간 격리 및 기밀성이 보장됩니다. PV 암호화를 사용하려면 PV 암호화를 위한 스토리지 클래스를 생성해야 합니다. 영구 볼륨 암호화는 RBD PV에서만 사용할 수 있습니다.

OpenShift Data Foundation은 HashiCorp Vault에 암호화 암호를 저장할 수 있도록 지원합니다. 영구 볼륨 암호화에 외부 키 관리 시스템(KMS)을 사용하여 활성화된 스토리지 클래스를 생성할 수 있습니다. 스토리지 클래스를 생성하기 전에 KMS에 대한 액세스를 구성해야 합니다.

참고

PV 암호화의 경우 유효한 Red Hat OpenShift Data Foundation Advanced 서브스크립션이 있어야합니다. 자세한 내용은 OpenShift Data Foundation 서브스크립션에 대한 지식베이스 문서 를 참조하십시오.

2.2.1. 키 관리 시스템 (KMS)에 대한 액세스 구성

사용 사례에 따라 다음 방법 중 하나를 사용하여 KMS에 대한 액세스를 구성해야 합니다.

  • vaulttokens:를 사용하면 사용자가 토큰을 사용하여 인증할 수 있습니다.
  • vaulttenantsa 사용(기술 프리뷰): 사용자가 serviceaccounts 를 사용하여 Vault로 인증할 수 있습니다.
중요

vaulttenantsa 를 사용하여 KMS에 액세스하는 것은 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

2.2.1.1. vaulttokens를 사용하여 KMS에 대한 액세스 구성

사전 요구 사항

  • OpenShift Data Foundation 클러스터는 Ready 상태에 있습니다.
  • 외부 키 관리 시스템 (KMS)에서 다음을 수행합니다.

    • 토큰이 있는 정책이 존재하고 Vault 의 키 값 백엔드 경로가 활성화되었는지 확인합니다.
    • Vault 서버에서 서명된 인증서를 사용하고 있는지 확인합니다.

절차

테넌트의 네임스페이스에 보안을 생성합니다.

  1. OpenShift Container Platform 웹 콘솔에서 워크로드 → 시크릿 으로 이동합니다.
  2. 생성 → 키/값 시크릿 을 클릭합니다.
  3. Secret Nameceph-csi-kms-token 로 입력합니다.
  4. Key토큰 으로 입력합니다.
  5. 값을 입력합니다.

    Vault의 토큰입니다. 찾아보기 를 클릭하여 토큰이 포함된 파일을 선택하고 업로드하거나 텍스트 상자에 토큰을 직접 입력할 수 있습니다.

  6. 생성을 클릭합니다.
참고

토큰은 ceph-csi-kms-token 을 사용하여 암호화된 모든 PVC를 삭제한 경우에만 삭제할 수 있습니다.

2.2.1.2. vaulttenantsa를 사용하여 KMS에 대한 액세스 구성

사전 요구 사항

  • OpenShift Data Foundation 클러스터는 Ready 상태에 있습니다.
  • 외부 키 관리 시스템 (KMS)에서 다음을 수행합니다.

    • 정책이 존재하고 Vault에 키 값 백엔드 경로가 활성화되어 있는지 확인합니다.
    • Vault 서버에서 서명된 인증서를 사용하고 있는지 확인합니다.
  • 다음과 같이 테넌트 네임스페이스에 다음 serviceaccount를 생성합니다.

    $ cat <<EOF | oc create -f -
    apiVersion: v1
    kind: ServiceAccount
    metadata:
        name: ceph-csi-vault-sa
    EOF

절차

OpenShift Data Foundation에서 Vault 로 인증하고 시작하기 전에 Kubernetes 인증 방법을 구성해야 합니다. 다음 명령은 OpenShift Data Foundation이 Vault 로 인증할 수 있도록 serviceAccount,ClusterRoleClusterRoleBinding 을 생성하고 구성합니다.

  1. 다음 YAML을 Openshift 클러스터에 적용합니다.

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: rbd-csi-vault-token-review
    ---
    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: rbd-csi-vault-token-review
    rules:
      - apiGroups: ["authentication.k8s.io"]
        resources: ["tokenreviews"]
        verbs: ["create", "get", "list"]
    
    ---
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: rbd-csi-vault-token-review
    subjects:
      - kind: ServiceAccount
        name: rbd-csi-vault-token-review
        namespace: openshift-storage
    roleRef:
      kind: ClusterRole
      name: rbd-csi-vault-token-review
      apiGroup: rbac.authorization.k8s.io
  2. serviceaccount 토큰 및 CA 인증서에 대한 시크릿을 생성합니다.

    $ cat <<EOF | oc create -f -
    apiVersion: v1
    kind: Secret
    metadata:
      name: rbd-csi-vault-token-review-token
      namespace: openshift-storage
      annotations:
        kubernetes.io/service-account.name: "rbd-csi-vault-token-review"
    type: kubernetes.io/service-account-token
    data: {}
    EOF
  3. 시크릿에서 토큰 및 CA 인증서를 가져옵니다.

    $ SA_JWT_TOKEN=$(oc -n openshift-storage get secret rbd-csi-vault-token-review-token -o jsonpath="{.data['token']}" | base64 --decode; echo)
    $ SA_CA_CRT=$(oc -n openshift-storage get secret rbd-csi-vault-token-review-token -o jsonpath="{.data['ca\.crt']}" | base64 --decode; echo)
  4. OpenShift 클러스터 끝점을 검색합니다.

    $ OCP_HOST=$(oc config view --minify --flatten -o jsonpath="{.clusters[0].cluster.server}")
  5. 이전 단계에서 수집한 정보를 사용하여 다음과 같이 Vault에서 kubernetes 인증 방법을 설정합니다.

    $ vault auth enable kubernetes
    $ vault write auth/kubernetes/config \
              token_reviewer_jwt="$SA_JWT_TOKEN" \
              kubernetes_host="$OCP_HOST" \
              kubernetes_ca_cert="$SA_CA_CRT"
  6. 테넌트 네임스페이스의 Vault에서 역할을 생성합니다.

    $ vault write "auth/kubernetes/role/csi-kubernetes" bound_service_account_names="ceph-csi-vault-sa" bound_service_account_namespaces=<tenant_namespace> policies=<policy_name_in_vault>

    CSI-kubernetes 는 OpenShift Data Foundation이 Vault에서 찾는 기본 역할 이름입니다. OpenShift Data Foundation 클러스터의 테넌트 네임스페이스의 기본 서비스 계정 이름은 ceph-csi-vault-sa 입니다. 이러한 기본값은 테넌트 네임스페이스에서 ConfigMap을 생성하여 덮어쓸 수 있습니다.

    기본 이름을 재정의하는 방법에 대한 자세한 내용은 테넌트 ConfigMap을 사용하여 Vault 연결 세부 정보 확장을 참조하십시오.

샘플 YAML

  • PVencrytpion에 vaulttenantsa 방법을 사용하는 스토리지 클래스를 생성하려면 기존 ConfigMap을 편집하거나 Vault와의 연결을 설정하는 데 필요한 모든 정보를 보유하는 csi-kms-connection-details 라는 ConfigMap을 생성해야 합니다.

    아래에 제공된 샘플 yaml을 사용하여 csi-kms-connection-detail ConfigMap을 업데이트하거나 생성할 수 있습니다.

    apiVersion: v1
    data:
      vault-tenant-sa: |-
        {
          "encryptionKMSType": "vaulttenantsa",
          "vaultAddress": "<https://hostname_or_ip_of_vault_server:port>",
          "vaultTLSServerName": "<vault TLS server name>",
          "vaultAuthPath": "/v1/auth/kubernetes/login",
          "vaultAuthNamespace": "<vault auth namespace name>"
          "vaultNamespace": "<vault namespace name>",
          "vaultBackendPath": "<vault backend path name>",
          "vaultCAFromSecret": "<secret containing CA cert>",
          "vaultClientCertFromSecret": "<secret containing client cert>",
          "vaultClientCertKeyFromSecret": "<secret containing client private key>",
          "tenantSAName": "<service account name in the tenant namespace>"
        }
    metadata:
      name: csi-kms-connection-details

    encryptionKMSType

    자격 증명 모음을 사용한 인증에 서비스 계정을 사용하려면 vaulttenantsa 로 설정합니다.

    vaultAddress

    포트 번호를 사용하여 자격 증명 모음 서버의 호스트 이름 또는 IP 주소입니다.

    vaultTLSServerName

    (선택 사항) 자격 증명 모음 TLS 서버 이름입니다.

    vaultAuthPath

    (선택 사항) Vault에서 kubernetes auth 방법이 활성화된 경로입니다. 기본 경로는 kubernetes 입니다. kubernetes 이외의 다른 경로에서 auth 방법을 활성화하면 이 변수를 "/v1/auth/<path>/login" 으로 설정해야 합니다.

    vaultAuthNamespace

    (선택 사항) kubernetes auth 방법이 활성화된 Vault 네임스페이스입니다.

    vaultNamespace

    (선택 사항) 키를 저장하는 데 사용되는 백엔드 경로가 존재하는 Vault 네임스페이스

    vaultBackendPath

    암호화 키가 저장되는 Vault의 백엔드 경로

    vaultCAFromSecret

    Vault에서 CA 인증서가 포함된 OpenShift Data Foundation 클러스터의 시크릿

    vaultClientCertFromSecret

    Vault의 클라이언트 인증서가 포함된 OpenShift Data Foundation 클러스터의 시크릿

    vaultClientCertKeyFromSecret

    Vault의 클라이언트 개인 키가 포함된 OpenShift Data Foundation 클러스터의 시크릿

    tenantSAName

    (선택 사항) 테넌트 네임스페이스의 서비스 계정 이름입니다. 기본값은 ceph-csi-vault-sa 입니다. 다른 이름을 사용해야 하는 경우 이 변수를 적절하게 설정해야 합니다.

2.2.2. 영구 볼륨 암호화를 위한 스토리지 클래스 생성

사전 요구 사항

사용 사례에 따라 다음 중 하나에 대해 KMS에 대한 액세스를 구성해야 합니다.

절차

  1. OpenShift 웹 콘솔에서 스토리지StorageClasses 로 이동합니다.
  2. 스토리지 클래스 생성을 클릭합니다.
  3. 스토리지 클래스 이름설명을 입력합니다.
  4. Reclaim Policy (폐기 정책)에 대해 Delete 또는 Retain 을 선택합니다. 기본적으로 삭제 가 선택됩니다.
  5. 볼륨 바인딩 모드로 Immediate 또는 WaitForFirstConsumer 를 선택합니다. WaitForConsumer 가 기본 옵션으로 설정됩니다.
  6. 영구 볼륨 프로비저닝에 사용되는 플러그인인 RBD Provisioner openshift-storage.rbd.csi.ceph.com 을 선택합니다.
  7. 목록에서 볼륨 데이터가 저장된 Storage Pool 을 선택하거나 새 풀을 생성합니다.
  8. Enable encryption (암호 암호화 활성화) 확인란을 선택합니다. KMS 연결 세부 정보를 설정하는 데 사용할 수 있는 두 가지 옵션이 있습니다.

    • 기존 KMS 연결 선택: 드롭다운 목록에서 기존 KMS 연결을 선택합니다. 목록은 csi-kms-connection-details ConfigMap에서 사용 가능한 연결 세부 정보에서 채워집니다.
    • 새 KMS 연결 생성: 이는 vaulttokens 에만 적용됩니다.

      1. 키 관리 서비스 공급자는 기본적으로 Vault로 설정됩니다.
      2. Vault 서버의 고유한 연결 이름, 호스트 주소 ('https://<hostname 또는 ip>'), 포트 번호 및 토큰을 입력합니다.
      3. 고급 설정을 확장하여 Vault 구성에 따라 추가 설정 및 인증서 세부 정보를 입력합니다.

        1. OpenShift Data Foundation 전용 및 고유한 백엔드 경로에 키 값 시크릿 경로를 입력합니다.
        2. 선택 사항: TLS 서버 이름Vault 엔터프라이즈 네임스페이스를 입력합니다.
        3. 각 PEM 인코딩 인증서 파일을 업로드하여 CA 인증서,클라이언트 인증서클라이언트 개인 키를 제공합니다.
        4. 저장을 클릭합니다.
      4. 저장을 클릭합니다.
  9. 생성을 클릭합니다.
  10. HashiCorp Vault 설정에서 백엔드 경로에서 사용하는 KV(Key/Value) 시크릿 엔진 API 버전을 자동으로 탐지하지 않는 경우 ConfigMap을 편집하여 vaultBackend 매개변수를 추가합니다.

    참고

    vaultBackend 는 configmap에 추가된 선택적 매개변수로 백엔드 경로와 연결된 KV 시크릿 엔진 API 버전을 지정합니다. 값이 백엔드 경로에 설정된 KV 시크릿 엔진 API 버전과 일치하는지 확인합니다. 그러지 않으면 PVC(영구 볼륨 클레임) 생성 중에 실패할 수 있습니다.

    1. 새로 생성된 스토리지 클래스에서 사용 중인 암호화KMSID를 식별합니다.

      1. OpenShift 웹 콘솔에서 스토리지 → 스토리지 클래스 로 이동합니다.
      2. 스토리지 클래스 이름 → YAML 탭을 클릭합니다.
      3. 스토리지 클래스에서 사용 중인 암호화KMSID 를 캡처합니다.

        예제:

        encryptionKMSID: 1-vault
    2. OpenShift 웹 콘솔에서 워크로드ConfigMaps 로 이동합니다.
    3. KMS 연결 세부 정보를 보려면 csi-kms-connection-details 를 클릭합니다.
    4. ConfigMap을 편집합니다.

      1. 작업 메뉴 (SAML) → ConfigMap 편집 을 클릭합니다.
      2. 이전에 식별한 암호화KMSID 에 구성된 백엔드에 따라 vaultBackend 매개변수를 추가합니다.

        KV 시크릿 엔진 API, 버전 1 및 kv -v2 를 KV 시크릿 엔진 API, 버전 2에 할당할 수 있습니다.

        예제:

         kind: ConfigMap
         apiVersion: v1
         metadata:
           name: csi-kms-connection-details
         [...]
         data:
           1-vault: |-
             {
               "encryptionKMSType": "vaulttokens",
               "kmsServiceName": "1-vault",
               [...]
               "vaultBackend": "kv-v2"
             }
           2-vault: |-
             {
               "encryptionKMSType": "vaulttenantsa",
               [...]
               "vaultBackend": "kv"
             }
      3. 저장을 클릭합니다.

다음 단계

  • 스토리지 클래스를 사용하여 암호화된 영구 볼륨을 만들 수 있습니다. 자세한 내용은 영구 볼륨 클레임 관리를 참조하십시오.

    중요

    Red Hat은 이 문서를 고객에게 서비스로 제공하기 위해 기술 파트너와 협력합니다. 그러나 Red Hat은 HashiCorp 제품을 지원하지 않습니다. 이 제품에 대한 기술 지원은 HashiCorp 에 문의하십시오.

2.2.2.1. 테넌트 ConfigMap을 사용하여 Vault 연결 세부 정보 덮어쓰기

openshift-storage 네임스페이스의 csi-kms-connection-details ConfigMap에 설정된 값과 다른 구성 옵션을 사용하여 Openshift 네임스페이스에서 ConfigMap을 생성하여 테넌트별로 자격 증명 모음 연결 세부 정보를 구성할 수 있습니다. ConfigMap은 테넌트 네임스페이스에 있어야 합니다. 테넌트 네임스페이스의 ConfigMap의 값은 해당 네임스페이스에 생성된 암호화된 영구 볼륨의 csi-kms-connection-details ConfigMap에 설정된 값을 재정의합니다.

절차

  1. 테넌트 네임스페이스에 있는지 확인합니다.
  2. 워크로드 → ConfigMap을 클릭합니다.
  3. ConfigMap 생성을 클릭합니다.
  4. 다음은 샘플 yaml입니다. 지정된 테넌트 네임스페이스에 대해 덮어쓸 값은 아래 표시된 대로 data 섹션에서 지정할 수 있습니다.

    ---
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: ceph-csi-kms-config
    data:
      vaultAddress: "<vault_address:port>"
      vaultBackendPath: "<backend_path>"
      vaultTLSServerName: "<vault_tls_server_name>"
      vaultNamespace: "<vault_namespace>"
  5. yaml을 편집한 후 생성을 클릭합니다.

3장. 블록 풀

OpenShift Data Foundation Operator는 사용 중인 플랫폼에 따라 기본 스토리지 풀 세트를 설치합니다. 이러한 기본 스토리지 풀은 Operator에서 소유하고 제어하며 삭제하거나 수정할 수 없습니다. OpenShift Container Platform을 사용하면 다음 기능을 제공하는 스토리지 클래스에 매핑되는 여러 사용자 정의 스토리지 풀을 생성할 수 있습니다.

  • 자체 고가용성으로 애플리케이션을 활성화하여 두 개의 복제본이 있는 영구 볼륨을 사용하므로 애플리케이션 성능이 저하될 수 있습니다.
  • 압축이 활성화된 스토리지 클래스를 사용하여 영구 볼륨 클레임 공간을 절약할 수 있습니다.
참고

외부 모드 OpenShift Data Foundation 클러스터에서는 여러 블록 풀이 지원되지 않습니다.

3.1. 블록 풀 생성

사전 요구 사항

  • 관리자로 OpenShift Container Platform 웹 콘솔에 로그인해야 합니다.

절차

  1. 스토리지 → 데이터 기반을 클릭합니다.
  2. 스토리지 시스템 탭에서 스토리지 시스템을 선택한 다음 BlockPools 탭을 클릭합니다.
  3. 블록 풀 생성을 클릭합니다.
  4. 풀 이름 을 입력합니다.

    참고

    기본 풀에서 2방향 복제 데이터 보호 정책을 사용하는 것은 지원되지 않습니다. 그러나 추가 풀을 생성하는 경우 양방향 복제를 사용할 수 있습니다.

  5. 2방향 복제 또는 3방향 복제 데이터 보호 정책을 선택합니다.
  6. 볼륨 유형 을 선택합니다.
  7. 선택 사항: 데이터를 압축해야 하는 경우 압축 활성화 확인란을 선택합니다.

    압축을 사용하면 애플리케이션 성능에 영향을 줄 수 있으며, 데이터를 이미 압축하거나 암호화할 때 유용할 수 있습니다. 압축을 활성화하기 전에 기록된 데이터는 압축되지 않습니다.

  8. 생성을 클릭합니다.

3.2. 기존 풀 업데이트

사전 요구 사항

  • 관리자로 OpenShift Container Platform 웹 콘솔에 로그인해야 합니다.

절차

  1. 스토리지 → 데이터 기반을 클릭합니다.
  2. 스토리지 시스템 탭에서 스토리지 시스템을 선택한 다음 BlockPools 를 클릭합니다.
  3. 업데이트하려는 풀 끝에 있는 작업 메뉴(Cinder)를 클릭합니다.
  4. 블록 풀 편집 을 클릭합니다.
  5. 양식 세부 정보를 다음과 같이 수정합니다.

    참고

    기본 풀에서 2방향 복제 데이터 보호 정책을 사용하는 것은 지원되지 않습니다. 그러나 추가 풀을 생성하는 경우 양방향 복제를 사용할 수 있습니다.

    1. 데이터 보호 정책을 2-way Replication 또는 3-way Replication으로 변경합니다.
    2. 압축 옵션을 활성화하거나 비활성화합니다.

      압축을 사용하면 애플리케이션 성능에 영향을 줄 수 있으며, 데이터를 이미 압축하거나 암호화할 때 유용할 수 있습니다. 압축을 활성화하기 전에 기록된 데이터는 압축되지 않습니다.

  6. 저장을 클릭합니다.

3.3. 풀 삭제

OpenShift Data Foundation에서 풀을 삭제하려면 다음 절차를 사용하십시오.

사전 요구 사항

  • 관리자로 OpenShift Container Platform 웹 콘솔에 로그인해야 합니다.

절차

  1. . 스토리지 → 데이터 기반을 클릭합니다.
  2. 스토리지 시스템 탭에서 스토리지 시스템을 선택한 다음 BlockPools 탭을 클릭합니다.
  3. 삭제할 풀의 마지막에 있는 작업 메뉴(SAML)를 클릭합니다.
  4. 블록 풀 삭제를 클릭합니다.
  5. 삭제를 클릭하여 풀 제거를 확인합니다.
참고

PVC에 바인딩되면 풀을 삭제할 수 없습니다. 이 활동을 수행하기 전에 모든 리소스를 분리해야합니다.

4장. OpenShift Container Platform 서비스의 스토리지 구성

OpenShift Data Foundation을 사용하여 이미지 레지스트리, 모니터링 및 로깅과 같은 OpenShift Container Platform 서비스에 대한 스토리지를 제공할 수 있습니다.

이러한 서비스에 대한 스토리지를 구성하는 프로세스는 OpenShift Data Foundation 배포에 사용된 인프라에 따라 다릅니다.

주의

항상 이러한 서비스를 위한 충분한 저장 용량이 있는지 확인하십시오. 이러한 중요한 서비스의 스토리지가 공간이 부족하면 클러스터가 작동할 수 없게 되고 복구하기가 매우 어렵습니다.

Red Hat은 이러한 서비스에 대해 짧은 큐레이션 및 보존 간격을 설정할 것을 권장합니다. 자세한 내용은 OpenShift Container Platform 설명서의 Prometheus 메트릭 데이터 모니터링 가이드에 대한 Curator 일정 구성 및 보존 시간 수정을 참조하십시오.

이러한 서비스를 위한 저장 공간이 부족하면 Red Hat 고객 지원에 문의하십시오.

4.1. OpenShift Data Foundation을 사용하도록 이미지 레지스트리 구성

OpenShift Container Platform은 클러스터에서 표준 워크로드로 실행되는 기본 컨테이너 이미지 레지스트리를 제공합니다. 일반적으로 레지스트리는 클러스터에 빌드된 이미지의 게시 대상과 클러스터에서 실행되는 워크로드의 이미지 소스로 사용됩니다.

참고

OpenShift Container Plaform 4.11부터 이미지 레지스트리를 구성하는 데 권장되는 백엔드 스토리지가 오브젝트 스토리지입니다.

이 섹션의 지침에 따라 OpenShift Data Foundation을 컨테이너 이미지 레지스트리에 대한 스토리지로 구성합니다. AWS에서 레지스트리의 스토리지를 변경할 필요가 없습니다. 그러나 스토리지를 vSphere 및 베어 메탈 플랫폼의 OpenShift Data Foundation Persistent Volume으로 변경하는 것이 좋습니다.

주의

이 프로세스는 기존 이미지 레지스트리에서 새 이미지 레지스트리로 데이터를 마이그레이션하지 않습니다. 기존 레지스트리에 컨테이너 이미지가 이미 있는 경우 이 프로세스를 완료하기 전에 레지스트리를 백업하고 이 프로세스가 완료되면 이미지를 다시 등록합니다.

4.1.1. Multicloud Object Gateway를 OpenShift 이미지 레지스트리의 백엔드 스토리지로 구성

MCG(Multicloud Object Gateway)를 OpenShift Container Platform 버전 4.11부터 온프레미스 OpenShift 배포에서 OpenShift 이미지 레지스트리 백엔드 스토리지로 사용할 수 있습니다.

사전 요구 사항

  • OpenShift 웹 콘솔에 대한 관리 액세스.
  • MCG가 있는 실행 중인 OpenShift Data Foundation 클러스터입니다.

절차

  1. 오브젝트 버킷 클레임 생성 단계에 따라 ObjectBucketClaim을 생성합니다.
  2. image-registry-private-configuration-user 시크릿을 생성합니다.

    1. OpenShift 웹 콘솔로 이동합니다.
    2. ObjectBucketClaim - Cryostat ObjectBucketClaim Data 를 클릭합니다.
    3. ObjectBucketClaim 데이터에서 openshift-image-registry 네임스페이스 에서 MCG 액세스 키 및 MCG 시크릿 키를 찾습니다.
    4. 다음 명령을 사용하여 시크릿을 생성합니다.

      $ oc create secret generic image-registry-private-configuration-user --from-literal=REGISTRY_STORAGE_S3_ACCESSKEY=<MCG Accesskey> --from-literal=REGISTRY_STORAGE_S3_SECRETKEY=<MCG Secretkey> --namespace openshift-image-registry
  3. Image Registry Operator의 managementState 상태를 Managed 로 변경합니다.

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --type merge -p '{"spec": {"managementState": "Managed"}}'
  4. Image Registry Operator 구성 파일의 spec.storage 섹션을 편집합니다.

    1. 웹 콘솔의 Object Bucket Claim Data 섹션 아래의 unique-bucket-nameregionEndpoint 를 가져오거나 명령에서 regionEndpoint 및 unique-bucket-name에 대한 정보를 가져올 수도 있습니다.

       $ oc describe  noobaa
    2. regionEndpointhttp://<Endpoint-name>:<port> 로 추가합니다.

      • StorageClass는 ceph-rgw storageclass 및 입니다.
      • endpoint는 openshift-storage 네임스페이스에서 내부 SVC를 가리킵니다.
    3. image-registry Pod는 Operator 레지스트리 구성 파일을 변경한 후 생성됩니다.

      $ oc edit configs.imageregistry.operator.openshift.io -n openshift-image-registry
      apiVersion: imageregistry.operator.openshift.io/v1
      kind: Config
      metadata:
      [..]
      name: cluster
      spec:
      [..]
      storage:
      s3:
      
        bucket: <Unique-bucket-name>
      
        region: us-east-1 (Use this region as default)
      
        regionEndpoint: https://<Endpoint-name>:<port>
      
        virtualHostedStyle: false
  5. 이미지 레지스트리 설정을 기본값으로 재설정합니다.

    $ oc get pods -n openshift-image-registry

검증 단계

  • 다음 명령을 실행하여 MCG를 OpenShift 이미지 레지스트리 백엔드 스토리지로 성공적으로 구성했는지 확인합니다.

    $ oc get pods -n openshift-image-registry

    출력 예

    $ oc get pods -n openshift-image-registry
    
    NAME        	                                   READY   STATUS     RESTARTS    AGE
    
    cluster-image-registry-operator-56d78bc5fb-bxcgv   2/2 	   Running 	    0         44d
    image-pruner-1605830400-29r7k                  	   0/1 	   Completed    0         10h
    image-registry-b6c8f4596-ln88h                 	   1/1 	   Running 	    0         17d
    node-ca-2nxvz                                  	   1/1 	   Running    	0         44d
    node-ca-dtwjd                                  	   1/1 	   Running 	    0         44d
    node-ca-h92rj                                  	   1/1 	   Running 	    0         44d
    node-ca-k9bkd                                  	   1/1 	   Running 	    0         44d
    node-ca-stkzc                                  	   1/1 	   Running 	    0         44d
    node-ca-xn8h4                                  	   1/1 	   Running 	    0         44d

  • (선택 사항) 다음 명령을 실행하여 MCG를 OpenShift 이미지 레지스트리 백엔드 스토리지로 성공적으로 구성했는지 확인할 수도 있습니다.

    $ oc describe pod <image-registry-name>

    출력 예

    $ oc describe pod image-registry-b6c8f4596-ln88h
    
    Environment:
    
          REGISTRY_STORAGE_S3_REGIONENDPOINT:      http://s3.openshift-storage.svc
    
          REGISTRY_STORAGE:                        s3
    
          REGISTRY_STORAGE_S3_BUCKET:              bucket-registry-mcg
    
          REGISTRY_STORAGE_S3_REGION:              us-east-1
    
          REGISTRY_STORAGE_S3_ENCRYPT:             true
    
          REGISTRY_STORAGE_S3_VIRTUALHOSTEDSTYLE:  false
    
          REGISTRY_STORAGE_S3_USEDUALSTACK:        true
    
          REGISTRY_STORAGE_S3_ACCESSKEY:           <set to the key 'REGISTRY_STORAGE_S3_ACCESSKEY' in secret 'image-registry-private-configuration'> Optional: false
    
          REGISTRY_STORAGE_S3_SECRETKEY:           <set to the key 'REGISTRY_STORAGE_S3_SECRETKEY' in secret 'image-registry-private-configuration'> Optional: false
    
          REGISTRY_HTTP_ADDR:                      :5000
    
          REGISTRY_HTTP_NET:                       tcp
    
          REGISTRY_HTTP_SECRET:                    57b943f691c878e342bac34e657b702bd6ca5488d51f839fecafa918a79a5fc6ed70184cab047601403c1f383e54d458744062dcaaa483816d82408bb56e686f
    
          REGISTRY_LOG_LEVEL:                      info
    
          REGISTRY_OPENSHIFT_QUOTA_ENABLED:        true
    
          REGISTRY_STORAGE_CACHE_BLOBDESCRIPTOR:   inmemory
    
          REGISTRY_STORAGE_DELETE_ENABLED:         true
    
          REGISTRY_OPENSHIFT_METRICS_ENABLED:      true
    
          REGISTRY_OPENSHIFT_SERVER_ADDR:          image-registry.openshift-image-registry.svc:5000
    
          REGISTRY_HTTP_TLS_CERTIFICATE:           /etc/secrets/tls.crt
    
          REGISTRY_HTTP_TLS_KEY:                   /etc/secrets/tls.key

4.1.2. OpenShift Data Foundation CephFS를 OpenShift 이미지 레지스트리의 백엔드 스토리지로 구성

사전 요구 사항

  • OpenShift 웹 콘솔에 대한 관리자 액세스 권한이 있습니다.
  • OpenShift Data Foundation Operator는 openshift-storage 네임스페이스에 설치 및 실행됩니다. OpenShift 웹 콘솔에서 Operator → 설치된 Operator 를 클릭하여 설치된 Operator 를 확인합니다.
  • 이미지 레지스트리 Operator가 openshift-image-registry 네임스페이스에 설치되고 실행됩니다. OpenShift 웹 콘솔에서 AdministrationCluster SettingsCluster Operators 를 클릭하여 클러스터 운영자를 확인합니다.
  • provisioner openshift-storage.cephfs.csi.ceph.com 이 있는 스토리지 클래스를 사용할 수 있습니다. OpenShift 웹 콘솔에서 스토리지 → StorageClasses 를 클릭하여 사용 가능한 스토리지 클래스를 확인합니다.

절차

  1. 이미지 레지스트리가 사용할 영구 볼륨 클레임을 생성합니다.

    1. OpenShift 웹 콘솔에서 스토리지영구 볼륨 클레임 을 클릭합니다.
    2. 프로젝트를 openshift-image-registry 로 설정합니다.
    3. 영구 볼륨 클레임 생성을 클릭합니다.

      1. 위에서 검색한 사용 가능한 스토리지 클래스 목록에서 provisioner openshift-storage.cephfs.csi.ceph.com 을 사용하여 스토리지 클래스 를 지정합니다.
      2. 영구 볼륨 클레임 이름 (예: ocs4registry )을 지정합니다.
      3. 공유 액세스(RWX)의 액세스 모드를 지정합니다.
      4. 최소 100GB의 크기를 지정합니다.
      5. 생성을 클릭합니다.

        새 영구 볼륨 클레임의 상태가 Bound 로 표시될 때까지 기다립니다.

  2. 새 영구 볼륨 클레임을 사용하도록 클러스터의 이미지 레지스트리를 구성합니다.

    1. AdministrationCustom Resource Definitions 를 클릭합니다.
    2. imageregistry.operator.openshift.io 그룹과 연결된 구성 사용자 정의 리소스 정의를 클릭합니다.
    3. 인스턴스 탭을 클릭합니다.
    4. 클러스터 인스턴스 외에도 Action Menu(작업 메뉴) → Edit Config (구성 편집) 를 클릭합니다.
    5. 새 영구 볼륨 클레임을 이미지 레지스트리의 영구 스토리지로 추가합니다.

      1. spec: 에서 다음을 추가하고 필요한 경우 기존 storage: 섹션을 바꿉니다.

          storage:
            pvc:
              claim: <new-pvc-name>

        예를 들어 다음과 같습니다.

          storage:
            pvc:
              claim: ocs4registry
      2. 저장을 클릭합니다.
  3. 새 구성이 사용되고 있는지 확인합니다.

    1. 워크로드포드 를 클릭합니다.
    2. 프로젝트를 openshift-image-registry 로 설정합니다.
    3. image-registry-* 포드가 Running 의 상태와 함께 표시되고 이전 image-registry-* pod가 종료되었는지 확인합니다.
    4. image-registry-* 포드를 클릭하여 Pod 세부 정보를 확인합니다.
    5. Volumes (볼륨)로 스크롤하여 registry-storage 볼륨에 새 영구 볼륨 클레임과 일치하는 Type (유형)이 있는지 확인합니다(예: ocs4registry ).

4.2. OpenShift Data Foundation을 사용하도록 모니터링 구성

OpenShift Data Foundation에서는 Prometheus 및 Alert Manager로 구성된 모니터링 스택을 제공합니다.

이 섹션의 지침에 따라 OpenShift Data Foundation을 모니터링 스택의 스토리지로 구성합니다.

중요

스토리지 공간이 부족하면 모니터링이 작동하지 않습니다. 항상 모니터링을 위한 충분한 저장 용량이 있는지 확인하십시오.

이 서비스에 대한 단기 보존 간격을 구성하는 것이 좋습니다. 자세한 내용은 OpenShift Container Platform 설명서에서 모니터링 가이드의 Prometheus 지표 데이터의 보존 시간 수정 을 참조하십시오.

사전 요구 사항

  • OpenShift 웹 콘솔에 대한 관리자 액세스 권한이 있습니다.
  • OpenShift Data Foundation Operator는 openshift-storage 네임스페이스에 설치 및 실행됩니다. OpenShift 웹 콘솔에서 Operator → 설치된 Operator 를 클릭하여 설치된 Operator 를 확인합니다.
  • Operator 모니터링이 openshift-monitoring 네임스페이스에 설치되고 실행됩니다. OpenShift 웹 콘솔에서 AdministrationCluster SettingsCluster Operators 를 클릭하여 클러스터 운영자를 확인합니다.
  • provisioner openshift-storage.rbd.csi.ceph.com 이 있는 스토리지 클래스를 사용할 수 있습니다. OpenShift 웹 콘솔에서 스토리지 → StorageClasses 를 클릭하여 사용 가능한 스토리지 클래스를 확인합니다.

절차

  1. OpenShift 웹 콘솔에서 워크로드구성 맵 으로 이동합니다.
  2. 프로젝트 드롭다운을 openshift-monitoring 로 설정합니다.
  3. 구성 맵 생성을 클릭합니다.
  4. 다음 예제를 사용하여 새 cluster-monitoring-config Config Map을 정의합니다.

    각도괄호(< , > )의 내용을 고유한 값으로 바꿉니다(예 : 24h 또는 storage: 40Gi ).

    storageClassName 을 provisioner openshift-storage.rbd.csi.ceph.com 을 사용하는 storageclass 로 바꿉니다. 아래 예제에서 storageclass 의 이름은 ocs-storagecluster-ceph-rbd 입니다.

    cluster-monitoring-config 구성 맵 예

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
          prometheusK8s:
            retention: <time to retain monitoring files, e.g. 24h>
            volumeClaimTemplate:
              metadata:
                name: ocs-prometheus-claim
              spec:
                storageClassName: ocs-storagecluster-ceph-rbd
                resources:
                  requests:
                    storage: <size of claim, e.g. 40Gi>
          alertmanagerMain:
            volumeClaimTemplate:
              metadata:
                name: ocs-alertmanager-claim
              spec:
                storageClassName: ocs-storagecluster-ceph-rbd
                resources:
                  requests:
                    storage: <size of claim, e.g. 40Gi>

  5. 생성을 클릭하여 구성 맵을 저장하고 생성합니다.

검증 단계

  1. 영구 볼륨 클레임이 포드에 바인딩되었는지 확인합니다.

    1. 스토리지영구 볼륨 클레임 으로 이동합니다.
    2. 프로젝트 드롭다운을 openshift-monitoring 로 설정합니다.
    3. 3개의 alertmanager-main-* Pod와 prometheus-k8s-* pod에 연결된 Bound 상태로 5개의 영구 볼륨 클레임이 표시되는지 확인합니다.

      그림 4.1. 생성 및 바인딩된 스토리지 모니터링

      openshift-monitoring 프로젝트에 바인딩된 영구 볼륨 클레임이 있는 Pod 5개를 표시하는 OpenShift 웹 콘솔의 스크린샷
  2. alertmanager-main-* 포드가 Running 상태로 표시되는지 확인합니다.

    1. 워크로드Pod 로 이동합니다.
    2. alertmanager-main-* pod를 클릭하여 Pod 세부 정보를 확인합니다.
    3. Volumes (볼륨)로 스크롤하여 볼륨에 새 영구 볼륨 클레임 중 하나와 일치하는 유형,ocs-alertmanager-claim - claim이 있는지 확인합니다(예: ocs-alertmanager-main -0).

      그림 4.2. alertmanager-main-* Pod에 연결된 영구 볼륨 클레임

      altermanager pod에 연결된 영구 볼륨 클레임을 표시하는 OpenShift 웹 콘솔의 스크린샷
  3. prometheus-k8s-* Pod가 Running 상태로 표시되는지 확인합니다.

    1. prometheus-k8s-* Pod를 클릭하여 Pod 세부 정보를 확인합니다.
    2. Volumes (볼륨)로 스크롤하여 볼륨에 새 영구 볼륨 클레임 중 하나와 일치하는 유형,ocs-prometheus-claim -claim(예: ocs-prometheus-prometheus-k8s -0)이 있는지 확인합니다.

      그림 4.3. prometheus-k8s-* Pod에 연결된 영구 볼륨 클레임

      prometheus Pod에 연결된 영구 볼륨 클레임을 표시하는 OpenShift 웹 콘솔의 스크린샷

4.3. 프로비저닝 수준 정책 제어 해제 [기술 프리뷰]

Overprovision 제어는 특정 애플리케이션 네임스페이스를 기반으로 스토리지 클러스터에서 사용하는 PVC(영구 볼륨 클레임) 양에 대한 할당량을 정의할 수 있는 메커니즘입니다.

오버 프로비저닝 제어 메커니즘을 활성화하면 스토리지 클러스터에서 사용하는 PVC를 오버 프로비저닝할 수 없습니다. OpenShift는 ClusterResourceQuota 의 도움으로 클러스터 범위에서 집계된 리소스 사용을 제한하는 제약 조건을 정의할 수 있는 유연성을 제공합니다. 자세한 내용은 OpenShift ClusterResourceQuota 에서 참조하십시오.

프로비저닝 제어를 통해 ClusteResourceQuota 이 시작되며 각 스토리지 클래스에 대한 스토리지 용량 제한을 설정할 수 있습니다. 알람은 용량 제한의 80%를 사용할 때 트리거됩니다.

참고

프로비저닝 수준 정책 제어는 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다. 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

OpenShift Data Foundation 배포에 대한 자세한 내용은 Product Documentation 을 참조하여 플랫폼에 따라 배포 절차를 선택합니다.

사전 요구 사항

  • OpenShift Data Foundation 클러스터가 생성되었는지 확인합니다.

절차

  1. 명령줄 인터페이스 또는 사용자 인터페이스에서 storagecluster 를 배포합니다.
  2. 애플리케이션 네임스페이스에 레이블을 지정합니다.

    apiVersion: v1
    kind: Namespace
    metadata:
         name: <desired_name>
         labels:
              storagequota: <desired_label>
    <desired_name>
    애플리케이션 네임스페이스의 이름을 지정합니다(예: quota-rbd ).
    <desired_label>
    스토리지 할당량의 레이블을 지정합니다(예: storagequota1 ).
  3. storagecluster 를 편집하여 스토리지 클래스에 할당량 제한을 설정합니다.

    $ oc edit storagecluster -n openshift-storage <ocs_storagecluster_name>
    <ocs_storagecluster_name>
    스토리지 클러스터의 이름을 지정합니다.
  4. 필요한 하드 제한이 있는 Overprovision Control에 대한 항목을 StorageCluster.Spec:에 추가합니다.

    apiVersion: ocs.openshift.io/v1
    kind: StorageCluster
    spec:
     [...]
         overprovisionControl:
         - capacity: <desired_quota_limit>
              storageClassName: <storage_class_name>
              quotaName: <desired_quota_name>
              selector:
                labels:
                       matchLabels:
                        storagequota: <desired_label>
    [...]
    <desired_quota_limit>
    스토리지 클래스에 필요한 할당량 제한을 지정합니다(예: 27Ti ).
    <storage_class_name>
    할당량 제한을 설정할 스토리지 클래스의 이름을 지정합니다(예: ocs-storagecluster-ceph-rbd ).
    <desired_quota_name>
    스토리지 할당량의 이름을 지정합니다(예: quota1 ).
    <desired_label>
    스토리지 할당량의 레이블을 지정합니다(예: storagequota1 ).
  5. 수정된 스토리지 클러스터를 저장합니다.
  6. clusterresourcequota 가 정의되어 있는지 확인합니다.

    참고

    이전 단계에서 정의한 quotaName (예: quota1 )으로 clusterresourcequota 를 예상합니다.

    $ oc get clusterresourcequota -A
    
    $ oc describe clusterresourcequota -A

4.4. OpenShift Data Foundation의 클러스터 로깅

클러스터 로깅을 배포하여 다양한 OpenShift Container Platform 서비스에 대한 로그를 집계할 수 있습니다. 클러스터 로깅 배포 방법에 대한 자세한 내용은 클러스터 로깅 배포를 참조하십시오.

초기 OpenShift Container Platform 배포 시 OpenShift Data Foundation은 기본적으로 구성되지 않으며 OpenShift Container Platform 클러스터는 노드에서 사용 가능한 기본 스토리지에만 의존합니다. OpenShift Data Foundation에서 지원하는 OpenShift Logging(ElasticSearch)의 기본 구성을 편집하여 OpenShift Data Foundation의 백업 로깅(Elasticsearch)을 사용할 수 있습니다.

중요

항상 이러한 서비스를 위한 충분한 저장 용량이 있는지 확인하십시오. 이러한 중요한 서비스를 위한 스토리지 공간이 부족하면 로깅 애플리케이션이 작동할 수 없고 복구하기가 매우 어렵습니다.

Red Hat은 이러한 서비스에 대해 짧은 큐레이션 및 보존 간격을 설정할 것을 권장합니다. 자세한 내용은 OpenShift Container Platform 설명서의 클러스터 로깅 큐레이터 를 참조하십시오.

이러한 서비스를 위한 저장 공간이 부족하면 Red Hat 고객 지원에 문의하십시오.

4.4.1. 영구 스토리지 구성

스토리지 클래스 이름 및 크기 매개변수를 사용하여 Elasticsearch 클러스터의 영구 스토리지 클래스 및 크기를 구성할 수 있습니다. Cluster Logging Operator는 이러한 매개변수를 기반으로 Elasticsearch 클러스터의 각 데이터 노드에 대한 영구 볼륨 클레임을 생성합니다. 예를 들어 다음과 같습니다.

spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage:
          storageClassName: "ocs-storagecluster-ceph-rbd”
          size: "200G"

이 예제에서는 클러스터의 각 데이터 노드가 200GiB ocs-storagecluster-ceph-rbd 스토리지를 요청하는 영구 볼륨 클레임에 바인딩되도록 지정합니다. 각 기본 분할은 단일 복제본에서 지원합니다. shard의 사본은 모든 노드에 복제되며 항상 사용할 수 있으며 단일 중복 정책으로 인해 두 개 이상의 노드가 존재하는 경우 복사본을 복구할 수 있습니다. Elasticsearch 복제 정책에 대한 자세한 내용은 클러스터 로깅 배포 및 구성Elasticsearch 복제 정책을 참조하십시오.

참고

스토리지 블록을 누락하면 기본 스토리지에서 지원하는 배포가 생성됩니다. 예를 들어 다음과 같습니다.

spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage: {}

자세한 내용은 클러스터 로깅 구성을 참조하십시오.

4.4.2. OpenShift data Foundation을 사용하도록 클러스터 로깅 구성

이 섹션의 지침에 따라 OpenShift Data Foundation을 OpenShift 클러스터 로깅을 위한 스토리지로 구성합니다.

참고

OpenShift Data Foundation에서 처음으로 로깅을 구성할 때 모든 로그를 가져올 수 있습니다. 그러나 로깅을 제거하고 다시 설치한 후에는 이전 로그가 제거되고 새 로그만 처리됩니다.

사전 요구 사항

  • OpenShift 웹 콘솔에 대한 관리자 액세스 권한이 있습니다.
  • OpenShift Data Foundation Operator는 openshift-storage 네임스페이스에 설치 및 실행됩니다.
  • 클러스터 로깅 Operator가 openshift-logging 네임스페이스에 설치되고 실행됩니다.

절차

  1. OpenShift 웹 콘솔의 왼쪽 창에서 Administration → Custom Resource Definitions 를 클릭합니다.
  2. 사용자 정의 리소스 정의 페이지에서 ClusterLogging 을 클릭합니다.
  3. 사용자 정의 리소스 정의 개요 페이지의 작업 메뉴에서 인스턴스 보기를 선택하거나 인스턴스 탭을 클릭합니다.
  4. 클러스터 로깅 페이지에서 클러스터 로깅 생성을 클릭합니다.

    데이터를 로드하기 위해 페이지를 새로 고쳐야 할 수도 있습니다.

  5. YAML에서 storageClassName 을 provisioner openshift- storage.rbd.csi.ceph.com 을 사용하는 storage 클래스 로 교체합니다. 아래 예제에서 storageclass 의 이름은 ocs-storagecluster-ceph-rbd 입니다.

    apiVersion: "logging.openshift.io/v1"
    kind: "ClusterLogging"
    metadata:
      name: "instance"
      namespace: "openshift-logging"
    spec:
      managementState: "Managed"
      logStore:
        type: "elasticsearch"
        elasticsearch:
          nodeCount: 3
          storage:
            storageClassName: ocs-storagecluster-ceph-rbd
            size: 200G # Change as per your requirement
          redundancyPolicy: "SingleRedundancy"
      visualization:
        type: "kibana"
        kibana:
          replicas: 1
      curation:
        type: "curator"
        curator:
          schedule: "30 3 * * *"
      collection:
        logs:
          type: "fluentd"
          fluentd: {}

    OpenShift Data Foundation 노드에 테인트된 경우 로깅을 위해 daemonset Pod를 예약할 수 있도록 허용 오차를 추가해야 합니다.

    spec:
    [...]
      collection:
        logs:
          fluentd:
            tolerations:
            - effect: NoSchedule
              key: node.ocs.openshift.io/storage
              value: 'true'
          type: fluentd
  6. 저장을 클릭합니다.

검증 단계

  1. 영구 볼륨 클레임이 elasticsearch 포드에 바인딩되었는지 확인합니다.

    1. 스토리지영구 볼륨 클레임 으로 이동합니다.
    2. 프로젝트 드롭다운을 openshift-logging 으로 설정합니다.
    3. elasticsearch-* Pod에 연결된 Bound 상태로 영구 볼륨 클레임이 표시되는지 확인합니다.

      그림 4.4. 생성 및 바인딩된 클러스터 로깅

      elasticsearch Pod에 바인딩된 상태가 있는 영구 볼륨 클레임의 스크린샷
  2. 새 클러스터 로깅이 사용 중인지 확인합니다.

    1. 워크로드 → 포드 를 클릭합니다.
    2. 프로젝트를 openshift-logging 으로 설정합니다.
    3. elasticsearch-* 포드가 Running (실행 중) 상태와 함께 표시되는지 확인합니다.
    4. elasticsearch-* 포드를 클릭하여 Pod 세부 정보를 확인합니다.
    5. Volumes (볼륨)로 스크롤하여 elasticsearch 볼륨에 새 영구 볼륨 클레임(예: elasticsearch-elasticsearch-cdm-9r624biv-3) 과 일치하는 Type 이 있는지 확인합니다.
    6. 영구 볼륨 클레임 이름을 클릭하고 PersistentVolumeClaim 개요 페이지에서 스토리지 클래스 이름을 확인합니다.
참고

Elasticsearch Pod에 연결된 PV의 PV 전체 시나리오를 방지하려면 더 짧은 큐레이터 시간을 사용해야 합니다.

보존 설정에 따라 Elasticsearch 데이터를 삭제하도록 Curator를 구성할 수 있습니다. 기본적으로 5일의 다음 기본 인덱스 데이터 보존을 설정하는 것이 좋습니다.

config.yaml: |
    openshift-storage:
      delete:
        days: 5

자세한 내용은 Elasticsearch 데이터 저장을 참조하십시오.

참고

영구 볼륨 클레임에서 지원하는 클러스터 로깅을 제거하려면 해당 배포 가이드의 제거 장에 있는 OpenShift Data Foundation에서 클러스터 로깅 Operator 제거 절차를 사용하십시오.

5장. OpenShift Data Foundation으로 OpenShift Container Platform 애플리케이션 백업

OpenShift Container Platform을 설치하는 동안 OpenShift Data Foundation을 직접 설치할 수 없습니다. 그러나 Operator Hub를 사용하여 기존 OpenShift Container Platform에 OpenShift Data Foundation을 설치한 다음 OpenShift Data Foundation에서 지원하도록 OpenShift Container Platform 애플리케이션을 구성할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform이 설치되어 있으며 OpenShift 웹 콘솔에 대한 관리자 액세스 권한이 있습니다.
  • OpenShift Data Foundation은 openshift-storage 네임스페이스에 설치되고 실행됩니다.

절차

  1. OpenShift 웹 콘솔에서 다음 중 하나를 수행합니다.

    • 워크로드 → 배포를 클릭합니다.

      배포 페이지에서 다음 중 하나를 수행할 수 있습니다.

      • 기존 배포를 선택하고 작업 메뉴( Action menu)에서 Add Storage (스토리지 추가) 옵션을 클릭합니다.
      • 새 배포를 생성한 다음 스토리지를 추가합니다.

        1. Create Deployment (배포 만들기)를 클릭하여 새 배포를 만듭니다.
        2. 요구 사항에 따라 YAML 을 편집하여 배포를 생성합니다.
        3. 생성을 클릭합니다.
        4. 페이지 오른쪽 상단에 있는 작업 드롭다운 메뉴에서 스토리지 추가 를 선택합니다.
    • 워크로드 → 배포 구성을 클릭합니다.

      배포 구성 페이지에서 다음 중 하나를 수행할 수 있습니다.

      • 기존 배포를 선택하고 작업 메뉴( Action menu)에서 Add Storage (스토리지 추가) 옵션을 클릭합니다.
      • 새 배포를 생성한 다음 스토리지를 추가합니다.

        1. Create Deployment Config (배포 구성 만들기)를 클릭하여 새 배포를 만듭니다.
        2. 요구 사항에 따라 YAML 을 편집하여 배포를 생성합니다.
        3. 생성을 클릭합니다.
        4. 페이지 오른쪽 상단에 있는 작업 드롭다운 메뉴에서 스토리지 추가 를 선택합니다.
  2. 스토리지 추가 페이지에서 다음 옵션 중 하나를 선택할 수 있습니다.

    • Use existing claim 옵션을 클릭하고 드롭다운 목록에서 적합한 PVC를 선택합니다.
    • 새 클레임 생성 옵션을 클릭합니다.

      1. 스토리지 클래스 드롭다운 목록에서 적절한 CephFS 또는 RBD 스토리지 클래스 를 선택합니다.
      2. 영구 볼륨 클레임의 이름을 제공합니다.
      3. ReadWriteOnce(RWO) 또는 ReadWriteMany(RWX) 액세스 모드를 선택합니다.

        참고

        ReadOnlyMany(ROX)는 지원되지 않으므로 비활성화됩니다.

      4. 원하는 스토리지 용량의 크기를 선택합니다.

        참고

        블록 PV를 확장할 수 있지만 영구 볼륨 클레임 생성 후 스토리지 용량을 줄일 수 없습니다.

  3. 컨테이너 내부의 마운트 경로 및 하위 경로(필요한 경우)를 지정합니다.
  4. 저장을 클릭합니다.

검증 단계

  1. 구성에 따라 다음 중 하나를 수행합니다.

    • 워크로드 → 배포를 클릭합니다.
    • 워크로드 → 배포 구성을 클릭합니다.
  2. 필요에 따라 프로젝트를 설정합니다.
  3. 스토리지를 추가한 배포를 클릭하여 배포 세부 정보를 표시합니다.
  4. Volumes (볼륨)로 스크롤하여 배포에 할당된 영구 볼륨 클레임과 일치하는 Type 이 있는지 확인합니다.
  5. 영구 볼륨 클레임 이름을 클릭하고 영구 볼륨 클레임 개요 페이지에서 스토리지 클래스 이름을 확인합니다.

6장. 기존 외부 OpenShift Data Foundation 클러스터에 파일 및 오브젝트 스토리지 추가

OpenShift Data Foundation이 외부 모드로 구성된 경우 영구 볼륨 클레임 및 오브젝트 버킷 클레임에 스토리지를 제공하는 여러 가지 방법이 있습니다.

  • 블록 스토리지의 영구 볼륨 클레임은 외부 Red Hat Ceph Storage 클러스터에서 직접 제공됩니다.
  • 파일 스토리지의 영구 볼륨 클레임은 외부 Red Hat Ceph Storage 클러스터에 메타데이터 서버(MDS)를 추가하여 제공할 수 있습니다.
  • 오브젝트 스토리지의 오브젝트 버킷 클레임은 Multicloud Object Gateway를 사용하거나 외부 Red Hat Ceph Storage 클러스터에 Ceph Object Gateway를 추가하여 제공할 수 있습니다.

다음 프로세스를 사용하여(메타데이터 서버) 또는 오브젝트 스토리지(Ceph Object Gateway 사용) 또는 둘 다를 블록 스토리지만 제공하도록 배포된 외부 OpenShift Data Foundation 클러스터에 추가합니다.

사전 요구 사항

  • OpenShift Container Platform 버전 4.11 이상에 OpenShift Data Foundation 4.11이 설치되어 실행되고 있습니다. 또한 외부 모드의 OpenShift Data Foundation Cluster는 Ready 상태입니다.
  • 외부 Red Hat Ceph Storage 클러스터는 다음 중 하나 또는 둘 다로 구성됩니다.

    • 오브젝트 스토리지를 위해 OpenShift Container Platform 클러스터에서 액세스할 수 있는 Ceph Object Gateway(RGW) 끝점
    • 파일 저장을 위한 메타데이터 서버(MDS) 풀
  • 외부 OpenShift Data Foundation 클러스터 배포 중에 ceph-external-cluster-details-exporter.py 스크립트와 함께 사용되는 매개 변수를 알고 있는지 확인합니다.

절차

  1. 다음 명령을 사용하여 ceph-external-cluster-details-exporter.py python 스크립트의 OpenShift Data Foundation 버전을 다운로드합니다.

    oc get csv $(oc get csv -n openshift-storage | grep ocs-operator | awk '{print $1}') -n openshift-storage -o jsonpath='{.metadata.annotations.external\.features\.ocs\.openshift\.io/export-script}' | base64 --decode > ceph-external-cluster-details-exporter.py
  2. 외부 Red Hat Ceph Storage 클러스터의 모든 클라이언트 노드에서 ceph-external-cluster-details-exporter.py 를 실행하여 외부 Red Hat Ceph Storage 클러스터에서 권한을 업데이트합니다. 이 작업을 수행하려면 Red Hat Ceph Storage 관리자에게 문의해야 할 수 있습니다.

    # python3 ceph-external-cluster-details-exporter.py --upgrade \
    --run-as-user=ocs-client-name \
    --rgw-pool-prefix rgw-pool-prefix
    --run-as-user
    OpenShift Data Foundation 클러스터 배포 중에 사용되는 클라이언트 이름입니다. 다른 클라이언트 이름이 설정되지 않은 경우 기본 클라이언트 이름 client.healthchecker 를 사용합니다.
    --rgw-pool-prefix
    Ceph Object Gateway 풀에 사용되는 접두사입니다. 기본 접두사를 사용하는 경우 생략할 수 있습니다.
  3. 외부 Red Hat Ceph Storage 클러스터에서 구성 세부 정보를 생성하고 저장합니다.

    1. 외부 Red Hat Ceph Storage 클러스터의 클라이언트 노드에서 ceph-external-cluster-details-exporter.py 를 실행하여 구성 세부 정보를 생성합니다.

      # python3 ceph-external-cluster-details-exporter.py --rbd-data-pool-name rbd-block-pool-name --monitoring-endpoint ceph-mgr-prometheus-exporter-endpoint --monitoring-endpoint-port ceph-mgr-prometheus-exporter-port --run-as-user ocs-client-name  --rgw-endpoint rgw-endpoint --rgw-pool-prefix rgw-pool-prefix
      --monitoring-endpoint
      은 선택 사항입니다. OpenShift Container Platform 클러스터에서 연결할 수 있는 활성 및 대기 mgrs의 쉼표로 구분된 IP 주소 목록을 허용합니다. 제공하지 않으면 값이 자동으로 채워집니다.
      --monitoring-endpoint-port
      은 선택 사항입니다. 이는 --monitoring-endpoint 에서 지정한 ceph-mgr Prometheus 내보내기er와 연결된 포트입니다. 제공하지 않으면 값이 자동으로 채워집니다.
      --run-as-user
      OpenShift Data Foundation 클러스터 배포 중에 사용되는 클라이언트 이름입니다. 다른 클라이언트 이름이 설정되지 않은 경우 기본 클라이언트 이름 client.healthchecker를 사용합니다.
      --rgw-endpoint
      OpenShift Data Foundation의 Ceph Object Gateway를 통해 오브젝트 스토리지를 프로비저닝하기 위해 이 매개변수를 제공합니다. (선택 사항)
      --rgw-pool-prefix
      Ceph Object Gateway 풀에 사용되는 접두사입니다. 기본 접두사를 사용하는 경우 생략할 수 있습니다.

      사용자 권한은 다음과 같이 업데이트됩니다.

      caps: [mgr] allow command config
      caps: [mon] allow r, allow command quorum_status, allow command version
      caps: [osd] allow rwx pool=default.rgw.meta, allow r pool=.rgw.root, allow rw pool=default.rgw.control, allow rx pool=default.rgw.log, allow x pool=default.rgw.buckets.index
      참고

      Ceph Object Gateway 세부 정보(제공되는 경우)를 제외한 모든 매개변수(선택 사항 포함)가 외부 모드에서 OpenShift Data Foundation을 배포하는 동안 사용된 항목과 동일한지 확인합니다.

    2. 스크립트 출력을 external-cluster-config.json 파일에 저장합니다.

      다음 예제 출력에서는 생성된 구성 변경 사항을 굵은 텍스트로 보여줍니다.

      [{"name": "rook-ceph-mon-endpoints", "kind": "ConfigMap", "data": {"data": "xxx.xxx.xxx.xxx:xxxx", "maxMonId": "0", "mapping": "{}"}}, {"name": "rook-ceph-mon", "kind": "Secret", "data": {"admin-secret": "admin-secret", "fsid": "<fs-id>", "mon-secret": "mon-secret"}}, {"name": "rook-ceph-operator-creds", "kind": "Secret", "data": {"userID": "<user-id>", "userKey": "<user-key>"}}, {"name": "rook-csi-rbd-node", "kind": "Secret", "data": {"userID": "csi-rbd-node", "userKey": "<user-key>"}}, {"name": "ceph-rbd", "kind": "StorageClass", "data": {"pool": "<pool>"}}, {"name": "monitoring-endpoint", "kind": "CephCluster", "data": {"MonitoringEndpoint": "xxx.xxx.xxx.xxx", "MonitoringPort": "xxxx"}}, {"name": "rook-ceph-dashboard-link", "kind": "Secret", "data": {"userID": "ceph-dashboard-link", "userKey": "<user-key>"}}, {"name": "rook-csi-rbd-provisioner", "kind": "Secret", "data": {"userID": "csi-rbd-provisioner", "userKey": "<user-key>"}}, {"name": "rook-csi-cephfs-provisioner", "kind": "Secret", "data": {"adminID": "csi-cephfs-provisioner", "adminKey": "<admin-key>"}}, {"name": "rook-csi-cephfs-node", "kind": "Secret", "data": {"adminID": "csi-cephfs-node", "adminKey": "<admin-key>"}}, {"name": "cephfs", "kind": "StorageClass", "data": {"fsName": "cephfs", "pool": "cephfs_data"}}, {"name": "ceph-rgw", "kind": "StorageClass", "data": {"endpoint": "xxx.xxx.xxx.xxx:xxxx", "poolPrefix": "default"}}, {"name": "rgw-admin-ops-user", "kind": "Secret", "data": {"accessKey": "<access-key>", "secretKey": "<secret-key>"}}]
  4. 생성된 JSON 파일을 업로드합니다.

    1. OpenShift 웹 콘솔에 로그인합니다.
    2. 워크로드시크릿 을 클릭합니다.
    3. projectopenshift-storage 로 설정합니다.
    4. rook-ceph-external-cluster-details 를 클릭합니다.
    5. Actions (작업) → 시크릿 편집을 클릭합니다.
    6. 찾아보기 를 클릭하고 external-cluster-config.json 파일을 업로드합니다.
    7. 저장을 클릭합니다.

검증 단계

  • OpenShift Data Foundation 클러스터가 정상이고 데이터가 탄력적인지 확인하려면 스토리지데이터 기반 → 스토리지 시스템 탭으로 이동한 다음 스토리지 시스템 이름을 클릭합니다.

    • 개요블록 및 파일 탭에서 상태 카드를 확인하여 스토리지 클러스터 가 정상임을 나타내는 녹색 눈금이 있는지 확인합니다.
  • 파일 저장을 위해 메타데이터 서버를 추가한 경우:

    1. 워크로드포드 를 클릭하고 csi-cephfsplugin-* Pod가 새로 생성되고 Running 상태인지 확인합니다.
    2. 스토리지스토리지 클래스를 클릭하고 ocs-external-storagecluster-cephfs 스토리지 클래스가 생성되었는지 확인합니다.
  • 오브젝트 스토리지에 대해 Ceph Object Gateway를 추가한 경우:

    1. 스토리지스토리지 클래스를 클릭하고 ocs-external-storagecluster-ceph-rgw 스토리지 클래스가 생성되었는지 확인합니다.
    2. OpenShift Data Foundation 클러스터가 정상이고 데이터가 탄력적인지 확인하려면 스토리지데이터 기반 → 스토리지 시스템 탭으로 이동한 다음 스토리지 시스템 이름을 클릭합니다.
    3. 오브젝트 탭을 클릭하고 오브젝트 서비스 및 데이터 복원력 이 정상임을 나타내는 녹색 눈금이 있는지 확인합니다.

7장. Red Hat OpenShift Data Foundation 전용 작업자 노드를 사용하는 방법

Red Hat OpenShift Container Platform 서브스크립션에는 OpenShift Data Foundation 서브스크립션이 필요합니다. 그러나 인프라 노드를 사용하여 OpenShift Data Foundation 리소스를 예약하는 경우 OpenShift Container Platform 서브스크립션 비용을 절감할 수 있습니다.

Machine API를 지원하거나 사용하지 않는 환경에서 일관성을 유지하는 것이 중요합니다. 이로 인해 모든 경우 작업자 또는 infra로 레이블이 지정된 특수 범주의 노드를 사용하는 것이 좋습니다. 자세한 내용은 7.3절. “인프라 노드 수동 생성” 섹션을 참조하십시오.

7.1. 인프라 노드 분석

OpenShift Data Foundation에서 사용할 인프라 노드에는 몇 가지 속성이 있습니다. 노드가 RHOCP 인타이틀먼트를 사용하지 않도록 infra -role 레이블이 필요합니다. infra node-role 레이블은 OpenShift Data Foundation을 실행하는 노드에 대해 OpenShift Data Foundation 자격만 필요한지 확인해야 합니다.

  • node-role.kubernetes.io/infra로 레이블이 지정됩니다.

NoSchedule effect가 있는 OpenShift Data Foundation 테인트를 추가하는 것도 인프라 노드가 OpenShift Data Foundation 리소스만 예약하도록 합니다.

  • node.ocs.openshift.io/storage="true"로 테인트됨

레이블은 Descheduler 서브스크립션 비용이 적용되지 않도록 RHOCP 노드를 인프라 노드로 식별합니다. 테인트는 테인트된 노드에서 비 OpenShift Data Foundation 리소스를 예약할 수 없도록 합니다.

참고

노드에 스토리지 테인트를 추가하려면 openshift-dns daemonset 와 같은 다른 daemonset Pod에 대한 허용 오차 처리가 필요할 수 있습니다. 허용 오차를 관리하는 방법에 대한 자세한 내용은 기술 자료 문서를 참조하십시오. https://access.redhat.com/solutions/6592171.

OpenShift Data Foundation 서비스를 실행하는 데 사용할 인프라 노드에 필요한 테인트 및 레이블의 예:

    spec:
      taints:
      - effect: NoSchedule
        key: node.ocs.openshift.io/storage
        value: "true"
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/worker: ""
          node-role.kubernetes.io/infra: ""
          cluster.ocs.openshift.io/openshift-storage: ""

7.2. 인프라 노드 생성을 위한 시스템 세트

환경에서 Machine API가 지원되는 경우 인프라 노드를 프로비저닝할 Machine Set의 템플릿에 라벨을 추가해야 합니다. 머신 API로 생성된 노드에 레이블을 수동으로 추가하는 경우의 안티 패턴을 피하십시오. 이렇게 하는 것은 배포로 생성된 Pod에 라벨을 추가하는 것과 유사합니다. 두 경우 모두 Pod/node에 실패하면 교체 Pod/node에 적절한 라벨이 없습니다.

참고

EC2 환경에서는 각각 고유한 가용성 영역(예: us-east-2a, us-east-2b, us-east-2c)에서 인프라 노드를 프로비저닝하도록 구성된 세 개의 머신 세트가 필요합니다. 현재 OpenShift Data Foundation은 다음 세 개 이상의 가용 영역에 대한 배포를 지원하지 않습니다.

다음 머신 세트 템플릿 예제에서는 인프라 노드에 필요한 적절한 테인트 및 라벨을 사용하여 노드를 생성합니다. 이는 OpenShift Data Foundation 서비스를 실행하는 데 사용됩니다.

  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: kb-s25vf
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: kb-s25vf-infra-us-west-2a
    spec:
      taints:
      - effect: NoSchedule
        key: node.ocs.openshift.io/storage
        value: "true"
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/infra: ""
          cluster.ocs.openshift.io/openshift-storage: ""
중요

인프라 노드에 테인트를 추가하는 경우 다른 워크로드의 테인트에 허용 오차를 추가해야 합니다(예: fluentd pod). 자세한 내용은 OpenShift 4의 Red Hat 지식베이스 솔루션 인프라 노드를 참조하십시오.

7.3. 인프라 노드 수동 생성

환경에서 Machine API가 지원되지 않는 경우에만 노드에 레이블을 직접 적용해야 합니다. 수동 생성을 수행하려면 OpenShift Data Foundation 서비스를 예약할 수 있고 이러한 노드에 충분한 CPU 및 메모리 리소스가 있어야 합니다. RHOCP 서브스크립션 비용을 방지하려면 다음이 필요합니다.

oc label node <node> node-role.kubernetes.io/infra=""
oc label node <node> cluster.ocs.openshift.io/openshift-storage=""

인프라 노드가 OpenShift Data Foundation 리소스만 스케줄링하고 OpenShift Data Foundation이 아닌 다른 워크로드의 재입력을 위해서는 NoSchedule OpenShift Data Foundation 테인트도 추가해야 합니다.

oc adm taint node <node> node.ocs.openshift.io/storage="true":NoSchedule
주의

node-role node-role.kubernetes.io/worker=""를 제거하지 마십시오.

node-role.kubernetes.io/worker="" 를 제거하면 OpenShift 스케줄러와 MachineConfig 리소스가 모두 변경되지 않는 한 문제가 발생할 수 있습니다.

이미 제거한 경우 각 인프라 노드에 다시 추가해야 합니다. node-role node-role.kubernetes.io/infra="" 및 OpenShift Data Foundation 테인트를 추가하면 인타이틀먼트 예외 요구 사항을 준수할 수 있습니다.

7.4. 사용자 인터페이스의 노드 테인트

이 섹션에서는 OpenShift Data Foundation 배포 후 노드를 테인트하는 절차를 설명합니다.

절차

  1. OpenShift 웹 콘솔에서 컴퓨팅노드를 클릭한 다음 테인트해야 하는 노드를 선택합니다.
  2. 세부 정보 페이지에서 테인트 편집 을 클릭합니다.
  3. Key <nodes.openshift.ocs.io/storage>, Value <true> 및 Effect<Noschedule> 필드에 값을 입력합니다.
  4. 저장을 클릭합니다.

검증 단계

  • 단계에 따라 노드가 성공적으로 테인트되었는지 확인합니다.

    • 컴퓨팅노드로 이동합니다.
    • 상태를 확인할 노드를 선택한 다음 YAML 탭을 클릭합니다.
    • specs 섹션에서 다음 매개변수의 값을 확인합니다.

      Taints:
        Key: nodes.openshift.ocs.io/storage
        Value: true
        Effect: Noschedule

추가 리소스

자세한 내용은 VMware vSphere에서 OpenShift Data Foundation 클러스터 생성을 참조하십시오.

8장. 영구 볼륨 클레임 관리

8.1. OpenShift Data Foundation을 사용하도록 애플리케이션 Pod 구성

이 섹션의 지침에 따라 OpenShift Data Foundation을 애플리케이션 포드에 대한 스토리지로 구성합니다.

사전 요구 사항

  • OpenShift 웹 콘솔에 대한 관리자 액세스 권한이 있습니다.
  • OpenShift Data Foundation Operator는 openshift-storage 네임스페이스에 설치 및 실행됩니다. OpenShift 웹 콘솔에서 Operator → 설치된 Operator 를 클릭하여 설치된 Operator 를 확인합니다.
  • OpenShift Data Foundation에서 제공하는 기본 스토리지 클래스를 사용할 수 있습니다. OpenShift 웹 콘솔에서 스토리지StorageClasses 를 클릭하여 기본 스토리지 클래스를 확인합니다.

절차

  1. 애플리케이션에서 사용할 PVC(영구 볼륨 클레임)를 생성합니다.

    1. OpenShift 웹 콘솔에서 스토리지영구 볼륨 클레임 을 클릭합니다.
    2. 애플리케이션 포드의 프로젝트를 설정합니다.
    3. 영구 볼륨 클레임 생성을 클릭합니다.

      1. OpenShift Data Foundation에서 제공하는 스토리지 클래스 를 지정합니다.
      2. PVC 이름 (예: myclaim )을 지정합니다.
      3. 필요한 액세스 모드를 선택합니다.

        참고

        IBM FlashSystem에서는 액세스 모드, 공유 액세스(RWX) 가 지원되지 않습니다.

      4. Rados Block Device(RBD)의 경우 액세스 모드가 ReadWriteOnce(RWO)인 경우 필요한 볼륨 모드를 선택합니다. 기본 볼륨 모드는 Filesystem 입니다.
      5. 애플리케이션 요구 사항에 따라 크기를 지정합니다.
      6. 생성을 클릭하고 PVC가 Bound 상태가 될 때까지 기다립니다.
  2. 새 PVC를 사용하도록 새 애플리케이션 Pod 또는 기존 애플리케이션 Pod를 구성합니다.

    • 새 애플리케이션 Pod의 경우 다음 단계를 수행합니다.

      1. 워크로드포드 를 클릭합니다.
      2. 새 애플리케이션 포드를 생성합니다.
      3. spec: 섹션에서 volumes: 섹션을 추가하여 애플리케이션 Pod의 볼륨으로 새 PVC를 추가합니다.

        volumes:
          - name: <volume_name>
            persistentVolumeClaim:
              claimName: <pvc_name>

        예를 들어 다음과 같습니다.

        volumes:
          - name: mypd
            persistentVolumeClaim:
              claimName: myclaim
    • 기존 애플리케이션 Pod의 경우 다음 단계를 수행합니다.

      1. 워크로드배포 구성을 클릭합니다.
      2. 애플리케이션 Pod와 관련된 필수 배포 구성을 검색합니다.
      3. 작업 메뉴(Cinder) → 배포 구성 편집 을 클릭합니다.
      4. spec: 섹션에서 volumes: 섹션을 추가하여 새 PVC를 애플리케이션 Pod의 볼륨으로 추가하고 저장 을 클릭합니다.

        volumes:
          - name: <volume_name>
            persistentVolumeClaim:
              claimName: <pvc_name>

        예를 들어 다음과 같습니다.

        volumes:
          - name: mypd
            persistentVolumeClaim:
              claimName: myclaim
  3. 새 구성이 사용되고 있는지 확인합니다.

    1. 워크로드포드 를 클릭합니다.
    2. 애플리케이션 포드의 프로젝트를 설정합니다.
    3. 애플리케이션 포드가 Running (실행 중) 상태로 표시되는지 확인합니다.
    4. 애플리케이션 포드 이름을 클릭하여 포드 세부 정보를 확인합니다.
    5. Volumes (볼륨) 섹션으로 스크롤하여 볼륨에 새 영구 볼륨 클레임과 일치하는 Type (예: myclaim )이 있는지 확인합니다.

8.2. 영구 볼륨 클레임 요청 상태 보기

PVC 요청 상태를 보려면 다음 절차를 사용하십시오.

사전 요구 사항

  • 관리자는 OpenShift Data Foundation에 액세스할 수 있습니다.

절차

  1. OpenShift 웹 콘솔에 로그인합니다.
  2. 스토리지영구 볼륨 클레임을 클릭합니다.
  3. 필터 텍스트 상자를 사용하여 필요한 PVC 이름을 검색합니다. 이름 또는 라벨로 PVC 목록을 필터링하여 목록을 좁힐 수 있습니다.
  4. 필요한 PVC에 해당하는 Status (상태) 열을 확인합니다.
  5. 필요한 이름을 클릭하여 PVC 세부 정보를 확인합니다.

8.3. 영구 볼륨 클레임 요청 이벤트 검토

이 절차를 사용하여 PVC(영구 볼륨 클레임) 요청 이벤트를 검토하고 처리합니다.

사전 요구 사항

  • OpenShift 웹 콘솔에 대한 관리자 액세스.

절차

  1. OpenShift 웹 콘솔에서 스토리지 → 데이터 생성을 클릭합니다.
  2. 스토리지 시스템 탭에서 스토리지 시스템을 선택한 다음 개요블록 및 파일 을 클릭합니다.
  3. 인벤토리 카드를 찾아 오류가 있는 PVC 수를 확인합니다.
  4. 스토리지영구 볼륨 클레임을 클릭합니다.
  5. 필터 텍스트 상자를 사용하여 필요한 PVC를 검색합니다.
  6. PVC 이름을 클릭하고 이벤트로이동합니다.
  7. 필요에 따라 또는 지시에 따라 이벤트를 처리합니다.

8.4. 영구 볼륨 클레임 확장

OpenShift Data Foundation 4.6부터는 영구 볼륨 클레임을 확장하여 영구 스토리지 리소스 관리 유연성을 높일 수 있습니다.

다음 영구 볼륨에 대해 확장이 지원됩니다.

  • 볼륨 모드 파일 시스템의 Ceph 파일 시스템(CephFS)을 기반으로 하는 ReadWriteOnce(RWO) 및 RWX(ReadWriteMany) 액세스 권한을 사용하는 PVC 입니다.
  • 볼륨 모드 파일 시스템이 있는 Ceph RADOS 블록 장치(RBD)를 기반으로 하는 ReadWriteOnce(RWO)가 있는 PVC입니다.
  • 볼륨 모드 블록 장치가 있는 Ceph RADOS 블록 장치(RBD)를 기반으로 하는 ReadWriteOnce(RWO)가 있는 PVC입니다.
참고

OSD, MON 및 암호화된 PVC에서 PVC 확장이 지원되지 않습니다.

사전 요구 사항

  • OpenShift 웹 콘솔에 대한 관리자 액세스.

절차

  1. OpenShift 웹 콘솔에서 스토리지영구 볼륨 클레임 으로 이동합니다.
  2. 확장할 영구 볼륨 클레임 옆에 있는 작업 메뉴(SAML)를 클릭합니다.
  3. Expand PVC 를 클릭합니다.

    영구 볼륨 클레임 확장 PVC 메뉴 항목
  4. 영구 볼륨 클레임의 새 크기를 선택한 다음 Expand:를 클릭합니다.

    영구 볼륨 클레임 마법사 확장
  5. 확장을 확인하려면 PVC의 세부 정보 페이지로 이동하여 Capacity 필드에 올바른 크기가 요청되었는지 확인합니다.

    참고

    Ceph RADOS Block Devices (RBD)를 기반으로 PVC를 확장할 때 PVC가 이미 Pod에 연결되어 있지 않은 경우 PVC의 세부 정보 페이지의 Condition 유형이 FileSystemResizePending 입니다. 볼륨이 마운트되면 파일 시스템의 크기가 성공하고 새 크기는 Capacity 필드에 반영됩니다.

8.5. 동적 프로비저닝

8.5.1. 동적 프로비저닝 소개

StorageClass 리소스 객체는 요청 가능한 스토리지를 설명하고 분류할 뿐 만 아니라 필요에 따라 동적으로 프로비저닝된 스토리지에 대한 매개 변수를 전달하는 수단을 제공합니다. StorageClass 객체는 다른 수준의 스토리지 및 스토리지에 대한 액세스를 제어하기 위한 관리 메커니즘으로 사용될 수 있습니다. 클러스터 관리자(cluster-admin) 또는 스토리지 관리자(storage-admin)는 사용자가 기본 스토리지 볼륨 소스에 대한 지식이 없어도 요청할 수 있는 StorageClass 오브젝트를 정의하고 만듭니다.

OpenShift Container Platform 영구 볼륨 프레임 워크를 사용하면이 기능을 사용할 수 있으며 관리자는 영구 스토리지로 클러스터를 프로비저닝할 수 있습니다. 또한 이 프레임 워크를 통해 사용자는 기본 인프라에 대한 지식이 없어도 해당 리소스를 요청할 수 있습니다.

OpenShift Container Platform에서 많은 스토리지 유형을 영구 볼륨으로 사용할 수 있습니다. 관리자가 이를 모두 정적으로 프로비저닝할 수 있지만 일부 스토리지 유형은 기본 제공자 및 플러그인 API를 사용하여 동적으로 만들 수 있습니다.

8.5.2. OpenShift Data Foundation에서 동적 프로비저닝

Red Hat OpenShift Data Foundation은 컨테이너 환경에 최적화된 소프트웨어 정의 스토리지입니다. OpenShift Container Platform에서 Operator로 실행되어 컨테이너에 고도로 통합되고 단순화된 영구 스토리지 관리 기능을 제공합니다.

OpenShift Data Foundation은 다음과 같은 다양한 스토리지 유형을 지원합니다.

  • 데이터베이스용 블록 스토리지
  • 지속적 통합, 메시징 및 데이터 집계를 위한 공유 파일 스토리지
  • 아카이브, 백업 및 미디어 스토리지를 위한 개체 스토리지

버전 4는 Red Hat Ceph Storage를 사용하여 영구 볼륨을 지원하는 파일, 블록 및 오브젝트 스토리지를 제공하고 Rook.io를 사용하여 영구 볼륨 및 클레임의 프로비저닝을 관리하고 오케스트레이션합니다. NooBaa는 오브젝트 스토리지를 제공하며, Multicloud Gateway는 여러 클라우드 환경(기술 프리뷰로 사용 가능)에서 오브젝트 통합을 허용합니다.

OpenShift Data Foundation 4에서 RADOS Block Device(RBD) 및 Ceph File System(CephFS)용 Red Hat Ceph Storage Interface(CSI) 드라이버는 동적 프로비저닝 요청을 처리합니다. PVC 요청이 동적으로 제공되는 경우 CSI 드라이버에는 다음 옵션이 있습니다.

  • 볼륨 모드 Block이 있는 Ceph RBD를 기반으로 ReadWriteOnce(RWO) 및 ReadWriteMany(RWX) 액세스를 사용하여 PVC를 생성합니다.
  • 볼륨 모드 파일시스템이 있는 Ceph RBD를 기반으로 ReadWriteOnce(ReadWriteOnce) 액세스를 사용하여 PVC 생성
  • 볼륨 모드 파일시스템의 CephFS를 기반으로 ReadWriteOnce(RWO) 및 ReadWriteMany(RWX) 액세스를 사용하여 PVC를 생성합니다.

사용할 드라이버 (RBD 또는 CephFS)에 대한 판단은 storageclass.yaml 파일의 항목을 기반으로 합니다.

8.5.3. 사용 가능한 동적 프로비저닝 플러그인

OpenShift Container Platform은 다음과 같은 프로비저너 플러그인을 제공합니다. 이에는 클러스터의 구성된 제공자 API를 사용하여 새 스토리지 리소스의 동적 프로비저닝을 위한 일반 구현이 포함되어 있습니다.

스토리지 유형프로비저너 플러그인 이름참고

OpenStack Cinder

kubernetes.io/cinder

 

AWS Elastic Block Store (EBS)

kubernetes.io/aws-ebs

다른 영역에서 여러 클러스터를 사용할 때 동적 프로비저닝의 경우 각 노드에 Key=kubernetes.io/cluster/<cluster_name>,Value=<cluster_id>로 태그를 지정합니다. 여기서 <cluster_name><cluster_id>는 클러스터마다 고유합니다.

AWS Elastic File System (EFS)

 

동적 프로비저닝은 EFS 프로비저너 Pod를 통해 수행되며 프로비저너 플러그인을 통해 수행되지 않습니다.

Azure Disk

kubernetes.io/azure-disk

 

Azure File

kubernetes.io/azure-file

persistent-volume-binder ServiceAccount에는 Azure 저장소 계정 및 키를 저장할 Secrets를 생성하고 검색할 수 있는 권한이 필요합니다.

GCE Persistent Disk (gcePD)

kubernetes.io/gce-pd

멀티 존 설정에서는 현재 클러스터에 노드가 없는 영역에서 PV가 생성되지 않도록 GCE 프로젝트 당 하나의 OpenShift Container Platform 클러스터를 실행하는 것이 좋습니다.

VMware vSphere

kubernetes.io/vsphere-volume

 

Red Hat Virtualization

csi.ovirt.org

 
중요

선택한 프로비저너 플러그인에는 관련 문서에 따라 클라우드, 호스트 또는 타사 공급자를 구성해야 합니다.

9장. 대상 볼륨에서 공간 회수

삭제된 파일 또는 제로 데이터 청크는 Ceph 클러스터에서 스토리지 공간을 차지하여 사용 가능한 스토리지 공간을 부정확하게 보고합니다. 회수 공간 작업은 대상 볼륨에서 다음 작업을 실행하여 이러한 불일치를 제거합니다.

  • fstrim - 이 작업은 파일 시스템 모드에 있는 볼륨에서 실행되며 회수 공간 작업을 실행할 때 볼륨이 Pod에 마운트된 경우에만 실행됩니다.
  • RBD Sparsify - 이 작업은 볼륨이 Pod에 연결되지 않은 경우 실행되고 4M 크기의 제로 크기의 청크로 사용되는 공간을 회수합니다.
참고
  • 회수 공간 작업은 Ceph RBD 볼륨에서만 지원됩니다.
  • 회수 공간 작업은 실행 시 성능 저하가 발생합니다.

업그레이드된 클러스터의 경우 계속 진행하기 전에 다음 명령을 실행합니다.

$ oc patch cm rook-ceph-operator-config -n openshift-storage -p $'data:\n "CSI_ENABLE_CSIADDONS": "true”'

다음 방법 중 하나를 사용하여 공간을 회수할 수 있습니다.

  • PersistentVolumeClaims 주석을 사용하여 회수 공간 작업 활성화( 회수 공간 작업을 활성화하는 데 사용할 권장 방법)
  • ReclaimSpaceJob을 사용하여 공간 회수 작업 활성화
  • ReclaimSpaceCronJob을 사용하여 공간 회수 작업 활성화

9.1. PersistentVolumeClaims 주석을 사용하여 공간 회수 활성화

지정된 일정에 따라 자동으로 회수 공간 작업을 호출할 수 있도록 PersistentVolumeClaims 에 주석을 달기 위해 이 절차를 사용합니다.

참고
  • schedule 값은 반복 작업 요청 및/또는 간격을 설정하는 Kubernetes CronJobs 와 동일한 형식입니다.
  • 권장 일정 간격은 @weekly 입니다. 일정 간격 값이 비어 있거나 유효하지 않은 형식의 경우 기본 일정 값은 @weekly 로 설정됩니다.
  • 예약된 각 작업 사이에 지원되는 최소 간격은 최소 24시간입니다. 예를 들어 @daily (하루 00:00시) 또는 0 3 * * * (매일 3:00)입니다.
  • off-peak, 유지 관리 창 또는 워크로드 입력/출력이 낮은 것으로 예상되는 간격 동안 ReclaimSpace 작업을 예약합니다.
  • 일정이 수정되면 ReclaimSpaceCronJob 이 다시 생성됩니다. 주석이 제거되면 자동으로 삭제됩니다.

절차

  1. PVC(영구 볼륨 클레임) 세부 정보를 가져옵니다.

    $ oc get pvc data-pvc
    NAME      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                          AGE
    data-pvc  Bound    pvc-f37b8582-4b04-4676-88dd-e1b95c6abf74   1Gi        RWO            ocs-storagecluster-ceph-rbd           20h
  2. reclaimspace.csiaddons.openshift.io/schedule=@monthly 주석을 PVC에 추가하여 reclaimspacecronjob 을 생성합니다.

    $ oc annotate pvc data-pvc "reclaimspace.csiaddons.openshift.io/schedule=@monthly"
    persistentvolumeclaim/data-pvc annotated
  3. reclaimspacecronjob"<pvc-name>-xxxxxxx" 형식으로 생성되었는지 확인합니다.

    $ oc get reclaimspacecronjobs.csiaddons.openshift.io
    NAME                    SCHEDULE    SUSPEND   ACTIVE   LASTSCHEDULE   AGE
    data-pvc-1642663516     @monthly                                      3s
  4. 이 작업을 자동으로 실행하도록 일정을 수정합니다.

    $ oc annotate pvc data-pvc "reclaimspace.csiaddons.openshift.io/schedule=@weekly" --overwrite=true
    persistentvolumeclaim/data-pvc annotated
  5. reclaimspacecronjob 의 일정이 수정되었는지 확인합니다.

    $ oc get reclaimspacecronjobs.csiaddons.openshift.io
    NAME                  SCHEDULE    SUSPEND   ACTIVE   LASTSCHEDULE   AGE
    data-pvc-1642664617   @weekly                                       3s

9.2. ReclaimSpaceJob을 사용하여 공간 회수 작업 활성화

ReclaimSpaceJob 은 대상 볼륨에서 회수 공간 작업을 호출하도록 설계된 네임스페이스가 지정된 CR(사용자 정의 리소스)입니다. 이는 회수 공간 작업을 즉시 시작하는 한 가지 방법입니다. 필요한 경우 회수 공간 작업을 반복하려면 ReclaimSpaceJob CR 생성을 반복해야 합니다.

참고
  • 회수 공간 작업 사이의 권장 간격은 weekly 입니다.
  • 각 작업 사이의 최소 간격이 24 시간 이상인지 확인합니다.
  • 외부 사용, 유지 관리 창 또는 워크로드 입력/출력이 낮은 것으로 예상되는 경우 회수 공간 작업을 예약합니다.

절차

  1. 공간 회수 작업을 위해 다음 사용자 정의 리소스를 생성하고 적용합니다.

    apiVersion: csiaddons.openshift.io/v1alpha1
    kind: ReclaimSpaceJob
    metadata:
      name: sample-1
    spec:
      target:
        persistentVolumeClaim: pvc-1

    여기서,

    target
    작업이 수행되는 볼륨 대상을 나타냅니다.
    persistentVolumeClaim
    PersistentVolumeClaim 의 이름입니다.
    backOfflimit
    회수 공간 작업을 실패로 표시하기 전에 최대 재시도 횟수를 지정합니다. 기본값은 6 입니다. 허용되는 최대 및 최소값은 각각 600 입니다.
    retryDeadlineSeconds
    작업이 초 단위로 간주될 수 있고 시작 시간을 기준으로 하는 기간을 지정합니다. 값은 양의 정수여야 합니다. 기본값은 600 초이고 허용되는 최대값은 1800 초입니다.
  2. 작업이 완료된 후 사용자 정의 리소스를 삭제합니다.

9.3. ReclaimSpaceCronJob을 사용하여 공간 회수 작업 활성화

ReclaimSpaceCronJob 은 매일, weekly 등과 같은 지정된 일정에 따라 회수 공간 작업을 호출합니다. 영구 볼륨 클레임에 대해 ReclaimSpaceCronJob 을 한 번만 생성해야 합니다. CSI-addons 컨트롤러는 요청된 시간 및 schedule 속성이 있는 간격에 ReclaimSpaceJob 을 생성합니다.

참고
  • 권장 일정 간격은 @weekly 입니다.
  • 예약된 각 작업 사이의 최소 간격은 최소 24시간 이상이어야 합니다. 예를 들어 @daily (하루 00:00시) 또는 "0 3 * *"(매일 3:00)입니다.
  • off-peak, 유지 관리 창 또는 워크로드 입력/출력이 낮은 것으로 예상되는 간격 동안 ReclaimSpace 작업을 예약합니다.

절차

  1. 공간 회수 작업을 위해 다음 사용자 정의 리소스를 만들고 적용합니다.

    apiVersion: csiaddons.openshift.io/v1alpha1
    kind: ReclaimSpaceCronJob
    metadata:
      name: reclaimspacecronjob-sample
    spec:
      jobTemplate:
        spec:
          target:
            persistentVolumeClaim: data-pvc
      schedule: '@weekly'
      concurrencyPolicy: Forbid

    여기서,

    concurrencyPolicy
    이전 ReclaimSpaceJob 이 계속 실행되는 동안 ReclaimSpaceCronJob 에서 새 ReclaimSpaceJob 을 예약할 때 변경 사항을 설명합니다. 기본 Forbid 는 새 작업을 시작하는 것을 방지하지만 Replace 는 실패 상태에서 실행 중인 작업을 삭제하고 새 작업을 생성하는 데 사용할 수 있습니다.
    failedJobsHistoryLimit
    문제 해결을 위해 보관된 실패한 ReclaimSpaceJobs 수를 지정합니다.
    jobTemplate
    요청된 ReclaimSpaceJob 작업의 세부 정보를 설명하는 ReclaimSpaceJob.spec 구조를 지정합니다.
    successfulJobsHistoryLimit
    성공적인 ReclaimSpaceJob 작업 수를 지정합니다.
    스케줄
    반복 작업 요청의 및/또는 간격을 지정하고 Kubernetes CronJobs 와 동일한 형식으로 지정합니다.
  2. 회수 공간 작업의 실행이 더 이상 필요하지 않거나 대상 PVC가 삭제될 때 ReclaimSpaceCronJob 사용자 정의 리소스를 삭제합니다.

10장. 볼륨 스냅샷

볼륨 스냅샷은 특정 시점에서 클러스터의 스토리지 볼륨 상태입니다. 이러한 스냅샷을 사용하면 매번 전체 복사를 수행하지 않고도 스토리지를 보다 효율적으로 사용할 수 있으며 애플리케이션 개발을 위한 빌딩 블록으로 사용할 수 있습니다.

관리자는 볼륨 스냅샷 클래스를 사용하여 볼륨 스냅샷 오브젝트에 속하는 다른 속성을 지정할 수 있습니다. OpenShift Data Foundation Operator는 사용 중인 플랫폼에 따라 기본 볼륨 스냅샷 클래스를 설치합니다. Operator는 이러한 기본 볼륨 스냅샷 클래스를 소유하고 제어하며 삭제하거나 수정할 수 없습니다.

동일한 PVC(영구 볼륨 클레임)의 여러 스냅샷을 생성할 수 있지만 스냅샷의 정기적인 생성을 예약할 수 없습니다.

  • CephFS의 경우 PVC당 최대 100개의 스냅샷을 생성할 수 있습니다.
  • RADOS 블록 장치(RBD)의 경우 PVC당 최대 512개의 스냅샷을 생성할 수 있습니다.
참고

이제 영구 볼륨 암호화에서 볼륨 스냅샷을 지원합니다.

10.1. 볼륨 스냅샷 생성

PVC(영구 볼륨 클레임) 페이지 또는 볼륨 스냅샷 페이지에서 볼륨 스냅샷을 생성할 수 있습니다.

사전 요구 사항

  • 일관된 스냅샷의 경우 PVC는 Bound 상태에 있고 사용하지 않아야 합니다. 스냅샷을 생성하기 전에 모든 IO를 중지하십시오.
참고

OpenShift Data Foundation은 Pod에서 PVC를 사용하는 경우에만 PVC의 볼륨 스냅샷에 대한 크래시 일관성을 제공합니다. 애플리케이션 일관성을 위해서는 먼저 실행 중인 포드를 종료하여 일관된 스냅샷을 유지하거나 애플리케이션에서 제공하는 모든 quiesce 메커니즘을 사용하여 이를 보장할 수 있습니다.

절차

영구 볼륨 클레임 페이지에서
  1. OpenShift 웹 콘솔에서 스토리지영구 볼륨 클레임 을 클릭합니다.
  2. 볼륨 스냅샷을 생성하려면 다음 중 하나를 수행합니다.

    • 원하는 PVC 옆에 있는 작업 메뉴 (작업 메뉴)스냅샷 생성을 클릭합니다.
    • 스냅샷을 생성할 PVC를 클릭하고 작업스냅샷 생성을 클릭합니다.
  3. 볼륨 스냅샷 의 이름을 입력합니다.
  4. 드롭다운 목록에서 Snapshot Class 를 선택합니다.
  5. 생성을 클릭합니다. 생성된 볼륨 스냅샷의 세부 정보 페이지로 리디렉션됩니다.
볼륨 스냅샷 페이지에서
  1. OpenShift 웹 콘솔에서 스토리지볼륨 스냅샷 을 클릭합니다.
  2. Volume Snapshots (볼륨 스냅샷) 페이지에서 Create Volume Snapshot (볼륨 스냅샷 만들기)을 클릭합니다.
  3. 드롭다운 목록에서 필요한 프로젝트를 선택합니다.
  4. 드롭다운 목록에서 영구 볼륨 클레임 을 선택합니다.
  5. 스냅샷의 이름을 입력합니다.
  6. 드롭다운 목록에서 Snapshot Class 를 선택합니다.
  7. 생성을 클릭합니다. 생성된 볼륨 스냅샷의 세부 정보 페이지로 리디렉션됩니다.

검증 단계

  • PVC의 세부 정보 페이지로 이동하고 Volume Snapshots 탭을 클릭하여 볼륨 스냅샷 목록을 확인합니다. 새 볼륨 스냅샷이 나열되는지 확인합니다.
  • OpenShift 웹 콘솔에서 스토리지볼륨 스냅샷 을 클릭합니다. 새 볼륨 스냅샷이 나열되는지 확인합니다.
  • 볼륨 스냅샷이 Ready 상태가 될 때까지 기다립니다.

10.2. 볼륨 스냅샷 복원

볼륨 스냅샷을 복원하면 새 PVC(영구 볼륨 클레임)가 생성됩니다. 복원된 PVC는 볼륨 스냅샷 및 상위 PVC와 독립적입니다.

영구 볼륨 클레임 페이지 또는 Volume Snapshots 페이지에서 볼륨 스냅샷을 복원할 수 있습니다.

절차

영구 볼륨 클레임 페이지에서

상위 PVC가 있는 경우에만 영구 볼륨 클레임 페이지에서 볼륨 스냅샷을 복원할 수 있습니다.

  1. OpenShift 웹 콘솔에서 스토리지영구 볼륨 클레임 을 클릭합니다.
  2. 볼륨 스냅샷과 함께 PVC 이름을 클릭하여 새 PVC로 볼륨 스냅샷을 복원합니다.
  3. Volume Snapshots (볼륨 스냅샷) 탭에서 복원할 볼륨 스냅샷 옆에 있는 Action(작업) 메뉴를 클릭합니다.
  4. 새 PVC로 복원을 클릭합니다.
  5. 새 PVC의 이름을 입력합니다.
  6. 스토리지 클래스 이름을 선택합니다.

    참고

    Rados Block Device(RBD)의 경우 상위 PVC와 동일한 풀의 스토리지 클래스를 선택해야 합니다. 암호화가 활성화되지 않은 스토리지 클래스를 사용하여 암호화된 PVC의 스냅샷을 복원하는 것은 지원되지 않습니다.

  7. 선택한 액세스 모드를 선택합니다.

    중요

    ReadOnlyMany(ROX) 액세스 모드는 개발자 프리뷰 기능이며 개발자 프리뷰 지원 제한 사항이 적용됩니다. 개발자 프리뷰 릴리스는 프로덕션 환경에서 실행할 수 없으며 Red Hat 고객 포털 케이스 관리 시스템을 통해 지원되지 않습니다. ReadOnlyMany 기능에 대한 지원이 필요한 경우 ocs-devpreview@redhat.com 메일링 목록에 연락하여 Red Hat 개발 팀의 멤버는 가용성 및 작업 일정을 기반으로 최대한 신속하게 지원합니다. ROX 액세스 모드를 사용하려면 복제본 생성 또는 새 읽기 전용 액세스 모드로 스냅샷 복원 을 참조하십시오.

  8. 선택 사항: RBD의 경우 볼륨 모드를 선택합니다.
  9. Restore 을 클릭합니다. 새 PVC 세부 정보 페이지로 리디렉션됩니다.
볼륨 스냅샷 페이지에서
  1. OpenShift 웹 콘솔에서 스토리지볼륨 스냅샷 을 클릭합니다.
  2. Volume Snapshots (볼륨 스냅샷) 탭에서 복원할 볼륨 스냅샷 옆에 있는 Action(작업) 메뉴를 클릭합니다.
  3. 새 PVC로 복원을 클릭합니다.
  4. 새 PVC의 이름을 입력합니다.
  5. 스토리지 클래스 이름을 선택합니다.

    참고

    Rados Block Device(RBD)의 경우 상위 PVC와 동일한 풀의 스토리지 클래스를 선택해야 합니다. 암호화가 활성화되지 않은 스토리지 클래스를 사용하여 암호화된 PVC의 스냅샷을 복원하는 것은 지원되지 않습니다.

  6. 선택한 액세스 모드를 선택합니다.

    중요

    ReadOnlyMany(ROX) 액세스 모드는 개발자 프리뷰 기능이며 개발자 프리뷰 지원 제한 사항이 적용됩니다. 개발자 프리뷰 릴리스는 프로덕션 환경에서 실행할 수 없으며 Red Hat 고객 포털 케이스 관리 시스템을 통해 지원되지 않습니다. ReadOnlyMany 기능에 대한 지원이 필요한 경우 ocs-devpreview@redhat.com 메일링 목록에 연락하여 Red Hat 개발 팀의 멤버는 가용성 및 작업 일정을 기반으로 최대한 신속하게 지원합니다. ROX 액세스 모드를 사용하려면 복제본 생성 또는 새 읽기 전용 액세스 모드로 스냅샷 복원 을 참조하십시오.

  7. 선택 사항: RBD의 경우 볼륨 모드를 선택합니다.
  8. Restore 을 클릭합니다. 새 PVC 세부 정보 페이지로 리디렉션됩니다.

검증 단계

  • OpenShift 웹 콘솔에서 스토리지영구 볼륨 클레임 을 클릭하고 새 PVC가 영구 볼륨 클레임 페이지에 나열되어 있는지 확인합니다.
  • 새 PVC가 Bound 상태에 도달할 때까지 기다립니다.

10.3. 볼륨 스냅샷 삭제

사전 요구 사항

  • 볼륨 스냅샷을 삭제하기 위해 특정 볼륨 스냅샷에 사용되는 볼륨 스냅샷 클래스가 있어야 합니다.

절차

영구 볼륨 클레임 페이지에서
  1. OpenShift 웹 콘솔에서 스토리지영구 볼륨 클레임 을 클릭합니다.
  2. 삭제해야 하는 볼륨 스냅샷이 있는 PVC 이름을 클릭합니다.
  3. Volume Snapshots (볼륨 스냅샷) 탭에서 원하는 볼륨 스냅샷 옆에 있는 작업 메뉴 (Cinder)Volume Snapshot 삭제를 클릭합니다.
볼륨 스냅샷 페이지에서
  1. OpenShift 웹 콘솔에서 스토리지볼륨 스냅샷 을 클릭합니다.
  2. Volume Snapshots (볼륨 스냅샷) 페이지에서 원하는 볼륨 스냅샷 옆에 있는 작업 메뉴 (Cinder) → Delete Volume Snapshot (볼륨 스냅샷 삭제) 을 클릭합니다.

검증 단계

  • 삭제된 볼륨 스냅샷이 PVC 세부 정보 페이지의 Volume Snapshots (볼륨 스냅샷) 탭에 없는지 확인합니다.
  • 스토리지볼륨 스냅샷 을 클릭하고 삭제된 볼륨 스냅샷이 나열되지 않도록 합니다.

11장. 볼륨 복제

복제본은 모든 표준 볼륨으로 사용되는 기존 스토리지 볼륨의 중복입니다. 볼륨 복제본을 생성하여 데이터 복사본을 시간 복사합니다. PVC(영구 볼륨 클레임)는 다른 크기로 복제할 수 없습니다. CephFS 및 RADOS 블록 장치(RBD) 모두에 대해 PVC당 최대 512개의 복제본을 생성할 수 있습니다.

11.1. 복제본 생성

사전 요구 사항

  • 소스 PVC는 Bound 상태에 있어야 하며 사용하지 않아야 합니다.
참고

Pod가 이를 사용하는 경우 PVC 복제본을 생성하지 마십시오. 그러면 PVC가 quiesced(일시 중지됨)되지 않기 때문에 데이터 손상이 발생할 수 있습니다.

절차

  1. OpenShift 웹 콘솔에서 스토리지영구 볼륨 클레임 을 클릭합니다.
  2. 복제본을 생성하려면 다음 중 하나를 수행합니다.

    • 원하는 PVC 옆에 있는 작업 메뉴 (SAML) → Clone PVC 를 클릭합니다.
    • 복제할 PVC를 클릭하고 작업PVC 복제 를 클릭합니다.
  3. 복제의 이름을 입력합니다.
  4. 선택한 액세스 모드를 선택합니다.

    중요

    ReadOnlyMany(ROX) 액세스 모드는 개발자 프리뷰 기능이며 개발자 프리뷰 지원 제한 사항이 적용됩니다. 개발자 프리뷰 릴리스는 프로덕션 환경에서 실행할 수 없으며 Red Hat 고객 포털 케이스 관리 시스템을 통해 지원되지 않습니다. ReadOnlyMany 기능에 대한 지원이 필요한 경우 ocs-devpreview@redhat.com 메일링 목록에 연락하여 Red Hat 개발 팀의 멤버는 가용성 및 작업 일정을 기반으로 최대한 신속하게 지원합니다. ROX 액세스 모드를 사용하려면 복제본 생성 또는 새 읽기 전용 액세스 모드로 스냅샷 복원 을 참조하십시오.

  5. Clone (복제)을 클릭합니다. 새 PVC 세부 정보 페이지로 리디렉션됩니다.
  6. 복제된 PVC 상태가 Bound 가 될 때까지 기다립니다.

    이제 Pod에서 복제된 PVC를 사용할 수 있습니다. 이 복제된 PVC는 dataSource PVC와 독립적입니다.

12장. CSI(Container Storage Interface) 구성 요소 배치 관리

각 클러스터는 infrastorage 노드와 같은 다수의 전용 노드로 구성됩니다. 그러나 사용자 정의 테인트가 있는 인프라 노드는 노드에서 OpenShift Data Foundation 영구 볼륨 클레임(PVC)을 사용할 수 없습니다. 따라서 이러한 노드를 사용하려면 허용 오차를 설정하여 노드에서 csi-plugins 를 가져올 수 있습니다. 자세한 내용은 https://access.redhat.com/solutions/4827161 을 참조하십시오.

절차

  1. configmap을 편집하여 사용자 정의 테인트에 대한 허용 오차를 추가합니다. 편집기를 종료하기 전에 저장하셔야 합니다.

    $ oc edit configmap rook-ceph-operator-config -n openshift-storage
  2. configmap 을 표시하여 추가된 톨러레이션을 확인합니다.

    $ oc get configmap rook-ceph-operator-config -n openshift-storage -o yaml

    테인트, nodetype=infra:NoSchedule 에 추가된 허용 오차의 출력 예:

    apiVersion: v1
    data:
    [...]
      CSI_PLUGIN_TOLERATIONS: |
        - key: nodetype
          operator: Equal
          value: infra
          effect: NoSchedule
        - key: node.ocs.openshift.io/storage
          operator: Equal
          value: "true"
          effect: NoSchedule
    [...]
    kind: ConfigMap
    metadata:
    [...]
    참고

    Tolerations 값 필드에 있는 문자열이 아닌 모든 값에 이중 따옴표가 있는지 확인합니다. 예를 들어 true 유형의 부울인 값 true 및 int 유형의 1 은 "true" 및 "1"로 입력되어야 합니다.

  3. csi-cephfsplugin-* 및 csi-rbdplugin-* Pod가 인프라 노드에서 자체적으로 시작되지 않으면 rook-ceph-operator 를 다시 시작합니다.

    $ oc delete -n openshift-storage pod <name of the rook_ceph_operator pod>

    예:

    $ oc delete -n openshift-storage pod rook-ceph-operator-5446f9b95b-jrn2j
    
    pod "rook-ceph-operator-5446f9b95b-jrn2j" deleted

검증 단계

csi-cephfsplugin-* 및 csi-rbdplugin-* Pod가 인프라 노드에서 실행 중인지 확인합니다.

13장. NFS를 사용하여 내보내기 생성 [기술 프리뷰]

이 섹션에서는 OpenShift 클러스터에서 외부에서 액세스할 수 있는 NFS를 사용하여 내보내기를 생성하는 방법을 설명합니다.

중요

NFS를 사용하여 내보내기를 생성하는 것은 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

다음 지침에 따라 OpenShift 클러스터에서 내보내기를 생성하고 외부에서 액세스합니다.

13.1. NFS 기능 활성화

NFS 기능을 사용하려면 클러스터에서 활성화해야 합니다.

사전 요구 사항

  • OpenShift Data Foundation은 openshift-storage 네임스페이스에 설치되고 실행됩니다.
  • OpenShift Data Foundation 설치에는 CephFilesystem이 포함됩니다.

절차

다음 명령을 실행하여 NFS 기능을 활성화합니다.

$ oc --namespace openshift-storage patch storageclusters.ocs.openshift.io ocs-storagecluster --type merge --patch '{"spec": {"nfs":{"enable": true}}}'
$ oc  --namespace openshift-storage patch configmap rook-ceph-operator-config --type merge --patch '{"data":{"ROOK_CSI_ENABLE_NFS": "true"}}'

검증 단계

다음 조건이 충족되면 NFS 설치 및 구성이 완료됩니다.

  • ocs-storagecluster-cephnfs 라는 CephNFS 리소스는 Ready 상태가 됩니다.
  • 모든 csi-nfsplugin-* Pod가 실행 중인지 확인합니다.

    oc -n openshift-storage describe cephnfs ocs-storagecluster-cephnfs
    oc -n openshift-storage get pod | grep csi-nfsplugin

    출력은 여러 포드가 됩니다. 예를 들어 다음과 같습니다.

    csi-nfsplugin-47qwq                                          2/2     Running  0  10s
    csi-nfsplugin-77947                                          2/2     Running  0  10s
    csi-nfsplugin-ct2pm                                          2/2     Running  0  10s
    csi-nfsplugin-provisioner-f85b75fbb-2rm2w                    2/2     Running  0  10s
    csi-nfsplugin-provisioner-f85b75fbb-8nj5h                    2/2     Running  0  10s

13.2. NFS 내보내기 생성

NFS 내보내기는 ocs-storagecluster-ceph-nfs StorageClass에 대해 PVC(영구 볼륨 클레임)를 생성하여 생성합니다.

NFS PVC는 다음 두 가지 방법으로 생성할 수 있습니다.

yaml을 사용하여 NFS PVC를 생성합니다.

다음은 PVC 예제입니다.

참고

volumeMode: Block 은 NFS 볼륨에서 작동하지 않습니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: <desired_name>
spec:
 accessModes:
   - ReadWriteOnce
 resources:
   requests:
     storage: 1Gi
 storageClassName: ocs-storagecluster-ceph-nfs
<desired_name>
PVC의 이름을 지정합니다(예: my-nfs-export ).

PVC가 Bound 상태에 도달하면 내보내기가 생성됩니다.

OpenShift Container Platform 웹 콘솔에서 NFS PVC를 생성합니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 로그인한 후 스토리지 클러스터에 NFS 기능이 활성화되어 있는지 확인합니다.

절차

  1. OpenShift 웹 콘솔에서 스토리지영구 볼륨 클레임을 클릭합니다.
  2. 프로젝트를 openshift-storage 로 설정합니다.
  3. PersistentVolumeClaim 생성을 클릭합니다.

    1. 스토리지 클래스,ocs-storagecluster-ceph-nfs 를 지정합니다.
    2. PVC 이름을 지정합니다( 예: my-nfs-export ).
    3. 필요한 액세스 모드를 선택합니다.
    4. 애플리케이션 요구 사항에 따라 크기를 지정합니다.
    5. 파일 시스템으로 볼륨 모드를 선택합니다.

      참고: NFS PVC에서는 블록 모드가 지원되지 않습니다.

    6. 생성을 클릭하고 PVC가 Bound 상태가 될 때까지 기다립니다.

13.3. 클러스터에서 NFS 내보내기 사용

Kubernetes 애플리케이션 pod는 이전에 생성된 PVC를 마운트하여 생성된 NFS 내보내기를 사용할 수 있습니다.

두 가지 방법 중 PVC를 마운트할 수 있습니다.

YAML 사용:

다음은 13.2절. “NFS 내보내기 생성” 에서 생성된 예제 PVC를 사용하는 Pod의 예입니다.

apiVersion: v1
kind: Pod
metadata:
 name: nfs-export-example
spec:
 containers:
   - name: web-server
     image: nginx
     volumeMounts:
       - name: nfs-export-pvc
         mountPath: /var/lib/www/html
 volumes:
   - name: nfs-export-pvc
     persistentVolumeClaim:
       claimName: <pvc_name>
       readOnly: false
<pvc_name>
이전에 생성한 PVC를 지정합니다(예: my-nfs-export ).

OpenShift Container Platform 웹 콘솔 사용.

절차

  1. OpenShift Container Platform 웹 콘솔에서 워크로드Pod 로 이동합니다.
  2. Pod 생성을 클릭하여 새 애플리케이션 포드를 생성합니다.
  3. metadata 섹션에서 이름을 추가합니다. 예를 들어 네임스페이스openshift-storagenfs-export-example 입니다.
  4. spec: 섹션에서 imagevolumeMounts 섹션이 포함된 containers: 섹션을 추가합니다.

    apiVersion: v1
    kind: Pod
    metadata:
     name: nfs-export-example
     namespace: openshift-storage
    spec:
     containers:
       - name: web-server
         image: nginx
         volumeMounts:
           - name: <volume_name>
             mountPath: /var/lib/www/html

    예를 들어 다음과 같습니다.

    apiVersion: v1
    kind: Pod
    metadata:
     name: nfs-export-example
     namespace: openshift-storage
    spec:
     containers:
       - name: web-server
         image: nginx
         volumeMounts:
           - name: nfs-export-pvc
             mountPath: /var/lib/www/html
  5. spec: 섹션에서 volumes: 섹션을 추가하여 애플리케이션 Pod의 볼륨으로 NFS PVC를 추가합니다.

    volumes:
      - name: <volume_name>
        persistentVolumeClaim:
          claimName: <pvc_name>

    예를 들어 다음과 같습니다.

    volumes:
      - name: nfs-export-pvc
        persistentVolumeClaim:
          claimName: my-nfs-export

13.4. OpenShift 클러스터에서 NFS 내보내기 사용

OpenShift 클러스터 외부의 NFS 클라이언트는 이전에 생성된 PVC로 생성된 NFS 내보내기를 마운트할 수 있습니다.

절차

  1. nfs 플래그가 활성화되면 Rook에서 singe-server CephNFS를 배포합니다. 다음 단계에서 사용할 nfs-ganesha 서버의 ceph_nfs 필드 값을 가져와야 합니다.

    $ oc get pods -n openshift-storage | grep rook-ceph-nfs
    $ oc describe pod  <name of the rook-ceph-nfs pod> | grep ceph_nfs

    예를 들어 다음과 같습니다.

    $ oc describe pod rook-ceph-nfs-ocs-storagecluster-cephnfs-a-7bb484b4bf-bbdhs | grep ceph_nfs
      ceph_nfs=my-nfs
  2. Kubernetes LoadBalancer Service를 생성하여 OpenShift 클러스터 외부에 NFS 서버를 노출합니다. 아래 예제에서는 LoadBalancer 서비스를 생성하고 OpenShift Data Foundation에서 생성한 NFS 서버를 참조합니다.

    apiVersion: v1
    kind: Service
    metadata:
     name: rook-ceph-nfs-ocs-storagecluster-cephnfs-load-balancer
     namespace: openshift-storage
    spec:
     ports:
       - name: nfs
         port: 2049
     type: LoadBalancer
     externalTrafficPolicy: Local
     selector:
       app: rook-ceph-nfs
       ceph_nfs: <my-nfs>
       instance: a

    & lt;my-nfs& gt;를 1단계에서 얻은 값으로 바꿉니다.

  3. 연결 정보를 수집합니다. 외부 클라이언트가 내보내기에 연결해야 하는 정보는 PVC에 대해 생성된 영구 볼륨(PV)에서 가져오고 이전 단계에서 생성한 LoadBalancer 서비스의 상태입니다.

    1. PV에서 공유 경로를 가져옵니다.

      1. NFS 내보내기의 PVC와 연결된 PV 이름을 가져옵니다.

        $ oc get pvc <pvc_name> --output jsonpath='{.spec.volumeName}'
        pvc-39c5c467-d9d3-4898-84f7-936ea52fd99d

        & lt;pvc_name& gt;을 자체 PVC 이름으로 바꿉니다. 예를 들어 다음과 같습니다.

        oc get pvc pvc-39c5c467-d9d3-4898-84f7-936ea52fd99d --output jsonpath='{.spec.volumeName}'
        pvc-39c5c467-d9d3-4898-84f7-936ea52fd99d
      2. 이전에 가져온 PV 이름을 사용하여 NFS 내보내기의 공유 경로를 가져옵니다.

        $ oc get pv pvc-39c5c467-d9d3-4898-84f7-936ea52fd99d --output jsonpath='{.spec.csi.volumeAttributes.share}'
        /0001-0011-openshift-storage-0000000000000001-ba9426ab-d61b-11ec-9ffd-0a580a800215
    2. NFS 서버의 수신 주소를 가져옵니다. 서비스의 수신 상태에는 여러 주소가 있을 수 있습니다. 외부 고객에게 사용하고자 하는 것을 선택합니다. 아래 예제에서는 호스트 이름 ingress-id.somedomain.com 이라는 단일 주소만 있습니다.

      $ oc -n openshift-storage get service rook-ceph-nfs-ocs-storagecluster-cephnfs-load-balancer --output jsonpath='{.status.loadBalancer.ingress}'
      [{"hostname":"ingress-id.somedomain.com"}]
  4. 이전 단계의 공유 경로 및 수신 주소를 사용하여 외부 클라이언트를 연결합니다. 다음 예제에서는 클라이언트의 디렉토리 경로 /export/mount/path 에 내보내기를 마운트합니다.

    $ mount -t nfs4 -o proto=tcp ingress-id.somedomain.com:/0001-0011-openshift-storage-0000000000000001-ba9426ab-d61b-11ec-9ffd-0a580a800215 /export/mount/path

    이 작업이 즉시 작동하지 않으면 NFS 서버로 수신할 수 있도록 네트워크 리소스를 구성하는 데 여전히 Kubernetes 환경이 시간이 걸릴 수 있습니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.