1. REPLICATED DATA TYPES - APPLICATIONS?

2. Remaining Topics The Orleans Actor System Extending Orleans with support for Geo- Distribution. GSP: a generalization of TSO for distributed systems.

3. ORLEANS

4. Distributed Cache + Actor System Use actors as the cache in a service Distribute actors over cluster of machines Maintains distributed hash table fault tolerant and elastic: nodes can fail, cluster can grow or shrink Front Tier Cache Layer Storage Tier Clients Data Center

5. Typical use? Actors = application-defined objects have some application-specific meaning (e.g. user profile, chatroom, order, client, …) often contains many variables/objects  group related data into single actor  For performance, want as few hops as possible not too large  each actor should have modest load, so the runtime can load balance actors across machines

6. Status Open Source https://github.com/dotnet/orleans https://github.com/dotnet/orleans Used in production by many teams inside/outside Microsoft Biggest internal customer: Halo (uses Orleans for services)

7. Main Differences to Standard Actors Actor Naming: user-defined keys Actor Lifetime: activate/deactivate instead of construct/GC Return values: all messages return value or time out, propagate exceptions

8. Actor Naming Actors are named by user- defined keys. For example, Game(Guid guid) UserProfile(string userid) Each actor is uniquely identified by the combination (class, key) Distributed hash table maps keys to actors Location is transparent to user

9. Actor Lifetime You cannot construct an actor, but you can construct a reference (from class + key) and send msg. Activation: Runtime installs instance in the cache on first message. Deactivation: instances are removed from the cache after inactivity (default 10min).

10. Volatile vs. Persistent Programmer decides whether an actor is volatile or persistent. Volatile Start fresh when activated. Throw away when deactivated. Persistent Read from storage when activated. Write to storage on each change. Write back when deactivated

11. A few code snippets Go to documentation at www.github.com/dotnet/orleans www.github.com/dotnet/orleans

12. Intra-Actor Scheduling Each grain has cooperative scheduling  No concurrency (never more than one thread executing)  no preemptions except at designated points (where doing I/O or other actor calls)  Reentrance optional (default: no reentrance) uses compiler-supported promises (async/await in C#)

13. Example: Simple handler public class MyGrain : IMyGrain { public async Task SayHello(string name ) { return "Hello " + name ; }

14. Example: Delegating handler public class MyGrain : IMyGrain { public async Task SayHello(string name ) { var forwardto = GrainClient. GrainFactory. GetGrain (“key"); await forwardto.SayHello(name); return "Hello " + name ; }

15. Example: Sequential Calls public class MyGrain : IMyGrain { public async Task SayHello(string name ) { var forwardto1 =…; var forwardto2 =…; var result1 = await forwardto1.SayHello(name); var result2 = await forwardto2.SayHello(name); return result1 + result2; }

16. Example: Parallel Calls public async Task SayHello(string name ) { var forwardto1 =…; var forwardto2 =…; var task1 = forwardto1.SayHello(name); var task2 = forwardto2.SayHello(name); var result1 = await task1; var result2 = await task2; return result1 + result2; }

17. Example: Many Parallel Calls public async Task SayHello(string name ) { var tasks = new List (); for (int x = 0; x < 999; x++) { var forwardto = GrainClient. GrainFactory. GetGrain (“key“+x); tasks.Add( forwardto.SayHello(name) ); } await Task.WhenAll(tasks); return “successfully called 1000 grains"; }

18. GEO-DISTRIBUTION FOR ORLEANS

19. California Netherlands Running Orleans in Multiple Data Centers? AB 19

20. Motivation for Geo-Distribution Better Service Latency  use datacenter close to client for servicing that client Better Fault Tolerance  application is available despite datacenter failure 20

21. Geo-Distributed Virtual Actor Cache Client Layer Front Tier Actor Cache Storage Tier

22. Programmer configures objects Chooses between persistent and volatile Chooses between single-instance and multi-instance Runtime selects applicable consistency protocol

23. Programming API? -Should support -linearizable operations -highly available operations -Should be easy to understand -no event graphs, relations, or consistency axioms, please. -Our Solution: GSP (global sequence protocol) -is a generalization of TSO -operational model -Includes equivalent of “fences” to support linearizability

24. THE VERSIONED API

25. State + Updates User defines class for object (w/ default constructor), and class for each update operation Example: class CounterState { int count = 0; apply(Add x) { count += x.amount; } apply(Reset x) { count = 0; } } class Add { uint amount; } class Reset { }

26. Global Version Sequence System constructs sequence of global versions v 0 v 1 v 2 … v 0 is given by default constructor v i+1 is given by calling Apply(u i ) on v i for some update u i

27. Programming API: System State Each cluster stores  Last known global version  Queue of unconfirmed updates

28. Background Tasks In the background,  unconfirmed updates are applied to latest version  latest version is propagated to all clusters (and confirmed updates are removed from queue)

29. Where is the Latest Version? Depends. For persistent objects, latest version is in storage. (programmer can see this via side channels) For volatile objects, depends on protocol (current default: use statically selected leader)

30. Local Update Programmer calls void enqueue(Upda Effect: update goes into local queue void enqueue(Update u) u

31. Local Read Programmer calls one of void enqueue(Upda Reads confirmed state or combination of confirmed state + unconfirmed updates Pair read_confirmed() State read_tentative()

32. Linearizable Update linearizable_update(Update u) { enqueue(u); await confirm_updates(); } flushes

33. Linearizable Read Flushes & Fetches linearizable_read() { await synchronize_now(); return read_confirmed(); }

34. Summary: Versioned API Can update w/o communication (update goes into queue) Can read w/o communication (read confirmed or tentative state) Can read or update linearizably (using 2 types of “fences”) Can visualize all possible behaviors using abstract operational model

35. Implementation Protocols BCAS: batching compare-and-swap VLB: volatile leader-based GSI: global single-instance VolatilePersistent Single- instance GSIGSI + sync GSI + BCAS Multi- instance VLBBCAS

36. Other Implementation Aspects Dynamic configuration  Administrator can add/remove clusters Discovery of dynamic IP addresses  Clusters must advertise IP addresses of gateways to other clusters System uses hybrid of broadcast/epidemic protocol for synchronizing configuration and gateway information

37. TSO VS. GSP

38. TSO Coherent Shared Memory update operations store buffer read operations update operations store buffer read operations

39. TSO Coherent Shared Memory update operations store buffer read operations update operations store buffer read operations stores are asynchronous, but reads are still synchronous

40. GSP Reliable Total Order Broadcast update operations update buffer read operations Local Replica We want something a little bit weaker, more like this

41. GSP Reliable Total Order Broadcast update operations update buffer read operations Local Replica see effect of updates immediately

42. GSP Reliable Total Order Broadcast update operations update buffer read operations Local Replica Stream updates both ways -> fully asynchronous

43. GSP vs. TSO? If returns-before is not observed across different sessions, then GSP is observationally equivalent to TSO. If returns-before is observed, they are not equivalent. This history is possible on GSP but not TSO: wr(1):ok wr(2):ok rd:1 rd:2 GSP is to TSO as SC is to Linearizability!

44. Conclusion Programming interactive, reactive, geo- distributed, scalable applications is a big challenge Many opportunities for interesting & relevant research