Azure Virtual Machineの稼働ステータスやIPアドレス、ディスクの情報を纏めて取得する(VM名を指定して取得する)

 

Azure Portal上で、Virtual Machineの設定を確認しようとすると、ディスクの情報はディスクのメニューを開き、ネットワークインターフェースの情報は、ネットワークインターフェースのメニューを開きという事で少し面倒。これをまとめて見れないかなぁという事で、Power Shellで見れるようにしてみました。

作成にあたっては以下の各コマンド(Get-AzDisk、Get-AzNetworkInterface)ガイドをサイトを参考に進めました。

https://docs.microsoft.com/en-us/powershell/module/az.network/get-aznetworkinterface?view=azps-3.8.0

https://docs.microsoft.com/en-us/powershell/module/az.compute/get-azdisk?view=azps-3.8.0

今回作成したものは GitHub上に公開しています。

https://github.com/Tama-negi/Li-akb-branch-office/tree/PowerShell_Azure/VM-Status-Get-20200424

1.Virtual Machineに関して取得する情報

Virtual Machine名を指定することによって、以下の情報を取得しています。必要に応じて適時追加削除してください。

    • Virtual Machine名
    • PowerState
    • VMSize
    • DISK名
    • DISKサイズ
    • DSIKのTier
    • Network Interface名
    • Private IP Address
    • 静的IP or 動的IP

2.Azure Virtual Machineの情報を取得するPower Shell

Get-AzVM でVirtual Machineの情報を取得し、その中にあるVM固有のIDを特定します。

Virtual Machineにディスクがアタッチされている場合は、このIDがディスクの情報に含まれます。そこで合致するディスクのディスク情報をGet-AzDiskで取得します。同じく ネットワークインターフェース情報はGet-AzNetworkInterfaceで取得しています。

また、Get-AzVMに-Statusオプションがないと、VMの稼働状況が取得出来ません。一方で、-StatusオプションをつけるとVmSizeが取得出来ません。その為、VmSizeの方は@{n=”VMSize”; e={$vm.HardwareProfile.VmSize}}とし、-Status無しの結果から値を取得しています。

#VMの情報を取得するPowerShell(基本編)

#VM名を指定して、IF名、IP、DISK名、サイズ、SKU等を取得

#パラメータ指定
param (
    [String] [Parameter(Mandatory=$true)] $VMName
    )

# VM Status 取得

$vm = Get-AzVM -name $VMName

# サブスクリプションID指定

$SubscriptionId =“サブスクリプションID”
Select-AzSubscription -SubscriptionId $SubscriptionId 

# VMの各情報を取得

Get-AzVm -ResourceGroupName $vm.ResourceGroupName -Name $vm.Name -Status `
| select-Object Name,@{n=”Status”; e={$_.Statuses[1].Code}},@{n=”VMSize”; e={$vm.HardwareProfile.VmSize}}
& `
Get-AzDisk -ResourceGroupName $vm.ResourceGroupName`
| Where { $_.ManagedBy -contains $VM.id }`
| Select-Object @{n=”DiskNmae”; e={$_.Name}},DiskSizeGB,@{n=”Tier”; e={$_.sku.Name}}
& `
Get-AzNetworkInterface `
| Where { $_.VirtualMachine.id -contains $VM.id}`
| Select-Object @{n=”NWInterFaceNmae”; e={$_.Name}},`
@{n=”PrivateIP”; e={$_.IpConfigurations.PrivateIpAddress}},`
@{n=”PrivateIpAllocation”; e={$_.IpConfigurations.PrivateIpAllocationMethod}}

※なぜか、サブスクリプションIDの指定をしないと情報取得出来なかったので、今回は、Select-AzSubscriptionでサブスクリプションIDの指定を行っています。

3.Azure Virtual Machineの稼働ステータスやIPアドレス、ディスクの情報の取得結果

実際にPower Shellを実行してみると、以下のような結果が得られます。(今回はディスクを2本ついたVirtual Machineなので2つ表示されます。)

PS> c:\PowerShell\VMの情報を取得する(基本編)(公開用).ps1 -VMname VM名

Name : VM名
Status : PowerState/running
VMSize : Standard_B1ms


DiskNmae : OSディスク名
DiskSizeGB : 30
Tier : Standard_LRS


DiskNmae : データDISK名
DiskSizeGB : 30
Tier : StandardSSD_LRS


NWInterFaceNmae : ネットワークインターフェース名
PrivateIP : PrivateIP
PrivateIpAllocation : Static

※作成にあたって、躓くことがあり、マイクロソフトサポート様に大変貴重なアドバイスをいただいております。有難うございました。

Azure Virtual Machine Bシリーズの残CPUクレジットを確認してみた

 

Azure Virtual Machineのシリーズの1つに、Bシリーズがあります。

Bシリーズは普段使わないCPUの使用量を貯めておいて、負荷が高くなった時にその貯めたCPU使用量を使うシリーズです。Dシリーズよりも大体2分の1位の使用料金で使える為、普段からCPUをガンガンに使わないVirtual Machineに向いています。

詳細は下記マイクロソフト様のサイトに記載があります。

https://azure.microsoft.com/ja-jp/pricing/details/virtual-machines/series/

https://docs.microsoft.com/ja-jp/azure/virtual-machines/sizes-b-series-burstable

Bシリーズを使っている時に、このクレジット残量がどの位残っているのか気になったので、このクレジット量を把握する為の方法を確認してみました。

1 .BシリーズのCPUクレジット残をAzure Portal上で確認する

Azure Portal上で簡単に確認ができます。

Virtual Machineのメニューで監視の区分にあるメトリックという項目を選択します。

このメトリックを選択すると、下記のように項目を選ぶとグラフが表示されます。この項目でCPU Credits Remainingを選択すると過去のクレジット残の履歴確認ができます。

.BシリーズのCPUクレジット残をPower Shellを使って確認する

Power Shellでも値が確認できます。今回は直近の値を確認しています。

サブスクリプションIDやリソースグループ名は環境に合わせて設定します。また、Power Shell実行時に、取得したいVirtual Machine名を指定します。

Get-Dateで取得した日付フォーマットそのままだとエラーになるので、フォーマットを変更しています。StartTime等を変更することにより、過去の値も取得可能です。

#CPU Credits Remaining

param (
    [String] [Parameter(Mandatory=$true)]  $VMname
    )

$subscriptionID =“サブスクリプションID”
$RGName = “リソースグループ名”

$startTime = (Get-Date).AddMinutes(-3) | Get-Date  -Format ‘yyyy-MM-dd THH:mm’
$endTime = Get-Date -Format “yyyy-MM-dd THH:mm”
 
# 注意-ResourceIdの行は折り返していますが、実際には1行です。GitHubの方を参考にして下さい
# https://github.com/Tama-negi/Li-akb-branch-office/tree/PowerShell_Azure/Azure_PowerShell

(Get-AzMetric `
    -ResourceId “/subscriptions/$subscriptionID/resourceGroups/$RGName/providers/Microsoft.Compute/virtualMachines/$VMname” `
    -TimeGrain 00:01:00 `
    -AggregationType “Average” `
    -StartTime $startTime `
    -EndTime $endTime `
    -MetricName “CPU Credits Remaining” `
    -DetailedOutput).Data `
| Select-Object TimeStamp,Average
 

実行すると以下のように結果が得られます。

TimeStamp Average

——— ——-

2020/04/16 10:20:00 316.12
2020/04/16 10:21:00 316.12
2020/04/16 10:22:00 316.12
 

※MetricNameの値を、CPU Credits Consumedに変更することにより、1分間にどれだけクレジットがたまっているかの確認が可能です。

.Azure Monitorにも設定があります

Azure Monitorの設定のメトリックにも、CPU Credits Remainingの項目があります。閾値を設定する事で、残量が少なくなったら、アラートを上げる事も可能です。 

Azure Virtual MachineのManaged Disksサイズを変更する(FIOでIOPSを測定もする)

 

Virtual Machine のデータディスクの拡張を試してみました。
また、Managed DiskはサイズによってもIOPSが違います。今回は併せてManaged Diskのサイズ拡張による、IOPSの変化をFIOで測定してみました。

今回は下記条件で実施しています。

    • OSはCent OS 7.7
    • Managed DISKはPremium SSDを利用
    • 32GB→512GBに拡張
    • データディスクは/dev/sdc
    • データディスクは/mnt/diskにマウント済みである。
    • IOPSはFIOで測定

※念のため、必ずバックアップを取得したうえで作業を実施して下さい。

1 .Virtual Machineのデータディスクサイズ変更

データディスクのサイズ変更を、Azure Portal上で実施します。
作業はVirtual Machine 停止させて実施します。
データディスクのアタッチ、デタッチはオンラインでも可能ですが、アタッチ済みのディスクの構成変更は、仮想マシンを停止する必要があります。(一度デタッチ後に構成変更して再アタッチという手も。。。)
対象のVirtual Machineを選択後、SettingsにあるDisksをクリックします。以下の画面が表示されますので、拡張するデータディスクをクリックします。

Disksの画面に移動するので、構成をクリックします。以下の画面が表示されますので、アカウントの種類やサイズの項目を変更します。今回はアカウントの種類をPremium SSDサイズを512GBとし保存をクリックします。

保存が完了したら、Virtual Machineを起動します。

2. OS側での、ボリューム拡張設定

サーバを起動した段階では、Azure側で実施したディスクの拡張はデバイスとしては認識されていますが、ボリュームとしては拡張されていない状態です。

[ユーザー名@ホスト名 tmp]$ fdisk -l /dev/sdc[

Disk /dev/sdc: 549.8 GB, 549755813888 bytes, 1073741824 sectors

[ユーザー名@ホスト名 tmp]$ df -h | grep /dev/sdc

/dev/sdc1 32G 6.1G 24G 21% /mnt/disk

fdiskコマンドでボリュームのサイズを変更します。

[ユーザー名@ホスト名 tmp]$ fdisk /dev/sdc

The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

コマンド (m でヘルプ): p

Disk /dev/sdc: 549.8 GB, 549755813888 bytes, 1073741824 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O サイズ (最小 / 推奨): 4096 バイト / 4096 バイト
Disk label type: dos
ディスク識別子: 0x00140f2e

デバイス ブート 始点 終点 ブロック Id システム
/dev/sdc1 2048 67108863 33553408 83 Linux

コマンド (m でヘルプ): d
Selected partition 1
Partition 1 is deleted

コマンド (m でヘルプ): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
パーティション番号 (1-4, default 1): 1
最初 sector (2048-1073741823, 初期値 2048):”入力せずにEnter”
初期値 2048 を使います
Last sector, +sectors or +size{K,M,G} (2048-1073741823, 初期値 1073741823):”入力せずにEnter”
初期値 1073741823 を使います
Partition 1 of type Linux and of size 512 GiB is set

コマンド (m でヘルプ): w
パーティションテーブルは変更されました!

ioctl() を呼び出してパーティションテーブルを再読込みします。

WARNING: Re-reading the partition table failed with error 16: デバイスもしくはリソースがビジー状態です.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
ディスクを同期しています。

以上の操作が完了したら、パーティションを拡張します。これで作業完了です。

[ユーザー名@ホスト名 tmp]$ resize2fs /dev/sdc1

確認してみると、サイズが変わっているのがわかります。

[ユーザー名@ホスト名 tmp]$ df -h | grep /dev/sdc 

/dev/sdc1 504G 6.1G 477G 2% /mnt/disk

3.FIOでManaged DiskのIOPSを測定

FIOのセットアップはyumコマンド(epelは有効)でOKです。関連パッケージを含めてインストールされます。

[ユーザー名@ホスト名 tmp]$ yum -y install fio

FIOのコマンドは以下のサイトを参考にしています。

https://qiita.com/toshihirock/items/fa4d310115e6921ab0ac

実行してみると以下のような結果になりました。ランダムreadでもスペック通りのIOPSが出ています。シーケンシャルでもおおむね同じ数値が出ています。Writeが遅い原因は不明です。

#シーケンシャルwriteの場合
 write: IOPS=402, BW=1610KiB/s (1649kB/s)(15.0MiB/10154msec)
#シーケンシャルreadの場合
 read: IOPS=2347, BW=9391KiB/s (9617kB/s)(92.3MiB/10069msec)

#ランダムwriteの場合
 write: IOPS=395, BW=6332KiB/s (6484kB/s)(69.8MiB/11295msec)
#ランダムreadの場合
 read: IOPS=2337, BW=36.5MiB/s (38.3MB/s)(383MiB/10490msec)

なお、いくつかのパターンで試すと、”ほぼ”Managed Diskの指標通りになっている事がわかります。

#Standard HDD(32GB)の場合(シーケンシャルread)
 read: IOPS=562, BW=2251KiB/s (2305kB/s)(22.3MiB/10131msec)

#Standard HDD(32GB)の場合(シーケンシャルwrite)
  write: IOPS=152, BW=610KiB/s (625kB/s)(6296KiB/10316msec)

#Premium SSD(32GB)の場合(シーケンシャルread)
  read: IOPS=122, BW=488KiB/s (500kB/s)(5148KiB/10544msec)

#Premium SSD(32GB)の場合(シーケンシャルwrite)
  write: IOPS=122, BW=489KiB/s (500kB/s)(5388KiB/11028msec)

 

 

Azure Virtual Machineを別テナントに移してみた

 

Azureのテナント間での仮想マシンを移行を試してみました。

仮想マシンのManaged DisksをいったんBLOBストレージにVHDファイルとして保管する必要があるようでした。VHDファイルをManaged Disksに戻し仮想マシンを作成することで実現出来ました。

Power Shellを利用して仮想マシンのテナント間の移行を実施してみました。

主な実施手順は以下の通りになります。

    • Managed Disksを別テナントのBlobストレージにコピーする
    • コピーしたファイルをManaged Disksに戻す
    • Managed DisksからVMを作成する(今回は割愛しています。)

※なお、同じテナントの別サブスクリプションへは、Managed Disksのまま移行が可能です。

1 .Managed Disksを別テナントのBlobストレージにコピーする

以下のサイトを参考に、Managed Disksをダウンロードせずに、直接Blobストレージにコピーしています。なお、サイト記載のサンプルをAz化しています。

https://docs.microsoft.com/ja-jp/archive/blogs/jpaztech/export-managed-disks-to-vhd

事前にコピー先のテナントには、ストレージアカウントとBlobストレージのコンテナを準備しておきます。
また、各テナントにログインが必要になりますので、適時ログインして下さい。

※本コマンドを発行前には、対象の仮想マシンは停止しておいてください。

#Managed Disk Copy PowerShell

# コピー元へのログイン
Login-AzAccount
Select-AzSubscription -SubscriptionId  “コピー元のサブスクリプション ID”

# コピー元のディスクパラメータ
$sourcergname = “コピー元リソースグループ名”
$diskname = “コピー対象のManagedDisk名”

# SAS URL の作成
$mdiskURL = Grant-AzDiskAccess -ResourceGroupName $sourcergname -DiskName $diskname -Access Read -DurationInSecond 3600

# コピー先の情報
# コピー先テナントにログイン

Login-AzAccount
Select-AzSubscription -SubscriptionId  “コピー先のサブスクリプション ID”

# コピー先の各種パラメーター
$targetrgname = “コピー先リソースグループ名”
$storageacccountname = “コピー先ストレージアカウント名”
$countainername = “コピー先コンテナ名”

$storageacccountkey = Get-AzStorageAccountKey -ResourceGroupName $targetrgname -Name $storageacccountname
$storagectx = New-AzStorageContext -StorageAccountName $storageacccountname -StorageAccountKey $storageacccountkey[0].Value
$targetcontainer = Get-AzStorageContainer -Name $countainername -Context $storagectx

$destdiskname = “コピー後のファイル名”
$sourceSASurl = $mdiskURL.AccessSAS

# コピー
$ops = Start-AzStorageBlobCopy -AbsoluteUri $sourceSASurl -DestBlob $destdiskname -DestContainer $targetcontainer.Name -DestContext $storagectx
Get-AzStorageBlobCopyState -Container $targetcontainer.Name -Blob $destdiskname -Context $storagectx -WaitForComplete

 

.コピーしたファイルをManaged Disksに戻す

コピーしたファイルをコピー先のテナントでManaged Disksに戻します。以下のサイトを参考に戻すPower Shellを作ってみました。

https://docs.microsoft.com/ja-jp/archive/blogs/jpaztech/convertvhdtomanageddiskdeployvm

複数のサブスクリプションにログインした状態での作業となるため、作業ミス防止用に明示的にサブスクリプションを指定を追加しています。

vhdのURLは、以下の方法で確認が可能です。
Azure Portal上で、ストレージ アカウントを選択→Blobを選択→ファイルが保管された コンテナーを選択→対象のディスクファイルを選択。プロパティが表示されますが、この中のURLがVHDのURLとなります。

なお、OS Typeを指定しないと、後の作業で仮想マシン作成ボタンが押せない状態となります。

# VHD→ManagedDisk PowerShell

#Select Subscription
$SubscriptionId =“コピー先のサブスクリプションID”
Select-AzSubscription -SubscriptionId $SubscriptionId

#Parameter
$ResourceGroupName = “ManagedDiskのRG名”
$location = “ManagedDiskのロケーション”
$DiskName = “作成するManagedDisk名”
$vhdUri = “コピーしたファイルのURL”
$AccountType =“ストレージアカウントのType (ex; Standard_LRS)”<
$OsType = ”ManagedDiskのOS Type (ex; Linux)”

#Disk Config
$DiskConfig = New-AzDiskConfig `
-AccountType $AccountType `
-Location $Location `
-CreateOption Import `
-SourceUri $vhdUri `
-OsType $OsType

#VHD → Managed Disk
New-AzDisk `
-DiskName $DiskName `
-Disk $DiskConfig `
-ResourceGroupName $ResourceGroupName

完了すると、新たにManaged Disksができています。

作成したManaged Disksを選択すると、仮想マシンの作成というボタンが表示されてますのでクリックします。そうすると仮想マシンが作成されます。

 

ARMテンプレートを使ってSQL Serverをデプロイしてみた(ディスクサイズを指定)

 

Azure環境にVirtual Machine(Windows SQL Server)をデプロイすると、デフォルトでデータディスクが1TBで作成されてしまいます。後で修正も可能なのですが、面倒なのでデプロイ時からディスクサイズを制限するようにARMテンプレートを作成してみました。

1 .Windows SQL Serverをデプロイする為のJsonファイルを作成する。

基本的な仮想マシンの設定で作っています。適時値を入れてください。

今回は簡易的なものなので、OSのUserとパスワードは平文で記載しています。大体の設定値をvariablesで定義するように構成しています。NICとOSディスク名は仮想マシンの値を変数として取得する形で作成しています。 

データディスクのサイズは、diskSizeGBの値で指定が可能です。(今回は128GBで設定しています。)

まず、以下のPowerShellで、Windows SQL ServerのVMイメージを確認します。

#Image List get

$location=“japaneast”

#pubName Get
#Get-AzVMImagePublisher -Location $location

$pubName=“MicrosoftSQLServer”

#offer Name Get
#Get-AzVMImageOffer -Location $location -Publisher $pubName

$offerName=“SQL2008R2SP3-WS2008R2SP1”
Get-AzVMImageSku -Location $location -Publisher $pubName -Offer $offerName

JSONテンプレートサンプルになります。(今回はSQL Server 2008を選択しています。)

{
“$schema”: “https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
“contentVersion”: “1.0.0.0”,
“variables”: {
  “location”: “japaneast”,

  “vmName”: “VM名”,
  “vmSize”: “Standard_B2s”,

  “adminUsername”: “User Name”,
  “adminPassword”: “Password”,

  “publisher”: “MicrosoftSQLServer”,
  “offer”: “SQL2008R2SP3-WS2008R2SP1”,
  “sku”: “Standard”,

  “nicName”: “[concat(variables(‘vmName’),’_nic’)]”,
  “addressPrefix”: “XXX.XXX.XXX.XXX/XX”,
  “subnetName”: “Subnet Name”,
  “subnetPrefix”: “XXX.XXX.XXX.XXX/XX”,
  “virtualNetworkName”: “VNET Name”,
  “subnetRef”: “[resourceId(‘Microsoft.Network/virtualNetworks/subnets’, variables(‘virtualNetworkName’), variables(‘subnetName’))]”,

  “diskName”: “[concat(variables(‘vmName’),’_os_disk’)]”,
  “DatadiskName”: “[concat(variables(‘vmName’),’_Data_disk’)]”,
  “storageAccountType”: “Standard_LRS”,

  “storageAccountName”: “Storage Account Name”

},
 “resources”: [
 {
  “type”: “Microsoft.Network/virtualNetworks”,
  “apiVersion”: “2018-11-01”,
  “name”: “[variables(‘virtualNetworkName’)]”,
  “location”: “[variables(‘location’)]”,
  “properties”: {
  “addressSpace”: {
  “addressPrefixes”: [
  “[variables(‘addressPrefix’)]”
  ]
},
 “subnets”: [
 {
  ”name”: “[variables(‘subnetName’)]”,
  ”properties”: {
  ”addressPrefix”: “[variables(‘subnetPrefix’)]”
    }
   }
  ]
 }
},
{
 ”type”: “Microsoft.Network/networkInterfaces”,
 ”apiVersion”: “2018-11-01”,
 ”name”: “[variables(‘nicName’)]”,
 ”location”: “[variables(‘location’)]”,
 ”dependsOn”: [
 ”[resourceId(‘Microsoft.Network/virtualNetworks/’, variables(‘virtualNetworkName’))]”
],
“properties”: {
 ”ipConfigurations”: [
 {
 ”name”: “ipconfig1”,
 ”properties”: {
 ”privateIPAllocationMethod”: “Dynamic”,
 ”subnet”: {
 ”id”: “[variables(‘subnetRef’)]”
     }
    }
   }
  ]
 }
},
{
 ”type”: “Microsoft.Compute/virtualMachines”,
 ”apiVersion”: “2018-10-01”,
 ”name”: “[variables(‘vmName’)]”,
 ”location”: “[variables(‘location’)]”,
 ”dependsOn”: [
 ”[resourceId(‘Microsoft.Network/networkInterfaces/’, variables(‘nicName’))]”
 ],
 ”properties”: {
 ”hardwareProfile”: {
 ”vmSize”: “[variables(‘vmSize’)]”
 },
 ”osProfile”: {
 ”computerName”: “[variables(‘vmName’)]”,
 ”adminUsername”: “[variables(‘adminUsername’)]”,
 ”adminPassword”: “[variables(‘adminPassword’)]”
 },
 ”storageProfile”: {
 ”imageReference”: {
 ”publisher”: “[variables(‘publisher’)]”,
 ”offer”: “[variables(‘offer’)]”,
 ”sku”: “[variables(‘sku’)]”,
 ”version”: “latest”
 },
 ”osDisk”: {
 ”createOption”: “FromImage”,
 ”name”: “[variables(‘diskname’)]”,
 ”managedDisk”: {
 ”storageAccountType”: “[variables(‘storageAccountType’)]”
 }
  },
 ”dataDisks”: [
 {
 ”lun”: 0,
 ”name”: “[variables(‘datadiskname’)]”,

 ”createOption”: “Empty”,
 ”managedDisk”: {
  ”storageAccountType”: “[variables(‘storageAccountType’)]”
  },
  ”diskSizeGB”: 128

  }
 ]
},
 ”networkProfile”: {
 ”networkInterfaces”: [
 {
 ”id”: “[resourceId(‘Microsoft.Network/networkInterfaces’,variables(‘nicName’))]”
 }
 ]
},
 ”diagnosticsProfile”: {
 ”bootDiagnostics”: {
 ”enabled”: true,
 ”storageUri”: “[concat(‘https://’, variables(‘storageAccountName’), ‘.blob.core.windows.net’)]”
       }
     }
   }
  }
 ]

}

2.デプロイする

テンプレート機能にJSONテンプレートを登録します。以下の内容が表示されますので、名前と説明を入力しOKを表示します。

そうすると、テンプレート画面が表示されますので、デフォルト表示されている内容を削除し、1)で作成したテンプレートをペーストしOKボタンをクリックします。 保存が完了したテンプレートを選択すると以下の画面が表示されますので、リソースグループ名を登録、使用条件に同意し、購入ボタンをクリックします。

デプロイが完了したら、リソースに移動して確認します。無事完成しているかと思います。

3.残念ながら、登録されているテンプレートを直接呼び出す方法はないそうです。(2019年12月現在)

現時点では、Azure Portalからのデプロイしかできません。

PowerShell等からのデプロイは、JSONファイルをローカルやGitHubを指定してのデプロイになります。

Azure Virtual Machine起動/停止時にManaged DisksのAccount Typeを変更して使用料金を削減する

 

Azure Managed Disksは利用するAccount Typeにより料金が異なります。この利用料金はVirtual Machine停止時にも料金が発生します。
Virtual Machine停止時にPremiumSSD等からStandard HDDに戻す事でランニングコストを抑えることができます。
今回は、Virtual Machine起動時や停止時に、Managed DiskのAccount Typeを変更するPowerShellを作って、試してみました。

作成にあたっては、以下のサイトを参考にしています。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/convert-disk-storage

1 .Virtual Machine起動時のPowerShell

以下のサンプルでは、Virtual Machine起動時に、接続されているManaged Diskが、すべてStandard SSDとなります。
なお、PowerShell実行時に、Virtual Machine名を変数として指定し、実行するようにしています。(VM IDを2回指定してますが、気にしないでください。)

#Vm Start (Changed Disk Type)

#VM名を固定にする場合は、下記の通り指定します。(param部分はコメントアウト)
#$vmName =”VM Name”

param (
            [string] [Parameter(Mandatory=$true)] $vmName
            )

$resourceGroupName =“RG Name”
$storageType =“StandardSSD_LRS”

$VM = Get-AzVM -Name $vmName -resourceGroupName $resourceGroupName
$vmDisks = Get-AzDisk | Where { $_.ResourceGroupName -eq $resourceGroupName } | Where { $_.ManagedBy -eq $VM.id }

foreach ($disk in $vmDisks)
 {
  if ($disk.ManagedBy -eq $vm.Id)
  {
  $diskUpdateConfig = New-AzDiskUpdateConfig –AccountType $storageType
  Update-AzDisk -DiskUpdate $diskUpdateConfig -ResourceGroupName $resourceGroupName `
  -DiskName $disk.Name
  }
}

Start-AzVM -ResourceGroupName $resourceGroupName -Name $vmName

起動対象のVirtual Machine 名を指定し、PowerShell実行します。(今回はPowerShell名を、VM_Start_SelectDiskType.ps1としています。)

c:\VM_Start_SelectDiskType.ps1 -vmName VM Name

.Virtual Machine停止時のPowerShell

以下のサンプルでは、Virtual Machine停止時に、接続されているManaged Diskが、すべてStandard HDDとなります。

#Vm Stop (Changed Disk Type)

#VM名を固定にする場合は、下記の通り指定します。(param部分はコメントアウト)
#$vmName =”VM Name”

param (
[string] [Parameter(Mandatory=$true)] $vmName
   )

  $resourceGroupName =“RG Name”
  $storageType =“Standard_LRS”

 Stop-AzVM -ResourceGroupName $resourceGroupName -Name $vmName -Force

 $VM = Get-AzVM -Name $vmName -resourceGroupName $resourceGroupName
 $vmDisks = Get-AzDisk | Where { $_.ResourceGroupName -eq $resourceGroupName } | Where { $_.ManagedBy -eq $VM.id }

foreach ($disk in $vmDisks)
{
 if ($disk.ManagedBy -eq $vm.Id)
  {
  $diskUpdateConfig = New-AzDiskUpdateConfig –AccountType $storageType
  Update-AzDisk -DiskUpdate $diskUpdateConfig -ResourceGroupName $resourceGroupName `
  -DiskName $disk.Name

 }
}

停止対象のVirtual Machine 名を指定し、PowerShell実行します。(今回はPowerShell名を、VM_Stop_SelectDiskType.ps1としています。)

c:\VM_Stop_SelectDiskType.ps1 -vmName VM Name

3 .各Managed DiskのAccount Typeについて

以下のPowerShellで、各Managed DiskのAccount Typeを表示する事ができます。変更後の確認に使えます。

Get-AzDisk -resourceGroupName  RG Name |ft Name,@{Name=”Name”; Expression={$_.Sku.Name}}

 

テンプレート機能を使ってAzure Virtual Machineをデプロイする

 

Azureにはテンプレートとういメニューがあります。このテンプレートというメニューではARMテンプレートを保存する事が出来ます。この機能にAzure Virtual Machineのテンプレートを登録してデプロイを実行する検証を実施してみました。

1 .仮想マシンをデプロイする為のJsonファイルを作成する。

基本的な仮想マシンの設定で作っています。適時値を入れてください。
なお今回は簡易的なものなので、OSのUserとパスワードは平文で記載しています。
大体の設定値をvariablesで定義するように構成しています。NICとOSディスク名は仮想マシンの値を変数として取得する形で作成しています。
なお、WindowsのVirtual Machine作成時は、以下のコマンドで、利用したいSKUの値を取得し、テンプレートのSKUの値を指定してください。

$location =“japaneast”

Get-AzVMImageSku -Location $location -PublisherName “MicrosoftWindowsServer” -Offer “WindowsServer”

CentOS7.5の場合のJSONテンプレートサンプルになります。(VMNameや、addressPrefix等を正しい値にしないと、テンプレート保存時にエラーになります。)

{
“$schema”: “https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
“contentVersion”: “1.0.0.0”,
“variables”: {
 “location”: “japaneast”,       

 

 ”vmName”: “VM Name”,
 ”vmSize”: “Standard_B1s”,  

 ”adminUsername”: “testuser”,
 ”adminPassword”: “testpassword”,  

 ”publisher”: “OpenLogic”,
 ”offer”: “CentOS”,
 ”sku”: “7.5”,

 ”nicName”: “[concat(variables(‘vmName’),’_nic’)]”,
 “virtualNetworkName”: “Vnet Name”,
 ”addressPrefix”: “XXX.XXX.XXX.XXX/XX”,
 ”subnetName”: “Subnet Name”,
 ”subnetPrefix”: “XXX.XXX.XXX.XXX/XX”,
 ”subnetRef”: “[resourceId(‘Microsoft.Network/virtualNetworks/subnets’, variables(‘virtualNetworkName’), variables(‘subnetName’))]”,

 ”diskName”: “[concat(variables(‘vmName’),’_os_disk’)]”,
 ”storageAccountType”: “Standard_LRS”,

 ”storageAccountName”: “storage Account Name”

 },
“resources”: [
 {
 ”type”: “Microsoft.Network/virtualNetworks”,
 ”apiVersion”: “2018-11-01”,
 ”name”: “[variables(‘virtualNetworkName’)]”,
 ”location”: “[variables(‘location’)]”,
 ”properties”: {
 ”addressSpace”: {
 ”addressPrefixes”: [
 ”[variables(‘addressPrefix’)]”
 ]
 },
“subnets”: [
 {
 ”name”: “[variables(‘subnetName’)]”,
 ”properties”: {
 ”addressPrefix”: “[variables(‘subnetPrefix’)]”
 }}]}},
{
 ”type”: “Microsoft.Network/networkInterfaces”,
 ”apiVersion”: “2018-11-01”,
 ”name”: “[variables(‘nicName’)]”,
 ”location”: “[variables(‘location’)]”,
 ”dependsOn”: [
 ”[resourceId(‘Microsoft.Network/virtualNetworks/’, variables(‘virtualNetworkName’))]”
],
 ”properties”: {
 ”ipConfigurations”: [
{
 ”name”: “ipconfig1”,
 ”properties”: {
 ”privateIPAllocationMethod”: “Dynamic”,
 ”subnet”: {
 ”id”: “[variables(‘subnetRef’)]”
}}}]}},
{
 ”type”: “Microsoft.Compute/virtualMachines”,
 ”apiVersion”: “2018-10-01”,
 ”name”: “[variables(‘vmName’)]”,
 ”location”: “[variables(‘location’)]”,
 ”dependsOn”: [
 ”[resourceId(‘Microsoft.Network/networkInterfaces/’, variables(‘nicName’))]”
],
 ”properties”: {
 ”hardwareProfile”: {
 ”vmSize”: “[variables(‘vmSize’)]”
},
 ”osProfile”: {
 ”computerName”: “[variables(‘vmName’)]”,
 ”adminUsername”: “[variables(‘adminUsername’)]”,
 ”adminPassword”: “[variables(‘adminPassword’)]”
},
 ”storageProfile”: {
 ”imageReference”: {
 ”publisher”: “[variables(‘publisher’)]”,
 ”offer”: “[variables(‘offer’)]”,
 ”sku”: “[variables(‘sku’)]”,
 ”version”: “latest”
},
 ”osDisk”: {
 ”createOption”: “FromImage”,
 ”name”: “[variables(‘diskname’)]”,
 ”managedDisk”: {
 ”storageAccountType”: “[variables(‘storageAccountType’)]”
}}

},
 ”networkProfile”: {
 ”networkInterfaces”: [
{
 ”id”: “[resourceId(‘Microsoft.Network/networkInterfaces’,variables(‘nicName’))]”
}]},
 ”diagnosticsProfile”: {
 ”bootDiagnostics”: {
 ”enabled”: true,
 ”storageUri”: “[concat(‘https://’, variables(‘storageAccountName’), ‘.blob.core.windows.net’)]”
}}}}] }

2.デプロイする

テンプレート機能にJSONテンプレートを登録します。以下の内容が表示されますので、名前と説明を入力しOKを表示します。

そうすると、テンプレート画面が表示されますので、デフォルト表示されている内容を削除し、1)で作成したテンプレートをペーストしOKボタンをクリックします。

保存が完了したテンプレートを選択すると以下の画面が表示されますので、リソースグループ名を登録、使用条件に同意し、購入ボタンをクリックします。

Virtual Machineがデプロイされますので、完了したら、リソースに移動して確認します。無事完成しているかと思います。

Azure Virtual Machine のサイズを取得して1サイズ大きくするPower Shell

 

Azure Virtual Machineのサイズ変更する場合は、同シリーズで1サイズだけ大きくしたりするケースが多いかと思います。汎用的に利用できるように、現在動作しているAzure Virtual Machineのサイズを取得して、同じシリーズで1サイズ大きくするPowerShellを作成してみました。

1 .PowerShellのサンプル(Linux版)

Linux環境のPowerShellでの実行してください。Windows環境で動くものは現在チャレンジ中です。

#Vm one size Up(Linux)

# リソースグループ、VM 名を設定
$ResourceGroupName = “リソースグループ名”
$VmName = “仮想マシン名”

# VM の現在の設定を取得
$VmCfg = get-azvm -ResourceGroupName $ResourceGroupName -Name $VmName

# VM の現在の VM サイズを取得
$VmSize = ( $VmCfg.hardwareprofile | grep Standard |awk ‘{print $1}’)

# 現在の VM サイズと同シリーズの 1 サイズ上の VM サイズを取得
$New_VmSize = “”
$New_VmSize = ( `
Get-AzVMSize -ResourceGroupName $ResourceGroupName -VMName $VmName `
| Sort-Object -property NumberOfCores,MemoryInMB,ResourceDiskSizeInMB `
| grep $VmSize.Substring(0,10) `
| grep -A 1 $VmSize.Substring(0,$VmSize.Length) `
| awk ‘NR== 2 {print $1}’ )

# 一つ上の VM サイズがあるかの確認
if($New_VmSize -eq $null) {

Write-Host ‘一つ上の VM サイズはありません。’

}else{

$vmCfg.HardwareProfile.VmSize = $New_VmSize
Update-AzVM -VM $vmCfg -ResourceGroupName $ResourceGroupName

}

※マイクロソフトサポート様より教えて頂いたサンプルをもとに作成しています。

Azure Monitorのアラート設定に集約という項目が追加されてました

 

Azure Monitorのアラート設定で、LogAnalyticsワークスペース-Custom log searchにを指定した際に集約という項目が追加されてました。

https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/alerts-unified-log#metric-measurement-alert-rules

詳細は上記サイトに記載の通りですが、これを具体的に言うと、LogAnalyticsワークスペース単位でアラート設定を行う場合に正しく集計されないケースがあるという事になります。

1つの例として、以下のような継続して閾値を超えた場合の設定を行うには、Custom log searchを利用し、かつクエリとして仮想マシン単位で指定が必要でした。

監視対象:仮想マシン
監視内容;メモリ監視
閾値;% Used Memoryが80%以上
間隔;5分間
継続回数;3回

集約という項目を使う事により、仮想マシン単位ではなく、LogAnalyticsのワークスペース単位での設定可能になりました。

※Metricを利用してのリソース監視では仮想マシン単位での監視が可能ですが、連続して3回発生した場合等、継続を条件としたような設定ができません。その為、Custom log searchでの設定が必要になります。

1 .Azure Monitorに設定するクエリ(Custom log searchを使う場合)

下記のLogAnalyticsクエリで、ワークスペースに接続された仮想マシンの% Used Memoryを仮想マシン単位で取得可能です。 しかし、このクエリをAzure Monitorのクエリとして設定しても、ワークスペースに接続された仮想マシンの平均値で認識されるため、正しくアラート検知されませんでした。(平均値として認識されるのはAzure Monitorの仕様だそうです。)

#LogAnalyticsクエリ(メモリ使用率取得)
Perf
| where ( ObjectName == ‘Memory’ )
| where ( CounterName == ‘% Used Memory’ )
| summarize AggregatedValue=avg(CounterValue) by bin(TimeGenerated, 5m), Computer

Azure Monitorに設定するクエリとしては、下記のように、仮想マシンを明示的に指定する必要がありました。

#LogAnalyticsクエリ(メモリ使用率取得)
Perf
| where ( Computer == ‘VM名‘ )`
| where ( ObjectName == ‘Memory’ )
| where ( CounterName == ‘% Used Memory’ )

| summarize AggregatedValue=avg(CounterValue) by bin(TimeGenerated, 5m)

※リソースを収集するためには、事前にLogAnalytics側の設定で、パフォーマンスカウンターの取得設定が必要です。

.集約を利用する。

集約を使う事により、以下のクエリをAzure Monitorでも正しくクエリを認識させる事ができます。

#LogAnalyticsクエリ(メモリ使用率取得)
Perf
| where ( ObjectName == ‘Memory’ )
| where ( CounterName == ‘% Used Memory’ )
| summarize AggregatedValue=avg(CounterValue) by bin(TimeGenerated, 5m), Computer

集約に表示されるのはクエリ内でbyで設定された項目になります。実際の設定は下記画面の通りになります。
今回の場合、集約という項目にComputerが表示されますので、これを選択します。

Computerを指定することにより、以下のクエリでもLogAnalyticsワークスペースに接続された仮想マシンのリソースをAzure Monitor上でも期待した動作をしてくれます。

.集約を使う事のメリット。

ワークスペース単位での指定になるため、仮想マシンがワークスペースに接続された段階でAzure Monitorの設定変更する事なく、監視が開始できます。
また1つのアラートルールで済むため、コスト削減のメリットもあります。
非常に、細かい部分での機能になりますが、メリットは十分にあるかと思います。

Virtual Machine(CentOS 7)からBlobfuseを利用してBlobストレージをマウントする

 

Azure Virtual Machine (CentOS7) からのBlobストレージマウントを利用検証してみました。

CentOS 7からBlobストレージのマウントにはBlobfuseを利用します。

前回、Azure Virtual Machine (CentOS7) に追加した、SSDディスクをキャッシュディスクとして利用しています。
SSDディスクのマウントは、下記記事を参考にしてください。

http://www.tama-negi.com/2019/10/14/disk/

1 .Blobfuseをインストールする。

以下のサイトを参考にセットアップしました。

https://docs.microsoft.com/ja-jp/azure/storage/blobs/storage-how-to-mount-container-linux

[root@test-01]# rpm -Uvh https://packages.microsoft.com/config/rhel/7/packages-microsoft-prod.rpm
#今回は、CentOS7なので6→7へ変えてます。(6用と7用のパッケージは異なるそうです。)(関連パッケージも一緒に入ります。)
[root@test-01]#yum -y install blobfuse

2.Blobfuseを設定する。

追加したSSDをキャッシュとして利用している為、MSさんのサイトの例とは若干異なります。

#事前にSSDをデータディスクとして追加し、フォーマット等を完了させています。(今回は/mnt/ramdiskにSSDをマウントし、キャッシュとして利用します。)
[root@test-01]#mkdir /mnt/ramdisk #Blobfuseキャッシュ用のディレクトリです。
[root@test-01]#mount /dev/sdc1 /mnt/ramdisk
[root@test-01]#mkdir /mnt/ramdisk/blobfusetmp
[root@test-01]#mkdir /var/blobfuse #Blobストレージマウント用のディレクトリです。

#設定ファイルを作成します。今回は、/etc/の配下に設定ファイルを作成してます。
#アカウントKeyは、ストレージアカウントのアクセスキーメニューを開くと、Key1が表示されていますのでここの値を入れてます。
[root@test-01]#echo “accountName ストレージアカウント名” >> /etc/fuse_connection.cfg
[root@test-01]#echo “accountKey アカウントKey” >> /etc/fuse_connection.cfg
[root@test-01]#echo “containerName コンテナ名” >> /etc/fuse_connection.cfg
[root@test-01]#chmod 600 /etc/fuse_connection.cfg

#今回はblobfuseでマウントポイントを/var/blobfuseとして、Blobストレージをマウントしています。
#-o allow_otherを追加しています。これを追加しないと他のユーザーからアクセスできません。
[root@test-01]#blobfuse /var/blobfuse –tmp-path=/mnt/ramdisk/blobfusetmp –config-file=/etc/fuse_connection.cfg -o attr_timeout=240 -o entry_timeout=240 -o negative_timeout=120 -o allow_other

#マウントされたかどうかを確認します。サイズは、キャッシュのサイズが表示されます。(実際に使用する容量分のキャッシュが必要です。)
[root@test-01]df -h

ファイルシス サイズ 使用 残り 使用% マウント位置
(略)
blobfuse 3.9G 25M 3.7G 1% /var/blobfuse

3 .実際に利用してみての感じ

今のところ非常遅い感じです。またキャッシュが悪さしているのか、共有領域が更新されない等もありました。何かチューニングポイントがありそうな気もするので色々探してみたいと思います。

Power Shellを利用してAzure Virtual Machine(CentOS 7)を作成してみた

 

今回は、マイクロソフト様のサイトに”Power Shellを利用して完全なVirtual Machineを作成する”という記事があったので試してみました。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/scripts/virtual-machines-linux-powershell-sample-create-vm

今回はCentOS 7.5で作成しています。

1 .今回作成した環境の前提条件

今回は自身の環境に合わせて、以下の通りとしてます。

・リソースグループや仮想ネットワーク、Subnetが作成済みである。
・ログインはID、PWDで実施する。
・PublicIPは利用せず、ローカルのIPは固定する。
・NSGの設定は行わない。(Subnet単位でNSGの設定を行っている為)
・可用性セットは作成済みである。

.CentOSのイメージを検索する。

利用するCentOSのイメージを検索します。CentOSのパブリッシャー名は、”OpenLogic”になります。

#仮想マシンを作成するリージョン名
$locName=“japaneast”
$pubName=“OpenLogic”
$offerName=“CentOS”
#パブリッシャー名を検索する場合は下記を利用します。
#Get-AzVMImagePublisher -Location $locName
#offerName確認時は、以下のコマンドを実行します。
#Get-AzVMImageOffer -Location $locName -Publisher $pubName
Get-AzVMImageSku -Location $locName -Publisher $pubName -Offer $offerName
#2019年10月時点では以下の通りの値が得られます
Skus Offer PublisherName Location Id
—- —– ————- ——– —
6.10 CentOS OpenLogic japaneast /Subscriptions/(省略)/japaneast/Publishers/OpenLogic/ArtifactTypes/VMImage/Offers/CentOS/Skus/6.10

~(省略)~

7.5 CentOS OpenLogic japaneast /Subscriptions/(省略)/japaneast/Publishers/OpenLogic/ArtifactTypes/VMImage/Offers/CentOS/Skus/7.5

7.6 CentOS OpenLogic japaneast /Subscriptions/(省略)/japaneast/Publishers/OpenLogic/ArtifactTypes/VMImage/Offers/CentOS/Skus/7.6

7.7 CentOS OpenLogic japaneast /Subscriptions/(省略)/japaneast/Publishers/OpenLogic/ArtifactTypes/VMImage/Offers/CentOS/Skus/7.7

3 .利用するSubnetのIDを調べる

利用するSubnetのIDを検索します。NIC作成時に必要になります。

#仮想マシンを作成するリージョン名
$rgNameVnet =“仮想ネットワークがあるRG名”
$VnetName =“仮想ネットワーク名”
$vnet = Get-AzVirtualNetwork -ResourceGroupName $rgNameVnet -Name $VnetName
$subnet0 = $vnet.Subnets[0].Id
$subnet0
#以下のような値が得られます。0から数字を変えて、自分が利用するSubnet名が該当するのを検索します。
/subscriptions/XXX/resourceGroups/RG名/providers/Microsoft.Network/virtualNetworks/仮想ネットワーク名/subnets/Subnet名

 3.仮想マシンを作成する。

仮想マシンを作成します。

#仮想マシンの変数情報
$rgName =“VMを構築するRG名”
$vmName =“構築するVM名”
$vmSize =“Standard_B1s” 
$location =“japaneast” 
$OSUser = “OSのユーザー名”
$OSPword = “OSのパスワード”

#NICの変数情報
$NicName =“ネットワークカード名”
$rgNameVnet =“仮想ネットワークがあるRG名”
$VnetName =“仮想ネットワーク名”
$PrivateIP = “仮想マシンに付与するローカルのIPアドレス”

#可用性セット名
$AvailabilitySetName =“可用性セット名”

#DISKの変数情報
#$DISKTypeは、利用するOSのディスクタイプを指定します。
$DISKName =“ディスク名”
$DISKType =“Standard_LRS”

#パスワードの作成
$Pword = ConvertTo-SecureString -String $OSPword -AsPlainText -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $OSUser, $Pword

#NICの作成を実施します。
#$vnet.Subnets[X]には、先ほど調べたSubnetIDを設定します。(0-9の半角数字)
$vnet = Get-AzVirtualNetwork -ResourceGroupName $rgNameVnet -Name $VnetName
$subnet = $vnet.Subnets[X].Id
$nic = New-AzNetworkInterface -Name $NicName -ResourceGroupName $rgName `
-Location $location -SubnetId $vnet.Subnets[X].Id `
-PrivateIpAddress $PrivateIP

#仮想マシンの作成のためのConfigを設定します。
#Set-AzVMOperatingSystem 行には、先ほど調べたOSのイメージの値を設定します。今回は7.5を指定しています。
$AvailabilitySet = Get-AzAvailabilitySet -ResourceGroupName $rgName -Name $AvailabilitySetName
$vmConfig = New-AzVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetID $AvailabilitySet[0].Id ` | `
Set-AzVMOperatingSystem -Linux -ComputerName $vmName -Credential $cred | `
Set-AzVMOSDisk -name $DISKName -StorageAccountType $DISKType -CreateOption FromImage| `
Set-AzVMSourceImage -PublisherName OpenLogic -Offer CentOS -Skus 7.5 -Version latest | `
Add-AzVMNetworkInterface -Id $nic.Id

#仮想マシンの作成を実行します。
New-AzVM -ResourceGroupName $rgName -Location $location -VM $vmConfig

4 .PowerShellで作る事の意外なメリット

ディスク名や、ネットワークインタフェース名を自分で命名する事ができるため、運用時に色々と便利というメリットがあります。

 

Azure Virtual Machine(CnetOS 7)にデータディスクを追加する

 

今回はAzure Virtual Machine (CentOS 7) へのデータディスク(Managed Disks(Standard SSD))追加を試してみました。

マイクロソフト様のサイトを参考に検証を進めてみました。

1.Power ShellでデータDISKを追加

以下のサイトを参考に仮想マシンにデータディスクを追加するPower Shellを作ってみました。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/attach-disk-portal

$rgName = ‘RG名’
$vmName = ‘DISK追加するVM名’
$location = ‘japaneast’
#今回は、Standard SSDなので下記を指定。

$storageType = ‘StandardSSD_LRS’
$dataDiskName = ‘VM名_CashDisk_1(追加するDISK名)’
#今回は、最低の4GBを指定。
$diskConfig = New-AzDiskConfig -SkuName $storageType -Location $location -CreateOption Empty -DiskSizeGB 4
$dataDisk1 = New-AzDisk -DiskName $dataDiskName -Disk $diskConfig -ResourceGroupName $rgName$vm = Get-AzVM -Name $vmName -ResourceGroupName $rgName
$vm = Add-AzVMDataDisk -VM $vm -Name $dataDiskName -CreateOption Attach -ManagedDiskId $dataDisk1.Id -Lun 1Update-AzVM -VM $vm -ResourceGroupName $rgName

2.Linux上でマウントする。

以下のマイクロソフト様のサイトに記載の通りの手順になります。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/attach-disk-portal

まず、仮想マシンにディスクが追加された状況をOS上で確認します。

[root@test-01]# dmesg | grep SCSI

[ 0.342149] SCSI subsystem initialized
[ 0.987188] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)
[ 2.867663] sd 2:0:0:0: [sda] Attached SCSI disk
[ 2.873137] sd 3:0:1:0: [sdb] Attached SCSI disk
[3965178.687477] sd 5:0:0:1: [sdc] Attached SCSI disk

今回の場合、sdcが追加されているので、fdsikでパーティションを作成します。

今回は新しいパーティションを作成するので、コマンドはnで実施します。

[root@akbwg-web-01 httpd]# fdisk /dev/sdc
Welcome to fdisk (util-linux 2.23.2).Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0x07ecc989.The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.コマンド (m でヘルプ): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
パーティション番号 (1-4, default 1): 1
最初 sector (2048-8388607, 初期値 2048):
初期値 2048 を使います
Last sector, +sectors or +size{K,M,G} (2048-8388607, 初期値 8388607):
初期値 8388607 を使います
Partition 1 of type Linux and of size 4 GiB is setコマンド (m でヘルプ): w
パーティションテーブルは変更されました!ioctl() を呼び出してパーティションテーブルを再読込みします。
ディスクを同期しています。

最後にmkfsコマンドでディスクをフォーマット後、マウントします。
今回はマウントポイントを/mnt/ramdiskとしてます。
UUIDを指定したマウントを行う為、/dev/sdc1のUUIDをコピーしてfstabを作成します。

[root@test-01]# mkfs -t ext4 /dev/sdc1
[root@test-01]# blkid

/dev/sda1: UUID=”fa2f8157-XXXXX-XXXXXX” TYPE=”xfs”
/dev/sda2: UUID=”12907c8a-XXXXX-XXXXXX” TYPE=”xfs”
/dev/sdb1: UUID=”bb32dd89-XXXXX-XXXXXX” TYPE=”ext4″
/dev/sdc1: UUID=”66891613-XXXXX-XXXXXX” TYPE=”ext4″

[root@test-01]# mkdir /mnt/ramdisk
[root@test-01]# vi /etc/fstab

##fstabに以下を追記します。
UID=66891613-XXXXX-XXXXXX /mnt/ramdisk ext4 defaults,nofail 0 0

OS再起動してマウントされていることを確認します。

使ってないAzure Managed Disksやネットワークインターフェースをまとめて削除する

 

Virtual Machineを削除した場合でも、Azure Managed Disksやネットワークインターフェースは削除されません。
特に、Managed Disksは課金が継続されるため、不必要な場合は削除しておいた方がお得です。

Virtual Machineを削除した場合に、都度個別に削除する作業も結構面倒ですし忘れがちです。

今回はリソースグループ内で利用されていないManaged Disksやネットワークインターフェースをまとめて削除するPowerShellを作ってみました。

1.Managed Disksをまとめて削除するPowerShell

以下のPowerShellを実行すると、使用されていない、Managed Disks一覧の取得、削除が出来ます。

#対象のRG名を指定
$rgName =”RG名”
$deleteUnattachedDisks=0$managedDisks = Get-AzureRmDisk foreach ($md in $managedDisks) {
#リソースグループを指定しない場合は、これに置き換える。
#if$md.ManagedBy -eq $null)if($md.ManagedBy -eq $null| Where { $md.ResourceGroupName -eq $rgName }){

#削除の場合は1、確認だけの場合は0を指定

if($deleteUnattachedDisks -eq 1){

Write-Host “Deleting unattached Managed Disk with Id: $($md.Id)

#確認メッセージを表示する場合は、-Forceを削除すること

$md | Remove-AzureRmDisk -Force

Write-Host “Deleted unattached Managed Disk with Id: $($md.Id)

}else{

$md.Id

} } }

削除された場合は、以下のようなメッセージが表示されます。

Deleted unattached Managed Disk with Id: /subscriptions/”SubscriptionID”/resourceGroups/”RG名”/providers/Microsoft.Compute/disks/”Disk名”

2.ネットワークインターフェースをまとめて削除するPowerShell

Managed Disksと同様に、使用されていないネットワークインターフェースも、一覧の取得、削除が出来ます。

#対象のRG名を指定
$rgName =”RG名”

$deleteNetworkIF=1$NetworkIF = Get-AzureRmNetworkInterface foreach ($nic in $NetworkIF) {

#リソースグループを指定しない場合は、これに置き換える。
#if$nic.VirtualMachine -eq $null)

if($nic.VirtualMachine -eq $null| Where { $nic.ResourceGroupName -eq $rgName }){

#削除の場合は1、確認だけの場合は0を指定

if($deleteNetworkIF -eq 1){

Write-Host “Deleting unattached Network Interface with Name: $($nic.name)

#確認メッセージを表示する場合は、-Forceを削除すること

$md | Remove-AzureRmNetworkInterface -Force

Write-Host “Deleting unattached Network Interface with Name: $($nic.Name)

}else{

$nic.Id

} } }

削除された場合は、以下のようなメッセージが表示されます。

Deleted unattached Managed Disk with Id: /subscriptions/”SubscriptionID”/resourceGroups/”RG名”/providers/Microsoft.Network/networkInterfaces/”ネットワークインターフェース名”

Azure Monitorを使ってLog Analytics(OMSエージェント)の死活監視を行う(Metricを使う)

 

前回の続きになります。

Log AnalyticsでVirtual Machineのログ取得を行う場合、OMSエージェント自体が動作していないと、ログ取得が行えません。

Azure Monitorを使ってOMSエージェントからLog Analyticsへ送信されているHeartBeatを監視することで、OMSエージェントが正常に動作しているかの監視を行えます。

Azure MonitorのCustom log searchを使う方法と、Metricを使う方法がありますが、今回はMetricを使う方法で実施します。(前回はCustom log searchで実施しました。)

1.監視設定方法

実際に関しを行うには、Azure Monitorの機能を利用して実施します。

1. 以下にアクセスし、[+ 新しいアラート ルール] をクリックします。
[Azure ポータル] – [Log Analytics ワークスペース] – [<対象のワークスペース>]
– [警告]

2. “リソース” が Log Analytics ワークスペースとなっていることを確認します。

3. “条件” にて以下を設定します。
シグナル名 : Heartbeat
シグナルの種類 : Metric
サービスの監視 : プラットフォーム

4. “シグナル ロジックの構成” にて、以下を選択します。
ディメンション名 Computer の “選択” にチェックを入れます。

*  対象のLog Analytics ワークスペースに接続されているすべての仮想マシンが対象となります。

5. “アラート ロジック” にて以下を設定します。
しきい値 : Static
演算子 : 次の値より小さい
集計の種類 : 合計
しきい値 : 1

6. “評価基準” にて以下を設定します。
集約粒度 (期間) : 15 分
評価の頻度 : 5 分

7. アクションにて電子メールの送信を行うアクションを追加します。

8. アラート ルール名を入力し、作成します。

2.実際のアラートメール

OMSエージェントを停止し、15分経過すると以下のメールが来ます。

どのVMのOMSエージェントが停止したかは、Dimensionsに記載されます。

Suject:Azure: Activated Severity: 3  ”アラート名”

 

Dimensions ResourceId = /subscriptions/XXXXXXXXXXXXX/resourceGroups/RG名/providers/Microsoft.OperationalInsights/workspaces/ワークスペース名-01Computer = ”VM名”

3.MetricとCustom log searchで設定した場合の違い

主な違いは以下のような感じになります。Log AnalyticsのHeartBeat監視の場合は、Metricを使った方が良さそうな感じです。

・メール送信タイミングが異なる

 Custom log searchを使用した場合は、回復するまでメールが送信され続けます。

 Metricを使用した場合は、発生時と回復時にのみメールが送信されます。

・コストは、Metricで設定した場合の方が安い。

・Metricで設定する場合は、仮想マシンを一括して設定可能。VM追加時も自動で監視追加できる。

 

Azure Virtual Machineで最初にすること(CentOS 7.5編)

CentOS 7でAzure Virtual Machine を作成した場合に最初に実施する事を整理してみました。

セキュリティ的な観点も考えて、ログインの上限回数制限等を実施しています。

今回は、Network Security Group(NSG)等での制御を想定しているので、firewalld、Selinuxを無効化していますが、環境に合わせて実施可否を判断して下さい。

1.rootのパスワードを設定する

Azureに作成した、CentOSはrootのパスワードが非公開です。その為、一番最初に、rootのパスワード設定を実施します。

[user@test-vm ~]$ sudo su –
Password:  #仮想マシン作成時のユーザーパスワード
[root@test-vm ~]# 
[root@test-vm ~]# passwd
Changing password for user root.

New password: #新規設定するrootのパスワードを入力
Retype new password: #新規設定するrootのパスワードを入力

2.デフォルトユーザーのSUDO権限を剥奪する

Virtual Machine作成時のアカウントには、SUDO権限が付与されているので、削除します。

#必ずrootユーザのパスワードを設定してから実行します。本設定後root権限が必要な設定が一切できなくなります。

[root@test-vm ~]#cp -p /etc/sudoers.d/waagent /etc/sudoers.d/waagent.`date “+%Y%m%d”`
[root@test-vm ~]#sed -i -e “s/user/#user/g” /etc/sudoers.d/waagent

3.OSを日本語化する

OSの日本語化を実施します。

[root@test-vm ~]# localectl  set-keymap –no-convert jp106
[root@test-vm ~]#localectl set-x11-keymap –no-convert jp106
[root@test-vm ~]#localectl set-locale LANG=ja_JP.utf8
[root@test-vm ~]#source /etc/locale.conf
[root@test-vm ~]#timedatectl set-timezone Asia/Tokyo

4.SELinux無効化する

SE Linuxを使わない場合は無効化します。

[root@test-vm ~]#cp -p /etc/selinux/config /etc/selinux/config.`date “+%Y%m%d”`
[root@test-vm ~]#sed -i -e “s/SELINUX=enforcing/SELINUX=disabled/g” /etc/selinux/config

5.firewalld 無効化する

仮想マシンのアクセス制御をネットワークセキュリティグループ側で設定する場合は、OS側での設定は不要なので無効化します。

[root@test-vm ~]# systemctl stop firewalld
[root@test-vm ~]# systemctl disable firewalld

#fail2banやその他、firewalldでアクセス制御する場合は有効化のまま設定しましょう。

6.rootユーザーのSSHログイン拒否やポート番号変更を実施する。

セキュリティ上の観点から、rootユーザーのSSHログインを明示的に拒否します。また可能であれば、ポート番号も変更します。

[root@test-vm ~]#cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.`date “+%Y%m%d”`
[root@test-vm ~]#sed -i -e “s/#PermitRootLogin yes/PermitRootLogin no/g” /etc/ssh/sshd_config

7.ユーザーのログイン失敗上限を設定する

一定回数以上ログイン失敗があった場合は、一定時間ログインできないようにします。

[root@test-vm ~]#sed -i -e “3i auth required pam_tally2.so deny=5 unlock_time=60” /etc/pam.d/system-auth
[root@test-vm ~]#sed -i -e “10i account required pam_tally2.so” /etc/pam.d/system-auth
[root@test-vm ~]#sed -i -e “5i auth required pam_tally2.so deny=5 unlock_time=60” /etc/pam.d/password-auth
[root@test-vm ~]#sed -i -e “12i account required pam_tally2.so” /etc/pam.d/password-auth

#今回の場合は、5回失敗したら、1時間ログインできないように設定しています。

8.SWAP領域を設定する

デフォルトでは、SWAP領域が設定されていないので、設定します。

[root@test-vm ~]#cp -p /etc/waagent.conf /etc/waagent.conf.`date “+%Y%m%d”`

[root@test-vm ~]#sed -i -e “s/ResourceDisk.EnableSwap=n/ResourceDisk.EnableSwap=y/g” /etc/waagent.conf
[root@test-vm ~]#sed -i -e “s/ResourceDisk.SwapSizeMB=0/ResourceDisk.SwapSizeMB=1024/g” /etc/waagent.conf

#今回の場合は、B1S(メモリ1GB)を利用している為、1024MBで設定します。Virtual Machineのメモリ容量に応じて適時変更してください。

9.Proxyを利用する場合の設定

Proxyサーバの指定をホスト名で実施する設定の場合になります。Azure LBを使用してProxyの冗長化した場合は、利用するIPの名前解決できないので、明示的にhostsにアドレスを指定します。

[root@test-vm ~]#cp -p /etc/hosts /etc/hosts.`date “+%Y%m%d”`

[root@test-vm ~]#echo ‘ ‘ >> /etc/hosts
[root@test-vm ~]#echo ‘192.168.1.1 azure-lb-proxy  proxy’ >> /etc/hosts

[root@test-vm ~]#cp -p /etc/wgetrc /etc/wgetrc.`date “+%Y%m%d”`

[root@test-vm ~]#echo ‘proxy=http://azure-lb-proxy:8080’ >> /etc/yum.conf

[root@test-vm ~]#cp -p /etc/wgetrc /etc/wgetrc.`date “+%Y%m%d”`

[root@test-vm ~]#echo ‘http_proxy=http://azure-lb-proxy:8080/’ >> /etc/wgetrc
[root@test-vm ~]#echo ‘https_proxy=http://azure-lb-proxy:8080/’ >> /etc/wgetrc
[root@test-vm ~]#echo ‘ftp_proxy=http://azure-lb-proxy:8080/’ >> /etc/wgetrc

[root@test-vm ~]#sed -i -e “s/#HttpProxy.Host=None/HttpProxy.Host=azure-lb-proxy/g” /etc/waagent.conf
[root@test-vm ~]#sed -i -e “s/#HttpProxy.Port=None/HttpProxy.Port=8080/g” /etc/waagent.conf

#Proxyのアドレスを、192.168.1.1 とし、ホスト名をazure-lb-proxy、ProxyのPortを8080とした場合の例になります。

10.syslogに不必要なログを表示させない

Azure特有のログや、利用する中で不必要なログが、/var/log/messagesに出力される事があります。必要でないログは、ログを見にくくするので出力しないようにします。設定は、ignoreファイルに出力したくない文字列を記載する事で実現します。

[root@test-vm ~]#echo ‘if $programname == “systemd” and ($msg contains “Starting Session” or $msg contains “Started Session” or $msg contains “Created slice” or $msg contains “Starting user-” or $msg contains “Starting User Slice of” or $msg contains “Removed session” or $msg contains “Removed slice User Slice of” or $msg contains “Stopping User Slice of”) then stop’ >> /etc/rsyslog.d/ignore-messages.conf

[root@test-vm ~]#echo ‘if $programname == “systemd” and ($msg contains “Starting OMI CIM Server” or $msg contains “Stopping OMI CIM Server” or $msg contains “Started OMI CIM Server” ) then stop’ >> /etc/rsyslog.d/ignore-messages.conf

#上記の記載は一例です。

#設定後、必要に応じてsystemctl restart rsyslogを実施してください。

11.Cronを設定する

CentOS7からは、anacronが利用されていますが、ログローテのタイミングが固定されず、利用し続けるにあたって非常に面倒なので、noanacronに変更します。

[root@test-vm ~]#yum -y install cronie-noanacron
[root@test-vm ~]#yum -y remove cronie-anacron
[root@test-vm ~]#cp -p /etc/cron.d/dailyjobs /etc/cron.d/dailyjobs.`date “+%Y%m%d”`

[root@test-vm ~]#sed -i -e “s/MAILTO=root/MAILT0=/g” /etc/cron.d/dailyjobs

[root@test-vm ~]#sed -i -e “s/MAILTO=root/MAILT0=/g” /etc/crontab

#Cronのメールも削除してます。

#必要に応じて、/etc/cron.d/dailyjobsを編集し実行時間を変えます。

12.NTPを設定する

NTPにはchronyが利用されていますが、デフォルトでは海外のNTP Serverを検索してしまうので、国内に変更します。

[root@test-vm ~]#cp -p /etc/chrony.conf /etc/chrony.conf.`date “+%Y%m%d”`

[root@test-vm ~]#vi /etc/chrony.conf

#以下の行をコメントアウトする

server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst

#以下の行を追加する。leapsecmode以下の行はうるう秒対策。

server ntp.nict.jp iburst
server 0.jp.pool.ntp.org iburst
server 1.jp.pool.ntp.org iburst

leapsecmode slew
maxslewrate 1000
smoothtime 400 0.001 leaponly

#内部NTPがある場合は、必要に応じてホストの指定先を変更します。

最後に、rebootコマンドで、OSの再起動を実施してください。各サービスの再起動、SWAP領域の有効化を行います。