- PR -

冗長パーティション？

1|2 次のページへ»
投稿者投稿内容
たらお
大ベテラン
会議室デビュー日: 2006/12/25
投稿数: 206
お住まい・勤務地: 東京・永代通り
投稿日時: 2007-03-22 14:32
現在、システム運用部署で、ネットワークを主に見ていますが、
この2年で起きたシステム障害に共通しているのが、

◆「サーバーの特定パーティションが100%使用されたこと」です。

OSはWin2KやLinuxで、ロギング領域や、退避エリアだったりです。
もちろん、ログの発生が異常に多くなった場合もありますが、
何かこう情けなく、もどかしいものを感じます。

こういう、パーティション容量不足の問題を回避する技術はないのでしょうか？

_________________
＿福田太郎＿
exit
会議室デビュー日: 2005/02/01
投稿数: 3
投稿日時: 2007-03-22 15:13
パーティションの空き容量を監視する。


スクリプト書いてcronとか、タスクスケジューラーでまわせばいいのでは。
閾値に達したらメール飛ばしたり、それでは見落としそうというなら、パトライトとかサイレンとか使って、、。
たらお
大ベテラン
会議室デビュー日: 2006/12/25
投稿数: 206
お住まい・勤務地: 東京・永代通り
投稿日時: 2007-03-22 17:40
ありがとうございます。
ご指摘のパーティション残量監視については、
最後の手段(=ユーザーによる運用回避)と思ってます。


そもそもの発端は、ログが書き出せなくなったくらいで、サービスが不能になる
(高価！)サーバー用アプリの作法やストレージの仕組みに、合点がいかないのです。
考え方としては、以下があると思います。

1.アプリレベルでの対応　→作業エリアのセカンダリ設定など
　数回連続でプライマリ作業エリアへの書き込みに失敗したら、
　セカンダリに設定された作業エリアにログを吐くとか。
　アプリ自体が、パーティションの残量を把握するのもありでしょう。

2.OSレベルでの対応　→拡張ディレクトリなど
　OSがパーティションの残量を見て、パーティションを変更/追加するとか。

3.ストレージでの対応　→ダイナミックスワップみたいな、、。
　HDD領域が規定の割合使用されたら、スタンバイHDDに切り替わるとか。


なければ発明してくださっても結構です。(笑)


_________________
＿福田太郎＿
せん
ぬし
会議室デビュー日: 2002/03/04
投稿数: 397
投稿日時: 2007-03-22 18:49
引用:

ご指摘のパーティション残量監視については、
最後の手段(=ユーザーによる運用回避)と思ってます。

私は残量監視こそ最初に行なう事だと思います。
運用契約で内部はノータッチとかなら話はわかりますけど、
それを最後の手段にする理由は思いつきません。

ネットワークを主に見てらっしゃるという事でサーバ側の担当ではない、
という事なのかも知れませんが、そうするとサーバ側の運用ってのは何を
してるんだろうかと、ちょっと疑問に思いました。
引用:

1.アプリレベルでの対応　→作業エリアのセカンダリ設定など
　数回連続でプライマリ作業エリアへの書き込みに失敗したら、
　セカンダリに設定された作業エリアにログを吐くとか。
　アプリ自体が、パーティションの残量を把握するのもありでしょう。
2.OSレベルでの対応　→拡張ディレクトリなど
　OSがパーティションの残量を見て、パーティションを変更/追加するとか。
3.ストレージでの対応　→ダイナミックスワップみたいな、、。
　HDD領域が規定の割合使用されたら、スタンバイHDDに切り替わるとか。

お金をかけてそのような製品を探すor開発すれば、不可能ではないかも知れません。


ただし、なぜログファイルの領域があふれてしまうのかを調べるのがスジだとおもいます。
ログファイルの容量見積もりが甘かったのか、利用想定が予想を超えたのか、
ゴミアクセスが多いためにログファイルが肥大化してしまったのか。

その辺が特定してから、1,2,3 のような方法を考えるべきだと思います。
shimix
ぬし
会議室デビュー日: 2004/08/05
投稿数: 512
お住まい・勤務地: 大分市
投稿日時: 2007-03-22 18:55
引用:

たらおさんの書き込み (2007-03-22 17:40) より:
ご指摘のパーティション残量監視については、
最後の手段(=ユーザーによる運用回避)と思ってます。

私は基本だと思っています。誰もこれ以上に良い方法を発明してくれてませんし、合点がいかなくても運用はしないといけませんから。

セカンダリとか自動拡張といっても切り替わったり拡張がいっぱいになったのを見落とせば結局同じなわけで、残量監視との違いは見出せません。そうであればシンプルな方がいいと思います。

（追記）
何らかの要因で｛切り替わらなかった｜拡張されなかった｝なんてことで慌てるのはイヤですねぇ。そもそも用意すべきセカンダリ領域とか拡張用領域をどうやって見積もるのかという・・（これが確定出来るのなら最初から不要）。

[ メッセージ編集済み 編集者: shimix 編集日時 2007-03-22 19:20 ]
末言己八
会議室デビュー日: 2007/03/01
投稿数: 6
投稿日時: 2007-03-22 19:47
引用:

そもそもの発端は、ログが書き出せなくなったくらいで、サービスが不能になる
(高価！)サーバー用アプリの作法やストレージの仕組みに、合点がいかないのです。
考え方としては、以下があると思います。


ディスク領域は有限なリソースなので、ログを適切に運用していなければ
いつかはパンクして当たり前だと思うけど...
古いログもサーバ上に残しておく必要があるのでしょうか？

メーカー側もある程度の仕組みは用意するかもしれませんが、万人に当てはまる
仕組みなどあるわけないので、通常は運用で回避できる部分は運用で回避するのが
普通だと思いますけど...
というかメーカー側が用意する仕組みも運用の補助的なものしかないと思われ...

ローテーション＆必要なら外部メディアにバックアップ＆古い世代のログ削除
Mattun
ぬし
会議室デビュー日: 2004/08/10
投稿数: 1391
投稿日時: 2007-03-22 20:16
ディスク枯渇の要因がどこまでの異常値なのか分かりませんが、
その辺をある程度見越して領域見積もりするのが当然です。

容量不足に陥りそうになったら、なんてことであれば容量監視なくしてどう実現するのかと。
監視とリソース変更を自動監視するような仕組みはすでに存在しますが、
サーバ単体でそれ実現するとなると、最初から割り当てればいいだけの話ですね。
よって、それなりの規模数のサーバが前提ですから、それなりに高価なソリューションです。

引用:

そもそもの発端は、ログが書き出せなくなったくらいで、サービスが不能になる
(高価！)サーバー用アプリの作法やストレージの仕組みに、合点がいかないのです。

ログが書き出せない＝何が起きたか事後確認できない
ということで、結構致命的な障害ですよ。
セキュリティに絡むログだとなおさらです。

なお、アプリによっては、アプリごとのログ容量制限が可能であり、
容量を超えた場合の処理の選択も可能です。
アプリを停止するか、古いログを上書きするかとか。
システム全体が停止しないという面では、こういう仕組みはありがたいところです。
そうなった時点でどのみち障害ではあるんですが。

本来なら、すべてのアプリがそういう実装であれば、
設計次第でサーバ全体障害は抑止できるでしょうね。
これをサーバ自体がというのは困難でしょう。
どのデータがどれだけ重要かはアプリ次第なんですから。
_________________
Mattun
Microsoft MVP for Directory Services
(Oct 2006-Sep 2007)
ちゃっぴ
ぬし
会議室デビュー日: 2004/12/10
投稿数: 873
投稿日時: 2007-03-22 23:25
Log rotation は普通考えますけど、その程度ですね。

どのみち膨れ上がるときは膨れ上がるので、閾値で監視するのが一般的かな。
_________________
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）