Transcript Capacity Planning in Distributed Environments

Capacity Planning in
Distributed Environments
Dr Bernie Domanski
City University of New York/CSI
Should Capacity Planning Be
Treated With the Same Reverence
As in the Past?
Let’s all sing the hymn “But That’s How We’ve Always
Done It.”
©B. Domanski,1997. All Rights Reserved
2
Objectives & Agenda
 View IT as a Service Provider; focus on service
delivery for the survival of the company;
 Does doing CP the same old way make sense
because “That’s How We’ve Always Done It”?
 Does the mainframe costing model make sense
today?
 When does make sense to do CP ?
 There are alternatives to complex tools that model
down to the disk revolution.
©B. Domanski,1997. All Rights Reserved
3
The Key Message
CP in a distributed environment
should allow IT to make intelligent,
cost-effective decisions regarding
the resources required that will
rapidly enhance the service given to
its customers.
Moore’s Law - Capacity
Doubles Every 18 Months
Intel Microprocessor Evolution
MIPS
# of Transistors
T
r
a
# n
s
o i
f s
t
o
r
s
100000000
100000000
10000000
10000000
1000000
1000000
100000
100000
10000
10000
MIPS
1000
1000
100
100
10
10
1
0.1
1970
1975
4004 8080
1980
8088
©B. Domanski,1997. All Rights Reserved
1985
1990
80286 80386 80486
Year
1995
Pentium
1
2000
PC2000?
5
Service Delivery
• Timely delivery of services to
customers
• Global view of resource use
• Cost mainaining a CP staff - what is the
ROI? Cost of studying vs. just buying!
• The difference for making mistakes is
orders of magnitude different in price.
©B. Domanski,1997. All Rights Reserved
6
What’s the Real Reason to Do
Capacity Planning?
• If mission-critical business applications
become overloaded,
• Then poor performance could have a very
serious consequence:
• Revenue can be lost if dissatisfied
customers move to the competition.
• If you can't do it right yourself, pay
someone else to do it for you!
©B. Domanski,1997. All Rights Reserved
7
Key Questions
• Providing too much capacity? Ties up $$$
• When is CP done? If that new appl could
negatively impact customers
• Why is CP done? To be competitive; new
features/functions implies sizing the
underlying architecture correctly
• What about business vs. technical
requirements? Needs are ASAP and cheap
=> use modeling for broad evaluations
©B. Domanski,1997. All Rights Reserved
8
Scaleability and Compatibility
• Success is a lousy teacher - Bill Gates
• Out-of-date? 8-track tape player,
vacuum tube television, or the monolithic
mainframe computer.
• The key to understanding mistakes is
the need to initiate rather than to
follow trends. Let’s look at some actual
history:
©B. Domanski,1997. All Rights Reserved
9
History
• 50’s / 60’s: Different machines/op.
Systems for different computing
purposes
• 65: IBM/Tom Watson => scaleable 360
architecture; you could move your work
up
• DEC/Ken Olsen => PDP alternative; VAX
in 77 offered scaleability too
©B. Domanski,1997. All Rights Reserved
10
What’s the Lesson Here?
• IBM & DEC saw a need that business had …
– to fill incremental computing needs in
different ways ...
– … without having to waste prior IT
investments
• This same need is still with us today!
• Need more computing power? Get it for
the mission-critical application software
©B. Domanski,1997. All Rights Reserved
11
Market-driven Compatibility
• Originally is was difficult and expensive to
“change brands”
• Amdahl, HDS, StorageTek, EMC => where
would we be today?
• Proliferation of UNIX
• IBM PC clones - Look at Apple!
• Internet acceptance: Netscape, IE cross
platforms
• JAVA allows dynamic distributed systems
©B. Domanski,1997. All Rights Reserved
12
CP is Driven by New Business
• What Drives CP for Distributed
Systems?
– Scaleable architectures
– Market-driven compatibility
• The key: the network - it’s the glue!
• CP becomes less about counting MIPS, &
• … becomes more about being driven by
anticipated new business that has to be
processed
©B. Domanski,1997. All Rights Reserved
13
WhadaWeWant?
• we want to scale our applications up to
process more work;
• we want them to run on the new hardware
we acquire;
• we need to connect applications (i.e. data)
that currently exist on different platforms;
and
• we don’t want to re-invent or convert
anything, if we can help it, to keep our
costs down and our productivity up.
©B. Domanski,1997. All Rights Reserved
14
Bill Gates “It’s a little hard to appreciate how far we’ve
come from the good old days where just to get
the sales report formatted in a nice way, you
might wait nine months! …
we’ve really gone way beyond anything that
ever happened on the mainframe. …
you really will be able to do simple, multiserver
applications. Just sit down, write a few lines of
business logic, and boom - connect all that up.”
©B. Domanski,1997. All Rights Reserved
15
Sam Greenblatt - CA’s Senior VP of
Advanced Technology
“Integrating application, system and
network management is helpful only if it
yields useful business information.
Nobody cares whether or not a system is
down if it doesn’t impact their business.”
©B. Domanski,1997. All Rights Reserved
16
Is Capacity Planning a Checkoff Item?
• Rather than burden the planner with
commodity shopping, users took on that
responsibility.
• Do we even need CP any more?
– it might be easier to just buy new gear
when you need it, period, and not do any
Capacity Planning at all!
– Consider, too, the cost of doing a CP study
©B. Domanski,1997. All Rights Reserved
17
More Important Questions
• Is the network yielding adequate
performance?
• What should we get/do if it isn’t?
• How are scaleable distributed appl’s
built?
• How many more users can be added
while preserving response time?
• We seek a new perspective that is more
closely tied with application-specific
measurement.
©B. Domanski,1997. All Rights Reserved
18
Key to CP Success
• Delivery of IT services, where ...
• Scaleability and compatibility are key.
• Deploying new applications on a specific
architecture may be wonderful today, but
• … may become disastrous tomorrow if that
architecture becomes a dinosaur and
new/faster/cheaper gear is available.
©B. Domanski,1997. All Rights Reserved
19
YOU MUST ...
• become application savvy
• understand the network.
• focus attention identifying the parts of an
application that won’t scale up well
• offer alternative solutions.
• keep compatibility across platforms at the
forefront of your thinking.
• be able to anticipate bottlenecks and
propose alternative components
©B. Domanski,1997. All Rights Reserved
20
Tools to Help Find How Much Capacity is
Needed
• Cottage industry originated for the
mainframe
• Costs: $20K = $120K (*MXG)
• Not meant for distributed applications
• No end-to-end response time
measurement
• Queuing models ignored the network
• No standout predictor of workload
growth
©B. Domanski,1997. All Rights Reserved
21
Needed Measurement Tools
• Populate a PDB with data from distributed
applications
• Display status of every resource in the
distributed environment + drill-down
• Need summarized data across systems for
trending
• Need simulation models along with queuing
©B. Domanski,1997. All Rights Reserved
22
Just-in-Time Capacity
• Use the tools …
– monitors
– collections of performance data
– models
• … to find when to add more resources
• Adding at the right time implies:
– no interruption in service quality
– no paying for services before they are
needed
©B. Domanski,1997. All Rights Reserved
23
Costing for Distributed Systems
• A great advantage is being able to buy
needed capacity in small increments.
• Scaleability is key for capacity planning
• You buy enough capacity to do your
processing now ...
– if additional capacity is required in the
future,
– then it is acquired at a reduced unit-cost
– because of the constant improvement in
price/performance ratios.
©B. Domanski,1997. All Rights Reserved
24
Is Costing That Simple?
• Incur both acquisition and installation
costs.
• Over time, you incur operational costs
(licensing fees, support personnel, and
maintenance).
©B. Domanski,1997. All Rights Reserved
25
What Happens When Additional
Capacity Is Needed?
• Yes, you acquire a bigger server, but
• Most companies would rollover the server
• Causes a cascading effect, … costs that
have to be incurred when installing each
old machine in a new place, e.g. installing
new software, testing, support personnel
costs, etc.
©B. Domanski,1997. All Rights Reserved
26
Leilani Allen
”By the year 2000, it will cost more to keep
old technology than to upgrade.”
Bottom Line: change the focus of financial
mgmt strategies from acquisition.
The realities of the life-cycle of equipment
dictate that ongoing operational costs
demand more attention (consider rollover)
©B. Domanski,1997. All Rights Reserved
27
Service Levels
• Service level measures should be
reported by business unit and
application – availability,
– response times and
– workload volumes
• Obstacles:
– client instrumentation
– different communication paths/protocols
©B. Domanski,1997. All Rights Reserved
28
ARM
• Transaction instrumentation becomes the
applications’ responsibility
• ARM SDK addresses appl’s written in
– C/C++,
– MicroFocus COBOL,
- Visual Basic,
- Delphi
• Approach systems management from the
end-to-end appl. workload perspective,
rather than as a collection of physical
components.
©B. Domanski,1997. All Rights Reserved
29
Summary & Thoughts
• The critical questions we must face -– Is CP helping IT deliver the best
service possible to its customers?
– Are you building scaleable
architectures that have marketdriven compatibility?
©B. Domanski,1997. All Rights Reserved
30
More Key Questions to Ask
Yourself !
• Perhaps a “checkoff” item CP philosophy
may prove to be a real cost saver
• Include the true costs associated with
adding incremental capacity.
• Without application-level instrumentation
across platforms, service-level
management across the enterprise may
not be possible
©B. Domanski,1997. All Rights Reserved
31
More of What We Need
• Reporting software must manage the volume of
customer data across platforms,
• It must address the network, the client and the
server.
• We need graphical modeling tools to make it
easier to define the network
• Modeling tools must be able to model any
combination of hardware & software
• Need predictions of IT service and usage from
a global perspective as well as a detailed
focused perspective
©B. Domanski,1997. All Rights Reserved
32
That’s It For Now!
Thanks for listening
Any questions???
Dr Bernie Domanski
Phone: 732-303-1500
Fax: 1503
Email:
[email protected]
©B. Domanski,1997. All Rights Reserved
33