深入研究Openstack Nova組件對象模型以及數據庫訪問機制
1. 背景
介紹在Openstack G版以前，Nova的所有服務(包括nova-compute服務)都是直接訪問數據庫的，數據庫訪問接口在nova/db/api.py模塊中實現，而該模塊只是調用了IMPL的方法，即該模塊只是一個代理，真正實現由IMPL實現，IMPL是一個可配置的動態加載驅動模塊，通常使用Python sqlalchemy庫實現，對應的代碼為nova.db.sqlalchemy.api：
- _BACKEND_MAPPING = {'sqlalchemy': 'nova.db.sqlalchemy.api'}
該模塊不僅實現了model的CRUD操作，還封裝了一些高級API，比如:
- instance_get_all: 獲取所有虛擬機實例。
- instance_update: 更新虛擬機熟悉。
- …
這種直接訪問數據庫的設計至少存在以下兩個問題：
- 所有服務與數據模型耦合，當數據模型變更時，可能需要涉及所有代碼的調整，并難以支持版本控制。
- 所有的主機都能訪問數據庫，大大增加了數據庫的暴露風險。
為了實現Nova服務與數據庫訪問解耦，從G版本開始引入了nova-conductor服務，該服務的一個重要作用就是訪問數據庫，其它服務訪問數據庫時需要向nova-conductor發起RPC請求，由nova-conductor代理請求數據庫。
以上方式基本解決了服務與數據庫訪問解耦，并且防止其它服務直接訪問數據庫，但仍然沒有解決對象模型的版本控制。從I版本開始引入了對象模型的概念，所有的對象模型定義在nova/objects。在此之前訪問數據庫是直接調用數據庫的model的，比如更新一個flavor一個字段，調用Flavor的update方法(由sqlalchemy)實現。引入對象模型后，相當于在服務與數據庫之間又添加了一級對象層，各個服務直接和資源對象交互，資源對象再和數據庫接口交互，數據庫返回時也會相應的轉化為對象模型中的對象。
對象模型的對象不僅封裝了數據庫訪問，還支持了版本控制。每個對象都會維護一個版本號，發起RPC請求時必須指定對象的版本號。新版本的對象通常能夠兼容舊版本對象，比如nova-conductor升級了使用對象模型版本為1.2，但nova-compute服務可能還沒有升級完成，仍然使用的是1.1版本，此時請求返回時會把conductor的返回的對象轉化為1.1版本兼容的對象。
目前Cinder服務還是直接訪問數據庫，目前已經在社區有對應的BP關于增加cinder-conductor服務Create conductor service for cinder like nova-conductor, 該BP于2013年6月提出，到當前最新版本N還尚未實現。
2. Nova配置
以上我們介紹了nova-conductor以及對象模型的背景，我們了解到所有服務訪問數據庫都必須通過RPC調用nova-conductor服務請求，但這并不是強制的，如果不考慮數據庫訪問安全，你仍然可以使用本地訪問方式，nova-compute服務可以直接訪問數據庫而不發起nova-conductor RPC調用。我們看nova-compute服務的初始化，它位于nova/cmd/compute.y：
- def main():
- # ...
- if not CONF.conductor.use_local:
- cmd_common.block_db_access('nova-compute')
- objects_base.NovaObject.indirection_api = \
- conductor_rpcapi.ConductorAPI()
- else:
- LOG.warning(_LW('Conductor local mode is deprecated and will '
- 'be removed in a subsequent release'))
- # ...
因此在/etc/nova.conf配置文件中可以配置是否直接訪問數據庫。以上indirection_api是Nova對象模型的一個字段，初始化為None。
如果設置use_local為true，則indirection_api為None，否則將初始化為conductor_rpcapi.ConductorAPI，從這里我們也可以看出調用conductor的入口。
我們可能會想到說在對象模型訪問數據庫時會有一堆if-else來判斷是否使用use_local，事實上是否這樣呢，我們接下來將分析源碼，從而理解Openstack的設計理念。
3. 源碼分析
3.1 nova-compute源碼分析
本小節主要以刪除虛擬機為例，分析nova-compute在刪除虛擬機時如何操作數據庫的。刪除虛擬機的API入口為nova/compute/manager.py的_delete_instance方法，方法原型為:
- _delete_instance(self, context, instance, bdms, quotas)
該方法有4個參數，context是上下文信息，包含用戶、租戶等信息，instance就是我們上面提到的對象模型中Instance對象實例，bdms是blockDeviceMappingList對象實例，保存著block設備映射列表，quotas是nova.objects.quotas.Quotas對象實例，保存該租戶的quota信息。
該方法涉及的數據庫操作代碼為:
- instance.vm_state = vm_states.DELETED
- instance.task_state = None
- instance.power_state = power_state.NOSTATE
- instance.terminated_at = timeutils.utcnow()
- instance.save()
- system_meta = instance.system_metadata
- instance.destroy()
從代碼中可以看到，首先更新instance的幾個字段，然后調用save()方法保存到數據庫中，最后調用destroy方法刪除該實例(注意，這里的刪除并不一定是真的從數據庫中刪除記錄，也有可能僅僅做個刪除的標識)。
我們先找到以上的save()方法，它位于nova/object/instance.py模塊中，方法原型為:
- @base.remotable
- save(self, expected_vm_state=None,
- expected_task_state=None, admin_state_reset=False)
save方法會記錄需要更新的字段，并調用db接口保存到數據庫中。關鍵是該方法的wrapper remotable，這個注解(python不叫注解，不過為了習慣這里就叫注解吧)非常重要，該方法在oslo中定義:
- def remotable(fn):
- """Decorator for remotable object methods."""
- @six.wraps(fn)
- def wrapper(self, *args, **kwargs):
- ctxt = self._context
- if ctxt is None:
- raise exception.OrphanedObjectError(method=fn.__name__,
- objtype=self.obj_name())
- if self.indirection_api:
- updates, result = self.indirection_api.object_action(
- ctxt, self, fn.__name__, args, kwargs)
- for key, value in six.iteritems(updates):
- if key in self.fields:
- field = self.fields[key]
- # NOTE(ndipanov): Since VersionedObjectSerializer will have
- # deserialized any object fields into objects already,
- # we do not try to deserialize them again here.
- if isinstance(value, VersionedObject):
- setattr(self, key, value)
- else:
- setattr(self, key,
- field.from_primitive(self, key, value))
- self.obj_reset_changes()
- self._changed_fields = set(updates.get('obj_what_changed', []))
- return result
- else:
- return fn(self, *args, **kwargs)
- wrapper.remotable = True
- wrapper.original_fn = fn
- return wrapper
從代碼看到，當indirection_api不為None時會調用indirection_api的object_action方法，由前面我們知道這個值由配置項use_local決定，當use_local為False時indirection_api為conductor_rpcapi.ConductorAPI。從這里了解到對象并不是通過一堆if-else來判斷是否使用use_local的，而是通過@remotable注解實現的，remotable封裝了if-else，當使用local時直接調用原來對象實例的save方法，否則調用indirection_api的object_action方法。
注意: 除了@remotable注解，還定義了@remotable_classmethod注解，該注解功能和@remotable類似，僅僅相當于又封裝了個@classmethod注解。
3.2 RPC調用
前面我們分析到調用conductor_rpcapi.ConductorAPI的object_action方法，該方法在nova/conductor/rpcapi.py中定義：
- def object_action(self, context, objinst, objmethod, args, kwargs):
- cctxt = self.client.prepare()
- return cctxt.call(context, 'object_action', objinst=objinst,
- objmethod=objmethod, args=args, kwargs=kwargs)
rpcapi.py封裝了client端的所有RPC調用方法，從代碼上看，發起了RPC server端的object_action同步調用。此時nova-compute工作順利轉接到nova-conductor，并堵塞等待nova-conducor返回。
3.3 nova-conductor源碼分析
nova-conductor RPC server端接收到RPC請求后調用manager.py的object_action方法(nova/conductor/manager.py):
- def object_action(self, context, objinst, objmethod, args, kwargs):
- """Perform an action on an object."""
- oldobj = objinst.obj_clone()
- result = self._object_dispatch(objinst, objmethod, args, kwargs)
- updates = dict()
- # NOTE(danms): Diff the object with the one passed to us and
- # generate a list of changes to forward back
- for name, field in objinst.fields.items():
- if not objinst.obj_attr_is_set(name):
- # Avoid demand-loading anything
- continue
- if (not oldobj.obj_attr_is_set(name) or
- getattr(oldobj, name) != getattr(objinst, name)):
- updates[name] = field.to_primitive(objinst, name,
- getattr(objinst, name))
- # This is safe since a field named this would conflict with the
- # method anyway
- updates['obj_what_changed'] = objinst.obj_what_changed()
- return updates, result
該方法首先調用obj_clone()方法備份原來的對象，主要為了后續統計哪些字段更新了。然后調用了_object_dispatch方法:
- def _object_dispatch(self, target, method, args, kwargs):
- try:
- return getattr(target, method)(*args, **kwargs)
- except Exception:
- raise messaging.ExpectedException()
該方法利用反射機制通過方法名調用，這里我們的方法名為save方法，因此顯然調用了target.save()方法，即最終還是調用的instance.save()方法，不過此時已經是在conductor端調用了.
又回到了nova/objects/instance.py的save方法，有人會說難道這不會無限遞歸RPC調用嗎?顯然不會，這是因為nova-conductor的indirection_api為None，在@remotable中肯定走else分支。
4. 思考一個問題
還記得在_delete_instance方法的數據庫調用代碼嗎?這里再貼下代碼:
- instance.vm_state = vm_states.DELETED
- instance.task_state = None
- instance.power_state = power_state.NOSTATE
- instance.terminated_at = timeutils.utcnow()
- instance.save()
- system_meta = instance.system_metadata
- instance.destroy()
有人會說instance記錄都要刪了，直接調用destory方法不得了，前面一堆更新字段然后save方法是干什么的。這是因為Nova在處理刪除記錄時使用的是軟刪除策略，即不會真正得把記錄徹底刪除，而是在記錄中有個deleted字段標記是否已經被刪除。這樣的好處是方便以后審計甚至數據恢復。
5. 總結
本文首先介紹了Openstack Nova組件數據庫訪問的發展歷程，然后基于源碼分析了當前Nova訪問數據庫的過程，最后解釋了Nova使用軟刪除的原因。
