Nowoczesne centra danych posiadają setki aktywnych urządzeń objętych różnymi rodzajami monitoringu. Ale nawet doskonały inżynier z doskonałym monitoringiem w ręku będzie w stanie odpowiednio zareagować na awarię sieci w ciągu zaledwie kilku minut. W referacie na konferencji Next Hop 2020 przedstawiłem metodologię projektowania sieci data center, która ma unikalną cechę – data center leczy się samoczynnie w milisekundy. Mówiąc dokładniej, inżynier spokojnie rozwiązuje problem, podczas gdy służby po prostu go nie zauważają.
Dla wielu inżynierów sieciowych sieć centrum danych zaczyna się oczywiście od ToR, z przełącznikiem w szafie. ToR ma zwykle dwa rodzaje linków. Maluchy idą na serwery, inne - jest ich N razy więcej - idą w kierunku grzbietów pierwszego poziomu, czyli do jego uplinków. Łącza nadrzędne są zwykle uważane za równe, a ruch między łączami nadrzędnymi jest zrównoważony w oparciu o 5-krokowy skrót, który obejmuje proto, src_ip, dst_ip, src_port, dst_port. Tutaj nie ma niespodzianek.
Następnie, jak wygląda architektura samolotów? Kolce pierwszego poziomu nie są ze sobą połączone, ale są połączone za pomocą superspinów. Litera X będzie odpowiedzialna za superspiny, to prawie jak cross-connect.
I jasne jest, że z drugiej strony tori są połączone ze wszystkimi kolcami pierwszego poziomu. Co jest ważne na tym obrazku? Jeśli mamy interakcję wewnątrz szafy, to oczywiście interakcja przechodzi przez ToR. Jeśli interakcja zachodzi wewnątrz modułu, to interakcja przechodzi przez kolce pierwszego poziomu. Jeśli interakcja jest intermodułowa - jak tutaj, ToR 1 i ToR 2 - wtedy interakcja przejdzie przez kolce zarówno pierwszego, jak i drugiego poziomu.
Teoretycznie taka architektura jest łatwo skalowalna. Jeśli dysponujemy przepustowością portów, rezerwą miejsca w data center i pre-ułożonym światłowodem, to zawsze można zwiększyć liczbę płaszczyzn, zwiększając tym samym ogólną przepustowość systemu. Na papierze jest to bardzo łatwe do zrobienia. Tak by było w prawdziwym życiu. Ale dzisiejsza opowieść nie jest o tym.
Chcę wyciągnąć właściwe wnioski. Wewnątrz data center mamy wiele ścieżek. Są warunkowo niezależne. Jedna droga do centrum danych jest możliwa tylko wewnątrz ToR. Wewnątrz modułu mamy tyle ścieżek, ile jest płaszczyzn. Liczba ścieżek między modułami jest równa iloczynowi liczby płaszczyzn i liczby superspinów w każdej płaszczyźnie. Aby było jaśniej, aby poczuć skalę, podam liczby, które są ważne dla jednego z centrów danych Yandex.
Jest osiem samolotów, każdy samolot ma 32 superspiny. W rezultacie okazuje się, że wewnątrz modułu jest osiem ścieżek, a przy interakcji między modułami jest ich już 256.
Oznacza to, że jeśli opracowujemy książkę kucharską, próbując dowiedzieć się, jak zbudować odporne na błędy centra danych, które same się naprawiają, to architektura planarna jest właściwym wyborem. Pozwala rozwiązać problem skalowania i teoretycznie jest to łatwe. Istnieje wiele niezależnych ścieżek. Pozostaje pytanie: jak taka architektura przetrwa awarie? Są różne awarie. I omówimy to teraz.
Niech jeden z naszych superspinów zachoruje. Tutaj powróciłem do architektury dwóch płaszczyzn. Będziemy trzymać się ich jako przykładu, ponieważ po prostu łatwiej będzie zobaczyć, co się tutaj dzieje przy mniejszej liczbie ruchomych części. Niech X11 zachoruje. Jak wpłynie to na usługi działające w centrach danych? Wiele zależy od tego, jak faktycznie wygląda awaria.
Jeśli awaria jest dobra, zostanie złapana na poziomie automatyzacji tego samego BFD, automatyzacja szczęśliwie stawia problematyczne złącza i izoluje problem, wtedy wszystko jest w porządku. Ścieżek mamy wiele, ruch jest błyskawicznie przekierowywany na trasy alternatywne, a służby niczego nie zauważą. To dobry scenariusz.
Zły scenariusz jest wtedy, gdy mamy ciągłe straty, a automatyzacja nie zauważa problemu. Aby zrozumieć, jak wpływa to na aplikację, będziemy musieli poświęcić trochę czasu na omówienie działania protokołu TCP.
Mam nadzieję, że nikogo nie zszokuję tą informacją: TCP to protokół uzgadniania. Oznacza to, że w najprostszym przypadku nadawca wysyła dwa pakiety i otrzymuje na nie zbiorcze potwierdzenie: „Otrzymałem dwa pakiety”.
Następnie wyśle jeszcze dwa pakiety i sytuacja się powtórzy. Z góry przepraszam za pewne uproszczenie. Ten scenariusz jest poprawny, jeśli okno (liczba pakietów w locie) wynosi dwa. Oczywiście nie musi tak być w ogólności. Ale rozmiar okna nie ma wpływu na kontekst przekazywania pakietów.
Co się stanie, jeśli zgubimy pakiet 3? W takim przypadku odbiorca otrzyma pakiety 1, 2 i 4. I jednoznacznie poinformuje nadawcę za pomocą opcji SACK: „Wiesz, trzy przyszły, ale środek przepadł”. Mówi „Ack 2, SACK 4”.
Nadawca w tym momencie bez problemu powtarza dokładnie ten pakiet, który został utracony.
Ale jeśli ostatni pakiet w oknie zostanie utracony, sytuacja będzie wyglądać zupełnie inaczej.
Odbiorca otrzymuje pierwsze trzy pakiety i przede wszystkim zaczyna czekać. Dzięki pewnym optymalizacjom w stosie TCP jądra Linuksa będzie czekać na sparowany pakiet, chyba że we flagach jest wyraźne wskazanie, że jest to ostatni pakiet lub coś w tym rodzaju. Będzie czekać, aż upłynie limit czasu opóźnionego potwierdzenia ACK, a następnie wyśle potwierdzenie dla pierwszych trzech pakietów. Ale teraz nadawca będzie czekał. Nie wie, czy czwarta paczka zaginęła, czy też wkrótce dotrze. Aby nie przeciążać sieci, będzie próbował czekać na wyraźne wskazanie, że pakiet został utracony lub upłynie limit czasu RTO.
Co to jest limit czasu RTO? Jest to maksimum z RTT obliczonego przez stos TCP i pewną stałą. Czym jest ta stała, omówimy teraz.
Ale ważne jest to, że jeśli znów będziemy mieli pecha i czwarty pakiet znów zostanie utracony, to RTO podwoi się. Oznacza to, że każda nieudana próba oznacza podwojenie limitu czasu.
Teraz zobaczmy, ile równa się ta podstawa. Domyślnie minimalny RTO wynosi 200 ms. Jest to minimalny RTO dla pakietów danych. Dla pakietów SYN jest inaczej, 1 sekunda. Jak widać, nawet pierwsza próba ponownego wysłania pakietów zajmie 100 razy dłużej niż RTT wewnątrz data center.
Wróćmy teraz do naszego scenariusza. Co się dzieje z serwisem? Usługa zaczyna gubić pakiety. Niech usługa początkowo będzie miała szczęście i zgubi coś w środku okna, wtedy otrzyma SACK, ponownie wyśle utracone pakiety.
Ale jeśli pech się powtórzy, mamy RTO. Co jest tutaj ważne? Tak, mamy wiele ścieżek w sieci. Ale ruch TCP jednego konkretnego połączenia TCP będzie nadal przechodził przez ten sam zepsuty stos. Utrata pakietów, pod warunkiem, że nasz magiczny X11 nie wyłączy się samoistnie, nie prowadzi do przepływu ruchu do obszarów, które nie są problematyczne. Próbujemy dostarczyć pakiet przez ten sam zepsuty stos. Prowadzi to do kaskadowej awarii: centrum danych to zestaw współpracujących ze sobą aplikacji, a niektóre połączenia TCP wszystkich tych aplikacji zaczynają się pogarszać - ponieważ superspin wpływa na wszystkie aplikacje znajdujące się w centrum danych. Jak w powiedzeniu: jeśli nie podkuwasz konia, koń utyka; koń utykał – meldunek nie został doręczony; wiadomość nie została dostarczona - przegrali wojnę. Tylko tutaj liczą się sekundy od momentu pojawienia się problemu do etapu degradacji, jaki zaczynają odczuwać usługi. Oznacza to, że użytkownicy mogą gdzieś czegoś nie otrzymać.
Istnieją dwa klasyczne rozwiązania, które wzajemnie się uzupełniają. Pierwszym z nich są usługi, które próbują położyć słomki i rozwiązać problem w następujący sposób: „Zmodyfikujmy coś w stosie TCP. I zróbmy limity czasu na poziomie aplikacji lub długotrwałe sesje TCP z wewnętrznymi kontrolami kondycji. Problem polega na tym, że takie rozwiązania: a) w ogóle się nie skalują; b) bardzo słabo przetestowany. Oznacza to, że nawet jeśli usługa przypadkowo skonfiguruje stos TCP, aby stał się lepszy, po pierwsze jest mało prawdopodobne, aby miało to zastosowanie do wszystkich aplikacji i wszystkich centrów danych, a po drugie, najprawdopodobniej nie zrozumie, co zostało zrobione poprawnie i co nie. To znaczy działa, ale działa słabo i nie skaluje się. A jeśli jest problem z siecią, kto jest winny? Oczywiście NOK. Co robi NOK?
Wiele służb uważa, że w NOC praca przebiega mniej więcej tak. Ale szczerze mówiąc, nie tylko.
NOC w klasycznym schemacie zajmuje się rozwojem wielu monitoringów. Są to zarówno monitorowanie czarnej skrzynki, jak i monitorowanie białej skrzynki. O przykładzie czarnej skrzynki-monitoringu kolców Alexander Klimenko o przeszłości Next Hop. Nawiasem mówiąc, ten monitoring działa. Ale nawet doskonały monitoring będzie miał opóźnienie czasowe. Zwykle jest to kilka minut. Po jego uruchomieniu dyżurujący inżynierowie potrzebują czasu, aby ponownie sprawdzić jego działanie, zlokalizować problem, a następnie ugasić problematyczny obszar. Oznacza to, że w najlepszym przypadku leczenie problemu zajmuje 5 minut, w najgorszym 20 minut, jeśli nie jest od razu oczywiste, gdzie występują straty. Oczywiste jest, że przez cały ten czas - 5 lub 20 minut - nasze usługi będą nadal boleć, co prawdopodobnie nie jest dobre.
Co chciałbyś otrzymać? Mamy tak wiele dróg. A problemy pojawiają się właśnie dlatego, że pechowe przepływy TCP nadal korzystają z tej samej trasy. Potrzebujemy czegoś, co pozwoli nam korzystać z wielu tras w ramach jednego połączenia TCP. Wydawałoby się, że mamy rozwiązanie. Istnieje TCP, który nazywa się tak - wielościeżkowy TCP, czyli TCP dla wielu ścieżek. To prawda, że \uXNUMXb\uXNUMXbzostał opracowany do zupełnie innego zadania - dla smartfonów, które mają kilka urządzeń sieciowych. Aby zmaksymalizować transfer lub zrobić tryb podstawowy/zapasowy, opracowano mechanizm, który w przejrzysty sposób tworzy kilka wątków (sesji) dla aplikacji i umożliwia przełączanie się między nimi w przypadku awarii. Lub, jak powiedziałem, zmaksymalizuj przepustowość.
Ale jest tu pewien niuans. Aby zrozumieć, co to jest, musimy przyjrzeć się, jak skonfigurowane są strumienie.
Wątki są ustawiane sekwencyjnie. Pierwszy strumień jest instalowany jako pierwszy. Kolejne przepływy są następnie ustawiane przy użyciu pliku cookie już uzgodnionego w ramach tego wątku. I tu jest problem.
Problem polega na tym, że jeśli pierwszy wątek nie zostanie zainstalowany, drugi i trzeci wątek nigdy się nie pojawią. Oznacza to, że wielościeżkowy protokół TCP nie rozwiązuje problemu utraty pakietu SYN w pierwszym strumieniu. A jeśli SYN zostanie utracony, wielościeżkowy TCP staje się normalnym TCP. W środowisku data center nie pomoże nam to więc rozwiązać problemu strat w fabryce i nauczyć się korzystać z wielu ścieżek w przypadku awarii.
Co może nam pomóc? Część z Was już odgadła po nazwie, że pole nagłówka etykiety przepływu IPv6 będzie ważnym polem w naszej dalszej historii. Rzeczywiście, jest to pole, które pojawia się w v6, nie ma go w v4, zajmuje 20 bitów, a jego użycie od dłuższego czasu budzi kontrowersje. To bardzo ciekawe - były spory, coś zostało poprawione w ramach RFC, a jednocześnie w jądrze Linuksa pojawiła się implementacja, która nigdy nie była nigdzie udokumentowana.
Sugeruję, żebyś dołączył do mnie w małym śledztwie. Rzućmy okiem na to, co działo się w jądrze Linuksa w ciągu ostatnich kilku lat.
rok 2014. Inżynier z dużej i renomowanej firmy dodaje do funkcjonalności jądra Linuksa zależność wartości etykiety przepływu od wartości skrótu gniazda. Co oni tutaj próbują naprawić? Jest to związane z dokumentem RFC 6438, w którym omówiono następujący problem. Wewnątrz centrum danych IPv4 jest często zamknięty w pakietach IPv6, ponieważ sama fabryka to IPv6, ale IPv4 musi być w jakiś sposób rozdany. Przez długi czas występowały problemy z przełącznikami, które nie potrafiły zajrzeć pod dwa nagłówki IP, aby dostać się do TCP lub UDP i znaleźć tam src_ports, dst_ports. Okazało się, że hash, jeśli spojrzeć na pierwsze dwa nagłówki IP, okazał się prawie naprawiony. Aby tego uniknąć, aby równoważenie tego zahermetyzowanego ruchu działało poprawnie, zaproponowano dodanie hasha z 5-krotkowego zahermetyzowanego pakietu do wartości pola flow label. W przybliżeniu to samo zrobiono dla innych schematów enkapsulacji, dla UDP, dla GRE, w tym ostatnim użyto pola klucza GRE. Tak czy inaczej, cele tutaj są jasne. I przynajmniej w tym momencie były przydatne.
W 2015 roku nowy patch pochodzi od tego samego szanowanego inżyniera. On jest bardzo interesujący. Mówi, co następuje - wylosujemy hash w przypadku negatywnego zdarzenia routingu. Co to jest zdarzenie routingu negatywnego? Jest to RTO, o którym mówiliśmy wcześniej, czyli utrata ogona okna jest zdarzeniem, które jest naprawdę negatywne. To prawda, że stosunkowo trudno zgadnąć, co to jest.
2016, kolejna szanowana firma, również duża. Analizuje ostatnie kule i sprawia, że hash, który wcześniej losowaliśmy, jest teraz zmieniany przy każdej retransmisji SYN i po każdym przekroczeniu limitu czasu RTO. I w tym liście, po raz pierwszy i ostatni, wybrzmiewa ostateczny cel - aby ruch w przypadku utraty lub przeciążenia kanałów miał możliwość miękkiego przekierowania, z wykorzystaniem wielu ścieżek. Oczywiście po tym było dużo publikacji, można je łatwo znaleźć.
Chociaż nie, nie można, bo nie ukazała się ani jedna publikacja na ten temat. Ale wiemy!
A jeśli nie do końca rozumiesz, co zostało zrobione, powiem ci teraz.
Co zostało zrobione, jaka funkcjonalność została dodana do jądra Linuksa? txhash zmienia się na losową wartość po każdym zdarzeniu RTO. To jest ten sam negatywny wynik routingu. Hash zależy od tego txhash, a etykieta przepływu zależy od skrótu skb. Jest tu kilka obliczeń funkcji, wszystkie szczegóły nie mogą być umieszczone na jednym slajdzie. Jeśli ktoś jest ciekawy, może przejrzeć kod jądra i sprawdzić.
Co jest tutaj ważne? Wartość pola etykiety przepływu zmienia się na liczbę losową po każdym RTO. Jak to wpływa na nasz pechowy strumień TCP?
W przypadku SACK nic się nie zmieniło, ponieważ próbujemy ponownie wysłać znany utracony pakiet. Jak na razie dobrze.
Ale w przypadku RTO, pod warunkiem, że dodaliśmy etykietę przepływu do funkcji skrótu w ToR, ruch może przebiegać inną trasą. A im więcej samolotów, tym większe prawdopodobieństwo znalezienia ścieżki, na którą nie ma wpływu awaria konkretnego urządzenia.
Pozostaje jeden problem - RTO. Oczywiście znajduje się inna trasa, ale poświęca się jej dużo czasu. 200ms to dużo. Drugi to generalnie dzikość. Wcześniej mówiłem o limitach czasu, które konfigurują usługi. Tak więc sekunda to limit czasu, który zwykle konfiguruje usługę na poziomie aplikacji, aw tym przypadku usługa będzie nawet względnie prawidłowa. Ponadto, powtarzam, prawdziwy RTT w nowoczesnym centrum danych wynosi około 1 milisekundy.
Co można zrobić z limitami czasu RTO? Limit czasu, który odpowiada za RTO w przypadku utraty pakietów danych, można stosunkowo łatwo skonfigurować z przestrzeni użytkownika: istnieje narzędzie IP, a jeden z jego parametrów zawiera ten sam rto_min. Biorąc pod uwagę, że oczywiście trzeba obracać RTO nie globalnie, ale dla danych prefiksów, taki mechanizm wygląda na całkiem sprawny.
To prawda, że \u1b\uXNUMXbz SYN_RTO wszystko jest nieco gorsze. Jest naturalnie przybity. Wartość jest ustalona w rdzeniu - XNUMX sekunda i to wszystko. Nie możesz się do niego dostać z przestrzeni użytkownika. Jest tylko jeden sposób.
eBPF przychodzi na ratunek. Mówiąc prościej, są to małe programy C. Można je wstawiać do haków w różnych miejscach wykonywania stosu jądra i stosu TCP, za pomocą których można zmienić bardzo dużą liczbę ustawień. Ogólnie rzecz biorąc, eBPF jest trendem długoterminowym. Zamiast wycinać dziesiątki nowych parametrów sysctl i rozszerzać narzędzie IP, ruch zmierza w kierunku eBPF i rozszerzania jego funkcjonalności. Dzięki eBPF możesz dynamicznie zmieniać kontrolę przeciążenia i różne inne ustawienia TCP.
Ale dla nas ważne jest, aby za jego pomocą można było przekręcić wartości SYN_RTO. I jest publicznie opublikowany przykład: . Co się tutaj robi? Przykład działa, ale sam w sobie jest bardzo szorstki. Przyjmuje się tutaj, że wewnątrz data center porównujemy pierwsze 44 bity, jeśli się zgadzają, to znajdujemy się wewnątrz DC. I w tym przypadku zmieniamy wartość limitu czasu SYN_RTO na 4ms. To samo zadanie można wykonać znacznie sprawniej. Ale ten prosty przykład pokazuje, co jest a) możliwe; b) stosunkowo łatwe.
Co już wiemy? To, że architektura planarna umożliwia skalowanie, okazuje się dla nas niezwykle przydatne, gdy włączymy etykietę przepływu na ToR i uzyskamy możliwość opływania problematycznych obszarów. Najlepszym sposobem na obniżenie wartości RTO i SYN-RTO jest użycie programów eBPF. Pozostaje pytanie: czy używanie etykiety przepływu do bilansowania jest bezpieczne? I tu jest pewien niuans.
Załóżmy, że masz usługę w sieci, która działa w anycast. Niestety, nie mam czasu, aby szczegółowo omówić anycast, ale jest to usługa rozproszona, w której różne serwery fizyczne są dostępne pod tym samym adresem IP. I tu pojawia się możliwy problem: zdarzenie RTO może wystąpić nie tylko podczas przejazdu przez fabrykę. Może to również wystąpić na poziomie bufora ToR: gdy wystąpi zdarzenie incast, może nawet wystąpić na hoście, gdy host coś rozleje. Gdy wystąpi zdarzenie RTO, które zmieni etykietę przepływu. W takim przypadku ruch może przejść do innej instancji anycast. Załóżmy, że jest to anycast stanowy, zawiera stan połączenia - może to być L3 Balancer lub inna usługa. Wtedy pojawia się problem, bo po RTO połączenie TCP dociera do serwera, który nic nie wie o tym połączeniu TCP. A jeśli nie mamy współdzielenia stanu między serwerami anycast, to taki ruch zostanie porzucony i połączenie TCP zostanie zerwane.
Co można tutaj zrobić? W kontrolowanym środowisku, w którym włączasz równoważenie etykiet przepływu, musisz ustalić wartość etykiety przepływu podczas uzyskiwania dostępu do serwerów anycast. Najłatwiej zrobić to za pomocą tego samego programu eBPF. Ale tutaj jest bardzo ważny punkt - co zrobić, jeśli nie obsługujesz sieci centrum danych, ale jesteś operatorem telekomunikacyjnym? To także twój problem: począwszy od niektórych wersji Juniper i Arista, domyślnie zawierają etykietę przepływu w funkcji skrótu - szczerze mówiąc, bez powodu nie rozumiem. Może to spowodować zerwanie połączeń TCP od użytkowników przechodzących przez Twoją sieć. Dlatego gorąco polecam sprawdzenie ustawień routera w tej lokalizacji.
Tak czy inaczej wydaje mi się, że jesteśmy gotowi przejść do eksperymentów.
Gdy włączyliśmy flow label na ToR, przygotowaliśmy eBPF agenta, który teraz żyje na hostach, postanowiliśmy nie czekać na kolejną wielką awarię, tylko przeprowadzić kontrolowane eksplozje. Wzięliśmy ToR, który ma cztery łącza nadrzędne, i dokonaliśmy zrzutów na jednym z nich. Narysowali regułę, powiedzieli - teraz tracisz wszystkie pakiety. Jak widać po lewej, mamy monitorowanie pakietów, które spadło do 75%, czyli 25% pakietów jest traconych. Po prawej stronie znajdują się wykresy usług znajdujących się za tym ZWZ. W rzeczywistości są to wykresy ruchu połączeń z serwerami wewnątrz szafy. Jak widać spadły jeszcze niżej. Dlaczego spadły - nie o 25%, ale w niektórych przypadkach 3-4 razy? Jeśli połączenie TCP jest pechowe, kontynuuje próbę dotarcia przez zepsuty interfejs. Sytuację pogarsza typowe zachowanie usługi wewnątrz DC — dla jednego żądania użytkownika generowanych jest N żądań do usług wewnętrznych, a odpowiedź trafia do użytkownika, albo gdy wszystkie źródła danych odpowiedzą, albo gdy przekroczony zostanie limit czasu o poziom aplikacji, który wymaga jeszcze skonfigurowania. To znaczy, wszystko jest bardzo, bardzo złe.
Teraz ten sam eksperyment, ale z włączoną etykietą przepływu. Jak widać po lewej, nasz monitoring partii spadł o te same 25%. Jest to całkowicie poprawne, ponieważ nie wie nic o retransmisjach, wysyła pakiety i po prostu liczy stosunek liczby pakietów dostarczonych i utraconych.
A po prawej harmonogram usług. Nie znajdziesz tutaj efektu problematycznego stawu. Ruch w tych samych milisekundach płynął z obszaru problemu do trzech pozostałych uplinków, na które problem nie miał wpływu. Mamy sieć, która sama się leczy.
To mój ostatni slajd, czas na podsumowanie. Mam nadzieję, że wiesz, jak zbudować samonaprawiającą się sieć centrum danych. Nie będziesz musiał przeglądać archiwum jądra Linuksa i szukać tam specjalnych łat, wiesz, że etykieta Flow rozwiązuje problem w tym przypadku, ale musisz ostrożnie podejść do tego mechanizmu. I jeszcze raz podkreślam, że jeśli jesteś przewoźnikiem, nie powinieneś używać etykiety przepływu jako funkcji haszującej, inaczej przerwiesz sesje swoich użytkowników.
Dla inżynierów sieciowych konieczna jest zmiana koncepcyjna: sieć nie zaczyna się od ToR, nie od urządzenia sieciowego, ale od hosta. Dość uderzającym przykładem jest to, jak używamy eBPF zarówno do zmiany RTO, jak i do ustalenia etykiety przepływu w kierunku usług anycast.
Mechanika etykiet przepływowych z pewnością nadaje się do innych zastosowań w kontrolowanym segmencie administracyjnym. Może to być ruch między centrami danych lub możesz wykorzystać taką mechanikę w specjalny sposób do kontrolowania ruchu wychodzącego. Ale o tym opowiem, mam nadzieję, następnym razem. Dziękuję bardzo za uwagę.
Źródło: www.habr.com