|
|
Opublikowano 11.04.2018 17:33:18
|
|
|
|
Aby łatwiej było zrozumieć, o czym jest ten artykuł, zacznijmy od zmiany średniej dziennej statystyki Stack Overflow. Poniższe dane pochodzą ze statystyk na dzień 12 listopada 2013 roku:
- Load balancer zaakceptował 148 084 833 żądań HTTP
- Z tego 36 095 312 to ładunki stron
- Do wysyłania wykorzystywanych jest 833 992 982 627 bajtów (776 GB) ruchu HTTP
- Otrzymano łącznie 286 574 644 032 bajtów (267 GB) danych
- Łącznie przesłano 1 125 992 557 312 bajtów (1 048 GB) danych
- 334 572 103 zapytań SQL (w tym tylko z żądań HTTP)
- 412 865 051 próśb Redis
- 3 603 418 żądań Tag Engine
- Zapytania SQL potrzebowały 558 224 585 ms (155 godzin)
- Na żądania Redis potrzebowałem 99 346 916 ms (27 godzin)
- Spędziłem 132 384 059 ms (36 godzin) na żądaniu silnika tagowego
- Proces ASP.Net zajęł 2 728 177 045 ms (757 godzin)
Poniższe dane pokazują zmiany w statystykach na dzień 9 lutego 2016 r., więc możesz porównać:
- Żądania HTTP otrzymane przez load balancer: 209 420 973 (+61 336 090)
- 66 294 789 (+30 199 477), z czego ładowa się strona
- Przesłane dane HTTP: 1 240 266 346 053 (+406 273 363 426) bajtów (1,24 TB)
- Łączna ilość odebranych danych: 569 449 470 023 (+282 874 825 991) bajtów (569 GB)
- Łączna ilość przesłanych danych: 3 084 303 599 266 bajtów (+1 958 311 041 954) bajtów (3,08 TB)
- Zapytania SQL (tylko z żądań HTTP): 504 816 843 (+170 244 740)
- Odsłony pamięci podręcznej Redis: 5 831 683 114 (+5 418 818 063)
- Wyszukiwania elastyczne: 17 158 874 (nieśledzone w 2013 roku)
- Żądania silnika tagów: 3 661 134 (+57 716)
- Łączny czas potrzebny na wykonanie zapytań SQL: 607 073 066 (+48 848 481) ms (168 godzin)
- Czas dotarcia do pamięci podręcznej Redis: 10 396 073 (-88 950 843) ms (2,8 godziny)
- Czas zużyty na żądania silnika tagów: 147 018 571 (+14 634 512) ms (40,8 godzin)
- Czas zużyty na przetwarzanie ASP.Net: 1 609 944 301 (-1 118 232 744) ms (447 godzin)
- 22,71 (-5,29) ms 49 180 275 stron wydania średni czas renderowania (z czego 19,12 ms jest zużywane w ASP.Net)
- 11,80 (-53,2) ms 6 370 076 pierwszych stron średni czas renderowania (z czego 8,81 ms zużywa się w ASP.Net)
Możesz się zastanawiać, dlaczego ASP.Net przetwarza o 61 milionów więcej żądań dziennie, a jednocześnie skraca czas przetwarzania o 757 godzin (w porównaniu z 2013 rokiem). Jest to głównie zasługa modernizacji naszych serwerów na początku 2015 roku oraz wielu prac nad optymalizacją wydajności w aplikacji. Nie zapominaj: wydajność wciąż jest atutem sprzedaży. Jeśli bardziej interesują Cię szczegóły sprzętowe, nie martw się, szczegóły dotyczące serwerów używanych do obsługi tych stron podam w formie dodatku w następnym artykule (zaktualizuję ten link, gdy nadejdzie czas).
Co więc się zmieniło w ciągu ostatnich dwóch lat? Niewiele, tylko wymiana serwerów i sprzętu sieciowego. Oto przegląd serwerów, na których obecnie działasz swoją stronę (zwróć uwagę, jak się zmieniły od 2013 roku)
- 4 serwery Microsoft SQL Server (z czego 2 korzystają z nowego sprzętu)
- 11 serwerów internetowych IIS (nowy sprzęt)
- 2 serwery Redis (nowy sprzęt)
- 3 serwery Tag Engine (z których 2 korzystają z nowego sprzętu)
- 3 serwery Elasticsearch (takie same jak powyżej)
- 4 serwery HAProxy load balancing (2 dodane, aby wspierać CloudFlare)
- 2 urządzenia sieciowe (Nexus 5596 rdzeń + 2232TM Fabric Extender, wszystkie urządzenia zaktualizowane do 10Gbps przepustowości)
- 2 x zapora Fortinet 800C (zastępuje ASA Cisco 5525-X)
- 2 routery Cisco ASR-1001 (zastępują routery Cisco 3945)
- 2 routery Cisco ASR-1001-x (NOWOŚĆ!) ）
Czego potrzebujemy, aby Stack Overflow działał? Niewiele się zmieniło od 2013 roku, ale dzięki optymalizacjom i nowemu sprzętowi wspomnianemu powyżej, teraz potrzebujemy tylko jednego serwera WWW. Już nieświadomie testowaliśmy tę sytuację i wielokrotnie odniosło sukces. Proszę zauważyć: właśnie powiedziałem, że to działa, nie powiedziałem, że to dobry pomysł. Ale za każdym razem, gdy to się dzieje, jest to całkiem interesujące.
Teraz, gdy mamy już podstawowe dane dotyczące pomysłów na skalowanie serwerów, zobaczmy, jak stworzyliśmy te fajne strony internetowe. Niewiele systemów istnieje całkowicie niezależnie (i nasze nie są wyjątkiem), a bez holistycznego spojrzenia integrującego te części znaczenie planowania architektonicznego jest znacznie ograniczone. Naszym celem jest zrozumienie ogólnej sytuacji. W przyszłości pojawi się wiele artykułów głęboko zagłębiających się w każdą z tych dziedzin. Ten artykuł to jedynie podsumowanie struktury logicznej kluczowego sprzętu, a kolejny artykuł zawiera szczegółowe informacje o tych urządzeniach.
Jeśli chcesz zobaczyć, jak wygląda ten sprzęt dzisiaj, oto kilka zdjęć, które zrobiłem szafce A (szafa B jest dokładnie taka sama jak ona) podczas aktualizacji serwera w lutym 2015 roku:
Teraz przejdźmy do układu architektonicznego architektury. Poniżej znajduje się podsumowanie logicznej architektury głównych istniejących systemów:
Podstawowe zasady
Oto kilka powszechnych zasad, których nie trzeba wprowadzać kolejno:
- Wszystko ma redundantne kopie zapasowe.
- Wszystkie serwery i urządzenia sieciowe mają co najmniej dwa połączenia o przepustowości 10Gbps.
- Wszystkie serwery mają dwa źródła zasilania, które dostarczają zasilanie przez dwa zestawy jednostek UPS, dwa generatory za nimi oraz dwa przewody napięcia sieciowego.
- Wszystkie serwery mają redundantną kopię zapasową zlokalizowaną w szafach A i szafach B.
- Wszystkie serwery i usługi mają podwójnie redundantne kopie zapasowe w osobnym centrum danych (w Kolorado), chociaż głównie zajmuję się Nowym Jorkiem.
- Wszystko ma redundantne kopie zapasowe.
Internet
Najpierw musisz znaleźć naszą stronę internetową, która jest czymś DNS. Wyszukiwanie stron internetowych jest szybkie, więc teraz przekazujemy je CloudFlare, ponieważ mają serwery DNS w każdym zakątku świata. Aktualizujemy rekordy DNS za pomocą API, które odpowiadają za "zarządzanie" DNS. Jednak w naszych złowrogich umysłach wciąż mamy własne serwery DNS z powodu głęboko zakorzenionych problemów z zaufaniem. Gdy apokalipsa jest apokaliptyczna – może z powodu problemów z GPL, Punyon lub buforowaniem – a ludzie nadal chcą programować, by odwrócić ich uwagę, przełączamy się na własne serwery DNS.
Gdy Twoja przeglądarka znajdzie nasze miejsce ukrycia, ruch HTTP od naszych czterech dostawców internetu (Level 3, Zayo, Cogent i Lightower w Nowym Jorku) trafia do jednego z naszych czterech zaawansowanych routerów. Używamy protokołu Border Gateway (BGP, bardzo standardowego protokołu) do przesyłania ruchu peer-to-peer od dostawców sieci, aby go kontrolować i zapewnić najefektywniejszy sposób dostępu do naszych usług. Routery ASR-1001 i ASR-1001-X dzielą się na dwie grupy, z których każda powinna korzystać z trybu aktywnego/aktywnego do obsługi ruchu od obu dostawców sieci – tutaj występują redundantne kopie zapasowe. Chociaż wszystkie mają taką samą fizyczną przepustowość 10Gbps, ruch z zewnątrz jest nadal niezależny od ruchu zewnętrznego VLAN-u i jest połączony z równoważeniem obciążenia osobno. Po przejściu ruchu przez router trafisz do load balancera.
Myślę, że czas wspomnieć, że mamy MPLS z przepustowością 10Gbps między dwoma centrami danych, choć nie jest to bezpośrednio związane z usługami stron internetowych. Korzystamy z tej technologii do przeprowadzania replikacji poza siedzibą oraz szybkiego odzyskiwania danych, aby radzić sobie w określonych sytuacjach awaryjnych. "Ale Nick, tu nie ma żadnej powtarzalności!" Cóż, z technicznego punktu widzenia masz rację (w pozytywnym sensie), to naprawdę jeden punkt awarii na tym poziomie. Ale chwileczkę! Przez dostawcę sieci mamy także dwie dodatkowe trasy awaryjnego OSPF (MPLS to pierwszy wybór, a to są druga i trzecia opcja ze względów kosztowych). Każdy z wcześniej wymienionych zestawów urządzeń zostanie odpowiednio połączony z centrum danych w Kolorado, aby zrównoważyć ruch sieciowy w przypadku awarii. Oczywiście mogliśmy połączyć te dwa zestawy urządzeń, tak by powstały cztery zestawy ścieżek, ale zapomnijmy o tym, przejdźmy dalej.
Równoważenie obciążenia (HAProxy)
Load balancing jest implementowany w HAProxy 1.5.15, działającym na CentOS 7 (nasza ulubiona wersja Linuksa). I dodaj bezpieczny protokół transmisji TLS (SSL) na HAProxy. Obserwujemy także HAProxy 1.7, który od razu zapewni wsparcie dla protokołu HTTP/2.
W przeciwieństwie do innych serwerów z podwójnymi połączeniami sieciowymi LACP 10Gbps, każdy load balancer ma dwa połączenia 10Gbps: jedno dla sieci zewnętrznej, drugie dla DMZ. Serwery te mają 64GB lub więcej pamięci, aby efektywniej obsługiwać warstwę protokołu SSL. Gdy możemy buforować i ponownie używać więcej sesji TLS w pamięci, zużywamy mniej zasobów obliczeniowych podczas łączenia się z tym samym klientem. Dzięki temu możemy przywracać sesje szybciej i taniej. Pamięć jest tak tania, że wybór jest łatwy.
Samo rozważenie obciążenia jest łatwe do skonfigurowania. Słuchamy różnych stron internetowych na różnych adresach IP (głównie ze względów zarządzania certyfikatami i DNS), a następnie kierujemy ruch do różnych backendów (głównie na podstawie nagłówków hostów). Jedyne, co robimy, to ograniczenie szybkości i pobieranie części informacji z nagłówków (z warstwy webowej), aby zalogować się do komunikatów systemowych HAProxy, dzięki czemu możemy rejestrować metryki wydajności dla każdego żądania. Wspomnimy o tym szczegółowo później.
Warstwa sieciowa (IIS 8.5, ASP.Net MVC 5.2.3 oraz .Net 4.6.1)
Load balancing rozdziela ruch między 9 serwerów głównych (01-09) oraz 2 serwery deweloperskie (10-11, nasze środowisko testowe). Główny serwer działa na Stack Overflow, Careers i wszystkich stronach Stack Exchange, podczas gdy meta.stackoverflow.com i meta.stackexchange.com działają na dwóch innych serwerach. Główna aplikacja Q&A jest wielodzierżawczą, co oznacza, że jedna aplikacja obsługuje wszystkie żądania ze strony Q&A. Innymi słowy, możemy uruchomić całą aplikację Q&A na jednej puli aplikacji na jednym serwerze. Inne aplikacje, takie jak Careers, API v2, Mobile API itd., są niezależne. Oto, co widzisz w IIS dla serwerów master i dev:
Oto rozkład warstwy sieciowej Stack Overflow, jak widać w Opserver (naszym wewnętrznym panelu monitorującym):
A oto zużycie zasobów przez te serwery WWW:
W kolejnym artykule opowiem więcej o tym, dlaczego dostarczamy tak dużo zasobów, skupiając się na rolling build, swobodzie i redundancji.
Warstwa usługowa (IIS, ASP.Net MVC 5.2.3, . NET 4.6.1 i HTTP. SYS)
Obok warstwy webowej znajduje się warstwa usługowa. Działają też na IIS 2012 w systemie Windows 8.5R2. Ta warstwa uruchamia niektóre wewnętrzne usługi wspierające warstwę webową oraz inne wewnętrzne systemy środowiska produkcyjnego. Dwie główne usługi to: "Stack Server", który uruchamia silnik tagów i opiera się na http.sys (nie IIS); Providence API (oparte na IIS). Ciekawostka: musiałem korelować oba procesy, aby połączyć się z różnymi gniazdami, ponieważ Stack Server bardzo często korzystał z pamięci podręcznej L2 i L3 podczas odświeżania listy problemów co dwie minuty.
Maszyny obsługujące te usługi są kluczowe dla silnika tagów i API backend, więc muszą być redundantne, ale nie 9x redundantne. Na przykład ładujemy wszystkie artykuły i ich tagi z bazy danych co n minut (obecnie 2 minuty), co nie jest mało. Nie chcemy powtarzać tej operacji ładowania 9 razy na warstwie webowej, 3 razy to dla nas wystarczająco bezpieczne. Używamy także różnych konfiguracji sprzętowych dla tych serwerów, aby lepiej optymalizować parametry obliczeniowe i ładowania danych w silniku tagów oraz zadaniach indeksu elastycznego (również działających na tej warstwie). Sam "silnik tagów" to stosunkowo złożony temat, który zostanie omówiony w osobnym artykule. Podstawowa zasada jest taka, że gdy uchodzisz do adresu /questions/tagged/java, odwiedzasz silnik tagowania, aby uzyskać pytania odpowiadające temu samemu. Silnik obsługuje wszystkie dopasowania tagów z wyjątkiem /search, więc wszędzie, w tym nowa nawigacja, otrzymuje dane przez tę usługę.
Buforowanie i publikowanie/Subskrybowanie (Redis)
W niektórych miejscach używaliśmy Redisa i ma on solidną stabilność. Chociaż miesięcznie wykonuje się nawet 160 miliardów operacji, procesor na instancję nie przekracza 2%, co zwykle jest niższe:
Używamy Redisa do systemów buforowania na poziomie L1/L2. Poziom "L1" to pamięć podręczna HTTP, która działa na serwerze WWW lub podobnej aplikacji. Poziom "L2" służy do pobierania danych przez Redis po awarii pamięci podręcznej poprzedniego poziomu. Nasze dane są przechowywane w formacie Protobuf, zaimplementowanym przez protobuf-dot-net napisanym przez Marca Gravela. Dla klienta Redis użyliśmy biblioteki StackExchange.Redis, która jest otwartoźródłową biblioteką stworzoną wewnętrznie. Jeśli serwer WWW nie trafi zarówno do pamięci podręcznej L1, jak i L2, pobiera dane ze swoich źródeł danych (zapytania bazowe danych, wywołania API itp.) i zapisuje wyniki w lokalnej pamięci podręcznej oraz Redis. Następny serwer może być nieobecny w pamięci podręcznej L1 podczas pobierania tych samych danych, ale pobiera dane w L2/Redis, eliminując potrzebę zapytań do bazy danych lub wywołań API.
Prowadzimy też wiele stron pytań i odpowiedzi, z których każda ma własną pamięć podręczną L1/L2: klucz jako prefiks w pamięci podręcznej L1 oraz identyfikator bazy danych w pamięci podręcznej L2/Redis. Temat ten omówimy w kolejnych artykułach.
Oprócz dwóch głównych serwerów Redis (jednego master i jednego slave) obsługujących wszystkie instancje site, skonfigurowaliśmy także instancję do uczenia maszynowego (głównie ze względów pamięci) na dwóch innych dedykowanych serwerach slave. Ta grupa serwerów służy do świadczenia usług takich jak rekomendowanie pytań na stronie głównej oraz lepsze dopasowanie zadań. Ta platforma nazywa się Providence, a Kevin Montrose o niej pisał.
Główny serwer Redis ma 256GB RAM (około 90GB zużyte), a serwer Providence ma 384GB pamięci (około 125GB wykorzystane).
Redis służy nie tylko do buforowania, ale posiada także mechanizm publikowania i subskrypcji, gdzie jeden serwer może opublikować wiadomość, a inni subskrybenci mogą ją otrzymywać (w tym Redis od klientów na serwerze). Używamy tego mechanizmu do czyszczenia pamięci podręcznej L1 na innych usługach, aby utrzymać spójność pamięci podręcznej na serwerze WWW. Ale ma też inne ważne zastosowanie: gniazda webowe.
Websockets (NetGain)
Używamy websockets, aby przesyłać użytkownikom aktualizacje w czasie rzeczywistym, takie jak powiadomienia na górnym pasku, głosy, nowe nawigacje, nowe odpowiedzi, komentarze i inne.
Sam serwer gniazda działa na warstwie sieciowej, korzystając z natywnych gniazd. To bardzo mała aplikacja oparta na naszej otwartoźródłowej implementacji biblioteki: StackExchange.NetGain. W szczytowych momentach mieliśmy około 500 000 jednoczesnych połączeń websocket, czyli dużo przeglądarek. Ciekawostka: niektóre z tych przeglądarek są otwarte od ponad 18 miesięcy i musisz znaleźć kogoś, kto sprawdzi, czy ci deweloperzy nadal żyją. Poniższy wykres pokazuje wzorzec współbieżności websocket w tym tygodniu:
Dlaczego używać gniazd websocketów? Na naszą skalę jest to znacznie bardziej efektywne niż sondaże. Dzięki temu możemy po prostu przesyłać więcej danych przy mniejszych zasobach i działać bardziej w czasie rzeczywistym dla użytkowników. To podejście nie jest jednak pozbawione problemów: tymczasowe porty, wyczerpane uchwyty plików w load balancerach to bardzo interesujące problemy, o których porozmawiamy później.
Wyszukiwanie (Elasticsearch)
Spoiler: Nie ma tu zbyt wielu powodów do ekscytowania. Warstwa webowa korzysta z Elasticsearch 1.4 i implementuje ultralekkiego, wysokowydajnego klienta StackExchange.Elastic. W przeciwieństwie do większości rzeczy, nie planujemy udostępniać tej części jako open source, ponieważ udostępnia bardzo mały podzbiór API, których musimy używać. Jestem pewien, że upublicznienie tego przeważy nad stratą i tylko zdezorientuje deweloperów. W tych miejscach używamy elastic:/search, aby obliczać powiązane pytania i udzielać sugestii podczas zadawania pytań.
Każdy klaster Elastic (po jednym dla każdego centrum danych) zawiera 3 węzły, z których każdy ma własny indeks. Strona Careers zawiera także dodatkowe indeksy. Nieco mniej standardową częścią naszej konfiguracji w elastycznych kręgach jest to, że nasz klaster 3 serwerów jest nieco mocniejszy niż zwykła konfiguracja: każdy serwer korzysta z pamięci SSD, 192GB pamięci, podwójnej sieci o przepustowości 10Gbps.
Ta sama domena aplikacji Stack Server (tak, zostaliśmy tu przemyślani przez .Net Core) gości też silnik tagów, który również korzysta z Elasticsearch do ciągłego indeksowania. Tutaj używamy małego triku, na przykład używając ROWVERSION w SQL Server (źródło danych), aby porównać go z dokumentem "last place" w Elastic. Ponieważ jest rzekomo sekwencyjny, łatwo jest nam przeszukiwać i indeksować treści, jeśli zostanie zmodyfikowana po ostatniej wizycie.
Głównym powodem, dla którego używamy Elasticsearch zamiast technologii takich jak wyszukiwanie tekstowe SQL, jest jego skalowalność i opłacalność. SQL jest stosunkowo drogi pod względem procesorów, podczas gdy Elastic jest znacznie tańszy i ostatnio wprowadza wiele nowych funkcji. Dlaczego nie użyć Solr? Musimy przeszukiwać sieć (z wieloma indeksami jednocześnie), a Solr nie wspiera tego scenariusza w momencie naszych decyzji. Powodem, dla którego jeszcze nie użyliśmy wersji 2.x, jest to, że typy w 2.x bardzo się zmieniły, co oznacza, że musimy wszystko ponownie indeksować, jeśli chcemy aktualizować. Po prostu nie mam wystarczająco dużo czasu, żeby zaplanować zmiany wymagań i migracje.
Baza danych (SQL Server)
Używamy SQL Server jako jednego źródła prawdy. Wszystkie dane w Elastic i Redis pochodzą z SQL Server. Mamy dwa klastry SQL Server i jesteśmy skonfigurowani z grupami dostępności AlwaysOn. Każdy klaster ma główny serwer w Nowym Jorku (który przejmuje prawie całe obciążenie) oraz serwer repliki, a także serwer replikowy w Kolorado (nasze centrum danych do odzyskiwania po awarii). Wszystkie operacje kopiowania są asynchroniczne.
Pierwszy klaster to zestaw serwerów Dell R720xd, każdy z 384GB pamięci, dyskiem PCIe SSD o pojemności 4TB oraz dwoma 12-rdzeniowymi procesorami. Zawiera Stack Overflow, Sites (to zła nazwa, wyjaśnię to później), PRIZM oraz bazę danych Mobile.
Drugi klaster to zestaw serwerów Dell R730xd, każdy z 768GB pamięci, dyskiem PCIe SSD o pojemności 6TB oraz dwoma 8-rdzeniowymi procesorami. Ten klaster zawiera wszystkie inne bazy danych, w tym Careers, Open ID, Chat, logi wyjątków oraz inne strony pytań i odpowiedzi (np. Super User, Server Fault itp.).
Na warstwie bazy danych chcemy utrzymać wykorzystanie CPU na bardzo niskim poziomie, choć w praktyce zużycie procesora będzie nieco wyższe, gdy pojawiają się planowane problemy z buforowaniem (które obecnie rozwiązujemy). Obecnie NY-SQL02 i 04 są głównymi serwerami, a 01 i 03 to serwery repliki, i właśnie dziś je zrestartowaliśmy z powodu aktualizacji SSD. Oto jak spisywali się w ciągu ostatnich 24 godzin:
Nasze użycie SQL jest bardzo proste. Proste znaczy szybko. Chociaż niektóre instrukcje zapytań mogą być wypaczone, nasza interakcja z SQL odbywa się w dość natywny sposób. Mamy trochę starszego Linq2Sql, ale wszystkie nasze nowe rozwiązania korzystają z Dapper, naszego otwartoźródłowego frameworka micro-ORM wykorzystującego POCO. Wyjaśnię to inaczej: Stack Overflow ma tylko jedną procedurę przechowywaną w swojej bazie danych, a ja zamierzam zablokować tę ostatnią procedurę przechowywaną i zastąpić ją kodem.
Biblioteka
No cóż, zmieńmy zdanie, oto rzeczy, które mogą pomóc Ci bardziej bezpośrednio. Wspominałem już o niektórych z nich, ale podam listę wielu otwartych bibliotek .Net, które utrzymujemy i z których korzystają wszyscy. Udostępniamy je jako open source, ponieważ nie mają w sobie podstawowej wartości biznesowej, ale mogą pomagać deweloperom na całym świecie. Mam nadzieję, że teraz będziesz mógł z nich korzystać:
- Dapper (.Net Core) – Wysokowydajny framework mikro-ORM dla ADO.Net
- StackExchange.Redis – Wysokowydajny klient Redis
- MiniProfiler – lekki profiler, którego używamy na każdej stronie (obsługuje także Ruby, Go i Node)
- Wyjątkowe – Do logowania błędów w SQL, JSON, MySQL itd
- Jil – Wysokowydajna serializacja JSON i deserializator
- Sigil – .Net CIL Generation Helper (używany, gdy C# nie jest wystarczająco szybkie)
- NetGain – Wysokowydajny serwer websocket
- Opserver – Panel monitorujący, który bezpośrednio ankietuje większość systemów i może pobierać informacje z Oriona, Bosuna lub WMI
- Bosun – System monitoringu w tle, napisany w Go
|
Poprzedni:Enum Enum sprawdza, czy wartość jest zawarta w enumNastępny:Jak szybko znaleźć MB
|
