More than 5 years have passed since last update.

Microsoft Azure TechAdvent Calendar 2017

@tsubasaxZZZ(Nomura Tsubasa)

Azure の Managed Disk のまとめ

Last updated at 2017-12-23Posted at 2017-02-09

以前の記事からかなり時間が経ってしまいましたが、そろそろナレッジも増えてきたため、大幅アップデートしました。

■概要

ストレージは Azure 側で管理され、ストレージプールのような使い方が出来る
従来仮想マシンの作成で必須だったストレージアカウントが不要に
IOPS の制限がなくなる
VMSS でも使える
Managed Disk から VHD へエクスポートが可能
イメージ・スナップショットの作成が可能
さらにそのイメージ・スナップショットから仮想マシンの作成が可能
RBACとも連携できる

■管理ディスクのメリット

シンプル＆スケーラブル

何はともあれ、初めに管理ディスクを使った仮想マシンの作り方を見てみましょう。
Azure ポータルからの作り方はとても簡単で、仮想マシンの作成画面のストレージの、[管理ディスクを使用]を**[はい]**にするだけです。

ちなみに、これを[いいえ]にすると、従来のストレージアカウントを使用しますので、
ストレージアカウントを選択(もしくは新規作成)する画面が出てきます。

Azure ポータルから仮想マシンを作成する方法だけ見ると、従来の仮想マシンの作り方とほとんど変わらず、何が変わったのか分からないと思います。

実際に、管理ディスクのシンプルさ＆スケーラブルさを感じるのは、
ARM テンプレートや PowerShell を使用し一度に複数台の仮想マシンを作るとき等の展開の場面、また、ディスクの容量を増やしたり種類を変えたりするとき等の運用の場面 といった、仮想マシンの展開や構築、運用をする場面です。

具体的にどのような点が便利になったのか見ていきましょう。

ARM テンプレートで管理ディスクを使った仮想マシンを展開する

上で書いたとおり、従来では、ストレージアカウントという概念が存在し、まずはストレージアカウントを作ってから、その中に VHD を作成するという方法で実現されていました。
必然的に、ストレージアカウントを作成するためのテンプレートが必要になり、resources の記載も複雑になります。

ストレージアカウントを使ったテンプレート

"resources": [
  /*******************************/
  /*始めにストレージアカウントを作る*/
  /*******************************/
  {
    "comments": "# Storage Account",
    "name": "[variables('StorageAccountName')]",
    "type": "Microsoft.Storage/storageAccounts",
    "location": "[resourceGroup().location]",
    "apiVersion": "2015-06-15",
    "dependsOn": [ ],
    "tags": {
      "displayName": "StorageAccount"
    },
    "properties": {
      "accountType": "[variables('StorageAccountType')]"
    }
  },
.
.
.
  /********************/
  /*仮想マシンのリソース*/
  /********************/
  {
    "comments": "# TRANSFER VM",
    "name": "[variables('vmNames')[0]]",
    "type": "Microsoft.Compute/virtualMachines",
    "location": "[resourceGroup().location]",
    "apiVersion": "2015-06-15",
    "dependsOn": [
      /*ストレージアカウントとの依存関係を定義*/
      "[concat('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
      "[concat('Microsoft.Network/networkInterfaces/', variables('vmNames')[0],'NIC')]"
    ],
    "imageReference": {
      "publisher": "[variables('imagePublisher')]",
      "offer": "[variables('imageOffer')]",
      "sku": "[variables('windowsOSVersion')]",
      "version": "latest"
    },
    "osDisk": {
      "name": "[concat(variables('vmNames')[0],'-osdisk')]",
      "vhd": {
      /*******************************************/
      /*ストレージアカウントの中にあるVDHのURLを指定*/
      /*******************************************/

      "uri": "[concat('http://', variables('storageAccountName'), '.blob.core.windows.net/', variables('vhdStorageAccountContainerName'), '/',variables('vmNames')[0],'-osdisk' , '.vhd')]"
      },
    "caching": "ReadWrite",
    "createOption": "FromImage"
  }

一方、管理ディスクを使った場合、リソースタイプとして diskを使った文字通りディスクが使えるようになるので、ストレージアカウントの様な回りくどいことをしなくてよくなります。

管理ディスクを使ったテンプレートを見てみましょう。

ストレージアカウントを使ったテンプレート

/*仮想マシンの一部を抜粋*/
"storageProfile": {
  "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "[parameters('windowsOSVersion')]",
    "version": "latest"
  },
  "osDisk": {
    "createOption": "FromImage" //イメージから作る。これだけ。
  },

これまでは、オブジェクトストレージとして表面上に見えていたディスク(VHD)ですが、新たな disk としてリソースタイプが定義されたことによって、使いやすくシンプルになったものが 管理ディスク です。

ストレージアカウントの制限がなくなる

上記で書いたように、管理ディスクは、これまでのストレージアカウントの管理が不要になりました。
つまりそれは、ストレージアカウントの制限を受けなくなる、という意味にもなります。
※制限が無くなるわけではありません。

ストレージアカウントの制限でよくあるのは、IOPS です。
1つのストレージアカウントに複数の仮想マシンの VHD を格納することはよくありますが、そこで注意しないといけないのは、ストレージアカウントの20000 IOPS という IOPSの上限です。

この上限があることで、例えば、高 IOPS を出すために、複数のデータディスクを束ねて使う場合、ストレージアカウントも複数作成し、その中にある VHD を接続するという、管理面で面倒な方法をとらざるを得ませんでした。

管理ディスクにすることで、そのようなストレージアカウントの制限を受けず、ディスクを接続したい場合に、管理ディスクを作って仮想マシンに接続、という非常にシンプルな操作で実現できるようになります。

ちなみに、管理ディスクでは、SSD(Premium)とHDD(Standard)でそれぞれリージョンごとに、10,000 個の上限(既定)があります。

ディスクの容量変更と種類の変更

こちらはとても分かりやすいです。
これまで、ストレージアカウントの種類(SSD/Premium、HDD/Standard)は、作成時に決めるものであり一度展開した後(仮想マシンを作った後)は、容易に切り替えることが出来ませんでした。切り替えには、別にストレージアカウントを作り、AzCopy 等で VHD をコピーし、その VHD から仮想マシンを起動するという手順が必要でした。

管理ディスクを使うと、SSD と HDD の切り替えがプルダウン一つで切り替えられます。
※ただし、仮想マシンを停止しておく必要があります。また、仮想マシンのサイズによって、SSD しか使えないサイズ、HDD しか使えないサイズがあります。

また、サイズの変更も数字を変えるだけです。

補足 : リソースプロバイダーやリソースタイプって？

シンプルさを実現しているのが、リソースタイプとして、管理ディスクを表現するdiskが登場したことです。

少し Azure の中の話しになりますが、現在の Azure は、ARM という API を使用しています。
この ARM では、例えば仮想マシンや、ディスクといったリソースを表す場合、リソースプロバイダー や リソースタイプというもので表されます。

言葉だけ並べてもよくわからないと思うので、Azure ポータルの仮想マシンの概要を表示している URL を見てみましょう。
実は、Azure のポータルでも、この ARM の API を垣間見ることが出来ます。

上の絵であるように、Azure のすべてのリソースの一意性は、サブスクリプションID、リソースグループ名、リソースプロバイダー、リソースタイプ、リソース名 で保証されています。

そして、ストレージアカウント(Microsoft.Storage。正確にはその中のstorageAccountsタイプ) や 仮想マシン(Microsoft.Compute) は、リソースプロバイダーとして存在しており、管理ディスクは、仮想マシンのリソースの1つ(Microsoft.Compute/disks)として、存在しています。

ちなみに、どのリソースプロバイダーに、どういうリソースタイプが存在するのかというのは、PowerShell や Azure CLI で見ることが出来ます。

プロバイダーの一覧

PS C:\Users\tsunomur> Get-AzureRmResourceProvider -ProviderNamespace Microsoft.Compute | ft

ProviderNamespace RegistrationState ResourceTypes                                               Locations                                                        ZoneMappings
----------------- ----------------- -------------                                               ---------                                                        ------------
Microsoft.Compute Registered        {availabilitySets}                                          {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {virtualMachines}                                           {East US, West US, North Central US, South Central US...}
Microsoft.Compute Registered        {virtualMachines/extensions}                                {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {virtualMachineScaleSets}                                   {East US, West US, North Central US, South Central US...}
Microsoft.Compute Registered        {virtualMachineScaleSets/extensions}                        {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {virtualMachineScaleSets/virtualMachines}                   {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {virtualMachineScaleSets/networkInterfaces}                 {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {virtualMachineScaleSets/virtualMachines/networkInterfaces} {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {virtualMachineScaleSets/publicIPAddresses}                 {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {locations}                                                 {}
Microsoft.Compute Registered        {locations/operations}                                      {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {locations/vmSizes}                                         {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {locations/runCommands}                                     {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {locations/usages}                                          {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {locations/virtualMachines}                                 {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {locations/publishers}                                      {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {operations}                                                {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {restorePointCollections}                                   {Southeast Asia, East US 2, Central US, West Europe...}
Microsoft.Compute Registered        {restorePointCollections/restorePoints}                     {Southeast Asia, East US 2, Central US, West Europe...}
Microsoft.Compute Registered        {virtualMachines/diagnosticSettings}                        {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {virtualMachines/metricDefinitions}                         {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {disks}                                                     {Southeast Asia, East US, North Central US, South Central US...}
# ----------------------------------   ↑この disks が管理ディスクです。  ----------------------------------
Microsoft.Compute Registered        {snapshots}                                                 {Southeast Asia, East US 2, Central US, West Europe...}
Microsoft.Compute Registered        {locations/diskoperations}                                  {Southeast Asia, East US 2, Central US, West Europe...}
Microsoft.Compute Registered        {images}                                                    {Southeast Asia, East US 2, Central US, West Europe...}

信頼性の向上

まず、従来のストレージアカウントを利用した場合の、仮想マシンの可用性セットの関係です。
こちらのドキュメントに記載があります。

Azure Storage のレプリケーション
https://docs.microsoft.com/ja-jp/azure/storage/common/storage-redundancy

ポイントはこちらです。

1つのデータは、1つのストレージスケールユニット内でデータがレプリケート
ストレージスケールユニットは、ストレージノードのコレクション
ストレージスケールユニット内で、障害ドメインと更新ドメインが存在

仮想マシンとも関連させて、絵にするとこのような形です。

ストレージアカウント(非管理ディスク)の場合

一方で、管理ディスクを利用した場合です。

Azure VM を Azure Managed Disks に移行する
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/migrate-to-managed-disks

ポイントはこちらです。

可用性セットが分かれると、ストレージスケールユニットが分離

つまり、仮想マシンの可用性セットとの関係で、下の様になります。
管理ディスクの場合

つまり、管理ディスクを使用することで、ストレージアカウント(非管理ディスク)の場合と比べ、ストレージ部分の信頼性が向上する場合があります。
※ここで、ストレージアカウント(非管理ディスク)の信頼性が低い、と単純には言えません。
管理ディスクのストレージスケールユニットはリージョンによって数が異なったり、ストレージアカウントには、管理ディスクにないGRS(地理冗長)の機能があります。

アクセス制御

ストレージアカウントは、作成すると、自動的にエンドポイント(URL)が用意されます。
例えば、domain1diag912というストレージアカウントを作った場合、以下の様に、https://domain1diag912.blob.core.windows.net/というURLが付与されます。

これは、ストレージアカウントはクラウド上のオブジェクトストレージであり、アクセスできる方法を確保しないといけないため、必然といえます。
しかし、仮想マシンを作成する上では、逆にそれによって、セキュリティの懸念が持たれます。

もちろん、仮想マシンを作成して、VHDができたとしても、ストレージアカウントのアクセス制御である Shared Access Signatures (SAS) により、誰でも VHD が外から見えるわけではありません。ただ、万が一アクセス制御の操作をあえて行い、誤った設定にした場合、VHD がインターネット上に晒されることになります。

ストレージアカウントのアクセス制御を絵にするとこんな感じです。

一方、管理ディスクでは、上記の通り リソースタイプの一つとして提供されるため、Azure の RBAC の機能によって、詳細にアクセス制御を行うことが出来ます。

つまりこうなります。

管理ディスクのアクセス制御

あえて、エクスポート操作をしない限り、管理ディスクがエンドポイントを持つことはありません。

ちなみに、管理ディスクのメニューを見ると、ちゃんとアクセス制御のメニューが出てきます。

価格と課金

管理ディスクの料金のポイントをまとめてみました。

ストレージの種類
- SSD(Premium) と HDD(Standard) で料金が異なる
ディスクサイズ
- SSD も HDD も、使用している実容量ではなく、管理ディスクとして確保した(プロビジョニングされた)容量で課金される
  - 非管理ディスクは、HDD に関しては実容量ベースで課金されていました
- SKU 毎に定められた容量よりも小さい場合は、切り上げて課金される
  - 例えば、50 GB の SSD を作成した場合、P6(64 GB)として課金される
トランザクション数
- HDD は、容量の課金以外にも、トランザクション数に対しても課金されます
  - これは非管理ディスクと同じです。また、SSD の管理ディスクはトランザクション数への課金はありません
送信データ転送
- Azure データセンターから送信方向に対するトラフィックに対して課金される
  - これも非管理ディスクと同じです。
管理ディスクスナップショット
- 管理ディスクではスナップショットが作れます。スナップショットに対しては、使用している容量のみに対する課金になります。