재해 복구에 대한 구성

이 솔루션 플레이북과 함께 제공되는 스크립트를 사용하여 기본 Kubernetes 클러스터에서 YAML 스냅샷을 생성하고 다른(보조) Kubernetes 클러스터에서 복원할 수 있습니다. YAML 스냅샷을 구성하기 위해 스크립트를 다운로드하고 사용하기 전에 구성을 계획하고 요구 사항을 이해하는 것이 중요합니다.

주:

이 솔루션은 제어 계획 및 작업자 노드를 포함한 Kubernetes 클러스터가 이미 존재한다고 가정합니다.

구성 계획

기본 시스템을 기반으로 보조 시스템에서 리소스 및 구성을 계획합니다. 이 스크립트는 두 Kubernetes 클러스터가 이미 존재해야 합니다. 두 클러스터에 대해 명령을 실행하려면 Kubernetes 명령행 도구 kubectl를 사용하여 두 클러스터에 액세스할 수 있어야 합니다.

주:

이 솔루션은 제어 계획 및 작업자 노드를 포함한 Kubernetes 클러스터가 이미 존재한다고 가정합니다. 이 플레이북에 제공된 권장 사항 및 스크립트는 리소스, 제어 플레인 또는 작업자 노드 구성을 확인하지 않습니다.

다음 다이어그램은 구성된 경우 완전히 다른 Kubernetes 클러스터에서 아티팩트 스냅샷을 복원할 수 있음을 보여줍니다.

그림 kube-api-dr.png에 대한 설명

구성을 계획할 때 Restore에 대해 다음 요구 사항을 완료합니다.

1. 1차의 필수 워커 노드 및 리소스가 2차에서 사용 가능한지 확인합니다.
   여기에는 POD의 공유 스토리지 마운트, 로드 밸런서 및 데이터베이스가 포함됩니다. 또한 복원 중인 이름 공간에서 사용되는 모든 외부 시스템을 포함합니다.
2. 스크립트를 실행하기 전에 관련된 네임스페이스에서 사용되는 필수 영구 볼륨을 수동으로 만듭니다.

   이는 기본 작업입니다. 스크립트는 기본 볼륨에 사용된 영구 볼륨 클레임을 생성합니다. 그러나 지속 볼륨이 서로 다른 네임스페이스의 여러 클레임에서 공유될 수 있으므로 자동화 스크립트는 extract-apply 스크립트를 실행하기 전에 보조 클러스터에서 지속 볼륨을 수동으로 만들어야 합니다.

   또는 maak8DR-apply.env 파일의 nons_artifacts_types 변수에 pv를 추가할 수 있습니다(즉, export nons_artifacts_types="crd clusterrole clusterrolebinding pv 사용). 이렇게 하면 스크립트에서 보조 볼륨에도 지속 볼륨을 만들도록 지시합니다. 이 두 번째 경우 다른 영구적 볼륨 클레임과 충돌이 발생할 수 있는지 여부를 결정해야 합니다.

3. 보조 클러스터가 복제 중인 네임스페이스에서 사용하는 컨테이너 이미지에 대한 적절한 액세스 권한을 가지는지 확인합니다.
   • 복제할 네임스페이스에 있는 컨테이너 레지스트리에 액세스하는 데 사용되는 암호는 이 플레이북과 함께 제공된 스크립트에 의해 복사됩니다. 레지스트리에 대한 인증서가 다른 네임스페이스에 저장된 경우 보조에서 수동으로 생성해야 합니다. 또는 암호가 YAML 스냅샷에도 포함되도록 인증서에 레이블을 maak8sapply: my_ns(여기서 my_ns는 복원 중인 이름 공간임)로 지정할 수 있습니다. 예제

     kubectl label secret regcredfra -n other_namespace 
     maak8sapply=namespace_being_backedup

   • 기본 워커 노드에 수동으로 로드된 이미지를 사용하는 경우 보조 워커 노드에도 수동으로 로드해야 합니다.

     주:

     제공된 스크립트는 복제하려는 네임스페이스에 사용된 이미지를 보고합니다.
4. 각 클러스터의 Kube API 끝점에 대해 kubectl 작업을 실행할 수 있는 배스천 노드를 통해 기본 및 보조 클러스터에 대한 액세스 권한을 제공합니다.
   ssh 또는 scp를 둘 다(기본 및 대기)에 사용하고 DR 동기화를 조정할 수 있는 세번째 노드를 사용할 수 있습니다. 그러나 불필요한 홉 및 세션 오버헤드를 방지하기 위해 Oracle은 기본 배스천을 DR 조정자로 사용할 것을 권장합니다. 다른 옵션을 사용하려면 제공된 스크립트를 사용자 정의해야 합니다.
5. my_ns namespace를 복원할 때 백업에 포함된 이름 없는 리소스가 보조에 적용되도록 하려면 maak8sapply: my_ns 레이블을 사용합니다.

   클러스터의 루트에 상주하는 아티팩트(즉, 정확한 네임스페이스의 일부가 아님)의 경우 스크립트는 네임스페이스 이름이 포함된 namespace: 및 group: 필드 참조를 찾습니다. 백업에 포함된 이름 없는 다른 리소스가 필요한 경우 추가할 레이블을 지정할 수 있습니다.

   예를 들어, domains.weblogic.oracle 사용자 정의 리소스 정의는 이름 공간의 일부가 아니지만 다음을 사용하여 apply 작업 레이블 지정에 포함할 수 있습니다. kubectl label crd domains.weblogic.oracle maak8sapply=opns.

구성

YAML 스냅샷 재해 복구를 구성합니다.

1. "Download Code"에서 모든 YAML 스냅샷 재해 복구 스크립트를 다운로드합니다.

   주:

   기본 스크립트가 다른 보조 스크립트를 사용하기 때문에 모든 스크립트가 동일한 경로에 있어야 합니다.
2. maak8DR-apply.env 스크립트를 편집하고 보조 시스템에 액세스하는 데 필요한 주소 및 SSH 키를 업데이트합니다.
   예제

   export user_sec=opc
   export ssh_key_sec=/home/opc/Key.ppk
   #Secondary bastion node
   export sechost=10.10.0.23

3. 필요에 따라 exclude_list 및 nons_artifacts_types의 값을 사용자정의합니다.
   • exclude_list: 모든 사용자 정의 네임스페이스를 백업하려고 할 때도 백업에서 제외해야 하는 네임스페이스의 공백으로 구분된 목록입니다. 이는 보조에 적용할 수 없는 제어 플레인 관련 네임스페이스를 복사하지 않도록 하기 위한 것입니다.
   • nons_artifacts_types: 루트 트리에 속하지만(정확한 네임스페이스의 일부가 아님) 스냅샷에도 포함되어야 하는 목록 또는 아티팩트입니다. 프레임워크는 백업 중인 네임스페이스에 대한 참조를 찾습니다.
   일반적으로 파일에 제공된 기본값을 사용할 수 있습니다.

   #List of namespaces that will be excluded from the backup
   export exclude_list="kube-system kube-flannel kube-node-lease kube-public"
   #Root artifacts that will be included
   export nons_artifacts_types="crd clusterrole clusterrolebinding"
   

4. 복제할 선택된 네임스페이스를 인수로 제공하는 maak8DR-apply.sh 스크립트를 실행합니다.

   • 인수를 제공하지 않을 경우 스크립트는 exclude_list 변수에 제공된 네임스페이스를 제외한 모든 네임스페이스를 복제합니다.

   • 정확한 네임스페이스 목록을 사용하는 경우 다른 네임스페이스와의 종속성을 기준으로 순서를 지정해야 합니다.

     즉, 네임스페이스 soans가 네임스페이스 opns의 서비스에 종속되거나 서비스를 사용하는 경우 opns가 목록에 먼저 나타나야 합니다. 예를 들어, ./maak8DR-apply.sh soans opns 대신 다음을 실행합니다.

     ./maak8DR-apply.sh opns soans

확인

maak8DR-apply.sh 스크립트를 실행한 후 기본 클러스터에 있는 모든 아티팩트가 보조 클러스터로 복제되었는지 확인합니다. 보조 클러스터를 살펴보고 보조 사이트의 POD가 오류 없이 실행 중인지 확인합니다.

maak8DR-apply.sh 스크립트를 실행하면 프레임워크에서 working_dir 디렉토리를 /tmp/backup.date로 생성합니다. maak8-get-all-artifacts.sh 및 maak8-push-all-artifacts.sh 스크립트를 개별적으로 실행하면 작업 디렉토리가 각 경우에 명령행의 인수로 제공됩니다.

1. 필요한 포드가 기본의 상태와 일치할 때까지 보조 포드의 상태를 확인합니다.
   기본적으로 Pod 및 배치는 보조 영역에서 시작됩니다. 복원이 끝나면 보조 클러스터의 상태가 표시됩니다. 일부 포드는 RUNNING 상태에 도달하는 데 추가 시간이 걸릴 수 있습니다.
2. 기본 파일의 $working_dir/date/backup-operations.log 파일에서 추출 및 적용 작업에 오류가 있는지 확인합니다.
3. 추출 및 적용 작업에서 가능한 오류가 있는지 보조의 $working_dir/restore.log 및 $working_dir/date/restore-operations.log 파일을 확인하십시오.
   restore-operations.log 파일에는 자세한 복원 작업이 포함되어 있습니다.