云服务器中安装本地打印机_云打印机服务器搭建「云服务器连接本地打印机」

2018年纪人云Meetup第一站，连合vivo在深圳举行BuildingMicroservice系列活动第一期。本次技能沙龙vivo、复兴通讯、华为、数人云共同派出技能大咖，为开辟者们带来有关微服务、容器化、设置中心、服务网格等范畴的实战与干货分享。

　　数人云Meetup每月一期，欢迎各人来面基、学习。本文为vivo云盘算架构师袁乐林分享的“vivo云服务容器化实践”现场演讲实录。

　　本日讲的内容重要是先容技能配景，产物的技能架构，我们关键技能的实践，前车可鉴，以及对下一代云服务架构的假想。

　　技能配景

　　vivo这些年的业务增长非常快，用户数已经上亿，服务器到了万级，业务域好几百，后端体系的复杂度在敏捷攀升，不但是运维方面、架构体系复杂度也非常高，vivo技能架构也是到了破茧化蝶的时间。

　　我们做过容器、假造机与物理机性能对比测试。上面这张图是当时做的性能测试架构图。得出了一些测试结论：

　　1.容器化app（4c8g）在性能上略优于非容器化app测试指标2.容器化app（32c64g）性能相较于裸跑同物理机有近4%左右性能斲丧，此中TPS有3.85%斲丧，均匀相应时间3.95%（1毫秒）的增长，对业务哀求无影响。3.容器化app在12h的稳固性测试中表现正常4.容器化app在cpu相对配额，cpu绑定以及绝对配额场景下，业务性能CPU相对配额CPU绑定绝对配额。5.容器化app在组部件非常，单盘算节点，控制非常场景下，容器运行正常。

　　综上所述，容器化app性能上靠近物理机，在多测试场景下，表现相对稳固可靠。同时，对盘算麋集型app，相对权重配额能实现CPU资源利用率最大化。

　　vivo容器化云服务框架

　　正是由于这个性能测试数据的支持，就有了vivo容器化云服务框架，我们给它取名Kiver，提供轻量级、高可靠的容器化生产方案。

　　在这个框架之上vivo一共有八个云服务，按照厥后统计数据来看，MySQL加上其他两个服务占到80%的比例，这也非常符合“二八”原则。

　　vivo整个云服务容器化产物的架构，左边是运维主动化的工具集，比如日记、监控等，日记在业界应用非常广泛，我们用收罗容器的数据、容器的监控指标。

　　这里有两个日记，上面是中心件的业务日记平台，全部业务基于中心件日记规范，输出日记后都会送到这内里网络起来，但是这个业务日记平台功能如今比力单薄，对新增长的一些组件，比如ECTD等不支持。vivo又引入了如今容器范畴比力常见的日记方案EFK，以后会规划把两个日记整合到一起。

　　vivo在运维方面做了一些工具，如vivoMachineCtl和KiverCtl，两个工具重要实现宿主机的主动化，简单来说可以把宿主机操纵体系主动化地装起来，装完之后变成Kiver的盘算节点大概控制节点。尚有KiverPerfermance，是我们内嵌的一个小的性能测试插件。

　　再来看右边，是vivo的底子办法，物理机和互换机，网络装备和防火墙等，上面是Docker，Docker容器假造化技能把物理机上面的相干资源假造化用起来。

　　右边有Ceph块存储，实现数据备份，上面是vivo自研的DevOps平台，做了调治框架，右边是用harbor做的镜像堆栈，再往上就是云服务Portal，前面所说的那些云服务，同时也可以跑永生命周期应用。

　　宿主机主动化实践

　　下面我们讲一下vivo的实践。如今物理机一旦上了规模之后，装操纵体系就成为一件大事，我们提供了vivoMachineCtl，这个工具是一个下令行给运维职员利用，可以实现宿主机会合化的参数设置和主动化。

　　利用vivoMachineCtl，起首和物理机管理卡做一个交互，交互之后拿到物理机的MAC地点，这里有个BMC，也有厂商叫iDrac卡，它可以取得这台服务器网卡的MAC地点，创建以MAC地点定名的Bootfile，指明如今必要装什么操纵体系，和其他一些参数。再进一步给它一个ipmi消息对服务器复位，然后服务器开始重启。

　　重启之后，服务器第一次会发dhcp哀求，拿到IP地点，之后会走一个pxe的协议，拿到bootfile，下载Bootfile所指明的小体系和内存文件体系文件下来，加载到物理机中，然后开始举行操纵体系安装。这就是操纵体系安装的过程。操纵体系安装完成之后，把安装类和文件体系切换成正在启动的文件体系，在post阶段到会合化的设置中心，把相干的设置拉下来，包罗IP地点，主机名和网关等信息，这是宿主机的主动化摆设。

　　KiverCtl实际上就是把操纵体系的宿主机变成盘算节点大概控制节点。盘算节点有如下几个功能：第一，根本的包安装，第二，Docker、Netplugin初始化，启动kiver-guard/flume/cadvisor容器，完成日记和监控指标的收罗。

　　控制节点上面有Etcd和Netmaster，也会可选地把Prometheus/alertmanager/grafana/启动起来。vivoMachineCtl和KiverCtl实现了云服务器节点从物理机到宿主机的变化。

　　业务日记集成到日记平台实践

　　这是vivo日记收罗的实践，在宿主机上做日记分区，容器运行起来之后挂这个目次，每个容器起来之后会创建一个本身的文件目次。表面有kiver-guard，用来侦听内核文件体系的新日记文件创建的关照。

　　根据关照会创建软件链接，链接到上一级Flume监控的日记目次，由Flume推到kafka。大数据平台会来斲丧这里的数据，业务日记平台也会斲丧这个数据，然后长期化到ES里，末了由中心件日记平台来实现对日记的检索和展示。

　　为什么要这么做？当时用的flume版本不支持主动网络递归子目次下日记新增内容的网络，完备的文件可以网络进去，但是日记文件在递归子目次下有不绝地追加是输不进去的。

　　kiver-guard本身也是一个容器，它起来之后把宿主机日记目次挂上去，在容器内里侦听日记目次下的create变乱。

　　不管这些日记路径有多深大概在那边，都可以链接出来。做链接的时间有一点必要留意，要确保链接过来之后文件名称是唯一的。有些容器被删除了，大概日记被轮转删除了，同样也会针对Delete变乱，侦测到delete是件之后删除上层flume监控日记路径的对应链接。

　　底子组件日记网络实践

　　底子组件日记采取Etcd、Ceph、CentOS、Netmaster等一些网上比力热门的EFK组件，开箱即用。

　　监控与告警实践

　　这是监控和告警实践，在容器范畴比力常见，vivo采取的是Promethus和Alertmanager。Promethus采取双节点，双拉（拉两遍），两个Promethus之间没有做主从，为了办理高可用题目，挂了一个别的一个还在。

　　之后接短信邮件中心，背面接Grafana作为监控面板，前面用了telegraf。我们做的东西不但仅有容器，尚有其他的组件像Ceph。我们用Cadvisor网络容器监控指标。

　　我们对集群康健做监控，也对集群资源利用环境举行监控，集群的康健性采取telegraf可以调用外部shell脚本的特性。我们在控制节点写了脚本，用来查抄Etcd的康健环境，也和各个节点举行通讯，查抄各个节点是不是康健。之后会返回数值，给出集群康健状态码。

　　这个就是前面讲的自界说的一些监控指标，这是集群的康健查抄，这是集群的资源利用率，大抵两条数据链进来。一个脚本由telegraf去拉，推到Prometheus内里，末了展如今Grafana上面。另一个，由DevOps框架把数据写到Mysql内里，再由Grafana界说Mysql的软件源。

　　这边拉出来的自界说的康健指标支持返回码，这个返回码必要翻译成笔墨，实际上Grafana已经具备这个特性，我们可以去做一个映射，比如1代表监控，2代表网络题目等等，它可以主动翻译来。

　　数据长期化实践

　　说到云服务各人都会关注这个题目，数据怎么做到长期化，做到不丢。容器启动的时间会挂在宿主机上面的一个数据目次，和日记雷同，有容器的启动进程，直接写脚本也可以，创造二级目次。

　　用主机名，是在容器默认的主机名，就是它的默认ID号。假如这个ID已经存在就不消创建，阐明容器是起用一个旧的容器，末了创建软链接到数据目次。如许确保每个容器日记数据都长期化到宿主机，还可以确保容器重启后数据不丢。

　　第二，数据本身有一个单独的备份体系，它会每天晚上破晓2点跑一遍，把Mysql数据推到Ceph块存储当中，实现数据的可靠性。

　　集群可靠性实践

　　这是容器集群可靠性实践，最典范的是三个副本，副本可以或许实现数据和服务的可靠性。

　　失效重试，在集群各节点提供一个crontab定时任务，每隔一段时间探测一次docker服务进程康健状态，若不康健，则拉起Docker服务进程。同时我们开启了docker的Restartalways选项，确保容器服务非常退出后，能被重新拉起来。

　　关于隔离，起首是分区隔离，宿主机业务日记目次/app/log独立分区，克制日记量过大时陵犯宿主机体系分区大概业务分区磁盘。

　　第二，资源隔离，flume当时是跑进程的，我们做的第一件事变是举行容器化，之后做配额，限定能利用的资源利用量，克制大日记传输时陵犯宿主机过多资源。

　　第三，故障隔离，开启dockerlive-restore选项，保障docker服务进程不影响容器服务。

　　前车之辙

　　我们犯过一些错误，不负责物理机运营的童鞋大概感受不显着。假如磁盘引导分区被粉碎，就大概导致操纵体系被重装，这个题目是很严峻的。缘故起因也很简单，服务器一样平常有多引导的选项，比如磁盘、网络、CD，一样平常在次序上磁盘第一，网络第二。

　　但假如磁盘引导分区坏了，服务器会以为没有操纵体系，然后就从第二个上引导。这时间不幸的事变是，在你的网络环境里假如之前刚好装过操纵体系，采取了第三方开源的摆设服务器，而没有把之前的文件删掉，那么它就会把那些操纵重新装上。

　　办理办法很简单，我们提供了定时任务，对两个小时前创建的引导文件，能望见它的创建时间、访问时间，并举行逼迫性删除。

　　第二个前车之辙，在网络Ceph日记时碰到困难，当时是用fluent-plugin-ceph插件来做。具体的环境是，第一，官方设置文档不精确，由于提交者没按官方文档格式编码，导致看到的设置是一行，拿返来根本不知道怎么办。第二，它和td-agent1.0版本不兼容。探索出的办理方法就是图片上表现的办法。

　　下一代云服务架构

　　这是我们下一代云服务架构，与上一代的重要区别在于，把编排框架换成了Kubernetes。如今AI这块已经用起来了，AI部分在线上大概有一百台物理机，跑Job任务，短任务每天可以跑到三万个，一次性可以变更3000个容器，将来会把这个些换成Kubnernetes，包罗我们的AI、云服务都会跑在Kubernetes上。

　　XaaSonKubernetes

　　假如把云服务跑到Kubernetes上，第一个要做的事变，大概会采取ceph块存储做背面的数据和数据长期化。如今vivo已经有了数据ceph块存储，但功能还不强大。第二，要办理pod漂移调治题目，假如不消ceph块存储，pod失效调治到其他节点上有题目，调已往没用的，没有数据。

　　第三，也是最常见的一个，固定PODIP，看到网上有人讨论这个事变，以为容器坏了，没须要把容器固定起来，由于有违微服务的原则。这种观点不太对，有一些场景，比如在vivo的企业IT架构内里，很多东西都跟IP挂钩，比如安全战略，它不是跟域名挂钩，而是PODIP挂钩，互换机、防火墙等很多的设置都跟这个相干。以是vivo要干的很紧张的事变，就是把PODIP固定。

　　如今业界对这块也有一些实践，比如京东近来有这方面的分享，把PODIP放在一个APP的IP小池子内里，小池子内里尚有IP的话，就从小池子里拿，没有的话就从大池子里去申请。

　　添加小数微信：xiaoshu062

　　备注公司、姓名、职位

　　小数将拉您进入相应技能群