Belajar OpenClaw - Disaster Recovery & Failover

#Pendahuluan

Episode 17 menutup dengan multi-cluster dan hybrid environments: bagaimana policy dikelola melintasi banyak cluster, gateway di tiap pintu masuk, dan pertimbangan jaringan lintas cloud. Episode 18 ini masuk lebih dalam ke sisi keandalan: disaster recovery & failover. Alasan utamanya sederhana — policy adalah tulang punggung keamanan jaringan. Kalau konfigurasi policy hilang, kendali atas lalu lintas hilang. Kalau control plane mati tanpa pengganti, tidak ada policy baru yang bisa diterapkan.

Roadmap episode 18: mengenal RPO dan RTO sebagai sasaran desain, menyusun backup dan restore konfigurasi OpenClaw, merancang strategi failover control plane, menangani network partition, lalu menguji rencana recovery sebelum benar-benar dibutuhkan.

#Backup dan Restore Konfigurasi OpenClaw

Apa yang harus dibackup? Bayangkan seluruh state yang membuat jaringan kalian berperilaku seperti sekarang. Itu mencakup semua resource policy (ServicePolicy, NetworkPolicy, MeshConfig, ServiceIdentity), config map global, secret yang menopang CA dan sertifikat mTLS, sampai definisi CRD itu sendiri. Tanpa secret CA, identitas service yang sudah disebar tidak bisa diverifikasi lagi setelah restore.

Menyusun rutinitas. Backup sekali tidak cukup — jadwalkan berkala dengan Velero atau CronJob, simpan beberapa versi, dan tandai setiap artefak dengan checksum agar restore tidak memakai file korup. Simpan salinan di lokasi terpisah dari cluster utama, bahkan di region berbeda, supaya bencana yang merusak cluster tidak ikut merusak cadangannya. Perhatikan juga retention: simpan cukup lama untuk kebutuhan compliance, tapi tidak selamanya.

kubectl get crd -l openclaw.io/active -o yaml > openclaw-crds.yaml
kubectl get servicepolicies,meshconfigs,serviceidentities,auditconfigs --all-namespaces -o yaml > openclaw-policies.yaml
kubectl get secrets -n openclaw -o yaml > openclaw-secrets.yaml
openclawctl backup create --name pre-release --destination s3://openclaw-backups

kubectl apply -f openclaw-crds.yaml
kubectl apply -f openclaw-secrets.yaml
kubectl apply -f openclaw-policies.yaml
openclawctl policy validate --cluster restored-cluster

Urutan restore penting: pastikan CRD terpasang lebih dulu, baru secret, lalu resource policy. Selalu uji restore dari cadangan terbaru, bukan hanya dari yang lama — cadangan yang tidak pernah direstore hanyalah ilusi keamanan.

#Strategi Failover Control Plane

Control plane OpenClaw harus berjalan lebih dari satu replika. Saat satu replika mati, replika lain mengambil alih lewat leader election: satu replika menjadi leader yang menulis, sisanya melayani pembacaan dan siap menggantikan. Agar keputusan tidak membelah, digunakan konsep quorum — mayoritas replika harus setuju. Dengan tiga replika, satu node hilang masih aman; dengan dua, kehilangan satu membuat quorum hilang dan tulis terhenti.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: openclaw-controlplane
  namespace: openclaw
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: openclaw-controlplane

Bukan cuma jumlah replikanya, tapi di mana mereka duduk. Dengan topologySpreadConstraints di atas, tiga replika dipaksa tersebar ke zone berbeda, sehingga kegagalan satu availability zone tidak mematikan seluruh control plane. Ini dasar arsitektur HA yang pernah kalian sentuh di episode 15.

Pilih strategi failover sesuai RTO kalian. Active-active berarti semua replika di semua cluster melayani lalu lintas — failover cepat, tapi kompleksitasnya tinggi. Active-standby berarti cluster standby ikut memantau dan tinggal dipromosikan saat utama runtuh — lebih sederhana, tapi RTO lebih lama karena butuh tindakan manual. Kalian bahkan bisa menaruh standby di cloud provider berbeda, sesuai semangat multi-cluster di episode 17.

openclawctl controlplane status
openclawctl controlplane failover --to standby-cluster

#Menangani Network Partitions

Network partition terjadi ketika cluster terbelah dua karena jaringan antar node putus. Data plane yang sudah menerima policy tetap menegakkannya dari cache — ini perilaku last-known-good: enforce terus berjalan, perubahan tidak bisa diterapkan sampai quorum kembali. Desain ini sengaja dibuat supaya jaringan tidak runtuh total saat control plane tidak terjangkau, tapi konsekuensinya harus dipahami: perubahan policy selama partisi tertahan.

Bahaya terbesar partisi adalah split-brain — dua sisi cluster masing-masing menganggap dirinya leader. Pencegahannya adalah lease dan quorum yang tadi dibahas: replica yang kehilangan kontak dengan mayoritas tidak boleh menerima tulis, bahkan jika ia mengira dirinya paling sehat.

apiVersion: openclaw.io/v1
kind: ControlPlaneConfig
metadata:
  name: default
spec:
  ha:
    quorum: majority
    leaseDuration: 15s
    renewDeadline: 10s
    retryPeriod: 2s

Saat partisi berakhir, jangan langsung percaya state salah satu sisi. Verifikasi dengan membandingkan policy di kedua sisi terhadap sumber kebenaran GitOps: openclawctl policy diff --from cluster-a --to cluster-b. Kalau ada perbedaan, biarkan Git yang menang — sisi yang melenceng di-reconcile ulang, bukan di-merge manual.

#Menguji Rencana Recovery

Rencana recovery yang tidak pernah diuji adalah rencana yang tidak ada. Jadikan pengujian acara terjadwal, bukan tanggapan darurat. Setiap kali menguji, catat berapa lama recovery benar-benar terjadi — itulah RTO asli kalian, bukan angka di dokumen.

kubectl delete pod -l app=openclaw-controlplane -n openclaw
watch -n 2 openclawctl controlplane status
kubectl rollout status deployment/openclaw-controlplane -n openclaw --timeout=60s

Daftar skenario minimum yang layak diuji: restore penuh ke cluster kosong, kematian leader mendadak, partisi antar zone, dan data plane yang terputus dari control plane. Untuk tiap skenario, tulis hasilnya ke runbook — apa yang berjalan cepat, apa yang gagal, apa yang harus diperbaiki. Recovery adalah otot: makin sering dilatih, makin cepat merespons saat dibutuhkan.

#Penutup

Pada episode 18, kalian memahami bahwa keandalan OpenClaw dibangun di atas tiga pilar: backup yang teruji, failover yang dirancang, dan partisi yang dipahami. Backup tanpa restore bukan apa-apa, failover tanpa quorum berisiko split-brain, dan partisi tanpa keputusan fail-open atau fail-closed bisa melukai di dua arah.

Inti yang harus dibawa pulang:

• Backup harus diuji dengan restore nyata, disimpan di luar cluster, dan diverifikasi checksum-nya.
• Control plane butuh replika ganjil yang tersebar antar zone agar quorum dan failover bekerja.
• Pilih antara active-active dan active-standby berdasarkan RTO yang bisa diterima bisnis.
• Saat partisi, andalkan last-known-good dan sumber kebenaran Git untuk rekonsiliasi, bukan merge manual.
• Jadwalkan game day recovery dan ukur RTO sungguhan, bukan yang ditulis di dokumen.

Di episode 19, kalian memasuki Fase 6 — CI/CD & GitOps for Policies. Kalian akan membangun pipeline untuk perubahan policy, memvalidasi dan men-deploy secara otomatis, serta mempromosikan policy antar branch dan lingkungan dengan disiplin GitOps. Sampai jumpa!