QNAP HA + Incus Cluster — Failover Tuning Runbook#

Scope: menjaga VM di cluster Incus (trim-computes-shr-incus-01..04) tetap hidup saat node QNAP active melakukan failover ke passive node. Storage backend: QNAP iSCSI LUN → multipath → clustered LVM (lvmcluster + lvmlockd/sanlock). Status: rev.5 — angka failover masih asumsi, wajib diukur (§7). Blocker terbuka di §10 (dukungan model NAS, single path, boot-from-SAN).

Perubahan di rev.5

• §5.3 Langkah 1 — koreksi: Environment= butuh tanda kutip; tanpa itu angka 30 dibuang dan lvmlockd gagal start (requires an argument). Terverifikasi di incus-01.
• §5.3 — --sanlock-timeout | -o <seconds> dikonfirmasi ada di biner terpasang
• §5.3 Langkah 2 — prasyarat baru: jangan start lvmlockd selagi iSCSI flapping

Perubahan di rev.4

• §5.3 Langkah 0–1 — pakai hook $OPTIONS di unit lvmlockd, bukan override ExecStart; plus jebakan systemctl edit yang membatalkan file secara senyap
• §5.3 Langkah 2 — ada 3 lockspace aktif, bukan 2; tambah vgchange -an sebelum lock-stop
• §5.3 Langkah 3 — verifikasi 4 lapis; lapis “proses” hijau tidak menjamin “lockspace” hijau
• §6 — baris sanlock diperbarui

Perubahan di rev.3

• §5.5 + §6 + §9 — sintaks incus config set diperbaiki ke format key=value
• §9 — catatan EVACUATED persist melewati reboot; incus cluster restore wajib, plus langkah kalau restore gagal karena lockspace belum naik

Perubahan di rev.2

• §5.2 — config final + jebakan override no_path_retry per-LUN
• §5.2.1 — temuan baru: hanya satu path per LUN, multipath belum redundan
• §5.3 — koreksi: global/sanlock_io_timeout di lvm.conf tidak valid, diganti drop-in lvmlockd --sanlock-timeout
• §5.3.1 — kenapa perubahan sanlock tidak boleh rolling
• §9 — checklist dipecah jadi Fase 2A (rolling) dan 2B (serentak)

1. Ringkasan Eksekutif#

QNAP High Availability Manager memberi HA di layer storage, bukan di layer VM. Kalau QNAP active mati:

Tanpa tuning, kegagalan yang paling mungkin terjadi bukan VM yang error, tapi host Incus di-reset oleh watchdog sanlock pada detik ke-80 — jauh sebelum QNAP selesai failover. Efeknya seluruh VM di node itu mati, bukan cuma yang I/O-nya nyangkut.

2. Arsitektur QNAP HA (dari FAQ QNAP)#

Referensi: https://www.qnap.com/en/how-to/faq/article/how-do-i-create-a-high-availability-cluster

• Model: active/passive, dua NAS terpisah (bukan dual-controller seri ES).
• Cluster connection: static IP di kedua NAS, satu subnet, disarankan satu switch.
• Heartbeat connection: kabel langsung antar NAS (tanpa perangkat di tengah), DHCP IP, MTU fixed 1500.
• Access point: klien mengakses cluster hostname + cluster IP, bukan IP node. Saat failover, passive mengambil alih cluster IP → target iSCSI muncul di alamat yang sama.

Konsekuensi arsitektural yang penting untuk kita#

Karena ini HA berbasis replikasi antar dua chassis (bukan shared backplane), failover-nya bukan sub-detik. Ada jendela di mana LUN hilang total dari host Incus. Semua tuning di dokumen ini pada dasarnya adalah: membuat setiap lapisan lebih sabar daripada jendela itu.

3. Requirements & Limitasi (pre-flight)#

Requirements hardware/OS#

• Dua NAS model identik, seri x74 ke atas
• QuTS hero h5.3.0+, versi OS sama di kedua unit
• Kapasitas RAM total sama
• Disk kapasitas identik di slot yang sama di kedua unit
• Hostname tiap NAS unik
• High Availability Manager versi sama di kedua unit
• Semua storage pool & shared folder dalam kondisi healthy

Fitur yang HARUS dibongkar sebelum create cluster#

Peringatan#

Seluruh data di passive node dihapus permanen saat cluster dibuat. Butuh unit kedua yang benar-benar kembar → biaya praktis 2×.

Cek terhadap environment kita#

• SSD cache / pool SSD baru (pool-qnap-ssd-01) — verifikasi kompatibel dengan HA mode sebelum commit. Konfigurasi cache sering jadi blocker.
• Snapshot policy di pool existing — pastikan tidak ada yang immutable.
• Cek App Compatibility List QNAP untuk app yang aktif di NAS.

4. Timeout Chain — prinsip dasar#

Ini kerangka yang menentukan semua angka. Urutannya tidak boleh tertukar.

deteksi path down            15s    ← satu-satunya yang PENDEK
      <  failover QNAP nyata     ~120s   (ASUMSI — ukur di §7)
      <  sanlock renewal fail     240s
      <  multipath berhenti antre queue / 240s
      <  sanlock host_dead        300s
      <  Incus healing            360s

Kenapa deteksi path harus cepat#

Kalau iSCSI menahan command 120 detik di layer SCSI, dm-multipath tidak pernah dapat sinyal “path down” dan tidak bisa switch path. Untuk kegagalan yang bukan NAS-mati-total (satu NIC putus, satu uplink switch mati), switch path itu justru yang menyelamatkan.

Pola yang benar: path gagal cepat, antrian ditahan di layer dm.

5. Konfigurasi per Layer#

5.1 iSCSI — fail cepat#

# /etc/iscsi/iscsid.conf
node.session.timeo.replacement_timeout = 15

File ini hanya berlaku untuk session baru. Untuk session yang sudah jalan:

# lihat target aktif
iscsiadm -m node

# update nilai tersimpan
iscsiadm -m node -T <target-iqn> -o update \
  -n node.session.timeo.replacement_timeout -v 15

# re-login agar nilai baru dipakai
iscsiadm -m node -T <target-iqn> --logout
iscsiadm -m node -T <target-iqn> --login

Awas: logout/login memutus I/O sesaat. Lakukan per node, VM sudah dievakuasi lebih dulu. Jangan serentak.

Verifikasi nilai yang benar-benar aktif di session:

iscsiadm -m session -P 2 | grep -i 'Recovery Timeout'

5.2 multipath — tahan antrian#

Config final yang dipakai:

# /etc/multipath.conf
defaults {
    user_friendly_names yes
    find_multipaths     strict
    polling_interval    5
    no_path_retry       queue
}
multipaths {
    multipath {
        wwid  36e843b63464323338303532343065333
        alias qnap-hdd-01
    }
    multipath {
        wwid  36e843b66463303865633330383139353
        alias qnap-ssd-01
    }
}

Jebakan yang sempat kejadian: section multipaths{} meng-override defaults{}. Draft awal punya no_path_retry fail di entry qnap-hdd-01, sehingga LUN HDD — yang menampung mayoritas VM — fail-fast sementara LUN SSD queue. Jangan set no_path_retry per-LUN; biarkan keduanya inherit dari defaults.

fail sebenarnya rekomendasi standar untuk clustered LVM (fail cepat → fencing bersih). Yang bikin kasus kita beda: storage-nya tidak hilang permanen, QNAP active/passive pasti balik. Fail-fast cocok untuk kegagalan final, bukan yang transien & terprediksi.

Kenapa queue dan bukan angka: pada active/passive NAS HA, storage-nya pasti balik — bukan hilang permanen. queue = antre tanpa batas → VM freeze sebentar lalu lanjut, tidak pernah menerima I/O error.

Trade-off: kalau ternyata kedua NAS mati, host tidak bisa reboot bersih. Escape hatch manual:

dmsetup message <mpath-name> 0 fail_if_no_path

Alternatif batas keras kalau tidak nyaman dengan queue tanpa batas:

no_path_retry 48        # 48 × polling_interval 5s = 240s

Failure mode-nya lebih jelek: di detik ke-241 dia melempar I/O error diam-diam, bukan hang yang kelihatan di monitoring.

Apply & verifikasi:

systemctl reload multipathd
multipathd show config | grep -A3 'multipath {'   # pastikan tak ada 'no_path_retry' tersisa
multipath -ll
cat /etc/multipath/wwids                          # 'strict' butuh WWID terdaftar

Yang dicari di multipath -ll: features='1 queue_if_no_path' di setiap LUN. Kalau tidak muncul, queue belum aktif.

5.2.1 TEMUAN — hanya ada satu path per LUN#

Status per pengecekan terakhir:

qnap-hdd-01 (36e843b6...) dm-6  QNAP,iSCSI Storage
size=32T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  `- 13:0:0:1 sdb 8:16 active ready running     ← satu-satunya path

Satu session iSCSI ke 172.16.145.69, satu path per LUN. Artinya multipath jalan tapi tidak me-multipath apa pun — dia cuma jadi pembungkus agar queue_if_no_path bisa dipakai.

NIC, kabel, port switch, dan uplink semuanya masih single point of failure. Satu link putus → tidak ada path pengganti → seluruh VM freeze sampai link balik.

Prioritas anggaran: path redundancy jauh lebih murah daripada NAS kedua, dan menutup mode kegagalan yang lebih sering terjadi. Kalau harus memilih: multipath dulu, HA belakangan. Tidak masuk akal membayar 2× NAS demi menghapus SPOF sementara satu kabel masih bisa menjatuhkan semuanya.

Yang perlu ditambah: session kedua lewat NIC berbeda ke portal IP berbeda di QNAP, idealnya melewati switch berbeda.

Setelah path kedua ada, cek ulang multipath -ll: yang benar dua priority group terpisah (ALUA active/optimized + non-optimized), bukan dua path dalam satu group. hwhandler='1 alua' sudah terdeteksi otomatis, jadi path_grouping_policy belum perlu diset eksplisit.

Catatan: dengan satu path, replacement_timeout = 15 tetap benar dan tetap perlu — tapi perannya berubah. Bukan lagi memicu switch path (tidak ada tujuan switch), melainkan agar path cepat ditandai down dan iscsid segera memulai siklus relogin, yang justru penting saat cluster IP berpindah ke passive node.

5.3 sanlock / lvmlockd — paling kritis#

KOREKSI (draft sebelumnya salah). global/sanlock_io_timeout bukan setting lvm.conf yang valid — LVM menolaknya dengan Configuration setting "global/sanlock_io_timeout" unknown. Kalau baris itu terlanjur ada, hapus dulu:

sed -i '/sanlock_io_timeout/d' /etc/lvm/lvm.conf
lvmconfig --validate

Knob yang benar adalah opsi daemon lvmlockd, bukan file konfigurasi. Jangan pula edit /etc/sanlock/sanlock.conf — lvmlockd meneruskan nilainya sendiri saat membuat lockspace, jadi setting di situ akan ditimpa.

Opsi yang dipakai: -o | --sanlock-timeout SECONDS (override the default sanlock I/O timeout). Referensi: man 8 lvmlockd.

Semua nilai sanlock adalah turunan dari io_timeout:

Default 10 detik berarti host di-reset watchdog (wdmd) di detik ke-80 — sebelum QNAP selesai failover. Ini penyebab utama kejadian “semua VM di node itu mati”.

Langkah 0 — konfirmasi opsi & cara passing-nya#

Manpage bisa berbeda dari versi yang benar-benar ter-install. Cek dulu:

lvmlockd --help 2>&1 | grep -i timeout       # harus muncul -o|--sanlock-timeout
systemctl cat lvmlockd | grep ExecStart
systemctl cat lvmlockd | grep -i environment

Kalau --sanlock-timeout tidak ada, stop — pendekatannya harus dicari ulang.

Pada unit yang terpasang di cluster ini, ExecStart sudah menyediakan hook resmi:

ExecStart=/usr/sbin/lvmlockd --foreground $OPTIONS

Variabel $OPTIONS default-nya kosong (ps cuma menampilkan --foreground). Karena hook ini ada, jangan override ExecStart — cukup isi environment-nya. Lebih bersih dan tidak bentrok saat paket lvm2-lockd di-upgrade.

Langkah 1 — isi $OPTIONS#

Cara A — environment file (dipakai di cluster ini). Path-nya ikut hasil grep -i environment di Langkah 0; prefix - pada EnvironmentFile=-/... berarti opsional, jadi file-nya sering belum ada dan tinggal dibuat:

echo 'OPTIONS="--sanlock-timeout 30"' > /etc/default/lvmlockd   # sesuaikan path
systemctl daemon-reload

Cara B — drop-in, hanya kalau unit tidak punya EnvironmentFile sama sekali:

mkdir -p /etc/systemd/system/lvmlockd.service.d
cat > /etc/systemd/system/lvmlockd.service.d/override.conf <<'EOF'
[Service]
Environment="OPTIONS=--sanlock-timeout 30"
EOF
systemctl daemon-reload
systemctl show lvmlockd -p Environment

Tanda kutip WAJIB. Environment= memecah argumen berdasarkan spasi, jadi tanpa kutip baris itu dibaca sebagai dua assignment: OPTIONS=--sanlock-timeout dan 30. Yang kedua dibuang, dan gejalanya muncul dua tahap:

systemd[1]: override.conf:2: Invalid environment assignment, ignoring: 30
lvmlockd[9379]: option '--sanlock-timeout' requires an argument

Hasil systemctl show lvmlockd -p Environment harus utuh berikut angkanya: Environment=OPTIONS=--sanlock-timeout 30

Bentuk pendek Environment="OPTIONS=-o 30" juga valid dan lebih tahan salah-pecah.

Jebakan systemctl edit: di systemd versi baru, template editor isinya komentar semua. Kalau disimpan tanpa menambah baris non-komentar, systemd membatalkan penulisan dengan pesan new contents are empty, not writing file. — dan file override tidak pernah dibuat. Pakai cat > ... <<'EOF' seperti di atas supaya kegagalan ini tidak terjadi diam-diam.

Kalau terpaksa override ExecStart penuh, baris ExecStart= kosong itu wajib lebih dulu untuk menghapus nilai lama — tanpa itu systemd menambah entry kedua dan unit gagal start.

Verifikasi sebelum lanjut:

systemctl show lvmlockd -p ExecStart --value
ps -eo args | grep '[l]vmlockd'      # baru berubah setelah restart di Langkah 2

Langkah 2 — apply, wajib serentak semua node#

PRASYARAT — storage harus stabil dulu. Jangan start lvmlockd atau --lock-start selagi iSCSI flapping. Kalau lockspace ter-join di atas koneksi putus-nyambung, sanlock gagal renew lease berulang dan wdmd bisa me-reset host — persis kegagalan yang justru sedang kita cegah.

Gate sebelum lanjut:

journalctl -k --since '-5min' | grep -c 'conn error'   # harus 0
multipath -ll                                          # prio=50, TANPA 'i/o pending'

Amati stabil beberapa menit, baru systemctl start lvmlockd.

io_timeout melekat di host_id lease saat lockspace di-join, bukan saat daemon start. Jadi restart daemon saja tidak cukup — lockspace harus di-rejoin. Rolling tidak boleh, lihat §5.3.1.

Ada 3 lockspace aktif di cluster ini (sanlock status -D menampilkan tiga io_timeout=10). Semuanya harus di-stop, bukan cuma dua VG yang jelas namanya. Identifikasi dulu:

sanlock client status
vgs -o vg_name,vg_lock_type,vg_lock_args

Untuk cluster staging, cold restart jauh lebih bersih daripada --lock-stop bergiliran:

# 1. $OPTIONS sudah diisi di KEEMPAT node
# 2. Stop semua VM
incus stop --all
# 3. Reboot keempat node bersamaan
# 4. Verifikasi setelah naik (lihat Langkah 3)

Alternatif tanpa reboot (kalau VM tidak bisa semua di-stop):

# di SEMUA node, hampir bersamaan
# LV harus non-aktif dulu — VM di node ini sudah stop/dievakuasi
vgchange -an vg-qnap-hdd-01 vg-qnap-ssd-01

vgchange --lock-stop vg-qnap-hdd-01
vgchange --lock-stop vg-qnap-ssd-01
# + lockspace ketiga sesuai hasil `sanlock client status`

systemctl daemon-reload && systemctl restart lvmlockd
ps -eo args | grep '[l]vmlockd'     # HARUS sudah ada --sanlock-timeout 30

vgchange --lock-start vg-qnap-hdd-01
vgchange --lock-start vg-qnap-ssd-01

vgchange --lock-stop gagal kalau masih ada LV aktif yang memegang lock — itu perilaku benar, bukan error. Kalau mentok, cek lvs -o lv_name,lv_active dulu.

Langkah 3 — verifikasi nilai benar-benar terpakai#

Empat lapis, urut dari luar ke dalam. Lapis 1–2 hijau tidak menjamin lapis 3 hijau.

# 1. konfigurasi terbaca systemd
systemctl show lvmlockd -p ExecStart --value

# 2. proses jalan dengan flag
ps -eo args | grep '[l]vmlockd'

# 3. LOCKSPACE memakai nilai baru  ← yang menentukan
sanlock status -D | grep -i io_timeout
sanlock client status
vgs -o vg_name,vg_lock_type,vg_lock_args

Target: semua baris io_timeout jadi 30. Jumlahnya harus sama dengan jumlah lockspace aktif — di cluster ini ada 3.

Abaikan write_init_io_timeout=60. Itu parameter berbeda, hanya dipakai saat inisialisasi lease, tidak ada hubungannya dengan renewal.

# 4. konsisten di keempat node — bukan opsional, lihat §5.3.1
for n in 01 02 03 04; do
  echo "=== incus-$n ==="
  ssh trim-computes-shr-incus-$n \
    "ps -eo args | grep '[l]vmlockd'; sanlock status -D | grep -i io_timeout"
done

Kalau lapis 2 hijau tapi lapis 3 masih 10: ada lockspace yang belum di-rejoin. Penyebab paling sering adalah urutan terbalik — --lock-start dijalankan sebelum systemctl restart lvmlockd. Ulangi Langkah 2 dengan urutan yang benar.

5.3.1 Kenapa tidak boleh rolling#

Selama ada node dengan io_timeout berbeda dalam satu lockspace, ada jendela split-brain:

Saat incus-01 kehilangan storage: incus-02 menganggapnya sudah mati di detik 140 dan boleh mengambil alih LV lock, sementara incus-01 masih merasa sah memegang lease sampai detik 300. Itu 160 detik di mana dua host bisa menulis ke LV yang sama.

Yang rusak adalah metadata VG, bukan sekadar VM yang crash. Tidak sepadan walaupun staging.

Trade-off yang harus disadari: host yang benar-benar mati sekarang butuh 300 detik sebelum lease-nya boleh diambil node lain. Recovery lebih lambat — itu harga dari toleransi 120 detik.

5.4 Guest Windows#

Linux guest dengan virtio aman: dia hang, bukan error, selama host mengantre. Windows punya timeout sendiri dan bisa BSOD 0x7A KERNEL_DATA_INPAGE_ERROR.

HKLM\SYSTEM\CurrentControlSet\Services\Disk\TimeOutValue = 300   (DWORD, decimal)

Bake ke template trim-vm-shr-tx-template-win2022, jangan per-instance. Masukkan ke langkah sysprep/install.ps1 yang sudah ada.

# jalankan sebelum sysprep
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Disk" `
  -Name "TimeOutValue" -Value 300 -PropertyType DWORD -Force

5.5 Incus cluster healing#

incus config set cluster.healing_threshold=360
incus config get cluster.healing_threshold

Sintaks: pakai key=value. Format lama <key> <value> (dipisah spasi) masih jalan tapi sudah deprecated dan mengeluarkan warning di Incus versi baru.

Ini bukan untuk mempercepat recovery, tapi untuk mencegah Incus panik saat outage transien.

Kalau healing menyala sebelum host_dead (300s) terlewat, node tujuan tidak akan bisa mengambil LV lock dan start-nya gagal — menghasilkan churn tanpa hasil. Karena itu 360s > 300s, bukan sebaliknya.

6. Tabel Ringkasan Nilai#

Semua nilai di atas diturunkan dari asumsi failover 120s. Kalau hasil pengukuran §7 berbeda, hitung ulang seluruh tabel.

7. Mengukur Failover Sebenarnya#

Angka 120s adalah asumsi. Ukur dulu — semua nilai di dokumen ini bergantung padanya.

Probe#

# di salah satu node, ke LUN TEST — JANGAN yang produksi
fio --name=probe --filename=/dev/mapper/<lun-test> \
    --rw=write --bs=4k --direct=1 --time_based --runtime=600 \
    --log_avg_msec=1000 --write_lat_log=probe

Cari gap terpanjang di probe_lat.*.log → itu failover window.

Dua skenario, hasilnya beda jauh#

Aturan pengambilan angka#

1. Jalankan skenario unplanned minimal 3×
2. Ambil nilai terburuk
3. Tambah margin 50%
4. Baru kunci sanlock_io_timeout dan turunan lainnya

8. Blocker yang Harus Dicek Duluan#

Node Incus tidak boleh boot dari SAN.

Waktu pemilihan lvmcluster ada kendala diskless node. Kalau / dan /var/lib/incus berada di QNAP (bukan disk lokal), semua tuning di dokumen ini percuma — host-nya sendiri yang mati saat storage hilang, dan tidak ada yang tersisa untuk mengantre I/O.

# verifikasi di tiap node
findmnt -no SOURCE /
findmnt -no SOURCE /var/lib/incus
lsblk -o NAME,TYPE,MOUNTPOINT,TRAN

Yang diharapkan: TRAN = sata/nvme, bukan iscsi.

9. Checklist Eksekusi#

Fase 0 — validasi

• Node Incus tidak boot dari SAN (§8)
• Pre-flight requirement QNAP terpenuhi (§3)
• SSD cache / pool-qnap-ssd-01 dikonfirmasi kompatibel HA mode

Fase 1 — ukur

• LUN test dibuat (terpisah dari produksi)
• Unplanned failover diukur 3× (§7)
• Nilai final tabel §6 dihitung ulang dari hasil ukur

Fase 2A — rolling per node (aman dicicil, mayoritas VM staging)

Item di bawah ini murni lokal ke host — tidak ada state bersama antar node:

• multipath.conf — edit, lalu reboot node
• iscsid.conf — edit, lalu reboot node (reboot sudah menggantikan iscsiadm --logout)
• cluster.healing_threshold — sekali saja, cluster-wide, tanpa restart
• Registry timeout di template win2022

Urutannya, satu node dituntaskan dulu sebelum lanjut:

# set mode evacuate ke 'stop' — hindari live-migrate
for i in $(incus list -c n --format csv location=incus-0X); do
  incus config set "$i" cluster.evacuate=stop
done

incus cluster evacuate incus-0X
systemctl reboot
incus cluster list          # tunggu ONLINE & healthy
incus cluster restore incus-0X

Jangan lewatkan incus cluster restore. State EVACUATED tersimpan di database cluster dan persist melewati reboot — reboot tidak mengembalikannya. Selama node masih evacuated, semua start instance ditolak dengan:

Instance start failed
Cluster member is evacuated

Yang menyesatkan: kolom STATUS di incus cluster list bisa menunjukkan ONLINE sementara kolom STATE masih EVACUATED. Dua kolom berbeda — yang dibaca STATE.

restore sekaligus menyalakan kembali VM yang tadi di-stop, jadi tidak perlu start manual.

Kalau restore gagal atau menggantung — kemungkinan besar lockspace belum naik setelah reboot:

sanlock status
vgs -o vg_name,vg_lock_type,vg_lock_args

# kalau VG tidak muncul di sanlock status
vgchange --lock-start vg-qnap-hdd-01
vgchange --lock-start vg-qnap-ssd-01

incus cluster restore incus-0X    # ulangi

Kenapa cluster.evacuate stop: pernah ada bug LV rounding (66.01g vs 66GiB) saat move antar node. Kalau evacuate mencoba live-migrate, dia bisa mentok di situ. Mode stop cuma mematikan VM, tidak memindahkan.

Fase 2B — serentak semua node (tidak boleh rolling, ~10 menit)

• Drop-in lvmlockd --sanlock-timeout 30 dipasang di keempat node dulu
• incus stop --all
• Reboot keempat node bersamaan
• Verifikasi sanlock status -D | grep io_timeout = 30 di semua node

Alasan tidak boleh rolling: §5.3.1 (jendela split-brain 160 detik → korupsi metadata VG).

Fase 3 — validasi

• Ulangi unplanned failover dengan VM produksi-mirip jalan
• VM Linux: hang lalu lanjut, tidak remount read-only
• VM Windows: tidak BSOD
• Tidak ada host yang ter-reset watchdog (journalctl -u wdmd)

10. Catatan Terbuka#

Blocker

• Model NAS didukung HA? Target IQN menunjukkan TS-h1886XU-RP R2. Syarat QNAP menyebut seri x74 ke atas — belum bisa dipastikan h1886XU R2 masuk daftar itu. Konfirmasi ke QNAP sebelum menghitung apa pun; kalau tidak didukung, seluruh rencana HA berubah bentuk.
• Single path (§5.2.1) — jadikan prasyarat sebelum Fase 2A, bukan pekerjaan susulan.
• Node Incus tidak boot dari SAN (§8) — belum diverifikasi.

Belum dipastikan

• lvmlockd --sanlock-timeout ada di biner terpasang — terkonfirmasi, di-pass lewat $OPTIONS. Nilai lockspace masih perlu diverifikasi di keempat node (§5.3 Langkah 3)
• Angka failover masih asumsi 120s — belum diukur, semua nilai §6 bergantung padanya
• Kompatibilitas SSD cache QNAP dengan HA mode
• Perilaku failover saat rebuild/resync passive node sedang berjalan

Prinsip

• QNAP HA bukan pengganti backup — replikasi ikut mereplikasi korupsi dan ransomware.
• Urutan investasi yang masuk akal: path redundancy → ukur failover → baru HA.