This is a multi-part message in MIME format.
------=_NextPart_000_0746_01C30DE2.E787EA00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
As a follow up to the summary I sent out a couple of weeks ago our IBM =
rep finally got something back to me which I think does a nice job of =
reiteratering the isssues surrounding sharing a single HBA for disk and =
tape traffic. Enjoy!
>>Begin Email from IBM rep<<
This is the statement as it will be published in the future redbook:
Mixing disk and tape on a single SCSI bus was rarely done. The workloads =
are different, the SCSI profiles are different, and it rarely worked =
satisfactorily. In some instances, tape drives would use large blocks =
and "data streaming" to maximize performance, tying up the SCSI bus for =
long periods of time, while disk drives with smaller block sizes =
appropriate for random I/O would get less than their fair share of the =
SCSI bus. In other instances, the tape drives would have trouble getting =
access to the bus because disk drives would respond faster. It was =
generally accepted that you kept disk and tape on separate SCSI
buses.
With Fibre Channel, it is possible - in principle - to do better. I/O =
can be multiplexed and small blocks can be interleaved in the middle of =
large blocks. There is no shared bus to keep a slow device from sending =
whenever it is ready. So it is certainly possible with Fibre Channel to =
have both disk and tape sending or receiving with little interference. =
There is always the issue of having too much data for the bandwidth =
available, but this is independent of whether device types are mixed.
Unfortunately, to actually take advantage of these capabilities in Fibre =
Channel, an HBA driver would have to be carefully written to handle =
this. Sophisticated multithreading would be needed to interleave the I/O =
fairly.
Furthermore, older SCSI drivers were written using a single SCSI profile =
for the whole adapter. This was fine since disk and tape were rarely, if =
ever, mixed, so a single profile (one for disk or one for tape) could be =
used for the whole adapter and work fine. Often this is not under the =
user's control - the driver picks a profile based on what devices it =
sees. HBA drivers could certainly be written to allow different profiles =
to be used for different devices at the same time on a single adapter, =
but this is not yet a common practice. Thus, if you do mix disk and tape =
on a single HBA, you end up either using a disk profile for both disk =
and tape, or a tape for both disk and tape. Some devices will be using a =
non-optimal profile.
Finally, subtle problems have been discovered whose source has been =
narrowed down to interference between disk and tape traffic. Typically =
these problems occur intermittently, but when they do, devices can go =
offline leading to interruption of service.
Also for Performance reason you may consider to have more than one HBA =
and does not share Disk and Tape I/O on the same HBA. During Backup your =
server has to read the Data from Disk and write it to the Tape Drive. If =
it's a LTO 2 Drive you may write more than 35 MB/sec to the Tape Drive. =
This means you have also to read 35 MB/sec. If those both streams goes =
over HBA, then this HBA have to handle at least 70 MB/sec. Considering a =
1 Gbit HBA you already reached the bandwidth of this HBA.
As long as there is no other Disk I/O activity during this backup it may =
work without any problems. But, if during the Backup still applications =
running which are accessing the Disk, then you may see impact of Backup =
performance and impact of the applications performance.
For Backupserver, especially TSM Server, where a high I/O load exist you =
should run with several HBAs and separate the disk and tape IO.
For all of these reasons, IBM's official stance on mixing disk and tape =
on a single HBA is a little different from other configurations. IBM =
will support mixing disk and tape on a HBA, and the IBM Support Center =
will accept problems reported on these configurations. However, if the =
problem determination process reveals that the problem in question is =
caused by the mixing of the traffic, IBM may choose to tell the customer =
that the only fix is to separate the traffic. This normally means =
installing additional HBA(s), which can be problematic if a server has =
insufficient adapter slots. Over time, more will be learned about which =
combinations seem to work satisfactorily, and which combinations have =
specific problems that will require separation of the traffic.
In essence, the customer is assuming some risk in these configurations, =
and it is strongly recommended to avoid mixing disk and tape traffic on =
a single HBA whenever possible.
>>End Email from IBM rep<<
Cheers,
-Chris
------=_NextPart_000_0746_01C30DE2.E787EA00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4923.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV>As a follow up to the summary I sent out a couple of weeks ago our =
IBM rep=20
finally got something back to me which I think does a nice job of =
reiteratering=20
the isssues surrounding sharing a single HBA for disk and tape =
traffic. =20
Enjoy!</DIV>
<DIV> </DIV>
<DIV>>>Begin Email from IBM rep<<</DIV>
<DIV>This is the statement as it will be published in the future =
redbook:</DIV>
<DIV><BR>Mixing disk and tape on a single SCSI bus was rarely done. The=20
workloads are different, the SCSI profiles are different, and it rarely =
worked=20
satisfactorily. In some instances, tape drives would use large blocks =
and "data=20
streaming" to maximize performance, tying up the SCSI bus for long =
periods of=20
time, while disk drives with smaller block sizes appropriate for random =
I/O=20
would get less than their fair share of the SCSI bus. In other =
instances, the=20
tape drives would have trouble getting access to the bus because disk =
drives=20
would respond faster. It was generally accepted that you kept disk and =
tape on=20
separate SCSI<BR>buses.</DIV>
<DIV> </DIV>
<DIV>With Fibre Channel, it is possible - in principle - to do better. =
I/O can=20
be multiplexed and small blocks can be interleaved in the middle of =
large=20
blocks. There is no shared bus to keep a slow device from sending =
whenever it is=20
ready. So it is certainly possible with Fibre Channel to have both disk =
and tape=20
sending or receiving with little interference. There is always the issue =
of=20
having too much data for the bandwidth available, but this is =
independent of=20
whether device types are mixed.</DIV>
<DIV> </DIV>
<DIV>Unfortunately, to actually take advantage of these capabilities in =
Fibre=20
Channel, an HBA driver would have to be carefully written to handle =
this.=20
Sophisticated multithreading would be needed to interleave the I/O =
fairly.</DIV>
<DIV> </DIV>
<DIV>Furthermore, older SCSI drivers were written using a single SCSI =
profile=20
for the whole adapter. This was fine since disk and tape were rarely, if =
ever,=20
mixed, so a single profile (one for disk or one for tape) could be used =
for the=20
whole adapter and work fine. Often this is not under the user's control =
- the=20
driver picks a profile based on what devices it sees. HBA drivers could=20
certainly be written to allow different profiles to be used for =
different=20
devices at the same time on a single adapter, but this is not yet a =
common=20
practice. Thus, if you do mix disk and tape on a single HBA, you end up =
either=20
using a disk profile for both disk and tape, or a tape for both disk and =
tape.=20
Some devices will be using a non-optimal profile.</DIV>
<DIV> </DIV>
<DIV>Finally, subtle problems have been discovered whose source has been =
narrowed down to interference between disk and tape traffic. Typically =
these=20
problems occur intermittently, but when they do, devices can go offline =
leading=20
to interruption of service.</DIV>
<DIV> </DIV>
<DIV>Also for Performance reason you may consider to have more than one =
HBA and=20
does not share Disk and Tape I/O on the same HBA. During Backup your =
server has=20
to read the Data from Disk and write it to the Tape Drive. If it's a LTO =
2 Drive=20
you may write more than 35 MB/sec to the Tape Drive. This means you have =
also to=20
read 35 MB/sec. If those both streams goes over HBA, then this HBA have =
to=20
handle at least 70 MB/sec. Considering a 1 Gbit HBA you already reached =
the=20
bandwidth of this HBA.</DIV>
<DIV> </DIV>
<DIV>As long as there is no other Disk I/O activity during this backup =
it may=20
work without any problems. But, if during the Backup still applications =
running=20
which are accessing the Disk, then you may see impact of Backup =
performance and=20
impact of the applications performance.</DIV>
<DIV> </DIV>
<DIV>For Backupserver, especially TSM Server, where a high I/O load =
exist you=20
should run with several HBAs and separate the disk and tape IO.</DIV>
<DIV> </DIV>
<DIV>For all of these reasons, IBM's official stance on mixing disk and =
tape on=20
a single HBA is a little different from other configurations. IBM will =
support=20
mixing disk and tape on a HBA, and the IBM Support Center will accept =
problems=20
reported on these configurations. However, if the problem determination =
process=20
reveals that the problem in question is caused by the mixing of the =
traffic, IBM=20
may choose to tell the customer that the only fix is to separate the =
traffic.=20
This normally means installing additional HBA(s), which can be =
problematic if a=20
server has insufficient adapter slots. Over time, more will be learned =
about=20
which combinations seem to work satisfactorily, and which combinations =
have=20
specific problems that will require separation of the traffic.</DIV>
<DIV> </DIV>
<DIV>In essence, the customer is assuming some risk in these =
configurations, and=20
it is strongly recommended to avoid mixing disk and tape traffic on a =
single HBA=20
whenever possible.</DIV>
<DIV>>>End Email from IBM rep<<</DIV>
<DIV> </DIV>
<DIV>Cheers,</DIV>
<DIV>-Chris<BR><BR></DIV></FONT></DIV></BODY></HTML>
------=_NextPart_000_0746_01C30DE2.E787EA00--
|
