アカウント名:
パスワード:
DCでの事故原因として電源がよく上げられるけど、改善されない要因ってなんだろう。
・電源なんてあって当たり前なので管理がいい加減のまま。・不安なので多重化しててもやっぱりどっかで事故っててきりがない。・実は他に原因があるけど言い訳(スケープゴート)にされやすい。・掃除のオバちゃんが黒幕。
電源周りは経年劣化が防げないので、お金と冗長性のトレードオフの結果じゃないでしょうか。データセンターの管理者とサービスのプロバイダーが同じで、ユーザーが多少我慢してくれるような所だと、金をケチって時々サービスを落としたほうが得なんだと思います。
でかい共用のデータセンターだと冗長性の規格があって、電源系統の冗長性や、受電設備-ラックUPS系統の冗長性、サーバーUPSの冗長性から施設の耐震性能に至るまでの要求事項が決められています。そして、こういった要求事項を満たしているので、統計的に年間の無電源時間をx時間以内に抑えられるはずだというのをユーザーに保証しています。
世間ではこの件でギットは信頼性が低いって風潮ですが
分散型のヴァージョン管理システムで、特定サーバの信頼性が云々って、限定的にしか問題にならないのではないかと思うんですけどね。最終的には、大本の所との同期が取れたらいいので…
githubにホスティングやバックアップ機能を完全に依存してれば確かに問題ですが、ユーザが複数いるような場合には、確かに同期を取ればいいだけの話のような(；´Д｀)
それでも不十分となったら、別のサービスで多重化した方がいいでしょうね。（と言うか、前々から一個のサービスでの公開だとこの手の障害ならまだしも、洪水とか爆発事故とか地震とかのもっと壊滅的な物理的障害には脆弱なので複数サービスに登録しようか迷ってはいますが）参考：http://www.find-job.net/startup/5-git-hosting [find-job.net]
「限定的にしか問題にならない」のと「今回の障害で信頼性に疑問が出てる」のは全然別の話
商用サービスとして売ってるんであれば、少なくとも完全に停止するような障害は避けるべきだと思いますよ
WEBサーバとかメールサーバならば確かに間違いじゃないと思うんですよ。ファイルサーバにしてもミラーリング周期に追いつかないようなやり取りが頻発するとかならたしかにそうです。
只、今回はGitですからね。元々自分の所と繋がってるノードを複数持てて、一回のpushやpullで同期を取れてしまう上に、大元は自分たちのところにありますからね。原則論的には、上記のような無停止性は重要じゃなくて、もう少し長いタイムスパン…数日とか…の停止期間があってもシステム的には何とかできるので。問題は、システムが落ちる前の状態で確実にバックアップからリストアできるか。改めてpushした時に、リポジトリの整合性が維持出来てるか。の方じゃないですか。
どちらかというと、次善の策をきちんと用意しましょうね。と言う話なのでは…年に何回かは落ちる可能性があるという前提で動いたほうがいいプロトコルなのでは…。
勿論、数百人規模やそれ以上の社内Commiterを（クローズドなプロジェクトとして）同時に捌く為に月何万円？もお金を払って有償サービスを買うような場合は、全く話が変わってくるでしょうけど、それもセカンダリの設定で凌げなくはない。
GitHub Enterpriseは落ちなかったようですようですまあ、そういうことです
GitHub がどうだかは知りませんが、急成長したサービスだと設備が追いついていない可能性はありますね。変に GEEK なノリが残っていたりとか。
＃ さすがに、こんなこと [atmarkit.co.jp]は無いと思いますがw
そーなの？復帰してからpushするだけやないの？
AWS CodeCommithttps://aws.amazon.com/codecommit/ [amazon.com]
自宅で最近使い始めたばかりなので詳しくは無いけど、中央集権型が良いならgit選ぶ必要無いのでは？SubversionやTFS（名前変わってたらゴメン）をSAASなり借りて作りゃいいやん、と思うんだけどなあ。
むしろGitのおかげで完全なミラーリング、冗長化が簡単にできるのでとても良いなと思っています。
以前使ってたDCも電源が一番高価だったな。起動タイミングのずらし方も電源の負荷を考えての事だったし。
(DCの高価な装置も設定ミスで停電したときは笑うしかなかった。
AC にすればよい！
ダウン、カッコ悪い
ぽぽぽぽーん？
コンピュータの電源に使われてるスイッチング電源は、大抵、整流した商用電源をFETのスイッチで制御して定電圧を供給していますが、途中途中に大容量の電解コンデンサやコイル・トランスを挟んで求められる安定度と直流の「きれいさ」（ノイズ輻射や電圧変動の小ささ）を確保している訳です。
これらの部品は経年劣化するし、温度や負荷が高ければ劣化速度は加速します。特に、電解コンデンサには電子部品としては比較的短い寿命がありまして、平均故障間隔 [wikipedia.org]が、少し前だと1,000〜2,000時間＠105℃、長くても5,000時間で、最近になっていろいろ改善されたり材質が固体化されたりして、10,000時間@105℃の物が出始めた。電源内部が50℃位で動作してると仮定した場合、電解コンデンサの温度依存性の法則 [nteku.com]から、中のコンデンサが2,000時間＠105℃の場合、大体90,000時間＝10年ちょっとの平均故障間隔となりますが、データセンターのサーバとなると熱的にかなりタイトなので、60℃程度で動作してる部位やリップル電流でもう少し高い温度になってるコンデンサもあるでしょうから、平均して大体5年弱で電源装置が壊れると見たほうがいいでしょう。
今は、電源に自己診断装置やロギング機能が入っていて、不良を起こしそうな兆候が見られるとアラートを上げるものも出てきてるようですが、自社データセンターで、大半のユーザが無料と言うサービスが、そこまで頻繁に機材を入れ替えてるだろうか。と言う問題があるわけです。
そんな感じである上に、スイッチング電源の設計が拙かったとか部品が想定外の壊れ方をしたということがあると、電源が短絡モードで故障したり商用電源側に大きな負荷変動を起こすことがある訳ですよ。そうなると、ラック内の他のサーバや他の電源ノードにまで影響が波及していく。これが、今回の問題の構図なんじゃないかと思いますよ。
とあるメーカーのWSは、内部管理ツールで電源ユニット毎のファン稼働時間を積算していて一定時間毎に交換アラームあげてきますね。保守入ってたら定期的にCEさんがそれのlog見て交換していってる。同時に稼働しているはずなのに、並列の電源ユニットの交換タイミングがバラバラなのが不思議だけどわざとそうしてんのかな。
わざとじゃないですかねえ。同時に同じロットのものを大量に交換した結果同じタイミングで大量に故障して焼け野原ってのを防ぎたいのじゃないかと。この辺実際運用に携わっている人の話を聞いてみたいです。
商用電源側の大きな負荷変動が祟ったかもしれないという推測はありえるかもです。障害検知をするための負荷変動のトリガーの感度設定ミスとかは過去にどこかでありましたね。鈍感で検知できない場合や、敏感すぎて切り替えた直後に異常と誤認識して落ちるとか。
ところで、大抵のところでは電源装置が故障することは当然の前提で電源系統の冗長性を確保しています。それでも落ちたのはどうしてだということですね。例えば、実システムでの切り替えテストが不十分だったとか、運用していく過程でのシステムの増改築変更により当初の設計想定外となったとか、最初からある程度のリスクは覚悟していたとかなんだとか。
githubの原因はなんだったのか気になります。
稼働中の装置が、実際に正常に切り替わるかどうか試験するわけにもいかんだろうしなあ。
「失敗するとコワいから切り替えテストができない」ぐらいの信頼性で運用してほしくないなぁ...
こないだもGMOが電源設備トラブルで長期システムダウンしてましたよね。
多重化しても多重化を制御する装置がイカれたりするんでしょうか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
弱点 (スコア:1)
DCでの事故原因として電源がよく上げられるけど、改善されない要因ってなんだろう。
・電源なんてあって当たり前なので管理がいい加減のまま。
・不安なので多重化しててもやっぱりどっかで事故っててきりがない。
・実は他に原因があるけど言い訳(スケープゴート)にされやすい。
・掃除のオバちゃんが黒幕。
Re:弱点 (スコア:2, 参考になる)
電源周りは経年劣化が防げないので、お金と冗長性のトレードオフの結果じゃないでしょうか。
データセンターの管理者とサービスのプロバイダーが同じで、ユーザーが多少我慢してくれるような所だと、金をケチって時々サービスを落としたほうが得なんだと思います。
でかい共用のデータセンターだと冗長性の規格があって、電源系統の冗長性や、受電設備-ラックUPS系統の冗長性、サーバーUPSの冗長性から施設の耐震性能に至るまでの要求事項が決められています。
そして、こういった要求事項を満たしているので、統計的に年間の無電源時間をx時間以内に抑えられるはずだというのをユーザーに保証しています。
Re: (スコア:0)
世間ではこの件でギットは信頼性が低いって風潮ですが
Re:弱点 (スコア:1)
分散型のヴァージョン管理システムで、特定サーバの信頼性が云々って、限定的にしか問題にならないのではないかと思うんですけどね。
最終的には、大本の所との同期が取れたらいいので…
githubにホスティングやバックアップ機能を完全に依存してれば確かに問題ですが、ユーザが複数いるような場合には、確かに同期を取ればいいだけの話のような(；´Д｀)
それでも不十分となったら、別のサービスで多重化した方がいいでしょうね。（と言うか、前々から一個のサービスでの公開だとこの手の障害ならまだしも、洪水とか爆発事故とか地震とかのもっと壊滅的な物理的障害には脆弱なので複数サービスに登録しようか迷ってはいますが）
参考：http://www.find-job.net/startup/5-git-hosting [find-job.net]
Re:弱点 (スコア:1)
「限定的にしか問題にならない」
のと
「今回の障害で信頼性に疑問が出てる」
のは全然別の話
商用サービスとして売ってるんであれば、
少なくとも完全に停止するような障害は避けるべきだと思いますよ
Re:弱点 (スコア:1)
WEBサーバとかメールサーバならば確かに間違いじゃないと思うんですよ。
ファイルサーバにしてもミラーリング周期に追いつかないようなやり取りが頻発するとかならたしかにそうです。
只、今回はGitですからね。
元々自分の所と繋がってるノードを複数持てて、一回のpushやpullで同期を取れてしまう上に、大元は自分たちのところにありますからね。
原則論的には、上記のような無停止性は重要じゃなくて、もう少し長いタイムスパン…数日とか…の停止期間があってもシステム的には何とかできるので。
問題は、システムが落ちる前の状態で確実にバックアップからリストアできるか。改めてpushした時に、リポジトリの整合性が維持出来てるか。の方じゃないですか。
どちらかというと、次善の策をきちんと用意しましょうね。と言う話なのでは…年に何回かは落ちる可能性があるという前提で動いたほうがいいプロトコルなのでは…。
勿論、数百人規模やそれ以上の社内Commiterを（クローズドなプロジェクトとして）同時に捌く為に月何万円？もお金を払って有償サービスを買うような場合は、全く話が変わってくるでしょうけど、それもセカンダリの設定で凌げなくはない。
Re: (スコア:0)
GitHub Enterpriseは落ちなかったようですようです
まあ、そういうことです
Re:弱点 (スコア:1)
GitHub がどうだかは知りませんが、急成長したサービスだと設備が追いついていない可能性はありますね。
変に GEEK なノリが残っていたりとか。
＃ さすがに、こんなこと [atmarkit.co.jp]は無いと思いますがw
Re: (スコア:0)
Re: (スコア:0)
そーなの？
復帰してからpushするだけやないの？
Re: (スコア:0)
AWS CodeCommit
https://aws.amazon.com/codecommit/ [amazon.com]
Re: (スコア:0)
自宅で最近使い始めたばかりなので詳しくは無いけど、中央集権型が良いならgit選ぶ必要無いのでは？
SubversionやTFS（名前変わってたらゴメン）をSAASなり借りて作りゃいいやん、と思うんだけどなあ。
Re: (スコア:0)
むしろGitのおかげで完全なミラーリング、冗長化が簡単にできるのでとても良いなと思っています。
Re: (スコア:0)
以前使ってたDCも電源が一番高価だったな。
起動タイミングのずらし方も電源の負荷を考えての事だったし。
(DCの高価な装置も設定ミスで停電したときは笑うしかなかった。
Re:弱点 (スコア:1)
AC にすればよい！
Re:弱点 (スコア:1)
ダウン、カッコ悪い
Re: (スコア:0)
ぽぽぽぽーん？
Re:弱点 (スコア:1)
コンピュータの電源に使われてるスイッチング電源は、大抵、整流した商用電源をFETのスイッチで制御して定電圧を供給していますが、途中途中に大容量の電解コンデンサやコイル・トランスを挟んで求められる安定度と直流の「きれいさ」（ノイズ輻射や電圧変動の小ささ）を確保している訳です。
これらの部品は経年劣化するし、温度や負荷が高ければ劣化速度は加速します。
特に、電解コンデンサには電子部品としては比較的短い寿命がありまして、平均故障間隔 [wikipedia.org]が、少し前だと1,000〜2,000時間＠105℃、長くても5,000時間で、最近になっていろいろ改善されたり材質が固体化されたりして、10,000時間@105℃の物が出始めた。
電源内部が50℃位で動作してると仮定した場合、電解コンデンサの温度依存性の法則 [nteku.com]から、中のコンデンサが2,000時間＠105℃の場合、大体90,000時間＝10年ちょっとの平均故障間隔となりますが、データセンターのサーバとなると熱的にかなりタイトなので、60℃程度で動作してる部位やリップル電流でもう少し高い温度になってるコンデンサもあるでしょうから、平均して大体5年弱で電源装置が壊れると見たほうがいいでしょう。
今は、電源に自己診断装置やロギング機能が入っていて、不良を起こしそうな兆候が見られるとアラートを上げるものも出てきてるようですが、自社データセンターで、大半のユーザが無料と言うサービスが、そこまで頻繁に機材を入れ替えてるだろうか。と言う問題があるわけです。
そんな感じである上に、スイッチング電源の設計が拙かったとか部品が想定外の壊れ方をしたということがあると、電源が短絡モードで故障したり商用電源側に大きな負荷変動を起こすことがある訳ですよ。そうなると、ラック内の他のサーバや他の電源ノードにまで影響が波及していく。これが、今回の問題の構図なんじゃないかと思いますよ。
Re:弱点 (スコア:1)
とあるメーカーのWSは、内部管理ツールで電源ユニット毎のファン稼働時間を積算していて一定時間毎に交換アラームあげてきますね。
保守入ってたら定期的にCEさんがそれのlog見て交換していってる。
同時に稼働しているはずなのに、並列の電源ユニットの交換タイミングがバラバラなのが不思議だけどわざとそうしてんのかな。
Re: (スコア:0)
わざとじゃないですかねえ。同時に同じロットのものを大量に交換した結果
同じタイミングで大量に故障して焼け野原ってのを防ぎたいのじゃないかと。
この辺実際運用に携わっている人の話を聞いてみたいです。
Re: (スコア:0)
商用電源側の大きな負荷変動が祟ったかもしれないという推測はありえるかもです。
障害検知をするための負荷変動のトリガーの感度設定ミスとかは過去にどこかでありましたね。
鈍感で検知できない場合や、敏感すぎて切り替えた直後に異常と誤認識して落ちるとか。
ところで、大抵のところでは電源装置が故障することは当然の前提で電源系統の冗長性を確保しています。
それでも落ちたのはどうしてだということですね。
例えば、実システムでの切り替えテストが不十分だったとか、
運用していく過程でのシステムの増改築変更により当初の設計想定外となったとか、
最初からある程度のリスクは覚悟していたとかなんだとか。
githubの原因はなんだったのか気になります。
Re:弱点 (スコア:1)
稼働中の装置が、実際に正常に切り替わるかどうか試験するわけにもいかんだろうしなあ。
Re: (スコア:0)
「失敗するとコワいから切り替えテストができない」ぐらいの信頼性で運用してほしくないなぁ...
Re: (スコア:0)
こないだもGMOが電源設備トラブルで長期システムダウンしてましたよね。
多重化しても多重化を制御する装置がイカれたりするんでしょうか。