راه‌اندازی Longhorn برای ذخیره‌سازی پایدار در کلاستر Kubernetes روی VPS و سرور اختصاصی

هر کس که یک کلاستر Kubernetes روی چند VPS یا سرور اختصاصی بالا آورده باشد، دیر یا زود به همین سوال می‌رسد: وقتی یک Pod دیتابیس یا هر ورک‌لود stateful دیگری روی یک نود بالا می‌آید، داده‌هایش کجا ذخیره شود که با ری‌استارت یا خرابی همان نود از بین نرود؟ راه‌اندازی Longhorn در Kubernetes دقیقاً همین مشکل را حل می‌کند: یک لایه ذخیره‌سازی بلاک تکرارشونده (replicated) که بین چند نود کپی نگه می‌دارد و اگر یک سرور از دسترس خارج شود، حجم (Volume) روی نودهای دیگر همچنان در دسترس می‌ماند.

چرا ذخیره‌سازی پایدار در Kubernetes چالش‌برانگیز است؟

به‌صورت پیش‌فرض، Kubernetes خودش هیچ راهکار ذخیره‌سازی توزیع‌شده‌ای ندارد. اگر از hostPath یا local volume استفاده کنید، داده فقط روی همان نودی که Pod اول بار زمان‌بندی شده ذخیره می‌شود. اگر آن نود از کار بیفتد یا Pod به نود دیگری منتقل شود، داده در دسترس نیست یا اصلاً از بین رفته است.

راه‌حل کلاسیک این مشکل، Ceph است؛ اما یک کلاستر کامل Ceph با MON، OSD و MGR جداگانه معمولاً برای یک تیم کوچک یا یک کلاستر با چند VPS بیش از حد سنگین است. هم به منابع بیشتری نیاز دارد و هم عملیات نگه‌داری‌اش زمان‌بر است.

Longhorn چیست و چه تفاوتی با Ceph دارد؟

Longhorn یک سیستم ذخیره‌سازی بلاک توزیع‌شده و سبک است که توسط Rancher توسعه داده شده و اکنون یک پروژه CNCF است. برخلاف Ceph، Longhorn نیازی به کامپوننت‌های جداگانه مانیتورینگ یا مدیریت کلاستر ندارد؛ هر نود Kubernetes که Longhorn روی آن نصب شود، هم می‌تواند میزبان replica باشد و هم Pod مصرف‌کننده حجم.

هر Volume در Longhorn به چند replica تقسیم می‌شود که هرکدام روی یک نود متفاوت ذخیره می‌شوند. اگر نودی که یکی از replicaها روی آن است از دسترس خارج شود، Longhorn به‌صورت خودکار یک replica جدید روی نود سالم می‌سازد و از داده‌های باقی‌مانده دوباره sync می‌کند.

ویژگی	Longhorn	Ceph (کلاستر کامل)
حداقل نودهای پیشنهادی	۳ نود	۳ تا ۵ نود با نقش‌های جدا (MON/OSD/MGR)
پیچیدگی نصب	یک Helm chart، بدون کامپوننت جانبی	نیاز به Rook یا نصب دستی، چند کامپوننت مجزا
رابط مدیریتی	داشبورد وب توکار	نیاز به ابزار جانبی (مثل Rook toolbox)
مناسب برای	کلاسترهای کوچک تا متوسط روی VPS	کلاسترهای بزرگ با نیاز به object/file/block storage هم‌زمان
Backup و Snapshot	توکار، با هدف S3-compatible	نیاز به پیکربندی جداگانه

اگر فقط به ذخیره‌سازی بلاک برای PVC نیاز دارید و کلاستر شما چند نود VPS یا سرور اختصاصی است، Longhorn معمولاً سریع‌تر بالا می‌آید و نگه‌داری‌اش ساده‌تر است.

پیش‌نیازها برای نصب Longhorn

قبل از شروع نصب، این موارد باید آماده باشد:

• یک کلاستر Kubernetes در حال اجرا (با kubeadm، k3s یا هر روش دیگری) روی حداقل سه VPS یا سرور اختصاصی، تا replica count پیش‌فرض ۳ معنا داشته باشد.
• بسته open-iscsi روی تمام نودها نصب و سرویس iscsid فعال باشد؛ Longhorn برای اتصال حجم‌ها از iSCSI استفاده می‌کند.
• فضای دیسک خالی روی هر نود (یک دیسک یا پارتیشن جداگانه بهتر از فضای اشتراکی روی دیسک سیستم‌عامل است).
• دسترسی kubectl با مجوز کافی برای ساخت namespace، CRD و DaemonSet.

# روی هر نود (Ubuntu/Debian)
sudo apt update
sudo apt install -y open-iscsi
sudo systemctl enable --now iscsid

نصب Longhorn با Helm

روش پیشنهادی نصب، استفاده از Helm chart رسمی است؛ به‌روزرسانی و مدیریت نسخه را ساده‌تر می‌کند.

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

kubectl create namespace longhorn-system

helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --set defaultSettings.defaultReplicaCount=3

بعد از چند دقیقه، وضعیت Podها را بررسی کنید تا مطمئن شوید همه در وضعیت Running هستند:

kubectl -n longhorn-system get pods

اگر ترجیح می‌دهید به Helm وابسته نباشید، همان نتیجه با اعمال مستقیم manifest رسمی هم قابل دستیابی است:

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

پیکربندی StorageClass و تعداد Replica

Longhorn به‌صورت پیش‌فرض یک StorageClass به نام longhorn می‌سازد و آن را default قرار می‌دهد. اگر بخواهید تعداد replica را برای یک کلاس خاص تغییر دهید (مثلاً برای دیتابیس‌های حساس‌تر، replica بیشتر)، یک StorageClass جدید تعریف کنید:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-db
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "30"
  fromBackup: ""

برای کلاسترهای کوچک‌تر که فقط دو نود دارند، تعداد replica را روی ۲ تنظیم کنید؛ در غیر این صورت Longhorn هرگز نمی‌تواند سومین replica را جای‌گذاری کند و Volume در وضعیت Degraded باقی می‌ماند.

ساخت PVC و تست ذخیره‌سازی تکرارشونده

با StorageClass آماده، ساخت یک PersistentVolumeClaim تفاوتی با هر provisioner دیگری ندارد:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 10Gi

برای تست واقعی رفتار replicated، یک Pod بسازید که این PVC را mount کند، چیزی در آن بنویسد، سپس نودی که replica اصلی رویش قرار دارد را با kubectl drain از چرخه خارج کنید. Pod باید روی نود دیگری دوباره زمان‌بندی شود و همان داده را از یکی از replicaهای باقی‌مانده بخواند؛ این دقیقاً همان سناریویی است که hostPath از پس آن برنمی‌آید.

دسترسی به داشبورد مدیریتی Longhorn

Longhorn یک UI وب توکار دارد که وضعیت Volumeها، نودها و فضای هر دیسک را نشان می‌دهد. برای دسترسی سریع در محیط تست:

kubectl -n longhorn-system port-forward svc/longhorn-frontend 8080:80

سپس با مرورگر به http://localhost:8080 بروید. برای محیط تولید، بهتر است این سرویس را پشت یک Ingress با احراز هویت (مثلاً Basic Auth یا OAuth proxy) قرار دهید، نه اینکه مستقیم روی اینترنت باز بماند.

بکاپ‌گیری و Snapshot

یکی از دلایل اصلی انتخاب Longhorn به‌جای volume محلی ساده، پشتیبانی توکار از Snapshot و Backup است. از داشبورد یا با یک منبع (Backup Target) سازگار با S3 می‌توانید بکاپ دوره‌ای تعریف کنید:

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

این job هر شب ساعت ۳ بامداد از تمام Volumeهای گروه default بکاپ می‌گیرد و هفت نسخه آخر را نگه می‌دارد؛ نسخه‌های قدیمی‌تر خودکار حذف می‌شوند.

نکات بهینه‌سازی و عیب‌یابی رایج

• پهنای باند شبکه بین نودها: چون replicaها دائم با هم sync می‌شوند، اگر VPSهای شما روی شبکه داخلی پرسرعت نباشند، تأخیر sync قابل توجه می‌شود. برای کلاسترهایی که حجم دیتای زیاد جابه‌جا می‌کنند، سرور اختصاصی با شبکه داخلی اختصاصی معمولاً پایدارتر از VPSهای اشتراکی است.
• دیسک جداگانه: مسیر پیش‌فرض داده Longhorn (/var/lib/longhorn) را روی یک دیسک یا پارتیشن مجزا از دیسک سیستم‌عامل قرار دهید تا I/O سیستم با I/O ذخیره‌سازی رقابت نکند.
• Volume در وضعیت Degraded: معمولاً یعنی Longhorn نتوانسته تعداد replica خواسته‌شده را روی نودهای موجود جای‌گذاری کند؛ یا تعداد نودها کم است یا فضای دیسک کافی نیست.
• iSCSI فراموش‌شده روی یک نود جدید: اضافه کردن نود جدید به کلاستر بدون نصب open-iscsi رایج‌ترین علتی است که Pod با خطای mount گیر می‌کند.

جمع‌بندی

Longhorn برای تیم‌هایی که یک کلاستر Kubernetes چند‌نودی روی VPS یا سرور اختصاصی دارند و به ذخیره‌سازی بلاک پایدار نیاز دارند، بدون این‌که بخواهند یک کلاستر کامل Ceph مدیریت کنند، گزینه‌ای عملی است. نصب با Helm چند دقیقه بیشتر طول نمی‌کشد، داشبورد مدیریتی همه‌چیز را قابل مشاهده می‌کند و Backup/Snapshot از ابتدا در دسترس است.

اگر هنوز زیرساخت کلاستر خود را راه‌اندازی نکرده‌اید، می‌توانید نودهای Kubernetes را روی VPS ابری آریانت بالا ببرید، یا برای نودهایی که به I/O و شبکه پایدارتری نیاز دارند (مثل نودهای ذخیره‌سازی Longhorn)، از سرور اختصاصی آریانت استفاده کنید.