3.2. Block Storage

ブロックストレージにより、個別のストレージユニットを高く作成できます。glusterfs がサポートする従来のファイルストレージ機能とは異なり、各ストレージボリューム/ブロックデバイスを独立したディスクドライブとして扱うことができるため、各ストレージボリューム/ブロックデバイスが個別のファイルシステムをサポートできます。

gluster-block は、ブロックデバイスの分散管理フレームワークです。Gluster がサポートするブロックストレージの作成とメンテナーンスを可能な限りシンプルにすることが目的です。gluster-block はブロックデバイスをプロビジョニングし、複数のノードで iSCSI LUN としてエクスポートし、データ転送に SCSI ブロック/コマンドとして iSCSI プロトコルを使用します。

注記
  • ブロックボリューム拡張が OpenShift Container Storage 3.11 でサポートされるようになりました。「ブロックボリューム拡張」を参照してください。
  • ボリュームの静的プロビジョニングは、ブロックストレージではサポートされません。ボリュームの動的プロビジョニングが、サポートされる唯一の方法です。
  • ブロックストレージに推奨される Red Hat Enterprise Linux(RHEL) バージョンは RHEL 7.5.4 です。カーネルのバージョンが 3.10.0-862.14.4.el7.x86_64 と一致していることを確認してください。確認するには、以下を実行します。

    # uname -r

    最新のカーネル更新を有効にするためにノードを再起動します。

3.2.1. Block Storage 用ボリュームの動的プロビジョニング

動的プロビジョニングにより、ボリュームを事前に作成せずに、Red Hat Gluster Storage ボリュームを実行中のアプリケーションコンテナーにプロビジョニングできます。ボリュームは要求を受け取る際に動的に作成され、まったく同じサイズのボリュームがアプリケーションコンテナーにプロビジョニングされます。

注記

OpenShift Container Storage が (デフォルトの)Ansible インストーラーを使用してデプロイされた場合、以下に概要を示す手順は必要ありません。インストール時に作成されたデフォルトのストレージクラス (glusterfs-storage-block) が使用されます。

3.2.1.1. ボリュームの動的プロビジョニングの設定

ボリュームの動的プロビジョニングを設定するには、管理者はクラスターで提供されるストレージの指定の"classes"を記述する StorageClass オブジェクトを定義する必要があります。Storage Class の作成後に、heketi 認証のシークレットを作成してから、Persistent Volume Claim(永続ボリューム要求、PVC) の作成を続行する必要があります。

3.2.1.1.1. すべてのイニシエーターでのマルチパスの設定

iSCSI イニシエーターが iSCSI ターゲットと通信し、マルチパスを使用して HA を実現できるようにするには、アプリケーション Pod がホストされるすべての OpenShift ノード (iSCSI イニシエーター) で以下の手順を実行します。

  1. イニシエーターを設定する必要があるすべてのノードにイニシエーター関連のパッケージをインストールするには、以下のコマンドを実行します。

    # yum install iscsi-initiator-utils device-mapper-multipath
  2. マルチパスを有効にするには、次のコマンドを実行します。

    # mpathconf --enable
  3. multipath.conf ファイルに以下の内容を作成して追加します。

    注記

    アップグレードする場合は、multipath.conf への変更と multipathd のリロードは、すべてのサーバーノードがアップグレードされた後にのみ実行されるようにしてください。

    # cat >> /etc/multipath.conf <<EOF
    # LIO iSCSI
    devices {
            device {
                    vendor "LIO-ORG"
                    user_friendly_names "yes" # names like mpatha
                    path_grouping_policy "failover" # one path per group
                    hardware_handler "1 alua"
                    path_selector "round-robin 0"
                    failback immediate
                    path_checker "tur"
                    prio "alua"
                    no_path_retry 120
            }
    }
    EOF
  4. 以下のコマンドを実行して、マルチパスデーモンを起動し、マルチパス設定を (再) 読み込みします。

    # systemctl start multipathd
    # systemctl reload multipathd
3.2.1.1.2. Heketi 認証のシークレットの作成

Heketi 認証のシークレットを作成するには、以下のコマンドを実行します。

注記

admin-key の値 (ボリュームの詳細を取得するために heketi にアクセスするためのシークレット) が Red Hat Openshift Container Storage のデプロイメント時に設定されていない場合、以下の手順を実行は省略できます。

  1. 以下のコマンドを実行して、パスワードのエンコードされた値を作成します。

    # echo -n "<key>" | base64

    ここで、key は、CNS のデプロイ時に作成された admin-key の値です。

    以下に例を示します。

    # echo -n "mypassword" | base64
    bXlwYXNzd29yZA==
  2. シークレットファイルを作成します。以下はシークレットファイルの例です。

    # cat glusterfs-secret.yaml
    
    apiVersion: v1
    kind: Secret
    metadata:
      name: heketi-secret
      namespace: default
    data:
      # base64 encoded password. E.g.: echo -n "mypassword" | base64
      key: bXlwYXNzd29yZA==
    type: gluster.org/glusterblock
  3. 以下のコマンドを実行して OpenShift にシークレットを登録します。

    # oc create -f glusterfs-secret.yaml
    secret "heketi-secret" created
3.2.1.1.3. ストレージクラスの登録

永続ボリュームのプロビジョニング用に StorageClass オブジェクトを設定する場合、管理者は使用するプロビジョナーのタイプと、クラスに属する PersistentVolume をプロビジョニングする際にプロビジョナーによって使用されるパラメーターを記述する必要があります。

  1. ストレージクラスを作成します。以下は、ストレージクラスのサンプルファイルです。

    # cat > glusterfs-block-storageclass.yaml
    
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
     name: gluster-block
    provisioner: gluster.org/glusterblock-infra-storage
    reclaimPolicy: Retain
    parameters:
     resturl: "http://heketi-storage-project.cloudapps.mystorage.com"
     restuser: "admin"
     restsecretnamespace: "default"
     restsecretname: "heketi-secret"
     hacount: "3"
     clusterids: "630372ccdc720a92c681fb928f27b53f,796e6db1981f369ea0340913eeea4c9a"
     chapauthenabled: "true"
     volumenameprefix: "test-vol"

    ここで、

    provisioner

    provisioner 名は、glusterblock provisioner Pod がデプロイされたプロビジョナーの名前と一致している必要があります。provisioner name を取得するには、次のコマンドを使用します。

    # oc describe pod <glusterblock_provisioner_pod_name> |grep PROVISIONER_NAME

    以下に例を示します。

    # oc describe pod glusterblock-registry-provisioner-dc-1-5j8l9 |grep PROVISIONER_NAME
         PROVISIONER_NAME:  gluster.org/glusterblock-infra-storage
    resturl
    Gluster REST サービス/Heketi サービスの URL。これは、gluster ボリュームをオンデマンドでプロビジョニングします。一般的な形式は IPaddress:Port でなければならず、GlusterFS 動的プロビジョナーの場合必須のパラメーターです。Heketi サービスが openshift/kubernetes 設定でルーティング可能なサービスとして公開される場合、これには http://heketi-storage-project.cloudapps.mystorage.com と同様の形式を設定できます。ここで、fqdn は解決可能な heketi サービスの URL です。
    restuser
    信頼済みストレージプールでボリュームを作成できる Gluster REST サービス/Heketi ユーザー
    restsecretnamespace + restsecretname
    Gluster REST サービスとの通信時に使用するユーザーパスワードを含むシークレットインスタンスの識別。これらのパラメーターはオプションです。空のパスワードは、restsecretnamespacerestsecretname の両方を省略する場合に使用されます。
    hacount
    これは、ブロックターゲットサーバーへのパスの数です。hacount は、iSCSI のマルチパス機能を使用して高可用性を提供します。パスに障害が発生した場合、I/O は中断されず、別の利用可能なパスを介して提供されます。
    clusterids

    これは、ボリュームのプロビジョニング時に Heketi によって使用されるクラスターの ID です。また、クラスター ID のコンマ区切りリストも指定できます。これはオプションのパラメーターです。

    注記

    クラスター ID を取得するには、以下のコマンドを実行します。

    # heketi-cli cluster list
    chapauthenabled
    CHAP 認証を有効にしてブロックボリュームをプロビジョニングする場合は、この値を true に設定する必要があります。これはオプションのパラメーターです。
    volumenameprefix

    これはオプションのパラメーターです。これは、heketi で作成されたボリュームの名前を示しています。詳細は、「(オプション) 永続ボリュームのカスタムボリューム名の接頭辞の指定」を参照してください。

    注記

    このパラメーターの値には、storageclass に _ を含めることができません。

  2. ストレージクラスを Openshift に登録するには、以下のコマンドを実行します。

    # oc create -f glusterfs-block-storageclass.yaml
    storageclass "gluster-block" created
  3. ストレージクラスの詳細を取得するには、以下のコマンドを実行します。

    # oc describe storageclass gluster-block
    Name:            gluster-block
    IsDefaultClass:  No
    Annotations:     <none>
    Provisioner:     gluster.org/glusterblock-infra-storage
    Parameters:      chapauthenabled=true,hacount=3,opmode=heketi,restsecretname=heketi-secret,restsecretnamespace=default,resturl=http://heketi-storage-project.cloudapps.mystorage.com,restuser=admin
    Events:          <none>
3.2.1.1.4. Persistent Volume Claim(永続ボリューム要求、PVC) の作成

永続ボリューム要求 (PVC) を作成するには、以下のコマンドを実行します。

  1. Persistent Volume Claim(永続ボリューム要求、PVC) ファイルを作成します。Persistent Volume Claim(永続ボリューム要求、PVC) のサンプルは以下のとおりです。

    # cat glusterfs-block-pvc-claim.yaml
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: claim1
      annotations:
        volume.beta.kubernetes.io/storage-class: gluster-block
    spec:
      persistentVolumeReclaimPolicy: Retain
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 5Gi
    persistentVolumeReclaimPolicy

    これはオプションのパラメーターです。このパラメーターを"Retain"に設定すると、対応する永続ボリューム要求 (PVC) が削除されても、基礎となる永続ボリュームが保持されます。

    注記

    PVC の削除時に、"persistentVolumeReclaimPolicy:"が"Retain"に設定されている場合、基礎となる heketi および gluster ボリュームは削除されません。ボリュームを削除するには、heketi cli を使用して PV を削除する必要があります。

  2. 以下のコマンドを実行して要求を登録します。

    # oc create -f glusterfs-block-pvc-claim.yaml
    persistentvolumeclaim "claim1" created
  3. 要求の詳細を取得するには、以下のコマンドを実行します。

    # oc describe pvc <_claim_name_>

    以下に例を示します。

    # oc describe pvc claim1
    
    Name:        claim1
    Namespace:    block-test
    StorageClass:    gluster-block
    Status:        Bound
    Volume:        pvc-ee30ff43-7ddc-11e7-89da-5254002ec671
    Labels:        <none>
    Annotations:    control-plane.alpha.kubernetes.io/leader={"holderIdentity":"8d7fecb4-7dba-11e7-a347-0a580a830002","leaseDurationSeconds":15,"acquireTime":"2017-08-10T15:02:30Z","renewTime":"2017-08-10T15:02:58Z","lea...
           pv.kubernetes.io/bind-completed=yes
           pv.kubernetes.io/bound-by-controller=yes
           volume.beta.kubernetes.io/storage-class=gluster-block
           volume.beta.kubernetes.io/storage-provisioner=gluster.org/glusterblock
    Capacity:    5Gi
    Access Modes:    RWO
    Events:
     FirstSeen    LastSeen    Count    From                            SubObjectPath    Type        Reason            Message
     ---------    --------    -----    ----                            -------------    --------    ------            -------
     1m        1m        1    gluster.org/glusterblock 8d7fecb4-7dba-11e7-a347-0a580a830002            Normal        Provisioning        External provisioner is provisioning volume for claim "block-test/claim1"
     1m        1m        18    persistentvolume-controller                Normal        ExternalProvisioning    cannot find provisioner "gluster.org/glusterblock", expecting that a volume for the claim is provisioned either manually or via external software
    1m        1m        1    gluster.org/glusterblock 8d7fecb4-7dba-11e7-a347-0a580a830002            Normal        ProvisioningSucceeded    Successfully provisioned volume pvc-ee30ff43-7ddc-11e7-89da-5254002ec671
3.2.1.1.5. 要求作成の確認

要求が作成されているかどうかを確認するには、以下のコマンドを実行します。

  1. 永続ボリューム要求 (PVC) および永続ボリュームの詳細を取得するには、以下のコマンドを実行します。

    # oc get pv,pvc
    
    NAME                                          CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM               STORAGECLASS    REASON    AGE
    pv/pvc-ee30ff43-7ddc-11e7-89da-5254002ec671   5Gi        RWO           Delete          Bound     block-test/claim1   gluster-block             3m
    
    NAME         STATUS    VOLUME                                     CAPACITY   ACCESSMODES   STORAGECLASS    AGE
    pvc/claim1   Bound     pvc-ee30ff43-7ddc-11e7-89da-5254002ec671   5Gi        RWO           gluster-block   4m
注記

ブロックボリュームとブロックホストボリュームを特定するには、https://access.redhat.com/solutions/3897581 を参照してください。

3.2.1.1.6. (オプション) 永続ボリュームのカスタムボリューム名の接頭辞の指定

作成する永続ボリュームに、カスタムボリューム名の接頭辞を指定できます。カスタムのボリューム名の接頭辞を指定すると、以下に基づいてボリュームを簡単に検索/フィルターできるようになります。

  • storageclass ファイルの"volnameprefix"フィールドの値として提供された文字列。
  • Persistent Volume Claim(永続ボリューム要求、PVC) 名。
  • プロジェクト/namespace 名。

名前を設定するには、パラメーター volumenameprefix をストレージクラスファイルに追加していることを確認します。詳細は、「ストレージクラスの登録」を参照してください。

注記

このパラメーターの値には、storageclass に _ を含めることができません。

カスタムのボリューム名の接頭辞が設定されているかどうかを確認するには、以下のコマンドを実行します。

# oc describe pv <pv_name>

以下に例を示します。

# oc describe pv pvc-4e97bd84-25f4-11e8-8f17-005056a55501
    Name:            pvc-4e97bd84-25f4-11e8-8f17-005056a55501
    Labels:          <none>
    Annotations:     AccessKey=glusterblk-67d422eb-7b78-4059-9c21-a58e0eabe049-secret
                     AccessKeyNs=glusterfs
                     Blockstring=url:http://172.31.251.137:8080,user:admin,secret:heketi-secret,secretnamespace:glusterfs
                     Description=Gluster-external: Dynamically provisioned PV
                     gluster.org/type=block
                     gluster.org/volume-id=cd37c089372040eba20904fb60b8c33e
                     glusterBlkProvIdentity=gluster.org/glusterblock
                     glusterBlockShare=test-vol_glusterfs_bclaim1_4eab5a22-25f4-11e8-954d-0a580a830003
                     kubernetes.io/createdby=heketi
                     pv.kubernetes.io/provisioned-by=gluster.org/glusterblock
                     v2.0.0=v2.0.0
    StorageClass:    gluster-block-prefix
    Status:          Bound
    Claim:           glusterfs/bclaim1
    Reclaim Policy:  Delete
    Access Modes:    RWO
    Capacity:        5Gi
    Message:
    Source:
        Type:               ISCSI (an ISCSI Disk resource that is attached to a kubelet's host machine and then exposed to the pod)
        TargetPortal:       10.70.46.177
        IQN:                iqn.2016-12.org.gluster-block:67d422eb-7b78-4059-9c21-a58e0eabe049
        Lun:                0
        ISCSIInterface      default
        FSType:             xfs
        ReadOnly:           false
        Portals:            [10.70.46.142 10.70.46.4]
        DiscoveryCHAPAuth:  false
        SessionCHAPAuth:    true
        SecretRef:          {glusterblk-67d422eb-7b78-4059-9c21-a58e0eabe049-secret }
        InitiatorName:      <none>
Events:                 <none>

glusterBlockShare の値には、namespace および要求名に割り当てられたカスタムのボリューム名の接頭辞が付けられます。ここでは"test-vol"です。

3.2.1.1.7. Pod での要求の使用

Pod で要求を使用するには、以下の手順を実行します。

  1. アプリケーションで要求を使用するには、たとえば、以下のようになります。

    # 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: claim1
    # 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 を参照してください。

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

    # 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
  3. 永続ボリュームがコンテナー内でマウントされていることを確認するには、以下のコマンドを実行します。

    # oc rsh busybox
    /  # df -h
    Filesystem                Size      Used Available Use% Mounted on
    /dev/mapper/docker-253:1-11438-39febd9d64f3a3594fc11da83d6cbaf5caf32e758eb9e2d7bdd798752130de7e
                            10.0G     33.9M      9.9G   0% /
    tmpfs                     3.8G         0      3.8G   0% /dev
    tmpfs                     3.8G         0      3.8G   0% /sys/fs/cgroup
    /dev/mapper/VolGroup00-LogVol00
                             7.7G      2.8G      4.5G  39% /dev/termination-log
    /dev/mapper/VolGroup00-LogVol00
                             7.7G      2.8G      4.5G  39% /run/secrets
    /dev/mapper/VolGroup00-LogVol00
                             7.7G      2.8G      4.5G  39% /etc/resolv.conf
    /dev/mapper/VolGroup00-LogVol00
                             7.7G      2.8G      4.5G  39% /etc/hostname
    /dev/mapper/VolGroup00-LogVol00
                             7.7G      2.8G      4.5G  39% /etc/hosts
    shm                      64.0M         0     64.0M   0% /dev/shm
    /dev/mpatha                  5.0G     32.2M      5.0G   1% /usr/share/busybox
    tmpfs                     3.8G     16.0K      3.8G   0% /var/run/secrets/kubernetes.io/serviceaccount
    tmpfs                     3.8G         0      3.8G   0% /proc/kcore
    tmpfs                     3.8G         0      3.8G   0% /proc/timer_list
    tmpfs                     3.8G         0      3.8G   0% /proc/timer_stats
    tmpfs                     3.8G         0      3.8G   0% /proc/sched_debug
3.2.1.1.8. Persistent Volume Claim(永続ボリューム要求、PVC) の削除
注記

storageclass の登録時に"persistentVolumeReclaimPolicy"パラメーターが "Retain"に設定されている場合、基礎となる PV と対応するボリュームは、PVC が削除されてもそのまま残ります。

  1. 要求を削除するには、以下のコマンドを実行します。

    # oc delete pvc <claim-name>

    以下に例を示します。

    # oc delete pvc claim1
    persistentvolumeclaim "claim1" deleted
  2. 要求が削除されたかどうかを確認するには、以下のコマンドを実行します。

    # oc get pvc <claim-name>

    以下に例を示します。

    # oc get pvc claim1
    No resources found.

    ユーザーが動的プロビジョニングで作成された永続ボリュームにバインドされている永続ボリューム要求 (PVC) を削除すると、永続ボリューム要求の削除とは別に、Kubernetes は永続ボリューム、エンドポイント、サービス、および実際のボリュームも削除します。これを検証する必要がある場合は、以下のコマンドを実行します。

    • 永続ボリュームが削除されたかどうかを確認するには、以下のコマンドを実行します。

      # oc get pv <pv-name>

      以下に例を示します。

      # oc get pv pvc-962aa6d1-bddb-11e6-be23-5254009fc65b
      No resources found.

次のステップ: Red Hat Openshift Container Storage 3.11 をインストールし、ロギングおよびメトリクスのバックエンドストレージとしてブロックストレージを使用する場合は、7章ロギングおよびメトリクス用バックエンドとしての Gluster Block Storage に進みます。