質問: 現在ネットワーク技術を勉強中の学生です。 過去の課題研究を引き継いでOpenflowスイッチ、Openflowのコントローラを用いてネットワーク環境を構築しております。 課題の業務要件の一部としてwebサービスのシームレス化が挙げられております。 ヒアリングの結果、メインwebサーバのwebサービスが停止した場合、ユーザが継続的にサービスを利用できるように、自動的にサブのサーバーへ切り替える機能が必要ということになりました。 この機能をsnmpのスクリプトを作成し、snmpのスクリプトの結果をトリガーとしてサーバの自動切り替えを実現したいと考えております。 このことについて、より良い方法や問題点があれば教えていただきたいです。
回答: ハードは無事で、appachなどのサーバが停止したことを問題視しているのであれば、service というものを使います。このserviceは一般的な言葉ではなく、soft packageの名前です。appach (httpd)が停止すると、自動的に再起動してくれます。無条件に再起動するので、設定が間違っている、appachがバグっている 時には、起動=> 即死を繰り返す場合もあります。 Ubuntu / CentOS などの場合、appachなどの場合は、標準でservice を使う設定もinstall されています。 ハードの故障対策で、単純なweb serverの場合であれば、同じ名前のserverを複数台準備します。どれか最初にアクセスできたものにつながります。死んだり、反応が遅いものは無視されます。 ここらの問題は、openflowの問題 というよりは、単純に耐障害性の問題です。同じハードばかり使えば、動的に再構成の必要性は減り、ソフト的に定義されているコンポーネントを使わない場合、仮想化はできません。 従って「サービスが停止した」を細分化・リストして、そのそれぞれに対して対策を設計することから始まるのではないかと思います。