# Capacity Planning for Google Compute Engine

::: note
For more information about disk and memory sizing, see [capacity planning](https://aerospike.com/docs/database/manage/planning/capacity).
:::

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](https://aerospike.com/docs/database/manage/namespace/storage/config) 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](https://aerospike.com/docs/database/manage/namespace/storage/config/#setup-for-an-ssd-storage-engine), the [Shadow Device Storage Engine](https://aerospike.com/docs/database/manage/namespace/storage/config/#setup-for-shadow-device) is designed for cloud environments like Google Compute Engine.

Google Compute Engine provides persistent storage in the form of [Persistent Disks](https://cloud.google.com/compute/docs/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](https://cloud.google.com/compute/docs/disks#pdperformance).

-   **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](https://console.developers.google.com/project) or the **gcloud** command to [do it programmatically](https://cloud.google.com/compute/docs/disks#create_disk)
    
-   **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](https://aerospike.com/docs/database/manage/namespace/storage/config/#setup-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](https://aerospike.com/docs/database/install/gcp/best-practices#persistence)

### 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](https://cloud.google.com/compute/docs/zones).

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](http://kafka.apache.org/) or [RabbitMQ](http://www.rabbitmq.com/).

[Aerospike Enterprise Edition](https://aerospike.com/products/features-and-editions/) has [Cross-Datacenter Replication (XDR)](https://aerospike.com/docs/database/manage/xdr/dynamic-xdr) feature, which handles clusters located in multiple datacenters. [Contact Aerospike](https://aerospike.com/contact/) for further details.