ceph 之osd 分类（class）

  1. ceph不能自动识别磁盘类型
  2. 设置osd分类前osd需要是未分类的，即：修改osd分类的做法是，先移除原有的分类，在添加新的分类：

     
  3. 操作osd分类使用的不是ceph osd crush class *
  4. 根据磁盘分类查看osd：

     
  5. 然后参考ceph osd crush rule 来创建自己的规则，如只存放在hdd上，或只存放在ssd上的规则，然后对pool设置响应的规则
  6. class 不需要预先创建：

    没有提供一个方法add class ssd， 也没看到一个方法可以del class ssd

 

参考： http://docs.ceph.com/docs/master/rados/operations/crush-map/

通过virsh创建基于lvm的pool

参考：

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-lvm_based_storage_pools#sect-LVM_based_storage_pools-Creating_an_LVM_based_storage_pool_with_virsh

 

示例：

将一个img 磁盘文件导入kvm-pool (结果总是失败)

  1. 创建一个volume：
  2. 导入img文件：

    总是提示： 无法关闭卷ceph-3； 然后将无法从ceph-3启动虚拟机
  3. 使用新的volume启动虚拟机

成功的做法

  1. 定义一个ceph-3.xml

     
  2. 将centos7.3.img 放到 /var/lib/libvirt/images 下面，然后：

openstack之迁移与热迁移

在配置openstack的热迁移时遇到了几个问题，这里记录一下。

  1. 迁移和热迁移的区别
    不太注意的情况下，发现迁移也挺快的，其实区别太大了

    1. 迁移是先停掉虚拟机，再启动虚拟机
    2. 热迁移基本是无感知的，虚拟机中的进程是不会死掉的
    3. openstack中，热迁移可以选择目标地址，迁移不能选择目标地址
    4. 迁移不需要libvirtd listen12506端口，热迁移需要
  2. 热迁移注意事项
    1. 要确保该落地的都落地了
    2. 虚拟机所在环境要高度一致
      1. 都使用正确配置了的共享存储
      2. qemu-kvm版本要一致
  3. 热迁移失败的故障排查
    1. 由于使用的qemu-kvm是官方的源，后来安装的qemu-kvm版本高了一些，所以热迁移总是失败，nova的日志中没有看到错误信息，结果却是在dashboard的httpd的错误日志中发现了问题所在，于是将所有qemu-kvm升级到最新版本
    2. 由于对热迁移没有研究过，基本小白一个，再次热迁移失败后，从目标机器nova的日志中看到错误信息，大致意思为libvirt连接源计算节点的12506端口失败，然而源计算节点并没有listen 12506端口，解决办法： http://yansu.org/2013/03/25/open-tcp-port-of-libvirt.html

libcgroup相关命令

lscgroup： 列出各cgroup及其挂载点； qemu 也是通过cgroup进行资源限制的

cgsnapshot  可以列出当前各cgroup子系统的配置信息

lssubsys  列出各子系统及其挂载点

 

 

openstack 安装记录

遇到过的问题：

  1. 配置文件贴错位置了
  2. 网络配置中漏掉了compute节点相关配置
  3. compute 节点qemu-kvm 版本低了一点
  4. mysql连接数被用完
    1. 配置了max_connections 也不管用，因为ulimit给限制了，修改ulimit后就可以了

解决思路：

  1. 根据id查日志 /var/log/

疑问：

  1. 创建机器的时候为什么指定的是网络的id，而不是子网的id？
  2. 在myservice network中，多个子网的情况下，因为无法指定子网id，如何确定机器是要放在哪个子网的？
    1. 可以明确指定ip地址来主动选择子网
  3. vxlan 端口号曾经是8472，后来修改为了4789，但是linux内核还在使用8472

其他：

  1. 路由器总是在控制节点上面的吗？
  2. 对于myservice网络，跨网段总是要求网关的，网关的压力势必会比较大，如何解决？
    1. provider 网络不存在该问题

原理：

  1. 浮动IP
    1. 浮动IP体现为路由器的网关接口的子接口
    2. provider网络默认是snat为true的，所以myservice网络默认是可以访问公网的，需要的话，可以将snat设置为false
    3. 浮动IP和绑定的vm之间的关系通过iptables规则实现，默认添加snat和dnat；需要的话：
      1. 可以只设置snat，则只允许出而不允许入；
      2. 也可以只设置dnat，只允许入不允许出
      3. 还可以让多个vm共享一个出口IP
    4. 这些都可以ip netns到相关路由器的名字空间中查看，注意：
      1. ip netns是通过/var/run/netns 中发现ns的，并非所有的netns都必须在这里注册的（docker 创建的netns就不放在这里）
      2. lsns 可以发现所有的ns，lsns是从/proc/$pid 中扫出来的
  2. 路由器
    1. 进入路由器所在网络名字空间中就可以查看路由器相关信息

php 之 stream编程

比较：

和

  1. 前者更加简单，后者显然复杂了一些
  2. 如果下载很大的文件，前者需要更多的内存，后者不需要
  3. PHP的stream wrapper的概念使得php的stream编程简单了许多
  4. 这两种方式都丢弃了http响应头信息，而对于请求头来讲，都可以通过context参数来设置