Azure Kubernetes Serviceでの共有ストレージ(Azure NetApp Files編)

SHARE

こんにちは、サイオステクノロジー技術部 武井です。今回は、Azure Kubernetes Serviceで利用できる共有ストレージの中で、Azure NetApp Filesを試してみました。

目次

AKSで利用できる共有ストレージ

公式マニュアルでは、Azure Kubernetes Serviceで利用できる共有ストレージは以下の3つがあります。

  • Azure Files
  • 仮想マシンに立てたNFSサーバー
  • Azure Netapp Files

今回はAzure NetApp Filesを試してみることにします。

Azure NetApp Filesとは？

Azure  NetApp Filesとは、NetApp社が提供するONTAPというストレージ専用OSを搭載した高性能ストレージのマネージドサービスです。Azure Filesとは違い、SMBだけではなくNFSプロトコルの採用、スナップショット機能、Active Directoryとの連携など、様々な機能を備えたストレージサービスです。

Azure Kubernetes Serviceから利用できるマネージドな共有ストレージの中で、最も高性能な部類に入ると言っても過言ではありません。今のところ、Azure Kubernetes Serviceから利用する共有ストレージは、Azure FilesかAzure NetApp Filseの2択になるのではないでしょうか？

Azure NetApp Filesの構成

以下のリンクを参考にAzure NetApp Filesの構成をまとめました。

https://docs.microsoft.com/ja-jp/azure/azure-netapp-files/azure-netapp-files-understand-storage-hierarchy

Screen Shot 2020-01-05 at 22.41.13

まず最上位にAzureサブスクリプションがあって、その下にNetAppアカウントがあります。NetAppアカウントを作成したあとは、それに紐づく容量プールというものを作成します。最小単位は4TiBです。そしてそこからボリュームというのを切り出していき、これがAzure NetApp Filesの最小利用単位となります。100GiBから利用可能です。このボリュームをAzure Kubernetes Cluster内のコンテナからマウントします。

サービスプラン

Azure NetApp FilesにはStandard、Premium、Ultraという3つのプランがあり、価格が異なるのはもちろんのことですが、プランごとに機能面では異なるのはスループットです。

  • Standard：1TiBあたり16MiB/s
  • Premium：1TiBあたり64MiB/s
  • Ultra：1TiBあたり128MiB/s

イマイチイメージしにくいかと思いますので、図にしてみました。

■ 例1：Premiumで1TiBのボリュームを切り出した場合

Screen Shot 2020-01-05 at 22.28.01

1TiBあたり64MiB/sのスループットが出るので、1TiBのボリュームを切り出したときは、そのまんま64MiB/sのスループットが出ます。

■ 例2：Premiumで500GiBのボリュームを切り出した場合

Screen Shot 2020-01-05 at 22.31.47

例1の場合とプランは同じで半分の500GiBのボリュームを切り出した場合は、例1の半分の32MiBのスループットになります。

■ 例3：Ultraで500GiBのボリュームを切り出した場合

Screen Shot 2020-01-05 at 22.34.30

例2とボリュームは500GiBと同じで、プランをPremiumからUltraに変更した場合は、スループットは64MiBとなり、例2の倍となります。Ultraのスループットは1TiBあたり128MiB/sだからです。

このように利用する容量とスループットによって、選択するプランを考えなければなりません。容量が少なくてもスループットが欲しい場合はUltra、容量がたくさん欲しいけれどスループットが低くてもいい場合はStandardなどの使い分けが必要になります。

構築してみましょう

基本的には以下のリンクの公式マニュアルどおりでOKでした。

https://docs.microsoft.com/ja-jp/azure/aks/azure-netapp-files

Azure NetApp Files順番待ちリスト送信

では、早速構築してみましょう。まず、2020年1月5日現在、Azure NetApp Filesを利用するにはAzure NetApp Files順番待ちリスト送信フォーム(上記URL参照)から申請をして、受理されなければなりません。これには数日かかります。

私の場合は、申請しても特に受理されたよ−みたいなメールも来ず、年末年始を挟んでいたせいか3〜4日程度待っても何も応答がありませんでした。そこでサポートに状況を確認したら、1日経たないうちに「申請が受理されたよ−」みたいなお返事を頂き、使えるようになりました。

NetAppアカウントの作成

以下のコマンドでNetAppアカウントを作成します。[MCから始めるリソースグループ名]はAzure Kubernetes Clusterを構成する各種リソースが所属するリソースグループを指定してください。naf-accountという名称で東日本リージョンにNetAppアカウントを作成します。

az netappfiles account create \
  --resource-group [MCから始まるリソースグループ名] \
  --location japaneast \
  --account-name naf-account

 

容量プールの作成

容量プールを作成します。下記コマンドは、東日本リージョンにnafpoolという名前の4TiBの容量プールをUltraプランで作成するものです。

az netappfiles pool create \
  --resource-group [MCから始まるリソースグループ名] \
  --location japaneast \
  --account-name naf-account \
  --pool-name nafpool \
  --size 4 \
  --service-level Ultra

サブネットの作成

後ほど作成するボリュームが所属するサブネットを作成します。Azure Kubernetes Clusterと同じサブネットに所属するようにします。

RESOURCE_GROUP=[MCから始まるリソースグループ名]
# Azure Kubernetes Clusterが所属する仮想ネットワークの名称を取得します。
VNET_NAME=$(az network vnet list --resource-group $RESOURCE_GROUP --query [].name -o tsv)
# Azure Kubernetes Clusterが所属する仮想ネットワークのIDを取得します。
VNET_ID=$(az network vnet show --resource-group $RESOURCE_GROUP --name $VNET_NAME --query "id" -o tsv)
# サブネット名を指定します。
SUBNET_NAME=nafSubnet
az network vnet subnet create \
    --resource-group $RESOURCE_GROUP \
    --vnet-name $VNET_NAME \
    --name $SUBNET_NAME \
    --delegations "Microsoft.NetApp/volumes" \
    --address-prefixes 10.0.0.0/28

 

ボリュームの作成

ボリュームを作成します。先程作成したサブネットに所属するようにします。

RESOURCE_GROUP=[MCから始まるリソースグループ名]
# ボリュームが所属するリージョンを指定します。
LOCATION=japaneast

# 先程作成したNetAppアカウント名を指定します。
ANF_ACCOUNT_NAME=naf-account

# 先程作成した容量プール名を指定します。
POOL_NAME=nafpool
# サービスプランを指定します。
SERVICE_LEVEL=Ultra

# Azure Kubernetes Clusterが所属する仮想ネットワーク名を取得します。
VNET_NAME=$(az network vnet list --resource-group $RESOURCE_GROUP --query [].name -o tsv)
# Azure Kubernetes Clusterが所属する仮想ネットワークのIDを取得します。
VNET_ID=$(az network vnet show --resource-group $RESOURCE_GROUP --name $VNET_NAME --query "id" -o tsv)
# 先程作成したサブネットの名前を指定します。
SUBNET_NAME=nafSubnet

# 先程作成したサブネットのIDを取得します。
SUBNET_ID=$(az network vnet subnet show --resource-group $RESOURCE_GROUP --vnet-name $VNET_NAME --name $SUBNET_NAME --query "id" -o tsv)
# ボリュームのサイズを指定します。
VOLUME_SIZE_GiB=100

# Azure NetApp Filesのサービス全体で、このボリュームを一意に識別するパスを指定します。
UNIQUE_FILE_PATH="naffilepath"
az netappfiles volume create \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION \
  --account-name $ANF_ACCOUNT_NAME \
  --pool-name $POOL_NAME \
  --name "nafvol" \
  --service-level $SERVICE_LEVEL \
  --vnet $VNET_ID \
  --subnet $SUBNET_ID \
  --usage-threshold $VOLUME_SIZE_GiB \
  --file-path $UNIQUE_FILE_PATH \
  --protocol-types "NFSv3"

 

作成されたボリュームのIPアドレスの確認

先程作成したボリュームに割り当てられたIPアドレスを確認します。後ほど、Azure Kubernetes Serviceからマウントするために作成するPersistentVolumeClaimを作成するために必要になります。以下のレスポンスのipAddressがボリュームに割り当てられたIPアドレスです。

az netappfiles volume show --resource-group $RESOURCE_GROUP --account-name $ANF_ACCOUNT_NAME --pool-name $POOL_NAME --volume-name "nafvol"
{
  ...
  "creationToken": "myfilepath2",
  ...
  "mountTargets": [
    {
      ...
      "ipAddress": "10.0.0.4",
      ...
    }
  ],
  ...
}

 

PersistentVolumeの作成

PersistentVolumeのマニフェストを以下のように作成します。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: naf-pv
spec:
  capacity:
    # PersistentVolumeの容量を指定します。
    storage: 100Gi
  accessModes:
    - ReadWriteMany
  nfs:
    # 先程取得したボリュームのIPアドレスを指定します。
    server: 10.0.0.4
    # ボリューム作成時に指定したUNIQUE_FILE_PATHを指定します。
    path: /naffilepath

 

PersistentVolumeClaimの作成

PersistentVolumeClaimのマニフェストを以下のように作成します。100Gのストレージを要求する例です。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: naf-pvc
spec:
  accessModes:
    - ReadWriteMany
  # storageClassNameは空で指定します。
  storageClassName: ""
  resources:
    requests:
      storage: 100Gi

 

Deploymentの作成

Podからボリュームをマウントするためのdeploymentリソースのマニフェストは以下のとおりです。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: hoge
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: httpsd:2.4.41
        ports:
        - containerPort: 80
        # マウントするための設定です。
        volumeMounts:
          # spec.template.sec.volumes.nameで定義した値を指定します。
          - name: naf-vlm
            # マウントしたいパスを指定します。
            mountPath: /var/www/html
      volumes:
      - name: naf-vlm
        persistentVolumeClaim:
          # 先ほど作成したpersistentVolumeClaimのmetadata.nameを指定します。
          claimName: naf-pvc

上記のマニフェストを実行すると、/var/www/html以下にAzure NetApp Filesのストレージがマウントされます。非常に簡単ですね。

まとめ

Azure NetApp Filesは本格的なエンタープライズ用途のストレージです。Azure Kubernetes Serviceから利用できる共有ストレージの中では最有力候補になりうるのではないかと思っております。これからもどんどん使っていきましょう(^o^)

ちなみにこちらの記事で紹介したAzure Filesを利用したときのWordPress激遅問題はAzure NetApp Filesを使うことで解決しました。

ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？

役に立った 役に立たなかった

2人がこの投稿は役に立ったと言っています。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

前の記事

KubernetesでRollingUpdateするためのPo…

次の記事

Zabbix4.4 の監視に関わりそうな新機能