これだけは知っておきたい サーバの常識

本日「これだけは知っておきたい サーバの常識」という本を技術評論社から出版させていただきました。著者は小島太郎さん、佐藤尚孝さん、そして私(監修)です。

この本には以下の特徴があります。

・サーバの全体像を理解することができる入門書です。（専門学校の授業教材などにいかがでしょうか）
・電車の中でも読み進められるように、やさしい文体で書いています。（堅苦しすぎると寝ちゃいますので）
・でも必要なことは端折らずに詰め込んでいます。（エニーキャスト方式とか、ローエンドサーバとハイエンドサーバの違いとか・・・）

よくある入門書だと、ただサーバの機能や用語がずらずらと書かれているだけで、一通り読んでもサーバの全体像がイメージできないということがよくあります。サーバの機能や用語を調べるだけだったらネットで検索すれば十分です。

そんなこともあり、この本ではサーバの全体像を理解してもらいながら、結果的に今自分は何を知っていて何を知らないのかを自分自身で発見してもらえるように構成しました。この本を読んだ後別の本でさらに勉強を進めていき、壁にぶちあたったらまたこの本に戻って確認する、という使い方でしょうか。

この本で込めたかったメッセージは2つあります。

1つ目は、「ハイエンドサーバってこんなにすごい。ハイエンドサーバで使われた機能や仕組みがどんどんミドルエンドサーバやローエンドサーバに技術移転されてきている。なので将来のサーバ像を知りたければ今のハイエンドサーバを見ればいい」ということです。今Windows7などで「64bitだからメモリをたくさん使えたり、仮想化が使えたりするのですごい」と叫ばれていますが、ハイエンドサーバではそんなの数十年前から普通に実現されていました。

2つ目は、このblogで繰り返し述べているように、ローエンドサーバであってもハイエンドサーバであっても、要はCPU、メモリ、ディスクI/O、そしてネットワークという要素で構成されているということです。普段なかなかハイエンドサーバを見る機会はないかと思いますが、このことさえ押さえておけばどうってことはないということです。

是非店頭でご覧いただけたらと思います。よろしくお願い致します。

※追記
技術評論社金田さん、著者の小島さん、佐藤さん。この半年本当にお疲れ様でした！

「生きてる」自宅サーバー運用

7月にThinkITさんで自宅サーバー関連の連載を持たせてもらいましたのでご紹介させていただきます。

第1回：自宅サーバーを立てるメリットとデメリット 
第2回：自宅サーバーを作ってみよう 
第3回：自宅サーバーを粋に使いこなそう 

※余談
ThinkITはシンクアイティーではなくてシンクイットと読むとのこと。お間違いなく。^^

Windowsサーバをインストールする際は自動更新に気をつけよう

Windowsサーバのインストールに慣れていない初心者の多くが一度は経験する設定ミスがあります。それは「セキュリティパッチの自動更新を有効」にしてしまうというものです。

セキュリティパッチを自動更新する設定は何故いけないのか。もちろん事前検証なしにいきなり本番系サーバにセキュリティパッチを適用するのは怖いというのもあるのですが、それよりもっと怖いのはパッチによっては適用後に勝手にOS再起動までされてしまうことです。本番系サーバが突然OS再起動されてしまう問題の大きさはあえて語るまでもないですね。

この設定ミスが厄介なのは、

1. OSインストール中に通知領域に自動更新を即すアラートが頻繁に出てくるので、つい何も考えないで設定を有効にしてしまう可能性があること。
   
2. もし毎日OS再起動されてしまうのであればこの問題まで特定されすいが、実際は数ヶ月に1回程度なので忘れた頃にやって来ること。
   
3. 数ヶ月に1回程度しか再発しないため、その場で問題究明まで至らなかった場合放置される可能性が高いこと。
   

気をつけましょうね。

Linuxが入らないサーバに無理やりLinuxをインストールする方法

今回はLinuxが入らない(というかLinux用ドライバー、特にRAIDコントローラーが用意されていない）サーバに無理やりLinuxを入れる方法を思いつきましたのでご紹介します。

私は趣味がサーバなもので、たまにヤフオクなどで昔のサーバを購入してはCentOSなどをインストールするんですが、最近購入した東芝Magnia Z310でCentOS5をインストールしようとするとブート途中でフリーズしてしまいました。おそらくRAIDコントローラー用ドライバーがないからだと思い探してみたんですが、どうしてもそれが手に入りませんでした。

ドライバーがなければCentOS5の利用は無理かな、と思った瞬間一つのアイデアを思いつきました。それは仮想化技術の利用です。仮想化すればドライバ部分は仮想化エンジンが吸収してくれますしね。ということで早速Windows2000をインストール後、そこにVMWare Serverを入れ、その上でCentOS5をインストールしてみたら難なく動きました。

普通は新しいサーバに古いOSを入れるわけなんですが、今回は逆に古いサーバに新しいOSを入れるというところが新しいです。(-_☆)キラーン

無論「そこまでやって何の意味があるの？」というご指摘はありそうですが、サーバ負荷が低い中小企業の社内サーバ用途ならむしろアリだと思ってます。その方法を使うと1台のサーバ上でWindows Serverとしての利用に加えてLinux Serverとしての利用もできるようになるわけで、これはこれでむしろ便利かなと思いました。

サーバをシャットダウンする作法(UNIX系OS編)

サーバのシャットダウンの仕方で、その人がどの程度の力量を持っているかなんとなくわかってしまいます。それくらいサーバのシャットダウンは奥深いです。そこで今回はサーバをシャットダウンする作法について考えてみたいと思います。

【初級：いきなりシャットダウンしてしまう】
サーバ管理初心者がサーバをシャットダウンするシーンを見ていると、rootでログインしたかと思ったらいきなりshutdownと打ち始めました。個人PCならまだしも、サーバでそれをやるのは危険ですよね。誰かそのサーバ上で作業しているかもしれないし。

【中級：上がっているサービス・プロセス・TCPコネクションなどを確認してシャットダウン】
サーバ管理中級者になると、サーバをシャットダウンする際は、まずはTCPコネクションがないかなどを確認してから、立ち上がっているサービスやプロセスを全て落とし、その後シャットダウンします。慣れているのですごい勢いでタイピングしてシャットダウンするのが中級者の特徴です。

【上級：とにかく慎重にシャットダウン】
サーバ管理上級者ともなると、とにかく慎重です。一行タイピングする毎に入力した内容を何度かチェックして間違いないことを確認してからEnterキーを押す。そしてsync、sync、syncと3回くらいタイピングし、その後最後に作業漏れがないか数秒考え、それでも問題ないと確信したらシャットダウンを行います。上級者のシャットダウンはとにもかくにも慎重なのが特徴です。

【サーバをシャットダウンする作法】
サーバというのはその名の通り、サービスを行う機械です。その機械を止めるという行為はサービスを止める行為に他ならないので、正しい手順で慎重かつ確実にサービスを停止していくのがサーバをシャットダウンする際の作法になります。

なお参考になるかわかりませんが、私がサーバをシャットダウンする直前に手癖的に打ってしまうコマンド群をご紹介します(下記全てのコマンドを打つ必要はないのですが、慎重かつ確実のためにあえて)。ちなみに同じUNIX系OSでもOSによって多少コマンドやオプションが異なりますのでご注意ください。

# ps -ef|more
# netstat -an|more
# w
# free

※追記(2008/5/20)
sync3回ってネタだよね、という狙い通りのご指摘ありがとうございました。正確には調べてませんがたしかに最近のUNIX系OSはsyncしなくてもよいと聞いたことがあります。よって「sync3回叩く人は古い人だ」という注意書きを入れるか迷ったのですが、ひょっとしたらUNIX系OSの中には未だにsyncが必要なものがあるかもしれないのであえて残しておきました。

English verisonのOSでシステムを構成しよう

これまで非常にいろいろなシステムを構築してきましたが、最近よく思うのは、OSを安定的に動かすにはEnglish versionが一番であるということです。

これにはいろいろな意味があります。

　(1) OSはまずEnglish versionで作られ、その後Japanese versionを作るので、その過程で不具合が紛れ込む可能性がある

　(2) Japaneseに比べてEnglishのほうが余計なものが入っていない分シンプルで軽い

　(3) ネット上には英語で書かれたドキュメントやノウハウが日本語で書かれたそれに比べて圧倒的に多い。

　(4) グローバル企業の場合、どの国の担当者も理解できる。

私はUNIX系OS(Linux,Solaris,FreeBSDなど)は昔からEnglish versionを使ってましたが、最近はWindows Serverもかなり安定してきたことからEnglish versionを使うようになりました。

・・・と書くといろいろ反論がきそうですので、予想される反論には先に答えてみます。

・日本のベンダーに頼むのであればJapaneseであることは必須となるのでは？
　　→はい。ただしその場合は品質をベンダーが保証してくれるので大きな問題にはならなそうです。

・いくら英語のドキュメントやノウハウが多くても読めなければ意味がないのでは？
　　→はい、ある程度の英語力は前提です。ただ、英語がとても苦手な私でも役に立つ情報が多いと感じるので積極的に活用したほうがよさそうです。

・アプリケーションがEnglish OSに対応してなければ意味がないのでは？
　　→はい、その通りですね。ただ最近はOSもマルチランゲージ化が進んだので、OSがEnglishだからといってアプリケーションまで動かない事例は昔と比べたらかなり減りました。

PS: IT資産管理ツールですが、最近急に本業が忙しくなって完全に止まってます。落ち着いたらまた進めますので少々お待ちください。m(._.)m

VISTA BusinessからXP Professionalにダウングレードしたときの記録

先日Toshiba Dynabook SS RX1というノートPCを中古で購入しました。薄型軽量高スペックという良いとこ取りでハードウェア的に大満足な反面、唯一の不満はVistaであること。しかしよく調べてみるとVista Business以上であればXP Professional(HomeはNG)へのダウングレード権がついているとのことで、早速その権利を行使してみました。今回はそのときの記録を記してみます。

【1. XP Proのメディアを探す】
ダウングレード権を行使するためには、まずXP Proのメディアがなければなりません。公式ページを見ると「使用するCD-ROM はダウングレードするPC の所有者が所持している必要があります」とのことなので、自宅になければ買ってこなければならず本末転倒です。幸いなことに自宅には以前購入したDELLのPCについていたOEM版のXP Proのメディアがありました。

OEM版のWindowsメディアは他のメーカーのPCには入らないとよく聞きます。結果的には無事インストールできましたし、今回の場合ライセンス的にも特に問題ないとのことです。事実新しいHDDに入れ替えてインストールしてみたらあっさり入りました。

あ、注意点があります。もしBIOSでAHCIモードが選択されているとインストール途中でブルー画面が出てとまります。多分XPには標準でAHCIモード用ドライバが入ってないからでしょう。この場合IDE互換のStandard IDEモードにしておきましょう。

【2. アクティベーション】
インストールが完了したら今度はアクティベーションです。今回の場合他社用OEM版メディアとのことでインターネット経由でのアクティベーションが当然できなかったので、電話でのアクティベーションを実施しました。まず音声案内に従って多分毎回ランダムで生成されるインターネットIDと呼ばれる数十桁の番号をプッシュ入力します（とてもしんどい）。すると今回の場合他社用OEM版だからかNGと言われ、オペレーターにつなぐか聞かれたのではいと(実際には1と)入力しました。

オペレーターが出たので「ダウングレード権を行使してVista Businessが入っていたノートPCからXP Professionalに入れ替える」旨を伝えました。それ自体は問題なかったですが、私が使ったメディアはプロダクトキーの入力が必要ないものだったため確認IDを発行できないとのこと。ただアクティベーションの画面の中に「プロダクトキーの変更」というボタンがありそこからプロダクトキーを入れればOKでした。

【3. Windows Vistaを仮想化して利用】
XPにしたものの、Vistaも使うかもしれません。そんなときのために元々のVistaをディスクイメージ化しておくと後で仮想化して使うことができます。・・・と思ったけどこれはライセンス違反なので駄目ですね。＞＜

【参考】
http://www.microsoft.com/japan/windows/products/windowsvista/buyorupgrade/downgrade/default.mspx

PS: IT資産管理ツールの公式ページを作りました。URLは・・・前回のエントリーのどこかに書いておきましたので、どうしても見てみたい人は探してみてください。ただバグがあるのでまだ実用性はないです。あくまでも参考ということでさりげなく公開しました(苦笑)。

社内でのリモートデスクトップの便利な使い方

社内のPCがもしWindows XP Professionalなど企業向けWindowsライセンスで統一されている場合、リモートデスクトップを便利に活用できますのでご紹介します。

【1.会議室から自分のPCに接続】
会議室で自分の作った資料をプレゼンすることになったとします。通常であればノートPCにデータを移して見せるとか、会議室に設置してあるPCにUSBメモリー経由などの方法でデータを移して見せるなどといったことが必要になります。しかしもしリモートデスクトップを使える環境であれば、会議室PCから自分のPCにリモートデスクトップ接続して、自分のPC上に用意しておいたファイルをそのまま見せることが可能になります。

この方法は、会議直前までプレゼン資料を作りこみ、時間になったのであわてて会議室に飛び込みすぐにその資料を見せる、などといった利用が想定されます。

【2.他の従業員へのヘルプデスクサポート】
ヘルプデスク要員が他の従業員PCのIPとID/PWDを知っていれば、問い合わせに対して直接PCにデスクトップ接続してサポートすることが可能となります。ITスキルが高くない従業員が多い環境では非常に有効でしょう。

【番外編】
以前ご紹介しましたが、リモートデスクトップといえばリモートデスクトップ接続でコンソールのセッションをコントロールする方法なんてものもあります。

割と便利な帯域制限方法(Linux編)

※帯域制御ではありません。帯域制限ですのでご注意を。

帯域制御をしようと思うとそこそこ面倒くさい(もしくはお金がかかる)ですが、大雑把でよければ簡単に帯域制限できる方法があるのでご紹介します。それはインタフェース的に制限をかけてしまうという方法です。

例えば1000baseTのNICを使っていたら、そのNICはおそらく10baseT(Half/Full)、100baseT(Half/Full)、1000baseT(Full)の5種類のモードに対応していると思われます。そのNICに対して思いっきり帯域を絞りたいのであれば10baseT(Half)に設定すると10Mbps以上の帯域が使われることがなくなるといった感じです。

【設定方法】
さて、設定方法ですが、例えば10baseT(Half)に設定しようとした場合、まずはお使いのNICが10baseT(Half)に対応しているか確認します。
# ethtool eth0 Settings for eth0:         Supported ports: [ TP MII ]         Supported link modes:   10baseT/Half 10baseT/Full                                 100baseT/Half 100baseT/Full         Supports auto-negotiation: Yes         Advertised link modes:  10baseT/Half 10baseT/Full                                 100baseT/Half 100baseT/Full         Advertised auto-negotiation: Yes         Speed: 100Mb/s         Duplex: Full         Port: MII         PHYAD: 1         Transceiver: internal         Auto-negotiation: on         Supports Wake-on: g         Wake-on: g         Current message level: 0x00000007 (7)         Link detected: yes

対応しているようであれば
# ethtool -s eth0 speed 10 # ethtool -s eth0 duplex half # ethtool -s eth0 autoneg off

とすれば10baseT(Half)として認識されるようになります。

Linuxでそこそこ安全かつ楽にサーバを立てる方法

【1.初めに】
要望がありましたので、今回はLinux（実際はRedhat系Linux）でそこそこ安全かつ楽にサーバを立てる際の手順を記してみます。

※一応注意：今回は、試しにサーバを立てる程度であればこのくらいで十分ではないかと思うレベルを想定しています。サービスに投入するサーバでは私はもっと細かいところまで手を入れています。

【2.そこそこ安全かつ楽にサーバを立てる手順】
さて、いよいよ本題です。サーバを立てる際は、不必要なものを全て取り除いてから必要なものを追加していくというのが基本になります。以下の手順1～5では不要なものの除去、手順6～7で必要なものを追加し確認しています。それを踏まえまして。

■手順1. OSをインストールします。(私はLinuxであればCentOSを入れることが多いです。その際私はインストールの種類をカスタムにしパッケージグループの選択では開発ツール以外全部チェックを外すことが多いです）

■手順2. OSにrootでログインしたら、「yum update」で全てのパッケージをupdateします。

■手順3. 「chkconfig --list」で各サービスのrunlevelを確認し、不要なサービスを例えば「chkconfig gpm off」の要領で止めていきます。ちなみに私の場合だと以下のサービスだけ残してあとは全て止めてしまっています。

・syslog
・network
・iptables
・anacron
・smartd
・sshd
・crond
・xinetd
・ntpd

■手順4. 「netstat -ln」（もしくは「netstat -l」）で現在開いているポート番号を確認し、不要なネットワークサービスを止めていきます。

# netstat -ln Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address               Foreign Address             State<br /> tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN<br /> tcp        0      0 0.0.0.0:21                  0.0.0.0:*                   LISTEN<br /> tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN<br /> tcp        0      0 0.0.0.0:631                 0.0.0.0:*                   LISTEN<br /> udp        0      0 0.0.0.0:111                 0.0.0.0:* udp        0      0 0.0.0.0:631                 0.0.0.0:*

ただnetstat -lnだけだとどのプログラムからポート番号を開けているのかわからないので、それを確認するために「lsof -i」を実行します。

# lsof -i COMMAND     PID   USER   FD   TYPE   DEVICE SIZE NODE NAME portmap    2128    rpc    3u  IPv4     4905       UDP *:sunrpc portmap    2128    rpc    4u  IPv4     4908       TCP *:sunrpc (LISTEN) sshd       3080   root    3u  IPv4 31179186       TCP *:ssh (LISTEN) cupsd     21437   root    0u  IPv4 32988846       TCP *:ipp (LISTEN) cupsd     21437   root    2u  IPv4 32988847       UDP *:ipp vsftpd    28195   root    3u  IPv4  7339417       TCP *:ftp (LISTEN)

ここで例えばcupsd(631番ポート)が不要だと思えば「chkconfig cupsd off」で、vsftpd(21番ポート)が不要だと思えば「chkconfig vsftpd off」でそれを止めればいいわけです。

■手順5. リブートします。リブートが完了したら、試しに「netstat -an」や「ps -ef」を実行してみてください。最初と比べて不要なものがほとんどなくなりとてもすっきり感じるはずです。

■手順6. 必要なサービスを追加します。例えばhttpdであれば「yum install httpd」といった感じです。もちろん言うまでもなくソースコードを入手してコンパイルしてインストールする方法もあります。

■手順7. 最終確認です。「dmesg」「more /var/log/messages」「more /var/log/secure」「ps -ef」「netstat -an」などの出力結果を一通り眺めてみて特に変なところがなければ終わりです。もし少しでも変だと感じる点があったら是非徹底的に調べてみましょう。

さて、こうして構築されたサーバですが、最後に気をつけたいことが1つあります。それはポートを開いているプログラムにセキュリティホールがないかどうかです。例えば現在TCP22番ポートはopensshが、TCP80番ポートはapache2が開けているとします。外部からアクセスできるこの2つのポートにセキュリティホールがあったら問題なので、セキュリティホールのないバージョン（原則最新バージョン）であることを常に意識することが重要になります。

【3.最後に】
今回ご要望をいただいた方曰く「OSのインストール自体は何度もやったことがあるけど、サーバを立てるとなるといまいちどうやっていいかわからない」とのことです。この件繰り返しになりますが、サーバを立てる際は不必要なものを全て取り除いてから必要なものを追加していくというのが基本になります。その基本を踏まえて今回具体的な手順を記してみました。参考になりましたら幸いです。

アプリケーションをインストールする方法の比較

※一番下に補足を加えました。(2007/5/13)

昔（WEBが登場する10年ほど前くらいまで）はUNIXシステムにアプリケーションをインストールする際はソースコードを持ってきてコンパイルするのが当たり前でしたが、現在は主要アプリケーションがパッケージ化されインストールが非常に簡単になりました。しかし、にも関らずプロのシステム管理の現場では未だに相変わらずアプリケーションをコンパイルして導入することが多いです。そこで今回はアプリケーションのインストール方法の比較をしてみたいと思います。

【yumやrpmなどでインストール】
Redhat系のLinuxでは他の人が作ってくれたパッケージを使ってアプリケーションをインストールすることができます。これらを利用してインストールするメリットは導入、アップデート、アンインストールが簡単ということに尽きます。例えば

# yum install httpd
# yum update httpd
# yum remove httpd

というような感じでアプリケーションを簡単に扱うことができます。

（ちなみにSolarisであればCompanion CDからのインストールになりますね）

【コンパイルしてインストール】
一方コンパイルしてインストールする場合は結構大変です。ソース配布元からソースコードをダウンロードしてきてインストールします。昔はアプリケーション毎にインストール方法が異なっていたのでREADMEファイルをしっかり読み込まないとコンパイルすらうまくいかなかったですが、最近では大抵の場合はconfigureしてmakeしてmake installするとインストールできるようになったので結構楽になりました。

コンパイルしてインストールする場合に大変なことはいろいろあります。まずは依存関係のあるライブラリがある場合です。単体で動かないアプリケーション、例えばphpなどがいい例ですが、最新版のphpをコンパイルしようとすると場合によっては依存関係のあるライブラリが足りないだとかバージョンが古いので最新バージョンを入れろだとかでコンパイルがストップします。この作業は非常に面倒くさいです。次にアップデートやアンインストールをする場合です。アップデートの場合は上書きで対応すると危険なので最新バージョンを別にコンパイルしておいて後で入れ替えたりします。アンインストールの場合はmake cleanした後残された設定ファイルを手動で消したりしていきます。

【プロが未だにコンパイルしてインストールする理由】
yumなどを使うと非常に簡単であることがおわかりいただけたかと思いますが、それでもプロが未だにコンパイルしてインストールする理由がいくつかあります。

まずは最新バージョンを使いたいからです。最新版のアプリケーションがrpm化されるまでには結構時間がかかる場合があります。特にセキュリティ案件だとそういったものがrpm化されるまで待っていられない場合もあるので、自分でコンパイルしてインストールしたほうが結果的には楽というのがあります。LAMP環境であればApache、MySQL、PHPだけはこうしてコンパイルして使う場合が多いです。

それから依存関係のあるライブラリのバージョンを管理したいからです。rpmの場合、誰かが一番最後にパッケージ化したときのバージョンがそのrpmの最新バージョンとなるため、必ずしもアプリケーション全てが最新バージョンのrpmが提供されているわけではありません。そういうのは管理がとても難しいので依存関係のあるライブラリも結局は自分でコンパイルしてインストールしたほうがバージョン管理ができて楽なのです。

が、当然のことながらこういった対応の仕方はシステム管理者にとってかなりの負担で、特に大規模サイトにもなるとサーバ台数がものすごく多いので現実的でなくなってきます。いわば職人技的なこういった仕事ぶりを近代的にしていくことがこれからのシステム管理には必要なことだと強く思います。

※補足(2007/5/13)
このエントリーに対して数名の方から「いや、プロであればむしろ自分でrpm作るのが普通ではないか？」という意見をいただきましたのでこの件補足します。

まず「yumやrpmなどを使ってアプリケーションをインストールする」という意味は誰かがrpm化してくれるのを待ってインストールするという意味で用いました。その意味では「自分でrpm化する」というのは「自分でコンパイルする」という範囲に（このエントリーの趣旨としては）含まれています。

あと「プロが」と一般化しましたがこれは「私が」としたほうが良かったかもです。何故私が自らrpmなどのパッケージを作らなかったかについてですが、
　　1.管理していたOSが多岐に渡っていたこと(&Linuxの比率が低かった)
　　2.サービスによって利用するアプリケーションを変える必要があった
というのがその理由です。昔のことなのでうろ覚えですが、たしか30種類くらいのパターンがあった記憶があります。そんなに種類があるものをいちいちパッケージ化していられないという事情があり、当時はパターン毎にインストールメモを作る程度で済ませていました。

コマンドリファレンス集

システム管理者にとってコマンドリファレンスは重要な商売道具の一つです。私がよく利用するコマンドリファレンスをご紹介します。印刷して持っておくと便利ですよ。データセンターなどに常備しておくのもお勧めです。

■Linuxコマンド集
http://itpro.nikkeibp.co.jp/article/COLUMN/20060224/230573/

■Linuxコマンド逆引き大全
http://itpro.nikkeibp.co.jp/article/COLUMN/20060224/230579/

■Windowsコマンド集
http://itpro.nikkeibp.co.jp/free/NT/WinKeyWord/20040805/1/

■UNIXコマンドリファレンス
http://www5.plala.or.jp/vaio0630/ftp/command.htm

■Emacs簡易コマンドリファレンス
http://park15.wakwak.com/~unixlife/emacs.html

■Vi機能別主要コマンドリファレンス
http://www.glasscom.com/tone/linux/Reference/Vi/ViReference1.htm

■awk reference manual
http://www.forest.shimane-u.ac.jp/nagayama/etc/awk.html

安価なサーバの登場に喜んではいけない

最近主要ベンダーから安価なサーバが発売されることが増えてきました。3万円を切るサーバなんてものもあるらしいですね。しかしこういう安価なサーバの登場に素直に喜んではいけないと思っています。そこで今回は何故安価なサーバの登場に喜んではいけないのか記してみたいと思います。

【同じ安いにも2種類ある】
同じ安いにも2種類あります。1つは技術革新や効率化によって業界全体の価格が下がるパターン。もう1つは戦略的な価格を実現するために無理やり価格を下げるパターンです。もし安価なサーバが前者の理由によって実現されたものであるならば喜ばしいのですが、最近発売されている安価なサーバは実際はどうも後者なようです。

【安さを実現できる理由】
戦略的な価格を実現するために無理やり価格を下げている場合、どうやってその安さを実現するのか観察してみました。

一番目は利益度外視です。3万円のサーバを1台売ったところで利益なんてたかがしれてます。

二番目は大量販売によるコストダウンです。安ければたくさん売れ、結果安く製造することが可能なのかもしれません。

そして三番目は安いパーツの利用です。通常サーバは24時間365日連続稼動させるものなのでそれなりの品質のパーツを使いますが、予想通り安価なサーバはPCで使われるパーツとそう大差がないように見えます。例えばメモリはエラー補正のないメモリを使う、HDDは24時間365日連続稼動を前提に設計されたSAS/SCSIを使わずSATAを使う、DVD-ROMではなくCD-ROMを使う、RAIDボードが付いていない等々、サーバとしてあって当然のパーツが使われていません。これではPCと何ら変わりません。

【終わりに】
安価なサーバは言わばワケアリ製品なので絶対に買ってはいけません。普通のサーバを使いましょう。

bin配下のディレクトリを探索してみよう

私がUNIXを勉強し始めたのは大学生時代。当時のUNIXはとても高価。またLinuxやFreeBSDなどのフリーのOSは存在するにはしていましたが、今のように入門書と呼べるような書籍がほとんど存在しない時代で、UNIXを勉強するにはなかなか敷居が高い時代でした。

その当時UNIX管理者に憧れていた私はいろいろな手段を使って勉強していたように記憶しています。図書館に行ってUNIX関連の書籍を読み漁ったり、UNIX管理を教えてくれそうな研究室を訪ねたりなどなど。そんな中、当時一番実践的で役に立ち、かつ面白かった勉強方法を思いつきました。それはbin配下のディレクトリを探索するというものです。

ご存知かもしれませんが、/binにはシステム寄りのコマンドが、/usr/binや/usr/local/binにはユーザが使うコマンドが慣習的に集められています。ということは、その中に格納されているファイルを手当たり次第manしていくと、（例：% man top、% man gzip、% man tcpdumpなど）いろいろなコマンドの使い方を知ることができます。これは当時は本当に面白かったなあ。

・・・そんなことを思い出したので、今日久しぶりにCentOSの/usr/binの中を見てみました。そうしたらznewコマンド(ファイルを .Z (compress) 形式から .gz (gzip) 形式に再圧縮する)や、yesコマンド(ひたすら'y'という出力を返す)などオモシロそうなコマンドを発見しました。時間があれば他にもいろいろ発見できたのですが、今日は時間がない（現実逃避^^;）なのでまた今度調べてみようと思います。

※補足
UNIXだけでなく、WindowsなんかもC:\Windows\配下やC:\Windows\System32配下の.exeファイルを見てみるといろいろ面白いです。

telnetを使ってメールを送信する

自分用のメモがてら記しておきます。

!!!警告!!!　もしこれをTipsとして使う場合は、きちんと周辺知識を固めてからにしてください。

【とりあえず送る場合】

% telnet mail.hogehoge.jp 25

MAIL FROM:＜sousinsya@hogehoge.jp＞
RCPT TO:＜jusinsya@hogehoge.jp＞
DATA
Subject: test
To: jusinsya@hogehoge.jp
From: sousinsya@hogehoge.jp
test test.
.
QUIT

システム管理者であればこのくらいは暗記しておきたいところです。(といいつつ私はたまに部分的に忘れます・・・)

【一応注意点】

1. 何はなくてもRFCが基本！
2. 不正リレー対策が施されていないサーバで実行すると・・・。
3. 誤ったメール系処理を被害は甚大。他の人に迷惑をかけないよう十分注意しましょう。

ファイルサーバの導入に失敗しない方法

今月分の@IT連載記事が掲載されました。タイトルは「ファイルサーバの導入に失敗しない方法」です。

http://www.atmarkit.co.jp/im/cop/serial/kanrisha/06/01.html

LinuxでLVMのデータを抜き出す方法

keyword: Linux,LVM,HDD,抜き出し

最近久しぶりにLinux(CentOS)をインストールする機会がありまして、いつの間にかLinuxにもLVM(論理ボリュームマネージャ)という概念が導入されていることを知りました。LVMを使うとソフトウェアRAIDが組めたりパーティションのサイズを変えられたりできるので便利といえば便利です。が、最近ちょっとした事件がありました。オペミスでOSが死亡してしまい、データだけでも救出しようとしたときの話しです。旧来の方法であれば、別HDDにLinuxを入れて、OSが死亡したHDDのデータ用パーティションをmountすれば簡単にデータが抽出できたのですが、LVMだとちょっと面倒くさいです。そこで今回はLinuxでLVMのデータを抜き出す方法をまとめてみました。(今回は多分一部ケアレスミスが含まれていると思います。その場合ご指摘いただけたら幸いです)

【LVMについて】
これからやろうとする作業がちんぷんかんぷんにならないためにも、まずはLVMが何かを知っておいたほうがよいです。とは言えここをご覧になっている方の多くは緊急事態なときでしょうから簡単に触れておきます。

まずLVMには3つの構成要素、PV(PhysicalVolume),VG(Volume Group),LV(Logical Volume)があるのを押さえましょう。意味は読んで字のごとくです。scanしてみるとこんな感じです。

# pvscan
PV /dev/sda2 VG VolGroup00 lvm2 [279.34 GB / 32.00 MB free]
Total: 1 [279.34 GB] / in use: 1 [279.34 GB] / in no VG: 0 [0 ]

# vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2

# lvscan
ACTIVE '/dev/VolGroup00/LogVol00' [277.38 GB] inherit
ACTIVE '/dev/VolGroup00/LogVol01' [1.94 GB] inherit


dfを実行してみるとこんな感じです。

# df
Filesystem 1K-ブロック 使用 使用可 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00 286285288 21927512 249815340 9% /
/dev/sda1 101086 19070 76797 20% /boot
none 512528 0 512528 0% /dev/shm

LVMは「/dev/mapper/VolGroup00-LogVol00」のように見えます。すなわちLVMでは、PV作って、VG作って、LVまで作らないとmountできないというわけですね。

【同じVG名がついてしまっている場合】
さて、OS用HDDとデータ用HDDをそれぞれ取り付けてLinux起動し、vgscanをしてみると本来であれば両HDDのVG情報が認識されてくるんですが、もし「VolGroup00」1つしか認識されてこないとしたら、それは両HDDでそれぞれ同じボリュームグループ名が付いてしまっている状態です。OSインストール時に何も考えずにインストールしてしまっている多くの人は大抵ここで問題となります。そのような場合はどちらかのボリュームグループ名を変更してあげる必要があります。

この場合よく行われるのはFedoraCoreのレスキューCDを使う方法です。データ用HDDだけを取り付けレスキューCDを立ち上げます。そして

# lvm vgchange -an VolGroup00" <- VGを無効化する
# lmv vgrename VolGroup00 VolNewGroup00 <- 名前を変更する
# lvm vgchange -an VolNewGroup00" <- VGを有効化する

とします。

【LVMのマウント】
OS用HDDとデータ用HDDをそれぞれ取り付けてLinux起動し、vgscanをしてみてうまくVG情報が見えれば成功です。そうしたら

# vgchange -an VolNewGroup00" <- VGを有効化する
# mkdir /mnt/data
# mount /dev/VolNewGroup00/LogVol00 /mnt/data
# ls /mnt/data

でデータが見えたら大成功です。LVM、便利だけど面倒ですね。

Windowsにおけるソケットの最大値とTIME_WAITの時間を修正しよう

大規模サイトでは1台のサーバにものすごい数のTCPコネクションが張られます。そのような状況ではOSのチューニングをしないとすぐにリソースが枯渇してしまいます。そこで今回はWindowsにおけるソケットの最大値とTIME_WAITの時間を修正する方法をご紹介します。

【前提知識】
サーバにTCPコネクションが張られるとソケットが1つ消費され、そのときポート番号が1つ消費されます。サーバにはポート番号が65534しかないのでソケット（ポート番号）は限られたリソースということになります。しかし実際OSはTCPコネクションのために65534個全てをリソースと活用するかというとそうではなくて通常制限がかかっています。Windowsの場合は5000がデフォルト値です。すなわちチューニングをしないとWindowsでは最大同時接続5000までということになります。これは大規模サイトには小さすぎます。

ただし同時接続5000と言ってもそれは全てのソケットがTCPコネクションされることができた場合の話しです。netstat -anを実行したときにESTABLISHEDやTIME_WAITなどの表示を見たことがあると思います。TCP状態遷移の説明はここでは省きますが、簡単に言うとESTABLISHEDがTCPコネクション中、TIME_WAITがタイムアウトを待っている状態です。すなわちTIME_WAIT状態のソケットがたくさんあるとそれだけ同時接続可能数が減ってしまうということになります。問題はTIME_WAITがどの程度の時間継続するかなのですが、Windowsの場合はなんと4分がデフォルト値です。これまた大規模サイトには長すぎます。

【Windowsにおける設定変更方法】
　「ソケットの最大数」、「TIME_WAITの時間」はそれぞれ以下のレジストリを変更して設定します。項目がない場合は追加します。

■ソケットの最大数(5,000～65,534の間で設定)：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\MaxUserPort (DWORD)

■TIME_WAITの時間(30～300秒の間で設定)：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay (DWORD)

※設定後は再起動しないと設定が反映されません。

【余談】
今回の設定はあくまでも大規模サイトで必要になるものであり普通のサイトではデフォルト設定のままで十分です。同時接続5000以上なんてテスト環境を作るのも結構大変そうですよね。

リモートデスクトップ接続でコンソールのセッションをコントロールする方法

WindowsXPや2003などでリモートデスクトップ接続しようとすると新しいセッションが作られて接続されます。これは、コンソール上で立ち上げているアプリケーション、例えばタスクで定期的に流されるバッチの状況がリモートでリアルタイムに確認できないことを意味します。

そのような場合は

% mstsc /console

と実行するとコンソールのセッションが取得できます。

Windwos2003Serverでの自動ログオン設定方法

Windows Updateをする度にログインするのは面倒くさいので、大勢が使うサーバの一部で自動ログインを実施しています。今回は覚え書きの意味も含めてそのやり方を記載してみます。(この方法、ちなみにWin2000でもできます)

１)　スタートメニュー⇒ファイル名を指定して実行で
control userpasswords2
と入力しEnter 。

２)　ユーザアカウントウィンドウが開くので、　「ユーザがこのコンピュータを使うときにはユーザ名とパスワードの入力が必要（E）」のチェックをはずし、　「OK」ボタン押下。

３)　自動ログオンウィンドウが開くので、自動でログオンしたいユーザ名とパスワードを入力して「OK」ボタン押下。

Windows2003 R2の仮想化環境を使いこなすためのコツ

Win2003 R2の売りはいろいろありますが個人的に注目しているのは仮想化環境です。そこで今回は仮想化環境に注目している理由とそれを使いこなすためのコツを述べてみたいと思います。

【R2の仮想化環境とは何？】
・仮想化テクノロジを使用すると単一の物理的なハードウェア システム (サーバーなど) で複数のオペレーティング システム環境 (OS 環境) を実行することができる。
・x86 および x64 ハードウェア プラットフォームでの仮想化テクノロジ。
・追加コストなく4つまでの仮想インスタンスを実行できる

仮想化環境という考え方は大型汎用機やエンタープライズUNIX機の世界では一般的に使われていましたが、ついにWindowsでも一般的に使えるようになったのだということで感慨無量です。

【仮想化環境で注目している点】
仮想化環境ではハードウェア資源の有効活用というのが何よりもメリットが大きいです。例えばグループウェア、メール、DNS、WEBという4つのサーバが必要な会社において、仮想化環境という技術がなければ4種類のサーバを用意するか無理やり1台のサーバに詰め込むということになっていました。しかし前者はハードウェア資源がもったいない、後者は運用管理が難しいというデメリットがあります。

仮想化環境下では、1台のサーバ上にリアルOSをインストールし、その上に仮想の4つのOSインスタンスを立てることになります。4つのインスタンスはそれぞれ完全に独立していますから1つのOS上に無理やり全てのアプリケーションを立てるのと比べて運用管理コストが大幅に軽減することになります。

【仮想化環境を使いこなすためのコツ】
仮想化環境では複数のインスタンスが同時に動くわけですから普通の環境と比べて多くのハードウェア資源を消費することになります。仮想化環境を使いこなすためのコツは、ハードウェア資源の利用状況を押さえておくことに尽きます。

ただこのblogで何度も述べているように、ボトルネックの調べ方をしっかり押さえておかないと意味なくメモリやCPUを増設するハメになりますので、システム管理者としてはボトルネックの見極め方がとても大切になります。下記に過去記事リンクを載せて置きます。最適な投資を心がけましょう。

サーバのボトルネックはどうやって調べるか

メール系サービスに異常が起きたらまずはDNSまわりを疑え

長い間システム管理をやっていると勘みたいなものがついてきます。今回はそんな勘の中でもメール系サービスのことを書いてみたいと思います。

【メール系サービスのトラブルと言えば】
安定稼動していたメール系サービスで異常が起きた場合、経験上DNSまわりのトラブルであることが非常に多かったです。80%以上？

DNSまわりのトラブルにもいろいろあります。例えば以下のような感じです。

　1.DNSサーバが落ちていた
　2.管理下のDNSサーバは生きていたが、上位DNSが落ちていた。
　3.F/Wルールの変更でDNSへのアクセスができなくなった。
4.MXレコード書き間違い。

【安定稼動していたメール系サービスのDNS以外のトラブル原因】
ついでに安定稼動していたメール系サービスのトラブルで、DNS以外の原因でよくあるものを書いてみます。

・HDD満杯
・やっぱりファイアウォール設定変更ミス
・スパム大量受信によるレスポンス低下

ポート番号を使っているアプリケーションの特定

どのポート番号が使われているかはnetstat -anで確認することができます。しかし残念ながらWindowsやSolaris等には標準でポート番号を使っているアプリケーションが特定できるようにはなっていません(多分)。そこで今回はポート番号を使っているアプリケーションを特定できるアプリケーションをご紹介します。

【UNIX系OSの場合】
UNIX系OSの場合はlsofを利用します。RedhatやFedoraCoreにはlsofが標準でインストールされているようですね。

ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/

【Windowsの場合】
Windowsの場合はActivePortsが便利です。

ActivePorts

サーバ用途の場合ロケールをどうするか

OSやアプリケーションをインストールする際、何も考えないでいると日本語ロケールでインストールしていることが多いと思います(Select your languageとか言われるとそりゃJapanese選びますがな)。しかし本当に日本語ロケールでいいの？ということを今回考えてみたいと思います。

【UNIX系OSでサーバ構築する場合は英語ロケールが安全】
あくまでもサーバ用途と考えた場合、日本語ロケールを選ぶことはよくない場合が多いです。サーバ構築の大原則は「シンプルかつ余計なものは極力入れない」ですから、英語に都合よく作られたOSをあとで日本語が出るように機能追加するということはリソースは喰うしバグやセキュリティホールが含まれていることがあるしあまりいいことがありません。

「日本語処理をしたいんだけど英語ロケールでも問題ないの？」という質問があるかもしれません。どの開発言語を使うかによるかと思いますが、ほとんどの開発言語の場合その処理構造を考える限り文字コードを自然言語の区別なく単なるデータとして処理しているだけなので問題ないかと思います。（もちろん実験はしてね）

【Windows等GUI系サーバ構築の場合は・・・日本語ロケールかなぁ】
同様にWindows等GUI系サーバ構築の場合も、「シンプルかつ余計なものは極力入れない」の原則でいくと英語ロケールが一番いいと思うんですが、問題はオペレータのレベルですね。Windowsの場合オペレータの数が世の中に豊富で割と安価に確保ができますが、英語版Windowsを扱えるオペレータということになると極端に少ないです。例え英語版Windowsのほうが安定していたとしてもオペレータがオペミスしてしまっては意味がないのでそれなりのレベルのオペレータを揃えなければならない・・・と考えていくと日本語ロケールを選んだほうが無難なのかな、と思ってしまいます。

【DBの場合】
応用でDBの場合も考えてみたいと思います。コマンドラインベースのDB(MySQL,PostgreSQL,Oracle)の場合は同様の理由で英語ロケール、SQLServerの場合は日本語ロケールがよいかもしれません。

Win系サーバのリモートからのリブートやシャットダウン

Windowsサーバがたくさんある場合、パッチ適用後にリブートするだけでも結構な手間です。そこで今回はサーバのシャットダウンやリブートをリモートで行う方法をご紹介します。

【shutdown.exeコマンド】
WinXPやWin2003 Serverにはshutdown.exeコマンドが標準装備されています。Win2000でもおそらくリソースキットの中に入っています。このコマンドを使うとリモートでサーバリブート/シャットダウンができます。

例:
shutdown -f -r -t00 -m \\SERVER01
shutdown -f -r -t00 -m \\10.1.0.1

【このコマンドの活用方法】
例えば5台のサーバを定期的にリブートしたいとします。そういった場合は

reboot.bat:
shutdown -f -r -t00 -m \\10.1.0.1
shutdown -f -r -t00 -m \\10.1.0.2
shutdown -f -r -t00 -m \\10.1.0.3
shutdown -f -r -t00 -m \\10.1.0.4
shutdown -f -r -t00 -m \\10.1.0.5

のようなバッチファイルを作っておいて、タスクやatコマンドで登録しておきます。そうすると定期的にサーバリブートが行えるようになります。

Windows2000のログイン画面カスタマイズ方法

こだわりのサーバはログイン画面もカスタマイズすべきです。（暇ならば）

■壁紙を使う

HKEY_USERS\.DEFAULT\Control Panel\Desktop\Wallpaper

に壁紙となる画像ファイルのファイル名を指定します。

■壁紙の表示方法の指定

HKEY_USERS\.DEFAULT\Control Panel\Desktop\TileWallpaper

の値を０にすると中央に表示。１にすると並べて表示。

■壁紙の拡大

HKEY_USERS\.DEFAULT\Control Panel\Desktop\WallpaperStyle

の値を０にするとデフォルトの大きさ。２にすると拡大して表示。

サーバスペックの決め方

昔初めてサーバを購入することになったとき、サーバスペックをどのように決めたらいいか大いに悩んだものです。そこで今回はサーバスペックの決め方について一般論を述べてみたいと思います。

【大前提】
まず大前提はどのようなサービスでどの程度のユーザ数がどの程度の頻度でアクセスしてくるのかある程度目安がないと判断のしようがないです。これはプロマネかもしくは企画者が決めるものだと思うので決めてもらってください。

【常識的に考える】
サーバスペックの決め方には一応の目安が存在するにはしますが、最終的には勘や経験則での判断になることが多いです。しかしそれだと初めての場合決めようがないですね。ではどうすればよいか。

私は、常識的に考えるという方法をお勧めしたいです。これはどういうことか。たとえばDBの場合は明らかにCPUを駆使しそうだしディスクI/Oもがりがり負荷がかかりそうだ。なのでCPUやHDDを高スペックにしよう、とそういう感じです。ボトルネックとなりうる要素は主に「CPU使用率」「メモリ使用量」「ディスクI/O」「TCPコネクション数」の４つなので、その４つそれぞれについて考えていけばいいと思います。

※こちらの記事(サーバのボトルネックはどうやって調べるか)も参考にしてやってください。

【私ならどう考えるか】
私がサーバスペックを決める場合、このように考えます。

・WEBサーバ(動的コンテンツなし)・・・4要素いずれもそんなに負荷がかからないので最低スペックでOK。(例：CPU1個,メモリ512M以上、HDD18MB回転数5400rpm以上)

・WEBサーバ(動的コンテンツあり)・・・CPUとメモリを駆使する場合が多いです。サービスによってはディスクI/Oも高い可能性があります。(例：CPU2個,メモリ1GB以上、HDD18GB回転数10krpm以上)

・APサーバ・・・CPUとメモリを駆使する場合が多いです。サービスによってはディスクI/Oも高い可能性があります。(例：CPU2個,メモリ1GB以上、HDD18MB回転数10krpm以上)

・DBサーバ・・・CPU、メモリ、ディスクI/O全て駆使する場合が多いです。またディスク容量が当然データ量以上必要になります。あとRAID構成も必要になりますね。(例：CPU2個以上,メモリ2GB以上、HDD73GBx3回転数15krpm以上)、RAID5)

※余談：最近のCPUはかなり速くなってきていて、かつハイパースレディングできるものも多くなってきています。そんなCPUを使えばCPU1個だけでもかなりのキャパシティがあり、CPU1個だけしか積まない選択をすることが多くなってきました。よい時代になりました。

Win2000でスタートアッププログラムを止める方法

Win2000にはmsconfigがないのでスタートアッププログラムを止めるのはちょっと面倒です。

1.　[スタート]→[ファイル名を指定して実行]してmsinfo32と入力
2.　[システム情報]が表示される。左側から[ソフトウェア環境]→[スタートアッププログラム]とサブカテゴリを選択する。
3.　右側に起動されるプログラムの一覧が表示されるので削除したいプログラムをメモする。
4.　[スタート]→[ファイル名を指定して実行]してregeditと入力。
5.　レジストリエディタが起動したら、メモしたものを検索して削除する。

※補足 (2005/7/11)
・・・と書いてみたけど、以下のレジストリ直接いじるのが早いな。
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Run

デフラグを自動的に周期的に実行する方法

デフラグを自動的に周期的に実行する方法をご紹介します。

コントロール→タスクを選択し、

「C:\WINDOWS\SYSTEM32\DEFRAG.EXE /ALL /F /NOPROMPT」

or

「C:\WINNT\SYSTEM32\DEFRAG.EXE /ALL /F /NOPROMPT」

を実行するように設定します。ファイルサーバなどにこれを設定しておくとパフォーマンスが向上するのでおすすめです。

Linuxで表示言語を変えたいときは

完全覚え書きです。Linuxで表示言語を変えたいときは

/etc/sysconfig/i18n

を書き換えます。

LANG="ja_JP.eucJP"

を

LANG="en_US.UTF-8"

とするとメッセージが日本語から英語に変わります。日本語だと文字化けするので嫌という人にお勧めです。(?!)

悪意のあるソフトウェアの削除ツール

「Microsoft Windows 悪意のあるソフトウェアの削除ツールを使用すると、Windows XP、Windows 2000、および Windows Server 2003 コンピュータが、Blaster、Sasser、Mydoom などの特定の悪意のあるソフトウェアに感染していないかどうかをチェックし、感染している場合は駆除することができます。検出処理と駆除処理が終了するとその結果が表示され、検出されて駆除の対象となった悪質なソフトウェアが表示されます。」

だそうです。ActiveXベースなのでインストールもいらず簡単楽ちんです。

http://www.microsoft.com/japan/security/malwareremove/default.mspx

negotiation設定変更方法(FreeBSD編)

①ifconfig で現在の状態を確認

# ifconfig
fxp0: flags=8843 mtu 1500
inet 10.0.0.21 netmask 0xffffff00 broadcast 10.0.0.255
inet6 fe80::206:5bff:fe3c:970%fxp0 prefixlen 64 scopeid 0x1
ether 00:06:5b:3c:09:70
media: Ethernet autoselect (none)
status: active
fxp1: flags=8802 mtu 1500
ether 00:06:5b:3c:09:71
media: Ethernet autoselect (none)
status: no carrier

②以下のコマンドで 100M full に設定

# ifconfig fxp0 media 100baseTX mediaopt full-duplex
# ifconfig fxp1 media 100baseTX mediaopt full-duplex

③ifconfig で確認

# ifconfig
fxp0: flags=8843 mtu 1500
inet 10.0.0.21 netmask 0xffffff00 broadcast 10.0.0.255
inet6 fe80::206:5bff:fe3c:970%fxp0 prefixlen 64 scopeid 0x1
ether 00:06:5b:3c:09:70
media: Ethernet 100baseTX
status: active
fxp1: flags=8802 mtu 1500
ether 00:06:5b:3c:09:71
media: Ethernet 100baseTX
status: no carrier

④/etc/start_if.fxp0 を作成
ifconfig fxp0 media 100baseTX mediaopt full-duplex
ifconfig fxp1 media 100baseTX mediaopt full-duplex

negotiation設定変更方法(Solaris編)

やりかたをよく忘れるのでφ(..)メモメモ。

①etc/system に以下の様に設定を行う。

set hme:hme_adv_100fdx_cap=1
set hme:hme_adv_100hdx_cap=0
set hme:hme_adv_10hdx_cap=0
set hme:hme_adv_10fdx_cap=0
set hme:hme_adv_autoneg_cap=0

※hme以外の qfe, eri, hmeについても、上記の設定方法は共通。パラメタの指定で、hme とあるところを、それぞれ、qfe, eri, hme に置き換えることで設定を行うことが可能。

※ただしdmfeの場合は/etc/systemに書く方法は使えない。

②リブート

③どうしてもリブートできない場合は、上記の記述に加えて、下記のコマンドを実行

# ndd -set /dev/hme0 adv_100fdx_cap 1
# ndd -set /dev/hme0 adv_100hdx_cap 0
# ndd -set /dev/hme0 adv_10hdx_cap 0
# ndd -set /dev/hme0 adv_10fdx_cap 0
# ndd -set /dev/hme0 adv_autoneg_cap 0

■確認方法
# ndd /dev/dmfe0 adv_autoneg_cap

のようにして、無効であれば0が、有効であれば1になります。

壊れにくいサーバについて考える（メモリ編）

メモリって頑丈そうで結構壊れます。信頼のおけるメーカーのメモリを選ぶことはとても重要です。特にメモリ増設の際は要注意ですね。

サーバ用のメモリはECC(Error Checking and Cirrection)機能、すなわちエラー発生時の自動補正機能がついているのが普通ですからPC用のメモリと比べれば信頼性は高いです。

しかしいくらECC機能がついていたとしても、システム管理者がサーバのログチェックをしていなくてメモリ故障に気づかなかったとしたら宝の持ち腐れです。こまめにログチェックをしてメモリ故障時ECC機能が有効であるうちにメモリ交換をしてしまいましょう。

Solaris等エンタープライズ用途を想定したOSはやはりよくできています。ログを見るだけでそのボードに刺してある何番目のメモリにどのような異常があるか手にとるようにわかります。最近Solarisを触ってないので忘れかけてますが、たしか/var/adm/messagesを見たり、prtdiagコマンドをたたいたりするんでしたよね。あとどなたか覚えていたら教えてください。Solarisでは「psradm -f 2 3」とかやるとCPUをoff-lineに、「psradm -a 2 3」とやるとon-lineにできましたが、これって同様にメモリでもできるんでしょうか。できたらシステム管理的には便利なんですけどね。

壊れにくいサーバについて考える（ファン編）

サーバやネットワーク機器でファンが壊れるという現象はよく聞きます。うちも何度か被害にあっております。特に中古品はファン故障、多いですね～。多分こまめに掃除をしてあげればよいんでしょうね。

SNMP等で温度の測定ができるようにしておくとファン故障がすぐに検知できてよいですよ。でもそこまできちんと測定しているところって特にＩＴベンチャーではあまり聞いたことがないですけど。

壊れにくいサーバについて考える（パワーサプライ編）

「パワーサプライはよく壊れるんですよね～」。そんなことを某サーバメーカーの営業さんに話したところ、日本製のパワーサプライは壊れにくいとのこと。壊れやすいというのは海外製の品質の悪いパーツを使っているからなんでしょう、とのことでした。

そういえば数年前パワーサプライがよく壊れると悪評高かった某究極ネットワークスイッチベンダー、さすがに懲りたのか現在は日本製の品質のよいパーツに変えて現在はあまり壊れなくなったとのこと。

そもそもあれなんですよね。日本って100Vじゃないですか。海外は200Vのところが多いので、200Vの国で作られたパーツが100Vの環境できちんと長い期間動作するかきちんと検証してなかったんでしょうね。このあたりの裏話に詳しい方のコメントを期待したいです！

壊れにくいサーバについて考える（HDD編）

※多くの方から「HDD障害を防ぐには冷却が重要」との意見を頂戴しましたのでその件追加しました(2005.1.19)

幸いなことにうちの会社ではこれまでサーバ故障に見舞われたことがほとんどないのですが、他の会社に勤める技術者の方々と話すと結構サーバ故障が頻発して困っていると聞くことが多いです。まずはサーバの中で壊れやすい部分はどこかを知っておくことは必須です。一般的には次の順番で壊れやすいと言われます。

　第１位：HDD
　第２位：パワーサプライ
　第３位：ファン
　第４位：メモリ

この４要素全てで品質が良いサーバを選べば壊れにくいサーバであると言えます。そこで今回はその中でも壊れやすいと言われるHDDについて考えてみたいと思います。

【HDDについて知る】
ハードディスクにはATAとSCSIがあるのはご存知だと思います。ATA HDDよりSCSI HDDの方が価格が高いので壊れにくいのでは、と通常思われているわけですが、これは半分その通りですが、その程度の認識だけだと不十分です。

メーカーによりますが通常どのメーカーでもサーバ用と一般用の２ラインの製品を持っています。サーバ用と一般用では品質にかなり大きな差があり、それに伴いMTBF(mean time between failure・・・壊れるまでの時間)も桁違いに変わってきます。よって一般用HDDを使っているようなサーバがもしあったとしたらそれはサーバ用途としては論外ということになります。

次にSCSI HDDとATA HDDについてですがMTBF的に見るとSCSI HDDのほうがATA HDDより長いことが普通です。何故そんな結果になるのかビジネス的な視点で考えれば明確です。SCSI HDDとATA HDDは構造的には似通っているのでATA HDDでもSCSI HDD並みのMTBFにすることはメーカー的に可能なはずですが、SCSI HDDの方が高く売れ、かつミッションクリティカルな環境でATA HDDを使うような顧客はほとんどいないはずなので、必然的にメーカーは「安価だが壊れやすいATA HDD」と「高価だが壊れにくいSCSI」というラインナップを打ち出してくるわけです。

またどこの国のメーカーの製品かということも意外と重要になってきます。アメリカ人的な発想では壊れれば交換すればよいという発想でMTBF的には多少劣るが安い製品を出そうとするのに対して、日本人的な発想では良いものであれば高くても売れるという発想でMTBF的には優れているが高い製品を出そうとします。

ということでまとめるともし壊れにくいHDDを選ぶのだとしたらサーバ用に作られた日本製のSCSI HDDがベスト、逆に壊れやすくてもよいから安いHDDを選ぶとしたら一般用に作られた外国製のATA HDDを選択するのがよいということになります。

※余談１：僕が他の会社の技術者仲間から「うちのサーバは壊れやすい」と聞く場合、確認してみるとほぼ例外なくATA HDDを使っています。うちはSCSI HDDしか使わないためかHDD故障でシステムが止まったことはほとんどなかったです。

※余談２：HDD故障で一番多いのは初期不良ですので、安定したHDDを使いたいと考えるのであればサーバを購入したらいきなり使わないで品質テストとして１週間くらいHDDを回してみることをお勧めします。ちなみにこのような品質テストをお客様に納品する全HDDで実施しているという良心的なサーバメーカーを僕は１社知っています。もしこのメーカーについてご興味があるかたはメールで問い合わせいただければお教えします（宣伝になっちゃうのでここに書くのは控えました）。

※余談３：HDD故障を引き起こす原因で最も多いのは熱だそうです。うちはデータセンターを使っていて熱は特に気をつけていたため、熱が原因の障害というのはこれまで発生したことがありませんでした。よってHDDが熱に弱いということは全く知りませんでした。ストレージに非常にお詳しいD社のSさん、ひょっとしてこれって常識でした？

Windwos2000Serverでの自動ログオン設定方法

Windows Updateをする度にログインするのは面倒くさいので、大勢が使うサーバの一部で自動ログインを実施しています。今回は覚え書きの意味も含めてそのやり方を記載してみます。

１)　スタートメニュー⇒ファイル名を指定して実行で
rundll32 netplwiz.dll,UsersRunDll
と入力しEnter 。

２)　ユーザアカウントウィンドウが開くので、　「ユーザがこのコンピュータを使うときにはユーザ名とパスワードの入力が必要（E）」のチェックをはずし、　「OK」ボタン押下。

３)　自動ログオンウィンドウが開くので、自動でログオンしたいユーザ名とパスワードを入力して「OK」ボタン押下。

ホスト級UNIXマシンにLinuxを入れよう

以前IBMさんとお話ししたとき、IBMで販売しているサーバ機ならどれでもLinuxが動くように準備をしているということを聞きました。これは安価なIAサーバからホスト級UNXサーバp690までどれでもということです（SunのFire25kではLinuxは動かないようですがHPのSuperdomeではLinuxが動くようですね）。当初の私は素人考えで「Linuxなんか動かす人なんているのか～？」なんて思っていましたが、最近は「それもアリかも」と思うようになりました。

会社規模が大きくなってくると、サーバダウンが即機会損失につながります。会社創業当時だったら機会損失といっても１時間サーバを止めても数百円程度にしかならなかったのでへっちゃらでしたが、最近だと、○○○○円（企業秘密）もの損失になるため、コストがかかってもサーバを止めないための出費なら許されるようになりました。

というように状況が変わると、Linuxでしか動かないアプリケーションは、ホスト級UNIXマシンに載せて動かすのは可用性向上には大変効果的なのではないかと考えるようになりました。読者の皆さんはホスト級UNIXマシンの経験があるかどうかはわかりませんが、そのクラスのマシンになると、まずハードウェア的な障害でシステムがダウンすることはまずありません。またそのクラスのマシンはどのメーカーも論理的分割（Sunだとドメイン、IBMだとLPAR、HPはよく知らないけどパーティショニング？）ができるので、マシンパワーの数パーセントをパーティション分けして使うというようなことができるようになります。すなわちホスト級UNIXマシンをまずメインDB用途に導入しておき、余ったマシンパワーでLinuxを動かすという使い方ですね。

Linuxで空きメモリ容量の調べ方

サーバ増強の検討に入るとき現在のサーバリソース使用量を知ることがとても大切になりますね。最近はサーバ増強台数の決定をうちの若いもの達にやってもらうようにしたのですが、そうすると勘違いが多く見られてちょっと驚きました。そこで今回はLinuxで空きメモリ容量の調べ方を記してみましょう。

【よくある間違い】
メモリ空き容量を調べる際、経験が浅い人だとtopもしくはvmstatあたりのコマンドを使って判断しようとします(マニアックな方はprocinfoを使うかもしれない)。次の例をみてください。

---

# top

Mem: 902772k av, 883884k used, 18888k free, 0k shrd, 42396k buff
547404k actv, 0k in_d, 18852k in_c
Swap: 2096440k av, 2956k used, 2093484k free 647904k cached

---

topで見るとメモリ搭載量1GBに対して空きが18Mbしかないように見えます。メモリ増強が必要？ でもちょっと待ってください。Linuxはメモリに空きができるとバッファとキャッシュに割り当てようとしますが、これらは空きメモリ容量と考えられます。

【正解】
というわけで正解です。Linuxの場合、空きメモリ容量はfreeコマンドで確認します。

---

# free
total used free shared buffers cached
Mem: 902772 895416 7356 0 40424 689488
-/+ buffers/cache: 165504 737268
Swap: 2096440 2392 2094048

---

２行目がバッファとキャッシュで使われた分を除いた本当の空きメモリ容量になります。freeで確認すると737MBも空いていることがわかりますね。なんだ、メモリ増強の必要がないや、とわかりましたね。めでたしめでたし。

RedHatの代わりにFedora Core2を使おう

先日社内で各OSのパフォーマンステストをやってみました。比較対照はRedHat9、Fedora Core2、Windows2000、Windows2003の４つです。

RedHat9.0とFedora Core2の比較だけでいうとFedora Core2が圧倒的でした。OSの違いというよりはLinux Kernel2.4とLinux Kernel2.6のパフォーマンスの違いがそのまま結果として現れたということになるのかもしれません。すばらしいです。

またついでに各OSの上にWEBサーバもやってみました。一番速かったはWindows2003+IIS6、二番目に速かったのはFedora Core2+Tux Web Server3になります。

【結論】
RedHat9.0である必要がない人は迷わずFedora Core2を使いましょう。

サーバのボトルネックはどうやって調べるか

サーバのレスポンスが遅くなると経験のないサーバ管理者は無意味にメモリ増強を行ったりしますが、行き当たりばったりのシステム拡張は無駄な投資につながります。ボトルネック個所の調べ方は案外簡単なので、この際押さえるところをきちんと押さえて正しい方法論でシステム拡張をしていきましょう。

【一般論】

ボトルネックとなりうる要素は主に４つです。

①CPU使用率
②メモリ使用量
③ディスクI/O
④TCPコネクション数

これらを押さえておけばボトルネック個所の把握とその解消は難しくありません。これを踏まえた一般論を述べてみたいと思います。

WEBサーバの場合は多くの場合、TCPコネクション数から先に限界が来ます。OSやApache等のWEBサーバのパフォーマンスチューニングを十分施すことが前提ですが、その場合TCPコネクション数1万くらいまではなんとか保てると思いますが、それ以上のTCPコネクション数がある場合はサーバ増強が必要だと思われます。TCPコネクション数は「netstat -an」で調べることができます。

アプリケーションサーバの場合は多くの場合、CPU使用率とメモリ使用量から先に限界が来ます。この場合CPU増強とメモリ増強を行うことも重要ですが、アプリケーションを書き換えることのほうが効果的な場合が多いです。UNIXの場合はCPU使用率はtopコマンドかwコマンド、メモリ使用量はtopコマンドかfreeコマンド等で調べられます。Windowsの場合はタスクマネージャで調べましょう。

DBサーバの場合は、問題の切り分けが難しいです。通常①②③のどれかがボトルネックになります。CPU使用率が70%を超えた辺りから注意というのはよく言われますね。あと意外と気づきにくいけどディスクI/Oです。ディスクI/Oのレスポンスが大幅に低下している場合はストレージ政策の見直しからはじめるべきだと思います(この件は後日改めて記します)。UNIXの場合はvmstat,iostat等で調べましょう。

【各種コマンドの使いこなし方】

ここからは実際のボトルネック測定方法をコマンドの使い方と共に記してみたいと思います。

■CPUボトルネックの測定(UNIXの場合)

# top
151 processes: 150 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states:  0.4% user,  0.5% system,  0.0% nice, 98.1% idle
CPU1 states:  0.1% user,  0.5% system,  0.0% nice, 98.4% idle
Mem:   513596K av,  442136K used,   71460K free,       0K shrd,   77992K buff
Swap: 1044184K av,   14120K used, 1030064K free                  208420K cached

CPU0と1の2個があって、それぞれidleが98%以上なので問題ないですね。

# w

12:08pm  up 171 days,  1:20,  1 user,  load average: 1.22, 1.02, 1.97

ロードアベレージが正常値なので問題ないですね。

※ロードアベレージの数値をどう読むかについてはこちらが参考になります。

■メモリボトルネックの測定(Linuxの場合)

# top
151 processes: 150 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states:  0.4% user,  0.5% system,  0.0% nice, 98.1% idle
CPU1 states:  0.1% user,  0.5% system,  0.0% nice, 98.4% idle
Mem:   513596K av,  442136K used,   71460K free,       0K shrd,   77992K buff
Swap: 1044184K av,   14120K used, 1030064K free                  208420K cached

512MBのメモリを搭載しているマシンで、442M程度のメモリを使用していて70M程度のメモリしか空きがない、と読み取れますが、それは厳密には間違いです。もっと見てみましょう。

# free
             total       used       free     shared    buffers     cached
Mem:        513596     443556      70040          0      78340     209196
-/+ buffers/cache:     156020     357576
Swap:      1044184      14120    1030064

Linuxの場合空いるメモリはすべてCacheにまわそうとします。それがtopに出てくる数字です。では空いているメモリでCacheで使われている分を減らした分はどのくらいかを調べるにはfreeコマンドでの実行結果の2行目を見ます。これを見ると357MBくらい空いているのがわかります。よってこのマシンはメモリに大分余裕があると見ることができます。

■ディスクI/Oボトルネックの測定(Linuxの場合)

# vmstat 1 5
   procs                      memory    swap          io     system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
 0  0  0   3604   3580  23580 187696   0   1     0     1    1     1   0   0   1
 0  0  0   3612   3580  23592 187636   0   8   148    96 1432   291   0   7  93
 0  0  0   3612   3484  23624 187756   0   0   312   332 1376   321   0  10  90
 0  0  0   3620   3456  23616 187772   0   8   164    80 1301   320   0   6  94
 0  0  0   3620   3600  23636 187772   0   0   488    64 1340   318   0   8  91

ここではbi/boの部分を見ます。bi: Blocks received from a block device (blocks/s).
, bo: Blocks sent to a block device (blocks/s)。どのくらいが適正値かというのは予算によります。一番お金をかけた場合だとストレージのキャッシュが十分に積まれていて、どんなにディスクにアクセスしてもbi/boが0というパターンになります。(きちんとディスクに書き込みを完了する前にドライブが書き込み完了を返す)

■ネットワークボトルネックの測定(UNIXの場合)

# netstat -an | wc -l
3050

この数字がTCPコネクション数とほぼ同等です(厳密にはESTABLISHED,TIME_WAIT,FIN_WAIT等の総数。余計な部分は許容誤差ということで)。

Windows vs UNIX論争はナンセンス。サーバOS選定のポイント

私はWindowsとUNIXのどちらが優れているかを論じることはあまり意味がないと思っています。要はそれぞれのＯＳの個性を知り、使い分ければよいだけの話です。(とは言いつつも１つのＯＳを覚えると他のＯＳを覚えるのは大変なのでそのＯＳに固持したくなる気持ちはよくわかりますけどね)

そこでここでは各ＯＳの一長一短に触れ、適切なＯＳの選定について私見を述べてみたいと思います。

【資料】各ＯＳの比較

-----------------------------------------------------------------------
OS             response       Disk I/O安全性         備考
-----------------------------------------------------------------------
Windows        ○                ○　　　　　　　　　    ASP言語を使える
Linux          ◎◎              ×××                  最速
Solaris        ×                ◎◎                    安全
FreeBSD        ○                ○　　　　　　　　　    JAVAに弱い
-----------------------------------------------------------------------

●Windows
ASP言語が使える唯一のOSです。開発納期を短縮するために習得が簡単なASP言語を選択するのはとてもよい考えだと思います。開発納期が短いサイトのWEBサーバに最適です。

IISはセキュリティ上弱いと思われていますが私はそうは思いません。サーバの設定を適切に行っておけば不正アクセスから十分保護できます。UNIX系OSと比べてWindowsはWindowsUpdateがあるおかげでパッチ適用が簡単な点は十分評価すべきだと思います。

●Linux
処理は速いけどDiskI/Oまわりの安定性が貧弱。自動車に例えるとスーパーカーのようなOSと言えます。DiskI/Oを駆使するアプリケーションをがんがんまわすとOSがフリーズするか最悪HDD自体が死亡します。

Linuxはセキュリティパッチが非常に多く出回るので油断ができません。Windowsより危険なんじゃないかと個人的に思っています。

RedHat Linuxでは世界最高速のWEBサーバ、Tux Web Serverが使えるのが大きなメリットです。Tux Web ServerではCGI等の動的なコンテンツは扱えませんが、その欠点を除けばapacheの2倍～5倍くらいのパフォーマンスが出ます。世界的に見て実績が非常に少ないですがなんでこんなよいものを使わないのか不思議でたまりません。画像データ等の静的データを配信するWEBサーバに是非お使いください。

WEBサーバとしては最適ですがDBサーバとしては決して使いたくないOSです。

補足：Kernel2.6はDiskI/Oが安定しているとの情報入手。余裕ができたら一度確認してみます。

●Solaris
Solarisは固いので有名ですが、個人的にもその名声に恥じないとても安定したOSだと思っています。特にDisk I/Oまわりの処理は遅いけど確実であることは大きな安心です。見た目は他のOSと変わりませんが、システムの状態を知るためのコマンド類がとても充実しています。かゆいところに手が届くOSと言えます。

が、残念ながらハードウェアは故障が多くてあまりよくないかもしれません。最近のモデルは知りませんが、昔のEnterprise系のモデルではよくCPUやメモリが死んでいました。ただしエラーログにパーツ故障情報が詳細に載るので予備部品を持っていれば怖くはないですけど。

絶対に止められないDBサーバやWEBサーバにお勧めです。

●FreeBSD
フリーのOSとして一時期Linuxと人気を二分していたのに、いつの間にかLinuxの圧勝な情勢となってきています。

OSの安定性はとても高いです。またセキュリティパッチがほとんど出ないのも安心です。Linuxと比較してディストリビューションが１つしかないので情報の入手がしやすいというのも大きなメリットです。

FreeBSDの弱点はライセンスの問題か何かでJAVAのサポートが遅れたことです。現在の状況は正確に知りませんが、まだまだFreeBSDで本格的にJAVAを扱うには時間がかかることでしょう。

あと大きな点ではありませんが、インストールがとても簡単で、慣れれば５分もあればインストールが完了します。

ということでDNSサーバ、メールサーバ等に最適です。

●(おまけ)IRIX,AIX,HP-UX
これらは私は多少経験がありますがほとんど知りませんので評価できません。しいて言えばAIXはコマンドが独特で、Linuxからの乗り換えだと学習が面倒かもしれません。Solarisからの乗り換えだとIBMがそれ用の資料が提供されているので多少は楽ですけれども。