Vyatta to specjalistyczna dystrybucja Linuksa oparta na Debianie, przeznaczona do tworzenia routerów. Oferuje między innymi obsługę protokołów RIP, OSPF i BGP, translacji adresów NAT, posiada także wbudowanego firewalla. Dodatkowo można ją skonfigurować jako bramkę VPN z obsługą PPTP, L2TP, IPSec i OpenVPN oraz współpracującą z RADIUS. Dostępny jest też serwer DHCP, obsługa QoS, PPPoE, SNMP. Vyatta pozwala więc przekształcić dowolny komputer klasy PC w router odpowiadający parametrami, funkcjonalnością, niezawodnością i wydajnością drogim routerom Cisco. Testujemy to rozwiązanie na własnej skórze od kilku miesięcy przy hostingu zarówno TechIT, jak i o wiele większego serwisu dobreprogramy i jak dotąd spisuje się ono znakomicie. Dzięki routerowi Vyatta można więc znacznie obniżyć koszty sprzętu, ale to jeszcze nie koniec - stworzenie w pełni redundantnego środowiska klastrowego obsługiwanego przez Vyattę jest tak proste (i tanie, w porównaniu do sprzętowych rozwiązań), jak w przypadku jednej maszyny. W tym artykule pokażemy, w jaki sposób to zrobić.
High Availability w dwóch smakach
Na początek należy zaznaczyć, że w zakresie High Availability i redundancji maszyn Vyatta oferuje zasadniczo dwa rozwiązania. Pierwsze z nich to protokół VRRP (RFC 3768). Umożliwia on stworzenie "wirtualnego routera", dodatkowej wyższej warstwy abstrakcji nad urządzeniami, która sprawia, że są one widoczne jako jedno. Dzięki temu awaria jednego z routerów nie wpływa na resztę sieci. Protokołem VRRP nie będziemy jednak zajmować się w tym artykule.
W tym artykule zajmiemy się tworzeniem klastra typu fail-over, czyli modelu dwóch urządzeń (węzłów), spośród których jedno jest aktywne, a drugie czeka w gotowości na wypadek awarii pierwszego. Taki scenariusz jest najbardziej elastyczny. Praktycznie każda usługa pracująca na routerze może być w ten sposób sklastrowana (z zewnątrz i tak nie ma znaczenia, która maszyna obsługuje użytkownika), choć cena za tę korzyść jest relatywnie wysoka - druga maszyna stoi i nie robi nic, dopóki pierwsza nie ulegnie awarii lub z innych powodów nie będzie mogła kontynuować pracy.
Vyatta i klaster - w teorii
W systemie Vyatta w wersji 5.0.2 klaster fail-over może być złożony wyłącznie z dwóch maszyn, które z zasady współdzielą jedną grupę usług. W przyszłych wersjach sytuacja ta ma ulec zmianie - prawdopodobnie dodana zostanie obsługa większej liczby maszyn w klastrze i większej liczby grup usług. Poprzez usługę rozumiemy tutaj usługi systemowe (np. demon pptpd odpowiadający za przyjmowanie połączeń VPN przy pomocy protokołu PPTP), ale również - co bardzo istotne - adresy IP. Istotą klastrowania jest bowiem fakt, że klaster posiada wspólny wirtualny adres IP (lub kilka), który wędruje zawsze do aktywnego węzła. W danej chwili tylko jeden wezeł - ten aktywny - ma przypisane wirtualne adresy IP klastra oraz posiada włączone usługi.
Najczęściej spotykanym scenariuszem jest konfiguracja przynajmniej jednego wirtualnego adresu klastra - do komunikacji z siecią wewnętrzną (adres ten podawany jest na klientach jako brama domyślna). Czasami konieczne jest również występowanie na zewnątrz pod jednym adresem IP - wtedy ten adres również powinien być wirtualnym adresem klastra i cały klaster wygląda tak, jak na poniższym rysunku:
Węzły nieustannie w konfigurowalnych odstępach wymieniają między sobą wiadomości kontrolne - tzw. heartbeaty. Jeśli jeden z węzłów nie otrzyma heartbeatu drugiego węzła przez określony czas (z reguły pewną wielokrotność odstępu wysyłania), przyjmuje, że drugi węzeł uległ awarii i uznaje siebie za nowy aktywny węzeł - przypisuje sobie wirtualne adresy IP i uruchamia określone w konfiguracji klastra usługi. W zależności od konfiguracji klastra po odzyskaniu sprawności przez pierwszy węzeł może on z powrotem przejąć status węzła aktywnego (revertible failover) lub stać się węzłem zapasowym (non-revertible failover).
Opcjonalnie Vyatta umożliwia przypisanie do klastra hostów trzecich, które będą monitorowane przez węzły - w razie utraty łączności z takim hostem węzeł uzna, że nie jest już zdolny do pełnienia funkcji i przekaże usługi drugiemu. Jest to rozwiązanie przydatne w sytuacji, gdy klaster jest używany do zapewnienia łączności na dwóch redundantnych łączach i jedno z nich przestanie funkcjonować. Klaster automatycznie umożliwi wtedy klientom w sieci łączność przez zapasowe łącze pomimo tego, że oba routery będą sprawne.
Vyatta i klaster - w praktyce
Konfigurację klastra na routerach Vyatta należy rozpoczać od zdefiniowania gałęzi cluster. W gałęzi tej można określić najważniejsze parametry funkcjonowania klastra.
Parametr keepalive-interval określa odstępy w milisekundach pomiędzy wysyłaniem kolejnych heartbeatów przez węzeł. Wartość tego parametru należy skorelować z wartością parametru dead-interval. Domyślnie jest to 5 sekund (5000 ms).
cluster {
keepalive-interval: 5000
}
Parametr dead-interval umożliwia podanie w milisekundach czasu od otrzymania ostatniego heartbeatu, po upływie którego Vyatta uznaje, że drugi węzeł uległ awarii i przejmuje na siebie sklastrowane usługi. Domyślnym ustawieniem jest 20 sekund (20000 ms). Nasze testy pokazują, że nie ma żadnego problemu, by wartość tę mocno obniżyć - nawet do kilku sekund. Krótszy limit oznacza krótszą przerwę na wypadek awarii, ale trzeba uważać, by nie wywołać fałszywych alarmów z uwagi na możliwe opóźnienia w transmisji heartbeatów.
cluster {
dead-interval: 20000
}
Interfejs w definicji klastra to platforma wymiany heartbeatów - to właśnie interfejsu zdefiniowanego w tym miejscu klaster będzie używał do wymiany informacji kontrolnych, dlatego oba węzły musza "widzieć się" na tym interfejsie i musza mieć na nim przypisane adresy IP. Możliwe jest określenie więcej niż jednego interfejsu.
cluster {
interface: ethx
}
Hasło jest potrzebne, by węzły klastra mogły się wzajemnie uwierzytelnić. Daje to gwarancję, że nikt niepowołany nie będzie próbował podszyć się pod któryś z węzłów i wprowadzić własną konfigurację.
cluster {
pre-shared-secret: haslo
}
Teraz pozostaje utworzyć grupę usług klastra, w której określone będą węzły, usługi, hosty do monitorowania oraz typ klastra (odwracalny czy nieodwracalny).
Parametr primary oraz secondary określa routery Vyatta w sieci, które będa razem tworzyć klaster. Pierwszy z nich po zacommitowaniu konfiguracji na obu routerach automatycznie stanie się węzłem aktywnym. Bardzo ważne jest, by routery na tym etapie "widziały się" w sieci na podstawie swoich nazw. Nazwę hosta można ustawić poleceniem set system host-name.
cluster {
group klaster {
primary VYATTA01
secondary VYATTA02
}
}
Bardzo ważne jest również, czy podstawowy węzeł klastra po zakończeniu awarii ma z powrotem przejąć rolę aktywnego węzła, czy też pozostawić ją hostowi zapasowemu i samemu czekać na jego awarię. Domyślną wartością jest false, czyli failback nie następuje. Zmiana tego parametru ma sens jedynie w sytuacji, gdy zapasowa maszyna jest słabsza lub mniej niezawodna - wtedy opłaca się poświęcić dodatkowe kilka(naście) sekund i ewentualne rozłączenie sesji użytkowników po to, by do pracy po swojej awarii wrócił mocniejszy i bardziej niezawodny router.
cluster {
group klaster {
auto-failback false
}
}
Istnienie hostów-monitorów w klastrze jest opcjonalne i nie zawsze ma sens. Może być przydatne w sytuacji, gdy mamy dwa routery np. podłączone do Internetu dwoma niezależnymi łączami - gdy jedno łącze ulegnie awarii, sam router będzie nadal pracował, co oczywiście nie wywoła zmiany aktywnego węzła. Aby taką zmianę wywołać, wystarczy ustawić monitor w postaci hosta w Internecie - brak łączności z nim (czyli awaria łącza) spowoduje zmianę aktywnego węzła na drugi, który dzięki niezależnemu łączu będzie mógł bezproblemowo obsługiwać klientów z sieci wewnętrznej. Warto pamiętać, że hosty-monitory muszą być widoczne za pośrednictwem adresu stale przypisanego do jednego z interfejsów routera, a nie wirtualnego adresu klastra.
cluster {
group klaster {
monitor 100.100.100.1
}
}
Pozostaje już tylko wybór usług, jakie mają być sklastrowane. Mając na uwadze koncepcję wirtualnych adresów IP klastra funkcjonujących jako usługi wystarczy wewnątrz grupy skonfigurować parametry service - może ich być wiele, dla każdej usługi jeden wpis. Aktualnie jedyną wspieraną przez twórców Vyatty usługą do klastrowania (oprócz adresów IP) jest tunel IPSec. Nic nie stoi jednak na przeszkodzie, by samemu poeksperymentować z innymi usługami - z naszych testów wynika, że naprawdę sporo usług działa w takim scenariuszu bez najmniejszych problemów (więcej o naszej konfiguracji w dalszej części artykułu). Oto przykładowa konfiguracja wyczerpująca wszystkie możliwości parametru service:
cluster {
group klaster {
service 192.168.0.100/24
service 192.168.0.100/24/eth1
service 192.168.0.100/24/eth1/192.168.0.255
service pptpd
service script::args
}
}
Najprostszym wpisem jest po prostu adres IP wraz z maską podsieci w notacji CIDR. Tak wpisany adres oznacza, że jest on wirtualnym adresem klastra i będzie przypisany zawsze do aktywnego węzła. Większą kontrolę uzyskujemy w sytuacji, gdy dopiszemy do niego numer interfejsu, do którego ma trafiać ten wirtualny adres. Opcjonalnie możemy dopisać także adres broadcast. Drugą możliwością jest wpisanie nazwy usługi pochodzącej z katalogu /etc/init.d. Może to być na przykład demon pptpd, jeśli klastrowaną usługą jest serwer dostępu zdalnego VPN. W takiej sytuacji klaster uruchamia demona na aktywnym węźle, a zatrzymuje go na węźle zapasowym. Failover powoduje akcję odwrotną - demon jest uruchamiany na hoście zapasowym i zatrzymywany na poprzednio aktywnym. Jest jeszcze trzecia możliwość skonfigurowania wpisu service - może to być skrypt (z ewentualnymi argumentami) umieszczony w katalogu /etc/ha.d/resource.d.
Na koniec jedna rada na temat commitowania konfiguracji - należy zacząć od węzła podstawowego. Jak zachowuje się Vyatta podczas wybierania pierwszego węzła aktywnego tuż po zacommitowaniu konfiguracji? Router czeka 120 sekund na heartbeat drugiego węzła - jeśli go otrzyma, przechodzi do trybu aktywnego (jeśli jest węzłem podstawowym) lub do trybu stand-by (jeśli jest zapasowym). Jeśli heartbeat nie nadejdzie przez dwie minuty od zacommitowania konfiguracji, router przyjmuje, że drugi węzeł jest nieosiągalny (uległ awarii) i sam staje się aktywnym.
Po zacommitownaniu konfiguracji aktualny status węzłów i usług można sprawdzić wydając polecenie show cluster status.
VYATTA01:~# show cluster status
=== Status report on primary node VYATTA01 ===
Primary VYATTA01 (this node): Active
Secondary VYATTA02: Active (standby)
Resources [192.168.0.100/24/eth1 pptpd]:
Active on primary VYATTA01
Klaster Vyatty w naszej infrastrukturze
Artykuł o klastrowaniu Vyatty powstał na podstawie rzeczywistego wdrożenia, jakie przeprowadziliśmy w naszej serwerowni. Oba węzły klastra pracują u nas jako maszyny wirtualne na bazie bezpłatnego hypervisora VMware ESXi 3.5 - oczywiście każdy węzeł na innym serwerze fizycznym. Obie Vyatty mają wpięcie do tych samych sieci na tych samych interfejsach - mówiąc w uproszczeniu są to po prostu niemal idealne kopie.
Vyatta jest sercem naszej infrastruktury hostingowej - gdy router nie działa, nie działa nic. Samego systemu używamy od listopada 2008 i od tamtej pory nigdy jeszcze nie zawiedliśmy się na stabilności i niezawodności Vyatty. Niemniej czasami są momenty, gdy system trzeba zrestartować (np. podczas aktualizacji oprogramowania ESXi) lub z jakichś innych powodów wyłączyć. Głównym celem było więc uzyskanie ciągłości pracy w takich sytuacjach, a przynajmniej skrócenie przerwy do minimum - podczas zmiany aktywnego węzła niestety nadal pozostaje bowiem kilkusekundowa przerwa, ale jest to znacznie lepsze rozwiązanie, niż telefon w środku nocy i ręczne podnoszenie zapasowego routera.
Nasz router pełni w zasadzie niewiele funkcji - routing BGP, firewall i QoS to najważniejsze. Wszystkie dało się sklastrować bez problemów. Przymierzaliśmy się kiedyś do skonfigurowania bramki VPN na Vyacie, ale niestety w ówczesnej wersji (i w bieżącej 5.0.2 także) możliwości konfiguracyjne VPN nie są na tyle rozbudowane, by sprostać naszym potrzebom. Gdybyśmy jednak zdecydowali się na postawienie serwera dostępu zdalnego na Vyacie, również nie byłoby problemów ze sklastrowaniem tych usług - sprawdziliśmy na maszynach testowych.
Jedyną rzeczą, nad którą zastanawialiśmy się przy okazji konfiguracji klastra były wpisy service, które zapewnią odpowiednie zachowanie BGP. Chcieliśmy, by w czasie failoveru sesje BGP nawiązywane były od razu przez zapasowy węzeł. Stało się jasne, że adresy, z których router łączy się z sąsiadami muszą być wirtualnymi adresami klastra. A co z demonami? I tu pojawił się jedyny problem. Ustaliliśmy jednak, że w parametrze service należy podać grupę usług vyatta-quagga. Grupa ta to przystosowana do Vyatty wersja pakietu usług routingu Quagga, w jej skład między innymi wchodzi zebra czy bgpd. Tak więc zrobiliśmy.
W pierwszej kolejności wpisaliśmy konfigurację BGP na zapasowym węźle (bez adresów IP) i odpięliśmy adresy od interfejsów zewnętrznych na podstawowym routerze, które swoją drogą u nas są VLANami - i z VLANami klastrowanie w Vyacie również działa. Po zacommitownaiu spowodowało to oczywiście rozłączenie sesji BGP, ale oba systemy cały czas próbowały nawiązać je z powrotem - i to naprowadziło nas na plan awaryjny, gdyby quagga nie dała się elegancko sklastrować. W drugim kroku wpisaliśmy konfigurację klastra na obu węzłach (wirtalne adresy IP i usługa vyatta-quaga) i zacommitowaliśmy. Na pierwszy rzut oka wszystko wyglądało w porządku - grupa quagga została zatrzymana na zapasowym węźle, a na podstawowym nawiązały się sesje BGP.
Niestety pojawił się problem, który pozostaje trochę niewyjaśniony i nawet na forum Vyatty nie udało nam się uzyskać do niego rozwiązania - w opisanej wyżej konfiguracji wydanie prostych poleceń na aktywnym węźle (np. show ip bgp summary) skutkowało zawieszeniem konsoli. Ponadto po restarcie routera system wyrzucił masę błędów i po prostu się zresetował. Doszliśmy do wniosku, że coś jest nie tak i usunęliśmy wpis dotyczący quaggi z konfiguracji klastra. Jaki był efekt? Prawidłowy - quagga co prawda wystartowała na obu węzłach, ale zapasowy nie miał adresów IP, więc i tak nie mógł ustanowić sesji BGP. Test klastra - wyłączenie podstawowego węzła - poskutkował przeniesieniem adresów IP na drugi węzeł, przez co ten od razu nawiązał sesje BGP. Polityki firewalla i Qos "złapały" na drugim węźle bez problemów po przeniesieniu adresów IP. Przerwa trwała jedynie chwilę - kilka sekund, które ustawiliśmy w parametrze dead-interval plus kilka sekund na przeniesienie adresów. Po ponownym wystartowaniu pierwszego węzła automatycznie stał się on zapasowym, bo używamy konfiguracji auto-failback false.