Este artigo foi elaborado para apresentar aos usuários familiarizados com o OpenStack os principais conceitos de introdução ao Google Cloud, 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 Google Cloud e, em seguida, comparamos os recursos de OpenStack e Google Cloud e fornecemos tabelas de referência rápida que explicam como os termos e conceitos do OpenStack correspondem aos do Google Cloud.
Neste artigo, não comparamos SDKs, APIs ou ferramentas de linha de comando fornecidos pelo OpenStack e pelo Google Cloud.
Para uma lista completa de produtos do Google Cloud, consulte Produtos e serviços.
Serviços de computação em nuvem
Eles oferecem um conjunto de serviços básicos, incluindo computação, armazenamento, rede, gerenciamento de acesso e, muitas vezes, serviços de banco de dados.
Os serviços básicos do OpenStack incluem:
- computação: OpenStack Compute (Nova e Glance)
- armazenamento: OpenStack Block Storage (Cinder)
- rede: OpenStack Networking (Neutron)
- Bancos de dados: banco de dados como serviço de código aberto do OpenStack (Trove)
- gerenciamento de acesso e identidade: OpenStack Identity Service (Keystone)
Os serviços de valor de referência do Google Cloud incluem:
- computação: Compute Engine e App Engine
- armazenamento: discos permanentes e Cloud Storage
- rede: Google Cloud Virtual Network, Google Cloud DNS e Google Cloud Interconnect
- bancos de dados: Cloud SQL, Datastore e Cloud Bigtable
- gerenciamento de identidade e acesso: IAM
Preços no Google Cloud
A maioria dos serviços no Google Cloud é oferecida no modelo de preços de pagamento por utilização, que inclui faturamento por segundo ou 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 Google Cloud otimiza 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.
Por que usar o Google Cloud?
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 Google Cloud coloca essa infraestrutura à sua disposição.
Comparação de arquiteturas de amostra
Nesta seção, comparamos como criar um sistema de aplicativos da Web de três camadas no OpenStack e no Google Cloud.
- A configuração do OpenStack resulta no modo ativo-backup.
- A configuração do Google Cloud usa 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.
Google Cloud: configuração ativa-ativa
A configuração de amostra do Google Cloud 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 a 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 Google Cloud 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 Google Cloud 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 uma comparação entre os termos e conceitos do OpenStack e do Google Cloud:
| OpenStack | Google Cloud | Observações |
|---|---|---|
| Região | Região | No OpenStack, uma região pode englobar vários data centers. No Google Cloud, 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 Google Cloud, uma zona corresponde a um cluster no data center. |
No OpenStack, uma região é definida como um único cluster gerenciado por nós de controlador dedicados. Uma região consiste em zonas de disponibilidade. Use essas zonas para definir vários grupos de recursos, como nós de computação e compartimentos de armazenamento.
No Google Cloud, uma região é uma área geográfica independente formada por zonas. Os locais nas regiões costumam ter latências de rede de retorno inferior a 5 ms no 95º percentil. Assim como zonas de disponibilidade do OpenStack, uma zona é uma área de implantação de recursos do Google Cloud em uma região. A zona deve ser considerada um domínio de falha único.
O Google Cloud fornece 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 Google Cloud. Por outro lado, no OpenStack, as regiões (em vez das zonas de disponibilidade) são consideradas domínios de falha independentes, porque zonas de disponibilidade em uma única região compartilham os mesmos nós de controlador. Para uma lista de regiões e zonas do Google Cloud, consulte Locais do Cloud.
Projetos e locatários
Veja a seguir uma comparação entre os termos e conceitos do OpenStack e do Google Cloud:
| OpenStack | Google Cloud | Observações |
|---|---|---|
| Locatário | Projeto | Todos os recursos do Google Cloud 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 Google Cloud. O Google Cloud agrupa o uso do serviço por projeto. É possível 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 uma comparação entre os termos e conceitos do OpenStack e do Google Cloud:
| OpenStack | Google Cloud | Observações |
|---|---|---|
| Neutron | Cloud Virtual Network | O Cloud Virtual Network é um serviço de rede gerenciado. No Google Cloud,
é 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 é necessário 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 de 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 Google Cloud 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, não é preciso usar endereços IP globais nem a Internet para comunicação inter-regional.
No Google Cloud, é possível 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.
Endereços IP
Veja a seguir uma comparação entre os termos e conceitos do OpenStack e do Google Cloud:
| OpenStack | Google Cloud |
|---|---|
| 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 se comunicar diretamente com endereços IP particulares. No entanto, elas comunicam-se por meio da rede externa usando endereços IP flutuantes.
No Google Cloud, todas as instâncias de VM têm um endereço IP interno e um externo no momento da inicialização. É possível 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 extra, como DNS dinâmico, para permitir que os clientes continuem acessando o serviço com o mesmo URL.
No Google Cloud, por outro lado, é 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 uma comparação entre os termos e conceitos do OpenStack e do Google Cloud:
| OpenStack | Google Cloud | 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 Google Cloud 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 Google Cloud, é possível usar o Cloud Virtual Network para definir regras de firewall que abrangem todas as regiões que usam uma combinação de regras e tags. Tag é um rótulo arbitrário associado a uma instância de VM. É possível 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 Google Cloud, 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 uma comparação entre os termos e conceitos do OpenStack e do Google Cloud:
| OpenStack | Google Cloud | Observações |
|---|---|---|
| Volumes do Cinder | Discos permanentes | Armazenamento permanente conectado à instância Com os discos permanentes do Google Cloud, 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 Google Cloud 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 uma comparação entre os termos e conceitos do OpenStack e do Google Cloud:
| OpenStack | Google Cloud | Observação |
|---|---|---|
| Tipo de instância | Tipo de máquina | No OpenStack, usuários gerais não podem
criar tipos de instância personalizados. No Google Cloud, 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 Google Cloud 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 Google Cloud, 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 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 Google Cloud 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 | Google Cloud | Observações |
|---|---|---|
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 manipula somente
as primeiras configurações de inicialização. O agente do Google Cloud 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 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 Google Cloud, 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
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 pelo Console do Google Cloud
ou a ferramenta de linha de comando gcloud depois de iniciar uma instância.
O SDK do Cloud está pré-instalado nas imagens padrão do SO convidado no Google Cloud. O SDK pode ser usado para acessar serviços no Google Cloud do SO convidado usando uma conta de serviço que tem alguns privilégios por padrão.
Controle de acesso
O controle de acesso no Google Cloud é aplicado por instância pelo IAM. 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 IAM, você não precisa preparar senhas ou códigos de credenciais manualmente para 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 que são essenciais à IaaS. Porém, para aproveitar o máximo que o Google Cloud 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 Google Cloud 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 Dataproc com serviços de armazenamento, computação e monitoramento no Google Cloud para criar uma plataforma completa de processamento de dados.
- Saiba sobre monitoramento, registro e diagnóstico usando o Google Stackdriver.
- Saiba mais sobre o 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.