本帖最后由 中国计算机学会 于 2024-5-17 08:58 编辑
摘要—本文分析了云边端协同的背景与现状，指出了云边端协同的新计算模式中的高可用问题。对于云边端协同高可用数据管理当前在冗余备份、网络优化、中间件与虚拟化、负载均衡等方面面临的挑战以及研究进展进行了探讨。最后，针对当前云边端协同系统的动态特性带来的一系列挑战，在网络、存储、参数配置、查询优化等方向提出了未来的可能研究方向。
王宏志（哈尔滨工业大学） 向清平（哈尔滨工业大学）
关键词：云边端协同 高可用性 数据库 背景 云边端协同的新计算模式对数据管理提出了新的需求，由于云边端协同的复杂环境和云边端协同数据库上的多样化任务，其中的高可用（Highly Available，HA）问题日益凸显，已成为制约数据库发展的重要因素。受网络信号、能量损耗和设备故障等因素影响，端侧设备会频繁加入或退出，边侧也会出现不稳定的情况。因此，云边端协同的显著特点是系统存在频繁波动。例如，端侧的工业传感器由于接近工业现场，易受电磁干扰、化学腐蚀、物理撞击等影响而出现节点故障，其数据可能会频繁出现短时不可用的情况；在边侧，接线开裂、电源老化、板卡松动、接口脱落等会造成工控机故障，导致数据丢失或者计算无法正常进行；在发展较为成熟的云侧，文献[1]指出即使通过冗余使无单点故障（No-SPoF）的原则得到广泛传播，冗余组件普遍部署在硬件和软件堆栈的许多级别中，云中断也仍然存在，通常发生在硬件升级或软件更新（如变电站的更新/升级、域名系统（DNS）和软件定义网络（SDN）控制器更新等）、网络故障（如核心和辅助网络交换机同时失效、冗余网络路径同时发生故障、受外部网络的支配等）、配置错误（如软件错误导致实时服务的配置损坏，使它们无法处理正常负载）、流量过载、电力中断等情况中。现有云边端协同数据管理理论和方法均未较好地解决这一系列问题，因此如何应对协同系统的故障，保障系统的高可用是面向云边端协同的数据管理面临的挑战。 云边端协同系统高可用的研究目标是最大程度地降低数据中断和服务不可用的风险，尤其是在金融交易、医疗、物联网等对服务不中断要求高的领域。 关键挑战及进展 当前的数据管理理论和技术研究主要集中在云侧，面向边缘和端的研究较少，面向云边端协同的数据管理理论和技术的研究更是凤毛麟角。相较于云边端协同，云计算既不存在显著的设备异构性，也无须考虑边缘和端节点严格的存储、计算和通信资源限制及移动设备的能量限制。同时，云计算中的节点一般通过专用高速网络连接，节点故障失效的概率低。而云边端协同中，端设备一般通过蜂窝网络连接，网络波动大，设备易失效，因而对数据管理系统的稳定性要求十分严苛。因此，云数据管理方法无法满足云边端协同场景对高可用的需求，需要进一步针对云边端协同的特点，提出新型的数据管理理论和方法。 文献[2]梳理了云边端一体化发展面临的若干挑战，并指出“云边端大规模节点管理稳定性和性能仍有不足”。在稳定性方面，全局管理平台虽然通过容器等方式实现了对边缘节点、终端设备的统一管理，但由于云边端节点所处网络环境通常较为复杂、终端设备多样性等挑战的存在，在跨网络环境、跨地理位置条件下的大规模节点管理仍缺乏稳定性，云-边／边-边通信、数据同步、边缘自治、IoT设备管理等方面的技术能力仍须增强。在性能方面，大规模节点之间的数据实时传输、控制指令实效下发、大规模应用快速分发部署也面临挑战，急需测试验证方法和工具[2]。 下面将概述云边端协同高可用数据管理的相关研究进展。 冗余备份 在动态、分布式、开放的云边端协同系统中，边缘或者云服务器很容易出现不可预测的故障，可能导致任务处理中断和数据丢失，最常见的补救措施是使用冗余技术，即为每个任务提前部署多个备份实例。其高可用性通常通过分布式数据复制实现，其中每个数据库记录驻留在一个主副本和一个或多个备份副本中。对主副本的更新将同步传播到所有备份副本，以便任何发生故障的主服务器都可以由备份服务器替换。主动-被动复制是最常用的复制技术之一。每个数据库分区都包含一个活动副本（称为主副本）和一个或多个备份副本，前者处理事务并对数据进行更改，后者作为备份副本与主副本保持同步。主动-被动方案通常通过日志传送实现，其中主数据库执行事务，然后将其日志传送到所有备份副本。备份副本重播日志，以便新的更改反映在其副本中。采用主动-主动协议的系统允许任何副本接受事务，然后将更改广播到所有其他副本。由于每个副本的事务与其他副本之间可能存在冲突，因此在副本之间同步更新需要比主动-被动方案更多的协调。 Remus[3]是一个为运行在Xenon上的普通虚拟机（VM）提供透明高可用性的软件系统，通过将正在运行的虚拟机的副本持续实时迁移到备份服务器实现。如果主服务器出现故障，备份服务器就会自动激活。Remus的主要功能包括：备份虚拟机是主虚拟机（磁盘/内存/网络）的精确副本；备份完全是最新的，即使是活动的传输控制协议（TCP）会话也能不间断地维持；无须以任何方式修改即可保护现有访客。Remus以主动-被动配置运行配对服务器，采用了两种主要技术：使用虚拟化基础架构简化整个系统的复制、异步复制允许主服务器继续运行的同时异步执行与复制服务器的同步[4]。RemusDB[5]提出了一种主动-备用高可用解决方案，该解决方案基于在虚拟机中运行数据库管理系统（DBMS），并将与高可用相关的大部分复杂性从DBMS中排除，依赖于虚拟化层的功能。虚拟化层捕获活动主机（包括DBMS）上整个虚拟机状态的变化，将其传播到备用主机，并在备用主机上应用备份VM。虚拟化层还检测故障，并管理从活动主机到备用主机的故障转移，这对DBMS是透明的。在故障转移期间，所有事务属性（包括原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）——ACID）都将得到维护，并保留客户端连接，从而使故障对DBMS客户端透明。 在冗余备份方面，目前企业界的主流思路是多节点同步集群，其基本想法实际上就是复制关键组件以提高系统的可用性，冗余既可以提高系统性能，又可以在组件发生故障时采取保护措施。OceanBase的每个集群由几个区域组成，每个区域中，OceanBase可以部署为无共享，使用Paxos协议在区域之间复制事务，其支持多个区域和零数据损失的跨区域容错，实现了恢复点目标（Recovery Point Objective，RPO）等于0，恢复时间目标（Recovery Time Objective，RTO）少于8秒[6]。PolarDB-X按计算节点、存储节点、日志节点对内核进行分解，其中日志节点兼容MySQL生态的主备复制协议[7]；对于数据节点集群，通过X-Paxos共识协议保证了数据在发生故障时能够快速恢复，实现了RPO等于0，RTO少于30秒。Microsoft Azure引入可用性区域（Azure High Availability Zone），每个区域由一个或多个数据中心组成，这些数据中心具有独立的电源、网络和冷却功能，提供容器服务Azure Kubernetes Service（AKS），可以自动管理和扩展容器化的应用程序，具有自动恢复和故障转移的能力。Oracle HACMP的基本架构是使用两个或多个服务器构成一个集群并提供共享存储，当一台服务器出现问题时，另一台服务器就会自动获得相应的服务，从而保证了不间断的服务。IBM DB2 pureScale通过在冗余架构中使用高可靠的IBM PowerHA pureScale技术，提供了持续的可用性，能够瞬间从节点故障中恢复，将工作负载重新分配给其他可用节点。 网络 分布式系统设计的传统观点认为网络开销是严重的性能瓶颈。主动-被动复制和主动-主动复制这两种主要的高可用性方法都采用网络开销最小化的优化目标。然而，随着下一代网络的兴起，尤其是在局域网（LAN）环境中，传统的网络优化方案可能不再是最佳选择，例如，最新的基于远程直接内存访问（RDMA）的网络可实现与主内存相似的带宽，性能瓶颈已从网络转移到CPU的计算开销。目前新的协议Active-Memory[8]可以充分释放RDMA网络的潜力，这是一种专为LAN的下一代RDMA网络而设计的新的高可用性协议，其优化目标是将执行数据复制的CPU开销最小化，而不是将网络流量最小化。Active-Memory的核心思想是利用RDMA的单向特性，直接更新远程备份服务器上的记录，而不涉及远程CPU。例如，阿里巴巴的数据中心网络是基于以太网的多层CLOS网络，采用基于以太网的RDMA技术RoCEv2，其网络架构涉及架顶（Top of Rack，ToR）层，ToR交换机连接叶（leaf）交换机，叶交换机连接脊（spine）交换机，每台机器都配备双端口RDMA网卡，连接到两个不同的ToR交换机，以支持在单个网络链路故障的情况下继续提供服务[9]。IBM DB2 pureScale利用RDMA直接对远程服务器的内存执行写操作。Oracle没有使用RDMA技术，这意味着Oracle通信使用速度较慢的套接字协议，并且需要一些开销较大的CPU中断，从而影响集群效率。 云边端协同系统中数据的查询处理操作根据用户需求对网络中的感知数据进行检索和回传。然而，部署在恶劣环境中的无线传感网络容易遭受外力破坏，或者由于自身资源（能量、存储等）有限，可能会导致节点发生位移和故障，从而造成网络拓扑不断改变以及部分节点的感知数据失效。同时，节点感知数据容量大、传输带宽有限以及网络链路不可靠等因素，可能会造成网络通信时延大大增加。这些因素在网络层面给云边端协同数据管理系统中快速、可靠的查询处理带来了挑战。文献[10]提出一种可在动态网络中实现的低延迟高可靠的数据查询机制，该机制是一种非聚合随机查询方式，通过将传感节点划分为源节点和查询节点实现数据查询。 中间件与虚拟化 中间件和虚拟化在云边端协同系统中应用广泛，可以提供更强大的可用性和灵活性。中间件通过监控和管理资源、检测故障并指导虚拟化层自动添加备份节点，提供高可用性和容错性。虚拟化技术通过资源的灵活管理和高可用性保护，提供更好的资源利用和故障恢复机制。它们相互协同，可以为云边端应用程序和设备提供可靠的服务和性能保证。 文献[11]将高可用性解决方案分为中间件方法和基于虚拟化的方法，针对不同层的故障提供不同的保护机制，提出了一个评估可用性解决方案的框架。该框架针对不同的故障类型（应用程序故障、VM故障、主机故障）设置不同的评审标准，并进一步将解决方案组织为三层（底层技术、服务（中层）和中间件（上层）），且上层可以由底层的一个或多个解决方案组成[12]。 中间件方法是独立于平台和应用程序的可用性解决方案。这些中间件可以在云边端协同环境中作为平台服务（即平台即服务（PaaS））在云中提供。OpenStack是一个用于公共和私有云的开源平台，可控制大量计算、存储和网络资源。OpenStack有多个组件，每个组件负责云环境的特定方面，在高可用方面，通过Heat组件可以从应用程序、实例和堆栈（VM组）三个级别监控资源和应用程序。如果出现失败，Heat会尝试在当前水平上解决问题。如果问题仍然存在，它将尝试在更高的层面上解决。通过对云环境中应用程序的检查点、WatchDog和日志服务提供高可用性和容错中间件[13]，中间件提供了确定性算法，实现了根据故障情况自动为系统分配备份节点。中间件检测到故障后，指导系统添加新节点作为故障节点的副本，保证应用的连续性。 在云边端协同环境下，服务器虚拟化是增加系统可靠性和灵活性的关键因素之一。在虚拟化提供的物理资源上重新分配工作负载的灵活性允许在开发人员不停止运行应用程序（在虚拟机上运行）的情况下执行维护操作，并通过虚拟机迁移实施更好的资源使用策略。虚拟化还可以用于在VM级别实现高可用机制，例如，将故障和攻击隔离在单独的虚拟机、利用检查点进行回滚实现快速恢复。除此之外，虚拟化还可以通过虚拟化网络功能在网络级别上使用，以实现相同的目标。为了给非高可用应用迁移到云端提供通用的可用性解决方案，研究者提出了各种基于虚拟化技术的可用性解决方案。在这些解决方案中，故障检测和故障服务的恢复是在虚拟机级别执行的。在云环境中，这些基于虚拟化的解决方案可以在基础设施即服务（IaaS）层提供。例如，VMware提出了两种可用性解决方案：VMware HA和VMware Fault Tolerance（FT）。这两种解决方案都可以保护应用程序免受虚拟机故障的影响，并通过重新启动发生故障的虚拟机或将其故障转移到另一台主机来恢复服务。Amazon EC2等IaaS提供商也提供可用性机制来保障虚拟机的可用性。但是，用户有责任正确使用这些机制。 OceanBase的OBProxy中间件实现了高可用性，一是确保OBProxy服务本身的高可用，二是确保OceanBase数据库的高可用。在OBProxy服务高可用方面：通过故障探测、弹性扩展和流量切换等策略，确保在部署机器出现问题时能够及时恢复服务；能够检测并自动重启异常的进程，确保服务端口能够持续提供服务。在OceanBase数据库高可用方面：通过故障探测识别OceanBase节点的状态，包括机器和进程故障以及业务逻辑问题；在转发SQL之前和之后都会尝试重试机制，以确保SQL能够成功执行。OBProxy的高可用特性还与OceanBase数据库的其他高可用机制紧密配合。例如，OBServer基于Paxos算法实现高可用，能够在多数派节点正常的情况下提供服务，并容忍少数派节点的异常。OBProxy需要快速准确地找到正常服务的节点，以实现无缝的服务切换。 负载均衡 负载不均衡是造成云边端协同数据管理系统低效的关键因素，而云、边、端在计算、存储和通信能力上的高度差异，将极大影响面向云边端协同数据管理的效率，极端情况下的不均衡情况可能会导致一些节点或服务器承受过多的负载，过载的节点可能会出现性能下降、响应延迟增加甚至崩溃的情况，从而成为系统的单点故障，影响系统的可用性。因此需要解决云边端协同的负载均衡问题，避免局部热点导致的故障，从而实现系统整体的高可用性。 计算迁移（computation offloading）被定义为将计算任务从能力受限的设备迁移到资源充足的基础设施以获得远程协助的过程。针对云边端协同系统的负载均衡感知迁移（Load Balance-Aware Offloading，LBAO）问题，可以考虑由云中心、多个边缘服务器和多个终端设备集合组成的云边端协同系统。文献[14]提出了通过负载演化模型表征不同迁移策略对协同系统负载动态的影响，协同动态地确定边缘服务器的云迁移率以及终端设备集合与边缘服务器之间的多对多边缘迁移比例，进而将总任务延迟最小化。文献[15]根据不同边缘设备的不同数据传输能力对边缘层进行细化，构建了云下四层异构物联网框架，并给出相应的数据分层传输策略，从而有效处理实时、近实时、非实时等敏感数据；同时开发了基于链路的高性能自适应负载均衡方案，实现系统资源的动态优化分配。针对物联网云边端协作中资源受限的边缘服务器的多目标优化任务迁移问题，上述文献构建了一个由端设备层、边缘层和云层组成的云边端协同计算迁移架构，引入二维迁移决策因子对延迟和能耗进行建模，并将模型形式化为多目标优化问题，其优化目标是将任务计算卸载的平均延迟和平均能耗最小化，还提出了一种基于改进的强度Pareto进化算法（SPEA2）的多目标迁移算法（SPMOO）解决该问题。 多种类型的高可用技术也可以组合使用。在共享访问方法中，两个或多个数据库服务器实例共享一个保存数据库的公共存储基础架构。存储基础设施冗余地存储数据，例如通过将数据镜像到多个设备上，以确保数据的可靠性。此外，服务器访问存储数据的网络互连（例如SAN）必须通过使用冗余访问路径提高可靠性。如果数据库服务器发生故障，访问同一数据库的其他服务器可以接管故障服务器的工作负载，如Oracle RAC实现了跨服务器实例的虚拟共享缓冲池、Microsoft SQL Server中的故障转移集群，以及通过MySQL Cluster中的NDB后端API访问的同步数据节点。 未来展望 面向云边端协同的数据管理系统具有显著的动态特性，系统内各类设备状态会随着外部物理世界和自身运行情况而变化，造成整个系统的动态变化，进而对系统可靠性和可用性产生严重影响。现有的数据管理仅关注不频繁的设备故障、自然灾害等，而云边端协同要求探索在频繁的动态变化环境下保证数据管理系统可靠性和可用性的解决方案。目前，面向云边端协同数据管理的理论和技术研究刚刚兴起，成果还非常少。 对于动态变化的网络环境，可以考虑研究设计一种能够预测网络环境的智能技术，以便相应地改变策略和代理，以主动方式规避网络拥堵、服务中断等潜在的行为。因此，利用机器学习、深度学习和强化学习实现目标（降低延迟、减少能耗等）将是一项有趣且具有挑战性的工作。 在存储方面，数据存储作为云边端高效协同数据管理的基础，存储面临云、边、端数据来源多样且规模巨大的挑战。在云边端协同中，面对海量多模异构数据与计算力下沉的场景，传统数据存储方法很难保证高可用性，边端侧需要支撑有一定复杂程度的数据处理任务，对实时管理和低时延响应要求高，而端侧数据规模整体上可能巨大且存在大量冗余，为传输和存储带来负担。从这些角度出发，良好的云边端侧数据分布技术能够帮助快速恢复故障，从而构建高可用、可扩展的存储架构。 在参数配置方面，基于云的云边端协同系统中由配置问题导致服务中断的比例不容忽视。综合分析已经发现的服务中断案例，发现错误的配置（人为错误和软件错误）可能导致流量过载等情况。目前在自动化参数配置方面仅考虑通过设计算法找到最优的参数配置，如使用强化学习、贝叶斯优化等黑盒模型进行云数据库参数调优，并未考虑高可用指标。而负载效率的参数调优很可能带来数据库宕机、负载实例启动失败、性能下降等风险，因此考虑面向可用性的参数适配方法进行优化，不仅对用户负载效率有至关重要的影响，还关系到数据库的可用性。通过设计面向提升可用性的参数适配方法，让用户输入负载特性和高可用指标（如误差容忍范围），并通过基于机器学习的安全调整机制推荐数据库参数配置，能够在提高用户负载效率的同时，大大提高用户实例的可用性，减少数据库宕机和实例失败的发生。 在查询优化方面，目前的系统具有网络延时高、传输代价高、计算开销高的特点。在云边端协同的场景中，需要将热点数据下推至对应边、端数据库以降低查询延迟和网络传输代价。云边端架构提供了维度更高、异构性更强的查询计划搜索空间和更为复杂的优化目标，以提升系统的资源利用率，但现有优化器尚无法针对此类高维异构问题进行多目标优化。目前的前沿研究多数只针对单个查询性能做优化，极少考虑整体负载平衡。而仅考虑单查询性能可能会带来数据库部分节点计算、I/O负载过高，进而影响数据库的可用性。我们可以考虑研究兼顾系统负载平衡的智能查询优化器，并以高可用性为约束进行多目标查询优化来尝试解决上述问题。现有智能查询优化器大多仅能优化单一查询，当发起大规模查询时，其无法兼顾系统负载的平衡，间接增加了数据库节点因负载过大而造成查询阻塞甚至宕机的可能。针对这一痛点，通过研究智能查询优化算法，以低时延、低传输代价、高可用性为约束设计基于强化学习的多目标查询优化，在兼顾系统整体查询代价的同时，通过平衡系统负载，减少单节点因过载而出现故障的频率，进而减少RTO。 考虑到云边端协同数据管理系统的复杂性，上面提出的研究问题可以进行协同研究，例如： 1.网络预测与存储协同研究。通过机器学习预测网络环境变化，可以为数据存储提供前瞻性指导。例如，预测到高负载即将到来时，可以提前调整数据分区策略，优化数据分布，避免单点过载。 2.参数配置与查询优化协同研究。自动化参数配置应考虑查询优化的需求，同时，查询优化器的设计也应考虑到参数配置的影响，以实现负载平衡和高可用性。 3.从可用性的角度出发，云、边、端不同层次的技术研究应相互配合。例如，边缘计算的数据处理能力提升可以减轻云端的负担，而云端的强大计算能力又可以支持边缘计算的智能决策。 ■
参考文献： [1] Gunawi H S, Hao M, Suminto R O, et al. Why does the cloud stop computing?: lessons from hundreds of service outages[C]// Proceedings of the Seventh ACM Symposium on Cloud Computing. ACM, 2016: 1-16. [3] Cully B, Lefebvre G, Meyer D, et al. Remus: high availability via asynchronous virtual machine replication[C]// Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation. 2008: 161-174. [4] Sharma Y K, Singh A S. High availability of databases for cloud[C]// Satapathy S C, Joshi A, Modi N, Pathak N. Proceedings of International Conference on ICT for Sustainable Development. Advances in Intelligent Systems and Computing. Singapore: Springer Singapore. 2016, 409: 501-509. [5] Minhas U F, Rajagopalan S, Cully B, et al. RemusDB: Transparent high availability for database systems[J]. The VLDB Journal, 2013, 22(1): 29-45. [6] Yang Z, Yang C, Han F, et al. OceanBase: A 707 million tpmc distributed relational database system[J]. Proceedings of the VLDB Endowment, 2022, 15(12): 3385-3397. [7] Cao W, Li F, Huang G, et al. PolarDB-X: An elastic distributed relational database for cloud-native applications[C]// 2022 IEEE 38th International Conference on Data Engineering (ICDE). 2022: 2859-2872. [8] Zamanian E, Yu X, Stonebraker M, Kraska T. Rethinking database high availability with RDMA networks[J]. Proceedings of the VLDB Endowment, 2019, 12(11): 1637-1650. [9] Cao W, Zhang Y, Yang X, et al. PolarDB serverless: A cloud native database for disaggregated data centers[C]// Proceedings of the 2021 International Conference on Management of Data. 2021: 2477-2489. [10] 梁俊斌, 马方强, 何综键. 动态无线传感网中低延迟高可靠的数据查询机制[J]. 计算机学报, 2020, 43(3): 555-572. [11] Hormati M, Khendek F, Toeroe M. Towards an evaluation framework for availability solutions in the cloud[C]// 2014 IEEE International Symposium on Software Reliability Engineering Workshops. IEEE, 2014: 43-46. [12] Endo PT, Rodrigues M, Gonçalves GE, et al. High availability in clouds: systematic review and research challenges[J]. Journal of Cloud Computing, 2016, 5(1): 16. [13] Imran A, Gias AU, Rahman R, et al. Cloud-niagara: a high availability and low overhead fault tolerance middleware for the cloud[C]// 16th Int’l Conf. Computer and Information Technology. 2014: 271-276. [14] Fan Y. Load balance-aware dynamic cloud-edge-end collaborative offloading strategy[J]. PLOS ONE, 2024, 19(1): e0296897. [15] Li J, Li X, Yuan J, et al. Load balanced data transmission strategy based on cloud–edge–end collaboration in the internet of things[J/OL]. Sustainability, 2022, 14(15): 9602. 版权声明：中国计算机学会(CCF)拥有《中国计算机学会通讯》(CCCF)所刊登内容的所有版权，未经CCF允许，不得转载本刊文字及照片，否则被视为侵权。对于侵权行为，CCF将追究其法律责任。
| 
京公网安备 11010802032778号 )
发表于 2024-5-17 08:52:46