Recensione del servizio di server virtuali AreaServer di Energit

(Una copia di sicurezza di questo post è disponibile all’indirizzo http://www.livejournal.com/users/jollino/2892.html.)

Dopo un’esperienza terribile con l’hosting di Aruba che mi perdeva la posta, stava down troppo spesso e aveva grossi problemi con PHP (il tutto condito da un’assistenza a dir poco penosa), ho deciso di cambiare tutto e passare a un server virtuale.
Un server virtuale è sostanzialmente uno “slot” ricavato da un server vero e proprio, in cui l’utente può fare (quasi) tutto quello che vuole.
Un amico mi ha consigliato di rivolgermi al servizio AreaServer di Energit, operatore telefonico e provider sardo.
Li ho contattati intorno al 10 settembre 2004 e, dopo uno scambio proficuo di informazioni via e-mail, Energit mi ha proposto una settimana di prova del servizio.
Ho accettato, e devo ammettere che durante quella settimana il tutto è funzionato decentemente, ma c’è anche da dire che non avevo nessun dominio associato al server quindi non potevo giocarci molto. Tuttavia la loro disponibilità mi sembrava positiva e ho deciso di attivare il mio server virtuale e di trasferire i miei due domini principali (sogno.net e nicolucci.net) presso di loro, di fatto rinunciando ai mesi rimanenti su Aruba.

L’attivazione è stata abbastanza rapida, un paio di giorni, e subito ho notato qualcosa che non andava: utilizzando il pannello di controllo via web per aggiungere il sito www.nicolucci.net, la modifica non veniva “notata” dal sistema. Ho chiamato subito l’assistenza telefonica e la risposta è stata “il dominio non è ancora stato trasferito e il sistema non lo vede”. Il tizio non era molto sicuro, e io lo ero ancora meno: so come funzionano queste cose e mi pare insensato effettuare un controllo del genere, perché potrei tranquillamente avere un dominio gestito da un nameserver esterno che punta al server virtuale… Alla fine ho risolto modificando a mano httpd.conf.

Adesso sono al quarto mese di servizio (ottobre-novembre-dicembre-gennaio), pago mensilmente € 9.90 con addebito su conto corrente bancario e ho un abbonamento annuale. Se non fosse che i soldi non crescono sugli alberi e non posso permettermi di buttare al vento i soldi dei mesi successivi, farei come con Aruba e mi troverei un posto migliore per gestire la mia roba. I problemi, infatti, sono all’ordine del giorno.

Gli utenti non hanno a disposizione un vero accesso root, e la virtualizzazione è fatta “alla buona”.
Si ha un utente admin, ma è root solo per finta; il filesystem è condiviso e ci sono soltanto dei “paletti” per evitare che si sconfini, e sono fermamente convinto che da qualche parte una falla c’è e permette di accedere anche ai file degli altri utenti; benché ps aux non mostri i processi altrui, è possibile aggirare questa “protezione” facendo qualcosa come
cd /proc; for i in *; do echo $i >> ~/processi; cat $i/cmdline >> ~/processi ; echo >> ~/processi; echo >> ~/processi; done
e andando poi a leggere il file processi nella propria home.

I demoni utilizzati sul server sono vecchi e buggati e ovviamente non è possibile aggiornarli personalmente perché non si ha la root.
Basti pensare che c’è una versione di ipopd3d vecchia di due anni (v2003.83) che, ovviamente, non gradisce molto l’allocazione di memoria forzata da xinetd. Risultato: se si riceve un messaggio più grande della memoria allocata da xinetd, quando si cerca di scaricare la posta ipop3d crasha. Ho anche fornito all’assistenza una mia analisi sul problema (in pratica credo che quella versione di ipop3d cerchi di caricare tutto il messaggio in mail, e ovviamente non avendo abbastanza memoria disponibile si ottiene un SIGSEGV), e dopo un paio di mesi mi è stato assicurato che il limite è stato alzato da 8 MB a 32 MB. Grazie tante, ma nel frattempo ogni volta dovevo accedere via webmail, inoltrare i messaggi incriminati a una casella decente (per esempio gmail), cancellarli dalla webmail, cancellarli dal cestino della webmail e poi finalmente riscaricarmi gli altri messaggi col mio client. Una cosa comoda e veloce, proprio.
In risposta a uno dei miei primi contatti all’assistenza a proposito di questo assurdo problema, mi è stato detto di usare ftp per i trasferimenti di file grandi, quindi in sostanza avrei dovuto attivare un accesso ftp per ricevere grandi allegati. Credo sia ovvio che è una soluzione impraticabile: non sempre si sa in anticipo che qualcuno deve inviarci un allegato di 10 MB.

Tra l’altro anche il server ftp ha un problema a dir poco assurdo: durante l’upload, i file vengono troncati a 50 MB precisi, a prescindere dallo spazio allocato per l’utente in questione. Ci ho perso un pomeriggio pensando che fosse un problema mio, e alla fine ho risolto facendo dei file .zip più piccoli di 50 MB e caricandoli separatamente. Erano delle mie registrazioni in mp3, per fortuna, quindi ho potuto farlo. Ma se fosse stata una mia produzione video?

Tornando alla questione posta, si è forzati ad utilizzare sendmail, che è notoriamente molto complesso, e majordomo, che non è molto meglio.
Avrei voluto installare Mailman per gestire le mie mailing list, ma il problema è il solito: non avendo la root, non si può. Punto.

Quello che mi chiedo, e l’ho anche detto apertamente anche a loro, è come fanno ad avere un fatturato se persino un cliente che con unix ci gioca tranquillamente ha problemi del genere. Come fa un tipico “utente medio” a usare questi servizi? Sarà per quello (mi si perdoni il cattivo pensiero) che fanno contratti annuali, così, comunque vada, l’introito c’è?

Ma torniamo alla descrizione del servizio: le statistiche web sono pressoché inutilizzabili, in quanto si riferiscono, di default, al mese in corso. Ciò significa che se il primo del mese voglio vedere com’è andata il mese precedente, devo fare qualcosa come
/usr/local/bin/awstats_buildstaticpages.pl -update -config=www.sogno.net -dir=/home/web/www.sogno.net/website/awstats -awstatsprog=/home/httpd/docs/awstats/wwwroot/cgi-bin/awstats.pl -staticlinks -year=2004 -month=12
e andare a vedermi la pagina. Alla rigenerazione successiva, ovviamente, le pagine delle statistiche saranno sovrascritte con i dati più recenti.
Anche qui, penso al classico utente medio che non ha le conoscenze per ricavarsi un comando del genere leggendosi pezzi di script in bash ma che può aver bisogno delle statistiche complete per motivi commerciali.

Inoltre spesso il server è irraggiungibile: a volte capita che sia attivo ma con tutti i demoni non funzionanti, e tutte le connessioni vengono rifiutate perché le porte sono chiuse. La soluzione in questo caso è riavviare il server virtuale almeno due o tre volte tramite il pannello di controllo. Una sola volta non è sufficiente, e nessuno sa perché.
Altre volte invece il carico della cpu è spaventoso. Secondo /proc/cpuinfo, la macchina sulla quale si trova il mio server virtuale è un Pentium IV 2.8 GHz che gira a 1.4 GHz:

…
model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
cpu MHz : 1399.999
…

e la RAM fisica è di 900 MB con oltre 5 GB di swap. Una macchina di tutto rispetto (salvo che la CPU gira a metà del clock), ma spesso e volentieri si arriva a carichi di oltre 150 e giorni fa ho visto un picco di 260. I “carichi” in questione sono quelli mostrati da uptime.
In questi casi la rete funziona perfettamente, perché è gestita dal kernel, ma tutto quello che gira in user-space, cioè praticamente tutto il resto del software, è mostruosamente lento.
Questo credo renda perfettamente l’idea:

[admin@vs3089 root]$ time uptime
21:13:54 up 3:13, 0 users, load average: 159.90, 119.98, 82.68

real 0m41.713s
user 0m0.000s
sys 0m0.010s

Chiunque abbia usato un po’ uno unix sa che 41 secondi per restituire l’output di uptime è veramente troppo. Tanto per confrontare, il mio vecchio PC (un Duron 850 MHz con 512 MB di RAM), che pure ha un po’ di demoni e software in esecuzione, impiega tre millesimi di secondo.

Il problema su quel server è che ci sono troppi server virtuali con troppi processi in esecuzione.
Ho provato a fare un semplice calcolo approssimato. Il mio server virtuale ha in esecuzione circa 30 processi, che sono quelli “standard” perché non ho nessun altro processo “personale” attivo. In /proc ci sono oltre 1400 pseudofile. Ammettendo che siano anche soli 1300 (per mettere in conto i processi del server “vero”) e che ogni server virtuale abbia in esecuzione esattamente 30 processi (ma so per certo che non è così), viene fuori che su quella macchina ci sono più di 43 server virtuali.
E francamente non mi sembra una macchina in grado di reggere un carico del genere, anche perché, non essendoci una divisione effettiva della CPU e della RAM tra i vari utenti, è possibile lanciare qualsiasi processo.
Il risultato è quello che ho descritto: carichi così elevati che le connessioni vengono accettate ma vanno inevitabilmente in timeout.
Spesso, per questo problema, mi ritrovo senza poter controllare la posta per ore. Ieri, durante un black-out del genere, ho calcolato il tempo necessario per farmi rispondere dal server di posta che l’utente pippo con password pippo non esiste e poi disconnettermi. Ecco il risultato:

innocence:~ jollino$ time echo -e “USER pippo\r\nPASS pippo\r\nQUIT\r\n” | nc sogno.net pop3
+OK POP3 vs3089.areaserver.it v2003.83 server ready
+OK User name accepted, password please
-ERR Bad login
+OK Sayonara

real 3m33.044s
user 0m0.000s
sys 0m0.040s

Oltre tre minuti e mezzo. Una macchina in buone condizioni non impiega più di dieci secondi, e spesso ne impiega molto meno. In altre parole il server virtuale è spesso oltre 20 volte più lento di quanto dovrebbe.

L’assistenza poi è, mi dispiace dirlo, ma è mediocre e approssimativa. Al telefono spesso vengono date risposte dubbie, come quella sul pannello di controllo che non veniva aggiornato con i nuovi siti o quella sul limite di 50 MB per gli upload ftp, e in mail spesso le risposte arrivano solo dopo giorni, e sono ugualmente poco convincenti. Addirittura per ricevere risposta ad una mia lunga mail di lamentele ho dovuto stampare il mio messaggio e inviarlo via fax, visto che era passata una settimana e non avevo ricevuto nulla.
In generale, poi, anche loro sembrano vittima della sindrome del “ci stiamo lavorando”, così come Aruba, e non serve un genio del marketing del capire che le promesse non mantenute servono solo a far sentire presi in giro i clienti.

Ecco i miei voti finali.

Prezzo: 8/10
Attivazione: 6/10
Funzionalità: 4/10
Assistenza: 5/10
Stabilità: 3/10
Facilità d’uso: 3/10
Velocità: 5/10
MEDIA: 4.8/10

Giudizio finale: da evitare. Meglio spendere un po’ di più e avere molto di più.

Io personalmente sto pensando di rivolgermi, quando il contratto annuale scadrà, a RimuHosting, un provider con sede legale in Nuova Zelanda ma con i server negli Stati Uniti. Li ho contattati per avere informazioni sul servizio e sembrano fantastici, sono dei geek che sanno di cosa stanno parlando (e non dei commerciali che si reinventano amministratori di sistema) e rispondono in fretta. E si tratta di veri virtual server basati su User-mode Linux, in cui si ha un vero filesystem privato e una vera root, oltre a un’allocazione vera di processore e memoria.