Article courtesy of JDEtips.com
By Glenn Robinson
When IBM started changing the
names of its systems a few years back,
there were some interesting stories
about how and why the systems got
their respective letters assigned. The
i in iSeries and System i represents
integration. For those who are not
too familiar with System i, specifically
i5/OS, integration really is at
the heart of the system. After all,
when you buy i5/OS you get security,
systems management tools, database
and much more built in-all good to
go out of the box.
One of i5/OS's really cool integration
functions is the ability to provide
virtual I/O and networking capabilities
for AIX, Linux and Windows.
Let's make something clear here
before we start: this is not Windows
running on POWER processors; this
is Windows running on IBM System
x or IBM Blades servers tightly integrated
with i5/OS.
If you've not heard of this IBM
offering before, you're probably asking
why would anyone want to do
this and what would they get out of it
if they did use it? My intention is to
address these questions so that you
can see when the solution is appropriate
for a customer.
Before we start, I'd like to make the
distinction between using the terms
i5/OS and System i. I can attach
Integrated Servers to any System i,
but only i5/OS partitions have the
ability to host these servers. AIX and
POWER Linux running on System i
do not have this capability. Hence,
it is important to understand that
we are integrating Windows servers
with i5/OS. It's also worth noting
that when we install Windows on
to a Blade or System x, we are using
standard Microsoft install media; we
don't do anything special because
we're integrating with i5/OS.
We have been able to attach specific
models of IBM xSeries and
System x to System i for a number
of years now, but we can now also
attach IBM BladeCenter. The first
question people ask on this is "do we
have to attach all the blades to the
i5/OS?" The answer is no, you can
attach as many or as few as you wish
to i5/OS.
For those of you not too familiar
with BladeCenter, here's a very quick
overview. The BladeCenter, (see Figure
1), consists of a chassis which
fits in to a standard rack. The chassis
contains power supplies, cooling,
keyboard, video, mouse (KVM),
CD/DVD and LAN facilities. You
then place blades in to the chassis
which use the resources provided by
the chassis. Up to 14 blades can be
located in a chassis. The blades are
Intel, AMD or POWER based servers
which utilize the power, cooling etc.
provided by the chassis. Blades are
hot technology at the moment and lot
of focus is being given to blade technology
by IBM and other vendors as
well.
These days, a great number of
Windows servers are attached to
SANs, which provide disk resource.
The connectivity between the server
and the SAN is usually Fibre Channel
or iSCSI. When integrating Windows
servers with i5/OS, we use the
iSCSI connection option.
iSCSI is server attachment to an
external SCSI storage network using
IP over an Ethernet network. What
this means is that when a server
requests disk data, this actually goes
across an Ethernet network to the
external storage device which services
the disk request. To get an idea
of how these components are connected,
please refer to Figure 2.
So what are the benefits of this
technology? Why would anyone do
this?
Integration and simplification are
the answers to both the above questions.
System i users are used to having
everything integrated in to the
operating system. They don't worry
themselves with Storage Management,
disk placement etc., as this
is done by the operating system. By
integrating Windows servers in to i5/
OS, we can extend some of the virtualization,
consolidation, and integration
features to our Windows servers.
Sounds like Nirvana? Almost.
Let's look at an example: You need
a SQL Server database up and running
with 300GB of disk space. With
an integrated Windows server, we
would create a 300GB virtual disk in
our i5/OS partition and assign it to
our integrated Windows server. Windows
does not know that the virtual
disk unit is located on a System i; it
merely sees a 300GB disk unit just
the same way it would if you added a
physical disk or a LUN from a SAN.
The benefit of this is that the virtual
disk is located on System i disk
units. If your i5/OS partition has 20
disk arms. then the 300GB virtual
disk will be evenly spread across the
20 disk arms. It will also benefit
from the disk protection currently
implemented across the physical disk
units, usually RAID-5 or Mirroring.
When a user requests data from
our SQL server, the request is sent,
by Windows, to the disk drive which
is then processed by i5/OS storage
management. Windows believes it is
accessing a single drive with a single
disk arm, but in reality there are 20
disk arms processing the request. It
is not uncommon in this type of environment
to see significant performance
improvements in i/o-intensive
Windows applications when using
integrated Windows servers. i5/OS is
extremely fast and efficient at storage
i/o processing and the disk controllers
used by i5/OS tend to have
large read and write caches built in.
Let's say you're running short
on disk space and need more than
300GB. What we can do is create a
new virtual disk, link it to the server
and then use Windows to format it,
and then start using it. You don't
take Windows down at any point.
Another pain point for many users
is testing of new software releases
and service packs. Many companies
do these tests on older servers,
but these aren't full tests because
the drivers between the production
server and test server are likely to
differ. The solution is to make clones
of the virtual disks used by the production
server which we will use for
our testing. Then, when we're ready
to do our testing, we'll power off the
server, unlink the production disks,
link the cloned disks and then power
on our server. We can then apply service
packs etc. and carry out our
testing safe in the knowledge that
our production disks are untouched
and available to re-link to our server
when our testing is complete.
Many customers actually have a
hot, spare integrated server in case
a production server should fail. The
hot-spare can be used for testing or
for development on a daily basis, if
required. Because the definition of
the integrated servers are held in
i5/OS as software objects, it is very
quick and easy to move a server definition
from one physical integrated
server to another. Many customers
looking at Windows high availability
are considering Windows Clusters;
these are complicated and can
be quite expensive. A great number
of customers are happy to settle for
up 30 minutes of down time should
a Windows server failure occur. By
using a hot, spare integrated Windows
server, it is very easy to have a
failed Windows server back up and
running within 10-15 minutes in
most cases. We simply tell i5/OS that
our server definition is now going
to run on integrated server B rather
than integrated server A, and then
power it up. It really is that simple,
and far less complex and cheaper
than a Cluster.
Integrated Windows servers also
benefit from the System i Virtual
Ethernet functionality. A System i
can have up to 4095 VLANs configured.
You can think of this as having
up to 4095 switches inside the
system. You decide which partitions
and/or integrated server can access
the VLANS; the configuration is
entirely up to you.
This is particularly useful in three
tier application environments as the
network traffic between the application
and database tiers. I'm assuming
Windows and i5/OS respectively
can be transmitted over the VLAN.
This adds a layer of security as the
data does not flow over the physical
LAN and can also provide extremely
fast performance since the network
traffic is running over the System i
bus and not over a wired external
network. The integrated Windows
server can access and transmit data
over the physical network as well as
the VLAN.
Utilizing integrated Windows
servers allows you to use your System
i tape drives either by using i5/
OS commands or by using Windowsbased
backup utilities. The most
common method used by our customers
is the i5/OS SAV command. With
this command, we can backup the
data under Windows shares located
on our integrated servers.
Using the latest version of i5/OS,
V5R4, the SAV command also works
with Windows' Volume Shadow
Copy Services (VSCS) which allows
the SAV command to backup integrated
Windows server based files
even when Windows has them open--
a bit like Save While Active in i5/OS.
Bear in mind that VSCS is a Window
XP and 2003 function; it is not an
i5/OS function.
IBM has recently announced that
it intends to make VMWare ESX
3.1 available on the iSCSI integrated
servers too. This will entail the
System i being certified as a storage
device by VMWare. Using VMWare
ESX means that you can run Windows
NT, 2000, 2003, Netware,
Solaris and Linux on your integrated
servers. This offering will only
provide storage virtualization at the
moment. The shared Ethernet and
tape backup capabilities have not
been announced by IBM.
System i Integrated Servers are a
great offering and you can achieve
significant cost savings for your
organization in terms of systems
management and administration of
Windows servers.
This is what virtualization is all
about: Improving utilization, reducing
running costs and simplifying
the IT infrastructure. And i5/OS
really does provide this. I've shown
a link below to a white paper which
covers this subject and illustrates
that over a three year period, the
Return on Investment is 258%. Now
that's a lot of cost to be saved by your
organization!
