IBM mi sembra orientata sulla seconda soluzione, cioè creare cluster di macchine. Tieni conto che i mainframe IBM da sempre permettono di far vedere ai SO solo parte dell'HW e quindi su un solo Mainframe fai girare diverse istanze di SO anche diversi, che comunque possono poi colloquiare fra loro o via rete (ovviamente virtuale) o se il SO lo permette via shared memory. IBM ha più volte dimostrato che al crescere del singolo sistema aumentano in modo esponenziale i tempi dedicati dal sistema a gestire se stesso. Cioè se la macchina è enorme e può fare un mucchio di cose, le code ad esempio del dispatcher diventano lunghissime e il tempo di percorrerle per decidere chi usa il prossimo time slice può diventare significativo. Inoltre più sono a lavorare e più cambi di contesto avvengono e anche questi sono tempi morti per l'utente finale. Oggi IBM propone sui grossi mainframe di frazionare l'HW in 32 partizioni con dentro 32 Linux che cooperano fra loro. Poi è possibile prendere fino ad 8 di queste macchine e farle lavorare come cluster. Ovviamente non parliamo di costi. :-( Quello che ottieni è una macchina completamente fault tolerance, con SO operativi dedicati a fare lavori specifici che però cambiano, nel senso che finita ad esempio una serie di transazioni oracle quel SO passa a fare transazioni apache eccetera. > Dicevo anche che probabilmente si finirà con una fork del kernel per > le macchine di fascia alta, a meno che nel frattempo le macchine di > fascia alta non vengano rimpiazzate da dei cluster di macchine di > fascia medio-bassa. -- Gelpi ing. Andrea -------------------------------------------------------------- It took the computing power of three C-64s to fly to the Moon. It takes a 486 to run Windows 95. Something is wrong here. -------------------------------------------------------------- -- Per iscriversi (o disiscriversi), basta spedire un messaggio con SOGGETTO "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxxxxxx