Spostamento di server nello stesso edificio

Ecco il mio scenario: sono uno sviluppatore che ha ereditato (a mia insaputa) tre server situati nel mio ufficio. Ho anche ereditato il ruolo di amministratore dei server con una netta mancanza di conoscenza dell'amministrazione del server e google / ServerFault come punto di riferimento. Fortunatamente, in realtà non ho mai dovuto entrare in contatto fisicamente con le macchine o affrontare eventuali problemi in quanto hanno sempre "appena funzionato".

Tutte e tre le macchine si trovano nella stessa sala dati e hanno lo scopo seguente:

Machine1- IIS 8.0 che ospita una serie di applicazioni interne
Machine2- Archivio dati di SQL Server 2008 R2 per le applicazioni interne
Machine3- Archivio mirror di SQL Server 2008 R2 diMachine2

Tutti e tre hanno hard disk esterni collegati che completano frequentemente i backup.

Sono stato informato che tutti e tre hanno bisogno di spostarsi da una sala dati all'altra all'interno degli stessi locali. Non completerò lo spostamento fisico dell'hardware, che verrà gestito da un motore competente.

Oltre a completare un backup completo di ciascuno, quali considerazioni devo prendere prima di premere ipoteticamente l'interruttore di accensione e guardare il mio mondo muoversi?

^{Sono consapevole che è tutt'altro che ideale avere tutti e tre situati nella stessa stanza / locale, ma questo è oltre lo scopo di questa domanda.}

Domanda davvero interessante, ben fatta :)

Ci sono alcune cose che devi controllare prima di questa mossa, alcune facili, altre difficili.

Alimentazione : controlla che la nuova sala non abbia solo la giusta quantità di prese di corrente ma che siano del tipo giusto, come nel tipo di connettore fisico e se la posizione corrente consente diverse fasi di alimentazione per server per proteggerle da guasti monofase ti esorto caldamente a replicarlo anche nella nuova posizione.

Raffreddamento : è necessario verificare che non si verifichi un accumulo immediato o graduale di calore che porterà al surriscaldamento e al potenziale arresto del server. Di solito puoi cercare la massima potenza (in watt) o il calore (in BTU) che ciascun server può attingere dal sito Web del produttore - fai sapere al tuo responsabile dell'edificio questo e ottieni una conferma scritta da loro che afferma che il raffreddamento in quella posizione farà fronte .

Networking - questo è difficile - non solo è necessario replicare lo stesso numero di porte tra la vecchia e la nuova posizione, ma anche il loro tipo, velocità e, soprattutto, configurazione. Quest'ultimo punto è la chiave - c'è stato un tempo in cui quasi tutte le porte in una rete erano praticamente uguali - Sono abbastanza vecchio da ricordare quei tempi! ma al giorno d'oggi il numero di configurazioni delle porte e il posto nella rete in cui può trovarsi una delle porte è astronomico, devi assicurarti che le persone della tua rete replicate TUTTO per essere identiche dalla vecchia alla nuova - ancora una volta scrivilo come questo non è facile. Se qualcosa dovesse andare storto con questa mossa, metterei i soldi che saranno sulle porte di rete non identici, succede sempre.

"Altre connessioni" : sai se i tuoi server hanno connessioni diverse da quelle di alimentazione e rete? forse hanno collegamenti Fibre Channel per l'archiviazione condivisa, collegamenti KVM a una schermata di gestione condivisa - anche in questo caso è necessario replicarli in modo identico.

A parte questo, sentiti libero di tornare qui con domande più specifiche e spero che la mossa vada bene.

Altre risposte riguardano gli aspetti tecnici della mossa. Potrebbe anche essere necessario considerare alcune altre cose.

Assicurati che gli utenti sappiano che le loro applicazioni non saranno attive durante lo spostamento. Dovrai pianificare il trasferimento, magari durante le ore non lavorative, in modo da ridurre al minimo il numero di persone interessate.

Chiedi a una persona (o persone) esperta di testare le applicazioni dopo aver visualizzato i server. Invitali a fare alcuni controlli di integrità per assicurarsi che le applicazioni funzionino come previsto.

Dopo il test, comunica ai tuoi utenti che lo spostamento è terminato e fai loro sapere se hanno problemi.

È abbastanza difficile da dire e borderline "troppo ampio" per il nostro formato. La cosa più importante che devi controllare è se devi riconfigurare la tua rete in qualsiasi modo se possono continuare a funzionare con gli stessi indirizzi. Anche se possono mantenere gli stessi indirizzi, assicurarsi che non siano configurati tramite DHCP e / o verificare che il server DHCP sia disponibile nella nuova posizione.

Nota a margine: come hai già detto, avere il server SQL e il suo mirror è tutt'altro che ideale. Tuttavia, avere le unità di backup nella stessa posizione è davvero pericoloso. È necessario disporre del backup in una posizione fisica diversa.

Altre risposte hanno buone considerazioni pre-mossa. Tuttavia, dovresti anche pianificare come organizzare la mossa effettiva. Dal fatto che Machine3 è un mirror di Machine2 , sembra che l'uptime sia una considerazione significativa per i database di SQL Server 2008 R2. Il fatto che sia uno specchio ti offre l'opportunità. Il motivo dell'esistenza di un mirror deve essere disponibile quando il server primario non lo è. Ciò include non essere disponibile a causa di manutenzione, che include lo spostamento.

Fai un piano:
dovresti fare un piano scritto su come verrà eseguita la mossa. Potrebbe essere necessario essere in grado di fornire questo piano, o parti di esso, alle persone che gestiscono parti del lavoro (ad esempio i traslochi). Questo piano dovrebbe includere tutte le attività pre-trasloco, lo spostamento effettivo e le azioni post-spostamento (ad es. Verifica della funzionalità).

Sposta le basi:

1. Sposta Machine3 (il mirror di SQL Server): rendilo completamente operativo. Verifica la risincronizzazione.
2. Sposta Machine2 : rendilo completamente operativo.
3. Sposta Machine1 : rendilo completamente operativo.

Descrizione più dettagliata della mossa:

Di seguito sono riportati due metodi (Percorso A e B) per utilizzare Machine3 per testare le connessioni per Machine1 e / o Machine2 . Dovresti usare solo un metodo. Il modo in cui farlo, o anche se utilizzarlo, dipende dalle informazioni non contenute nella domanda (ad es. Separazione fisica delle posizioni finali della macchina, dimensione fisica delle macchine, lunghezza della rete / cavi di alimentazione, disponibilità di estensioni per lo stesso, somiglianza delle configurazioni delle porte di rete, necessità di uptime, ecc.). L'uso di Machine3 per testare queste connessioni consente potenzialmente tempi di attività più elevati per Machine2 , ma in particolare per Machine1 , che non ha mirror. Puoi scegliere di usare uno dei due metodi o nessuno dei due.

1. Sposta prima Machine3 .

   • Lasciare Machine1 e Machine2 in posizione per ora.
   • Backup Machine3 , quindi spegnerlo
   • Ottieni Machine3 completamente spostato nella nuova posizione.
   • [Percorso B: non utilizzato se si intende utilizzare il passaggio n. 2 opzionale.] Se le configurazioni di rete e alimentazione per tutte le macchine sono identiche: collocare Machine3 dove Machine1 è pianificato per finire usando le connessioni previste per Machine1 .
   • Ottenere Machine3 tornato attivo e funzionante. Nella nuova posizione, verificare che funzioni normalmente come mirror di Machine2 . Ciò fornirà la verifica fisica che la configurazione di tutti i problemi (alimentazione, rete, ecc.) Sia funzionale nella nuova posizione.
   • Risolvi eventuali problemi che si presentano.
   • Verificare che Machine3 sia stato risincronizzato completamente con Machine2 prima di procedere.

2. Percorso A: (Opzionale):

   • Utilizzare Machine3 per testare tutte le strutture destinate a Machine2 e Machine1 .
   • Arrestare Machine3 e spostare / passare a utilizzando la posizione / connessioni per Machine2 , (verificare la risincronizzazione), quindi Machine1 (verificare la risincronizzazione). Se hai pianificato di farlo, allora Machine3 avrebbe dovuto essere inizialmente impostato con le connessioni destinate all'uso finale da Machine1 o Machine2 , quindi non impostarlo prima nella posizione finale per Machine3 e poi cambiarlo 3 volte, ma solo 2 iniziando con esso utilizzando le strutture di una delle altre macchine.
   • Verificare che Machine3 sia stato risincronizzato completamente con Machine2 prima di procedere.

3. Sposta macchina2 .

   • La tua pratica con Machine3 dovrebbe renderla molto più fluida.
   • Backup Machine2 , quindi spegnerlo
   • Spostare Machine2 nella nuova posizione; effettuare tutte le connessioni
   • Risolvi eventuali problemi che si presentano.
   • Verificare che Machine2 sia stato risincronizzato completamente con Machine3 prima di procedere.

4. [Percorso B: non necessario se hai testato tutte le connessioni con Machine3 nel passaggio opzionale # 2] Se ora hai Machine3 in cui Machine1 deve finire:

   • Spegni Machine3 .
   • Spostalo nel punto in cui è pianificato di finire (fuori dalla posizione in cui desideri localizzare Machine1 ).
   • Risolvi eventuali problemi che si presentano.
   • Verificare che Machine3 sia stato risincronizzato completamente con Machine2 prima di procedere.

5. Spostare Machine1 .

   • Dopo aver spostato sia Machine2 che Machine3 (e speriamo di aver verificato le connessioni effettive che Machine1 userà facendo in modo che Machine3 le usi temporaneamente), questa dovrebbe essere la più fluida delle mosse.
   • Backup Machine1 , quindi spegnerlo
   • Spostare Machine1 nella nuova posizione; effettuare tutte le connessioni
   • Risolvi eventuali problemi che si presentano.
   • Se qualcosa va storto con le strutture nella posizione che Machine1 dovrebbe occupare, hai la possibilità di usare le strutture in cui ora Machine3 si trova. Spero che tu sia già stato in grado di testare tutte le strutture nella posizione Machine1 facendolo già usare da Machine3 per un certo periodo (Path A o Path B).

Se uno qualsiasi degli IP dei server cambierà, e le connessioni verranno effettuate alla casella SQL tramite la risoluzione DNS, sarà necessario pianificare una modifica ai record DNS contemporaneamente allo spostamento.

Cose che dovresti sapere sul software e sui database intranet:

• Il software Intranet si collega a SQL Server tramite IP, NetBIOS o DNS?
• Gli account utente di SQL Server utilizzati dal software Intranet hanno un'autenticazione limitata al traffico proveniente da un IP?
• I dipendenti della tua azienda accedono a SQL Server direttamente da fogli di calcolo o strumenti di reporting, in tal caso, come definiscono il DSN?

Se non ottieni gli stessi IP esatti o se finisci su una sottorete diversa, dovrai accedere per modificare il codice sorgente o i file di configurazione per tutte le app che si connettono al server SQL. Le persone potrebbero fare affidamento su un accesso SQL non documentato e diretto per i report ad hoc.

Utilizza i tuoi server "Disaster Recovery". Passa a loro per gestire il carico mentre sposti i tuoi server di produzione. Con le apparecchiature DR configurate correttamente, puoi muoverti a metà giornata senza vedere molto tempo di inattività (fino a 15 minuti). Poiché i server di ripristino di emergenza devono essere configurati allo stesso modo dei server di produzione. Se non si dispone di apparecchiature DR, consiglio vivamente di procurarle.

Pensala in questo modo: mentre la tua corvetta si sta sintonizzando, usa il tuo minivan per affrontare la giornata.

Una cosa che non credo sia stata menzionata è la sicurezza fisica della nuova casa dei server. A cosa serviva prima la stanza e chi ha le chiavi? C'è un'adeguata sicurezza (sistemi di allarme, telecamere, ecc.).

Alcune considerazioni oltre alle altre risposte:

• Le applicazioni sono collegate ad altre tramite, ad esempio, lo scambio notturno di dati per file o mediante servizi web? Quali sono le conseguenze quando le applicazioni non sono disponibili? Le applicazioni correlate possono farcela o fallire o persino produrre risultati errati a causa della mancanza di informazioni dalle applicazioni?

• Un downtime è accettabile per i tuoi utenti, la tua azienda o anche i tuoi clienti? Quanto può durare?

• Penso che sia una buona idea avere un piano per un rollback. È possibile utilizzarlo in caso di un problema che non può essere risolto rapidamente, ad esempio un problema di rete. Probabilmente dovrai tenere il mover disponibile per il caso di riportare l'hardware.

• Le tue applicazioni portano a un elevato traffico di rete e la rete deve essere preparata per questo (probabilmente un problema molto più improbabile rispetto a problemi con indirizzi e firewall)? Se si dispone di applicazioni in tempo reale (ad es. Software per videoconferenza), le latenze saranno importanti.

• I server devono inserirsi nel rack server se ne hai uno.