Google Cloud Platform para usuários do OpenStack

Este artigo foi elaborado para apresentar aos usuários familiarizados com o OpenStack os principais conceitos de introdução ao Google Cloud Platform (GCP), independentemente se você pretende migrar ou implementar uma implantação híbrida.

Visão geral

Primeiramente, este artigo compara arquiteturas de aplicativos da Web de três camadas de amostra no OpenStack e no GCP e, na sequência, compara os recursos de cada um, apresentando tabelas de referência rápida que explicam como os termos e conceitos do OpenStack se correspondem aos do GCP.

Ele não compara os SDKs, as APIs ou as ferramentas de linha de comando fornecidos pelo OpenStack e GCP.

Para ver a lista completa de produtos do Google Cloud Platform, consulte Produtos e serviços.

Serviços de computação em nuvem

Eles oferecem um conjunto de serviços de linha de base, incluindo computação, armazenamento, rede, gerenciamento de acesso e, muitas vezes, serviços de banco de dados.

Os serviços de linha de base do OpenStack incluem:

  • computação: OpenStack Compute (Nova e Glance)
  • armazenamento: OpenStack Block Storage (Cinder)
  • rede: OpenStack Networking (Neutron)
  • gerenciamento de acesso e identidade: OpenStack Identity Service (Keystone)

Os serviços de linha de base do Cloud Platform incluem os seguintes:

Preços do Google Cloud Platform

A maioria dos serviços no GCP é oferecida no modelo de preços de pagamento por utilização, que inclui faturamento por segundo e por minuto, além de descontos automáticos conforme o aumento do uso. Combinado à alocação de recursos flexível, como tipos de máquinas personalizados, o modelo de preços do GCP ajuda a otimizar o desempenho eficaz e econômico dos aplicativos.

Para acessar detalhes e ferramentas de estimativa rápida de preços, consulte Calculadoras de preços.

Por que usar o Google Cloud Platform?

Nos últimos 15 anos, o Google vem criando uma das infraestruturas de nuvem mais rápidas, mais avançadas e da mais alta qualidade do planeta. Internamente, o Google usa essa infraestrutura para vários serviços de alto volume de tráfego e escala global, como Gmail, Google Maps, YouTube e Pesquisa Google. O GCP coloca essa infraestrutura à sua disposição.

Comparação de arquiteturas de amostra

Esta seção compara como você pode criar um sistema de aplicativos da Web de três camadas no OpenStack e no GCP.

  • A configuração do OpenStack resulta no modo ativo-backup.
  • A configuração do GCP usa os serviços gerenciados para resultar no modo ativo-ativo.

Um aplicativo da Web de três camadas comum consiste nos seguintes componentes:

  • balanceador de carga
  • Servidor da Web
  • Servidor de aplicativos
  • servidor de banco de dados

OpenStack: modo ativo-backup

A configuração de amostra do OpenStack mostrada na Figura 1 tem as seguintes características:

  • Você implanta recursos em duas regiões como dois domínios de falha separados para redundância.
  • A rede usa uma única sub-rede para todas as camadas em cada região, e todos os servidores são instâncias de máquina virtual (VM).
  • Você define grupos de segurança para os quatro papéis de servidor e os atribui às instâncias apropriadas.
  • Um volume do Cinder é anexado ao servidor de banco de dados como volume de dados. Para garantir a redundância nos domínios de falha, o banco de dados na região ativa é incluído no backup para armazenamento de objetos e restaurado para aquele na região de backup, quando necessário. Essa arquitetura não usa replicação de banco de dados em tempo real porque a largura de banda é limitada entre as regiões.
  • Essa arquitetura oferece o modo ativo-backup. Ao fazer o failover do serviço para outra região, você restaura o backup mais recente no servidor de banco de dados na região de backup.

App da Web de três camadas

Figura 1: sistema de aplicativos da Web de três camadas no OpenStack

GCP: modo ativo-ativo

A configuração de amostra do GCP mostrada na Figura 2 tem as seguintes características:

  • Você implanta recursos em uma única sub-rede que abrange várias zonas em uma só região para redundância.
  • Você implanta servidores da Web e de aplicativos como instâncias de VM.
  • Você define regras de firewall usando tags para especificar destinos de pacotes.
  • Você define o controle de acesso para conexão do banco de dados com base no endereço IP de origem como parte da configuração do Cloud SQL. O Cloud SQL é um serviço gerenciado pelo GCP para bancos de dados MySQL que fornece replicação de dados entre várias zonas. O backup de dados programado e o processo de failover são automatizados, e você acessa o banco de dados de várias zonas na mesma região. O failover entre zonas é transparente para os aplicativos executados nas instâncias de VM. É possível acessar uma única instância do Cloud SQL de várias zonas. O Cloud SQL tem duas gerações: Cloud SQL de Primeira geração e Cloud SQL de Segunda geração. Eles têm características e comportamentos padrão diferentes no que se refere à replicação e failover.
  • O Google Cloud Load Balancing é um serviço de balanceamento de carga HTTP(S) em que é possível usar um único endereço IP global (VIP) para distribuir o acesso do cliente a várias regiões e zonas.
  • A arquitetura oferece o modo ativo-ativo entre várias zonas, resultando em um serviço redundante em todos os domínios de falha.

App da Web de três camadas2

Figura 2: sistema de aplicativos da Web de três camadas no GCP

Comparação de recursos

Esta seção compara detalhes dos recursos usados nas arquiteturas de amostra.

Arquitetura de rede

Esta seção compara como as redes do OpenStack e do GCP funcionam nas regiões e zonas, e discute projetos, locatários, endereços IP, failover e regras de firewall.

Regiões e zonas

Veja a seguir o mapeamento dos termos e conceitos do OpenStack com os do GCP:

OpenStack GCP Observações
Região Região No OpenStack, uma região pode englobar vários data centers. No GCP, uma região corresponde a um campus de data center, que normalmente tem várias criações independentes.
Zona de disponibilidade Zona No OpenStack, uma zona de disponibilidade é normalmente usada para identificar um conjunto de servidores que têm um atributo em comum.

No GCP, uma zona corresponde a um cluster no data center.

No OpenStack, uma região é definida como um único cluster gerenciado por nodes de controlador dedicados. Uma região consiste em zonas de disponibilidade. Use essas zonas para definir vários grupos de recursos, como nodes de computação e compartimentos de armazenamento.

No GCP, região é uma área geográfica independente composta por zonas. Os locais nas regiões costumam ter latências de rede de retorno inferior a 5 ms no 95º percentil. Assim como as zonas de disponibilidade do OpenStack, uma zona é uma área de implantação de recursos do GCP em determinada região. A zona precisa ser considerada um domínio de falha único.

O GCP dispõe de uma rede interna dedicada em todas as regiões para que a largura de banda e a latência entre as diferentes zonas na mesma região sejam comparáveis às de uma única região. Você pode implantar um aplicativo de cluster estreitamente associado a várias zonas sem se preocupar com a largura de banda e a latência entre elas.

Nas duas plataformas, a implantação do aplicativo em várias zonas ou regiões pode ajudar a proteger contra falhas inesperadas. As zonas são consideradas domínios de falha independentes no GCP. Por outro lado, no OpenStack, as regiões (e não as zonas de disponibilidade) são consideradas domínios de falha independentes porque as zonas de disponibilidade em uma única região compartilham os mesmos nodes de controlador. Para ver a lista de regiões e zonas do GCP, consulte Locais do Cloud.

Projetos e locatários

Veja a seguir o mapeamento dos termos e conceitos do OpenStack com os do GCP:

OpenStack GCP Observações
Locatário Projeto Todos os recursos no GCP precisam pertencer a um projeto. Os usuários podem criar seus próprios projetos novos.

No OpenStack, somente os administradores podem criar novos locatários.

Você precisa configurar uma conta do Google para usar os serviços do GCP. O GCP agrupa o uso de serviços por projeto. Você pode criar vários projetos, totalmente diferentes, na mesma conta, e os usuários podem criar projetos próprios nas contas deles. Os recursos em um único projeto podem facilmente trabalhar juntos, por exemplo, comunicando-se por meio de uma rede interna, sujeitos às regras de regiões e zonas. Os recursos em cada projeto são isolados daqueles em outros projetos. Você pode interconectá-los apenas por meio de uma conexão de rede externa.

Esse modelo permite criar espaços no projeto para divisões ou grupos separados na empresa. Esse modelo também pode ser útil para fins de teste: após concluir um projeto, você poderá excluí-lo, e todos os recursos criados por esse projeto também serão excluídos.

O OpenStack usa o termo locatário para fazer referência à funcionalidade similar ao isolamento de recursos de grupos diferentes. No OpenStack, somente administradores de sistemas podem criar novos locatários.

Configurações de rede

Veja a seguir o mapeamento dos termos e conceitos do OpenStack com os do GCP:

OpenStack GCP Observações
Neutron Cloud Virtual Network O Cloud Virtual Network é um serviço de rede gerenciado. No GCP, é possível definir várias redes no projeto, e cada uma delas é independente.
Rede particular virtual
Rede particular virtual Uma única rede particular virtual do GCP abrange todas as regiões conectadas por meio da rede interna dele. A rede particular virtual do Neutron engloba todas as zonas de disponibilidade em uma região.

Em uma implantação comum do OpenStack Neutron, cada rede virtual do locatário é inserida em seu próprio espaço de rede particular. Conforme mostrado na Figura 1, não há necessidade de usar várias sub-redes, mas será possível configurá-las se você precisar delas. A Figura 3 mostra uma rede virtual do OpenStack composta por um único roteador virtual e três chaves virtuais. Duas das chaves virtuais são conectadas à rede externa por meio do roteador virtual. AZ-1 e AZ-2 são zonas de disponibilidade.

rede virtual

Figura 3: exemplo de configuração de rede do OpenStack

O GCP oferece dois tipos de rede: legada e sub-rede.

A rede legada oferece uma única sub-rede particular que abrange todas as regiões ao redor do globo, conforme mostrado na Figura 4.

Em uma rede de sub-rede, mostrada na Figura 5, a chave virtual corresponde a um roteador virtual do OpenStack Neutron, e as chaves virtuais são conectadas pela rede interna. Todas as sub-redes podem ser roteadas entre si por meio de endereços IP particulares, portanto você não precisa usar endereços IP globais nem a Internet para comunicação inter-regional.

No GCP, você pode usar uma combinação de redes legadas e de sub-rede em um projeto. Cada projeto recém-criado inclui uma rede predefinida chamada padrão, que, por sua vez, contém uma sub-rede denominada padrão em cada região.

rede legada

Figura 4: exemplo de configuração de rede legada do Google Cloud Platform

rede de sub-rede

Figura 5: exemplo de configuração de rede de sub-rede do Google Cloud Platform

Endereços IP

Veja a seguir o mapeamento dos termos e conceitos do OpenStack com os do GCP:

OpenStack GCP
As instâncias têm endereços IP internos particulares. É possível atribuir um endereço IP global (endereço IP flutuante), se necessário.

As instâncias têm endereços IP internos particulares. Além disso, quando uma instância é criada com a ferramenta de linha de comando "gcloud", um endereço IP temporário é automaticamente atribuído. É possível também atribuir endereços IP estáticos, se necessário.
Os endereços IP globais são necessários para comunicação entre instâncias em diferentes regiões ou roteadores virtuais distintos. As sub-redes em todas as regiões podem ser roteadas entre si por meio de endereços IP particulares, portanto você não precisa usar endereços IP globais nem a Internet para comunicação entre instâncias.

No Neutron, as instâncias de VM em uma rede particular comunicam-se por meio de chaves e roteadores virtuais que usam endereços IP particulares atribuídos na inicialização. Os endereços IP globais não são atribuídos por padrão.

O roteador virtual processa o acesso das instâncias de VM para a rede externa para que essas instâncias compartilhem o endereço IP global comum atribuído ao roteador virtual. Para expor uma instância à rede externa e permitir conexões de usuários externos, atribua um endereço IP flutuante à instância de um pool de endereços IP globais.

Como a rede virtual está contida em uma única região, as instâncias em regiões diferentes precisam usar os endereços IP flutuantes para comunicar-se pela rede externa.

Uma única rede pode incluir vários roteadores. As instâncias de VM conectadas a roteadores diferentes não podem comunicar-se diretamente com endereços IP particulares. No entanto, elas comunicam-se por meio da rede externa usando endereços IP flutuantes.

No GCP, todas as instâncias de VM têm um endereço IP interno e um externo na inicialização. Você pode desanexar um endereço IP externo, se necessário.

Por padrão, o endereço IP externo é temporário, o que significa que está vinculado à vida útil da instância. Quando você encerra uma instância e, em seguida, inicia-a novamente, talvez ela receba um endereço IP externo diferente. Você também pode solicitar um endereço IP permanente, denominado IP estático, para anexar à instância. O endereço IP estático será seu até você decidir liberá-lo, e você o atribui explicitamente às instâncias de VM. É possível anexar e desanexar endereços IP estáticos das instâncias, conforme necessário.

Conforme ilustrado nas arquiteturas de aplicativos da Web de três camadas de amostra no OpenStack, em caso de failover, como não é possível usar o mesmo endereço IP global em diferentes regiões, você precisa usar um mecanismo adicional, como DNS dinâmico, para permitir que os clientes continuem acessando o serviço com o mesmo URL.

Por outro lado, no GCP, é possível usar um único endereço IP global (VIP) fornecido pelo Cloud Load Balancing para distribuir acesso de cliente a várias regiões e zonas. Desse modo, é possível fazer failover entre regiões e zonas, que é transparente aos clientes.

Firewalls

Veja a seguir o mapeamento dos termos e conceitos do OpenStack com os do GCP:

OpenStack GCP Observações
Aplica as regras de firewall por meio de grupos de segurança. Aplica as regras de firewall por meio de regras e tags. Um grupo de segurança do OpenStack contém várias ACLs, que você define por papel da instância e, em seguida, atribui a uma instância.

Os grupos de segurança do OpenStack precisam ser definidos para cada região.

É possível definir as regras e tags do GCP uma vez e usá-las em todas as regiões.

No OpenStack, um único grupo de segurança contém várias listas de controle de acesso (ACLs, na sigla em inglês), que são independentes das instâncias de VM. Atribua um grupo de segurança a uma instância de VM para aplicar as ACLs a ela. Normalmente, você define os grupos de segurança de acordo com os papéis das instâncias de VM, como servidor da Web ou servidor de banco de dados.

Por exemplo, no caso da arquitetura de amostra, você define os seguintes grupos de segurança para cada região:

Grupo de segurança Origem Protocolo
load-balancer qualquer HTTP/HTTPS
Sub-rede de gerenciamento SSH
web-server load-balancer HTTPS
Sub-rede de gerenciamento SSH
web-application web-server TCP 8080
Sub-rede de gerenciamento SSH
database web-application MYSQL
Sub-rede de gerenciamento SSH

Você pode especificar a origem do pacote com um intervalo de sub-rede ou o nome de um grupo de segurança. Na tabela anterior, Sub-rede de gerenciamento é o intervalo de sub-rede em que os administradores do sistema fazem login no SO convidado para fins de manutenção.

Essa arquitetura pressupõe que o SSL do cliente termina no balanceador de carga, que se comunica com os servidores da Web usando HTTPS. Esses servidores comunicam-se com os servidores de aplicativos por TCP 8080. MySQL é usado no servidor de banco de dados.

Após definir os grupos de segurança, atribua-os a cada instância da seguinte maneira:

Instância Grupo de segurança
Balanceador de carga load-balancer
Servidor da Web web-server
Servidor de aplicativos web-application
Servidor de banco de dados database

No GCP, ao usar o Cloud Virtual Network, você pode definir regras de firewall que abrangem todas as regiões usando uma combinação de regras e tags. Tag é um rótulo arbitrário associado a uma instância de VM, e você pode atribuir várias tags a uma única instância de VM. Regra é uma ACL que permite ao pacote fluir com as seguintes condições:

  • origem: intervalo de IPs, sub-rede, tags
  • destino: tags

Por exemplo, defina primeiro uma regra para permitir o envio de pacotes que têm uma porta de destino TCP 80 de quaisquer endereços IP para a tag web-server. Em seguida, adicione a tag web-server a quaisquer instâncias de VM para permitir conexões HTTP com elas. Você gerencia tags para especificar os papéis das instâncias, e regras para especificar as ACLs que correspondem aos papéis separadamente.

A Figura 6 ilustra algumas regras predefinidas da rede padrão em um projeto recém-criado. Por exemplo, 10.128.0.0/9 é um intervalo de sub-rede que contém sub-redes subjacentes em todas as regiões. Esse intervalo pode ser diferente em cada projeto. Do começo ao fim, as regras permitem as seguintes conexões de rede:

  • pacotes de protocolo ICMP (Internet Control Message Protocol) de qualquer origem externa
  • qualquer pacote entre todas as instâncias conectadas à rede padrão
  • conexão RDP (Remote Desktop Protocol) de qualquer origem externa
  • conexão SSH (Secure Shell) de qualquer origem externa

Regras de firewall predefinidas

Figura 6: regras de firewall predefinidas no Virtual Cloud Network para a rede padrão

Para mais informações, consulte Usar redes e firewalls.

Nas regras de firewall do GCP, use tags para especificar destinos de pacotes e os intervalos de sub-rede ou as tags para especificar origens de pacotes. Neste cenário, defina as seguintes regras:

Origem Destino Protocolo
130.211.0.0/22 web-server HTTP, HTTPS
web-server web-application TCP 8080
Sub-rede de gerenciamento web-server, web-application SSH

Na tabela anterior, 130.211.0.0/22 é um intervalo de sub-rede do qual o balanceador de carga e o sistema de verificação de integridade acessam o servidor da Web. Sub-rede de gerenciamento é o intervalo de sub-rede do qual os administradores dos sistemas fazem login no SO convidado para fins de manutenção. web-server e web-application são as tags atribuídas ao servidor da Web e de aplicativos, respectivamente. Em vez de atribuir regras, como no caso dos grupos de segurança, atribua tags às instâncias de acordo com os papéis delas.

O controle de acesso para a conexão do banco de dados é configurado com base no endereço IP de origem, como parte da configuração do Cloud SQL.

Armazenamento

Veja a seguir o mapeamento dos termos e conceitos do OpenStack com os do GCP:

OpenStack GCP Observações
Volumes do Cinder Discos permanentes Armazenamento permanente anexado à instância

Com os discos permanentes do GCP, os dados são automaticamente criptografados antes de serem transferidos da instância para o armazenamento em disco permanente.

Discos temporários N/D Armazenamento temporário anexado à instância
Swift do OpenStack Google Cloud Storage Serviços de armazenamento de objetos
Discos temporários e volumes do Cinder

O OpenStack oferece duas opções de discos anexados à instância: discos temporários e volumes do Cinder.

Os discos temporários foram desenvolvidos para uso como discos do sistema que contêm arquivos do sistema operacional, e os volumes do Cinder foram criados para armazenar dados de aplicativos permanentes. Como a migração ao vivo não está disponível com discos temporários, as pessoas geralmente usam os volumes do Cinder também como discos do sistema.

Quando um disco temporário é usado como disco do sistema, uma imagem de modelo do SO é copiada para o armazenamento local de um node de computação, e a imagem local é anexada à instância. Quando a instância é destruída, a imagem anexada também é.

Os volumes do Cinder dispõem de uma área de disco permanente que reside em dispositivos de armazenamento externo. Em implantações comuns, o dispositivo de blocos é anexado ao node de computação usando o protocolo iSCSI e anexado à instância como um disco virtual. Quando a instância é destruída, o volume anexado permanece no dispositivo externo e pode ser reutilizado de uma outra instância.

O software do aplicativo em execução na instância também pode acessar o armazenamento de objetos fornecido pelo Swift do OpenStack.

disco temporário e volume do Cinder

Figura 7: comparação de um disco temporário e um volume do Cinder no OpenStack

Discos permanentes

O GCP oferece armazenamento permanente anexado à instância na forma de discos permanentes, que são parecidos com os volumes do Cinder no OpenStack. Use um disco permanente como um disco do sistema que contém os arquivos do sistema operacional e para armazenar os dados de aplicativos permanentes. Os dados são automaticamente criptografados antes de serem transferidos da instância para o armazenamento em disco permanente. É possível estender um único disco permanente para até 64 TB, mas a capacidade total máxima dos discos anexados está restrita ao tamanho da instância. Para mais informações, consulte Opções de armazenamento.

Quando precisar de armazenamento local de alto desempenho, você também poderá usar os discos permanentes locais de estado sólido (SSDs, na sigla em inglês). Cada SSD tem 375 GB, mas é possível anexar até oito dispositivos SSD locais por instância para 3 TB de espaço total de armazenamento em SSD local. A migração ao vivo está disponível para instâncias com SSDs locais anexados. Como os dados nos SSDs locais são copiados entre as instâncias durante a migração ao vivo, o desempenho do armazenamento pode ser temporariamente afetado.

O software do aplicativo em execução na instância pode acessar o armazenamento de objetos fornecido pelo Cloud Storage, um serviço hospedado para armazenar e acessar um grande número de objetos binários, ou blobs, de tamanhos variados.

Instâncias de VM

Veja a seguir o mapeamento dos termos e conceitos do OpenStack com os do GCP:

OpenStack GCP Nota
Tipo de instância Tipo de máquina No OpenStack, usuários gerais não podem criar tipos de instância personalizados.

No GCP, qualquer usuário pode criar tipos de máquina personalizados.
Serviço de metadados Servidor de metadados O OpenStack somente fornece informações sobre instâncias.

O GCP também fornece informações sobre projetos.

Ao iniciar uma nova instância de VM no OpenStack, escolha um tipo de instância para especificar o tamanho dela, como o número de vCPUs e a quantidade de memória. Se você tem o direito de acesso adequado atribuído pelo administrador do sistema, pode definir tipos de instância adicionais. Usuários gerais não têm permissão para adicionar tipos de instância personalizados.

No GCP, os tamanhos das instâncias são definidos como tipos de máquina. Além de escolher um dos tipos de máquina predefinidos, o usuário pode alterar o número de vCPUs e a quantidade de memória separadamente para criar um tipo de máquina personalizado. Para mais informações, consulte Tipos de máquinas.

Metadados

O OpenStack oferece um serviço de metadados para recuperar informações da instância de VM do sistema operacional convidado (SO convidado) dela, como tipo, grupos de segurança e endereços IP atribuídos. É possível também adicionar metadados personalizados no formato chave-valor. O OpenStack fornece um tipo de metadados denominado dados do usuário. Você pode especificar um arquivo de texto executável como user-data ao iniciar uma nova instância, para que o agente cloud-init que está sendo executado no SO convidado faça as tarefas de ajuste de inicialização de acordo com seu conteúdo, por exemplo, ao instalar pacotes de aplicativos. Use o URL em http://169.254.169.254/latest/meta-data para acessar os metadados do SO convidado.

O GCP dispõe do servidor de metadados para recuperar informações sobre instâncias e projetos do SO convidado da instância. Os metadados do projeto são compartilhados por todas as instâncias dele. É possível adicionar metadados personalizados tanto de instância quanto de projeto no formato chave-valor. O GCP fornece metadados especiais denominados startup-script e shutdown-script, executados quando você inicializa ou encerra a instância, respectivamente.

Diferentemente do user-data do OpenStack, o startup-script é executado toda vez que você reinicia a instância. Os dois scripts startup-script e shutdown-script são processados pelo agente incluído em compute-image-packages, que é pré-instalado nas imagens de modelo do SO. Para mais informações, consulte Armazenar e recuperar metadados de instância.

Use um dos seguintes URLs para acessar os metadados do SO convidado:

  • http://metadata.google.internal/computeMetadata/v1/
  • http://metadata/computeMetadata/v1/
  • http://169.254.169.254/computeMetadata/v1/
Agente do sistema operacional convidado
OpenStack GCP Observações
Pacote do agente de tarefas de configuração cloud-init Pacote do agente de tarefas de configuração compute-image-packages O agente do OpenStack processa somente as primeiras configurações de inicialização.

O agente do GCP processa as primeiras configurações de inicialização, e a configuração dinâmica é alterada durante a execução da instância.

No OpenStack, o pacote do agente denominado cloud-init é pré-instalado nas imagens do SO convidado padrão. Ele processa as tarefas iniciais de configuração no primeiro tempo de inicialização, como estender o espaço do sistema de arquivos raiz, armazenar uma chave pública SSH e executar o script fornecido como dados do usuário.

No GCP, o pacote do agente denominado compute-image-packages é pré-instalado nas imagens do SO convidado padrão. Ele processa as tarefas iniciais de configuração por meio do startup-script no primeiro tempo de inicialização e também realiza a configuração dinâmica do sistema durante a execução do SO convidado, como adicionar novas chaves públicas SSH e alterar configurações de rede para balanceamento de carga HTTP. Depois de iniciar uma instância, gere e adicione uma nova chave SSH pelo Console do Google Cloud Platform ou pela ferramenta de linha de comando gcloud.

O Google Cloud SDK é pré-instalado nas imagens do SO convidado padrão no GCP. Você pode usar o SDK para acessar serviços no GCP do SO convidado usando uma conta de serviço que, por padrão, tenha alguns privilégios.

Controle de acesso

O Google Cloud IAM aplica o controle de acesso por instância no GCP. Por exemplo, para que o aplicativo em execução na instância armazene os dados no Google Cloud Storage, atribua a permissão de leitura e gravação a ela. Com o Cloud IAM, não é necessário preparar senhas ou códigos de credenciais manualmente para os aplicativos em execução na instância. Para mais informações, consulte Criar e ativar contas de serviço para instâncias.

O Keystone do OpenStack proporciona controle de acesso para APIs de serviço com base na conta de usuário, mas não oferece controle de acesso baseado na instância para APIs de aplicativo, como permissão de leitura e gravação no armazenamento de objetos ou banco de dados. É possível implementar controle de acesso personalizado para APIs de aplicativo, se necessário.

Além do IaaS: plataforma como um serviço

Este artigo compara os componentes e os serviços oferecidos pelo OpenStack e pelo Google Cloud Platform que são essenciais à IaaS. Porém, para aproveitar o máximo que o GCP tem a oferecer em termos de disponibilidade, escalonabilidade e eficiência operacional, convém combinar os serviços gerenciados, como a construção de blocos para o sistema inteiro.

A gama completa de serviços do GCP vai além do conceito tradicional da plataforma IaaS, incluindo, dentre outros, os seguintes itens:

Próximas etapas

  • Saiba mais sobre a integração do Google Cloud Dataproc com os serviços de armazenamento, computação e monitoramento no GCP para criar uma plataforma completa de processamento de dados.
  • Saiba sobre monitoramento, registro e diagnóstico usando o Google Stackdriver.
  • Saiba mais sobre o Google BigQuery, um serviço de armazenamento de dados totalmente gerenciado para análise que inclui uma plataforma sem servidor, para você se dedicar à análise de dados usando SQL até em conjuntos de dados em escala de petabytes.
  • Saiba mais sobre produtos e serviços do Google Cloud Platform.
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Google Cloud Platform para usuários do OpenStack