Skalowalność w aplikacjach webowych stała się standardem. Pojedynczy serwer nie poradzi sobie z rosnącą ilością podłączonych do Internetu urządzeń. Skalowalność to charakterystyka systemu, która odpowiada na pytanie: czy jeśli zwiększy się ilość zasobów, to system będzie działał wydajniej? Nie wszystkie aplikacje, systemy oraz sieci są skalowalne i muszą być do tego celu specjalnie zaprojektowane. Rozwiązania w chmurze z definicji zapewniają przetwarzanie na dużą skalę. Platformy IoT także powinny oferować podobne rozwiązania. Platforma musi oferować stosowny poziom niezawodności nawet, gdy ilość podłączonych urządzeń wzrasta. Ilość urządzeń nie powinna wpływać na dostępność danych, a ich przetwarzanie, analiza i transformacja powinny być szybkie i efektywne. Platformy IoT stają się kluczowe w infrastrukturze, każde żądanie wymaga przygotowania odpowiedzi – od prostych zapytań o aktualne pomiary, aż do złożonych raportów, takich jak roczne MTBF (ang. mean time between failures).
IIoT (ang. Industrial Internet of Things) obsługuje setki tysięcy podłączonych urządzeń, ale także pozwala na grupowanie ich w linie oraz całe hale produkcyjne, a nawet fabryki. Podłączanie nowych linii produkcyjnych, czy też wymiana urządzeń powinna być łatwa i szybka. Skalowanie takich rozwiązań jest bardzo ważne także w kontekście zmniejszania zasobów. Wyłączanie hal produkcyjnych celem oszczędzania energii lub zmniejszenie podaży przy zredukowanym popycie, powinna być odzwierciedlona także w aplikacjach IoT – wyłączanie serwerów nie powinno powodować przestojów.
Środowiska klastrowe zwiększają wydajność poprzez dodawanie nowych serwerów. Jest to przykład skalowalności poziomej (ang. horizontal scaling). Zasoby klastra wzrastają wraz z dodawaniem nowych węzłów. Innym przykładem jest skalowalność wertykalna (ang. vertical scaling), gdzie zasoby dodawane są do samego serwera. To swoisty dylemat, czy lepsza jest ilość, czy wielkość.
Skalowanie wertykalne
Skalowanie w pionie (inaczej w górę lub w dół) oznacza dodawanie lub usuwanie zasobów jednego serwera. Wspomniane zasoby to rdzenie procesora, pamięć RAM oraz przestrzeń dyskowa. Ten przykład skalowania zwiększa przepustowość (ang. throughput), czyli ilość operacji w danej jednostce czasu. Największym mankamentem tego typu skalowania jest potrzeba wyłączenia serwera celem wymiany sprzętu. Oprócz tego, takie skalowanie stosuje się w środowiskach monolitycznych (w odróżnieniu do klastrów, dostępny jest tylko jeden serwer), uszkodzenie sprzętu powoduje nieplanowane przestoje. Jakkolwiek uzasadnione, skalowanie w górę ma swój limit – nie można zwiększać zasobów w nieskończoność.
Zalety:
- Kod aplikacji pozostaje bez zmian. Ta sama aplikacja będzie działa na serwerze ze zwiększonymi zasobami
- Pojedynczy serwer jest łatwiejszy w zarządzaniu, a wzrost wydajności widać zaraz po uruchomieniu serwera
- Często tańsze w kontekście zarządzania i administracji
Wady:
- Przestoje spowodowane wymianą sprzętu
- Wysokiej klasy sprzęt może być drogi
- Górny limit w szczególności w przypadku użycia prekonfigurowanych instancji w chmurze
Skalowanie horyzontalne
Skalowanie w poziomie (inaczej na zewnątrz i do wewnątrz) oznacza dodawanie nowych węzłów do klastra. Teoretyczny brak limitu, łatwość dodawania nowych węzłów oraz zarządzania nimi sprawia, że ten typ skalowania jest znacznie bardziej przystępny i popularny. Warto zaznaczyć brak przestojów, ponieważ nowy serwer nie wpływa w żaden sposób na te obecnie działające. Wymiana uszkodzonych serwerów jest w zasadzie niewidoczna dla użytkowników końcowych. Dodatkowo, skalowanie do wewnątrz (przy braku zapotrzebowania na zasoby) także odbywa się w sposób płynny.
Świetnym aspektem tego typu skalowania jest wysoka dostępność (ang. High Availability), która leży u podstaw takiego rozwiązania – skalowanie w poziomie może odbyć się tylko w środowiskach klastrowych. Każdy węzeł posiada tę samą konfigurację oraz aplikację, dzięki czemu może przejąć ruch sieciowy w przypadku, gdy inny serwer uległ awarii.
Zalety:
- Serwery są tańsze ze względu na mniejszą ilość zasobów
- Łatwy do zbudowania scenariusz awaryjny, ze względu na bezproblemową wymianę węzłów
- Skalowanie jest niewidoczne dla użytkowników i nie wprowadza przestojów – zarówno jeśli chodzi o dodawania, jak i odejmowanie węzłów
- Teoretyczny brak limitu w skalowaniu na zewnątrz
Wady:
- Bardziej skomplikowany kod aplikacji wprowadza więcej potencjalnych błędów
- Mniej przejrzyste kwestie licencjonowania, ze względu na zwiększoną ilość węzłów
- Bardziej złożone kwestie zarządzania i administracji
Klaster Aktywny-Aktywny w ThingWorx 9
Możliwości skalowania zostały wprowadzone w wersji 9 oprogramowania ThingWorx. Wysoka dostępność oraz klaster Aktywny-Pasywny były wspierane wcześniej, ale nowa wersja pozwala na łatwe skalowanie na zewnątrz i do wewnątrz. Klaster pracuje w trybie Aktywny-Aktywny. Oznacza to, że wszystkie węzły klastra obsługują żądania oraz biorą aktywny udział w działaniu całej platformy. Ten tryb pozwala na zwiększenie zdolności procesowych, co przekłada się na możliwość podłączenia większej ilości urządzeń. Platforma IoT powinna być elastyczna, dać się wpasować w każdy przypadek użycia, powinna także być w stanie obsłużyć wzrost aktywności użytkowników lub urządzeń, optymalizować koszty i minimalizować przestoje.
Podejście Aktywny-Pasywny zakłada, że tylko jeden serwer odpowiada na żądania oraz jest podłączony do zewnętrznych systemów. Równolegle, uruchomiony jest węzeł pasywny (lub więcej), który jest także regularnie aktualizowany danymi i ustawieniami. Często określa się to instancją lustrzaną, nie obsługuje ona żądań, ale jest w gotowości, aby przejąć rolę aktywnego węzła gdy obecny ulegnie awarii.
Nowe podejście zapewnia nawet większą dostępność systemu, dzięki włączeniu wszystkich serwerów do aktywnej pracy nad obsługą urządzeń, połączeń i żądań. Przetwarzanie danych odbywa się w sposób równoległy, a klaster jako całość jest w stanie działać wydajniej niż pojedyncza instancja. Ponadto, klaster działający w trybie Aktywny-Aktywny obsługuje skalowanie w poziomie, dając możliwość dodawania nowych węzłów. Tym samym uzyskuje większą moc obliczeniową i przepustowość, ale także możliwość wyłączania węzłów, gdy taka moc nie jest potrzebna. Przetwarzanie danych na dużą skale w rozwiązaniach IIoT jest prostsze niż kiedykolwiek.
Co składa się na klaster Aktywny-Aktywny
Synchronizacja danych pomiędzy węzłami w ThingWorx 9 odbywa się przy pomocy Apache Ignite. Jest to potężne narzędzie ułatwiające zarządzanie danymi klastra, ale także wprowadzające znaczny stopień elastyczności. Apache Ignite może działać w trzech trybach:
- Pamięć podręczna w pamięci RAM, wysokiej wydajności i niskiej latencji cache Klucz-Wartość (wspiera zapytania ANSI SQL)
- Siatka danych w pamięci RAM, zaawansowana siatka danych pozwalająca przyspieszyć odczyt danych z bazy RDBMS nawet stukrotnie
- Baza danych w pamięci RAM, wielowarstwowa i skalowalna w poziomie i w pionie baza danych
Wymiana danych pomiędzy węzłami w ThingWorx musi być szybka i niezawodna. Dzięki zastosowaniu load balancera, węzeł, który otrzyma dane z czujników musi zapisać je w pamięci trwałej (np. InfluxDB). Celem zapewnienia integralności danych, taki pomiar musi być dostępny także dla innych węzłów. Użycie pamięci podręcznej (ang. cache) staje się idealnym rozwiązaniem. Dane są synchronizowane z bazą danych przy użyciu dodatkowej warstwy w pamięci RAM.
Oprogramowanie Apache Ignite wspiera skalowanie horyzontalne – nie wymaga to dodatkowych ustawień, a nowe węzły są dodawane do klastra w sposób automatyczny. Odbywa się to dzięki tzw. Service Discovery, który wykorzystując rejstr węzłów pozwala na komunikację między nimi. Instancje Apache Ignite w ThingWorx 9 wykorzystują Zookeeper Discovery, które pozwala skalować do setek a nawet tysięcy węzłów. Mniejsze klastry mogą skorzystać z szybkiego TCP/IP Discovery, które jest domyślne w Apache Ignite.
Podsumowując, klaster Aktywny-Aktywny w ThingWorx 9 składa się z następujących narzędzi:
- Apache Zookeeper do zarządzania klastrem oraz prowadzenia rejestru węzłów
- Apache Ignite do synchronizacji i zapewnienia integralności danych oraz zwiększenia wydajności zapytań do bazy danych
- Wiele instancji serwera ThingWorx, które działają jednocześnie
Na diagramie widać, że wszystkie instancje ThingWorx są aktywne i zarządzają połączeniami. Load balancer wie, ile żądań obsłużył każdy serwer, a także do którego węzła przekazać nowe żądania na podstawie algorytmu balansowania. Całym klastrem zarządza Apache Zookeeper, także użyty jako rejestr (service discovery) dla instancji Apache Ignite. Pamięć podręczna (ang. cache) jest podzielona (domyślnie, co da się skonfigurować) pomiędzy wszystkie węzły. Ciekawa jest także możliwość wykorzystania Apache Ignite jako siatki obliczeniowej (ang. compute grid). Pozwala to podzielić zadania pomiędzy wszystkie węzły, przyspieszając przetwarzanie i umożliwiając analizowanie większej ilości danych jednocześnie. Nowe możliwości obliczania wskaźników KPI i pokazywania ich na żywo na dashboardach to tylko kwestia zrównoleglenia obecnych algorytmów.
Podsumowanie
Oba typy skalowania mają zarówno wady, jak i zalety. Oczywiście finalny wybór należy dostosować do konkretnego zapotrzebowania, jednak w większości przypadków skalowanie horyzontalne sprawdzi się lepiej. Platforma ThingWorx zyskała długo wyczekiwaną opcję obsługi klastra w trybie Aktywny-Aktywny. Jest to niewątpliwie duży krok naprzód. Wiele serwerów obsługujących tę samą aplikację w klastrze zyskuje nowe możliwości przetwarzania, analizy i transformacji danych. Rozwiązania IIoT obsługujące setki tysięcy urządzeń mogą być teraz wdrażane przy lepszym szacowaniu kosztów i czasu, z jeszcze większą dostępnością i niezawodnością. Pozwala to zaoszczędzić pieniądze, przy jednoczesnej redukcji przestojów.
ThingWorx w wersji 9 stał się platformą skali enterprise. Dzięki umożliwieniu skalowania na zewnątrz i do wewnątrz platforma pozwala lepiej szacować koszty utrzymania. Pozostaje też niezawodna, nawet w przypadku nieoczekiwanego (lub oczekiwanego) wzrostu ilości żądań klientów lub urządzeń podłączanych w okresie świątecznym lub w trakcie wydarzeń sportowych. Skalowanie poziome pomaga firmom rozwijać biznes poprzez rozbudowywanie linii i hal produkcyjnych, a nawet łączenie całych fabryk. Wysoka wydajność zmniejsza koszty eliminując nieoczekiwane przestoje. Nowe szanse na rozwój biznesu stają otworem. Firmy mogą skupić się na rozbudowywaniu obecnych i planowaniu nowych rozwiązań zamiast na utrzymaniu. Większa moc obliczeniowa pozwala wdrażać bardziej wyrafinowane modele uczenia maszynowego, a to z kolei stwarza zupełnie nowe możliwości, pozwalając firmom być o krok przed konkurencją.
Jeśli potrzebujesz pomocy we wdrażaniu nowych lub rozbudowywaniu istniejących rozwiązań w oparciu o ThingWorx skontaktuj się z nami.
