This 8 week online course equips learners with the basics of network virtualization with VMware NSX. To get the most of this course, you should have familiarity with generic IT concepts of routing, switching, firewalling, disaster recovery, business continuity, cloud and security. At the end of the course, you will be able to: • Understand network virtualization basics • Describe NSX business value and use cases • Explain how NSX is different from traditional networking • Summarize networking and security solution architecture with VMware NSX around these key areas: + Micro-segmentation + Automation with OpenStack + Automation with VMware vRealize Automation + Disaster Recovery and Business Continuity + Operational Transformation • Demonstrate understanding through hands-on experience • Develop a learning plan for network virtualization certification If you are new to network virtualization, download our Network Virtualization for Dummies guide. http://learn.vmware.com/36350_NSX_ITAutomation_Reg?src=af_5acfd24cebb90&cid=70134000001YR9b
People Evolution: Operational Transformation (3 of 4)
Loading...
来自 VMware 的课程
Networking and Security Architecture with VMware NSX
5 个评分
从本节课中
Operations (part 2 of 2)
The content covers process automation with VMware NSX using common cloud management platforms like OpenStack and vRealize Automation. In addition the content describes the need for new tooling that provides converged and correlated data of new data center technologies. Finally, the module explains the importance a growth mindset and the evolution of IT organizations away from rigid, well-defined silos to a more collaborative, cross-functional workforce.
与讲师见面
Chris McCainDirector of Product Management
Networking & Security
Moving on to part two of this module,
we're going to talk about operational transformation for your processes.
In this section, we're going to talk about change management,
configuration management, incident management,
capacity management and provisioning.
These key processes are not just impacted by NSX but significantly impacted by NSX.
Because of what we saw in
the people transformation part and the significant change with people,
when it comes to tracking change,
tracking configurations, tracking incidents and capacity and provisioning,
if we can bring the people together,
it certainly impacts these five areas of our processes in the organization.
Change Management.
This is the decoupling of physical infrastructure,
the ability to isolate services and the standardization of efforts in order
to streamline and reduce change management activities, that's our goal.
The current model, we have a request for change process.
So we fill out a form or we send an email to somebody and we say,
''Hey can we make this change?
How long does it take? Depends, right?
Depends on the significance of the change,
it depends on the significance of the change as it impacts the environment, right?
A change that's going to impact a lot of the environment will take
a little more time to really figure out how we're going to implement the change.
Normal changes are categorized according to risk and impact to business,
and that change approval board that takes
the RFCs can often take days if not weeks to make their decisions.
Depending on the type of change,
it will be put in production manually and then validated,
and hopefully without causing downtime or unforeseen problems.
In our new model,
we would like to be able to perform change as quickly as
possible and with little impact to the environment.
So, using NSX for your networking and security something
as simple as a firewall rule change can be performed quickly
to a service that is isolated by going through a localized Change Advisory Board.
So, because the change has been isolated to a particular virtual machine or
a particular segment of the infrastructure and we know
that that is not going to impact a larger set,
then we can have a localized decision being made as
opposed to having to send that RFC up to a higher level.
Policy change requests will involve
service-specific teams within the process
that change can go through validation in advance,
and then reducing change management activities in
the physical infrastructure by being policy-based instead of manual.
So, policy base is a very important part of your process change.
If we're going to get away from doing things manually,
then what we'd prefer is to create policies,
to create reusable objects that support requirements for something new or for a change.
That way we can change policy as opposed to applying change to architecture.
If the policy has already been defined,
and the policies already have been approved,
then it's simply a change in policy,
it's not a change in underlying architecture.
So here's a little self assessment.
Think about what you do on a daily basis.
Think about how much of that is done over and over and
over again versus how much of that is done in a unique fashion.
How much of that would you like to be able to automate?
How much of those processes can be changed so that
the repetitive tasks can be done without you,
and then all you have to focus on is
either other projects that add more value or handling
those one-off or more unique configurations which should be
the minority of the requests that you get in your environment.
So if you're looking at this thinking,
you know most of the stuff I do,
let's say 80 percent of the stuff I do is repetitive and 20 percent is unique.
Well there's a lot of opportunity there to leverage automation,
to leverage a change in process to give you a lot of time back.
Configuration Management.
Automation through blueprints and templates will simplify
configuration management and configuration assurance tasks.
So in the current model, we discover and track
configuration items and we maintain that relationship
between the change and the objects and
the people in some type of change management database.
We utilize the relationship,
information during the incident and the change management activities,
and we keep records of configuration changes to
the infrastructure all the while manually recording this,
manual configuration audits to see
what changes have been made or what changes we want to make.
In our new model, the logical components for a service or an application or
a virtual machine are tracked in the in
the Cloud Management Platform as part of the blueprint.
So, now rather than having to go change something that I'm using to deploy manually,
if I can make that change in a blueprint,
then it's recorded as part of the change or Cloud Management Platform rather.
The networking and security changes are captured
dynamically through APIs and tools like vRealize Operations,
and then tools like Chef and Puppet can be used to maintain
configuration consistency or your manager for a particular application.
It's also possible especially if you're leveraging
full-blown automation through a Cloud Management Platform that you can modify
the workflows to support an automatic update into the change management database.
So let's say that I have a blueprint that creates a virtual machine,
and that virtual machine is created with one single CPU,
eight gigs of memory connected to a network,
put into a security group with security policy, right?
So all of the constructs for that application are created as part of the blueprint.
But somebody wants to change this virtual machine and go from a single CPU to two CPUs,
or they would change the network that it's connected to something like that.
We can build into the workflows in
the Cloud Management Platform that when that change is made and submitted,
that the Cloud Management Platform
communicate with the Change Management Database in order to
update and now we know that change has been recorded without manual effort.
Incident management.
Incident management should be centralized and
streamlined with less triaging and escalation,
monitoring and troubleshooting through application aware and
virtual and physical context tools.
The current model, again very silo specific,
monitoring and troubleshooting tools that are focused on infrastructure,
ticket flows across multiple domain-specific experts,
and then triaging with lots of coordination and communication between multiple groups,
maybe even back and forth multiple times between these groups.
We're very reactive in our incident troubleshooting and remediation.
In the new model,
the application aware and
the virtual and physical visibility tools actually
help us identify issues in a much quicker fashion.
If we have tools that show us how packets flow between physical and virtual networking,
then we have the ability to quickly identify where an issue is and resolve that issue.
Once we've been able to make the people transformation,
once we've been able to bring together
these different silos into a more cross-functional team,
now the tickets don't have to flow between different silos,
it flows to a single, integrated team.
This integrated team, just by sheer nature of being
integrated is now better equipped to solve the issue with fewer escalations.
I don't have to go outside the team.
I don't have to go find a different expert to solve the problem
because the team is made up of individuals that have cross domain functionality.
So, less time is spent on trying to figure
out how we communicate or who we should communicate with,
which gives us then more time to spend on solving the problem,
which then leads to faster remediation of the problem.
So ultimate our incident management is significantly
improved because of the change in people that we make.
Capacity Management.
Capacity management helps infrastructure service providers understand the demand
for resources and the capacity utilization of the services offered.
In the current model we have individual infrastructure capacity tools,
tools to look at compute,
tools to look at networking,
separate tools to look at storage,
and then provide the reporting processes to collectively look at this information,
or individually within silos.
Reports are used to forecast demand and capacity planning
across the different domains without consideration for the other domains,
and we often have a long lead time for purchasing and deploying new capacity.
In the new model,
we want tools that provide
capacity information across the entire software defined data center.
We want that converged correlated look at the different components including compute,
and storage, and networking, and security.
We want our reports to be used for forecasting demand
and capacity holistically across the environment,
and we want to be able to dynamically allocate
new capacity quickly and potentially automatically.
Here's an example of a capacity management situation.
In the top diagram,
we have an organization that has used some type of
older pod type design for their data center and the boundary for the pod,
it could be compliance requirements,
it could be IP boundary, right.
So each particular pod is responsible for
a certain set of IP addresses within the environment.
The problem with this type of design is that we end up with
hotspots in the data center or areas of significant utilization,
areas of less utilization.
So you can see in this diagram between the orange, the green,
the blue and the red that the green,
the orange and the blue have more utilization than the red.
So if the green continued to experience growth
and we continue to add resources and add resources to the green,
the green is going to run out before any of the other pods run out.
But we wouldn't be able to take new workloads characteristically destined for green
and put them in the red pod because of
the artificial boundaries that were created as part of the design.
So, really from a capacity management perspective,
we would now have to go purchase additional capacity for that green pod
in order to support despite the fact that we have plenty of
capacity leftover among the other pods.
Leveraging something like NSX,
where we can now take layer two and stretch it across clusters or we can leverage
the distributed firewall for micro-segmentation for
PCI compliance or HIPAA compliance or whatever regulation you might have,
we can actually re-architect the way that
workloads are dispersed across all of the cluster.
In the bottom diagram,
leveraging NSX for stretching layer two or micro-segmentation,
you can see that now our workloads orange,
green, blue or red can run on any of the clusters.
If we migrate the workloads to get better utilization of our resources,
you can find that we can, in fact,
completely evacuate some of the resources that we have.
So there would be no need in the bottom situation to have to purchase
additional capacity because we wouldn't be reaching
the limitation that we had in the first pod design.
And finally, provisioning.
So provisioning,
customers are using cloud management platforms and
orchestration tools to automate the provisioning
of networking and security with more speed,
efficiency, consistency and a reduction in operating expenditures or OpEx.
In the current model however,
the app team opens a request that
generates multiple tickets with the different infrastructure teams.
Finance decides, ''Hey, we want to deploy this new
application," or sales decides they want to deploy this new application,
they have to get all of the components for this application
deployed before they can actually install the application.
So they'd have to call networking to get some networking.
They'd call security to get security.
They would call the virtualization team to get the VM.
There's a lot of different tickets.
There's a lot of timing that all has to come together in order
to finally get that virtual machine to deploy the application.
That physical infrastructure that they request might be configured
manually to a command line interface or maybe there are scripts but either way,
there's a process for getting that done.
By having to have multiple groups within IT that get involved,
we introduce a complex coordination between these groups,
all of it leading to a longer time to market for this application.
In the new model, our workloads for
these applications three-tier applications, multi-tier applications,
it doesn't matter, our networking and security are
going to be provisioned along with the virtual machine.
The compute, the storage and network and security,
all come together within minutes.
The virtualization infrastructure is provided via the blueprint.
That blueprint was created by
the architecture team by communicating to the application owner,
''Hey, if we deploy this application,
exactly what information do we need?
Exactly what components do we need?"
The networking steps in to say,
''Hey, are we deploying a new network?
Are we going to connect this to an existing network?"
The security team steps in and says,
''Hey, what type of security does this need?
How does it communicate?
What pods does it communicate on?
Do we have a defined policy already for this?
Is it something where we need a new policy to create?''
All of these different individuals working together as part of this architecture team
to create these blueprints that give us
a standardized configuration to be deployed in minutes.
This cross-functional team of SMEs,
they build the automation quickly.
There's no hand-off in this situation.
Once they're done, and the blueprint is built,
we don't need to go back to the architects again.
The self-service portal will allow the instantiation of
that application and they're comfortable because they designed the blueprint.
There might be a revisiting.
We might come back to it to say, ''Hey,
do we need to make any changes at some point?''
But that change again will now be localized to that blueprint.
We don't have to make
architectural changes to the physical network or to the cluster design,
it's a blueprint change localized within the automation engine.
So here are some topics to think about with regards to process transformation.
With regards to change,
how might you optimize change management in your environment based on NSX capabilities?
What challenges might you face and how will you address them?
For configuration, how might you optimize
configuration management in your environment based on NSX capabilities?
How might software-defined networking and security
simplify configuration drift detection and remediation?
For incidents, what concerns you about troubleshooting a software-defined networking and
security environment during a high pressure incident
related situation in your current environment?
This is a key area to think about because this often
becomes one of the hurdles to any new technology.
People understand exactly how to troubleshoot if there's a problem today.
Bringing a new technology,
same troubleshooting processes don't necessarily apply.
And so, now we're thinking, ''Wait a minute,
I don't know if I want this new technology because I'm really
comfortable if something happens today,
high pressure situation, I know how to get in and fix something.''
Bringing in a new technology high pressure situation,
if I don't know how to fix it,
all eyes are on me to try and fix it.
But you have to think about this as part of the engineering effort,
as part of the operations effort and certainly as part of
the people transformation when it comes to educating and learning.
Capacity. How might software-defined networking and
security ease your capacity challenges?
And then finally, for provisioning.
Are your customers satisfied with how long it takes you to provision workloads?
Are the different business units within your organization
satisfied with the time to market for a new application that they've requested?
What other innovative activities could you undertake if
resources were freed up by automating your provisioning?
