Capacity Planning for Google Compute Engine

This page describes capacity planning for deploying Aerospike Database in Google Compute Engine (GCE).

The two most common use-cases for Aerospike are:

• An in-memory cache with no persistence
• A fast persistent data store

We will look at how to implement these cases on the Google Compute Engine platform. For information about more choices to organize your storage, see the storage engines documentation.

GCE offers both x86_64 and Arm-based VM instances. Aerospike supports 64-bit Arm deployments on supported Linux distributions, so include Arm-based instances in your capacity planning when they meet your CPU, memory, storage, and operating system requirements. For package architecture details and Linux requirements, see Install on Google Compute Engine and Install on Linux.

Aerospike as a Fast Persistent Data Store

Take advantage of local disk performance with the persistence guarantee of persistent disks. An extension of our SSD Storage Engine, the Shadow Device Storage Engine is designed for cloud environments like Google Compute Engine.

Google Compute Engine provides persistent storage in the form of Persistent Disks that are network-attached to virtual machine instances.

In this storage engine, only the index resides in memory and data is stored in Persistent Disks.

Pros:

• Comparatively less RAM and fewer number of nodes required.
• Can make use of instances with lesser RAM.
• Provides persistence model.

Cons:

• The maximum possible TPS is potentially bottlenecked by maximum available Persistent Disks IOPS.
• Further degradation of service due to Persistent Disks performance uncertainties is possible.

We recommend using the SSD Persistent Disks for storage while configuring your Aerospike data store, as they offer better performance.

• Create and attach local disks: You must create the VM with Local disks. It cannot be added later.

• Create and attach an SSD persistent disk: You can use either the Google Compute Engine web console or the gcloud command to do it programmatically

• Configure Aerospike to use the local and persistent SSD: Once the disk has been attached to the instance, it should appear as a block device (e.g.: /dev/disk/by-id/google-persistent-disk-1 and /dev/disk/by-id/google-local-disk-0) on your instance. Next, you should use the recipe for Shadow Device to configure an Aerospike namespace to use these devices for storage.

You can read more about our recommendations about local and persisted disks on our recommendations page

High availability using zones

GCE resources are hosted in multiple locations world-wide. These locations are composed of regions and zones. Putting resources in different zones in a region provides isolation for many types of infrastructure, hardware, and product failures. Putting resources in different regions provides an even higher degree of failure independence. Read more from Google Compute Engine Regions and Zones documentation.

Aerospike Enterprise Edition includes Cross-Datacenter Replication (XDR), which replicates clusters across multiple datacenters. Contact Aerospike for further details.

Related documentation

For more information about disk and memory sizing, see Capacity planning guide. For more information about storage options, see Configure namespace storage.