Serverの最近のブログ記事

 どういうものなのかググッても的確な情報が出てこないのですが、1IPあたり秒間30回程度の不正アクセスを受けています。

 結果として404エラーで返していて、内容からしてWindowsサーバに対してアタックしているようなので、単にウザイだけなんですが、国内の一般プロバイダからのアクセスなので切断するわけにも行かない・・・。

一応どんなログが出ているかというとこんな感じ。

221.251.12.138 - - [10/Nov/2010:13:16:11 +0900] "GET /contents/c/url(res://C:/Program%20Files/Google/Google%20Toolbar/Component/GoogleToolbarDynamic_mui_en_950DF09FAB501E03.dll/findy_buttons.png) HTTP/1.1" 404 1148 "http://c-production.com/contents/c/sec11.html" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB6.6; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"


 この障害が発生した時ネット経由で知ってちょいちょいアクセスしてみましたが、ロードバランサが原因だったのか・・・。意外でした。

 ドメインでのアクセスで即エラー帰ってくるし、DNSで調べてIP直接だとアクセスできて、ウェブサーバは生きてるしDNSが落ちているわけでも無くてなんだろうと思ってましたが納得です。ウェブサーバ自身がグローバルIPを持っているのかどうかは知りませんがもしかしたらロードバランサーが完全ダウンしたのではなくて一部障害状態になったのかもしれませんね。憶測はここまでにしておいて、続報があれば確認したいと思います。

 そして今回の件でアクセス負荷に対してロードバランサで負荷分散するやり方ではいつかロードバランサの故障でサービス不能になる一例として見させていただきました。こういうのってDNS側でもラウンドロビンさせてロードバランサもアクティブ機を複数台用意してその下に繋ぐウェブサーバをボンディングとかで回避できるかな?

Yahoo! Japanのアクセス障害、原因はロードバランサーの物理障害 - CNET Japan
http://japan.cnet.com/news/business/story/0,3800104746,20421416,00.htm
SSHの設定が済んだら次はファイアーウォールですよね。不要なサービスを止める作業も必要ですがそれだけでは新しくインストールした未設定のサービスが標的にされることもあるのでとりあえずアクセスを弾く機能は必要だと思います。

前回のSSHでも同じですが、この辺の設定を誤るとリモートログイン自体が出来なくなる可能性がありますので設定内容と手順には十分気をつけましょう。さくらのVPSの場合はブラウザ上でシリアル接続できるので最悪そこから設定を戻す事になります。(実は手順ミスって接続切られたorz)

参考:
にわかSEの独り言 CentOS 5.2 x64でiptablesを設定

基本参考サイトの通りなのですが若干気をつける点がありましたのでこちらで試した手順は以下の通り。

今までは/etc/sysconfig/iptablesを編集していたのですが、さくらのVPSにはそのファイルが初期状態でありません。それでコマンドラインで設定することにしました。念のためiptablesがストップしている事を確認し自動起動も外しておいたほうが良いと思います。それは万が一設定を間違って接続できなくなっても再起動すれば良いので、接続手段が無くなってしまったときにリモートか若しくはデーターセンター側のサポートで再起動してもらえば良いからです。

設定の初期化
# iptables -F

受信を全て破棄
# iptables -P INPUT DROP

送信を全て許可
# iptables -P OUTPUT ACCEPT

通過は全て破棄
# iptables -P FORWARD DROP

# サーバから外部に接続したコネクションのレスポンスを許可(2010/10/08追加)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

PINGの許可
# iptables -A INPUT -p icmp -j ACCEPT

ローカルの許可
# iptables -A INPUT -i lo -j ACCEPT

ブロードキャストアドレス、マルチキャストアドレス宛のパケットを破棄
# iptables -A INPUT -d 255.255.255.255 -j DROP
# iptables -A INPUT -d 224.0.0.1 -j DROP

SSHの許可
# iptables -A INPUT -p tcp --dport 22 -j ACCEPT

SMTPの許可(submissionも追加) 2010/10/08修正
# iptables -A INPUT -p tcp --dport 25 -j ACCEPT
# iptables -A INPUT -p tcp --dport 587 -j ACCEPT
# iptables -A INPUT -p tcp --sport 25 -j ACCEPT
# iptables -A INPUT -p tcp --sport 587 -j ACCEPT

DNSの許可(source port 53 のルールも追加して下さい) 2010/10/08修正
# iptables -A INPUT -p udp --dport 53 -j ACCEPT
# iptables -A INPUT -p udp --sport 53 -j ACCEPT

HTTPの許可
# iptables -A INPUT -p tcp --dport 80 -j ACCEPT

POP3の許可
# iptables -A INPUT -p tcp --dport 110 -j ACCEPT

NTPの許可
# iptables -A INPUT -p udp --dport 123 -j ACCEPT

SNMPの許可
# iptables -A INPUT -p tcp --dport 161 -j ACCEPT
# iptables -A INPUT -p udp --dport 161 -j ACCEPT

SSLの許可
# iptables -A INPUT -p tcp --dport 443 -j ACCEPT

DROP対象をロギング
# iptables -A INPUT -m limit --limit 1/s -j LOG --log-prefix "[IPTABLES INPUT] : "
# iptables -A INPUT -j DROP
# iptables -A FORWARD -m limit --limit 1/s -j LOG --log-prefix "[IPTABLES FORWARD] : "
# iptables -A FORWARD -j DROP

設定の保存
# service iptables save

iptables起動
# service iptables start

ざっとこんな感じですが、FreeBSDのファイアーウォールと違ってハマったところは、私の調査不足なだけかも知れませんがレスポンスについてのルールを設定していないこと。サーバーから外部へのアクセスについては全許可してますが、そのアクセスのレスポンスについては何も設定していないので応答がDROPされてしまいました。今回の場合DNSの応答がDROPされた為、iptablesを起動してからSSH接続の応答が非常に遅くなって焦りました。

ちなみにSSH接続の応答が遅い時は経験上、接続元のIPを逆引きしようとして失敗している場合が多いので/etc/resolv.confで指定しているDNSサーバはアクセス可能なのか、今回のように53番が塞がっていないか確認します。そもそもSSH接続でDNS使うなよって思っているのですが、どうも逆引き→正引きを行ってIPアドレスが正しいものか認証しているようですね。理由が分かるとUseDNSをnoに変えるのもマズイかなっと思った。

追記:2010/10/08
探したらありました。絶対あるはずだと思ってた。

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

最初のACCEPT行の上に書いておけば良いかな。これでsource port 53のルールは不要になりました。多分SMTP関係のsource portのルールも不要になっているはずなので外してメールサーバを構築した時に確認してみます。

参考:
Kozupon.com - 解りにくいiptablesのアルゴリズム!
 サーバーコストの節約という事で専用サーバ+共用レンタルの構成をVPS2台にしようとお試しで1台借りてみました。

さくらのVPS|VPS(仮想専用サーバ)はさくらインターネット

早速ですが最初はrootユーザしか無いためセキュリティ関連の設定を行います。ちょっと変則的かも知れないかもしれませんが一例として。

まずはroot権限に昇格できる作業ユーザを作成します。俺ルールとしてはこのユーザでメールやウェブは使わないようにしています。ここでは名称をworkuserとして書きますが、実際に作業ユーザを作成する場合は辞書にヒットするような名称は避けましょう。

作業ユーザの作成
# useradd workuser

パスワードの設定
# passwd workuser

ユーザグループの変更(wheelグループに所属させる)
# usermod -g wheel workuser
# usermod -G wheel,workuser workuser

SSHのログイン方法ですがVPSなら運用上SSHログインするユーザは狭い範囲で限定されることが多いと思いますのでクライアント認証の方式にします。

ユーザ用のキーペアを作成しておく
※今回はteratermの機能で作成
メニュー[設定]-[SSHキー作成]
作成した公開鍵をログインするユーザの~/.ssh/authorized_keysに保存

workuserに切り替え
# su - workuser

.sshディレクトリの作成とパーミッションの設定
$ mkdir ~/.ssh
$ chmod 700 ~/.ssh

authorized_keysを新規編集
$ vi ~/.ssh/authorized_keys
クライアントからSCP等で公開鍵をアップロードしても良いのですが、ターミナル上でコピペでも行けるので最初のユーザの場合等はそうしています。あと面倒だからってサーバーでキーペアを作成して秘密鍵をダウンロードするというのはセキュリティ運用上悪いので避けてください。

authorized_keysもパーミッションを適正値に修正します。グループやその他に権限があるとログインできなくなりますので後で慌てる事のないよう必ずチェックしてください。
$ chmod 600 ~/.ssh/authorized_keys

workuserから脱出
$ logout

ここでrootユーザに戻っているはず

次にsshdのログイン方法の設定変更をします。

まずは/etc/ssh/sshd_configの編集
# vi /etc/ssh/sshd_config

以下3行をnoに変更
PermitRootLogin no  
PasswordAuthentication no  
UsePAM no  

1行目はrootでのSSHログインを無効、2行目はパスワード認証を無効、3行目はPAMを無効(多分パスワード認証で使っているものだから不要ということで無効なのかな?)

設定修正が終わったらsshdを再起動します。serviceコマンドでもOK。
# /etc/init.d/sshd restart  

次にsuコマンドでrootに成れるユーザの制限をします。

suコマンドの制限

/etc/pam.d/suの下記のコメントを外す
auth sufficient pam_wheel.so trust use_uid
auth required pam_wheel.so use_uid

サーバー再起動
shutdown -r now

作業ユーザでクライアント認証ログインし、さらに
su - でrootに成れるところまで確認する。

一応作業ユーザ以外にもユーザを作ってみてwheelグループに属していない場合はsuコマンドでのユーザ切り替えができないことを確認する。

さくらのVPSの場合は管理画面にシリアル接続のターミナルがあるのでログインできなくなったらそこから設定の見直しをする。

鍵の管理は厳重に取り扱う

root自体のパスワードを無効化した時やroot権限を使う場合でもrootのパスワードを利用したくない場合はsudoの利用設定をします。sudoもwheelグループだけ使えるように制限します。

visudo コマンドでsudoの許可制限
# visudo  

以下1行のコメントを外します 
%wheel  ALL=(ALL)       ALL

続きは次回に

参考:
yukotan hour: CentOSで特定のユーザがsuでrootに昇格できるよう設定する

myfinder's blog: さくらのVPSを借りたら真っ先にやるべきssh設定

 いつもお世話になっているさくらインターネットですが、VPSの販売をしているのを知って検討してみようと思った。なんせ月額980円からなのでメモリーが心配ではありますがうまく行けばサーバー代を10分の1以下にできるかもしれない。最近専用サーバーを更新したばかりでこの専用サーバも5年目に入るのですがそろそろ危ないかなっと・・・。それに専用サーバーを共用サーバとして組むよりVPSで数の勝負した方が設定が楽というのもある(リスク分散的な意味で)。

さくらのVPS|VPS(仮想専用サーバ)はさくらインターネット
http://vps.sakura.ad.jp/

現在のサーバー費用ですが、専用サーバが113,190円でメールの為に残している旧サーバ(共用レンタル)が15,000円の合計128,190円です。で、現在サービス停止不可なドメインは2つなので2台借りるとすると10,780円×2で21,560円(1つはこのブログのドメインでもう一つは開発用の公開サーバなのでDBを開発側に設置するという分散を考えて)。これならアフィリエイトだけで赤字を防げる気がする。

現在のサーバーの残り期間から、移行は来年の春くらいになりますがCentOSなら自宅で何度も移行シミュレーションできるし、あとはMTのチューニング次第ってところですね。

メールサーバが12月末更新なので多分解約申し込みは11月下旬が期限になるはず、それまでにはメールサービスを移行する必要があるので11月初旬申し込み、中旬に移設作業が妥当かな。無料2週間が契約期間に加算されないのであれば10月下旬申し込みというのもあり。もちろん2台。メールだと対した移設はなくてユーザに事前通知が必要なぐらい。これに関してはアカウント情報の変更内容をVPS借りる前に確定して10月の段階で告知かな。次に12月に入ってからはウェブサーバの移設になりますが、こちらの期限は来年7月下旬なので6月までに移設完了していればOK。軽いサイトから順次移行します。今はIPv4を16個も確保してますが、今のところ公式SSLサイトが無いのでVPSにしても無問題。メールも使いたいとかSSLサイト構築したいといった要望が出たらその数だけVPSを増設すれば終わりw

メールサーバのマルチドメイン・マルチユーザは正直面倒くさい。VPSで安ければリスクヘッジも含めて楽だと思った。

load average 30!

| コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
最初にお詫び申し上げます。時々ご不便をお掛けし申し訳ありません。非常にアクセスしずらいなーと思い気になってサーバーログインしてみたらload averageが30を超えてました。どうもperlが大量に立ち上がって暴走していたみたいですがmod_perlとMT4の相性が悪くて使ってないのと、MT4側に外部からアクセスされるプログラムの一部でパフォーマンスが悪く。DDosでも無いのにサービスダウンに近い状態になってました。

これはどうしようか。MT5に切り替えたら、MT4のスクリプトは全て起動しないようにするかな。。。

 ここ半年ぐらいは64bit版OSが使えるからという理由でVMwareを使っていますが、複数台同時稼動させて通信関連のテストを行おうとするとホストOSが激重になるんですよね。WinXP 32bit版ですけど。(Win7 64bitの方は今のところ大丈夫)。という事でVirtual PCも捨てがたく再インストールしました。んー。

Zabbixとか

| コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
サーバー監視を行う統合ソフトウェアとしてZabbixというのを最近知りました。今まで自作であれこれやってて辛いものがあったのでこれを導入してみようかな。

ZABBIX-JP - Un-Official Support Page
http://www.zabbix.jp/
 ちょっと前に見つけたこのエントリー。一般的に物理的な理由でSSDの方がランダムアクセスにの性能に優れる事をこの実験でも証明されましたが、CPUが先にボトルネックになる程とは・・・。これSSDは速いからって深く考えないで移設したら、JOINが多く非効率なSQLが走った時にサーバーが飛びやすいって事だよな・・・。ユーザ向けのDB等はSSDを利用してレイテンシを下げて、バッチ系は完全に切り離さないとマズいな、予算の問題もあるけど。

HDDをSSDにしたらデータベースはどれだけ速くなるか? オラクルと富士通が実験 - Publickey

スクリプト言語の息の根を止めるのは案外 SSD かもな - kwatchの日記

ここでスクリプト言語がネックと書かれていましたが、基本DBサーバーは運用上分けていたりするでしょ?それにこれはDBが使用するCPUの負荷がボトルネックという事だと思うので、スクリプト言語使ってパフォーマンスが遅いほうが全体として助かると思う。

スクリプト言語でパフォーマンスを上げる方法はいくつかあるし、コンパイル不要で稼動する便利さは手放せないと思いますよ。通常手を加える必要が無いテンプレートエンジンやライブラリはスクリプト言語で書くメリットは少ないからそういうものは積極的にバイナリに変えたりしたいところですね。
本日、ライブドアデータホテルパトロールより、長時間に渡るアクセス障害の連絡を頂き、該当ドメインの調査を進めたところ、開発者向けに提供しているドメインの一部においてDNS障害による名前解決が行われていない事が判明いたしました。

検知時刻:11/27 17:11:57
最終検知:11/27 22:16:46
DNSサーバー1:01.dnsv.jp
DNSサーバー2:02.dnsv.jp

ドメイン 取るならお名前.com
【DNS設定/転送Plus】名前解決不具合の発生

この障害に関する影響につきましては下記の通りとなります。
ウェブサービス:未提供の為、影響なし
メールサービス:対象ドメイン宛のメールでエラーが返されている可能性がございます。

追記:23:53
DNS障害が再発しております。現在も障害継続中。
検知時刻:11/27 23:21:37
お名前.comの告知の更新はありません。

追記:0:57
11/28 0:41:39の検知報告を最後に異常が出ておりませんので0:47を復旧時刻といたしますが、DNSの性質上、完全復旧まで24時間かかる場合があります。(キャッシュタイム24時間に設定しているため)
お名前.comでは0:15に復旧報告が告知されております。

以上でこの件はクローズさせて頂きます。

追記:2:26
検知時刻:11/28 1:46:47
障害がまた再発しているようなのでしばらく様子見てましたが、お名前.comの告知が更新され復旧に至って無いことが確認されました。

緊急対策として

緊急の場合は、外部のDNSサービス("無料DNS","Free DNS" などで検索)などをご利用いただきますようお願い申しあげます。
手順:
1.外部DNSサービスにてレコード設定
2.ドメインNaviにてネームサーバー変更

と紹介されてますがISPのキャッシュDNSじゃあるまいし、そんなにwhoisの内容をコロコロ変えられますかって、伝播のこと考えたら永久変更だな。

ところで何でお名前.comのDNSはプライマリとセカンダリのIPアドレスが並んでるんだ?
ISPならパフォーマンスを上げるためのキャッシュDNSを地域の経路に設定するので同じネットワーク内に入るのは理解できるけど、ドメイン管理会社のDNSとしてはありえない設定じゃないのか?
同一施設においているのもどうかと思うがIPアドレスが並んでいるのはネットワーク上同じ経路を使っているのが確実でタブーというか論外。
再発防止策にこの点の改良が見られない場合は残念ですが別会社に移管の手続きを進めたいと思います。

追記:10:10
最終検知:11/28 6:56:44
現在は正常に稼動しております。お名前.comではサーバー増強による対策を行われたと告知が着ておりましたが、サーバー負荷が主な原因のようです。バックボーンや経路上の装置の障害ではないようですがプライマリ・セカンダリのIPアドレスは並んだままですね。今回は応急処置ということで理解しますが同一施設でのDNS運用は今後のリスクを考えるとお任せできないので週明けにも変更します。

 同じバージョンのMySQLを2台同じサーバーに入れたりというのは開発環境でやったことがあるのですが、双方とも自動起動してバージョン違いかつ文字コード違いという環境は初めて入れた。結論としては自動起動スクリプトがまるで複数導入を想定していないというのが分かったくらいかな。

やってみた構成はこんな感じ。

  • rpm版同士での複数インストール
    これは普通に競合するのでNG

  • 既存のMySQLクライアントとPHP-MySQLコネクタを残して、MySQL公式サイトのrpm最新版(Serverのみ)をインストール
    これも競合。MySQL公式サイトのものはServerとClientで2つに分けているが、RedHat公式のMySQLはServerとClientとその両方で使う無印パッケージの3つ分かれ、無印とMySQL公式のパッケージで競合を起こす。

  • 既存はrpm版で別途ソース版を入れる
    これは問題なし、自動起動スクリプトは改造が必要

  • 既存がソース版で別途インストールもソース版
    問題は無いがソース版同士なので全ての設定を別に分ける必要が出てくる。自動起動スクリプトは改造が必要。
自動起動スクリプトの改造が必要なのは、configureの設定内容を無視しているのでそのまま使えばデフォルトの構造でmy.cnfやpidファイル、sockファイルを探しに行くという恐ろしいワナがある。結局自動起動スクリプト上のmysql_safeコマンドの行に--defaults-file=[my.cnfのパス]で設定が必要。ちなみにこのオプションは最初に記述しないとエラーになります。他にはDBの初期化(mysql_install_db)をするときに既存のDBを破壊しないように念のためバックアップを取った上でオプションでdatadirやdefaults-fileを設定し回避すること。これは理由がわからないのですがスレーブ用に構築する予定のDBで初期化するときに最初からmy.cnfよりbin-logを抜いていたらエラーになった。これは初期化にはバイナリログが必要だったのか、中途半端なコメントがまずかったのかは不明。別に初期化の時にバイナリログが出されてもたいしたこと無いので別に良いのですけどね。

参考

またレプリケーションも本格的に負荷分散しようとしたら参照系で不要なDBやテーブルを持ってきたくないという事がありました。こちらの設定はスレーブ側のmy.cnfの[mysqld]内に
replicate-do-table=dbname.table
replicate-do-db=dbname
といった感じで追記するだけ。

また文字コードの設定で[mysqld]内に
default-character-set = utf8
だけでなく
skip-character-set-client-handshake
を設定するとPHPから接続したときにいちいち「SET NAMES」を設定しなくても良くなるし、他のセクションにdefault-character-setを入れなくても文字コードが統一される(status;やshow variablesで確認)。

[MySQL] 特定データベース、特定テーブルを指定したレプリケーション設定 | 半袖野郎 blog.hansode.org

あと大きなバッチを使うときに気になるのがメモリ使用量なのですが、折角1行ずつ取り出すのに一斉に配列に入れようとするのはセンス無さ過ぎで見つけ次第指導するレベルなのですが、また全件必要でないのにどうせ詮索スピード変わらないからという理由でLIMITを使わないのもメモリの事を考えてない証拠なのでこれもダメ、でもまさかmysql_query関数の結果が一旦全部メモリにキャッシュされるとは思わなかった。PHP上ではどう見てもメモリが溜まるような処理を書いてないのにメモリ不足になるのはこれのせいだった。そのときはmysql_unbuffered_queryを使いましょう。mysql_unbuffered_queryの制約としてはmysql_data_seekが使えないことや全ての行をフェッチする必要があるという事なので件数の絞込みはしっかりLIMITで設定しましょう。スピードは多分遅くなると思いますがバッチ等では消費メモリの上限を抑えられない方が問題なので。

PHP:SQLクエリのメモリ消費量を抑える:mysql_unbuffered_query
 今日はMySQLに対し数千万件のデータ生成バッチを組んでましたが、重複禁止のデータの為主キーにしていたら200万件超えた辺りから見る見るデータ挿入が遅くなる。これは挿入のたびに重複検査するから遅くなるのかとうっかりしてました。それでINDEXなら大丈夫だろうとキーの種類変えて再実行したら主キーのときに比べれば若干マシなのですがそれでも500万件超えると極端に遅くなる・・・。何でだろうとちょっとSELECTしてみたらINDEXのフィールドはソートされるのか!今までメモリにキャッシュしてるだけかと思ってた。こんなのDBエンジニアやシステム開発者では常識なんだろうな。。。結果、INDEXを全く付けないテーブルだと最も速い(挿入以外の処理をしない)事になりますが当然検索や集計には向かないので記録用テーブルと集計用のクローンテーブルって必要なんだな・・・。並べ替え不要な条件だったら速いのならログ関係はタイムスタンプのみINDEX貼って、集計クローンテーブルは集計期間で拾って作成すると効率よさそう。(やってみないと差が分かりませんが)

これはMySQL5.1のパーティショニングを使ったときはどのような挙動するだろうか?INDEXなしは余りパフォーマンスが変わらなくて、INDEX付きが結構速くなり、主キーだとちょっと速くなりって感じかな?
 7月1日(現地時間)にPostgreSQL 8.4がリリースされました。1年5カ月ぶりの新版ということだそうですがMySQLから見るとそれでも早いなぁという印象です。

PostgreSQL 8.4リリース,1年5カ月ぶりの新版は293件の新機能と改良:ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20090702/333088/

 とても興味深い記事です。そういえば「はてな」のサーバーはさくらインターネットに収容してましたね。空調がしっかりしているラックないなら筐体カバーいらないのかな?ボードむき出しのままマウントするのはインパクトあるけどラックマウントは結構ファンによる風が強いはずだから冷却効果が凄そうだ・・・。

1Uラックマウント可能なサーバを自作する - marqs blog
http://d.hatena.ne.jp/marqs/20090622/1245670553

[PR]さくらインターネット×はてな、自作サーバを語り合う - はてなブックマークニュース
 先週から不用品等整理してコンパクトにしようとしているのですが、PC等も整理したほうがいいかな?っと思い10U程度の19インチラックを買ってスッキリその中に纏めるのはどうだろうと検討中。というかメインがノートPC使いなのでプリントサーバ代わりにしか使わないデスクトップはもういらないんですよね・・・。あとバックアップもビデオなんて撮ってるとDVDなど光ディスクでは全然足りないのでRAID1のNASとかあったほうが良いかな・・・など考えてます。

☆サーバーラック 19インチ☆「サーバーラック ラックマウント」格安販売激安特価価格 小型 耐震 防音

ここでサンワサプライ製のラックが安く売っているので、ここでラックを購入して、デスクトップPCが必要なら

ラックマウントケース - HEC Online shop

こちらでケース買って乗せ変えようかなとか考えてます。ちなみにNASは

“TeraStation PRO” RAID機能搭載 NAS ラック対応タイプ|TS-RHTGL/R5シリーズ

ラックマウント型のTeraStationを検討しています。

PCを4Uにすればあまり奥行きの無いラックでもよさそうだけど、Linux用とWindows用積んだらそれで終了というのも悲しいので奥行きも確保して2Uにしようかな?ラックマウントのLinuxサーバ導入するかどうか未定ですがするとしたらUPS内蔵静音電源搭載にします。んで木製の自作ラックはポイッっと。
 一部サービス再開からは特に状況を追っていませんでしたが、最終的に99%以上のデータ復旧ができて停止したサービスも再開できていたんですね。担当の方は大変苦労されたと思いますが、この経験は今後の障害対応に役立つものと願っております。

2月に障害発生の「Doblog」。5月30日をもってサービスを終了
http://internet.watch.impress.co.jp/cda/news/2009/04/24/23277.html
 核燃料庫だった所をデーターセンターに改装して出来たそうです。水爆にも耐え、予備電力も潜水艦用のものを使用するため停電があっても暫くは大丈夫らしい。それにしても綺麗な秘密基地みたいだ・・・。

映画に出てきそうな地下データセンター - GIGAZINE
http://gigazine.net/index.php?/news/comments/20081117_super_designed_data_center/

データセンター関連で探したらこういうのも見つけました。コンテナラック?ともいうのかな。

マイクロソフトの考える屋根がない衝撃的な第4世代型データセンター構想 - GIGAZINE

スケーラビリティと設備投資の計画の立てやすさで今後増えそうですが、平地の少ない日本じゃ難しいですね。そういえばニコニコ動画ってもうデータセンターにサーバー置くスペース無いって言ってましたね。動画は安定した帯域確保するのにも大変でしょうから、2ちゃんねるみたいにアメリカにサーバー設置というわけにも行かないような気がする。

さすがGoogleは賢い、私が自宅サーバーにノートPCを使うのも同じ理由でUPSでバックアップ電源を統合するよりも個々にバッテリーを置いたほうが安全なんです。社内にサーバーを設置しているところでUPSを取り付けているところを何箇所か見たことありますが、設置の仕方に問題あるところの方が多かったですね。UPS自体容量も出力も有限なのにディスプレイ含めてサーバー何台も繋いでいるとか、UPSのバッテリーに寿命がきてしまったばかりに電源障害を起こしそれにぶら下がっているサーバー全台計画停止などUPS自体がボトルネックになるような運用されているところがありました。

個人的意見としては外部UPSはルーターやHUB等あまり電力を消費しない組み込みネットワーク機器のバックアップ電源として統合して停電時でも通信を継続できるようにし、サーバーは個々にUPSを用意してリスク分散をするのが良いと思います。ディスプレイは基本UPSいらないでしょ。

実はUPSは小分けしたほうが電源容量あたりのコストパフォーマンスも良かったような気がします。デスクトップPCでもアキバに行けば5インチベイ内蔵型で直列タイプのバッテリーがあるのでそういったものを利用するのも良いと思います。しかも外部UPSより安い。

記事では変換効率の上でもパフォーマンスが良いことを上げられていますが確かに内蔵型であれば一往復分のAC/DC変換を省略できますからね。あとスペースもかなり省略できる。

Googleのサーバは12Vバッテリを搭載 - スラッシュドット・ジャパン

Google uncloaks once-secret server | Business Tech - CNET News

Googleの検索エンジンはgrepってホリエモンこと堀江貴文さんのブログにちらっと書かれてました。あれはそうだとしたらホントに目からウロコ。

追記:2009/04/06
翻訳記事がありました。
グーグル、自社設計のサーバを初公開--データセンターに見る効率化へのこだわり:スペシャルレポート - CNET Japan
http://japan.cnet.com/special/story/0,2000056049,20390984,00.htm?ref=rss
3年半程前に構築したメインの自宅サーバーが完全に故障してしまった。正確にはメインは半年前に故障していてHDDを半壊状態のサブサーバーと交換して騙し騙し使っていましたが、そのサブサーバーもダメになった。どちらもマザーボード故障。MMO Project用に構築した開発向けサーバーがこれで完全にぶっ飛んだという事です。。。ドメインやメール関係は外部のレンタルサーバーに移設済みなので実質的な影響はないのですが。しばらく開発環境はVirtualPCでなんとかしてその内VPS用にハードウェア一台購入することにします。
 ke-tai.orgサイトより。auのIPアドレス帯域に変化があったとの記事がありました。
確か去年凄い細分化されて設定が面倒だった記憶がありますが、多分移行を行っていたのかもしれません。

 今回はルールの削除ということで突然携帯からアクセスできなくなるわけではないのでそういう意味で緊急の対応は必要ありませんが、同じサイト内でIPによるPC/携帯割り分けを行っているサイトが対応が必要になりますね。

ke-tai.org > Blog Archive > 2009年3月10日付けでauのIPアドレス帯域に大幅な削除があったようです
http://ke-tai.org/blog/2009/03/10/auip20090310/

アーカイブ