Witam czytelników Habr. Tym artykułem rozpoczynamy serię, która będzie opowiadać o opracowanym przez nas hiperkonwergentnym systemie AERODISK vAIR. Początkowo chcieliśmy opowiedzieć wszystko o wszystkim w pierwszym artykule, ale system jest dość skomplikowany, więc słonia zjemy po kawałku.
Zacznijmy opowieść od historii powstania systemu, zagłębimy się w system plików ARDFS, na którym opiera się vAIR, a także porozmawiajmy trochę o pozycjonowaniu tego rozwiązania na rynku rosyjskim.
W przyszłych artykułach omówimy bardziej szczegółowo różne komponenty architektury (klaster, hypervisor, moduł równoważenia obciążenia, system monitorowania itp.), proces konfiguracji, poruszymy kwestie licencyjne, osobno pokażemy testy zderzeniowe i oczywiście napiszemy o testach obciążenia i rozmiar. Społecznościowej wersji vAIR poświęcimy także osobny artykuł.
Czy Aerodisk to opowieść o systemach pamięci masowej? Albo dlaczego w ogóle zaczęliśmy stosować hiperkonwergencję?
Początkowo pomysł stworzenia własnej hiperkonwergencji przyszedł nam do głowy gdzieś około 2010 roku. Nie było wówczas na rynku Aerodiska ani podobnych rozwiązań (komercyjne pudełkowe systemy hiperkonwergentne). Nasze zadanie było następujące: z zestawu serwerów z dyskami lokalnymi, połączonych interkonektem poprzez protokół Ethernet, należało stworzyć rozbudowaną pamięć masową i uruchomić tam maszyny wirtualne oraz sieć oprogramowania. Wszystko to trzeba było wdrożyć bez systemów pamięci masowej (ponieważ po prostu nie było pieniędzy na systemy pamięci masowej i ich sprzęt, a nie wymyśliliśmy jeszcze własnych systemów pamięci masowej).
Wypróbowaliśmy wiele rozwiązań open source i ostatecznie rozwiązaliśmy ten problem, ale rozwiązanie było bardzo złożone i trudne do powtórzenia. Poza tym to rozwiązanie znalazło się w kategorii „Czy to działa? Nie dotykaj! Dlatego po rozwiązaniu tego problemu nie rozwijaliśmy dalej pomysłu przekształcenia wyniku naszej pracy w pełnoprawny produkt.
Po tym incydencie odeszliśmy od tego pomysłu, ale nadal mieliśmy poczucie, że ten problem jest w pełni do rozwiązania, a korzyści z takiego rozwiązania są więcej niż oczywiste. Następnie wypuszczone produkty HCI zagranicznych firm tylko potwierdziły to uczucie.
Dlatego w połowie 2016 roku powróciliśmy do tego zadania w ramach tworzenia pełnoprawnego produktu. Nie mieliśmy wtedy jeszcze żadnych relacji z inwestorami, więc stanowisko deweloperskie musieliśmy kupić za własne, niezbyt duże pieniądze. Po zebraniu używanych serwerów i przełączników w Avito zabraliśmy się do pracy.
Głównym początkowym zadaniem było stworzenie własnego, choć prostego, ale własnego systemu plików, który mógłby automatycznie i równomiernie dystrybuować dane w postaci wirtualnych bloków na n-tej liczbie węzłów klastra, połączonych interkonektem przez Ethernet. Jednocześnie system FS powinien dobrze i łatwo skalować się oraz być niezależny od sąsiednich systemów, tj. zostać wyobcowane z vAIR w formie „tylko magazynu”.
Pierwsza koncepcja vAIR
Celowo porzuciliśmy stosowanie gotowych rozwiązań open source do organizacji magazynów naciągniętych (ceph, gluster, połysk i tym podobne) na rzecz własnego rozwoju, ponieważ mieliśmy już z nimi duże doświadczenie projektowe. Oczywiście same te rozwiązania są znakomite i przed pracą nad Aerodiskiem realizowaliśmy z nimi niejeden projekt integracyjny. Ale czym innym jest wykonanie konkretnego zadania dla jednego klienta, przeszkolenie personelu i być może wykupienie wsparcia dużego dostawcy, a czym innym stworzenie produktu łatwo replikowalnego, który będzie służył do różnych zadań, które my, jako sprzedawca, może nawet o sobie wiemy, że tego nie zrobimy. Z tego drugiego powodu istniejące produkty open source nie były dla nas odpowiednie, dlatego postanowiliśmy sami stworzyć rozproszony system plików.
Dwa lata później kilku programistów (którzy połączyli pracę nad vAIR z pracą nad klasycznym systemem przechowywania Engine) osiągnęło pewien wynik.
Do 2018 roku napisaliśmy prosty system plików i uzupełniliśmy go o niezbędny sprzęt. System połączył dyski fizyczne (lokalne) z różnych serwerów w jedną płaską pulę za pośrednictwem wewnętrznego interkonektu i „pociął” je na bloki wirtualne, następnie z bloków wirtualnych utworzono urządzenia blokowe o różnym stopniu odporności na uszkodzenia, na których utworzono wirtualne i wykonane przy użyciu samochodów hypervisorów KVM.
Nie zawracaliśmy sobie zbytnio głowy nazwą systemu plików i zwięźle nazwaliśmy go ARDFS (zgadnij, co to oznacza))
Prototyp ten wyglądał dobrze (oczywiście nie wizualnie, nie było jeszcze projektu wizualnego) i wykazał dobre wyniki pod względem wydajności i skalowania. Po pierwszym realnym efekcie uruchomiliśmy ten projekt, organizując pełnoprawne środowisko deweloperskie i osobny zespół zajmujący się wyłącznie vAIR.
Właśnie do tego czasu dojrzała ogólna architektura rozwiązania, która nie uległa jeszcze większym zmianom.
Zanurzanie się w systemie plików ARDFS
ARDFS stanowi podstawę vAIR, która zapewnia rozproszone, odporne na awarie przechowywanie danych w całym klastrze. Jedną z (ale nie jedyną) charakterystyczną cechą ARDFS jest to, że nie wykorzystuje on żadnych dodatkowych serwerów dedykowanych do metadanych i zarządzania. Pierwotnie miało to na celu uproszczenie konfiguracji rozwiązania i zapewnienie jego niezawodności.
Struktura przechowywania
We wszystkich węzłach klastra ARDFS organizuje pulę logiczną z całej dostępnej przestrzeni dyskowej. Ważne jest, aby zrozumieć, że pula nie jest jeszcze danymi ani sformatowaną przestrzenią, ale po prostu znacznikami, tj. Po dodaniu do klastra wszystkie węzły z zainstalowanym vAIR są automatycznie dodawane do współdzielonej puli ARDFS, a zasoby dyskowe stają się automatycznie udostępniane w całym klastrze (i dostępne do przyszłego przechowywania danych). Takie podejście pozwala na dodawanie i usuwanie węzłów na bieżąco, bez poważnego wpływu na już działający system. Te. system można bardzo łatwo skalować „w cegiełkach”, w razie potrzeby dodając lub usuwając węzły w klastrze.
Dyski wirtualne (obiekty przechowywania maszyn wirtualnych) są dodawane do puli ARDFS i są zbudowane z wirtualnych bloków o rozmiarze 4 megabajtów. Dyski wirtualne bezpośrednio przechowują dane. Schemat odporności na błędy jest również ustawiany na poziomie dysku wirtualnego.
Jak można się już domyślić, w celu zapewnienia odporności podsystemu dyskowego na awarie nie używamy koncepcji RAID (nadmiarowa tablica niezależnych dysków), ale używamy RAIN (nadmiarowa tablica niezależnych węzłów). Te. Odporność na awarie jest mierzona, automatyzowana i zarządzana w oparciu o węzły, a nie dyski. Dyski są oczywiście również obiektem pamięci masowej, one, jak wszystko inne, są monitorowane, można na nich wykonywać wszystkie standardowe operacje, w tym montaż lokalnego sprzętowego RAID, ale klaster działa konkretnie na węzłach.
W sytuacji, gdy naprawdę potrzebujesz RAID (na przykład scenariusz, który obsługuje wiele awarii na małych klastrach), nic nie stoi na przeszkodzie, aby skorzystać z lokalnych kontrolerów RAID i zbudować na to rozciągniętą pamięć masową i architekturę RAIN. Ten scenariusz jest całkiem aktualny i jest przez nas wspierany, dlatego porozmawiamy o nim w artykule o typowych scenariuszach wykorzystania vAIR.
Schematy tolerancji błędów przechowywania
W vAIR mogą istnieć dwa schematy odporności na błędy dla dysków wirtualnych:
1) Współczynnik replikacji lub po prostu replikacja – ta metoda tolerancji błędów jest prosta jak kij i lina. Replikacja synchroniczna jest wykonywana pomiędzy węzłami ze współczynnikiem 2 (odpowiednio 2 kopie na klaster) lub 3 (odpowiednio 3 kopie). RF-2 pozwala dyskowi wirtualnemu wytrzymać awarię jednego węzła w klastrze, ale „zjada” połowę użytecznego woluminu, a RF-3 wytrzyma awarię 2 węzłów w klastrze, ale rezerwuje 2/3 objętość użyteczna dla jego potrzeb. Schemat ten jest bardzo podobny do RAID-1, czyli dysk wirtualny skonfigurowany w RF-2 jest odporny na awarię dowolnego węzła w klastrze. W takim przypadku wszystko będzie dobrze z danymi i nawet operacje we/wy nie zostaną zatrzymane. Kiedy uszkodzony węzeł powróci do działania, rozpocznie się automatyczne odzyskiwanie/synchronizacja danych.
Poniżej znajdują się przykłady rozkładu danych RF-2 i RF-3 w trybie normalnym i w sytuacji awarii.
Dysponujemy maszyną wirtualną o pojemności 8MB unikalnych (użytecznych) danych, która działa na 4 węzłach vAIR. Oczywiste jest, że w rzeczywistości jest mało prawdopodobne, że będzie tak mały wolumen, ale dla schematu odzwierciedlającego logikę działania ARDFS ten przykład jest najbardziej zrozumiały. AB to wirtualne bloki o wielkości 4MB zawierające unikalne dane maszyny wirtualnej. RF-2 tworzy dwie kopie tych bloków, odpowiednio A1+A2 i B1+B2. Bloki te są „ułożone” pomiędzy węzłami, unikając przecięcia tych samych danych w tym samym węźle, co oznacza, że kopia A1 nie będzie zlokalizowana w tym samym węźle, co kopia A2. To samo z B1 i B2.
W przypadku awarii jednego z węzłów (na przykład węzeł nr 3, który zawiera kopię B1), kopia ta zostaje automatycznie aktywowana w węźle, w którym nie ma kopii jej kopii (czyli kopii B2).
W ten sposób dysk wirtualny (i odpowiednio maszyna wirtualna) może z łatwością przetrwać awarię jednego węzła w schemacie RF-2.
Schemat replikacji, choć prosty i niezawodny, cierpi na ten sam problem co RAID1 – za mało miejsca do wykorzystania.
2) Kodowanie kasujące lub kodowanie kasujące (znane również jako „kodowanie nadmiarowe”, „kodowanie kasujące” lub „kod redundancyjny”) istnieje w celu rozwiązania powyższego problemu. EC to schemat nadmiarowości zapewniający wysoką dostępność danych przy niższym nakładzie miejsca na dysku w porównaniu z replikacją. Zasada działania tego mechanizmu jest podobna do RAID 5, 6, 6P.
Podczas kodowania proces EC dzieli blok wirtualny (domyślnie 4MB) na kilka mniejszych „porcji danych” w zależności od schematu EC (na przykład schemat 2+1 dzieli każdy blok 4MB na 2 porcje po 2MB). Następnie proces ten generuje „fragmenty parzystości” dla „fragmentów danych”, które nie są większe niż jedna z wcześniej podzielonych części. Podczas dekodowania EC generuje brakujące fragmenty, odczytując „przetrwałe” dane w całym klastrze.
Przykładowo dysk wirtualny o schemacie 2+1 EC, zaimplementowany na 4 węzłach klastra, z łatwością wytrzyma awarię jednego węzła w klastrze w taki sam sposób jak RF-2. W tym przypadku koszty ogólne będą niższe, w szczególności współczynnik wydajności użytecznej dla RF-2 wyniesie 2, a dla EC 2+1 będzie to 1,5.
Mówiąc prościej, istota jest taka, że wirtualny blok dzieli się na 2-8 (dlaczego od 2 do 8, patrz niżej) „kawałków” i dla tych kawałków obliczane są „kawałki” o parzystości o podobnej objętości.
W rezultacie dane i parzystość są równomiernie rozłożone we wszystkich węzłach klastra. Jednocześnie, podobnie jak w przypadku replikacji, ARDFS automatycznie rozdziela dane pomiędzy węzłami w taki sposób, aby zapobiec przechowywaniu identycznych danych (kopii danych i ich parzystości) w tym samym węźle, aby wyeliminować ryzyko utraty danych na skutek na fakt, że dane i ich parzystość nagle znajdą się w jednym węźle magazynowania, który ulegnie awarii.
Poniżej znajduje się przykład z tą samą maszyną wirtualną 8 MB i 4 węzłami, ale ze schematem EC 2+1.
Bloki A i B są podzielone na dwie części po 2 MB każda (dwa, bo 2+1), czyli A1+A2 i B1+B2. W przeciwieństwie do repliki, A1 nie jest kopią A2, jest to wirtualny blok A, podzielony na dwie części, tak samo jak blok B. W sumie otrzymujemy dwa zestawy po 4MB, z których każdy zawiera dwie sztuki po dwa MB. Następnie dla każdego z tych zestawów obliczana jest parzystość o objętości nie większej niż jedna sztuka (tj. 2 MB), otrzymujemy dodatkowo + 2 sztuki parzystości (AP i BP). W sumie mamy 4×2 dane + 2×2 parzystość.
Następnie elementy są „układane” pomiędzy węzłami, tak aby dane nie przecinały się z ich parzystością. Te. A1 i A2 nie będą w tym samym węźle co AP.
W przypadku awarii jednego węzła (na przykład także trzeciego) uszkodzony blok B1 zostanie automatycznie przywrócony z parzystości BP zapisanej w węźle nr 2 i zostanie aktywowany w węźle, w którym znajduje się brak parytetu B, tj. kawałek BP. W tym przykładzie jest to węzeł nr 1
Jestem pewien, że czytelnik ma pytanie:
„Wszystko, co opisałeś, zostało już dawno wdrożone zarówno przez konkurencję, jak i w rozwiązaniach open source. Jaka jest różnica między Twoim wdrożeniem EC w ARDFS?”
A potem pojawią się ciekawe funkcje ARDFS.
Usuń kod z naciskiem na elastyczność
Początkowo zapewniliśmy dość elastyczny schemat EC X+Y, gdzie X jest równe liczbie od 2 do 8, a Y jest równe liczbie od 1 do 8, ale zawsze mniejsze lub równe X. Ten schemat jest zapewniony dla elastyczności. Zwiększenie liczby fragmentów danych (X), na które podzielony jest blok wirtualny, pozwala na zmniejszenie kosztów ogólnych, czyli zwiększenie powierzchni użytkowej.
Zwiększenie liczby fragmentów parzystości (Y) zwiększa niezawodność dysku wirtualnego. Im większa wartość Y, tym więcej węzłów w klastrze może ulec awarii. Oczywiście zwiększenie wolumenu parzystości zmniejsza ilość użytecznej pojemności, ale jest to cena, jaką trzeba zapłacić za niezawodność.
Zależność wydajności od obwodów EC jest niemal bezpośrednia: im więcej „elementów”, tym niższa wydajność; tutaj oczywiście potrzebne jest zrównoważone podejście.
Takie podejście pozwala administratorom konfigurować rozciągniętą pamięć masową z maksymalną elastycznością. W ramach puli ARDFS można stosować dowolne schematy odporności na błędy i ich kombinacje, co naszym zdaniem również jest bardzo przydatne.
Poniżej znajduje się tabela porównująca kilka (nie wszystkie możliwe) schematów RF i EC.
Z tabeli wynika, że nawet najbardziej „frottowa” kombinacja EC 8+7, pozwalająca na utratę aż 7 węzłów w klastrze jednocześnie, „zjada” mniej przestrzeni użytkowej (1,875 vs 2) niż standardowa replikacja i chroni 7 razy lepiej , co czyni ten mechanizm zabezpieczający, choć bardziej złożony, znacznie atrakcyjniejszym w sytuacjach, gdzie konieczne jest zapewnienie maksymalnej niezawodności w warunkach ograniczonej przestrzeni dyskowej. Jednocześnie musisz zrozumieć, że każdy „plus” do X lub Y będzie dodatkowym obciążeniem wydajnościowym, dlatego w trójkącie pomiędzy niezawodnością, oszczędnością i wydajnością musisz wybierać bardzo ostrożnie. Z tego powodu poświęcimy osobny artykuł kasowaniu rozmiaru kodowania.
Niezawodność i autonomia systemu plików
ARDFS działa lokalnie na wszystkich węzłach klastra i synchronizuje je własnymi środkami poprzez dedykowane interfejsy Ethernet. Co ważne, ARDFS niezależnie synchronizuje nie tylko dane, ale także metadane związane z przechowywaniem. Pracując nad ARDFS, badaliśmy jednocześnie wiele istniejących rozwiązań i odkryliśmy, że wiele z nich synchronizuje meta systemu plików za pomocą zewnętrznego rozproszonego systemu DBMS, którego również używamy do synchronizacji, ale tylko konfiguracji, a nie metadanych FS (o tym i innych powiązanych podsystemach w następnym artykule).
Synchronizacja metadanych FS za pomocą zewnętrznego DBMS-u jest oczywiście rozwiązaniem działającym, ale wtedy spójność danych przechowywanych na ARDFS zależałaby od zewnętrznego DBMS-u i jego zachowania (a jest to, szczerze mówiąc, kapryśna dama), co w nasza opinia jest zła. Dlaczego? Jeśli metadane FS ulegną uszkodzeniu, same dane FS również można pożegnać, dlatego zdecydowaliśmy się obrać bardziej złożoną, ale niezawodną ścieżkę.
Podsystem synchronizacji metadanych dla ARDFS wykonaliśmy sami i działa on całkowicie niezależnie od sąsiednich podsystemów. Te. żaden inny podsystem nie może uszkodzić danych ARDFS. Naszym zdaniem jest to najbardziej niezawodny i poprawny sposób, ale czas pokaże, czy rzeczywiście tak jest. Ponadto podejście to ma dodatkową zaletę. ARDFS można używać niezależnie od vAIR, podobnie jak magazyn naciągnięty, który z pewnością wykorzystamy w przyszłych produktach.
W rezultacie, opracowując ARDFS, otrzymaliśmy elastyczny i niezawodny system plików, który daje wybór, czy można zaoszczędzić na pojemności, zrezygnować z wydajności, czy też stworzyć wyjątkowo niezawodną pamięć masową za rozsądną cenę, ale zmniejszając wymagania dotyczące wydajności.
W połączeniu z prostą polityką licencjonowania i elastycznym modelem dostarczania (patrząc w przyszłość, vAIR jest licencjonowany przez węzeł i dostarczany jako oprogramowanie lub jako pakiet oprogramowania), pozwala to na bardzo precyzyjne dostosowanie rozwiązania do szerokiej gamy wymagań klientów i następnie łatwo utrzymać tę równowagę.
Komu potrzebny ten cud?
Z jednej strony można powiedzieć, że na rynku są już gracze, którzy mają poważne rozwiązania w zakresie hiperkonwergencji i właściwie w tym kierunku zmierzamy. Wydaje się, że to stwierdzenie jest prawdziwe, ALE...
Z drugiej strony, kiedy wychodzimy na pola i komunikujemy się z klientami, my i nasi partnerzy widzimy, że wcale tak nie jest. Zadań przed hiperkonwergencją jest wiele, w niektórych miejscach ludzie po prostu nie wiedzieli, że takie rozwiązania istnieją, w innych wydawało się to drogie, w jeszcze innych nieudane testy alternatywnych rozwiązań, a w innych w ogóle zabraniają zakupu ze względu na sankcje. Ogólnie pole okazało się niezaorane, więc poszliśmy uprawiać dziewiczą ziemię))).
Kiedy system przechowywania jest lepszy niż GCS?
Współpracując z rynkiem, często spotykamy się z pytaniami, kiedy z systemami pamięci masowej lepiej zastosować klasyczny schemat, a kiedy hiperkonwergentny? Wiele firm produkujących GCS (zwłaszcza te, które nie mają w swoim portfolio systemów pamięci masowej) twierdzi: „Systemy pamięci masowej stają się przestarzałe, tylko hiperkonwergentne!” To odważne stwierdzenie, ale nie do końca odzwierciedlające rzeczywistość.
Co prawda rynek pamięci masowych rzeczywiście zmierza w stronę hiperkonwergencji i podobnych rozwiązań, jednak zawsze jest „ale”.
Po pierwsze, centrów danych i infrastruktur IT budowanych w klasycznym schemacie z systemami pamięci masowych nie da się łatwo odbudować, dlatego modernizacja i uzupełnianie takich infrastruktur to wciąż dziedzictwo na 5-7 lat.
Po drugie, infrastruktura, która jest obecnie budowana w przeważającej części (czyli Federacji Rosyjskiej) jest budowana według klasycznego schematu z wykorzystaniem systemów magazynowania i to nie dlatego, że ludzie nie wiedzą o hiperkonwergencji, ale dlatego, że rynek hiperkonwergencji jest nowy, rozwiązania i standardy nie zostały jeszcze ustalone, informatycy nie są jeszcze przeszkoleni, mają niewielkie doświadczenie, ale centra danych muszą budować tu i teraz. I ten trend utrzyma się przez kolejne 3-5 lat (a potem kolejne dziedzictwo, patrz punkt 1).
Po trzecie, istnieje czysto techniczne ograniczenie w zakresie dodatkowych małych opóźnień wynoszących 2 milisekundy na zapis (oczywiście z wyłączeniem lokalnej pamięci podręcznej), które stanowią koszt rozproszonej pamięci masowej.
No cóż, nie zapominajmy o zastosowaniu dużych serwerów fizycznych, które uwielbiają pionowe skalowanie podsystemu dyskowego.
Istnieje wiele niezbędnych i popularnych zadań, w których systemy pamięci masowej zachowują się lepiej niż GCS. Tutaj oczywiście ci producenci, którzy nie mają w swoim portfolio systemów przechowywania, nie zgodzą się z nami, ale jesteśmy gotowi rozsądnie argumentować. Oczywiście my, jako twórcy obu produktów, na pewno porównamy systemy przechowywania i GCS w jednej z naszych przyszłych publikacji, gdzie wyraźnie pokażemy, który jest lepszy w jakich warunkach.
A gdzie rozwiązania hiperkonwergentne sprawdzą się lepiej niż systemy pamięci masowych?
Na podstawie powyższych punktów można wyciągnąć trzy oczywiste wnioski:
- Tam, gdzie dodatkowe 2 milisekundy opóźnienia przy nagrywaniu, które stale występują w każdym produkcie (teraz nie mówimy o syntetykach, na syntetykach można pokazać nanosekundy), są bezkrytyczne, odpowiednia jest hiperkonwergentność.
- Tam, gdzie obciążenie z dużych serwerów fizycznych można zamienić na wiele małych wirtualnych i rozłożyć pomiędzy węzłami, tam również hiperkonwergencja sprawdzi się dobrze.
- Tam, gdzie skalowanie poziome ma wyższy priorytet niż skalowanie w pionie, GCS również tam sobie poradzi.
Jakie są te rozwiązania?
- Wszystkie standardowe usługi infrastrukturalne (usługi katalogowe, poczta, EDMS, serwery plików, małe i średnie systemy ERP i BI itp.). Nazywamy to „ogólnym przetwarzaniem”.
- Infrastruktura dostawców usług chmurowych, gdzie konieczna jest szybka i ujednolicona rozbudowa w poziomie oraz łatwe „wycięcie” dużej liczby maszyn wirtualnych dla klientów.
- Infrastruktura wirtualnych pulpitów (VDI), w której działa wiele maszyn wirtualnych małych użytkowników, które po cichu „unoszą się” w ramach jednolitego klastra.
- Sieci oddziałowe, gdzie każdy oddział potrzebuje standardowej, odpornej na awarie, ale niedrogiej infrastruktury 15-20 maszyn wirtualnych.
- Wszelkie przetwarzanie rozproszone (na przykład usługi dużych zbiorów danych). Gdzie ładunek nie idzie „w głąb”, ale „wszerz”.
- Środowiska testowe, w których dopuszczalne są dodatkowe małe opóźnienia, ale są ograniczenia budżetowe, ponieważ są to testy.
W tej chwili właśnie do tych zadań stworzyliśmy AERODISK vAIR i to na nich się skupiamy (na razie z sukcesem). Być może wkrótce to się zmieni, bo... świat nie stoi w miejscu.
Więc…
Na tym kończy się pierwsza część obszernego cyklu artykułów, w kolejnym artykule porozmawiamy o architekturze rozwiązania i zastosowanych komponentach.
Czekamy na pytania, sugestie i konstruktywne spory.
Źródło: www.habr.com