JAZUG

2月23日の空は雷雨でした

/ buchizo / コメントする

 

というわけで2月23日は盛大にWindows Azureが落ちてました。正確にはWindows Azure Storageの証明書の問題で、Storageに引っ張られてACS、管理ポータル、Media Services、ServiceBus、Web Sitesなどが軒並みアウトという状況。

ダッシュボードの様子は Windows Azure Armageddon で見れます。（アルマゲドンとか言われてるし）

まぁ自分管理のサービスはなかったにせよ、多数の悲鳴が聞こえてきたわけで、アルマゲドンとか言われるのもわかります。

事の発端というか認識はこのツイートから。

image

 

で。ダッシュボードみたらあれよという感じです。原因はStorageで仕様している証明書の期限切れです。（またか）

 

このあたりPKIやってると基本のキみたいなところですが、どうも手動オペレーションっぽいところはまだまだノウハウたまってないというか共有できてないのか、不十分っぽいですね。これを気によりよくしてもらいたいです。

※誰かが言っていましたが原因がわかっている障害だけにまだましとも言えますが「ダサい」障害なのは間違いない…

細かい対応の経緯とかはこちらで見れます。

Feb 22 2013 8:44PM – We are experiencing an issue with Storage Worldwide and this is impacting all dependent services. We are actively investigating this issue and working to resolve it as soon as possible. Further updates will be published to keep you apprised of the situation. We apologize for any inconvenience this causes our customers.

Feb 22 2013 9:30PM – We identified that HTTPS operations (SSL transactions) on Storage accounts worldwide are impacted. We are actively investigating this issue and working to resolve it as soon as possible. Further updates will be published to keep you apprised of the situation. We apologize for any inconvenience this causes our customers.

Feb 22 2013 9:45PM – Access Control v2, Service Bus, WindowsAzure.com and WebSites services are impacted by Storage service degradation worldwide. We are actively validating the recovery steps to resolve it as soon as possible. Further updates will be published to keep you apprised of the situation. We apologize for any inconvenience this causes our customers.

Feb 22 2013 10:15PM – We are currently validating the repair steps in our test environment. Further updates will be published to keep you apprised of the situation. We apologize for any inconvenience this causes our customers.

Feb 23 2013 12:15AM – We have initiated the recovery on some of the impacted clusters. This is expected to take a few hours. We are also validating faster recovery options. Further updates will be published within 2 hours to keep you apprised of the situation. We apologize for any inconvenience this causes our customers.

Feb 23 2013 2:15AM – The test deployments on two of the impacted storage clusters are making steady progress. We are evaluating accelerated repair options to mitigate the impact as soon as possible. We expect to finalize the repair steps within 2 hours, at which time we’ll be able to provide more details. We apologize for any inconvenience this causes our customers.

Feb 23 2013 4:15AM – The test deployments on two of the impacted storage clusters are making steady progress. We finalized the accelerated recovery steps and will execute them on remaining Storage clusters. Further updates will be published within 2 hours to keep you apprised of the situation. We apologize for any inconvenience this causes our customers.

Feb 23 2013 5:30AM – We executed repair steps to update the SSL certificate and majority of our customers are likely to notice recovery. Further updates will be published to keep you apprised of the situation. We apologize for any inconvenience this causes our customers.

Feb 23 2013 7:30AM – Restoration of Storage service is complete on majority of the clusters in the sub-region and we are monitoring SSL traffic. We will continue to monitor the health of the service and address any intermittent failures before declaring the sub-region fully recovered. We apologize for any inconvenience this causes our customers.

Feb 23 2013 9:00AM – We have executed repair steps to update SSL certificate on the impacted clusters and have recovered to over 99% availability across all sub-regions. We will continue monitoring the health of the Storage service and SSL traffic for the next 24 hrs. Customers may experience intermittent failures during this period. We apologize for any inconvenience this causes our customers.

 

あと話変わりますがWadeが証明書が期限切れかどうか確認するコード書いてるので参考まで。

結局、9～12時間ほど止まってたのかな。今はもちろん復旧していますがだいぶ泥臭い対応したようで、今後恒久対策など終われば公式発表がちゃんとあると思います。

→ RCA （根本原因解析）でました

今回たまたまAvakashのツイートみてわかりましたけど、日本語での対応状況をツイートしたりどこかに載せてもらえると嬉しいですね。

というわけで2月は毎年晴天じゃないAzureさんでした。来年以降は快晴に期待。FeedBackとか手伝えることがあればやりますけども。

Windows Azure Media ServicesがGAしました

/ buchizo / 1件のコメント

GAは唐突に。そう唐突に。

ScottGu’s Blog （日本語訳）にもある通り、Windows Azure Media Servicesが一般提供（General Availability）されました。

一般提供が開始されたということは、SLAが付いたということです。ちょっと日本語のフォントがおかしいですがSLAはこちらから入手できます。

※フォント指定しなおしたらちゃんと見えます。

SLAは2種類あって1つはオンデマンドストリーミングの月間稼働時間、もう1つはメディアサービスのエンコードREST APIのトランザクション数のようです。どちらも99.9%を下回ると10%返金のようですね。気になる人はちゃんと読みましょう。

気になるお値段ですが、以下の4種類で変わりますので注意。

メディア サービスのエンコード

とりあえずメディアサービスのエンコードに関しては2013年2月17日までは課金されないようです。課金単位は「処理されたデータ量」で、データの入力とエンコードされたデータの出力両方が対象です。※保存先のストレージとそれにかかるデータ転送料も別途かかります。

最初の5TBまでは 173.95円/GByte。

メディア サービス エンコードの占有ユニット

占有ユニットを使用してエンコードの並列処理ができますが、その占有ユニットあたり8,653.59円/月かかります。ちょっと計算がややこしいようです。

アカウントでプロビジョニングされた状態の占有ユニットの最大数を使用して日割りで計算されます (24 時間単位)。たとえば、11:00 にエンコードの占有ユニットを 5 個購入した後、15:00 にその数を 3 個に減らした場合、その日は 5 個の占有ユニットに対して料金が発生します。23:00 にエンコードの占有ユニットを 5 個購入した後、翌日 10:00 にその数を 3 個に減らした場合、1 日目は 5 個の占有ユニットに対して料金が発生し、2 日目も、最初の 10 時間は 5 個の占有ユニットを所有していたため同様の料金が発生します。

まぁ、注意しましょう、ということですね。占有ユニットを使わない場合はこの費用は掛からないみたいです。

メディア サービス オンデマンド ストリーミング

オンデマンドストリーミングする場合、ユニットあたり17,394.59円/月かかります。アクティブだった占有ユニットの最大数の24時間単位な日割りで計算なのでこちらも注意。またAzureからのデータ送信は別途費用が発生します。

メディア サービスのパッケージ化

パッケージングそのものは無料でOK

というわけで料金詳細はこちら。

ちなみにオンデマンドストリーミング、エンコーディングについては管理ポータルの「スケール」で変更することができます。既定はどちらも占有ゼロ状態なので安心ですね（？）

image

 

Windows Azure Media Servicesを使ったサービスを開発する場合、Media Services libraries for .NET (Windows Azure Media Services .NET SDK) とMedia Services libraries for Javaの2種類があるようです。JavaのほうはAzure SDKに含まれてるからそっち見てね。とのこと。

Java使えるから一応WIndows/Mac/Linuxで開発できますね。

動画を見るクライアント側のSDKとしてはSmooth Streaming Client SDKがWindows 8用、SilverlightとWindows Phone用の2種類、それからOSMF向けPluginとiOS Media Player Frameworkが提供されています。

ということで、以下のようなクライアントたちをターゲットに配信できちゃいます。

  • Windows 8
  • iOS
  • Xbox
  • Flash Player (built using Adobe OSMF)
  • Silverlight
  • Windows Phone
  • Android
  • Embedded devices (Connected TV, IPTV)

やったね☆

動画の処理はメディアサービスが行ってくれますが、実際に大量の動画データをAzure側に送り込む必要があるので大変です。そんなときは一括アップロードしちゃいましょう。またUDPを使ったAsperaで高速アップロードも使えるので必要に応じて使いましょう。

というわけで、GAされて一安心。動画配信プラットフォームはSmooth Streaming＋Windows Azure Media Servicesでキマリですね。

Microsoft Hosting Solutions ServicesがGAしたよ

/ buchizo / 1件のコメント

以前、「Windows Azureを作ってみた」で紹介したMicrosoft Hosting Solutions Servicesが無事GA（General Availability）されたようです！

( ﾟДﾟﾉﾉ”☆ﾊﾟﾁﾊﾟﾁﾊﾟﾁﾊﾟﾁ

image

 

いわゆるクラウド事業者さん向けの、Windows Azure Webサイトや仮想マシンのホスティング環境を実現させるための機能集みたいなものです。

肝となるのは、すべてのベースとなるWindows Server 2012、ホストマシンを効率よく管理するためのSystem Center 2012（SP1）、それからユーザーにサービスを提供する入り口となる管理ポータルと管理用REST API集の3本です。

それぞれ細かいインストール方法などはMicrosoft Hosting Solutions Servicesのサイトにリンクがあるのでそちらを見てください。

雰囲気としては

こんな感じのインフラがゴールになります。

Multi-tenant PortalってのがWindows Azure管理ポータルっぽい画面ですね。

もちろんホスティング事業者向けなのでテナント別に機能制限かけたりすることもできます。

さぁこれであなたもAzureにならなイカ！

Windows AzureのCloud ServicesでVirtual Network

/ buchizo / コメントする

移行とかでDBはやむを得ずそのままでフロントは頑張った系の構成つくろう、つまり Windows Azureのクラウドサービス（Web RoleとかWorker Role）をVirtual Networkに参加させちゃおうという話です。

ついでに同じVirtual NetworkにWindows Azure 仮想マシンも参加させてサービス間通信もしちゃいましょう。

今回想定しているのはざっくり以下のような構成です。

バックエンドのVMはDBとかまぁそういうのを想定。通信の方向性としては双方向で通信できますが、今回はフロントのWebRoleからVMへのアクセスを想定します。

といっても対してすることは無く。Web RoleなどのCloud ServicesでのVirtual Networkへの参加方法と、VMのVirutla Networkへの参加方法、名前解決についてあたりを書こうと思います。

続きを読む →

Windows Azureのホスト名

/ buchizo / コメントする

以前、ロール間通信の話をちょっと書きましたが、なんかもっと簡単にできそうでした。（クラウドサービスが対象です）

Windows Azureのクラウドサービス上で稼働するインスタンスのホスト名は伝統的なピンクぷーどｒではなくRedDogの頭文字、RDで始まるランダムなもので、よくわかりませんでした。

ですが、サービス設定ファイル（*.cscfg）のRole要素でvmName属性を使用すると、指定した名前＋連番でインスタンスを設定してくれるようです。

サービス設定ファイルの例↓

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="WindowsAzure18_45" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="3" osVersion="*" schemaVersion="2012-10.1.8">
  <Role name="MvcWebRole1" vmName="KOSMOS">
    <Instances count="3" />
    <ConfigurationSettings>

以下略

ほうほう。実際にデプロイしてみましょう。

おお、確かにホスト名がvmNameで指定したもの＋連番（ゼロオリジン）です！

ちなみにDNSサフィックスは

02158fc001144d09bf43a37f3660d936.penguindrum.3216464207.asiaeast.internal.cloudapp.net

となってますね。

最初の赤字部分はデプロイID、次の青字部分はクラウドサービスの名前です。asiaeastは配置場所（DC）、internal.cloudapp.netはまぁ固定でクラウドサービスの内部って意味でしょうけど、1つよくわからないのがありますね～。普通に考えるとDC内の何かの（たぶん論理）単位ですね。まぁ自身のDNSサフィックス調べれば生成する必要ないのであまり意味はありませんが。

もちろんクラウドサービス内で有効なだけですけど、ちゃんと名前解決もできる＝ポートさえ空いていれば通信ができます。

image

これでHOSTSを弄ったり、変なEndpoint定義したりしなくてもいいですね！！

ちなみに、このvmName属性はSDK1.7以降で使えるようです。いろいろ増えてるんだなぁ～。

参考

Azure Guest OS 3.xでARRv3を使う

/ buchizo / コメントする

Windows Azure Advent Calrendar jp: 2012 の #24です。

みなさんご存知の通り、Windows Azureのクラウドサービスおよび仮想マシンでWindows Server 2012が利用できます。

※残念ながらAzure WebサイトはまだWindows Server 2008 R2ベース。

仮想マシンは自分でいろいろ設定して永続化しておけるのでどうってことは無いんですが、みんな大好きクラウドサービスはそういうわけにはいきません。

で、せっかくクラウドサービスのGuest OS 3.xで、Windows Server 2012つまりIIS8が使えるようになったので、ARR（Application Request Router）も対応したものを使いましょーというのが主旨です。

IIS8に対応したARRv3はExternal CacheやURL Rewriteもこれまで通り使えますし、なんといってもWebSocketに対応してるのが嬉しいですね。

とはいえ、IIS8に対応したARRv3はまだBetaなので利用には注意が必要ですが。

続きを読む →

Windows Azure管理ポータルが更新されました

/ buchizo / コメントする

いつものように管理ポータルで操作してたらいきなり「新しいバージョンのポータルが利用できます」って表示されてリロードしたらいろいろ新しくなってました（

ということで簡単に気づいた点など。（※差分が分からないので前から実装されてたのがあるかもしれない。）

続きを読む →