Infograb logo
확장

이 섹션에서는 대규모 셀프 호스팅 배포를 위한 권장 구성 설정을 설명합니다.

Tip

Teleport Enterprise Cloud는 이 설정을 자동으로 처리하므로 즉시 인프라에 대한 안전한 액세스를 제공할 수 있습니다.

Teleport Enterprise Cloud의 무료 평가판으로 시작하세요.

전제 조건

  • Teleport v17.0.0-dev 오픈 소스 또는 엔터프라이즈.

하드웨어 권장 사항

고가용성 구성으로 Teleport를 설정하세요. 고가용성 구성.

시나리오최대 권장 수량프록시 서비스인증 서비스AWS 인스턴스 유형
인증 서비스에 연결된 Teleport SSH 노드10,0002x 4 vCPUs, 8GB RAM2x 8 vCPUs, 16GB RAMm4.2xlarge
인증 서비스에 연결된 Teleport SSH 노드50,0002x 4 vCPUs, 16GB RAM2x 8 vCPUs, 16GB RAMm4.2xlarge
리버스 터널을 통해 프록시 서비스에 연결된 Teleport SSH 노드10,0002x 4 vCPUs, 8GB RAM2x 8 vCPUs, 16+GB RAMm4.2xlarge

인증 서비스 및 프록시 서비스 구성

Teleport의 연결 제한을 기본 연결 제한인 15000 에서 65000 으로 업그레이드합니다.

# Teleport 인증 서비스 및 프록시 서비스
teleport:
  connection_limits:
    max_connections: 65000

에이전트 구성

에이전트는 접근 제어 결정을 빠르게 하기 위해 역할 및 기타 구성을 로컬에 캐시합니다. 기본적으로 에이전트는 인증 서비스와의 연결이 끊어지면 캐시를 재초기화하려고 꽤 공격적입니다. 매우 큰 클러스터에서는 이것이 "천둥의 무리" 효과를 초래할 수 있습니다. 이럴 경우 제어 평면 요소가 재시작 후 즉시 과도한 부하를 경험할 수 있습니다. max_backoff 매개변수를 8-16분 범위로 설정하면 이 효과를 완화하는 데 도움이 될 수 있습니다:

teleport:
  cache:
    enabled: yes
    max_backoff: 12m

커널 매개변수

Teleport의 systemd 유닛 매개변수를 조정하여 열 수 있는 파일의 수를 늘리도록 설정합니다:

[Service]
LimitNOFILE=65536

Teleport 프로세스의 파일 제한이 충분히 높은지 확인합니다:

cat /proc/$(pidof teleport)/limits

제한 소프트 제한 하드 제한 단위

최대 열려 있는 파일 65536 65536 파일

DynamoDB 구성

Teleport를 DynamoDB와 함께 사용할 때, 자동 확장 프로비저닝을 사용하는 것을 권장합니다. 이렇게 하면 DynamoDB가 클러스터 부하에 따라 확장할 수 있습니다.

자동 확장 프로비저닝을 사용할 수 없는 고객에게는 10k 클러스터의 경우 최소 250 WCU와 100 RCU를 권장합니다.

etcd

Teleport를 etcd와 함께 사용할 때, 다음을 권장합니다.

  • 성능을 위해 가장 빠른 SSD를 사용하고 etcd 피어 간의 저지연 네트워크 연결을 보장합니다. 자세한 내용은 etcd 하드웨어 권장 사항 가이드를 참조하세요.
  • 디버그를 위해 etcd의 Prometheus 메트릭을 수집하고 대시보드를 사용하여 시간 도에 따라 시각화합니다. 자세한 내용은 etcd 메트릭 가이드를 참조하세요.

사고 발생 시, etcdctl 을 실행해보라고 요청할 수 있으며 다음 명령을 성공적으로 실행할 수 있는지 테스트합니다.

etcdctl \ --write-out=table \ --cacert=/path/to/ca.cert \ --cert=/path/to/cert \ --key=/path/to/key.pem \ --endpoints=127.0.0.1:2379 \ endpoint status

지원되는 로드

아래 테스트는 8 vCPU 및 32 GiB 메모리를 가진 인스턴스에서 실행되는 Teleport Cloud 테넌트를 대상으로 수행되었으며 기본 제한은 4CPU 및 4Gi 메모리입니다.

동시 로그인

리소스 유형로그인 명령로그인 수실패
SSHtsh login2000인증 CPU 제한 초과
애플리케이션tsh app login2000인증 CPU 제한 초과
데이터베이스tsh db login2000인증 CPU 제한 초과
쿠버네티스tsh kube login && tsh kube credentials2000인증 CPU 제한 초과

초당 세션 수

리소스 유형세션 수실패
SSH1000인증 CPU 제한 초과
애플리케이션2500프록시 CPU 제한 초과
데이터베이스40프록시 CPU 제한 초과
쿠버네티스50프록시 CPU 제한 초과

윈도우 데스크탑 서비스

윈도우 데스크탑 세션은 사용되는 애플리케이션에 따라 리소스 사용량이 크게 달라질 수 있습니다. 세션당 리소스 사용량에 영향을 미치는 주요 요소는 화면이 업데이트되는 빈도입니다. 예를 들어, 전체 화면 모드에서 비디오를 재생하는 세션은 텍스트 편집기에서 입력하는 세션보다 훨씬 더 많은 리소스를 소모하게 됩니다.

우리는 전체 화면 비디오를 재생하는 세션의 리소스 사용량을 측정하여 리소스 요구 사항에 대한 최악의 경우 추정치를 얻었습니다. 그런 다음 이러한 측정을 바탕으로 보다 일반적인 사용 사례에 대한 리소스 요구 사항을 추론했습니다.

최악의 경우:

  • 동시 세션당 1/12 vCPU
  • 동시 세션당 42 MB RAM

일반적인 경우:

  • 동시 세션당 1/240 vCPU
  • 동시 세션당 2 MB RAM

이러한 추정치를 바탕으로 예상되는 최대 동시 세션 수에 대한 다음 권장 사항 테이블을 계산했습니다:

동시 사용자 수CPU (vCPU, 낮음에서 높음)메모리 (GB, 낮음에서 높음)
110.5
1010.5에서 1
1001에서 81에서 8
10004에서 964에서 64

서비스 중단을 피하기 위해 리소스 사용량을 모니터링하면서 권장 사항의 높은 쪽으로 시작하는 것을 권장하며, 그 후 측정된 결과를 바탕으로 리소스를 확장해야 합니다.

단일 windows_desktop_service 에 제한되지 않으며, 여러 개를 클러스터에 연결하여 여러 논리 머신에 리소스를 분산할 수 있음을 유의하세요.

Teleport 원문 보기