ＬＡＭＰ環境における考えられるリスクに関して
大まかに考えると以下の3つに分けられる
ハード障害
アプリケーション障害
ネットワーク障害
それぞれを考える。
ハード障害
ディスク障害
データの損失を招くのでバックアップによるデータ退避が必要
近年では、ＳＭＡＲＴなどにより監視を実施し、事前に予兆があれば検知可能
ただしハードディスクに依存するので予備機による回避が適当か
ファンなどのアクセサリー障害
ＣＰＵであればカーネルパニックなどを引き起こす。再起動になるので、ベースの
監視システム次第。ＤＢのファイルが問題になる可能性があるので、こちらはレプリケ
ーションをかけて保護策を検討
電源装置のトラブル
電源が落ちてしまうことがある。これによるディスク障害、あがらなくなどが発生する。
対策としては予備機による保護が適当と思われる。
アプリケーション障害
アプリケーションによるトラブルによるもの。バグなどが考えられるが広義で言えば
侵害なども含まれると思われる。脆弱性をついてという点ではアプリケーションが狙
われやすいのではないか。
作業ミスによるもの
ＤＢのデータ操作ミスなど
対応策は、予備機による退避と、検証機による退避が妥当
ネットワーク障害
ネットワークケーブル、設定によるもの
ＯＳＩ物理層におけるトラブルに対応。これはレンタルサーバであれば業者に一任する
よりないので、予備機を別契約にするなどの対応が必要になるが、最も上記のうちでは
少ないと思われる。
ＤＮＳ障害
ドメインの設定漏れによるもの。セカンダリの契約を行い、ＤＮＳ自体の契約がされてい
れば防げると考えられる。
ファイヤウォール、負荷分散装置などの障害
レンタルサーバ環境において、冗長構成をとらないため、障害ポイントにはなりにくいと
思われる
よって以下の構成をとるのが、よいと考えられる。
Ａ，Ｂ重複構成でのレンタルサーバの借受
Ａ 本番機
Ｂ 検証および待機系
Ａ，Ｂ間においてMYSQLのレプリケーションを実施。Ｂに切り替えるときは、レプリケーションを
やめる設定をバッチ化をしておく。
Ｂにおいて検証環境はＤＢのすみわけを行っておき、こちらをアプリ側で切り替える
なおＢ側でバックアップを取るようにすると、バックアップによる負荷がかかりにくい。
問題点および対応策
ＤＮＳの切り替えがネックになるので、こちらを早期に行えるようにするか、
ＨＡ構成を取れるようにし、フロートＩＰをＡ側に付与しておき、問題があった場合にはＢ側に移せ
るようにしておく。（仮想ＩＰ）
ＨＡを自動で切り替えられるHeartBeatなどのＯＳＳのソフトがあるが、シリアル通信が
必要など、物理的にレンタルサーバでは難しいと考えられるので手動に含めるのが妥当。
切り替え時間はシェルの実行にもよるがスイッチの学習がデフォルトであれば10分程度。
ＤＮＳで30分程度にしておく策も有効であるのでどちらかを検討したい。