27 Feb 2016, 12:30

TerraformをAzure ARMで使う時の認証

高まってまいりました

全国10,000人のTerraformファンのみなさま、こんにちは。applyしてますか。

Terraformのマイナーバージョンアップのたびに、Azure Resource Manager Providerのリソースが追加されているので、ぼちぼちClassic(Service Management)からの移行を考えよう、という人もいるのでは。VMリソースが追加されたら、いよいよ、ですかね。

そこで、Classicとは認証方式が変わっているので、ご注意を、という話です。

client_id/client_secret って何よ

以下がARM向けのProvider設定です。

# Configure the Azure Resource Manager Provider
provider "azurerm" {
  subscription_id = "..."
  client_id       = "..."
  client_secret   = "..."
  tenant_id       = "..."
}

subscription_idは、いつものあれ。tenant_idは普段使わないけどどこかで見た気がする。でも、client_id/client_secret って何よ。ためしにポータルログインで使うID/パスワード指定したら、盛大にコケた。

"The provider needs to be configured with the credentials needed to generate OAuth tokens for the ARM API."

おっとそういうことか。OAuth。

サービスプリンシパルを使おう

Terraformをアプリケーションとして登録し、そのサービスプリンシパルを作成し権限を付与すると、使えるようになります。

“アプリケーション オブジェクトおよびサービス プリンシパル オブジェクト”

“Azure リソース マネージャーでのサービス プリンシパルの認証”

以下、Azure CLIでの実行結果をのせておきます。WindowsでもMacでもLinuxでも手順は同じです。

まずは、Terraformをアプリとして登録します。–identifier-urisの存在チェックはないですが、ユニークにしなければいけません。また、–passwordはclient_secretになるので、おぼえておきましょう。

$ azure ad app create --name "My Terraform" --home-page "http://tftest.makabe.info" --identifier-uris "http://tftest.makabe.info" --password pAssw0rd%
info:    Executing command ad app create
+ Creating application My Terraform
data:    AppId:                   AppId-AppId-AppId-AppId-AppId
data:    ObjectId:                AppObjId-AppObjId-AppObjId-AppObjId
data:    DisplayName:             My Terraform
data:    IdentifierUris:          0=http://tftest.makabe.info
data:    ReplyUrls:
data:    AvailableToOtherTenants:  False
data:    AppPermissions:
data:                             claimValue:  user_impersonation
data:                             description:  Allow the application to access My Terraform on behalf of the signed-in user.
data:                             directAccessGrantTypes:
data:                             displayName:  Access My Terraform
data:                             impersonationAccessGrantTypes:  impersonated=User, impersonator=Application
data:                             isDisabled:
data:                             origin:  Application
data:                             permissionId:  AppPermID-AppPermID-AppPermID-AppPermID
data:                             resourceScopeType:  Personal
data:                             userConsentDescription:  Allow the application to access My Terraform on your behalf.
data:                             userConsentDisplayName:  Access My Terraform
data:                             lang:
info:    ad app create command OK

次にサービスプリンシパルを作ります。AppIdは先ほどアプリを登録した際に生成されたものです。

$ azure ad sp create AppId-AppId-AppId-AppId-AppId
info:    Executing command ad sp create
+ Creating service principal for application AppId-AppId-AppId-AppId-AppId
data:    Object Id:               SpObjId-SpObjId-SpObjId-SpObjId
data:    Display Name:            My Terraform
data:    Service Principal Names:
data:                             AppId-AppId-AppId-AppId-AppId
data:                             http://tftest.makabe.info
info:    ad sp create command OK

サービスプリンシパルの役割を設定します。–objectIdは、サービスプリンシパルのObject Idなのでご注意を。アプリのObject Idではありません。

この例では、サブスクリプションのContributorとして位置づけました。権限設定は慎重に。

$ azure role assignment create --objectId SpObjId-SpObjId-SpObjId-SpObjId-SpObjId -o Contributor -c /subscriptions/SubId-SubId-SubId-SubId-SubId/
info:    Executing command role assignment create
+ Finding role with specified name
/data:    RoleAssignmentId     : /subscriptions/SubId-SubId-SubId-SubId-SubId/providers/Microsoft.Authorization/roleAssignments/RoleAsId-RoleAsId-RoleAsId-RoleAsId
data:    RoleDefinitionName   : Contributor
data:    RoleDefinitionId     : RoleDefId-RoleDefId-RoleDefId-RoleDefId-RoleDefId
data:    Scope                : /subscriptions/SubId-SubId-SubId-SubId-SubId
data:    Display Name         : My Terraform
data:    SignInName           :
data:    ObjectId             : SpObjId-SpObjId-SpObjId-SpObjId-SpObjId
data:    ObjectType           : ServicePrincipal
data:
+
info:    role assignment create command OK

サービスプリンシパルまわりの設定は以上です。

テナントIDを確認しておきましょう。

$ azure account list --json
[
  {
    "id": "SubId-SubId-SubId-SubId-SubId",
    "name": "Your Subscription Name",
    "user": {
      "name": "abc@microsoft.com",
      "type": "user"
    },
    "tenantId": "TenantId-TenantId-TenantId-TenantId-TenantId",
    "state": "Enabled",
    "isDefault": true,
    "registeredProviders": [],
    "environmentName": "AzureCloud"
  }
]

これでようやく.tfファイルが書けます。さくっとリソースグループでも作ってみましょう。

# Configure the Azure Resource Manager Provider
provider "azurerm" {
  subscription_id = "SubId-SubId-SubId-SubId-SubId"
  client_id       = "AppId-AppId-AppId-AppId-AppId"
  client_secret   = "pAssw0rd%"
  tenant_id       = "TenantId-TenantId-TenantId-TenantId-TenantId"
}

# Create a resource group
resource "azurerm_resource_group" "test" {
    name     = "test"
    location = "Japan West"
}

apply。もちろんplanしましたよ。

$ terraform apply
azurerm_resource_group.test: Creating...
  location: "" => "japanwest"
  name:     "" => "test"
azurerm_resource_group.test: Creation complete

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.  

これで、ARM認証難民がうまれなくなりますように。

15 Feb 2016, 17:00

Azure DDoS対策ことはじめ

すこぶるFAQ

攻撃者の荒ぶり具合が高まっており、ご相談いただく機会が増えました。「どうすればいいか見当がつかない」というケースも少なくないので、DDoSに絞り、現時点で検討していただきたいことをシンプルにまとめます。

公式ホワイトペーパー

Microsoft Azure Network Security Whitepaper V3が、現時点でのMicrosoft公式見解です。DDoS以外にもセキュリティ関連で考慮すべきことがまとまっています。おすすめです。

今回はここから、DDoSに言及している部分を抜き出し意訳します。必要に応じて補足も入れます。

2016//3/4 追記 日本語訳がありました

2.2 Security Management and Threat Defense - Protecting against DDoS

"To protect Azure platform services, Microsoft provides a distributed denial-of-service (DDoS) defense system that is part of Azure’s continuous monitoring process, and is continually improved through penetration-testing. Azure’s DDoS defense system is designed to not only withstand attacks from the outside, but also from other Azure tenants:"

MicrosoftはDDoSを防ぐ仕組みを提供しています。Azure外部からの攻撃はもちろんのこと、Azure内部で別テナントから攻撃されることも考慮しています。

Azureがやってくれること

では、具体的に。

"1. Network-layer high volume attacks. These attacks choke network pipes and packet processing capabilities by flooding the network with packets. The Azure DDoS defense technology provides detection and mitigation techniques such as SYN cookies, rate limiting, and connection limits to help ensure that such attacks do not impact customer environments."

ネットワークレイヤで検知できる力押しは、AzureのDDoS防御システムが検知、緩和します。このホワイトペーパーのAppendixで図解されていますが、それはファイヤウォールの前段に配置され、SYN Cookieやレート制限、コネクション制限などのテクニックを使っています。

お客様対応が必要なこと

ですが、アプリケーションレイヤの攻撃は、AzureのDDoS防御システムだけでは防ぎきれません。お客様のアプリや通信の内容、要件まで踏み込めないからです。

"2. Application-layer attacks. These attacks can be launched against a customer VM. Azure does not provide mitigation or actively block network traffic affecting individual customer deployments, because the infrastructure does not interpret the expected behavior of customer applications. In this case, similar to on-premises deployments, mitigations include:"

以下のような対処が有効です。

"Running multiple VM instances behind a load-balanced Public IP address."

攻撃されるポイントを負荷分散装置のパブリックIPに限定し、複数のVMへ負荷を散らします。 攻撃されても、できる限り踏ん張るアプローチです。AzureのDDoS防御システムで緩和しきれなかったトラフィックを受け止め、ダウンしないようにします。攻撃規模は事前に判断できないので、どれだけスケールさせるかは、ダウンした場合のビジネスインパクトとコストの兼ね合いで決める必要があります。

"Using firewall proxy devices such as Web Application Firewalls (WAFs) that terminate and forward traffic to endpoints running in a VM. This provides some protection against a broad range of DoS and other attacks, such as low-rate, HTTP, and other application-layer threats. Some virtualized solutions, such as Barracuda Networks, are available that perform both intrusion detection and prevention."

WAFを入れて、通信の中身を見ないとわからない攻撃を検知、緩和します。一見ノーマルなトラフィックでも「ゆっくりと攻撃」するようなケースもあります。たとえば、ゆっくりWebサーバのコネクションを枯渇させるような攻撃などです。Azureでは仮想アプライアンスとして、Barracuda NetworksのWAFなどが使えます。

" Web Server add-ons that protect against certain DoS attacks."

Webサーバへアドインを入れましょう。パッチも適用しましょう。構成も見直しましょう。ちょっと古いですがここが参考になります。

"Network ACLs, which can prevent packets from certain IP addresses from reaching VMs."

もしブロックしたいアクセス元IPアドレスがわかるなら、ACLで遮断しましょう。逆に通信可能な範囲のみ指定することもできます。

ホワイトペーパーに加えて

CDNも有効ですので検討ください。2段構えでの負荷分散、防御ができます。Akamaiとの統合ソリューションも今後提供される予定です。

CDNは常に世界中からのトラフィックで揉まれているだけあって、DDoS防御四天王で最強の漢が最初に出てくるくらい強力です。

最後に。攻撃されている感があれば、カスタマーサポートまで。

11 Feb 2016, 12:00

Azure Blob Upload ツール別ベンチマーク

同じ目的を達成できるツールがたくさん

やりたいことがあり、それを達成する手段がたくさん。どう選ぼう。じゃあ特徴を知りましょう。という話です。

端末からAzureへファイルをアップロードする手段は多くあります。CLIツール、GUIツール、SDKで自作する、etc。

そして、端末と、そのおかれている環境も多様です。Windows、Mac。有線、無線。

で、大事なのは平行度。ブロックBlobはブロックを平行に転送する方式がとれるため、ツールが平行転送をサポートしているか? どのくらい効くのか? は重要な評価ポイントです。

なので、どのツールがおすすめ?と聞かれても、条件抜きでズバっとは答えにくい。そしてこの質問は頻出。なのでこんな記事を書いています。

環境と測定方式

おそらくファイルを送る、という用途でもっとも重視すべき特徴は転送時間でしょう。ではツール、環境別に転送時間を測定してみます。

環境は以下の通り。

  • Windows端末
    • Surface Pro 4 Core i7/16GB Memory/802.11ac
    • 1Gbps Ethernet (USB経由)
    • Windows 10 (1511)
  • Mac端末
    • Macbook 12inch Core M/8GB Memory/802.11ac
    • USB-C… 有線テストは省きます
    • El Capitan
  • Wi-Fiアクセスポイント/端末間帯域
    • 100~200Mbpsでつながっています
  • Azureデータセンタまでの接続
    • 日本マイクロソフトの品川オフィスから、首都圏にあるAzure Japan Eastリージョンに接続
    • よってWAN側の遅延、帯域ともに条件がいい
  • 対象ツール
  • 転送ファイル
    • Ubuntu 15.10 ISOイメージ (647MBytes)

そして測定方式。

AzCopyはPowerShellのMeasure-Commandにて実行時間をとります。NCが平行度指定です。デフォルトの平行度はCPUコア数の8倍です。わしのSurface、OSから4コア見えていますので、32。

Measure-Command {AzCopy /Source:C:\Users\myaccount\work /Dest:https://myaccount.blob.core.windows.net/mycontainer /DestKey:mykey /Pattern:ubuntu-15.10-server-amd64.iso /Y /NC:count}

Azure CLIも同様にMeasure-Commandで。–concurrenttaskcountで平行度を指定できますが、ソースを確認したところ、平行度のデフォルトは5です。”StorageUtil.threadsInOperation = 5;“ですね。

Measure-Command {azure storage blob upload ./ubuntu-15.10-server-amd64.iso -a myaccount -k mykey mycontainer ubuntu1510 --concurrenttaskcount count}

残念ながらMacむけAzCopyはありませんので、Azure CLIのみ実行します。timeコマンドで時間をとります。

time azure storage blob upload ./ubuntu-15.10-server-amd64.iso -a myaccount -k mykey mycontainer ubuntu1510 --concurrenttaskcount count

Azure Storage Explorer Cross Platform GUIは、目視+iPhoneのストップウォッチで。

結果

平行度上げても伸びないな、というタイミングまで上げます。

 実行No   クライアントOS   ネットワーク接続   クライアント   並行数   転送時間(秒) 
1 Windows 10 1Gbps Ethernet AzCopy (default:32) 9.62
2 Windows 10 1Gbps Ethernet AzCopy 5 12.28
3 Windows 10 1Gbps Ethernet AzCopy 10 10.83
4 Windows 10 1Gbps Ethernet AzCopy 20 10.43
5 Windows 10 1Gbps Ethernet Azure CLI (default:5) 49.92
6 Windows 10 1Gbps Ethernet Azure CLI 10 29.47
7 Windows 10 1Gbps Ethernet Azure CLI 20 21.05
8 Windows 10 1Gbps Ethernet Azure CLI 40 20.12
9 Windows 10 1Gbps Ethernet Storage Explorer N/A 50.10
10 Windows 10 802.11ac AzCopy (default:32) 74.87
11 Windows 10 802.11ac AzCopy 5 53.32
12 Windows 10 802.11ac AzCopy 10 58.85
13 Windows 10 802.11ac Azure CLI (default:5) 57.23
14 Windows 10 802.11ac Azure CLI 10 50.71
15 Windows 10 802.11ac Azure CLI 20 54.37
16 Windows 10 802.11ac Storage Explorer N/A 54.63
17 Mac OS X 802.11ac Azure CLI (default:5) 40.86
18 Mac OS X 802.11ac Azure CLI 10 33.97
19 Mac OS X 802.11ac Azure CLI 20 58.57
20 Mac OS X 802.11ac Storage Explorer N/A 58.20

考察

  • 有線AzCopy早い。単純計算で67MByte/s出ています。それぞれの計測点の解釈の違いでBlobサービス制限の60MBytes/sを超えてしまっていますがw。データセンタまでのボトルネックがなければ、ポテンシャルを引き出せることがわかります。
  • 平行度は大きく性能に影響します。
    • 平行度が高すぎてもだめ
      • 無線AzCopyのデフォルト(平行度32)が平行度10、20より時間がかかっていることからわかる
    • デフォルトで遅いからといってあきらめず、平行度変えて試してみましょう
    • SDK使って自分で作る時も同じ。平行度パラメータを意識してください
      • .NET: BlobRequestOptions
      • Java/Android: BlobRequestOptions.setConcurrentRequestCount()
      • Node.js: parallelOperationThreadCount
      • C++: blob_request_options::set_parallelism_factor
  • Azure CLIよりAzCopyが早い。
    • .NETで最適化できているから合点
    • Node.jsベースでマルチOS対応のAzure CLIは比べられると分が悪い
    • でも、802.11acでも無線がボトルネックになっているので、いまどきのWi-Fi環境では似たような性能になる
    • No.18の結果は無線状態がよかったと想定
  • Azure Storage Explorer Cross Platform GUIは、現時点で平行度変えられないので性能面では不利。でも直観的なので、使い分け。

WAN条件がいいベンチマークでなので、ぜひみなさんの条件でも試してみてください。遅延の大きなリージョンや途中に帯域ボトルネックがある条件でやると、最適な平行度が変わってくるはずです。

でも一番言いたかったのは、Macbookの有線アダプタ欲しいということです。

07 Feb 2016, 17:00

Linux on Azureでファイル共有する方法

ファイル共有、あまりおすすめしないです

いきなりタイトルを否定しました。ロック。

さて、これからクラウド、というお客様に、よく聞かれる質問があります。それは「NFSとかの、ファイル共有使える?」です。頻出です。クラウド頻出質問選手権では、西東京予選で毎年ベスト8入りするレベルの強豪校です。

ですが個人的にはあまりおすすめしません。クラウドはなるべく共有部分を減らして、スケーラブルに、かつ障害の影響範囲を局所化するべき、と考えるからです。特にストレージはボトルネックや広範囲な障害の要因になりやすい。障害事例が物語ってます。その代わりにオブジェクトストレージなど、クラウド向きの機能がおすすめです。

でも、否定はしません。アプリの作りを変えられないケースもあるかと思います。

そこで、もしAzureでファイル共有が必要であれば、Azure File Storageを検討してみてください。Azureのマネージドサービスなので、わざわざ自分でサーバたてて運用する必要がありません。楽。

対応プロトコルは、SMB2.1 or 3.0。LinuxからはNFSじゃなくSMBでつついてください。

使い方は公式ドキュメントを。

“Azure Storage での Azure CLI の使用”

“Linux で Azure File Storage を使用する方法”

もうちょっと情報欲しいですね。補足のためにわたしも流します。

Azure CLIでストレージアカウントを作成し、ファイル共有を設定

ストレージアカウントを作ります。fspocは事前に作っておいたリソースグループです。

local$ azure storage account create tomakabefspoc -l "Japan East" --type LRS -g fspoc

ストレージアカウントの接続情報を確認します。必要なのはdata: connectionstring:の行にあるAccountKey=以降の文字列です。このキーを使ってshareの作成、VMからのマウントを行うので、控えておいてください。

local$ azure storage account connectionstring show tomakabefspoc -g fspoc
info:    Executing command storage account connectionstring show
+ Getting storage account keys
data:    connectionstring: DefaultEndpointsProtocol=https;AccountName=tomakabefspoc;AccountKey=qwertyuiopasdfghjklzxcvbnm==
info:    storage account connectionstring show command OK

shareを作成します。share名はfspocshareとしました。

local$ azure storage share create -a tomakabefspoc -k qwertyuiopasdfghjklzxcvbnm== fspocshare

エンドポイントを確認しておきましょう。VMからのマウントの際に必要です。

local$ azure storage account show tomakabefspoc -g fspoc
[snip]
data:    Primary Endpoints: file https://tomakabefspoc.file.core.windows.net/

Linux * 2VMで共有

Ubuntuでやりますよ。SMBクライアントとしてcifs-utilsパッケージをインストールします。Marketplace提供の14.04 LTSであれば、すでに入ってるはずです。

fspocvm01:~$ sudo apt-get install cifs-utils

マウントポイントを作り、マウントします。接続先の指定はエンドポイント+share名で。usernameはストレージアカウント名。パスワードはストレージアカウントのキーです。 パーミッションは要件に合わせてください。

fspocvm01:~$ sudo mkdir -p /mnt/fspoc
fspocvm01:~$ sudo mount -t cifs //tomakabefspoc.file.core.windows.net/fspocshare /mnt/fspoc -o vers=3.0,username=tomakabefspoc,password=qwertyuiopasdfghjklzxcvbnm==,dir_mode=0777,file_mode=0777

マウント完了。確認用のファイルを作っておきます。

fspocvm01:~$ echo "test" > /mnt/fspoc/test.txt
fspocvm01:~$ cat /mnt/fspoc/test.txt
test

2台目のVMでも同様のマウント作業を。

fspocvm02:~$ sudo apt-get install cifs-utils
fspocvm02:~$ sudo mkdir -p /mnt/fspoc
fspocvm02:~$ sudo mount -t cifs //tomakabefspoc.file.core.windows.net/fspocshare /mnt/fspoc -o vers=3.0,username=tomakabefspoc,password=qwertyuiopasdfghjklzxcvbnm==,dir_mode=0777,file_mode=0777

1台目で作ったファイルが見えますね。

fspocvm02:~$ ls /mnt/fspoc
test.txt
fspocvm02:~$ cat /mnt/fspoc/test.txt
test

ファイルをいじりましょう。

fspocvm02:~$ echo "onemoretest" >> /mnt/fspoc/test.txt
fspocvm02:~$ cat /mnt/fspoc/test.txt
test
onemoretest

1台目から確認。

fspocvm01:~$ cat /mnt/fspoc/test.txt
test
onemoretest

ご利用は計画的に

2016年2月時点で、Azure File Storageには最大容量:5TB/share、1TB/file、ストレージアカウントあたりの帯域:60MBytes/sという制約があります。これを超えるガチ共有案件では、Lustreなど別の共有方法を検討してください。

なおファイルサーバ用途であれば、Azure File Storageではなく、OneDriveなどオンラインストレージSaaSに移行した方が幸せになれると思います。企業向けが使いやすくなってきましたし。運用から解放されるだけじゃなく、便利ですよ。

27 Jan 2016, 00:19

Linux on AzureでDisk IO性能を確保する方法

“俺の鉄板”ができるまで

前半はポエムです。おそらくこのエントリにたどり着く人の期待はLinux on AzureのDisk IO性能についてと思いますが、それは後半に書きます。

クラウド、Azureに関わらず、技術や製品の組み合わせは頭の痛い問題です。「これとこれ、組み合わせて動くの?サポートされるの?性能出るの?」という、あれです。技術や製品はどんどん進化しますので、同じ組み合わせが使えることは珍しくなってきています。

ちなみにお客様のシステムを設計する機会が多いわたしは、こんな流れで検討します。

  1. 構成要素全体を俯瞰したうえで、調査が必要な技術や製品、ポイントを整理する
    • やみくもに調べものしないように
    • 経験あるアーキテクトは実績ある組み合わせや落とし穴を多くストックしているので、ここが早い
  2. ベンダの公式資料を確認する
    • 「この使い方を推奨/サポートしています」と明記されていれば安心
    • でも星の数ほどある技術や製品との組み合わせがすべて網羅されているわけではない
    • 不明確なら早めに問い合わせる
  3. ベンダが運営しているコミュニティ上の情報を確認する
    • ベンダの正式見解ではない場合もあるが、その製品を担当する社員が書いている情報には信ぴょう性がある
  4. コミュニティや有識者の情報を確認する
    • OSSでは特に
    • 専門性を感じるサイト、人はリストしておく
  5. 動かす
    • やっぱり動かしてみないと
  6. 提案する
    • リスクがあれば明示します
  7. 問題なければ実績になる、問題があればリカバリする
    • 提案しっぱなしにせずフォローすることで、自信とパターンが増える
    • 次の案件で活きる

いまのわたしの課題は4、5です。特にOSS案件。AzureはOSSとの組み合わせを推進していて、ここ半年でぐっと情報増えたのですが、まだ物足りません。断片的な情報を集め、仮説を立て、動かす機会が多い。なので、5を増やして、4の提供者側にならんとなぁ、と。

Linux on AzureでDisk IO性能を確保する方法

さて今回の主題です。

結論: Linux on AzureでDisk IOを最大化するには、MDによるストライピングがおすすめ。いくつかパラメータを意識する。

Linux on AzureでDisk IO性能を必要とする案件がありました。検討したアイデアは、SSDを採用したPremium Storageを複数束ねてのストライピングです。Premium Storageはディスクあたり5,000IOPSを期待できます。でも、それで足りない恐れがありました。なので複数並べて平行アクセスし、性能を稼ぐ作戦です。

サーバ側でのソフトウェアストライピングは古くからあるテクニックで、ハードの能力でブン殴れそうなハイエンドUnixサーバとハイエンドディスクアレイを組み合わせた案件でも、匠の技として使われています。キャッシュやアレイコントローラ頼りではなく、明示的にアクセスを分散することで性能を確保することができます。

Linuxで使える代表的なストライプ実装は、LVMとMD。

ではAzure上でどちらがを選択すべきでしょう。この案件では性能が優先事項です。わたしはその時点で判断材料を持っていませんでした。要調査。この絞り込みまでが前半ポエムの1です。

前半ポエムの2、3はググ、もといBing力が試される段階です。わたしは以下の情報にたどり着きました。

“Configure Software RAID on Linux”

“Premium Storage: Azure 仮想マシン ワークロード向けの高パフォーマンス ストレージ”

“Azure Storage secrets and Linux I/O optimizations”

得られた情報の中で大事なのは、

  • 公式ドキュメントで
    • LVMではなくMDを使った構成例が紹介されている
  • マイクロソフトがホストするブログ(MSDN)で、エキスパートが
    • LVMと比較したうえで、MDをすすめている
    • MDのChunkサイズについて推奨値を紹介している
    • そのほか、ファイルシステムやスケジューラに関する有益な情報あり

なるほど。わたしのこの時点での方針はこうです。

  • LVMを使う必然性はないため、MDに絞る
    • LVMのほうが機能豊富だが、目的はストライピングだけであるため、シンプルなほうを
    • 物理障害対策はAzureに任せる (3コピー)
  • MDのChunkをデフォルトの512KBから64KBに変更する (ここは結果によって調整)
  • Premium StorageのキャッシュはReadOnly or Noneにする予定であるため、ファイルシステムのバリアを無効にする

上記シナリオで、ディスク当たり5,000IOPS、ストライプ数に比例した性能が実際出れば提案価値あり、ということになります。 ですが、ズバリな実績値が見つからない。ダラダラ探すのは時間の無駄。これは自分でやるしかない。

構成手順は前述のリンク先にありますが、ポイントを抜き出します。OS=Ubuntu、ファイルシステム=ext4の場合です。

MDでストライプを作る際、チャンクを64KBに変更します。

sudo mdadm --create /dev/md127 --level 0 --raid-devices 2  /dev/sdc1 /dev/sdd1 -c 64k

マウント時にバリアを無効にします。

sudo mount /dev/md127 /mnt -o barrier=0

では、Premium Storage(P30)をMDで2つ束ねたストライプにfioを実行してみましょう。

  • 100% Random Read
  • キャッシュ効果のないデータをとるため、Premium StorageのキャッシュはNone、fio側もdirect=1
  • ブロックサイズは小さめの値が欲しかったので、1K

結果。

randread: (g=0): rw=randread, bs=1K-1K/1K-1K/1K-1K, ioengine=libaio, iodepth=32
fio-2.1.3
Starting 1 process

randread: (groupid=0, jobs=1): err= 0: pid=9193: Tue Jan 26 05:48:09 2016
  read : io=102400KB, bw=9912.9KB/s, iops=9912, runt= 10330msec
[snip]

2本束ねて9,912IOPS。1本あたりほぼ5,000IOPS。ほぼ期待値。