Domande sul singolo punto di errore per le piccole operazioni

1. Se non puoi permetterti o non hai bisogno di un cluster o di un server di riserva in attesa di essere online in caso di guasto, sembra che potresti dividere i servizi forniti da un server robusto su due server meno robusti. Pertanto, se il server A si arresta, i client potrebbero perdere l'accesso, ad esempio la posta elettronica, e se il server B non funziona, potrebbero perdere l'accesso al sistema ERP .

   Mentre all'inizio sembra che sia più affidabile, non aumenta semplicemente la possibilità di guasti hardware? Quindi, ogni singolo fallimento non avrà un impatto così grande sulla produttività, ma ora ti stai preparando per il doppio degli errori.

   Quando dico "meno robusto", ciò che intendo veramente è una specifica di componente inferiore, non di qualità inferiore. Quindi una specifica della macchina in uscita per la visualizzazione contro due server specificati per meno carico ciascuno.

2. Spesso si consiglia una SAN in modo da poter utilizzare il clustering o la migrazione per mantenere i servizi attivi. Ma che dire della stessa SAN? Se dovessi investire denaro nel luogo in cui si verificherà un errore, non si troverà sull'hardware di base del server, ma avrà qualcosa a che fare con l'archiviazione. Se non si dispone di una sorta di SAN ridondante, quei server ridondanti non mi darebbero un grande senso di fiducia. Personalmente per una piccola operazione sarebbe più sensato per me investire in server con componenti ridondanti e unità locali. Vedo un vantaggio in operazioni più grandi in cui il prezzo e la flessibilità di una SAN sono convenienti. Ma per i negozi più piccoli non vedo l'argomento, almeno non per la tolleranza agli errori.

Tutto ciò si riduce alla gestione del rischio. Fare un'analisi dei costi / rischi adeguata dei sistemi IT ti aiuterà a capire dove spendere i soldi e con quali rischi puoi o devi affrontare. C'è un costo associato a tutto ... questo include HA e tempi di inattività.

Lavoro in un posto piccolo, quindi capisco questa lotta e il fanatico dell'IT in me non vuole nessun singolo punto di errore da nessuna parte, ma il costo per farlo ad ogni livello non è un'opzione realistica. Ma qui ci sono alcune cose che sono stato in grado di fare senza avere un budget enorme. Questo non significa sempre rimuovere il singolo punto di errore.

Network Edge : abbiamo 2 connessioni Internet a T1 e Comcast Business. Progettando di spostare il nostro firewall su una coppia di vecchi computer che eseguono pfSense usando CARP per HA.

Rete : ottenere un paio di switch gestiti per il core della rete e utilizzare il bonding per dividere i server critici tra i due switch impedisce a un interruttore di eliminare l'intero armadio di dati.

Server : tutti i server dispongono di alimentatori ridondanti e RAID.

Server di backup : ho un sistema più vecchio che non è potente come il file server principale ma ha alcune unità sata di grandi dimensioni in raid5 che richiede istantanee del file server principale. Ho impostato degli script per questo per cambiare i ruoli in modo che diventino il file server primario in caso di interruzione.

Server di backup offsite : simile al backup onsite, eseguiamo backup notturni su un server tramite un tunnel VPN in una casa dei proprietari.

Macchine virtuali : ho un paio di server fisici che eseguono numerosi servizi all'interno di macchine virtuali usando Xen. Questi eseguono una condivisione NFS sul file server principale e posso eseguire la migrazione in tempo reale tra i server fisici in caso di necessità.

Penso che questa sia una domanda con molte risposte, ma sarei d'accordo in molti negozi più piccoli che la soluzione del server funziona e, come dici tu, almeno qualcosa continua se si verifica un errore. Ma dipende da ciò che fallisce.

Molto difficile da coprire tutte le basi ma alimentatori ridondanti, alimentazione di buona qualità e buoni backup possono aiutare.

Abbiamo utilizzato Backup Exec System Recovery per alcuni sistemi critici. Non tanto per il backup quotidiano ma come strumento di recupero. Siamo in grado di ripristinare su hardware diverso, se disponibile, e utilizziamo anche il software per convertire l'immagine di backup in una macchina virtuale. Se il server si guasta e dobbiamo attendere le riparazioni dell'hardware, possiamo avviare una VM su un server o una stazione di lavoro diversi e zoppicare. Non perfetto ma può essere installato e funzionante rapidamente.

Per quanto riguarda le SAN: quasi tutto ciò che usi sarà ridondante. Anche se si tratta di un singolo contenitore, all'interno saranno presenti doppi alimentatori, doppi connettori e doppie "testine", ciascuna con collegamenti a tutti i dischi. Anche qualcosa di semplice come un MD3000 venduto da Dell ha tutte queste caratteristiche. Le SAN sono progettate per essere il cuore delle tue scatole, quindi sono costruite per sopravvivere a qualsiasi errore hardware casuale.

Detto questo, hai ragione che la ridondanza non è sempre l'opzione migliore. Soprattutto se aumenta la complessità. (e lo farà) Una domanda migliore da porsi è ... "Quanto accetteranno i tempi di fermo". Se la perdita del tuo mailserver per un giorno o due non è un grosso problema, probabilmente non dovresti preoccuparti di due di loro. Ma se un'interruzione del server web inizia a perdere denaro reale ogni minuto, allora forse dovresti passare il tempo a creare un cluster adeguato per esso.

Più server hai, maggiori sono le possibilità che qualcosa si rompa, questo è un modo di vederlo. Un altro è se uno si interrompe, sei cresciuto del 100%, anche proprio come stai dicendo.

L'errore hardware più comune sono gli HD, come dicevi sopra. Indipendentemente da quanto si desidera suddividere le operazioni, è necessario eseguire il RAIDing della memoria.

Vorrei votare per un paio di server (ovviamente RAIDed) anziché uno enorme, sia per stabilità delle operazioni, sia per prestazioni. Meno software si imbattono in ognuno di essi richiedendo risorse, ingombro ridotto, più dischi su cui leggere / scrivere e così via.

Personalmente opterei per più server. Non penso che il guasto dell'apparecchiatura sia più probabile in questo scenario. Sì, hai più equipaggiamenti che potrebbero fallire, ma le probabilità di un dato guasto dell'unità dovrebbero essere costanti.

Ciò che mi offre più server in una configurazione non ridondante / non HA è la possibilità di scaricare parte del lavoro su un altro server in caso di errore. Quindi, supponiamo che il mio server di stampa non funzioni. Se riesco a mappare alcune stampanti sul file server mentre sto riparando il server di stampa, l'impatto sulle operazioni è ridotto. Ed è qui che conta davvero. Spesso tendiamo a parlare di ridondanza hardware, ma l'hardware è solo uno strumento per la continuità delle operazioni.

Lavoro in un piccolo negozio (dipartimento IT di un uomo) e non cambierei i miei server multipli con uno singolo in nessun caso. Se uno qualsiasi dei server si arresta, ho la possibilità di aggiungere i servizi ora mancanti a un'altra macchina o anche semplicemente configurarli su un PC di riserva. Possiamo vivere con un'interruzione di un'ora o due per la maggior parte delle cose, ma non possiamo vivere con un'interruzione completa di tutti i sistemi. Mentre posso sostituire uno qualsiasi dei nostri server con un PC, almeno temporaneamente, non ho, o posso prontamente prenderne possesso, qualsiasi cosa sia abbastanza vicino abbastanza potente da sostituire tutti i server contemporaneamente.

Il tuo post originale ipotizza che non puoi permetterti un cluster, ma consideri le soluzioni con due server (esclusi i backup). Ciò implicherebbe che molto probabilmente hai tre server a portata di mano, abbastanza per avviare un cluster.

Esistono soluzioni intermedie che possono evitare SPoF ed essere ancora appropriate nelle piccole e medie imprese: replica da nodo a nodo senza archiviazione SAN.

Questo è supportato ad esempio da Proxmox (ma penso che sia supportato anche da XCP-ng / XenServer e probabilmente da ESXi).

Consideriamo una configurazione a 3 nodi. Tutto con RAID, alimentatore ridondante, rete ridondante.

• I nodi A e B hanno CPU potenti e molta RAM.
• Il nodo C è più modesto in CPU / RAM ma ha molto spazio di archiviazione e viene utilizzato per fornire il quorum al watchdog ad alta disponibilità e ai backup host.

Quindi due opzioni:

1. Tutte le macchine virtuali normalmente funzionano sul nodo A e vengono replicate sul nodo B (che richiede un decente CPU decente)
2. Le macchine virtuali sono divise tra il nodo A e B e replicate reciprocamente alcune dal nodo A al nodo B e dal nodo B al nodo A.

Questo tipo di installazione può tollerare un errore di rete, un errore di nodo totale e maggiore (uno dei tre), con un tempo di inattività di circa 1 minuto (circa il tempo necessario per l'avvio di una VM). Il rovescio della medaglia, è la perdita di dati dall'ultima replica (che a seconda delle impostazioni e delle prestazioni dell'hardware può arrivare a un minimo di 1 minuto e fino a poche ore).

Con la seconda opzione (VM normalmente suddivisa tra il nodo A e B), è necessario stabilire la priorità di quale VM può tornare online. Poiché, poiché il carico della VM è in genere suddiviso tra due server, averli tutti in esecuzione su un singolo nodo potrebbe esaurire la RAM del nodo o congestionare la CPU.

"Mentre all'inizio sembra che sia più affidabile, non aumenta semplicemente la possibilità di guasti hardware?"

• Da un punto di vista hardware non vedo come aumenti praticamente le possibilità di errore. Ci sono molte variabili qui, e non ho mai studiato la probabilità, ma per semplificare eccessivamente: diciamo che Dell produce 1 server difettoso ogni 100.000. Le tue possibilità sono cambiate da 1 su 100.000 a 2 su 100.000 (o 1 su 50.000). Quindi sì, due volte la possibilità, ma comunque a causa della scala le possibilità praticamente non sono così diverse.
• Penso che la prospettiva sia la chiave qui. "Ti stai preparando per il doppio degli errori." Forse dal tuo punto di vista, ma in entrambi gli scenari che hai fornito, l'e-mail è in esecuzione su un server e ERP è in esecuzione su un server. Quindi, dal punto di vista dell'email o dell'erp (che è ciò che interessa all'azienda), è davvero lo stesso. A meno che non si sentano soli o apprezzino il loro spazio ;-)
• Penso che dovresti anche guardarlo dal punto di vista della gente. Penso che il fallimento a causa di errori delle persone sia forse più probabile, e in questo modo qualcuno probabilmente rovinerebbe solo un server alla volta. Inoltre semplifica l'identificazione dei problemi con cose come il carico. Se sia la posta elettronica che un sito Web vengono eseguiti su un server, tempo aggiuntivo per scoprire dove si trova il problema.

Non è mai così semplice, i server grandi e robusti possono essere fatti meglio o peggio ancora. Potrebbero avere parti di qualità superiore, ma forse fare più calore e non essere adeguatamente raffreddati. Un server robusto ha più RAM, più CPU ecc., Quindi alla fine potresti avere altrettante CPU in entrambi gli scenari, quindi forse un server non è l'unità giusta a cui pensare.

A causa della complessità delle possibilità, qualunque cosa sia la più conveniente vince credo. Se è necessario pagare per le licenze, 1 server di grandi dimensioni potrebbe essere più economico di alcuni server più piccoli a seconda della struttura delle licenze.

Il mio approccio predefinito è quello di evitare qualsiasi infrastruttura centralizzata. Ad esempio, ciò significa nessuna SAN , nessun bilanciamento del carico . Puoi anche definire un approccio così centralizzato "monolitico".

Come architetto del software, sto lavorando con l'infrastruttura del cliente. Ciò potrebbe significare utilizzare il proprio data center privato o utilizzare qualcosa come AWS. Quindi di solito non ho il controllo sul fatto che utilizzino o meno una SAN. Ma il mio software di solito si estende su più clienti, quindi lo costruisco come se fosse eseguito su singole macchine in isolamento su una rete.

L'esempio e-mail

L'email è strana, perché è un sistema legacy (che funziona). Se la posta elettronica fosse stata inventata oggi, probabilmente utilizzerebbe le API RESTFul sui server Web e i dati sarebbero in un database che potrebbe essere replicato utilizzando strumenti normali (replica transazionale, backup incrementali).

La soluzione di architettura software è che un'applicazione Web si connetterà a uno di un elenco di nodi disponibili (a caso) e, se non è disponibile, proverà a connettersi a un altro nodo (a caso). Un client potrebbe essere espulso da un server, se è troppo occupato. Qui, non è necessario che un bilanciamento del carico si connetta a una Web farm; e non è necessaria una SAN per l'alta disponibilità. È anche possibile frammentare il database per dipartimento o area geografica.

Merce significa ...

Quindi, invece di avere 1 o 2 server costosi e una SAN con misure di ridondanza interna, è possibile utilizzare diverse macchine a basso costo a basso consumo.

• Semplicità : la ridondanza deriva esclusivamente dal numero di dispositivi. È possibile verificare facilmente la ridondanza in base alla quantità di macchine. E più correttamente stimate che abbiano maggiori possibilità di fallimento e vi preparate.

• Percentuale di ridondanza : se si dispone di 2 server, in caso di errore ne rimane 1 (50%). Se hai 10 server di prodotti e uno fallisce, ne rimangono 9 (90%)

• Inventario : un dispositivo di consumo è prontamente disponibile da qualsiasi negozio nelle vicinanze per un ottimo prezzo.

• Compatibilità : con i canali in fibra ottica e tutti i tipi di standard per formati di volume del disco, dispositivi di base e architettura software significa che non si è bloccati in un singolo modello di dispositivo o marchio.

• Prestazioni : con 2 dispositivi su SAN, devono trovarsi nella stessa stanza. Con l'approccio macchina di base, se hai 5 uffici, puoi averne 2 in ogni ufficio, con ridondanza WAN VPN tra gli uffici. Ciò significa che il software e le comunicazioni si trovano sulla LAN con un tempo di accesso <1 ms.

• Sicurezza : basandosi sull'elevato livello di ridondanza, è possibile ricostruire facilmente i nodi come un normale processo di base. Vuoi ricostruire un cluster monolitico a 2 server? Tira fuori il manuale. Ricostruendo spesso le macchine (con l'automazione) mantieni aggiornato il software e impedisci a qualsiasi hacker o virus di prendere piede sulla tua rete.

Nota: è comunque necessario disporre di ridondanza di router switch e gateway multipli