Sobre planetas, regiões, pods, organizações, ambientes e hosts virtuais

Edge para nuvem privada v4.18.05

Uma instalação local da nuvem privada do Edge, ou uma instância do Edge, consiste em vários componentes do Edge instalados em um conjunto de nós do servidor. A imagem a seguir mostra a relação entre planeta, regiões, pods, organizações, ambientes e hosts virtuais que compõem uma instância de borda:

A tabela a seguir descreve essas relações:

Componente Contém Associado a Padrão
Planeta Uma ou mais regiões N/A
Região Um ou mais pods “dc-1”
Pod Um ou mais componentes do Edge "central"
"gateway"
"analytics"
Organização Um ou mais ambientes Um ou mais pods contendo processadores de mensagens e um usuário atuando como administrador da organização nenhum
Ambiente Um ou mais hosts virtuais Um ou mais processadores de mensagens em um pod associado à organização pai nenhum
Host virtual Um ou mais aliases de host nenhum

Sobre os planetas

Um planeta representa um ambiente inteiro de hardware e software do Edge e pode conter uma ou mais regiões. No Edge, um planeta é um agrupamento lógico de regiões: você não cria ou configura explicitamente um planeta como parte da instalação do Edge.

Sobre as regiões

As regiões são um agrupamento de um ou mais pods. Por padrão, quando você instala o Edge, o instalador cria uma única região chamada "dc-1" que contém três pods, conforme mostrado na tabela a seguir:

Região Pods na região
“dc-1” "gateway", "central", "analytics"

A imagem a seguir mostra as regiões padrão:

A imagem mostra o balanceador de carga direcionando o tráfego para o pod "gateway". O pod "gateway" contém os componentes do roteador de borda e do processador de mensagens que processam as solicitações de API. A menos que você defina vários data centers, não será necessário criar outras regiões.

Em uma instalação mais complexa, é possível criar duas ou mais regiões. Um motivo para criar várias regiões é organizar as máquinas geograficamente, o que minimiza o tempo em trânsito da rede. Nesse cenário, você hospeda endpoints da API para que estejam geograficamente próximos dos consumidores dessas APIs.

No Edge, cada região é chamada de data center. Um data center no leste dos EUA pode lidar com solicitações que chegam de Boston, Massachusetts, enquanto um data center em Singapura pode lidar com solicitações provenientes de dispositivos ou computadores na Ásia.

Por exemplo, a imagem a seguir mostra duas regiões, que correspondem a dois data centers:

Sobre os pods

Um pod é um agrupamento de um ou mais componentes do Edge e repositórios de dados do Cassandra. Os componentes de borda podem ser instalados no mesmo nó, mas costumam ser instalados em nós diferentes. Um repositório de dados do Cassandra é usado pelos componentes do Edge no pod.

Por padrão, quando você instala o Edge, o instalador cria três pods e associa os seguintes componentes do Edge e repositórios de dados do Cassandra a cada um deles:

Pod Componentes do Edge

Repositórios de dados do Cassandra
"gateway" Roteador, processador de mensagens cache-datastore
contador-datastore
dc-datastore 		keyvaluemap-datastore
kms-datastore
"central" Management Server, Zookeeper, 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

Os componentes do Edge e os repositórios de dados do Cassandra no pod "gateway" são necessários para o processamento da API. Esses componentes e repositórios de dados devem estar em funcionamento para processar as solicitações de API. Os componentes e repositórios de dados nos pods "central" e "analytics" não são necessários para processar APIs, mas adicionam outras funcionalidades ao Edge.

A imagem a seguir mostra os componentes em cada pod:

É possível adicionar outros pods de processador de mensagens e roteador aos três criados por padrão. Também é possível adicionar outros componentes do Edge a um pod atual. Por exemplo, é possível adicionar outros roteadores e processadores de mensagens ao pod "gateway" para lidar com o aumento de cargas de tráfego.

Observe que o pod "gateway" contém os componentes do roteador de borda e do processador de mensagens. Os roteadores só enviam solicitações para processadores de mensagens no mesmo pod, e não para processadores de mensagens em outros pods.

Use a chamada de API a seguir para conferir os detalhes do registro do servidor ao final da instalação de cada pod. Essa é uma ferramenta de monitoramento útil.

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

em que ms_IP é o endereço IP ou nome DNS do servidor de gerenciamento e podName é um dos seguintes itens:

  • gateway
  • central
  • analytics

Por exemplo, para o pod "gateway":

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

A Apigee retorna uma saída semelhante a esta:

[ {
  "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"
} ]

O atributo type lista o tipo de componente. Observe que ela lista os repositórios de dados do Cassandra registrados no pod. Enquanto os nós do Cassandra estão instalados no pod "gateway", você vai ver os repositórios de dados do Cassandra registrados com todos os pods.

Sobre as organizações

Uma organização é um contêiner para todos os objetos em uma conta da Apigee, incluindo APIs, produtos de API, apps e desenvolvedores. Uma organização está associada a um ou mais pods, e cada um deles precisa conter um ou mais processadores de mensagens.

Por padrão, não há organizações em uma instalação no local da nuvem privada do Edge. Ao criar uma organização, você especifica duas informações:

  1. Um usuário que atua como administrador da organização. Esse usuário pode adicionar outros usuários à organização e definir o papel de cada um.
  2. O pod "gateway", que contém os processadores de mensagens.

Uma organização pode ter um ou mais ambientes. O procedimento padrão de instalação do Edge solicita a criação de dois ambientes: "test" e "prod". No entanto, você pode criar mais ambientes conforme necessário, como "preparação", "experimentos" etc.

A organização fornece escopo para alguns recursos da Apigee. Por exemplo, os dados de mapa de chave-valor (KVM) estão disponíveis no nível da organização, ou seja, em todos os ambientes. Outros recursos, como o armazenamento em cache, têm o escopo definido para um ambiente específico. Os dados de análise da Apigee são particionados por uma combinação de organização e ambiente.

Veja abaixo os principais objetos de uma organização, incluindo aqueles definidos globalmente na organização e aqueles definidos especificamente para um ambiente:

Sobre ambientes

Um ambiente é um contexto de execução de ambiente para os proxies de API em uma organização. Você precisa implantar um proxy de API em um ambiente antes de poder ser acessado. É possível implantar um proxy de API em um único ambiente ou em vários.

Uma organização pode conter vários ambientes. Por exemplo, você pode definir um ambiente "dev", "test" e "prod" em uma organização.

Ao criar um ambiente, você o associa a um ou mais processadores de mensagens. Pense em um ambiente como um conjunto nomeado de processadores de mensagens em que os proxies de API são executados. Cada ambiente pode ser associado aos mesmos processadores de mensagens ou a diferentes.

Para criar um ambiente, especifique estas informações:

  1. A organização que contém o ambiente.
  2. Os processadores de mensagens que processam as solicitações do proxy da API para o ambiente. Esses processadores de mensagens precisam estar em um pod associado à organização pai do ambiente.
    Por padrão, quando você cria um ambiente, o Edge associa todos os processadores de mensagens disponíveis no pod "gateway" ao ambiente. Como alternativa, especifique um subconjunto dos processadores de mensagens disponíveis para que diferentes processadores de mensagens processem solicitações para ambientes diferentes.

Um processador de mensagens pode ser associado a vários ambientes. Por exemplo, sua instalação do Edge contém dois processadores de mensagens: A e B. Em seguida, você cria três ambientes na sua organização: "dev", "test" e "prod":

  • No ambiente "dev", você associa o processador de mensagens A porque não espera um grande volume de tráfego.
  • Para o ambiente de "teste", você associa o processador de mensagens B porque não espera um grande volume de tráfego.
  • Para o ambiente "prod", associe os processadores de mensagens A e B para lidar com o volume no nível de produção.

Os processadores de mensagens atribuídos a um ambiente podem ser todos do mesmo pod ou de vários pods, abrangendo várias regiões e data centers. Por exemplo, você define o ambiente "global" na sua organização que inclui processadores de mensagens de três regiões, ou seja, três data centers diferentes: EUA, Japão e Alemanha.

A implantação de um proxy de API no ambiente "global" faz com que o proxy de API seja executado nos processadores de mensagens de todos os três data centers. O tráfego da API que chega a um roteador em qualquer um desses data centers é direcionado apenas para os processadores de mensagens dele, porque os roteadores só direcionam o tráfego para os processadores de mensagens no mesmo pod.

Sobre hosts virtuais

Um host virtual define a porta no roteador de borda em que um proxy de API é exposto e, por extensão, o URL que os apps usam para acessar o proxy de API. Cada ambiente precisa definir pelo menos um host virtual.

Verifique se o número da porta especificado pelo host virtual está aberto no nó do roteador. Em seguida, você pode acessar um proxy de API fazendo uma solicitação para os seguintes URLs:

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

Em que:

  • http ou https: se o host virtual estiver configurado para oferecer suporte a TLS/SSL, use HTTPS. Se o host virtual não for compatível com TLS/SSL, use HTTP.
  • routerIP:port é o endereço IP e o número da porta do host virtual.
  • proxy-base-path e resource-name são definidos quando você cria o proxy de API.

Normalmente, você não publica suas APIs para clientes com um endereço IP e um número de porta. Em vez disso, você define uma entrada DNS para o roteador e a porta. Exemplo:

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

Você também precisa criar um alias de host para o host virtual que corresponda ao nome de domínio da entrada de DNS. No exemplo acima, você especificaria um alias de host de myAPI.myCo.com. Se não tiver uma entrada de DNS, defina o alias do host como o endereço IP do roteador e a porta do host virtual, como routerIP:port.

Para mais informações, consulte Sobre hosts virtuais.

Como criar sua primeira organização, ambiente e host virtual

Depois de concluir o processo de instalação do Edge, a primeira ação normalmente é criar uma organização, um ambiente e um host virtual pelo processo de "integração". Para realizar a integração, execute o seguinte comando no nó do servidor de gerenciamento de borda:

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

Esse comando recebe como entrada um arquivo de configuração que define um usuário, uma organização, um ambiente e um host virtual.

Por exemplo, você cria:

  • Um usuário escolhido para atuar como administrador da organização
  • Uma organização chamada example
  • Um ambiente na organização chamado prod, associado a todos os processadores de mensagens no pod "gateway"
  • Um host virtual no ambiente chamado default que permite acesso HTTP na porta 9001
  • Alias de host para o host virtual

Depois de executar esse script, acesse suas APIs usando um URL no formato:

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

Posteriormente, você poderá adicionar quantas organizações, ambientes e hosts virtuais quiser.

Para saber mais, consulte Integrar uma organização.