カテゴリー: Virtual Machine

認証方法にSSH公開キーを利用しAzure VMにログインする(Cent OS)

投稿日: 投稿者: tama-negi

 

Cent OSのAzure Virtual Machine(Azure VM)は作成時に、管理者アカウントの認証方式（ログイン方法）を、パスワードかSSH公開キーか選択する事が出来ます。

今回は、以下のサイトを参考に、管理者アカウントの認証方式をSSH公開キーでVMを作成し接続までを試してみました。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/ssh-from-windows

今回実施した作業は大きく分けて3段階になります。

１）PuTTYgenを利用して公開鍵、秘密鍵を作成する。

２）１）で作成した公開鍵を利用して、Azure VMを作成する。

３）１）で作成した秘密鍵を利用して、作成したAzure VMにログインする。

1.PuTTYgenを利用して公開鍵、秘密鍵を作成する

PuTTYがインストールされていない場合は、下記サイトよりダウンロードしてインストールします。

https://www.putty.org/

※Download PuTTYに、You can download PuTTYとありますので、こちらをクリックするとダウンロードのページに移動します。Package filesとありますので、こちらからダウンロードします。(通常のWin環境であれば64bitのMSIファイルで良いかと思います｡)

１）PuTTYgenを起動し、Generateをクリックし、公開鍵と秘密鍵を作成します。

※空白部分でマウスを動かさないとKeyが生成されませんので注意して下さい。

２）作成されたら、公開鍵、秘密鍵をそれぞれ保存します。公開鍵はSave Public Key、秘密鍵はSave Private Keyをクリックして行います。

これでPuTTYgenを利用した鍵の発行作業は完了です。

2.Azure VMの認証方法でSSH公開キーを選択する

Azure VM作成時の認証方法でSSH公開キーを選択する場合の設定になります。

先ほど保存した公開鍵のファイルをテキストエディタで開き、オレンジ色の部分をコピーします。

—- BEGIN SSH2 PUBLIC KEY —-
Comment: “rsa-key-20200705”
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
—- END SSH2 PUBLIC KEY —-

Cent OSのAzure VM作成時に管理者アカウントの認証方法でSSH公開キーを選択すると下記画面が表示されますので、下記の通り入力します。

    • ユーザー名は管理者アカウント名を入力します。
    • SSH公開キーのソースは既存の公開キーを選択します。
    • SSH公開キーには、PuTTYgenで発行した、公開鍵情報をコピペします。

後は通常通りAzure VMの作成を行えば、作業は完了です。

３.SSHキー(秘密鍵)を利用してAzure VM(Cent OS)にログインする

作成したAzure VMに、PuTTYを利用してログインします。(認証方法にSSH公開キーを設定した場合、サーバ上に公開鍵が配置されます。ですのでログイン時に使用するのは秘密鍵になります。)

１）PuTTYを起動し、接続先IPアドレス(もしくはホスト名)を入力します。

２）PuTTYのCategoryでAuthを選択すると下記画面が表示されます。最初に作成した秘密鍵を指定します。(SSHログイン時に利用する秘密鍵になります。)

３）PuTTYでOpenをクリックし、Azure VMに接続します。下記画面が表示されますので、管理者アカウントにユーザー名を入力してください。

この方法で、認証に公開SSHキーを利用してAzure VMにログインが出来ました。

4.認証方法にSSH公開キーを利用した場合の注意点

Azure Portalのシリアルコンソールを利用してログインする場合、認証方法にSSH公開キーを設定したユーザーは利用できません。(2020年7月5日現在)

シリアルコンソールを利用するには、別途パスワードでログインできるユーザーを作成する必要があります。

なお、rootアカウントのパスワード設定方法はこちらの記事に記載しております。

Azure VMのroot初期パスワードについて(Cent OS)

Azure VMのroot初期パスワードについて(Cent OS)

投稿日: 投稿者: tama-negi

 

Cent OSのAzure Virtual Machine(Azure VM)を作成した場合、rootアカウントの初期パスワードは非公開となっておりAzure VM作成時点では分かりません。

では、どうするのか？　

自身が作成した初期アカウントにはsudoの権限が付与されています。このsudo権限を利用してrootになり、root自身としてパスワードの初期化を実施する事でパスワードを設定する事が出来ました。

今回は、その手順を記載します。

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

１）まずAzure VM作成時に設定したアカウントでOSにログインします。

２）sudo su -でルートになります。この際にパスワードを聞かれます。Azure VM作成時に設定したユーザーのパスワードを入力します。

[user@test-vm ~]$ sudo su –
Password:  #Azure VM作成時のユーザーパスワード
[root@test-vm ~]#

３）rootになれたら、passwdコマンドでパスワードの初期化を行います。

[root@test-vm ~]# passwd
Changing password for user root.

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

これでrootのパスワードが設定できました。

2.Azure VMのrootのパスワードを設定する(keyでログインした場合)

Azure VM作成時にパスワードでは無く、keyで設定した場合にはどうなるでしょうか？

この場合も同じ方法で設定可能です。sudo実行時にパスワードを聞かれません。

sudo su -でルートになり、passwdコマンドでパスワードを初期化します。

[root@test-vm ~]# sudo su –

[root@test-vm ~]# passwd
Changing password for user root.

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

同じくrootのパスワードが設定できました

３.初期作成アカウントのsudo権限を剥奪する

Azure VM作成時の初期アカウントには、sudo権限が付与されています。

セキュリティ面を考えると、sudo権限を剥奪しておいた方が良いと思われます。

今回はこちらの手順もあわせて記載します。

初期作成アカウントのsudo権限は、/etc/sudoers.d/waagentにて定義されています。これをコメントアウトする事でsudo権限が剥奪出来ました。

[root@test-vm ~]#vi /etc/sudoers.d/waagent

#コメントアウトします。

username ALL=(ALL) ALL
↓
#username ALL=(ALL) ALL

これでsudo権限を剥奪する事が出来ました。

※sudo権限の剥奪は必ずrootアカウントのパスワード設定後に実施して下さい。

認証方法にSSHキーを用いた場合はこちらで試しております。

認証方法にSSH公開キーを利用しAzure VMにログインする(Cent OS)

その他に初期設定を下記にも記載しております。参考にしていただければ幸いです。

Azure VMデプロイ直後のOS初期設定（CentOS 7.5編）

Azure VMデフォルトのまま作ると危険なのでNSG設定しましょう

投稿日: 投稿者: tama-negi

 

Azure Portalを使って仮想マシン(VM)をそのまま作成すると、外部からのRDPやSSHアクセスが許可された状態になります。

これはネットワークセキュリティグループ(NSG)の受信規則が、Windowsの場合はRDP(3389)、Linux系の場合はSSH(22)がAnyで許可された状態になる為です。

AzureのパブリッククラウドのグローバルIPに対しては、作成した瞬間から不正なアクセスが来ます。インターネットからのアクセスをすべて許可した状態で放置する事は非常に危険な状態になります。

今回は、実際にやってみて、メッセージが表示される意味や、VM作成作業中に接続許可IPを指定する方法を確認してみました。

なおネットワークセキュリティグループ(NSG)はAzureで接続許可や拒否設定を行うものになります。

1 .仮想マシン(VM)をそのまま作成した際の、ネットワークセキュリティグループ(NSG)設定を確認してみました。

今回は、にAzure PortalでWindowsの仮想マシン(VM)作成を作成する時にネットワークセキュリティグループに関する設定を確認します。

まず基本画面で受信ポートの規則という以下の項目が表示されます。デフォルトこの画面で3389のポートが許可されます。

次にネットワーク画面で、以下の項目がデフォルトで表示されます。

デフォルトはBasicを選択されてます。このままデフォルト設定のまま進んでみます。

この設定のまま仮想マシン(VM)を作成してみます。

作成後、ネットワークインターフェースの設定を確認してみました。

ネットワークインターフェースに対して、NSG(ネットワークセキュリティグループ)が作成されているのですが、受信規則として下記ルールが作成されていました。

AnyでRDP(3389)が受信が許可された状態になってます。RDPでどこからでもアクセスできる状態になっています。

デフォルトのまま進んでしまうと、このように非常に危険な状態になる事がわかりました。

2 .仮想マシン(VM)と共に作成される、ネットワークセキュリティグループ設定を変更してみる

次に、仮想マシン(VM)作成時のどこで設定するのかを確認してみました。

Azure Portalで仮想マシン(VM)作成時に表示されるメッセージの通りで、基本画面の受信ポートの設定では何もできません。

ネットワークの画面で行います。下記の通りNICネットワークセキュリティグループで詳細を選択します。

ネットワークセキュリティグループの構成で、新規作成をクリックします。

そうすると下記画面が表示されます。ここで受信規則をクリックします。

そうすると下記画面が表示されます。ソースでIPアドレスを選択しますと、ソースIPアドレスが表示されますので、自身がアクセスするIPアドレスを入力します。

IPアドレスや名前等を入力して保管しますと、特定のIPからのみアクセス可能なネットワークセキュリティグループ(NSG)が作成されます。

なお自身のIPアドレスは、下記サイト等で確認が可能です。(Proxy等をご利用の方は社内システム管理者さん等に確認下さい。)

https://www.cman.jp/network/support/go_access.cgi

3 .そのままにしておくとどうなるのか

自身の経験ですが、実際にそのままにしておくと、5分後位から秒で辞書攻撃的なアクセスが来ました。

検証環境だから、すぐ消すからとか言ってそのままにしている事を多くみかけますが、要件が無い限り、ログイン元のIPアドレスは制限するようにした方が良いかと思います。

使う時しか上げないとかって、絶対に忘れますから！！

※実際のシステムではサブネットや、すでに作成済みのネットワークセキュリティグループ(NSG)を使うケースが多いと思いますが注意しましょう。

Azure VMの割り当て解除、停止忘れ対策

投稿日: 投稿者: tama-negi

 

今回は、Azure Virtual Machine(VM)を止めたつもりなのに、停止し忘れて課金が発生しているVMを一覧出力して停止するPower Shellを作ってみました。

Azureを触り始めて最初の頃に非常に戸惑ったのですが、AzureのVMでは、OSでシャットダウンコマンドを発行しても課金が停止しません。

VMの起動状態には、大きく分けてVM自体の起動状態とOSの起動状態という２つの考え方があります。

電源ON、OS停止、電源オフという流れを具体的に書くとこんな感じになります。

    • 電源ON(Azure Portalで開始をクリックする)　１→3
    • OSでシャットダウンコマンド発行　3→5
    • 電源Off(Azure Portalで停止をクリックする)　5→7
  VMの状態 状態 PowerState 課金

1

停止済み(割り当て解除)

 電源Off VM deallocated 課金されない
2 起動中 VM、OS起動中 VM starting 課金される
3 起動済み OS起動済み VM running 課金される
4 停止中 OS停止中 VM stopping 課金される
5 停止済み OS停止 VM stopped 課金される

6

停止中(割り当て解除中)

 VM停止中 VM deallocating 課金される

7

停止済み(割り当て解除)

 電源Off VM deallocated 課金されない

OSでシャットダウンコマンドを発行しても、OSは停止するのですが、VMのリソース解放はされてない状態（OS停止、VM起動）になります。その為継続して課金が発生します。

OSのみシャットダウンして、VM停止し忘れて課金が発生し続けるという事が結構ありました。

そこで、VMの課金が発生し続ける事態を防ぐために、OSのみがシャットダウンされている状態のVM一覧を取得し停止するPower Shellを作ってみました。

Azure VM停止時にディスクタイプを変更するPower Shellも作っておりますので、こちらも見て頂ければと。

Power ShellでAzure VM起動/停止と一緒にディスクタイプを変更する

1 .Azure Portal上でVMの電源状態を確認してみる。

最初にAzure PortalでVMの電源状態を確認してみました。VMのメニューの概要（VMを選択すると一番最初に表示される画面）の状態が電源状態を示すます。

　1) VMが完全に停止している状態（1の状態）（課金が発生しない状態）

　

　2) VMが実行されている状態(3の状態)

　

　3) OSのみがシャットダウンしている状態(5の状態)(課金が発生している状態)

　

　また、Virtual Machinesのメニューでも一覧で確認する事ができます。

　

２.Power Shellを使ってVMの電源状態を確認するにはGet-AzVM -status

PowerShellでVMの電源状態を確認するには、Get-AzVM コマンドを利用します。

Get-AzVM -statusのPowerStateが電源状態に対応します。

VM名とVMのステータスのみを取得する場合の例を示します。ftでコマンドの実行結果の中で表示される内容をVM名(Name)と電源状態(PowerState)に絞ってます。

#見れるVMのすべての電源状態を見る場合

PS> Get-AzVM -Status |ft Name,PowerState

Name PowerState
—- ———-
VM1 VM deallocated
VM2 VM deallocated

#リソースグループを指定してVMの電源状態を見る場合

PS> Get-AzVM -Status -ResourceGroupName “リソースグループ名” |ft Name,PowerState

３.VMの電源状態を取得して電源オフにするPower Shell(無駄な課金が発生してるVMの一覧を取得する)

不必要な課金が発生しているVMはPowerState が “VM Stoppe”になっているVMになります。

そこでPowerState が “VM Stoppe”の一覧取得しPower Shellで実施してみました。併せてVM停止をするようにしています。

    • #VMの状態を取得部分で、PowerState が “VM Stopped”の一覧を取得しています。
    • リソースグループを指定して実施するようにしています。
    • $vmstoporcheckを指定する事で、確認のみか停止するかを選択できるようにしています。
    • Stop-AzVMに-Forceをつける事で停止時の確認メッセージが表示されないようにしています。

#VM 割り当て解除忘れ漏れ対策 PowerShell

#RGを指定します。（RGを指定しない場合は下記3行をコメントアウトします。)
param (
        [string] [Parameter(Mandatory=$true)]  $resourceGroupName
      )

#確認のみの場合は0を選択する
$vmstoporcheck=1

#VM の状態を取得
    $vmstat = (Get-AzVM -Status `
    | Select-Object ResourceGroupName,Name,PowerState `
    | Where-Object { $_.PowerState -eq “VM Stopped” } )

#RGを指定する場合
    foreach ($vmstatus in $vmstat | Where-Object {$_.ResourceGroupName -eq $resourceGroupName })

#RGを指定しない場合
#   foreach ($vmstatus in $vmstat)

{
    if($vmstoporcheck -eq 1){
  
        Write-Host “Stop VM Name: $($vmstatus.Name)”
        Stop-AzVM -ResourceGroupName $vmstatus.resourceGroupName -Name $vmstatus.Name -Force
    
    }else{

        Write-Host “Stop VM Name: $($vmstatus.Name)”

    }
}

作成したPowerShellはGitHubにも公開しています。

https://github.com/Tama-negi/Li-akb-branch-office/tree/PowerShell_Azure/VmPowerStatusCheck_20200607

※VMのPowerState が “VM Stopped”になっていても、意図的にその状態で置かれているケースもあるかと思います。その編は実際の利用環境に合わせて注意願います。

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

第2世代 Azure Virtual Machineの指定

投稿日: 投稿者: tama-negi

 

すでに半年以上たってはいるのですが、第 2 世代仮想マシン (VM) が Azure でサポートされるようになっています。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/generation-2

まだ、Hyper-Vの第2世代とは、セキュアブートやVHDX形式はサポートされない等の差はあるようです。

ですが、ディスク コントローラーがSCSIになるなど、いろいろ進化しているようです。

今回は、第2世代の仮想マシンを明示的に指定する方法について、Azure PortalとARMテンプレートの場合について確認してみました。

1 .Azure Portal上で第2世代の仮想マシンを指定する方法について

マイクロソフト様のサイトにもありますが、Azure Portalを利用して第2世代の仮想マシンを作成するのは詳細タブで実施します。。

下記のように詳細タブの一番下に、VMの生成という項目があります。こちらでGen2を選択すると第2世代の仮想マシンが作成できます。

2 .Azure Resource Manager(ARM)テンプレート等で第2世代の仮想マシンを指定する方法について

ARMテンプレート等で第2世代の仮想マシンを指定するには、SKUで指定する形になるようです。

仮想マシンの場合は、OSを指定する場合、以下の項目で指定されます。

    • PublisherName　発行者
    • Offer　OSのタイプ（WindowsかCentOSか）
    • Skus　OSのバージョン
    • version　詳細バージョン（大体latestかと思います。）

実際に見るのが一番わかりやすいので、Windows Serverの場合とCentOSの場合について確認してみました。(結果は省略してます。)

まずはWindows　Serverの場合です。gsというのもあるのですが、2019-datacenter-gensecondを選ぶようです。

PS> Get-AzVMImageSku -Location ‘Japan East’ -PublisherName MicrosoftWindowsServer -Offer WindowsServer |ft Skus,Offer,PublisherName,Version

Skus Offer PublisherName Version
—- —– ————- ——-
2019-Datacenter WindowsServer MicrosoftWindowsServer
2019-datacenter-gensecond WindowsServer MicrosoftWindowsServer
2019-datacenter-gs WindowsServer MicrosoftWindowsServer
2019-Datacenter-smalldisk WindowsServer MicrosoftWindowsServer
2019-datacenter-smalldisk-g2 WindowsServer MicrosoftWindowsServer
2019-Datacenter-with-Containers WindowsServer MicrosoftWindowsServer
2019-datacenter-with-containers-g2 WindowsServer MicrosoftWindowsServer
2019-datacenter-with-containers-gs WindowsServer MicrosoftWindowsServer

次にCent OSの場合ですCentOSの場合は、-gen2がついているのが第2世代の仮想マシンに対応するようです。　(結果は省略してます。)

PS> Get-AzVMImageSku -Location ‘Japan East’ -PublisherName OpenLogic -Offer CentOS |ft Skus,Offer,PublisherName,Version

Skus Offer PublisherName Version
—- —– ————- ——-
7.4 CentOS OpenLogic
7.5 CentOS OpenLogic
7.6 CentOS OpenLogic
7.7 CentOS OpenLogic
7_4 CentOS OpenLogic
7_4-gen2 CentOS OpenLogic
7_5-gen2 CentOS OpenLogic
7_6-gen2 CentOS OpenLogic
7_7-gen2 CentOS OpenLogic
7_8 CentOS OpenLogic
7_8-gen2 CentOS OpenLogic
8.0 CentOS OpenLogic
8_0-gen2 CentOS OpenLogic
8_1 CentOS OpenLogic
8_1-gen2 CentOS OpenLogic

この結果を踏まえて、ARMテンプレートで第2世代の仮想マシンを指定する場合はこんな感じになりました。

#Windows　Serverの場合

“imageReference”: {
“publisher”: “MicrosoftWindowsServer”,
“offer”: “WindowsServer”,
“sku”: “2019-datacenter-gensecond”,
“version”: “latest”

#Cent OSの場合

“imageReference”: {
“publisher”: “OpenLogic”,
“offer”: “CentOS”,
“sku”: “8_1-gen2”,
“version”: “latest”

注意点ですが、第2世代の仮想マシンと第１世代の仮想マシンは相互に変換する事が2020年6月時点ではできません。基本的には第2世代で作った方が良いように思えるのですが、注意はしておいた方が良いと思われます。

ARMテンプレートを使ったAzure VMのデプロイについてはこちらの記事に記載しております。

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

Azure VMの稼働ステータスやIPアドレス、ディスク情報を纏めて取得

投稿日: 投稿者: tama-negi

 

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.Azure VMに関して使って取得する情報

今回は指定したVMについて稼働状況、DISK情報、ネットワークインターフェースの下記情報を取得してみました。

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

2.Azure VMの情報を取得する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 VMの稼働ステータスや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 VM Bシリーズ CPUクレジットの確認と監視

投稿日: 投稿者: tama-negi

 

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

Bシリーズは普段使わないCPUの使用量を貯めておいて、負荷が高くなった時にその貯めたCPU使用量を使うシリーズです。

Dシリーズと比較して2分の1位の使用料金で使える為、普段からCPUを使わないようなサーバに向いているシリーズになります。

Azure VM　Bシリーズの詳細は下記マイクロソフト様のサイトに記載があります。

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

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

ただ、このAzure VMのBシリーズですが、CPUの使用量が使い果たされている為性能が発揮されないという可能性もあります。

今回はCPUクレジット残量確認方法を試し、Azure Monitorの設定項目確認までを行ってみました。

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

Azure Portal上のメトリックで確認ができます。

仮想マシンのメニューの監視にあるメトリックという項目を選択します。

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

CPU使用率が高く使い果たしているような状況だと0になります。

なお、CPU Credits Consumedを使う事により、CPUクレジットがどれだけ溜まっているのか確認できます。

２.BシリーズのCPUクレジット残(CPU Credits Remaining)をPower Shellで確認する

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

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

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 VM Bシリーズの残CPUクレジット(CPU Credits Remaining)を監視

Azure MonitorのVirtual Machineメトリック監視にCPU Credits Remainingの項目があります。

スコープにAzure VMを指定します。

条件の選択でCPU Credits Remainingを選択するとシグナルロジックの構成が表示されます。

下記画面のように残量が次の値より小さいと指定すると、CPU Credits Remainingが少なくなった場合にアラートを上げる事も可能です。 

このアラートが頻発するようだと、CPUのリソースを使っているという事になるので、Dシリーズを選択した方が良いと思われます。

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

投稿日: 投稿者: tama-negi

 

Azure VM のデータディスクの拡張を試してみました。
また、Managed DiskはサイズによってIOPSが違います。

今回は併せてManaged Diskのサイズ拡張による、IOPSの変化をFIOで測定してみました。

Azure VMでのデータディスク拡張作業は、下記条件で実施しています。

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

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

なお、データディスクの追加に関しては以下の記事に纏めております。

Azure VM(CentOS 7)にデータディスクを追加する

1 .Azure VMのデータディスクサイズ変更

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

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

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

2. Cent OSでデータディスクのボリューム拡張設定

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

dfのコマンド結果を見ると、拡張前の32Gしか認識されていない事が分かります。

[ユーザー名@ホスト名 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: 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)

※Writeが遅いのですが、この原因は不明です。

 

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

投稿日: 投稿者: tama-negi

 

今回は、Azure VMをAzureの別テナントへ移行してみました。

実際に試行錯誤して実施してみたのですが、最終的には以下のような段取りになりました。

      • Azure VMのManaged Disksを別テナントのBlobストレージにコピーする
      • コピーしたファイルをManaged Disksに戻す
      • Managed DisksからVMを作成する

実施してみた所、Azure VMのManaged Disksを移行先のテナントのBLOBストレージにVHDファイルとして保管する必要があるようでした。移行先テナントでVHDファイルをManaged Disksに戻すことで仮想マシンを作成することで実現出来ました。

今回作業にあたっては、PowerShellを利用して実施してみました。

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

1 .Azure VMのManaged Disksを移行先テナントのBlobストレージにコピーする

まず事前に以下の準備をしておきます。

      • 移行先のテナントに、ストレージアカウントとBlobストレージのコンテナを準備しておく
      • 移行対象の仮想マシンを停止しておく。(Managed DisksにAzure VMをアタッチしていない場合はそのままで実行可能です。)

Managed Disksを一旦ローカルにダウンロードして、移行先のストレージアカウントにアップロードする事でも対応可能です。

ただ作業が面倒なので、以下のサイトを参考に、Managed Disksをダウンロードせずに、直接移行先のBlobストレージにコピーする方法を試してみました。

サイト記載のサンプルをAz化しています。

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

Power Shell実行時には各テナントへのログイン画面が表示されます。適時ログインして下さい。

※サイト記載のサンプルをAz化しています。

#Managed Disk Copy PowerShell

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

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

# SAS URL の作成(有効時間を1時間にしています。タイムアウトになる場合は適時調整します。)
$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

コマンドが完了したら、移行先のBlobストレージ内にファイルが生成されているの確認してください。生成されていたら作業は完了です。

2 .コピーされたVHDファイルをManaged Disksに変換する

コピーされたファイルをコピー先のテナントでManaged Disksに変換します。

以下のサイトを参考に戻すPower Shellを作ってみました。

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

本Power Shellの重要な注意点ですが、OS Typeを指定しないと、変換自体は出来るのですが、後の作業で仮想マシン作成ボタンが押せない状態となります。これでドはまりしました。

Power Shell内で指定するVHDファイルのURLは、VHDファイルが保管されているBlobストレージにて確認します。

Storage ExplorerにてVHDファイルを選択します。右クリックするとプロパティという項目が表示されますので選択します。下記画面が表示されますので、Uriに表示されている内容をコピーします、Power Shell実行時に指定するVHDファイルのURLになります。

実際に実行するPower Shellは下記の通りになりました。

# 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

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

Power Shellを実行し完了すると、新たにManaged Disksができています。確認はディスクのメニューでできます。

変換が終了したManaged Disksを選択すると、VMの作成というボタンが表示されてますのでクリックします。そうすると仮想マシンの作成画面に遷移しますので、そのまま作成を進めればAzure VMが作成できます。

※オペレーティングシステムが空白の場合はVMの作成ボタンがクリックできません。

3 .移行後のAzure VMで作業が必要そうです

なお、OMSエージェントを含む、拡張機能は接続先のテナントが異なる為、再度設定が必要になります。この編でドはまりする事もあるので注意が必要になります。

別件にはなりますが参考程度で見て頂ければと。(結果、関連パッケージのアンインストール、インストールを実施しました。)

Log AnalyticsでLogやリソース情報が取得出来なくなった時にやった事

 

 

SQL Serverのデータディスクサイズを指定してデプロイ

投稿日: 投稿者: tama-negi

 

Azure Portalを使ってMarket Placeから直接Windows SQL Serverをデプロイするとデータディスクが1TBで作成されてしまいます。

後でデータディスクを削除、追加して修正する事も可能なのですが、デプロイ時からディスクサイズを指定した方が便利かと思われます。

そこでデプロイ時にデータディスクのサイズを指定出来るように、ARMテンプレートを作成してみました。

Cent OSの場合のテンプレート作成、デプロイはこちらに記載しております。

テンプレート機能woAzure VMをデプロイする

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

基本的なVM設定としています。

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

まず、最初にWindows SQL ServerのVMイメージ(SKU)を確認します。

#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

確認したSKUを指定して、Windows SQL ServerのARMテンプレートを作ってみるとこんな感じになりました。（今回は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.Windows SQL Serverをテンプレートを使ってデプロイする

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

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

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

3.登録されているテンプレートをPower Shellから呼び出せない(2019年12月現在)

2019年12月時点では、テンプレート機能に登録したテンプレートを外部から呼び出すことはできないそうです。Azure Portalからのデプロイしかできないそうです。

Power Shell等からARMテンプレートを使ったデプロイを行うには、ローカルに保存したファイルやGitHubを指定してのデプロイとなるようです。

Power ShellでAzure VM起動/停止と一緒にディスクタイプを変更する

投稿日: 投稿者: tama-negi

 

Azure Managed Disksですが、Azure VMの起動停止状態に関わらず使用料金が発生します。

またAccount Type(Premium SSD、Standard HDD)により使用料金が異なります。
Azure VMを停止している時に、Premium SSDを利用する事はコストの無駄になります。Azure VM停止時にPremiumSSD等からStandard HDDに戻す事等で、Azureの利用料金を抑えることができます。

今回は、Azure VM起動時や停止時に、Managed DiskのAccount Typeを変更するPower Shellを作ってみました。

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

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

Azure VMの起動停止をRunbook使って実施する記事やAzure VMの停止忘れ対応に関する記事も併せて参考にして頂ければと。

Azure AutomationのRunbookで実行時間制限

Azure VMの割り当て解除、停止忘れ対策

1 .Azure VM起動と共にディスクタイプを変更するPower Shell(HDD→SSD) 

Azure VMの起動に併せて、Azure VMに接続されているすべてのManaged DiskをStandard SSDとするようにしてみました。
Power Shell実行時に、VM名を変数として指定し、実行するようにしています。（VM IDを2回指定してますが、気にしないでください。）

#Vm Start (Changed Disk Type)

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

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

$resourceGroupName =“リソースグループ名”
$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

起動対象のVM名を指定し、Power Shell実行します。（今回はPowerShell名を、VM_Start_SelectDiskType.ps1としています。）

c:\VM_Start_SelectDiskType.ps1 -vmName VM Name

2 .Azure VM停止と共にディスクタイプを変更するPower Shell(SSD→HDD) 

Azure VM停止に併せて、VMに接続されているManaged DiskをすべてStandard HDDにしています。Power Shell実行時に、VM名を変数として指定し、実行するようにしています。

#Vm Stop (Changed Disk Type)

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

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

  $resourceGroupName =“リソースグループ名”
  $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

　}
}

停止対象のVM名を指定し、Power Shell実行します。（今回はPowerShell名を、VM_Stop_SelectDiskType.ps1としています。）

c:\VM_Stop_SelectDiskType.ps1 -vmName VM Name

3 .Managed DisksのAccount Typeを確認する

Power ShellでManaged DiskのAccount Typeを表示する事ができます。変更後の確認に使えます。

Get-AzDisk -resourceGroupName  ”リソースグループ名” |ft Name,@{Name=”Name”; Expression={$_.Sku.Name}}

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

投稿日: 投稿者: tama-negi

 

Azure Portalを確認しているとテンプレートというメニューがありました。

テンプレートという機能を使うと、各アイテムのARMテンプレートを保存やそのテンプレートを使用してデプロイする事が出来るそうです。

今回は、テンプレート機能を使って、Azure VMのARMテンプレート登録からデプロイまでを試してみました。

1 .Azure VMをデプロイする為のARMテンプレート(Jsonファイル)を作成する

基本的な仮想マシンの設定でARMテンプレートを作っています。

    • OSのUserとパスワードは平文で設定しています
    • 設定値をvariablesで定義しています
    • ネットワークインターフェースとOSディスク名はVM名を取得し設定しています

まず、最初に利用したいイメージ名(SKU)を取得し確認します。

Cent OSのVM作成時は、以下のコマンドで確認ができます。確認した値を元にテンプレートのSKUを設定します。

$location =“japaneast”

Get-AzVMImageSku -Location $location -PublisherName “OpenLogic” -Offer “CentOS”

第2世代のVM指定についてはこちらに記載しておりますので、併せて参考にして頂ければと。

第2世代 Azure Virtual Machineの指定

Cent OS 7.5を指定したARMテンプレートを作ってみました。（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’)]”
}}}}] }

Windows SQL Serverの場合のARMテンプレートも作っております。併せて参考にして頂ければと。

SQL Serverのデータディスクサイズを指定してデプロイ

2.テンプレート機能を使ってAzure VMをデプロイする

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

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

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

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

Azure VMを今のサイズから1つ大きくするPower Shell

投稿日: 投稿者: tama-negi

 

今回は、Azure VMのサイズ変更をPower Shellでやってみました。

Azure VMのサイズ変更する場合には、同シリーズで1サイズだけ大きくしたりするケースが多いかと思います。

現在動作しているAzure VMのサイズを取得して、同じシリーズで1サイズ大きくするPower Shellを作成してみました。(Power ShellはLinux環境での実行を想定しています。)

Cent OSでのPower Shellセットアップはこちらを参考にして頂ければと。

Cent OSでAzモジュールを使えるようにしてみた

1 .現在動作しているAzure VMのサイズを取得して1サイズ上げるPower Shell

まず最初に現在動作しているAzure VMのシリーズやサイズを取得しています。その次に同じシリーズのサイズを確認して1サイズアップしています。

Cent OS環境のPower Shellでの実行を想定しています。

#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のアラート設定に集約という項目が追加されてました

投稿日: 投稿者: tama-negi

 

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側の設定で、パフォーマンスカウンターの取得設定が必要です。

2 .集約を利用する。

集約を使う事により、以下のクエリを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上でも期待した動作をしてくれます。

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

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

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

投稿日: 投稿者: tama-negi

 

Azure VM(Cent OS 7) からのBlobストレージマウントを利用検証してみました。

Azure上のLinuxからBlobストレージのマウントをするにはBlobfuseを利用するそうです。

Azure VM (Cent OS 7) に追加した、Standard SSDのデータディスクをキャッシュディスクとして利用して試してみました。
ディスクの追加やマウントは、下記に記載させて頂きましたので併せて参考にして頂ければと思います。

Azure VM(CentOS 7)にデータディスクを追加する

1 .Cent OS 7にBlobfuseをインストールする

以下のサイトを参考にBlobfuseをインストールしました。RPMファイルのダウンロード、インストールを行った後に、Blobfuseのパッケージをyumでインストールしています。

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を設定する

主な手順は3つの作業になりました。

    • ディレクトリ作成、マウント
    • ストレージアカウントのアクセスキーの設定
    • Blobストレージのマウント

追加したSSDのデータディスクをキャッシュとして利用している為、マイクロソフト様の例とは手順が若干手順が異なります。

#事前に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 .実際に利用してみての感じ

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