উৎপাদন k3s ক্লাস্টারগুলির জন্য লংহর্ন স্টোরেজ: ডায়নামিক PVC সম্প্রসারণ, প্রতিলিপি, এবং দুর্যোগ পুনরুদ্ধার

স্টোরেজ হল Kubernetes-এর সবচেয়ে কঠিন সমস্যা। কম্পিউট রাষ্ট্রহীন এবং ছত্রাকযোগ্য — একটি শুঁটি হত্যা করুন, অন্যটির সময়সূচী করুন। নেটওয়ার্কিং-এ পরিপক্ক CNI প্লাগইন এবং পরিষেবা মেশ রয়েছে। কিন্তু স্টোরেজ? সঞ্চয়স্থান হল যেখানে রাজ্য বাস করে, যেখানে ডেটা রিস্টার্ট জুড়ে থাকে, যেখানে একটি একক ভুল কনফিগারেশন স্থায়ী ডেটা ক্ষতির অর্থ হতে পারে। k3s ক্লাস্টারগুলি চলমান প্রোডাকশন ওয়ার্কলোডগুলির জন্য — ডাটাবেস, বার্তা সারি, অ্যাপ্লিকেশন স্টেট — আপনার একটি স্টোরেজ সমাধান প্রয়োজন যা বিতরণ করা, স্থিতিস্থাপক, প্রসারণযোগ্য এবং পরিচালনাযোগ্য। লংহর্ন সেই সমাধান।

লংহর্ন হল Kubernetes-এর জন্য একটি হালকা ওজনের, নির্ভরযোগ্য এবং সহজে ব্যবহারযোগ্য ডিস্ট্রিবিউটেড ব্লক স্টোরেজ সিস্টেম। মূলত Rancher Labs দ্বারা তৈরি করা হয়েছে (এখন SUSE এর অংশ), এটি একটি CNCF ইনকিউবেটিং প্রজেক্ট যা ক্লাস্টারের জন্য তৈরি করা হয়েছে যেখানে সরলতা গুরুত্বপূর্ণ কিন্তু উৎপাদন নির্ভরযোগ্যতা আলোচনার যোগ্য নয়। Ceph-এর বিপরীতে, যা ডেডিকেটেড স্টোরেজ নোড এবং গভীর দক্ষতার দাবি করে, অথবা লোকাল-পাথ প্রোভিজার, যেটি শূন্য রিডানডেন্সি অফার করে, লংহর্ন k3s ক্লাস্টারগুলির প্রয়োজনীয় ভারসাম্যকে স্ট্রাইক করে: নোড জুড়ে বিতরণ করা প্রতিলিপি, গতিশীল ভলিউম সম্প্রসারণ, ক্লাউড অবজেক্ট স্টোরেজে সমন্বিত ব্যাকআপ, স্ন্যাপশট এবং পরিষ্কার UI ব্যবস্থাপনার মাধ্যমে সমস্ত কিছু পুনরুদ্ধার করা। Kubernetes-নেটিভ CRDs।

এই নির্দেশিকাটি উত্পাদনের জন্য k3s-এ লংহর্ন স্থাপন করার জন্য প্রয়োজনীয় সমস্ত কিছু কভার করে: আর্কিটেকচার ইন্টারনাল, ইনস্টলেশন পদ্ধতি, স্টোরেজক্লাস কনফিগারেশন, গতিশীল PVC সম্প্রসারণ, প্রতিলিপি কৌশল, ব্যাকআপ এবং দুর্যোগ পুনরুদ্ধার, ভলিউম এনক্রিপশন, কর্মক্ষমতা টিউনিং এবং ডেটাবেসের জন্য মনিটরিং, সমস্যা। প্রতিটি সুপারিশ উত্পাদন-পরীক্ষিত কনফিগারেশনের সাথে আসে যা আপনি আপনার পরিবেশের সাথে মানিয়ে নিতে পারেন।

লংহর্ন আর্কিটেকচার

লংহর্নের স্থাপত্য বোঝার প্রতিলিপি, কর্মক্ষমতা, এবং ব্যর্থতা পরিচালনার বিষয়ে জ্ঞাত সিদ্ধান্ত নেওয়ার জন্য অপরিহার্য। লংহর্ন তিনটি মূল উপাদানের সমন্বয়ে গঠিত যা আপনার Kubernetes নোডের সাথে সংযুক্ত স্থানীয় ডিস্কের উপরে বিতরণকৃত ব্লক স্টোরেজ প্রদান করতে একসাথে কাজ করে।

লংহর্ন ম্যানেজারক্লাস্টারের প্রতিটি নোডে ডেমনসেট হিসাবে চলে। এটি লংহর্নের কন্ট্রোল প্লেন — এটি API কল পরিচালনা করে, ভলিউম তৈরি করে, প্রতিলিপি পরিচালনা করে, স্ন্যাপশট এবং ব্যাকআপ সমন্বয় করে এবং PersistentVolume এবং PersistentVolumeClaim জীবনচক্র পরিচালনা করতে Kubernetes API সার্ভারের সাথে যোগাযোগ করে। আপনি যখন একটি PVC তৈরি করেন যা একটি লংহর্ন স্টোরেজক্লাসের উল্লেখ করে, লংহর্ন ম্যানেজার CSI ড্রাইভারের মাধ্যমে অনুরোধটি গ্রহণ করে, ভলিউম বিধান করে এবং উপলব্ধ নোডগুলিতে এর প্রতিলিপিগুলি নির্ধারণ করে।

লংহর্ন ইঞ্জিনহল একটি প্রতি-ভলিউম স্টোরেজ কন্ট্রোলার যা একটি লিনাক্স ইউজারস্পেস প্রক্রিয়া হিসাবে প্রয়োগ করা হয় (র‍্যাঞ্চার লংহর্ন ইঞ্জিনের কাঁটার উপর ভিত্তি করে)। প্রতিটি ভলিউম তার নিজস্ব ডেডিকেটেড ইঞ্জিন প্রক্রিয়া পায় যেখানে নোডে ভলিউম সংযুক্ত থাকে। ইঞ্জিন সেই ভলিউমের জন্য সমস্ত রিড এবং রাইট I/O পরিচালনা করে, অ্যাপ্লিকেশানে লেখার স্বীকৃতি দেওয়ার আগে সমস্ত কনফিগার করা প্রতিলিপিতে সিঙ্ক্রোনাসভাবে লেখার প্রতিলিপি করে। এই প্রতি-ভলিউম আর্কিটেকচারের অর্থ হল যে একটি ভলিউমের ইঞ্জিনে ক্র্যাশ বা হ্যাং হওয়া অন্য কোনও ভলিউমকে প্রভাবিত করে না - উত্পাদনের জন্য একটি গুরুত্বপূর্ণ বিচ্ছিন্নতা বৈশিষ্ট্য।

রেপ্লিকাসহল প্রকৃত ডেটা স্টোরেজ প্রক্রিয়া। প্রতিটি প্রতিরূপ নোডের স্থানীয় ডিস্কে ভলিউম ডেটার একটি সম্পূর্ণ অনুলিপি সংরক্ষণ করে যেখানে এটি চলে। ডিফল্টরূপে, লংহর্ন প্রতিটি ভলিউমের জন্য তিনটি প্রতিলিপি তৈরি করে, বিভিন্ন নোড (এবং ঐচ্ছিকভাবে বিভিন্ন অঞ্চল) জুড়ে বিতরণ করা হয়। প্রতিলিপিগুলি স্ন্যাপশটের জন্য একটি অনুলিপি-অন-রাইট প্রক্রিয়া ব্যবহার করে, যা ভলিউম আকার নির্বিশেষে স্ন্যাপশট তৈরিকে তাত্ক্ষণিক করে তোলে।

এই আর্কিটেকচারটি উত্পাদন ব্যবহারের জন্য বেশ কয়েকটি মূল বৈশিষ্ট্য সরবরাহ করে।ফল্ট সহনশীলতা:তিনটি নোড জুড়ে তিনটি প্রতিলিপি সহ, ভলিউম দুটি যুগপত নোড ব্যর্থতা থেকে বেঁচে থাকে।বিচ্ছিন্নতা:প্রতিটি ভলিউমের নিজস্ব ইঞ্জিন প্রক্রিয়া রয়েছে, তাই একটি ভলিউমে একটি বাগ বা হ্যাং ক্যাসকেড করতে পারে না।সরলতা:কোনও ডেডিকেটেড স্টোরেজ নোড নেই, কোনও আলাদা Ceph বা GlusterFS ক্লাস্টার নেই — লংহর্ন আপনার অ্যাপ্লিকেশন পডগুলির মতো একই কর্মী নোডগুলিতে চলে, তাদের স্থানীয় ডিস্কগুলি ব্যবহার করে৷Kubernetes-নেটিভ:সবকিছু CRDs, kubectl এবং Kubernetes CSI ইন্টারফেসের মাধ্যমে পরিচালিত হয়।

k3s

Longhorn তিনটি পদ্ধতির মাধ্যমে 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.

Helm এর মাধ্যমে ইনস্টলেশন (প্রস্তাবিত)

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

# Create the namespace
kubectl create namespace longhorn-system

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

এখানে টিউন করা ডিফল্ট সহ একটি প্রোডাকশন-গ্রেডvalues.yamlরয়েছে:

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

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

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

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

longhornUI:
  replicas: 2

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

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

ইনস্টলেশন

যদি Rancher আপনার k3s ক্লাস্টার পরিচালনা করে, তাহলেঅ্যাপগুলিতে নেভিগেট করুন & মার্কেটপ্লেস → চার্ট → লংহর্নRancher UI এ। আপনার টার্গেট নেমস্পেস নির্বাচন করুন (longhorn-system), ফর্ম ইন্টারফেসের মাধ্যমে মানগুলি কনফিগার করুন এবং ইনস্টল করুন ক্লিক করুন৷ Rancher স্বয়ংক্রিয়ভাবে Helm জীবনচক্র ব্যবস্থাপনা এবং আপগ্রেড ট্র্যাকিং পরিচালনা করে।

Kubectl

ইনস্টলেশন

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

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

পোস্ট-ইনস্টলেশন: লংহর্নকে ডিফল্ট স্টোরেজক্লাস

# 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 সম্প্রসারণ — ডাউনটাইম ছাড়াই, ডেটা ক্ষতি ছাড়াই এবং একটি একক kubectl কমান্ড বা ম্যানিফেস্ট পরিবর্তনের বাইরে ম্যানুয়াল হস্তক্ষেপ ছাড়াই একটি স্থায়ী ভলিউমের আকার বৃদ্ধি করার ক্ষমতা। এটি ডাটাবেসের জন্য গুরুত্বপূর্ণ যেখানে ডেটা বৃদ্ধি অপ্রত্যাশিত এবং ডিস্কের স্থান ফুরিয়ে যাওয়া মানে বিভ্রাট।

লংহর্নঅনলাইন সম্প্রসারণ(ভলিউমটি বৃদ্ধির সময় সংযুক্ত এবং মাউন্ট করা থাকে) এবংঅফলাইন সম্প্রসারণ(ভলিউমটি প্রথমে আলাদা করা হয়) উভয়কেই সমর্থন করে। অনলাইন সম্প্রসারণ হল উৎপাদনের জন্য ডিফল্ট এবং প্রস্তাবিত পদ্ধতি কারণ এটি অ্যাপ্লিকেশন ডাউনটাইম এড়ায়।

স্টোরেজক্লাস

ডায়নামিক 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

স্ন্যাপশট এবং ব্যাকআপ

লংহর্ন দুটি স্বতন্ত্র ডেটা সুরক্ষা ব্যবস্থা প্রদান করে:স্ন্যাপশট(স্থানীয়, তাত্ক্ষণিক, দ্রুত রোলব্যাকের জন্য) এবংব্যাকআপ(দূরবর্তী, অবজেক্ট স্টোরেজ, দুর্যোগ পুনরুদ্ধারের জন্য)। প্রতিটি কখন ব্যবহার করতে হবে তা বোঝা গুরুত্বপূর্ণ।

স্ন্যাপশটগুলি ভলিউম প্রতিলিপিগুলির মতো একই ডিস্কে স্থানীয়ভাবে সংরক্ষণ করা হয়। এগুলি কপি-অন-রাইট ব্যবহার করে তাত্ক্ষণিকভাবে তৈরি করা হয় — স্ন্যাপশটের সময়ে কোনও ডেটা অনুলিপি করা হয় না, স্ন্যাপশট অতিরিক্ত স্থান বরাদ্দ করার পরে শুধুমাত্র নতুন লেখাগুলি। স্ন্যাপশটগুলি একটি ঝুঁকিপূর্ণ স্থানান্তর বা স্থাপনার আগে দ্রুত রোলব্যাকের জন্য দুর্দান্ত, তবে তারা নোড বা ডিস্ক ব্যর্থতার বিরুদ্ধে সুরক্ষা দেয় না কারণ তারা ভলিউমের মতো একই স্টোরেজে থাকে।

ব্যাকআপগুলি একটি বাহ্যিক ব্যাকআপ লক্ষ্যে ভলিউম ডেটা অনুলিপি করে — S3, GCS, Azure ব্লব, বা যে কোনও 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

দুর্যোগ পুনরুদ্ধার

লংহর্নDR ভলিউম- একটি সেকেন্ডারি ক্লাস্টারে স্ট্যান্ডবাই ভলিউমের মাধ্যমে একটি অন্তর্নির্মিত দুর্যোগ পুনরুদ্ধার ব্যবস্থা প্রদান করে যা প্রাথমিক ক্লাস্টারের ব্যাকআপ টার্গেট থেকে ক্রমাগত ক্রমবর্ধমান ব্যাকআপগুলিকে টেনে আনে৷ যখন দুর্যোগ আঘাত হানে, আপনি DR ভলিউম সক্রিয় করেন এবং এটি একটি নিয়মিত পঠন-লেখার ভলিউম হয়ে যায়, যা সেকেন্ডারি ক্লাস্টারটি দখল করতে দেয়।

DR ভলিউম

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

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

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

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

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

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

ভলিউম এনক্রিপশন

Longhorn Linux LUKS2 ব্যবহার করে ভলিউম-লেভেল এনক্রিপশন সমর্থন করে। এনক্রিপ্ট করা ভলিউমগুলি অন্তর্নিহিত ডিস্কে বিশ্রামে ডেটা রক্ষা করে — এমনকি যদি কেউ সার্ভারের সঞ্চয়স্থানে শারীরিক অ্যাক্সেস লাভ করে, তারা এনক্রিপশন কী ছাড়া ভলিউম ডেটা পড়তে পারে না।

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

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

ReadWriteMany (RWX)

ডিফল্টরূপে, লংহর্ন ভলিউমগুলি হল ReadWriteOnce (RWO) — এগুলি একটি একক নোডে একটি একক পড দ্বারা মাউন্ট করা যেতে পারে৷ একাধিক পড (যেমন, শেয়ার্ড মিডিয়া আপলোড, কনফিগারেশন ফাইল, এমএল মডেল আর্টিফ্যাক্ট) জুড়ে শেয়ার্ড স্টোরেজ প্রয়োজন এমন কাজের চাপের জন্য, লংহর্ন একটি সমন্বিত 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

ডাটাবেস ওয়ার্কলোড Longhorn-এ

ডাটাবেস চালানোর জন্য StorageClass প্যারামিটার, পড অ্যাফিনিটি এবং ব্যাকআপ ইন্টিগ্রেশনের প্রতি সতর্ক মনোযোগ প্রয়োজন। লংহর্নের প্রতি-ভলিউম ইঞ্জিন এবং সিঙ্ক্রোনাস প্রতিলিপি এটিকে ডাটাবেস কাজের চাপের জন্য উপযুক্ত করে তোলে, তবে উত্পাদন-গ্রেড কর্মক্ষমতা এবং নির্ভরযোগ্যতা পেতে আপনাকে এটি সঠিকভাবে কনফিগার করতে হবে।

Longhorn

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

Longhorn

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 গতিতে স্থানীয় ডিস্ক হিট হয়। লেখাগুলি এখনও দূরবর্তী নোডগুলিতে প্রতিলিপি তৈরি করে, তবে স্থানীয় প্রতিরূপটি পড়ার জন্য নেটওয়ার্ক রাউন্ড-ট্রিপগুলিকে সরিয়ে দেয়।

লংহর্নে ডিস্ক উৎসর্গ করুন।Longhorn ডেটার সাথে 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

মনিটরিং

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 প্রোডাকশন স্ট্যাকের সাথে ফিট করে, বেয়ার মেটাল সার্ভার থেকে শুরু করে অ্যাপ্লিকেশন পড পর্যন্ত, Rancher ব্যবস্থাপনা এবং Prometheus/Grafana পর্যবেক্ষণযোগ্যতা সহ।

অন্যান্য Kubernetes স্টোরেজ সলিউশনের সাথে তুলনা

Longhorn Kubernetes এর জন্য একমাত্র স্টোরেজ বিকল্প নয়। এটি বিকল্পগুলির সাথে কীভাবে তুলনা করে তা বোঝা আপনাকে আপনার নির্দিষ্ট প্রয়োজনীয়তার জন্য সঠিক পছন্দ করতে সহায়তা করে।

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

Longhorn বনাম Rook-Ceph:Ceph হল আরও শক্তিশালী সিস্টেম — এটি একটি অত্যাধুনিক ক্রাশ প্লেসমেন্ট অ্যালগরিদম সহ অবজেক্ট স্টোরেজ, ফাইল স্টোরেজ এবং ব্লক স্টোরেজ সমর্থন করে। যাইহোক, Ceph অন্তত 3টি ডেডিকেটেড OSD নোড, উল্লেখযোগ্য RAM (ন্যূনতম 4GB প্রতি OSD ডেমন) এবং গভীর অপারেশনাল দক্ষতার দাবি করে। 3-10 নোড সহ k3s ক্লাস্টারগুলির জন্য, লংহর্ন অপারেশনাল খরচের 10% মূল্যের 90% প্রদান করে।

লংহর্ন বনাম ওপেনইবিএস মায়াস্টর:মায়াস্টার উচ্চ-কার্যক্ষমতার প্রতিলিপির জন্য NVMe-ওভার-ফ্যাব্রিক ব্যবহার করে, লংহর্নের TCP-ভিত্তিক প্রতিলিপির চেয়ে কম লেটেন্সি অর্জন করে। যদি কাঁচা IOPS এবং সাব-মিলিসেকেন্ড লেটেন্সি আপনার প্রাথমিক উদ্বেগ হয় এবং আপনার কাছে RDMA নেটওয়ার্কিং সহ NVMe পরিকাঠামো থাকে, মায়াস্টর সেরা পছন্দ হতে পারে। বেশিরভাগ k3s স্থাপনার জন্য, Longhorn-এর সমন্বিত ব্যাকআপ, DR, এবং অপারেশনাল সরলতা মায়াস্টরের পারফরম্যান্স প্রান্তকে ছাড়িয়ে যায়।

লংহর্ন বনাম লোকাল-পাথ:লোকাল-পাথ প্রোভিজার হল k3s-এর ডিফল্ট স্টোরেজ — এটি নোডের স্থানীয় ফাইল সিস্টেমে কেবল ডিরেক্টরি তৈরি করে। জিরো রেপ্লিকেশন, জিরো স্ন্যাপশট, জিরো ব্যাকআপ ইন্টিগ্রেশন। এটা উন্নয়নের জন্য জরিমানা কিন্তু উত্পাদন তথ্য জন্য অগ্রহণযোগ্য.

উত্পাদনের সেরা অনুশীলনগুলি

এই সুপারিশগুলি ডাটাবেস ওয়ার্কলোড চলমান কয়েক ডজন প্রোডাকশন k3s ক্লাস্টার জুড়ে লংহর্ন অপারেটিং থেকে পাতিত হয়।

1. উদাহরণ পরিচালকদের জন্য রিসোর্স রিজার্ভেশন সেট করুন। নোড চাপের সময় I/O স্টল এড়াতেলংহর্ন ইনস্ট্যান্স ম্যানেজারদের (ইঞ্জিন এবং রেপ্লিকা ম্যানেজারদের) নিশ্চিত CPU প্রয়োজন। Longhorn সেটিংসেguaranteedInstanceManagerCPUকে কমপক্ষে 12% এ সেট করুন।

2. ডাটাবেস ভলিউমের জন্য পুনরুদ্ধার নীতি বজায় রাখুন।ডাটাবেস PVC এর জন্যDeleteকখনই ব্যবহার করবেন না৷ একটিRetainনীতি PVC মুছে ফেলার পরেও PV এবং এর ডেটা রাখে, যা আপনাকে দুর্ঘটনাজনিত মুছে ফেলার বিরুদ্ধে একটি নিরাপত্তা জাল দেয়।

3. উৎপাদনের জন্য রেপ্লিকা নরম অ্যান্টি-অ্যাফিনিটি অক্ষম করুন৷প্রতিলিপিগুলি সর্বদা বিভিন্ন নোড জুড়ে ছড়িয়ে রয়েছে তা নিশ্চিত করতেreplicaSoftAntiAffinity: falseসেট করুন। নরম অ্যান্টি-অ্যাফিনিটি সহ, লংহর্ন একই নোডে একাধিক প্রতিলিপি নির্ধারণ করতে পারে যখন স্থান আঁটসাঁট থাকে — প্রতিলিপির উদ্দেশ্যকে পরাজিত করে।

4. প্রতিটি নোডে স্টোরেজ স্পেস সংরক্ষণ করুন।storageMinimalAvailablePercentageকমপক্ষে 15% এ সেট করুন। এটি লংহর্নকে সমস্ত ডিস্কের স্থান গ্রাস করতে বাধা দেয়, যা সমস্ত পডকে প্রভাবিত করে নোড-স্তরের সমস্যা সৃষ্টি করে।

5. অটো-সেলভেজ সক্ষম করুন।autoSalvageসেটিং স্বয়ংক্রিয়ভাবে ভলিউম পুনরুদ্ধার করে যা একটি ত্রুটিযুক্ত অবস্থায় প্রবেশ করে যখন অন্তত একটি প্রতিরূপ এখনও সুস্থ থাকে। এটি নোড ব্যর্থতার সময় ম্যানুয়াল হস্তক্ষেপ হ্রাস করে।

6. সিস্টেম-ক্লাস্টার-ক্রিটিকাল-এ অগ্রাধিকার শ্রেণী সেট করুন। নোড চাপের সময়লংহর্নের ম্যানেজার এবং ড্রাইভার উপাদানগুলি কখনই উচ্ছেদ করা উচিত নয়। তাদের priorityClasssystem-cluster-criticalএ সেট করুন যাতে তারা পড উচ্ছেদ থেকে বেঁচে থাকে।

7. সমস্ত উত্পাদন ভলিউমের জন্য পুনরাবৃত্ত কাজগুলি কনফিগার করুন৷প্রতিটি উৎপাদন ভলিউমে স্ন্যাপশট এবং ব্যাকআপ পুনরাবৃত্ত কাজ উভয়ই থাকা উচিত। দ্রুত রোলব্যাকের জন্য প্রতি 4 ঘন্টা স্ন্যাপশট, দুর্যোগ পুনরুদ্ধারের জন্য প্রতিদিন ব্যাকআপ।

8. নিয়মিতভাবে DR ভলিউম অ্যাক্টিভেশন পরীক্ষা করুন।আপনার স্ট্যান্ডবাই ক্লাস্টারে DR ভলিউম সক্রিয় করতে একটি মাসিক সময়সূচী তৈরি করুন, ডেটা অখণ্ডতা যাচাই করুন এবং ফেইলওভার পদ্ধতি অনুশীলন করুন৷ একটি ডিআর প্ল্যান যা কখনও পরীক্ষা করা হয়নি তা শুধু ডকুমেন্টেশন।

9. সক্রিয়ভাবে ভলিউম স্বাস্থ্য নিরীক্ষণ করুন।অবনমিত এবং ত্রুটিযুক্ত ভলিউম, নোড স্টোরেজ ক্ষমতা, ব্যাকআপ বয়স এবং প্রতিলিপি পুনর্নির্মাণের স্থিতির জন্য Prometheus সতর্কতা সেট আপ করুন৷ যখন একজন ব্যবহারকারী একটি ধীর ডাটাবেস রিপোর্ট করে, তখন স্টোরেজ সমস্যা কয়েক ঘন্টা ধরে তৈরি হচ্ছে।

10. ডেডিকেটেড স্টোরেজ ডিস্ক ব্যবহার করুন।OS ডিস্ক থেকে লংহর্ন ডেটা আলাদা করুন৷ এটি I/O বিবাদ প্রতিরোধ করে, আপনাকে ক্লিনার ক্যাপাসিটি ম্যানেজমেন্ট দেয় এবং লংহর্ন ডেটা দিয়ে OS ডিস্ক পূরণ করার ঝুঁকি এড়ায়।

ক্লাউড-নির্দিষ্ট স্থাপনার নির্দেশিকা

AWS — EC2 NVMe ইনস্ট্যান্স স্টোরেজ

AWS স্থাপনার জন্য, NVMe ইনস্ট্যান্স স্টোরেজের সাথে আসাi3.xlargeবাi3en.xlargeদৃষ্টান্তগুলি ব্যবহার করুন৷ এগুলি প্রভিশন করা 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 — আল্ট্রা ডিস্ক

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-standardVM-এর সাথে সংযুক্ত স্থানীয় SSD অফার করে। স্থানীয় SSDs 680,000 রিড IOPS সহ প্রতি ডিস্কে 375 GB প্রদান করে। একাধিক স্থানীয় SSD সংযুক্ত করুন এবং বড় ভলিউমের জন্য তাদের RAID করুন।

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

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

অন-প্রিমিসেস ডেটাসেন্টার

অন-প্রিমিসেস স্থাপনার জন্য, লংহর্নের জন্য ডেডিকেটেড NVMe বা SAS SSD ড্রাইভ সহ সার্ভার ব্যবহার করুন। স্টোরেজ ডিস্ক থেকে 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

লংহর্ন UI ওয়াকথ্রু

লংহর্ন একটি অন্তর্নির্মিত ওয়েব UI সহ জাহাজ যা ভলিউম, স্ন্যাপশট, ব্যাকআপ, নোড এবং সেটিংস পরিচালনার জন্য একটি ভিজ্যুয়াল ইন্টারফেস প্রদান করে৷ ইনস্টলেশনের সময় কনফিগার করা ইনগ্রেসের মাধ্যমে বা 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

আপগ্রেড পদ্ধতি

লংহর্ন আপগ্রেডগুলি সাবধানে সঞ্চালিত করা উচিত, কারণ স্টোরেজ সিস্টেম সমস্ত রাষ্ট্রীয় কাজের চাপকে আন্ডারপিন করে৷ আপগ্রেড করার আগে সর্বদা সমস্ত গুরুত্বপূর্ণ ভলিউমের ব্যাকআপ নিন।

# 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 অপারেটর) লংহর্নের সাথে নির্বিঘ্নে কাজ করে। অপারেটর ডাটাবেস জীবনচক্র পরিচালনা করে যখন লংহর্ন প্রতিলিপি, স্ন্যাপশট এবং ব্যাকআপ সহ অন্তর্নিহিত স্টোরেজ প্রদান করে।

# 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 সম্প্রসারণ — এন্টারপ্রাইজ-গ্রেড জটিলতা ছাড়াই এন্টারপ্রাইজ-গ্রেড স্টোরেজ সরবরাহ করে।

উৎপাদনে লংহর্নের সাফল্যের চাবিকাঠি তিনগুণ। প্রথমত, এটিকে শুরু থেকে সঠিকভাবে কনফিগার করুন: ডেডিকেটেড স্টোরেজ ডিস্ক ব্যবহার করুন, উপযুক্ত প্রতিলিপি উপাদান এবং ডেটা স্থানীয়তা সেট করুন এবং বিভিন্ন কাজের চাপের জন্য উদ্দেশ্য-নির্মিত স্টোরেজ ক্লাস তৈরি করুন। দ্বিতীয়ত, প্রথম দিন থেকে আপনার আর্কিটেকচারে ব্যাকআপ সংহত করুন: দ্রুত রোলব্যাকের জন্য পুনরাবৃত্ত স্ন্যাপশট, দুর্যোগ পুনরুদ্ধারের জন্য S3/GCS/Azure-এ দৈনিক ব্যাকআপ, এবং সবচেয়ে খারাপ পরিস্থিতির জন্য স্ট্যান্ডবাই ক্লাস্টারে DR ভলিউম। তৃতীয়ত, সবকিছু নিরীক্ষণ করুন: ভলিউম হেলথ, নোড স্টোরেজ ক্ষমতা, ব্যাকআপ বয়স এবং রেপ্লিকা রিবিল্ড স্ট্যাটাস — স্টোরেজের সমস্যাগুলি বিপর্যয় না হওয়া পর্যন্ত অদৃশ্য থাকে।

ডায়নামিক PVC সম্প্রসারণ উৎপাদনের ঘটনাগুলির সবচেয়ে সাধারণ উত্সগুলির একটিকে দূর করে — ডিস্কের স্থান ফুরিয়ে যাচ্ছে৷ লংহর্নের সাথে, 50Gi থেকে 500Gi-এ ডাটাবেস ভলিউম প্রসারিত করা হল শূন্য ডাউনটাইম সহ একটি একক kubectl কমান্ড। ক্ষমতা থ্রেশহোল্ডগুলিতে Prometheus সতর্কতার সাথে মিলিত, আপনি ক্রিটিক্যাল হওয়ার আগে ভলিউমগুলিকে সক্রিয়ভাবে প্রসারিত করতে পারেন, বা সম্প্রসারণ সম্পূর্ণরূপে স্বয়ংক্রিয়ভাবে করতে পারেন।

আপনি k3s-এ PostgreSQL, MySQL, MongoDB, বা Redis চালাচ্ছেন না কেন — বেয়ার মেটাল সার্ভারে, AWS EC2, Azure VM, GCP ইনস্ট্যান্স, বা অন-প্রিমিসেস ডেটাসেন্টার হার্ডওয়্যারে — লংহর্ন স্টোরেজ ফাউন্ডেশন প্রদান করে যা আপনাকে আপনার ডেটা নিয়ে দুশ্চিন্তা করার পরিবর্তে মনোযোগ দিতে দেয়। এটি ইনস্টল করুন, এটি কনফিগার করুন, এটি নিরীক্ষণ করুন এবং আপনার উত্পাদন ডেটা দিয়ে এটিকে বিশ্বাস করুন৷