深刻理解 DeepSea 和 Salt 部署工具 - Storage6

學習 SUSE Storage 系列文章

（1）SUSE Storage6 實驗環境搭建詳細步驟 - Win10 + VMware WorkStation

（2）SUSE Linux Enterprise 15 SP1 系統安裝

（3）SUSE Ceph 快速部署 - Storage6

（4）SUSE Ceph 增長節點、減小節點、 刪除OSD磁盤等操做 - Storage6

（5）深刻理解 DeepSea 和 Salt 部署工具 - Storage6

---

 

首先咱們經過前幾篇文章，已經搭建了一套完整的Ceph集羣，對使用salt工具自動化搭建集羣有所瞭解，下面咱們就對部署方式進行詳解

SUSE Enterprise Storage 部署方式

storage4 採用的方式：

• ceph-deploy 工具，標準的ceph腳本部署，適用於中小型存儲集羣
• crowbar工具，部署SUSE Openstack的標準工具

storage5/6 採用方式：

• DeepSea (Salt)，輕量級，敏捷性，靈活性，彈性部署

     過去咱們的部署方式採用社區的方式ceph-deploy或 crowbar 工具搭建，這2種工具部署都有必定侷限性，不適合大型存儲集羣部署，敏捷性、靈活性太差。所以從2018年開始，SUSE Enterprise Storage 5 棄用 ceph-deploy / crowbar 羣集部署工具 ,推出DeepSea方式進行部署，該方式更加輕量級，高速互通，敏捷性，靈活性，適用於各類場景部署集羣系統，也是Ceph產品部署方式的趨勢。

1、DeepSea 簡介

      DeepSea 旨在節省管理員的時間，讓他們自信地對 Ceph 羣集執行復雜操做。Ceph 是一款高度可配置的軟件解決方案。它提升了系統管理員的自由度和職責履行能力。最低的 Ceph 設置可以很好地知足演示目的，但沒法展現 Ceph 在處理大量節點時可體現的卓越功能。DeepSea 會收集並儲存有關單臺服務器的相關數據，例如地址和設備名稱。對於諸如 Ceph 的分佈式儲存系統，可能須要收集並儲存數百個這樣的項目。收集信息並手動將數據輸入到配置管理工具的過程很是耗費精力，而且容易出錯。準備服務器、收集配置信息以及配置和部署 Ceph 所需執行的步驟大體相同。可是，這種作法沒法解決管理獨立功能的需求。在平常操做中，必須作到不厭其煩地將硬件添加到給定的功能，以及從容地去除硬件。DeepSea 經過如下策略解決了這些需求：DeepSea 可將管理員的多項決策合併到單個文件中。這些決策包括羣集指派、角色指派和配置文件指派。此外，DeepSea 會收集各組任務以組成一個簡單的目標。每一個目標就是一個階段：

 關於DeepSea官方資料：

GitHub 連接： https://github.com/SUSE/DeepSea/wiki

  2、SaltStack 簡介

 

SaltStack 是一個服務器基礎架構集中化管理平臺，具有配置管理、遠程執行、監控等功能，通常能夠理解爲簡化版的puppet和增強版的func。SaltStack 基於Python語言實現，結合輕量級消息隊列（ZeroMQ）與Python第三方模塊（Pyzmq、PyCrypto、Pyjinjia二、 python-msgpack和PyYAML等）構建。

經過部署SaltStack環境，咱們能夠在成千上萬臺服務器上作到批量執行命令，根據不一樣業務特性進行配置集中化管理、分發文件、採集服務器數據、操做系統基礎及軟件包管理等，SaltStack是運維人員提升工做效率、規範業務配置與操做的利器。

特性：

（1）部署簡單、方便；

（2）支持大部分UNIX/Linux及Windows環境；

（3）主從集中化管理；

（4）配置簡單、功能強大、擴展性強；

（5）主控端（master）和被控端（minion）基於證書認證，安全可靠；

（6）支持API及自定義模塊，可經過Python輕鬆擴展。

SaltStack: Pillar 和 Grains 詳解

 

SatlStack 遠程執行

 一、遠程執行

• 目標 （Targeting）
• 模塊 （Module）
• 返回 （return）

二、目標

（1）和Minion ID 有關，須要使用Minion ID

• 通配符
• 正則表達式
• 列表

通配符方式：

# salt 'node00[1-3]'.example.com cmd.run 'w'
node002.example.com:
     13:06:12 up  4:05,  0 users,  load average: 0.28, 0.09, 0.02
    USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
node001.example.com:
     13:06:12 up  4:05,  0 users,  load average: 0.23, 0.13, 0.05
    USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
node003.example.com:
     13:06:12 up  4:05,  0 users,  load average: 0.24, 0.09, 0.02
    USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT

正則表達式

# salt -E 'node(001|002).example.com' test.ping        
node002.example.com:
    True
node001.example.com:
    True

（2）和Minion ID 無關，不涉及到Minion ID

• 子網 /  IP 地址
• Grains
• Pillar
• Compound matchers (複合匹配)
• Node groups (節點組)
• Batching execution （批處理執行）

Grains 方式，OS是SUSE

# salt -G 'os:SUSE' test.ping 
node001.example.com:
    True
node002.example.com:
    True
node003.example.com:
    True
node004.example.com:
    True
admin.example.com:
    True

獲取 Pillar ，而後指定pillar方式

# salt 'admin*' pillar.items 
admin.example.com:
    ----------
    available_roles:
        - storage
        - admin
        - mon
        - mds
        - mgr

     .....

    roles:
        - master
        - admin
        - prometheus
        - grafana
    time_server:
        admin.example.com

# salt -I 'roles:grafana' test.ping             
admin.example.com:
    True

三、模塊詳解

1000+ 的模塊，目前在不斷增長中 ， saltstack模塊連接 

admin:~ # salt 'node001*' network.arp  
node001.example.com:
    ----------
    00:0c:29:33:70:2d:
        192.168.2.42
    00:0c:29:33:70:37:
        192.168.3.42
    00:0c:29:ae:44:51:
        172.200.50.39
    00:0c:29:ae:44:5b:
        192.168.2.39
    00:0c:29:d3:ba:15:
        192.168.2.41
    00:0c:29:d3:ba:1f:
        192.168.3.41
    00:0c:29:e0:5c:8c:
        192.168.2.43
    00:0c:29:e0:5c:96:
        192.168.3.43

 

admin:~ # salt 'node001*' network.interface eth1 
node001.example.com:
    |_
      ----------
      address:
          192.168.2.40
      broadcast:
          192.168.2.255
      label:
          eth1
      netmask:
          255.255.255.0

3、配置和自定義

policy.cfg 文件

/srv/pillar/ceph/proposals/policy.cfg 配置文件用於肯定單個羣集節點的角色。例如，哪一個節點充當 OSD，或哪一個節點充當監視器節點。請編輯 policy.cfg ，以反映所需的羣集設置。段落採用任意順序，但所包含行的內容將重寫前面行的內容中匹配的密鑰。

一、policy.cfg 的模板

• 能夠在 /usr/share/doc/packages/deepsea/examples/ 目錄中找到完整策略文件的多個示例。

• 通常咱們選擇基於角色定義的模板

# ll /usr/share/doc/packages/deepsea/examples/
total 12
-rw-r--r-- 1 root root 329 Aug  9 16:00 policy.cfg-generic
-rw-r--r-- 1 root root 489 Aug  9 16:00 policy.cfg-regex
-rw-r--r-- 1 root root 577 Aug  9 16:00 policy.cfg-rolebased

二、羣集指派

要包含全部受控端，請添加如下幾行：

cluster-ceph/cluster/*.sls

要將特定的受控端加入白名單，請運行如下命令：

cluster-ceph/cluster/abc.domain.sls

要將一組受控端加入白名單，可使用通配符：

cluster-ceph/cluster/mon*.sls

要將受控端加入黑名單，可將其設置爲 unassigned ：

cluster-unassigned/cluster/client*.sls 

 三、policy.cfg 示例

下面是一個基本 policy.cfg 文件的示例：

 1 vim /srv/pillar/ceph/proposals/policy.cfg 
 2 
 3 ## Cluster Assignment
 4 cluster-ceph/cluster/*.sls
 5 
 6 ## Roles
 7 # ADMIN
 8 role-master/cluster/admin*.sls
 9 role-admin/cluster/admin*.sls
10 
11 # Monitoring
12 role-prometheus/cluster/admin*.sls
13 role-grafana/cluster/admin*.sls
14 
15 # MON
16 role-mon/cluster/node00[1-3]*.sls
17 
18 # MGR (mgrs are usually colocated with mons)
19 role-mgr/cluster/node00[1-3]*.sls
20 
21 # COMMON
22 config/stack/default/global.yml
23 config/stack/default/ceph/cluster.yml
24 
25 # Storage
26 role-storage/cluster/node00*.sls
27 
28 # MDS
29 role-mds/cluster/node001*.sls
30 
31 # IGW
32 role-igw/stack/default/ceph/minions/node002*.yml
33 role-igw/cluster/node002*.sls
34 
35 # RGW
36 role-rgw/cluster/node00[3-4]*.sls

（1）第3-4行：

• 指示在 Ceph 羣集中包含全部受控端。若是您不想在 Ceph 羣集中包含某些受控端，請使用：

cluster-unassigned/cluster/*.sls
cluster-ceph/cluster/node00*.sls

• 將全部受控端標記爲未指派。
• 覆蓋與「node00*.sls」匹配的受控端，並將其指派到 Ceph 羣集。

（2）第7-9行

• 指定主機名爲admin的主機節點具備"master" 和 「admin」 角色

（3）第11-13行

• 指定要部署 Dashboard 可視化界面的節點

（4）第15-16行

• 將受控節點 node001 node002 node003 設置爲MON 節點

（5）第18-19

• 將受控節點 node001 node002 node003 設置爲 MGR 節點 ，該設置必須跟隨 MON 設置同樣

 （6）第21-23行

• 表示接受 fsid 和 public_network 等通用配置參數的默認值

 （7）第25-36行

• 受控端 「node00*」 將具備 storage  IGW RGW MDS 角色

4、DeepSea 部署方式

 經過架構圖，咱們能夠清楚的瞭解到，安裝 Storage6 時只要管理節點安裝 satl-master 和 salt-minion，其餘OSD節點安裝 salt-minion，而且全部的 minion 都指向salt-master IP地址或主機名（推薦使用public網段地址），而後執行deepsea 的4個階段命令 「salt-run state.orch ceph.stage.X」 就能夠輕鬆的搭建完成。

DeepSea階段說明

階段 0 — 準備：在此階段，將應用所有所需的更新，而且可能會重引導您的系統。

階段 1 — 發現：在此階段，經過Salt在客戶端安裝的salt minion, 將檢測羣集中的全部硬件, 並收集 Ceph 配置所需的信息。

階段 2 — 配置：您須要以特定的格式準備配置數據。（定義 salt 的pillar）

階段 3 — 部署：建立包含必要 Ceph 服務的基本 Ceph 羣集。有關必要服務的列表

階段 4 — 服務：可在此階段安裝 Ceph 的其餘功能，例如 iSCSI、RADOS 網關和CephFS。其中每一個功能都是可選的。

階段 5 — 去除階段：此階段不是必需的，在初始設置期間，一般不須要此階段。在此階段，將會去除受控端的角色以及羣集配置。若是您須要從羣集中去除某個儲存節點，則須要運行此階段.

DeepSea CLI

DeepSea 還提供了一個 CLI 工具，供用戶監視或運行階段，同時實時將執行進度可視化。支持使用如下兩種模式來可視化階段的執行進度：

• 監視模式：可視化另外一個終端會話中發出的 salt-run 命令所觸發 DeepSea 階段的執行進度。
• 獨立模式：運行 DeepSea 階段，並在該階段的構成步驟執行時提供相應的實時可視化效果。

 監控模式 Monitor Mode

   該程序監控提供一個詳細的，實時的可視化操做行爲，當在執行運行salt-run state.orch時，監控執行期間運行了什麼

# deepsea monitor

 獨立模式 Stand-alone Mode

# deepsea stage run stage-name
# salt-run state.orch ceph.stage.0
# deepsea stage run ceph.stage.0

Deepsea幫助信息

# man deepsea-monitor
NAME
deepsea-monitor - Starts the DeepSea stage execution progress monitor.
# man deepsea-stage run