Cisco Cisco Prime Virtual Network Analysis Module (vNAM) 6.0 Livre blanc
3-4
Cisco Virtualized Multiservice Data Center (VMDC) Virtual Services Architecture (VSA) 1.0
Design Guide
Chapter 3 VMDC VSA 1.0 Design Details
VMDC Building Blocks
PoD
Previous iterations of the VMDC reference architecture defined resource containers called "pods" that
serve as the basis for modularity within the Cloud data center (
serve as the basis for modularity within the Cloud data center (
). As a homogenous modular
unit of network, compute, and storage resources, the pod concept addresses environmental, physical,
logical, and application-level requirements in a consistent way. The pod serves as a blueprint for
incremental build-out of cloud data centers in a structured fashion. When resource utilization within a
pod reaches a predetermined threshold (for example, 70% to 80%), the idea is that one simply deploys
a new pod. From a service fulfillment and orchestration perspective, a pod represents a discrete resource
management domain.
logical, and application-level requirements in a consistent way. The pod serves as a blueprint for
incremental build-out of cloud data centers in a structured fashion. When resource utilization within a
pod reaches a predetermined threshold (for example, 70% to 80%), the idea is that one simply deploys
a new pod. From a service fulfillment and orchestration perspective, a pod represents a discrete resource
management domain.
Figure 3-2
Pod Concept
In practice, the pod concept can serve simply as a framework, with designers defining variants tuned to
specific environmental or performance characteristics. A pod can be defined at different levels of
modularity, supporting growth in differing increments. For example, one could have an access pod,
terminating at access switching nodes within an infrastructure; and one could have a compute pod,
addressing only the compute or the compute and storage portions of the infrastructure. Special-purpose
pods can be defined around application requirements or operational functions. For example, in the
VMDC reference architecture, a management pod, called a Virtual Management Infrastructure (VMI)
pod, is defined to physically and logically separate back-end management resources from production
resources.
specific environmental or performance characteristics. A pod can be defined at different levels of
modularity, supporting growth in differing increments. For example, one could have an access pod,
terminating at access switching nodes within an infrastructure; and one could have a compute pod,
addressing only the compute or the compute and storage portions of the infrastructure. Special-purpose
pods can be defined around application requirements or operational functions. For example, in the
VMDC reference architecture, a management pod, called a Virtual Management Infrastructure (VMI)
pod, is defined to physically and logically separate back-end management resources from production
resources.
Previously in the VMDC reference architecture, a general purpose utility compute pod extended from
the compute and storage layers to the L2 ports on aggregation nodes serving as the L2/L3 boundary, up
to and including components in the network services layer. In a traditional hierarchical topology model,
the port and MAC address capacity of the aggregation nodes were key factors in determining scale. Port
and MAC address capacity limited the number of pods that a pair of aggregation nodes could support in
a cloud data center.
the compute and storage layers to the L2 ports on aggregation nodes serving as the L2/L3 boundary, up
to and including components in the network services layer. In a traditional hierarchical topology model,
the port and MAC address capacity of the aggregation nodes were key factors in determining scale. Port
and MAC address capacity limited the number of pods that a pair of aggregation nodes could support in
a cloud data center.
In contrast, a key benefit of a Clos-type architectural model is that it broadly expands overall port
capacity and bandwidth within the L2 (pod) domain. However, where physical service appliances are
attached at the FabricPath edge nodes, MAC address support on L3 aggregation-edge or access-edge nodes
is a consideration in terms of host scale per pod (e.g., a pod comprising a single FabricPath domain).
Furthermore, in the virtual customer edge (vCE) model that is the focus of VMDC VSA 1.0, the logical
capacity and bandwidth within the L2 (pod) domain. However, where physical service appliances are
attached at the FabricPath edge nodes, MAC address support on L3 aggregation-edge or access-edge nodes
is a consideration in terms of host scale per pod (e.g., a pod comprising a single FabricPath domain).
Furthermore, in the virtual customer edge (vCE) model that is the focus of VMDC VSA 1.0, the logical