文章来源：[1]P. S. Souza, T. C. Ferreto, F. D. Rossi, and R. N. Calheiros, “Location-Aware Maintenance Strategies for Edge Computing Infrastructures,” IEEE Communications Letters, vol. 26, no. 4, pp. 848–852, Apr. 2022, DOI: 10.1109/lcomm.2022.3150243.
摘要：高效的服务器维护和更新对于防止边缘计算环境中的性能和安全问题至关重要。尽管在维护计划中有很多措施，最先进的方法聚焦于云数据中心上进行更新，忽略了边缘计算范式特有的问题，比如用户位置感知。在这封信中，我们提出了两个维护策略，分别是Lamp和Laxus，它们在执行迁移决策时考虑用户的位置以避免边缘服务器维护期间的时延瓶颈。结果表明提出的策略与现存的策略相比可以减少维护时间约44.27%，同时有效的避免了时延瓶颈。
关键词 Edge computing, update, maintenance
I 引言
边缘计算基础设施运营商有责任保证边缘基础设施启动和运行，随着资源的短缺这不是不重要的，边缘基础设施相对于云基础设施缺乏鲁棒性。更糟糕的是，针对边缘的攻击越来越频繁。例如，例如，Mirai病毒策划了一次针对边缘服务器的分布式拒绝服务攻击，导致超过178000个域宕机。
II 系统模型
本小节描述了本工作中的边缘维护方案。首先，我们描述了边缘基础设施的元素。然后，我们制定了组成维护过程的步骤。表I总结了符号，以下为表I的具体内容：
\(b_f\): wireless delay of base station \(\mathcal{B}_f\) 基站的无线时延
\(\xi_u\): delay of network link \(\mathcal{L}_u\) 网络连接的时延
\(\aleph_u\): bandwidth capacity of network link \(\mathcal{L}_u\) 网络连接的带宽能力
\(\rho_i\): capacity of edge server \(\mathcal{S}_i\) 边缘服务器的能力
\(\eta_i\): capacity demand of edge server \(\mathcal{S}_i\) 边缘服务器的能力需求
\(\mu_i\): update status of edge server \(\mathcal{S}_i\) 边缘服务器的更新状态
\(\wp_i\): update time of edge server \(\mathcal{S}_i\) 边缘服务器的更新时间
\(\partial_i\): sanity check time of edge server \(\mathcal{S}_i\) 边缘服务器完整性检查时间
\(\lambda_i\): capacity demand of application \(\mathcal{A}_{j}\) 应用的能力需求
\(\omega_i\): delay of application \(\mathcal{A}_{j}\) 应用的时延
\(\hbar_{j}\)：delay threshold of \(\mathcal{A}_{j}\) 应用的时延阈值
\(x_{i,j}\): matrix that represents the applacations palcement 表示应用程序安置的矩阵
\(\Upsilon\left(\mathcal{A}_{j}, \mathcal{S}_{i}\right)\): set of links used to migrate \(\mathcal{A}_{j}\) to \(\mathcal{S}_{i}\) 用于将\(\mathcal{A}_{j}\)迁移到\(\mathcal{S}_{i}\)的连接集
我们将环境表示为如图所示，将地图分为几个六边形。边缘基础设施包括一组配备边缘服务器并互联的基站\(\mathcal{B}\)，位于每个地图单元。当基站为一组用户\(\mathcal U\)提供无线连接时，边缘服务器托管用户应用程序\(\mathcal{A}\)。我们将基站表示为\(\mathcal{B}_f\leftarrow\{b_f\}\)，其中\(b_f\)是基站的无线时延，网络连接表示为\(\mathcal{L}_u\leftarrow\{\xi_u,\aleph_u\}\)，其中\(\xi_u\)和\(\aleph_u\)分别表示连接时延和带宽。
边缘服务器建模为\(\mathcal{S}_i = \left\{\rho_i, \eta_i, \mu_i, \wp_i, \partial_i,\right\}\)。符号\(\rho_i\)和\(\eta_i\)分别表示为服务器\(\mathcal{S}_{i}\)的能力和需求。更具体地说，\(\eta_i\)是寄主于\(\mathcal{S}_{i}\)上所有应用的需求的总和。\(\mathcal{S}_i\)的更新状态用\(\mu_i\)表示，当\(\mathcal{S}_i\)更新时\(\mu_i=1\)，否则为\(\mu_i=0\)。修补\(\mathcal{S}_i\)需要\(\wp_i\)个单位时间。修补\(\mathcal{S}_i\)后，花费\(\partial_i\)个单位时间执行完整性检查，以验证其完整性。
应用具有以下属性\(\mathcal{A}_j=\{\lambda_j, \omega_j, \hbar_j\}\)。\(\lambda_j\)表示应用的能力需求，当选择哪个服务器来托管程序时应该被考虑。程序\(\mathcal{A}_j\)的时延\(\omega_j\)利用公式1计算，考虑用户\(\mathcal{A}_j\)的用户所使用的基站的无线时延(表示为\(\mathcal B_f\))和用于将\(\mathcal{A}_j\)通信给其用户的网络链路的聚合时延相加。
随着\(\mathcal{A}_j\)的用户在地图上移动，处理过程将程序从一个基站转移到另外一个基站。在这种情况下，如果\(\mathcal{A}_j\)的用户没有链接到与\(\mathcal{A}_j\)服务器主机相同的基站，它们之间的连接是通过一组称为\(\theta\)网络链路路由\(\mathcal{A}_j\)的数据建立的。我们以链路延迟作为权重，通过Dijkstra最短路径算法定义链路\(\theta\)的集合。当应用的时延\(\omega_j\)超过它的时延阈值\(\hbar_j\)发生SLA违规。应用程序的位置是由二进制矩阵\(x\)给出的，其中\(\mathcal{S}_i\)是\(\mathcal{A}_j\)的宿主时\(x_{i,j}=1\)，否则为0。
本文中所考虑的维护场景聚焦于每个服务器\(\mathcal S_i\in\mathcal{S}\)的更新，其中维护过程被分为批次集\(\mathcal Q = \{\mathcal Q_1, \mathcal Q_2, \ldots, \mathcal Q_{|\mathcal Q|}\}\)。维护持续了很多批次，直到\(\sum_i^{|S|}\mu_i=|\mathcal S|\)，意味着所有服务器已被更新。我们的目标是尽快的更新服务器，同时尽可能少的执行迁移，并避免违反SLA。
在我们的模型中，服务器需要被重新启动才能使补丁生效。因此，可以只更新没有运行应用程序的服务器，以避免应用程序停机。在每个维护批次\(\mathcal Q_e\in\mathcal Q\)，所有没有运行应用程序的过时边缘服务器全部被更新。然后，迁移发生，将应用程序从剩余的过时服务器中重新定位，这样他们在下一批就可以更新了（这个迁移的过程被称为“服务器耗尽”，因为迁移的目标是“清空”过时的服务器）。这个过程重复多次迭代（即维护批次）直到所有的服务器被更新。
我们假设在基础架构中不存在共享存储。因此，将应用\(\mathcal A_j\)迁移到边缘服务器\(\mathcal S_i\)意味着通过互相连接边缘服务器的基站的一组链接\(\Upsilon\left(\mathcal{A}_{j}, \mathcal{S}_{i}\right)\subseteq\mathcal{L}\)将\(\mathcal A_j\)的能力需求\(\lambda_i\)从当前的主机转移到\(\mathcal S_i\)。通过Dijkstra最短路径算法定义\(\Upsilon\left(\mathcal{A}_{j}, \mathcal{S}_{i}\right)\)。在这种情况下，将\(\mathcal A_j\)迁移到\(\mathcal S_i\)所花费的时间是由\(\mathcal A_j\)的能力需求\(\lambda_j\)和迁移可用的带宽之间的比率给出的，如公式2所示。
因为边缘网络基础设施可能是异构的，连接集合\(\Upsilon\left(\mathcal{A}_{j}, \mathcal{S}_{i}\right)\)可能有不同的带宽能力。因此，\(\Upsilon\left(\mathcal{A}_{j}, \mathcal{S}_{i}\right)\)连接中最低可用的带宽被认为是迁移实际可用的带宽。
