of distributed file system hierarchies. Our approach maintains both the advantages of peer-to-peer synchronization with the cloud-based approach that stores a ...
Cloud-based Synchronization of Distributed File System Hierarchies Sandesh Uppoor∗ , Michail D. Flouris∗ , and Angelos Bilas∗† ∗
Foundation for Research and Technology - Hellas (FORTH) Institute of Computer Science (ICS) 100 N. Plastira Av., Vassilika Vouton, Heraklion, GR-70013, Greece † Department of Computer Science, University of Crete P.O. Box 2208, Heraklion, GR 71409, Greece {suppoor, flouris, bilas}@ics.forth.gr Abstract—As the number of user-managed devices continues to increase, the need for synchronizing multiple file hierarchies distributed over devices with ad hoc connectivity, is becoming a significant problem. In this paper, we propose a new approach for efficient cloud-based synchronization of an arbitrary number of distributed file system hierarchies. Our approach maintains both the advantages of peer-to-peer synchronization with the cloud-based approach that stores a master replica online. In contrast, we do not assume storage of any user’s data in the cloud, so we address the related capacity, cost, security, and privacy limitations. Finally, the proposed system performs data synchronization in a peer-to-peer manner, eliminating cost and bandwidth concerns that arise in the ”cloud master-replica” approach. Index Terms—File synchronization, data management, distributed storage, cloud service.
I. I NTRODUCTION Users increasingly depend on electronic information that is processed and stored in a multitude of computers and storage devices, connected by both wired and wireless networks. The number and type of devices, has increased recently due to the significant growth of affordable smart devices, as well as the quality and cost of the networking infrastructure. The increased number of devices and locations and the fact that many of these devices have limited storage capacities and exhibit ad hoc network connectivity, such as frequent offline operation and/or movement through different networks, introduce many challenges in managing user data distributed over multiple devices and many locations. One of the challenges in maintaining distributed user data is synchronizing replicated data sets between an arbitrary number of nodes. This is useful not only for backup purposes, but also for off-line operation, where a user with a device of limited capacity needs to selectively replicate part of a data set, modify it off-line and then re-synchronize with the main data set when networking conditions allow it. Currently there are two main approaches to the distributed synchronization issue, the user-controlled peer-to-peer synchronization and the cloud master-replica synchronization approach. In the first approach users install synchronization c 2010 IEEE 978-1-4244-8396-9/10/$26.00 ⃝
software, such as rsync [1], Unison [2] or Sync Butler [3] in all computers containing the data files and explicitly initiate a peer-to-peer synchronization whenever they need to synchronize their files. This is a ”manual” process requiring the user to provide the network addresses of all device(s), as well as the synchronization parameters, such as direction of the synchronization, which files to keep or overwrite, etc. Furthermore, most of these synchronization applications operate pair-wise, that is they synchronize only a pair of nodes each time. Managing synchronization for three or more file system hierarchies can be a cumbersome and error-prone process, especially for the average user without technical skills [2]. Finally, the synchronization software is usually not portable across operating systems, not automated (requires user intervention), and not suitable for small mobile devices with ad hoc connectivity. The second approach, cloud master-replica synchronization solves some of these issues by employing cloud services to automate synchronization and deal with the small mobile devices with ad hoc connectivity. In the approach followed by many cloud-based synchronization and backup services (e.g. [4], [5], [6], [7]), a master replica with all data to be synchronized is maintained as a central copy in the cloud, while all the user’s file systems synchronize and transfer updates to this central copy. This approach with one-way synchronization to the master replica in the cloud, offers increased availability and reliability in case of device failure(s), automates synchronization management and does not require technical skills. On the other hand, it makes the assumption that all user’s data will be stored online in the cloud. This is not only expensive, because cloud storage capacity costs, but also introduces important security and privacy concerns. Furthermore, it requires significant (upload) bandwidth between all replicas and the central copy in the cloud, which may be limited and/or expensive, while local, peer-to-peer connectivity between some of the replicas is cheap and high-speed (e.g. a laptop and a mobile phone synchronizing over a home LAN with limited upload bandwidth to the Internet). Note that the approaches mentioned above operate at the user level, and not in the operating system, as file systems do.
INTERNET
Fig. 1.
Cloud service and user devices.
Unfortunately, file systems that support replication and offline operation mandate the use of the specific file system, which is often not an option for users. In this paper, we propose a new approach for efficient cloudbased synchronization of distributed file system hierarchies, dealing with an arbitrary number of synchronization nodes. Our approach maintains both the advantages of peer-to-peer synchronization and the cloud-based master-replica approach. It does not assume storage of any file data in the cloud, so it addresses the capacity, cost, security, and privacy issues. Moreover, the proposed solution performs data synchronization in a peer-to-peer manner, eliminating cost and bandwidth concerns that arise in the ”cloud master-replica” approach. Our main contribution is the design of new algorithms and protocols that are more complex than the afforementioned approaches, but provide more benefits and less drawbacks. This paper presents the design of our system, Synchronizer. Since a system prototype is currently under development, we do not present implementation details, or evaluation results. The rest of this paper is organized as follows. Section II discusses the design of Synchronizer and how it addresses the associated challenges. Finally, we draw our conclusions and discuss future work in Section III. II. S YSTEM D ESIGN In our approach we assume a scenario where a user needs to synchronize a number of data files stored in the file systems of multiple devices (or nodes), each located in a different location with ad hoc connectivity. In the rest of this section, we consider the terms ”device” and ”replica” as synonymous. Also we denote the hierarchy of directories with many data files and sub-directories in a single file system as a filetree. For simplicity we will assume that a device (or replica) contains a single filetree to be synchronized. 1) Assumptions: Our synchronization scheme requires the use of metadata for every file in all devices. Metadata consists of file and directory information, i.e. file system metadata, as well as a cryptographic hash (e.g. SHA256) of a file’s data content. The hash is used to compare data across files, and to detect data modifications of a particular file in a filetree. Given a file f , its metadata is defined as M (f ) = { path (directory), name, size, creation time, last modification time, data hash} Besides the devices storing the filetrees, we assume a cloud service, i.e. a node in the Internet cloud that provides the synchronization services, as shown in Figure 1. This is necessary in order to automate synchronization, scale up to
any number of devices, and address the issues of devices with ad hoc connectivity. We also assume that the cloud service is able to connect and communicate with the devices over the Internet, when they are able to connect, and collect metadata of the filetrees from each device. Each device may periodically send updates for its filetree(s) to the cloud service, however, we do not make an assumption on the update model (push or pull), as long as the filetree metadata on the cloud service are updated frequently. 2) Initial synchronization: Before the initial step of our system we assume that the user has configured the cloud service with information on how to connect to the devices and which filetrees need to be synchronized. This can be done through a user-friendly user interface, such as a web interface. In order to retrieve the current filetree state, the cloud service connects to the devices and gets the updated metadata. Then, it calculates the file operations which need to be performed across replicas. First time, when a synchronization process is performed between filetrees of different nodes, there is no previous state stored in the cloud service, in contrast to the subsequent synchronization operations. In this initial step, we create the synchronization state by performing the basic synchronization algorithm between two filetrees, as detailed in the First Sync Algorithm (II-2). File operations in the algorithm, e.g. delete, rename, copy, are considered atomic. The copy operation used in the Algorithm II-2 refers to the transfer of a file from one replica to another. It can be either full file transfer when it is encountered as new, or transfer of just the modification when its encountered as modified. Rename refers to changing in name of an existing file, or moving it across directories within the same device. After the cloud service computes the operations for all files on all filetrees, it sends them to the replicas to be performed through the coordinated peer-to-peer networking protocol discussed in II-5. 3) Stateful synchronization: Once the initial operations sent by the cloud service have been executed on the replicas successfully, they are known to be in a synchronized state (or simply “sync state”), where all replicas have the same copy of data or filetree. This “sync state” of each replica computed by the initial synchronization is stored in the cloud service. Note that this state consists only filetree metadata, not data. Whenever a subsequent synchronization needs to be performed, the “diff sync state”, i.e. the changes to the filetree since the previous sync, can be obtained as a difference of the stored previous sync state and current filetree state read from the replica. For a replica A, PA = previous sync state of A CA = current state of A DA = diff state of A DA = CA - PA The diff states of replicas are carefully analyzed to detect individual changes to files. A “file change” refers to either a file content modification, a file rename, a file creation or
Algorithm 1 First Sync for two filetrees. Let F TA and F TB be two filetrees, on nodes A and B respectively. d refers to a directory name (absolute path from root of FT), f to a file name (within a directory), and hash(f ) to the hash of a file’s data. for d in F TA do if d′ exists in F TB , such that d == d′ then for f in d do if f ′ does not exist in d′ , such that f ′ == f then f is a new file to be copied to d′ else if f ′ exists in d′ , such that f ′ == f then if hash(f ) != hash(f ′ ) then file f exist but is modified if fT imestamp > fT′ imestamp then copy modification to f ′ else copy modification to f end if else if hash(f ) == hash(f ′ ) then same file f exist unmodified end if else if f ′′ exists in d′ , such that hash(f ′′ ) == hash(f ) then file f exists in F TB with same content but different name if fT imestamp > fT′′imestamp then rename f ′′ to name(f ) else rename f to name(f ′′ ) end if end if end for else create d in F TB and copy all files in d to F TB end if end for
a file deletion, with respect to its previous sync state. In a diff state of a replica, the diff state of each file can be in one of five different types: modified, renamed, deleted, new or unmodified. The detection of file changes in a replica and the computation of diff state is described in Algorithm II-3: File classification. 4) Conflict detection and handling: When a file is modified in one or more replicas, we need to find the latest version of the file and propagate it to the other replicas. The case of a file being independently modified in more than one replicas, is considered a conflict between file versions. Detecting the correct version of the file in the case of conflicts is difficult and dangerous. An incorrect decision in the case of a conflict will result in data loss, since the correct file version is overwritten with another. In many cases, resolving the ambiguity of a conflict requires user intervention and merging of files at the application level (e.g. a document independently modified in
Algorithm 2 File classification. Let PA ,PB ,PC be the previous sync states, and CA ,CB ,CC the current states of replicas A, B and C respectively. Let DA ,DB ,DC be the diff states between the previous sync state and current state of each replica. Modified Renamed be the set of Modified files, DA the set of Let DA New Delete Renamed files, DA the set of New files, and DA the set of Deleted files in replica A after a previous sync. for node X in A, B, C do for file f in CX and f ′ in PX , such that f ′ == f do if hash(fCX ) != hash(fP′ X ) and name(fCX ) == name(fP′ X ) then Modified f is classified as Modified !→ DX else if name(fCX ) != name(fP′ X ) and hash(fCX ) == hash(fP′ X ) then Renamed f is classified as Renamed !→ DX else if f is not in PX then New f is classified as New !→ DX else if f ′ is not in CX then Delete f is classified as Deleted !→ DX else f is unmodified end if end for end for two replicas may contain changes in different parts of it that need to be merged using a word processing application). Most existing synchronization applications or cloud services require user intervention for resolving conflicts, or just keep all file versions with different file names [2], [4]. State of F TX /F TY Modified Renamed Deleted
Mod Mod-Mod Ren-Mod Del-Mod
Ren Mod-Ren Ren-Ren Del-Ren
Del Mod-Del Ren-Del —
TABLE I C ONFLICT TYPES .
Conflicts can be categorized in four types, as shown in Table I. The diff state of any two replicas is shown in each dimension in Table I, while the conflict category depends on the independent changes made to a file in each replica. Our algorithm is able to detect all conflicts, however, due to lack of space we only present part of it in Algorithm 3, that detects a Mod-Mod conflict. A conflict of type Mod-Mod refers to modifications done to a file f independently in two or more replicas. Conflict resolution is an important component in every synchronization system. Our approach offers two alternatives, ”Manual” or ”Auto” mode. Manual mode requires user input in selecting which file(s) to keep, whereas Auto mode provides the option of setting up some conflict resolution policies. The current options for policies are: (i) Keep the most recent
Algorithm 3 Mod-Mod conflict detection. Modified for f in DA do Modified Modified if f in DB or f in DC then f is in Mod-Mod Conflict end if end for
Replica A
Replica B
Cloud Service
Replica A (Master) Phases 1,4 Replica B Fig. 3.
Replica D Fig. 2.
Replica C
Peer-to-peer replica synchronization.
version depending on timestamps, (ii) Keep all conflicted file versions with different names. Once all conflicts are resolved, either via manual or auto mode, the cloud service starts computing the operations to be performed by the replicas. 5) Update propagation: Before discussing processing of conflict-free sync state, it is important to discuss the planned propagation of file operations to the replicas. The user is likely to have updated files in many replicas, so the source of file updates is usually not a single replica, but several replicas. In this case, communication may become complex, because it involves transferring files between all replicas. An example with 4 replicas is shown in Figure 2, where updates from each replica should be propagated to all other replicas. This requires all-to-all communication, which is impractical with firewalls between replicas, and increases protocol complexity to handle ad hoc communication between replicas (i.e. failures). Instead of all-to-all communication, we consider an approach where one replica acts as the master or coordinator. Thus when calculating the update operations between all replicas, we consider one replica as the master and batch all update operations to phases, where each phase batching operations between the master and one other replica. Due to lack of space we omit details of processing the diff state of filetrees and performing optimizations to save network bandwidth, for example in the case of renamed files or directories. We only describe a summary of the process using phases between the coordinator and the rest of the replicas. All operation phases are computed in the cloud service and then sent to the master replica for performing peer-topeer synchronization between all replicas. To propagate all the updates and to attain a complete sync state with each replica, we need two rounds of communication with the master replica. An example of the first round is shown in Figure 3. As shown, when phase 1 is executed between the master replica A and replica B, all updates from B are propagated to A hence at the end, replica A contains updates of A+B. Similarly, after phase 2 is executed with master replica, all A+B updates from master is propagated to C and updates from C is propagated to master, which at the end will contain updates A+B+C. After the master replica executes the first round of phases
2,5
Replica C
3,6 Replica D
Synchronization with a master replica.
with all replicas i,e. phases 1, 2 and 3, during which, all replicas propagate the latest version of updates to the master replica, the master will contain the latest versions of all files and directories in all replicas. During the second round of phases, i.e. phases 4, 5 and 6, the latest versions of files and directories from the master replica are propagated to the rest. So, for example, when the master replica containing A+B+C+D executes phase 4, all updates from C and D are propagated to B, but there is no updates from B to master replica since it has already been propagated in first round in phase 1. In case any replica is unreachable or fails during the propagation of updates, the process is aborted and operations are recalculated in the cloud service without the faulty replica. This is necessary to avoid overwriting a newer file version with an older file, and is orthogonal to the communication scheme used (coordinated or all-to-all file update protocol). III. C ONCLUSIONS In this paper, we propose a new approach for efficient cloudbased synchronization of an arbitrary number of distributed file system hierarchies. Our approach maintains both the advantages of peer-to-peer synchronization with the cloudbased approach that stores a master replica online. In contrast, we do not assume storage of any user’s data in the cloud, so we address the related capacity, cost, security and privacy limitations. Finally, the proposed system performs data synchronization in a peer-to-peer manner, eliminating cost and bandwidth concerns that arise in the ”cloud mastercopy” approach. Since a system prototype is currently under development, we do not present implementation details, or evaluation results. ACKNOWLEDGMENTS We thankfully acknowledge the support of the European Commission under the 7th Framework Programs through the FP7 ITN project SCALUS (contract no 238808). R EFERENCES [1] A. Tridgell, “Efficient algorithms for sorting and synchronization,” 2000. [2] B. C. Pierce, J. Vouillon, and J. Vouillon, “What’s in unison? a formal specification and reference implementation of a file synchronizer,” tech. rep., 2004. [3] “Sync Butler.” http://code.google.com/p/syncbutler. [4] Drew Houston and Arash Ferdowsi, “Dropbox.” www.dropbox.com. [5] CodeDroids, “OneSync.” http://onesync.googlecode.com. [6] Siber Systems Inc., “GoodSync.” http://www.goodsync.com/support/manual. [7] L. Yecies and D. Mihovilovic, “SugarSync.” https://www.sugarsync.com/.
