Planowanie katastrofy


18

Pracuję dla małej firmy marketingowej, która zajmuje się również projektowaniem i tworzeniem stron internetowych. Obsługujemy wszystkich naszych klientów zajmujących się projektowaniem i tworzeniem stron internetowych na dedykowanym serwerze Hostgator. Mamy dedykowany serwer ze skonfigurowanymi dyskami twardymi RAID 1. Wykonujemy również cotygodniowe kopie zapasowe, które są zautomatyzowane przez cPanel i pobrane lokalnie przez automatyczne oprogramowanie FTP.

Dzisiaj rozmawialiśmy o tym, co byśmy zrobili, gdyby Hostgator miał jakąś katastrofalną awarię. Może to oznaczać eksplozję serwera, Hostgator miał poważne problemy z siecią, FBI wykonało jeden ze swoich słynnych „raidów na każdym serwerze, który widzimy”, naloty itp. Zasadniczo w każdym scenariuszu, w którym spodziewana jest przedłużona awaria. Następnie przenieśliśmy go na wyższy poziom i zastanawialiśmy się, co byśmy zrobili, gdyby Hostgator miał dłuższą przerwę w działaniu i nie byliśmy w stanie uzyskać dostępu do naszych lokalnych kopii zapasowych. Może to być spowodowane pożarem, powodzią itp. Wiem, że szanse na to, że nasz serwer nie będzie działał przez dłuższy czas, a nasze lokalne pliki jednocześnie będą niedostępne, są zdalne, ale wystarczy tylko dwazłe rzeczy się wydarzyły i właśnie tam moglibyśmy stać. (Jeśli kiedykolwiek zdarzyło Ci się zepsuć oponę i odkryłeś, że twój zapasowy był płaski lub brakuje go, wiesz, jak łatwo jest, gdy dwie złe rzeczy zdarzają się jednocześnie, naprawdę jest).

Nie trzeba dodawać, że chcemy być przygotowani na wydarzenia typu „najgorszy scenariusz”, ponieważ prawie na pewno wyeliminowałoby nas to z biznesu. Więc moje dwa pytania to:

  1. Co możemy zrobić, aby przygotować się na przedłużającą się awarię hostgatora? Idealny scenariusz sprawi, że strony internetowe naszych klientów i, miejmy nadzieję, e-maile, zostaną szybko uruchomione ponownie.

  2. Co zawiera solidny plan tworzenia kopii zapasowych, aby ważne dane nigdy nie zostały utracone? Idealne rozwiązanie zostanie zautomatyzowane.

Możesz założyć, że koszt nie jest problemem w twoich odpowiedziach, ale im tańsze są rozwiązania, tym lepiej.


Wygląda na to, że odpowiedzi tutaj obejmują już wiele dobrych stron. Mogę ręczyć, że chmura Amazon jest bardzo ekonomiczna jako rozwiązanie zapasowe do tego momentu. Nie wiadomo, co przyniesie przyszłość, ale jeśli nic więcej, to dobry sposób, aby dowiedzieć się, jak działa chmura.
JMC

Oto kalkulator szacowanego kosztu dla AWS, jeśli jeszcze go nie spotkałeś: kalkulator.s3.amazonaws.com/calc5.html
JMC

@John Conde: jakie były Twoje doświadczenia z HostGator, jakieś poważne przestoje? Jeśli tak, jak długo pamiętałeś o poważnych przestojach?
Marco Demaio,

@Marco Demaio, w Hostgator nie mieliśmy żadnych przestojów. Są niezwykle niezawodni, a ich wsparcie jest fantastyczne.
John Conde

Odpowiedzi:


15

Sugerowałbym, abyś:

  1. Automatycznie wykonaj kopię lustrzaną całej zawartości i konfiguracji głównego serwera na pomocniczym serwerze kopii zapasowych w całkowicie oddzielnej sieci w innym centrum danych. Użyj RSync, FXP, cPanel voodoo lub dowolnej innej metody automatyzacji synchronizacji.

  2. Użyj przełączania awaryjnego DNS, aby automatycznie kierować ruch do serwera zapasowego, jeśli serwer Hostgator nie będzie odpowiadał.

Oznacza to, że zawsze masz „gorącą” kopię zapasową, która czeka na najgorsze, a nie „zimną” kopię zapasową, która wymaga ręcznej interwencji oraz dużo grzebania i panikowania. Oznacza to również, że Twoi klienci nigdy nie dowiedzą się, że ich witryna nie działała wcześniej, co może być niepokojące dla wszystkich.

Możesz skonfigurować DNS trybu failover za pomocą dostawcy, takiego jak DNS Made Easy . Dla każdej hostowanej domeny skonfigurujesz do pięciu zapasowych adresów IP, po jednym dla każdego serwera kopii zapasowych. Gdy to zrobisz ...

  1. Usługa DNS Made Easy sprawdza serwer główny co dwie do czterech minut, a jeśli nie wykryje odpowiedzi, kieruje ruch na dodatkowy adres IP.

  2. Usługa DNS Made Easy nadal sprawdza serwer główny. Kiedy się pojawi, przekieruje ruch na pierwszy serwer lub - jeśli wolisz - zatrzyma go podczas tworzenia kopii zapasowej podczas diagnozowania, co poszło nie tak i napraw serwer podstawowy.

Oczywiście to rozwiązanie podniesie koszty operacyjne, które w jakiś sposób będziesz musiał przenieść na klientów, ale - jeśli działasz w branży, w której przestój spowodowałby, że przestaniesz prowadzić działalność - opłacenie znacznie zbędnego serwera jest prawdopodobnie warte po raz pierwszy ratuje firmę.

Ponadto:

Duplikat, duplikat, duplikat

Im więcej niezależnych kopii zapasowych masz, tym lepiej. Przechowuję zdalne kopie zapasowe na lokalnym dysku twardym, który jest dublowany na zewnętrzny dysk twardy, Dropbox, repozytorium git i zdalne konto FTP. Nie ryzykuj. Zduplikuj jak najwięcej. Jeśli musisz przywrócić dane z ręcznej kopii zapasowej, lepiej mieć wybór pięciu niż jednego. Paranoja jest niedoceniana.

Przećwicz przywracanie kopii zapasowych ręcznie

Jeśli nigdy nie próbowałeś odzyskać danych po jednej z kopii zapasowych, skąd wiesz, że działają? Warto wykonywać ćwiczenia awaryjne, aby zobaczyć, co się stanie, jeśli zawiodą zautomatyzowane procedury.


AKTUALIZACJA: Kilka innych usług, które niedawno odkryłem, o których warto wspomnieć w związku z tworzeniem kopii zapasowych witryn, odzyskiwaniem po awarii i utrzymywaniem czasu dostępności:

  • Cloudflare, który zapewnia funkcje bezpieczeństwa i buforowania, aby utrzymywać witryny w stanie awarii, gdy serwer przestaje działać. (Odzwierciedlają twoją witrynę i udostępniają ją z globalnie rozproszonej pamięci podręcznej zamiast bezpośrednio z serwera).
  • Codeguard, który zapewnia automatyczne tworzenie kopii zapasowych i przywracanie kodu strony (tylko FTP).
  • Site Auto Backup, który zapewnia automatyczne kopie zapasowe i wycofywanie kodu witryny, danych e-mail i informacji MySQL za pośrednictwem kopii zapasowych cPanel. Pamiętaj, że jest to uruchamiane przez Hostgator, więc niekoniecznie jest odpowiednie, jeśli hostujesz na nich również swoją witrynę, ale może pomóc innym.

W szczególności Cloudflare wygląda na użyteczne, aby uniknąć przestojów i ogólnie poprawić reakcję witryny.


Nie wiedziałem, że istniało coś takiego jak DNS. Byłby to świetny sposób na szybkie przekierowanie witryn w przypadku awarii głównego serwera.
John Conde

Doskonale nadają się również do ogólnego hostingu DNS. Kupuję domeny od mojego ulubionego rejestratora, ale do obsługi rekordów DNS używam usługi DNS Made Easy. Mają wiele serwerów nazw na całym świecie, więc strony szybko się rozstrzygają, ładują szybciej za pierwszym razem i nie spadają, gdy serwery nazw twojego rejestratora się zadławią. To też nie jest takie drogie.
Nick

@Nick: tutaj mówią, że przełączanie awaryjne DNS (myślę, że usługa, którą najczęściej używasz w usłudze DNS Made Easy) nie jest zalecane: serverfault.com/questions/60553 / ... Co sądzisz?
Marco Demaio

@Marco Słusznie podkreślają, że nie jest on niezawodny, ale sprawdził się w przypadku kilku małych aplikacji internetowych, którymi zarządzam.
Nick

1
Nawiasem mówiąc, Stack Exchange również korzysta z przełączania awaryjnego DNS. Główne centrum danych znajduje się w New Yourk, drugie w Oregon. meta.stackexchange.com/a/231138/238706 meta.stackexchange.com/q/207653/238706
Palec

6

Odzyskiwanie po awarii może być ogromnym zadaniem, szczególnie w przypadku wielu serwerów, witryn i baz danych. Dwa kluczowe elementy, które należy wziąć pod uwagę przy wyborze wybranego rozwiązania, to cele dotyczące czasu odzyskiwania (RTO) i cele punktu odzyskiwania (RPO).

RTO jest zasadniczo oczekiwaniem, ile czasu powinno zająć, zanim strony zostaną ponownie utworzone. Jeśli masz RTO na minutę lub dwie (lub mniej), powinieneś rozważyć rozwiązanie zgodne z sugestią Nicka, które obejmuje replikację plików i danych w czasie rzeczywistym do dodatkowego centrum danych i automatyczne przełączanie awaryjne DNS, które mogłoby można to zrobić za pomocą usługi płatnej lub sprzętu w obu centrach danych (takich jak BIG-IP Global Traffic Managerz sieci F5. Może to być kosztowne, ale w dużej mierze zależy od odpowiedzi na pytanie „Jaki jest koszt przestoju?” Jeśli Twój RTO trwa kilka godzin lub nawet kilka dni, możesz rozważyć procedury odzyskiwania po awarii, które mogą wymagać większego ręcznego zaangażowania, takiego jak przełączanie serwerów w tryb online, przełączanie DNS itp. Żmudne, ale z pewnością opłacalne, jeśli Twój RTO na to pozwala.

RPO to w zasadzie częstotliwość wykonywania kopii zapasowych i ilość danych, które chcesz stracić w razie katastrofy. Jeśli zmiany treści i / lub danych zdarzają się często, istnieje prawdopodobieństwo, że RPO może wynosić kilka minut lub godzin i może zajmować się replikacją w czasie rzeczywistym lub kopiami zapasowymi o wysokiej częstotliwości. Jeśli treść nie zmienia się tak często lub masz klientów, którzy niekoniecznie dbają o to, że tracą dane na kilka dni, kopie zapasowe mogą zdarzać się rzadziej.

Jak wspomniałem, zgadzam się w dużej mierze z tym, co Nick miał do powiedzenia. Inną alternatywą, którą możesz rozważyć, jest wykorzystanie usług chmurowych od jednego z większych dostawców chmurowych, takich jak Rackspace lub Amazon. W szczególności obaj dostawcy mają ogromną infrastrukturę, aby móc poradzić sobie z każdą katastrofą. W przypadku czegoś takiego jak witryna w chmurze lub serwer w chmurze (terminy używane przez Rackspace) masz tę zaletę, że możesz także skalować i nie musisz martwić się fizycznym aspektem tego sprzętu.

Rackspace oferuje również niestandardowe opcje, w których można zmiksować infrastrukturę, składając się z kombinacji serwerów chmurowych, serwerów fizycznych i plików chmurowych jako części rozwiązania. Podejście hybrydowe może być czymś do rozważenia w zależności od potrzeb klienta, jeśli nie chcesz stosować jednego uniwersalnego podejścia.

Jeśli to pomoże, na stronie Rackspace znajduje się strona poświęcona odzyskiwaniu po awarii, którą można znaleźć tutaj . (Również dla przypomnienia, nie jestem związany z Rackspace, ale korzystałem z ich usług w przeszłości).

Mam nadzieję, że to pomogło.

EDYCJA : Pomyślałem, że to może pomóc, jeśli oceniasz rozwiązania chmurowe. Raport Gartner Magic Quadrant dotyczący infrastruktury oraz usługi i hostingu może dać ci wgląd w innych dostawców rozwiązań.


Nigdy nawet nie zastanawiałem się nad użyciem hostingu w chmurze jako „serwera” zapasowego. Byłby to bardzo ekonomiczny sposób na szybkie przygotowanie kopii zapasowej.
John Conde

2

Najbardziej oczywistym rozwiązaniem wydaje się pełna replikacja serwera w innym obiekcie innej firmy hostingowej.

Pliki mogą być synchronizowane z narzędziami takimi jak rsync i unison. Kopie zapasowe SQL można również zsynchronizować, a następnie przesłać do bazy danych slave za pomocą skryptów.


1

Upewnij się, że korzystasz z kontroli wersji całego kodu za pomocą repozytorium kodu źródłowego (SVN lub GIT). Czy używasz SVN lub GIT?

Możesz uzyskać konto (bezpłatne lub płatne) w repozytorium strony trzeciej, takim jak Project Locker , a jeśli wersja całego kodu jest wykonywana podczas pracy, zasadniczo masz kopię zapasową wszystkich danych w repozytorium, które znajduje się w trzeciej lokalizacji . W ten sposób dodatkowo zmniejszasz swoje szanse (prawie do zera) utraty całej pracy na raz.

Możesz wykonać swoje zatwierdzenia / wypłaty SVN za pomocą wiersza poleceń lub klienta takiego jak Versions (dla komputerów Mac) lub TortoiseSVN (dla systemu Windows).


Jedyny problem z repozytorium kodu źródłowego, nie tworzy kopii zapasowej bazy danych ani żadnych plików przesłanych przez użytkownika itp.
Daveo

Prawdziwe. Ale możesz utworzyć plik zrzutu bazy danych i dodać go do repozytorium. Możesz nawet napisać skrypt, aby uczynić to procesem automatycznym. Z bazą danych lub bez niej jest co najmniej jeszcze jedno miejsce na kopię zapasową kodu i zasobów, przy czym główną zaletą jest kontrola wersji wszystkich tych elementów.
Joel Glovier

Niestety nie używamy kontroli wersji. W rzeczywistości, zanim tu zacząłem, cała praca została wykonana na stronie na żywo! Udało mi się stworzyć lokalne środowisko programistyczne, więc przynajmniej oficjalnie nie ma praktyki.
John Conde
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.