Calamari的架構(gòu)圖其中紅框部分為Calamari代碼實現(xiàn)的部分，非紅框部分為非Calamari實現(xiàn)的開源框架。
在Cephserver node安裝的組件有Diamond和Salt-minion。Diamond負責收集監(jiān)控數(shù)據(jù)，它支持非常多的數(shù)據(jù)類型和metrics；每一個類型的數(shù)據(jù)都是上圖中的一個collector，它除了收集Ceph本身的狀態(tài)信息，它還可以收集關鍵的資源使用情況和性能數(shù)據(jù)，包括CPU，內(nèi)存，網(wǎng)絡，I / O負載和磁盤指標。Collector都是使用本地的命令行來收集數(shù)據(jù)，然后報告給Graphite。
Graphite不僅是一個企業(yè)級的監(jiān)控工具, 還可以實時繪圖。carbon-cache是Python實現(xiàn)的高度可擴展的事件驅(qū)動的I/O架構(gòu)的后端進程，它可以有效地跟大量的客戶端通信并且以較低的開銷處理大量的業(yè)務量。
Whisper跟RRDtool類似，提供數(shù)據(jù)庫開發(fā)庫給html' target='_blank'>應用程序來操縱和檢索存儲在特殊格式的文件數(shù)據(jù)（時間數(shù)據(jù)點數(shù)據(jù)），Whisper最基本的操作是創(chuàng)建作出新的Whisper文件，更新寫入新的數(shù)據(jù)點到一個文件中，并獲取檢索的數(shù)據(jù)點
Graphite_web是用戶接口，用來生成圖片，用戶可以直接通過URL的方式訪問這些生成的圖片。
Calamari 使用了Saltstack讓Calamari Server和Ceph server node通信。Saltstack是一個開源的自動化運維管理工具，與Chef和Puppet功能類似。Salt-master發(fā)送指令給指定的Salt-minion來完成對Cpeh Cluster的管理工作；Salt-minion 在Ceph server node安裝后都會從master同步并安裝一個ceph.py文件，里面包含Ceph操作的API，它會調(diào)用librados或命令行來最終和Ceph Cluster通信。
calamari_rest提供Calamari REST API，詳細的接口請大家參照官方文檔。Ceph的REST API是一種低層次的接口，其中每個URL直接映射到等效的CEPH CLI；Calamari REST API提供了一個更高層次的接口，API的使用者可以習慣的使用GET/POST/PATCH方法來操作對象，而無需知道底層的Ceph的命令；它們之間的主要區(qū)別在于，Ceph的REST API的使用者需要非常了解Ceph本身，而Calamari 的REST API更貼近對Ceph資源的描述，所以更加適合給上層的應用程序調(diào)用。
cthulhu可以理解是Calamari Server的Service層，對上為API提供接口，對下調(diào)用Salt-master。
calamari_clients是一套用戶界面，Calamari Server在安裝的過程中會首先創(chuàng)建opt/calamari/webapp目錄，并且把webapp/calamari下的manager.py(django 配置)文件考進去， calamari_web的所有內(nèi)容到要放到opt/calamari/webapp下面來提供UI的訪問頁面。
calamari-web包下面的文件提供所有web相關的配置，calamari_rest和calamari_clients都要用到。在Calamari的基礎之上進行新的功能開發(fā)，主要分為如下的幾個模塊，這部分包括Rest-API部分，Cthulhu、salt客戶端的擴展。關于擴展新功能的基本步驟如下：
>> 擴展URL模塊，確定對應的響應接口參數(shù)、對應ViewSet中的響應接口。
>> 完成ViewSet中部分接口的實現(xiàn)，這部分主要涉及與cthulhu的交互，如何獲取數(shù)據(jù)信息，有些情況下還需要獲取serializer中對象的序列化操作。
>> 完成后臺rpc.py中對應類型的擴展，這部分主要是針對部分的post操作。
>> 完成cluster_monitor.py的擴展，對于提供操作的部分功能需要支持create、update、delete等操作，必須提供對應的RequestFactory。而在cluster_monitor.py中需要將對應的RequestFactory添加代碼中。
>> 完成對應RequestFactory類的編寫，這部分主要是完成命令操作的封裝。并構(gòu)建對應的請求操作。
>> salt-minion的擴展，這部分主要是針對ceph.py文件的擴展，當然也可以提供新的xxx.py文件。
接下來以PG的控制和操作為例進行說明。
1.1URL模塊擴展目前Calmamari采用Rest-API形式，采用Django的Rest-Framework框架支持，這部分在rest-api代碼目錄中。Django采用Url和代碼邏輯分離的實現(xiàn)方式，因此URL可以單獨的擴展。
在rest-api/calamari-rest/urls/v2.py中添加如下的有關PG的URL：
url(r'^cluster/(?P
url(r'^cluster/(?P
calamari_rest.views.v2.PgViewSet.as_view({'post': 'apply'}),
name='cluster-pool-pg-control'),
以上定義了兩個URL，分別是:
api/v2/cluster/xxxx/pool/x/pg
api/v2/cluster/xxxx/pool/x/pg/xx/command/xxx
以上兩個URL分別指定了PgViewSet中的接口，url的get方法對應了list接口。post接口對應的apply接口。這兩個接口就是PgViewSet中必須實現(xiàn)的。
1.2ViewSet的擴展在擴展URL之后，接下來就是進行對應響應接口的擴展，這部分的擴展主要是針對在URL中指定的接口類進行實現(xiàn)。在之前的PG指定了兩個不同的接口，分別是獲取和操作命令，對應的代碼路徑為/rest-api/calamari-rest/view/v2.py,具體的代碼如下：
class PgViewSet(RPCViewSet):
serializer_class= PgSerializer
deflist(self, request, fsid, pool_id):
poolName = self.client.get(fsid, POOL, int(pool_id))['pool_name']
pg_summary = self.client.get_sync_object(fsid, PgSummary.str)
pg_pools = pg_summary['pg_pools']['by_pool'][int(pool_id)]
forpg in pg_pools:
pg['pool'] = poolName
return Response(PgSerializer(pg_pools, many=True).data)
defapply(self, request, fsid, pool_id, pg_id, command):
return Response(self.client.apply(fsid, PG, pg_id, command), status=202)
從如上的實現(xiàn)可知，代碼實現(xiàn)了兩個接口，分別是list和apply接口，即對應與之前的get、post操作。以上兩個操作都會與后臺cthulhu進行交互。分別是獲取參數(shù)和提交請求。返回內(nèi)容也有一定的差異。
同時在list接口中進行了序列化設置，即PgSerializer，該實現(xiàn)在rest-api/calamari-rest/serializer/v2.py中。
1.2.1 序列化操作通常在Rest-Api中會進行數(shù)據(jù)的序列化，這部分并不是一定要進行的，通常在需要更改的操作中是有必要的。如下是Pg的序列化操作：
class PgSerializer(serializers.Serializer):
classMeta:
fields = ('id', 'pool', 'state', 'up', 'acting', 'up_primary','acting_primary')
id =serializers.CharField(source='pgid')
pool =serializers.CharField(help_text='pool name')
state =serializers.CharField(source='state', help_text='pg state')
up =serializers.Field(help_text='pg Up set')
acting =serializers.Field(help_text='pg acting set')
up_primary = serializers.IntegerField(help_text='pg up primary')
acting_primary =serializers.IntegerField(help_text='pg acting primary')
這部分并不是必須的。有些模塊可能不存在這部分的操作。在之前的三個步驟中基本上就實現(xiàn)了Rest-API部分的擴展，其中主要的ViewSet的擴展。有關ViewSet實際上實現(xiàn)了cthulhu與rest-api的交互方法。
在ViewSet的擴展中實際上采用了rpc與后臺交互，因此在cthulhu的實現(xiàn)部分主要是處理對應的rpc請求。
1.3rpc擴展rpc.py中實現(xiàn)了所有請求的操作，但是新擴展的操作也是需要支持擴展的，以pg為例繼續(xù)說明：
defapply(self, fs_id, object_type, object_id, command):
"""
Apply commands that do not modify an object in a cluster.
"""
cluster = self._fs_resolve(fs_id)
ifobject_type == OSD:
# Run a resolve to throw exception if it's unknown
self._osd_resolve(cluster, object_id)
return cluster.request_apply(OSD, object_id, command)
elifobject_type == PG:
return cluster.request_apply(PG,object_id, command)
else:
raise NotImplementedError(object_type)
而Pg的列表是通過PgSummary獲取。這部分在之前的實現(xiàn)中已存在，之前的代碼實現(xiàn)如下:
defget_sync_object(self, fs_id, object_type, path=None):
"""
Getone of the objects that ClusterMonitor keeps a copy of from the mon, such
asthe cluster maps.
:param fs_id: The fsid of a cluster
:param object_type: String, one of SYNC_OBJECT_TYPES
:param path: List, optional, a path within the object to return insteadof the whole thing
:return: the requested data, or None if it was not found (including ifany element of ``path``
was not found)
"""
ifpath:
obj =self._fs_resolve(fs_id).get_sync_object(SYNC_OBJECT_STR_TYPE[object_type])
try:
for part in path:
if isinstance(obj, dict):
obj = obj[part]
else:
obj = getattr(obj, part)
except (AttributeError, KeyError) as e:
log.exception("Exception %s traversing %s: obj=%s" % (e, path,obj))
raise NotFound(object_type, path)
return obj
else:
returnself._fs_resolve(fs_id).get_sync_object_data(SYNC_OBJECT_STR_TYPE[object_type])
1.4cluster_monitor.py擴展有關請求的操作都會進行集群的控制，這部分可以通過cluster_monitor進行實現(xiàn)，以pg為例進行說明。
def__init__(self, fsid, cluster_name, notifier, persister, servers, eventer,requests):
super(ClusterMonitor, self).__init__()
self.fsid = fsid
self.name = cluster_name
self.update_time = datetime.datetime.utcnow().replace(tzinfo=utc)
self._notifier = notifier
self._persister= persister
self._servers = servers
self._eventer = eventer
self._requests = requests
#Which mon we are currently using for running requests,
#identified by minion ID
self._favorite_mon = None
self._last_heartbeat = {}
self._complete = gevent.event.Event()
self.done = gevent.event.Event()
self._sync_objects = SyncObjects(self.name)
self._request_factories = {
CRUSH_MAP: CrushRequestFactory,
CRUSH_NODE: CrushNodeRequestFactory,
OSD: OsdRequestFactory,
POOL: PoolRequestFactory,
CACHETIER: CacheTierRequestFactory,
PG: PgRequestFactory,
ERASURE_PROFILE: ErasureProfileRequestFactory,
ASYNC_COMMAND: AsyncComRequestFactory
}
self._plugin_monitor = PluginMonitor(servers)
self._ready = gevent.event.Event()
這部分主要是將對應的請求與對應的請求工廠類進行綁定，這樣才能產(chǎn)生出合適的請求。
1.5工廠類編寫該工廠類主要是針對不同的需求，實現(xiàn)具體的接口類，不同的對象有不同的請求類，以Pg為例說明:
from cthulhu.manager.request_factory importRequestFactory
from cthulhu.manager.user_request importRadosRequest
from calamari_common.types importPG_IMPLEMENTED_COMMANDS, PgSummary
class PgRequestFactory(RequestFactory):
def scrub(self,pg_id):
return RadosRequest(
"Initiating scrub on{cluster_name}-pg{id}".format(cluster_name=self._cluster_monitor.name,id=pg_id),
self._cluster_monitor.fsid,
self._cluster_monitor.name,
[('pg scrub', {'pgid': pg_id})])
defdeep_scrub(self, pg_id):
return RadosRequest(
"Initiating deep-scrub on{cluster_name}-osd.{id}".format(cluster_name=self._cluster_monitor.name,id=pg_id),
self._cluster_monitor.fsid,
self._cluster_monitor.name,
[('pg deep-scrub', {'pgid': pg_id})])
defrepair(self, pg_id):
return RadosRequest(
"Initiating repair on{cluster_name}-osd.{id}".format(cluster_name=self._cluster_monitor.name,id=pg_id),
self._cluster_monitor.fsid,
self._cluster_monitor.name,
[('pg repair', {'pgid': pg_id})])
defget_valid_commands(self, pg_id):
ret_val = {}
file('/tmp/pgsummary.txt', 'a+').write(PgSummary.str + '/n')
pg_summary = self._cluster_monitor.get_sync_object(PgSummary)
pg_pools = pg_summary['pg_pools']['by_pool']
pool_id = int(pg_id.split('.')[0])
pool= pg_pools[pool_id]
forpg in pool:
if pg['pgid'] == pg_id:
ret_val[pg_id] = {'valid_commands': PG_IMPLEMENTED_COMMANDS}
else:
ret_val[pg_id] = {'valid_commands': []}
return ret_val
該類中實現(xiàn)了三個不同的命令的實現(xiàn)，該命令主要是進行對應的封裝，這部分關鍵字需要根據(jù)ceph源碼中的參數(shù)進行選擇，因此在編碼時需要參照ceph源碼中對應命令的json參數(shù)名。
1.6salt-minion的擴展這部分是salt的擴展模塊，主要用于獲取對應的數(shù)據(jù)信息，執(zhí)行對應的操作命令等。在cthulhu中通過salt執(zhí)行對應的操作命令。Ceph.py中有rados.commands等接口，該接口可用于執(zhí)行ceph的命令。工廠類中封裝的命令最終都會通過該接口執(zhí)行。http://www.bkjia.com/PHPjc/1092984.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/1092984.htmlTechArticleceph管理平臺Calamari的擴展開發(fā) 接近大半年沒有寫日志了，也許是自己越來越懶惰吧。但有時候?qū)憣憱|西能夠讓自己沉淀，還是回來記錄一下...
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
新聞熱點
疑難解答
