Friday, March 28, 2008

Learn more about LIMITATIONS AND REQUIREMENTS and Implementation-related limitations of storage networks

Learn more about LIMITATIONS AND REQUIREMENTS and Implementation-related limitations of storage networks

In this section we will first discuss architecture-related (Section 5.2.1) and implementation  related limitations (Section 5.2.2) of storage networks. We will then go on to describe  further requirements for an efficient management of storage in large storage networks (Section 5.2.3). Finally, in Section 5.2.4, we will summarize the requirements of storage virtualization.

 Architecture-related limitations of non-virtualized storage networks

The storage resources brought together in a storage network are easier to manage than those in a server-centric IT architecture due to the separation of servers and storage devices. In many cases, the number of storage devices to be administered can also be drastically reduced by the introduction of a storage network. As a result, resource management becomes easier and more flexible (Section 1.3). The flexible assignment of free hard disk capacity (Figure 2.3) alone is not, how- ever, enough to fully exploit the savings potential of the storage-centric IT architecture such as resource and data sharing and the simplification of the management of storage resources. Without storage virtualization in the storage network there remains a direct connection between the storage device that provides the storage and the server that uses it. If, for example, changes are made to the configuration of the storage devices, then these remain visible on the server, meaning that appropriate modifications are necessary there. In smaller environments with moderate data quantities this may be acceptable. In

large environments the examples mentioned below represent a greater challenge to system administrators.

The replacement of storage devices in the event of a defect or an upgrade to newer, more powerful devices can only be performed at significant extra cost because the data from the old media must be transferred to the new. Additionally, administrators often are faced with an impossible task if this is to take place in a 24 × 7 environment without applicationfailures. The modifications that have to be carried out on servers and applications to use the new storage devices after a replacement give rise to additional costs.

Without storage virtualization, every change to the storage resources requires changes to the operating system and to the applications on the servers that use this. In many configurations a volume manager shields changes to the storage hardware from the applications. We will see later that a volume manager  epresents a form of storage virtualization. In addition to storage virtualization on the server by a volume manager we will also discover further possibilities for storage virtualization, which solve the problem of the direct influence of storage devices and servers. Often there is also an inefficient use of the storage resources. For example, the following situation can occur (Figure 5.9): a storage network has two servers, A and B, which own disk space allocated on a disk subsystem. If the disks on server A have been filled, this server cannot simply share the free storage space on the drives of server B. This is because the volumes on a disk subsystem are still statically assigned to a server and no suitable mechanisms have been implemented in the disk subsystems for the sharingof block-level resources. So, although on most disk subsystems it is possible to assign the same volume to several servers, the possible data inconsistencies that could arise as a

result of such disk sharing are not rectified by the disk subsystem itself. The consequence of this is that additional new storage must be purchased or at least further storage devices allocated in order to solve the space problems of server A, even though the capacity allocated to server B has not yet been used up. Storage virtualization software can realize the sharing of resources in a storage network. The shared disk file systems introduced in Section 4.3 represent one approach to this. However, the complexity of the software to be used for this increases the administrative cost.

 Implementation-related limitations of storage networks

In previous sections we discussed only the conceptual boundaries of storage networks. In real environments matters are even worse. Incompatibilities between the storage systems of different manufacturers represent the main evil. For example, the manufacturers of disk subsystems are currently (2003) supplying special device drivers for their storage devices which provide advanced functions like handling multiple paths between a server and the storage device (Section 6.3.1). Unfortunately these disk subsystem specific device drivers only work with one disk subsystem type. To make matters worse, the installation of the device drivers for different disk subsystems onto one computer at the same time is usually not supported. This incompatibility between disk subsystem specific device drivers means that each server is linked to a very specific disk subsystem model or a very specific range of disk subsystem models, depending upon the respective device driver (Figure 5.10). As a result, one advantage of storage networks that has been mentioned several times in

this book – namely the flexible allocation of free storage – only works on paper and in homogeneous storage landscapes. In real systems, a server can only use free storage capacity if this exists on a storage device with a compatible device driver. It currently (2003) looks as though the functionality of device drivers will, to an increasing degree, be integrated into operating systems, so that this limitation will very probably be rectified in a few years. Furthermore, some disk subsystem vendors are working on the interoperability of their device drivers and they can thus be installed in parallel on the same server. In practice this leads directly to economic disadvantages: let us assume that high per- formance requirements exist for 20% of the data of an application, whilst only average

performance requirements exist for the remaining 80%. In this case it would be desirable to put just the 20% of the data on a high-end disk subsystem and store the rest of the data on a cheaper mid-range disk subsystem. Due to the incompatibility of the disk subsystem device drivers, however, the application server can only be connected to one type of disk subsystem, which means that all data must be stored on the high-end disk subsystem Ultimately, this means that 80% of the data is taking up storage capacity that is more expensive than necessary. A further interoperability problem in the practical use of storage systems is the

lack of standardization of the interfaces for the disk subsystem-based remote mirroring (Section 2.7.2). As a result of this, the data cannot currently (2003) be mirrored between

any two storage systems. Usually, remote mirroring is only possible between two disk subsystems of the same type, only very exceptionally is it possible between different models or between two devices from different manufacturers. Here too, economic disadvantages result because this restricts the choice of disk subsystems that can be combined, meaning that it is not always possible to use the most economical storage system. The inadequate interoperability of disk subsystem device drivers and remote mirroring gives rise to very real difficulties when replacing an old disk subsystem with a new one: this operation requires that the data from the old device is copied to the new device. However, it is precisely this copying process that can be very difficult in practice. Data mirroring by the volume manager would be preferable, so that the data could be copied to the new disk subsystem largely without interruptions. However, it is precisely this that is not possible if the device drivers of the two participating disk subsystems are not compatible with each other. In this situation, remote mirroring does not offer an alternative due to the lack of interoperability. Ultimately, economic disadvantages arise here, too, because it is not always possible to choose the most economical new storage system.

No comments:

Buy Vmware Interview Questions & Storage Interview Questions for $150. 100+ Interview Questions with Answers.Get additional free bonus reference materials. You can download immediately even if its 1 AM. You will recieve download link immediately after payment completion.You can buy using credit card or paypal.
----------------------------------------- Get 100 Storage Interview Questions.
:
:
500+ Software Testing Interview Questions with Answers are also available plz email roger.smithson1@gmail.com if you are interested to buy them. 200 Storage Interview Questions word file @ $97

Vmware Interview Questions with Answers $100 Fast Download Immediately after payment.: Get 100 Technical Interview Questions with Answers for $100.
------------------------------------------ For $24 Get 100 Vmware Interview Questions only(No Answers)
Vmware Interview Questions - 100 Questions from people who attended Technical Interview related to Vmware virtualization jobs ($24 - Questions only) ------------------------------------------- Virtualization Video Training How to Get High Salary Jobs Software Testing Tutorials Storage Job Openings Interview Questions

 Subscribe To Blog Feed