GaussDB 100逻辑架构如图所示。
OM
运维管理模块（Operation Manager）。提供集群日常运维、配置管理的管理接口、工具。
不同于集群中的实例（CM、CN、DN）模块，OM为用户提供了相关工具对集群进行管理。
CM
集群管理模块（Cluster Manager）。管理和监控分布式系统中各个功能单元和物理资源的运行情况，确保整个系统的稳定运行。
CM由CM Agent、daemon和CM Server组成。
CM Agent：负责监控所在主机上CN、主备DN的运行状态并将状态上报给CM Server。同时负责执行CM Server下发的仲裁指令。GaussDB 100集群的每台主机上均有CM Agent进程。
daemon ：看护CM Agent的定时任务。负责在CM Agent意外停止的情况下将CM Agent重启。
CM Server：根据CM Agent上报的实例状态判定当前是否需要修复，并下发指令给CM Agent执行。
GaussDB 100提供了CM Server的主备实例方案，以保证集群管理系统本身的高可用性。正常情况下，CM Agent连接主CM Server，在主CM Server发生故障的情况下，备CM Server会主动升为主CM Server，避免出现CM Server单点故障。
CN
协同调度节点（Coordinator Node）。负责接收来自应用的访问请求，并向客户端返回执行结果；负责分解任务，并调度任务分片在各DN上并行执行。
集群中，CN有多个且CN的角色是平等的（执行DML语句时连接到任何一个CN都可以得到一致的结果）。只需要在CN和应用程序之间增加一个负载均衡器，使得CN对应用是透明的。CN故障时，由负载均衡自动路由连接到另外一个CN。
当前分布式事务框架下无法避免CN之间的互连，建议CN配置数目<10个。
DN
数据节点（Datanode）。负责存储业务数据，执行数据查询任务以及向CN返回执行结果。
在集群中，DN有多个。每个DN支持设置多个存储备机。
使用Zenith_HA内核的DN支持设置同步备机和异步备机，使用Zenith_ZPAXOS内核的DN则不做此区分。
DN主、备机1、备机2、备机3间的工作原理如下：
主机同时向备机1，备机2同步数据。
主、备机1间无法正常同步数据时，主DN会持续向备机2同步数据，不会阻塞。
主、备机1间数据同步恢复正常后，主DN会将异常期间的数据同步到备机1DN上。
备机1DN从主DN同步数据期间，如果主DN突然故障不可用。此时，备机2升主，备机3不会升主，只有手动切换或者同城所有DN故障备机3才会升主 。
ETCD
ETCD是一个高可用的分布式键值(key-value)数据库。
负责存储集群各个节点和实例集群状态，便于集群CM管理各个实例。
在集群中，ETCD至少要有3个，可以有多个但必须是奇数个，角色分leader和follower。ETCD leader和ETCD follower间工作原理如下：
ETCD leader同时向所有ETCD follower同步数据。
写入数据到ETCD leader时，会根据raft一致性协议，与ETCD follower达成大多数一致后才能写入成功。
当ETCD 没有leader时，所有ETCD follower会自发启动抢主流程，重新选举出新的ETCD leader。
GTS
全局时钟服务器（Global Time Server）。 用于强一致场景下，为各个节点提供逻辑时钟。
全局时钟服务器（GTS）通过提供全局逻辑时钟，实现sharding间数据的强一致性读；集群中GTS节点可设置多个备节点，主备节点间的时钟通过配置NTP服务保障时间的递增属性。
时间服务器的优点有：无状态、批量处理、无锁化、无瓶颈点。GTS针对每个请求获取本地时间，多并发之间没有互斥锁或内核互斥锁，但取时间需要经过内核态调用。
Storage
服务器的本地存储资源，持久化存储数据。
