また、32bit用バイナリって実はあまり最適化がかけられていないことが多い。自前で、自分のマシン専用にリコンパイルしたのなら話は別だろうが、大抵の場合、出来合いをそのまま使っているだろう? 出来合いの32bit用バイナリは、可能な限り多くの種類のマシンで動かせるようにしなくちゃいけないので、実はかなり古いCPU用にチューンされていたりする。あまり効果的な動き方はしていない。 これに対して64bit用バイナリはCPUの種類がまだ32bitほど多様ではないこと、一番初期の64bit CPU でさえも持っていた機能が多様に存在すること、などから出来合いであっても比較的効率よく動作するバイナリが提供されている。
ついでに、時代遅れな distribution とかは捨てる。新しいCPUをちゃんと使いこなせるのは最新の distribution です。Core i7 に RHL 7.3 とかそういう馬鹿な組み合わせは使わない(いるんだよ、これが… orz)。
そこで、まずは 64bit 化してしまう。で、真面目な計測をここから始める。
-----
消費電力をサーバー単位で計測する。で、それと同時に sar の出力結果(もし Linux とか Solaris とか HP/UX とかを使っているならきっとあるだろう。無いマシンでも似たような出力は得られるはずだ)を取っておく。 断っておくが、32bitで計測した結果なんぞ何の役にも立たないので、「32bit⇒64bit移行と、電源最適化を同時に」なんぞと考えてはいけない。32bitの世界と64bitの世界は全く別の世界だと考えるべし。
そんな事言われても一律じゃないもの… (スコア:1)
まず、自分の所のサーバーがどのように動いていて、何で電気を食っているのかを調べること無く戦略を立てようとしても、それはほとんど無理。
ほとんど何も把握せずにやれることは、まず、32bit OSで動いているものを、全部64bit化しろ辺りでしょう。一台として残しちゃ駄目。全部。有無をいわさず。メモリは可能な限り大容量化できるようにチップセットを選ぼう。
サーバーは大抵4Gbyteとか8Gbyteとか「以上の」メモリを搭載している。しかし 32bit OS は kernel 用に 1Gbyte とか 2Gbyte とかしかメモリを使えない。「kernel の使う仮想空間」や「アプリケーションの使う仮想空間」のサイズよりも「物理空間」の方が広いと、どうしても『ベスト』な割合でメモリを使うことができないのだ。だから、いいからとにかく64bit 化しろ。エンドユーザーのPCじゃないんだから。
また、32bit用バイナリって実はあまり最適化がかけられていないことが多い。自前で、自分のマシン専用にリコンパイルしたのなら話は別だろうが、大抵の場合、出来合いをそのまま使っているだろう?
出来合いの32bit用バイナリは、可能な限り多くの種類のマシンで動かせるようにしなくちゃいけないので、実はかなり古いCPU用にチューンされていたりする。あまり効果的な動き方はしていない。
これに対して64bit用バイナリはCPUの種類がまだ32bitほど多様ではないこと、一番初期の64bit CPU でさえも持っていた機能が多様に存在すること、などから出来合いであっても比較的効率よく動作するバイナリが提供されている。
ついでに、時代遅れな distribution とかは捨てる。新しいCPUをちゃんと使いこなせるのは最新の distribution です。Core i7 に RHL 7.3 とかそういう馬鹿な組み合わせは使わない(いるんだよ、これが… orz)。
そこで、まずは 64bit 化してしまう。で、真面目な計測をここから始める。
-----
消費電力をサーバー単位で計測する。で、それと同時に sar の出力結果(もし Linux とか Solaris とか HP/UX とかを使っているならきっとあるだろう。無いマシンでも似たような出力は得られるはずだ)を取っておく。
断っておくが、32bitで計測した結果なんぞ何の役にも立たないので、「32bit⇒64bit移行と、電源最適化を同時に」なんぞと考えてはいけない。32bitの世界と64bitの世界は全く別の世界だと考えるべし。
複数のマシン間で「逆相関がある」サーバーを探す。Aと言うサーバーとBというサーバーが同期して up/down しているなら、仮想化したら悲惨なことになる。Aというサーバーの消費電力が上がるとき、Bというサーバーの消費電力が「下がってくれなくちゃいけない」。そういうサーバーが見つからないなら、もうその段階で「仮想化による統合」はやめたほうが良い。
# いや、逆相関があっても「単にサービスを2つ動かすだけ」なら別に仮想化しなくても、
# メモリを多い目に奢ってあげた新マシン1台に統合するだけで十分だしな。
# 仮想化を考える前に、同一マシン上に複数のサービスを単純に統合することができないか、
# できない理由はなにか、よく考えたほうが良い。今ある環境を単純に仮想マシン上に移行して
# べチョーっと動かすだけでは、どのみちろくな消費電力改善にはならない。
次に、swap IO や page IO を消費電力向上が同期しているものを見つける。こういうマシンは、とりあえずメモリの搭載量を増やす。これ以上増やせないマシンだ~と言う場合は「新しいマシンを買う」。swap IO が少ない時の CPU の張り付き具合とご相談ではあるが、大抵の場合CPUはそんなに必要ない。それよりRAMだ、RAM。disk IO に比べたらRAMの消費電力なんてカスみたいなもんだ。そして、RAM 上の file cache はストレージIOを圧倒的に減らしてくれる。
データIOが、大きなブロック単位で動作しているもの…例えば DBMS とか…の消費電力を見る。disk IO と消費電力が同期していて、なおかつ disk IO の際の消費電力量が全体の 30% 以上になっていないか? なっているなら HDD を SSD 化する。HDD に比べて SSD は容量が 1/4 ぐらいだが、消費電力は 1/10 ぐらいだ。なにしろ head seek を伴わないので、電力消費的には msec オーダー対 10usec オーダーと 1/100 ぐらいしか消費量の大きいタイミングがない。お値段がブッ飛んでるのが問題だが…そこは緊急時だってことで、予算を割り当ててもらおう。RAID とかの場合は、ベンダーに SSD 製品がないか尋ねる。今時、大抵の製品が、そのラインナップの一部にSSD化製品を持っている。そいつでどれぐらい電力を消費するのか、見積もってもらう。大抵のメーカーは、この手の動作シミュレーターを持っているものだ。
ただし、DBMSのredo logとかは書き込み頻度が高すぎてSSDだとあっという間に壊れるかもしれない。この辺の見極めは注意が必要だ。
Bootdiskをちょっと見てみよう。OSが入っているdiskだ。起動時に大量のIOがあるのはいいとして、それ以降どれぐらいIOがある? swap IOが必要なくなるぐらいRAMを搭載したら、かなりIOが減っているはずだ(/var/log/messages とかがあるので、それでも0にはならないだろう)。それは SSD じゃ駄目か? 待機時の消費電力が小さく、IO量が少ないストレージはSSD化するのが一番だ。
FlashROM boot でも…と言いたい所だが、FlashROMの大半は常時通電された場合に熱的に耐えられない。大丈夫な製品を知っている場合をのぞいて、やめたほうが良い。2.5inch型のSSDとかBlade X-gale [toshiba.co.jp]とかを考えるべきだ。
-----
一度、ここまでの最適化を図る。で、次のフェーズに移る。
つまり、計測のやり直しだ。
今度は「消費電力」と「サービス」と「温度」の関係を見る。そのためにサーバーのアチラコチラに温度センサーを着けて、温度を計測しながら消費電力とサービスとの関係を見ていく。最悪でも、ラックの空気の吸気口と排気口の温度は調べよう。
基本的に「消費電力」が上がれば「温度」も上がるはずだ。が、具体的にはどのような温度になるだろう??
別の言い方をすると、あるラックと別のラックが同じ温度の空気を吸入しているとして、排気している側の温度も同じような温度になっているだろうか? なっていないとするなら、それは何故? 温度が低いラックにはまだ余地があったりしないだろうか?
ラックの排熱分布が均等でない場合、マシンルームへ供給する空気の温度は 最悪値に合わせなくちゃいけない。だから発熱量がなるべく均等化するようにラック内サーバー/サービスの組み合わせを考えたほうが良い。ようするにラック間での消費電力差が常に大きくならないようにしつつ、時間方向でも大きく up/down しないようにする、ということだ。
ラック間消費電力差が小さくなると、どのラックであっても「同じ温度の空気」を入れたら、「ほぼ同じ温度の空気」が出てくる事を意味する。これはつまり冷却用の空気を過剰に冷却しなくても良くなる、ということだ。大抵のサーバールームの温度設定はラック間のバラつきのことを配慮してかなり余裕のある温度設定になっている。ばらつきを均したら1℃ぐらい温度が上げられるようにならないかい? 日本のように多湿な国では1℃の差は、「潜熱をどれぐらい汲み上げるか」(除湿のためにどれぐらい過剰に冷却するか)の差となって現れる。なので「乾燥空気を1℃余計に冷却するために必要な電力」よりもかなり大きな差が出るはずだ。
消費電力を下げる努力は「全体として」であって、サーバー単位で削減するのではない。だからこういうばらつきに伴う過剰品質を、ばらつきを抑えることで削っていく、というのも手なのだ。
ここまで見て、10%以上電力消費量が下がっていないとするなら、そのデータセンターは凄い。
最初からかなり良く考えられて作ってあるか、問題点は色々見つかるが諸事情で全然手がつけられないほど悪質か、どっちかだからだ。どちらの意味なのかは判らないが、とにかく凄い。手ごわいのは間違いない。
-----
ファイルのIO量を考えよう。IO量の多いファイルとIO量の少ないファイルを、同一性質のメディア上に置いていないか? IO量の多いファイルは HDDなら 15000rpmのSASで構成されたRAID上にあるのが良いだろうが、IO量が減った(つまり、ほとんど参照されていない)ファイルまで 15000rpmのSASでできたRAID上に残っているとしたら、それは勿体無い。5400rpm SATA でできたRAIDであれば、回転数が低いだけでなくHDDの消費電力も小さいし、容量も大きい。より小さな消費電力で多くのデータを保存できる。
ストレージベンダーと呼ばれる所は大抵、複数メディアを仮想化して自動的にファイルを再配置する機能を持った製品を揃えている(「ファイル」を最適化配置するものなので、RAID製品にはない。NASとか、サーバーOSに対するカーネルモジュールの形を取る)。
もし、ファイルの利用状況を考慮せずに「ごちゃ~~~~~」と保持しているのであれば、そろそろファイル配置の最適化を考えるべきだ。全体としては、高速でbit当たりの電気消費量が多いディスクを減らして、低速でbit当たりの電気消費量が少ないディスクに置き換える。この仮定でディスクの総数自体も減らす。
UPSの入出力と、サーバーの電源の種類を調べてみよう。
UPSの出力にDC出力がないだろうか? サーバー側の電源の入力にもDC入力がないだろうか?
ご存知のようにサーバーの電源はAC/DC変換を行う。こいつの効率は、消費電力が小さければ小さいほど効率が悪い。逆の言い方をすると、1つのUPSが4台のサーバーに電力を供給している場合、UPS側でAC/DC変換を行うほうが、各サーバーの電源でAC/DC変換を行うよりも効率が良い。
あまり例はないが、こういうUPSを買っている場合は、UPS・サーバ電源をセットで置き換えると、10%ぐらい電力効率がアップする場合がある(カタログスペックとかでは 15% とかの数字が踊っている場合もある。が、そこまでは期待するべきじゃない)。
-----
ここまで検討して、それでも全然足りないなら、その時は「待機系」を Hot Standby から Cold Standby にできないか、考える。ここで重要なのは、「待機系」はメイン側がダウンしたときに仕事を引き継ぐために「待機」しているということだ。待機系が立ち上がるまではサービスは止まってしまうので、いかに待機系を早く立ち上げるかが勝負になる。発想点は2つ。
1) 既出だが、Boot media を SSD 化して起動を1秒でも早くする
2) メイン系がダウンするのを待たずに切り替える
1 は判ると思うので主な説明は省略する。が、この場合さらにポイントは2つあって、
a) 待機系が十分早く立ち上がってサービスアップしてくれるなら、Hot Standby じゃなくてもいいよね、が正しいぐらい、時間的余裕があるか?
b) で、メイン系が落ちたことを誰が検出して、どうやって Cold Standby の起動をkickするの?
という点だ。この場合、監視系として小さなマシンを1つ動かしておく必要がある。実体としてはOpenBlocks程度の規模でいいのだが、こいつに定期的にポーリングをかけさせ、メインが動いていないとなったらサブを切り替え、メインの電源を落とすようUPSを叩くプログラム等を組む必要がある。
なお、死活監視でpingを打って終わり、と言う奴があるが、ICMP ECHO REPLYなんぞ kernel の割り込みハンドラーだけで処理が終わる。kernelが割り込みハンドラー内部で暴走していない限り、pingだけでは「相手がもう墓に入った後なのか、まだゾンビのようにうろついているのか」程度しか判らない。ちゃんとサービス判定は真面目に考えるように。
ポイントは 2 だ。サーバーにはダウン前に色々な兆候が見える時がある。温度が上がる、IO error が増えるなどのハードウェア障害。kernel の slab 消費量が増える、user process が消費する仮想空間が巨大化するなどのソフトウェア障害。これらを可能な限り検知して、本当にシステムがダウンする前に待機系を立ち上げ、そちらにサービスを移行してしまう。メインで動いていた側は障害兆候として dump などを収集した後に電源を切ってもよいし、rebootさせた後、待機系からサービスを再度引き継ぎ直しても良い(この場合は待機系は再び Cold Standby に戻る)。
日本のユーザーのほぼ全てがこれを全くやらない。できるものについてもやらない所が多い。でもこれは検討するべきだと思う。少なくとも「待機系を電源断するだけ」よりははるかに安全だ。
似たような発想に「サービスを提供するマシン」の計画的統廃合がある。ようするに、あまりサービスしなくて良いと解っているタイミングでは複数のサービスを1つのマシンに「切り替え」、そうじゃなくなりつつあるタイミングで別のマシンに「fail over」する。仮想マシンとかでもできるが、仮想化の段階でそこそこマシンパワーを食うので、計画的に切り替えられる場合は、自前のスクリプトとかで切り替える方が簡単だし省電力だ。
-----
とまぁ、この程度は大抵のコンサルタントが考えてくれるだろう。問題は、「GW明け」に検討を開始して間に合うか、ということの方だろう。
ちょっと苦しいんじゃないかなぁ、だって他の会社も皆同じ結論に到達するよ??
fjの教祖様
サーバの負荷を軽くするため、 (スコア:0, おもしろおかしい)
とりあえず、コメントを25%カットするところからやってみようか。
Re: (スコア:0)
Re: (スコア:0)
テムレイがあの回路を片手に熱弁しているのを連想した。
#okky…酸素欠乏症に…
Re: (スコア:0)
fjのdeus様を思い出したり
Re: (スコア:0)