Tech Sketch Bucket of Technical Chips by TIS Inc.

OSS統合監視ツール「Zabbix」を利用して大規模環境監視(1)

Pocket

システムを運用する際には、安定稼働を実現するため日々システムの状況を監視する必要があるかと思います。
障害が発生した場合にはただちに検知し、対応できるようにしておくことで障害によるシステム停止時間を短縮できます。
また、システム内のサーバのリソース状況を把握しておくことによって、障害発生を未然に防ぐことが可能になるかもしれません。

昨今、仮想化技術が普及してきて、インフラ管理者1人当たりが管理するサーバの台数もますます増加してきているかと思います。

このような大量にマシンを管理しなければならない状況で、よりコストをかけずにシステムを監視し、運用していくために有用な統合監視ツールを紹介します。
紹介するのはOSSの統合監視ツール「Zabbix」です。

OSSツール:Pacemakerを使ってクラスタを作ろう(3)

Pocket

techsketch-banner-OSS+startingblock(700x65).jpg前回はPacemakerのリソースエージェント設定についての説明をしました。
今回はPacemakerの動作についての話をしようと思います。

HA クラスタの基本動作は、「サーバあるいはプロセス等に障害が発生したら、無事なサーバへフェイルオーバーしてサービスを継続させる」ということです。当然ながら、このような基本動作には何の問題もありません。(ここに問題があるなら、単なる"使えないツール"で終わってしまいますよね。)
HAクラスタを構築したときに一番気になるのは、スプリットブレイン対策だと思います。
スプリットブレインが発生すると、サービスが継続できなくなるのはもちろん、深刻なデータ障害(データ破壊、ロスト)が発生する場合がありますので、最大限の注意を払いたいところです。
Pacemaker(+DRBD)でクラスタを構築した場合に、この対策をどうするかというのが今回のテーマです。
実際にテストしてみた結果をお話します。

ITシステムの性能に取り組む基礎知識 (その4: チューニングポイントの優先度)

Pocket

techsketch-banner-perfeng+blackgraph(700x72).jpg


この一連のブログは「基礎の基礎からの話をします」と書いて始めました,今回が最後の記事にするつもりです.

■問題

APサーバとDBサーバの2層から構成されるITシステムがあります.高負荷時に平均1秒以内の応答時間が要件です.製造を終えて単発(低負荷)で性能を測定してみると,AP=0.5秒,DB=0.2秒が掛かり,合計0.7秒でした.高負荷状態になったときには1秒を超過することが予想されます.さて,APサーバのロジックを改善する案と,DBサーバのデータ構造を改善する案の2案があるとき,どちらを優先させるのが良いでしょうか?

前回の問題と同じように,上記の問題の文中に書かれていることだけでは不明なことがたくさんあります.言い換えるとその隠れた条件次第で,正解はひとつではありません.また,APサーバかDBサーバかを画一的に決定できるとも限りません.以下ではいくつかの考え方を述べてみたいと思います.

3Dプログラミング基礎知識(3)

Pocket

3Dプログラミング基礎知識(2)の続きです。

画面に描画されるまでの流れ(おさらい)

Pipeline.png

今回は「ビュー変換」についてみていきたいと思います。

ビュー変換

前回書いた「ワールド変換」によって、3D空間に立方体が配置されました。
しかし、残念なことに現在一般的に使われているディスプレイが表示できるのは平面のみに限られており、3D空間に配置した立方体をそのまま表示することはできません。

現実という3D空間に対してカメラを向け、写真を撮ると3D空間を2Dの平面上に表現することができます。これと同じく、仮想的な3D空間においても仮想的なカメラを配置し、3D空間を特定の方向から眺めた結果を求めることで、2D平面上に表現することが可能です。

この変換を行うのが「ビュー変換」と、次回取り上げる「射影変換」になります。