大和屋貴仁

ネタ元：Use port pings instead of ICMP to test Azure VM connectivity

ICMPプロトコルは、Azureのロードバランサーで許可されていないので、インターネットやAzure 仮想マシン内からAzure仮想マシンにpingをしても結果を取得できません。

エンドポイントを設定して、エクスターナルのIPを使用するネットワークトラフィックの場合の話で、Azure仮想ネットワークゲートウェイやExpressRouteを使って接続するときには、ICMPはブロックされません。

接続テストをするには、代わりにポートPingを使用することをお勧めします。
Ping.exeはICMPを使用するので、特定のTCPポートにpingできるPsPing, Nmap, or Telnetのようなツールを使用します。

たとえば、Azure仮想マシン内からyahoo.comにpingするとリクエストタイムアウトします。これは、AzureロードバランサーでICMPがブロックされているからです。

C:\>ping yahoo.com

Pinging yahoo.com [206.190.36.45] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 206.190.36.45:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

しかし、特定のポートに接続テストができるSysinternalツールのPsPingを使用して、Azure仮想マシンからインターネット上のサイトの80番ポートにテストをすると成功します。

C:\Users\craig\Downloads\PSTools>psping yahoo.com:80

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 206.190.36.45:80:
5 iterations (warmup 1) connecting test:
Connecting to 206.190.36.45:80 (warmup): 53.25ms
Connecting to 206.190.36.45:80: 52.26ms
Connecting to 206.190.36.45:80: 52.14ms
Connecting to 206.190.36.45:80: 52.32ms
Connecting to 206.190.36.45:80: 51.48ms

TCP connect statistics for 206.190.36.45:80:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 51.48ms, Maximum = 52.32ms, Average = 52.05ms

ちなみに、bing.comへのICMP pingだけは例外的に動作します。BingとAzureは両方マイクロソフトが提供するからです。

C:\Users\craig\Downloads\PSTools>psping bing.com

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

Pinging 204.79.197.200 with 32 bytes of data:
5 iterations (warmup 1) ping test:
Reply from 204.79.197.200: 6.85ms
Reply from 204.79.197.200: 2.47ms
Reply from 204.79.197.200: 2.30ms
Reply from 204.79.197.200: 2.95ms
Reply from 204.79.197.200: 2.39ms

Ping statistics for 204.79.197.200:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 2.30ms, Maximum = 2.95ms, Average = 2.53ms

オンプレミスからAzure仮想マシンにテストをすると、同様の結果となります。ICMPトラフィックは、Azureロードバランサーでブロックされ、pingはタイムアウトします。しかし、代わりにポートpingをすれば、仮想マシンが起動していてファイヤーウォールでポートブロックされていなくてエンドポイントがされていれば、成功します。

C:\>ping CLJun21WS12R2A.cloudapp.net

Pinging CLJun21WS12R2A.cloudapp.net [23.100.76.67] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 23.100.76.67:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\>psping CLJun21WS12R2A.cloudapp.net:56972

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 23.100.76.67:56972:
5 iterations (warmup 1) connecting test:
Connecting to 23.100.76.67:56972 (warmup): 60.44ms
Connecting to 23.100.76.67:56972: 61.28ms
Connecting to 23.100.76.67:56972: 63.41ms
Connecting to 23.100.76.67:56972: 63.69ms
Connecting to 23.100.76.67:56972: 60.41ms

TCP connect statistics for 23.100.76.67:56972:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 60.41ms, Maximum = 63.69ms, Average = 62.20ms

C:\>psping CLJun21WS12R2A.cloudapp.net:5986

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 23.100.76.67:5986:
5 iterations (warmup 1) connecting test:
Connecting to 23.100.76.67:5986 (warmup): 61.49ms
Connecting to 23.100.76.67:5986: 65.29ms
Connecting to 23.100.76.67:5986: 67.08ms
Connecting to 23.100.76.67:5986: 62.70ms
Connecting to 23.100.76.67:5986: 60.99ms

TCP connect statistics for 23.100.76.67:5986:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 60.99ms, Maximum = 67.08ms, Average = 64.02ms

Azure Fridayで、「Adding Web Tests to an Azure Web Site」が公開されていたので紹介する。

Web Testsは、世界各地にあるAzure Dcから、指定したURLにアクセスをして、正常にアクセスできるかどうかをテストするための仕組み。

Web Testsを追加するには、Webサイトの詳細画面にある「Webtests」をクリックする。

 

そーすると、すでにWebTestsを設定済みな実行結果が表示される。

 

時間帯ごとの実行結果が表示される。レスポンスタイムも表示され、それをクリックするとさらに詳細と、エラーある場合はエラー内容が表示される。

 

新規にWebTestsを追加する。WebTests名とチェックするURLとテスト元のDCを指定する。

 

DCは、こんな一覧から選択する。

 

テストでOKとする、HTTPステータスと、レスポンスに含まれていないといけない文字列があれば、それを指定する。下の画面だと「Developer」ですね。

 

テストがこけたら通知する宛先とテストレベルを指定する。
テストレベルは、「Sensitivity settings: 1= Low alerts you when all locations fail within 15 minutes. 2 = Medium alerts when half of locations fail in 10 minutes. 3 = High alerts any time a test fails.」とのこと。

Azure Frydayで「Adding Analytics to Azure Web Sites」が公開されていたので紹介する。

ポータルで、Webサイトを選択し、「Analytics」をクリックする。

 

すると、埋め込むためのJava Scriptが表示されるので、それをコピーしてサイトのソースに追加しておく。

 

そーすると、データ収集が行われ記録される。グラフをクリックすると詳細な情報が表示される。

 

右上の全画面表示ボタンをクリックすると、全画面に表示される。

 

左上から順番に、アクセスに使用されたブラウザの種類と比率、デバイスの種類と比率、PVグラフ、表示が遅いページ一覧などが表示される。

 

PVグラフをクリックすると、URL別のアクセス数が表示される。

 

表示が遅いページ一覧をクリックすると、URL別の表示時間数と表示数一覧とグラフが表示される。

 

リクエストとエラー数グラフをクリックすると、表示クエリを設定できる。

 

 

詳細な性能情報を確認できる。

 

ここからアラート通知ルールを追加できる。

 

アラート状況は、Webサイトの詳細画面の下部から確認できる。

 

こーいうポータルがあると、開発者がいろいろと調整するには便利ですね。オンプレミス環境下でも、こういうダッシュボードを用意できると幸せになれそう。（Azure Packかなぁ…

Linux Kernel CIFSクライアントを使用して、LinuxからAzure File 共有を使用することができます。カーネルクライアントでSMB 2.1を使用できるように設定しないといけません。

ビルド時にカーネル設定で、CONFIG_CIFS_SMB2を有効にします。

# zcat /proc/config.gz | grep CONFIG_CIFS_SMB2

マウント時に、mount.cifsパラメーターでvers=2.1を指定します。

# mount.cifs -o vers=2.1,user=smb //smb.file.core.windows.net/share /share/
  
Password for smb@//smb.file.core.windows.net/share:  ******...

  
# mount.cifs -o vers=2.1,user=smb //smb.file.core.windows.net/share /share/
Password for smb@//smb.file.core.windows.net/share:  ******...
# df -h /share/
Filesystem                         Size  Used Avail Use% Mounted on
//smb.file.core.windows.net/share  5.0T     0  5.0T   0% /share/pre>

間もなくリリース予定のSUSE Linux Enterprise Server 12では、この機能に対応していて、openSuseでも利用可能になる予定です。

元ネタ；Using the Azure File Service on Linux

Microsoft Azure Universal Storage for SQL Server 2014で、どのストレージを使用すべきなのかを考察した結果が投稿されていたので概要を紹介する。

ストレージの種類

Azure仮想マシン内で、SQL Serverを使用するときに設定するストレージとして、三種類のストレージ（Azure File、Azure Disks、Azure Blob）が候補にあがる。
では、どのストレージを使用すべきなのかを検討した結果が、元記事のお話。

結論

大きなストレージのIOPSが必要なら、Azure Data Disk。
もっとファイル容量が必要なら、Azure Blob。

AlwaysOn Availability Groupやアプリケーションがトラフィックを必要とするようなネットワーク帯域が重要な場合は、Azure FileかAzure Blob。

SQL Server 2014では、Azure Data Diskよりも直接スケールするAzure Blobを使用できるので、Azure Fileを使用する理由が見つからない。

SQL Server 2012では、Azure Blobがサポートされていないので、IOPSやデータ領域が必要な場合は、Azure Fileの使用を検討から除外することはできない。

各ストレージの比較

それぞれの具体的な検討過程や、SQL Serverからどのようなアーキテクチャでストレージが使用されるかなどは、元記事で説明されている。