Mold에서의 DR 구성

[gigs4014]

구성방안

아키텍처

구성시 고려 상황

2개의 Mold 클러스터가 필요하며, 1번 클러스는 운영 클러스터 2번 클러스터는 DR클러스터를 의미하며 아래 에서는 1번 클러스터 2번 클러스터로 기술함.

2개의 Mold 클러스터 및 Glue 클러스터는 네트워크 통신이 가능한 환경에서 개발이 필요하며, 해당 인프라는 Mold DR개발에서는 고려 상황이 아니며, 클러스터 간의 네트워크 구성정보는 추후 도큐먼트를 이용하여 설명을 진행 한다.

1. 1번 클러스터와 2번 클러스터가 DR 구성될수 있는 화면 필요
2. 1번 클러스터에서 DR 구성할 경우 Glue의 이미지 미러 기능까지 Mold에서 구성할지 아니면 Glue에서 이미지 미러를 셋팅하고 Mold에서 진행을 해야 할지 확인 필요
3. 2번 클러스터에서는 DR 시 사용할 가상 네트워크, 컴퓨트 오퍼링, 디스크 오퍼링 등 필요한 정보는 미리 생성이 되어 있어야 한다.
4. 1번 클러스터에서 가상머신을 DR 선택을 할 경우 2번 클러스터에서 미러링된 이미지를 이용한 가상머신을 생성해야 하며, 2번 클러스터의 가상머신은 시작이 되지 않는 상태여야 한다.
5. 1번 클러스터에서 가상머신을 DR 선택 할 경우 2번 클러스터의 컴퓨트 오퍼링, 디스크 오퍼링 및 필요한 정보를 조회 후 해당 내용을 선택 하여 DR 을 진행 한다.

[dhslove]

다음과 같은 절차 및 내용이 포함되어 있어야 함

1. 관리자는 글로벌설정 및 클러스터 설정해서 DR 기능 활성화 여부 및 ABLESTACK 클러스터에 대한 DR 클러스터 정보를 입력해야 함
2. DR이 활성화되어 있는 경우 관리자는 인프라스트럭처 > 클러스터 상세 탭에서 DR 클러스터의 정보 및 클러스터의 Mold 상태, 미러링 에이전트 등의 상태를 확인할 수 있어야 함
3. 가상머신을 생성할 때 템플릿/ISO와 함께 특정 볼륨을 이용해서 가상머신을 만들 수 있도록 해야 함(가상머신 생성 시 루트디스크 및 데이터디스크 할당)
4. 볼륨을 생성할 때 특정 패스를 이용해 생성할 수 있도록 해야 함(기본스토리지 브라우저에서 볼륨 생성)
5. 가상머신에서 DR을 설정할 수 있어야 하며, DR을 설정하면 별다른 설정 없이 미러링 설정이 이루어져야 함
6. DR 설정, 즉 미러링 설정이 된 경우 가상머신 볼륨별로 미러링 상태를 확인할 수 있어야 함
7. DR 측 사이트에서 미러링된 볼륨을 만들 때 DR목적으로 가상머신을 만든다는 정보를 설정해야 하고, 이러한 가상머신은 정지 상태로 생성되어야 함
8. DR 측 가상머신을 만들면 원본 측 가상머신 DR 상태 조회에서 DR 측 가상머신 정보를 DR 상태 탭에서 확인할 수 있어야 함(DR 가상머신 정보 + 볼륨 미러링 정보)
9. 가상머신의 DR 상태에 대해 모의 시험을 할 수 있어야 함
10. DR 상태에서 강제 프로모트 및 강제 디모트가 가능하도록 설정할 수 있어야 함

이 정도 입니다. 나중에 필요한 사항이 더 있다면 추가하도록 하죠.

[stardom3645]

Mold에서의 DR 기능 예시

- DR 기능 활성화/비활성화

• 위치: 구성 > 글로벌 설정
• 설명: 글로벌 설정에서 DR 기능을 enable 또는 disable할 수 있습니다.
  • enable: '재난복구클러스터' 메뉴와 가상머신 상세 탭에 'DR'탭이 활성화 되며 '재난 복구 클러스터' 메뉴에서 여러 DR 클러스터를 추가할 수 있습니다.
  • disable을 선택할 경우 미러링을 중단하고 메뉴를 표시하지 않습니다.

• 고려사항:

• 이미지
  

---

- '재난복구클러스터' 메뉴

• 액션버튼 (Primary 클러스터일 경우)
  • 편집: Primary 클러스터의 이름, 설명, IP, 포트 변경
  • 활성화: Primary 클러스터의 비활성화
  • 비활성화: Primary 클러스터의 비활성화
  • 삭제: 클러스터 삭제
• 액션버튼 (Secondary 클러스터일 경우)
  • 편집: Secondary 클러스터의 이름, 설명, IP, 포트 변경
  • 활성화: Secondary 클러스터의 비활성화
  • 비활성화: Secondary 클러스터의 비활성화
  • 강제 프로모트: Primary 클러스터로 강제 프로모트 실행
  • 강제 디모트: Secondary 클러스터로 강제 디모트 실행
  • 삭제: 클러스터 삭제

---

- '재난복구클러스터' 메뉴 - 01

리스트 화면

• 위치: 인프라스트럭처 > 재난 복구 클러스터
• 설명:
  • 표시 항목
    • 이름
    • 클러스터 모드: 등록된 클러스터가 Primary 클러스터인지 Secondary 클러스터인지 표시되며 "primary", "sSecondary"로 구분
    • IP: Primary 또는 Secondary 클러스터의 ip 정보
    • 클러스터 상태: Secondary 클러스터의 상태 ->Secondary 클러스터와의 연결 상태
    • 미러링 에이전트 상태: DR 미러링을 수행하는 에이전트의 상태
• 고려사항 :
  • Primary 클러스터 인지 Secondary 클러스터 인지 식별 정보 명확하게 표현할 UI 필요.
  • 미러링 에이전트 상태와 달리 Primary 클러스터와 Secondary 클러스터의 미러링 상태
• 이미지
  

---

- '재난복구클러스터' 메뉴 - 02

DR 상세 탭 화면

• 위치: 인프라스트럭처 > 재난 복구 클러스터
• 설명:
  • 표시 항목
    • 왼쪽 섹션
      • 클러스터 상태 정보
      • 미러링 에이전트 상태
      • 아이디(uuid)
      • IP, Zone, 계정, 도메인, 생성일
      • API 키, 비밀 키
    • 오른쪽 섹션
      • 이름, 설명
      • IP, 포트, Zone, 생성일
• 고려사항 :
• 이미지
  
  

---

- '재난복구클러스터 구성' 메뉴 - 03

DR 가상머신 탭 화면

• 위치: 인프라스트럭쳐 > 재난복구클러스터 > DR 가상머신 탭
• 고려사항 :
• 이미지
  

---

- '재난복구클러스터' 메뉴 - 04

DR 설정 탭 화면

• 위치: 인프라스트럭쳐 > 재난복구클러스터 > DR 설정 탭
• 고려사항 :
• 이미지
  

---

- '재난복구클러스터' 메뉴 - 05

재난복구클러스터 추가 버튼

• 위치: 인프라스트럭쳐 > 재난복구클러스터 > 재난복구클러스터 추가 버튼
• 고려사항 : Mold 정보(api key, secret key)와 Glue정보(private key) 값을 입력할 때 시각적으로 구분해서 보여줄 필요가 있음.
• 이미지
  

---

- '재난복구클러스터' 메뉴 - 06

강제 프로모트 - Primary 클러스터 장애 시, DR 클러스터를 Primary 클러스터로 강제 프로모트 하는 기능

• 위치: 인프라스트럭쳐 > 재난복구클러스터 > 강제 프로모트
• 고려사항 : 기존 Primary 클러스터를 먼저 디모트하지 않으면 동시에 2개의 Primary 클러스터 존재하기 때문에 로드밸랜서를 통해 라우팅 처리
• 이미지

---

- '가상머신 메뉴 DR' - 01

기존 생성된 디스크로 가상머신 생성

• 위치: 가상머신 생성 > 템플릿/ISO/볼륨 section
• 고려사항 : DR용으로 만든다는 메시지 표시, 볼륨 테그가 root에서 data disk로 변경되어 확인 필요.
• 이미지
  

---

- '가상머신 메뉴 DR' - 02

Primary 클러스터의 VM을 DR 클러스터로 복제 생성하는 기능

• 위치: 컴퓨트 > 가상머신 > 가상머신 상세 화면 > DR 가상머신 추가 액션버튼
• 설명:
  • DR 가상머신 추가 액션버튼 누른 후, 모달창에서 'DR 사이트'를 선택하면 스토리지, 컴퓨트 오퍼링, 네트워크 오퍼링이 선택된 DR사이트의 정보에 따라 셀렉트 박스에 표시.
  • DR 가상머신 추가 결과는 DR 탭 리스트의 "+" 버튼을 눌러 진행사항과 결과를 확인.
• 고려사항 : 오퍼링 스펙이 모두 일치해아 하는지 확인 필요, 네트워크 (ip) 달라질 경우 이슈 파악
• 이미지
  

---

- '가상머신 메뉴 DR' - 03

Primary 클러스터의 VM에서 DR 클러스터로 복제된 VM 정보 기능

• 위치: 컴퓨트 > 가상머신 > 가상머신 상세 화면 > DR 탭
• 설명: 가상머신 상세화면에서 'DR' 탭을 선택하면 DR 클러스터에 미러링 된 가상머신의 이름, DR 클러스터 명, DR가상머신의 상태에 대한 값이 리스트에 표시 됩니다. 또한 "+" 버튼을 클릭할 경우, DR가상머신 아이디 값과 미러링된 볼륨, 미러링 상태, 모의시험 실행 버튼이 표시됩니다.

• 고려사항 :

• 이미지
  

---

- '가상머신 메뉴 DR' - 04

Primary 클러스터의 VM에서 DR 미러링 모의 시험 기능

• 위치: 컴퓨트 > 가상머신 > 가상머신 상세 화면 > DR 탭 > DR 미러링 모의 시험 액션버튼
• 설명: DR 미러링 모의 시험 버튼 누른 후, 모달창에서 모의시험 시작 버튼을 눌러 모의 시험 실행하며 진행 사항을 확인
• 고려사항 :
• 이미지
  
  

[stardom3645]

• 논의 사항
  • 강제 프로모트 디모트 기능은 mold 클러스터 단위로만 실행되는 것인지 가상머신 별로도 실행 가능한 것인지
  • DR 가상머신 스펙은 100% 동일해야 하는 지

[dhslove]

• 논의 사항

  • 강제 프로모트 디모트 기능은 mold 클러스터 단위로만 실행되는 것인지 가상머신 별로도 실행 가능한 것인지
  • DR 가상머신 스펙은 100% 동일해야 하는 지

1. 강제 프로모트, 디모트 기능은 클러스터 및 가상머신 단위로 실행함. 단 양쪽 모두 중지 되어 있는 가상머신에 대해서만 강제 프로모트, 디모트 기능을 사용할 수 있음(가상머신에서 현재 가상머신이 Primary(Promote) 상태인지의 여부를 확인할 수 있어야 함)
2. DR 설정 시 가상머신의 컴퓨트 스팩은 동일할 필요 없음. 단 볼륨 스펙(크기)은 동일해야 함.

[stardom3645]

DR 기능 용어 정리

1순위	2순위	설명
재난 복구 클러스터	DR 클러스터	mold 메뉴 명
Primary 클러스터	Operation 클러스터	서비스 제공 중인 프로모트된 클러스터
Secondary 클러스터	DR 클러스터	대기 중인 디모트된 클러스터
Primary 클러스터 가상머신		현재 해당 클러스터에서 운영되고 있는 가상머신
Secondary 클러스터 가상머신	미러링 가상머신	secondary 클러스터에 존재하며 primary 클러스터에서 운영 중인 가상머신과 미러링된 가상머신

[Dajeong-Park]

API 설계

• 권한

admin 권한으로 개발진행 예정이며, 가상머신 관련 모의시험 등에 대한 API 에 user 권한이 필요한지 확인 필요

**** DR 관련 클러스터에 대한 용어는 Primary 클러스터, Secondary 클러스터로 임의로 지칭하여 작성함 ****

• DR

  • DR 클러스터 연결 테스트 (connectivityTestsDisasterRecovery)

    • 설명 : DR 추가 시 필수로 실행해야 할 API
    • 작업 1 : SCVM IP 목록 조회하는 API 개발 (listScvmIpAddress)
    • 작업 2 : 구성할 DR 클러스터의 Mold 상태 조회 (listScvmIpAddress API 요청)
    • 작업 3 : 구성할 DR 클러스터의 Glue 상태 조회 (/api/v1/glue API 요청)
      Q&A : Glue 상태 조회 시 어떤 상태를 기준으로 할지? Health_OK 인 경우 or warn 인 경우?

  • DR 추가 (createDisasterRecovery)

    • 사전 작업 : UI 에서 DR 클러스터 연결 테스트 API 실행 후 결과에 따른 성공/에러 처리 후 진행
    • 참조 : 미러링 클러스터 설정 glue-api 파라미터 중 "Remote Cluster PrivateKey" 는 glue 의 id_rsa 파일을 뜻함.
    • 작업 1 : Glue 의 미러링 클러스터 설정 (glue-api : /api/v1/mirror POST)
    • 작업 2 : Secondary 클러스터의 DB에 Primary 클러스터 정보 DB 업데이트
    • 작업 3 : Primary 클러스터의 DB에 Secondary 클러스터 정보 DB 업데이트
      Q&A : Primary 클러스터의 경우 DR 1개 구성되어있는 경우 더 추가할 수 있도록 해야하는지? 추가할 수 없도록 막아야하는지?
Q&A : 이미 등록된 Primary 클러스터가 있는 Secondary 클러스터의 경우 DR 추가할 수 있도록 해야하는지? 추가할 수 없도록 막아야하는지?

  • DR 조회 (listDisasterRecovery)

    • 설명 : DR 추가를 실행한 주체(Mold)의 DR 리스트는 Secondary 클러스터를 목록에서 확인하며, Secondary 클러스터로 등록된 Mold의 DR 리스트는 Primary 클러스터를 목록에서 확인할 수 있다.
    • 작업 1 : Glue의 미러링 상태 조회 (glue-api : /api/v1/mirror GET) 및 DB 업데이트

  • 액션 버튼

    • DR 활성화 (enableDisasterRecovery)

      • 작업 1 : Primary 클러스터에서 액션을 실행한 경우 DB에서 Secondary 클러스터 상태를 활성화로 업데이트한 후 Secondary 클러스터의 DB에서 Primary 클러스터 상태를 활성화로 업데이트
      • 작업 2 : Secondary 클러스터에서 액션을 실행한 경우 DB에서 Primary 클러스터 상태를 활성화로 업데이트한 후 Primary 클러스터의 DB에서 Secondary 클러스터 상태를 활성화로 업데이트

    • DR 비활성화 (disableDisasterRecovery)

      • 작업 1 : Glue API 요청하여 풀 미러링에 대한 활성화/비활성화
      • 작업 2 : Primary 클러스터에서 액션을 실행한 경우 DB에서 Secondary 클러스터 상태를 비활성화로 업데이트한 후 Secondary 클러스터의 DB에서 Primary 클러스터 상태를 비활성화로 업데이트
      • 작업 3 : Secondary 클러스터에서 액션을 실행한 경우 DB에서 Primary 클러스터 상태를 비활성화로 업데이트한 후 Primary 클러스터의 DB에서 Secondary 클러스터 상태를 비활성화로 업데이트

    • DR 편집 (updateDisasterRecovery)

      • 작업 1 : Secondary 클러스터의 DB에 변경된 정보 업데이트
      • 작업 2 : Primary 클러스터의 DB에 변경된 정보 업데이트
        Q&A : 편집 가능 항목 픽스 필요 (클러스터 이름, 설명, URL, API키/비밀키)

    • DR 삭제 (deleteDisasterRecovery)

      • 작업 1 : Glue 의 미러링 클러스터 제거 (glue-api : /api/v1/mirror DELETE)
      • 작업 2 : Secondary 클러스터의 DB에 해당 Primary 클러스터 remove 처리
      • 작업 3 : Primary 클러스터의 DB에 해당 Secondary 클러스터 remove 처리
        Q&A : DR 삭제 시 다른 고려사항은 없는지?

    • DR 강제 프로모트 (promoteDisasterRecovery)

      • 참조 : MirrorImagePromote (glue-api) 로직은 RemoteImageDemote -> ImageStatus -> ImagePromote -> ImageStatus 순으로 작업이 진행된다.
      • 참조 : Primary 클러스터가 다운된 복구 상황에서는 rbd mirror image promote 시 ---force 명령어를 붙여야하며, 현재 glue-api 에서는 --force 명령어를 적용하지않고 있음.
      • 설명 : Primary 클러스터를 Demote 하고, Secondary 클러스터를 Promote 하는 것을 의미함.
      • 작업 1 : 클러스터 단위인 경우 Glue의 미러링 이미지 조회 (glue-api : /api/v1/mirror/image GET) 한 후 각 이미지 별 강제 프로모트 실행 (glue-api : /api/v1/mirror/promote/:mirrorPool/:imageName POST)
      • 작업 2 : 가상머신 단위인 경우 Glue의 가상머신 단위 강제 프로모트 실행 (glue-api : /api/v1/mirror/promote/:mirrorPool/:imageName POST)

    • DR 강제 디모트 (demoteDisasterRecovery)

      • 참조 : MirrorImageDemote (glue-api) 로직은 ImageDemote -> ImageStatus -> RemoteImagePromote -> ImageStatus 순으로 작업이 진행된다.
      • 설명 : Secondary 클러스터를 Demote 하고, Primary 클러스터를 Promote 하는 것을 의미함.
      • 작업 1 : 클러스터 단위인 경우 Glue의 미러링 이미지 조회 (glue-api : /api/v1/mirror/image GET) 한 후 각 이미지 별 강제 디모트 실행 (glue-api : /api/v1/mirror/demote/:mirrorPool/:imageName DELETE)
      • 작업 2 : 가상머신 단위인 경우 Glue의 가상머신 단위 강제 디모트 실행 (glue-api : /api/v1/mirror/demote/:mirrorPool/:imageName DELETE)
        Q&A : Primary/Secondary 양쪽 모두 중지 상태의 VM에서만 해당 액션을 실행해야하며, 강제로 정지 명령을 내린 후 작업을 진행하는 것까지 자동으로 해야하는지, 중지된 VM에서만 액션이 가능하다고 예외처리를 해야하는지, 중지상태의 VM에 한해서 액션을 실행할지

• VM

  • Secondary 클러스터의 정보 조회 (API명 필요)

    • 작업 1 : Secondary 클러스터의 컴퓨트 오퍼링과 네트워크 목록을 조회
    • 참조 : DR 미러링 VM 추가 시 가상머신 생성 요청까지 작업한다면 필요하지만, 볼륨 미러링만 작업한다면 해당 API는 필요하지 않음

  • 볼륨 미러링 상태 조회 (API명 필요)

    • 작업 1 : 가상머신의 볼륨별 Glue의 이미지 미러링 상태 조회 (glue-api : /api/v1/mirror/image/:mirrorPool/:imageName GET) 및 DB 업데이트

  • 액션 버튼

    • DR 미러링 VM 추가 (API명 필요)

      • 사전 작업 : UI에서 Secondary 클러스터의 정보 조회하는 API 실행해야함.
      • 작업 1 : Secondary 클러스터에 정지된 상태의 가상머신 생성 요청
        Q&A : 가상머신 생성 요청까지 작업할지, 볼륨 미러링까지만 작업하고 Secondary 클러스터에서 수동으로 가상머신 생성하도록 할지?
      • 작업 2 : 현재 VM과 동일한 볼륨 스펙으로 가상머신의 볼륨별 Glue의 이미지에 미러링 설정 (glue-api : /api/v1/mirror/image/:mirrorPool/:imageName POST) 및 DB 업데이트

    • DR 볼륨 미러링 추가 (API명 필요)

      • 작업 1 : 현재 VM과 동일한 볼륨 스펙으로 가상머신의 볼륨별 Glue의 이미지에 미러링 설정 (glue-api : /api/v1/mirror/image/:mirrorPool/:imageName POST) 및 DB 업데이트
      • 작업 2 : interval과 startTime 설정은 클러스터 설정으로 default 지정

    • DR 미러링 VM 모의시험 (API명 필요)

      • 사전 작업 : 강제로 가상머신 정지 명령을 내린 후 작업
      • 작업 1 : VM의 볼륨별 강제 디모트 실행 (glue-api : /api/v1/mirror/demote/:mirrorPool/:imageName DELETE)
      • 작업 2 : DR VM의 볼륨별 강제 프로모트 실행 (위 API에서 해당 작업진행)
      • 작업 3 : DR VM 시작
      • 작업 4 : timeout 1~2분 이상없음 확인
      • 작업 5 : DR VM 정지
      • 작업 6 : DR VM의 볼륨별 강제 디모트 실행 (glue-api : /api/v1/mirror/promote/:mirrorPool/:imageName POST)
      • 작업 7 : VM의 볼륨별 강제 프로모트 실행 (위 API에서 해당 작업진행)
      • 작업 8 : 모의시험 실행한 VM 시작

• DB

  • disaster_recovery 테이블 추가

    • 컬럼 : id, name, description, type, protocol, ip, port, mirror_status, cluster_status, api_key, secret_key

  • disaster_recovery_vm 테이블 추가

    • 컬럼 : id, cluster_id, vm_id, vol_id, vol_size, vol_mirror_status
      Q&A : 사전 볼륨 미러링 여부, interval, startTime에 대한 값도 저장해야할지?

   Q&A : 장애 발생 시 Secondary 클러스터로 복구조치하여 Primary 클러스터가 된 경우에 필요한 후처리는??