Przeprowadź migrację serwera na żywo

Mam problem , mam działający serwer ze zwykłymi usługami (httpd, mail, sql) i wygląda na to, że muszę być naprawdę szybki, aby zapobiec całkowitej utracie danych (moja macierz RAID zawiodła, więc jestem zależny od jednego HDD teraz).

Cały system zbudowany w oparciu o instrukcje HowtoForge, a kiedy czytam ten w Squeeze , wygląda na to, że mogę z łatwością? migruj moich (wirtualnych) użytkowników do nowego urządzenia.

Naprawdę wiem, że to bardzo specyficzny problem, ale czy mógłbyś mi powiedzieć coś ważnego o całym procesie migracji. Które rzeczy mogą być trudne, gdzie powinienem się skupić? Jak rozpoczniesz ten proces?

Niektóre informacje w tle:

• Dwa serwery są oddalone od siebie o 200 km, więc migracja powinna odbywać się przez Internet
• Oba serwery to Debian, stary to Etch, nowy to Squeeze
• Kluczową usługą jest poczta, strony mogą zostać zawieszone na pewien czas
• RAID oznacza dwa dyski w RAID 1 (oba komputery)
• Stare pole to DNS1 dla wszystkich hostowanych domen

Mój (naprawdę) podstawowy zarys:

• Budowanie podobnego systemu jak stary (podobna struktura wirtualnej poczty, hasła przechowywane z tym samym typem szyfrowania, ponieważ nie mogę powiedzieć starych)
• utwórz jedną domenę, w której mogę sprawdzić, czy wszystko jest w porządku (DNS, e-mail, www są w porządku)
• Migruj domenę po domenie, aż stara nic nie zrobi

Moje martwe pola:

• Nie możesz znaleźć krótkiego opisu, jak zrobić RAID-1 na Squeeze (wystarczy Lenno howto?)
• Jak skopiować określone foldery (np. Foldery poczty użytkowników) z określonymi prawami użytkownika, gdy są potrzebne? (rsync to zrobi?)
• Jak skonfigurować DNS na nowym komputerze (stary to DNS1) (nowy komputer również powinien być DNS, a migrowane domeny powinny używać się jako DNS1?)
• Jak mogę zapobiec utracie wiadomości e-mail (z powodu czasu odświeżania DNS) (muszę skonfigurować nową maszynę jako MX?)

Twój podstawowy zarys jest mniej więcej poprawny.

Instalator squeeze dobrze wykona programową macierz RAID. Jedną z różnic jest to, że squeeze domyślnie używa grub2; Lenny użył grub-legacy (chyba 0.9). To sprawia, że ​​niektóre administrowanie GRUB jest nieco inne, szczególnie jeśli chodzi o zapewnienie, że GRUB uruchomi się z obu dysków w przypadku awarii. Zawsze możesz powrócić do grub-legacy, co właśnie skończyło się ostatnim razem, gdy napotkałem ten problem. Opłaca się przetestować wszystko, co robisz, aby upewnić się, że możesz zrestartować komputer, jeśli któryś z dysków ulegnie awarii.

Aby skopiować dane między, na pewno użyj rsync. Upewnij się, że najpierw skonfigurowane są odpowiednie konta z tymi samymi identyfikatorami użytkowników, a następnie rsync, ale zawsze możesz to później naprawić. rsync -avPHAX powinien uzyskać wszystko (-a dostaje większość rzeczy, z wyjątkiem -H [ard links] -A [CLs] i -X [atrybuty pielęgnowane], więc jest to przydatne.

Biorąc pod uwagę, że jednocześnie przeprowadzasz skuteczną aktualizację, przygotuj się na awarie usług w subtelny sposób. Konfiguracje nieznacznie się zmienią. Po zrobieniu czegoś podobnego ostatnio, myślę, że wolałbym przeprowadzić migrację typu Like->, a następnie uaktualnić hosta końcowego jakiś czas po fakcie, ponieważ migracja wszystkiego i zarządzanie aktualizacjami w tym samym czasie uczyniło z niego gigantyczne zadanie.

Zaktualizowano o dodatkowe punkty bólu:

W przypadku DNS w jednym kroku przeniosę cały hosting DNS na nową maszynę. Pozostaw rekordy na początku, ale od razu ustaw odświeżanie (około 10 minut). Daje to możliwość przeniesienia rekordów DNS na nowy komputer po zakończeniu przenoszenia każdej domeny. Przeniesienie DNS może wymagać aktualizacji rekordów whois dla wszystkich domen, które hostujesz, więc pamiętaj o tym. Ustaw teraz odświeżanie dla wszystkich domen, zanim zaczniesz cokolwiek innego - nic gorszego niż posiadanie źle zbuforowanego wyniku powodującego problemy.

Odnośnie utraty wiadomości e-mail: przenosząc pocztę na nowy serwer, upewnij się, że rekordy DNS zostały zaktualizowane, aby wskazywały główny MX na nowy serwer, i upewnij się, że stary serwer jest nadal skonfigurowany, aby umożliwić przekazywanie w twoich domenach. Tak długo, jak zarówno stary, jak i nowy serwer mają aktualne widoki DNS, twoja usługa pocztowa na starym serwerze będzie działać, nie będzie już podstawowym MX i przekaże wszelkie wiadomości e-mail na nowy podstawowy. Poczta poradzi sobie również z krótkimi opóźnieniami w dostarczaniu - abyś mógł po prostu zamknąć lub zaporę dostępu do wszystkich komputerów na obu komputerach, przenieść wszystko naraz, przetestować na nowej maszynie, a następnie przenieść rekordy MX i otworzyć pocztę na nowej maszynie . SMTP jest zaprojektowany do obsługi awarii, a wszelkie rozsądnie krótkie przerwy (mniej niż 4 godziny, jak sądzę) nawet nie generują tymczasowych powiadomień o błędach.

Zaktualizowano, aby dodać:

Inną możliwością jest utworzenie maszyny wirtualnej na nowym serwerze i zsynchronizowanie całego starego serwera z obrazem dysku nowej maszyny wirtualnej. Następnie można odpalić maszynę wirtualną i zaktualizować adresy IP itp., A także mieć w pełni działającą replikę oryginalnego serwera wewnątrz tej maszyny wirtualnej. Potencjalnie dużo mniej wysiłku, ale jeśli nie znasz stosów maszyn wirtualnych, takich jak KVM lub Virtualbox, być może nie warto.