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

Sobre os planetas

Um planeta representa um ambiente de hardware e software do Edge inteiro 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

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, como mostra a tabela a seguir:

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 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 de API para que eles fiquem geograficamente próximos dos consumidores dessas APIs.

No Edge, cada região é chamada de data center. Um data center no leste dos EUA pode processar solicitações que chegam de Boston, Massachusetts, enquanto um data center em Singapura pode processar solicitações originadas 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 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 repositórios de dados do Cassandra a cada pod:

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 em execução para processar 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 mais funcionalidades ao Edge.

A imagem a seguir mostra os componentes em cada pod:

É possível adicionar mais pods de processador de mensagens e roteador aos três criados por padrão. Como alternativa, é possível adicionar outros componentes do Edge a um pod. Por exemplo, é possível adicionar mais roteadores e processadores de mensagens ao pod "gateway" para lidar com o aumento das 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 seguinte chamada de API para ver 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 é um dos seguintes:

• 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 resposta 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 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 ver os armazenamentos 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 está associada a um ou mais pods, em que cada pod precisa conter um ou mais processadores de mensagens.

Em uma instalação local do 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 o papel de cada um.
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 que você crie dois ambientes: "test" e "prod". No entanto, é possível criar mais ambientes conforme necessário, como "teste", "experimentos" etc.

A organização fornece escopo para alguns recursos da Apigee. Por exemplo, os dados do mapa de chave-valor (KVM) estão disponíveis no nível da organização, ou seja, em todos os ambientes. Outros recursos, como armazenamento em cache, têm como escopo 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 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. 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 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 mãe 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, é possível especificar 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, crie 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 de "teste", você associa o processador de mensagens B porque não espera um grande volume de tráfego.
• Para o ambiente "prod", você associa 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 ele seja executado em processadores de mensagens em todos os três data centers. O tráfego de API que chega a um roteador em qualquer um desses data centers é direcionado apenas para processadores de mensagens nesse data center, porque os roteadores só direcionam o tráfego para processadores de mensagens no mesmo pod.

Sobre hosts virtuais

Um host virtual define a porta no roteador do Edge 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, é possível 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 aceitar 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 DNS. No exemplo acima, você especificaria um alias de host de myAPI.myCo.com. Se você não tiver uma entrada 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 por meio do processo de "integração". Para realizar a integração, execute o seguinte comando no nó do servidor de gerenciamento do Edge:

/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, uma organização, um ambiente e um host virtual.

Por exemplo, você cria:

• Um usuário de sua escolha para atuar como administrador da organização
• Uma organização chamada example
• Um ambiente na organização chamado prod que está 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 do host virtual

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

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

Depois, é possível adicionar qualquer número de organizações, ambientes e hosts virtuais.

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