在上一篇文章中，我們和您一起了解了 vRouter的內部結構和程式，今天繼續Tungsten Fabric其它元件的內部探秘旅程。

作者：Tatsuya Naganawa 譯者：TF編譯組

- control內部 -

IFMAP-SERVER棄用

在R4.0之後，不建議使用ifmap-server，當前控制節點直接從cassandra接收配置資訊。

話雖如此，但是在內部，它仍然使用ifmap結構來儲存vrf、interface、logical-router等的拓撲資料。

為了直接從cassandra中拾取資料，對ifmap客戶端進行了一些更改，這些更改由control使用。

最初，ifmap客戶端包含很多邏輯來從ifmap-server提取資料，但是目前它僅包含一種邏輯，從cassandra獲取json檔案，並用該資料填充ifmap結構。

因此，它現在將ifmap用作內部使用的結構，而不是用作一個wire協議。

NAMED和DNS的區別

contrail-dns和contrail-named是不同的程式，實際上有著不同的用途。
contrail-dns具有與contrail-control類似的功能，它透過XMPP提供vDNS資訊，vRouter將基於該輸入執行一些DNS任務。

contrail-named實際上並不使用XMPP，而是使用ISC繫結來提供DNS資料，用於對vDNS條目進行外部DNS查詢。

- config內部 -

CRUD操作REST API和MSGBUS更新

Config-api將提供REST API，以實現每個配置物件的CRUD操作，例如virtual-network、network-policy等。

為此，它基於架構（schema）檔案動態建立URL。

_generate_resource_crud_methods和_generate_resource_crud_uri建立通用方法和URL

這種方法的預設行為是執行Cassandra更新，並且Rabbitmq交換也填充了一些資訊，以供其它程式使用，例如schema-transformer、svc-monitor、device-manager。

def dbe_create(self, obj_type, obj_uuid, obj_dict):
        (ok, result) = self._object_db.object_create(obj_type, obj_uuid,
                                                     obj_dict)
        if ok:
            # publish to msgbus
            self._msgbus.dbe_publish('CREATE', obj_type, obj_uuid,
                                     obj_dict['fq_name'], obj_dict=obj_dict)
            self._dbe_publish_update_implicit(obj_type, result)
        return (ok, result)
    # end dbe_create

其它任務（例如檢查輸入資料或使用預設值填充）將由pre_dbe_create或post_dbe_create（此建立可以刪除，更新，讀取等）完成，並且按資源定義。

DEPENDENCY_TRACKER

schema-transformer、svc-monitor和device-manager使用dependency tracker來處理config-api中的amqp訊息，並遞迴地評估更新物件所引用的物件。

在內部，如果reaction_map包含amqp訊息中的物件的鍵（key），它將開始評估該物件。這裡reaction_map其實是一個已更新物件名稱的python dict，而其它物件名稱需要評估。

舉例來說，如果virtual-machine-interface已更新，

如果它具有最初更新的virtual-machine-interface引用，還將評估virtual-machine、port-tuple、virtual-network和bgp-as-a-service。

- config database內部 -

讀取CONFIG_DB_UUID鍵空間內容

當cqlsh看到Cassandra的內容時（例如cql> select * from config_db_uuid.obj_fq_name_table;），它將返回一些人類無法理解的輸出。

關鍵是config-api內部使用pycassa的ColumnFamily（

要讀取此資訊，透過backup / restore程式建立的json檔案是很方便的。

儘管該結果與config-api的HTTP GET輸出大部分相似。

TUNGSTEN FABRIC配置資料庫中 ZOOKEEPER的使用

使用Cassandra計算下一個整數並不容易，為此Tungsten Fabric使用了Zookeeper。

資料在各種Zookeeper的path中，可以使用以下命令檢視。

備份指令碼也可以用於轉儲所有Zookeeper資料。

- analytics內部 -

REDIS、CASSANDRA和KAFKA

Analytics有多個後端資料庫，最主要的是notabliy、redis和cassandra，如果安裝了alarmgen，那麼還包括kafka。

這些資料庫由collector分別更新，當vRouter之類的sandesh更新時，control就已經到達了該程式。

收到之後，，

並根據收到的sandesh資料型別執行一些任務。

如果收到的是UVE，則填充redis和kafka，如果安裝了Cassandra，還將填充此資料庫的統計表。

因此，redis和kafka將僅處理UVE，當Cassandra未安裝時，除UVE之外的所有資料都不會匯入到analytics資料庫中。

UVEUPDATE.LUA

在UVE到達collector時，collector目錄中的一些lua檔案將用於更新Redis。

在內部，它在編譯時透過xxd命令轉換為cpp檔案。

- 補充一些配置knob -

轉發模式（FORWARDING MODE）

vRouter具有幾種轉發模式。

預設情況下，它將使用L2/L3模式。L3模式和L2模式也有一些用例。

未知單播泛洪（FLOOD UNKNOWN UNICAST）

當使用L2 BMS連線時使用此knob。

預設情況下，由於控制器知道虛擬機器的所有mac地址，因此vRouter將丟棄未知的單播，儘管使用L2 BMS時並非如此。

因此，在這種情況下需要啟用此knob。

允許傳遞（ALLOW TRANISIT）

此knob與服務鏈功能一起使用。

當VM1 - VN1 - VNF1 - VN2 - VNF2 - VN3 - VM2已建立，並且VN1-VN2，VN2-VN3服務鏈已配置時，由於ServiceChain字首不可傳遞，因此預設情況下VM1無法ping通VM2。

在VN2中啟用此knob後，VN1中的字首將匯入到VN3，反之亦然，因此VM1可以ping通到VM3。

多重服務鏈（MULTIPLE SERVICE CHAIN）

我實際上從未嘗試過此knob。

此URL中描述了詳細資訊，請與TF中文社群聯絡。

Tungsten Fabric知識庫丨更多元件內部探秘