diff --git a/documentation/deployment/gcp.md b/documentation/deployment/gcp.md index be59034a8..6d1c019a1 100644 --- a/documentation/deployment/gcp.md +++ b/documentation/deployment/gcp.md @@ -1,341 +1,495 @@ --- -title: Deploying to Google Cloud Platform (GCP) +title: Deploying QuestDB on GCP sidebar_label: GCP description: - This document explains what to hardware to use, and how to provision QuestDB on Google Cloud Platform (GCP). + Deploy QuestDB on Google Cloud Platform using Compute Engine, with instance sizing, storage, and networking recommendations. --- - -import FileSystemChoice from "../../src/components/DRY/_questdb_file_system_choice.mdx" +import Screenshot from "@theme/Screenshot" +import InterpolateReleaseData from "../../src/components/InterpolateReleaseData" +import CodeBlock from "@theme/CodeBlock" import MinimumHardware from "../../src/components/DRY/_questdb_production_hardware-minimums.mdx" -## Hardware recommendations +## Quick reference - +| Component | Recommended | Notes | +|-----------|-------------|-------| +| Instance | `c3-standard-4` or `c3-highmem-8` | 4-8 vCPUs, 16-64 GiB RAM | +| Storage | Hyperdisk Balanced data disk, 300+ GiB | 5000 IOPS / 300 MBps for production | +| File system | `ext4` | Or `zfs` with `lz4` for on-disk compression | +| Ports | 9000, 8812, 9009, 9003 | Restrict to known IPs only | -### Google Compute Engine with Google Cloud Hyperdisk +--- -Google Compute Engine offers a variety of VM instances tuned for different workloads. +## Infrastructure +Plan your infrastructure before launching. This section covers instance types, +storage, and networking requirements. -Do **not** use instances containing the letter `A`, such as `C4A`. These are `ARM` architecture instances, -using Axion processors. + -Either `AMD EPYC` CPUs (`D` letter) or `Intel Xeon` (no letter) are appropriate for `x86_64` deployments. +### Instance sizing -We recommend starting with `C-Series` instances, and reviewing other instance types if your workload demands it. +| Workload | Instance | vCPUs | RAM | Use case | +|----------|----------|-------|-----|----------| +| Development | `c3-standard-4` | 4 | 16 GiB | Testing, small datasets | +| Production (starter) | `c3-highmem-4` | 4 | 32 GiB | Light ingestion, moderate queries | +| Production (standard) | `c3-highmem-8` | 8 | 64 GiB | High ingestion, complex queries | +| Production (heavy) | `c3-highmem-22` | 22 | 176 GiB | Heavy workloads, large datasets | -You should deploy using an `x86_64` Linux distribution, such as Ubuntu. +**Choosing an instance family:** -For storage, we recommend using [Hyperdisk Balanced](https://cloud.google.com/compute/docs/disks/hyperdisks) disks, -and provisioning them at `5000 IOPS/300 MBps` until you have tested your workload. +Start with `C3` (Intel Xeon) or `C3D` (AMD EPYC) instances. Both perform +similarly for QuestDB. Choose based on availability and pricing in your region. + +You can use the `highcpu`, `standard`, and `highmem` variants to adjust the +RAM-to-vCPU ratio between `2:1`, `4:1`, and `8:1`. Higher RAM can improve query +performance dramatically when it lets your working set fit entirely in memory. :::warning -Hyperdisk Balanced is not supported on all machine types. N2 instances do not -support Hyperdisk. Use N4, C3, or C4 series instances with Hyperdisk Balanced. +Do **not** use instances containing the letter `A`, such as `C4A`. These are +ARM architecture instances using Axion processors. QuestDB's JIT compilation and +SIMD optimizations are limited on ARM. Deploy on `x86_64` instances and an +`x86_64` Linux distribution such as Ubuntu. ::: -`Hyperdisk Extreme` generally requires much higher `vCPU` counts - for example, it cannot be used on `C3` machines -smaller than `88 vCPUs`. - - +### Storage +Use [Hyperdisk Balanced](https://cloud.google.com/compute/docs/disks/hyperdisks) +volumes for QuestDB data, provisioned at `5000 IOPS / 300 MBps` until you have +tested your workload. Keep the OS disk separate from the QuestDB data disk, and +mount the data disk at `/var/lib/questdb`. -### Google Filestore +| Workload | Disk | Size | IOPS | Throughput | +|----------|------|------|------|------------| +| Development | Hyperdisk Balanced | 100 GiB | 3000 | 140 MBps | +| Production | Hyperdisk Balanced | 300+ GiB | 5000 | 300 MBps | +| High I/O | Hyperdisk Balanced | 500+ GiB | 5000+ | 300+ MBps | -Google Filestore is a managed NFS service that can be used as a replication -transport layer in QuestDB Enterprise. - -Filestore should **not** be used as primary storage for QuestDB. However, it -is well-suited for replication when low latency is required. The `fs::` -transport over NFS provides sub-200ms replication lag with -[aggressive tuning](/docs/high-availability/tuning/), compared to ~1s+ with -object store transport (GCS). - -To use Filestore for replication: - -1. Create a Filestore instance in the same region as your QuestDB VMs -2. Mount the NFS share on both primary and replica nodes -3. Configure the `fs::` transport in `server.conf`: +:::warning +Hyperdisk Balanced is not supported on all machine types. N2 instances do not +support Hyperdisk. Use N4, C3, or C4 series instances with Hyperdisk Balanced. +::: -```ini -replication.object.store=fs::root=/mnt/questdb-repl/final;atomic_write_dir=/mnt/questdb-repl/scratch; -``` +`Hyperdisk Extreme` generally requires much higher vCPU counts. For example, it +cannot be used on `C3` machines smaller than `88 vCPUs`. -Use the [backup](/docs/operations/backup/) feature to manage WAL file retention -on the NFS mount. +**File system:** -On GKE, expose the Filestore share as a `PersistentVolume` with -`ReadWriteMany` access mode using the -[Filestore CSI driver](https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/filestore-csi-driver), -so both primary and replica pods can mount it simultaneously. +Format the data disk as `ext4`. If you need on-disk compression, use `zfs` with +`lz4` instead, at a small performance cost. See +[ZFS compression](/docs/deployment/compression-zfs/). -:::note -Filestore Zonal and Basic SSD tiers may require a -[quota increase](https://cloud.google.com/docs/quotas/view-manage) before use. -Basic HDD is typically available by default. -::: +**Unsupported storage:** -### Google Cloud Storage +- **Filestore** - Not supported as primary storage (NFS latency too high). Use + for Enterprise replication only (see [Enterprise on GCP](#enterprise-on-gcp)). +- **Google Cloud Storage** - Not supported as primary storage. Use for + Enterprise replication only. -QuestDB supports Google Cloud Storage as its replication object store in the -Enterprise edition. GCS is the simplest and cheapest replication transport, but -has higher latency (~1s+) due to object store API overhead. +### Networking -To get started, create a bucket for the database to use. Then follow the -[Enterprise Quick Start](/docs/getting-started/enterprise-quick-start/) steps to create a connection string and -configure QuestDB. +**Firewall rules:** -### NetApp Volumes +| Port | Protocol | Source | Purpose | +|------|----------|--------|---------| +| 22 | TCP | Your IP | SSH access | +| 9000 | TCP | Your IP / VPC | Web Console & REST API | +| 8812 | TCP | Your IP / VPC | PostgreSQL wire protocol | +| 9009 | TCP | Application servers | InfluxDB line protocol | +| 9003 | TCP | Monitoring servers | Health check & Prometheus | -[NetApp Volumes](https://cloud.google.com/netapp/volumes/docs/discover/overview) -is a managed NFS service on GCP backed by NetApp ONTAP. Like Filestore, it can -be used as a low-latency replication transport via the `fs::` prefix. The -QuestDB configuration is identical to Filestore. +The firewall rule below opens only 9000 and 8812. Add 9009 only if you ingest +over ILP, and reach 9003 from within the VPC or over SSH rather than exposing +it publicly. -:::note -NetApp Volumes requires enabling the `netapp.googleapis.com` API and may -require separate quota allocation. +:::warning +Never expose ports 9000, 8812, or 9009 to `0.0.0.0/0`. Restrict access to known +IP ranges or use an Identity-Aware Proxy (IAP) bastion. ::: -### Minimum specification +**VPC recommendations:** -- **Instance**: `c3-standard-4` or `c3d-standard-4` `(4 vCPUs, 16 GB RAM)` -- **Storage** - - **OS disk**: `Hyperdisk Balanced (30 GiB)` volume provisioned with `3000 IOPS/140 MBps`. - - **Data disk**: `Hyperdisk Balanced (100 GiB)` volume provisioned with `3000 IOPS/140 MBps`. -- **Operating System**: `Linux Ubuntu 24.04 LTS x86_64`. -- **File System**: `ext4` +- Deploy QuestDB in a private subnet +- Use Cloud NAT for outbound access (package updates, etc.) +- Use a network tag (this guide uses `questdb`) so one firewall rule applies to + every QuestDB instance you create +- Use Private Google Access for GCS if using Enterprise replication +--- -### Better specification +## Deployment -- **Instance**: `c3-highmem-8` or `c3d-highmem-8` `(8 vCPUs, 64 GB RAM)` -- **Storage** - - **OS disk**: `Hyperdisk Balanced (30 GiB)` volume provisioned with `5000 IOPS/300 MBps`. - - **Data disk**: `Hyperdisk Balanced (300 GiB)` volume provisioned with `5000 IOPS/300 MBps`. -- **Operating System**: `Linux Ubuntu 24.04 LTS x86_64`. -- **File System**: `zfs` +Deploy QuestDB on a Google Compute Engine virtual machine. :::note - -You can use the `highcpu` and `highmem` variants to adjust the `standard` `4:1` RAM/vCPU -ratio to `2:1` or `8:1` respectively. Higher RAM can improve performance dramatically -if it means your working set data will fit entirely into memory. - +Deploying QuestDB as a container at VM creation (the **Deploy Container** option +on Compute Engine) is no longer supported. Create a standard Linux VM and +install QuestDB over SSH as described below. ::: - -## Launching QuestDB on Google Compute Engine - -This guide describes how to run QuestDB on a new Google Cloud Platform (GCP) -Compute Engine instance. After completing this guide, you will have an instance -with QuestDB running in a container using the official QuestDB Docker image, as -well as a network rule that enables communication over HTTP and PostgreSQL wire -protocol. - ### Prerequisites - A [Google Cloud Platform](https://console.cloud.google.com/getting-started) - (GCP) account and a GCP Project + account and a GCP project - The [Compute Engine API](https://console.cloud.google.com/apis/api/compute.googleapis.com) - must be enabled for the corresponding Google Cloud Platform project + enabled for that project +- An SSH key registered with your project or account +- The [Google Cloud CLI](https://cloud.google.com/sdk/docs/install) if you want + to use the `gcloud` commands instead of the console +- A client source CIDR for firewall rules, such as your workstation IP address + with `/32`. Do not use `0.0.0.0/0` for QuestDB ports. -### Create a Compute Engine VM +### Create the VM 1. In the Google Cloud Console, navigate to [Compute Engine](https://console.cloud.google.com/compute/instances) and click **Create Instance** -import Screenshot from "@theme/Screenshot" - -2. Give the instance a name - this example uses `questdb-europe-west3` -3. Choose a **Region** and **Zone** where you want to deploy the instance - this - example uses `europe-west3 (Frankfurt)` and the default zone -4. Choose a machine configuration. The default choice, `ec2-medium`, is a - general-purpose instance with 4GB memory and should be enough to run this - example. - - {" "} - -5. To add a running QuestDB container on instance startup, scroll down and click - the **Deploy Container** button. Then, provide the `latest` QuestDB Docker - image in the **Container image** textbox. - - ```text - questdb/questdb:latest - ``` - - Click the **Select** button at the bottom of the dropdown to complete the - container configuration. +2. Give the instance a name. This example uses `questdb-europe-west3` +3. Choose a **Region** and **Zone**. This example uses + `europe-west3 (Frankfurt)` and the default zone +4. Select a machine configuration (see [Instance sizing](#instance-sizing)) +5. Under **Boot disk**, click **Change** and choose **Ubuntu 24.04 LTS + (x86/64)** as the image +6. Set the boot disk type to **Hyperdisk Balanced** and the size to `30 GiB` +7. Add a separate blank **Hyperdisk Balanced** data disk: + - Set **Name** to `questdb-data` + - Set **Size** to `300 GiB` for production, or `100 GiB` for development + - Set **Provisioned IOPS** to `5000` + - Set **Provisioned throughput** to `300 MBps` + - Set **Deletion rule** to **Keep disk** if you want the data disk to survive + instance deletion + - Set the device name to `questdb-data` - Your docker configuration should look like this: - - {" "} + -Before creating the instance, we need to assign it a **Network tag** so that we -can add a firewall rule that exposes QuestDB-related ports to the internet. This -is required for you to access the database from outside your VPC. To create a -**Network tag**: +Before creating the instance, assign it a **Network tag** so a firewall rule can +expose the QuestDB ports: -1. Expand the **Advanced options** menu below the **firewall** section, and then - expand the **Networking** panel -2. In the **Networking** panel add a **Network tag** to identify the instance. - This example uses `questdb` +1. Expand the **Advanced options** menu, then expand the **Networking** panel +2. Add a **Network tag** to identify the instance. This example uses `questdb` -You can now launch the instance by clicking **Create** at the bottom of the -dialog. +Click **Create** at the bottom of the dialog to launch the instance. + +If you prefer Cloud Shell or another shell with `gcloud` configured, this is the +equivalent VM and disk setup: + +```bash +export QDB_INSTANCE="questdb-europe-west3" +export QDB_ZONE="europe-west3-a" +export QDB_MACHINE_TYPE="c3-standard-4" +export QDB_TAG="questdb" +export QDB_DISK="questdb-data" + +gcloud compute instances create "$QDB_INSTANCE" \ + --zone "$QDB_ZONE" \ + --machine-type "$QDB_MACHINE_TYPE" \ + --image-family "ubuntu-2404-lts-amd64" \ + --image-project "ubuntu-os-cloud" \ + --boot-disk-size "30GiB" \ + --boot-disk-type "hyperdisk-balanced" \ + --tags "$QDB_TAG" + +gcloud compute disks create "$QDB_DISK" \ + --zone "$QDB_ZONE" \ + --size "300GiB" \ + --type "hyperdisk-balanced" \ + --provisioned-iops "5000" \ + --provisioned-throughput "300" \ + --access-mode "READ_WRITE_SINGLE" + +gcloud compute instances attach-disk "$QDB_INSTANCE" \ + --zone "$QDB_ZONE" \ + --disk "$QDB_DISK" \ + --device-name "$QDB_DISK" +``` ### Create a firewall rule -Now that we've created our instance with a `questdb` network tag, we need to -create a corresponding firewall rule to associate with that tag. This rule will -expose the required ports for accessing QuestDB. With a network tag, we can -easily apply the new firewall rule to our newly created instance as well as any -other QuestDB instances that we create in the future. +The network tag lets a single firewall rule apply to this instance and any +future QuestDB instances you create with the same tag. 1. Navigate to the [Firewall configuration](https://console.cloud.google.com/net-security/firewall-manager/firewall-policies) - page under **Network Security** -> **Firewall policies** -2. Click the **Create firewall rule** button at the top of the page + page under **Network Security** → **Firewall policies** +2. Click **Create firewall rule** 3. Enter `questdb` in the **Name** field -4. Scroll down to the **Targets** dropdown and select "Specified target tags" -5. Enter `questdb` in the **Target tags** textbox. This will apply the firewall - rule to the new instance that was created above -6. Under **Source filter**, enter an IP range that this rule applies to. This - example uses `0.0.0.0/0`, which allows ingress from any IP address. We - recommend that you make this rule more restrictive, and naturally that you - include your current IP address within the chosen range. -7. In the **Protocols and ports** section, select **Specified protocols and - ports**, check the **TCP** option, and type `8812,9000` in the textbox. -8. Scroll down and click the **Create** button +4. Under **Targets**, select **Specified target tags** and enter `questdb` in + **Target tags** +5. Under **Source filter**, enter the IP range this rule applies to. Restrict + this to your own IP range rather than `0.0.0.0/0` (see + [Networking](#networking)) +6. Under **Protocols and ports**, select **Specified protocols and ports**, + check **TCP**, and enter `8812,9000` +7. Click **Create** -All VM instances on Compute Engine in this account which have the **Network -tag** `questdb` will now have this firewall rule applied. +:::warning +Only add port 9009 if you need ILP ingestion, and restrict the source to your +application servers. +::: -The ports we have opened are: +The equivalent `gcloud` command is: -- `9000` for the REST API and [Web Console](/docs/getting-started/web-console/overview/) -- `8812` for the PostgreSQL wire protocol +```bash +export QDB_ALLOWED_SOURCE="YOUR_CLIENT_IP/32" -## Verify the deployment +gcloud compute firewall-rules create "questdb-client-access" \ + --network "default" \ + --target-tags "questdb" \ + --source-ranges "$QDB_ALLOWED_SOURCE" \ + --allow "tcp:9000,tcp:8812" +``` -To verify that the instance is running, navigate to **Compute Engine** -> -[VM Instances](https://console.cloud.google.com/compute/instances). A status -indicator should show the instance as **running**: +### Connect to the VM - +Connect to the instance over SSH. You can use the **SSH** button on the +[VM Instances](https://console.cloud.google.com/compute/instances) page, or +connect with `gcloud`: -To verify that the QuestDB deployment is operating as expected: +```bash +gcloud compute ssh questdb-europe-west3 --zone europe-west3-a +``` -1. Copy the **External IP** of the instance -2. Navigate to `http://:9000` in a browser +### Prepare the data disk -The [Web Console](/docs/getting-started/web-console/overview/) should now be visible: +Run these commands on the VM over SSH. They assume the attached data disk uses +the custom device name `questdb-data` and format it as `ext4`, which is the +recommended default. If you need on-disk compression, format the data disk as +`zfs` with `lz4` instead. See [ZFS compression](/docs/deployment/compression-zfs/). + +:::warning +The `mkfs.ext4` command erases the target device. Run it only on a new blank +data disk, and verify that the device path points to the data disk before +formatting. +::: + +```bash +export QDB_ROOT="/var/lib/questdb" +export QDB_DATA_DEVICE="/dev/disk/by-id/google-questdb-data" + +ls -l "$QDB_DATA_DEVICE" + +sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard "$QDB_DATA_DEVICE" +sudo mkdir -p "$QDB_ROOT" +sudo mount -o discard,defaults "$QDB_DATA_DEVICE" "$QDB_ROOT" +QDB_DATA_UUID="$(sudo blkid -s UUID -o value "$QDB_DATA_DEVICE")" +echo "UUID=$QDB_DATA_UUID $QDB_ROOT ext4 discard,defaults,nofail 0 2" | sudo tee -a /etc/fstab +sudo chown "$USER:$USER" "$QDB_ROOT" +findmnt "$QDB_ROOT" +``` + +After this step, QuestDB configuration, logs, and table data will live under +`/var/lib/questdb`. + +### Install QuestDB + +Download QuestDB and start it with `/var/lib/questdb` as the QuestDB root +directory: + + ( + +{`wget https://github.com/questdb/questdb/releases/download/${release.name}/questdb-${release.name}-rt-linux-x86-64.tar.gz +tar xzf questdb-${release.name}-rt-linux-x86-64.tar.gz +cd questdb-${release.name}-rt-linux-x86-64/bin +./questdb.sh start -d /var/lib/questdb +./questdb.sh status -d /var/lib/questdb`} + +)} +/> + +Access the Web Console at `http://:9000`, using the instance's +**External IP** from the VM Instances page. -Alternatively, a request may be sent to the REST API exposed on port 9000: +You can also send a request to the REST API on port 9000: ```bash curl -G \ --data-urlencode "query=SELECT * FROM telemetry_config" \ - :9000/exec + "http://:9000/exec" +``` + +The deployment is working when: + +- `questdb.sh status -d /var/lib/questdb` reports the service as running +- `curl http://localhost:9003/status` returns `Status: Healthy` from the VM +- `http://:9000` loads the Web Console from an allowed source IP + +For production deployments, use [systemd](/docs/deployment/systemd/) to manage +the QuestDB service. + +--- + +## Security + +### Change default credentials + +Update credentials immediately after deployment. + +**Web Console and REST API** - edit `conf/server.conf`: + +```ini +http.user=your_username +http.password=your_secure_password +``` + +**PostgreSQL** - edit `conf/server.conf`: + +```ini +pg.user=your_username +pg.password=your_secure_password +``` + +**InfluxDB line protocol** - edit `conf/auth.json`. See +[ILP authentication](/docs/ingestion/ilp/overview/#authentication). + +Restart after changes: + +```bash +./questdb.sh stop -d /var/lib/questdb +./questdb.sh start -d /var/lib/questdb +``` + +### Disable unused interfaces + +Reduce attack surface by disabling protocols you don't use: + +```ini title="conf/server.conf" +pg.enabled=false # Disable PostgreSQL +line.tcp.enabled=false # Disable ILP +http.enabled=false # Disable Web Console & REST API +http.security.readonly=true # Or make HTTP read-only +``` + +--- + +## Operations + +### Upgrading + +1. Stop QuestDB: + ```bash + ./questdb.sh stop -d /var/lib/questdb + ``` + +2. Back up your data directory + +3. Download and extract the new version: + + ( + +{`wget https://github.com/questdb/questdb/releases/download/${release.name}/questdb-${release.name}-rt-linux-x86-64.tar.gz +tar xzf questdb-${release.name}-rt-linux-x86-64.tar.gz`} + +)} +/> + +4. Start the new version: + ```bash + cd questdb-*/bin + ./questdb.sh start -d /var/lib/questdb + ``` + +### Monitoring + +**Health check:** + +```bash +curl http://localhost:9003/status ``` -### Set up GCP with Pulumi - -If you're using [Pulumi](https://www.pulumi.com/gcp/) to manage your -infrastructure, you can create a QuestDB instance with the following: - -```python -import pulumi -import pulumi_gcp as gcp - -# Create a Google Cloud Network -firewall = gcp.compute.Firewall( - "questdb-firewall", - network="default", - allows=[ - gcp.compute.FirewallAllowArgs( - protocol="tcp", - ports=["9000", "8812"], - ), - ], - target_tags=["questdb"], - source_ranges=["0.0.0.0/0"], -) - -# Create a Compute Engine Instance -instance = gcp.compute.Instance( - "questdb-instance", - machine_type="e2-medium", - zone="us-central1-a", - boot_disk={ - "initialize_params": { - "image": "ubuntu-os-cloud/ubuntu-2004-lts", - }, - }, - network_interfaces=[ - gcp.compute.InstanceNetworkInterfaceArgs( - network="default", - access_configs=[{}], # Ephemeral public IP - ) - ], - metadata_startup_script="""#!/bin/bash - sudo apt-get update - sudo apt-get install -y docker.io - sudo docker run -d -p 9000:9000 -p 8812:8812 \ - --env QDB_HTTP_USER="admin" \ - --env QDB_HTTP_PASSWORD="quest" \ - questdb/questdb - """, - tags=["questdb"], -) - -# Export the instance's name and public IP -pulumi.export("instanceName", instance.name) -pulumi.export("instance_ip", instance.network_interfaces[0].access_configs[0].nat_ip) +**Prometheus metrics:** + +```bash +curl http://localhost:9003/metrics +``` + +**Cloud Monitoring integration:** + +Use the Ops Agent to collect: +- VM metrics (CPU, memory, disk I/O) +- QuestDB logs from the `log/` directory +- Custom metrics from the Prometheus endpoint + +--- + +## Enterprise on GCP + +QuestDB Enterprise adds production features for GCP: + +- **GCS replication** - Continuous backup for durability +- **Cold storage** - Move old partitions to GCS, query on-demand +- **High availability** - Automatic failover across instances + +GCP offers two low-latency NFS services that can act as a replication transport +via the `fs::` prefix, as an alternative to GCS: + +- **Google Filestore** - a managed NFS service. The `fs::` transport over NFS + provides sub-200ms replication lag with + [aggressive tuning](/docs/high-availability/tuning/), compared to ~1s+ with + the GCS object store transport. +- **[NetApp Volumes](https://cloud.google.com/netapp/volumes/docs/discover/overview)** - + a managed NFS service backed by NetApp ONTAP. The QuestDB configuration is + identical to Filestore. + +To use Filestore or NetApp Volumes for replication: + +1. Create the instance in the same region as your QuestDB VMs +2. Mount the NFS share on both primary and replica nodes +3. Configure the `fs::` transport in `server.conf`: + +```ini +replication.object.store=fs::root=/mnt/questdb-repl/final;atomic_write_dir=/mnt/questdb-repl/scratch; ``` + +Use the [backup](/docs/operations/backup/) feature to manage WAL file retention +on the NFS mount. On GKE, expose the share as a `PersistentVolume` with +`ReadWriteMany` access mode using the +[Filestore CSI driver](https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/filestore-csi-driver) +so both primary and replica pods can mount it simultaneously. + +:::note +Filestore Zonal and Basic SSD tiers may require a +[quota increase](https://cloud.google.com/docs/quotas/view-manage) before use, +and NetApp Volumes requires enabling the `netapp.googleapis.com` API. +::: + +For GCS replication, create a bucket for the database, then follow the +[Enterprise Quick Start](/docs/getting-started/enterprise-quick-start/) to +create a connection string and configure QuestDB. diff --git a/static/images/guides/google-cloud-platform/create-vm-docker.webp b/static/images/guides/google-cloud-platform/create-vm-docker.webp deleted file mode 100644 index c630f2d2a..000000000 Binary files a/static/images/guides/google-cloud-platform/create-vm-docker.webp and /dev/null differ diff --git a/static/images/guides/google-cloud-platform/instance-available.webp b/static/images/guides/google-cloud-platform/instance-available.webp deleted file mode 100644 index e5f766784..000000000 Binary files a/static/images/guides/google-cloud-platform/instance-available.webp and /dev/null differ