[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する①

batchiです。

Auto Scalingをいじっていると、クールダウンという言葉をよく目にします。
それとは別に、ウォームアップという言葉もあります。

え?何が違うの?
冷やしたらいいのか温めたらいいのかどちらですか?

…と、なった時に一度調べたのですが、
久しぶりに思い出そうとしたらまったく思い出せなかったので、
改めて調べて記します。

結論のようなもの

・冷やすのと温めるのは同時にはできません
・冷やすか温めるかはスケーリングプランないしポリシーによって決定されます
・温める機会があるのはステップスケーリングポリシーを選択したときだけです
・デフォルトのクールダウンって何、と思ったらメインルートテーブルを思い出そう
・温める動作の意味が分からなかったらdesired capacityとcurrent capacityを意識しよう

この結論に至るまで、まわりくどく寄り道をして記していきます。

1.スケーリングプラン

「Auto Scalingによってインスタンスが増えます減ります」という動作を、
どのように実現しましょうか、という方法(プラン)は、いくつか種類があります。

参考にするドキュメントは以下のあたりです。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/scaling_plan.html#scaling_typesof

1.1.インスタンス数の維持

指定したインスタンス数を維持しようとするスケーリング動作です。
この「インスタンス数」にカウントされるのは、正常なインスタンスだけです。

なので、インスタンスに異常が検知された場合には、
そのインスタンスを削除し、
新たな正常なインスタンスを起動することでインスタンス数を維持します。

何をもって異常とするかは、ヘルスチェックの設定によります。
デフォルトでは、EC2インスタンスのステータスのみを評価します。
 
******長い脱線開始*****

EC2インスタンスのステータスってどこのこと指してます?
ドキュメントを見ましょう。

インスタンスステータスが running 以外の状態の場合、またはシステムステータスが impaired である場合は、Auto Scaling はインスタンスを異常ありと見なし、代わりのインスタンスを起動します。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/as-maintain-instance-levels.html#determine-instance-health

こういったドキュメントとかコンソール画面の日本語は、
ひっかかりやすいのでうっかりすると間違いそうですね。

まず「インスタンスステータス」とは、
マネジメントコンソールで「インスタンスの状態」と表示されている部分のことです。

‘running’と記載があるのでイメージはしやすいですね。

running以外は異常ありとみなすので、
うっかり「停止」を押して「stopping」状態になると、瞬く間に削除されます。

次に「システムステータス」とは何を表しているか。

「2/2のチェックに合格しました」でおなじみのステータスチェック。
内訳を見ると以下の2つがある。

①システムステータスのチェック
②インスタンスステータスのチェック

※②で「インスタンスステータス」という言葉が出てくるのが紛らわしいですが、
‘running’とか表示される「インスタンスの状態」とは別物です。

「システムステータス」って要は①のことでしょ、と思っていたら、違いました。
①②の結果によって「システムステータス」が決定される、でした。

ステータスチェックは 1 分ごとに実行され、それぞれ成功または失敗のステータスを返します。すべてのチェックが成功すると、インスタンス全体のステータスが OK になります。1つ以上のチェックが失敗すると、全体のステータスが impaired になります。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html?icmpid=docs_ec2_console

①②両方とも成功するとシステムステータスは「OK」になる。
①②いずれかが失敗するとシステムステータスは「impaired」になる。

そういうことでした。

同じことを言っててもドキュメントやコンソール画面で言い回しが違ったりするので、
惑わされず「ここでいうこれは何を指してるんだろう」というのを正確に読み取るのは大事ですね。

******長い脱線終了*****
 
ここまで述べたEC2のステータスに加えて、
ELBによるヘルスチェックの結果もAuto Scalingグループによる評価対象に加えることができます。
(Inservice/OutOfserviceと表示されるアレです)

このスケーリングプランを利用して、
障害が発生しても自動回復させよう、という試みを俗にAuto healingと言いますね。

1.2.手動スケーリング

手動で稼働させる台数を指定し、スケールアウトないしスケールインを実施します。
Auto Scalingなのに手動で操作するんですか?という質問はやめましょう。
自動車の自動運転だってまだ実現してないじゃないですか。

1.3.スケジュールに基づくスケーリング

スケジュールとインスタンス数を設定しておけば、
自分の代わりに小人が手動スケーリングを行ってくれるイメージです。

スケジュール指定で自動でやるか人力でやるかの違いだけです。
一度きりでも繰り返しでも設定もできます。

1.4.動的なスケーリング

どの「きっかけ」に基いて、
「どのような内容で」スケーリングを実施するかを予め設定しておくことで、
負荷状況に合わせたスケーリングが実現できます。

「きっかけ」になりうるのは以下の2つ。
・メトリクス(Cloudwatchアラームによる監視)
・Amazon SQS

「どのような内容で」というのは「スケーリングポリシー」によって定義します。
スケーリングポリシーは以下の2種類があります。

・シンプルスケーリングポリシー
・ステップスケーリングポリシー

冒頭で述べましたが、ウォームアップが関わってくるのは、
後者のステップスケーリングポリシーだけです。

1.スケーリングプランで様々なスケーリング方法が出てきましたが、
一番最後の「動的なスケーリングでステップスケーリングポリシーを使う」場合のみ、
ウォームアップが関わってきます。

じゃあそれ以外はクールダウンが関わってくるんですね、
というとそういうわけではなく、
クールダウンすら関わってこない場合と、
クールダウンの中でも種類があってこのクールダウンだけ…というのもあるので、
それは次回まわりくどく説明します。

以上です。

ALBでパスベースのルーティングができると何が嬉しいのか~後追い編~

batchiです。
過去2回ほどこのテーマで書いていました。

前置き編
中継ぎ編

気づいたらパスベースだけでなくホストベースでもルーティングできるようになっていた。

びっくりですね。早いですね。AWSのアップデートがね。
こちとらパスベース前提の記事も書き終わっていないというのにね。

でも、この新機能を記事に盛り込める、とプラスに考えます。
新機能についての詳細は2017/4/5発表の以下記事をどうぞ。

(新規 – AWS Application Load Balancer に対するホストベースのルーティングのサポート)
https://aws.amazon.com/jp/blogs/news/new-host-based-routing-support-for-aws-application-load-balancers/

CLBとALBのコンポーネントの違い

なぜALBではパスベース(そしてホストベース!)でのルーティングが可能で、
CLBではできないのか、その答えはコンポーネントの違いだと私は捉えています。

簡単に言えば、「ターゲットグループ」というコンポーネントの有無に尽きるかと思います。

CLBのコンポーネント

ALBとの対比にちょうどいいコンポーネント図が無かったので、
勝手に作りました。正確性は保障しておりません。

CLBコンポーネント図

簡単に言えば、ロードバランサーがあって、リスナーがあって、配下にインスタンスがあります。
ロードバランサーが配下のインスタンスに対してヘルスチェックを実施します。
どのような内容でヘルスチェックを行うかは配下のインスタンスすべてに対して共通です。

ロードバランサーには1つ以上のリスナーが必要です。
1つのリスナーにつき以下2つを定義します。

  • クライアントとロードバランサー間の接続プロトコル・ポート…①
  • ロードバランサーとバックエンドインスタンス間の接続プロトコル・ポート…②

CLBのリスナーでサポートされているプロトコルは以下の通りです。

  • HTTP(レイヤ7)
  • HTTPS(レイヤ7)
  • TCP(レイヤ4)
  • SSL(レイヤ4)

1つのリスナーにおいて、①と②で異なるレイヤのプロトコルを設定することはできません。
また、①に設定するポート番号は複数のリスナーで重複することはできません。

どのようなリスナーを経由しても、ルーティング先の候補は配下のインスタンス全台になります。
条件を指定してルーティング先を限定する、ということはできません。

ALBのコンポーネント

こちらは以下ドキュメントから拝借してきました。
(http://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/introduction.html#application-load-balancer-components)

component_architecture

CLBと比べてコンポーネントが増えています。
リスナーの中にルールというコンポーネントがあったり、
インスタンスがターゲットというコンポーネントになっていたり、
(つまりEC2インスタンス以外のリソースを宛先にできる。らしい)
ターゲットの集まりであるターゲットグループというコンポーネントがあったりします。

どのような内容でヘルスチェックを行うかはターゲットグループ単位で設定できるようになっています。

少し注釈をつけます。

ALBコンポーネント図

CLBにおいては「①で受け取ったら問答無用で②にルーティングする」、というイメージですが、
ALBにおいては、「リスナーで受けとったらルールに応じてターゲットグループにルーティングする」というイメージです。

ターゲットグループごとにプロトコルとポート番号の組み合わせを定義します。
ターゲットグループに対してターゲット(主にインスタンス)を関連付けていきます。
(CLBではロードバランサーにインスタンスを関連付ける)

リスナーとターゲットグループで使用できるプロトコルは以下の通りです。

  • HTTP(レイヤ7)
  • HTTPS(レイヤ7)

CLBと違いレイヤ4のプロトコルは指定できません。

ちなみに、CLBの①と同様、複数のリスナーで同一のポート番号を指定することはできません。

複数のターゲットグループにインスタンスを関連付けることで、
同一インスタンスの異なるポートにルーティングを行う、ということも可能になります。

ヘルスチェックは実行対象の単位が変わっただけでなく、
どのようなHTTPステータスコードが返ってくれば正常とみなすかを設定可能です。
(CLBでは200固定)

おわりに

ALBは、ターゲットグループ(と、ルール)というコンポーネントが追加されたことで、
CLBに比べ柔軟なルーティングが可能になっていることがわかります。

ホストベースとかパスベースをひっくるめて
コンテントベースのルーティングと言うらしいです。

CLBとALBそれぞれできることが違いますので、用途によって使い分けましょう。

以上です。

Multi-AZ配置とSingle-AZ配置とは?

こんにちは。SKMです。

今回はAWSをやっていてよく耳にするけど詳しく分からなかった、

Multi-AZ配置とSingle-AZ配置について説明してみます。

そもそもどのタイミングで活用されるのか?

RDS(Relational Database Service)で、DBインスタンスの高可用性とフェイルオーバーを実現するために使われます。

マスター(M)が存在するアベイラビリティゾーンとは異なるアベイラビリティゾーンに同期スタンバイのスレーブ(S)を配置します。 →高可用性

異常や障害が発生したとき、冗長な待機系コンピュータサーバ/システム/ネットワークに切り替える機能。 →フェイルオーバー

どのタイミングでフェイルオーバーするのか?

下記の状態が発生した場合、プライマリBDインスタンスがスタンバイレプリカに自動的に切り替えられる。(フェイルオーバーする)

・アベイラビリティゾーンの機能停止

・プライマリDBインスタンスのエラー

・DBインスタンスのサーバータイプ変更

・DBインスタンスのオペレーティングシステムでソフトウェアのパッチ適用中

・DBインスタンスの手動フェイルオーバーが [Reboot with failover] を使用して開始された

 

 

Multi-AZとSingle-AZの違い

Multi-AZ配置

複数のアベイラビリティゾーンに配置される、自動でフェイルオーバーが行われる。AZ

 

Single-AZ配置

1つのアベイラビリティゾーンに配置される、手動で復元する必要がある。

singleAZ

 

1つのリージョンに複数のAZがあり、その中にマスターやスレーブがある。

マスターは管理・制御する元のデータであり、

それに対してスレーブがマスターを複製したものになる。

スレーブはマスターに問題が生じたときに、常に最新の状態に更新されているため、マスターに昇格する。しかし、マスターが動いている間は読み書きしないため、マスターの負荷を減らすことはない。

それと合わせて、Multi-AZ配置する際に覚えておきたいのが、リードレプリカです。

データの読み書きはマスターのみ可能で、スレーブは読み取りも出来ない完全なスタンバイになるので、データベースの読み取り性能を上げたい場合はリードレプリカを作成するかElastiCacheを配置します。リードレプリカは読み込みが可能なため、マスターの読み取り負荷を軽減させることが出来ます。

先程スレーブは自動的に同期されると記載しましたが、リードレプリカは非同期です。

 

Multi-AZとSingle-AZに関する説明は以上になります。

今までマスターとスレーブの存在をそもそも知らなかったため、なぜデータベースで可用性を高めるのがMulti-AZ配置なのか分かりませんでした。

マスターとスレーブの役割を知ったのでMulti-AZ配置について理解出来ました。

以上になります。

 

IPアドレスの変換方法

こんにちは。SKMです。

前回の投稿の続きになります。

私はIPアドレスからサブネットマスクへの変換が出来ませんでした。

自分なりに理解が追いついてきたので、ご説明したいと思います。

AWSのEC2とVPCにおいてIPv4とIPv6のアドレス設定で割り当てることが出来ますが

今回の変換方法はサブネットマスクに関する基礎的な知識となります。

AWSに限ったものではありません。

例えば、10.10.1.164/27が属するネットワークのサブネットマスク、ネットワークアドレス、ブロードキャストアドレスを求める場合。

●サブネットマスクの求め方

/27でサブネット化されているため、サブネットマスクの第4オクテットは2進数で「11100000」になります。

サブネットマスク

 

上記からサブネットマスクは255.255.255.224になります。

 

●ネットワークアドレスの求め方

第4オクテットの「164」を2進数に変換すると「10100100」になります。

先程の第4オクテットとAND演算します。

11100000 + 10100100 = 10100000

10100000を10進数に変換すると160になるので、ネットワークアドレスは10.10.1.160になります。

 

●ブロードキャストアドレスの求め方

ブロードキャストアドレスを求める時はサブネットマスクのホスト部をすべて1に変換します。

サブネットマスクの第4オクテットは「11100000」なので、右側5ケタはすべて「1」にします。

先程の第4オクテットの「164」を2進数に変換して「10100100」になった右側5ケタを「1」にして

「10111111」になります。

101111111を10進数に変換すると191になるので、ブロードキャストアドレスは10.10.1.191になります。

 

 

計算方法の説明は以上になります。

さりげなくネットワーク部とホスト部の話が出ましたが、ネットワーク部はサブネットマスクが「1」になっている範囲になり、ホスト部はサブネットマスクが「0」になっている範囲になります。

私はいつもネットを調べながらではないと計算出来ない状態ですので、

自分の頭で出来るように訓練したいと思っております・・・。

 

 

 

VPCとサブネットについて

こんにちは。SKMです。
私はサブネットの理解が不十分でしたので、記事にしてみたいと思います。

基本知識
VPCを作成する際は、IPv4アドレスの範囲をCIDR(Classless Inter-Domain Routing)ブロック形式で指定する必要がある。
VPCを作成したら、Availability Zoneごとに必ず1つ以上のサブネットを追加する。
1つのサブネットが複数のAvailability Zoneにまたがることは出来ない
(VPCはAZにまたげるのでサブネットもまたげると勝手に思ってましたが、サブネットはAZをまたがることが出来ないのですね・・・)

サブネットの種類
パブリックサブネット -> インターネットゲートウェイにルーティングされている
プライベートサブネット -> インターネットゲートウェイへのルートがない
VPNのみのサブネット -> インターネットゲートウェイへのルートがなく、トラフィックがVPN接続の仮想プライベートゲートウェイにルーティングされている

subnet

VPCとサブネットのサイズ設定

今回はIPv4用のVPCとサブネットのサイズ設定をご紹介(ほかにIPv6用がある)
1つのCIDRブロックをVPCに割り当てることが出来る。
許可されているのは/16ネットマスクから/28ネットマスクの間のブロックサイズ。
(16~65,536個のIPアドレスを含めることが出来る)

VPCを作成する場合は、プライベートIPv4アドレス範囲からCIDRブロックを指定することを勧めている。

10.0.0.0~10.255.255.255
172.16.0.0~172.31.255.255
192.168.0.0~192.168.255.255

一度作成したVPCはサイズの変更が出来ない。
VPCが小さい場合は、新しい大きなVPCを作成し、インスタンスを移行する。
→実行中のインスタンスからAMIを作成し、新しいVPCで代替インスタンスを起動する。
古いインスタンスを終了し、元のVPCを削除する。

サブネットCIDRブロックの最初の4つのIPアドレス(10.0.0.0~3)と
最後のIPアドレス(10.0.0.255)は使用ができず、
インスタンスに割り当てることが出来ない。
その場合は下記のIPアドレスが予約される。

10.0.0.0:ネットワークアドレス
10.0.0.1:VPCルーター用にAWSで予約されている
10.0.0.2:AWSで予約されているDNSサーバーの IP アドレス
10.0.0.3:将来の利用のためにAWSで予約されている
10.0.0.255:ネットワークブロードキャストアドレス。VPCではブロードキャストアドレスがサポートされていないため、予約されている

これらの情報をもとにサブネットマスク、ネットワークアドレス、ブロードキャストに変換する問題が出題される可能性もあります。覚えておく必要があります。

次回は今回の内容を踏まえ、IPアドレスからサブネットマスクの変換方法を説明出来るようになれればと思います。

こんにちは、hmです。

ここ最近、監視ツールの調査をしており、面白そうなものを見つけたので、
紹介したいと思います。

なお、今回はあくまで特徴をお伝えするにとどめます。
構築手順は別途お伝えしますが、すごく楽です。
(この点もPrometheusのいいところでもあります。)

Prometheus

ふわっと特徴をお伝えすると、

1.Pull型のOSS監視ツール
Pull型とは、サーバー側から監視先ホストのポートをたたいて回ります。
そのため、サーバー側にはホストの情報を覚えさえてなければなりませんが、
すべて書く必要はなく、service discoveryを使えば簡単に設定、かつ監視対象の絞り込みが
できます。

scrape_configs:
- job_name: ‘my_ec2_hosts’

# EC2 Service Discovery Config
ec2_sd_configs:

- region:
access_key:#アクセスキー
secret_key:#シ-クレットキー
port: 9100 # 監視対象ポート

2.Golang製

3.扱えるのは数値のみ(ログ監視もできそうですが、まだ調査中です)
ここは私がまだわかってないところですが、サーバーがとってくる情報は、数値情報です。
ログの文字列をとってくるというのは、exporter(エージェント)を書かなければならないのですが、あるのかは今はまだ調査中です。

4.ラベルで監視したい項目の絞り込みが簡単
例えば、「この役割で、このステージで、こういうグループの…」
みたいな絞り込みが可能です。

・サービスやステージにかかわらず、Webサーバーのロードアベレージが見たい!
ということであれば、下記のようなクエリを投げれば見ることができます。
node_load5{Role="web"}

また、クエリ自身もぱっとみてわかりやすく、使いやすいです。
クエリ詳細はこちらから!

アーキテクチャ
Prometheusでやっていることは、主に下記の3つです。
・情報をあつめて、ためる。
・アラートを上げる
・クエリへの回答

architecture of prometheus

Web UI
下記は実際に構築したものです。ただし、このWeb UIだけではパッと見て、
わかりづらいかなというのが個人的な意見です。ですので、Grafanaで可視化をしてあげると
よりわかりやすいのかなと。別の記事で紹介をしようかと思います。

下記はホーム画面です。デフォルトは、http://localhost:9090/graphです。
WS000003
クエリはこんな感じでリストになってます。
WS000004
これはmetricsです。監視対象にexporter(エージェント)が入ってないため、
prometheusサーバー自身の情報を表示してます。
WS000005
PrometheusのコンフィグもWeb UIからのぞけます。
WS000000

今回は、ここまでです。次回は、Grafanaの可視化とservice discoveryを設定してみたいと思います。

お付き合いいただきありがとうございました。

備考:
性能については、ユースケースをもとにKibana+Elasticsearchとの組み合わせと比較をしている下記が参考になります。
http://qiita.com/sugitak/items/ff8f5ad845283c5915d2#%E9%AB%98%E6%80%A7%E8%83%BD

ALBでパスベースのルーティングができると何が嬉しいのか~中継ぎ編~

batchiです。

前回の続きからです。
http://www.simpline.co.jp/tech/?p=1739

パスベースのルーティングが必要となるのはどんな場合?というところからです。

ケース1:同じFQDNで別サーバで稼働している場合

パスベースの振り分け

HPと技術ブログを、同じFQDNで異なるサーバ上で動かしていた場合。

ALBであればパスで判断してサーバの振分けが可能ですが、CLBだとそれができません。

上記の構成でCLBを採用した場合、CLBのルーティングアルゴリズムによって
いずれかのサーバにルーティングされ、
運が良ければ然るべきサーバにたどり着くかもね、という状態になります。

ケース2:同一サーバの別ポートで稼働している場合

パスベースの振り分け2

HPと技術ブログが、同一のサーバ上で、異なるポートで動いていた場合。

CLBの場合、下記のような縛りがあるので、基本的に対応できません。

  • ロードバランサーのポート1つあたり設定できるインスタンスのポートは1つ
  • ロードバランサーのポートを重複して指定できない

(80で待ち受けてインスタンスの80に渡す、443で待ち受けて8080に渡す、という無理くりならできる?)

ALBであれば「単一のインスタンスで複数のポートにルーティング」ができます。

CLBを使わざるを得ないのであれば、
FQDNの異なる2つのCLBを用意する、といった対策が必要になります。

余談

「ALBでパスベースのルーティングできると何が嬉しいのか」に対する答えは、
「上記のケースにも対応できるから」で終了なのですが、
自分がこんがらがっていた部分があるので、
FQDNがらみでの「こんな時どうする?」のケースを書きます。

異なるドメインで同一サーバにルーティングしたい

例えば、https://infilic.co.jpでも、
https://simpline.co.jpでも、同じサーバを向かせたい。

こうしましょう。これはCLBでもALBでも変わりません。

異なるFQDN

…と書いていて思ったのですが、
異なるDomeinNameのHostedZoneが、
同一のELBに対してAレコードのエイリアス設定をすれば、
ELBは1つで済んだりするのでしょうか。

HTTPSで待ち受けたい時どうするの、
(どっちか片方の証明書しかELBにインストールできないでしょ、)と思いましたが、
ACMであれば複数ドメインに対する証明書を用意できると聞いたような聞いてないような。

宿題としてとっておきます。

同じドメインで複数のホスト名を持たせて同じサーバにルーティングしたい

例えばhttps://simpline.co.jpでも、
https://www.simpline.co.jpでも、
https://hoge.simpline.co.jpでも、同じサーバを向かせたい。

Route53でがんばりましょう。CLBでもALBでも変わりません。

ホスト名異なる

レコードセットではワイルドカードが使えるので、
最少で、zoneapexである「simpline.co.jp」と、
「*.simpline.co.jp」の2つを作ってあげれば事が足りそうです。
証明書が対応している前提で。

同じドメインで複数のホスト名を持たせて違うサーバにルーティングしたい

上に同じです。
レコードセットごとに、エイリアス設定するELBを分ければ実現可能です。

続く

実際にパスベースのルーティングをどう実現するかの設定を書くつもりでしたが、
構成図を書くのに疲れたので次回にします。

以上です。

XenServer6.5へXenCenterから接続+Zabbix2.4で監視する②

こんにちはmollyです。

前回のXenServer6.5へXenCenterから接続+Zabbix2.4で監視する①の続きになります。

 

1. XenCenter(Windows専用GUI)をインストールする

XenServer6.5へXenCenterから接続+Zabbix2.4で監視する①の最初にダウンロードした
”XenServer-6.5.0-xenserver.org-install-cd.iso”をダブルクリックすると、
ローカルPCの[スタート]→[コンピュータ]で以下のようにXenServerがBD-ROMドライブとして表示されます。

479f17e8-bf9d-8598-899b-d1c286aedcfe

・「BD-ROM ドライブ(E:)XenServer-6.5.0」→「client_install」と開き、「XenCenterSetup.exe」というアプリケーションを選択すると以下のようなセットアップウィザードが表示されます。そして[Next]をクリック。

WS000005

・XenCenterをどこに置くか、XenCenterを誰が使用するかを決定し、[Next]をクリック。
(インストール作業者のみでなく、全員が利用できるようにする場合はAll Usersを選択します)WS000007

・画面が切り替わって[Install]をクリックすると、インストールが始まります。インストールが終わったら[Finish]を押してセットアップウィザードを閉じます。

WS000008

 

2. XenCenterを利用してXenServerへ接続する

・Windows画面左下の[スタート]から「citrix」と検索するとXenCenterが出ます。
・XenCenterを選択すると以下の画面が表示されます。

WS000009

・画面中央の[ADD a server]を選択すると以下の画面が表示されるので接続先のXenServerの情報を入力して[Add]をクリックします。(XenServerのネットワーク設定が出来ているかチェックしておく)

WS000011

・接続できました。

無題

 

3. XenServerにZabbixエージェントをインストール/設定する

・まずXenServerにSSHで接続します。
・SSHで接続できたら以下のコマンドでzabbix-agentのリポジトリを登録します。

rpm -ihv http://repo.zabbix.com/zabbix/2.4/rhel/5/x86_64/zabbix-release-2.4-1.el5.noarch.rpm

・次に以下のコマンドでzabbix-agentをインストールします。

yum install zabbix-agent --disablerepo=citrix,base,epel

◆/etc/zabbix/zabbix_agentd.confの中を編集

Zabbixサーバーを指定
Server=192.168.XX.XX

Zabbix サーバーを指定
ServerActive=192.168.XX.XX

XenServerのホスト名を指定
Hostname=test-XenServer

◆zabbix-agentの起動と自動起動設定

service zabbix-agent start
chkconfig zabbix-agent on

◆XenServerのポートの開放
zabbixと通信するにはデフォルトで10050ポートを使用する為、10050ポートを開放します。

/etc/sysconfig/iptablesの中に以下の一文を追加
-A RH-Firewall-1-INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 10050 -j ACCEPT

追加したらiptablesを再起動します
/etc/init.d/iptables restart

 

4. Zabbixサーバのブラウザ上で設定する

・zabbixサーバのダッシュボードにアクセスし、[設定]→[ホスト]→[ホスト作成]を選択します。
「ホスト」タブで以下のように設定します。(例)
  【ホスト名】XenServer
  【所属グループ】Virtual machines
  【エージェントのインターフェース】IPアドレス/ポート10050

・「テンプレート」タブで[Template OS Linux]を選択し、そこまで設定したら一旦[追加]します。

zbxagnt

・テンプレートまで設定すればグラフが自動で出来るのでそれらでスクリーンを作成すればXenServerに関するグラフを一気に見ることが出来ます。

graph

 

長々と書いてきましたが以上になります。
AWSはまったく関係のない記事でしたがXenAppやXendesktopがバージョン7.5からAWSでも使えるようになったみたいなので、そちらもキャッチアップ出来たら挑戦してみたいと思います。

ありがとうございました。

XenServer6.5へXenCenterから接続+Zabbix2.4で監視する①

初めまして、mollyです。

技術ブログを更新する機会をいただきました。
AWS関連ではないのですが、自分がせっかく学んで実践してみたことを
共有したいので今回はXen+Zabbixのお話を書かせて頂きます。
長くなってしまいそうなので2つに分けて投稿します。

新しく携わる案件のためにXenを学んだので、XenServer6.5の構築と
継続して勉強していたZabbix2.4での監視をしてみようと思いました。
今回、XenServer6.5はVirtualboxに構築します。

前提
・Zabbixサーバ2.4構築済み+ブラウザでダッシュボードが見られる環境
・Virtualboxにエクステンションパックが入っている

 

1. まずVirtualboxにXenServerの起動準備をします。

ここから「XenServer Installation ISO」を選択してダウンロードします。
・Virtualboxを管理者権限で開いて、[新規]をクリックします。
・【名前】XenServer→【タイプ】Linux→【バージョン】Other Linux(64-bit) このように設定しました。
・次からは以下のように設定しました。
  【メモリサイズ】4096
  【仮想ハードディスク】仮想ハードディスクを作成する
  【ハードディスクのファイルタイプ】VDI(VirtualBox Disk Image)
  【物理ハードディスクにあるストレージ】(可変サイズ)
  【ファイル名】XenServer
  【仮想ハードディスクのサイズ】16GB
・作成した仮想マシンを選択し、画面上の[設定]を押して[システム]→[プロセッサー]→プロセッサー数を2CPUに設定します。

 

2. XenServerを起動します。

・作成した仮想マシンを選択し、画面上の[起動]を押します。
・「起動ハードディスクを選択」という画面が出るので、先ほどダウンロードしてきた”XenServer-6.5.0-xenserver.org-install-cd.iso”を選択する。
・言語選択画面で日本語([qwerty] jp106)を選択。

WS000001

・インストールを続行するか聞かれるので[OK]を選択してEnterを押します。

WS000002

・「End User License Agreement」は、ライセンスに関する同意画面なので[Accept EULA]を選択してEnterを押します。

WS000020

・インストール先のストレージを選択する画面が表示されるので対象のディスクを選択して[OK]を押します。

WS000022

・「Select Installation Source」画面では[Local media]を選択して[OK]を押します。

WS000023

・Supplemental Packのインストールをするかどうか聞かれるので、[Yes]を選択(自由)する。
次に聞かれるテスト(Verify Installation source)も行うかはどちらもでもよい。

WS000024

WS000025

・その他もろもろの設定をします。
  【rootのパスワード】自由に設定(2回入力して[OK])
  【NetWorking】DHCPか固定IP(今回は固定IPにしました)
  【ホスト名/DNSサーバ】環境に合わせて設定
  【タイムゾーン】Asia>>Tokyo
  【System Time】Manual time entry(NTPを使う場合は次の画面で設定)

・ここまで設定したら以下の画面になるので[Install XenServer]を選択してEnterを押すとインストールが始まります。
(Supplemental Packのインストールを行うと選択している場合、「New Media」という画面が表示されるが特にインストールしないので、[Skip])

WS000032

・しばらく待つとインストールが終了し、「Installation Complete」という画面になるので[OK]を押して再起動します。

WS000035

・起動すると、以下の画面になるのでここからはWindows専用XenClientのXenCenterから設定などの変更が出来るようになります。

WS000034

この段階ではXenServerを構築したのみで、まだ何と接続しているわけではありません。
きりが良いので一旦ここまで、、、②に続きます。
次回はXenCenterのインストール~接続~Zabbixでの監視編です。

ALBでパスベースのルーティングができると何が嬉しいのか~前置き編~

batchiです。

早いものでALB(Application Load Balancer)が登場してから数ヶ月。
先輩のpinoco氏はALBが登場してすぐにブログに書いていたのですが、

ELB(Application Load Balancer)をおさわりする

当時の僕はパスベースとはなんぞや状態で、
いまいち「ALBならでは」の挙動を理解できておりませんでした。

ここにきてようやく理解が追いついてきたので、
数ヶ月前の自分に向けて噛み砕いた説明を記していきます。

まずはCLBとALBの違い

ALB(Application Load Balancer)が登場したことによって、
従来のLoad BalancerはCLB(Classic Load Balancer)と称されることになりました。

以下記事中の呼称はALB、CLBに統一します。

公式ドキュメントで両者の比較表が作られていますので確認しましょう。
http://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/what-is-load-balancing.html#elb-features

ALBとCLBの違い

[パスベースのルーティング]という行には、
ALBにのみチェックがついていることがわかります。

あとはまぁ、いろいろ違いますね。

いきなり脱線して日本語訳への不満

[スティッキーセッション (Cookie)]の行をご確認ください。
ALBの列に、「生成されたロードバランサー」と書いてあります。

ちょっと意味が分からないですね。

英語表記に切り替えると、
「load balancer generated」と記載されています。
「generated」によって「load balancer」が修飾されているという訳し方ですね。

正しくは「load balancer generated」が「cookies」を修飾していて、
「ロードバランサーが生成した(クッキー)(によるスティッキーセッション)」のはずです。

CLBであれば、
アプリケーション制御のcookieによるスティッキーセッションも、
ロードバランサー制御のスティッキーセッションも選択できるけど、
ALBでは後者しか使えません。という意味でした。

パスベースのパスとは

話は戻ってパスベースの話です。
パスベースにおけるパスとは何を指しているのかをきちんと理解するために、
URLの構成をおさらいしておきましょう。

https://www.cman.jp/network/term/url/
↑こちらのサイト様がわかりやすくまとまっていました。

簡単に言うとこういった構成になります。

http://<FQDN> <パス>

FQDNとは、「(ホスト名+)ドメイン」のことです。

弊社のHPのURLで見ると…
https://www.simpline.co.jp

ホスト名 www
ドメイン simpline.co.jp
パス なし

技術ブログの場合だと…
http://www.simpline.co.jp/tech/

ホスト名 www
ドメイン simpline.co.jp
パス /tech/

「パスベースのルーティング」には、
URLにおけるこの「パス」が関係してくるというわけです。

パスベースのルーティングが必要ないケース

ここで、弊社のサーバ構成をごく簡単にご説明します。

パスベースでないケース

簡単すぎますね。

EC2上でwebサーバを動かしており、
そのフロントにはCLBが立っています。

HPや技術ブログの他にも社員ブログ、代表ブログなど様々ありますが、
基本的に同じサーバの同じポート番号で動かしています。

クライアントはwww.simpline.co.jp <何がしかのパス>というURLにアクセスしてくるわけですが、
ここで<パス>が何であっても、
クライアント→hosted zone→CLB→80番ポートに至るまでの経路は全く同じです。

こういった構成においては、パスベースのルーティングは必要ありません。

では一体どういったケースで必要になってくるかというと…
肝心なところは次回に持ち越しです。

以上です。