Opções de armazenamento

O Compute Engine oferece várias opções de armazenamento para suas instâncias de VM. Cada uma delas tem características únicas de preço e desempenho:

Os volumes de disco permanente fornecem armazenamento em rede redundante e de alto desempenho. Cada volume de disco permanente é removido por centenas de discos físicos.
- Por padrão, as VMs usam discos permanentes zonais e armazenam dados em volumes localizados em uma única zona, como us-west1-c.
- Também é possível criar discos permanentes regionais, que replicam dados de maneira síncrona entre discos localizados em duas zonas e fornecem proteção se uma zona ficar indisponível.
Os volumes de Hyperdisk oferecem armazenamento em rede redundante mais rápido para o Compute Engine, com desempenho e volumes configuráveis que podem ser redimensionados dinamicamente.
Os SSDs locais são unidades físicas anexadas diretamente ao mesmo servidor da VM. Eles podem oferecer um desempenho melhor, mas são temporários.
Também é possível usar os buckets do Cloud Storage e o Filestore com suas VMs.

Cada opção de armazenamento tem características únicas de preço e desempenho. Para ver uma comparação de preços, consulte Preços de discos. Se você não tem certeza de qual opção usar, a solução mais comum é adicionar um disco permanente à instância.

Introdução

Por padrão, cada instância do Compute Engine tem um único disco de inicialização que contém o sistema operacional. Normalmente, os dados do disco de inicialização são armazenados em um volume de disco permanente (PD, na sigla em inglês). Quando os aplicativos precisarem de mais espaço de armazenamento, será possível provisionar um ou mais dos seguintes volumes de armazenamento para a instância.

Para saber mais sobre cada opção de armazenamento, consulte a tabela a seguir:

	DP padrão por zona	DP padrão regional	DP balanceado por zona	DP balanceado regional	DP SSD por zona	DP SSD regional	DP extremo por zona	Hiperdisco extremo	SSDs locais	Buckets do Cloud Storage
Tipo de armazenamento	Armazenamento em blocos eficiente e confiável	Armazenamento em blocos eficiente e confiável com replicação síncrona em duas zonas de uma região	Armazenamento em blocos econômico e confiável	Armazenamento em blocos econômico e confiável com replicação síncrona em duas zonas de uma região	Armazenamento em blocos rápido e confiável	Armazenamento em blocos rápido e confiável com replicação síncrona em duas zonas de uma região	Opção de armazenamento em blocos de disco permanente com melhor performance com IOPS personalizáveis	Opção de armazenamento em blocos mais rápida com IOPS personalizáveis	Armazenamento em blocos local de alto desempenho	Armazenamento econômico de objetos
Capacidade mínima por disco	10 GiB	200 GiB	10 GiB	10 GiB	10 GiB	10 GiB	500 GiB	64 GiB	375 GiB	n/a
Capacidade máxima por disco	64 TiB	64 TiB	64 TiB	64 TiB	64 TiB	64 TiB	64 TiB	64 TiB	375 GiB	n/a
Aumento de capacidade	1 GiB	1 GiB	1 GiB	1 GiB	1 GiB	1 GiB	1 GiB	1 GiB	Depende do tipo de máquina^†	n/a
Capacidade máxima por instância	257 TiB^*	257 TiB^*	257 TiB^*	257 TiB^*	257 TiB^*	257 TiB^*	257 TiB^*	257 TiB^*	9 TiB	Quase infinito
Escopo de acesso	Zona	Zona	Zona	Zona	Zona	Zona	Zona	Zona	Instância	Global
Redundância de dados	Zonal	Multizona	Zonal	Multizona	Zonal	Multizona	Zonal	Zonal	Nenhum	Regional, birregional ou multirregional
Criptografia em repouso	Sim	Sim	Sim	Sim	Sim	Sim	Sim	Sim	Sim	Sim
Chaves de criptografia personalizadas	Sim	Sim	Sim	Sim	Sim	Sim	Sim	Sim	Não	Sim
Instruções	Adicionar um disco permanente padrão	Adicionar um disco permanente padrão regional	Adicionar um disco permanente balanceado	Adicionar um disco permanente regional balanceado	Adicionar um disco permanente SSD	Adicionar um disco permanente SSD regional	Adicionar um disco permanente extremo	Adicionar um Hyperdisk	Adicionar um SSD local	Conectar um bucket

^* Se você estiver pensando em criar um volume lógico maior que 64 TB, analise como o tamanho do volume lógico afeta performance.

^† O incremento de capacidade para SSDs locais depende do número de discos SSD (partições) permitidos por VM, que varia para cada tipo de máquina. Para mais informações, consulte Tipos de máquina e SSDs locais.

Além das opções de armazenamento listadas na tabela anterior, o Google Cloud oferece os seguintes serviços de armazenamento para suas instâncias:

Serviços de arquivos: é possível criar um servidor de arquivos ou sistema de arquivos distribuído no Compute Engine para usar como um sistema de arquivos de rede com recursos NFSv3 e SMB3.
Disco RAM: é possível montar um disco RAM na memória da instância de VM para criar um volume de armazenamento em blocos com baixa latência e alta capacidade de processamento.

Os recursos de armazenamento em blocos têm características de desempenho diferentes. Considere os requisitos de tamanho e desempenho do armazenamento ao determinar o tipo correto de armazenamento em blocos para as instâncias de VM.

Para informações sobre limites de desempenho para cada tipo de disco, consulte:

Os discos permanentes criados no modo de vários gravadores têm limites específicos de capacidade e IOPS. Para mais detalhes, consulte Desempenho dos discos permanentes no modo de vários gravadores.

Discos permanentes

Os discos permanentes são dispositivos de armazenamento de rede duráveis que podem ser acessados por suas instâncias, como discos físicos em um desktop ou em um servidor. Os dados em cada disco permanente são distribuídos em vários discos físicos. O Compute Engine gerencia os discos físicos e a distribuição de dados para garantir a redundância e otimizar o desempenho.

Os discos permanentes estão localizados independentemente das instâncias de máquina virtual (VM, na sigla em inglês), portanto, é possível retirá-los ou movê-los para manter os dados mesmo que as instâncias sejam excluídas. Como o desempenho do disco permanente é escalonado automaticamente conforme o tamanho, é possível possa redimensionar os discos permanentes atuais ou adicionar mais deles a uma instância visando atender aos requisitos de desempenho e espaço de armazenamento.

Tipos de disco permanente

Ao configurar um disco permanente, selecione um dos tipos de disco a seguir:

Discos permanentes padrão (pd-standard)
- Ideal para grandes cargas de trabalho de processamento de dados que usam principalmente E/Ss sequenciais.
- Com respaldo dos drives de disco rígido padrão (HDD)
Discos permanentes equilibrados (pd-balanced)
- Alternativa aos discos permanentes de desempenho (pd-ssd)
- Equilíbrio de desempenho e custo. Para a maioria dos formatos de VM, exceto os muito grandes, esses discos têm as mesmas IOPS máximas que os discos permanentes SSD e IOPS por GB mais baixos. Esse tipo de disco oferece níveis de desempenho adequados para a maioria dos aplicativos de uso geral a uma faixa de preços igual à dos discos permanentes padrão e de desempenho (pd-ssd).
- Com respaldo das unidades de estado sólido (SSD).
Discos permanentes de desempenho (SSD) (pd-ssd)
- Ideal para aplicativos empresariais e bancos de dados de alto desempenho que exigem menos latência e mais IOPS do que os discos permanentes padrão.
- Projetado para latências de milissegundo com um dígito. A latência observada é específica do aplicativo.
- Com respaldo das unidades de estado sólido (SSD).
Discos permanentes extremos (pd-extreme)
- Oferece alto desempenho consistente para cargas de trabalho de acesso aleatório e capacidade de processamento em massa.
- Projetado para cargas de trabalho de banco de dados sofisticados, como Oracle ou SAP HANA.
- Permite provisionar os IOPS de destino.
- Com respaldo das unidades de estado sólido (SSD).
- Disponível com um número limitado de tipos de máquinas.

Se você criar um disco no console do Google Cloud, o tipo de disco padrão será pd-balanced. Se você criar um disco usando a CLI gcloud ou a API Compute Engine, o tipo de disco padrão será pd-standard.

Para informações sobre o suporte do tipo de máquina, consulte:

Durabilidade dos discos permanentes

A durabilidade do disco representa a probabilidade de perda de dados, por design, para um disco típico em um ano típico, usando um conjunto de suposições sobre falhas de hardware, a probabilidade de eventos catastróficos, práticas de isolamento e processos de engenharia nos data centers do Google e nas codificações internas usadas por cada tipo de disco. Os eventos de perda de dados no disco permanente são extremamente raros e têm sido historicamente o resultado de falhas de hardware coordenadas, bugs de software ou uma combinação dos dois. O Google também toma muitas medidas para reduzir o risco de corrupção de dados silenciosa em todo o setor. Um erro humano de um cliente do Google Cloud, como quando um cliente exclui acidentalmente um disco, está fora do escopo de durabilidade do disco permanente.

Há um risco muito pequeno de perda de dados que ocorre com um disco permanente regional devido às codificações e à replicação de dados internos. Os discos permanentes regionais fornecem o dobro de réplicas dos discos permanentes zonais. Com as réplicas distribuídas entre duas zonas na mesma região, eles fornecem alta disponibilidade e Pode ser usada para recuperação de desastres se um data center inteiro for perdido e não puder ser recuperado (embora isso nunca tenha ocorrido). As réplicas adicionais em uma segunda zona podem ser acessadas imediatamente se uma zona principal ficar indisponível durante uma interrupção longa.

Observe que a durabilidade é agregada para cada tipo de disco e não representa um contrato de nível de serviço (SLA, na sigla em inglês) com suporte financeiro.

A tabela abaixo mostra a durabilidade para o design de cada tipo de disco. 99,999% de durabilidade significa que, com 1.000 discos, você provavelmente ficaria cem anos sem perder um único.

Disco permanente padrão zonal	Disco permanente equilibrado de zona	Disco permanente SSD por zona	Disco permanente extremo por zona	Disco permanente padrão regional	Disco permanente equilibrado regional	Disco permanente SSD regional
Melhor que 99,99%	Melhor que 99,999%	Melhor que 99,999%	Melhor que 99,9999%	Melhor que 99,999%	Melhor que 99,9999%	Melhor que 99,9999%

Discos permanentes por zona

Fácil de usar

O Compute Engine faz a maioria das tarefas de gerenciamento de disco para que você não precise lidar com particionamento, matrizes de disco redundantes ou gerenciamento de subvolumes. Geralmente, não é necessário criar volumes lógicos maiores, mas é possível estender a capacidade do disco permanente anexado e secundário para 257 TB por instância e aplicar essas práticas aos seus discos permanentes. Você economiza tempo e aprimora o desempenho quando formata os discos permanentes com um único sistema de arquivos e sem tabelas de partição.

Se for necessário separar os dados em vários volumes exclusivos, crie mais discos em vez de dividir os discos atuais em várias partições.

Quando precisar de mais espaço nos discos permanentes, redimensione os discos em vez de particionar novamente e formatar.

Desempenho

O desempenho do disco permanente é previsível e dimensionado linearmente de acordo com a capacidade provisionada até que os limites das vCPUs provisionadas de uma instância sejam atingidos. Para mais informações sobre otimização e limites de dimensionamento de desempenho, consulte Configurar discos para atender aos requisitos de desempenho.

Os discos permanentes padrão são eficientes e econômicos para lidar com operações sequenciais de leitura/gravação. No entanto, eles não são otimizados para processar altas taxas de operações aleatórias de entrada/saída por segundo (IOPS, na sigla em inglês). Se os aplicativos exigirem altas taxas de IOPS aleatórias, use discos permanentes SSD ou extremos. Discos permanentes SSD são projetados para latências de milissegundo com um dígito. A latência alcançada é específica para cada aplicativo.

O Compute Engine otimiza o desempenho e o escalonamento em discos permanentes automaticamente. Você não precisa gravar vários discos juntos ou pré-aquecê-los para atingir o melhor desempenho. Quando você precisar de mais espaço em disco ou de um melhor desempenho, bastará redimensionar os discos e, possivelmente, adicionar mais vCPUs para aumentar o espaço de armazenamento, a capacidade e a taxa de IOPS. O desempenho do disco permanente é baseado na capacidade total do disco permanente anexado a uma instância e no número de vCPUs nela.

No caso dos dispositivos de inicialização, é possível usar um disco permanente padrão para reduzir os custos. Discos permanentes pequenos de 10 GB funcionam nos casos de uso de gerenciamento básico de inicialização e de pacotes. No entanto, para garantir um desempenho consistente para uso mais geral do dispositivo de inicialização, use um disco permanente balanceado como disco de inicialização.

Cada operação de gravação de disco permanente contribui para o tráfego de saída de rede cumulativo para a instância. Isso significa que as operações de gravação de disco permanentes são limitadas pelo limite de saída da rede para a instância.

Confiabilidade

Os discos permanentes têm redundância incorporada para proteger os dados contra falhas de equipamentos e garantir a disponibilidade dos dados por meio de eventos de manutenção de datacenter. As somas de verificação são calculadas para todas as operações de discos permanentes para garantir que você leia exatamente aquilo que foi gravado.

Além disso, crie snapshots de discos permanentes para se proteger contra perda de dados devido a erros do usuário. Os snapshots são incrementais e levam apenas alguns minutos para serem criados, mesmo se os discos deles estiverem anexados a instâncias em execução.

Modo de vários gravadores

É possível anexar um disco permanente SSD no modo de vários gravadores a até duas VMs N2 simultaneamente, para que ambas as instâncias possam ler e gravar no disco. Os discos permanentes no modo de vários gravadores fornecem um recurso de armazenamento em blocos compartilhado e apresentam uma base de infraestrutura para a criação de um sistema distribuído de arquivos de rede (NFS, na sigla em inglês) e serviços altamente disponíveis semelhantes. No entanto, os discos permanentes com o modo de vários gravadores exigem sistemas de arquivos especializados, como o GlusterFS ou o GFS2. Muitos sistemas de arquivos, como EXT4, XFS e NTFS, não foram projetados para serem usados com o armazenamento em blocos compartilhados. Para mais informações sobre as práticas recomendadas ao compartilhar discos permanentes entre VMs, consulte Práticas recomendadas. Se você precisar de um armazenamento de arquivos totalmente gerenciado, monte um compartilhamento de arquivos do Filestore nas suas VMs do Compute Engine.

Para ativar o modo de vários gravadores em novos discos permanentes, crie um novo disco permanente e especifique a sinalização --multi-writer na CLI gcloud ou na propriedade multiWriter na API Compute Engine. Para mais informações, consulte Como compartilhar discos permanentes entre VMs.

Criptografia do disco permanente

O Compute Engine criptografa automaticamente os dados antes que eles saiam da instância para o espaço de armazenamento do disco permanente. Cada disco permanente continua criptografado com chaves definidas pelo sistema ou fornecidas pelo cliente. O Google distribui dados de discos permanentes em vários discos físicos de maneira não controlada pelos usuários.

Quando você exclui um disco permanente, o Google descarta as chaves de criptografia, tornando os dados irrecuperáveis. Esse processo é irreversível.

Se quiser controlar as chaves usadas para criptografar os dados, crie os discos com as próprias chaves de criptografia.

Restrições

Não é possível anexar um disco permanente a uma instância em outro projeto.
É possível anexar um disco permanente equilibrado a, no máximo, 10 instâncias de VM no modo somente ler.
Nos tipos de máquina personalizados ou tipos de máquina predefinidos que tenham no mínimo uma vCPU, é possível anexar até 128 discos permanentes.
Cada disco permanente pode ter até 64 TB. Por isso, não é necessário gerenciar matrizes de discos para criar volumes lógicos grandes. É possível anexar apenas uma quantidade limitada de espaço total e um número restrito de discos permanentes individuais a cada instância. Os tipos de máquina predefinidos e os tipos de máquina personalizados têm os mesmos limites de discos permanentes.
A maioria das instâncias pode ter até 257 TB de espaço total e 128 discos permanentes anexados a cada uma delas. O espaço total em disco permanente de uma instância inclui o tamanho do disco permanente de inicialização.
Os tipos de máquina com núcleo compartilhado estão limitados a 16 discos permanentes e a 3 TB de espaço total neles.
A criação de volumes lógicos maiores do que 64 TB pode exigir considerações especiais. Para mais informações sobre um desempenho de volume lógico maior, consulte Tamanho do volume lógico.

Discos permanentes regionais

Os discos permanentes regionais têm atributos de armazenamento semelhantes aos discos permanentes por zona. No entanto, eles proporcionam replicação de dados e armazenamento durável entre duas zonas na mesma região.

Se você estiver projetando sistemas robustos ou serviços de alta disponibilidade no Compute Engine, use discos permanentes regionais com outras práticas recomendadas, como fazer backup dos dados com snapshots. Os discos permanentes regionais também são projetados para funcionar com grupos gerenciados de instâncias regionais.

No caso improvável de uma interrupção na zona, normalmente é possível fazer o failover da carga de trabalho em execução em discos permanentes regionais para outra zona usando a sinalização --force-attach. A sinalização --force-attach permite anexar o disco permanente regional a uma instância de VM em espera, mesmo que o disco não possa ser removido da VM original devido à indisponibilidade. Para saber mais, consulte Failover de disco permanente regional. Não é possível forçar a anexação de um disco permanente zonal a uma instância.

Desempenho

Os discos permanentes regionais foram projetados para cargas de trabalho que exigem um objetivo de ponto de recuperação (RPO, na sigla em inglês) e um objetivo de tempo de recuperação (RTO, na sigla em inglês) menores em comparação com o uso de snapshots de disco permanente (páginas em inglês).

Os discos permanentes regionais são uma opção quando o desempenho de gravação é menos crítico do que a redundância de dados em várias zonas.

Assim como os discos permanentes zonais, os discos permanentes regionais podem alcançar melhor desempenho de IOPS e capacidade de processamento em instâncias com um maior número de vCPUs. Para mais informações sobre essa e outras limitações, consulte Configurar discos para atender aos requisitos de desempenho.

Quando você precisa de mais espaço em disco ou de desempenho melhor, é possível redimensionar os discos regionais para adicionar mais espaço de armazenamento, capacidade de processamento e IOPS.

Confiabilidade

O Compute Engine replica dados de seu disco permanente regional para as zonas selecionadas quando você criou seus discos. Os dados de cada réplica são distribuídos por várias máquinas físicas dentro da zona para garantir a redundância.

Assim como os discos permanentes por zona, é possível criar snapshots de discos permanentes para se proteger contra perda de dados devido a um erro do usuário. Os snapshots são incrementais e levam apenas alguns minutos para serem criados, mesmo se os discos deles estiverem anexados a instâncias em execução.

Restrições

Só é possível anexar discos permanentes regionais a VMs que usam tipos de máquina E2, N1, N2 e N2D.
Não é possível usar discos permanentes regionais como discos de inicialização.
Ao usar o modo somente leitura, é possível anexar um disco permanente equilibrado regional a, no máximo, 10 instâncias de VM.
O tamanho mínimo de um disco permanente regional padrão é 200 GB.
Só é possível aumentar o tamanho do Persistent Disk regional; não é possível diminuir o tamanho dele.
Os volumes de disco permanente regional têm características de desempenho diferentes dos volumes zonais. Para mais informações, consulte Desempenho do armazenamento em blocos.
Se você criar um disco permanente regional clonando um disco zonal, as duas réplicas zonais não estarão totalmente sincronizadas no momento da criação. Após a criação, é possível usar o clone de disco regional em média em até três minutos. No entanto, talvez seja necessário aguardar dezenas de minutos até que o disco atinja um estado totalmente replicado e o objetivo do ponto de recuperação (RPO) esteja próximo de zero. Saiba como verificar se o Persistent Disk regional está totalmente replicado.

Hyperdisks

O Google Cloud Hyperdisk Extreme para Compute Engine oferece o armazenamento em blocos mais rápido. Ela é adequada para cargas de trabalho de última geração que precisam das mais alta capacidade de processamento e IOPS.

Os volumes extremos de Hyperdisk permitem que você ajuste de maneira independente a capacidade e as IOPS das cargas de trabalho. O tamanho e o desempenho do armazenamento são separados do tipo e do tamanho da instância, o que proporciona mais flexibilidade.

Os volumes extremos do Hyperdisk são criados e gerenciados como um disco permanente, com a capacidade adicional de definir o nível de IOPS provisionado e alterar esse valor a qualquer momento. Não há caminho de migração direto do disco permanente extremo para volumes extremos do Hyperdisk. Em vez disso, é possível criar um snapshot e restaurá-lo para um novo volume extremo do Hyperdisk.

Consulte Sobre os Hyperdisks para saber mais.

Criptografia do Hyperdisk

O Compute Engine criptografa automaticamente os dados ao gravar em um volume do Hyperdisk.

Persistência de dados no Hyperdisk

A durabilidade do disco representa a probabilidade de perda de dados, por padrão, para um disco típico em um ano típico. A durabilidade é calculada usando um conjunto de suposições sobre falhas de hardware, como:

A probabilidade de eventos catastróficos
Práticas de isolamento
Processos de engenharia nos data centers do Google
As codificações internas usadas por cada tipo de disco

O Hyperdisk Extreme oferece mais de 99,9999% de durabilidade.

SSDs locais

Os SSDs locais são anexados fisicamente ao servidor que hospeda a instância de VM. Eles têm mais capacidade e menos latência do que os discos permanentes padrão ou discos permanentes SSD. Os dados armazenados em um SSD local permanecem somente até você interromper ou excluir a instância. Cada SSD local tem 375 GB, mas é possível anexar várias partições desse tipo à instância, dependendo do número de vCPUs.

Crie uma instância com SSDs locais quando você precisar de um cache ou disco de trabalho rápido e não quiser usar a memória da instância.

Criar uma instância com SSDs locais

Desempenho

Os SSDs locais são projetados para oferecer taxas de IOPS muito altas e baixa latência. Ao contrário dos discos permanentes, nos SSDs locais é preciso gerenciar a gravação por conta própria. Combine várias partições SSD locais em um único volume lógico para conseguir o melhor desempenho de SSD local por instância ou formate partições SSD locais individualmente.

O desempenho do SSD local depende da interface selecionada. Os SSDs locais estão disponíveis nas interfaces SCSI e NVMe (páginas em inglês).

A tabela a seguir traz uma visão geral da capacidade do SSD local e do desempenho estimado usando o NVMe. Para atingir os limites máximos de desempenho com um tipo de máquina N1, use 32 ou mais vCPUs. Para atingir os limites máximos de desempenho em um tipo de máquina N2 e N2D, use 24 ou mais vCPUs.

Espaço de armazenamento	Partições
		Leitura	Gravação	Leitura	Gravação
3 TB	8	680.000	360.000	2.650	1.400
6 TB	16	1.600.000	800.000	6.240	3.120
9 TB	24	2.400.000	1.200.000	9.360	4.680

Para mais informações, consulte Desempenho do SSD local e Como otimizar o desempenho do SSD local.

Criptografia do SSD local

O Compute Engine criptografa automaticamente os dados quando eles são gravados no espaço de armazenamento SSD local. Não é possível usar chaves de criptografia fornecidas pelo cliente com SSDs locais.

Permanência de dados em SSDs locais

Leia Persistência de dados do SSD local para saber quais eventos preservam os dados do seu SSD local e quais eventos podem fazer com que eles não sejam recuperáveis.

Limitações gerais

É possível criar uma instância de VM com no máximo 16 ou 24 partições de SSD local para 6 TB ou 9 TB de espaço de SSD local, respectivamente, usando os tipos de máquina N1, N2 e N2D.
Para os tipos de máquina C2, C2D, A2, M1 e M3, é possível criar uma instância com até 8 partições de SSD locais, para um total de 3 TB de espaço em SSD local.
Para atingir os limites máximos de IOPS, use uma instância de VM com 32 ou mais vCPUs.
Não é possível anexar partições de SDD locais a instâncias com tipos de máquina de núcleo compartilhado.
Não é possível anexar SSDs locais a tipos de máquina E2, Tau T2D, Tau T2A e M2.

SSDs locais e tipos de máquina

É possível anexar SSDs locais a quase todos os tipos de máquina disponíveis no Compute Engine, salvo indicação em contrário. No entanto, há limitações do número de SSDs locais que pode ser anexado com base em cada tipo de máquina:

Tipos de máquina N1	Número de partições de SSD local permitidas por instância de VM
Todos os tipos de máquina N1	1 a 8, 16 ou 24
Tipos de máquina N2
Tipos de máquina com duas a 10 vCPUs	1, 2, 4, 8, 16, ou 24
Tipos de máquina com 12 a 20 vCPUs	2, 4, 8, 16, ou 24
Tipos de máquina com 22 a 40 vCPUs	4, 8, 16, ou 24
Tipos de máquina com 42 a 80 vCPUs	8, 16, ou 24
Tipos de máquina com 82 a 128 vCPUs, inclusive	16 ou 24
Tipos de máquina N2D
Tipos de máquina com 2 a 16 vCPUs, inclusive	1, 2, 4, 8, 16, ou 24
Tipos de máquina com 32 ou 48 vCPUs	2, 4, 8, 16, ou 24
Tipos de máquina com 64 ou 80 vCPUs	4, 8, 16, ou 24
Tipos de máquina com 96 a 224 vCPUs, inclusive	8, 16, ou 24
Tipos de máquina C2
Tipos de máquina com 4 ou 8 vCPUs	1, 2, 4 ou 8
Tipos de máquina com 16 vCPUs	2, 4 ou 8
Tipos de máquina com 30 vCPUs	4 ou 8
Tipos de máquina com 60 vCPUs	8
Tipos de máquina C2D
Tipos de máquina com 2 a 16 vCPUs, inclusive	1, 2, 4 ou 8
Tipos de máquinas com 32 vCPUs	2, 4 ou 8
Tipos de máquinas com 56 vCPUs	4 ou 8
Tipos de máquinas com 112 vCPUs	8
Tipos de máquina A2
`a2-highgpu-1g`	1, 2, 4 ou 8
`a2-highgpu-2g`	2, 4 ou 8
`a2-highgpu-4g`	4 ou 8
`a2-highgpu-8g` ou `a2-megagpu-16g`	8
Tipos de máquina G2
`g2-standard-4`	1
`g2-standard-8`	1
`g2-standard-12`	1
`g2-standard-16`	1
`g2-standard-24`	2
`g2-standard-32`	1
`g2-standard-48`	4
`g2-standard-96`	8
Tipos de máquina M1
`m1-ultramem-40`	Indisponível
`m1-ultramem-80`	Indisponível
`m1-megamem-96`	1 a 8
`m1-ultramem-160`	Indisponível
Tipos de máquina M1
`m3-ultramem-32`	4, 8
`m3-megamem-64`	4, 8
`m3-ultramem-64`	4, 8
`m3-megamem-128`	8
`m3-ultramem-128`	8
Tipos de máquina E2, Tau T2D, Tau T2A e M2	Esses tipos de máquina não são compatíveis com unidades SSD locais.

SSDs locais e instâncias de VM preemptivas

É possível iniciar uma instância de VM preemptiva com um SSD local. Nesse caso, o Compute Engine cobra os preços spot pelo uso do SSD local. Os SSDs locais conectados a instâncias preemptivas funcionam como SSDs locais normais, mantêm as mesmas características de persistência de dados e permanecem vinculados por toda a vida útil da instância.

No Compute Engine, não haverá cobrança pelos SSDs locais se as instâncias deles forem definidas como preemptivas a partir do primeiro minuto de execução.

Para mais informações sobre SSDs locais, consulte Como adicionar SSDs locais.

Como reservar SSDs locais com descontos por uso contínuo

Para reservar recursos de SSD local em uma zona específica, consulte Reservas de recursos zonais do Compute Engine.

Para receber descontos por compromisso de uso para SSDs locais em uma zona específica, crie e anexe reservas aos compromissos adquiridos para esses recursos de SSD local. Para mais informações, consulte Anexar reservas a compromissos.

Buckets do Cloud Storage

Os buckets do Cloud Storage são a opção de armazenamento mais flexível, escalonável e durável para as instâncias de VM. Se os aplicativos não exigirem a menor latência de discos permanentes e SSDs locais, é possível armazenar os dados em um bucket do Cloud Storage.

Conecte a instância a um bucket do Cloud Storage quando a latência e a capacidade não forem prioridade, e quando você precisar compartilhar dados com facilidade entre várias instâncias ou zonas.

Desempenho

O desempenho dos buckets do Cloud Storage depende da classe de armazenamento selecionada e do local do bucket relacionado à instância.

A classe de armazenamento padrão usada no mesmo local da instância tem um desempenho comparável ao dos discos permanentes, mas com maior latência e características de capacidade menos consistentes. Essa classe quando usada em um local multirregional armazena os dados de forma redundante em pelo menos duas regiões em um local multirregional maior.

As classes Nearline e Coldline Storage servem principalmente para arquivamento de dados a longo prazo. Ao contrário da classe de armazenamento padrão, essas classes de arquivamento têm cargas de leitura e durações de armazenamento mínimas. Por isso, elas são melhores para o armazenamento a longo prazo de dados que são acessados com pouca frequência.

Confiabilidade

Todos buckets do Cloud Storage têm redundância incorporada para proteger seus dados contra falhas em equipamentos e garantir a disponibilidade deles durante eventos de manutenção de data center. Os checksums são calculados para todas as operações do Cloud Storage para garantir que você consiga ler exatamente aquilo que gravou.

Flexibilidade

Ao contrário dos discos permanentes, os buckets do Cloud Storage não estão restritos à zona em que a instância está localizada. Além disso, é possível ler e gravar dados em um bucket a partir de várias instâncias ao mesmo tempo. Por exemplo, configure instâncias em várias zonas para ler e gravar dados no mesmo bucket em vez de replicar os dados em discos permanentes em várias zonas.

Criptografia do Cloud Storage

O Compute Engine criptografa automaticamente os dados antes que eles saiam da instância para os buckets do Cloud Storage. Você não precisa criptografar os arquivos nas instâncias antes de gravá-los em um bucket.

Assim como nos discos permanentes, é possível criptografar buckets com suas próprias chaves de criptografia.

Como gravar e ler dados dos buckets do Cloud Storage

Grave e leia arquivos dos buckets do Cloud Storage usando a ferramenta de linha de comando gsutil ou a API Cloud Storage.

gsutil

Por padrão, a ferramenta de linha de comando gsutil está instalada na maioria das VMs que usa imagens públicas. Se sua VM não tiver a ferramenta de linha de comando gsutil, instale gsutil como parte da Google Cloud CLI.

Conecte-se a uma instância.
1. No Console do Google Cloud, acesse a página Instâncias de VMs.
  Acessar instâncias de VM
2. Na lista de instâncias de máquina virtual, clique em SSH na linha da instância à qual você quer se conectar.
Se você nunca usou gsutil nessa instância, configure as credenciais com a CLI gcloud.
```
gcloud init
```
Como alternativa, se a instância estiver configurada para usar uma conta de serviço com um escopo de Cloud Storage, pule esta etapa.
Use a ferramenta gsutil para criar buckets e ler e gravar dados deles. Para gravar ou ler dados de um bucket, você precisa ter acesso a ele. Também é possível ler os dados de qualquer bucket que tenha acesso público.

Também é possível fazer streaming de dados para o Google Cloud Storage.

API

Se você configurou a instância para usar uma conta de serviço com um escopo do Cloud Storage, utilize a API Cloud Storage para gravar e ler dados dos buckets dessa solução.

Conecte-se a uma instância.
1. No Console do Google Cloud, acesse a página Instâncias de VMs.
  Acessar instâncias de VM
2. Na lista de instâncias de máquina virtual, clique em SSH na linha da instância à qual você quer se conectar.
Instale e configure uma biblioteca de cliente na linguagem que preferir.
Se necessário, siga os exemplos de código de inserção para criar um bucket do Cloud Storage na instância.
Siga os exemplos de código de inserção para gravar e ler dados e inclua o código no app que grava ou lê um arquivo de um bucket do Cloud Storage.

A seguir

Faça um teste

Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho do Compute Engine em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

Faça uma avaliação gratuita do Compute Engine