うーん、AWS知識をカタカナ英語な理解で進めると、やたらと躓きますね…こんにちは。
今回は、可用性な話です。
仮想マシンの作成時にすぐに「高可用性」という項目があって「可用性セット」てのが出てきます。これってどうやらデプロイ時にしか選択出来ないようで、後からやっぱりやると言っても駄目そうなんですね。
本来なら、デプロイなんて、するするする～っと出来ないと駄目なのに、実際には「これはなんだあれはなんだ」状態です。そして、あとから修正出来ないとか・・・いあー参ったね。
で、Azureでは色々な可用性の話が出てくるんですよ・・・。
仮想マシンの可用性とストレージの可用性・・・
・LRS [Local Redundant Storage] ローカル冗長ストレージ
・GRS [Geo Redundant Storage] 地理的冗長ストレージ
・Manage availability [可用性セット]
・Service Healing [ 仮想マシンの自動復旧]
くっそ～。彼方此方で可用性の話されてシンドイな。
サクッと理解できる方法ないのかなって思うけど、ここに輪を掛けて混乱するのがResourceやらロードバランスとの関係なんだろうな…。
とりあえず、やっつけやすい所から。
可用性セットがなしの場合でも、仮想マシンについては「Service Healing」という機能で、ホスト障害があっても別のホストに自動復旧する仕組みが標準であるんだって。
これはvmwareでいうHAな話と一緒だね。なので、自動復旧機能のダウンタイムの許容とセッション断やらデータリカバリが何とかなるなら、可用性セットは気にせんでもいいのかな。
Azure 仮想マシンにおける可用性の考え方 – ainaba's blog
↑のサービス復旧図の解説が分かりやすかった。
ただ、AWSとAzureの違いでいうと、AWSの場合は、Availability Zone（以下AZ)というのを指定して仮想マシンを構築するのに対して、Azureの場合はその指定は無し（将来対応するっぽいけど？）。なので、AZ-a,AZ-cに自己配置出来るAWSと違って、Azureの場合はWEBサーバーを2台用意しても同一のゾーンに配置されちゃうかもしれない訳です。
AWSのAZの場合はAZ毎のサブネットを作るので、同じサブネットでの可用性は無い感じに対してAzureの場合はサブネットは同一のものが利用できる感じね。
で、同じサブネット内に例えば2台のサーバーを建てちゃうと、AWS風にいうとAZ-aに配置する感じになっちゃう。これだとSLAが微妙ね？
てことでAzureでは「可用性セット」という考えがあるんだと解釈した（＾＾；
で、AzureではAZの事を「障害ドメイン」ていう表現になるぽいですね。
AWS : Availability Zone
Azure : Availability Domains ? Fault Domains
まぁメンドクサイ。更新ドメインは良いと思いますよ。同一グループの更新を一気にやらないで済む仕組みはいいんじゃない。
高可用性の可用性セットをしたら勝手に仮想マシンの複製が出来るのかと思ってたけどさ、違ってた。
プログラム的にいうと、可用性セットの宣言を行って、パラメータはこんな感じです・・・という流れなのかな。
宣言を行う事で、その可用性セットのグルーピング(障害ドメイン)は０と１に分かれていますね。これがAWSでいうところの、aとかcとかっていうやつですな。
こんなパターンも作ってみましたよ。
うーん、今回も結局やってみれば本の言っていることが分かってくるけど、どーにもAWSもAzureもローカライズに問題があるような・・・？大事な言葉はムリに翻訳しなくてイイさ～。
でもこれは色々参ったね。ある程度ちゃんと理解してからでないと設計しにくいぞ。
触っているお陰で前進はしている気はするんだけど、AWSを触り始めた頃よりも苦労している気がする。何が違うんだろう…。
分かっている事は、AWSもAzureも本家サイトの情報が一番わかりづらいのは共通しています :-)
これは英語の言い回しをそのまま翻訳するからなのかな？
GRSを活かした構成な設計が出来るようになるまで道のり長そうだ…(^^;
さて、次行ってみよう。
