@msg7086 #12
45 盘位有点少啊

我这有垂直插放的机箱，不过是个 5U 的，因为 4U 下散热无法保证。

垂直插放的话，4 排，一排可以放 14 盘，实践最后改为 13 盘扩大一点间距为了走风，在磁盘下部安装大风扇，机箱下部打孔进风，同时高出的 1U 位置上部做水平无硬件阻挡风道快速排风，用的 AVC 12V 7A 的 90W 暴力 8CM 风扇做水平风道才让硬盘温度看起来不那么提心吊胆

考虑到垂直插放其实 4U 和 5U 的盘位数量应该是一致的 不过在主板区域我这额外做了 16 个 SSD 存储位

@opengps #9
不是自建机房
是自建高可用架构

另外 目前来说，我这边自建，云上都有，自建的可用性远比阿里云要高 尤其是你说的磁盘方面

磁盘损坏是正常的，有完整流程，我这每个月京东至少从我这拿走 50 块坏机械盘，80 块坏的 SSD 换新……

自建存储集群，就要管理水平上的去，一线维护我这全是啥也不懂的，就按章办事

如果你能自己解决 sas expander 的问题，这边有的成型方案里有定制的机箱，5U 高度，非热插拔垂直安装的机箱，不带背板，用数据线直连 expander，52 块 3.5 寸盘+16 块 2.5 寸 SSD 的存储机箱
但是实际运行过程中散热特别差，硬盘温度胆战心惊

懒得看视频
他这是多大密度？

我这机房有一堆 4U 36 块 3.5 寸盘位+4 块 2.5 寸 SSD 的 DIY 存储机箱
机箱好解决，主要是 sas expander 麻烦

裸奔 只要不安装来路不明安装软件，基本 100%安全

而且 value 什么鬼？

@skyshine725 #5
'$w' '$p'
你确定？

自建高可用架构啊

云计算的云盘连损失都不赔的 技术角度讲本身就不是可靠性很强的东西

云计算帮你解决的是基础硬件维护问题

物理文件损坏了？

独到的测试方式：

安装 thinksns plus 后给数据库添加了少量数据，保证每个接口都是有数据的状态；然后在服务器本地压测一些常用的数据读取接口，压测结果吞吐量为 30QPS 左右。

@o0 #3
感觉策划部门又可以领奖金而不是去 shi 了
又骗来一堆人

没问题。虽然我不用。

从快照新建虚拟机没有么？

@msg7086 #16
你不了解我的需求 把整体架构实现目标从早晨解释到晚上意义也不大

简单说 系统维护部分的需求 就是要各种基本 apt 安装的应用层包的统一升级维护 版本一致性保持 应用层的还有应用层的系统自动化维护机制

现在采用的最省事的办法就是各家的自己直接带的系统（方便有时候的批量起按需实例从 api 直接创建和销毁 也方便傻瓜客户自己购买云服务器） 只要保持外部版本号一致，采用同一个 apt 源就能保证应用层软件的系统维护指令一致时的版本一致性

这些云服务，尤其是国内的，基础结构都有不少 hack，有运维团队单纯的自己想往里搞东西并不是很费劲，但是后续的维护就不可避免的可能出现莫名其妙的问题导致不省心

全部 ubuntu server 的基本服务器应用软件都是基于 apt 包管理安装，自定义的东西也是发布成内部源或者 ppa 源 这个结构是经过多年的结合实际摸索出来的套路 因为涉及很多客户自采半自维服务器 云服务账号 API 都没有，安装我们的引导软件接入平台统一管理 还有一些其他的更乱套的场景需要更细致的

@msg7086 #14
不全是阿里的啊
主要是外部版本号一致 就比较方便的分发和控制包版本，从同一个 apt 源弄出来的软件包都是同样的版本没有差异
有些弹性部署的节点当然是自动化的 但是你自动化创建完事再做可能一堆问题的跨版本升级就蛋疼了

@zocome #10
显然是为了集中部署统一管理需求的 多于 2000 台计算节点

一点数据库基础没有的还不会准备资料的从 0 开始提问学习 DB 优化