网站建设功能文档,营销技巧和营销方法培训,制作网页时采用的最基本的语言是,宜春网站建设推广全国职业技能大赛云计算赛项---Linux系统调优案例 Linux系统调优案例#xff1a;OpenStack平台调度策略优化:OpenStack平台镜像优化#xff1a;OpenStack平台I/O优化#xff1a;OpenStack 平台内存优化#xff1a;Linux 系统调优-防止SYN 攻击#xff1a; Linux系统调优案… 全国职业技能大赛云计算赛项---Linux系统调优案例 Linux系统调优案例OpenStack平台调度策略优化:OpenStack平台镜像优化OpenStack平台I/O优化OpenStack 平台内存优化Linux 系统调优-防止SYN 攻击 Linux系统调优案例
1.Linux系统句柄介绍 文件句柄会随着进程数增加而增加。其实Linux是有文件句柄限制的而且Linux默认一般都是1024。在生产环境中很容易到达这个值因此这里就会成为系统的瓶颈。 在Linux系统的生产环境中会经常遇到“too many open files”的报错。这个报错顾名思义是打开过多文件数。不过这里的files不单是文件的意思也包括打开的通讯链接比如socket正在监听的端口等等所以有时候也可以叫做句柄handle这个错误通常也可以叫做句柄数超出系统限制。 在出现“too many open files”报错的时候大多数情况是由于程序没有正常关闭一些资源引起的所以出现这种情况这个时候需要检查I/O读写socket通讯等是否正常关闭等。当然也可以通过修改参数将系统的文件句柄限制提高来缓解这一压力。
2.Linux系统句柄优化 1.规划节点
IP 主机名节点192.168.200.21 localhost实验节点
2.基础准备 登录云平台进入实验自动分配一台CentOS 7.9云主机。使用云主机作为本次案例的实验节点。 1查看当前的句柄数 查看当前系统默认的文件句柄数量所以优化句柄数量限制是很有必要的。命令如下 [rootlocalhost ~]# ulimit -n 1024 可以看到系统默认限制是1024。系统默认的1024远远不够会导致系统报“too many open files”的错误。
2修改句柄数. 修改Linux系统的句柄数限制有两种方法一种是使用ulimit命令临时生效另外一种是修改配置文件永久生效。此处使用修改配置文件的方式。 注意如果使用命令临时生效句柄限制root用户可以调大或者调小句柄的限制而非root用户一旦设定了值就只能调小这个限制不能调大不然会报“bash: ulimit: open files: cannot modify limit: Operation not permitted”的错误。
修改配置文件调整句柄限制为65535命令如下 [rootlocalhost ~]# echo “* soft nofile 65535” /etc/security/limits.conf [rootlocalhost ~]# echo “* hard nofile65535” /etc/security/limits.conf 添加配置的解释如下 ● *代表所有用户。 ● soft超过文件句柄数时仅提示。 ● hard超过文件句柄数时直接限制。 修改完之后不需要重启系统即会生效但是需要重新登录。退出重新登录该云主机查看当前的句柄限制命令如下 [rootlocalhost ~]# logout Connection closed. Last login: Tue Feb 801:58:31 2022 from 192.168.0.70 [rootlocalhost ~]# ulimit -n 65535 可以看到当前的限制为65535。
OpenStack平台调度策略优化:
1.规划节点
IP 主机名节点192.168.200.11 controller控制节点
2.基础准备 根据云平台分配的主机All in one作为实验节点该案例只研究云平台在大规模创建云主机遇到特定报错时的解决方法。 案例实施
1.OpenStack平台报错分析 在OpenStack平台经历大并发的时候比如同一个平台大量的用户同时创建云主机单个用户创建大量云主机不会触发此种现象会达到云平台的性能瓶颈导致创建云主机报错。 大量用户同时创建云主机会对云平台的两个服务造成性能瓶颈一个是RabbitMQ当RabbitMQ达到瓶颈时会报如下错误 ERROR oslo.messaging._drivers.impl_rabbit [req-eb79ea09-247e-49e0-960b-0896ef978661 - - - - -] [303415c0-e494-4ea2-8158-d66d4165600d] AMQP server on controller:5672 is unreachable: timed out. Trying again in 10 seconds.: timeout: timed out 另一个就是DHCP。本案例重点讨论DHCP报错的情况不考虑RabbitMQ的性能瓶颈。DHCP报错信息如下 WARNING nova.compute.manager [req-8d9240cd-6a47-4979-a289-bdd58d399f0a 891c061e4aea4af8909a4affe0c24f92 c509a52800de4902845460fcc5318f3f - 8d899afee33641e0a094f85fbeb9b2c6 8d899afee33641e0a094f85fbeb9b2c6] [instance: 374aa944-6cd7-4dbf-a741-5bd44623919d] Received unexpected event network-vif-plugged-b803941a-c3ae-45d7-b962-13ba1ff00a31 for instance with vm_state active and task_state None. 在这种情况下因为大量的创建云主机导致获取IP地址超时然后就发生了如上的报错。
注意这个报错还和计算节点的性能有关大量创建云主机的时候计算节点如果没有创建过该镜像的云主机会先从控制节点复制镜像到计算节点这也会导致速度变慢。而且在创建大量云主机的时候对计算节点的硬盘也是一个考验如果硬盘性能差的话也会导致创建速度慢大量排队超时等现象。
2.解决策略 在解决问题之前首先了解创建云主机的过程在创建虚机过程中Nova-compute会调用wait_for_instance_event函数nova/compute/manage.py进行network-vif-plugged的事件等待。 在Nova-compute配置文件中有两个与该事件相关的参数- vif_plugging_timeout、vif_plugging_if_fatal前者是等待事件的最大时间后者是处理超时异常的方式。若在规定时间内Nova-compute接受到了事件响应那么虚机可正常创建那么当超时现象发生时Nova-compute会根据vif_plugging_is_fatal的配置采取两种处理方式。
若超时发生并且配置文件中vif_plugging_is_fatal为TrueNova首先执行guest.poweroff停止Qemu进程然后执行cleanup函数先清除网络资源使用函数_unplug_vifs删除plug_vifs函数创建的ovs portovs agent检测到了删除端口的事件然后通知Neutron-server删除neutron db中的port信息最后抛VirtualInterfaceCreateException。
如果vif_plugging_is_fatal为False即便发生eventlet.timeout.Timeout异常创建过程也会继续。然后等虚拟机创建成功后依然可以拿到IP地址。 通过上述虚拟机创建的过程对于上述云平台发生的错误就有了解决的思路通过修改/etc/nova/nova.conf配置文件将vif_plugging_is_fatal参数由true改为false命令如下 修改/etc/nova/nova.conf配置文件 [rootcontroller ~]# vi /etc/nova/nova.conf 找到如下这行 #vif_plugging_is_fataltrue 将该行的注释去掉并将true改为false修改完之后如下 vif_plugging_is_fatalfalse 保存退出nova.conf最后重启Nova服务也可以重启所有服务命令如下 [rootcontroller ~]# openstack-service restart 等待重启完毕即可。通过该参数的修改可解决在大并发量创建虚拟机时因排队超时导致虚拟机获取不到IP地址的报错。
OpenStack平台镜像优化
1.OpenStack平台制作镜像 在OpenStack平台的使用过程中镜像是一个不可或缺的组件与服务一般来说使用最多的是基础镜像比如CentOS7.5CentOS7.6CentOS7.9等获取这些基础镜像的方式也很简单可以通过官网直接下载。 当用户想使用自定义镜像的时候可以使用OpenStack平台中打快照的方式去制作镜像比如想制作一个带有数据库服务的镜像具体操作不再演示。 2.OpenStack平台镜像优化 1.规划节点
IP 主机名节点192.168.200.11 controller控制节点
2.基础准备 使用云平台分配的All in one作为实验节点本案例只讲述如何优化通过打快照方式制作的镜像。 案例实施
1.OpenStack平台制作镜像 在OpenStack平台的使用过程中镜像是一个不可或缺的组件与服务一般来说使用最多的是基础镜像比如CentOS7.5、CentOS7.6、CentOS7.9等获取这些基础镜像的方式也很简单可以通过官网直接下载。 当用户想使用自定义镜像的时候可以使用OpenStack平台中打快照的方式去制作镜像比如想制作一个带有数据库服务的镜像可以按照如下步骤操作具体操作不再演示 1启动一个基础的CentOS镜像 2连接虚拟机配置Yum源 3安装数据库服务 4初始化数据库 5设置开机自启 6在OpenStack平台中将该虚拟机实例打成快照 7在控制节点的镜像和快照存放目录/var/lib/glance/images目录下找到这个镜像文件改名成mysql.qcow2 通过上述的方法打快照制作镜像可以获得一个mysql.qcow2的镜像文件使用该文件上传至其他云平台中今后使用该镜像启动的虚拟机就带有数据库服务了。
2.OpenStack平台镜像优化 在使用打快照方式制作镜像后镜像的大小会变得非常大比如一个基础的CentOS镜像大小为400M左右但是使用打快照方式制作的镜像大小会有1个G左右具体的大小还要根据安装的东西来实际情况实际分析。
qemu-img命令中提供一个可用于镜像转换与压缩的选项即qemu-img convert。接下来使用该命令对已经打快照完成的镜像进行压缩操作。 使用提供的镜像CentOS7.5-compress.qcow2下载至controller节点的/root目录下查看镜像的大小命令如下 [rootcontroller ~]# curl -O http://mirrors.douxuedu.com/competition/CentOS7.5-compress.qcow2 [rootcontroller ~]# du -sh CentOS7.5-compress.qcow2 892M CentOS7.5-compress.qcow2 可以看到当前的镜像大小为892M接下来使用命令对镜像进行压缩命令如下 [rootcontroller ~]# qemu-img convert -c -O qcow2 CentOS7.5-compress.qcow2 CentOS7.5-compress2.qcow2 该命令参数的解释如下 ● -c压缩。 ● -O qcow2输出格式为 qcow2。 ● CentOS7.5-compress.qcow2被压缩的文件。 ● CentOS7.5-compress2.qcow2压缩完成后文件。 等待一小段时间后压缩完成查看当前目录下CentOS7.5-compress2.qcow2镜像文件的大小命令如下 [rootcontroller ~]# du -sh CentOS7.5-compress2.qcow2 405M CentOS7.5-compress2.qcow2 可以看到镜像大概被压缩到了一半的大小。使用qemu-img convert命令可以压缩QCW2镜像在日常的工作中经常会用到此命令进行镜像压缩。
OpenStack平台I/O优化
为什么需要IO调度呢在最开始的时候Linux存储在磁盘上。磁盘盘片高速旋转通过磁臂的移动读取数据。磁臂的移动是物理上的机械上的移动它无法瞬移这速度是很慢的。如果我们读取的数据位置很随机一会在A地点一会在隔着老远的B地点移动的时间就全做了无用功这也就是我们说的随机读写性能慢的原因。如果 读取的数据地址是连续的即使不是连续的也是地址接近的那么移动磁臂的时间损耗就少了。在最开始IO调度的作用就是为了合并相近的IO请求减少磁臂的移动损耗。
1.单队列I/O调度介绍 登录物理OpenStack平台的Controller节点查看I/O调度策略命令如下 此区域已隐藏一部分内容点击右侧按钮可展开… 可以看到物理节点默认使用的是deadline算法。常用的单队列算法就是noop、deadline和cfq关于这三种调度算法的详细解释如下 1noop noop只会对请求做一些简单的排序其本质就是一个FIFO的队列只会简单地合并临近的I/O请求后本质还是按先来先处理的原则提交给磁盘。 根据它的原理我们可以发现它倾向于饿死读利于写为什么呢异步写是把数据直接放到page cache的也就意味着可以通过page cache缓存大量的写数据再一次性往下提交I/O请求。而读呢读一般是同步的也就意味着必须在读完一笔后再读下一笔两次读之间是可能被写请求插足的。 2cfq CFQ全称Completely Fair Scheduler中文名称完全公平调度器它是现在许多Linux发行版的默认调度器CFQ是内核默认选择的I/O调度器。它将由进程提交的同步请求放到多个进程队列中然后为每个队列分配时间片以访问磁盘。对于通用的服务器是最好的选择CFQ均匀地分布对I/O带宽的访问。CFQ为每个进程和线程单独创建一个队列来管理该进程所产生的请求,以此来保证每个进程都能被很好的分配到I/O带宽I/O调度器每次执行一个进程的4次请求。该算法的特点是按照I/O请求的地址进行排序而不是按照先来后到的顺序来进行响应。简单来说就是给所有同步进程分配时间片然后才排队访问磁盘。 3deadline deadline确保请求在一个用户可配置的时间内得到响应避免请求饿死。其分别为读I/O和写I/O提供不同的FIFO队列读FIFO队列的最大等待时间是500ms写FIFO队列的最大等待时间是5s。deadline会把提交时间相近的请求放在一批。在同一批中请求会被排序。当一批请求达到了大小上限或着定时器超时这批请求就会提交到设备队列上去。 总体来讲deadline算法对request进行了优先权控制调度主要表现在如下几个方面 读写请求分离读请求具有高优先调度权除非写请求即将被饿死的时候才会去调度处理写请求。这种处理可以保证读请求的延迟时间最小化。 对请求的顺序批量处理。对那些地址临近的顺序化请求deadline给予了高优先级处理权。例如一个写请求得到调度后其临近的request会在紧接着的调度过程中被处理掉。这种顺序批量处理的方法可以最大程度的减少磁盘抖动。 保证每个请求的延迟时间。每个请求都赋予了一个最大延迟时间如果达到延迟时间的上限那么这个请求就会被提前处理掉此时会破坏磁盘访问的顺序化特征回影响性能但是保证了每个请求的最大延迟时间。 对于这三种调度算法的总结如下 ● noop 对于闪存设备和嵌入式系统是最好的选择。对于固态硬盘来说使用noop是最好的deadline次之而CFQ效率最低。 ● cfq 为所有进程分配等量的带宽,适用于有大量进程的多用户系统CFQ是一种比较通用的调度算法它是一种以进程为出发点考虑的调度算法保证大家尽量公平,为所有进程分配等量的带宽,适合于桌面多任务及多媒体应用。 ● deadline 适用于大多数环境,特别是写入较多的文件服务器从原理上看DeadLine是一种以提高机械硬盘吞吐量为思考出发点的调度算法尽量保证在有I/O请求达到最终期限的时候进行调度非常适合业务比较单一并且I/O压力比较重的业务比如Web服务器数据库应用等。 2.多队列I/O调度介绍 现在有多种multi-queue多队列调度器分别为bfqnonekyber和mq-deadline。下面对常用调度器的进行介绍 1mq-deadline mq-deadline调度器跟单队列的deadline调度器发挥的功能很相似。它有个insert_request()函数不会使用多个staging队列而是把请求放到两个全局的基于时间的队列中一个放读请求一个放写请求先尝试把该新请求与已经存在的请求合并如果合并不了则把这个新请求放到队列尾部。dispatch_request()函数会从这些队列中返回第一个请求基于时间的队列基于请求批大小以及避免写饥饿的队列。 2none 多队列无操作I/O调度程序。不对请求进行重新排序最小的开销。NVME等快速随机I/O设备的理想选择。 3.I/O调度策略修改 1.规划节点
IP 主机名节点192.168.200.11 controller控制节点
2.基础准备 使用云平台分配的All in one作为实验节点。 案例实施 I/O调度策略修改 调度策略的修改是比较简单的首先查看当前使用的调度算法命令如下 [rootcontroller ~]# cat /sys/block/vda/queue/scheduler [none] mq-deadline kyber 可以看到当前的I/O调度算法none修改算法为mq-deadline命令如下 [rootcontroller ~]# echo mq-deadline /sys/block/vda/queue/scheduler 修改完之后查看当前使用的算法命令如下 [rootcontroller ~]# cat /sys/block/vda/queue/scheduler [mq-deadline] kyber none 可以看到当前的I/O调度算法为mq-deadline模式。 以上就是I/O策略的优化无论是单队列还是多队列都可以使用echo命令去修改当前的I/O策略。选择何种策略也需要根据当前使用的硬盘与应用场景来决定不能盲目修改。
OpenStack 平台内存优化
搭建完 OpenStack 平台后关闭系统的内存共享打开透明大页。 [rootcontroller ~]# find / -name defrag /sys/kernel/mm/transparent_hugepage/defrag /sys/kernel/mm/transparent_hugepage/khugepaged/defrag [rootcontroller~]# echo never /sys/kernel/mm/transparent_hugepage/defrag [rootcontroller ~]# cat /sys/kernel/mm/transparent_hugepage/defrag always madvise [never] Linux 系统调优-防止SYN 攻击
修改 controller 节点的相关配置文件开启 SYN cookie防止 SYN 洪水攻击。 [rootcontainer ~]# vim /etc/sysctl.conf #添加以下参数 net.ipv4.tcp_max_syn_backlog2048 net.ipv4.tcp_syncookies1 net.ipv4.tcp_syn_retries 0 [rootcontainer ~]# sysctl -p net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.tcp_max_syn_backlog 2048 net.ipv4.tcp_syncookies 1 sysctl: setting key “net.ipv4.tcp_syn_retries”: Invalid argument net.ipv4.tcp_syn_retries 0
