Jump to: navigation, search

Difference between revisions of "Main Page/cobbler"

Line 1: Line 1:
Hi:
 
  
I have deployed a RDO havana version's openstack environment for a period.
+
sqlalchemy和sqlalchemy-migrate在openstack的应用介绍
  
By chance I tested APIs of ceilometer, in the first I defined a new meter like meter_test, then used 'ceilometer sample-list -m yjmeter' command to check the result.
+
sqlalchemy
I found that the query cost about 13 seconds, why it was so slow with one record?
+
简介:
 +
提供ORM(对象关系映射)能力的python库,类似hibernate技术,支持postgresql、mysql等主流关系数据;用户只需定义DB对应的类,通过操作类实例,即可通过sqlalchemy引擎转换成标准sql语句,对DB进行操作
  
Now that RDO used mongodb as default DB for ceilometer, I logging into it and found that the meter collection had about 2,700,000 records. Maybe the mass records slowed the query.
+
Openstack中的应用:
 +
openstack各项目涉及关系数据库的DB driver,基本都是使用sqlalchemy库。
 +
table对应class定义:\nova\db\sqlalchemy\models.py中,例如class Instance(BASE, NovaBase)
 +
db操作API:\nova\db\sqlalchemy\api.py,调用sqlalchemy相关库函数操作DB,数据实体使用models.py定义的class
  
Take production environemnt into account, If there are 100 hosts , each host contains 30 VM.
+
sqlalchemy-migrate
CeilometerI use default configuration of 11 compute pollsters and the pipeline interval is 600s.
+
简介:
Then one day system will generate 4,752,000 record, the formula is: 11(meter) * 30(VM) * 6(system run pollsters 6 times an hour) * 24(a day) * 100(host) = 4,752,000 records.
+
基于sqlalchemy库,提供数据库版本管控能力的python库。
  
For above case I think it is necessary to restrict number of records by some mechanism, below are my immature idea:
+
Openstack中的应用:
1. Make restriction on max supported records by time or number of samples, discard old records.
+
版本升级能力是openstack当前能力较缺失的一块,但是从DB升级的角度看,由于引入了sqlalchemy-migrate框架,openstack各项目比较容易管理DB的变化,例如新增加一张table,新增加一个字段等。
2. Providing API to delete samples by resource_id or some other conditions, so the third integration system may call this API to delete related samples when delete a resource.
+
sqlalchemy-migrate在2011年发布了0.7.2版本后,就已经停止更新了,也不接受bugfix。因此openstack考虑引入Alembic(同样由sqlalchemy-migrate的开发者)替代sqlalchemy-migrate
3. Running period task of accounting on raw samples, using 1min samples to generate 5min statistics samples, using 5min statistics to generate 30min statistics samples, and so on. Every period of sample has individual data table and has resriction on max supported records .
+
sqlalchemy-migrate提供upgrade(升级)、downgrade(降级)、db_version(查看最新版本)等接口
  
I am not a ceilometer programmer and I apologize if I am missing something very obvious.
+
应用举例:
Can you give me some help to make me clear about them and how to implement my requirement?
+
在H版本代码基础上nova项目提供USB设备管理能力,故在DB Layper需增加一张table存放USB设备信息。
  
Thanks
+
1. 在/nova/db/sqlalchemy/migrate_repo/versions增加一个217_add_usb_devices.py(H版本version号到216,故新增文件命令以217开头)
 +
#定义升级函数,本例升级即创建一张新table
 +
def upgrade(migrate_engine):
 +
    meta = MetaData(bind=migrate_engine)
  
Hi
+
    usb_devices_uc_name = 'uniq_usb_devices0compute_node_id0address0deleted'
 +
    usb_devices = Table('usb_devices', meta,
 +
                        Column('created_at', DateTime(timezone=False)),
 +
                        ...
 +
#定义升级回退函数,本例回退即删除创建的table
 +
def downgrade(migrate_engine):
 +
    meta = MetaData(bind=migrate_engine)
  
I have a requirement of monitoring VMs, if a VM's meter like cpu_util become too high, then system generate an alarm for this VM with meter information.
+
    try:
 +
        usb_device = Table('usb_devices', meta, autoload=True)
 +
        usb_device.drop()
 +
        ...
 +
2. 执行nova-manage db sync命令,对nova DB进行升级。结果是在数据库中即可见到产生的usb_devices表
 +
3. 执行nova-manage db sync 216命令,对nova DB进行升级。结果是usb_devices表被删除
  
I have tested alarm function of ceilometer, below are commands I used to create alarm object with meter and resource id or not:
+
系统内部流程简介:
ceilometer alarm-threshold-create  --name alarm1 --meter-name cpu_util --period 60 --evaluation-periods 1 --statistic avg --comparison-operator gt --threshold 1 -q resource_id=757dadaa-0707-4fad-808d-81edc11438aa
+
(1)在DB的migrate_version中存放了nova的DB版本信息,如下所示:
ceilometer alarm-threshold-create  --name alarm1 --meter-name cpu_util --period 60 --evaluation-periods 1 --statistic avg --comparison-operator gt --threshold 1
+
mysql> select * from migrate_version;
 +
+---------------+------------------------------------------------------------------+---------+
 +
| repository_id | repository_path                                                  | version |
 +
+---------------+------------------------------------------------------------------+---------+
 +
| nova          | /usr/lib/python2.6/site-packages/nova/db/sqlalchemy/migrate_repo |    216 |
 +
+---------------+------------------------------------------------------------------+---------+
 +
1 row in set (0.00 sec)
 +
(2)执行nova-manage db sync命令,调用/nova/db/sqlalchemy/migration.py的db_sync函数
 +
        此函数检查当前版本号和API传入的版本号,如果API不指定版本号(见上面例子)、或者指定的版本号大于当前版本号,则进入升级流程,否则进入降级流程
 +
(3)最终进入migrate/versioning/api.py的_migrate函数
 +
        此函数检查是否有变更点,如果没有变更点则结束流程,如果有变更点(例如上例新增加了217_xx),则执行变更(即执行217_add_usb_devices.py中的upgrade函数),产生新DB
  
I have the following question:
+
相关参考:
If I have to define alarm object for every VM and every meter?
+
http://blog.csdn.net/tpiperatgod/article/details/17560005
Take 100 VM and 2 meter cpu_util, memory_util as an example, I will have to define 100*2 alarm objects for them.  
+
http://www.sqlalchemy.org/
I think if I just define alarm object with meter not but VM(resource_id), then alarm evaluator will count all VM's meter.
+
http://www.cnblogs.com/willier/archive/2013/05/16/3081475.html
 
+
http://www.ustack.com/blog/sqlalchemy-migrate-and-alembic/
Another question produced by question above: I know that alarm evaluator will process alarm object one by one, so too many alarm object may result in performance problems too.
 
 
 
I am not a ceilometer programmer and I apologize if I am missing something very obvious.
 
Can you give me some help to make me clear about them and how to implement my requirement?
 
 
 
Thanks
 

Revision as of 10:47, 15 April 2014

sqlalchemy和sqlalchemy-migrate在openstack的应用介绍

sqlalchemy 简介: 提供ORM(对象关系映射)能力的python库,类似hibernate技术,支持postgresql、mysql等主流关系数据;用户只需定义DB对应的类,通过操作类实例,即可通过sqlalchemy引擎转换成标准sql语句,对DB进行操作

Openstack中的应用: openstack各项目涉及关系数据库的DB driver,基本都是使用sqlalchemy库。 table对应class定义:\nova\db\sqlalchemy\models.py中,例如class Instance(BASE, NovaBase) db操作API:\nova\db\sqlalchemy\api.py,调用sqlalchemy相关库函数操作DB,数据实体使用models.py定义的class

sqlalchemy-migrate 简介: 基于sqlalchemy库,提供数据库版本管控能力的python库。

Openstack中的应用: 版本升级能力是openstack当前能力较缺失的一块,但是从DB升级的角度看,由于引入了sqlalchemy-migrate框架,openstack各项目比较容易管理DB的变化,例如新增加一张table,新增加一个字段等。 sqlalchemy-migrate在2011年发布了0.7.2版本后,就已经停止更新了,也不接受bugfix。因此openstack考虑引入Alembic(同样由sqlalchemy-migrate的开发者)替代sqlalchemy-migrate sqlalchemy-migrate提供upgrade(升级)、downgrade(降级)、db_version(查看最新版本)等接口

应用举例: 在H版本代码基础上nova项目提供USB设备管理能力,故在DB Layper需增加一张table存放USB设备信息。

1. 在/nova/db/sqlalchemy/migrate_repo/versions增加一个217_add_usb_devices.py(H版本version号到216,故新增文件命令以217开头)

  1. 定义升级函数,本例升级即创建一张新table

def upgrade(migrate_engine):

   meta = MetaData(bind=migrate_engine)
   usb_devices_uc_name = 'uniq_usb_devices0compute_node_id0address0deleted'
   usb_devices = Table('usb_devices', meta,
                       Column('created_at', DateTime(timezone=False)),
                       ...
  1. 定义升级回退函数,本例回退即删除创建的table

def downgrade(migrate_engine):

   meta = MetaData(bind=migrate_engine)
   try:
       usb_device = Table('usb_devices', meta, autoload=True)
       usb_device.drop()
       ...

2. 执行nova-manage db sync命令,对nova DB进行升级。结果是在数据库中即可见到产生的usb_devices表 3. 执行nova-manage db sync 216命令,对nova DB进行升级。结果是usb_devices表被删除

系统内部流程简介: (1)在DB的migrate_version中存放了nova的DB版本信息,如下所示: mysql> select * from migrate_version; +---------------+------------------------------------------------------------------+---------+ | repository_id | repository_path | version | +---------------+------------------------------------------------------------------+---------+ | nova | /usr/lib/python2.6/site-packages/nova/db/sqlalchemy/migrate_repo | 216 | +---------------+------------------------------------------------------------------+---------+ 1 row in set (0.00 sec) (2)执行nova-manage db sync命令,调用/nova/db/sqlalchemy/migration.py的db_sync函数

        此函数检查当前版本号和API传入的版本号,如果API不指定版本号(见上面例子)、或者指定的版本号大于当前版本号,则进入升级流程,否则进入降级流程

(3)最终进入migrate/versioning/api.py的_migrate函数

        此函数检查是否有变更点,如果没有变更点则结束流程,如果有变更点(例如上例新增加了217_xx),则执行变更(即执行217_add_usb_devices.py中的upgrade函数),产生新DB

相关参考: http://blog.csdn.net/tpiperatgod/article/details/17560005 http://www.sqlalchemy.org/ http://www.cnblogs.com/willier/archive/2013/05/16/3081475.html http://www.ustack.com/blog/sqlalchemy-migrate-and-alembic/