Witam,
taki problem do rozwazenia mam: jak jest rozwiazywany nastepujacy problem w powaznych firmach:
Mamy sobie powiedzmy jakis serwerek, ktory ma byc 24/365 dostepny w necie.
Sa wiec spiete dwie sesje BGP do dwoch operatorow (Dual homing), pula PI /24, wlasny AS.
A co w przypadku, powodzi, pozaru serwerowni, meteorytu? Potrzebna jest zapasowa, nie?
W jaki sposob sprawic zeby adres IP tego serwera nagle pojawil sie w innej lokalizacji?
Dla uproszenia problemu nie interesuje nas replikacja danych miedzy serwerami.
Ale czas czas przelaczenia ma wynosic maksymalnie okolo 1 minuty.
Jedynym rozwiazaniem takiego problemu wydaje mi sie jest pojawie sie adresu IP
w innej lokalizacji (ale jak?) bo zabawy z DNS zbyt dlugo sie propaguja.
Jak taki "failover" realizuje sie w rzeczywistosci?
Pozdrawiam!
Zapasowa serwerownia
Zapasowa serwerownia
wysoki
CCNA
CCNA
Szukaj w sieci pod "global load balancing", zaś "disaster recovery" site'u to podzbiór tego zagadnienia.
Pozdrawiam z Wrocławia (no dobra, teraz z Wawy) - Mariusz @@@ Linkedin - zapraszam: http://pl.linkedin.com/in/trojanowski
Jak rozumiem masz 2 ośrodki połączone ze sobą i logicznie pracujące jako jeden.
W takim przypadku redundantne serwery muszą stać w oby lokalizacjach.
Teraz zależy w jakiej części zapewnisz redundancję lub load balancing.
a - Redundancję możesz zrobić na serwerach - różnego rozwiązania clustrowe na serwerach
zalewniające redundancję i load balancing
b - sam load balancing na dodatkowych urządzaniach sieciowych - CSS, ACE, F5
Są też rozwiązania gdzie występuje wiele ośrodków pracujących niezależnie od siebie. Występują wtedy serwery które przekierowują usera do dostępnego, najbliższego/najmniej obciążonego ośrodka.
W takim przypadku redundantne serwery muszą stać w oby lokalizacjach.
Teraz zależy w jakiej części zapewnisz redundancję lub load balancing.
a - Redundancję możesz zrobić na serwerach - różnego rozwiązania clustrowe na serwerach
zalewniające redundancję i load balancing
b - sam load balancing na dodatkowych urządzaniach sieciowych - CSS, ACE, F5
Są też rozwiązania gdzie występuje wiele ośrodków pracujących niezależnie od siebie. Występują wtedy serwery które przekierowują usera do dostępnego, najbliższego/najmniej obciążonego ośrodka.
Panowie, zaden load balancing, pytam o mechanizmy jakimi sie realizuje sam taki "global failover",
czyli pada jedna serwerownia, to jej role przejmuje druga (ktora do tej pory byla standby).
Z tego co piszecie to wymagany jest jakis dedykowany link miedzy nimi, tak?
Da sie to zrobic w obrebie jednego ASa, czy musza byc dwa?
A czym sie realizuje "przelaczenie" na backup? Jakies mechanizmy w BGP?
Jakies warunkowe zestawianie sesji, ze jesli z internetu znikna dwa łącza w primary serwerowni,
to serwerownia standby zestawia sesje z operatorami i rozglasza adresy z serwerowni primary u siebie?
Jak sie realizuje takie "przeniesienie" adresów IP?
czyli pada jedna serwerownia, to jej role przejmuje druga (ktora do tej pory byla standby).
Z tego co piszecie to wymagany jest jakis dedykowany link miedzy nimi, tak?
Da sie to zrobic w obrebie jednego ASa, czy musza byc dwa?
A czym sie realizuje "przelaczenie" na backup? Jakies mechanizmy w BGP?
Jakies warunkowe zestawianie sesji, ze jesli z internetu znikna dwa łącza w primary serwerowni,
to serwerownia standby zestawia sesje z operatorami i rozglasza adresy z serwerowni primary u siebie?
Jak sie realizuje takie "przeniesienie" adresów IP?
wysoki
CCNA
CCNA
Najprościej to chyba zastosować Anycast IP, czyli np. dwa serwery w różnych lokalizacjach z tym samym adresem IP rozgłaszanym do Internetu lub sieci extranet. Odpowiednimi politykami BGP lub IGP wybierasz, która lokalizacja ma mieć priorytet. Mechanizm sprawdza się głównie dla aplikacji UDP.wysoki pisze:Panowie, zaden load balancing, pytam o mechanizmy jakimi sie realizuje sam taki "global failover",
czyli pada jedna serwerownia, to jej role przejmuje druga (ktora do tej pory byla standby).
Dla ruchu TCP w przypadku awarii łącza/serwera podstawowego sesja musi zostać zestawiona ponownie lub potrzebny by był mechanizm synchronizacji. W tym miejscu przydaje się - tak jak koledzy podpowiadali - regionalny load-balancer, który sprawdzałby dostępność serwerów i przekierowywałby użytkownika do najbliższego serwera lub tego o najlepszych parametrach.
Anycast , ciekawa opcja jest redystrybucja do dowolnego protokolu routingu statickow, ale tylko wtedy gdy sla dostepnosci serwera głownego przestaje odpowiadać.
A tak na powaznie, jak chcesz to zrobic tanio na cisco to uzyj ciscowego IP SLB.
Mozesz badac dostepnosc klockow z okreslone puli serwerow, serwery moga miec rozne IP- jest to bez znaczenia poniewaz IP SLB obsluguje funkcjonalnosc natowania farm serwerow (choć wcale nie musi).
Fajne nie
A tak na powaznie, jak chcesz to zrobic tanio na cisco to uzyj ciscowego IP SLB.
Mozesz badac dostepnosc klockow z okreslone puli serwerow, serwery moga miec rozne IP- jest to bez znaczenia poniewaz IP SLB obsluguje funkcjonalnosc natowania farm serwerow (choć wcale nie musi).
Fajne nie
"Trust no one"
Ten sam AS i prefix moze byc rozglaszany przez lokacje oddalone nawet tysiace kilometrow od siebie, jedna z BGP prependem powiedzmy 5 razy. Wszyscy klienci routowani sa do pierwszej, jak Chinczycy przywala atomowka to przestanie rozglaszac i wszyscy leca do drugiej.
Providerzy czasami wymagaja by na wszystkich punktach styku z nimi rozglaszac im ten sam zestaw prefixow - jesli mamy jakies dodatkowe nie-redundantne to musimy zapewnic routing klientow ktorzy weszli przez A a ich cel znajduje sie w B. Dla ruchu od klienta wystarczy tunnel GRE i iBGP, do replikacji danych IPSec VPN (albo dzierzawiona fala DWDM) tyle ze serwery musza miec dodatkowe unikatowe adresy. Jesli w A i B uzywamy roznych ISP to problem rozglaszania tych samych zestawow nie istnieje.
Failover nastepuje z predkoscia konwergencji BGP, czesto dluzsza niz minuta (zalezy z jak wielkiej czesci swiata zbieramy klientow).
W praktyce rownie dobry jest DNS z ustawionym TTL na 60s, tyle ze DNS serwer(y) musi wydolic z obsluga wszystkich zapytan.
Providerzy czasami wymagaja by na wszystkich punktach styku z nimi rozglaszac im ten sam zestaw prefixow - jesli mamy jakies dodatkowe nie-redundantne to musimy zapewnic routing klientow ktorzy weszli przez A a ich cel znajduje sie w B. Dla ruchu od klienta wystarczy tunnel GRE i iBGP, do replikacji danych IPSec VPN (albo dzierzawiona fala DWDM) tyle ze serwery musza miec dodatkowe unikatowe adresy. Jesli w A i B uzywamy roznych ISP to problem rozglaszania tych samych zestawow nie istnieje.
Failover nastepuje z predkoscia konwergencji BGP, czesto dluzsza niz minuta (zalezy z jak wielkiej czesci swiata zbieramy klientow).
W praktyce rownie dobry jest DNS z ustawionym TTL na 60s, tyle ze DNS serwer(y) musi wydolic z obsluga wszystkich zapytan.
Tylko, że powstają dwa problemy:Paulus pisze:Ten sam AS i prefix moze byc rozglaszany przez lokacje oddalone nawet tysiace kilometrow od siebie, jedna z BGP prependem powiedzmy 5 razy. Wszyscy klienci routowani sa do pierwszej, jak Chinczycy przywala atomowka to przestanie rozglaszac i wszyscy leca do drugiej.
1. To że ustawimy 5 razy prepend wcale nie implikuje tego, że będzie do preferowana trasa do nas.
2. Nasz peer bgp może nie zezwalac/filtrowac nasze preependy i wtedy nici z całego planu.
Jednym z rozwiązań jest rozdzielenie prefixów w obrębie tego samego AS per Data Center.
W przypadku rozpięcia połączenia między nimi nadal jest możliwość podawania treści z obu DC. Problem pojawia się przy komunikacji wtedy miedzy tymi dwoma DC poprzez sieć zewnętrzną bo zostana na sesjach eBGP odrzucone prefixy przychodzące ze świata z lokalnym AS (zapobieganie petli w BGP).
Inna uzupełniająca metodą zachowania redundancji jest wstrzykiwanie adresu wirtualnego usługi z różnych DC w obrębie protokołu IGP z maska /32 i różnymi metrykami (RHI).
Przy problemach z daną usługą lub sprzętem ją obsługującą cały ruch trafia do drugiego centrum danych lub po prostu na inne load balancery.
Oczywiście oprócz tego obniżone TTL na wpisach w domenie na możliwość przepięcia na inne DC w przypadku całkowitego kataklizmu.
Rozwiązań jest wiele, ważne jest aby dobrać odpowiednie do skali i możliwości.
W przypadku rozpięcia połączenia między nimi nadal jest możliwość podawania treści z obu DC. Problem pojawia się przy komunikacji wtedy miedzy tymi dwoma DC poprzez sieć zewnętrzną bo zostana na sesjach eBGP odrzucone prefixy przychodzące ze świata z lokalnym AS (zapobieganie petli w BGP).
Inna uzupełniająca metodą zachowania redundancji jest wstrzykiwanie adresu wirtualnego usługi z różnych DC w obrębie protokołu IGP z maska /32 i różnymi metrykami (RHI).
Przy problemach z daną usługą lub sprzętem ją obsługującą cały ruch trafia do drugiego centrum danych lub po prostu na inne load balancery.
Oczywiście oprócz tego obniżone TTL na wpisach w domenie na możliwość przepięcia na inne DC w przypadku całkowitego kataklizmu.
Rozwiązań jest wiele, ważne jest aby dobrać odpowiednie do skali i możliwości.
Myslę, że może się przydać ;)
http://www.cisco.com/en/US/docs/solutio ... ml#wp52864
http://www.cisco.com/en/US/docs/solutio ... ml#wp52864