繼研究了Neutron之後，繼續Nova的外圍研究之旅。本站是研究塊存儲服務Cinder。
0。驗證環境
環境包括：
1、一個controller節點，運作nova-api, nova-scheduler, cinder-api, cinder-scheduler, mysql, rabbitmq
2、一個Nova compute節點，運作一個虛機
3、三個cinder volume節點，每個節點使用LVMISCSIDriver來使用本地存儲
4. 建立一個volume type，設定 volume_backend_name = lvmbackend
cinder.conf 在 block1上
enabled_backends = lvmdriver-b1
[lvmdriver-b1]
volume_group = cinder-volumes
volume_driver = cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name = lvmbackend
cinder.conf 在 block2上
enabled_backends = lvmdriver-b21,lvmdriver-b22
storage_availability_zone=az1
[lvmdriver-b21]
iscsi_ip_address = 10.0.1.29
volume_group = cinder-volumes1
volume_driver = cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name = lvmbackend
[lvmdriver-b22]
volume_group = cinder-volumes2
volume_driver = cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name = lvmbackend
cinder.conf 在 block3上
enabled_backends = lvmdrier-network
[lvmdriver-network]
volume_group = system
volume_driver = cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name = lvmbackend 關于幾個小問題的說明：
- [***] 會定一個一個 backend，下面幾行是該backend 的配置。需要啟用的backend 需要添加到 enabled_backends 的值中
- volume_backend_name 會被 volume type 用到，通過 --property volume_backend_name 屬性來設定。
- 多個backends 中的 volume_backend_name 可以相同。此時 scheduler 會按照指定的排程放在在多個 backend 之内選擇一個最合适的。
- 每個 backend 都會有一個 cinder volume service instance，出現在 cinder service-list 指令的輸出中，其 Host 的格式為 <節點名稱>@<backend 值>
cinder的service如下：
[email protected]:/home/s1# cinder service-list
+------------------+---------------------------+------+---------+-------+----------------------------+-----------------+
| Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
+------------------+---------------------------+------+---------+-------+----------------------------+-----------------+
| cinder-backup | controller | nova | enabled | up | 2015-01-11T16:36:00.000000 | None |
| cinder-scheduler | controller | nova | enabled | up | 2015-01-11T16:36:01.000000 | None |
| cinder-volume | [email protected] | nova | enabled | up | 2015-01-11T16:36:08.000000 | None |
| cinder-volume | [email protected] | az1 | enabled | up | 2015-01-11T16:36:06.000000 | None |
| cinder-volume | [email protected] | az1 | enabled | up | 2015-01-11T16:36:05.000000 | None |
| cinder-volume | [email protected] | nova | enabled | up | 2015-01-11T16:36:02.000000 | None |
+------------------+---------------------------+------+---------+-------+----------------------------+-----------------+ 說明:
- Cinder為每一個backend運作一個cinder-volume服務
- 通過在cinder.conf中設定 storage_availability_zone=az1 可以指定cinder-volume host的Zone。使用者建立volume的時候可以選擇AZ，配合cinder-scheduler的AvailabilityZoneFilter可以将volume建立到指定的AZ中。 預設的情況下Zone為nova。
- 通過在cinder.conf中的backend配置部分設定 iscsi_ip_address = 10.0.1.29 可以指定iSCSI session使用的網卡，進而做到資料網絡和管理網絡的分離。
- 搭以上多節點環境，一定要注意各節點之間使用NTP進行時間同步，否則可能出現cinder-volume沒有任何錯誤，但是其狀态為down的情況。
1、關于OpenStack塊存儲
1.1 OpenStack中的存儲
1.2 虛機對塊存儲的要求
1.3 Cinder概述
1.4 Cinder的内部架構
- 三個主要組成部分
- –cinder-api 元件負責向外提供Cinder REST API
- –cinder-scheduler 元件負責配置設定存儲資源
- –cinder-volume 元件負責封裝driver，不同的driver負責控制不同的後端存儲
- 元件之間的RPC靠消息隊列（Queue）實作
- Cinder的開發工作主要集中在scheduler和driver，以便提供更多的排程算法、更多的功能、以及指出更多的後端存儲
- Volume中繼資料和狀态儲存在Database中
1.5 Cinder的基本功能
| 1 | 卷操作 | 建立卷 |
| 2 | 從已有卷建立卷 （克隆） | |
| 3 | 擴充卷 | |
| 4 | 删除卷 | |
| 5 | 卷-虛機操作 | 挂載卷到虛機 |
| 6 | 分離虛機卷 | |
| 7 | 卷-快照操作 | 建立卷的快照 |
| 8 | 從已有卷快照建立卷 | |
| 9 | 删除快照 | |
| 10 | 卷-鏡像操作 | 從鏡像建立卷 |
| 11 | 從卷建立鏡像 |
1.6 Cinder 插件
1.6.1 LVMISCSIDriver
上圖說明：
- cinder-volume 服務部署在控制節點上。該節點上建立了一個 volume group。所謂LVM中的 Local，指的就是 volume group 和 cinder-volume 在同一個節點上，因為 cinder LVM driver 需要調用本地的相關指令來管理 volume group。
- 每個 nova-compute 計算節點作為 iSCSI Intiator 和存儲節點通信。每當 VG 中為一個計算節點的一台虛機配置設定一個volume 後，在計算節點上就會出現一個 /dev/sdx 裝置。此裝置會被 qemu-kvm 提供給虛機，作為虛機的一個disk。
- 一個 cinder-volume 節點上可以有多個 volume group。此時每個 volume group 都有一個 cinder-volume 服務執行個體。
- 一個 openstack 環境中可以有多個 cinder-volume 節點。
每個計算節點作為一個iSCSI initiator。比如 Initiator: iqn.1993-08.org.debian:01:8d794081cd6a alias: compute1
[email protected]:/home/s1# cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1993-08.org.debian:01:8d794081cd6a 每個Lun作為一個iSCSI target： 比如 IQN - iqn.2010-10.org.openstack:volume-3f204086-609e-449f-90a1-3a0d2c92c525 每個initiator和target之間有個tcp session。在compute node上檢視iSCSI session：
[email protected]:/home/s1# iscsiadm -m session
tcp: [10] 192.168.1.24:3260,1 iqn.2010-10.org.openstack:volume-5cfc715d-a7b3-47b4-bded-44c0a228360c
tcp: [11] 192.168.1.19:3260,1 iqn.2010-10.org.openstack:volume-4039eb07-90eb-4a92-8fd3-e3514cb4969b
tcp: [14] 192.168.1.29:3260,1 iqn.2010-10.org.openstack:volume-3f204086-609e-449f-90a1-3a0d2c92c525
tcp: [16] 10.0.1.29:3260,1 iqn.2010-10.org.openstack:volume-1b7f6669-06db-474e-bf78-4feea529be5b
tcp: [6] 192.168.1.24:3260,1 iqn.2010-10.org.openstack:volume-39363c5f-cf3c-4461-af83-00314839f05a
tcp: [9] 192.168.1.24:3260,1 iqn.2010-10.org.openstack:volume-a0a7ccb3-8864-4fd0-aee2-0e20d43ba8dd 每個target的詳細資訊：
tgtadm --lld iscsi --op show --mode target
Target 1: iqn.2010-10.org.openstack:volume-136354c3-5920-46b9-a930-52c055c53295
System information:
Driver: iscsi
State: ready
I_T nexus information:
I_T nexus: 2
Initiator: iqn.1993-08.org.debian:01:8d794081cd6a alias: compute1
Connection: 0
IP Address: 192.168.1.15
LUN information:
LUN: 0
Type: controller
SCSI ID: IET 00010000
SCSI SN: beaf10
Size: 0 MB, Block size: 1
Online: Yes
Removable media: No
Prevent removal: No
Readonly: No
SWP: No
Thin-provisioning: No
Backing store type: null
Backing store path: None
Backing store flags:
LUN: 1
Type: disk
SCSI ID: IET 00010001
SCSI SN: beaf11
Size: 1074 MB, Block size: 512
Online: Yes
Removable media: No
Prevent removal: No
Readonly: No
SWP: No
Thin-provisioning: No
Backing store type: rdwr
Backing store path: /dev/cinder-volumes/volume-136354c3-5920-46b9-a930-52c055c53295
Backing store flags:
Account information:
s6KdhjSUrU2meEyxPTDZ
ACL information:
ALL volume被從虛機分離後，相應的tcp session被删除。
1.6.2 IBM SVC/DS8K/XIV 插件
上圖說明：
- cinder-volume 通過管理網絡和存儲的控制器進行通信來管理volume，是以，理論上最少隻需要一個 cinder-volume 執行個體。但是，為了高可用需要，往往會再部署一個備 cinder-volume 服務，并用 Pacemaker 進行控制。當主服務down後，備服務會接管。
- 以 XIV iSCSI driver （代碼在這裡）為例說明建立卷的過程
- 該 cinder 通過遠端運作SSH 來執行XIV指令來操縱 XIV，比如運作 svctask mkvdisk 指令來建立一個XIV 卷。
- 當為虛機配置設定一個XIV volume 時 cinder driver 所做的工作：（1）計算計算節點的 host name （2）在 XIV 上為該host 建立一個 virtual host，需要指定HBA卡的WWPN（當采用FC連接配接時），或者host 的 IQN（當采用 iSCSI 連接配接時） （4）在XIV 上建立一個 LUN （5）将該LUN mount 給virtual host
- 此時，host 上每個 volume 都會有一個 /dev/sdx 裝置
- qemu 将 sdx 裝置虛拟化為虛機的一個 disk
1.6.3 LVM插件和Vendor插件的比較
2、 Cinder操作
下面講講幾個比較有意思的操作。
2.1 tranfer volume：将volume 的擁有權從一個tenant中的使用者轉移到另一個tenant中的使用者。
兩步走：
1。 在volume所在tenant的使用者使用指令 cinder transfer-create 産生tranfer的時候會産生transfer id 和 authkey： [email protected]:/home/s1# cinder transfer-create d146a947-9c1e-489f-b7a3-6b9604d9fb49
+------------+--------------------------------------+
| Property | Value |
+------------+--------------------------------------+
| auth_key | a94e45d06dd54500 |
| created_at | 2015-01-07T07:36:33.916921 |
| id | b14d1d26-8249-4dd2-8213-258ccfe31542 |
| name | None |
| volume_id | d146a947-9c1e-489f-b7a3-6b9604d9fb49 |
+------------+--------------------------------------+ 目前的tenant id： os-vol-tenant-attr:tenant_id | 96aacc75dc3a488cb073faa06a34b235 2。 在另一個tenant中的使用者使用指令cinder transfer-accept 接受transfer的時候，需要輸入transfer id 和 auth_key [email protected]:~$ cinder transfer-accept b14d1d26-8249-4dd2-8213-258ccfe31542 a94e45d06dd54500
+-----------+--------------------------------------+
| Property | Value |
+-----------+--------------------------------------+
| id | b14d1d26-8249-4dd2-8213-258ccfe31542 |
| name | None |
| volume_id | d146a947-9c1e-489f-b7a3-6b9604d9fb49 |
+-----------+--------------------------------------+ 新的tenant id： os-vol-tenant-attr:tenant_id | 2f07ad0f1beb4b629e42e1113196c04b 其實，對volume來說，就是修改了tenant id （屬性：os-vol-tenant-attr:tenant_id ）而已。
2.2 volume migrate： 将volume從一個backend遷移到另一個backend
多種可能的情況：
1. 如果volume沒有attach到虛機， 1.1 如果是同一個存儲上不同backend之間的遷移，需要存儲的driver會直接支援存儲上的migrate。 1.2 如果是不同存儲上的backend之間的volume遷移，或者存儲cinder driver不支援同一個存儲上backend之間的遷移，那麼将使用cinder預設的遷移操作：Cinder首先建立一個新的volume，然後從源volume拷貝資料到新volume，然後将老的volume删除。 2. 如果volume已經被attach到虛機，Cinder建立一個新的volume，調用Nova去将資料從源volume拷貝到新volume，然後将老的volume删除。目前隻支援Compute libvirt driver. 注意在多個backend的情況下，host必須使用host全名。比如： cinder migrate vol-b21-1 [email protected]
2.3 volume backup
OpenStack Juno版本支援将volume備份到 Ceph，Swift，IBM Tivoli Storage Manager (TSM)。
2.4 qos 支援
Cinder提供qos支援架構，具體的實作依賴于各vendor實作的plugin。 以IBM SVC為例，可以按照如下方法使用qos： （1）建立一個qos spec： cinder qos-create qos-spec qos:IOThrottling=12345 （2）關聯qos spec到一個volume type cinder qos-associate 0e710a13-3c40-4d50-8522-72bddabd93cc （3）建立該volume type類型的volume cinder create 1 --volume-type svc-driver25 --display-name volwit （4）檢視該volume，其被設定了throttling 屬性，它限制了該volume上最大的I/O。 SVC Volume: throttling 12345
3 cinder的元件
關于RPC： cinder内部各元件之間使用基于RabbitMQ的RPC通信。cinder-scheduler和cinder-volume分别 會 建立RPC連接配接，啟動消費者線程，然後等待隊列消息。當輪詢查詢到消息到達後，建立線程處理相關消息。
3.1 cinder-api
主要服務接口, 負責接受和處理外界的API請求，并将請求放入RabbitMQ隊列，交由後端執行。
cinder-api提供兩個版本的REST API：V1提供Volume，Vloume type，Snapshot操作的API；V2增加了QoS，Limits，Backup操作的API。
除了V1和V2文檔列出來的API外，一些volume的操作需要通過POST + action的方式實作，比如extend volume：
POST http://controller:8776/v1/fa2046aaead44a698de8268f94759fc1/volumes/8e87490c-fa18-4cff-b10e-27645c2a7b99/action
Action body: {"os-extend": {"new_size": 2}}
此類操作有：
- os-reset_status
- os-force_delete
- os-force_detach
- os-migrate_volume
- os-migrate_volume_completion
- os-reset_status
- os-update_snapshot_status
- os-attach
- os-detach
- os-reserve
- os-unreserve
- os-begin_detaching
- os-roll_detaching
- os-initialize_connection
- os-terminate_connection
- os-volume_upload_image
- os-extend
- os-update_readonly_flag
- os-retype
- os-set_bootable
- os-promote-replica
- os-reenable-replica
- os-unmanage
cinder-api service 的啟動過程分析見 探索 OpenStack 之（11）：cinder-api Service 啟動過程分析 以及 WSGI / Paste deploy / Router 等介紹 (2015-02-04 16:01)
3.2 cinder-scheduler
cinder-scheduler的用途是在多backend環境中決定建立volume的放置host：
0。 首先判斷host的狀态，隻有service狀态為up的host才會被考慮。
1。建立volume的時候，根據filter和weight算法選出最優的host來建立volume。
2。遷移volume的時候，根據filter和weight算法來判斷目的host是不是符合要求。
如果選出一個host，則使用RPC調用cinder-volume來執行volume操作。
為了維護host的狀态，cinder-scheduler接受定時的host上cinder-volume狀态上報：
2015-01-12 02:02:56.688 828 DEBUG cinder.scheduler.host_manager [req-403ef666-5551-4f31-a130-7bcad8e9d1ec - - - - -] Received volume service update from [email protected]: {u'pools': [{u'pool_name': u'lvmbackend', u'QoS_support': False, u'allocated_capacity_gb': 1, u'free_capacity_gb': 3.34, u'location_info': u'LVMVolumeDriver:block2:cinder-volumes1:default:0', u'total_capacity_gb': 5.34, u'reserved_percentage': 0}], u'driver_version': u'2.0.0', u'vendor_name': u'Open Source', u'volume_backend_name': u'lvmbackend', u'storage_protocol': u'iSCSI'} update_service_capabilities /usr/lib/python2.7/dist-packages/cinder/scheduler/host_manager.py:434
3.2.1 Host Filtering 算法
預設的filter包括 AvailabilityZoneFilter,CapacityFilter,CapabilitiesFilter。其中：
- AvailabilityZoneFilter會判斷cinder host的availability zone是不是與目的az相同。不同則被過濾掉。
- CapacityFilter會判斷host上的剩餘空間 free_capacity_gb 大小，確定free_capacity_gb 大于volume 的大小。不夠則被過濾掉。
- CapabilitiesFilter會檢查host的屬性是否和volume type中的extra specs是否完全一緻。不一緻則被國旅掉。
經過以上Filter的過濾，cinder-scheduler會得到符合條件的host清單，然後進入weighting環節，根據weighting算法選出最優的host。得到空清單則報No valid host was found錯誤。
cinder.conf中，scheduler_default_filters不設定的話，cinder-scheduler預設會使用這三個filter。
3.2.2 Host Weighting 算法
- AllocatedCapacityWeigher：有最小已使用空間的host勝出。 可設定allocated_capacity_weight_multiplier為正值來反轉，其預設值為-1。
- CapacityWeigher：有最大可使用空間的host勝出。可設定capacity_weight_multiplier為負值來反轉算法，其預設值為1
- ChanceWeigher：随機從過濾出的host中選擇一個host
經過此步驟，cinder-scheduler将得到一個weighted_hosts清單，它将會選擇第一個host做為volume的目的host，把它加到retry_hosts清單中，然後通過RPC調用上面的cinder-volume來建立volume。
cinder.conf中，scheduler_default_weighers不設定的話，cinder-scheduler預設使用 CapacityWeigher。
3.3 cinder-volume
該服務運作在存儲節點上，管理存儲空間，處理cinder資料庫的維護狀态的讀寫請求，通過消息隊列和直接在塊儲存設備或軟體上與其他程序互動。每個存儲節點都有一個Volume Service，若幹個這樣的存儲節點聯合起來可以構成一個存儲資源池。 cinder-volume會實作一些common操作，比如 copy_volume_data， 在driver.py裡面實作先attach source 和 target volume，然後執行拷貝資料。其它操作則需要 調用driver的接口來實作volume的操作。
3.3.1 volume建立失敗重試機制
使用者可以在cinder.conf中使用scheduler_max_attempts來配置volume建立失敗時候的重試次數，預設次數為3，值為1則表示不使用重試機制。
# Maximum number of attempts to schedule an volume (integer value)
#scheduler_max_attempts=3
cinder-sheduler和cinder-volume之間會傳遞目前是重試次數。如果volume建立失敗，cinder-volume會通過RPC重新調用cinder-scheduler去建立volume，cinder-scheduler會檢查目前的重試次數是不是超過最大可重試次數。如果沒超過，它會選擇下一個可以使用的host去重新建立volume。如果在規定的重試次數内仍然無法建立volume，那麼會報No valid host was found錯誤。
比如下面的重試過程：
cinder-volume：
- Insufficient free space for volume creation on host [email protected]#lvmbackend (requested / avail): 5/0.0
- Insufficient free space for volume creation on host [email protected]#lvmbackend (requested / avail): 5/4.0
- Insufficient free space for volume creation on host [email protected]#lvmbackend (requested / avail): 5/1.0
cinder-scheduler： No valid host was found
3.3.2 從image建立volume
a。volume-driver首先嘗試去調用driver的clone_image方法。大多數driver沒有實作該方法，比如預設的LVM driver。IBM的GPFS Driver有實作該方法，其實作參考其注釋：
Attempt to create a volume by efficiently copying image to volume. If both source and target are backed by gpfs storage and the source image is in raw format move the image to create a volume using either gpfs clone operation or with a file copy. If the image format is not raw, convert it to raw at the volume path.
b。若driver的clone-image方法不成功，則執行Cinder的預設方法：（1）建立一個raw的volume，設定其狀态為downloading （2）将image下載下傳并拷貝到該volume。具體方法每個driver可以自行實作，Cinder也提供預設實作。
c。拷貝image的metadata到volume的metadata。
3.3.3 從snapshot建立volume
a。擷取snapshot
b。Cinder不提供預設實作方式，它調用各driver的create_volume_from_snapshot方法建立volume。以IBM SVC為例，它會在SVC存儲上建立snapshot的一個拷貝。
c。如果snapshot是bootable的話，需要拷貝它的metadata到新的volume上。
3.3.4 從volume建立volume
a。擷取源volume
b。Cinder不提供預設實作方式，它需要調用各driver的create_cloned_volume方法來建立volume。以IBM SVC為例，它會在存儲上建立源volume的一個拷貝。
c。如果源volume是bootable的話，需要拷貝它的metadata到新的volume上。
3.3.5 建立原始volume
預設的話，cinder-volume會調用各driver建立一個原始的volume。
Cinder的研究基本到這裡。