运维123 - 云计算
type: channel
link: https://sddts.cn/index.php/category/%E4%BA%91%E8%AE%A1%E7%AE%97/
items: OpenAI 将 PostgreSQL 扩展至 8 亿用户的技术实践
items: WSIStreamer 云原生 WSI 流媒体服务器技术分析
items: 202601171730.AWS：European：Sovereign：Cloud：Technical：Analysis
items: Proxmox VE 精简配置存储耗尽故障案例分析
items: 基于 vmware_exporter 的 ESXi 监控方案技术分析
items: VMware 到 KubeVirt 大规模迁移技术分析
items: Microsoft AI 数据中心电力成本承担计划技术分析
items: Manus Sandbox 云计算机技术分析
items: 下载了一些超融合的招标文件包含技术参数
items: UCloud发送短信失败

OpenAI 将 PostgreSQL 扩展至 8 亿用户的技术实践
type: item
date: 2026-01-23T12:19:15+00:00
description: OpenAI 将 PostgreSQL 扩展至 8 亿用户的技术实践一、新闻概述1. 标题Scaling PostgreSQL to power 800 million ChatGPT users（将 PostgreSQL 扩展至支持 8 亿 ChatGPT 用户）2. 发布时间2025 年 12 月 12 日3. 来源OpenAI 官方博客4. 作者Bohan Zhang，OpenAI 技术团队成员二、核心内容1. 事件摘要A. 主要内容OpenAI 详细介绍了如何通过单一主节点 Azure PostgreSQL 实例和近 50 个跨多地域的只读副本，将 PostgreSQL 扩展至支持每秒数百万次查询，服务于 8 亿用户。B. 核心亮点单主节点架构支持 8 亿用户规模每秒处理数百万次查询（QPS）跨地域部署近 50 个只读副本实现个位数毫秒级 p99 延迟达到 99.999% 可用性（五个九）2. 关键信息A. 规模数据用户数量：8 亿查询量：每秒数百万次副本数量：近 50 个只读副本负载增长：过去一年增长超过 10 倍B. 技术指标p99 延迟：个位数毫秒级可用性：99.999%（五个九）复制延迟：接近零SEV-0 事故：过去 12 个月仅 1 次C. 涉及技术Azure PostgreSQL Flexible ServerPgBouncer 连接池级联复制（Cascading Replication）缓存层与缓存锁定机制3. 背景介绍A. PostgreSQL 简介PostgreSQL 是由加州大学伯克利分校科学家创建的开源关系数据库系统，以其可靠性和功能丰富著称。B. OpenAI 的使用场景PostgreSQL 是 OpenAI 核心产品（如 ChatGPT 和 API）的关键数据系统，承载了大量读密集型工作负载。三、详细报道1. 主要内容A. 架构设计OpenAI 采用了单主节点多副本的架构：1 个主节点（Primary）处理所有写入近 50 个只读副本（Read Replicas）分布在全球多个地域使用 PgBouncer 作为连接池代理层实施多层级速率限制B. 扩展策略读扩展：将读请求尽可能卸载到只读副本跨地域部署副本以降低延迟使用缓存层减少数据库读压力写扩展：将可分片的写密集型工作负载迁移到分片系统（如 Azure Cosmos DB）优化应用逻辑减少不必要的写入引入延迟写入以平滑流量峰值C. 技术改进优化查询性能，避免复杂的多表连接实施工作负载隔离，防止"吵闹邻居"问题部署 PgBouncer 降低连接建立时间（从 50ms 降至 5ms）实现缓存锁定机制防止缓存未命中风暴2. 技术细节A. 系统架构graph TB Client[客户端] --> Proxy[代理层/PgBouncer] Proxy --> Primary[主节点/Primary] Proxy --> Replica1[副本1/美国] Proxy --> Replica2[副本2/欧洲] Proxy --> Replica3[副本3/亚洲] Proxy --> ReplicaN[副本N/其他区域] Primary -->|WAL流复制| Replica1 Primary -->|WAL流复制| Replica2 Primary -->|WAL流复制| Replica3 Primary -->|WAL流复制| ReplicaN Cache[缓存层] -.读请求.-> ClientB. MVCC 挑战PostgreSQL 的多版本并发控制（MVCC）实现使其在写密集型工作负载下效率较低：更新操作会复制整行创建新版本导致写放大和读放大引发表和索引膨胀增加自动清理（autovacuum）调优复杂度C. 性能指标连接建立延迟：从 50ms 降至 5ms（使用 PgBouncer）p99 客户端延迟：保持在个位数毫秒级复制延迟：接近零可用性：99.999%D. 复制架构演进当前架构：主节点向所有副本流式传输 WAL 日志未来计划：级联复制graph LR Primary[主节点] -->|WAL| Intermediate[中间副本] Intermediate -->|WAL| Replica1[下游副本1] Intermediate -->|WAL| Replica2[下游副本2] Intermediate -->|WAL| ReplicaN[下游副本N]3. 数据与事实A. 扩展历程过去一年 PostgreSQL 负载增长超过 10 倍从少量副本扩展到近 50 个副本从 ChatGPT 发布时的基础设施问题到现在的稳定运行B. 事故记录过去 12 个月仅发生 1 次 SEV-0 级别 PostgreSQL 事故该事故发生在 ChatGPT Im…

WSIStreamer 云原生 WSI 流媒体服务器技术分析
type: item
date: 2026-01-18T13:20:12+00:00
description: WSIStreamer 云原生 WSI 流媒体服务器技术分析一、项目概述1. 项目背景WSIStreamer 是一个现代化的云原生全切片图像瓦片服务器。全切片图像通常体积巨大（1-3GB+），传统查看器需要下载整个文件才能显示单个瓦片，这在云存储场景下效率极低。2. 核心创新WSIStreamer 采用完全不同的方法：原生理解切片格式，通过 HTTP Range 请求仅获取所需的字节，立即返回 JPEG 瓦片。这实现了真正的按需流式传输，无需本地文件存储。3. 项目亮点一行命令启动服务：无需配置文件、无本地存储、无复杂设置云原生设计：直接从 S3 兼容对象存储服务生产级就绪：支持 HMAC-SHA256 签名 URL 认证多级缓存：切片、块、编码瓦片三级缓存机制二、技术架构1. 系统架构WSIStreamer 采用分层架构设计，核心是理解 WSI 格式并按需提取数据。graph TB Client[客户端浏览器] -->|HTTP 请求| Server[WSIStreamer 服务器] Server -->|Range 请求| S3[S3 兼容存储] Server -->|格式解析| Parser[Rust 解析器] Parser -->|Aperio SVS| SVS[SVS 格式] Parser -->|Pyramidal TIFF| TIFF[TIFF 格式] Server -->|JPEG 瓦片| Client Server -->|多级缓存| Cache[缓存系统] Cache --> L1[切片缓存] Cache --> L2[块缓存] Cache --> L3[瓦片缓存]2. 核心组件A. 格式解析器Aperio SVS 解析器：处理 SVS 格式医学图像Pyramidal TIFF 解析器：支持金字塔 TIFF 格式压缩支持：JPEG、JPEG 2000B. 存储适配器AWS S3 原生支持S3 兼容存储（MinIO、Ceph 等）HTTP Range 请求优化C. 缓存系统切片级缓存：默认最多 100 个切片块级缓存：减少重复的 Range 请求瓦片缓存：编码后的 JPEG 瓦片，默认 100MBD. Web 查看器基于 OpenSeadragon支持平移、缩放深色主题3. 工作流程sequenceDiagram participant U as 用户浏览器 participant W as WSIStreamer participant S as S3 存储 U->>W: 请求瓦片 /tiles/slide.svs/0/0/0.jpg W->>W: 检查缓存 alt 缓存命中 W-->>U: 返回 JPEG 瓦片 else 缓存未命中 W->>W: 解析切片文件结构 W->>S: Range 请求（仅所需字节） S-->>W: 返回图像块数据 W->>W: 解码并裁剪瓦片 W->>W: JPEG 编码 W->>W: 存入缓存 W-->>U: 返回 JPEG 瓦片 end三、技术实现1. 开发语言与框架语言：Rust 97.1%（Shell 2.3%、Dockerfile 0.6%）Web 框架：基于 Rust 异步运行时图像处理：原生 Rust 实现2. 核心功能A. Range 请求优化// 伪代码示例 async fn fetch_tile_range(s3_client: &S3Client, slide_id: &str, offset: u64, length: u64) -> Vec<u8> { s3_client.get_object() .bucket(slide_id) .range(format!("bytes={}-{}", offset, offset + length - 1)) .send() .await .body() .collect() }B. 多级缓存实现L1：切片元数据缓存（避免重复解析文件头）L2：块数据缓存（减少 Range 请求）L3：编码瓦片缓存（直接返回 JPEG）C. 认证机制支持 HMAC-SHA256 签名 URL 认证：graph LR A[客户端] -->|1. 请求签名| B[签名服务] B -->|2. 生成签名URL| A A -->|3. 带签名请求| C[WSIStreamer] C -->|4. 验证签名| C C -->|5. 返回瓦片| A3. API 设计A. RESTful 端点端点方法描述/healthGET健康检查/view/{slide_id}GETWeb 查看器/tiles/{slide_id}/{level}/{x}/{y}.jpgGET获取瓦片/slidesGET列出所有切片/slides/{slide_id}GET…

202601171730.AWS：European：Sovereign：Cloud：Technical：Analysis
type: item
date: 2026-01-17T07:34:29+00:00
description: AWS 欧洲主权云正式发布：欧盟数字主权里程碑一、新闻概述1. 标题AWS 欧洲主权云正式发布2. 发布时间2026 年 1 月 14 日3. 来源AWS 官方博客二、核心内容1. 事件摘要A. 主要内容AWS 宣布 AWS European Sovereign Cloud（欧洲主权云）正式对所有客户开放。这是首个完全独立运营、功能齐全的欧盟主权云解决方案，旨在满足欧洲公共部门和高监管行业最严格的主权要求。B. 核心亮点首个区域位于德国勃兰登堡州，现已全面可用完全独立的云基础设施，所有组件位于欧盟境内由欧盟居民运营，逐步过渡到仅由欧盟公民运营78 亿欧元投资计划，预计到 2040 年将为欧洲经济贡献 172 亿欧元2. 关键信息A. 版本号/发布内容AWS European Sovereign Cloud 一般可用（GA）B. 重要数据投资额：78 亿欧元预期经济贡献：172 亿欧元（至 2040 年）年均支持岗位：约 2800 个全职等效岗位分区名称：aws-eusc区域名称：eusc-de-east-1C. 涉及产品/技术Amazon EC2、AWS LambdaAmazon SageMaker、Amazon Bedrock（AI/ML）Amazon EKS、Amazon ECS（容器编排）Amazon Aurora、DynamoDB、Amazon RDS（数据库）Amazon S3、Amazon EBS（存储）3. 背景介绍A. 前置版本/历史AWS 于 2023 年首次宣布建设欧洲主权云的计划，这是继该项目启动后的重要里程碑。B. 相关上下文欧洲组织面临日益复杂的数据驻留、运营控制和治理独立性监管要求。此前，具有最高主权要求的欧洲组织被迫停留在传统本地环境或使用功能受限的云服务。三、详细报道1. 主要内容A. 功能更新AWS European Sovereign Cloud 提供与标准 AWS 区域相同的服务能力，从发布之日起即可访问广泛的 AWS 服务，包括 AI/ML 工作负载的 Amazon SageMaker 和 Amazon Bedrock。B. 技术改进独立的法律实体：根据德国法律建立的专门欧洲法律实体管理专属运营团队：仅由欧盟居民运营，正在过渡到仅由欧盟公民运营技术控制：防止从欧盟外部访问的基础设施内置技术控制证书机构：专门的欧洲信任服务提供商C. 政策变化2025 年 10 月，AWS 任命 Stéphane Israël（欧盟公民，居住在欧盟）为总经理。2026 年 1 月，任命 Stefan Hoechbauer 为联合总经理。2. 技术细节A. 架构变化graph TB subgraph 欧盟边界 A[德国区域 eusc-de-east-1] B[比利时 Local Zone] C[荷兰 Local Zone] D[葡萄牙 Local Zone] E[专属 Local Zones] F[AI Factories] G[Outposts] end A --> H[独立 IAM 系统] A --> I[独立计费系统] A --> J[欧洲信任服务提供商] A --> K[专属 Route 53 服务器] H --> L[客户工作负载] I --> L J --> L K --> L style A fill:#2563eb style B fill:#16a34a style C fill:#16a34a style D fill:#16a34aB. 性能指标多个可用区设计，具有冗余电源和网络即使与世界其他地方的连接中断也能持续运行支持所有标准 AWS 访问方法：管理控制台、AWS SDK、AWS CLIC. 兼容性说明使用熟悉的 AWS 架构、服务组合和 API，便于构建和迁移应用程序。支持现有 AWS 工作流程和自动化工具的无缝集成。3. 数据与事实A. 性能对比与标准 AWS 区域相同的性能和安全能力，包括加密、密钥管理、访问治理和 AWS Nitro 系统。B. 用户数据所有内容保留在用户选择的区域内，客户创建的元数据（角色、权限、资源标签、配置）也保留在欧盟内。C. 市场数据AWS 合作伙伴生态系统包括 Adobe、Cisco、Cloudera、Dedalus、Esri、Genesys、GitLab、Mendix、Pega、SAP、SnowFlake、Trend Micro 和 Wiz。四、影响分析1. 行业影响A. 竞争格局AWS 是首个提供完全独立主权云的云服务提供商，这将在欧洲云市场产生显著竞争优势。B. 技术趋势主权云成为全球趋势，各地区的监管机构要求数据驻留和运营控制。这一发布可能推动其他云服务提供商推出类似解决方案。2. 用户影响A. 现有用户欧洲公共部门实体和高监管行业（金融、…

Proxmox VE 精简配置存储耗尽故障案例分析
type: item
date: 2026-01-16T12:39:16+00:00
description: Proxmox VE 精简配置存储耗尽故障案例分析一、事件概述1. 事件背景某企业生产环境使用 Proxmox VE（PVE）虚拟化平台，在业务运行过程中遭遇核心业务全面瘫痪。9 台运行关键业务的虚拟服务器同时无法启动，PVE 管理界面显示所有虚拟机处于"已暂停"状态。2. 影响范围A. 影响范围9 台核心业务虚拟机全部停机B. 影响时长从故障发现到完全恢复约 2 小时C. 影响功能所有依赖虚拟机的业务系统，包括 ERP 系统、数据库服务、文件服务等核心业务3. 严重程度P0 级故障（生产环境全面停机）二、事件时间线1. 故障发现（大清早）A. 现象描述接到紧急报障电话，用户报告生产环境全面瘫痪。登录 PVE 管理界面发现，9 台虚拟机全部显示"已暂停"状态，点击"启动"按钮无任何响应。B. 初步检查PVE 宿主机可以正常登录执行 df -h 显示根分区使用率 100%dmesg 日志持续刷出"no space left on device"错误2. 问题定位（30 分钟后）A. 存储配置分析通过现场勘查发现存储配置如下：硬件配置：2 块 500GB SSD 组成 RAID1 作为存储虚拟机配置：9 台虚拟机各配置 100GB 精简配置（Thin Provisioning）硬盘理论需求：9×100GB = 900GB（远超物理容量 500GB）B. 根本原因LVM-Thin 的精简配置特性允许"超额分配"，系统初期不会报错。但随着虚拟机数据持续写入，实际占用逐渐超过物理容量，最终导致存储空间完全耗尽，所有依赖该存储的虚拟机因无法分配新块而挂起。graph TB A[初始状态] -->|9台VM各100GB精简配置| B[超额分配] B -->|实际占用<500GB| C[正常运行] C -->|数据持续写入| D[占用增长] D -->|物理空间耗尽| E[存储锁死] E -->|无法分配新块| F[VM全部暂停]3. 应急响应（1 小时内）A. 紧急诊断执行 pvesm status -h 确认 local-lvm 存储已满，必须立即扩容。B. 硬件扩容新增 1TB SATA SSD，通过热插拔方式插入服务器。C. LVM 扩容将新硬盘加入原卷组并扩展 Thin Pool，恢复可用空间。D. 虚拟机恢复扩容完成后，直接启动所有虚拟机，无需迁移或修改配置。三、问题分析1. 直接原因物理存储容量不足，500GB 硬盘承载了 900GB 的虚拟机配置（超配 80%），且使用精简配置导致实际占用随时间增长直至耗尽。2. 根本原因分析A. 为什么出现这个问题？存储规划时未考虑精简配置的实际占用特性追求"超配"带来的成本优势，忽视了风险缺少存储空间监控和告警机制B. 为什么没有及时发现？没有配置存储使用率监控没有设置 Thin Pool 使用率告警缺少定期巡检机制C. 为什么没有自动恢复？虚拟机因存储耗尽而挂起，无法自动恢复缺少自动清理临时空间的机制未配置存储自动扩容3. 深层反思这是典型的"小气"存储规划遇上业务增长的必然结果。精简配置虽然是虚拟化的优势之一，但必须配合合理的容量规划和完善的监控体系，否则会埋下严重隐患。四、解决方案1. 临时方案（本次实施）A. 实施措施热插拔新增 1TB SATA SSD将新硬盘创建为物理卷并加入 pve 卷组扩展 Thin Pool 逻辑卷至所有可用空间刷新 Thin Pool 元数据使 PVE 识别新空间B. 关键操作步骤阶段 1：识别新硬盘lsblk # 发现新硬盘 sdb，931.5G阶段 2：分区并创建 LVM 物理卷parted /dev/sdb # 创建 GPT 分区表，单分区，标记为 LVM pvcreate /dev/sdb1阶段 3：扩展卷组和 Thin Poolvgextend pve /dev/sdb1 lvextend -l +100%FREE /dev/pve/data lvchange --refresh pve/data阶段 4：验证扩容结果lvdisplay /dev/pve/data df -h /var/lib/vzC. 效果评估存储空间从 100% 降至合理范围虚拟机可直接启动，无需迁移业务完全恢复，数据未丢失2. 永久方案A. 改进措施存储规划公式物理容量 ≥ (单台最大需求 × 数量) × 1.5（冗余系数）正确配置：9 台 100GB 虚拟机需要至少 1350GB 物理容量或者减少数量：500GB 容量建议不超过 3 台 100GB 虚拟机配置 RAID 保护使用 RAID 1（镜像）保护关键数据或使用 RAID 10（性能+冗余）至少使用 RAID 5（单盘容错）实施存储配额为每个虚拟机设置合理的磁盘配额，防止单个虚拟机占用过多空间。B. 实施计划1 …

基于 vmware_exporter 的 ESXi 监控方案技术分析
type: item
date: 2026-01-16T01:41:43+00:00
description: 基于 vmware_exporter 的 ESXi 监控方案技术分析一、概述1. 背景A. 业务场景数据中心和边缘节点大量使用 VMware ESXi 承载计算资源。稳定性和容量可视化是基础运维诉求，统一监控体系需要纳入 ESXi 与 vCenter 的指标。B. 技术挑战多集群、多 vCenter 环境下的统一监控ESXi 与 vCenter 指标的标准化采集监控数据的统一存储与可视化展示告警规则的统一管理与路由分发2. 设计目标A. 功能目标使用 vmware_exporter 采集 ESXi/vCenter 指标通过 Docker Compose 编排部署监控组件将指标接入 Prometheus 进行时序存储使用 Grafana 构建可视化仪表盘通过 Watchalert 实现端到端告警管理B. 非功能目标支持多数据中心、多 vCenter 并行采集提供开箱即用的配置模板支持自签证书场景实现高可用的监控架构二、架构设计1. 系统架构graph TB subgraph VMware基础设施 ESXi1[ESXi主机集群1] ESXi2[ESXi主机集群2] vCenter[vCenter服务器] end subgraph 采集层 Exp1[vmware_exporter 北京集群:9272] Exp2[vmware_exporter 南京集群:9273] end subgraph 存储层 Prometheus[Prometheus 时序数据库] end subgraph 告警层 Watchalert[Watchalert 告警路由与通知] end subgraph 可视化层 Grafana[Grafana 仪表盘] end ESXi1 --> vCenter ESXi2 --> vCenter vCenter --> Exp1 vCenter --> Exp2 Exp1 --> Prometheus Exp2 --> Prometheus Prometheus --> Watchalert Prometheus --> Grafana Watchalert -->|告警通知|运维团队2. 组件说明A. vmware_exporter版本：0.18.4功能：连接 vCenter 或直接 ESXi，暴露 Prometheus 格式的 /metrics 接口开源地址：https://github.com/pryorda/vmware_exporterB. Prometheus版本：3.5.0 LTS功能：抓取 exporter 指标，存储时序数据提供 PromQL 查询语言C. Watchalert版本：3.8.0功能：接收 Prometheus 数据，配置监控项与告警表达式，支持 webhook 通知支持告警聚合、抑制、路由D. Grafana版本：10.2.3功能：可视化查询与仪表盘展示支持多种数据源和丰富的图表类型三、环境准备1. 前置条件A. 网络与账户确保可访问 vCenter 或 ESXi 的网络连通性准备只读账户，避免使用管理员账户密码通过环境变量或外部秘密管理，禁止硬编码B. Docker 环境安装 Docker 与 Docker Compose确保容器间网络通信正常C. 监控基础设施部署好 Prometheus、Watchalert 与 Grafana确保各组件间网络可达2. 组件版本清单组件名称版本说明vmware_exporter0.18.4ESXi/vCenter 指标采集Prometheus3.5.0 LTS时序数据存储Watchalert3.8.0告警管理Grafana10.2.3可视化展示四、部署实施1. vmware_exporter 部署A. 环境变量配置支持多集群、多 vCenter 场景，为每个集群创建独立的配置文件：config-bj.env（北京集群）：VSPHERE_USER=administrator@vsphere.local VSPHERE_PASSWORD='xxxxxx' VSPHERE_HOST=172.10.30.1 VSPHERE_IGNORE_SSL=TRUE VSPHERE_SPECS_SIZE=2000config-nj.env（南京集群）：VSPHERE_USER=administrator@vsphere.local VSPHERE_PASSWORD='xxxxxx' VSPHERE_HOST=172.22.33.1 VSPHERE_IGNORE_SSL=TRUE VSPHERE_SPECS_SIZE=2000B. Docker Compose 编排version: '3.8' services: vmware_exporter_nj: image: dock…

VMware 到 KubeVirt 大规模迁移技术分析
type: item
date: 2026-01-15T12:41:25+00:00
description: VMware 到 KubeVirt 大规模迁移技术分析一、背景概述1. 迁移动机本次迁移项目源于 VMware 续费报价上涨 3 倍，成本压力迫使企业寻找替代方案。原环境运行约 2000 台虚机，涵盖业务系统、数据库、中间件等各类工作负载。2. 技术选型分析在方案评估阶段，团队对多个虚拟化平台进行了对比分析：方案优点缺点最终评估OpenStack成熟稳定，社区活跃架构复杂，运维成本高排除Proxmox VE开源免费，界面友好企业级功能欠缺备选oVirtRed Hat 支持社区萎缩，未来不明排除KubeVirt云原生，统一管理相对年轻，学习曲线陡最终选择3. 选择 KubeVirt 的核心原因统一技术栈：现有容器平台已使用 Kubernetes，虚机和容器统一管理可降低运维复杂度渐进式迁移：同一集群可同时运行容器和虚机，业务可逐步迁移避免厂商锁定：纯开源方案，避免被单一厂商卡脖子成本控制：年度基础设施成本预期降低 60% 以上二、技术架构分析1. KubeVirt 核心组件KubeVirt 在 Kubernetes 之上构建虚拟化管理层，通过自定义资源定义（CRD）扩展 Kubernetes API。graph TB subgraph KubeVirt A[virt-api] B[virt-controller] C[virt-handler DaemonSet] end subgraph Libvirt D[libvirt + QEMU/KVM] end subgraph Node E[Linux with KVM support] end A --> F[VirtualMachine CRD] B --> G[VMI] C --> D D --> E组件功能说明virt-api：提供 KubeVirt API 入口，处理 VirtualMachine 等 CRD 的请求virt-controller：监听 VM 相关资源变化，负责创建对应的 VMI（VirtualMachineInstance）virt-handler：以 DaemonSet 形式部署在每个节点，负责虚机生命周期管理virt-launcher：每个虚机对应一个 Pod，内部运行 libvirt 和 QEMU 进程2. 环境配置硬件配置计算节点：Dell PowerEdge R750xs双路 Intel Xeon Gold 6348（28 核 56 线程）512GB DDR4 ECC 内存2 x 1.92TB NVMe SSD（本地缓存）存储：Dell PowerStore 5200T，100TB 可用容量，iSCSI 连接网络：Mellanox ConnectX-6 Dx 100GbE 双端口网卡，配置 bond软件版本组件版本操作系统Rocky Linux 8.9Kubernetes1.28.4（kubeadm 部署）KubeVirt1.1.1CDI1.58.1Longhorn1.5.3（后期替换）Rook-Ceph1.12.9（最终采用）Multus4.0.2OVN-Kubernetes与 K8s 集成节点规模Master 节点：3 台计算节点：42 台（其中 18 台专用于虚机负载）三、迁移实施1. 迁移流程graph LR A[VMware] -->|virt-v2v| B[QEMU/KVM] B -->|qcow2| C[CDI Import] C -->|DataVolume| D[KubeVirt] E[Longhorn] -.拒绝.-> F[性能不足] G[Rook-Ceph] -->|采用| D2. 存储方案演进存储是迁移过程中最关键的组件。项目初期采用 Longhorn，但在大规模虚机场景下性能不足，两个月后切换至 Rook-Ceph。Rook-Ceph 配置要点使用 NVMe 设备作为 OSD 存储介质配置三副本策略保证数据可靠性启用压缩模式降低存储占用为虚机负载创建专用存储池RBD StorageClass 配置apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: rook-ceph-block-vm provisioner: rook-ceph.rbd.csi.ceph.com parameters: clusterID: rook-ceph pool: replicapool-vm imageFormat: "2" imageFeatures: layering,fast-diff,object-map,deep-flatten,exclusive-lock reclaimPolicy: Delete allowVolumeExpansion: true …

Microsoft AI 数据中心电力成本承担计划技术分析
type: item
date: 2026-01-15T08:29:34+00:00
description: Microsoft AI 数据中心电力成本承担计划技术分析一、新闻概述1. 标题Microsoft 承诺防止 AI 数据中心推高居民电费2. 发布时间2026 年 1 月 13 日3. 来源CNN Business二、核心内容1. 事件摘要A. 主要内容Microsoft 宣布在建设 AI 数据中心的地区，将主动承担更高的电力账单，以防止当地居民的电力价格上涨。这是科技公司为解决大规模 AI 基础设施建设引发的成本和环境担忧而采取的最新措施。B. 核心亮点承诺支付超出实际用电量的电网升级费用不寻求房产税减免或优惠投资当地水资源系统、图书馆和学校提供就业和 AI 技能培训2. 关键信息A. 成本增幅数据根据 Bloomberg News 2025 年分析，数据中心附近地区的电力成本与五年前相比上涨了高达 267%。B. 投资承诺规模大型科技公司正在投入数千亿美元建设 AI 数据中心，这些设施消耗大量电力。C. 政策响应特朗普政府表示正在与大型科技公司合作，确保美国人不因科技公司的电力消耗而承担更高的水电费账单。3. 背景介绍A. AI 基础设施建设热潮硅谷和国会领袖将 AI 基础设施建设定位为经济和国家安全的必要项目，但其引发的电力成本上涨引发了当地社区的强烈反对。B. 社区关切许多美国人认为他们并未要求 AI 建设，且担心无法从中受益，尤其是考虑到科技领袖警告 AI 可能导致就业岗位流失。三、系统分析1. 数据中心电力需求模型A. 电力消耗组成graph TD A[AI 数据中心] --> B[计算设备功耗] A --> C[冷却系统功耗] A --> D[辅助设施功耗] B --> E[GPU 集群] B --> F[CPU 服务器] B --> G[网络设备] C --> H[精密空调] C --> I[液冷系统] D --> J[UPS] D --> K[照明与监控]B. 电力需求特征组件类别功耗占比特征计算设备50-60%随 AI 计算负载波动冷却系统30-40%与计算设备功耗正相关辅助设施10-15%相对稳定2. 电网影响机制A. 电力成本传导路径graph LR A[数据中心] -->|增加用电需求| B[本地电网] B -->|电网容量不足| C[电网升级] C -->|资本支出| D[电力公司] D -->|成本分摊| E[所有用户] E --> F[居民电费上涨]B. 问题根源传统模式下，电网升级成本由所有用户分摊。当高功耗的数据中心入驻后，会触发电网扩容需求，但这些成本被平均分摊到所有电力用户，导致居民电费上涨。3. Microsoft 解决方案架构A. 成本承担模式graph TD subgraph 传统模式 T1[数据中心] -->|标准电费| T2[电力公司] T3[居民用户] -->|标准电费| T2 T4[电网升级] -->|成本分摊| T2 T2 -->|涨价| T3 end subgraph Microsoft 模式 M1[数据中心] -->|标准电费| M2[电力公司] M1 -->|承担升级费用| M2 M3[居民用户] -->|标准电费| M2 M4[电网升级] -->|由数据中心承担| M2 M2 -->|价格不变| M3 endB. 承诺内容详解电力成本承担支付数据中心实际消耗的电力费用承担电网升级和扩容的资本支出确保这些成本不转嫁给其他本地公用事业用户水资源承诺当数据中心需要抽取当地水资源时，支付水资源补充费用与地方政府合作修复管道泄漏财政贡献不寻求房产税减免或优惠投资当地水系统、图书馆和学校社区投资建筑工人就业培训数据中心运营人员培训AI 技能培训项目四、技术细节分析1. 数据中心电力需求规模A. 典型 AI 数据中心功耗根据行业数据，一个大型 AI 数据中心的电力需求可达：小型设施：10-50 MW中型设施：50-100 MW大型设施：100 MW+对比参考：一个典型美国家庭平均用电：约 1.2 kW100 MW 数据中心 ≈ 83,000 个家庭的用电量B. GPU 集群功耗以 NVIDIA H100 SXM 为例：单卡 TDP：700 W单服务器（8 卡）：约 5.6 kW（不含冷却）冷却系统额外功耗：约为计算设备功耗的 40-60%2. 电网升级成本构成A. 电网扩容投资项目成本范围说明变电站升级1000-5000 万美元根据电压等级和容量输电线路100-500 万美元/公里根据电压等级配电网络改造500-2000 万美元取决于覆盖范围B. 成本分摊机制传统模式下，这些投资通过电力公司的费率回收机制（Rate Case）分摊给所有用户，周期通常为 10-30 年。3. 水资源消耗A. 数据中心用水场景冷却系统补水（蒸发冷却塔）湿式冷却器湿球温度调节B. 用水量估算一个 1…

Manus Sandbox 云计算机技术分析
type: item
date: 2026-01-15T04:06:04+00:00
description: Manus Sandbox 云计算机技术分析摘要Manus Sandbox 是 Manus 平台为每个任务分配的完全独立的云虚拟机环境。本文基于第一性原理分析 Manus Sandbox 的系统架构、生命周期管理、安全模型以及隐私保护机制。1. 系统概述1.1 核心问题在传统的 AI 交互模式中，AI 模型主要进行思考和对话，缺乏实际的执行能力。Manus 的设计理念源于拉丁文"Mens et Manus"（Mind and Hand），旨在让 AI 不仅能够思考，更能够通过行动来帮助用户完成任务。1.2 解决方案Manus Sandbox 为每个任务提供一个完整的云计算机环境，具备以下核心能力：完整计算能力：网络访问、文件系统、浏览器、各类软件工具持久化存储：任务执行过程中的所有文件和产物24/7 运行：不占用用户本地资源并行执行：多个 Sandbox 可同时运行，互不影响1.3 系统架构图 1：Manus Sandbox 系统架构系统采用分层架构设计：用户层：接收用户请求和任务指令Manus 平台层：AI Agent 解析任务，任务调度器分配资源虚拟化层：多个独立的 Sandbox 实例并行运行Sandbox 内部组件：文件系统、网络、浏览器、工具集安全层：Zero Trust 隔离和资源回收机制2. Sandbox 内部组成2.1 文件系统Sandbox 中的文件系统包含以下内容：Manus 产物：AI 生成的代码、文档、网站等输出用户上传的附件：任务相关的输入文件任务配置文件：用户上传的密钥（API Keys、SSH Keys 等）Manus 分配的服务密钥运行时文件：代码执行过程中的中间产物2.2 工具能力Sandbox 提供完整的计算环境：网络访问：HTTP/HTTPS 请求、API 调用浏览器工具：自动化网页操作、数据抓取开发工具：代码编辑器、编译器、解释器版本控制：Git 等代码管理工具部署能力：前后端服务部署到公网3. 生命周期管理3.1 生命周期状态图 2：Sandbox 生命周期状态转换Sandbox 遵循可预测的生命周期管理策略：状态触发条件行为数据保持运行中用户活跃操作Sandbox 正常运行-休眠无操作一段时间自动进入休眠状态文件数据保持不变唤醒用户返回任务自动唤醒 Sandbox恢复到休眠前状态回收免费用户 7 天 / Pro 用户 21 天销毁 Sandbox 实例部分文件被恢复重建访问已回收的 Sandbox创建新的 Sandbox 实例恢复重要文件3.2 文件恢复策略当 Sandbox 被回收后重新创建时，Manus 采用选择性恢复策略：自动恢复的文件：Manus 产物（生成的代码、文档等）用户上传的附件Slides/WebDev 项目文件不恢复的文件：运行过程中的中间代码临时文件和缓存3.3 设计权衡休眠/回收机制在以下方面取得平衡：资源效率：回收闲置 Sandbox 释放计算资源用户体验：保持重要文件的持久化成本控制：免费用户和 Pro 用户享有不同的保留期限注意：对于需要长时间运行的后台服务，建议使用 Manus 的网页开发能力创建前后台服务并部署到公网。4. 安全模型4.1 Zero Trust 原则Manus Sandbox 采用 Zero Trust 安全架构，核心设计理念包括：完全隔离：每个 Sandbox 是独立的云虚拟机不受限操作：用户和 AI 对 Sandbox 拥有完全控制权可获取 root 权限可修改系统文件可格式化整个磁盘零影响：Sandbox 的任何操作不影响：Manus 服务的安全和稳定性用户会话和账号数据其他 Sandbox 实例4.2 安全边界┌─────────────────────────────────────────┐ │ Manus 平台（安全区域） │ │ • 用户账号数据 │ │ • 会话管理 │ │ • 服务控制 │ ├─────────────────────────────────────────┤ │ 安全隔离边界 │ ├─────────────────────────────────────────┤ │ Sandbox（用户控制区域） │ │ • 文件系统 │ │ • 网络访问 │ │ • 系统配置 │ └─────────────────────────────────────────┘4.3 容错机制自动替换：当 Sandbox 出现不可恢复错误时，自动创建新实例服务连续性：确保用户任务能够继续执行数据恢复：重要文件自动恢复到新 Sandbox5. 隐私保护5.1 数据访问控制操作类型对话内容Sandbox 内容Connectors分享（Share）可见不可见不适用协作（Collaborate）可见可访问自动禁用图 3：数据…

下载了一些超融合的招标文件包含技术参数
type: item
date: 2025-10-10T03:59:05+00:00
description: 重庆大学医院信息系统超融合服务.pdf山东大学 AI 超融合私有云模块采购.pdf温岭市公安局超融合平台采购合同.pdf西安市高陵区人民法院超融合系统项目.pdf

UCloud发送短信失败
type: item
date: 2024-08-27T09:20:00+00:00
description: 之前同事使用UCloud的短信服务的SDK实现了业务程序调用发送短信的功能，可是最近老是发不出来了。经过检查，服务挂掉了，启动后并且做了uptime kuma监控。不过，运行一段时间后还是挂掉。尝试直接发送短信发现无法收到短信。后台直接显示发送失败。查看失败原因，说是签名问题。提了工单文明情况，工程师解释由于签名是英文的不合适。申请了中文签名后，异常报错依旧。这次报错是“UT:0010”。工程师说是“核实是关键词导致”。稍后，再次发送就可以了。