Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2018年05月18日

Kayo

Pacemaker+Corosyncを使ってみました!(はまった部分をシェア)

みなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。前回前々回と「Pacemaker+Corosyncを使ってみました!」についてお話ししてきましたが、最後に【はまった部分】をみなさんとシェアしたいと思います。何かお役に立つ情報が見つかれば幸いです。

はまった部分①crmファイルのロードエラー

前回の記事で、設定項目をまとめたcrmファイルを作成したとお伝えしました。それぞれの設定が何なのか、下記のように日本語でコメントを記述しました。

しかし、このファイルをロードしたらエラーが発生してしまいました。内容を確認すると、文字コードエラーでした。

日本語がエラーの原因のようで、英語だと特にエラーは出力されませんでした。何の設定なのか英語で書いても他の人に上手く伝わらない!どうしても日本語で記述する必要があったので、下記のコマンドで無理やり読み込むようにしました。

はまった部分②cloneの値を間違った

Pacemaker+Corosync環境の検証のため、当初は2台構成をしていましたが、7台に増やした際にはまった部分があります。crmファイルのclone設定部分を2→7に書き換えるのを忘れてしまいました。
(誤)

(正)

起動した際、ping疎通エラーが出力されてしまい、ログにも「not running」が出力されました。

はまった部分③ping(疎通確認)のIPアドレスが間違っていた

crmファイルに間違ったpingのIPアドレスを記述してしまいました。

(誤)

(正)

crm_monにオプション-Aをつけると詳細を確認できます。pingエラーが出ています。

ping疎通がエラーになったため、「prmVIPcheck」や「IPaddr2_1」も作動しなかったです。

設定を反映する前に、pingコマンドで疎通確認をしておくことも大切です。

3回にわたってPacemaker+Corosyncについてお話ししてきましたが、少しでも興味をもっていただければ嬉しいです。

今後も役立つインフラ情報をアップする予定なので、引き続きよろしくお願いします。


2018年05月8日

Hashimoto Naoto

動的パフォーマンス・ビューでORA-00942が出たときの対処法

インフラ課の橋本です。

OracleDBの操作で、V$●●系テーブル(ビュー)をselectしようとした時、ないしはV$●●系テーブルに対する権限付与を行う際に

というエラーが返った場合の対処法です。

対処法

sysユーザでログインし、以下のようにテーブル(ビュー)名に『_』を付けて権限付与を行う。

解説

  • V$●●系テーブルは動的パフォーマンス・ビューというもの。200以上の種類があります。
    • 一例としてV$SESSIONテーブルなどが、参照権限の付与の要望を受けやすいでしょう。
  • パフォーマンス・ビューにはデータベース管理者(sysユーザ)がアクセス可能です。
  • データベースの状態によって『動的』に更新され続ける性質があり、主に『パフォーマンス』に関連した情報のため「動的パフォーマンス・ビュー」と呼ばれます。
  • V$●●系の動的パフォーマンス・ビューはパブリック・シノニム(特定のユーザが所有しているわけではないエイリアス、別名)であり、実体はV_$●●というテーブルです。
  • そのため、V_$●●に権限を設定してやる必要があります。これは、シノニムを介して権限を設定できないためです。

シノニムを介して権限付与ができないので、エラーとなります。


2018年04月23日

Kayo

Pacemaker+Corosyncを使ってみました!(crmコマンド編)

みなさん、こんにちは。ピクトリンク事業部インフラ課(3月末から事業部名が変わりました)の藤本佳世です。今回は「Pacemaker+Corosyncを使ってみました!」の続編、crmコマンドを使った設定の部分についてお話しします。

前回の記事はこちら

crmコマンド集

Pacemakerの設定をしたり、確認や削除といった作業は、crmコマンドを使って行います。
今回の構築で使ったコマンドをまとめてみました。※詳しい説明は後ほど

Pacemakerの設定

crm configureコマンド使ってPacemakerの設定ができます。

この状態で1つずつ設定していくことも可能ですが、私の場合は、設定したい項目をすべてcrmファイルに書き出して、crm configure load updateコマンドを使って設定を反映させました。

setting.crmの内容はこちらです。
※仮想VIP設定は、「primitive prmVIPcheck ocf:heartbeat:VIPcheck」の部分です。
※ping疎通監視設定は、「primitive pingd_gw ocf:pacemaker:ping」の部分です。

設定内容を確認するコマンドは下記のようにshowを付けます。

また、設定を削除したいときは、eraseを最後に付けます。

ただし、ノードが「running」ステータスでは下記のようなエラーが発生します。

その場合は、全ノードを「standby」ステータスに切り替え、「running」ステータス以外にする事が必要です。

再度「online」ステータスに切り替えるには下記を実行。

そして最後に、設定のバックアップ取っておくコマンドがこちらです。

現在設定されている項目をbackup.crmに書き出してくれます。
設定をバックアップ取っておくと、再構築になった際にとても便利ですね。
backup.crmの使い方は、最初にお伝えしたように、loadするだけです。

 

今回の投稿は以上です。次回は最終版として構築ではまった部分をみなさんに共有したいと思います。


2018年03月7日

Kayo

Pacemaker+Corosyncを使ってみました!(インストール編)

みなさん、こんにちは。コンテンツ・メディア第1事業部インフラ課の藤本佳世です。
今回は、Pacemaker+Corosyncについてお話しします。
今までは、Heartbeatを使っていたのですが、サーバリプレースに伴い、最新バージョンで推奨されているPacemaker+Corosyncを構築しました。まずは、インストールの部分をお話ししたいと思います。

Pacemakerとは

オープンソースソフトウェアとして開発されている、HAクラスタソフトのこと(Heartbeat の後継)。
障害を検知したら他のサーバに自動的にフェイルオーバしてくれます。
Corosyncと組み合わせて利用します。
※HAとは、「High Availability」高可用性のこと。

Corosyncとは

ノードの死活監視を行うオープンソースソフトウェア。
Pacemakerと組み合わせて、クラスタシステムを構成します。

フリューでの利用について

主に、データベースサーバでPacemaker+Corosyncを採用しています。
サーバ(master)に仮想VIPがセカンダリIPとして割り当てられており、サーバ(master)に障害が発生した際、10秒以内(弊社環境)でサーバ(slave)に仮想VIPが付与され、masterとして稼働します。
以前のHeartbeatよりも、Corosyncの方が切替の時間が早いというメリットもあります。

構築した環境

サーバ名 OS Pacemakerバージョン Corosyncバージョン IPアドレス 仮想VIP
server1 CentOS7.4 1.1.16.1 2.4.2-1 192.168.33.28 192.168.33.21
server2 CentOS7.4 1.1.16.1 2.4.2-1 192.168.33.29

Pacemaker+Corosyncの構築

LINUX-HA JAPANのドキュメントを参考に進めました。
詳しく手順が書かれているので、この通りに進めるだけです。

インストールの後は、corosync.confを修正します。

以下のbindnetaddrとquorumの部分を修正しました。

  • bindnetaddr:構築するネットワーク環境に合わせて設定
  • expected_votes :クラスタを構成するノードの数を設定

続いて、corosync認証鍵ファイルの設定です。
どれか一つのノード上で実行します。

/etc/corosync配下にauthkey ファイルが生成されます。
作成されたauthkeyファイルをクラスタを構成する全てのノードにコピーします。

この後は、pacemakerファイルの設定です。
pacemakerの内部プロセスが故障した場合も、ノード故障として取り扱うようにするため、
以下の設定に変更します。

そして、最後にクラスタ起動スクリプトの設定です。
ドキュメントに下記の設定を反映させるために修正が必要と書かれています。

  • pacemakerサービス停止時に corosyncサービスも同時に停止させるため
  • corosyncプロセス故障時に watchdog 機能を有効にするため
  • corosyncの改善により soft_margin オプションは不要となったため

※ExecStart/Stop は置き換える前に空白にする必要があるので注意してください。

これで完了です。
ドキュメント通り進めるだけなので、簡単に構築できると思います。

いよいよ起動

設定が終わったら、いよいよ起動です。

起動確認

Onlineになっています!問題なさそうです。

ここまでがインストールの作業です。
次に、仮想VIPやping疎通監視など設定していきますが、詳細は次回説明したいと思います。
crm configureコマンドを使った設定などご紹介する予定なので、お楽しみに。


2018年02月8日

Hashimoto Naoto

ESXi6.5でOS再起動時に公開鍵が消える問題の対処方法

コンテンツ・メディア第1事業部インフラ課の橋本です。
弊社では仮想サーバをオンプレ環境で構築するための基盤(ホスト)OSとして、一部ではESXiを利用しています。

概ね便利に使えるESXiサーバには、困った特徴というか仕様がありまして、/etc 以下であるとか /bin 以下の階層に配置したファイルが、OS再起動時に初期化(クリア)されてしまいます。

接続を便利にしてくれる公開鍵なんかも、ESXiサーバを再起動するたびに消えてしまいます。

そして、以前のESXi(バージョン5.5や6.0において)で使えたいくつかの対処法は、検証した限りでは使えなくなっています。(そればかりか、再起動時にパープルスクリーンで固まってしまい、OSが起動しなくなったりさえします。なんということでしょう!)

そのため、今回ご紹介する対処方法も、これまでの方法と同様にバージョン互換性がない可能性が大いに有り得ます。具体的にはESXi6.5以外のバージョンで使えるという保障はございません。あらかじめ、ご了承いただきたく思います。

追記:ESXiの新バージョン(6.7以降?)では、このディスククリアを無効化する設定が追加されるそうです! やった……!!

対処方法

「そもそも消されないようにする」というのが実現困難でしたので、今回は「再起動時に配置しなおす」というアプローチです。

大まかな手順はふたつです。
ひとつめ、鍵をバックアップする。
ふたつめ、再起動時に展開されるようにする。

公開鍵のバックアップをとる

以下はEXSiサーバ上での操作です。sshなどで接続します。
まずは、公開鍵ファイルをバックアップするスクリプトを用意しましょう。

13〜16行目にあたる部分で、authorized_keys をリストアップし、tarで固めています。
ここで、16行目でbin/keys-backup.sh(このスクリプト自身)をも含めているのは、このスクリプトを/binに配置しているので再起動によって容赦無く消されるためですむごい。

authorized_keysではなく、自前のスクリプトや他のファイルを保持しておきたいという場合は、この13行目〜16行目の探索条件を調整してみてくださいね。
なお、tarで圧縮する際は相対パスで指定するようにお気をつけください。
絶対パスで指定すると、展開時にも絶対パスで展開されるので、えらい目に遭うことがあります。
上記スクリプトで、わざわざ3行目に cd / の後、14行目で相対パスに直してアーカイブしているのは、そのためです。

次に、実行権限をつけておきます。

keys-backup.sh を実行すると、/bootbank/sshkeys.tgzが出来ているはずです。
念のため、アーカイブの中身を確認してみましょう。

authrized_keys 各種とkeys-backup.shがアーカイブされていれば成功です。
新しくauthrized_keysを配置したときには、併せてkeys-backup.shを実行するようにしましょう。

再起動時にアーカイブを展開させる

あと少しです。再起動時にsshkeys.tgzを展開するように仕込みを行います。

/etc/rc.local.d/local.sh はEXSi6.5ではもともと配置されているファイルです。

ファイル内に

# Note: modify at your own risk!

と記述がありますように、運用にはご注意ください。
このファイルのexit 0の前に、1, 2行目の内容を挿入しておきます。
これで、再起動が完了後に/bootbank/sshkeys.tgzが展開されるようになります。

/bin/auto-backup.sh にも似たような仕組みがもともと存在するのですが、拡張を意図されていない既存のコードはなるべく変更を加えたくないなぁ……という思いから、今回は別のスクリプトで手動実行する方式としています。