- The Home Office
- The Small Office
- The Midrange
- The At-Distance Site
- FC and iSCSI
- Chapter Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Small Office
Examples of the small office environment are dentists, accountants, construction, real estate, and the like—that is, any office that has a relatively small number of employees working in close proximity and a continuing need to grow its storage. Individual desktop systems in small offices have the same disruptive effect when adding storage as they have in home offices, but they are often connected to a file server. However, these file servers face the same problems that individual office or home systems face when adding additional storage. Their owners do not want to disassemble them to add storage and may instead replace the system altogether.
The real problem starts when the user has to migrate the data from an old file server to a new unit, a difficult and very disruptive process. There are technical solutions, of course. One of them is to buy another file server or a network attached storage (NAS) appliance. Thanks to iSCSI there is another, generally less costly approach—pooled storage. Pooled storage may consist of simple iSCSI JBODs (just a bunch of disks) or RAID controllers, all connected to the same network via iSCSI. With iSCSI, users can also begin small and add storage as needed, placing it wherever they have room and a network connection. Regardless of how many units they add, all of them are logically pooled and yet any of the individual systems in the office can have its own private storage portion.
With iSCSI all the major storage placement decisions are performed by the various host systems as if the storage were directly connected to them. Because of this fact, iSCSI is fairly simple compared to NAS and this results in low processing requirements in the iSCSI storage controllers. It is therefore expected that iSCSI JBODs and RAID controllers will be significantly less costly, and support more systems, than the same storage in a NAS appliance. Using iSCSI units in this way is not always the right answer; however, it does give the customer another option that may meet their needs for flexibil-ity and price. In other words, for the same processor power an iSCSI appliance can support more clients and more storage than is possible with a NAS appliance.
A performance analysis carried out by IBM compared a NAS (NFS) server to an iSCSI target (with the same basic power and equipment). This comparison showed that the iSCSI target used much less processing power than did the NFS server. (Refer to the discussion of measurements in Chapter 3.) Small offices are similar to home offices, except that they have more links and switches. In most installations, a switch can be used to attach either a new NAS appliance or an iSCSI storage controller. (See Figure 2–3.) Like home office systems, small office systems are bound together with 100Mb/s links. As a rule, it will be possible for them to upgrade to 1000Mb/s links whenever their 100Mb/s links become congested. They can usually ease into iSCSI storage controllers with 100Mb/s links, but over time these links will be upgraded to 1000Mb/s. They will operate on the same (Cat. 5) Ethernet cable and provide all the bandwidth needed to support any normal demand for iSCSI access, NAS access, normal interactive traffic, and Web traffic.
)
Figure 2–3 Small-office interconnect.
In a small office that has NAS, iSCSI storage can be added to the existing network with no more network congestion than would exist if its current file server were updated or if a new NAS server unit were added.
A question that needs to be asked is when it is appropriate to add a NAS unit and when it is appropriate to attach an iSCSI storage controller. The answer depends on the customer application. Some small offices, such as dentists and accountants, use specialty software, acquired from a salesperson who supplies them with other tools of their trade. It might be an appointment management system or a billing system, or sometimes a trade/business-specific system. Some are database applications; others are just file based.
The first thing to determine is whether the software is a database application or a file system application. If a database application, the normal choice for additional external storage is iSCSI. This is true whether or not the database uses a local file system or a "raw" partition (without file system formatting). In either case the most efficient process is to let the database or file system allocate its own data blocks and then use iSCSI to access them. Oracle and IBM DB2, for example, can operate efficiently with a raw partition, but they also have been set up to interface efficiently with many local file systems. The use of iSCSI exploits that fact. As indicated above, the iSCSI storage controller can handle more loads, at higher performance, than a NAS system with similar hardware can.
The clear trend in the industry is to tie applications to databases. When this is done, for the most part the question of sharing files becomes academic since almost all major databases1 use "Shared Nothing." In this model the storage is not shared with other systems. This is true even in larger "clustered" installations, where the database query is "parsed" and divided up among the different database systems in the cluster that "own" the data. In this way the more database servers an installation has, the less it needs to share files and the more useful iSCSI becomes.
If the application uses a file system instead of a database, we need to ask if the application is capable of sharing data with other users in either serial or parallel manner. If so, then we need to ask if the user actually does any file sharing. The answers to these questions will generally indicate that 90% or more of the data at the site is not shared. In fact, the answer with the highest probability in a small office is that no file sharing occurs.
Normally the only data sharing in a business environment is via a database. The main exception to this is in an engineering environment. For example, physical design engineers—such as those working at a company like Boeing—may share design files that need to be integrated from time to time so that full simulations can be done. The wing designer might need to share his design file with the engine mount designer, and both might need to share files with the engine designer.
We can find a similar situation with chip engineers, who need to share macro files and their own design files with other designers and the simulation system. Software engineers are still another example. They share their development libraries, their resultant components, and even their documentation library.
The engineering environment is the primary environment where files are shared. Much of the rest of the world shares by sending things around in e-mails. In general, they usually do not have a file sharing need.
When incidental serial file sharing occurs, the small business office, like the home office, is more apt to use peer-to-peer sharing and not put in a NAS server. However, this probability varies with the size of the office; the larger it is, the higher the possibility that it will devote a system to file serving or install a NAS appliance. Even when the file sharing is not very important, it often finds use for the file server/NAS as a backup device.
Once file-sharing requirements are understood, we can determine if a NAS unit or an iSCSI storage controller best meets the need. If we have a large file-sharing requirement, NAS is usually the best fit. If not, the best fit is usually iSCSI. Then, in the rare case when file sharing is needed, the peer-to-peer type is appropriate.
If the installation has a lot of sharing and nonsharing requirements, we determine the minimum number of NAS systems needed for file sharing and the number of iSCSI systems needed for nonfile sharing, buying the minimum of both. If all workload can fit into a single inexpensive NAS unit, often this is the best approach. In general, it is best for an installation to fit the entire file-sharing workload into the fewest number of NAS units that can support it. Then it can either try to fit some amount of the nonfile sharing storage access into the unfilled NAS capacity or leave it for subsequent NAS growth. The rest of the storage access load, which will probably be a large majority of the total storage requirement, should exploit the efficiencies of iSCSI storage controllers. This approach is usually much more cost effective than pushing all workload into NAS units.
One other solution is the single unit that supports both NAS and iSCSI functions, which I call a "dual dialect" storage server. With this type of system the installation does not need much precision in its NAS/iSCSI planning. As an example, let's suppose the installation only needs 10% of its clients, or applications, to have file sharing. In this case, one dual dialect storage server can devote 70% of its processing capability to that 10% and use the remaining 30% for the 90% that have no file-sharing requirements. (See Figure 2–4.) Of all environments, a small office environment is the least capable of anticipating and designing the storage layout that can optimally support its workload. I therefore expect dual dialect systems to be very successful in small office environments that include both engineers and nonengineers. Environments without heavy engineering design work will generally find iSCSI storage controllers to be the most appropriate equipment for providing IP-based storage.
)
Figure 2–4 Storage combo—NAS and iSCSI.