Furyu
[フリュー公式]

Tech Blog

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

2018年09月20日

Kayo

sshfsを使ってみました!

みなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。
今回は、使ってみてとても便利だった「sshfs」をご紹介したいと思います。

sshfsとは

SSHを経由して、他のサーバのディレクトリをマウントすることができるコマンドです。

なぜ便利なのか?

私は日々の業務でよくAnsibleを使ってサーバのミドルウェアのインストールや設定などを行います。
※Ansibleについては、以前ブログを書いているのでこちらをご覧ください。

 

今までは自分のローカルUbuntu環境からAnsibleを実行していたのですが、Macから実行すると環境違いでエラーになる事などがありました。
この状況を解消すべく、インフラ課のメンバー全員が同じ環境でAnsibleを実行できるよう専用サーバを構築しました。しかし、ローカルとリモートのコードを2重で管理という面倒な仕様になってしまい、何か解消する方法はないかと悩んでいました。

blog1

そんな時見つけたのが「sshfs」です。
これを使ってリモートで直接コードを修正しつつ、ローカルでのデバッグ実行も可能となり、とても便利になりました。

NFSと比較した場合、リモートサーバでコマンドを実行する(=SSHでログインして実行する)環境が既にできあがっているので、ローカル側にプログラムをインストールするだけで実現可能というお手軽さもあります。

使い方は簡単

  • sshfsのインストール(Ubuntuの場合)

  • マウント方法

例として、私のローカルマシーンの/testというディレクトリを作成し、サーバserver1の/home/fujimoto.kayoディレクトリをマウントします。

あとは、sshfsコマンドをローカルマシーンから実行するだけです。

これでマウントができた状態です。実際にサーバserver1の/home/fujimoto.kayo配下には、example-ansibleディレクトリが存在しますが、
ローカルマシーンの/test配下にも同じexample-ansibleが存在します。

  • アンマウント方法も簡単

最後に

コードの2重管理がなくなったり、コードの修正をローカルで使い慣れている環境のエディタで編集できたり、ちょっとした工夫で日々の業務がスムーズに行えるようになりました。

是非、皆さんもこの「sshfs」を使ってみて下さい!


2018年08月27日

Kayo

サーバ増設したらDNSラウンドロビンが壊れた!?

はじめに

みなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。

 

先日、稼働中のサーバにアクセスが集中したため、サーバ増設を行いました。

その作業の1つとして、DNSラウンドロビン設定に増設したサーバを追加したのですが、上手く負荷分散されず、今まで特に問題なく利用していたDNSラウンドロビンの思わぬ落とし穴にはまってしまったので、忘れないようにブログに書いておきます。

DNSラウンドロビンとは

1つのドメイン名に複数のIPアドレスを割り当て、負荷を分散させる技術のこと。

スライド1

 

メリットは、簡単に設定ができることです。

スライド2
私が行ったように急遽サーバ増設が必要になった場合でも、zoneファイル上の対象ドメイン名に増設したサーバのIPアドレスを追加するだけで負荷分散してくれます。

 

デメリットは、万が一、サーバに障害が発生しても検知することができず、負荷を分散し続けてしまうこと。結果クライアントにエラーが返されてしまいます。

はまったこと

zoneファイル上の対象ドメイン名(test.com)に、増設したサーバ2台のIPアドレスを追加しました。

下記、実際に追加したzoneファイルの中身です。

この変更を加えるまでは、問題なく4台で負荷分散できていたのですが、2台を追加したことで、この2台しか負荷分散ができなくなったしまったのです。

スライド3

原因

DNSラウンドロビンの数に制限があるかなど、色々調べてみましたが、

原因は、増設したIPアドレスの「一致長が変わったのが原因でした。※参考になったURLがこちら

スライド4

4列目のIPアドレスと問い合わせる側の自分のIPアドレス(192.168.0.1)を比較し、一致する部分の長さが最も大きくなるものが使われるようです。つまり、増設した192.168.0.6と192.168.0.7が選択され、それ以外のものは使われなくなってしまったということです。

対応策

一致長が異なるのが問題だったので、これを合わせてやる(別のIPアドレスを使う)ことで増設することができました。

まとめ

DNSラウンドロビンはとても簡単に設定ができるので、弊社でも長らく利用してきました。

今回、思わぬ落とし穴にはまってしまったのですが、DNSラウンドロビンの問題は今回のものだけではありません。例えば、DNSサーバのBINDのバージョン9.13.2(unstable版)では、そもそもラウンドロビンが動作しなくなっているようです。
DNSは名前解決に専念させ、負荷分散はロードバランサに任せるなど、今後もDNSラウンドロビンを使い続けるかどうか慎重な検討が必要のようです。


2018年07月30日

Kayo

便利なtmux-xpanesのご紹介

みなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。
今回は、使ってみてとても便利だった「tmux-xpanes」をご紹介したいと思います。

 

すでに「tmux-xpanes」ご存知の方いらっしゃるかもしれませんが、とても便利なコマンドです。

私は業務でよくサーバにsshログインし、コマンドを実行します。よくあるケースが、10台のサーバに配置された同じサービスをそれぞれ起動したりします。今までは、1台ずつサーバにsshログイン→起動→起動確認→次のサーバという動作を繰り返していました。

 

繰り返すのはとても面倒ですし、時間もかかります。そんな時見つけたのが「tmux-xpanes」です。「tmux-xpanes」を使うと、このような10回繰り返す操作を1回で済ませることができるのです。更に、サービス起動を同じタイミングで実施したいという場合にもとても便利です。

 

「tmux-xpanes」のインストール方法や詳細については、公式のREADME.mdに詳しく書かれているのでご覧ください。

使い方

例として、test-01~04というサーバにログインして、一度に4台すべてのhttpdを起動させます。
まず、ターミナルを開いてサーバにログイン。–sshオプションをつけて、sshログインします。
※他にもオプションがありますが、私が良く使うのはsshです。その他のオプションについては、先ほどの公式README.mdを見て下さいね。

<実際の画面>

1

Enterを押すと、画面が4分割され、サーバ4台にログインできました。

<実際の画面>

2

あとは、httpd起動コマンドを入力するだけですが、4サーバで同時にコマンドが打てます。

<実際の画面>

3

無事4台同時に起動することができました。

<実際の画面>

4

最後に

「tmux-xpanes」は、複数台同時にコマンドが打てるので、仕事も捗ります。

みなさんも是非、この便利な「tmux-xpanes」コマンド使ってみて下さい。
ただし、間違ったコマンドを打ってしまうと大変なことになったりもしますので、操作するときは気をつけて下さいね。


2018年06月28日

Kayo

DNS逆引きやってみました!

みなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。
今回は「DNS逆引き」についてお話しします。
インフラ業務を行っていると、「このIPアドレス、どこのサーバ?」といった状況に出くわすことが多く、今回DNS逆引き対応をして、日々の業務改善ができました。

DNSとは

DNSとは、Domain Name Systemの略で、ホスト名をもとに、ホストのIPアドレスを教えてくれます。
IPアドレスとは、サーバ1台ずつに割り振られた識別番号で、ネットワーク上の住所のようなもの。
このIPアドレスをもとに、情報のやり取りをします。

例として、nslookupを使って、test01.server.com(ホスト名)のIPアドレスを調べてみます。

IPアドレスは、192.168.33.60と教えてくれます。
IPアドレスは、8bitごとに4つに分割され、それぞれ10進数で表示されます。

上記の例では、test01.server.comというホスト名に対して、IPアドレスを取得しました。
しかし、もしこれが「192.168.33.60」だけ知っていて、ホスト名を調べる際どうすればいいでしょうか?

この問題を解決してくれるのが、DNS逆引きです。

DNS逆引きとは

ホストのIPアドレスをもとに、ホスト名を教えてくれます。
nslookupを使って、192.168.33.60のホスト名を調べます。

ホスト名は、test01.server.comと教えてくれます。

逆引きを実施したときの、60.33.168.192.in-addr.arpaとは何でしょうか?

in-addr.arpaとは

IPアドレスに名前を付けたものが、in-addr.arpaアドレスです。
つまり、192.168.33.60のin-addr.arpaアドレスは60.33.168.192.in-addr.arpaとなります。

逆引きの設定

/var/named/chroot/etc/named.confに設定を追加

/var/named/chroot/var/named/data/192.168.33.revファイルを指定します。

そして、192.168.33.revファイルの中身がこちらです。

60はtest01.server.com、61はtest02.server.comだと分かります。

このように設定ファイルを少し修正するだけで、DNS逆引きをすることが可能となりました。
とても便利なので、みなさんも是非やってみて下さい!


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についてお話ししてきましたが、少しでも興味をもっていただければ嬉しいです。

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