如何从头开始确定虚拟SharePoint服务器场的配置(compute resource, network和storage)
让我们来设想一下, 假设你被上级要求设计一个SharePoint场, 用于满足自己公司的需求. 那么, 你会怎么做呢?
首先, 摆在你面前的是一系列的问题:
1. 用实体机搭建还是选用虚拟机平台?
2. 我的需求究竟是怎么样的? 如果需要描述, 我可以把这份需求拆分成为几个方面的问题?
3. 我的服务器场需要怎样的拓扑逻辑(即服务器角色分配)?
4. 为我的服务器场分配多少计算资源(compute resource)? 如何分配?
5. 网络连接和可靠性如何得到保证?
6. 后端存储该如何设计才能既满足容量上的需求也满足性能上的需求?
7. 服务器场数据的备份还原该怎么做? 灾备呢?
8. 如何测试并确保这样的设计是可以满足我的需求的?
等等
这些问题有大有小, 自己动手独立回答起来有简单也有复杂, 简单的一句话, 复杂的可能你得动手写工具, 搭环境并进行测试上个把月.
在这篇文章里, 我们将逐一的探讨这些问题及其答案, 最后帮助你完成上级下发的设计服务器场的任务. 当然, 如果不差钱, 那就是另外一回事了. 我们的目标是经济实惠地完成服务器场的设计任务.
第一个问题, 实体机平台, 还是虚拟机平台
========================
在Cloud风起云涌的今天, 自己购买所有的硬件进行服务器端的搭建已经显的不够前卫了, 不是么? 今天, 越来越多的企业用户有迁移他们的服务器端软件到Cloud上. 如果说已经迁移了的企业用户是"前卫"的话, 那么用"过时"这个词来形容用实体机搭建服务器场是不是合适呢? 还是中庸一点, 选虚拟化吧.
虚拟化有很多好处, 唠叨起来几天也说不完. 简单来说有:
- 省钱 - 高效利用资源, 节约能源, 需要的硬件更少.
- 安全 - 备份, 还原, 灾备的实现更可靠,方便,灵活.
- 性能 - 通过多种技术保证虚拟化了的应用程序的高性能.
- 管理便捷 - 这点就不废话了, 都虚拟了, 都在一个地方集中配置和管理, 当然比登录到单独的物理设备上去改配置, 增添资源要简单得多.
SharePoint服务器场是个能利用虚拟化的这些好处的一个典型应用.
第二个问题, 明确自己的需求
========================
SharePoint服务器场的需求可以非常非常的多, 谁让SharePoint功能多可扩展性可定制性强呢! 但是要把一个场的具体配置定下来, 不可能所有方面都考虑到, 不现实. 这里列出来几个最重要的也是最必要的问题, 供你参考:
1. 一共有多少个用户?
2. 一个合理的最大并发用户数是多少?
3. 总容量大小的增长如何(年增长率)?
4. 初始总容量是多大(GB, TB)?
5. SharePoint场的主要用途是什么? 或者说哪一类的使用会比较多(文档协作比较多? 网页访问比较多? ).
6. 对SharePoint的搜索出来的内容的更新频率有无高要求?
这些问题的答案背后都对应着不同的配置设定, 是构建一个服务器场之前一定要弄清楚的. 举个简单的例子, 并发用户数的多少跟SharePoint服务器场的前端(WFE)的虚拟机的数量直接相关; 初始容量及其年增长率决定着后端存储需要用多大的磁盘来支持; 用户数, 重点使用类型, 对搜索的依赖与否, 都对CPU, Memory, 和Storage的分配起着重要的决定作用. 你可以有许多其他的需求, 比如说你有某种定制, 需要用SharePoint来做非SharePoint原生的内容的展现, 或者有Word Conversion的Service Application, 但是上面列出的这些问题是服务器场的设计者逃不掉的.
第三个问题, 确定SharePoint场的拓扑逻辑
========================
如果重视这个问题, 好好规划, 实施的话, 还是很有些内容可以谈的. 如果比较粗犷呢, 可以结合对自己服务器场规模的估计, 参照微软给出来的拓扑逻辑的例子照葫芦画瓢, 起码不会出大差错. 顶多就是浪费点资源.
微软出品的架构图列在下面:
还是觉得太模糊? 需要量化得清楚点? 推荐参照EMC的WhitePaper中介绍的并发用户数与WFE数量的对照表. 原表引用在这里.
你可能会问, 微软都没有给出过这样的建议, 这个图表是怎么做出来的? 怎么数字看起来如此精确? Publishing Portal是什么? Document Management Portal又是什么?
嗯, 别着急, 你的疑问很好, 让我们一个个的来解决掉它们吧.
先来了解一些术语, 以方便我们下面的讨论.
RPS - 为了保持文章简洁, 请暂时移步这里来查看关于这个定义的详细信息. 这篇文章还解释了VSTS的load test的结果与RPS的关系. 为了保持文章的完整性, 我会对这里的重要部分进行一下重申.
Green Zone: 代表着一种正常的状态, 即各种性能指标都处于比较健康的状态, 也代表着当前配置一直处于这种状态, 则可以认为当前配置处理日常的负载的峰值是没有问题的.
Red Zone: 代表着一种超负荷的状态, 许多性能指标都在峰值附近徘徊. 这种状态不可持续很长时间, 很快, 要么性能变的差的不可接受, 要么场的可靠性就会出现问题.
好了, 开始聊聊上面的数字吧. 测试SharePoint服务器场的某种配置能承担多大的负载是需要工具的. 我们选用微软的Visual Studio Team System.
创建一个Load Test Project, 并在其中添加各种你想要的测试场景, 比如说页面请求, 搜索关键字, 修改文档属性, 下载文档, Social互动等等. 可以在这里查看2007版的时候微软给出的一系列的测试类型,(2010和2013版中的更多, 比如Social).
然后, 设置测试条件, 使之满足Green Zone的条件, 开始测试. 运行一段时间也就稳定了. 测试过程中要保证是一直满足green zone的条件, 结束后你就会得到结果, 其中最重要的就是Test per second(TPS). 这里的TPS就是上面的RPS了.
有了RPS, 那么如何算出这对应着多少个用户呢? 请查看我之前的文章VSTS中测试出来的Test per second与Concurrent user number是什么关系.
简单来说在重度(Heavy)使用下, 用户数= TPS*60
通过一系列包括不同数量的WFE的测试, 我们就能得到每种WFE的数量能承受多少用户数, 这里的精确数字就是这么算出来的. 到这里你也许会问, 如果我的Hypervisor的CPU更强, 那岂不是可以支持更多的用户数? 答案是没错. EMC在这个测试中使用的是思科的Cisco UCS C260, 供你参考.
得到WFE的数目之后, 下一步你需要确定Application Server Role的虚机的配置. 这里其实要说清楚是很难的, 毕竟每个场里需要运行的service application 不一样, 更何况不少牛X的公司还自己开发Service Application. 多个service application可以挤在一台机器里, 一个service application也可以分散在不同的机器里运行. 对于一般的serivce application, 如果有需要就可以考虑添一台虚机运行它吧. 我们暂时先讨论每个场都会有的 – Search Service Application.
你可以参考上面列出的两个微软公布的topology的图例来设计自己的场. 总结一下, 你会发现再大规模的场, 其search的基本组成元素就是下面的两组虚拟机组合. 称之为组合就在于虽然search app 2013有6种组件, 但是在微软自己的设计当中, 这种是一种基本的固定组成搭配(4种). 建议你灵活的扩展你的search 拓扑结构时也采用同样的搭配方法, 可以让你的设计少走些弯路.
EMC的白皮书中(链接在文章最后的部分), 使用的是下面的角色组(2种)作为元素进行扩展的. 带有Query和Replica的称为Query组, 带有Crawl, Admin, Analytics, 和Content Processing的成为Crawl组.
之前谈到过, WFE的数目反映了活跃的在线用户数, 可以反映场的负载, 同时也可以反映搜索方面的负载. 经过测试(即如果某配置不能满足green zone的需求, 就扩展它), 可以得到这样的一张表.
| WFE数目 | Application Server数目(对search低要求) | Application Server数目(对search高要求) |
| 1 | 1 | 1 |
| 2 | 1 | 2(Query组, Crawl组各一个) |
| 3 | 2(Query组, Crawl组各一个) | 4(Query组, Crawl组各两个) |
| 4 | 2(Query组, Crawl组各一个) | 4(Query组, Crawl组各两个) |
| 5 | 2(Query组, Crawl组各一个) | 4(Query组, Crawl组各两个) |
第四个问题, 如何分配计算资源
========================
这个问题比较简单, 微软的文档Hardware and software requirements for SharePoint 2013有明确的说明.
我简要的列出重要的一些信息供你作为解决方案部署的一个起点, 之后你可以再观察一下自己的场的状况进行资源的增减.
Web Application Server
| Compute resource | Amount |
| CPU | 4 core |
| Memory | 12 GB |
Application Server
| Compute resource | Amount(Non Crawl) | Amount(Crawl) |
| CPU | 4 core | 12 core |
| Memory | 12 GB | 12 GB |
SQL Server – Standard I
| Amount(<1000 users) | Amount(>1000 users) | |
| CPU | 4 core | 4 core |
| Memory | 8 GB | 16 GB |
SQL Server – Standard II
| <500 GB | >500 GB, < 2 TB | > 2 TB | |
| Memory | 8 GB | 16 GB | 32 GB |
做一些解释, 在测试中, 带有Crawl角色的虚拟机需要非常多的CPU资源. 你可以选择采用微软推荐的角色组合, 保持其CPU个数4个不变, 但同时增加许多个运行着crawl组件的虚拟机, 也可以采用EMC经过测试了的角色分配, 并为其配置12核的CPU, 简化场配置和资源, 同时又能满足性能上的需求.
第五个问题, 网络连接和可靠性如何得到保证
===================================
这里给出一个简单的例子, 仅仅是个示意, 其中的产品如果你愿意用一样的就用, 不用那换成其他类似的也行.
这里值得注意的是每个点之间都至少有两条链路. 一条断了的话, 也还可以继续使用的. 当然, 如果预算够, 要求高, 也可以考虑再加链路.
第六个问题, 后端存储该如何设计才能既满足容量上的需求也满足性能上的需求
===================================
这个问题是本文的最重要也是最有价值的地方, 希望你能从中获得一些有用的知识.
大家都知道, IT发展到现在, CPU和内存对于企业级应用程序来说已经不那么容易成为瓶颈了. 戴尔, 思科, IBM, 等等厂商的主机的计算能力越来越强, 但是数据存储的能力却进步的没有CPU和内存那么快. 即使出现了全闪存阵列这种IO怪兽, 但高昂的成本和维护费用还是让不少企业犹豫的.
从前我遇到过很多问题, 排查下来发现WFE端处理请求和发送请求到数据库端很快, 数据库的CPU也不忙, 内存也够大, 但就是慢, 原因就是存储出现了性能问题. 作为应用程序层的专家, 对后端存储不了解是很正常的. 那么设想一下, 上万个用户的请求发进来, 你的Host再多, 再强, 如果你把所有数据都放在一块硬盘上, 那我想结果是不难猜出来的. 你需要把数据放在多块磁盘上, 然后这些磁盘一起提供数据, 这样才能满足你的需求. 那么如何组织这些磁盘, 这就涉及到了后端存储上的设计了.
让我们来看看对于一般的企业级高端存储, 该如何设计才能满足SharePoint的性能要求.
基础
===============
在我们开始之前, 你还需要了解一些东西, 那就是完成一个存储端的设计都需要些什么.
首先, 就是你需要描述数据读写的特性指标, 包括:
1. Throughput - 即吞吐量, 单位是IOPS (IO per second).
2. R/W - 即读写比.
3. IO Size - 即读写的大小.
4. Data size - 这个最好理解, 即数据一共有多大.
有了这些, 你还需要知道磁盘的RAID的类型以及它们的特性, 你可以移步这里来进行详细的查看.
推荐你查看一下EMC的白皮书SharePoint Best Practices中附录A, 其中有对SharePoint的数据访问特性的详细的测试结果和图表, 可以帮助你理解访问特性和进行后端存储的独立设计, 或者说, 拿来说服你的老板, 好让他也同意你的设计. ^_^.
在这里我列举几个SharePoint 2013的重要的IO访问特性的数据, 供你参考. SharePoint 2010的请查看白皮书附录A.
Content database in Crawl
-------------
|
Avg. peak read IOPS |
Avg. peak write IOPS |
Read I/O size (KB) |
Write I/O size (KB) |
Read/Write ratio |
|
3445 |
All read |
8 |
N/A |
All read |
Crawl database
-------------
|
Avg. peak read IOPS |
Avg. peak write IOPS |
Read I/O size (KB) |
Write I/O size (KB) |
Read/Write ratio |
|
260 |
200/40 |
8 |
32 |
29:11 |
Read
Write
Index Partition during crawl
-------------
|
Avg. peak read IOPS |
Avg. peak write IOPS |
Read I/O size (KB) |
Write I/O size (KB) |
Read/Write ratio |
|
150 |
35 |
2048 |
1024 |
3:2 |
Read
Write
虽然我上面推荐的文章你都看一下肯定可以得出结论, 但是为了节省你的时间和照顾文章的完整性, 我还是在这里简要的把重点都说一下.
SharePoint用到的原生数据可以大致包含:
- 内容数据库(Content Database)
- 各种Service Application数据库(Serivce app DBs)
- Search Serivce Application所需的文件索引(Index for Search)
- MySite数据库
- 数据库的Transaction log日志文件
基于测试, 你可以得到这些数据的访问特性, 包含访问数据的大小, 读写比, 吞吐量峰值等等. 这些知识加上不同RAID的特性, 你就不难得到这样的存储设计了.
| Data | RAID | 特点 |
| Content Databases | 5 | 随机读比较多, 写相对少, 但性能要求也不低 |
| Service Application Databases | 10 | 随机写与读的量相差不大, 对写入操作的性能要求较高. |
| My Site | 6 | 个人站点, 读写都比较少, 对容量的要求会比较大. |
下一步, 让我们再来看看不同种类的磁盘吧. 请移步这里来查看更多更详细的磁盘种类的信息. 这里的文章中最后列出的表格给出的只是不同种类的磁盘的大致的性能指标, 在不同的存储机柜上, 或者在不同的应用环境中, 这些值都是不大一样的. 但是, 文中的表格可以让你了解他们之间的区别大致是怎样的.
基本设计
================
结合访问特性, RAID知识, 磁盘类型这些知识, 那么你就不难得到这样的SharePoint的后端存储的典型设计了.
| Data | Storage | 其他选择 |
| Content Databases | RAID 5(4+1) SAS | FAST VP(RAID 6 NL-SAS + RAID 10 EFD) |
| Service Applicaiton | RAID 10(4+4) SAS | RAID 10(2+2), RAID 10(3+3) |
| My Site | RAID 6(6+2) NL-SAS | RAID 6(6+2), RAID 6(8+2) |
下面的图就是以Hyper-V和VMware为Virtualization 平台做出的存储的设计.
细心的你会发现, 这里我给出的Content database pool里还有RAID 6. 这是针对用户非常少的场给出的设计, 因为用户数特别少(同时在线不超过六百人)的场, RAID 6(6+2)基本就能满足要求了. 当然, 如果你的存储本身就比较弱, 那么恐怕还是得用RAID 5的. 这个设计可以满足EMC VSPEX的最新一代(时至2014.4)的产品.
你可能还会问, 在上面的表格中"其他选择"的部分, 写了的FAST VP是什么?
这里写的FAST VP是在EMC存储产品上高效利用闪存盘(Flash, EFD)的一种技术. 其核心就是让最经常访问的数据放在访问速度最快的闪存盘上. 继续说下去那么就涉及到数据访问的skew值, 数据挪动的频繁程度, 数据挪动的数据块的大小等等技术细节了. 你可以查看Design Guide: EMC VSPEX for Virtualized Microsoft SharePoint 2013中对于带FAST VP的SharePoint 后端存储的设计, 其核心就是通过NL-SAS+EFD的FAST VP组合来达到省钱却并不降低整体性能的目的. 说多了容易让你走神, 或者睡着, 好, 咱们继续.
Size你的设计
=================
好了, 你想好了你的SharePoint场content DB要用RAID 5(4+1), 可是到底使用5块盘好呢, 还是15块盘好呢, 还是20块盘好呢?
你的service application的部分是用RAID(4+4), 可是到底是8块盘好呢, 还是16块盘好呢?
这里就面临着将你的设计确定大小的问题了. 那么, 首先, 你面临的就是估计你的访问量, 和了解相应RAID类型下不同盘数所能支持的访问量了.
呵呵, 你有两种选择:
1. 自己搭环境, 做不同的存储用以支持你的SharePoint场, 跑测试. 看看哪种设计适合你.
2. 使用EMC solution team根据他们已经跑过的测试的结果做出来的EMC VSPEX Sizing Tool. 你可以使用自己的邮箱免费注册一个帐号, 之后就可以使用这个工具了. 输入你的需求, 然后你就会得到一份符合你需求的从应用到存储的设计解决方案.
假设你是一个有志青年(还得有钱, 有闲), 不愿意用人家做好的现成的sizing的工具, 非要自己做才放心. 没问题! 让我们一起来大致领略一下该怎么做吧.
磨刀不误砍柴工, 你需要一些工具来帮助你完成这项颇艰巨的任务.
- Bulk Loader – Create Unique Documents based on Wikipedia Dump File
- Load Bulk Content to SharePoint 2010 – Upload documents to SharePoint
- SharePoint Performance Testing - Sample code for SharePoint performance testing
用这些工具先基于维基百科生称文档, 之后再将文档上传到SharePoint的数据库中. 这样你就有了测试环境的数据源, 而且基本上搜索啥关键字都会有个结果的, 酷炫呀.
之后呢, 用Performance testing sample code project在VSTS中进行压力测试. 你可以自己再写一些新的test scenario来丰富你的测试, 这里就不多做介绍了.
工具都有了, 测试可以开始了, 那么该怎么测呢?
上面我们已经谈到了VSTS中的RPS与SharePoint的同时在线用户数的关系, 具体请看这里. 通过这知识, 我们就可以把测试结果RPS与SharePoint的用户负载关联起来了.
测试的方式如下:
1. 给出一种场的拓扑配置, 同时给定一种存储设定.
2. 调整测试目标. 比如WFE的CPU利用率在百分之60-70.
3. 运行测试, 监控指标. 比如说, 每项测试的时间都必须在两秒以内结束(这是网页用户感觉站点还可以的能够忍受的延迟), 失败的测试的比率等等.
4. 得出测试结果.
5. 计算这种配置能承受的在线用户数.
EMC的solution team得出了SharePoint 2013的如下的WFE与能承受的在线用户数的线性关系, 省下你的测试了不是么?
好了, 现在如果你得知了你的场的用户数, 那你就可以得到你的场应该有的前端的数量了. 结合微软给出的diagram, 你就可以得到一个瓶颈绝对不在应用层的设计了.
下面就是评估后端存储的部分了.
从high level来看, 大致的步骤如下:
1. 从SQL上收取performance log, 查看其中的host IOPS的量.
2. 从host IOPS结合RAID的种类, 计算出backend IOPS的量.
3. 根据不同的后端存储系统得到不同种类的磁盘所能承受的最大的单盘IOPS, 然后做一个除法, 得到所需要的最少的盘数, 在Roundup到RAID组的盘数的倍数.
EMC的解决方案小组, 搭建了各种测试环境, verify了各种不同的后端的配置, 从而得到了SharePoint的Sizing tool.
篇幅有限, 关于Backup and Restore和data protection的部分, 请你查阅一下EMC的白皮书Design Guide: EMC VSPEX for Virtualized Microsoft SharePoint 2013. 这里就不做的更多的介绍了.
EMC Whitepapers
===================================
Design Guide: EMC VSPEX for Virtualized Microsoft SharePoint 2013
Implementation Guide: EMC VSPEX for Virtualized Microsoft SharePoint 2013 with VMware Vsphere
Implementation Guide: EMC VSPEX for Virtualized Microsoft SharePoint 2013 with Microsoft Hyper-V
Microsoft SharePoint Server: Best Practices and Design Guidelines for EMC Storage
Reference
===================================
Performance and capacity test results and recommendations (SharePoint Server 2013)
http://technet.microsoft.com/en-us/library/ff608068.aspx
Technical diagrams for SharePoint 2013
http://technet.microsoft.com/en-us/library/cc263199(v=office.15).aspx
Technical diagrams (SharePoint Server 2010)
http://technet.microsoft.com/en-us/library/cc263199(v=office.14).aspx
Technical diagrams and other supplemental documentation(2007)
http://technet.microsoft.com/en-us/library/cc263199(v=office.12).aspx