두 개의 단일 노드 사이트에 대해 Geo 설정

Tier: 프리미엄, 얼티메이트 Offering: Self-managed

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

전제 조건:

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

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

전제 조건:

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

주 사이트 구성

  1. GitLab 주 사이트에 SSH로 로그인한 다음 root로 전환합니다. 

    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에서 새 암호를 사용하도록 설정합니다.

    참고: 설정된 gitlab_rails['db_password'] 및 postgresql['sql_user_password'] 값이 일치해야 합니다. 그러나 postgresql['sql_user_password'] 값만 MD5 암호화된 암호여야 합니다. 이에 대한 변경 사항은 Rethink how we handle PostgreSQL passwords in cookbooks에서 논의 중입니다.

    1. 원하는 암호의 MD5 해시 생성: 

      gitlab-ctl pg-password-md5 gitlab
# 암호 입력: <여기에_암호_입력>
# 암호 확인: <여기에_암호_입력>
# fca0b89a972d69f00eb3ec98a5838484

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

      # `gitlab-ctl pg-password-md5 gitlab`으로 생성된 해시로 채웁니다.
postgresql['sql_user_password'] = '<당신의_데이터베이스_암호의_md5_해시>'

# Puma 또는 Sidekiq를 실행하는 모든 노드에서 아래와 같이 데이터베이스의
# 암호를 지정해야 합니다. 고가용성 설정이 있는 경우 모든 애플리케이션 노드에
# 이 설정이 있어야 합니다.
gitlab_rails['db_password'] = '<여기에_데이터베이스_암호_입력>'

  6. 데이터베이스 복제 사용자에 대한 암호를 정의합니다. /etc/gitlab/gitlab.rb에서 정의된 사용자 이름(postgresql['sql_replication_user'] 설정)을 사용하세요. 기본 값은 gitlab_replicator입니다.

    1. 원하는 암호의 MD5 해시 생성: 

      gitlab-ctl pg-password-md5 gitlab_replicator

# 암호 입력: <여기에_복제_암호_입력>
# 암호 확인: <여기에_복제_암호_입력>
# 950233c0dfc2f39c64cf30457c3b7f1e

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

      # `gitlab-ctl pg-password-md5 gitlab_replicator`으로 생성된 해시로 채웁니다.
postgresql['sql_replication_password'] = '<당신의_복제_암호_의_md5_해시>'

    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 주 역할
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 또는 Google Cloud Platform의 “내부 주소”에 해당하는 VPC(가상 사설 네트워크) 또는 기타 공급 업체를 사용하는 경우, postgresql['md5_auth_cidr_addresses'] 및 postgresql['listen_address']에 주 사이트와 보조 사이트 사설 주소를 사용할 수 있습니다.

      참고: 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_site_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 트래픽을 암호화하기 위해 인증서가 자동으로 생성되었습니다. 액티브(“중간자”) 공격에서 보호하려면 인증서를 보조 사이트에 복사하세요.

    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 주소를 사용하거나 방화벽이 사이트 접근을 막고 있을 수 있습니다. 공용 및 개인 주소 간의 차이에 주의하여 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 <primary_site_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
## - '<secondary_site_ip>'를 네트워크 구성에 적합한 공용 또는 VPC 주소로 대체합니다.
##
postgresql['listen_address'] = '<secondary_site_ip>'
postgresql['md5_auth_cidr_addresses'] = ['<secondary_site_ip>/32']

##
## Database credentials password (defined previously in primary site)
## - 기본 사이트에서 정의한 것과 동일한 값을 여기에 복제합니다
##
postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'
postgresql['sql_user_password'] = '<md5_hash_of_your_db_password>'
gitlab_rails['db_password'] = '<your_db_password_here>'

    IP 주소를 네트워크 구성에 적합한 주소로 교체하십시오.

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

    gitlab-ctl reconfigure

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

gitlab-ctl restart postgresql

데이터베이스 복제

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

이 스크립트는 기본 Linux 패키지 디렉터리를 사용합니다. 기본값을 변경하면 스크립트의 디렉터리 및 경로 이름을 자체 이름으로 교체하십시오.

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

데이터베이스를 복제하려면:

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

    sudo -i

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

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

    경고: 각 Geo 보조 사이트에는 고유한 복제 슬롯 이름이 있어야 합니다. 두 개의 보조 사이트 간에 같은 슬롯 이름을 사용하면 PostgreSQL 복제가 동작하지 않습니다. 

    gitlab-ctl replicate-geo-database \
   --slot-name=<secondary_site_name> \
   --host=<primary_site_ip> \
   --sslmode=verify-ca

    묻는다면 gitlab_replicator의 설정한 일반 텍스트 비밀번호를 입력하십시오.

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

새로운 보조 사이트 구성

초기 복제 프로세스가 완료되면 보조 사이트에서 다음 항목을 구성합니다.

인증된 SSH 키의 빠른 조회

인증된 SSH 키의 빠른 조회를 구성하려면 설명서에 따릅니다.

빠른 조회는 Geo에서 필수 사항입니다.

참고: 인증은 기본 사이트에서 처리됩니다. 보조 사이트에 사용자 정의 인증을 설정하지 마십시오. 관리자 영역에 액세스할 필요가 있는 변경 사항은 보조 사이트가 읽기 전용 복사본이기 때문에 기본 사이트에서 수행해야 합니다.

GitLab의 비밀값 수동 복제

GitLab은 /etc/gitlab/gitlab-secrets.json에 여러 비밀 값을 저장합니다. 이 JSON 파일은 각 사이트 노드 간에 동일해야 합니다. 이슈 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

Primary 사이트 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. 왼쪽 사이드바에서 맨 아래에서 Admin을 선택합니다.
    2. Geo > Sites를 선택합니다.

    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 관리 페이지에 추가되고 재시작된 후, 사이트는 백필(Backfill)이라는 과정에서 프라이머리 사이트에서 누락된 데이터를 자동으로 복제하기 시작합니다.

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

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

HTTP/HTTPS 및 SSH로 Git 액세스 활성화

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

기본 사이트에서:

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

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

기존의 기본 사이트 자격 증명을 사용하여 보조 사이트에 로그인할 수 있습니다.

로그인한 후에:

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

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

Geo 대시보드

관련 주제