프로젝트

일반

사용자 정보

실행

새 기능 #13767

실장비가 밝혀낸 GMS 규칙 반영과 드라이버 분할 마무리

오 지호님이 6일 전에 추가함. 6일 전에 수정됨.

상태:
진행
우선 순위:
보통
담당자:
목표 버전:
시작 시간:
2026/09/22
완료 기한:
2026/09/22 (7일 지연)
진척도:

100%

추정 시간:
4:00 시간
발견 버전:
반영 버전:
난이도:
보통
중요도:
하
조력자:
회사:
연락처:
점수:
0.00

설명

개요

드라이버 분할의 마지막 단계다. 2노드 ASE4 장비 회차가 밝혀낸 GMS 규칙 셋을 드라이버에 반영하고, manila 2024.1 지원 문서와 실장비 검증 기록을 정리한다.

가장 큰 것은 export 순서다. pcsd가 활성이면 GMS는 filesystem 리소스가 정지된 채 있는 LV의 마운트를 "Block device is managed by Pacemaker"로 거부한다. 같은 device를 손으로 마운트하면 성공하므로 mock은 이 거부를 재현하지 못했고, 정지된 share를 ensure_share가 수리하려다 여기서 죽었다. 이제 export의 클러스터 리소스 단계가 마운트 확인보다 앞선다. HA에서 실제로 마운트하는 주체는 filesystem 리소스의 agent이고 확인은 그 agent의 마운트를 찾는다. 이 이동 때문에 maintenance 가드는 재진입 가능해야 한다. 마운트가 자기 LV 변경 창에서 같은 락을 다시 잡기 때문이고 일반 락으로 두면 HA 통합 검사가 create에서 멈춘다.

두 번째는 VG 정지가 서비스 VIP를 끌어내리는 문제다. 마지막 share를 지우면 VG 리소스가 정지되는데, VIP 그룹에 대한 INFINITY colocation이 걸린 채로 정지가 실패하면 드라이버가 통신하는 주소까지 같이 내려간다. 이 클러스터의 LVM agent는 VG 정지에 실패한다. 리소스를 아예 삭제하는 우회로도 답이 아니다. 고아가 된 정지가 같은 방식으로 실패하고 다음 create가 그 위에 colocation을 다시 만든다. 그래서 teardown_vg가 아무것도 정지하기 전에 해당 VG를 참조하는 colocation 제약을 먼저 지운다.

세 번째는 share root 권한이다. snapshot은 root inode도 다른 것과 같이 찍으므로, 기존 파일시스템을 다시 export하면서 create의 초기화를 되풀이하면 호출자가 건드려 달라고 한 적 없는 상태를 지우게 된다. 초기화는 create에만 남기고 squash 신원의 chown은 그 정책을 live로 읽는 update_access로 옮겼다.

revert to snapshot은 이번에도 들어오지 않는다. 백엔드가 snapshot 병합을 지원하지 않아 구현이 우회책이 되고, GMS가 병합 API를 갖추면 흐름 전체가 한 번의 호출로 접히면서 딸려온 부분들이 버려진다. 설계 문서와 실장비 기록은 별도 브랜치로 보존한다.

작업 내용

  • export의 클러스터 리소스 단계를 마운트 확인보다 앞으로 옮긴다. maintenance 가드를 재진입 가능하게 만들고 mock도 정지된 리소스 아래의 직접 마운트를 거부한다.
  • share root 초기화를 create 전용으로 한다. 777 개방은 갓 만든 파일시스템에만 적용하고 squash 신원의 chown은 update_access로 옮긴다.
  • teardown_vg가 VG 리소스를 정지하기 전에 VIP 그룹과의 colocation 제약을 먼저 지운다. 클라이언트에 제약 조회와 삭제 엔드포인트를 래핑한다.
  • failover 뒤 새 active 노드가 access map PUT에 404를 주면 catalog record로 export를 다시 만들고 재시도한다. 다른 상태 코드는 그대로 올린다.
  • Access Group 이름의 10-hex 절단을 없앤다. GMS가 이름 규칙을 64자로 넓혔으므로 LV와 같은 전체 instance id를 쓴다.
  • 백엔드를 변경하는 모든 흐름을 하나의 락으로 직렬화한다. 읽기 경로와 update_access는 제외한다. 각 흐름이 내는 모든 백엔드 호출의 락 상태를 기록하는 검사를 붙여 데코레이터를 빠뜨린 흐름이 테스트에서 걸리게 한다.
  • manila 2024.1(18.0.1)과 Python 3.8을 호환 표에 적고, 두 번째 compose 스택과 인터프리터 범위를 테스트 문서에 기술한다.
  • 2노드 ASE4 장비 회차가 정한 세 규칙을 phase 3 기록으로 남긴다.
  • README의 상태 문구와 기능 표를 실제 검증 상태에 맞춘다. 실장비를 만난 적 없다고 적혀 있었으나 phase 3이 그 반대를 증명한 지 오래다.
실행 #2

오 지호님이 6일 전에 변경

  • 진척도 항목을 변경했습니다 (0 => 100)
실행

내보내기 Atom PDF

클립보드 이미지 추가 (최대 크기: 50 MB)