Scalr ハンズオンセミナーに参加しました

覚書 クラウド

Scalrというもの自体、初耳でした。

RiGHT SCALE が代表的なサービスですが、
クラウドサービスをAPI経由で操作する共通のコントロールパネルみたいなサービスですね。

対応しているクラウドサービスであれば、
サービスをまたがって共通のコントロールパネルが使えるという感じです。

なので、AmazonEC2 と IDCFのセルフ型NOAHが サーバ一覧に並ぶ。
ということも出来るわけです。

RiGHT SCALEでもたいていの事は出来るみたいですが、
触ったことが無いので比較しようが無いです。

今回はScalrをさわってどういうところが便利だったか書いておこうと思います。

サーバデプロイが便利

サーバのデプロイは 機能別に用意されたイメージがあるので、
機能を選択して追加するだけ、といった簡単な手順で追加することが出来る。

MySQLのサーバを追加すると、
1台目がMasterになり、2台目からはSlaveとして動作するように
自動的に設定してくれる。

Masterが死んだ場合、自動的にSlaveがMasterに昇格するような機能も有るとのこと。

DBサーバが増えても共通の読み書き別々のホスト名を用意することで
DNSラウンドロビンが出来る。

DBサーバMaster :10.XXX.XXX.1
DBサーバSlave :10.XXX.XXX.2

DNSレコード read.db.Private: 10.XXX.XXX.1 , 10.XXX.XXX.2

read.db.private にアクセスすると 2台のIPが登録されてるので、
どっちかにアクセスしてDBを読み出す事が出来る。
といった具合。

アプリケーションデプロイが便利

簡単なアプリケーションであれば デプロイまですることが出来る。
http経由でWordpressのtarを落としてきて、
コマンドをスクリプトとして書く事でデプロイを自動で行う事が可能。

また、svnとgit経由でもデプロイ出来るらしい。

オートスケールが便利

NOAHだけだと自動でスケールしないんですが、
Scalrを使うと自動化ができます。

条件を指定して スケールアウト後の最大インスタンス数などを指定すれば
出来るみたいです。

条件として面白いのは 日付・時間。
何曜日の何時から何時までは2台。
といった条件を構築することが出来る。

まとめ

Rightscaleを触ったことがないので比較出来ないのが残念ですが、
参加していた方のお話だと Scalrの方が分かりやすいメニューになっているようです。
Rightscaleはメニューがごちゃごちゃしているみたいですね。

RightScaleもScalrも有料のサービスではありますが、
大量のインスタンスを管理するとなると大変なので、
こういったサービスを有効的に活用して行きたいですね。

1日経つとRubyコマンドが使えなくなる

覚書 Linux

又聞きなので正確な情報ではないですが、覚書。

概要

GitとGitlabを入れてローカルGitとして運用をしていたサーバで起きた事。
1日経つとRubyコマンドが使えなくなっている。
復旧するために毎回インストールしなおしていた。

調査

毎日使えなくなるので、Cronで行われている何かだろうと推測。

Cron.dailyに怪しいのを発見。
prelink

どうもこの prelinkがRubyのバイナリを破壊するらしい。
http://www.cozzbox.com/wordpress/archives/365

対処

prelink を使うと良い効果もあるみたいなので、rubyだけ対象外にする。

/etc/prelink.conf に直接書くか。

-b /usr/bin/ruby

-b は ブラックリストのｂらしい。
以下、/etc/prelink.conf内のコメント。

# Directories or files with `-b ' prefix will be blacklisted.

もしくは /etc/prelink.conf.d/に ruby.conf とか作ってあげるのも良い。

/etc/prelink.conf の中で
-c /etc/prelink.conf.d/*.conf として読んでるので、自動的に読み込まれる。

これでRubyのバイナリがおかしくなることも無くなったそうです。

MySQLがネットワーク経由で接続出来ない

覚書 MySQL Linux

MySQLへネットワーク経由で接続

MySQLへネットワーク経由で直接許可するなんてあんまりしない気がするけど。
ローカルマシンにMySQL WORKBENCH を使って接続して、GUIでテーブルをいじるとか。
ローカルマシンのMySQLに別立てしたWEBサーバから接続するとか。
そういった利用方法が考えられなくも無い。

接続できない

MySQLが実行されているサーバにネットワーク経由で接続出来なかったので、
何でか調べていた。

他のMySQLサーバはSSHトンネルを張ってLocalhostとして接続すれば接続できた。

特定のサーバだけ外部から接続出来なかったので何でなんだろう、と。

よくよくmy.cnfを確認してみると

skip-networking

と書いてある。

skip-networking

調べてみるとこのオプションが指定されていると、ネットワーク経由での接続が出来なくなるようです。

SSHトンネルでLocalhostとして接続してもIPネットワーク経由の接続になっている。という事らしい。
このオプションが入ってるとUNIXソケットでしかアクセス出来ないって事なのかな。

一つ賢くなりました。

DRBDの再同期

覚書 Linux

crm_mon コマンドで確認できる failedcount という死活監視失敗した回数をリセットする必要がある。

crm resource failcount [リソース名] delete [ホスト名]

で消すことが出来る。

例

crm resource failcount res_drbd delete hogehoge.hoge

再同期のやり方

セカンダリ側

セカンダリ側で実行するコマンド

drbdadm down all
drbdadm attach all
drbdadm invalidate all
drbdadm connect all

プライマリ側

プライマリ側で実行するコマンド

状態確認

drbdadm role all

再接続

drbdadm connect all

これで直った。

再度状態を確認する。

cat /proc/drbd

プライマリ側：cs:SyncSource
セカンダリ側：cs:SyncTarget

drbdadm role all

プライマリ側：Primary/Secondary
セカンダリ側：Secondary/Primary

ここから同期が再開されるみたい。
今までの差分がどうとかいうのは分からないんだけど。
どうなんだろう？

もともとなんでunknown状態になっていたかも良く分かっていない。
(途中から引き継いだので･･･。)

DRBDの再同期やり方

覚書 Linux

DRBDでミラーリングしてるディスクを使ってメールサーバを作ろうとしている。

途中まで作ったサーバを渡されて、
いきなり同期が止まってる状態だったので、
止まった原因を調べていたけど、
ログがローテートで吹っ飛んでいてなんだか原因が分からない状態になっていた。

まっさらからやり直すとさらに時間がかかるし、どうにか直す方向で試行錯誤中。

Pacemaker の状態がよくなかったみたいなので、
直そうとするも直らない。
仕方なくサーバを再起動する。

セカンダリ側をシャットダウンして、
プライマリ側を再起動。
セカンダリが居ないよ！っていうエラーが出てる間に、
セカンダリを機動したらPacemakerによるクラスタリングは成功した模様。

これでOKかと思いきや、DRBDが同期していないことに気付く。

DRBDの状態を確認する

cat /proc/drbd

ここに cs:standalone って表示されてる時は、
プライマリ・セカンダリ間で上手く通信が出来ていない状態らしい。

drbdのノードの役割を確認する

調べて出てきた多くのサイトが drbdadm state all って書いてるんですが。
バージョンが古いみたい。
私の調べ方の問題かも知れないけど･･･。

drbdadm role all ていうのが最新版でのコマンドみたい。
drbdのバージョンは 8.4.2。

これで確認すると
プライマリ側： Primary/Unknown
セカンダリ側： Secondary/Unknown

ドメインの全レコードを取得するコマンド

覚書 まとめ 小ネタ サーバ Linux ネットワーク

権威DNSサーバに登録されている、ドメインのレコード全てを取得するコマンド。
もしくはそれに順ずる方法みたいなのってあるのかな、っていう疑問があり。
少し調べてみた。

結論から言うと存在する。

ただ、殆どの場合使えない。

コマンドは以下のようになっている。

Linuxの場合

dig @192.168.0.10 example.co.jp axfr

Windowsの場合

nslookup →対話モードに入る
>ls example.co.jp

何故殆ど使えないのか。

DNSサーバにはゾーン情報をセカンダリDNSサーバへ転送する機能 AXFRがあります。
これを使ってプライマリDNSサーバはセカンダリDNSサーバにゾーン情報を転送します。

本来、これらのコマンドはAXFRを使ってゾーン情報を転送できるかどうか、確認するための物です。

したがってプライマリがセカンダリDNSサーバのみ、転送先として許可していなかった場合。
このコマンドを使ってもAXFRのリクエストがDNSサーバに拒否されてしまいます。

DNSSECだったら･･･

DNSSECでは問い合わせを受けたホスト名が存在しないという回答が用意されており、
それを権威DNSサーバが返すことでキャッシュサーバに存在しないレコードとしてキャッシュし、
上位DNSサーバに問い合わせないようにする事が出来るようになっています。

その不在証明の方法が２種類あるのですが、
そのうちのNSECという手法で不在証明をしていた場合。

存在しないレコードの名前の次のレコードを答えてくれるという機能になっているので、
これを繰り返せば全てのレコード内容が容易に取得できるかも。

普通は想定できる単語やらなにやらで 総当りして、
存在するレコードと存在しないレコードを調べなくてはならないが、
これは存在するレコードを返してくれるわけなので。

で、これが問題になって今はNSEC3という手法もある。
これは次のレコードを答えない手法。

まとめ

ドメインの全レコードなんて自由に取得されていたら、
ホストの存在がバレバレになって攻撃対象になりまくってしまうと思うので、
named.conf のACLは気をつけて設定しないといけませんね。

追記(2012/11/05)

DNSSECの場合、DNSSEC Walkerというツールを使うと、
ゾーン全てのレコードを取得できる。