V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
THEcattail
V2EX  ›  程序员

小型工作室存储选型的一点思考和疑问

  •  
  •   THEcattail · 97 天前 · 4277 次点击
    这是一个创建于 97 天前的主题,其中的信息可能已经有所发展或是发生改变。

    有什么适合长期存储热数据(比如代码仓库、数据库、元数据之类的)的生产环境吗

    本地存储心里放心,但是需要大量运维精力,也缺乏应对极端故障的能力,考虑数据和服务最好在一个网络里就还要考虑拉商宽的成本,感觉有点得不偿失

    云托管是看到最多建议的方案,但是也比较担心运维和云平台耦合度高,未来有迁移需求比较麻烦的问题,另外这也是唯一一个成本会和读写次数/流量挂钩的方案

    还有一个个人还有点心仪的方案是租 idc 的服务器托管,但是看了一圈好像没有看到那种公认知名稳定的大品牌,数据安全系数是个未知数,对准备备份迁移的要求反而会更高

    第 1 条附言  ·  96 天前
    可能是表述得不太清楚,是需要跑一些需要持久化数据的服务,我想是先决定数据存储在哪里,才好决定服务跑在哪里,因此存储的方案也受服务所在环境的运维难度影响
    31 条回复    2024-09-22 23:30:26 +08:00
    kalayygl001
        1
    kalayygl001  
       97 天前   ❤️ 1
    买 2 台数据中心下架 dell 730xd 或者 740xd 一台做存储 配置上 raid 卡 一台做开发环境
    不考虑电费
    比云服务器便宜很多
    JensenQian
        2
    JensenQian  
       97 天前
    大厂的对象存储呗
    一般东西不大的话也没多少钱
    就是做好下防护,当心被人刷
    glcolof
        3
    glcolof  
       97 天前   ❤️ 1
    啊这……想太多了吧?
    我们公司直接找了台退役的电脑,固态盘装系统,两块 4TB 机械盘组镜像卷,安装 SVN Server ,开启系统自带的文件共享,定期用移动硬盘备份数据,移动硬盘有 2 块,其中一块保存在老板家里做异地存储,哪里需要“大量运维精力”呀。
    之前的公司规范一点,买的是戴尔的专业服务器,四块机械硬盘组建 2 组 RAID1 镜像,软件层面同样是 Windows 系统,SVN Server+文件共享,定期备份到局域网内的另一台服务器上(同样是 Windows+RAID1+文件共享)上,平时同样不需要运维。

    这种简单的系统,应对百年不遇的极端故障已经足够了。真遇到超百年不遇的极端故障,需要考虑的大概率是人还在不在,而不是数据在不在。
    ztm0929
        4
    ztm0929  
       97 天前 via iPhone
    是商业需要吗?凡是涉及到商业的先自己估算下 ROI (收入产出比),我个人认为作为小型团队,金钱的计算比精力的计算优先级更高。
    tomczhen
        5
    tomczhen  
       96 天前
    相对稳定的架构下,只要初始方案靠谱其实运维花费比较小。但是,只是能用的门槛太低了。见过买新服务器但是省钱只装一块硬盘的,还见过为了节省磁盘空间组 raid0 的。

    极端故障的应对就是需要钱,想省钱就需要明确能接受的故障恢复时间是多少。单机架构只要数据不丢,恢复时间能接受的越长,成本就可以降低。

    关键基础设施职能越单一越固定,那么运维难度就越低,不稳定和运维难很多时候就是想“省”。
    Jhma
        6
    Jhma  
       96 天前
    @glcolof 定时备份现在很容易搞定,但是出现 RAID 损毁甚至服务器开不了机的情况,怎样实现原系统原环境原数据快速恢复运行起来,这个就考验技术了。目前云上倒是可以实现服务器组跨地域做负载均衡和故障转移,计算存储网络均高可用,不过金钱的代价也高
    shakoon
        7
    shakoon  
       96 天前   ❤️ 1
    租机架找三大电信运营商将是了,没有比这更大牌的了
    akira
        8
    akira  
       96 天前
    代码仓库、数据库、元数据 这是 3 个不同的事情。。。感觉你们缺的不是存储方案,缺的东西多了。。
    glcolof
        9
    glcolof  
       96 天前
    @Jhma 镜像卷或者 RAID1 是指数据同时向两块硬盘写入,两块硬盘的数据总是一致的。购买硬盘的时候尽量不要买同品牌同批次的硬盘,两块硬盘同时损毁的概率是很低的,只要有一块硬盘没有坏,数据就不会丢失,恢复数据的时候也不需要额外的操作,直接把硬盘安装到新电脑上就可以正常使用了。这与 RAID0 或者 RAID5 之类的模式是完全不同的。

    何况还有定期的冷备份,就算遇到天灾,两块硬盘都坏了,还有冷备份的数据,并不会完全损失。如果有条件,还能结合云盘之类的方式进行额外的备份。
    huage
        10
    huage  
       96 天前
    直接云服务,可以多云
    daimaosix
        11
    daimaosix  
       96 天前 via Android
    运维靠谱的话并不需要大量的运维精力,大宝贝
    dann73580
        12
    dann73580  
       96 天前
    truenas+ups 就可以吧?一般其实没啥运维的,断电有 ups
    THEcattail
        13
    THEcattail  
    OP
       96 天前 via Android
    @akira 可能是表述得不太清楚,是需要跑一些需要持久化数据的服务,我想是先决定数据存储在哪里,才好决定服务跑在哪里,因此存储的方案也受服务所在环境的运维难度影响
    samli12
        14
    samli12  
       96 天前
    万国数据
    ShuWei
        15
    ShuWei  
       96 天前
    弄个 nas 不就解决了
    Jhma
        16
    Jhma  
       96 天前
    @glcolof 那可不一定哈,很多生产环境是 RAID5/6/50/60 ,作为一个合格的 IT 运维,也要考虑到 RAID1/10 的损毁,所以我在本地部署了 VSAN ,一个虚拟生产服务器还有另外两个副本,还是实时的,更没有最近冷备份到损毁前的数据差异,你这种思维是我多年前的认知
    libook
        17
    libook  
       96 天前 via Android
    我们十年的服务从一个云迁移到另一个云,服务用
    libook
        18
    libook  
       96 天前 via Android
    服务用容器,数据放数据库里,迁移没遇到耦合情况,除非你用了很多云服务自己的 api
    smdbh
        19
    smdbh  
       96 天前
    想省钱,只有自己多花时间和心思
    2 个二手硬盘的备份,比一个新企业盘可靠, 是否能接受这样的观点, 才有后面的方案
    testcgd
        20
    testcgd  
       96 天前 via Android
    线上服务上云,开发环境本地部署二手洋垃圾,核心数据定期往云备份,备份记得做演练,别备个寂寞
    sunchuo
        21
    sunchuo  
       96 天前
    如果带宽和流量需求多,不要考虑云了。原地倒闭。
    你描述的不是很清楚(多少数据、怎么使用、预计多大等)。所以没办法给你更具体的建议。
    linzyjx
        22
    linzyjx  
       96 天前
    内部研发环境,我们主要是内网需求比较大(做模型的,要放很多图片数据以及存储和训练)
    目前存储是直接用群晖,现在把一些核心基础服务( DNS 、Git 等服务)也挂到群晖上了。
    计算部分用的其它服务器,NFS 接群晖。
    datocp
        23
    datocp  
       96 天前 via Android
    之前用自己设的 raid1
    之后用了 22 个 sata 组了 8t ,我也不知道它是啥 raid 。哈哈,搞笑,自己都不知道服务器怎么组的。什么高 io 不如把自己的 erp 死锁问题做做好,这年头忽悠浪费甲方成本。

    平时也没那条件,本地备份,通过网络共享再备份一份到另外一台电脑,这么多年就是这么用来,没出事过。反而这个 22 盘方案,担心受怕的。

    1 天 3 备份,用自己熟悉的才是关键,高大上的东西看起来还是高大上。不说 raid 仍然保证不了数据被更换了嘛!

    那个 freebsd 的 zfs 倒是印象深刻,但也只占用了 2010 年银河 1t 估计前面 20g 空间。被我 1 个命令瞎工作,全盘清空。

    用自己不熟悉的东西才是灾难。
    oneisall8955
        24
    oneisall8955  
       96 天前
    设备功能专用,不要套在一起,否则有 allinboom 风险,存储归存储,代码仓库归代码仓库
    Admstor
        25
    Admstor  
       96 天前   ❤️ 1
    IDC 托管那边其实很少会说把你服务器卷跑的,因为实际上二手服务器并不之前且销赃困难,完全没必要
    最多就是带宽不达标,比如你想 100M 独享,但是实际上给你接在一个 1G 的共享口下,大部分情况你跑 100M 没啥问题,但是都跑满你肯定就收影响了,负责的监控预警及时调整,不负责的给你拖 2 天吃资源的走了你自然也就好了。

    然后如果你租用对方服务器就不一定给你全新的,很多都是二手清楚数据后给你用,当然肯定是能用的,你自己做好硬件监控,RAID 监控,反正托管租用期内的硬件故障肯定是免费更换,有些是满 XX 时间后,服务器就送你,你不托管了也可以拿走。

    但是这种模式说实在的,机房并不会很上心,各种监控还是需要你自己做的,你发现故障,提工单,才会给你处理(需要帮你监控得加钱)

    小规模还是上云便宜一些,当然了,上云的问题就是在于,规模扩大后,云就很贵了,人家也是靠这个赚钱的
    但是我觉得吧,如果你是刚开始,人手都不足,上云不要分散自己的精力,这点很重要
    GeekGao
        26
    GeekGao  
       96 天前
    "看了一圈好像没有看到那种公认知名稳定的大品牌" 你去当地找个 IDC 代理,租个柜子或者位置,签合同就行了啊。
    虽然小 IDC 存在网络抖动严重和割接频次多的问题,但是总体还好,毕竟价格美丽。
    Admstor
        27
    Admstor  
       96 天前   ❤️ 1
    对了你还没说你需要的容量和带宽

    大容量的云肯定贵的很,毕竟 10G 存储背后可能是 30G 的实际物理存储( RAID+容灾),大宽带的云也是贵的起飞

    如果你容量很大,也吃带宽,托管肯定是便宜许多的

    托管机房最好选择离你近,或者离你业务主要区域近的,然后有本地公司/分公司
    可以要求给个测试机器测带宽延迟,满意了再确定购买

    BGP/双线/三线也有具体的实现方式,可以跟技术对接询问下细节,例如本机 IP 是几个,是否需要自己做分流解析等
    如果没有跨区域的要求,找个本地机房单线大带宽就行了

    带宽还有共享/独享/95 计费等,共享独享只要线路优秀邻居良好差异不大,95 计费适合有极大的峰值,但是峰值持续时间很短,如果不是这种情况,95 计费会很贵,而且 95 计费一般只用于大带宽上
    Admstor
        28
    Admstor  
       96 天前
    得益于互联互通
    现在不要是延迟敏感的业务,单线在大部分地区也很不错了
    当然还是看你具体业务具体分析,找当地 IDC 问问就行了
    这行业虽然每年都有进去的,但是基本都是因为不和谐的问题导致的,很少会有卷机器跑路这种经济问题(苦笑)
    glcolof
        29
    glcolof  
       95 天前
    @Jhma 所以我的意思是,“小型工作室”,不是什么专业大公司,不想付出“大量运维精力”,用 RAID1 就够了,用 RAID5/6/50/60 之类的不是自讨苦吃么,连 RAID 01/10 都不合适。
    hefish
        30
    hefish  
       95 天前
    多买点硬盘嘛。。。
    之前有 qq 群里以为大佬表示,他接了 20 多个硬盘,然后分了 20 多个盘符...
    wangbin11
        31
    wangbin11  
       95 天前
    要兼职的运维嘛,2k 一月
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2938 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 11:18 · PVG 19:18 · LAX 03:18 · JFK 06:18
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.