Distributed Backup System.Net

Transcription

1 Distributed Backup System.Net world can now backup for free... AUTHORS Martina Babini Guido Angelo Ingenito

2 vision Since disks are cheap, backup must be cheap too! Obviously backup locally your data is not enough to protect them from: virus, fire, flood, power surge, robbery... You should send your files to peers so if a catastrophe strikes your area, you can recover data from surviving peers!

3 technologies DBS.Net Network Discovery.NET Remoting Web Services MSMQ Microsoft Framework.NET Microsoft Framework.Net v.2.0 MSMQ: Microsoft Message Queuing.NET Remoting Web Services

4 data threats On etherogeneous context data must be treated in different ways and its backup must substantially grant: integrity, durability, authenticity. Enterprise and public administration use expensive applications, in most cases connected to outsourced data centers. The aim of DBS.Net is to offer the same features in a less expensive way using the spread opportunities offered by peer to peer networks.

5 backup structure Data Files Chunks Replication Metadata Time: Life Cycle A backup contains: N files A replication level R Defines on how many peers will store the j-th chunk; A life cycle Defines how long a backup must be stored on other peers. Metadata Check sum, compression, encryption, digest, signature,...

6 backup process N Given a backup of N files: 1.Each file is splitted in C chunks; 2.Each chunk is compressed, encrypted, signed and stored locally (producer consumer); 3.Each file is sent over the network R times. Every phase adds its metadata (pipe). R

7 applicative architecture DBS.Net is a PCE application: Presentation Control Entities a. The presentation layer uses and extends the base platform graphical entities providing an intuitive UI (callbacks). b. The control layer offers multithreading support to the other application layers through the definition of commands and tasks (scheduler). c.the entity layer offers common domain objects (abstraction layer). Every layer uses the Microsoft Enterprise Pattern & Practices application building blocks for logging.

8 network architecture WS The network layer has been implemented through a component model approach: Remoting a. The usage of MSMQ provides the support for messages and protocol implementations; b. The discovery architecture is inter-changeable at runtime using: SOA or.net Remoting. A defined abstraction layer of classes and interfaces through the dynamic assembly loading offers the possibility for developers to extend and provide their own discovery implementations.

9 network discover y Each peer can act as a simple peer or as a relay: a. In the first case the peer asks to known relays informations about other peers in the neighborhood. b. In the second case the relay can be directly addressed on the network, so it can reply to other peers with the informations it has collected about other peers. Each query performed on a relay peer has also the possibility to specify a search pattern specifying for example the location of searched peers. Informations about relay peers are stored locally to each peer through the usage of an object oriented database.

10 web ser vices DBS.Net uses the power of web services to define one of its modules for network discovery: a. The client, called PeerResolverClient, is defined, as the other modules, in an external DLL and loaded on demand; b. The discovery web service, called PeerResolver, is automatically loaded into the web server IIS if the end-user chooses to left its DBS.Net client act as a relay. Discovery through Web Service is auspicable in context where firewalls doesn t allow other protocols rather than http.

11 web ser vices The PeerResolver data access has been implemented through a Provider Pattern. Through the use of Reflection and Dynamic Assembly Load ondemand can be used the SqlDataProvider rather than the DefaultDataProvider (in-memory table). In DBS.Net every customizable parameter on both server and client side is specified through an XML configuration file.

12 .net remoting Another module for network discovery is realized using.net Remoting Framework: the client, PeerClient, is defined in an external DLL and loaded on demand on a peer. It retrieves first the remoting object and then performs operations using it; a listener server that registers the channel and the service type; the remoting object is a singleton object, passed by reference: it is a singleton object because is necessary to keep state information between different clients.

13 .net remoting Our default implementation uses a channel TCP to communicate. TCP channels are the best way, in remoting, to work inside a LAN, because they uses: a binary formatter for data; sockets to communicate between machines that grant a better optimization and less overhead in this scenario.

14 .net remoting To use.net remoting over the Internet, is better to use an implementation that communicates through an HTTP channel and SOAP protocol as well as Web Services. Remoting objects exposed in this way are as easy to configure as web services hosting them in IIS. The client will then read WSDL file of this object to communicate with it using SOAP.

15 msmq Sending Sending Application Application Message Queue Receiving Application MSMQ is a message oriented middleware that: enables applications running at different times to communicate across heterogeneous networks; provides guaranteed message delivery, efficient routing, security, and prioritybased messaging. DBS.Net uses MSMQ to implement its fundamentals communication strategies between peers.

16 backup protocol Chunk Response received phase: Ask Backup for free send space phase green is green a chunk positive received response message phase red means red a negative chunk not response received

17 restore protocol Response phase: Ask for backup green Ok to is start a positive Sending retrieve response phase red is a message negative phase response A peer that sends a positive response sends also an information about chunks that it has.

18 protocol properties The first phase of each protocol is a lookup phase used also to check which peer is really reachable or not. Negative messages are thought to let peers going on with their work without wasting time in waiting for responses.

19 properties Reliability: granted by MSMQ, if a chunk was delivered well it would be certainly stored on the destination peer. Security: only encrypted and signed data is sent on the Internet. QoS: due to our protocol a peer that receives a confirmation message can be sure that its message was delivered.

20 properties Modularity: it was built to be as modular as possible with a great attention on network modules that could easily changed. Network fault tolerance: the peer resolver has a timer that cleans its list of available peers after a time slice. This feature assures to a peer that the peer list it receives contains only really connected ones.

21 properties Autenticity: when a peer asks for a backup to another one has to send a signed token containing its id to allow the other one to check if he is really the backup owner. Resources management: the backup expiration date allows a peer to delete an expired backup and free storage space for other peers.

22 expansion points extension of the backup chunk concepts to be able to realize an incremental backup; network analyzer to module network traffic according to bandwidth usage; user interface improvements; integration with third party applications.