每天进步一点点:在Linode上增加新卷以满足HIVE节点运行空间

随着hive节点数据量越来越大,原有的VPS附带的磁盘空间即将告罄。升级VPS到更高型号会大幅增加成本,所以最终我选择在原有VPS上增加个新卷来运行HIVE节点。

image.png
(图源 :pixabay)

我的见证人配置

在刚开始做见证人的时候,我使用的是Linode的64 GB内存型号的VPS,月租金320美元,为了安全起见,我还用同款VPS允许备份节点,这样一旦主节点坏掉,我可以随时切换。

这样我的见证人节点每月的服务器支出就是多达640美元,很长一段时间以来,见证人绝对是入不敷出的。在我和某TOP 20见证人聊天时,提到我的超豪华配置,被他一通鄙视,他说他主备节点加一起成本也不过300美元左右,并给我推荐一系列主机商。

但是我以我超豪华配置为荣呢,怎么能换主机商呢?于是我负担了好久640美元/月的成本。大概是HIVE硬分叉时,降低了内存占用,我试着在32G内存的机器上跑了一下,咦,竟然毫无问题,这样我的见证人成本(主备)降低至320美元/月。

HIVE价格低的时候就不必说了,肯定时还是入不敷出,但是如果HIVE价格维持在1美元附近时,我还能略有结余,不错不错。

空间不够了

不过前段时间,我发现一个很恐怖的事情——block_log的空间占用已经超过了550G!

Reveal spoiler

image.png

而Linode 32G内存的机型,附带的硬盘空间只有640 GB,也就是说去掉系统以及杂七杂八的东西,我的VPS硬盘即将爆炸!

一旦硬盘爆炸,见证人节点肯定会死翘翘了,好吧,其实我的见证人排名很低的,大概一个多小时才能轮到我出一次块,即便DOWN掉,对HIVE的影响也是微乎其微。但是作为一名有节操的见证人,怎么能让这种丢人的事情发生呢?必须想办法解决。

三种方案

一种最省心的方案就是从32G机型升级到64G机型,空间1280G,应该足够了:

Reveal spoiler

image.png

但是那样的话,我又要入不敷出了,哎,以前入不敷出时没觉得有多悲惨,但是用惯了便宜方案,再回归贵的,有点舍不得了呢。

还有方案就是选择其它服务商,比如换Amazon EC2啥的,不过一想到一堆东西要从头弄,就有点头大,而且前段时间我正偏头痛,一想,头更疼了。

所以最终选择的方案就是新加一个卷,然后把HIVED丢到这个新卷上运行。Linode的Block Storage $0.1/G/月,我先加一个800G的,估计再坚持个一年半载问题不大,等不够的时候再扩容,每月每台VPS增加$80的成本,貌似可以接受,就这么干了。

创建并绑定新存储卷

在Linode VPS上新增卷是很简单的事情,我们只需进到对应的VPS,然后选择Storage条目:

Reveal spoiler

image.png

在下边选择Create Volume

Reveal spoiler

image.png

然会就会在右侧弹出如下页面:

Reveal spoiler

image.png

创建成功后会提示如下配置信息页面:

Reveal spoiler

image.png

这时候进入到系统中,并使用sudo fdisk -l就会发现我们新创建并挂载的卷:

Reveal spoiler

image.png

因为喜欢小写的路径,所以对上述指令做了一些修改:

sudo mkfs.ext4 "/dev/disk/by-id/scsi-0Linode_Volume_WORK"
sudo mkdir /work
sudo mount "/dev/disk/by-id/scsi-0Linode_Volume_WORK" "/work"

/etc/fstab中添加如下内容:

/dev/disk/by-id/scsi-0Linode_Volume_WORK /work ext4 defaults,noatime,nofail 0 2

这样我们就完成新建存储卷并挂载到VPS的全过程,用sudo df -lh看一下,还剩747G,不错不错(咦,空间损失到哪里去了?算了不研究了):

Reveal spoiler

image.png

重新运行hived

有了新的存储卷以及足够的存储空间后,我选择创建了个新的用户,并把hived的全部数据迁移过去。

但是当我完成迁移并运行时,我发现原本启动很迅速的hived,竟然要好长时间才能加载起来。换句话说,新附加的存储卷似乎没有VPS自带的存储快

我理解可能自带的存储卷可能是本地存储,而新附加的应该是网络存储——尽管我不确定这种理解是否正确。

但是一个很现实的问题就是,如果存储不够快或者IOPS不够高,就可能对hived的运行产生一些影响,比如说影响出块!,难道我的努力都白费了吗?

好在我又找到一个折中的方法,那就是把见证人放在内存中运行——更确切地说是把shared_memory.bin放到内存中,这样,就不存在读写瓶颈了。

如何这样操作很简单,我在之前的文章晕,见证人节点真的炸掉了 & 在内存中replay HIVE节点介绍过在内存中replay HIVE节点,在内存中运行,是一样的操作,这里就不再赘述了。

这样操作后,节点关停和启动都非常迅速,运行了一段时间后,出块也没有任何问题,所以这个方案是完全可行的。

相关链接

Sort:  

Your content has been voted as a part of Encouragement program. Keep up the good work!

Use Ecency daily to boost your growth on platform!

Support Ecency
Vote for new Proposal
Delegate HP and earn more

辛苦了,欧哥,感谢您的付出.

感谢O哥,辛苦了!

敬 Hive“王国”默默付出的人。

VPS租金没想到这么贵,还好O哥找到了好办法,不至于那么亏。新加卷不仅实惠而且容量大,如果可以一直加,以后就不用担心不断升高的存储成本问题了。

神一样的操作。真心学不来