CDP:NFS Sharingパターン
(Difference between revisions)
KenTamagawa (Talk | contribs) (→注意点) |
|||
Line 31: | Line 31: | ||
* サーバ台数が多くなると、NFSアクセスのパフォーマンスの考慮が必要となる。 | * サーバ台数が多くなると、NFSアクセスのパフォーマンスの考慮が必要となる。 | ||
* NFSサーバがSPOFになるのを防ぐために、GlusterFSなどのソリューションを検討する | * NFSサーバがSPOFになるのを防ぐために、GlusterFSなどのソリューションを検討する | ||
+ | * DBサーバーは、耐障害性、メンテナンスの観点からもWebサーバーとは分離して設置することが望ましい。しかし、DBレイヤのスケールアウトはWebレイヤと比べて一般的に難しい。リレーショナルデータベースのパターンを参照すると良いだろう。 | ||
== その他 == | == その他 == |
Revision as of 15:13, 15 April 2012
共有コンテンツの利用
Contents |
解決したい課題
複数サーバで負荷分散した場合、コンテンツの同期方法が常に課題となる。 簡単な手段としてマスターサーバから定期的に一方向の同期を行うものなどもあるが、 この方法でも同期の遅延や、各サーバでの書き込みがすべてのサーバに反映されないなどの課題は残る。
クラウドでの解決/パターンの説明
このパターンは、複数のサーバ間で、同じ内容のコンテンツをリアルタイムに読み書きできるようにするものである。 共有するコンテンツの実体を配置するマスターサーバをそのままNFSサーバにし、 その他のコンテンツを共有するサーバはNFSクライアントとすることで、リアルタイムで各サーバからの更新が 反映する共有コンテンツを実現することができる。
実装
AWSにはEC2と呼ばれる仮想サーバを構築することができる。EC2上ではLinuxなどのOSが稼働し、 従来の方法で容易にNFSサーバ/クライアントを構築することが可能である。
- NFSサーバをEC2上に構築する。
- 共有したいコンテンツをNFS サーバに配置する。
- スケールアウトするサーバ群から、そのNFSサーバのコンテンツを参照するようにする。
- Clone Serverパターンで解説したディスクの同期と、NFSでの共有部分を、共存させることもできる。更新頻度の高いものは、NFSでの共有を用いると良い。
構造
利点
- 共有コンテンツをNFSに置くことで、リアルタイムで同期できる。
- NFSをマウントするだけで、コンテンツの共有ができ、セットアップが簡単である。
注意点
- NFSサーバの管理が必要となる。
- サーバ台数が多くなると、NFSアクセスのパフォーマンスの考慮が必要となる。
- NFSサーバがSPOFになるのを防ぐために、GlusterFSなどのソリューションを検討する
- DBサーバーは、耐障害性、メンテナンスの観点からもWebサーバーとは分離して設置することが望ましい。しかし、DBレイヤのスケールアウトはWebレイヤと比べて一般的に難しい。リレーショナルデータベースのパターンを参照すると良いだろう。