配置exchange2010邮箱和邮件大小限制
配置邮箱和邮件大小限制
A、邮箱大小设置
emc---组织配置---双击mailboxdatabase---限制
邮箱大小默认限制为2.4g，当大小超过1.99g的时候会发出警告，超过2.09g时限制发送，超过2.4g时禁止接受
B、传输单个邮件大小的限制。单个文件的大小受到两种限制，首先是客户端outlook上面的限制，邮件中的附件总大小受到服务器的限制，但是邮件中的一个附件的大小受到outlook的限制。outlook2007限制邮件中单个附件最大为150M，outlook2010中限制单个附件最大为10M。其次是一个单独的邮件的大小限制。
邮箱大小---邮件大小---单个附件大小的例子如下：
邮箱大小为16g-----单个邮件最大为3g---邮件中最大的单个附件为150M（附件个数不限）
设置方法：
1）、设置单个附件大小。这是邮件限制里面的最高权限，它与服务器无关，只和outlook相关。
2）、使用者信箱传送大小的限制和接收大小的限制
3）、全局限制
4）、接收连接器
5）、发送连接器
6）、OWA 2010 (Web.configfile)的上传大小限制（仅对使用web进行传输时起作用）
设置方法：
1）客户端设置
outlook2007貌似是150M上限，outlook2010貌似是10M上限。。。。。，需要添加以下键值。（outlook2010是14，outlook27是12）不限制单个附件的大小。
Windows Registry EditorVersion 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Preferences]
&MaximumAttachmentSize&=dword:
从2）到5）之间的权限相等，以最小值来限制单个邮件的大小
默认全局及连接器都是限制10MB，如果安装好exchange2010后未设置邮件大小，则单个邮件的大小默认值会被限制在10MB。
2）、使用者邮箱传输大小的限制和接收大小的限制，不用修改，保持默认的不限制就好了，单独设置了邮箱传输大小限制是无法发送大邮件的，它是限定条件之一。如果要修改
emc---收件人配置---双击收件人---邮件流设置---双击邮件大小限制
3）全局限制，单独设置了全局限制是无法发送大邮件的，它是限定条件之一。
emc---组织配置---集线器传输---全局设置---双击传输设置---修改最大接收大小和最大发送大小，单位为kb，50M就是51200
在emshell中的命令为（注意空格）：
set-transportconfig-MaxReceiveSize 50mb -MaxSendSize 50mb
也可以分成两条命令来写
set-transportconfig-MaxReceiveSize 50mb
set-transportconfig-MaxSendSize 50mb
4）、接收连接器，单独设置了接收连接器是无法发送大邮件，它是限定条件之一
emc---服务器配置---集线器传输---接收连接器---双击显示出来的两个接收连接器---修改最大邮件大小
在emshell中的命令为
首先使用get-receiveconnector得到所有的接收连接器的名称（其实就是在emc中接收连接器看到的名称）
set-receiveconnector&default 你服务器的名称& -MaxMessageSize 50mb
set-receiveconnector&client 你服务器的名称& -MaxMessageSize 50mb
5）、发送连接器，单独设置了接收连接器是无法发送大邮件的，它是限定条件之一
Exchange2010的发送连接器在默认安装情况下，在安装集线器传输服务器角色或边缘传输服务器角色时，不创建任何显式发送连接器，而是使用基于ActiveDirectory 站点拓扑自动计算的隐式发送连接器在集线器传输服务器之间以内部方式路由邮件。在exchange2010的默认安装中，在emc上是看不到发送连接器的，即使使用exshell的get-sendconnector命令也看不到。
只有当配置边缘传输服务器订阅到AD之后，才能自动建立一个可见的发送连接器。面向Internet 的集线器传输服务器或未订阅的边缘传输服务器必须手动配置发送连接器。所以我们必须要手动添加后再配置它。
关于发送连接器的介绍参阅
/zh-cn/library/aa998662(EXCHG.140).x
默认的隐藏发送连接器能够发送的邮件大小，貌似是30mb，要修改这个数字最好是新建一个发送连接器，然后修改邮件大小。
emc---组织配置---集线器传输---发送连接器---新建---名称输入一个好记简短的---预期用法选内部---点添加---勾选包含所有子域（）---成本保持默认1---确认---不要勾选“作用域发送连接器”---下一步---添加智能主机---填入ip地址或者主机名称---不要勾选“使用传输服务器上的外部dns查找设置”---下一步---身份验证保持默认“无”---下一步，会将默认的服务器显示出来---下一步---建立。
上面步骤的说明：
预期用法选项，一共有四项，自定义一般用来给不是exchange的服务器发送邮件；内部是给域内用的；internet需要用到dnsmx记录来路由；伙伴是给纳入了安全域列表的伙伴域的服务器用的。我是内部使用，所以选了第二项内部；
添加，如果直接点添加就默认使用smtp，如果点添加旁边的小三角，可以指定类型。我选择直接点添加；
地址，可以用通配符*，*.,*.com或者是fqdn完全的地址；
包含所有子域，如果地址中使用了通配符，点击确认后会自动勾选包含所有子域；
成本，可以写1-100，在具有多个发送连接器时，成本越小越优先。
作用域发送连接器，限制发送连接器的作用域，勾选后只给域内传输服务器使用，我保持默认没有勾选。
智能主机，可以用exchange服务器的ip地址（例如192.168.1.61）或者是fqdn（）.
使用传输服务器上的外部dns查找设置，不使用网卡dns设置上面的dns，而是用dns列表中的dns才勾选它。
建立好之后，在em shell中才能使用命令get-sendconnector，看到刚才建立的发送连接器。
现在开始设置发送连接器的邮件大小
emc---组织配置---集线器传输---发送连接器---双击方才建立的连接器---勾选最大邮件大小---51200表示50Mb
在emshell中的命令为（假设建立的连接器名字叫做ABCD）
set-sendconnector ABCD-maxmessagesize 50mb
建立发送连接器，并设置邮件大小的em shell命令为
New-SendConnector -Name&ABCD& -Usage internal -AddressSpace &*.;5&,&*.;8& -DNSRoutingEnabled $false-SmartHosts 192.168.1.61 -MaxMessageSize 50MB
建立名字叫做ABCD的发送连接器
用法是内部 internal（还可以选择输入custom，internet，partner）
地址设置了两个，*.，开销是5；*.，开销是8
不使用dns路由，而是使用192.168.1.61这个智能主机路由
设定邮件大小为50mb
6）、在C:\ProgramFiles\Microsoft\ExchangeServer\V14\ClientAccess\Owa目录里找到clientaccess\owa找到web.config打开修改maxRequestLength修改后面的数值，默认是30000（30M），修改它。
使用以上六步后，就可以完全开放邮件大小限制了。
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'最近在测试Lync 2010和Exchange 2010，发现lync2010的有的时候,右下角角标提示与exchange连接错误,只是lync在外网登陆的时候才会有，但网Lync客户端不会提示，该Lync 2010错误提示如下:Lync2010错误：Lync遇到exchange连接问题。Lync将尝试修复连接，直到连接完全还原。在连接还原前，记录、语音邮件以及与Outlook有关的功能可能不可用或过期。这个问题很有可能是Lync客户端无法正确正确联系exchange auto discover或者EWS 导致的，这个时候我们就需要先测试EXchange autodiscover，我测试我的outlook 2010是正常的。（对着outlook客户端按住CTRL+右键，选择测试电子右键自动即可），可以看出结果是正常的这个时候打开lync的客户端，发现如下问题，在客户端的EWS外部URL中，出现了如下问题：从上图中可以看出，我们的exchange 在为exchange配置自动发现EWS外部URL的时候，出现了一个错误：将EWS的目录中/EWS/exchange.asmx，输入成了aspx，也就造成了lync在外网 登陆 提示这个连接错误了（写的比较简单，不过我想我大概说明白了）微信公众号：centoscn
Exchange2010备份与恢复工具之Win Server Backup
& & &最近开始搞Exchange邮件及其他应用系统的备份和容灾方案。想到一些中小型企业对于自身的数据安全不是太重视，同时出于成本考虑，也很难上一台相对完善的备份系统。出现问题后，KB的还是我们这些“攻城狮”和“民工”。因此在这里给大家分享一下如何使用Windows Server Backup对Exchange进行备份与恢复的方法。在不增加额外成本的前提下这个还是比较实用的。废话不多说了，走起。。。
& & &在windows2003和Exchange2003时,IT人员可以直接使用系统内置的NT backup来作为Exchange的备份还原工具。到了windows2008和Exchange时代，由于没有了NT backup，开始逐渐采用第三方的备份软件进行备份管理，如symantec的NBU、BE或者微软的DPM等。
在Windows2008和Exchange2010中，虽然windows2008中没有了NT backup工具，但是我们可以使用全新的windows server backup工具搭配Exchange2010全新的Recovery Database（RDB）功能，轻松完成用户邮箱数据库的备份与还原工作。
& & &需要注意的是Exchange2010不再支持对数据库的流式备份，只支持VSS备份；Windows Server Backup 对DAG成员不支持VSS Write（即不支持对DAG副本备份还原）。
一般来说，使用Windows server backup对Exchange2010的主动节点进行备份即可。DAG本身就是一种数据库备份技术，一般来说对被动节点进行备份的需求并不高。同时建议只在小规模的Exchange环境中使用，大中型Exchange环境建议考虑第三方的备份工具。
一、 安装Windows Server Backup
在Exchange2010 Mailbox服务器上安装Windows Server Backup。在服务器管理器中右键点击功能，选择添加功能。
选择Windows Server Backup。
点击“安装”。
二、禁用Exchange服务器的VSS Writer（没有使用DAG的可跳过）
如果Exchange服务器加入了DAG组，需要在Exchange服务器上禁用VSS Writer。
禁用的方法如下图所示，首先在Exchange服务器上运行regedit，定位到HKEY_Local_Machine\Software\Microsoft\Exchangeserver\v14\replay\parameters，选择新建一个DWORD键。
键名设置为EnableVssWriter，键值设置为0。
然后将Exchange服务器上的Microsoft Exchange Server Extension for Windows Server Backup服务类型设置为自动，启动此服务。
三、备份Exchange邮件数据库
Exchange服务器中有一个数据库mdb01，mdb01数据库在两台Mailbox服务器上都有一个副本，mdb数据库中有一个用户邮箱user2。
启动Windows Server Backup，我们使用Windows Server Backup备份数据库。
选择“一次性备份”。（生产环境中一般会设置备份计划）
选择“其他选项”。
自定义备份内容。
本例中我们备份mdb01数据库所在的文件夹即可。生产环境中，一般是直接备份Exchange数据库所在的卷。
点击“高级设置”
VSS设置要设为“VSS完整备份”，这样备份完成后Exchange才可以自动截断事务日志。如果不能截断事务日志，事务日志会增长得非常迅速，有可能导致磁盘空间不足。
确认要备份的内容无误，点击“下一步”继续。
备份可以保存在服务器本地的卷，也可以保存到远程共享文件夹。
本例选择本地的 E盘
注: 一般来说，Window Server Backup不允许将备份结果存储到源数据所在的卷。如果一定要保存到源卷，那么需要在Exchange的服务器中的注册表HKEY_Local_Machine\System\CurrentControlSet\Services\wbengine\SystemStateBackup中添加一个名为AllowSSBToAnyVolume的键值，键类型为DWORD，内容设置为1。
点击“备份”。
备份完成。
四、用户邮箱环境准备
备份前user3的邮箱内容如下图所示，邮箱中共有2封邮件。
备份后user3对邮箱做了误删除操作，邮箱中只有一封邮件了。
备份后user3又收到了一封新的邮件
我们的测试需求是，user2需要从之前的备份中恢复被误删除的邮件，同时要保留备份后收到的新邮件。要解决这个问题，需要利用Exchange2010的邮箱恢复数据库，将user2之前备份的邮箱内容和当前的邮箱内容进行合并。
五、创建RDB恢复数据库
备份完成后，不能直接用备份恢复当前的邮件数据库，这样会导致所有用户的邮箱内容都受到影响。正确的做法是利用备份创建Exchange的恢复数据库，然后将恢复数据库中的用户邮箱和当前用户邮箱内容进行合并。
Windows Server Backup的备份并不能直接创建RDB数据库，需要将备份还原到备用位置，然后利用EMS命令创建出RDB数据库。
首先在Exchange的EMC控制台中暂停DAG复制。在mdb01服务器上选择“搁置数据库副本”。
选择“是”。
在Exchange服务器上运行Windows Server Backup，选择“恢复”。
选择恢复到此服务器。
选择合适的备份数据进行恢复。
选择恢复“文件和文件夹”。如果备份时包括了Exchange2010所在的卷，则还原时可以选择“应用程序”类型。无论选择恢复应用程序还是文件和文件夹，对恢复的结果没有影响。
选择要进行恢复的文件夹
选择将备份还原到C:\RDB目录。
点击“恢复”。
恢复完成，点击“关闭”。
恢复数据已经被复制到D:\RDB目录。
在Exchange的EMS中运行
New-MailboxDatabase -Recovery -Name "RDB" -Server BJRENNEX03 -EdbFilePath "e:\rdb\mdb\mdb.edb"
CLogFolderPath "e:\rdb\mdb\"这条命令是在Exchange服务器上创建一个名为rdb的恢复数据库，数据库文件是e:\rdb\mdb\mdb.edb，数据库日志则位于e:\rdb\mdb目录。
注意提示：如果要mount恢复数据库，要确保恢复数据库出于干净关闭状态。
这是因为我们新建的数据库RDB是连接的现有的Exchange邮箱数据库。
六、合并邮件
恢复数据库在mount之前，要确保数据一致性。正确的做法是在挂载数据库之前，将数据库日志commit到数据库。
打开恢复数据库日志文件夹，可以看到日志文件都以E04开头。
在Exchange服务器上打开Exchange Management Shell，进入RDB数据库目录，执行
eseutil.exe /R E04 /I /D
这条命令是将rdb中的日志commit到rdb中的数据库文件。
Commit日志后，在Exchange的EMS中运行
eseutil.exe /mh E:\RDB\mdb\mdb.edb 来查看数据库的状态
如果State显示为Clean shutdown，则数据库处于干净关闭状态；如果State显示为Dirty shutdown,则数据库还需要使用Eseutil /r进行软修复或使用eseutil /p进行硬修复。
完成后，打开EMC管理控制台对恢复数据库RDB进行挂载
挂载恢复数据库之后，在Exchange服务器的EMS中运行
restore-mailbox CIdentity user3 CRecoveryDatabase rdb
这条命令的作用是将恢复数据库中的user3邮箱内容和当前的user3邮箱进行合并。
命令执行完成后
接下来一user3身份登录OWA，查看user3的收件箱。
可以看到恢复了备份后误删除的邮件，同时也保留了备份后收到的新邮件。
最后对mdb数据库的副本执行恢复数据库复制的操作，至此，数据库还原完成。
此种方式结合windows server backup的备份计划完全能够满足小规模exchange环境的邮件备份恢复操作，而且不需要额外的成本投入，嘻嘻^_^
不过对于大中型exchange环境，建议还是上一套第三方的备份或者容灾系统，毕竟邮件系统对于企业来说是相当重要的。
------分隔线----------------------------
本文介绍对Exchange存储有关的知识可能存在的误区，包括现实的场景以及误区的场景都有...bisheng.hu 的BLOG
用户名：bisheng.hu
文章数：69
评论数：599
访问量：337402
注册日期：
阅读量：3416
阅读量：282852
阅读量：1009977
阅读量：155598
51CTO推荐博文
&&& 相比之前的Blog更新速度，最近应该算很久没有写新的东西了。一方面是工作的事情太多，另一方面也主要是在学习和研究。现在工作上的事情，相对轻了一些，而且，也该总结一点东西了。&&& 所以现在，我尽可能的将前一段时间的一点心得，总结于此。算是对自己的总结，也为路过的朋友提供一点参考。
&&& 那么第一个，就来谈谈DAG这个东西。
&&& DAG(Database Availability Groups)：数据库可用性组技术使Exchange Server 2010在高可用性方面得到进一步简化与完善，借助于多台服务器间的连续复制，可为用户提供高可用性的Exchange邮箱。这看似只是一项简单的改进，但实际上，与前代版本相比，这是一个非常大的进步，它使用户无需借助复杂的技术与高昂的设备，就可以获得高可用性。(此段摘自于)&&& 相信对Exchange2010有所了解的人肯定会知道这项重大的改变。相比一些其他的所谓的新功能、新体验来说，这项位于系统核心的数据结构和服务器结构上的变化，我个人觉得，可能意义更为重大一些。到底有何意义，又为何重大，我们暂且不论。先来一些理性的分析看看。
&&& 无论是中文名字“数据库可用性组”还是英文名字“Database Availability Groups”，我们都可以看到，它们是由三个部分组成：D-数据库、A-高可用、G-组。那么我们就从这三个方面来个全面的认识。
&&& D-数据库&&&&这个数据库从本质上，它是一个位于硬盘上的文件，相信这点绝对没有歧义。那么这么一个本质的东西能有什么值得关注的呢？有，那就是容错方式。&&& 相信大家都知道在Exchange2007的时候，有两种用于高可用性的技术，LCR和CCR。LCR是通过在本地创建一个数据库的副本，而CCR是在一个Failover Cluster的备份节点上创建一个数据库副本。这两种方式可以任选一种，或者组合使用。&&& 好处不必多说，之前实际接触过的朋友，自然清楚。不大了解的朋友，也能通过搜索来获取到非常丰富的信息。这里只谈谈不足之处，也就是促使微软在Exchange2010里做出改进的地方。&&& 下面列举一二：&&&&&&& LCR、CCR只能用于MB角色&&&&&&& LCR无法支持主机级容灾，换句话说，如果是主机掉电或者物理网卡失败，无论本地有多少个数据库副本，均无法实现高可用。&&&&&&& CCR必须构建于Windows Failover Cluster之上，随之带来诸如无法实现异地容灾；或者某一节点上的某一DB失败，导致所有DB全部发生切换操作；以及永远都有至少一个未被实际利用的备份节点服务器资源；等等。&&& 为了解决这些问题，在Exchange2010中，结合了以前的CCR和LCR想法。在DAG中，数据库的容灾，完全基于DB级或者说是服务级，与windows是否实现cluster无关。换句话说，有点类似于SQL的数据库镜像。它是通过数据库日志的方式，同时在几个数据库镜像上写入相同的数据，且有一套机制来保证所有镜像副本上的操作一致性。数据库镜像最多可以创建16个，在这些镜像中，有一个是出于活动的对外提供服务，其余的全部用来备用。而这每一个镜像副本，分别放置在可用性组中的不同服务器上。&&&&这样做的一个最大的好处就是，最为关键的邮箱数据库服务，不会受到任何其他层面的影响，而只会关注某一个数据库的状态是否可用。它不关心数据库文件是放在哪里，放在什么样的存储设备上，也不关心Windows是否实现了高可用，更不关心网络是否通畅。只要它发现某个应该提供服务的数据库副本无法提供服务了，就立刻会启动另外一个副本进行工作。并且只是针对这一个邮件数据库而已，如果同一个服务器上的其他副本的数据库服务正常的话，它们将不会被切换走。&&& 另外，脱离Cluster，就更容易实现异地灾备的解决方案了。理论上，DAG的数据库镜像，并不关心这些服务器是否在同一个地点，它们之间只要保证必要的链路带宽，保证数据库日志的有效复制，就可以实现高可用了。当然，具体的带宽，目前我也没有去测过。留个作业给大家把。&&& 数据库的结构如此，其实只是一个基础。至于怎么被切换，才是关键，下面就看看高可用性是如何实现的了。
&&& A-高可用&&& DAG中所实现的高可用，简单来说，是两个层面的工作。一个是数据库服务的监控，第二个，其实还是使用了Windows底层的MSCS（MS Cluster Service），只是可以不需要将Windows搭建成Cluster环境而已。&&& MSCS就不单说了，就是个底层的Windows服务，随便一搜，就能搜到好多。这里我们主要谈谈服务的监控和切换的实现。&&& 在此之前，我觉得有必要提一下Exchange2010中服务器角色架构的改变。其中最大的改变就是CAS，因为以前MAPI方式的客户端是直接连接到MB角色上的。而在Exchange2010中，CAS接管了所有方式的客户端连接，包括MAPI方式的连接。&&& 在活动邮箱数据库副本上会运行 Information Store, CI, Assistants等服务，而每个DAG中的服务器上都会运行一个叫Active Manager的组件（貌似它就是基于MSCS之上的一个东西）。在CAS角色上，有一个叫RPC Client Access的东西。&&& 在它们之间又形成了一个C/S结构，CAS是C，MB是S。通过CAS上的RPC Client Access服务，如果它发现MB上的这个服务有任何的闪失，它将通过Active Manager的配合，找到另外一个副本进行连接。并且Active Manager会将那个备份副本，启用成活动副本。&&& 这样，一个服务的快速切换，就完成了，不过其实大概需要30秒左右。如果凑巧此刻没有用户在收发邮件的话，可能就是一次神不知鬼不觉的切换了。如果碰上老大正在发邮件，被卡了的话，30秒好像也不是很严重，不过提前编好3套以上的解说词比较靠得住。。嚯嚯。。&&& 当然，有人肯定会问，如果CAS出现故障，不就歇菜啦？确实如此！！我很负责的告诉大家，如果CAS不可用了，就等着电话被打爆吧。。。呵呵。。不过还好的一点是，Exchange2010除MB以外的所有角色均支持NLB，所以在这个问题上，比Exchange2007要好解决多了。
&&& G-组&&& 最后，我们再来看看这个用来做数据库载体的“组”，是个什么东西。&&& 其实很简单，它就是一堆服务器的集合。这个集合所起的作用是明确资源的边界，明确管理的边界，仅此而已。&&& 如果还不太明白，我们就来一个著名的比喻吧。。组就是一张茶几，上面放满了“杯具”。。杯具就好比我们的服务器节点，数据库副本就是水，你可以把水倒入这张茶几上的任意一个或者多个杯具里（提示：DAG中最多只能倒16个），但你没有办法把水倒在这张茶几以外的杯具里面。换句话说，如果你希望用另外一个杯具来盛水，那你必须先把它放到这个茶几上来。&&& 大致可以这么认为，但其实DAG中，服务器节点和组的情况要比这个比喻复杂。准确来说，是一个茶几上放了好几套杯具，注意是套，不是个，因为一套可能有好几个杯具组成，而每一套里的杯具可以分别放入不同的饮料。所以一个服务器节点，其实相当于一套杯具。因为在一个服务器中，可以放入多个不同的数据库副本，并且允许它们有些是活动的，有些是其他节点上的备份副本。
&&& 谈到这里，算是把DAG大致了解了一下。概括来说，它就是通过类似SQL的数据库镜像技术，实现了邮件数据库的高可用性。从而避免了对Windows Cluster的依赖，也简化了高可用的实现方式。这就是DAG的意义所在。
&&& 至于意义是否重大，还要看不同的企业，不同的需求，不见得DAG就能适用于所有的场景。
&&& 其实明眼人可能已经看出其中的猫腻了，对，就是存储！！如果没明白过来的人，可以算笔帐。如果在Exchange2007下使用CCR的方式实现高可用性的话，我们算一下如果数据库是1个G的大小，最终我们需要多少个G的存储空间。其实很简单，就是1个G。因为即使是多节点的Cluster，由于我们可以使用共享存储机制，所以，实际支出的存储空间，只有共享存储中的那1个G而已。。
&&& 但是如果是DAG呢？乖乖隆嘀隆啊！！有几个副本，所需要的空间就翻多少倍！因为DAG是不关心你底层数据存储方式的，不管是本地硬盘、直连存储、还是网络存储，也不管你的存储级别是否已经提供了冗余机制。
&&& 不过以微软自己的说法，这种方式也有它的好处，因为DAG的机制，加上Exchange2010中邮件数据结构的变化，使得I/O大量减少，且提高了数据存储的效率。所以使得用户可以使用更为廉价的直连存储，甚至是SATA的本地硬盘来作为邮件系统的存储解决方案。暂且不说是否坏了好多存储硬件厂商的好事，对于中小型企业来讲，这确实是一件非常好的事情。
&&& 但是，对于一些大型或者超大型企业来说，他们可能已经在早期做出了规划，并投入了SAN或者别的存储解决方案。而且对于他们来说，垂直型的IT架构分解，对于管理来说是非常有必要的。那么对于这些企业来说，DAG将绝对是个噩梦。。现在唯一能做的，就是通过配置不同的RAID，来提高存储的使用率。。
&&& 如何取舍？相信每个老百姓心里都有自己的一杆称。。。
&&& 最后贴个示意图，相信大家都能看明白。。
650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)' alt="" src="/attachment/129886.png" border="0" />本文出自 “” 博客，转载请与作者联系！
了这篇文章
类别：┆阅读(0)┆评论(0)
17:05:08 11:38:49 10:07:35 17:34:01 16:36:25 09:31:19 10:33:26 15:19:22 14:18:32 09:25:16