Knowledge base
Dlaczego wybraliśmy i porzuciliśmy Infinibanda? Czyli historia rozwoju najlepszego storage’u chmurowego
Posted by Marketing Department on 04.10.2016 12:52

Od stycznia 2013 roku do mniej więcej czerwca 2016 roku sieć storage’owa Oktawave działała w oparciu o technologię Infiniband. Pomiędzy czerwcem a połową lipca br. zrobiliśmy chyba największą dotychczasową rewolucję i wymieniliśmy całkowicie Infiniband na dobrze znany FC SAN (w tym przypadku 16 Gbps), przyznając tym samym, że nasze pierwotne założenia były być może nieco zbyt ambitne. Ale – jak mawiają – nie ma tego złego, co by na dobre nie wyszło. Nasza nowa architektura jest jeszcze wydajniejsza, a przy tym bardzo stabilna.

Jak to się wszystko zaczęło?
Cofnijmy się na chwilę w czasie. Jest połowa 2011 roku, pełną parą idą prace nad budową naszej platformy, a przyjęty deadline to pierwszy kwartał 2012 roku, kiedy planowaliśmy start testów beta. Jednym z najważniejszych założeń platformy było wówczas dostarczenie rozwiązań storage’owych o maksymalnej prędkości, niespotykanych nigdzie indziej (oraz w akceptowalnych cenach dla klienta).
Rezygnujemy więc z zakupów macierzy (1), budujemy własne rozwiązania oparte o drogie naówczas karty PCIe NVMe, tworzymy zręby architektury fizycznej oraz software’owej i zabieramy się do projektowania procesu dostarczania całej tej wydajności do maszyn wirtualnych. W efekcie ma powstać usługa nazwana później OVS (2).

Rynek wtedy poruszał się pomiędzy technologią FC SAN 4 i 8 Gbps oraz implementacją iSCSI we wczesnych sieciach 10G. Było jeszcze kilka innych technologii, ale w zasadzie marginalnych. Wpadliśmy wówczas na pomysł węzłów danych (a jest ich wiele) - tyle że każdy z nich ma wydajność od około 600 tys. do 800 tys. IOPS („randomowych” operacji na blokach 4K). FC SAN 8 Gbps jest w stanie na jednym kanale wykonać 200 tys. (i to w teorii, bo w praktyce na poziomie samego środowiska wirtualnego i uwzględniając narzuty hiperwizora, to jest mu bliżej do 160 tys.). Testy pokazały, że rozproszenie na wiele ścieżek, co prawda, zwiększa przepływność (powyżej 1 GB/s), ale za to narzut związany z przełączaniem wprowadza tak duże opóźnienia, że na poziomie IOPS jest raczej mniej. No cóż, wzór IOPS = 1 (s) / latency (s) x queue_depth (count) jest raczej nieubłagany. Kolejek nie da się zwiększać w nieskończoność, a opóźnienia (latency) nie damy rady zmniejszyć ani za pomocą skrócenia kabla, ani za pomocą dylatacji czasu czy też skróceniu Lorentza. O iSCSI nawet nie wspomnę, bo osiągane wartości to w ogóle nie ten rząd.

A może Infiniband?
I nagle ktoś rzucił pomysł: a co z Infinibandem? Przecież jest wykorzystywany od lat do tworzenia superkomputerów, QDR to ok 40 Gbps, a zbliżający się (wtedy) FDR jest jeszcze szybszy. Latency dla QDR to 1,3 mikrosekundy (FC był gdzieś bliżej połowy 1 milisekundy). Jest dobrze, ale zaraz: Infiniband to zazwyczaj RDMA, a my tu potrzebujemy implementacji SCSI. Mamy szczęście, jest również bowiem SRP. Brzmi to obiecująco, szkoda tylko że SRP był w wersji 4.x VMware ESX, który jest naszym podstawowym hiperwizorem, ale nie ma w wersji 5.0, z którą startujemy na produkcji (choć też jeszcze w fazie beta). Zaczynamy rozmowy z dostawcą – telefonicznie, e-mailowo, na konferencjach. Ostatecznie udaje się – za kilka miesięcy będziemy mieli potrzebną nam wersję.

Beta platformy Oktawave startuje na FC, ale faktycznie później wykonujemy zmianę i jest upragniony Infiniband! Tylko, że wraz z nim zaczyna się nasza przygoda. W miarę wzrostu ruchu zaczęły pojawiać się bolączki wynikające z zupełnie niedojrzałego drivera SRP dla Vmware powodujące m.in. gubienie ścieżek, blokowanie I/O, timeouty i w efekcie gubienie dostępu do storage’u z poziomu wirtualek, resety spanikowanych ESX-ów, przełączanie w r/o. Co z tego, że przepustowości są w porządku (faktycznie te 3 GB/s można było z dysków od Tier-2 w górę wycisnąć na poziomie wirtualki), jeśli na poziomie IOPS bywa średnio, a częste restarty powodują głęboką frustrację zarówno po stronie klienta, jak i po stronie administratorów. Nie poddajemy się, nadal jesteśmy przekonani, że to się da rozwiązać. Z biegiem czasu pojawiają się nowe drivery, ulepszamy konfigurację, co na kilka miesięcy przynosi spokój. Kolejne poziomy obciążenia sprawiają jednak, że zdarza nam się wracać do punktu wyjścia.

Męska decyzja
Uznajemy, że taki stan nie może się przedłużać i nie możemy liczyć na to, że dostawcy oprogramowania wykonają swoją pracę. Nasza sieć była już wówczas bardzo duża, obejmowała trzy niezależne subregiony, a do tego na początku tego roku zaplanowaliśmy największą chyba w historii rozbudowę infrastruktury – właściwie zamierzaliśmy podwoić jej wielkość. I to był ten moment, kiedy podjęliśmy decyzję o całkowitym wycofaniu się z Infinibanda. Początkowo tylko dla nowej infrastruktury, ale ostatecznie wymieniliśmy po prostu wszystko.

Oprócz zrealizowania rozbudowy (na marginesie: jest już dostępny subregion PL-004, za niedługi pojawi się PL-005 i pewnie jeszcze kilka miłych niespodzianek), w każdym z subregionów zostało wymienione okablowanie, przełączniki, karty HCA/HBA, konfiguracja węzłów danych – jednym słowem operacja na dużą skalę i to w zamierzeniu online. Nie wnikając już w same szczegóły tej operacji, ostatecznie każdy z subregionów został przemigrowany na funkcjonującą obecnie na rynku FC SAN 16 Gbps (przepraszamy, ale nadal nic innego się nie nadaje i jest to nasza personalna niewzruszona opinia).

Nowe wspaniałe Oktawave
Tutaj realne są już cyfry na poziomie 350 tys. IOPS na poziomie pojedynczej ścieżki i już z poziomu wirtualki. Na dwóch ścieżkach da się przekroczyć też 3 GB/s transferu. To wszystko, co prawda, na Intelach 2660 v3, ale starsze Intele pracujące w PL-001 też osiągają wartość 200 tys. IOPS, a procesory AMD w PL-002 i PL-003 pokonują magiczną barierę 100 tys. IOPS.

Uzupełniając obraz sytuacji i dla czystości przekazu, musimy także wspomnieć, że zmieniliśmy też nieco architekturę węzłów danych – porzucając pomysły synchronicznej czy asynchronicznej replikacji i obecnie w większości przypadków stosujemy klasyczny układ spotykany w regularnych macierzach dyskowych, tj. każdy węzeł danych składa się z pary urządzeń (serwerów) tzw. head (head A/B), każdy wyposażony w odpowiednie interfejsy (HBA) służące do podłączenia do sieci danych, własne kontrolery danych, współdzielone nośniki danych oraz własne oprogramowanie – co w zasadzie jest analogiczne do klasycznej macierzy z dwoma kontrolerami pracującymi w trybie A/A. Wyjątkiem są węzły dostarczające Tier-5 gdzie konfiguracja jest zupełnie inna – ale to materiał na inny artykuł. Technicznie heady są to urządzenia zbudowane w oparciu o klasyczne serwery x86, ale posiadające optymalną względem obsługi operacji I/O konfigurację sprzętową i programową.

Podsumowując, od czasu tej całej migracji skończyły się właściwie wszystkie problemy związane z medium transmisyjnym: brak restartów, przełączeń, nieoczekiwanych odmów współpracy. Wniosek płynie z tego taki, że chyba próbowaliśmy prześcignąć swój czas, tyle że postawiliśmy na złego konia. Dzisiaj niektóre technologie dorosły już to tych prędkości, które staramy się dostarczyć, ale my także z dużo większą ostrożnością patrzymy na nowe ambitne pomysły, w końcu nie jesteśmy już małym doświadczalnym laboratorium osadzonym w świecie startupów i absolutnym priorytetem jest dla nas komfort naszych klientów.

Niedługo opublikujemy też w naszej bazie wiedzy dokument, w którym będzie można znaleźć znormalizowane dane szybkości działania OVS w poszczególnych subregionach, metody optymalizacji, tuningowania oraz kilka innych życiowych porad.

Na koniec wszystkich chętnych zapraszamy do sprawdzenia, jak to wszystko teraz działa, a szczególnej uwadze polecamy subregion PL-004.

 

==========

(1) Wówczas ceny macierzy, które choćby zbliżają się do zakładanych parametrów, wyrażały się w liczbach 6 i 7 cyfrowych (USD).

(2) Dyski OVS są implementacją urządzeń blokowych (zwykłych dysków znanych z desktopów, serwerów) w zwirtualizowanej sieci danych Oktawave. Dyski OVS są niezależną i oddzielną usługą od pozostałych usług Oktawave (w szczególności od OCI). Obecnie korzystanie z usługi dysków OVS wymaga posiadania co najmniej jednego serwera OCI, do którego dysk OVS będzie można podłączyć. Dyski OVS jako oddzielna usługa posiada także swoje nominalne i maksymalne parametry pracy (niezależne od serwera OCI), a ich osiągnięcie z pespektywy serwera OCI zależne jest od wielu czynników – w tym przepustowości sieci w danych subregionie, wydajności i rodzaju procesorów w subregionie, rodzaju sterownika zainstalowanego na serwerze OCI i ustawień długości.

(3 vote(s))
This article was helpful
This article was not helpful

Comments (0)
Post a new comment
 
 
Full Name:
Email:
Comments:
CAPTCHA Verification 
 
Please enter the text you see in the image into the textbox below. This is required to prevent automated registrations and form submissions.