DEV Community

Cover image for Learning Distributed Object Storage with Incus and PGSTY SILO
hardyweb
hardyweb

Posted on

Learning Distributed Object Storage with Incus and PGSTY SILO

#architecture #backend #cloud #linux

Aku buat R&D homelab untuk memahami konsep distributed storage, khususnya bagaimana object storage seperti MinIO/SILO menggunakan beberapa storage drives dan nodes untuk menyediakan redundancy dan survive daripada kegagalan storage.

Untuk lab ini, aku gunakan:

  • Windows + WSL2
  • Debian
  • Incus
  • Debian VM
  • PGSTY SILO
  • MinIO Client (mc)
  • ext4 filesystem

Tujuan utama bukan untuk membina production storage cluster, tetapi untuk memahami apa yang berlaku apabila storage drive atau node gagal.

PGSTY SILO ialah fork daripada MinIO yang mengekalkan compatibility dengan S3 dan MinIO tooling. (github.com)

1. Apa yang aku cuba faham?

Istilah seperti:

  • distributed storage
  • object storage
  • erasure coding
  • quorum
  • storage node
  • storage drive
  • drive failure
  • node failure
  • healing

nampak macam konsep yang berasingan.

Jadi aku nak buat experiment yang mudah:

Kalau satu storage drive mati, adakah object masih boleh dibaca?

Kemudian:

Apa pula yang berlaku kalau satu server/node mati?

Daripada sini kita boleh faham konsep distributed storage melalui experiment sebenar.

2. Kenapa guna Incus?

Aku tidak mempunyai beberapa physical server untuk dijadikan storage nodes.

Jadi Incus digunakan untuk simulate beberapa server.

Topology:

WSL2
 │
 └── Incus
      │
      ├── debian-vm
      │    ├── sdb → storage drive 1
      │    └── sdc → storage drive 2
      │
      └── debian-vm2
           ├── sdb → storage drive 3
           └── sdc → storage drive 4
Enter fullscreen mode Exit fullscreen mode

VM bukan distributed storage itu sendiri.

VM hanya digunakan sebagai simulation of storage nodes.

Distributed storage berlaku pada layer SILO.

3. Kenapa guna VM, bukan container?

Pada awalnya aku cuba menggunakan Incus container. Incus Container menggunakan root block sebagai virtual hdd. cara lain adalah menggunakan real block device seperti:

/dev/sdb
/dev/sdc
Enter fullscreen mode Exit fullscreen mode

ia diperlukan agar dapat simulate storage drive sebenar.

Incus custom block volumes boleh digunakan pada VM dan disk devices VM menyokong hotplug. (linuxcontainers.org)

Jadi architecture akhirnya:

Incus
 │
 ├── debian-vm
 │    ├── /dev/sdb
 │    └── /dev/sdc
 │
 └── debian-vm2
      ├── /dev/sdb
      └── /dev/sdc
Enter fullscreen mode Exit fullscreen mode

4. Membina storage drives

Untuk setiap VM, aku create dua Incus block volumes.

Contohnya:

incus storage volume create default silo1 size=5GiB --type block
incus storage volume create default silo1-extra size=5GiB --type block
Enter fullscreen mode Exit fullscreen mode

Kemudian attach kepada VM:

incus config device add debian-vm silo-disk \
    disk pool=default source=silo1

incus config device add debian-vm silo-disk2 \
    disk pool=default source=silo1-extra
Enter fullscreen mode Exit fullscreen mode

Hasilnya:

debian-vm

sda  30G   OS
sdb   5G   storage
sdc   5G   storage
Enter fullscreen mode Exit fullscreen mode

Perkara yang sama dibuat pada debian-vm2.

Akhirnya:

2 nodes × 2 drives = 4 storage endpoints
Enter fullscreen mode Exit fullscreen mode

5. Format dan mount storage

Setiap block device diformat sebagai ext4:

sudo mkfs.ext4 /dev/sdb
sudo mkfs.ext4 /dev/sdc
Enter fullscreen mode Exit fullscreen mode

Kemudian:

sudo mkdir -p /mnt/export1
sudo mkdir -p /mnt/export2

sudo mount /dev/sdb /mnt/export1
sudo mount /dev/sdc /mnt/export2
Enter fullscreen mode Exit fullscreen mode

Jadi setiap node mempunyai:

/mnt/export1
/mnt/export2
Enter fullscreen mode Exit fullscreen mode

yang masing-masing berada pada storage drive berbeza.

Untuk lab ini, mount dilakukan secara manual. fstab belum digunakan kerana fokusnya adalah experiment storage failure.

6. Network antara nodes

SILO memerlukan nodes berkomunikasi antara satu sama lain.

Incus menyediakan network dan DNS antara instances.

Contohnya:

ping debian-vm2
Enter fullscreen mode Exit fullscreen mode

berjaya dari debian-vm.

Jadi SILO boleh menggunakan hostname:

debian-vm
debian-vm2
Enter fullscreen mode Exit fullscreen mode

sebagai storage endpoints.

7. Setup SILO authentication

Sebelum menjalankan SILO, kita set credential untuk S3/API.

Untuk lab, kita gunakan environment variables:

export SILO_ROOT_USER="siloadmin"
export SILO_ROOT_PASSWORD="change-this-password"
Enter fullscreen mode Exit fullscreen mode

Jangan gunakan password contoh ini untuk production.

Password perlu cukup kuat dan sebaiknya disimpan melalui secret-management mechanism apabila deployment sudah menjadi production.

Kemudian jalankan SILO dengan storage endpoints:

silo server \
    http://debian-vm/mnt/export1 \
    http://debian-vm/mnt/export2 \
    http://debian-vm2/mnt/export1 \
    http://debian-vm2/mnt/export2
Enter fullscreen mode Exit fullscreen mode

Nama environment variable dan authentication mechanism perlu disesuaikan dengan versi SILO yang digunakan. Semak silo server --help atau dokumentasi versi yang dipasang sebelum production deployment.

8. Connect menggunakan mc

Selepas SILO berjalan, mc digunakan sebagai S3 client.

Contohnya:

mc alias set silo \
    http://debian-vm:9000 \
    siloadmin \
    change-this-password
Enter fullscreen mode Exit fullscreen mode

Kemudian check:

mc alias list
Enter fullscreen mode Exit fullscreen mode

dan:

mc admin info silo
Enter fullscreen mode Exit fullscreen mode

mc sekarang boleh digunakan untuk:

  • create bucket
  • upload object
  • download object
  • inspect server
  • inspect storage status

Contoh:

mc mb silo/test
Enter fullscreen mode Exit fullscreen mode

Kemudian upload:

echo "distributed storage test" > test.txt

mc cp test.txt silo/test/
Enter fullscreen mode Exit fullscreen mode

Dan verify:

mc ls silo/test/
Enter fullscreen mode Exit fullscreen mode

9. Membina distributed SILO pool

SILO dijalankan menggunakan keempat-empat storage endpoints:

silo server \
    http://debian-vm/mnt/export1 \
    http://debian-vm/mnt/export2 \
    http://debian-vm2/mnt/export1 \
    http://debian-vm2/mnt/export2
Enter fullscreen mode Exit fullscreen mode

Sekarang SILO tidak lagi melihat storage sebagai empat directory yang tidak berkaitan.

Ia melihatnya sebagai satu distributed storage pool.

Topology:

                    SILO
                     │
              Distributed Pool
                     │
        ┌────────────┴────────────┐
        │                         │
   debian-vm                 debian-vm2
        │                         │
    ┌───┴───┐                 ┌───┴───┐
    │       │                 │       │
   sdb     sdc               sdb     sdc
    │       │                 │       │
   D1      D2                D3      D4
Enter fullscreen mode Exit fullscreen mode

Dalam experiment ini, mc admin info menunjukkan:

Pool: 1

Drives: 2/2 OK
Enter fullscreen mode Exit fullscreen mode

dan:

Pool | Drives Usage | Erasure stripe size | Erasure sets
1st  | 0.0%         | 4                   | 1
Enter fullscreen mode Exit fullscreen mode

Jadi empat storage endpoints tersebut membentuk:

1 pool
1 erasure set
4 drives
Enter fullscreen mode Exit fullscreen mode

10. Distributed storage bukan sekadar "copy file"

Salah satu perkara penting yang aku mula faham:

4 drives ≠ semestinya 4 copies
Enter fullscreen mode Exit fullscreen mode

Distributed object storage menggunakan mekanisme seperti erasure coding untuk menyediakan redundancy.

Secara konsep:

             Object
                │
          Erasure Coding
                │
       ┌────────┼────────┐
       │        │        │
      D1       D2       D3 ... Dn
Enter fullscreen mode Exit fullscreen mode

Data object dipecahkan kepada beberapa shards dan sebahagian shard digunakan sebagai parity.

SILO menggunakan storage class dengan konfigurasi parity seperti EC:n. Konfigurasi sebenar perlu disemak daripada cluster configuration dan mc admin info, bukan diandaikan hanya berdasarkan jumlah drive. (github.com)

11. Drive failure experiment

Ini experiment yang paling menarik.

Aku mahu simulate:

Satu physical drive rosak tetapi server masih hidup.

Kita tidak shutdown VM.

Contohnya:

debian-vm

sdb → /mnt/export1
sdc → /mnt/export2
              ↑
           FAILURE
Enter fullscreen mode Exit fullscreen mode

Pertama, filesystem di-unmount:

sudo umount /mnt/export2
Enter fullscreen mode Exit fullscreen mode

Tetapi:

umount sahaja bukan bermaksud drive rosak.

Ia cuma unmount filesystem.

Untuk simulate drive benar-benar hilang daripada VM, kita remove Incus disk device:

incus config device remove debian-vm silo-disk2
Enter fullscreen mode Exit fullscreen mode

Kemudian:

incus exec debian-vm -- lsblk
Enter fullscreen mode Exit fullscreen mode

/dev/sdc sudah tidak kelihatan.

Sekarang simulation menjadi:

debian-vm
 │
 ├── sdb  ONLINE
 │
 └── sdc  OFFLINE
Enter fullscreen mode Exit fullscreen mode

tetapi:

debian-vm = RUNNING
Enter fullscreen mode Exit fullscreen mode

Jadi kita sedang menguji drive failure, bukan node failure.

12. Apa yang berlaku kepada object?

Sebelum melakukan failure test, upload satu object:

mc cp test.txt silo/test/
Enter fullscreen mode Exit fullscreen mode

Kemudian pastikan object boleh dibaca:

mc cat silo/test/test.txt
Enter fullscreen mode Exit fullscreen mode

Selepas satu drive ditarik keluar, cuba lagi:

mc cat silo/test/test.txt
Enter fullscreen mode Exit fullscreen mode

Inilah experiment sebenar yang kita mahu lihat.

Jika cluster masih mempunyai quorum yang diperlukan untuk operasi tersebut, object boleh terus diakses walaupun satu storage endpoint offline.

Ini bergantung kepada erasure-set dan storage-class configuration.

13. Memasukkan drive kembali

Selepas experiment selesai, drive boleh attach kembali.

incus config device add debian-vm silo-disk2 \
    disk pool=default source=silo1-extra
Enter fullscreen mode Exit fullscreen mode

Check:

incus exec debian-vm -- lsblk
Enter fullscreen mode Exit fullscreen mode

Kita mahu lihat:

sda
sdb
sdc
Enter fullscreen mode Exit fullscreen mode

Kemudian mount kembali:

incus exec debian-vm -- sudo mount /dev/sdc /mnt/export2
Enter fullscreen mode Exit fullscreen mode

Verify:

incus exec debian-vm -- df -hT /mnt/export2
Enter fullscreen mode Exit fullscreen mode

Kemudian:

mc admin info silo
Enter fullscreen mode Exit fullscreen mode

untuk melihat status drive dan cluster.

Jangan jalankan mkfs pada drive yang sama.

Kita mahu preserve filesystem dan storage data yang sedia ada.

14. Drive failure vs Node failure

Ini satu lagi konsep penting.

Drive failure 

debian-vm
 │
 ├── drive 1  ONLINE
 └── drive 2  OFFLINE
Enter fullscreen mode Exit fullscreen mode

Server masih hidup.

SILO masih boleh berkomunikasi dengan node tersebut.

Node failure

Sekarang kita shutdown keseluruhan VM:

debian-vm          OFFLINE
 │
 ├── drive 1
 └── drive 2

debian-vm2         ONLINE
 ├── drive 3
 └── drive 4
Enter fullscreen mode Exit fullscreen mode

Dalam keadaan ini dua storage endpoints hilang serentak.

Jadi:

1 drive failure ≠ 1 node failure
Enter fullscreen mode Exit fullscreen mode

Ini adalah sebab penting kenapa distributed storage perlu dilihat berdasarkan failure domain, bukan sekadar jumlah drives.

15. Current lab topology

Topology semasa:

                     WSL2
                       │
                     Incus
                       │
          ┌────────────┴────────────┐
          │                         │
     debian-vm                 debian-vm2
          │                         │
     ┌────┴────┐               ┌────┴────┐
     │         │               │         │
    sdb       sdc             sdb       sdc
     │         │               │         │
   5 GiB     5 GiB            5 GiB     5 GiB
     │         │               │         │
 export1    export2          export1    export2
     └─────────┴───────────────┴─────────┘
                       │
                      SILO
                       │
                    Pool 1
                 1 erasure set
                    4 drives
Enter fullscreen mode Exit fullscreen mode

Authentication:

S3/API user:
siloadmin

Password:
set melalui SILO environment variable
Enter fullscreen mode Exit fullscreen mode

Client:

mc
 │
 └── silo alias
       │
       └── http://debian-vm:9000
Enter fullscreen mode Exit fullscreen mode

16. Apa yang aku belajar

Lab ini bermula dengan soalan:

"Macam mana distributed storage sebenarnya bekerja?"

Sekarang konsepnya lebih jelas:

Node
 │
 ├── Drive
 ├── Drive
 │
 └── SILO
       │
       ├── Erasure Set
       ├── Erasure Coding
       ├── Quorum
       ├── Failure Detection
       └── Recovery / Healing
Enter fullscreen mode Exit fullscreen mode

Incus pula digunakan untuk simulate infrastructure:

Incus
  ↓
Virtual Machines
  ↓
Block Devices
  ↓
Filesystems
  ↓
SILO
  ↓
Distributed Object Storage
  ↓
S3 Client (mc)
Enter fullscreen mode Exit fullscreen mode

17. Next experiment

Selepas berjaya memahami single-drive failure, experiment seterusnya:

Experiment 1 — Node failure

Shutdown:

debian-vm
Enter fullscreen mode Exit fullscreen mode

Kemudian lihat behaviour cluster.

Experiment 2 — Node recovery

Start semula:

debian-vm
Enter fullscreen mode Exit fullscreen mode

Kemudian observe status drives.

Experiment 3 — Healing

Perhatikan sama ada cluster melakukan recovery/healing selepas storage kembali.

Experiment 4 — Load balancer

Selepas memahami storage layer, baru tambah Nginx sebagai client-facing endpoint:

                 Client
                    │
                  Nginx
                    │
          ┌─────────┴─────────┐
          │                   │
      debian-vm           debian-vm2
          │                   │
       D1   D2              D3   D4
          \                   /
           \────── SILO ─────/
Enter fullscreen mode Exit fullscreen mode

Ini memisahkan dua konsep:

SILO
→ distributed storage / data resilience

Nginx
→ client traffic / endpoint failover
Enter fullscreen mode Exit fullscreen mode

Conclusion

Apa yang menarik tentang lab ini ialah kita tidak hanya menjalankan MinIO/SILO.

Kita cuba merosakkan storage secara sengaja.

Mula dengan:

4 drives
2 nodes
1 erasure set
Enter fullscreen mode Exit fullscreen mode

Kemudian:

pull 1 drive
        ↓
observe
        ↓
attach kembali
        ↓
observe recovery
Enter fullscreen mode Exit fullscreen mode

Daripada experiment ini, konsep distributed storage menjadi lebih mudah difahami kerana kita boleh melihat sendiri hubungan antara:

Node
+
Drive
+
Erasure Coding
+
Erasure Set
+
Quorum
+
Failure
+
Recovery
Enter fullscreen mode Exit fullscreen mode

Seterusnya kita akan cuba matikan satu node, bukan sekadar satu drive.

Itulah beza antara:

"satu disk rosak"

dan

"satu server storage hilang."

Top comments (0)