一种适用于sap与b2b系统的数据传输方法
技术领域：
：1.本发明属于数字通信
技术领域：
：，具体涉及为一种适用于sap与b2b系统的数据传输方法。
背景技术：
：：2.b2b(businesstobusiness),商家(泛指企业)对商家的电子商务，是指进行电子商务交易的供需双方都是商家(或企业、公司)，他们使用了internet的技术或各种商务网络平台，完成商务交易的过程。3.sap(systemsapplicationsandproductsindataprocessing)是一款用于企业资源计划管理的软件，可使用分布式的架构。4.针对sap与b2b系统之间的数据传输，由于服务器性能和地域的限制，通常一个公司会把应用分布在多台机器上，但是分开以后，就会有几台、几十台的服务器。如果企业购置多台服务器，甚至演变成为一个具有多台服务器的数据中心，而且服务器的数量会直接影响这个数据中心的业务处理能力。除了高额的初期建设成本之外，计算机的运营支出中花费在电费上的金钱要比投资成本高得多，再加上计算机和网络的维护支出，这些总的费用是中小型企业难以承担的，于是云计算的概念便应运而生了。5.云计算的发展，为分布式的架构的大量数据资料的实时传输提供了潜在的解决方案，sap与b2b系统的数据传输可以转向应用云计算。云计算（cloudcomputing）是分布式计算的一种，指的是通过网络“云”将巨大的数据计算处理程序分解成无数个小程序，然后，通过多部服务器组成的系统进行处理和分析这些小程序得到结果并返回给用户。6.当面临不同系统之间大量数据的实时传输的难题时，负载平衡便成了云计算的关注重点之一。由于云端通常有多台服务器集结而成为一个服务器集合，并通过负载平衡将外部的请求平均地分配到集合中的特定服务器上，在由该服务器独立地对外回应连入请求，从而达到分散外部请求流量的效果。但是，每台服务器的处理能力都是不同的，平均分配的请求的方式并无法做到服务器资源的有效利用。7.传统的解决方案是在是用户端在第一次发送连线请求的时候，将封包导向至openflow控制器，由控制器判断当前最适合的服务器信息，并新增一条能够匹配该条连线信息与修改封包标头内容的规则，让封包可以顺利导向到内部服务器位址至openflow交换机中，从而完成负载平衡的系统。8.然而，在现实生活中的资料中心环境下，openflow控制器可能会同时需要处理好几万条的连线请求，对于这样的系统设计，可能会造成openflow控制器的处理瓶颈。此外，当用户端连线请求被导向至内部服务器时，会有一条规则来处理该条连线之封包，待openflow交换机收到来自服务器的回复时，也需要一条规则来修改封包标头，才能正确地回到相对应的用户端，因此这样的做法也可能导致同时有大量的规则被新增到openflow交换机内，如果超出openflow交换机所能够容纳的最大值时，就会造成用户端连线请求失败。9.公开号为cn105120008a的中国专利公开了一种基于分层的分布式云计算中心负载平衡方法，其通过服务器节点集群的比例是否超过阈值来判断服务器是否过载。而由于每个服务器的体质并不相同，服务器节点集群的比例也是由管理员自行定义的，并无法真正地反映出实际服务器的负载能力。10.公开号为cn106850803a的中国专利公开了一种基于sdn的加权轮询系统及算法，利用用户端在第一次发送连线请求时，将封包导向控制器，由控制器判断当前最合适的服务器，并新增一条能够匹配该条连线信息且修改封包标头内容的规则，让封包可以顺利导向内部的服务器地址到交换机中，从而完成负载的调整。然而，在实际的运作中，控制器可能会同时需要处理好几万条的连线请求，可能会造成控制器的处理瓶颈。此外，当用户端连线请求被导向内部服务器时，会有一条规则来处理该条连线的封包，待交换机收到来自服务器的回复时，也需要一条规则来修改封包标头，才能正确的回到相对应的用户端，因此，传统的做法可能导致同时由大量的规则被新增到交换机中，如果超出交换机的最大容纳值时，就会造成用户端的连线失败。技术实现要素：11.针对上述提到的缺陷和不足，而提供一种适用于sap与b2b系统的数据传输方法。12.为了实现上述目的，本发明采取的技术方案如下。13.一种适用于sap与b2b系统的数据传输方法，包括以下步骤：步骤s1，建立云计算系统；该云计算系统，包括用户端、互联网、和云计算中心；所述用户端通过互联网与云计算中心建立通信连接；所述云计算中心包括1个交换机、1个控制器和至少2个服务器；所述交换机通信连接有用户端和服务器，形成数据传输网络；所述交换机和控制器通信连接，形成openflow网络；所述控制器通信连接有所有的服务器，形成内部管理网络；所述交换机通信连接有用户端、控制器和服务器；所述交换机，为openflow交换机，其是云计算中心的单一对外连线的服务窗口，用以传送数据封包，向用户端提供服务器上的数据资源；所述交换机，设置有流表；所述控制器，为openflow控制器，采用软件定义网络技术，对openflow交换机进行配置，控制数据封包的流向，并监控服务器的状态；步骤s2，预先设定好交换机中流表的配对字段：流表包含有以下字段：配对字段：对封包内的字段进行配对，通过预先设定源ip地址，确定流规则，用以过滤用户端ip地址；计数器：用以计算封包数量和封包大小的总和；旗标：用来指定流规则的行为；步骤s3，控制器定期向交换机查询并取得流表中计数器的字节计数值，然后通过加权负载平衡机制得到的结果，改写封包目的服务器的地址信息，重新导向用户端发送的流量到地址信息所对应的后端服务器；步骤s4，用户端向交换机发送arp请求封包，以取得各自网域的预设闸道的mac地址；步骤s5，流量导向：用户端在取得预设闸道的mac地址后，发出http请求封包至交换机；交换机根据流表中的规则对封包进行比对；交换机，先查询自身内部流表中的流规则是否匹配用户端ip地址，再根据匹配后的结果将用户端的数据封包发送给后端的服务器。14.进一步，所述步骤s3，包括以下步骤：步骤s301，赋予每个服务器一个初始的权重值wi，并统计所有服务器权重值之和wt；步骤s302，取得步骤s2中交换机内每条流规则预先设定的计数器的字节计数值pi，并统计所有流规则中的字节计数值之和pt；初始时，将所有字节计数值设定为1；步骤s303，将字节计数值乘以每个服务器的权重值比例，得到每个服务器的负载值li；步骤s304，在执行第一次初始化的负载平衡计算之后，对权重值进行调整，收集每个服务器的cpu使用率ic和内存占用率im，将cpu使用率ic和内存占用率im相加并减半之后得到占用率，然后用100%减去占用率得到当前服务器的可用率ii；然后计算所有服务器的可用率之和it；将当前服务器的可用率ii除以所有服务器的可用率之和it，得到商数乘以100，四舍五入取整后得到每个服务器的权重值wi；然后根据步骤s303，重新计算每个服务器的负载值li，控制器修改交换机中用以匹配用户端ip地址的流规则，重新导向用户端发送的流量到负载值li有盈余的后端服务器。15.进一步，所述步骤s5中，当交换机将流量导向新的服务器时，执行封包追踪机制：控制器对用户端发送的封包进行解析，核查封包中的旗标是否有被设置：当旗标被设置，表示该条封包属于新连线的封包，然后控制器解析该封包的五元素并查询先前的记录中是否有相同的记录信息：如果有记录，则将此封包传送至新的服务器；如果没有记录，则控制器用哈希函数对封包的五元素进行存储，作为下一次连线的判别，接着将此封包传送至新的服务器；五元素由源ip、源端口、目标ip、目标端口、4层通信协议5个字段组成；当旗标没有被设置，控制器解析该封包的五元素，查询先前的记录中是否有相同的记录信息；如果有记录则表示该条封包是属于新连线的封包，将此封包传送至新的服务器；否则，该条封包是属于旧的封包，送往旧的服务器。16.进一步，所述步骤s5中，确定接收的服务器之后，交换机将该封包送往群组规则中，由该群组规则修改封包内容，修改目的端ip为服务器的ip，修改目的端mac为服务器的mac地址，并将封包传送至服务器；服务器向交换机回传http回复封包，此时，封包中的目的端mac地址为预设闸道的mac地址，因此，匹配到该封包的规则会将该封包传送至其它流表并修改目的端mac地址为用户端的mac地址，以确保服务器发送的http回复封包能狗准确的送回到用户端。17.本方案预先通过ip分群的方法，将用户端的ip做了分群，并匹配流规则到交换机中。让每条来自不同的ip的用户端在第一次发送http请求的时，不需要经由交换机传送至控制器去判别并新增流规则，因此，可以大幅的减少用户端请求的响应时间。18.本方案设置有负载平衡机制，将用户端的请求动态的分配到服务器。同时，封包追踪机制，在维持封包连线传输的同时，不会造成用户端与服务器之间的连线中断。table）。流表用以告知交换机如何处理每一个进入到交换机的数据封包，每张流表包含多条流规则(flowentries），用来执行封包查询和封包转传的动作。31.所述控制器，为openflow控制器，采用软件定义网络技术，对openflow交换机进行配置，控制数据封包的流向，并监控服务器的状态。具体的，所述控制器，根据openflow协议，对交换机进行新增、修改或者删除流表内的流规则(flowentries）。32.作为优选，所述交换机，采用日本ntt公司销售的lagopusv交换机，其是开放原始码的软件交换机，具有高性能的数据封包处理能力，对openflow协议的支持程度较高。33.所述控制器，采用日本ntt公司销售的ryu控制器，其是一个开放原始码的openflow控制器，对openflow协议的支持较为完整。34.预先设定一组虚拟ip地址作为云计算中心对外入口的连接，该虚拟ip地址为172.16.1.253/24。用户端通过该虚拟ip地址连接到云计算中心以存取数据。35.云计算中心内部设置有2个服务器，其ip地址分别为172.16.2.221/24和172.16.2.222/24。36.步骤s2，预先设定好交换机中流表的配对字段。37.表1为流表的字段表。配对字段优先权字段计数器指令集计时器小型存储信息旗标38.流表（flowtable）包含有以下字段：配对字段（matchfields）：对封包内的字段进行配对，通过预先设定源ip地址，确定流规则，用以过滤用户端ip地址。39.优先权字段（priority）：用来表示流规则在流表内被配对的顺序。40.计数器（counters）：用以计算封包数量和封包大小的总和。41.指令集（instructions）：定义封包成功配对该条流规则之后所要执行的动作。42.计时器（timeout）：记录该流规则在交换机流表中的有效存活时间。当流规则超过有效存活时间，交换机删除该条流规则，并通知控制器。43.小型存储信息（cookie）：用来记录控制器用过滤流的修改、删除的信息。44.旗标（flag）：用来指定流规则的行为。45.图2为用户端ip地址的匹配示意图。图中，在流表的配对字段中预先设定用以过滤用户端ip地址的配对字段，例如：ip_src=10.1.0.0/16，然后进行ip地址的匹配。46.在传统交换机内部的mac地址对应表中，同一条流规则只能匹配一个mac地址。而在本方案中，通过将用户端ip地址进行分群的做法，能够直接匹配整个网络的ip地址，能大量减少所需要被定义的流规则和记忆空间，减少新增到交换机的流规则数量。47.步骤s3，控制器定期（例如30秒）向交换机查询并取得流表中计数器的字节计数值（bytecounter），然后通过加权负载平衡机制得到的结果，改写封包目的服务器的地址信息，重新导向用户端发送的流量到地址信息所对应的后端服务器。48.由于本方案采用软件定义网络分离控制平面和资料平面，因此，对于交换机来说，并没有执行运算和决策的能力，因此，预设控制器每30秒定期执行演算，从而达到动态调整负载量的效果。49.步骤s301，赋予每个服务器一个初始的权重值wi，并统计所有服务器权重值之和wt，即，式中n表示服务器的数量。50.步骤s302，取得步骤s2中交换机内每条流规则预先设定的计数器的字节计数值pi，并统计所有流规则中的字节计数值之和pt，即，式中n表示流规则的数量。51.初始时，由于没有数据封包进入到交换机，因此，字节计数值均为0。预设时，将所有字节计数值设定为1，以方便后续计算。52.步骤s303，将字节计数值乘以每个服务器的权重值比例，得到每个服务器的负载值li。即。53.如图3所示，初始化时，在交换机中设定30个流规则，并新增3台服务器，同时给予每个服务器预设值为10的权重值。在首次负载平衡执行完毕之后，由于预设的字节计数值为1，因此，计算后的所有流规则中的字节计数值之和pt为30，且每个服务器被平均分配到10条负载量。一段时候之后，假设变更了权重值，第1个服务器的权重值为3，第2个服务器的权重值为3，第3个服务器的权重值为4，进行下一次的负载平衡计算后，得到所有流规则中的字节计数值之和pt为300，则可以计算出：第1个服务器的负载值为90，第2个服务器的负载值为90，第3个服务器的负载值为120。因此，第1个服务器和第2个服务器均释放出一个ip负载量（即10），第3个服务器获得两个ip负载量（即20）。54.步骤s304，在执行第一次初始化的负载平衡计算之后，对权重值进行调整，收集每个服务器的cpu使用率ic和内存占用率im，将cpu使用率ic和内存占用率im相加并减半之后得到占用率，然后用100%减去占用率得到当前服务器的可用率ii，即ii=100%-0.5（ic im）；然后计算所有服务器的可用率之和it，即；将当前服务器的可用率ii除以所有服务器的可用率之和it，得到商数乘以100，四舍五入取整后得到每个服务器的权重值wi，即；然后根据步骤s303，重新计算每个服务器的负载值li，控制器修改交换机中用以匹配用户端ip地址的流规则，重新导向用户端发送的流量到负载值li有盈余的后端服务器。55.图5为用户端发送连线请求流程图。根据图5解释步骤s4和步骤s5。56.步骤s4，用户端向交换机发送arp请求封包，以取得各自网域的预设闸道的mac地址。用户端向交换机发送arp请求封包，在arp请求封包进入到交换机时，交换机根据流表中的规则对封包进行比对；由于交换机中并没有设置arp请求封包的规则，因此，该arp请求封包没有在流表中发现能与之匹配的规则，则交换机将该arp请求封包封装成packet-in封包发送到控制器处理。57.控制器接收到packet-in封包时，根据用户端发送的封包内容，查询相对应的预设闸道的mac地址，并将预设闸道的mac地址加入到arp回复封包中，再以packet-out的方式将arp回复封包通过交换机回传给用户端。58.步骤s5，流量导向和封包追踪机制：用户端在取得预设闸道的mac地址后，发出http请求封包至交换机；交换机根据流表中的规则对封包进行比对；交换机，先查询自身内部流表中的流规则是否匹配用户端ip地址，再根据匹配后的结果将用户端的数据封包发送给后端的服务器。59.当交换机将流量导向新的服务器时，用户端有可能仍然与旧的服务器进行数据传输，此时，有可能造成用户端连线的终端。因此，需要执行封包追踪机制，以防止上述行为的发生。60.图4是执行封包追踪机制的流程图。控制器对用户端发送的封包进行解析，核查封包中的旗标（flag）是否有被设置：当旗标被设置，表示该条封包属于新连线的封包，然后控制器解析该封包的五元素（5-tuple）并查询先前的记录中是否有相同的记录信息：如果有记录，则将此封包传送至新的服务器；如果没有记录，则控制器用哈希函数对封包的五元素进行存储，作为下一次连线的判别，接着将此封包传送至新的服务器。61.五元素由源ip(sourceip)、源端口(sourceport)、目标ip(destinationip)、目标端口(destinationport)、4层通信协议(thelayer4protocol)5个字段组成。62.当旗标没有被设置，控制器解析该封包的五元素（5-tuple），查询先前的记录中是否有相同的记录信息；如果有记录则表示该条封包是属于新连线的封包，将此封包传送至新的服务器；否则，该条封包是属于旧的封包，送往旧的服务器。63.确定接收的服务器之后，交换机将该封包送往群组规则中，由该群组规则修改封包内容，修改目的端ip为服务器的ip，修改目的端mac为服务器的mac地址，并将封包传送至服务器。64.服务器向交换机回传http回复封包，此时，封包中的目的端mac地址为预设闸道的mac地址，因此，匹配到该封包的规则会将该封包传送至其它流表并修改目的端mac地址为用户端的mac地址，以确保服务器发送的http回复封包能狗准确的送回到用户端。65.设定100位用户向系统发送http请求，连线1分钟并记录观察http请求回应时间，实验结果如表2。66.表2为http请求回应时间统计表（单位微妙）。67.轮询演算方案和随机演算方案在前30秒发送的http请求过程中，需要花费的时间，是本方案的2~3倍，这是由于用户端在第一次发送http请求的时候，交换机内并足以没有匹配该ip地址的规则，所以交换机将该http请求封包传送至控制器，由控制器决定送往哪一个服务器，同时，新增加流规则到交换机，以避免下次同一个ip地址发送的http请求被传送至控制器。68.本方案维持在10000微妙的响应时间，这是由于本方案预先通过ip分群的方法，将用户端的ip做了分群，并匹配流规则到交换机中。让每条来自不同的ip的用户端在第一次发送http请求的时，不需要经由交换机传送至控制器去判别并新增流规则，因此，可以大幅的减少用户端请求的响应时间。69.本方案设置有负载平衡机制，将用户端的请求动态的分配到服务器。同时，封包追踪机制，在维持封包连线传输的同时，不会造成用户端与服务器之间的连线终端。70.传统的方案中，利用用户端在第一次发送连线请求时，将封包导向控制器，由控制器判断当前最合适的服务器，并新增一条能够匹配该条连线信息且修改封包标头内容的规则，让封包可以顺利导向内部的服务器地址到交换机中，从而完成负载的调整。然而，在实际的运作中，控制器可能会同时需要处理好几万条的连线请求，可能会造成控制器的处理瓶颈。此外，当用户端连线请求被导向内部服务器时，会有一条规则来处理该条连线的封包，待交换机收到来自服务器的回复时，也需要一条规则来修改封包标头，才能正确的回到相对应的用户端，因此，传统的做法可能导致同时由大量的规则被新增到交换机中，如果超出交换机的最大容纳值时，就会造成用户端的连线失败。71.本方案，交换机匹配用户端的来源段ip地址，在根据匹配后的结果将用户连线请求送往后端的服务器，最后由相应的服务器来回应网页内容，从而到达ip分群的目的。传统的mac地址对应表，同一条规则只能匹配一个mac地址。而ip分群的方法，能够直接匹配整个网段的ip地址，从而大量地减少所需要被定义的规则与存储空间，大幅度地较少新增到交换机的流规则数量。72.传统的方案，如果赋予每台服务器一个权重值，作为控制器分配流量负载平衡的决策，而当该权重值是管理者自行定义时，就无法真正的反映出服务器的实际负载能力。73.本方案，取得各个服务器当前的负载状态，让控制器能够评估并计算出最佳的流量分配，以此来实现负载平衡。74.可以理解的是，对本领域普通技术人员来说，可以根据本发明的技术方案及其发明构思加以等同替换或改变，而所有这些改变或替换都应属于本发明所附的权利要求的保护范围。当前第1页12当前第1页12
技术领域：
：1.本发明属于数字通信
技术领域：
：，具体涉及为一种适用于sap与b2b系统的数据传输方法。
背景技术：
：：2.b2b(businesstobusiness),商家(泛指企业)对商家的电子商务，是指进行电子商务交易的供需双方都是商家(或企业、公司)，他们使用了internet的技术或各种商务网络平台，完成商务交易的过程。3.sap(systemsapplicationsandproductsindataprocessing)是一款用于企业资源计划管理的软件，可使用分布式的架构。4.针对sap与b2b系统之间的数据传输，由于服务器性能和地域的限制，通常一个公司会把应用分布在多台机器上，但是分开以后，就会有几台、几十台的服务器。如果企业购置多台服务器，甚至演变成为一个具有多台服务器的数据中心，而且服务器的数量会直接影响这个数据中心的业务处理能力。除了高额的初期建设成本之外，计算机的运营支出中花费在电费上的金钱要比投资成本高得多，再加上计算机和网络的维护支出，这些总的费用是中小型企业难以承担的，于是云计算的概念便应运而生了。5.云计算的发展，为分布式的架构的大量数据资料的实时传输提供了潜在的解决方案，sap与b2b系统的数据传输可以转向应用云计算。云计算（cloudcomputing）是分布式计算的一种，指的是通过网络“云”将巨大的数据计算处理程序分解成无数个小程序，然后，通过多部服务器组成的系统进行处理和分析这些小程序得到结果并返回给用户。6.当面临不同系统之间大量数据的实时传输的难题时，负载平衡便成了云计算的关注重点之一。由于云端通常有多台服务器集结而成为一个服务器集合，并通过负载平衡将外部的请求平均地分配到集合中的特定服务器上，在由该服务器独立地对外回应连入请求，从而达到分散外部请求流量的效果。但是，每台服务器的处理能力都是不同的，平均分配的请求的方式并无法做到服务器资源的有效利用。7.传统的解决方案是在是用户端在第一次发送连线请求的时候，将封包导向至openflow控制器，由控制器判断当前最适合的服务器信息，并新增一条能够匹配该条连线信息与修改封包标头内容的规则，让封包可以顺利导向到内部服务器位址至openflow交换机中，从而完成负载平衡的系统。8.然而，在现实生活中的资料中心环境下，openflow控制器可能会同时需要处理好几万条的连线请求，对于这样的系统设计，可能会造成openflow控制器的处理瓶颈。此外，当用户端连线请求被导向至内部服务器时，会有一条规则来处理该条连线之封包，待openflow交换机收到来自服务器的回复时，也需要一条规则来修改封包标头，才能正确地回到相对应的用户端，因此这样的做法也可能导致同时有大量的规则被新增到openflow交换机内，如果超出openflow交换机所能够容纳的最大值时，就会造成用户端连线请求失败。9.公开号为cn105120008a的中国专利公开了一种基于分层的分布式云计算中心负载平衡方法，其通过服务器节点集群的比例是否超过阈值来判断服务器是否过载。而由于每个服务器的体质并不相同，服务器节点集群的比例也是由管理员自行定义的，并无法真正地反映出实际服务器的负载能力。10.公开号为cn106850803a的中国专利公开了一种基于sdn的加权轮询系统及算法，利用用户端在第一次发送连线请求时，将封包导向控制器，由控制器判断当前最合适的服务器，并新增一条能够匹配该条连线信息且修改封包标头内容的规则，让封包可以顺利导向内部的服务器地址到交换机中，从而完成负载的调整。然而，在实际的运作中，控制器可能会同时需要处理好几万条的连线请求，可能会造成控制器的处理瓶颈。此外，当用户端连线请求被导向内部服务器时，会有一条规则来处理该条连线的封包，待交换机收到来自服务器的回复时，也需要一条规则来修改封包标头，才能正确的回到相对应的用户端，因此，传统的做法可能导致同时由大量的规则被新增到交换机中，如果超出交换机的最大容纳值时，就会造成用户端的连线失败。技术实现要素：11.针对上述提到的缺陷和不足，而提供一种适用于sap与b2b系统的数据传输方法。12.为了实现上述目的，本发明采取的技术方案如下。13.一种适用于sap与b2b系统的数据传输方法，包括以下步骤：步骤s1，建立云计算系统；该云计算系统，包括用户端、互联网、和云计算中心；所述用户端通过互联网与云计算中心建立通信连接；所述云计算中心包括1个交换机、1个控制器和至少2个服务器；所述交换机通信连接有用户端和服务器，形成数据传输网络；所述交换机和控制器通信连接，形成openflow网络；所述控制器通信连接有所有的服务器，形成内部管理网络；所述交换机通信连接有用户端、控制器和服务器；所述交换机，为openflow交换机，其是云计算中心的单一对外连线的服务窗口，用以传送数据封包，向用户端提供服务器上的数据资源；所述交换机，设置有流表；所述控制器，为openflow控制器，采用软件定义网络技术，对openflow交换机进行配置，控制数据封包的流向，并监控服务器的状态；步骤s2，预先设定好交换机中流表的配对字段：流表包含有以下字段：配对字段：对封包内的字段进行配对，通过预先设定源ip地址，确定流规则，用以过滤用户端ip地址；计数器：用以计算封包数量和封包大小的总和；旗标：用来指定流规则的行为；步骤s3，控制器定期向交换机查询并取得流表中计数器的字节计数值，然后通过加权负载平衡机制得到的结果，改写封包目的服务器的地址信息，重新导向用户端发送的流量到地址信息所对应的后端服务器；步骤s4，用户端向交换机发送arp请求封包，以取得各自网域的预设闸道的mac地址；步骤s5，流量导向：用户端在取得预设闸道的mac地址后，发出http请求封包至交换机；交换机根据流表中的规则对封包进行比对；交换机，先查询自身内部流表中的流规则是否匹配用户端ip地址，再根据匹配后的结果将用户端的数据封包发送给后端的服务器。14.进一步，所述步骤s3，包括以下步骤：步骤s301，赋予每个服务器一个初始的权重值wi，并统计所有服务器权重值之和wt；步骤s302，取得步骤s2中交换机内每条流规则预先设定的计数器的字节计数值pi，并统计所有流规则中的字节计数值之和pt；初始时，将所有字节计数值设定为1；步骤s303，将字节计数值乘以每个服务器的权重值比例，得到每个服务器的负载值li；步骤s304，在执行第一次初始化的负载平衡计算之后，对权重值进行调整，收集每个服务器的cpu使用率ic和内存占用率im，将cpu使用率ic和内存占用率im相加并减半之后得到占用率，然后用100%减去占用率得到当前服务器的可用率ii；然后计算所有服务器的可用率之和it；将当前服务器的可用率ii除以所有服务器的可用率之和it，得到商数乘以100，四舍五入取整后得到每个服务器的权重值wi；然后根据步骤s303，重新计算每个服务器的负载值li，控制器修改交换机中用以匹配用户端ip地址的流规则，重新导向用户端发送的流量到负载值li有盈余的后端服务器。15.进一步，所述步骤s5中，当交换机将流量导向新的服务器时，执行封包追踪机制：控制器对用户端发送的封包进行解析，核查封包中的旗标是否有被设置：当旗标被设置，表示该条封包属于新连线的封包，然后控制器解析该封包的五元素并查询先前的记录中是否有相同的记录信息：如果有记录，则将此封包传送至新的服务器；如果没有记录，则控制器用哈希函数对封包的五元素进行存储，作为下一次连线的判别，接着将此封包传送至新的服务器；五元素由源ip、源端口、目标ip、目标端口、4层通信协议5个字段组成；当旗标没有被设置，控制器解析该封包的五元素，查询先前的记录中是否有相同的记录信息；如果有记录则表示该条封包是属于新连线的封包，将此封包传送至新的服务器；否则，该条封包是属于旧的封包，送往旧的服务器。16.进一步，所述步骤s5中，确定接收的服务器之后，交换机将该封包送往群组规则中，由该群组规则修改封包内容，修改目的端ip为服务器的ip，修改目的端mac为服务器的mac地址，并将封包传送至服务器；服务器向交换机回传http回复封包，此时，封包中的目的端mac地址为预设闸道的mac地址，因此，匹配到该封包的规则会将该封包传送至其它流表并修改目的端mac地址为用户端的mac地址，以确保服务器发送的http回复封包能狗准确的送回到用户端。17.本方案预先通过ip分群的方法，将用户端的ip做了分群，并匹配流规则到交换机中。让每条来自不同的ip的用户端在第一次发送http请求的时，不需要经由交换机传送至控制器去判别并新增流规则，因此，可以大幅的减少用户端请求的响应时间。18.本方案设置有负载平衡机制，将用户端的请求动态的分配到服务器。同时，封包追踪机制，在维持封包连线传输的同时，不会造成用户端与服务器之间的连线中断。table）。流表用以告知交换机如何处理每一个进入到交换机的数据封包，每张流表包含多条流规则(flowentries），用来执行封包查询和封包转传的动作。31.所述控制器，为openflow控制器，采用软件定义网络技术，对openflow交换机进行配置，控制数据封包的流向，并监控服务器的状态。具体的，所述控制器，根据openflow协议，对交换机进行新增、修改或者删除流表内的流规则(flowentries）。32.作为优选，所述交换机，采用日本ntt公司销售的lagopusv交换机，其是开放原始码的软件交换机，具有高性能的数据封包处理能力，对openflow协议的支持程度较高。33.所述控制器，采用日本ntt公司销售的ryu控制器，其是一个开放原始码的openflow控制器，对openflow协议的支持较为完整。34.预先设定一组虚拟ip地址作为云计算中心对外入口的连接，该虚拟ip地址为172.16.1.253/24。用户端通过该虚拟ip地址连接到云计算中心以存取数据。35.云计算中心内部设置有2个服务器，其ip地址分别为172.16.2.221/24和172.16.2.222/24。36.步骤s2，预先设定好交换机中流表的配对字段。37.表1为流表的字段表。配对字段优先权字段计数器指令集计时器小型存储信息旗标38.流表（flowtable）包含有以下字段：配对字段（matchfields）：对封包内的字段进行配对，通过预先设定源ip地址，确定流规则，用以过滤用户端ip地址。39.优先权字段（priority）：用来表示流规则在流表内被配对的顺序。40.计数器（counters）：用以计算封包数量和封包大小的总和。41.指令集（instructions）：定义封包成功配对该条流规则之后所要执行的动作。42.计时器（timeout）：记录该流规则在交换机流表中的有效存活时间。当流规则超过有效存活时间，交换机删除该条流规则，并通知控制器。43.小型存储信息（cookie）：用来记录控制器用过滤流的修改、删除的信息。44.旗标（flag）：用来指定流规则的行为。45.图2为用户端ip地址的匹配示意图。图中，在流表的配对字段中预先设定用以过滤用户端ip地址的配对字段，例如：ip_src=10.1.0.0/16，然后进行ip地址的匹配。46.在传统交换机内部的mac地址对应表中，同一条流规则只能匹配一个mac地址。而在本方案中，通过将用户端ip地址进行分群的做法，能够直接匹配整个网络的ip地址，能大量减少所需要被定义的流规则和记忆空间，减少新增到交换机的流规则数量。47.步骤s3，控制器定期（例如30秒）向交换机查询并取得流表中计数器的字节计数值（bytecounter），然后通过加权负载平衡机制得到的结果，改写封包目的服务器的地址信息，重新导向用户端发送的流量到地址信息所对应的后端服务器。48.由于本方案采用软件定义网络分离控制平面和资料平面，因此，对于交换机来说，并没有执行运算和决策的能力，因此，预设控制器每30秒定期执行演算，从而达到动态调整负载量的效果。49.步骤s301，赋予每个服务器一个初始的权重值wi，并统计所有服务器权重值之和wt，即，式中n表示服务器的数量。50.步骤s302，取得步骤s2中交换机内每条流规则预先设定的计数器的字节计数值pi，并统计所有流规则中的字节计数值之和pt，即，式中n表示流规则的数量。51.初始时，由于没有数据封包进入到交换机，因此，字节计数值均为0。预设时，将所有字节计数值设定为1，以方便后续计算。52.步骤s303，将字节计数值乘以每个服务器的权重值比例，得到每个服务器的负载值li。即。53.如图3所示，初始化时，在交换机中设定30个流规则，并新增3台服务器，同时给予每个服务器预设值为10的权重值。在首次负载平衡执行完毕之后，由于预设的字节计数值为1，因此，计算后的所有流规则中的字节计数值之和pt为30，且每个服务器被平均分配到10条负载量。一段时候之后，假设变更了权重值，第1个服务器的权重值为3，第2个服务器的权重值为3，第3个服务器的权重值为4，进行下一次的负载平衡计算后，得到所有流规则中的字节计数值之和pt为300，则可以计算出：第1个服务器的负载值为90，第2个服务器的负载值为90，第3个服务器的负载值为120。因此，第1个服务器和第2个服务器均释放出一个ip负载量（即10），第3个服务器获得两个ip负载量（即20）。54.步骤s304，在执行第一次初始化的负载平衡计算之后，对权重值进行调整，收集每个服务器的cpu使用率ic和内存占用率im，将cpu使用率ic和内存占用率im相加并减半之后得到占用率，然后用100%减去占用率得到当前服务器的可用率ii，即ii=100%-0.5（ic im）；然后计算所有服务器的可用率之和it，即；将当前服务器的可用率ii除以所有服务器的可用率之和it，得到商数乘以100，四舍五入取整后得到每个服务器的权重值wi，即；然后根据步骤s303，重新计算每个服务器的负载值li，控制器修改交换机中用以匹配用户端ip地址的流规则，重新导向用户端发送的流量到负载值li有盈余的后端服务器。55.图5为用户端发送连线请求流程图。根据图5解释步骤s4和步骤s5。56.步骤s4，用户端向交换机发送arp请求封包，以取得各自网域的预设闸道的mac地址。用户端向交换机发送arp请求封包，在arp请求封包进入到交换机时，交换机根据流表中的规则对封包进行比对；由于交换机中并没有设置arp请求封包的规则，因此，该arp请求封包没有在流表中发现能与之匹配的规则，则交换机将该arp请求封包封装成packet-in封包发送到控制器处理。57.控制器接收到packet-in封包时，根据用户端发送的封包内容，查询相对应的预设闸道的mac地址，并将预设闸道的mac地址加入到arp回复封包中，再以packet-out的方式将arp回复封包通过交换机回传给用户端。58.步骤s5，流量导向和封包追踪机制：用户端在取得预设闸道的mac地址后，发出http请求封包至交换机；交换机根据流表中的规则对封包进行比对；交换机，先查询自身内部流表中的流规则是否匹配用户端ip地址，再根据匹配后的结果将用户端的数据封包发送给后端的服务器。59.当交换机将流量导向新的服务器时，用户端有可能仍然与旧的服务器进行数据传输，此时，有可能造成用户端连线的终端。因此，需要执行封包追踪机制，以防止上述行为的发生。60.图4是执行封包追踪机制的流程图。控制器对用户端发送的封包进行解析，核查封包中的旗标（flag）是否有被设置：当旗标被设置，表示该条封包属于新连线的封包，然后控制器解析该封包的五元素（5-tuple）并查询先前的记录中是否有相同的记录信息：如果有记录，则将此封包传送至新的服务器；如果没有记录，则控制器用哈希函数对封包的五元素进行存储，作为下一次连线的判别，接着将此封包传送至新的服务器。61.五元素由源ip(sourceip)、源端口(sourceport)、目标ip(destinationip)、目标端口(destinationport)、4层通信协议(thelayer4protocol)5个字段组成。62.当旗标没有被设置，控制器解析该封包的五元素（5-tuple），查询先前的记录中是否有相同的记录信息；如果有记录则表示该条封包是属于新连线的封包，将此封包传送至新的服务器；否则，该条封包是属于旧的封包，送往旧的服务器。63.确定接收的服务器之后，交换机将该封包送往群组规则中，由该群组规则修改封包内容，修改目的端ip为服务器的ip，修改目的端mac为服务器的mac地址，并将封包传送至服务器。64.服务器向交换机回传http回复封包，此时，封包中的目的端mac地址为预设闸道的mac地址，因此，匹配到该封包的规则会将该封包传送至其它流表并修改目的端mac地址为用户端的mac地址，以确保服务器发送的http回复封包能狗准确的送回到用户端。65.设定100位用户向系统发送http请求，连线1分钟并记录观察http请求回应时间，实验结果如表2。66.表2为http请求回应时间统计表（单位微妙）。67.轮询演算方案和随机演算方案在前30秒发送的http请求过程中，需要花费的时间，是本方案的2~3倍，这是由于用户端在第一次发送http请求的时候，交换机内并足以没有匹配该ip地址的规则，所以交换机将该http请求封包传送至控制器，由控制器决定送往哪一个服务器，同时，新增加流规则到交换机，以避免下次同一个ip地址发送的http请求被传送至控制器。68.本方案维持在10000微妙的响应时间，这是由于本方案预先通过ip分群的方法，将用户端的ip做了分群，并匹配流规则到交换机中。让每条来自不同的ip的用户端在第一次发送http请求的时，不需要经由交换机传送至控制器去判别并新增流规则，因此，可以大幅的减少用户端请求的响应时间。69.本方案设置有负载平衡机制，将用户端的请求动态的分配到服务器。同时，封包追踪机制，在维持封包连线传输的同时，不会造成用户端与服务器之间的连线终端。70.传统的方案中，利用用户端在第一次发送连线请求时，将封包导向控制器，由控制器判断当前最合适的服务器，并新增一条能够匹配该条连线信息且修改封包标头内容的规则，让封包可以顺利导向内部的服务器地址到交换机中，从而完成负载的调整。然而，在实际的运作中，控制器可能会同时需要处理好几万条的连线请求，可能会造成控制器的处理瓶颈。此外，当用户端连线请求被导向内部服务器时，会有一条规则来处理该条连线的封包，待交换机收到来自服务器的回复时，也需要一条规则来修改封包标头，才能正确的回到相对应的用户端，因此，传统的做法可能导致同时由大量的规则被新增到交换机中，如果超出交换机的最大容纳值时，就会造成用户端的连线失败。71.本方案，交换机匹配用户端的来源段ip地址，在根据匹配后的结果将用户连线请求送往后端的服务器，最后由相应的服务器来回应网页内容，从而到达ip分群的目的。传统的mac地址对应表，同一条规则只能匹配一个mac地址。而ip分群的方法，能够直接匹配整个网段的ip地址，从而大量地减少所需要被定义的规则与存储空间，大幅度地较少新增到交换机的流规则数量。72.传统的方案，如果赋予每台服务器一个权重值，作为控制器分配流量负载平衡的决策，而当该权重值是管理者自行定义时，就无法真正的反映出服务器的实际负载能力。73.本方案，取得各个服务器当前的负载状态，让控制器能够评估并计算出最佳的流量分配，以此来实现负载平衡。74.可以理解的是，对本领域普通技术人员来说，可以根据本发明的技术方案及其发明构思加以等同替换或改变，而所有这些改变或替换都应属于本发明所附的权利要求的保护范围。当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
