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.
Odpowiedzi:
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.
źródło
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.
źródło
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.
źródło
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:
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.
Najpierw przenieś Machine3 .
Ścieżka A: (opcjonalnie):
Przenieś maszynę 2 .
[Ś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ę:
Przenieś maszynę 1 .
źródło
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:
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.
źródło
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ń.
źródło
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.).
źródło
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.
źródło