大规模文件存储OSS技术与实践
在进行机器数以及相关硬件进行评估时,需要考虑流量峰值的情况,我们一般以正常流量的2到3倍来进行规划,比如,某个分中心的流量为每秒1300Gb,那么我们设计时就需要考虑峰值的情况,也就是最大能支撑每秒3900的流量。 3.2 集群的设计目标基于上面描述的项目现状,经过分析,我们的整个OSS集群需要实现以下设计目标: 1. 各中心采用Tomcat集群来支撑数据流量 2. 各中心的流量均衡打到每台Tomcat服务器 3. 负载均衡设备的高可用 4. 存储服务的稳定性 3.3 最佳实践3.3.1 如何保证Tomcat单机的性能最优我们主要从以下几个方面来优化Tomcat的性能: 1)JVM内存大小 2)最大线程数(maxThreads) 3)最大连接数(maxConnections) 4)全连接队列长度(acceptCount) 我们选用单台机器来测试Tomcat的性能,硬件配置如下: Tomcat的版本选用8.5.43。 测试的目标: 1. 单台Tomcat支持的最大并发数 2. 单台Tomcat支持的最大TPS 3. NIO模型和APR模型的性能对比 测试工具使用:ApacheBench。 我们使用对比测试的方法,分别测试在上传1KB,10KB,100KB,1M,10M,100M的时候,Tomcat各项指标的数值。 Tomcat配置:maxThreads=100,minSpareThreads=10,acceptCount=102400,maxConnections=1000000,acceptorThreadCount=2JVM配置:-Xmx16384m -Xms16384m-Xmn1024m -XX:+UseConcMarkSweepGC -XX:MaxPermSize=256m 1、使用NIO模型的测试结果如下: 根据以上测试结果可得出以下结论: 1)在上传相同文件大小的情况下,随着并发数的增大,会出现一定的丢包情况; 2)在相同并发量的情况下,随着上传文件大小增大,吞吐量会随之下降。 2、使用APR模型的测试结果如下: 根据以上测试结果以及对比NIO模型的测试结果,我们可以得出以下结论: 1)小文件上传APR模式不如NIO模式,大文件上传APR模式要好于NIO模式; 2)随着并发的增加,TPS先增加后减少,平均响应时间不断增加; 3)小文件应该关注TPS,大文件应该关注平均响应时间; 4)小文件TPS大概在2万到3万之间,能接受的并发在300到500之间。 3.3.2 如何保证HBase存储的稳定性HBase以高吞吐著称,那么我们应该如何在保证高吞吐的情况下,能保证稳定的存储。主要应该关注两个点: 1)GC的次数以及停顿时间; 2)HBase的compaction机制。 3.3.2.1 GC调优由于HBase是使用Java编写的,所以垃圾收集(GC)对HBase的影响也是很大的,我们需要适当调整GC相关的参数,使得HBase能达到较好的性能和稳定的运行。在JVM中,有很多种垃圾收集器,我们在项目中使用的是CMS GC,下面首先介绍CMS GC的工作原理,再详细说明调优的相关细节。 3.3.2.2 GC调优目标在介绍具体的调优技巧之前,有必要先来看看GC调优的最终目标和基本原则: 1)平均Minor GC时间尽可能短; 2)CMS GC次数越少越好。 3.3.2.3 HBase 场景内存分析一般来讲,每种应用都会有自己的内存对象特性,分类来说无非就两种:一种是对象的生存期较短的工程,比如大多数的HTTP请求处理工程,这类的对象可能占到所有对象的70%左右;另一种是对象生存期居多的工程,比如类似于HBase,Flink等这类大内存工程。这里以HBase为例,来看看具体的内存对象: 1)RPC请求对象 2)Memstore对象 3)BlockCache对象 因此可以看到,HBase系统属于对象生存期居多的工程,因为GC的时候只需要将RPC这类对象生存期较短的Young区淘汰掉就可以达到最好的GC效果。 在HBase优化中比较关键的两个GC的参数。 1)年轻代Young区的大小; 2)年轻代Young区中的Survivor区的大小以及进入老年代的阈值。 3.3.2.4 生产环境中的GC配置假设我们机器的物理内存是80G,所以根据上面的分析,我们可以对相关的参数做如下配置: 1)缓存模式采用BucketCache策略Offheap模式 2)内存我们采用如下配置: -Xmx64g -Xms64g -Xmn4g -Xss256k -XX:MaxPermSize=512m-XX:SurvivorRatio=2 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC-XX:+CMSParallelRemarkEnabled -XX:MaxTenuringThreshold=15-XX:+UseCMSCompactAtFullCollection-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75-XX:-DisableExplicitGC 3.3.3 如何保证大流量情况下系统稳定运行流量限制是以一种被动的方式来对流量进行控制的方式。我们可以通过压力测试来粗略估计OSS所能承受的最大压力,然后在配置文件中配置限流的数值。这里要注意的是,需要根据业务的特点对限制的流量进行处理,其一,可以完全丢弃掉被限制的流量;其二,也可以对限制的流量进行相应的处理。 4. OSS监控 OSS在运行过程中,我们需要了解相关的监控信息,比如每种文件类型在一段时间的占比,或者在一段时间的网络吞吐量等等,下面就来一一介绍我们是如何来对OSS进行监控的吧。 4.1 以文件类型划分的指定时间段内的总存储占比该图表用于统计当前OSS中各文件类型存储的占比。 4.2 以文件类型划分的指定时间段内的文件数量占比该图表用于统计当前OSS中各文件类型数量的占比。 4.3 OSS服务指定时间段内的网络吞吐量该图表用于统计OSS的吞吐量。 4.4 OSS服务指定时间段内的每秒并发处理数(TPS)该图表用于统计当前OSS的负载情况。 5. 结语与展望 (编辑:应用网_阳江站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |