두 개의 단일 노드 사이트를 위한 Geo 설정

Tier: Premium, Ultimate Offering: Self-Managed

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

필수 컴포넌트:

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

Linux 패키지(Omnibus)를 위한 Geo 설정

필수 컴포넌트:

기본 사이트 구성

  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'] = '<사이트_이름_여기에>'

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

    gitlab-ctl reconfigure

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

    gitlab-ctl set-geo-primary-node

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

  5. gitlab 데이터베이스 사용자에 대한 비밀번호를 생성하고 Rail에서 새 비밀번호를 사용하도록 설정합니다.

    note
    gitlab_rails['db_password'] 및 postgresql['sql_user_password'] 설정에 구성된 값이 일치해야 합니다. 그러나 postgresql['sql_user_password'] 값은 MD5로 암호화된 비밀번호여야 합니다. 이에 대한 변경 사항은 PostgreSQL 암호를 쿡북에서 어떻게 처리할지 재고해야 함에서 논의 중입니다.

    1. 원하는 비밀번호의 MD5 해시를 생성합니다: 

      gitlab-ctl pg-password-md5 gitlab
# Enter password: <여기에_귀하의_db_비밀번호_입력>
# Confirm password: <여기에_귀하의_db_비밀번호_입력>
# fca0b89a972d69f00eb3ec98a5838484

    2. /etc/gitlab/gitlab.rb을 편집합니다: 

      # `gitlab-ctl pg-password-md5 gitlab`에 의해 생성된 해시로 채우기
postgresql['sql_user_password'] = '<귀하의_db_비밀번호_여기에_해시_넣기>'
      
# Puma 또는 Sidekiq를 실행하는 모든 노드는 아래와 같이 데이터베이스 비밀번호를 지정해야 합니다. 고가용성 설정이 있는 경우 모든 응용 프로그램 노드에 이 설정이 있어야 합니다.
gitlab_rails['db_password'] = '<귀하의_db_비밀번호_여기에>'

  6. 데이터베이스 복제 사용자에 대한 비밀번호를 정의합니다. /etc/gitlab/gitlab.rb에서 postgresql['sql_replication_user'] 하위의 사용자 이름을 사용합니다. 기본값은 gitlab_replicator입니다.

    1. 원하는 비밀번호의 MD5 해시를 생성합니다: 

      gitlab-ctl pg-password-md5 gitlab_replicator
      
# Enter password: <여기에_복제_비밀번호_입력>
# Confirm password: <여기에_복제_비밀번호_입력>
# 950233c0dfc2f39c64cf30457c3b7f1e

    2. /etc/gitlab/gitlab.rb을 편집합니다: 

      # `gitlab-ctl pg-password-md5 gitlab_replicator`에 의해 생성된 해시로 채우기
postgresql['sql_replication_password'] = '<복제_비밀번호_여기에_해시_넣기>'

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

      --- 새 사용자 'replicator' 생성
CREATE USER gitlab_replicator;
      
--- 비밀번호 설정/변경 및 복제 권한 부여
ALTER USER gitlab_replicator WITH REPLICATION ENCRYPTED PASSWORD '<복제_비밀번호>';

  7. /etc/gitlab/gitlab.rb에서 geo_primary_role을 역할로 설정합니다: 

    ## Geo Primary 역할
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
      0.0.0.0 또는 *를 listen_address로 사용해야 하는 경우 postgresql['md5_auth_cidr_addresses'] 설정에 127.0.0.1/32를 추가하여 Rails가 127.0.0.1을 통해 연결할 수 있도록 설정해야 합니다. 자세한 내용은 이슈 5258을 참조하십시오.

    2. /etc/gitlab/gitlab.rb에 다음 라인을 추가합니다. IP 주소는 네트워크 구성에 맞게 적절한 주소로 대체하십시오: 

      ##
## 기본 주소
## - '<기본_노드_ip>'를 기본 Geo 노드의 공용 또는 VPC 주소로 대체하십시오
##
postgresql['listen_address'] = '<기본_사이트_ip>'
      
##
# 기본 및 보조 IP에서 PostgreSQL 클라이언트 인증 허용. 이 IP는 CIDR 형식으로 공용 또는 VPC 주소여야 합니다. 예: ['198.51.100.1/32', '198.51.100.2/32']
##
postgresql['md5_auth_cidr_addresses'] = ['<기본_사이트_ip>/32', '<보조_사이트_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 트래픽을 자동으로 보호하기 위해 인증된 SSL/TLS 연결을 사용하여 인증서가 자동으로 생성되었습니다. 액티브(중간자) 공격자로부터 보호하려면 인증서를 보조 사이트로 복사합니다:

    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 연결을 확인합니다: 기본 사이트 PostgreSQL 서버에 대한 TCP 연결 확인 

    gitlab-rake gitlab:tcp_check[<기본 사이트 IP>,5432]

    이 단계에서 실패하면 잘못된 IP 주소를 사용하거나 방화벽이 사이트 접근을 방해할 수 있습니다. 공용 및 사설 주소 간의 차이에 주의하여 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 사용자가 기본 사이트 데이터베이스에 연결할 수 있는지 테스트합니다. 기본 Linux 패키지 이름은 gitlabhq_production입니다. 

    sudo \
   -u gitlab-psql /opt/gitlab/embedded/bin/psql \
   --list \
   -U gitlab_replicator \
   -d "dbname=gitlabhq_production sslmode=verify-ca" \
   -W \
   -h <기본 사이트 IP>

    프롬프트가 표시되면 gitlab_replicator 사용자의 일반 텍스트 암호를 입력합니다. 정상적으로 작동했다면 기본 사이트 데이터베이스 디렉터리이 표시됩니다.

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

    ##
## Geo Secondary role
## - configure dependent flags automatically to enable Geo
##
roles(['geo_secondary_role'])

    자세한 내용은 Geo roles을 참조하세요.

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

    ##
## Secondary address
## - replace '<secondary_site_ip>' with the public or VPC address of your Geo secondary site
##
postgresql['listen_address'] = '<보조 사이트 IP>'
postgresql['md5_auth_cidr_addresses'] = ['<보조 사이트 IP>/32']
   
##
## Database credentials password (defined previously in primary site)
## - replicate same values here as defined in primary site
##
postgresql['sql_replication_password'] = '<복제 암호의 md5 해시>'
postgresql['sql_user_password'] = '<데이터베이스 암호의 md5 해시>'
gitlab_rails['db_password'] = '<여기에 데이터베이스 암호 입력>'

    IP 주소를 네트워크 구성에 적합한 주소로 교체하세요.

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

    gitlab-ctl reconfigure

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

    gitlab-ctl restart postgresql

데이터베이스 복제

보조 사이트의 데이터베이스를 기본 사이트의 데이터베이스에 연결합니다. 다음 스크립트를 사용하여 데이터베이스를 복제하고 스트리밍 복제에 필요한 파일을 생성할 수 있습니다.

이 스크립트는 기본 Linux 패키지 디렉터리를 사용합니다. 기본값을 변경했다면 아래 스크립트의 디렉터리 및 경로 이름을 고유한 이름으로 대체하세요.

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=<보조 사이트 이름> \
   --host=<기본 사이트 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 애플리케이션 노드): 

      # 보조 사이트에서 실행, 서버의 IP 또는 FQDN에 맞게 `<기본 사이트_fqdn>`을 변경하세요
scp root@<기본 노드_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 <sudo 권한이 있는 사용자>@<기본 사이트_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

    출력은 다음과 유사해야 합니다. 

    1024 SHA256:FEZX2jQa2bcsd/fn/uxBzxhKdx4Imc4raXrHwsbtP0M root@serverhostname (DSA)
256 SHA256:uw98R35Uf+fYEQ/UnJD9Br4NXUFPv7JAUln5uHlgSeY root@serverhostname (ECDSA)
256 SHA256:sqOUWcraZQKd89y/QQv/iynPTOGQxcOTIXU/LsoPmnM root@serverhostname (ED25519)
2048 SHA256:qwa+rgir2Oy86QI+PZi/QVR+MSmrdrpsuH7YyKknC+s root@serverhostname (RSA)

    공개 및 개인 키에 대해 올바른 지문이 생성되어야 합니다.

  6. 각 보조 사이트 노드에서 sshd를 재시작합니다. 

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

  7. 새 터미널에서 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. Geo 설정에 문제가 있는지 확인하기 위해 다음을 실행하여 공통 문제가 있는지 확인합니다. 

    gitlab-rake gitlab:geo:check

    모든 확인 사항이 실패하는 경우 문제 해결 문서를 참조하세요.

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

    gitlab-rake gitlab:geo:check

    확인 사항 중 어느 것이 실패하는 경우 문제 해결 문서를 확인하세요.

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

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

보조 사이트가 실행되고 액세스할 수 있는지 확인하십시오. 기본 사이트와 동일한 자격 증명으로 보조 사이트에 로그인할 수 있습니다.

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

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

기본 사이트에서:

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

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

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

로그인한 후:

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

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

Geo 대시보드

관련 주제