17.7. 使用与MySQL簇的高速互连

17.7.1. 配置MySQL簇以使用SCI套接字

17.7.2. 理解簇互连的影响

即使在1996年开始NDB簇的设计之前，在创建并行数据库的过程中遇到的一个主要问题显然是网络中节点之间的通信问题。正因为如此，从开始设计时，NDB簇就允许使用多种不同的数据传输机制。在本手册中，我们使用了术语传输器。

目前，MySQL簇代码库包含对四种不同传输器的支持。目前的大多数用户采用的是以太网上的TCP/IP，这是因为它无处不在。它也是迄今为止在MySQL簇中经过最佳测试的传输器。

我们正在努力，以确保与ndbd进程的通信是尽可能大的“组块”，这是因为，它有利于所有的数据传输类型。

对于需要它的用户，也能使用簇互联以进一步增强性能。实现它的方式有两种：或使用能处理该情况的定制传输器，或使用能绕过TCP/IP堆栈的套接字实施方案。我们使用由Dolphin开发的SCI（规模可扩展的计算机连接接口）技术，对这两类技术进行了试验。

17.7.1. 配置MySQL簇以使用SCI套接字

在本节中，我们将介绍如何改编为常规TCP/IP通信配置的簇，以使用SCI套接字。本文档基于2004年10月1日发布的SCI套接字2.3.0版。

前提条件

对于任何打算使用SCI套接字的机器，都必须配备SCI卡。

能够与任何版本的MySQL簇一起使用SCI套接字。不需要特殊创建，这是因为它采用了MySQL簇中已提供的正常套接字调用。但是，目前仅在Linux 2.4和2.6内核上才支持SCI套接字。尽管到目前为止我们仅在Linux 2.4上核实了这点，在一些其他操作系统上也成功测试了SCI传输器。

对于SCI套接字，有四种基本要求：

1. 创建SCI套接字库。

2. 安装SCI套接字内核库。

3. 安装1个或2个配置文件。

4. 必须为整个机器或启动MySQL簇进程的shell启用SCI套接字库。

对于打算将SCI套接字用于节点间的通信的簇，需要为簇中的每台机器重复该进程。

要想使SCI套接字工作，需要获得两个软件包：

1. 包含用于SCI套接字库的DIS支持库的源码软件包。

2. 用于SCI套接字库本身的源码软件包。

目前，仅以源码格式提供了它们。编写本文档时可用的最新版本的软件包分别是DIS_GPL_2_5_0_SEP_10_2004.tar.gz和SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz。在下述站点，可找到它们（也可能找到更新的版本）：http://www.dolphinics.no/support/downloads.html。

软件包安装

获得库软件包后，接下来应将它们解包到恰当的目录下，将SCI套接字库解包到DIS代码下的目录中。然后，需要创建库。在下面的示例中，给出了在Linux/x86平台上执行该任务所需的命令：

shell> tar xzf DIS_GPL_2_5_0_SEP_10_2004.tar.gz

shell> cd DIS_GPL_2_5_0_SEP_10_2004/src/

shell> tar xzf ../../SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz

shell> cd ../adm/bin/Linux_pkgs

shell> ./make_PSB_66_release

能够为64位处理器创建这些库。要想为使用64位扩展的Opteron CPU创建这些库，请运行make_PSB_66_X86_64_release而不是make_PSB_66_release。如果创建工作是在Itanium机器上进行的，应使用make_PSB_66_IA64_release。X86-64变体应能与Intel EM64T体系结构一起工作，但这点尚未测试（就我们所知）。

完成创建进程后，在zipped tar文件中可发现已编译好的库，文件的名称符合DIS-<operating-system>-time-date。现在，可将软件包安装到恰当位置。在本例中，我们使用的安装目录是/opt/DIS（注释：你很可能需要以系统根用户的身份运行下述命令）：

shell> cp DIS_Linux_2.4.20-8_181004.tar.gz /opt/

shell> cd /opt

shell> tar xzf DIS_Linux_2.4.20-8_181004.tar.gz

shell> mv DIS_Linux_2.4.20-8_181004 DIS

网络配置

至此，所有的库和二进制文件均已安装到了恰当的位置，还需确保SCI卡在SCI的地址空间范围内拥有恰当的节点ID。

进行后面的操作前，还需确定网络结构。对于该情形，有三种可使用的网络结构：

·一维单环网络。

·1个或多个SCI交换器，每个交换器端口有1个环形网。

·2维或3维环面网。

每类拓扑结构均有自己的、用于提供节点ID的方法。下面给出了简要讨论。

单环网采用的节点ID是4的非0倍数，4，8，12…。

下一个可行的选择是SCI交换器。1个SCI交换器有8个端口，每个端口都能支持1个环形网。有必要确保不同的环形网使用了不同的节点ID空间。对于典型的配置，第1个端口使用的节点ID低于64（4～60），接下来的64个节点ID（68～124）指定给下一个端口，依此类推，节点ID 452～508将被指定给第8个端口。

对于2维或3维环面网结构，每个节点位于各维中，在第1维中，各节点的增量为4，在第2维中，增量为64，在第3维中（如果适用的话），增量为1024。关于更详尽的文档，请参见Dolphin的网站。

在我们的测试中，采用了交换器方式，但大多数大型簇安装应用使用的是2维或3维环面网结构。采用交换器方式具有的优点是：使用双SCI卡和双交换器，能够相对容易地创建冗余网络，SCI网络上的平均故障切换时间在100毫秒量级。对于SCI套接字实施，MySQl簇中的SCI传输器支持该结构，而且它也处于发展当中。

对于2D/3D环面网，故障切换也是可能的，但需要向所有节点发送发出新的路由索引。然而，这仅需要100毫秒左右就能完成，对于大多数高可用性情形，这是可接受的。

通过将簇数据节点恰当地置于交换式体系结构中，能够使用2个交换器来构建结构，将16台计算机互联在一起，任何单点故障均不会妨碍1台以上的计算机。对于32台计算机和2台交换器，也能以这样的方式配置簇，任何单点故障均不会导致2个以上的节点丢失，在此情况下，也能知道那一对节点收到影响。因此，通过将两个节点置于不同的节点组，就能创建“安全的”MySQL簇。

要想为SCI卡设置节点ID，可使用/opt/DIS/sbin目录中的下述命令。在本例中，“-c 1”指的是SCI卡的编号（如果在机器上只有1块卡，它总为1），“-a 0”指的是适配器0，“68”是节点ID：

shell> ./sciconfig -c 1 -a 0 -n 68

如果在同一台机器上有多块SCI卡，使用下述命令（假定当前的工作目录是/opt/DIS/sbin），可确定哪块卡使用哪个插槽：

shell> ./sciconfig -c 1 -gsn

它将给出SCI卡的序列号。然后用“-c 2”重复该步骤，依此类推（对机器上的每块卡）。一旦将每块卡与1个插槽匹配后，可为所有卡设置节点ID。

安装了必要的库和二进制文件，并设置了SCI节点ID后，下一步是设置从主机名（或IP地址）到SCI节点ID的映射。该任务可在SCI套接字配置文件中完成，该文件应被保存为/etc/sci/scisock.conf。在该文件中，通过恰当的SCI卡将SCI节点映射到与之通信的主机名或IP地址。这里给出了一个很简单的配置文件示例：

#host   #nodeId

alpha   8

beta    12

192.168.10.20   16

也能对配置进行限制，使其仅应用在这些主机的可用端口子集上。也能使用额外的配置文件/etc/sci/scisock_opt.conf完成该设置，如下所示：

#-key-type-values

EnablePortsByDefaultyes

EnablePort  tcp   2200

DisablePort tcp   2201

EnablePortRange     tcp   2202 2219

DisablePortRange    tcp   2220 2231

驱动程序安装

创建好了配置文件后，可安装驱动程序。

首先应安装底层驱动，然后安装SCI套接字驱动：

shell> cd DIS/sbin/

shell> ./drv-install add PSB66

shell> ./scisocket-install add

如果愿意，可调用脚本来核实SCI套接字配置文件中的所有节点是否均能访问，通过该方式检查安装：

shell> cd /opt/DIS/sbin/

shell> ./status.sh

如果发现错误并需要更改SCI套接字配置，需要使用ksocketconfig来完成该任务：

shell> cd /opt/DIS/util

shell> ./ksocketconfig -f

测试设置

为了确保SCI套接字已实际使用，可使用latency_bench测试程序。使用该实用工具的服务器组件，客户端能够连接服务器以测试连接的等待时间，通过观察等待时间，可方便地判定是否启用了SCI。（注释：使用latency_bench之前，需要设置环境变量LD_PRELOAD，请参见本节后面的介绍）。

要想设置服务器，可使用下述命令：

shell> cd /opt/DIS/bin/socket

shell> ./latency_bench -server

要想运行客户端，再次使用latency_bench，但此时采用“-client”选项：

shell> cd /opt/DIS/bin/socket

shell> ./latency_bench -client server_hostname

到目前为止，应完成了SCI套接字配置，而且MySQL簇已做好了使用SCI套接字和SCI传输器的准备（请参见17.4.4.10节，“MySQL簇SCI传输连接”）。

启动簇

该进程接下来的步骤是启动MySQL簇。要想启用SCI套接字，在启动ndbd、mysqld和ndb_mgmd之前，需要设置环境变量LD_PRELOAD。该变量应指向用于SCI套接字的内核库。

要想在bash shell下启动ndbd，可执行下述命令：

bash-shell> export LD_PRELOAD=/opt/DIS/lib/libkscisock.so

bash-shell> ndbd

在tcsh环境下，可使用下述命令完成相同的任务：

tcsh-shell> setenv LD_PRELOAD=/opt/DIS/lib/libkscisock.so

tcsh-shell> ndbd

注释：MySQL簇可以仅使用SCI套接字的内核变体。

17.7.2. 理解簇互连的影响

有四种访问方法：

·主键访问

通过其主键简单地访问记录。在最简单的情况下，一次仅访问一条记录，这意味着该单一请求需负担设置众多TCP/IP消息的全部开销以及众多的场景切换开销。对于在一批中发出多个主键访问请求的情况，这些访问请求将分担设置必要TCP/IP消息和场景切换的开销。如果TCP/IP消息是面向不同目标的，还须设置额外的TCP/IP消息。

·唯一键访问

唯一键访问与主键访问类似，差别在于，唯一键访问是作为在索引表上的读取操作执行的，然后是作用在表上的主键访问。但是，MySQL服务器仅发送一条请求，而且对索引表的读取是由ndbd负责处理的。这类请求也受益于批处理法。

·全表扫描

对于表查询，当不存在索引时，将执行全表扫描。这将作为单一请求被发送至ndbd进程，该进程随后将表扫描分为在所有簇ndbd进程上进行的一组并行扫描。在未来的MySQL簇版本中，SQL节点能够过滤某些扫描。

·使用有序索引的范围扫描

使用有序索引时，它将使用与全表扫描相同的方式执行扫描，不同之处在于，它仅扫描位于MySQL服务器（SQL节点）所传输查询使用的范围内的记录。当所有绑定的索引属性包含分区键中的所有属性时，将以并行方式扫描所有分区。

为了检查这些访问方法的基本性能，我们开发了一组基准。作为这类基准之一，testReadPerf能够测试简单的和批处理式主键和唯一键访问。通过发出返回单一记录的扫描请求，该基准还能测量范围扫描的设置开销。此外，还有1个该基准的变体，它采用了范围扫描来获取批量记录。

这样，我们就能确定单键访问的开销，以及单记录扫描访问的开销，并能根据基本访问方法测量通信媒介的影响。

在我们进行的测试中，为采用TCP/IP套接字的正常传输器和使用SCI套接字的类似设置进行了基本设置。下面给出的数字是关于少量访问的，每次访问20条记录。使用2KB的记录时，串行访问和批式访问之间的差异将降低3～4倍。对于2KB的记录，未测试SCI套接字。测试是在下述簇上进行的，该簇有两个数据节点，这两个数据节点运行在2台双CPU机器上，处理器为AMD MP1900+。

Access type: TCP/IP sockets   SCI Socket

Serial pk access:    400 microseconds 160 microseconds

Batched pk access:    28 microseconds  22 microseconds

Serial uk access:    500 microseconds 250 microseconds

Batched uk access:    70 microseconds  36 microseconds

Indexed eq-bound:   1250 microseconds 750 microseconds

Index range:  24 microseconds  12 microseconds

我们还执行了另一组测试，以检查SCI套接字的性能以及SCI传输器的性能，并将这两者与TCP/IP传输器的性能进行了比较。所有测试均采用了主键访问方法，或采用串行多线程方式，或采用多线程批方式。

测试结果表明，SCI套接字比TCP/IP约快100％。与SCI套接字相比，在大多数情况下，SCI传输器的速度更快。在具有很多线程的测试程序中出现了1个值得关注的情况，它表明，与mysqld进程一起使用时，SCI传输器的执行性能并不很好。

我们得出的总体结论是，对于大多数基准，与TCP/IP相比，除了罕见的通信性能不成其为关注事宜的情况外，使用SCI套接字能将性能提升约100％。当扫描过滤器占用大多数处理时间，或当执行大量的主键访问，就会出现该情况。在这类情况下，ndbd进程中的CPU处理操作将占用开销的相当大部分。

对于使用SCI传输器来取代SCI套接字，它仅对ndbd进程之间的通信有意义。如果CPU能专门用于ndbd进程，使用SCI传输器也也很有意义，这是因为SCI传输器能确保该进程永不休息。另一个重要特性是，它能确保对ndbd进程的优先级进行特定的设置，即使运行了很长的时间，其优先级也不会丧失，就像在Linux 2.6中通过将进程锁定到CPU而能实现的那样。如果这类配置是可能的，与使用SCI套接字相比，ndbd进程将获得10～70％的性能提升（执行更新以及可能的并行扫描操作时，性能提升较大）。。

对于计算机簇，还有数种其他的优化套接字实施方案，包括Myrinet、吉比特以太网、Infiniband（无限带宽）和VIA接口。迄今为止，我们仅与SCI套接字一起测试了MySQL簇。我们还提供了上述文档，其中，介绍了如何使用针对MySQL簇的常规TCP/IP来设置SCI套接字的方法。