Azure仮想マシンでUnixBenchを取ってみた
わりと微妙なベンチマークが身内で話題になっていたので、せっかくなので実測してみました。 1コアのインスタンスでUnixBenchを走らせてみた結果です。 OSは Ubuntu Server 14.04 LTS です。
テスト項目 | Standard_A1 | Standard_DS1 | Standard_DS1v2 |
---|---|---|---|
Dhrystone 2 using register variables | 1224.4 | 2047.9 | 2752.8 |
Double-Precision Whetstone | 312.4 | 521.4 | 763.4 |
Execl Throughput | 535.4 | 898.9 | 1448.1 |
File Copy 1024 bufsize 2000 maxblocks | 1215.2 | 2071 | 3084.7 |
File Copy 256 bufsize 500 maxblocks | 802.1 | 1335.3 | 1951 |
File Copy 4096 bufsize 8000 maxblocks | 2107.6 | 3948.9 | 6319.2 |
Pipe Throughput | 671.9 | 1112.8 | 1680.3 |
Pipe-based Context Switching | 403.4 | 615 | 914.1 |
Process Creation | 512.9 | 848.2 | 1399 |
Shell Scripts (1 concurrent) | 923.3 | 1566.8 | 2420 |
Shell Scripts (8 concurrent) | 874.4 | 1457.4 | 2239.1 |
System Call Overhead | 1210.1 | 2114.3 | 2930.2 |
System Benchmarks Index Score: | 787.8 | 1325.4 | 1993.9 |
一応書いておくと、各インスタンスのスペックはこんな感じです。売り文句より実測値の方がちょっと速めですね。
- A1・・・1コア、1.75GBメモリ
- DS1・・・1コア、3GBメモリ(Aシリーズより60%早いのが売り)
- DS1v2・・・1コア、3GBメモリ(Dシリーズより35%早いのが売り)
DSのv2シリーズ、早く日本に来ませんかねー。Dシリーズより早い上に安いんですよね。
Azure PowerShellで仮想マシンV2を作成する (SysprepしたVHDから)
という記事を読みましたので、Sysprepした方のVHDからv2仮想マシンを生成するPowerShellスクリプトも置いておきます。
VM本体を構成するだけのスクリプトなので、各種コンポーネントはあらかじめ作っておいて下さい。 以下のものがあらかじめ用意されている前提のスクリプトになっています。 * リソースグループ * ストレージアカウント * 仮想ネットワークとサブネット * NIC * 可用性セット * (必要に応じて)ロードバランサーとパブリックIPアドレス * Sysprep されたVHDファイル
特殊化VHD(Sysprepしていない)との大きく違うところは、置いてあるVHDをそのまま仮想マシンに接続するのではないというところでしょうか。 「-VhdUri」で指定したところに新たなVHDファイルが作られます。
# Azureアカウントへログイン Login-AzureRmAccount # サブスクリプションの指定 $SubscriptionId = '[Subscription ID]' Get-AzureRmSubscription -SubscriptionId $SubscriptionId | Select-AzureRmSubscription # リソースグループの指定 $ResourceGroupName = '[Resource Group Name]' # OSディスク情報の指定(Syspreped / Generalized VHDから生成する場合) $StorageAccountName = '[Storage Account Name]' $Caching = '[Disk Cache Mode]' $CreateOption = 'fromimage' $osDiskSourceImageUri = '[Source VHD Uri]' $vhdUri = "[OS Disk VHD Uri]" # 仮想マシンの構成情報 $vmName = '[VM Name]' $vmSize = '[VM Size]' $cred = Get-Credential $Location = (Get-AzureRmStorageAccount -Name $StorageAccountName -ResourceGroupName $ResourceGroupName).Location # 可用性セットの構成情報 $AvailabilitySetName = '[Availability Set Name]' $vmAs = Get-AzureRmAvailabilitySet -ResourceGroupName $ResourceGroupName -Name $AvailabilitySetName # NICの指定 $NicName = '[NIC Name]' $nic = Get-AzureRmNetworkInterface -Name $NicName -ResourceGroupName $ResourceGroupName # VM構成情報の組立 $vm = New-AzureRmVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetId $vmAs.Id $vm = Set-AzureRmVMOperatingSystem -ComputerName $vmName -Credential $cred -VM $vm -Windows $vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.id $vm = Set-AzureRmVMOSDisk -VM $vm -SourceImageUri $osDiskSourceImageUri -VhdUri $vhdUri -Name $vmName -CreateOption $CreateOption -Caching $Caching -Windows # VMのデプロイ New-AzureRmVM -ResourceGroupName $ResourceGroupName -Location $Location -VM $vm
ちなみに、Sysprepしてない手順でSysprepしたVHDから仮想マシンを作ると、「国または地域」などを指定する画面で止まってしまって悲しいことになります。
おまけで、仮想マシンのキャプチャを行うPowerShellスクリプトはこちらです。Sysprepだったり、Linuxの場合は sudo waagent -deprovision+user だったりは事前に各自で行って下さい。
$ResourceGroupName = '[Resource Group name]' $vmName = '[VM Name]' $DestinationContainerName = '[Destination Blob Container Name]' $VHDNamePrefix = '[Vhd Prefix]' # 仮想マシンの汎用化 Set-AzureRmVM -ResourceGroupName $ResourceGroupName -Name $vmName -Generalized # キャプチャの実行 Save-AzureRmVMImage -DestinationContainerName $DestinationContainerName -Name $vmName -ResourceGroupName $ResourceGroupName -VHDNamePrefix $VHDNamePrefix
JSONテンプレートを触った方が楽なケースが多いとは思いますが、用途によってはということで。
Azure Cool Blob storage を触ってみました
Azure Cool Blob storage が GA しましたので、軽く触ってみました。
General availability: Azure Cool Blob storage
AWSの「Glacier」やGoogleの「Nearline」相当のサービスになるかと思います。 パフォーマンスが同じ、というのが特徴でしょうか。
(2016/07/15 追記) って書いたんですが、AWSGlacierというよりStandard-IAの方ですね:
特徴
- 互換性: 100%同じAPI。
- パフォーマンス: レイテンシ、スループットとも同じ。
- 可用性: Coolは99%、Hotは99.9% (RA-GRSは別)。
- 既存ストレージアカウントからの移行は出来ない。
- 対象はBLOBのみ。BLOBのみのストレージアカウントを新たに作る。
- あらかじめHOT/COOLを指定して作ったストレージアカウントであれば、後から変更可能。
- LRS,GRSなども後から変更可能。
- 当然ですが、Premium Storage は対象外。
- 今のところ、Azure Backup の保存先には選べないようです。
料金について
- 容量当たりの単価は安い(東日本、100Tまでで約37%off)。
- 割引率はLRS, GRS, RA-GRS ともほぼ同じ。
- 容量が増えると割引率が低くなる(100Tまで 37% → 900TBまで 35% → 4,000TBまで 33%)
- トランザクション課金はCOOLの方が高い(倍)。
作り方
- 新規にストレージアカウントを作るのと同じ
- Classic モデルでは作成出来ない。ARMのみ。
- Account kind (アカウントの種類)から「Blob storage」を指定して作成。
用途によってはしばらく割高感のあったAzureのストレージでしたが、これでまた値頃感が出てきましたね。 Azure Backup が対応してくれると更に嬉しいところです。
Azure Hybrid Use Benefit(HUB) の使い方
ライセンス周りのネタですが、Azure Hybrid Use Benefit(HUB) の具体的な使い方が日本語で公開されていました。 Windows OSのSAを持っていれば、Azure VM利用時にWindowsライセンスの利用料が削減できるというアレですね。
Azure Hybrid Use Benefit の使用方法 | Cloud and Server Product Japan Blog blogs.technet.microsoft.com
が、いま見たら、Cloud and Server Product Japan Blog がひととおり文字化けしているようなので英語の方も貼っておきます。 How can I use the Hybrid Use Benefit in Azure? | Azure in Education
具体的には、デプロイ時にLicenseTypeを「Windows_Server」を指定するということのようです。 既存の Azure VM からコンバートする場合、VHDから作り直しになるなど細かい点は注意が必要ですね。
▼PowerShellの例
New-AzureRmVM -ResourceGroupName $ResourceGroupName -Location $LocationName –LicenseType “Windows_Server” -VM $VirtualMachine -Verbose
▼JSONテンプレートの例
“properties”: { “licenseType”: “Windows_Server”,
Web Appsにデプロイしたnode.jsアプリが500エラーになる時の対処
いつも通りにGitHubからnode.jsのアプリをデプロイしたら500エラーになってしまってしばらくあたふたしたのでメモしておきます。
症状
- Web Apps のステージング用スロットに GitHub からデプロイしたら500エラーが発生。
- 別のスロットにデプロイした同じソースはちゃんと動いている。
- Kudu からログを見ると「Error: Cannot find module 'debug'」といった感じで、モジュールが足りない模様。
対処
- Kudu から node_modules ディレクトリを消す。
- npm install
今回はこれで無事復活しました。
(参考URL) stackoverflow.com
Office 365 の多要素認証にGoogle Authenticatorを使う
Azure AD が OATH に対応したということで、Office 365 にログインするときの多要素認証に Google Authenticator が使えるようになったので手順をメモしておきます。
- Office 365 にログインする https://portal.office.com/Home
- 右上の歯車から「Office 365 の設定」を選ぶ。
- 左のメニューから「設定」を選ぶ(通常は選ばれているはず)。
- 「追加のセキュリティ検証」をクリックする。
- 下に開くので「アカウントのセキュリティ検証に使用する電話番号を更新します。」をクリックする。
- 「既定ではこの確認オプションが使用されます。」のプルダウンで「アプリの確認コードを使用する」を選ぶ。
- 「応答に使用する方法を選択してください。」から「Azure Authenticator アプリ」にチェックを入れ、「構成」をクリック。
- QRコードのページが表示されたら、まず「通知をオフにしてアプリを構成」をクリックして、表示されたQRコードを Google Authenticator でスキャンして追加する。
あとは画面なりに進めて下さい。 次回ログインのMFAから Google Authenticator が使えるはずです。
Premium Storage が付いた仮想マシンもバックアップ出来るようになっていました
いつのまにか Premium Storage を接続した仮想マシンもバックアップ出来るようになっていました(プレビュー)。
手順はサイトに案内されているとおりなので、特に迷うところは無いかと思います。
ポータルを日本語で使っている場合、名前が「Recovery Services コンテナー」となりますのでご注意を。英語だと「Recovery Services Vault」です。いずれにしても、Backupうんたら〜ではないので、なんとなく探そうと思うと毎回迷います。
ドキュメントにも書いてあるとおり、バックアップ時は、同じストレージアカウント内にいったん「AzureBackup-」というPrefixのコンテナーが作られ、その中にVHDを複製します。その後、バックアップコンテナーへ移動されますので、一時的にせよPremium Storage の課金が余分にかかります。 試してみたところ、バックアップが終わるとコンテナは消えるようです。
リストアですが、Premium Storage に直接は復元できないようです。 記事に書いてあるとおり、まず Standard Storage アカウントに復元した後でPremium StorageアカウントにVHDをコピーするというひと手間がかかります。GAまでに改善されると嬉しいですね。
あと、なぜかUsageにカウントされないように見えますが、表示上だけの問題でしょうか。これは128GBのP10を付けた仮想マシンをバックアップしたところですが、OSディスク分しかカウントされていないように見えました。