WANdisco Git MultiSite logo

2. Installation Guide

2.1 Before you install

This guide runs through everything you need to know to get Git MultiSite deployed. First we'll cover all the things that you need to have in place before you install. We'll then cover a standard installation and setup. Finally we'll look at some possible problems you might experience with some troubleshooting tips.

Before we install Git MultiSite, we need to ensure that we've got a suitable platform, with sufficient hardware, compatible versions of required software that is configured appropriately.

Skills requirement

This section details the knowledge and technical requirements for deployment and operation of the WANdisco software, you should ensure that each of these sections is addressed before you begin the deployment.

Technical Skill Requirements

System administration
  • Unix operating system installation
  • Disk Management
  • Memory monitoring and management
  • Command Line administration and manually editing configuration files
Apache administration (if applicable)
  • Familiarity with Apache web server architecture
  • Management of httpd.conf / Apache2 configuration file management settings
  • WebDAV protocol
  • Start/stop/restart administration
  • User authentication options
  • Log setup and viewing
Networking
  • IP Address assignation
  • TCP/IP ports and Firewall setup
Git
  • Familiarity with Git administration in order to manage git repositories via the command line
  • Repository creation and/or file-system copying and synchronization
  • Familiarity with WANdisco's replication architecture
  • Understanding of the installation procedure relevant to the OS in use
  • Concept of Node types and Replication groups

If you're not confident about handling any of these tasks, you can request a supported installation from WANdisco.

A single administrator can manage all the systems running MultiSite, although it's a good idea to have someone at each site who is familiar with the MultiSite Basics.

Deployment overview

As with any software implementation you should deploy Git MultiSite following a well defined plan. Doing so will help keep things under control, understood, and any potential problems will be spotted and fixed before you go into production.
We recommend that any deployment plan include the following steps:

System requirements

This section covers everything you need to know when preparing your Git servers for replication. You should view this information as a set of guidelines, not as a fixed set of requirements that are followed slavishly. There are a lot of factors at play and there's really no substitute to running your own performance tests during an evaluation period.

It is possible to run Git MultiSite nodes as virtual machines on the same physical hardware. Please note that this will impact the ability to provide uptime in the event of hardware failure.

If you do want to use virtual machines, make sure your setup is configured to allow for uninterrupted running in the event of a hardware outage.

Hardware Recommendations

Hardware Sizing Guidelines
Size #Users Repository Size (GB) CPU speed (GHz) #CPU #Cores RAM (GB) HDD (GB)
Small 100 25 2 1 2-4 8-16 100
Medium 500 100 2 2 4 16-32 250
Large 1000 500 2.66 4 4 32-64 750
Very Large 5000 1000 2.66 4 4-6 128 1500

Storage tips

Processor tips

Setup requirements

MultiSite Servers must have:

This is a summary of the requirements, you'll need to run through the more detailed Installation Checklist.

Git installations must have:

Requirement
You must run Git and Git MultiSite on the same server.
Alert
A repository can belong to only one replication group at a time.

2.2 Pre-Installation Checklist

Though you may have referred to the Installation Checklist prior to an evaluation of Git MultiSite we strongly recommend that you revisit the checklist and confirm that your system still meets all requirements.

System setup
Operating Systems We've tested the following operating systems:
  • Red Hat Linux Enterprise Server (32 or 64 bit): 6.3

    Running with 32-bit RHEL

    In order to run with 32-bit Red Hat, you will need to edit git-multisite/bin/common.sh and change the maximum Java heap listed in the MEM_HIGH parameter to be 2.5 Gigabytes or less otherwise the replicator will not start.

    MEM_HIGH="-Xms128m -Xmx2621m"
    MEM_LOW="-Xms128m -Xmx1024m"
  • Ubuntu: 12.04 LTS

Go 64-bit

While it's possible to run Git MultiSite on 32-bit architecture, this would impose serious limits on scalability.

For this reason we strongly discourage deploying on anything less than a 64-bit Operating System unless your requirements are limited to a handful of sites and less than a hundred repositories.

Git server
Required Version:
Git MultiSite needs to use WANdisco's own Git distribution, which includes modifications necessary to deploy Git with replicated repositories.

Write access for system user
The replicator user must have write permission for all repositories - as the replicator writes directly to the Git repository.


Manage repository file ownership if using Git+SSH:// or file://
Accessing Git repositories via Apache2+WEBDAV is simplified by the fact that all user access is handled via the same daemon user. Git+SSH or file:// access is a little more tricky, there are potential permission problems when multiple users access the same repository.

Tips:
  • Simplify user management by putting SSH users into a single group, you can then ensure that the group has read-write permissions for the repositories.
  • Make repositories wholly owned by the group.
  • Ensure that the prevailing umask is set to provide suitable permissions (002 instead of the default 022).
  • Use wrapper scripts for certain commands.
Git Binaries
are now available from WANdisco. Providing the latest builds, including modifications required for Git Multisite.
Same location
All replicated repositories must be in the same location (same absolute path) and in exactly the same state before replication can start.
Git client

Any Git client compatible with a Git 1.8 remote repository.

Hooks
  • Hook scripts need to be replicated on all repository replicas
System memory

Minimum recommended: 8 GB RAM; 16 GB swapping container

Disk space
Git: Match to projects and repositories.
MultiSite Transaction Journal: Equivalent of seven days of changes.

To estimate your disk requirements, you need to quantify some elements of your deployment:
  • overall size of all of your Git repositories.
  • frequency of commits in your environment.
  • types of files being modified - text,binaries (Git clients only send deltas for text).
  • number and size of files being changed.
  • rate that new files are being added to the repository.
File descriptor/User process limits

Ensure hard and soft limits are set to 64000 or higher. Check with the ulimit or limit command.
Running lots of repositories
When the replicator is not run as a root user the 'max user processes' needs to be set to a high value otherwise your system won't be able to create the threads required to deploy all your repositories.
User process limits

Maximum processes and open files are low by default on some systems. We recommend that process numbers, file sizes and number of open files are set to unlimited.

Temporary changes for current shell:

ulimit -u unlimited && ulimit -f unlimited && ulimit -n 64000

-f The maximum size of files created by the shell(default option)
-u The maximum number of processes available to a single user
-n The maximum number of open files for a single user

Permanent changes:

RHEL6 and later:

Make the changes in both /etc/security/limits.conf and /etc/security/limits.d/90-nproc.conf:

# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.
* soft nproc 1024   <- Increase this limit or ulimit -u will be reset to 1024
# The asterisk changes values for all users. If you want to change for a specific user, replace it with the username:
gitms soft nproc 65000
gitms hard nproc 65000
gitms soft nofile 65000
gitms hard nofile 65000
gitms soft 

Ubuntu

Changes for Ubuntu should be made in /etc/security/limits.conf:


gitms           soft    nofile  65000
gitms           hard    nofile  65000
gitms           soft    nproc   65000
gitms           hard    nproc   65000

If your user does not see these increased limits you may need to edit further files.

If you are logging in as the MultiSite user, add the following to /etc/pam.d/login:

session	required	pam_limits.so

If you su to the MultiSite user, add the following to /etc/pam.d/su:

session	required	pam_limits.so

If you run commands through sudo you'll need to make the same edit to /etc/pam.d/sudo.

Journaling file system Replicator logs should be on a journaling file system, for example, ext3 on Linux or VXFS from Veritas.
Avoiding Data Loss
We have an article in our Knowledgebase that looks at a number of implementation strategies that will militate against potential data loss as a result of power outages - Data Loss and Linux
Java
Install JDK 7
Use Oracle Java
Our development and testing is done using Oracle JDK 7. While it may be possible to use other Java packages, we will not be able to support you unless you run with Oracle's package.
Python Install version 2.3 or later.
Browser Compatibility

Set up and configuration requires access through a browser, what follows is a basic (not exhaustive) guide to which browsers are known to work:

  • Internet Explorer 8, 9 or 10
  • Firefox 4.0 or later
  • Google Chrome 10.0 or later
  • Safari 5.0.4 or later
  • Opera 10.60 or later
Network settings
Reserved ports

During installation a block of ports is reserved for use by MultiSite, these ports can't be manually edited after installation - make sure you get them right from the start.

Required Ports
dcone.port= An integer / between 1 - 65535 (Default: 6444)
DConE port handles agreement traffic between sites
content.server.port= An integer / between 1 - 65535 (Default: 4321)
The content server port is used for the replicator's payload data: repository changes etc.

delegate.port= An integer / between 1 - 65535 (Default: 7777)
The delegate port is used by Git to delegate write operations to the WANdisco Replicator (via the above contact.server.port)

jetty.http.port= An integer / between 1 - 65535 (Default: 8082)
The jetty port is used for the MultiSite management interface.

jetty.https.port An integer / between 1 - 65535 (Default: 8445)
The jetty port is used for the MultiSite management interface when SSL encryption is enabled.

Make each port different
In contrast with earlier versions of MulitSite which used the same port for both the UI and replication traffic, Git MuliSite doesn't multiplex different traffic on a single port. You will need to assign a different port to each type of traffic.
Firewall or AV software
If your network has a firewall, ensure that traffic is not blocked on the reserved ports noted above. Configure any AV software on your system so that it doesn't block or filter traffic on the reserved ports.

VPN
Set up IPsec tunnel, and ensure WAN connectivity.
VPN persistent connections
Ensure that your VPN doesn't reset persistent connections for Git MultiSite.

Bandwidth

Put your WAN through realistic load testing before going into production. You can then identify and fix potential problems before they impact productivity.

DNS setup
Use IP addresses instead of DNS hostnames, this ensures that DNS problems won't hinder performance. If you are required to use hostnames, test your DNS servers performance and availability prior to going into production.

MultiSite setup
Replication Configuration
Read our Replication Setup Guide for information on how to optimise your replication - Replication Setup.

Voters follow the sun
Git users get the best performance if Git MultiSite gets agreement from the local nodee. For this reason you should schedule for the the voter node to correspond with the location in which developers are active (i.e. in office hours).

Disk space for recovery journal Provision large amounts of disk space for git-multisite/replicator/database, enough space to cover at least the number of commits within a two to four hours during your times of peak Git usage.
License Model

Git MultiSite is supplied through a licensing model based on the numbers of both nodes and Git repository end-users. WANdisco generates a license.key file will be matched to your agreed usage requirements.

Evaluation License

To simplify the process of pre-deployment testing Git MultiSite is supplied with an evaluation license. This type of license imposes no restrictions on use but it time-limited to an agreed period.

Production License

Customers entering production need production license file for each node, these license files are tied to the node server's IP address so care needs to be taken during deployment. In the event that a node needs to be moved to a new server with a different IP customers should contract WANdisco's support team and request that a new license be generated ideally before you transfer the node. Production license can be set to expire or they can be perpetual.

Special Node Types

Git MuliSite offers additional node types that provide limited functionality for special cases where a node only needs to perform in a limit role:

Passive Nodes (Learner only) - A passive node operates like a slave in a master-slave model of distribution. Change to its repository replicas only occur through inbound proposals, it never generates any proposals itself.

Voter-only nodes (Acceptor only)- A voter-only nodes operates in a fashion where they don't need to know the content of proposals, they cast votes based only on the basis of replication history: "have I already voted yes to a Global Order Number equal or larger than this one".

These limited-function nodes are license differently from active nodes. Speak to WANdisco's sales team for more details. In short the IP addresses will be a fixed list but the node count and special node count may move between sets of nodes, as long as the number of each type of node is within the limit specified in the license.key.

2.3 Installation Procedure

The installation guide runs through setting up Git MultiSite for the first time. If you are upgrading from an earlier version of Git MultiSite you should also follow this procedure - Git MultiSite is a completely new class of product so it's not possible to follow a shortcut upgrade procedure.

Installation overview

Before we begin, here is a recap of the installation process:

  • 1. Revisit the Installation Checklist. Taking extra time making sure you have everything set up and ready may save you from running into problems during the installation process. The main boxes you need to tick are:
    • Git authentication: Git installed, and using authentication.
    • JDK: You'll need to be running an Oracle JDK. We recommend JDK 7, but 6 will work, with warnings.
    • Java Memory Settings: The Java process on which Git MultiSite runs is assigned a minimum and maximum amount of system memory, by default it will get 128MB at start up and 4GB Maximum.
    • System resources: Ensure that your system is going to operate with a comfortable margin.
  • 2. Ensure that your repositories are copied into place on all nodes.
  • 3. Download and copy the MultiSite files into place.
  • 4. Run the setup, then complete the installation from a web browser.

First steps

Some things you should bear in mind before starting the installation:

Starting the installation

  • 1. Extract the setup file.
  • 2. Save the wandisco-git-multisite.sh installer file to your Installation site.
  • 3. Make the script executable, e.g. enter the command:
    chmod a+x wandisco-git-multisite.sh
  • 4. Run the setup script.
    
    [root@redhat6 ~]# chmod a+x git-multisite.sh
    [root@redhat6 ~]# ./git-multisite.sh
    Verifying archive integrity... All good.
    Uncompressing WANdisco MultiSite .......
        ::   ::  ::     #     #   ##    ####  ######   #   #####   #####   ##### 
       :::: :::: :::    #     #  #  #  ##  ## #     #  #  #     # #     # #     # 
      ::::::::::: :::   #  #  # #    # #    # #     #  #  #       #       #     # 
     ::::::::::::: :::  # # # # #    # #    # #     #  #   #####  #       #     # 
      ::::::::::: :::   # # # # #    # #    # #     #  #        # #       #     # 
       :::: :::: :::    ##   ##  #  ## #    # #     #  #  #     # #     # #     # 
        ::   ::  ::     #     #   ## # #    # ######   #   #####   #####   #####  
    
    
    
    
    INFO: Using the following Memory settings:
    
    INFO: UI:         -Xms128m -Xmx1024m
    INFO: Replicator: -Xms1024m -Xmx4096m
    
    Do you want to use these settings for the installation? (Y/n) 
    
  • 5. Enter "Y" and click enter.

    Which port should the MultiSite UI listen on? [8080]:

    Confirm the port you wish to run the admin interface on

    We strongly advise against running Git MultiSite as the root user.
    
    Which user should Git MultiSite run as?

    Confirm the user who will run Git Multisite.

    This user will need to have read and write access to your git repos

    Which group should Git MultiSite run as?

    Confirm the group of the user running Git Multisite

    Installing with the following settings:
    
    MultiSite user:    gitms
    MultiSite group:   gitms
    MultiSite UI Port: 8080
    MultiSite UI Minimum memory: 128
    MultiSite UI Maximum memory: 1024
    MultiSite Replicator Minimum memory: 1024
    MultiSite Replicator Maximum memory: 4096
    
    Do you want to continue with the installation? (Y/n)

    Confirm the configuration settings and hit Y to finish the install. In our example, our server will run as gitms with a group of gitms.

  • 10. Open a browser and go to the provided URL. If your server's DNS isn't running you can go to the next step at the following address:
    http://<IP_Adress>:<admin port>/multisite-local
    e.g.
    http://10.0.100.252:8080/

  • 11. The web installer begins with the Welcome screen Welcome to the installation of Git MultiSite.

    Welcome to Git MultiSite.
    You're about to run through the installation, which should only take a couple of minutes.

    If you run into difficulties on the way, check our documentation or talk to our support team through the Customer Support Website.

    Before you click Next, make sure you Read the Installation Checklist

    Click Next to begin the installation.
  • 12. The next (Terms & Conditions) screen contains the WANdisco Master Subscription Agreement.
    To continue the installation click the I AGREE button.
  • 13. On the next (License Upload) screen you are prompted to browse for your product license key file. Click on the + Browse button and locate your file. You will have been sent this by the WANdisco sales team, contact them if you have any problems locating or using your license file.

  • 14. On the Administrator Setup screen you enter the username plus an associated password which you will use to login to Git MultiSite's UI.

    Username
    The administrator's username.
    Password
    The administrator's password.
    Confirm Password
    Enter your password again to confirm that it's been typed in correctly.
    User Interface HTTP Port
    You entered the port during the first part of the installation, it's now possible to choose an alternate port here.
    This port is sometimes referred to as the jetty port.
  • 15. The last screen in the setup process covers Server Settings.

    Node ID

    The default name for this node.

    Temporary limitation
    Node names can not contain spaces or ".".
    Node IP/Host
    The node's IP or hostname. If the server is multi-homed, you can select the IP to which you want Git MultiSite to be associated.
    Latitude
    Git MultiSite schedules changes to replication based on the local time. For this reason we capture the coordinates of the node's location. The default location is close to WANdisco's Sheffield office. You can quickly capture your node's location using one of many online map tools
    Longitude
    The longitude of the server's location.
    Replication Port
    Select the port that will be used for replicated Git repository data. (Default: 6444)
    Content Server Port
    Select the port that will be used to transfer replicated content (repository changes). (Default: 4321)This is different from the port used by WANdisco's DConE2 agreement engine.
    Content Node Count
    This setting gives you the ability to enforce a degree of resiliance. The value represents the number of nodes within a membership that must receive the content before a proposal is submitted for agreement. If the value is greater than the total learners in the current membership, it is adjusted to total learners in the current membership. The proposing node is not considered in the calculation.
    Minimum Content Nodes Required
    Ticking this checkbox will enforce the Content Node Count as a prerequisite for replication.
    REST API Port
    The port to be used for Git MultiSite's REST-based API. (Default: 8082)
    REST API UI Using SSL
    Check box for enabling the use of SSL for all API traffic.
    REST API SSL Port
    The port to be used for Git MultiSite's REST-based API when traffic is secured using SSL encryption. (Default: 8445)
    UI SSL Port
    The port for HTTPS encrypted access to the MultiSite administrative interface. (Default: 8443)
    SSL Certificate Alias
    The name of your SSL Certificate file.
    SSL Key Password
    The password for your HTTPS service.
    SSL Key Store
    The name of the keystore file. The keystore contains the public keys of authorized users.
    SSL Key Store Password
    The password associated with the keystore.
    SSL Trust Store
    The location of your trust store file. The Truststore contains CA certifcates to trust. If your server's certificate is signed by a recognized Certification Authority (CA), the default truststore that ships with the JR will already trust it (because it already trusts trustworthy CAs), so you don’t need to build your own, or to add anything to the one from the JRE.
    SSL Trust Store Password
    The password for your trust store.
    A word about trust stores and key stores

    You might be familiar with the Public-key system that allows two parties to use encryption to keep their communications with each other private (incomprehensible to an intercepting third-party).

    The keystore is used to store the public and private keys that are used in this system. However, iIn isolation, however, the system remains susceptible to the hijacking of the public key file, where an end user may receive a fake public key and be unaware that it will enable communication with an impostor.

    Enter Certificate Authorities (CAs). These trusted third parties issue digital certificates that verify that a given public key matches with the expected owner. These digital certificates are kept in the truststore. An SSL implementation that uses both keystore and truststore files offers a more secure SSL solution.

  • 16. Click FINISH when you have entered everything. The installer will now complete the configuration. Once that's all done a START USING MULTISITE button will appear. Click the button to login for the first time.

  • 17. Time to login. Enter the username and password during step 12. Then click FINISHED - LET'S GO!.
  • 18. The first time you view the dashboard, it will contain mostly blank areas. You can view the reference section to learn what all the buttons and options mean.

Repeat the installation process at all sites

Now repeat section 3 for each node that you wish to share your Git repositories.

You may benefit from creating an image of your initial server, with the repositories in place and using this as a starting point on your other sites - this will help you ensure that your replicas are in exactly the same state.

Same Location
All replicas must be in the same location (same absolute path) and in exactly the same state before replication can start.

2.4 Node Configuration

After installing Git MultiSite at all sites, you'll need to make the sites aware of each other through the node induction process. There's a particular way that you need to run through this process so get another coffee and don't skip this section.

Membership Induction

It's important that nodes are connected together in specific sequence. Run through the following steps to ensure that your sites are all able to talk to each other:

  • 1. When Git MultiSite is installed on all your sites, select one node to be your Inductor. This node will accept requests for membership and share its existing membership information. It doesn't matter which node you select.

    ** Induction overview **
  • 2. Login to this Inductor's admin console (http://<Inductor's IP>:8080/multisite-local/) and gather the following information, most is available from the Settings tab.

    ** Induction overview **

    All your remaining sites are now classed as Inductees.

  • 3. Select one of you remaining Inductee sites. Connect to its web admin console (http://<Inductee1>:8080/multisite-local/) and go to the Nodes tab.

  • 4. Click on the CONNECT TO NODE button and enter the details that you collected from your Inductor node.

    ** Induction overview **
    Node Node ID *
    The name of the inductor node - you can verify this from the NODE ID entry on the Inductor node's Settings tab (see step 2, above.)
    Node Location ID *
    The reference code that is used to define the inductor node's location -you can verify this from the NODE ID entry on the Inductor node's SETTINGS tab (see step 2, above).
    Node IP Address *
    The IP address of the inductor node server.
    Node Port No *
    The DConE Port number (6444 by default), defined on the inductor node's SETTINGS tab.

    When these details are entered, click the SEND CONNECTION REQUEST button. The inductor node will accept the request and add the inductee to its membership. You will need to refresh your browser to see that this has happened..

  • 5. Go back to step 3 and select one of your remaining inductees. Repeat this process until all the sites that you want to be included in the current membership have been connected to the inductor.

Create a Replication Group

Git MultiSite lets you share specific repositories between selected sites. This is done by creating Replication Groups that contain a list of sites and the specific repositories they will share.

** I only live to be born again **

This illustration shows a collection of four sites that are running two replication groups. Replication Group one replicates Repo1 across all four sites, whilst Replication Group 2 replicates repo2 across a subset of sites.

Follow this procedure to create a Replication Group. You can create as many replication groups as you like. However, each repository can only be part of one active replication group at a time.


  • 1. Once you have sites defined, click on the REPLICATION GROUPS tab. Then click on the CREATE REPLICATION GROUP button.
    ** Replication Group Creation 1 **

    Create Replication Group

    Local node automatically made the first member
    It's not possible to create a replication group remotely - the node on which you are creating the group must itself be an member. For this reason, when creating a replication group, the first node is added automatically.
  • 2. Enter a name for your Replication Group in the Replication Group Name field. Then enter an existing Node name in the Add Sites field - any existing sites that match your entry will appear and can be selected with a click. Instead of typing in a name you can click on the drop-down button and choose from a list of existing sites (that are not already members of the new group).

    You can select any number of available Sites. Those sites that you select will appear as clickable buttons in the Add Node field.

    ** This is history **

    Enter a name and add some node.

  • 3. New sites are added as Active Voters (denoted with "AV"). You can change the type of a node by clicking on its label. For an explanation of what each node type does, view the Technical Overview - Available Node Types

    p> ** This is history **

    Change node type

    Once you have added all sites and configured their type, click CREATE REPLICATION GROUP to see a groups details.

  • 4. Replication Groups that you create will be listed on the REPLICATION GROUPS tab.

    ** This is history **

    Groups boxes, click QUICK VIEW view your options.

Add Repositories

Before adding a repo, you should run a git fsck to ensure its integrity.

You may also wish to run a git gc before your git fsck for performance reasons.

Once you have added at least one Replication Group you will be able to add repositories to your node. Here's how:

  • 1. Click on the REPOSITORIES tab. Click on the ADD button.
    ** Add repository 1 **

    Repositories > ADD

  • 2. Enter the Repository's name, the file system path (full path to the repository) and use the drop-down to select the replication group. You can set the repository to be Read-only by ticking the Global Ready-only You can deselect this later. Click ADD REPO.
    ** Add repository 1 **

    Repositories > Enter details then click ADD REPO

  • 3. Once added, a repository will appear in a list on the REPOSITORIES tab. The list provides the following details.
    ** Add repository 1 **

    Repositories listed


    Name
    The name of the repository - this will be the same as the folder name in the Git directory.
    Path
    The full path to the Repository.
    Replication Group
    The Replication Group in which the repository may be replicated.
    Size
    The size of the repository is calculated as the disk space consumed by the repository directory on the node. It is computed when the UI loads the repository information. The value can differ between nodes.
    Youngest Rev
    The youngest (latest) revision in the repository. Comparing the youngest revisions between replicas is a quick test that a repository is in the same state on all sites.
    Last Modified
    The timestamp for the last revision, which provides a quick indicator for the last time a Git user made a change.
    Global RO
    Checkbox that indicates whether the repository is globally Read-only, that is Read-only at all sites.
    Local RO
    Checkbox that indicates whether the repository is locally Read-only, that is Read-only to users at this node. The repository receives updates from the replicas on other sites, but never instigates changes itself.

Using Git Sub-Modules

If you use sub-modules, they are typically defined using the full URL of the repository, for example:

git add submodule test2 git@192.168.1.30:/home/wandisco/repos/subrepo.git

This adds the following into your .gitmodules file:

[submodule "test2"]
path = test2
url = git@192.168.1.30:/home/wandisco/repos/subrepo.git

It is possible to use them in this way, but this means that submodule activity will occur against a specific Git server. If the repository used as a submodule is being replicated through Git MultiSite, you will lose the benefits of using the repository on a local node.

To maintain the benefits of the replicated environment, specify the relationship to the sub-module using a relative path, such as:

git submodule add REPONAME ../RELATIVE-PATH-TO-REPO

For example:

git submodule add ../subrepo.git test2

This would then add the following entry to your .gitmodules file:

[submodule "test2"]
path = test2
url = ../subrepo.git

Note: If you're using external sub-modules, you can continue to specify them using full URLs. This is only applicable to local sub-modules you want replicated.