SeaMicro: 512 CPU Intel Atom in un singolo server

[lucusta]

Originariamente inviato da shodan

Tutto giusto, ma è altrettanto vero che si potrebbe ottenere più o meno lo stesso risultato con qualche macchina carrozzata a dovere e varie virtual machine sopra.

Anzi, si potrebbe pensare di non usare proprio virtual machine e di affidarsi alla multiutenza del sistema operativo (es: terminal server o X11).

Ciao.

quasi, shodan.
il tuo ragionamento funziona perfettamente nel momento in cui la rete e' unica e monotematica;
quando invece s'intrecciano diverse reti adibite a diversi ambiti (anche un'infrastruttura clone di un'altra ma con compiti diversificati, ad esempio produzione e sviluppo), non conviene avere una sola macchina a governare il tutto, perche' comunque si hanno layer separati, ed e' "di cattivo gusto" mischiarli.
in questo modo, invece, hai il modulo opetativo standard ( l'host ATOM), al quale puoi indirizzare la singola istanza, di qualsiasi natura essa sia e da qualsiasi ambito essa proviene, e farla operare disgiuntamente dagli altri moduli.
hai in pratica hardware monotipo su cui girano implementazioni differenziate e separate.
sinceramente pensavo all'azienda in cui lavoro, in cui s'intrecciano almeno 8 reti differenziate, e qualche miliaio di client, che, ora come ora, sono tutti client base ed operano in teminal web o in proprio.
il reale problema e' che se mi si scassa un terminal web di una delle reti che uso e al CED non ne hanno uno pronto per il rimpiazzo io sono costretto a spostarmi (poco male), ma se si rompe il mio client novell, su cui ho riversato tutto il mio lavoro... he.. la son dolori, perche' non m'importa della macchina di rimpiazzo, ma dei dati che ho temporaneamente storato sul client, che sono essenziali.
demandando tutto ad un datacenter ed a un terminal server come quello che si puo' infrastrutturare su una macchina del genere, al massimo collassano 8 macchine hardware di una scheda o uno dei terminali, non il mio lavoro.
certo e' che si tratta di soluzioni di nicchia, e bisogna naturalmente soppesare diversi aspetti per trovarne la reale convenienza.

[shodan]

Originariamente inviato da lucusta

quasi, shodan.
il tuo ragionamento funziona perfettamente nel momento in cui la rete e' unica e monotematica;
quando invece s'intrecciano diverse reti adibite a diversi ambiti (anche un'infrastruttura clone di un'altra ma con compiti diversificati, ad esempio produzione e sviluppo), non conviene avere una sola macchina a governare il tutto, perche' comunque si hanno layer separati, ed e' "di cattivo gusto" mischiarli.
in questo modo, invece, hai il modulo opetativo standard ( l'host ATOM), al quale puoi indirizzare la singola istanza, di qualsiasi natura essa sia e da qualsiasi ambito essa proviene, e farla operare disgiuntamente dagli altri moduli.
hai in pratica hardware monotipo su cui girano implementazioni differenziate e separate.
sinceramente pensavo all'azienda in cui lavoro, in cui s'intrecciano almeno 8 reti differenziate, e qualche miliaio di client, che, ora come ora, sono tutti client base ed operano in teminal web o in proprio.
il reale problema e' che se mi si scassa un terminal web di una delle reti che uso e al CED non ne hanno uno pronto per il rimpiazzo io sono costretto a spostarmi (poco male), ma se si rompe il mio client novell, su cui ho riversato tutto il mio lavoro... he.. la son dolori, perche' non m'importa della macchina di rimpiazzo, ma dei dati che ho temporaneamente storato sul client, che sono essenziali.
demandando tutto ad un datacenter ed a un terminal server come quello che si puo' infrastrutturare su una macchina del genere, al massimo collassano 8 macchine hardware di una scheda o uno dei terminali, non il mio lavoro.
certo e' che si tratta di soluzioni di nicchia, e bisogna naturalmente soppesare diversi aspetti per trovarne la reale convenienza.

Ciao,
certo la multiutenza proprio del s.o. va utilizzata con criterio e, laddove è necessario mantenere ambienti di esecuzione o policy di sicurezza separate, probabilmente non è così adatta.

Però ribadisco che il problema potrebbe risolversi alla radice con le virtual machine. Il ragionamento è questo:
- i normali server "carrozzati" spesso sono in idle
- il server SeaMicro è adatto quando ho molte istanze leggere da far girare
- quindi posso utilizzare i server di cui al punto n.1 per virtualizzare e aggregare così molte istanze del s.o. su poche macchine fisiche.

Sicuramente, se SeaMicro ha investito nell'ASIC e nella tecnologia di interfacciamente proprietaria, deve esserci un mercato per questa soluzione. Il punto è che questo mercato mi sembra abbastanza ristretto... poi libero di sbagliarmi eh

Ciao.