久しぶりの大規模サーバ構築

といっても、非常に前時代的な構成ですが(苦笑)。
用途を考えると過剰過ぎる構成で、電気かなり喰いまくりな感じです。エコってどこ?ってなわけで。

あまり細かく構成を書くわけにはいかないのですが、台数だけ言いますと、バックアップサーバ込みで10台です。

今回は時間がないのと、その後の管理を私がやるわけではないので、自分のポリシーに反した構築を行いました。

Source Makeは極力やらない。
絶対に使いたい機能がある場合及び大きなセキュリティホールがある以外はバージョンを落としてでもRPMでインストールしてみました。

監視ツールをしっかりとインストールする。
まあこれはポリシーというわけではないのですが。
以前のサーバはスペックが弱く、監視ツールを入れる事自体がサーバにとって負荷となっていたために入れてなかっただけで。
今回は基本的な監視ツールはとりあえずインストールしてみました。

バックアップをしっかりと。
幸い、今までのサーバではバックアップデータを使わざるを得ない事態に陥ったことはなかったのですが、今後はどうか分かりませんし、過剰設備でもあるので(爆)、非常に高価なオートローダー付きUltrium+市販のバックアップソフトなんていう贅沢なものが入っています。こんな高価な設備、初めて使うのでドキドキです、贅沢過ぎて設定がよく分かりません。
やはり私にはシェルスクリプトとかPerlとかでシコシコとバックアップ用のスクリプトを書くのが合っているようです(爆)。

設定はシンプルに。
前回のシステムはとにかくいろいろとやり過ぎてましたので、今回は徹底的にシンプル化を進めました。
メールサーバのソースなんて絶対にいじらないし、NICのドライバなんて絶対にいじらない。

最後まで迷ったのがログ管理で・・・というか、実はこれは今でも迷っているのですが。
集中監視するべきなのでしょうけど、容量がどれくらい必要か分からないので、どうしようかな・・という感じです。
今回はログについてもこまめに圧縮して保管するようなスクリプトを作ろうかと考えているので、それで制御しようかな・・・と思っています。可能であれば撤去されるまでの5〜6年分のログをサーバ上に残したいんだけど、ログを集約しちゃうと容量的に厳しいかもしれません。結局2年分くらいになっちゃうかな。

とりあえず来週から細かい調整に入る予定。
ログローテーションの必要がない(syslog-ngを使ったため)ので、後はログを圧縮して保管するスクリプトを書いて、アラートメールを送信する仕組みを組み込まなきゃ。

今回は事前にかなりの準備と調査をしていた(時間外にね・・・)ので、比較的スムーズに進んでます。

Leave a comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

Webサイトのこと、WordPressのこと、何でもお問い合わせ下さい