VDS Bayiliği Nasıl Yapılır? Havuz Bazlı Cloud Bayilik Rehberi

VDS bayiliği, bir altyapı sağlayıcısından aldığın sanal sunucu kaynaklarını kendi markan ve kendi fiyatlandırmanla müşterilerine satma modelidir. Havuz bazlı cloud bayilikte sabit paketler almak yerine vCPU, RAM ve disk gibi kaynakları bir havuz olarak edinir, bu havuzdan istediğin boyutta sanal makineler (VM) oluşturursun. Bu rehberde modelin nasıl çalıştığını, havuzu nasıl planlayacağını, müşterine VM açarken izleyeceğin adımları, konsol/ISO/yedek yönetimini ve sürdürülebilir bir iş modelinin nasıl kurulacağını bulacaksın.

Bayilik modelleri: havuz bazlı mı, komisyonlu mu?

Piyasada iki ana yaklaşım var ve çoğu zaman karıştırılıyor:

Havuz modelinde marjın ve esnekliğin yüksektir ama müşteri desteği, faturalama ve abuse yönetimi sende kalır. Komisyon modelinde operasyon yükün düşüktür ama müşteri ilişkisinin ve fiyatın kontrolü sağlayıcıdadır. İkisini birleştirmek de mümkündür: kendi yönettiğin müşterilere havuzdan, yönetmek istemediğin büyük talepleri komisyonla yönlendirebilirsin. Güncel program koşulları için Nixcon cloud bayilik sayfasına bakabilir veya satış ekibiyle konuşabilirsin; bu yazı koşulları değil, çalışma mantığını anlatıyor.

Adım 1: Havuzu müşteri profiline göre planla

Havuz bazlı modelin en kritik hatası, havuzu "ne kadar büyükse o kadar iyi" diye almaktır. Önce hedef müşteri profilini yaz:

• Web/WordPress barındırma: 1-2 vCPU, 2-4 GB RAM, küçük disk
• Oyun sunucusu (Minecraft, FiveM vb.): yüksek tek çekirdek performansı, 4-16 GB RAM
• Uygulama/API sunucusu: 2-4 vCPU, 4-8 GB RAM
• Veritabanı / depolama ağırlıklı: RAM ve disk öncelikli

Ardından basit bir kapasite formülü kullan:

Toplam talep = Σ (paket_adedi × paket_kaynağı)
Havuz ihtiyacı = Toplam talep + güvenlik payı (öneri: %15-20)

Güvenlik payı, ani müşteri artışı ve geçici ihtiyaçlar (ISO'dan kurulum, test VM'i, geri yükleme) için gerekir. Kaynakları fazla taahhüt etmek (overcommit) kısa vadede marjı artırır, ama özellikle RAM ve disk I/O'da müşteri şikâyetine dönüşür. Havuzdaki sınırların ve genişletme şeklinin nasıl işlediğini satın almadan önce netleştir.

Adım 2: Paket ve ürün yapısını tasarla

Havuzdan sınırsız kombinasyon çıkarabilirsin, ama müşteriye 3-5 net paket sunmak hem satışı hem desteği kolaylaştırır:

1. Başlangıç: tek proje, düşük kaynak
2. Standart: çoğu müşterinin ineceği orta paket
3. Performans: yüksek RAM/CPU
4. Özel: müşterinin istediği kombinasyon, ayrı fiyatlanır

Ek hizmetleri (ek IP, yedekleme, yönetilen kurulum, izleme) paketin içine gömmek yerine ayrı kalem yap. Marjın büyük kısmı çoğunlukla bu ek hizmetlerden gelir. Kendi ASN'i ve IP bloğu olan müşterilerin için BGP destekli seçenekleri de VDS hizmet sayfasından inceleyip katalogna ekleyebilirsin.

Adım 3: Müşteriye VM açma akışı

Her müşteri için aynı akışı izlemek hataları azaltır:

1. Siparişi ve ödemeyi doğrula.
2. Havuzda yeterli boş kaynak olduğunu kontrol et.
3. VM'i paket boyutlarında oluştur; işletim sistemini şablondan veya ISO'dan kur.
4. IP, hostname ve root/yönetici erişimini ayarla.
5. Erişim bilgilerini güvenli kanaldan ilet (düz e-posta ile parola göndermek yerine ilk girişte değiştirmeyi zorunlu kıl).
6. Müşteriyi izleme ve yedek listesine ekle.

Şablon (template) hazırlığı

Tekrarlanan kurulumları şablonla hızlandır. Linux şablonunu kapatmadan önce şunları yap:

# VMware araçları (Debian/Ubuntu)
apt update && apt install -y open-vm-tools
systemctl enable --now open-vm-tools

# RHEL / AlmaLinux / Rocky
dnf install -y open-vm-tools
systemctl enable --now vmtoolsd

# Şablon temizliği
cloud-init clean --logs 2>/dev/null || true
truncate -s 0 /etc/machine-id
rm -f /etc/ssh/ssh_host_*
history -c

Not: SSH host anahtarlarını sildiysen ilk açılışta yeniden üretilmesini sağlaman gerekir. Debian'da bu dpkg-reconfigure openssh-server ile, cloud-init kullanan imajlarda ise otomatik olur. /etc/machine-id boşaltılmazsa klonlanan VM'ler aynı kimliği paylaşır; DHCP ve bazı izleme araçlarında çakışma yaratır.

Temel sertleştirme

Şablona şu varsayılanları koy:

# SSH: parola yerine anahtar
sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
systemctl reload sshd

# Güvenlik duvarı (Ubuntu örneği)
ufw default deny incoming
ufw allow 22/tcp
ufw enable

Müşteri parola ile girmek isterse bunu bilinçli bir tercih olarak açtır; varsayılan güvenli olsun. Zayıf parolalı VM'ler, bayinin başına en çok abuse şikâyeti getiren kalemdir.

Adım 4: Konsol, ISO ve yedek yönetimi

Konsol erişimi

SSH/RDP'ye ulaşılamadığında (yanlış güvenlik duvarı kuralı, bozuk ağ yapılandırması) müşterinin tek çaresi sanal konsoldur. Bayi panelinden konsol erişiminin nasıl verildiğini test et ve müşteri dokümanına şunları ekle:

• Konsola nasıl girilir
• Ağ ayarı bozulduğunda hangi dosyalar kontrol edilir (/etc/netplan/, /etc/network/interfaces)
• Konsol oturumu için kullanıcı/parola kurtarma adımı

ISO yönetimi

Müşteri kendi işletim sistemini kurmak isteyebilir. Kaynak güvenilirliği için ISO'ları her zaman resmi sitelerden indir ve sağlamasını yap:

sha256sum -c SHA256SUMS --ignore-missing

Resmi imza dosyası varsa GPG doğrulamasını da ekle. Müşterinin yüklediği özel ISO'ları ayrı bir kategoride tut ve kurulum sonrası ISO'yu sanal sürücüden çıkar; aksi halde VM yeniden başlatıldığında tekrar kuruluma düşebilir.

Yedekleme

Önemli ayrım: anlık görüntü (snapshot) yedek değildir. Snapshot aynı depolama üzerinde durur ve değişiklik biriktikçe performansı düşürür. Gerçek yedek, farklı bir konumda tutulan, geri yükleme testi yapılmış kopyadır. Panelde yedek özelliği varsa kapsamını (ne sıklıkla, kaç kopya, nereye) net öğren; yoksa VM içinde dosya bazlı yedek ile desteklersin. Örnek restic akışı:

export RESTIC_REPOSITORY="sftp:backup@198.51.100.20:/srv/restic/musteri01"
export RESTIC_PASSWORD_FILE=/root/.restic-pass

restic init
restic backup /etc /var/www /var/lib/mysql-dumps
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 3 --prune
restic check

Bunu cron veya systemd timer ile günlük çalıştır. Ayda bir rastgele bir müşteri için geri yükleme testi yap; test edilmemiş yedek, yedek sayılmaz.

Adım 5: Sürdürülebilir iş modeli

Teknik kısım çözüldüğünde işin gerçek zorluğu operasyondur. Dikkat edeceğin kalemler:

• Maliyet yapısı: havuz maliyeti + lisans (Windows vb.) + faturalama/panel aracı + destek emeği. Fiyatı yalnızca "havuz maliyeti × çarpan" ile değil, destek saatini de katarak belirle.
• Marj: ek hizmetlerde (yedek, yönetilen kurulum, izleme) daha yüksek, çıplak VM'de rekabetçi tut.
• Destek seviyesi: "yönetilmeyen" (unmanaged) VDS ile "yönetilen" hizmeti ayır. Hangi sorunun senin, hangisinin müşterinin sorumluluğunda olduğunu sözleşmede yaz.
• Abuse ve kötüye kullanım: kabul edilebilir kullanım politikası (AUP) hazırla; spam, tarama ve saldırı trafiğine karşı müdahale süreni tanımla.
• Saldırı koruması: oyun ve web müşterileri DDoS'a açıktır. Altyapı tarafındaki DDoS koruma ve firewall seçeneklerini paketlerine nasıl yansıtabileceğini önceden planla.
• Nakit akışı: sağlayıcıya aylık ödüyorsan müşteriden de peşin veya dönem başı tahsil et.

Yaygın hatalar ve çözümleri

Başlamadan önce kontrol listesi

• [ ] Hedef müşteri profili ve 3-5 paket tanımlı
• [ ] Havuz boyutu güvenlik payıyla hesaplandı
• [ ] Şablonlar (en az bir Linux, gerekirse Windows) hazır ve test edildi
• [ ] Konsol, ISO ve yedek akışı denendi
• [ ] AUP, hizmet şartları ve destek kanalları yazıldı
• [ ] Faturalama ve müşteri bildirim süreci hazır

Sonuç

VDS bayiliği, doğru planlandığında altyapı yönetmeden kendi markanla büyüyebileceğin bir iş modelidir. Havuzu müşteri profiline göre boyutlandır, VM açma akışını şablonlarla standartlaştır, konsol/ISO/yedek süreçlerini baştan kur ve sorumluluk sınırlarını yaz. Nixcon kendi ağını (AS40368) işlettiği için bayilik tarafında altyapı kararlarını tek sağlayıcıyla netleştirebilirsin; seçenekleri ve program koşullarını cloud bayilik sayfasından inceleyebilirsin.