Testujemy wirtualną szafę vRack w OVH: instalacja poda Diaspory

Wirtualizacja zawładnęła hostingiem. W imię zwiększenia wydajności i obniżenia kosztów, wirtualizuje się praktycznie wszystkie elementy infrastruktury serwerowej i sieciowej. A skoro zwirtualizowaliśmy już serwery, to czemu nie zwirtualizować serwerowej szafy? Taką właśnie technologię vRack oferuje OVH, by łatwo rozwiązać całkiem realny problem łączenia różnych serwerów i usług, położonych w różnych centrach danych. Jak to może działać w praktyce? Mieliśmy możliwość przetestować rozwiązanie vRack, wraz z kilkoma serwerami dedykowanymi od OVH, na wybranej przez siebie aplikacji. Postanowiliśmy zrobić coś pożytecznego, społecznościowego – postawiliśmy własny pod (węzeł składający się z kilku serwerów) sieci społecznościowej Diaspora.

Na początek trochę teorii. Wirtualna szafa vRack pozwala na podłączenie wielu serwerów do wirtualnego switcha, poprzez który mogą się one bezpiecznie komunikować, nie tylko w sposób niewidzialny dla innych internautów (z pominięciem sieci publicznej), ale także niewidzialny dla innych użytkowników infrastruktury operatora. Jest to możliwe dzięki zastosowaniu jednej lub więcej wydzielonych wirtualnych sieci prywatnych.

Powodów sięgnięcia po taką technologię może być wiele: vRack pomoże także przy budowie infrastruktury hybrydowej, w której łączy się publiczne i prywatne serwery firmowe, przy tworzeniu infrastruktury z wysokim poziomem bezpieczeństwa dla sieci firmowej, czy też przy budowaniu usług rozproszonych między różnymi centrami danych – gdy np. ze względów prawnych dane użytkowników muszą być przetwarzane na serwerze bazodanowym znajdującym się w określonym państwie, podczas gdy całą resztę można uruchomić w bardziej dogodnych miejscach. Wszystko to bez potrzeby wynajmowania szaf w centrach danych i fizycznego przemieszczania serwerów.

Pierwsza generacja vRacka (Virtual Rack 1.0) działała w obrębie jednej lokalizacji i pozwalała łączyć serwery dedykowane w sieć prywatną w serwerowniach zlokalizowanych w Roubaix. Wersja 1.5 pozwoliła na komunikację pomiędzy wieloma centrami danych OVH, a także łączenie serwerów w prywatnych chmurach, w ramach izolowanej sieci.

Kolejna wersja vRack wykorzystywała technologię QinQ. Pozwalała ona, między innymi, na stworzenie za pomocą tagów kilku sieci VLAN wewnątrz tej samej ramki Ethernet. W ramach vRack 2.0 każdy z użytkowników miał możliwość konfiguracji wielu sieci VLAN - aż do 4 tys. - w celu lepszego odizolowania poszczególnych elementów infrastruktury. Dzięki podziałowi instalacji na szczelne, z punktu widzenia sieci, segmenty jest ona dobrze zabezpieczona przed zewnętrzną ingerencją.

Od połowy 2016 roku dostępny jest vRack 3.0, który wreszcie umożliwił łączenie w prywatnych sieciach wszystkich typów serwerów (a więc dedykowanych, instancji chmurowych Public Cloud, a także infrastruktur dedykowanych Private Cloud). vRack 3.0 nie opiera się już na QinQ, ale na technologii VxLAN, co pozwala podnieść teoretyczną granicę dostępnych VLANów do 16 milionów w ramach tej samej domeny. Dodatkowo, dzięki wysyłaniu ramek UDP bezpośrednio na wartswę 2, technologia umożliwia segmentację VLAN na zewnątrz pojedynczej domeny Ethernet, pozwalając tym samym na jej pominięcie. W ramach wirtualnego centrum danych, VxLAN poszerza w znaczący sposób sieci warstwy 2, oferując więcej elastyczności administratorom.

Centra danych OVH są obecnie połączone światłowodami z gęstym zwielokrotnieniem falowym (DWDM), oferując w Europie wewnętrznie łączną przepustowość 3 Tb/s. OVH ma także swoją swoją sieć w Ameryce Północnej, a obie spięte są po dnie Atlantyku kablami o przepustowości 200 Gb/s.

Panel klienta OVH pozwala na szybkie skonfigurowaniewirtualnej sieciowej infrastruktury. Do testowego konta dostaliśmytrzy serwery dedykowane HOST-128L z 128 GB RAM-u DDR4, dwoma 2-terabajtowymi dyskami, gigabitową kartą vRack i przepustowością 250 MB/s: dwa zlokalizowane w polskim centrum danych (WAW-1) i jeden w kanadyjskim Beauharnois (BHS-1).

Instalacja systemu na dedykowanym serwerze jest dość prosta: dostawca rozwiązań chmurowych oferuje dziś do wyboru gotowe obrazy kilkudziesięciu różnych systemów operacyjnych (w większości linuksowych), a także gotowe do użytku środowiska administracyjne i wirtualizacyjne (np. cPanel czy VMware ESXi). By było jak najprościej, zdecydowaliśmy się zainstalować wszędzie Ubuntu Server 16.04 w domyślnej konfiguracji, z dwoma dyskami JBOD (Just a Bunch Of Drives).

Przed zainstalowaniem serwera poprzez prosty kreator OVH, trzeba jednak pamiętać o wygenerowaniu pary kluczy do połączenia SSH – bez tego zdalnie się z serwerem nie połączymy. Odbywa się to nie na poziomie konfiguracji serwera, ale w konfiguracji konta użytkownika. Robimy to poleceniem ssh-keygen -b4096, a potem wygenerowany klucz publiczny (.pub) kopiujemy do formularza w panelu klienta. Jeżeli klucz nie został wygenerowany, system automatycznie wyśle e-maila z hasłem dostępu do SSH.

Zainstalowane i skonfigurowane serwery otrzymują domyślne nazwy domenowe i adresy IP – w tym momencie można już zacząć instalować na nich oprogramowanie. Wcześniej jednak skonfigurujemy wirtualną szafę.

W panelu klienta, w zakładce usługi vRack należy kliknąć przycisk +. Po jej aktywacji dostajemy listę dostępnych usług oraz „kontener” wirtualnej szafy. Umieszczenie tam wybranych serwerów czy usług sprowadza się do ich zaznaczenia i kliknięcia przycisku Dodaj – konfiguracja zajmuje kilka chwil.

O tym, że serwer znalazł się w wirtualnej szafie, informuje komunikat w polu Przepustowość usługi vRack – dla naszej konfiguracji to 1 Gb/s. Oznacza to, że serwery w ramach vRacka będą mogły komunikować się z pełną szybkością, podczas gdy komunikacja poza prywatną siecią to dla testowanego mostu byłoby już „tylko” 250 Mb/s. Dostępne są jednak także serwery, które dysponują przepustowością 500 Mb/s. Istnieje także możliwość zwiększenia jej do 3 Gb/s.

Sprawdzimy możliwości infrastruktury OVH, uruchamiając na niej serwer Diaspory. To zdecentralizowany portal społecznościowy, stawiający na wolność i prywatność użytkowników którzy korzystają z rozproszonej sieci niezależnych serwerów, tzw. podów. Każdy może mieć swój własny pod: wystarczy, że zainstaluje i skonfiguruje oprogramowanie Diaspory na własnym serwerze.

Popularność Diaspory jest oczywiście znikoma w porównaniu do przeznaczonych dla masowego użytkownika sieci społecznościowych, dziś konta w niej ma raptem 650 tys. osób (a może 50 tys. aktywnie korzysta), ale z drugiej strony, czy zawsze liczby przekładają się na jakość udostępnianych treści? Poza tym, w przeciwieństwie do popularnych serwisów, tu możemy zrobić coś swojego. Każdy z założonych podów Diaspory może połączyć się z innymi w ramach federacji, pozwalając na swobodna komunikację między ich użytkownikami.

Instalacja poda Diaspory jest dobrze udokumentowana i nie powinna sprawić kłopotu nikomu, kto zna się na choć trochę na Linuksie.

Instalacja zaczyna się od niezbędnych pakietów dla serwera aplikacyjnego i utworzenia użytkownika Diaspory. Później należy zainstalować (z uprawnieniami tego użytkownika) Ruby Version Manger – i tu mogą pojawić się pierwsze problemy, związane z obsługą cyfrowych podpisów. Nie wdając się w szczegóły, pomoże ręczne pobranie i zainstalowanie klucza mpapis, tak jak to opisano w dokumentacji. Instalacja samej aplikacji Diaspory sprowadza się do pobrania jej kodu z GitHuba, a następnie pobraniu niezbędnych bibliotek. Na tym etapie warto skonfigurować jeszcze reverse proxy dla używanego serwera WWW – przez niego będą przechodziły wszystkie statyczne treści, podczas gdy inne wywołania zostaną przekierowane do Diaspory. Dostępne są gotowe takie konfiguracje, m.in. dla standardowego Apache.Na drugim serwerze, zainstalowaliśmy bazę danych PostgreSQL, założyliśmy użytkownika dla Diaspory z uprawnieniem do zakładania baz i przygotowaliśmy jej konfigurację. Warto skorzystać z poradnika dostępnego na stronach pomocy Ubuntu. Tak jak opisano tam na początku, należy pamiętać o włączeniu możliwości łączenia się z serwerem bazodanowym dla innych komputerów – normalnie dopuszczony jest tylko localhost.

Po zainstalowaniu Diaspory pozostaje nam przebić się przez jej konfigurację, w praktyce zawartą w dwóch plikach YAML (.yml): config/database.yml oraz config/diaspora.yml .

Najważniejsze parametry, jakie należy ustawić w diaspora.yml to:

• sekcja environment | url – publiczny adres (domena internetowa) poda.
• Sekcja environment | certificate_authorities – odhaszować wersję dla Debiana.
• Sekcja environment | require_ssl – jeśli nie mamy certyfikatu SSL (nie chciało się nam korzystać z Let's Encrypt), należy ustawić na false.
• Sekcja server | rails_environment – koniecznie ustawić na \production.
• Sekcja settings | pod_name – nazwa poda wyświetlana w różnych miejscach.

W database.yml należy ustawić parametry połączenia z bazą danych, czyli adres hosta (naszego serwera bazodanowego), nazwę użytkownika ("diaspora") oraz hasło.

Finalny krok to uruchomienie narzędzia rake z parametrami podanymi w dokumentacji (to odpowiednik normalnego Make dla Ruby on Rails), a następnie uruchomienie servera diaspory – ./script/server.

Na tym etapie mamy już działający pod Diaspory, pozostaje założyć pierwszego użytkownika, w prostym (dla odmiany!) formularzu przeglądarki, a następnie podać nieco informacji o sobie (włącznie z wgraniem fotki) i swoich zainteresowaniach. Klikając przycisk „świetnie – zabierz mnie na Diasporę” możemy już trafić na serwer jako jego pierwszy użytkownik.