Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.retrocomputing > #48615 > unrolled thread

uptime: 24 anni :)

Back to article view | Back to it.comp.retrocomputing

Contents

  uptime: 24 anni :) zfkirone <zfkirone@gmail.com> - 2017-01-29 12:52 +0100
    Re: uptime: 24 anni :) zfkirone <zfkirone@gmail.com> - 2017-01-29 13:22 +0100
    Re: uptime: 24 anni :) G. <gerry77@no.spam.mail.com> - 2017-01-29 17:33 +0100
      Re: uptime: 24 anni :) Fabio Bizzi <fbizzi@bizzi.org> - 2017-01-30 09:31 +0100
        Re: uptime: 24 anni :) tony pedi <tonyTOGLIMI.pediTOGLIPUREQUESTO@libero.it> - 2017-02-07 19:28 +0100
      Re: uptime: 24 anni :) zfkirone@gmail.com - 2017-01-30 09:19 -0800
        Re: uptime: 24 anni :) Lead_Oxide <lead@tin.it.invalid> - 2017-01-30 22:33 +0100
        Re: uptime: 24 anni :) G. <gerry77@no.spam.mail.com> - 2017-01-31 13:01 +0100
      Re: uptime: 24 anni :) nez.geo@getitoutyahoo.com (nda) - 2017-02-11 12:22 +0100
    Re: uptime: 24 anni :) GIulia <far593@iperbole.bologna.it> - 2017-01-29 18:45 +0100
      Re: uptime: 24 anni :) zfkirone@gmail.com - 2017-01-30 09:26 -0800

#48615 — uptime: 24 anni :)

http://www.computerworld.com/article/3162416/data-center/booted-up-in-1993-this-server-still-runs-but-not-for-much-longer.html

Server Stratus (mai sentito) con componenti ridondati (ossia, se si 
guasta un pezzo c'è il gemello che tiene su la baracca, al che puoi 
cambiare (immagino hotwsap) quello guasto).

Sistema operativo proprietario VOS (mai sentito manco questo)

Ad Aprile lo mettono a nanna per upgrade, RIP

CYA

[toc] | [next] | [standalone]

#48616

Scusate, l'oggetto è fuorviante, dall'articolo si evince che qualche 
shutdown pianificato l'hanno fatto ^_^;;


CYA

[toc] | [prev] | [next] | [standalone]

#48618

On Sun, 29 Jan 2017 12:52:22 +0100, zfkirone <zfkirone@gmail.com> wrote:

> http://www.computerworld.com/article/3162416/data-center/booted-up-in-1993-this-server-still-runs-but-not-for-much-longer.html
> 
> Server Stratus (mai sentito) con componenti ridondati (ossia, se si 
> guasta un pezzo c'è il gemello che tiene su la baracca, al che puoi 
> cambiare (immagino hotwsap) quello guasto).
> 
> Sistema operativo proprietario VOS (mai sentito manco questo)

È roba poco nota perché parecchio costosa e abbastanza di nicchia. Un altro
esempio del genere è il buon vecchio NonStop della Tandem (e già i nomi sono
indicativi della filosofia che ci sta dietro) che ora è della HP.

Detto questo, anche il più noto e diffuso VMS può fare qualcosa del genere,
nonostante sia disaster tolerant ma non fault tolerant. La differenza c'è ed
è importante. Un sistema fault tolerant è tutto ridondato e non si ferma se
una sua parte si guasta: "non si ferma" significa che il software neppure si
accorge di quel che è successo (a parte il sistema operativo). Un sistema
disaster tolerant invece si ferma, ma poi riparte quasi subito da dove era
rimasto conservando non solo tutti i dati, ma anche tutte le transazioni in
corso che quindi possono essere tutte riportate a uno stato noto.

Caso tipico di VMS è quello di due nodi in cluster a distanza geografica, il
primo dei quali subisce un disastro mentre il secondo sopravvive: in un
tempo variabile fra 30 secondi e 3 minuti il cluster si riconfigura da solo
e tutto riprende da dov'era rimasto. Chiaramente molto dipende anche dagli
scenari: ovvio che un terminale seriale collegato direttamente a un nodo, se
quel nodo "muore", perderà la connessione e rimarrà isolato, ma già in caso
di collegamento tramite terminal server verrebbe automaticamente rediretto
al nodo superstite (30 secondi circa di timeout), però l'utente dovrebbe in
ogni caso verosimilmente rifare login.

Se al caso di cui sopra si aggiunge un ulteriore strato software per fare un
ulteriore "disaccoppiamento" dall'hardware, per esempio con un ambiente di
tipo client-server, oppure con un transaction manager che "conosce" ciascun
terminale per nome (e.g. singola porta sul singolo terminal server), ecco
che l'utente dopo una breve interruzione potrebbe rivedere lo stesso video
su cui stava lavorando al momento del guasto, forse addirittura con i campi
che aveva già compilato riproposti nello stato in cui erano.

Tutto dipende da quanto si vuole spendere e dal tipo di continuità che si
deve avere: ci si può permettere un'interruzione di qualche minuto? si può
perdere una pagina di dati inseriti a mano? Si può rifare una transazione
annullata? Ha senso spendere tanti soldi per annullare il downtime?

Più o meno dello stesso genere sono (erano) anche Sun Cluster e TruCluster.

VMS permette di fare l'upgrade hardware e software di un nodo per volta, o
anche di più nodi, l'importante è che la maggioranza dei voti del cluster
sia sempre disponibile. In questo modo, anche se le singole macchine vengono
riavviate spesso, il cluster come entità può sopravvivere per decenni, il
che non è una cosa solo "formale", ma significa che non si è mai interrotta
la capacità di elaborazione.

È esistita anche una versione fault tolerant, il VAXft, che però non ha mai
avuto grande successo e che curiosamente si raccomandava non venisse usata
in cluster perché i timeout del cluster, per quanto brevi, avrebbero potuto
rallentare le risposte del sistema fault tolerant.

Da questo ne discende che era fault tolerant, ma non disaster tolerant, o
alameno credo, e credo anche che non fosse l'unico. Forse anche lo Stratus
di cui sopra è così, se è tutto contenuto in un unico data center...

Scusate il "pippone", avevo voglia di scrivere :)

Ciao,
G.

[toc] | [prev] | [next] | [standalone]

#48620

Il giorno Sun, 29 Jan 2017 17:33:24 +0100
G. <gerry77@no.spam.mail.com> ha scritto:

> 
> È roba poco nota perché parecchio costosa e abbastanza di nicchia. Un
[...]
> 
> Scusate il "pippone", avevo voglia di scrivere :)
> 
> Ciao,
> G.
> 

Scusate? Semmai GRAZIE!!!! :)

-- 
member of the italian hobbyist DECnet network - HOBBIT

[toc] | [prev] | [next] | [standalone]

#48653

Il 30/01/2017 09:31, Fabio Bizzi ha scritto:
> Il giorno Sun, 29 Jan 2017 17:33:24 +0100
> G. <gerry77@no.spam.mail.com> ha scritto:
>
>>
>> È roba poco nota perché parecchio costosa e abbastanza di nicchia. Un
> [...]
>>
>> Scusate il "pippone", avevo voglia di scrivere :)
>>
>> Ciao,
>> G.
>>
>
> Scusate? Semmai GRAZIE!!!! :)
>

mi hai tolto le parole da sotto i tasti ;-) :-)

[toc] | [prev] | [next] | [standalone]

#48621

Il giorno domenica 29 gennaio 2017 17:33:25 UTC+1, G. ha scritto:

[snip]
> Scusate il "pippone", avevo voglia di scrivere :)

Beh, a me hai fatto venir voglia di leggere :D

CYA

[toc] | [prev] | [next] | [standalone]

#48623

Il 30/01/2017 18:19, zfkirone@gmail.com ha scritto:
> Il giorno domenica 29 gennaio 2017 17:33:25 UTC+1, G. ha scritto:
>> Scusate il "pippone", avevo voglia di scrivere :)
>
> Beh, a me hai fatto venir voglia di leggere :D

Anche a me :)

[toc] | [prev] | [next] | [standalone]

#48625

On Mon, 30 Jan 2017 09:19:16 -0800 (PST), zfkirone@gmail.com wrote:

> Beh, a me hai fatto venir voglia di leggere :D

Grazie :)

In realtà rileggendomi mi rendo conto di aver fatto un po' di "mischione"
fra VMS che è un sistema operativo, il relativo cluster (VMScluster) che è
una funzione aggiuntiva offerta dall'OS, e uno strano animale come il VAXft
che era una soluzione hardware basata su processori VAX che poi non ha più
avuto seguito perché il mercato si è mostrato poco interessato.

Diciamo che VMScluster (un tempo VAXcluster) è sempre stato considerato il
fiore all'occhiello di VMS, o per lo meno quello più evidente e "mitico", a
cui poi si sono ispirati gli altri produttori, non tanto nel senso che
abbiano copiato, quanto nel senso che si siano dovuti adeguare a un "golden
standard" stabilito dalla Digital.

Del resto anche TruCluster, cioè il cluster per Tru64 (quindi Digital anche
lui), pur essendo nato nella stessa casa è piuttosto diverso e per certi
versi pure più potente e moderno, visto che è venuto dopo. Un altro del
genere è (era) Sun Cluster, poi sono venuti i "nuovi cluster" tipo Beowulf e
Mosix che si basano su una filosofia diversa e hanno scopi diversi.

Alla fine tutti i cluster sono nati per lo stesso motivo: perché una sola
macchina non era più sufficiente. I cluster più "tradizionali" tipo quello
di VMS hanno un occhio più rivolto alla continuità e sono generalmente di
tipo loosely coupled, cioè macchine relativamente autonome e distinte anche
per l'utente finale. Viceversa i cluster più "nuovi" sono più orientati
verso la potenza di calcolo e sono generalmente più di tipo tightly coupled,
cioè appaiono all'utente come un unico sistema più grosso e somigliano di
più all'idea che abbiamo oggi di un supercomputer.

Il fatto è che nella definizione di cluster ormai rientra tanta di quella
"roba" che è difficile dire cosa sia davvero un cluster e cosa no. L'unica
cosa certa è che un cluster è fatto da più sistemi che fanno "cose" in
comune a un livello meno stretto della singola macchina con più CPU in SMP.

Poi va be', oggi sono cambiate le esigenze e i cluster del primo tipo non
sono più diffusi e di "moda" come una volta, infatti non se ne sente parlare
quasi più. Ormai la singola macchina è diventata così potente e affidabile
da rendere il più delle volte un cluster non necessario, fatti salvi i casi
in cui più che la continuità è richiesto il supercalcolo.

Comunque, a proposito di uptime:

| OpenVMS V8.3  on node Hxxxxx  31-JAN-2017 12:51:51.53  Uptime  1944 17:30:04

1944 giorni, cioè cinque anni, tre mesi e venticinque giorni :)

E infine, per ritornare un po' in tema con il topic del gruppo, qui tempo fa
c'era parecchia gente (me compreso) che si dilettava con VMS e altre simili
amenità, anche in cluster. Chissà dove sono spariti tutti quanti... 8-)

Ciao,
G.

[toc] | [prev] | [next] | [standalone]

#48659

G. <gerry77@no.spam.mail.com> wrote:

> avevo voglia di scrivere :)

È sempre un piacere. :)

-- 
Nicola D'Agostino
<!-- http://www.nicoladagostino.net -->
<!-- http://www.storiediapple.it -->

[toc] | [prev] | [next] | [standalone]

#48619

zfkirone wrote:
> http://www.computerworld.com/article/3162416/data-center/booted-up-in-1993-this-server-still-runs-but-not-for-much-longer.html
>
> Server Stratus (mai sentito) con componenti ridondati (ossia, se si guasta un pezzo c'è il gemello che tiene su la baracca, al che puoi cambiare (immagino
> hotwsap) quello guasto).
>
> Sistema operativo proprietario VOS (mai sentito manco questo)
>
> Ad Aprile lo mettono a nanna per upgrade, RIP

Comunque qualunque cosa lontanamente collegata alla rete nel 2017 deve subire volente o nolente aggiornamenti firmware/SO/software.
Io definirei l'uptime in modo differente a questo punto, un reboot software schedulato pur resettando il contatore di uptime del SO lo vedrei
come una continuita del servizio visto che e'  gestito dal SO che fa sostanzialmente una chiamata volontaria alla routine di reset e riparte da dove si era fermato.

Giulia

[toc] | [prev] | [next] | [standalone]

#48622

Il giorno domenica 29 gennaio 2017 18:45:35 UTC+1, GIulia ha scritto:


> Io definirei l'uptime in modo differente a questo punto, un reboot software schedulato pur resettando il contatore di uptime del SO lo vedrei
> come una continuita del servizio visto che e'  gestito dal SO che fa sostanzialmente una chiamata volontaria alla routine di reset e riparte da dove si era fermato.

Su Linux esiste una variante di uptime che non si azzera al riavvio.
da una ricerchina trovo tuptime, ma forse ce n'è altri...
http://www.tecmint.com/find-linux-uptime-shutdown-and-reboot-time-with-tuptime/

CYA

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.retrocomputing

csiph-web