พื้นที่จัดเก็บข้อมูล Longhorn สำหรับคลัสเตอร์ k3s การผลิต: การขยาย PVC แบบไดนามิก การจำลองแบบ และการกู้คืนความเสียหาย

Storage เป็นปัญหาที่ยากที่สุดใน Kubernetes การประมวลผลไม่มีสถานะและสามารถทดแทนได้ — ปิดพ็อดแล้วกำหนดเวลาใหม่ ระบบเครือข่ายมีปลั๊กอิน CNI และโครงข่ายบริการที่ครบถ้วน แต่การจัดเก็บ? พื้นที่จัดเก็บข้อมูลคือพื้นที่ของรัฐ โดยที่ข้อมูลยังคงอยู่ระหว่างการรีสตาร์ท ซึ่งการกำหนดค่าผิดพลาดเพียงครั้งเดียวอาจทำให้ข้อมูลสูญหายอย่างถาวร สำหรับคลัสเตอร์ k3s ที่ใช้งานปริมาณงานจริง เช่น ฐานข้อมูล คิวข้อความ สถานะแอปพลิเคชัน คุณต้องมีโซลูชันพื้นที่จัดเก็บข้อมูลที่กระจาย ยืดหยุ่น ขยายได้ และใช้งานได้ ลองฮอร์นคือคำตอบนั้น

Longhorn เป็นระบบจัดเก็บบล็อกแบบกระจายน้ำหนักเบา เชื่อถือได้ และใช้งานง่ายสำหรับ Kubernetes เดิมพัฒนาโดย Rancher Labs (ปัจจุบันเป็นส่วนหนึ่งของ SUSE) เป็นโครงการบ่มเพาะ CNCF ที่สร้างขึ้นโดยมีจุดประสงค์สำหรับคลัสเตอร์ที่ความเรียบง่ายมีความสำคัญ แต่ความน่าเชื่อถือในการผลิตไม่สามารถต่อรองได้ ต่างจาก Ceph ซึ่งต้องการโหนดพื้นที่จัดเก็บข้อมูลเฉพาะและความเชี่ยวชาญเชิงลึก หรือตัวจัดสรรเส้นทางเฉพาะที่ซึ่งให้ความซ้ำซ้อนเป็นศูนย์ Longhorn ตอบสนองความสมดุลที่แน่นอนที่คลัสเตอร์ k3s ต้องการ: การจำลองแบบกระจายข้ามโหนด การขยายวอลุ่มแบบไดนามิก การสำรองข้อมูลแบบรวมไปยังพื้นที่จัดเก็บออบเจ็กต์บนคลาวด์ สแน็ปช็อต และการกู้คืนระบบ - ทั้งหมดนี้ได้รับการจัดการผ่าน UI ที่ปลอดภัยและ CRD แบบเนทีฟ Kubernetes

คู่มือนี้ครอบคลุมทุกสิ่งที่คุณต้องการในการปรับใช้ Longhorn บน k3s สำหรับการผลิต: สถาปัตยกรรมภายใน, วิธีการติดตั้ง, การกำหนดค่า StorageClass, การขยาย PVC แบบไดนามิก, กลยุทธ์การจำลองแบบ, การสำรองข้อมูลและการกู้คืนระบบ, การเข้ารหัสโวลุ่ม, การปรับแต่งประสิทธิภาพสำหรับฐานข้อมูล, การตรวจสอบ และการแก้ไขปัญหา ทุกคำแนะนำมาพร้อมกับการกำหนดค่าที่ผ่านการทดสอบแล้วซึ่งคุณสามารถปรับให้เข้ากับสภาพแวดล้อมของคุณได้

การทำความเข้าใจสถาปัตยกรรมของ Longhorn ถือเป็นสิ่งสำคัญสำหรับการตัดสินใจโดยใช้ข้อมูลรอบด้านเกี่ยวกับการจำลองแบบ ประสิทธิภาพ และการจัดการความล้มเหลว Longhorn ประกอบด้วยองค์ประกอบหลัก 3 ส่วนซึ่งทำงานร่วมกันเพื่อให้พื้นที่จัดเก็บแบบบล็อกแบบกระจายที่ด้านบนของดิสก์ในเครื่องที่แนบกับโหนด Kubernetes ของคุณ

Longhorn Managerทำงานเป็น DaemonSet บนทุกโหนดในคลัสเตอร์ เป็นระนาบควบคุมของ Longhorn — จัดการการโทร API, ควบคุมการสร้างวอลุ่ม, จัดการการจำลอง, ประสานสแน็ปช็อตและการสำรองข้อมูล และสื่อสารกับเซิร์ฟเวอร์ Kubernetes API เพื่อจัดการวงจรการใช้งาน PersistentVolume และ PersistentVolumeClaim เมื่อคุณสร้าง PVC ที่อ้างอิงถึง Longhorn StorageClass นั้น Longhorn Manager จะได้รับคำขอผ่านไดรเวอร์ CSI จัดเตรียมวอลุ่ม และกำหนดเวลาการจำลองในโหนดที่มีอยู่

Longhorn Engineเป็นตัวควบคุมพื้นที่จัดเก็บข้อมูลต่อวอลุ่มที่ใช้งานเป็นกระบวนการพื้นที่ผู้ใช้ Linux (อิงตามทางแยกของ Rancher Longhorn Engine) แต่ละวอลลุมได้รับกระบวนการกลไกเฉพาะของตัวเองที่ทำงานบนโหนดที่แนบวอลลุม กลไกจัดการการอ่านและเขียน I/O ทั้งหมดสำหรับโวลุ่มนั้น โดยจำลองการเขียนแบบซิงโครนัสไปยังเรพลิกาที่กำหนดค่าทั้งหมดก่อนที่จะยอมรับการเขียนไปยังแอปพลิเคชัน สถาปัตยกรรมต่อวอลุ่มนี้หมายความว่าการชนหรือการค้างในกลไกของวอลลุมหนึ่งจะไม่ส่งผลกระทบต่อวอลลุมอื่น ซึ่งเป็นคุณสมบัติการแยกที่สำคัญสำหรับการผลิต

Replicasเป็นกระบวนการจัดเก็บข้อมูลจริง แต่ละเรพลิกาจะจัดเก็บสำเนาที่สมบูรณ์ของข้อมูลวอลุ่มบนดิสก์ภายในเครื่องของโหนดที่รัน ตามค่าเริ่มต้น Longhorn จะสร้างแบบจำลองสามรายการสำหรับแต่ละวอลุ่ม โดยกระจายไปตามโหนดที่แตกต่างกัน (และโซนที่แตกต่างกัน) การจำลองใช้กลไกการคัดลอกเมื่อเขียนสำหรับสแน็ปช็อต ทำให้การสร้างสแน็ปช็อตทำได้ทันทีโดยไม่คำนึงถึงขนาดวอลุ่ม

สถาปัตยกรรมนี้มีคุณสมบัติหลักหลายประการสำหรับการใช้งานจริงความทนทานต่อข้อผิดพลาด:มีการจำลองสามรายการในสามโหนด ไดรฟ์ข้อมูลจะคงอยู่ในกรณีที่โหนดล้มเหลวพร้อมกันสองครั้ง การแยก:แต่ละวอลุ่มมีกระบวนการเอ็นจิ้นของตัวเอง ดังนั้นข้อผิดพลาดหรือการค้างในโวลุ่มเดียวจึงไม่สามารถเรียงซ้อนได้ ความเรียบง่ายของ:ไม่มีโหนดพื้นที่จัดเก็บข้อมูลเฉพาะ ไม่มีคลัสเตอร์ Ceph หรือ GlusterFS แยกกัน — Longhorn ทำงานบนโหนดผู้ปฏิบัติงานเดียวกันกับพ็อดแอปพลิเคชันของคุณ โดยใช้ดิสก์ภายในเครื่องKubernetes-native:ทุกอย่างได้รับการจัดการผ่าน CRDs, kubectl และอินเทอร์เฟซ Kubernetes CSI

กำลังติดตั้ง Longhorn บน k3s

Longhorn สามารถติดตั้งบน k3s ได้ 3 วิธี: แผนภูมิ Helm (แนะนำสำหรับการผลิต), Rancher App Marketplace (หากคุณให้ Rancher จัดการคลัสเตอร์ของคุณ) หรือใช้ kubectl โดยตรง ก่อนการติดตั้ง ตรวจสอบให้แน่ใจว่าโหนดของคุณตรงตามข้อกำหนดเบื้องต้น

สิ่งที่จำเป็นต้องมี

# Verify prerequisites on each node
# Required: open-iscsi (for iSCSI support)
sudo apt-get install -y open-iscsi
sudo systemctl enable iscsid
sudo systemctl start iscsid

# Required: NFSv4 client (for backup/restore to NFS targets)
sudo apt-get install -y nfs-common

# Recommended: check all prerequisites with Longhorn's environment check script
curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/v1.7.2/scripts/environment_check.sh | bash

# Verify kernel modules
lsmod | grep -E "iscsi_tcp|dm_crypt|nfs"

# On k3s specifically, local-path-provisioner is the default.
# We will make Longhorn the default StorageClass after installation.

ผ่าน Helm (แนะนำ)

# Add the Longhorn Helm repository
helm repo add longhorn https://charts.longhorn.io
helm repo update

# Create the namespace
kubectl create namespace longhorn-system

# Install with production values
helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --version 1.7.2 \
  --values longhorn-values.yaml

นี่คือvalues.yamlระดับการผลิตพร้อมค่าเริ่มต้นที่ปรับแล้ว:

# longhorn-values.yaml — Production configuration
persistence:
  defaultClass: true
  defaultFsType: ext4
  defaultClassReplicaCount: 3
  defaultDataLocality: best-effort
  reclaimPolicy: Retain

defaultSettings:
  backupTarget: s3://longhorn-backups@eu-west-1/
  backupTargetCredentialSecret: longhorn-backup-s3-secret
  createDefaultDiskLabeledNodes: true
  defaultDataPath: /var/lib/longhorn/
  defaultReplicaCount: 3
  defaultDataLocality: best-effort
  replicaSoftAntiAffinity: false
  replicaAutoBalance: best-effort
  storageOverProvisioningPercentage: 150
  storageMinimalAvailablePercentage: 15
  guaranteedInstanceManagerCPU: 12
  upgradeChecker: false
  autoSalvage: true
  autoDeletePodWhenVolumeDetachedUnexpectedly: true
  disableSchedulingOnCordonedNode: true
  replicaZoneSoftAntiAffinity: true
  volumeAttachmentRecoveryPolicy: wait
  snapshotDataIntegrity: fast-check
  snapshotDataIntegrityCronjob: "0 7 * * *"
  concurrentAutomaticEngineUpgradePerNodeLimit: 1

longhornManager:
  priorityClass: system-cluster-critical
  tolerations:
    - key: "node-role.kubernetes.io/storage"
      operator: "Exists"
      effect: "NoSchedule"

longhornDriver:
  priorityClass: system-cluster-critical
  tolerations:
    - key: "node-role.kubernetes.io/storage"
      operator: "Exists"
      effect: "NoSchedule"

longhornUI:
  replicas: 2

ingress:
  enabled: true
  ingressClassName: nginx
  host: longhorn.internal.example.com
  tls: true
  tlsSecret: longhorn-tls
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: longhorn-basic-auth
    nginx.ingress.kubernetes.io/auth-realm: "Longhorn UI"

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

ผ่าน Rancher App Marketplace

หาก Rancher จัดการคลัสเตอร์ k3s ของคุณ ให้ไปที่Apps & ตลาดซื้อขาย → แผนภูมิ → Longhornใน Rancher UI เลือกเนมสเปซเป้าหมายของคุณ (longhorn-system) กำหนดค่าผ่านอินเทอร์เฟซแบบฟอร์ม และคลิก ติดตั้ง Rancher จัดการการจัดการวงจรการใช้งาน Helm และการติดตามการอัปเกรดโดยอัตโนมัติ

ผ่าน kubectl

# Direct manifest installation
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.7.2/deploy/longhorn.yaml

# Verify all pods are running
kubectl -n longhorn-system get pods -w

หลังการติดตั้ง: กำหนดให้ Longhorn เป็นคลาสการจัดเก็บข้อมูลเริ่มต้น

# Remove default annotation from k3s local-path
kubectl patch storageclass local-path -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

# Verify Longhorn is now default
kubectl get storageclass
# NAME                 PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
# longhorn (default)   driver.longhorn.io   Retain          Immediate           true                   5m
# local-path           rancher.io/local-path Delete         WaitForFirstConsumer false                 30d

สำหรับการผลิต

Longhorn StorageClass เริ่มต้นใช้งานได้สำหรับการพัฒนา แต่ปริมาณงานการผลิตจำเป็นต้องมีการกำหนดค่าเฉพาะสำหรับกรณีการใช้งานที่แตกต่างกัน — ฐานข้อมูลต้องการการจำลองแบบสูงและอยู่ในพื้นที่เฉพาะของข้อมูล การประมวลผลชั่วคราวต้องการไดรฟ์ข้อมูลจำลองเดียวที่รวดเร็ว และไดรฟ์ข้อมูลที่ใช้ร่วมกันต้องการการรองรับ RWX

# StorageClass for database workloads — maximum durability
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-db
  annotations:
    storageclass.kubernetes.io/is-default-class: "false"
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Retain
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  fromBackup: ""
  fsType: ext4
  dataLocality: best-effort
  recurringJobSelector: '[{"name":"db-snapshot","isGroup":true},{"name":"db-backup","isGroup":true}]'
---
# StorageClass for general workloads — balanced
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-standard
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "2"
  staleReplicaTimeout: "2880"
  fsType: ext4
  dataLocality: best-effort
---
# StorageClass for temporary/cache workloads — performance
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-fast
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "1"
  staleReplicaTimeout: "2880"
  fsType: ext4
  dataLocality: strict-local
---
# StorageClass for RWX (ReadWriteMany) shared volumes
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-rwx
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Retain
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "3"
  nfsOptions: "vers=4.1,hard,timeo=50,retrans=3"
  staleReplicaTimeout: "2880"
  fsType: ext4

การขยาย PVC แบบไดนามิก

หนึ่งในคุณสมบัติการผลิตที่สำคัญที่สุดของ Longhorn คือส่วนขยาย PVC แบบไดนามิก — ความสามารถในการเพิ่มขนาดของไดรฟ์ข้อมูลถาวรโดยไม่ต้องหยุดทำงาน โดยไม่สูญเสียข้อมูล และไม่มีการแทรกแซงด้วยตนเอง นอกเหนือจากคำสั่ง kubectl เดียวหรือการเปลี่ยนแปลงรายการ นี่เป็นสิ่งสำคัญสำหรับฐานข้อมูลที่การเติบโตของข้อมูลไม่สามารถคาดเดาได้ และพื้นที่ดิสก์ไม่เพียงพอหมายถึงการหยุดทำงาน

Longhorn รองรับทั้งส่วนขยายออนไลน์(วอลุ่มจะติดอยู่และติดตั้งในขณะที่ขยาย) และส่วนขยายออฟไลน์(โวลุ่มจะถูกถอดออกก่อน) การขยายแบบออนไลน์เป็นแนวทางเริ่มต้นและที่แนะนำสำหรับการผลิต เนื่องจากจะช่วยหลีกเลี่ยงการหยุดทำงานของแอปพลิเคชัน

การเปิดใช้งานการขยายระดับเสียงใน StorageClass

ข้อกำหนดหลักสำหรับการขยาย PVC แบบไดนามิกคือ StorageClass ต้องมีallowVolumeExpansion: trueStorageClass เริ่มต้นของ Longhorn มีสิ่งนี้อยู่แล้ว แต่หากคุณมี StorageClasses แบบกำหนดเอง ให้ตรวจสอบว่าได้ตั้งค่าฟิลด์นี้แล้ว

# Verify your StorageClass supports expansion
kubectl get storageclass longhorn -o yaml | grep allowVolumeExpansion
# allowVolumeExpansion: true

# If not set, patch it
kubectl patch storageclass longhorn -p '{"allowVolumeExpansion": true}'

ทีละขั้นตอน: ขยาย PVC แบบไดนามิก

# 1. Check current PVC size
kubectl get pvc pg-data-postgresql-0 -n database
# NAME                    STATUS   VOLUME       CAPACITY   ACCESS MODES   STORAGECLASS   AGE
# pg-data-postgresql-0    Bound    pvc-abc123   50Gi       RWO            longhorn-db    30d

# 2. Check current usage inside the pod
kubectl exec -n database postgresql-0 -- df -h /var/lib/postgresql/data
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/longhorn   49G   42G  7.0G  86% /var/lib/postgresql/data

# 3. Expand the PVC (online — no downtime)
kubectl patch pvc pg-data-postgresql-0 -n database --type merge -p '{
  "spec": {
    "resources": {
      "requests": {
        "storage": "100Gi"
      }
    }
  }
}'

# 4. Watch the expansion progress
kubectl get pvc pg-data-postgresql-0 -n database -w
# Wait for CAPACITY to update from 50Gi to 100Gi

# 5. Verify the filesystem expanded inside the pod
kubectl exec -n database postgresql-0 -- df -h /var/lib/postgresql/data
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/longhorn   99G   42G   57G  43% /var/lib/postgresql/data

# 6. Verify via Longhorn volume status
kubectl -n longhorn-system get volumes.longhorn.io -o wide

การขยาย PVC อัตโนมัติพร้อมการแจ้งเตือน

ในการผลิต คุณไม่ควรรอจนกว่าดิสก์จะเต็ม 86% เพื่อขยายด้วยตนเอง ใช้การแจ้งเตือน Prometheus เพื่อกระตุ้นการขยายโดยอัตโนมัติ หรือแจ้งเตือนวิศวกรที่โทรติดต่อก่อนที่ความจุจะมีความสำคัญ

# PrometheusRule for PVC capacity alerts
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: pvc-capacity-alerts
  namespace: monitoring
spec:
  groups:
    - name: pvc-capacity
      rules:
        - alert: PVCCapacityWarning
          expr: |
            (kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes) > 0.80
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "PVC {{ $labels.persistentvolumeclaim }} at {{ $value | humanizePercentage }} capacity"
            runbook: "Expand the PVC using: kubectl patch pvc {{ $labels.persistentvolumeclaim }} -n {{ $labels.namespace }} --type merge -p '{\"spec\":{\"resources\":{\"requests\":{\"storage\":\"NEW_SIZE\"}}}}'"
        - alert: PVCCapacityCritical
          expr: |
            (kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes) > 0.90
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "CRITICAL: PVC {{ $labels.persistentvolumeclaim }} at {{ $value | humanizePercentage }}"
            description: "Immediate expansion required to prevent application failure"

การจำลองวอลุ่มและตำแหน่งข้อมูล

Longhorn จำลองข้อมูลโวลุ่มข้ามหลายโหนดเพื่อป้องกันความล้มเหลวของฮาร์ดแวร์ การตั้งค่าปัจจัยการจำลองและตำแหน่งข้อมูลจะควบคุมการแลกเปลี่ยนระหว่างความทนทาน ประสิทธิภาพ และประสิทธิภาพการจัดเก็บข้อมูล

ปัจจัยการจำลองกำหนดจำนวนสำเนาของข้อมูลที่มีอยู่ ค่าเริ่มต้นคือ 3 ซึ่งหมายความว่าการเขียนแต่ละครั้งจะถูกจัดเก็บไว้ในโหนดที่แตกต่างกันสามโหนด สำหรับฐานข้อมูลการใช้งานจริง 3 คือค่าที่แนะนำขั้นต่ำ คุณสามารถตั้งค่าเป็น 2 สำหรับปริมาณงานที่มีความสำคัญน้อยกว่าเพื่อประหยัดพื้นที่จัดเก็บข้อมูล หรือปล่อยไว้ที่ 1 สำหรับวอลุ่มชั่วคราว/แคช ซึ่งยอมรับการสูญหายของข้อมูลได้

ตำแหน่งข้อมูลควบคุมว่า Longhorn พยายามเก็บแบบจำลองไว้บนโหนดเดียวกันกับพ็อดที่ใช้ระดับเสียงหรือไม่ มีสามโหมด:

• ปิดใช้งาน— การจำลองจะถูกกำหนดเวลาตามพื้นที่ว่างและการป้องกันความสัมพันธ์เท่านั้น พ็อดอาจอ่านจากเรพลิกาบนโหนดระยะไกล โดยเพิ่มเวลาแฝงของเครือข่ายให้กับทุกการดำเนินการ I/O
• พยายามอย่างเต็มที่ — Longhorn พยายามวางแบบจำลองหนึ่งรายการบนโหนดเดียวกันกับพ็อดที่ใช้งาน หากโหนดในเครื่องไม่มีพื้นที่เหลือหรือพ็อดถูกย้าย โวลุ่มจะยังคงใช้งานได้แต่อาจมีเวลาแฝงที่สูงกว่าเล็กน้อย นี่คือการตั้งค่าที่แนะนำสำหรับภาระงานส่วนใหญ่
• แบบเข้มงวดในพื้นที่ — วอลุ่มสามารถใช้ได้บนโหนดที่มีแบบจำลองในเครื่องเท่านั้น หากพ็อดถูกกำหนดเวลาไปยังโหนดที่ไม่มีแบบจำลองในเครื่อง การแนบวอลุ่มจะล้มเหลว ใช้สิ่งนี้เฉพาะกับปริมาณงานการจำลองเดี่ยวที่มีความอ่อนไหวต่อเวลาแฝง ซึ่งคุณยอมรับการแลกเปลี่ยนความทนทาน

# Change replication factor on an existing volume
kubectl -n longhorn-system patch volumes.longhorn.io pvc-abc123 \
  --type merge -p '{"spec":{"numberOfReplicas":3}}'

# Set data locality on existing volume
kubectl -n longhorn-system patch volumes.longhorn.io pvc-abc123 \
  --type merge -p '{"spec":{"dataLocality":"best-effort"}}'

# Replica auto-balancing (spreads replicas evenly across nodes)
# Set via Longhorn settings
kubectl -n longhorn-system edit settings.longhorn.io replica-auto-balance
# Set value to: best-effort

สแนปชอตและการสำรองข้อมูล

Longhorn มีกลไกการปกป้องข้อมูลที่แตกต่างกันสองแบบ:สแนปช็อต(ภายในเครื่อง ทันที สำหรับการย้อนกลับอย่างรวดเร็ว) และการสำรองข้อมูล(ระยะไกล ไปยังพื้นที่จัดเก็บอ็อบเจ็กต์ สำหรับการกู้คืนระบบ) การทำความเข้าใจว่าเมื่อใดควรใช้แต่ละรายการเป็นสิ่งสำคัญ

จะถูกจัดเก็บไว้ในดิสก์เดียวกันกับแบบจำลองโวลุ่ม ข้อมูลเหล่านี้จะถูกสร้างขึ้นทันทีโดยใช้การคัดลอกเมื่อเขียน โดยจะไม่มีการคัดลอกข้อมูล ณ เวลาสแนปชอต มีเพียงการเขียนใหม่หลังจากสแน็ปช็อตเท่านั้นที่จะจัดสรรพื้นที่เพิ่มเติม สแน็ปช็อตเป็นเลิศสำหรับการย้อนกลับอย่างรวดเร็วก่อนการโยกย้ายหรือการปรับใช้ที่มีความเสี่ยง แต่สแนปชอตไม่ได้ป้องกันความล้มเหลวของโหนดหรือดิสก์เนื่องจากสแนปชอตอยู่บนพื้นที่จัดเก็บข้อมูลเดียวกันกับโวลุ่ม

จะคัดลอกข้อมูลโวลุ่มไปยังเป้าหมายการสำรองข้อมูลภายนอก — S3, GCS, Azure Blob หรือร้านค้าที่รองรับ S3 (MinIO, Wasabi) ข้อมูลสำรองจะเพิ่มขึ้นในระดับบล็อก: เฉพาะบล็อกที่เปลี่ยนแปลงตั้งแต่การสำรองข้อมูลครั้งล่าสุดเท่านั้นที่ถูกถ่ายโอน ทำให้การสำรองข้อมูลที่เกิดซ้ำรวดเร็วและมีประสิทธิภาพในการจัดเก็บข้อมูล การสำรองข้อมูลป้องกันการสูญเสียคลัสเตอร์ทั้งหมดเนื่องจากมีอยู่อย่างแยกจากกัน

การกำหนดค่าเป้าหมายสำรอง

# Create the S3 credentials secret
kubectl create secret generic longhorn-backup-s3-secret \
  -n longhorn-system \
  --from-literal=AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE \
  --from-literal=AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
  --from-literal=AWS_ENDPOINTS=https://s3.eu-west-1.amazonaws.com

# Set the backup target in Longhorn settings
kubectl -n longhorn-system edit settings.longhorn.io backup-target
# Set value to: s3://longhorn-backups@eu-west-1/

kubectl -n longhorn-system edit settings.longhorn.io backup-target-credential-secret
# Set value to: longhorn-backup-s3-secret

# For GCS backup target
# value: s3://longhorn-backups@us/  (GCS is S3-compatible via interop)
# Or use the GCS JSON key:
kubectl create secret generic longhorn-backup-gcs-secret \
  -n longhorn-system \
  --from-literal=GOOGLE_APPLICATION_CREDENTIALS=/var/longhorn-backup/gcs-key.json \
  --from-file=gcs-key.json=./service-account-key.json

# For Azure Blob backup target
kubectl create secret generic longhorn-backup-azure-secret \
  -n longhorn-system \
  --from-literal=AZBLOB_ACCOUNT_NAME=prodbackupstorage \
  --from-literal=AZBLOB_ACCOUNT_KEY=base64encodedkeyhere

VolumeSnapshot Class และ Snapshot YAML

# VolumeSnapshotClass for Longhorn
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: longhorn-snapshot-vsc
driver: driver.longhorn.io
deletionPolicy: Delete
parameters:
  type: snap
---
# Create a VolumeSnapshot
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: pg-data-snap-before-migration
  namespace: database
spec:
  volumeSnapshotClassName: longhorn-snapshot-vsc
  source:
    persistentVolumeClaimName: pg-data-postgresql-0
---
# Restore a PVC from a snapshot
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pg-data-restored
  namespace: database
spec:
  storageClassName: longhorn-db
  dataSource:
    name: pg-data-snap-before-migration
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

ตารางการสำรองข้อมูลที่เกิดซ้ำ

# Recurring snapshot job — every 4 hours, retain 6
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: db-snapshot-4h
  namespace: longhorn-system
spec:
  cron: "0 */4 * * *"
  task: snapshot
  retain: 6
  concurrency: 2
  groups:
    - db-volumes
  labels:
    tier: database
---
# Recurring backup job — daily at 02:00, retain 14 days
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: db-backup-daily
  namespace: longhorn-system
spec:
  cron: "0 2 * * *"
  task: backup
  retain: 14
  concurrency: 2
  groups:
    - db-volumes
  labels:
    tier: database
---
# Recurring backup job — weekly full, retain 8 weeks
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: db-backup-weekly
  namespace: longhorn-system
spec:
  cron: "0 3 * * 0"
  task: backup
  retain: 8
  concurrency: 1
  groups:
    - db-volumes
  labels:
    tier: database
---
# Assign recurring jobs to a volume via labels
# Label the PVC or volume with: recurring-job-group.longhorn.io/db-volumes: enabled
kubectl label pvc pg-data-postgresql-0 -n database \
  recurring-job-group.longhorn.io/db-volumes=enabled

การกู้คืนความเสียหาย

Longhorn มอบกลไกการกู้คืนความเสียหายในตัวผ่านไดรฟ์ข้อมูลDR— ไดรฟ์ข้อมูลสแตนด์บายในคลัสเตอร์รองที่ดึงการสำรองข้อมูลส่วนเพิ่มอย่างต่อเนื่องจากเป้าหมายการสำรองข้อมูลของคลัสเตอร์หลัก เมื่อเกิดภัยพิบัติ คุณจะเปิดใช้งานไดรฟ์ข้อมูล DR และจะกลายเป็นไดรฟ์ข้อมูลแบบอ่าน-เขียนปกติ โดยปล่อยให้คลัสเตอร์รองเข้ามาแทนที่

การตั้งค่าไดรฟ์ข้อมูล DR

# On the DR cluster: create a DR volume from the primary's backup
# This is done via the Longhorn UI or API

# 1. Configure the DR cluster's backup target to point to the same S3 bucket
kubectl -n longhorn-system edit settings.longhorn.io backup-target
# value: s3://longhorn-backups@eu-west-1/

# 2. Create a DR volume from the latest backup
# Via Longhorn UI: Backup → Select volume → Create DR Volume
# Via kubectl:
apiVersion: longhorn.io/v1beta2
kind: Volume
metadata:
  name: pg-data-dr
  namespace: longhorn-system
spec:
  size: "107374182400"  # 100Gi in bytes
  numberOfReplicas: 3
  fromBackup: "s3://longhorn-backups@eu-west-1/?backup=backup-abc123&volume=pg-data"
  standby: true
  frontend: ""

# 3. The DR volume auto-syncs incremental backups from S3
# Monitor sync status:
kubectl -n longhorn-system get volumes.longhorn.io pg-data-dr -o jsonpath='{.status.lastBackup}'

# 4. During failover — activate the DR volume:
kubectl -n longhorn-system patch volumes.longhorn.io pg-data-dr \
  --type merge -p '{"spec":{"standby":false,"frontend":"blockdev"}}'

# 5. Create a PVC bound to the activated DR volume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pg-data-postgresql-0
  namespace: database
spec:
  storageClassName: longhorn-db
  volumeName: pg-data-dr
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

การเข้ารหัสโวลุ่ม

Longhorn รองรับการเข้ารหัสระดับเสียงโดยใช้ Linux LUKS2 โวลุ่มที่เข้ารหัสจะปกป้องข้อมูลที่เหลือบนดิสก์ที่ซ่อนอยู่ แม้ว่าบางคนจะสามารถเข้าถึงพื้นที่จัดเก็บข้อมูลของเซิร์ฟเวอร์ได้ก็ตาม พวกเขาจะไม่สามารถอ่านข้อมูลโวลุ่มได้หากไม่มีคีย์เข้ารหัส

# Create a Kubernetes secret with the encryption passphrase
kubectl create secret generic longhorn-crypto \
  -n longhorn-system \
  --from-literal=CRYPTO_KEY_VALUE="a-very-long-and-random-passphrase-here" \
  --from-literal=CRYPTO_KEY_PROVIDER=secret \
  --from-literal=CRYPTO_KEY_CIPHER=aes-xts-plain64 \
  --from-literal=CRYPTO_KEY_HASH=sha256 \
  --from-literal=CRYPTO_KEY_SIZE=256 \
  --from-literal=CRYPTO_PBKDF=argon2i

# StorageClass with encryption enabled
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-encrypted
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Retain
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  fromBackup: ""
  encrypted: "true"
  csi.storage.k8s.io/provisioner-secret-name: longhorn-crypto
  csi.storage.k8s.io/provisioner-secret-namespace: longhorn-system
  csi.storage.k8s.io/node-publish-secret-name: longhorn-crypto
  csi.storage.k8s.io/node-publish-secret-namespace: longhorn-system
  csi.storage.k8s.io/node-stage-secret-name: longhorn-crypto
  csi.storage.k8s.io/node-stage-secret-namespace: longhorn-system

ReadWriteMany (RWX) รองรับ

ตามค่าเริ่มต้น ไดรฟ์ข้อมูล Longhorn จะเป็น ReadWriteOnce (RWO) — สามารถติดตั้งได้ด้วยพ็อดเดียวบนโหนดเดียว สำหรับปริมาณงานที่ต้องการพื้นที่จัดเก็บข้อมูลที่ใช้ร่วมกันในหลายพ็อด (เช่น การอัปโหลดสื่อที่ใช้ร่วมกัน ไฟล์การกำหนดค่า อาร์ติแฟกต์ของโมเดล ML) Longhorn รองรับ ReadWriteMany (RWX) ผ่านเซิร์ฟเวอร์ NFS ที่ผสานรวม

เมื่อ PVC ขอโหมดการเข้าถึง RWX นั้น Longhorn จะใช้พ็อดตัวจัดการการแชร์ที่รันเซิร์ฟเวอร์ NFS ที่ได้รับการสนับสนุนจากโวลุ่ม Longhorn โดยอัตโนมัติ พ็อดหลายตัวสามารถติดตั้งวอลลุ่มพร้อมกันบน NFS ได้ ซึ่งง่ายกว่าการใช้เซิร์ฟเวอร์ NFS แยกต่างหาก แต่จะเพิ่มโอเวอร์เฮดเครือข่ายอีกชั้นหนึ่งเมื่อเทียบกับการเข้าถึงบล็อกโดยตรง

# PVC with ReadWriteMany access mode
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-media
  namespace: application
spec:
  storageClassName: longhorn-rwx
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 50Gi

บน Longhorn

ที่ใช้งานบน Longhorn ต้องการความเอาใจใส่อย่างระมัดระวังต่อพารามิเตอร์ StorageClass, พ็อดแอฟฟินิตี้ และการผสานรวมการสำรองข้อมูล กลไกต่อวอลุ่มและการจำลองแบบซิงโครนัสของ Longhorn ทำให้เหมาะสมกับปริมาณงานฐานข้อมูล แต่คุณต้องกำหนดค่าอย่างถูกต้องเพื่อให้ได้ประสิทธิภาพและความน่าเชื่อถือระดับการใช้งานจริง

PostgreSQL StatefulSet พร้อม Longhorn

# PostgreSQL StatefulSet using Longhorn PVC
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgresql
  namespace: database
spec:
  serviceName: postgresql
  replicas: 3
  selector:
    matchLabels:
      app: postgresql
  template:
    metadata:
      labels:
        app: postgresql
    spec:
      terminationGracePeriodSeconds: 120
      securityContext:
        fsGroup: 999
        runAsUser: 999
      containers:
        - name: postgresql
          image: postgres:16-alpine
          ports:
            - containerPort: 5432
          env:
            - name: POSTGRES_DB
              value: production
            - name: POSTGRES_USER
              valueFrom:
                secretKeyRef:
                  name: pg-credentials
                  key: username
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: pg-credentials
                  key: password
            - name: PGDATA
              value: /var/lib/postgresql/data/pgdata
          resources:
            requests:
              cpu: "1"
              memory: 2Gi
            limits:
              cpu: "4"
              memory: 8Gi
          volumeMounts:
            - name: pg-data
              mountPath: /var/lib/postgresql/data
          livenessProbe:
            exec:
              command: ["pg_isready", "-U", "$(POSTGRES_USER)"]
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            exec:
              command: ["pg_isready", "-U", "$(POSTGRES_USER)"]
            initialDelaySeconds: 5
            periodSeconds: 5
  volumeClaimTemplates:
    - metadata:
        name: pg-data
        labels:
          recurring-job-group.longhorn.io/db-volumes: enabled
      spec:
        storageClassName: longhorn-db
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 100Gi

MySQL StatefulSet พร้อม Longhorn

# MySQL StatefulSet using Longhorn PVC
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
  namespace: database
spec:
  serviceName: mysql
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - name: mysql
          image: mysql:8.0
          ports:
            - containerPort: 3306
          env:
            - name: MYSQL_ROOT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mysql-credentials
                  key: root-password
            - name: MYSQL_DATABASE
              value: production
          args:
            - "--default-authentication-plugin=mysql_native_password"
            - "--innodb-buffer-pool-size=4G"
            - "--innodb-log-file-size=1G"
            - "--innodb-flush-log-at-trx-commit=1"
            - "--sync-binlog=1"
          resources:
            requests:
              cpu: "1"
              memory: 4Gi
            limits:
              cpu: "4"
              memory: 8Gi
          volumeMounts:
            - name: mysql-data
              mountPath: /var/lib/mysql
  volumeClaimTemplates:
    - metadata:
        name: mysql-data
        labels:
          recurring-job-group.longhorn.io/db-volumes: enabled
      spec:
        storageClassName: longhorn-db
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 200Gi

สำหรับปริมาณงานฐานข้อมูล

Longhorn เพิ่มเลเยอร์การจำลองการจัดเก็บข้อมูลระหว่างแอปพลิเคชันและฟิสิคัลดิสก์ ซึ่งทำให้เกิดเวลาแฝงเมื่อเปรียบเทียบกับการเข้าถึงดิสก์ในเครื่องโดยตรง สำหรับเวิร์กโหลดส่วนใหญ่ โอเวอร์เฮดนี้ไม่สำคัญ แต่เวิร์กโหลดฐานข้อมูลที่มีรูปแบบการเขียนจำนวนมากจำเป็นต้องปรับแต่งเพื่อให้ได้ประสิทธิภาพสูงสุด

ใช้ตำแหน่งข้อมูล: พยายามอย่างดีที่สุดช่วยให้มั่นใจได้ว่าเรพลิกาหนึ่งรายการอยู่บนโหนดเดียวกันกับพ็อดฐานข้อมูล ซึ่งหมายความว่าจะอ่านการเข้าถึงดิสก์ภายในเครื่องด้วยความเร็ว NVMe/SSD การเขียนยังคงทำซ้ำไปยังโหนดระยะไกล แต่การจำลองในเครื่องจะกำจัดการเดินทางไปกลับของเครือข่ายเพื่อการอ่าน

อุทิศดิสก์ให้กับ Longhornอย่าแชร์ดิสก์ OS กับข้อมูล Longhorn เพิ่มไดรฟ์ NVMe หรือ SSD เฉพาะและกำหนดค่าเป็นดิสก์ Longhorn ซึ่งจะป้องกันการแย่งชิง I/O ระหว่างระบบปฏิบัติการและวอลุ่มฐานข้อมูล

# Configure dedicated disks on a node
# Via kubectl (Longhorn node CRD)
kubectl -n longhorn-system edit nodes.longhorn.io worker-01

# Add the dedicated disk under spec.disks:
spec:
  disks:
    default-disk:
      allowScheduling: false  # disable OS disk for Longhorn
      path: /var/lib/longhorn/
      storageReserved: 0
    nvme-data:
      allowScheduling: true
      path: /mnt/nvme-longhorn/
      storageReserved: 10737418240  # 10Gi reserved
      tags:
        - nvme
        - database

ชุดรับประกันตัวจัดการเครื่องยนต์ CPU. กระบวนการกลไกของLonghorn ใช้ CPU สำหรับการประมวลผลและการจำลอง I/O การตั้งค่าguaranteedInstanceManagerCPUจะสงวนเปอร์เซ็นต์ของโหนด CPU สำหรับตัวจัดการอินสแตนซ์ Longhorn เพื่อป้องกันไม่ให้ CPU หยุดทำงานภายใต้ภาระงาน

ปรับจำนวนเรพลิกาสำหรับฐานข้อมูลที่มีการจำลองแบบระดับแอปพลิเคชันอยู่แล้ว (การจำลองแบบสตรีมมิ่ง PostgreSQL, การจำลองแบบกลุ่ม MySQL, ชุดแบบจำลอง MongoDB) คุณสามารถลดจำนวนแบบจำลอง Longhorn ลงเหลือ 2 แทนที่จะเป็น 3 การจำลองแบบของฐานข้อมูลเองจะมอบการปกป้องข้อมูลอีกชั้นหนึ่ง และแบบจำลอง Longhorn ที่น้อยลงหมายถึงการขยายการเขียนน้อยลงและปริมาณงานการเขียนที่ดีขึ้น

ใช้ ext4 บน xfs สำหรับ I/O สุ่มขนาดเล็กแม้ว่า xfs จะเก่งในเรื่องการเขียนตามลำดับขนาดใหญ่ แต่โดยทั่วไปแล้ว ext4 จะทำงานได้ดีกว่าสำหรับรูปแบบ I/O แบบสุ่มขนาดเล็กทั่วไปของเวิร์กโหลดฐานข้อมูล ตั้งค่าfsType: ext4ใน StorageClass ของคุณ

การตั้งเวลาโหนดและการจัดการดิสก์

Longhorn ให้การควบคุมอย่างละเอียดว่าจะใช้โหนดและดิสก์ใดในการกำหนดเวลาวอลุ่ม นี่เป็นสิ่งสำคัญในคลัสเตอร์ที่ต่างกัน โดยที่บางโหนดมีพื้นที่จัดเก็บข้อมูล NVMe ที่รวดเร็ว และโหนดอื่นๆ มีไดรฟ์ SATA ที่ช้ากว่า

# Tag nodes for storage scheduling
kubectl label node worker-01 node.longhorn.io/storage=nvme
kubectl label node worker-02 node.longhorn.io/storage=nvme
kubectl label node worker-03 node.longhorn.io/storage=nvme
kubectl label node worker-04 node.longhorn.io/storage=sata

# Use node selector in StorageClass to target NVMe nodes
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-nvme
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  nodeSelector: "node.longhorn.io/storage=nvme"
  diskSelector: "nvme,database"
  dataLocality: best-effort

ด้วย Prometheus และ Grafana

Longhorn เปิดเผยตัววัด Prometheus ผ่านตำแหน่งข้อมูลตัววัดในตัว การตรวจสอบตัววัดเหล่านี้ถือเป็นสิ่งสำคัญสำหรับการวางแผนกำลังการผลิต การวิเคราะห์ประสิทธิภาพ และการแจ้งเตือนเชิงรุก

# ServiceMonitor for Longhorn metrics
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: longhorn-prometheus
  namespace: monitoring
  labels:
    release: prometheus
spec:
  selector:
    matchLabels:
      app: longhorn-manager
  namespaceSelector:
    matchNames:
      - longhorn-system
  endpoints:
    - port: manager
      path: /metrics
      interval: 30s
---
# PrometheusRule for Longhorn alerts
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: longhorn-alerts
  namespace: monitoring
spec:
  groups:
    - name: longhorn-storage
      rules:
        - alert: LonghornVolumeStatusCritical
          expr: longhorn_volume_robustness == 3
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Longhorn volume {{ $labels.volume }} is Faulted"
        - alert: LonghornVolumeStatusDegraded
          expr: longhorn_volume_robustness == 2
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "Longhorn volume {{ $labels.volume }} is Degraded"
        - alert: LonghornNodeStorageWarning
          expr: |
            (longhorn_node_storage_usage_bytes / longhorn_node_storage_capacity_bytes) > 0.80
          for: 15m
          labels:
            severity: warning
          annotations:
            summary: "Longhorn node {{ $labels.node }} storage at {{ $value | humanizePercentage }}"
        - alert: LonghornBackupFailed
          expr: longhorn_backup_state == 3
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Longhorn backup failed for volume {{ $labels.volume }}"

Key Grafana ที่สร้างขึ้นสำหรับการตรวจสอบ Longhorn ประกอบด้วย: IOPS ของไดรฟ์ข้อมูล (อ่าน/เขียน), ปริมาณการประมวลผลของไดรฟ์ข้อมูล (MB/s), เวลาแฝงของไดรฟ์ข้อมูล (p50/p95/p99), ความคืบหน้าในการสร้างแบบจำลองใหม่, ความจุและการใช้งานพื้นที่จัดเก็บโหนด, สถานะและอายุของการสำรองข้อมูล และจำนวนสแน็ปช็อตต่อไดรฟ์ข้อมูล

k3s พร้อมกองจัดเก็บข้อมูล Longhorn ที่สมบูรณ์

แผนภาพต่อไปนี้แสดงให้เห็นว่า Longhorn เข้ากับกลุ่มการผลิต k3s ที่สมบูรณ์ได้อย่างไร ตั้งแต่เซิร์ฟเวอร์ Bare Metal ไปจนถึงพ็อดแอปพลิเคชัน พร้อมด้วยการจัดการ Rancher และความสามารถในการสังเกต Prometheus/Grafana

กับโซลูชันการจัดเก็บข้อมูล Kubernetes อื่นๆ

Longhorn ไม่ใช่ตัวเลือกการจัดเก็บเพียงตัวเดียวสำหรับ Kubernetes การทำความเข้าใจว่าระบบนี้เปรียบเทียบกับทางเลือกอื่นๆ อย่างไรจะช่วยให้คุณตัดสินใจเลือกได้ถูกต้องสำหรับความต้องการเฉพาะของคุณ

Longhorn vs Rook-Ceph:Ceph เป็นระบบที่ทรงพลังกว่า — รองรับการจัดเก็บอ็อบเจ็กต์ พื้นที่จัดเก็บไฟล์ และบล็อกพื้นที่จัดเก็บด้วยอัลกอริธึมการวางตำแหน่ง CRUSH ที่ซับซ้อน อย่างไรก็ตาม Ceph ต้องการโหนด OSD เฉพาะอย่างน้อย 3 โหนด, RAM จำนวนมาก (ขั้นต่ำ 4GB ต่อ OSD daemon) และความเชี่ยวชาญในการดำเนินงานเชิงลึก สำหรับคลัสเตอร์ k3s ที่มี 3–10 โหนด Longhorn จะให้มูลค่า 90% ที่ 10% ของต้นทุนการดำเนินงาน

Longhorn เทียบกับ OpenEBS Mayastor:Mayastor ใช้ NVMe-over-Fabrics สำหรับการจำลองแบบประสิทธิภาพสูง โดยได้รับเวลาแฝงต่ำกว่าการจำลองแบบ TCP ของ Longhorn หาก IOPS ดิบและเวลาแฝงต่ำกว่ามิลลิวินาทีเป็นปัญหาหลักของคุณ และคุณมีโครงสร้างพื้นฐาน NVMe พร้อมเครือข่าย RDMA Mayastor อาจเป็นตัวเลือกที่ดีกว่า สำหรับการปรับใช้ k3s ส่วนใหญ่ การสำรองข้อมูลแบบผสานรวม, DR และความเรียบง่ายในการปฏิบัติงานของ Longhorn นั้นมีมากกว่าความได้เปรียบด้านประสิทธิภาพของ Mayastor

Longhorn เทียบกับ local-path:local-path allowanceer เป็นที่เก็บข้อมูลเริ่มต้นของ k3s — เพียงสร้างไดเรกทอรีบนระบบไฟล์ในเครื่องของโหนด การจำลองแบบเป็นศูนย์, สแน็ปช็อตเป็นศูนย์, การรวมการสำรองข้อมูลเป็นศูนย์ เป็นเรื่องปกติสำหรับการพัฒนา แต่ไม่สามารถยอมรับได้สำหรับข้อมูลการผลิต

แนวทางปฏิบัติที่ดีที่สุดในการผลิต

คำแนะนำเหล่านี้กลั่นกรองมาจากการใช้งาน Longhorn กับคลัสเตอร์ k3s ที่ใช้งานจริงหลายสิบรายการที่ใช้งานเวิร์กโหลดฐานข้อมูล

1. ตั้งค่าการจองทรัพยากรสำหรับผู้จัดการอินสแตนซ์ ตัวจัดการอินสแตนซ์Longhorn (ตัวจัดการกลไกและตัวจัดการแบบจำลอง) จำเป็นต้องมีการรับประกัน CPU เพื่อหลีกเลี่ยงปัญหา I/O หยุดทำงานในระหว่างที่โหนดกดดัน ตั้งค่าguaranteedInstanceManagerCPUเป็นอย่างน้อย 12% ในการตั้งค่า Longhorn

2. ใช้นโยบายการเรียกคืน Retain สำหรับวอลุ่มฐานข้อมูลห้ามใช้Deleteสำหรับฐานข้อมูล PVC นโยบายRetainจะรักษา PV และข้อมูลไว้แม้ว่า PVC จะถูกลบไปแล้วก็ตาม ทำให้คุณปลอดภัยจากการลบโดยไม่ตั้งใจ

3. ปิดใช้งานการจำลองแบบ soft anti-affinity สำหรับการผลิตตั้งค่าreplicaSoftAntiAffinity: falseเพื่อให้แน่ใจว่าเรพลิกาจะกระจายไปตามโหนดต่างๆ เสมอ ด้วยการต่อต้านความสัมพันธ์แบบนุ่มนวล Longhorn อาจกำหนดเวลาการจำลองหลายรายการบนโหนดเดียวกันเมื่อพื้นที่มีจำกัด ซึ่งเอาชนะวัตถุประสงค์ของการจำลองแบบ

4. สำรองพื้นที่จัดเก็บข้อมูลในทุกโหนดตั้งค่าstorageMinimalAvailablePercentageเป็นอย่างน้อย 15% การทำเช่นนี้จะป้องกันไม่ให้ Longhorn ใช้พื้นที่ดิสก์ทั้งหมด ซึ่งจะทำให้เกิดปัญหาระดับโหนดซึ่งส่งผลต่อพ็อดทั้งหมด

5. เปิดใช้งานการกอบกู้อัตโนมัติการตั้งค่าautoSalvageจะกู้คืนวอลุ่มที่เข้าสู่สถานะผิดพลาดโดยอัตโนมัติ เมื่อแบบจำลองอย่างน้อยหนึ่งตัวยังคงอยู่ในสภาพปกติ ซึ่งจะช่วยลดการแทรกแซงด้วยตนเองในระหว่างที่โหนดล้มเหลว

6. ตั้งค่าคลาสลำดับความสำคัญเป็น system-cluster-critical ส่วนประกอบตัวจัดการและไดรเวอร์ของLonghorn ไม่ควรถูกไล่ออกในระหว่างที่โหนดกดดัน ตั้งค่าลำดับความสำคัญของคลาสเป็นsystem-cluster-criticalเพื่อให้แน่ใจว่าพวกเขาจะรอดจากการขับไล่พ็อด

7. กำหนดค่างานที่เกิดซ้ำสำหรับปริมาณการผลิตทั้งหมดทุกปริมาณการผลิตควรมีทั้งงานสแน็ปช็อตและงานสำรองข้อมูลที่เกิดซ้ำ สแนปชอตทุกๆ 4 ชั่วโมงเพื่อการย้อนกลับอย่างรวดเร็ว การสำรองข้อมูลรายวันเพื่อการกู้คืนระบบ

8. ทดสอบการเปิดใช้งานไดรฟ์ข้อมูล DR เป็นประจำสร้างกำหนดการรายเดือนเพื่อเปิดใช้งานไดรฟ์ข้อมูล DR ในคลัสเตอร์สแตนด์บายของคุณ ตรวจสอบความสมบูรณ์ของข้อมูล และฝึกฝนกระบวนการเฟลโอเวอร์ แผน DR ที่ไม่เคยทดสอบเป็นเพียงเอกสารประกอบ

9. ตรวจสอบความสมบูรณ์ของระดับเสียงในเชิงรุกตั้งค่าการแจ้งเตือน Prometheus สำหรับไดรฟ์ข้อมูลที่เสื่อมลงและเกิดข้อผิดพลาด ความจุพื้นที่จัดเก็บโหนด อายุการสำรองข้อมูล และสถานะการสร้างแบบจำลองใหม่ เมื่อผู้ใช้รายงานฐานข้อมูลที่ช้า แสดงว่าปัญหาการจัดเก็บข้อมูลได้ก่อตัวขึ้นเป็นเวลาหลายชั่วโมงแล้ว

10. ใช้ดิสก์จัดเก็บข้อมูลเฉพาะแยกข้อมูล Longhorn ออกจากดิสก์ OS วิธีนี้จะป้องกันการโต้แย้ง I/O ช่วยให้คุณจัดการความจุได้สะอาดขึ้น และหลีกเลี่ยงความเสี่ยงในการเติมข้อมูล Longhorn ในดิสก์ OS

คำแนะนำการใช้งานเฉพาะระบบคลาวด์

AWS — EC2 พร้อมพื้นที่จัดเก็บอินสแตนซ์ NVMe

สำหรับการปรับใช้ AWS ให้ใช้อินสแตนซ์i3.xlargeหรือi3en.xlargeที่มาพร้อมกับพื้นที่จัดเก็บอินสแตนซ์ NVMe สิ่งเหล่านี้มอบประสิทธิภาพ NVMe ดิบโดยมีค่าใช้จ่ายเพียงเล็กน้อยของ EBS IOPS ที่จัดเตรียมไว้ ฟอร์แมตพื้นที่จัดเก็บอินสแตนซ์และกำหนดค่าเป็นดิสก์ Longhorn

# On each EC2 i3.xlarge instance
sudo mkfs.ext4 /dev/nvme0n1
sudo mkdir -p /mnt/longhorn-nvme
sudo mount /dev/nvme0n1 /mnt/longhorn-nvme
echo '/dev/nvme0n1 /mnt/longhorn-nvme ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab

# Configure as Longhorn disk (via node CRD or UI)
# Path: /mnt/longhorn-nvme/

Azure — VM พร้อม Ultra Disk

บน Azure ให้ใช้Standard_L8s_v3หรือStandard_L16s_v3VMs พร้อมที่เก็บข้อมูล NVMe ในเครื่อง หรือติดตั้ง Ultra Disks เพื่อให้มีเวลาแฝงต่ำกว่ามิลลิวินาทีที่สม่ำเสมอ Ultra Disks ช่วยให้คุณสามารถกำหนดค่า IOPS และปริมาณงานได้อย่างอิสระ

# Attach Ultra Disk to Azure VM (Azure CLI)
az vm disk attach \
  --vm-name k3s-worker-01 \
  --resource-group k3s-cluster \
  --name longhorn-ultra-01 \
  --size-gb 512 \
  --sku UltraSSD_LRS \
  --disk-iops-read-write 10000 \
  --disk-mbps-read-write 300 \
  --new

GCP — VM พร้อม SSD ภายใน

GCP มี SSD ภายในที่แนบกับn2-standardหรือc3-standardVM SSD ภายในให้พื้นที่ 375 GB ต่อดิสก์พร้อม IOPS การอ่านสูงสุด 680,000 แนบ SSD ภายในหลายตัวและ RAID เพื่อให้ได้โวลุ่มที่ใหญ่ขึ้น

# Create VM with local SSDs (gcloud)
gcloud compute instances create k3s-worker-01 \
  --machine-type=n2-standard-8 \
  --local-ssd=interface=NVME \
  --local-ssd=interface=NVME \
  --zone=europe-west1-b

# RAID two local SSDs for 750GB Longhorn disk
sudo mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/nvme0n1 /dev/nvme0n2
sudo mkfs.ext4 /dev/md0
sudo mkdir -p /mnt/longhorn-nvme
sudo mount /dev/md0 /mnt/longhorn-nvme

ศูนย์ข้อมูลภายในองค์กร

สำหรับการปรับใช้ภายในองค์กร ให้ใช้เซิร์ฟเวอร์ที่มีไดรฟ์ NVMe หรือ SAS SSD เฉพาะสำหรับ Longhorn แยกดิสก์ OS ออกจากดิสก์จัดเก็บข้อมูล ใช้เครือข่าย 10GbE หรือ 25GbE ระหว่างโหนดเพื่อให้แน่ใจว่าการรับส่งข้อมูลการจำลองไม่เกิดปัญหาคอขวด — การจำลองแบบซิงโครนัส Longhorn จะสร้างการรับส่งข้อมูลเครือข่ายตามสัดส่วนปริมาณงานการเขียนคูณด้วยจำนวนแบบจำลอง

# Typical on-premises server spec for Longhorn k3s node
# CPU: 8+ cores (Xeon or EPYC)
# RAM: 32+ GB
# OS Disk: 256GB SATA SSD (mirrored)
# Longhorn Disk: 2x 1TB NVMe (RAID-1 or individual Longhorn disks)
# Network: 2x 25GbE (bonded, one for application, one for storage)

# Configure dedicated storage network (optional but recommended)
# In Longhorn settings:
# storage-network: kube-system/storage-network-attachment

Longhorn UI

Longhorn มาพร้อมกับ UI เว็บในตัวที่ให้อินเทอร์เฟซแบบภาพสำหรับจัดการวอลุ่ม สแน็ปช็อต การสำรองข้อมูล โหนด และการตั้งค่า เข้าถึงได้ผ่านทาง Ingress ที่กำหนดค่าระหว่างการติดตั้งหรือผ่านการส่งต่อพอร์ต kubectl

# Quick access via port-forward
kubectl -n longhorn-system port-forward svc/longhorn-frontend 8080:80
# Open http://localhost:8080 in your browser

UI มีมุมมองหลักหลายประการ:Dashboardแสดงความสมบูรณ์ของพื้นที่จัดเก็บข้อมูลทั่วทั้งคลัสเตอร์ รวมถึงความจุทั้งหมด พื้นที่ใช้งาน และสถานะไดรฟ์ข้อมูล ไดรฟ์ข้อมูลแสดงรายการไดรฟ์ข้อมูลทั้งหมดพร้อมสถานะ (สมบูรณ์/เสื่อมคุณภาพ/มีข้อบกพร่อง) ขนาด จำนวนเรพลิกา และโหนดที่เชื่อมต่อ คุณสามารถขยาย สแน็ปช็อต สำรองข้อมูล และกู้คืนโวลุ่มได้โดยตรงจากมุมมองนี้Nodeแสดงการกำหนดค่าพื้นที่เก็บข้อมูลของแต่ละโหนด การจัดสรรดิสก์ และสถานะการตั้งเวลา การสำรองข้อมูลแสดงรายการการสำรองข้อมูลทั้งหมดที่จัดเก็บไว้ในเป้าหมายการสำรองข้อมูลพร้อมปริมาณ ขนาด และเวลาในการสร้าง การตั้งค่าจะแสดงพารามิเตอร์การกำหนดค่า Longhorn ทั้งหมดพร้อมคำอธิบาย

การแก้ไขปัญหาทั่วไป

โวลุ่มลดระดับ

ไดรฟ์ข้อมูลเข้าสู่สถานะลดระดับลง เมื่อแบบจำลองตั้งแต่หนึ่งรายการขึ้นไปไม่มีประสิทธิภาพ แต่ไดรฟ์ข้อมูลยังคงใช้งานได้ สาเหตุที่พบบ่อย ได้แก่ โหนดล้มเหลว ดิสก์เต็ม หรือพาร์ติชันเครือข่าย

# Check volume status
kubectl -n longhorn-system get volumes.longhorn.io -o wide

# Describe the volume for detailed status
kubectl -n longhorn-system describe volumes.longhorn.io pvc-abc123

# Check replica status
kubectl -n longhorn-system get replicas.longhorn.io -l longhornvolume=pvc-abc123

# If a replica is stuck in error state, delete it to trigger rebuild
kubectl -n longhorn-system delete replicas.longhorn.io pvc-abc123-r-12345

# Monitor rebuild progress
kubectl -n longhorn-system get volumes.longhorn.io pvc-abc123 \
  -o jsonpath='{.status.conditions}' | jq

ติดค้างอยู่ในการติดตั้ง/ถอด

# Check engine status
kubectl -n longhorn-system get engines.longhorn.io -l longhornvolume=pvc-abc123

# Check for stuck VolumeAttachment objects
kubectl get volumeattachments | grep pvc-abc123

# Force detach a stuck volume (use cautiously)
kubectl -n longhorn-system patch volumes.longhorn.io pvc-abc123 \
  --type merge -p '{"spec":{"nodeID":""}}'

# If attachment is truly stuck, delete the VolumeAttachment
kubectl delete volumeattachment csi-abc123def456

แรงดันอวกาศ

# Check node storage usage
kubectl -n longhorn-system get nodes.longhorn.io -o wide

# Identify large snapshots consuming space
kubectl -n longhorn-system get snapshots.longhorn.io -l longhornvolume=pvc-abc123

# Purge old snapshots to reclaim space
# Via Longhorn UI: Volume → Snapshots → Delete unneeded snapshots
# Old snapshots consume space because COW data cannot be freed until the snapshot is deleted

# Check for snapshot data integrity issues
kubectl -n longhorn-system get settings.longhorn.io snapshot-data-integrity

Longhorn ควรทำอย่างระมัดระวัง เนื่องจากระบบจัดเก็บข้อมูลรองรับเวิร์กโหลดแบบมีสถานะทั้งหมด สำรองข้อมูลวอลุ่มที่สำคัญทั้งหมดก่อนอัปเกรดเสมอ

# 1. Back up all volumes before upgrade
for vol in $(kubectl -n longhorn-system get volumes.longhorn.io -o jsonpath='{.items[*].metadata.name}'); do
  echo "Backing up $vol"
  kubectl -n longhorn-system patch volumes.longhorn.io $vol \
    --type merge -p '{"spec":{"lastBackupAt":"'$(date -u +"%Y-%m-%dT%H:%M:%SZ")'"}}'
done

# 2. Check current version
kubectl -n longhorn-system get daemonset longhorn-manager -o jsonpath='{.spec.template.spec.containers[0].image}'

# 3. Upgrade via Helm
helm repo update
helm upgrade longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --version 1.7.2 \
  --values longhorn-values.yaml

# 4. Monitor the rolling upgrade
kubectl -n longhorn-system rollout status daemonset/longhorn-manager
kubectl -n longhorn-system rollout status deployment/longhorn-driver-deployer

# 5. Verify all volumes are healthy after upgrade
kubectl -n longhorn-system get volumes.longhorn.io -o custom-columns=NAME:.metadata.name,STATE:.status.state,ROBUSTNESS:.status.robustness

# 6. Longhorn automatically upgrades engines — monitor progress
kubectl -n longhorn-system get engines.longhorn.io -o wide

กับตัวดำเนินการฐานข้อมูล

ตัวดำเนินการฐานข้อมูล Kubernetes สมัยใหม่ (CloudNativePG, Percona Operator, Zalando Postgres Operator) ทำงานร่วมกับ Longhorn ได้อย่างราบรื่น ผู้ปฏิบัติงานจัดการวงจรการใช้งานฐานข้อมูลในขณะที่ Longhorn จัดเตรียมพื้นที่จัดเก็บข้อมูลพื้นฐานพร้อมการจำลองแบบ สแน็ปช็อต และการสำรองข้อมูล

# CloudNativePG cluster using Longhorn storage
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: production-pg
  namespace: database
spec:
  instances: 3
  storage:
    size: 100Gi
    storageClass: longhorn-db
    pvcTemplate:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 100Gi
  walStorage:
    size: 20Gi
    storageClass: longhorn-fast

  postgresql:
    parameters:
      shared_buffers: "2GB"
      effective_cache_size: "6GB"
      maintenance_work_mem: "512MB"
      wal_buffers: "64MB"
      max_connections: "200"

  backup:
    barmanObjectStore:
      destinationPath: s3://pg-backups/cnpg/
      endpointURL: https://s3.eu-west-1.amazonaws.com
      s3Credentials:
        accessKeyId:
          name: aws-creds
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: aws-creds
          key: SECRET_ACCESS_KEY
      wal:
        compression: gzip
    retentionPolicy: "30d"

  resources:
    requests:
      cpu: "2"
      memory: 4Gi
    limits:
      cpu: "4"
      memory: 8Gi

# Percona XtraDB Cluster with Longhorn storage
apiVersion: pxc.percona.com/v1
kind: PerconaXtraDBCluster
metadata:
  name: production-mysql
  namespace: database
spec:
  crVersion: "1.14.0"
  pxc:
    size: 3
    image: percona/percona-xtradb-cluster:8.0
    resources:
      requests:
        cpu: "2"
        memory: 4Gi
    volumeSpec:
      persistentVolumeClaim:
        storageClassName: longhorn-db
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 200Gi
  backup:
    image: percona/percona-xtradb-cluster-operator:1.14.0-pxc8.0-backup-pxb8.0.35
    storages:
      s3-backup:
        type: s3
        s3:
          bucket: mysql-backups
          region: eu-west-1
          credentialsSecret: aws-creds
    schedule:
      - name: daily-full
        schedule: "0 2 * * *"
        keep: 14
        storageName: s3-backup

สรุป

Longhorn เปลี่ยน k3s จากการกระจาย Kubernetes น้ำหนักเบาที่เหมาะสำหรับ Edge และการพัฒนาเท่านั้น ให้เป็นแพลตฟอร์มที่พร้อมสำหรับการผลิตที่สามารถรันปริมาณงาน stateful ที่มีความสำคัญต่อภารกิจได้ สถาปัตยกรรม — กลไกต่อวอลุ่ม, การจำลองแบบหลายโหนดแบบซิงโครนัส, สแน็ปช็อตที่ผสานรวมและการสำรองข้อมูลไปยังพื้นที่จัดเก็บออบเจ็กต์บนคลาวด์, ไดรฟ์ข้อมูล DR, การเข้ารหัสไดรฟ์ข้อมูล และการขยาย PVC ออนไลน์ มอบพื้นที่จัดเก็บข้อมูลระดับองค์กรโดยไม่มีความซับซ้อนระดับองค์กร

กุญแจสู่ความสำเร็จของ Longhorn ในการผลิตมีสามประการ ขั้นแรก กำหนดค่าอย่างเหมาะสมตั้งแต่เริ่มต้น: ใช้ดิสก์จัดเก็บข้อมูลเฉพาะ ตั้งค่าปัจจัยการจำลองและตำแหน่งข้อมูลที่เหมาะสม และสร้าง StorageClasses ที่สร้างขึ้นตามวัตถุประสงค์สำหรับประเภทเวิร์กโหลดที่แตกต่างกัน ประการที่สอง รวมการสำรองข้อมูลเข้ากับสถาปัตยกรรมของคุณตั้งแต่วันแรก: สแน็ปช็อตที่เกิดซ้ำเพื่อการย้อนกลับอย่างรวดเร็ว การสำรองข้อมูลรายวันไปยัง S3/GCS/Azure สำหรับการกู้คืนระบบ และไดรฟ์ข้อมูล DR ในคลัสเตอร์สแตนด์บายสำหรับสถานการณ์ที่เลวร้ายที่สุด ประการที่สาม ตรวจสอบทุกอย่าง: ความสมบูรณ์ของไดรฟ์ข้อมูล ความจุของพื้นที่จัดเก็บโหนด อายุการสำรองข้อมูล และสถานะการสร้างแบบจำลองใหม่ ปัญหาเกี่ยวกับพื้นที่จัดเก็บจะมองไม่เห็นจนกว่าจะกลายเป็นหายนะ

การขยาย PVC แบบไดนามิกช่วยขจัดหนึ่งในสาเหตุที่พบบ่อยที่สุดของเหตุการณ์การผลิต — พื้นที่ดิสก์ไม่เพียงพอ ด้วย Longhorn การขยายวอลุ่มฐานข้อมูลจาก 50Gi เป็น 500Gi เป็นเพียงคำสั่ง kubectl เดียวที่มีการหยุดทำงานเป็นศูนย์ เมื่อใช้ร่วมกับการแจ้งเตือน Prometheus เกี่ยวกับเกณฑ์ความจุ คุณสามารถขยายวอลุ่มในเชิงรุกก่อนที่จะกลายเป็นวิกฤติ หรือทำให้การขยายทั้งหมดเป็นแบบอัตโนมัติ

ไม่ว่าคุณจะใช้งาน PostgreSQL, MySQL, MongoDB หรือ Redis บน k3s — บนเซิร์ฟเวอร์ Bare Metal, AWS EC2, Azure VMs, อินสแตนซ์ GCP หรือฮาร์ดแวร์ศูนย์ข้อมูลในองค์กร — Longhorn มอบรากฐานการจัดเก็บข้อมูลที่ช่วยให้คุณมุ่งเน้นไปที่แอปพลิเคชันของคุณ แทนที่จะกังวลเกี่ยวกับความทนทานของข้อมูล ติดตั้ง กำหนดค่า ตรวจสอบ และไว้วางใจกับข้อมูลการผลิตของคุณ