Tijd om te synchroniseren op consistentie in IIoT-systemen

Een belangrijk (en veelbesproken) onderwerp bij het ontwerpen van gedistribueerde systemen is welk consistentiemodel moet worden gebruikt. Consistentiemodellen beïnvloeden veel onderdelen van het systeemontwerp, en het kiezen van de een boven de ander heeft invloed op zaken als systeembeschikbaarheid en robuustheid tegen netwerkstoringen. Deze blog is bedoeld voor systeemarchitecten die meer grip willen krijgen op wat het betekent om wel of niet consistent te zijn.

Laten we eerst duidelijk maken dat deze blog niet gaat over de "C" in ACID (https://en.wikipedia.org/wiki/ACID). ACID-consistentie zorgt ervoor dat updates van een datastore geldig zijn volgens een reeks beperkingen. Deze blog richt zich op het soort consistentie dat beschrijft wat er gebeurt wanneer gegevens worden gerepliceerd tussen gedistribueerde winkels. Het blijkt dat ACID doet daar iets over zeggen, maar het is de 'I' (Isolation), niet de 'C'. Verwarrend? Een beetje, maar heb geduld.

Isolatie wordt ook wel sterke consistentie genoemd . Wanneer een systeem sterk consistent is, worden alle schrijf- en leesbewerkingen tussen gedistribueerde winkels in dezelfde volgorde uitgevoerd voor elke toepassing in dat systeem. Dat is een uitgebreide manier om te zeggen, wanneer een applicatie iets schrijft, alle applicaties die na . lezen het schrijven, zijn gegarandeerd de nieuwe gegevens te zien.

Dit blijkt in veel systemen een ongelooflijk nuttige eigenschap te zijn. Het zorgt ervoor dat geen twee mensen dezelfde koelkast via een winkelwebsite kunnen bestellen, zelfs niet wanneer ze op exact hetzelfde moment aankopen. Sterke consistentie dwingt dezelfde volgorde van bewerkingen wereldwijd af , dus twee aankopen worden altijd door iedereen in dezelfde volgorde verwerkt. In de praktijk betekent dit dat bij de tweede aankooppoging gegarandeerd is dat de koelkast niet op voorraad is.

Sterke consistentie klinkt als een mooi ding om te hebben, dus waarom gebruiken niet alle systemen het? Het is vanwege iets dat de CAP-stelling wordt genoemd (https://en.wikipedia.org/wiki/CAP_theorem). Allereerst een korte opmerking:CAP is door velen terecht bekritiseerd omdat het te eenvoudig is om het gedrag van complexe gedistribueerde systemen te beschrijven - dus wees voorzichtig bij het gebruik ervan - maar het biedt wel een nuttig kader voor het bespreken van consistentiemodellen. Ik zal niet ingaan op de details van CAP omdat het internet veel bronnen heeft die het veel beter doen dan ik hier zou kunnen hopen.

Samenvattend vertelt CAP ons wat er gebeurt in gedistribueerde systemen wanneer applicaties tijdelijk niet meer kunnen "praten", of met andere woorden:wanneer het netwerk uitvalt. Het blijkt dat het onmogelijk is voor een systeem om sterk consistent te zijn en garanderen altijd uptime, ongeacht het verlies van connectiviteit. Jammer.

Dat klinkt ingewikkeld, maar is eigenlijk best intuïtief. Weet je nog hoe sterke consistentie een globale volgorde vereist voor alle bewerkingen in een systeem? Dat betekent een gelezen must zie alle eerdere schrijft, van iedereen. Als niet alle applicaties zijn aangesloten, wordt dit onmogelijk te garanderen. Eén aanvraag heeft misschien een bestelling voor een koelkast geplaatst, maar als nog niet alle aanvragen deze bestelling hebben ontvangen, kunnen ze geen nieuwe bestellingen plaatsen. Dat resulteert in downtime voor de winkelwebsite!

Downtime kan worden beperkt door meer middelen aan het probleem te besteden, zoals databasereplicatie (meer opslag) of redundante webservers (meer rekenkracht). Tegenwoordig is dit bijna triviaal om te doen in openbare cloudinfrastructuren, hoewel het behoorlijk duur en complex wordt als een systeem veel bewegende delen heeft, zoals bij microservice-architecturen. Wanneer een systeem niet in een cloud draait, is het toevoegen van meer bronnen verre van triviaal, aangezien opslag, rekenkracht en bandbreedte allemaal veel beperkter zijn in niet-cloudomgevingen.

Dus hoewel sterke consistentie handig is voor applicaties, belast het een infrastructuur (en uw portemonnee!). Om deze problemen te omzeilen, hebben slimme mensen oplossingen bedacht die niet zo pedant zijn als het gaat om consistentie, maar toch werkbaar vanuit een toepassingsperspectief. Waar we het over hebben is 'uiteindelijke consistentie'. Tijd voor een andere definitie.

Een systeem is uiteindelijk consistent wanneer, als er geen updates zijn geweest voor een bepaald item, alle applicaties uiteindelijk dezelfde waarde zien. Of in lekentermen:iedereen ziet uiteindelijk dezelfde data als ze maar lang genoeg wachten. Dit betekent dat applicaties tegelijkertijd kunnen lezen en schrijven, en dat zelfs als het netwerk plat ligt! Uiteindelijk levert de infrastructuur van het systeem alle updates voor de applicaties.

Omdat applicaties niet op elkaar hoeven te wachten, is de uptime van een uiteindelijk consistent systeem in theorie oneindig - op voorwaarde dat je applicaties niet crashen en er geen stroomstoring optreedt. Infinity is echter niet praktisch; na enige tijd verwacht je dat je applicaties opnieuw verbinding maken. Daarom stellen uiteindelijk consistente systemen doorgaans een limiet aan de tijd die nodig is om consistent te worden. Wanneer die limiet verloopt en toepassingen geen kans hebben gehad om te synchroniseren, vindt herstel van fouten plaats.

Beschikbaarheid is niet het enige voordeel van uiteindelijk consistente systemen. Omdat lezen en schrijven geen synchronisatie vereisen, zoals bij sterk consistente systemen het geval is, zijn ze veel sneller. Het gebrek aan synchronisatie maakt ook directe peer-to-peer-communicatie mogelijk, wat de prestaties verder verbetert en tegelijkertijd de robuustheid verbetert, omdat er geen gecentraliseerde berichtenmakelaar nodig is, die single points of failure introduceert.

Hoewel uiteindelijke consistentie niet werkt voor winkelwebsites, zou het, gezien de voordelen (beschikbaarheid, prestaties, robuustheid, efficiënt gebruik van hulpbronnen) geen verrassing moeten zijn dat het veel wordt gebruikt in bedrijfskritieke systemen.

De RTI Connext Product Suite is de toonaangevende implementatie van de OMG DDS-standaard, die op grote schaal wordt ingezet als een protocol in bedrijfskritieke, industriële IoT-systemen. Een groot verschil tussen OMG DDS en andere connectiviteitsprotocollen is dat DDS zich gedraagt ​​als een gedistribueerde database die continu wordt gesynchroniseerd tussen applicaties, terwijl andere protocollen doorgaans een interface bieden om berichten rond te sturen en het statusbeheer over te laten aan de applicatie.

Als je denkt dat een gedistribueerde database klinkt als iets dat te maken heeft met consistentie, dan heb je gelijk. RTI Connext DDS moet voortdurend de balans vinden tussen beschikbaarheid en prestaties en consistentie om te kunnen werken in de meest veeleisende missiekritieke omgevingen. Standaard gebruikt RTI Connext DDS uiteindelijke consistentie die garandeert dat applicaties die ermee zijn gebouwd niet stoppen met werken wanneer het netwerk uitvalt, terwijl ervoor wordt gezorgd dat alle applicaties uiteindelijk hetzelfde beeld van "de wereld" delen.

Nu zie je hoe iets dat zo abstract klinkt als "consistentie" verstrekkende gevolgen heeft en moet worden behandeld als een belangrijk onderwerp in het vroege systeemontwerp. Helaas is het nooit zo eenvoudig om ofwel 'sterk consistent' of 'uiteindelijk consistent' te zijn. Een lambda-architectuur (https://en.wikipedia.org/wiki/Lambda_architecture) is slechts één voorbeeld dat zowel sterke als uiteindelijke consistentie gebruikt om het beste van beide werelden te krijgen. Met zoveel tinten consistentie moeten systeemarchitecten complexe beslissingen nemen over hoeveel consistentie hun systeem zich kan veroorloven.

Bij RTI helpt ons professionele serviceteam u om die beslissingen te nemen, de consequenties te doordenken en onze producten te configureren om een ​​consistente oplossing te creëren die voor u werkt.

Lees hier meer over RTI-services:https://www.rti.com/services