如何在Windows Server 2012中实现扩展文件服务器

　　我们介绍了扩展文件服务器，这里继续介绍扩展文件服务器背后的技术SMB 30和CSV 20以及在Windows Server 2012中实现扩展文件服务器的具体步骤。

深入了解SMB 30 和CSV 20

SMB 30 和CSV 20是扩展文件服务器背后的技术。SMB 30得到了增强，可以提供透明的故障转移功能，当工作负载转移或者服务器崩溃时，允许中断的文件操作重新连接。SMB Multichannel允许多个网卡用于SMB流量增加吞吐量和可靠性。SMB Direct允许远程DMA功能的网卡进行服务器之间内存到内存的转移。SMB Encryption提供SMB通信端到端的数据包加密。

CSV 20主要更新包括一个一致的文件名称空间，称为CSV文件系统。它提供了高速I / O直接访问由多个同步服务器。CSV 20还提供了磁盘加密的加密支持和SMB 共享的VSS备份，而不必像WindowsServer 2008 R2一样通过网络重定向I / O

通过启用CSV读缓存可能优化读密集型应用程序。可以通过使用两个配置设置实现，SharedVolumeBlockCacheSizeInMB和CsvEnableBlockCache第一个设置是用来控制缓冲区读请求RAM的缓存大小，第二个设置使每个磁盘私有读缓存来优化特定卷。你可以使用以下PowerShell cmdlets启用和设置读缓存：

（Get-Cluster）。SharedVolumeBlockCacheSizeInMB = 512

- sets read cache to 512MB

Get-ClusterSharedVolume “Cluster Disk 1” | Set-ClusterParameter CsvEnableBlockCache 1

实现扩展文件服务器

现在既然已经熟悉了扩展文件服务器，这里是在Windows Server 2012故障转移集群中实现的7个步骤。

1 通过服务器管理器安装文件服务器角色

2 通过服务器管理器安装故障转移集群功能

3 使用磁盘管理配置共享磁盘（上线，初始化，NTFS格式）

注意：不要为磁盘分配驱动器名称，可以使用CSV

4 验证和创建故障转移集群--与Windows Server 2008 / R2相同

5 添加磁盘到CSV（使用故障转移集群管理器，右键单击磁盘并选择添加到CSV）

6 添加文件服务器角色（使用故障转移集群管理器，右键单击角色，配置角色…）

7 添加文件共享与连续的可用性（右键单击新添加的文件服务器，添加文件共享）

步骤6中配置文件服务器时一定要选择扩展文件服务器当选择类型的文件服务器。如图2所示。

在步骤7中添加文件分享时，一定要选择“SMB Share- Applications”如图3所示。新的分享向导将提示您为CSV卷和共享名称来创建共享。

通过使用Windows Server 2012故障转移集群与扩展文件服务器，现在可以支持成千上万用户的企业级环境。 CSV 20和SMB 30中的新功能提供了持续可用的文件共享，提供了较高的性能和可靠性。其他的新的集群功能如集群识别的更新、集群的任务调度程序、集群资源启动优先级、动态群体管理和内置的NIC组合，这些反映了微软将继续发展故障转移集群技术。

两者都不是，Windows Server 2012是微软公司研发的服务器操作系统，于2012年9月4日发布。

Windows Server 2012可以用于搭建功能强大的网站、应用程序服务器与高度虚拟化的云应用环境。

无论是大、中或小型的企业网络，都可以使用Windows Server 2012的管理功能与安全措施，来简化网站与服务器的管理、改善资源的可用性、减少成本支出、保护企业应用程序与数据。

可以更轻松有效地管理网站、应用程序服务器与云应用环境。

2012年2月29日，微软推出了Windows Server 8 Beta版本进行公开测试，该版本更新了在线备份服务，并内置了简体中文、英文、法语、德语、日语等五种语言。

Windows Server 2012包含了SMB 30，第三版服务器消息块（SMB）协议提供的新功能，可用于构建持续可用的文件服务器。SMB是一种网络文件共享协议，可供应用程序读写文件，并通过网络从服务发出服务请求。

SMB 30新增了自动重新平衡横向扩展文件服务器客户端、作为来宾群集共享存储的VHDX文件、通过SMB进行Hyper-V实时迁移、改进SMB带宽管理和支持一个横向扩展文件服务器上的多个SMB实例等功能。

分布式存储与传统的SAN、NAS相比，优势如下：

1、性能: 在分布式存储达到一定规模是，性能会超过传统的SAN、NAS。大量磁盘和节点，结合适当的数据分布策略，可以达到非常高的聚合带宽。传统的SAN、NAS都会有性能瓶颈，一旦达到扩展能力，性能不会改变甚至降低。

2、价格: 传统的SAN、NAS，价格比较高。特别是SAN网络设备，光纤网络成本比较高。而且，以后扩展还需要增加扩展柜。成本太高。分布式存储只需要IP网络，几台X86服务器加内置硬盘就可以组建起来，初期成本比较低。扩展也非常方便，加服务器就行。

3、可持续性: 传统的SAN、NAS扩展能力受限，一个机头最多可以带几百个磁盘。如果想要个PB以上的共享存储，分布式存储只的选择。不用担心扩展能力问题。

缺点：

1、需要比较强的技术能力和运维能力，甚至有开发能力的用户。传统存储开箱即用，硬件由厂家提供，也有完善的文档和服务。而分布式很多是开源或者是有公司基于开源系统提供支持服务，版本迭代比较快，出问题后有可能需要自己解决。

2、数据一致性问题。对于ORACLE RAC这一类对数据一致性要求比较高的应用场景，分布式存储的性能可能就稍弱了，因为分布式的结构，数据同步是一个大问题，虽然现在技术一致在进步，但是也不如传统存储设备数据存储方式可靠。

3、稳定性问题，分布式存储非常依赖网络环境和带宽，如果网络发生抖动或者故障，都可能会影响分布式存储系统运行。例如，一旦发生IP冲突，那么整体分布式存储可能都无法访问。传统存储一般使用专用SAN或IP网络，稳定性方面，更可靠一些。

超融合架构迅速发展的原因是其具有显著的优势，能够带来极高 的客户价值。超融合架构实现了计算、存储、网络等资源的统一管理 和调度，具有更弹性的横向扩展能力，可以为数据中心带来的效 率、灵活性、规模、成本和数据保护。使用计算存储超融合的一体化 平台，替代了传统的服务器加集中式存储的架构，使得整个架构更清 晰简单，极大简化了复杂 IT 系统的设计。

从用户的角度考虑，选择超融合架构的理由，往往在以下几个方面：

(1)性能

业务规模、数据可用性、业务连续性、性能等方面的需求快速增 长，传统的 IT 架构无法满足或者代价过高。超融合架构可以轻松达 到数十万 IOPS。若采用全闪存超融合，性能远超普通的 SAN 阵列。

(2)成本

传统 IT 架构在提供同样性能的前提下成本过高，成本并不是超 融合的优势，但比传统方案还是能节省投资。

(3)利旧

利旧原本不是超融合该做的事，但却是真实存在的需求。超融合 支持通用标准 x86 服务器硬件，因此支持在现有服务器上部署，从而 保护投资。

超融合服务器是一种集成了计算、存储、网络和虚拟化等多种功能的服务器。

超融合服务器采用一体化的架构，将计算、存储、网络和虚拟化等多种功能融合在一起，通过软件定义的方式提供全方位的资源管理和应用部署。这种一体化的架构可以简化IT基础设施的管理，提高资源利用率。

超融合服务器采用模块化的设计，可以根据实际需求进行灵活的扩展。这种扩展性可以帮助企业更好地适应业务发展的需求，减少了资源浪费和成本开销。超融合服务器通过软件定义的方式实现了高可用性。它可以自动检测故障并进行快速的故障转移，从而确保业务的连续性和稳定性。

超融合基础架构是指在同一套单元设备中不仅仅具备计算、网络、存储和服务器虚拟化等资源和技术，而且还包括备份软件、快照技术、重复数据删除、在线数据压缩等元素，而多套单元设备可以通过网络聚合起来，实现模块化的无缝横向扩展（scale-out），形成统一的资源池。

超融合服务器功能特点

超融合基础架构继承了融合式架构的一些特性，同样都是使用通用硬件服务器为基础，将多台服务器组成含有跨节点统一储存池的群集，来获得整个虚拟化环境需要的效能、容量扩展性与数据可用性。

可透过增加群集中的节点数量，来扩充整个群集的运算效能与储存空间，并透过群集各节点间的彼此数据复制与备份，提供服务高可用性与数据保护能力。

而为能灵活地调配资源，超融合架构也采用了以虚拟机（VM）为核心，软件定义方式来规划与运用底层硬件资源，然后向终端用户交付需要的资源。

传统的存储区域网络架构使用的运算和储存单元是分离的。传统的服务器外接SAN交换机、储存设备等，超融合架构则将运算和储存单元合二为一。

在NetBIOS出现之后，Microsoft就使用NetBIOS实现了一个网络文件/打印服务系统，这个系统基于NetBIOS设定了一套文件共享协议，Microsoft称之为SMB（Server Message Block）协议。这个协议被Microsoft用于它们Lan Manager和Windows NT服务器系统中，而Windows系统均包括这个协议的客户软件，因而这个协议在局域网系统中影响很大。随着Internet的流行，Microsoft希望将这个协议扩展到Internet上去，成为Internet上计算机之间相互共享数据的一种标准。因此它将原有的几乎没有多少技术文档的SMB协议进行整理，重新命名为 CIFS（Common Internet File System），并打算将它与NetBIOS相脱离，试图使它成为Internet上的一个标准协议。

因此，为了让Windows和Unix计算机相集成，最好的办法即是在Unix中安装支持SMB/CIFS协议的软件，这样Windows客户就不需要更改设置，就能如同使用Windows NT服务器一样，使用Unix计算机上的资源了。

与其他标准的TCP/IP协议不同，SMB协议是一种复杂的协议，因为随着Windows计算机的开发，越来越多的功能被加入到协议中去了，很难区分哪些概念和功能应该属于Windows操作系统本身，哪些概念应该属于SMB 协议。其他网络协议由于是先有协议，实现相关的软件，因此结构上就清晰简洁一些，而SMB协议一直是与Microsoft 的操作系统混在一起进行开发的，因此协议中就包含了大量的Windows系统中的概念。 在SMB协议中，计算机为了访问网络资源，就需要了解网络上存在的资源列表（例如在Windows下使用网络邻居查看可以访问的计算机），这个机制就被称为浏览（Browsing）。虽然SMB协议中经常使用广播的方式，但如果每次都使用广播的方式了解当前的网络资源（包括提供服务的计算机和各个计算机上的服务资源），就需要消耗大量的网络资源和浪费较长的查找时间，因此最好在网络中维护一个网络资源的列表，以方便查找网络资源。只有必要的时候，才重新查找资源，例如使用Windows下的查找计算机功能。

但没有必要每个计算机都维护整个资源列表，维护网络中当前资源列表的任务由网络上的几个特殊计算机完成的，这些计算机被称为Browser，这些Browser通过记录广播数据或查询名字服务器来记录网络上的各种资源。

Browser并不是事先指定的计算机，而是在普通计算机之间通过自动进行的推举产生的。不同的计算机可以按照其提供服务的能力，设置在推举时具备的不同权重。为了保证一个Browser停机时网络浏览仍然正常，网络中常常存在多个Browser，一个为主Browser（Master Browser），其他的为备份Browser。 工作组和域这两个概念在进行浏览时具备同样的用处，都是用于区分并维护同一组浏览数据的多个计算机。事实上他们的不同在于认证方式上，工作组中每台计算机都基本上是独立的，独立对客户访问进行认证，而域中将存在一个（或几个）域控制器，保存对整个域中都有效的认证信息，包括用户的认证信息以及域内成员计算机的认证信息。浏览数据的时候，并不需要认证信息，Microsoft将工作组扩展为域，只是为了形成一种分级的目录结构，将原有的浏览和目录服务相结合，以扩大Mircrosoft网络服务范围的一种策略。工作组和域都可以跨越多个子网，因此网络中就存在两种Browser，一种为Domain Master Browser ，用于维护整个工作组或域内的浏览数据，另一种为Local Master Browser，用于维护本子网内的浏览数据，它和Domain Master Browser通信以获得所有的可浏览数据。划分这两种Browser 主要是由于浏览数据依赖于本地网广播来获得资源列表，不同子网之间只能通过浏览器之间的交流能力，才能互相交换资源列表。

但是，为了浏览多个子网的资源，必须使用NBNS名字服务器的解析方式，没有NBNS的帮助，计算机将不能获得子网外计算机的NetBIOS名字。Local Master Browser也需要查询NetBIOS名字服务器以获得Domain Master Browser的名字，以相互交换网络资源信息。

由于域控制器在域内的特殊性，因此域控制器倾向于被用做Browser，主域控制器应该被用作Domain Master Browser，他们在推举时设置的权重较大。 在Windows 9x系统中，习惯上使用共享级认证的方式互相共享资源，主要原因是在这些Windows系统上不能提供真正的多用户能力。一个共享级认证的资源只有一个口令与其相联系，而没有用户数据。这个想法是适合于一小组人员相互共享很少的文件资源的情况下，一旦需要共享的资源变多，需要进行的限制复杂化，那么针对每个共享资源都设置一个口令的做法就不再合适了。

因此对于大型网络来讲，更适合的方式是用户级的认证方式，区分并认证每个访问的用户，并通过对不同用户分配权限的方式共享资源。对于工作组方式的计算机，认证用户是通过本机完成的，而域中的计算机能通过域控制器进行认证。当 Windows计算机通过域控制器的认证时，它可以根据设置执行域控制器上的相应用户的登录脚本并桌面环境描述文件。 共享资源每个SMB服务器能对外提供文件或打印服务，每个共享资源需要被给予一个共享名，这个名字将显示在这个服务器的资源列表中。然而，如果一个资源的名字的最后一个字母为$，则这个名字就为隐藏名字，不能直接表现在浏览列表中，而只能通过直接访问这个名字来进行访问。在SMB协议中，为了获得服务器提供的资源列表，必须使用一个隐藏的资源名字IPC$来访问服务器，否则客户无法获得系统资源的列表。 l SMB是过去Windows网络中用来存取远程文件的通讯协议

n 无法整合新的NTFS功能

n 并不是设计用来传输大型的远程文件

l SMB2内建在Windows Vista与Windows Server 2008

n 支援 NTFS客户端符号链接

n 所有操作可以批处理，减少 client/server之间的来回

n 支持更大的暂存大小，比以前增加 30到40倍的传输量 SMB透明故障转移：让管理员可执行群集文件服务器中节点的硬件或软件维护，且不会中断将数据存储在这些文件共享上的服务器应用程序。此外，如果群集节点出现硬件或软件故障，SMB 客户端将以透明方式重新连接到其他群集节点，且不会中断将数据存储在这些文件共享上的服务器应用程序。即客户端能够持续、稳定的对远程文件服务器进行通讯，用户不会感受到单点服务器故障所带来的性能影响（不兼容SMB10或SMB2x）。 SMB横向扩展：可构建横向扩展文件服务器（Scale-Out File Server），在使用群集共享卷（CSV）版本2时，管理员可以通过文件服务器群集中所有节点，创建可供同时访问含直接I/O的数据文件的文件共享。这可更好地利用文件服务器客户端的网络带宽和负载平衡，以及优化服务器应用程序的性能。 SMB多通道：如果在SMB30客户端及服务器之间提供多条路径，则支持网络带宽和网络容错的聚合，提升了网络可用性及文件服务器的稳定性，并让服务器应用程序可以充分利用可用网络带宽，以及在发生网络故障时快速恢复。 SMB直接访问（SMB over Remote Direct Memory Access[RDMA]）：支持使用具有RDMA功能且可全速运行的网络适配器，其中延迟非常低且CPU利用率极少。对于Hyper-V或Microsoft SQL Server等实现工作负载，这让远程服务器如同本地存储一般。 用于服务器应用程序的性能计数器：全新 SMB 性能计数器提供有关吞吐量、延迟和 I/O/秒 (IOPS) 的按共享列出的详细信息，从而让管理员可以分析用于存储数据的 SMB 30 文件共享的性能。这些计数器专为将文件存储在远程文件共享上的服务器应用程序而设计，如 Hyper-V 和 SQL Server。 性能优化：SMB 30 客户端和 SMB 30 服务器均已针对小型随机读/写 I/O 优化，这种 I/O 在 SQL Server OLTP 等服务器应用程序中很常见。此外，默认情况下打开大型最大传输单元 (MTU)，这将大幅提高大型连续传输性能，如 SQL Server 数据仓库、数据库备份或还原、部署或复制虚拟硬盘。 SMB加密：提供SMB数据的端对端加密并防止数据在未受信任网络中遭受窃听。无需新部署成本，且无需Internet协议安全性（IPsec）、专用硬件或WAN加速器。它可按共享配置，也可针对整个文件服务器配置，并且可针对数据遍历未受信任网络的各种方案启动。 为SMB文件共享所提供的VSS： SMB目录租用：缩短分支机构的应用程序响应时间。使用目录租用后，缩短了从客户端到服务器的往返时间，因为是从保留时间较长的目录缓存中检索元数据。缓存一致性得到保持，因为在服务器上的目录信息更改时将通知客户端。适用于 主文件夹（读/写，无共享）和 发布（只读，带共享）。 SMB PowerShell：借助于全新的SMB Windows PowerShell cmdlet，管理员可以从命令行以端对端方式管理文件服务器上的文件共享。

在国内,服务器整合已经有很多成功的应用案例。随着云计算和虚拟化步伐的日益加速,更多尚未进行服务器整合的客户也逐渐开始关注这一基础架构解决方案。和全球许多企业的IT部门一样,国内的IT应用也经历过一段服务器硬件设备的高速扩张期。特别是在2005年左右,随着单位计算价格大幅下降,以及服务器供应商的同质化价格竞争,使得服务器采购价格变得极为低廉。而且由于国内许多企业的财务模式,为每个部门的每个应用建立独立的系统是非常常见的事情。从2007年开始,我们就不断发现IT硬件支出在整个IT开销中所占比率日益减少,而机房资源,能耗等隐性成本迅速递增。计算资源可以带来的优势是不言而喻的,除了可以消除上述隐性成本外,对国内用户而言,很重要的一点是可以更加迅速地面对多变的商业环境。原来的系统建设模式一般是内部预算申请、立项、采购、到货、安装、测试、上线一般都会延续3个月甚至更长的时间。而如何可以实现完全的资源池化,更易于整个系统资源的监控、预测和调配,以及减少那些次要应用所占的计算资源,释放出更多的处理能力。同时,如果每台服务器的资源需求峰值不在同一时刻发生,还可以进行错峰整合。比如一些财务系统一般仅在月末有大交易量发生,可以在这时降低其它不是核心应用的响应速度。在服务器虚拟化方式上,有横向和纵向两种模式。我们目前更多地关注于横向扩展模式,即将大量小型服务器整合在一个计算池中,按需分配资源。而其实纵向扩展的方式在国内亦有很大应用场合。这里将两者的优劣和适用场景略做介绍。横向扩展目前最多的做法是通过VMware等虚拟化软件,在已有硬件平台上搭建一个虚拟层,在其上运行操作系统及应用程序。这种方式可以充分利用用户已有的系统资源,在有些情况下,通过相应的系统分析软件(如VMwareROITCO等)分析整合后,不需额外购买任何服务器设备,就可以获取更大的计算资源。但这种方式也不是万能的,国内有些客户常会有这样一个设想,即利用原本的2台服务器(每台上面运行2颗处理器)来运行一个需要4颗处理器的应用程序,这种想法在横向的虚拟化方式上得不到支持。(高性能计算应用例外)此外,这种虚拟化整合方式也会带来一些隐性成本,例如整合后出现故障如何快速找到供应商提供服务响应,国内不少x86架构的服务器一般的使用周期是5年,而超过3年的保修期后用户需要支付设备供应商不小的维护费用,加上额外虚拟化软件的咨询、部署和维护费用,横向扩展的总体拥有成本不一定低于纵向扩展的虚拟化整合方式。而且,横向扩展的方式需要将目前的应用环境做大规模迁移。这对用户来说也不是一项愿意轻易尝试的工作。纵向扩展是指将原本多台设备上的应用迁移到一台高端设备上,例如将原本4台2路的服务器整合到1台8路的服务器上。这种方式所带来的最大好处在于提升了管理性,这样在故障发生时就可以更高地定位故障发生点;同时降低了服务器总体数量。而且纵向扩展可以更为安全地将已有应用迁移到新的高端平台上,不会出现因为规划错误而引发资源紧张的情况。纵向扩展的劣势在于需要额外采购的大型服务器,这对于企业而言就是一笔开销,特别是在有大量服务器需要整合时。更好的一种做法是用户先对已有的应用进行充分评估(不是简单运行资源分析软件)。将应用分为两类,关键的核心应用,如财务、计费、客户关系等系统,和非关键应用,如邮件、网络门户等(对于不同类型的企业分类不同)。将核心应用部署在单独的服务器上以确保运行性能,并可以考虑部署集群环境。而将非核心也能够用运行在使用时间较长的计算池上,通过虚拟化软件的容错性确保系统不会宕机。在这一过程中,已有设备的使用状况,故障情况和服务器供应商维保期也是需要考虑的因素。