Valeriano Manassero

Secondo il mio umile parere, stai approcciando il problema dalla parte sbagliata e lo dico per te. Un "muletto" che parta in caso di necessità, sul cloud lo crei in 10 minuti ma non è ciò che ti serve. Se ascolti me, prima di tutto, chiarisci col cliente l'uptime che gli devi garantire e poi in base a quello scegli la soluzione più adatta altrimenti sarà un bagno di sangue e ti ricorderai di questo messaggio quando sarà troppo tardi (toccati :asd: ). Poi fai come vuoi.

Qualche minuto di down dell'infrastruttura in un anno è un uptime veramente molto alto da garantire. Forse non sono stato chiaro abbastanza, scusa, riprovo che a volte do per scontate delle cose: che uptime annuale devi garantire al Cliente da progetto? lo dico perché se l'obiettivo è un uptime garantito stile "servizi bancari", il cliente dovrà essere preparato a sborsare una svalangata di soldi e mi pare che tutta questa storia sia un enorme overkill considerato che non c'è ancora nemmeno il sito (se ho ben capito). Se è così, un uptime di una VPS professionale dovrebbe già essere una garanzia sufficiente.

Non ti serve bilanciare, come sospettavo, infatti non è che una macchina sola non riesca a sopportare il carico di lavoro. Tu vuoi un piano di failover che è una strategia totalmente differente. Se per un sistema unico unmanaged dico sempre che ci vuole l'esperienza, in un contesto distribuito il livello di difficoltà sale e parecchio. Prima di tutto cerca di individuare quanto tempo puoi stare offline col tipo di servizio che offri e poi in base a quello si può parlare della soluzione più adatta. EDIT: Doppio incrocio con Flame, dovremo arrivare a sincronizzarci prima di postare :D

Plesk non ha niente a che vedere col bilanciamento. Intanto bisognerebbe vedere che cosa vuoi bilanciare e perché per scegliere la soluzione giusta. Immagino tu voglia esporre HTTP e HTTPS al pubblico, dubito tu voglia bilanciare mysql, piuttosto vorrai metterlo in failover ma stiamo parlando di due livelli di rete differente. Insomma, per andare su strutture di una certa complessità il pannello non lo prenderei nemmeno in considerazione se non DOPO aver creato tutta la struttura a manina con NFS, heartbeat, mysql in configurazione cluster ed altro.

Anche se non è íl wiki di Centos, potrebbero tornati utili queste info (Arch è systemd based): https://wiki.archlinux.org/index.php/Change_root Guardati la sezione System-nspawn

Tutto legale, sicuro?

Uno per dominio?

Aruba Smart Cloud Server in taglia Small dovrebbe fare al caso tuo.

EDIT: Elimino il messaggio che, a ben pensarci, è un discorso che non può essere recepito per ovvie ragioni. Good luck e fine :D

Confermo. Stanno diventando una roba vergognosa.

Perché un server va gestito e checchè se ne dica, il 99% degli utenti non lo sa fare e si affida al pannellino LOL di turno, magari free e anche famoso per essere un colabrodo :D . Poi fra 6 mesi torna qua a piangere che le sue mail vanno in spam o che, STRANAMENTE, il sito con 5 utenti attivi è inchiodato e comincerà ad incazzarsi che il provider non gli fornisce supporto per una vps da 5 euro al mese. Però da un certo punto di vista c'è del positivo in tutto ciò (non per noi ovvio), ovvero c'è sempre carne nuova da botnet :D P.S. Una soluzione di hosting un pelino più PRO con un certo tipo di garanzie potrebbe essere la scelta giusta in questi casi, ovviamente il cliente deve essere disposto a pagare per abbandonare una soluzione low-cost. (che poi parlassimo anche di 150 euro l'anno, per un professionista serio, sono noccioline da mettere a budget dai).

Secondo me c'è un problema di comunicazione tra te e l'hoster che dice, due righe più su, che te li avrebbe forniti. Awstats e Google non sono strumenti di debug. Ti potrei illustrare centinaia di casi in cui con una sola richiesta di pochissimi kb, ti sparo la cpu al 100% per un po'. E poi non è detto che il problema sia il website ma potrebbe essere l'MTA, te l'ho già anche detto. Non conosco le politiche di HostingVirtuale ma è possibilissimo che abbiano rilevato un'anomalia di consumo di qualche risorsa e non per questo conoscano la causa che risiede all'interno del tuo applicativo per cui loro non possono ovviamente intervenire. Se la tua auto fa fumo come una ciminiera, non passa il collaudo, ma il collaudatore non ti fa mica la diagnosi del motore, per quello ci vuole il meccanico che deve aprire tutto e capire dove sta il guaio.

Va beh che siamo in un forum e che i typo capitano ma punteggiatura e grammatica non sono optional :D Non è chiaro. La RAM rimanente da cosa era impegnata?

Una casella di posta per uso business con certe garanzie non la si ottiene con questo tipo di prodotto, hai fatto un errore di valutazione. :asd: :asd: Questa è fantastica :D Tutti preferirebbero non avere problemi nella vita, ma capita; è il come si interviene che fa la differenza. Giustissimo. E' anche giusto che per poter fare debug devi poter avere strumenti adatti per poterci lavorare. I log di Apache sono il primo passo se parliamo del webserver, ma ci vorrebbero anche i log del MTA perché magari è lì che hai avuto un problema. Who knows?

Posto che dovresti lavorare un pochino sulla tua capacità di formulare frasi di senso compiuto (non ti offendere, ma faccio fatica a capire cosa vuoi comunicare). Se ho ben capito sei ancora nella fase in cui si deve aprire partita iva. Primo pass: business plan e relativa quota necessaria all'investimento. Il resto viene dopo.