集群部署规范

集群部署规范篇一：集群硬件配置规范集群硬件配置规范 利用淘汰过时的主机，做更大的事情。这里的主机是指商业主机，并非个人主机。 Hadoop 的管理员考虑到各种因素。Hadoop 是在完整的行业标准的硬件上运行，建议一个理想的集群配置是不一样只是提供了硬件规格列表容易。选择硬件提供了一个给定的工作负载的性能和经济的最佳平衡，需要测试和验证。例如，用户 IO 密集型工作负载将投资在些每核心主轴。在这里将讨论的工作量评价和它在硬件的选择起着至关重要的作用。 存储和计算的融合 IT 组织有标准化的刀片服务器和 SAN（存储区域网络），以满足他们的网格和处理密集型工作负载。虽然这种模式使一些标准的应用，如 Web 服务器，应用服务器，规模较小的结构化数据库和简单的 ETL（提取，转换，装载）基础设施的要求有很大的意义已经发生变化的数据量和数量用户已经成长。 Web 服务器现在前端使用缓存层，数据库使用大规模并行与本地磁盘，ETL 作业正在推动更多的数据比他们可以在本地处理。硬件厂商建立创新体系，以满足这些要求包括存储刀片，SAS（串行连接 SCSI）开关，外部SATA 阵列和更大容量的机架单元。 Hadoop 的目的是基于一种新的方法来存储和处理复杂的数据。海量存储和可靠性进行处理然后移动到刀片服务器的集合，而不是依靠在 SAN 上，Hadoop 的处理大数据量和可靠性，在软件层。 Hadoop 的数据分布到集群上，处理平衡，并使用复制，以确保数据的可靠性和容错。因为数据的分布式计算能力的机器上，处理可以直接发送到存储数据的机器。由于每个机器在一个 Hadoop 集群的存储和处理数据，他们需要进行配置，以满足数据存储和处理要求。 任务压力问题 MapReduce 作业，在几乎所有情况下，将遇到一个瓶颈，从磁盘或从网络（作为 IO 密集型的工作） ，或在处理数据读取的数据（CPU 密集型工作） 。 IO 密集型工作的一个例子是排序，这就需要非常小的加工（简单的比较）和大量的读取和写入磁盘。一个 CPU 密集型的工作的一个例子是分类，其中一些输入数据处理非常复杂的方式来确定一个本体。 ? IO 密集型工作负载 Hadoop 涉及到的 I/O 操作，主要包括下列几项： 索引（Indexing） 群化（Grouping） 数据导入和导出（Data importing and exporting） 数据移动和转换（Data movement and transformation） ? CPU 密集型工作负载 Hadoop 中，作业的执行，需要 CPU 的持续运作。下面列举了几个方面： 集群处理（Clustering/Classification） 复杂的文本挖掘 Complex text mining 自然语言的处理(Natural-language processing) 特殊功能的提取（Feature extraction） 根据客户需要完全理解集群的工作负载，才能选择最优的 Hadoop 硬件，而这好像是一个鸡生蛋蛋生鸡的问题。大多数工作组在没有彻底剖析他们的工作负载时，就已经搭建好了 Hadoop 集群，通常 Hadoop 运行的工作负载随着他们的精通程度的提高而完全不同。而且，某些工作负载可能会被 一些未预料的原因受限。例如，某些理论上是 IO 受限的工作负载却最终成为了 CPU 受限，这是可能是因为用户选择了不同的压缩算法，或者算法的不同实现改变 了 MapReduce 任务的约束方式。基于这些原因，当工作组还不熟悉要运行任务的类型时，深入剖析它才是构建平衡的 Hadoop 集群之前需要做的最合理的工作。 接下来需要在集群上运行 MapReduce 基准测试任务，分析它们是如何受限的。完成这个目标最直接的方法是在运行中的工作负载中的适当位置添加监视器来 检测瓶颈。我们推荐在 Hadoop 集群上安装 Cloudera Manager，它可以提供 CPU，硬盘和网络负载的实时统计信息。 （Cloudera Manager 是 Cloudera 标准版和企业版的一个组件，其中企业版还支持滚动升级）Cloudera Manager 安装之后，Hadoop 管理员就可以运行MapReduce 任务并且查看 Cloudera Manager 的仪表盘，用来监测每台机器的工作情况。 在为工作负载构建合适的集群之外，还建议客户和硬件提供商合作确定电力和冷却方面的预算。由于 Hadoop会运行在数十台，数百台到数千台节点上。通过使用高性能功耗比的硬件，作业组可以节省一大笔资金。硬件提供商通常都会提供监测功耗和冷却方面的工具和建议。 要怎么选择硬件配置呢？ 选择机器配置类型的第一步就是了解运维团队已经在管理的硬件类型。在购买新的硬件设备时，运维团队经常根据一定的观点或者强制需求来选择，并且倾向于工作在自己业已熟悉的平台类型上。Hadoop 不是唯一的从规模效率上获益的系统。再一次强调，作为更通用的建议，如果集群是新建立的或者并不能准确的预估极限工作负载，建议选择均衡的硬件类型。 Hadoop 集群有四种基本任务角色:NameNode（包括SecondaryNameNode） ，JobTracker，TaskTrackers，和 DataNode 节点。节点是执行某一特定功能的工作站。大部分集群内的节点需要执行两个角色的任务，作为 DataNode（数据存储）和TaskTrackers（数据处理） 。这是在一个平衡 Hadoop 集群中，为DataNode/TaskTrackers 提供的推荐规格： ? 在一个磁盘阵列中要有 12 到 24 个 14TB 硬盘 ? 2个频率为 2的四核、六核或八核 CPU ? 64512GB 的内存 ? 有保障的千兆或万兆以太网（存储密度越大，需要的网络吞吐量越 高）NameNode 负责协调集群上的数据存储，JobTracker 协调数据处理（SecondaryNameNode 不应与集群中的 NameNode 共存，并且运行在与之相同的硬件环境上。） 。 在这里强烈推荐客户购买在 RAID1 或 10 配置上有足够功率和企业级磁盘数的商用机器来运行 NameNode 和JobTracker。 NameNode 也会直接需要与群集中的数据块的数量成比例的 RAM。一个好的但不精确的规则是对于存储在分布式文件系统里面的每一个 1 百万的数据块，分配 1GB 的NameNode 内存。在一个群集里面的 100 个 DataNodes 而言，NameNode 上的 64GB 的 RAM 提供了足够的空间来保证集群的增长。我们也推荐把 HA 同时配置在 NameNode 和JobTracker 上， 这里就是为 NameNodeJobTrackerStandby NameNode 节点群推荐的技术细节。驱动器的数量或多或少，将取决于冗余数量的需要。 ? 46 1TB 硬盘驱动器 采用一个 JBOD 配置(1 个用于 OS, 2 个用于文件系统映像RAID 1, 1 个用于 Apache ZooKeeper, 1 个用于 Journal 节点) ? 2 4-/16-/8-核心 CPUs,至少运行于 ? 64-128GB 随机存储器 ? Bonded Gigabit 以太网卡 or 10Gigabit 以太网卡 如果 Hadoop 集群扩展到 20 台机器以上，推荐最初配置的集群应分布在两个机架，而且每个机架都有一个位于机架顶部的 10G 的以太网交换机。当这个集群跨越多个机架的时候，将需要添加核心交换机使用 40G 的以太网来连接位于机架顶部的交换机。两个逻辑上分离的机架可以让维护人员更好地理解机架内部和机架间通信对网络需求。 Hadoop 集群安装好后，维护人员就可以开始确定工作负载，并准备对这些工作负载进行基准测试以确定硬件瓶颈。经过一段时间的基准测试和监视，维 护人员将会明白如何配置添加的机器。异构的 Hadoop集群是很常见的，尤其是在集群中用户机器的容量和数量不断增长的时候更常见。因此为你的工作负载所配置的“不理想”开始时的那组机器不是在浪费时间。Cloudera管理器提供了允许分组管理不同硬件配置的模板，通过这些模板你就可以简单地管理异构集群了。下面是针对不同的工作负载所采用对应的各种硬件配置的列表，包括我们最初推荐的“负载均衡”的配置： ? 轻量处理方式的配置(1U 的机器）:两个 16 核的CPU，24-64GB 的内存以及 8 张硬盘（每张 1TB 或者 2TB)。 ? 负载均衡方式的配置(1U 的机器）:两个 16 核的CPU，48-128GB 的内存以及由主板控制器直接连接的 12-16张硬盘（每张 1TB 或者 2TB)。通常在一个 2U 的柜子里使用2 个主板和 24 张硬盘实现相互备份。 ? 超大存储方式的配置(2U 的机器）:两个 16 核的CPU，48-96GB 的内存以及 16-26 张硬盘（每张 2TB-4TB)。这种配置在多个节点/机架失效时会产生大量的网络流量。 ? 强力运算方式的配置(2U 的机器）:两个 16 核的CPU，64-512GB 的内存以及 4-8 张硬盘（每张 1TB 或者 2TB)。关于 CPU 的选择考虑 Hadoop 生态系统设计是考虑了并行计算的特点。在选择硬件的时候不建议选择高主频的处理器，高主频的处理器都有很高的功耗和散发热量这两大问题。当然也不能选择主频较低的处理器，处于中间性能的价位的处理器，在频率、价格和核心数方面性价比是最好的。公司系统主流使用的 CPU：英特尔 Intel 至强 E3 其他 。 在单个以太网网卡的情况下，将接入和接出分别绑定在不同的端口上。或者装备两张或两张以上的以太网网卡。这样可保证每台机子提供 2Gbps 的数据流量。 绑定 2Gbps 的节点最多可容纳的数据量是 12TB。一旦你传输的数据超过 12TB，你将需要使当遇上生成大量中间数据的应用时，也就是说输出数据的量和读入数据的量相等的情况时 用传输速率为捆绑方式实现的 4Gbps(4x1Gbps)。另外，对哪些已经使用 10Gb 带宽的以太网或者无线网络用户来说，这样的方案可以用来按照网络带宽实现工作负载的分配。 内存大小选择需要考虑额外的开销，Java 本身要使用高达 10%的内存来管理虚拟机。建议把 Hadoop 配置为只使用堆，这样就可以避免内存与磁盘之间的切换。切换大大地降低 MapReduce 任务的性能，并且可以通过给机器配置更多的内存以及给大多数 Linux 发布版以适当的内核设置就可以避免这种切换。 优化内存的通道宽度也是非常重要的。例如，当使用双通道内存时，每台机器就应当配置成对内存模块（DIMM） 。当使用三通道的内存时，每台机器都应当使用三的倍数个内存模块（DIMM） 。类似地，四通道的内存模块（DIMM)就应当按四来分组使用内存。 公司的硬件配置选择 根据现有的数据和业务，系统现有数据量达亿条数据，要进行存储以及全文检索，适当的对数据进行统计和分类，并生成索引数据。公司在开发测试阶段使用的配置比生产环境下的硬件配置要低。在生产环境下对硬件的推荐选择如下： 测试环境，配置如下：篇二：Redis 集群规范Redis 集群规范 引言 这个文档是正在开发中的 Redis 集群功能的规范（specification）文档， 文档分为两个部分： 第一部分介绍目前已经在 unstable 分支中实现了的那些功能。 第二部分介绍目前仍未实现的那些功能。 文档各个部分的内容可能会随着集群功能的设计修改而发生改变， 其中， 未实现功能发生修改的几率比已实现功能发生修改的几率要高。 这个规范包含了编写客户端库（client library）所需的全部知识， 不过请注意， 这里列出的一部分细节可能会在未来发生变化。 什么是 Redis 集群？ Redis 集群是一个分布式（distributed） 、容错（fault-tolerant）的 Redis 实现， 集群可以使用的功能是普通单机 Redis 所能使用的功能的一个子集（subset） 。 Redis 集群中不存在中心（central）节点或者代理（proxy）节点， 集群的其中一个主要设计目标是达到线性可扩展性（linear scalability） 。 Redis 集群为了保证一致性（consistency）而牺牲了一部分容错性： 系统会在保证对网络断线（net split）和节点失效（node failure）具有有限（limited）抵抗力的前提下， 尽可能地保持数据的一致性。 集群将节点失效视为网络断线的其中一种特殊情况。集群的容错功能是通过使用主节点（master）和从节点（slave）两种角色（role）的节点（node）来实现的： 主节点和从节点使用完全相同的服务器实现， 它们的功能（functionally）也完全一样， 但从节点通常仅用于替换失效的主节点。 不过， 如果不需要保证“先写入，后读取”操作的一致性（read-after-write consistency） ， 那么可以使用从节点来执行只读查询。 Redis 集群实现的功能子集 Redis 集群实现了单机 Redis 中， 所有处理单个数据库键的命令。 针对多个数据库键的复杂计算操作， 比如集合的并集操作、合集操作没有被实现， 那些理论上需要使用多个节点的多个数据库键才能完成的命令也没有被实现。 在将来， 用户也许可以通过 MIGRATE COPY 命令， 在集群的计算节点（computation node）中执行针对多个数据库键的只读操作， 但集群本身不会去实现那些需要将多个数据库键在多个节点中移来移去的复杂多键命令。 Redis 集群不像单机 Redis 那样支持多数据库功能，集群只使用默认的 0 号数据库， 并且不能使用 SELECT 命令。 Redis 集群协议中的客户端和服务器 Redis 集群中的节点有以下责任： 持有键值对数据。 记录集群的状态，包括键到正确节点的映射（mapping keys to right nodes） 。 自动发现其他节点，识别工作不正常的节点，并在有需要时，在从节点中选举出新的主节点。 为了执行以上列出的任务， 集群中的每个节点都与其他节点建立起了“集群连接（cluster bus） ”， 该连接是一个 TCP 连接， 使用二进制协议进行通讯。 节点之间使用 Gossip 协议 来进行以下工作： 传播（propagate）关于集群的信息，以此来发现新的节点。 向其他节点发送 PING 数据包，以此来检查目标节点是否正常运作。 在特定事件发生时，发送集群信息。 除此之外， 集群连接还用于在集群中发布或订阅信息。 因为集群节点不能代理（proxy）命令请求， 所以客户端应该在节点返回 -MOVED 或者 -ASK 转向（redirection）错误时， 自行将命令请求转发至其他节点。 因为客户端可以自由地向集群中的任何一个节点发送命令请求， 并可以在有需要时， 根据转向错误所提供的信息， 将命令转发至正确的节点， 所以在理论上来说，客户端是无须保存集群状态信息的。 不过， 如果客户端可以将键和节点之间的映射信息保存起来， 可以有效地减少可能出现的转向次数， 籍此提升命令执行的效率。 键分布模型 Redis 集群的键空间被分割为 16384 个槽（slot） ， 集群的最大节点数量也是 16384 个。 推荐的最大节点数量为 1000 个左右。 每个主节点都负责处理 16384 个哈希槽的其中一部分。 当我们说一个集群处于“稳定” （stable）状态时， 指的是集群没有在执行重配置（reconfiguration）操作， 每个哈希槽都只由一个节点进行处理。 重配置指的是将某个/某些槽从一个节点移动到另一个节点。 一个主节点可以有任意多个从节点， 这些从节点用于在主节点发生网络断线或者节点失效时， 对主节点进行替换。 以下是负责将键映射到槽的算法： HASH_SLOT = CRC16(key) mod 16384 以下是该算法所使用的参数： 算法的名称: XMODEM (又称 ZMODEM 或者 CRC-16/ACORN) 结果的长度: 16 位 多项数（poly）: 1021 (也即是 x16 + x12 + x5 + 1) 初始化值: 0000 反射输入字节（Reflect Input byte）: False 发射输出 CRC （Reflect Output CRC）: False 用于 CRC 输出值的异或常量（Xor constant to output CRC）: 0000 该算法对于输入 “123456789“ 的输出: 31C3 附录 A 中给出了集群所使用的 CRC16 算法的实现。 CRC16 算法所产生的 16 位输出中的 14 位会被用到。在我们的测试中， CRC16 算法可以很好地将各种不同类型的键平稳地分布到 16384 个槽里面 集群节点属性 每个节点在集群中都有一个独一无二的 ID ， 该 ID 是一个十六进制表示的 160 位随机数， 在节点第一次启动时由 /dev/urandom 生成。 节点会将它的 ID 保存到配置文件， 只要这个配置文件不被删除， 节点就会一直沿用这个 ID 。 节点 ID 用于标识集群中的每个节点。 一个节点可以改变它的 IP 和端口号， 而不改变节点 ID 。 集群可以自动识别出 IP/端口号的变化， 并将这一信息通过 Gossip 协议广播给其他节点知道。 以下是每个节点都有的关联信息， 并且节点会将这些信息发送给其他节点： 节点所使用的 IP 地址和 TCP 端口号。 节点的标志（flags） 。 节点负责处理的哈希槽。 节点最近一次使用集群连接发送 PING 数据包（packet）的时间。 节点最近一次在回复中接收到 PONG 数据包的时间。 集群将该节点标记为下线的时间。 该节点的从节点数量。 如果该节点是从节点的话，那么它会记录主节点的节点 ID 。 如果这是一个主节点的话，那么主节点 ID 这一栏的值为 0000000 。 以上信息的其中一部分可以通过向集群中的任意节点（主节点或者从节点都可以）发送 CLUSTER NODES 命令来获得。 以下是一个向集群中的主节点发送 CLUSTER NODES 命令的例子， 该集群由三个节点组成： $ redis-cli cluster nodes d1861060fe6a534d42d8a19aeb36600e18785e04 :0 myself - 0 1318428930 connected 0-13643886e65cc906bfd9b1f7e7bde468726a052d1dae :6380 master - 1318428930 1318428931 connected 1365-2729 d289c575dcbc4bdd2931585fd4339089e461a27d :6381 master - 1318428931 1318428931 connected 2730-4095 在上面列出的三行信息中， 从左到右的各个域分别是： 节点 ID ， IP 地址和端口号， 标志（flag） ， 最后发送 PING 的时间， 最后接收 PONG 的时间， 连接状态， 节点负责处理的槽。 节点握手（已实现） 节点总是应答（accept）来自集群连接端口的连接请求， 并对接收到的 PING 数据包进行回复， 即使这个 PING 数据包来自不可信的节点。 然而， 除了 PING 之外， 节点会拒绝其他所有并非来自集群节点的数据包。 要让一个节点承认另一个节点同属于一个集群， 只有以下两种方法： 一个节点可以通过向另一个节点发送 MEET 信息， 来强制让接收信息的节点承认发送信息的节点为集群中的一份子。 一个节点仅在管理员显式地向它发送 CLUSTER MEET ip port 命令时， 才会向另一个节点发送 MEET 信息。 另外， 如果一个可信节点向另一个节点传播第三者节点的信息， 那么接收信息的那个节点也会将第三者节点识别为集群中的一份子。 也即是说， 如果 A 认识 B ， B 认识 C ， 并且 B 向 A 传播关于 C 的信息， 那么 A 也会将 C 识别为集群中的一份子， 并尝试连接 C 。 这意味着如果我们将一个/一些新节点添加到一个集群中， 那么这个/这些新节点最终会和集群中已有的其他所有节点连接起来。 这说明只要管理员使用 CLUSTER MEET 命令显式地指定了可信关系， 集群就可以自动发现其他节点。 这种节点识别机制通过防止不同的 Redis 集群因为 IP 地址变更或者其他网络事件的发生而产生意料之外的联合（mix） ， 从而使得集群更具健壮性。 当节点的网络连接断开时， 它会主动连接其他已知的节点。 MOVED 转向 一个 Redis 客户端可以向集群中的任意节点（包括从节点）发送命令请求。 节点会对命令请求进行分析， 如果该命令是集群可以执行的命令， 那么节点会查找这个命令所要处理的键所在的槽。 如果要查找的哈希槽正好就由接收到命令的节点负责处理， 那么节点就直接执行这个命令。 另一方面， 如果所查找的槽不是由该节点处理的话，节点将查看自身内部所保存的哈希槽到节点 ID 的映射记录， 并向客户端回复一个 MOVED 错误。 以下是一个 MOVED 错误的例子： GET x -MOVED 3999 :6381 错误信息包含键 x 所属的哈希槽 3999 ， 以及负责处理这个槽的节点的 IP 和端口号 :6381 。 客户端需要根据这个 IP 和端口号， 向所属的节点重新发送一次 GET 命令请求。 注意， 即使客户端在重新发送 GET 命令之前， 等待了非常久的时间， 以至于集群又再次更改了配置， 使得节点 :6381 已经不再处理槽 3999 ， 那么当客户端向节点 :6381 发送 GET 命令的时候， 节点将再次向客户端返回 MOVED 错误， 指示现在负责处理槽 3999 的节点。 虽然我们用 ID 来标识集群中的节点， 但是为了让客户端的转向操作尽可能地简单， 节点在 MOVED 错误中直接返回目标节点的 IP 和端口号， 而不是目标节点的 ID 。 虽然不是必须的， 但一个客户端应该记录（memorize）下“槽 3999 由节点 :6381 负责处理“这一信息， 这样当熬再次有命令需要对槽 3999 执行时， 客户端就可以加快寻找正确节点的速度。 注意， 当集群处于稳定状态时， 所有客户端最终都会保存有一个哈希槽至节点的映射记录（map of hash slots to nodes） ， 使得集群非常高效： 客户端可以直接向正确的节点发送命令请求， 无须转向、代理或者其他任何可能发生单点故障（single point failure）的实体（entiy） 。 除了 MOVED 转向错误之外， 一个客户端还应该可以处理稍后介绍的 ASK 转向错误。 集群在线重配置（live reconfiguration） Redis 集群支持在集群运行的过程中添加或者移除节点。 实际上， 节点的添加操作和节点的删除操作可以抽象成同一个操作， 那就是， 将哈希槽从一个节点移动到另一个节点： 添加一个新节点到集群， 等于将其他已存在节点的槽移动到一个空白的新节点里面。 从集群中移除一个节点，等于将被移除节点的所有槽移动到集群的其他节点上面去。因此， 实现 Redis 集群在线重配置的核心就是将槽从一个节点移动到另一个节点的能力。 因为一个哈希槽实际上就是一些键的集合， 所以 Redis 集群在重哈希（rehash）时真正要做的， 就是将一些键从一个节点移动到另一个节点。 要理解 Redis 集群如何将槽从一个节点移动到另一个节点， 我们需要对 CLUSTER 命令的各个子命令进行介绍， 这些命理负责管理集群节点的槽转换表（slots translation table） 。 篇三：关于华为二层交换机集群管理配置规范及说明关于华为二层交换机集群管理配置规范及说明 一、组网说明： 榆社县局 S3552G 交换机 E0/1 下挂榆社水利小区 3 号楼 SXXC，3 号楼 SXXC 交换机 E0/2 下挂水利小区 2 号楼S2403H，3 号楼 SXXC 交换机 E0/3 下挂水利小区 1 号楼S2024C。 二、组网图： 三、配置步骤 1、 配置管理设备 （由汇聚层人员来配置） （1）启动设备上的 NDP 和端口 E0/1 日的 NDP 协议：YS_XianJu_S3552G ndp enable YS_XianJu_S3552G interface ethernet 0/1 YS_XianJu_S3552G -Ethernet0/1 ndp enable YS_XianJu_S3552G -Ethernet0/1 interface ethernet 0/2 YS_XianJu_S3552G -Ethernet0/2 ndp enable # 配置 NDP 信息的有效保留时间为 200 秒 YS_XianJu_S3552G ndp timer aging 200 # 配置 NDP 报文发送的时间间隔为 70 秒 YS_XianJu_S3552G ndp timer hello 70 （2）启动设备上的 NTDP 和端口 E0/1 E0/2 上的 NTDP YS_XianJu_S3552G ntdp enable YS_XianJu_S3552G interface ethernet 0/1 YS_XianJu_S3552G -Ethernet0/1 ntdp enable YS_XianJu_S3552G -Ethernet0/1 interface ethernet 0/2 YS_XianJu_S3552G -Ethernet0/2 ntdp enable # 配置拓扑收集范围为 7 跳 YS_XianJu_S3552G ntdp hop 7# 配置被收集设备转发拓扑收集请求的延迟时间为150ms YS_XianJu_S3552G ntdp timer hop-delay 150 # 配置被收集设备的端口转发拓扑收集请求的延迟时间为 15ms YS_XianJu_S3552G ntdp timer port-delay 15 # 配置定时拓扑收集的时间间隔为 3 分钟 YS_XianJu_S3552G ntdp timer 3 (3)配置管理 vlan #创建管理 vlan YS_XianJu_S3552Gvlan 4051 #将管理 vlan4051 作为管理 vlan YS_XianJu_S3552Gmanagement-vlan 4051 #进入以太网端口 E0/19 YS_XianJu_S3552G-Ethernet0/19 description to_ys_shuili_dishui2_caizhen_xiaoqu port link-type trunk undo port trunk permit vlan 1 port trunk permit vlan 45 to 51 3527 4051 （4）启动集群功能 YS_XianJu_S3552G cluster enable # 进入集群视图 YS_XianJu_S3552G cluster YS_XianJu_S3552G -cluster # 配置集群内部使用的 IP 地址池 起始地址为 有 254 个地址 YS_XianJu_S3552G -cluster ip-pool （5） 配置集群名字 建立集群 YS_XianJu_S3552G -cluster build YSYD YSYD_XianJu_S3552G -cluster （6） 将下挂的两个交换机加入到集群中 YSYD_XianJu_S3552G -cluster add-member 1 mac-address 00e0-fc01-0011 YSYD_XianJu_S3552G -cluster add-member 2 mac-address 00e0-fc01-0013 YSYD_XianJu_S3552G -cluster add-member 3 mac-address 00e0-fc01-0011 # 配置成员设备信息的保留时间为 100 秒 YSYD_XianJu_S3552G -cluster holdtime 100 # 配置握手报文定时发送的时间间隔为 10 秒 YSYD_XianJu_S3552G -cluster timer 10 2、配置成员设备（由接入层维护人员来配置） 以榆社水利小区 3 号楼 SXXC 为例 ： # 启动设备上的 NDP 和端口 Ethernet1/1 上的 NDP YS_ShuiLi_3#Lou_SXXC ndp enable YS_ShuiLi_3#Lou_SXXC interface ethernet 1/1 YS_ShuiLi_3#Lou_SXXC -Ethernet1/1 ndp enable # 启动设备上的 NTDP 和端口 Ethernet1/1 上的 NTDPYS_ShuiLi_3#Lou_SXXC ntdp enable YS_ShuiLi_3#Lou_SXXC interface ethernet 1/1 YS_ShuiLi_3#Lou_SXXC -Ethernet1/1 ntdp enable #创建 vlan 4051 创建管理 vlan，根汇聚层交换机管理 vlan 来确定。 YS_ShuiLi_3#Lou_SXXC vlan 4051 #将 vlan4051 作为管理 vlan YS_ShuiLi_3#Lou_SXXC management-vlan 4051 #进入以太网端口 E0/1,透传管理 vlan 405