Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 12
  1. #1
    Utente di HTML.it
    Registrato dal
    Mar 2005
    Messaggi
    317

    Vorrei parlare di Cluster

    Salve a tutti ...

    Condividiamo un po di pensieri sui server in cluster ? ... io ultimamente ne sto facendo molti.

    A me piace partire da delle simulazioni, quindi prendiamo una bella applicazione web, abbiamo quindi i soliti protagonisti: APACHE, PHP e MYSQL.

    "Questa volta abbiamo fatto centro!!!" La nostra applicazione è scritta bene e avrà sicuramente modo di espandere le proprie funzionalità, siamo già sicuri che ci saranno centinaia di accessi, centinaia di utenti che la utilizzeranno per lavoro... tutti i giorni!

    Dobbiamo pensare ad un dimensionamento dei server e ad una soluzioni in cluster.

    Benissimo ... ora, il mio pensiero parte da fatto che WEB server e Database Server devono essere separati. Il lavoro più grosso infatti lo fa mysql, tutte le pagine sono dinamiche e anche la pagina più semplice fa circa 20 query tra controllo autorizzazioni e popolazione dei contenuti.

    Stavo pensando a 2 tipi di cluster, entrambi con load balancer (ovviamente):
    il primo, per il web e php, formato da un due o tre server un po economici
    il secondo per mysql con server più potenti.

    Stavo anche pensando alla possibilità di avere i server distribuiti, ad esempio su un totale di 10 server MySql, tutti facente parte dello stesso cluster ma fisicamente in luoghi (città) diversi.

    Avrebbe senso metterci solo i Server MySql ? O ci andrebbe una parte del cluster web ?

    Nel CED teniamo il load balancer del cluster WEB (che risponde a www.miosito.it), con 2 server web (cluster-web1.local, cluster-web2.local); il load balancer MySql (potrebbe essere db.miosito.it) con 2 server web (cluster-mysql1.local, cluster-mysql2.local).

    Correggetemi se sbaglio:
    La richiesta viene tradotta dai DNS e www.miosito.it raggiunge il mio CED, il load balancer mi passa uno dei due server web. Ora il PHP deve accedere al Database, fa quindi riferimento a db.miosito.it per autenticarsi e lanciargli le query, a questo punto il load balancer di mysql dovrebbe passarmi il primo mysql server libero che ho li nel CED giusto ?

    Se io avessi un MySql server 3 e 4 (cluster-mysql3.miosito.it, cluster-mysql4.miosito.it), uno a Milano e uno a Bologna, posso inserirli nel cluster giusto ?! Avranno indirizzi pubblici ma ne posso inserire quanti ne voglio nel cluster...

    Questa situazione secondo me comporterebbe un investimento sbagliato per i server di Milano e Bologna.

    Quando mai il load balancer mysql andrà su internet a passarmi una richiesta invece che accedere ad uno dei due che trova nella sua LAN in Giga ??? Solo nel caso in cui i due server nel CED scoppino !!! Per il resto non credo vada bene ...

    sbaglio ? Sicuramente si ... ma dove mi sono perso ?
    Grazie per le condivisioni .... Ciao
    La fortuna favorisce la mente preparata

  2. #2
    puoi fare un mysql clutser con vari nodi ...e bilanciare il tutto con il bilanciamento delle richieste sul dns..

    ma parliamo di query , pesanti , cioè querry innestate , il cui tempo medio di risposta è ?

    oppure parliamo di numero di richieste al dabatase pesanti?.


    ci dovresti fornire qualche dato statistico , per consigliarmi al meglio.
    www.danieleferrara.it sistemista /programmatore pagina personale
    www.e-sysadmin.com e-commerce informatico

  3. #3
    Utente di HTML.it
    Registrato dal
    Mar 2005
    Messaggi
    317
    Ciao !!!


    bilanciare il tutto con il bilanciamento delle richieste sul dns..
    Scusami ma non ho capito bene questa frase ... cosa intendi per bilanciamento delle richieste sul DNS, ipotizziamo che si abbia a disposizione la gestione DNS (tipica di aruba) ... al record www.miosito.it associo un IP pubblico che faccio arrivare ad una macchina nel CED (in teoria è il load balancer).

    E' qui che sbaglio ? Posso mettere più di un record www.miosito.it con un altro ip pubblico di un altro load balancer (posizionato altrove) ?


    ma parliamo di query , pesanti , cioè querry innestate , il cui tempo medio di risposta è ?

    oppure parliamo di numero di richieste al dabatase pesanti?.
    Dunque, la mia è una simulazione di fantasia, quindi non sto basando questi ragionamenti su un'applicazione esistente.

    Facciamo comunque un tempo di risposta medio di circa 0.5 - 0.8 secondi

    Le Query, in teoria non sono complesse, ipotizziamo una web app in stile ecommerce, c'è una ricerca effettuata su tabella items molto grande e successivamente il click su uno di questi per vederne i dettagli, query semplicissima con 5 o 6 JOIN al massimo, questo lato end-user. Poi c'è tutta la zona interna dove vengono creati nuovi articoli, preparate mail marketing, creare nuovi clienti, proporre preventivi, gestire gli ordini...

    Numero di richieste molto elevato, facciamo finta che sia un sistema centralizzato per le vendite online per un azienda e tutte le sue filiali (IKEA ?!?!), stimiamo circa 500 utenti che lavorano in backend, quindi creano gli articoli, gestiscono le fatture, gestiscono gli ordini e il magazzino ed in più un numero imprecisato (ma si spera mooolto alto) di utenti di frontend che visitano gli articoli e li acquistano con carrello elettronico.

    La parte più complessa la stimiamo nelle pagine di analisi interrogabili solo da alcuni utenti dell'azienda, dove si può ad esempio chiedere al sistema qual'è l'oggetto più cliccato, le categorie più ricche, l'utente che utilizza di più i servizi del sistema, il fatturato su un certo intervallo di tempo... ecc ecc ... Queste pagine possono richiedere anche più tempo a caricarsi, basta che non si vada oltre i 15 secondi (gli mettiamo una bella barra di avanzamento con AJAX e siamo a posto ).

    Bisogna puntare sul fatto che le pagine, qualunque si l'operazione, sia fatta con tempi di risposta buoni (non dico proprio come google che sembra imperturbabile in qualsiasi momento della giornata ma quasi) anche se il database prende il crescere.
    Inoltre, ovviamente, i servizi devono essere sempre disponibili.
    La fortuna favorisce la mente preparata

  4. #4
    vabbè contattami in privato e mi spieghi il tutto , mandami il tuo contatto di messenger
    www.danieleferrara.it sistemista /programmatore pagina personale
    www.e-sysadmin.com e-commerce informatico

  5. #5
    Utente di HTML.it L'avatar di albgen
    Registrato dal
    Jun 2005
    Messaggi
    3,249
    Ciao,
    perchè vuoi mettere server in città diverse?
    sai che costi di manutenzione hai? Considera in caso di guasto di uno di questi server.
    Poi fà conto, che per ogni città hai come minimo un server web e un mysql quando anche se il tuo sito ha 2000 utenti al minuto li tieni benissimo con 2 web server in load balancer e XX mysql sempre in load balancer.

    XX -> parti con 2 mysql, se senti delle lamentele sulla velocità aggiungi un altro e cosi' via...

    io non ti consiglio una soluzione con il dns. Poi prima dicevi di utilizzare in remoto dei db tramite il dns. Soluzione molto inefficiente.

    il load balancer dei mysql con cosa lo realizzi?
    I got the remedy

  6. #6
    albgen, ha ragione..sui costi di manutenzione...

    Da quello che io ho capito , si parte da un progetto grande anche in fase di realizzazione, ma ci vuole qualche informazioni in più.

    bisogna fare delle analisi su dati oggettivi.

    poi credo che Anuelicon, parlando di server in diverse sedi , distribuendo la sua base dati , avrà dei buoni motivi, perchè come accennava, albgen i costi sono enormi di realizzazione e di manutenzione.
    www.danieleferrara.it sistemista /programmatore pagina personale
    www.e-sysadmin.com e-commerce informatico

  7. #7
    Utente di HTML.it
    Registrato dal
    Mar 2005
    Messaggi
    317
    Ciao ... a tutti !!

    Mi ero quasi convinto che mettendo server in punti geografici diversi avrebbero distribuito meglio le richieste e quindi il carico.

    www.google.com digitato da un client qui in italia, dubito che risponda il server in California, mettendo anche solo un cluster in Europa ci gestisce lui le richieste in quanto il numero di HOP è sicuramente inferiore.

    Mi rendo conto che questo discorso si applica magari in continenti diversi e non in città Italiane ...
    Però c'è anche un discorso di banda ... tu dici, "quando lamentano un po di lentezza aggiungi un MySql server al cluster", ok, ma prima o poi bisogna fare i conti anche con la banda.

    Partiamo da una banda simmetrica di 2Mb/sec di MCR nella tua sede di milano ...

    Se tieni tutto centralizzato li prima o poi dovrai portare la tua 2 Mb a 4Mb e poi chissà ...

    mettiamo che tu abbia a disposizione una connessione di 1Mb/sec in una filiale di Bologna e una 2Mb/sec nella sede di Siena.

    con i server in più sedi non hai più autonomia ??? Se la tua sede risulta un po congestionata le richieste successive non possono essere servite dai server di bologna o siena che hanno ancora gran parte della banda a disposizione ???

    Altrimenti potremmo mettere tutti i nostri server in una server farm, paghiamo quello che dobbiamo pagare al mese o all'anno e non ci preoccupiamo più di banda. Che ne dite di questa scelta ?!??!

    Sul fatto della manutenzione sono pienamente d'accordo ... questo aggiunge punti sia alla soluzione centralizzata che mi dicevi che alla soluzione server farm ... altrimenti nella nostra simulazione potremmo risolvere mettendo un reparto tecnico in ogni sede che intervenga subito in caso di guasto, ma così mi sa che si complica un po troppo la cosa.

    Il load balancer mysql lo realizzo con debian Ultra Monkey - heartbeat e ldirectord.
    ... perchè sinceramente è l'unica soluzione che so fare in autonomia.
    La fortuna favorisce la mente preparata

  8. #8
    Non riusciamo a darti una soluzione..

    perchè parogoni una struttura Data-Center di google alla tua applicazione che pur grande che sia non ci viene quantificata in numeri.


    Scusami tu ci parli di grande progetto e poi lo vorresti fare con hdsl di 2 megabit?

    in più se tu facessi server distribuiti in varie città, dovresti creare canali sicuri (vpn) per la sincronizzazione delel base dati che ti rubano cmq banda.


    comprendo che forse non vuoi parlare del progetto in se, ma se mi contatti in privato e mi spieghi per bene la cosa ti posso dare un cosngilio.

    cmq la soluzione server-farm è una delle migliori anche per quando riguarda.. rischi e responsabilità di avere server in "casa".

    ma che stai fancedo qualche lavoro per il SISMI?
    www.danieleferrara.it sistemista /programmatore pagina personale
    www.e-sysadmin.com e-commerce informatico

  9. #9
    Utente di HTML.it L'avatar di albgen
    Registrato dal
    Jun 2005
    Messaggi
    3,249
    La banda deve essere 'ultimo dei tuoi problemi. Quando vedi che non ce la fà chiedi di più al tuo isp. Poi sinceramente, 2mb per 500 utenti sono molto pochi. Devi chiedere minimo un 8-10 mega in upload e sei già al limite. Significa che se tutti e 500 si collegano nello stesso momento, ogniuno ha a disposizione 20kbit e cioè meno di 3 kbyte al secondo! se per esempio hai una pagina da 30kbyte, e tutti la richiedono allo stesso momento(supponiamo che il db cè la fà) ci metteranno 10 secondi per scaricarla.
    Quindi come vedi, i conti per la banda si fanno in base al peso di una pagina web e gli utenti collegati.

    ma per la sincronizzazione dei dati come fai?

    mi sembra che mysql ha già una soluzione cluster...dovrebbe essere molto più robusta rispetto a vritual server + heartbeat...


    @daniele1980:
    per il bene della communità conviene che la discussione sia aperta a tutti quindi senza scambio di messaggio privati.
    I got the remedy

  10. #10
    Ciao albagen..
    hai ragione sul fatto che la discussione debba essere fatta sul forum , ma forse il progetto è talmente "segreto" che non lo può pronunciare , ho dato la mia disponibilità"

    cmq Mysql ha una osluzione clutser che ho realizzato, molto robusta.
    www.danieleferrara.it sistemista /programmatore pagina personale
    www.e-sysadmin.com e-commerce informatico

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.