Subversionのシステム構成を考えてみた

全社的にSubversionを使えないか調べているんだけど、その構成に関する資料はとても少ない。
SVN1.5だとエンタープライズ環境におけるSubversionの複製アーキテクチャ by japan.internet.com デベロッパーとかSubversionを見直せ by プログラマの思索さんがとても詳しい。

そこで、Subversionのシステム構成をまとめてみた。いきなり「WebDAV Transparent Write-Through Proxyっすよ！」とMTGで提案するのも何なので、まずは整理。

 

単一サーバの場合

これは簡単。WindowsならばAll-in-one Tracとか使えばすぐ環境ができる。
昔の職場では、自分のPCに入れて使っていたのでこの構成になる。

いいところ
・シンプル
・小さいプロジェクトとかならこれで十分

悪いところ
・リポジトリが壊れるとバックアップからの復旧になる

 

複数サーバ・単一リポジトリの場合

NFSとかを使ってディクス共有ができるのであればこういう構成も可能。ただし、リポジトリは結局1つなので、Apacheは冗長になっているけど、リポジトリが壊れたらおしまい。サーバ間でリポジトリを同期しなくていいのが楽で、Apacheの故障であれば有効かもしれないけど、Apacheの冗長化があまり効果を発揮していない気もする。

こんときに注意しないといけないのが、SVNはApacheサーバはAct/Actでいいんだけど、両方にリクエストを渡すのはだめっぽい。どうも複数サーバから単一リポジトリにコミットなどWriteすると、リポジトリが壊れるみたい。
Act/Actにしておいて、片サーバのみにリクエストを投げるようにLBなりで設定しておかなければえらいめにあう。
LBが使えないなら、2つのSVNサーバそれぞれにドメインを割りあって、待機系のSVNサーバからはコミットできないようにしておかないとだめ。

いいところ
・Apacheの停止に強い
・サーバ間のリポジトリ同期が必要ない

悪いところ
・LBがない場合、マスタとスレーブの使い分けが必要
・リポジトリが壊れるとバックアップからの復旧になる

 

複数サーバ・複数リポジトリの場合（svnsync利用）

複数にリポジトリをとると、サーバ間の同期が気になると思う。
SVNはsvnsyncという機能を持っており、リモートやローカルの別リポジトリと同期し、レプリケーションを作成することができる。
この場合、ミラーリングしているので、障害時にApacheをスイッチできれば、SVNは止まらず利用できる。

ただし、通常利用するマスタSVNはRW。スレーブSVNはRとしておかないと、スレーブにコミットしたときに。同期はマスタ＞スレーブの一方通行なので、マスタと同期がとれなくなる。
よって障害時はスレーブをRで運用しなければならない。

これは問題に感じるが、コミットの緊急性よりもチェックアウトの緊急性が高いはずなので、障害復旧まではコミットできないけど、チェックアウトはできるのでいいんじゃね？というポリシーに納得できれば、シェルを書くだけで簡単に組める。

LBが使えたらこの構成で十分そうだし、LBが使えず、ユーザの手間を気にしなくていいなら、2つのSVNサーバに2つのドメインを割り当てて使うのもありかなと。

いいところ
・Apacheの停止に強い
・リポジトリが壊れてもRでアクセスができるため可用性が高い

悪いところ
・LBがない場合、マスタとスレーブの使い分けが必要

 

WebDAV Transparent Write-Through Proxyを使う場合

SVN1.5の新機能。WebDAV 透過ライトスループロキシというらしい。

複数サーバ・複数リポジトリの場合（svnsync利用）に似ていて、svnsyncを使うのだけれども、ちょっと違うのが、LBなど使わずにDNSラウンドロビンで2サーバを活用する場合に便利そう。

LBが振り分けを判定するのではなく、SVNが判定する仕組みになっている。

スレーブSVNにリクエストが来た場合、コミットとかのWrite処理だったらマスタに透過的にProxyする。こちらもマスタだけがWrite処理というポリシーになっている。
Readだけなら

Gitのような分散リポジトリ構成を組めるので、理想形と言えば理想。Apache2.2系のmod_proxyを使っているらしいので、Apacheのバージョンに注意が必要。

いいところ
・Apacheの停止に強い
・リポジトリが壊れてもRでアクセスができるため可用性が高い
・LBとかいらない
・WriteはマスタだけになるがRは負荷分散できる

悪いところ
・特になし