Edge Computing a Fog Computing: o výhodách mlžných sítí

Provoz v bezdrátových sítích se má během dalších deseti let zvýšit třítisíckrát proti stavu z roku 2000. Co s tím?

Přístupů k tomu, jak urychlit odbavení provozu v bezdrátových sítích, se v poslední době vyrojila celá řada. Pokud je pravda, že se provoz v bezdrátových sítích během dalších deseti let zvýší třítisíckrát proti stavu z roku 2000, není se zase čemu divit. Já jsem si pro dnešek vybral jeden, který mě zaujal už proto, že se tomu věnujeme v Energomonitoru. Jde o Edge nebo též Fog Computing

Okraj sítě nebo mlha v ní

Proč to jméno? Má připomenout, že na rozdíl od cloudu, kde jsou kompletní data a aplikace umístěny v datovém centru, se nyní styčné body přesouvají do okrajů sítě (to je to Edge) nebo sestupují jako mlha mezi uživatele (to je ten fog) – obojí popisuje jedno a to samé. Zatímco cloud je nahoře, mlha je dole, mezi námi, říkají hlasatelé fog computingu. Jak to přeložit do češtiny, suď Bůh či Viktor Janiš – něco jako mlžné síťování? 

Schéma Fog computingu

Pojďme se podívat, k čemu mlžné síťování je. Už jsme si řekli, že jde o vysunutí datového rozhraní co nejblíže k uživateli. Data se neposílají do centrálního cloudu přes několik skoků v síti a půlku světa, ale ideálně jedním skokem na nejbližší síťový prvek. Ten je zpracuje, vyhodnotí, něco odpoví, případně sám kontaktuje cloud a získá komplexnější odpověď, je-li potřeba. Poněkud to připomíná systém CDN, jenže v CDN se skladují předpřipravená data, kdy uživatel chce film číslo osmnáct a ten se mu pošle ze síťově nejbližšího úložiště. Fog na rozdíl od CDN musí data umět zpracovat, vyhodnotit a vrátit zpět unikátní data, případně si svá vlastní data asynchronně aktualizovat z cloudu. 

Proč IoT směřuje na kraj sítě 

Fog má zkrátit odezvy, kdy se čeká na odpověď vzdáleného datového centra. To je podstatné hlavně v mobilních sítích 5G, kde by to snížilo zpoždění i rozptyl. Takhle by Fog vypadal ve srovnání s Cloudem: 

Cloud

Fog

Zpoždění

větší, neovlivnitelné

malé

Rozptyl

větší, neovlivnitelný

malý

Umístění nodů v síti

na internetu

na okraji místní sítě

Vzdálenost mezi klientem a serverem

více skoků

spíše jeden skok

Bezpečnost

nedefinovaná

lze vyžadovat

Útok na datový přenos

pravděpodobný

málo pravděpodobný

Teď se podívejme na to, jak by to vypadalo v praxi. V tomto případě s přihlédnutím k chytrým městům a Energomonitoru, protože s takovou aplikací máme určitou zkušenost. 

Když v Energomonitoru provádíme nějaké měření (teplota, spotřeba, nějaký jiný stav), není měřící senzor připojený přímo do internetu. Je napojen na “homebase”, domácí základnu. Z pohledu architektury fog/edge sítí jde právě o ten edge, hraniční zařízení. V našem případě šlo původně o pragmatický tlak na cenu a použitelnost: vybavovat každý senzor připojením do internetu by bylo drahé, těžko by se to spravovalo a dělalo by to problémy s napájením, životností baterií i instalací. Až později se ukázalo, že hvězdicová architektura HAN (Home Area Network) soustředěná do homebase má i spoustu dalších výhod. 

Role homebase 

Homebase v pozici hraničního zařízení provádí věci, které samotný senzor dělat nezvládá, neboť v něm je jednoduchý (=levný) procesor. Homebase například dělá součty senzory dodávaných hodnot, násobí hodnoty cenou (staženou z cloudu) tak, aby ukazoval na lokálním displeji útratu za energie, je také schopna reagovat na překročení hodnoty, pokud je potřeba. To u nové generace homebase využíváme například pro zčervenání displeje, pokud vyhodnotíme nadměrnou spotřebu. 

Čistě cloudová architektura očekávala, že tyhle výpočty bude dělat až cloudový server, jenže to by bylo nepraktické i z důvodů autonomního nouzového provozu. Teď, když si hrajeme s vlastním termostatem, vidíme polo-autonomní provoz jako velmi důležitý, a ten zajišťuje právě hraniční zařízení. V našem případě zůstává hraničním zařízením homebase, která je zastrčená někde u internetu, na zdi má uživatel regulátor termostatu s displejem i tlačítky. 

Pokyny k ovládání topení dává uživatel tímto regulátorem. Tehdy data jdou do homebase a případně dále. Nebo změny uživatel zadává přes web, kdy naopak cloud posílá data do homebase a ta dále na displej regulátoru, aby věděl, že má ukazovat novou nastavenou teplotu. Nebo zařízení jede v automatickém režimu, kdy se topná křivka z částí vygeneruje cloudem, z části ji aktualizuje homebase podle momentálního stavu (počasí aj.) a požadavků z regulátoru. 

Důležité je, že se topí i v případě, kdy nefunguje internet, protože homebase zhruba ví, co má dělat, jen třeba nemusí mít nejčerstvější data o počasí a začne topit i s tím, že se za půl hodiny náhle venku oteplí. Zařízení není závislé na tom, zda internet funguje. Pokud internetové připojení neběží, jen chytrý termostat zhloupne. Doufám, že z příkladu je jasnější, co se fogem a hraničním zařízením myslí a jaké jsou přínosy tohoto konceptu. Je zřejmé, že v případě IoT k němu dospěla řada vývojářů nezávisle, intuitivně, analýzou potřeb a požadavků. 

Proč si od edge computingu slibují přínos zavedené počítačové firmy a proč ji třeba Dell tak propaguje? Konkrétně Dell by rád dodával svoje servery jako hraniční zařízení, přičemž tady vynikne krása všeprostupující síťové mlhy. 

Svatý grál univerzální homebase 

Hraniční zařízení by totiž mohlo mít API, přes které by se jednotlivá IoT zařízení zaregistrovala a sdělila by, odkud si má hraniční zařízení stáhnout jejich profily. V profilech stažených z cloudu by byly informace pro zkonfigurování a provozování služby v rámci API, tedy vlastně to, co by hraniční zařízení měla s daty dělat – která zpracovávat, která posílat rovnou do cloudu, co z cloudu vracet na připojené senzory či jiná IoT zařízení. Podstatná výhoda by byla jasná: stačilo by mít pro obsluhu více systémů jedno hraniční zařízení, nebylo by potřeba mít jednu jednotku pro Energomonitor, jinou pro Hue a další třeba pro NetAtmo. To by znamenalo přehlednější architekturu, méně náročnou na obsluhu a síťování, rychlejší provoz v síti a také nižší cenu. A odbyt pro dodavatele hraničního hardware (už asi chápete, co v tom vidí Dell). 


Autor: Dell

Dell Edge Gateway

Všechno má svá pro a proti. Tak především, vytvořit a zpřístupnit třetím stranám takové prostředí, aby to fungovalo automaticky a s mírou variability, jakou turbulentní prostředí IoT vyžaduje, je velmi těžké. Proto se stále potkáváme s přístupem, že si hraniční zařízení každá firma vyrábí sama (jako my) a doma se vám ty “krabičky” štosují. Má to svou logiku, vyrobit jednoúčelový hardware je výrazně levnější, než udělat víceúčelový, po SW i HW stránce vyhovující univerzální zařízení. 

Cesta směřuje k univerzalitě, ale ještě to potrvá. Navíc je v tom politika – jednotlivé firmy se nechtějí vzdát možnosti být v budoucnu takovým “edge hubem”, nebo na to nejsou technologicky připravené a především, chybí řešení. Letos se to pár firem jako Samsung, LG nebo Google pokusí změnit, na veletrzích se představovaly takové první domácí huby kombinované s routery, ale všechny mají své “ale” – v případě Googlu třeba tvrdohlavé trvání na vlastním rádiovém protokolu Thread a dychotomii s termostatem Nest, jenž aspiruje na podobnou pozici. Ostatně, právě rádiové protokoly a dost široký rozptyl funkcí, které IoT už dnes pokrývá, stojí za problémy s návrhem opravdu univerzální hraniční krabičky. 

“Univerzální” Edge zařízení nacházejí využití spíše ve větších průmyslových instalacích, kde je počet scénářů použití předem daný a všechno se dá předkonfigurovat. Jenže co je dnes v průmyslu, sestoupí rychle do masového trhu. Něco takového se možná snaží udělat Turris Omnia – někde se o podpoře IoT psalo, ale obávám se, že v téhle podobě je to obří úkol, ve kterém ovšem budeme držet palce. 

KL_NOMINACE

Je v tom business, není v tom business? 

Význam hraničních zařízení a mlžných sítí poroste spolu s tím, jak se bude zvyšovat počet IoT zařízení a jak porostou nároky na ně. Život jim bude komplikovat roztříštěnost komunikačních i přenosových protokolů, tedy kombinace HTTP/S, MQTT, STOMP, AMQP Zigbee, Zwave, BTSmart, wmbus a dalších. I tady se bude prach usazovat dlouho, protože každý z radiových protokolů je určený pro něco jiného a má své opodstatnění. Stejně tak každý z protokolů pro přenos zpráv se hodí na něco jiného. 

Dnes se může zdát, že význam API v hraničních zařízeních poroste a že je to optimální moment, začít budovat ekosystem pro embedded zařízení a naskočit na rostoucí vlnu. Ve skutečnosti je ve hře stále mnoho neznámých a také tlaků firem, které jsou výrazně napřed a mají možnost prosadit svou cestu. Mezi ně patří Google/Nest, Apple, Samsung i LG a také firmy, které masově vyrábějí domácí routery a všímají si rostoucí poptávky po vyšší inteligenci routerů, jako D-Link, Netgear Ubiquiti, Cisco/Linksys a v neposlední řadě také Synology. Na trhu tedy bude docela tlačenice, v níž se vyznat nebude lehké.

16 názorů Vstoupit do diskuse
poslední názor přidán 27. 1. 2016 4:39

Školení Google Analytics pro pokročilé

  •  
    Jak využít nové funkce Google Analytics
  • Vyhodnocování pomocí Multichannel funnels
  • Neopakujte chyby při vyhodnocování dat.

Informace o školení Google Analytics pro pokročilé »