カテゴリー別アーカイブ: 運用

WordPressを運用しているサーバーのApacheをZabbixで監視する方法

| コメントをどうぞ

前回は、ZabbixでApacheを監視するための設定手順を紹介しました。
今回は、Wordpress(このブログサイト)を運用しているサーバー上での監視設定です。

監視対象サーバーの環境

  • OS: Amazon Linux
  • zabbix-agent: 2.2.5
  • httpd: 2.2.29
  • WordPress: 4.0

手順

前回の記事の設定の続きです。

server-statusをリダイレクトをしないように設定

Apacheの監視設定をしたときにserver-statusが取得できませんでした。

サーバー上で実行したコマンド

curl http://localhost/server-status

結果

< !DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>

</head><body>
<h1>Found</h1>
The document has moved <a href="https://localhost/index.php">here</a>.
<hr />
<address>Apache/2.2.29 (Amazon) Server at localhost Port 80</address>
</body></html>

どうやらWordpressの設定でリダイレクトされているようです。

続きを読む

AWS上のZabbixをPacemaker(HeartbeatV2)で冗長化

| 1件のフィードバック

AWS上で監視システムにZabbixを動かしておられる方も多いかと思います。AWSとZabbixは相性が良いので今後も増えていくと予想されます。しかしZabbix単体では冗長構成をとる機能が無い為、Zabbixが停止すると監視も止まります。「ちょっとくらい監視がとまっても業務は止まらないから良い。」と割り切れる場合はOKですが、監視が止まったら困るケースもあります。監視をサービス提供している場合は特にそうなります。じゃあ冗長化しましょうという事になりますが、商用のクラスタソフトはなかなかお高く手が出しづらい状況です。そこでオープンソースのツールを使って冗長化します。

Pacemaker(Heartbeat)で無料でZabbixを冗長化

Linuxでは古くからLinux-HAというプロジェクトがありHeartbeatというツールがあります。HeartbeatV1→V2→V3と進化してミドルウェアの制御部分を分離してPacemakerとなりました。V2(たぶんV3も)まではHeartbeatがミドルウェア部分も制御していました。
(V2までしか触ってなかったのでここらへんの知識はあいまい。)
歴史がありますので実績も十分です。(商用環境でも採用されています。)
HeartbeatとLVS(LinuxVirtualServer)を組み合わせてロードバランサーを安価に構築したりする事も可能です。
ただ、昔は実機のロードバランサーが高価だった為に結構構築されていましたが、今はAWSでELBとか出てきたのであまり見かけなくなりました。

HeartbeatV1

初期のころのHeartbeatでOS単位で冗長化出来ます。フェイルオーバー時に待機系でキックするミドルウェアを指定可能です。(メジャーなミドルウェア最初からリソースエージェントが用意されています。無い場合は作りますがシンプルなので容易に作成できると思います。)

但しフェイルオーバーのトリガーに出来るのはOSの死活のみでミドルウェアが停止してもOSが生きていたらフェイルオーバーはしてくれません。この為当時は別途シェルスクリプトなどと連携させてミドルウェアが停止したらHeartbeatの切替コマンドを実行させるなどで強引に対応しました。また、クラスタ構成は1対1の2台構成までです。

HeartbeatV2~

V2になって進化してミドルウェアもフェイルオーバー対象に出来るようになりました。クラスタ構成も1対Nが
可能になり、3台クラスター、5台クラスターという構成も可能になりました。但しcib.xmlファイルというものを作成する必要があり、更には冗長構成にするには色々と複雑な設定をしていく必要がありました。この為、この時代でもHeartbeatV1を利用しているケースが結構ありました。ただ、メジャーなミドルウェアは最初からOCF(OpenClusterFramework)というものが用意されているのでこちらを利用すると冗長化はしやすいです。(無い場合は自分で作成)

Pacemaker

V2にあったミドルウェアを制御するcrm(クラスタリソースマネージャ)分離してpacemakerになり、GUIで設定出来たり、crm configureで簡単にクラスタ構成を組めるようになったようです。何故「~ようです」と書いたかというと使ってみた感じ劇的に簡単になったか?と聞かれると微妙・・・。cib.xmlを書いた経験のある方ならcib.xmlを手書きしてしまっても構わないような感じではあります。ちなみにGUI版は触った事ないのでわかりません。

AWS上でHeartbeatで冗長化するには?

前置きが長くなりましたが、ここからAWSで冗長化を考えます。Heartbeat及びpacemakerはクラウドとか流行るより昔に生まれたので実機(オンプレミス)での冗長構成を念頭に開発されている部分があります。(シリアルケーブルで死活通信が可能など。)
どのサーバがサービス稼働中なのかの区別にサービス稼働中にVIPをつける方式がとても多いです。WEBサーバを冗長構成で組んでいるとして、エンドユーザにはVIPにアクセスさせます。Heartbeatがフェイルオーバー時に待機系にVIPを付け替える事によってエンドユーザはサーバが切り替わっても継続したサービスを受けれる仕組みです。しかしAWSではこの方式だと問題があります。

AWSはマルチキャストのパケットが通らない。

仕様上許しておらずマルチキャストパケットは破棄されます。何が困るかというとVIPを付け替える際にブロードキャストして知らせるわけですが、AWSでは破棄されるので勝手にVIP名乗っているだけで誰も(周りのサーバは)VIPを知らないので通信できません。ですので、

VIPの変わりにELBで代用します。

エンドユーザのアクセスをELBにしてELBのヘルスチェックを使って稼働系のインスタンスへ振り分ける事でこの問題が回避出来きるのでELB+Pacemaker(HeartbeatV2)を基本設計にAWS上でのZabbixの冗長化を行います。ZabbixをAWSで冗長構成を組むのに大まかに以下のパターンがあります。

  1. Pacemaker(HeartbeatV2) + RDS

  2. cluster1

    ● AWS上でVPC内にAvailabilityZoneをActiveとStandbyで分けてZabbixを動かしDR対応させる。
    ● AWSではマルチキャストを通さない仕様でVIP方式の冗長が利用出来ない為、ELBによるヘルスチェックを実施。
    ● データベースをRDS Multi-Azを採用することにより、汎用性、運用効率を上げる。
    ● Pacemakerでミドルウェア単位でグループ化してActive-Standbyの冗長を構成。
       グループ:Apache,Zabbix,Swatch
            ※Apacheは常時起動でそれ以下をグループ化してもOK

    ・・・なんでSwatchがいるの?と言うとやってみて分かった事ですがRDSのフェイルオーバー後はZabbixサーバが止まります。毎回DBに接続するアプリであれば問題は無いのですがZabbixのようなDBに接続しっぱなしのdaemonなどは一旦切断して再接続しないとならないようです。ここにも書いてありました。

    Amazon Web Services ブログ
    http://aws.typepad.com/aws_japan/2012/05/multi-az-option-for-amazon-rds-for-oracle-database.html

    そこでこの問題を、

    ● RDSフェイルオーバー時にZabbixの監視が停止する問題をSwatchで対処。している為クラスタグループにSwatchがいます。(他に妙案が浮かばなかった。。)

    動かした状態のクラスタモニタ

    Online: [ zabbixcluster-1 zabbixcluster-2 ]
    
     Resource Group: zabbixcluster
         apache     (lsb:httpd):    Started zabbixcluster-1
         zabbix_server      (lsb:zabbix_server):    Started zabbixcluster-1
         swatch     (lsb:swatch):   Started zabbixcluster-1
    

  3. Pacemaker(HeartbeatV2) + DRBD

  4. cluster2

    ゾーンを分けてELBでヘルスチェックまでは基本同じで、
    ● データベースをMySQL、データ格納領域をDRBDで同期。
    ● Pacemakerでミドルウェア単位でグループ化してActive-Standbyの冗長を構成。 
       クラスタグループ:Apache,Zabbix,MySQL,DRBD
                ※DRBDのMaster/Slave切替もPacemakerで制御。

    動かした状態のクラスタモニタ

    Online: [ zabbixcluster-1 zabbixcluster-2 ]
    
     Master/Slave Set: ms_drbd_r0
         Masters: [ zabbixcluster-1 ]
         Slaves: [ zabbixcluster-2 ]
     Resource Group: group_zabbix
         mount_r0   (ocf::heartbeat:Filesystem):    Started zabbixcluster-1
         httpd      (lsb:httpd):    Started zabbixcluster-1
         mysqld     (lsb:mysqld):   Started zabbixcluster-1
         zabbix_server      (lsb:zabbix_server):    Started zabbixcluster-1
    

  5. Pacemaker(HeartbeatV2) + MySQLレプリケーション

  6. cluster3



ゾーンを分けてELBでヘルスチェックまでは基本同じで、
● データベースをMySQL、データをレプリケーションでSlaveに同期。(Semi-Sync方式)
● Pacemakerでミドルウェア単位でグループ化してActive-Standbyの冗長を構成。
   クラスタグループ:Apache,Zabbix,MySQL
            ※MySQLのMaster/Slave切替もPacemakerで制御。

動かした状態のクラスタモニタ

Online: [ zabbixcluster-1 zabbixcluster-2 ]

 Master/Slave Set: ms_mysqld
     Masters: [ zabbixcluster-1 ]
     Slaves: [ zabbixcluster-2 ]
 Resource Group: group_zabbix
     mysqld     (lsb:mysqld):   Started zabbixcluster-1
     httpd      (lsb:httpd):    Started zabbixcluster-1
     zabbix_server      (lsb:zabbix_server):    Started zabbixcluster-1

それぞれのメリット/デメリット

RDS採用のメリット/デメリット
● メリット

  1. AWSコンソールからLaunch出来るので導入がし易い。
  2. バックアップ/リカバリの方法もスナップショットで行える。
  3. EC2インスタンスとRDSが分離しているのでEC2インスタンスだけインスタンスタイプを変更したり、RDSだけインスタンスタイプを変更したりといった運用が可能。

● デメリット

  1. EC2インスタンスとRDSインスタンスの料金が発生する。Multi-AZにする場合は更に費用が発生。
  2.      ※結構馬鹿にならない料金になります。ここが最大のネック。

  3. RDSはデータベースの管理者権限が取得出来ない為、それに伴う諸々の不便さが存在する。
  4. RDSは時刻がUTCだったりと日本仕様で無い部分があり対策が必要。
  5. フェイルオーバーにかかる時間がDRBDやMySQLレプリケーションより遅い。

DRBD採用のメリット/デメリット
● メリット

  1. 離れたディスク(Volume)をRAID1のように利用出来る為、データの整合性が高い。
  2. カーネルモジュールで動作する為、CPUやメモリへの負担が小さい。
  3. Volume間を繋ぐ回線速度が速いほどデータのディスク性能を上げる事が出来る。
  4. RDS採用よりもコストを抑えられる。

● デメリット

  1. ディスク性能が回線速度に大きく依存する為、速い回線にする必要がある。AWSではインスタンスタイプで回線速度が決まっている為、CPU、メモリに余裕があってもDRBDの為だけにインスタンタイプを高スペックにする必要がある。
  2. データを同時に書き込む仕様で不整合が発生しにくいはずだが、AWSでは発生しやすく、同期がはずれてStandAloneの状態になりやすい。
  3. ※特に大きいファイルが一瞬で書き終わる時に発生しやすい模様。有り得ない早さで書き終わる時があるのでAWS側のパフォーマンスを上げる為の仕組みか何かが作用しているかもしれません。ストレージゲートウェイでも似たような事象があるのでEC2インスタンスもデータを書き込む時にキャッシュしたりしてるかもしれません。

  4. 不整合発生時のリカバリ時など運用面で効率はRDSに劣る。

MySQLレプリケーションのメリット/デメリット
● メリット

  1. 広く利用されてきた方式の為、情報が豊富で導入や運用がし易い。
  2. DRBDよりも同期速度は速い。
  3. MySQL5.5以降の機能のSemi-Syncを使うとデータの整合性が高くなる。
  4. RDS採用よりもコストを抑えられる。

● デメリット

  1. DRBD程ではないが、性能は回線速度に依存する。
  2. CPUやメモリへの負担はDRBDよりも高い。
  3. Semi-Syncを採用してもDRBDより整合性では劣る。
  4. 不整合発生時のリカバリ時など運用面で効率はRDSに劣る。



これらを踏まえて実際に構築して比べてみると性能面では、

RDS > MySQLレプリ > DRBD

耐障害性(フェイルオーバーの迅速さ)では、

DRBD > MySQLレプリ > RDS

導入の容易さや運用効率では、

RDS > MySQLレプリ > DRBD

と、感じましたがここらへんはもっと時間をかけて調査しないと何とも言えない部分もあります。。
DRBDはmicroだとかなり厳しいパフォーマンスでしたが、largeに上げたら一昔前のハードディスクくらいの性能出しましたし、MySQLレプリもSemi-SyncだとDRBDじゃなくても良いんじゃないか?という整合性を保ってくれます。更にはAWSのDRBDは単に構築した段階ではうまく同期とれているように見えましたが、ディスクに大きいデータを書き込むような状況下では不整合しやすかったりなど(DRBDって同時書込みのはずなのに)
まだまだテストや工夫しないとならないようです。

では、各パターンの実際の設定やちょっとしたテストに入って行きたいと思いますが、長くなりましたので次回書きます。次回はパターンの1つめの、

  • Pacemaker(HeartbeatV2) + RDS
  • の設定とテスト結果を書きます。

    CentOS6.4でWebSphereV8.5にJava7を入れる方法

    | コメントをどうぞ

    WebSpherev8.5ではデフォルトでJava6が入っています。
    Java7にしたいと色々検索しましたが、情報が少ないというか錯綜しているというか。
    Java7がすでに入っている状態から切り替える方法、というのもありました。
    WAS 小ワザ集: 第26回:WAS V8.5でSDKを変更する方法

    でも私の利用した環境では入っていなかったので、下記ブログを参考にさせていただき、IBMのリポジトリからダウンロードして設定することができました。
    WebSphere8.5(試用版)にJava7を入れる

    CentOS6.4で行ったときのメモです。

    1. IBMインストールマネージャーでJava7を入れる

    まずCentOSのVMを立ち上げ、以下コマンドでデスクトップ版に切り替えます。

    > startx
    

    続きを読む

    ZabbixでApacheを監視するための設定手順

    | コメントをどうぞ

    今回は、ZabbixでApacheを監視するための設定手順です。

    監視対象サーバーの環境

    • OS: Amazon Linux
    • zabbix-agent: 2.2.5
    • httpd: 2.2.27

    手順

    mod_statusを有効にする

    監視対象サーバーのmod_statusを有効にして、http://localhost/server-statusで稼働状況を確認できるようにします。

    httpd.confを2箇所編集します。

    vi /etc/httpd/conf/httpd.conf
    

    1 以下の行のコメントアウトを解除します。

    ExtendedStatus On
    

    2 以下のコメントアウトを解除して一部修正します。

    Before

    #<Location /server-status>
    #    SetHandler server-status
    #    Order deny,allow
    #    Deny from all
    #    Allow from .example.com
    #</Location>
    

    After

    <Location /server-status>
        SetHandler server-status
        Order deny,allow
        Deny from all
        Allow from 127.0.0.1
    </Location>
    

    ここでは、ローカルからしかアクセスできないように設定しています。
    Apacheを再起動します。

    /etc/init.d/httpd restart
    

    続きを読む

    PostgreSQL セットアップからDBの作成&削除まで

    | コメントをどうぞ

    いつ「ポスグレ使う」と言われてもウロタエないように少し調べてみました。
    今回はインストールとDBを作成および削除する方法について分かったことを記します。
    環境はCentOS 6.5です。

    セットアップ

    # yum postgresql-server
    

    yumpostgresql-serverをインストールすると、依存関係であるpostgresqlpostgresql-libsもインストールされます。

    • postgresql
    • postgresql-libs
    • postgresql-server

    サービスを起動しようとしたところ、以下のメッセージが表示されて起動できませんでした。

    # service postgresql start
    /var/lib/pgsql/data is missing. Use "service postgresql initdb" to initialize the cluster first.
    

    初期化のため、最初にservice postgresql initdbを実行しなければならないようです。
    serviceコマンドでinitdbは指定したことが無かったので、どういうことかとrcスクリプトを見てみたところ

    # cat /etc/init.d/postgresql
    

    initdb()とcase文にinitdbがありました。(startstopが規定というわけではないんですね。)
    納得できたのでメッセージ通りにinitdbを実行し、サービスを起動しました。

    # service postgresql initdb
    # service postgresql start
    

    ちなみにOS起動時にPostgreSQLのサービスを自動で開始したい場合はchkconfigコマンドで設定できます。

    # chkconfig postgresql on
    

    DBの作成と削除

    DBの作成と削除はそれぞれ次のコマンドで可能です。

    createdb ${DB名}
    dropdb ${DB名}
    

    ただし、PostgreSQLではこれらの操作はrootユーザーではできません。rootユーザーで操作しようとすると次のメッセージが表示されました。

    createdb: could not connect to database postgres: FATAL:  ユーザ"root"のIdent認証に失敗しました
    

    なのでインストール時に自動で作成されたユーザーpostgresを使用します。

    su - postgres
    

    なお、作成されたユーザーとグループは次のコマンドで確認できます。

    # id postgres
    uid=XX(postgres) gid=XX(postgres) groups=XX(postgres)
    

    コマンドラインによる操作

    psqlコマンドでPostgreSQLをコマンドラインで操作できます。

    PostgreSQLのバージョンの表示

    # psql --version
    

    コマンドのヘルプの表示

    # psql --help
    

    DBの一覧

    # psql --list
    

    DBへの接続

    #psql ${DB名}
    

    接続が成功するとプロンプトが${DB名}=#になり、テーブルの作成や削除、CRUDの実行が可能になります。
    以下にDBに接続している状態で使用可能なコマンドの一部を記します。

    テーブルの一覧

    =# \d
    

    指定したテーブル情報の一覧

    =# \d ${テーブル名}
    

    DBからの切断と終了

    =# \q
    

    MySQLのLOAD DATA INFILEで大はまりした話

    | 1件のフィードバック

    MySQLにCSVファイルをインポートする際にはLOAD DATA INFILE構文を使います。
    とあるシステムのテーブルにCSVファイルをインポートしたところ、なぜかシステムが正常に動作しなくなり大はまりしました。今回はそんなお話です。

    続きを読む

    DB2のLinuxへのインストール手順&アップグレード手順のまとめ

    | コメントをどうぞ

    背景

    現在RHEL 5.2上にてDB2 Express-C V9.5が稼動しているが、理由があってバージョンアップしたい。しかし、DB2 Express-C V10.5を入手したところ、RHEL 5.2にはインストールできない。DB2 Express-C V10.1も同様であった。このため、DB2 Express-C V9.7にすることにした。

    条件

    OSはRHEL 5.2(x86)。
    DB2はdb2exc_975_LNX_x86.tar.gz。

    続きを読む