Vraag Servers verplaatsen binnen hetzelfde gebouw


Dit is mijn scenario: ik ben een ontwikkelaar die (buiten het medeweten van mij) drie servers in mijn kantoor heeft geërfd. Ik heb ook de taak van beheerder van de servers geërfd met een duidelijk gebrek aan kennis van serverbeheer en google / ServerFault als referentiepunt. Gelukkig hoefde ik fysiek nooit fysiek contact te maken met de machines of problemen aan te pakken omdat ze altijd 'gewoon' gewerkt hebben.

Alle drie machines bevinden zich in dezelfde dataroom en hebben het volgende doel:

Machine1 - IIS 8.0 host een aantal interne applicaties
Machine2 - SQL Server 2008 R2 dataopslag voor de interne applicaties
Machine3 - SQL Server 2008 R2 mirror store van Machine2

Alle drie hebben externe harde schijven aangesloten die complete back-ups vaak maken.

Ik ben geïnformeerd dat ze alle drie binnen dezelfde ruimte van de ene dataroom naar de andere moeten gaan. Ik zal niet het fysieke verplaatsen van de hardware voltooien, die zal worden afgehandeld door een competente beweger.

Los van het invullen van een volledige back-up van elk, welke overwegingen moet ik maken voordat ik hypothetisch op de aan / uit-schakelaar ga en kijk hoe mijn wereld beweegt?

Ik ben me ervan bewust dat het verre van ideaal is om ze alle drie in dezelfde kamer / gebouwen te hebben, maar dat is buiten het bestek van deze vraag.


60
2017-08-22 10:51


oorsprong


Zelfs los van deze zet, heb je al een plan wat ga je doen als één (of alle) moederborden / voedingen / schijven doodgaan? (omdat het uiteindelijk zal gebeuren) - Dusan Bajic
@spuder misschien moeten ze de app beschikbaar hebben zonder internet (ze zeggen dat het een interne applicatie is) of ze willen gewoon niet dat de NSA naar binnen gluren. De cloud is geen wondermiddel. - André Borie
Dit is niet genoeg voor een antwoord op zichzelf, maar ik raad aan om een ​​zachte uitschakeling en power-up uit te voeren voordat de verhuizing plaatsvindt, zodat u weet wat de servers doen wanneer ze met succes worden aangezet. Er kunnen een aantal enge piepjes of onterechte foutmeldingen zijn waarvan u niet weet dat deze moeten worden genegeerd als u de vorige keer geen stroom hebt gefietst. Als je weet hoe een soepele inschakeling eruit ziet / klinkt en hoe lang het duurt, ben je beter in staat om te beoordelen of er na de zet iets erg mis is. - Stefan Mohr
Start achtereenvolgens elke computer opnieuw op en hoop dat het zonder fouten opnieuw tot leven komt voordat u verhuist! - Matt
@Matt hij geeft in ieder geval toe dat hij geen idee heeft en probeert te leren wat goed is. Ik heb veel te veel gevallen gezien waarbij de beheerder een complete idioot is, maar het niet eens beseft. - André Borie


antwoorden:


Echt interessante vraag, goed gevraagd :)

Er zijn een paar dingen die je moet controleren voordat je deze zet doet, sommige eenvoudig, een beetje moeilijk.

macht - controleer of de nieuwe ruimte niet alleen de juiste hoeveelheid stopcontacten heeft, maar ook dat ze van het juiste type zijn - zoals in het fysieke connectortype en als de huidige locatie het mogelijk maakt om verschillende voedingsfasen per server te beschermen tegen uitval in één fase dan ik ' d dring er bij u op aan om dat ook op de nieuwe locatie te repliceren.

Koeling - u moet controleren of er geen directe of geleidelijke opbouw van warmte is die zal leiden tot oververhitting en mogelijke uitschakeling van de server. U kunt meestal het maximale vermogen (in watt) of verwarming (in BTU's) opzoeken dat elke server kan nemen op de website van de fabrikant - laat uw gebouwbeheerder dit weten en ontvang een schriftelijke bevestiging van hen dat de koeling op die locatie het hoofd zal bieden .

Netwerken - dit is de moeilijkste - niet alleen moet hetzelfde aantal poorten worden gerepliceerd tussen oude en nieuwe locaties, maar ook hun type, snelheid en vooral configuratie. Dit laatste punt is de sleutel - er was een tijd dat bijna alle poorten in een netwerk vrijwel gelijk waren - ik ben oud genoeg om die tijden te onthouden! maar tegenwoordig is het aantal poortconfiguraties en de plaats in het netwerk waar elke poort zich in bevindt astronomisch, je moet ervoor zorgen dat je netwerkmensen ALLES repliceerden om identiek te zijn van oud naar nieuw - schrijf dit opnieuw als dit is niet gemakkelijk. Als er iets misgaat met deze zet, zou ik geld stoppen dat de netwerkpoorten niet identiek zijn, het gebeurt altijd.

'Andere verbindingen' - weet u of uw servers andere verbindingen hebben dan stroom en netwerken? misschien hebben ze Fibre Channel links naar gedeelde opslag, KVM linkt naar een gedeeld managementscherm - nogmaals, als ze dat doen, moet je ze identiek repliceren.

Buiten dat voel je je vrij om hier terug te komen met meer specifieke vragen, en ik hoop dat de verhuizing goed gaat.


61
2017-08-22 11:24



+1 voor Chopper3 - Ik zou ook willen toevoegen dat, afhankelijk van hoe uw netwerk is geconfigureerd, er slechts een kleine kans is dat de MAC-adressen van uw netwerkkaarten niet van de oude switch worden vrijgegeven en dat internet mogelijk niet werkt, afhankelijk van hoe het netwerk is gebouwd. Ik weet dat dit misschien niet gebeurt als de switches correct zijn geconfigureerd, maar ik heb in een grote omgeving gewerkt en dit gebeurde vrij vaak en de netwerkingenieur moest het MAC-item handmatig wissen. - Mugurel
Maak een foto van de backplane voordat u de demontage uitvoert. Redt een laod van pijn. - Sobrique
Alles. Maak gewoon foto's op je cameratelefoon van waar alle kabels naartoe gaan en wat er is aangesloten en wat niet. (Ervan uitgaande dat u die in de DC bent toegestaan). Echt goed om later nogmaals te kijken hoe 'dingen eruit zagen' als er iets raar gebeurt. - Sobrique
Ah dus 'poorten' dan - backplane verwijst vaak naar iets heel anders - Chopper3
@ Chopper3 Backplane altijd verwijst naar een interne hardwarecomponent en nooit "de achterkant van de behuizing van de server". Behalve wanneer het een mislukt sociaal netwerk betekent. - Christopher Schultz


Andere antwoorden hebben betrekking op de technische aspecten van de verhuizing. Misschien moet u ook andere dingen overwegen.

Zorg ervoor dat gebruikers weten dat hun apps niet beschikbaar zijn tijdens de verhuizing. U zult de verhuizing willen inplannen, misschien tijdens uren die niet werken, zodat u het aantal getroffen mensen tot een minimum beperkt.

Laat een deskundige persoon (of personen) de toepassingen testen nadat u de servers hebt geopend. Laat ze een aantal sanitaire controles uitvoeren om ervoor te zorgen dat de applicaties werken zoals verwacht.

Na het testen, vertel je gebruikers dat de zet is voltooid en laat ze je laten weten of ze problemen hebben.


27
2017-08-22 16:36





Het is vrij moeilijk om te vertellen en borderline "te breed" voor ons formaat. Het belangrijkste dat u moet controleren, is of u uw netwerk op een of andere manier moet herconfigureren als ze met dezelfde adressen kunnen blijven werken. Zelfs als ze dezelfde adressen kunnen behouden, moet u ervoor zorgen dat ze niet zijn geconfigureerd via DHCP en / of controleren of de DHCP-server beschikbaar is op de nieuwe locatie.

Kanttekening: Zoals u al zei, is het hebben van de SQL-server en de mirror verre van ideaal. Het is echter wel zo dat de back-upstations op dezelfde locatie zijn werkelijk gevaarlijk. U moet uw back-up op een andere fysieke locatie hebben staan.


18
2017-08-22 11:09



+1 back-ups. Ze zouden niet op dezelfde locatie moeten staan, ook de server waarvan een back-up is gemaakt zou geen toegang moeten hebben tot back-upmedia, anders kan een fout / malware / sabotage / ransomware op een van de servers ook back-ups vernietigen. Misschien heeft u op dit moment geen budget, maar zet u het op uw lijst met dingen die u moet doen. - sdkks


Andere antwoorden hebben goede pre-move-overwegingen. U moet echter ook plannen hoe u de daadwerkelijke verhuizing organiseert. Van het feit dat machine3 is een spiegel van machine2, het lijkt erop dat uptime een belangrijke overweging is voor de SQL Server 2008 R2-database (s). Het feit dat het een spiegel is, biedt u een kans. De reden voor het bestaan ​​van een mirror is om beschikbaar te zijn wanneer de primaire server dat niet is. Dat omvat niet beschikbaar zijn vanwege onderhoud, inclusief verhuizen.

Een plan maken:
Je moet een geschreven plan maken voor hoe de verhuizing zal worden uitgevoerd. Mogelijk moet u dit plan, of delen ervan, kunnen verstrekken aan mensen die delen van het werk afhandelen (bijvoorbeeld de verhuizers). Dit plan moet alle pre-move activiteiten omvatten, de daadwerkelijke verplaatsing en acties na verplaatsing (bijvoorbeeld verificatie van functionaliteit).

Basisbeginselen verplaatsen: 

  1. verhuizing machine3 (de SQL Server-mirror): volledig operationeel. Verifieer opnieuw synchroniseren.
  2. verhuizing machine2: Krijg het volledig operationeel.
  3. verhuizing machine1: Krijg het volledig operationeel.

Meer gedetailleerde beschrijving van de verhuizing:

Het volgende bevat twee methoden (pad A en B) voor gebruik machine3 om de verbindingen te testen voor machine1 en / of machine2. Je zou maar één methode moeten gebruiken. Welke manier om dit te doen, of zelfs om een ​​van beide te gebruiken, hangt af van informatie die niet in de vraag is opgenomen (bijv. Fysieke scheiding van de uiteindelijke machinelocaties, fysieke grootte van de machines, lengte van netwerk / netsnoeren, beschikbaarheid van extensies voor dezelfde, gelijkenis van netwerkpoortconfiguraties, uptime-behoeften, etc.). Gebruik makend van machine3om deze verbindingen te testen maakt u mogelijk hogere uptime mogelijk machine2, maar vooral voor machine1, die geen spiegel heeft. U kunt ervoor kiezen om beide methoden te gebruiken of geen van beide.

  1. verhuizing machine3 eerste.

    • Het verlof machine1 en machine2 op zijn plaats voor nu.
    • backup machine3, sluit het dan af
    • Krijgen machine3 volledig verplaatst naar de nieuwe locatie.
    • [Pad B: niet gebruikt als u optionele stap # 2 gaat gebruiken.] Als de netwerk- en stroomconfiguraties voor alle machines identiek zijn: machine3 waar machine1 is gepland om uiteindelijk de voorgenomen verbindingen te gebruiken machine1.
    • Krijgen machine3 een back-up maken. Controleer op de nieuwe locatie of deze normaal functioneert als een spiegel van machine2. Dit zorgt voor fysieke verificatie dat de configuratie van alle problemen (voeding, netwerk, enz.) Functioneel is op de nieuwe locatie.
    • Los eventuele problemen op.
    • Verifieer dat machine3 is volledig opnieuw gesynchroniseerd met machine2 voorafgaand aan de procedure.
  2. Pad A: (optioneel):

    • Gebruik machine3 om alle voorgenomen voorzieningen te testen machine2 en machine1.
    • gesloten machine3 naar beneden en verplaatsen / schakelen naar het gebruik van de positie / verbindingen voor machine2, (verifieer opnieuw synchroniseren) dan machine1 (verifieer opnieuw synchroniseren). Als je van plan was om dit te doen, dan machine3 moet in eerste instantie zijn opgezet met de aansluitingen bedoeld voor eindgebruik door machine1 of machine2, zodat u het niet eerst op de eindlocatie instelt voor machine3 en verander het dan 3 keer, maar slechts 2 door ermee te beginnen met behulp van de faciliteiten van een van de andere machines.
    • Verifieer dat machine3 is volledig opnieuw gesynchroniseerd met machine2 voorafgaand aan de procedure.
  3. verhuizing machine2.

    • Je oefent met machine3 zou dit veel soepeler moeten maken.
    • backup machine2, sluit het dan af
    • verhuizing machine2 naar de nieuwe locatie; maak alle verbindingen
    • Los eventuele problemen op.
    • Verifieer dat machine2 is volledig opnieuw gesynchroniseerd met machine3 voorafgaand aan de procedure.
  4. [Pad B: niet nodig als je alle verbindingen hebt getest machine3 in optionele stap # 2] Als het nu is machine3 waar machine1 moet eindigen:

    • Stilgelegd machine3.
    • Verplaats het naar waar het is gepland om te eindigen (van de locatie die u van plan bent machine1 lokaliseren).
    • Los eventuele problemen op.
    • Verifieer dat machine3 is volledig opnieuw gesynchroniseerd met machine2 voorafgaand aan de procedure.
  5. verhuizing machine1.

    • Beide verplaatst machine2 en machine3 (en hopelijk de daadwerkelijke verbindingen getest machine1 zal gebruiken door te hebben machine3 gebruik ze tijdelijk), dit zou de meest vloeiende beweging moeten zijn.
    • backup machine1, sluit het dan af
    • verhuizing machine1 naar de nieuwe locatie; maak alle verbindingen
    • Los eventuele problemen op.
    • Als er iets misgaat met de faciliteiten in de positie dat machine1 zou moeten bezetten, je hebt de mogelijkheid om de faciliteiten te gebruiken waar machine3 bevindt zich nu. Hopelijk was je al in staat om alle faciliteiten in de machine1 positie door het al te laten gebruiken door machine3 voor een tijd (pad A of pad B).

16
2017-08-23 15:37





Als een van de IP's van de servers dan verandert en verbindingen worden gemaakt met de SQL-box via DNS-resolutie, moet u een wijziging in de DNS-records plannen op hetzelfde moment als de verplaatsing.

Dingen die u moet weten over de intranetsoftware en databases:

  • Maakt de intranetsoftware verbinding met de SQL Server via IP, NetBIOS of DNS?
  • Hebben de SQL Server-gebruikersaccounts die worden gebruikt door de intranet-software, verificatie beperkt tot verkeer dat afkomstig is van een IP?
  • Hebben medewerkers van uw bedrijf rechtstreeks toegang tot de SQL Server vanuit spreadsheets of rapportagetools, en zo ja, hoe definiëren zij de DSN?

Als u niet exact dezelfde IP's krijgt, of als u op een ander subnet terechtkomt, hebt u toegang nodig om de broncode of configuratiebestanden te wijzigen voor alle apps die verbinding maken met de SQL-server. Mensen kunnen een beroep doen op ongedocumenteerde en directe SQL-toegang voor ad-hocrapportage.


7
2017-08-23 12:20





Gebruik uw "Disaster Recovery" -servers. Schakel over naar hen om de lading te verwerken terwijl u uw productieservers verplaatst. Met correct geconfigureerde DR-apparatuur kunt u de verhuizing in het midden van de dag uitvoeren zonder veel downtime te zien (maximaal 15 minuten). Omdat de noodherstelservers op dezelfde manier moeten worden geconfigureerd als de productieservers. Als je geen DR-apparatuur hebt, raad ik je aan ze te kopen.

Zie het op deze manier: terwijl je korvet zich opmaakt, gebruik je minivan om de dag door te komen.


2
2017-08-23 14:39



Je veronderstelt veel over een bedrijf dat een onervaren beheerder verrast met drie servers. - RoadieRich
Absoluut, ik veronderstel een volledig functionerend correct opgezet serverlab. Of op zijn minst een plaats met een aantal oude servers (of zelfs pc's) die nog steeds rondvliegen met het verzamelen van stof. Re-config hen enkel om de beweging te doen. - Software_Programineer


Een ding dat volgens mij niet is genoemd, is fysieke beveiliging van het nieuwe huis van de servers. Waar was de kamer vroeger voor en wie heeft er sleutels voor? Is er voldoende beveiliging (alarmsystemen, camera's, etc.).


1
2017-08-24 01:27





Enkele overwegingen naast de andere antwoorden:

  • Zijn de applicaties gekoppeld aan andere via e. g. nachtelijke uitwisseling van gegevens per bestand of via webservices? Wat zijn de gevolgen wanneer de applicaties niet beschikbaar zijn? Kunnen gerelateerde applicaties hiermee omgaan of falen ze of produceren ze zelfs verkeerde resultaten door een gebrek aan informatie uit je applicaties?

  • Is downtime acceptabel voor uw gebruikers, bedrijf of zelfs klanten? Hoe lang kan het zijn?

  • Ik denk dat het een goed idee is om een ​​plan voor een rollback te hebben. U kunt het gebruiken in geval van een probleem dat niet snel kan worden opgelost, e. g. een netwerkprobleem. U moet waarschijnlijk de verhuizer beschikbaar houden voor het geval dat de hardware wordt teruggebracht.

  • Leiden uw applicaties tot hoog netwerkverkeer en moet het netwerk hiervoor worden voorbereid (waarschijnlijk veel minder waarschijnlijk dan problemen met adressen en firewalls)? Als u realtimetoepassingen hebt (bijv. Videoconferentiesoftware), zijn de latenties belangrijk.

  • De servers moeten in het serverrack passen als u er een hebt.


1
2017-08-27 09:11