Ceph | BURAK AKTAŞ https://www.burakaktas.com/katagori/ceph/ Virtualization Technologies Blog Sun, 03 May 2026 21:48:41 +0000 tr hourly 1 https://wordpress.org/?v=7.0 https://www.burakaktas.com/wp-content/uploads/2020/04/cropped-vm_favicon-32x32.png Ceph | BURAK AKTAŞ https://www.burakaktas.com/katagori/ceph/ 32 32 Ceph Ghost OSD Clear https://www.burakaktas.com/ceph-ghost-osd-clear/ Sun, 03 May 2026 21:43:40 +0000 https://www.burakaktas.com/?p=4313 Ghost OSD’nin teknik tanımı: Ceph OSDMap içinde OSD ID kayıtlıdır ama: Bu nedenle cluster OSD’yi hala map içinde tuttuğu için CRUSH map üzerinde hayalet gibi durur bunada Ghost OSD denir. Ghost OSD nasıl oluşur? Ceph OSD silme işlemi yanlış sırayla yapılınca. Doğru işlem sırası: Bu işlemler eksik yapılırsa → OSD Map içinde kalır → Ghost OSD olur. Ghost OSD nasıl […]

The post Ceph Ghost OSD Clear appeared first on BURAK AKTAŞ.

]]> Ghost OSD’nin teknik tanımı:

Ceph OSDMap içinde OSD ID kayıtlıdır ama:

  • OSD’nin fiziksel diski çıkarılmıştır.
  • OSD process’i (ceph-osd@ID) yoktur.
  • Node üzerinde /var/lib/ceph/osd/ceph-ID dizini bulunmaz.
  • Systemd service çalışmaz.
  • Ceph bu OSD’yi DOWN + OUT olarak görür.
  • “destroyed / purge edilmemiş” OSD’dir.

Bu nedenle cluster OSD’yi hala map içinde tuttuğu için CRUSH map üzerinde hayalet gibi durur bunada Ghost OSD denir.

Ghost OSD nasıl oluşur?

Ceph OSD silme işlemi yanlış sırayla yapılınca.

Doğru işlem sırası:

ceph osd out <id>
ceph osd crush remove osd.<id>
ceph auth del osd.<id>
ceph osd rm <id>

Bu işlemler eksik yapılırsa → OSD Map içinde kalır → Ghost OSD olur.

Ghost OSD nasıl anlaşılır?

ceph osd tree

Ghost OSD genellikle şöyle görünür:

ID  CLASS  WEIGHT  STATUS  REWEIGHT  PRI-AFF
45         0.0     down    0.00000   1.00
  • Weight = 0
  • Status = down
  • Disk yok
  • OSD directory yok

Ama ID hala listede → GHOST.

Ghost OSD neden sorun yaratır?

Her zaman kritik değildir ama şu sorunlara sebep olabilir:

  • CRUSH Map karmaşıklaşır
  • OSD ID’ler karışır
  • ceph-volume lvm create sırasında ID çakışması olabilir
  • Ansible / Proxmox auto-OSD scriptleri OSD ID seçerken hata verebilir
  • Dashboard “Health Warning” üretir

Ghost OSD nasıl temizlenir?

Ghost OSD ID’sini bul

ceph osd tree

Varsayalım ghost ID = 45

OSD’yi crush map’ten sil

ceph osd crush remove osd.45

Auth kaydını sil

ceph auth del osd.45

OSD ID’yi tamamen sil

ceph osd rm 45

Kontrol et

ceph osd tree
ceph -s

OSD artık görünmüyorsa → Ghost temizlendi.

Bir sonraki yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Ceph Ghost OSD Clear appeared first on BURAK AKTAŞ.

]]> Removing Empty Hosts from the Ceph CRUSH Tree https://www.burakaktas.com/removing-empty-hosts-from-the-ceph-crush-tree/ Sun, 03 May 2026 21:25:32 +0000 https://www.burakaktas.com/?p=4303 Kırmızı ile işaretlenen “boş host entry” satırları Ceph CRUSH map içinde OSD’siz tanımlı hostlardır. Bunlar genelde, Node daha önce cluster’a eklenip sonra kaldırıldığında, ceph orch veya pveceph ile yanlış isim otomatik eklendiğinde, CRUSH map manuel düzenlendiğinde oluşur. Çözüm: Bu hostları CRUSH map’ten silmek. Önce mevcut CRUSH tree’yi kontrol et: Kırmızı kutuda olanlar örneğin: Bunları kaldırmak için: Sonra tekrar kontrol et: […]

The post Removing Empty Hosts from the Ceph CRUSH Tree appeared first on BURAK AKTAŞ.

]]>

Kırmızı ile işaretlenen “boş host entry” satırları Ceph CRUSH map içinde OSD’siz tanımlı hostlardır.

Bunlar genelde, Node daha önce cluster’a eklenip sonra kaldırıldığında, ceph orch veya pveceph ile yanlış isim otomatik eklendiğinde, CRUSH map manuel düzenlendiğinde oluşur.

Çözüm: Bu hostları CRUSH map’ten silmek.

Önce mevcut CRUSH tree’yi kontrol et:

ceph osd tree

Kırmızı kutuda olanlar örneğin:

  • host r2-prx-test-03
  • host r2-prx-test-10

Bunları kaldırmak için:

ceph osd crush remove r2-prx-test-03
ceph osd crush remove r2-prx-test-10

Sonra tekrar kontrol et:

ceph osd tree

Eğer “node has items” hatası gelirse

Bu durumda Ceph host altında OSD olmadığını düşünüyor ama bir weight kayıtlı olabilir. Şu komut ile kontrol et:

ceph osd crush tree | grep r2-prx-test-03

Eğer ağırlık görünürse sıfırla:

ceph osd crush reweight-n r2-prx-test-03 0

Tekrar sil:

ceph osd crush remove r2-prx-test-03

Ek Temizlik (Gerekirse)

Bazı eski Ceph sürümlerinde host sadece CRUSH map’ten değil, CRUSH bucket içinden de silinmek zorunda:

ceph osd crush rm r2-prx-test-03

Sonuç:

Bu iki komut sorunu çözecek:

ceph osd crush remove r2-prx-test-03
ceph osd crush remove r2-prx-test-10

Bir sonraki yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Removing Empty Hosts from the Ceph CRUSH Tree appeared first on BURAK AKTAŞ.

]]> Proxmox + Ceph HCI Cluster Node Decommission v9.x https://www.burakaktas.com/proxmox-ceph-hci-cluster-node-decommission/ Sun, 03 May 2026 13:38:27 +0000 https://www.burakaktas.com/?p=4291 Bu runbook Proxmox VE + Ceph HCI cluster ortamında node shrink işlemini güvenli şekilde yapmak için hazırlanmıştır. Örnek Operasyon:10 node → 5 node shrink Operasyon Mantık Sırası1️⃣ Operasyon planı2️⃣ VM / HA cleanup3️⃣ Ceph OSD removal4️⃣ Proxmox node removal5️⃣ Ceph rebalance & PG planning6️⃣ CRUSH rule doğrulama Örnek Cluster Ortamı Proxmox Cluster: 10 nodeStorage: Ceph HCIReplica size: 3OSD per node: […]

The post Proxmox + Ceph HCI Cluster Node Decommission v9.x appeared first on BURAK AKTAŞ.

]]> Bu runbook Proxmox VE + Ceph HCI cluster ortamında node shrink işlemini güvenli şekilde yapmak için hazırlanmıştır.

Örnek Operasyon:
10 node → 5 node shrink

Operasyon Mantık Sırası
1️⃣ Operasyon planı
2️⃣ VM / HA cleanup
3️⃣ Ceph OSD removal
4️⃣ Proxmox node removal
5️⃣ Ceph rebalance & PG planning
6️⃣ CRUSH rule doğrulama

Örnek Cluster Ortamı

Proxmox Cluster: 10 node
Storage: Ceph HCI
Replica size: 3
OSD per node: 12 NVMe
Toplam: 120 OSD

Shrink hedefi: 10 → 5 node

1-Operasyon Öncesi Kontroller

Proxmox Cluster Health

pvecm status

Beklenen çıktı:
Quorate: Yes
Nodes: 10

Node Listesi

pvecm nodes

Ceph Cluster Health

ceph -s

Beklenen:
HEALTH_OK

Eğer cluster HEALTH_WARN / DEGRADED ise node removal yapılmamalıdır.

2-Node Üzerindeki VM ve Container’ları Taşı

Node tamamen boş olmalıdır.

Kontrol:
qm list
pct list

VM Migration
qm migrate VMID TARGETNODE --online

Container Migration
pct migrate CTID TARGETNODE

GUI
VM → Migrate

3-HA Kaynaklarını Temizle

HA kontrolü:
ha-manager status

HA resource taşıma:
ha-manager migrate vm:101 node02

4-Node Üzerindeki Ceph OSD’leri Tespit Et

ceph osd tree

Örnek:

host r1-prx-test-06
         osd.61
         osd.62
         osd.63
         osd.64
         osd.65

5-OSD’leri OUT Yap

ceph osd out 61
ceph osd out 62
ceph osd out 63
ceph osd out 64
ceph osd out 65

Kontrol:

ceph -s

Cluster aşağıdaki aktiviteleri başlatır:

recovery
backfill
rebalancing
⚠️ Bu işlemler bitmeden devam edilmez

6-OSD’leri STOP Et

systemctl stop ceph-osd@61
systemctl stop ceph-osd@62
systemctl stop ceph-osd@63
systemctl stop ceph-osd@64
systemctl stop ceph-osd@65

Kontrol:

systemctl status ceph-osd@61
systemctl status ceph-osd@62
systemctl status ceph-osd@63
systemctl status ceph-osd@64
systemctl status ceph-osd@65
👉 inactive olmalı

7-OSD’leri Cluster’dan Tamamen Sil

ceph osd purge 61 --yes-i-really-mean-it
ceph osd purge 62 --yes-i-really-mean-it
ceph osd purge 63 --yes-i-really-mean-it
ceph osd purge 64 --yes-i-really-mean-it
ceph osd purge 65 --yes-i-really-mean-it

Bu işlem temizler:
  • OSD map
  • CRUSH map
  • auth keys
  • metadata

8-Ceph MON Kontrol

ceph mon dump
Eğer node üzerinde MON varsa:

ceph mon remove r1-prx-test-06
MON sayısı tek sayı olmalıdır

3 / 5 / 7

9-Ceph MGR Kontrol

ceph mgr dump
Node üzerindeki mgr varsa kaldırılabilir.

10-CRUSH Host Entry Temizliği

ceph osd crush remove r1-prx-test-01

11-Disklerin Wipe ve Destroy Edilmesi

ceph-volume lvm zap /dev/nvme0n1  --destroy
ceph-volume lvm zap /dev/nvme1n1  --destroy
ceph-volume lvm zap /dev/nvme2n1  --destroy
ceph-volume lvm zap /dev/nvme3n1  --destroy
ceph-volume lvm zap /dev/nvme4n1  --destroy
ceph-volume lvm zap /dev/nvme5n1  --destroy
ceph-volume lvm zap /dev/nvme6n1  --destroy
ceph-volume lvm zap /dev/nvme7n1  --destroy
ceph-volume lvm zap /dev/nvme9n1  --destroy
ceph-volume lvm zap /dev/nvme10n1 --destroy
ceph-volume lvm zap /dev/nvme11n1 --destroy
ceph-volume lvm zap /dev/nvme12n1 --destroy

12-Node’u Power Off Et

shutdown -h now
⚠️ Node cluster networkünde tekrar açılmamalıdır.

13-Proxmox Cluster’dan Node Çıkarma

Başka bir node üzerinden çalıştırılır.
pvecm delnode r1-prx-test-06

Kontrol:
pvecm nodes

Node listeden silinmiş olmalıdır.

14-Eğer Quorum Hatası Oluşursa

pvecm expected 1

Sonra tekrar:
pvecm delnode r1-prx-test-06

15-Node Directory Temizliği

Bazı durumlarda şu klasör kalabilir:
/etc/pve/nodes/r1-prx-test-06

Temizleme:
rm -rf /etc/pve/nodes/r1-prx-test-06

16-Ceph Cluster Health Kontrol

ceph -s

Beklenen:
HEALTH_OK

17-Ceph HCI Node Shrink Planning

Örnek pool:
pool: r1_c01_artuklu
size: 3
PG: 4096
autoscaler: off

18-Ceph PG Dağılım Mantığı

Ceph veri dağılımı:

Object
 ↓
PG
 ↓
OSD

Replica:
size=3

19-PG Hesaplama Formülü

PG = (OSD × 100) / replica

20-Mevcut Cluster

10 node
12 OSD per node

Toplam: 120 OSD

PG hesap: (120 × 100) / 3 = 4000

Mevcut: 4096 PG

Bu ideal.

21-Shrik Sonrası

5 node
12 OSD

Toplam: 60 OSD

22-Yeni PG Hesabı

(60 × 100) / 3 = 2000

İdeal: 2048 PG

Ama mevcut: 4096 PG

23-PG Fazla Olursa

Etki                     Sebep
OSD RAM Artar            PG state
CPU Artar                Metadata
Peering Süresi Artar     Recovery

Production Cluster'larda Genelde Kritik Problem Yaratmaz.

24—Node Removal Data Movement

Node Removal Sırasında:

OSD OUT
 ↓
PG remap
 ↓
backfill
 ↓
recovery

25—Veri Hareketi Hesabı

Shrink: 10 → 5 node

Cluster kapasitesinin yaklaşık: %50

Yani Ceph yaklaşık: cluster data × 50% veri taşır.

26—Shrink Strategy

⚠️ 10 → 5 shrink tek seferde yapılmaz
Önerilen sıra:

10 → 9
recovery finish

9 → 8
recovery finish

8 → 7
recovery finish

7 → 6
recovery finish

6 → 5
Her adımda kontrol:

ceph -s

27-OSD Utilization Kontrol (Opsiyonel)

ceph osd df

Düzeltme: ceph osd reweight-by-utilization

28—CRUSH Failure Domain Kontrolü

Replica dağılımı şu şekilde olmalıdır:

replica1 → r1-prx-test-10
replica2 → r1-prx-test-09
replica3 → r1-prx-test-08
replica3 → r1-prx-test-07
replica3 → r1-prx-test-06

Kontrol:

ceph osd crush rule dump

Beklenen:
step chooseleaf firstn 0 type host

Bu sayede replica’lar farklı node’lara dağıtılır.

29—Final Health Check

ceph -s
ceph osd tree
ceph osd df

pvecm status

Beklenen:

HEALTH_OK

cluster stable
node removed

Final Operasyon Sırası

VM migrate
↓
HA cleanup
↓
OSD out
↓
OSD purge
↓
MON remove
↓
Node shutdown
↓
pvecm delnode
↓
Ceph rebalance

Bir sonraki yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Proxmox + Ceph HCI Cluster Node Decommission v9.x appeared first on BURAK AKTAŞ.

]]> Proxmox Ceph Storage Cluster Safe Shutdown and Startup v9.x https://www.burakaktas.com/proxmox-cluster-ceph-storage-safe-shutdown-and-startup-v9-x/ Sat, 02 May 2026 22:16:48 +0000 https://www.burakaktas.com/?p=4280 Merhaba, bu yazımızda Ceph storage kullanılan bir Proxmox cluster ortamının güvenli şekilde kapatılması ve tekrar açılması için izlenmesi gereken yolu anlatıyor olacağım. (10 node’lu bir cluster üzerinde bu demo yapıldıktan sonra bu yazı yazılmıştır.) 1️⃣ Ceph Cluster Health Kontrolü Shutdown işlemine başlamadan önce Ceph cluster sağlıklı olmalıdır. Ek Kontrol Komutları: 2️⃣ Ceph Maintenance Flag Ayarlama Node’lar kapandığında Ceph’in gereksiz veri […]

The post Proxmox Ceph Storage Cluster Safe Shutdown and Startup v9.x appeared first on BURAK AKTAŞ.

]]> Merhaba, bu yazımızda Ceph storage kullanılan bir Proxmox cluster ortamının güvenli şekilde kapatılması ve tekrar açılması için izlenmesi gereken yolu anlatıyor olacağım.

(10 node’lu bir cluster üzerinde bu demo yapıldıktan sonra bu yazı yazılmıştır.)

1️⃣ Ceph Cluster Health Kontrolü

Shutdown işlemine başlamadan önce Ceph cluster sağlıklı olmalıdır.

Komut: ceph -s

Beklenen çıktı: HEALTH_OK

Ek Kontrol Komutları:

ceph osd tree
ceph pg stat

Şunlar olmamalıdır:
  • degraded PG
  • recovery
  • backfill

2️⃣ Ceph Maintenance Flag Ayarlama

Node’lar kapandığında Ceph’in gereksiz veri rebalance yapmasını önlemek için aşağıdaki flag’ler set edilir.

Önce mevcut flag’leri kontrol edin:

ceph osd dump | grep flags

Ardından maintenance flag’leri set edilir:

ceph osd set noout
ceph osd set norebalance
ceph osd set nobackfill
Kontrol: ceph osd dump | grep flags

Bu flag’ler sayesinde:

• OSD offline olduğunda Ceph hemen rebalancing başlatmaz
• Gereksiz disk IO oluşmaz
• Cluster performansı korunur

3️⃣ VM ve Container’ları Kapatma

Shutdown işleminden önce tüm VM ve Container’lar kapatılmalıdır.

VM listeleme: qm list
VM kapatma: qm shutdown VMID
Zorunlu durumda: qm stop VMID

Container kapatma: pct shutdown CTID
Büyük clusterlarda toplu shutdown için: qm list | awk 'NR>1 {print $1}' | xargs -I {} qm shutdown {}

4️⃣ HA Servisini Devre Dışı Bırakma

Cluster HA kullanıyorsa shutdown sırasında HA migration oluşmasını engellemek için HA servisleri durdurulmalıdır.

HA durumunu kontrol et: ha-manager status

Tüm node'lar da aşağıdaki servisler durdurulur.

LRM servis: systemctl stop pve-ha-lrm

CRM servis: systemctl stop pve-ha-crm

Bu işlem HA stack'i tamamen dondurur.

5️⃣ Proxmox Node’ları Kapatma (HCI Cluster)

VM ve HA servisleri kapatıldıktan sonra node’lar güvenli şekilde kapatılabilir.

Her node üzerinde: sync; shutdown -h now veya poweroff

Önerilen Shutdown Sırası (HCI)

HCI mimaride compute ve storage aynı node üzerinde bulunduğundan shutdown sırası Ceph MON quorum’u koruyacak şekilde planlanmalıdır.

1️⃣ MON içermeyen node’lar

node06
node07
node08
node09
node10

2️⃣ MON içeren node’lar

node01
node02
node03
node04
node05

3️⃣ En son aktif MON node

MON quorum kaybolmaması için en son node kapatılır.

Örnek Shutdown Sırası:

node10
node09
node08
node07
node06
node05
node04
node03
node02
node01 (en son)

Bu yöntem sayesinde:
• Ceph quorum korunur
• cluster crash olmaz
• unnecessary recovery oluşmaz

6️⃣ Cluster’ı Tekrar Açma (HCI)

Cluster açılırken shutdown sırasının tam tersi uygulanmalıdır.

Power On Sırası

1️⃣ Önce Ceph MON node’lar

node01
node02
node03
node04
node05

Bu node’lar Ceph quorum’u oluşturur.
Node’lar açıldıktan sonra 1-2 dakika beklenmesi önerilir. Bu süre Ceph MON election ve quorum oluşumu için gereklidir.

2️⃣ Sonra diğer HCI node’lar

node06
node07
node08
node09
node10

7️⃣ Cluster Quorum Kontrolü

Cluster node’ları açıldıktan sonra quorum kontrol edilir.

pvecm status

Beklenen çıktı: Quorate: Yes

8️⃣ Ceph Cluster Health Kontrolü

Cluster açıldıktan sonra Ceph health kontrol edilir.

ceph -s

Beklenen çıktı: HEALTH_OK

Ek kontrol: ceph osd stat

Beklenen: X osds: X up, X in

Bu aşamada noout flag'i hala aktif olacaktır.

9️⃣ Ceph Flag’leri Kaldırma

Shutdown sırasında set edilen flag’ler kaldırılmalıdır.

ceph osd unset noout
ceph osd unset norebalance
ceph osd unset nobackfill

Kontrol: ceph osd dump | grep flags

🔟 HA Servislerini Yeniden Başlatma

HA servisleri tekrar aktif edilir.

Önce CRM başlatılır: systemctl start pve-ha-crm
Sonra LRM başlatılır: systemctl start pve-ha-lrm
Kontrol: ha-manager status

1️⃣1️⃣ VM’leri Başlatma

Cluster tamamen sağlıklı ise VM’ler tekrar başlatılır.

qm start VMID veya GUI üzerinden.

Final Kontroller

Proxmox cluster kontrolü: pvecm status
Ceph cluster kontrolü: ceph -s
OSD kontrolü: ceph osd tree

Tüm OSD'ler: up + in olmalıdır.
HCI Cluster İçin Kritik Not
Ceph MON quorum kuralı: quorum = (MON sayısı / 2) + 1

Örnek:

3 MON → quorum 2
5 MON → quorum 3

Shutdown sırasında:
• Aynı anda birden fazla MON kapatılmamalıdır.

Kritik Notlar
• Shutdown öncesi Ceph HEALTH_OK olmalıdır.
• HA servisleri mutlaka durdurulmalıdır.
• Cluster açılırken MON node'lar önce açılmalıdır.
• Ceph flag'leri startup sonrası kaldırılmalıdır.

Bir sonraki yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Proxmox Ceph Storage Cluster Safe Shutdown and Startup v9.x appeared first on BURAK AKTAŞ.

]]> Proxmox Ceph Storage Cluster Failed Disk Replacement https://www.burakaktas.com/ceph-cluster-failed-disk-replacement/ Fri, 01 May 2026 11:43:08 +0000 https://www.burakaktas.com/?p=4255 Bu yazımız da sizlere Proxmox VE üzerinde çalışan Ceph Storage cluster’da arızalanan bir diskin güvenli şekilde değiştirilmesi için uygulanacak prosedürü aktarıyor olacağım. Tipik senaryo: • Disk failure• OSD DOWN• Disk replacement• OSD redeploy• Ceph rebalance 1️⃣ Öncelikle cluster durumu kontrol edilir. 2️⃣ Arızalı OSD Tespiti 3️⃣ Maintenance Flag (noout) Disk değişimi sırasında Ceph’in gereksiz rebalance başlatmaması için noout flag set edilir. 4️⃣ OSD […]

The post Proxmox Ceph Storage Cluster Failed Disk Replacement appeared first on BURAK AKTAŞ.

]]> Bu yazımız da sizlere Proxmox VE üzerinde çalışan Ceph Storage cluster’da arızalanan bir diskin güvenli şekilde değiştirilmesi için uygulanacak prosedürü aktarıyor olacağım.

Tipik senaryo:

• Disk failure
• OSD DOWN
• Disk replacement
• OSD redeploy
• Ceph rebalance

1️⃣ Öncelikle cluster durumu kontrol edilir.

CLI: ceph -s
Beklenen durum: HEALTH_WARN
Genellikle aşağıdaki hata görülür: OSD_DOWN

2️⃣ Arızalı OSD Tespiti

CLI: ceph osd tree & ceph osd tree | grep down
Örnek: osd.17 down
GUI

Datacenter
 → Node
   → Ceph
     → OSD

DOWN olan OSD kırmızı görünür.

3️⃣ Maintenance Flag (noout)

Disk değişimi sırasında Ceph’in gereksiz rebalance başlatmaması için noout flag set edilir.

CLI: ceph osd set noout

Kontrol: ceph osd dump | grep flags

4️⃣ OSD OUT Yapılması

Arızalı OSD cluster’dan çıkarılır.

CLI: ceph osd out osd.17
GUI

Node
 → Ceph
   → OSD
     → osd.X
       → OUT

Ceph bu noktada veriyi diğer OSD’lere taşımaya başlar.

5️⃣ Recovery Sürecini İzleme

CLI: watch ceph -s

Durumlar:

active+recovering
active+backfilling

Recovery tamamlandığında:

active+clean

6️⃣ OSD Destroy

Recovery tamamlandıktan sonra OSD cluster’dan kaldırılır.

CLI: ceph osd destroy 17 --yes-i-really-mean-it
GUI

Node
 → Ceph
   → OSD
     → osd.X
       → Destroy

Bu işlem arka planda:

# ceph osd crush remove
# ceph auth del
# ceph osd rm

komutlarını çalıştırır.

7️⃣ Crash Alarm Temizleme (Opsiyonel)

CLI:

ceph crash ls
ceph crash archive-all

8️⃣ Fiziksel Disk Değişimi

Datacenter’da arızalı disk yeni disk ile değiştirilir.
Node üzerinde yeni disk görünmelidir.

CLI: lsblk

9️⃣ Disk Temizleme (Zap)

Yeni disk üzerinde eski metadata varsa temizlenir.

CLI: ceph-volume lvm zap /dev/sdX --destroy

🔟 Yeni OSD Oluşturma

CLI: ceph-volume lvm create --data /dev/sdX
GUI

Node
 → Ceph
   → OSD
     → Create OSD

Disk seçilir ve OSD oluşturulur.

1️⃣1️⃣ Rebalance ve Recovery

Yeni OSD eklendikten sonra Ceph otomatik olarak:

backfill - recovery - rebalance - başlatır.

CLI: ceph -s

1️⃣2️⃣ Maintenance Flag Kaldırma

Operasyon tamamlandıktan sonra noout flag kaldırılır.

CLI: ceph osd unset noout

1️⃣3️⃣ Operasyon Tamamlanması

Cluster aşağıdaki duruma geldiğinde işlem tamamlanmıştır.

HEALTH_OK ve all PGs active+clean

Operasyon Komut Özeti

ceph -s
ceph osd tree
ceph osd set noout
ceph osd out osd.X
watch ceph -s
ceph osd destroy X --yes-i-really-mean-it
ceph crash archive-all
lsblk
ceph-volume lvm zap /dev/sdX --destroy
ceph-volume lvm create --data /dev/sdX
ceph osd unset noout
ceph -s

Bir sonraki yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Proxmox Ceph Storage Cluster Failed Disk Replacement appeared first on BURAK AKTAŞ.

]]> Ceph Manager Dashboard Kurulumu https://www.burakaktas.com/ceph-manager-dashboard-kurulumu/ Sun, 23 Jun 2024 20:16:00 +0000 https://www.burakaktas.com/?p=3960 Merhaba, bu yazımda sizlere Ceph Manager dashboard kurulumunu anlatacağım. Kurmuş olduğumuz Proxmox VE Ceph Storage yapımızda ceph mgr install işlemlerimizi yapmış olup her node üzerine birer manager kurmuştuk. Fakat Ceph’ in bize tanımış olduğu bir Ceph Manager Dashboard‘u var bunuda ortamımıza entegre edersek Ceph yönetimimizi daha kolay bir hale getirmiş olacağız. Öncelikle tüm node’lar üzerinde aşağıdaki komutu çalıştırarak Ceph Manager Dashboard’u […]

The post Ceph Manager Dashboard Kurulumu appeared first on BURAK AKTAŞ.

]]> Merhaba, bu yazımda sizlere Ceph Manager dashboard kurulumunu anlatacağım.

Kurmuş olduğumuz Proxmox VE Ceph Storage yapımızda ceph mgr install işlemlerimizi yapmış olup her node üzerine birer manager kurmuştuk. Fakat Ceph’ in bize tanımış olduğu bir Ceph Manager Dashboard‘u var bunuda ortamımıza entegre edersek Ceph yönetimimizi daha kolay bir hale getirmiş olacağız.

Öncelikle tüm node’lar üzerinde aşağıdaki komutu çalıştırarak Ceph Manager Dashboard’u kuruyoruz.

#apt-get install ceph-mgr-dashboard

Buradan sonraki adımlarda sadece 1 node üzerinde ilgili komutları çalıştırmamız yeterli olacaktır.

Sonrasında ceph mgr modülü enable ediyoruz ve dashboard’ un kullanacağı sertifikayı oluşturuyoruz.

#ceph mgr module enable dashboard

#ceph dashboard create-self-signed-cert

Son olarak aşağıdaki komut ile Ceph Manager Dashboard‘ un kullanıcısını oluşturuyoruz fakat öncesinde ise bir .txt oluşturup içine “admin” kullanıcısına vereceğimiz şifreyi yazıyoruz.

#echo Password1! > passwd.txt

#ceph dashboard ac-user-create admin -i “passwd.txt” administrator

Artık Ceph Manager Dashboard‘a erişim sağlayabiliriz burada ceph mgr‘ler active – standby şeklinde çalışmaktadır. Cluster içindeki hangi ip ile giderseniz gidin active olan node üzerinden erişim sağlayabilirsiniz.

https://ip_address:8443

Bir sonraki Proxmox yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Ceph Manager Dashboard Kurulumu appeared first on BURAK AKTAŞ.

]]> Proxmox VE Ceph Storage Kurulumu https://www.burakaktas.com/proxmox-ve-ceph-storage-kurulumu/ Sun, 23 Jun 2024 20:02:48 +0000 https://www.burakaktas.com/?p=3909 Merhaba, bu yazımda sizlere Proxmox VE üzerinde Ceph Storage kurulumunu anlatıyor olacağım. Öncelikle Proxmox VE üzerine Ceph kurulumumuzu ve ayarlarımızı yapmadan önce Ceph’in yapısından ve mimarisinden başlayalım.Ceph kurulumlarında sıkca duyacağımız PG (Placement Group), OSD (Object Storage Daemon), RBD (Rados Block Device), Ceph MON ve Ceph MGR terimlerini inceleyelim. Ceph Mimarisi Ceph nesne tabanlı ve blok depolama ile dosya sistemi türündeki […]

The post Proxmox VE Ceph Storage Kurulumu appeared first on BURAK AKTAŞ.

]]> Merhaba, bu yazımda sizlere Proxmox VE üzerinde Ceph Storage kurulumunu anlatıyor olacağım.

Öncelikle Proxmox VE üzerine Ceph kurulumumuzu ve ayarlarımızı yapmadan önce Ceph’in yapısından ve mimarisinden başlayalım.
Ceph kurulumlarında sıkca duyacağımız PG (Placement Group), OSD (Object Storage Daemon), RBD (Rados Block Device), Ceph MON ve Ceph MGR terimlerini inceleyelim.

Ceph Mimarisi

Ceph nesne tabanlı ve blok depolama ile dosya sistemi türündeki depolama ortamlarının tamamını bir arada sunan ve bu amaçla 5 temel bileşenden oluşan açık kaynak kodlu bir depolama çözümüdür. Bu 5 bileşen aşağıda açıklanmıştır:

  • Ceph OSD (Object Storage Daemon): OSD bileşenleri veriyi nesne halinde tutmakla yükümlüdür. Verinin kopyalar halinde (replikasyon) tutulmasını yönetir. Disk ekleme/çıkarma işlemleri sonrasında verinin depolama ortamı üzerinde yeniden yapılandırılarak gerekli kopyaların oluşturulmasını ve diskler üzerinde dengeli olarak dağıtılmasını sağlar. Ayrıca monitör sunucularına disklerin durumu ile ilgili bilgi sağlar. Önerilen yapıda her disk için ayrı bir OSD kullanılması önemli konulardan birisidir.
  • Ceph MON (Monitor): Monitör bileşenleri tüm depolama ortamının sağlıklı çalışmasını takip amacıyla haritasını tutar. MAP ismi verilen bu haritalar arasında OSD Map, Monitor Map, PG Map ve CRUSH Map bulunur. Monitör bileşenleri diğer tüm bileşenlerden durum bilgilerini alarak haritayı çıkarır ve bunu diğer monitör ve OSD bileşenleri ile paylaşır. Ceph istemcileri bir okuma veya yazma yapacağı zaman yazacağı OSD ve PG’leri belirledikten sonra bu OSD’lerin çalışır durumda olup olmadığına bakar. İlk belirlenen erişilebilir durumda değilse duruma göre 2. veya 3. OSD kullanılır. Burada belirlenen OSD sayısı replikasyon sayısına bağlıdır.
  • Ceph RGW (Rados Gateway): RGW, Ceph’in doğrudan nesne tabanlı depolama ortamına erişmeye olanak veren API servisini sağlayan bileşendir. Bu API Amazon S3 ve OpenStack Swift API ile uyumludur.
  • Ceph RBD (Rados Block Device): RBD, Ceph’in nesne tabanlı depolama altyapısı üzerinde çalışan ve sanal sunucular, fiziksel sunucular ve diğer istemcilere blok tabanlı depolama sağlayan katmanıdır. OpenStack ve CloudStack desteği bulunur. Ticari çözümlerin sunduğu snapshot, thin-provisioning ve compression gibi özellikleri destekler.
  • Ceph FS (File System): Ceph’in nesne tabanlı depolama altyapısını kullanarak istemcilere POSIX uyumlu dosya sistemi vermesini sağlayan katmanıdır. Linux kernel üzerinde CephFS mount etmek üzere hali hazırda destek bulunduğu gibi alternatif olarak FUSE kullanılarak da mount işlemi yapılabilir. Diğer bileşenlerin aksine CephFS çalışmak için bir metadata sunucusuna ihtiyaç duyar.

Aşağıdaki resimde bu bileşenler gösterilmekte olup monitör sunucuları ve OSD sunucuları ile eğer ihtiyaç duyuluyorsa RGW sunucuları ve metadata sunucuları eklenerek aşağıdaki servisler sağlanabilir.

OSD katmanını biraz daha anlaşılabilir hale getirmek için aşağıdaki resimdeki yapıya dikkat çekilebilir. Depolamanın yapıldığı OSD sunucuları üzerinde işletim sisteminin çalıştığı bir disk ya da disk grubu bulunur. Bu resmin en solunda bulunan ilk sutünda görülmektedir. Alt katmandaki disk ext3, ext4, xfs gibi bir dosya sistemi ile formatlanarak üzerine işletim sistemi kurulur. Bu tüm sunuculardaki klasik kullanım şeklidir. Yanındaki sütunda sarı renk ile gösterilen journal ise OSD servislerinde çalışan mekanik disklere (SAS, SATA veya NL-SAS gibi) önbellek (cache) olarak bağlanmak üzere tasarlanan ve SSD üzerinde çalışan bir yapıdır. SSD disklerin yüksek yazma hızı ve IOPS performansından faydalanılarak yapılan yazma isteklerini karşılayarak sıralı (sequential) hale getirir. Bu disk üzerinde belirlenen süre boyunca önbelleklenen veri sıralı halde daha hızlı bir şekilde diske yazılır, böylece okunurken de sıralı biçimde daha hızlı okunur. OSD servislerine bağlı mekanik diskler ise resmin sağında yer alan ve kesikli çizgi ile çevrelenen alanda gösterilmektedir. Burada da diskler ext4, xfs veya btrfs gibi dosya sistemi ile formatlanarak OSD servislerine bağlanır. OSD servisi veriyi sunucu üzerine OSD servisleri ile mount edilen bu disklere nesneler halinde yazar.

Ceph Üzerinde Veri Yerleşimi

Ceph üzerindeki veri yerleşimini anlamak için önce Ceph tarafından kullanılan bazı temel yapı taşlarını anlamak gerekmektedir. Bunlardan bu aşamada gerekli olanlar aşağıda özetlenmiştir:

Veri Havuzu (Pool): Verileri birbirinden mantıksal olarak ayırmak üzere tasarlanmış, içerisinde imajları barındıran üst seviye bileşenlerdir. Her veri havuzu oluşturulurken veri miktarı ile doğru orantılı olarak belirlenen yerleşim grubu sayısı ile birlikte oluşturulur.

İmajlar (Images): Veri havuzlarının içerisinde yer alan ve blok depolama kullanmak üzere kullanılan bileşenlerdir.

Yerleşim Grubu (Placement Group-PG): Verileri gruplamak üzere OSD ve veri havuzları arasında kullanılan yapı taşlarıdır. OSD başına PG ortalamasının 100-150 civarı olması önerilmektedir. OSD başına PG sayısının 300’ü geçmesi sakıncalı bulunmaktadır.

Kural Grubu (Ruleset): Ceph’in kullandığı CRUSH algoritmasına ait haritanın (CRUSH Map) veriyi özel tanımlar ile hiyerarşik yapıda dağıtmasına izin vermek için kullandığı kurallardır. Varsayılan olarak hiyerarşik yapıda Region/DC/Room/Pod/PDU/Row/Rack/Chassis/Host/OSD olarak tanımlanan sırada örneğin farklı disk tiplerinden farklı veri havuzları oluşturarak (SSD’ler için ayrı, SAS’lar için ayrı, SATA’lar için ayrı) bu kurallar vasıtasıyla ilgili veri havuzlarının ilgili disk gruplarını kullanması sağlanır.

Buna göre herhangi bir istemci bir veri yazma talebinde bulunduğu zaman aşağıdaki resimdeki sıra ile yazılacak alan belirlenir ve replika sayısına göre kopya çıkarılır.

  • Öncelikle istemci tarafından yazılacak veri belirlenir ve Ceph üzerinde bulunan bir veri havuzuna yazma talebi yapılır.
  • CRUSH algoritması çalıştırılarak istemcinin yazması gereken PG ataması yapılır. Bu esnada herhangi bir metadata sunucusuna veya başka bir lookup tablosuna bakılmaz.
  • CRUSH algoritması ayrıca kullanılacak PG’yi bir OSD ile eşler. Böylece istemci veriyi birincil olarak belirlenen PG dolayısıyla OSD üzerine yazar.
  • CRUSH tarafından belirlenen birincil OSD’ye yazma işlemi tamamlanınca, verinin kopyası replika sayısına bağlı olarak diğer OSD’lere yazılır. Örneğin replika sayısı 3 ise birincil OSD’ye yazılan veri 2 ayrı OSD’ye daha kopyalanır. Bu OSD’ler varsayılan CRUSH map ayarlarında farklı sunucular üzerinde olacak şekilde ayarlanmıştır. Tüm kopyalar yazıldıktan sonra istemciye yazma işleminin başarılı olduğu bilgisi verilir.

CRUSH Algoritması

CRUSH (Controlled Replication Under Scalable Hashing), Ceph üzerinde verinin nereye yazılıp nereden okunacağını bir hesaplama yaparak belirleyen ve hem istemci hem de sunucularda bulunan, bu sayede veri lokasyonu için ikinci bir işlem gerektirmeyen bir algoritmadır. Daha önce bahsedildiği gibi Ceph bu yaklaşım sayesinde yüksek ölçeklere rahatlıkla çıkabilmektedir.

CRUSH map rolü ve sorumlulukları aşağıdaki gibidir:

  • Her hiyerarşik yapı için tanımlanan kurallarla birlikte Ceph’in veriyi nasıl saklayacağını belirler.
  • Çok aşamalı olabileceği gibi en az bir düğüm ve yaprak hiyerarşisine sahip olmalıdır.
  • Hiyerarşideki her düğüm sepet (bucket) olarak adlandırılır ve her sepetin bir tipi vardır.
  • Verileri tutan nesneler disklere verilebilecek ağırlıklara disklere dağıtılır.
  • İhtiyaca göre istenilen esneklikte hiyerarşik yapı tanımlanabilir. Tek kısıt en alttaki yaprak ismi verilen düğümler OSD’leri temsil etmelidir. Ayrıca her yaprak düğüm bir sunucuya ya da başka bir tipteki sepete bağlı olmalıdır.

OSD ve PG Nedir ?

OSD Nedir ?

  • Ceph Cluster’da her bir disk için bir ceph process’i koşmakta ve disk ile ilgili işlemleri yürütmektedir.
  • Bu process’e Object Storage Daemon yani OSD denilmektedir.
  • Genelde OSD ile bu process veya Ceph Cluster’ındaki her bir disk kast edilmektedir.

PG Nedir ?

  • Placement Group’lar (PGs) Ceph client’ları tarafından görünmez fakat Ceph Cluster’larda önemli bir rol oynarlar.
  • Bir Ceph Cluster’ı exabyte seviyesinde kapasiteye ulaştırmak için binlerce OSD eklemek gerekebilir.
  • Ceph Client’lar objeleri pool lara kayıt ederler. Pool’lar tüm cluster’ın mantıksal alt kümeleri olarak düşünülebilir.
  • Bir pool’daki toplam obje sayısı kolayca milyon ve üzeri sayılara çıkabilir.
  • Milyonlarca veya daha fazla sayıda obje içeren bir sistemde hangi objenin nerede olduğunu obje bazlı takip etmek performans konusunda sıkıntılar çıkarır.
  • Bu nedenle Ceph objeleri “Placement Group” lara ve Placement Group’ları da OSD’lere atar. Böylece hem verimlilik sağlar hem de dinamik bir şekilde objeleri yeniden dağıtabilir. (re-balancing)
  • PG ve OSD ilişkisi aşağıdaki diagramlardan daha net anlaşılabilir.

Ceph’de Placement Group’lar (PGs) hakkında detaylı bilgi için RedHat Ceph Dokümanında ilgili bölümü okuyabilirsiniz.

Dikkat !!!

  • Ceph’de PG Sayısı artırma en önemli işlemlerden birisidir !
  • Ceph’de PG artırma işlemi yavaş ve önerilen yöntemlerle yapılmazsa çok önemli performans sorunlarına yol açabilir.
  • PGP_NUM artırma işlemi sonrası veri PG’ler arası taşınmaya başlar ve bu işlem durdurulamaz, geriye alınamaz ve bu işlemin bitmesi beklenmelidir.
  • PG artırma işlemi cluster’ın az yoğun kullanıldığı saatlerde yapılmalıdır.
  • İşlem sırasında kullanıcılar yaşanabilecek potansiyel performans etkileri konusunda bilgilendirilmelidir!
  • İşlem yapılmadan önce daha yeni dokümanlar da incelenmelidir.

PG Sayısının Önemi

Ceph Cluster’ da Placement Group (PG) sayısı performans ve veri dağıtımı için çok kritik öneme sahiptir. Optimum değerleri bulmak için PG Hesap Makinesi kullanılmalıdır.

RedHat Ceph PG Calc

PG Hesap Makinesinde detaylı olarak da görülebileceği üzere Ceph’ de OSD başına 100 ile 300 arası PG tavsiye edilmektedir.

Ceph’de yeni bir pool oluştururken pool başına düşen PG (Placement Group) sayısını belirtebiliyoruz.

PG Sayısı ne zaman artırılmalı ? Performans ve veri sağlamlığını sağlamak için PG sayısını artırmamız gereken durumlar:

  • Zaman içerisinde cluster’ımıza yeni OSD’ler eklediysek, OSD başına düşen PG miktarı 100 ve altına düştüyse
  • PG sayısı ilk cluster kurulumunda yanlış belirlendiyse

PG artırma işlemi çok önemli olduğu için yükseltme yapmadan önce dikkatli planlama yapılmalı ve yakın öngürülebilir gelecekteki muhtemel cluster büyümeleri de hesaba katılmalıdır.

Eklenen her bir PG için OSD Node’ları ve Monitor Node’larının kaynak tüketimi (Memory, CPU, Network) artıyor, özellikle recovery işlemi sırasında bu kaynak tüketiminin daha da artacağı belirtiliyor.

PG sayısını minimum’da tutmak:

Kaynak tüketimini düşürüyor.
Verilerin dengesiz dağıtılmasına neden oluyor !

Ceph MGR Nedir ?

Depolama kullanımı, mevcut performans ölçümleri ve sistem yükü dahil olmak üzere çalışma zamanı ölçümlerini ve Ceph kümesinin mevcut durumunu takip etmekten sorumludur.

Ceph MON Nedir ?

MON map, Manager map, OSD map, MDS map ve CRUSH map dahil olmak üzere küme durumunun haritalarını tutar.
Bu haritalar, Ceph arka plan programlarının birbiriyle koordine olması için gerekli olan kritik küme durumudur.

Proxmox VE Ceph Storage Kurulumu

Artık Proxmox VE Ceph Storage kurulumuna başlayabiliriz.

Kurup cluster oluşturduğumuz node’ lara Ceph Install yapmamız gerekiyor bunu ister GUI üzerinden isterseniz de cli üzerinden yapabilirsiniz. Ben kurulum sırasında GUI üzerinden ilerledik ama her adımda cli üzerinden de ilgili komut satırlarını yazacağım.

#pveceph install

Sonrasında kuracağımız sürümü burda tercih ediyoruz ama dikkat edilmesi gereken bir durum var Proxmox VE’ nin sürümü ile Ceph’in sürümün uyuşması gerekiyor. Ben yaptığım testlerde 17.2’nin quincy stabil çalışmadığını gördükten sonra 16.2 pacific versiyonunu kurduk.

Burada dikkat edilmesi gereken bir diğer konu ise community edition kullandığımız için Proxmox VE’nin community’ si üzerinden iki ürünün uyumunu sorgulamamız gerekiyor.

Next diyerek devam ediyoruz ve karşımıza cluster configuration ekranı gelecek burada ilk node’u seçiyoruz ve bunu Ceph Mon olarak seçiyoruz. Burada dikkat edilmesi gereken bir konu cluster network olacak, kurulumun ilerleyen adımlarında onuda cli üzerinden değiştireceğiz.

Burada network takımınız ile istişare ederek bond mimarisinde bir network config’i ile cluster network’ünüzü ayrı bir vlan ile ayırabilirsiniz.

İlk node kurulumumuz tamamlandı sonrasında diğer node’larada ceph install işlemini yapıyoruz. Zatan burada kurulumlarla birlikte her node’un ceph mon‘u gelecektir. Biz daha sonrasında ceph mgr’ leri diğer node’ lara kuracağız.

CLI üzerindende aşağıdaki komutlarla kurulumlarınızı yapabilirsiniz.

#pveceph createmon

#pveceph createmgr

Ceph Install işlemimiz tamamlandı, ceph mon‘lar kuruldu ve ceph mgr‘ler kuruldu.
Burada yapmamız gereken bir diğer şey yazının içinde bahşetmiş olduğumuz cluster_network ve public_network düzeltilmesi olacak.

İlgili resimde ip’ler ilk node’a kurmuş olduğumuz ip ile geliyor biz bunları ilgili ip bloğu olarak değiştireceğiz.

nano etc/pve/ceph.conf

Artık disklerimizi OSD olarak ayarlayabiliriz. Diğer adımlarda yapmış olduğumuz üzere burada da hem GUI üzerinden hemde cli üzerindenişlem yapma imkanımız bulunuyor. Node üzerindeki diskleri tek tek OSD olarak grupluyoruz.

#pveceph osd create /dev/sd[X]

Aşağıdaki resimde görüldüğü gibi 3 node’lu bir Proxmox VE Cluster‘da 6’şar adet diskimizi her node üzerinde OSD olarak ayarladık.

Son olarak 3 node’ da oluşturmuş olduğum OSD‘leri bir pool altında toplamaya.

Create Ceph Pool diyerek karşımıza gelen ekran da pool’ umuza bir isim veriyoruz, replication size’ı “3“, minimum kopya sayısınıda “2” olarak bırakıyoruz.

Burada dikkat edilmesi gereken bir konu ise “PG Autoscale Mode” bunun “0ff” durumda olması gerekiyor neden diyecek olursanız yazımızın ilk bölümlerinde bahsetmiştik “PG” sayısının düşürülmesi yada yükseltilmesi kritik olduğundan dolayı bunu “On” bırakmamamız gerekiyor.

Son olarak gelelim “Number of PGs” ve “Min. Number of PGs” ayarlarına. Burada dikkatli davranmalıyız ve hesap yapmalıyız. Zatan “PG” sayısını ayarlarken mutlaka 2 ve katları olacak şekilde ayarlamalıyız.

Bizim ortamımız için yapılan hesaplamada ortam da 3 node var ve her node da 6 disk var buda 3×6 yaptığımızda 18 OSD ediyor. Replication size’ı “3” olarak düşündüğümüzde her OSD‘ye 128 PG veriyoruz zaten PG sayıları 100 ile 300 aralığında olmalıdır. 128 PG x 6 disk yaptığımızda node başına 768 PG oluyor bunu cluster olarak hesap ettiğimizde 768 PG x 3 node 2304 PG ediyor. Bunuda 3 replication size’a böldüğümüzde sayı 768 PG olarak karşımıza geliyor ama ileriye dönük büyümeyide düşünerek +1 fazlasını veriyorum ve number of PGs sayısını 1024 yapıyorum.

Yani minumum PGs 128 number of PGs ise 1024 olarak ayarlanıyor.

Tüm hesaplarda tamamlanınca bu pool’u storage olarak ekleyeceğiz. Add as Storage tikini işaretliyoruz.

Ceph Cluster’ın status durumunu kontrol etmek için herhangi bir node’a cli üzerinden bağlanıp “ceph status” komutunu çalıştırıyoruz.

Ceph mimarisi tarafında desteklerini esirgemeyen mesai arkadaşlarım Yusuf Güngör ve Mesut Şahin‘e ayrıca teşekkür ederim.

Bir sonraki Proxmox yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Proxmox VE Ceph Storage Kurulumu appeared first on BURAK AKTAŞ.

]]>