Veeam Kasten - On-Prem to Azure AKS 이전

Veeam Kasten(Kubernetes 백업 솔루션) 이용해서 On-Prem Kube Cluster 에서 Azure AKS로 간단한 PostgreSQL Database 이전 작업을 성공하여 해당 내역 공유해 드립니다. 중간에 스토리지(Azure Storage 또는 NFS 서버)를 두고  DB Data + DB 설정 Manifest(YAML 파일)을 Copy 하는 구조 입니다. 

 

이렇게 구성하면 DR 센터 구성 시 별도의 시스템을 구축하지 않고(즉 비용 발생하는 상시 운영 서버를 두지 않고) 스토리지에 정기적으로 Data(snapshot 기반) + 설정을 저장만 하면 됩니다. 그리고 1주일 혹은 한달마다 복구 테스트를 하면 Public Cloud(또는 원격지 On-Prem) DR 센터 구성이 가능합니다. 물론 VM도 비슷하게 구성이 가능하지만 속도와 정확성 측면에서 Kube가 월등합니다.

 

Kasten은 DR 센터 구축 또는 Hybrid Cloud(On-Prem + Public Cloud 이전 작업) 또는 Multi Cloud 환경에서 괜찮은 솔루션 같습니다. 

 

작업 내역

On-Prem PostgreSQL DB를 원격 AKS(Azure Kubernetes Service)로 Migration 한 테스트 사례 입니다. 사전에 복구에 사용할 AKS Cluster와 데이터 이전 용 Azure Storage는 미리 만드셔야 합니다. 

 

먼저 On-Prem Kube Cluster에 설치한 postgresql을 Export 합니다. On-prem, DB는 간단히 아래의 데이터가 저장되어 있습니다.

[spkr@erdia22 k10-4.0.3 (ubuns:postgresql)]$ k exec -it postgresql-postgresql-0 -- bash
1001@postgresql-postgresql-0:/$ PGPASSWORD=postgres psql -U postgres
psql (11.12)
Type "help" for help.

postgres=# select * from account_test;
 user_id | username | password |     email      |         created_on         | last_login
---------+----------+----------+----------------+----------------------------+------------
       1 | 이름     | 1234     | DBMS@NAVER.COM | 2021-06-23 01:09:48.571987 |
(1 row)

Kasten의 모든 작업은 편리하게 GUI로 가능합니다. GUI에서 백업할 Application을 선택 합니다. 

 

Application - postgresql

• export 메뉴 선택 

DB 데이터 백업을 위하여 원격에서도 mount 가능한 Storage가 사전에 필요합니다. (Azure Storage 만드는 방법은 생략 하였습니다.) 사용 가능한 스토리지 종류는 AWS S3,  Google, NFS 등이 있습니다.

저는 Azure에서 복구할 예정이라 Azure Storage로 만들었습니다.

Data 뿐만 아니라 Manifest 전체, 즉 CM, Namespace, Secret, Service 등 Application 관련된 전체 resource 까지 같이 백업 됩니다.  복구 후 확인해 보시면 Helm PostgreSQL 전체가 같이 포함되어 있습니다.

ConfigMap, Namespace, secrets 전체 포함되어 있습니다.

(물론 Data만 백업하고 설정 파일 등은 GitOps 환경을 구축하여 동기화하는 것이 더 나은 구성입니다.)

Export가 완료되면 Import에 사용할 ‘key’가 생성됩니다. 향후 import 시 사용하므로 별도 Text 파일에 꼭 저장하셔야 합니다. (작업이 완료되면 별도 조회가 안 되는 것 같습니다.)

이제 Application을 Import 합니다. 사전에 설치한 AKS에 Kasten을 미리 설치해 둡니다. 

Kasten 설치 참조 

: https://jerryljh.tistory.com/30

Kube 백업 - Veeam Kasten 테스트 내역 공유

: https://docs.kasten.io/4.0.3/install/index.html

 

Kasten 대시보드 중간 Policies를 선택합니다.

Import 작업을 수행할 ‘Create New Policy’ 선택 합니다.

임의의 이름을 지정하고 Import를 선택 합니다.

복구 후 Restore 작업까지 수행하므로 아래 ‘Restore After Import’ 선택합니다.

각 Kube Cluster마다 StorageClass 이름이 다르므로 이름 변경이 필요합니다. 즉 On-Prem Kube Cluster에서 사용한 StorageClass 이름과 Azure AKS에서 사용하는 Storage Class 이름은 서로 다르므로 변경 작업을 미리 하셔야 합니다. 설정을 위하여 ‘Apply transforms to restored resources’ 선택 합니다.

클릭하시면 나오는 화면의 오른쪽에 Use an Example, Change storageClass 선택하시면 StorageClass 이름을 변경하는 예제가 이미 친절하게 잘 나와 있습니다. ^^

storageClassName을 지원하는 AKS에서 지원하는 SC로 변경 합니다.

(참고로 사용 가능한 StorageClass을 미리 확인 합니다.)
[spkr@erdia22 k10-4.0.3 (myaks:postgre)]$ k get sc
NAME                PROVISIONER                  RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
azurefile           kubernetes.io/azure-file     Delete          Immediate              true                   5h6m
azurefile-premium   kubernetes.io/azure-file     Delete          Immediate              true                   5h6m
default (default)   kubernetes.io/azure-disk     Delete          WaitForFirstConsumer   true                   5h6m
managed-premium     kubernetes.io/azure-disk     Delete          WaitForFirstConsumer   true                   5h6m

 

기본 예제의 “ssd-us-web1-a” StorageClass 이름을 Azure에서 사용 중인 “default”로 변경 합니다.

이제 StorageClass 이름 설정이 완료 되었습니다. 기존 Export 시 생성한 Key 값을 Paste 합니다.

Import 스케쥴 주기를 설정합니다. 매시간 혹은 매일 등의 주기를 설정 할 수 있습니다.

Import 정책이 생성되었습니다.

복구를 위하여 생성한 Import 작업을 즉시 실행(run once) 합니다. 

 

Application, Restore Point 선택 합니다.

Storage Class 이름 변경을 위하여 아래 옵션을 선택 합니다.

Azure에서 사용 가능한 StorageClass를 이용할 예정이므로 기존 On-Prem에서 사용 중인 StorageClass 생성은 제외 합니다. 

설정이 완료되어 마지막 Restore 버튼을 클릭 합니다.

Restore 작업이 시작되면 대시 보드 Actions에 Restore 작업 진행 내역이 표시됩니다.  

약 1분 정도 지나서 작업이 완료되었습니다. 

이제 정상적으로 완료되었는지 확인을 위하여 kubectl 명령어로 POD, PVC 등의 리소스를 확인해 보겠습니다.

[spkr@erdia22 k10-4.0.3 (myaks:postgre)]$ kns postgresql
Context "myaks" modified.
Active namespace is "postgresql".

[spkr@erdia22 k10-4.0.3 (myaks:postgresql)]$ k get pod -n postgresql
NAME                      READY   STATUS    RESTARTS   AGE
postgresql-postgresql-0   1/1     Running   0          67s

[spkr@erdia22 k10-4.0.3 (myaks:postgresql)]$ k get pvc -n postgresql
NAME                           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
data-postgresql-postgresql-0   Bound    pvc-56b18cfa-3cd1-4d07-a656-0cafc8cda61c   50Gi       RWO            default        2m14s

정상적으로 POD 및 PVC가 생성되었습니다. secret, service 등 관련 Object 등도 확인 가능합니다.

[spkr@erdia22 k10-4.0.3 (myaks:postgresql)]$ k get cm,secret
NAME                         DATA   AGE
configmap/kube-root-ca.crt   1      2m59s

NAME                                      TYPE                                  DATA   AGE
secret/default-token-nst2x                kubernetes.io/service-account-token   3      3h35m
secret/postgresql                         Opaque                                1      3m
secret/sh.helm.release.v1.postgresql.v1   helm.sh/release.v1                    1      2m59s

[spkr@erdia22 k10-4.0.3 (myaks:postgresql)]$ k get svc
NAME                  TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
postgresql            ClusterIP   10.0.137.16   <none>        5432/TCP   4m5s
postgresql-headless   ClusterIP   None          <none>        5432/TCP   4m5s

DB 데이터 확인해 보겠습니다. 

[spkr@erdia22 k10-4.0.3 (myaks:postgresql)]$ k exec -it postgresql-postgresql-0 -- bash
I have no name!@postgresql-postgresql-0:/$ PGPASSWORD=postgres psql -U postgres
psql (11.12)
Type "help" for help.

postgres=# select * from account_test;
 user_id | username | password |     email      |         created_on         | last_login
---------+----------+----------+----------------+----------------------------+------------
       1 | 이름     | 1234     | DBMS@NAVER.COM | 2021-06-23 01:09:48.571987 |
(1 row)

역시 정상적으로 복구 되었습니다. DB Dump 등 별다른 작업 없이 정상적으로 DB 백업 및 원격지 복구가 완료 되었습니다.

이상으로 원격지 Kube Cluster 간 백업 및 복구 테스트 진행 내역을 공유하였습니다. 마이그레이션 작업은 항상 쉽지 않은 작업인데 Kube + Kasten 사용 시 GUI 상에서 비교적 편리하게 작업이 가능한 것이 가장 큰 장점 같습니다.