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

Edge para nuvem privada v4.18.05

Uma instalação local do Edge para nuvem privada 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 o planeta, as regiões, os pods, as organizações, os ambientes e os hosts virtuais que compõem uma instância do Edge:

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 com 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 mãe nenhum
Host virtual Um ou mais aliases de host nenhum

Sobre os planetas

Um planeta representa um ambiente de hardware e software completo 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 nem configura um planeta explicitamente como parte da instalação do Edge.

Sobre as regiões

Uma regiã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" contendo 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:

Esta 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 solicitações de API. A menos que você defina vários data centers, não será necessário criar regiões adicionais.

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

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

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

Sobre os pods

Um pod é um agrupamento de um ou mais componentes do Edge e Datastores do Cassandra. Os componentes do Edge podem ser instalados no mesmo nó, mas geralmente são instalados em nós diferentes. Um repositório de dados do Cassandra é um repositório de dados 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 data stores do Cassandra a cada pod:

Pod Componentes de borda

Armazenamentos de dados do Cassandra
"gateway" Roteador, processador de mensagens cache-datastore
counter-datastore
dc-datastore 		keyvaluemap-datastore
kms-datastore
"central" Servidor de gerenciamento, Zookeeper, LDAP, interface, 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 precisam estar ativos para processar solicitações de API. Os componentes e os repositórios de dados nos pods "central" e "analytics" não são necessários para processar APIs, mas adicionam mais funcionalidades ao Edge.

A imagem a seguir mostra os componentes em cada pod:

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

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 seguinte chamada de API para conferir os detalhes do registro do servidor no 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 o nome DNS do servidor de gerenciamento e podName é uma das seguintes opções:

  • gateway
  • central
  • analytics

Por exemplo, para o pod "gateway":

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

O 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. Ele lista os repositórios de dados do Cassandra registrados no pod. Enquanto os nós do Cassandra estiverem instalados no pod "gateway", você vai encontrar os repositórios de dados do Cassandra registrados em 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 é associada a um ou mais pods, em que cada pod precisa conter um ou mais processadores de mensagens.

Em uma instalação local da Edge Private Cloud, não há organizações por padrão. Ao criar uma organização, você especifica duas informações:

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

Uma organização pode conter um ou mais ambientes. O procedimento de instalação padrão do Edge solicita a criação de dois ambientes: "test" e "prod". No entanto, é possível criar mais ambientes conforme necessário, como "estágio", "experimentos" etc.

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

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

Sobre os 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. Você pode pensar 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 processadores diferentes.

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

  1. A organização que contém o ambiente.
  2. Os processadores de mensagens que processam solicitações de proxy de 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 diferentes ambientes.

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":

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

Os processadores de mensagens atribuídos a um ambiente podem ser 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 centros de dados diferentes: EUA, Japão e Alemanha.

A implantação de um proxy de API no ambiente "global" faz com que ele seja executado em processadores de mensagens nos 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 nesse data center, porque os roteadores só direcionam o tráfego para os processadores de mensagens no mesmo pod.

Sobre os 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, acesse 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 tiver suporte para TLS/SSL, use o 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 na criação do proxy de API.

Normalmente, você não publica suas APIs para clientes com um endereço IP e 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 corresponde ao nome de domínio da entrada DNS. No exemplo acima, você especificaria um alias de host de myAPI.myCo.com. Se você não tiver uma entrada de DNS, defina o alias de 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, sua 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 usa como entrada um arquivo de configuração que define um usuário, organização, ambiente e host virtual.

Por exemplo, você cria:

  • Um usuário que você escolher 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 o acesso HTTP na porta 9001
  • Alias de host para o host virtual

Depois de executar esse script, você pode acessar suas APIs usando um URL no formato:

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

Depois, você pode adicionar quantas organizações, ambientes e hosts virtuais quiser.

Para mais informações, consulte Integrar uma organização.