1TB 以上のディスクを持つ VM の Azure Backup (Private Preview)

こんにちは、Azure サポート チームの世古です。 現在 Azure Storage において新しいディスク サイズが最大 4 TB までサポートされるようになりました。 2018/1/21 より管理ディスクを持つ VM においてもサポートされるようになりました。 Azure Storage の新しいディスク サイズ – 4 TB までの VHD サイズがサポートされるようになりました 12 月までは Azure IaaS VM のバックアップにおいては 4 TB のディスクを持つ VM のバックアップはサポートしておりませんでしたが、Azure Backup の機能追加により非管理ディスクのみ Private Preview として機能を提供しております。管理ディスクについては、1 月を目途に Private Preview の提供を進めております。 Instant recovery point and large disk support for Azure Backup…


Azure Site Recovery を用いた Azure IaaS 仮想マシンの Azure to Azure のレプリケーション

こんにちは、Azure サポート チームの伊東です。 Azure Site Recovery を用いて Azure IaaS 仮想マシンを別リージョンの Azure 仮想マシンへとレプリケーションする機能 (Azure to Azure) のプレビュー版が、先日公開されました。今回はこの新機能の概要と、レプリケーションの有効化後、フェールオーバー、フェールバックする際の手順をご紹介します。 ※ Recovery Services コンテナーは作成済みとします。 概要 Azure Site Recovery は、プライマリ リージョンの仮想マシンや物理サーバーを継続的にレプリケートし、障害発生時にセカンダリ リージョンのサーバーにフェールオーバーすることで障害から素早く復旧するためのソリューションです。 今まで Azure Site Recovery ではオンプレミスのサイト間、もしくはオンプレミスのサイトと Azure 間でのみレプリケートすることが可能でしたが、Azure 上の仮想マシンを別のリージョンにレプリケートすることは出来ませんでした。しかし、2017 年 5 月 31 日 (日本では 6 月 1 日) から、異なる Azure リージョン間でのレプリケーション機能が公開 (プレビュー)されました。 この新機能により、Azure 仮想マシンを自動的に別のリージョンにレプリケートし、障害発生時にフェールオーバーすることが可能になりました。 メリット シンプルでコスト効率に優れたバックアップ (BaaS) ソリューション…


Runbook の Update-AzureRmVM コマンドが ‘Vhd’ cannot be null. で失敗する

こんにちは、Windows プラットフォーム サポートの世古です。 今回は Azure  Automation の Runbook 実行でよくお問い合わせいただく内容についてご紹介させていただきます。 Runbook の実行で Update-AzureRmVM が ‘Vhd’ cannot be null. で失敗する事象がございます。この問題は以下の条件で発生します。   ・対象の VM が管理ディスクを持つ ・モジュールのバージョンが最新でない   この問題はモジュールのバージョンを最新に更新いただく事で回避されますので、以下の公開情報の手順を実施下さい。 Azure Automation の Azure PowerShell モジュールを更新する方法 以前の Powershell モジュールにおいては、管理ディスクを操作可能な実装が含まれていなかった為、VM の情報を正常に取得出来なかった為、本問題が発生いたします。その為、モジュールのアップデートをご検討ください。   ※本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。


Azure Storage の新しいディスク サイズ – 4 TB までの VHD サイズがサポートされるようになりました

こんにちは、Azure サポート部の石井です。   これまで 1 TB (1023 GB) が上限だった VHD サイズが、4 TB (4095 GB) 上限までサポートされるようになりました。   Announcing large disk sizes of up to 4 TB for Azure IaaS VMs https://azure.microsoft.com/en-us/blog/azure-introduces-new-disks-sizes-up-to-4tb/   本日 6/16 時点では、まだポータル UI からの作成や拡張ができないので、スクリプトで行っていただく必要があります。 来週から月末にかけて、ポータルからも実行ができるように開発が進められています。 <2017/7/11更新> ポータルから 1023 GB 以上への VHD のサイズ変更が行えるようになりました。VM は停止状態で行ってください。   チェックすべき点について、おまとめしました。   FAQ ドキュメントのまとめ   まずはじめに、以下の FAQ ドキュメントの留意点についておまとめしておきます。  …

2

Microsoft Azure Backup でのスケジュール バックアップが実行されない

こんにちは、Azure テクニカル サポート担当の伊東です。 オンプレミスのファイル/フォルダの情報を Azure 上にアップロードする方法として Microsoft Azure Backup (MARS エージェント) でのバックアップ方法がございます。このバックアップにて対象環境の構成によりスケジュールでのバックアップが実行されない問題がございます。これは Microsoft Azure Backup で作成されたタスク スケジューラーのタスクを実行するユーザー アカウントに影響して発生します。その為、以下の回避策を実行して正常にスケジュールでもバックアップが実行されるかご確認ください。 対処策 1 1.以下のパスに移動します。 C:\Program Files\Microsoft Azure Recovery Services Agent\Bin\Modules\MSOnlineBackup (MARS エージェントのインストール パスですので、場所を変更されている場合には、そちらのパスをご確認ください。) 2.MSOnlineBackup.psd1 をコピーします。 3.以下の 2 つのパスにコピーします。 C:\Windows\System32 C:\Windows\System32\WindowsPowerShell\v1.0 4.スケジュールのバックアップを実行します。   上記対処策で問題が解決しない場合には、以下の手順にてスケジュール タスクの変更を検討ください。 対処策 2 1.タスク スケジューラーを起動します。 2.[タスク スケジューラー ライブラリ] – [Microsoft] – [OnlineBackup] を開きます。 3.2 つスケジュールがありますが、それぞれのプロパティを編集します。…


インターンシップでのプロジェクト – App Service と SQL Database サービスを使った構成で災害復旧の計画を立てる

こんにちは、マイクロソフト Azure サポートにてインターンシップをしているニューヨーク大学在籍の福川です。 インターンシップ プロジェクトの中で先ほどのポストに加えて、Azure の災害対策について研究をしてみました。   Azureは非常に信頼性が高いですが、Webサイト、Webアプリケーション、およびデータの可用性を予期できないイベントで危険にさらす可能性があります。もし地震等で、使っていたデータセンターがオフラインになったらどうしますか?休日に急に今までにない大量のユーザートラッフィクがアプリをアクセスして運用が停止してしまったらどうしますか?このようなイベントへの準備をしておくことはとても重要です。   Azureではこの様な時にアプリの運用を守るTraffic Managerや、データを保管するGeo-replicationツール 等を提供しています。この二つのサービスの機能性を確かめる為に簡単なアプリを作って色々と実験してみました。 この記事ではAzureのWeb Appサービスを使っての簡単なウェブアプリの作り方と、Azure のtraffic managerとgeoreplicationサービスを使ってのディザスターリカバリーの概略を述べます。 まず、アプリの構造から説明します。例として使う アプリはユーザーの選んだ科目に関連する情報をAzureのSQLデータベースから引っ張り出し、表示します。このデータベースは東日本のデータセンターに置きました。そしてこのデータセンターに異常があった時の為にgeo-replicationサービスを使って西日本のデータセンターにも私のデータベースをバックアップしました。もし東日本のデータセンターから私のデータベースがアクセスできなくなっても、西日本にデータが保存されているので心配ないです。この機能を確認するためにAzure portalで東日本のデータベースをフェールオーバー機能で西日本のデータベースとスウィッチしてみました。ブラウザーで確認すると、フェールオーバー完了後、アプリが異常なくデータをアクセスすることに成功しました。この様なチェックで、geo-replicationの機能の成功が観れました。もし使っていたデータベースにアクセスできなくなってしまっても、geo-replicateされたデータベースでバックアップが取れているのでデータ紛失の心配はないですね。しかし、このバックアップは常にされていないのでRPOによりディザスター何分か前までのデータが紛失する可能性があります。 次はもしウェブアプリ・ウェブサイトのが何かしらの理由で使えなくなってしまったら、というシナリオをみてみました。これにはtraffic managerを使います。このドキュメントを参考にしました 。ドキュメントによると、一つのエンドポイントが使えなくなった時点から健康なエンドポイントへtraffic managerがスウィッチするまではtraffic managerの DNS time-to-live足す2分かかるようです。 Traffic managerの機能を確かめるためにまずウェブアプリの同一コピーを違う場所のデータセンターに作りました。そして、両コピーをエンドポイントとしてポータル上でtraffic manager繋げました。このセットアップが終わった後に、一つのエンドポイントを無効にしてみました。¬¬エンドポイントを無効にするというのはtraffic managerにそのエンドポイントが使えなくなったと伝えることです。この状態でTraffic managerがどう反応するかブラウザーとパワーシェルで確認しました。エンドポイントのスウィッチ完了後、ブラウザーは通常通りアプリにアクセスが出来、パワーシェルでアプリのIPアドレスを確認すると健康な方のエンドポイントのIPアドレスに変わってました。 ディザスターリカバリーの設定と確認ができました。 Azure Appサービスを使ってウェブアプリを作成  Azureポータルにログインし、 [新規]→[Web App]→をクリックします。 パフォーマンスと操作のしやすさをを意識しリソースグループを私と仮想ユーザーがいるエリア、東日本で作成します。 アプリをローカルで開発します。 私はsublime text editorでHTML, CSS, PHPを書きました。 コードをAzureにアップロードします。 まず簡単なindexとウェブサイトの骸骨を載せます。 FTP/デプロイユーザー名はポータルでApp Servicesの [概要]にあります。 パスワードはazureアカウントパスワードと同じです。 私はFTPを使うfetchというトランスファークライアントを使いました。 この時点からアップロードした内容がブラウザーで見れるようになります。 アプリが使うSQLデータベースを作成します。 Web App…

0

Azure サポート チームでのインターンシップ – Azure Batchプロジェクト

自己紹介 今年の夏、Microsoftインターンの福川遥です。アメリカで生まれ、フィリピンで育ちました。今はニューヨークの大学、New York Universityで数学を勉強している4年生です。一昨年休学をして日本語を勉強するために初めて日本に住んでみました。それから日本での生活が気に入り、将来は東京で働きたいと思うようになりました。去年からプログラミングを始め、様々なインターンシップをやっている 内にテクノロジーを触る仕事に就きたいと決めました。まだプログラミングも日本語も勉強中ですが、Microsoftのインターンシップ一ヶ月の期間でやったプロジェクトを皆さまに披露させていただきます。   Azure Batchで並列計算 プロジェクトの一環とし、何千個かのWikipediaの特定のアメリカ人の人種に関わる記事に一番多く使われている言葉をAzure batchで数えてみました。結果が出た後、Azure Batch でノード数によってどのくらい計算のスピードが変わるか気になり始めました。しかし、私が使っていた目的だと計算の時間がノード数だけに影響されるだけでは無く、 記事の長さによってかなり計算時間に差が出てしまうことに気づきました。よって、この手法だと Azure Batch 単体のパフォーマンス分析には不向きだと思い、数学を用いてノード数と計算速度の関係を調べるというアプローチに変更しました。 ノード数の影響を観察直接するために、Azure Batchで数値積分をするプログラムを書いてノード数を変えながら時間を計ってみました。 バイアスのないテストをするために、定積分 をリーマン和で計算させるプログラムを作りました。まず区間、x ∈[0,100π] 、を一億個の等しい子区間に分けてそれを100個のタスクに入れてAzure batchに送り、リーマン和を計算しました 。 全部の子区間を同じメッシュサイズにすることで問題だった記事の長さの誤差等の問題に影響されずノード数だけに影響される計算のスピードが測れました。実験の結果、ノード数(x)を変えると時間(t)はこのように変わることが判明しました。 (この数式ではtが計算にかかった時間、xがノードの数、cはコンスタントです)つまり、ノード数を増やすと計算時間は短くなりますが、ノード数を増やすにつれ、計算時間から削れる時間はどんどん減ってしまいます。すなわち、計算時間を半分にするには使っているノード数の4倍のノード数を使わないとならないということです。 グラフから見える通り、この数式は結構明確な的確な関連性を表してます。c=1271.4はプログラムの内容によるので、気にしなくていいです。 ノード数17 のケースを例に挙げると、ある程度のノード数を超えると、合計計算時間が長くなるケースもありました。これは Azure Batch で仮想マシン (ノード) を準備する時間にも依存するという推測をしています。 なお、Azure batchの制限により、このスピードの数式はノード数20個までしか使えません。。特別に申請しない限りノード数20個までしか使うことができません。よって、20個以上のノードをプログラム上で使おうとしても、結果として20個しか使われません。   Azure Batchプロジェクト まずAzure Batch でサンプルの Python コードを使えるようにします。 Azureポータルから[新規]→ [Batch サービス]をクリックします。 [作成]をクリックします。 ここで、必要な欄に情報を入力します。全て同じデータセンターの場所を選んだ方が通信スピードが速いので、ここでは例として全て東日本を選択します。 このチュートリアルを見ながら処理を進めてください。ここでは pythonを例として使うため、pythonのコードとチュートリアルを閲覧して進めています。PythonのコードはAnaconda Spyderを使って記述しています。 サンプルコードをダウンロードし、 “python_tutorial_client.py” とを開きます。…

0

スケジュールされた Runbook で最新のモジュールが使用されるよう機能改善されました

10 月 5 日更新 現在 Automation アカウント内にてモジュールの更新を行う際に、下図のようにスケジュールを再度関連付けする必要がある旨のメッセージが表示されてしまい、 実際はどうなのか ?? と多数のお問合せをいただいております。 実際には以前にご案内しておりますとおり、スケジュールとの関連付けを再度行う必要はございませんのでご安心ください。 現在開発にて誤ったメッセージが表示されないよう、修正を行っており、次回の改修にて上図のメッセージは表示されなくなります。 紛らわしい表記となり大変ご迷惑をおかけいたしますが、改修まで今しばらくお待ちください。   こんにちは、Azure サポート チームの世古です。 以前より多くのお客様からご要望がございました Azure Automation の機能追加についてご紹介いたします。 以前の Runbook においては、スケジュールで実行される後続のジョブは、スケジュール作成時の Automation アカウントのモジュールが使用されておりました。その為、 スケジュールされた Runbook で更新されたモジュールを使用するには、その Runbook でスケジュールのリンクを解除し、もう一度リンクする必要がありました。その結果 runbook で Azure PowerShell モジュールのコマンドレットを使用して Azure リソースを管理する場合、モジュールを最新に保つために 1 か月に 1 回程度この更新プロセスを実行する必要がございました。 しかし、今回の機能改善により Automation アカウントのモジュールを更新しても、スケジュールの再リンクが不要になり、モジュール更新後は最新版のモジュールを自動で使用されるように変更されました。現在既に作成された Runbook については 7 月 12 日から反映されます。 今後もユーザー様にとって使いやすい製品となるよう機能改善を進めて参りますので、ご要望がある場合には、Feedback サイトより要望を追加いただけますと幸いです。


ExpressRoute のピアリング構成情報を見ると表示されない

みなさんこんにちは、Azure テクニカルサポートチームの平原です。本日はポータル上で ExpressRoute の構成確認をする際に発生する表示の問題の件について、ご案内をいたします。少しでもお役に立てば幸いです。 問題 ExpressRoute の各種ピアリング構成(ルート情報など)を確認すると、うまくデータが取得できない。   原因 ExpressRoute のデータはポータル (https://portal.azure.com) で表示する場合、リソースマネージャモードで表示を行いますが、作成時の状況によっては、リソースマネージャのデータストアに、ExpressRoute の構成情報の最新情報がアップデートされていない場合があります。   対策 対策としては、以下の方法にて対応可能です。 ポータル (https://portal.azure.com) 上から ExpressRoute の構成を開き、ExpressRouteの構成情報の画面にある [最新の情報に更新] をクリックします。 再度、ポータルから各ピアリングの情報を取得できるかどうかをご確認ください。 PowerShell からデータを更新する方法もございます。 Azure PowerShell コマンドで、以下のコマンドを実施して、ExpressRoute の情報を取得し更新します。 $exr = Get-AzureRmExpressRouteCircuit -ResourceGroup <リソースグループ名> -Name <ExpressRoute 名> Set-AzureRmExpressRouteCircuit -ExpressRouteCircuit $exr   以上ご参考になれば幸いです。

0

SSL 証明書の更新に関するアナウンス

本日、Azure サービスの証明書更新に関する通知がお客様に送信されました。 この通知は日本のお客様に対しても英語で送信されてしまい、すぐに対処が必要なのか、なにかリスクが発生しているのかなどがわかりにくく、ご心配をおかけしてしまっているのではないかと思います。 今回の通知について、米国本社の下記ブログ記事をベースに、日本語版のご案内を以下に用意いたしました。以下の内容にて、ご覧いただけますと幸いです。 参考: Azure TLS Certificates changes

1