Skopiuj hosta Linux na nowy sprzęt


13

Muszę przeprowadzić migrację hosta do hosta ze starego sprzętu na nowy. W szczególności od HP BL460G7 do HP BL460G8. Zarówno stary, jak i nowy serwer mają dyski 2 x 600 GB 2,5 "i są skonfigurowane dla RAID 1. Mogę sobie pozwolić na 30 minut przestoju na serwer.

Do migracji są cztery serwery, najmniejszy ma w sumie 120 GB przydzielonych w woluminach logicznych, a największy ma przydzielone 510 GB. Trzy serwery działają na RHEL5, a jeden na RHEL6.

Rozmyślałem nad tym, jak to zrobić w określonym czasie i bez niszczenia systemu operacyjnego i krytycznych danych.

Moją jedyną myślą jest:

  • usuń jeden dysk ze starego serwera (serwer jest włączony)
  • usuń oba dyski z nowego serwera (serwer jest wyłączony)
  • wyjmij dysk G7 z wózka i odłóż na bok
  • wyjmij dysk G8 z ​​caddy i zainstaluj w caddy G7
  • zainstaluj dysk G8 w caddy G7 na starym serwerze
  • poczekaj, aż kontroler RAID odbuduje macierz RAID1
  • po zakończeniu zamknij stary serwer
  • usuń dysk G8 z ​​caddy G7
  • zainstaluj dysk G8 w caddy G8 i włóż do G8 (zainstalowany pojedynczy dysk)
  • uruchom serwer G8
  • poczekaj na uruchomienie systemu operacyjnego
  • po uruchomieniu systemu operacyjnego włóż pozostały dysk
  • poczekaj na przebudowanie macierzy RAID

Czy to brzmi rozsądnie?

EDYCJA: RHEL5 to RHEL5.10, a RHEL6 to RHEL6.6

Powinienem również zauważyć, że dwa systemy są częścią gorącego klastra z czterema węzłami, który wykonuje niemal ciągłą replikację „zdarzeń” aplikacji (jego część systemu infrastruktury krytycznej). Mamy kopie zapasowe, ale używamy ich tylko w przypadku całkowitej awarii systemu.

Poprzednie testy wykazały, że maksymalne „dd” między systemami wynosi około 50 MB / s, co jest zdecydowanie zbyt wolne.

EDYCJA: Zamierzałem polegać na kudzu przy odbiorze i radzić sobie ze zmianami sprzętowymi.


Jakie konkretne wersje RHEL5 i RHEL6 są używane?
ewwhite

Odpowiedzi w edycji
użytkownik1174838

Nie próbuj dopasowywać dysków G7 do serwera Gen8 - zmieniło się coś więcej niż tylko fizyczny podajnik.
Chopper3

Celowa degradacja macierzy RAID z ważnymi danymi nie brzmi jak dobry plan.
kasperd

Odpowiedzi:


18

Należy zauważyć, że mogą być konieczne inne kroki, w zależności od dystrybucji. Przede wszystkim sterowniki (dzięki za wskazanie tego na @ewwhite).

  1. Uruchom nowy serwer z livecd / usb.
  2. Przygotuj partycje i bootblock na nowych dyskach.
    • W zależności od konfiguracji można to zrobić, kopiując MBR / bootblock.
  3. Utwórz systemy plików.
  4. Wykonaj rsync ze starego serwera na nowy.
    • Możesz to zrobić ponownie, aby zobaczyć, jak długo potrwa rsync kontrolny - jeśli będzie trwał mniej niż 30 minut, kontynuuj.
    • To jest czas, którego możesz spróbować, jeśli uruchomi się nowy system. Uważaj tylko, aby nie spowodować żadnych konfliktów adresów IP (lub innych).
  5. Zamknij wszystkie usługi, które zapisałyby do systemu plików
    • Najlepiej zrestartuj do livecd / usb
  6. Ponownie zsynchronizuj dane ze starego serwera do nowego
  7. Uruchom ponownie nowy serwer i użyj go

Robiąc to w ten sposób, oryginalny serwer pozostaje nienaruszony, więc jeśli coś pójdzie nie tak, istnieje łatwy sposób powrotu. Wymaga to jednak pewnej wiedzy (grub / rsync / partitions), dlatego sugeruję wykonanie wcześniejszej pracy przygotowawczej i przetestowanie przed uruchomieniem na żywo.


Rzeczywiście istnieją różnice między sterownikami między tymi dwiema platformami, dlatego ważne jest, aby wiedzieć, jakich mniejszych wersji RHEL używa.
ewwhite

Ach tak, nie powinienem odpowiadać na nic związanego z dystrybucją korporacyjną ... przepraszam za to ...
Fox

@ Fox: Nieusunięty przez popularne zapotrzebowanie. Twoja odpowiedź jest dobra.
Sven

1
@ user1174838 to nie powinno być przeszkodą ... Jedyny problem, jaki zobaczyłem, to bardzo duża liczba małych plików.
Fox

1
I nie zapomnij o tym cudownym rozwiązaniu, że podwójne rsync minimalizuje przestoje serwera: ponieważ większość danych jest przesyłana na działającym serwerze, drugi rsync (na serwerze obecnie nieczynnym) kopiuje tylko najnowsze różnice.
peterh - Przywróć Monikę

6

Dwie rzeczy:

  • Chciałbym zbudować dane od nowa i rsync.
  • Przydział / czas przestoju wydaje się zbyt krótki. 30 minut może pracować w określonych sytuacjach, ale nie powinny TY być dyktując realistyczny wymóg przestojów w oparciu o to, czego potrzeba, aby rzeczywiście osiągnąć pracę?

W zależności od danych zawartych na każdym serwerze, ilości odrzucanych danych i schematu udostępniania, może być sensowne zainstalowanie niezbędnego systemu operacyjnego na nowym Gen8 ProLiant i zsynchronizowanie ustawień i innych części danych w punkcie, w którym można wyciszyć dane.

Być może wykonaj kopię źródłową i określ wymagania dotyczące czasu przestoju na podstawie czasu potrzebnego na pobranie zmian plików w kolejnych rsyncs. Jeśli potrzebujesz przyspieszyć proces przesyłania lub masz dużo małych plików, możesz w tym pomóc .

Często wykonuję tego rodzaju przejścia. Przy podobnych instalacjach Linuksa rzadko potrzebujesz więcej niż dokładnej listy pakietów (łatwo dostępnej za pomocą Yum lub RPM), katalogów konfiguracji (np. /etc) I partycji danych. Jeśli nie masz jeszcze systemu administracyjnego kickstart, możesz skorzystać z /root/anaconda-ks.cfgpliku, aby dowiedzieć się, jak zbudowano system G7.

Jest to absolutnie możliwe, aby odpowiedzieć na pytanie dotyczące zwykłego przenoszenia dysków w oparciu o określone wersje RHEL, o których wspomniałeś. Możesz przenosić dyski / nośniki, a metadane HP Smart Array są kompatybilne między kontrolerami P410 i P420, które mogą znajdować się w twoim systemie. Nie zrobiłbym tego jednak bez pełnej aktualizacji oprogramowania wewnętrznego napędów i komponentów w nowym systemie.


Bardzo dobre komentarze w tym wątku, dzięki wszystkim. Wrócę do PM i poproszę o większe okno zmian.
user1174838,

1

Jeśli Twoja poprzednia wersja systemu operacyjnego była w stanie obsłużyć nowy sprzęt (głównie kontroler RAID), możesz spróbować CloneZilla .

Aby sprawdzić, czy jest możliwe przejście z jednego sprzętu na inny, można przekazać wszystkie dane ze starego na nowy serwer, wykonując kilka sztuczek z dd.

Uruchom nowy serwer z dystrybucją na żywo, taką jak SystemRescueCD , skonfiguruj za pomocą adresu IP i polecenia dd, takiego jak ten:

nc -l 8000 | dd of=/dev/sda

Na bieżącym serwerze wykonaj

dd if=/dev/sda | nc ${newserverip} 8000

Spowoduje to utworzenie nieprzetworzonej kopii twojego / dev / sda twojego serwera na nowym serwerze / dev / sda. W ten sposób możesz przeprowadzić test bez przestoju na oryginalnym serwerze i podjąć ryzyko niemal zerowe.


2
Jeśli pozostawisz procesy uruchomione na starym serwerze, które zapisują pliki na starym dysku, szczególnie serwery baz danych i podobne, istnieje bardzo duże prawdopodobieństwo, że spowoduje to uszkodzenie systemu plików (skopiowanie) i uszkodzenie danych w (skopiowanych) plikach. Nigdy nie dodawaj surowego dysku, chyba że jest on zamontowany lub zamontowany tylko do odczytu.
Guntram Blohm wspiera Monikę

@GuntramBlohm Wiem, to po prostu sprawdzić, czy możesz sklonować stary serwer na nowy, bez donwtime. Po przetestowaniu możesz sklonować serwer, oczywiście zamykając go lub zatrzymując kluczowe usługi.
alphamikevictor

Kopiowanie danych między systemami CloneZilla i powiązane techniki potrwają dłużej niż 30 minut.
user1174838

0

Kierownik projektu odrzucił moją prośbę o większe okno awarii.

Proponowana procedura opisana w pytaniu sprawdziła się w testowaniu. Przestój wynosił poniżej 20 minut. Użyłem narzędzia hpacucli do monitorowania postępu na G7, a następnie Gen8, było to bardzo przydatne.

Jeszcze nie zrobiłem tego w gniewie, ale jak już wspomniano, sprawdził się dobrze w testach dla RHEL 5.10 na BL460G7 do BL460 Gen8.

Nie zaktualizowałem oprogramowania układowego.

Początkowa ponowna synchronizacja RAID1 w G7 zajęła nieco ponad godzinę. Ponowna synchronizacja w Gen8 zajęła mniej niż 50 minut. To mnie niepokoiło, ale nie znalazłem żadnych problemów.

Jeszcze raz dziękuję za wszystkie pomocne komentarze i sugestie.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.