中国领先的IT技术网站
|
|
创建专栏

Openstack虚拟机防止误删除操作的几种实现方法

虚拟机是Openstack中最重要的角色之一,我们接触比较多的Nova服务就是通过虚拟机方式提供计算虚拟化服务。

作者:付广平|2017-06-02 10:42

沙龙活动 | 去哪儿、陌陌、ThoughtWorks在自动化运维中的实践!10.28不见不散!


1.虚拟机保护的重要性

虚拟机是Openstack中最重要的角色之一,我们接触比较多的Nova服务就是通过虚拟机方式提供计算虚拟化服务。除此之外,还有很多高层服务也是完全依赖于Nova服务提供的虚拟机,比如Sahara大数据服务、Magnum容器编排服务、Manila文件共享服务以及Trove数据库服务等,这些服务底层都是基于虚拟机实现的。虚拟机的保护至关重要,不仅承载着用户活动的业务,还保存着用户的重要数据。虚拟机意外丢失不仅可能导致用户业务中止,还可能导致重要数据的丢失,甚至造成重大生产事故,虚拟机的保护不容忽视!

Openstack Nova服务相对来说比较成熟了,虚拟机通常不会出现突然消失的情况,排除天灾,剩下的就是人祸了,最危险的莫过于误删除操作,危险等级不亚于以下几种:

  1. rm -rf / 
  2. ceph osd pool delete rbd rbd --yes-i-really-really-mean-it 
  3. drop database nova; 

不幸的是,Openstack一直没有一套完善的虚拟机保护机制,默认的权限策略也存在一定的问题:

  • admin是全局的,只要属于admin组,就能够操作所有租户的资源,删除所有虚拟机只需一个命令。
  • 虚拟机的Lock感觉形同虚设,admin完全无视任何锁。

当然尽管不完善,Openstack针对虚拟机的保护措施还是做了一些工作的,本文接下来将逐一介绍。

2.Lock机制

Openstack很早就开始支持对虚拟机加锁操作:

  1. usage: nova lock <server> 
  2. Lock a server. A normal (non-admin) user will not be able to execute actions 
  3. on a locked server. 

被locked的虚拟机不允许非管理员执行任何操作,包括delete、reboot、resize、rebuild、migrate等等。但是到目前为止也没有实现通过API获取虚拟机的锁状态,换句话说,只有当你执行以上操作时,才会莫名其妙地告诉你执行失败了,因为虚拟机被加锁了:

  1. $ nova delete 5a7b14b0-a47c-47be-98bb-92e139d16b00 
  2. Instance 5a7b14b0-a47c-47be-98bb-92e139d16b00 is locked (HTTP 409) (Request-ID: req-6366a53b-d696-47cc-8111-1a760b8d0253) 
  3. ERROR (CommandError): Unable to delete the specified server(s). 

2014年2月就已经有人提关于查看虚拟机lock状态API实现BP:get-lock-status-of-instance,目前已被标记为Slow progress。

需要注意的是,正如前面所言,管理员账号是无视锁的,检查锁的代码非常简单:

  1. def check_instance_lock(function): 
  2.     @functools.wraps(function
  3.     def inner(self, context, instance, *args, **kwargs): 
  4.         if instance.locked and not context.is_admin: 
  5.             raise exception.InstanceIsLocked(instance_uuid=instance.uuid) 
  6.         return function(self, context, instance, *args, **kwargs) 
  7.     return inner 

我们为了强化锁的作用,直接把if后面的and not context.is_admin去掉了,这样即使是管理员在确认需要删除虚拟机时也必须先unlock,一定程度上提高了虚拟机的安全性。

注意: 锁定的虚拟机即使执行nova force-delete也会失败。

3.soft-delete

微信聊天时如果不小心说错话了,两分钟内可以立马撤回消息,并不明觉厉地向对方扔一个对方撤回了一条消息。不小心误删虚拟机时,你是否也会在心里想如果可以撤回刚刚的操作该多好!

值得庆幸的是,Openstack原生支持软删除操作。开启了软删除功能后,删除的虚拟机不会立刻清除,而是会保留一段时间(比如一天),在虚拟机保留期内你可以随时restore恢复。

开启办法是修改Nova配置文件/etc/nova/nova.conf,在DEFAULT配置组下设置reclaim_instance_interval值,该值表示删除虚拟机后保留的时间,单位为秒。

我们简单验证下:

我们首先创建了一个虚拟机,uuid为c6fd7a92-bf51-4000-b9e1-18850090ab47:

  1. $ nova list | grep c6fd7a92-bf51-4000-b9e1-18850090ab47 
  2. | c6fd7a92-bf51-4000-b9e1-18850090ab47 | int32bit-test-3 | ACTIVE | - | Running | rally-shared-net=10.168.0.18 | 

然后执行删除操作:

  1. nova delete c6fd7a92-bf51-4000-b9e1-18850090ab47 

查看虚拟机状态,注意--deleted选项,否则看不到已经删除的虚拟机:

  1. $ nova list --deleted | grep c6fd7a92-bf51-4000-b9e1-18850090ab47 
  2. | c6fd7a92-bf51-4000-b9e1-18850090ab47 | int32bit-test-3| SOFT_DELETED | - |Shutdown| rally-shared-net=10.168.0.18| 

可见虚拟机此时为SOFT_DELETED状态,此时我们可以使用nova restore操作恢复:

  1. nova restore c6fd7a92-bf51-4000-b9e1-18850090ab47 

再次使用nova list可发现虚拟机已经回来了。

软删除的代码实现也相对简单,直接上核心代码(nova/compute/manager.py:

  1. def soft_delete_instance(self, context, instance, reservations): 
  2.         # ... 
  3.         try: 
  4.             self._notify_about_instance_usage(context, instance, 
  5.                                               "soft_delete.start"
  6.             try: 
  7.                 self.driver.soft_delete(instance) 
  8.             except NotImplementedError: 
  9.                 self.driver.power_off(instance) 
  10.             instance.power_state = self._get_power_state(context, instance) 
  11.             instance.vm_state = vm_states.SOFT_DELETED 
  12.             instance.task_state = None 
  13.             instance.save(expected_task_state=[task_states.SOFT_DELETING]) 
  14.         except Exception: 
  15.             with excutils.save_and_reraise_exception(): 
  16.                 quotas.rollback() 
  17.         quotas.commit() 

从代码发现会调用driver的soft_delete方法,但实际上libvirt driver并未实现该方法,因此会fallback到except语句,即执行简单关机操作,然后更新虚拟机状态到数据库即完成软删除操作。

因此,虚拟机的软删除操作原理就是关机虚拟机并标记为软删除。

需要注意的是: nova force-delete会立即强制删除虚拟机,不会保留虚拟机,请小心操作。

4.禁止删除

这个应该算是Nova的隐藏功能了,不阅读源码真的不知道,虚拟机有一个disable_terminate标记,具有该标记的虚拟机无法通过任何API删除虚拟机,无论你是admin还是force-delete都会删除失败,对于非常重要的虚拟机,万万不能删除的虚拟机,可以设置该标记。

不过目前并没有API设置该标记,社区提了好几个与之相关的BP:

目前只能靠操作数据库查看和设置该标记了。

  1. update instances set disable_terminate=1 where uuid='a80d78c0-9f5f-4f01-8ace-72a5133a4763'

此时执行删除虚拟机操作不会有任何反应。

实现方式非常简单,在nova/compute.api.py,只要设置了该标记,直接return:

  1. def _delete(self, context, instance, delete_type, cb, **instance_attrs): 
  2.         if instance.disable_terminate: 
  3.             LOG.info(_LI('instance termination disabled'), 
  4.                      instance=instance) 
  5.             return 
  6.         # ... 

5. 快照备份

以上都是通过删除保护方式来保证虚拟机的安全性,为了更全面地保护虚拟机,快照备份也是保护虚拟机的有效途径,可参考的方式如下:

  1. 使用nova image-create创建虚拟机快照。
  2. 使用nova backup定期快照备份。
  3. 如果使用Ceph做后端存储,可以考虑使用rbd mirror。
  4. 挂载的volume可以使用cinder backup服务增量备份。

6.总结

虽然Openstack提供的虚拟机保护措施还不够完善,但做的工作还是不少的,用户可以根据自己的需求选择适合自己的方案。

【本文是51CTO专栏作者“付广平”的原创文章,如需转载请通过51CTO获得联系】

戳这里,看该作者更多好文

【编辑推荐】

  1. 张涵诚:大数据操作系统遐想
  2. 盘点Openstack那些顽固bug
  3. 深入理解Openstack QoS控制实现与实践
  4. 学习Java虚拟机没用? 听听当事人是怎么说的!
  5. 【廉环话】安全入侵应对实务——操作系统篇
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

热门职位+更多

× Python最火的编程语言