VPS mi Dedicated Sunucu mu: Hangisini Seçmelisiniz?

Yazar:komut.io ekibi Rehber & İpuçları
0 Yorum

Yıllarca hem VPS hem de dedicated sunucu yönettikten sonra şunu rahatlıkla söyleyebilirim: bu sorunun “doğru” bir cevabı yok, ama sizin durumunuz için kesinlikle daha iyi bir cevap var. İki seçeneği de yanılarak, bazen fazla para harcayarak, bazen de yetersiz kaynak kullanarak öğrendim. Bu yazıda o deneyimleri aktarmaya çalışacağım.

Temel Fark Nedir, Gerçekten?

Teknik tanımları zaten biliyorsunuz muhtemelen. VPS, fiziksel bir sunucunun sanallaştırma katmanıyla bölünmüş bir parçası. Dedicated ise o fiziksel sunucunun tamamı. Ama asıl mesele bu değil.

Asıl mesele şu: VPS’te komşularınız var, dedicated’ta yalnızsınız.

Bu komşuluk meselesi, benim deneyimimde en çok gözden kaçan nokta oluyor. Bir hosting sağlayıcısının fiziksel sunucusunda onlarca, hatta yüzlerce VPS çalışıyor olabilir. Bunlardan birinin ani trafik patlaması yaşaması, disk I/O’yu patlatması ya da ağı doldurması sizin performansınızı doğrudan etkiler. Buna “noisy neighbor” problemi deniyor ve gerçek hayatta çok karşılaşılan bir durum.

Dedicated’ta böyle bir derdiniz yok. Ama bunun da bedeli var.

Maliyet Analizi: Sadece Fiyat Etiketine Bakma

İlk bakışta VPS ucuz, dedicated pahalı gibi görünür. Türkiye’deki yaygın sağlayıcılara baktığınızda ortalama bir VPS planı aylık 3-15 dolar bandında, giriş seviyesi dedicated ise 50-100 dolar ve üzeri. Ama bu karşılaştırma yanıltıcı.

Şöyle düşünün: 4 vCPU, 8 GB RAM, 100 GB SSD alan bir VPS yerine dedicated bir sunucu istiyorsanız, fiyat farkı yaklaşık 3 ila 5 kat. Peki o fiyat farkını başka şeylere harcayarak daha mı iyi bir altyapı kurabilirsiniz?

Gerçek dünya senaryosu: Bir e-ticaret müşterim, yıllarca tek bir dedicated sunucu üzerinde çalıştı. Aylık 120 dolar ödüyordu. Biz bu yapıyı iki adet yüksek performanslı VPS’e taşıdık; biri uygulama sunucusu, biri veritabanı. Toplam maliyet 45 dolar. Performans? Daha iyi. Çünkü iş yüklerini ayırdık ve her biri kendi kaynağını kullandı.

Ama bunun tersi de oldu. Bir medya şirketinin yoğun video işleme yapan sunucusunu VPS’te çalıştırmaya çalıştık. Disk I/O sınırına sürekli takıldık, komşu kaynak kullanımından etkilendik. Dedicated’a geçince sorunlar çözüldü.

Ne Zaman VPS Yeterlidir?

Şu senaryolarda VPS genellikle ideal seçimdir:

  • Web siteleri ve bloglar: Orta trafik düzeyli WordPress siteleri, statik siteler, küçük-orta ölçekli uygulamalar
  • Geliştirme ve test ortamları: Her geliştirici için ayrı ortam, CI/CD pipeline’ları, staging sunucuları
  • Microservice mimarileri: Her servis için ayrı küçük VPS’ler, orkestrasyon için Kubernetes veya Docker Swarm
  • Başlangıç aşamasındaki projeler: Trafiğin ve ihtiyaçların henüz netleşmediği durumlar
  • Bölgesel dağıtım: Farklı coğrafi konumlarda düşük maliyetle varlık gösterme ihtiyacı

VPS’in en güçlü yönü esnekliktir. Kaynak ihtiyacınız arttığında birkaç tıklamayla yükseltebilirsiniz. Ya da birden fazla VPS’i yük dengeleyici arkasına koyarak ölçeklendirebilirsiniz.

# Birden fazla VPS için basit bir nginx yük dengeleyici konfigürasyonu
upstream backend_pool {
    least_conn;
    server 10.0.1.10:8080 weight=3;
    server 10.0.1.11:8080 weight=3;
    server 10.0.1.12:8080 weight=1 backup;
    keepalive 32;
}

server {
    listen 80;
    server_name ornek.com;
    
    location / {
        proxy_pass http://backend_pool;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
    }
}

Bu yapıyla üç adet orta seviye VPS kullanarak dedicated’dan daha iyi bir yüksek erişilebilirlik çözümü kurabilirsiniz.

Ne Zaman Dedicated Sunucu Gereklidir?

Bazı durumlar var ki VPS’in sınırları gerçekten sorun yaratır.

Yoğun I/O iş yükleri: Büyük veritabanları, video işleme, log analizi. Bu işlemlerde paylaşımlı disk I/O gerçekten performansı öldürür.

Düzenleyici gereklilikler ve uyumluluk: Bazı sektörlerde (finans, sağlık) verinin fiziksel olarak izole edilmesi zorunlu olabilir. KVKK veya sektöre özgü düzenlemeler bazen dedicated’ı zorunlu kılar.

Tahmin edilebilir yüksek CPU ihtiyacı: Makine öğrenmesi modeli eğitimi, render farm’ları, bilimsel hesaplamalar.

Özel donanım gereksinimleri: Belirli bir GPU modeli, RAID konfigürasyonu, HSM (Hardware Security Module) gibi özelleşmiş donanım ihtiyaçları.

Güvenlik gereksinimleri: Hypervisor katmanından kaynaklanan potansiyel güvenlik açıklarının tolere edilemediği durumlar.

Şunu da söylemek lazım: çok yüksek trafikli, monolitik bir uygulama bazen VPS üzerinde parçalanmış mimariden daha iyi çalışabilir. Her şeyin tek, güçlü bir makinede olması bazı durumlarda network overhead’ı ortadan kaldırır.

Performans Testleri: Kör Güvenmek Yerine Ölçün

Hangi seçeneği değerlendiriyorsanız olun, ölçüm yapın. Sağlayıcıların vaat ettiği rakamlar ile gerçek performans çoğunlukla farklıdır.

# Disk I/O performansını test etme
# fio aracını kurun: apt-get install fio

# Sıralı okuma testi
fio --name=seq-read --rw=read --bs=1M --size=4G 
    --numjobs=1 --iodepth=8 --runtime=60 
    --time_based --group_reporting

# Rastgele yazma testi (veritabanı simülasyonu)
fio --name=rand-write --rw=randwrite --bs=4K --size=2G 
    --numjobs=4 --iodepth=32 --runtime=60 
    --time_based --group_reporting --fsync=1
# CPU performans testi için sysbench
apt-get install sysbench

# CPU hesaplama testi
sysbench cpu --cpu-max-prime=20000 --threads=4 run

# Bellek bant genişliği testi
sysbench memory --memory-block-size=1M 
    --memory-total-size=100G 
    --memory-operation=write run
# Ağ performansı testi için iperf3
# Sunucuda
iperf3 -s -p 5201

# İstemcide (farklı bir makineden)
iperf3 -c SUNUCU_IP -p 5201 -t 30 -P 4

# Gecikme testi
ping -c 100 SUNUCU_IP | tail -1

Bu testleri hem potansiyel VPS hem de dedicated sağlayıcılarında mutlaka yapın. Ben bir keresinde “yüksek performanslı SSD” yazan bir VPS sağlayıcısında fio testi yaptım, çıkan sonuçlar ortalama bir HDD’den bile kötüydü. Sorduğumda “o an yoğunluk vardı” dediler. Dedicated sunucuda böyle bir bahanem olmazdı.

Sanallaştırma Teknolojileri ve Önemi

VPS seçiyorsanız, sağlayıcının hangi sanallaştırma teknolojisini kullandığı önemlidir.

KVM (Kernel-based Virtual Machine): Tam sanallaştırma sağlar, dedicated’a en yakın izolasyonu sunar. CPU saat frekansına doğrudan erişim vardır. Çoğu ciddi sağlayıcı bunu kullanır.

OpenVZ / LXC: Konteyner tabanlı izolasyon, kernel paylaşılır. Kaynak kullanımı daha verimli ama izolasyon daha zayıf. Kernel parametrelerini değiştiremezsiniz, bazı uygulamalar çalışmayabilir.

Xen: KVM’e benzer tam sanallaştırma, AWS’nin eski nesil alt yapısı bunu kullanıyordu.

# Hangi sanallaştırma altında çalıştığınızı kontrol edin
systemd-detect-virt

# Alternatif olarak
cat /proc/cpuinfo | grep "model name" | head -1
dmidecode -s system-manufacturer 2>/dev/null

# KVM üzerindeyseniz şunu görmelisiniz
virt-what 2>/dev/null || cat /sys/class/dmi/id/product_name

KVM olmayan bir VPS satın aldıysanız ve sonradan custom kernel modülü yüklemek ya da özel network konfigürasyonu yapmak zorunda kaldıysanız, o zaman gerçekten sıkıntı yaşarsınız.

Kaynak Overprovisioning Meselesi

VPS sağlayıcılarının büyük çoğunluğu “oversell” yapar. Yani fiziksel sunucudaki toplam kaynaktan daha fazla kaynak satar. Neden? Çünkü istatistiksel olarak tüm kullanıcılar aynı anda maksimum kaynağı kullanmaz.

Bu genellikle sorun yaratmaz. Ama siz peak yükünüzde tam kaynak istediğinizde komşunuz da peak yükündeyse, bu sefer “burst limit” devreye girer ve performansınız düşer.

# CPU steal time'ı izleyin - bu değer yüksekse komşularınız sizi etkiliyor demektir
# vmstat ile
vmstat 1 10

# top ile - "st" (steal) kolonuna bakın
top

# daha detaylı izleme için
mpstat -P ALL 1 5 | grep -E "CPU|Average"

# Eğer steal time sürekli %5'in üzerindeyse, sağlayıcınızla konuşma vakti
# ya da dedicated'a geçme vakti
sar -u 1 10 | grep -v "^$"

Dedicated sunucuda steal time kavramı yoktur. Tüm CPU döngüleri sizindir.

Yönetim ve Operasyon Yükü

Dedicated sunucu, daha fazla kontrol ama daha fazla sorumluluk demektir.

VPS’te genellikle şunlarla uğraşmazsınız:

  • Donanım arızaları (sağlayıcı halleder, sizi taşır)
  • RAID konfigürasyonu
  • BIOS/firmware güncellemeleri
  • Fiziksel ağ ekipmanı

Dedicated’ta bunların hepsini ya siz yönetirsiniz ya da sağlayıcıyla anlaşma (managed dedicated) yaparsınız. Managed dedicated oldukça pahalıdır.

# Dedicated sunucuda disk sağlığını izleme
# smartmontools kurulu olmalı
apt-get install smartmontools

# Disk durumu kontrolü
smartctl -a /dev/sda

# SMART testini çalıştır
smartctl -t short /dev/sda
# Sonuçları 2 dakika sonra kontrol et
smartctl -l selftest /dev/sda

# RAID durumunu kontrol et (yazılımsal RAID için)
cat /proc/mdstat
mdadm --detail /dev/md0
# Donanım arızası erken uyarı sistemi
# Bu scripti cron'a ekleyin

#!/bin/bash
DISK="/dev/sda"
THRESHOLD=10

REALLOCATED=$(smartctl -A $DISK | grep "Reallocated_Sector" | awk '{print $10}')
PENDING=$(smartctl -A $DISK | grep "Current_Pending_Sector" | awk '{print $10}')

if [ "$REALLOCATED" -gt "$THRESHOLD" ] || [ "$PENDING" -gt "0" ]; then
    echo "UYARI: Disk sorunları tespit edildi - Reallocated: $REALLOCATED, Pending: $PENDING" | 
    mail -s "DISK UYARISI - $(hostname)" [email protected]
fi

Bu tür monitoring VPS’te gereksizdir, dedicated’ta ise kritiktir. Çünkü disk arızasını önceden fark etmezseniz, veri kaybı ya da servis kesintisi yaşarsınız.

Hybrid Yaklaşım: İkisi Bir Arada

Gerçek hayattaki pek çok üretim ortamı artık ne saf VPS ne de saf dedicated. İkisini bir arada kullanmak mümkün.

Örneğin:

  • Veritabanı katmanı: Yüksek I/O gerektirdiği için dedicated
  • Uygulama katmanı: Ölçeklenebilir olması için VPS cluster
  • CDN ve static content: Cloud storage + CDN servisler
  • Monitoring ve log toplama: Küçük bir VPS

Bu yaklaşım hem maliyet optimizasyonu hem de performans açısından çoğu zaman en iyi sonucu verir. Ben genellikle müşterilere şunu öneririm: bottleneck olan katmanı dedicated’a taşıyın, geri kalanını VPS’te tutun.

# Uygulama sunucularında (VPS) veritabanı bağlantısını optimize etme
# PostgreSQL bağlantı havuzu için pgBouncer konfigürasyonu

cat > /etc/pgbouncer/pgbouncer.ini << 'EOF'
[databases]
uygulama_db = host=10.0.0.5 port=5432 dbname=production

[pgbouncer]
listen_port = 6432
listen_addr = 0.0.0.0
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction
max_client_conn = 200
default_pool_size = 25
min_pool_size = 5
reserve_pool_size = 5
log_connections = 0
log_disconnections = 0
EOF

Bu örnekte veritabanı dedicated bir sunucuda, uygulama VPS’lerde çalışıyor. PgBouncer ise bağlantı sayısını yönetiyor.

Sağlayıcı Seçimi: Teknik Özelliklerden Öte

Hem VPS hem dedicated için sağlayıcı seçimi kritiktir. Türkiye’deki kullanıcılar için bazı pratik notlar:

Network kalitesi: Yurt içi trafiğe önem veriyorsanız, sağlayıcının Türk internet değişim noktalarına (IX) bağlantısını sorgulayın. Bazı yabancı VPS sağlayıcıların Türkiye’ye latency’si 100ms’yi geçebilir.

SLA ve uptime garantisi: Kağıt üzerindeki %99.9 uptime garantisi ile gerçek uptime farklıdır. Referans isteyin, forumları okuyun.

Destek kalitesi: Dedicated sunucuda donanım arızasında sağlayıcının ne kadar sürede müdahale edeceği kritik. Bunu sözleşmede netleştirin.

Veri merkezi lokasyonu: KVKK açısından bazı sektörlerde veri Türkiye’de tutulmalı. Bunu göz ardı etmeyin.

Karar Verme Çerçevesi

Özetlemek gerekirse, şu soruları kendinize sorarak karar verebilirsiniz:

VPS tarafına işaret eden durumlar:

  • Aylık bütçeniz 100 doların altında
  • İş yükünüz dalgalı veya öngörülemiyor
  • Birden fazla izole ortama ihtiyaç duyuyorsunuz
  • Hızlı provision ve esnek ölçeklendirme önceliğiniz
  • Geliştirme, test, staging ortamı kuruyorsunuz
  • Uygulamanız yatay ölçeklenmeye uygun mimaride

Dedicated tarafa işaret eden durumlar:

  • Sürekli ve yüksek I/O iş yükünüz var
  • Düzenleyici uyum gereksinimleri fiziksel izolasyon gerektiriyor
  • Kernel parametrelerini ya da donanımı özelleştirmeniz gerekiyor
  • Tek büyük instance, birden fazla küçük VPS’ten daha mantıklı
  • Özel donanım ihtiyacınız var (GPU, özel depolama vs.)
  • Noisy neighbor probleminden defalarca etkilendiyseniz

Sonuç

Bu soruya “X her zaman daha iyidir” diye cevap verenlerden şüphelenin. Doğru seçim iş yükünüze, bütçenize, teknik gereksinimlerinize ve yönetim kapasitenize bağlı.

Kendi pratiğimden çıkardığım en önemli ders şu: ölçüm yapın, varsayım yapmayın. Bir VPS sağlayıcısını ciddiye almadan önce fio, sysbench ve iperf3 testlerini mutlaka çalıştırın. Dedicated sunucunuzu aldıktan sonra SMART testlerini ve monitoring’i ilk gün kurun.

İkinci önemli ders: sağlayıcı lock-in’den kaçının. Altyapınızı, kolayca başka bir yere taşıyabileceğiniz şekilde kurun. Ansible, Terraform ya da en azından iyi dökümante edilmiş runbook’lar bu konuda hayat kurtarır.

Ve son olarak: hybrid yaklaşımı küçümsemeyin. Bazen tek bir dedicated veritabanı sunucusu ile birkaç VPS’ten oluşan bir cluster, hem tek büyük dedicated’dan hem de tamamen VPS tabanlı mimariden daha iyi ve daha ucuz bir çözüm sunar.

Altyapı kararları geri dönüşü olmayan kararlar değil. Yanlış seçerseniz maliyetli olur ama düzeltilebilir. Önemli olan sisteminizi iyi izlemek ve darboğazları zamanında fark etmektir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir