顺丰全栈资源下的自动化运维灵魂,Fabric中最好的Fabric

Mac电脑修改账户名称和个人目录后丢失管理员权限问题,mac账户

Mac电脑修改账户名称和个人目录后丢失管理员权限问题

午休时,其它部门的经理拿一台MacBook过来,说电脑没重要数据可以把硬盘格式化,让我给他装最新的Mac系统。

电脑入手后,回过神来有点懵逼,不就是打开App
Store点系统更新么,一定要过来打扰我的午休!!!

看到他电脑上安装着系统优化软件,突然就理解他了,解决这种心理问题我们是专业的。

于是整理了一下系统安装思路:

1、打开App Store更新系统;

2、进入“系统偏好设置”-“用户与群组”
更改管理员账户名和个人目录(如:图一);

这样一弄,重启后桌面焕然一新,给他的心理感觉绝壁好到爆。

系统更新完成后,修改账号名和个人目录时,出现了一些意想不到的问题,管理员权限居然丢了(如:图三
标示为了“普通用户”,理想的情况应该是图二这样子)。丢失管理权限后,重启电脑自然就无法进入开机设置流程了。

可以负责任的说,这样不是第一次操作了以前从未遇到过这种情况。之前每次进新公司入职iOS时第一步就是修改管理员账户名和个人目录,因为这样替换掉管理员后并不会销毁他们的工作目录,数据仍会保存在硬盘的用户目录中。

后面,百度了一种解决方案,试验后能解决问题。

开机同时按住command+s;
输入密码启动电脑后会出现终端,再就是按顺序输入每行的指令敲回车循环下去;
/sbin/mount -uaw
rm var/db/.applesetupdone
reboot

这样执行指令启动后就能进入开机设置流程,进入桌面后打开Finder的偏好设置将硬盘显示到桌面(如:图四),进入硬盘可以查看用户目录的情况(如:图五)。

示意图:

图一

图二

图三

图四

图五


0


0

[解读] Brocade(博科)为何认为FC是NVMe over Fabric中最好的Fabric?,brocadenvme

      Brocade最近发表了对NVMe over
Fabric理解和观点,认为FC Fabric相比以太网具有很多优势,并且FC聚焦数据中心数据传输和交换,具有更好的网络安全性。文章把Brocade的主要观点做了解析(文章全是干货,建议阅读前记得多喝水,易于消化),大家可以关注本公众号,在菜单底部回复关键字“ Fcfabric ”获取Brocade相关全文技术资料。

     
目前,基于SCSI的全闪存和混合阵列正成为数据中心的主流,但与此同时,一种为固态PCIe模块专门构建的非易失性存储器(NVMe)标准已经成为服务器连接Flash的一个新的高性能接口。NVMe通过低延迟和增强队列机制提供了更好的随机和连续性能,并增加了传统协议(如SAS)应用程序的并行性。

      为了支持数据中心的网络存储,通过NVMe over
Fabric实现NVMe标准在PCIe总线上的扩展,以此来挑战SCSI在SAN中的统治地位。NVMe
over
Fabric支持把NVMe映射到多个Fabrics传输选项,主要包括FC、InfiniBand、RoCE
v2和iWARP

      随着NVMe的发展和NVMe over
Fabric技术商品化,在SAN市场,将NVMe定位为SCSI的替代方案,这也为Flash模块供应商打开一扇门来应对这个新的市场。自然地,存储市场的新来者试图吹捧他们的技术有优势,然而,新技术的缺点可能没有受到太多关注。通过作者的分析,希望大家能对NVMe和NVMe
over Fabrics技术有个综合全面的认识。

1、FC不但可以作为NVMe的Fabrics且更有优势

      FC实际上是支持NVMe的一种fabrics选择。NVMe over
fabric白皮书上概述了对NVMe支持的两种类型的fabrics,一个是RDMA和一个是使用FC。尽管一些竞争者会声称光纤通道不是合法的NVMe
Fabric,但是NVM Express白皮书例证说明了这个问题。

      同样,白皮书明确列出了光纤通道作为一个NVMe over
Fabrics选择,也描述了理想的Fabrics需要具备可靠的、以Credit为基础的流量控制和交付机制。然而,基于Credit的流程控制机制是FC、InfiniBand和PCIe传输原生能力。基于Credit流控制不是以太网/
IP网络的一部分,所以,相比iWARP或RoCE的以太网Fabrics,FC实际上是NVMe更好的Fabrics选择。

2、RDMA也不是NVMe Fabric的关键

      RDMA提倡者一般声称RDMA对设计好NVMe
Fabric很重要。但在NVMe的白皮书中并没有把RDMA列为“理想”NVMe over
Fabric的重要属性,也就是说RDMA除了只是一种实现NVMe
Fabric的方法外,没有什么特别的。在博科看来,InfiniBand社区在RDMA有较大投入且与PCIe社区合作紧密,但是NVMe和NVMe
over Fabric本身并不依赖于RDMA。

3、SCSI也不是唯一的FC Native协议

      RDMA倡导者通常将NVMe
over以太网/IP和FC的延迟时间进行比较(这就像比较把IP和以太网比较一样),由于NVMe是上层协议,光纤通道是链路层协议。完整的比较应该是把NVMe
over以太网和SCSI over
FC进行比较,如果描述正确的话,这才是一个有效的比较。现在,作为光纤通道专家也意识到一个问题,由于FC上承载SCSI叫光纤通道协议(FCP),所以不止一个新手错误地认为所有的FC通信都必须是FCP。但事实上FCP与FC不一样,FCP仅仅是一种FC-4(上层)协议,类似于FICON(大型机存储协议),可以通过FC传输。

     
常常产生的一个误解是NVMe首先被翻译成底层SCSI(FCP)之后才运行在FC上。这种误解很有可能是由同样的白皮书引起的,它告诉我们理想的NVMe传输应该允许客户端“直接发送和接收本地NVMe命令,无需使用诸SCSI如此类的转换层”。这句话本身这是有道理的,因为NVMe是延迟优化的,而转换层却会引入延迟。

      实际上FC本身就可以运输NVMe,无需翻译和转化。NVMe over
FC定义了一个新的上层FC-NVMe流量类型,它识别了特定于NVMe的帧。

     
FC-NVMe标准组织认为在FC上同时支持NVMe和SCSI会具有更大价值。FC-NVMe标准规定了NVMe
over FC使用与FCP相同IO框架类型。FC作为多协议结构的长期使用和应用表明FC
SAN同时支持SCSI和NVMe是非常可靠的。

 

4、如何看待SCSI到NVMe转换层对NVMe产生的影响?

      NVMe fabric聚焦于最低延迟,NVMe over
fabric的白皮书说明传输的一个理想方式是不需要翻译层,如果存在SCSI到NVMe转换就是次优的传输方式。在编写应用程序时,如果能直接使用NVMe,不但有效避免翻译步骤,还将避免了每IO引入的时钟周期。FC不需要转换翻译且支持Native
NVMe。

     
与此同时,NVMe社区也意识到SCSI应用程序部署时,上层应用程序适配、兼容和SCSI到NVMe转换层的重要性。许多NVMe的潜在用户无法重新设计他们运行的应用程序,但希望能选择搬到NVMe基础设施之上,不依赖于它们的应用程序供应商重新设计。从这个角度来看,有一个转化翻译层作为一种选择对NVMe的采用和普及实际上是有益的。

     
值得庆幸的是,目前业界主流的HBA厂商都提供了从SCSI到 NVMe转换翻译的驱动程序,同时也提供Native
NVMe能力支持原生支持NVMe over Fabric应用程序。

5、FC能否实现零拷贝(Zero Copy)功能?

     
IP堆栈当时被开发时,主要设计用于处理许多上层协议和许多层2网络,从令牌环到电话线,清晰的网络层划分对于互操作性有很好的意义,为了达到这个目的最好的选择是使用中间缓冲,使缓冲区复制公共数据。

     
在20世纪80年代早期,提供单副本复制(Single-Copy)也算是一个好的网络协议栈,网络接口卡(NIC)接收帧后,通过DMA技术将它们写到与网络堆栈相关联的DRAM缓冲区中,然后堆栈会决定哪个应用应该接受、继续处理帧数据,并把数据复制到应用对应的DRAM缓存区中。

     
在20世纪80年代中期,随着FC的生产,一切发生了变化。FC主要特点就是速度,所以为了达到优化的目前,FC允许芯片技术更复杂,FC/SCSI堆栈的层数更少,也放开了IP堆栈所面临的向后兼容性的限制。因此,FC实现一个适配器、驱动模型的堆栈架构,从而消除单一副本(Single-Copy)。

     
事实也确实如此,当应用程序请求存储IO时,应用程序以“逻辑地址范围”的形式指定一个缓冲区地址,然后将其转换为DMA的物理地址范围实现DMA传输。有时,一个逻辑范围将映射到多个物理块,因此HBA采用Scatter-Gather
List
(SGL)完成数据传输和保存。FC通过提供零拷贝(Zero-Copy)技术,支持DMA数据传输。RDMA通过从本地服务器传递Scatter-Gather
List到远程服务器有效地将本地内存与远程服务器共享,使远程服务器可以直接读取或写入本地服务器的内存。

 

6、IP上的零拷贝(Zero-Copy)也不需要RDMA

      由于RDMA越来越流行,因此在2007年将其扩展了到Internet Wide
Area网络,从而形成RDMA协议(iWARP)标准。iWARP是建立在TCP之上的,传输协议使用确认和重传机制。TCP还采用一个“窗口”算法以避免传输超过了发送方和接收方之间的网络容量。

      在Internet Engineering Task Force (IETF) Requests For Comment
(RFCs 5040–5044)中,前一个RFC 5040中描述了RDMA如何使用Direct Data
Placement
(DDP)协议来实现FC和InfiniBand的零拷贝(Zero-Copy)效率,后一个RFC
5044标记了TCP中PDU对齐规范,有效地禁用了TCP 的“合并”行为,使得NIC更容易地处理接收的数据,提供DDP的硬件支持。

     
前面提到的RFCs为零拷贝(Zero-Copy)效率提供了基础,但是传统的NICs没有TCP处理功能。软件实现虽然提供了互操作性,但无法满足RDMA性能要求。为此,新的称为TCP
Offload Engines
(TOEs)的NICs卡就产生了,然而早期的TOEs都不适合iWARP,只有基于硬件实现DDP能力的RDMA使能TOEs才能提供类似FC一样的零拷贝(Zero-Copy)效果。

 

     
2009年前后,随着当时InfiniBand市场的低迷,NVMe获得了越来越多的关注,IETF的Transparent
Interconnection of Lots of Links (TRILL) 和IEEE的 Data Center Bridging
(DCB)获得发展动力并以太网成为无损的Fabric。其中TRILL是指除IEEE的生成树协议支持以外的任何以太网拓扑结构;DCB采用基于优先级的流量控制、增强的传输选择和数据中心桥接交换技术。

     
InfiniBand行业协会(IBTA)看到了一个机会,在新的技术领域利用其在RDMA方面的专业知识,因此,他们开发了RDMA
over Converged Ethernet (RoCE)规范(Converged
Ethernet就是早期的DCB)。就像iWARP需要专门的TOEs来实现零拷贝(Zero-Copy)效率一样,RoCE依赖于RDMA-enabled
NICs (RNICs)实现这一能力。IBTA认为RoCE的性能比iWARP更高,并指出了TCP
(iWARP)不是低延迟通信的理想协议。

     
因为以太网不提供类似TCP的可靠传输能力,RoCE标准是在更高层的协议堆栈中实现可靠性功能。在RoCE发布的时候,对IPv4地址有相关约束,对TRILL的2层以太网网络扩展能力也有很高要求。IBTA显然认为RoCE应该拥有交付大规模高性能RDMA所需的一切能力。

7、“可路由”的RoCE v2才是更好的RoCE

      Hyper-Scale和软件定义的网络推崇者促使IBTA创建RoCE
v2(有时会被称为“可路由的RoCE”),意在取代RoCE。不同于基于TCP的iWARP, RoCE
v2运行在UDP之上没有缓慢启动的节流行为。当然,采用UDP意味着RoCEv2帧不兼容RoCEv1帧(尽管支持RoCEv2的RDMA-enable的NICs通常可以配置为使用RoCE
v1格式
)。因为基于UDP的 RoCEv2缺乏类似TCP的显式拥塞通知能力,所以IBTA指出通过支持IETF的ECN实现在UDP之上传输层的流控制。

     
鉴于原文内容太多且作者英文也不好,所以解读到此为止,如果觉得上面内容没过瘾,请获取Brocade发布的全文资料。实际上,SSD和闪存发展的趋势就是结合NVMe实现更好的传输效率和性能,通过NVMe
over
Fabric实现更好的扩展性。关于SSD、闪存技术产品现状NVMe趋势详细分析,请通过原文链接获取电子书材料。

>>>相关阅读

  • 32Gb光纤技术将延续SAN存储网络之争

  • 50TB SSD商用预示EB级闪存系统指日可待

  • 如何成为全栈式软件架构师

温馨提示:
请搜索“ICT_Architect”或“扫一扫”下面二维码关注公众号,获取更多精彩内容。

听说点赞和分享的朋友都已走上人生巅峰

顺丰全栈资源下的自动化运维灵魂,丰全

查看评论

Mac电脑修改账户名称和个人目录后丢失管理员权限问题
午休时,其它部门…

作者简介:

陈天宇
顺丰科技系统技术管理部负责人,07年参加工作,先后任职于中国电信、平安科技、顺丰科技,专注运维领域10年,从公务员到运维工程师,再到高级小步兵,一路坚守用技术解决问题的理念。目前任职于顺丰科技,负责操作系统相关的技术管理工作。

前言:

首先,我们先发散一下思维,后收敛。天下武功为快不破,互联网时代,让大家可以充分的分享信息,运维大会这类平台再早5年的话,在中国做运维不会这么苦也不会那么累。

本文、我分享的主题是全栈资源下做自动化。做运维到现在,参加过7*24小时值班,抗过机器,敲过代码,也玩过数据库,这个课题也是在帮我回顾总结这些年的运维经历苦难后留下的一些思考与总结。

我觉得我没有遇到运维的好日子,我真正从推板车模式里走出来,才发现原来大家都是这么玩的,大家都在玩自动化,都是以这个方法论、方向在玩,都在向
AIdevops 前进。

好的东西大家都会认同,长的帅的,基本帅的差不多。大家都知道美好的运维长什么样,但达到这个目标的路线是大家最关心的,我们也正在这条路上。

工程师与科学家的不同在于,工程师专注于这件事情怎么做,像步兵一样,一步一个台阶往前进,我接触的大多是运维“工程师”,戏称高级小步兵。我喜欢这样去呼呼我们的同事、包括我自己。下面把思维收敛到具体的内容,看看我们在顺丰的步兵前行记。

一、服务器资源KPI时代

我们回归正题。讲自动化之前,我先讲讲我们所处的资源环境及规则。先讲一下服务器KPI。借用三个经典哲学的问题来思考为什么服务器资源的KPI不能忽视。

我是谁?我们是哪个行业?我们做运维,我们是IT行业;我们在这个行业当中,我们为什么站在这个风口浪尖上,为什么大家这么关注运维?

我前端时间看到有个朋友圈分享的信息:“老板说,你觉得你的公司需要运维吗?运维经理回答说,过独木桥的时候,老板你觉得需要栏杆吗?独木桥上没有栏杆你也可以走过去,但是有栏杆你走的更放心,运维就是一家公司的护航、类似医生。你造一个航母要有人维护这个航母。”

在这巨大的包含了思想、技术、智慧的灵魂流入IT行业的时候,同样需要强大的肉身来装载,肉身在这里我狭义的定义为基础硬件,广义的大家可以理解为运维。服务器资源作为基础架构三大组件资源之首,逃脱不了被KPI规则化。

1.1、服务器资源KPI时代-我是谁

顺丰服务器的增长迅猛增长,2013年服务器数量到2017年翻了20倍。服务器增长快到什么地步,2013顺丰机房的兄弟人手不够,做系统、虚拟化、windows的同事全部前线支援上架。

IT部门目前是纳入成本中心,服务器的每笔采购必须是把背景、技术框架、物理部署架构、上线计划、容量评估依据等讲的清清楚楚,这就需要完整的容量管理体系,在这个体系里哪些点才是key呢?在这快速增长过程中,我们的人员实际上是没有翻倍增长的,这些就是运维技术发展带来的红利。

我常与我们同事分享一个理念:我们追求运维新技术,刷新自己的技能不是为了追赶潮流,而是学习多一种新手段,在解决问题的时候会多一种选择。在这种引导下,现在我们再去给老板汇报预算的时候,都有数据支撑,我们把所有的从底层自服务器安装到OS标准化,到虚拟化模板,到应用、数据库的配置,及容量性能监控采集数据全部入库,并可展示。

还有下面一张图,是摩尔定律的,每26个月晶体管数量翻一番,现在来看摩尔定律遇到最大的问题就是如何解决散热,如果芯片设计不出现根本性变革,摩尔定律可能被打破。

说到这里,大家认为服务器KPI需要设定吗,怎么设定?是看使用率、看故障率、看采购价格、根据应用场景看使用率区间?如果使用率设置为KPI,那就是为performance
tune埋坑,数据库、应用优化做的越好,使用率反而更低,不合适。

好的KPI应该是服务器资源交付快,快到小时级别;硬件故障率低,低到整机千分之5以下;使用率在考虑HA及最优配置及业务高峰后,越接近服务性能极限越好。后面我们来说这些我们的行动路线。

1.2、服务器资源KPI时代-我从哪里来

我们从哪里来?这里要回到服务器资源投入到哪个业务上,带来的预估价值上来。之所以是预估价值,是因为这些涉及太多边际成本,我们只能狭义的去预估这个业务的价值,同样从业务到IT投入的价值评估模型建立我们也在进行中。

X86服务器不像小型机那样“高贵”,硬件的供应多选择,所以在选择的能力上我们要有,怎么做:建立硬件性能指标体系,看右侧的图就是我们底层用的工具。

明知芯片速度的提升已经达到难以为继的境界,但是人类对速度的追求却并没有丝毫停歇的意思。那怎样在不烧毁计算机的情况下满足人类漫无止凌的贪婪呢?

质量上不行,数量上补:多核结构出现。这当中,美国的一个研究室得到一个结论,并不是买机器的时候核数越高越好,服务器的核数对于OLTP型的应用性能提升最高是在八核的配置下;这些就让我们知道在选型的时候不会盲目追求核数越多越好,也知道应用迁移的时候,核数的增多带来的应用性能提升不一定对等。

1.3、服务器资源KPI时代-将要去哪里

我有个朋友在一家上市的电子公司工作,他们有全国有6个工厂。IT系统基本靠5台小型机承载;然后他问我,能不能也搞自动化?我说,你们用的小型机也挺稳定,而且运维共计就三个人,自动化没有必要做,但可以学习其中有用的理念:精益运维、主动预防。

做运维自动化,很多同事会问你的目标是什么,投了多少人,产出的如何,实用性如何?资源这块,我没办法解决,但目标我们不能变,不能因为资源影响我们运维人对美好运维生活的向往。

只有目标不变,我们才会自发的向这个方向走,当大家尝到好处,接受的人会越多,公司也就越支持,自然得到的资源就会越多。

首先强调是说,运维开发,为什么不是开发,它是运维出身的,你代码的逻辑都是用运维的思维沉淀下来写的;

我以前以为外面的和尚会念经,我招了一个,然后我让他写个自动化绑IP的API功能,就是VIP的;后来他2、3个小时写出来了,我看了一下,几条命令搞定了;我开玩笑说,你疯了,你入参这个不判断一下,别人输入字符串呢?掩码不判断下,别人输入的不同网段呢,不限定数字,别人输入260呢?

所以就是说,做开发的,他会写代码有这个开发能力,但是没有这个逻辑,根本写不出来你想要的东西。

这里有个能力三条边模型,类似字母“Z”,最下面的这条边我们可以叫做我们掌握的运维的逻辑规则基线,类似CAP理论、高可用、灾难应对、容量管理逻辑、应用日志输入规范、安全基线要求等等;最上面的边,我们可以叫做我们要做的事情或者目标;中间的斜线就是我们要达到目标的路径或者说的步骤,你会发现能力基线与目标与接近,斜率越小,也约容易。

招一个没有运维经验的研发,就好比基线在地底,你要完成运维开发的目标,斜率接近90度,挺难的。

我开始带团队只有2个人,现在有18个人,我当时因为去内部新生ITclass分享工作心得,赢得两位新大学生的青睐,2个研究生分组自愿到了我们团队

来了之后,我说你给我把所有的工单做一下,而且不用太分边界网络、数据库,这都要理解其中的原理;我会给他们强调:岗位有边界,但是技术是没有边界的(其实是引用的一位科学家的爱国之言,科学没有国度,但是科学家有祖国。)之前大家都是写sh,后面我提要求,所以自动化编码默认都使用python,这种自觉的推动下,大家的这种基本编码能力建立起来了。

为什么在爱因斯坦那个年代那么容易出伟大的物理学家;挺老一辈讲那时的大学老师去讲课的时候,都会很谦虚的说,今天讲相对论,我还太不懂,大家一起互相交流,相对论提出来的时候全世界懂的只有2.5个人;因为当时做物理研究的人很少。

现在做运维的很多的知识充分的交流,充分的去学习之后,大家已经知道了做的好的是什么样,已经知道了蓝图,如何去实现变的有迹可循。走这条路,没钱没资源,你有那么多坑要填,还是负责运维,要交付资源,交付网络,交付各种工单,真做这个事情需要领导认同;给予编制、给予支持、给予容错、给予严厉的价值要求。我很幸运遇到了一个这样的老板,他是这条路线的支持者,给予了我们很大的帮助。

发表评论

电子邮件地址不会被公开。 必填项已用*标注