Akcja Play dla WOŚP 2019 była wydarzeniem o ogólnopolskim zasięgu. Przygotowanie infrastruktury IT wymagało rozwiązania szeregu kwestii typowo inżynierskich, ponieważ w okresie WOŚP spodziewaliśmy się skokowego wzrostu obciążenia ruchu sieciowego. Rozwiązanie, które wprowadził Michał Gliński, Senior Network Administrator w Dataspace, zapewniło sprawne i bezproblemowe działanie usług podczas całej akcji.

Charakterystyka środowiska Klienta

Agencja Plej posiada dedykowany wielowęzłowy system oparty o Proxmox ze storage osadzonym na CEPH, sieć publiczną o przepływności 1 Gb/s oraz sieć wewnętrzną o przepustowości 10 Gb/s.

Główne wyzwanie

Spodziewamy się ruchu sieciowego powyżej 1 Gb/s. Jak zmieścić ruch sieciowy o wolumenie ponad 1 Gb/s na serwerach, które posiadają fizyczny interfejs o przepływności 1 Gb/s?

Rozwiązanie

Problem ten rozwiązaliśmy poprzez zastosowanie dwóch mechanizmów – round robin DNS oraz programowego load balancera pod postacią HaProxy. Domena playdlawosp.pl rozwiązywała się na wiele adresów IP. Każdy z nich zaterminowany był na innej maszynie fizycznej będącej hostem wirtualizatora, co pozwalało stabilnie zwiększać dostępne pasmo. Z kolei każda z tych trzech maszyn wirtualnych znajdowała się na innym fizycznym serwerze.

W efekcie wielokrotnie zwiększyliśmy dostępne pasmo na czas trwania akcji i wprowadziliśmy mechanizm, który pozwala na dalsze skalowanie. HaProxy było połączone poprzez sieć wewnętrzną o przepływności 10 Gb/s z maszynami wirtualnymi, w których znajdowała się sama aplikacja.

Środowisko zostało tak przygotowane, aby w razie potrzeby dołożyć kolejne serwery aplikacyjne, które zrównoważyłyby obciążenie.

Rozwiązanie

Dużym wyzwaniem jest charakterystyka ruchu sieciowego (aplikacja www), w której to występuje bardzo wiele pakietów o małym rozmiarze. Taki ruch sieciowy generuje bardzo dużo przerwań dla procesora. Dla eliminacji tego wąskiego gardła zostało ręcznie skonfigurowane SNP affinity, zarówno dla maszyn fizycznych, jak i wirtualnych. Z poziomu maszyn wirtualnych było to możliwe poprzez dodanie kolejek do kart sieciowych.

Dzięki takiemu rozwiązaniu duży ruch sieciowy (wysoka ilość pakietów) mógł być obsługiwany przez zadaną ilość rdzeni procesora – np. maszyna wirtualna posiadająca 4 vCPU, 2 z nich obsługują ruch sieciowy, a 2 pozostałe odpowiadają za nginxa.