22T48 7 Kroków Utworzenia Mikro Data Center [konfiguracja Mikrotik] cz.4

Data Center VRRP

Link do artykułu.

0:00 Wprowadzenie

1:07 Topologia

2:29 Interfejsy, Konfiguracja

16:20 Podsumowanie

Transkrypcja

Cześć. Dzisiaj pokażę jak w moim środowisku Micro Data Center skonfigurować VRRP czyli protokół wirtualnego IP. Chodzi o przede wszystkim stronę gdzie będę podłączał serwery. Czyli jeżeli mam już skonfigurowaną strefę czy DMZ’ową czy moją zaufaną internalową i mam po dwa routery to jest super. OSPF sobie z tym poradzi więc od zewnętrznej strony nie muszę tego jakoś specjalnie wirtualizować, jeżeli chodzi o adres IP chyba, że będę miał jakieś tam inne potrzeby ale na dzisiaj nie widzę takiej konieczności. To co potrzebuje to stworzyć VRRP od strony wewnętrznej.

Zarówno w DMZie jak i w strefie wewnętrznej po to żeby serwery, które będę miał postawione w tych dwóch strefach mogły wychodzić do internetu czy do połączeń tunelowych nawet jeżeli nastąpi awaria dowolnego z routerów brzegowych. Dzięki temu będę miał niezawodność tak jak to się powinno planować i wykonywać w rozwiązaniach Data Center.

Zacznijmy od tego co tutaj mamy. Mamy Data Center strefa zielona, adresacja 10.140.1 DMZ DC i adresacja 10.140.0 Jeżeli chodzi o konfigurację to VRRP będę wykonywał dla pary routerów dla DC to będzie interfejs eth-2 MT 3 DC i eth-2, MT4 DC podobnie dla strefy DMZ VRRP z końcówką 254 na eth-2 MT1 DC DMZ eth-2 MT2 DC DMZ. Czyli w tych parach będzie VRRP konfigurowane i będzie działało. Master będę tutaj wskazywał przez prytet na lewą stronę czyli Mikrotik 3 i Mikrotik 1. Te Mikrotiki będą masterami jeżeli nastąpi awaria to oczywiście nastąpi przełączenie a jeżeli będzie wszystko działało zgodnie z normalną topologią to te dwa routery będą obsługiwały ruch Gatewaya. No to przechodzę do konfiguracji MT 3 DC i MT4 DC. Zaczynam od MT1 DC DMZ.

Przechodzę do interfejsów VRRP i dodaję nowy interfejs. Interfejs, który wskazuje to ether 2 czyli eth-2. Priorytet dla jedynki i dla trójki będzie 200. Czyli że ma być masterem. Preemption Mode wyłącze. Czyli chcę żeby masterem był ten router, który działa najdłużej jako Master. To chodzi o taki przypadek, że jeżeli masz dwa routery i tutaj masz jakiegoś hosta i załóżmy, że ten standardowo jest masterem a ten jest Backup. Ruch płynie od hosta do Mastera i dalej do kolejnych sieci do internetu.

Teraz jeżeli nastąpi sytuacja taka, że Master ulegnie awarii. No to mamy sytuację następującą: ten nie działa, ten się staje Masterem po prawej stronie i host się przełącza na Mastera I Masterem idzie ruch do internetu. I co się stanie gdy pierwotny router wróci z powrotem do działania. Czyli mamy hosta, mamy tutaj Mastera I ten po lewej pytanie jaki ma mieć stan. Jeżeli wyłączymy Preemption Mode to znaczy, że ten który jest Masterem aktualnie pozostanie tym Masterem a ten drugi będzie backupem mimo, że priorytet dla tego, który uległ awarii, że priorytet ma 200 a ten po lewej ma priorytet 100.

Czyli mimo tego, że ma niższy priorytet to jeżeli jest Preemption Mode wyłączony. Czyli specjalny typ, który przełącza zawsze na router, który ma na o wyższym priorytecie ustawienie to jeżeli nie włączymy tego Preemption
Mode to Masterem jest zawsze ten, który ma najwyższy up time jako Master. Czyli w tym przypadku ten po prawej stronie będzie Masterem. Jeżeli chodzi o
scenariusze to jeżeli nie masz żadnego innego wymagania to wyłączenie Preemption Mode jest zalecane. Chodzi o to, że minimalizujesz ilość przełączeń roli pomiędzy tymi dwoma routerami. Czyli w momencie, kiedy mamy nawet awarię tego po lewej stronie i on wróci, całość aplikacji działa na routerze po prawej stronie to my nie musimy tego przełączać, chyba, że mamy inny powód.

Jaki to może być inny powód? No powodem może być między innymi taka topologia, że mamy hosta, tu jakiś mamy Firewall a dopiero za nim mamy te routery i tutaj te Firewalle też zapewne najczęściej są w klastrze. Czyli mamy taką mniej więcej topologię. Wtedy możemy się zastanowić czy nie chcemy tego Preemption Mode uruchomić. Jeżeli zależy nam na tym żeby z jakiegoś powodu ten główny Firewall miał jakby ruch przepuszczany był przez niego głównie. Ale to są bym powiedział przypadki szczególne co do zasady raczej należy Preemption Mode wyłączyć żeby nam niepotrzebnie nie włączał kolejnych przełączeń w momencie kiedy wraca nam uszkodzony router.

Kolejna rzecz uwierzytelnianie – dobrze by było… To nawet nie jest jakiś specjalnie silny mechanizm… Ale dobrze by było żeby był wprowadzony jednak, wprowadzone jakieś hasło. Chodzi o to żeby wykluczyć przypadkowe dołączenie innego routera VRRP z jakimś nieprzewidzianym priorytetem, który nam może zrobić nieprzewidziane przełączenie w naszej topologii. Więc Autentication czyli uwierzytelnianie powinno być zastosowane jako mechanizm dodatkowy. Akceptujemy, Ok. W simple nie może być więcej, że się znaków to przyłączmy w ah wersję drugą i tu powinno już być Ok.

Interfejs jest stworzony. Podobnie interfejs teraz stworzę dla MT2 DC DMZ. Tutaj Priority 100, Preemption Modę wyłączone. To samo dla Mikrotika 3 czyli Mikrotik 3, Mikrotik 4 to jest dla DC. Interfejsy mam podtworzone, teraz przypisanie adresów IP. Czyli przechodzę do adresacji, dodaję nowy adres. Jeżeli chodzi o Mikrotika 4 DC na którym jestem to tutaj będzie adres 10.140.1.254 maska 24 bity i wskazuje interfejs VRRP DC. To samo robię na
Mikrotiku 3 i teraz przechodzę do Mikrotika 2. Adresacja .0.254

Tu chwilę potrzeba żeby ten adres IP był aktywny. Sprawdźmy. Tu już są aktywne, tu na Mikrotiku 4 nie jest aktywny i jeszcze na Mikrotiku 1 też nie jest aktywny. Nieaktywny bo jest backup. Tu też jest backup. Dobrze, czyli to się zgadza bo już zestawiły te routery ze sobą sąsiedztwa. W związku z tym jest jeden backup jeden master. Przejdźmy tutaj do interfejsów VRRP. Jest master, Running, OK. Czyli mamy spięte te nasze dwie pary VRRP działa i jest synchronizowane. No to teraz spróbujmy zrobić test czyli na przykład Linuxa DC będę pingował jakiś serwer po stronie na przykład Campusu 1, spróbujmy VPC1 i zobaczymy jak sytuacja się będzie przedstawiać. VPC11 przepraszam.

To jest 10.0.10.11 i będziemy pingować z tego tutaj naszego DC. Nadam mu tylko adres IP. Tutaj jest serwer więc nie będę dynamicznie nadawał adresacji 10.140 z końcówką 1 i Gateway’em będzie 10.140.1.254 No i sprawdzę pingujemy 10 11. Nie pingujemy no to zobaczmy czy Gatewaya pingujemy i będziemy szli dalej. Gateway jest, kolejny Gateway odpowiada. No to co, to teraz trzeba by coś po OSPFie. Przykład sieć 10.11.11.0 z końcówką 254. Ok, odpowiada. No to idźmy dalej 253 i potem 10. 0.10.253 odpowiada też i potem 10… Nie odpowiada, tutaj się spodziewam, że prawdopodobnie OSPF coś nie działa. No ale zobaczmy… Zobaczmy może na Mikrotiku 1 DC i sprawdźmy jak wygląda tablica routingu. Nas interesuje się 10.0.10 i widać, że tutaj ta sieć się nie pojawia ale no to sprawdźmy dalej. Na MT 1 Campus tablica routingu tutaj również nie pojawia się sieć dziesiątkowa. No to znaczy, że idziemy dalej na MT3 Campus.

Tutaj trzeba sprawdzić OSPFa. A sąsiedzi… 10.11.11.254 czyli sąsiada widzi ten MT3 Campus widzi sąsiada MT1 Campus w OSPFie. Natomiast nie przekazuje informacji o sieci 10.0.10 Zaraz to naprawimy. Zapewne na MT3 nie ma interfejsu pasywnego dla sieci 10.0.10 MT3 Campus i jak patrzymy sobie na
interfejsy czyli jest interfejs tylko eth1 MT3 a my potrzebujemy template Passive. Client. Czyli ten template jakiegoś powodu nie odpowiada dla interfejsu… Interfejs eth-2 na MT3. Klient eth2.

Czyli tu muszę sprawdzić bo jest wpisany interfejs eth-2 na MT3 i zobaczyć czy on nie jest do bridge przypadkiem podpięty. Eth MT3 No i dlatego
nie działa. Czyli jak wyłączę z Bridge ten Interfejs… Doszedłem do wniosku, że tu mi Bridge nie potrzebny i w OSPFie, w template mam konkretny interfejs wpisany. Client eth-2 MT3. To teraz sytuacja powinna być dobra tylko jeszcze IP adres muszę zmienić bo tu oczywiście był podpięty inny interfejs bridge był a ja chcę client i teraz się powinno tutaj wszystko pingować i oczywiście działa.

Dobrze, czyli mamy tutaj podłączony teraz nasz serwer Linuxowy, który wychodzi przez MT3 DC, możemy zobaczyć sobie… arp-y. Mnie interesuje ten arp czyli adres 10.141.1 Zobaczmy na MT4 czy tu taki arp się pojawił. 10.141 na interfejsie 2 czy on też go zobaczył? No to teraz możemy zobaczyć jaka jest rola tego interfejsu. Jestem na MT3 DC czyli wracamy, że jest masterem MT4 jest backupem, to puśćmy teraz pinga ciągłego. Przejdę tutaj do wyłączenia MT3. No i widać, że przełączenie było na tyle krótkie, że nam tutaj nawet ping nie wypadł. Przynajmniej na razie.

Zobaczmy… tak MT3 jest już wyłączony. Teraz możemy zobaczyć jaka jest rola. No MT3 wiadomo, że będzie niedostępny albo jest wyłączony a na MT4 mamy rolę teraz Master. Running Master. No dobra czyli włączę teraz MT3. Tu cały czas ping leci. Nie ma przerwy no i zobaczmy tu mamy cały czas na MT4 Mastera. Zobaczmy czy MT3 już wrócił. MT3 DC3 też jest Master. Czyli MT3 przełączył się na Mastera. Nie powinien ale Preemption Mode jest włączone czyli się przełączy. Czyli tu wyłączę. Zobaczmy na drugim. Tu jest wyłączony. No to jeszcze raz ten sam test. Preemption Mode jest wyłączone. Ok. Czyli czwarty jest masterem, trzeci nie działa, wyłączony, włączę go i jest backupem. Czyli widzimy, że z wyłączonym Preemption Mode działa tak jak powiedziałem wcześniej. Czyli ten, który jest masterem tym masterem pozostaje. Mimo, że MT3 ma wyższy priorytet bo ma priorytet 200. To samo zrobimy teraz na MT1 MT2 tu ping cały czas leci. No to wyłączamy… A najpierw może sprawdzimy jaka jest rola MT1 DC DMZ. MT1…

MT1 jest backupem bo tak było wcześniej i sprawdziły na MT2 DC DMZ a ten jest masterem. No to tym razem wyłączyłem Mastera. No bo jak wyłączę backup to tak naprawdę nic się nie zmieni. Nie ma żadnego przyłączenia. Czyli tu wyłączę MT2 DC DMZ, tu ping cały czas leci i wyłączam po prawej stronie i widzimy że MT1 się przyłączył w Mastera, MT2 jest niedostępna. Ponownie go włączę. No i jest backupem MT1 nadal jest masterem.

No i na dzisiaj to tyle. Dziękuję ci za uwagę. Jeżeli masz jakieś pytania co do tego tematu to oczywiście pisz w komentarzu i widzimy się i słyszymy już tydzień.