iis做的网站为啥打不开,ddns域名注册,wordpress页面分析插件,wordpress输出成word上篇图文#xff0c;从GaussDB关键架构目标、GaussDB分布式架构、数据计算路由层#xff08;Coordinator#xff09;关键技术方案等三方面对GaussDB架构进行了介绍。本篇将从数据持久化存取层(DataNode)关键技术方案、全局事务管理层#xff08;GTM#xff09;关键技术方案…
上篇图文从GaussDB关键架构目标、GaussDB分布式架构、数据计算路由层Coordinator关键技术方案等三方面对GaussDB架构进行了介绍。本篇将从数据持久化存取层(DataNode)关键技术方案、全局事务管理层GTM关键技术方案、集群管理层CM关键技术方案、OM运维管理关键技术方案等方面继续解读GaussDB架构。
目录 4 数据持久化存取层(DataNode)关键技术方案
5 全局事务管理层GTM关键技术方案
5.1 单节点的事务
5.2 跨节点事务
6 集群管理层CM关键技术方案
7 OM运维管理关键技术方案
8 安全关键技术方案
安全关键技术一密态等值查询
安全关键技术二账本数据库 4 数据持久化存取层(DataNode)关键技术方案
Datanode节点主要负责数据的持久化和快速写入、读取。数据持久化采用物理日志wal事务提交wal刷盘 对外提供逻辑日志功能反解析物理日志为SQL逻辑日志。 图1 datanode数据持久化
Astore存储格式为追加写优化设计其多版本元组采用新、老版本混合存储方式。当一个更新操作将老版本元组更新为新版本元组之后如果老版本元组所在页面仍然有空闲空间则直接在该页面内插入更新后的新版本元组并在老版本元组中记录指向新版本元组地址的指针。在这个过程中新版本元组以追加写的方式和被更新的老版本元组混合存放这样可以减少更新操作的IO开销。然而需要指出的是由于新、老版本元组是混合存放的因此在清理老版本元组时需要从混杂的数据中挑出垃圾数据清理开销会比较大。同时由于新版本元组位置相对老版本元组位置发生了变化而索引中只记录了老版本元组的位置因此容易导致索引膨胀。为了缓解索引膨胀这个问题对于同一个页面内的更新采用了HOT技术将同一个记录的多个版本按从老至新的更新顺序给串连起来但是这种从老至新的更新链顺序对于并发的OLTP类短查询是效率是比较低需要遍历的版本个数较多。
Ustore与astore相比ustore的最大特点在于新、老版本记录的分离存储。当一个更新操作将老版本元组更新为新版本元组之后直接在老版本元组的位置覆写新版本元组内容同时将老版本元组移到统一管理历史版本的undo区域。在这个过程中既需要修改数据页面也需要修改undo页面更新操作开销较astore的追加更新稍大。但是就如同垃圾分类回收一样这样带来的好处也是显而易见的在清理老版本元组时不再需要遍历扫描主表数据直接按需回收undo区域即可垃圾清理开销较astore不仅大幅降低而且稳定可控。同时由于新版本元组复用老版本元组的物理位置因此索引无需更新索引膨胀得到有效控制。另外在ustore中多个版本的更新链按从新至老的顺序串连对于并发查询更友好。总而言之ustore更适合更新频繁的业务场景。
5 全局事务管理层GTM关键技术方案
GTM 仅处理全局时间戳请求 64位CSN递增几乎都是CPU 和消息收发操作。不是每次都写ETCD, 而是采用定期持久化到ETCD 里 每次写ETCD的CSN要加上一个backup_step (100w), 一旦GTM故障CSN从ETCD读取出来的值保证单调递增。当前GTM 只完成CSN, 预估可以支持200M/s 请求。GTM处理获取csn消息和csn的消息, TCP 协议栈消耗CPU会非常严重采用用户态协议栈提高GTM单节点的处理能力。未来架构演进完全去中心化采用高精度时钟解决扩展性问题。
5.1 单节点的事务 图2 单节点事务处理流程
关键设计 GTM 只维护一个CSN, snapshot 只包含CSN DN 本地维护事务id, 维护id到CSN的映射(CSN_LOG) DN 本地GC的过程中回填CSN 单shared读事务使用local snapshot get local latest CSN get prepared_xid wait csn commit in process(same as before) 如果row.csn localsnapshot.csn || xid in prepared_xid list 可见, 否则不可见
5.2 跨节点事务 图3 跨节点事务处理流程
关键设计 第二阶段Commit 改为异步方式只同步做prepare xact。1.5 PC DN 上行级别可见性判断 DN处于prepared状态的事务依赖对应CN上的事务是否提交如果已经提交且CSN比snapshot.CSN小就可见
对DN上处于prepared的事务CN上的事务不处于提交状态则必须判断是否残留状态回滚。
6 集群管理层CM关键技术方案
GaussDB Kernel V5 集群管理层关键模块如下。 图4 集群管理层组件设计图
CM 组件提供了四种服务 CM Agent, CM Server, OM Monitor, cm_ctl与各类实例服务组件CN, DN, GTM 等一起构成了整个数据库集群系统。
cm_ctl 通过命令行执行集群的启动、停止、状态查询、主备倒换、备机重建等功能 除启动和停止外主要通过与 CM Server 的消息传递执行命令 可在任意节点执行并获取到相同的结果
OM Monitor 由系统定时任务拉起 负责 CM Agent 的运行状态监控
CM Agent 由 OM Monitor 拉起 负责拉起和停止所在节点的 CN, DN, GTM, CM Server如果存在监控实例状态并上报至 CM Server执行 CM Server 下发的命令等 对应 cm_agent 二进制文件所有节点常驻服务
CM Server 由 CM Agent 拉起是整个集群管理组件的大脑 负责接收 cm_ctl 发送的命令并下发至 CM Agent接收并处理 CM Agent 上报的实例状态下发仲裁指令保证各类故障和异常场景下集群的可用性 对应 cm_server 二进制文件常驻服务
CM与各类组件的主备数据同步、倒换、重建等机制高度融合提供告警、重启、倒换、隔离等手段赋予数据库实例故障恢复及自愈的高可用HA能力保证数据的可靠性和完整性最终实现集群对外的业务连续性。
集群管理仲裁关键技术
单节点故障在生产过程中不可避免。CM 组件可根据探测到的状态进行仲裁从而尽可能恢复集群可用性的过程。
以某个主 DN 故障为例一次典型的仲裁流程包括
① CM Agent 1探测DN主实例并发现故障
② CM Agent 1持续上报实例故障信息至CM Server
③ CM Server执行仲裁流程选择DN备机升主
④ CM Server下发升主命令至CM Agent 2
⑤ CM Agent 2对实例执行升主操作 图5 集群管理仲裁过程
常见的故障类型包含磁盘故障、网络故障、下电故障、操作系统故障、其它故障CPU故障等。CM在选举过程中遵从DN多数派。即对于某一个DN分片来说故障后的选主需要得到大多数DN的投票候选DN副本才可以被选中升主。仲裁规则主要依据两个原则1 任期Term大且日志长的DN副本优先被选主 2 同等条件下静态主优先。
CM辅助不同组件故障情况下恢复过程
1. CN 故障 集中式部署时无CM节点 DDL 语句无法执行DML 语句不受影响 通过将故障 CN 剔除可保障 DDL 语句不受影响 仅支持集群内 CN 个数大于 3且 1 个 CN 发生故障时剔除
2. DN 故障 单点故障可自动恢复 主 DN 故障时仲裁备 DN 升主继续提供服务 备 DN 故障时主 DN 将日志和数据同步至从备业务不受影响
3. 主 GTM 故障 备 GTM 升主后继续提供服务
4. 主 CM Server 故障 备 CM Server 接受多数派 CM Agent链接升主后继续提供服务
异常检测
从业界经验来看数据库实例可能处于故障、僵死、亚健康等状态。这些状态的出现概率逐级降低但检测难度逐级增高。尤其是如何区分亚健康状态和系统繁忙状态具有较大的挑战性。
CM 组件包含异常检测流程可用于识别和处理网络不稳定、磁盘 IO 挂死、进程/线程僵死、进程频繁退出、实例状态时好时坏等场景提高集群的稳定性和可用性。
以 DN 短链接检测为例CM Agent 按照固定时间间隔与 DN 实例新建链接。如果与某个主 DN 链接失败或通过新链接无法执行 SQL 语句则认为该 DN 发生 1 次 Hang 异常。如果多次出现异常则会触发 Hang 检测机制将该 DN 实例杀死并执行主备切换。目前常见的异常检测项有 短链接建立 通过短链接执行 SQL 语句 IO 挂死 内存占用异常
基于Paxos协议复制实现DN副本自仲裁
GaussDB Kernel V5 采用基于Paxos协议主备副本复制协议实现DN副本的自仲裁功能。关键技术方案如下图所示其中DCF为GaussDB Kernel V5 基于Paxos协议的一致性复制组件。需包含日志复制、自仲裁选主等功能。 图6 DN自仲裁设计
关键技术方案要点1DN 副本自仲裁缩短仲裁链路减小RTO 2采用Paxos一致性协议保证DN副本间的一致性避免备机由于日志分叉产生增量重建。
未来技术方案演进1 DCF组件日志与数据库内核日志合一减少对IO的占用。2 采用Parallel Paxos协议或者多主的Paxos协议提升日志复制的吞吐量 3通过RDMA/UB 网络优化主、备节点日志传输提升日志复制性能。
7 OM运维管理关键技术方案
GaussDB Kernel V5 OM运维管理关键模块如下。
OM 运维主要功能有 安装 升级 节点替换 扩容、缩容 自动告警 巡检 备份恢复、容灾 日志分析系统
在华为云的部署模式下OM相关组件部署示意图如下 图7 华为云OM运维管理 用户登录华为云Console访问GaussDB Kernel V5的管控页面输入想要的运维操作购买实例。 华为云Console调用云管控服务云管控服务根据用户输入的运维操作如购买实例进行相应的操作如购买实例云管控服务会创建虚拟机。 云管控服务调用Mgr AgentMgr Agent会调用内置插件Adapter。 Adapter会调用OM Agent。 OM Agent会调用OM来完成具体的运维操作。
通过OM Adaptor和OM Agent 采用适配器模式设计对管控面提供了统一的北向接口。降低了管控面平台变更后重新对接的难度更适用于云平台下的开发模式。
8 安全关键技术方案
安全关键技术一密态等值查询
密态等值查询属于密态数据库第一阶段方案但是遵从密态数据库总体架构。密态数据库的总体架构示意图如下图所示。密态数据库的完整形态包括密码学方案和软硬结合方案。 图8 密态数据库总体架构
由于密态等值查询仅涉及到软件部分仅需集成密态数据库总体架构的软件部分其总体实现方案如下图所示。 图9 密态等值查询总体方案
从总体流程上来看数据在客户端完成加密以密文形式发送到GaussDB Kernel数据库服务侧即需要在客户端构建加解密模块。加解密模块依赖密钥管理模块密钥管理模块生成根密钥(RK, Root Key)和客户端主密钥(CMKClient Master Key)有了CMK可以通过SQL语法定义列加密密钥(CEKColumn Encryption Key)。其中CMK由RK加密后保存在密钥存储文件(KSFKey Store File)中与RK一起由KeyTool统一管理CEK则由CMK加密后存储在服务端加密算法使用AES128和AES256。
按照原有明文格式发送至服务端。当查询任务发起后客户端需要对当前的Query进行解析如果查询语句中涉及加密列则对对应的列参数(加密列关联参数)也要进行加密(这里说的加密均需要为确定性加密否则无法支持对应的查询)如果查询语句中不涉及加密列则直接发送至服务端无需额外的操作。
在数据库服务侧加密列的数据始终以密文形态存在整个查询也在密文形态下实现。对于第一阶段密态等值查询解决方案需要采用确定性加密使得相同的明文数据获得相同的密文从而支持等值计算。
按照用户使用的流程整体设计思路将围绕用户的使用步骤展开即整个Use Case被切分成三部分。具体如下 生成客户端主密钥用户需要在本地部署密钥管理工具KeyTool通过密钥管理工具相关指令来管理密钥如创建或删除密钥当前该工具底层集成华为公司KMC组件生成的主密钥通过KMC进行保存和管理并返回密钥信息给用户方便后续调用和管理 记录CMK与CEK信息在系统创建加密表有了阶段1中生成的密钥信息后为数据库设计专门的密钥创建语法包括设计新的主密钥(CMK, Client Master Key)和列加密密钥(CEK, Column Encryption Key)语法通过内核接口访问KeyTool中存储的主密钥并记录在系统中列加密密钥则由主密钥在客户端完成加密后存储在数据库服务端数据通过列加密密钥完成在客户端的加密然后传输到服务端。为了做到查询对用户的透明需要基于当前已有的创建表语法进行改造主要进一步增强列的option信息 完成密态等值查询为了完成密态等值查询需要在客户端和服务端完成配合设计。其中在客户端需要设计轻量级的解析模块完成对查询语句的解析定义密态等值查询所支持的规格。在客户端解析模块需要识别所有涉及的属性是否包含加密列信息如果不涉及则直接返回并将查询发送到服务端如果涉及加密列则需要按照对应的列加密密钥和加密算法加密参数信息然后发送查询任务到服务端。在服务端需要在优化器和执行器的各个执行逻辑过程中完成功能适配特别的数据在经过加密后存储的数据类型发生变更在服务端需要根据新的存储类型进行查询任务执行。
安全关键技术二账本数据库
防篡改数据库的整体方案如图1所示其最终形态是多个数据库之间的多方共识系统。我们基于GaussDB Kernel数据库从存储层、应用层和传输层进行改造和增强。存储层为防篡改用户表增加校验信息作为篡改校验的基础能力应用层提供高效篡改校验接口使用高性能校验算法能够快速识别出用户表、用户历史表以及全局区块表的一致性有效识别篡改行为传输层增加多方共识执行接口并内置CFG、BFT等共识算法使得系统中每一次对防篡改用户表的修改都需要取得大多数参与方的认可和记录保证核心数据的防篡改、可追溯。 图10 防篡改数据库总体方案
账本数据库属于防篡改数据库第一阶段方案是防篡改数据库的单集群形态主要是实现了存储层、执行层的功能提供了用于防篡改校验数据以及高效篡改校验算法。账本数据库作为防篡改数据库整体方案的基础功能和核心能力需要紧密结合内核并利用分布式数据库的执行框架和通信流程。
我们采用schema对防篡改用户表和普通表进行隔离。用户在防篡改schema中创建的表会成为防篡改用户表防篡改用户表与普通表最大的差别是防篡改用户表会在创建时自动添加名为hash的系统列。hash列在用户插入数据时自动通过单向加密哈希算法生成。同时在创建防篡改用户表时会在blockchain系统schema中创建与之一一对应的用户历史表。用户对防篡改表进行DML操作造成的行级数据更改记录会记录在对应的用户历史表中同时会将sql语句记录在全局区块表中作为操作的记录。防篡改用户表、用户历史表、全局区块表中的hash摘要信息可以相互校验如果校验通过则视为用户表未被篡改。
需要特别说明的是我们通过判断数据的一致性来识别篡改行为不能防止恶意用户从文件层一致的修改多个文件以及越权用户通过sql语句对用户表进行修改。
账本数据库的功能主要分为三个部分防篡改用户表的DDL和DML操作、防篡改用户表的一致性校验以及校验数据的归档和修复功能。
首先我们介绍防篡改特性的隔离级别我们使用schema来隔离普通用户表和防篡改用户表。通过增加创建防篡改schema的语法: CREATE SCHEMA schema_name WITH BLOCKCHAIN在防篡改schema中创建的表均为防篡改用户表。
其次是用户表的DDL和DML操作在创建防篡改用户表的过程中主要有两点修改
1. 对该表增加一个名为hash的伪列该列类型为uuid16该列记录和每一行数据的校验信息。
2. 生成防篡改用户表对应的用户历史表用户表中记录了行级数据的修改记录。
以上内容为数据持久化存取层(DataNode)关键技术方案、全局事务管理层GTM关键技术方案、集群管理层CM关键技术方案、OM运维管理关键技术方案和安全关键技术方案的相关内容下篇图文将接着分享智能关键技术方案、驱动接口关键技术方案的精彩内容敬请期待
欢迎小伙伴们交流~
