İçeriğe geç
Longhorn Kubernetes Dağıtık Depolama Kurulumu ve Yönetimi

Longhorn Kubernetes Dağıtık Depolama Kurulumu ve Yönetimi

6 dk okuma DevOps

Longhorn, Kubernetes kümesindeki düğümlerin yerel disklerini toplayıp üzerinde çoğaltmalı kalıcı birimler sunan blok depolama sistemi. Rancher ekibi tarafından geliştirildi, CNCF bünyesinde olgunlaştı. Ceph veya GlusterFS gibi ayrı bir depolama kümesi kurmaz; depolama ve hesaplama aynı düğümlerde yaşar, yönetim de Kubernetes nesneleri üzerinden akar. CSI sürücüsüyle çalıştığı için PersistentVolumeClaim yazan Deployment ya da StatefulSet tarafında Longhorna özgü hiçbir kod değişikliği gerekmez.

Ön koşullar

Her worker düğümünde open-iscsi kurulu ve iscsid servisi çalışıyor olmalı. Longhorn birimleri motor üzerinden iSCSI hedefi olarak açar, bu bileşen eksikse birimler attach aşamasında takılır. Debian ve Ubuntu tarafında:

apt-get install -y open-iscsi nfs-common
systemctl enable --now iscsid

RHEL ailesinde karşılıkları iscsi-initiator-utils ve nfs-utils. NFS istemcisi opsiyonel gibi görünse de yedek hedefi NFS olacağı anda lazım olur, baştan kurmak sıkıntı çıkarmaz. Sadece Linux düğümler desteklenir, x86_64 ve arm64 yaygın kullanılan mimariler. Resmi belgeler üç düğümlü bir taban için düğüm başına en az 4 vCPU ve 4GiB bellek öneriyor; küçük laboratuvar kümelerinde azıyla da döner ama bileşenler bir arada belirli bir taban kaynak tüketir.

Depoda scripts/environment_check.sh adında bir denetim betiği var. Kurulumdan önce çalıştırıp iscsi durumu, çekirdek modülleri ve benzeri ön koşulları görmek, kuruldan sonra sürünen podlarla uğraşmaktan ucuzdur.

Kurulum

İki yol var. Helm grafiği güncelleme takibi kolaylaştırdığı için çoğu ortamda tercih edilir:

helm repo add longhorn https://charts.longhorn.io
helm repo update
helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace

Manifest sevenler için grafikten üretilmiş tek dosya dağıtımı mevcut. Sürüm etiketini güncel release ile eşleştirin:

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

Kurulum bitince podların oturması izlenir: kubectl get pods -w -n longhorn-system. longhorn-manager her düğümde bir, motor ve replika süreçlerini barındıran instance-manager podları ile CSI sürücüsü ve arayüz podu sınıfın içinde ayağa kalkar. Hepsi Running olana kadar PVC oluşturmayın.

Perde arkası: motor ve replikalar

Bir birim oluştuğunda Longhorn o birim için bir motor ve ayarlanan sayıda replika planlar. Varsayılan replika sayısı üçe; her replika ayrı bir düğüme yerleşir. Veri, varsayılan olarak /var/lib/longhorn/ altındaki dizinlerde tutulur. Aynı dizini isterseniz arayüzden ayrık bir diske ya da bölümle değiştirebilirsiniz. Replikalar birbirine yazıları önceliklendirilmiş şekilde kopyalar; bir düğüm gittiğinde kalan iki replika hizmeti kesintisiz sürdürür ve zamanla eksik replika başka düğümlerde yeniden inşa edilir.

Podun çalıştığı düğüme birim bir iSCSI hedefi olarak bağlanır, CSI sürücüsü attach ve detach işlerini yönetir, üstüne ext4 ya da xfs ile dosya sistemi kurulur. Küme tarafında volumes, engines, replicas, nodes gibi özel kaynaklar oluşur; kubectl -n longhorn-system get volumes.longhorn.io ile birim sağlığını podlardan bağımsız izlemek mümkün.

ReadWriteMany erişimi de var. Longhorn bunun için birim başına küçük bir NFS sunucusu ayağa kaldırır. Web sunucusu yapılandırması, log arşivi gibi paylaşımlı okuma senaryolarına uyar; veritabanı gibi tek yazıcı isteyen işlerde ReadWriteOnce kalın.

StorageClass ile ayar sürmek

Kurulum longhorn adında varsayılan bir StorageClass getirir. Replika sayısını iş yükü bazında değiştirmek isterseniz ayrı bir sınıf tanımlanır:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-iki-replika
provisioner: driver.longhorn.io
parameters:
  numberOfReplicas: "2"
  staleReplicaTimeout: "30"

Test kümesinde iki replika yeter, üretimde üçe kalmak çoğu senaryoda doğru denge. PVC tarafı bilindik:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn-iki-replika
  resources:
    requests:
      storage: 20Gi

Arayüz

Grafik arayüz longhorn-frontend servisi arkasında gelir. Hızlı bakmak için port yönlendirme yeterli:

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

Tarayıcıdan localhost:8080 adresine gidildiğinde düğümler, diskler, birimler ve her birimin replikalarının hangi düğümde olduğu tek ekranda görünür. Disk ekleme, replika yeniden planlama, anlık görüntü alma ve zamanlanmış görevler de aynı yerden yönetilir.

Anlık görüntü ve yedekleme

Anlık görüntüler kopyala-üzerine-yaz mantığıyla saniyeler içinde alınır, birim boyutundan bağımsız hızlıdır. Yedekleme ise dış hedefe yazılır: S3 uyumlu bir nesne deposu ya da NFS paylaşımı. Yedekler artımlı gider, hedefteki önceki yedekle aradaki blok farkı taşınır. Olağan dışı bir durumda yedekten yeni bir kümede birim geri yüklenir; iki küme arasında coğrafi yedek stratejisi bu akışla kurulur. Hedef tanımı arayüzdeki ayarlar bölümünden veya Helm değerleriyle yapılır.

Düğüm çıkarırken, eklerken

Bir düğümü bakıma almak için kubectl drain çalıştırdığınızda Longhorn boşaltma kancalarıyla devreye girer ve podlarla birlikte replikaları da planlar. Düğüm kalıcı gidiyorsa arayüzden önce devre dışı bırakıp replikaların başka yerlerde tamamlanmasını beklemek, sonra silmek gerekir; sırayı bozmak veri kaybı riskini büyütür. Yeni disk eklemek de arayüzden birkaç tıklamayla olur, mevcut birimler büyüdükçe yeni diske otomatik yayılır. Verinin podla aynı düğümde tutulmasını sağlayan bir data locality ayarı da mevcut, g/ yoğun işlerde fark yaratır.

Sürüm uyumu

Bu yazıdaki etiket ve grafik detayları 1.7 kuşağını referans alır. Longhorn her sürümde desteklediği Kubernetes aralığını açıkça listeler; küme sürümünüzle uyum tablosunu kurulum öncesi resmi belgelerden doğrulayın. Yükseltmeler Helm ile helm upgrade longhorn longhorn/longhorn -n longhorn-system akışıyla yapılır, önce belgelerdeki ara sürüm basamaklarına bakılır.

Tek düğümlü kümelerde varsayılan üç replika karşılanamayacağı için birim eksik durumda kalır; orada replika sayısını bire düşürmek gerekir. Üç ve üzeri düğümlü bir kümede ise Longhorn kurulumu, size kalan işi biçimlendirmekten ibaret. Ayrıntılı senaryolar ve güncel parametre listesi için GitHub deposu da belgeler kadar faydalı.