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 ImageGen 病毒式发布期间一周内超过 1 亿新用户注册，写入流量激增 10 倍以上四、影响分析1. 行业影响A. 技术认知突破OpenAI 的实践证明，PostgreSQL 可以扩展到支持比之前认为的更大的读密集型工作负载。这挑战了业界对单主节点 PostgreSQL 架构扩展性的传统认知。B. 架构设计启示单主节点架构在大量优化下可支撑大规模读密集型工作负载分片不是唯一选择，也不应该是首选方案垂直扩展与水平扩展结合的重要性C. PostgreSQL 生态影响证明 PostgreSQL 在大规模生产环境中的可靠性为其他企业提供可参考的扩展实践推动 PostgreSQL 云服务商（如 Azure）改进服务2. 用户影响A. 现有用户享受低延迟和高可用性的服务系统稳定性显著提升，SEV-0 事故极少B. 潜在用户展示了 PostgreSQL 在大规模场景下的可行性为计划采用 PostgreSQL 的企业提供信心C. 迁移成本OpenAI 选择不进行 PostgreSQL 分片，避免了复杂的迁移工作证明在正确优化下，现有架构仍有足够的增长空间3. 技术趋势A. 数据库发展方向传统关系数据库仍在大规模场景中保持竞争力优化比架构重构更有效混合架构（关系数据库 + 分片系统）成为趋势B. 云数据库服务Azure PostgreSQL Flexible Server 证明其可扩展性云服务商与用户的深度合作价值级联复制等新特性的重要性五、关键技术挑战与解决方案1. 写扩展限制挑战单主节点架构无法横向扩展写入，写入峰值可能快速压垮主节点。解决方案将可分片的写密集型工作负载迁移到 Azure Cosmos DB优化应用逻辑减少冗余写入在适当场景引入延迟写入平滑流量峰值字段回填时实施严格速率限制2. 昂贵查询挑战某些查询（如连接 12 个表的查询）会消耗大量 CPU，导致服务降级。解决方案持续优化查询，避免 OLTP 反模式将复杂连接逻辑拆分并移至应用层审查 ORM 生成的 SQL配置超时参数（如 idle_in_transaction_session_timeout）3. 单点故障挑战主节点故障会影响整个服务。解决方案将关键读请求卸载到副本，确保主节点故障时仍可服务主节点运行在 HA 模式，配备热备副本每个地域部署多个副本，确保单副本故障不影响区域服务4. 吵闹邻居问题挑战某些请求消耗不成比例的资源，影响其他工作负载。解决方案工作负载隔离到专用实例按优先级分层路由（高优先级和低优先级）不同产品和服务使用独立实例5. 连接管理挑战Azure PostgreSQL 实例最大连接限制为 5000，容易出现连接耗尽。解决方案部署 PgBouncer 作为连接池代理使用事务池模式高效复用连接将代理、客户端和副本部署在同一区域以降低网络开销仔细配置空闲超时等参数6. 缓存未命中风暴挑战缓存命中率突然下降时，大量请求直接击中数据库。解决方案实施缓存锁定（和租约）机制同一缓存键未命中时，仅一个请求从数据库获取数据其他请求等待缓存更新，避免全部访问数据库7. WAL 复制压力挑战随着副本数量增加，主节点需要向更多实例流式传输 WAL，增加网络带宽和 CPU 压力。解决方案与 Azure PostgreSQL 团队合作开发级联复制功能中间副本向下游副本中继 WAL可扩展到超过 100 个副本而不压垮主节点8. 流量峰值挑战特定端点的流量峰值、昂贵查询激增或重试风暴可能耗尽关键资源。解决方案在应用、连接池、代理和查询多层实施速率限制避免过短的重试间隔在 ORM 层支持速率限制必要时完全阻止特定查询摘要（有针对性的负载丢弃）9. 模式变更风险挑战即使小的模式变更（如更改列类型）也可能触发全表重写。解决方案仅允许轻量级模式变更对模式变更执行严格的 5 秒超时允许并发创建和删除索引新表必须使用分片系统（如 Azure Cosmos DB）六、经验总结1. 成功经验A. 充分的优化空间PostgreSQL 在正确优化下可支撑远超预期的规模。B. 架构选择的重要性分片不是银弹，单主节点架构在大量优化下仍有足够的增长空间。C. 云服务商合作的价值与 Azure PostgreSQL 团队的深度合作推动了关键功能的开发。2. 需要关注的问题A. MVCC 的写效率PostgreSQL 的 MVCC 实现在写密集型工作负载下效率较低。B. 复制架构的扩展性传统 WAL 复制架构在副本数量增加时面临扩展瓶颈。C. 运维复杂度随着优化措施的增加，系统复杂度也相应提升。3. 未来计划A. 持续迁移写密集型工作负载继续将剩余的写密集型工作负载迁移到分片系统。B. 级联复制与 Azure 合作实现级联复制，以支持更多副本。C. 探索其他扩展方案包括分片 PostgreSQL 或其他分布式系统。七、相关链接1. 官方公告OpenAI 官方博客原文2. 技术文档Azure PostgreSQL Flexible ServerThe Part of PostgreSQL We Hate the Most（作者与 Andy Pavlo 教授合著的 MVCC 深度分析）3. 相关技术Cascading Replication参考资料Scaling PostgreSQL to power 800 million ChatGPT users - OpenAI Blog
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切片元数据/slides/{slide_id}/thumbnailGET缩略图/slides/{slide_id}/dziGETDZI 描述符B. 使用示例基本使用：# 从 S3 启动服务 wsi-streamer s3://my-slides-bucket --s3-region eu-west-3 # 自定义端口 wsi-streamer s3://my-slides --port 8080 # 使用 MinIO 等 S3 兼容存储 wsi-streamer s3://slides --s3-endpoint http://localhost:9000API 调用：# 列出切片 curl http://localhost:3000/slides # 获取切片元数据 curl http://localhost:3000/slides/sample.svs # 获取瓦片 curl http://localhost:3000/tiles/sample.svs/0/0/0.jpg -o tile.jpg # 获取缩略图 curl "http://localhost:3000/slides/sample.svs/thumbnail?max_size=256" -o thumb.jpg启用认证：# 启用 HMAC-SHA256 认证 wsi-streamer s3://my-slides --auth-enabled --auth-secret "$SECRET" # 生成签名 URL wsi-streamer sign --path /tiles/slide.svs/0/0/0.jpg --secret "$SECRET" --base-url http://localhost:3000四、部署方案1. 安装方式A. Cargo 安装cargo install wsi-streamerB. 从源码构建git clone https://github.com/PABannier/WSIStreamer.git cd WSIStreamer cargo build --releaseC. Docker 部署# 从 GitHub Container Registry 拉取 docker run -p 3000:3000 -e WSI_S3_BUCKET=my-bucket ghcr.io/pabannier/wsistreamer:latest # 使用 Docker Compose 本地开发 docker compose up --build2. 配置选项所有选项可通过 CLI 标志或环境变量设置：参数环境变量默认值描述--hostWSI_HOST0.0.0.0绑定地址--portWSI_PORT3000HTTP 端口--s3-bucketWSI_S3_BUCKET—S3 存储桶名称--s3-endpointWSI_S3_ENDPOINT—自定义 S3 端点--s3-regionWSI_S3_REGIONus-east-1AWS 区域--auth-enabledWSI_AUTH_ENABLEDfalse启用认证--auth-secretWSI_AUTH_SECRET—HMAC 密钥--cache-slidesWSI_CACHE_SLIDES100最大切片缓存数--cache-tilesWSI_CACHE_TILES100MB瓦片缓存大小--jpeg-qualityWSI_JPEG_QUALITY80JPEG 质量（1-100）--cors-originsWSI_CORS_ORIGINSany允许的 CORS 源3. 验证工具# 检查 S3 连接 wsi-streamer check s3://my-slides # 列出可用切片 wsi-streamer check s3://my-slides --list-slides # 测试特定切片 wsi-streamer check s3://my-slides --test-slide sample.svs五、技术优势1. 性能优势按需加载：仅传输需要的字节数据多级缓存：大幅减少网络请求和计算开销原生性能：Rust 实现保证内存安全和执行效率2. 架构优势无状态设计：易于水平扩展云原生：直接对接对象存储，无需本地文件系统一行命令：极简的使用体验3. 兼容性优势S3 兼容：支持 AWS S3、MinIO、Ceph 等多种存储后端格式支持：Aperio SVS 和 Pyramidal TIFFWeb 标准：输出标准 JPEG 瓦片，兼容任何浏览器六、应用场景1. 医学影像数字病理学：全切片病理图像查看远程会诊：云端的图像共享和协作教学演示：医学教育和培训2. 科研领域高分辨率图像分析：不需要下载整个文件大规模图像数据集：云端存储和按需访问3. 归档系统长期存储：将大型图像归档到 S3 等对象存储按需访问：需要时才提取特定区域七、项目生态1. 版本信息最新版本：v0.4.0（2025 年 1 月 14 日发布）开源协议：MIT项目热度：127 stars，1 fork2. 开发活跃度54 次提交4 个版本发布持续维护中3. 相关链接GitHub：https://github.com/PABannier/WSIStreamercrates.io：https://crates.io/crates/wsi-streamerDocker 镜像：https://github.com/PABannier/WSIStreamer/pkgs/container/wsistreamer八、技术总结WSIStreamer 是一个设计精良的云原生图像流媒体服务器，通过巧妙的架构设计解决了大型医学图像的按需访问问题。其核心优势在于：Range 请求优化：仅传输需要的数据，极大节省带宽多级缓存：三层缓存机制确保高性能极简部署：一行命令即可启动服务云原生：直接对接 S3 存储，无本地依赖该项目展示了 Rust 在系统级编程中的优势，通过内存安全和高性能特性，构建了一个可靠、高效的图像服务解决方案。对于需要处理大型图像的医学影像、科研等领域，WSIStreamer 提供了一个极具价值的开源选择。参考资料WSIStreamer GitHub RepositoryWSIStreamer on crates.ioProject Discussion on Hacker News
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. 现有用户欧洲公共部门实体和高监管行业（金融、医疗、政府）现在可以在满足主权要求的同时利用云创新。B. 潜在用户之前因主权顾虑而拒绝使用云服务的组织现在可以迁移到 AWS。C. 迁移成本需要创建新的 AWS European Sovereign Cloud 分区根账户，但架构和 API 的熟悉性降低了迁移门槛。3. 技术趋势A. 技术方向主权云与数据主权、数字主权概念紧密相关，反映了全球数字化治理的区域化趋势。B. 生态影响合作伙伴解决方案的可用性将加速欧洲主权云生态系统的成熟。五、各方反应1. 官方回应AWS 任命的总经理 Stéphane Israël 表示，这一发布体现了 AWS 满足欧洲特定需求的承诺。2. 业内评价A. 专家观点这是云计算行业的重要里程碑，平衡了主权要求与技术创新需求。B. 社区反馈从发布时间和投资规模来看，AWS 对欧洲市场的重视程度显著。3. 用户反馈A. 正面评价公共部门和高监管行业将受益于这一解决方案。B. 关注点客户将关注实际运营中欧盟公民运营比例的透明度。六、相关链接1. 官方公告AWS European Sovereign Cloud 官方页面：https://aws.eu/2. 相关报道AWS 欧洲主权云服务列表公告合作伙伴解决方案发布公告3. 技术文档AWS European Sovereign Cloud 白皮书AWS European Sovereign Cloud 主权参考框架参考资料Opening the AWS European Sovereign Cloud | AWS News Blog
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 周内完成 RAID 配置1 个月内完成存储规划调整持续优化监控体系3. 预防措施A. 监控体系建议监控指标存储使用率（阈值：80% 告警，90% 严重告警）Thin Pool 使用率虚拟机磁盘实际使用量系统日志中的磁盘错误B. 定期维护定期清理不必要的快照定期清理日志文件定期清理临时文件C. 备份策略备份铁律每日增量备份每周全量备份异地备份（防止机房灾难）定期测试备份恢复五、经验总结1. 做得好的地方快速定位故障根因熟练掌握 LVM 扩容操作理解热插拔技术，无需停机维护虚拟机无需迁移，直接启动恢复2. 需要改进的地方存储规划严重不足，超配比例过高缺少基本的监控告警机制没有配置 RAID 数据保护备份策略不完善3. 流程优化建议建立存储规划规范，强制要求冗余系数接入监控系统，设置多级告警定期进行容量评估和扩容规划建立备份和恢复演练机制六、关键技术要点1. 热插拔技术SATA 硬盘支持热插拔，并非只有 SAS 硬盘可以热插拔需要确认服务器背板支持热插拔功能企业级硬盘通常支持热插拔，消费级硬盘可能不支持2. LVM-Thin 原理Thin Provisioning 允许超额分配，但物理空间耗尽会导致严重后果扩展 Thin Pool 后，原磁盘文件无需迁移，可直接使用需要刷新 Thin Pool 元数据才能让 PVE 识别新空间3. 虚拟机暂停机制虚拟机暂停是因为存储空间耗尽导致无法分配新块并非磁盘文件损坏，恢复空间后可直接启动无需修改虚拟机配置，硬件仍指向原存储路径七、故障处理最佳实践1. 故障响应流程graph LR A[故障发现] --> B[存储诊断] B --> C[空间耗尽] C --> D[硬件扩容] D --> E[LVM扩容] E --> F[虚拟机恢复] F --> G[业务验证]2. 存储规划检查清单计算理论需求应用冗余系数 1.5配置 RAID 保护设置监控告警建立备份策略3. 应急处理要点保持冷静，按流程排查确认数据安全后再操作记录所有操作步骤验证业务完全恢复参考资料9台服务器集体"罢工"——服务器是虚拟的，惊魂却是实实在在的
基于 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: docker.cnb.cool/srebro/docker-images-chrom/pryorda-vmware_exporter:latest_amd64 container_name: vmware_exporter_nj restart: always ports: - "9272:9272" env_file: - ./config-nj.env healthcheck: test: ["CMD", "nc", "-z", "localhost", "9272"] interval: 30s timeout: 10s retries: 3 start_period: 60s vmware_exporter_bj: image: docker.cnb.cool/srebro/docker-images-chrom/pryorda-vmware_exporter:latest_amd64 container_name: vmware_exporter_bj restart: always ports: - "9273:9272" env_file: - ./config-bj.env healthcheck: test: ["CMD", "nc", "-z", "localhost", "9272"] interval: 30s timeout: 10s retries: 3 start_period: 60sC. 健康检查机制检测本地 9272 端口检测间隔 30 秒单次检测超时 10 秒连续失败 3 次后标记为不健康启动后 60 秒开始检测D. 验证部署启动后访问 metrics 接口：curl http://<host>:9272/metrics curl http://<host>:9273/metrics检查容器日志，确认认证与连接正常：docker logs vmware_exporter_nj docker logs vmware_exporter_bj2. Prometheus 接入配置A. 抓取配置在 Prometheus 的 scrape_configs 中添加 vmware_exporter 任务：scrape_configs: - job_name: 'vmware_vcenter' metrics_path: '/metrics' static_configs: - targets: ['172.22.33.218:9272'] labels: project_name: "Datacenter-srebro" nodename: "EXSI-172.1.5.17" relabel_configs: - source_labels: [__address__] target_label: __param_target - source_labels: [__param_target] target_label: instance - source_labels: [__address__] regex: '(.*):9272$' target_label: datacenter replacement: 'Datacenter-srebro' metric_relabel_configs: - action: replace target_label: host_name replacement: 'EXSI-172.1.5.17' - action: replace target_label: dc_name replacement: 'EXSI-172.1.5.17'B. 标签管理通过 relabel_configs 和 metric_relabel_configs 实现标签自定义：project_name：项目名称nodename：节点名称datacenter：数据中心标识host_name：主机名称dc_name：数据中心名称C. 验证接入Prometheus Targets 页面确认 vmware_exporter 处于 UP 状态使用 PromQL 查询 vmware_* 前缀指标确认指标标签正确应用3. Grafana 可视化配置A. 数据源配置添加 Prometheus 数据源指向 Prometheus HTTP 地址配置访问权限和认证信息B. 仪表盘导入可导入社区仪表盘：仪表盘 ID：15446（VMware 总览）仪表盘 ID：11243（VMware 详细）根据实际情况可能需要微调查询语句和变量。C. 推荐监控面板ESXi 主机状态概览CPU 使用率趋势内存使用率趋势存储容量与使用率虚拟机状态分布网络流量统计五、告警规则设计1. 告警规则配置以下规则可导入 Watchalert，根据实际环境调整阈值：rules: - alert: ESXi宿主机离线 expr: vmware_host_power_state == 0 for: 30s labels: severity: 1 annotations: summary: "ESXi宿主机离线" description: "区域：{{ $labels.project_name }} 宿主机：{{ $labels.host_name }} ESXi宿主机离线，当前值 {{ $value }}，请登录vCenter查看" - alert: ESXi存储使用率超阈值 expr: ((1-(vmware_datastore_freespace_size/vmware_datastore_capacity_size))*100) > 85 for: 1m labels: severity: 1 annotations: summary: "ESXi存储使用率超阈值" description: "区域：{{ $labels.project_name }} 存储名：{{ $labels.ds_name }} 使用率超过85%，当前值 {{ $value }}%" - alert: ESXi虚拟机CPU使用率过高 expr: vmware_vm_cpu_usage_average/100 >= 85 for: 30s labels: severity: 3 annotations: summary: "ESXi虚拟机CPU使用率过高" description: "区域：{{ $labels.project_name }} 主机：{{ $labels.nodename }} CPU使用率超过85%，当前值 {{ $value }}%" - alert: ESXi虚拟机内存使用率过高 expr: vmware_vm_mem_usage_average/100 >= 90 for: 30s labels: severity: 3 annotations: summary: "ESXi虚拟机内存使用率过高" description: "区域：{{ $labels.project_name }} 主机：{{ $labels.nodename }} 内存使用率超过90%，当前值 {{ $value }}%" - alert: ESXi实例CPU负载过高 expr: (vmware_host_cpu_usage/vmware_host_cpu_max)*100 > 70 for: 1m labels: severity: 1 annotations: summary: "ESXi实例CPU负载过高" description: "区域：{{ $labels.project_name }} 宿主机：{{ $labels.host_name }} CPU负载超过70%，当前值 {{ $value }}%" - alert: ESXi实例内存使用率过高 expr: (vmware_host_memory_usage/vmware_host_memory_max)*100 > 85 for: 30s labels: severity: 1 annotations: summary: "ESXi实例内存使用率过高" description: "区域：{{ $labels.project_name }} 宿主机：{{ $labels.nodename }} 内存使用率超过85%，当前值 {{ $value }}%" - alert: ESXi虚拟机快照数量过多 expr: vmware_vm_snapshots > 5 for: 30s labels: severity: 3 annotations: summary: "ESXi虚拟机快照数量过多" description: "区域：{{ $labels.project_name }} 主机：{{ $labels.nodename }} 快照数量超过5个，当前值 {{ $value }}"2. 告警级别说明级别说明典型场景severity: 1严重告警宿主机离线、存储超阈值、资源过载severity: 3一般告警虚拟机资源使用过高、快照过多3. Watchalert 配置要点支持告警聚合：相同告警合并发送支持告警抑制：依赖关系避免告警风暴支持 webhook 通知：对接企业微信、钉钉等六、监控数据流1. 指标采集流程sequenceDiagram participant ESXi as ESXi/vCenter participant Exporter as vmware_exporter participant Prometheus as Prometheus participant Grafana as Grafana participant Watchalert as Watchalert participant User as 运维人员 ESXi->>Exporter: 暴露指标接口 Exporter->>Exporter: 转换为Prometheus格式 Prometheus->>Exporter: 定期抓取/metrics Prometheus->>Prometheus: 存储时序数据 Grafana->>Prometheus: 查询指标数据 Grafana->>User: 展示仪表盘 Prometheus->>Watchalert: 推送告警评估 Watchalert->>User: 发送告警通知2. 关键指标说明指标名称说明单位vmware_host_power_state主机电源状态0/1vmware_datastore_freespace_size数据存储空闲空间字节vmware_datastore_capacity_size数据存储总容量字节vmware_vm_cpu_usage_average虚拟机 CPU 使用率百分比vmware_vm_mem_usage_average虚拟机内存使用率百分比vmware_host_cpu_usage主机 CPU 使用量兆赫兹vmware_host_cpu_max主机 CPU 总量兆赫兹vmware_host_memory_usage主机内存使用量字节vmware_host_memory_max主机内存总量字节vmware_vm_snapshots虚拟机快照数量个七、扩展功能1. 鉴权功能增强原版 vmware_exporter 未提供鉴权功能，存在安全风险。增强版已添加鉴权支持：代码仓库：https://cnb.cool/sro/vmware_exporter镜像地址：docker.cnb.cool/sro/vmware_exporter:0.18.4使用文档：https://cnb.cool/sro/vmware_exporter/-/blob/master/README.md2. 镜像加速使用国内镜像加速地址：docker.cnb.cool/srebro/docker-images-chrom/pryorda-vmware_exporter:latest_amd64八、最佳实践1. 安全建议使用只读账户进行监控采集密码通过环境变量或外部秘密管理启用 exporter 鉴权功能限制网络访问范围2. 性能优化合理设置 VSPHERE_SPECS_SIZE 参数使用 healthcheck 确保服务可用性调整 Prometheus 抓取间隔配置合理的指标保留策略3. 运维建议定期检查容器健康状态监控 exporter 自身的资源消耗及时更新组件版本建立告警值班机制参考资料vmware_exporter GitHub 仓库vmware_exporter 增强版仓库（带鉴权）Prometheus 官方文档Grafana 官方文档Watchalert GitHub 仓库
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 volumeBindingMode: Immediate3. 网络架构虚机需要使用原 VMware 环境的 VLAN 网络，采用 Multus + OVN-Kubernetes 实现二层网络透传。graph LR A[VLAN 100] -->|ovn-k8s-cni| B[br-vlan100] C[VLAN 200] -->|ovn-k8s-cni| D[br-vlan200] B --> E[VM Production] D --> E F[Multus CNI] -->|网络适配| G[KubeVirt Pod] G --> EMultus 配置示例apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: vlan100-production namespace: vm-production spec: config: |- { "cniVersion": "0.3.1", "name": "vlan100-production", "type": "ovn-k8s-cni-overlay", "topology": "localnet", "vlanID": 100, "mtu": 9000, "subnets": "10.100.0.0/16" }四、虚机迁移策略1. 虚机分类根据业务影响和迁移难度，将 2000 台虚机分为五类：优先级类型数量迁移方式Priority 1已关机、无共享磁盘342批量离线迁移Priority 2无状态服务567从模板重建Priority 3标准业务845有停机时间的迁移Priority 4关键业务198计划窗口迁移Priority 5复杂配置48手动验证迁移2. 迁移工具采用 virt-v2v + 自研批量脚本的组合方案：virt-v2v：官方转换工具，负责 VMDK 到 qcow2 的格式转换自研脚本：实现批量调度、状态跟踪、错误处理virt-v2v 转换命令virt-v2v -ic "vpx://${VCENTER_USER}@${VCENTER_HOST}/${ESXI_HOST}?no_verify=1" \ "${VM_NAME}" \ -o local -os "${OUTPUT_DIR}" \ -of qcow2 \ --password-file <(echo "${VCENTER_PASSWORD}")3. Windows 虚机特殊处理Windows 虚机迁移需预先安装 VirtIO 驱动：# 安装 VirtIO 存储驱动 pnputil.exe /add-driver E:\vioscsi\w10\amd64\*.inf /install # 安装 VirtIO 网络驱动 pnputil.exe /add-driver E:\NetKVM\w10\amd64\*.inf /install # 安装 QEMU Guest Agent msiexec.exe /i E:\guest-agent\qemu-ga-x86_64.msi /qn五、性能优化1. CPU 优化对延迟敏感的工作负载启用 CPU 绑定：spec: template: spec: domain: cpu: cores: 4 dedicatedCpuPlacement: true isolateEmulatorThread: true model: host-passthrough numa: guestMappingPassthrough: {}实测数据显示，开启 CPU 绑定后数据库虚机 P99 延迟降低 40%。2. 内存优化内存密集型工作负载使用大页内存：domain: memory: guest: 32Gi hugepages: pageSize: 1Gi节点配置：# 配置 1GB 大页 echo 34 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages # 持久化配置 cat >> /etc/sysctl.conf << EOF vm.nr_hugepages = 34 EOF # 标记节点 kubectl label node node-vm-01 kubevirt.io/hugepages-1Gi=true3. 存储 IO 优化数据库工作负载的 IO 调优：domain: devices: disks: - name: datadisk disk: bus: virtio io: native cache: none dedicatedIOThread: true在此配置下，MySQL 虚机达到 85000 IOPS（4K 随机读）。六、高可用与监控1. 实时迁移配置spec: configuration: migrations: parallelMigrationsPerCluster: 10 parallelOutboundMigrationsPerNode: 4 bandwidthPerMigration: 1Gi completionTimeoutPerGiB: 800 progressTimeout: 300 allowAutoConverge: true allowPostCopy: false2. 监控指标使用 Prometheus + Grafana 监控关键指标：CPU 使用率：kubevirt_vmi_cpu_system_usage_seconds_total内存使用：kubevirt_vmi_memory_used_bytes网络 IO：kubevirt_vmi_network_receive_bytes_total磁盘 IO：kubevirt_vmi_storage_iops_read_total迁移状态：kubevirt_vmi_migration_phase_transition_time_seconds七、迁移成果经过 6 个月实施，项目取得以下成果：指标数据迁移完成率1987 台成功（99.35%）成本节省年度基础设施成本降低 62%运维效率团队规模从 12 人优化到 8 人故障恢复时间从 45 分钟降至 12 分钟八、经验总结1. 关键经验存储是核心：Longhorn 在大规模虚机场景下性能不足，Ceph 虽复杂但稳定可靠网络提前规划：VLAN 透传配置繁琐，需在项目初期设计好网络架构分批迁移：每批 50 台可控，问题影响面小Windows 需专门模板：驱动和激活问题需提前准备监控先行：迁移前建好监控体系，便于问题排查2. 常见问题问题原因解决方案Guest agent 未连接QEMU Guest Agent 未安装安装并启动 qemu-guest-agent网络不通Multus 配置错误检查 NetworkAttachmentDefinition 和 VLAN 透传磁盘性能差缓存策略不当改为 cache: none + io: native实时迁移失败带宽或存储问题调整迁移带宽，检查存储可达性九、参考资料KubeVirt 官方文档KubeVirt GitHub 仓库virt-v2v 文档Rook-Ceph 文档OVN-Kubernetes 文档
Microsoft AI 数据中心电力成本承担计划技术分析
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. 用水量估算一个 100 MW 数据中心在使用冷却塔的情况下：年用水量可达 100-500 万立方米取决于冷却效率和气候条件C. Microsoft 补水措施Arizona 示例：与市政当局合作查找和修复管道泄漏投资节水基础设施支持社区水资源保护项目五、影响分析1. 行业影响A. 竞争格局Microsoft 的这一举措可能成为行业新标准：其他云服务商（AWS、Google Cloud）可能面临类似压力可能引发行业良性竞争，争相展示社区责任B. 监管趋势特朗普政府的表态表明：联邦层面开始关注 AI 基础设施对民生的影响可能推动相关法规的制定数据中心审批可能增加社区影响评估要求2. 技术趋势A. 能效优化压力更高的电力成本承担将推动：更高效的芯片架构（如 ASIC、TPU）液冷技术的普及数据中心 PUE（Power Usage Effectiveness）优化B. 可再生能源整合为降低电力成本，数据中心将加速：onsite 可再生能源发电（太阳能、风能）购电协议（PPA）与绿色电力采购储能系统投资3. 社区关系模式A. 从对抗到合作传统模式：数据中心入驻 → 社区反对 → 法律纠纷新模式：社区投资承诺就业与技能培训基础设施共享B. 社区许可（Social License）Microsoft 的策略表明，大型科技项目需要：不仅满足法律要求更需要获得社区认可建立长期共赢关系六、挑战与不确定性1. 执行层面挑战A. 成本测量与核算如何精确区分数据中心导致的电网升级成本如何建立透明的成本分摊机制第三方审计的必要性B. 长期承诺的可信度数据中心生命周期通常为 15-20 年如何确保承诺在技术迭代和商业模式变化中持续需要法律约束还是自愿承诺2. 经济可持续性A. 对 AI 成本的影响电力成本是 AI 运营成本的重要组成部分承担额外费用可能影响 AI 服务的定价可能影响数据中心的选址决策B. 边际地区的影响在电力基础设施薄弱的地区：电网升级成本更高可能导致数据中心避开这些地区加剧数字鸿沟七、各方反应1. 官方立场MicrosoftBrad Smith（微软总裁）：最低标准是让社区确信数据中心不会推高电价数据中心可以为整个社区的经济繁荣提供动力这是美国基础设施历史的下一个阶段特朗普政府正在与大型科技公司合作将在未来几周内宣布更多措施确保美国人不用为科技公司的电力消耗买单2. 社区反馈支持观点认可企业承担社会责任期待社区投资和就业机会支持保护居民电费关注点承诺的具体执行机制第三方监督的必要性对环境的长期影响八、未来展望1. 行业标准化Microsoft 的举措可能推动：数据中心社区影响评估标准电力成本承担的行业准则社区投资的最佳实践2. 技术创新方向A. 更高效的 AI 硬件专用 AI 芯片的能效提升神经形态计算的探索光子计算等前沿技术B. 分布式计算边缘计算减少中心化压力分布式训练降低单个数据中心负载负载迁移与智能调度3. 政策建议A. 透明度要求数据中心电力消耗的公开披露电网升级成本的分摊明细定期的社区影响报告B. 激励机制对承担社区责任的企业给予税收优惠绿色数据中心认证体系社区投资的可抵扣政策参考资料Microsoft has a plan to stop AI data centers from hiking up your electricity bill
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：数据访问权限矩阵5.2 分享机制通过"Share"按钮分享任务时：被分享者只能看到对话消息和输出产物Sandbox 内容完全不可见适用于展示任务结果而不泄露工作环境5.3 协作机制通过协作按钮邀请用户参与时：协作者可向 AI 发送指令控制任务协作者可通过 AI 访问和修改 Sandbox 文件Connectors 自动禁用，防止访问连接的服务风险：可能造成预期外的数据泄露5.4 最佳实践协作前检查：邀请协作者前确认 Sandbox 中无敏感内容任务隔离：如已有敏感内容，创建新任务只复制必要内容定期清理：及时删除 Sandbox 中的敏感数据和密钥6. 可用性与定价功能免费用户Pro 用户Sandbox 使用可用可用并行任务标准限制更高限制休眠保留期7 天21 天7. 应用场景7.1 典型用例网站开发：从设计到部署的全流程开发移动应用开发：完整的 App 开发和打包数据处理：大规模数据分析和转换自动化任务：定时任务和批量操作API 集成：多服务集成和自动化测试7.2 技术优势零本地资源占用：所有计算在云端完成完整的开发环境：预装常用工具和库AI 辅助编码：AI 可直接编写和执行代码快速迭代：即时预览和调试8. 技术挑战与限制8.1 当前限制休眠机制：不适合需要长时间运行的后台服务文件恢复：临时文件和中间代码不会自动恢复协作风险：协作者对 Sandbox 的完全访问权限8.2 未来改进方向持久化服务：支持长时间运行的云服务细粒度权限：更灵活的协作权限控制增量备份：更完善的文件恢复机制9. 总结Manus Sandbox 代表了 AI 驱动工作方式的新范式——从对话走向真正的执行。通过提供一个持久、安全、功能完整的云计算环境，Manus 使 AI 能够通过编写代码和使用工具来完成复杂的实际任务。其核心技术创新在于：完整虚拟化：每个任务独立的云计算机环境Zero Trust 安全：完全隔离的安全架构智能生命周期管理：在效率和持久性之间取得平衡AI 原生设计：为 AI Agent 优化的工具链和环境参考资料Manus Sandbox 官方博客Manus 产品文档Zero Trust 架构最佳实践文档生成时间：2025-01-15分析基于：Manus 官方博客和技术文档
下载了一些超融合的招标文件包含技术参数
重庆大学医院信息系统超融合服务.pdf山东大学 AI 超融合私有云模块采购.pdf温岭市公安局超融合平台采购合同.pdf西安市高陵区人民法院超融合系统项目.pdf
之前同事使用UCloud的短信服务的SDK实现了业务程序调用发送短信的功能，可是最近老是发不出来了。经过检查，服务挂掉了，启动后并且做了uptime kuma监控。不过，运行一段时间后还是挂掉。尝试直接发送短信发现无法收到短信。后台直接显示发送失败。查看失败原因，说是签名问题。提了工单文明情况，工程师解释由于签名是英文的不合适。申请了中文签名后，异常报错依旧。这次报错是“UT:0010”。工程师说是“核实是关键词导致”。稍后，再次发送就可以了。