随着云计算、大数据等新型业务的快速发展，您的企业是否也对数据价值和数据中心的要求越来越高？在新业务环境下，贵企业的传统存储是否也面临着难以适应业务的复杂性、高度个性化和动态资源配置等难题？现在，中国闪存联盟行业应用解决方案智库“三百大行动”正式开启，100个企业级存储难题典型需求正在火热征集中！只要您将贵企业的存储待解决需求提交给我们，我们将针对需求进行全方位研究评估，如您的需求入选智库，我们将提供量身定制的完美解决方案！ 提交需求方式：点击下载表格按模板填写发送至以下邮箱，有问题请与彭培斌联系！ 联系人：彭培斌 咨询电话：13811945803 邮箱：peibin.peng@twtgroup.com.cn
下载表格模板如无法下载表格，请发送存储应用场景需求至 peibin.peng@twtgroup.com.cn加入我们，并不是一次演习，而是一场实战，真客户真需求，靠的是真技术真实力！中国闪存联盟行业应用解决方案智库三百大行动，已经正式吹响号角，2016年，中国闪存联盟行业应用解决方案智库将挖掘100个经过筛选的行业典型需求，评选出100个针对需求的优秀解决方案，100天完成。现在，亮出你最具实力的方案，解决企业最真实的问题，赢取商机！ 提交方案方式： 根据智库筛选的行业用户需求场景设计解决方案并发送至以下邮箱，有问题请与彭培斌联系！ 发送格式：序号+行业+贵公司名字，如1+银行+XX公司 评选规则：将由提出需求的企业专家选出最佳解决方案 联系人：彭培斌 咨询电话：13811945803 邮箱：peibin.peng@twtgroup.com.cn
点击提交需求如点击无法打开，请发送解决方案至 peibin.peng@twtgroup.com.cn| 业务应用 | 场景描述 | |
|---|---|---|
| 1 | 数据仓库系统 | OLAP大批量连续读写，IO繁忙率较高（账单日在90%以上），IO读写比约4:1，面临的问题如下： 1）存储容量不足 2）IO繁忙率较高 3）计算资源不足（CPU、内存、IO） 4）集群版本升级受限 |
| 2 | 核心系统 | 1）异构存储之间的统一管理不够方便，主机使用存储后的配置管理没有有效的工具，使用块存储后的切换不是很灵活，变更管理较为传统，比较麻烦，没有有效的统一性能容量管理工具，希望有高效的双活方案，便捷的统一管理工具进行存储管理。 |
| 3 | 银行核心、账务系统 | 1）随着业务数据量的增大，报表处理较慢。 |
| 4 | 前置系统 | 1）服务器老化严重，故障率高，性能低下，异常修复时间长。需求是适应云架构改造方向，进行前置应用程序改造优化，同时服务器替换升级。 |
| 5 | 手机银行 | 1）当前问题是系统维护停机时间长，需求是实现数据双活，采用软件定义方式优化架构快速部署资源服务应用。 |
| 6 | 数据仓库 | 1）报表慢，备份恢复时间长。需求是提高性能，数据高可用，自动资源调配。 |
| 7 | 国结报表 | 1）批量处理时间长，转换架构。 |
| 8 | 授信系统 | 1）CPU使用率高，IO busy高，处理时间太长，希望能进行设备和调优进行优化。需求是数据库SQL优化，设备升级。 |
| 9 | 核心账务系统 | 1）7*24小时不间断运行，且周一到周五工作日期间，并发量要求大，晚上需要跑批处理，io性能要求高。由于业务发展的需要，对批处理以及交易的效率要求更高，需要在提升主机，存储性能的同时，对业务系统做一定的优化和性能提升。 |
| 10 | 核心系统 | 1）晚上并发大，计算量超级大。应用服务器是瓶颈，CPU耗费极大，jvm应用。适合jvm场合，能适合调度jvm资源及其释放回收的服务器。 |
| 11 | 核心系统 | 1）OLTP,白天交易量大和夜间批处理时磁盘IO较高，但因业务量和数据量较少，io带宽不超过70% 2）异地灾备使用db2 hadr技术，由于专线带宽较少，只能使用asynchonous方式，存在数据丢失风险 |
| 12 | 统一归档平台 | 1）异构存储管理 2）存储智能管理平台，存储虚拟化池化统一管理 |
| 13 | 影像系统 | 1）日间数据IO较大，数据量大。无备份系统数据安全性要求较高 2）采用scsi连线，直连方式，无法扩展。IO性能有待提升 |
| 14 | 核心系统/其它外围系统 | 1）核心系统全年均有交易，日常交易量在上午9：30～11点和下午2：30～4：30时间段内较大 2）目前，vmware虚拟资源通过DS8800做MM灾备时，有一些异常情况 |
| 15 | 办公OA系统 | 1）集中时点上有大量交易，系统打开时有大量延迟，其他时间均能满足要求 2）有访问风暴问题，并且对数据冗余性要求高 3）之前也用过闪存，但是由于Vmware的底层对数据读写的限制，收效一般，后来考虑冗余性又使用了vplex。希望能有一款存储适合Vmware底层数据设计特点 |
| 16 | 核心/网银 | 1）OLTP类型交易系统，7*24小时对外服务 2）由于未部署应用分析监控系统，对应用故障的问题分析定位较慢 3）已考虑进行应用的日志分析系统，对应用进行深层次监控分析，提前或及时发现应用故障，提高应用的处理时效 |
| 业务应用 | 场景描述 | |
|---|---|---|
| 1 | 核心交易撮合系统 | 1）在股票交易高峰时段，由于系统性能不足导致客户无法登陆、交易申请拥塞（买卖报单均不能成交） 2）晚上集中结算批处理需要人工干预，结算运行时间往往较长 3）RAS可靠性要求高，交易时段不能业务间断，短时间宕机即会造成巨大的资金损失，甚至造成社会事件影响 4）股票交易对时机把握非常敏感，大额交易的VIP用户对系统的快速反应尤其敏感 5）机房空间不足，无法使用高能耗高空间占用的传统高端磁盘阵列 |
| 2 | x86虚拟平台存储整合 | 1）x86虚拟化平台要求提高系统整体响应能力的存储性能 2）现有系统中大多数为异构存储环境，新建系统需要具备建立存储整合系统的能力 3）要求存储整合平台具备丰富的功能性 |
| 3 | 融资融券系统 | 1）在股票频繁交易时段，由于系统性能原因，可能会存在交易申请拥塞情景，比如买不进，卖不出。这就需要存储系统需要提供极低的IO延迟 2）机房空间不足，无法使用高能耗高空间占用的传统高端磁盘阵列 |
| 4 | VIP客户快速报盘系统 | 1）大额高频度报盘交易对存储响应时间要求及其严格 2）存储IO并发能力要求高 |
| 5 | 核心系统 | 1）日常交易量在上午9：30-11:30和下午13：00-15：30左右较大。日间服务器性能足够满足，晚间结算也可以 |
| 6 | 核心 | 1）5*4类型的交易，系统的压力情况主要是根据市场交易情况，高峰期会有一定的存储IO压力，大部分时间是不会遇到 |
| 7 | 数据库 | 1）olap，IOPS压力大 2）数据库大量等待磁盘I/O，应用程序优化效果不明显 |
| 业务应用 | 场景描述 | |
|---|---|---|
| 1 | 核心系统、总账系统、银保通系统、核保、理赔 | 周结、月结，新程序发布，业务上线段对主机资源和存储资源需求量高，cpu、内存消耗较大。日间交易高峰时间段为10点左右，数据库查询较多，程序新版本发布大多在周五 。I/0吞吐量部分时间段存在瓶颈，月结，新程序发布，业务上线段对主机资源和存储资源需求量高，cpu、内存消耗较大 1）业务流量处理：要以每年500万条记录为参考 2）.响应能力：与数据库交互一次的时间应为毫秒级，一般不打过5秒，同时应尽量较少与数据库的交互次数，技术上使用读写分离 3）实时查询能力：需考虑大数据亮的复杂查询 4）业务并发操作处理能力：以2000在线，200并发用户为参考级数 5）应对单节点故障处理能力：应充分考虑硬件软件不稳定的情况下硬件软件故障。 |
| 2 | 核心系统/承保/理赔/再保 | 1）现有问题主要集中在软件架构上；多个业务集中部署在1台主机也是没有办法，软件架构决定了只能这样去部署，拆分的话，软件代码变动会非常大 2）通过APM等工具分析，明确可以看到是wls端一些逻辑或代码写法有问题 3）在年底冲量时，服务器的处理性能可见飞速增长；当前wls已考虑从AIX迁移至X86做集群部署 |
| 3 | 保险核心系统 | 1）夜间批处理数据库负载较大，业务计算都在数据库端。 2）系统能满足大部分的业务需求，中间件weblogic有时候会宕掉，但采用了负载均衡不影响业务。 |
| 4 | 核心系统、OA系统、快速出单系统 | 1）DB2数据库SQL死锁，导致应用宕机 。 |
| 5 | 个险核心业务系统 | 1）JSON接口偶尔超时，处理业务比较慢。 |
| 6 | 承保/理赔/单证/收付/客服/业务 | 1）系统伸缩性不够，扩展硬件资源流程复杂，主要靠负载解决高可用（没有高可用冗灾架构）。 2）关注docker的技术，移动互联网的整体解决方案。 |
| 7 | 核心系统 | 全年交易，交易主要集中在银保渠道和网销渠道，网销渠道一般集中在晚上20:00-24:00，银保渠道集中在9:30-11:30，13：00-16：00 目前服务器和存储IO性能满足，无IO问题导致的系统响应较慢情况出现： 1） 公司新开业，只采购了单台存储，未考虑绿存储级别的高可用架构，存在单点故障的风险 2） 存储未包含NAS功能，如果要实现需加板卡或者添加nas机头 |
| 8 | 核心系统/影像 | 1）非高峰期无压力，由于大量使用虚拟化，在做备份或者短时间大量数据读写时IO要求较高 2） 当前传统存储的性能无法满足虚拟化短时间大量备份以及互联网业务峰值期间数据写入，另外存储扩折和资源灵活使用仍需提高 |
| 9 | 核心周边系统 | 1）已运行虚拟服务器80余台，服务器资源池使用率已达到60%，其中统一客户视图系统服务器日常运行占用CPU及IOPS较大 2）现有SAN存储架构，在增加虚拟化物理服务器、存储扩容等横向扩展的地方存在瓶颈（因涉及光纤交换机、存储设备调整，有较大风险），通常虚拟化环境扩容等同于再新建一套虚拟化环境 |
| 业务应用 | 场景描述 | |
|---|---|---|
| 1 | 核心银行系统 (Core-banking) | 核心银行是银行处理客户信息、存储/贷款产品、支付服务和核心总账的核心系统，是银行业务系统运作的心脏。一切关于存款贷款账户的业务操作都需要在核心业务系统中完成，其主要业务包括：客户信息管理、存款/贷款业务、总账及存款/贷款业务的日间操作。 核心银行系统建设的需求如下： 1）大集中系统建设，数据集中存放，结构化数据居多，交易性能及数据安全要求高 2）银监会对核心系统有明确的、强制性要求，对RTO/RPO有清晰的定义，各银行都需要建设高可用和容灾系统 3）核心业务系统数据未必巨大，但稳定性压倒一切 4）晚上批量结算时间希望能缩短 5）节省机房空间和电力 |
| 2 | 总账及财务系统 | 银行总账系统是银行后端经营管理类系统的核心部分之一，完善流畅的总账系统可以减轻核心银行系统的压力。与核心系统一样，金融行业对于各种经营分析类的业务系统的时效性、可靠性要求越来越高，比如： 1）需要一个可靠的数据存储架构来保证数据的实时可用 2）需要建设高可用和容灾系统：完善建设本地高可用，并逐步向外围扩展 3）总账及财务系统需要高效的数据处理和报表查询性能 |
| 3 | 数据仓库系统BI系统 | 银行的数据仓库系统以核心业务系统数据和各类规范的管理数据为数据源，建立统一的企业级数据仓库，为银行各级管理人员提供信息查询、动态报表生成、多维数据分析服务。同时，为全行财务管理、风险控制、客户关系等管理工作提供有力的支持。 数仓应用的特点如下: 1）数据量巨大，有结构化数据，也有非结构化数据，是典型的OLAP处理，需要较高的持续带宽 2）数仓系统也有较高的可靠性要求 3）对数据访问的吞吐量有很高的要求，并且部分事务处理要求在较短的时间内完成 4）系统架构要有很大的弹性，性能和容量都易于扩展 5）数据分析类应用，短时间内IO压力巨大，吞吐要求高。传统存储在性能和响应时间上很难满足要求 6）绿色节能，低能耗，低机房空间占用，低机房承重要求 |
| 4 | 后督影像系统 | 1）为信贷、支票、柜面等业务提供事后监督影像系统 2）容量需求一般在百TB以上，考虑3-5年规划，可达500TB以上 3）需要并发处理文件，对吞吐并发能力需求高。同时索引等元数据需要高IO小块并发 4）倾向分级存储，节省投资 5）文件系统需要统一的文件命名空间，提供大文件的管理和访问 6）需要提供高性能的文件检索和访问 |
| 5 | BI及资金风险 | 1）BI及资金风险系统当前采用传统存储，难以满足时间要求。 2）存储性能需要更低的IO响应时延 3）需要与现有存储架构整合 |
| 6 | 信用卡交易记录存储、查询、分析 | 构建服务于内部及外部用户的信用往来记录查询系统: 银行业务部门：信用卡中心各职能部门在市场营销活动中可以通过查询客户信用卡往来交易记录查询系统，通过一定的过滤逻辑迅速找到达标客户，实现精细化经营. 外部持卡人：持卡人通过网站或App查询信用卡往来记录系统掌握自己的积分、账单、银行促销活动等信息，实现自助化。 主要需求： Capacity: 3千万信用卡用户，4亿比交易每天。 Performance: 高并发、快速响应，平均每天5000次查询，支持1000并发每秒。 Architechture: 四层架构：应用层、访问控制层、数据服务层及源数据层，层间实现松耦合。 Scalability: 性能及容量线性扩展，支持TB到百TB线性扩展 Service interface: 支持http Restful API外部接口。 |
| 7 | 金融风险分析系统 | 金融机构在具体的金融交易活动中出现的风险，有可能对该金融机构的生存构成威胁；具体的一家金融机构因经营不善而出现危机，有可能对整个金融体系的稳健运行构成威胁；一旦发生系统风险，金融体系运转失灵，必然会导致全社会经济秩序的混乱，甚至引发严重的政治危机。金融行业有多种商业软件支持下列风险分析业务： - 风险估值 VaR (value at risk) - 信用值调整CVA (credit value adjustments for CCR) - 资产负债建模ALM (asset liability modeling) - 灵敏度分析 - 信用等级评分 - 抵押分析 - 可变年金建模 - 模型回溯测试 - 投资组合压力测试 - 数据的提取,转换和加载 ETL - 策略提取Strategy mining - 精算分析 |
| 8 | 银联前置 | 1）存储系统要提供较高IOPS性能 2）RAS可靠性要求高，交易时段不能业务间断，短时间宕机即会造成巨大的资金损失 3）机房空间和电力已不足 |
| 9 | ODS系统 | 1）存储系统要提供较高IOPS性能 2）系统做批处理需要时间较长 |
| 10 | 核心交易系统 | 1） 全天候业务，交易呈线性增长，并有业务突发相伴。业务时间为7*24 。白天交易，下午结算，晚上夜盘交易 2） 监控系统不多，监控的数量非常少。而且第三方目前也没有合适的 |
| 11 | 金仕达期货交易结算系统 | 全年除法定节假日的日期均有交易，并且有夜盘连续交易。期货交易的快速交易模式，大多是较大并发访问量伴随大量小块数据高速访问，对系统的数据读写速度要求比较高，也要求系统存贮有更好的可靠性： 1） 现有问题主要有因为适应期货业务的变更，系统升级很频繁，同时经常参加交易所各类测试，系统数据的备份和恢复存在多个版本，备份和恢复的时间较长，存在恢复错误的隐患 2） 目前是Linux HA模式，但此模式是主机双活，系统数据双活没有部署，需要优化为双存贮多的模式 |
| 12 | CRM系统 | 全年除法定节假日的日期均有交易，并且有夜盘连续交易。此系统是业务服务系统，提供大数据的分析和查询，数据并发量没有交易系统大，实时性的要求也没有交易系统高，对存贮的可靠行要求高： 1） 现有问题主要有系统数据大批量读写时性能较差，系统归档及数据整理时，因原始数据量大，耗费的时间太久，备份和恢复时间长 2） 需要在存贮的数据级别上能更好的优化，不能仅靠主机增加配置提升有限的性能 |
| 业务应用 | 场景描述 | |
|---|---|---|
| 1 | ERP系统 | 1）作为制造业的核心业务系统，需要一套兼具高可用和高性能的存储系统来满足ERP系统的苛刻需求 2）在生产管理系统中，利用条码扫描技术对生产各个环节进行管理，条码扫描的响应时间会影响产能 3）报表的生成也要及时快速 4）BI和零售系统的效率要求基础架构能提供高性能、低延迟 5）绿色节能：低能耗，低机房空间占用，低机房承重要求 |
| 2 | EBS系统建设 | 1）满足新建ERP系统，以及邮件、呼叫中心容量需求 2）需要对对Oracle EBS、NC等关键应用，充分考虑数据的安全性，通过相应技术实现数据的冗余保护 3）进行存储的统一规划部署，需要实现对现有存储的利旧保护 |
| 3 | ERP系统 | 1）作为制造业的核心业务系统，需要一套兼具高可用和高性能的存储系统来满足ERP系统的苛刻需求 2）在生产管理系统中，利用条码扫描技术对生产各个环节进行管理 3）条码扫描的响应时间影响了生产效率 4）报表的生成也要及时快速 5）BI和零售系统的效率要求基础架构能提供高性能、低延迟 |
| 4 | SAP系统应用 | 1）ERP系统是企业最核心的业务系统，而大多数ERP应用程序为读密集型，因此，单独依靠额外的CPU处理能力几乎无法提升性能 2）通过将读数据存放在低延迟的全闪存阵列上，读操作会被更快的处理，从而带来性能的急剧提升 3）可仅将IO负载较高的数据库放在Flash上，也可将整个 ERP 生产数据库放在 Easy Tier 管理下的分集存储上，非生产数据库放在传统硬盘上 |
| 5 | SAP HANA | 1）核心系统对IO压力很大 2）传统存储无法满足业务系统要求 3）SAP系统中热点数据存储需要高性能存储介质以提升读性能 |
| 6 | 高性能计算前后处理一体化 | 1）统一管理调度平台，集成所有业务计算应用 2）异构平台作业调度，对linux、windows统一管理 3）各业务阶段无数据转移 4）通过GPFS提供并行文件系统提高IO读写，文件分级管理 |
| 7 | SAP应用系统优化 | 1）现有SAP核心系统存在I/O瓶颈：存储系统本身的性能是原因之一；SAP系统的优化是提升性能的一个有效办法 2）现有存储系统容量已经到达临界值，扩容费用高，且提升性能效果不显著 |
| 8 | PDM | 1）研发图纸，文件占用空间大，加载速度较慢 2）容量问题（目前EMC NAS最大支持16TB） 3）性能及架构优化的需求 |
| 9 | tc/sp/sap/mes/qms | 1）并发量数量有限但是大数据量传输，如何利用数据驱动质量改进，如何进行试验数据有效管理并与cae对应，提升虚拟验证能力。 |
| 10 | ASCP | 1）周期性 2）集中压力较大 3）性能优化的需求 |
| 11 | Oracle ERP | 1）OLTP,月结IOPS压力大 2）报表产出慢 3）提升IOPS的需求 |
| 12 | ERP，CRM，财务，OA | 1） 性能慢、用户体验差、报表慢，异构存储管理效率低，系统维护停机时间长，未采用高可用冗灾架构 2） 性能优化%，资源虚拟化池化统一管理、数据双活，采用软件定义方式优化架构快速部署资源服务应用 |
| 13 | 营销系统、一号工程 | 1） 全年均需要运行，允许非业务时间停业，在查询阶段对IOPS要求较高 2） I/0吞吐量在业务查询高峰期存在瓶颈，内存cpu消耗较大 |
| 14 | MES | 生产期间会有较多的数据读写，并且对数据的准确性、实时性有严格要求： 1） 目前存储双机采用AIX的LVM方式进行数据同时写入两个存储，其中的一个存储的链路出现问题，在进行写入时会导致会话等待，从而影响数据库对应用的响应速度，引起生产数据问题 2） 生产的实时数据都是写入的数据库，当数据库端（软、硬）问题会直接反映到应用端 |
| 15 | WASserver、Mqserver、DB2数据 | 1） 全年均有交易，但交易量非线性，而是根据险种不同，业务员入单时间不同，造成交易量大小不同，且险种不同，交易数据量不同，如一个村的农险与一个区的农险入单；日常交易量在上午9：30-11:00和下午1：00-3：40左右较大。日间服务器性能足够满足，晚间结算也可以 2） 小机与存储平均运行时间将近5年，目前做到是HA,但没有做过切换演练 |
| 业务应用 | 场景描述 | |
|---|---|---|
| 1 | 企业ERP系统 | 地产是中国经济的支柱产业，多年来业务发展迅速，规模空前。房地产ERP就是房地产企业资源计划的简称。地产ERP特点如下： 1）面向房地产企业决策者，了解进展，信息挖掘，提供决策支持 2）面向房地产企业员工，将员工待办、关注、发起的任务展现出来，并与企业内部管理平台的相关功能界面连接，实现工作协作流程化、任务安排自动化，是企业门户与协作平台 3）面向客户，围绕CRM平台、客户门户， 建立全面的客户关系管理，向客户传达企业品牌价值和产品价值 4）面向房地产企业合作伙伴，从合作伙伴评估与管理、采购招投标管理到项目执行过程中进度管理、质量控制、成本控制等各方面维护合作伙伴关系，提升项目竞争力，实现与合作伙伴的双赢 5）ERP系统对性能有一定的要求，特别是报表分析系统 6）房产营销高度依赖IT环境，因此系统的可用性要求高 |
| 业务应用 | 场景描述 | |
|---|---|---|
| 1 | 风电高性能计算平台 | 1）新建的高性能计算平台要与原有计算资源整合统一管理调度 2）需要对Linux, Windows软件统一调度，通过命令行、web portal及软件UI提供多种计算任务提交方式 3）业务计算的过程数据通过Flash进行加速，配合v7k存储来实现软件定义的存储架构 |
| 2 | 海量地震数据处理存储管理优化 | 地震数据处理计算任务需要对大量数据进行读写操作，任务计算周期长，通过对存储性能的提升可以缩短计算周期。GPFS通过并行化I/O来加速对光纤存储的访问速率，同时将数据元数据存放在Flash上可更进一步加快对文件的访问操作。 1）地体图像勘探与运算的高性能运算场景 2）Metadata成为高性能运算平台的全局数据热点，需要优化 3）提高整体图像勘探系统的性能与效率 4）需要成熟的Scale-out无扩展瓶颈的架构 |
| 3 | 勘探开发云管理平台 | 针对于石油领域的勘探开发业务，建立HPC云管理平台，提供： 1）处理系统物理机快速部署，切换计算环境，快速提供业务计算资源，作业调度 2）解释系统物理/虚拟机管理、远程3D可视化 3）石油专业应用许可证管理调度 |
| 4 | 财务报销系统 | 1）财务系统在结算时会有相比于平时较大的性能瓶颈 2）对延迟要求较高 3）RAS可靠性也需要保证 |
| 5 | 核心系统/设计信息 | 1）工作时间用户在800人在线，资源性能非常紧张。每个用户占用200M内存，无法释放。用户客户端访问慢，流程进展有时候会丢失 2） 架构设计有缺陷造成资源无法满足，计划将aix数据库迁移至X86服务器linux下看是否有效果 |
| 6 | 钢铁生产系统 | 生产型业务，全年均有交易。V7000主要部署企业ERP系统，DS800部署桌面虚拟化及能源管控系统部分Server功能；ERP系统涉及炼铁、炼钢、轧钢、动力、运输、计量、扫描等生产型业务及采购、销售、财务、结算等日常型业务，交易量在上午7：30-12:00和下午1：30-6：00左右较大。日间服务器性能足够满足，晚间结算也可以： 1）现有问题主要有：访问ERP的WebsphereJVM虚拟机（5个，负载均衡）经常性宕机重启，尤其客户做报表时，每月平均20-30次 2）WAS版本较低，扩展业务受限，很多新功能受限 3） 能源管控系统负责收集全厂水、电、风、气等能源数据。想在其主要存储DS800下划分部分空间与V7000ERP系统做双备 |
| 7 | 核心系统 | 重要的系统对IOPS有很强的需求，在业务高峰期容易出现延迟写入和等待： 1）现有问题主要集中在存储架构上，多业务如何隔离IO，如何提高写的性能 2） 异构存储的统一监控 |
| 8 | ERP | 生产数据实时传输，数据量不是很大，带宽压力不大： 1）现有问题主要集中在数据库连接资源被不合理的程序占用，从而导致系统中间件顶死 |
| 9 | 核心系统/SAP | 1）SAP业务使用，IO特点为增、删、改、查 2）存储性能基本满足业务需求。因该存储为核心业务系统使用，后端服务器较多，从运维角度出发，问题出在不便于管理和维护 |
| 10 | K3/PLM/MES | 服务器主要用于部署ERP，目前ERP用户数约为200，正常工作日访问量较大，未来ERP部署模式从C/S转向B/S，用户数会有所增加，多屏访问会相当频繁，同时公司网络也在进一步优化当中，以满足日常业务需要： 1）现阶段由于异地访问服务器通过2X软件，用户体验相对于本地来说，不是很理想，经常出现延迟 2）数据备份等还停留在简单的数据库备份阶段，未采用双机热备，可能会出现因系统故障而无法正常使用ERP的情况产生 |
| 业务应用 | 场景描述 | |
|---|---|---|
| 1 | BOSS核心运营支撑 | 1）BOSS（Business & Operation Support System，BOSS）指的是运营商的业务运营支撑系统。核心运营支撑系统, 包括计费/帐务/CRM/客服 2）核心业务对可靠性要求极高, 本地双存储HA是标配要求 3）业务高峰期间可能出现IO性能瓶颈, 调优难度很大 |
| 2 | 多租户大数据平台 | 电信企业需要建立企业级的统一的大数据平台(大数据中心),通过企业级大数据平台实现资源统一管理，满足多个大数据应用的资源分配需求及应用SLA 1）大数据中心建立企业级统一大数据平台, 共享资源,提高收益 2）企业级大数据平台需要实现资源统一管理-硬件资源共享, 文件/数据共享,应用和资源定义共享 3）满足多个大数据应用的SLA管理, 包括项目级SLA, 应用级SLA, 作业级SLA |
| 3 | VDC(虚拟数据中心) | VDC（Virtual Data Center），是将云计算概念及技术运用于IDC的一种新型的数据中心形态。通过传统IDC业务与云计算技术相结合，构建可伸缩的虚拟化基础架构，采用集中管理、分布服务模式，向用户提供一站受理、全网服务的基础IT设施方案与服务。 主要业务范畴包括： 1）云计算服务 2）云备份服务 3）云存储服务 VDC主要的数据类型众多，尤以非结构化数据为多，是对象存储的应用场景之一 |
| 4 | 开发测试云 | 1）为基于X86虚拟化云计算环境的开发测试系统提供云存储支撑平台 2）采用和前端云计算环境同购的基于X86的弹性块存储模式 3）基础架构开放,自主, 可控的技术路线选择 |
| 5 | BOSS业支Tier2业务整合 | 1）数据中心趋向软件定义基础架构 2）新应用平台计划迁移到X86分布式平台 3）新应用系统基于虚拟化云计算架构部署, 期望建设更具弹性的软件定义存储平台 |
| 6 | 计费账务NAS | 1）计费账务应用中有海量小文件处理场景，对存储性能要求高 2）整体业务性能受累于随机小文件数据访问延迟 3）计费数据库DB忙时超过80%的DB Time为随机小IO |
| 7 | 渠道支付 | 1）IO读写频繁，大小没统计 2）连接数大，数据库压力大 3）采用软件定义方式优化架构快速部署资源服务应用 |
| 8 | 核心系统 | 1）实时交易，储存大量信息，随时需要调用，峰值在10：00至16:00 2）维护费用高昂，扩容成本高，原厂维护技术不易掌握 |
| 业务应用 | 场景描述 | |
|---|---|---|
| 1 | 公安高清卡口实时预警及分析 | 卡口预警系统对实时性要求很高，需要快速获得预警信息用于交通干预。支持各种高级分析、研判和关联分析 同行车辆分析、昼伏夜出车辆、关联业务，以及多个边界系统的有效整合及信息交换，跨部门、多警种的高效联动。 1）同行车辆分析： 通过分析嫌疑车辆前后几分钟的车辆（时间自定义），找出在不同地市不同卡口多次同行的车辆。对确认的同行车辆进行关联追踪，寻找出其他同行车辆，并以线条方式在地图上展示同行车辆的轨迹，查看同行车辆轨迹信息； 2）昼伏夜出分析： 分析判断部分车辆经常白天某个时间点进城后不出城或是晚上某个时间点进城或出城，针对该些具有规律性的车辆进行筛选，筛选出该车辆进行特别关注，并对该车辆进行特别标注； 3）与车辆登记库、交通违法库关联分析： 针对部分车辆只提供车辆品牌等特征并非知道该车辆号牌号码、车牌颜色等特征，需与车辆登记库进行关联，查询出该车辆的登记信息，并根据车辆登记信息关联交通违法库，查询出该车辆是否为涉案等违法车辆。 |
| 2 | 集中支付电子化系统，部门预算管理系统，非税业务系统管理等 | 1）运行Oracle数据库，主要为结构化数据 2）财政行业的核心业务系统，对于可靠性和性能要求高 3）利旧现有存储系统 |
| 3 | 人口系统 | 1）整合的存储平台，能支撑Unix，Linux，Windows等多种业务系统的数据存储 2）核心数据的访问要求具备高并发，低延迟的需求 3）具备本地高可用+同城同步容灾的技术能力 |
| 4 | 税务网票系统，综合数据分析平台 | 1）数据分析系统，容量空间要求大，性能要求高，且要具备容量性能保持线性增长的能力 2）打破以往的竖井式建设模式，改成平台建设方式，能整合已有的存储设备，利旧节省成本 3）考虑数据的分层分级部署 4）绿色数据中心需求，节电及节省空间和承重 |
| 5 | 气象预报高性能计算资料归档系统 | 气象预报分为4部分： 1）观测系统（卫星、雷达、探空观测、地面观测等）进行数据和资料收集 2）观测数据的前处理和归档 3）模式运行，结合数学，物理，化学，地球科学，需要大量的计算资源 4）模式后处理 因此系统对计算资源调度和管理、分布式文件系统、备份等都提出了大规模的需求。 |
| 6 | 公积金业务系统 | 1）核心业务需要高可用性和高性能兼顾 2）原有业务系统晚间日终业务时间超过4小时，需要从软硬件层面进一步优化 3）客户希望核心业务系统对应的基础架构全部由企业级设备构建 4）大量小文件需要通过NAS进行共享 5）利用磁盘进行备份，提供更好的备份/恢复速度 |
| 7 | 社保系统，医保系统 | 1）性能慢，报表慢 2）希望数据双活建设 |
| 8 | 人社信息系统 | 1）交易量非线性，每月前15日交易量较多 2） 新的系统，刚开始运行，问题不凸显，就是在交易量多的时候，性能变慢 3）交易量多的时候保证性能，需要进行性能优化 |
| 9 | 核心系统/五险合一系统/劳动就业系统/医疗定点系统等 | 全年均有交易，但交易量非线性，而是根据全市各地险经办业务情况的不同，业务员操作时间不同，造成交易量大小不同，且业务操作类型不同，交易数据量不同，如一个新参保业务与一个区的业务变更等等的不同；日常交易量高峰在上午9：00-10:30和下午1：30-3：00左右较大。日间服务器性能足够满足，晚间结算也可以： 1）现有问题主要集中在软件架构上；多个业务数据集中部署在1台主机也是没有办法，软件架构决定了只能这样去部署，重新设计的话，软件代码变动会非常大；也没有能力解决重新整体设计问题 2）通过TIVOLI等监控工具分析，明确可以看到是wls端一些逻辑或代码写法有问题；需要不断优化最好重新设计。 在集中查询或者统计时，服务器的处理性能可见飞速增长；当前wls已在X86集群部署，但原来设计与现有环境并不是适合的，应该要根据现有环境重新设计，但这种要求非常渺茫 |
| 业务应用 | 场景描述 | |
|---|---|---|
| 1 | HIS | 1）HIS系统是医院最重要的信息管理系统，为医院所属各部门提供病人诊疗信息和行政管理信息。业务高峰时对存储IO有一定压力 2）RAS可靠性要求高，不能业务间断，短时间宕机可能会造成医疗事故 3）数据库系统，结构化数据为主 4）院方业务规模持续扩大，涉及到大量患者的挂号，就诊，缴费，取药等并发事务，性能要求高，延时要求低 |
| 2 | 卫生档案归档系统 | 卫生系统档案管理从原来的纸质转移到电子化，建立的过程中，需要对过去的纸质文件（健康、妇保、免疫、食品等）进行归档保存，并按保存期限（10年、30年、50年）进行标记划分。 1）数据保存时间久，冷数据保存数目大 2）磁盘保存方式经济性和时效性差 3）图片、PDF式文件保存占90% |
| 3 | HIS/MER/PACS/LIS | 系统应用要求每天24小时不间断安全、高效运转,数据交换频繁，尤其是非结构化数据传输给医院网络带宽带来很大压力： 1）大数据存储技术路线最典型的共有三种：第一种是采用MPP架构的新型数据库集群；第二种是基于Hadoop的技术扩展和封装；第三种是大数据一体机，这是一种专为大数据的分析处理而设计的软、硬件结合的产品。 那么，医疗么业既有结构化数据又有非结构化数据，如何选择技术路线和产品选型才能保障数据集中平台的最优化和高性价比 2）医疗行业非结构化数据，数据量大而且增速大，但随着时间的推移，并发访频率逐渐降低，因此一般采用分级存储技术，目前分级存储设计发展为在线存储、近线存储、离线存储，那么，有没有一种算法，确定多久的数据适合在线存储,多久的数据适合近线存储，多久的数据适合离线存储才比较科学？ 中心机心服服器较多，已考虑服务器虚拟化 |
| 业务应用 | 场景描述 | |
|---|---|---|
| 1 | 媒资归档系统 | 媒资行业的存储，制作时对实时性能的要求高并且有大量内容需要长期归档。长期归档采用存储介质的类型主要为：40%的内容采用磁带归档，28%采用外部硬盘（移动硬盘），保持在存储里面只有16%。 1）后期编辑数据移动，使用磁带转移成本低 2）影音数据长期保存，冷资料长期保存，磁带有更高的经济性 3）按影音数据文件的冷、温、热程度，进行自动分层和转移，将冷数据自动迁移到磁带长期保存 |
| 业务应用 | 场景描述 | |
|---|---|---|
| 1 | ERP核心系统 | 1）ERP系统自最初建设至今有较大数据量的增长，需要优化存储性能 2）ERP系统与可靠性要求高 |
| 2 | 铁路运输调度核心系统 | 1）铁路运输调度系统为核心生产，对可靠性要求极高 2）铁路运维人员希望架构简单且易于维护 |
| 3 | 货流系统 | 属于报表系统，iops高峰达到20000左右，每个月一次跑数据： 1）之前使用了普通的sas磁盘，后由于性能较慢更换了SSD磁盘，更换后性能并没有提升，反而有所下降。相关的sp均没有变过。发生变化的只有服务器从p6升级至p7，磁盘由sas升级成ssd 2）目前无法定位可能的原因出现在哪里，急需要解决性能方面的问题 |
| 4 | ERP | 1）全年均使用，用户访问量主要集中在工作日，（因原ERP系统性能不能满足业务量）此系统为新迁移的系统，系统性能不足。 |
| 业务应用 | 场景描述 | |
|---|---|---|
| 1 | 供应链SCM系统 | 1）承载了客户的供应链的数据库系统；要求较高的IOPS，比如10万IOPS以上；对IO的延迟要求很高，1ms以内 2）对业务的连续性要求很高；业务数据库采用Oracle RAC方式部署，交易时段不能业务间断 |
| 2 | ERP系统（财务系统，供应链、协同系统） | 1）硬盘读写跟不上 2）数据库读写较慢 3）后期准备使用oracle RAC架构 |
| 业务应用 | 场景描述 | |
|---|---|---|
| 1 | SAP BW | 公司每天早上7点前会出销售数据报表，要在每天22点前汇总所有数据，进行跑批处理。跑批时间长，中间会有数据归档、数据备份、节假日高峰期、其他一些临时任务的话，第二天7点前报表不能跑完： 1）目前公司类是于这种报表服务器他太多基，本都是速度慢，容易导致未按时间出报表 2）是否能用其他架构替代当前的传统的bw 3）如何在有备份，有临时任务，或者节假日业务高峰期时不影响报表按时跑完 |
| 业务应用 | 场景描述 | |
|---|---|---|
| 1 | 虚拟桌面云 | 云桌面（Workspace）是一种运用云计算方式，提供虚拟Windows、Linux桌面与应用的服务，用户可以突破时间、地点、终端、应用的限制，随时随地接入到数据中心的桌面云办公。专业的桌面云解决方案，可以打造更精简、高效的办公系统环境。 其特点如下： 1）数据高度集中，需要较高的数据安全保护机制 2）集中、并发、的移动环境随时随地接入 3）可以减少数据外泄的风险 4）高机动性，特别适合临时办公、移动办公、大型企事业单位等 5）功能模块化，便捷体验 |
| 2 | 虚拟带库系统优化 | 虚拟带库通过磁盘仿真磁带库，有效的规避了磁带库的机械操作时间，对数据库的恢复效率比传统带库要高 1）需要备份的数据规模越来越大，备份窗口越来越小，需要快速备份方案 2）虚拟带库备份速度或许能满足要求，但数据恢复性能未必理想 3）关键业务系统的数据更需要快速备份和快速恢复 |
| 3 | HPC | 1）同时有结构化和海量非结构化数据需要存储 2）具备Infiniband的接口，简化组网方式 3）存储性能要求较高，且要随容量的扩展线性实现性能扩展 4）与Spectrum Scale融合，提升数据并行处理和访问的效率 |
| 4 | 虚拟化系统 （闪存+备份） | 在利用虚拟化技术对信息化软硬件资源进行整合后, 也随之出现了一些急需解决的问题： 1）常规的数据备份不能解决虚拟化环境下的重复数据多、数据量大、备份时间长以及多点备份等难题 2）虚拟化环境规模化后，出现的启动风暴等问题也需要使用更好的技术来解决 3）需要有针对的进行虚拟化系统更专业的技术方案来进行备份，解决不同文件粒度恢复、以及针对虚拟化环境的增量备份技术进行大规模虚拟化环境的备份 |
| 5 | 视频监控 | 1）同时有结构化和海量非结构化数据需要存储 2）存储性能随容量扩展线性增长 3）在用户最看重高密度和性价比的领域，传统阵列很难满足要求 |
| 6 | 数据中心异构存储监控系统 | 异构存储的性能监控和报表在数据中心日益繁杂的情况下越来越重要 1）不同品牌的存储提供的性能监控方式不同，没有统一的仪表盘进行统一的监控 2）报表数据和来源、格式不一，反馈到决策支持系统，信息凌乱复杂 3）能够针对细节需求进行报表的自定义和设计，满足个性化报表需求 |
| 7 | Vmware虚拟化整合 | 1）X86平台上多种业务系统需要整合，包括计算资源和存储资源的整体整合 2）整合后多个业务的并发数据存储会对后端存储提出更高的性能要求 3）整合后为避免数据存储的单点风险被放大，可用性需求更高 |
| 8 | 大型NAS系统 | NAS系统被各行各业广泛使用：随着数据量爆炸式的增长，NAS设备所承载的数据容量也爆发式增长。 税务系统NAS：业务数据资料、日常办公文件资料及数据邮件系统的统一存储和备份 制造业NAS：实现海量数据的集中存储、备份、分析与共享 医疗行业NAS：容量大、易扩展、热数据备份和冷数据备份，缩短数据存储、查找的时间 教育行业NAS：容量大、安全性高，并要有非常快的传输速率，确保整个数据资料的安全、快速存取 保险NAS系统等：保单和保单影像系统要求容量大，访问快，易扩展，数据安全 |
| 9 | 核心业务系统/租赁 | 每天均有交易，业务入单时间不同，并且交易量大小和交易金额数据大小有差异，造成数据读写不稳定。日常交易集中在10:00-16：30之间,期间磁盘读写频繁，偶尔提示IO busy。日间服务器使用率接近80%，内存资源全部占用： 1）现有问题主要集中在系统瓶颈上,应用服务启动较多导致占用系统资源过高，内存资源不足，cpu接近警戒线 2）使用相关工具解析应用程序代码，分析得出其相关参数设置需要调整。 希望对应用程序进行优化，调整应用程序参数，限制对主机资源的过度消耗，对硬件资源进行升级，提高服务器性能。必要的话可以从小机平台迁移至X86平台 |