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月17日

furusin

フリュー主催の勉強会を開催します!

はじめまして!ピクトリンク事業部サービス開発2課の古川と申します。

昨年10月にJOINし、京都でPICTLINKのAndroidアプリ開発に携わっています。

これからどうぞよろしくお願い致します。

タイトルの通りですが、フリュー主催の技術勉強会を開催することとなりました。

勉強会詳細

日時

2018/05/25(金)19:00 〜 21:30

場所

弊社会議室(京都タワーホテル4階)

内容

初回はモバイルを題材として開催します!

今後はモバイルだけでなく、様々な技術分野に関する勉強会が開催できればと考えております。

参加をご希望の方はこちら「京都Devかふぇ #1 〜モバイル〜」からご登録お願いします。

なぜフリューが勉強会をやるのか?

フリューでは社内で活発に勉強会が開かれています。

積極的に社外の勉強会に参加しているメンバーも多数おりますが、

「関西は東京に比べて圧倒的に勉強会が少ない」

という感想を皆持っており、多少の危機感を感じています。

そこで、関西の技術力の向上や活発な技術者間の交流に貢献し、共に成長したく、フリューとして京都で勉強会を開催することとなりました。

勉強会会場への行き方

勉強会の会場は多少わかりにくい場所にございますので、ここで解説致します。

 

ステップ1.JR京都駅から京都タワーホテルへ向かう

こちらのリンクからGoogle Mapでたどり着くことも可能ですが、念のため解説します。

まずは京都駅の中央改札口から出ます。

IMG02878_HDR

 

そのまま真っすぐ外に出ると視界が開け、京都タワーが見えます。会場はその真下です。

IMG02879

 

京都タワーに向かって歩いていくと、信号があります。信号を渡ったらすぐそこです!

IMG02881_HDR

 

ステップ2.京都タワーホテル内へ入る

ここで注意!信号を渡ったら目の前に入り口がありますが、ここからは入らないようにしましょう。

信号を渡ったら左に曲がります。

IMG02883_HDR

ビルに沿って少し歩くと、辻利さんが見えてきますので、その手前の出入り口「KYOTO TOWER HOTEL」とある所から入ります。

(下に降りる方ではなく自動ドアの方です)

IMG02884

 

ステップ3.会場の4階へエレベーターで上がる

自動ドアから入ると、辻利さんの横にエレベーターがありますので、ここから4階へ上がります。

IMG02885

4階へ上がると少し殺風景ですが、エレベーターを降りたら左へ行きます。

IMG02886

少しわかりにくいですが、エレベーターを降りて左に真っすぐ行った突き当りが会場となります!

(当日はここに張り紙をする予定です)

IMG02887

 

ちなみに・・・

エレベーターはもう1箇所あり、そちらから上がると非常にわかりにくい場所に出てしまいます。

その場合はこの矢印のある方向へ突き当りまで道なりに進んでください。先程の場所へたどり着けます。

 

IMG02888

 


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月27日

CentOS7でのSpring Bootの起動について

こんにちは。フリューのジョンです。

さてさて、以前以下の記事でSpring Bootアプリケーションのserviceでの起動について触れました。
Spring Boot アプリケーションの再起動時にハマったこと

しかし、上記はCentOS6での話でした。CentOS7になるとより柔軟なサービスの管理ができます。
さて、何が変わるのでしょうか?

serviceとsystemctlの違い

私が感じている良い点としては以下です

  1. systemctl statusでサービスの状態がわかる(いつ起動したのかなどもわかります)
  2. 後述する、ユニットファイルの設定によって起動の依存を記述することができる(あるサービスが起動していなければ動かさないなど
  3. 起動時、停止時に呼ばれるスクリプトを指定することができる

実際に複雑なマイクロサービスを作っていく上では欲しい機能になるかと思います。

変更方法

主に前回のものとの比較になりますが2点が異なるのみです。

サービスの登録方法がことなる

サービスの登録には以下のコマンドを実行していましたが

CentOS7では、プロセス名.service というユニットファイルを /usr/lib/systemd/system に配置します。
中身は以下のようになります。(中身の詳細は 9.6. システムのユニットファイルの作成および変更 を参照ください)

プロセスの起動方法が異なる

サービスの実行には以下コマンドで実行していましたが、

CentOS7では、systemctlコマンドを利用します。

この2点だけです。それ以外のconfファイルの書き方、配置などは全く変わりません。

補足

デフォルトのユニットファイル設定では /var/log/messages にログが吐き出されます。
そのため、アプリケーションのログは別に出しているし、ここに吐き出されたくない場合はユニットファイルのServiceに以下を追加します。

まとめ

systemctlコマンドによる起動で再起動スクリプトを自作する必要もありません(serviceによる起動でも同じですが
マイクロサービスを進めていくには、インフラ回りについてきちんと勉強していく必要があると感じます。

それでは素敵なマイクロサービス運用、Spring Bootライフを!!

弊社では一緒にサービスを作ってくれるSpringエンジニアを募集しています!!

詳しくはこちら

追記:

Spring Boot 2系でのリリースについて若干変更がありましたのでページを作りました。
Spring Boot 2系でServiceによる起動をさせてみる