小ネタ

dmmではすべてのサーバでwol対応のnicを利用するようにしています。

ただ、みなさんがお使いのように他のコンピューターから起動するために利用しているわけではありません。

電源が入ってない状態もしくはOSが起動していない状態でもポートのlinkをUPさせるためにWOLを利用するようにしています。

なぜかというと

ケーブリングするエンジニアと実際に導通を確認するエンジニアが別だからです。

LinuxではWOLに対応していないNICだとIP設定まで行わないとリンクがアップしませんが、

WOL対応NICを利用すればケーブリングするエンジニアが目的のスイッチとの接続性をリンクの状態だけで確認できるようになります。

意識してないとうっかり未対応のNICを選択してしまう場合があるのでいつも注意してサーバを購入しています。

雑談

6が出るまでは我慢して5sはいらないかなあと思っていたんですが

マジで便利っすね。iPhone5sの指紋認証

認識率も抜群でまったくストレスがありません。

いつものように親指でホームボタンを押すだけで認識してくれ、
また、AppStoreでのアプリ購入も指紋認証で済ませることができるなんてさすがです。

dmm、facebookやtwitterへのログインで使えるようになるといいなあ。

ところで、素朴な疑問なんですが、

認証のための指紋データはappleがサーバで管理しているのでしょうか?

それとも、

個人のiPhone内で管理されているのでしょうか?

盗まれても人間の指紋はクレジットカードのように再発行できませんので、
さすがにデータを盗まれることを前提に考えると中央サーバーで管理はせずiPhone内で保管してると思ってはいるのですが。

それにしても

昔の指をずらすタイプの指紋認証は認識率が酷くて指紋がちゃんと登録できたのかどうかもわからず使えないなあと思っていたんですが、
appleの指紋認証はほんとにシンプルで使いやすく一気に普及しそうな予感がします。この技術は称賛に値すると思います。

ただ、

iphoneに限らず携帯ってよく触るので画面や底面に思いっきり指紋がついているかと思います。
これを使って簡単にログインできちゃうようなキットが売り出されると困っちゃいそうではあります。

DNS, linux

私もよく混乱するのですが、

dnsの問い合わせで遅延が発生するパターンは二つあります。

1.resolv.conf上位のDNSキャッシュサーバがホストダウン中に
2番手のネームサーバへの切り替えるため遅延が発生する。
デフォルト設定では5秒待ってから次のサーバを試す。

2.RHEL6系からAとAAAAレコードが同じソケットでの問い合わせを行うため
対応していないfirewallやブロードバンドルータ配下のホストでは遅延が発生する。
AとAAAAレコードの二つのレコード結果の両方が揃うまで待ち続けるため、
その待ちがタイムアウトするまで5秒遅延が発生する。

どちらも5秒待つことになるので同じ問題なんだと考え深みにはまる。

1については「DNSキャッシュサーバのメンテナンスや障害時の影響と対策」でお話ししましたが、ここでは2について触れます。

2の場合でも混乱ポイントがあって、同じバージョンであっても問題がでる場合とでない場合があるということを留意しておく必要がありますのでご注意ください。

我々の環境ではバックボーン環境やサーバで構築しているNATサーバ、firewallや負荷分散装置配下のRHEL6系のホストでは遅延は発生していません。

一方でオフィスのBフレッツ回線配下に設置するRHEL6系のOSはことごとく遅延してしまいます。

裏は取れていないのですが、上流のブロードバンドルータが同一ソケットでの問い合わせに対応できずパケットを落としてしまうため問題が発生していると推測しています。

ということで、上記を踏まえつつ今件をどのように対応するかについてなんですが、

3つの方法が考えられます。

■ひとつめ

A、AAAAレコードを同一ソケットで問い合わせが出来る機器で構成する。

■ふたつめ

みなさんご存じのresolv.confでの設定

もしくは

で対応していくことになるかと思います。

このオプション使用前と後でのtcpdumpで改善したかどうか確認してみましょう。

■オプション使用前

AとAAAAレコードが同じソケット(35504)で問い合わせを行い
Aレコードは返答が来ているがAAAAレコードを待っているため5秒待っているのが分かる。

■オプション使用後

こちらは別ソケット(Aレコードは48690、AAAAレコードは52755)で
順番に問い合わせしているので遅延は発生していないのがわかる。

■みっつめ

OS側でipv6をdisableとすると改善します。

上記のいずれかの対応を自身の環境に合わせて適用していけばよさそうです。

それにしても、ほんと混乱します。

システムコールやコマンドごとに挙動が違うことも問題を複雑化させているように思います。

traceroute、curlは遅延しますし、

ping、digやnslookupなどは遅延しません。

例えばpingで確認してしまうと直ったと勘違いしてしまうことになります。^^;

とりあえずは、標準化の策定の中でsingle-requestを入れておくというのが正解なんだと思います。

最後に小ネタをひとつ

curlコマンドはオプションで[-4]を利用すると遅延が改善します。

DNS, linux

DNSキャッシュサーバのメンテナンスや障害時の影響と対策

みなさん、サーバ構築する際/etc/resolv.confでnameserverの設定をされているかと思います。

ここに指定しているDNSキャッシュサーバで障害が発生しホストダウンとなると
resolv.confで設定した次のネームサーバへ問い合わせるまである一定の時間待たされ影響が出ることがあります。

標準のタイムアウト値は5秒なんですが復旧するまでの名前解決はそれぞれずっと5秒間遅延することになりますのでdmmでは意外と影響が大きくなります。

IPは生きていてdnsサービス自体が落ちている場合はすぐに次のDNSキャッシュサーバに切り替わるのですが、
IPの接続性がなくなるホストダウンとなるとタイムアウト値まで待たされることになりますので注意が必要です。

存在しないIPアドレス:10.255.255.255
存在するがDNSサーバではない:10.163.0.226
動作中のローカルDNSキャッシュ:127.0.0.1

の組み合わせでテストしてみました。結果は下記です。

■5秒待たされる場合のstrace結果

10.255.255.255を試し、タイムアウト(5秒)まで待たされて127.0.0.1へ問い合わせしているのがわかります。

 

■すぐに切り替わる場合のstrace結果

10.163.0.226を試してすぐにPOLLERRとなりすぐに127.0.0.1へ問い合わせしているのがわかります。

ということでこれらの影響を最小限とするため下記のような対策が必要になってくると思っています。

1.タイムアウト値を調整し障害発生時でも影響を最小限に

resolv.confでのタイムアウト値を規定の5秒から1秒へ変更
options timeout:1

2.そもそもDNSキャッシュサーバを落とさない構成

lvs配下にDNSキャッシュサーバを2台以上配置。
その構成を2セット用意してそもそも落とさない
3.各サーバでdnsmasqやunboundを導入し切り替え時間を高速化する。

resolv.confに
nameserver 127.0.0.1

として
一番上にローカルにインストールされたDNSキャッシュサーバを指定しておく。

※ローカルのIPは落ちることがないのでローカルにインストールされた
DNSキャッシュが停止したとしてもすぐに切り替わる。
4.hostsを利用しそもそもDNSキャッシュサーバに頼らない。

分かり切った相手先への通信を行うサーバについてはhostsを利用し、
そもそもDNSキャッシュサーバを利用しない。
5.DNSキャッシュアプライアンスを導入する。

6.外部のDNSキャッシュサービスを利用する。
上記6つの対策はどれも正解でそれぞれを適材適所で利用することになるんだと思います。

dmmでは

DNSキャッシュサーバを落とさない設計

プラス

各サーバのローカル環境にDNSキャッシュサーバをインストールし、さらに一部hostsも利用し低レイテンシーを実現する方向で対策を行います。

最近は各社さんとの連携のため多くの通信が発生し、その通信に低レイテンシーさが求められるようになってきているためhostsを使ったりunboundやdnsmasqなどのDNSキャッシュを利用する構成をとります。

みなさんはどのような対策を行っていますでしょうか?

コメントorツイートいただけると嬉しいです。

linux, 超解釈

cronとanacronとRHEL5系6系についてですが

結構、適当に設定し、
はまることが多々あったので自分なりに簡単に解釈してみましたのでお話しします。

anacronについては同じものではあるのですが
5系と6系で解釈を変えるとすんなりと頭に入り込んでくるようになると思います。

では、始めます。

RHEL5系

cron
特定のプログラムなどの処理を定期的に実行してくれるプログラム

anacron
サーバ停止中のためcronが実行できなかった場合にジョブを再実行させるためのcronのヘルパープログラム

定期ジョブは下記の二つのうちのいずれかで設定を行う。

■/etc/crontab
cron処理の実行スケジュールを設定する。

■/etc/cron.{hourly,daily,weekly,monthly}
スケジュールごとに指定のディレクトリでプログラムを登録する。
上記の設定だけで定期スケジュールとプログラムの設置が完了する

■/etc/cron.d
自分ではさわらない。

ヘルパーのanacronを利用したい場合はcron.dailyなどのディレクトリでプログラムを登録し、
/etc/init.d/anacronで定期的にstartしてあげる。
設定ファイルは/etc/anacrontabを読み込みます。
標準で/etc/cron.{daily,weekly,monthly}配下に登録されたプログラムがanacronで動作していなかった場合に再実行してくれます。

RHEL6系

cron
特定のプログラムなどの処理を定期的に実行してくれるプログラム

anacron
仮想環境などのゲスト環境でcron処理が特定の時間に集中しないように定期ジョブをうまいこと分散してくれるプログラム
なので、サーバが稼働し続けていなくともRHELの5系の時のanacronのように、サーバが稼働した時点でジョブを実行してくれるようになります。

■/etc/crontab
確実にcronを指定時間に動かしたい場合はこちらを利用する。

■/etc/anacrontab
実行時間は変動するが確実にcronを実行させたい場合はこちらを利用する。

■/etc/cron.{daily,weekly,monthly}
こちらのディレクトリでプログラムを登録するとanacronのほうで実行されます。
※cron.hourlyを使いたい場合はanacrontabで設定を忘れずに

■/etc/cron.d
自分ではさわらない。

5系と同じようにcronを利用したい場合はcronie-nonanacronをインストールしてcronie-anacronをremoveするといいみたい。

p.s.
タイトルは「部屋とYシャツと私」を字余りで歌いながら書き込んでました^^;

PAGE TOP