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

Edge for Private Cloud v. 4.17.05

Uma instalação local da nuvem privada do Edge, ou instância do Edge, consiste em várias Componentes de borda 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 um Instância de borda:

A tabela a seguir descreve essas relações:

Sobre os planetas

Um planet 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. Não é preciso criar ou configurar 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, conforme a tabela a seguir mostra:

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

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

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 de trânsito da rede. Em neste cenário, você hospeda endpoints de API de modo que fiquem geograficamente “próximos” da e os consumidores dessas APIs.

No Edge, cada região é chamada de data center. Um data center O leste dos EUA pode então 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. A borda podem ser instalados no mesmo nó, mas são mais comumente 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 com cada pod:

Os componentes do Edge e os repositórios de dados do Cassandra no "gateway" um pod são necessários para processamento. Esses componentes e repositórios de dados devem estar em execução para processar solicitações de API. A e repositórios de dados na região "central" e "analytics" os pods não precisam processar APIs, mas adicionar outras funcionalidades ao Edge.

A imagem a seguir mostra os componentes de cada pod:

É possível adicionar outros pods de Processador de Mensagens e de Roteador aos três pods criados pelo padrão. Como alternativa, é possível adicionar outros componentes do Edge a um pod atual. Por exemplo: é possível adicionar outros roteadores e processadores de mensagens ao "gateway" que o pod lida com aumentos no tráfego de rede.

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

Você pode usar a seguinte chamada de API para visualizar os detalhes do registro do servidor no final do para 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 é:

• gateway
• central
• estatísticas

Por exemplo, para o "gateway" pod:

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

Você verá a saída no formulário:

[ {
  "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 do componente. Observe que ele lista os arquivos do Cassandra de dados registrados no pod. Enquanto os nós do Cassandra estiverem instalados no "gateway" bando, você 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, em que cada pod precisa conter um ou mais processadores de mensagens.

Em uma instalação local da nuvem privada de borda, não há organizações por padrão. 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 usuários à organização e defina o papel de cada um deles.
2. O "gateway" pod, o pod 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 que você crie dois ambientes: "teste" 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, mapa de chave-valor (KVM) os dados estão disponíveis no nível da organização, ou seja, de todos os ambientes. Outros recursos, como o armazenamento em cache, têm escopo de um ambiente específico. Os dados de análise da Apigee são particionados por uma combinação de organização e ambiente.

Abaixo estão os principais objetos de uma organização, incluindo aqueles definidos globalmente no 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. Você pode pense em um ambiente como um conjunto nomeado de processadores de mensagens em que proxies de API são executados. Todas pode ser associado aos mesmos processadores de mensagens ou a 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 da API para o ambiente. Mensagens Os processadores 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 o "gateway" pod com o ambiente. Como alternativa, você pode especificar um subconjunto os processadores de mensagens disponíveis para que os processadores de mensagens processem solicitações para diferentes e ambientes de teste.

Um processador de mensagens pode ser associado a múltiplos ambientes. Por exemplo, o Edge contém dois processadores de mensagens: A e B. Em seguida, você vai criar três ambientes organização: "dev", "test" e "prod":

• Para a versão "dev", ambiente, você associa o processador de mensagens A porque não espera que uma com um grande volume de tráfego.
• Para o "teste", ambiente, você associa o processador de mensagens B porque não espera que uma com um grande volume de tráfego.
• Para "prod" ambiente de nuvem, você associa os processadores de mensagens A e B para lidar volume da produção.

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

Implantar um proxy de API no ambiente "global" ambiente faz com que o proxy de API seja executado no Message Processadores nos três data centers o tráfego de API que chega a um roteador em qualquer um dos os data centers do Google seriam direcionados somente aos processadores de mensagens direciona o tráfego apenas para processadores de mensagens no mesmo pod.

Sobre hosts virtuais

Um host virtual define a porta no Edge Router em que um proxy de API é exposto, e, por extensão, o URL que os apps usam para acessar o proxy da 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. Você pode Em seguida, acesse um proxy de API fazendo uma solicitação para:

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 oferece suporte a TLS/SSL, use HTTPS. Se o host virtual não oferecer suporte a TLS/SSL, use HTTP.
• <routerIP>:<port> é o IP e o número da porta do host virtual.
• {proxy-base-path} e {resource-name} foram definidos quando você criar o 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, defina 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 deve criar um alias de host para o host virtual que corresponda ao nome de domínio do DNS entrada. No exemplo acima, você especificaria um alias de host de myAPI.myCo.com. Se você não tiver uma entrada DNS, defina o alias do host como o endereço IP do roteador e a porta host virtual, como <routerIP>:port.

Para mais informações, acesse http://apigee.com/docs/api-services/content/virtual-hosts (em inglês).

Ao criar sua primeira organização, e host virtual

Depois de concluir o processo de instalação do Edge, sua primeira ação é criar um organização, ambiente e host virtual por meio da integração de desenvolvimento de software. Para realizar 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 toma como entrada um arquivo de configuração que define um usuário, uma organização, um ambiente e 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 denominado prod que está associado a todas as Processadores no "gateway" bando
• Um host virtual no ambiente chamado default que permite o acesso HTTP na porta 9.001
• Alias de host do host virtual

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

http://<router-ip>:9001/{proxy-base-path}/{resource-name}

Posteriormente, será possível adicionar qualquer número de organizações, ambientes e hosts virtuais.

Para mais informações sobre integração, consulte Integrar um organização.