COMPUTE ENGINE Features
Pricing for Compute Engine is based on per-second usage of the machine types, persistent disks, and other resources
that you select for your virtual machines.
Predefined machine types
Compute Engine offers predefined virtual machine configurations
for every need from small general purpose instances to large
memory-optimized instances with up to 11.5 TB of RAM or fast
compute-optimized instances with up to 60 vCPUs.
Custom machine types
Create a virtual machine with a custom machine type that best fits
your workloads. By tailoring a custom machine type to your specific
needs, you can realize significant savings.
Preemptible VMs
Low-cost, short-term instances designed to run batch jobs and
fault-tolerant workloads. Preemptible VMs provide significant
savings of up to 80% while still getting the same performance and
capabilities as regular VMs.
Live migration for VMs
Compute Engine virtual machines can live-migrate between host
systems without rebooting, which keeps your applications running
even when host systems require maintenance.
Persistent disks
Durable, high performance block storage for your VM instances.
You can create persistent disks in HDD or SSD formats. You can
also take snapshots and create new persistent disks from that
snapshot. If a VM instance is terminated, its persistent disk retains
data and can be attached to another instance.
Local SSD
Compute Engine offers always-encrypted local solid-state drive
(SSD) block storage. Local SSDs are physically attached to the
server that hosts the virtual machine instance for very high
input/output operations per second (IOPS) and very low latency
compared to persistent disks.
GPU accelerators
GPUs can be added to accelerate computationally intensive
workloads like machine learning, simulation, medical analysis, and
virtual workstation applications. Add or remove GPUs to a VM when
your workload changes and pay for GPU resources only while you
are using them.
Global load balancing
Global load-balancing technology helps you distribute incoming
requests across pools of instances across multiple regions, so you
can achieve maximum performance, throughput, and availability at
low cost.
Linux and Windows support
Run your choice of OS, including Debian, CentOS, CoreOS, SUSE,
Ubuntu, Red Hat Enterprise Linux, FreeBSD, or Windows Server
2008 R2, 2012 R2, and 2016. You can also use a shared image
from the Google Cloud community or bring your own.
Per-second billing
Google bills in second-level increments. You pay only for the
compute time that you use.
Commitment savings
With committed-use discounts you can save up to 57% with no up-
front costs or instance-type lock-in.
Sustained-use savings
Sustained-use discounts are automatic discounts for running
Compute Engine resources for a significant portion of the billing
month.
Container support
Run, manage, and orchestrate Docker containers on Compute
Engine VMs with Google Kubernetes Engine.
Reservations
Create reservations for VM instances in a specific zone. Use
reservations to ensure that your project has resources for future
increases in demand. When you no longer need a reservation,
delete the reservation to stop incurring charges for it.
Right-sizing recommendations
Compute Engine provides machine type recommendations to help
you optimize the resource utilization of your virtual machine (VM)
instances. Use these recommendations to resize your instance’s
machine type to more efficiently use the instance’s resources.
OS patch management
With OS patch management, you can apply OS patches across a
set of VMs, receive patch compliance data across your
environments, and automate installation of OS patches across VMs
- all from a centralized location.
Placement Policy
Use Placement Policy to specify the location of your underlying
hardware instances. Spread Placement Policy provides higher
reliability by placing instances on distinct hardware, reducing the
impact of underlying hardware failures. Compact Placement Policy
provides lower latency between nodes by placing instances close
together within the same network infrastructure.
Cloud Storage Persistent disk
Accessibility Accessibility
Global accessibility (including Accessibility in one zone only and
non-Compute Engine only by Compute Engine instances
systems)
Mounted read-write by one instance
Accessible read-write from or read-only by many Compute
many systems Engine instances
Scale Scale
Multi-PB scale buckets 10 TB volume limit
Characteristics
How to use How to use
REST interface; higher latency SCSI interface; lower latency
than locally attached block
Write semantics are transactional -
storage
random edits
Write semantics include insert
No versioning; continuous edits
and overwrite file only
Must format a filesystem to make
Offers versioning
usable for files
Files implicit in Cloud Storage
Content distribution for mobile, Compute Engine boot devices
consumer, gaming, and SaaS
Raw block datastore to build
Rich media
SQL servers (e.g., MySQL)
Read-only input for
NoSQL servers (e.g.,
Target Users parallelizable HPC work (e.g.,
Cassandra/Mongo)
rendering and genomics)
Fileservers (e.g., Gluster)
Backup and archival
Key value store persistence (e.g.,
Hadoop (via GHFS)
Redis)
Cloud Bigtable is not a relational database. It does not support SQL queries, joins, or multi-row
transactions. Cloud Bigtable is not a good solution for storing less than 1 TB of data.
If you need full SQL support for an online transaction processing (OLTP) system, consider Cloud Spanner
or Cloud SQL.
If you need interactive querying in an online analytical processing (OLAP) system, consider BigQuery.
If you need to store highly structured objects in a document database, with support for ACID transactions
and SQL-like queries, consider Firestore.
For in-memory data storage with low latency, consider Memorystore.
To sync data between users in realtime, consider the Firebase Realtime Database.
Preemptible VMs are low-cost instances that can run up to 24 hours before being preempted,
or shut down. They are a good option for batch processing and other tasks that are
easily recovered and restarted.
Autoscaling enables engineers to deploy an adequate number of instances needed to meet
the load on a system. When demand is high, instances are increased, and when demand is
low, the number of instances is reduced
Structured data fits well with both relational and NoSQL databases. If SQL
is required, then your choices are Cloud SQL, Spanner, BigQuery, or running a relational
database yourself in Compute Engine. If you require a global, strongly consistent transactional
data store, then Spanner is the best choice, while Cloud SQL is a good choice for
regional-scale databases. If the application using the database requires a flexible schema,
then you should consider NoSQL options. Cloud Datastore is a good option when a document
store is needed, while Bigtable is well suited for ingesting large volumes of data at
low latency.
Of course, you could run a NoSQL database in Compute Engine. If a service needs to
ingest time-series data at low latency and one of the business requirements is to maximize
the use of managed services, then Bigtable should be used. If there is no requirement
to use managed services, you might consider deploying Cassandra to a cluster in
Compute Engine. This would be a better choice, for example, if you are planning a liftand-
shift migration to the cloud and are currently running Cassandra in an on-premises
data center.
Since Cloud Storage has four types of storage, you will have to consider access
patterns and reliability requirements. If the data is frequently accessed, then regional or
multiregional class storage is appropriate. If high availability of access to the data is a
concern or if data will be accessed from different areas of the world, you should consider
multiregional storage. If data will be infrequently accessed, then Nearline or Coldline
storage is a good choice. Nearline storage is designed for data that won’t be accessed
more than once a month. Coldline storage is well suited for data that will be accessed not
more than once a year
If you need to transmit more than 10 Gbps, then you should consider a Cloud Interconnect solution over a VPN
solution, which works up to about 3 Gbps
Jenkins and Spinnaker are widely used tools to support continuous integration and deployment. Google Cloud has a
code repository, but many developers use GitHub.
Sometimes businesses are locked into existing solutions, such as a third-party database
Preemptible VMs are well suited for batch jobs or other workloads that can be disrupted
and restarted. They are not suitable for running services that need high availability, such as
a database or user-facing service, like a web server.
Preemptible VMs are also not suitable for applications that manage state in memory
or on the local SSD. Preemptible VMs cannot be configured to live migrate; when they
are shut down, locally persisted data and data in memory are lost. If you want to use preemptible
VMs with stateful applications, consider using Cloud Memorystore, a managed
Redis service for caching data, or using a database to store state
Mountkrik:
The executive statement notes, “replace MySQL and move to an environment that provides
autoscaling, low latency load balancing, and that frees us up from managing physical
servers.” Cloud SQL running MySQL meets the requirements to free the company from
managing physical servers, but it does not provide autoscaling. The MySQL database is
used for reporting and analytics, so this is a good candidate for BigQuery.
BigQuery is a fully managed database, with load distribution and autoscaling. This
meets the requirement to “dynamically scale up or down based on game activity.” It also
uses SQL as a query language, so users would not have to learn a new query language and
existing reporting tools will likely work with BigQuery. BigQuery is also a good option for
meeting the requirement to store at least 10 TB of historical data. (Currently, Cloud SQL
can store up to 10 TB, which makes BigQuery a good choice).
There is a requirement to “process data that arrives late because of slow mobile networks.”
This requirement could be satisfi ed using a common ingestion and preprocessing
pattern of writing data to a Cloud Pub/Sub topic, which is read by a Cloud Datafl ow process
and transformed as needed and then written to BigQuery
The Dress4Win storage requirements include specifications for database storage,
network-attached storage, and storage for the Spark cluster. If they use Cloud SQL instead
of a self-managed MySQL server, they can improve storage availability by using regional
replicas. Using Cloud Storage will provide highly available storage for images, logs, and
backups. If Dress4Win decides to use Cloud Dataproc instead of managing its own Spark
cluster, then storage availability will be managed by the Google Cloud Platform.
TerramEarth needs to store 9 TB of equipment data per day. This data is time-series
data, which means that each record has a time stamp, identifiers indicating the piece of
equipment that generated the data, and a series of metrics. Bigtable is a good option when
you need to write large volumes of data in real time at low latency. Bigtable has support
for regional replication, which improves availability. Regional or zonal persistent disk
can be used with Compute Engine VMs. Regional persistent disks provide higher availability
if needed.
Redundant network connections can be used to increase the availability of the network
between an on-premises data center and google’s data center. One type of connection is
a dedicated interconnect, which can be used with a minimum of 10 Gbps throughput
and does not traverse the public Internet. A Partner Interconnect is another option. In
this case, traffic flows through a telecommunication provider’s network, not the Internet.
VPNs can also be used when sending data over the Internet is not a problem.
Persistent Disks are well suited for large-volume, batch processing when low cost and high storage volume
are
important. When performance is a consideration, such as when running a database on a
VM, persistent SSDs are the better option
