Alternativa a CloudLinux: limiti per account con cgroup v2 su Ubuntu 24.04
Su un server di hosting condiviso basta un sito che esagera (un plugin impazzito, un bot che scarica tutto, un sito bucato che manda spam) per rallentare tutti gli altri. CloudLinux risolve il problema dando a ogni account i suoi limiti di CPU, memoria, processi e disco, ma costa circa 18 dollari al mese per server e richiede AlmaLinux o un suo derivato. Su Ubuntu 24.04 gli stessi limiti si ottengono con strumenti già presenti nel sistema: systemd e i cgroup v2. In questa guida vediamo come farlo a mano per un account, cosa manca rispetto a CloudLinux e come lo fa Koapanel con il modulo Isolamento e limiti, incluso in tutti i piani.
Cosa fa CloudLinux, in breve
CloudLinux aggiunge al server alcune funzioni pensate per l'hosting condiviso:
- LVE: limiti per account di CPU, memoria, processi, velocità del disco (I/O e IOPS), numero di file e entry processes, cioè quante richieste PHP dell'account possono girare nello stesso momento;
- CageFS: ogni account vede un file system tutto suo, senza gli altri clienti e senza i file di sistema sensibili;
- MySQL Governor: rallenta nel database l'account che esagera;
- PHP Selector e selettori per Ruby, Python e Node;
- strumenti di diagnosi come X-Ray per i siti lenti.
Per un server che ospita i siti di molti clienti sono funzioni utili. Ma il kernel di Linux oggi fa gran parte di questo lavoro da solo.
cgroup v2: il meccanismo che c'è già
I cgroup (control group) sono la funzione del kernel che raggruppa i processi e ne limita le risorse. Ubuntu 24.04 usa la versione 2, e systemd la espone in modo semplice: ogni servizio gira nel suo cgroup e le slice raggruppano più servizi con un limite comune.
Le proprietà che servono per l'hosting:
| Proprietà systemd | Cosa limita | Equivalente CloudLinux |
|---|---|---|
CPUQuota=100% |
tempo di CPU (100% = un core) | SPEED |
MemoryMax=1G |
memoria | PMEM |
TasksMax=200 |
processi e thread | NPROC |
IOReadBandwidthMax, IOWriteBandwidthMax |
MB/s su un disco | IO |
IOReadIOPSMax, IOWriteIOPSMax |
operazioni al secondo | IOPS |
Mancano all'appello gli entry processes, ma per il PHP c'è un equivalente semplice: il numero massimo di processi del pool PHP-FPM dell'account (pm.max_children).
Il problema di PHP-FPM condiviso
Su un server Ubuntu normale tutti i pool PHP-FPM girano sotto un unico servizio, php8.3-fpm.service. Anche se ogni sito ha il suo utente Linux, i processi PHP di tutti i clienti stanno nello stesso cgroup: limitare quel servizio vorrebbe dire limitare tutti insieme.
La soluzione è dare a ogni account un PHP-FPM tutto suo, come servizio separato dentro la sua slice.
Limiti per un account, a mano
Prendiamo un account cliente1, con i siti in /var/www/cliente1 e l'utente Linux cliente1.
1. La slice con i limiti
# /etc/systemd/system/cliente1.slice
[Unit]
Description=Hosting account cliente1
[Slice]
CPUQuota=100%
MemoryMax=1G
TasksMax=200
IOReadBandwidthMax=/dev/vda 50M
IOWriteBandwidthMax=/dev/vda 50M
Il dispositivo (/dev/vda nell'esempio) è il disco dove stanno i siti: controllalo con df /var/www.
2. Un pool PHP-FPM dedicato
; /etc/php/8.3/fpm/cliente1.conf
[global]
pid = /run/php/php-fpm-cliente1.pid
error_log = /var/log/php-fpm-cliente1.log
[cliente1]
user = cliente1
group = cliente1
listen = /run/php/php-fpm-cliente1.sock
listen.owner = www-data
listen.group = www-data
pm = ondemand
pm.max_children = 10
pm.process_idle_timeout = 30s
php_admin_value[open_basedir] = /var/www/cliente1:/tmp
pm.max_children = 10 fa da entry processes: al massimo dieci pagine PHP dell'account nello stesso momento, le altre aspettano in coda invece di prendersi CPU e memoria.
3. Il servizio, dentro la slice e isolato
# /etc/systemd/system/php-fpm-cliente1.service
[Unit]
Description=PHP-FPM for cliente1
After=network.target
[Service]
Type=notify
Slice=cliente1.slice
ExecStart=/usr/sbin/php-fpm8.3 --nodaemonize --fpm-config /etc/php/8.3/fpm/cliente1.conf
ExecReload=/bin/kill -USR2 $MAINPID
# isolamento, il cuore di CageFS:
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/var/www/cliente1 /run/php /var/log
InaccessiblePaths=-/var/www/cliente2 -/var/www/cliente3
[Install]
WantedBy=multi-user.target
ProtectSystem=strict rende il sistema in sola lettura, PrivateTmp=yes dà all'account una /tmp sua, InaccessiblePaths nasconde le cartelle degli altri clienti.
4. Attivare e verificare
sudo systemctl daemon-reload
sudo systemctl enable --now php-fpm-cliente1.service
systemctl status cliente1.slice
sudo systemd-cgtop
Poi nella configurazione nginx dei siti di cliente1 fai puntare fastcgi_pass al nuovo socket unix:/run/php/php-fpm-cliente1.sock e ricarica nginx. Con systemd-cgtop vedi in tempo reale CPU, memoria e I/O di ogni slice: se un sito dell'account esagera, rallenta solo cliente1.slice.
Per cambiare un limite senza riavviare: sudo systemctl set-property cliente1.slice CPUQuota=200%.
Quello che resta fuori
La versione fatta a mano funziona, ma su un server vero mancano diversi pezzi:
- cron e WP-CLI: girano fuori dalla slice, quindi fuori dai limiti, a meno di lanciarli con
systemd-run --slice=cliente1.slice; - la cache Redis di ogni sito, se c'è, va messa nella slice dell'account;
- il database: i cgroup non vedono quanto lavora MariaDB per ciascun account. Si può limitare il numero di connessioni per utente (
MAX_USER_CONNECTIONS), ma non la CPU come fa il MySQL Governor; - i grafici: sapere chi ha raggiunto i limiti, quando e quante volte richiede di leggere i contatori dei cgroup (
memory.events,cpu.stat) e conservarli; - la manutenzione: un servizio e una slice per ogni account, da creare, aggiornare e cancellare insieme agli account, per ogni versione di PHP.
Con dieci account si gestisce; con cento serve uno strumento.
Come lo fa Koapanel
Koapanel ha il modulo Isolamento e limiti, facoltativo e incluso in tutti i piani, che fa quanto sopra per ogni account, con i siti online:
- limiti per account di CPU, memoria, processi, I/O, IOPS, richieste PHP contemporanee, file e connessioni al database, nel pacchetto, sul singolo account o come predefiniti del server; anche un tetto complessivo per rivenditore;
- PHP isolato come CageFS: ogni account vede solo i propri siti, il sistema in sola lettura e una
/tmpprivata; nei limiti rientrano anche cron, WP-CLI e la cache Redis; - limitatore del database facoltativo, come il MySQL Governor;
- X-Ray per i siti lenti: per ogni pagina PHP troppo lenta indica il plugin, il tema o il file colpevole;
- limite delle email all'ora per account, contro gli account compromessi che mandano spam;
- grafici di 24 ore e 30 giorni, avvisi via email quando un account raggiunge i limiti, una classifica e un rapporto ogni lunedì;
- import dei limiti da cPanel su CloudLinux con la migrazione via SSH;
- nel modulo WHMCS i limiti si vendono come opzioni configurabili.
Non modifica il kernel e non ha selettori per Ruby, Python o Node: copre PHP e WordPress, cioè quasi tutto l'hosting condiviso. Si installa e si disinstalla con un clic; disinstallato, il server torna com'era. Il confronto punto per punto con CloudLinux e il calcolo del risparmio sono nella pagina alternativa a CloudLinux; i dettagli nel manuale, sezione Isolamento e limiti.
Domande frequenti
I cgroup v2 rallentano il server?
No in modo misurabile: il kernel conta le risorse di ogni processo comunque. Il costo vero è la memoria dei PHP-FPM separati, circa 10 MB per account; con il PHP su richiesta solo gli account visitati di recente ne occupano.
Funziona anche su Debian?
I meccanismi (systemd e cgroup v2) sì, con Debian 12 o più recente. Koapanel invece gira solo su Ubuntu 24.04 LTS.
Posso passare da CloudLinux a Koapanel senza perdere i limiti?
Sì: la migrazione via SSH da un server cPanel con CloudLinux legge i limiti LVE di ogni account e un amministratore li importa con un clic. Vedi migrare da cPanel.
Il limite di memoria fa cadere il sito?
Quando un account arriva al limite, il processo PHP che esagera viene fermato e quella pagina dà errore; le altre pagine e gli altri account continuano. Per questo conviene dare limiti realistici e guardare i grafici nei primi giorni.
Prova Koapanel
Guarda il pannello nella demo pubblica oppure installalo su un Ubuntu 24.04 appena creato, gratis fino a 3 siti:
curl -fsSL https://get.koapanel.app | sudo bash
Il modulo si installa da Server › Isolamento e limiti, oppure subito con l'installazione: curl -fsSL https://get.koapanel.app | sudo KOAPANEL_ISOLATION=1 bash.