The basic model for management has been around for years and is based on a very simple and logical hierarchy: You start with devices to build your network, which means you start with element management to manage them. Your network, which comprises a cooperative group of devices, uses a network management system to secure its interconnections, while a service management system adds the necessary service-to-network awareness.
It's a great model -- a model with decades of history behind it -- but it's also a model that's now obsolete thanks to virtualization.
The industry doesn't have all the answers to virtual management yet, but we have made some progress in defining management models and controlling management traffic.
Virtualization has its own management model based onabstraction and instantiation. You start with an abstract service or appliance you want to deploy -- perhaps a router or set of routers, or a VPN service built on that set of routers. Then, you deploy that abstraction by committing virtual resources -- compute power, applications, data storage, virtual connections, whatever -- to implement it. Even in this simplified description, two truths about virtualization become evident.
First, virtualization can skip all the lower-level steps between services and resources, which in turn means skipping all those nice management processes normally at that stage. But if virtual networking enables cloud providers to create virtual network services by directly manipulating virtual devices, then it's reasonable to assume that the virtual devices wouldn't know anything about their contributions to services as a whole, nor their relationships with each other. Lost in this is the management context -- that is, the ability to relate the pieces of a service to the service as a whole, and vice versa.
Consequently, virtual network management requires providers to keep a record of the relationships established when a service is created, so they can recover the management context later on. This is a critical step that's almost always skipped in cloud networking, which usually builds services as software overlays that don't have any specific link with network equipment. You can build best-effort services this way but not SLA-based, contract-committed managed services.
The second observation about virtualization is that the abstract resources it creates differ from their physical counterparts. You don't build a virtual switch, router or firewall using the real form of those devices; you use hosted, software-based functionality instead. This complicates the management picture even more. For example, a virtual firewall might actually be made up of several hosted processes and a couple of network connections between them. If this firewall were a physical device, we could send an SNMP command to read its management information base (MIB) to check its status. But since there is no physical firewall component in our virtual network service, there is no MIB to read. Even if there were an MIB for each component, how would that MIB data be related to the function of virtual firewall? We would also have to consider the state of connections between the components -- connections that wouldn't even exist in the physical world.
Apart from these two strategic issues with virtual network management, there is a single practical issue. Imagine a dozen physical servers with virtual machines (VMs) in several different data centers, with the latter linked by a fiber trunk. Now, imagine how the virtual network services spread across this complex would behave. There might be a thousand customers and two thousand services, with 12 servers and one inter-data center link. To discover the status of any service, we would have to check the management interface of the resources that service uses, thus leading to thousands of services making such requests to just a few resources. That's an explosion in management traffic on the network and a heavy load on resources just to answer management inquiries.
Emerging management models for virtual network services
The industry doesn't have all the answers to virtual management yet, but we have made some progress in defining management models and controlling management traffic. Both are likely to be refined as virtual management experience grows.
On the traffic side, the IETF has been working on a project called Infrastructure to Application Exposure (i2aex), which would create a management repository by having systems process poll resources for status and collect the results in a convenient location or locations. Applications would then go to the i2aex repository for data instead of trying to get management data directly. The repository could also push changes to applications rather than asking them to poll repeatedly.
In management models, we're seeing two approaches develop. One is the virtual device model, where software-defined or virtual network functions include a management element that represents the virtual device they create. Because you can compose the management element in whichever collection of these functions is most convenient, this model offers the potential to create virtual devices based more on convenience of management than on strict functionality.
MORE ON MANAGING VIRTUAL RESOURCES
FAQ: How to address common virtualization management problems
Network functions virtualization may be key to scalable networks
Tips for managing virtual resources in a Hyper-V environment
The other model is the service-derived operations model, where collections of functions are defined to create services. For example, using the TM Forum's Information Framework (SID) GB922 service domain model, cloud providers can define the management relationships at the same time as they define service compositions. As a result, a generalized process can deliver a management view at any point -- eliminating per-service management elements completely.
Despite skepticism in the market that current OSS/BSS systems are unsuitable for new virtualization-based services, operators are largely committed to evolving these systems rather than replacing them. The combination of a unified data model and a service-derived operations model appears to align with operators' future goals in virtual services management, while also retaining a connection with current OSS/BSS software and practices. In fact, operators hope that these ingredients will frame the evolution of the TM Forum specifications and their own OSS/BSS systems, preparing operators for a new cloud-driven, virtualization-based future.
Posts
0 comments:
Post a Comment