IBM dashDB Local 从入门到精通，第 2 部分 IBM 私有云数据仓库解决方案介绍（4）
上篇文章，我们为大家介绍了 dashDB Local 优势、dashDB Local 应用场景及实现路径、dashDB Local 架构、dashDB Local 最小系统配置及建议系统配置，接下来，我们继续为大家介绍 dashDB Local MPP 弹性伸缩能力、dashDB Local MPP 高可用性、dashDB Local 支持 R 及 SPARK 分析、dashDB Local 的维护、Data Server Manager for dashDB Local 等内容。
Massively Parallel Processing (MPP) for dashDBdashDB Local 支持 SMP 及 MPP 两种并行处理架构，传统的 SMP 并行处理架构可以将查询任务在多 cpu 核上并行处理，如下图所示：
图 1. SMP 并行处理架构采用 SMP 处理架构的主要特点包括：
针对小于 12TB 规模数据集
通常价格比较便宜
性能较慢
MPP 并行处理架构可以将查询任务在多 cpu 核上及多台机器之间并行处理，如下图所示：
图 2. MPP并行处理架构采用 MPP 处理架构的主要特点包括：
针对大于 4TB 规模数据集
需要更多的月预算
性能非常高
dashDB LocalMPP 配置
通常，dashDB Local MPP 的配置如下图所示：
图 3. dashDB Local MPP 典型配置
每台主机运行一个 dashDB Local 容器
主机可以是裸机（bare metal）或虚拟机
dashDB Local MPP 包含 1 个 head node，多个 data node
最少包含 3 个 nodes，最多支持 24 个 nodes
LDAP 服务器及控制台 Console 同一时间只在一个节点上被激活
dashDB Local MPP 弹性伸缩能力dashDB Local MPP 弹性伸缩能力主要体现在以下几个方面：
自动探知硬件资源并执行扩展操作
Docker 容器自动感知硬件资源情况并执行扩展操作，在执行变更操作时只需要临时停止 dashDB Local 服务，对数据库操作产生极小的中断。
在旧机器上停止容器服务，拷贝数据到新的文件系统上，并在新机器上启动容器即可，容器的移植非常简单。 Elasticity: Scale Out
dashDB Local MPP 的 Scale Out 操作允许根据需要增加新节点或删除现存节点，数据分区会自动在所有容器之间重分布，而数据不需要进行重分布。
当执行扩展操作时，用户需要在宿主机上增加相应的存储容量到集群文件系统中，增加的新节点将加入到 HA 组中，数据分区会自动在所有容器之间重分布，如下图所示：
图 4. dashDB Local MPP Scale Out在这个示例中，我们将在 3 个节点的 dashDB Local MPP 集群中增加一个新节点，并在集群文件系统中增加新的容量，此时，数据库的 24 个分区将在 ContainerA、ContainerB、ContainerC、ContainerD 之间重新分布，但数据保持不变。
dashDB Local MPP 集群最多支持 24 个节点。当我们需要增加新的节点时，首先，我们需要准备这些新机器，包括在新机器上安装操作系统、将集群文件系统挂接到新增加的机器上、保证所需的网络端口处于打开状态、运行 docker pull 命令下载 dashDB Local 镜像到新机器上。接下来，我们需要注册这些新机器到 dashDB Local MPP 集群，包括在 node 文件中为每一台新机器增加一条记录、执行 docker stop dashDB 命令停止集群服务、在这些节点上运行 docker run 命令。docker run 命令将执行一些准备工作，包括设置 SSH 连接、保证网络通信等，它只需执行几秒钟。这个过程，和初始部署工作类似。最后，我们在 head node 上运行 docker exec -it dashDB start 命令启动 dashDB Local 服务，数据分区或 data slices 会重分布、系统自动配置并优化 dashDB 数据库，这个过程会需要 10 分钟左右。由于我们在对新机器进行准备阶段时，系统还在运行，只是在注册过程及重启服务阶段才需要停止服务，因此，基本上 10 分钟左右新的集群就可以正常工作了。
Scale In 同 Scale Out 过程类似，同样可以很快完成集群重构过程。 Elasticity: Scale Up
dashDB Local MPP 的 Scale Up 允许我们调整节点的 CPU 及内存资源配置。由于 dashDB Local 容器同存储卷相互独立，因此，Scale Up 操作十分简单。Scale Up 操作可以有以下两种场景：
场景一：完全更换服务器（Server A -> Server B）
操作过程包括：在旧机器上运行 docker stop dashDB 命令停止 dashDB 容器、执行 docker run 命令在新机器上重建 dashDB Local 容器，此时我们将透明地将无状态的 dashDB Local 容器重新链接到存储卷上的状态数据。如下图所示：
图 5. dashDB Local MPP Scale Up
场景二：增加节点资源
针对该场景，我们只需要重启容器即可。
当执行 Scale Up 操作时，系统会检测到硬件资源的变化进行自动重配置、重优化，而应用程序指向相同的 IP 地址，因此，应用升级是无缝的。 dashDB Local: Portability
dashDB Local MPP 的可移植性允许我们在云和本地数据中心之间方便地进行迁移，也是 dashDB Local 灾备（DR）的一种解决方案。当我们完成从云到本地数据中心迁移时，我们只需要停止云上旧服务器的 dashDB Local 容器、将集群文件系统从云上拷贝到本地数据中心、在本地数据中心重新创建 dashDB Local 容器即可，如下图所示：
图 6. dashDB Local MPP Portability该种 DR 解决方式，允许我们用可承受的价格、灵活的基础设施支撑来实现从本地到云或从云到本地等形式的灾备功能。
dashDB Local MPP 高可用性dashDB Local MPP 内置容器级别高可用性，它基于心跳检测、服务自动重启及节点接管机制。当心跳检测到节点、数据分区、web 控制台失效后，集群管理器会执行相应的动作，如重启失效的数据分区或 web 控制台。由于文件系统不是 HA 组的一部分，我们需要使用相应的 HA 解决方案来实现存储的高可用。另外，我们还需要使用负载均衡器（load balancer）来实现当 head 节点失效后应用程序透明连接问题。dashDB Local 1.6.0 版本提供了对 HAProxy load balancer 的支持。
如下图所示，我们有 1 个 head 节点和 3 个数据节点，heartbeat 运行在每一个节点上，它负责检测节点、容器、服务的状态，当发生失效事件时，head 节点上的 system manager 会协调数据节点上的 system manager 执行相应的动作，如重启失效的数据分区或 web 控制台。
图 7. dashDB Local MPP高可用性目前，dashDB Local MPP 最少包含 3 个节点，最多支持 24 个节点，系统定义了 24 个数据分区，这些分区分布在所有节点上。根据节点的个数，每一个节点会分配相应数量的分区，如下所示：
3 个容器->分配 8 个分区
4 个容器->分配 6 个分区
6 个容器->分配 4 个分区
如下图所示，我们有 3 个节点，其中包含 1 个 Head 节点和 2 个数据节点。系统为每一个节点分配 8 个数据分区。Head 节点还负责响应 Web 控制台服务及应用程序连接请求。Heartbeat 负责检测节点、数据分区及服务的状态。
图 8. 3 个节点 dashDB Local MPP 高可用配置 如果使用 dashDB Local 1.7 或更高版本，部署时集群内存总量至少 960 GB，将分配 60 个数据分区，最多支持 60 个节点（1 个 head 节点，59 个数据节点）。
dashDB Local MPP 提供容器级别的高可用性，当容器内服务失效，比如说 dashDB 引擎失效，dashDB Local 系统管理器会检测到该故障并重新启动 dashDB 引擎；当整个容器失效，也就是说节点失效时，dashDB Local 检测到该故障并会在其他存活的容器上启动 dashDB 服务。
当 Head 节点失效，dashDB Local 会在活动的数据节点中选举出一个新的 Head 节点，Web 控制台在该节点上重新启动，应用也要重新路由到该节点上。如下图所示：
图 9. 3 个节点 dashDB Local MPP 配置故障切换当 Head 节点失效时，它上面的 8 个数据分区或 data slices 将被分配给其他 2 个数据节点，4 个数据分区分配给数据节点 1，另外 4 个数据分区分配给数据节点 2。由于是 Head 节点失效，新的 Head 节点将从存活的 2 个数据节点中选出，我们这里，数据节点 1 被选举为新的 Head 节点。
由此可见，dashDB Local MPP 提供了无需管理的、自动的、完全集成的 HA 解决方案。
采用 SMP 处理架构的主要特点包括：
采用 MPP 处理架构的主要特点包括：
在这个示例中，我们将在 3 个节点的 dashDB Local MPP 集群中增加一个新节点，并在集群文件系统中增加新的容量，此时，数据库的 24 个分区将在 ContainerA、ContainerB、ContainerC、ContainerD 之间重新分布，但数据保持不变。
该种 DR 解决方式，允许我们用可承受的价格、灵活的基础设施支撑来实现从本地到云或从云到本地等形式的灾备功能。
目前，dashDB Local MPP 最少包含 3 个节点，最多支持 24 个节点，系统定义了 24 个数据分区，这些分区分布在所有节点上。根据节点的个数，每一个节点会分配相应数量的分区，如下所示：
如果使用 dashDB Local 1.7 或更高版本，部署时集群内存总量至少 960 GB，将分配 60 个数据分区，最多支持 60 个节点（1 个 head 节点，59 个数据节点）。
当 Head 节点失效时，它上面的 8 个数据分区或 data slices 将被分配给其他 2 个数据节点，4 个数据分区分配给数据节点 1，另外 4 个数据分区分配给数据节点 2。由于是 Head 节点失效，新的 Head 节点将从存活的 2 个数据节点中选出，我们这里，数据节点 1 被选举为新的 Head 节点。