- Home
- Categorie
- Coding e Sistemistica
- Hosting, Server e Domini
- Cloud, Scalabilità e Load balancing, un chiarimento.
-
Cloud, Scalabilità e Load balancing, un chiarimento.
Buongiorno a tutti,
scrivo questo post nella speranza che qualcuno sappia sciogliere i miei dubbi e/o comunque darmi chiarimenti in merito. Oggi si parla tanto di cloud (dedicato o non), scalabilità, architetture hardware configurabili personalmente (IAAS), ecc. ma non so come potrei gestire una mia applicazione web in termini pratici.Sono un designer (con qualche competenza di php + mysql ), ho sviluppato una mia applicazione web (ambiente LAMP) che a regime dovrebbe servire migliaia di utenti.
Vorrei provare a configurare più server (almeno 2 dedicati al DB e almeno 3 per la parte php/script) e posizionarvi l'applicazione. Ho letto, documentandomi un pò sull'argomento, che un load balancer analizza la richiesta del client indirizzandola sul server meno carico in quel momento. Fin qui ci sono, ma essendo un'applicazione che vive anche di contenuti generati dal contributo degli utenti, come fa in pratica il contenuto ad essere salvato sugli hard disk di più server? Devo essere io (tramite il codice della mia applicazione) a far scrivere il dato simultaneamente su più server/hard disk o è sufficiente un'impostazione hardware che monitora un server principale e duplica il contenuto appena inserito su tutti gli altri server? Oppure quello che ho illustrato fin qui è errato e la metodologia di funzionamento è completamente diversa?E poi... se si tratta di contenuti duplicati, come faccio ad evitare che Google mi penalizzi? (ma questo forse devo postarlo in un altra sezione del forum)?
Grazie a chiunque dia il proprio contributo, anche se esaustivo solo in piccola parte. Sono un "quasi" neofita anche io.
Francesco
-
Premesso che sono sistemista fino ad un certo punto, ma ho lavorato con ambienti strutturati. Un load Balancer è una cosa, si mette sui web per distribuire le richieste secondo il carico. Il db risiede su un'altro server e in caso di scalabilita orrizontale si parla di cluster di database. Cmq cosa vuol dire migliaia di richieste? Al giorno, simultanei? Comincerei a pensare a strutture di questo problema quando i problemi sono reali, anche perché a quei livelli ci son molti altri problemi da gestire.
-
Il problema più grande del cloud è proprio quello che hai citato. Una risposta definitiva non l'ha dato ancora nessuno, ma si ricorre spesso alla replicazione.
Guarda ad esempio questo http://www.nuodb.com/explore/sql-cloud-database-how-it-works/
Loro usano messaggi e un'architettura p2p. Ovviamente ciò implica che non tutti i nodi saranno simultaneamente sincronizzati e quindi bisognerà attendere un tot di tempo affinchè le informazioni fluiscano lungo la rete p2p. Nella stragrande maggioranza delle applicazioni cloud, si usa o un dbms transazionale normalissimo ( magari in configurazione cluster ) o dbms nosql ( che però non garantiscono le proprietà ACID ).
-
@erise said:
Premesso che sono sistemista fino ad un certo punto, ma ho lavorato con ambienti strutturati. Un load Balancer è una cosa, si mette sui web per distribuire le richieste secondo il carico. Il db risiede su un'altro server e in caso di scalabilita orrizontale si parla di cluster di database. Cmq cosa vuol dire migliaia di richieste? Al giorno, simultanei? Comincerei a pensare a strutture di questo problema quando i problemi sono reali, anche perché a quei livelli ci son molti altri problemi da gestire.
Ciao Erise,
il progetto dell'applicazione web a regime dovrebbe arrivare a generare migliaia di visitatori unici giornalieri. Al momento del lancio, anche un unico webserver (ben settato e prestante) + un server per il db può bastare, ma sto pensando alla scalabilità dell'applicazione proprio perchè non ne so molto e non vorrei trovarmi nel momento del bisogno a discutere con un sistemista che mi dice che il codice dell'applicazione così com'è scritto non va assolutamente bene e quindi va riscritto. Vorrei sapere cosa c'è da fare prima che questa avvenga, cosa è bene predisporre sin da ora, in modo tale da trovarmi pronto per scalare l'applicazione.
Poi, a parte le prestazioni, se l'applicazione va bene credo sia utile installarla su almeno un secondo server per ridondanza/continuità.Ho anche letto qualcosa sul round robin, ma a parte il fatto che non saprei come replicare il contenuto sui vari server, pare ci siano problemi con la gestione delle sessioni. A quanto ho capito l'utente viene allocato, sequenzialmente, sui vari server ad ogni richiesta (quindi ad ogni pagina).
-
Migliaia di visitatori giornalieri non sono tanti per il web, fai il conto di quante accessi simultanei credi di avere, piuttosto di preoccuparmi di queste cose pensa a scrivere una applicazione a prova di bomba, ottimizzata, veloce, dividendo i contenuti statici da quelli dinamici, usando una cdn... Ti accorgerai che con opportuni accorgimenti i carico dei server diminuiscono drasticamente e il momento in cui avrai bisogno di una struttura del genere sarà molto ma molto lontano.
-
Senza entrare nei dettagli, il load balancing è una buona soluzione se lo abbini a una struttura cluster o High Availability (HA), reale o virtuale.
Generalmente, per server (o siti) molto trafficati, si opera con questa struttura MINIMA:
un router fisico che fa da balancer, ovvero smista il traffico in ingresso verso la rete interna;
due server in cluster reale o virtuale (che sono la "rete interna")I due server in cluster possono essere in cluster reale o virtuale. Cluster reale significa che sono due server solitamente identici in tutto e per tutto con configurazioni software e hardware particolari (tipicamente usano un NAS per condividere i dati e software specifici come p.e. MySql Cluster), cluster virtuale significa che operano più che altro a livello software senza usare però software o hardware appositamente studiati.
Cerco di spiegare meglio il lato "virtuale". Per sincronizzare i dati tra i due server si può operare ad esempio con MySql configurato in replica master-master, con la parte web (diciamo apache, ma è indifferente) che si sincronizza tramite un software tipo unison e la parte "servizi aggiuntivi" (chessò Dns, ftp ecc) che operano indipendentemente e senza replica.In poche parole questa è la situazione standard che si ha con sistemi LB e HA, cioè Load Blanaced e in High Availability.
Detto questo, una soluzione così a parte essere costosa, ha poco senso se il sistema è unico, se ne ha il pieno controllo e non raggiunge traffico di migliaia di utenti al secondo