第3章 永続ボリュームの作成

1. 作成するエンドポイントを指定するには、コピーした sample-gluster-endpoints.yaml ファイルを、環境に基づいて作成されるエンドポイントで更新します。Red Hat Gluster Storage の信頼済みストレージプールには、それぞれ、信頼済みストレージプールのノードの IP を持つ独自のエンドポイントが必要です。

   # cat sample-gluster-endpoints.yaml
   apiVersion: v1
   kind: Endpoints
   metadata:
     name: glusterfs-cluster
   subsets:
     - addresses:
         - ip: 192.168.10.100
       ports:
         - port: 1
     - addresses:
         - ip: 192.168.10.101
       ports:
         - port: 1
     - addresses:
         - ip: 192.168.10.102
       ports:
   - port: 1

   name

   エンドポイントの名前。

   ip

   Red Hat Gluster Storage ノードの IP アドレス。

2. 以下のコマンドを実行してエンドポイントを作成します。

   # oc create -f <name_of_endpoint_file>

   以下に例を示します。

   # oc create -f sample-gluster-endpoints.yaml
   endpoints "glusterfs-cluster" created

3. エンドポイントが作成されたことを確認するには、以下のコマンドを実行します。

   # oc get endpoints

   以下に例を示します。

   # oc get endpoints
   NAME                       ENDPOINTS                                                     AGE
   storage-project-router     192.168.121.233:80,192.168.121.233:443,192.168.121.233:1936   2d
   glusterfs-cluster          192.168.121.168:1,192.168.121.172:1,192.168.121.233:1         3s
   heketi                     10.1.1.3:8080                                                 2m
   heketi-storage-endpoints   192.168.121.168:1,192.168.121.172:1,192.168.121.233:1         3m

4. 以下のコマンドを実行して gluster サービスを作成します。

   # oc create -f <name_of_service_file>

   以下に例を示します。

   # cat sample-gluster-service.yaml
   apiVersion: v1
   kind: Service
   metadata:
     name: glusterfs-cluster
   spec:
     ports:
   - port: 1

   # oc create -f sample-gluster-service.yaml
   service "glusterfs-cluster" created

5. サービスが作成されたことを確認するには、以下のコマンドを実行します。

   # oc get service

   以下に例を示します。

   # oc get service
   NAME                       CLUSTER-IP      EXTERNAL-IP   PORT(S)                   AGE
   storage-project-router     172.30.94.109   <none>        80/TCP,443/TCP,1936/TCP   2d
   glusterfs-cluster          172.30.212.6    <none>        1/TCP                     5s
   heketi                     172.30.175.7    <none>        8080/TCP                  2m
   heketi-storage-endpoints   172.30.18.24    <none>        1/TCP                     3m

   注記

   エンドポイントとサービスは、永続ストレージを必要とする各プロジェクトに対して作成する必要があります。

6. GlusterFS から Replica 3 の 100 G 永続ボリュームを作成し、このボリュームを記述する永続ボリュームの仕様を pv001.json ファイルに出力します。

   $ heketi-cli volume create --size=100 --persistent-volume-file=pv001.json

   cat pv001.json
   {
     "kind": "PersistentVolume",
     "apiVersion": "v1",
     "metadata": {
       "name": "glusterfs-f8c612ee",
       "creationTimestamp": null
     },
     "spec": {
       "capacity": {
         "storage": "100Gi"
       },
       "glusterfs": {
         "endpoints": "TYPE ENDPOINT HERE",
         "path": "vol_f8c612eea57556197511f6b8c54b6070"
       },
       "accessModes": [
         "ReadWriteMany"
       ],
       "persistentVolumeReclaimPolicy": "Retain"
     },
     "status": {}

   重要

   Labels 情報は .json ファイルに手動で追加する必要があります。

   以下は、参照用の YAML ファイルの例です。

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: pv-storage-project-glusterfs1
     labels:
       storage-tier: gold
   spec:
     capacity:
       storage: 12Gi
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain
     glusterfs:
       endpoints: TYPE END POINTS NAME HERE,
   path: vol_e6b77204ff54c779c042f570a71b1407

   name

   ボリュームの名前。

   storage

   このボリュームに割り当てられるストレージの量。

   glusterfs

   使用されているボリュームタイプ。この場合は glusterfs プラグインです。

   endpoints

   作成された信頼済みストレージプールを定義するエンドポイント名

   path

   信頼済みストレージプールからアクセスされる Red Hat Gluster Storage ボリューム。

   accessModes

   accessModes は、PV と PVC を一致させるためのラベルとして使用されます。現時点で、これらはいずれの形態のアクセス制御も定義しません。

   labels

   ラベルを使用して、ボリューム間で共有している共通の属性や特性を識別します。この例では、gluster ボリュームを定義し、storage-tier という名前のカスタム属性 (キー) を持たせて、gold という値を割り当てています。要求で storage-tier=gold を使用して PV を選択すると、その PV に一致します。

   注記

   • heketi-cli は、コマンドラインのエンドポイント名 (--persistent-volume-endpoint="TYPE ENDPOINT HERE") も受け入れます。次に、これをパイプで oc create -f - に渡して永続ボリュームをすぐに作成できます。
   • 環境内に複数の Red Hat Gluster Storage の信頼済みストレージプールがある場合は、heketi-cli volume list コマンドを使用して、ボリュームが作成される信頼済みストレージプールを確認できます。このコマンドはクラスター名を一覧表示します。次に、pv001.json ファイルのエンドポイント情報を適宜更新できます。
   • レプリカ数がデフォルト値の 3(レプリカ 3) に設定された 2 つのノードのみを持つ Heketi ボリュームを作成する場合、3 つの異なるノードに 3 つのディスクのレプリカセットを作成するスペースがないため、Heketi がエラー"No space"を表示します。
   • すべての heketi-cli 書き込み操作 (volume create、cluster create など) が失敗し、読み取り操作 (例:topology info、volume info など) に成功すると、gluster ボリュームが読み取り専用モードで動作している可能性があります。

7. pv001.json ファイルを編集し、エンドポイントのセクションにエンドポイントの名前を入力します。

   cat pv001.json
   {
     "kind": "PersistentVolume",
     "apiVersion": "v1",
     "metadata": {
       "name": "glusterfs-f8c612ee",
       "creationTimestamp": null,
       "labels": {
         "storage-tier": "gold"
       }
     },
     "spec": {
       "capacity": {
         "storage": "12Gi"
       },
       "glusterfs": {
         "endpoints": "glusterfs-cluster",
         "path": "vol_f8c612eea57556197511f6b8c54b6070"
       },
       "accessModes": [
         "ReadWriteMany"
       ],
       "persistentVolumeReclaimPolicy": "Retain"
     },
     "status": {}
   }

8. 以下のコマンドを実行して永続ボリュームを作成します。

   # oc create -f pv001.json

   以下に例を示します。

   # oc create -f pv001.json
   persistentvolume "glusterfs-4fc22ff9" created

9. 永続ボリュームが作成されたことを確認するには、以下のコマンドを実行します。

   # oc get pv

   以下に例を示します。

   # oc get pv
   
   NAME                 CAPACITY   ACCESSMODES   STATUS      CLAIM     REASON    AGE
   glusterfs-4fc22ff9   100Gi      RWX           Available                       4s

10. 永続ボリューム要求ファイルを作成します。以下に例を示します。

    # cat pvc.yaml
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: glusterfs-claim
    spec:
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 100Gi
        selector:
          matchLabels:
    storage-tier: gold

11. 以下のコマンドを実行して、永続ボリュームを永続ボリューム要求 (PVC) にバインドします。

    # oc create -f pvc.yaml

    以下に例を示します。

    # oc create -f pvc.yaml
    persistentvolumeclaim"glusterfs-claim" created

12. 永続ボリュームと永続ボリューム要求がバインドされていることを確認するには、以下のコマンドを実行します。

    # oc get pv
    # oc get pvc

    以下に例を示します。

    # oc get pv
    
    NAME                 CAPACITY   ACCESSMODES   STATUS    CLAIM                  REASON    AGE
    glusterfs-4fc22ff9   100Gi      RWX           Bound     storage-project/glusterfs-claim             1m

    # oc get pvc
    
    NAME              STATUS    VOLUME               CAPACITY   ACCESSMODES   AGE
    glusterfs-claim   Bound     glusterfs-4fc22ff9   100Gi      RWX           11s

13. この要求はアプリケーションで使用できます。以下に例を示します。

    # cat app.yaml
    
    apiVersion: v1
    kind: Pod
    metadata:
      name: busybox
    spec:
      containers:
        - image: busybox
          command:
            - sleep
            - "3600"
          name: busybox
          volumeMounts:
            - mountPath: /usr/share/busybox
              name: mypvc
      volumes:
        - name: mypvc
          persistentVolumeClaim:
    claimName: glusterfs-claim

    # oc create -f app.yaml
    pod "busybox" created

    アプリケーションで glusterfs 要求を使用する方法についての詳細は https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-storage-examples-gluster-example を参照してください。

14. Pod が作成されたことを確認するには、以下のコマンドを実行します。

    # oc get pods -n <storage_project_name>

    以下に例を示します。

    # oc get pods -n storage-project
    
    NAME                               READY     STATUS    RESTARTS   AGE
    block-test-router-1-deploy         0/1       Running     0          4h
    busybox                            1/1       Running   0          43s
    glusterblock-provisioner-1-bjpz4   1/1       Running   0          4h
    glusterfs-7l5xf                    1/1       Running   0          4h
    glusterfs-hhxtk                    1/1       Running   3          4h
    glusterfs-m4rbc                    1/1       Running   0          4h
    heketi-1-3h9nb                     1/1       Running   0          4h

15. 永続ボリュームがコンテナー内でマウントされていることを確認するには、以下のコマンドを実行します。

    # oc rsh busybox

    / $ df -h
    Filesystem                Size      Used Available Use% Mounted on
    /dev/mapper/docker-253:0-1310998-81732b5fd87c197f627a24bcd2777f12eec4ee937cc2660656908b2fa6359129
                          100.0G     34.1M     99.9G   0% /
    tmpfs                     1.5G         0      1.5G   0% /dev
    tmpfs                     1.5G         0      1.5G   0% /sys/fs/cgroup
    192.168.121.168:vol_4fc22ff934e531dec3830cfbcad1eeae
                           99.9G     66.1M     99.9G   0% /usr/share/busybox
    tmpfs                     1.5G         0      1.5G   0% /run/secrets
    /dev/mapper/vg_vagrant-lv_root
                           37.7G      3.8G     32.0G  11% /dev/termination-log
    tmpfs                     1.5G     12.0K      1.5G   0% /var/run/secretgit s/kubernetes.io/serviceaccount

1. GID の値を指定してストレージクラスファイルを作成します。以下に例を示します。

   # cat glusterfs-storageclass.yaml
   
   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: gluster-container
   provisioner: kubernetes.io/glusterfs
   parameters:
     resturl: "http://heketi-storage-project.cloudapps.mystorage.com"
     restuser: "admin"
     secretNamespace: "default"
     secretName: "heketi-secret"
     gidMin: "2000"
   gidMax: "4000"

   注記

   gidMin 値および gidMax 値が指定されていない場合、動的にプロビジョニングされたボリュームには 2000 から 2147483647 までの GID が設定されます。

2. 永続ボリューム要求 (PVC) を作成します。詳細は、「Persistent Volume Claim(永続ボリューム要求、PVC) の作成」を参照してください。
3. Pod の要求を使用します。この Pod が特権を持たないことを確認します。詳細は、「Pod での要求の使用」を参照してください。

4. GID が指定の範囲内にあるかどうかを確認するには、以下のコマンドを実行します。

   # oc rsh busybox

   $ id

   以下に例を示します。

   $ id
   uid=1000060000 gid=0(root) groups=0(root),2001

   ここで、上記の出力の 2001 は、永続ボリュームに割り当てられた GID で、ストレージクラスで指定された範囲内にあります。割り当てられた GID を使用して、このボリュームに書き込むことができます。

   注記

   永続ボリューム要求 (PVC) が削除されると、永続ボリュームの GID がプールから解放されます。

手順

1. 必要なタグを heketi デバイスに適用します。

   # heketi-cli device settags <device-name> <key>:<value>

   例:

   # heketi-cli device settags 1fe1b83e5660efb53cc56433cedf7771 disktype:hdd

2. 適用されたタグをデバイスから削除します。

   # heketi-cli device rmtags <device-name> <key>

   例:

   # heketi-cli device rmtags 1fe1b83e5660efb53cc56433cedf7771 disktype

3. デバイスに追加されたタグを確認します。

   # heketi-cli device info <device-name>

   例:

   # heketi-cli device info 1fe1b83e5660efb53cc56433cedf7771

   出力例:

   Device Id: 1fe1b83e5660efb53cc56433cedf7771
   State: online
   Size (GiB): 49
   Used (GiB): 41
   Free (GiB): 8
   Create Path: /dev/vdc
   Physical Volume UUID: GpAnb4-gY8e-p5m9-0UU3-lV3J-zQWY-zFgO92
   Known Paths: /dev/disk/by-id/virtio-bf48c436-04a9-48ed-9 /dev/disk/by-path/pci-0000:00:08.0 /dev/disk/by-path/virtio-pci-0000:00:08.0 /dev/vdc
   Tags:
     disktype: hdd    ---> added tag

4. タグ付けされたデバイスを使用してボリュームを作成します。

    # heketi-cli volume create --size=<size in GiB> --gluster-volume-options'user.heketi.device-tag-match <key>=<value>’

   重要

   • ボリュームの作成時に、新しいボリュームオプション user.heketi.device-tag-match を渡す必要があります。ここで、オプションの値は、タグキーに続いて"=" または "!="のいずれか、これにタグの値が続きます。
   • すべての一致は完全一致であり、大文字と小文字が区別され、1 つの device-tag-match のみを指定できます。

   例:

   # heketi-cli volume create --size=5 --gluster-volume-options 'user.heketi.device-tag-match disktype=hdd’

   注記

   ボリュームが作成されると、ボリュームオプションの一覧が固定されます。tag-match ルールは、ボリューム拡張およびブリックの置き換えの目的で、ボリュームのメタデータと共に永続化されます。

5. ストレージクラスを作成します。

   • ハードディスク上にのみボリュームを作成するストレージクラスを作成します。

     # cat hdd-storageclass.yaml

     apiVersion: storage.k8s.io/v1
     kind: StorageClass
     metadata:
       annotations:
         storageclass.kubernetes.io/is-default-class: "false"
       name: glusterfs-storage-hdd
       selfLink: /apis/storage.k8s.io/v1/storageclasses/glusterfs-storage
     parameters:
       resturl: http://heketi-storage.glusterfs.svc:8080
       restuser: admin
       secretName: heketi-storage-admin-secret
       secretNamespace: glusterfs
       volumeoptions: "user.heketi.device-tag-match disktype=hdd"
     provisioner: kubernetes.io/glusterfs
     reclaimPolicy: Delete
     volumeBindingMode: Immediate

   • より高速なソリッドステートストレージだけを使用してボリュームを作成するストレージクラスを作成します。

     重要

     ハードディスクデバイスを除外する負のタグのマッチングルールを使用する必要があります。

     # cat sdd-storageclass.yaml

     apiVersion: storage.k8s.io/v1
     kind: StorageClass
     metadata:
       annotations:
         storageclass.kubernetes.io/is-default-class: "false"
       name: glusterfs-storage-dd
       selfLink: /apis/storage.k8s.io/v1/storageclasses/glusterfs-storage
     parameters:
       resturl: http://heketi-storage.glusterfs.svc:8080
       restuser: admin
       secretName: heketi-storage-admin-secret
       secretNamespace: glusterfs
       volumeoptions: "user.heketi.device-tag-match disktype!=hdd"
     provisioner: kubernetes.io/glusterfs
     reclaimPolicy: Delete
     volumeBindingMode: Immediate