アカウント名:
パスワード:
DCでの事故原因として電源がよく上げられるけど、改善されない要因ってなんだろう。
・電源なんてあって当たり前なので管理がいい加減のまま。・不安なので多重化しててもやっぱりどっかで事故っててきりがない。・実は他に原因があるけど言い訳(スケープゴート)にされやすい。・掃除のオバちゃんが黒幕。
電源周りは経年劣化が防げないので、お金と冗長性のトレードオフの結果じゃないでしょうか。データセンターの管理者とサービスのプロバイダーが同じで、ユーザーが多少我慢してくれるような所だと、金をケチって時々サービスを落としたほうが得なんだと思います。
でかい共用のデータセンターだと冗長性の規格があって、電源系統の冗長性や、受電設備-ラックUPS系統の冗長性、サーバーUPSの冗長性から施設の耐震性能に至るまでの要求事項が決められています。そして、こういった要求事項を満たしているので、統計的に年間の無電源時間をx時間以内に抑えられるはずだというのをユーザーに保証しています。
世間ではこの件でギットは信頼性が低いって風潮ですが
分散型のヴァージョン管理システムで、特定サーバの信頼性が云々って、限定的にしか問題にならないのではないかと思うんですけどね。最終的には、大本の所との同期が取れたらいいので…
githubにホスティングやバックアップ機能を完全に依存してれば確かに問題ですが、ユーザが複数いるような場合には、確かに同期を取ればいいだけの話のような(；´Д｀)
それでも不十分となったら、別のサービスで多重化した方がいいでしょうね。（と言うか、前々から一個のサービスでの公開だとこの手の障害ならまだしも、洪水とか爆発事故とか地震とかのもっと壊滅的な物理的障害には脆弱なので複数サービスに登録しようか迷ってはいますが）参考：http://www.find-job.net/startup/5-git-hosting [find-job.net]
「限定的にしか問題にならない」のと「今回の障害で信頼性に疑問が出てる」のは全然別の話
商用サービスとして売ってるんであれば、少なくとも完全に停止するような障害は避けるべきだと思いますよ
WEBサーバとかメールサーバならば確かに間違いじゃないと思うんですよ。ファイルサーバにしてもミラーリング周期に追いつかないようなやり取りが頻発するとかならたしかにそうです。
只、今回はGitですからね。元々自分の所と繋がってるノードを複数持てて、一回のpushやpullで同期を取れてしまう上に、大元は自分たちのところにありますからね。原則論的には、上記のような無停止性は重要じゃなくて、もう少し長いタイムスパン…数日とか…の停止期間があってもシステム的には何とかできるので。問題は、システムが落ちる前の状態で確実にバックアップからリストアできるか。改めてpushした時に、リポジトリの整合性が維持出来てるか。の方じゃないですか。
どちらかというと、次善の策をきちんと用意しましょうね。と言う話なのでは…年に何回かは落ちる可能性があるという前提で動いたほうがいいプロトコルなのでは…。
勿論、数百人規模やそれ以上の社内Commiterを（クローズドなプロジェクトとして）同時に捌く為に月何万円？もお金を払って有償サービスを買うような場合は、全く話が変わってくるでしょうけど、それもセカンダリの設定で凌げなくはない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
弱点 (スコア: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を（クローズドなプロジェクトとして）同時に捌く為に月何万円？もお金を払って有償サービスを買うような場合は、全く話が変わってくるでしょうけど、それもセカンダリの設定で凌げなくはない。