Przenoszenie serwerów w tym samym budynku

Oto mój scenariusz: Jestem programistą, który odziedziczył (bez mojej wiedzy) trzy serwery znajdujące się w moim biurze. Odziedziczyłem też pracę jako administrator serwerów z wyraźnym brakiem wiedzy na temat administrowania serwerami i jako punkt odniesienia google / ServerFault. Na szczęście nigdy nie musiałem fizycznie stykać się z maszynami ani rozwiązywać problemów, ponieważ zawsze „po prostu działały”.

Wszystkie trzy maszyny znajdują się w tym samym pomieszczeniu danych i służą do następujących celów:

Machine1- IIS 8.0 obsługujący wiele aplikacji wewnętrznych
Machine2- Magazyn danych SQL Server 2008 R2 dla aplikacji wewnętrznych
Machine3- Magazyn kopii lustrzanych SQL Server 2008 R2Machine2

Wszystkie trzy mają podłączone zewnętrzne dyski twarde, które często wykonują kopie zapasowe.

Zostałem poinformowany, że wszystkie trzy muszą przenieść się z jednego pokoju danych do drugiego w tym samym lokalu. Nie będę kończył fizycznego przenoszenia sprzętu, którym zajmie się kompetentny wnioskodawca.

Oprócz wykonania pełnej kopii zapasowej każdego z nich, jakie kwestie muszę wziąć pod uwagę przed hipotetycznym przesunięciem przełącznika zasilania i obserwowaniem, jak mój świat się porusza?

^{Wiem, że dalekie od ideału jest posiadanie wszystkich trzech w tym samym pokoju / lokalu, ale jest to poza zakresem tego pytania.}

Naprawdę ciekawe pytanie, dobrze zadane :)

Jest kilka rzeczy, które musisz sprawdzić przed tym ruchem, niektóre łatwe, niektóre trudne.

Zasilanie - sprawdź, czy nowe pomieszczenie ma nie tylko odpowiednią liczbę gniazd zasilających, ale czy są odpowiedniego typu - jak w fizycznym typie złącza i czy bieżąca lokalizacja pozwala na różne fazy zasilania na serwer w celu ochrony przed awarią jednofazową, a następnie I zdecydowanie zachęcam do skopiowania tego również w nowej lokalizacji.

Chłodzenie - musisz sprawdzić, czy nie nastąpi natychmiastowe lub stopniowe nagromadzenie ciepła, które doprowadzi do przegrzania i potencjalnego wyłączenia serwera. Zazwyczaj można sprawdzić maksymalną moc (w watach) lub ciepło (w BTU), którą każdy serwer może pobierać ze strony internetowej producenta - poinformuj o tym kierownika budynku i uzyskaj od nich pisemne potwierdzenie, że chłodzenie w tej lokalizacji da sobie radę .

Praca w sieci - to jest trudne - nie tylko trzeba replikować tę samą liczbę portów między starą i nową lokalizacją, ale także ich typ, szybkość i, co najważniejsze, konfiguracja. Ten ostatni punkt jest kluczem - był czas, kiedy prawie wszystkie porty w sieci były prawie równe - jestem wystarczająco dorosły, aby zapamiętać te czasy! ale w dzisiejszych czasach liczba konfiguracji portów i miejsce w sieci, w którym może znajdować się każdy port, jest astronomiczne, musisz upewnić się, że twoi ludzie w sieci powiedzieli WSZYSTKO, aby były identyczne ze starych na nowe - ponownie otrzymaj to na piśmie, ponieważ to nie jest łatwe. Jeśli coś pójdzie nie tak z tym ruchem, położyłbym pieniądze, że nie będą identyczne na portach sieciowych, to dzieje się cały czas.

„Inne połączenia” - czy wiesz, czy twoje serwery mają inne połączenia niż zasilanie i sieć? być może mają łącza Fibre Channel do pamięci współdzielonej, linki KVM do ekranu wspólnego zarządzania - ponownie, jeśli trzeba, należy je replikować identycznie.

Poza tym nie wahaj się wrócić tutaj z bardziej szczegółowymi pytaniami i mam nadzieję, że ten ruch się powiedzie.

Inne odpowiedzi dotyczą technicznych aspektów przeprowadzki. Być może będziesz musiał rozważyć kilka innych rzeczy.

Upewnij się, że użytkownicy wiedzą, że ich aplikacje będą wyłączone podczas przenoszenia. Będziesz chciał zaplanować przeprowadzkę, być może poza godzinami pracy, aby zminimalizować liczbę dotkniętych nią osób.

Poproś kompetentną osobę (lub osoby) o przetestowanie aplikacji po uruchomieniu serwerów. Poproś ich o sprawdzenie poprawności, aby upewnić się, że aplikacje działają zgodnie z oczekiwaniami.

Po zakończeniu testu poinformuj użytkowników, że przenoszenie zostało zakończone, i poinformuj ich, jeśli mają jakieś problemy.

Jest to dość trudne do określenia i graniczne jako „zbyt szerokie” dla naszego formatu. Najważniejszą rzeczą, którą musisz sprawdzić, jest konieczność ponownej konfiguracji sieci w taki sposób, aby mogła nadal działać z tymi samymi adresami. Nawet jeśli mogą zachować te same adresy, upewnij się, że nie są skonfigurowane przez DHCP i / lub sprawdź, czy serwer DHCP będzie dostępny w nowej lokalizacji.

Uwaga dodatkowa: Jak już wspomniano, posiadanie serwera SQL i jego kopii lustrzanej jest dalekie od ideału. Jednak posiadanie dysków zapasowych w tej samej lokalizacji jest naprawdę niebezpieczne. Musisz mieć kopię zapasową w innym fizycznym miejscu.

Inne odpowiedzi mają dobre rozważania poprzedzające ruch. Powinieneś jednak również planować, w jaki sposób zorganizujesz faktyczny ruch. Biorąc pod uwagę fakt, że Machine3 jest kopią lustrzaną Machine2 , wygląda na to, że czas działania jest istotną kwestią dla baz danych SQL Server 2008 R2. To, że jest lustrem, daje ci taką możliwość. Powód istnienia kopii lustrzanej ma być dostępny, gdy serwer podstawowy nie jest. Obejmuje to niedostępność z powodu konserwacji, która obejmuje przeprowadzkę.

Zrób plan:
powinieneś sporządzić pisemny plan, w jaki sposób zostanie przeprowadzony ruch. Konieczne może być dostarczenie tego planu lub jego części osobom zajmującym się częściami pracy (np. Przeprowadzkami). Plan ten powinien obejmować wszystkie działania poprzedzające ruch, faktyczny ruch i działania po ruchu (np. Weryfikacja funkcjonalności).

Przenieś podstawy:

1. Przenieś Machine3 (serwer lustrzany programu SQL Server): Uzyskaj pełną funkcjonalność. Sprawdź ponownie synchronizację.
2. Przenieś Machine2 : Uzyskaj pełną funkcjonalność.
3. Przenieś maszynę1 : Spraw, by była w pełni operacyjna.

Bardziej szczegółowy opis przeprowadzki:

Poniżej przedstawiono dwie metody (Ścieżka A i B) korzystania z Komputera 3 do testowania połączeń dla Komputera 1 i / lub Komputera 2 . Powinieneś użyć tylko jednej metody. Jaki sposób to zrobić, a nawet jeśli użyć, zależy od informacji nie zawartych w pytaniu (np. Fizyczna separacja końcowych lokalizacji maszyny, fizyczny rozmiar maszyn, długość przewodów sieciowych / zasilających, dostępność rozszerzeń dla tego samego, podobieństwo konfiguracji portów sieciowych, potrzeby czasu pracy itp.). Używanie Machine3 do testowania tych połączeń potencjalnie pozwala na dłuższy czas pracy dla Machine2 , ale szczególnie dla Machine1 , który nie ma lustra. Możesz wybrać jedną z tych metod lub żadną z nich.

1. Najpierw przenieś Machine3 .

   • Na razie pozostaw Machine1 i Machine2 na miejscu.
   • Backup Machine3 , a następnie wyłącz
   • Uzyskaj Machine3 całkowicie przeniesione do nowej lokalizacji.
   • [Ścieżka B:. Nie stosować, jeśli masz zamiar użyć opcjonalnego Krok 2] Jeżeli konfiguracje sieci i moc dla wszystkich urządzeń są identyczne: Umieść machine3 gdzie Machine1 planuje się skończyć za pomocą połączeń przeznaczonych dla komputera Komputer1 .
   • Uzyskaj machine3 powrotem i działa. W nowej lokalizacji sprawdź, czy działa normalnie jako kopia lustrzana Machine2 . Zapewni to fizyczną weryfikację, czy konfiguracja wszystkich problemów (zasilanie, sieć itp.) Działa w nowej lokalizacji.
   • Rozwiąż wszelkie pojawiające się problemy.
   • Sprawdź, czy machine3 całkowicie ponownie zsynchronizowane z machine2 przed kontynuowaniem.

2. Ścieżka A: (opcjonalnie):

   • Użyj Machine3, aby przetestować wszystkie urządzenia przeznaczone dla Machine2 i Machine1 .
   • Wyłącz maszynę3 i przesuń / przełącz na używanie pozycji / połączeń dla maszyny2 , (sprawdź ponownie synchronizację), a następnie maszynę1 (sprawdź ponownie synchronizację). Jeśli planujesz to zrobić, Komputer3 powinien początkowo zostać skonfigurowany z połączeniami przeznaczonymi do użytku końcowego przez Komputer1 lub Komputer2 , więc nie należy go ustawiać najpierw w końcowej lokalizacji dla Komputera3, a następnie zmieniać go 3 razy, ale tylko 2, zaczynając od korzystania z urządzeń jednej z innych maszyn.
   • Sprawdź, czy machine3 całkowicie ponownie zsynchronizowane z machine2 przed kontynuowaniem.

3. Przenieś maszynę 2 .

   • Twoja praktyka z Machine3 powinna uczynić to znacznie płynniejszym.
   • Backup Machine2 , a następnie wyłącz
   • Przenieś Machine2 do nowej lokalizacji; wykonaj wszystkie połączenia
   • Rozwiąż wszelkie pojawiające się problemy.
   • Sprawdź, czy machine2 całkowicie ponownie zsynchronizowane z machine3 przed kontynuowaniem.

4. [Ścieżka B: Nie potrzebne jeśli testowane wszystkie połączenia z machine3 w opcjonalnym kroku # 2] Jeżeli teraz mają machine3 gdzie Machine1 ma zakończyć się:

   • Wyłącz maszynę 3 .
   • Przenieś go do miejsca, w którym planowane jest zakończenie (poza miejsce, w którym ma znajdować się Maszyna1 ).
   • Rozwiąż wszelkie pojawiające się problemy.
   • Sprawdź, czy machine3 całkowicie ponownie zsynchronizowane z machine2 przed kontynuowaniem.

5. Przenieś maszynę 1 .

   • Po przeprowadzce Zarówno machine2 i machine3 (i miejmy nadzieję, że badane rzeczywiste połączenia Machine1 będą używać mając machine3 wykorzystać je tymczasowo), to powinien być płynny porusza.
   • Backup Machine1 , a następnie wyłącz
   • Przenieś Machine1 do nowej lokalizacji; wykonaj wszystkie połączenia
   • Rozwiąż wszelkie pojawiające się problemy.
   • Jeśli coś pójdzie nie tak z obiektami w pozycji, którą ma zajmować Machine1 , masz możliwość skorzystania z udogodnień, w których obecnie znajduje się Machine3 . Mam nadzieję, że jesteś już w stanie przetestować wszystkich obiektów w MACHINE1 pozycji mając już używany przez machine3 przez pewien czas (ścieżka A lub ścieżka B).

Jeśli którykolwiek z adresów IP serwerów ulegnie zmianie, a połączenia z polem SQL zostaną nawiązane za pomocą rozpoznawania DNS, konieczne będzie zaplanowanie zmiany w rekordach DNS w tym samym czasie, co przeniesienie.

Co powinieneś wiedzieć o oprogramowaniu intranetowym i bazach danych:

• Czy oprogramowanie intranetowe łączy się z SQL Server poprzez IP, NetBIOS lub DNS?
• Czy konta użytkowników programu SQL Server używane przez oprogramowanie intranetowe mają uwierzytelnianie ograniczone do ruchu przychodzącego z adresu IP?
• Czy pracownicy w Twojej firmie uzyskują dostęp do SQL Server bezpośrednio z jakichkolwiek arkuszy kalkulacyjnych lub narzędzi do raportowania, jeśli tak, to w jaki sposób definiują DSN?

Jeśli nie otrzymasz dokładnie tych samych adresów IP lub znajdziesz się w innej podsieci, będziesz potrzebować dostępu do zmiany kodu źródłowego lub plików konfiguracyjnych dla aplikacji łączących się z serwerem SQL. Ludzie mogą polegać na nieudokumentowanym i bezpośrednim dostępie SQL do raportowania ad-hoc.

Wykorzystaj swoje serwery „Disaster Recovery”. Przełącz się na nie, aby obsłużyć obciążenie podczas przenoszenia serwerów produkcyjnych. Dzięki odpowiednio skonfigurowanemu sprzętowi DR możesz przeprowadzać się w środku dnia, nie tracąc czasu na przestoje (do 15 minut). Ponieważ serwery odzyskiwania po awarii powinny być skonfigurowane w taki sam sposób jak serwery produkcyjne. Jeśli nie masz sprzętu DR, bardzo polecam je zdobyć.

Pomyśl o tym w ten sposób: gdy twoja korweta zaczyna się poprawiać, użyj minivana, aby przetrwać dzień.

Jedną rzeczą, o której nie sądzę, wspomniano, jest fizyczne bezpieczeństwo nowego domu serwerów. Do czego wcześniej używany był pokój i kto ma do niego klucze? Czy istnieje odpowiednie bezpieczeństwo (systemy alarmowe, kamery itp.).

Niektóre uwagi oprócz innych odpowiedzi:

• Czy aplikacje są powiązane z innymi aplikacjami, np. Przez nocną wymianę danych w pliku lub za pomocą usług sieciowych? Jakie są konsekwencje braku dostępu do aplikacji? Czy pokrewne aplikacje mogą sobie z tym poradzić, czy zawodzą, czy nawet generują błędne wyniki z powodu braku informacji z twoich aplikacji?

• Czy przestoje są dopuszczalne dla użytkowników, firmy, a nawet klientów? Jak długo to może potrwać?

• Myślę, że dobrym pomysłem jest mieć plan wycofania. Możesz go użyć w przypadku problemu, którego nie można szybko rozwiązać, np. Problemu z siecią. Prawdopodobnie będziesz musiał zachować dostęp do napędu w przypadku przywrócenia sprzętu.

• Czy twoje aplikacje prowadzą do dużego ruchu w sieci i czy sieć musi być na to przygotowana (prawdopodobnie znacznie bardziej mało prawdopodobny problem niż problemy z adresami i zaporami ogniowymi)? Jeśli masz aplikacje w czasie rzeczywistym (np. Oprogramowanie do wideokonferencji), opóźnienia będą ważne.

• Serwery muszą zmieścić się w szafie serwerowej, jeśli taką masz.