다운타임 없이 다중 노드 인스턴스 업그레이드

Linux 패키지 기반의 다중 노드를 다운타임 없이 업그레이드.

다운타임 없이 다중 노드 GitLab 환경을 업그레이드하는 프로세스는 업그레이드 순서 에 따라 각 노드를 순차적으로 처리하는 것을 포함합니다. 로드 밸런서 및 HA 메커니즘은 각 노드가 다운되는 상황을 적절히 처리합니다. 다운타임 없이 업그레이드를 시작하기 전에 다운타임 옵션을 고려 하십시오. 시작하기 전에 # 업그레이드의 일부로 다운타임 제로를 달성하는 것은 분산 애플리케이션에서 특히 어렵습니다. 문서는 HA 참조 아키텍처 에 대해 테스트되었으며 사실상 관측 가능한 다운타임이 없었습니다. 그러나 특정 시스템 구성에 따라 결과가 다를 수 있음을 알고 있으십시오. 추가적인 확신을 위해 일부 고객은 특정 로드 밸런서 또는 인프라 기능을 사용하여 노드를 수동으로 드레인하는 것과 같은 추가 기술을 성공적으로 사용했습니다. 이러한 기술은 기본 인프라 기능에 크게 의존합니다. 추가 정보는 GitLab 담당자 또는 지원팀 에 문의하십시오. 요구 사항 # 다운타임 제로 업그레이드 프로세스는 다음과 같이 구성된 로드 밸런싱 및 사용 가능한 HA 메커니즘이 있는 Linux 패키지로 구축된 다중 노드 GitLab 환경이 필요합니다: readiness ( /-/readiness ) 엔드포인트에 대한 상태 확인이 활성화된 GitLab 애플리케이션 노드를 위한 외부 로드 밸런서. TCP 상태 확인이 활성화된 PgBouncer 및 Praefect 구성 요소를 위한 내부 로드 밸런서. 존재하는 경우 Consul, Postgres 및 Redis 구성 요소를 위해 구성된 HA 메커니즘. 이러한 구성 요소 중 HA 방식으로 배포되지 않은 것은 다운타임과 함께 별도로 업그레이드해야 합니다. 데이터베이스의 경우 Linux 패키지는 기본 GitLab 데이터베이스에 대한 HA만 지원 합니다. Praefect 데이터베이스 와 같은 다른 데이터베이스의 경우 HA를 달성하고 다운타임을 방지하기 위해 타사 데이터베이스 솔루션이 필요합니다. 다운타임 제로 업그레이드를 위해서는 다음을 수행해야 합니다: 한 번에 하나의 마이너 릴리스만 업그레이드 합니다. 따라서 16.1 에서 16.2 로, 16.3 으로는 건너뛰지 않습니다. 릴리스를 건너뛰면 데이터베이스 수정이 잘못된 순서로 실행되어 데이터베이스 스키마가 손상된 상태로 남을 수 있습니다 . 포스트 배포 마이그레이션을 사용합니다. 고려 사항 # 다운타임 제로 업그레이드를 고려할 때 다음을 알고 있으십시오: 대부분의 경우 패치 릴리스가 최신 버전이 아닌 경우 패치 릴리스에서 다음 마이너 릴리스로 안전하게 업그레이드할 수 있습니다. 예를 들어 16.3.3 이 릴리스된 경우에도 16.3.2 에서 16.4.1 로 업그레이드하는 것이 안전합니다. 업그레이드 경로 와 관련된 버전별 업그레이드 노트 를 확인하고 필수 업그레이드 중지 지점을 알고 있어야 합니다: GitLab 18 업그레이드 노트 GitLab 17 업그레이드 노트 GitLab 16 업그레이드 노트 GitLab 15 업그레이드 노트 일부 릴리스에는 백그라운드 마이그레이션이 포함될 수 있습니다