; 103-corosync-pacemaker-crmsh | Linux运维部落

103-corosync-pacemaker-crmsh

一、概述:

1.1 什么是AIS和OpenAIS?

AIS是应用接口规范,是用来定义应用程序接口(API)的开放性规范的集合,这些应用程序作为中间件为应用服务提供一种开放、高移植性的程序接口。是在实现高可用应用过程中是亟需的。服务可用性论坛(SA Forum)是一个开放性论坛,它开发并发布这些免费规范。使用AIS规范的应用程序接口(API),可以减少应用程序的复杂性和缩短应用程序的开发时间,这些规范的主要目的就是为了提高中间组件可移植性和应用程序的高可用性。

OpenAIS是基于SA Forum 标准的集群框架的应用程序接口规范。OpenAIS提供一种集群模式,这个模式包括集群框架,集群成员管理,通信方式,集群监测等,能够为集群软件或工具提供满足 AIS标准的集群接口,但是它没有集群资源管理功能,不能独立形成一个集群。

1.2 corosync简介

corosync最初只是用来演示OpenAIS集群框架接口规范的一个应用,可以说corosync是OpenAIS的一部分,但后面的发展明显超越了官方最初的设想,越来越多的厂商尝试使用corosync作为集群解决方案。如Redhat的RHCS集群套件就是基于corosync实现。

corosync只提供了 Cluster Messaging Layer(集群信息层)负责集群信息以及心跳信息传递),并没有资源管理功能,资源管理还得依赖于上层的crm(Cluster resource Manager,集群资源管理器),对服务或者资源进行管理.而corosync与pacemaker 是最佳组合.corosync 将底层的集群信息统一管理,并提供API 上上一层的pacemaker 实现资源,服务等统一调度,进行资源/服务管理.

                              

 

1.3 corosync+pacemaker HA 高可用集群架构说明

1.3.1 架构示意图:

                           

         结构说明:

            高可用集群可分为三个层次结构,分别由红色部分的Messaging与Membership层,蓝色部分的Cluster Resource Manager(CRM)层,绿色部分的Local Resource Manager(LRM)与Resource Agent(RA)组成,下面我们就来具体说明(如上图),


 1.位于最底层的是信息和成员关系层(Messaging and Membership),Messaging主要用于节点之间传递心跳信息,也称为心跳层。节点之间传递心跳信息可以通过广播,组播,单播等方式。成员关系(Membership)层,这层最重要的作用是主节点(DC)通过Cluster Consensus Menbership Service(CCM或者CCS)这种服务由Messaging层提供的信息,来产生一个完整的成员关系。这层主要实现承上启下的作用,承上,将下层产生的信息生产成员关系图传递给上层以通知各个节点的工作状态;启下,将上层对于隔离某一设备予以具体实施。

(该层即时使用corosync实现)


2.集群资源管理层(Cluster Resource Manager),真正实现集群服务的层。在该层中每个节点都运行一个集群资源管理器(CRM,cluster Resource Manager),它能为实现高可用提供核心组件,包括资源定义,属性等。在每一个节点上CRM都维护有一个CIB(集群信息库 XML文档)和LRM(本地资源管理器)组件。对于CIB,只有工作在DC(主节点)上的文档是可以修改的,其他CIB都是复制DC上的那个文档而来的。对于LRM,是执行CRM传递过来的在本地执行某个资源的执行和停止的具体执行人。当某个节点发生故障之后,是由DC通过PE(策略引擎)和TE(实施引擎)来决定是否抢夺资源。


3.资源代理层(Resource Agents),集群资源代理(能够管理本节点上的属于集群资源的某一资源的启动,停止和状态信息的脚本),资源代理分为:LSB(/etc/init.d/*),OCF(比LSB更专业,更加通用),Legacy heartbeat(v1版本的资源管理)。


1.4 Cluster Messaging Layer核心组件说明

1.4.1 核心组件示意图:

                                     

  

1.4.2 核心组件说明:

1.ccm组件(Cluster Consensus Menbership Service):作用,承上启下,监听底层接受的心跳信息,当监听不到心跳信息的时候就重新计算整个集群的票数和收敛状态信息,并将结果转递给上层,让上层做出决定采取怎样的措施,ccm还能够生成一个各节点状态的拓扑结构概览图,以本节点做为视角,保证该节点在特殊情况下能够采取对应的动作。


2.crmd组件(Cluster Resource Manager,集群资源管理器,也就是pacemaker):实现资源的分配,资源分配的每个动作都要通过crm来实现,是核心组建,每个节点上的crm都维护一个cib用来定义资源特定的属性,哪些资源定义在同一个节点上。


3.cib组件(集群信息基库,Cluster Infonation Base):是XML格式的配置文件,在内存中的一个XML格式的集群资源的配置文件,主要保存在文件中,工作的时候常驻在内存中并且需要通知给其它节点,只有DC上的cib才能进行修改,其他节点上的cib都是拷贝DC上。配置cib文件的方法有,基于命令行配置和基于前台的图形界面配置。


4.lrmd组件(Local Resource Manager,本地资源管理器):用来获取本地某个资源的状态,并且实现本地资源的管理,如当检测到对方没有心跳信息时,来启动本地的服务进程等。


5.pengine组件:

PE(Policy Engine):策略引擎,来定义资源转移的一整套转移方式,但只是做策略者,并不亲自来参加资源转移的过程,而是让TE来执行自己的策略。

  STONITH(Shoot The Other Node in the Head,”爆头“), 这种方式直接操作电源开关,当一个节点发生故障时,另 一个节点如果能侦测到,就会通过网络发出命令,控制故障节点的电源开关,通过暂时断电,而又上电的方式使故障节点被重启动, 这种方式需要硬件支持。

TE(Transition Engine): 就是来执行PE做出的策略的并且只有DC上才运行PE和TE。


6.stonithd组件

  STONITH应用案例(主从服务器),主服务器在某一端时间由于服务繁忙,没时间响应心跳信息,如果这个时候备用服务器一下子把服务资源抢过去,但是这个时候主服务器还没有宕掉,这样就会导致资源抢占,就这样用户在主从服务器上都能访问,如果仅仅是读操作还没事,要是有写的操作,那就会导致文件系统崩溃,这样一切都玩了,所以在资源抢占的时候,可以采用一定的隔离方法来实现,就是备用服务器抢占资源的时候,直接把主服务器给STONITH,就是我们常说的”爆头 ”。

STONITH有硬件级别如power switch(电源交换机); 软件级别的如 xen/kvm…等,但是不靠谱

1.4 CRM中的几个基本概念

1.4.1 资源粘性:

        资源粘性表示资源是否倾向于留在当前节点,如果为正整数,表示倾向,负数则会离开,-inf表示正无穷,inf表示正无穷。

        (注意: 当正无穷与负无穷相遇做选择时,结果为选择负无穷)

        资源粘滞性相当于其他高可用集群解决方案中的权重,可在服务器宕机时候选择备用服务器替代成为主服务器; 也可以用于定义资源/服务 跟随指定

        的资源或者服务一起启动/停止等功用.

1.4.2 资源类型:

  • primitive(native):基本资源,原始资源
  • group:资源组
  • clone:克隆资源(可同时运行在多个节点上),要先定义为primitive后才能进行clone。主要包含STONITH和集群文件系统(cluster filesystem)
  • master/slave:主从资源,如drdb(下文详细讲解)

1.4.3 RA(Resource Agents)类型:

  • Lsb:linux表中库,一般位于/etc/rc.d/init.d/目录下的支持start|stop|status等参数的服务脚本都是lsb
  • ocf:Open cluster Framework,开放集群架构
  • heartbeat:heartbaet V1版本
  • stonith:专为配置stonith设备而用


1.5 集群类型和模型

  • corosync+pacemaker可实现多种集群模型,包括 Active/Active, Active/Passive, N+1, N+M, N-to-1 and N-to-N。
  • Active/Passive 冗余:

  •  
  • N to N 冗余(多个节点多个服务):

  •  




corosync的程序环境:

配置文件:/etc/corosync/corosync.conf

密钥文件:/etc/corosync/authkey

Unit File:corosync.service

配置文件格式:

totem { }:

interface { }:

totem协议:节点间的通信协议,主要定义通信方式、通信协议版本、加密算法等 ;

interface{}:定义集群心跳信息传递的接口,可以有多组;

 Within the interface sub-directive of totem there are four parameters which are required.  There  is  one  parameter which is optional.

 

 ringnumber: When using the redundant ring protocol, each interface should specify separate ring numbers to uniquely identify to the membership protocol which interface  to  use for which redundant ring. The ringnumber must start at 0.

 

 bindnetaddr:should be an IP address configured on the system, or a network address.

 

 mcastaddr: This is the multicast address used by corosync executive.

 

 mcastport:This specifies the UDP port number.

 

 ttl:This  specifies  the  Time To Live (TTL).

 

 version:This specifies the version of the configuration file. 目前取值仅有2一项可用;

 crypto_hash:This specifies which HMAC authentication should be used to authenticate all messages. Valid values  are  none (no authentication), md5, sha1, sha256, sha384 and sha512.

crypto_cipher:This  specifies  which cipher should be used to encrypt all messages.  Valid values are none (no encryption), aes256, aes192, aes128 and 3des.  Enabling crypto_cipher, requires also enabling of crypto_hash.


配置示例:

totem {

version: 2

crypto_cipher: aes256

crypto_hash: sha1

interface {

ringnumber: 0

bindnetaddr: 10.1.0.0

mcastaddr: 239.255.100.1

mcastport: 5405

ttl: 1

}

}

logging {

fileline: off

to_stderr: no

to_logfile: yes

logfile: /var/log/cluster/corosync.log

to_syslog: no

debug: off

timestamp: on

logger_subsys {

subsys: QUORUM

debug: off

}

}

quorum {

provider: corosync_votequorum

}

nodelist {

node {

ring0_addr: node1.magedu.com

nodeid: 1

}

node {

ring0_addr: node2.magedu.com

nodeid: 2

}

}

生成authkey:

corosync-keygen

启动服务:systemctl start corosync.service

验正服务启动:

(1) 查看日志;

(2) corosync-cmapctl  | grep members 

(3) corosync-cfgtool:管理工具;

-s:显示当前节点各ring相关的信息;

-R:控制所有节点重载配置;

pacemaker:

程序环境:

配置文件:/etc/sysconfig/pacemaker

                                                                #无专门配置文件,需要借助环境文件来完成配置

主程序:/usr/sbin/pacemakerd

Unit File:pacemaker.service

启动服务:

systemctl start pacemaker.service 

监控服务启动是否正常:

# crm_mon 

配置接口(crmsh/pcs)

crmsh:

运行方式:

交互式方式:

crm(live)#

命令方式:

crm COMMAND

获取帮助:ls, help

help [KEYWORD]

COMMAND:

cd             Navigate the level structure

help           Show help (help topics for list of topics)

ls             List levels and commands

quit           Exit the interactive shell

report         Create cluster status report

status         Cluster status

up             Go back to previous level

cib/           CIB shadow management

cibstatus/     CIB status management and editing

 cluster/       Cluster setup and management

 configure/     CIB configuration

 assist/        Configuration assistant

 history/       Cluster history

 ra/            Resource Agents (RA) lists and documentation

 template/      Edit and import a configuration from a template

 corosync/      Corosync management

 node/          Nodes management

 options/       User preferences

 resource/      Resource management

 script/        Cluster script management

 site/          Site support

#注意结尾有 “/”的,代表有子命令  

configure命令:

Finally, there are the cluster properties, resource meta attributes defaults, and operations defaults. All are just a set of attributes. These attributes are managed by the following commands:


– property

– rsc_defaults

– op_defaults

Commands for resources are:


– primitive

– monitor

– group

– clone

– ms/master (master-slave)

There are three types of constraints:


– location

– colocation

– order

设置集群的全局属性:property 

stonith-enabled=true|false

定义一个primitive资源的方法:

primitive <rsc> {[<class>:[<provider>:]]<type>}  [params attr_list] [op op_type [<attribute>=<value>…] …]


op_type :: start | stop | monitor

定义一个组资源的方法:

group <name> <rsc> [<rsc>…]

<rsc>:资源的ID,字符串;

[<class>:[<provider>:]]<type>

定义资源监控:

(1) monitor <rsc>[:<role>] <interval>[:<timeout>]

(2) primitive <rsc> {[<class>:[<provider>:]]<type>}  [params attr_list] [op monitor interval=# timeout=#]

ra:

Commands:

cd             Navigate the level structure

classes        List classes and providers

help           Show help (help topics for list of topics)

info           Show meta data for a RA

list           List RA for a class (and provider)

ls             List levels and commands

providers      Show providers for a RA and a class

quit           Exit the interactive shell

up             Go back to previous level

常用命令:

classes:类别列表

list CLASSES [PROVIDER]:列出指定类型(及提供者)之下的所有可用RA;

info [<class>:[<provider>]:]]<type>:显示指定的RA的详细文档;

资源约束关系的定义:

.资源约束

资源约束则用以指定在哪些群集节点上运行资源,以何种顺序装载资源,以及特定资源依赖于哪些其它资源。

  • Resource Location(资源位置):定义资源可以、不可以或尽可能在哪些节点上运行;

  • Resource Collocation(资源排列):排列约束用以定义集群资源可以或不可以在某个节点上同时运行;

  • Resource Order(资源顺序):顺序约束定义集群资源在节点上启动的顺序;

定义约束时,还需要指定值。资源安按值管理是集群工作方式的重要组成部分。从迁移资源到决定在已降级集群中停止哪些资源的整个过程是通过以某种方式改变资源值来实现的。值按每个资源来计算,资源值为负的任何节点都无法运行该资源。在计算出资源值后,集群选择值最高的节点。

   有两个特殊值:inf(正无穷,表示只要有可能就要)、-inf(负无穷,表示只要有可能就不要)

   定义资源约束时,也可以指定每个约束的值。值较高的约束先应用,值较低的约束后应用。通过使用不同的值为既定资源创建更多位置约束,可指定资源故障转移至的目标节点的顺序。

资源粘性stickiness: 表示资源是否倾向于留在当前节点
>0: 倾向于留在当前节点
<0: 倾向于离开此节点
=0: 由HA来决定去留
INFINITY: 正无穷大

-INFINITY: 负无穷大

3.4.3 资源约束

  • 由此可见,即便集群拥有所有必需资源,但它可能还无法进行正确处理。资源约束则用以指定在哪些群集节点上运行资源,以何种顺序装载资源,以及特定资源依赖于哪些其它资源。pacemaker共给我们提供了三种资源约束方法: 
    1)Resource Location(资源位置):定义资源可以、不可以或尽可能在哪些节点上运行; 
    2)Resource Collocation(资源排列):排列约束用以定义集群资源可以或不可以在某个节点上同时运行; 
    3)Resource Order(资源顺序):顺序约束定义集群资源在节点上启动的顺序;
  • 定义约束时,还需要指定分数。各种分数是集群工作方式的重要组成部分。其实,从迁移资源到决定在已降级集群中停止哪些资源的整个过程是通过以某种方式修改分数来实现的。分数按每个资源来计算,资源分数为负的任何节点都无法运行该资源。在计算出资源分数后,集群选择分数最高的节点。INFINITY(无穷大)目前定义为 1,000,000。加减无穷大遵循以下3个基本规则: 
    1)任何值 + 无穷大 = 无穷大 
    2)任何值 – 无穷大 = -无穷大 
    3)无穷大 – 无穷大 = -无穷大

定义资源约束时,也可以指定每个约束的分数。分数表示指派给此资源约束的值。分数较高的约束先应用,分数较低的约束后应用。通过使用不同的分数为既定资源创建更多位置约束,可以指定资源要故障转移至的目标节点的顺序

位置约束:

                                                            #定义资源对于一个节点的倾向性大小

location <id> rsc  <score>:  <node>

<score>:

#, -#

inf, -inf 

#正无穷inf: 只要对应节点Online,无一定运行在此节点上

                                                                负无穷-inf 则反之
                                                    eg:
                                                        configure> location webip_prefer_node1 webip inf: node1.com
                                                                            #资源webip对节点node1的倾向性为正无穷
                                                         configure> location webip_refuse_node2 webip -inf: node1.com
                                                                            #资源webip对节点node2的倾向性为负无穷,即无论如何都不会在node2
                                                                                运行;
                                                       注意: 资源对节点的选择性,首先受控于default-resource-stickiness和location定义
                                                               
                                                                若location的值一样的大,则倾向于留在当前节点,不切换
                                                                若不一样大,则只要值大的一方处于online状态,资源就会转移过去
                                                                若不一样大,并且当前节点拥有default-resource-stickiness值,则即使location中值较大的节点
                                                                    恢复到online状态,资源也不会转移,会停留在当前节点



property default-resource-stickiness=#

                                                                         #定义资源所在的当前节点对资源的默认粘性大小,此配置只有当前节点才生效,其他节点无效,
                                                                            除非在其他节点也配置此项
                                                                        #即.只要配置此项,并且值最大,资源在此节点时,即使有其他location定义的值更大的节点处于online状态,
                                                                            资源也不会转移
                  
    configure>show xml   #显示xml格式的详细配置信息
 
                                                                    #定义当前节点对资源的默认粘性大小

排列约束:

colocation <id> <score>:  <rsc>  <with-rsc>

#定义资源与资源之间的依赖关系

顺序约束:

order <id> [{kind|<score>}:] first then [symmetrical=<bool>]

         定义服务/资源的启动|关闭顺序

                                                               order webserver_before_webip Mandatory: webserver webip
                                                                 webserver_after_webip:此顺序定义的名称
                                                                Mandatory : 强制使用此顺序
                                                                symmetrical : 对称模式,即先开的后关,先关的后开
                                                                                               默认即为此模式
                                                                webserver webip : webserver先启动,后启动webip ,
                                                                    #注意:  webserver webip 位置顺序决定了启动/关闭顺序,不可随便调整位置

高可用ipvs,可借助于ldirectord实现; 

博客作业:corosync, pacemaker,nfs高可用mariadb;

pcs:node1, node2, node3

 
 

 
 
 
 
 
 

 
 

 
 

 

 

 

 

 
nic: 用于指定网卡接口,如果不指定,则会自动选择一个;

 

 

 

 
在任意节点控制其他节点standby 以及online 

 

 
状态测试:

 
 
在各节点配置httpd,并配置页面文件,使httpd可以正常使用,然后systemctl stop httpd , 
同时还需要 systemctl enable httpd
此时在crm中产看:ra> list systemd 可以查询到支持httpd服务
且:

 
定义httpd资源:

 由此可以使httpd接受集群托管

 

 
查看组资源启动情况:

 #此时集群会自动启用httpd
访问web服务: (此时httpd已经可以正常工作,并接受集群托管)
#当前位于node1

 
当前运行节点执行standby测试:

 #资源向其他节点迁移:(迁移到node2上)

 
再次迁移:
#此时迁移到节点4, node1,node2都执行standby

 
迁移的时候,根据顺序,先停止IP ,再停止服务,并向其他及诶单迁移
资源强制迁移:

 
#注意: 此时如果资源迁移失败,会报错

 
注意: 错误信息即使在服务恢复正常以后,依会存在,此时需要手动清理:

 
 
 
nfs对应的资源类型:

查看filesystem类型的资源定义方式:
ra> info ock:heartbeat:Filesystem

 
添加nfs服务到集群中
#首先需要先配置nfs,并使其正常工作,然后再各节点umount , 并执行systemctl enable nfs-server
然后进入crm ,定义nfs 资源即可

 

 此时就应经将nfs交给集群托管
添加监控:

interval : 监控间隔时间     timeout: 重启超时时间,一旦超过这个时长,服务任然无法启动,则
认为该节点失效,资源会迁移到其他节点
 
测试: 手动killall httpd , 30S后,服务会重启

 30S后服务重启:

 当集群尝试开始第一次尝试重启服务失败,并超过20s后,即认为节点已经失效,
会将服务自动迁移到其他节点;
也可以手动调整配置,而不使用命令:
configure> edit

 
定义资源对于节点的倾向性:
help location

 
定义资源间的粘性:

 
节点对资源的默认粘性:

 

 
资源倾向性整体定义:

node2的资源优先级最高,其次是node1,最后为node4,
当资源运行在node2上,并且node2不可工作时,资源会优先跳转到node1,若node1不可用才跳转到node4 
order中定义了停止服务时候,webip会先停止,再停止webserver服务,  

 双节点模式下,必须添加此项,都则投票时,无法大于半数




三、在CentOS 7.x上配置基于corosync的httpd-Web高可用

3.1前提:

1) 本配置共有三个测试节点,分别node1.com 和 node2.com, node4.com

      对应的IP地址分别为10.1.249.284和10.1.252.218, 10.1.249.70;

2)集群服务为httpd服务;

3)提供web服务的地址为10.1.48.1,即vip;

4)系统为CentOS 7.1 x86_64

5) 各节点名称必须与实际使用的名称一致



当上一次迁移,在对应节点出错时,错误信息会一直存在,此时可以手动清除:

 清理: 使用 resource> clearup source_name (刚执行迁移并且出错的资源名字)

 

3.2准备工作

大致流程: 
    安装corosync , pacemaker , crmsh(需要安装包手动安装,并且依赖另外两个rpm 包,需要一同安装)
    配置corosync, 并使其正常启动
    启动pacemaker 
    使用crm命令进入pacemaker-crmsh 交互式命令行管理接口
    查看集群基本信息,并确保每个节点已经在线
    进入configure 模式, 查看各节点status, show(配置), 测试standy 以及online状态切换
     进入ra模式,定义资源resource , 资源为ip等
     测试资源在各节点上的切换

3.2.1 为了配置一台Linux主机成为HA的节点,通常需要做出如下的准备工作:

1) 所有节点的主机名称和对应的IP地址解析服务可以正常工作,且每个节点的主机名称需要跟”uname -n“命令的结果保持一致;因此,需要保证两个节点上的/etc/hosts文件均为下面的内容:

10.1.249.284  node1.com node1

10.1.252.218   node2.com node2

10.1.249.70    node4.com node4


ansible all -m shell -a ‘echo -e “10.1.249.284  node1.com node1\n10.1.252.218   node2.com node2\n10.1.249.70    node4.com node4\n” >> /etc/hosts’


为了使得重新启动系统后仍能保持如上的主机名称,还分别需要在各节点执行类似如下的命令:

Node1:

# hostnamectl set-hostname node1.com

# hostname node1.com

Node2:

# hostnamectl set-hostname node2.com

# hostname node2.com

Node4:

# hostnamectl set-hostname node4.com

# hostname node4.com

        

2)若需要各节点基于密钥进行ssh通信,这可以通过类似如下的命令实现:

Node1:

# ssh-keygen -t rsa -P ”

# ssh-copy-id -i ~/.ssh/id_rsa.pub root@node2.com

Node2:

# ssh-keygen -t rsa -P ”

# ssh-copy-id -i ~/.ssh/id_rsa.pub root@node1.magedu.com


   也可以使用ansible 批量对指定主机传输公钥:

        (需要先将主机写入/etc/ansible/hosts中)

        ssh-keygen -t rsa -P ”

        ansible all -m authorized_key –a “user=root key='{{ lookup(‘file’, ‘/root/.ssh/id_rsa.pub’) }}’ 

               path=/root/.ssh/authorized_keys manage_dir=no” –ask-pass -c paramiko

#注意: 密钥文件权限必须为600或者400


3) 多节点时间同步

    #在集群系统中,各节点必须进行时间同步,否则会出错

        同步命令:

            ntpdate time_server_ip

        ansible all -m shell -a “ntpdate 10.1.0.1”

            

           4)安装:各节点安装相关的程序包,corosync/pacemaker httpd 等

         ansible all -m shell -a “yum install corosync pacemaker httpd -y”

                  
                   #此处还需要为httpd 创建虚拟主机,并使httpd正常工作,
                    且需要禁止httpd 自动启动, 交给集群托管.

                   ansible all -m shell -a “systemctl disable httpd   

            
            5)   利用corosync-keygen 生成通信秘钥文件:
                    直接运行corosync-keygen即可
                      注意: 密钥生成需要随机数,若随机数不够,需要多按键盘与鼠标,已供生成随机数    
                       
                       
               # 生成密钥以后,需要将其复制到其他节点的/etc/corosync/下 
            6) 配置 corosync 配置文件:
                  默认corosync配置文件只存在示例文件,因此需要复制示例文件
                       cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf
                        
=====================================================================================================================
pcs 的使用比较繁琐,因此可以忽略不看,视频尾部有关于pcs启动集群的简单讲解,其他资源定义较为繁琐,无需再做了解
            

来自为知笔记(Wiz)

原创文章,作者:ldt195175108,如若转载,请注明出处:/60910

联系我们

400-080-6560

在线咨询:点击这里给我发消息

邮件:1660809109@qq.com

工作时间:周一至周五,9:30-18:30,节假日同时也值班

友情链接:万达娱乐平台  万达直属  guoqibee.com  万达娱乐招商QQ  万达娱乐招商  万达招商QQ  万达娱乐主管QQ  万达开户  万达娱乐直属  万达招商QQ