Agile Cat — in the cloud

Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_1

Posted in .Chronicle, .Selected, Amazon by Agile Cat on April 25, 2011

The AWS Outage: The Cloud’s Shining Moment
Image(25)By
George Reese
April 23, 2011
http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html

image

So many cloud pundits are piling on to the misfortunes of Amazon Web Services this week as a response to the massive failures in the AWS Virginia region. If you think this week exposed weakness in the cloud, you don’t get it: it was the cloud’s shining moment, exposing the strength of cloud computing.

今週に AWS Virginia リージョンで起こった大規模な障害に対する反応として、かなりの数のクラウド評論家たちが、Amazon Web Servicesの失敗に尾ひれを付けている。 しかし、クラウドが脆弱さを露呈したと考えるなら、あなたはクラウドの輝く瞬間を見逃し、また、クラウド・コンピューティングのパワーを理解していないことになる。

Image(26)

In short, if your systems failed in the Amazon cloud this week, it wasn’t Amazon’s fault. You either deemed an outage of this nature an acceptable risk or you failed to design for Amazon’s cloud computing model. The strength of cloud computing is that it puts control over application availability in the hands of the application developer and not in the hands of your IT staff, data center limitations, or a managed services provider.

要するに、あなたのシステムが、今週に Amazon クラウドで障害を起こしていても、それは Amazon の過失ではない。 あなたは、このサービス停止を、当然の事として受容すべきリスクとみなしたのか、さもなければ、Amazon クラウド・コンピューティング・モデルを設計をし損ねただけだ。 クラウド・コンピューティングの強さとは、アプリケーションの可用性に関するコントロールが、アプリケーション・デベロッパーの手に委ねられることにある。 つまり、あなたの IT スタッフや、データセンターの限界、そして、マネージ・サービス・プロバイダーに委ねられるのではない。

The AWS outage highlighted the fact that, in the cloud, you control your SLA in the cloud—not AWS.

また、今回の AWS におけるサービス停止により、クラウドにおける SLA は、あなたが自身がコントロールすべきことであり、それを AWS に委ねてはならないという事実が浮き彫りにされた。

The Dueling Models of Cloud Computing

Until this past week, there’s been a mostly silent war ranging out there between two dueling architectural models of cloud computing applications: “design for failure” and traditional. This battle is about how we ultimately handle availability in the context of cloud computing.

一週間前まで、クラウド・コンピューティング・アプリケーションにおいては、2つのアーキテクチャ・モデルの間に、つまり、Design for Failure(障害を前提としたデザイン)と、従来からのデザインの間に、出口の見つからない静かな論争があった。その戦いは、クラウド・コンピューティング環境における可用性の、究極的な処理方法に関するものである。

The Amazon model is the “design for failure” model. Under the “design for failure” model, combinations of your software and management tools take responsibility for application availability. The actual infrastructure availability is entirely irrelevant to your application availability. 100% uptime should be achievable even when your cloud provider has a massive, data-center-wide outage.

Amazon モデルは、その Design for Failure モデルである。 この Design for Failure モデルにおいては、あなたのソフトウェアとマネージメント・ツールの組み合わせが、アプリケーションの可用性に対して責任を負う。そして、実際のインフラストラクチャにおける可用性は、あなたのアプリケーションの可用性とはまったく無関係である。 したがって、対象となるクラウド・プロバイダーが、データセンターごと機能を停電するという、大規模なダウンタイムを生じるときでさえ、100% のアップタイムを達成できなければならない。

Most cloud providers follow some variant of the “design for failure” model. A handful of providers, however, follow the traditional model in which the underlying infrastructure takes ultimate responsibility for availability. It doesn’t matter how dumb your application is, the infrastructure will provide the redundancy necessary to keep it running in the face of failure. The clouds that tend to follow this model are vCloud-based clouds that leverage the capabilities of VMware to provide this level of infrastructural support.

大半のクラウド・プロバイダーが、この Design for Failure から派生した、なんらかのモデルにしたがっている。 しかし、その基礎をなすインフラストラクチャにおいて、従来からのモデルに従順なプロバイダは、可用性に対する究極の責任を取らざるを得ない。 そして、どれほど稚拙なアプリケーションであっても、それが重要になることはない。 障害に直面した時であっても、アプリケーションを実行するために必要な冗長性が、対象となるインフラストラクチャから提供されるだろう。 こうしたモデルに追随するクラウドとしては、vCloud ベース・クラウドがある。 そこでは、必要とされるレベルのインフラストラクチャが、VMware の機能を高めることで実現されている。

The advantage of the traditional model is that any application can be deployed into it and assigned the level of redundancy appropriate to its function. The downside is that the traditional model is heavily constrained by geography. It would not have helped you survive this level of cloud provider (public or private) outage.

この、従来からのモデルにおけるアドバンテージは、いかなるアプリケーションであってもディプロイし、その機能に適切とされる冗長性のレベルを割り当てられる点にある。 その反面、この従来型モデルは、地理的な制約を受けるという欠点を持つ。 したがって、今回のような、クラウド・プロバイダ(public or private)がもたらすレベルのサービス停止では、あなたのアプリケーションの可用性を保持する上で、何の役にも立たないだろう。

The advantage of the “design for failure” model is that the application developer has total control of their availability with only their data model and volume imposing geographical limitations. The downside of the “design for failure” model is that you must “design for failure” up front.

Design for Failure モデルのアドバンテージは、この地理的な制約を圧倒するデータのモデルとボリュームだけを用いて、アプリケーション・デベロッパーが全体的な可用性をコントロールできる点にある。 そして、Design for Failure モデルの欠点は、前もって Design for Failure モデルを、自分自身で考える必要性が生じる点にある。

AmazonThe Five Levels of Redundancy

In a cloud computing environment, there are five possible levels of redundancy:

クラウド・コンピューティング環境には、冗長性を実現するための 5つのレベルが存在する:

  • Physical
  • Virtual resource
  • Availability zone
  • Region
  • Cloud

When I talk about redundancy, I’m talking about a level of redundancy that enables you to survive failures with zero downtime. You have the redundancy that simply lets the system keep moving when faced with failures.

冗長性について話すなら、障害を回避してダウンタイムをゼロにする、冗長性のレベルについて説明したい。つまり、障害に直面しているときであっても、そのシステムを簡単に動かし続ける冗長性を手にしているという話だ。

Physical redundancy encompasses all traditional “n+1″ concepts: redundant hardware, data center redundancy, the ability to do vMotion or equivalents, and the ability to replicate an entire network topology in the face of massive infrastructural failure.

物理的な冗長性は、従来からの 『 N+1』 コンセプトの全てをカバーする。 つまり、インフラストラクチャの大規模な障害に直面する際の、ハードウェアの冗長性および、データセンターの冗長性、vMotion レベルの能力、そして、ネットワーク・トポロジ全体のリプリケーションのことである。

Traditional models end at physical redundancy. “Design for failure” doesn’t care about physical redundancy. Instead, it allocates redundant virtual resources like virtual machines so that the failure of the underlying infrastructure supporting one virtual machine doesn’t impact the operations of the other unless they are sharing the failed infrastructural component.

従来からのモデルを突き詰めていくと、この物理的な冗長性にたどりつく。 そして、Design for Failure は、この物理的な冗長性を無視している。 それに換えて、仮想マシンのような、冗長性のための仮想リソースが割り当てられる。それにより、障害を持つインフラストラクチャ・コンポーネントを共有していない場合に限り、仮想マシンをサポートしているインフラストラクチャの障害が、他の運用に影響を与えないようになる。

The fault tolerance of virtual redundancy generally ends at the cluster/cabinet/data center level (depending on your virtualization topology). To achieve better redundancy, you spread your virtualization resources across multiple availability zones. At this time, I believe only Amazon gives you full control over your availability zone deployments. When you have redundant resources across multiple availability zones, you can survive the complete loss of (n-1) availability zones (where n is the number of availability zones in which you are redundant).

一般的に、仮想を用いる冗長性のフォールト・トレランスは、クラスタ/キャビネット/データセンターのレベルに到達する(それぞれの仮想化トポロジーに応じて)。さらに優れた冗長性を達成するためには、多数のアベイラビリティ・ゾーンをまたいで、仮想化されたリソースを展開すべきだ。 現時点において、Amazon だけが、アベイラビリティ・ゾーンに関するフル・コントロールを提供しているはずだ。 多数のアベイラビリティ・ゾーンを横断する形で、冗長化されたリソースを有しているなら、アベイラビリティ・ゾーンの完全な喪失(n-1)からも、アプリケーションを守ることができる(冗長性は、n 個のアベイラビリティ・ゾーンにより担保される)。

Until this week, no one has needed anything more than availability zone redundancy. If you had redundancy across availability zones, you would have survived every outage suffered to date in the Amazon cloud. As we noted this week, however, an outage can take out an entire cloud region.

今週の出来事を経験するまで、アベイラビリティ・ゾーンの冗長性のことや、それ以上のことを、誰も必要としていなかった。 アベイラビリティ・ゾーンをまたがる冗長性を有していたなら、Amazon クラウドがサービスを停止しても、アプリケーションは生き残っていたはずだ。しかし、私たちが指摘したように、1回のサービス停止が、クラウド・リージョン全体を壊してしまうこともある。

Regional redundancy enables you to survive the loss of an entire cloud region. If you had regional redundancy in place, you would have come through the recent outage without any problems except maybe an increased workload for your surviving virtual resources. Of course, regional redundancy won’t let you survive business failures of your cloud provider.

リージョンについても、そこに冗長性を持たせることで、1つのクラウド・リージョン全体の喪失からも、生き残ることが可能となる。 リージョンに関する冗長性を、適切に配置していたなら、今回のサービス停止を、何の問題もなく乗り切ることができたはずだ。そこで必要となったのは、あなたの仮想リソースを保持するための、ワークロードが増加くらいだろう。そして、もちろん、リージョンに関する冗長性は、クラウド・プロバイダにおけるビジネス上の失敗を、保護するものにはならない。

Cloud redundancy enables you to survive the complete loss of a cloud provider.

つまり、クラウドの冗長性は、クラウド・プロバイダの完全な喪失からも、あなたのアプリケーションを守るものになるのだ。

<続く> ⇒ Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_2

 

 

 

 

 

Tags:

ーーーーー

この春に、私たちは、原子力発電所の喪失と、最強クラウドの喪失を経験しましたが、いかなる技術や情熱が注がれるにしても、シングル・フェイル・ポイントは重要な視点を欠いていると、証明されたのだと思います。

先週末から、いろいろな文献を読みあさってみましたが、今の時点で総括まで踏み込んでいるのは、George Reese さんの、この一本だけだったと記憶しています。 とても素晴らしい見識であり、訳していて、感銘してしまいました。 ーーー  __AC Stamp 2

ーーーーー

<関連>

Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_2
Amazon に起こった大規模ダウンタイムを分析する – Data Center Knowledge

Motorola の 次期 Android Phone は、Quad Core を搭載する?

Posted in Google, Mobile by Agile Cat on April 25, 2011

Motorola Quad Core Android Phones
Posted by
Harish on April 24, 2011
http://www.tech2hell.com/2011/04/motorola-quad-core-android-phones/

image

Motorola Bullet and Jet with Quad Cores !!

We recently saw phones like Motorola Atrix 4G with Dual Core Processors.Two phones are going to release in 2012 Q1 with Quad Core Processors loaded with Android.Yes,It’s Shocking !! They are Motorola Bullet and Motorola Jet.The Dual Core Smartphones brought with it the Nvidia’s Tegra 2 Hardware.Now the Quad Core Android phones is loaded with Nvidia Tegra 3 Hardware.

最近のことだが、 Motorola Atrix 4G with Dual Core Processors に似たソマートフォンを見た。 その 2つのスマートフォンは、Android と Quad Core Processors を搭載し、2012 年の 1Q にリリースされるという。 YES! それはショッキングだ !! それらは、Motorola Bullet と Motorola Jet である。 Dual Core Smartphones では、Nvidia Tegra 2 ハードウェアを搭載していた。 そして、Nvidia Tegra 3 ハードウェアを搭載した、Quad Core の Android Phone が提供される。

image

Specs:

The Motorola Bullet will feature a 4.3-inch qHD display and will have a RAM(Random Access Memory) between 1 and 2 Gigs.The Smaller Jet will have a 4″ qHD Display and will have same RAM as that of the Bullet and will have a QWERTY Slider.Both the Smartphones will have NFC Capabilities and will be loaded with 12 Megapixel Main Camera’s.There is no news about the front-facing camera.The Bullet and Jet will have 16 GB of Internal Memory.

imageMotorola Bullet の特徴は、4.3インチ qHD ディスプレイであり、1GB ~ 2GB の RAM(Random Access Memory)搭載する。 小型版の Jet は、4インチ qHD ディスプレイと、Bullet と同等の RAM を搭載し、さらに、QWERTY Slider を提供するらしい。 どちらのスマートフォンも NFC Capabilities を有し、12M Pixel のメイン・カメラを搭載する。 フロントの、セカンド・カメラに関する情報は提供されていない。 そして、Bullet と Jet の双方とも、16GB の内部メモリーを搭載する。

ーーーーー

思わず、『 本気ですか ? 』と聞きたくなるような、Motorola の Bullet と Jet ですが、スマーフォンと言ったって、ケータイ電話なんですよ ~~~。 そこに Quad Core を載せて、RAM が 1GB ~ 2GB というのは、フツーじゃぁありませんよね。 頭がクラクラしてきます。。。 でも、面白そうだし、欲しくなりそうです :) ーーー __AC Stamp 2

ーーーーー

<関連>

企業データにアクセスするモバイルと、セキュリティとの関係を、そろそろ真剣に考えよう
Level 3 Communications が Global Crossing を $1.9 billion で買収
Facebook Phone – INQ Cloud Touch を GIGAOM が初レビュー
Microsoft は主張する – Apple と Google はアプリケーション数を誇張していると
Verizon の市場では HTC が優勢? Thunderbolt vs iPhone 4

%d bloggers like this: