Chapter 6. Fibre Channel products and technology
7.6 Storage virtualization in the SAN
7.6.2 Virtualization levels
We will define the different levels that virtualization can be achieved at in a storage network, as illustrated in Figure 7-6.
Figure 7-6 Levels that storage virtualization can be applied at
Fabric level
At the fabric level, virtualization can enable the independence of storage pools from heterogeneous servers. The SAN fabric would be zoned to allow the virtualization appliances to see the storage subsystems, and for the servers to see the virtualization appliances. Servers would not be able to directly see or operate on the storage subsystems.
Storage subsystem level
As seen before in this chapter, a LUN is a logical volume within a storage device. Disk storage systems can provide some level of virtualization already by
subdividing disks into LUNs. Conversely, multiple storage devices could be consolidated together to form one large virtual drive. RAID subsystems are an example of virtualization at the storage level. Storage virtualization can take this to the next level by enabling the presentation and the management of disparate storage systems.
Server level
Abstraction at the server level is by means of the logical volume management of the operating systems on the servers. At first sight, increasing the level of
Storage
subsystem
level
SUN Solaris HP-UX IBM AIX Windows File system levelServer level
Fabric level
SAN
SAN
Chapter 7. Management 151 abstraction on the server seems well suited for environments without storage networks, but this can be vitally important in storage networks too.
Since the storage is no longer controlled by individual servers, it can be used by any server as needed. Capacity can be added or removed on demand without affecting the application servers. Storage virtualization simplifies storage management and reduces the cost of managing the SAN environment.
File system level
Virtualization at the file system level provides the highest level of virtual storage. It can also provide the highest benefit, because it is data (not volumes) that is to be shared, allocated, and protected.
7.6.3 Virtualization models
Storage virtualization, just like general-purpose management mechanisms, can be implemented in an in-band or out-of-band fashion.
When we implement an in-band virtual storage network, both data and control flow over the same path. Levels of abstraction exist in the data path, and storage can be pooled under the control of a domain manager. In general, in-band solutions are perceived to be simpler to implement, especially because they do not require special software to be installed in servers (other than conventional multi-pathing software). In-band solutions can also provide caching and advanced functions within the storage network. This can help to improve the performance of existing disk systems and can extend their useful life, and reduce the cost of new storage capacity by enabling the use of lower function, lower cost disk systems, without the loss of performance.
Other advantages include:
Ability to off load function from the host
Providing storage management for the SAN
Performing performance optimizations in the data path
Supporting host systems not in a cluster
Supporting multiple heterogeneous hosts
Integrating well with storage management software
Releasing the customer from a particular vendor’s storage
Integrating with storage to create a better management picture
Offering excellent scalability
In an out-of-band implementation, the data flow is separated from the control flow. This is achieved by separating the data and meta-data (data about the data) into different places. Out-of-band virtualization involves moving all mapping
and locking tables to a separate server (the meta-data controller) that contains the meta-data of the files.
In an out-of-band solution the servers request authorization to data from the meta-data controller, which grants it, handles locking, and so on. Once they are authorized, servers access the data directly without any meta-data controller intervention. Once a client has obtained access to a file, all I/O will go directly over the SAN to the storage devices. For many operations, the meta-data controller does not even intervene.
Separating the flow of control and data in this manner allows the I/O to use the full bandwidth that a SAN provides, while control could go over a separate network or routes in the SAN that are isolated for this purpose. This results in performance that is nearly equal to local file system performance with all of the benefits and added functionality that come with an out-of-band implementation. Other advantages include:
Releasing the customer from a particular vendor’s storage
Providing storage management for the SAN
Offering excellent scalability
Off loading host processing
Supporting storage management from multiple vendors
Integrating well with storage management software
Supporting multiple heterogeneous hosts
Relatively low overhead in the data path
7.6.4 Virtualization strategies
The IBM strategy is to move the storage device management intelligence out of the server, reducing the dependency of having to implement specialized software, like Logical Volume Managers (LVM), at the server level. We also intend to reduce the requirement for intelligence at the storage subsystem level, which will decrease the dependency on having to implement intelligent storage subsystems.
By implementing at a fabric level, storage control is moved into the network, which gives the opportunity to all for virtualization, and at the same time reduces complexity by providing a single view of storage. The storage network can be used to leverage all kinds of services across multiple storage devices, including virtualization.
By implementing at a file system level, file details are effectively stored on the storage network instead of in individual servers. This design means the file system intelligence is available to all application servers. Doing so provides
Chapter 7. Management 153 immediate benefits: a single namespace and a single point of management. This eliminates the need to manage files on a server-by-server basis.
© Copyright IBM Corp. 1999, 2003, 2006. All rights reserved. 155
Chapter 8.
Security
Security has always been a major concern for networked systems administrators and users. Even for specialized networked infrastructures, such as SANs, special care has to be taken so that information does not get corrupted, either accidentally or deliberately, or fall into the wrong hands. And, we also need to make sure that at a fabric level the correct security is in place, for example, to make sure that a user does not inadvertently change the configuration incorrectly.
Now that SANs have “broken” the traditional direct-attached storage paradigm of servers being cabled directly to servers, the inherent security that this provided has been lost. The SAN and its resources may be shared by many users and many departments. The SAN may be shared by different operating systems that have differing ideas as to who owns what storage. To protect the privacy and safeguard the storage, SAN vendors came up with a segmentation tool, zoning, to overcome this. The fabric itself would enforce the separation of data so that only those users intended to have access could communicate with the data they were supposed to.
Zoning, however, does not provide security. For example, if data is being
transmitted over a link it would be possible to “sniff” the link with an analyzer and steal the data. This is a vulnerability that becomes even more evident when the data itself has to travel outside of the data center, and over long distances. This will often involve transmission over networks that are owned by different carriers.
More often than not, not all data is not encrypted before being sent and this itself means that stealing data could be extremely fruitful. The introduction of
multiprotocol devices that allow Fibre Channel hosts to connect to Gigabit Ethernet switches have, in a touch of irony to those that see these as competing technologies, allowed the introduction of IP Security (IPSec) into the Fibre Channel world. There are also third-party devices that will provide encryption using tried and trusted algorithms.
It would be naive to expect that the required level of security can be achieved from any one of the methodologies and technologies, independent of all others, that we will discuss in this chapter. The storage architect needs to understand, and administrators accept, that in a SAN environment, often with a combination of diverse operating systems and vendor storage devices, that some
combination of technologies could be required to ensure that the SAN is secure from unauthorized systems and users.
In terms of making the fabric and the data as secure as possible, these are some of the questions that need to be answered:
How do we stop hosts in the SAN from taking over all the storage (LUNs) that they see?
How can we segregate operating systems and at what level?
How can we segregate different applications on the fabric?
How do we allow a host to access some LUNs and not others?
How do we provide switch-to-switch security?
How do we protect the fabric from unauthorized hosts logging in?
How do we provide users with different authorization levels?
How do we track, or audit, and changes?
SANs and their ability to make data highly available, need to be tempered by well thought out, and more importantly implementing, security policies that manage how devices interact within the SAN. It is essential that the SAN environment implements a number of safeguards to ensure data integrity, and to prevent unwanted access from unauthorized systems and users.
In the discussions that follow we briefly explore some of the technologies and their associated methodologies that can be used to ensure data integrity, and to protect and manage the fabric. Each technology has advantages and
disadvantages; and each must be considered based on a well thought out SAN security strategy, developed during the SAN design phase.
Chapter 8. Security 157
8.1 Security principles
It is a well-known fact that “a chain is only as strong as its weakest link” and when talking about computer security, the same concept applies: there is no point in locking all the doors and then leaving a window open. A secure, networked infrastructure must protect information at many levels or layers, and have no single point of failure.
The levels of defense need to be complementary, and work in conjunction with each other. If you have a SAN, or any other network for that matter, that crumbles after a single penetration, then this is not a recipe for success.
There are a number of unique entities that need to be given consideration in any environment. We discuss some of the most important ones in the topics that follow.
8.1.1 Access control
Access control can be performed both by means of authentication and
authorization techniques:
Authentication Means that the secure system has to challenge the user (usually by means of a password) so that he or she identifies himself.
Authorization Having identified a user, the system will be able to “know” what this user is allowed to do and what they are not. As true as it is in any IT environment, it is also true in a SAN environment that access to information, and to the configuration or management tools, must be restricted to only those people that are need to have access, and authorized to make changes. Any configuration or management software is typically protected with several levels of security, usually starting with a user ID and password that must be assigned appropriately to personnel based on their skill level and responsibility.