Regional Filestore & High Availability

Tại sao quan trọng trong production

Zonal Filestore instance là single point of failure: zone incident → instance không accessible → tất cả service phụ thuộc bị downtime. Với shared filesystem, downtime này ảnh hưởng hàng chục service đồng thời, không phải chỉ một service.

Regional tier giải quyết vấn đề này bằng cách replicate data across zones. Nhưng "regional HA" không phải zero-cost: có trade-off về performance (write latency tăng do synchronous replication), cost (cao hơn zonal), và compatibility (không support Multishares, không support resize linh hoạt như Zonal).

Hiểu đúng cơ chế bên dưới giúp bạn quyết định: workload nào cần Regional, workload nào có thể dùng Zonal với strategy recovery khác.

Internal model — Replication mechanism

Synchronous cross-zone replication

Regional Filestore instance replicate data synchronously across 3 zones trong cùng một region. Điều này khác hoàn toàn với asynchronous replication (dùng cho cross-region DR).

Cơ chế synchronous replication nghĩa là:

Client write() call
       │
       ▼
NFS Server (primary zone)
       │
       ├─────────────────── replicate ──────────────────┐
       │                                                  │
       ▼                                                  ▼
  Zone A (primary)                    Zone B (replica)  Zone C (replica)
  Write acknowledged to storage       Write persisted   Write persisted
       │                                    │                │
       └──────────── All 3 zones ACK ───────┘────────────────┘
                           │
                    Write ACK to client

Client chỉ nhận ACK sau khi tất cả 3 zones đã persist write. Điều này đảm bảo không mất data khi một zone fail ngay sau khi write — nhưng đồng thời làm write latency cao hơn zonal (thêm network round-trip giữa các zones).

Write latency của Regional tier thường cao hơn Zonal ~1–5ms trong worst case (tùy zones có gần nhau hay không). Với workload write-intensive và latency-sensitive (database, high-frequency logging), đây là trade-off đáng cân nhắc.

Transparent failover khi zone failure

Khi một zone fail, Regional Filestore thực hiện transparent failover:

Primary NFS server detect zone unreachable
Một trong hai replica zones được promote lên làm primary
NFS service tiếp tục từ zone mới, với cùng IP address
NFS clients đang mount không cần thực hiện bất kỳ action nào

Cụm từ "transparent" ở đây là quan trọng: client không cần remount, không cần cập nhật IP. Từ góc nhìn của client, đây chỉ là một khoảng thời gian latency spike (trong khi failover xảy ra), sau đó IO tiếp tục bình thường.

Đây là khác biệt cốt lõi so với Zonal tier: zone fail → zonal instance offline hoàn toàn.

Thời gian failover: Không có SLA công bố cụ thể, nhưng trong thực tế failover xảy ra trong vòng vài phút.

Giới hạn trong quá trình zone failure

Mặc dù data access tiếp tục, một số operations bị giới hạn khi một zone đang fail:

Không thể tạo Regional hay Enterprise instances mới trong region đó trong thời gian zone failure
Filestore API và Console operations có thể bị unavailable hoặc chậm trong vài giờ
Performance có thể giảm tạm thời trong quá trình rebalancing sau khi zone phục hồi

Điều này ảnh hưởng đến auto-scaling scenarios: nếu workload cần tạo Filestore instance mới trong khi zone đang có incident, operation sẽ fail. Phải account cho điều này trong HA design.

IP address stability

Regional instance có một IP không đổi qua các failover events. Đây là thiết kế có chủ ý: thay vì để client tự detect và reconnect (như DNS-based failover), Filestore giữ IP ổn định.

Điều này làm đơn giản hóa client configuration: NFS mount với IP cố định hoạt động xuyên suốt các zone failures mà không cần thay đổi.

Replication cho Disaster Recovery (Cross-region)

Regional tier HA chỉ bảo vệ chống lại zone failure. Nếu toàn bộ region có sự cố (hiếm nhưng có thể xảy ra), instance Regional không accessible.

Để bảo vệ chống lại regional failure, Filestore cung cấp instance replication — asynchronous cross-region replication:

┌─────────────────────────────────────────┐
│  Region A (Primary)                     │
│  Regional Filestore Instance            │
│  ├── Zone 1 (sync replica)             │
│  ├── Zone 2 (sync replica)             │
│  └── Zone 3 (sync replica)             │
└───────────────┬─────────────────────────┘
                │ Async replication
                │ (best effort, không guarantee RPO)
                ▼
┌─────────────────────────────────────────┐
│  Region B (Standby / DR)                │
│  Regional Filestore Instance (Standby)  │
│  - Read-only trong trạng thái standby  │
│  - Có thể promote lên Primary           │
└─────────────────────────────────────────┘

Asynchronous nghĩa là: data được ghi vào primary region không đảm bảo đã được replicate sang standby region ngay lập tức. Khi primary region fail, có thể có một khoảng thời gian data bị mất (RPO > 0).

RPO thực tế phụ thuộc vào replication lag, thường là vài giây đến vài phút trong điều kiện bình thường.

Promote standby instance

Khi primary region có sự cố và cần failover sang DR region:

bash

# Promote standby instance lên primary
gcloud filestore instances promote-replica STANDBY_INSTANCE \
  --zone=DR_ZONE

Sau khi promote:

Standby instance trở thành read-write
Instance có IP mới ở DR region
Tất cả clients phải update mount point sang IP mới

Đây là điểm khác với trong-region failover: cross-region failover không transparent — cần cập nhật IP/DNS.

Instance replication setup

bash

# Tạo replication configuration
gcloud filestore instances update PRIMARY_INSTANCE \
  --zone=PRIMARY_ZONE \
  --replication=replication-mode=ACTIVE_STANDBY,\
    standby-instance=projects/PROJECT/locations/DR_ZONE/instances/STANDBY_INSTANCE

Performance trade-offs: Regional vs Zonal

Write latency

Synchronous replication thêm latency vào mọi write operation. Mức tăng phụ thuộc vào khoảng cách vật lý giữa các zones trong region:

Cùng metro area zones (ví dụ: us-central1-a, -b, -c): thường < 2ms thêm
Nếu zones xa hơn: có thể lên 5ms

Với workload write latency-sensitive (database buffer writes, real-time logging), đây là con số đáng kể. Ngược lại với workload read-heavy (serving static files, shared ML dataset đọc nhiều), overhead này gần như không đáng kể.

Write IOPS so sánh

Regional tier có write IOPS thấp hơn Zonal tier ở cùng capacity vì overhead của synchronous replication:

Capacity	Zonal Write IOPS (4,000 base/TiB)	Regional Write IOPS (4,000 base/TiB)
1 TiB	1,200	4,000
5 TiB	6,000	20,000
10 TiB	12,000	40,000

Lưu ý: bảng trên là ví dụ minh họa, số thực tế phụ thuộc vào configuration.

Write IOPS của Regional tier thường bị giới hạn ~30% so với read IOPS (tương tự Zonal), nhưng synchronous replication thêm overhead khiến effective write performance giảm.

Cost

Regional tier có chi phí cao hơn Zonal khoảng 20–40% cho cùng capacity, do:

Infrastructure cho 3 zones thay vì 1
Replication bandwidth giữa zones
Cao hơn SLA commitment

Khi nào dùng Regional, khi nào dùng Zonal

Dùng Regional khi:

Production workload không thể chịu zone-level downtime
SLA yêu cầu >= 99.9% availability
Data là critical và không thể tái tạo
Ứng dụng không có cơ chế retry/failover ở application level

Dùng Zonal khi:

High performance là yêu cầu tối thượng (HPC, ML training)
Workload có thể retry hoặc tái khởi động sau zone failure
Data có thể tái tạo (temp files, cache, intermediate computation results)
Cost optimization là yếu tố quan trọng

Hybrid approach: Dùng Regional tier cho data critical (config files, state, shared database files) và Zonal tier cho scratch/working data (ML training checkpoints, temporary outputs). Tách biệt mounting points cho hai loại data này.

Anti-pattern: Dùng Zonal Filestore cho stateful production services

Sai lầm phổ biến: Deploy Filestore Zonal instance cho shared filesystem của production web application cluster, không có backup strategy.

Kịch bản thất bại:

Zone chứa Filestore instance có sự cố (xác suất nhỏ nhưng không phải 0)
Tất cả web servers không thể access shared filesystem
Application trả về lỗi hoặc hang (tùy hard/soft mount option)
Incident kéo dài vài giờ cho đến khi zone phục hồi
Không có DR playbook → team không biết làm gì

Tại sao sai về mặt cơ chế: Zonal instance không có redundancy ở storage level. Không phải "có thể bị ảnh hưởng" mà là "chắc chắn bị ảnh hưởng" nếu zone fail.

Fix: Regional tier cho production shared filesystem. Nếu cost là vấn đề, giảm capacity thay vì downgrade tier.

GCP-native implementation guidance

Tạo Regional instance

bash

gcloud filestore instances create prod-shared-fs \
  --zone=us-central1     \          # dùng region, không phải zone cụ thể
  --tier=REGIONAL \
  --file-share=name="vol1",capacity=2TiB \
  --network=name="projects/PROJECT/global/networks/production-vpc" \
  --connect-mode=PRIVATE_SERVICE_ACCESS

Lưu ý: với Regional tier, --zone nhận region value (ví dụ: us-central1), không phải zone (ví dụ: us-central1-a). Google chọn zones tự động.

Mount với hard mount option (khuyến nghị cho Regional)

bash

# /etc/fstab entry
10.x.x.x:/vol1  /mnt/filestore  nfs  defaults,hard,intr,nfsvers=3,_netdev  0  0

hard mount: NFS client sẽ retry vô hạn nếu server không responsive. Với Regional tier và transparent failover, đây là hành vi đúng — instance sẽ phục hồi sau failover, application chỉ cần chờ (thay vì fail).

intr: Cho phép interrupt hang NFS operation bằng signal (Ctrl+C, kill). An toàn hơn hard mà không có intr.

Monitoring health của Regional instance

bash

# Alert khi instance state != READY
gcloud monitoring policies create \
  --notification-channels=CHANNEL_ID \
  --conditions='[{
    "displayName": "Filestore Instance Not Ready",
    "conditionThreshold": {
      "filter": "resource.type=\"filestore_instance\" AND metric.type=\"file.googleapis.com/nfs/server/used_bytes\"",
      "comparison": "COMPARISON_GT",
      "thresholdValue": 0
    }
  }]'

Thực tế hơn: monitor từ client side — đo NFS operation latency từ client VM. Đây là ground truth về performance thực sự của mount:

bash

# Benchmark NFS latency từ client
fio --name=nfs-latency-test \
    --filename=/mnt/filestore/test.bin \
    --rw=randread \
    --bs=4k \
    --numjobs=1 \
    --iodepth=1 \
    --time_based \
    --runtime=30 \
    --lat_percentiles=1 \
    --output-format=json

Regional Filestore & High Availability ​

Tại sao quan trọng trong production ​

Internal model — Replication mechanism ​

Synchronous cross-zone replication ​

Transparent failover khi zone failure ​

Giới hạn trong quá trình zone failure ​

IP address stability ​

Replication cho Disaster Recovery (Cross-region) ​

Promote standby instance ​

Instance replication setup ​

Performance trade-offs: Regional vs Zonal ​

Write latency ​

Write IOPS so sánh ​

Cost ​

Khi nào dùng Regional, khi nào dùng Zonal ​

Anti-pattern: Dùng Zonal Filestore cho stateful production services ​

GCP-native implementation guidance ​

Tạo Regional instance ​

Mount với hard mount option (khuyến nghị cho Regional) ​

Monitoring health của Regional instance ​

References ​

Regional Filestore & High Availability

Tại sao quan trọng trong production

Internal model — Replication mechanism

Synchronous cross-zone replication

Transparent failover khi zone failure

Giới hạn trong quá trình zone failure

IP address stability

Replication cho Disaster Recovery (Cross-region)

Promote standby instance

Instance replication setup

Performance trade-offs: Regional vs Zonal

Write latency

Write IOPS so sánh

Cost

Khi nào dùng Regional, khi nào dùng Zonal

Anti-pattern: Dùng Zonal Filestore cho stateful production services

GCP-native implementation guidance

Tạo Regional instance

Mount với hard mount option (khuyến nghị cho Regional)

Monitoring health của Regional instance

References