Object stores provide security for data requests from independent entities transferred over a shared network.
Security is probably the most significant issue raised in today's SAN architecture. SAN security is comprised of security and protection. A protection mechanism provides defense against non-malicious "attacks," such as buggy clients, administrative errors, etc. Protection is always needed when there is shared access to data. It enables users to define the access control policy to the shared resources. Security addresses intentional attempts at unauthorized access. The security mechanism ensures that the system's access policy is enforced at all times. Basically, security is essential if the infrastructure is not trusted.
Security in Today's SAN solutions
Today's SANs offer limited security, which makes them vulnerable to a wide range of attacks. In practice, these attacks are not that common since SANs are almost exclusively Fibre Channel-based. Because Fibre Channel is not pervasive, and hosts with Fibre Channel connections tend to be in protected machine rooms, the practical opportunity for attacks is limited. However, the expected adoption of IP-based storage is likely to exacerbate the SAN security problem. IP networks are readily available, IP connectivity is not limited to protected machines, and unfortunately there is a range of tools and techniques for IP-based security attacks.
With today's coarse-grain security support, clients are assumed to be completely trusted. Existing mechanisms such as zoning, LUN masking, and so forth are hard to use and related to the physical structure of the storage. They provide protection only at LUN-level.
Scalability for a large number of storage clients becomes an issue when hosts share access to volumes, since this requires coordination.
In SAN file systems built upon a block control unit, space allocation is managed by some form of meta-data server (see Storage Tank, Lustre, PanFS) typically in concert with smart client involvement. A good degree of scalability can be achieved by having this metadata server run on a cluster and partitioning responsibility between the nodes of the cluster. However, this coordination requires additional communication and extra overhead to harden meta-data updates, or a risk of (meta)data loss.
Object Store can leverage support provided by the storage controllers, such as hardening the meta-data, if the storage controller performs space allocation.
The problems facing storage management are similar to the ones that arise in security. Management at the level of a single block is not practical, since there are simply too many blocks, and management at the logical unit granularity is too coarse-grain, since a given logical unit may contain data that requires different policies.
Previously, when data was directly attached to the host that generated and used the data, end-to-end management was easy, since everything was in a single box. Today, with block storage as an independent entity, end-to-end management of individual data units is difficult; we would like to support functions such as quality-of-service for individual files and migration/replication of individual files. However, block control units only recognize blocks and logical units.
Future versions of OSDs will provide advanced functionality. Such functionality includes support for collections of objects, multi-object operations, snapshots, cloning, and space-management. When implemented close to the object device, such functionality can distribute the work that today takes place in the centralized file-server, resulting in improved performance and simplified management.