You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by ana kish <an...@gmail.com> on 2013/01/22 07:57:39 UTC
Hardware requirements
Hi All,
I would like to know the hardware requirements for SVN server.
We would be having around 10 developers are going to use server
simultaneously.
the code of the project could be around 150 MB.
We were thinking about using a Windows VM machine for this.
Is it ok to go with VM?
Please advise how much RAM to be allocated and how much harddisk space we
would be requiring for setting up the server.
Thanks & Regards
Kishore
Re: Hardware requirements
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Tue, Jan 22, 2013 at 7:18 AM, Stefan Sperling <st...@elego.de> wrote:
> On Tue, Jan 22, 2013 at 12:27:39PM +0530, ana kish wrote:
>> Is it ok to go with VM?
>
> If you go with a VM, I would advise not to put the repositories onto
> a virtual disk image, but on an iscsi disk or SAN that is connected
> to the VM via network.
>
> I've seen a bad case of repository corruption where the repositories
> on a virtual disk were broken after the host system of the VM had
> unexpectedly lost power. Upon reboot revision files in the VM were there
> but they contained corrupt 512 byte blocks (disk sector size). So the
> virtual disk could not properly save data to the physical disk in this
> case. Network disks are better designed to handle failure cases like this.
The same risk is true of any storage, to one degree or another. I've
found iSCSI to be really underwhelming under load.
Backup is *critical* for a production server. Seriously consider
setting up an svnsynced offsite repository and backing up from *that*,
to help ensure that the backups occur between the necessarily atomic
operations of any database.
> If you must use a virtual disk in the VM to host the repositories,
> make sure you have a backup procedure in place that copies revision
> data off the virtual disk as soon as possible (e.g. run 'svnadmin dump
> --incremental' from the post-commit hook and copy the resulting dump
> file to another machine).
I've had good success with svnsync. Neither svnsync nor svnadmin dump
replicate other Subverson configurations, such as Subversion file
ownership or post-commit or authentication or Apache access
configurations, so review how those are replicated for failover as
well.
Re: Hardware requirements
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Jan 22, 2013 at 12:27:39PM +0530, ana kish wrote:
> Is it ok to go with VM?
If you go with a VM, I would advise not to put the repositories onto
a virtual disk image, but on an iscsi disk or SAN that is connected
to the VM via network.
I've seen a bad case of repository corruption where the repositories
on a virtual disk were broken after the host system of the VM had
unexpectedly lost power. Upon reboot revision files in the VM were there
but they contained corrupt 512 byte blocks (disk sector size). So the
virtual disk could not properly save data to the physical disk in this
case. Network disks are better designed to handle failure cases like this.
If you must use a virtual disk in the VM to host the repositories,
make sure you have a backup procedure in place that copies revision
data off the virtual disk as soon as possible (e.g. run 'svnadmin dump
--incremental' from the post-commit hook and copy the resulting dump
file to another machine).
Re: Hardware requirements
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Tue, Jan 22, 2013 at 9:11 AM, Andy Levy <an...@gmail.com> wrote:
>
>
> On Tue, Jan 22, 2013 at 7:38 AM, Thorsten Schöning <ts...@am-soft.de>
> wrote:
>>
>> Guten Tag ana kish,
>> am Dienstag, 22. Januar 2013 um 07:57 schrieben Sie:
>>
>> > We were thinking about using a Windows VM machine for this. Is
>> > it ok to go with VM?
>>
>> In general yes and besides what others think if you already have
>> Windows experience and Windows users just use Windows, there's really
>> no need to waste any time with Linux if you don't already have
>> experience with it. Windows is safe, it is stable and it is easy to
>> backup, especially as using a VM the problem isn't the guest at all,
>> but how you save the VM. Using working copies on network shares for
>> Windows clients would be a main reason for me to use a Windows Server
>> as Samba sounds good in general but things like authenticating users,
>> ACLs etc. are much easier with using Windows as server and client OS,
>> especially if you have limited experience with Linux and Samba.
>> It's just wasted time...
If you are using filesystem based access control to Subversion
repositories, you are already in deep trouble. Whether it's direct
file-based access on the relevant Windows server to check out local
working copies, or CIFS based network share access, there are some
real risks of corrupting the repository accidentally for anyone with
file system access to a Subversion server. And managing pre- or
post-script tools for multiple Windows, Linux, UNIX, or MacOS CIFS
clients that might also have access is a nightmare.
Subversion has a lightweight, flexible access structure with svn.conf
or in Apache configurations that should be more than sufficient for
only 10 users.
> The biggest challenges (IME) in running Subversion on Windows are:
>
> 1) Hook scripts. Because BAT files suck, and getting messages from other
> scripts called by your BAT files back to the client is a pain. You could
> compile an EXE, but that just adds another layer to the hook development
> process.
> 2) Case insensitivity
Big exclamation points on this one.
> For #2: If your repository is in d:\repos\Code and you have SVNParentPath
> pointed at d:\repos, and your per-directory authz specifies repos:/Code,
> anyone attempting operations against http://server/parent/Code will succeed
> but http://server/parent/code will get an error. However, if you allow
> anonymous read but require authentication for write, users can check out
> from http://server/parent/code because Apache will find it either way (due
> to NTFS being case-preserving but not sensitive, by default), but it will
> throw a 403 error when you attempt to commit, because that path isn't found
> in the authz file.
Re: Hardware requirements
Posted by Andy Levy <an...@gmail.com>.
On Tue, Jan 22, 2013 at 7:38 AM, Thorsten Schöning <ts...@am-soft.de>wrote:
> Guten Tag ana kish,
> am Dienstag, 22. Januar 2013 um 07:57 schrieben Sie:
>
> > We were thinking about using a Windows VM machine for this. Is
> > it ok to go with VM?
>
> In general yes and besides what others think if you already have
> Windows experience and Windows users just use Windows, there's really
> no need to waste any time with Linux if you don't already have
> experience with it. Windows is safe, it is stable and it is easy to
> backup, especially as using a VM the problem isn't the guest at all,
> but how you save the VM. Using working copies on network shares for
> Windows clients would be a main reason for me to use a Windows Server
> as Samba sounds good in general but things like authenticating users,
> ACLs etc. are much easier with using Windows as server and client OS,
> especially if you have limited experience with Linux and Samba.
> It's just wasted time...
>
> Said that, things like using Subversion through a web server like httpd
> may be better supported on current Linux distributions, I would
> personally avoid any situation where I would need to compile anything
> for httpd and Subversion on Windows on my own. Therefore if I were you
> I would first decide on how your users will mainly access the repos and
> afterwards look which OS serves best. This doesn't mean that httpd and
> Subversion won't work on Windows, just that they may be situations
> were some modules aren't current enough or whatever.
>
>
Do people find themselves having to compile their own Apache & modules for
Windows often? There are lots of pre-built distributions which include
Apache.
One big win with running a distribution like VisualSVN Server (which uses
Apache) on Windows is the easy integration with your pre-existing Active
Directory infrastructure.
The biggest challenges (IME) in running Subversion on Windows are:
1) Hook scripts. Because BAT files suck, and getting messages from other
scripts called by your BAT files back to the client is a pain. You could
compile an EXE, but that just adds another layer to the hook development
process.
2) Case insensitivity
For #2: If your repository is in d:\repos\Code and you have SVNParentPath
pointed at d:\repos, and your per-directory authz specifies repos:/Code,
anyone attempting operations against http://server/parent/Codewill
succeed but
http://server/parent/code will get an error. However, if you allow
anonymous read but require authentication for write, users can check out
from http://server/parent/code because Apache will find it either way (due
to NTFS being case-preserving but not sensitive, by default), but it will
throw a 403 error when you attempt to commit, because that path isn't found
in the authz file.
Re: Hardware requirements
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag ana kish,
am Dienstag, 22. Januar 2013 um 07:57 schrieben Sie:
> We were thinking about using a Windows VM machine for this. Is
> it ok to go with VM?
In general yes and besides what others think if you already have
Windows experience and Windows users just use Windows, there's really
no need to waste any time with Linux if you don't already have
experience with it. Windows is safe, it is stable and it is easy to
backup, especially as using a VM the problem isn't the guest at all,
but how you save the VM. Using working copies on network shares for
Windows clients would be a main reason for me to use a Windows Server
as Samba sounds good in general but things like authenticating users,
ACLs etc. are much easier with using Windows as server and client OS,
especially if you have limited experience with Linux and Samba.
It's just wasted time...
Said that, things like using Subversion through a web server like httpd
may be better supported on current Linux distributions, I would
personally avoid any situation where I would need to compile anything
for httpd and Subversion on Windows on my own. Therefore if I were you
I would first decide on how your users will mainly access the repos and
afterwards look which OS serves best. This doesn't mean that httpd and
Subversion won't work on Windows, just that they may be situations
were some modules aren't current enough or whatever.
I preferred running svnserve on Windows for years without any
problems, the repos used FSFS as backend. You even have the
opportunity to switch the repos to Linux by just moving all files,
at least in the current versions of FSFS/Subversion/whatever. I've
done that recently to consolidate our old Windows Server to a current
Ubuntu LTS without any problems.
> Please advise how much RAM to be allocated and
> how much harddisk space we would be requiring for setting up the server.
Don't waste to much time thinking of those things as especially in VMs
you can almost always just add more RAM and haddisk space. Even a
current 64 Bit Windows server should work quite well with just 2 GB of
RAM and whatever space you think you will need for your repos in
future, Windows itself may recommend something about 25 or 35 GB.
Every modern OS and filesystem can be extended online, I already did
it on Windows Server 2008 R2 x64 without problems.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Hardware requirements
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Tue, Jan 22, 2013 at 1:57 AM, ana kish <an...@gmail.com> wrote:
> Hi All,
> I would like to know the hardware requirements for SVN server.
> We would be having around 10 developers are going to use server
> simultaneously.
> the code of the project could be around 150 MB.
That's quite modest.
> We were thinking about using a Windows VM machine for this.
> Is it ok to go with VM?
VM's are fine. Windows as a server, though, is generally a bad idea.
They're notorious security issues, they're not the OS the software was
written for, they're tougher to back up, and they're burdened with a
lot of unnecessary system debris that a Subversion server absolutely
does not need.
A lightweight Linux (or even UNIX) system will leave far more of your
CPU and memory resources for actually running the server.
> Please advise how much RAM to be allocated and how much harddisk space we
> would be requiring for setting up the server.
If I were installing an RHEL or Scientific Linux 6.3 system, I'd
allocate 10 Gig of disk for the OS itself (which is very generous) and
start out by allocating 10 Gig on a separate disk image, or LVM
partition, mounted at /var/www/svn, with 2 Gig of RAM. That's plenty
for a lightly used system with modest web or SSH based access, with
reasonable space for access logging and buidling any little widgets
you might want to compile for the server itself. If they project has a
lot of churn, or if you set up a CIFS service for developers to access
a network share and do their Subversion working copies on it, I'd
consider adding a a separate virtual disk for that. Samba is quite
good for this, and retains the network flexibility and namespace
handling of Linux or UNIX while serving the file sharing needs of
Windows users quite well.
I would *never* run a high availability or security sensitive system,
such a Subversion server, on a Windows OS if I could reasonably aboid
it.
> Thanks & Regards
> Kishore
RE: Hardware requirements
Posted by "Cooke, Mark" <ma...@siemens.com>.
Hello,
> -----Original Message-----
> From: ana kish [mailto:anakish1980@gmail.com]
> Sent: 22 January 2013 06:58
> To: users@subversion.apache.org
> Subject: Hardware requirements
>
> Hi All,
> I would like to know the hardware requirements for SVN server.
> We would be having around 10 developers are going to use
> server simultaneously.
> the code of the project could be around 150 MB.
> We were thinking about using a Windows VM machine for this.
> Is it ok to go with VM?
I use a VM with 1vCPU and 1024MB RAM to support a similar number of users across quite a few projects with much more code. As most of the work is done on the developer's systems and not on the server, it doesn't need to be very beefy. We also run Trac on the same server with both Trac and svn hosted by apache.
~ Mark C
> Please advise how much RAM to be allocated and how much
> harddisk space we would be requiring for setting up the server.
>
> Thanks & Regards
> Kishore
>