mod_cluster で簡単クラスタリング ～ JBoss EAP 編

ご無沙汰しています。サイオステクノロジーの鎌田です。

今回は JBoss のプロジェクトの一つである mod_cluster を使って、クラスタリング構成を簡単に実現するレシピを紹介します。

JBossコマンドラインインタフェースのモード

こんにちは、JBossテクニカルチームの寺田です。 今回は前回に引き続き、JBossコマンドラインインタフェースのモード について紹介していきます。

JBossコマンドラインインタフェースを使ってみる

JBoss テクニカルチームの 寺田 です。
今回は、JBoss EAP6の管理に使用するコマンドラインインタフェースを紹介します。 古いバージョンのJBossでは、twiddle.shと呼ばれるコマンドラインインタフェースで、 コネクションプールの状態、JVMの状態などを取得していました。 EAP6で同じことをしようとすると、jboss-cliと呼ばれるコマンドラインインタ フェースを使うことになります。
今回はこのコマンドラインインタフェースを紹介します。

Oracle Linux 第2回 ゼロ・ダウンタイム アップデート機能「Ksplice」

現在のシステム運用では Linux Kernel のアップデートが必要な場合にはマシンの再起動が必要となるため、適用を先送りにされるケースが多々あるかと思います。しかしながら、セキュリティホールを狙う攻撃は跡を絶たず、これまでも何件もの情報漏えい事故が発生し、社会問題になるケースも数多くあります。

セキュリティソフトで不要なポートを遮断し、ウィルスからサーバを守ることはできますが脆弱性を狙った攻撃に対しては、セキュリティソフトによる対策よりも、対象の脆弱性に対するアップデートパッチを適用することが重要となります。また、 kernel のアップデートパッチにはバグ修正も含まれており、システムをクラッシュさせてしまう問題の修正なども行われております。

クライアントの PC に対しては、常に最新のセキュリティパッチ適用を呼びかけている企業が多い中で、より重要なデータが格納されているサーバに対してはサービスを停止することが出来ないという理由から、最新のセキュリティパッチは当てられていないという現状には矛盾を感じないでしょうか。

ダウンタイムが発生するからアップデートを当てていないという理由でリスクをそのままにしてしまうのであれば、ダウンタイムが発生しない技術があればこの問題は解決できるのではないでしょうか。

Oracle Linux 第1回 導入編 My Oracle Support 登録 ～ Unbreakable Linux Network 登録まで

こんにちは。サイオステクノロジーの小川です。

弊社では幾つか Linux の製品サポートをしておりますが、その中から今回は Oracle Linux について紹介をしていきます。

Oracle Linux の主な特徴として、「ダウンタイムゼロでパッチの適用ができる」という点があります。パッチの適用で、たとえばカーネルアップデートを実施する場合、通常は OS の再起動を行う必要がありますが、Oracle Linux の場合は OS の再起動をすることなくカーネルアップデートができます。

ミッションクリティカルなシステムでサービス停止はビジネスに多大な影響を及ぼしますので、パッチ適用時のダウンタイム発生の課題を抱えるお客様にとって Oracle Linux の導入はベストプラクティスになります。

※ なお、ダウンタイムゼロを実現できるソフトウェアを Ksplice といいます(プレミアムサポートでのみ利用可能。)。使い方などの詳細は次回以降の記事でご紹介します。

また、Oracle Linux のライセンスは、Oracle 社が提供するポータルサイトを通じて Oracle 社のバックエンドサポートが受けられることや、バグフィックスや ERRATA 情報、パッチの取得などのサービスを受けることもできます。

本記事では Oracle Linux を利用するうえで必要な Oracle アカウントの作成や My Oracle Support の登録方法、Oracle Linux 6 のインストールまでを紹介していきます。

webmin ~リモートでサーバ管理~ 管理項目編

お久しぶりです。稲垣です。

前回の記事では、webmin のインストールから最低限行うべき設定変更までご紹介しました。

まだ読んでいない方は、webmin ~リモートでサーバ管理~ インストール編 をまずは読んでみてください。

それでは、前回 https で接続するように設定変更したので、https://[ホスト名 または IP アドレス]:10000/ にアクセスします。

表示されたトップページの左側のメニューに管理可能な項目があります。

全ての管理項目についてご紹介することはできないので、いくつかピックアップしてご紹介いたします。

Zabbix 2.0.3 セットアップ編

こんにちは、サイオステクノロジーの小川です。

今回はオープンソース統合監視ソフトウェア Zabbix の紹介です。

Zabbix は、ライセンス費用無料、かつ 機能が豊富 にあるため、既に多くの企業様が Zabbix に注目し、数々の 導入事例 があります。弊社でもお客様より Zabbix のサポートのご相談を受けることがあり、Zabbix を使用した統合監視ソリューションの需要を感じます。

さて、今回は Zabbix 2.0.3 のセットアップの話ですが、この前 Zabbix 日本法人代表の寺島様が Twitter で、Zabbix 2.0.3 のオフィシャルテスト版 RPM パッケージをアップロードした、とツイートされていたので、早速インストールしてみました。Zabbix 1.8 系を RPM パッケージでインストールするときと同じ感じでできます。

(1.8 系のインストールは ZABBIX-JP の Zabbixのインストール(RPM編) が参考になります。Zabbix の特徴は こちら に記載されています。)

本記事で使用する OS は CentOS 6.3 64bit 最小構成でインストールしています。

rsyslog のログを DB で管理する ( MySQL / PostgreSQL )

こんにちは。サイオステクノロジーの小川です。

前回は rsyslog でログを転送管理する設定をご紹介しました。今回は rsyslog のログを MySQL または PostgreSQL のデータベースに保存する方法をご紹介します。

rsyslog はデフォルトの設定ではログをテキストファイルで保存しますが、rsyslog にモジュールを追加し機能を拡張することでデータベースにログを保存できるようになります。

rsyslog で提供されているモジュールは MySQL の ommysql や PostgreSQL の ompgsql があり、これらのモジュールを追加することで、データベースにログを書き込むことができるようになります。サーバのログをデータベースで一元管理したい、 というような場合は rsyslog のモジュールを是非活用してみてください。

本記事で使用する OS は前回と同様 CentOS 6.3 64bit です。rsyslog やデータベースの使用で必要なパッケージはすべて CentOS に同梱されているものを使用します。 パッケージのバージョンは rsyslog 5.8.10、rsyslog-mysql-5.8.10、mysql-server-5.1.61、rsyslog-pgsql 5.8.10、postgresql-server 8.4.11 です。

rsyslog でリモートホストにログを転送管理する

こんにちは、サイオステクノロジーの小川です。

今回は rsyslog でリモートホストにログを転送する設定と TIPS のご紹介です。

まず、syslog はカーネルやアプリケーションが出力したメッセージをファイルに記録するプログラムですが、今回ご紹介する rsyslog には頭文字に「r」がついています。この「r」は何を示しているのかというと、「reliable」の頭文字で信頼性のある syslog という意味があります。

信頼性があるといえる理由の一つとして、rsyslog はリモートホストに TCP でログメッセージを転送できるという点があります。

syslog のデーモンプログラム syslogd では、ログを別のホストに転送する際に UDP 通信を行うので、送信したログメッセージが相手に届くという保証はありませんが、rsyslog では TCP も使用できるため、ログメッセージの転送を保障します。

障害発生で原因を追跡する際に大事なログが欠落していた、なんて事になったら致命的ですよね。今回はまず、TCP でログメッセージを別のホストに転送する設定を紹介をします。本設定はログのバックアップやログの集中管理を行いたい場合に有効です。

本記事では CentOS 6.3 64 bit、CentOS 同梱の rsyslog 5.8.10 使用しています。なお、CentOS 6.3 では標準で rsyslog はインストールされます。(最小構成でインストールした場合も rsyslog のパッケージが入り、自動的に起動されます。)

RPM パッケージのビルドと作成と公開 (6)

こんにちは、サイオステクノロジーの山田です。

前回は repo ファイルを作成し、repo ファイルと鍵をインストールするだけの単純なパッケージを作成しました。

今回はパッケージを公開するサーバー上でリポジトリを作成し、クライアントでリポジトリの内容を表示したり、パッケージのインストールができることを確認します。

リポジトリ

yum サーバーにリポジトリを作成します。

リポジトリの URL を http://yumserver.labs.sios.com/sios としたので、これに対応する sios というディレクトリを作成し、その配下に i386、x86_64、SRPMS の３つのディレクトリを作成します。

# cd [ドキュメントルートとなっているディレクトリ]
# mkdir sios 
# cd sios 
# mkdir i368 x86_64 SRPMS

作成したディレクトリに、それぞれ i386 で作成した RPM パッケージ (noarch も含める)、x86_64 で作成したパッケージ (noarch も含める)、ソースコード・パッケージ (i386 で作成したものも x86_64で作成したものも同一なので i386 のもの) をコピーします。

サーバの環境構築自動化を考える vol.5: KickStart ～ ks.cfg スタンダード構成編

こんにちは、OSSテクノロジーセンターの原です。

前回は主に ks.cfg の読み方について説明しましたが、そのままの設定ですと必須項目も足りないためインストールを行う事ができません。

今回はその必須項目も合わせて設定し、まずはスタンダードな構成で動くように調整します。

まず前回の ks.cfg ファイルを確認してみましょう。

# Kickstart file automatically generated by anaconda.

#version=DEVEL
install
cdrom
lang en_US.UTF-8
keyboard us
network --onboot no --device eth0 --bootproto dhcp --noipv6
rootpw  --iscrypted XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
firewall --service=ssh
authconfig --enableshadow --passalgo=sha512
selinux --enforcing
timezone --utc Asia/Tokyo
bootloader --location=mbr --driveorder=vda --append="crashkernel=auto rhgb quiet"
# The following is the partition information you requested
# Note that any partitions you deleted are not expressed
# here so unless you clear all partitions first, this is
# not guaranteed to work
#clearpart --linux --drives=vda
#volgroup VolGroup --pesize=4096 pv.01
#logvol / --fstype=ext4 --name=lv_root --vgname=VolGroup --grow --size=1024 --maxsize=51200
#logvol swap --name=lv_swap --vgname=VolGroup --grow --size=2016 --maxsize=2016
#part /boot --fstype=ext4 --size=500
#part pv.01 --grow --size=1

%packages
@core
@server-policy
%end

インストールソースの指定や、ディスク配置の指定など、必須項目が抜けていることがわかります。

これらの必須項目を埋め、ks.cfg ファイルとして利用できるように編集していきましょう。

yum, rpm vs apt-get, dpkg 対応表

こんにちは、サイオステクノロジーの山田です。

サイオスの「OSS よろず相談室」では Red Hat 系の OS だけでなく Debian 系の OS についてもサポートを行なっています。そこで今回の内容は Red Hat 系と Debian 系のパッケージ管理に関してです。

ネットで検索してみると Red Hat 系のパッケージ管理をまとめた記事は Red Hat 系で閉じていて、Debian 系のパッケージ管理をまとめた記事は Debian 系で閉じているものが多く、両方を対照的に書いた記事はあまり見当たりません。そこで今回は両方のパッケージ管理の対応についてまとめました。

両方のパッケージが完全に同じ操作や表示を行うとは限りませんが、大体同じような内容のものだという感覚で利用して下さい。