业务可以按稳态和敏态分为两类,也可以按业务等级(一般业务/关键业务/核心业务)区分,不同属性的业务对于存储的需求也就发生变化,同时存储的规划设计也不能独立看待,需要结合基础架构整体规划,下面有几个视角,供参考。 在银行
在目前银行 IT 基础架构中,主流的存储形态依然是存算分离架构,计算层与存储层是松耦合的(物理机+集中存储或虚拟化+集中存储),即便是传统的数据库一体机,计算与存储也是分开的,之间通过高速网络连接(例如 IB),存算一体的架构目
如您所说,对于交易系统的存储选型,会关注稳定性、可靠性和高性能,早期都会使用集中存储支撑(FC-SAN),近些年,在硬件红利和高性能协议的加持下,以 SDS 软件定义的分布式存储得到快速发展,并在很多金融机构落地,支撑不同的业务场
在目前国内的生态下,超融合基础架构(非数据库一体机)与上层数据库厂家确时还是有边界的,如果要做到开箱即用的使用体验,一定是需要厂商之间做深度的集成,否则就还是两套各自的初始化界面,这点做的比较好的是云计算整体提供商
如您所说,两种架构各有优势,所以就要看你的应用场景是什么了,就像跑车和越野车都可以在公路行驶,但是两种车的用途和适用场景是不同的。 超融合架构底层是使用分布式存储支撑上层虚拟化的数据持久化存储,与独立的 SDS 分
存储资源池分层通常都是指性能、容量、可靠性和可用性等维度,通过不同类型的产品和硬件组合,抽象池化出不同能力的存储资源,来支撑上层各种业务需求,对于你的问题1“如何对资源池进行分层”,有两个切入角度,一是从上而下,也
在当前的企业数据中心中,存储异构是一种常态,不同品牌,不同技术类型的存储一同构建了底层数据存储资源池,统一自动化运维需要先明确以下几个背景信息。 谁是最终使用者? 谁是管理者? 日常自动化运维功能的 Scope ? 需要纳
我理解你的问题是异构存储厂家背景下的存储资源池建设(如果基于单一产品构建,难度会小很多),这是一个相对要复杂一些的框架设计,如果采用自下而上的方法论,如何抽象出不同能力属性的存储池,如何统一管理,统一监控,存储卷的生命
对于聚焦的这 5 个问题,个人认为每个话题都可以展开讨论,这里基于我个人的视角给出一点思考。 1.存储资源池规划过程中,如何与监管层日益推行的金融数据治理方向进行贴合 根据”银行业金融机构数据治理指引“,对于金融
采用自主研发、安全可控的信息技术产品,已经成为金融行业 IT 发展的明确趋势,作为重要的基础架构底层支撑系统,存储平台近年来在非常多金融机构都在进行基于国产化的实践,无论是在传统集中存储,还是新型的基于软件定义的分
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30