数据库服务器,并发用户在50人左右，中型ERP服务存储_百度知道企业内部服务器选取方案，用作ERP服务器。最多100人并发(30-80人)， 知道的大大们给一些建议，_百度知道责任编辑：河南亿恩
共有：0条评论网友评论：
亲，还没评论呢！速度抢沙发吧！查看:7105|回复：44
中级工程师
公司有两台服务器是暴露在公网下面，有被攻击过。公司现在也很注重这块，所以现想把网络安全搞上去，现就是服务器两台都在电信机房，公网，两台服务器实现内网，ERP和数据库连接，还有一个WEB是用来远程的，其中所有客房端都是远程到服务器的ERP办公，所以服务器上建了有一百多个用户名，现在服务器配置也不够用，当然还会办置新的服务器。公司用的是20M电信的专线，内网就是一个H3C的双网口路由器，下接深信服上网行为管理设备。现在想到了一种方法就是在服务器那里装个硬件防火墙，然后公司里也装个硬件防火墙，就是不知道哪种防火墙要好点，然后通过一个VPN的方式，公司走VPN通过防火墙，用ERP，这样的话服务器就不会那么吃力。现在想的就是这样。不知道技术圈里面的同伴们还有没有什么其它更好的意见，希望大家提出来，我对防火墙这块也没怎么接触过，希望大家多多给力，就是这个方案在五月份上旬就要出来，大家踊越回复。
(61.46 KB)
中级工程师
用防火墙主要就是为了保护服务器的安全，关闭所有些端口，只留些出来给数据的访问，图画得不怎么好，不好意思。
过了五一就要给方案了，希望大家多多给点意见，谢谢了。
中级工程师
有什么好的见意还可以跟我联系，QQ，谢谢、
中级工程师
:(bofu20): 等这么久都没一个回复的
中级工程师
难道就没有人能帮我看看
中级工程师
首先在电信机房的服务器是不是直接暴露在公网下面呢？还是你们得服务器直接放在公司，两个公网IP地址直接配置在服务器上面？你们是用远程终端访问你们的服务器还是怎样访问的？你要实现你们的数据安全？你问题是现在连问题都没有描述清楚！模模糊糊的，让别人怎么看懂呢？你们放在电信机房的服务器如果做好了安全防备，你们公司内部通过VPN连接，本来就不存在多少安全问题，全程安全加密！整个就在一个私网下面啊！
& && &&&不过我建议楼主：描述问题描述清楚一些，你的现状是什么？瓶颈是什么？具体出的问题是什么？想通过改造达到的目的是什么？详细的想法是什么？大家才能把自己的想法和建议跟你说啊！
一个人的生命应当这样度过，当他回首往事时，不因虚度年华而悔恨，也不因碌碌无为而羞愧！
中级工程师
你好，你哪里看不懂。我有画图的，看图看不懂吗
初级工程师
不明白，帮顶吧！等高手来解决
专注中小企业IT实施，构建最具性价 ...
显丑了:(pdd_19):
(139.47 KB)
高级工程师
LZ的那个图算拓扑图？
1，你的服务器为什么要暴露在公网上？
2，为什么要建立那么多账户，用远程桌面去ERP办公？
3，ERP是什么架构？为何不采用客户端或者WEB……
这是什么结构啊……
ＶＰＮ防火墙是可以解决你上面的问题，但是服务器依然很危险……
你这个是防内不防外啊……
如果服务器没有对外的服务，就直接放在局域网好得多。
有对外的比如ＷＥＢ之类的，放在电信，做好安全防护。必要的反入侵认证之类的要做。
ＥＲＰ服务器放在公网上，就是自己找事做了……
:(mars_17):
中级工程师
引用:原帖由 abcd 于
21:42 发表
你好，你哪里看不懂。我有画图的，看图看不懂吗 你自己问题都描述不清楚，还能怪谁，楼下好多人也看不懂啊！你这样也叫请教？
一个人的生命应当这样度过，当他回首往事时，不因虚度年华而悔恨，也不因碌碌无为而羞愧！
中级工程师
这之前就搞的，我也是刚进来、我叫放到内网上去，公司说会经常停电，对服务器不好。就这样子。
中级工程师
你有什么不明白的，说出来。我再改改
中级工程师
路由器的地址，跟服务器的地址不是同一网段的。建了很多来宾用户，还要加远程
中级工程师
你好，首先我说了，服务器在电信机房，然后还是暴露在公网下面。
& && & 还有我说了是远程进去的，然后才用ERP。ERP不是CS构架，就是所有的客户端进去，都是ERP服务端登录。你再看一遍吧。我不想跟你这样争论，没意思。
高级工程师
引用:原帖由 abcd 于
15:48 发表
这之前就搞的，我也是刚进来、我叫放到内网上去，公司说会经常停电，对服务器不好。就这样子。 做套电力系统就解决了……
现在这样只有做SSL VPN ，&&不过带宽会成为瓶颈。&&电信那边和你公司都配置一套SSL&&VPN，对连就可以了。
公司需要连接服务器就先ＶＰＮ连接后再像以前一样登陆服务器。
２，建议把ＥＲＰ做客户端登陆，避免用户直接远程ＥＲＰ服务器对服务器自身的更改造成误操作之类的。
３，多用户要进行权限管控和登陆日志。
或者走一根电信到公司的专线（估计成本比较贵哈哈）。:(bofu21):bofu21):& /&
现在机房稍微花点钱也可以做得专业一些……
服务器异地，而且又是做内网服务，很不好管控……万一出现故障什么的，排查和维护都很麻烦……:(bofu13):bofu13):& /&
本帖最后由 tankm1m2 于
16:06 编辑
中级工程师
现在就是在服务器那里加上硬件防火墙，然后做策略，开通一些必要的端口号。做VPN
公司放一台防火墙，通过VPN的一种形式，连接到服务器那里去，上ERP。
换一台新的服务器，把数据库放到新的那台服务器上，再跟ERP连接。这样可不可行。
或者说你们有没有什么更好的方法
中级工程师
是啊，我们公司这里七点就停电，然后服务器要等到零晨备份，其中还有就是各网点上的用户都要上班到9点。所以在电这一块真的不好搞。
中级工程师
现在的思路就是架两个硬件防火墙，走VPN。
然后服务器换一台配置高的
1）与其不断的上设备，不如在不影响正常使用的情况下，对架构做一个调整（找ERP售后）。
2）安全问题，既然你们是放在电信机房，那有入侵的发生极有可能是你们机器本身策略及制度出现了问题。不应该用加设备来掩盖这些。
3）预算问题，有想过按你的想法去实施，需要多少预算吗？
4）最后是你这个方案，在服务器端加一台VPN防火墙即可，用户拨入之后，该干什么干什么。客户端（公司本部）实在没必要在加一台防火墙了。可以找找看深信服是否有其它功能？
5）如果需要提升服务器性能，建议使用虚拟化技术。
6）个人谬论，如有不足之处，还请诸位多指正博客访问： 427857
博文数量： 1329
注册时间：
认证徽章：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： Linux
1、 前言当一个新的业务系统开发完成后，需要在一个区域乃至全国推广此应用软件，如何根据业务规模来选择服务器配置、内外置磁盘大小、以及网络带宽，是一件复杂的事情。一个最真实的评估，是建立一个接近真实业务应用的操作环境，进行各种压力测试，测算出不同的用户数量下，系统的响应时间和吞吐量，并得出当时服务器的各种资源的利用率情况，对硬件资源的完整评估，需要考虑下列三个方面：服务器性能的评估 客户端工作站或前端桌面的评估 通讯网卡和网络带宽的评估 如果不能建立准确的压力测试环境，需要根据工业界的Benchmark对服务器进行评估，推算出符合业务规模的服务器配置,同时要考虑在做系统管理时所消耗的资源，如在做备份、恢复、问题诊断、性能分析时、软件维护时都会对资源带来附加的消耗，对重要资源要考虑为将来留下升级和可扩展的余地，下列是一些通用的原则：处理器：要考虑高峰时的处理器的能力，并适当保留一些缓冲，确保在业务增长时，系统有扩展的余地。如果要保持快速的响应能力，应当为CPU保留20%至40%的富余量。 内存：要为运行在此服务器的所有应用软件考虑内存，所需要的内存主要依赖于用户数、应用程序类型、进程的方式、和应用程序处理的数据量决定。 磁盘：评估业务的实际用户的数据量，以此推算出磁盘的最小个数，不要忘记选择备份设备（如磁带机）。 IO槽：尽量保留更多的IO槽，防止将来插更多的PCI卡。 网络：选择合适的网卡，保证网络不是系统的瓶颈。 在评估数据库服务器性能时，最困难的事情是如何把握准确度问题，到底考虑哪些因素等。理想情况下，应考虑下列要素：交易的复杂性 交易率 数据读/写比例 并发连接数目 并发交易数目 数据库最大表的大小 性能度量的目标 根据各种Benchmark测试结果和对各种生产系统的检测，下表概括了CPU、磁盘、内存页面、网络和虚存页交换的利用率，可看出一个服务器如果其利用率保持在Good 所标示的范围内时，是一种理想的模式。2、 基于rPerf的推算，评估数据库服务器的CPUrPerf(Relative performance)是从IBM公司解析模型得出的商务处理性能估计值。该模型模拟部分系统的操作，如中央处理器、高速缓存和内存，该模型没有模拟磁盘和网络的输入/输出操作。虽然采用了一般数据库和操作系统的参数，但该模型不能反映出具体的数据库或AIX版本。除非单独说明，否则rPerf均在系统推出时估计。IBM pSeries 640-B80为基准参照系统，其值为本。虽然rPerf可用于比较商业处理性能，但实际的系统性能可能不同，取决于许多因素，包括系统硬件配置和软件设计与配置。评估数据库服务器的性能，需要理解交易的类型、高峰期的情况、用户数量、在高峰时每个用户的交易数量。假如在高峰时，有三种典型的交易类型：轻的、一般的、重的。需要知道高峰时，每种交易的并发用户数目。假定高峰时间为：10:00-11:00，每个用户的交易数目如下：轻的交易 =120 交易/用户一般的交易= 60 交易/用户重的交易 = 15交易/用户2.1、每个交易所使用的CPU秒评估出交易类型后，需要评估出运行每个交易所消耗的CPU秒，如果假定B80服务器每秒中支持10个交易，则每个交易需要消耗0.1个CPU秒。如果不知道如何评定CPU秒，则根据应用类型参照下列表。2.2、评估服务器所需的rPerf值服务器所需要的rPerf值=SUM(NU * TX * CS/PP) / MCNU:高峰时并发的用户数TX:高峰时每个用户的交易数量CS:在rPerf=1的服务器上，每个交易所需要的CPU秒PP:高峰持续的时间MC:最大的CPU利用率（推荐< 70%）下面举例说明如何计算所需的rPerf值，假定某公司的情况如下：业务高峰时间： 10:00-11:00=1Hour=3600秒交易类型： 无复杂查询的简单应用相对交易类型，用户数目分布:轻的=2000, 一般=50, 重的=5在高峰时，每个用户的交易数量：轻的=120交易/用户一般=60交易/用户重的=15交易/用户对于rPerf=1的服务器，每个交易响应的CPU秒轻的=1一般=3重的=15最大的CPU利用率：60%根据上述公式，可推算出不同交易类型所对应的rPerf值。轻的交易：NU*TX*CS/PP=/一般交易：NU*TX*CS/PP=50*60*3/重的交易：NU*TX*CS/PP=5*15*15/所需的总的rPerf/MC=(66.0+2.5+0.3)/0.7=98.3 rPerf3、基于TPC-C的推算，评估数据库服务器的CPUTPC-C基准是事务处理委员会建立的一个专门演示在线事务处理性能（OLTP）的性能基准，它的测量方法是为了使客户能够评估不同的在线事务处理系统的性能，这些事务进程于一个可控制的状态下在一个标准的数据库中运行。TPC-C测试包括5个典型的OLTP事务，它们是：新订单　：一个用户提交一个新的订单支付　　：更新用户的账户余额以反映一个支付交付　　：订单的交付（通过一个批事务处理实现）订单状态：返回用户最新订单的状态库存水平：监控当前仓库库存TPC-C的事务处理是在一个９个表的数据库上实现的事务处理过程包括：更新、插入、删除、终止，以及对主和次级键的访问,每种事务处理９０％的响应时间应小于或等于５秒，其中，库存水平的响应时间可以在２０秒以内。TPC-C的吞吐量值是终端活动水平的直接结果，如每一个仓库有10个终端，在每一个终端上上述5个事务都是可用的，一个远程的终端仿真器被用来在性能测试过程中进行必要的事务混合工作。这个混合代表着一个完整的订单商务处理流程：录入、支付、检验、交付。更专业的是，这个必要的混合被定义为产生一个相等数量的新订单和支付事务，以及在每10个新订单事务中产生一个交付事务，一个订单状态检验事务和一个库存水平检验事务远程终端仿真器也被用来测量每一个事务的响应时间，以及用来模拟键入时间及思考时间，键入时间是指在终端上录入数据所花费的时间，思考时间是指操作人员在终端读取事务的结果，进行下一个事务请求之前所花费的时间。每一个事物都有一个最小键入时间和最小思考时间。另外，这个响应时间必须在一个给定的极限值之下。TPC-C基准测试的结果--TPC-C的吞吐量（tpmC），代表的是系统的最大的持续性能，它被定义为系统每分钟可以处理多少个新订单事务，与此同时，系统还在处理其他四种事务类型（支付、订单状态、交付、库存水平）。所有５个TPC-C事务都有某个限定的用户响应时间要求，其中新订单事务的响应时间是５秒以内。因此如果一个系统的TPC-C值是100tpmC/min，说明该系统在每分钟处理其他的混合的TPC-C事务的工作的同时，可以产生１００个新订单事务。3.1、如何使用TPC-C进行服务器的评估由上可知，TPC-C测试基准主要用于测试主机服务器每分钟能够处理的联机交易笔数，测试产生的单位结果是TPM值（Transaction Per Minute，即每分钟处理的交易比数）。TPC-C虽然客观的反映了各个计算机厂商的系统处理性能，并且测试基准也在不断完善以更加贴近现实应用的交易环境，但是仍然无法与纷繁多样的各类实际应用完全吻合；而且参加TPC测试的主机系统都做了适当程度的系统优化。因此，在实际业务应用系统选择主机服务器乘载体时，必须考虑到多方面的因素，以最大程度的做到适合应用系统的生产需求。以下计算公式是IBM公司在金融综合业务系统的实际应用中总结的经验方法论，基本反映了金融业务特点对主机处理能力的需求：TPM=TASK x 80% x S x F / (T x C)其中：TASK：为每日业务统计峰值交易量T：为每日峰值交易时间，假设每日80%交易量集中在每天的4小时，即240分钟内完成：T=240。S：为实际银行业务交易操作相对于标准TPC-C测试基准环境交易的复杂程度比例。由于实际的金融业务交易的复杂程度与TPC?C标准测试中的交易存在较大的差异，须设定一个合理的对应值。以普通储蓄业务交易为例，一笔交易往往需要同时打开大量数据库表，取出其相关数据进行操作，相对于TPC-C标准交易的复杂度，要复杂很多；根据科学的统计结果，每笔交易操作相比较于TPC标准测试中的每笔交易的复杂度此值可设定为10~20。C：为主机CPU处理余量。实际应用经验表明，一台主机服务器的CPU利用率高于80%则表明CPU的利用率过高会产生系统瓶颈，而利用率处于75%时，是处于利用率最佳状态。因此，在推算主机性能指标时，必须考虑CPU的冗余，设定C=75%。F：为系统未来3~5年的业务量发展冗余预留。综上所述，为保障联机业务处理性能要求，我们可推算得出主机所需的处理能力，据此得出相应的机型和配置。4、举例说明，使用TPC-C进行数据库服务器评估下面针对XYZ行的网上银行业务的需求，我们进行数据库服务器的选型分析。由于目前XYZ行只有17个分行开通了网上银行业务，据我们估计，按照目前的客户数量，全部分行都开通网上银行业务后，总的客户数量可以达到10万。考虑INTERNET在我国的迅猛发展，客户数量的年增长率按照50%计算，那么，3年后的客户数量将达到10万×（1+50%）3≈34万。这些客户当中，至少有一半是个人客户，另一半是企业客户。企业客户的交易频率比较高，我们按平均每个企业客户每天做1.5笔交易计算；个人客户常用的交易是查询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4次交易；那么，每天的交易量就是：34万×50%×1.5+34万×50%×(4÷30) ≈28万笔假设网上银行的交易复杂度达到15，那么，每天的数据库操作数达到：28万×15=420万次高法诉讼费缴费：由于诉讼费的增长量不大，我们按年递增率5%计算。根据XYZ总行的统计，全国共37家分行，缴费量比较大的分行可以达到25000笔每月，占分行总数的20%；缴费量中等的省可达到15000笔每月，占分行总数的30%；缴费量小的省可达到7000笔每月，占分行总数的50%；按一个月20个工作日计算。这样，三年后每天的交易数量可以达到：（2000×30%+7000×50%）×37÷20×（1+5%）3≈28740笔我们假设高法诉讼缴费的交易复杂度达到13，那么每天的数据库操作达到：620次4.1、整体性能要求：总的数据库操作次数是：620=4573620假设每天的交易的80%集中在4小时内发生，那么高峰交易时间内每分钟的数据库联机交易次数为：%÷（4×60）≈15250要为将来陆续加入的应用预留40%的处理能力；另外，考虑到CPU的繁忙时间低于70%时，系统的性能较好，我们把这个比例定在65%。所以系统的TPC-C值应达到：15250÷（1－40%）÷65%≈390004.2、内存容量需求分析首先根据数据库容量算出所需的数据库缓存大小，再估计出操作系统、系统软件等所需内存，合计即是所需的内存容量。网银数据量分析：XYZ总行网上银行系统的数据库由CIF信息，交易日志、交易流水三部分组成。其中：CIF信息包括企业客户和个人客户信息，企业客户信息平均大小为20K左右，个人客户信息平均大小为5K左右；每一笔交易都要记交易日志，日志的平均大小为4K左右；每一笔转帐交易都要记交易流水，交易流水的大小为2K左右。这些客户当中，至少有一半是个人客户，另一半是企业客户。企业客户的交易频率比较高，我们按平均每个企业客户每天做1.5笔交易计算；个人客户常用的交易是查询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4次交易；那么，每天的交易量就是：所有的交易日志和交易流水都要保留三个月。由于个人客户的转帐交易非常少，可以忽略不计；假定企业客户的转帐交易占总交易量的70%。我们就可以计算网上银行对存储系统容量的要求：CIF信息容量=20K×（34万×50%）+5K×（34万×50%）=3.25GB+421MB ≈ 4GB交易日志容量=[34万×50%×1.5+34万×50%×(4÷30)] ×4K×30×3 =K×30×3 ≈95GB交易流水容量=（34万×50%×1.5）×70%×2K×30×3 ≈30GBXYZ网上银行总体数据容量要求：=4GB+95GB+30GB=129GB高法诉讼费数据量分析：高法的交易数据按要求要保留三年，每笔交易记录的大小为512字节，总体容量为：（2000×30%+7000×50%）×37×12×3×0.5K≈8.2GB因此，数据库的总数据量为： 129GB+8.2GB=137.2GB数据库系统在缓存容量达到数据库总容量的5%时性能较好，因此，数据库缓存大小为：6.86GB。从而计算出系统内存需求为：1. AIX操作系统所占的内存 128MB 2. 数据库管理系统所占的内存 256MB 3. 双机热备等系统软件所占的内存 128MB 4. 应用程序所占的内存 256MB 5. 数据库缓存 6.86GB 6. 合理的内存利用率 75% 总计 10GB 4.3、 存储容量需求分析除了上述的XYZ网上银行系统和高法诉讼费缴费系统的存储容量要求之外，还有异步查询下载服务的存储要求。异步查询下载服务每隔1小时生成一个下载数据包，每个数据包的大小为3MB，需要下载的数据包是上午十点生成的数据包，这个数据包需要保存2年，其它数据包只要保存3个月。因此，存储容量为：23×3M×30×3＋1×3M×365*2=6GB+2GB=8GB为避免存储系统成为系统性能的瓶颈，系统存储系统的使用率应小于40%，建议采用镜像方式存储数据，因此总的存储容量为：(137.2GB+8GB)÷40% ×2= 766GB
阅读(954) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。}