107 lines
6.8 KiB
HTML
107 lines
6.8 KiB
HTML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html lang="en-us" xml:lang="en-us">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<meta name="security" content="public" />
|
|
<meta name="Robots" content="index,follow" />
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
|
<meta name="DC.Type" content="topic" />
|
|
<meta name="DC.Title" content="Scenario: Consolidate servers using switchable independent disk pools" />
|
|
<meta name="DC.Relation" scheme="URI" content="rzalyswitchableiasps.htm" />
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2002, 2006" />
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2002, 2006" />
|
|
<meta name="DC.Format" content="XHTML" />
|
|
<meta name="DC.Identifier" content="scenario" />
|
|
<meta name="DC.Language" content="en-us" />
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
|
<!-- US Government Users Restricted Rights -->
|
|
<!-- Use, duplication or disclosure restricted by -->
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
|
<title>Scenario: Consolidate servers using switchable independent disk pools</title>
|
|
</head>
|
|
<body id="scenario"><a name="scenario"><!-- --></a>
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
|
<h1 class="topictitle1">Scenario: Consolidate servers using switchable independent disk pools</h1>
|
|
<div><div class="section" id="scenario__situation"><a name="scenario__situation"><!-- --></a><h4 class="sectionscenariobar">Situation</h4><p>Your
|
|
company's network currently uses 30 small servers distributed within a single
|
|
region, all in the same time zone, using the same language, and running the
|
|
same release of the operating system and programming code. The amount of time
|
|
and effort you spend maintaining the small systems and keeping them at the
|
|
same operating system and application release levels is significant. </p>
|
|
</div>
|
|
<div class="section" id="scenario__objective"><a name="scenario__objective"><!-- --></a><h4 class="sectionscenariobar">Objectives</h4><p>To
|
|
reduce the resource required to maintain and administer your servers, you
|
|
want to consolidate by reducing the number of servers in your network.</p>
|
|
<div class="p">The
|
|
objectives of this scenario are as follows:<ul><li>To consolidate from 30 small servers to one larger server at a central
|
|
location</li>
|
|
<li>To maintain data independence for each geographic region</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
<div class="section" id="scenario__details"><a name="scenario__details"><!-- --></a><h4 class="sectionscenariobar">Details</h4><p>None
|
|
of the 30 small servers in your network require more than four disk units.</p>
|
|
</div>
|
|
<div class="section" id="scenario__prereq"><a name="scenario__prereq"><!-- --></a><h4 class="sectionscenariobar">Prerequisites
|
|
and assumptions</h4><div class="p">A potential consolidation answer for your network
|
|
is logical partitioning (LPAR). However, in your scenario, consolidating the
|
|
30 locations with logical partitioning is not ideal because:<ul><li>The effort required to manage the partitions is approximately the same
|
|
as managing 30 distributed systems.</li>
|
|
<li>Each partition requires an IOP in order to support a load source for the
|
|
partition. As a result, 30 IOPs are required for the consolidated system.</li>
|
|
<li>Additional expansion units are required to hold the IOPs needed for the
|
|
30 partitions. Since each location uses only a few disk units, the expansion
|
|
units might be nearly empty.</li>
|
|
</ul>
|
|
As a result, the LPAR solution is not justifiable from an economic point
|
|
of view for your scenario.</div>
|
|
<p>A better way to solve your particular scenario
|
|
is to use switchable independent disk pools to provide server consolidation.
|
|
By creating one switchable independent disk pool for each of the 30 branch
|
|
offices, you will be able to reduce the number of IOPs from 30 to 7, while
|
|
requiring just two expansion units. This is an economically attractive alternative.</p>
|
|
</div>
|
|
<div class="section" id="scenario__steps"><a name="scenario__steps"><!-- --></a><h4 class="sectionscenariobar">Design</h4><div class="p">To
|
|
understand how to use switchable independent disk pools, see <a href="rzalycreateswitchableiasp.htm">Create a switchable independent disk pool</a>. In addition to the planning and configuration steps
|
|
for implementing switchable independent disk pools, the following strategies
|
|
can be used to ensure that your users at the respective branch offices can
|
|
seamlessly access data:<ul><li>To ensure that users receive access to the correct set of data, your run-time
|
|
environment can be changed to make sure that users from different branch offices
|
|
connect to their data in the corresponding independent disk pool. This can
|
|
be accomplished through a simple adjustment to user profiles and to the job
|
|
descriptions that are specified by user profiles. <p>All user profiles from
|
|
a particular branch office will use one job description. The job description
|
|
will specify the independent disk pool that contains the user's data, and
|
|
create the library list that each job will use. With these simple changes,
|
|
the task of getting each user to the correct set of data is completed.</p>
|
|
</li>
|
|
<li>Another run-time problem to be pointed out is the resolution of duplicate
|
|
subsystems and job queues. Each branch office uses a cloned subsystem description
|
|
to run batch jobs. Each of the subsystems uses job queues that have the same
|
|
name on each of the branch office subsystems. If a single subsystem and a
|
|
single set of job queues are used in the consolidated environment, jobs submitted
|
|
by users from different branch offices will all be placed on the same set
|
|
of queues and initiated by a single subsystem. This results in work flow that
|
|
is inconsistent with the run-time environment of the distributed systems. <p>To
|
|
resolve this problem, the subsystems will be given unique names. Then, a command
|
|
to start all of the subsystems will be added to the startup program. Finally,
|
|
each of the job queues used by the subsystem will be moved into a library
|
|
that is unique to each of the job descriptions that are used by the branch
|
|
offices. As a result, any application that submits a job will require no changes
|
|
in order to submit batch jobs to its unique queue.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzalyswitchableiasps.htm">Examples: Switchable independent disk pools</a></div>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html> |