플래닛, 리전, 포드, 조직, 환경, 가상 호스트 정보

Private Cloud용 Edge v4.18.01

Edge Private Cloud의 온프레미스 설치 또는 Edge 인스턴스는 서버 노드 집합에 설치되는 여러 Edge 구성요소로 구성됩니다. 다음 이미지는 Edge 인스턴스를 구성하는 지구, 리전, 포드, 조직, 환경, 가상 호스트 간의 관계를 보여줍니다.

다음 표에서는 이러한 관계를 설명합니다.

포함 연결 대상 기본
지구 하나 이상의 리전 해당 사항 없음
리전 하나 이상의 포드 'dc-1'
포드 하나 이상의 Edge 구성요소 "central"
"gateway"
"analytics"
Organization 하나 이상의 환경 메시지 프로세서가 포함된 하나 이상의 포드와 조직 관리자 역할을 하는 사용자 없음
환경 하나 이상의 가상 호스트 상위 조직과 연결된 포드에 있는 하나 이상의 메시지 프로세서 없음
가상 호스트 하나 이상의 호스트 별칭 없음

행성 정보

지구는 전체 Edge 하드웨어 및 소프트웨어 환경을 나타내며 리전을 하나 이상 포함할 수 있습니다. Edge에서 지구는 리전의 논리적 그룹입니다. Edge를 설치하는 과정에서 명시적으로 지구를 만들거나 구성하지 않습니다.

'지역' 정보

리전은 하나 이상의 포드를 그룹화한 것입니다. 기본적으로 Edge를 설치하면 설치 프로그램이 다음 표와 같이 3개의 포드가 포함된 'dc-1'이라는 단일 리전을 만듭니다.

리전 리전의 포드
'dc-1' '게이트웨이', 'central', '애널리틱스'

다음 이미지는 기본 리전을 보여줍니다.

이 이미지는 트래픽을 '게이트웨이' 포드로 전달하는 부하 분산기를 보여줍니다. '게이트웨이' 포드에는 API 요청을 처리하는 에지 라우터 및 메시지 프로세서 구성요소가 포함됩니다. 데이터 센터를 여러 개 정의하지 않는 한 리전을 추가로 만들 필요가 없습니다.

보다 복잡한 설치에서는 리전을 두 개 이상 만들 수 있습니다. 여러 리전을 만드는 이유 중 하나는 머신을 지리적으로 구성하여 네트워크 전송 시간을 최소화하기 위해서입니다. 이 시나리오에서는 API 엔드포인트를 호스팅하여 이러한 API 소비자와 지리적으로 가까이 있도록 합니다.

Edge에서는 각 리전을 데이터 센터라고 합니다. 그러면 미국 동부의 데이터 센터에서 매사추세츠주 보스턴에서 도착하는 요청을 처리할 수 있고, 싱가포르의 데이터 센터에서는 아시아의 기기 또는 컴퓨터에서 수신되는 요청을 처리할 수 있습니다.

예를 들어 다음 이미지는 두 데이터 센터에 해당하는 두 리전을 보여줍니다.

포드 정보

포드는 하나 이상의 Edge 구성요소와 Cassandra Datastore를 그룹화한 것입니다. Edge 구성요소는 동일한 노드에 설치할 수 있지만 일반적으로 다른 노드에 설치됩니다. Cassandra 데이터 스토어는 포드의 에지 구성요소가 사용하는 데이터 저장소입니다.

기본적으로 Edge를 설치하면 설치 프로그램이 3개의 포드를 만들고 다음 Edge 구성요소 및 Cassandra 데이터 스토어를 각 포드와 연결합니다.

포드 에지 구성요소

Cassandra Datastore
"gateway" 라우터, 메시지 프로세서 cache-datastore
counter-datastore
dc-datastore 		키-값맵-데이터 저장소
kms-데이터 저장소
"central" 관리 서버, 동물원키퍼, LDAP, UI, Qpid application-datastore
apimodel-datastore
audit-datastore
auth-datastore		 Identityzone-datastore
edgenotification-datastore
management-server
scheduler-datastore
user-settings-datastore
"analytics" Postgres analytics-datastore reportcrud-datastore

'게이트웨이' 포드의 Edge 구성요소와 Cassandra 데이터 스토어는 API 처리에 필요합니다. API 요청을 처리하려면 이러한 구성요소와 데이터 스토어가 실행 중이어야 합니다. 'central' 및 'analytics' 포드의 구성요소와 Datastore는 API를 처리하는 데 필요하지 않지만 Edge에 기능을 추가합니다.

다음 이미지는 각 광고 모음의 구성요소를 보여줍니다.

기본적으로 생성되는 3개에 메시지 프로세서 및 라우터 포드를 추가할 수 있습니다. 또는 기존 포드에 Edge 구성요소를 더 추가할 수 있습니다. 예를 들어 '게이트웨이' 포드에 라우터와 메시지 프로세서를 추가하여 늘어난 트래픽 부하를 처리할 수 있습니다.

'게이트웨이' 포드에는 에지 라우터 및 메시지 프로세서 구성요소가 포함되어 있습니다. 라우터는 동일한 포드에 있는 메시지 프로세서에만 요청을 전송하고 다른 포드의 메시지 프로세서에는 요청을 전송하지 않습니다.

다음 API 호출을 사용하여 각 포드의 설치가 끝날 때 서버 등록 세부정보를 볼 수 있습니다. 유용한 모니터링 도구입니다.

curl -u adminEmail:pword http://<ms_IP>:8080/v1/servers?pod=podName

여기서 ms_IP는 관리 서버의 IP 주소 또는 DNS 이름이고 podName은 다음 중 하나입니다.

  • gateway
  • central
  • analytics

'게이트웨이' 포드의 경우를 예로 들어보겠습니다.

> curl -u adminEmail:pword http://<ms_IP>:8080/v1/servers?pod=gateway

다음과 같은 형식으로 출력이 표시됩니다.

[ {
  "externalHostName" : "localhost",
  "externalIP" : "192.168.1.11",
  "internalHostName" : "localhost",
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ {
      "name" : "jmx.rmi.port",
      "value" : "1101"
    }, ... ]
  },
  "type" : [ "message-processor" ],
  "uUID" : "276bc250-7dd0-46a5-a583-fd11eba786f8"
}, 
{
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ ]
  },
  "type" : [ "dc-datastore", "management-server", "cache-datastore", "keyvaluemap-datastore", "counter-datastore", "kms-datastore" ],
  "uUID" : "13cee956-d3a7-4577-8f0f-1694564179e4"
},
{
  "externalHostName" : "localhost",
  "externalIP" : "192.168.1.11",
  "internalHostName" : "localhost",
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ {
      "name" : "jmx.rmi.port",
      "value" : "1100"
    }, ... ]
  },
  "type" : [ "router" ],
  "uUID" : "de8a0200-e405-43a3-a5f9-eabafdd990e2"
} ]

type 속성은 구성요소 유형을 나열합니다. 여기에는 포드에 등록된 Cassandra 데이터 스토어가 나열됩니다. Cassandra 노드가 '게이트웨이' 포드에 설치되는 동안 모든 포드에 등록된 Cassandra 데이터 스토어가 표시됩니다.

조직 정보

조직은 API, API 제품, 앱, 개발자를 포함한 Apigee 계정의 모든 객체를 담은 컨테이너입니다. 조직은 하나 이상의 포드와 연결되어 있으며, 각 포드에는 1개 이상의 메시지 프로세서가 포함되어야 합니다.

Edge Private Cloud의 온프레미스 설치에는 기본적으로 조직이 없습니다. 조직을 만들 때 다음 두 가지 정보를 지정해야 합니다.

  1. 조직 관리자 역할을 하는 사용자입니다. 그런 다음 해당 사용자는 조직에 사용자를 추가하고 각 사용자의 역할을 설정할 수 있습니다.
  2. '게이트웨이' 포드, 메시지 프로세서를 포함하는 포드.

조직에는 하나 이상의 환경이 포함될 수 있습니다. 기본 Edge 설치 절차에서 'test'와 'prod'라는 두 가지 환경을 만들라는 메시지가 표시됩니다. 하지만 필요에 따라 '스테이징', '실험' 등의 추가 환경을 만들 수 있습니다.

조직은 일부 Apigee 기능의 범위를 제공합니다. 예를 들어 키-값 맵 (KVM) 데이터는 조직 수준, 즉 모든 환경에서 사용할 수 있습니다. 캐싱과 같은 다른 기능은 특정 환경으로 범위가 지정됩니다. Apigee 분석 데이터는 조직 및 환경의 조합으로 파티션이 나뉩니다.

아래에는 조직에서 전역적으로 정의된 객체 및 환경에 구체적으로 정의된 객체를 포함한 조직의 주요 객체가 나와 있습니다.

환경 정보

환경은 조직의 API 프록시에 대한 런타임 실행 컨텍스트입니다. 환경에 액세스하려면 API 프록시를 환경에 배포해야 합니다. API 프록시를 단일 환경 또는 여러 환경에 배포할 수 있습니다.

한 조직에 여러 환경이 포함될 수 있습니다. 예를 들어 조직의 'dev', 'test', 'prod' 환경을 정의할 수 있습니다.

환경을 만들 때 하나 이상의 메시지 프로세서와 연결합니다. 환경을 API 프록시가 실행되는 메시지 프로세서의 이름이 지정된 집합이라고 생각하면 됩니다. 모든 환경은 동일한 메시지 프로세서 또는 서로 다른 메시지 프로세서와 연결될 수 있습니다.

환경을 만들려면 다음 두 가지 정보를 지정합니다.

  1. 환경이 포함된 조직입니다.
  2. 환경에 대한 API 프록시 요청을 처리하는 메시지 프로세서 이러한 메시지 프로세서는 환경의 상위 조직과 연결된 포드에 있어야 합니다.
    기본적으로 환경을 만들면 Edge가 '게이트웨이' 포드에서 사용 가능한 모든 메시지 프로세서를 환경과 연결합니다. 또는 사용 가능한 메시지 프로세서의 하위 집합을 지정하여 서로 다른 메시지 프로세서가 서로 다른 환경에 대한 요청을 처리하도록 할 수 있습니다.

메시지 프로세서는 여러 환경과 연결될 수 있습니다. 예를 들어 Edge 설치에 A와 B라는 두 개의 메시지 프로세서가 포함되어 있다고 가정하겠습니다. 그런 다음 조직에 'dev', 'test', 'prod'라는 세 가지 환경을 만듭니다.

  • 'dev' 환경에서는 대량의 트래픽을 예상하지 못하므로 메시지 프로세서 A를 연결합니다.
  • '테스트' 환경에서는 대량의 트래픽을 예상하지 않으므로 메시지 프로세서 B를 연결합니다.
  • 'prod' 환경의 경우 메시지 프로세서 A와 B를 모두 연결하여 프로덕션 수준의 볼륨을 처리합니다.

환경에 할당된 메시지 프로세서는 모두 동일한 포드에 있거나 여러 리전 및 데이터 센터에 걸쳐 있는 여러 포드에 있을 수 있습니다. 예를 들어 3개 리전(미국, 일본, 독일)의 메시지 프로세서 3개를 포함하는 조직 환경을 '전역'으로 정의합니다.

API 프록시를 '전역' 환경에 배포하면 API 프록시가 데이터 센터 3곳 모두의 메시지 프로세서에서 실행됩니다. 이러한 데이터 센터 중 하나의 라우터에 도착하는 API 트래픽은 해당 데이터 센터의 메시지 프로세서로만 전달됩니다. 라우터는 동일한 포드에 있는 메시지 프로세서로만 트래픽을 전달하기 때문입니다.

가상 호스트 정보

가상 호스트는 API 프록시가 노출되는 에지 라우터의 포트 및 더 나아가 앱이 API 프록시에 액세스하는 데 사용하는 URL을 정의합니다. 모든 환경은 하나 이상의 가상 호스트를 정의해야 합니다.

가상 호스트에서 지정한 포트 번호가 라우터 노드에서 열려 있는지 확인합니다. 그런 다음 다음을 요청하여 API 프록시에 액세스할 수 있습니다.

http://routerIP:port/proxy-base-path/resource-name
https://routerIP:port/proxy-base-path/resource-name

각 항목의 의미는 다음과 같습니다.

  • http 또는 https: 가상 호스트가 TLS/SSL을 지원하도록 구성된 경우 HTTPS를 사용합니다. 가상 호스트가 TLS/SSL을 지원하지 않으면 HTTP를 사용합니다.
  • routerIP:port는 가상 호스트의 IP 주소와 포트 번호입니다.
  • proxy-base-path 및 resource-name는 API 프록시를 만들 때 정의됩니다.

일반적으로 개발자는 IP 주소와 포트 번호를 사용해 고객에게 API를 게시하지 않습니다. 대신 라우터와 포트에 대한 DNS 항목을 정의합니다. 예를 들면 다음과 같습니다.

http://myAPI.myCo.com/proxy-base-path/resource-name
https://myAPI.myCo.com/proxy-base-path/resource-name

또한 DNS 항목의 도메인 이름과 일치하는 가상 호스트의 호스트 별칭을 만들어야 합니다. 위의 예에서 myAPI.myCo.com의 호스트 별칭을 지정합니다. DNS 항목이 없으면 호스트 별칭을 라우터의 IP 주소와 가상 호스트의 포트(routerIP:port)로 설정합니다.

자세한 내용은 가상 호스트 정보를 참고하세요.

첫 번째 조직, 환경, 가상 호스트 만들기

Edge 설치 프로세스를 완료한 후 첫 번째 작업은 일반적으로 '온보딩' 프로세스를 통해 조직, 환경, 가상 호스트를 만드는 것입니다. 온보딩을 수행하려면 에지 관리 서버 노드에서 다음 명령어를 실행합니다.

/opt/apigee/apigee-service/bin/apigee-service apigee-provision setup-org -f configFile

이 명령어는 사용자, 조직, 환경, 가상 호스트를 정의하는 구성 파일을 입력으로 사용합니다.

예를 들어 다음을 만듭니다.

  • 조직 관리자 역할을 하도록 선택한 사용자
  • 이름이 example인 조직
  • '게이트웨이' 포드의 모든 메시지 프로세서와 연결된 prod라는 조직의 환경
  • 포트 9001에서 HTTP 액세스를 허용하는 default라는 환경의 가상 호스트
  • 가상 호스트의 호스트 별칭

스크립트를 실행한 후 다음 형식의 URL을 사용하여 API에 액세스할 수 있습니다.

http://routerIP:9001/proxy-base-path/resource-name

나중에 원하는 수의 조직, 환경, 가상 호스트를 추가할 수 있습니다.

자세한 내용은 조직 온보딩을 참고하세요.