2.2　魔術師的工具箱：MEC管理

現在讓我們將注意力轉向如何管理ME主機。為了理解ETSI MEC的總體管理理念，我們需要回顧一下，一個典型的MEC系統可能包括數百或數千個邊緣站點（即ME主機站點）。它們連接到一個集中的實體或通過某種類型的廣域網（WAN）鏈路互連。從云環境的角度來看，這些鏈路通常非常糟糕。與典型的數據中心互連相比，它們的吞吐量受限（太慢）、延遲受限（耗時太長），而且并不可靠（太容易發生故障）。因此，將數據中心云管理框架簡單地轉換為ME系統可能會失敗。

ETSI MEC認識到這一問題，并啟用了一個管理框架，它將管理功能分散到每個ME主機上的分散組件和ME系統中的一個集中式組件。值得注意的是，這樣做是為了使與關鍵云管理框架（例如ETSI NFV）的集成盡可能簡單。不過，讓我們暫時把這個話題放在一邊，只關注管理框架的實際作用，或者更確切地說，ETSI MEC定義了哪些服務，以便實現高效的功能管理框架。

讓我們從關注主機中的內容開始。圖2.2顯示了一個虛擬基礎設施管理器（VIM）的存在。如在NFV中一樣，這被認為是一個相當經典的虛擬化堆棧。但有一個警告，“開箱即用”的OpenStack或VMware堆棧在MEC環境中可能無法正常工作。由于它們是為管理數據中心中的大量計算節點而設計的，因此它們通常會占用相當多的計算資源（當總池很大時這不是問題），并假定所有計算節點、存儲卷之間已具備LAN類型（高吞吐量/低延遲/低故障）的互連。這些假設可能使得在每個邊緣站點中定位一個完整的VIM堆棧變得不切實際——這樣一個堆棧的資源開銷可能太昂貴。同時，這些堆棧在WAN類型的鏈路上無法正常工作，因為WAN類型的鏈路比數據中心LAN鏈路具有更低的吞吐量、更高的延遲和較高的故障可能性。這些堆棧的各種開發者（包括開源的和商業的）都認識到了這一局限性，因此正在開發新的VIM架構，允許將大部分VIM放在ME主機之外的集中位置。此類當前工作的例子包括OpenStack在解決這個問題上所做的相關工作，例如它們關于這項工作需求的白皮書[27]，VMware在這方面也有所投入[28]。

重要的是，將VIM的某些部分移動到ME系統級會使ETSI MEC參考架構在這方面不準確。這可能會影響在Mm4、Mm6和Mm7參考點上定義的API。然而，ETSI MEC實際上并沒有在這些接口上定義API，因為API總是由VIM的生產者定義的。

這使ME平臺管理器（MEPM）成為主機中關鍵的MEC定義的管理實體。該實體負責MEP的生命周期管理以及主機上運行的所有應用程序，包括所有監控、故障和性能管理，還包括應用程序對服務、流量和云資源訪問相關策略的應用/實施。所有這些操作都應集中協調，這使得MEPM在Mm2和Mm3參考點上提供的服務對于有效管理至關重要。MEC 010-1[29]和MEC 010-2[30]規范對這些服務進行了全面的定義，前者用于管理MEP本身，后者用于對主機上運行的應用程序進行管理。

Mm2和Mm3參考點允許MEPM向MEC系統空間中的兩個關鍵集中管理實體（ME編排器和運營支持系統（OSS））提供服務。

如參考文獻[15]所述，ME編排器負責以下功能：

• 根據已部署的移動邊緣主機、可用資源、可用的移動邊緣服務和拓撲結構，維護移動邊緣系統的總體視圖；
• 應用程序包的發布，包括檢查應用程序包的完整性和真實性；
• 驗證應用程序規則和要求，如有必要，對其進行調整以符合運營商策略，記錄已發布的軟件包，并準備虛擬化基礎設施管理器來處理應用程序；
• 根據延遲、可用資源和可用服務等限制條件，為應用程序實例化選擇合適的移動邊緣主機；
• 觸發應用程序實例化和終止；
• 在支持時，根據需要觸發應用程序重新定位。

OSS是運營商網絡中的關鍵管理實體，負責大量的功能。然而，與MEC相關，OSS負責處理和批準應用程序實例化、終止或重新定位的請求。這些請求可以通過面向客戶的系統（CFS）門戶（該門戶是云應用程序提供商的接口）或從移動設備提供。

讓UE直接向OSS請求應用程序實例化（或終止）會帶來許多潛在的安全問題。事實上，這將是一個全新的OSS門戶——以前從未有客戶端設備能夠與OSS進行交互，但這從來都不是必要的。然而，對于邊緣計算，確實需要客戶端設備請求在特定邊緣主機上實例化應用程序實例，因此交互是必需的。ETSI MEC參考架構通過定義一個用戶應用程序代理功能來預測這種需求，其目的基本上是充當客戶端設備和OSS之間的安全網關。然后ETSI MEC將一個來自UE的API標準化到這個代理中，這在MEC 016[31]中指定。