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
Neste artigo, primeiro comparamos arquiteturas de aplicativos da Web de três camadas de amostra no OpenStack e no GCP e, na sequência, comparamos os recursos de cada um, apresentando tabelas de referência rápida que explicam como os termos e conceitos do OpenStack se comparam com os 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)
Entre os serviços básicos do Cloud Platform estão:
- computação: Google Compute Engine e Google App Engine
- armazenamento: discos permanentes e Google Cloud Storage
- rede: Google Cloud Virtual Network, Google Cloud DNS e Google Cloud Interconnect
- bancos de dados: Google Cloud SQL, Google Cloud Datastore e Google Cloud Bigtable
- gerenciamento de identidade e acesso: Google Cloud IAM
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áquina personalizados, o modelo de preços do GCP ajuda a otimizar o desempenho eficaz e econômico dos aplicativos.
Para detalhes e ferramentas de estimativa rápida de preço, consulte a calculadora de preços do Google Cloud Platform.
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, Maps, YouTube e Pesquisa. 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.
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 a 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.
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 | Notas |
|---|---|---|
| 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 (em vez das zonas de disponibilidade) são consideradas domínios de falha independentes, porque as zonas de disponibilidade em uma única região compartilham os mesmos nós 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 | Notas |
|---|---|---|
| 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 | Notas |
|---|---|---|
| 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 privada virtual |
Rede privada virtual | Uma única rede privada virtual do GCP abrange todas as regiões conectadas por meio da rede interna dele. A rede privada virtual do Neutron abrange 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 privada. 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.
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 privados, portanto, não é preciso 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 denominada padrão, que, por sua vez, contém uma sub-rede denominada padrão em cada região.
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 privados. 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, a 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.
Nessa arquitetura, supõe-se que o SSL cliente é encerrado no balanceador de carga, que se comunica com os servidores da Web usando HTTPS. Os servidores da Web se comunicam com 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
Para mais informações, consulte Como 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. A sub-rede de gerenciamento representa um intervalo de sub-rede no qual os administradores de sistemas fazem login no SO convidado para fins de manutenção. web-server e web-application são tags atribuídas ao servidor da Web e ao servidor 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 respectivos papéis.
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 | Notas |
|---|---|---|
| Volumes do Cinder | Discos permanentes | Armazenamento permanente conectado à 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 aplicativo em execução na instância também pode acessar o armazenamento de objetos fornecido pelo Swift do 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 em tempo real, o desempenho do armazenamento pode ficar temporariamente reduzido.
O software 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 (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áquina.
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. É possível especificar um arquivo de texto executável como user-data ao iniciar uma nova instância para que o agente cloud-init em execução no SO convidado execute tarefas de configuração de inicialização de acordo com o próprio conteúdo, como a instalação de pacotes de aplicativos. Você usa o URL em http://169.254.169.254/latest/meta-data para acessar os metadados do SO convidado.
O GCP fornece um 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 do projeto. É 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ê inicia ou encerra a instância, respectivamente.
Ao contrário douser-data do OpenStack, startup-script é executado sempre que você reinicia a instância. Os dois scripts startup-script e shutdown-script são manipulados pelo agente incluído no compute-image-packages (em inglês), que é pré-instalado nas imagens de modelo do SO. Para mais informações, consulte Como 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 | Notas |
|---|---|---|
cloud-init pacote de agente de tarefas de configuração |
compute-image-packages pacote de agente de tarefas de configuração |
O agente do OpenStack só manipula somente as primeiras configurações de inicialização. O agente do GCP manipula 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 de agente denominado cloud-init está pré-instalado nas imagens padrão do SO convidado. 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 de agente denominado compute-image-packages está pré-instalado nas imagens padrão do SO convidado. Ele manipula as primeiras tarefas de configuração por meio de startup-script no primeiro tempo de inicialização e também manipula 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. É possível gerar e adicionar uma nova chave SSH por meio do Console do Google Cloud Platform ou a ferramenta de linha de comando gcloud depois de iniciar uma instância.
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 controle de acesso no GCP é aplicado pelo Google Cloud IAM por instância. Por exemplo, se quiser que seu aplicativo em execução em uma instância armazene dados no Google Cloud Storage, atribua a permissão de leitura e gravação à instância. 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 Como 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: Platform as a Service
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:
- Big Data
- Machine learning
- Ferramentas de gestão
- Ferramentas para desenvolvedores
- Serviços de identidade e segurança
A seguir
- 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 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.