두 개의 단일 노드 사이트용 Geo 설정

Tier: Premium, Ultimate Offering: Self-managed

다음 가이드에서는 외부 서비스를 설정하지 않은 두 Linux 패키지 인스턴스를 사용하여 두 개의 단일 노드 사이트 설치에 대한 GitLab Geo를 배포하는 간결한 지침을 제공합니다.

필수 조건:

  • 독립적으로 작동하는 GitLab 사이트가 적어도 두 개 있어야 합니다. 사이트를 만들려면 GitLab 참조 아키텍처 문서를 참조하세요.
    • 하나의 GitLab 사이트는 Geo 기본 사이트로 작동합니다. 각 Geo 사이트에 대해 다른 참조 아키텍처 사이즈를 사용할 수 있습니다. 이미 작동 중인 GitLab 인스턴스가 있는 경우 해당 사이트를 기본 사이트로 사용할 수 있습니다.
    • 두 번째 GitLab 사이트는 Geo 보조 사이트로 작동합니다. Geo는 여러 보조 사이트를 지원합니다.
  • Geo 기본 사이트에는 GitLab Premium 라이선스가 필요합니다. 모든 사이트에 하나의 라이선스만 필요합니다.
  • 모든 사이트가 Geo 실행 요구 사항을 충족하는지 확인하세요.

Linux 패키지용 Geo 설정 (Omnibus)

필수 조건:

  • PostgreSQL 12 이상을 사용해야 합니다. 이에는 pg_basebackup 도구가 포함됩니다.

기본 사이트 구성

  1. GitLab 기본 사이트에 SSH로 로그인하여 루트 사용자로 전환합니다. 

    sudo -i

  2. /etc/gitlab/gitlab.rb에 고유한 Geo 사이트 이름을 추가합니다. 

    ##
## Geo 사이트의 고유 식별자. 자세한 정보는
## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings을 참조하세요.
##
gitlab_rails['geo_node_name'] = '<site_name_here>'

  3. 변경 사항을 적용하려면 기본 사이트를 다시 구성합니다. 

    gitlab-ctl reconfigure

  4. 사이트를 기본 Geo 사이트로 정의합니다. 

    gitlab-ctl set-geo-primary-node

    이 명령은 /etc/gitlab/gitlab.rb에서 정의된 external_url을 사용합니다.

  5. gitlab 데이터베이스 사용자를 위해 암호를 생성합니다.

    1. 원하는 암호의 MD5 해시를 생성합니다. 

      gitlab-ctl pg-password-md5 gitlab
# 암호 입력: <your_password_here>
# 암호 확인: <your_password_here>
# fca0b89a972d69f00eb3ec98a5838484

    2. /etc/gitlab/gitlab.rb를 편집합니다. 

      # `gitlab-ctl pg-password-md5 gitlab`에 의해 생성된 해시로 채웁니다.
postgresql['sql_user_password'] = '<md5_hash_of_your_password>'
      
# Puma 또는 Sidekiq를 실행하는 모든 노드는 다음과 같이 데이터베이스
# 암호를 지정해야 합니다. 고가용성 설정을 사용하는 경우 모든 애플리케이션 노드에
# 이 설정이 있어야 합니다.
gitlab_rails['db_password'] = '<your_password_here>'

  6. 데이터베이스 복제 사용자를 위한 암호를 정의합니다. postgresql['sql_replication_user'] 설정 아래에서 정의된 사용자를 사용합니다. 기본값은 gitlab_replicator입니다.

    1. 원하는 암호의 MD5 해시를 생성합니다. 

      gitlab-ctl pg-password-md5 gitlab_replicator
      
# 암호 입력: <your_password_here>
# 암호 확인: <your_password_here>
# 950233c0dfc2f39c64cf30457c3b7f1e

    2. /etc/gitlab/gitlab.rb를 편집합니다. 

      # `gitlab-ctl pg-password-md5 gitlab_replicator`에 의해 생성된 해시로 채웁니다.
postgresql['sql_replication_password'] = '<md5_hash_of_your_password>'

    3. 선택 사항. Linux 패키지로 관리되지 않는 외부 데이터베이스를 사용하는 경우 해당 데이터베이스에 대해 gitlab_replicator 사용자를 만들고 해당 사용자에 대한 암호를 매뉴얼으로 정의해야 합니다. 

      --- 새 사용자 'replicator' 만들기
CREATE USER gitlab_replicator;
      
--- 암호 설정 및 복제 권한 부여
ALTER USER gitlab_replicator WITH REPLICATION ENCRYPTED PASSWORD '<replication_password>';

  7. /etc/gitlab/gitlab.rb에서 geo_primary_role을 사용하여 역할을 설정합니다. 

    ## Geo 기본 역할
roles(['geo_primary_role'])

  8. PostgreSQL이 네트워크 인터페이스에서 수신하도록 구성합니다.

    1. Geo 사이트의 주소를 찾으려면 Geo 사이트로 SSH하여 다음 명령을 실행합니다. 

      ##
## 사설 주소
##
ip route get 255.255.255.255 | awk '{print "사설 주소:", $NF; exit}'
      
##
## 공용 주소
##
echo "외부 주소: $(curl --silent "ipinfo.io/ip")"

      대부분의 경우, 다음과 같은 주소를 사용하여 GitLab Geo를 구성합니다:

      구성 주소
      postgresql['listen_address'] 기본 사이트의 공용 또는 VPC 사설 주소.
      postgresql['md5_auth_cidr_addresses'] 기본 및 보조 사이트의 공용 또는 VPC 사설 주소.

      Google Cloud Platform, SoftLayer 또는 기타 VPC(가상 사설망)를 제공하는 공급업체인 경우, 기본 및 보조 사이트의 사설 주소(구글 클라우드 플랫폼의 “내부 주소”에 해당)를 postgresql['md5_auth_cidr_addresses'] 및 postgresql['listen_address']에 사용할 수 있습니다.

      note
      listen_address로 0.0.0.0 또는 *를 사용해야 하는 경우, postgresql['md5_auth_cidr_addresses'] 설정에 127.0.0.1/32을 추가하여 Rails가 127.0.0.1을 통해 연결할 수 있도록 해야 합니다. 자세한 정보는 issue 5258를 참조하세요.

      네트워크 구성에 따라 제안된 주소가 잘못될 수 있습니다. 기본 및 보조 사이트가 로컬 영역 네트워크 또는 Amazon의 VPC 또는 Google의 VPC 같은 가용성 영역을 연결하는 가상 네트워크를 통해 연결되는 경우, postgresql['md5_auth_cidr_addresses']에 보조 사이트 사설 주소를 사용해야 합니다.

    2. /etc/gitlab/gitlab.rb에 다음 라인을 추가합니다. IP 주소를 자신의 네트워크 구성에 맞게 교체하세요. 

      ##
## 기본 주소
## - '<primary_node_ip>'를 기본 사이트의 공용 또는 VPC 주소로 교체하세요.
##
postgresql['listen_address'] = '<primary_site_ip>'
      
##
# PostgreSQL 클라이언트 인증을 기본 및 보조 IP에서 허용합니다. 이 IP는
# CIDR 형식의 공용 또는 VPC 주소일 수 있습니다. 예: ['198.51.100.1/32', '198.51.100.2/32']
##
postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']

  9. 임시로 자동 데이터베이스 마이그레이션을 비활성화하여 PostgreSQL이 재시작되고 사설 주소에서 수신 대기할 때까지 적용합니다. /etc/gitlab/gitlab.rb에서 gitlab_rails['auto_migrate']를 false로 설정합니다. 

    ## 자동 데이터베이스 마이그레이션 비활성화
gitlab_rails['auto_migrate'] = false

  10. 이러한 변경 사항을 적용하려면 GitLab을 다시 구성하고 PostgreSQL을 다시 시작합니다. 

    gitlab-ctl reconfigure
gitlab-ctl restart postgresql

  11. 마이그레이션을 다시 활성화하려면 /etc/gitlab/gitlab.rb를 편집하고 gitlab_rails['auto_migrate']를 true로 변경합니다. 

    gitlab_rails['auto_migrate'] = true

    파일을 저장하고 GitLab을 다시 구성합니다. 

    gitlab-ctl reconfigure

    PostgreSQL 서버가 원격 연결을 수락하도록 설정됩니다.

  12. netstat -plnt | grep 5432를 실행하여 PostgreSQL이 기본 사이트의 사설 주소에서 포트 5432에서 수신 대기하는지 확인합니다.

  13. PostgreSQL 트래픽을 자동으로 보호하기 위해 인증서가 자동으로 생성되었습니다. 이 인증서는 PostgreSQL 트래픽을 도청자로부터 자동으로 보호하는 데 사용됩니다. 무차별 대입 공격자로부터 보호하기 위해 인증서를 보조 사이트로 복사합니다.

    1. 기본 사이트에서 server.crt의 사본을 만듭니다. 

      cat ~gitlab-psql/data/server.crt

    2. 나중에 보조 사이트를 구성할 때 출력을 저장합니다. 인증서는 민감한 데이터가 아닙니다.

    이 인증서는 일반적인 PostgreSQL 공용 이름으로 생성됩니다. 호스트 이름 불일치 오류를 방지하기 위해 데이터베이스를 복제할 때 verify-ca 모드를 사용해야 합니다.

보조 서버 구성

  1. GitLab 보조 사이트에 SSH로 로그인하고 root로 로그인합니다. 

    sudo -i

  2. 사이트가 구성되기 전에 어떤 명령도 실행되지 않도록 하기 위해 애플리케이션 서버와 Sidekiq를 중지합니다. 

    gitlab-ctl stop puma
gitlab-ctl stop sidekiq

  3. 주 사이트 PostgreSQL 서버와의 TCP 연결을 확인합니다. 여기를 클릭하여 확인할 수 있습니다. 

    gitlab-rake gitlab:tcp_check[<primary_site_ip>,5432]

    만약 이 단계가 실패하면, 올바르지 않은 IP 주소를 사용하고 있는지 또는 방화벽이 사이트 접근을 막고 있는 것일 수 있습니다. 공용 및 사설 주소의 차이에 주의하십시오. 방화벽이 있으면, 보조 사이트가 5432번 포트에서 주 사이트에 연결할 수 있도록 허용되었는지 확인하십시오.

  4. 보조 사이트에서 server.crt라는 파일을 생성하고, 주 사이트를 구성할 때 만든 인증서의 사본을 추가합니다. 

    editor server.crt

  5. 보조 사이트에서 PostgreSQL TLS 검증을 설정하려면 server.crt를 설치합니다. 

    install \
   -D \
   -o gitlab-psql \
   -g gitlab-psql \
   -m 0400 \
   -T server.crt ~gitlab-psql/.postgresql/root.crt

    이제 PostgreSQL은 TLS 연결을 확인할 때 정확히 이 인증서만 인식합니다. 이 인증서는 주 사이트에만 존재하는 개인 키에 액세스 권한이 있는 사람에 의해 복제될 수 있습니다.

  6. gitlab-psql 사용자가 주 사이트 데이터베이스에 연결할 수 있는지 테스트합니다. 기본 리눅스 패키지 이름은 gitlabhq_production입니다. 

    sudo \
   -u gitlab-psql /opt/gitlab/embedded/bin/psql \
   --list \
   -U gitlab_replicator \
   -d "dbname=gitlabhq_production sslmode=verify-ca" \
   -W \
   -h <primary_site_ip>

    프롬프트가 나타나면, gitlab_replicator 사용자에게 설정한 일반 텍스트 암호를 입력하십시오. 모든 것이 올바르게 작동했다면, 주 사이트 데이터베이스 디렉터리이 표시됩니다.

  7. /etc/gitlab/gitlab.rb를 편집하고 역할을 geo_secondary_role로 설정합니다. 

    ##
## Geo Secondary 역할
## - 종속 플래그를 자동으로 구성하여 Geo를 활성화합니다.
##
roles(['geo_secondary_role'])

    자세한 정보는 Geo roles를 참조하십시오.

  8. PostgreSQL을 구성하려면 /etc/gitlab/gitlab.rb를 편집하고 다음을 추가합니다. 

    ##
## 보조 주소
## - 'secondary_site_ip'를 여러분의 Geo 보조 사이트의 공용 또는 VPC 주소로 대체합니다.
##
postgresql['listen_address'] = '<secondary_site_ip>'
postgresql['md5_auth_cidr_addresses'] = ['<secondary_site_ip>/32']
   
##
## 데이터베이스 자격 증명 암호 (이전에 주 사이트에서 정의함)
## - 주 사이트에서 정의한 것과 동일한 값을 여기에 복제합니다.
##
postgresql['sql_replication_password'] = '<your_password_here>'
postgresql['sql_user_password'] = '<your_password_here>'
gitlab_rails['db_password'] = '<your_password_here>'

    IP 주소를 여러분의 네트워크 구성에 맞는 주소로 교체해야 합니다.

  9. 변경 사항을 적용하려면 GitLab을 다시 구성합니다. 

    gitlab-ctl reconfigure

  10. IP 주소 변경을 적용하려면 PostgreSQL을 다시 시작합니다. 

    gitlab-ctl restart postgresql

데이터베이스 복제

보조 사이트의 데이터베이스를 주 사이트의 데이터베이스에 연결합니다. 아래 스크립트를 사용하여 데이터베이스를 복제하고 스트리밍 복제에 필요한 파일을 만들 수 있습니다.

이 스크립트는 기본 리눅스 패키지 디렉터리를 사용합니다. 여러분이 기본값을 변경했다면, 아래 스크립트에서 디렉터리 및 경로 이름을 여러분의 것으로 바꿔야 합니다.

caution
복제 스크립트는 보조 사이트에서만 실행해야 합니다. 스크립트는 pg_basebackup을 실행하기 전에 모든 PostgreSQL 데이터를 제거하므로 데이터 손실이 발생할 수 있습니다.

데이터베이스를 복제하려면 다음을 수행합니다:

  1. GitLab 보조 사이트에 SSH로 로그인하고 root로 로그인합니다. 

    sudo -i

  2. 복제 슬롯 이름으로 사용할 데이터베이스 친화적인 이름을 선택합니다. 예를 들어, 여러분의 도메인이 secondary.geo.example.com이면, secondary_example을 슬롯 이름으로 사용하십시오. 복제 슬롯 이름은 소문자, 숫자 및 밑줄 문자만 포함해야 합니다.

  3. 다음 명령을 실행하여 데이터베이스를 백업하고 복원하고 복제를 시작합니다.

    caution
    각 Geo 보조 사이트는 고유한 복제 슬롯 이름을 가져야 합니다. 두 개의 보조 사이트 간에 동일한 슬롯 이름을 사용하면 PostgreSQL 복제가 손상됩니다.
    gitlab-ctl replicate-geo-database \
   --slot-name=<secondary_site_name> \
   --host=<primary_site_ip> \
   --sslmode=verify-ca

    프롬프트가 나타나면, gitlab_replicator에 대해 설정한 일반 텍스트 암호를 입력하십시오.

복제 프로세스가 완료되었습니다.

새로운 보조 사이트 구성

복제 프로세스가 완료되면, 인증된 SSH 키의 빠른 조회를 구성해야 합니다.

note
인증은 주 사이트에서 처리됩니다. 보조 사이트에 사용자 지정 인증을 설정하지 마십시오. 관리 영역에 액세스하는 모든 변경은 보조 사이트가 읽기 전용 복사본이기 때문에 주 사이트에서 이루어져야 합니다.

GitLab의 비밀 값 매뉴얼 복제

GitLab은 /etc/gitlab/gitlab-secrets.json에 여러 비밀 값을 저장합니다. 이 JSON 파일은 각 사이트 노드 모두에서 동일해야 합니다. issue 3789에서 이 동작을 변경하기로 제안되었지만, 현재는 여러분이 모든 보조 사이트에 매뉴얼으로 비밀 파일을 복제해야 합니다.

  1. 주 사이트의 Rails 노드에 SSH로 로그인하고 아래 명령을 실행합니다. 

    sudo cat /etc/gitlab/gitlab-secrets.json

    이 명령은 JSON 형식으로 표시된 복제해야 하는 비밀 값을 표시합니다.

  2. 보조 Geo 사이트의 각 노드에 SSH로 로그인하고 root로 로그인합니다. 

    sudo -i

  3. 기존 비밀 값의 백업을 만듭니다. 

    mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`

  4. 주 사이트 Rails 노드에서 /etc/gitlab/gitlab-secrets.json을 각 보조 사이트 노드로 복사합니다. 또는 파일 내용을 노드 간에 복사하여 붙여넣을 수도 있습니다. 

    sudo editor /etc/gitlab/gitlab-secrets.json
   
# 주 사이트에서 실행했던 `cat` 명령의 출력을 붙여넣습니다.
# 저장하고 종료합니다.

  5. 파일 권한이 올바른지 확인합니다. 

    chown root:root /etc/gitlab/gitlab-secrets.json
chmod 0600 /etc/gitlab/gitlab-secrets.json

  6. 변경 사항을 적용하려면 각 Rails, Sidekiq 및 Gitaly 보조 사이트 노드에서 다시 구성하고 다시 시작합니다. 

    gitlab-ctl reconfigure
gitlab-ctl restart

기본 사이트 SSH 호스트 키 매뉴얼 복제

  1. 보조 사이트의 각 노드에 SSH로 로그인하고 root로 로그인합니다. 

    sudo -i

  2. 기존 SSH 호스트 키를 백업합니다. 

    find /etc/ssh -iname 'ssh_host_*' -exec cp {} {}.backup.`date +%F` \;

  3. 기본 사이트에서 OpenSSH 호스트 키를 복사합니다.

    • 보통 SSH 트래픽을 제공하는 기본 사이트 노드 중 하나에 root로 액세스할 수 있는 경우(일반적으로 주요 GitLab Rails 애플리케이션 노드): 

      # 보조 사이트에서 실행하며, '<primary_site_fqdn>'을 서버의 IP 또는 FQDN으로 변경합니다.
scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh

    • sudo 권한이 있는 사용자를 통해 액세스할 수 있는 경우: 

      # 기본 사이트의 노드에서 실행합니다.
sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key*
     
# 각 보조 사이트 노드에서 실행합니다.
scp <user_with_sudo>@<primary_site_fqdn>:geo-host-key.tar.gz .
tar zxvf ~/geo-host-key.tar.gz -C /etc/ssh

  4. 각 보조 사이트 노드에 대해 파일 권한이 올바른지 확인합니다. 

    chown root:root /etc/ssh/ssh_host_*_key*
chmod 0600 /etc/ssh/ssh_host_*_key

  5. 키 핑거프린트가 일치하는지 확인하려면, 각 사이트의 기본 및 보조 노드에서 다음 명령을 실행합니다. 

    for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done

    두 노드에서 동일한 출력을 얻어야 합니다.

  6. 기존 개인 키에 대한 올바른 공개 키를 확인합니다. 

    # 개인 키의 핑거프린트를 출력합니다.
for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
   
# 공개 키의 핑거프린트를 출력합니다.
for file in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $file; done

    공개 및 개인 키 명령의 출력은 동일한 핑거프린트를 생성해야 합니다.

  7. 각 보조 사이트 노드에 대해 sshd를 다시 시작합니다. 

    # Debian 또는 Ubuntu 설치
sudo service ssh reload
   
# CentOS 설치
sudo service sshd reload

  8. SSH가 여전히 작동하는지 확인하기 위해 새 터미널에서 GitLab 보조 서버로 SSH로 들어갑니다. 연결할 수 없는 경우, 올바른 권한을 가지고 있는지 확인합니다.

보조 사이트 추가

  1. 보조 사이트의 각 Rails 및 Sidekiq 노드에 SSH로 로그인하고 root로 로그인합니다. 

    sudo -i

  2. /etc/gitlab/gitlab.rb를 편집하고 사이트에 대한 고유한 이름을 추가합니다. 

    ##
## Geo 사이트에 대한 고유 식별자. 
## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings 참조
##
gitlab_rails['geo_node_name'] = '<site_name_here>'

    다음 단계에 대한 고유 이름을 저장합니다.

  3. 변경 사항을 적용하기 위해 보조 사이트의 각 Rails 및 Sidekiq 노드를 다시 구성합니다. 

    gitlab-ctl reconfigure
  4. 기본 노드 GitLab 인스턴스로 이동합니다:
    1. 왼쪽 사이드바에서 맨 아래에서 관리자 영역을 선택합니다.
    2. Geo > 사이트를 선택합니다.

    3. 사이트 추가를 선택합니다.

      보조 사이트 추가

    4. 이름에는 /etc/gitlab/gitlab.rb의 gitlab_rails['geo_node_name'] 값 입력합니다. 두 값은 정확히 일치해야 합니다.
    5. 외부 URL에는 /etc/gitlab/gitlab.rb의 external_url 값 입력합니다. 둘 중 하나의 값이 ‘/’로 끝나도 상관없습니다. 그렇지 않은 경우, 두 값은 정확히 일치해야 합니다.
    6. (선택사항) 내부 URL(선택 사항)에는 기본 사이트의 내부 URL을 입력합니다.
    7. (선택사항) 보조 사이트에서 복제할 그룹 또는 리포지터리 샤드를 선택합니다. 모두 복제하려면 빈 칸으로 둡니다. 선택적 동기화 참조
    8. 변경 사항 저장 선택합니다.

  5. 보조 사이트의 각 Rails 및 Sidekiq 노드에 SSH로 로그인하고 서비스를 다시 시작합니다. 

    gitlab-ctl restart

  6. GitLab Geo 설정에 대한 일반 문제를 확인하려면 다음을 실행하여 공통 문제가 있는지 확인합니다. 

    gitlab-rake gitlab:geo:check

    모든 확인 사항에 실패하는 경우, 문제 해결 문서를 참조하십시오.

  7. 보조 사이트에 도달할 수 있는지 확인하려면 기본 사이트의 Rails 또는 Sidekiq 서버로 SSH로 로그인하고 root로 로그인합니다. 

    gitlab-rake gitlab:geo:check

    확인 사항 중 하나라도 실패하는 경우, 문제 해결 문서를 확인하십시오.

보조 사이트가 Geo 관리 페이지에 추가되고 다시 시작된 후, 해당 사이트는 기본 사이트에서 누락된 데이터를 자동으로 복제하여 백필(fill) 프로세스를 시작합니다.

한편, 기본 사이트는 각 보조 사이트에게 변경 사항을 즉시 알리기 시작하여 보조 사이트가 즉시 조치할 수 있도록 합니다.

보조 사이트가 실행되고 접근 가능한지 확인하세요. 기본 사이트에서 사용한 것과 동일한 자격 증명으로 보조 사이트에 로그인할 수 있습니다.

HTTP/HTTPS 및 SSH를 통한 Git 액세스 활성화

Geo는 리포지터리를 HTTP/HTTPS를 통해 동기화하므로 이 클론 방법을 활성화해야 합니다. 이것은 기본적으로 활성화되어 있습니다. 기존 사이트를 Geo로 변환하는 경우 클론 방법이 활성화되어 있는지 확인해야 합니다.

기본 사이트에서:

  1. 왼쪽 사이드바에서 아래쪽에 있는 관리 영역을 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 가시성 및 액세스 제어를 확장합니다.
  4. SSH를 통해 Git을 사용하는 경우:
    1. 활성화된 Git 액세스 프로토콜이 SSH 및 HTTP(S)로 설정되어 있는지 확인합니다.
    2. 기본 사이트와 보조 사이트에서 데이터베이스 내의 SSH 키 빠른 조회를 따릅니다.
  5. Git을 SSH로 사용하지 않는 경우, 활성화된 Git 액세스 프로토콜을 HTTP(S)만으로 설정합니다.

보조 사이트의 올바른 작동 확인

기본 사이트에서 사용한 자격증명으로 보조 사이트에 로그인할 수 있습니다.

로그인한 후:

  1. 왼쪽 사이드바에서 아래쪽에 있는 관리 영역을 선택합니다.
  2. Geo > 사이트를 선택합니다.
  3. 사이트가 올바르게 보조 Geo 사이트로 식별되고 Geo가 활성화되었는지 확인합니다.

초기 복제에는 시간이 걸릴 수 있습니다. 기본 사이트의 브라우저에서 Geo 사이트 대시보드에서 각 Geo 사이트의 동기화 프로세스를 모니터링할 수 있습니다.

Geo 대시보드

관련 주제