Kubernetes بدون storage پایدار یعنی هر Pod restart = از دست رفتن داده. روی cloud، EBS/PD/Azure Disk هست؛ روی bare-metal یا multi-cloud، تیم‌ها اغلب می‌مانند بین:

NFS تک‌نقطه شکست
آرایه SAN گران و غیرقابل‌حمل
Ceph قدرتمند اما سنگین برای cluster کوچک/متوسط

Longhorn پاسخ Rancher (حالا SUSE) است:

Cloud native distributed block storage for Kubernetes — Easy to use, 100% open source, run anywhere.

یعنی block storage با replication داخل خود cluster — بدون SAN خارجی، بدون license open-core.

CNCF Incubating Project. آخرین docs پایدار: v1.12.1.

مشکل persistent storage روی Kubernetes

local PV:
  سریع — بدون HA؛ node down = data risk

cloud disk CSI:
  HA در cloud — vendor lock، هزینه، latency بین AZ

external NFS:
  ساده — SPOF، performance محدود

Longhorn:
  PVC استاندارد → volume با N replica روی nodeهای مختلف
  UI + snapshot + backup به S3

Longhorn برای block (RWO) طراحی شده — دیتابیس، stateful app، VM disk. برای shared filesystem چند-writer همزمان، CubeFS یا NFS/CephFS مناسب‌تر است.

Longhorn چیست؟

Longhorn سیستم distributed block storage سبک برای Kubernetes است که:

• هر volume را با controller اختصاصی (Engine) و چند Replica همگام نگه می‌دارد
• همه چیز را به‌صورت microservices داخل cluster اجرا می‌کند
• از CSI برای PVC/PV استاندارد استفاده می‌کند
• snapshot افزایشی و backup به S3-compatible یا NFS دارد
• Disaster Recovery volume بین clusterها می‌سازد
• با UI مدیریت volume، disk، node، backup را ساده می‌کند
• upgrade بدون قطع کامل IO را هدف می‌گیرد

Repo: github.com/longhorn/longhorn

Originally: Rancher Labs → CNCF

License: Apache 2.0

معماری: Control Plane و Data Plane

طبق Concepts:

Pod (workload)
    │ CSI mount
    ▼
Longhorn Engine  ← روی همان node که Pod attach شده
    │ sync write
    ├── Replica A (node-1 disk)
    ├── Replica B (node-2 disk)
    └── Replica C (node-3 disk)

Longhorn Manager (DaemonSet روی هر node)
    └── CR volumes / engines / replicas + API برای UI و CSI

Longhorn Manager (control plane)

• DaemonSet روی هر node
• الگوی Kubernetes controller / operator
• ساخت Volume CR، Engine، Replica
• پاسخ به CSI plugin و Longhorn UI

Longhorn Engine (data plane)

• یک Engine per volume — failure یک controller فقط همان volume را می‌زند
• همیشه روی nodeی که volume به آن attach است اجرا می‌شود
• write را synchronous به همه replicaهای سالم می‌فرستد
• با N replica، تحمل تا N−1 شکست replica (حداقل یک replica سالم لازم است)

Replicas

• هر replica روی node/disk جدا ترجیح دارد
• داده به‌صورت thin provisioned (sparse files در V1)
• chain از snapshotها = حالت فعلی volume

CSI Driver / Plugin

PVC → csi-provisioner → Longhorn Manager → Volume CR
Pod schedule → csi-attacher → Engine on node
kubelet → CSI node plugin → format/mount → Pod

قابلیت‌های CSI: create، delete، attach، detach، mount، snapshot. بقیه قابلیت‌ها (backup target، recurring، DR، disk management) عمدتاً از Longhorn UI/API.

Longhorn UI

داشبورد برای:

• volumes و replicas
• snapshots / backups
• nodes و disks (space usage)
• settings و recurring jobs

V1 vs V2 Data Engine

فعال‌سازی V2 (پس از نصب و آماده‌سازی node):

kubectl patch settings.longhorn.io v2-data-engine \
  -n longhorn-system \
  --type merge \
  -p '{"value":"true"}'

StorageClass با V2:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-v2
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
parameters:
  numberOfReplicas: "3"
  dataEngine: "v2"

Preflight با SPDK:

longhornctl --kubeconfig ~/.kube/config \
  --image longhornio/longhorn-cli:v1.12.1 \
  install preflight --enable-spdk

برای workload حیاتی، مگر validation کامل روی نسخه خودتان، V1 مسیر امن‌تر است.

Snapshot، Backup، Disaster Recovery

Snapshot (primary / داخل cluster)

• Point-in-time روی replicaها
• زنجیره differencing disk (مثل لایه‌های image)
• read index برای پیدا کردن آخرین داده هر 4K block
• حداکثر حدود ۲۵۴ snapshot per volume (محدودیت اندازه read index)
• CSI VolumeSnapshot از v1.3 می‌تواند snapshot یا backup بسازد

Backup (secondary storage)

Backup به Backupstore خارج cluster:

• S3-compatible (AWS S3، MinIO، …)
• NFS

بر اساس change block detection — incremental و کارآمدتر از کپی کامل هر بار.

Snapshot (local)  →  سریع، وابسته به cluster
Backup (S3/NFS)  →  محافظت در برابر از دست رفتن کل cluster

Recurring jobs

زمان‌بندی snapshot و backup از UI یا CR:

apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: backup-daily
  namespace: longhorn-system
spec:
  cron: "0 2 * * *"
  task: backup
  groups:
  - default
  retain: 7
  concurrency: 2

PVC را با label به group وصل کنید تا job اعمال شود.

Disaster Recovery (DR) Volume

Longhorn می‌تواند از backupstore یک DR volume در cluster دیگر بسازد:

• replication خارجی کل datastore را از صفر بازسازی نمی‌کند
• granularity در سطح volume
• در حادثه: failover با RPO/RTO تعریف‌شده

این برای multi-cluster DR سبک‌تر از «بازسازی کامل SAN» است.

Thin provisioning و اندازه volume

• Volume فقط فضای مصرف‌شده واقعی را روی دیسک می‌گیرد (مثلاً PVC ۲۰GB با ۱GB داده ≈ ۱GB روی disk × replica count)
• Shrink خودکار بعد از delete فایل در filesystem نیست — Longhorn سطح block است، نه FS؛ حذف فایل داخل ext4 لزوماً space روی sparse را آزاد نمی‌کند مگر عملیات خاص (trim و غیره در محدودیت‌های نسخه)

Volume expansion از StorageClass با allowVolumeExpansion: true پشتیبانی می‌شود.

نصب

پیش‌نیاز عمومی

• Kubernetes (نسخه پشتیبانی‌شده در docs همان release)
• هر worker: فضای دیسک کافی، open-iscsi برای V1
• شبکه پایدار بین nodeها (replication sync حساس به latency)
• Privileged pods / مناسب برای storage CSI

Helm (توصیه‌شده)

helm repo add longhorn https://charts.longhorn.io
helm repo update

helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --version 1.12.1

kubectl -n longhorn-system get pod

kubectl manifest

kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.12.1/deploy/longhorn.yaml

دسترسی به UI

kubectl -n longhorn-system get svc
# longhorn-frontend — معمولاً ClusterIP

kubectl -n longhorn-system port-forward svc/longhorn-frontend 8080:80
# باز کردن http://localhost:8080

در production: Ingress + TLS با cert-manager و auth مناسب — UI را بدون محافظت expose نکنید.

استفاده روزمره: StorageClass و PVC

StorageClass پیش‌فرض

پس از نصب معمولاً longhorn ساخته می‌شود:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "30"
  fromBackup: ""
  fsType: "ext4"
  dataLocality: "disabled"   # یا best-effort / strict-local

PVC + Pod

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-data
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: password
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: mysql-data

ReadWriteOnce — یک node writer در زمان. برای چند Pod writer همزمان روی یک PVC، Longhorn مدل file RWX عمومی (مثل NFS) نیست؛ از RWX مبتنی بر share manager در سناریوهای خاص پشتیبانی دارد اما use-case اصلی block RWO است.

Volume CR مستقیم

kubectl get volumes.longhorn.io -n longhorn-system
kubectl describe volume.longhorn.io <name> -n longhorn-system

تنظیمات مهم production

Backup target مثال (S3)

در UI یا Settings:

s3://my-backups@us-east-1/

Secret با access key در longhorn-system. برای MinIO endpoint سفارشی، پارامترهای S3 در docs همان نسخه را دنبال کنید.

Disk و Node

• چند disk per node از UI قابل تعریف است
• node/disk را می‌توان disable / eviction کرد برای maintenance
• tag برای placement (مثلاً ssd, nvme)

Rebuild و failure

Replica fail (disk/node down)
  → Engine با replicaهای سالم ادامه می‌دهد
  → Manager replica جدید می‌سازد
  → sync از healthy replicas
  → volume به replica count هدف برمی‌گردد

اگر همه replicaهای یک volume از دست بروند و backup نباشد — data loss. برای همین:

1. numberOfReplicas ≥ 3 در production
2. backup دوره‌ای به S3/NFS
3. antiaffinity واقعی (replicas روی nodeهای جدا)

مقایسه: Longhorn در کجای stack storage؟

Longhorn جایگزین object store یا data lake نیست — block برای stateful workloads داخل Kubernetes است.

Observability و troubleshooting

kubectl -n longhorn-system get pod
kubectl -n longhorn-system get volumes.longhorn.io
kubectl -n longhorn-system logs -l app=longhorn-manager --tail=100

# PVC events
kubectl describe pvc mysql-data

مشکلات رایج:

Metrics: Longhorn و instance managerها Prometheus metrics دارند — latency، rebuild، space.

شبکه پایدار مهم است — CNI مثل Cilium و latency بین node روی sync write اثر مستقیم دارد.

امنیت

• UI را پشت auth / SSO / network policy بگذارید
• Backup bucket با encryption و IAM محدود
• RBAC Kubernetes روی PVC و Longhorn CRها
• Volume encryption (طبق قابلیت نسخه — تنظیمات encrypt در docs)
• جدا کردن disk Longhorn از OS disk وقتی ممکن است
• NetworkPolicy برای محدود کردن longhorn-system

State خود Longhorn CRها در etcd است — backup etcd control plane را فراموش نکنید؛ backup volume داده جدا از backup etcd است.

ارتباط با stack شما

StatefulSet / Deployment
  └── PVC (Longhorn CSI)
        ├── Engine + Replicas روی worker disks
        └── Backup → S3 / NFS

Cluster foundation
  ├── [etcd](/blog/etcd-distributed-key-value-store-guide/) — CRD state
  ├── CRI ([containerd](/blog/containerd-container-runtime-guide/))
  ├── CNI ([Cilium](/blog/cilium-ebpf-kubernetes-networking/))
  └── [CoreDNS](/blog/coredns-kubernetes-dns-guide/)

Ops
  ├── [Argo CD](/blog/argo-project-kubernetes-gitops-cicd/) — deploy Longhorn + apps
  ├── [cert-manager](/blog/cert-manager-kubernetes-tls-certificates/) — TLS برای UI/Ingress
  └── [Crossplane](/blog/crossplane-kubernetes-control-plane-guide/) — optional: provision backup bucket

برای VM روی Kubernetes (KubeVirt)، Longhorn اغلب به‌عنوان backend disk volume استفاده می‌شود.

Best practices

1. حداقل ۳ node با disk جدا برای replica
2. numberOfReplicas: 3 برای production
3. Backup target از روز اول — نه بعد از حادثه
4. Recurring backup + retain سیاست مشخص
5. Monitor disk usage قبل از ۹۰٪ — rebuild به space نیاز دارد
6. Data locality را آگاهانه انتخاب کنید (عملکرد vs توزیع)
7. Drain با سیاست Longhorn — نه فقط kubectl drain کور
8. V1 برای critical path تا V2 را با workload واقعی تست کنید
9. جدا کردن OS و data disk روی nodeها
10. تست restore از backup — backup بدون restore تست‌شده بی‌فایده است

چه زمانی Longhorn؟

✅ استفاده کنید

• Kubernetes روی bare-metal / edge / homelab با نیاز HA block
• StatefulSets: MySQL، PostgreSQL، Redis (با درک RWO)
• نیاز به snapshot/backup ساده بدون تیم Ceph
• DR بین دو cluster با backupstore مشترک
• تیم‌هایی که UI و سادگی ops می‌خواهند

⚠️ شاید نه

• هزاران volume با IOPS بسیار بالا بدون sizing درست → ممکن است Ceph/cloud disk بهتر باشد
• نیاز RWX file سنگین برای AI dataset → CubeFS / NFS
• فقط یک node → replication معنی ندارد
• managed Kubernetes که cloud disk ارزان و کافی است

جمع‌بندی

Longhorn فاصله بین «PVC بدون HA» و «Ceph سنگین» را پر می‌کند: block storage واقعی، replicate‌شده، قابل backup، با UI — داخل همان Kubernetes که اپ را اجرا می‌کنید.

قدم بعدی

1. سه node با disk آزاد + open-iscsi
2. helm install longhorn نسخه ۱.۱۲.x
3. یک PVC تست + Pod write/read
4. Backup target به MinIO/S3 وصل کنید و یک backup بگیرید
5. Restore را در namespace دیگر تمرین کنید
6. (اختیاری) V2 را روی node آزمایشی با NVMe ارزیابی کنید

دوره رایگان: Longhorn Basics از سایت پروژه.

منابع

• Longhorn — longhorn.io
• Documentation v1.12.1
• Architecture & Concepts
• Install with Helm
• GitHub — longhorn/longhorn
• CNCF Longhorn

منتشر شده در P30Light — بخش زیرساخت و سرور.