Kryzys ekonomiczny daje o sobie znać coraz częściej i powoli zaczyna dotykać również sektora IT. Tymczasem obsługa kilku milionów użytkowników i przerzucenie kilkudziesięciu milionów odsłon miesięcznie to nie lada wyzwanie, jeśli chodzi o zapotrzebowanie na łącza, a co za tym idzie - pieniądze. Nie tylko sam ruch na stronach, ale także materiały wideo, demonstracje, webcasty – to wszystko pochłania megabity w bardzo szybkim tempie. Jeśli dodatkowo pod uwagę weźmie się jesienny okres szybkiego wzrostu oglądalności i fakt, że największy serwis w całym naszym portfolio – dobreprogramy.pl – to w większości hosting dużych plików, łatwo zdać sobie sprawę, że rozmowa o wymaganej przepustowości prowadzona jest w kontekście dziesiątek albo i setek megabitów.
Sukcesywnie powiększamy więc dostępne pasmo, także poprzez wpinanie się do takich sieci jak AC-X i PLIX. Całkiem niedawno okazało się jednak, że o ile rozszerzanie łącza nie sprawia większych problemów, tak nasza aktualna infrastruktura przyłączeniowa niestety z gumy nie jest i specyfikacji technicznej nie przeskoczy. Wykorzystywany przez nas od dłuższego czasu router Cisco 7140 z obsługą BGP, zdolny przetworzyć 100 megabitów ruchu przestał już nam wystarczać. Z tego powodu musieliśmy wstrzymywać się z publikacją m.in. materiałów wideo czy demonstracji w bardziej hurtowych ilościach, bo w przeciwnym wypadku sami skazalibyśmy się na DoS. Potrzebowaliśmy więc czegoś, co pozwoli pokonać tę magiczną barierę i wysyłać w świat więcej niż 100 megabitów programów, filmów, demonstracji.
Traffic
Techniczna bariera 100 Mbps była, jak widać, naprawdę sporym problemem...
Możliwych rozwiązań było kilka. Najprostszym z nich byłaby wymiana routera na jego odpowiednik z gigabitowej półki. Naszym wymaganiom sprostałby router Cisco z serii 7200 z trzema gigabitowymi portami. Niestety cena takich rozwiązań jest mrożąca - trzeba za nie zapłacić prawie 50 tysięcy złotych netto. Zwyczajnie zakup tak drogiego urządzenia nie wchodził więc w grę. Drugie rozwiązanie, czyli zakup wyłącznie gigabitowych kart do istniejącgo routera również było drogie, a nie rozwiązywało do końca problemu – jedna karta kosztuje około 10 tysięcy złotych netto, a i tak bez zmiany kontrolera moglibyśmy przesyłać nie więcej niż 200 megabitów. Zdecydowaliśmy się więc na trzecie rozwiązanie, mocno eksperymentalne, ale nie bez szans na powodzenie. To rozwiązanie to zastąpienie sprzętowego routera Cisco serwerem pracującym pod kontrolą specjalistycznej dystrybucji Linuksa przeznaczonej do budowy routerów – Vyatta.
Nie jest tajemnicą, że nasze środowisko hostingowe dotychczas było oparte w pełni o rozwiązania Windows Server System. Konfiguracja dość „surowego” systemu opartego na Debianie była więc dla nas, zatwardziałych administratorów Windows bardzo interesującym, ale i wymagającym wyzwaniem. Razem z Tomkiem Bryją zastanawialiśmy się, czy to w ogóle będzie działać, a kiedy już zadziała, to czy będzie się nadawało do stałego wykorzystania w naszym środowisku. Sporo osób, z którymi rozmawialiśmy nie wróżyło sukcesów – byli to zwolennicy „pewnych” i stosunkowo łatwych w utrzymaniu oraz konfiguracji rozwiązań sprzętowych, z politowaniem spoglądający w stronę naszego serwera-routera wypchanego kartami sieciowymi.
Czym zatem jest Vyatta? To specjalistyczna dystrybucja Linuksa oparta na Debianie, od początku do końca zaprojektowana do pełnienia funkcji routera. Obsługuje wszystkie najważniejsze protokoły, począwszy od RIP przez OSPF na BGP kończąc. W aktualnej wersji 4.1 posiada póki co jeszcze eksperymentalne opcje inspekcji ruchu, filtrowania i wykrywania włamań. Dodatkowo można ją skonfigurować jako bramkę VPN z obsługą PPTP, L2TP i IPSec oraz współpracą z RADIUS. Dostępny jest też serwer DHCP, NAT, protokół QoS, PPPoE, SNMP. Całość została ubrana w specjalny interfejs użytkownika, który umożliwia banalne wręcz poruszanie się po drzewiastej strukturze konfiguracji podobnej do urządzeń Juniper. Dzięki tak zbudowanemu interfejsowi nie trzeba w ogóle (a jak się później okazało, jest to nawet niewskazane) zaglądać do plików konfiguracyjnych poszczególnych demonów, a wszystkie zmiany wykonuje się wpisując odpowiednie kombinacje poleceń show, set i delete – wcześniej korzystając w razie potrzeby z rozbudowanego systemu pomocy i podpowiadania składni poleceń.
Na router wybraliśmy wcale nie najmocniejszą maszynę HP ProLiant ML110 G5 z procesorem Core 2 Duo i 1 GB pamięci RAM. Wkrótce okazało się, że to i tak aż nadto. Zapłaciliśmy za nią niewiele ponad tysiąc złotych netto. Po wstępnym skonfigurowaniu serwera w biurze i transporcie do serwerowni system rozpoczął pracę praktycznie od razu po podłączeniu kabli sieciowych. Byliśmy przygotowani na różne scenariusze, bo musimy uczciwie przyznać, że nie było to pierwsze podejście – jakiś czas temu, jeszcze w wersji VC2 (czyli dwie wstecz od dzisiaj) system zamienił miejscami interfejsy sieciowe podczas jazdy samochodem i po uruchomieniu w serwerowni oraz marnych próbach rekonfiguracji na miejscu szybko okazało się, że można jechać z powrotem. Wygląda więc na to, że programiści Vyatty przez te parę miesięcy wykonali kawał dobrej roboty i tym razem system spisał się wyśmienicie, a my zaoszczędziliśmy ładnych kilkanaście tysięcy złotych, co w dobie ogólnoświatowego kryzysu ekonomicznego jest naprawdę świetnym wynikiem
Traffic
Serwer miałby dłuższy uptime gdyby nie awaria prądu
Vyatta rozwiązała jeszcze jeden nasz problem – pozbyliśmy się ISA Servera, który dotąd funkcjonował jako pomost pomiędzy routerem Cisco i naszą siecią lokalną. ISA była już bardzo ociężała, a sensowność jej istnienia malała z każdym kolejnym megabitem ruchu, który musiała przełknąć. W pewnym momencie zmuszeni byliśmy po prostu wyłączyć większość funkcji, które w ISA są najfajniejsze – na przykład filtrowanie ruchu w warstwie aplikacji. Serwer po prostu nie dawał rady i powodował opóźnienia, które w tej sytuacji są nie do przyjęcia. Nasze doświadczenia z ISA pokazują, że to rozwiązanie po prostu nie nadaje się do zastosowania jako serwer graniczny w infrastrukturze hostingowej z tak dużym ruchem. Jest jeszcze jedna rzecz: ISA nie obsługuje protokołu BGP i na razie nic nie wskazuje na to, by wkrótce miało się to zmienić, a ewentualna chęć zapewnienia redundancji czy rozłożenia obciążenia w przyszłości wiązała się z koniecznością zakupu drogich licencji Enterprise.
Niestety jedna rzecz nas zabolała - ISA świetnie spisywała się jako bramka VPN, czego nie można powiedzieć o Vyacie. Okazało się, że korzystając z wychwalanego przeze mnie parę zdań wyżej interfejsu da się skonfigurować tylko kilka podstawowych opcji VPN, które być może zadowolą administratorów sieci biurowych, ale na pewno nie sprostają wymogom bardziej rozbudowanych środowisk. Niczym konkretnym nie skończyła się również próba ręcznej konfiguracji demonów odpowiadających za VPN – każdorazowo przy restarcie serwera Vyatta i tak nadpisywała całą ręczną konfigurację swoją własną. Problemem nie do przeskoczenia było między innymi zmuszenie systemu do współpracy z serwerem DHCP. Ostatecznie serwer VPN uruchomiliśmy korzystając ze sprawdzonych usług Routing and Remote Access w Windows Server 2003.
Traffic
Konfiguracja VPN do rozbudowanych niestety nie należy
Podsumowując, Vyatta wydaje się bardzo dobrą alternatywą dla zaawansowanych i drogich sprzętowych routerów. Choć skala i poziom niektórych błędów poprawianych w kolejnych wydaniach mogą wprowadzać cień wątpliwości, to nasze doświadczenia pokazują, że przynajmniej fundamentalne komponenty systemu są wykonane bardzo przyzwoicie. Powierzyliśmy Vyacie obsługę kilkudziesięciu milionów odsłon naszych witryn w miesiącu i po kilku tygodniach bezawaryjnej pracy możemy z czystym sumieniem powiedzieć – udało się. Możemy też z czystym sumieniem polecić to rozwiązanie innym. By zachęcić Was do eksperymentów, testów, a może nawet produkcyjnych wdrożeń rozpoczęliśmy cykl publikacji na temat Vyatty – na początek polecamy lekkie i łatwe w odbiorze demonstracje. Zapraszamy też do dyskusji na forum, gdzie chętnie odpowiemy na Wasze pytania.
