| |
In the game of data access and movement, performance means making your SLAs with time to spare. It is possible to get 6 times the performance out of your existing network infrastructure. You just need to think different about how you address the problems.
Background
There are two types of networks which are deployed extensively in all businesses: Communications Networks and Data Networks.
Communications networks (CNs) are manifested in NICs, hubs, routers, switches, etc. and are for the purpose of providing communications mechanisms to and from servers in the enterprise to and from client applications. These networks use TCP/IP as the underlying transport protocol.
Data networks (DNs) are manifested in HBAs, directors, switches, etc. and are for the purpose of providing access to and from data on storage media to and from servers requiring that data. On mainframes, we use the term ESCON and FICON to refer to these networks and on UNIX, Windows or Linux, we use the terms SAN (Storage Area Network) and fibre channel. Within this article, we use the DN acronym to refer to all of these.
CNs tend to be serial in nature and have a small number of connections per server while DNs tend to be massively parallel and have a great number of connections per server. The performance of CNs is unpredictable and dependent on loading and the type of traffic; whereas, given a specific configuration, DNs deliver consistent, predictable performance.
Most companies spend significantly more (orders of magnitude) on their DNs than their CNs. The reason for this is performance. Getting the most out of a DN means getting the most out of the processor, since access to data is directly related to response time. For that reason, these systems are very sophisticated and involve caching within the processors as well as outboard in disk arrays. SLAs (Service Level Agreements) rely very heavily on consistent DN performance.
While DNs have been evolving in both speed and technology, CN improvements have been limited to merely increases in available bandwidth and improved routing techniques, error handling, and new standards relating to the internet.
The handling of CN traffic within processors has always been CPU-intensive. While the world has standardized in the use of TCP/IP, most of the work needed to implement the protocol is still done within processors. There are even solutions, such as iSCSI and NFS which unnecessarily put TCP/IP protocol between processors and their mission-critical data.
In contrast, even in the earliest days, most of the work done to implement DNs has been within the components of the DN itself and not within the processors. From the first IBM System 360 mainframes through today’s System z, channel processors manage I/O. Once an application initiates an I/O operation, the channel takes over and handles direct memory transfer to and from the device. In this way the processor continues to do other things until the I/O completes. The latest System z systems from IBM have up to 1024 FICON connections and significant improvement in I/O performance as well through the use of System Assist Processors. UNIX, Windows or Linux systems, as well, have on-board processors within HBAs to handle DMA (Direct Memory Access) to and from the fibre channel network.
Data Movement
No business of any size has a single server anymore. Typically, the availability of applications or cost dictates that multiple platforms are used. This results in the need to move data between processors; because, typically, the processor that generates and manages a set of data is not the processor that exclusively uses this data.
In the early days of mainframes, IBM defined a possible way to move data between DNs without crossing the boundary into CNs. This is called a Channel-to-Channel Adapter (CTCA). It allowed for direct I/O links between processors so that data could be transmitted efficiently using all of the power of the DN. Today, these are implemented within FICON directors as FCTCs (FICON CTCs). They still provide a very efficient mechanism for connecting two or more z/OS processors.
In the UNIX, Windows or Linux world, conversely, FTP is used to move data over CNs. The world struggled for many years (and still is), to solve the problem of co-existence of interactive traffic with file transfer traffic. In essence, the presence of DN traffic on the CN is corrupting the original objective of having a CN. This problem has not been solved. Configuring networks for both data and interactive traffic is still problematic.
|
|
|
