怎么给客户出NAS集群方案?Infortrend这个示例让您豁然开朗

对于Infortrend分布式NAS集群EonStor CS,我们之前对它的产品特点、应用场景通过图文、视频讲座已经做了详尽的介绍,但是在实际给客户出方案时,如何将这些优势最快形成到方案当中去,我们的SI可能还有疑问,今天在这里我们给您提供一个示例,向您展示该如何配置EonStor CS集群,希望用简单明了的方式,让您在最短的时间确定NAS集群方案。在配置前,首先应该了解用户的需求,例如容量和读/写性能。根据用户提供的这些信息,再结合存储系统所具备的各种参数,一个成熟的方案就初步成形了。

得到用户的信息后,考虑以下这几个问题可以帮助您理清存储配置的思路:
·需要多少个节点能够满足用户要求的性能 ?
·多少颗硬盘以及哪种硬盘的类型可以满足用户要求的容量?
·用户是否需要存储的其他功能(这些功能会需要许可)?

我们假设用户需要:
·15GB/10GB 读写性能
·2PB 空间
·存储需要与云集成,本地存储系统保存热数据,冷数据则保存到云上

要满足用户的性能要求,您可以联系Infortrend售前团队,获取性能报告,计算节点的数量。我们的示例设定EonStor CS 4016每个HDD节点在平衡模式下,性能可以达到1.6 GB/s 的读和1 GB/s 的写。由于用户需要16GB/ 10GB的读写性能,那么需要部署10个节点。接下来我们计算空间,RAID 与纠删码/副本需要给校验码或副本预留空间。我们采用纠删码4+1保护级别,RAID采用平衡模式(关于平衡模式的概念,你可以参考配置EonStor CS分布式集群方案要考虑哪些关键点?)。

· 假如我们使用10TB的HDD做RAID5,1颗盘做热备,空间将会为: (16-1-1)×10TB×0.9 = 126TB. 记住要×0.9以得出硬盘的实际可用容量。
· 用扩展柜JBOD 3016连接每个节点,总容量将会达到: 126TB×20 = 2520TB = 2.5PB
· 纠删码4+1: 2.5PB×4/5 = 2PB

现在我们可以满足用户对性能与容量的要求了。现在还剩下存储与云的集成,用户可以在EonStor CS集群上创建一个云存储池,和云进行集成,这个要求也就得到了满足。最后我们来总结一下,向用户提供的EonStor CS集群的配置如下表所示:

我们提供这个示例的目的,是为了帮您理清配置EonStor CS存储系统的基本思路,实际应用场景要比示例复杂的多,如果您对于EonStor CS的配置有任何疑问,请联系Infortrend的售前团队,获取更多的细节内容。请关注Infortrend的微信公众号给我们留言,或登录我们的官网与专业的工程师进行深入的交流。

原文地址:https://blog.51cto.com/14113298/2457118

时间: 2024-07-30 10:05:46

怎么给客户出NAS集群方案?Infortrend这个示例让您豁然开朗的相关文章

架构设计:系统间通信(26)——ActiveMQ集群方案(下)

(接上文<架构设计:系统间通信(26)--ActiveMQ集群方案(上)>) 3.ActiveMQ热备方案 ActiveMQ热备方案,主要保证ActiveMQ的高可用性.这种方案并不像上节中我们主要讨论的ActiveMQ高性能方案那样,同时有多个节点都处于工作状态,也就是说这种方案并不提高ActiveMQ集群的性能:而是从集群中的多个节点选择一个,让其处于工作状态,集群中其它节点则处于待命状态.当主要的工作节点由于各种异常情况停止服务时,保证处于待命的节点能够无缝接替其工作. 3-1.Acti

Apache 2.4.12 64位+Tomcat-8.0.32-windows-x64负载集群方案

上次搞了Apache 2.2的集群方案,但是现在自己的机器和客户的服务器一般都是64位的,而且tomcat已经到8了.重新做Apache 2.4.12 64位+Tomcat-8.0.32-windows-x64负载集群方案. 知其然知其所以然,先看下一些关键术语: 1.负载均衡(load balance)在互联网高速发展的时代,大数据量.高并发等是互联网网站提及最多的.如何处理高并发带来的系统性能问题,最终大家都会使用负载均衡机制.它是根据某种负载策略把请求分发到集群中的每一台服务器上,让整个服

Infortrend亮相2019年台北国际电脑展,横向扩展NAS集群、云存储、AI一体机集体登场

Infortrend普安科技在2019年台北国际电脑展上展示了几条重要的产品线,向与会者显示我们应对数据管理和分析等需求的决心.具备高扩展性的横向扩展NAS,云存储解决方案.智能AI一体机将是我们重点推介的解决方案,这些方案能够帮助企业客户构建灵活的数据环境,在大数据和AI的潮流中持续推动产品与服务的前进. 如今各个行业都在经历数字化转型,数据已成为企业最宝贵的资产. 根据IDC的数据,2019年大数据和数据分析的总产值将达到1891亿美元,预计到2022年将增长到2743亿美元,复合年增长率为

PostgreSQL高可用性、负载均衡、复制与集群方案介绍

目录[-] 一.高可用性.负载均衡.复制的几个方案比较: 二.多节点集群方案比较 9.3官方文档(中文):http://58.58.27.50:8079/doc/html/9.3.1_zh/high-availability.html 复制.集群和连接池: https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling 集群方案功能列表: http://blog.osdba.net/46.html

Oracle的三种高可用集群方案

Oracle的三种高可用集群方案 主要有三种: 1. RAC RAC,  Real Application Clusters 多个Oracle服务器组成一个共享的Cache,而这些Oracle服务器共享一个基于网络的存储.这个系统可以容忍单机/或是多机失败. 不过系统内部的多个节点需要高速网络互连,基本上也就是要全部东西放在在一个机房内,或者说一个数据中心内.如果机房出故障,比如网络不通,那就坏了.所以仅仅用RAC还是满足不了一般互联网公司的重要业务的需要,重要业务需要多机房来容忍单个机房的事故

架构设计:系统存储(18)——Redis集群方案:高性能

1.概述 通过上一篇文章(<架构设计:系统存储(17)--Redis集群方案:高可用>)的内容,Redis主从复制的基本功能和进行Redis高可用集群监控的Sentinel基本功能基本呈现给了读者.虽然本人并不清楚上一篇根据笔者实际工作经验所撰写的文章有什么重大问题,导致那么多朋友集体点踩而且截止目前又没有任何人愿意为笔者指出这些问题,但是这不会影响笔者继续学习.总结技术知识的热情.从这篇文章开始我们一起来讨论Redis中两种高性能集群方案,并且在讨论过程中将上一篇文章介绍的高可用集群方案结合

架构设计:系统间通信(25)——ActiveMQ集群方案(上)

1.综述 通过之前的文章,我们讨论了ActiveMQ的基本使用,包括单个ActiveMQ服务节点的性能特征,关键调整参数:我们还介绍了单个ActiveMQ节点上三种不同的持久化存储方案,并讨论了这三种不同的持久化存储方案的配置和性能特点.但是这还远远不够,因为在生产环境中为了保证让我们设计的消息服务方案能够持续工作,我们还需要为消息中间件服务搭建集群环境,从而在保证消息中间件服务可靠性和处理性能. 2.ActiveMQ多节点方案 集群方案主要为了解决系统架构中的两个关键问题:高可用和高性能.Ac

关于redis集群方案

最近在研究redis集群方案,看到知乎上有个朋友写的观点很好,就先收过来了.原文见:http://www.zhihu.com/question/21419897 为什么集群? 通常,为了提高网站响应速度,总是把热点数据保存在内存中而不是直接从后端数据库中读取.Redis是一个很好的Cache工具.大型网站应用,热点数据量往往巨大,几十G上百G是很正常的事儿,在这种情况下,如何正确架构Redis呢? 首先,无论我们是使用自己的物理主机,还是使用云服务主机,内存资源往往是有限制的,scale up不

Redis集群方案应该怎么做

方案1:Redis官方集群方案 Redis Cluster Redis Cluster是一种服务器sharding分片技术. Redis3.0版本开始正式提供,解决了多Redis实例协同服务问题,时间较晚,目前能证明在大规模生产环境下成功的案例还不是很多,需要时间检验. Redis Cluster中,Sharding采用slot(槽)的概念,一共分成16384个槽.对于每个进入Redis的键值对,根据key进行散列,分配到这16384个slot中的某一个中.使用的hash算法也比较简单,CRC1