[SCM] source code management-centralized authorization of perforce + distributed team + Server Load balancer + scalability + high availability + disaster recovery

 

This article mainly discusses perforce's

* Perforce centralized authorization

* Perforce's support for Distributed teams

* Server Load balancer and scalability of perforce

* Perforce high availability and disaster recovery

 

One perforce centralized authorization

Currently, in many large companies, different departments have different p4servers, which leads to the simultaneous existence of multiple p4servers in the company, as an administrator of p4server, you need more energy to back up and restore all servers and manage the users and permissions of all servers. Generally, a user has an account on multiple p4servers. If the user leaves the company or needs to change the name, the user must delete or modify the account on multiple p4servers.

After the latest version 2010.2, p4server provides a centralized authorization mechanism, which means that the user and permission information of multiple p4servers can be stored in one p4server. This greatly reduces the burden on administrators. For example:

P4d-In server2-a central: 1666-P 1999

 

Server2 uses centralized server central authorization to manage users and permissions. Server2 depends on the user, group, protection, review, and license information of the central server.

In addition to the centralized authorization server, the latest p4server also supports the chagnelist of multiple p4servers to be managed in the same server, so that the company's changelist can be uniquely identified and will not repeat.

The preceding centralized authorization server and changelist server are used to solve the problems of multiple p4servers in the company. If possible, we recommend that you use the unique p4server in the company to avoid a lot of repetitive management work. The following describes the problems that only one p4server may face in the company.

 

Deployment structure of binary p4server

For each p4server, there are two types of data on the server: 1)Source code, Called versioned files; 2) perforce database files, such as DB. Users that contain user information, DB. Changes that contain change, which is also called metadata or database.

 

3. Support for Distributed teams

Perforce can well support the software development of distributed teams of multinational companies. Assume that a multinational company has developers and testers for a product in the United States, India, China, and UK, and p4server (mainserver) is in the United States, we know that the long-distance transmission of files is very slow. How can we enable people in India, China, and the UK to quickly access the source?CodeWhat about it? Perforce provides a proxy mechanism to avoid file transmission problems. You only need to set up a proxy for mianserver in India, China, and UK. Then, when developers in India, China, and UK access the proxy for the first time, the proxy automatically copies the file from the mainserver to the local proxy. In the future, all the local developers will access the file only from the local proxy, this greatly improves the speed for developers to access code.

 

Proxy creation instance:

P4P-P 1999-T central: 1666-r/var/proxyroot

 

Note: The proxy is only used to reduce file transmission and better support development by the distributed team. Therefore, the proxy only automatically copies versioned files to the proxy, and the access to metadata still needs to access mainserver.

 

4. Server Load balancer and scalability of perforce

If a large company only has one p4server, we have to consider the Server Load balancer problem. How can we make the server support access by both developers and backend services without improper machine access. The common practice of Server Load balancer is to separate read/write access. Perforce has a replicated SERVER + broker to achieve load balancing.

The replicated Server is a replication of the mainserver. The replication process is automatically completed in the background. Replicated server is generally used as a read-only server to process read-only operations. You can use P4 pull or P4 replicate to create a replicate server. For example, you can create a replicated server for report or build to reduce access to the mainserver.

To achieve load balancing in a true sense, we also need to use perforce broker as the front-end interfaces of mainserver, proxy and replicated server. When a user accesses the broker, automatically transfers read-only operations to the replicated server, and writes to the proxy or mianserver.

The proxy and replicated server can be expanded with the increase of users, which provides good support for scalability. However, it seems that the extension of mainserver is not supported. :)

 

Note: Generally, the replicated server only serves as a read-only server to share read-only operations to reduce the load on the mainserver. Because the replicated server is automatically synchronized from the mainserver, if the replicatedserver is only read-only, there is no need for reverse synchronization, so no database lock is required, there will be no performance problems. Replicated server can be set as only replicate database files or replicate database + versioned files as needed. For example, you only need to replicated the database for report.

 

5. High Availability and disaster recovery

For perforce, we can perform Backup Recovery to avoid the destruction of the daily p4server. However, for high availability and disaster recovery, the current support for perforce is not very direct and perfect. If a multinational company has a replicated server in multiple locations, when the mainserver is damaged by a disaster, users can still access the replicatedserver for read operations, or we can quickly start the replicated server as the mainserver to shorten the time of the server, achieve a certain degree of high availability and disaster recovery.

 

We can consider applying load balancing, scalability, high availability, and disaster recovery for more general databases to perforce.

 

Complete!