2012年07月01日

【自宅サーバ構築】6. HP ProLiant ML110 G7サーバ機 パーティション設計

 「HP ProLiantサーバー ML110 G7」を買ってからの泥縄の仕様決めでかなり時間が経過したが、ようやく設計計画が完成した(笑)。Windowsなら原則同じHDDの単一パーティションに導入するので関係ないが、Linuxの場合は各ディレクトリの用途性質を踏まえて、上手く分割することでバックアップ等の日常保守と障害時の修復作業を効率的に行なうことが出来る上に、運転時の負荷分散効果による安定化等のむメリットが期待出来るからで、具体的動機は以下の通りだ。
  •  デバイスイメージはアンマウントしてからバックアップする必要がある。その為、起動中のLinux自身のアンマウントは出来ないので、通常はシャットダウン後、Knoppix等の他のLinuxを起動させ実施することになる。サーバの場合停止タイミングは、カーネルやその主要ライブラリのupdate等、再起動が必要となることを実施した際となるので、稼働中のアンマウントが100%適わない「/」と「/boot」はできるだけ小さなパーティションに収めたい。
  •  「/usr」「/opt」等システム変更やupdateしない限り変更しない領域、「/var」「/tmp」といったシステムとしてデータを書き込まれる領域、そして「home」等ユーザの要求で書込みが行なわれる領域をパーティション分けすることで、バックアップを効率的に行なうと共に、不慮のシステム障害結果を生まない様にしたい。例えば、ユーザのデータ書込みで、HDDが一杯になったりするとlogが取れなくなったり、一時ファイルの書込みが出来ず一部システムが異常停止したり、HDDのデフラグ進行でサーバ動作が緩慢になる事態を想定頂きたい。各領域を隔離すれば、少なくとも具体的障害内容は単純化されるのだ。無論、空き領域も分割され個別領域の余裕は、単一パーティションよりは厳格に見積もる必要が出る。
  • 当面、冗長化の為のサーバを準備出来ないので、せめて、別HDDに同データのバックアップを取る形で対応したい。
  • ユーザデータはシステムデータと異なり、サーバ管理者単独で再構築不可能なので、Webの動的データや「/home」等のユーザデータはRAIDによる冗長化で運転時の保全性を高めると共にストレージ分割でHDDのヘッドアクセスの競合による動作遅延を軽減したい。
  • 障害時や保守時の起動Linuxも別途installし、その折の暫定運転の確保と、相互にバックアップ作業時に活用したい。
 動機の中で別HDDでRAIDを構成する点は、当初は省く予定だったことだったので、予定外の出費となったが、実際、installを試してみると、「HP ProLiantサーバー ML110 G7」の内蔵RAID利用はinstall時にのみRAIDドライバの導入が可能な様なので、将来RAID利用の可能性があるなら、例え単一のHDDにinstallするにしても、その手順を踏み進める必要がある。そこで、今回は衝動買いっぼく320GBのHDD2台を計8,960円で購入し、サーバ機内にinstallした。辛うじてサーバ機本体の価格よりは安いので良しとしよう(嘆息)。

 さて、そのRAID用HDDを前提に、現在NotePC上で端末利用しているCentOS6.2を参考に考えたパーティションが次のものである。
PAT. DIR.   Usage of MyPC     CAPA.
1. /boot 104.9 MB → 1 G ずぼらな性格だとkernelのupdateで増加していくのでちょいと大きめ。
2. / 1,673.7 MB → 10 G 手軽にイメージbackupする為、小さめ。
3. /usr 4,600.0 MB → 8 G 容量不足になったら/usr/localを別パーティションを新設し引越。
4. (拡張): 以下は全てこのパーティション上の論理パーティション。これを消すと全て失う運命。
5. /opt 614.8 MB → 2 G RDBMSであるFirebird等の追加installで利用。
6. /home 27,400.0 MB → 16 G 日常管理者のdownloadファイルが主用途。固定Webコンテンツもここに。
7. /var 637.3 MB → 30 G 雑多な共通データ書込。logはrotate必須。webコンテンツ主体は別確保。
8. /tmp 6.7 MB → 25 G crondで定期削除される一時的処理データの置き場。
9. SWAP → 8 G 現在メモリ4G実装。不足なら後は実メモリー追加で対処。
100 G


 全部で100GとHDDの半分以下に収まる容量である。「/」と「boot」は停止時に定期的にイメージバックアップを取る為、当方の従来の設計よりかなり小さくしたのが主因である。そのかわり、動的に容量を消費するものは全て別区画で確保し「/」のパーティションを一切使わない様にした。することで、残りは次の通りのディレクトリを賄うことが出来れば良いことになる。実際の活用次第では必要容量が大きく変わり得るとは思うが、当方の端末利用使用実績で見る限り、1,673.7MB程度しか消費していないので、10GBでは大き過ぎるとも言えるが、rootでの保守を余儀なくされたときのファイル置き場として「/root」とローカルな活用と障害保守時のマウントミスによる誤使用等も考慮した上で、どちらかと言うと許容されるバックアップ時間の負担の範囲で決定した次第だ。
  • /etc 20.3 MB
  • /dev 576.0 MB
  • /bin 7.5 MB
  • /sbin 13.4 MB
  • /sys 542.6 MB
  • /proc 0.7175 MB
  • /lib 487.6 MB
  • /lib64 25.6 MB
  • /root
  • /selinux
  • /cgroup
  • /srv
  • /misc
  • /net
  • /media
  • /mnt

     それに対し、「/usr」「/opt」は、余裕は消費の倍程度とした。今後、サーバ独自のパッケージが加わってもデフラグの影響が出ないことが前提の数字である。
     また、「/home」については、利用実績より逆に小さな容量設計としたが、これは、現在の端末利用でもパッケージのダウンロードがそのほとんどを締めていることから、サーバシステム構築に充分な容量として16GBとした。サーバなので管理者以外のユーザを無闇に登録することはないし、サーバとしての動的データは別途RAID1上に収める為、考慮する必要がないからである。
     これらに比べ、「/var」「/tmp」は極端に大きく余裕を持たせているが、これは、共に、管理者の意思とは関係なく、ファイルが作成される領域で、満杯になると「/var」は障害解析に必要なlogファイル等の書込みが出来なくなる等の課題が発生するし、「/tmp」は、その時に一時ファイルを書き込もうとしたアプリが異常終了してしまうことになり、各領域を埋め尽した原因は直接掴めない。これは公開サーバの場合には想定外のセキュリティ破りに使われる可能性が無いと迄は言えないだろう。これだけで充分とは言わないが、例えば/var/www以下を固定コンテンツ利用迄に留めるなら、最悪その中身が無くなっても、障害復旧自体に支障が無くして行けるのである。これからのことではあるが、「/var」「/tmp」の空き容量については自動監視し、常に空き容量を確保する様にすれば、この障害発生をより確実に予防出来るし、今回は実現出来ないが、公開サーバの場合はlogについてはlogrotate等で余り溜め込まない様にする以外に、ほぼ即時のタイミングでlog解析用のサーバに転送する方が確実になる。

     既述の動機と重複するが、日常管理におけるバックアップ方針の概略は次の通りである。
    1.  システムがある程度完成した時点にはなるが、HDDの全てのパーティションのイメージファイルの作成を行なう。最悪の場合でも、これさえあれば、ここ迄なら戻せる様になる。
    2.  カーネルUpdateで必要となるサーバ再起動時には、ddまたはdd_rhelpを使い「MBR」「/」「/boot」の3つのイメージファイルを常に作成し、履歴管理する。
    3.  「/usr」「/opt」は、変更時とUpdate時にtarによるバックアップファイルを作成し、履歴管理する。
    4.  「/home」「/var」のアプリデータについてはサブディレクトリ別の重要度に合わた頻度で定期的にtarでバックアップファイルを作成し、履歴管理する。
    5.  「/var」のlogファイルについては、logrotateで自動消去させる以外に、適切な管理アプリを導入する。特に外部公開サービスのログについてはユーザ個別開示も視野にDB化(取り敢えず同一サーバ上)を考える。
    6.  「/var/lock」等で、たまにアプリ側で書込み権限が無いとして怒られてしまうものがあるので、その分を予め手順化かスクリプト化して置く。
    7.  「/tmp」についても、障害切分け用途として、tarで定期backupし解析して置く。
    8.  システム変更については、毎回、手順を目で追って実行するのも良いが、スクリプト化も積極的に取り組んで行く。これにより、バックアップを被せるだけでは修復不能なものもより手早く対処可能になる。


     思ったより長くなったので、具体的作業は次稿に廻すことにする。
posted by Mire at 02:58 | Comment(0) | TrackBack(0) | 自宅サーバ構築管理 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/278231558
※ブログオーナーが承認したトラックバックのみ表示されます。

この記事へのトラックバック
月額見放題1,000円開始キャンペーンバナー(画像ありver)
紺碧の艦隊 ルパン三世 GREAT CHASE クリックプロモーション
<< 2013年01月 >>
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
カテゴリ
タグクラウド
ファン
利用中のオープンソース
最近のコメント
最近の記事
過去ログ
QRコード
レガシーなアプリはいかが?
Dell 法人のお客様ページ
  • 【法人様向け】デル、お得なキャンペーン情報
  • 法人のお客様向け ストレージソリューション
  • 法人のお客様向け ネットワークソリューション
  • 【SOHO法人様向け】デル・オンライン広告限定ページ
  • デル-個人のお客様ページ
  • 【個人のお客様向け】デル・オンライン広告限定ページ
  • オンライン広告限定キャンペーンページ
  • ソフトウェア&周辺機器 パソコン工房
    ツートップインターネットショップ(twotop.co.jp) マウスコンピューター/G-Tune
  • ×

    この広告は1年以上新しい記事の投稿がないブログに表示されております。