Uderzenie Evana ma kilka dobrych punktów, ale tutaj może być jakiś konkretny opłacalny sposób, aby uzyskać mniej niż 1 godzinę czasu regeneracji w przypadku awarii.
Małe firmy prawdopodobnie oznaczają niewielki sprzęt, więc wykonanie prostych czynności, które w znacznym stopniu zwiększą odporność na problemy, może nie być kosztowne. Główną ideą jest po prostu dodatkowy sprzęt gotowy do pracy.
Po pierwsze, usiądź wygodnie z myślą o wirtualnym adresie IP. To jest adres IP, z którym użytkownicy będą rozmawiać, ale mogą znajdować się na każdym serwerze, któremu go podasz. To jest adres IP, z którego korzystasz, a aplikacje będą chciały z nim rozmawiać. I będzie to najbardziej pomocne dla ostatecznego rozwiązania. Posiadanie konta VIP oznacza, że nie trzeba ponownie konfigurować żadnej aplikacji podczas przełączania awaryjnego. Należy również pamiętać, że nadmiarowy sprzęt ma również wpływ na zwiększenie nakładów administracyjnych, wykonując dwie aktualizacje konfiguracji zamiast 1.
Jeśli zaczniemy od routingu / serwera proxy sieci, prawdopodobnie jest to najłatwiejsze, ponieważ nie będzie to żaden rzeczywisty stan, który należy przechowywać na samym urządzeniu. Zdobądź więc duplikat tego samego pudełka i skonfiguruj to samo. Trzymałbym oba podłączone do segmentu LAN i zakładając, że Internet jest w innym interfejsie, zamień kable, jeśli są awarie. Z punktu widzenia routingu ustawiasz wszystkich klientów LAN na adres .1 (VIP) dla ich domyślnej trasy, a serwer proxy nadaje serwerowi A adres .2, a serwerowi B adres .3. W ten sposób można nimi zarządzać aktualizacjami konfiguracji (dotyczy obu). Wszystko, co musisz zrobić, aby przejść w tryb failover, to usunąć przypisanie .1 IP z .2 i przenieść je do .3 oraz przenieść połączenie internetowe do innego interfejsu. To nie jest bardzo skomplikowane, łatwe do zrobienia i zrozumienia, i kosztuje dodatkowy sprzęt drugiego pudełka. Jeśli możesz uzyskać redundancję po stronie internetowej, możesz dodać trochę złożoności i uzyskać automatyczne przełączanie awaryjne za pomocą czegoś takiego jak VRRP.
Bez szczegółów trudno powiedzieć, ale Twój serwer internetowy może być równie prosty. Dodaj drugi serwer z identyczną konfiguracją, utwórz vIP między nimi i przenieś VIP do kopii zapasowej w razie awarii. Zasadniczo nie mam nic przeciwko utracie stanu sesji po przełączeniu awaryjnym (krytyczny problem powoduje przełączenie awaryjne). Więc jeśli użytkownicy będą musieli się ponownie zalogować, nic wielkiego. Ponownie, vrrp można prawdopodobnie użyć do automatycznego przełączania awaryjnego.
Przechodząc do DB, jest to znacznie bardziej skomplikowane. Większość baz danych ma jakiś model podstawowy / pomocniczy, w którym wykonuje się kopię zapasową oryginalnej bazy danych na pomocniczej, a następnie kopiuje wszystkie dzienniki transakcji lub zmiany DB na pomocniczej. Ponownie możesz połączyć to z VIP-ami dla aplikacji / użytkowników faktycznie uzyskujących dostęp do bazy danych. Jednak przełączanie awaryjne jest bardziej dotkliwe. W zależności od awarii podstawowego może być konieczne uruchomienie napędów w celu skopiowania i pozostawienia dzienników transakcji. Następnie aktywuj drugorzędne. Jeśli możesz tolerować niektóre utracone dane, możesz od razu włączyć dodatkową aktywność. Po przełączeniu awaryjnym serwer B jest teraz Twoim głównym serwerem, a Twoim zadaniem byłoby przywrócenie serwera A i przekształcenie go w nową kopię zapasową, aby był gotowy na awarię, gdy serwer B w końcu będzie miał problemy.
Serwery plików są zawsze najtrudniejsze, ponieważ w przeciwieństwie do DB, trudniej jest uzyskać wbudowaną funkcję systemu plików. Jednak pewien poziom odporności można osiągnąć, mając drugi serwer, i po prostu napisz skrypt, który skanuje system plików pod kątem zmian, i skopiuj nowe pliki do pomocniczego. Możesz w zasadzie uruchomić rsync na cronie, który uważam za taki. Ponownie używasz VIP-a, który dajesz użytkownikom, do którego przenosisz się w przypadku przełączenia awaryjnego. W swoim skrypcie zdecydowanie zalecam sprawdzenie, czy system jest właścicielem VIP przed przesłaniem plików. Naprawdę naprawdę nie chcesz, aby rsync działał w złym kierunku i zastępował wszelkie zmiany, które wprowadzają użytkownicy. Może to spowodować utratę niektórych plików, jeśli ich awaria,
Nie mam pojęcia, co możesz zrobić z systemem telefonicznym ... to naprawdę zależy od dostawcy i jego konfiguracji. Sprzedawca może mieć gotowe rozwiązanie zapewniające odporność.
Kilka ostatnich słów ostrzeżenia. Upewnij się, że dokładnie przetestowałeś konfigurację, z którą zamierzasz skorzystać. Upewnij się, że wiesz, jak go przełączyć bez utraty kluczowych informacji. Przetestuj test testowy, aby upewnić się, że zadziała, kiedy będzie to potrzebne. Upewnij się, że masz wdrożone procesy, dzięki którym zmiany konfiguracji, aktualizacje oprogramowania itp. Zostaną odpowiednio zastosowane zarówno do kopii zapasowej, jak i podstawowej. Dobrą wiadomością jest to, że prawdopodobnie możesz wykonać kontrolowane przełączanie awaryjne, gdy chcesz sprowadzić serwer do aktualizacji itp. Nie jest to konfiguracja aktywna-aktywna, więc nie masz pojęcia, czy pomocnicza będzie działać, kiedy jej potrzebujesz.
Pracuję w telekomunikacji, a nasz sprzęt jest bardzo redundantny, w tym w większości przypadków redundancja geograficzna. Naszym pierwszym punktem awarii jest to, że nadmiarowość nie jest testowana po zmianach, a użytkownicy dokonujący zmian, którzy nie wiedzą, jak działa model nadmiarowości. Mamy jednak dodatkowy problem, że cały nasz sprzęt musi obsługiwać automatyczne przełączanie awaryjne w nie więcej niż kilka sekund. Możesz tolerować ręczną interwencję w trybie failover, jeśli potrzebujesz być gotowy do pracy w ciągu 30 - 60 minut. Musisz się tylko przygotować. Powodzenia.