パスワードを忘れた? アカウント作成
12199869 story
インターネット

データセンターのサーバーのうち、3分の1はゾンビサーバー 47

ストーリー by hylom
納得できるようなできないような 部門より
taraiok 曰く、

米国環境保護庁のデータセンターのエネルギー研究を行っている研究者グループによると、データセンター内にある4000台の物理サーバのうち30%が昏睡状態か、または動作はしているものの、有用な情報を配信していないことが判明したという。なお、昏睡状態とは6か月間何も行っていないことを差しているという。注目すべきなのは、2008年に行われた別の企業による調査結果でも同様に30%のサーバーが昏睡状態にあるという結果が出ていること(COMPUTERWORLDSlashdot)。

天然資源防衛協議会(NRDC)の2014年の調査によると、2013年のデータセンターの電気使用量は910億kw/hであったという。米国ではデータセンターの需要が2020年には53%増加すると予想されている。前述のようなゾンビサーバーへの対処を行えばエネルギー効率は40%ほど改善する可能性があるとしている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2015年06月23日 13時04分 (#2835573)

    大抵は未就職のニートじゃなかったモラトリアム・サーバなだけですよ。
    中にはリタイア後のセカンドライフ待ちなサーバとかもいますが。
    ましてや待機任務な人は立派に就職してるんだからゾンビ扱いとか酷い。

    # ゾンビというのは
    # 壊れて無反応なくせにリモートから電源落とせなくて電気だけ喰うのとか
    # 撤去予定で電源落としたはずなのに、いつの間にか勝手に起動してくるやつとか
    --
    クラウド事業者的な感想

    • タイトルだけ見て、botの温床が1/3もあるのかと思った。
      そんな事態なったらデータセンターが異常だな。

      親コメント
    • セカンドライフ [secondlife.com]のサーバがゾンビな訳じゃないのね。

      停電のタイミングでシャットダウンしていく時に、このサーバ何?>もう使ってないやんけ!ってのは時々ありますよね。
      付けっぱなしだった間の電気代を考えると……空調より涼しくなるという。

      親コメント
    • by Anonymous Coward

      問題にすべきはモラトリアム状態(?)のサーバーの待機時消費電力をいかに減らすべきかでしょうね
      場合によっては必用になった時点で電源オンにすれば良いのでしょうし
      #本当に即起動のホットスタンバイが必要なものってどの程度の割合?

    • by Anonymous Coward

      GC的には既に到達不可能になって「お前は既に死んでいる」ことも判明しているけれど、
      まだ回収されてないオブジェクトをゾンビオブジェクトって呼んでた。(と思う。)
      #C言語風に言えば、既に死んだことが確定してるけど、まだfree()されてない領域。

      そういうオブジェクトは死亡確定なので、後で使いたいと思っても新しくnewする以外に手は無い。

  • by ymasa (31598) on 2015年06月23日 12時09分 (#2835534) 日記

    スタンバイはゾンビに含まれますか?

    あと気になるのはどのくらいの能力を使っているかですね。
    100台で各10%ならば20台で50%で済むじゃないか?80台眠らせ!とか。
    (実際過負荷に陥ったら落ちますけど)

    冗長性っていろいろ犠牲にしてますよね。

    • by Anonymous Coward on 2015年06月23日 13時34分 (#2835593)

      「(エコを推進する)部外者から見て活動していない」ってだけですからねぇ…
      コールドスタンバイや負荷追従起動するシステムが6ヶ月間安定状態を維持したらゾンビ扱いだし、
      システムの更新に前後して使用する予備機や、特に役割はないが障害対応用に待機してる機器もゾンビ扱いの筈。
      であれば「突発事象は考慮せず予備率0%になるまで切り詰めるべきだ。突発事象が起きたら後は知らん」みたいなアホな理論と大差無い。

      全部クラウドにぶち込んどけばクラウド内で予備資源を融通しあって全体のスタンバイ量は減らせますが、
      預けるというリスクと業界全体で同時多発的に予備資源を消費する事態がが生じるとやはり死んでしまうわけで。

      電源切れてるスタンバイ含めて30%なら割と良い塩梅なんじゃないかと思う。

      親コメント
    • by matlay (32743) on 2015年06月23日 15時33分 (#2835680) 日記

      >冗長性っていろいろ犠牲にしてますよね。

      知ってて書いてるとは思うのですが、自己言及型ジョークですねそれ。

      #自己書き換えコードとか再帰処理とかとの親近感というかそういう感じがあるので、プログラマのジョークはそうなる傾向にあるのかもしれない
      ##自己書き換えコード=凡人プログラマのあこがれ
      ##再帰処理を変換しようとしたら、催奇処理となった。ちょっとそのままにしとこうかと思った。

      --
      #存在自体がホラー
      親コメント
    • by Ryo.F (3896) on 2015年06月23日 16時13分 (#2835714) 日記

      なので、2台1セットでactive-standby構成にしてたものを複数セット統合してstandbyを減らせるとか、そう言うものをサービス化して提供するクラウドができたわけですね。

      せっかくクラウドで見えなくしたものを、要らんこと「見える化」(苦笑)なんかするからいかんのですよ。

      親コメント
  • 何割かは必ず怠ける (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2015年06月23日 12時19分 (#2835540)

    働き蟻の何割かは常に怠けていて、
    その何割かを取り除くと、今まで働いていた蟻が怠け始めると言う話を思い出した。
    昏睡状態のサーバーも、なくしたつもりが新たに発生したりして。

    • by Anonymous Coward

      パレートの法則 [wikipedia.org]、もしくは2・6・2の法則ですね。

    • by Anonymous Coward

      人間が設計、運用している以上2:8の法則や2:6:2の法則に従った
      働きになってしまうのは、ある意味必然でしょう。

    • by Anonymous Coward

      不当マイナスモデしたい。
      別コメントにあるとおり、この無駄は人間の設計力の限界なんじゃないだろうか。

      • >この無駄は人間の設計力の限界なんじゃないだろうか。

        そらまあ、その通りで、可用性を確保する手段として冗長化する(無駄を作る)事を選択したというのは(理屈では)可用性を確保する手段として一番合理的なのがそれだったという事で、
        それ以外の手段を用意するには人知を超える設計力が必要という意味では人間の限界ではあるよ。

        言い換えると、未来に対しての正確な予測を行なって、それに対して過不足ない設計を行う事は神様にしかできん。

        --
        #存在自体がホラー
        親コメント
        • by Ryo.F (3896) on 2015年06月23日 23時30分 (#2835990) 日記

          今回の「昏睡」の定義なら、冗長構成で昏睡サーバ0は、人智の範囲で実現可能なのでは?
          例えば、一台当り稼働率60%の(物理)サーバ三台でシステムを構成すれば、一台故障時に他の二台で肩代わりしても、一台当たりの稼働率80%で、システム全体の仕事量はこなせてる計算。

          ま、実際にはそう上手くいく場合ばかりではないわけですが。

          未来の予測に関しては、もちろん同意。
          人智では完全な予測は不可能。

          親コメント
          • by Anonymous Coward

            ロードバランスに参加しないバックアップ(フェイルオーバー用の各種スタンバイ)はほぼ全てゾンビですよ。
            コールドスタンバイは無論、ホットスタンバイや試験用のサーバも通常状態なら配信無しにカウントされうる。
            メンテナンス時の作業用空きラックに交換用の予備機とか詰めたらそっちもそれだけで昏睡にカウントされます。
            大規模なシステム更新後に一定期間残すだろう旧システムなんかも当然カウントされる。ゼロは無理でしょう。

            ホットスタンバイ以外をDCから追い出したところで「トヨタは在庫を持たない代わりに道路を倉庫代わりに使っている」
            みたいに別のところにそのバックアップが押し付けられたり、有事の際に毎回長時間システムが止まるようになってもねぇ…

            全バックアップをロードバランスに参加させるとかリスキーにしか思えない。形だけの参加とかもエコ云々含め本末転倒

            • by Ryo.F (3896) on 2015年06月24日 21時43分 (#2836531) 日記

              ロードバランスに参加しないバックアップ(フェイルオーバー用の各種スタンバイ)はほぼ全てゾンビですよ。

              その通りですね。

              で、私の主張は、物理サーバレベルであれば、ロードバランスに参加しないバックアップサーバをゼロにすることができる、と言うものです。
              よく読んでみてください。

              メンテナンス時<<略>>ゼロは無理でしょう。

              この辺りはおっしゃる通り。私が

              ま、実際にはそう上手くいく場合ばかりではないわけですが。

              と書いた理由の一部がそれらです。

              親コメント
        • by Anonymous Coward

          ちがうちがう、冗長性を確保する設計という意味ではなく、
          人間の仕事は必ず2,3割は無駄になるということ。
          その無駄は、保険や計画性のあるものではなく、
          頑張って効率的に設計したけれども、あてが外れて無駄になったもの。

          • で、そのあてが外れたを許容しないというのは神様にしかできんだろうと。
            #ユダヤ教かな?それ以上にキツイ神様っているかな?

            ちょっと話がずれますが、

            冗長性のために用意した○○の量の無駄の○○%が意味のない無駄だと断言するという事は、
            そのシステムが許容するリスクを算定した結果、100-○○%しか必要ないはずだとその人が判断するという事で、いや、そのシステムの担当者の仕事をしていただいてありがとうございます。という話です。
            #それを判断できるのは個々のシステムに対しての責任者しかいないはず
            ##提言までならありかな

            --
            #存在自体がホラー
            親コメント
  • by Anonymous Coward on 2015年06月23日 12時14分 (#2835539)
    Sleepig Duty ですわよ

    # Principal の熱い kick で目覚めます。
  • >前述のようなゾンビサーバーへの対処を行えばエネルギー効率は40%ほど改善する可能性があるとしている。

    多分、この結論を出した人は「保険」という概念を知らないと思う。
    #さすが米国人という事....か?
    ##日本は保険大国らしい。まあそうだな。なるほど、システムに関する考え方にも相関関係があるのかもしれない。

    --
    #存在自体がホラー
    • s/インシュアランス/インシュランス

      恥ずい....英語が苦手でごめんなさい。英語で書けばよかった(事前に確認するから)
      ごめん、フレーズの印象だけで実質はあまり考えてませんでした。
      あまりブラックジャック詳しくないので。

      ただ、一般的に戦略というものを構成する要素の中に「保険」というものがあるんだと言いたかったぐらいの事です。

      --
      #存在自体がホラー
      親コメント
    • by Anonymous Coward

      ブラックジャックのインシュランスはかなり限られた条件じゃないと期待値マイナスだそうですが。
      何が何でもその場の損を減らさなきゃならない状況か、カードの期待値が余程偏って無ければ無意味です。
      その場での損益期待値は減るけどそれ以上に利益の期待値も減る。保険の例としては不適切ではないかと…
      一般的な保険は「その場の損」が圧倒的だけど、普通のギャンブルなら期待値見たほうが良いと思います。

      # それはそれとして、保険と無駄の区別がついてないという意見には賛成。

  • by Anonymous Coward on 2015年06月23日 12時26分 (#2835545)

    無駄を省いて余裕0にすると突発的に負荷がかかった時などに全てご臨終してしまうのでは?

  • 利用頻度の低いサービスだって、必要なときに即座に使える状態でスタンバっているのは重要だと思うが。

    • by Anonymous Coward

      おっしゃるとおり。
      ただ、データの破棄を定期的に行わない限り、昏睡状態のデータは増えてゆく一方。その保管・運用コストやエネルギーロスは増えてゆく一方になります。
      今後インターネットを通じたデータ取得でも、「このデータは磁気テープに保存されているので、手続きを行った後30分後に閲覧可能になります」みたいな状況を許容できるかどうか?
      利用頻度が低下した過去のデータに関しては、何らかの割り切りをするしか無いように思う。もしくは何かの画期的なソリューションを期待するか。

  • by Anonymous Coward on 2015年06月23日 12時48分 (#2835563)

    動作はしているものの、有用な情報を配信していない

    特定の時期になると極東の島国からひたすら滅びの呪文 [google.co.jp]が投稿されるサーバの事ですか?

  • by Anonymous Coward on 2015年06月23日 12時51分 (#2835565)

    わからないやつが多すぎるんですよ。
    特に経営者とか株主とかにね・・・

    • by Anonymous Coward

      あと逆の意味で
      営業とか中途半端な技術者とかもね

      #中間は中間でこれたまた板挟み

  • by Anonymous Coward on 2015年06月23日 13時14分 (#2835579)

    データ収集をしてたり、他のサーバに保管されてるデータのマイニングをしてるのはゾンビに入るの?

    • by Anonymous Coward

      それは「昏睡状態」にはあたらないでしょ

      > 昏睡状態とは6か月間何も行っていないことを差しているという

      • > 昏睡状態か、または動作はしているものの、有用な情報を配信していないこと
        多分シャットダウンされているものが「昏睡状態」で、
        コールドスタンバイしてるシステムが「有用な情報を配信していない」扱いでしょうね。
        バックエンドとして動いているサーバも含めたら30%では利かないだろうから、
        恐らくトラフィック(もしかすると上り限定)が発生しているかが基準だと思われます。

        コールドスタンバイ、幾らかのホットスタンバイ、設備更新や障害対応用の予備機、
        演算主体でトラフィックの小さいシステム、辺りもかなりの数がゾンビにカウントされてると思いますよ。

        • by Anonymous Coward

          シャットダウンしているのがエネルギー効率と何の関係があるの?
          まさか質量持ってるからエネルギーの無駄とか言わないよね?

        • by Anonymous Coward

          > コールドスタンバイしてるシステムが「有用な情報を配信していない」扱いでしょうね。

          いや、もと文は「動作はしているものの、有用な情報を配信していない」と書いてあるのだけれど。
          コールドスタンバイでも動作していると言い張るリース業者の方ですか?

  • by Anonymous Coward on 2015年06月23日 13時40分 (#2835596)

    旧基幹システムのデータをたまに見たいために残してるとかはどうでしょうね?スタンバイさせておく必要があるかどうか。データセンターじゃなくて手元に置いたらいいかもしれない。

    サーバーに限らず通信機器は一般家庭でもありそう。ISDNのTAが何するもんだかわからず光にした今でも電源だけ刺さって他ケーブルすべて抜けてるのに残ってるとかね。

  • by Anonymous Coward on 2015年06月24日 14時25分 (#2836296)

    年末データベースをリプレースしたのですが、半年過ぎてなお旧サーバがラックに残っています
    ラック内にまだ稼働中の機械があるので、ケーブルを解いて、機械を取り出して…なんて工事はしたくないし
    シャットダウンしたけどIPMIはそのままだったなぁ

typodupeerror

あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall

読み込み中...