Reseller hosting paket ve kaynak planlama

Bu rehberde ne yapacağız?

Reseller hosting işinde en sık yapılan hata, fiziksel sunucunun gerçek kapasitesini düşünmeden paket sayısını artırmaktır. Bu rehberde bir reseller hosting paketini kaynak açısından nasıl planlayacağınızı, aşırı satış (overselling) riskini nasıl ölçeceğinizi, hesap başına limitleri nasıl tanımlayacağınızı ve kullanımı nasıl izleyeceğinizi adım adım ele alıyoruz.

Rehber, bayilik paketleri sunan hosting sağlayıcılarına ve kendi sunucusunda müşteri barındıran sistem yöneticilerine hitap eder. Planlama tablosunu hazırlamak ve izleme komutlarını denemek yaklaşık 45-60 dakika sürer. Komutlar Debian/Ubuntu ve RHEL tabanlı (AlmaLinux, Rocky) sistemlerde çalışır; kontrol paneli menüleri ürüne göre değiştiği için panel ayarları genel düzeyde anlatılmıştır.

Gereksinimler

• Bayi hesaplarının barındırıldığı bir Linux sunucu (sanal veya fiziksel) ve sudo yetkili kullanıcı
• Sunucunun toplam CPU çekirdeği, RAM, disk ve disk türü (SSD/NVMe/HDD) bilgisi
• Mevcut müşteri sayısı ve paket başına ortalama kullanım verisi (yoksa tahmini değerler)
• Zaman serisi izleme için sysstat paketi veya mevcut bir izleme aracı

Adım adım reseller hosting kaynak planlama

1. Gerçek kapasiteyi belirleyin

Önce sunucunun işletim sistemi ve temel servisler için ayırdığınız payı düşünün. Toplam kapasitenin tamamını satılabilir kabul etmeyin; genel kural olarak RAM ve CPU'nun yaklaşık beşte birini sistem, veritabanı, posta ve yedekleme gibi arka plan işlerine ayırmak sağlıklıdır. Disk için ise yedek alanını ve büyüme payını ayrıca hesaba katın.

nproc
free -h
df -h
lsblk -d -o NAME,ROTA,SIZE,MODEL

lsblk çıktısındaki ROTA sütunu 0 ise disk SSD/NVMe, 1 ise dönen disktir. Dönen disklerde G/Ç (I/O) en önce tükenen kaynaktır; paket limitlerini buna göre daha sıkı tutun.

2. Paketleri tanımlayın ve aşırı satış oranını hesaplayın

Aşırı satış, satılan toplam kaynağın fiziksel kapasiteyi aşmasıdır ve çoğu hosting modelinde bilinçli bir tercihtir; çünkü müşterilerin büyük çoğunluğu paketlerinin küçük bir kısmını kullanır. Risk, oranı ölçmeden artırmaktan doğar. Önerilen yöntem: satılan kaynak toplamını, gerçekte kullanılan kaynak toplamına bölerek bir kullanım oranı bulmaktır.

• Disk: satılan kota toplamı / gerçek kullanım toplamı. Disk aşırı satışı en zararsız olanıdır ama doluluk %80'i geçmeden genişleme planlanmalıdır.
• RAM ve CPU: satılan değil, aynı anda çalışan en yüksek talep (pik) esas alınır. Hesap başına limit koyamıyorsanız aşırı satıştan kaçının.
• Posta ve veritabanı: saatlik gönderim limitleri ve eş zamanlı bağlantı limitleri ayrı planlanır.

Basit bir planlama örneği: sunucuda 16 çekirdek ve 64 GB RAM varsa, sistem payı sonrası yaklaşık 12 çekirdek ve 48 GB RAM satılabilir kapasitedir. Hesap başına 1 çekirdek ve 1 GB RAM limiti verip hesapların en fazla %25'inin aynı anda yoğun çalışacağını varsayarsanız, teorik olarak 48 / 1 / 0,25 = 192 hesaba kadar çıkabilirsiniz; ancak ilk aşamada bunun yarısıyla başlayıp izleme verisine göre artırmak daha güvenlidir.

3. Hesap başına limitleri uygulayın

Limit uygulamasının yolu kullandığınız panele ve kernel katmanına bağlıdır. Panelinizde veya CloudLinux benzeri bir kaynak yalıtım katmanında hesap bazlı CPU, RAM, işlem sayısı ve G/Ç limiti tanımlayabiliyorsanız önce bunu kullanın. Böyle bir katman yoksa, systemd ile kullanıcı dilimi (slice) başına sınır koymak mümkündür.

id hesapkullanici
sudo systemctl set-property user-1001.slice CPUQuota=100% MemoryMax=1G TasksMax=300
systemctl show user-1001.slice -p CPUQuotaPerSecUSec -p MemoryMax -p TasksMax

Burada 1001, id çıktısındaki kullanıcı kimliğidir. Bu yöntem yalnızca o kullanıcının systemd oturumuna bağlı süreçleri kapsar; web sunucusu havuzları (PHP-FPM) ayrı kullanıcılarla çalışıyorsa her havuz için ayrı kısıt gerekir. Havuz bazlı sınırlama için PHP-FPM havuz dosyalarında pm.max_children ve request_terminate_timeout değerlerini de bayi paketine göre belirleyin.

4. Disk ve inode kotalarını belirleyin

Disk kotası kadar inode (dosya sayısı) sınırı da önemlidir; milyonlarca küçük dosya yedeklemeyi ve dosya sistemi performansını bozar. Kota desteği dosya sisteminde açık olmalıdır.

mount | grep -E 'usrquota|usrjquota|prjquota'
df -i /home
sudo repquota -s /home

Her paket için disk kotasının yanında bir inode üst sınırı tanımlayın. Örneğin 10 GB diske karşılık 250 bin inode makul bir başlangıç değeridir; müşteri gerekçe sunarsa artırılır.

5. İzleme altyapısını kurun

Sistem düzeyinde geçmiş veri toplamak için sysstat paketini kurun.

# Debian / Ubuntu
sudo apt install sysstat
sudo systemctl enable --now sysstat

# AlmaLinux / Rocky
sudo dnf install sysstat
sudo systemctl enable --now sysstat

Anlık durumu görmek için aşağıdaki komutlar işinize yarar. Üçüncü komut, kullanıcı başına toplam CPU yüzdesini ve RAM kullanımını (MB) sıralar.

uptime
vmstat 5 5
ps -eo user=,pcpu=,rss= | awk '{c[$1]+=$2; m[$1]+=$3} END {for (u in c) print u, c[u], int(m[u]/1024)}' | sort -k2 -nr | head -15

Geçmiş veri için sar -u (CPU), sar -r (bellek) ve sar -d (disk) komutlarını kullanabilirsiniz. Disk G/Ç baskısını iostat -x 5 3 çıktısındaki %util ve await değerlerinden izleyin.

6. Eşik değerleri ve uyarı kuralları belirleyin

Bir sunucuyu ne zaman yeni müşteriye kapatacağınızı önceden yazılı hale getirin. Örnek eşikler: 15 dakikalık yük ortalaması çekirdek sayısının 0,7 katını sürekli aşıyorsa, RAM'de swap kullanımı sürekli artıyorsa, disk doluluğu %80'e ulaşırsa veya G/Ç bekleme süresi uzun süre yüksekse yeni hesap açılışı durdurulur ve kapasite artırma süreci başlar.

swapon --show
free -m | awk 'NR==2 {printf "RAM kullanim: %d%%\n", $3*100/$2}'
df -h --output=target,pcent | sort -k2 -nr | head

Doğrulama

Planlamanın çalıştığını iki yerden doğrulayın. Birincisi, uyguladığınız systemd sınırının gerçekten tanımlı olduğunu kontrol edin.

systemctl show user-1001.slice -p CPUQuotaPerSecUSec -p MemoryMax -p TasksMax

Beklenen sonuç: tanımladığınız MemoryMax ve TasksMax değerlerinin sayısal olarak listelenmesidir (sınırsız ise infinity görünür). İkincisi, sysstat verisinin toplandığını doğrulayın.

sar -u 1 3
ls /var/log/sysstat /var/log/sa 2>/dev/null | head

Beklenen sonuç: sar komutunun CPU yüzdelerini yazdırması ve günlük veri dosyalarının oluşmaya başlamasıdır. Bir hafta sonra pik saatlerdeki değerleri planlama tablonuzla karşılaştırın.

Sık karşılaşılan sorunlar

• Belirti: Gün içinde sunucu yavaşlıyor ama hiçbir hesap limitini aşmıyor. Çözüm: Limitler tek tek makul olsa bile toplam talep kapasiteyi aşıyor olabilir; pik saat verisiyle aşırı satış oranını yeniden hesaplayın.
• Belirti: systemd sınırı koyduğum halde kullanıcı süreçleri sınırı aşıyor. Çözüm: Süreçler başka bir slice veya hizmet altında çalışıyordur; PHP-FPM gibi hizmetlerin ayrı havuz ve hizmet sınırlarını kontrol edin.
• Belirti: Disk boş görünüyor ama yeni dosya oluşturulamıyor. Çözüm: Inode tükenmiş olabilir; df -i ile kontrol edin ve gereksiz küçük dosya birikimini (oturum, önbellek) temizletin.
• Belirti: Bellek sınırına takılan süreçler aniden sonlanıyor. Çözüm: Çekirdek günlüğünde (sudo journalctl -k | grep -i oom) bellek yetersizliği kaydını arayın ve hesabın paketini gözden geçirin.

Güvenlik ve bakım notları

• Limitler aynı zamanda bir güvenlik önlemidir: ele geçirilmiş tek bir hesabın sunucudaki diğer müşterileri etkilemesini sınırlar.
• Her hesabı ayrı sistem kullanıcısı ve ayrı PHP-FPM havuzu ile çalıştırın; hesaplar arası dosya erişimini dosya izinleriyle kapatın.
• Planlama tablonuzu üç ayda bir gerçek kullanım verisiyle güncelleyin; müşteri profili değiştikçe aşırı satış oranı da değişir.
• Yedekleme alanını ve yedekleme sırasında oluşan G/Ç yükünü kapasite hesabına dahil edin.
• Limit değişikliklerini ve istisnaları tarihiyle birlikte not edin; müşteri şikayeti geldiğinde izlenebilirlik sağlar.
• İzleme verisini sadece yöneticilerin okuyabildiği bir yerde tutun; kullanıcı bazlı kullanım bilgisi kişisel veri sayılabilir.