Let's talk about NAS first. In a typical NAS setup you will have a NAS server which exposes a single namespace and control point for business objects. Sounds perfect but there are inherent drawbacks with NAS technology where there is high data-transfer involved. Since NAS runs on high-latency TCP/IP protocol, LAN performance suffers when there is heavy data flow. NAS, though, has an advantage that it allows data stored on NAS file shares or filesystems to be shared across clients.
The above scenario reverses in the case of SAN. In SAN client and storage are connected via short-I/O paths and as a result is a technology of choice for data-transfer intensive applications. However, SAN does not allows data to be shared among clients. If client wants to shared data stored on SAN they will have to coordinate among themselves on their own.
As you can see both NAS and SAN suffers from drawbacks this is where OSDs come to the rescue. OSDs try to provide the best of both the worlds by overcoming the limitations of both NAS and SAN.
The fundamental innovation which enables this architecture is the reassignment of the responsibility for the mapping of I/O streams to sectors (block storage) from the client/server to the data store itself (OSD).
Since the OSD can perform the stream to sector mapping and the clients no longer need to worry about the algorithm to employ for this mapping, it makes OSD so suitable for data sharing in a cross-platform environment.
This cross-platform data sharing addresses the major benefit of NAS over SAN, and is inherent in Object Storage Arhcitecture (OSA).
The scalable performance is achieved by the fact that the data flow is direct between the client(s) and the OSD(s), without any need to pass through a server. This allows aggregate system performance to rise to the inherent capacity of the underlying fabric. This direct pipe from clients to storage addresses the major benefit of SAN with respect to NAS, and is inherent in OSA.
You just saw how OSDs combine the benenfits of both NAS and SAN into one storage device. In OSA apart from Client and OSDs there is one more actor involved - The Metadata Server(MDS). The MDS has the responsibility for maintaining all of the file system other than the mapping of streams to sectors. The MDS is where any hierarchical directory structure would be maintained, along with permissions, file-scope locking, etc.
Lets try to understand tis with an analogy of a 5-star hotel. Assume that the hotel is the OSD, various objects stored in there are the rooms of the hotel and the person sitting at the reception acts as MDS. Whenever a guest comes to the hotel and requests for access to a particular room he goes to the reception and asks for an electronic key to that room. The person at the reception also tells him the way to the floor. Once he has the key the guest can access the room any number of times. He will use the same key each and every time he wants to access the room. Also normally the key is valid for a certain period.
We just identified three primary objects in the architecture - client, OSD, and MDS. In any system, there are any number of clients, any number of ODSs, and one MDS. So one might think that because of the presence of a single logical MDS in any system, OSA also suffers from the same scalability problem as NAS does. It is correct that all communications must hit the MDS at some point but the situation is different than that of NAS. In NAS every request has to go through the NAS management server whereas in OSD the data itself never passes through the MDS. All data flow is directly between clients and OSDs. As explained above, once granted access to an object, the client may use the MDS-supplied credential (permission) across multiple accesses.
Here I have tried to throw some light on the concept of Object Storage Device. More information is available freely on the internet.
