Perché le grandi installazioni di Exchange richiedono tempi di inattività per la manutenzione?

8

Nel corso degli anni ho utilizzato diversi fornitori di Exchange di terze parti di livello superiore e tutti hanno avuto regolari tempi di inattività programmati per la manutenzione ordinaria (circa una volta al mese). Mi chiedo che cos'è Exchange che rende impossibile evitare tempi di inattività di questo tipo? È davvero impossibile mantenere il tempo di attività 24 ore su 24, 7 giorni su 7 o solo in modo proibitivo e costoso?

exchange hosted-exchange

— Michael Teper
fonte

2

IMO il modo in cui viene posta questa domanda lo rende fuori tema per serverfault. Questo sito è destinato ai sistemi amministrati, non a domande su come i provider di hosting hanno impostato il proprio sistema. Una domanda del tipo "come faccio a impostare lo scambio per non avere interruzioni di manutenzione" sarebbe stata ok.

— Zoredache,

@Zoredache Ora che ho utilizzato tre diversi hoster di Exchange per un periodo di tempo significativo (oltre un anno) e che tutti e tre eseguono regolarmente la manutenzione programmata, mi sono sentito al sicuro supponendo che la configurazione di un'installazione di Exchange senza interruzioni non sia pratica. Volevo scoprire perché. @Zippy sembra avere la risposta.

— Michael Teper,

Sono d'accordo con Zoredache, questa è una domanda per l'utente finale. È anche completamente soggettivo, anche se la risposta breve deve essere: lo stesso motivo per cui tutti i sistemi Windows non sono in linea per manutenzione (ad es. Patch, aggiornamenti, ecc.)

— John Gardeniers,

Anche i sistemi Linux necessitano di patch e aggiornamenti.

— ceejayoz,

7

Gli aggiornamenti di Windows ed Exchange richiedono sempre il riavvio per completare l'installazione, quindi fa parte di esso. Con una buona pianificazione e una corretta installazione (bilanciamento del carico e clustering) è possibile mantenere il tempo di attività 24x7 in modo che la posta elettronica sia sempre disponibile su un server.

Sul lato client, tuttavia, c'è sempre una breve interruzione (5-30sec) poiché Outlook scopre che il server CAS a cui è connesso non è in linea e l'individuazione automatica lo commuta su un altro. In genere viene visualizzato il messaggio "L'amministratore di Exchange ha apportato una modifica che richiede il riavvio di Outlook" quando ciò accade.

Non è un'interruzione prolungata, ma conta come un'interruzione, quindi è necessario pianificare i tempi di manutenzione per farlo. C'è anche la possibilità che qualcosa vada storto durante il periodo di manutenzione, quindi per CYA è necessario programmarlo.

EDIT: Quindi ho scoperto che se metti un bilanciamento del carico davanti ai tuoi server CAS non otterrai il messaggio "L'amministratore di Exchange ha apportato una modifica ..." in Outlook. Avrai comunque una breve interruzione quando il bilanciamento del carico passa a un server CAS attivo.

— vigoroso
fonte

non c'è motivo per cui uno switch di server debba richiedere ai client di riavviare il proprio software (è altrettanto ridicolo che richiedere agli utenti di riavviare IE / Firefox se un server Web si riavvia), questo è solo un difetto in Exchange stesso.

— Sdraiati Ryan il

Sembra la risposta più plausibile finora, ma è contraddetta direttamente dalla risposta di @ Massimo. Sono un po 'perplesso su come decidere quale assegnare la risposta. Suggerimenti?

— Michael Teper,

Voterei per la risposta di zippy su quella di massimo. Avrai sempre quel breve periodo di ritaglio quando la posta non è accessibile, anche con due server e archiviazione condivisa. La modalità cache sul client potrebbe rendere meno ovvio quando ciò accade, ma non vorrei davvero che due server accedessero allo stesso archivio di backup contemporaneamente.

— Robert Novak,

9

Per farla breve ... Non stai usando quei grandi fornitori.

Non vi è alcun motivo per cui è necessario pianificare periodi di inattività regolari di un ambiente Exchange (sebbene la pianificazione di finestre di manutenzione regolari sia sempre una cosa saggia). Soprattutto con Exchange 2010. Finché la ridondanza è pianificata e implementata correttamente, tutto scorre. Rete ridondante, memoria ridondante, server ridondanti.

Probabilmente non lo otterrai utilizzando un provider $ 3 / al mese. Non rivendo cassette postali di scambio di $ 3 / mese. La maggior parte dei miei motivi per raccomandare Exchange ospitato riguarda l'importanza dell'email e del tempo di attività. Devi pagare di più per un fornitore che non diminuisce sempre, ma il ROI ha senso.

Il nostro fornitore invia e-mail per ogni manutenzione programmata. Ne riceviamo almeno uno al mese. Il 99% di loro praticamente legge: "Stiamo facendo manutenzione sui nostri server tra le 2:00 e le 2:15. Potresti notare 15-30 secondi di problemi di connettività durante il failover delle cassette postali / archiviazione".

Se stai cercando il 100% di uptime senza 30 secondi di failover, non lo troverai da nessuna parte. Non con Exchange, non con Google Apps, non con Domino. Il 100% di uptime non esiste. Le finestre di manutenzione saranno sempre necessarie e i failover richiedono ancora tempo (anche se tale tempo è breve).

Quindi trova un nuovo fornitore che potrebbe costare di più ma ti fornirà il tipo di uptime di cui hai bisogno.

— Jason Berg
fonte

2

@Jason Mi dispiace, ma la tua risposta è una contraddizione. Per prima cosa dici che non sono necessari tempi di fermo regolari e poi dici che lo è, e nessuno può evitarlo. Citi Google come controesempio di Exchange, tuttavia non ho mai ricevuto un avviso di inattività per GMail o Google Apps. Inoltre, presumi erroneamente che io abbia usato provider di Exchange di livello inferiore. In realtà non l'ho fatto e ho pagato molto più di $ 3 / cassetta postale / mese.

— Michael Teper,

2

Probabilmente non riceverai avvisi di downtime dalle app di Gmail o Google, ma ciò non significa che non subirai di tanto in tanto un grave degrado (3-4 volte nell'ultimo mese per i miei domini).

— Robert Novak,

1

E Jason non si sta contraddicendo. Le finestre di manutenzione programmata (intervalli di tempo prevedibili per la manutenzione programmata, quando necessario) sono un'ottima pratica. I tempi di fermo programmati (interruzioni prevedibili / garantite) non lo sarebbero. Vedi la differenza?

— Robert Novak,

3

but your answer is a contradition. First you say that regular downtime is not required and then you say that it is. In realtà, non sono necessari tempi di inattività effettivi, ma potrebbe verificarsi un breve periodo di tempo in cui si verifica il failover. Non chiamerei un server "inattivo" durante la finestra di failover. I singoli sistemi devono essere mantenuti, ma l'intera installazione di Exchange non dovrebbe essere interrotta se si spendono molti $$$ per configurarlo correttamente.

— Zoredache,

Come è impossibile il 100% di uptime? Non potresti avere solo alcuni server con record MX a priorità inferiore che contengono posta mentre i server principali sono inattivi?

— Daniel Lo Nigro,

7

Mantenere la ridondanza N + 1 per letteralmente ogni parte della rete per garantire che i tempi di inattività per la manutenzione non costeranno di più; abbastanza più di quanto il servizio non sarebbe più competitivo sui prezzi. La maggior parte delle aziende è molto tollerante nei tempi di inattività pianificati minimi. Questo non è esclusivo di Exchange, quasi tutti i fornitori di hosting, di qualsiasi tipo, con cui ho avuto a che fare approssimativamente la stessa cosa.

Nel caso di Exchange, scenderà una volta al mese (almeno) per Patch Martedì.

— Chris S
fonte

6

Tutti vogliono il 100% di uptime, ma pochissimi sono disposti o in grado di pagare per questo. Per i server di posta elettronica penso che molte persone vadano bene con il 99% di uptime.

— zippy

1

Mantenere la ridondanza di N + 1 è a basso costo per un grande valore di N, l'OP è interessato per l'installazione di Exchange di grandi dimensioni che dovrebbe essere in grado di permettersi una ridondanza di N + 1.

— Sdraiati Ryan il

@Lie Ryan: il costo per utente potrebbe essere inferiore su grandi basi di installazione, ma non è gratuito. Se le persone si confrontano con l'hosting di scambio per $ 10 al mese e lo scambio di hosting per $ 5 al mese, allora quanti sceglieranno il piano a basso costo e si lamenteranno dei loro tempi di inattività e non si accorgeranno mai che l'host da $ 10 al mese ha 3 volte la disponibilità dell'host da $ 5 e è per questo che costa di più?

— Rob Moir,

5

L'unica manutenzione ordinaria di cui ha bisogno Exchange è l'applicazione di patch ai server, che in un ambiente correttamente costruito non dovrebbero creare alcun tempo di inattività: anche con solo due server è possibile mantenerne uno attivo mentre si patch e si riavvia l'altro. L'esecuzione di backup non crea alcun tempo di inattività e testare i ripristini è qualcosa che deve essere fatto in un ambiente DR, non su server live. Davvero non capisco cosa sia questa "manutenzione ordinaria" o perché dovrebbe essere assolutamente necessaria.

Ovviamente non sto dicendo che garantire un uptime del 99% sia facile; i problemi si verificano, anche negli ambienti migliori e più costosi. Quello che sto dicendo è che non vi è alcun motivo per smantellare un sistema Exchange per la "manutenzione ordinaria". A meno che non eseguiate le normali deframmentazioni offline dei vostri database ... qualcosa che nessuno nella sua mente giusta dovrebbe fare più (ma comunque ...).

— Massimo
fonte

0

Non c'è nulla in Exchange che lo rende intrinsecamente inaffidabile o incline a scendere ... in effetti direi che vale il contrario. Dipende da come sono impostati i provider per fornire il loro servizio di Exchange .

Un servizio può essere fornito da uno o più server : i principali siti Web, i sistemi di posta elettronica (ad esempio gmail, hotmail, ecc.) Sono forniti da gruppi di server progettati per consentire la disattivazione di alcuni dei server che ospitano il servizio senza influire sulla disponibilità del servizio.

Se i server che forniscono il servizio sono basati su un sistema che supporta l'alta disponibilità (ad esempio il clustering), è possibile che alcuni server che forniscono il servizio siano offline senza effettivamente portare il servizio stesso offline.

Questa è la teoria ... e la teoria può essere fatta funzionare nella pratica. La domanda è: quanto il fornitore è disposto a spendere in hardware, progettazione e supporto dei sistemi (il costo per passare dal 99,99% disponibile al 99,999% disponibile è molto più alto del costo del passaggio dal 99% al 99,9% disponibile, ad esempio) . Nel caso di un servizio ospitato, questo diventa rapidamente una questione di quanto le persone sono disposte a pagare per il servizio.

Per un fornitore, questo può rapidamente diventare proibitivamente costoso e quando si scatta per una disponibilità molto elevata, anche i tempi di inattività molto piccoli possono battere le tue statistiche .

— Rob Moir
fonte