설치 요구사항

Private Cloud용 Edge v. 4.17.09

하드웨어 요구사항

프로덕션 등급 환경에서 가용성이 높은 인프라를 위해서는 다음과 같은 최소 하드웨어 요구사항을 충족해야 합니다. 다음 표에는 설치 토폴로지에 설명된 모든 설치 시나리오에서 설치 구성요소의 최소 하드웨어 요구사항이 나열되어 있습니다.

이 표에서 하드 디스크 요구사항은 운영체제에 필요한 하드 디스크 공간에 더해 추가로 적용됩니다. 애플리케이션 및 네트워크 트래픽에 따라 아래 나열된 것보다 더 많은 리소스가 필요하거나 더 적은 리소스가 필요할 수 있습니다.

설치 구성요소

RAM

CPU

최소 하드 디스크

Cassandra

16GB

8코어

SSD가 포함된 250GB 로컬 스토리지 또는 2,000IOPS를 지원하는 빠른 HDD

동일한 머신의 메시지 프로세서/라우터

16GB

8코어

100GB

애널리틱스 - 동일한 서버의 Postgres/Qpid (프로덕션에는 권장되지 않음)

16GB*

8코어*

500GB - 1TB** 네트워크 스토리지***, 가급적 1, 000IOPS 이상* 지원 SSD 백엔드 사용 권장

애널리틱스 - Postgres 독립형

16GB*

8코어*

500GB - 1TB** 네트워크 스토리지***, 가급적 1,000IOPS 이상* 지원 SSD 백엔드 사용 권장

애널리틱스 - Qpid 독립형

8GB

4코어

30GB~50GB 로컬 저장소(SSD 또는 빠른 HDD)

TPS가 250개보다 큰 설치의 경우 로컬 스토리지가 1, 000IOPS를 지원하는 HDD를 사용하는 것이 좋습니다.

기본 Qpid 큐 크기는 20GB입니다. 용량을 더 추가해야 하는 경우 Qpid 노드를 추가하세요.

기타 (OpenLDAP, UI, Management Server)

4GB

2코어

60GB

*처리량에 따라 Postgres 시스템 요구사항을 조정합니다.

  • TPS 250개 미만: 1,000IOPS 이상을 지원하는 관리형 네트워크 스토리지*** 8GB, 4코어
  • TPS 250개 초과: 16GB, 8코어, 관리형 네트워크 스토리지***(1,000IOPS 이상 지원)
  • TPS 1,000개 이상: 16GB, 8코어, 관리형 네트워크 스토리지***(2,000IOPS 이상 지원)
  • TPS 2,000개 이상: 32GB, 16코어, 관리형 네트워크 스토리지***(2,000IOPS 이상 지원)
  • TPS 4,000개 이상: 64GB, 32코어, 관리형 네트워크 스토리지***(4,000IOPS 이상 지원)

**Postgres 하드 디스크 값은 Edge에서 캡처하는 즉시 사용 가능한 분석을 기반으로 합니다. 커스텀 값을 애널리틱스 데이터에 추가하면 그에 따라 이러한 값이 증가해야 합니다. 다음 수식을 사용하여 필요한 스토리지를 예상합니다.

(요청당 #바이트) * (초당 요청 수) * (시간당 초) * (일일 최고 사용량 시간) * (월간 최고 사용량) * (데이터 보관 월) = 필요한 스토리지 바이트

예:

(요청당 분석 데이터 2,000바이트, 10GB/초 * 10GB/초 * 360바이트/초) * 360바이트

*** Postgresql 데이터베이스에는 다음과 같은 이유로 네트워크 스토리지가 권장됩니다.

  • 필요한 경우 스토리지 크기를 동적으로 확장할 수 있습니다.
  • 오늘날 대부분의 환경/스토리지/네트워크 하위 시스템에서 네트워크 IOPS를 즉시 조정할 수 있습니다.
  • 스토리지 수준 스냅샷을 백업 및 복구 솔루션의 일부로 사용 설정할 수 있습니다.

또한 수익 창출 서비스를 설치하려는 경우 다음 하드웨어 요구사항이 나와 있습니다.

수익 창출 구성요소

RAM

CPU

하드 디스크

관리 서버 (수익 창출 서비스 포함)

8GB

4코어

60GB

애널리틱스 - 동일한 서버의 Postgres/Qpid

16GB

8코어

500GB - 1TB 네트워크 스토리지(SSD 백엔드 권장, 1,000IOPS 이상 지원 또는 위 표의 규칙 사용).

애널리틱스 - Postgres 독립형

16GB

8코어

500GB - 1TB 네트워크 스토리지(SSD 백엔드 권장, 1,000IOPS 이상 지원 또는 위 표의 규칙 사용).

애널리틱스 - Qpid 독립형

8GB

4코어

40GB~500GB 로컬 저장소(SSD 또는 빠른 HDD)

TPS가 250개보다 큰 설치의 경우 로컬 스토리지가 1, 000IOPS를 지원하는 HDD를 사용하는 것이 좋습니다.

다음은 API BaaS를 설치하려는 경우의 하드웨어 요구사항입니다.

API BaaS 구성요소

RAM

CPU

하드 디스크

ElasticSearch*

8GB

4코어

60~80GB

API BaaS 스택 *

8GB

4코어

60~80GB

API BaaS 포털

1GB

2코어

20GB

Cassandra (선택사항 - 일반적으로 Edge와 API BaaS 서비스 모두에 동일한 Cassandra 클러스터를 사용)

16GB

8코어

SSD가 포함된 250GB 로컬 스토리지 또는 2,000IOPS를 지원하는 빠른 HDD

* ElasticSearch 및 API BaaS 스택을 동일한 노드에 설치할 수 있습니다. 이 경우 4GB의 메모리를 사용하도록 ElasticSearch를 구성합니다 (기본값). ElasticSearch가 자체 노드에 설치되어 있으면 6GB 메모리를 사용하도록 구성합니다.

참고:

  • 루트 파일 시스템이 설치를 할 만큼 크지 않은 경우 데이터를 더 큰 디스크에 저장하는 것이 좋습니다.
  • 머신에 프라이빗 클라우드용 Apigee Edge의 이전 버전이 설치되어 있으면 새로 설치하기 전에 /tmp/java 폴더를 삭제해야 합니다.
  • Cassandra를 시작하려면 시스템 전체 임시 폴더 /tmp에 실행 권한이 필요합니다.
  • 설치 전에 사용자 'apigee'를 만든 경우 '/home/apigee'가 홈 디렉터리로 존재하고 'apigee:apigee'에서 소유하는지 확인하세요.

운영체제 및 타사 소프트웨어 요구사항

이러한 설치 안내와 제공된 설치 파일은 여기(https://apigee.com/docs/api-services/reference/supported-software)에 나열된 운영체제와 타사 소프트웨어에서 테스트했습니다.

Apigee 사용자 만들기

설치 절차에서는 'apigee'라는 Unix 시스템 사용자를 만듭니다. 에지 디렉터리 및 파일은 'Apigee'에서 소유하며, Edge 프로세스도 소유합니다. 즉, Edge 구성요소가 'apigee' 사용자로 실행됩니다. 필요한 경우 구성요소를 다른 사용자로 실행할 수 있습니다. 예시는 노드에 에지 구성요소 설치에서 '보호된 포트에 라우터 결합'을 참조하세요.

설치 디렉터리

기본적으로 설치 프로그램은 모든 파일을 /opt/apigee 디렉터리에 씁니다. 이 디렉터리 위치는 변경할 수 없습니다. 이 디렉터리를 변경할 수는 없지만 아래 설명된 대로 /opt/apigee를 다른 위치에 매핑하는 심볼릭 링크를 만들 수는 있습니다.

이 가이드의 안내에서 설치 디렉터리는 /<inst_root>/apigee로 표시되어 있으며, 여기서 /<inst_root>는 기본적으로 /opt입니다.

/opt/apigee에서 심볼릭 링크 만들기

심볼릭 링크를 만들려면 먼저 'apigee'라는 사용자와 그룹을 만들어야 합니다. 이는 Edge 설치 프로그램에서 생성된 동일한 그룹 및 사용자입니다.

심볼릭 링크를 만들려면 bootstrap_4.17.01.sh 파일을 다운로드하기 전에 다음 단계를 수행합니다. 다음 단계를 모두 루트로 수행해야 합니다.

  1. 'apigee' 사용자 및 그룹을 만듭니다.
    > groupadd -r apigee
    > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee
  2. /opt/apigee에서 원하는 설치 루트로 연결되는 심볼릭 링크를 만듭니다.
    > ln -Ts /srv/myInstallDir /opt/apigee
    여기서 /srv/myInstallDir은 원하는 Edge 파일 위치입니다.
  3. 설치 루트와 심볼릭 링크를 'apigee' 사용자로 변경합니다.
    > chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Java

설치하기 전에 각 머신에 지원되는 Java1.8 버전이 설치되어 있어야 합니다. 지원되는 JDK는 다음과 같습니다.

https://apigee.com/docs/api-services/reference/supported-software

JAVA_HOME이 설치를 수행하는 사용자를 위해 JDK의 루트를 가리키는지 확인합니다.

SELinux

SELinux 설정에 따라 Edge 구성요소를 설치하고 시작하는 데 문제가 발생할 수 있습니다. 필요한 경우 설치하는 동안 SELinux를 사용 중지하거나 허용 모드로 설정한 다음 설치 후에 다시 사용 설정할 수 있습니다. 자세한 내용은 Edge Apigee 설정 유틸리티 설치를 참고하세요.

네트워크 설정

설치하기 전에 네트워크 설정을 확인하는 것이 좋습니다. 설치 프로그램은 모든 머신에 고정 IP 주소가 있을 것으로 예상합니다. 다음 명령어를 사용하여 설정을 검증합니다.

  • hostname은 머신 이름을 반환합니다.
  • hostname -i는 다른 머신에서 처리할 수 있는 호스트 이름의 IP 주소를 반환합니다.

운영체제 유형과 버전에 따라 호스트 이름이 올바르게 설정되지 않은 경우 /etc/hosts/etc/sysconfig/network를 수정해야 할 수도 있습니다. 자세한 내용은 사용 중인 운영체제의 문서를 참조하세요.

서버에 인터페이스 카드가 여러 개 있는 경우 'hostname -i' 명령어는 공백으로 구분된 IP 주소 목록을 반환합니다. 기본적으로 Edge 설치 프로그램은 반환된 첫 번째 IP 주소를 사용합니다. 이 주소는 경우에 따라 정확하지 않을 수도 있습니다. 또는 설치 구성 파일에서 다음 속성을 설정할 수 있습니다.

ENABLE_DYNAMIC_HOSTIP=y

이 속성을 'y'로 설정하면 설치 프로그램에서 설치의 일부로 사용할 IP 주소를 선택하라는 메시지가 표시됩니다. 기본값은 'n'입니다. 자세한 내용은 Edge 구성 파일 참조를 확인하세요.

TCP 래퍼

TCP Wrapper는 일부 포트의 통신을 차단할 수 있으며 OpenLDAP, Postgres, Cassandra 설치에 영향을 미칠 수 있습니다. 해당 노드에서 /etc/hosts.allow/etc/hosts.deny를 확인하여 필수 OpenLDAP, Postgres, Cassandra 포트에 포트 제한이 없는지 확인합니다.

iptables

필수 Edge 포트에서 노드 간 연결을 방지하는 iptables 정책이 없는지 확인합니다. 필요한 경우 다음 명령어를 사용하여 설치하는 동안 iptables를 중지할 수 있습니다.

> sudo/etc/init.d/iptables stop

CentOS 7.x:

> systemctl stop firewalld

에지 라우터가 /etc/rc.d/init.d/functions에 액세스할 수 있는지 확인하세요.

Edge Router 및 BaaS 포털 노드는 Nginx 라우터를 사용하며 /etc/rc.d/init.d/functions에 대한 읽기 액세스 권한이 필요합니다.

보안 프로세스에서 /etc/rc.d/init.d/functions에 대한 권한을 설정해야 하는 경우 권한을 700으로 설정하지 마세요. 권한을 설정할 경우 라우터가 시작되지 않습니다. /etc/rc.d/init.d/functions에 대한 읽기 액세스를 허용하도록 권한을 744로 설정할 수 있습니다.

Cassandra

모든 Cassandra 노드는 링에 연결되어야 합니다. Cassandra는 안정성과 내결함성을 보장하기 위해 여러 노드에 데이터 복제본을 저장합니다. 각 Edge 키스페이스의 복제 전략은 복제본이 배치되는 Cassandra 노드를 결정합니다. 자세한 내용은 Cassandra 복제 계수 및 일관성 수준 정보를 참조하세요.

Cassandra는 사용 가능한 메모리에 따라 Java 힙 크기를 자동으로 조정합니다. 자세한 내용은 자바 리소스 조정을 참조하세요. 성능이 저하되거나 메모리를 많이 소비하는 경우

Private Cloud용 Edge를 설치한 후 /<inst_root>/apigee/apigee-cassandra/conf/cassandra.yaml 파일을 검사하여 Cassandra가 올바르게 구성되었는지 확인할 수 있습니다. 예를 들어 Private Cloud용 Edge 설치 스크립트가 다음 속성을 설정했는지 확인합니다.

  • cluster_name
  • initial_token
  • 파티션 나누기
  • 시드
  • listen_address
  • rpc_address
  • 스니치

경고: 이 파일을 수정하지 마세요.

PostgreSQL 데이터베이스

Edge를 설치한 후 시스템에서 사용할 수 있는 RAM 양에 따라 다음 PostgreSQL 데이터베이스 설정을 조정할 수 있습니다.

conf_postgresql_shared_buffers = 35% of RAM      # min 128kB
conf_postgresql_effective_cache_size = 45% of RAM
conf_postgresql_work_mem = 512MB       # min 64kB

이 값을 설정하는 방법은 다음과 같습니다.

  1. postgresql.properties 수정:
    > vi /<inst_root>/apigee/customer/application/postgresql.properties

    파일이 없으면 새로 만듭니다.
  2. 위에 나열된 속성을 설정합니다.
  3. 수정사항을 저장합니다.
  4. PostgreSQL 데이터베이스를 다시 시작합니다.
    > /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

시스템 한도

Cassandra 및 메시지 프로세서 노드에 다음과 같은 시스템 제한을 설정했는지 확인합니다.

  • Cassandra 노드에서 아래와 같이 /etc/security/limits.d/90-apigee-edge-limits.conf 에서 설치 사용자에 대한 소프트 및 하드 memlock, nofile, 주소 공간(기본값은 'apigee') 한도를 설정합니다.
    apigee soft memlock 무제한
    apigee 하드 memlock 무제한
    apigee soft nofile 32768
    apigee soft nofile 32768



  • 아래와 같이 메시지 프로세서 노드에서 /etc/security/limits.d/90-apigee-edge-limits.conf 의 최대 열려 있는 파일 설명자 수를 64K로 설정합니다.
    apigee soft nofile 32768
    apigee 하드 nofile 65536


    필요한 경우 이 한도를 늘릴 수 있습니다. 예를 들어 한 번에 많은 수의 임시 파일이 열려 있는 경우입니다.

jsvc

'jsvc'는 API BaaS를 사용하기 위한 전제 조건입니다. API BaaS를 설치하면 버전 1.0.15-dev가 설치됩니다.

네트워크 보안 서비스 (NSS)

네트워크 보안 서비스 (NSS)는 보안이 사용 설정된 클라이언트 및 서버 애플리케이션의 개발을 지원하는 라이브러리 집합입니다. NSS v3.19 이상을 설치했는지 확인해야 합니다.

현재 버전을 확인하려면 다음 안내를 따르세요.

> yum info nss

NSS를 업데이트하려면 다음 안내를 따르세요.

> yum update nss

자세한 내용은 RedHat의 이 도움말을 참고하세요.

NSCD (Name Service Cache Daemon)를 사용할 때 IPv6에서 DNS 조회 사용 중지

NSCD (이름 서비스 캐시 데몬)를 설치하고 사용 설정한 경우 메시지 프로세서는 IPv4와 IPv6에 각각 하나씩 총 두 번의 DNS 조회를 수행합니다. NSCD를 사용할 때는 IPv6에서 DNS 조회를 사용 중지해야 합니다.

IPv6에서 DNS 조회를 사용 중지하려면 다음 단계를 따르세요.

  1. 모든 메시지 프로세서 노드에서 /etc/nscd.conf를 수정합니다.
  2. 다음 속성을 설정합니다.
    enable-cache host no

RedHat/CentOS 7용 Google Cloud Platform에서 IPv6 사용 중지

RedHat 7에 Edge를 설치하거나 Google Cloud Platform에 CentOS 7을 설치하는 경우 모든 Qpid 노드에서 IPv6를 사용 중지해야 합니다.

IPv6 사용 중지에 대한 안내는 사용 중인 OS 버전의 RedHat 또는 CentOS 문서를 참조하세요. 예를 들어 다음과 같은 작업을 처리할 수 있습니다.

  1. 편집기에서 /etc/hosts를 엽니다.
  2. 다음 줄 중 하나의 열에 '#' 문자를 삽입하여 주석 처리합니다.
    #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  3. 파일을 저장합니다.

AWS AMI

Red Hat Enterprise Linux 7.x용 AWS Amazon Machine Image (AMI)에 Edge를 설치하는 경우 먼저 다음 명령어를 실행해야 합니다.

> yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

도구

설치 프로그램은 EL5 또는 EL6에서 제공하는 표준 버전에서 다음 UNIX 도구를 사용합니다.

awk

expr

lua-socket

분당 회전수

unzip

basename

grep

ls

rpm2cpio

사용자 추가

bash

hostname

net-tools

sed

wc

bc

id

perl (procps에서)

sudo

wget

curl

리바이오

pgrep (procps에서)

tar

Xerces-C

Cyrus-Sasl
libdb-cxx
ps tr 맛있어요

date

리비버브

pwd

uuid

chkconfig

dirname
librdmacm
python 유남
echo
libxlst

참고:

  • 도구 'useradd'의 실행 파일은 /usr/sbin에 있고 chkconfig의 경우 /sbin에 있습니다.
  • sudo 액세스 권한을 사용하면 호출하는 사용자의 환경에 대한 액세스 권한을 얻을 수 있습니다. 예를 들어 일반적으로 'sudo <command>' 또는 'sudo PATH=$PATH:/usr/sbin:/sbin <command>'를 호출합니다.
  • 서비스 팩 (패치) 설치 전에 '패치' 도구를 설치했는지 확인합니다.

ntpdate – 서버 시간을 동기화하는 것이 좋습니다. 아직 구성되지 않은 경우 'ntpdate' 유틸리티가 이 목적으로 사용하여 서버가 시간 동기화되었는지 확인합니다. 'yum install ntp'를 사용하여 유틸리티를 설치할 수 있습니다. 이 기능은 OpenLDAP 설정을 복제하는 데 특히 유용합니다. 서버 시간대는 UTC로 설정합니다.

openldap 2.4 – 온프레미스 설치에는 OpenLDAP 2.4가 필요합니다. 서버가 인터넷에 연결되어 있으면 Edge 설치 스크립트가 OpenLDAP를 다운로드하여 설치합니다. 서버가 인터넷에 연결되어 있지 않으면 Edge 설치 스크립트를 실행하기 전에 OpenLDAP가 이미 설치되어 있는지 확인해야 합니다. RHEL/CentOS에서는 'yum install openldap-clients openldap-servers'를 실행하여 OpenLDAP를 설치할 수 있습니다.

13개의 호스트 설치 및 두 개의 데이터 센터가 있는 12개의 호스트 설치의 경우 OpenLDAP를 호스팅하는 노드가 여러 개 있으므로 OpenLDAP 복제가 필요합니다.

방화벽 및 가상 호스트

'가상'이라는 용어는 IT 분야에서 일반적으로 과부하가 걸리기 때문에 프라이빗 클라우드 배포 및 가상 호스트를 위한 Apigee Edge에서도 마찬가지입니다. 명확히 설명하자면, '가상'이라는 용어에는 두 가지 주요 용도가 있습니다.

  • 가상 머신 (VM): 필수는 아니지만 일부 배포에서는 VM 기술을 사용하여 Apigee 구성요소에 대해 격리된 서버를 만듭니다. 물리적 호스트와 마찬가지로 VM 호스트에는 네트워크 인터페이스와 방화벽이 있을 수 있습니다.
  • 가상 호스트: Apache 가상 호스트와 유사한 웹 엔드포인트입니다.

VM의 라우터는 여러 가상 호스트를 노출할 수 있습니다 (호스트 별칭 또는 인터페이스 포트에서 서로 다른 경우).

이름 지정 예시와 마찬가지로 단일 물리적 서버 'A'가 'VM1'과 'VM2'라는 두 개의 VM을 실행할 수 있습니다. VM1이 가상 이더넷 인터페이스를 노출한다고 가정해 보겠습니다.이 인터페이스는 VM 내부에 eth0이라는 가상 이더넷 인터페이스를 노출하고, 이 인터페이스에는 IP 주소 111.111.111.111이 할당되어 있습니다.그러면 서버1.1.가상2 또는 VM2라는 IP 주소

두 VM 각각에서 Apigee 라우터를 실행 중일 수 있습니다. 라우터는 다음 가상의 예와 같이 가상 호스트 엔드포인트를 노출합니다.

VM1의 Apigee 라우터는 eth0 인터페이스 (특정 IP 주소가 있음), api.mycompany.com:80, api.mycompany.com:443, test.mycompany.com:80에 가상 호스트 3개를 노출합니다.

VM2의 라우터는 api.mycompany.com:80 (VM1에서 노출된 것과 동일한 이름과 포트)을 노출합니다.

물리적 호스트의 운영체제에 네트워크 방화벽이 있을 수 있습니다. 네트워크 방화벽이 있는 경우 가상화된 인터페이스에 노출되는 포트로 연결되는 TCP 트래픽을 전달하도록 방화벽을 구성해야 합니다 (111.111.111.111:{80, 443}111.111.111.222:80). 또한 각 VM의 운영체제는 eth0 인터페이스에 자체 방화벽을 제공할 수 있으며 포트 80443 트래픽 연결을 허용해야 합니다.

기본 경로는 API 호출을 배포했을 수 있는 다른 API 프록시로 라우팅하는 데 사용되는 세 번째 구성요소입니다. API 프록시 번들은 기본 경로가 다른 경우 엔드포인트를 공유할 수 있습니다. 예를 들어, 기본 경로 하나를 http://api.mycompany.com:80/로 정의하고 다른 기본 경로는 http://api.mycompany.com:80/salesdemo로 정의할 수 있습니다.

이 경우 두 IP 주소 간에 http://api.mycompany.com:80/ 트래픽을 분할하는 부하 분산기 또는 트래픽 디렉터가 필요합니다 (VM1에서 111.111.111.111, VM2에서 111.111.111.222). 이 기능은 특정 설치에 따라 다르며 로컬 네트워킹 그룹에서 구성됩니다.

기본 경로는 API를 배포할 때 설정됩니다. 위의 예에서 호스트 별칭이 api.mycompany.com이고 포트가 80으로 설정된 가상 호스트를 사용하여 mycompany-org 조직에 mycompanytestmycompany라는 두 API를 배포할 수 있습니다. 배포에서 기본 경로를 선언하지 않으면 라우터는 수신 요청을 전송할 API를 알 수 없습니다.

하지만 기본 URL이 /salesdemo인 API testmycompany를 배포할 경우 사용자는 http://api.mycompany.com:80/salesdemo를 사용하여 해당 API에 액세스합니다. 기본 URL / 로 API mycompany를 배포하면 사용자가 http://api.mycompany.com:80/ URL로 API에 액세스합니다.

에지 포트 요구사항

방화벽을 관리해야 할 필요성은 가상 호스트를 넘어서게 됩니다. VM과 물리적 호스트 방화벽은 구성요소가 서로 통신하는 데 필요한 포트의 트래픽을 허용해야 합니다.

다음 이미지는 각 Edge 구성요소의 포트 요구사항을 보여줍니다.

이 다이어그램의 참고사항:

  • *라우터와 메시지 프로세서 간에 TLS/SSL을 구성할 때 라우터에서 액세스할 수 있도록만 메시지 프로세서의 포트 8082가 열려 있으면 됩니다. 라우터와 메시지 프로세서 간에 TLS/SSL을 구성하지 않는 경우, 구성요소를 관리하기 위해 기본 구성인 포트 8082는 메시지 프로세서에서 열려 있어야 하지만 라우터에서 액세스할 필요는 없습니다.
  • 'M' 접두사가 붙은 포트는 구성요소를 관리하는 데 사용되는 포트이며 구성요소에서 열려 있어야 하며 관리 서버가 액세스할 수 있도록 구성요소에서 열려 있어야 합니다.
  • 라우터, 메시지 프로세서, UI, Postgres, Qpid 등의 구성요소를 사용하려면 관리 서버의 포트 8080에 액세스해야 합니다.
  • 메시지 프로세서는 포트 4528을 관리 포트로 열어야 합니다. 여러 메시지 프로세서가 있는 경우 포트 4528 (메시지 프로세서의 포트 4528과 관련해 위 다이어그램에서 루프 화살표로 표시)을 통해 포트 4528을 통해 서로 액세스할 수 있어야 합니다. 데이터 센터가 여러 개 있는 경우 모든 데이터 센터의 모든 메시지 프로세서에서 포트에 액세스할 수 있어야 합니다.
  • 필수는 아니지만 라우터에서 포트 4527을 열어 모든 메시지 프로세서가 액세스할 수 있습니다. 그렇지 않으면 메시지 프로세서 로그 파일에 오류 메시지가 표시될 수 있습니다.
  • 라우터는 관리 포트로 포트 4527을 열어야 합니다. 라우터가 여러 개 있는 경우 모두 포트 4527 (라우터의 포트 4527과 관련해 위 다이어그램에 루프 화살표로 표시됨)을 통해 서로 액세스할 수 있어야 합니다.
  • Edge UI에서는 추적 도구에서 보내기 버튼을 지원하기 위해 API 프록시에서 노출된 포트의 라우터에 액세스해야 합니다.
  • 관리 서버는 Cassandra 노드의 JMX 포트에 액세스해야 합니다.
  • JMX 포트에 대한 액세스는 사용자 이름/비밀번호를 요구하도록 구성할 수 있습니다. 자세한 내용은 모니터링 방법을 참고하세요.
  • 다른 포트를 사용할 수 있는 특정 연결에 대해 TLS/SSL 액세스를 선택적으로 구성할 수 있습니다. 자세한 내용은 TLS/SSL을 참조하세요.
  • 마스터-대기 복제를 사용하도록 Postgres 노드 2개를 구성하는 경우 SSH 액세스를 위해 각 노드에서 포트 22를 열어야 합니다. 필요한 경우 개별 노드에서 포트를 열어 SSH 액세스를 허용할 수 있습니다.
  • 외부 SMTP 서버를 통해 이메일을 보내도록 관리 서버 및 Edge UI를 구성할 수 있습니다. 이 경우 관리 서버 및 UI가 SMTP 서버의 필요한 포트에 액세스할 수 있는지 확인해야 합니다. 비 TLS SMTP의 경우 포트 번호는 일반적으로 25입니다. TLS가 사용 설정된 SMTP의 경우 465인 경우가 많지만 SMTP 제공업체에 문의하세요.

아래 표에서는 Edge 구성요소별로 방화벽에서 열어야 하는 포트를 보여줍니다.

구성요소

포트

설명

표준 HTTP 포트

80, 443

HTTP 및 가상 호스트에 사용하는 기타 포트

관리 서버

8080

Edge 관리 API 호출을 위한 포트입니다. 라우터, 메시지 프로세서, UI, Postgres, Qpid 등의 구성요소를 사용하려면 관리 서버의 포트 8080에 액세스해야 합니다.

1099

JMX 포트

4526

분산 캐시 및 관리 호출의 경우

관리 UI

9,000

관리 UI에 대한 브라우저 액세스 포트

메시지 프로세서

8998

라우터와의 통신을 위한 메시지 프로세서 포트

8082

메시지 프로세서의 기본 관리 포트로, 관리 서버가 액세스하려면 구성요소에서 열려 있어야 합니다.

라우터와 메시지 프로세서 사이에 TLS/SSL을 구성하는 경우, 라우터가 메시지 프로세서의 상태를 확인하는 데 사용합니다.

1101

JMX 포트

4528

메시지 프로세서 간의 분산 캐시 및 관리 호출과 라우터와 관리 서버로부터의 통신용

라우터

8081

라우터의 기본 관리 포트이며, 관리 서버가 액세스할 수 있도록 구성요소에서 열려 있어야 합니다.

4527

분산 캐시 및 관리 호출의 경우

15999

상태 점검 포트 부하 분산기는 이 포트를 사용하여 라우터를 사용할 수 있는지 확인합니다.

라우터의 상태를 가져오기 위해 부하 분산기는 라우터에서 포트 15999에 요청합니다.

> curl -v http://<routerIP>:15999/v1/servers/self/reachable

라우터에 연결할 수 있으면 요청에서 HTTP 200이 반환됩니다.

59001

apigee-validate 유틸리티에서 Edge 설치를 테스트하는 데 사용되는 포트입니다. 이 유틸리티는 라우터의 포트 59001에 액세스해야 합니다. 포트 59001에 관한 자세한 내용은 설치 테스트를 참고하세요.

ZooKeeper

2181

관리 서버, 라우터, 메시지 프로세서 등의 다른 구성요소에서 사용됩니다.

2888, 3888

JoKeeper 클러스터 (ZooKeeper 앙상블이라고 함) 커뮤니케이션을 위해 내부적으로 주Keeper에서 사용됩니다.

Cassandra

7000, 9042, 9160

Cassandra 노드 간 통신 및 다른 Edge 구성요소의 액세스를 위한 Apache Cassandra 포트

7199

JMX 포트. 관리 서버에서 액세스할 수 있도록 열려 있어야 합니다.

Qpid

5672

라우터 및 메시지 프로세서에서 Qpid 서버로의 통신에 사용됨

8083

Qpid 서버의 기본 관리 포트로, 관리 서버가 액세스하려면 구성요소에서 열려 있어야 합니다.

1102

JMX 포트

4529

분산 캐시 및 관리 호출의 경우

Postgres

5432

Qpid/관리 서버에서 Postgres로의 통신에 사용됩니다.

8084

Postgres 서버의 기본 관리 포트이며 관리 서버가 액세스할 수 있도록 구성요소에서 열려 있어야 합니다.

1103

JMX 포트

4530

분산 캐시 및 관리 호출의 경우

22

마스터-대기 복제를 사용하도록 Postgres 노드 2개를 구성하는 경우 SSH 액세스를 위해 각 노드에서 포트 22를 열어야 합니다.

LDAP

10389

OpenLDAP

SmartDocs

59002

SmartDocs 페이지 요청이 전송되는 에지 라우터의 포트입니다.

다음 표에는 동일한 포트가 소스 및 대상 구성요소와 함께 숫자로 표시되어 있습니다.

포트 번호

목적

소스 구성요소

대상 구성요소

<가상 호스트 포트#>

HTTP 및 가상 호스트 API 호출 트래픽에 사용하는 기타 포트 포트 80 및 443이 가장 일반적으로 사용되며, 메시지 라우터는 TLS/SSL 연결을 종료할 수 있습니다.

외부 클라이언트 (또는 부하 분산기)

메시지 라우터의 리스너

1099~1103

JMX 관리

JMX 클라이언트

관리 서버 (1099)

메시지 프로세서 (1101)

Qpid 서버 (1102)

Postgres 서버 (1103)

2,181개

Jokeeper 클라이언트 통신

관리 서버

라우터

메시지 프로세서

Qpid 서버

Postgres 서버

Zookeeper

2888 및 3888

Jokeeper 노드 간 관리

Zookeeper

Zookeeper

4,526

RPC 관리 포트

관리 서버

관리 서버

4,527명 분산 캐시 및 관리 호출과 라우터 간 통신을 위한 RPC 관리 포트

관리 서버

라우터

라우터

4,528

메시지 프로세서 간의 분산 캐시 호출 및 라우터와의 통신용

관리 서버

라우터

메시지 프로세서

메시지 프로세서

4,529개 분산 캐시 및 관리 호출을 위한 RPC 관리 포트 관리 서버 Qpid 서버
4,530 분산 캐시 및 관리 호출을 위한 RPC 관리 포트 관리 서버 Postgres 서버

5,432

Postgres 클라이언트

Qpid 서버

Postgres

5,672

라우터 및 메시지 프로세서에서 Qpid로 분석을 전송하는 데 사용됩니다.

라우터

메시지 프로세서

Qpid 서버

7000

Cassandra 노드 간 통신

Cassandra

다른 Cassandra 노드

7,199개

JMX 관리. Cassandra 노드에서 관리 서버가 액세스할 수 있도록 열려 있어야 합니다.

JMX 클라이언트

Cassandra

8,080

Management API 포트

Management API 클라이언트

관리 서버

8081~8084

개별 구성요소에 직접 API 요청을 전송하는 데 사용되는 구성요소 API 포트입니다. 각 구성요소는 다른 포트를 엽니다. 사용되는 정확한 포트는 구성에 따라 다르지만 관리 서버에서 액세스하려면 구성요소에서 열려 있어야 합니다.

Management API 클라이언트

라우터 (8081)

메시지 프로세서 (8082)

Qpid Server (8083)

Postgres 서버 (8084)

8,998개

라우터와 메시지 프로세서 간 통신

라우터

메시지 프로세서

9,000명

기본 에지 관리 UI 포트

탐색자

관리 UI 서버

9,042개

CQL 네이티브 전송

라우터

메시지 프로세서

관리 서버

Cassandra

9,160

Cassandra 중고 클라이언트

라우터

메시지 프로세서

관리 서버

Cassandra

10,389

LDAP 포트

관리 서버

OpenLDAP

15,999개

상태 점검 포트 부하 분산기는 이 포트를 사용하여 라우터를 사용할 수 있는지 확인합니다.

부하 분산기 라우터
59,001 apigee-validate 유틸리티에서 Edge 설치를 테스트하는 데 사용하는 포트입니다. apigee-validate 라우터

59,002

SmartDocs 페이지 요청이 전송되는 라우터 포트

SmartDocs

라우터

메시지 프로세서는 시간 초과가 발생하지 않도록 구성된 Cassandra에 전용 연결 풀을 열어 둡니다. 방화벽이 메시지 프로세서와 Cassandra 서버 사이에 있으면 방화벽에서 연결 제한 시간을 초과할 수 있습니다. 그러나 메시지 프로세서는 Cassandra에 다시 연결을 설정하도록 설계되지 않았습니다.

이러한 상황을 방지하기 위해 Apigee에서는 Cassandra 서버, 메시지 프로세서, 라우터를 동일한 서브넷에 설정하여 방화벽이 이러한 구성요소의 배포에 관여하지 않도록 할 것을 권장합니다.

방화벽이 라우터와 메시지 프로세서 사이에 있고 유휴 TCP 제한 시간이 설정되어 있는 경우 권장사항은 다음과 같습니다.

  1. Linux OS의 sysctl 설정에서 net.ipv4.tcp_keepalive_time = 1800을 설정합니다. 여기서 1800은 방화벽 유휴 TCP 제한 시간보다 낮아야 합니다. 이 설정은 방화벽이 연결을 해제하지 않도록 연결을 설정된 상태로 유지해야 합니다.
  2. 모든 메시지 프로세서에서 /<inst_root>/apigee/customer/application/message-processor.properties를 수정하여 다음 속성을 추가합니다. 파일이 없으면 새로 만듭니다.
    conf_system_cassandra.maxconnecttimeinmillis=-1
  3. 메시지 프로세서를 다시 시작합니다.
    > /opt/apigee/apigee-service/bin/apigee-service Edge-message-processor restart
  4. 모든 라우터에서 /<inst_root>/apigee/customer/application/router.properties를 수정하여 다음 속성을 추가합니다. 파일이 없으면 새로 만듭니다.
    conf_system_cassandra.maxconnecttimeinmillis=-1
  5. 라우터를 다시 시작합니다.
    > /opt/apigee/apigee-service/bin/apigee-service Edge-router restart

두 개의 데이터 센터가 있는 12개의 호스트 클러스터링 구성을 설치하는 경우 두 개의 데이터 센터의 노드가 아래에 표시된 포트를 통해 통신할 수 있는지 확인합니다.

API BaaS 포트 요구사항

API BaaS를 설치하려면 API BaaS 스택 및 API BaaS 포털 구성요소를 추가합니다. 이러한 구성요소는 아래 그림에 표시된 포트를 사용합니다.

이 다이어그램의 참고사항:

  • API BaaS 포털은 BaaS Stack 노드에 직접 요청하지 않습니다. 개발자가 포털에 로그인하면 포털 앱이 브라우저에 다운로드됩니다. 그러면 브라우저에서 실행되는 포털 앱이 BaaS 스택 노드에 요청을 전송합니다.
  • API BaaS의 프로덕션 설치에서는 API BaaS 포털 노드와 API BaaS 스택 노드 사이에 부하 분산기를 사용합니다. 포털을 구성할 때 그리고 BaaS API를 호출할 때 스택 노드가 아닌 부하 분산기의 IP 주소 또는 DNS 이름을 지정합니다.
  • 다른 모든 스택 노드에서 액세스하려면 모든 스택 노드는 포트 2551을 열어야 합니다 (스택 노드의 포트 2551에 대해 위 다이어그램에서 루프 화살표로 표시됨). 데이터 센터가 여러 개 있는 경우 모든 데이터 센터의 모든 스택 노드에서 포트에 액세스할 수 있어야 합니다.
  • 외부 SMTP 서버를 통해 이메일을 보내도록 모든 Baas 스택 노드를 구성해야 합니다. 비 TLS SMTP의 경우 포트 번호는 일반적으로 25입니다. TLS가 사용 설정된 SMTP의 경우 465인 경우가 많지만 SMTP 제공업체에 문의하세요.
  • Cassandra 노드는 API BaaS 전용으로 사용되거나 Edge와 공유될 수 있습니다.

아래 표는 방화벽에서 열어야 하는 기본 포트를 구성요소별로 보여줍니다.

구성요소

포트

설명

API BaaS 포털

9,000

API BaaS UI의 포트

API BaaS 스택

8080

API 요청이 수신된 포트

2551

모든 스택 노드 간의 통신을 위한 포트입니다. 데이터 캔터의 다른 모든 스택 노드에서 액세스할 수 있어야 합니다.

데이터 센터가 여러 개 있는 경우 모든 데이터 센터의 모든 스택 노드에서 포트에 액세스할 수 있어야 합니다.

ElasticSearch

9,200~9,400

API BaaS 스택과 통신하고 ElasticSearch 노드 간에 통신하기 위해

라이선스

Edge를 설치할 때마다 Apigee에서 가져오는 고유한 라이선스 파일이 필요합니다. 관리 서버를 설치할 때 라이선스 파일의 경로(예: /tmp/license.txt)를 제공해야 합니다.

설치 프로그램이 라이선스 파일을 /<inst_root>/apigee/customer/conf/license.txt에 복사합니다.

라이선스 파일이 유효하면 관리 서버가 만료 시간과 허용된 메시지 프로세서 (MP) 수를 검증합니다. 라이선스 설정이 만료된 경우 /<inst_root>/apigee/var/log/edge-management-server/logs 위치에서 로그를 찾을 수 있습니다. 이 경우 Apigee 지원팀에 문의하여 마이그레이션 세부정보를 확인하세요.

아직 라이선스가 없는 경우 여기에서 영업팀에 문의하세요.