redes de suporte de sistemas distribuídos · distributed systems 20/21 –di/fct/nova / 2 goals in...

Distributed Systems 20/21 – DI/FCT/NOVA / 1

DISTRIBUTED SYSTEMS

Lab 10

Nuno Preguiça, João Leitão, Sérgio Duarte


GOALS

In the end of this lab you should be able to:

• Project Architecture Overview

• Understand the goals of replication

• Kafka

• Understand the abstractions provided by Kafka

• Understand how to publish events in Java

• Understand how to subscribe event in Java

• Understand the asynchronous processing of Kafka received operations

in the project.

• Zookeeper

• Understand the abstractions provided by Zookeeper

• Understand how to create a tuple in Java

• Understand how to monitor a tuple in Java

• Understand how Zookeeper can be used to (dynamically) elect a

primary

• Overall Revision of the Project Goals


GOALS




• Kafka





in the project.

• Zookeeper





primary



fcm192.168.1.132

Users:

REST

Spreadsheets:

PROJECT ARCHITECTURE OVERVIEW

fcsh192.168.1.45

Users:José

SOAP

Spreadsheets:...

fct192.168.1.2

Users:Sara

REST

Spreadsheets:...


fcm192.168.1.132

Users:Magda

REST

Spreadsheets:


sara@fct

Rest Server

Soap Server

Proxy Server

Clientes finais emuladospelo Tester jose@fcsh magda@fcm

fcsh192.168.1.45

Users:José

SOAP

Spreadsheets:...

fct192.168.1.2

Users:Sara

REST

Spreadsheets:...


fcm192.168.1.132

Users:

REST

Spreadsheets:


Rest Server

Soap Server

Proxy Server

REST Interactions1 2

sara@fct jose@fcsh magda@fcm

fcsh192.168.1.45

Users:José

SOAP

Spreadsheets:...

fct192.168.1.2

Users:Sara

REST

Spreadsheets:...


fcm192.168.1.132

Users:

REST

Spreadsheets:


Rest Server

Soap Server

Proxy Server

SOAP Interactions 1 2


fcsh192.168.1.45

Users:José

SOAP

Spreadsheets:...

fct192.168.1.2

Users:Sara

REST

Spreadsheets:...


fcm192.168.1.132

Users:

REST

Spreadsheets:


Rest Server

Soap Server

Proxy Server

Rest Interactions1

2


3

4

REST Interactions(with OAuth)

fcsh192.168.1.45

Users:José

SOAP

Spreadsheets:...

fct192.168.1.2

Users:Sara

REST

Spreadsheets:...


GOALS




• Kafka





in the project.

• Zookeeper





primary



GOALS OF REPLICATION

As the name implies, replication entails having replicas

(multiple copies) of a service. The idea is that these replicas

cooperate and coordinate among themselves to provide a

(single and unified) service to users.

• Usually, the user should not be aware or notice the

existence of replicas (Transparency)

• If one replica fails, the service can continue without the user

noticing the failure of that replica (Fault-Tolerance)

• Sometimes it is possible to take advantage of the additional

computational resources (across multiple replicas) to handle

more client requests or handle these requests faster

(Performance)



As the name imply replication entails having replicas (multiple

copies) of a service. The idea is that these replicas cooperate

and coordinate among themselves to provide a service to

users.



• If one replica fails, the service can continue without

the user noticing the failure of that replica (Fault-Tolerance)




(Performance)


GOALS




• Kafka





in the project.

• Zookeeper





primary



KAFKA: PUBLISH/SUBSCRIBE

Apache Kafka is a popular system that provides indirect and

reliable communication through a publish/subscribe API

There are two main entities in this context:

• Publisher: Emits events/messages for a given topic

• Subscriber: That registers its interest in receiving

events/messages that are/were published in a given topic

(or set of topics)

Interactions in this model are independent of space and time,

meaning that two entities might exchange information without

knowing each other or without being online simultaneously.


KAFKA: PUBLISH/SUBSCRIBE

In the context of the project one of the variants of replication

that you can build will use Kafka to propagate operations

received from a (end-user) client the server replicas within a

single domain.

This will be achieved by publishing the received operations as

events through Kafka in a topic (that can be the domain

name).

Notice that interactions between your servers and Kafka are

asynchronous (i.e., they are not instantaneous, there can be

delays which can impact the system).


KAFKA: PROGRAMMING (PRELIMINARIES)

There is an Eclipse Java Project in the course web page that

has the examples that are going to be presented in this

section.

The project name is: sd2021-aula10-kafka



You need to add maven dependencies to use Kafka in your

project (file pom.xml):

In the <dependencies> section:<dependency>

<groupId>org.apache.kafka</groupId>

<artifactId>kafka-clients</artifactId>

</dependency>

In the <dependencyManagement> section and within the

<dependencies> subsection:<dependency>

<groupId>org.apache.kafka</groupId>

<artifactId>kafka-clients</artifactId>

<version>2.8.0</version>

</dependency>



To use and interact with Kafka you will need the Kafka server

(that internally also uses Zookeeper) executing.

In the project you have script files for linux/mac and windows

that executes a docker container with Kafka (and Zookeeper)

ready for use in either your local machine (address localhost)

and in the context of the SD project tester (in a container with

hostname kafka)

Linux/Mac: start-kafka.sh

Windows: start-kafka.bat



To use it in your local machine (for instance to test your code in

Eclipse):

Linux/Mac: bash start-kafka.sh localhost

Windows: Start-kafka.bat localhost



To use it with your containers in docker:

Linux/Mac: bash start-kafka.sh kafka

Windows: Start-kafka.bat kafka


GOALS




• Kafka





in the project.

• Zookeeper





primary



KAFKA: PROGRAMMING (PUBLISH EVENTS)

To show how you can publish a Message on a Given Topic we

have a simple application (main) that serves only as an example

of how you can publish messages.

In your project your own server are going to be responsible for

publishing messages and there is no need for new classes with a

main for this purpose.

The Javadoc of Kafka (for version 2.8.0) can be found in:

https://kafka.apache.org/28/javadoc/

https://kafka.apache.org/28/javadoc/



Class KafkaSendMsg



Class KafkaSendMsg

This is simple code for asking the user to provide

the name of the topicwhere we are going to

publish the message andthe message itself



Class KafkaSendMsg

We create a KafkaPublisher (we will see the code next) using the static method createPublisher. The argument is a string with

possible locations for the kafkaservers separated by commas

(hostname:port)



Class KafkaSendMsg

We can now publish any number of messages we want. Each

message has a topic and a value (the message itself).

It returns the sequence number of this message in Kafka (notice that sequence numbers are per

Topic)



Class KafkaSendMsg

If the sequence number of positive it will indicate success, otherwise -1 denotes an error (potentially because the Kafka server could not be contacted)



Class KafkaPubisher (preamble)




The static method used to instantiate this class that defines

a set of important properties




This properties indicates the location of Kafka servers, it’s a

String with pairs hostname:portseparated by commas (as seen

previously)




This indicates the format (particularly, how to serialize) the Keys of records. Keys are optional

when you publish a record in Kafka.

Here we assume these are String




This indicates the format (particularly, how to serialize) the

values of records.

Here we assume these are also String




This is the KafkaProducer which is the class in the Apache Kafka

library responsible for managing interactions of a Publisher with

the Kafka server(s).




You can terminate a KafkaProducer (if you are not

going to publish more messages) by using the close() method.



Class KafkaPubisher (publish methods)

Here we have two alternative methods to publish a record to

Kafka. They only differ in using or not a Key associated with that

record.




To publish a Record to Kafka we use the method send of the KafkaProducer. The argument is a

ProducerRecord that is typified with the types of the Key and Value (both String in this case).

The arguments can either be the topic, key, value or only the topic and value.




The send method returns what is called a Future (i.e., it returns before effectively communicating with the Kafka server)

The .get() invocation over this Future blocks until we get a reply from the Kafka server (making the method synchronous)

It return an object with Metadata for the record just created.




The .offset method of the RecordMetada object returned by the get operation provides the sequence number of this record in Kafka for this topic. Notice that sequence numbers are per Topic. Consumers consume records in an order that

respects this offset (if the topic has a single partition, you can check more about this in the documentation)


GOALS




• Kafka





in the project.

• Zookeeper





primary



KAFKA: PROGRAMMING (SUBSCRIBING AND RECEIVINGEVENTS)

Class KafkaReceiver



Class KafkaReceiver

This is just asking the user for the topic in which this client

will be interested



Class KafkaReceiver

Since Consumers can be interested in multiple topics,

we encapsulate that topic within a List



Class KafkaReceiver

Here we create the KafkaSubscriber instance that will receive events from Kafka for the topic provided (we will see this class afterwards).

The arguments are a String with the possible location of Kafka servers (as before) and the List

with topics)



Class KafkaReceiver

The start method initializes a thread that will consume events (i.e., Records) from Kafka for ever. It receives an instance of the ConsumerRecord interface (defined in-line here) with the code to handle each record (in this example it

simply prints the contents of the record)



Class KafkaSubscriber (preamble)




The static method that creates an instance of this class has some

parameters that define the behaviour of the KafkaConsumer




This it the list of Kafka servers as we seen previously for the Producer




This parameter defines the behaviour of the

consumer in relation to where it starts to consume the stream of records for a

topic. Only one value should be used (the two lines here is to show the alternatives) check the

documentation to pick the correct one.




The GROUP_ID_CONFIG parameter defines the group of the consumer. Consumers in the same groups receive different

records for each topic (and each record is received by

a single element of the group). In our case we

want every consumer to receive all the records, so all of them have to be in distinct groups (that is

why we use the System.nanoTime() that

should have different values in different

machines)




We need to indicate how should Keys and Values within records be deserialized (i.e., their formats). As in the producer we are assuming both the Key and Value to be

Strings, hence we use the StringDeserializerfor both.




The KafkaConsumer is the class form the Kafka API that is responsible to interact with the Kafka servers as a consumer. We create it

here and will use it to obtain records from Kafka.

Notice that you can indicate the list of relevant topics on the Constructor, or use the

method subscribe to indicate this list at a later time (there are also methods to

unsubscribe from topics)



Class KafkaSubscriber (methods to consume records)




This is the method used in our example. It starts a new thread that will consume records (or events) from the topics subscribed by this consumer.

It receives a class as argument that implements the RecordProcessor interface (that has a single method:

void onReceive(ConsumerRecord<String, String> r);

This method is executed for each record received from Kafka with the poll method




The pool method of the KafkaConsumer contacts the Kafka server to obtain a Set of (previously unprocessed) records for the relevant topics.

The argument is the time (in miliseconds) for which the operation waits for new records. Upon timeout if no records exist it returns an empty set of Records.

The method can return immediately if there exist records ready for processing by this consumer.




For each record returned by Kakfa we execute the method onReceive ofthe class passed as argument to the start method.

Notice that records are processed in the same order in which they were received.




This method is similar to the previous one, but it does not create a new thread to continually receive records from Kafka (hence, it will block the receiver forever).

It uses a different interface for registering the class that will process each record.

The interface SubscribeListener (defined below) must be implemented by the class being passed as argument to this method.


KAFKA: PROGRAMMING (EXECUTING EXAMPLES)

You can test the examples provided in eclipse.

To do so do the following steps:

1. Start the kafka container as show before in localhost mode

(bash start-kafka.sh localhost or

./start-kafka.sh localhost)

2. Launch the Receiver (in eclipse) and provide a topic (e.g., SD)

3. Launch the Sender (in eclipse) and provide a topic and

message (the topic must be the same)

4. You can execute the Sender more times to see increasing

sequence numbers


KAFKA: PROGRAMMING (EXECUTING EXAMPLES)

Execution of the Sender (in Eclipse)

Execution of the Receiver (in Eclipse)


GOALS




• Kafka




• Understand the asynchronous processing of Kafka received

operations in the project.

• Zookeeper





primary



KAFKA: ASYNCHRONY AND REST SERVERS

(end-user)Client

REST SERVER 1

KAFKA

MainthreadRest

Requestthread

Kafka Consumer

thread

OtherREST

SERVER Replicas



(end-user)Client

REST SERVER 1

KAFKA

MainthreadRest

Requestthread

Kafka Consumer

thread

OtherREST

SERVER Replicas

Rest RequestREQ



(end-user)Client

REST SERVER 1

KAFKA

MainthreadRest

Requestthread

Kafka Consumer

thread

OtherREST

SERVER Replicas

Rest RequestREQ PUBLISH REQ



(end-user)Client

REST SERVER 1

KAFKA

MainthreadRest

Requestthread

Kafka Consumer

thread

OtherREST

SERVER Replicas


CONSUMES REQEXECUTE REQ

CONSUMES REQ



(end-user)Client

REST SERVER 1

KAFKA

MainthreadRest

Requestthread

Kafka Consumer

thread

OtherREST

SERVER Replicas



CONSUMES REQ

Other replicas do notneed to reply to client



(end-user)Client

REST SERVER 1

KAFKA

MainthreadRest

Requestthread

Kafka Consumer

thread

OtherREST

SERVER Replicas



Rest Reply to REQ



(end-user)Client

REST SERVER 1

KAFKA

MainthreadRest

Requestthread

Kafka Consumer

thread

OtherREST

SERVER Replicas



Rest Reply to REQ ?



(end-user)Client

REST SERVER 1

KAFKA

MainthreadRest

Requestthread

Kafka Consumer

thread

OtherREST

SERVER Replicas



Rest Reply to REQ

Wait for Reply



(end-user)Client

REST SERVER 1

KAFKA

MainthreadRest

Requestthread

Kafka Consumer

thread

OtherREST

SERVER Replicas



Rest Reply to REQ

Wait for Reply

Reply



(end-user)Client

REST SERVER 1

KAFKA

MainthreadRest

Requestthread

Kafka Consumer

thread

OtherREST

SERVER Replicas



Rest Reply to REQ

Wait for Reply

ReplyReply



To simplify this interaction, we provide in the Kafka project that

supports this Lab a SyncPoint classe that can be used by the

thread that receives the client request to wait for the reply, and

by the Kafka consumer thread to deliver the result of the

operation to the waiting thread.

This class also offers mechanisms that allow to ensure that clients

do not interact with a replica that are outdated in relation to what

the client has previously observed from the system. This will be

discussed in more detail on the theoretical lectures.

Like the Discovery, this class will have to be accessible both to the

REST Resources class and the Kafka Consumer class (you can

instantiate it in the Main of your Server(s), and pass as an

argument in the constructor of classes that need access to it)


KAFKA: ASYNCHRONY AND REST SERVERSClass SyncPoint (relevant methods)



This method should be used by the thread that received the request from the client to wait for the operation to

be ordered and delivered by kafka(and executed by the Consumer) to

obtain the reply that should be sent to to the client.

The argument is the sequence number of the record sent to Kafka as

shown in the previous example.



This method is used by the KafkaConsumer to store the result of an operation received from

Kafka (and executed by it).

The long n parameter is the sequence number of the record received from Kafka. The String res

should encode the HTTP response code to send back to the client (depending on the outcome of

the execution of the operation)


GOALS




• Kafka





in the project.

• Zookeeper





primary



ZOOKEEPER: DISTRIBUTED TUPLE SPACE

Apache Zookeeper is a popular system that provides an API to

enable storing (control) information in a reliable and strongly

consistent way on a hierarchical tuple space.

Some relevant aspects of zookeeper:

• Tuples have a unique name and optionally a value

associated. A tuple is named a znode in the zookeeper

nomenclature.

• Tuples are hierarchical like the directory structure of a file

system. You can have a tuple named ’zoo’; a child tuple

named ‘one’ whose complete name is ‘/zoo/one’

• You can watch for modifications in a znode (and all its

children) and be notified by zookeeper whenever a change

happens.


ZOOKEEPER: DISTRIBUTED TUPLE SPACE

In the context of the project one of the variants of replication

that you can build is primary/secondary, where there is a

leader that is responsible for executing operations, having all

replicas act as a backup to the primary.

However, when the primary fails, one of the secondary replicas

must take its place an become the new primary. Evidently only

one of the replicas can become the new primary.

This is an instance of the “leader election” problem, and

zookeeper can be used to address this problem in practice (for

most fault scenarios).


ZOOKEEPER: PROGRAMMING (PRELIMINARIES)

There is an Eclipse Java Project in the course web page that

has the examples that are going to be presented in this section

of the Lab.

The project name is: sd2021-aula10-zookeeper



You need to add maven dependencies to use Zookeeper in

your project (file pom.xml):

In the <dependencies> section:<dependency>

<groupId>org.apache.zookeeper</groupId>

<artifactId>zookeeper</artifactId>

</dependency>

In the <dependencyManagement> section and within the

<dependencies> subsection:<dependency>

<groupId>org.apache.zookeeper</groupId>

<artifactId>zookeeper</artifactId>

<version>3.4.11</version>

</dependency>



To use and interact with Zookeeper its server to be executing.

In the project you have script files for Linux/Mac and Windows

that execute a docker container with Zookeeper ready for use

in either your local machine (address localhost) and in the

context of the SD project tester (under the name kafka).

Linux/Mac: start-kafka.sh

Windows: start-kafka.bat

Notice that the script is the same as for Kafka, since

Kafka also requires Zookeeper to run, we have both

system executing in the same container (the port to

contact Zookeeper however is different)


GOALS




• Kafka





in the project.

• Zookeeper





primary



KAFKA: PROGRAMMING (CREATE A TUPLE)

To show how you can create Tuples (i.e., a znode) on Zookeeper,

we will use a simple application (main) that serves only as an

example.

In your project your own servers are going to be responsible for

creating and reading znodes from Zookeeper and there is no need

for new classes with a main for this purpose.

The Javadoc of Zookeeper (for version 3.7.0) can be found in:

https://www.javadoc.io/doc/org.apache.zookeeper/zookeeper/3.4.

11/index.html

https://www.javadoc.io/doc/org.apache.zookeeper/zookeeper/3.4.11/index.html


ZOOKEEPER: PROGRAMMING (CREATE A TUPLE)Class Writer (Example with Main)


Class Writer (Example with Main)

ZOOKEEPER: PROGRAMMING (CREATE A TUPLE)

The code creates a persistent znode(without a valueassociated) and a child znode that is

ephemeral to which it associates

a value.




This is simple codefor asking the user

to provide thename of the

znode that it willcreate and the

value to store in the internal znode

that will becreated.




The ZookeeperProcessor class is an auxiliary class that we will use to interact with

Zookeeper (we will see its code in a bit).

The argument, similar to Kafka, is a string containing the location of zookeeper servers (pairs hostname:port separated by commas)




This method is creating a znode as indicated by the user input. This znode has no value

associated and it PERSISTENT

PERSISTENT means that this znode will continue to exist even if the process that

created it stops (or crashes)




This method is creating a znode as indicated by the user input. This znode has no value

associated and it PERSISTENT

PERSISTENT means that this znode will continue to exist even if the process that

created it stops (or crashes)

Since znodes must have unique names

this method might fail if the znode already

exists (the write method returns null in that case otherwise it returns the name of the created znode)




This method is creating a child znode of the previous one (hence its path starts with the

name of the previous znode)




This method is creating a child znode of the previous one (hence its path starts with the

name of the previous znode)

It also associates a value to this znode, meaning that the Zookeeper server will store the

contents of value associated to this znode




The creation mode is EPHEMERAL_SEQUENTIAL.There are two implications here:

EPHEMERAL: Means that this zone will only exist while the connection of this process to zookeeper remains open. If this process closes its connection,

terminates, or crashes, Zookeeper will automatically remove this znode.




The creation mode is EPHEMERAL_SEQUENTIAL.There are two implications here:

SEQUENTIAL: Means that the name of the znode will be generated by Zookeeper by appending a

sequential number to the end of the znode name provided in this call. This makes sure that a znode will

always be possible to create.

The numbers used to name znodes that are meanwhile removed are not reused.



Class ZookeeperProcessor (Preamble)



This is the constructor of the ZookeeperProcessor class.

It instantiates a Zookeeper class which is the class in the Zookeeper Java API that is used to interact with the Zookeeper server.

The first argument is the String containing server information, the second is the session timeout (in milliseconds) and the third is a class that implements the interface Watcher.




The Watcher interface has a singe method:void process(WatchedEvent event)

This will be called to handle asynchronous events issued by Zookeeper (for instance when the contents/childs of a watched znode change)


https://www.javadoc.io/static/org.apache.zookeeper/zookeeper/3.4.11/org/apache/zookeeper/WatchedEvent.html



Class ZookeeperProcessor (write methods)




These methods both create a znode.

The only difference is that the first does not associate any data to the created znode, while the second does.




To create a znode we use the create method of the Zookeeper class.

The arguments are in order: i) the name of the znode (complete name that must start with / )ii) the value to associate with the znode (or null if no value is to be associated)

iii) the access control list of the znode (here we use the UNSAFE default that allows all to read and modify the znode)

iv) the mode associated with the created znode (PERSISTENT or EPHEMERAL_SEQUENTIAL)


GOALS




• Kafka





in the project.

• Zookeeper





primary



ZOOKEEPER: PROGRAMMING (READING CHILDS OFTUPLE)

Class GetChildren



Class GetChildren

This is a simple example that reads the childs of a znode (whose name is indicated by the user) and keeps monitoring that znode (and their

children) for changes.



This is simple code for asking the user to

provide the name of the znode to read and

to monitor

Class GetChildren



Class GetChildren

The ZookeeperProcessor class is an auxiliary class that we will use to interact with Zookeeper (we will see its code in a bit).

It is the same we used in the previous example



Class GetChildren

The method getChildren reads a List containing the name of all child znodes of the znode whose name is provided as value to the path

argument (the return value is being ignored). The second argument is a class that implements the Watcher

interface (defined here inline)



Class GetChildren

Whenever a change occurs to the contents of the watched znode (including changes in its children) an event will be

issued by zookeeper and the process method of the watcher executed.

In this example the watcher only reads and prints the list of child znodes.



Class GetChildren

The application blocks waiting for user input, such that you can execute the example and see the changes on the child

znodes as writers start and stop.



Class ZookeeperProcessor (read methods)



These are the methods to read the childs of a znode and a default Watcher (that only prints the event received from

Zookeeper)




The only difference between the two variants of the getChildren method is the existence of a Watcher, that

indicates to Zookeeper if we want to be notified of changes in the read znode or not.




To read the childs of a znode we use the getChildren method of the Zookeeper class.

The arguments are: i) the name of the znode to read (must start with / )ii) the watcher to receive notifications or false if no monitoring of the znode is necessary




To read the childs of a znode we use the getChildren method of the Zookeeper class.

The arguments are: i) the name of the znode to read (must start with / )ii) the watcher to receive notifications or false if no monitoring of the znode is necessary


The Zookeeper class also has methods to access data associated with a

znode (if any).

You can check the documentation for that.


ZOOKEEPER: PROGRAMMING (EXECUTING EXAMPLES)You can test the examples provided in eclipse.

To do so do the following steps:

1. Start the Kafka container as show before in localhost mode

2. Launch one Writer and provide a znode (e.g., /SD) just to

create that znode (the value is irrelevant)

3. Launch the GetChildren (in eclipse) and provide the same

znode, the process will be watching for changes

4. Launch a second Writer (in eclipse) and provide the same

znode as you did initially

5. You can more copies of the Writer to see more changes and

increasing sequence numbers.


GOALS




• Kafka





in the project.

• Zookeeper




• Understand how Zookeeper can be used to (dynamically) elect

a primary



ZOOKEEPER: LEADER ELECTION

The idea is that you will use Zookeeper (if you select that option) to

elect the primary of a set of replicas for a given domain (and to

pick a new one when the previous primary fails).

How can you do this:

1. Each domain should have a persistent znode with the name

being the domain itself.

2. Each replica, when it start, creates a child znode on its domain

znode for itself. The child znode should be ephemeral and have

names with a sequential identifier.

3. Every replica reads and watches the znode for their domain.

The primary replica is the one whose child znode is the first

within the domain znode.

4. You can store control information in znodes if you need.


GOALS




• Kafka





in the project.

• Zookeeper





primary



PROJECT REVISION AND EXERCISE

1. Use what you have learned in this class to complete your project

by supporting replication in your original REST servers.

Remember that you have multiple implementation alternatives as

specified in the project web page:

• Alternative 1: Replication using Kafka

• Alternative 2a: Replication based on Primary/Secondary (with a

fixed Primary)

• Alternative 2b: Replication based on Primary/Secondary using

Zookeeper to select the Primary


QUICK OVERVIEW OF REPLICATION

• The goal in the project is to replicate the Spreadsheet server

within any domain (We assume that there is a single server for

Users in each domain that never fails as in the first project).

• Depending on the replication solution that you adopt, you will

need to handle write operations (those that change the state of

the service) in a different way.

• In the following we discuss the workflow of these operations for

each of the alternatives.


REPLICATION USING KAFKA

fct192.168.1.2

REST

Spreadsheets:...

sara@fct

fct192.168.1.3

REST

Spreadsheets:... fct

192.168.1.4

REST

Spreadsheets:...

Kafka



sara@fct

Kafka

fct192.168.1.2

REST

Spreadsheets:...

fct192.168.1.3

REST


192.168.1.4

REST

Spreadsheets:...



In your REST resources you must divide each operation that you

might receive from a user client or a server from another domain

in two parts:

1. The first part is the REST endpoint itself that will receive the

operation, publish it to Kafka, wait for the reply, and send the

response back to the client (either a user or the server from

another domain)

2. The second part will be called by the KafkaConsumer when it

receives the operation from Kafka, this should store the

response in the SyncPoint for the response to be possible to

be sent to the client.

Typically, you will have a topic per domain, you can use Records

with Key (the key can be the operation) the value can be any Java

object encoded in Json (with Gson)


REPLICATION USING PRIMARY/SECONDARY(FIXED PRIMARY)

sara@fct

fct192.168.1.2

REST

Spreadsheets:...

fct192.168.1.3

REST


192.168.1.4

REST

Spreadsheets:...



sara@fct

A replica will know if it is the primary according to

parameters passed to the main of the server by our tester

(check the project webpage for details)

fct192.168.1.2

REST

Spreadsheets:...

fct192.168.1.3

REST


192.168.1.4

REST

Spreadsheets:...



sara@fct

Send HTTP 307: TEMPORARY REDIRECT with the equivalent URL to the request issued by the client but to the primary (with the IP of the primary)

fct192.168.1.2

REST

Spreadsheets:...

fct192.168.1.3

REST


192.168.1.4

REST

Spreadsheets:...



sara@fct

Send HTTP 307: TEMPORARY REDIRECT with the equivalent URL to the request issued by the client but to the primary (with the IP of the primary)

fct192.168.1.2

REST

Spreadsheets:...

fct192.168.1.3

REST


192.168.1.4

REST

Spreadsheets:...

throw new WebApplicationException(Response.temporaryRedirect(URI.create("https://...")).build());



sara@fct

fct192.168.1.2

REST

Spreadsheets:...

fct192.168.1.3

REST


192.168.1.4

REST

Spreadsheets:...



In your REST resources you must divide each operation that you

might receive from a user client or a server from another domain

in two parts:

1. The first part is the REST endpoint itself that will receive the

operation and call the execution endpoints on the local server

and all other replicas, wait for the reply from everyone, and

send the response back to the client (either a user or the

server from another domain)

2. The second part will be in an internal REST endpoint and is

called by the primary (and only by the primary) to execute

operations that he received from user clients or servers from

other domains.


REPLICATION USING PRIMARY/SECONDARY + ZOOKEEPER

sara@fct

Zookeeper

fct192.168.1.2

REST

Spreadsheets:...

fct192.168.1.3

REST


192.168.1.4

REST

Spreadsheets:...



sara@fct

Zookeeper

fct192.168.1.2

REST

Spreadsheets:...

fct192.168.1.3

REST


192.168.1.4

REST

Spreadsheets:...



sara@fct

Zookeeper

Send HTTP 307: TEMPORARY REDIRECT with the equivalent URL to the request issued by the client but to the primary

(with the IP of the primary)

fct192.168.1.2

REST

Spreadsheets:...

fct192.168.1.3

REST


192.168.1.4

REST

Spreadsheets:...

throw new WebApplicationException(Response.temporaryRedirect(URI.create("https://...")).build());



sara@fct

Zookeeper

Same as in the previous Primary/Secondary Example

fct192.168.1.2

REST

Spreadsheets:...

fct192.168.1.3

REST


192.168.1.4

REST

Spreadsheets:...



sara@fct

Zookeeper

fct192.168.1.2

REST

Spreadsheets:...

fct192.168.1.4

REST

Spreadsheets:...



Like the Primary/Secondary, but the Primary might swap from

replica to replica, and you must adapt the execution of your

system accordingly.


WHAT ABOUT READ OPERATIONS

• Read operations can follow the same path of write operations,

but this will make read operations very slow.

• Alternatively, read operations can be handled by a single (any)

replica, as far as the returned value is at least as up-to-date as

the last value observed by the client issuing the request.

• This can force the a spreadsheet server to wait before replying

to the client if he becomes aware the client as seen/wrote a

version after the one currently stored in that server.

• To do this check operations (both write and reads) might need

to pass additional control information in all replies sent to

clients in the form of an additional header (whose name should

start with sheetsserver).

• More information in the theoretical lectures.


PROJECT REVISION AND EXERCISE

1. Use what you have learned in this class to complete your project

by supporting replication in your original REST servers.

Remember that you have multiple implementation alternatives as

specified in the project web page:

• Alternative 1: Replication using Kafka

• Alternative 2a: Replication based on Primary/Secondary (with a

fixed Primary)

• Alternative 2b: Replication based on Primary/Secondary using

Zookeeper to select the Primary PICK ONLY ONE OF THE REPLICATION ALTERNATIVES

redes de suporte de sistemas distribuídos · distributed systems 20/21 –di/fct/nova / 2 goals in...

Documents