CloudLinux LVE Nedir? Paylaşımlı Sunucuda Kaynak Limitleri

Paylaşımlı hosting işletenlerin hepsinin bildiği bir arıza tipi var: bir müşterinin WordPress'i eklenti güncellemesinden sonra her istekte 400 MB RAM yemeye başlar ve aynı sunucudaki diğer 300 hesap onunla birlikte sürünür. CloudLinux'un tek bir varlık sebebi var: bunu sunucu problemi olmaktan çıkarıp tek hesabın problemi hâline getirmek.

Bu yazı LVE'nin ne olduğunu, hangi limitin ne zaman devreye girdiğini, 508 hatasının gerçekte ne söylediğini ve CageFS / PHP Selector / MySQL Governor üçlüsünün nereye oturduğunu anlatıyor.

LVE tam olarak nedir

LVE (Lightweight Virtual Environment), hesap başına bir tane oluşturulan, çekirdek seviyesinde bir ölçüm ve kısıtlama katmanıdır. Sanal makine değildir, chroot değildir; süreçleri sayan, CPU'yu bölen ve limit dolduğunda işi ya yavaşlatan ya da reddeden bir sarmalayıcıdır.

Her LVE'nin ID'si hesabın UID'idir. Anlık durumu cat /proc/lve/list ile görürsün; limitler /etc/container/ve.cfg dosyasında tutulur.

İsteği doğru LVE'nin içine yerleştiren şey web sunucusu tarafındaki bileşendir: Apache'de mod_hostinglimits, LiteSpeed'de sunucunun kendi yerleşik CloudLinux desteği. PHP çalışmaya başlamadan önce istek zaten LVE'nin içindedir; bu yüzden limit aşımı PHP'nin kendi hata mekanizmasından önce devreye girer.

En sık atlanan nokta: LVE hesap başınadır, site başına değil. Tek bir cPanel hesabı altında 30 alan adı barındıran bir müşteri, 30 site için tek bir limit setini paylaşır.

Altı limit ve hangisi ne yapar

• SPEED — CPU payı. 100% bir tam çekirdek, 200% iki çekirdek demektir. Limit dolduğunda istek reddedilmez, yavaşlatılır. Yani CPU limiti 508 üretmez; timeout ve "site çok yavaş" ticketı üretir.
• PMEM — fiziksel bellek. Aşıldığında yeni bellek ayırma başarısız olur, süreç ölür; ziyaretçi genellikle 500 ya da 503 görür.
• EP (Entry Processes) — LVE'ye aynı anda giren istek sayısı. Pratikte "şu anda paralel çalışan PHP isteği sayısı". 508 hatasını üreten limit budur.
• NPROC — kullanıcıya ait toplam süreç sayısı. Dolduğunda yeni süreç açılamaz: SSH ya da cron tarafında fork: Cannot allocate memory veya Resource temporarily unavailable, web tarafında yine 500/503 görürsün. NPROC 508 üretmez, karıştırılan yer burasıdır.
• IO — disk okuma/yazma hızı, KB/s cinsinden.
• IOPS — saniyedeki disk işlemi sayısı. IO limiti boşta ama IOPS doluysa semptom "disk yavaş" gibi görünür; oysa problem büyük dosya değil, çok sayıda küçük dosyadır.

Yapılandırmada bir de VMEM (sanal bellek) duruyor ama kullanımdan kaldırıldı: CloudLinux'un kendi önerisi bu limiti 0 bırakıp belleği yalnızca PMEM ile sınırlamak. Sebebi basit — modern runtime'lar gerçekte dokunmadıkları büyük sanal alanlar ayırıyor, VMEM ile ölçmek yanıltıcı sonuç veriyor.

508 hatası aslında ne diyor

508 kodu HTTP'de tanımsız değil; RFC 5842'de WebDAV için "Loop Detected" olarak geçer. CloudLinux bu kodu kendi amacı için yeniden kullanır ve gösterdiği "508 Resource Limit Is Reached" ekranının tek bir anlamı vardır: istek geldiğinde hesabın EP limiti doluydu, istek sıraya bile alınmadı.

Buradaki en yaygın yanlış okuma "sitenin trafiği çok arttı" demektir. EP eşzamanlılıktır, trafik değil. İlişki basit:

eşzamanlı istek sayısı = saniyedeki istek × ortalama istek süresi

EP=20 ile:

• Ortalama 0,2 saniye süren sayfalarda saniyede ~100 isteğe kadar hiçbir şey olmaz.
• Ortalama 2 saniye süren sayfalarda saniyede 10 istek 508 üretmeye yeter.

Aynı trafik, on kat farklı sonuç. Yani 508 çoğu zaman bir süre problemidir. EP'yi yükseltmek semptomu bastırır ve sunucunun toplam yükünü artırır; sayfa süresini düşürmek (opcode cache, sayfa cache, sorgu düzeltmesi) sorunu ortadan kaldırır.

Kimin, ne zaman, hangi limite tosladığını görmek için:

• lveinfo --period=1d --display-username — son 24 saatin özeti, LVE ID yerine kullanıcı adıyla
• lveinfo --period=7d --display-username --by-fault=any --limit=20 — en çok fault alan 20 hesap (--limit varsayılanı 10'dur, o yüzden elle vermek gerekir)
• WHM > CloudLinux LVE Manager > Users sekmesi — aynı veri, renkli çubuklarla

Ayrıca LVE Manager'dan son kullanıcı bildirimlerini açmakta fayda var. Müşteri cPanel'deki "Resource Usage" ekranından kendi fault geçmişini görebiliyorsa, gelen ticketların önemli bir kısmı "sizin sunucu bozuk" olmaktan çıkıp "o eklentiyi kaldırdım" oluyor.

lve-stats verisi varsayılan olarak SQLite'ta (/var/lve/lvestats2.db) tutulur. Yoğun sunucularda bu dosya büyüdükçe lvestats'in kendisi belirgin IO üretmeye başlar; o noktada istatistik veritabanını MySQL'e taşımak mantıklı olur.

Limitleri tahminle değil ölçerek ayarlamak

Doğru yaklaşım paket bazında ayarlamak; kullanıcı bazında istisna açmak ikinci adım.

• lvectl package-set starter --speed=100% --pmem=1G --ep=20 --nproc=100 --io=4096 --iops=1024 — paketin limitleri
• lvectl apply all — /etc/container/ve.cfg içindeki ayarları çalışan tüm LVE'lere uygular
• lvectl set-user kullanici --speed=200% --pmem=2G --ep=30 — tek hesap için istisna
• lvectl list — mevcut limitleri döker

Paket limitini değiştirdikten sonra lvectl apply all çalıştırmayı unutma; onun ardından limitler anında geçerli olur, hiçbir servisi yeniden başlatmak gerekmez.

Başlangıç için makul bir set (WordPress ağırlıklı, orta yoğunluklu bir sunucu): speed 100%, pmem 1G, ep 20, nproc 100, io 4096 KB/s, iops 1024. Sonra bir hafta lveinfo çıktısına bakıp gerçek fault dağılımına göre daralt ya da genişlet.

Sık yapılan üç hata:

• IO'yu boş bırakmak. CPU ve belleği sıkı tutup IO'yu sınırsız bırakırsan, gece çalışan tek bir yedekleme scripti diski kilitler ve LVE hiçbir şey yapmaz.
• NPROC'u EP'ye çok yakın vermek. NPROC cron işlerini, SSH oturumlarını ve arka plan süreçlerini de sayar. EP=20 iken NPROC=25 vermek kullanıcıyı sebepsiz duvara çarptırır; 100 civarı çok daha sağlıklı.
• Herkese aynı limiti verip unutmak. Bir e-ticaret hesabıyla statik bir kurumsal siteyi aynı pakete koymak, birine gereksiz ticket, diğerine gereksiz kaynak demektir.

CageFS: kullanıcıyı kendi dosya sistemine kapatmak

CageFS her kullanıcıya sanallaştırılmış, izole bir dosya sistemi verir. Kullanıcı /etc/passwd okuduğunda yalnızca kendi satırını ve birkaç sistem hesabını görür, ps aux çalıştırdığında yalnızca kendi süreçlerini görür ve diğer hesapların home dizinlerine giden hiçbir yol yoktur.

Pratik karşılığı: paylaşımlı hostingin klasik açığı olan symlink saldırısı (bir hesaptan diğerinin wp-config.php dosyasını okuma) kapanır. Kullanıcıya yalnızca açıkça izin verilmiş binary'ler sunulur, tehlikeli SUID araçları görünmez olur.

• cagefsctl --enable-all — devre dışı listesindekiler hariç tüm kullanıcılar için aç
• cagefsctl --list-disabled — kimler kapsam dışı
• cagefsctl --disable kullanici — tek hesabı çıkar
• cagefsctl --update — skeleton'ı güncelle (yeni paket kurduktan sonra şart)
• cagefsctl --force-update — güncelleme periyodunu beklemeden skeleton'ı yeniden kurar, uzun sürer
• cagefsctl --remount-all — skeleton'ı ve tüm kullanıcıları yeniden bağlar

Sisteme yeni bir paket kurdun ve kullanıcılar onu göremiyor mu? Cevap neredeyse her zaman cagefsctl --update çalıştırılmamış olmasıdır. Kendi aracını kullanıcılara açmak içinse /etc/cagefs/conf.d/aracim.cfg dosyasına [aracim], comment=Aracim ve paths=/usr/local/bin/aracim satırlarını yazıp cagefsctl --force-update çalıştırman gerekir.

Bedeli de var: skeleton diskte birkaç GB yer kaplar, --force-update yoğun bir sunucuda dakikalar sürer ve her kullanıcının kendi /tmp'i olduğu için destek ekibi bazen "dosya orada yok" derken aslında yanlış namespace'e bakıyordur.

PHP Selector ve kurmadan önce bilinmesi gereken üç kısıt

PHP Selector, kullanıcının kendi panelinden PHP sürümünü ve eklentilerini seçmesini sağlar. alt-php paketleri eski 5.x sürümlerinden 8.x'e uzanır ve her sürüm ayrı bir RPM setidir.

• selectorctl --list — kurulu sürümler
• selectorctl --summary — hangi kullanıcı hangi sürümde
• selectorctl --set-user-current=8.2 --user=kullanici
• selectorctl --list-extensions --version=8.2

Kurmadan önce netleştirmen gereken üç şey:

• CageFS zorunludur. CageFS kapalı bir kullanıcı için PHP Selector çalışmaz. İkisini birbirinden bağımsız düşünme.
• cPanel'de PHP-FPM ile birlikte çalışmaz. Bir hesapta PHP-FPM açıksa Selector o hesap için devre dışı kalır ve hesap EA-PHP sürümünü kullanır. İnsanların en çok takıldığı yer burasıdır ve seni bir tercihe zorlar: FPM'in performans profili mi, kullanıcının sürüm özgürlüğü mü.
• MultiPHP Manager'ın önceliği daha yüksektir. Sunucunun "System PHP Version" değeri bir ea-php sürümü olmalı (oraya alt-php seçmek Selector'ı bozar) ve Selector kullanacak alan adları MultiPHP Manager'da "inherit" bırakılmalıdır; aksi halde panelde seçilen sürüm kullanıcının seçimini ezer.

LiteSpeed tarafında mod_lsapi alt-php ile sorunsuz çalışır ve FPM'e ihtiyaç duymadan benzer bir eşzamanlılık profili verir; LiteSpeed lisansı ile CloudLinux'u aynı sunucuda kullananların büyük kısmı bu yüzden bu kombinasyonda kalıyor.

MySQL Governor: LVE'nin göremediği yer

LVE veritabanı yükünü ölçmez. Çünkü sorgu kullanıcının LVE'sinde değil, mysqld sürecinin içinde çalışır. Kötü yazılmış tek bir JOIN sunucunun CPU'sunu bitirebilir ve LVE bunu hiç görmez — o kullanıcının CPU grafiği tertemiz görünür.

MySQL Governor tam olarak bu boşluğu kapatır: kullanıcı başına veritabanı CPU'sunu ve okuma/yazma miktarını izler, eşiği aşan hesabı kısıtlar.

Kurulum MySQL/MariaDB'yi CloudLinux'un kendi derlemesiyle değiştirir: /usr/share/lve/dbgovernor/mysqlgovernor.py --install. Bu bir bakım penceresi ister, veritabanı yeniden başlar. Ayrıca CloudLinux'un derlemeleri upstream sürümlerin bir miktar gerisinden gelebilir; bu hafta çıkan bir minor sürüme ihtiyacın varsa bunu planına yaz.

• dbctl list — kullanıcı bazında limitler ve güncel kullanım
• dbctl set kullanici --cpu=150,100,70,50 --read=2048,1500,1000,800 — dört değer, art arda gelen dört kısıtlama seviyesine karşılık gelir
• dbctl restrict kullanici / dbctl unrestrict kullanici — elle kısıtla, kısıtlamayı kaldır
• dbctl list-restricted — o an kısıtlı olan hesaplar
• dbctl ignore kullanici — hesabı kısıtlamanın tamamen dışında tut
• dbtop — kullanıcı bazında canlı MySQL kullanımı

Yapılandırma /etc/container/mysql-governor.xml içindedir. Buradaki lve etiketinin use değeri kısıtlanan kullanıcının nasıl ele alınacağını, restrict etiketindeki level1-level4 değerleri ise art arda gelen dört kısıtlama seviyesinin ne kadar süreceğini belirler (örnek yapılandırmada 60 saniye, 15 dakika, 1 saat, 1 gün). Kullanıcı bazında üç mod vardır: restrict (varsayılan), norestrict (kullanımı izle ama kısıtlama) ve ignore (ne izle ne kısıtla).

Üretime doğrudan sıkı limitlerle girmek yerine bir hafta norestrict ile izleyip kimin gerçekten yük ürettiğini görmek çok daha az ticket üretir.

Az bilinen ikinci faydası: uzun süren sorguları öldürme. Aynı dosyadaki slow_queries ayarını açtığında eşiği aşan sorgular kesilir — böylece dakikalardır dönen tek bir SELECT yüzünden tüm sunucu beklemez.

CloudLinux neyi çözmez

Dürüst olmak gerekirse birkaç boşluk var:

• Ağ bant genişliğini limitlemez. Büyük dosya servisi yapan bir hesap hiçbir LVE limitine takılmadan hattı doldurabilir; bunu web sunucusu ya da trafik şekillendirme tarafında çözmen gerekir.
• Güvenlik yazılımı değildir. CageFS izolasyon sağlar ama zararlı dosya tespiti, WAF ve brute force koruması ayrı bir katmandır; Imunify360 tarafına ayrıca bakman gerekir.
• Kötü kodu düzeltmez. Sadece zararını tek hesaba hapseder. O hesabın müşterisi hâlâ 508 görüyor olacak.
• Kendi çekirdeğiyle gelir. Güvenlik yamaları için yeniden başlatma gerekir. Bunu ortadan kaldırmak istiyorsan KernelCare ile canlı yamaya bakman lazım; ikisi aynı sunucuda birlikte kullanılmak üzere tasarlanmıştır.

Lisans tarafı

vialicense.com üzerinden aldığın CloudLinux lisansı sunucunun IP adresine bağlanır, bir anahtar dosyasına değil. Bu, kurulumu pratikte tek komuta indirir: betik lisansı IP'den bulur. Sunucu taşıdığında IP'yi panelden kendin değiştirirsin, eski adres anında düşer.

Aktivasyon otomatiktir — ön ödemeli bakiyeden düşer, onay adımı yoktur ve genellikle bir dakika içinde çalışır durumdadır. Aylık lisanslar dönem sonuna kadar geçerlidir; taahhüt ya da cayma bedeli yoktur. Sürümler ve aktivasyon adımları CloudLinux lisansı sayfasında duruyor.