Viewing entries tagged
Stash

Atlassian Stashの耐障害性を高めよう その4 分散ストレージ設定編

Atlassian Stashの耐障害性を高めよう その4 分散ストレージ設定編

今回もStashの高可用性を目指してクラスタを組んでいきたいと思います。
前回までで、サーバーとStashのプロセスの冗長化は一旦完了したので、
今回は一番重要なデータ保存領域の冗長化を目指します。

お知らせ

今までAtlassian Stash を冗長化しようと頑張ってきましたが、つい先日なんとAtlassian Stashがなくなってしまいました。
今度からは生まれ変わった? Bitbucket Server をよろしくお願いします。

・・・閑話休題・・・

それでは、Stash改めBitbucket Serverのストレージを冗長化したいと思います。

Atlassianの公式によるとストレージは GFS2 + DRBD でストレージの冗長化を行っていますが、
今回は個人的な興味で、GlusterFSを使って冗長構成をしてみたいと思います。

事前準備

VagrantにDISKを追加

Virtualbox コンソール経由で、node01,node02 にDISKを追加します。
Stashのデータに使用するので、保存するデータの容量によって大きさを考える必要があります。
今回は仮に8GBとして データ用にパーティション /dev/sdb1 を作成しました。

GlusterFSのインストール(全ノード)

パッケージのインストール

    cd /etc/yum.repos.d/
    curl -o glusterfs.repo http://download.gluster.org/pub/gluster/glusterfs/LATEST/CentOS/glusterfs-epel.repo
    yum install glusterfs-server

通信ポートの開放

まずは、通信に必要なポートを開放します。
今回は実験用途なのでどこからでも通信可能に設定してしまいます。

/usr/lib/firewalld/services/glusterfs.xml を以下の内容で作成します。

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>GlusterFS</short>
  <description>GlusterFS</description>
  <port protocol="tcp" port="1111"/>
  <port protocol="tcp" port="24007-24100"/>
    <port protocol="tcp" port="49152"/>
</service>

作成したファイルをもとにfirewallの設定を変更します。

firewall-cmd --permanent --add-service=glusterfs
firewall-cmd --reload

GlusterFS Volumeの作成

次にGlusterFSで使用するディスクの準備をします。

ファイルシステムの作成

GlusterFSは共有するボリュームのファイルシステムをXFSにする必要があります。
まずはデータ用のボリュームをXFSで用意します。

mkfs.xfs /dev/sdb1

/etc/fstab の末尾にエントリを追加します。

/dev/sdb1       /data                      xfs     defaults        0 0

マウントします。

mount -a

GlusterFSの起動

systemctl start glusterd
systemctl enable glusterd    

GlusterFSのノード登録

node01

gluster peer probe node02

node02

gluster peer probe node01

GlusterFSのVolume作成(任意の1ノードで実行)

mkdir -p /data/atlassian/stash
gluster volume create stash_vol replica 2 node01:/data/atlassian/stash node02:/data/atlassian/stash
gluster volume start stash_vol

GlusterFSのマウント

マウントポイントの作成

まずマウントポイントを作成します。
既存のStashのデータディレクトリはあとでGlusterFS上にコピーするためリネームして退避しておきます。

mv /var/atlassian/application-data/stash /var/atlassian/application-data/stash.org
mkdir -p  /var/atlassian/application-data/stash
chown atlstash:atlstash /var/atlassian/application-data/stash

fstabの修正

次に各ノードで /etc/fstab にエントリを追加します。

node01

node01:stash_vol        /var/atlassian/application-data/stash   glusterfs       defaults        0 0

node02

node02:stash_vol        /var/atlassian/application-data/stash   glusterfs       defaults        0 0

ファイルシステムのマウント

次に、両方のノードでglusterfsをマウントします。

mount -a

既存データのコピー

次に、今までのデータをどちらか一方のノードでコピーします

cp -rp /var/atlassian/application-data/stash.org/* /var/atlassian/application-data/stash/.

これで課題だったDISKの冗長化も出来、Stash改めBitbucketServerのクラスタリングが完了しました。
実際の運用では、定期的なデータのバックアップは行う事はあっても、クラスタリングをすることはまれかもしれませんが、
クラスタリングを検討されている方の参考になれば幸いです。

※ このシリーズの記事はあくまで検証用途でクラスタの設定を行っているため、実際の環境では使用に耐えない可能性があります。
実際にHAを構成を行う場合には十分な検証を行うことをおすすめします。

Atlassian Stashの耐障害性を高めよう その2 HAセットアップ編

Atlassian Stashの耐障害性を高めよう その2 HAセットアップ編

今回は 前回 「Atlassian Stashの耐障害性を高めよう その1 プランニング編」 の続きとして、
HAクラスタのセットアップを行いたいと思います。

手順はredhat向けのHIGH AVAILABILITY ADD-ON リファレンス を参考に行っていきます

今回の構成

今回は、LinuxのHAクラスタミドルウェアの定番であるPacemakerを使用してクラスタを構成します。

ソフトウェアバージョン
CentOS7.1
Pacemaker1.1.12
Corosync2.3.4
pcs0.9.137

ノード設定

ホスト名IP備考
node01192,168.33.21Stash node #1
node02192,168.33.22Stash node #2
stash192,168.33.101Stash VIP

事前準備

クラスタ構成の際にお互いのノード名を解決出来なければならないので、
/etc/hosts にホストを追加しておきます。

/etc/hosts

192.168.33.21 node01
192.168.33.22 node02

次にクラスタの通信に使用するポートを開放します

# firewall-cmd --permanent --add-service=high-availability
# firewall-cmd --add-service=high-availability

ソフトウェアのインストール

それでは、必要なソフトウェアをインストールしていきます。

# yum install pcs fence-agents-all

コマンドを両方のノードで実行します。
これだけでHAクラスタに必要なソフト一式がインストールされます。

インストールが無事完了したら、クラスタの構成を行うコマンドのデーモンである pcsd を起動します。
また、再起動時に自動的に起動するように設定します。

# systemctl start pcsd
# systemctl enable pcsd

クラスタの構築

次に、node01,node02をメンバーとして、HAクラスタを構築します。

hacluster ユーザーのパスワードを設定

ここでは、マニュアルの推奨に従って、両ノードともに同じパスワードを設定します。

# passwd hacluster

これも両ノードで実行します。

クラスタノードの認証

クラスタノード間の認証設定をします。

# pcs cluster auth node01 node02 -u hacluster -p hacluster

クラスタの作成

クラスタを作成します

pcs cluster setup --start --name stash node01 node02

クラスタ状態の確認

作成したクラスタの状況を確認します。

# pcs cluster status
Cluster Status: Last updated: Mon Sep 14 09:46:54 2015 Last change: Mon Sep 14 09:42:40 2015 by hacluster via crmd on node02
Stack: corosync Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 0 resources configured

Online: [ node01 node02 ]

PCSD Status: 
  node01: Online
  node02: Online

両ノードがOnlineとなっていればOKです。

STONITH の無効化

ここで、/var/log/messages を確認すると。

Sep 14 11:16:14 localhost pengine[4158]: error: Resource start-up disabled since no STONITH resources
have been defined
Sep 14 11:16:14 localhost pengine[4158]: error: Either configure some or disable STONITH with the ston
ith-enabled option
Sep 14 11:16:14 localhost pengine[4158]: error: NOTE: Clusters with shared data need STONITH to ensure
 data integrity
 
といったエラーが発生しています。
この[ページ][0]によると STONITHと呼ばれるノードが不安定になった場合、自動的に再起動を行う機能が有効になっているものの、その機能を実現するためのリソースが無いためエラーとなってしまっているようです。 現時点ではSTONITHを使用しないため、
pcs property set stonith-enabled=false

を実行し、機能を無効化します。

リソースの作成

クラスタの設定が終わったところで、次にリソースを設定します。
クラスタでのリソースとは、特にクラスタノード間で共有するリソースのことを指します。
例えばアクティブノードが使用する仮想IPなどです。

今回は、ユーザーがアクセスする際に指定する、サービス用の仮想IPをリソースとして追加します。

どちらかのノードでコマンドを実行します。

# pcs resource create stash_vip IPaddr2 ip=192.168.33.101 cidr_netmask=24 op monitor interval=6s

これで、6秒ごとに死活確認を行うIPアドレスの共有リソースが設定されました。
具体的には、アクティブノードに 192.168.33.101 のIPエイリアスが設定されます。

ノード切り替えのテスト

サービス用の仮想IPが割り当てられることが確認出来ましたので、
正しく系切り替えが行えるか確認してみたいと思います。

アクティブノードの障害

アクティブノードの障害時に正常に切り替わるか確認してみましょう。

Active : node01 Standby: node02

の状態で、node01の電源をOFFしてみます。

実施前

# pcs status
Cluster name: stash
Last updated: Mon Sep 14 12:14:31 2015        Last change: Mon Sep 14 11:51:35 2015 by root via crm_attribute on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 1 resource configured

Online: [ node01 node02 ]

Full list of resources:

 stash_vip    (ocf::heartbeat:IPaddr2):   Started node01

PCSD Status:
  node01: Online
  node02: Online

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

2ノードともオンラインで、stash_vip は node01に割り当てられています。

ここで node01 の電源をOFFにします

# pcs status
Cluster name: stash
Last updated: Mon Sep 14 12:18:31 2015        Last change: Mon Sep 14 11:51:35 2015 by root via crm_attribute on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 1 resource configured

Online: [ node02 ]
OFFLINE: [ node01 ]

Full list of resources:

 stash_vip    (ocf::heartbeat:IPaddr2):   Started node02

PCSD Status:
  node01: Offline
  node02: Online

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

正常に node02 にIPが切り替わりました。
この間pingを192.168.33.101宛に行っていましたが、今回はpingが途切れる事なくノードが切り替わりました。

スタンバイノードの追加

では、次に稼働中のクラスタに、node01を追加します。

node01を起動し、node01でクラスタを起動します。

# pcs cluster start

正常に node01がクラスタに参加しました、ただアクティブノードはnode02のままです。

pcs status
Cluster name: stash
Last updated: Mon Sep 14 12:24:38 2015        Last change: Mon Sep 14 11:51:35 2015 by root via crm_attribute on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 1 resource configured

Online: [ node01 node02 ]

Full list of resources:

 stash_vip    (ocf::heartbeat:IPaddr2):   Started node02

PCSD Status:
  node01: Online
  node02: Online

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

アクティブノードの手動切替

最後に、アクティブノードを切り替えます。
片系ずつ切り替えながらメンテナンスする際に威力を発揮しそうです。

アクティブノードをスタンバイ状態にし、強制的にきりかえます。
アクティブノード上で下記のコマンドを実行します。

 # pcs cluster standby
 
正常にノードが切り替わり、node01がアクティブになりました。
# pcs status
Cluster name: stash
Last updated: Mon Sep 14 12:44:33 2015        Last change: Mon Sep 14 12:44:24 2015 by root via crm_attribute on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 1 resource configured

Node node02: standby
Online: [ node01 ]

Full list of resources:

 stash_vip    (ocf::heartbeat:IPaddr2):   Started node01

PCSD Status:
  node01: Online
  node02: Online

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

ただ、このままですと node01に障害が発生した場合でもnode02に切り替わらないので、 node02のスタンバイ状態を解除します。
スタンバイ状態のノードで以下のコマンドを実行します。

# pcs cluster unstandby
pcs status
Cluster name: stash
Last updated: Mon Sep 14 12:46:29 2015        Last change: Mon Sep 14 12:46:27 2015 by root via crm_attribute on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 1 resource configured

Online: [ node01 node02 ]

Full list of resources:

 stash_vip    (ocf::heartbeat:IPaddr2):   Started node01

PCSD Status:
  node01: Online
  node02: Online

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

node02がアクティブになりました。

今回はここまで

これでひと通りのクラスタ切り替えの動作の確認が出来ました。
しかしながら、IPの切り替えだけではStashの冗長化は出来ません。
次回は、ストレージの冗長化を設定しStashの冗長化を完成させたいと思います。

参考資料:

RED HAT ENTERPRISE LINUX 7 向け HIGH AVAILABILITY ADD-ON のリファレンスドキュメント
リファレンスなので、ひと通り情報は乗っているが、ステップバイステップで構築の手順となっていなく、コマンド例ももう一声ほしいところ。 総じて、読み解くのに読者の頑張りが必要なドキュメント。。。

CentOS7.1でPacemaker+corosyncによるクラスタを構成する(Part.1)
CentOS7 + Pacemaker でのクラスタ構築からVIP設定までが非常に丁寧にステップバイステップで解説されています。 最終的には、このエントリもほぼ似たような感じになってしまいました。