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>

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

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

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

ceph osd tree

Varsayalım ghost ID = 45

OSD’yi crush map’ten sil

ceph osd crush remove osd.45

ceph osd crush remove osd.45

Auth kaydını sil

ceph auth del osd.45

ceph auth del osd.45

OSD ID’yi tamamen sil

ceph osd rm 45

ceph osd rm 45

Kontrol et

ceph osd tree
ceph -s

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Ş.

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

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

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

Sonra tekrar kontrol et:

ceph osd tree

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

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

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

Tekrar sil:

ceph osd crush remove r2-prx-test-03

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

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

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Ş.

Ö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

pvecm status

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

Node Listesi

pvecm nodes

pvecm nodes

Ceph Cluster Health

ceph -s

Beklenen:
HEALTH_OK

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

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

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

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

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

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ı

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

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

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.

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

10-CRUSH Host Entry Temizliği

ceph osd crush remove r1-prx-test-01

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

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.

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.

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

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

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

ceph -s

Beklenen:
HEALTH_OK

17-Ceph HCI Node Shrink Planning

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

Ö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

Ceph veri dağılımı:

Object
 ↓
PG
 ↓
OSD

Replica:
size=3

19-PG Hesaplama Formülü

PG = (OSD × 100) / replica

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.

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

5 node
12 OSD

Toplam: 60 OSD

22-Yeni PG Hesabı

(60 × 100) / 3 = 2000

İdeal: 2048 PG

Ama mevcut: 4096 PG

(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.

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

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.

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

⚠️ 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

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.

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

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

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Ş.

(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

Komut: ceph -s

Beklenen çıktı: HEALTH_OK

Ek Kontrol Komutları:

ceph osd tree
ceph pg stat

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

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

ceph osd dump | grep flags

Ardından maintenance flag’leri set edilir:

ceph osd set noout
ceph osd set norebalance
ceph osd set nobackfill

ceph osd set noout
ceph osd set norebalance
ceph osd set nobackfill

Kontrol: ceph osd dump | grep flags

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

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.

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

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

node06
node07
node08
node09
node10

2️⃣ MON içeren node’lar

node01
node02
node03
node04
node05

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)

Ö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

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

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

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.

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

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

Ö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.

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.

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Ş.

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

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

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.

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

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

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.

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

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

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.

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

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

CLI: lsblk

9️⃣ Disk Temizleme (Zap)

Yeni disk üzerinde eski metadata varsa temizlenir.

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

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

🔟 Yeni OSD Oluşturma

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

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

GUI

Node
 → Ceph
   → OSD
     → Create OSD

Disk seçilir ve OSD oluşturulur.

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

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

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

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

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Ş.

Proxmox cluster ortamında bazı node’lar GUI üzerinde “Unknown” durumuna düşebilir. Bu durumda:

• Node çalışıyor olabilir (SSH erişilebilir)
• HA aktif görünür
• Ancak GUI ve API tarafında node health okunamaz

Aşağıdaki gibi görünür:

Root Cause (En Yaygın Sebep)

Bu durum genellikle:

• pvestatd servisinin kilitlenmesi
• PID lock dosyasının bozulması
• Servisin zombie durumda kalması

nedenleriyle oluşur.

Troubleshooting Adımları

1️⃣ Servis Loglarını Kontrol Et

journalctl -xeu pvestatd.service

Bakılacak şeyler:

• timeout
• lock hataları
• stuck process

2️⃣ Process Kontrolü

ps aux | grep pvestatd

3️⃣ Port / File Lock Kontrolü

lsof | grep pvestatd

veya

fuser /var/run/pvestatd.pid.lock

Burada PID lock kullanan process varsa problem buradadır.

Çözüm (Restart ATMADAN)

1️⃣ Problemli Process’i Öldür

kill -9 <PID>

2️⃣ Servisi Yeniden Başlat

systemctl restart pvestatd

3️⃣ Durumu Kontrol Et

systemctl status pvestatd

ve GUI’den node durumunu kontrol et.

✅ Beklenen Sonuç

• Node status → Online
• Question mark → kaybolur
• Metrics → tekrar akmaya başlar

Sonuç

Bu problem reboot atmadan %95 çözülür ve Proxmox ortamlarında oldukça yaygındır.
Özellikle büyük cluster ortamlarda daha sık görülür.

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

The post Proxmox Node Status “Unknown” Problemi appeared first on BURAK AKTAŞ.

Proxmox HA ortamında bir node’u bakım moduna almak:

Node’u HA için geçici olarak devre dışı bırakır.
Üzerindeki HA VM’leri otomatik olarak diğer node’lara taşır.

Yani bakım yapacağın node boşaltılır, servis kesintisi olmadan işlem yaparsın.

Önemli Fark (VMware ile Karşılaştırma)

VMware’de olduğu gibi GUI üzerinden maintenance mode göremezsin / yönetemezsin.

Proxmox’ta bu işlem sadece CLI üzerinden yapılır.

Bakım Moduna Alma (Enable)

ha-manager crm-command node-maintenance enable NODENAME

Ne olur ?

• HA sistemi node’u unavailable olarak işaretler.
• Üzerindeki HA VM’ler diğer node’lara migrate edilir.
• Node boşalır ve bakım için hazır hale gelir.

Bakım Modundan Çıkarma (Disable)

Bakım bittikten sonra node’u tekrar cluster’a almak için:

ha-manager crm-command node-maintenance disable NODENAME

Ne olur ?

• Node tekrar available olur.
• HA sistemi isterse VM’leri geri taşıyabilir.

Önemli Notlar (Kritik)

1. VM’ler anında gitmez

• Komutu verdikten sonra migration başlar.
• Node tamamen boşalana kadar beklemelisin.

2. Reboot atsan bile maintenance mode kalır

• Node restart olunca otomatik çıkmaz.
• Mutlaka disable etmen gerekir.

3. Her node’dan çalıştırabilirsin

• Komutu sadece ilgili node’da değil.
• Cluster’daki herhangi bir node’dan çalıştırabilirsin.

Proxmox HA ortamında bakım yaparken:

❌ Direkt reboot/shutdown yapma
✅ Önce maintenance mode kullan

Bu, production ortamda servis kesintisini önleyen en kritik adımdır. 👍

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

The post Proxmox HA Maintenance Mode appeared first on BURAK AKTAŞ.

If you are configuring settings specific to a cluster, ensure that the same configurations are applied across all nodes in the cluster.

1. Checking for iscsi Initiator

Before proceeding, ensure that the iSCSI Initiator is already installed on your Proxmox system. You can verify its presence by checking the following directory:

/etc/iscsi/...

If it is not installed (typically, it is included if you installed Proxmox using the PVE.iso), you can install it using the following command:

apt-get install open-iscsi

2. Verifying the iSCSI Initiator Name

To begin, I confirmed the unique iSCSI Initiator Name on the Proxmox server. This step ensures proper communication between Proxmox and Pure Storage. The command used was:

cat /etc/iscsi/initiatorname.iscsi

The output displayed the InitiatorName, which is critical for iSCSI communication.

3. Creating a New Host in Pure Storage

In the Pure Storage management interface, I created a new host named “pve-01” to serve as the connection point for Proxmox VE.

4. Configuring the iSCSI IQNs

After creating the host, I configured its iSCSI IQNs to enable communication with Proxmox. The IQN value added was consistent with the Proxmox server’s initiator details.

5. Editing the iSCSI Configuration

The /etc/iscsi/iscsid.conf file was modified to set the session startup mode to automatic and configure session timeouts for stability. The relevant parameters edited included:

node.startup = automatic
node.session.timeo.replacement_timeout = 15

6. Restarting and Verifying iSCSI Service

I restarted the iscsid.service to apply the configuration changes and confirmed its active status using:

systemctl restart iscsid.service
systemctl status iscsid.service

7. Adding iSCSI Storage in Proxmox VE

Using the Proxmox VE interface, I added iSCSI storage under the “Datacenter” and configured it with portal addresses, target IQN, and nodes.

Volume usage / RDM blocking

If you want to use LVM on top of iSCSI, it make sense to set content none. That way it is not possible to create VMs using iSCSI LUNs directly. The iSCSI protocol does not define an interface to allocate or delete data. Instead, that needs to be done on the target side and is vendor specific. The target simply exports them as numbered LUNs. So Proxmox VE iSCSI volume names just encodes some information about the LUN as seen by the linux kernel. iSCSI is a block level type storage, and provides no management interface. So it is usually best to export one big LUN, and setup LVM on top of that LUN. You can then use the LVM plugin to manage the storage on that iSCSI LUN.

8. Scanning for iSCSI Targets

To ensure the iSCSI target was reachable, I used the pvesm scan iscsi command in the terminal. The scan successfully detected the Pure Storage target and its portals.

9. Configuring Multipath

I then set up multipath to provide fault tolerance and enhanced performance. The /etc/multipath/multipath.conf file was edited to include the Pure Storage device’s WWID and an alias:

multipath -a

10. Restarting Multipath Services

I restarted the Multipath service and verified it was running correctly:

systemctl restart multipath-tools.service
systemctl status multipath-tools.service

11. Verifying Multipath Devices

Using the multipath -ll command, I validated that the Pure Storage device paths were active and properly configured.

12. Adding LVM Storage in Proxmox

Next, I configured an LVM storage unit in Proxmox VE based on the connected iSCSI storage. The details included volume groups and allowed content types (disk images and containers).

13. Editing LVM Storage Configuration

I fine-tuned the LVM storage configuration, enabling options such as “Shared” and linking it to all nodes for seamless access across the cluster.

14. Final Verification

Lastly, I verified the storage integration in the Proxmox interface, ensuring the added LVM storage unit was accessible and operational.

Potential Issues

If you are adding your LUN to a cluster, it is likely that you will need to restart all nodes except the primary node. Otherwise, you may see a question mark icon above the iSCSI and LVM options in the Server View and realize that these nodes are not connected to the target at all. Alternatively, you can restart the service using the following command:

systemctl restart open-iscsi.service

Result

This detailed step-by-step configuration enabled seamless integration between Proxmox VE and Pure Storage using iSCSI and LVM. Each step was executed to ensure performance, reliability, and optimal storage utilization in my virtualized environment.

To verify redundancy, I performed a test by disabling the ports of Pure Storage controllers ct0 and ct1 sequentially. During the test, I verified that the network and IQN connections remained intact despite the port shutdowns. The result showed successful redundancy and stability of the configuration.

Source: Proxmox ISCSI Multipath

The post Proxmox VE with Pure Storage using iSCSI and LVM appeared first on BURAK AKTAŞ.

vSAN OSA ve ESA’nın Mimari Farklılıkları

vSAN OSA (Original Storage Architecture), vSAN’ın geleneksel mimarisidir. Bu modelde, her disk grubu bir önbellek katmanı (SSD) ve bir kapasite katmanından (HDD veya SSD) oluşur. OSA, hem hibrit (HDD+SSD) hem de tamamen flaş yapılandırmaları destekler ve geleneksel RAID yapılandırmalarını (RAID-1 ve RAID-5/6) kullanır. Ancak, OSA’nın önbellek temelli yapısı, modern NVMe cihazlarının tam performansını ortaya koyma konusunda sınırlamalara sahiptir.

vSAN ESA (Express Storage Architecture) ise vSAN 8 ile tanıtılan modern bir mimaridir. ESA, NVMe cihazları optimize bir şekilde kullanan, disk gruplarını ortadan kaldıran ve tüm cihazları tek bir depolama havuzunda birleştiren bir yapıya sahiptir. Bu sayede daha yüksek performans, daha basit yönetim ve daha iyi depolama verimliliği sağlar. ESA’nın daha az manuel yapılandırma gereksinimi ve gelişmiş veri dayanıklılığı özellikleri, büyük ölçekli veya performans odaklı ortamlar için önemli avantajlar sunar.

vSAN OSA Mimari Diyagramı

Bu diyagram, vSAN OSA’nın disk grupları ve önbellek katmanlarını içeren geleneksel yapısını gösterir.

vSAN ESA Mimari Diyagramı

Bu diyagram, vSAN ESA’nın NVMe tabanlı, disk grubu olmayan modern mimarisini temsil eder.

Performans Karşılaştırması

OSA, geleneksel disk gruplarına ve önbellekleme mekanizmalarına dayalı olduğundan, performans genellikle önbelleğe bağlıdır. Bu, okuma/yazma gecikmesini artırabilir ve toplam throughput değerlerini sınırlayabilir.

ESA, NVMe’nin sağladığı düşük gecikme avantajını tam anlamıyla kullanır. Disk grubu yapısı bulunmadığından, ESA doğrudan depolama cihazlarına erişim sağlayarak daha yüksek IOPS, daha düşük gecikme ve daha yüksek bant genişliği sunar. ESA’nın performans optimizasyonu sayesinde, özellikle yüksek IOPS gerektiren uygulamalarda ciddi farklar oluşur.

vSAN OSA ve ESA Performans Karşılaştırma Grafiği

Bu grafik, OSA ve ESA’nın okuma/yazma gecikmesi ve IOPS değerlerindeki farkları gösterir.

Verimlilik ve Kaynak Kullanımı

OSA, RAID-1 mirroring gibi yapılandırmalara dayandığından daha fazla depolama aşımı yaratabilir. Deduplication ve compression işlemleri genellikle sonradan yapılır ve bu da verimliliği sınırlayabilir. Ayrıca, geleneksel RAID yöntemleri, modern NVMe cihazlarının potansiyelini tam anlamıyla kullanma konusunda kısıtlayıcı olabilir.

ESA, inline deduplication ve compression gibi özelliklerle çok daha verimlidir. RAID-5/6 benzeri dayanıklılık sağlayarak, kapasite açısından daha az aşım oluşturur. ESA’nın daha verimli veri yönetimi, özellikle büyük veri kümeleriyle çalışan ortamlar için ciddi maliyet tasarrufları sunabilir.

Ölçeklenebilirlik ve Yönetim Kolaylığı

OSA, disk gruplarını genişletme yoluyla ölçeklenir, ancak bu yöntem daha fazla fiziksel donanım, manuel yapılandırma ve daha karmaşık bir yönetim süreci anlamına gelir. Özellikle büyük ölçekli ortamlar için yönetim karmaşıklığı artabilir.

ESA, basitleştirilmiş ölçeklenebilirlik sunar. Disk grubu bulunmadığı için yeni cihaz eklemek çok daha hızlıdır. Tek bir depolama havuzu üzerinden yönetim sağlandığından, daha az hata ve daha kolay kapasite planlaması yapılabilir. Bu da ESA’yı büyük ölçekli, hızlı büyüyen altyapılar için ideal bir çözüm haline getirir.

vSAN OSA ve ESA Ölçeklenebilirlik ve Yönetim Diyagramı

Bu diyagram, OSA ve ESA’nın ölçeklenebilirlik ve yönetim süreçlerindeki farklılıklarını gösterir.

Maliyet Karşılaştırması

OSA (Original Storage Architecture) genellikle daha düşük başlangıç maliyetlerine sahiptir. Bunun temel nedeni, hibrit yapılandırmaları (HDD + SSD) desteklemesi ve geleneksel RAID yapılandırmalarını kullanmasıdır. Ancak, bu yapılandırmalar daha fazla fiziksel kapasite gerektirdiği için, uzun vadede toplam sahip olma maliyeti (TCO) artabilir. Özellikle, RAID 1 (mirroring) ve RAID 5/6 (erasure coding) yapılandırmalarında kullanılan ek depolama kapasitesi, işletme giderlerini zamanla yükseltebilir.

ESA (Express Storage Architecture) ise, tamamen NVMe cihazlara dayalı olduğundan başlangıçta daha yüksek bir yatırım maliyeti gerektirir. NVMe cihazların fiyatları, geleneksel SSD’lere kıyasla daha yüksek olmasına rağmen, ESA’nın sunduğu gelişmiş sıkıştırma ve deduplikasyon özellikleri sayesinde depolama verimliliği önemli ölçüde artar. Ayrıca, ESA mimarisi daha az kapasite aşımı gerektirdiği için, uzun vadede depolama maliyetlerini azaltabilir. Bu durum, özellikle büyük veri kümelerine sahip ortamlarda, toplam sahip olma maliyetini dengeleme veya düşürme avantajı sağlayabilir.

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

The post VMware vSAN OSA ve ESA Karşılaştırması: Mimari, Performans ve Verimlilik appeared first on BURAK AKTAŞ.

Bu makale, Cluster Health – CLOMD Liveness Check hakkında bilgi verir ve vSAN Health Service’in neden bir hata raporlayabileceğini açıklar.

CLOMD (Cluster Level Object Manager Daemon), bir vSAN kümesinin çalışmasında kritik bir rol oynar. Her ESXi ana bilgisayarında çalışır ve şu görevlerden sorumludur:

• Yeni nesne oluşturma
• Arızalar sonrası mevcut nesnelerin onarımını başlatma
• Veri taşıma ve tahliyeleri yönetme (Maintenance Mode’a girme, vSAN’den disk çıkarırken veriyi tahliye etme, dengeyi sağlama ve yeniden dengeleme işlemlerini tetikleme, politika değişikliklerini uygulama vb.)

CLOMD, doğrudan veri yolu işlemlerine katılmaz ancak veri yolu işlemlerini tetiklediği için birçok yönetim iş akışında ve hata senaryosunda kritik bir bileşendir.

Şu işlemler sırasında CLOMD gereklidir:

• Virtual Machine (VM) Power On
• Storage vMotion to vSAN

Bu işlemler bir swap object oluşturmayı gerektirir ve nesne oluşturma işlemi CLOMD tarafından yönetilir.

Ayrıca, vSAN 6.0 itibarıyla bellek anlık görüntüleri (memory snapshots) nesne olarak saklanır. Bu nedenle, memory state içeren bir snapshot almak da CLOMD’yi gerektirir.

Diğer Önemli Daemon’lar

vSAN kümesinin sağlıklı çalışmasını sağlamak için çeşitli daemon’lar görev yapar:

EPD (Entry Persistence Daemon)

• Her vSAN kümesindeki ESXi ana bilgisayarında çalışır.
• Silinen nesnelerin bileşenlerinin sızdırılmadığından emin olur.

CMMDSD (Cluster Monitoring, Membership, and Directory Service Daemon)

• CMMDS (Cluster Monitoring, Membership and Directory Service) içeriğini korur.
• Küme bağlantılarını izler ve küme metadata dağıtımı için ana dağıtım altyapısıdır.
• Küme sağlığı ve ağ bağlantılarının durumunu korur.

OSFSD (Object Store File System Daemon) – vSAN 8.0U2 ile Eklendi

• ESXi üzerinde çalışan ve sanal makineler için dağıtılmış bir dosya sistemi sağlayan bir daemon’dur.
• vSAN’in birincil depolama işlevine ek olarak file services sunmasına olanak tanır.

CMMDSTIMEMACHINED (Cluster Monitoring, Membership, and Directory Service Time Machine Daemon) – vSAN 8.0U2 ile Eklendi

• ESXi üzerinde çalışır ve nesne versiyonları için geçmiş metadata kayıtlarını tutar.
• Metadata tutarsızlıklarını geri alma yeteneği sunarak, vSAN kümesinin kurtarılmasını sağlar.

Hangi vSAN Sürümlerinde Geçerlidir?

• VMware vSAN 6.x
• VMware vSAN 7.x
• VMware vSAN 8.x

Çözüm: Cluster Health – vSAN Daemon Liveness Check Nedir?

Bu kontrol, aşağıdaki daemon’ların çalışır durumda olup olmadığını test eder:

• CLOMD
• EPD
• CMMDSD
• OSFSD (vSAN 8.0U2 ile eklendi)
• CMMDSTIMEMACHINED (vSAN 8.0U2 ile eklendi)

Özellikle CLOMD için:

• Tüm ESXi host’larda çalıştığından emin olunur.
• Servisin istatistikleri sorgulanarak yanıt verip vermediği kontrol edilir.

Diğer daemon’lar için sadece çalışıp çalışmadığı test edilir.

Not: Bu kontrol, nesne oluşturma, yeniden dengeleme gibi işlevlerin çalıştığını garanti etmez ancak ilk seviye bir sağlık değerlendirmesi yapar.

Hata Durumu Ne Anlama Gelir?

Eğer bu kontrol hata veriyorsa, CLOMD, EPD, CMMDSD, OSFSD ve CMMDSTIMEMACHINED daemon’ları beklenildiği gibi çalışmıyor olabilir. İlgili ESXi host’ta durum kontrol edilmelidir.

CLOMD’nin sağlığını test etmek için:

• Bir sanal makine oluşturma testi yapılabilir (Proactive tests).
• Çünkü bu işlem, nesne oluşturmayı tetikler ve CLOMD’nin düzgün çalışıp çalışmadığını test etmenin iyi bir yoludur.

Daha fazla bilgi için: CLOM Daemon Liveness Check

Hata Durumu Nasıl Giderilir?

1. Standart Küme İçin

Tüm ESXi host’larda, aşağıdaki servislerin çalıştığından emin olunmalıdır:

• CLOMD
• EPD
• CMMDSD
• OSFSD
• CMMDSTIMEMACHINED

2. Stretched Cluster veya Metadata Cluster İçin

Aşağıdaki tabloya bakarak, ilgili node’da servisin çalışması gerekip gerekmediğini kontrol edin.

Eğer ESXi host’ta bir daemon çalışmıyorsa, ilgili daemon’ın durumu “Abnormal” olarak görünecektir.

3. Manuel Kontroller

ESXi host üzerinde daemon’ların durumunu kontrol etmek için:

/etc/init.d/cmmdsd status && /etc/init.d/epd status && /etc/init.d/clomd status && /etc/init.d/cmmdsTimeMachine status && /etc/init.d/osfsd status

Eğer bir daemon çalışmıyorsa, aşağıdaki komut ile yeniden başlatabilirsiniz:

/etc/init.d/cmmdsd restart && /etc/init.d/epd restart && /etc/init.d/clomd restart && /etc/init.d/cmmdsTimeMachine restart && /etc/init.d/osfsd restart

Eğer vSAN Daemon Liveness Check hala başarısız oluyorsa veya bu kontrol düzenli olarak başarısız olmaya devam ediyorsa, VMware Support ile iletişime geçilmelidir.

Daha fazla bilgi için: Creating and Managing Broadcom Support Cases

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

The post vSAN Health Service – Cluster Health – Daemon Liveness Check appeared first on BURAK AKTAŞ.