CAS 는 controller 파드와 worker 파드로 구성된다. 살아 있는지 판단할 때는 쿠버네티스 쪽과 SAS 쪽을 함께 본다.
kubectl get pods -n <namespace> | grep cas
kubectl get svc -n <namespace> | grep cas
kubectl get pods -n <namespace> -l cas.sas.com/role=worker
컨트롤러 로그에서 라이선스·메모리·노드 조인 실패가 바로 드러난다.
kubectl logs -n <namespace> <cas-controller-pod> -c cas
kubectl describe pod -n <namespace> <cas-controller-pod>
describe 의 Events 에서 OOMKilled, Insufficient memory, NodeAffinity 를 먼저 찾는다.
SAS 세션에서는 다음으로 확인한다.
cas;
caslib _all_ assign;
proc cas;
session.listSessions;
serverStatus;
quit;
파드가 Running 이고 컨트롤러 로그에 ERROR 가 없으며 serverStatus 가 정상이고 caslib _all_ assign 이 통과하면 CAS 는 살아 있다고 본다.
sas-cas-backup-data PVC 가 계속 커진다는 신고가 잦다. 여기에서 헷갈리는 지점이 둘 있다.
첫째, 백업 CronJob 의 Job 파드는 이 PVC 를 직접 마운트하지 않는다. Job 은 백업을 요청할 뿐이고, 실제 파일을 쓰는 것은 CAS controller 파드 안의 sas-backup-agent 컨테이너다. 그래서 Job YAML 을 아무리 뒤져도 PVC 가 보이지 않는다.
kubectl describe pod -n <namespace> sas-cas-server-default-controller | grep -A3 backup
BACKUP_MOUNT_LOCATION: /sasviyabackup
/sasviyabackup from backup (rw)
backup:
ClaimName: sas-cas-backup-data
둘째, 백업을 만드는 CronJob 과 지우는 CronJob 이 다르다.
| CronJob | 역할 |
|---|---|
sas-scheduled-backup-job |
주간 전체 백업 |
sas-scheduled-backup-incr-job |
평일 증분 백업 |
sas-scheduled-backup-all-sources |
PostgreSQL 을 포함한 전체 소스 백업 |
sas-backup-purge-job |
보존 기간이 지난 백업 삭제 |
용량이 무한히 늘어난다면 원인은 보통 purge-job 이 실패하고 있다는 것이다. 보존 기간 설정이 있어도 삭제를 실행하는 쪽이 죽으면 쌓이기만 한다.
kubectl get cronjob -n <namespace>
kubectl get job -n <namespace> | grep sas-backup-purge
kubectl logs -n <namespace> job/<sas-backup-purge-job-name>
보존 기간은 sas-backup-job-parameters ConfigMap 의 RETENTION_PERIOD 로 제어한다. 단위는 일이다.
kubectl get cm -n <namespace> | grep backup
kubectl get cm sas-backup-job-parameters-<hash> -n <namespace> -o yaml | grep RETENTION
kustomize 가 ConfigMap 이름에 해시를 붙이므로 이름이 여러 개 보이는 것은 정상이다. 실제로 쓰이는 것은 CAS controller 파드가 참조하는 하나뿐이다.
임시로 바꿀 때는 패치한다.
kubectl patch cm sas-backup-job-parameters-<hash> -n <namespace> \
--type merge -p '{"data":{"RETENTION_PERIOD":"7"}}'
영구 반영은 kustomization.yaml 의 configMapGenerator 로 한다.
configMapGenerator:
- name: sas-backup-job-parameters
behavior: merge
literals:
- RETENTION_PERIOD=7
| 환경 | 권장 보존 기간 |
|---|---|
| PoC · 테스트 | 1~3일 |
| 개발 | 5~7일 |
| 운영 | 7~14일 |
설정을 바꾼 뒤에도 이미 쌓인 백업이 바로 사라지지는 않는다. 다음 purge-job 실행부터 적용된다.
백업 PVC 아래 디렉터리 이름은 타임스탬프와 종류로 되어 있다.
20251207-010212F
20251214-010016F
20251221-010212F
20251228-010211F
20260104-010212F
끝의 F 는 전체(full) 백업이다. 주 1회 전체 백업에 보존 기간이 30일이면 4~5개가 남는 것이 정상이며, 새 백업이 하나 생길 때마다 가장 오래된 하나가 지워져 총량이 유지된다. 이 상태라면 손댈 필요가 없다.
Viya 통합 백업은 CAS 를 기본으로 포함하고, CAS 데이터가 용량의 대부분을 차지한다. CAS 만 제외하는 옵션은 없으므로 선택지는 둘뿐이다.
첫째, 백업 생성 CronJob 을 중지한다. 이미 만들어진 백업은 남고 새 백업만 생기지 않으므로 용량이 고정된다.
kubectl patch cronjob sas-scheduled-backup-job -n <namespace> -p '{"spec":{"suspend":true}}'
kubectl patch cronjob sas-scheduled-backup-incr-job -n <namespace> -p '{"spec":{"suspend":true}}'
kubectl patch cronjob sas-scheduled-backup-all-sources -n <namespace> -p '{"spec":{"suspend":true}}'
둘째, 보존 기간을 줄인다.
sas-backup-purge-job 은 중지하면 안 된다. 삭제를 담당하는 쪽이라 멈추면 정리가 되지 않는다.
PostgreSQL 백업은 Crunchy Operator 가 별도 CronJob(sas-crunchy-platform-postgres-repo1-full, ...-incr)으로 수행하며 CAS 백업 PVC 를 쓰지 않는다. 따라서 CAS 백업을 중지해도 데이터베이스 백업에는 영향이 없다. 통합 백업에서 PostgreSQL 을 빼려면 INCLUDE_POSTGRES=false 를 준다.
sas-backup-job-parameters ConfigMap 에서 조절할 수 있는 항목들이다.
| 키 | 의미 |
|---|---|
RETENTION_PERIOD |
보존 기간(일) |
JOB_TIME_OUT |
백업 작업 제한 시간(분) |
INCLUDE_POSTGRES |
등록된 PostgreSQL 서버 포함 여부 |
FILESYSTEM_BACKUP_EXCLUDELIST |
파일시스템 백업에서 제외할 패턴 |
ENABLE_NOTIFICATIONS |
백업 실패 알림 |
DISABLE_VALIDATION |
PVC 여유 공간 사전 검증 비활성화 |
백업 PVC 의 StorageClass 와 크기, 백업 작업의 CPU·메모리, CAS controller 안 backup-agent 컨테이너의 리소스는 각각 별도의 예제 변환기로 바꾼다. 예제는 sas-bases/examples/backup/configure 아래에 있다.