virtualization arşivleri | BURAK AKTAŞ https://www.burakaktas.com/etiket/virtualization/ Virtualization Technologies Blog Thu, 25 Jun 2026 21:38:47 +0000 tr hourly 1 https://wordpress.org/?v=7.0 https://www.burakaktas.com/wp-content/uploads/2020/04/cropped-vm_favicon-32x32.png virtualization arşivleri | BURAK AKTAŞ https://www.burakaktas.com/etiket/virtualization/ 32 32 Proxmox VE + Ceph HCI: Swap Sorunu ve Kalıcı Çözüm v9.x https://www.burakaktas.com/proxmox-ve-ceph-hci-swap-sorunu-ve-kalici-cozum-v9-x/ Thu, 25 Jun 2026 21:38:46 +0000 https://www.burakaktas.com/?p=4341 Proxmox + Ceph HCI ortamında swap dolduğunda ne olur, neden tehlikelidir ve nasıl kalıcı olarak çözülür adım adım. Swap Dolarsa Ne Olur? Ceph OSD’ler yavaşlar. OSD swap’a düştüğünde RAM↔disk I/O yerine RAM↔swap I/O yapıyor. Heartbeat’e geç cevap verir, cluster HEALTH_WARN alır, uzarsa OSD down olarak işaretlenir ve rebalance başlar. VM’ler etkilenir. QEMU process’i swap’a düşünce VM içindeki uygulama yavaşlar, “disk […]

The post Proxmox VE + Ceph HCI: Swap Sorunu ve Kalıcı Çözüm v9.x appeared first on BURAK AKTAŞ.

]]>

Proxmox + Ceph HCI ortamında swap dolduğunda ne olur, neden tehlikelidir ve nasıl kalıcı olarak çözülür adım adım.

Swap Dolarsa Ne Olur?

Ceph OSD’ler yavaşlar. OSD swap’a düştüğünde RAM↔disk I/O yerine RAM↔swap I/O yapıyor. Heartbeat’e geç cevap verir, cluster HEALTH_WARN alır, uzarsa OSD down olarak işaretlenir ve rebalance başlar.

VM’ler etkilenir. QEMU process’i swap’a düşünce VM içindeki uygulama yavaşlar, “disk yavaş” gibi görünür — asıl sorun host memory’dir.

En kötü senaryo: OOM Killer. Swap tamamen dolarsa kernel en fazla memory kullanan process’i öldürür. Bu ceph-osd veya bir QEMU process olabilir. OSD ölürse HEALTH_ERR, QEMU ölürse VM aniden kapanır.

Neden Oldu?

Linux kernel’inin varsayılan vm.swappiness değeri 60’tır. Bu “RAM dolmasa bile idle sayfaları swap’a at” demek. Proxmox kurulumunda Debian bu değere dokunmaz. Uzun uptime boyunca küçük küçük biriken swap kullanımı %90’ı aşabilir — sistem çalışıyor çünkü RAM hâlâ bol, ama tetikleyici bir olay (backup, recovery, yoğun I/O) gelince patlama noktasına dönüşür.

Proxmox staff’ın HCI ortamları için önerisi: swappiness = 10.

PVE 9 Notu: /etc/sysctl.conf artık yok. Tüm ayarlar /etc/sysctl.d/ altına yazılıyor.
1
Mevcut Durumu Gör

Başlamadan önce ne durumda olduğunu belge altına al.

bash 
echo "=== SWAP DURUMU ===" && free -h
echo "=== SWAPPINESS ===" && cat /proc/sys/vm/swappiness
echo "=== EN FAZLA SWAP KULLANANLAR ==="
cat /proc/*/status 2>/dev/null | \
  awk '/^Name/{name=$2} /^VmSwap/{if($2>0) print $2" kB --> "name}' | \
  sort -rn | head -10

Beklenen çıktı:

çıktı 
=== SWAP DURUMU ===
Swap:          8.0Gi       7.4Gi     614Mi

=== SWAPPINESS ===
60

=== EN FAZLA SWAP KULLANANLAR ===
2854288 kB --> kvm
808100 kB  --> kvm
254860 kB  --> ceph-mgr
101072 kB  --> ceph-osd
2
Swap’ı Güvenli Temizle

Swap’taki tüm sayfalar RAM’e geri çekilir. Önce yeterli RAM olduğunu doğrula:

bash 
awk '/MemAvailable/{avail=$2} /SwapTotal/{total=$2} /SwapFree/{free=$2}
     END{
       used=total-free;
       print "RAM Available : " avail/1024/1024 " GiB";
       print "Swap Used     : " used/1024/1024 " GiB";
       if(avail > used)
         print "SONUC: Guvenli, devam edebilirsin";
       else
         print "SONUC: UYARI - Yeterli RAM yok!";
     }' /proc/meminfo

“Güvenli, devam edebilirsin” yazıyorsa swap’ı temizle:

bash 
swapoff -a && swapon -a
⚠️ Birkaç dakika sürebilir, disk IO artar. Mesai saati dışında yap.

Temizlendi mi kontrol et:

bash 
free -h
# Swap: used → 0 olmalı
3
Kalıcı Çözüm — swappiness 10 Yap

Swap temizlendi ama swappiness hâlâ 60 ise birkaç ay sonra aynı yere dönersin.

bash 
echo "vm.swappiness=10" > /etc/sysctl.d/99-proxmox-hci-tuning.conf
sysctl -p /etc/sysctl.d/99-proxmox-hci-tuning.conf
cat /proc/sys/vm/swappiness
# Çıktı: 10
4
Son Kontrol
bash 
echo "=== SWAPPINESS ===" && cat /proc/sys/vm/swappiness
echo "=== SWAP DURUMU ===" && free -h | grep Swap
echo "=== AYAR DOSYASI ===" && cat /etc/sysctl.d/99-proxmox-hci-tuning.conf

Beklenen çıktı:

çıktı 
=== SWAPPINESS ===
10

=== SWAP DURUMU ===
Swap:   8.0Gi    0B    8.0Gi

=== AYAR DOSYASI ===
vm.swappiness=10

Tüm Cluster İçin Toplu Script

MacBook veya Linux bir OS üzerinden çalıştırılır. sshpass ile root şifresi kullanır, tüm node’lara sırayla bağlanır.

Gereksinim: brew install sshpass

Script’i oluştur:

bash 
cat > ~/swap-fix.sh << 'SCRIPT'
#!/bin/bash
# ============================================================
# Proxmox VE + Ceph HCI — Swap Tuning Script
# Cluster : prx-test (10 node)
# Tarih   : 2026-06-23
# Yazar   : Burak
# ============================================================

ROOT_PASS="buraya_root_sifresini_yaz"

NODES=(
  prx-test-01
  prx-test-02
  prx-test-03
  prx-test-04
  prx-test-05
  prx-test-06
  prx-test-07
  prx-test-08
  prx-test-09
  prx-test-10
)

GREEN='\033[0;32m'
RED='\033[0;31m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m'

ok()   { echo -e "${GREEN}[OK]${NC}   $1"; }
err()  { echo -e "${RED}[ERR]${NC}  $1"; }
warn() { echo -e "${YELLOW}[WARN]${NC} $1"; }
inf()  { echo -e "${BLUE}[INFO]${NC} $1"; }

apply_node() {
  local NODE=$1
  echo ""
  echo "============================================"
  inf "Node: $NODE"
  echo "============================================"

  sshpass -p "$ROOT_PASS" ssh \
    -o StrictHostKeyChecking=no \
    -o ConnectTimeout=10 \
    root@"$NODE" bash << 'REMOTE'

HOST=$(hostname)
SWAP_TOTAL=$(awk '/SwapTotal/{print $2}' /proc/meminfo)
SWAP_FREE=$(awk '/SwapFree/{print $2}'   /proc/meminfo)
MEM_AVAIL=$(awk '/MemAvailable/{print $2}' /proc/meminfo)
SWAP_USED=$((SWAP_TOTAL - SWAP_FREE))

echo "[$HOST] Mevcut swappiness : $(cat /proc/sys/vm/swappiness)"
echo "[$HOST] Swap used         : $((SWAP_USED/1024)) MiB"
echo "[$HOST] RAM available     : $((MEM_AVAIL/1024)) MiB"

echo "vm.swappiness=10" > /etc/sysctl.d/99-proxmox-hci-tuning.conf
sysctl -p /etc/sysctl.d/99-proxmox-hci-tuning.conf > /dev/null
echo "[$HOST] swappiness -> $(cat /proc/sys/vm/swappiness)"

if [ "$SWAP_USED" -eq 0 ]; then
  echo "[$HOST] Swap zaten temiz, atlanıyor."
elif [ "$MEM_AVAIL" -gt "$SWAP_USED" ]; then
  echo "[$HOST] Swap temizleniyor..."
  swapoff -a && swapon -a
  NEW_USED=$(awk '/SwapFree/{f=$2}/SwapTotal/{t=$2}END{print (t-f)/1024}' /proc/meminfo)
  echo "[$HOST] Swap temizlendi. Kalan: ${NEW_USED} MiB"
else
  echo "[$HOST] UYARI: RAM yetersiz, swap temizlenemedi!"
fi

echo "[$HOST] SONUÇ | swappiness: $(cat /proc/sys/vm/swappiness) | swap used: $(awk '/SwapFree/{f=$2}/SwapTotal/{t=$2}END{print (t-f)/1024}' /proc/meminfo) MiB"
REMOTE

  if [ $? -eq 0 ]; then
    ok "Node $NODE tamamlandı."
  else
    err "Node $NODE — bağlantı hatası!"
  fi

  if [ "$NODE" != "${NODES[-1]}" ]; then
    warn "30 saniye bekleniyor..."
    sleep 30
  fi
}

if ! command -v sshpass &> /dev/null; then
  err "sshpass yok. Kur: brew install sshpass"
  exit 1
fi

echo ""
echo "============================================"
inf "Swap Tuning Script başlıyor"
inf "Toplam node: ${#NODES[@]}"
echo "============================================"

for NODE in "${NODES[@]}"; do
  apply_node "$NODE"
done

echo ""
echo "============================================"
ok "TÜM NODE'LAR TAMAMLANDI"
echo "============================================"
SCRIPT

chmod +x ~/swap-fix.sh

Şifreyi yaz, çalıştır:

bash 
nano ~/swap-fix.sh
# ROOT_PASS satırını düzenle

bash ~/swap-fix.sh

Özet

Adım İşlem Kalıcı mı?
1 Mevcut durumu gör —
2 swapoff -a && swapon -a ✗ Tek seferlik
3 vm.swappiness=10 yaz ✓ Reboot sonrası da geçerli
4 Son kontrol —
Neden swap tamamen kapatılmadı?
Nadir de olsa OSD veya QEMU anlık memory spike yaşayabilir. Swap bu durumda OOM kill yerine zaman kazandırır. HCI ortamında swap’ı tamamen kaldırmak önerilmez.
Neden 10?
Proxmox staff’ın HCI ortamları için önerdiği değer. “Gerçekten mecbur kalmadıkça gitme” anlamına gelir. 0 yapmak modern kernel’de swap’ı tamamen kapatmaz, sadece ağırlığı düşürür.

Bu makale gerçek bir production ortamında uygulanan operasyon adımları esas alınarak hazırlanmıştır.

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

The post Proxmox VE + Ceph HCI: Swap Sorunu ve Kalıcı Çözüm v9.x appeared first on BURAK AKTAŞ.

]]> Proxmox LVM Snapshot – Upgrade Öncesi Yedek Alma https://www.burakaktas.com/proxmox-lvm-snapshot-upgrade-oncesi-yedek-alma/ Tue, 02 Jun 2026 22:05:23 +0000 https://www.burakaktas.com/?p=4330 Proxmox VE güncellemesi öncesinde sistemi anlık olarak yedekleyip, sorun çıkması halinde geri dönüş imkânı sağlayan operasyon adımları. Neden LVM Snapshot Alınmalı? Proxmox VE güncellemeleri bazen beklenmedik sorunlara yol açabilir: kernel panik, servis başlatma hataları veya yapılandırma kayıpları bunların başında gelir. LVM snapshot, upgrade öncesinde root volume’ün anlık bir kopyasını alarak sorun çıkması halinde sistemi dakikalar içinde eski haline döndürme imkânı […]

The post Proxmox LVM Snapshot – Upgrade Öncesi Yedek Alma appeared first on BURAK AKTAŞ.

]]>

Proxmox VE güncellemesi öncesinde sistemi anlık olarak yedekleyip, sorun çıkması halinde geri dönüş imkânı sağlayan operasyon adımları.

Neden LVM Snapshot Alınmalı?

Proxmox VE güncellemeleri bazen beklenmedik sorunlara yol açabilir: kernel panik, servis başlatma hataları veya yapılandırma kayıpları bunların başında gelir. LVM snapshot, upgrade öncesinde root volume’ün anlık bir kopyasını alarak sorun çıkması halinde sistemi dakikalar içinde eski haline döndürme imkânı sunar.

  • Snapshot alma işlemi saniyeler içinde tamamlanır, sistemi durdurmaya gerek yoktur
  • Upgrade başarılı olursa snapshot silinir, disk alanı geri kazanılır
  • Upgrade başarısız olursa lvconvert --merge ile sistem eski haline döner

1. Snapshot Al

Root volume’ü 15 GB geçici alan ayırarak anlık olarak yedekle. Bu adım upgrade öncesi yapılacak en kritik işlemdir.

lvcreate -L 15G -s -n root_before_upgrade /dev/pve/root

Başarılı çıktı şu şekilde görünür:

root@pve-demo:/# lvcreate -L 15G -s -n root_before_upgrade /dev/pve/root
  Logical volume "root_before_upgrade" created.

⚠️ 15G değeri geçici bir copy-on-write alanıdır. Upgrade sırasında root volume’de yapılan her değişiklik bu alana yazılır. Alan dolarsa snapshot geçersiz hale gelir — bu yüzden yeterli boş alan bırakmak önemlidir.

2. Snapshot’ı Kontrol Et

Alınan snapshot’ın aktif ve sağlıklı olduğunu doğrula.

lvs

Beklenen çıktı:

root@pve-demo:/# lvs
  LV                   VG   Attr       LSize   Pool Origin Data%  Meta%
  data                 pve  twi-a-tz-- 757.72g              0.00   0.25
  root                 pve  owi-aos---  96.00g
  root_before_upgrade  pve  swi-a-s---  15.00g      root    0.02
  swap                 pve  -wi-ao----   8.00g

root_before_upgrade satırında Origin: root ve düşük bir Data% değeri görülüyorsa snapshot sağlıklı demektir.

ℹ️ lsblk komutu ile de disk yapısını doğrulayabilirsin.

3. Upgrade Sırasında Snapshot’ı İzle (Opsiyonel)

Upgrade işlemi sürerken ikinci bir SSH oturumu açarak snapshot doluluk oranını gerçek zamanlı takip edebilirsin.

watch -n5 'lvs -o name,snap_percent 2>/dev/null'

⚠️ snap_percent değeri 100’e ulaşırsa snapshot geçersiz hale gelir ve geri dönüş imkânı ortadan kalkar. Bu durumda upgrade’i tamamlayıp elle müdahale etmen gerekir.

4. Upgrade’i Başlat

GUI ya da CLI üzerinden güncellemeyi başlat.

CLI üzerinden:

apt update && apt dist-upgrade

GUI üzerinden: Proxmox web arayüzünde Node → Updates → Upgrade butonuna tıkla.

Upgrade tamamlandıktan sonra yeni kernel’in devreye girebilmesi için sistemi yeniden başlat.

uname -a && reboot

Reboot sonrasında uname -a çıktısında yeni kernel sürümünü görüyorsan upgrade başarıyla tamamlanmış demektir.

5. Upgrade Sonrası — İki Senaryo

✅ Upgrade Başarılı: Snapshot’ı Sil

Her şey yolundaysa snapshot’a artık ihtiyaç yoktur. Aşağıdaki komutla silerek 15 GB disk alanını geri kazan:

lvremove /dev/pve/root_before_upgrade

Onay sorulduğunda y ile devam et.

❌ Upgrade Başarısız: Snapshot’tan Geri Dön

Upgrade sonrası sistem stabil değilse snapshot’ı root volume’e merge ederek sistemi eski haline döndür:

lvconvert --merge /dev/pve/root_before_upgrade && reboot

Komut çalıştırıldığında şu çıktı görünür:

root@pve-demo:/# lvconvert --merge /dev/pve/root_before_upgrade && reboot
  Delaying merge since origin is open.
  Merging of snapshot pve/root_before_upgrade will occur on next activation of pve/root.

Reboot sırasında merge işlemi otomatik tamamlanır. Sistem ayağa kalktığında root volume, snapshot alındığı andaki haline dönmüş olur.

⚠️ Merge işleminin tamamlanması için bazen 2. bir reboot gerekebilir. Sistem açıldıktan sonra lvs komutu ile root_before_upgrade satırının kaybolduğunu doğrula — bu merge’in başarıyla tamamlandığını gösterir.

reboot

Reboot sonrası lvs çıktısında root_before_upgrade satırı artık görünmüyorsa geri dönüş başarıyla tamamlanmıştır:

root@pve-demo:~# lvs
  LV    VG   Attr       LSize   Pool Origin Data%  Meta%
  data  pve  twi-a-tz-- 757.72g              0.00   0.25
  root  pve  -wi-ao----  96.00g
  swap  pve  -wi-ao----   8.00g

Özet

Tüm adımları sırasıyla uygula:

1

Snapshot Al

Upgrade öncesi root volume’ü anlık olarak yedekle. En kritik adım.

lvcreate -L 15G -s -n root_before_upgrade /dev/pve/root
2

Snapshot’ı Kontrol Et

Snapshot’ın aktif ve sağlıklı olduğunu doğrula.

lvs
3

Snapshot’ı İzle (Opsiyonel)

Upgrade sırasında 2. SSH oturumundan doluluk oranını takip et.

watch -n5 'lvs -o name,snap_percent 2>/dev/null'
4

Upgrade’i Başlat

GUI veya CLI ile güncellemeyi başlat, ardından sistemi yeniden başlat.

apt update && apt dist-upgrade && reboot
✓

Upgrade Başarılı — Snapshot’ı Sil

Her şey yolundaysa snapshot’ı silerek 15 GB disk alanını geri kazan.

lvremove /dev/pve/root_before_upgrade
✕

Upgrade Başarısız — Geri Dön

Sistem stabil değilse snapshot’ı merge ederek eski haline döndür.

lvconvert --merge /dev/pve/root_before_upgrade && reboot

Bu makale gerçek bir production ortamında uygulanan operasyon adımları esas alınarak hazırlanmıştır.

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

The post Proxmox LVM Snapshot – Upgrade Öncesi Yedek Alma appeared first on BURAK AKTAŞ.

]]> vSAN Performance Service: Stats Object Hatası & Çözümü https://www.burakaktas.com/vsan-performance-service-stats-object-hatasi-cozumu/ Tue, 26 May 2026 14:31:26 +0000 https://www.burakaktas.com/?p=4324 1. Sorun Tanımı vSAN Performance Service, vSphere ortamlarında cluster genelinde performans metriklerinin toplanması ve görselleştirilmesi için kullanılan kritik bir bileşendir. Bu servis düzgün çalışmadığında aşağıdaki belirtiler ortaya çıkar: Stats object health alanı boş (--) görünür Stats object UUID atanmamış Stats object storage policy bağlı değil Compliance status doğrulanamıyor “Failed to extract performance charts data” hatası alınır “vSAN Performance Service is […]

The post vSAN Performance Service: Stats Object Hatası & Çözümü appeared first on BURAK AKTAŞ.

]]>

1. Sorun Tanımı

vSAN Performance Service, vSphere ortamlarında cluster genelinde performans metriklerinin toplanması ve görselleştirilmesi için kullanılan kritik bir bileşendir. Bu servis düzgün çalışmadığında aşağıdaki belirtiler ortaya çıkar:

  • Stats object health alanı boş (--) görünür
  • Stats object UUID atanmamış
  • Stats object storage policy bağlı değil
  • Compliance status doğrulanamıyor
  • “Failed to extract performance charts data” hatası alınır
  • “vSAN Performance Service is disabled on this cluster” uyarısı çıkar

İlginç olan nokta şudur: Servis arayüzde Enabled görünmesine rağmen gerçekte çalışmıyor olabilir. Bu durum genellikle vSAN Stats DB objesinin hiç oluşturulmamış ya da bozulmuş olmasından kaynaklanmaktadır.

Performance Service arayüzünde stats alanları boş görünüyor
Şekil 1 – Performance Service arayüzünde tüm stats alanlarının boş (–) görünmesi

2. Olası Nedenler

  • vSAN datastore mevcut değil veya erişilemiyor
  • vSAN disk group’ları claim edilmemiş
  • Stats DB objesi hiç oluşturulmamış (yeni cluster kurulumu)
  • Stats DB objesi bozulmuş veya silinmiş
  • Performance Service UI toggle’ı (Disable/Enable) sorunu çözmüyor
⚠️ Disable → Enable toggle işlemi stats objesini otomatik oluşturmadığı durumlarda aşağıdaki RVC yöntemi kullanılmalıdır.

3. Çözüm: RVC ile Stats Objesi Yeniden Oluşturma

Bu makalede çözüm, VMware Remote Console (RVC) aracı kullanılarak vSphere 7.x ortamında gerçekleştirilmiştir. RVC, VCSA bünyesinde gömülü olarak gelen Ruby tabanlı bir komut satırı arayüzüdür.

3.1 vCenter Appliance’a SSH Bağlantısı

vCenter Server Appliance’a (VCSA) root hesabıyla SSH ile bağlanın:

ssh root@<vcenter_ip_adresi>

3.2 RVC’yi Başlatma

Bağlantı kurulduktan sonra RVC aracını başlatın:

rvc administrator@vsphere.local@localhost

Şifre sorulduğunda vCenter yönetici şifrenizi girin. Başarılı girişin ardından komut istemi rvc > şekline dönüşür.

⚠️ vSphere 7.x ve 8.x ortamlarında RVC başlatıldığında [DEPRECATED] RVC will be deprecated. It will not be available in the next major release. uyarısı görünebilir. Bu uyarı işlemi engellemez, güvenle devam edilebilir.

3.3 Cluster Path’inin Belirlenmesi

Cluster’ın RVC içindeki tam yolunu bulmak için:

ls
ls localhost/
ls localhost/<datacenter_adı>/computers/

3.4 Stats Objesinin Silinmesi ve Yeniden Oluşturulması

Önce mevcut stats objesini silmeye çalışın. Obje yoksa “Didn’t find any existing stats object” mesajı gelir — bu normaldir. Ardından yeni objeyi oluşturun:

> vsan.perf.stats_object_delete localhost/<datacenter>/computers/<cluster>/
Didn't find any existing stats object

> vsan.perf.stats_object_create localhost/<datacenter>/computers/<cluster>/
Creating vSAN Stats DB object, which will enable vSAN Performance Service ...
Task: Enable vSAN performance service
New progress: 1%
Task result: success
⚠️ “Didn’t find any existing stats object” bir hata değildir; stats objesinin daha önce hiç oluşturulmadığını gösterir.
RVC komut çıktısı - Task result success
Şekil 2 – RVC komutlarının başarılı çıktısı: Stats objesi oluşturuldu, “Task result: success”

4. Doğrulama

RVC’den çıktıktan sonra vCenter arayüzünden durumu doğrulayın:

  • Cluster → Configure → vSAN → Services → Performance Service bölümüne gidin
  • Stats object health alanının dolu geldiğini kontrol edin
  • Stats object UUID’nin atandığını doğrulayın
  • Storage policy’nin bağlandığını ve Compliance status’ün OK olduğunu teyit edin
  • Cluster → Monitor → vSAN → Performance altında grafiklerin geldiğini kontrol edin

5. RVC Versiyon Desteği ve Alternatifler

Bu çözümde kullanılan RVC (Ruby vSphere Console), vSphere’in tüm versiyonlarında desteklenmemektedir. Ortamınızın versiyonuna göre aşağıdaki tabloyu referans alabilirsiniz:

Versiyon RVC Durumu Açıklama Alternatif Yöntem
vSphere 6.x ✅ Tam Destekli Aktif, uyarısız çalışır RVC yeterli
vSphere 7.x ⚠️ Deprecated Uyarısı Çalışır, deprecation mesajı verir RVC veya PowerCLI
vSphere 8.x ⚠️ Deprecated (Hâlâ Var) VCSA’da mevcut, resmi olarak deprecated PowerCLI önerilir
vSphere 9.x / VCF 9 ❌ Kaldırıldı RVC artık VCSA’da yok PowerCLI veya UI

5.1 vSphere 7.x — Bu Makaledeki Senaryo

Bu makalede kullanılan ortam vSphere 7.x’tir. RVC, VCSA üzerinde fiziksel olarak mevcuttur ve çalışmaktadır. Başlatıldığında deprecated uyarısı görünse de tüm vsan.perf.* komutları sorunsuz çalışır.

✅ vSphere 7.x: RVC ile stats_object_create komutu başarıyla çalışır.

5.2 vSphere 8.x — Hâlâ Kullanılabilir

vSphere 8.x ortamlarında RVC hâlâ VCSA bünyesinde gömülüdür ve aynı komutlarla kullanılabilir. Ancak Broadcom, resmi olarak RVC’yi deprecated ilan etmiştir. Başlatma sırasında şu uyarı görünür:

[DEPRECATED] RVC will be deprecated.
It will not be available in the next major release.

Bu uyarıya rağmen vSphere 8.x’te aynı adımlar uygulanabilir. Broadcom’un kendi KB makaleleri de vSphere 8.x için RVC komutlarını hâlâ referans göstermektedir.

ℹ️ vSphere 8.x için uzun vadeli çözüm olarak PowerCLI tercih edilmesi önerilir.

5.3 vSphere 9.x / VCF 9 — RVC Kaldırıldı

vSphere 9.0 ve VCF 9 ile birlikte RVC, VCSA’dan tamamen kaldırılmıştır. Bu versiyonlarda aynı işlem PowerCLI ile gerçekleştirilmelidir:

# PowerCLI ile vCenter'a bağlan
Connect-VIServer -Server <vcenter_ip> -User administrator@vsphere.local -Password <sifre>

# vSAN Performance Service API nesnesini al
$cluster = Get-Cluster -Name "<cluster_adi>"
$vsanPerf = Get-VsanView -Id "VsanPerformanceManager-vsan-performance-manager"

# Stats objesini yeniden oluştur
$vsanPerf.VsanPerfCreateStatsObjectTask($cluster.ExtensionData.MoRef, $null)
❌ vSphere 9.x / VCF 9: rvc komutu bulunamaz. PowerCLI veya vCenter UI kullanılmalıdır.

5.4 Tüm Versiyonlarda Çalışan Yöntem: vCenter UI

Cluster → Configure → vSAN → Services → Performance Service → EDIT ekranından “Recreate stats object” seçeneği tüm desteklenen vSphere versiyonlarında mevcuttur. Eğer bu seçenek çalışmazsa (toggle sonuç vermiyorsa), yukarıdaki CLI yöntemine başvurulmalıdır.

6. Özet

vSAN Performance Service, UI üzerinde Enabled görünmesine rağmen Stats DB objesi eksikse çalışmaz. Bu durumda Disable/Enable toggle’ı sorunu çözmez; stats objesinin elle oluşturulması gerekir.

  • vSphere 6.x – 8.x: RVC aracı ile vsan.perf.stats_object_create komutu
  • vSphere 9.x / VCF 9: RVC kaldırıldı, PowerCLI veya vCenter UI kullanılmalı
  • Tüm versiyonlarda: UI üzerinden “Recreate stats object” seçeneği denenebilir
ℹ️ Bu makaledeki örnek vSphere 7.x ortamında test edilmiş ve başarıyla uygulanmıştır.

Bu makale gerçek bir production ortamında karşılaşılan sorun ve uygulanan çözüm esas alınarak hazırlanmıştır.

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

The post vSAN Performance Service: Stats Object Hatası & Çözümü appeared first on BURAK AKTAŞ.

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

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

]]> Proxmox Node Status “Unknown” Problemi https://www.burakaktas.com/proxmox-node-status-unknown-problemi/ Thu, 26 Mar 2026 21:30:54 +0000 https://www.burakaktas.com/?p=4238 Problem Tanımı Proxmox cluster ortamında bazı node’lar GUI üzerinde “Unknown” durumuna düşebilir. Bu durumda: Aşağıdaki gibi görünür: Root Cause (En Yaygın Sebep) Bu durum genellikle: nedenleriyle oluşur. Troubleshooting Adımları 1️⃣ Servis Loglarını Kontrol Et Bakılacak şeyler: 2️⃣ Process Kontrolü Hiç yok servis down Var ama stuck kill gerekir 3️⃣ Port / File Lock Kontrolü veya Burada PID lock kullanan process […]

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

]]> Problem Tanımı

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
Hiç yokservis down
Var ama stuckkill gerekir

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 Maintenance Mode https://www.burakaktas.com/proxmox-ha-maintenance-mode/ Thu, 26 Mar 2026 20:20:28 +0000 https://www.burakaktas.com/?p=4223 Ne İşe Yarar ? 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 […]

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

]]> Ne İşe Yarar ?

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

]]> Proxmox VE Cluster Yapılandırması https://www.burakaktas.com/proxmox-ve-cluster-yapilandirmasi/ Sun, 23 Jun 2024 14:20:19 +0000 https://www.burakaktas.com/?p=3893 Merhaba, bir önceki yazımda sizlere Proxmox VE 7.3 Kurulumu‘nu anlatmıştım. Bu yazıda sizlere birden fazla Proxmox VE node’ unun cluster seviyesine nasıl getirileceğini dilim döndüğünce anlatıyor olacağım. Proxmox VE (Virtual Environment) ile bir cluster kurulumunda minimum ve maksimum node sayıları şu şekildedir: Cluster yapılandırmasında her node, merkezi bir yönetim arayüzü üzerinden izlenebilir ve yönetilebilir. Ayrıca, yüksek erişilebilirlik (HA), canlı geçiş […]

The post Proxmox VE Cluster Yapılandırması appeared first on BURAK AKTAŞ.

]]> Merhaba, bir önceki yazımda sizlere Proxmox VE 7.3 Kurulumu‘nu anlatmıştım. Bu yazıda sizlere birden fazla Proxmox VE node’ unun cluster seviyesine nasıl getirileceğini dilim döndüğünce anlatıyor olacağım.

Proxmox VE (Virtual Environment) ile bir cluster kurulumunda minimum ve maksimum node sayıları şu şekildedir:

  • Minimum Node Sayısı: Proxmox VE ile bir cluster oluşturmak için en az 2 node gereklidir. Ancak, tek bir node ile de çalışabilir ve yönetim işlemlerini gerçekleştirebilirsiniz.
  • Maksimum Node Sayısı: Proxmox VE clusterında resmi olarak desteklenen maksimum node sayısı 32’dir. Ancak, bu sayı donanım ve ağ yapılandırmasına bağlı olarak değişebilir ve daha büyük ölçekli kurulumlar için dikkatli planlama ve yapılandırma gerektirir.

Cluster yapılandırmasında her node, merkezi bir yönetim arayüzü üzerinden izlenebilir ve yönetilebilir. Ayrıca, yüksek erişilebilirlik (HA), canlı geçiş (live migration) ve yük dengeleme gibi özelliklerden de yararlanabilirsiniz.

Ben yazımda iki node’ lu bir cluster yapısı anlatıyor olacağım. PVE-01 ve PVE-02’yi birbirine cluster yapacağız.

Node farketmez herhangi bir node’ un en tepesine giderek Datacenter seviyesinde “Create Cluster” diyoruz.
Cluster’ı GUI üzerinden veya cli üzerinden yapabiliriz.

CLI üzerinden yapmak istediğimizde ilgili node’ un cli’ ından “pvecm create clustername” komutunu kullanıyoruz.

Cluster’a bir isim veriyoruz ve create diyip devam ediyoruz.

Resimde gördüğünüz gibi Proxmox VE cluster mimarisine geçiş yaparken corosync servisi ile bu işi yapıyor ve gerekli dataları ilgili conf dosyalarına yazarak restart edip cluster filesystem’i devreye alıyor.

Proxmox Corosync, Proxmox sanallaştırma platformunun bir bileşenidir ve özellikle yüksek erişilebilirlik (HA) kümeleme için kullanılır. Corosync, bir küme içerisindeki düğümler arasında mesajlaşma ve veri senkronizasyonunu sağlamak için kullanılan bir yazılımdır. İşte Proxmox Corosync hakkında bazı önemli noktalar:

  • Küme İletişimi: Corosync, kümedeki düğümler arasında iletişimi sağlar. Bu, düğümlerin birbirleriyle senkronize olmasını ve bir düğümün arızalanması durumunda diğer düğümlerin bu durumu algılamasını mümkün kılar.
  • Yüksek Erişilebilirlik (HA): Corosync, Proxmox’un yüksek erişilebilirlik özelliklerini destekler. Bu, bir düğüm arızalandığında diğer düğümlerin otomatik olarak hizmet vermeye devam etmesini sağlar. Böylece kesintisiz hizmet sunumu mümkün olur.
  • Mesajlaşma ve Seçim Algoritmaları: Corosync, düğümler arasında mesajlaşma ve seçim algoritmaları kullanarak küme yönetimini gerçekleştirir. Bu sayede, hangi düğümün lider olacağı ve hangi düğümlerin hangi görevleri üstleneceği belirlenir.
  • Veri Senkronizasyonu: Corosync, düğümler arasında veri senkronizasyonunu sağlar. Bu, verilerin tutarlılığını ve bütünlüğünü koruyarak herhangi bir düğüm arızasında verilerin kaybolmamasını sağlar.
  • Proxmox Entegrasyonu: Proxmox sanallaştırma platformu, Corosync’i entegre ederek kullanıcıların sanal makinelerini yüksek erişilebilirlik modunda çalıştırmasına olanak tanır. Bu, özellikle kritik iş yükleri için önemli bir özelliktir.

Özetle, Proxmox Corosync, Proxmox sanallaştırma ortamında yüksek erişilebilirlik sağlamak için kullanılan bir küme mesajlaşma ve senkronizasyon yazılımıdır.

Cluster mimarisi tek node üzerinde oluştu. Artık PVE-01 bir cluster kümesinde biz bu kümeye PVE-2’yi dahil edeceğiz bunun içinde PVE-01 üzerinden Join Information bilgilerini alıyoruz.

Aldığımız bilgileri bu sefer kümeye dahil edeceğimiz PVE-02’nin Join Cluster sekmesine giderek bilgileri yapıştırıp “root” şifremizi giriyoruz.

Oluşturmuş olduğumuz Proxmox VE Cluster’ına ister GUI, isterseniz de cli üzerinden diğer nodeları ekleyebilirsiniz. Ben GUI üzerinden yapmayı tercih ettim ama cli üzerinden yapmak içinde komutlar aşağıdaki gibidir.

  • pvecm create clustername –> Cluster oluşturuyoruz.
  • pvecm add pve-node-01 –> Bu komutu cluster’a ekleyeceğimiz node’larda çalıştırıyoruz.
  • pvecm status –> Bu komut ile cluster’ın durumunu kontrol ediyoruz.

Bu işlemi tüm node’larda sırası ile yaptıktan sonra tüm Proxmox VE node’ larının cluster altında toplandığını görüyoruz.

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

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

The post Proxmox VE Cluster Yapılandırması appeared first on BURAK AKTAŞ.

]]>