Changeset 5050
- Timestamp:
- Sep 13, 2005, 5:24:45 PM (21 years ago)
- Location:
- trunk
- Files:
-
- 3 edited
-
Nebulous-Server/docs/design.txt (modified) (1 diff)
-
Nebulous/docs/design.txt (modified) (1 diff)
-
Nebulous/lib/Nebulous/Client/QuickStart.pod (modified) (2 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/Nebulous-Server/docs/design.txt
r5045 r5050 1 1 # Copyright (C) 2004-2005 Joshua Hoblitt 2 2 # 3 # $Id: design.txt,v 1.3 2005-09-14 00:46:58 jhoblitt Exp $ 3 # $Id: design.txt,v 1.4 2005-09-14 03:24:45 jhoblitt Exp $ 4 5 Abstract 6 -- 7 8 Nebulous is a user-space distributed object (file) storage system. It is much 9 more a database of where objects are stored then a filesystem in the 10 traditional sense. Nebulous is considered distributed because of it's data 11 storage model, where objects are stored across a number of storage volumes and 12 may have redundant copies. While IPC is done in the traditional client/server 13 model with a single[1] centralized server containing all storage object 14 meta-data. This system was designed, unlike most distributed filesystems, 15 specifically so that clients have the option of hosting one or more storage 16 volumes. Although, if you so choose, clients and storage volumes can reside 17 on independent hardware. Above all else, Nebulous is designed to make 18 efficient use of both disk and network bandwidth. 19 4 20 5 21 Overview 6 22 -- 7 23 8 Nebulous is a user-space distributed object (file) storage system. The system9 is distributed in the sense of it's data storage model where objects are stored10 across a number of storage volumes and may have redundant copies. While IPC11 is done in the traditional client/server model with a single[1] centralized12 server containing all storage object meta-data. This system was designed,13 unlike most distributed filesystems, specifically so that Nebulous clients14 could also host one or more storage volumes. Although, there is no requirement15 that clients also provide storage space. If you so choose, clients and the16 storage volumes can reside on independent hardware.17 18 24 There are 4 principle components required for a working Nebulous system; 19 server, client, data transport, and data storage. The Nebulous system only 20 provides the server and the client software. Data transport[2] and Data 21 storage are left to 3rd party software packages. As this function is typically 22 included with most operation system it is unlikely that those specific 23 technologies can be improved upon. 24 25 A centralized server model was used to allow efficient use of 'like' searches 26 on storage object names. The current 'best' technique for a distributed 27 metadata store is with distributed hash tables. Unfortunately, no widely 28 available DHT implementation allows 'like' searches on key names. 25 server, client, data transport, and data storage. The Nebulous software 26 distribution provides only the server and the client software. Data 27 transport[2] and Data storage are left to 3rd party software packages. As 28 those functionalities are typically included with most operation system. 29 Instead, Nebulous build upon and benfits from advances made in those 30 technologies. 31 32 Server 33 -- 34 35 The server is responsible for keeping track of storage objects, all instances 36 of that object, and enforcing locking semantics. Extensive logging and 37 tracing support is provided for debug and to allow for statics generation and 38 possible X<hotspot> optimization. 39 40 Nebulous uses a centralized server model. This model was choosen because it 41 allows efficient X<pattern matching> of storage object names. The current 42 'best' technique for a distributed metadata store is with distributed hash 43 tables. Unfortunately, no widely available DHT implementation allows efficent 44 I<pattern matching> of key names. 45 29 46 30 47 [1] Multiple Nebulous servers should be possible via database replication. -
trunk/Nebulous/docs/design.txt
r5045 r5050 1 1 # Copyright (C) 2004-2005 Joshua Hoblitt 2 2 # 3 # $Id: design.txt,v 1.3 2005-09-14 00:46:58 jhoblitt Exp $ 3 # $Id: design.txt,v 1.4 2005-09-14 03:24:45 jhoblitt Exp $ 4 5 Abstract 6 -- 7 8 Nebulous is a user-space distributed object (file) storage system. It is much 9 more a database of where objects are stored then a filesystem in the 10 traditional sense. Nebulous is considered distributed because of it's data 11 storage model, where objects are stored across a number of storage volumes and 12 may have redundant copies. While IPC is done in the traditional client/server 13 model with a single[1] centralized server containing all storage object 14 meta-data. This system was designed, unlike most distributed filesystems, 15 specifically so that clients have the option of hosting one or more storage 16 volumes. Although, if you so choose, clients and storage volumes can reside 17 on independent hardware. Above all else, Nebulous is designed to make 18 efficient use of both disk and network bandwidth. 19 4 20 5 21 Overview 6 22 -- 7 23 8 Nebulous is a user-space distributed object (file) storage system. The system9 is distributed in the sense of it's data storage model where objects are stored10 across a number of storage volumes and may have redundant copies. While IPC11 is done in the traditional client/server model with a single[1] centralized12 server containing all storage object meta-data. This system was designed,13 unlike most distributed filesystems, specifically so that Nebulous clients14 could also host one or more storage volumes. Although, there is no requirement15 that clients also provide storage space. If you so choose, clients and the16 storage volumes can reside on independent hardware.17 18 24 There are 4 principle components required for a working Nebulous system; 19 server, client, data transport, and data storage. The Nebulous system only 20 provides the server and the client software. Data transport[2] and Data 21 storage are left to 3rd party software packages. As this function is typically 22 included with most operation system it is unlikely that those specific 23 technologies can be improved upon. 24 25 A centralized server model was used to allow efficient use of 'like' searches 26 on storage object names. The current 'best' technique for a distributed 27 metadata store is with distributed hash tables. Unfortunately, no widely 28 available DHT implementation allows 'like' searches on key names. 25 server, client, data transport, and data storage. The Nebulous software 26 distribution provides only the server and the client software. Data 27 transport[2] and Data storage are left to 3rd party software packages. As 28 those functionalities are typically included with most operation system. 29 Instead, Nebulous build upon and benfits from advances made in those 30 technologies. 31 32 Server 33 -- 34 35 The server is responsible for keeping track of storage objects, all instances 36 of that object, and enforcing locking semantics. Extensive logging and 37 tracing support is provided for debug and to allow for statics generation and 38 possible X<hotspot> optimization. 39 40 Nebulous uses a centralized server model. This model was choosen because it 41 allows efficient X<pattern matching> of storage object names. The current 42 'best' technique for a distributed metadata store is with distributed hash 43 tables. Unfortunately, no widely available DHT implementation allows efficent 44 I<pattern matching> of key names. 45 29 46 30 47 [1] Multiple Nebulous servers should be possible via database replication. -
trunk/Nebulous/lib/Nebulous/Client/QuickStart.pod
r5047 r5050 3 3 =head1 NAME 4 4 5 Nebulous::Server::QuickStart - Nebulous QuickStart Guide5 Nebulous::Server::QuickStart - Nebulous QuickStart Guide 6 6 7 7 =head1 Perl CLIENT … … 77 77 PKG_CHECK_MODULES([NEBCLIENT], [nebclient >= 0.0.1]) 78 78 79 This Will setup the variables C<NEBLCLIENT_CFLAGS> and C<NEBCLIENT_LIBS> for79 This will setup the variables C<NEBLCLIENT_CFLAGS> and C<NEBCLIENT_LIBS> for 80 80 you and C<AC_SUBST()> them. 81 81
Note:
See TracChangeset
for help on using the changeset viewer.
