立即注册 登录
About云-梭伦科技 返回首页

goldtimes的个人空间 https://www.aboutyun.com/?1402 [收藏] [复制] [分享] [RSS]

日志

openstack经验总结

已有 2959 次阅读2014-11-9 10:07


openstack 扩展instance disk磁盘空间


qemu-img resize disk 1000GB

需要关闭虚拟机,然后再启动,注意这里是先关闭,再启动,而不是直接重启,根据我的测试,直接重启后,操作系统并不会检测到磁盘的更新。




openstack 迁移虚拟机项目

把一个虚拟机从A项目迁移到B项目
use keystone;
select id, name, enabled from project\G;

use nova;
select project_id, reservation_id, display_name from instances where project_id = ’52fd755a6cf74d72980039f2623ef72f’;
update instance set project_id =’e6aa57fbccac4775a320a3587648cafa’ where reservation_id =’r-7om7b3we’;

现在这个虚拟机已经出现在B项目里,但是IP地址没了。这个时候还需要迁移下端口。
现实环境中首先网络是由 交换机 和端口 组成。
那虚拟机环境中当然也不例外

use neutron;
将连接虚拟机的这个端口改到B项目
update ports set tenant_id=’e6aa57fbccac4775a320a3587648cafa’ where device_id=’2310208c-f327-4c2b-8191-75f0885418b9′;

把这个端口的网络设备改到B项目中网络设备上
update ports set network_id=’73709194-7eaa-42c8-88a3-9844f889e5c0′ where device_id=’2310208c-f327-4c2b-8191-75f0885418b9′;

然后进入虚拟机系统删除/etc/udev/rules.d/70-persistend-cd.rules
重启即可



openstack instace and image 延迟删除

nova虚拟机的软删除
修改nova.conf
# Interval in seconds for reclaiming deleted instances
# (integer value)
#reclaim_instance_interval=0

该值为0,则立刻删除。不为0,则为软删除。
在该时间到达前,可以通过API将虚拟机找回。
周期性任务_reclaim_queued_deletes会定期检查,真正删除已经到达时间的虚拟机。

image 延迟删除
glance 修改如下配置
delayed_delete=False为TRUE
scrub_time=0 多久删除

该值为0,则立刻删除。不为0,则为软删除。
在该时间到达前,可以通过API将虚拟机找回。
周期性任务_reclaim_queued_deletes会定期检查,真正删除已经到达时间的虚拟机。
相关API:
[plain] view plaincopy在CODE上查看代码片派生到我的代码片
# 强制删除(会对虚拟机立刻删除)
POST v2/​{tenant_id}​/servers/​{server_id}​/action
{
“forceDelete”: null
}

# 找回
POST v2/​{tenant_id}​/servers/​{server_id}​/action
{
“restore”: null
}

实现原理
实现原理比较简单,通过虚拟机数据库中的状态进行软删除控制。
通过定时任务进行虚拟机的删除。




ImageNotFound: Image 3bb459f8-2fd9-4464-9b66-f2f34c17396f could not be found.


我是纯粹OPENSTACK小白,以为删除了虚拟机启动的时候不需要原始镜像,就把镜像给删除了。结果实例重启的时候出现了悲催的错误,后来看了下原理.关于GLANCE镜像启动原理看这个地址

http://labs.chinamobile.com/mblog/854855/196136

文章说会缓存一个镜像到本地节点,那奇怪了 。我的镜像跑哪里去了

在看一个文章

http://docs.openstack.org/openstack-ops/content/disappear_images.html

大致意思:隔一段时间86400秒,检测没有用的镜像,然后果断给删,这样做可能是为了节省空间吧

那解决办法:
在来个文章

https://bugs.launchpad.net/nova/+bug/1029674

https://github.com/openstack/nova/commit/a8e83e130d999fecc217cc8581558193da780bc7

大概意思是修改计算节点nova.conf 里的配置
# Should unused base images be removed? (boolean value)
#remove_unused_base_images=true

# Unused unresized base images younger than this will not be
# removed (integer value)
#remove_unused_original_minimum_age_seconds=86400



openstack 自定义auth rule

Customizing Authorization
The default authorization settings only allow administrative users to create resources on behalf of a different project. OpenStack handles two kind of authorization policies:
Operation-based: policies specify access criteria for specific operations, possibly with fine-grained control over specific attributes.
Resource-based: whether access to a specific resource might be granted or not according to the permissions configured for the resource (currently available only for the network resource). The actual authorization policies enforced in an OpenStack service vary from deployment to deployment.
The policy engine reads entries from the policy.json file. The actual location of this file might vary from distribution to distribution, for nova it is typically in /etc/nova/policy.json. You can update entries while the system is running, and you do not have to restart services. Currently the only way of updating such policies is to edit the policy file.
The OpenStack service’s policy engine matches a policy directly. A rule indicates evaluation of the elements of such policies. For instance, in a compute:create: [["rule:admin_or_owner"]] statement, the policy is compute:create, and the rule is admin_or_owner.
Policies are triggered by an OpenStack policy engine whenever one of them matches an OpenStack API operation or a specific attribute being used in a given operation. For instance, the engine tests the create:compute policy every time a user sends a POST /v2/{tenant_id}servers request to the OpenStack Compute API server. Policies can be also related to specific API extensions. For instance, if a user needs an extension like compute_extension:rescue the attributes defined by the provider extensions trigger the rule test for that operation.
An authorization policy can be composed by one or more rules. If more rules are specified, evaluation policy will be successful if any of the rules evaluates successfully; if an API operation matches multiple policies, then all the policies must evaluate successfully. Also, authorization rules are recursive. Once a rule is matched, the rule(s) can be resolved to another rule, until a terminal rule is reached. These are the rules defined:
Role-based rules: evaluate successfully if the user submitting the request has the specified role. For instance “role:admin” is successful if the user submitting the request is an administrator.
Field-based rules: evaluate successfully if a field of the resource specified in the current request matches a specific value. For instance “field:networks:shared=True” is successful if the attribute shared of the network resource is set to true.
Generic rules: compare an attribute in the resource with an attribute extracted from the user’s security credentials and evaluates successfully if the comparison is successful. For instance “tenant_id:%(tenant_id)s” is successful if the tenant identifier in the resource is equal to the tenant identifier of the user submitting the request.
Here are snippets of the default nova policy.json file:

{
“context_is_admin”: [["role:admin"]],
“admin_or_owner”: [["is_admin:True"], ["project_id:%(project_id)s"]], [1]
“default”: [["rule:admin_or_owner"]], [2]
“compute:create”: [],
“compute:create:attach_network”: [],
“compute:create:attach_volume”: [],
“compute:get_all”: [],
“admin_api”: [["is_admin:True"]],
“compute_extension:accounts”: [["rule:admin_api"]],
“compute_extension:admin_actions”: [["rule:admin_api"]],
“compute_extension:admin_actions:pause”: [["rule:admin_or_owner"]],
“compute_extension:admin_actions:unpause”: [["rule:admin_or_owner"]],
“compute_extension:admin_actions:suspend”: [["rule:admin_or_owner"]],
“compute_extension:admin_actions:resume”: [["rule:admin_or_owner"]],

“compute_extension:admin_actions:migrate”: [["rule:admin_api"]],
“compute_extension:aggregates”: [["rule:admin_api"]],
“compute_extension:certificates”: [],
“compute_extension:cloudpipe”: [["rule:admin_api"]],

“compute_extension:flavorextraspecs”: [],
“compute_extension:flavormanage”: [["rule:admin_api"]], [3]
}

[1] Shows a rule which evaluates successfully if the current user is an administrator or the owner of the resource specified in the request (tenant identifier is equal).
[2] Shows the default policy which is always evaluated if an API operation does not match any of the policies in policy.json.
[3] Shows a policy restricting the ability of manipulating flavors to administrators using the Admin API only.
In some cases, some operations should be restricted to administrators only. Therefore, as a further example, let us consider how this sample policy file could be modified in a scenario where we enable users to create their own flavors:
“compute_extension:flavormanage”: [ ],



horizon 界面修改以及扩展


我的需求是用户只可以开虚拟机,上传KEY,我仅仅给项目分配资源就可以。。
所以把各种对于项目组的研发部需要的功能统统去掉,话说界面是真的好修改,但是附加功能还是有点点难度

openstack horizon修改

openstack horizon修改

有没有感觉我的好简单

HORIZON是高度化模块的形式去除界面是不需要的功能 只需要注释掉这个文件中的几行代码即可
/usr/share/openstack-dashboard/openstack_dashboard/dashboards/project/dashboars.py

class BasePanels(horizon.PanelGroup):
slug = "compute"
name = _("Compute")
panels = ('overview',
# 'instances',
'access_and_security',
# 'volumes',
# 'images',

class Project(horizon.Dashboard):
name = _("Project")
slug = "project"
panels = (
BasePanels,
NetworkPanels,
# ObjectStorePanels,
# OrchestrationPanels,
DatabasePanels,)
default_panel = 'overview'
supports_tenants = True
当然我把很多功能都集成到了admin账户下了,实现了一个账户总账户,底下的都是普通账户的简单需求

推荐个几个文档
http://www.metacloud.com/openstack-horizon-controlling-cloud-using-django/ 这个是讲HORIZON页面结构的文档,我感觉很不错。
http://docs.openstack.org/developer/horizon/topics/tutorial.html#run-and-check-the-dashboard 看完上面这个文档,在按照官网的步骤例子照做一遍,大概可以明白了


由于一个计算节点满了,不想虚拟机在开到此节点
我的存储时在本地的,所以需要新的主机不要开放在此节点
如果是存储是共享存储就简单

把一个计算节点调整成维护模式
nova host-update compute-01 --maintenance enable
ERROR: The server has either erred or is incapable of performing the requested operation. (HTTP 500) (Request-ID: req-5667d1ff-bgha-4veq-9drb-8c6'733f1s4b)

私有云的方法:

$ nova boot bla bla bla --availability-zone :

R Note: admin permissions are required. and the default zone is nova.

公有云的方法:

调用一下命令,将不会在此节点做任何操作
$ sudo nova-manage service disable --host= --service=




openstack 在一个节点上调整虚拟机大小

Resize a Running Instance on a Single Compute Node

One can resize a running instance in OpenStack by running the following nova command:
nova resize --poll 
The default behavior of this command is to invoke the nova scheduler to determine the best compute node for the resized instance. If there is only one compute node in the environment, the resize will fail.

We need to tell nova to allow resizing on the same host by modifying /etc/nova/nova.conf .

Modify /etc/nova/nova.conf

allow_resize_to_same_host=True
scheduler_default_filters=AllHostsFilter

By changing the default nova scheduler filter to AllHostsFilter , all compute hosts will be available and unfiltered. It is not a good idea to keep this setting in a multi-compute environment.

Restart Services
After making the changes to nova.conf, restart scheduler and compute services:

service nova-scheduler restart
service nova-compute restart

Resize Confirm
After resizing the instance, the status will change to VERIFY_RESIZE . One will see two copies of the instance in /var/lib/nova/instances : the original and the resized. Run the following command to verify the resize and delete the original instance:

nova resize-confirm

上面的文章我是转载的 我解释下
在你的所有控制节点和计算节点的/etc/nova/nova.conf 加入以下配置
allow_resize_to_same_host=True
scheduler_default_filters=AllHostsFilter
虽然文章说只重启scheduler服务和nova-compute服务。但是我发觉我重启了控制节点上所有的nova服务器 和计算节点上的openstack-nova-compute 服务才生效。。







路过

雷人

握手

鲜花

鸡蛋

评论 (0 个评论)

facelist doodle 涂鸦板

您需要登录后才可以评论 登录 | 立即注册

关闭

推荐上一条 /2 下一条