उत्पादन k3s क्लस्टर के लिए लॉन्गहॉर्न स्टोरेज: गतिशील PVC विस्तार, प्रतिकृति और आपदा पुनर्प्राप्ति

स्टोरेज सबसे कठिन समस्या है। कंप्यूट स्टेटलेस और फंगसिबल है - एक पॉड को मारें, दूसरे को शेड्यूल करें। नेटवर्किंग में परिपक्व सीएनआई प्लगइन्स और सर्विस मेश हैं। लेकिन भंडारण? भंडारण वह जगह है जहां राज्य रहता है, जहां डेटा पुनरारंभ के दौरान बना रहता है, जहां एक भी गलत कॉन्फ़िगरेशन का मतलब स्थायी डेटा हानि हो सकता है। उत्पादन कार्यभार चलाने वाले k3s क्लस्टर के लिए - डेटाबेस, संदेश कतार, एप्लिकेशन स्थिति - आपको एक भंडारण समाधान की आवश्यकता होती है जो वितरित, लचीला, विस्तार योग्य और संचालन योग्य हो। लॉन्गहॉर्न वह समाधान है.

लॉन्गहॉर्न Kubernetes के लिए एक हल्का, विश्वसनीय और उपयोग में आसान वितरित ब्लॉक स्टोरेज सिस्टम है। मूल रूप से रैंचर लैब्स (अब एसयूएसई का हिस्सा) द्वारा विकसित, यह एक सीएनसीएफ इनक्यूबेटिंग प्रोजेक्ट है, जिसका उद्देश्य उन समूहों के लिए बनाया गया है जहां सादगी मायने रखती है लेकिन उत्पादन विश्वसनीयता पर समझौता नहीं किया जा सकता है। सेफ के विपरीत, जो समर्पित भंडारण नोड्स और गहरी विशेषज्ञता, या स्थानीय-पथ प्रावधानकर्ता की मांग करता है, जो शून्य अतिरेक प्रदान करता है, लॉन्गहॉर्न k3s क्लस्टर के लिए आवश्यक सटीक संतुलन बनाता है: नोड्स में वितरित प्रतिकृति, गतिशील वॉल्यूम विस्तार, क्लाउड ऑब्जेक्ट स्टोरेज के लिए एकीकृत बैकअप, स्नैपशॉट और डिजास्टर रिकवरी - सभी को एक स्वच्छ यूआई और Kubernetes-मूल CRDs के माध्यम से प्रबंधित किया जाता है।

यह मार्गदर्शिका उत्पादन के लिए k3s पर लॉन्गहॉर्न को तैनात करने के लिए आवश्यक सभी चीज़ों को शामिल करती है: आर्किटेक्चर आंतरिक, इंस्टॉलेशन विधियां, स्टोरेजक्लास कॉन्फ़िगरेशन, गतिशील PVC विस्तार, प्रतिकृति रणनीतियाँ, बैकअप और डिजास्टर रिकवरी, वॉल्यूम एन्क्रिप्शन, डेटाबेस के लिए प्रदर्शन ट्यूनिंग, निगरानी और समस्या निवारण। प्रत्येक अनुशंसा उत्पादन-परीक्षणित कॉन्फ़िगरेशन के साथ आती है जिसे आप अपने परिवेश के अनुसार अनुकूलित कर सकते हैं।

लॉन्गहॉर्न आर्किटेक्चर

प्रतिकृति, प्रदर्शन और विफलता प्रबंधन के बारे में सूचित निर्णय लेने के लिए लॉन्गहॉर्न की वास्तुकला को समझना आवश्यक है। लॉन्गहॉर्न तीन मुख्य घटकों से बना है जो आपके Kubernetes नोड्स से जुड़ी स्थानीय डिस्क के शीर्ष पर वितरित ब्लॉक स्टोरेज प्रदान करने के लिए एक साथ काम करते हैं।

लॉन्गहॉर्न मैनेजरक्लस्टर में प्रत्येक नोड पर डेमनसेट के रूप में चलता है। यह लॉन्गहॉर्न का नियंत्रण विमान है - यह API कॉल को संभालता है, वॉल्यूम निर्माण को व्यवस्थित करता है, प्रतिकृति का प्रबंधन करता है, स्नैपशॉट और बैकअप का समन्वय करता है, और PersistentVolume और PersistentVolumeClaim जीवनचक्र को प्रबंधित करने के लिए Kubernetes API सर्वर के साथ संचार करता है। जब आप एक PVC बनाते हैं जो लॉन्गहॉर्न स्टोरेजक्लास को संदर्भित करता है, तो लॉन्गहॉर्न मैनेजर सीएसआई ड्राइवर के माध्यम से अनुरोध प्राप्त करता है, वॉल्यूम का प्रावधान करता है, और उपलब्ध नोड्स में इसकी प्रतिकृतियां शेड्यूल करता है।

लॉन्गहॉर्न इंजनएक प्रति-वॉल्यूम स्टोरेज नियंत्रक है जिसे लिनक्स यूजरस्पेस प्रक्रिया (रंचर लॉन्गहॉर्न इंजन के एक कांटे पर आधारित) के रूप में कार्यान्वित किया जाता है। प्रत्येक वॉल्यूम की अपनी समर्पित इंजन प्रक्रिया उस नोड पर चलती है जहां वॉल्यूम जुड़ा हुआ है। इंजन उस वॉल्यूम के लिए सभी पढ़ने और लिखने वाले I/O को संभालता है, एप्लिकेशन पर लिखने को स्वीकार करने से पहले सभी कॉन्फ़िगर किए गए प्रतिकृतियों में समकालिक रूप से लिखने की प्रतिलिपि बनाता है। इस प्रति-वॉल्यूम आर्किटेक्चर का मतलब है कि एक वॉल्यूम के इंजन में क्रैश या हैंग किसी अन्य वॉल्यूम को प्रभावित नहीं करता है - उत्पादन के लिए एक महत्वपूर्ण अलगाव संपत्ति।

प्रतिकृतियांवास्तविक डेटा भंडारण प्रक्रियाएं हैं। प्रत्येक प्रतिकृति उस नोड की स्थानीय डिस्क पर वॉल्यूम डेटा की एक पूरी प्रतिलिपि संग्रहीत करती है जहां वह चलती है। डिफ़ॉल्ट रूप से, लॉन्गहॉर्न प्रत्येक वॉल्यूम के लिए तीन प्रतिकृतियां बनाता है, जो विभिन्न नोड्स (और वैकल्पिक रूप से अलग-अलग क्षेत्रों) में वितरित की जाती हैं। प्रतिकृतियां स्नैपशॉट के लिए कॉपी-ऑन-राइट तंत्र का उपयोग करती हैं, जिससे वॉल्यूम आकार की परवाह किए बिना स्नैपशॉट निर्माण तत्काल हो जाता है।

यह आर्किटेक्चर उत्पादन उपयोग के लिए कई प्रमुख गुण प्रदान करता है।दोष सहनशीलता:तीन नोड्स में तीन प्रतिकृतियों के साथ, वॉल्यूम एक साथ दो नोड विफलताओं से बच जाता है।अलगाव:प्रत्येक वॉल्यूम की अपनी इंजन प्रक्रिया होती है, इसलिए एक वॉल्यूम में बग या हैंग कैस्केड नहीं हो सकता है।सादगी:कोई समर्पित स्टोरेज नोड नहीं, कोई अलग सेफ या ग्लस्टरएफएस क्लस्टर नहीं - लॉन्गहॉर्न आपके एप्लिकेशन पॉड्स के समान वर्कर नोड्स पर अपने स्थानीय डिस्क का उपयोग करके चलता है।Kubernetes-नेटिव:सब कुछ CRDs, kubectl और Kubernetes CSI इंटरफ़ेस के माध्यम से प्रबंधित किया जाता है।

k3s

लॉन्गहॉर्न को k3s पर तीन तरीकों से स्थापित किया जा सकता है: Helm चार्ट (उत्पादन के लिए अनुशंसित), Rancher ऐप मार्केटप्लेस (यदि आपके पास 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.

इंस्टालेशन (अनुशंसित)

# 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 आपके k3s क्लस्टर का प्रबंधन करता है, तोऐप्स और amp पर नेविगेट करें। मार्केटप्लेस → चार्ट → रैंचर यूआई में लॉन्गहॉर्न। अपना लक्ष्य नामस्थान (longhorn-system) चुनें, फॉर्म इंटरफ़ेस के माध्यम से मान कॉन्फ़िगर करें, और इंस्टॉल पर क्लिक करें। रैंचर 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

पोस्ट-इंस्टॉलेशन: लॉन्गहॉर्न को डिफ़ॉल्ट स्टोरेजक्लास

# 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

स्टोरेजक्लास कॉन्फ़िगरेशन

डिफ़ॉल्ट लॉन्गहॉर्न स्टोरेजक्लास विकास के लिए काम करता है, लेकिन उत्पादन वर्कलोड को विभिन्न उपयोग के मामलों के लिए विशिष्ट कॉन्फ़िगरेशन की आवश्यकता होती है - डेटाबेस को उच्च प्रतिकृति और विशिष्ट डेटा इलाके की आवश्यकता होती है, अस्थायी प्रसंस्करण के लिए तेज़ एकल-प्रतिकृति वॉल्यूम की आवश्यकता होती है, और साझा वॉल्यूम को 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 विस्तार

लॉन्गहॉर्न की सबसे महत्वपूर्ण उत्पादन विशेषताओं में से एक गतिशील PVC विस्तार है - बिना डाउनटाइम के, बिना डेटा हानि के, और एक भी क्यूबेक्टल कमांड या मैनिफ़ेस्ट परिवर्तन से परे मैन्युअल हस्तक्षेप के बिना लगातार वॉल्यूम के आकार को बढ़ाने की क्षमता। यह उन डेटाबेस के लिए महत्वपूर्ण है जहां डेटा वृद्धि अप्रत्याशित है और डिस्क स्थान से बाहर होने का मतलब आउटेज है।

लॉन्गहॉर्नऑनलाइन विस्तार(वॉल्यूम बढ़ने पर संलग्न और माउंट रहता है) औरऑफ़लाइन विस्तार(वॉल्यूम पहले अलग हो जाता है) दोनों का समर्थन करता है। ऑनलाइन विस्तार उत्पादन के लिए डिफ़ॉल्ट और अनुशंसित दृष्टिकोण है क्योंकि यह एप्लिकेशन डाउनटाइम से बचाता है।

स्टोरेजक्लास

गतिशील PVC विस्तार के लिए मुख्य आवश्यकता यह है कि स्टोरेजक्लास मेंallowVolumeExpansion: trueहोना चाहिए। लॉन्गहॉर्न डिफ़ॉल्ट स्टोरेजक्लास में यह पहले से ही शामिल है, लेकिन यदि आपके पास कस्टम स्टोरेजक्लास हैं, तो सत्यापित करें कि यह फ़ील्ड सेट है।

# 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"

वॉल्यूम प्रतिकृति और डेटा स्थानीयता

लॉन्गहॉर्न हार्डवेयर विफलताओं से बचाने के लिए कई नोड्स में वॉल्यूम डेटा की नकल करता है। प्रतिकृति कारक और डेटा स्थानीयता सेटिंग्स स्थायित्व, प्रदर्शन और भंडारण दक्षता के बीच व्यापार-बंद को नियंत्रित करती हैं।

प्रतिकृति कारकनिर्धारित करता है कि डेटा की कितनी प्रतियां मौजूद हैं। डिफ़ॉल्ट 3 है, जिसका अर्थ है कि प्रत्येक लेखन तीन अलग-अलग नोड्स पर संग्रहीत है। उत्पादन डेटाबेस के लिए, 3 न्यूनतम अनुशंसित मान है। आप स्टोरेज बचाने के लिए कम महत्वपूर्ण कार्यभार के लिए इसे 2 पर सेट कर सकते हैं, या अस्थायी/कैश वॉल्यूम के लिए इसे 1 पर छोड़ सकते हैं जहां डेटा हानि स्वीकार्य है।

डेटा स्थानीयतानियंत्रित करता है कि क्या लॉन्गहॉर्न उसी नोड पर एक प्रतिकृति रखने की कोशिश करता है जिस पर पॉड वॉल्यूम का उपभोग करता है। तीन मोड हैं:

• अक्षम- प्रतिकृतियां पूरी तरह से उपलब्ध स्थान और एंटी-एफ़िनिटी के आधार पर निर्धारित की जाती हैं। पॉड किसी दूरस्थ नोड पर प्रतिकृति से पढ़ सकता है, जिससे प्रत्येक I/O ऑपरेशन में नेटवर्क विलंबता जुड़ जाती है।
• सर्वोत्तम प्रयास- लॉन्गहॉर्न उपभोक्ता पॉड के समान नोड पर एक प्रतिकृति रखने का प्रयास करता है। यदि स्थानीय नोड में जगह खत्म हो जाती है या पॉड माइग्रेट हो जाता है, तो वॉल्यूम अभी भी काम करता है लेकिन इसमें थोड़ी अधिक विलंबता हो सकती है। अधिकांश कार्यभार के लिए यह अनुशंसित सेटिंग है.
• सख्त-स्थानीय- वॉल्यूम का उपयोग केवल उस नोड पर किया जा सकता है जिसमें स्थानीय प्रतिकृति है। यदि पॉड को स्थानीय प्रतिकृति के बिना किसी नोड पर शेड्यूल किया गया है, तो वॉल्यूम अनुलग्नक विफल हो जाता है। इसका उपयोग केवल विलंबता-संवेदनशील एकल-प्रतिकृति वर्कलोड के लिए करें जहां आप स्थायित्व व्यापार-बंद स्वीकार करते हैं।

# 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

स्नैपशॉट और बैकअप

लॉन्गहॉर्न दो अलग डेटा सुरक्षा तंत्र प्रदान करता है:स्नैपशॉट(स्थानीय, तत्काल, त्वरित रोलबैक के लिए) औरबैकअप(दूरस्थ, ऑब्जेक्ट स्टोरेज के लिए, आपदा पुनर्प्राप्ति के लिए)। प्रत्येक का उपयोग कब करना है यह समझना महत्वपूर्ण है।

स्नैपशॉट को वॉल्यूम प्रतिकृतियों के समान डिस्क पर स्थानीय रूप से संग्रहीत किया जाता है। वे कॉपी-ऑन-राइट का उपयोग करके तुरंत बनाए जाते हैं - स्नैपशॉट समय पर कोई डेटा कॉपी नहीं किया जाता है, स्नैपशॉट के बाद केवल नए लिखने से अतिरिक्त स्थान आवंटित होता है। जोखिम भरे माइग्रेशन या परिनियोजन से पहले त्वरित रोलबैक के लिए स्नैपशॉट उत्कृष्ट हैं, लेकिन वे नोड या डिस्क विफलता से रक्षा नहीं करते हैं क्योंकि वे वॉल्यूम के समान स्टोरेज पर रहते हैं।

बैकअप वॉल्यूम डेटा को बाहरी बैकअप लक्ष्य - S3, GCS, Azure ब्लॉब, या किसी S3-संगत स्टोर (MinIO, वसाबी) पर कॉपी करते हैं। बैकअप ब्लॉक स्तर पर वृद्धिशील होते हैं: केवल वे ब्लॉक स्थानांतरित किए जाते हैं जो पिछले बैकअप के बाद से बदल गए हैं। यह आवर्ती बैकअप को तेज़ और भंडारण-कुशल बनाता है। बैकअप कुल क्लस्टर हानि से बचाते हैं क्योंकि वे स्वतंत्र रूप से मौजूद होते हैं।

बैकअप लक्ष्य

# 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

वॉल्यूमस्नैपशॉट क्लास और स्नैपशॉट 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

आपदा पुनर्प्राप्ति

लॉन्गहॉर्न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

वॉल्यूम एन्क्रिप्शन

लॉन्गहॉर्न 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)

डिफ़ॉल्ट रूप से, लॉन्गहॉर्न वॉल्यूम ReadWriteOnce (RWO) हैं - उन्हें एक नोड पर एक पॉड द्वारा माउंट किया जा सकता है। ऐसे वर्कलोड के लिए जिन्हें कई पॉड्स में साझा भंडारण की आवश्यकता होती है (उदाहरण के लिए, साझा मीडिया अपलोड, कॉन्फ़िगरेशन फ़ाइलें, एमएल मॉडल आर्टिफैक्ट), लॉन्गहॉर्न एक एकीकृत एनएफएस सर्वर के माध्यम से ReadWriteMany (RWX) का समर्थन करता है।

जब PVC RWX एक्सेस मोड का अनुरोध करता है, तो लॉन्गहॉर्न स्वचालित रूप से एक शेयर-मैनेजर पॉड तैनात करता है जो लॉन्गहॉर्न वॉल्यूम द्वारा समर्थित 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

डेटाबेस वर्कलोड

लॉन्गहॉर्न पर डेटाबेस चलाने के लिए स्टोरेजक्लास पैरामीटर, पॉड एफ़िनिटी और बैकअप एकीकरण पर सावधानीपूर्वक ध्यान देने की आवश्यकता होती है। लॉन्गहॉर्न का प्रति-वॉल्यूम इंजन और सिंक्रोनस प्रतिकृति इसे डेटाबेस वर्कलोड के लिए उपयुक्त बनाती है, लेकिन उत्पादन-ग्रेड प्रदर्शन और विश्वसनीयता प्राप्त करने के लिए आपको इसे सही ढंग से कॉन्फ़िगर करने की आवश्यकता है।

लॉन्गहॉर्न

PostgreSQL स्टेटफुलसेट

# 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 स्टेटफुलसेट

# 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

डेटाबेस वर्कलोड

प्रदर्शन ट्यूनिंग

लॉन्गहॉर्न एप्लिकेशन और भौतिक डिस्क के बीच एक स्टोरेज प्रतिकृति परत जोड़ता है, जो प्रत्यक्ष स्थानीय डिस्क एक्सेस की तुलना में कुछ विलंबता का परिचय देता है। अधिकांश कार्यभार के लिए यह ओवरहेड नगण्य है, लेकिन भारी लेखन पैटर्न वाले डेटाबेस कार्यभार को इष्टतम प्रदर्शन प्राप्त करने के लिए ट्यूनिंग की आवश्यकता होती है।

डेटा इलाके का उपयोग करें: सर्वोत्तम प्रयास।यह सुनिश्चित करता है कि एक प्रतिकृति डेटाबेस पॉड के समान नोड पर है, जिसका अर्थ है एनवीएमई/एसएसडी गति पर हिट स्थानीय डिस्क को पढ़ता है। राइट्स अभी भी दूरस्थ नोड्स की प्रतिकृति बनाते हैं, लेकिन स्थानीय प्रतिकृति पढ़ने के लिए नेटवर्क राउंड-ट्रिप को समाप्त कर देती है।

लॉन्गहॉर्न को डिस्क समर्पित करें।OS डिस्क को लॉन्गहॉर्न डेटा के साथ साझा न करें। समर्पित NVMe या SSD ड्राइव जोड़ें और उन्हें लॉन्गहॉर्न डिस्क के रूप में कॉन्फ़िगर करें। यह ऑपरेटिंग सिस्टम और डेटाबेस वॉल्यूम के बीच 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 सेट करें।लॉन्गहॉर्न की इंजन प्रक्रियाएं I/O प्रसंस्करण और प्रतिकृति के लिए CPU का उपभोग करती हैं।guaranteedInstanceManagerCPUसेटिंग लॉन्गहॉर्न इंस्टेंस प्रबंधकों के लिए नोड CPU का एक प्रतिशत आरक्षित रखती है, जिससे लोड के तहत CPU भुखमरी को रोका जा सकता है।

प्रतिकृति गणना को ट्यून करें।उन डेटाबेस के लिए जिनमें पहले से ही एप्लिकेशन-स्तरीय प्रतिकृति (PostgreSQL स्ट्रीमिंग प्रतिकृति, MySQL समूह प्रतिकृति, MongoDB प्रतिकृति सेट) है, आप लॉन्गहॉर्न प्रतिकृति गिनती को 3 के बजाय 2 तक कम कर सकते हैं। डेटाबेस की स्वयं की प्रतिकृति डेटा सुरक्षा की एक अतिरिक्त परत प्रदान करती है, और कम लॉन्गहॉर्न प्रतिकृतियों का मतलब कम लेखन प्रवर्धन और बेहतर लेखन थ्रूपुट है।

छोटे यादृच्छिक I/O के लिए xfs पर ext4 का उपयोग करें।जबकि xfs बड़े अनुक्रमिक लेखन में उत्कृष्टता प्राप्त करता है, ext4 आम तौर पर डेटाबेस वर्कलोड के विशिष्ट छोटे यादृच्छिक I/O पैटर्न के लिए बेहतर प्रदर्शन करता है। अपने स्टोरेज क्लास मेंfsType: ext4सेट करें।

नोड शेड्यूलिंग और डिस्क प्रबंधन

लॉन्गहॉर्न सूक्ष्म नियंत्रण प्रदान करता है जिस पर वॉल्यूम शेड्यूलिंग के लिए नोड्स और डिस्क का उपयोग किया जाता है। यह विषम समूहों में महत्वपूर्ण है जहां कुछ नोड्स में तेज़ 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 मेट्रिक्स को उजागर करता है। क्षमता नियोजन, प्रदर्शन विश्लेषण और सक्रिय चेतावनी के लिए इन मेट्रिक्स की निगरानी आवश्यक है।

# 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 }}"

लॉन्गहॉर्न मॉनिटरिंग के लिए बनाए जाने वाले

कुंजी Grafana डैशबोर्ड पैनल में शामिल हैं: वॉल्यूम IOPS (पढ़ें/लिखें), वॉल्यूम थ्रूपुट (MB/s), वॉल्यूम विलंबता (p50/p95/p99), प्रतिकृति पुनर्निर्माण प्रगति, नोड भंडारण क्षमता और उपयोग, बैकअप स्थिति और आयु, और प्रति वॉल्यूम स्नैपशॉट गिनती।

संपूर्ण लॉन्गहॉर्न स्टोरेज स्टैक के साथ

k3s क्लस्टर

निम्नलिखित आरेख दिखाता है कि लॉन्गहॉर्न कैसे रैंचर प्रबंधन और Prometheus/Grafana अवलोकन के साथ, नंगे धातु सर्वर से लेकर एप्लिकेशन पॉड्स तक संपूर्ण k3s उत्पादन स्टैक में फिट बैठता है।

की तुलना अन्य Kubernetes स्टोरेज सॉल्यूशंस

लॉन्गहॉर्न Kubernetes के लिए एकमात्र भंडारण विकल्प नहीं है। यह समझना कि यह विकल्पों से कैसे तुलना करता है, आपको अपनी विशिष्ट आवश्यकताओं के लिए सही विकल्प चुनने में मदद करता है।

लॉन्गहॉर्न बनाम रूक-सेफ:सेफ अधिक शक्तिशाली प्रणाली है - यह एक परिष्कृत क्रश प्लेसमेंट एल्गोरिदम के साथ ऑब्जेक्ट स्टोरेज, फ़ाइल स्टोरेज और ब्लॉक स्टोरेज का समर्थन करता है। हालाँकि, सेफ कम से कम 3 समर्पित ओएसडी नोड्स, महत्वपूर्ण रैम (न्यूनतम 4 जीबी प्रति ओएसडी डेमॉन), और गहन परिचालन विशेषज्ञता की मांग करता है। 3-10 नोड्स वाले k3s क्लस्टर के लिए, लॉन्गहॉर्न परिचालन लागत के 10% पर 90% मूल्य प्रदान करता है।

लॉन्गहॉर्न बनाम ओपनईबीएस मेयस्टोर:मेयस्टोर उच्च-प्रदर्शन प्रतिकृति के लिए NVMe-ओवर-फैब्रिक्स का उपयोग करता है, जो लॉन्गहॉर्न की टीसीपी-आधारित प्रतिकृति की तुलना में कम विलंबता प्राप्त करता है। यदि कच्चा IOPS और उप-मिलीसेकंड विलंबता आपकी प्राथमिक चिंता है और आपके पास RDMA नेटवर्किंग के साथ NVMe बुनियादी ढांचा है, तो मायास्टोर बेहतर विकल्प हो सकता है। अधिकांश k3s परिनियोजन के लिए, लॉन्गहॉर्न का एकीकृत बैकअप, DR, और परिचालन सरलता मायास्टोर के प्रदर्शन में बढ़त से अधिक है।

लॉन्गहॉर्न बनाम स्थानीय-पथ:स्थानीय-पथ प्रावधानकर्ता k3s का डिफ़ॉल्ट भंडारण है - यह बस नोड के स्थानीय फाइल सिस्टम पर निर्देशिका बनाता है। शून्य प्रतिकृति, शून्य स्नैपशॉट, शून्य बैकअप एकीकरण। यह विकास के लिए ठीक है लेकिन उत्पादन डेटा के लिए अस्वीकार्य है।

उत्पादन सर्वोत्तम अभ्यास

ये सिफ़ारिशें डेटाबेस वर्कलोड चलाने वाले दर्जनों उत्पादन k3s क्लस्टरों में लॉन्गहॉर्न के संचालन से प्राप्त हुई हैं।

1. उदाहरण प्रबंधकों के लिए संसाधन आरक्षण सेट करें।लॉन्गहॉर्न इंस्टेंस प्रबंधकों (इंजन और प्रतिकृति प्रबंधकों) को नोड दबाव के दौरान I/O स्टालों से बचने के लिए गारंटीकृत CPU की आवश्यकता होती है। लॉन्गहॉर्न सेटिंग मेंguaranteedInstanceManagerCPUको कम से कम 12% पर सेट करें।

2. डेटाबेस वॉल्यूम के लिए रिटेन रिक्लेम पॉलिसी का उपयोग करें।डेटाबेस PVCs के लिए कभी भीDeleteका उपयोग न करें।Retainनीति PVC हटाए जाने के बाद भी पीवी और उसके डेटा को बनाए रखती है, जिससे आपको आकस्मिक विलोपन के खिलाफ सुरक्षा मिलती है।

3. उत्पादन के लिए प्रतिकृति नरम एंटी-एफ़िनिटी अक्षम करें। यह सुनिश्चित करने के लिए कि प्रतिकृतियां हमेशा विभिन्न नोड्स में फैली हुई हैं,replicaSoftAntiAffinity: falseसेट करें। नरम एंटी-एफ़िनिटी के साथ, लॉन्गहॉर्न स्थान की कमी होने पर एक ही नोड पर कई प्रतिकृतियां शेड्यूल कर सकता है - जिससे प्रतिकृति का उद्देश्य विफल हो जाता है।

4. प्रत्येक नोड पर भंडारण स्थान आरक्षित करें।storageMinimalAvailablePercentageको कम से कम 15% पर सेट करें। यह लॉन्गहॉर्न को सभी डिस्क स्थान का उपभोग करने से रोकता है, जिससे सभी पॉड्स को प्रभावित करने वाले नोड-स्तरीय समस्याएं पैदा होंगी।

5. स्वतः-बचाव सक्षम करें।autoSalvageसेटिंग स्वचालित रूप से उन वॉल्यूम को पुनर्प्राप्त करती है जो दोषपूर्ण स्थिति में प्रवेश करती हैं जब कम से कम एक प्रतिकृति अभी भी स्वस्थ होती है। यह नोड विफलताओं के दौरान मैन्युअल हस्तक्षेप को कम करता है।

6. प्राथमिकता वर्ग को सिस्टम-क्लस्टर-क्रिटिकल पर सेट करें।लॉन्गहॉर्न के प्रबंधक और ड्राइवर घटकों को नोड दबाव के दौरान कभी भी बेदखल नहीं किया जाना चाहिए। यह सुनिश्चित करने के लिए कि वे पॉड निष्कासन से बचे रहें, उनकी प्राथमिकता क्लास कोsystem-cluster-criticalपर सेट करें।

7. सभी उत्पादन संस्करणों के लिए आवर्ती नौकरियों को कॉन्फ़िगर करें।प्रत्येक उत्पादन वॉल्यूम में स्नैपशॉट और बैकअप आवर्ती कार्य दोनों होने चाहिए। त्वरित रोलबैक के लिए हर 4 घंटे में स्नैपशॉट, आपदा पुनर्प्राप्ति के लिए दैनिक बैकअप।

8. नियमित रूप से डीआर वॉल्यूम सक्रियण का परीक्षण करें।अपने स्टैंडबाय क्लस्टर में डीआर वॉल्यूम को सक्रिय करने, डेटा अखंडता को सत्यापित करने और फेलओवर प्रक्रिया का अभ्यास करने के लिए एक मासिक शेड्यूल बनाएं। एक डीआर योजना जिसका कभी परीक्षण नहीं किया गया वह केवल दस्तावेज़ीकरण है।

9. वॉल्यूम स्वास्थ्य की सक्रियता से निगरानी करें।खराब और दोषपूर्ण वॉल्यूम, नोड भंडारण क्षमता, बैकअप आयु और प्रतिकृति पुनर्निर्माण स्थिति के लिए Prometheus अलर्ट सेट करें। जब तक कोई उपयोगकर्ता धीमे डेटाबेस की रिपोर्ट करता है, तब तक भंडारण की समस्या घंटों तक बनी रहती है।

10. समर्पित स्टोरेज डिस्क का उपयोग करें।लॉन्गहॉर्न डेटा को OS डिस्क से अलग करें। यह I/O विवाद को रोकता है, आपको स्वच्छ क्षमता प्रबंधन प्रदान करता है, और OS डिस्क को लॉन्गहॉर्न डेटा से भरने के जोखिम से बचाता है।

क्लाउड-विशिष्ट परिनियोजन मार्गदर्शन

AWS — EC2 NVMe इंस्टेंस स्टोरेज के साथ

AWS परिनियोजन के लिए,i3.xlargeयाi3en.xlargeइंस्टेंसेस का उपयोग करें जो NVMe इंस्टेंस स्टोरेज के साथ आते हैं। ये प्रावधानित ईबीएस आईओपीएस की लागत के एक अंश पर कच्चा एनवीएमई प्रदर्शन प्रदान करते हैं। इंस्टेंस स्टोरेज को फॉर्मेट करें और इसे लॉन्गहॉर्न डिस्क के रूप में कॉन्फ़िगर करें।

# 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 - अल्ट्रा डिस्क

Azure पर, स्थानीय NVMe स्टोरेज के साथStandard_L8s_v3याStandard_L16s_v3VM का उपयोग करें। वैकल्पिक रूप से, लगातार उप-मिलीसेकंड विलंबता के लिए अल्ट्रा डिस्क संलग्न करें। अल्ट्रा डिस्क आपको 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 - स्थानीय SSD

GCPn2-standardयाc3-standardVMs से जुड़ा स्थानीय SSD प्रदान करता है। स्थानीय एसएसडी 680,000 रीड आईओपीएस के साथ प्रति डिस्क 375 जीबी प्रदान करते हैं। एकाधिक स्थानीय SSDs संलग्न करें और बड़ी मात्रा के लिए उन पर 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 ड्राइव वाले सर्वर का उपयोग करें। ओएस डिस्क को स्टोरेज डिस्क से अलग करें। यह सुनिश्चित करने के लिए कि प्रतिकृति ट्रैफ़िक बाधित न हो, नोड्स के बीच 10GbE या 25GbE नेटवर्क का उपयोग करें - लॉन्गहॉर्न सिंक्रोनस प्रतिकृति, प्रतिकृति गणना द्वारा गुणा किए गए थ्रूपुट को लिखने के लिए आनुपातिक रूप से नेटवर्क ट्रैफ़िक उत्पन्न करती है।

# 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

लॉन्गहॉर्न यूआई वॉकथ्रू

लॉन्गहॉर्न एक अंतर्निर्मित वेब यूआई के साथ आता है जो वॉल्यूम, स्नैपशॉट, बैकअप, नोड्स और सेटिंग्स को प्रबंधित करने के लिए एक विज़ुअल इंटरफ़ेस प्रदान करता है। इंस्टालेशन के दौरान कॉन्फ़िगर किए गए इनग्रेस के माध्यम से या कुबेक्टल पोर्ट-फॉरवर्ड के माध्यम से इसे एक्सेस करें।

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

यूआई कई प्रमुख दृश्य प्रदान करता है:डैशबोर्डकुल क्षमता, प्रयुक्त स्थान और वॉल्यूम स्थिति सहित क्लस्टर-व्यापी भंडारण स्वास्थ्य दिखाता है।वॉल्यूमसभी वॉल्यूम को उनकी स्थिति (स्वस्थ/विघटित/दोषपूर्ण), आकार, प्रतिकृति गणना और संलग्न नोड के साथ सूचीबद्ध करता है। आप इस दृश्य से सीधे वॉल्यूम का विस्तार, स्नैपशॉट, बैकअप और पुनर्स्थापित कर सकते हैं।नोडप्रत्येक नोड के स्टोरेज कॉन्फ़िगरेशन, डिस्क आवंटन और शेड्यूलिंग स्थिति को दिखाता है।बैकअपबैकअप लक्ष्य में संग्रहीत सभी बैकअप को उनकी मात्रा, आकार और निर्माण समय के साथ सूचीबद्ध करता है।सेटिंगविवरण के साथ सभी लॉन्गहॉर्न कॉन्फ़िगरेशन मापदंडों को उजागर करता है।

सामान्य समस्याओं का निवारण

डिग्रेडेड वॉल्यूम

एक वॉल्यूम ख़राब स्थिति में प्रवेश करता है जब एक या अधिक प्रतिकृतियां अस्वस्थ होती हैं लेकिन वॉल्यूम अभी भी कार्यात्मक होता है। सामान्य कारणों में नोड विफलता, डिस्क पूर्ण होना, या नेटवर्क विभाजन शामिल हैं।

# 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

अपग्रेड प्रक्रियाएं

लॉन्गहॉर्न अपग्रेड सावधानी से किया जाना चाहिए, क्योंकि स्टोरेज सिस्टम सभी स्टेटफुल वर्कलोड को रेखांकित करता है। अपग्रेड करने से पहले हमेशा सभी महत्वपूर्ण वॉल्यूम का बैकअप लें।

# 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 डेटाबेस ऑपरेटर (क्लाउडनेटिवपीजी, पेरकोना ऑपरेटर, ज़ालैंडो Postgres ऑपरेटर) लॉन्गहॉर्न के साथ निर्बाध रूप से काम करते हैं। ऑपरेटर डेटाबेस जीवनचक्र का प्रबंधन करता है जबकि लॉन्गहॉर्न प्रतिकृति, स्नैपशॉट और बैकअप के साथ अंतर्निहित भंडारण प्रदान करता है।

# 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

निष्कर्ष

लॉन्गहॉर्न k3s को एक हल्के Kubernetes वितरण से बदल देता है जो केवल बढ़त और विकास के लिए उपयुक्त उत्पादन-तैयार प्लेटफ़ॉर्म में मिशन-महत्वपूर्ण स्टेटफुल वर्कलोड चलाने में सक्षम है। इसका आर्किटेक्चर - प्रति-वॉल्यूम इंजन, सिंक्रोनस मल्टी-नोड प्रतिकृति, एकीकृत स्नैपशॉट और क्लाउड ऑब्जेक्ट स्टोरेज के लिए बैकअप, डीआर वॉल्यूम, वॉल्यूम एन्क्रिप्शन और ऑनलाइन PVC विस्तार - एंटरप्राइज़-ग्रेड जटिलता के बिना एंटरप्राइज़-ग्रेड स्टोरेज प्रदान करता है।

उत्पादन में लॉन्गहॉर्न के साथ सफलता की कुंजी तीन गुना है। सबसे पहले, इसे शुरू से ही ठीक से कॉन्फ़िगर करें: समर्पित स्टोरेज डिस्क का उपयोग करें, उचित प्रतिकृति कारक और डेटा स्थानीयता सेट करें, और विभिन्न कार्यभार प्रकारों के लिए उद्देश्य-निर्मित स्टोरेजक्लास बनाएं। दूसरा, पहले दिन से ही अपने आर्किटेक्चर में बैकअप को एकीकृत करें: तेज़ रोलबैक के लिए आवर्ती स्नैपशॉट, आपदा पुनर्प्राप्ति के लिए S3/GCS/Azure के लिए दैनिक बैकअप, और सबसे खराब स्थिति के लिए स्टैंडबाय क्लस्टर में DR वॉल्यूम। तीसरा, हर चीज की निगरानी करें: वॉल्यूम स्वास्थ्य, नोड भंडारण क्षमता, बैकअप आयु, और प्रतिकृति पुनर्निर्माण स्थिति - भंडारण की समस्याएं तब तक अदृश्य रहती हैं जब तक कि वे भयावह न हो जाएं।

डायनामिक PVC विस्तार उत्पादन घटनाओं के सबसे आम स्रोतों में से एक को समाप्त करता है - डिस्क स्थान से बाहर होना। लॉन्गहॉर्न के साथ, डेटाबेस वॉल्यूम को 50Gi से 500Gi तक विस्तारित करना शून्य डाउनटाइम के साथ एक एकल kubectl कमांड है। क्षमता सीमा पर Prometheus अलर्ट के साथ संयुक्त, आप वॉल्यूम के गंभीर होने से पहले सक्रिय रूप से विस्तार कर सकते हैं, या विस्तार को पूरी तरह से स्वचालित कर सकते हैं।

चाहे आप PostgreSQL, MySQL, MongoDB, या Redis को k3s पर चला रहे हों - बेयर मेटल सर्वर, AWS EC2, Azure VMs, GCP इंस्टेंसेस, या ऑन-प्रिमाइसेस डेटासेंटर हार्डवेयर पर - लॉन्गहॉर्न स्टोरेज फाउंडेशन प्रदान करता है जो आपको डेटा स्थायित्व के बारे में चिंता करने के बजाय अपने अनुप्रयोगों पर ध्यान केंद्रित करने देता है। इसे स्थापित करें, इसे कॉन्फ़िगर करें, इसकी निगरानी करें और अपने उत्पादन डेटा पर इस पर भरोसा करें।