上回书讲完了部署,部署完成之后,就开始了无休止的调优,对于Ceph运维人员来说最头痛的莫过于两件事:一、Ceph调优;二、Ceph运维。 调优是件非常头疼的事情,下面来看看运维小哥是如何调优的,运维小哥根据网上资料进行了一个调优方法论(调优总结)。 · 网络规划 万兆网络现在基本上是跑Ceph必备的,网络规划上,也尽量考虑分离cilent和cluster网络。 基本做云平台的,VT和HT打开都是必须的,超线程技术(HT)就是利用特殊的硬件指令,把两个逻辑内核模拟成两个物理芯片,让单个处理器都能使用线程级并行计算,进而兼容多线程操作系统和软件,减少了CPU的闲置时间 Ceph目前并未对NUMA架构的内存做过多优化,在日常使用过程中,我们通常使用2~4颗CPU,这种情况下,选择SMP架构的内存在效率上还是要高一些。
但在现在云数据中心的兴起带来的是海量数据被集中起来。相较于传统备份行业常见的小容量(小于500GB)RTO、RPO敏感型场景,在云数据中心带来的挑战下完全无法作到有效保护。 关卡五:PB级数据中心灾备设计关卡 上 画难度:四颗星 传统的备份方式通常面向应用来做保护,依靠代理来调用应用端的接口。数据一致性能得到完全的保证。 但传统备份由于要建立索引表,面对海量小文件时或者是云计算中心的PB级数据量时无论是备份速度还是存储效率都及其有限。 从安全性上看还有一定隐患。 3、基于存储网关的数据保护。 且受限于商业策略和技术路线,从成本上(基本上都是几十万级)或者从设备的广泛兼容上看(虽说各家虚拟化网关厂家都说可以做到节点平滑扩展,但最大节点数一直都在16节点以内;且都需要保持同型同代产品)都有很大限制
关于Hyper,大家比较好奇,本文将从三个方面重点分享Hyper的原理和容器云运维:从Docker到Hyper Container,Hyper Container用于公有云,容器云上运维的变化。 容器云上运维的变化 最后想分享一下我对于容器时代运维的一些思考。在容器时代,很多运维理念跟以前不太一样了。 资源视角。以前,资源就是机器,不管是物理机还是虚机。 传统的运维都会有一套配置管理的工具(例如Puppet)来保证集群中每台机器的配置一致,但是在容器时代,一个应用所需要的依赖、配置全部打包进镜像里了,Puppet就不再需要了。 传统的运维方式,就是就是把应用的二进制文件编译好了扔到服务器上,替换旧的,重启服务,发现有问题赶紧把旧文件换回来,回滚服务,这是典型的变更方式。 一开始运维可能很不适应,但是我相信未来的趋势是容器,我们要往这个方向去努力。
许多Ceph新手在测试环节以及预生产的时候会对Ceph集群的部署以及调优产生困扰,A公司运维小哥也遇到了部署和调优问题。下面来看看A公司运维小哥是如何解决这个问题的。 关卡二:部署调优关(部署) 难度:三颗星 上篇文章开头我也说到了,部署Ceph是新手的噩梦,对于传统运维来说部署一套Ceph是很难的事情,A公司运维小哥在官网以及Ceph中国社区的相关资料和帮助下才渐渐熟悉了什么是 而此时就是考验一个运维人员的处理故障的基本素质,好在这个运维小哥有过一两年的经验,经过基本排查,最终确定了是时间问题。由于三个节点时间不一致而导致的这个问题,这里称之为“OSD打摆子”。 1.某云平台由于时间问题,导致云主机创建不了、宕机等问题。 2.某分布式文件存储由于时间问题,导致数据分布不均衡、脑裂等问题。 所以云平台也好存储也好,都会因为时间而产生不必要的故障问题,建议运维人员要注重时间问题。 ? 图8:Ceph集群 好了言归正传,上图是运维小哥新搭建好的集群。三节点、六个OSD的Ceph小集群。
运维从横向、纵向分可以分为多个维度和层次,本文试图抛开这纷繁复杂的概念,讲述一个传统的企业级运维人员转型到云运维人员,尤其是软件定义存储的运维之间经历的沟沟坎坎。 传统的运维人员,以往接触的更多是硬件,如服务器、设备和风火水电;但是在云数据中心时代,运维人员已经从面向物理设备,转变为面向虚拟化、云的管理方式。 因此,云数据中心的运维对于传统的运维人员提出了新的能力要求——不仅要熟悉传统硬件设备,同时要掌握虚拟化、云系统的部署、监控和管理等运维能力。 本文选取云数据中心的其中一点,即软件定义存储(SDS)的运维为例,试述整个演进历程。 欲知后事,且听下文《从传统运维到云运维演进历程之软件定义存储(二)》,主要讲述了A公司运维小哥在硬件选型完毕之后开始部署Ceph遇到的一些问题以及解决办法。
p=465 利用Cosbench来测试Ceph Cosbench是Intel的开源云存储性能测试软件,Cosbench目前已经广泛使用与云存储测试,并作为云存储的基准测试工具使用,Cosbench可在windows Cosbench是一个分布式的基准测试工具,测试云对象存储系统,目前为止它支持一些云对象存储系统的测试,Cosbench也允许用户创建额外的存储系统适配器。 在Cosbench 上换算是按照1000算的。例如:若你写4096KB就是4096X1000=4096000,这个就算小文件。
关卡五:Ceph灾备神兵利器-故障域 重要度:五颗星 转眼六篇文章过去了,还记得大明湖畔(本系列一)的运维小哥吗? 勿忘初心,咱们还是回到最初的运维小哥,运维小哥经历了硬件选型、部署、调优、测试的一系列转型的关卡,终于就要到最后的上线了。 运维小哥最初的梦想搭建一个Ceph存储集群,对接云服务,底层存储实现高可用的数据访问架构。 OSD上的权重代表了该OSD上存储数据的比重。如果为0,其上将不会存储任何数据。而如果一个OSD的权重为1,而另一个为2的话,第一个OSD上存储的数据量将只会有第二个OSD上数据量的一半。 它还可以被用来减轻一个OSD上的负载。 具体的Crush Map操作查看官网:http://docs.ceph.com/docs/master/rados/operations/crush-map/?
回到最初的Ceph运维工程师的问题,本系列讲述的是传统运维向新一代云运维转型之软件定义存储部分的转型,运维是企业业务系统从规划、设计、实施、交付到运维的最后一个步骤,也是重要的步骤。 运维小哥最初的梦想搭建一个Ceph存储集群,对接云服务,底层存储实现高可用的数据访问架构。 传统的运维人员,以往接触的更多是硬件,如服务器、设备和风火水电;但是在云数据中心时代,运维人员已经从面向物理设备,转变为面向虚拟化、云的管理方式。 因此,云数据中心的运维对于传统的运维人员提出了新的能力要求——不仅要熟悉传统硬件设备,同时要掌握虚拟化、云系统的部署、监控和管理等运维能力。 通过九篇文章简单介绍了下传统运维向云运维或者说是传统运维向SDS运维的转型之路。
上回书讲到了运维小哥的调优方法论(上),对于Ceph运维人员来说最头痛的莫过于两件事:一、Ceph调优;二、Ceph运维。调优是件非常头疼的事情,下面来看看运维小哥是如何调优的。 中断记录情况 3.硬件加速 在大多数情况下,CPU需要负责服务器中几乎所有的数据处理任务,事实上CPU并不如我们想象中的那样强大,在大量的数据处理中往往显得力不从心,于是便有了硬件加速技术。 TOE网卡可以将这些计算工作交给网卡上的协处理器完成。 (2)中断处理 上面讲到,在通用网络IO的处理方式上,普通网卡每个数据包都要触发一次中断,TOE网卡则让每个应用程序完成一次完整的数据处理进程后才出发一次中断,显著减轻服务对中断的响应负担。 filestore queue相关的参数对于性能影响很小,参数调整不会对性能优化有本质上提升 ?
日志维护着这个p_w_picpath上的所有事务的操作记录列表。它可以被视为存在于集群中的另一个rbd p_w_picpath(一系列RADOS对象)。 RBD Mirror功能的启用和禁用可以作用在整个Pool或者一个p_w_picpath上。 RGW逻辑概念 Region:一般用来代表逻辑上的地理区域(比如省会、国家等较大规模的地理范围),一个Region可以包含一个或多个Zone。 要实现RGW异地同步,首先需要将原本孤立零散的RGW服务,按照一定逻辑组成Region和Zone,从而打破物理地域的限制,在逻辑上形成统一的命名空间。 转眼间第七篇文章也结束了,剩下最后的运维关卡了,预知后事如何,请期待最后的《 运维&演练》。
一、云原生时代数据库运维挑战图片1.1 数据库运维体系演进从数据库运维体系的演进历程来看,1、2000年左右,PC互联网时代兴起,商业数据库是市场主流,而开源数据库方兴未艾。 在数据库运维领域,则自然衍生出了云计算的一个分支概念,DaaS,data as a service,数据库的运维方式因此由人工脚本方式转变为了数据库平台的方式。 1.2 云原生时代挑战这样的时代背景下,我以为数据库运维主要有三个方面的挑战:云原生时代应用架构普遍微服务化,一个系统拆成多个微服务,这个系统的数据库也分拆成多个。 这导致数据库实例成倍增加,数据库的运维工作量也成倍增加。因此大规模数据库实例如何有效运维?这就是第一个挑战。云原生理念应用架构层面的弹性伸缩,自然也要求数据库层面做到弹性伸缩。 效率上,节省了92%的数据库运维工作量。月均数千的总工单量,其中92%都是无需运维参与,由平台用户自助执行。
整理了一下自己的思路,把近期要做的事情也分一下类别。
「腾讯云大学」在疫情期间为开发者特推出了免费的「腾讯云认证辅导直播课」!让您足不出户,即可享受优质的学习资源,就能完成开发技能升级。 抗击疫情,居家学习,腾讯云大学与你相伴而学。欢迎大家预约直播! 本课程将介绍腾讯云产品全景和分类、产品基本功能和概念,并通过云数据库、掌握腾讯云控制台的登录方法,并以云服务器为例展示如何利用安全访问服务访问腾讯云上产品。 「腾讯云大学」邀请 腾讯云认证讲师 李晓辉 为大家带来腾讯云运维工程师认证辅导课-云上运维概述。 李晓辉,腾讯云认证讲师,熟悉OpenStack私有云领域、Docker、Kubernetes容器架构设计、Ceph 分布式存储等开源技术。 对于开发者个人和企业,腾讯云培训与认证都能提供极大的价值。
随着企业越来越多地将应用程序开发和工作负载转移到云上,以及这些云上支出变得越来越复杂,一个与此相关的概念CloudOps(即“云运维”)出现了。 CloudOps: 一种用于云运维的多层框架 “Holistic CloudOps是一个多层次的框架,可以用于帮助企业管理云生态系统的各个方面,”咨询公司Capgemini Americas的副总裁兼卓越云中心主管 “许多客户在以竖井的方式管理着他们的云原生地图,使用了不同的工具和流程,并且从整体上查看其整个云原生地图的能力微乎其微。” 随着越来越多的企业将更多的工作和流程转移到云上,他们也将需要专注于构建CloudOps专业知识。 IT、安全、架构和应用团队都需要在通用的CloudOps实践上协作并保持一致,”CTO说。“如果这些团队在孤岛中工作,CloudOps就不能很好地工作。”
在上一期推文《混沌工程》中,我们给大家介绍的是能验证业务系统稳定性的故障演练平台,本期给大家带来的是运维平台中的一个重要功能组件——密码库。 密码库是什么 密码库是运维平台的功能组件,用于统一管理云平台使用的物理机、虚拟机操作系统用户密码。 密码库为平台云产品及客户第三方系统提供密码查询、密码修改、密码重置等接口,为其使用操作系统用户密码提供自动化支持。 3.密钥 SSH 协议支持 RSA 密钥对的验证方式,通过将公钥放置在远端服务器上,用户即可以通过密钥验证来 SSH 登录远端服务器,从而实现免密码登录。密码库支持配置服务器为密钥登录方式。 往期 · 推荐 运维专题第1期:数据中枢 运维专题第2期:警戒哨兵 运维专题第3期:诊断专家 运维专题第4期:数据掘金者
本文将从部署系统的角度,介绍知乎应用平台从无到有的演进过程,希望可以对大家有所参考和帮助。 支持金丝雀灰度验证,期间支持故障检测以及自动回滚 支持蓝绿部署,在蓝绿部署情况下,上线和回滚时间均在秒级 支持部署 Merge Request 阶段的代码,用于调试 下文将按时间顺序,对部署系统的功能演进进行介绍 基于 Consul 和 HAProxy 的服务注册与发现 每次部署物理机时,都会先将机器从 Consul 上摘除,当部署完成后,重新注册到 Consul 上。 为了避免每次部署到金丝雀后,都依赖人工去观察指标系统,我们在部署系统上,又开发了「金丝雀自动回滚」功能。 但是实际上很多情况下,我们的代码在 Merge Request 阶段就需要进行部署,以方便开发者进行自测,或者交由 QA 团队测试。
内容亮点 收获前沿行业认知,明晰云 SRE 组织发展趋势与 AI 重塑 SRE 的方向 获得实用技术实践指引,学习腾讯云顾问平台功能及应用,优化运维流程 更可借鉴多维经验,涵盖技术、组织、管理、协作、技能等方面 尽管 IT 服务管理或 IT 运维领域给人的印象可能较为传统,但我们依然努力将 B 端复杂逻辑和 C 端用户体验完美融合。 传统运维人员需要每天制作报表、分析日志,而我们的平台通过自然语言处理,让这一过程变得简单高效。 此外,根因分析功能可以从现象直接追溯到根因,这得益于我们整体的产品设计理念——按图索骥。 我们在腾讯云顾问的产品化过程中也参考了这两种模式。 传统的运维体系通常是技术主导的,由开发运维团队发起,要求所有系统上报日志,然后制定指标、配置监控告警,等待问题发生时通知。 例如,业务团队告诉我们“618”即将到来,预计用户量将增加 5 倍,运维团队就会根据这一需求进行扩容评估,并在平台上完成评估和扩容。
在云计算时代和互联网持续高速发展的今天,数据和服务规模迅速升级,传统运维面临着许多新型挑战,如何结合DevOps理念,解决云计算时代的运维难题? 为了更好地推进运维领域技术交流发展,并且让更多的企业能够完成向云计算的转变,腾讯云和织云联合举办“腾讯云运维干货” 系列沙龙。 每期沙龙将会邀请腾讯运维领域专家,分享云计算时代运维的思考和实践,并且为参加沙龙活动的人员提供一定金额的腾讯云代金券,帮助大家0门槛体验腾讯云上各类云产品,而针对企业用户,腾讯云“云+创业”计划更是能给出高达百万的云资扶持 [图片] (腾讯运维技术总监梁定安) 出品人大梁宣布了腾讯云与织云的“6+6运维技术沙龙 六个运维主题覆盖运维的质量、效率、成本、规划、DevOps与AI运维的相关话题,将独家曝光大量运维实践的案例。
EasyNTS上云网关在诞生之初便是一个主要服务于远程运维的产品,在后来的改版中,我们才添加了其视频拉转推的功能,视频拉转推功能可远程运维的功能同时启用。 在试用远程运维之前,需要对数据库做个监测,而部分用户没有数据库的检测工具,而EasyNTS则提供了可以检测本地或者远程的数据库是否可以连接的功能。
在之前我们发布了一篇《EasyNTS上云网关是如何上云的:设备上云、现场上云、推流上云、桌面上云》,主要描述的是EasyNTS上云网关是如何做到设备在云端发布、在云端配置、在云端管控的,今天我们从应用场景的角度来展开 ,描述视频上云网关具体是什么样的东西。 直播上云 EasyNTS上云网关的直播上云技术能非常广泛地应用于各种直播类的基础场景,最简单的类似于之前描述的幼儿园直播、景区直播、公共画面的开放直播等,交通部的视频上云项目,实际就是这种形式的升级版, ,分析服务在公网云端,要打通现场和公网,就需要EasyNTS上云网关的现场设备穿透功能,将现场设备流端口发布到云端,这样就能够为视频分析厂商提供视频分析设备视频源了; 运维上云 EasyNTS上云网关从多个维度解决了现场设备 (包括上云网关本身)的运维需求,可以远程桌面,可以远程指令,可以远程穿透到本地调试,实实在在做到了物理问题以外的问题全面运维。