تخزين Longhorn لمجموعات الإنتاج k3s: توسيع PVC الديناميكي والنسخ المتماثل والتعافي من الكوارث

هو المشكلة الأصعب في Kubernetes. الحوسبة عديمة الحالة وقابلة للاستبدال — اقتل حجرة، وحدد موعدًا لأخرى. تحتوي الشبكات على مكونات إضافية وشبكات خدمة ناضجة لـ CNI. لكن التخزين؟ التخزين هو المكان الذي تعيش فيه الحالة، حيث تستمر البيانات عبر عمليات إعادة التشغيل، حيث يمكن أن يؤدي أي تكوين خاطئ لمرة واحدة إلى فقدان البيانات بشكل دائم. بالنسبة لمجموعات k3s التي تقوم بتشغيل أحمال عمل الإنتاج - قواعد البيانات وقوائم انتظار الرسائل وحالة التطبيق - فإنك تحتاج إلى حل تخزين موزع ومرن وقابل للتوسيع وقابل للتشغيل. Longhorn هو هذا الحل.

Longhorn هو نظام تخزين كتلة موزع خفيف الوزن وموثوق وسهل الاستخدام لـ Kubernetes. تم تطويره في الأصل بواسطة Rancher Labs (التي أصبحت الآن جزءًا من SUSE)، وهو عبارة عن مشروع حضانة CNCF مصمم خصيصًا للمجموعات حيث البساطة مهمة ولكن موثوقية الإنتاج غير قابلة للتفاوض. على عكس Ceph، الذي يتطلب عقد تخزين مخصصة وخبرة عميقة، أو مزود المسار المحلي، الذي لا يوفر أي تكرار، يحقق Longhorn التوازن الدقيق الذي تحتاجه مجموعات k3s: النسخ المتماثل الموزع عبر العقد، وتوسيع الحجم الديناميكي، والنسخ الاحتياطي المتكامل لتخزين الكائنات السحابية، واللقطات والتعافي من الكوارث - كل ذلك تتم إدارته من خلال واجهة مستخدم نظيفة وCRD الأصلية لـ Kubernetes.

يغطي هذا الدليل كل ما تحتاجه لنشر Longhorn على k3s للإنتاج: الأجزاء الداخلية للهندسة المعمارية، وطرق التثبيت، وتكوين StorageClass، وتوسيع PVC الديناميكي، واستراتيجيات النسخ المتماثل، والنسخ الاحتياطي والتعافي من الكوارث، وتشفير الحجم، وضبط الأداء لقواعد البيانات، والمراقبة، واستكشاف الأخطاء وإصلاحها. تأتي كل توصية مع تكوين تم اختباره على مستوى الإنتاج ويمكنك التكيف مع بيئتك.

العمارة ذات القرون الطويلة

يعد فهم بنية Longhorn أمرًا ضروريًا لاتخاذ قرارات مستنيرة بشأن النسخ المتماثل والأداء ومعالجة الفشل. يتكون Longhorn من ثلاثة مكونات أساسية تعمل معًا لتوفير مساحة تخزين موزعة أعلى الأقراص المحلية المتصلة بعقد Kubernetes.

يعملLonghorn Managerكمجموعة DaemonSet على كل عقدة في المجموعة. إنه مستوى التحكم في Longhorn - فهو يتعامل مع مكالمات API، وينسق إنشاء وحدة التخزين، ويدير النسخ المتماثل، وينسق اللقطات والنسخ الاحتياطية، ويتواصل مع خادم Kubernetes API لإدارة دورة حياة PersistentVolume وPersistentVolumeClaim. عند إنشاء PVC الذي يشير إلى Longhorn StorageClass، يتلقى Longhorn Manager الطلب من خلال برنامج تشغيل CSI، ويقوم بتوفير وحدة التخزين، وجدولة النسخ المتماثلة الخاصة به عبر العقد المتاحة.

محركLonghornعبارة عن وحدة تحكم تخزين لكل وحدة تخزين يتم تنفيذها كعملية مساحة مستخدم Linux (استنادًا إلى شوكة محرك Rancher Longhorn). يحصل كل مجلد على محرك خاص به يعمل على العقدة حيث يتم إرفاق المجلد. يعالج المحرك جميع عمليات الإدخال/الإخراج الخاصة بالقراءة والكتابة لوحدة التخزين هذه، وينسخ عمليات الكتابة بشكل متزامن إلى كافة النسخ المتماثلة التي تم تكوينها قبل الإقرار بالكتابة إلى التطبيق. تعني هذه البنية لكل مجلد أن أي عطل أو توقف في محرك أحد المجلدات لا يؤثر على أي مجلد آخر - وهي خاصية عزل مهمة للإنتاج.

النسخ المتماثلةهي عمليات تخزين البيانات الفعلية. تقوم كل نسخة متماثلة بتخزين نسخة كاملة من بيانات وحدة التخزين على القرص المحلي للعقدة التي تعمل فيها. افتراضيًا، تقوم Longhorn بإنشاء ثلاث نسخ متماثلة لكل مجلد، موزعة عبر عقد مختلفة (ومناطق مختلفة اختياريًا). تستخدم النسخ المتماثلة آلية النسخ عند الكتابة للقطات، مما يجعل إنشاء اللقطة فوريًا بغض النظر عن حجم الصوت.

توفر هذه البنية العديد من الخصائص الأساسية لاستخدام الإنتاج.تحمل الخطأ:مع ثلاث نسخ متماثلة عبر ثلاث عقد، وحدة التخزين تنجو من فشلين في العقدة المتزامنة. عزل: كل مجلدله عملية محرك خاصة به، لذلك لا يمكن أن يتكرر الخطأ أو التعليق في مجلد واحد. بساطة:لا يوجد عقد تخزين مخصصة، ولا مجموعات Ceph أو GlusterFS منفصلة - يعمل Longhorn على نفس العقد العاملة مثل كبسولات التطبيق الخاصة بك، باستخدام الأقراص المحلية الخاصة بها.Kubernetes-native:تتم إدارة كل شيء من خلال CRDs وkubectl وواجهة Kubernetes CSI.

تثبيت Longhorn على 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

عبر Rancher App Marketplace

إذا كان Rancher يدير مجموعة k3s الخاصة بك، فانتقل إلىApps & السوق ← الرسوم البيانية ← Longhornفي واجهة مستخدم Rancher. حدد مساحة الاسم المستهدفة (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

بعد التثبيت: اجعل Longhorn هو فئة التخزين الافتراضية

# 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

تكوين فئة التخزين للإنتاج

تعمل فئة 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 كلاً من توسيععبر الإنترنت(يظل الحجم متصلاً ومثبتًا أثناء نموه) وتوسيعدون اتصال بالإنترنت(يتم فصل الحجم أولاً). يعد التوسع عبر الإنترنت هو الأسلوب الافتراضي والموصى به للإنتاج لأنه يتجنب توقف التطبيق.

تمكين توسيع الحجم في StorageClass

الشرط الأساسي لتوسيع PVC الديناميكي هو أن StorageClass يجب أن يحتوي علىallowVolumeExpansion: true. يتضمن StorageClass الافتراضي Longhorn هذا بالفعل، ولكن إذا كان لديك 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 لوحدات التخزين المؤقتة/ذاكرة التخزين المؤقت حيث يكون فقدان البيانات مقبولاً.

تتحكم منطقة البياناتفي ما إذا كان Longhorn يحاول الاحتفاظ بنسخة متماثلة على نفس العقدة مثل الكبسولة التي تستهلك وحدة التخزين. هناك ثلاثة أوضاع:

• معطل— تتم جدولة النسخ المتماثلة بناءً على المساحة المتوفرة ومكافحة التقارب. قد تقرأ الحجرة من نسخة متماثلة على عقدة بعيدة، مما يضيف زمن استجابة الشبكة إلى كل عملية إدخال/إخراج.
• أفضل جهد- يحاول Longhorn وضع نسخة متماثلة واحدة على نفس العقدة مثل الكبسولة المستهلكة. إذا نفدت مساحة العقدة المحلية أو تم ترحيل الكبسولة، فستظل وحدة التخزين تعمل ولكن قد يكون لها زمن استجابة أعلى قليلاً. هذا هو الإعداد الموصى به لمعظم أحمال العمل.
• محلي متشدد — لا يمكن استخدام وحدة التخزين إلا على العقدة التي تحتوي على نسخة متماثلة محلية. إذا تمت جدولة الكبسولة إلى عقدة بدون نسخة متماثلة محلية، فسيفشل مرفق وحدة التخزين. استخدم هذا فقط لأعباء العمل ذات النسخة المفردة الحساسة لزمن الاستجابة حيث تقبل مقايضة المتانة.

# 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

التعافي من الكوارث

Longhorn آلية مدمجة لاستعادة القدرة على العمل بعد الكوارث من خلال وحدات تخزين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) يدعم

افتراضيًا، تكون وحدات تخزين Longhorn هي ReadWriteOnce (RWO) — ويمكن تركيبها بواسطة حجرة واحدة على عقدة واحدة. بالنسبة لأحمال العمل التي تحتاج إلى تخزين مشترك عبر منصات متعددة (على سبيل المثال، تحميلات الوسائط المشتركة وملفات التكوين وعناصر نموذج ML)، تدعم Longhorn ReadWriteMany (RWX) من خلال خادم NFS متكامل.

عندما يطلب PVC وضع الوصول إلى RWX، تقوم Longhorn تلقائيًا بنشر حجرة مدير المشاركة التي تقوم بتشغيل خادم NFS مدعومًا بوحدة تخزين Longhorn. يمكن للقرون المتعددة بعد ذلك تركيب وحدة التخزين في وقت واحد عبر 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

يتطلب تشغيل قواعد البيانات على Longhorn اهتمامًا دقيقًا بمعلمات StorageClass وتقارب الجراب وتكامل النسخ الاحتياطي. إن محرك Longhorn لكل وحدة تخزين والنسخ المتماثل المتزامن يجعله مناسبًا تمامًا لأحمال عمل قاعدة البيانات، ولكنك تحتاج إلى تكوينه بشكل صحيح للحصول على أداء وموثوقية على مستوى الإنتاج.

PostgreSQL مجموعة الحالة مع Longhorn

# 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 مجموعة الحالة مع Longhorn

# 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.لا تشارك قرص نظام التشغيل مع بيانات Longhorn. أضف محركات أقراص NVMe أو SSD مخصصة وقم بتكوينها كأقراص Longhorn. وهذا يمنع تعارض الإدخال/الإخراج بين نظام التشغيل ووحدات تخزين قاعدة البيانات.

# 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 CPU لمعالجة الإدخال/الإخراج والنسخ المتماثل. يحتفظ إعدادguaranteedInstanceManagerCPUبنسبة مئوية من العقدة CPU لمديري مثيلات Longhorn، مما يمنع جوع CPU تحت التحميل.

قم بضبط عدد النسخ المتماثلة.بالنسبة لقواعد البيانات التي تحتوي بالفعل على نسخ متماثل على مستوى التطبيق (النسخ المتماثل المتدفق لـ PostgreSQL، والنسخ المتماثل لمجموعة MySQL، ومجموعات النسخ المتماثلة لـ MongoDB)، يمكنك تقليل عدد النسخ المتماثلة لـ Longhorn إلى 2 بدلاً من 3. يوفر النسخ المتماثل لقاعدة البيانات طبقة إضافية من حماية البيانات، ويعني عدد أقل من النسخ المتماثلة لـ Longhorn تضخيمًا أقل للكتابة وإنتاجية كتابة أفضل.

استخدم ext4 عبر xfs للإدخال/الإخراج العشوائي الصغير.بينما يتفوق xfs في عمليات الكتابة المتسلسلة الكبيرة، فإن أداء ext4 بشكل عام أفضل بالنسبة لنمط الإدخال/الإخراج العشوائي الصغير النموذجي لأحمال عمل قاعدة البيانات. قم بتعيينfsType: ext4في StorageClass الخاص بك.

جدولة العقدة وإدارة الأقراص

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

مع Prometheus وGrafana

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

Key Grafana التي تم إنشاؤها لمراقبة Longhorn ما يلي: وحدة تخزين IOPS (قراءة/كتابة)، وإنتاجية وحدة التخزين (MB/s)، وزمن استجابة وحدة التخزين (p50/p95/p99)، وتقدم إعادة بناء النسخة المتماثلة، وسعة تخزين العقدة واستخدامها، وحالة النسخ الاحتياطي والعمر، وعدد اللقطات لكل وحدة تخزين.

k3s مع مجموعة تخزين كاملة ذات قرون طويلة

يوضح الرسم البياني التالي كيف تتناسب Longhorn مع مجموعة إنتاج k3s الكاملة، بدءًا من الخوادم المعدنية وحتى حجرات التطبيقات، مع إدارة Rancher وإمكانية مراقبة Prometheus/Grafana.

مع حلول تخزين Kubernetes الأخرى

Longhorn ليس خيار التخزين الوحيد لـ Kubernetes. يساعدك فهم كيفية مقارنتها بالبدائل على اتخاذ القرار الصحيح لمتطلباتك المحددة.

Longhorn vs Rook-Ceph:Ceph هو النظام الأكثر قوة - فهو يدعم تخزين الكائنات وتخزين الملفات وتخزين الكتل باستخدام خوارزمية وضع CRUSH المتطورة. ومع ذلك، يتطلب Ceph ما لا يقل عن 3 عقد OSD مخصصة، وذاكرة وصول عشوائي (RAM) كبيرة (4 جيجابايت على الأقل لكل برنامج OSD الخفي)، وخبرة تشغيلية عميقة. بالنسبة لمجموعات k3s التي تحتوي على 3-10 عقد، توفر Longhorn 90% من القيمة مقابل 10% من تكلفة التشغيل.

Longhorn vs OpenEBS Mayastor: يستخدمMayastor تقنية NVMe-over-Fabrics للنسخ المتماثل عالي الأداء، مما يحقق زمن وصول أقل من النسخ المتماثل المستند إلى TCP الخاص بـ Longhorn. إذا كان IOPS الخام وزمن الوصول أقل من مللي ثانية هو اهتمامك الأساسي ولديك بنية NVMe الأساسية مع شبكة RDMA، فقد يكون Mayastor هو الخيار الأفضل. بالنسبة لمعظم عمليات نشر k3s، فإن النسخ الاحتياطي المتكامل لـ Longhorn، وDR، والبساطة التشغيلية يفوق أداء Mayastor.

Longhorn vs local-path: مزود المسار المحليهو التخزين الافتراضي لـ k3s - فهو ببساطة ينشئ أدلة على نظام الملفات المحلي للعقدة. صفر تكرار، صفر لقطات، صفر تكامل النسخ الاحتياطي. إنه جيد للتطوير ولكنه غير مقبول لبيانات الإنتاج.

تم استخلاص هذه التوصيات من تشغيل Longhorn عبر العشرات من مجموعات الإنتاج k3s التي تشغل أحمال عمل قاعدة البيانات.

1. قم بتعيين حجوزات الموارد لمديري المثيلات. يحتاج مديرو مثيلاتLonghorn (مديرو المحرك والنسخ المتماثلة) إلى CPU مضمون لتجنب توقف الإدخال/الإخراج أثناء ضغط العقدة. اضبطguaranteedInstanceManagerCPUعلى 12% على الأقل في إعدادات Longhorn.

2. استخدم سياسة الاحتفاظ بالاسترداد لأحجام قاعدة البيانات.لا تستخدم أبدًاDeleteلقاعدة البيانات PVCs. تحافظ سياسةRetainعلى PV وبياناتها حتى بعد حذف PVC، مما يمنحك شبكة أمان ضد الحذف غير المقصود.

3. قم بتعطيل النسخة المتماثلة الناعمة المضادة للتقارب للإنتاج.قم بتعيينreplicaSoftAntiAffinity: falseللتأكد من أن النسخ المتماثلة منتشرة دائمًا عبر العقد المختلفة. من خلال خاصية مكافحة التقارب الناعمة، قد تقوم Longhorn بجدولة نسخ متماثلة متعددة على نفس العقدة عندما تكون المساحة ضيقة - وهو ما يتعارض مع غرض النسخ المتماثل.

4. حجز مساحة تخزين على كل عقدة.اضبطstorageMinimalAvailablePercentageعلى 15% على الأقل. وهذا يمنع Longhorn من استهلاك كل مساحة القرص، مما قد يتسبب في مشكلات على مستوى العقد تؤثر على جميع القرون.

5. تمكين الإنقاذ التلقائي.يقوم إعدادautoSalvageتلقائيًا باسترداد وحدات التخزين التي تدخل حالة معطوبة عندما تكون هناك نسخة متماثلة واحدة على الأقل لا تزال سليمة. وهذا يقلل من التدخل اليدوي أثناء فشل العقدة.

6. اضبط فئة الأولوية على مجموعة النظام الحرجة. لا ينبغي أبدًا إخراج مكونات المدير والسائق فيLonghorn أثناء ضغط العقدة. قم بتعيين فئة الأولوية الخاصة بهم علىsystem-cluster-criticalللتأكد من نجاتهم من عملية الإخلاء.

7. قم بتكوين المهام المتكررة لجميع أحجام الإنتاج.يجب أن يحتوي كل حجم إنتاج على مهام لقطة ونسخ احتياطي متكررة. لقطات كل 4 ساعات للتراجع السريع، ونسخ احتياطي يوميًا للتعافي من الكوارث.

8. اختبر تنشيط وحدة تخزين DR بانتظام.قم بإنشاء جدول شهري لتنشيط وحدات تخزين DR في مجموعتك الاحتياطية، والتحقق من سلامة البيانات، وممارسة إجراء تجاوز الفشل. إن خطة DR التي لم يتم اختبارها مطلقًا هي مجرد وثائق.

9. مراقبة صحة الحجم بشكل استباقي.قم بإعداد تنبيهات Prometheus لوحدات التخزين المتدهورة والمعيبة، وسعة تخزين العقدة، وعمر النسخ الاحتياطي، وحالة إعادة بناء النسخة المتماثلة. بحلول الوقت الذي يبلغ فيه المستخدم عن بطء قاعدة البيانات، تكون مشكلة التخزين قد تراكمت لساعات.

10. استخدم أقراص التخزين المخصصة.افصل بيانات Longhorn عن قرص نظام التشغيل. وهذا يمنع تعارض الإدخال/الإخراج، ويمنحك إدارة أفضل للسعة، ويتجنب خطر ملء قرص نظام التشغيل ببيانات Longhorn.

إرشادات النشر الخاصة بالسحابة

AWS — EC2 مع وحدة تخزين مثيلات NVMe

بالنسبة لعمليات نشر AWS، استخدم مثيلاتi3.xlargeأوi3en.xlargeالتي تأتي مع تخزين مثيل NVMe. توفر هذه أداء NVMe الأولي بجزء بسيط من تكلفة EBS IOPS المتوفرة. قم بتنسيق مخزن المثيلات وقم بتكوينه كقرص Longhorn.

# 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، استخدم أجهزة VMStandard_L8s_v3أوStandard_L16s_v3مع وحدة تخزين NVMe المحلية. وبدلاً من ذلك، قم بتوصيل Ultra Disks للحصول على زمن استجابة ثابت أقل من مللي ثانية. تسمح لك Ultra Disks بتكوين 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 محلي

GCP SSD محلي متصل بأجهزةn2-standardأوc3-standardVM. توفر محركات أقراص SSD المحلية 375 جيجابايت لكل قرص مع ما يصل إلى 680.000 قراءة لـ IOPS. قم بتوصيل محركات أقراص 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 مخصصة لـ Longhorn. افصل قرص نظام التشغيل عن أقراص التخزين. استخدم شبكة 10 جيجابت أو 25 جيجابت بين العقد لضمان عدم حدوث اختناق في حركة النسخ المتماثل - يؤدي النسخ المتماثل المتزامن Longhorn إلى إنشاء حركة مرور على الشبكة تتناسب مع إنتاجية الكتابة مضروبة في عدد النسخ المتماثلة.

# 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

Longhorn مزودًا بواجهة مستخدم ويب مدمجة توفر واجهة مرئية لإدارة وحدات التخزين واللقطات والنسخ الاحتياطية والعقد والإعدادات. يمكنك الوصول إليه من خلال Ingress الذي تم تكوينه أثناء التثبيت أو عبر kubectl port-forward.

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

توفر واجهة المستخدم عدة طرق عرض رئيسية: لوحة معلوماتتعرضصحة التخزين على مستوى المجموعة بما في ذلك السعة الإجمالية والمساحة المستخدمة وحالة وحدة التخزين. وحدة تخزينيسردكافة وحدات التخزين مع حالتها (سليمة/متدهورة/معطوبة)، وحجمها، وعدد النسخ المتماثلة، والعقدة المرفقة. يمكنك توسيع وحدات التخزين والتقاطها ونسخها احتياطيًا واستعادتها مباشرةً من طريقة العرض هذه. عقدةتعرضتكوين تخزين كل عقدة وتخصيص القرص وحالة الجدولة.Backup يسردجميع النسخ الاحتياطية المخزنة في هدف النسخ الاحتياطي مع حجمها وحجمها ووقت الإنشاء. يعرض إعدادجميع معلمات تكوين Longhorn مع الأوصاف.

استكشاف المشكلات الشائعة وإصلاحها

وحدات التخزين المتدهورة

تدخل وحدة التخزين إلى الحالة المتدهورة عندما تكون نسخة متماثلة واحدة أو أكثر غير سليمة ولكن وحدة التخزين لا تزال تعمل. تتضمن الأسباب الشائعة فشل العقدة أو امتلاء القرص أو قسم الشبكة.

# 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 Operator، Zalando Postgres Operator) بسلاسة مع Longhorn. يدير المشغل دورة حياة قاعدة البيانات بينما يوفر 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 بشأن حدود السعة، يمكنك توسيع وحدات التخزين بشكل استباقي قبل أن تصبح حرجة، أو أتمتة التوسيع بالكامل.

سواء كنت تقوم بتشغيل PostgreSQL أو MySQL أو MongoDB أو Redis على k3s - على خوادم معدنية أو AWS EC2 أو Azure VMs أو مثيلات GCP أو أجهزة مركز البيانات المحلية - توفر Longhorn أساس التخزين الذي يتيح لك التركيز على تطبيقاتك بدلاً من القلق بشأن متانة البيانات. قم بتثبيته وتكوينه ومراقبته والوثوق به مع بيانات الإنتاج الخاصة بك.