Współczesne serwisy internetowe odpowiadają na miliony zapytań użytkowników. Wszystkie one działają w środowiskach klastrowych. Obsługa wielu zapytań wymaga znacznych zasobów, takich jak czas procesora (CPU) oraz pamięć RAM. Każde połącznie do serwera generuje jego dodatkowe obciążenie. W takiej sytuacji jeden serwer wymagałby ogromnych ilości zasobów, a prawo Moor’a już się nie sprawdziło. Aby temu zaradzić potrzebujemy wielu serwerów, które obsługują zapytania użytkowników. Aplikacje webowe (w tym także IoT) używają protokołu HTTP(S), który działa na zasadzie: żądanie-odpowiedź. Gdy użytkownik otwiera stronę, lub wywołuje akcję, zostaje wysłane żądanie do serwera. Na każde żądanie użytkownika serwer musi przygotować odpowiedź. Każda odpowiedź musi zostać w odpowiedni sposób przeprocesowana, a to stanowi główne kryterium  estymacji ilości zasobów serwera – żądania mogą być różne, od danych statycznych jak style CSS lub obrazy, po skomplikowane jak pobieranie danych z bazy, filtrowanie lub wyliczanie pewnych współczynników.

Czas pomiędzy stworzeniem żądania a uzyskaniem odpowiedzi nazywamy latency. Oczywistym jest, że dążymy do jak najmniejszego latancy. Pierwszy problem, który może się pojawić to przepełnienie serwera żądaniami do takiego stopnia, że nie jest w stanie odpowiadać w akceptowalnym czasie (lub w ogóle). W celu utrzymania niskiego latancy wykorzystuje się środowiska klastrowe. Klastry pozwalają stosunkowo łatwo budować niezawodne, skalowalne oraz elastyczne serwisy. Oprócz tego możliwym jest uruchomienie High Availability (ang. wysoka dostępność) – pozwala to zapewnić ciągłość pracy aplikacji, nawet jeśli serwer jest niedostępny. Gartner obliczył, że średni koszt każdej minuty przestoju wynosi $5 600.

Na dłuższą metę klaster pozwala zaoszczędzić pieniądze poprzez zmniejszenie ilości i czasu przestojów. Próg wejścia jest nieco wyższy z powodu nadmiarowości sprzętu – każda część klastra to działający serwer, co znacznie ułatwia efektywne zarządzanie serwisami. Użytkownicy będą częściej wracać, jeśli aplikacje i serwisy są zawsze dostępne, szybkie i pozbawione błędów. Firmom dostarczającym serwisy pozwala to zmniejszyć nie tylko przestoje ale też czas i pracę inżynierów odpowiedzialnych za przywrócenie systemu.

High Availability

Jak działają klastry

Klaster to wiele serwerów, na których działa dokładnie ta sama aplikacja z dokładnie taką samą konfiguracją. Wszystkie serwery w klastrze pracują wspólnie, co przekłada się na wysoką dostępność, niezawodność i skalowalność. Każdy serwer może obsłużyć żądania, dzięki czemu cały system lepiej radzi sobie z obciążeniem. Z perspektywy użytkownika nic się nie zmienia – ciągle używa tego samego adresu URL lub IP w celu połączenia. Żądanie jest przekierowywane do odpowiedniego serwera na podstawie wybranego algorytmu równoważenia obciążenia. Istnieje wiele różnych algorytmów i wybór konkretnego zależy od wymagań i danego przypadku użycia.

Do najbardziej popularnych należą:

  • Roundrobin – serwery wybierane są turami, a obciążenie jest równomiernie rozłożone
  • Least connection (ang. najmniej połączeń) – serwer z najmniejszą liczbą połączeń obsługuje żądanie
  • Source (ang. źródło) – każdy użytkownik (ten sam adres IP) będzie przekierowywany do tego samego serwera, który został przydzielony przy pierwszym połączeniu.
  • Uri – użytkownicy używający tego samego adresu uri (niezależnie, czy jest to lewa, czy prawa strona znaku zapytania) będą kierowani do tego samego serwera
  • Hdr – podobny do Uri, ale używa nagłówków zapytania HTTP do wybory serwera

Bardzo popularne jest wybieranie serwera ze względu na geolokalizację – żądanie dostanie serwer, który jest najbliżej użytkownika (na podstawie lokalizacji danego adresu IP).

Podsumowując:

  • Wykorzystywany jest algorytm balansowania obciążenia – używany przez Load balancer
  • Load balancer przekierowuje połączenia do serwerów w klastrze, co gwarantuje nieprzerwane działanie serwisów oraz replikację sesji
  • Serwery obsługują konkretne żądania użytkowników

Wydaje się to koncepcyjnie proste, a zarazem bardzo skuteczne. Problem zaczyna się od strony implementacyjnej. Dlatego do budowania klastrów stosuje się wiele narzędzi pomagających nimi zarządzać.

Czym jest High Availability?

Skutki wyłączenia systemu mogą być katastrofalne. To nie tylko koszty poniesione przez przedsiębiorstwo, ponieważ nie może ono zarabiać na działającym systemie, ale także ogromny nakład pracy, aby postawić system  z powrotem na nogi. Istnieje wiele mniej lub bardziej spodziewanych przyczyn zaprzestania działania serwera, to może być awaria systemu, brak prądu, błąd aplikacji i wiele innych. Aby zapobiec nieoczekiwanym przestojom należy użyć środowisk klastrowych. Jeśli jeden z serwerów nie jest w stanie obsługiwać żądań, ruch może zostać przekierowany do innych serwerów, które nadal działają. Taki scenariusz nazywa się High availability. Bez znaczenia co stanie się z serwerem, zawsze dostępne są inne, które mogą przejąć obsługę żądań. Nadmiarowość pozwala klastrowi być zawsze dostępnym, nawet gdy pojawi się problem – mało prawdopodobnym jest, że wszystkie węzły klastra będą niedostępne.

Amazon zapewnia 99,999% (także nazywane „pięcioma dziewiątkami”) dostępności dla systemów reagowania kryzysowego. Dlaczego potrzebujemy aż trzech dziewiątek po przecinku? Czy 99% nie będzie wystarczające? Otóż nie, dostępność na poziomie 99% oznacza ~87 godzin przestojów w ciągu roku, czyli 14 minut na dzień! Dla systemów, które działając całą dobę to zdecydowanie z dużo.

Osiągnięcie High Availability (lub po prostu HA) jest zdecydowanie łatwiejsze przy użyciu odpowiednich narzędzi. Najważniejszy z nich jest wspomniany Load balancer. To przewodnik, który pokazuje każdemu żądaniu drogę do serwera gdzie zostanie rozpatrzone. Load balancer dokładnie wie, ile żądań przechodzi do klastra oraz ile z tych żądań każdy z serwerów obsłużył. Pozwala to równoważyć obciążenie na wszystkie dostępne serwery. Load balancer zna także kondycję wszystkich serwerów np. na podstawie długości obsługi podobnych żądań, wie które serwery są niedostępne i może przekierować użytkowników na wciąż działające serwery. To trochę tak, gdy mechanik oferuje samochód zastępczy na czas naprawy.

High Availability

High Availability w ThingWorx

High Availability w ThingWorx zostało zaprezentowane w wersji 8.0. Pozwala ono na stworzenie wielu instancji serwera ThingWorx i połączenia load balancera. Zawsze dostępny jest jeden tzw. Master serwer, który obsługuje żądania. Inne serwery pełnią funkcję pomocników, którzy czekają, aż serwer główny przestanie działać (z jakiejkolwiek przyczyny), aby wejść na scenę i dokończyć show. To podejście nazywa się Active-Passive. Klaster ma wiele węzłów, ale tylko jeden, główny, jest aktywny w danym momencie. Pomaga to w budowaniu High Availability, ale nie jest zbyt pomocne przy skalowaniu klastra. Dodawania nowych węzłów zwiększa dostępność systemu – trochę jak dodawanie dziewiątki po przecinku.

Współczesne aplikacje IoT opierają się na łączności. Niezwykle ważnym jest, aby serwer był dostępny, ponieważ w takich aplikacjach najważniejsze są dane. Urządzenia, które nieustannie zbierają dane nie zawsze są w stanie przechowywać je przez dłuższy czas, a jeszcze rzadziej mogą te dane przetwarzać w wartość. Aplikacje działające na platformie ThingWorx są krytyczne dla całej infrastruktury – jest to centralna baza danych, która bez przerwy analizuje dane i może do nich stosować modele uczenia maszynowego. Dzięki temu urządzenia końcowe mogę być kontrolowane na podstawie obecnego stanu (np. rozpoczynać nawadnianie roślin, gdy ziemia jest zbyt sucha) lub przewidywanych działań (np. optymalizacja farm wiatrowych na podstawie prognoz pogody). Przez niedostępność systemu ThingWorx, żadne z powyższych nie może się zadziać. Jest to główny powód, dla którego warto rozważyć klastry pracujące w trybie Active-Passive.

High Availability Overview

ThingWorx używa oprogramowania Apache Zookeeper do zarządzania klastrem. Zookeeper pozwala na:

  • Zarządzanie konfiguracją
  • Wybór lidera (głównego serwera)
  • Synchronizację
  • Usługę nazewnictwa – łatwe dodawanie nowych węzłów
  • Zarządzanie całym klastrem

Dzięki zastosowaniu oprogramowania Zookeeper, dodawanie nowych serwerów do klastra jest niesamowicie proste. Wszystko, co jest potrzebne, to nowy serwer, który wystarczy dołączyć do klastra. Bez ponownych uruchomień i przestojów. Wystarczy skonfigurować serwer offline, przetestować aplikację i przekazać do Zookeepar’a, że mamy nowy węzeł. Zookeeper automatycznie włączy serwer do klastra i zapewni, że konfiguracja jest taka sama na wszystkich serwerach. Zazwyczaj pod HA potrzebujemy jeden węzeł główny – wybierany przez Zookeeper’a podczas uruchamiania klastra oraz 2 lub więcej węzłów pomocniczych – zawsze gotowych, ale nie obsługujących żądań. Nadmiarowość serwerów zawsze należy skonfrontować z wymaganiami oraz konkretnymi przypadkami użycia.

diagram high availability

Na diagramie widać, że wszystkie połącznia trafiają do load balancera. Aplikacje klienckie oraz urządzenia nie łączą się do platformy bezpośrednio. To pozwala na przekierowywanie ruchu do aktualnie aktywnej instancji systemu ThingWorx. Gdy węzeł z powodu błędu zostaje wyłączony, load balancer automatycznie przekieruje ruch do innego węzła, który od tej pory będzie węzłem głównym.

Beyond High Availability

Celem poradzenia sobie ze wzmożonym ruchem lub wysokim obciążenie potrzebne jest inne podejście: klaster w trybie Active-Active. Taka opcja została dodana do wersji 9 platformy ThingWorx. Węzły, zamiast czekać, mogą aktywnie brać udział w obsłudze żądań. Klastry zapewniają nie tylko HA, ale także ułatwiają skalowanie horyzontalne. Taki typ skalowania pozwala na łatwiejsze dostarczenie nowych zasobów do klastra. Zamiast wymiany sprzętu w działającym serwerze, co oczywiście powoduje jego wyłączenie oraz przestój, dodawany jest nowy serwer, który jak wspomniano, może być przygotowany wcześniej i dodany do klastra. Planowanie zasobów produkcyjnych jest wyzwaniem, ale zdecydowanie łatwiejszym w środowiskach klastrowych.

Skalowalność aplikacji można mierzyć ilością żądań, która może być równocześnie obsłużona przez serwer. Punkt krytyczny znajduje się tam, gdzie aplikacja nie może efektywnie obsłużyć nowych żądań. Taki punkt często nazywa się limitem skalowalności. Warto wspomnieć, że zdecydowanie łatwiej jest dwukrotnie zwiększyć ilość żądań, dodając drugi serwer, niż zrobić to samo, zwiększając zasoby jednego serwera. Dzięki platformie ThingWorx 9 możliwe jest budowanie skalowalnych rozwiązań IoT, które mogą obsługiwać setki tysięcy urządzeń.

Jeśli potrzebujesz pomocy we wdrażaniu nowych lub rozbudowywaniu istniejących rozwiązań w oparciu o ThingWorx skontaktuj się z nami.

How useful was this post?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.

W przypadku naruszenia Regulaminu Twój wpis zostanie usunięty.

    _Wszystkie wpisy z tej kategorii

    7 sposobów jak widoczność danych zwiększa efektywność produkcji

    XXI wiek to czas kiedy dane odgrywają coraz większą rolę, a trend ten zauważalny jest również w branży produkcyjnej. Gromadzenie ich to jednak…
    Czytaj dalej

    5 kroków do zwiększenia efektywności energetycznej w firmie produkcyjnej

    Według Niemieckiego Federalnego Urzędu Statystycznego zużycie energii przez przemysł do produkcji towarów w latach 1995-2019 prawie się nie zmieniło. W 2019 roku wyniosło…
    Czytaj dalej

    5 sposobów na redukcję kosztów energii w przemyśle

    Koszt energii elektrycznej – bardzo często pomijany bądź akceptowany taki, jaki jest z uwagi na to, że jest integralną częścią produkcji. W czasach…
    Czytaj dalej

    Energy Advisor dla produkcji - oszczędność energii dla przemysłu

    Rachunki za zużycie energii od wielu lat są przedmiotem zainteresowania praktycznie wszystkich dziedzin przemysłu, a obecna sytuacja na świecie jest czynnikiem zwiększającym zapotrzebowanie…
    Czytaj dalej

    Dlaczego warto używać Azure Cloud dla rozwiązań IoT

    Cyfrowa transformacja zmienia sposób, w jaki połączone są produkty, aktywa, dane i operacje, aby dostarczyć biznesową wartość dla klientów. Przekształcenie danych cyfrowych na…
    Czytaj dalej

    Wizualizacja danych w IoT

    Jedną z niewątpliwych zalet rozwiązania, jakim jest Internet Rzeczy, jest możliwość gromadzenia i przetwarzania ogromnej liczby różnorodnych danych (np. wartość temperatury, liczba wyprodukowanych…
    Czytaj dalej

    Skalowanie Horyzontalne w ThingWorx 9

    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,…
    Czytaj dalej

    IoT Hub Connector dla ThingWorx – Połączenie ThingWorx z Chmurą Azure

    Thingworx IoT Hub Connector jest mostem, który łączy platformę Thingworx z chmurą Azure (a dokładniej z Azure IoT Hub). Zapewnia on bezpieczną (opartą…
    Czytaj dalej

    Czym jest AIoT? Artificial Intelligence of Things w Przemyśle 4.0 

    Synergia, tak można określić to naturalne połączenie technologii, które znacząco wpłynie na wygląd przyszłości produkcyjnej. Ostatnimi czasy coraz większą popularność zyskuje, obok Internetu Rzeczy (IoT), sztuczna inteligencja…
    Czytaj dalej

    Co nowego w ThingWorx 9.0?

    Tegoroczny Liveworx, ze względu na globalną sytuację wywołaną przez pandemię COVID-19, wyjątkowo odbywał się wyłącznie w wersji on-line. Już pierwszego dnia zapowiedziano wypuszczenie…
    Czytaj dalej

    Machine Learning & ThingWorx vs COVID-19

    Rozwój sztucznej inteligencji, a wraz z nią uczenia maszynowego nabrał w ostatnich latach dużego rozpędu. Ciągłe dążenie do zwiększenia mocy obliczeniowej komputerów dało…
    Czytaj dalej

    Sieć 5G kluczem do Przemysłowego Internetu Rzeczy

    Przemysłowy Internet Rzeczy zmienia dziś nasze spojrzenie na klasyczne pojęcie produkcji. Największe koncerny wytwórcze chętnie sięgają po rozwiązania technologiczne, które usprawniają i zwiększają…
    Czytaj dalej

    Koronawirus, a ciągłość produkcji – IoT i AR dla przemysłu

    Nagła epidemia koronawirusa SARS-CoV-2 i wywoływanej przez niego choroby COVID-19 wpłynęła na każdą sferę funkcjonowania współczesnego świata. Wywołane zagrożeniem epidemiologicznym ograniczenie przepływu ludzi, towarów i usług już negatywnie wpłynęło na ciągłość procesów produkcyjnych wielu branż, a każdy…
    Czytaj dalej

    Jak Internet Rzeczy zmienia branżę lotniczą?

    Internet Rzeczy stosowany jest w coraz szerszym zakresie, a z rozwiązań optymalizujących czy gromadzących informacje korzystają światowi giganci. Wszystko po to, aby usprawniać…
    Czytaj dalej

    Jak Internet Rzeczy rozwija przemysł motoryzacyjny?

    Nikogo nie zaskoczy stwierdzenie, że przemysł motoryzacyjny jest z natury innowacyjny. Samochody to maszyny, które historycznie zrewolucjonizowały wiele obszarów przemysłu, a dziś można…
    Czytaj dalej

    Internet Rzeczy w branży logistycznej

    Wydawałoby się, że Internet Rzeczy jest dedykowany wyłącznie branży przemysłowej. Z nią jednak bardzo związane są transport oraz logistyka, które również mogą skorzystać…
    Czytaj dalej

    Czym ThingWorx różni się od Axeda i czy warto rozważyć zmianę?

    Odkąd PTC odzyskało ThingWorx w 2013, było jasne, że pionier parametrycznego CAD’a oraz jeden z liderów PLM chciał znacznie powiększyć ślad swojej obecności…
    Czytaj dalej

    _Zostańmy w kontakcie

    Skontaktuj się