windows server 2012怎么配置网络负载均衡

众所周知，windows server 2012是支持虚拟系统的。那么具体怎么对服务器设置网络负载均衡，一起来看看。

1、给2台WEB服务器装置NLB，以后在其间恣意一台上来新建群集，然后将别的一台加入到这个群会集即可，并保证这2台服务器都是运用的静态IP。

2、在web-01(1921681130)上从管理工具中翻开 网络负载均衡器，右击“网络负载平衡群集”，挑选“新建群集”

3、在“新群集：衔接”窗口中将 1921681130增加为主机，点击下一步进入 “新群集：主机参数”，下一步，进入 “新群集：群集IP地址”，增加窗口中的“增加” 将1921681254 增加到窗口中然后下一步；

4、进入 “新群集：群集参数”，挑选“多播”然后下一步；进入 “新群集：端口规则”，选中悉数，然后修改；将端口范围改成 80~80，协议选 “TCP”，相关性选“无”点击断定回到主窗口，然后点击完结。

5、经过上面的过程，咱们现已建立了一个群集，并且将web-01加入到了群会集，咱们还需要手动将web-02也加入到群会集。在群集(1921681254)上右键点击“增加主机到群集”。衔接”窗口中的 主机中输入1921681131即可。

负载均衡

先来简单了解一下什么是负载均衡，单从字面上的意思来理解就可以解释N台服务器平均分担负载，不会因为某台服务器负载高宕机而某台服务器闲置的情况。那么负载均衡的前提就是要有多台服务器才能实现，也就是两台以上即可。

测试环境

在VMware里安装了三台。

A服务器IP ：1921680219 （主）

B服务器IP ：1921680119

C服务器IP ：1921680109

部署思路

A服务器做为主服务器，域名直接解析到A服务器（1921680219）上，由A服务器负载均衡到B服务器（1921680119）与C服务器（1921680109）上。

在A服务器上，upstream指令——分配负载

vi /etc/nginx/confd/defaultconf

upstream 1921680219 {

server 1921680119:80;

server 1921680109:80;

}

server {

listen 80;

server_name 1921680219;

charset utf8;

location / {

proxy_pass

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}

}

保存重启nginx

在B、C服务器上，

vi /etc/nginx/confd/defaultconf

server {

listen 80;

server_name 1921680219;

index indexhtml;

root /usr/share/nginx/html;

}

保存重启nginx

测试

当访问的时候，为了区分是转向哪台服务器处理我分别在B、C服务器下写一个不同内容的indexhtml文件，以作区分。

打开浏览器访问acom结果，刷新会发现所有的请求均分别被主服务器（1921685149）分配到B服务器（1921680119）与C服务器（1921680109）上，实现了负载均衡效果。

主服务器不能提供服务吗？

以上例子中，我们都是应用到了主服务器负载均衡到其它服务器上，那么主服务器本身能不能也加在服务器列表中，这样就不会白白浪费拿一台服务器纯当做转发功能，而是也参与到提供服务中来。

怎么解决这个问题呢？因为80端口已经用来监听负载均衡的处理，那么本服务器上就不能再使用80端口来处理1921680219的访问请求，得用一个新的。

于是我们在主服务器中编辑/etc/nginx/confd/defaultconf，添加以下内容

server {

listen 8080;

server_name 1921680219;

index indexhtml;

root /usr/share/nginx/html;

}

重启nginx

然后，再重新渡负载均衡。

更多Nginx相关教程见以下内容 ：

CentOS 62实战部署Nginx+MySQL+PHP

使用Nginx搭建WEB服务器

搭建基于Linux63+Nginx12+PHP5+MySQL55的Web服务器全过程

CentOS 63下Nginx性能调优

CentOS 63下配置Nginx加载ngx_pagespeed模块

CentOS 64安装配置Nginx+Pcre+php-fpm

Nginx安装配置使用详细笔记

Nginx日志过滤 使用ngx_log_if不记录特定日志

1、打开Workbench并从功能区中选择Tools选项卡。选择Platform Services。

2、在Basic选项卡下， 选择‘Standard’ 作为它的服务器角色。

3、对Load Balance Server 2重复步骤2。负载均衡服务器的设置。

4、如果希望同时设置两个服务器作为冗余对和负载均衡对，则可以只需添加FrameWorX服务器冗余即可。

注意事项：

交换机根据工作位置的不同，可以分为广域网交换机和局域网交换机。广域的交换机就是一种在通信系统中完成信息交换功能的设备，它应用在数据链路层。交换机有多个端口，每个端口都具有桥接功能，可以连接一个局域网或一台高性能服务器或工作站。实际上，交换机有时被称为多端口网桥。

根据一些专家的调查分析，发现企业在使用数据库的时候，90%以上主要用来查询。有些企业这个比例甚至更高。也就说，用户对数据库的操作，其实更新操作占的比例很少。大部分的操走都只是查询操作。

　　如一些论坛，大部分用户只会看贴，而不会发帖。这就是一个典型的查询操作比例大大超过更新操作比例的例子。针对这种情况，其查询操作往往是其数据库性能的瓶颈。如何有效提高查询的性能，这就使各个数据库专家在考虑的问题。在SQL Server数据库中，已经有了一个现成的解决方案。数据库管理员可以利用缓存服务器来提高数据库的性能。笔者这里就以SQLServer2008为例，谈谈如何利用缓存服务器来实现负载均衡，来提高数据库的查询效率。

　　一、 数据查询与数据更新分开走。

　　如上图所示，如果用户要查看某个帖子，其就会打开某个连接。此时WEB应用服务器就会从后台数据库中查询相关的记录。这里需要注意的是，由于其只是查看帖子，而不涉及到更新的操作，为此WEB应用服务器就只从缓存服务器中读取数据。这个缓存服务器中的记录跟数据库服务器的内容是同步的。WEB应用服务器在从数据库缓存服务器读取数据之前，还会先判断一下哪台数据库服务器比较空。会优先连接到比较空闲的数据缓存服务器中，然后从这台服务器中读取数据。所以，当访问这个论坛的用户比较多时，这个数据缓存服务器能够实现负载均衡的需要。

　　如果用户看了某个帖子，现在需要发表一个评论，此时后台数据库会怎么操作呢注意，当WEB应用服务器发送了一个 Update更新操作的时候，其应用服务器会自动连接到数据库服务器，而不会再连接到数据库缓存服务器。而是直接向数据库服务器发送更新操走的语句。当数据库服务器更新了相关的内容之后，会与数据库缓存服务器实现数据的同步。从上图中可以看出，整个数据查询与数据更新WEB应用服务器是分两条路走。其实这就好像是公路上分道行驶，机动车走机动车道;非机动车走非机动车道。

　　　　如此的话，就不会因为非机动车比较慢，而影响到机动车的速度。在这个方案中，将数据库的更新操作与查询操作分开来走，也是类似的道理。在查询时，数据流是单向流动的，所以能够在很大程度上提高查询的效率。从而让数据负载均衡的效果更加明显。总之，当某个应用程序查询操作大大超过更新操作时，通过在多个数据库间缓存只读数据，并在数据库间均匀连接客户端以分发负载，则就可以向外扩展工作负荷的读取分区，即实现负载均衡的目的。

　　二、 采用这个方案需要注意的地方。

　　在部署这个解决方案时，仍然有些数据库管理员需要关注的内容。如以下这些内容，数据库管理员需要根据企业的实际情况来进行调整，以提高这个方案的价值。

　　首先需要考虑数据缓存服务器与数据库服务器之间同步的频率问题。这个同步操作是一把双刃剑。若同步的频率太高，会影响数据库服务器与缓存服务器的性能;若同步频率比较低的话，则数据库缓存服务器中的数据得不到及时的更新。

　　如此的话，用户查询时可能在短时间内无法获取最新的数据。所以，一般来说，系统滞后的时间应该尽量的短，即数据库服务器的更新内容必须尽快与数据库缓存服务器进行同步。

　　理想的状态时，在更新数据库服务器的同时更新数据库缓存服务器。但是，这么做是以牺牲数据库与数据库缓存服务器的性能为代价的。为此数据库管理员在实施这个解决方案时，往往不会这么做。而是设置在一段时间之后同步。如可以设置为10秒、60秒、300秒或者更长的时间后进行同步。

　　具体这个同步的时间间隔多少为好，没有一个统一的标准。这需要数据库管理员根据企业对数据同步的要求不同而定。一般来说，数据库管理员在满足用户需要的前期下，可以将这个时间设置的相对长一点。这可以避免因为过多的同步操作而降低了这个方案的价值。其实，对于大部分用户来说，60秒左右的时间差异还是可以接受的。如在论坛中，一个人发帖后，在一分钟之后看到一般不会有什么问题。对于人的感觉来说，这个一分钟时间不长。但是对于数据库服务器来说，这一分钟可以做很多事情。所以，适当延长这个同步时间，却可以在很大程度上提高数据库服务器性能。这个时间的代价，有时候还是值得的。

　　其次，在数据库服务器与数据库缓存服务器之间，应该建立比较直接的、快速的网络连接。当用户比较多时，数据库服务器与数据库缓存服务器之间若发生同步操作，则会造成很多的网络流量。有时候同步操作发生时，影响这个工作的效率可能并不是数据库服务器或者数据库缓存服务器本身，而是他们之间的网络连接。

　　由于其可用的带宽跟不少数据库服务器系统的吞吐量，从而影响到了同步操作的效率。为此，在数据库服务器与数据库缓存服务器之间的网路连接，应该尽量的直接。如最好不要在中间夹着其他的不必要的网络设备;也最好不要在他们之间配备防火墙等安全策略。这些安全策略与网络设备都会在很大程度上影响到这个同步操作的效率。

　　另外，最好也不要有其他的应用服务来争抢带宽。所以简单的说，如果可能的话，在数据库服务器上部署多张网卡，直接与数据库源服务器实现双机互联，而那传输同步操作需要的数据，这是一个很不错的手段。由于其数据传输更直接、而且其他设备或者应用服务也会来争夺其带宽，同时又可以克服他们的非法攻击。为此，只要他们之间多距离比较短的话，采用这种方案可能效果会比较好，可以在最大程度内缩短这个同步操作所需要的时间，从而让其他用户尽早看到更新的数据。

　　第三为同步选择合适的复制方案。

　　那么该如何实现数据库服务器与缓存服务器之间的同步呢在SQLServer数据库中，有三个方案可供数据库管理员选择。这三个方案分别为快照复制、合并复制与事务复制。这三个复制模型各有各的特点。不过从最终效果来看，其都可以实现数据库服务器与数据库缓存服务器之间的同步。不过由于其内部的实现机制不同，为此其虽然结果相同，但是从性能等方面考虑，还是有差异的。

　　各种复制模型的原理与特点属于基本知识的范畴，笔者在这里就不做过多阐述了。笔者认为，在利用这个数据库缓存服务器来实现负载均衡的方案中，最好采用事务复制的同步方案。因为相比其他方案来说，事务日志能够满足事务的一致性、数据库服务器系统比较大的吞吐量、同步时尽量少的开销、以及系统比较短的滞后时间等等需求。

　　另外在有些企业中采用这个方案的话，还要考虑到表与记录的过滤需求。而通过事务复制的话，就可以实现对列和行的过滤。而其他复制模型的话，只能够部分满足这些需求。

　　　　所以，笔者认为，在选择数据同步方案时，可能选择事务复制来实现同步，更加的合适。不过最终是否真是如此，还是要求数据库管理员根据企业的实际需要，然后分别采用几个复制模型来进行测试，才能够得出真正合理的结果。

负载均衡（Load Balance）

由于目前现有网络的各个核心部分随着业务量的提高，访问量和数据流量的快速增长，其处理能力和计算强度也相应地增大，使得单一的服务器设备根本无法承担。在此情况下，如果扔掉现有设备去做大量的硬件升级，这样将造成现有资源的浪费，而且如果再面临下一次业务量的提升时，这又将导致再一次硬件升级的高额成本投入，甚至性能再卓越的设备也不能满足当前业务量增长的需求。

针对此情况而衍生出来的一种廉价有效透明的方法以扩展现有网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性的技术就是负载均衡（Load Balance）。

负载均衡技术主要应用

1、DNS负载均衡 最早的负载均衡技术是通过DNS来实现的，在DNS中为多个地址配置同一个名字，因而查询这个名字的客户机将得到其中一个地址，从而使得不同的客户访问不同的服务器，达到负载均衡的目的。DNS负载均衡是一种简单而有效的方法，但是它不能区分服务器的差异，也不能反映服务器的当前运行状态。

2、代理服务器负载均衡 使用代理服务器，可以将请求转发给内部的服务器，使用这种加速模式显然可以提升静态网页的访问速度。然而，也可以考虑这样一种技术，使用代理服务器将请求均匀转发给多台服务器，从而达到负载均衡的目的。