Capacity Planning in Distributed Environments
Download
Report
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