diff options
Diffstat (limited to 'docs/guides/onap-developer/architecture/blueprint-enr.rst')
| -rw-r--r-- | docs/guides/onap-developer/architecture/blueprint-enr.rst | 100 |
1 files changed, 0 insertions, 100 deletions
diff --git a/docs/guides/onap-developer/architecture/blueprint-enr.rst b/docs/guides/onap-developer/architecture/blueprint-enr.rst deleted file mode 100644 index a3018a195..000000000 --- a/docs/guides/onap-developer/architecture/blueprint-enr.rst +++ /dev/null @@ -1,100 +0,0 @@ -ONAP Blueprint Enrichment -------------------------- - -The ONAP Beijing release includes four functional enhancements in the -areas of manually triggered scaling, change management, and hardware -platform awareness (HPA). These features required significant community -collaboration as they impact multiple ONAP projects. These features are -applicable to any use case; however, to showcase them in a concrete -manner, they have been incorporated into VoLTE and vCPE blueprints. - -Manually Triggered Scaling -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Scale-out and scale-in are two primary benefits of NFV. Scaling can be -triggered manually (e.g., by a user or OSS/BSS) or automatically via a -policy-driven closed loop. An automatic trigger allows real-time action -without human intervention, reducing costs and improving customer -experience. A manual trigger, on the other hand, is useful to schedule -capacity in anticipation of events such as holiday shopping. An ideal -scaling operation can scale granularly at a virtual function level (VF), -automate VF configuration tasks and manage the load-balancer that may be -in front of the VF instances. In addition to run-time, this capability -also affects service design, as VNF descriptors need to be granular up -to the VF level. - -The Beijing release provides the initial support for these capabilities. -The community has implemented manually triggered scale-out and scale-in -in combination with a specific VNF manager (sVNFM) and demonstrated this -with the VoLTE blueprint. An operator uses the Usecase UI (UUI) project -to trigger a scaleing operation. UUI communicates with the Service -Orchestrator (SO). SO uses the VF-C controller, which in turn instructs -a vendor-provided sVNFM to implement the scale-out action. - -We have also demonstrated a manual process to Scale Out VNFs that use -the Virtual Infrastructure Deployment (VID), the Service Orchestrator -(SO) and the Application Controller (APPC) as a generic VNF Manager. -Currently, the process is for the operator to trigger the Scale Out -action using VID, which will request SO to spin up a new component of -the VNF. Then SO is building the ConfigScaleOut request and sending to -APPC over DMaaP, where APPC picks it up and executes the configuration -scale out action on the requested VNF. - -Change Management -~~~~~~~~~~~~~~~~~ - -NFV will bring with it an era of continuous, incremental changes instead -of periodic step-function software upgrades, in addition to a constant -stream of both PNF and VNF updates and configuration changes. To -automatically deliver these to existing network services, the ONAP -community is creating framework to implement change management -functionality that is independent of any particular network service or -use case. Ideally, change management provides a consistent interface and -mechanisms to manage complex dependencies, different upgrade mechanisms -(in-place vs. scale-out and replace), A/B testing, conflict checking, -pre- and post-change testing, change scheduling, rollbacks, and traffic -draining, redirection and load-balancing. These capabilities impact both -design-time and run-time environments. - -Over the next several releases, the community will enhance change -management capabilities in ONAP, culminating with a full CI/CD flow. -These capabilities can be applied to any use case; however, specifically -for the Beijing release, the vCPE blueprint has been enriched to execute -a predefined workflow to upgrade the virtual gateway VNF by using -Ansible. An operator invokes an upgrade operation through the VID -interface. VID drives SO, which initiates a sequence of steps such as -VNF lock, pre-check, software upgrade, post-check and unlock. Since -virtual gateway is an L3 VNF, the specific operations are carried out by -the SDN-C controller in terms of running the pre-check, post-check and -upgrade through Ansible playbooks. - -Hardware Platform Awareness (HPA) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Many VNFs have specific hardware requirements to achieve their -performance and security goals. These hardware requirements may range -from basic requirements such as number of cores, memory size, and -ephemeral disk size to advanced requirements such as CPU policy (e.g. -dedicate, shared), NUMA, hugepages (size and number), accelerated -vSwitch (e.g DPDK), crypto/compression acceleration, SRIOV-NIC, TPM, SGX -and so on. The Beijing release provides three HPA-related capabilities: - -1. Specification of the VNF hardware platform requirements as a set of - policies. - -2. Discovery of hardware and other platform features supported by cloud - regions. - -3. Selection of the right cloud region and NFV infrastructure flavor by - matching VNF HPA requirements with the discovered platform - capabilities. - -While this functionality is independent of any particular use case, in -the Beijing release, the vCPE use case has been enriched with HPA. An -operator can specify engineering rules for performance sensitive VNFs -through a set of policies. During run-time, SO relies on the ONAP -Optimization Framework (OOF) to enforce these policies via a -placement/scheduling decision. OOF determines the right compute node -flavors for the VNF by querying the above-defined policies. Once a -homing decision is conveyed to SO, SO executes the appropriate workflow -via the appropriate controller. |