漫谈分布式存储的规划与设计

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/TM6zNf87MDG7Bo/article/details/79946945
序言

    闲来无事,所以。。谈谈规划。


    有的书看了之后,半夜睡不着,各种激动人心的观点,各种没有想到的一些新奇的想法和思维。。。这种看了之后,会失眠。。。


    有的书看了之后,想死的心都有,格格不入。。。怎么就选了这本书。。。


    看各种书籍,有的谈思想,有的谈具体操作,有的居然把官方文档搬上来凑数。。。这种。。。脑子里在想什么。。。


    看各种书籍,很多都涉及到各种具体的操作步骤,第一步怎么做,第二步怎么做,做完了,结束了。。。


    看分布式存储,里面都没有设计到如何来规划设计分布式存储。。。WHY?


    看容器化技术,里面都是介绍docker,容器,volume,network,storage。。。也没有提到如何去规划。。。。WHY?


    看到KVM,里面都是涉及到各种服务,各种创建VM,各种使用镜像。。。也没有提到如何去规划。。。。WHY?


    既然每个人都不谈规划,那么我就来妄谈规划!


分布式存储的规划设计

   场景:假设使用的具有中心节点的分布式存储,例如HDFS,中心节点称之为master节点,那么具体负责存储数据的为chunkserver,在master节点上需要运行相关的进程,进行调度服务,负载均衡,数据拷贝等服务,在chunkserver上需要运行具体存储数据的进程,负责与master之间的通信,负责汇报chunkserver的状态。


    那么现在就有了两种角色,一种是master,一种是chunkserver,在云环境中,运行服务的有很多种,可以运行在物理机上,可以运行在VM中,也可以运行在docker中,那么在开始规划的时候,这种如何来进行规划设计?


    考虑以下两者的作用,master是用来调度的,用来存储元数据的,是CPU密集型的应用,也就是说,只要CPU足够就好了,那么运行在VM中即可;而chunkserver,主要是用来保存数据的,那么是IO密集型的应用,对IO的需求比较大,而且是用来持久化存储的,从而必须运行在物理机中。


    那么在这个分布式的集群中,就由三个VM和N台物理机组成,为什么是三台VM?因为master需要选主,所以需要奇数台,你要有五台更好,可以容忍两个VM挂掉。。。不。。。我就要五个。。。我要两地三数据中心五副本。。。两个区域,一个在北京,一个在南京,那么在南京本地建立两个数据中心,在这两个数据中心中,分别分为2个master,从而。。挂哪一个都无所谓。。。


    有点扯远了,所以还是换回单个的数据中心,在其中部署一个私有云,私有云的分布式存储。。。


    假设chunkserver使用6台物理机,那么这几个master的VM也运行在这六台物理机上么?不!!!


    为了保证可靠性和可用性,所有的鸡蛋肯定不能放在一个篮子了,所谓狡兔三窟,所以一定要再找3台物理机,在每个物理机上创建一个VM,然后运行这个master。


    再思考一种场景,数据是安全可靠了,各种分片,各种数据分布,但是!!!如果master进程或者chunkserver进程挂了怎么办?


    从而需要一个检活的进程,市面上检活的工具也有很多,最常见的莫过于supervisor,当进程挂了,自动拉起来。。。。哦?你死了?复活吧,我的勇士!!!


    从而也就又有了两个VM,你问我为什么需要两个VM,这两个VM主要是用来做负载均衡的,或者主备的,主要就是为了保证检活的进程自己也要活着,毕竟万物不可靠,弄两个是最可靠的,。。。副本是分布式可靠性的唯一的保障手段!!!


    是不是就够了呢?不够。。。还需要一个工具的VM,你问我为什么需要一个tools的VM?因为在分布式存储中,有的时候进行各种批量的操作,例如检测chunkserver的日志,需要专门的工具或者sdk等;例如需要进行统计集群的剩余容量,你需要专门的工具;你需要检测各个进程的状态,你需要一个工具。所以这个tools不是必须的,但是。。。最好是有的,而且要把这个tools工具的VM做成免密的形式,因为这样才有批量操作的权利。


640?wx_fmt=png       

    这样是不是就够了呢?所有的进程都有了,所有的监控也有了,所有的日志也都保存了,所有告警???我的告警监控呢。。。


    告警监控,这个必须运行在每个服务器上,从而无论是物理机,还是VM,都需要运行这个监控程序,这样才能进行告警通知管理。。。但是你说我是分布式,我为什么还要告警呢?


    分布式能自动恢复,是否就不需要告警了,其实,可以认为是告警自愈不是更好,在那段时间告警,过短时间自动恢复,蛮好的。


    再考虑一种场景,我的生产系统需要一个分布式存储,我的测试环境需要一个分布式存储,我的开发环境也需要一个分布式存储。。。天天部署这种服务也心累。。。那么怎么办?


    模板。。。template,自动安装,必须自动,规划之中,给你几个ip,给你几个物理机,你自动去安装,你自己去写配置文件,你的模板不同,生成的分布式存储就不同,那么。。。这个就看你怎么设计你的模板了。


    所以每个人每天的时间都是24小时,不会多,也不会少,你怎么去规划?你怎么去设计?你的每天就是一个模板。。。。你能做到什么个性化设置?你每天又能积累多少。。。你每天又能持久化存储多少数据。。。大数据时代,你的每天经历就是你的UGC内容,那么你又能创造多少价值????


    JUST Thinking。。。。


等风来。。。。

    

640?wx_fmt=png

    微服务,不存在的。。。看看这种微服务,感觉爽不爽,惊不惊喜。。。刺激不刺激。。。(盗图)


    用了K8S就能改善么。。。并不会。。。

640?wx_fmt=png

    容器化应用,用了K8s就能改善么。。。乱花渐欲迷人眼。。。你猜我是哪个应用里面的容器。。。你猜我是哪个pod,,,你猜我是哪个service,,,你猜我猜不猜。。。。!!!


    不猜,你说!!!!

    

    JUST WAITING...............

640?wx_fmt=jpeg

 


阅读更多 登录后自动展开
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页