大数据量_高效存储_新技术探析_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
&&¥1.00
&&¥3.00
&&¥3.00
&&¥0.50
喜欢此文档的还喜欢
大数据量_高效存储_新技术探析
阅读已结束，如果下载本文需要使用
想免费下载本文？
把文档贴到Blog、BBS或个人站等：
普通尺寸(450*500pix)
较大尺寸(630*500pix)
你可能喜欢1959人阅读
NOR和NAND都是闪存技术的一种，NOR是Intel公司开发的，它有点类似于内存，允许通过地址直接访问任何一个内存单元，缺点是：密度低（容量小），写入和擦除的速度很慢。NAND是东芝公司开发的，它密度高（容量大），写入和擦除的速度都很快，但是必须通过特定的IO接口经过地址转换之后才可以访问，有些类似于磁盘。
我们现在广泛使用的U盘，SD卡，SSD都属于NAND类型，厂商将flash memory封装成为不同的接口，比如Intel的SSD就是采用了SATA的接口，访问与普通SATA磁盘一样，还有一些企业级的闪存卡，比如FusionIO，则封装为PCIe接口。
SLC是单极单元，MLC是多级单元，两者的差异在于每单元存储的数据量（密度），SLC每单元只存储一位，只包含0和1两个电压符，MLC每单元可以存储两位，包含四个电压符（00,01,10,11）。显然，MLC的存储容量比SLC大，但是SLC更简单可靠，SLC读取和写入的速度都比MLC更快，而且SLC比MLC更耐用，MLC每单元可擦除1w次，而SLC可擦除10w次，所以，企业级的闪存产品一般都选用SLC，这也是为什么企业级产品比家用产品贵很多的原因。
SSD的技术特点
SSD与传统磁盘相比，第一是没有机械装置，第二是由磁介质改为了电介质。在SSD内部有一个FTL(Flash Transalation Layer)，它相当于磁盘中的控制器，主要功能就是作地址映射，将flash memory的物理地址映射为磁盘的LBA逻辑地址，并提供给OS作透明访问。
SSD没有传统磁盘的寻道时间和延迟时间，所以SSD可以提供非常高的随机读取能力，这是它的最大优势，SLC类型的SSD通常可以提供超过35000的IOPS，传统15k的SAS磁盘，最多也只能达到160个IOPS，这对于传统磁盘来说几乎就是个天文数字。SSD连续读的能力相比普通磁盘优势并不明显，因为连续读对于传统磁盘来说，并不需要寻道时间，15k的SAS磁盘，连续读的吞吐能力可以达到130MB，而SLC类型的SSD可以达到170-200MB，我们看到在吞吐量方面，SSD虽然比传统磁盘高一些，但优势虽然并不明显。
SSD的写操作比较特殊，SSD的最小写入单元为4KB，称为页(page)，当写入空白位置时可以按照4KB的单位写入，但是如果需要改写某个单元时，则需要一个额外的擦除（erase）动作，擦除的单位一般是128个page（512KB），每个擦除单元称为块（block）。如果向一个空白的page写入信息时，可以直接写入而无需擦除，但是如果需要改写某个存储单元（page）的数据，必须首先将整个block读入缓存，然后修改数据，并擦除整个block的数据，最后将整个block写入，很显然，SSD改写数据的代价很高，SSD的这个特性，我们称之为erase-before-write。
经过测试，SLC SSD的随即写性能可以达到3000个左右的IOPS，连续写的吞吐量可以达到170-200MB，这个数据还是比传统磁盘高出不少。但是，随着SSD的不断写入，当越来越多的数据需要被改写时，写的性能就会逐步下降。经过我们的测试，SLC在这个方面要明显好于MLC，在长时间写入后，MLC随机写IO下降得非常厉害，而SLC表现则比较稳定。为了解决这个问题，各个厂商都有很多策略来防止写性能下降的问题。
wear leveling
因为SSD存在&写磨损&的问题，当某个单元长时间被反复擦写时（比如Oracle redo），不仅会造成写入的性能问题，而且会大大缩短SSD的使用寿命，所以必须设计一个均衡负载的算法来保证SSD的每个单元能够被均衡的使用，这就是wear leveling，称为损耗均衡算法。
Wear leveling也是SSD内部的FTL实现的，它通过数据迁移来达到均衡损耗的目的。Wear leveling依赖于SSD中的一部分保留空间，基本原理是在SSD中设置了两个block pool，一个是free block pool（空闲池），一个是数据池（data block pool），当需要改写某个page时（如果写入原有位置，必须先擦除整个block，然后才能写入数据），并不写入原有位置（不需要擦除的动作），而是从空闲池中取出新的block，将现有的数据和需要改写的数据合并为新的block，一起写入新的空白block，原有的block被标识为invalid状态（等待被擦除回收），新的block则进入数据池。后台任务会定时从data block中取出无效数据的block，擦除后回收到空闲池中。这样做的好处在于，一是不会反复擦写同一个block，二是写入的速度会比较快(省略了擦除的动作)。
Wear leveling分为两种：动态损耗均衡和静态损耗均衡，两者的原理一致，区别在于动态算法只会处理动态数据，比如数据改写时才会触发数据迁移的动作，对静态数据不起作用，而静态算法可以均衡静态数据，当后台任务发现损耗很低的静态数据块时，将其迁移到其他数据库块上，将这些块放入空闲池中使用。从均衡的效果来看，静态算法要好于动态算法，因为几乎所有的block都可以被均衡的使用，SSD的寿命会大大延长，但是静态算法的缺点是当数据迁移时，可能会导致写性能下降。
因为SSD的erase-before-write的特性，所以就出现了一个写入放大的概念，比如你想改写4K的数据，必须首先将整个擦除块（512KB）中的数据读出到缓存中，改写后，将整个块一起写入，这时你实际写入了512KB的数据，写入放大系数是128。写入放大最好的情况是1，就是不存在放大的情况。
Wear leveling算法可以有效缓解写入放大的问题，但是不合理的算法依然会导致写入放大，比如用户需要写入4k数据时，发现free block pool中没有空白的block，这时就必须在data block pool中选择一个包含无效数据的block，先读入缓存中，改写后，将整个块一起写入，采用wear leveling算法依然会存在写入放大的问题。
通过为SSD预留更多空间，可以显著缓解写入放大导致的性能问题。根据我们的测试结果，MLC SSD在长时间的随机写入后，性能下降很明显（随机写IOPS甚至降低到300）。如果为wear leveling预留更多空间，就可以显著改善MLC SSD在长时间写操作之后的性能下降问题，而且保留的空间越多，性能提升就越明显。相比较而言，SLC SSD的性能要稳定很多（IOPS在长时间随机写后，随机写可以稳定在3000 IOPS），我想应该是SLC SSD的容量通常比较小（32G和64G），而用于wear leveling的空间又比较大的原因。
数据库IO特点分析
IO有四种类型：连续读，随机读，随机写和连续写，连续读写的IO size通常比较大（128KB-1MB），主要衡量吞吐量，而随机读写的IO size比较小(小于8KB)，主要衡量IOPS和响应时间。数据库中的全表扫描是连续读IO，索引访问则是典型的随机读IO，日志文件是连续写IO，而数据文件则是随机写IO。
数据库系统基于传统磁盘访问特性来设计，最大特点是日志文件采用sequential logging，数据库中的日志文件，要求必须在事务提交时写入到磁盘，对响应时间的要求很高，所以设计为顺序写入的方式，可以有效降低磁盘寻道花费的时间，减少延迟时间。日志文件的顺序写入，虽然是物理位置是连续的，但是并不同于传统的连续写类型，日志文件的IO size很小（通常小于4K）,每个IO之间是独立的（磁头必须抬起来重新寻道，并等待磁盘转动到相应的位置），而且间隔很短，数据库通过log buffer（缓存）和group commit的方式（批量提交）来达到提高IO size的大小，并减少IO的次数，从而得到更小的响应延迟，所以日志文件的顺序写入可以被认为是&连续位置的随机写入&，瓶颈还是在IOPS，而不是吞吐量。
数据文件采用in place update的方式，意思是数据文件的修改都是写入到原来的位置，数据文件不同于日志文件，并不会在事务commit时写入数据文件，只有当数据库发现dirty buffer过多或者需要做checkpoint动作时，才会刷新这些dirty buffer到相应的位置，这是一个异步的过程，通常情况下，数据文件的随机写入对IO的要求并不是特别高，只要满足checkpoint和dirty buffer的要求就可以了。
SSD的IO特点分析
1.随机读能力非常好，连续读性能一般，但比普通SAS磁盘好。
2.不存在磁盘寻道的延迟时间，随机写和连续写的响应延迟差异不大。
3.erase-before-write特性，造成写入放大，影响写入的性能。
4.写磨损特性，采用wear leveling算法延长寿命，但同时会影响读的性能。
5.读和写的IO响应延迟不对等（读要大大好于写），而普通磁盘读和写的IO响应延迟差异很小。
6.连续写比随机写性能好，比如1M顺序写比128个8K的随即写要好很多，因为随即写会带来大量的擦除。
基于SSD的上述特性，如果将数据库全部放在SSD上，可能会有以下的问题：
1.日志文件sequential logging会反复擦写同一位置，虽然有损耗均衡算法，但是长时间写入依然会导致性能下降。
2.数据文件in place update会产生大量的随机写入，erase-before-write会产生写入放大。
3.数据库读写混合型应用，存在大量的随机写入，同时会影响读的性能，产生大量的IO延迟。
基于SSD的数据库优化法则：
基于SSD的优化就是解决erase-before-write产生的写入放大的问题，不同类型的IO分离，减少写操作带来的性能影响。
1.将sequential logging修改为In-page logging，避免对相同位置的反复擦写。
2.通过缓存写入的方式将大量的in-place update随机写入合并为少量顺序写入。
3.利用SSD随机读写能力高的特点，减少写增加读，从而达到整体性能的提升。
In-page logging
In-page logging是基于SSD对数据库sequential logging的一种优化方法，数据库中的sequential logging对传统磁盘是非常有利的，可以大大提高响应时间，但是对于SSD就是噩梦，因为需要对同一位置反复擦写，而wear leveling算法虽然可以平衡负载，但是依然会影响性能，并产生大量的IO延迟。所以In-page logging将日志和数据合并，将日志顺序写入改为随机写入，基于SSD对随机写和连续写IO响应延迟差异不大的特性，避免对同一位置反复擦写，提高整体性能。
In-page logging基本原理：在data buffer中，有一个in-memory log sector的结构，类似于log buffer，每个log sector是与data block对应的。在data buffer中，data和log并不合并，只是在data block和log sector之间建立了对应关系，可以将某个data block的log分离出来。但是，在SSD底层的flash memory中，数据和日志是存放在同一个block（擦除单元），每个block都包含data page和log page。
当日志信息需要写入的时候（log buffer空间不足或者事务提交），日志信息会写入到flash memory对应的block中，也就是说日志信息是分布在很多不同的block中的，而每个block内的日志信息是append write，所以不需要擦除的动作。当某个block中的log sector写满的时候，这时会发生一个动作，将整个block中的信息读出，然后应用block中的log sector，就可以得到最新的数据，然后整个block写入，这时，block中的log sector是空白的。
在in-page logging方法中，data buffer中的dirty block是不需要写入到flash memory中的，就算dirty buffer需要被交换出去，也不需要将它们写入flash memory中。当需要读取最新的数据，只要将block中的数据和日志信息合并，就可以得到最新的数据。
In-page logging方法，将日志和数据放在同一个擦除单元内，减少了对flash相同位置的反复擦写，而且不需要将dirty block写入到flash中，大量减少了in-place update的随机写入和擦除的动作。虽然在读取时，需要做一个merge的操作，但是因为数据和日志存放在一起，而且SSD的随机读取能力很高，in-page logging可以提高整体的性能。
SSD作为写cache&append write
SSD可以作为磁盘的写cache，因为SSD连续写比随机写性能好，比如：1M顺序写比128个8K的随机写要好很多，我们可以将大量随机写合并成为少量顺序写，增加IO的大小，减少IO(擦除)的次数，提高写入性能。这个方法与很多NoSQL产品的append write类似，即不改写数据，只追加数据，需要时做合并处理。
基本原理：当dirty block需要写入到数据文件时，并不直接更新原来的数据文件，而是首先进行IO合并，将很多个8K的dirty block合并为一个512KB的写入单元，并采用append write的方式写入到一个cache file中（保存在SSD上），避免了擦除的动作，提高了写入性能。cache file中的数据采用循环的方式顺序写入，当cache file空间不足够时，后台进程会将cache file中的数据写入到真正的数据文件中（保存在磁盘上），这时进行第二次IO合并，将cache file内的数据进行合并，整合成为少量的顺序写入，对于磁盘来说，最终的IO是1M的顺序写入，顺序写入只会影响吞吐量，而磁盘的吞吐量不会成为瓶颈，将IOPS的瓶颈转化为吞吐量的瓶颈，从而提升了整体系统能力。
读取数据时，必须首先读取cache file，而cache file中的数据是无序存放的，为了快速检索cache file中的数据，一般会在内存中为cache file建立一个索引，读取数据时会先查询这个索引，如果命中查询cache file，如果没有命中，再读取data file（普通磁盘），所以，这种方法实际不仅仅是写cache，同时也起到了读cache的作用。
SSD并不适合放数据库的日志文件，虽然日志文件也是append write，但是因为日志文件的IO size比较小，而且必须同步写入，无法做合并处理，对SSD来说，需要大量的擦除动作。我们也曾经尝试把redo log放在SSD上，考虑到SSD的随机写入也可以达到3000 IOPS，而且响应延时比磁盘低很多，但是这依赖于SSD本身的wear leveling算法是否优秀，而且日志文件必须是独立存放的，如果日志文件的写入是瓶颈，也算是一种解决方案吧。通常情况下，我还是建议日志文件放在普通磁盘上，而不是SSD。
SSD作为读cache&flashcache
因为大部分数据库都是读多写少的类型，所以SSD作为数据库flashcache是优化方案中最简单的一种，它可以充分利用SSD读性能的优势，又避免了SSD写入的性能问题。实现的方法有很多种，可以在读取数据时，将数据同时写入SSD，也可以在数据被刷出buffer时，写入到SSD。读取数据时，首先在buffer中查询，然后在flashcache中查询，最后读取datafile。
SSD作为flashcache与memcache作为数据库外部cache的最大区别在于，SSD掉电后数据是不丢失的，这也引起了另外一个思考，当数据库发生故障重启后，flashcache中的数据是有效还是无效？如果是有效的，那么就必须时刻保证flashcache中数据的一致性，如果是无效的，那么flashcache同样面临一个预热的问题（这与memcache掉电后的问题一样）。目前，据我所知，基本上都认为是无效的，因为要保持flashcache中数据的一致性，非常困难。
flashcache作为内存和磁盘之间的二级cache，除了性能的提升以外，从成本的角度看，SSD的价格介于memory和disk之间，作为两者之间的一层cache，可以在性能和价格之间找到平衡。
随着SSD价格不断降低，容量和性能不断提升，SSD取代磁盘只是个时间问题。
Tape is Dead，Disk is Tape，Flash is Disk，RAM Locality is King.&&&&&&& Jim Gray
后续，我还会整理一个PPT，并提供一个技术分享。
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：2575681次
积分：29254
积分：29254
排名：第76名
原创：328篇
转载：430篇
评论：1202条
(2)(2)(18)(4)(7)(4)(10)(10)(2)(2)(3)(2)(1)(3)(8)(7)(4)(3)(5)(1)(3)(2)(1)(3)(5)(2)(3)(1)(2)(3)(4)(3)(3)(1)(5)(3)(1)(6)(1)(3)(1)(2)(3)(3)(7)(2)(1)(5)(3)(5)(4)(3)(1)(2)(3)(2)(3)(6)(4)(2)(6)(3)(4)(5)(2)(1)(5)(2)(4)(3)(2)(2)(2)(3)(9)(7)(6)(6)(5)(4)(9)(7)(2)(7)(6)(5)(2)(6)(8)(7)(4)(7)(11)(2)(4)(7)(10)(12)(21)(7)(23)(9)(13)(15)(21)(21)(17)(11)(11)(6)(6)(10)(22)(21)(28)(8)(2)(4)(3)(3)(9)(36)(7)(8)(4)(5)评测导购 >
数据库系统方案设计
&&佚名丨 14:05 &
系统总体结构图
根据数据中心形式的信息数据库建设需求分析，系统总体结构（图 11-2）描述如下： 本项目的存储网络架构图，通过 SAN 能够将多种数据应用全面整合起来，其中后端的阵列是整个系统的核心，所有的业务数据都存在该阵列中，因此阵列本身需要完全冗余架构和极高的吞吐性能；SAN 网络采用 dual Fabric设计，采用两台交换机构成冗余的存储网络；每台主机（关键业务）可以采用两块（甚至更多）HBA 跨接到两台 SAN 交换机上，做的主机到存储接口冗余；主机层采用 HA配置，因此整个系统是高效而全冗余的。同时也能够平滑过渡到下阶段的容灾系统。
图 11-2& 数据中心建设概况
备份系统也跨接到 SAN 网络上，这样所有的备份工作可以大大减轻对于生产网络的影响，主机直接通过 SAN 将数据读出并写到带库，完全采用 FC/SCSI 协议。 在上述架构中，后端的磁盘阵列采用高性能磁盘阵列，作为综合存储磁盘阵列。该磁盘阵列代表当时行业的最佳性能、100%数据可用性，以及功能丰富的管理软件。
数据库服务器设计
数据库系统结构
数据库服务平台主要采用动态分区、多机集群、并行数据库等技术，实现多台数据库主机同时并行访问数据库，应用可以根据需求均衡到不同主机资源上同时工作，多机互为备份。这种机制依靠系统提供的系统硬件、操作系统集群软件、与数据库提供的并行技术来满足要求。数据库支持数据分区技术，通过数据库分区技术提高查询效率。同时，与数据库服务平台相配合，采用专用数据采集处理服务器，负责数据采集工作，各数据库的数据采取分别汇集，单点入库的数据更新策略。
数据库服务器系统图如下：
图 11-3& 数据服务器示意图，以 IBM 产品为例
数据库服务器选用高性能 UNIX 服务器，每台& 高性能 UNIX 服务器划分成 2 个分区，每个分区配置 8 路 1.7GHz CPU、16GB 内存、2 块千兆光纤网卡、2 块15000转 73G硬盘、2 块 2GB 光纤通道卡。对应分区通过 HACMP 软件实现群集。根据设计要求：“当前配置tpmC =(TPMC基准值* 实际CPU数目*& 实际CPU主频)/ (基准 CPU 数目*基准 CPU主频)” (768,839*16*1.7)/(32*1.7)=384,420tpmC数据来源 www.tpc.org
存储系统设计
存储系统结构
图 11-4& 网络存储结构图
上图为数据存储部分的系统架构示意图。 整体架构采用 SAN-存储局域网的架构搭建，分为主机、交换机和存储设备三个层面：
1、主机层面
前端服务器每台通过两块光纤卡（以下简称 HBA 卡）跨接到两台光纤交换机上，构成冗余链路；
2、光纤交换机
利用两台 16口光纤交换机作为 SAN 的骨干设备，连接主机和存储设备；
3、存储设备
主存储设备：核心磁盘阵列存储所有系统的数据。该磁盘阵列通过 1对（2 块）接口卡分别跨接到两台光纤交换机上，构成冗余链路 近线存储设备：近线备份目标磁盘阵列使用采用 STAT磁盘的廉价磁盘阵列，离线备份目标带库采用设计方案已有的带库。
主存储系统方案
目前存储区域网（SAN）是解决海量存储问题的主流解决方案，也是本项目建设要求的解决方案，同时也支持 NAS 方式。数据中心形式的信息数据库建设数据库及其应用系统相关的数据库即将统一存储到大容量高性能的存储设备上，存储设备与主机群之间通过 SAN光纤交换机互联（具有冗余联接），同时数据备份设备也通过光纤交换机联接以提高备份效率，减轻网络和主机的压力。在本方案中，存储工程师使用高档全光纤磁盘阵列为主存储系统，从用户的投资、需求综合分析，推荐了极佳的性能价格比的产品，用户可以根据性能要求、扩展性要求、价格需求等因素来选择。 根据数据中心形式的信息数据库建设该设计的需求，为了提高主磁盘阵列的性能，在该设计中推荐配备 15000RPM 的 73GB磁盘。
磁盘阵列在各方面均应充分扩展，并能够充分满足今后业务发展过程中数据迁移、系统容灾的要求：1）硬件方面 所有重要部分均应在线扩容――前端接口、磁盘控制卡、缓存、磁盘等。 2）软件方面 可选择不同的软件实现性能优化、数据迁移和数据容灾等：管理软件&& 安全控制软件&& 数据缓存化软件&&& 性能管理套件&& 本地镜像软件&& 容灾软件&& 多链路负载均衡和故障切换软件 3）所有维护和扩容均应在用户现场、不中断应用的情况下完成&
近线备份系统
传统的数据存储一般分为在线(On-line)存储及离线(Off-line)存储两级存储方式。所谓在线存储就是指将数据存放在磁盘系统上，而离线则是指将数据备份到磁带上。硬盘的优点是速度快，特别是随机访问能力强，但单位容量成本高，适合需要频繁访问的数据存储；磁带善于传输流式数据，介质与驱动器相分离的特性决定了其单位容量成本低廉，保存数据的安全性也较高，适合数据备份。 但随着数据量的猛增，这种只使用在线和离线两级存储的策略已经不能适应企业的需求。
一方面，用户有越来越多的数据在一定时期内仍需要访问，如果备份到磁带上，则读取的速度太慢，而保持在线状态，又会因访问频度不高而占用宝贵的存储空间；另一方面，用户要求“备份窗口”越来越小，备份设备要具有更快的速度，以缩短备份时间，而带基设备与盘基设备相比还不够快。由此产生了数据的分级存储管理（HierarchicalStorageManagement，HSM）。分级存储管理是一种将非在线存储与在线存储融合的技术。它以数据生命周期的不同阶段来决定存储的位置，从而在在线存储与离线存储之间诞生了第三种存储方式――近线(Near-line)存储，使存储网络从“在线－离线”的两级架构向“在线－近线－离线”的三级架构演变。近线存储的特点是性能接近在线存储，而成本接近离线存储。
根据大型信息数据库存储系统分析结果，存储容量约为 16TB，考虑适当冗余和“快照”备份，存储阵列实配容量应大于 20TB，存储阵列最大扩展容量应不低于 64TB。 基于存储区域网技术，满足数据中心形式的信息数据库建设数据库和应用系统相关数据库，以及运行于其上的业务系统、查询系统、数据分析系统的要求，必须增强数据存储核心，选择高性能存储阵列，LUN 数量应≥2048，系统 IOPS≥240000（吞吐量大于 1540 M/S）。
其基本性能需求分析如下：
1、在存储系统中，处理器主要完成 I/O 处理、Cache 控制管理、数据传输控制以及一些智能化的软件运行功能，处理器的能力直接影响到整个存储系统的性能。考虑到不同厂商存储所采用的 CPU 性能差异较大、主处理器所承担的任务也有所区别，应在给出实际处理器配置数量的同时给出性能指标、承载任务分析，CPU 实配数量不低于 16 个。
2、磁盘本身性能也决定存储系统整体性能，通常磁盘性能以转速、寻道时间等技术指标衡量，考虑到性价比，推荐采用 15K rpm的磁盘。
3、对于数据库等大数据量访问应用，缓存越大，性能越好，本项目实配存储容量应与Cache 的容量配置成比例配置，按大于 16GB考虑，最大可扩展到 128GB。
负载均衡系统设计
考虑到系统的高并发访问量和系统应用需求的快速增长，项目建设明确制定了 Web 服务层、应用服务层规划：走横向扩容、持续发展的道路，以服务器群、交易中间件满足不断增长且趋于复杂化的用户访问请求、提高访问处理和响应能力。
遵循这一规划，Web 信息发布层、应用服务层考虑了以下因素：1、支持横向扩容的负载均衡器。 2、提高系统可靠性的集群或热备技术应用 3、各层服务器本身构架、性能、配置要满足需求。
本系统中采用业界领先的全千兆负载均衡解决方案：（千兆光纤端口＋千兆以太网端口） 方案中，可以采用两台 IP 应用交换机 BIGIP& 安全流量交换机 6400 作为冗余，为中间件服务器和应用服务器做负载均衡，并且 SSL 加速功能。所有服务器均配置冗余千兆网卡。与两台 BIGIP6400 相连，这样无论是其中的一个服务器网卡故障还是一台 BIGIP6400 故障，都不影响业务的正常运行。
图 11-5 负载均衡设计图
方案的特色：实时监控服务器应用系统的状态，并智能屏蔽故障应用系统&& 实现多台服务器的负载均衡，提升系统的可靠性&& 提供服务器在线维护和调试的手段&& 可以对服务器提供流量限制和安全保护
应用服务器、浏览服务器和数据处理前置机设计
应用服务器层主要负责业务逻辑处理，用户请求的连接处理和数据库端或其他应用系统的连接处理，以及业务处理过程实现。用户多层体系结构要求应用服务器与 Web 服务器物理独立，考虑到应用服务器对处理能力、系统稳定性的要求均大大高于数据表现层，关键应用采用 Unix服务器，其他应用可考虑刀片式微机服务器，建立多机集群环境。 本方案中间一的应用服务器采用中档 UNIX 服务器，实配单台处理能力不低于70000tpmC，中档 UNIX 服务器& 采用4 路1.45GHz CPU（可扩≥8 路），8GB 内存（可扩≥64GB），73G 硬盘 2 块，4 块千兆光纤网卡。浏览服务器群和数据处理前置机采用工业级刀片服务器，每台配置2路Xeon MP2.7GHz CPU（可扩≥4 路），8GB 内存，2 块 73GB 硬盘，2 块 2GB 千兆光纤通道卡。系统架构中该层面应不少于 2 台小型机，4 台微机服务器，以满足峰值下信息访问的需求。
【编辑推荐】
戴尔透露闪存服务器细节 虚拟SAN上日程 摩擦渐消 EMC将ScaleIO纳入VMware内核 解析：iSCSI、FCoE和FC的性能比较 光纤通道――SSD存储之王 华为存储OceanStor V3引领传统企业IT变革 什么是富士通“Data Center-focused”的ICT产品？ 百万用户规模的系统如何扩展 如何给Win7系统下的硬盘分区 大海捞针 数据中心存储系统应如何使用 硕讯联盟（ERAS GROUP）推出万兆IP统一存储系统
今日微信独家
《华尔街日报》报道日前援引知情人士的消息称，由于被美国政府以国家安全问题为由进行调查，联想斥资23亿美元收购IBM低端服务器业务的交易陷入了停滞状态。
关注新浪官博
订阅微信订阅号
订阅焦点周刊
论坛与活动
看DELL微视频，赢大奖！
51CTO旗下网站}