据IDC发布的《数据时代2025》报告显示，全球每年产生的数据将从2018年的33ZB增长到2025年的175ZB，平均每天约产生491EB数据。随着数据量的不断增长，数据存储成本成为企业IT预算的重要组成部分。例如1PB数据存储一年，全部放在高性能存储介质和全部放在低成本存储介质两者成本差距在一个量级以上。由于关键业务需高性能访问，因此不能简单的把所有数据存放在低速设备，企业需根据数据的访问频度，使用不同种类的存储介质获得最小化成本和最大化效率。因此，把数据存储在不同层级，并能够自动在层级间迁移数据的分层存储技术成为企业海量数据存储的首选。
Kubernetes 集群备份一直是我们的痛点。虽然可以通过Etcd v3备份与恢复来实现K8S集群备份，但是这种备份很难恢复单个 Namespace。
随着数据量的爆发式增长，数字化转型称为了整个IT行业的热点，数据也开始需要更深度的价值挖掘，因此需要确保数据中保留的原始信息不丢失，从而应对未来不断变化的需求。当前以oracle为代表的数据库中间件已经逐渐无法适应这样的需求情况，于是业界也开始进行不断的产生的计算引擎，以便应对数据时代的到来。在此背景下，数据湖的概念被越来越多的人提起，希望能有一套系统在保留数据的原始信息情况下，又能够快速对接多种不同的计算平台，从而在数据时代占比的先机。
AutoMQ[1] 是新一代基于共享存储架构实现的云原生 Kafka。得益于其存算分离的共享存储架构，通过和阿里云合作，深度使用阿里云可靠、先进的云服务如对象存储 OSS、块存储 ESSD、弹性伸缩 ESS 以及抢占式实例实现了相比 Apache Kafka 10 倍的成本优势并且提供了自动弹性的能力。
3、从快照中恢复数据，注意：在源集群中全量备份数据，恢复的时候，会有索引冲突的现象
在近日的一个风和日丽的下午，正在快乐的写 bug 时，突然间钉钉就被 call 爆了，原来是 k8s 测试集群的一个 namespace 突然不见了。这个 namespace 里面有 60 多个服务，瞬间全部没有了……虽然得益于我们的 CI/CD 系统，这些服务很快都重新部署并正常运行了，但是如果在生产环境，那后果就是不可想象的了。在排查这个问题发生的原因的同时，集群资源的灾备和恢复功能就提上日程了，这时 Velero 就出现了。
阿里云高级技术专家车漾老师在 QCon 上海会议上，分享了在 Fluid 项目作为云原生 AI 场景下的数据和任务编排框架，在 AIGC 模型推理工程化落地方面做了许多优化探索的工作，包括简化云原生 AI 场景的分布式缓存管理和运维，降低资源成本；以及优化推理服务读取模型数据的效率，加速模型加载过程。同时也会演示了如何通过 Fluid 将一个 LLM 模型的推理加载速度提升近 7 倍，同时提供缓存弹性的能力，避免资源浪费的实践话题。
在云上PaaS服务愈发成熟的大背景下，越来越多自建Elasticsearch的业务希望迁移到云上，享用云服务统一、高标准的服务体验的同时，降低运维成本。本方案旨在通过集群融合的方式帮助用户进行在线迁移，尽量降低迁移过程对业务的影响，同时尽可能提高迁移的自动化程度。
MySQL 的官网下载地址：https://www.mysql.com/downloads/
导读| 如何让功能缺陷修复快速上线？版本发出问题时怎样快速回退？效率提升后质量掉队？为解决这些常让运维工程师头疼的事情，本栏目特邀腾讯知名运维工程师袁旭东，讲述对象存储COS的发布演进过程，为各位开发者提供业务通用的高效高质变更方法。该业务通过提升灰度自测能力、优化流转时间和并发策略等方法实现提效，同时提出措施保障质量，并设置了一套可度量体系保障持续监控、调优，最终带动发布变更水平上新台阶。 背景 1）背景诉求 现网发布变更对运维开发工程师来说是最繁重的工作。发布变更的概念、节奏等已经是老生
一面数据原有的技术架构是在线下机房中使用 CDH 构建的大数据集群。自公司成立以来，每年都保持着高速增长，业务的增长带来了数据量的剧增。
李阳良，一面数据大数据部门负责人，九年互联网工作经验，对后台开发、大数据技术接触比较多。
与传统的数据架构要求整合、面向主题、固定分层等特点不同，数据湖为企业全员独立参与数据运营和应用创新提供了极大的灵活性，并可优先确保数据的低时延、高质量和高可用，给运营商数据架构优化提供了很好的参考思路。
用户希望将历史数据迁移到OSS上的用户目标存储桶。需要迁移的源数据可能来自某个OSS桶，也可能来自本地或第三方云存储(例如腾讯云COS)。等等，HTTP等。
在早期版本的 NTP 服务部署中，直接使用 NTPD 单源提供 NTP 服务，且 NTP 客户端侧直接使用 crontab 定时执行 ntpdate 命令同步时间，这样既简单又能满足所有机器时间一致性的需求。
随着业务的高速发展和实时计算的迭代，业务对实时计算的需求越来越多，对实时任务的稳定性要求也越来越高。对实时计算平台而言，底层调度系统及计算引擎的稳定性、高可用性就变的十分重要。本文主要围绕作业帮实时计算平台底层调度系统，从背景现状、目标与挑战、方案设计以及未来规划等几方面来展开。
接着上篇《做容灾，双活、多活、同城、异地、多云，到底应该怎么选？》，这篇聊聊公有云上应该如何建容灾，跟我们自建机房有什么区别，没看过的同学，建议先从上篇文章看一下。
刚进公司那段时间，在敏捷项目制的执行下，需求有条不紊地进行着。某个周末，业务系统反馈群内，操作人员反馈系统不可用，我们急忙寻求运维的帮助，将系统重启并恢复使用。同时排查相关log，检查异常点，但是根据log并没有跟踪出结果。于是想到是否有OOM的dump文件生成，询问运维后，被告知并没有生成。咨询之前的应用负责人，以前也有类似系统不可用情况，但只是偶现。没有办法，根据应用日志查不出结果，只有下次复现时导出dump彻查了。又过去一段时间，故障反馈群里又是一样的问题，于是赶忙麻烦运维把dump生成，然后重启了应用，同时离线对dump进行了分析。
导语：随着云存储业务蓬勃发展，节点数不断扩展。在数十万节点的庞大系统中，如何做到一周内完成全区域覆盖，并杜绝版本发布中的人为失误？文章围绕对象存储(以下简称COS)整体的发布演进，从发布效率的极致提升，平台发布标准化外包化上展开，讲解COS发布成熟度如何提升（当前level2+），希望提供业务通用的高质量变更模式与提效参考。
本篇文章我们讨论 Netflix's 所采用的服务网格，演进历史，动机，我们如何与 Kinvolk 团队 以及 Envoy 社区合作开发，一项在复杂微服务环境中简化服务网格的功能：按需集群发现(on-demand cluster discovery,ODCD)
随着AT&T、Telefónica、中国移动等运营商纷纷开始采用SDN/NFV，通信服务提供商（CSP）正在不断加大对SDN/NFV的投资。以美国最大的运营商AT&T（同时也是动作最大的公司）为例，该公司今年2月份宣布将在2017年实现其55%的网络虚拟化，2016年该公司已经将其34%的网络实现虚拟化，最终目标是到2020年完成75%网络虚拟化，并且表示到2020年将会成为一家软件公司。 Telefónica和中国移动也在SDN领域取得了可喜的进展，能够有效提高效率并降低网络成本。根据Hea
得物上一代日志平台的存储主要依赖于 ES。随着公司业务的高速发展，日志场景逐步产生了一些新需求，主要表现在：应用数量逐步增多，研发需要打印更多的日志定位业务问题，安全合规需要保留更长时间的日志。随着 Clickhouse 的应用广泛，我们了解到行业部分知名公司已经将日志平台逐步由 ES 迁移至Clickhouse，以此来获取更好的写入性能与高压缩比。因此我们与日志平台研发团队开始进行日志平台新存储的选型评估，本文会介绍我们如何通过 Clickhouse 的冷热分离存储替代 ES 的实施方案。
Verdaccio 是 Sinopia 开源框架的一个分支。它提供了自己的小数据库，以及代理其他注册中心的能力（例如：npmjs.org 网站)，配置以及部署相对简单，一步到"胃"。如果公司的私包比较少的话或者你想偷懒，可以考虑一下。
作者 | 微博研发中心基础架构部 姚四芳、胡云鹏、臣勇、胡春林 编辑 | 蔡芳芳 机房断电、数据中心着火，极端情况下全站持续不可用已经成为很多公司不得不直面的现实问题。微博的目标是在遭受极端情况下在线数据完全损毁时，1 个小时内在异地重新构建完整的微博服务，同时确保数据完整性。这在整个业界都是一个前所未有的巨大挑战。 1大数据时代数据至关重要 数据时代全球每天新产生的数据达到 2.3EB，存量数据达到 33ZB，无论是传统企业还是新晋独角兽企业，都在基于大数据进行更快、更好的决策支持，从数据中孵化新的产品与
自研业务存储平台-是 QQ 的富媒体（图片、视频、语音、文件等）数据传输、存储、处理等全链路解决方案的平台。致力于为用户提供稳定快速的群聊 、单聊图片上传和下载服务。为了面对突发热点也能快速响应，作者团队决定对其进行上云处理。本文着重以 QQ 聊天图片（简称：QQ 图片）为例讲述整个上云的过程及调优。
笔者近期调研SDN/NFV影响下的OSS，之前自己知识中没有相关的积累，又一直没有比较官方的资料或者观点，所以在整理的时候遇到了瓶颈。最近在ONF网站看到了刚发布的一篇文档，对OSS/BSS在SDN/NFV时代的挑战和发展做了比较全面的总结，其中多数观点也与笔者收集到的资料相符，在这里分享给大家。 在ETSI NFV ISG提出的NFV框架中，OSS与SDN控制器分别负责不同的工作：OSS负责静态配置或者可以缓慢进行的服务特性等的配置，而NFV编排器和SDN控制器则负责动态配置以及实时的网络状态传输。尽管如
oss-server是针对项目开发时提供的小型对象存储系统,开发者在针对文件上传时业务剥离,同时方便文件迁移，为满足单个项目，多个系统的情况下，提供统一的oss服务
2022年6月初，Spring Boot发布了2.7版本，这个版本是Spring Boot 2.x的最后一个主要版本。
作者 | Ion Stoica 译者 | Maglish 策划 | 蔡芳芳 UC Berkely 计算机科学与电气工程教授，AMPLab 共同创始人，Spark 的核心设计者 Ion Stoica 在近日召开的操作系统会议 HotOS 上，提出了“Sky Computing”这一构想，展望超越单个云平台的公用计算未来。论文思考了该如何推动目前的差异化云计算平台逐渐发展成为一项公用服务，Stoica 称其为“Sky Computing”。论文提出实现 Sky Computing 的障碍更多来自于经济层面，而
在当今数字化时代，数据量不断增长，对于存储系统提出了更高的要求。传统的存储方式已经难以满足大规模数据的存储和管理需求，因此，对象存储（Object Storage）应运而生。对象存储是一种面向海量数据的存储架构，以其高扩展性、弹性存储、高性能和简单管理等特点，成为了云计算、大数据分析和企业数据管理中的重要组成部分。
来源：马哥教育链接：https://mp.weixin.qq.com/s/UupllldADYE0sHbRs0uouQXfS文件系统是SGI开发的高级日志文件系统，XFS极具伸缩性，非常健壮。所幸的是SGI将其移植到了Linux系统中。在linux环境下。目前版本可用的最新XFS文件系统的为1.2版本，可以很好地工作在2.4核心下。XFS文件系统简介主要特性包括以下几点：数据完全性采用XFS文件系统，当意想不到的宕机发生后，首先，由于文件系统开启了日志功能，所以你磁盘上的文件不再会意外宕机而遭到破坏了。不论目前文件系统上存储的文件与数据有多少，文件系统都可以根据所记录的日志在很短的时间内迅速恢复磁盘文件内容。传输特性XFS文件系统采用优化算法，日志记录对整体文件操作影响非常小。XFS查询与分配存储空间非常快。xfs文件系统能连续提供快速的反应时间。笔者曾经对XFS、JFS、Ext3、ReiserFS文件系统进行过测试，XFS文件文件系统的性能表现相当出众。可扩展性XFS 是一个全64-bit的文件系统，它可以支持上百万T字节的存储空间。对特大文件及小尺寸文件的支持都表现出众，支持特大数量的目录。最大可支持的文件大小为263 = 9 x 1018 = 9 exabytes，最大文件系统尺寸为18 exabytes。XFS使用高的表结构(B+树)，保证了文件系统可以快速搜索与快速空间分配。XFS能够持续提供高速操作，文件系统的性能不受目录中目录及文件数量的限制。传输带宽XFS 能以接近裸设备I/O的性能存储数据。在单个文件系统的测试中，其吞吐量最高可达7GB每秒，对单个文件的读写操作，其吞吐量可达4GB每秒。XFS文件系统的使用下载与编译内核下载相应版本的内核补丁，解压补丁软件包，对系统核心打补丁下载地址：ftp://oss.sgi.com/projects/xfs/d … .4.18-all.patch.bz2对核心打补丁，下载解压后，得到一个文件：xfs-1.1-2.4.18-all.patch文件。对核心进行修补如下：# cd /usr/src/linux # patch -p1 < /path/to/xfs-1.1-2.4.18-all.patch修补工作完成后，下一步要进行的工作是编译核心，将XFS编译进Linux核心可中。首先运行以下命令，选择核心支持XFS文件系统：#make menuconfig在“文件系统“菜单中选择：<*> SGI XFS filesystem support ##说明：将XFS文件系统的支持编译进核心或 SGI XFS filesystem support ##说明：以动态加载模块的方式支持XFS文件系统另外还有两个选择：Enable XFS DMAPI ##说明：对磁盘管理的API，存储管理应用程序使用 Enable XFS Quota ##说明：支持配合Quota对用户使用磁盘空间大小管理完成以上工作后，退出并保存核心选择配置之后，然后编译内核，安装核心:#make bzImage #make module #make module_install #make install如果你对以上复杂繁琐的工作没有耐心或没有把握，那么可以直接从SGI的站点上下载已经打好补丁的核心，其版本为2.4.18。它是一个rpm软件包，你只要简单地安装即可。SGI提交的核心有两种，分别供smp及单处理器的机器使用。创建XFS文件系统完成对核心的编译后，还应下载与之配套的XFSprogs工具软件包，也即mkfs.xfs工具。不然我们无法完成对分区的格式化:即无法将一个分区格式化成XFS文件系统的格式。要下载的软件包名称：xfsprogs-2.0.3。将所下载的XFSProgs工具解压，安装，mkfs.xfs自动安装在/sbin目录下。#tar –xvf xfsprogs-2.0.3.src.tar.gz #cd xfsprogs-2.0.3src #./configure #make #make install使用mkfs.xfs格式化磁盘为xfs文件系统，方法如下：# /sbin/mkfs.xfs /dev/sda6 ＃说明：将分区格式化为xfs文件系统,以下为显示内容： meta-data=/dev/sda6 isize=256 agcount=8, agsize=128017 blks data = bsize=4096 blocks=1024135, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none
今天分享一下文件存储的一些心得，在软件开发过程中，必然会涉及到文件存储，文件存储的方案有很多，市面上也出现了很多文件系统，我们需要根据自己的需求去选择选择存储方式和规格等等，例如是采用公有云存储还是私有云存储，还是混合云存储，这都需求根据项目的特征去选择，没有哪一种方式是十全十美的，完全根据场景去选择，软件领域没有银弹嘛。
本文从通用的数据上云场景，以及友商云数据迁移场景出发，介绍基于腾讯云对象存储（COS）的上云步骤，包括迁移前的环境准备工作，云上的配置与迁移工具的实施，数据的一致性校验，云上业务的切换与验证。
在实际使用腾讯云cvm的场景中会使用到cvm实例跨可用区迁移，跨地域迁移以及跨账号迁移去部署或迁移业务，目前在腾讯云官网没有直接针对上述三种实例迁移的方案，但读者可以参考如下方案间接的实现实例“迁移”，详见以下三种情况：
大搜车已经搭建起比较完整的汽车产业互联网协同生态。在这一生态中，不仅涵盖了大搜车已经数字化的全国 90% 中大型二手车商、9000+ 家 4S 店和 70000+ 家新车二网，还包括大搜车旗下车易拍、车行168、运车管家、布雷克索等具备较强产业链服务能力的公司， 与大搜车在新零售解决方案上达成深度战略合作的长城汽车、长安汽车、英菲尼迪等主机厂商，以及与中石油昆仑好客等产业链上下游的合作伙伴。基于这样的生态布局，大搜车数字化了汽车流通链条上的每个环节，进而为整个行业赋能。
COS Migration 是一个集成了 COS 数据迁移功能的一体化工具。通过简单的配置操作，用户可以将源地址数据快速迁移至 COS 中，它具有以下特点：
12月15日，由腾讯云主办的首届“腾讯云+社区开发者大会”在北京举行。本届大会以“新趋势•新技术•新应用”为主题，汇聚了超40位技术专家，共同探索人工智能、大数据、物联网、小程序、运维开发等热门技术的最新发展成果，吸引超过1000名开发者的参与。以下是DevOps分会场的演讲内容，稍作整理，分享给大家。
当下，随着数字化技术不断深入，愈来愈多企业将核心业务搬到线上。业务系统高可用、可扩展、容灾能力决定企业系统的连续性，中间件作为构建企业核心系统的重要组成部分，其高可用容灾能力也将决定应用系统的。本文结合腾讯云中间件各PaaS产品的容灾能力及实践，以一个行业头部客户业务容灾实践举例，来展开说明基于腾讯云中间件PaaS层相关产品的实践。
迁移上云的时候，会有迁移上腾讯云对象存储（cos）的需求，目前的迁移方案有两种：1、cos提供的COS Migration工具；2、客户自己利用友商和cos的api实现文件的下载和上传。前者需要自己部署，迁移过程中出现问题，难以排查，后者需要自己研发、测试、部署运行，需要投入研发人力和机器成本。总结了一下迁移上到cos的过程中存在的一下几个需求：
业务同学反馈有个服务在部署容器后不间断收到积压告警，该服务对积压敏感，影响派单的时效性。原来部署到ECS上的服务没有积压情况，准备往容器迁移。下面是业务同学做的排除测试，另外容器当前在J/K可用区部署，而MQ集群部署在B/G/F区。
最近在使用 Terraform Cloud 来置备 OCI 的 Always Free Tier, 发现它非常好用，相比 Terraform OSS, 用起来省心多了。
Dapr 团队最近在博客上发布了 Dapr 完成模糊测试审核[1]的文章，该审计是 CNCF 通过模糊测试改善[2]开源云原生项目安全状况的计划的一部分。该审计由 Ada Logics[3] 于 2023 年 5 月和 6 月进行的，Ada Logics 团队为了改善 Daprs 安全状况，并且由于创建了大量模糊器，发现的问题数量很少，一共开发了 39个 fuzzer，发现了3个问题，三个问题的数量非常少，这证明了 Dapr 项目编写良好且维护良好的代码库。这也表明了代码库的成熟水平。 审计中的所有模糊器都是开源的，最初被添加到 CNCF 的模糊测试存储库[4]中，团队已经开始将模糊器迁移到Dapr 仓库中[5]来完善Dapr的测试。
近年来，云计算已成为主流，企业从自身利益出发，或是不愿意被单一云服务商锁定，或是业务和数据冗余，或是出于成本优化考虑，会尝试将部分或者全部业务从线下机房迁移到云或者从一个云平台迁移到另一个云平台，业务迁移涉及到数据的迁移。正好 JuiceFS 已经对接了各种对象存储的 API ，也实现了数据同步的逻辑，让我们来了解下 JuiceFS 的 sync 命令。
今年是ETSI发布首个白皮书之后的第四年，NFV已经从概念转向了测试阶段，一些NFV的功能已经得以实现，但是要实现NFV面临着ROI、技能和新挑战的痛点：软件许可。 在本周三的世界宽带论坛上，Cabl
随着 Flink 实例的迁移下云以及新增需求接入，自建 Flink 平台规模逐渐壮大，当前总计已超 4 万核运行在自建的 K8S 集群中，然而 Flink 任务数的增加，特别是大状态任务，每次 Checkpoint 时会产生脉冲式带宽占用，峰值流量超过 100Gb/s，早期使用 OSS 作为 Checkpoint 数据存储，单个 Bucket 每 1P 数据量只有免费带宽 10Gb/s，超出部分单独计费，当前规模每月需要增加 1x w+/月。
什么是网络功能虚拟化（NFV）的风险？与任何新兴技术一样，快速迁移或选择错误的组件可能会带来很多危害。我们接下来将会分析构建虚拟网络时面对的NFV风险。 我耗时数月来收集各种服务提供商的反馈，以了解N
随着得物 App 的用户流量增长，业务选择的数据库越来越多样化，异构数据源之间的数据同步需求也逐渐增多。为了控制成本并更好地支持业务发展，我们决定自建 DTS 平台。本文主要从技术选型、能力支持与演化的角度出发，分享了在 DTS 平台升级过程中获得的经验，并提供一些参考。
意大利电信公司TIM的漏洞研究部门Red Team Research (RTR) 发现了2个影响爱立信 OSS-RC 的新漏洞。TIM RTR已向爱立信报告了这些漏洞。
近期，Milvus 发布了全新升级的 Milvus 2.3 版本，内核引擎加速的同时也加入了诸如支持 GPU 这样实用且强大的特性。可以说，以 Milvus 2.3 为代表的 Milvus 2.x 版本无论在功能还是性能上都远超 Milvus 1.x 版本。因此，有很多新老用户反馈，想要将存量向量数据从其他数据源迁移到 Milvus2.x 中，为了解决这一需求，Milvus-migration 项目应运而生。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
