# GANA-VDC: Application-Aware with Bandwidth Guarantee in Cloud Datacenters
## 4 GANA-VDC System Architecture
### Switch-Centered Mapping  
In our work, we proposed a heuristic switch centered based mapping mechanism for VN to PN to solve VDC allocation. The principal, built on a hierarchical architecture in a self-organizing approach, accelerates the mapping from VN to PN, using distributed VDC allocation. Such architecture employs task division, e.g., _Global Leader_ (GL) and _Pod Allocation Managers_ (PAM), to allow efficient VDC allocation. Each PAM manages the local network separately, and the GL acts as a supervisor of the PAMs enforcing decomposition if necessary. The GL strategizes the VDC allocation delegating to the PAMs based on respective latency level, thus scheduling specialized VM agreeing with the tenant specifications. Moreover, another advantage represents exploiting PAM autonomy, in which a daemon responsible for path consolidation can achieve substantial network energy saving. To assure this architecture is self-organized, we design it on top of the Apache ZooKeeper [40], a reliable and highly available coordination system including leader election algorithm among PAMs if the GL fails.  
Figure 7: OpenFlow based on fat-tree.  
To check PAM resource availability, the latter regularly sends this information to the GL. Based on this, the index information decides if a PAM can handle VDC tasks or if it should distribute it among several PAMs stored in the GL. A tenant can request a VDC with 30,000 VMs, noting one pod contains 576 hosts and each of the houses 12 VMs, and a minimum of five pods is required to accommodate a VDC. This requires the GL to handle good resource management when determining the pods needed to fulfill a task. As illustrated in Figure 8, two parts compose the index information. The first is the index for the edge layer, given by an increasing bandwidth interval [Bm, Bn]. The tuples correspond to <Switch, VM-number> where Switch corresponds to the number of VMs accommodated by one edge switch within the interval [Bm, Bn] and VM-number gives the sum of VMs that can be handled by a pod within this same interval. Secondly, the aggregation layer index is given, in the same format as the one used for the edge layer with the sole difference being the tuple <Switch, VM-number> now contains the same information but for one aggregation switch. In doing so, the assumption is that, only when both parts of this index information are fulfilled, will the allocation be assigned to a pod. The GL efficiently chooses between pods as ordered in increasing number of VMs they can handle, thus assuring reasonable VDC allocation. This simply makes sure one mapping from VN to VP exists based on an index information validation mechanism. Indeed, the efficiency of the fast allocation is improved, and if some pods are chosen, they can parallelly perform sub VDC allocation including mapping of VM and links through mapping centered switches. This sub VDC mapping finds the optimal choice selected from the possible mappings. However, it will vary with both sub VDC mapping mechanism used by the cloud service provider and per tenant strategy generated as the acting factor according to tenant intent. If no other choices are presented, we use a single mapping outcome.