25. Pain Point System z Power x86
Avoiding downtime Best
Unmatched system reliability and
redundancy of server hardware assets.
Better Good
Managing growth Best
Dynamically add real hardware; share
system resources with multiple
hypervisors in a single machine.
Better Good
Underutilized Resources Best (up to 100%)
Extensive hardware sharing as you scale;
extremely granular sharing of system
resources.
Better (~ 80%)
Moderate hardware
sharing as you scale
Good (~ 50%)
Very little hardware
sharing as you scale
Need for flawless system
monitoring
Best
Superior statistics and operational
insight.
Better Good
Workload management Extensive
Also able to span architectures with
zEnterprise (z/p/x).
Moderate Minimal
Time to market Best
Server cloning can be achieved in
seconds; granular and efficient sharing
of resources facilitates rapid
provisioning.
Better Good
26. Number of Tenants
SizeofTenants
Large tenants
Medium tenants
Long tail of small tenants
Medium Tenants Small TenantsLarge Tenants
Isolation: Databases
Shared: Hardware
Isolation: Tables
Shared: Database
Isolation: Rows
Shared: Tables
MT ApplicationMT Application
MT Application or
non-MT application
Database-as-a-Service and Multi-tenancy with
DB2 on z/OS
Multi-tenancy: multiple companies or users using the same software with a level of
isolation
– Tenants are companies or users that would have historically installed and used a
single instance of software solely for their own use
– Multi-tenancy allows companies/users to use the same software with a level of isolation
Multi-tenancy can further reduce hardware and maintenance costs of DBaaS
Analogous to users running various applications on the same operating system
– The point is to share management and hardware costs among a number of tenants
– Tenants, like the distinct users on an operating system require a level isolation
27. 27
Role and Value of System z
Function Cloud Model z/VM z/OS
Hardware Configuration CMDB HMC HMC
Hw/SW Relationships CMDB System Directory SYS1.PARMLIB
Monitoring ITM Performance toolkit SMF/RMF/OMEGAMO
N
Software configs DSL VMSES SMP
Usage TUAM Performance Toolkit SMF/RMF
Image Repository Hipervisor / SAN System Directory +
Guest MiniDisks
SYS1.PARMLIB + DASD
Provisioning TPM + HiperVisor TPM Support No TPM Support yet
Automation TPAE Netview MPF - Netview
Service Request
Management
TSRM NA NA
Pervasive Security None RACF/ACF2 etc. RACF/ACF2 etc.
28. Multi-System Cloud Management on IBM zEnterprise
The Big Picture Going Forward
SystemzHardwareManagementConsole(HMC)
withUnifiedResourceManager
zBX
Select IBM Blades
Blade HW Resources
Optimizers
IBMSmartAnalyticsOptimizer
z HW Resources
z/OS
Support Element
Linux
on
System z
z/VM
Private data network (IEDN)
System z Host
Linux on
System x 1
AIX on
POWER7
DataPower1
FutureOffering
FutureOffering
Blade Virtualization Blade Virtualization
System z PR/SM
z/TPF
z/VSE
Linux
on
System z
SystemzHardwareManagementConsole(HMC)
withUnifiedResourceManager
SystemzHardwareManagementConsole(HMC)
withUnifiedResourceManager
zBX
Select IBM Blades
Blade HW Resources
Optimizers
IBMSmartAnalyticsOptimizer
z HW Resources
z/OS
Support Element
Linux
on
System z
z/VM
Private data network (IEDN)Private data network (IEDN)
System z Host
Linux on
System x 1
AIX on
POWER7
DataPower1
FutureOffering
FutureOffering
Blade Virtualization Blade Virtualization
System z PR/SM
z/TPF
z/VSE
Linux
on
System z
IBM Tivoli Service Management
IBM Systems Director VMControl
Future
Future
Enables optimal workload placement in a
multi-system cloud infrastructure: spend
less and deliver higher qualities of service
Allows clients to manage all the
hypervisors in a zEnterprise system with
consistency
Extends same management capabilities to
Power and System x servers elsewhere in
the enterprise
IBM Power IBM System x
Note: All statements regarding IBM's plans, directions, and intent are subject to change or withdrawal without notice, and represent goals and objectives only.
32. 32
Enterprise focus on private cloud
Infrastructure as a Service
Development and Test Instances
Best place to start
Quicker instance availability
Change the time to value of development
Easier to demonstrate value
Non production
Sophisticated user profile
Challenges
Cloud crosses multiple Silos
Building consensus takes time
Immaturity of support processes
33. Cloud implementation snapshot
End
Users Service Portal
Service Request
Catalog
Provisioning Engine
Workflows
Expert Systems
Scripts
Optional Service
Modules
e.g. Metering/
Usage Billing,
Monitoring, etc.
Virtualized Cloud
Infrastructure
Easy to access, easy to use Service Request Catalog
Hides underlying complex infrastructure from user and
shifts focus to services provided
Enables the ability to provide standardized and lower
cost services
Facilitates a granular level of services metering and
billing
Workload standardization eases complexity
07/28/15
In today’s economy, many businesses are faced with the challenge of “taking cost out” of their infrastructure while continuing to deliver new , innovative business services - basically they need to “do more with less”
There are two primary levers to achieve cost optimization – operating expense and capital expense, and for many businesses its not just a question of lowering costs its also important to strike the right balance between Op-ex and Cap-Ex
On the horizontal axis, you have virtualization, or the ability to pool the IT resources to reduce capital expense of hardware, software and facilities.
On the vertical axis, is standardization…with common software stacks , operational policies, and improved service management. The farther you can drive standardize the more you reduce operating expense – like labor and downtime – which is far and away the fastest growing piece of the IT spend.
The more standardization you are able to achieve within your infrastructure, the greater the economies of your operating expenses become. Similarly, the more you leverage virtualization within your IT infrastructure, the greater the economies of your capital expenditures will be. So addressing both standardization and virtualization is key to reduce infrastructure costs, while still meeting the dynamic needs of the business.
The need to achieving cost optimization has also provided fertile ground for Cloud Computing. The cloud paradigm is an attempt to improve service delivery by applying engineering discipline and economies of scale in an Internet inspired architecture.
Cloud computing can be an important new option in helping businesses optimize the IT expense equation while maintaining fast, high quality service delivery.
NOTE: If asked to discuss public vs. private clouds:
- A private cloud drives efficiency, while retaining control and greater customization.
- Public clouds today are for processes deemed more easily standardized and a lower security risk.
There some functions that already exhibit a high degree of standardization, that are more easily moved to a public cloud – things like search, e-commerce, and discreet business processes like sales force management.
07/28/15
So we get to the point where we can introduce the concept of a “Service.” We’ll use this for the rest of this workshop. The top of the chart offers the definition, with further explanation about what some of the keywords are relating to. For now, let’s focus on the picture.
A “Service” is a something that someone else can use … or in computer language, “invoke.” To use or invoke a service, the requester (or service “consumer”) needs only to know that the service exists, where it’s located, and what’s required to invoke it and what can be expected in return. In this sense the service has a kind of standardized, defined set of input and output requirements.
Note: a service does not need to be a computer program. It can be a human behind a desk who does something on your behalf. But for the purposes of this workshop, we’re focusing on a service being a computer-implemented thing.
The key to this is that the actual implemention of the service -- what goes on behind the interface, in other words -- is something the service consume doesn’t care about. I don’t care how the Post Office gets my letter from here to there … all I know is that I have to put an address and ZIP code on the envelope and turn it over to them.
There’s absolutely nothing revolutionary about this. We’ve been striving to achieve something like this in the computer industry for decades. (Subroutines are a kind of “service,” the whole client/server thing had elements of this in mind, distributed objects and remote procedure calls also share this basic notion.) What’s different is the times in which we live -- things have come to be that facilitate SOA much better -- a common networking protocol (TCP/IP … you can’t begin to imagine how important it is that debate is over); cheap and readily available bandwidth; the coming of age of industry standards … not only the standards but the idea of embracing standards rather than seeing them as a threat; and finally Java as a kind of common runtime language. All have made the adoption of SOA much easier. Let’s now look at an example of a service.
At this point we need to pause and point out that “Service Oriented Architecture” means different things to different people. It depends on what perspective one takes. To the IT specialist or architect, they’re going to view “services” as IT-related components. So to them the hypothetical shipping and receiving application flow is represented by a series of IT components -- a service to match a received shipment to the purchase order; another service to make sure the quantity received is equal to the quantity ordered; another service to reserve the stocking location in the warehouse, etc.
But to the business manager or consultant, they’ll be viewing it not necessarily as computer-related application functions, but discrete functional components of the business.
Both views or perspectives are important, and they serve different purposes. Both will be part of any SOA discussion, depending on who you’re talking to. We bring this up because this is why you’ll see many write-ups on SOA switch between pure computer talk to business-speak, and back again.
Now we can try to define what “Service Oriented Architecture” means.
Again, imagine you’ve built up an inventory of reusable services, all with defined interfaces. Now you’re getting ready to construct a new application (we’ll call it “Application A”). Rather than rewrite the same function over again, or do “tightly coupled” things like link-edit the other function into the application or make sure some CLASSPATH is updated, all you need to do is code the new application to go out and invoke the services in the order it needs. The whole application probably won’t be just invoking one service after another, but hopefully a large portion of it will be that.
But here’s the value -- imagine you’ve got two other applications -- B and C -- and they also need to use some of the same services as Application A. All those applications would need to do is invoke them. Application A doesn’t need to know about B or C at all. Further, if you ever had to go into those two services that all the apps are use -- “Process Backorder” and “Request Stock Replenishment” -- and tweak the internal implementation, applications A, B and C remain unaffected … provided the interface remains as it was.
This is good … the connectivity has been decoupled a bit. This helps illustrate the benefits of reuse.
We mentioned how WebSphere is an excellent and natura HTTP handler. That means it can host a Web Service. That service will be written in Java as an EJB or a Javabean. It will provide the interface for the service. The implementation of the service -- what does the actual work -- is whatever you create behind the interface.
That implementation has available to it all the resources WebSphere Application Server itself provides. This includes the full range of “data connector” technologies that permit access to data outside of WebSphere Application Server. The chart above shows you what those include.
The final point listed on the chart above is one that should be noted. If the data resource and the WebSphere Application Server web service is co-located on the same MVS image, there are benefits related to that proximity. In many cases cross-memory speed can be realized accessing the data. Or, if the connection is TCP, then a reduced code-path TCP connection service can be used that greatly speeds up communications.
Performance and Scalability
70% system capacity performance improvement over z9 EC 54-way
Networking and connectivity
Policy-based networking helps create a network responsive to your application needs
Availability
Basic HyperSwap for high-availability disk, continued Parallel Sysplex clustering and GDPS enhancements
Simplified Operations
New z/OS Management Facility: Support for a Web-based management console for z/OS
Energy Management
z10 EC displays energy efficiency on SAD screens
Utilizes IBM Systems Director Active Energy Manager for Linux on System z for trend calculations and managing other servers