管理ディスクを用いたLinuxのOSディスクを他の仮想マシンのデータディスクとして接続する方法

こんにちは、Azureサポートチームの三國です。 今回は管理ディスクを用いたLinuxのOSディスクを他の仮想マシンのデータディスクとして接続する方法についてご案内致します。 非管理対象ディスクの手順についてはLinux OS が起動しない時のトラブル シューティングについて (ARM編)にて記載がありますのでそちらをご参照下さい。 本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。 はじめに 利用シーン・概要・注意事項・補足・FAQについては Linux OS が起動しない時のトラブル シューティングについて (ARM編) をご参照ください。   手順 それでは手順をご案内します。 1. 仮想マシンの情報を確認します(サイズ、仮想ネットワーク/サブネット) 仮想マシン再作成時に必要な情報となります。 2. ディスクの情報を確認します(名前、リソースID) 他仮想マシンへのディスクアタッチ時、仮想マシン再作成時に必要となります。 3. 仮想マシンを削除します。 4. データディスクとして他のVMにアタッチします。 アタッチできる仮想マシンは、同じリージョンでご利用いただいている Linux の仮想マシンです。ない場合はお手数ですが、作成ください。 (注意: 異なるイメージから作成したVMへアタッチすることを推奨します。同じイメージの場合 データ ディスクのマウント時に UUID が重複しているためのエラーが発生する場合がございます。) 5. データディスクをマウントして復旧作業を行います 5-1. 手順4にてディスクをアタッチした仮想マシンに SSH 接続します 5-2. 以下のコマンドを実行し、追加されたディスクの識別子を確認します(データ ディスクを Linux 仮想マシンに接続する方法にも記載がございます) 例) $ sudo grep SCSI /var/log/messages…

0

カスタムイメージを使用して仮想マシンスケールセットをデプロイする

こんにちは、Azure サポートチームの米田です。 今回は、ユーザが作成したカスタムのOSイメージを用いて仮想マシンスケールセット(Virtual Machine Scale Sets:VMSS)をデプロイする方法をご案内します。 ※本手順は ARM (リソースマネージャー モデル / V2)を対象にした記事になります。 ※本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。 (前提)仮想マシンスケールセットとは この記事を見ている方は、多少なりともVMSSに興味を持たれているかと思いますので、VMSSなにそれ?という人はいないかと思いますが、念のため振り返ります。 VMSSは、同一の仮想マシン(以下、VM)を複数同時に展開するためのCompute リソースです。VMSSリソースを作成すると、配下にVMインスタンスが展開されます。このVMインスタンスを必要に応じて数を増やしたり(スケールアウト)、減らしたり(スケールイン)できる技術です。現時点で1つのVMSS配下にVMインスタンスを最大1000台まで展開することができます。 一般的には、このインスタンス増減を、あらかじめ設定した条件に合致した時に自動実行する自動スケールと呼ばれる仕組みと併用されます。 例えば、Webサイトを運用しており、サイトアクセスによって各VMインスタンスのCPU使用率が一定値以上になったら台数をxx台自動的に増やすといったシナリオや、特定の日時においてサイトアクセスの上昇が見込まれるので予め台数増加の実行をスケジューリングしておきたいといったシナリオでも利用されます。他にも大規模計算を実行するためのHPC基盤としても利用されることもあります。 VMSSは独立した技術で利用されるよりも、多くのシナリオで他の独立したAzureの機能(リソース)と組み合わせて利用されます。そのため、まったく触れたことのない方にはとっつきにくい部分があるかも知れません。 これからVMSSの利用を検討されるという方は、現在 Azure ポータルからで基本的な構成でデプロイすることが可能なので試しに作成することをお勧めします。 Azure Portal を使用して Virtual Machine Scale Set を作成する方法 https://docs.microsoft.com/ja-jp/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-portal-create/ こちらを作成するとVMSSだけでなく、ロードバランサ、仮想ネットワーク、パブリックIPアドレスといった様々なリソースが同時に作成されることが確認できると思います。これらリソースは次のようにそれぞれ仮想マシンスケールセットと連携しています。 目的 AzureポータルからVMSSをデプロイいただいたことがある方なら、デプロイ時にWindows ServerやLinuxディストリビューションなどのOSイメージをご選択した覚えがあると思います。Azure ポータルから選択できるOSイメージは、Azure Marketplaceで公開されているイメージです。 VMSSのスケールアウトによってインスタンスが増える場合は、このVMSSと紐づいたイメージをベースに作成されます。 これはつまり、独自のアプリケーションやミドルウェアをVMSSで利用したい場合は、VMSSのデプロイ時にカスタマイズ設定を施したイメージを事前に指定しておかないといけないということを意味します。イメージをカスタマイズする上で、当イメージを基に VM が展開された場合に、初期設定を自動完了させ、既存のアプリケーションに加わるなどの処理を OS の起動スクリプトを通じて自動化しておくことが重要です。例えば、Web アプリケーションであれば、VM が作成された段階でバックエンドのデータベースに連携し、すぐにサービスが展開出来るようなセットアップを完了させる処理ということになります。 これはVMSSを利用してシステムを実運用する、ほとんどのシナリオで注意しないといけないポイントだと思います。 本記事では、VMSSのデプロイ時に自身で作成したイメージを指定してデプロイする方法をご紹介します 手順 本書では、次の流れに沿って自身で作成したイメージを指定してVMSSをデプロイする方法を次の 3 STEPでご紹介します。 仮想マシンで一般化おこないOSのマスターイメージを作成する 一般化済みのイメージをAzureの「イメージ」リソースとして登録する 登録した一般化イメージからVMSSをデプロイする…

0

Azureで単数NICの仮想マシンを複数NICにする

こんにちは、Azureサポートチームの三國です。 今回は、単数NICの仮想マシンを複数NICにする方法についてご案内します。 本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。 はじめに NICとは、ネットワークインターフェイスカードの略です。Azure Portalから仮想マシンを作成するときは単数NICがついている仮想マシンしか作成できないのですが、Azure PowerShellなどを使うことにより最初から複数のNICを持った仮想マシンを作成することができます。 最初から複数NICを持った仮想マシンを作成する方法は、下記のドキュメントをご覧ください。 複数の NIC を持つ Windows 仮想マシンの作成と管理 今回のテーマは、「後からNICの数を複数にしたい!」というケースです。 実は、2つのNICを持つ仮想マシンにもう1つNICを加えることは難しくありません。 本ブログにおいてこのケースは直接的には取り上げませんので、以下のドキュメントをご参照ください。 (なお、本ブログを読んでも方法については理解できるようになります) 既存の VM への NIC の追加 それでは、早速中身に入りましょう。 単数NICの仮想マシンを複数NICにする 以下のPowerShellを用いてください。解説は後述します。 注意!!このスクリプトにより仮想マシンが停止(割り当て解除)されます。 注意!!このスクリプトでは新しいNICにNSGを割り当てません。割り当てたい場合はスクリプトをカスタマイズするか、NIC追加後にポータルより行ってください。 ###################################################################### ### ログインとサブスクリプション指定 ###################################################################### Login-AzureRmAccount $mySub = Get-AzureRmSubscription | Out-GridView -Title “Select an Azure Subscription …” -PassThru Select-AzureRmSubscription -SubscriptionId $mySub.Id ###################################################################### ###基本情報を設定する ###なお、パブリックIPアドレスの割り当ては任意です ###################################################################### $resourceGroup = “リソースグループ名” $location…

0

Azure Tableストレージに格納されたゲストOS診断データを時間指定で削除する

こんにちは、Azureサポートチームの三國です。 今回は、Azure Tableストレージに格納されたゲストOS診断データを時間指定で削除する方法についてご案内します。 本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。 はじめに Azure Table ストレージには、表形式で情報を格納できます。たとえば、仮想マシンの”ゲストOSの診断”情報を格納できます。格納は仮想マシン作成時などに設定できます。 この”ゲストOSの診断”を利用することで、VMのパフォーマンス情報などを得ることができ、それはポータルから確認ができます。   “ゲストOSの診断”データは、たとえばストレージエクスプローラなどで下図のように蓄積されていることを確認できます。 さて、このデータはどれくらいの期間保管されるのでしょうか? ストレージアカウントの診断ログアーカイブはリテンションというパラメータがあり、保管期間を指定することができます。 しかし、現時点では”ゲストOSの診断”データについては保管期間の管理ができません。 そのため、過去にさかのぼって診断データを確認できるメリットはありますが、保管しているデータの容量に対して課金が発生します。課金体系の詳細はこちらをご覧ください。 今回は、Tableストレージに蓄積されたゲストOS診断データについて時間を指定して削除するPowerShellスクリプトをご紹介します。 クラシックモデルについては、こちらで同機能の PowerShell のサンプルが公開されていましたが、ARM についてはサンプルはありませんでしたので、今回、公開する事にしました。 スクリプトのご紹介 以下、powershellスクリプトになります。.ps1形式で保存し、powershellとしてお使いください。 ClearOutAzureTableStorageEntity_ARM 必要な引数は以下です。 StorageAccountName: “ストレージアカウント名” TableName: “テーブル名” ResourseGroupName: “リソースグループ名” StartTime: “削除開始時間” EndTime: “削除終了時間”   StartTime(削除開始時間)、EndTime(終了時間)はGMT(グリニッジ標準時)で以下のフォーマットで指定してください。 mm/dd/yyyy hh:mm:ss AM(or PM) 例: 10/13/2017 06:00 AM 以下は実行例です。 PS > .\scriptForBlog.ps1 -StorageAccountName saforblog -ResourseGroupName rgForBlog -TableName WADPerformanceCountersTable -StartTime…

0

Nested Hyper-V を使った VM の復旧

こんにちは、Azure サポート部の石井です。   Azure で Nested Hyper-V を使ってみました、というポストです。サポートらしく、トラブルシュート用に活用してみます。   Azure では RDP (Windows)/ SSH (Linux) 接続でのみ仮想マシンが管理できます。このため、システム破損が起きた・誤った変更を加えてしまったといったトラブルにおいて、RDP や SSH が何らかの理由で起動に至らない場合、何がおきたのかわからないまま再構築やバックアップからのリストアを余儀なくされるケースがありました。   原因追求のため、トラブルシュートをしようと思っても、オンプレミスに VHD をダウンロードしてオンプレミスの Hyper-V 環境で VM を立ち上げる必要があったため、そんなハードウェアが自社内に無いという場合に手詰まりとなってしまいます。 今回は、新機能である Nested Hyper-V を使って、Azure 上の VM からリモート接続できない VM を起動させて、コンソール接続による動作確認やトラブルシュートを行える環境を構築する方法をご紹介します。   Nested Hyper-V とは、端的にいうと Hyper-V の仮想マシンの中にさらに Hyper-V の仮想マシンが立ち上げられるという機能です。Windows Server 2016 の新機能として登場し、Windows Server でのコンテナー テクノロジーの活用や、Hyper-V を流用したセキュリティ向上などが見込まれています。     <必要なもの> Dv3…

0

Azure Backup Agent で使用されるキャッシュ フォルダのサイズ要件について

こんにちは、Azure サポート チームの世古です。   今回は Azure Backup Agent (MARS エージェント) を使用したバックアップを実施した際に Azure 上に送信する前の一時領域として使用されるキャッシュ フォルダのサイズ要件についてご案内いたします。 以下の公開情報にございます通り、キャッシュ フォルダの最小サイズ要件はバックアップするデータ容量の 5 %  です。   https://docs.microsoft.com/ja-jp/azure/backup/backup-azure-file-folder-backup-faq キャッシュ フォルダーの最小サイズ要件を教えてください。 キャッシュ フォルダーのサイズによって、バックアップするデータ量が決まります。 キャッシュ フォルダーは、データの格納に必要なスペースの 5% に設定する必要があります。   尚、この要件は最小要件となり、使用される容量についてはファイル数に応じ増加します。その為、100 万ファイルを超える場合には、最大で 20 % 程度使用される可能性がございます。 またこのキャッシュ フォルダはバックアップ データからの復元の際にも使用されます。復元速度を上げる為、一時的にキャッシュ フォルダに復元するデータを保持し、実際の復元場所にリストアします。復元処理においては、復元するデータ容量の 5 ~ 10 % 程度が使用される可能性がございますので、必要量の空き領域をご用意ください。   上記内容よりバックアップおよびリストアに使用されるキャッシュ領域の容量を検討いただけますと幸いです。またサポートとしては、キャッシュ領域はバックアップするデータ容量の 15 ~ 20 % 程度の空き領域を確保頂くことを推奨しております。   以下キャッシュ フォルダを他の場所に変更する手順をご案内します。  …


ExpressRoute のエッジ ルーターのメンテナンス通知に関する説明

本日、ExpressRoute のエッジ ルーターにおけるメンテナンスのお知らせがお客様に送信されました。 お知らせにもあるとおり、今回のメンテナンスにおいてお客様のサービスに影響が発生することは想定しておりません。この点についてはご安心いただければと思います。ただ、送信されたお知らせの文面は最低限のものですので、どのようなメンテナンスが予定されており、どういった理由で影響がないのかなど、本ブログ記事にてご説明をさせていただきます。 これまでにも何度か実施されているメンテナンスと同じですので、内容についてはご存知の方もいらっしゃるかと思いますが、参考になりましたら幸いでございます。

0

ネットワーク制限がかかった環境から Azure 上のリソースを管理する場合のベスト プラクティス

こんにちは、Azure サポート部の石井です。   オンプレミスで Proxy サーバーがある環境にて、ネットワーク制限がかかった状態から Azure Portal を操作したい、というご要望をいただく事があります。 派生案件としては、そのような環境から、特定のページや操作だけがうまくいかず、スマートフォンのテザリングなど公共網からのアクセスだと問題が無い、というケースに行き着きます。 これは、Azure Portal の実装上、URL フィルターがある環境からのアクセスが難しい、ということが原因です。今回はこのような環境からのベストプラクティスについてご紹介します。   ポータルの仕組み 一見すると、portal.azure.com (と事前認証の Web サイト) にアクセス許可を与えればいいのでは?と考えられるのですが、実は構造上複雑です。   具体的には以下が理由です。 1. ポータルはパフォーマンス アップのため、CDN (キャッシュ サーバー群) とも連携し、情報を様々なバックエンドから取得する、役割分担を前提とした設計となっています。(クロス オリジン リソース共有 = CORS と呼ばれるアーキテクチャです。) このバックエンドの URL はコンポーネントにより様々です。 2. クラウドでは常に新しいサービスが追加・更新され、それに伴って URL の変更や追加が行われています。また、機能の変更だけでなく、URL をホスティングするインフラ側の理由にて変更が生じるということも考えられます。このため、今確認できる URL が将来同じとは限りません。   このことから、URL 一覧を把握し、あらかじめ Proxy で許可させておく、という利用方法には適しておりません。   現行で公開情報から導き出した URL 一覧は後述いたしますが、それでも足りない、あるいは今後動作が変わったという場合、お客様にて Fiddler という解析ツールを用いて…

0

自分の VM に何が起きるか把握する Instance Metadata Service のご紹介

2017/10/13追記: 一時停止 (Freeze) を伴うメンテナンスのサンプルを文末に追記しました。   こんにちは、Azure サポート部の石井です。   今回は、Azure の Instance Metadata Service について、実例を交えて紹介します。VM 内部から、自身のメンテナンス時間が把握でき、猶予時間内に適切な処理が行えるというものです。   詳しい内容は以下技術情報をご参考ください: Windows VM 用の Azure Instance Metadata Service https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/instance-metadata-service Azure Metadata Service: Windows VM のスケジュールされたイベント (プレビュー) https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/scheduled-events   [機能の紹介] VM の内部のシステム管理者やアプリケーション開発・運用者から見ると、Azure プラットフォーム側から何らかの操作をされる、ということは、実際にシステムに影響が出るまで分からないものです。それが問題となるケースにおいては、Instance Metadata Service を使うことで事前に対応ができる猶予時間を得られることができます。 Azure VM の内部から、以下のような操作を知ることができるというものになります。 ・非通知のメンテナンスとして VM を一時停止 (フリーズ) 状態にして行うもの ・Azure 仮想マシン管理者のポータル・CLI などの操作による再起動や再デプロイ マイクロソフトが行うメンテナンスのほか、Azure のリソース管理者が行う再起動・再デプロイなど、広義の意味でのメンテナンス作業があるかどうか、VM 内部でプログラム的に知ることができるということがメリットです。…

0

Azureで仮想マシン名を変更する

こんにちは、Azureサポートチームの三國です。 今回は、Azureの仮想マシン名を変更する方法および注意点についてご案内します。 本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。 目次 1. はじめに: 仮想マシン名とは 2. 注意: 仮想マシン名は簡単には変更できない 3. 今回ご案内する手順の想定ケース 4. 変更手順 5. 仮想マシン名の代わりにタグでも管理できる 1. はじめに: 仮想マシン名とは 今回変更する”仮想マシン名”とは、Azureのリソースとして表示される名前を指しています。 仮想マシンビューを開いたときに表示される”コンピュータ名”や、OS内で表示される”コンピュータ名”、”ホスト名”とは異なりますのでご注意ください。ただし、仮想マシン名を作成したときこれらの名前と同じに作成されます。 (注: こっちではない↓) 皆様はここにどのような名前を入れていますか?オンプレでサーバを管理するときと同様にシステム名などを入れることが多いかと思います。 システム名が変わったときに、古いシステム名のままサーバが残ってしまって、「このサーバは何者なのか」という問いを新規参画者から受けることも多いと思います。 Azureサポートでも、そういった背景から「仮想マシン名を変更したい」という問い合わせを受けることが多いためこのブログを書くに至りました。   2. 注意: 仮想マシン名は簡単には変更できない 簡単に変える手順を期待していた方、申し訳ございません。仮想マシン名を簡単に変更することはできません。 仮想マシン名はAzureが管理するリソース情報と密接にかかわっているためです。 今回ブログを書くにあたり、手順がわかっていても、20分程度かかりました。 また、”仮想マシン名”を変更するにあたりダウンタイムが発生する、というデメリットもございます。 その点を踏まえて、次項以降をご覧ください。 3. 想定ケース 今回はポータル操作だけで手順が完結できる、簡単なケースをご紹介します。たとえば非管理対応ディスクを使うと、ARMテンプレートやPowerShellでの操作が必要となります。 (必須条件)   -管理ディスクを使っている   -ネットワークインターフェイスが変更となる   -ホスト名は変更しない(承前: ホスト名とAzureから見える仮想マシンの名前は異なります)   -クラシックポータルを使っていない (オプション条件)   -データディスクを使用している   -可用性セットに入っている 4. 変更手順…

0