Se si rompe il server?

[nengistelle]

Salve, ho questo dilemma.Spesso faccio assistenza tecnica per i computer a una farmacia.Loro hanno un server in cui gira il software gestionle, poi varie postazioni (terminali e pc fissi) da cui accedono al server tramite desktop remoto.Il problema è che se il server si rompe, non possono usare il gestionale,quindi chiudono il negozio, non possono fare nulla,non funzionano nenache le casse.Mi hanno chiesto se posso trovare una soluzione a questa eventulità,ma io di server ci capisco poco.L'unica idea che mi è venuta è quella di comprare un'altro server identico a quello che c'è,e nel caso che si rompa, prendere l'hard disk e metterlo sull'altro server.E' fattibile come cosa o è una cavolata? Le altre aziende come fanno?
Grazie

[Billy-joe]

Ciao, ho poca esperienza nel campo (ci sto giocando ora con un serverino a casa), ma la soluzione più "veloce" secondo me è primo virtualizzare il server attuale ed installare come base vSphere, prendere un altro server ed installarci vSphere e fare una vMotion tra uno e l'altro in caso di guasto (dovrebbe essere un'operazione che fa lui in automatico.
Per l'hardware che ci vuole per fare tutto questo, attendo consiglio d'esperti.
Dovresti valutare attualmente però com'è il server, se ha già delle ridondanze (raid, NIC, Alimentazione etc etc) così da limitare il fermo in caso di guasto macchina. Iniziando comunque virtualizzando l'attuale server e facendo backup continui della VM ti inizia già a dare una sorta di sicurezza in più, così che in caso di guasto totale della macchina tu possa piazzare la VM su un altro pc e far girare temporaneamente il server limitando il fermo.

[nengistelle]

Grazie per le informazioni ,alla macchian virtuale non ci avevo proprio pensato.
Loro hanno un vecchio server,quello che c'era prima, in teoria posso far girare la macchina virtuale sul vecchio server?
mi spieghi meglio come funziona questo vsphere?
per loro i backup non sono fondamentali, il problema è che se il server si rompe chiudono il negozio perchè non possono usare il gestionale.

[nanotek]

Prima di buttare idee a caso (più che altro perchè ci sono tanti modi per risolvere un problema come questo) è bene rilevare la configurazione attuale del server. Poi si potrà iniziare a fare ipotesi più attinenti al caso.

[fally]

ma ti pagano pure per le tue "competenze"?

[nengistelle]

Il server attuale è un ibm con 2 alimentatori, 2 hard disk messi in raid 1,e tutti i pc si collegano al server con il desktop remoto.

[nanotek]

Modello ?
Processore ?
Ram ?
Spazio richiesto dal gestionale ? Quantità di dati conservata ?
Sistema operativo?
Da quanto è in funzione il server (e gli hd) ?

[nengistelle]

IBMx3400 M3 configurato con:

CPU Intel XEON QUAD-CORE - 16 GB RAM
HD in RAID1 550 GB in cui 1 in hotspare
Doppia ETHERNET 1000 Mbit
Doppio alimentatore

Attualmente sono conservati 80gb di dati, il gestionale ne occupa circa 30 gb

[Shinobi]

Ciao, per farsi un'idea del tutto servono più informazioni:

-Il server attuale ha un contratto di manutenzione attiva? Se si, di che tipo?
-Quanto è tollerabile per loro un eventuale fermo macchina? Minuti, ore o giorni?
-C'è un sistema di backup attualmente funzionante?
-Budget messo a disposizione?

Sono stati citati soluzioni come vmotion ma soluzioni di questo tipo hanno un costo non leggero (licenze apposite vsphere, doppio server, storage etc.)

[Shinobi]

per loro i backup non sono fondamentali, il problema è che se il server si rompe chiudono il negozio perchè non possono usare il gestionale.

Mi era sfuggita questa frase: conta che se hai dei backup validi puoi ripristinare il tutto (è solo questione di riparare l'hardware o comprarne di nuovo) ma anche se virtualizzi/hai hardware ridondato rimani in braghe di tela senza backup.

Conta che i backup ti servono anche nel caso in cui il server non abbia problemi ma ci siano problemi a livello logico (per esempio il database del gestionale che si corrompe), è la base da cui partire.

[nengistelle]

Se loro stanno fermi un giorno,perdono circa 4000 euri,quindi anche stare fermi 10 minuti un costo non indifferente.
Un sistema di backup è funzionante.
Si,hanno un contratto di assistenza, però non so di preciso di che tipo.
Ripeto, stare fermi anche 10 minuti per loro è un costo.
Budget 1500 euri
loro hanno una persona che gli fa assistenza per il gestionale, quindi a me questo non interessa,almeno non direttamente

[JackLayne]

Se loro stanno fermi un giorno,perdono circa 4000 euri,quindi anche stare fermi 10 minuti un costo non indifferente.
Un sistema di backup è funzionante.
Si,hanno un contratto di assistenza, però non so di preciso di che tipo.
Ripeto, stare fermi anche 10 minuti per loro è un costo.
Budget 1500 euri
loro hanno una persona che gli fa assistenza per il gestionale, quindi a me questo non interessa,almeno non direttamente

Si ma devi capire meglio quale è la situazione generale se vuoi capire come affrontare la problematica.. hanno un contratto dimanutenzione, ma come? assistenza in quanto? 4 ore? NBD?

Considerando che hai due alimentatori e un RAID 1, puoi gestire tranquillamente guasti di un disco e un alimentatore.. il guasto potrebbe ad esempio essere una scheda madre, in quel caso devi capire in quanto intervengono.. VMware è una possibile soluzione, ma tutto ha un costo.. con 1500 euro non ci fai molto in quel caso.. Potresti anche mettere su un server secondario, ovviamente non di quelle prestazioni, giusto per tamponare in attesa del tecnico.. ma ti ripeto, per capire come gestire la cosa devi avere un quadro migliore della situazione..

[nengistelle]

Mi informo meglio su alcuni dettagli.
In linea di massima, quali sono le soluzioni anche temporanee?
Una è la virtualizzazione,altre?
La mia teoria di comprare un server identico, e poi spostarci l'hard disk è fattibile o una cavolata?

[nanotek]

La mia teoria di comprare un server identico, e poi spostarci l'hard disk è fattibile o una cavolata?

Fattibile ma già il server identico mi sembra che sia overbudget :D

[nengistelle]

Per esempio le banche come fanno? Si possono sincronizzare 2 server?

[conzi]

con 1500€ non cambi di molto la situazione.
virtualizza il server fisico e vai di snapshot frequenti durante il giorno.
ah, tieni di scorta un'altra macchina nel caso si rompesse la prima

[Dane]

Per esempio le banche come fanno? Si possono sincronizzare 2 server?

Te l'hanno già spiegato.
Non hanno un budget di 1500 euro.

Oltre che backup e/o repliche sincrone/semisincrone geografiche spesso hanno san da decine di migliaia di euro (ridondate a vari livelli).

A meno che i tempi di ripristino siano stringenti come dici, al posto tuo cercherei di concordare un fermo di mezza giornata. Vuol dire che devi mettere su un sistema di backup funzionante, testarlo regolarmente ed infine tu devi essere pronto in un qualsiasi momento ad intervenire.
Scommetto che i backup (se vengono fatti) non vengono portati via. In caso di furto del server rimangono con carta e penna.... E' l'occasione per mettere mano anche a questo.

Un'altra soluzione, non economica, sarebbe di spostare il gestionale in cloud. Scegliendo bene puoi ridurre di molto la probabilità fermo causato dal fermo macchina. Ma se rimangono senza internet: carta e penna.

Una terza possibilità è di aggiungere un secondo server. Poi fare la replica di tutta la VM, o fare una replica a livello applicativo (ovvero database, dati, ecc).

Non sono soluzioni economicamente leggere, nè tecnicamente facili.
Occhio che mettergliela in piedi spesso vuol dire anche garantirla!

[alex87alex]

Il mio approccio sarebbe:
- Compri un serverino con prestazioni più scarse di quello attuale per usarlo come tampone
- Migri tutto il sistema su questo serverino
- Cerchi una soluzione che faccia i dump dei databases sul server attuale, li invii al serverino e li carichi ogni giorno.. (se fosse ospitato su un server linux basterebbe un semplice script: mysqldump ---> rsync ---> drop ---> mysqldump )
- Se dovesse succedere il guasto crei un'icona su ogni client che punti all'applicativo gestionale con l'indirizzo ip dell'altro server, così non perdono nemmeno un minuto di lavoro. Basta che fai loro un minimo di formazione dicendogli di fare attenzione all'icona che cliccano....

Per me è la soluzione meno dispendiosa in termini di tempo/risorse...

[nengistelle]

Innanzitutto vi grazio a tutti per le info che mi avete dato, le mie conoscenze in abito server sono molto limitate,però si puo sempre iniziare ad imparare.
Come faccio a migrare tutto il sistema su un'altro server?
Girovagando su Internet ho trovato dei server identici a quello che hanno a costi ridicoli, tipo 500-600 euri, hanno meno ram e hard disk meno capienti ma per una soluzione temporanea vanno più che bene.Tenete conto che parliamo di una farmacia, con collegati 15 pc,quindi non ho il server di Google, il sever che avevano prima era del 1998 e non avevano problemi.

[nanotek]

Tenete conto che parliamo di una farmacia, con collegati 15 pc

Una farmacia molto grossa a vedere il numero di client!
Sicuro che accedono in desktop remoto ? O ogni client esegue l'interfaccia del gestionale ?
Come so cosa usa? windows server 2008 ?

[nengistelle]

Tutti accedono al server con il desktop remoto, e poi ognuno apre il gestionale e fa quello che deve fare.Hanno windows server 2008.
Il gestionale è installato solo sul server, per questo se il server si rompe non possono andare avanti neanche con le casse.
Infatti, io gli avevo proposto come soluzione di mettere 5 pc collegati alle casse con il gestionale installato su ogni singolo pc,così se il server non funzionava usano il gestionale di ogni singola cassa.
Però ,non mi ricordo, ma non si poteva fare.

[alex87alex]

Innanzitutto vi grazio a tutti per le info che mi avete dato, le mie conoscenze in abito server sono molto limitate,però si puo sempre iniziare ad imparare.
Come faccio a migrare tutto il sistema su un'altro server?
Girovagando su Internet ho trovato dei server identici a quello che hanno a costi ridicoli, tipo 500-600 euri, hanno meno ram e hard disk meno capienti ma per una soluzione temporanea vanno più che bene.Tenete conto che parliamo di una farmacia, con collegati 15 pc,quindi non ho il server di Google, il sever che avevano prima era del 1998 e non avevano problemi.Non conosco le procedure di migrazione di win server 2008, ma con linux è un comando (dd if=/dev/sda of=/path/backup.img). Aspettiamo gli esperti microsoft, ma penso ci sia uno strumento simile (o almeno spero per te :D )

[nengistelle]

Domani vado in farmacia e mi informo meglio.
Il server ha un hard disk in hotswap, quindi,se il server si rompe, tolgo questo hard disk e lo metto sull'altro server identico, e passa la paura?
Se sì.mi sembra la soluzione più economica (sotto i 1000 euri) e anche la più semplice e veloce.

[alex87alex]

Domani vado in farmacia e mi informo meglio.
Il server ha un hard disk in hotswap, quindi,se il server si rompe, tolgo questo hard disk e lo metto sull'altro server identico, e passa la paura?
Se sì.mi sembra la soluzione più economica (sotto i 1000 euri) e anche la più semplice e veloce.Si, se gli hd rimangono buoni. Nell'eventualità che si sputtanino che succederebbe?

[nanotek]

con linux è un comando (dd if=/dev/sda of=/path/backup.img)
Così fai solo un'immagine del disco che hai. Devi anche ripristinare il sistema sull'altro disco.
Il tutto è semplice se il sistema funziona. Se non funziona i tempi si allungano...

[Dane]

Si, se gli hd rimangono buoni. Nell'eventualità che si sputtanino che succederebbe?

idem se il controller del server sostitutivo non "digerisce" i dischi del server rotto, che aveva un'altro controller.


....tanto per fare un'altro esempio.

[alex87alex]

Così fai solo un'immagine del disco che hai. Devi anche ripristinare il sistema sull'altro disco.
Il tutto è semplice se il sistema funziona. Se non funziona i tempi si allungano...Ovvio, un comando sul server attuale e un comando opposto sul server target :) Pensavo si fosse capito :D

Poi ovviamente bisogna farlo ADESSO che il server funziona, non ha senso farlo dopo. Per i db del gestionale basta un dump e un restore giornaliero :)

[h4xor 1701]

io sono pro virtualizzazione, ma utilizzare vSphere per una cosa simile mi sembra assai sprecato (e costoso), quello che ti consiglio io è virtualizzare l'attuale sistema e tenerlo con una licenza minima di VMWare ESX sul server di produzione...mentre ne tieni un altro a prestazioni ridotte con installata la licenza free di ESX (controlla se è possibile per usi commerciali) e lo spostamento della VM lo puoi fare tu a mano....così abbatti i costi.....oppure alle brutte puoi sempre accorrere tu con un portatile con installato vmware ed eseguire win server direttamente da li in questo modo :D :D :D

[Kaya]

Buongiorno, leggo solo ora e vedo davvero TANTA confusione.

Come già scritto, è necessaria prima una analisi dello stato attuale della rete.
Inoltre la parte "dei backup non mi interessa" mi ha lasciato di ghiaccio: poni per esempio che ti si brucino entrambi gli hard disk, cosa fai?
Ricostruisci a mano tutto il database con i prodotti presenti a magazzino? E visto che è collegato alle casse immagino gestisca anche la contabilità; se si presenta la GDF per un controllo rispondi che "tanto il backup non interessa"?

Tornando al tuo problema, la soluzione di "un server identico" è fattibile.
Verifica però le criticità come il fatto che il gestionale non sia legato a codici di attivazione legati all'hardware (ad es. il mac address del server)
Inoltre considera che, avendo di mezzo un raid, lo spostamento dei dischi su un secondo server potrebbe lanciare la procedura di ricostruzione del raid, e se per caso uno dei due dischi a problemi potrebbe fare più danni che altro.

La virtualizzazione potrebbe essere una soluzione più fattibile.

Prendi un altro server, ci installi un virtualizzatore (proxmox ad esempio) e fai una migrazione phisical to virtual. Verifichi che la VM giri senza problemi e poi installi sul server originale lo stesso virtualizzatore e li metti in cluster.
Evita la migrazione automatica delle VM in caso di guasto, potrebbe essere più un problema che una soluzione.

Inoltre ricorda che devi regolarizzare le licenze di Windows in ogni caso.

Un paio di risposte sparse:
il comando
dd if=/dev/sda of=/path/backup.img
funziona ma anche no. Nel caso sul server ci sia un database, la copia del file puro potrebbe generare dei casi di inconsistenza dello stesso e quindi renderlo in accessibile. Il dump è più corretto

Dubito che il gestionale si possa installare sui singoli client: sicuramente si affacciano al database e quello risiede sul server. Anche installassi il gestionale in giro, non avrebbe più modo di comunicare col DB se il server si spegne

I backup FALLI, e sopratutto non fidarti di usare i dischi esterni per i backup, specialmente se nello stesso locale server

[komodo_1]

Potresti virtualizzare il server originale e poi installarci sopra esxi senza licenza.
Lo stesso potresti fare sul nuovo serverino di backup
Non ricordo se con la licenza free puoi scaricarlo ed utilizzarlo sui due host, ma eventualmente c'è un appliance, vmware data recovery mi pare si chiami, che si occupa dei backup delle vm.
Qualora non utilizzabile, si possono pensare altre soluzioni più artigianali.
Comunque sia, se alla fine sfrutterai vmware, ti sconsiglio vivamente di usare gli snapshot per fare i backup in quanto lo snapshot implica poi la crescita esponenziale del disco.

In alternativa a vmware, volendo e potendo smanettare un po', esistono tanti altri hypervisor free (kvm, oraclevm, proxmox, ecc)
Come ti dicevano prima, dipende un po' da vari fattori (budget, competenze, tempo...)

Per il porting del solo applicativo su altra piattaforma, dipende molto dal/dai prodotti coinvolti

Ciao

[alex87alex]

Un paio di risposte sparse:
il comando
dd if=/dev/sda of=/path/backup.img
funziona ma anche no. Nel caso sul server ci sia un database, la copia del file puro potrebbe generare dei casi di inconsistenza dello stesso e quindi renderlo in accessibile. Il dump è più correttoMi spiego meglio, forse non sono stato chiaro fin dall'inizio:
la procedura corretta sarebbe:
1) dump tutti database su supporto esterno
2) dd con clonezilla o simili di backup
3) dd con clonezilla o simili di restore sulla macchina target
4) drop dei db sulla macchina target
5) mettere i db backuppati

Forse il malinteso nasce dall'aver scritto questa procedura in due post separati. Comunque ora ci siamo capiti :)

In un mondo ideale sarebbe stato bello avere il server pronto per il gestionale, senza dati, backuppato e messo da parte per un possibile ripristino futuro, ma chi c'è stato prima di lui nemmeno si sarà posto il problema:rolleyes:

Dubito che il gestionale si possa installare sui singoli client: sicuramente si affacciano al database e quello risiede sul server. Anche installassi il gestionale in giro, non avrebbe più modo di comunicare col DB se il server si spegne

Dipende dal tipo di gestionale, quello che ho a lavoro per esempio si connette al server tramite un collegamento sul desktop ad un applicativo java remoto che prende diversi parametri tra cui la directory di java, l'indirizzo ip del server e l'utente che lo sta usando. Va da se che creare un collegamento con un indirizzo del server diverso significa cambiare un numero nel collegamento e cambiare icona :D Dipende, ho dato uno spunto senza sapere cosa realmente sia questo "gestionale della farmacia"

[nanotek]

Dipende dal tipo di gestionale, quello che ho a lavoro per esempio si connette al server tramite un collegamento sul desktop ad un applicativo java remoto che prende diversi parametri tra cui la directory di java, l'indirizzo ip del server e l'utente che lo sta usando. Va da se che creare un collegamento con un indirizzo del server diverso significa cambiare un numero nel collegamento e cambiare icona Dipende, ho dato uno spunto senza sapere cosa realmente sia questo "gestionale della farmacia"

Non mi piacciono i gestionali fatti in quel modo. E' un'architettura client - server farlocca. Il client deve essere eseguito indipendentemente dal server ed eseguire l'interfaccia. Per tutte le richieste di dati si connette al server e il server gli dà una risposta. In questo modo c'è da impostare solo l'ip del server (e la porta a cui connettersi).
Diverso è il discorso del desktop remoto..buona l'idea così si lavora solo sul server.. però spesso la realizzazione è pessima ( si vedono pc con i5 solo per connettersi a desktop remoti..)

[Tasslehoff]

Buongiorno, leggo solo ora e vedo davvero TANTA confusione.Quoto.
Però c'è un problema di base in tutta questa faccenda, non fraintendermi nengistelle ma una architettura che possa garantire continuità di servizio anche in caso di guasto non è uno scherzo da implementare e nemmeno da manutenere.
Le soluzioni possibili sono diverse, alcuni generiche che fanno bene in quasi ogni caso (es cluster attivo/passivo), altre vanno bene in altre casistiche (es virtualizzazione con vmotion), altre in casi specifici più ristretti (es clustering applicativo).

Tutte queste casistiche però richiedono delle competenze specifiche e una conoscenza piuttosto dettagliata del prodotto che utilizzate, della sua architettura, della logica con cui lavora.
Con tutto il rispetto (e per tua stessa ammissione) a me non sembra che tu abbia chiaro cosa comportano queste soluzioni, ne tantomeno come implementarle, per cui io mi sentirei di consigliarti di chiedere a una società che fornisca servizi IT nella tua zona di fare una analisi e una quotazione.

Quoto Kaya anche sui backup, la stragrande maggioranza dei ripristini dai backup non sono certo innescati da catastrofi naturali, furti o incendi, ma da puri e semplici errori umani, cancellazioni di dati non volute, sovrascritture etc etc...
Tutte le architetture ridondate di questo mondo non potranno MAI e poi MAI proteggerti da queste casistiche, solo un backup può farlo.
Quindi l'eventuale soluzione di cluster che eventualmente deciderete di implementare non può assolutamente fare a meno di un backup fatto con tutti i crismi, e questo significa fatto tenendo conto delle specificità del prodotto che usate.

[komodo_1]

Concordo su tutti i fronti :)
Quoto.
Però c'è un problema di base in tutta questa faccenda, non fraintendermi nengistelle ma una architettura che possa garantire continuità di servizio anche in caso di guasto non è uno scherzo da implementare e nemmeno da manutenere.
...snip...
Quindi l'eventuale soluzione di cluster che eventualmente deciderete di implementare non può assolutamente fare a meno di un backup fatto con tutti i crismi, e questo significa fatto tenendo conto delle specificità del prodotto che usate.

[alex87alex]

Non mi piacciono i gestionali fatti in quel modo. E' un'architettura client - server farlocca. Il client deve essere eseguito indipendentemente dal server ed eseguire l'interfaccia. Per tutte le richieste di dati si connette al server e il server gli dà una risposta. In questo modo c'è da impostare solo l'ip del server (e la porta a cui connettersi).
Diverso è il discorso del desktop remoto..buona l'idea così si lavora solo sul server.. però spesso la realizzazione è pessima ( si vedono pc con i5 solo per connettersi a desktop remoti..)
Ci sono pro e contro di ogni soluzione. Da noi era fondamentale quell'approccio perchè un server decente accoppiato a client pessimi dà sempre buone prestazioni. Lavoriamo per la pubblica amministrazione, quindi di p4 ne vedo a bizzeffe :D

[nanotek]

Ci sono pro e contro di ogni soluzione. Da noi era fondamentale quell'approccio perchè un server decente accoppiato a client pessimi dà sempre buone prestazioni. Lavoriamo per la pubblica amministrazione, quindi di p4 ne vedo a bizzeffe :D

Allora lo scenario giustifica l'uso del desktop remoto o l'uso di una applicazione per cui i client visualizzano solo l'interfaccia (per questo vanno tanto le web app). Client scarsi e quindi fanno solo da terminali.
Mi metto invece a ridere quando vedo dei pc nuovissimi equipaggiati di i5, 8 gb ram e hd da 1Tb a fare da terminale per il desktop remoto.

[alex87alex]

Allora lo scenario giustifica l'uso del desktop remoto o l'uso di una applicazione per cui i client visualizzano solo l'interfaccia (per questo vanno tanto le web app). Client scarsi e quindi fanno solo da terminali.
Mi metto invece a ridere quando vedo dei pc nuovissimi equipaggiati di i5, 8 gb ram e hd da 1Tb a fare da terminale per il desktop remoto.Sfortunatamente abbiamo a che fare sempre più spesso con amministratori incompetenti/svogliati, pc preistorici e connessioni lentissime anche in gigabit :D