20:56
25/8/2016

Rozpoczynamy nowy cykl artykułów “z placu boju“. Pisane przez praktyków w formie case-studies — bez lania wody i czasem z przyznaniem się do błędów — opisują doświadczenia (zarówno te pozytywne jak i negatywne) związane z wdrażanymi rozwiązaniami i podejmowanymi decyzjami projektowymi. Cykl otwiera artykuł Macieja Kuźniara, CEO Oktawave, który podzielił się z nami historią opisującą kulisy decyzji i dylematy, z jakimi borykał się zespół polskiej chmury, chcąc zapewnić jej odpowiednie parametry. Oddajemy głos Maciejowi i obiecujemy, że warto doczytać tekst do końca — tam czeka na was drobny prezent :)

Rewolucje w storage’u

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, budujemy własne rozwiązania oparte o rzadko spotykane naówczas karty PCIe NVMe, tworzymy zręby architektury fizycznej oraz software’owej i zabieramy się do projektowania sieci dostarczającej całą tą wydajność do maszyn wirtualnych. W efekcie ma powstać usługa nazwana później OVS.

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 – tyle że każdy z nich (a jest ich wiele) 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 pomiędzy ścieżkami wprowadza tak duże opóźnienia, że na poziomie IOPS jest raczej mniej. No cóż, uproszczony (pomijamy ilość operacji „w locie”) 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 różnie, 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 zazwyczaj na kilka miesięcy przynosi spokój. Kolejne poziomy obciążenia sprawiają jednak, że zdarza nam się wracać do punktu wyjścia smutno patrząc na śmierć światów:

unnamed-11

Męska decyzja

Uznajemy, że taki stan nie może się przedłużać a nie możemy już 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 we wszystkich subregionach.

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 (iSer też) i jest to nasza personalna niewzruszona opinia).

Nowe 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.

Sprawdź sam!

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

Specjalnie dla czytelników Niebezpiecznika (a dokładnie dla pierwszych 200 czytelników) udostępniamy kod na 50 zł na przetestowanie chmury obliczeniowej Oktawave.

Aby wykorzystać kod, zarejestruj konto w Oktawave, a następnie zaloguj się do panelu administracyjnego. W menu po prawej stronie wybierz zakładkę BILLING i wybierz formę płatności KOD PROMOCYJNY oraz wpisz w odpowiednie okienko kod 1tNM8hgb, następnie kliknij przycisk DALEJ. Po zaakceptowaniu transakcji Twoje konto w Oktawave zostanie zasilone kwotą odpowiadającą wartości kodu promocyjnego.

Kod jest ważny do 31 sierpnia 2016. Sprawdź chmurę już dziś!


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

36 komentarzy

Dodaj komentarz
  1. a jeśli podam ten kod 200 razy ?

    • działa tylko raz ;)

  2. Dobra, a na czym polegał tu błąd? Jedyny jaki ja widzę to platforma sprzedawana jako produkcyjna, stojąca na oprogramowaniu w wersji beta .

    • artykuł zawiera lokowanie produktu? :)

  3. Skoro o chmurach, to z innej beczki – najciekawsza z nich była chińska Yunio. Oferowali 1 TB za free, a polskie portale się o niej rozpisywały. Po upływie około roku pojawił się na ich stronie napis “THNX”, Twory z chin pokroju Weiyun 36 TB radzę omijać.

  4. To Cię znajdziemy i zjemy ;)

  5. Oktawave zbiera nr PESEL przy zakładaniu konta WTF?!

    • Nie trzeba podawać

  6. Podaj imię, nazwisko, nr telefonu, adres i PESEL (!). Nie podoba mi się to. W szczególności ten PESEL :/

  7. Żeby zarejestrować konto trzeba podać wszystkie swoje dane: imię, nazwisko, adres zamieszkania, numer telefonu. Nie można do testów tego pominąć?

  8. Nie działa – już wszystkie kody wykorzystane? :(

    • Tak się składa :) Zainteresowanych kodami na testy prosimy o kontakt z bok@oktawave.com, będziemy pewnie dystrybuować jeszcze dodatkowe

    • u mnie też nie działa :(

    • to nie ja ;)

    • Taa… napisałem na bok czym prędzej i cisza aż tu wczoraj nocą gdzie dostaje DSRkę :D
      Wg. strony BOK ma adres customer@oktawave.com i widać nie mają aliasu bok@.

      Delivery to the following recipient has been delayed:
      bok@oktawave.pl
      Message will be retried for 1 more day(s)
      Technical details of temporary failure:
      The recipient server did not accept our requests to connect. Learn more at https://support.google.com/mail/answer/7720
      [oktawave.pl 2001:1a68:b:1:2:149:198:21: socket error]
      [oktawave.pl 195.149.198.21: socket error]

  9. Bardzo ciekawy art. Rozumiem ze taka moc obliczeniowa jest wazna… Ale na przykladzie mojej firmy. Deweloper pisze sobie aplikacyjke ktora mieli baze danych i dodaje oraz przerabia rekordy baza powiedzmy 6 tb. I na chmurce wynajetej dziala super swietnie bo ma do dyspozycji milion iops a potem leci to na test i tez dziala bo na tescie baza mniejsza a jak dolatuje do preproda albo proda to sie zaczynaja schody glowna macierz nie wyrabia. Staje deba i proces ten co na chmurce trwal 4h noe jest wstanie sie przerobic przez 24 h. Potem taki developer twierdzi to zmiencie macierz kupcie dedykowana pod moja aplikacje…. Czasami tak sie dzieje ze toak sie robi a po 2 miesiacach okazuje sie ze developer popelnil blad w optymalizacji….. Tylko na mega wydajnej chmurce nie byl w stanie tego dostrzec bo wsYstko smigalo….

    • Developer powinien brać pod uwagę konfigurację środowiska produkcyjnego i w opisanej sytuacji jest to zwyczajnie jego błąd. Jeśli to było w Oktawave powinien ustawić dyski w Tier-1 i wtedy będą one pracować z prędkością maks ok. 1,000 IOPS co odpowiada mniej więcej macierzy z 7-8 dyskami w R5. Taka konfiguracja jest wtedy analogiczna dla środowiska z macierzą. Inne rozwiązanie to uruchomić środowisko produkcyjne w chmurze.

    • Dokladnie! Dlatego pamietam co powtarzal moj pierwszy szef: deweloperzy powinni pracowac na relatywnie slabych komputerach (srodowisku), wlasnie aby uniknac sytuacji jaka opisales. Niestety o wiele czesciej zdarza sie z ze wzgledow -powiedzmy- srodowiskowych, wszystko dziala poprawnie, a po oddaniu oprogramowania klientowi zaczynaja sie schody.

    • I oczywiście to wina super wydajnej chmury a nie developera że napisał nie wydajny kod.

  10. Historia bardzo znajoma. Przeszliśmy podobną drogę, ale zaczynając od IB na ESX 3.5 ostatecznie kończąc, kilka lat później, na iSCSI po 10Gb. Prawda, że Infiniband dla ESX był w tamtych latach dość nowatorskim rozwiązaniem, a dostawcy byli zupełnie nieprzygotowani. Dziś już chyba nikt w IB dla hypervisor’ów inwestował nie będzie, a sama technologia zostanie niszową “ciekawostką” dla rozwiązań typu Oracle Exadata…

    • Tak kategorycznie bym samej technologii nie odrzucał, w przypadku ESX’ów jest chyba konflikt interesów pomiędzy wspieraniem producentów macierzy (EMC) którzy nie kochają tej technologii póki co (a wręcz przeszkadza) oraz otwartym środowiskami. Drivery OFED pod czystym linuxem działają bardzo ładnie, osiągając rzeczywiste i stabilne prędkości
      daleko powyżej nawet FC 16Gbps. Tylko że trzeba wtedy inny hyperwizor..

  11. Czekamy na artykuł opłacony przez 2be.pl próbujący odzyskać wizerunek.

    • “HOSTING
      O KTÓRY NIE MUSISZ SIĘ MARTWIĆ”

      :D

    • Ach morda się sama śmieje na wspomnienie Bartusia :D

  12. Założyłem wczoraj konto a dzisiaj dostałem email, który zaczynał się tak:

    Proces rejestracji został zakończony, a Pana konto aktywowane.
    Aby skorzystać z promocji 25 zł na start proszę o przesłanie skanu dokumentu tożsamości w celu weryfikacji wprowadzonych danych (dowodu osobistego, prawa jazdy itp.).

    WTF??

    • Tak samo jak ja.

    • Oczywiście rozumiem, dlaczego chcą weryfikować tożsamość i to, że nie muszę przesyłać skanu, żeby korzystać z ich usług, ale proszenie o skan dowodu, nawet jeżeli dają w zamian 25 zł to jest GRUBA przesada.

  13. Przesyłanie skanu niepokojące niestety. No i kody już zużyte :(.

  14. https://www.oktawave.com/pl
    Threat Reason: Domain reported and verified as serving malware. Identified as malicious domain or URL.
    Notification: WBRS

  15. 43 zł za najniższą ofertę z 1VCPU to tak tanio?

    https://www.ovh.pl/vps/vps-ssd.xml

  16. Założyłem konto podając poprawne dane a Ci piszą mi tak:

    Blokada konta
    Twoje konto zostało zablokowane i zakolejkowane do usunięcia. W celu odblokowania konta skontaktuj się z Biurem Obsługi Klienta w ciągu 7 dni.

    Rejestracja bez podawania PESEL a jako że mieszkam na wsi (moderniej zwane miejscowością) to nazwa ulicy podana jako “-” a wg. nich pewnie ulica musi być. Powinienem podać ich adres siedziby :)

  17. Niebezpiecznika chyba nie czytają same mastahaki. Spodziewam się, że dla ludzi z “branży” wszystko jest jasne, ale można byłoby wziąć pod uwagę, że zaglądają tu “fahofcy od wszystkiego ;)” co to na internetach znają się najlepiej na świecie :).
    Artykuł bardzo techniczny, na niektóre określenia musiałem poświęcić trochę czasu aby zatrybić o co chodzi.

  18. Oktawave – nie polecam.
    Support – specjaliści w odbijaniu piłeczki.

    • Witaj,
      jako że zależy nam na świadczeniu usług dobrej jakości, czy mógłbyś proszę podać nr ticketu tak, abyśmy mogli sprawdzić Twoje zgłoszenie?
      Pozdrawiamy, zespół Oktawave

  19. Trend w braży telco jest teraz odwrotny. Ucieka się od wspaniałych pomysłów na wirtualizacje technologii i produktów w chmurze dla klienta, które były rozpoczynane parę lat temu. Chmura to pułapka – nie tylko dla zoorientowanych klientów ale też dla firm, które zaczęły inwestować w nią. Krzyk nad tą technologią objawiający cud w tym obszarze, jakoś ostatnio cichnie. Ataki, awarie, kradzieże, straty danych, pieniędzy i klientów dały do myślenia niektórym. Techologia, któa miała miała być tańsza, wcale nią nie jest po podliczeniu wydatków i zwrotów. Jedynymi zainteresowanymi nadal są firmy, które wciskaja kit i chcą się nachapać oraz służby, bo jak wszystko wrzucamy do netu, to łatwiej to pozyskać w którymś tam miejscu. Zainteresowni wiedzą o czym piszę.

  20. Miało być “bez lania wody” a tutaj prawie zero konkretów dotyczących technologi poza bardzo wysoką, wręcz marketingowym, poziomem abstrakcji. Przyznam że na niebezpiecznik.pl liczyłem na więcej.

Odpowiadasz na komentarz Maciej

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: