Hello. I am Joe, I am a Solution Architect at Hewlett Packard Enterprise.
Today I am going to talk to you about OneView, our infrastructure management solution.
OneView is quite a mature product. It has been in the market for around 4 to 5 years now
and we use it as the basis for monitoring and managing a number of products within the HPE portfolio.
It is also a constituent part of the Synergy Platform.
OneView has a few key unique features.
Before I get into the features, I want to explain to you how OneView does what it does.
OneView provides a consistent interface for connecting to our server products like
HPE BladeSystem, Apollo, and DLs, our storage environments, 3PAR and Nimble,
and our networking technologies, both in form of Virtual Connect,
FlexFabric top-of-rack, and a few select third-party solutions
to provide a consistent interface within that datacenter.
OneView lets us interact with a number of third-party vendor solutions
and a number of software providers through a single REST API.
That single interface is one of the key features of the HPE OneView solution
because it gives us consistency across all of these environments.
There are not needs for a separate API for each of these, not one tool for the server environment
and a different tool for the networking environment. OneView gives us that single view of everything.
The REST API is also how the user interface is accessed,
so the same things that are available natively within OneView´s user interface
are available to scripts and to third-party integrations.
This has really driven the growth of quite a mature ecosystem around OneView
and the support of a number of different management and monitoring tools
and provisioning tools as well, such as Ansible, Chef, and Puppet.
To do this, OneView leverages a few key principles.
The first is this ability of having software-defined profiles for everything in the environment.
You will have a profile for an individual server, a profile for a volume on a storage array,
a profile for a network connection.
These profiles can be aggregated up into templates to make things easy to repeat
and to reduce operational overhead and ensure operational consistency.
I can take a simple template that contains values for an individual property,
and I could deploy those many times to stamp out multiple instances of the same profile.
that massively improved my ability to automate an environment
and deliver infrastructure quicker to the line of business to deploy applications onto.
What I can also do is, if I am making a change, if I want to change a property for something else,
when I change the template,
I could make sure that that gets automatically updated into all of its deployed profiles.
Again, ensuring consistency, making it easier to make changes within that environment.
OneView also provides an ability to have a global search function.
Now the global search function allows a user to log in to OneView, enter in some parameters,
such as a MAC address, or worldwide name associated to a volume
and pull out all of the resources that relate to that for that environmental parameter.
That makes it much easier to diagnose problems quicker.
Partnered with our activity log, which records all of the changes to both profiles, templates
and physical assets, you can track the changes in environment much better than we would be able to,
were it not for this global search.
We also have the ability to use Map View within OneView,
which allows us to relate different components together through those sort of common elements,
like profile templates, and hardware attributes.
For instance, we could work out whether doing a particular firmware upgrade
would affect my ability to provision a certain network.
Is that network going to be affected if I change the firmware on these hosts?
What is the scope of a network parameter change? How many hosts will it affect?
What storage devices are reliant on that network being provisioned?
All of these attributes that are hard to interrelate when you have multiple tools
become much simpler when we move to HPE OneView.
A great example of how we can enforce this operational consistency could be in SAN provisioning.
For instance, you may have a blade enclosure with multiple hosts, all running a virtualization software.
These could be connected to SAN infrastructure that is managed by HPE OneView.
And all of that is connected to storage arrays, again under the management of HPE OneView.
When I create a new profile on one of these hosts for a storage connection,
all of the necessary SAN zoning information goes into the SAN through the creation of that profile
Then a data volume, for instance, gets spun up on the storage array here
that can all be done from a single line of code through the OneView REST API
in a way that we have not been able to do with multiple disparity tools.
That's really the advantage of HPE OneView.
Another use case could be the facilitation of adding a new network
to connect into some of these server environments.
Typically, we have a computer node connected to a pair of networking switches.
These might be cross-connected as well.
When I provision a new network on one of these switches, what we are able to do within HPE OneView
is make sure that the host is receptive of that network, so it has a new port on that network.
The switch expects the network present as well.
And we do those connections through that server profile, I might add, in a line that says,
“hey, there is my new server profile connection to this particular network”
and OneView makes that provisioning step happen, either through addressing these modules
as Virtual Connect or as FlexFabric,
whichever is most appropriate for that particular deployment.
If you want to find out more about what OneView can do, you can go to the HPE.com/oneview website
where there are a number of videos, white papers and further information on HPE OneView.
I hope you found this useful.