행성, 리전, 포드, 조직, 환경, 가상 호스트에 대한 정보

Private Cloud용 Edge v4.18.05

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

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

구성요소 포함 연결된 리소스 수 기본값
행성 하나 이상의 리전 해당 사항 없음
리전 하나 이상의 포드 'dc-1'
포드 하나 이상의 Edge 구성요소 '중앙'
'게이트웨이'
'분석'
Organization 하나 이상의 환경 메시지 프로세서가 포함된 하나 이상의 포드와 조직 관리자로서의 역할을 하는 사용자 없음
환경 하나 이상의 가상 호스트 상위 조직과 연결된 포드의 메시지 프로세서 1개 이상 없음
가상 호스트 하나 이상의 호스트 별칭 없음

행성 정보

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

리전 정보

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

리전 리전의 포드
'dc-1' '게이트웨이', '중앙', '분석'

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

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

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

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

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

포드 정보

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

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

포드 에지 구성요소

Cassandra 데이터 스토어
'게이트웨이' 라우터, 메시지 프로세서 cache-datastore
counter-datastore
dc-datastore 		keyvaluemap-datastore
kms-datastore
"central" 관리 서버, Zookeeper, LDAP, UI, Qpid application-datastore
apimodel-datastore
audit-datastore
auth-datastore		 identityzone-datastore
edgenotification-datastore
management-server
scheduler-datastore
user-settings-datastore
'분석' Postgres analytics-datastore reportcrud-datastore

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

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

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

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

다음 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

Apigee는 다음과 유사한 출력을 반환합니다.

[ {
  "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 계정의 모든 객체에 대한 컨테이너입니다. 조직은 하나 이상의 포드와 연결되며, 각 포드에는 하나 이상의 메시지 프로세서가 포함되어야 합니다.

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를 모두 연결하여 프로덕션 수준의 볼륨을 처리합니다.

환경에 할당된 메시지 프로세서는 모두 동일한 포드에서 가져올 수도 있고 여러 리전과 데이터 센터에 걸쳐 여러 포드에서 가져올 수도 있습니다. 예를 들어 조직에서 세 지역의 메시지 프로세서를 포함하는 환경 '전 세계'를 정의합니다. 즉, 미국, 일본, 독일의 세 가지 데이터 센터가 포함됩니다.

'전체' 환경에 API 프록시를 배포하면 API 프록시가 세 데이터 센터의 모든 메시지 프로세서에서 실행됩니다. 이러한 데이터 센터 중 하나의 라우터에 도착하는 API 트래픽은 라우터가 동일한 팟의 메시지 프로세서로만 트래픽을 전달하므로 해당 데이터 센터의 메시지 프로세서로만 전달됩니다.

가상 호스트 정보

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

가상 호스트에서 지정한 포트 번호가 라우터 노드에서 열려 있는지 확인합니다. 그런 다음 다음 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 설치 프로세스를 완료한 후 일반적으로 '온보딩' 프로세스를 통해 조직, 환경, 가상 호스트를 만듭니다. 온보딩을 실행하려면 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

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

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