구독 및 라이선싱

Rediacc 라이선싱은 세 가지 주요 부분으로 나뉩니다:

• account는 권리를 서명하고 사용량을 추적합니다
• rdc는 인증하고, 라이선스를 요청하고, 머신에 전달하고, 런타임에 적용합니다
• renet (머신 위의 런타임)은 계정 서버를 호출하지 않고 로컬에서 설치된 라이선스를 검증합니다

이 페이지에서는 로컬 배포에서 이러한 부분들이 어떻게 함께 작동하는지 설명합니다.

라이선싱의 역할

라이선싱은 두 가지 다른 기능을 제어합니다:

• 부동 라이선스를 통한 머신 접근 계정 처리
• 저장소 라이선스를 통한 저장소 런타임 인증

이들은 관련이 있지만 같은 형태가 아닙니다.

라이선싱 작동 방식

account는 요금제, 계약 재정의, 머신 슬롯 상태, 월간 저장소 라이선스 발급의 신뢰할 수 있는 출처입니다.

rdc는 워크스테이션에서 실행됩니다. 계정 서버에 로그인하고, 필요한 라이선스를 요청하고, SSH를 통해 원격 머신에 설치합니다. 저장소 명령을 실행할 때, rdc는 필요한 라이선스가 설치되어 있는지 확인하고 머신에서 런타임에 검증합니다.

일반적인 흐름은 다음과 같습니다:

1. rdc subscription login으로 인증합니다
2. rdc repo create, rdc repo up, 또는 rdc repo down 같은 저장소 명령을 실행합니다
3. 필요한 라이선스가 누락되었거나 만료되었다면, rdc가 account에서 요청합니다
4. rdc가 서명된 라이선스를 머신에 작성합니다
5. 라이선스가 머신에서 로컬로 검증되고 작업이 계속됩니다

워크스테이션 대 서버 분할에 대해서는 rdc vs renet을 참고하고, 저장소 라이프사이클 자체에 대해서는 Repositories를 참고하세요.

자동화 및 AI 에이전트의 경우 브라우저 로그인 대신 범위가 지정된 구독 토큰을 사용합니다:

rdc subscription login --token "$REDIACC_TOKEN"

환경을 통해 토큰을 직접 주입하면 CLI가 대화형 로그인 단계 없이 저장소 라이선스를 발급하고 새로 고칠 수 있습니다:

export REDIACC_TOKEN="rdt_..."
export REDIACC_ACCOUNT_SERVER="https://www.rediacc.com/account"

머신 슬롯과 저장소 라이선스

머신 슬롯 (서버 측)

머신 슬롯 추적은 서버 측에서 적용됩니다. CLI가 저장소 라이선스를 발급하면 계정 서버가 구독의 머신 슬롯 할당량을 확인합니다. 셀프 서비스 요금제(Community, Professional, Business)는 모두 머신 슬롯을 1개씩 포함하며, 여러 대의 머신을 운영하려면 파트너와 함께 구성하는 Enterprise 계약이 필요합니다. 슬롯은 해당 머신에서 마지막으로 저장소 라이선스가 발급된 시점부터 5시간 동안 유지되며, 비활성 상태가 지속되면 자동으로 해제됩니다. 슬롯은 실제로 프로비저닝하는 동안에만 유지되므로, 슬롯 하나로도 한 달 동안 여러 대의 머신을 충분히 감당할 수 있습니다.

이 상한은 요금제에 하드코딩된 상수가 아니라 구독 레코드에서 읽어옵니다. 따라서 별도로 협의한 활성화 수는 구독에 설정되는 즉시 반영됩니다. 요금제 티어는 시작 값만 결정합니다.

발급과 갱신은 적용 방식이 다르며, 이 차이가 중요합니다.

• 새 라이선스 발급은 상한에서 막힙니다. 모든 슬롯이 사용 중이면 요청은 MAX_MACHINES_REACHED로 실패하고 아무것도 프로비저닝되지 않습니다.
• 기존 라이선스 갱신은 막히지 않습니다. 모든 슬롯이 사용 중인 상태에서 갱신한 머신은 계속 동작하며, 해당 슬롯은 상한 초과로 기록됩니다. 이 내용은 포털의 Machines 페이지, rdc subscription status, 그리고 라이선스 상태 API의 overLimitCount 필드에서 확인할 수 있습니다. 머신이 다시 상한 안으로 들어오면 이 표시는 자동으로 해제됩니다.

갱신 쪽을 더 느슨하게 둔 것은 의도적입니다. 이미 보유한 라이선스를 갱신하는 머신은 새로 추가되는 용량이 아니며, 이를 거부하면 이미 비용을 지불한 인프라에서 백업이 멈추게 됩니다. 계속 막히는 것은 용량을 늘리는 쪽입니다.

머신 라이선스 파일은 머신에 저장되지 않습니다. 슬롯 적용은 서버의 발급 시간에 발생합니다.

저장소 라이선스

저장소 라이선스는 하나의 머신의 한 저장소에 대한 서명된 라이선스입니다. 이는 머신에 저장된 유일한 라이선스 파일이며, 데이터스토어별 그리고 서명 키별로 다음과 같이 배치됩니다.

/var/lib/rediacc/license/repos/{guid}/{keyId}.json
/var/lib/rediacc/license/datastores/{datastoreId}/repos/{guid}/{keyId}.json

머신의 기본 스토리지에 있는 저장소는 첫 번째 경로를 사용합니다. 이름이 지정된 데이터스토어에 있는 저장소는 두 번째 경로를 사용하며, 여기서 {datastoreId}는 그 데이터스토어가 생성될 때 부여받은 신원입니다. 이 범위 구분 덕분에 데이터스토어 포크가 정직하게 계측됩니다. 포크된 데이터스토어는 완전히 새로운 신원을 받으므로, 그 안의 저장소들은 라이선스가 하나도 없는 상태에서 시작해 첫 라이선스 대상 작업에서 missing을 보고하고 각자 자신의 라이선스를 발급받습니다. 실제로 놓인 데이터스토어와 다른 데이터스토어를 가리키는 라이선스를 가진 저장소는 자동으로 재발급되지 않고 identity_mismatch로 즉시 실패합니다. 이것이 라이선스 파일이 옆으로 복사되는 것을 막습니다.

{keyId}는 16자리 16진수 지문(서명 서버의 Ed25519 공개 키에 대한 SHA-256의 처음 8바이트)입니다. 둘 이상의 계정 유니버스가 관리하는 저장소(예: 프로덕션과 bench가 같은 머신에 배포하는 경우)는 {guid} 디렉터리 아래에 서명 키별로 파일을 하나씩 보유합니다. 머신의 renet 빌드는 자신에게 내장된 키, 또는 그 키에 체인으로 연결된 위임 인증서로 검증할 수 있는 파일만 검증합니다. 다른 유니버스의 파일은 사용되지 않습니다. 유니버스를 전환해도 라이선스는 무효화되지 않습니다: 새 유니버스에서의 첫 작업이 그 유니버스의 라이선스를 한 번 발급하며(결과가 missing이면 자동 발급), 이후에는 두 라이선스가 함께 존재합니다.

다음의 경우에 사용됩니다:

• rdc repo create, rdc repo fork, rdc repo commit: 프로비저닝 전에 검증됩니다 (확인 시점에는 저장소가 아직 존재하지 않으므로, 신원 증명 없이 사전 발급된 뒤 생성 후 신원 증명과 함께 재발급됩니다)
• rdc repo resize, rdc repo expand, rdc repo merge, rdc repo promote: 만료를 포함해 완전히 검증됩니다
• 백업 전송은 만료를 포함해 완전히 검증됩니다: rdc repo push, rdc repo pull, rdc repo migrate, 그리고 예약 백업
• rdc repo up, rdc repo up --all, rdc repo exec, 그리고 머신 재시작 시 저장소 자동 시작: 만료와 위임 인증서 유효 기간을 모두 생략하고 검증됩니다
• rdc repo down, rdc repo delete, 저장소 목록 조회 같은 읽기 전용 명령에는 라이선스가 전혀 필요하지 않습니다

서명, 키 바인딩, 머신 바인딩, 저장소 바인딩, 그리고 모든 위임 인증서 제약은 위 모든 경우에 강제됩니다. 마지막 그룹이 완화하는 것은 두 가지 기간 검사뿐이므로, 만료된 라이선스나 실효된 인증서 때문에 자신의 데이터를 시작하거나 종료하지 못하게 되는 일은 없습니다.

저장소 라이선스는 머신과 대상 저장소에 바인딩됩니다. 각 라이선스는 머신 ID, 저장소 GUID, 구독 ID, 요금제 제한, 만료를 포함합니다. 암호화된 저장소의 경우 Rediacc는 기본 볼륨의 LUKS 신원도 검증합니다.

여러 구독이 같은 머신에 공존할 수 있습니다. 각 저장소는 자체 구독 컨텍스트를 가진 자체 라이선스를 전달합니다.

클러스터

클러스터링은 Enterprise 계약의 일부로 파트너를 통해 판매됩니다. 셀프 서비스 요금제 옵션이 아니므로, 아래 내용은 구매 방법이 아니라 어떻게 계측되는지를 설명합니다.

노드는 곧 머신입니다. 클러스터 자체에는 별도의 라이선싱 신원이 없습니다. 클러스터에 속한 모든 노드는 Renet Agent가 설치된 일반 머신이며, 단독 머신과 정확히 같은 방식으로 계산됩니다.

풀링은 없습니다. 노드 다섯 개짜리 클러스터가 공유 클러스터 슬롯 하나를 나눠 쓰지 않습니다. 각 노드는 저장소가 처음 배치될 때 자신의 슬롯을 확보하며, 그 슬롯은 다른 슬롯과 똑같은 5시간 부동 방식을 따릅니다. 즉 해당 노드에서 마지막으로 저장소 라이선스가 발급된 시점부터 5시간 동안 유지되고, 그 뒤에는 스스로 해제됩니다.

클러스터를 구축하는 것은 무료이고, 계측되는 것은 저장소 배치입니다. 클러스터 생성, 노드 결합, 분산 스토리지 계층 설치, Kubernetes 컨트롤 플레인 구성에는 슬롯이 전혀 들지 않습니다. 계측은 저장소가 노드에 올라가는 시점부터 시작됩니다.

클러스터 포크는 저장소 단위로 다시 계측됩니다. 클러스터 전체를 포크하면 포크된 데이터스토어에 새 신원이 부여되므로, 포크 안의 각 저장소는 어느 노드에서 실행되든 처음 사용되는 시점에 자신의 라이선스를 발급받습니다. 단순 마이그레이션은 그 반대입니다. 저장소를 머신 사이로 옮기면 라이선스도 함께 따라가고 계속 검증을 통과하는데, 스토리지 신원이 전혀 바뀌지 않았기 때문입니다.

클러스터에서의 갱신은 위의 느슨한 확보 규칙을 따릅니다. 각 노드는 무인으로 자기 라이선스를 갱신하므로, 활성화 수를 넘어 커진 클러스터도 계속 동작하면서 상한을 초과한 노드를 보고합니다. 한밤중에 백업이 실패하는 일은 없습니다. 새 노드를 추가하는 것은 여전히 상한에서 막힙니다.

클러스터 규모 산정은 체크박스가 아니라 대화로 정하는 일입니다. 클러스터의 활성화 수는 주문에서 합의하며, 담당 파트너가 구독에 직접 설정합니다. 먼저 문의하기로 이야기를 시작해 주세요.

기본 제한

저장소 크기는 권리 수준에 따라 다릅니다:

• Community: 최대 10 GB
• 유료 요금제: 요금제 또는 계약 제한

기본 유료 요금제 제한:

Plan	Floating Licenses	Repository Size	Monthly repo license issuances	Delegation cert default / max
Community	1	10 GB	100	15d / 30d
Professional	1	100 GB	2,000+	60d / 120d
Business	1	500 GB	5,000+	90d / 180d
Enterprise	맞춤형	1 TB+	15,000+	120d / 365d

계약별 제한은 특정 고객을 위해 이러한 값을 높이거나 낮출 수 있습니다. 위임 인증서 유효성도 subscription.expiresAt + 3 day grace로 하드 캡되므로 월별 청구되는 구독은 자연스럽게 청구 주기에 맞춰진 인증서를 얻습니다. 전체 규칙은 License Chain & Delegation - Validity Policy를 참고하세요.

무료 체험판과 Community 폴백

신규 가입자는 Professional 또는 Business 요금제로 14일 무료 체험이 자동으로 시작됩니다. 가입 시 신용카드 정보를 등록하지만 실제 결제는 체험 기간이 끝날 때 처음 발생하므로, 그 전에 해지하면 비용이 전혀 들지 않습니다. 체험판은 고객 한 명당 한 번만 이용할 수 있습니다.

Community는 항상 존재하는 무료 기본 요금제입니다. 신규 계정이 바로 가입할 수 있는 옵션은 아니며, 대신 체험 중 해지, 이후 유료 요금제 해지, 결제 실패 등 구독이 종료될 때마다 계정이 Community로 전환됩니다. Community 폴백 상태에서는 머신 1대, 저장소당 10GB, 월 100회 설정이라는 제한이 적용됩니다. 체험판 기반 모델 도입 이전에 만들어진 계정은 기존 Community 접근 권한을 그대로 유지합니다.

제한 적용 방식은 가장 중요한 부분에서는 완만하게 유지됩니다. 구독이 종료되어도 실행 중인 저장소(up, down, delete, 자동 시작)는 계속 정상 작동합니다. 그 너머로는 서로 다른 두 가지 규칙이 적용되는데, 이 둘을 혼동하는 것이 60일 유예 기간이 일관성 없어 보이는 이유입니다.

• 계정 서버가 필요한 작업은 활성 구독 없이는 수행할 수 없습니다. 서버가 서명을 거부하기 때문입니다. create, fork, 그리고 모든 라이선스 새로 고침이나 갱신이 여기에 해당합니다. 구독이 만료되면 새로 프로비저닝되는 것은 아무것도 없습니다.
• 유효하게 설치된 라이선스만 있으면 되는 작업은 그 라이선스가 하드 만료될 때까지 서버 없이 계속 동작합니다. 이미 보유한 저장소에 대한 resize와 expand, 그리고 백업 전송(push, pull, 예약 백업)이 여기에 해당합니다. 저장소의 기본 라이선스는 구독 종료일로부터 60일 뒤에 하드 만료되며, 60일 유예 기간은 여기에서 나옵니다. 포크의 라이선스는 최대 7일로 훨씬 짧기 때문에, 포크를 많이 쓰는 머신은 아래에서 설명하는 자체 갱신에 의존합니다.

정리하면, 구독이 만료되면 플릿을 늘리는 것은 즉시 막히고, 그 안의 저장소를 키우는 것은 60일 뒤에 막힙니다.

VM 마이그레이션 유예 기간

호스팅 제공자가 VM을 다른 물리 하드웨어로 마이그레이션할 때 머신 ID가 변경됩니다 (DMI UUID, /etc/machine-id, NIC MAC 주소 같은 하드웨어 식별자에서 파생됨). 저장소 라이선스는 머신 ID에 바인딩되므로 마이그레이션은 일반적으로 모든 라이선스를 무효화합니다.

이를 투명하게 처리하기 위해 저장소 라이선스에는 40일 머신 ID 유예 기간이 포함됩니다. 머신 ID가 일치하지 않지만 라이선스가 40일 이내에 발급되었다면 라이선스는 여전히 수락됩니다. 라이선스가 30일마다 새로 고쳐지므로 다음 새로 고침이 자동으로 새 머신 ID에 바인딩합니다.

실제로는:

• VM 마이그레이션, 머신 ID 변경: 저장소는 계속 실행됨 (40일 창 내에서)
• 다음 rdc 작업이 새 머신 ID로 라이선스를 새로 고침
• 수동 개입 필요 없음
• rdc machine status <machine> --system --licenses으로 머신 ID 및 라이선스 상태 확인

Edge 채널 계정은 Community 요금제로 운영되며 제한이 2배로 늘어납니다 (20 GB 저장소, 월 200회 설정, 머신 2대). 유료 요금제는 Stable 채널에서만 사용할 수 있습니다. 자세한 내용은 Release Channels를 참고하세요.

저장소 생성, 시작, 중지, 재시작 중의 작동

저장소 생성 및 포크

저장소를 생성하거나 포크할 때:

1. rdc가 구독 토큰을 사용할 수 있는지 확인합니다 (필요하면 장치 코드 인증 트리거)
2. rdc가 계정 서버에서 저장소 라이선스를 사전 발급합니다 (서버는 이 시점에서 머신 슬롯 할당량과 월간 발급 제한을 확인함)
3. 사전 발급된 저장소 라이선스가 머신에 작성되고 로컬로 검증됩니다 (서명, 머신 ID, 저장소 GUID, 만료, 크기 제한)
4. 생성 성공 후, rdc가 저장소 신원 증명으로 저장소 라이선스를 재발급합니다 (LUKS UUID 또는 저장소 지문)

계정 백업 발급은 월간 저장소 라이선스 발급 사용량에 계산됩니다. 각 라이선스는 계정 소유자의 이메일과 회사명을 포함하며 renet이 라이선스를 검증할 때 기록됩니다.

저장소 시작, 중지, 삭제

rdc가 머신의 설치된 저장소 라이선스를 검증하지만 만료 검사를 생략합니다. 서명, 머신 ID, 저장소 GUID, 신원은 여전히 검증됩니다. 사용자는 만료된 구독이더라도 저장소를 운영할 수 없습니다.

저장소 크기 조정 및 확장

rdc는 만료 및 크기 제한을 포함한 전체 저장소 라이선스 검증을 수행합니다.

머신 재시작 및 자동 시작

자동 시작은 rdc repo up과 같은 규칙을 사용합니다: 만료는 생략되므로 저장소는 항상 자유롭게 재시작됩니다.

저장소 라이선스는 장기 유효성 모델을 사용합니다:

• refreshRecommendedAt는 소프트 새로 고침 포인트입니다
• hardExpiresAt는 차단 포인트입니다

저장소 라이선스가 오래되었지만 여전히 하드 만료 전이면 런타임이 계속될 수 있습니다. 하드 만료에 도달하면 rdc가 크기 조정/확장 작업을 위해 새로 고쳐야 합니다.

기타 저장소 작업

저장소 나열, 저장소 정보 검사, 마운트 같은 작업은 라이선스 검증이 필요하지 않습니다.

상태 확인 및 라이선스 새로 고침

사용자 로그인:

rdc subscription login

자동화 또는 AI 에이전트 로그인:

rdc subscription login --token "$REDIACC_TOKEN"

비대화형 환경의 경우 REDIACC_TOKEN을 설정하는 것이 가장 간단한 옵션입니다. 토큰은 에이전트가 필요한 구독 및 저장소 라이선스 작업만으로 범위를 지정해야 합니다.

계정 백업 구독 상태 표시:

rdc subscription status

한 머신의 머신 활성화 세부 정보 표시:

rdc subscription status -m hostinger

한 머신의 설치된 저장소 라이선스 세부 정보 표시:

rdc subscription status -m hostinger

머신에서 레포지토리의 라이선스 새로 고침:

rdc subscription refresh -m hostinger --repo my-app

--repo ref는 로컬 rdc 구성에서 확인될 수 있어야 합니다. 머신에서 발견되었지만 로컬 구성에서 누락된 레포지토리는 거부됩니다. 실패로 보고되며 자동으로 분류되지 않습니다.

처음 사용할 때 라이선스된 저장소 또는 백업 작업이 사용 가능한 저장소 라이선스를 찾지 못하면 계정 인증을 자동으로 트리거할 수 있습니다. CLI가 권한 부여 URL을 인쇄하고, 대화형 터미널에서 브라우저를 열려고 하며, 권한 부여 및 발급이 성공한 후 작업을 재시도합니다.

비대화형 환경에서 CLI는 브라우저 승인을 기다리지 않습니다. 대신 rdc subscription login --token ... 또는 REDIACC_TOKEN을 사용하여 범위가 지정된 토큰을 제공하도록 요청합니다.

처음 머신 설정의 경우 Machine Setup을 참고하세요.

라이선스 자체 갱신

지금까지의 내용은 모두 사람이 키보드 앞에 있다고 가정합니다. 예약 백업은 그렇지 않으며, 자체 갱신은 바로 그 경우를 위해 존재합니다.

예약 백업은 엄격한 계층에서 검증되므로 만료되지 않은 라이선스가 필요합니다. 그런데 포크의 라이선스는 최대 7일입니다. 머신은 설계상 계정 자격 증명을 전혀 보유하지 않기 때문에, 자체 갱신이 도입되기 전에는 포크의 백업이 생성 일주일 뒤 새벽 3시에 조용히 멈춰 있곤 했습니다.

토큰 없이 머신이 갱신하는 방법

Rediacc가 발급하거나 갱신하는 모든 라이선스에는 그 라이선스에 서명한 계정 서버의 갱신 엔드포인트 전체 주소가 renewalUrl로 담겨 있습니다. 머신은 그 주소를 자신에게 설치된 라이선스에서 읽어오므로, 계정 서버의 위치를 따로 알려줄 필요가 없습니다.

그다음 머신은 설치된 라이선스를 그 엔드포인트에 그대로 제시합니다. 라이선스 자체가 자격 증명입니다. 라이선스에는 서명이 있고 서버는 그 서명을 검증하며, 어디에도 API 토큰은 개입하지 않습니다. 서버는 새로운 유효 기간을 가진 라이선스를 반환하고, 머신은 그것을 설치한 뒤 다시 검증하고 나서야 갱신이 끝난 것으로 간주합니다.

갱신은 머신 전체를 대상으로 하는 작업입니다.

sudo renet license renew

저장소는 서명한 서버별로 묶이므로, 두 계정 유니버스를 함께 사용하는 머신은 각 서버에 한 번씩 연결합니다. 잠금 파일이 두 개의 갱신이 동시에 실행되는 것을 막고, --jitter는 그대로 두면 정각마다 한꺼번에 깨어날 머신들의 시점을 분산시킵니다.

서버가 갱신을 거부하는 경우는 세 가지이며, 각각 의미가 다릅니다.

거부 사유	무슨 뜻인가
구독이 만료되었거나, 정지되었거나, 유예 기간을 지났음	결제 문제입니다. 구독이 다시 활성화되면 갱신도 저절로 재개됩니다
위임 인증서가 만료되었거나 취소되었음	온프레미스 설정 문제입니다. 온프레미스 서버에서 인증서를 갱신하면 머신들은 정상적으로 갱신됩니다
머신 신원이 더 이상 일치하지 않고 40일 유예 기간도 지났음	그 라이선스는 다른 머신의 것입니다. 현재 머신 컨텍스트에서 재발급하세요

거부가 실행 전체를 중단시키지는 않습니다. 저장소 하나가 만료되었다고 해서 같은 머신의 다른 저장소 갱신이 막히지는 않습니다.

예약 백업은 스스로 갱신합니다

Rediacc가 작성하는 모든 백업 유닛은 갱신을 먼저 실행합니다.

ExecStartPre=-<renet> license renew --jitter 45s

앞의 -는 이 작업이 최선 노력임을 의도적으로 표시한 것입니다. 갱신 거부, 일시적인 네트워크 장애, 아직 이 명령을 모르는 구버전 Renet Agent가 백업 자체를 무너뜨려서는 안 되기 때문입니다. 백업은 실행되고, 라이선스는 가능할 때 그 과정에서 갱신됩니다.

백업이 차단되었을 때

라이선싱이 실제로 백업을 거부하면 머신이 이를 기록합니다. 이 표시는 무인 백업이 데이터 복사를 멈췄다는 사실을 알려주는 유일한 신호이므로 눈에 띄게 드러납니다.

rdc machine status <machine> --licenses

backups 열에는 사유와 함께 BLOCKED가 표시되고, 같은 정보가 표 아래에도 오류로 출력되어 저장소 서른 개 사이에 묻히지 않습니다. renewed 열은 마지막 무인 갱신이 어떻게 되었는지를, 서버가 거부한 경우에는 그 거부 코드까지 함께 보여줍니다. 이것이 해결해야 할 문제가 결제 문제인지 온프레미스 인증서 문제인지 알려줍니다.

갱신에 성공하면 표시가 지워지고, 라이선스 검사를 통과한 백업 역시 표시를 지웁니다. 손으로 확인하거나 초기화할 것은 없습니다.

오프라인 동작 및 만료

라이선스 검증은 머신에서 로컬로 발생합니다. 저장소를 운영하기 위해 계정 서버에 연결할 필요가 없습니다.

즉:

• 실행 중인 환경은 모든 명령에서 라이브 계정 연결이 필요하지 않습니다
• 모든 저장소는 만료된 라이선스가 있어도 항상 시작, 중지, 삭제될 수 있으며 사용자는 자신의 저장소 운영에서 결코 잠기지 않습니다
• 프로비저닝 작업 (create, fork)은 사전 발급된 저장소 라이선스가 필요하고 성장 작업 (resize, expand)은 유효한 저장소 라이선스가 필요합니다
• 정말로 만료된 저장소 라이선스는 크기 조정/확장 전에 교체해야 하며, 워크스테이션에서 rdc로 하거나 머신이 스스로 갱신하도록 하면 됩니다
• 라이선스 서명은 내장된 공개 키에 대해 검증되며 서명 검증을 비활성화할 수 없습니다

복구 동작

자동 복구는 의도적으로 제한적입니다.

• missing: rdc가 필요한 경우 account 접근을 인가하고, 저장소 라이선스를 일괄 갱신하며, 한 번 재시도할 수 있습니다.
• expired: rdc가 저장소 라이선스를 일괄 갱신하고 한 번 재시도할 수 있습니다.
• machine_mismatch: 빠르게 실패하고 현재 머신 컨텍스트에서 재발급하도록 안내합니다.
• repository_mismatch: 빠르게 실패하고 저장소 라이선스를 명시적으로 갱신하도록 안내합니다.
• sequence_regression: 저장소 라이선스 무결성/상태 문제로 빠르게 실패합니다.
• invalid_signature: 저장소 라이선스 무결성/상태 문제로 빠르게 실패합니다.
• identity_mismatch: 저장소 신원이 설치된 라이선스와 일치하지 않아 빠르게 실패합니다.
• cert_expired: 성장 작업(create, fork, resize)과 백업 전송(push, pull)에서는 즉시 실패합니다. repo up과 자동 시작은 계속 동작하며, 이는 소프트 라이선스 만료 모델과 동일합니다. 위임 인증서를 갱신하세요
• cert_invalid: 빠르게 실패합니다. 위임 인증서가 제약 조건을 충족하지 못했습니다(마스터 키 서명 오류, 구독/플랜 불일치, 크기 상한, 또는 maxTotalIssuances를 초과하는 시퀀스). 근본적인 한도를 수정한 뒤 인증서를 재발급하세요

이러한 빠른 실패 경우는 account 지원 갱신 또는 발급 호출을 자동으로 소비하지 않습니다.

이 목록을 읽을 때 참고할 점이 두 가지 있습니다.

• missing이 항상 문제인 것은 아닙니다. 갓 포크한 데이터스토어 안에서 저장소를 처음 사용할 때 나오는 정상적인 결과이기도 하며, 바로 그것이 그 포크를 계측되게 만듭니다. 라이선스가 발급되고, 슬롯이 확보되며, 작업은 그대로 이어집니다. identity_mismatch는 의도적으로 그 반대여서, 다른 데이터스토어에서 복사해 온 라이선스 파일은 조용히 재발급되지 않고 즉시 실패합니다.
• 이 목록이 설명하는 것은 워크스테이션에서의 복구입니다. 머신이 스스로 갱신할 때는 결과가 따로 있으며, 이는 명령 실패로 올라오는 대신 rdc machine status <machine> --licenses로 보고됩니다. 예약 백업에게는 알려줄 상대가 없기 때문입니다.

온프레미스를 위한 위임 인증서

온프레미스 및 에어갭 배포의 경우 업스트림 account 서버는 온프레미스 설치가 자체 Ed25519 키로 라이선스를 서명하도록 인가하는 위임 인증서를 발급합니다. 인증서는 온프레미스를 플랜 한도로 제한하고 변조 방지 체인을 생성합니다.

구독 소유자를 위한 주요 사항:

• 구독당 하나의 활성 인증서. 각 온프레미스 설치는 자체 로컬 원장에 대해 월별 및 머신별 할당량을 적용하므로 다중 설치는 조정 가능성 없이 효과적인 할당량을 곱합니다. 프로덕션 + 스테이징 + DR이 필요한 고객은 설치당 하나의 구독을 구매해야 합니다.
• 계층별 기본 유효성 (15일/60일/90일/120일) 및 상한 (30일/120일/180일/365일) - 위의 한도 표를 참조하십시오.
• 고객 포털에서 셀프 서비스. 조직 소유자와 관리자는 /account/delegation-certs에서 위임 인증서를 생성, 갱신, 취소할 수 있습니다. 페이지는 플랜 계층에 관계없이 모든 고객에게 표시됩니다. 한도만 다릅니다.
• 자동 갱신은 온프레미스가 업스트림 갱신 호출에 사용할 delegation:renew 범위의 API 토큰을 발급하는 원클릭 부트스트랩을 통해 지원됩니다.
• 에어갭 갱신은 온프레미스 관리자가 다운로드하여 오프라인으로 업스트림에 전송하고, 업스트림이 처리하여 새 인증서를 발급하는 서명된 갱신 요청 매니페스트를 통해 지원됩니다.

운영 설정은 온프레미스 설치 - 에어갭 배포를 위한 라이선싱을 참조하고, 암호화 설계는 라이선스 체인 및 위임을 참조하십시오.

월간 저장소 라이선스 발급

이 지표는 현재 UTC 역월의 성공적인 account 지원 저장소 라이선스 발급 활동을 계산합니다.

포함 항목:

• 최초 저장소 라이선스 발급
• 새로 서명된 라이선스를 반환하는 성공적인 저장소 라이선스 갱신

포함되지 않는 항목:

• 변경되지 않은 일괄 항목
• 실패한 발급 시도
• 발급 전에 거부된 추적되지 않는 저장소

사용량과 최근 저장소 라이선스 발급 이력의 고객용 보기가 필요하면 account 포털을 사용하십시오. 머신 측 검사가 필요하면 rdc subscription status -m 및 rdc subscription status -m을 사용하십시오.