Chinaunix首页 | 论坛 | 博客
  • 博客访问: 5303119
  • 博文数量: 1644
  • 博客积分: 16831
  • 博客等级: 上将
  • 技术积分: 12469
  • 用 户 组: 普通用户
  • 注册时间: 2011-02-25 07:23
  • 认证徽章:
个人简介

柔中带刚,刚中带柔,淫荡中富含柔和,刚猛中荡漾风骚,无坚不摧,无孔不入!

文章分类

全部博文(1644)

文章存档

2019年(3)

2018年(19)

2017年(69)

2016年(61)

2015年(51)

2014年(201)

2013年(224)

2012年(644)

2011年(372)

分类: 云计算

2015-07-17 13:28:12

cloudstack+xenserver6.2  私有云架设问题个人汇总(随笔更新)

  (2015-04-20 12:41:16)
标签: 

xenserver

 

cloudstack

分类: cloudstack xenserver
storage存储的cache缓存相关机制write-though和write-back(write-caching)

1,write-though即写操作直接写入磁盘,不使用缓存;
  即关闭写缓存
  这样就释放了更多缓存给读操作


2,缓存用于读写操作

3,write caching提升写操作的性能,因为先写到缓存中,再由存储的控制器定时把缓存数据写入到存储中
  write caching也叫write-back

4,到底是write-though或是write-back(write caching)哪种性能更好;和磁盘的工作负荷及磁盘访问方式有关

5,如果磁盘负荷很轻,比如过n久才发生io,而不是高并发的io;此时把数据先写在缓存,然后由控制器把缓存中的数据
  写入到磁盘中;自然是写性能很高
 
  但如果磁盘负荷相当重,比如不停发生io,这时把数据先写入缓存,为了写入新的数据,缓存中的数据必须要马上
  写入到磁盘中,为新的io把缓存腾出来;这样你想想,一个写操作要分为2次完成,反而减少了写性能
 
6,上述说到如果先把写的数据放在缓存中,哪么控制器会定时把缓存的数据写入到磁盘中,到底多久把缓存数据写入
  到磁盘,这里有几个参数控制
 
  且仅与write-back(write caching)有关
 
  starting cache flushing level
 
  stopping cache flusing  level
 
  二参数表示占用整个缓存的百分比
 
  如果缓存中未写入磁盘的数据达到starting cache flushing level,控制器开始把缓存数据写入到磁盘
 
  如果缓存中未写入磁盘的数据低于stopping cache flushing level,控制器停止把缓存数据写入到磁盘
 
  控制器总是先写入旧的缓存数据
 
  缓存中未写入磁盘的数据在缓存中20秒会自动写入到磁盘
 
7,典型配置二参数为80%,可以缓存更多的数据,提升写性能,但会牺性数据保护(因为更多的数据在缓存中,可能存储掉电就loss)     

  最好二参数配置成一样
 
  (因为由缓存写到磁盘的动作一直停不下来,所以会导致磁盘不停的写,即造成block disk)
  如果stopping cache flushing level远小于starting cache flusing level,由缓存写入磁盘会导致磁盘阻塞
 
8,cache block size
   指定缓存分配单元的大小
  
   可以指定4k或8k或16k
  
   选择合理的值,可以提升缓存的性能
  
   如果应用程序常常访问小于4k的数据,而把cache block size配置为16k,每次仅使用一部分cache block的空间,造成浪费
  
   如果应用程序比如oracle多是随机io和小数据块,4k比较合适;
  
   如果是数据仓库它多是顺序io和大数据块,16k比较合适 


[CloudStack] 使用全部资源

CloudStack 默认只能使用 85% 的资源 (CPU/内存/存储等),超过85% 则无法创建 VM实例,也就是说 CloudStack 会保留 15% 的资源不被分配使用

默认值
默认的比率值为 "0.85"(85%) , 我们将其更改为 "1" 也就是 100% 使用


cloudstack+xenserver6.2 <wbr> <wbr>私有云架设问题个人汇总(随笔更新)

重启MS
复制代码

1
/etc/init.d/cloudstack-management restart

资源信息
cloudstack+xenserver6.2 <wbr> <wbr>私有云架设问题个人汇总(随笔更新)

其它
如果是CPU 按照以上步骤修改 "cluster.cpu.allocated.capacity.disablethreshold" 参数即可。
,在同一个区域如果添加第二台主机失败,请尝试在第一台主机上创建池,把第二台主机加到池里面,就可以了,同时要查看时间是否同步(最好用NTP与装有NTP服务的节点设备同步一下),再添加主机的时候,新添加的主机最好与原CS的主机配置要同步,包括CPU,内存等。

NFS缓存IO机制

默认的mount参数为async,async 参数表示内核不会透传程序的IO请求给sever,对于写IO会延迟执行,积累一定的时间以便合并上层的IO请求以提高效率。

如果mount的时候选用sync参数,或者如果上层使用 sync 调用,那么其产生的读I/O一定在内核处也是同步的,因为只有在前一个读请求数据成功返回给客户端程序,客户端程序才会发起下一个读请求,(对于异步读调用,内核可以在短时间内接受到多个读请求,此时内核可以将这些读请求合并,这就是异步过程)。但是同步读并不影响nfs的预读.
,故障信息
1. XenServer 集群三次无故重启,先后排除UPS电源,服务器硬件设备,网络设备等。
2. 所有 XenServer 同时重启,查看系统日志发现大量 "nfs: server 10.0.0.X not responding, timed out"cloudstack+xenserver6.2 <wbr> <wbr>私有云架设问题个人汇总(随笔更新)
3. NFS 服务器IOwait 等待严重
cloudstack+xenserver6.2 <wbr> <wbr>私有云架设问题个人汇总(随笔更新)

故障原因
发现如果 xenserver 无法得到 nfs存储响应,会尝试多次连后由heartbeat 守护进程自动重启服务器。
复制代码
1
2
3
4
5
6
Feb 11 09:51:04 xen-34 heartbeat: Potential problem with /var/run/sr-mount/7c71a215-8b19-d623-2f99-88654be0cfaa/hb-0021f92c-b3cc-4180-b1a7-a9082a347aee: not reachable since 26 seconds
..
Feb 11 09:51:26 xen-34 heartbeat: Potential problem with /var/run/sr-mount/7c71a215-8b19-d623-2f99-88654be0cfaa/hb-0021f92c-b3cc-4180-b1a7-a9082a347aee: not reachable since 48 seconds
..
Feb 11 09:51:51 xen-34 heartbeat: Potential problem with /var/run/sr-mount/7c71a215-8b19-d623-2f99-88654be0cfaa/hb-0021f92c-b3cc-4180-b1a7-a9082a347aee: not reachable since 73 seconds
Feb 11 09:51:51 xen-34 heartbeat: Problem with /var/run/sr-mount/7c71a215-8b19-d623-2f99-88654be0cfaa/hb-0021f92c-b3cc-4180-b1a7-a9082a347aee: not reachable for 73 seconds, rebooting system!
cloudstack+xenserver6.2 <wbr> <wbr>私有云架设问题个人汇总(随笔更新)


解决方法
1. 临时
调整NFS 写入磁盘策略由 "sync"同步写入 变更为 "async"异步写入,注意 "async" 存在数据丢失的风险。

2. 更换存储设备


扩展
关于NFS的缓存IO机制
sync 代表资料会同步写入到内存与磁盘中。
async 则代表资料会先暂存于内存当中,而非直接写入磁盘。
>简单配置了NFS,nfs的设置到不复杂,本机测试通过。但是客户端在卸载时或挂载文件/磁分区时,总出现错误,类似以下:
[root@node1 ~]# showmount -e 192.168.0.26
mount clntudp_create: RPC: Port mapper failure - RPC: Unable to receive

[root@node1 ~]# mount -t nfs 192.168.0.26:/data /mnt
mount: mount to NFS server '192.168.0.26' failed: timed out (retrying).
mount: mount to NFS server '192.168.0.26' failed: timed out (retrying).
mount: mount to NFS server '192.168.0.26' failed: timed out (giving up)
 

在nfs服务器端中iptabes里面开放了如下的端口111:tcp 111:udp 2049:tcp 2049:udp,测试还是报错。
后来,经测试关闭防火墙就没问题。开启防火墙就出现上述问题。后来,经查询是NFS端口没有完全通过防火墙导致。

NFS主要用到的端口有:111- portmapper, 875 - rquotad,2049-nfs,udp:32769-nlockmgr(tcp 32803-nlockmgr),892-mountd..

分别把以上端口(程序所用端口)加入iptables允许其通过即可。

编辑配置文件为 /etc/sysconfig/nfs设置端口号:(添加红色字体即可)

# vi /etc/sysconfig/nfs


RQUOTAD_PORT=875
LOCKD_TCPPORT=32803
LOCKD_UDPPORT=32769
MOUNTD_PORT=892

重启相关服务
# /etc/init.d/portmap restart
# /etc/init.d/nfs restart
查看服务运行的相关端口情况
[root@bj data]# rpcinfo -p
   程序 版本 协议   端口
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp    709  status
    100024    1   tcp    712  status
    100011    1   udp    875  rquotad
    100011    2   udp    875  rquotad
    100011    1   tcp    875  rquotad
    100011    2   tcp    875  rquotad
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100021    1   udp  32769  nlockmgr
    100021    3   udp  32769  nlockmgr
    100021    4   udp  32769  nlockmgr
    100021    1   tcp  32803  nlockmgr
    100021    3   tcp  32803  nlockmgr
    100021    4   tcp  32803  nlockmgr
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100005    1   udp    892  mountd
    100005    1   tcp    892  mountd
    100005    2   udp    892  mountd
    100005    2   tcp    892  mountd
    100005    3   udp    892  mountd
    100005    3   tcp    892  mountd

调整你的iptables规制如下:
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 111 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 111 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 875 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 875 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 892 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 892 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 32803 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 32769 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2049 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 2049 -j ACCEPT

[CloudStack] 日常维护正确的关闭与开启顺序

cloudstack 私有云,由多个节点组成,包括管理节点 计算节点 存储节点等,维护时需要正确的关闭顺序,以免操失误导致数据丢失.

案例

机房电力设备维护,时间较长UPS无法支撑,需要在断电前关闭cloudstack 私有云.

关闭顺序
1 关闭VM实例
2 禁用zone
3 关闭系统VM (cpvm/ssvm/虚拟路由器)
4 关闭MS服务器
5 关闭Hpyervisor 服务器(XenServer Pool集群,先关闭集群内成员最后关闭Master)
6 关闭存储服务器


开启顺序

维护完毕后,按照相反的顺序开启.
1 开启存储服务器
2 开启Hpyervisor 服务器(XenServer Pool集群,先开启Master最后开启成员)
3 开启MS服务器
4 开启zone
等待系统VM 自动开启
6 启动 VM实例

值得注意的是,开启时注意要有一定的延时,例如 确保存储服务器正常运行后,再开启Hypervisor服务器,以此类推.

八, 今天鄙人在执行上面的测试断电步骤发现一个问题,实例都起不了,查看了下日志,基本是资源分配的问题,然后我在基础架构里面找到了问题所在,VR(路由器)居然异常,虽然running是正常的,但是控制台打开异常,这说明VR是有问题的,有问题那就分配不了IP啊,呵呵,然后重启了下VR,开启实例就正常了。

九,通过CS创建的实例在重启基本会默认为ISO引导,这个基本是JAVA编码写死了,怎么解决呢,在实例界面上打开,如图:cloudstack+xenserver6.2 <wbr> <wbr>私有云架设问题个人汇总(随笔更新)左数第6个,点取消附件ISO就OK了,哈哈。

十,XENSERVER安装RHEL7.0 IP不能分配,手动设置

二、设置IP地址、网关DNS

说明:RHEL 7.0默认安装好之后是没有自动开启网络连接的!


	
  1. cd  /etc/sysconfig/network-scripts/  #进入网络配置文件目录 


	
  1. vi  ifcfg-eno16777736  #编辑配置文件,添加修改以下内容 


	
  1. TYPE="Ethernet" 
  2. BOOTPROTO="static"  #启用静态IP地址 
  3. DEFROUTE="yes" 
  4. IPV4_FAILURE_FATAL="no" 
  5. IPV6INIT="yes" 
  6. IPV6_AUTOCONF="yes" 
  7. IPV6_DEFROUTE="yes" 
  8. IPV6_FAILURE_FATAL="no" 
  9. NAME="eno16777736" 
  10. UUID="8071cc7b-d407-4dea-a41e-16f7d2e75ee9" 
  11. ONBOOT="yes"  #开启自动启用网络连接 
  12. IPADDR0="192.168.21.128"  #设置IP地址 
  13. PREFIX0="24"  #设置子网掩码 
  14. GATEWAY0="192.168.21.2"  #设置网关 
  15. DNS1="8.8.8.8"  #设置主DNS 
  16. DNS2="8.8.4.4"  #设置备DNS 
  17. HWADDR="00:0C:29:EB:F2:B3" 
  18. IPV6_PEERDNS="yes" 
  19. IPV6_PEERROUTES="yes" 
  20. :wq!  #保存退出 
  21. service network restart   #重启网络 
  22. ping www.baidu.com  #测试网络是否正常 


	
  1. ip addr  #查看IP地址 



 十一,[CloudStack] VM实例扩展磁盘

环境
CloudStack 4.4
XenServer 6.2

计算方案
Small
cloudstack+xenserver6.2 <wbr> <wbr>私有云架设问题个人汇总(随笔更新)

磁盘方案
Small
cloudstack+xenserver6.2 <wbr> <wbr>私有云架设问题个人汇总(随笔更新)

扩展磁盘
关闭虚拟机
cloudstack+xenserver6.2 <wbr> <wbr>私有云架设问题个人汇总(随笔更新)

扩展完毕后
cloudstack+xenserver6.2 <wbr> <wbr>私有云架设问题个人汇总(随笔更新)

VM磁盘信息
cloudstack+xenserver6.2 <wbr> <wbr>私有云架设问题个人汇总(随笔更新)

注意:只有数据卷可以扩展,ROOT卷无法扩展

十二,XenServer中网卡绑定模式分析

  • by Froyo
  • 08/31/2011 at 8:31:55

XenServer的网卡绑定使用linux提供的绑定机制,而XenServer支持Linux的Source Level Bond(SLB)以及Active-Passive Nic Bond(A/P)两种绑定模式。

关于Linux支持的7中Bond模式,这里简单介绍下,网上找了找资料:

bond mode bond mode name bond description remarks
0 balance-rr
(round-robin policy)
轮询策略 依次轮流传输数据库,知道完毕,提供负载均衡和冗余功能
1 active-backup
(active-backup policy)
主/备策略 只有一个网卡活动,当活动网卡宕掉以后,另外一块设备马上接管,MAC地址对交换机只有一个端口可见,避免了混乱,该模式提供冗余功能
2 balance-xor
(XOR policy)
布尔异或策略 基于MAC地址与目的地址的异或来决定流量走哪块网卡,同一目的MAC会走相同的网卡,该模式提供负载均衡和冗余
3 broadcast
(Broadcast policy)
广播策略 发送所有流量到所有网口,该模式提供冗余功能
4 802.3ad
(IEEE 802.3ad Dynamic link aggregation)
动态链接聚合策略 需要ethtool support和交换机对802.3ad的支持,建立相同速率和双工设置的聚合组
5 balance-tlb
(adaptive transmit load balancing)
适配器传输负载平衡策略 发送流量基于网卡当前负载决定,主要基于相对速率的计算,入栈流量由当前网卡接收,如果失败,则另外一块网卡接管,提供冗余功能
6 balance-alb
(Adaptive load balancing)
适配器负载平衡策略 在模式balance-tlb的基础上,对接收的负载进行计算并实现负载均衡

我 们可以看到linux提供了多种绑定模式的支持,而XenServer的bond也是基于Linux的绑定功能,但是官方指出,只支持mode 6(Active/Active)与Mode 1(Active/Passive)两种模式,使用其他模式,可能不受官方技术支持,但是实际测试发现,XenServer的绑定也支持其他几种模式。 (实测了mode=3)

通过设置pif的参数bond-mode来实现修改bonding的模式:

1
2
3
4
#设置绑定模式为主/备模式
xe pif-param-set uuid= other-config:bond-mode=active-backup
#or
xe pif-param-set uuid= other-config:bond-mode=1

设置bond-mode=6则为XenServer默认的A/A负载均衡模式,也可以设置成其他模式。

注:修改完绑定模式以后,需要重启XenServer生效
十三,xencenter 直接导出 vhd
xe vdi-list  name-label='dsf' is-a-snapshot=false  params=all
xe vdi-list name-label='centos6.4 0' is-a-snapshot=false

xe sr-list name-label=base 取得
xe vdi-copy uuid=96be4f59-cb63-43a1-a004-9ce8eea89c36 sr-uuid=79883d2d-56b9-9719-36db-57124d701c06
十四,XenServer tools服务启动失败 Error:1053
当试图启动Citrix XenServer Tools服务时候,会显示以下错误消息:

 

此外,在XenCenter中的虚拟机的常规选项卡,你可以观察到,没有安装的XenServer工具在虚拟状态显示,在下面的屏幕截图所示: 

 


 

Cause

 

XenServer 6.0版本有冲突,如果只有微软的。NET Framework 4的客户端配置文件被安装在虚拟机上。

 

Resolution

 

为了解决上述问题,请完成以下步骤:

1.        从虚拟机,卸载Microsoft .NET Framework 4 Client profile

2.        下载完整版本的 Microsoft .NET Framework 4从下面的网页, Microsoft .NET Framework 4 FULL.

3.        在虚拟机上安装的 Microsoft .NET Framework 4

4.        重新启动虚拟机。
开始在XenServer Tools服务。

十六,系统启动异常解决办法

进数据库 mysql -p

update vm_instance set state='Stopped' where instance_name='s-1-vm'
十七,

阅读(1351) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册