پیداوار k3s کلسٹرز کے لیے Longhorn Storage: Dynamic PVC توسیع، نقل، اور ڈیزاسٹر ریکوری

اسٹوریج Kubernetes میں سب سے مشکل مسئلہ ہے۔ کمپیوٹ بے وطن اور فنگیبل ہے - ایک پوڈ کو مار ڈالو، دوسرا شیڈول کریں۔ نیٹ ورکنگ میں بالغ CNI پلگ ان اور سروس میشز ہیں۔ لیکن اسٹوریج؟ سٹوریج وہ جگہ ہے جہاں ریاست رہتی ہے، جہاں ڈیٹا دوبارہ شروع ہونے کے دوران برقرار رہتا ہے، جہاں ایک غلط کنفیگریشن کا مطلب ڈیٹا کا مستقل نقصان ہو سکتا ہے۔ پروڈکشن ورک بوجھ چلانے والے k3s کلسٹرز کے لیے — ڈیٹا بیس، پیغام کی قطاریں، ایپلیکیشن اسٹیٹ — آپ کو ذخیرہ کرنے کے حل کی ضرورت ہے جو تقسیم شدہ، لچکدار، قابل توسیع، اور قابل عمل ہو۔ Longhorn وہ حل ہے.

Longhorn Kubernetes کے لیے ایک ہلکا پھلکا، قابل اعتماد، اور استعمال میں آسان تقسیم شدہ بلاک اسٹوریج سسٹم ہے۔ اصل میں Rancher Labs (اب SUSE کا حصہ) کی طرف سے تیار کیا گیا ہے، یہ ایک CNCF انکیوبٹنگ پراجیکٹ ہے جس کا مقصد کلسٹرز کے لیے بنایا گیا ہے جہاں سادگی اہمیت رکھتی ہے لیکن پیداوار کی بھروسے کے قابل نہیں ہے۔ Ceph کے برعکس، جو ڈیڈیکیٹڈ سٹوریج نوڈس اور گہری مہارت کا مطالبہ کرتا ہے، یا لوکل پاتھ پروویژنر، جو صفر فالتو پن پیش کرتا ہے، لانگ ہارن k3s کلسٹرز کی ضرورت کے عین مطابق توازن کو پورا کرتا ہے: تمام نوڈس میں تقسیم شدہ نقل، متحرک حجم کی توسیع، کلاؤڈ آبجیکٹ اسٹوریج کے لیے مربوط بیک اپ، اسنیپ شاٹ اور کلین UI کا انتظام کرنے کے ذریعے سب کو صاف کرنا۔ Kubernetes- مقامی CRDs۔

یہ گائیڈ ہر وہ چیز کا احاطہ کرتا ہے جس کی آپ کو پیداوار کے لیے k3s پر Longhorn کو تعینات کرنے کی ضرورت ہے: فن تعمیر کے انٹرنل، انسٹالیشن کے طریقے، StorageClass کنفیگریشن، متحرک PVC توسیع، نقل کی حکمت عملی، بیک اپ اور ڈیزاسٹر ریکوری، والیوم انکرپشن، پرفارمنس ٹیوننگ اور ڈیٹا بیسز کی نگرانی، پریشانیوں کی نگرانی۔ ہر سفارش پروڈکشن کی جانچ کی گئی ترتیب کے ساتھ آتی ہے جسے آپ اپنے ماحول کے مطابق ڈھال سکتے ہیں۔

لانگ ہارن آرکیٹیکچر

نقل، کارکردگی، اور ناکامی سے نمٹنے کے بارے میں باخبر فیصلے کرنے کے لیے Longhorn کے فن تعمیر کو سمجھنا ضروری ہے۔ Longhorn تین بنیادی اجزاء پر مشتمل ہے جو آپ کے Kubernetes نوڈس سے منسلک مقامی ڈسکوں کے اوپر تقسیم شدہ بلاک اسٹوریج فراہم کرنے کے لیے مل کر کام کرتے ہیں۔

لانگ ہارن مینیجرکلسٹر میں ہر نوڈ پر ڈیمون سیٹ کے طور پر چلتا ہے۔ یہ Longhorn کا کنٹرول طیارہ ہے — یہ API کالز کو ہینڈل کرتا ہے، حجم کی تخلیق کو منظم کرتا ہے، نقل کا انتظام کرتا ہے، اسنیپ شاٹس اور بیک اپ کو مربوط کرتا ہے، اور Kubernetes API سرور کے ساتھ Persistent Volume اور PersistentVolumeClaim لائف سائیکل کو منظم کرنے کے لیے بات چیت کرتا ہے۔ جب آپ ایک PVC بناتے ہیں جو Longhorn StorageClass کا حوالہ دیتا ہے، Longhorn مینیجر CSI ڈرائیور کے ذریعے درخواست وصول کرتا ہے، حجم کا بندوبست کرتا ہے، اور دستیاب نوڈس میں اس کی نقلیں ترتیب دیتا ہے۔

Longhorn Engineایک فی والیوم اسٹوریج کنٹرولر ہے جسے لینکس یوزر اسپیس پروسیس کے طور پر لاگو کیا جاتا ہے (رینچر لانگ ہارن انجن کے کانٹے پر مبنی)۔ ہر والیوم کو اس نوڈ پر انجن کا اپنا مخصوص عمل ملتا ہے جہاں والیوم منسلک ہوتا ہے۔ انجن اس والیوم کے لیے تمام پڑھنے اور لکھنے والے I/O کو ہینڈل کرتا ہے، ایپلی کیشن میں لکھنے کو تسلیم کرنے سے پہلے تمام کنفیگر شدہ ریپلیکا کے ساتھ مطابقت پذیری سے تحریروں کی نقل تیار کرتا ہے۔ اس فی والیوم آرکیٹیکچر کا مطلب ہے کہ ایک والیوم کے انجن میں کریش یا لٹکنا کسی دوسرے حجم کو متاثر نہیں کرتا ہے - پیداوار کے لیے ایک اہم تنہائی کی خاصیت۔

Replicasاصل ڈیٹا ذخیرہ کرنے کے عمل ہیں۔ ہر نقل نوڈ کی مقامی ڈسک پر والیوم ڈیٹا کی ایک مکمل کاپی اسٹور کرتی ہے جہاں یہ چلتا ہے۔ پہلے سے طے شدہ طور پر، Longhorn ہر والیوم کے لیے تین نقلیں بناتا ہے، جو مختلف نوڈس (اور اختیاری طور پر مختلف زونز) میں تقسیم ہوتے ہیں۔ نقلیں اسنیپ شاٹس کے لیے کاپی آن رائٹ میکانزم کا استعمال کرتی ہیں، حجم کے سائز سے قطع نظر اسنیپ شاٹ کی تخلیق کو فوری بناتی ہے۔

یہ فن تعمیر پیداوار کے استعمال کے لیے کئی کلیدی خصوصیات فراہم کرتا ہے۔فالٹ ٹولرنس:تین نوڈس میں تین نقلوں کے ساتھ، حجم دو بیک وقت نوڈ کی ناکامیوں سے بچ جاتا ہے۔تنہائی:ہر والیوم کا اپنا انجن کا عمل ہوتا ہے، اس لیے ایک والیوم میں بگ یا ہینگ جھڑنا نہیں جا سکتا۔سادگی:کوئی وقف شدہ سٹوریج نوڈس نہیں، کوئی علیحدہ Ceph یا GlusterFS کلسٹرز نہیں — Longhorn ان ہی ورکر نوڈس پر چلتا ہے جیسے آپ کی ایپلیکیشن پوڈز، اپنی مقامی ڈسکوں کا استعمال کرتے ہوئے۔Kubernetes- مقامی:ہر چیز کا نظم CRDs، kubectl، اور Kubernetes CSI انٹرفیس کے ذریعے کیا جاتا ہے۔

k3s

Longhorn k3s پر تین طریقوں سے انسٹال کیا جا سکتا ہے: 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

انسٹالیشن

اگر رینچر آپ کے k3s کلسٹر کا انتظام کرتا ہے، توایپس پر جائیں اور رینچر UI میں مارکیٹ پلیس → چارٹس → Longhorn۔ اپنی ٹارگٹ نیم اسپیس (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

StorageClass کنفیگریشن برائے پیداوار

ڈیفالٹ 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آن لائن توسیع(حجم منسلک رہتا ہے اور بڑھتا ہے) اورآف لائن توسیع(حجم پہلے الگ ہوتا ہے) دونوں کو سپورٹ کرتا ہے۔ آن لائن توسیع پروڈکشن کے لیے پہلے سے طے شدہ اور تجویز کردہ طریقہ ہے کیونکہ یہ ایپلیکیشن ڈاؤن ٹائم سے بچتا ہے۔

StorageClas

متحرک PVC توسیع کے لیے اہم ضرورت یہ ہے کہ StorageClass میںallowVolumeExpansion: trueہونا ضروری ہے۔ Longhorn ڈیفالٹ StorageClass میں پہلے سے ہی یہ شامل ہے، لیکن اگر آپ کے پاس حسب ضرورت 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 پر چھوڑ سکتے ہیں جہاں ڈیٹا کا نقصان قابل قبول ہو۔

ڈیٹا لوکلٹیکنٹرول کرتا ہے کہ آیا لانگ ہارن ایک ریپلیکا کو اسی نوڈ پر رکھنے کی کوشش کرتا ہے جس طرح پوڈ والیوم استعمال کرتا ہے۔ تین طریقے ہیں:

• غیر فعال— نقلیں مکمل طور پر دستیاب جگہ اور اینٹی وابستگی کی بنیاد پر ترتیب دی گئی ہیں۔ پوڈ ریموٹ نوڈ پر نقل سے پڑھ سکتا ہے، ہر 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

سنیپ شاٹس اور بیک اپ

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

والیوم اسنیپ شاٹ کلاس اور سنیپ شاٹ 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

ڈیزاسٹر ریکوری

LonghornDR والیومکے ذریعے ڈیزاسٹر ریکوری میکانزم فراہم کرتا ہے - ثانوی کلسٹر میں اسٹینڈ بائی والیوم جو بنیادی کلسٹر کے بیک اپ ٹارگٹ سے مسلسل اضافی بیک اپ کھینچتا ہے۔ جب آفت آتی ہے، تو آپ 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 ایک مربوط NFS سرور کے ذریعے ReadWriteMany (RWX) کو سپورٹ کرتا ہے۔

جب ایک PVC RWX رسائی موڈ کی درخواست کرتا ہے، لانگ ہارن خود بخود ایک شیئر مینیجر پوڈ تعینات کرتا ہے جو لانگ ہارن والیوم کی حمایت سے NFS سرور چلاتا ہے۔ ایک سے زیادہ پوڈز پھر حجم کو بیک وقت 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

ڈیٹا بیس ورک بوجھ لانگ ہارن پر

چلانے والے ڈیٹا بیس کے لیے StorageClass کے پیرامیٹرز، pod affinity، اور بیک اپ انٹیگریشن پر محتاط توجہ کی ضرورت ہے۔ لانگ ہارن کا فی والیوم انجن اور ہم وقت ساز نقل اسے ڈیٹا بیس کے کام کے بوجھ کے لیے موزوں بناتی ہے، لیکن آپ کو پروڈکشن گریڈ کی کارکردگی اور قابل اعتماد حاصل کرنے کے لیے اسے درست طریقے سے ترتیب دینے کی ضرورت ہے۔

لانگ ہارن

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

ڈیٹا بیس ورک بوجھ کے لیے

پرفارمنس ٹیوننگ

Longhorn ایپلی کیشن اور فزیکل ڈسک کے درمیان ایک سٹوریج ریپلیکیشن پرت کا اضافہ کرتا ہے، جو براہ راست مقامی ڈسک تک رسائی کے مقابلے میں کچھ تاخیر کا تعارف کراتی ہے۔ زیادہ تر کام کے بوجھ کے لیے یہ اوور ہیڈ نہ ہونے کے برابر ہے، لیکن بھاری تحریری نمونوں کے ساتھ ڈیٹا بیس کے کام کے بوجھ کو بہترین کارکردگی حاصل کرنے کے لیے ٹیوننگ کی ضرورت ہوتی ہے۔

ڈیٹا لوکلٹی کا استعمال کریں: بہترین کوشش۔یہ یقینی بناتا ہے کہ ایک نقل اسی نوڈ پر ہے جس میں ڈیٹا بیس پوڈ ہے، یعنی NVMe/SSD کی رفتار سے ہٹ لوکل ڈسک پڑھتا ہے۔ تحریریں اب بھی ریموٹ نوڈس پر نقل کرتی ہیں، لیکن مقامی نقل پڑھنے کے لیے نیٹ ورک راؤنڈ ٹرپس کو ختم کرتی ہے۔

لانگ ہارن کو ڈسکیں وقف کریں۔لانگ ہارن ڈیٹا کے ساتھ OS ڈسک کا اشتراک نہ کریں۔ وقف شدہ 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 کے انجن کے عمل I/O پروسیسنگ اور نقل کے لیے CPU استعمال کرتے ہیں۔guaranteedInstanceManagerCPUسیٹنگ لانگ ہارن مثال کے مینیجرز کے لیے نوڈ CPU کا فیصد محفوظ رکھتی ہے، CPU کو بوجھ کے نیچے بھوک سے روکتی ہے۔

نقل کی گنتی کو ٹیون کریں۔ایسے ڈیٹا بیسز کے لیے جن کے پاس پہلے سے ہی ایپلیکیشن لیول ریپلیکیشن ہے (PostgreSQL سٹریمنگ ریپلیکیشن، MySQL گروپ ریپلیکیشن، MongoDB ریپلیکا سیٹ)، آپ لانگ ہارن ریپلیکا کی گنتی کو 3 کے بجائے 2 تک کم کر سکتے ہیں۔ ڈیٹا بیس کی اپنی ریپلیکا ڈیٹا کی ایک اضافی پرت فراہم کرتی ہے، اور کم لکھنے کے ذریعے کم لکھنے کا مطلب ہے لانگ ہارن ریپلیکا کو کم کرنا۔

چھوٹے رینڈم I/O کے لیے xfs پر ext4 استعمال کریں۔اگرچہ xfs بڑی ترتیب وار تحریروں پر سبقت لے جاتا ہے، ext4 عام طور پر ڈیٹا بیس ورک بوجھ کے چھوٹے بے ترتیب I/O پیٹرن کے لیے بہتر کارکردگی کا مظاہرہ کرتا ہے۔ اپنی StorageClass میںfsType: ext4سیٹ کریں۔

نوڈ شیڈولنگ اور ڈسک مینجمنٹ

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

مانیٹرنگ

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

لانگ ہارن مانیٹرنگ کے لیے بنائے جانے والے

کلیدی Grafana ڈیش بورڈ پینلز میں شامل ہیں: والیوم IOPS (پڑھنا/لکھنا)، والیوم تھرو پٹ (MB/s)، والیوم لیٹنسی (p50/p95/p99)، ریپلیکا ری بلڈ پروگریس، نوڈ اسٹوریج کی گنجائش اور استعمال، بیک اپ اسٹیٹس اور عمر، اور سنیپ شاٹ کا شمار فی والیوم۔

مکمل لانگ ہارن اسٹوریج اسٹیک کے ساتھ

k3s کلسٹر

مندرجہ ذیل خاکہ دکھاتا ہے کہ کس طرح لانگ ہارن مکمل k3s پروڈکشن اسٹیک میں فٹ بیٹھتا ہے، ننگے میٹل سرورز سے لے کر ایپلی کیشن پوڈز تک، رینچر مینجمنٹ اور Prometheus/Grafana مشاہدے کے ساتھ۔

دوسرے Kubernetes اسٹوریج سلوشنز کے ساتھ موازنہ

Longhorn Kubernetes کے لیے واحد اسٹوریج آپشن نہیں ہے۔ یہ سمجھنا کہ یہ متبادل سے کیسے موازنہ کرتا ہے آپ کو اپنی مخصوص ضروریات کے لیے صحیح انتخاب کرنے میں مدد کرتا ہے۔

Longhorn بمقابلہ Rook-Ceph:Ceph زیادہ طاقتور سسٹم ہے — یہ ایک جدید ترین CRUSH پلیسمنٹ الگورتھم کے ساتھ آبجیکٹ اسٹوریج، فائل اسٹوریج، اور بلاک اسٹوریج کو سپورٹ کرتا ہے۔ تاہم، Ceph کم از کم 3 وقف شدہ OSD نوڈس، اہم RAM (کم از کم 4GB فی OSD ڈیمون)، اور گہری آپریشنل مہارت کا مطالبہ کرتا ہے۔ 3–10 نوڈس والے k3s کلسٹرز کے لیے، Longhorn 90% قیمت فراہم کرتا ہے آپریشنل لاگت کے 10% پر۔

Longhorn بمقابلہ OpenEBS Mayastor:Mayastor اعلی کارکردگی کی نقل کے لیے NVMe-over-fabrics کا استعمال کرتا ہے، Longhorn کی TCP پر مبنی نقل کے مقابلے میں کم تاخیر کو حاصل کرتا ہے۔ اگر خام IOPS اور سب ملی سیکنڈ لیٹینسی آپ کی بنیادی تشویش ہے اور آپ کے پاس RDMA نیٹ ورکنگ کے ساتھ NVMe انفراسٹرکچر ہے تو Mayastor بہتر انتخاب ہو سکتا ہے۔ زیادہ تر k3s تعیناتیوں کے لیے، Longhorn کا مربوط بیک اپ، DR، اور آپریشنل سادگی مایاسٹر کی کارکردگی کے کنارے سے کہیں زیادہ ہے۔

Longhorn بمقابلہ لوکل پاتھ:لوکل پاتھ پروویژنر k3s کا ڈیفالٹ اسٹوریج ہے — یہ نوڈ کے لوکل فائل سسٹم پر آسانی سے ڈائریکٹریز بناتا ہے۔ صفر نقل، صفر سنیپ شاٹس، صفر بیک اپ انضمام۔ یہ ترقی کے لیے ٹھیک ہے لیکن پروڈکشن ڈیٹا کے لیے ناقابل قبول ہے۔

پیداوار کے بہترین طریقے

یہ سفارشات لانگ ہارن کو چلانے والے درجنوں پروڈکشن k3s کلسٹرز کے ڈیٹا بیس ورک بوجھ پر چلنے سے حاصل کی گئی ہیں۔

1. مثال کے مینیجرز کے لیے وسائل کے تحفظات سیٹ کریں۔لانگ ہارن انسٹینس مینیجرز (انجن اور ریپلیکا مینیجرز) کو نوڈ پریشر کے دوران I/O اسٹالز سے بچنے کے لیے CPU کی ضمانت کی ضرورت ہے۔ لانگ ہارن کی ترتیبات میںguaranteedInstanceManagerCPUکو کم از کم 12% پر سیٹ کریں۔

2. ڈیٹا بیس والیوم کے لیے ریٹین ری کلیم پالیسی کا استعمال کریں۔ڈیٹا بیس PVCs کے لیے کبھی بھیDeleteاستعمال نہ کریں۔Retainپالیسی PVC کے حذف ہونے کے بعد بھی PV اور اس کے ڈیٹا کو محفوظ رکھتی ہے، جو آپ کو حادثاتی طور پر حذف ہونے کے خلاف تحفظ فراہم کرتی ہے۔

3. پروڈکشن کے لیے ریپلیکا نرم اینٹی وابستگی کو غیر فعال کریں۔replicaSoftAntiAffinity: falseسیٹ کریں تاکہ یہ یقینی بنایا جا سکے کہ نقلیں ہمیشہ مختلف نوڈس میں پھیلی ہوئی ہوں۔ نرم مخالف وابستگی کے ساتھ، لانگ ہارن ایک ہی نوڈ پر متعدد نقلیں ترتیب دے سکتا ہے جب جگہ تنگ ہو — نقل کے مقصد کو شکست دے کر۔

4. ہر نوڈ پر اسٹوریج کی جگہ محفوظ کریں۔storageMinimalAvailablePercentageکو کم از کم 15% پر سیٹ کریں۔ یہ لانگ ہارن کو ڈسک کی تمام جگہ استعمال کرنے سے روکتا ہے، جس کی وجہ سے تمام پوڈز کو متاثر کرنے والے نوڈ لیول کے مسائل پیدا ہوں گے۔

5۔ آٹو سیلویج کو فعال کریں۔autoSalvageسیٹنگ خود بخود ان جلدوں کو بازیافت کرتی ہے جو خراب حالت میں داخل ہوتے ہیں جب کم از کم ایک نقل اب بھی صحت مند ہو۔ یہ نوڈ کی ناکامی کے دوران دستی مداخلت کو کم کرتا ہے۔

6. ترجیحی کلاس سسٹم-کلسٹر-کریٹیکل پر سیٹ کریں۔Longhorn کے مینیجر اور ڈرائیور کے اجزاء کو نوڈ پریشر کے دوران کبھی بھی بے دخل نہیں کیا جانا چاہیے۔ ان کی priorityClass کوsystem-cluster-criticalپر سیٹ کریں تاکہ یہ یقینی بنایا جا سکے کہ وہ پوڈ کی بے دخلی سے بچ جاتے ہیں۔

7. تمام پروڈکشن والیوم کے لیے بار بار چلنے والی جابز کو ترتیب دیں۔ہر پروڈکشن والیوم میں اسنیپ شاٹ اور بیک اپ اعادی کام دونوں ہونے چاہئیں۔ فوری رول بیک کے لیے ہر 4 گھنٹے بعد سنیپ شاٹس، ڈیزاسٹر ریکوری کے لیے روزانہ بیک اپ۔

8. باقاعدگی سے DR والیوم ایکٹیویشن کی جانچ کریں۔اپنے اسٹینڈ بائی کلسٹر میں DR والیوم کو چالو کرنے، ڈیٹا کی سالمیت کی تصدیق کرنے اور فیل اوور کے طریقہ کار پر عمل کرنے کے لیے ایک ماہانہ شیڈول بنائیں۔ ایک DR منصوبہ جس کا کبھی تجربہ نہیں کیا گیا وہ صرف دستاویزات ہے۔

9. حجم کی صحت کو فعال طور پر مانیٹر کریں۔انحطاط شدہ اور خراب والیومز، نوڈ اسٹوریج کی گنجائش، بیک اپ کی عمر، اور ریپلیکا ری بلڈ اسٹیٹس کے لیے Prometheus الرٹس مرتب کریں۔ جب تک صارف سست ڈیٹا بیس کی اطلاع دیتا ہے، اسٹوریج کا مسئلہ گھنٹوں سے کھڑا ہوتا ہے۔

10. وقف شدہ اسٹوریج ڈسک استعمال کریں۔لانگ ہارن ڈیٹا کو OS ڈسک سے الگ کریں۔ یہ I/O تنازعہ کو روکتا ہے، آپ کو کلینر صلاحیت کا انتظام فراہم کرتا ہے، اور OS ڈسک کو Longhorn ڈیٹا سے بھرنے کے خطرے سے بچاتا ہے۔

کلاؤڈ کے لیے مخصوص تعیناتی گائیڈنس

AWS — EC2 NVMe انسٹینس اسٹوریج

AWS کی تعیناتیوں کے لیے،i3.xlargeیاi3en.xlargeمثالیں استعمال کریں جو NVMe انسٹینس اسٹوریج کے ساتھ آتی ہیں۔ یہ فراہم کردہ EBS IOPS کی لاگت کے ایک حصے پر خام 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 — الٹرا ڈسک کے ساتھ VMs

Azure پر، مقامی NVMe اسٹوریج کے ساتھStandard_L8s_v3یاStandard_L16s_v3VMs استعمال کریں۔ متبادل طور پر، الٹرا ڈسک کو مسلسل ذیلی ملی سیکنڈ کی تاخیر کے لیے منسلک کریں۔ الٹرا ڈسک آپ کو 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 پیش کرتا ہے۔ مقامی SSDs 680,000 تک پڑھنے والے IOPS کے ساتھ 375 GB فی ڈسک فراہم کرتے ہیں۔ ایک سے زیادہ مقامی 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 ڈرائیوز کے ساتھ سرور استعمال کریں۔ OS ڈسک کو اسٹوریج ڈسک سے الگ کریں۔ نوڈس کے درمیان 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

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 کئی اہم نظارے فراہم کرتا ہے:ڈیش بورڈکلسٹر وائیڈ اسٹوریج کی صحت کو ظاہر کرتا ہے بشمول کل گنجائش، استعمال شدہ جگہ، اور حجم کی حیثیت۔والیومتمام جلدوں کو ان کی حالت (صحت مند/ڈیگریڈڈ/فالٹڈ)، سائز، نقل کی گنتی، اور منسلک نوڈ کے ساتھ درج کرتا ہے۔ آپ اس منظر سے براہ راست حجم کو بڑھا سکتے ہیں، سنیپ شاٹ لے سکتے ہیں، بیک اپ لے سکتے ہیں اور والیوم کو بحال کر سکتے ہیں۔نوڈہر نوڈ کی سٹوریج کنفیگریشن، ڈسک ایلوکیشن، اور شیڈولنگ سٹیٹس کو دکھاتا ہے۔بیک اپبیک اپ ہدف میں محفوظ کردہ تمام بیک اپ کو ان کے حجم، سائز اور تخلیق کے وقت کے ساتھ فہرست کرتا ہے۔کی ترتیب تمام لانگ ہارن کنفیگریشن پیرامیٹرز کو تفصیل کے ساتھ بے نقاب کرتی ہے۔

ٹربل شوٹنگ عام مسائل

تنزلی والیومس

ایک والیوم انحطاطی حالت میں داخل ہوتا ہے جب ایک یا زیادہ نقلیں غیر صحت مند ہوتی ہیں لیکن حجم پھر بھی کام کرتا ہے۔ عام وجوہات میں نوڈ کی ناکامی، ڈسک فل، یا نیٹ ورک پارٹیشن شامل ہیں۔

# 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 آپریٹر، Zalando Postgres آپریٹر) 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 تقسیم سے تبدیل کرتا ہے جو صرف کنارے اور ترقی کے لیے موزوں ہے ایک پروڈکشن کے لیے تیار پلیٹ فارم میں جو مشن کے لیے اہم ریاستی کام کے بوجھ کو چلانے کے قابل ہے۔ اس کا فن تعمیر — فی والیوم انجن، ہم وقت ساز ملٹی نوڈ نقل، مربوط اسنیپ شاٹ اور کلاؤڈ آبجیکٹ اسٹوریج میں بیک اپ، DR والیوم، والیوم انکرپشن، اور آن لائن PVC توسیع — انٹرپرائز گریڈ کی پیچیدگی کے بغیر انٹرپرائز گریڈ اسٹوریج فراہم کرتا ہے۔

پیداوار میں Longhorn کے ساتھ کامیابی کی کلید تین گنا ہے۔ سب سے پہلے، اسے شروع سے ہی درست طریقے سے ترتیب دیں: وقف شدہ سٹوریج ڈسک استعمال کریں، نقل کرنے کے مناسب عوامل اور ڈیٹا لوکلٹی سیٹ کریں، اور کام کے بوجھ کی مختلف اقسام کے لیے مقصد سے تیار کردہ سٹوریج کلاسز بنائیں۔ دوسرا، بیک اپ کو اپنے فن تعمیر میں پہلے دن سے ضم کریں: تیز رفتار رول بیک کے لیے بار بار آنے والے سنیپ شاٹس، ڈیزاسٹر ریکوری کے لیے S3/GCS/Azure پر روزانہ بیک اپ، اور بدترین صورت حال کے لیے اسٹینڈ بائی کلسٹر میں DR والیوم۔ تیسرا، ہر چیز کی نگرانی کریں: حجم کی صحت، نوڈ اسٹوریج کی گنجائش، بیک اپ کی عمر، اور ریپلیکا ری بلڈ اسٹیٹس — اسٹوریج کے مسائل اس وقت تک پوشیدہ رہتے ہیں جب تک کہ وہ تباہ کن نہ ہو جائیں۔

ڈائنامک PVC توسیع پیداواری واقعات کے سب سے عام ذرائع میں سے ایک کو ختم کرتی ہے — ڈسک کی جگہ ختم ہو رہی ہے۔ Longhorn کے ساتھ، ڈیٹا بیس والیوم کو 50Gi سے 500Gi تک بڑھانا صفر ڈاؤن ٹائم کے ساتھ ایک واحد kubectl کمانڈ ہے۔ صلاحیت کی حدوں پر Prometheus انتباہات کے ساتھ مل کر، آپ حجم کو اہم بننے سے پہلے فعال طور پر بڑھا سکتے ہیں، یا توسیع کو مکمل طور پر خودکار کر سکتے ہیں۔

چاہے آپ k3s پر PostgreSQL، MySQL، MongoDB، یا Redis چلا رہے ہوں — ننگے میٹل سرورز پر، AWS EC2، Azure VMs، GCP مثالوں، یا آن پریمیسس ڈیٹا سینٹر ہارڈ ویئر پر — Longhorn اسٹوریج کی بنیاد فراہم کرتا ہے جو آپ کو اپنے ڈیٹا پر توجہ مرکوز کرنے کے بجائے آپ کے ڈیٹا پر توجہ مرکوز کرنے دیتا ہے۔ اسے انسٹال کریں، اسے ترتیب دیں، اس کی نگرانی کریں، اور اپنے پروڈکشن ڈیٹا کے ساتھ اس پر بھروسہ کریں۔