Capacity Planning for Google Compute Engine

info

For details on disk and memory sizing, see the main capacity planning docs.

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 on more choices to organize your storage, see the storage engines documentation.

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 SSD Persistent Disk: 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

Google Cloud Platform 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 software failures. Putting resources in different regions provides an even higher degree of failure independence. Read more from Google Compute Engine Regions and Zones documentation.

If you wish to configure multiple Aerospike cluster across two or more zones or regions, we suggest you use an Application-level Queue like Kafka or RabbitMQ.

Aerospike Enterprise Edition has Cross-Datacenter Replication (XDR) feature, which handles clusters located in multiple datacenters. Contact Aerospike for further details.