Bir web sitesi, uygulama, oyun sunucusu veya kurumsal yazılım için altyapı ararken en zor soru çoğu zaman “Kaç GB RAM almalıyım?” değildir. Asıl soru, hangi sunucu modelinin iş yükünüze, bütçenize, büyüme planınıza ve kabul edebileceğiniz kesinti riskine uygun olduğudur. VPS, VDS, bulut sunucu, nested sunucu ve fiziksel sunucu terimleri birbirine benzer görünür. Oysa aralarında donanım sahipliğinden sanallaştırma katmanına, kaynak paylaşımından felaket kurtarmaya kadar ciddi farklılıklar bulunur.
Bu rehberde her teknolojinin nasıl çalıştığını, kimler için mantıklı olduğunu, nerede avantaj sağladığını ve hangi durumda gereksiz masraf yarattığını adım adım inceleyeceğiz. Yalnızca “en güçlü sunucu hangisi?” sorusunu değil; “aynı bütçeyle en doğru mimariyi nasıl kurarım?” sorusunu da yanıtlayacağız. Karşılaştırmalarda özellikle teknik olarak doğrulanabilir özelliklerle satış sayfalarında kullanılan ürün adlarını birbirinden ayıracağız.
Beş Sunucu Türünün 60 Saniyelik Özeti
| Teknoloji | En yalın tanım | En güçlü tarafı | En çok dikkat edilmesi gereken konu |
|---|---|---|---|
| VPS | Fiziksel bir sunucunun sanallaştırılmış bölümü | Ekonomik başlangıç, yönetim esnekliği | CPU paylaşımı, kaynak sınırları, komşu iş yükleri |
| VDS | Genellikle daha belirgin kaynak ayrımıyla pazarlanan sanal sunucu | Kaynak planlaması, öngörülebilirlik | “Dedicated” ifadesinin tam olarak neyi kapsadığı |
| Bulut sunucu | Kaynak havuzu ve otomasyon odaklı sunucu hizmeti | Hızlı sağlama, esnek ölçekleme potansiyeli | Mimariye göre değişen HA, yedekleme ve fatura modeli |
| Nested sunucu | Sanal bir makinenin içinde ikinci sanallaştırma katmanı | Laboratuvar, hypervisor ve çoklu VM kurma | L2 uyumluluğu, performans kaybı, ağ ve lisanslama |
| Fiziksel sunucu | Fiziksel donanımın bir müşteriye tahsisi | Donanım kontrolü, izolasyon, özel donanım | İlk maliyet, donanım arızası, kapasite yönetimi |
Bu tablo, teknoloji ailelerinin eğilimlerini gösterir; mutlak sıralama değildir. İyi tasarlanmış bir VPS, yanlış yapılandırılmış fiziksel sunucudan hızlı olabilir. Tek makineden oluşan bir “cloud” kurulumu da düzgün tasarlanmış çok düğümlü bir sistemden daha az dayanıklı olabilir. Bir ürünü yalnızca adına bakarak değerlendirmek, otomobili yalnızca kaputundaki yazıyla satın almaya benzer.
Önce beş kritik soruyu yanıtlayın
- Kaç kişi kullanacak? Eşzamanlı kullanıcı, ziyaretçi sayısından daha belirleyici olabilir.
- Uygulama ne tüketiyor? CPU, RAM, disk I/O, veritabanı bağlantısı ve ağ bant genişliği ayrı ayrı incelenmelidir.
- Kesintiye ne kadar dayanabilirsiniz? Birkaç saat durabilen test sistemiyle dakikalar içinde satış kaybettiren e-ticaret sitesi aynı mimariye ihtiyaç duymaz.
- Sistem büyüyecek mi? Bugünkü tüketim kadar altı ay sonraki trafik ve veri hacmi de önemlidir.
- Yönetimi kim yapacak? Root erişimi, işletim sistemi güncellemeleri, güvenlik duvarı ve geri yükleme operasyonunu üstlenecek ekip var mı?
Sunucuların Temel Çalışma Mantığı: Donanım, Hypervisor ve Sanal Makine
Bir bilgisayarın üzerinde işlemci, bellek, depolama ve ağ arabirimleri bulunur. Fiziksel sunucu da bunların veri merkezi ortamına uygun tasarlanmış hâlidir: yüksek bellek kapasitesi, ECC RAM, uzaktan yönetim, yedekli güç kaynağı ve çoklu disk gibi özellikler sunabilir. Bu donanımın üzerine doğrudan işletim sistemi kurabilirsiniz. Alternatif olarak bir hypervisor kurarak tek fiziksel makineden birden fazla sanal makine oluşturabilirsiniz.
Sanallaştırma, fiziksel kaynakları mantıksal olarak bölüştürür. Her sanal makine kendine ait işletim sistemi, disk dosyası veya blok aygıtı, sanal ağ kartı ve tahsis edilmiş bellek sınırı ile çalışabilir. Örneğin 32 fiziksel çekirdeği ve 256 GB RAM’i olan bir ana sunucu üzerinde birden fazla Linux veya Windows sanal makinesi barındırılabilir. Ancak toplam sanal çekirdek sayısının fiziksel çekirdek sayısını aşması mümkündür; bunun performansa etkisi eşzamanlı yük ve sağlayıcının kaynak planlama politikasına bağlıdır.
Hypervisor türleri: Tip 1 olarak bilinen bare-metal hypervisor, fiziksel donanıma yakın konumda çalışır; VMware ESXi, Microsoft Hyper-V ve KVM tabanlı kurulumlar bu alanda değerlendirilir. Tip 2 yaklaşımında ise örneğin masaüstünde VirtualBox gibi bir yazılım, genel amaçlı işletim sistemi üzerinde çalışır. KVM teknik olarak Linux çekirdeği içinde işlev görür; bu nedenle “Tip 1 / Tip 2” ayrımı her gerçek dünya mimarisini kusursuz anlatmaz. Önemli olan sanal makinelerin nasıl yönetildiği, izole edildiği ve donanıma hangi yollardan eriştiğidir.
Proxmox VE bir işletim sistemi mi, hypervisor mı? Proxmox VE, Debian tabanlı bir sanallaştırma yönetim platformudur; KVM sanal makinelerini ve LXC konteynerlerini yönetir. Hypervisor ile yönetim paneli aynı şey değildir. Benzer şekilde “KVM kullanıyoruz” ifadesi, otomatik olarak çok düğümlü bulut, yedekleme veya belirli bir depolama mimarisi anlamına gelmez.
vCPU, fiziksel çekirdek ve işlemci zamanı aynı şey değildir
Bir pakette “8 vCPU” yazıyorsa bu, mutlaka müşteriye sekiz bağımsız fiziksel çekirdeğin ayrıldığı anlamına gelmez. Bir vCPU, hypervisor’ın sanal makineye sunduğu mantıksal işlem birimidir. Sağlayıcı sanal çekirdekleri fiziksel çekirdeklere belirli bir oranla eşleyebilir, zamanlayabilir, sınırlandırabilir veya özel tahsisli olarak yapılandırabilir. “8 vCore özel tahsisli” ifadesi bile çekirdeğin yalnızca o müşteriye fiziksel düzeyde ayrılıp ayrılmadığı konusunda ilave teknik açıklama gerektirebilir.
Örneğin iki farklı sağlayıcının aynı “8 vCPU / 16 GB RAM” paketleri, CPU nesli, baz ve turbo frekansı, NUMA yerleşimi, CPU steal time, işlemci overselling oranı ve disk gecikmeleri yüzünden çok farklı sonuç verebilir. Gerçek performans karşılaştırmasında yalnızca paneldeki sayılara değil, iş yükünüze benzeyen ölçümlere bakın.
Sanal makine ile konteyner arasındaki fark
Sanal makine kendi çekirdeğini ve işletim sistemini çalıştırabilir. Konteynerler çoğunlukla ana sistemin Linux çekirdeğini paylaşır ve süreçleri izole eder. Docker konteynerini bir VPS üzerinde çalıştırmak, otomatik olarak nested virtualization değildir. Kubernetes kümesi de her zaman nested sanallaştırma gerektirmez; birden çok normal VM veya fiziksel makine üzerinde çalışabilir.
VPS Sunucu Nedir?
VPS (Virtual Private Server), fiziksel sunucu üzerinde sanallaştırma veya işletim sistemi seviyesinde izolasyon kullanılarak sunulan, müşteriye ayrı bir çalışma alanı sağlayan sanal sunucu hizmetidir. VPS satın aldığınızda çoğunlukla size ayrılmış sanal CPU, RAM ve depolama sınırları ile işletim sistemi yönetim erişimi verilir. Donanımı satın almazsınız; üzerinde çalıştığınız kaynakları kiralarsınız.
Bir VPS üzerinde WordPress, Nginx, Apache, PHP, Node.js, Python, PostgreSQL, MySQL/MariaDB, Redis, VPN ve benzeri servisler çalıştırılabilir. İşletim sistemi ve sağlayıcı izin verdiği sürece Docker konteynerleri de kurulabilir. VPS’nin uygunluğu uygulamanın RAM tüketimine, trafik desenine, veri hacmine ve yönetim ihtiyaçlarına bağlıdır.
VPS nasıl çalışır?
Bir fiziksel ana makine üzerinde örneğin 20 müşteri sanal makinesi bulunduğunu düşünün. Her VM diğerlerinden mantıksal olarak ayrılır; ancak aynı fiziksel CPU, depolama ve ağ altyapısına erişir. Sağlayıcı kaynak tahsisini dikkatle yönetiyorsa komşu iş yüklerinin etkisi düşük olabilir. Kaynaklar fazla satılmışsa yoğun saatlerde CPU bekleme süresi ve disk yanıt süresi artabilir. Bu davranışa sıklıkla noisy neighbor, yani gürültülü komşu etkisi denir.
Burada önemli ayrım şudur: Modern KVM tabanlı VPS tam sanallaştırma sunabilir; bazı eski veya farklı VPS ürünleri ise işletim sistemi düzeyinde konteyner izolasyonu kullanır. Dolayısıyla “VPS = kesin paylaşımlı ve zayıf”, “VDS = kesin donanımsal olarak ayrılmış” gibi evrensel bir denklem yoktur.
VPS’nin avantajları
- Genellikle düşük başlangıç bütçesiyle kurulabilir.
- Paylaşımlı hosting’e göre işletim sistemi ve uygulama üzerinde daha fazla kontrol sağlar.
- Küçük sitelerden geliştirme ortamlarına kadar birçok iş yükünü barındırabilir.
- İyi bir sağlayıcıda imajdan yeniden kurulum, panel ve snapshot gibi işlemler kolaylaşabilir.
- Proje küçükken kaynakları büyütmek mümkündür; ancak değişiklikte yeniden başlatma gerekebilir.
VPS’nin sınırları
Çok büyük trafik, yoğun veritabanı sorguları, sürekli çalışan video dönüştürme, ağır derleme ve yüksek IOPS isteyen işlemlerde uygun olmayan bir VPS paketi zorlanabilir. Paket özellikleri yeterli görünse bile CPU paylaşımı, düşük disk I/O limiti veya kısıtlı ağ çıkışı gerçek darboğaz olabilir. VPS üzerinde tam root erişimi sunulması da sağlayıcının her çekirdek özelliğini, özel kernel modülünü veya nested virtualization’ı açacağı anlamına gelmez.
VPS kimler için mantıklı? Kişisel siteler, orta ölçekli bloglar, geliştirme/staging ortamları, düşük ve orta trafikli API’ler, küçük uygulamalar, hafif botlar ve öngörülebilir tüketimi olan projeler için iyi başlangıç noktası olabilir. İlk ölçümleri aldıktan sonra gereksinime göre yükseltme yapmak, baştan kapasitenin büyük bölümünü boş bırakmaktan daha ekonomik olabilir.
VDS Sunucu Nedir? VPS ile Arasındaki Gerçek Fark
VDS (Virtual Dedicated Server), kelime anlamıyla sanal adanmış sunucudur. Türkiye’deki barındırma pazarında bu terim sıklıkla CPU kaynaklarının daha belirgin tahsis edildiği, performans izolasyonunun daha güçlü biçimde sunulduğu veya üst segment sanal makine paketleri için kullanılır. Ancak VPS ve VDS’yi birbirinden ayıran, bütün sağlayıcılarca kabul edilmiş zorunlu bir teknik standart yoktur.
VDS adı fiziksel sunucuya eşdeğer olmak anlamına gelmez. Aynı fiziksel host üzerinde başka müşteriler bulunabilir; depolama, ağ, bellek bant genişliği ve diğer bileşenler ortak altyapıyı kullanıyor olabilir. Bazı sağlayıcılar VDS ile VPS’yi neredeyse eş anlamlı kullanır, bazıları da farklı CPU paylaşım politikaları uygular.
VDS satın alırken hangi soruları sormalısınız?
- CPU gerçekten nasıl tahsis ediliyor? Dedicated vCPU, CPU pinning, fiziksel core tahsisi veya yalnızca öncelik garantisi mi sunuluyor?
- İşlemcinin tam modeli ve nesli nedir? “Xeon” veya “EPYC” adı tek başına ölçülebilir bir performans belirtmez.
- Disk alanı mı, IOPS garantisi mi var? 200 GB NVMe kapasitesi depolama performansını tanımlamaz.
- RAM fiziksel olarak rezerve mi? Memory overcommit ve ballooning uygulamaları neler?
- DDoS, yedekleme ve yönetim hizmeti pakete dahil mi? Sıklıkla ayrı fiyatlanırlar.
- SLA tam olarak neyi kapsıyor? Donanım, ağ veya uygulama seviyesinde mi; kredi ve istisnalar neler?
Pratik bir VDS örneği
Diyelim ki gün boyunca 100–200 kullanıcıya hizmet veren bir muhasebe uygulamanız var. Aylık trafik çok yüksek olmasa bile belirli saatlerde rapor üretimi ve veritabanı sorguları işlemci tüketimini artırıyor. Bu durumda düşük maliyetli ve agresif CPU paylaşımlı bir sanal sunucu yerine, daha açık kaynak tahsisi taahhüdü veren bir VDS paketi daha tutarlı yanıt süreleri sağlayabilir. Yine de gerçek karar, yük testi ve paket koşullarına dayanmalıdır.
Pazardaki yapılandırmaları karşılaştırmak isteyenler, örneğin VDS sunucu paketlerinin CPU, RAM, depolama ve ağ özelliklerini bir kontrol listesiyle inceleyebilir. Burada önemli olan marka veya paket adından ziyade, kaynağın hangi koşulla tahsis edildiğini anlamaktır.
VPS mi, VDS mi?
İki paket aynı CPU paylaşım politikasına, aynı hypervisor’a ve aynı depolama sistemine sahipse, sırf birinin VDS diye etiketlenmesi onu otomatik olarak üstün yapmaz. Öte yandan bir pakette fiziksel çekirdek tahsisi, daha öngörülebilir disk performansı ve güçlü servis taahhütleri gerçekten varsa, iş açısından fark yaratabilir. Karar kriteri isim değil, teknik şartnamedir.
Bulut Sunucu Nedir? Cloud Server Ne Anlama Gelir?
Bulut sunucu (cloud server), talep üzerine sağlanabilen ve paylaşılan bir hesaplama kaynak havuzundan yararlanan sunucu hizmetidir. NIST’in bulut bilişim tanımı beş temel özelliğe odaklanır: talep üzerine self-servis, geniş ağ erişimi, kaynak havuzu, hızlı esneklik ve ölçülebilir hizmet. Bu yaklaşım bulutu tek başına bir sanallaştırma yazılımından veya belirli bir sunucu kasasından ayırır.
Bulut sunucular da çoğu zaman sanal makinelerdir. Bulutu farklılaştıran unsur, gerektiğinde kaynak oluşturmayı, değiştirmeyi, izlemeyi ve bazı mimarilerde birden fazla fiziksel ana makine arasında hizmeti sürdürmeyi kolaylaştıran işletim modelidir. Ancak “cloud” adı olan her ürün otomatik ölçekleme, çoklu veri merkezi, canlı taşıma veya yüzde yüz çalışma süresi sunmaz.
Bulut sunucunun beş temel özelliği
1. Talep üzerine hizmet: Kullanıcı uygun panel veya API üzerinden kaynak oluşturabilir. İnsan onayı beklemeden otomasyon kurabilmek operasyonel hız sağlar.
2. Ağ üzerinden erişim: Sunucular internet veya özel ağ üzerinden yönetilir ve servis verir. Lokasyon, gecikme ve güvenlik politikaları önemini korur.
3. Kaynak havuzu: CPU, bellek, ağ ve depolama bir havuzda organize edilir. Farklı müşteriler birbirinden mantıksal olarak izole edilir; fiziksel kaynak paylaşımı tasarıma göre değişir.
4. Hızlı esneklik: Belirli sınırlar içinde kaynak kapasitesi genişletilip daraltılabilir. Bunun otomatik mi, manuel mi, yeniden başlatmalı mı gerçekleştiğini ayrıca kontrol etmek gerekir.
5. Ölçülebilir kullanım: Faturalandırma saatlik, aylık, ayrılmış kapasiteye veya ölçülen kullanıma dayalı olabilir. “Bulut = sadece kullandığın kadar ödersin” her ürün için doğru değildir.
Bulut sunucunun tek VPS’den temel farkı
Basit bir VPS de panelden saniyeler içinde kurulabilir. Bu tek başına onu olgun bir bulut platformuyla eşitlemez. Çok düğümlü altyapı, yazılım tanımlı ağ, API, otomasyon, paylaşımlı depolama, arıza alanı ayrımı ve planlı bakım davranışı gibi özellikler bulut mimarisinin niteliğini belirler. Yine de her bulut sağlayıcı bu özelliklerin tamamını her pakette sunmaz.
Önemli yanlış anlama: “Bulut sunucu aldım, fiziksel sunucu bozulursa sitem hiç kesilmez.” Bu garanti değildir. Yüksek erişilebilirlik (HA) için sağlayıcının host arızasını nasıl yönettiği, disklerin nerede bulunduğu, başka düğüme geçiş desteği ve uygulamanın kendisinin kaç kopya çalıştığı incelenmelidir. Tek VM’yi aynı bölge içinde yeniden başlatmak, kesintisiz çalışan çok düğümlü uygulamayla aynı şey değildir.
Google Cloud’un host bakım davranışlarını açıklayan dokümantasyonu iyi bir örnektir: bazı VM türleri canlı taşınabilirken bazı türler bakımda durdurulur veya yeniden başlatılır. Dünyanın büyük platformlarında bile bu yetenekler sunucu türüne göre değişiyorsa, genel bir “cloud asla durmaz” iddiası teknik olarak savunulamaz.
Dikey ve yatay ölçekleme: Neden önemli?
Dikey ölçekleme (scale up), mevcut sunucunun RAM’ini 8 GB’dan 16 GB’a veya vCPU sayısını 4’ten 8’e çıkarmaktır. Uygulama değişmeden rahatlama sağlayabilir. Bunun için kimi zaman sunucuyu yeniden başlatmak gerekir ve tek makinenin ulaşabileceği bir üst sınır vardır.
Yatay ölçekleme (scale out), tek sunucu yerine uygulamanın iki, üç veya daha fazla kopyasını çalıştırmaktır. Örneğin yük dengeleyici arkasına üç uygulama sunucusu koyarak artan istekleri dağıtabilirsiniz. Bunun çalışması için oturumların merkezi saklanması, dosya yüklemelerinin ortak depoya yönlendirilmesi ve veritabanı darboğazlarının çözülmesi gerekir. Sadece sunucu sayısını artırmak her uygulamayı ölçeklenebilir yapmaz.
IaaS, PaaS ve SaaS bulutla nasıl ilişkilidir?
- IaaS (Infrastructure as a Service): Sanal makine, disk ve ağ gibi altyapı kaynakları kiralanır. İşletim sisteminin ve uygulamanın büyük kısmını müşteri yönetir.
- PaaS (Platform as a Service): Uygulama çalıştırma ortamı daha fazla yönetilir. İşletim sistemiyle uğraşmadan kod dağıtmak kolaylaşabilir.
- SaaS (Software as a Service): Son kullanıcı hazır yazılımı kullanır; sunucuya doğrudan sahip olmak veya yönetmek zorunda değildir.
“Bulut sunucu” satın alırken çoğunlukla IaaS kategorisine yakın bir hizmetten söz ederiz. Yönetilen veritabanı, nesne depolama veya sunucusuz işlevler aynı hizmetin parçası olmak zorunda değildir.
Bulut sunucu hangi projelerde tercih edilmeli?
Kampanya dönemlerinde büyüyen e-ticaret uygulamaları, otomasyon ağırlıklı yazılımlar, API servisleri, mikroservis mimarileri, test ortamlarını hızlı kurup silen ekipler ve gelecekte birden fazla düğüme dağıtılması planlanan sistemler buluttan fayda görebilir. Ancak tek blog için çok karmaşık bir küme kurmak, çözülmemiş bir problemi büyütmekten ibaret olabilir.
Satın alma öncesinde bulut sunucu yapılandırmalarını değerlendirirken disk tipi, vCore tahsisi, kaynak artırma yöntemi, yedekleme bedeli ve bakım sırasında VM’nin davranışı birlikte sorgulanmalıdır. İyi bir bulut deneyimini belirleyen şey yalnızca hızlı kurulum değildir; kapasite ve arıza yönetiminin açıkça belgelenmesidir.
Nested Sunucu Nedir? Nested Virtualization Nasıl Çalışır?
Nested virtualization, bir sanal makine içinde başka bir hypervisor çalıştırıp onun da yeni sanal makineler oluşturmasını sağlayan mimaridir. Türkçede “iç içe sanallaştırma” adıyla da anılır. Normal sanallaştırmada fiziksel host üzerindeki hypervisor sanal makineleri yönetir. Nested yapıda ise ilk sanal makine kendi içinde ikinci bir sanallaştırma katmanı çalıştırır.
Temel katmanları şöyle düşünebilirsiniz:
- L0 – Fiziksel ana makine: Gerçek işlemci, RAM, disk ve ağ kartları burada bulunur. Ana hypervisor fiziksel donanım üzerinde çalışır.
- L1 – Nested için ayrılan sanal sunucu: Sanallaştırma uzantıları bu sanal makineye aktarılır. Buraya Proxmox VE, Hyper-V veya desteklenen başka bir hypervisor kurulabilir.
- L2 – İçte çalışan sanal makineler: L1 ortamında sizin oluşturduğunuz sanal sunuculardır. Örneğin üç Linux VM ve bir Windows test VM’si.
Burada önemli detay, L1 katmanının gerçekten sanal makine olmasıdır. “Nested dedicated server” adlı bir hizmetin sizi fiziksel kasanın tek müşterisi yapıp yapmadığı ancak sözleşme ve teknik mimariyle anlaşılır. Ürünün adında dedicated geçmesi, çıplak fiziksel donanım tahsisi verildiğini ispatlamaz.
Nested sunucu için neden özel destek gerekir?
Normal bir sanal makineye Proxmox kurmaya çalışmanız, içinde sorunsuz KVM VM’leri çalıştırabileceğiniz anlamına gelmez. Fiziksel işlemcideki Intel VT-x/EPT veya AMD-V/NPT gibi donanım sanallaştırma özelliklerinin uygun biçimde L1 sanal makineye expose edilmesi gerekir. Hypervisor zincirinde desteklenmeyen bir kombinasyon varsa ikinci seviyedeki VM açılmayabilir, aşırı yavaş çalışabilir veya beklenmedik ağ sorunları yaşayabilir.
Microsoft’un Hyper-V nested virtualization rehberi, bu özelliğin işlemci mimarisi, işletim sistemi sürümü ve sanal makine yapılandırmasına bağlı olduğunu açıkça belirtir. Dolayısıyla yalnızca “VT-x var” diye her nested senaryosunun desteklendiği sonucuna varılmamalıdır.
Nested yapıya örnek: Tek üst sunucuda beş laboratuvar VM’si
Bir sistem yöneticisinin aşağıdaki test ortamına ihtiyacı olduğunu düşünün:
| İç sanal makine | Test amacı | Örnek RAM tahsisi |
|---|---|---|
| VM-1 | Linux web sunucusu | 4 GB |
| VM-2 | PostgreSQL veritabanı | 8 GB |
| VM-3 | Windows Server test ortamı | 8 GB |
| VM-4 | Güvenlik ve ağ izleme | 4 GB |
| VM-5 | CI/CD runner | 4 GB |
| Toplam | L2 sanal makinelere ayrılan bellek | 28 GB |
Yalnızca VM’lere 28 GB bellek atamak yeterli değildir. Üst hypervisor’ın, dosya önbelleğinin, sanal ağ servislerinin ve yönetim ajanlarının da RAM’e ihtiyacı vardır. Bu yüzden örneğin 32 GB’lık bir nested ortam çok az hareket alanı bırakabilir; iş yüküne göre daha yüksek RAM ve depolama kapasitesi gerekebilir. Ayrıca eşzamanlı CPU kullanımını ve disk I/O yoğunluğunu ayrı hesaplamalısınız.
Unutmayın: İç içe daha çok VM kurabilmek, sınırsız performans elde etmek değildir. 10 sanal makinenin hepsi aynı anda 4 vCPU’yu tam kullanmak isterse işlemci zamanı yine fiziksel kapasiteyle sınırlandırılır.
Nested sunucu hangi işler için çok uygundur?
Sanallaştırma eğitimi ve laboratuvarları: Proxmox cluster mantığını öğrenmek, Windows etki alanı kurmak, güvenlik duvarı ve sanal ağ senaryolarını denemek, öğrenci başına ayrı VM oluşturmak için yararlı olabilir.
CI/CD ve otomatik test: Yazılımın farklı işletim sistemlerinde çalışmasını test etmek, VM şablonları üretmek ve otomatik kurulum süreçlerini doğrulamak için kullanılabilir. Ancak yoğun derleme veya performans testi sırasında iç içe sanallaştırmanın etkisi ayrıca ölçülmelidir.
Hosting otomasyonu geliştirme: VPS oluşturma, yeniden kurma, IP atama, snapshot alma ve müşteri paneli entegrasyonlarını gerçek müşterilerin bulunduğu üretim ortamına dokunmadan sınamak mümkündür.
Müşteri veya ekip izolasyonu: Küçük ekipler, her proje için ayrı L2 VM’ler açabilir. Fakat üretim ortamında müşterilere sunucu kiralayacaksanız performans, ağ izolasyonu, yedekleme, SLA ve lisans koşulları çok daha önemli hâle gelir.
Nested ortamın gizli maliyetleri ve riskleri
Performans ek yükü: İç katmandaki CPU planlama, bellek yönetimi, sanal disk ve ağ işlemleri ek yük oluşturabilir. Kayıp her sistemde sabit bir yüzde değildir; hypervisor kombinasyonu, cihaz geçişi ve iş yüküne göre değişir.
Ağ yapılandırması: İç VM’ler için bridge, NAT, routed subnet, ek IPv4/IPv6 adresleri, MAC spoofing ya da promiscuous mode benzeri ayarlar gerekebilir. Sağlayıcının ağı L2 sanallaştırma için uygun değilse VM çalışsa bile dış dünyaya sağlıklı çıkamayabilir.
Yedekleme zinciri: L0 üzerindeki bir snapshot, L1 içindeki bütün sistemlerin veritabanı tutarlılığını garanti etmez. L2 katmanındaki kritik uygulamalar için uygulama farkındalıklı yedek ve geri yükleme planı oluşturulmalıdır.
Lisans ve destek: Hypervisor ürün sürümleri, Windows lisansları, sanal işletim sistemi çalıştırma hakları ve ticari kullanım şartları birbirinden farklı olabilir. Teknik olarak açılabilen bir VM’nin lisans açısından uygunluğu ayrıca değerlendirilmelidir.
Tek hata alanı: L1 üst sunucu durursa, içindeki bütün L2 sistemler aynı anda etkilenir. Bir nested makinede çok sayıda VM bulunması kendi başına yüksek erişilebilirlik sağlamaz.
Nested mi, fiziksel hypervisor mı?
Deneme, eğitim, otomasyon geliştirme ve belirli küçük çoklu VM ihtiyaçları için nested çok esnektir. Sürekli yüksek yükte çalışan onlarca müşteri VM’si, özel ağ donanımı veya sıkı performans garantisi gerekiyorsa doğrudan fiziksel sunucuda hypervisor çalıştırmak çoğu zaman daha açık bir kapasite modeli sunar. Bununla birlikte iki yaklaşımın kesin üstünlüğünü iş yüküne özgü test belirler.
Örneğin nested sunucu seçenekleri incelenirken işlemci ve RAM miktarından önce tercih edilen Proxmox veya VMware sürümünün, ikinci seviye sanallaştırmanın ve ağ yapısının sağlayıcı tarafından doğrulanmasını istemek akıllıca olur.
Fiziksel Sunucu Nedir? Dedicated Server ve Bare Metal
Fiziksel sunucu, işlemci, RAM, disk ve ağ bileşenleriyle gerçek bir sunucu bilgisayarıdır. Dedicated server olarak kiralandığında donanım belirli bir müşterinin kullanımına tahsis edilir. Bare metal ifadesi genellikle doğrudan fiziksel donanıma erişim ve sanallaştırma katmanının zorunlu olmamasını vurgular. Günlük kullanımda dedicated ve bare metal çoğu zaman yakın anlamlarda kullanılsa da uzaktan kurulum, kiralama süresi, ağ ve yönetim modeli bakımından hizmet ayrıntıları değişebilir.
Fiziksel sunucu kiralamak demek, makinenin mutlaka yeni, aynı nesil ya da her zaman daha hızlı olacağı anlamına gelmez. Beş yıl önce üretilmiş çok çekirdekli bir işlemci, belirli bir tek çekirdek ağırlıklı işte güncel ve daha düşük çekirdekli bir işlemciden yavaş olabilir. Donanımın tam modelini görmek bu yüzden önemlidir.
Fiziksel sunucuda neleri kontrol edebilirsiniz?
Anlaşmanıza bağlı olarak tüm işlemci kapasitesini, RAM’i, diskleri, RAID/HBA denetleyicilerini, işletim sistemi kurulumunu ve hypervisor tercihlerini yönetebilirsiniz. Donanım üzerinde Proxmox VE, VMware ESXi, Hyper-V, Linux veya Windows Server çalıştırabilir; kendi sanal sunucularınızı oluşturabilirsiniz. IPMI/iDRAC/iLO gibi uzaktan yönetim araçları sağlayıcı tarafından erişime açılmış olabilir.
Ancak donanıma özel tahsis yapılması veri merkezinin ağ omurgasını, internet hattını veya elektrik altyapısını size özel kılmaz. Yönetilen fiziksel sunucu hizmetinde bazı ayarlar sağlayıcının operasyon politikasıyla sınırlandırılabilir.
Fiziksel sunucunun güçlü tarafları
- Başka bir müşterinin sanal makinesiyle aynı fiziksel CPU veya RAM havuzunu paylaşmama avantajı sağlar.
- Sürekli yüksek CPU yükü ve büyük bellek gereksinimlerinde kapasiteyi daha doğrudan planlamayı kolaylaştırır.
- Özel NVMe, RAID denetleyicisi, GPU, yüksek hızlı NIC ve benzeri donanımlara uygun seçenekler sunabilir.
- Lisans, güvenlik ve sistem politikaları izin verdiğinde özelleştirilmiş hypervisor mimarileri kurulabilir.
- Büyük ve istikrarlı iş yüklerinde birim kapasite maliyeti avantajlı olabilir.
Fiziksel sunucunun dezavantajları
Donanım arızası: Tek fiziksel sunucu bozulduğunda uygulama etkilenir. RAID disk arızalarına karşı belirli koruma sağlayabilir; ancak yedekleme değildir ve ana kart, ağ, güç, yazılım ya da veri silme risklerini ortadan kaldırmaz.
Kapasiteyi esnetme: 64 GB RAM’den 128 GB’a çıkmak fiziksel modül eklemeyi ve bakım penceresini gerektirebilir. Bulutta sık görülen anlık sanal kaynak değiştirme deneyimi her zaman bulunmaz.
Yönetim sorumluluğu: BIOS/firmware güncellemeleri, hypervisor güvenliği, sanal ağlar, yedekleme ve izleme süreçleri için uzmanlık gerekebilir. Yönetilen hizmet alıyorsanız kapsamı açıkça tanımlatın.
Tek makine riski: Dedicated olması, kendi başına HA anlamına gelmez. Kritik uygulamalar için ikinci sunucu, çoğaltılmış depolama, yük dengeleme ve felaket kurtarma mimarisi düşünülmelidir.
Fiziksel sunucu ne zaman gerçekten mantıklı?
Yıl boyunca yüksek CPU kullanımı, yüzlerce GB RAM ihtiyacı, özel GPU/PCIe kartları, lisans gereği donanım erişimi, büyük veritabanları, yoğun sanallaştırma kümeleri ve belirli veri yerleşimi gereksinimleri fiziksel sunucu lehine olabilir. Buna karşın yalnızca üç kurumsal web sitesi barındıracak bir işletmenin donanım yönetim yükünü üstlenmesi çoğu zaman gereksizdir.
Fiziksel sunucu ile kendi sunucunuzu veri merkezine koymak aynı şey mi?
Hayır. Sunucu kiralama (dedicated hosting) modelinde donanım genellikle sağlayıcıya aittir ve müşteriye tahsis edilir. Colocation (sunucu barındırma) modelinde donanım sizindir; veri merkezi kabin, enerji, soğutma, ağ bağlantısı ve seçilen ek hizmetleri sağlar. Donanım satın alma, arıza parçası bulundurma ve uzaktan müdahale sorumlulukları farklılaşabilir. Fiyat karşılaştırmasını buna göre yapın.
VPS, VDS, Bulut, Nested ve Fiziksel Sunucu Karşılaştırması
İlk bakışta “hangisi daha hızlı?” sorusu kolay görünür. Gerçekte hız, kullanılan teknoloji kadar işlemci nesline, RAM kapasitesine, disk gecikmesine, ağ performansına ve yönetim kalitesine bağlıdır. Aşağıdaki tabloda tipik kullanım eğilimlerini görebilirsiniz; sağlayıcının ürün şartnamesi her zaman daha belirleyicidir.
| Karar ölçütü | VPS | VDS | Bulut sunucu | Nested sunucu | Fiziksel sunucu |
|---|---|---|---|---|---|
| Çalışma biçimi | Sanal makine/konteyner tabanlı hizmet | Genelde sanal makine | Havuz/otomasyon üzerinden sunulan VM | L1 içinde L2 sanallaştırma | Doğrudan fiziksel donanım |
| Fiziksel CPU’nun tamamı | Genellikle hayır | Her zaman değil | Her zaman değil | Genellikle hayır | Kiralanan makinede evet |
| Kendi işletim sistemi | Ürüne göre | Genellikle evet | Genellikle evet | L1 ve L2’de evet | Evet |
| Kendi hypervisor’ını çalıştırma | Ayrı izin gerekebilir | Ayrı izin gerekebilir | Özel instance desteği gerekebilir | Temel kullanım amacı | Doğrudan kurulabilir |
| Kaynak büyütme | Sağlayıcıya bağlı | Sağlayıcıya bağlı | Genellikle daha çevik | L1 sınırına kadar | Donanım değişikliğine bağlı |
| Otomatik yüksek erişilebilirlik | Varsayılmaz | Varsayılmaz | Varsayılmaz, mümkün olabilir | Varsayılmaz | Varsayılmaz |
| Donanım seviyesinde kontrol | Sınırlı | Sınırlı | Sınırlı | L1’e tanınan haklarla sınırlı | Yüksek |
| Başlangıç operasyon yükü | Düşük–orta | Düşük–orta | Düşük–yüksek | Orta–yüksek | Orta–yüksek |
| Tipik kullanım | Site, API, test | Tutarlı VM yükü | Esnek ve otomasyonlu uygulamalar | Lab, sanallaştırma testi, çoklu VM | Yoğun sürekli yük, özel donanım |
Hangisi en iyi performansı verir?
Aynı donanım, aynı kaynak payı ve aynı iş yükünde fiziksel sunucunun doğrudan donanım erişimi bazı ek yükleri azaltabilir; fakat bu, bütün fiziksel sunucuların bütün bulut VM’lerinden hızlı olduğu anlamına gelmez. Güçlü bir güncel bulut VM’si, eski donanımlı dedicated sunucuyu geçebilir. Ayrıca veritabanı için düşük disk gecikmesi, tek çekirdek hızı ve RAM; video dönüştürme için toplam CPU/GPU kapasitesi; CDN ağırlıklı web sitesi için ağ ve cache katmanı daha belirleyicidir.
Hangisi daha güvenlidir?
Fiziksel izolasyon, bazı yan kanal ve çok kiracılı ortam risklerini azaltabilir; fakat yanlış yapılandırılmış bir fiziksel sunucu internete açık zayıf parola nedeniyle kolayca tehlikeye atılabilir. Güncel bir bulut VM ise iyi ağ segmentasyonu, MFA, patch yönetimi ve izleme ile güçlü güvenlik sunabilir. Güvenlik ürün adından değil, katmanlı kontrollerden çıkar.
Hangisi daha kolay yönetilir?
Kurulumu kolay olan ürün, yönetimi kolay ürün demek değildir. Bir bulut VM’si dakikalar içinde açılabilir ancak Linux güncellemeleri, veritabanı yedeği, güvenlik duvarı ve olay müdahalesi hâlâ sizin sorumluluğunuzda olabilir. Yönetilen hizmet ile yönetilmeyen hizmet arasındaki fark bazen VPS–dedicated farkından daha önemlidir.
Hangisi daha uzun ömürlü bir yatırım?
Sık değişen projeler için geçişi kolay, yedeklemesi düzenli, altyapı bağımlılığı düşük sistemler daha dayanıklıdır. Uzun ömür yalnızca fiziksel disklerin kalitesi değil; dokümantasyon, yedeklerden geri dönüş, güncelleme stratejisi ve çıkış planı gibi süreçlerin sonucudur.
Hangi Proje İçin Hangi Sunucu? 14 Gerçek Hayat Senaryosu
Sunucu seçimi en doğru biçimde kullanım senaryosuyla yapılır. Aşağıdaki örnekler tavsiye edilen başlangıç yaklaşımını gösterir; kesin RAM ve CPU rakamları, uygulamanın ölçülen tüketimine göre belirlenmelidir.
1. Yeni açılan kişisel blog veya tanıtım sitesi
Başlangıç önerisi: Paylaşımlı hosting yeterli olabilir; root erişimi veya özel servis gerekiyorsa küçük VPS. WordPress’in her zaman ayrı bir sunucuya ihtiyacı yoktur. İyi yapılandırılmış önbellek, CDN ve optimize edilmiş görseller küçük bir makineyi uzun süre yeterli kılabilir. Trafik zirvesi olmayan projede fiziksel sunucu kiralamak kaynak israfıdır.
Ne zaman büyütülmeli? PHP işçi süreçleri sürekli doluyor, RAM takası artıyor, veritabanı sorguları gecikiyor veya site düzenli trafik zirvelerinde yanıt veremiyorsa önce uygulama optimizasyonu, sonra kapasite artırımı düşünülmelidir.
2. Günlük düzenli ziyaretçi alan içerik sitesi
Başlangıç önerisi: Ölçümlere göre VPS, kaynak tahsisi açık bir VDS veya uygun bulut VM. Ziyaretçi sayısı tek başına kapasite belirlemez: Bir haber sayfası güçlü cache ile çok sayıda görüntülenme taşıyabilirken, eklentileri ağır bir WordPress yönetim paneli az kullanıcıyla bile yavaşlayabilir. PHP-FPM, OPcache, Redis, veritabanı indeksleri ve CDN çoğu zaman sunucu türünden önce incelenmelidir.
3. WooCommerce veya yoğun sipariş alan e-ticaret sitesi
Başlangıç önerisi: Veritabanı performansı güçlü, RAM sınırları açık ve güvenilir yedekleme sağlayan VDS veya bulut sunucu. Sepet, ödeme ve kullanıcı oturumu içeren sayfalar herkese aynı HTML’yi sunmadığından cache her şeyi çözmez. Sipariş kaybı toleransı düşükse ikinci uygulama düğümü, yönetilen veritabanı ve felaket kurtarma seçenekleri gündeme gelir.
Örnek: Günde 500 sipariş alan bir mağazanın Black Friday kampanyasında kısa sürede binlerce eşzamanlı isteğe çıkması mümkünse, yalnızca 8 vCPU’dan 16 vCPU’ya geçmek yerine yük testinde kuyruklar, ödeme servisleri, veritabanı bağlantı havuzu ve cache verimliliği gözlenmelidir. Gerçek talep tahmini olmadan kapasite uydurmak yanıltıcı olur.
4. CRM, ERP veya şirket içi iş uygulaması
Başlangıç önerisi: Sıkı erişim kontrolü ve düzenli yedekleme sağlayan VDS, bulut VM veya özel durumlarda fiziksel sunucu. Kullanıcı sayısı sınırlı olsa bile veri gizliliği, veritabanı tutarlılığı ve hizmet kesintisinin iş etkisi yüksek olabilir. Donanımdan önce erişim modeli, VPN, kimlik doğrulama, günlükleme ve RPO/RTO hedefleri netleştirilmelidir.
5. SaaS ürünü ve çok müşterili uygulama
Başlangıç önerisi: İlk aşamada tek bir iyi VM, büyürken bulutun otomasyon ve ağ olanakları. SaaS ekibinin ilk gün Kubernetes kümesi kurması şart değildir. Uygulama mimarisi ayrıştırıldığında veri tabanı, kuyruk, nesne depolama ve gözlemlenebilirlik ayrı servisler olarak gelişebilir. Önemli olan müşterilerin birbirinden uygulama seviyesinde de izole edilmesidir.
6. API, webhook ve arka plan işleyicileri
Başlangıç önerisi: Trafiğe ve çalışma desenine göre VPS/VDS veya bulut VM. Kısa ama keskin trafik patlamaları için kuyruk sistemleri, worker ölçekleme ve rate limiting yararlıdır. Çoğu API’nin darboğazı ham CPU’dan ziyade veritabanı, dış servis gecikmesi veya bağlantı havuzlarıdır. Bu nedenle ortalama CPU kullanımının düşük olması sistemi sorunsuz yapmaz.
7. Oyun sunucuları ve düşük gecikme isteyen işler
Başlangıç önerisi: İyi tek çekirdek performansı, kararlı CPU zamanı ve oyuncuya yakın lokasyon sunan VDS veya fiziksel sunucu; bazı yüklerde uygun bulut VM de olabilir. Oyun motoruna göre yüksek frekanslı işlemci, düşük ağ jitter’ı, doğru UDP yapılandırması ve DDoS korunması kritikleşir. 64 çekirdekli eski işlemci, tek çekirdeğe yüklenen bir oyun için beklenen avantajı sağlamayabilir.
8. Çok sayıda müşteri sitesi barındıran ajans
Başlangıç önerisi: Yönetim yetkinliğine göre VDS veya bulut VM üzerinde kontrol paneli; büyürse birden fazla node. Müşteri siteleri arasında kaynak sınırları, ayrı PHP kullanıcıları, düzenli yedek ve merkezi izleme kurmak gerekir. Tüm müşterileri tek sunucuda toplamak yönetimi kolaylaştırabilir ama aynı zamanda ortak hata noktası yaratır.
9. Hosting firması, reseller platformu veya sanal sunucu otomasyonu
Başlangıç önerisi: Geliştirme ve entegrasyon testleri için nested; ticari üretimde maliyet, ağ ve kapasite koşullarına göre doğrudan fiziksel hypervisor veya iyi tasarlanmış çok düğümlü altyapı. Bir müşteri panelinden otomatik VPS oluşturmayı test etmek ile onlarca müşteriye kesinti taahhüdü vermek bambaşka ölçeklerdir. IP havuzu, imaj yönetimi, abuse operasyonu, faturalama ve geri yükleme işin çekirdeğidir.
10. Proxmox, VMware veya Hyper-V laboratuvarı
Başlangıç önerisi: Nested virtualization desteği doğrulanmış nested sunucu. Eğitim ortamlarında birkaç farklı işletim sistemini aynı üst sunucu içinde açmak, ağ topolojileri denemek ve snapshot üzerinden tekrar başlamak ciddi kolaylık sağlar. Ancak kullanılan hypervisor ve sürüm kombinasyonunun destek durumunu sağlayıcıyla doğrulayın.
11. Büyük veritabanı, analitik veya arama indeksi
Başlangıç önerisi: IOPS ve latency gereksinimleri ölçülerek güçlü VDS, veri tabanı odaklı bulut VM veya fiziksel sunucu. PostgreSQL, MySQL, Elasticsearch/OpenSearch gibi ürünlerde RAM, disk gecikmesi, WAL/yazma deseni ve indeks boyutu performansı belirleyebilir. Sadece “NVMe var” ifadesi yeterli değildir; sürdürülebilir yazma hızını ve depolama sınırlamalarını sorun.
12. Yapay zekâ modeli, makine öğrenimi ve GPU iş yükü
Başlangıç önerisi: Uygulamanın gerçekten GPU isteyip istemediğine göre GPU sunucusu veya uygun GPU destekli bulut VM; CPU ile yapılan küçük inference işleri için klasik VM yeterli olabilir. GPU modeli, VRAM, CUDA/ROCm uyumluluğu, GPU paylaşım yöntemi ve veri aktarım maliyeti incelenmelidir. “AI projesi” etiketli her uygulama pahalı bir GPU gerektirmez.
13. Uzaktan masaüstü ve Windows iş uygulamaları
Başlangıç önerisi: Lisanslama ve eşzamanlı kullanıcı ihtiyacına göre VDS, bulut VM veya fiziksel sunucu. Windows Server ve Remote Desktop Services erişim lisansları, kullanıcı sayısı ve uygulamanın desteklediği sürümler maliyetin büyük bölümünü oluşturabilir. Yalnızca sanal sunucunun aylık fiyatına bakmak doğru değildir.
14. Yüksek erişilebilirlik isteyen kritik uygulama
Başlangıç önerisi: “En büyük tek sunucu” değil, birden fazla hata alanına yayılmış uygulama tasarımı. İki bağımsız uygulama düğümü, uygun veri replikasyonu, yük dengeleyici ve test edilmiş failover süreçleri gerekebilir. Bu tasarım bulut üzerinde de fiziksel sunucularla da oluşturulabilir. En pahalı donanımı tek bir noktaya koymak, tek hata noktasını yalnızca pahalılaştırır.
Karar özet tablosu
| Kullanım | İlk bakılacak seçenek | Belirleyici ölçüm |
|---|---|---|
| Kişisel site / blog | Paylaşımlı hosting veya VPS | TTFB, RAM, PHP worker |
| Trafiği artan kurumsal site | VPS / VDS / bulut VM | P95 yanıt süresi, CPU ve disk |
| E-ticaret | VDS / bulut VM | Sepet/ödeme akışı, DB gecikmesi |
| SaaS ve API | Bulut VM / VDS | Trafik patlaması, otomasyon ihtiyacı |
| Oyun sunucusu | VDS / fiziksel | Tek çekirdek, ping, jitter |
| Laboratuvar ve sanallaştırma testi | Nested | L2 desteği, RAM, ağ |
| Çok sayıda üretim VM’si | Fiziksel / küme mimarisi | Yoğunluk, kaynak garantisi, HA |
| Büyük veri tabanı | Güçlü VDS / fiziksel / özel bulut VM | Disk latency, IOPS, bellek |
| GPU yoğun iş | GPU’lu fiziksel / bulut | VRAM, GPU zamanı, yazılım uyumu |
CPU, RAM, Disk ve Ağ: Sunucu Seçiminde Gerçekten Ölçmeniz Gerekenler
CPU: Kaç çekirdek değil, nasıl çekirdek?
vCPU sayısı paralel çalıştırılabilecek iş miktarını etkiler; fakat tek iş parçacıklı uygulamalar için tek çekirdek performansı ve saat frekansı daha önemli olabilir. Ayrıca CPU’nun sanallaştırma katmanında ne kadar beklediğini gösteren steal time, ana makinenin aşırı yüklenmesine ilişkin fikir verebilir. Linux’ta top, vmstat, mpstat ve uygulamaya özgü profiler araçlarıyla gözlem yapabilirsiniz.
Örnek: Bir oyun sunucusu bir ana oyun döngüsünde yoğunlaşıyorsa 32 yavaş çekirdek yerine daha güçlü birkaç çekirdek avantajlı olabilir. Buna karşılık birbirinden bağımsız 40 video dönüştürme işini çalıştırıyorsanız toplam çekirdek sayısı ve sürdürülebilir güç tüketimi önem kazanır.
RAM: Bellek kapasitesinin yanında bellek davranışını inceleyin
RAM yetersiz kaldığında işletim sistemi dosya önbelleğini küçültebilir, swap kullanabilir veya süreçleri bellek baskısı nedeniyle sonlandırabilir. Veritabanlarında yeterli RAM, sık kullanılan verilerin diskten tekrar okunmasını azaltabilir. Ancak “ne kadar çok RAM, o kadar hızlı site” her zaman doğru değildir; uygulama zaten yeterli belleğe sahipse ek kapasite kullanılmadan kalır.
Sunucu planlarken işletim sistemi, yönetim paneli, veritabanı, PHP/Java/Node.js süreçleri, cache, izleme ajanları ve olası trafik pikleri için pay bırakın. Nested yapıda ayrıca L1 hypervisor ve L2 VM toplamlarını hesaba katın.
Disk: NVMe SSD neden her zaman aynı hızda değil?
NVMe, depolama aygıtlarının yüksek paralellik ve düşük gecikmeli erişim için kullandığı bir protokoldür. SATA SSD’ye göre önemli avantajlar sağlayabilir; ancak iki NVMe sunucu aynı performansı üretmeyebilir. Çünkü disk kontrolcüsü, NAND teknolojisi, RAID düzeni, dosya sistemi, paylaşılan depolama ağı, queue depth ve sağlayıcının I/O limitleri farklıdır.
Dört kavramı birbirinden ayırın:
- Kapasite (GB/TB): Ne kadar veri depolayabilirsiniz?
- IOPS: Saniyede kaç okuma/yazma işlemi tamamlanabilir?
- Throughput (MB/s): Saniyede kaç megabayt veri aktarılabilir?
- Latency (ms): Bir I/O işleminin cevaplanması ne kadar sürer?
Veritabanında küçük rastgele I/O ve gecikme önemliyken büyük medya dosyalarında sıralı aktarım hızı daha belirleyici olabilir. Paylaşımlı storage ile yerel NVMe de farklı dayanıklılık ve performans dengeleri sunar. Depolama seçerken uygulama benzeri testlerin 95. ve 99. yüzdelik gecikmelerine bakmak değerlidir.
Ağ: “1 Gbit port” ne anlama gelir?
Ağ portunun 1 Gbit/s olması, her an tek uygulamanın internete 1 Gbit/s net veri göndereceği anlamına gelmez. Hat paylaşımı, transit, peering, paket başına işlem kapasitesi, uzak kullanıcının internet erişimi ve TCP/UDP davranışı sonuçları etkiler. Ayrıca limitsiz trafik, bazı sağlayıcılarda adil kullanım veya kötüye kullanım kurallarıyla sınırlandırılabilir. Sözleşmede port hızı, garantili bant genişliği, aylık veri transferi, DDoS sınırları ve dışa veri aktarım ücretlerini ayrı ayrı sorgulayın.
Lokasyon: Türkiye’deki ağırlıklı bir kullanıcı kitlesi için İstanbul’da barındırma, pek çok durumda ağ gecikmesini azaltabilir. Fakat fiziksel yakınlık tek başına iyi routing garantisi değildir. Gerçek kullanıcı ağlarından ping, traceroute/MTR ve uygulama düzeyinde test yapmak daha güvenilir sonuç verir. Global kullanıcıları olan projeler için CDN, çok bölgeli mimari veya coğrafi önbellek daha önemli hâle gelebilir.
Doğru yük testi nasıl yapılır?
İki sunucuyu yalnızca boşta çalışan benchmark skorlarıyla kıyaslamayın. Önce aynı uygulama sürümünü, aynı veri kümesini ve aynı yazılım yapılandırmasını kurun. Ardından gerçek isteklere benzeyen test trafiği üretin. Ortalama yanıt süresini, p95/p99 gecikmelerini, hata oranını, CPU steal time’ı, disk kuyruk uzunluğunu ve ağ paket kayıplarını birlikte değerlendirin.
Örneğin bir API testinde “1000 istek/saniye” tek başına başarı değildir. İsteklerin yüzde 5’i birkaç saniye bekliyorsa kullanıcı deneyimi ve ödeme işlemleri olumsuz etkilenebilir. Yük testlerini üretim ortamını ve üçüncü taraf servisleri rahatsız etmeyecek izinli ortamlarda yürütün.
Güvenlik, Yedekleme ve Yüksek Erişilebilirlik: Beş Teknolojide de Ortak Kurallar
Bir sunucu alırken performans tabloları kadar önem verilmesi gereken üç konu vardır: veriyi korumak, hizmeti geri getirebilmek ve saldırı yüzeyini küçültmek. Bu kurallar VPS, VDS, bulut, nested ve fiziksel sunucuların tamamı için geçerlidir.
Sunucu kiralamak, yönetilen hizmet almak değildir
IaaS modelinde sağlayıcı çoğunlukla fiziksel tesis, donanım ve kendi sanallaştırma altyapısının belirli bölümlerinden sorumludur; müşteri ise işletim sistemi, uygulamalar, kullanıcı erişimi ve verinin korunmasından sorumlu olabilir. Hizmet sözleşmesi bu sorumlulukları değiştirebilir. Microsoft’un Azure IaaS güvenlik önerileri de sanal makine işletim sistemi güncellemelerinin müşteri tarafından yönetilmesi gerektiğini açıkça anlatır.
Yönetilmeyen bir sanal sunucu satın aldıysanız “Sunucuya virüs bulaştı, neden hizmet sağlayıcısı düzeltmedi?” sorusunun yanıtı, yönetim kapsamınızda saklı olabilir. Yönetilen pakette de hangi işletim sistemlerinin, panellerin, veritabanlarının, güvenlik olaylarının ve yedek geri yüklemelerinin desteklendiğini yazılı isteyin.
Uygulanabilir güvenlik kontrol listesi
- SSH’de parola yerine uygun yerde anahtar tabanlı kimlik doğrulama ve gerektiğinde MFA kullanın.
- Yönetim panellerini bütün internete açık bırakmayın; VPN, IP kısıtı veya güvenli erişim katmanı kullanın.
- İşletim sistemi, hypervisor, kontrol paneli ve uygulama güvenlik yamalarını planlı biçimde uygulayın.
- Gereksiz portları kapatın; ağ güvenlik duvarı ile sunucu içi güvenlik duvarını birlikte değerlendirin.
- Veritabanını ve iç servisleri zorunlu olmadıkça doğrudan internetten erişilebilir yapmayın.
- Yönetici hesaplarını kişiye özel tutun; en az yetki ilkesini uygulayın ve erişim kayıtlarını saklayın.
- Log, izleme ve uyarı sistemleri kurun; disk doluluğu kadar başarısız girişleri de izleyin.
- Yedekleri şifreleyin, ayrı erişim bilgileriyle koruyun ve periyodik geri yükleme testi yapın.
- API anahtarlarını uygulama koduna veya herkese açık Git depolarına koymayın.
- Sözleşmenizde veri yerleşimi, güvenlik olayı bildirimleri ve destek süreçlerini netleştirin.
Snapshot, yedekleme ve replikasyon arasındaki fark
Snapshot, sistemin belirli bir andaki durumunu kaydetmeye yönelik mekanizmadır. Bazı snapshot’lar aynı depolama sistemine bağımlıdır; snapshot zincirinin bozulması veya ana depolamanın kaybı geri dönüşü engelleyebilir. Snapshot çok kullanışlıdır ama tek başına bağımsız ve uzun süreli yedek sayılmamalıdır.
Yedekleme, verinin kopyasını belirlenmiş saklama ve geri dönüş hedefleriyle üretmektir. Uygulamaya özel yedekleme veritabanı tutarlılığı, işlem kayıtları ve yapılandırma dosyaları gibi unsurları kapsamalıdır. Yedeğin üretilebilmesi kadar geri yüklenebilmesi de önemlidir.
Replikasyon, verinin başka düğüme veya bölgeye çoğaltılmasıdır. Hizmet sürekliliğini artırabilir ancak yanlışlıkla silinen verinin veya fidye yazılımıyla şifrelenen dosyanın diğer kopyaya da taşınması mümkündür. Bu nedenle replikasyon da tek başına yedekleme değildir.
3-2-1 yaklaşımı: Kritik verinin üç kopyasını, iki farklı ortamı ve birini ayrı lokasyonda tutmayı hedefleyen yaygın bir prensiptir. Modern uygulamada çevrimdışı veya değiştirilemez (immutable) yedeklerin de planlanması, fidye yazılımı riskine karşı ek savunma sağlar. Her organizasyon aynı yedek saklama modeline ihtiyaç duymaz; işin kritikliği, mevzuat ve maliyet belirleyicidir.
RPO ve RTO: Kesintinin gerçek ölçüsü
RPO (Recovery Point Objective) kabul edilebilir veri kaybı süresini, RTO (Recovery Time Objective) hizmetin yeniden çalışmaya başlaması için kabul edilebilir süreyi ifade eder. Bu kavramlar AWS Well-Architected kurtarma hedefleri dokümanında da açıklanır.
Örnek: Bir içerik sitesinde son bir günlük taslakların kaybı tolere edilebilirken, ödeme yapan bir e-ticaret sitesinde son saatlik siparişlerin kaybı kabul edilemeyebilir. Birinci sistem günlük yedeklemeyi yeterli görebilir; ikinci sistem işlem günlüğü, daha sık yedek, farklı bir veritabanı çoğaltma stratejisi ve test edilmiş geri dönüş planına ihtiyaç duyabilir. Bunlar örnektir; gerçek hedefleri işletme belirlemelidir.
%99,9 SLA gerçekten ne demek?
Yüzdelik kullanılabilirlik beyanını tek başına okumayın. Hesap dönemi, planlı bakım istisnası, ağ/donanım kapsamı, hizmet kredisi ve ölçüm yöntemi önemlidir. Sadece matematiksel karşılıklarına bakılırsa 30 günlük bir dönemde %99,9 kullanılabilirlik yaklaşık 43,2 dakikalık, %99,99 ise yaklaşık 4,32 dakikalık kesinti bütçesine karşılık gelir. Bu rakamlar sözleşmenin gerçekten izin verdiği kesinti süresi değildir; SLA istisnaları ve hesaplama yöntemi farklı olabilir.
Bir başka ayrım da şudur: “%99,9 donanım kullanılabilirliği” taahhüdü, WordPress sayfanızın her zaman %99,9 başarıyla açılacağını garanti etmez. Uygulama, veritabanı, DNS, harici ödeme sağlayıcısı ve kullanıcı bağlantısı ayrı hata alanlarıdır.
DDoS koruması her tür saldırıyı durdurur mu?
Hayır. Ağ katmanındaki hacimsel DDoS saldırılarını filtreleyen hizmet, uygulama katmanındaki kötü niyetli HTTP isteklerini veya kimlik doğrulama saldırılarını aynı etkinlikte engellemeyebilir. Oyun sunucuları, API uç noktaları ve web siteleri farklı saldırı profillerine sahiptir. Koruma kapasitesi, TCP/UDP desteği, temiz trafik davranışı, kural yönetimi ve gerektiğinde WAF gibi ek katmanları ayrıca değerlendirin.
Sunucu Kiralama Maliyeti Nasıl Hesaplanır? Yalnızca Aylık Ücrete Bakmayın
Üç paketin fiyatını karşılaştırırken ilan edilen aylık kira bedeli ilk satırdır, toplam sahip olma veya kullanma maliyeti değil. Özellikle bulut altyapısında depolama, yedekleme, IP adresi, dışa veri transferi ve yönetilen hizmet gibi kalemler toplamı değiştirebilir. Fiziksel sunucuda ise yüksek kapasiteli donanımın yıllık maliyeti, bakım ve uzman personel süresi belirleyicidir.
Toplam maliyet formülü
Yaklaşık aylık toplam maliyet = Sunucu bedeli + yedekleme + ek disk/IP/ağ + lisans + güvenlik hizmetleri + yönetim/iş gücü + beklenen operasyonel ek giderler.
İş yükü için gerekli tüm özellikleri aynı koşullarda karşılaştırmadıkça “ayda 500 TL daha ucuz” iddiası anlamlı değildir. Ucuz pakette yedekleme bulunmaması, tek başına fiyat farkından daha önemli bir risk yaratabilir.
Örnek 1: Sabit trafikli küçük işletme sitesi
Bir şirketin sitesi günün çoğunda benzer seviyede trafik alıyor ve ekibin sunucu yönetimi sınırlı olsun. Bu durumda sabit fiyatlı VPS/VDS veya yönetilen hosting, karmaşık saatlik bulut faturalandırmasından daha öngörülebilir olabilir. Gereksiz CPU/RAM almak yerine yedekleme, izleme ve destek kapsamına bütçe ayrılması daha doğru olabilir.
Örnek 2: Kampanya zamanında büyüyen SaaS
Bir SaaS ürünü normal zamanlarda iki küçük uygulama düğümü kullanıyor ancak belirli kampanyalarda kısa süreli ek kapasiteye ihtiyaç duyuyor olsun. Altyapı otomasyonu ve uygulamanın yatay ölçeklenebilirliği hazırsa bulut üzerinde yalnızca yoğun dönemde ek kapasite açmak yararlı olabilir. Fakat sabit çalışan veritabanı, depolama ve ağ maliyetleri devam eder; ölçekleme sisteminiz kapanmayan gereksiz VM’ler bırakırsa fatura artar.
Örnek 3: Sürekli yüksek yükte çalışan platform
Her gün 24 saat yüksek CPU tüketen, bellek ihtiyacı öngörülebilir bir uygulama için kiralık fiziksel sunucu ya da özel kaynak tahsisli sanal hizmet avantajlı olabilir. Öte yandan tek fiziksel sunucunun arızası kabul edilemiyorsa yedek ikinci makine veya ek felaket kurtarma ortamı maliyete eklenmelidir. “Bir dedicated aldım, sorun bitti” hesabı eksiktir.
Gizli masraf kontrol listesi
| Masraf veya koşul | Mutlaka sorun |
|---|---|
| Yedekleme | Dahil mi, saklama süresi kaç gün, geri yükleme ücretli mi? |
| Snapshot | Kaç adet, hangi depoda, ne kadar süre korunuyor? |
| Dışa veri transferi | Gerçekten sınırsız mı, ek transfer veya egress bedeli var mı? |
| IPv4/IPv6 | Kaç IP dahil, ek IP şartları neler? |
| Lisans | Windows, RDS, kontrol paneli, hypervisor lisansları dahil mi? |
| Teknik destek | Yalnızca altyapı mı, işletim sistemi ve uygulama da mı? |
| Güvenlik | DDoS kapsamı, WAF, izleme ve olay müdahalesi dahil mi? |
| Kaynak değişimi | Yeniden başlatma veya hizmet kesintisi gerekiyor mu? |
| Sözleşme ve yenileme | Kampanyalı bedel sonrası fiyat ve iptal koşulu ne? |
| Taşıma | Başka sağlayıcıya veri çıkarma ve geçiş maliyeti ne? |
Doğru Sunucu Seçimi İçin Karar Matrisi ve 10 Adımlık Yol Haritası
Aşağıdaki karar dizisi, sağlayıcıların ürün adları değişse bile işe yarar:
Adım 1 – İş hedefini yazın. Bir web sitesi mi yayımlıyorsunuz, müşteri VM’leri mi oluşturacaksınız, veritabanı mı çalıştıracaksınız? İş yükünün fonksiyonu bilinmeden kaynak seçimi kör uçuş olur.
Adım 2 – Mevcut tüketimi ölçün. CPU kullanım eğrisi, RAM tepe değeri, disk gecikmesi, ağ aktarımı ve eşzamanlı oturumları inceleyin. Mevcut sistem yoksa küçük bir pilot kurarak yük testi yapın.
Adım 3 – Kesinti toleransını belirleyin. RTO, RPO ve hizmet kritikliğini iş birimleriyle netleştirin. Önemli bir uygulama için yedek makine ihtiyacı, ana sunucunun tipini değiştirebilir.
Adım 4 – Root ve donanım ihtiyacını kontrol edin. Sadece PHP sitesi yayımlayacaksanız root şart olmayabilir. Kendi hypervisor’ınızı çalıştırmak istiyorsanız nested destek veya fiziksel donanım gereksinimi vardır.
Adım 5 – Sanallaştırma katmanını doğrulayın. KVM, LXC, Hyper-V veya VMware kullanımının işletim sistemi, kernel, Docker ve nested gereksinimleriyle uyumlu olup olmadığını sorun.
Adım 6 – Performans garantisini yazılı isteyin. CPU tahsis modeli, RAM sınırı, disk IOPS/throughput, ağ portu ve olası fair-use politikaları belirsiz kalmasın.
Adım 7 – Büyüme planına bakın. Üç ay sonra trafik ikiye katlanırsa aynı makine büyütülebiliyor mu? Yatay ölçekleme için mimariniz elverişli mi? Disk küçültme ve veri taşıma sınırları neler?
Adım 8 – Yedek ve güvenliği tasarlayın. Yedek pakete dahil değilse ayrıca bütçelendirin. Başka lokasyona kopya alma, anahtar yönetimi ve geri yükleme testi planı hazırlayın.
Adım 9 – Toplam maliyeti karşılaştırın. Başlangıç fiyatı değil; kaynak, lisans, destek, veri transferi, yedek ve operasyon toplamıyla değerlendirin.
Adım 10 – Küçük başlatın, test edin, sonra büyütün. Pilot ortamda gerçek iş yükünü çalıştırın; yanıt süreleri ve hata oranı hedefleri karşılanıyorsa üretime geçin. Ölçüm olmadan çok büyük paket almak profesyonellik göstergesi değildir.
Hızlı seçim ağacı
- Sadece site yayınlayacağım ve sunucu yönetmeyeceğim: Önce yönetilen hosting veya uygun yönetilen sunucu çözümlerini değerlendirin.
- Root erişimi istiyorum, iş yüküm küçük veya orta: VPS ile başlayın; kaynak tahsisi beklentisi yüksekse VDS koşullarını kıyaslayın.
- Uygulamamın kaynakları zamanla veya aniden değişiyor, otomasyon istiyorum: Bulut altyapısını ve ilgili fatura modelini değerlendirin.
- Bir sunucunun içinde Proxmox/ESXi/Hyper-V ve çoklu VM açacağım: Doğrulanmış nested desteğini veya fiziksel hypervisor seçeneğini inceleyin.
- Sürekli yüksek yük, özel donanım veya doğrudan fiziksel kontrol istiyorum: Fiziksel sunucu maliyetini ve yedeklilik ihtiyacını karşılaştırın.
- Kesinti kabul edemiyorum: Öncelikle çok düğümlü uygulama mimarisi, ayrı hata alanları ve felaket kurtarma planı oluşturun; tek ürün adı çözüm değildir.
Sunucu değiştirme zamanı geldiğinde: Risksiz geçiş yaklaşımı
Yeni sunucuyu seçmek kadar mevcut sistemden geçmek de önemlidir. Önce envanter çıkarın: DNS kayıtları, TLS sertifikaları, uygulama sürümleri, PHP uzantıları, cron işler, e-posta servisleri, veritabanları, yükleme klasörleri ve dış API bağımlılıklarını listeleyin. Ardından yeni ortamı üretim verisinden güvenli kopyayla kurun ve alan adı değiştirmeden test edin.
Taşıma gününde veri yazma işlemlerini kontrol altına almak, son veritabanı eşitlemesini yapmak, DNS TTL’yi uygun zamanda düşürmek ve eski sistemi bir süre geri dönüş imkânı olarak tutmak işleri kolaylaştırır. Ancak DNS yayılımı anlık bir anahtar değildir; önbellek süresi değişebilir. E-ticaret gibi sürekli yazma yapılan sistemlerde veri tutarlılığı için bakım penceresi veya uygulamaya özel sıfıra yakın kesinti stratejisi gerekebilir.
Taşıma sonrası yalnızca sitenin açılmasını değil; ödeme, e-posta, cron, API, log, dosya izinleri, yedekleme ve izleme süreçlerini test edin. Yeni sunucu daha güçlü olsa bile yanlış yapılandırılmış PHP-FPM, veritabanı bağlantısı veya güvenlik kuralı tüm kazanımı silebilir.
Sık Sorulan Sorular: VPS, VDS, Bulut, Nested ve Fiziksel Sunucu
1. VPS mi daha iyi, VDS mi?
Tek başına biri her zaman daha iyi değildir. VDS terimi çoğu zaman daha belirgin kaynak tahsisini anlatmak için kullanılır; fakat evrensel bir teknik standart değildir. CPU tahsis politikası, disk performansı, yedekleme ve SLA aynıysa iki ürün arasında isimden kaynaklanan zorunlu performans farkı bulunmaz.
2. VPS ile VDS aynı şey mi?
Bazı sağlayıcılarda büyük ölçüde evet, bazılarında hayır. İkisi de fiziksel donanım üzerinde sanallaştırılmış sunucu olarak sunulabilir. Ayrımın gerçek olup olmadığı, işlemci ve RAM rezervasyonu, sanallaştırma modeli ve kaynak paylaşım şartlarından anlaşılır.
3. Bulut sunucu VPS midir?
Bir bulut sunucu teknik olarak sanal makine olabilir; bu açıdan VPS ile ortak teknolojiler kullanabilir. Ancak bulut kavramı kaynak havuzu, talep üzerine sağlama, otomasyon ve esneklik gibi işletim modeli özelliklerini de kapsar. Her bulut hizmeti aynı mimariyi sunmaz.
4. Bulut sunucu internet bağlantısı olmadan çalışır mı?
Sunucunun veri merkezi içinde çalışması için sizin bilgisayarınızın internete bağlı kalması gerekmez. Ancak uzaktan erişim, internet üzerinden hizmet sunma ve dış kaynaklarla haberleşme için ilgili ağ bağlantıları gereklidir. İnternet kesilirse sunucu çalışmaya devam etse bile kullanıcılar ona erişemeyebilir.
5. Bulut sunucu her zaman fiziksel sunucudan hızlı mı?
Hayır. Güncel işlemci, disk, ağ, kaynak tahsisi ve uygulamanın iş yüküne göre sonuç değişir. Çok iyi kaynaklandırılmış bir bulut VM’si eski fiziksel sunucudan hızlı olabileceği gibi, yoğun ve özel donanım gerektiren bir yükte fiziksel makine avantajlı olabilir.
6. Fiziksel sunucu daha mı güvenli?
Fiziksel ayrım bazı çok kiracılı ortam risklerini azaltabilir. Ancak işletim sistemi yaması, ağ segmentasyonu, erişim kontrolü ve yedekleme yapılmazsa fiziksel sunucu da savunmasızdır. Güvenlik, altyapı tipiyle birlikte operasyon kalitesine bağlıdır.
7. Nested sunucu fiziksel sunucu mudur?
Genellikle hayır. Nested sanallaştırmanın özü bir sanal makine içinde ikinci hypervisor çalıştırmaktır. Ürün adında “dedicated” geçmesi, fiziksel kasanın tamamının tahsis edildiğini kanıtlamaz. Satın almadan önce L0–L1 mimarisini ve fiziksel kaynak tahsisini sorun.
8. Nested sunucuya Proxmox kurulabilir mi?
Donanım sanallaştırma uzantıları L1 makineye doğru aktarılıyor, sürüm kombinasyonu ve ağ yapısı destekleniyorsa kurulabilir. Yalnızca Proxmox panelinin açılması yeterli test değildir; içine oluşturulan L2 sanal makinelerin de düzgün çalışması gerekir.
9. Nested sunucuda sınırsız sanal makine açabilir miyim?
Yazılımda belirli bir VM sayısı engeli olmaması, sınırsız kapasite olduğu anlamına gelmez. VM sayısı CPU, RAM, disk, IP, ağ ve lisans koşullarıyla sınırlandırılır. Her VM’nin kullanılabilir performansını koruyacak kapasite planı yapılmalıdır.
10. Nested virtualization Docker çalıştırmak için gerekli mi?
Çoğu standart Docker senaryosunda hayır. Docker konteynerleri Linux çekirdeği özellikleriyle çalışır; sanal makine içinde ayrı bir hypervisor açılmasını gerektirmez. Bazı özel konteyner, sanal makine destekli güvenlik veya geliştirme senaryoları farklı gereksinimlere sahip olabilir.
11. VPS’de Windows Server kurulur mu?
Sağlayıcının sanallaştırma platformu, imaj seçenekleri ve lisans modeli destekliyorsa evet. Windows sürümü, aktivasyon yöntemi ve gerekiyorsa RDS/CAL lisansları ayrıca doğrulanmalıdır.
12. 4 vCPU, dört fiziksel çekirdek midir?
Zorunlu olarak değil. vCPU, sanal makineye sunulan mantıksal işlemci birimidir. Bir fiziksel çekirdeğin veya mantıksal CPU’nun nasıl paylaştırıldığı sağlayıcının zamanlayıcı, pinning ve overcommit politikasına bağlıdır.
13. 8 GB RAM bütün WordPress siteleri için yeterli mi?
Hayır; bazı siteler için gereğinden fazla, bazıları için yetersiz olabilir. Tema, eklenti, PHP worker sayısı, eşzamanlı kullanıcı, cache, veritabanı ve panel tüketimi ölçülmelidir. Trafiğin niteliği, kaba ziyaretçi sayısından önemlidir.
14. NVMe disk mi, SSD mi daha iyi?
NVMe de genellikle SSD teknolojisini kullanır; bunlar birbirinin zıddı değildir. NVMe, cihazla iletişim için kullanılan protokolü tanımlar. Gerçek performans sürücü, kontrolcü, depolama katmanı ve IOPS/latency sınırlarına bağlıdır.
15. 1 Gbit/s port, saniyede 1 gigabayt aktarım demek mi?
Hayır. Gbit/s, saniye başına gigabit; GB/s ise gigabayt birimidir. Bir bayt sekiz bitten oluşur. Ayrıca portun teorik hızı, uygulamanın uçtan uca sürekli elde edeceği faydalı aktarım hızı değildir.
16. Bulut sunucu otomatik yedeklenir mi?
Ancak hizmetin yedekleme özelliği açıkça sunulmuş ve etkinleştirilmişse. Birçok üründe yedekleme ayrı ücrete tabidir. Snapshot, replikasyon ve bağımsız yedekleme birbirinin yerine geçmez; saklama ve geri dönüş koşulları kontrol edilmelidir.
17. Yüksek erişilebilirlik (HA) ile yedekleme aynı mı?
Hayır. HA, arıza anında hizmeti sürdürmeye veya hızlı geri getirmeye odaklanır. Yedekleme, verinin geçmiş bir sürümüne geri dönmeyi sağlar. HA kümesindeki yanlış veri silinmesi diğer düğümlere de yayılabilir; bu nedenle ikisi birlikte planlanmalıdır.
18. Sunucu lokasyonu SEO’yu doğrudan belirler mi?
Sunucu lokasyonu tek başına arama sıralamasını belirleyen sihirli bir ayar değildir. Kullanıcılara yakınlık, ağ gecikmesi ve sayfa deneyimi açısından yararlı olabilir; CDN, önbellek ve uygulama performansı da önemlidir. SEO için asıl hedef hızlı, erişilebilir ve yararlı bir sayfa sunmaktır.
19. 2026’da Google için mutlaka fiziksel veya bulut sunucu mu almalıyım?
Hayır. Google, içeriğin yararlılığı, dizine eklenebilirliği, erişilebilirliği ve sayfa deneyimi gibi etkenleri önemser; belirli bir sunucu ticari etiketini şart koşmaz. Sunucu seçimi kullanıcı deneyimini ve operasyonel istikrarı desteklemelidir.
20. SEO için sunucu performansı neden önemlidir?
Yavaş sunucu ve yanıt gecikmesi ziyaretçiyi etkileyebilir. Google’ın Core Web Vitals yaklaşımında sayfa yükleme, etkileşim yanıtı ve görsel kararlılık ölçülür. Ancak güçlü donanım, ağır JavaScript, optimize edilmemiş görseller veya hatalı veritabanı sorgularını tek başına düzeltmez.
21. Cloud sunucuda kaynak azaltınca faturam hemen düşer mi?
Fiyatlandırma modeline bağlıdır. Saatlik kullanım üzerinden ücretlenen sistemlerde değişiklik faturaya daha hızlı yansıyabilirken, aylık sabit paketlerde dönem veya sözleşme şartları geçerli olabilir. Bazı kaynaklar küçültülemez veya küçültme için taşıma gerekebilir.
22. Fiziksel sunucuda VPS satışı yapabilir miyim?
Uygun hypervisor, ağ ve IP planlaması, güvenlik, lisanslama ve sağlayıcı sözleşmesiyle teknik olarak mümkündür. Ancak sürdürülebilir ticari hizmet sunmak için merkezi yedekleme, izleme, otomatik kurulum, müşteri izolasyonu ve arıza yönetimi gerekir.
23. Bir fiziksel sunucuyu iki sunucuya bölmek performansı artırır mı?
Genellikle toplam fiziksel kapasiteyi artırmaz. Sanallaştırma kaynakları daha düzenli ayırabilir, farklı iş yüklerini izole edebilir ve yönetimi kolaylaştırabilir; fakat bölme işleminin kendisi yeni işlemci veya RAM yaratmaz. Üstelik bir miktar sanallaştırma yükü ekleyebilir.
24. Kendi sunucum için kaç CPU ve RAM seçmeliyim?
Önce uygulamanın tipik ve yoğun dönemlerdeki CPU, RAM, disk ve ağ kullanımını ölçün. Ardından operasyonel pay ve büyüme payı ekleyin. Sayısal kapasiteyi, uygulamanın gerçek ölçümleri olmadan yalnızca kullanıcı sayısından tahmin etmek yanıltıcıdır.
25. Hangi sunucu türü en ekonomik?
Hafif yükte paylaşımlı hosting veya VPS genellikle ekonomik başlayabilir. Sürekli yüksek yükte fiziksel sunucu ya da ayrılmış kaynaklı sanal hizmet birim maliyet avantajı sunabilir. Değişken trafik ve otomasyonda bulut modelinin esnekliği toplam maliyeti düşürebilir. En doğru cevap iş yükünün yıllık maliyet modelinden çıkar.
Sonuç: En İyi Sunucu Değil, İhtiyacınıza En Uygun Mimari Vardır
VPS, VDS, bulut sunucu, nested sanallaştırma ve fiziksel sunucunun her biri doğru ihtiyaç için değerli araçlardır. VPS, kolay ve ekonomik başlangıç sunabilir. VDS olarak konumlanan hizmetler, kaynak tahsisi daha açık sözleşmeyle sunuluyorsa tutarlı performans isteyen projelere hitap edebilir. Bulut sunucu hızlı sağlama, otomasyon ve ölçekleme potansiyeli sağlar; ancak HA ve yedekleme ayrı doğrulanmalıdır. Nested, bir sanal sunucunun içinde kendi sanallaştırma laboratuvarınızı kurmanıza imkân tanır. Fiziksel sunucuysa donanım kontrolü, özel bileşenler ve sürdürülebilir yüksek yüklerde güçlü bir seçenektir.
Seçimi şu sırayla yapın: İş yükünü tanımlayın, ölçün, riskleri belirleyin, kaynak paylaşımını öğrenin, yedeklemeyi planlayın ve ancak sonra fiyat karşılaştırın. Bu yaklaşım sizi yalnızca gereksiz aylık harcamadan değil, yanlış mimarinin yol açabileceği performans ve veri kaybı sorunlarından da korur.
Bir satıcının “en hızlı”, “sıfır kesinti”, “sınırsız kaynak” gibi iddialarına karşı sorulacak en iyi soru şudur: “Bunu hangi teknik özellik, ölçüm ve sözleşme maddesiyle doğrulayabiliyorum?” Doğru sunucu seçimi tam da bu soruyla başlar.
Teknik Kaynaklar ve İleri Okuma
Bu rehberin teknik çerçevesi aşağıdaki birincil kaynakların kavramlarıyla karşılaştırılarak hazırlanmıştır. Belirli sağlayıcı hizmetlerinin güncel fiyatları veya performansları için ayrıca o hizmetin sözleşmesini ve teknik dokümantasyonunu inceleyin.
- NIST SP 800-145 – The NIST Definition of Cloud Computing: Bulut hizmetinin temel karakteristikleri ve servis modelleri.
- Microsoft Learn – Enable Nested Virtualization: Nested sanallaştırma için işlemci ve konfigürasyon gereksinimleri.
- Google Cloud – About Host Events: Bulut VM’lerinde canlı taşıma, bakım ve yeniden başlatma davranışları.
- AWS Well-Architected – Recovery Objectives: RTO ve RPO tanımları.
- Microsoft Learn – IaaS Security Best Practices: Sanal sunucularda güvenlik ve işletim sistemi sorumlulukları.
- Google Search Central – Helpful, Reliable, People-First Content: Yararlı içerik ve güvenilirlik ilkeleri.
Editoryal not: Kaynak tahsisi, yedekleme, yüksek erişilebilirlik ve fiyatlandırma uygulamaları sağlayıcıya ve pakete göre farklılaşır. Bu rehber belirli bir satın alma taahhüdü değil, teknik seçim çerçevesidir.
