Po odrobinie strachu przed serwerem, który nie pojawił się pewnego ranka, wyższe firmy zdecydowały, że firma potrzebuje wysokiej dostępności / konfiguracji awaryjnej.
Mamy 5 głównych serwerów (4x Linux, 1x OpenBSD), z których wszystkie muszą działać, aby firma działała. Trzy serwery są dość standardowe (Pliki / Sieć / Baza danych), czwarty obsługuje większość routingu sieciowego i serwerów proxy, a piąty obsługuje nasz system telefoniczny i ma niestandardowy sprzęt.
Mój szef stwierdził, że czas zawracania w przypadku awarii serwera powinien wynosić mniej niż 30 minut.
Moje doświadczenie w tej dziedzinie nie istnieje (jestem tylko programistą, który został „awansowany”), więc chyba moje pytanie sprowadza się do:
- Czy jest to coś, czego powinien spróbować nawet ktoś o przeciętnych umiejętnościach administratora serwera. Jeśli tak, co powinienem przeczytać i z kim mam porozmawiać?
Dzięki.
Odpowiedzi:
Myślę, że powinieneś zacząć od zebrania liczb, aby opisać koszty związane ze spełnieniem określonego „wymogu”, aby sprawdzić, czy w ogóle mieści się ono w budżecie. Jeśli nie czujesz się komfortowo ze wszystkimi „normalnymi” metodami, które byłyby używane do spełnienia wymagań (klastry pracy awaryjnej, hiperwizory z funkcją „migracji na gorąco” itp.), Prawdopodobnie dobrze byłoby znaleźć konsultanta, który mógłby wydźwignąć.
Studium wykonalności będzie wiązało się z pewnymi kosztami, ale odkrycie, że dobre rozwiązanie nie będzie pasować do podanego wymogu (będzie oznaczało, że oczekiwania muszą zostać realistycznie ustalone przez kierownictwo), trzeba kucnąć więcej pieniędzy) niż będzie to kosztować zrobienie czegoś na wpół osamotnionego, co w końcu nie spełni wymogu i wyda mnóstwo pieniędzy.
Wygląda na to, że twój szef wyciągnął tę liczbę z powietrza. Być może dokonał analizy i wie, jaki jest koszt godzinny związany z przestojami różnych systemów, ale wątpię w to. To brzmi jak jakaś nieziemska liczba niepowiązana z rzeczywistością. Byłbym zaskoczony, gdyby wszystkie wasze systemy wymagały tego rodzaju dostępności. Może się zdarzyć, że w trakcie badania firmy odkryjesz, że tylko podzbiór funkcjonalności musi mieć taki stopień bezawaryjności i odporności na awarie (a zatem takie rozwiązanie ostatecznie kosztowałoby mniej). Jestem pewien, że są tam telefony i aplikacja dla firm, ale możesz tolerować przestoje w niektórych innych systemach.
Moje przeczucie mówi, że prawdopodobnie odniesiesz zwycięstwo dzięki wykorzystaniu technologii wirtualizacji do stworzenia systemu przełączania awaryjnego opartego na migracji maszyn wirtualnych między sprzętem nadmiarowym. To, czy będzie pasować do Twojego budżetu, czy nie, będzie zależeć od Twojej firmy, ponieważ na pewno będziesz potrzebować pewnego rodzaju sieci SAN, aby działała skutecznie.
Nie należy jednak pomijać „tradycyjnych” klastrów pracy awaryjnej. Są też zdecydowanie „wygrane”, jeśli twoje aplikacje są dobrze dostosowane do takiej konfiguracji.
Zastanawiam się, czy twój szef pomyślał o katastrofalnych scenariuszach awarii (oparzenia budynków, powódź, tornado, kradzież itp.). Jeśli nie jest to jeszcze zaplanowane, byłaby to doskonała okazja do pracy w ogólnym planowaniu ciągłości działania i na wypadek awarii.
Uzyskaj pomoc od kogoś, kto może przyjść i zbadać Twoją firmę i wydać zalecenia. Nie pożałujesz.
źródło
„Ta droga prowadzi do bólu i bólu…”
Jaki jest plan ciągłości działania Twojego biznesu? Plan odzyskiwania po awarii?
Omówiłeś to? Zapisałeś to? TESTOWANE?
Musisz mieć właściwą rozmowę z „wyższymi” i naprawdę dotrzeć do dolnej części wymagań dotyczących wysokiej dostępności, ponieważ jest różna dla różnych usług.
Więc czym tak naprawdę był „ból”, który poczuli tego ranka?
To było?
Zakładam, że kupiłeś sprzęt wysokiej jakości do swoich głównych systemów? Dobrze, bo taniej na sprzęcie jest fałszywa ekonomia, ponieważ serwery te mają „podwójne” wszystko w pudełku.
Zakładam również, że wiesz, jak odbudować serwer, wymienić wentylatory, zasilacze, zamontować serwer, skonfigurować sieci z podwójną ścieżką w redundantne przełączniki? Zrobiłeś to wystarczająco dużo razy, aby zrozumieć, co działa, a co nie, co jest normalne, a co błędne? Jeśli nie, uzyskaj pomoc i szkolenie (lub przynajmniej praktykę i doświadczenie).
Być może dużym problemem był strach. Nie mieli pojęcia, że taki problem może się zdarzyć (i jak ważne były serwery dla ich firmy), a tak naprawdę nie wiedziałeś, co robisz (?) Problem z pewnością siebie?
Musisz wykonać wszystkie powyższe czynności PRZED zejściem bardzo drogą drogą HA. Czy firma może sobie pozwolić na ten drogi sprzęt (i większość z definicji będzie kiedykolwiek używana tylko w razie awarii i często nigdy nie będzie używana!)
źródło
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.
źródło
Każdy inny punkt jest świetny, więc tylko kilka komentarzy.
Nie można zagwarantować 30 minut, szczególnie na wszystko. Można powiedzieć, że jest to cel, ale nie ma żadnej gwarancji, ponieważ zawsze istnieje współczynnik X. Możesz mieć 2 linie ISP, a ciężarówka wpada do budynku i zabiera je obie, ponieważ nie sądzisz, że kierowanie ich z przeciwległych krańców budynku jest jednym z przykładów.
Na początek wyceny podwój wszystko. Masz 5 serwerów, więc musisz to podwoić. Nie musi to być wszystko sprzętowe, możesz wirtualizować, ale rozumiesz, co mam na myśli. Ponadto wszystko musi być świadome HA, co dodatkowo zwiększy koszty, możesz dowiedzieć się, że będziesz musiał wymienić router na nowy i och, potrzebujesz 2 z nich. Nie zapomnij podwoić źródeł zasilania i uzyskać generator, ponieważ nie możesz zagwarantować, że firma energetyczna zostanie przywrócona w ciągu 30 minut.
Te przykłady myślą, że jest to mniej więcej gorąca konfiguracja w trybie gotowości, o czym podejrzewam, że myśli twój szef.
Dla małej firmy lepsze jest zaprojektowanie planu odzyskiwania i klasyfikacji wszystkiego.
Dowiedz się, które usługi są
krytyczne (zatrzymania działalności)
ważne (biznes zwalnia)
rutyna (biznes może sobie na chwilę poradzić).
Na przykład telefony z centrum obsługi telefonicznej są krytyczne, więc może warto kupić drugi serwer i drugiego usługodawcę internetowego, a średnia przerwa w dostawie prądu wynosi około 15 minut, więc otrzymamy zasilacz UPS, który będzie trwał 60 minut (nie zapomnij też o stacjach roboczych). Powiedzmy teraz, że ERP jest tylko ważny, co oznacza, że możesz bez niego funkcjonować przez chwilę. Być może używają go pracownicy call center, ale jeśli jest wyłączony, mogą wrócić do pióra i papieru lub notatnika, a następnie zaktualizować ERP po. Procedura, aby to zrobić, jeśli nie działa, może być tańsza niż próba uczynienia z niej usługi krytycznej. A te rutynowe mogą być czymś w rodzaju drukarek, ok, to jest ból, ale możemy zrobić to przez kilka dni, jeśli wszystkie zepsują się.
To również daje ci rozkaz naprawienia rzeczy, jeśli pewnego dnia naprawdę trafi fan :)
źródło
Czy to możliwe? Pewnie. Czy to jest niedrogie? Prawdopodobnie nie dla „małej firmy”, zwłaszcza jeśli masz szefa, który podaje ci dowolne liczby, według których chcesz pracować, a on żąda wysokiej dostępności od działu IT, który składa się z zastępcy programisty (widziałem go wiele razy w innych miejscach i nigdy nie jest dość dla twoich poziomów stresu, jeśli twoja sytuacja była podobna do ich).
Przełączanie awaryjne jest możliwe, ale zwykle wymaga redundantnego sprzętu, sieci SAN do udostępniania danych między serwerami itp., Innymi słowy, powodzenia w uzyskaniu finansowania, jeśli nie zatrudnią dedykowanego administratora, który się tym zajmie.
Wspomniany sprzęt systemu telefonicznego jest sprzętem specjalistycznym i nawiązywałeś do bycia call center. Powinieneś porozmawiać z dostawcą na temat opcji, aby uczynić to zbędnym. Goofing z tym może w pierwszej kolejności unieważnić wsparcie.
Inne systemy, które najprawdopodobniej moglibyście zyskać na nadmiarowości, inwestując w rozwiązania VMWare (lub Hyper-V lub XenServer, ale najpierw przyjrzałbym się VMware i XenServer). Następnie możesz spojrzeć na SAN, kilka rozbudowanych serwerów z szybkimi przełącznikami sieci, i użyć LiveMotion do migracji zwirtualizowanych serwerów między serwerami sprzętowymi, jeśli wystąpi awaria, a także zrównoważyć część obciążenia między serwerami w zależności od potrzeb.
Wspomniałeś, że używasz Linuksa na tych systemach. Mając pieniądze na zdobycie wielu serwerów, możesz zamiast tego pomyśleć o skonfigurowaniu DRBD za pomocą programu pulsu i STONITH do replikacji danych między serwerami i przejęcia kontroli, gdy jeden stanie się niedostępny; będziesz chciał skonfigurować system, w którym dosłownie skopiowałeś każdy serwer, a także podwoiłeś zużycie energii i rozpraszanie ciepła w serwerowni (jeśli masz serwerownię). Można tego dokonać kosztem sprzętu i rozsądkiem. Ponadto musisz to przetestować, będziesz mieć przestoje podczas konfigurowania i nadal będziesz mieć możliwość, że czasami nie zadziała, ponieważ nadal istnieje możliwość pojawienia się problemów, które należy rozwiązać (podział mózg, na przykład).
Ostatni to plan, aby kilka systemów działało jak puste systemy i mieć naprawdę dobry plan tworzenia kopii zapasowych, który pozwoli ci przywrócić dane do jednego z „pustych” systemów, jeśli serwer umrze. Posiadanie sprzętu na miejscu daje pewne opcje, jeśli / kiedy serwer umrze; ale nadal będziesz mieć przestoje podczas przywracania danych i potrzebujesz instrukcji, jak poprawnie zainstalować aplikacje na nowym serwerze. W zależności od tego, jak szybko pracujesz i jak duże są dane, możesz mieć przestoje trwające od kilku godzin do jednego lub dwóch dni. Ty nie masz pracę, znany-dobry backup dla serwerów, z planu naprawy na miejscu, tak?
Powinieneś spróbować? Moją pierwszą reakcją jest to, że jeśli drapiesz się po którąś z sugestii lub odczuwasz ból w żołądku, próbując wymyślić te rzeczy, to nie powinieneś. Potrzebujesz firmy konsultingowej, która przyjrzy się temu problemowi, obliczy koszty i wdroży go, lub będziesz musiał zatrudnić dedykowanego administratora, który zrobi to dla Twojej firmy.
Fakt, że każą ci to zrobić, a ty mówisz, że jesteś „tylko programistą, który został„ wypromowany ”, a masz PHB, który mówi ci o nadmiarowości z maksymalnym czasem awarii wynoszącym 30 minut, jest taki, że jesteś miły z potoku.
źródło