[p4] Edge server vs forward replica

[Garner Halloran]

Our company is trying to decide whether to use a forward replica or an edge
server and while I understand the basic differences I'd like some help in
determines which one best suits our needs.

Currently we have a master (commit) server in Burbank and a proxy in
Durham. It's the Durham location we want to change.

People from both locations need to be able to sync, edit, integrate, etc
from any of the depots. Edge servers talk about handling things locally
including branch specs and labels. We hardly use labels anymore, but we do
use branch specs for integrating between projects. Can Edge Servers handle
this?

Another reason we want to move away from a proxy is being more self
sufficient. If our VPN goes down, we lose Perforce access. Our tools
require Perforce access. Will either or both handle this situation? Any
caveats?

Thanks!

[Michael Mirman]

Garner -

We are in the process of replacing our forwarding replicas with edge servers.
We think it will take a few more months, but it's definitely worth it.

we do use branch specs for integrating between projects
Can Edge Servers handle this?

Certainly. Integrations are done locally, opening files in the clients on the edge server.

If our VPN goes down, we lose Perforce access. Our tools require Perforce access.
Will either or both handle this situation?

This is a great question. I'd like to say with the 98% certainty, YES.
I'm leaving a couple of percentage points for cases like this:

We understand that not only commands like "p4 commit" is passed through to the commit server, but also things like "branch -i", "stream -i", and other similar commands.
Then, what happens is: the edge server - just like a forwarding replica - will wait until the information that was written on the commit server comes back through the replication channel (pull).
Only after this information comes back and replayed on the edge server, the user gets back control on the command line (or where ever the command was issued).
So, in normal circumstances, we observe a delay when this happens - sometimes small, sometimes not so small - it depends.

If the master goes down, and my "p4 submit" sees it immediately and fails because it could not connect, I don't see any problem.
However, there are other cases, when the server is unresponsive, but the TCP connection goes through.
Now I am stuck.
I think we've had some cases like this, when everything was hung, but it's very rare, and I can't really give a specific workflow that would definitely lead to it.

There are a number of issues we filed with Perforce Support in regards to the edge servers, but almost all of them can be worked around.
The technology is still very young, but all in all, edge servers seem the way to go. :-)

--Michael Mirman
508-647-7555
MathWorks, Inc.
3 Apple Hill Dr, Natick, MA 01760

-----Original Message-----
From: perforce-user-***@perforce.com [mailto:perforce-user-***@perforce.com] On Behalf Of Garner Halloran
Sent: Wednesday, July 09, 2014 2:38 PM
To: perforce-***@perforce.com
Subject: [p4] Edge server vs forward replica

Our company is trying to decide whether to use a forward replica or an edge
server and while I understand the basic differences I'd like some help in
determines which one best suits our needs.

Currently we have a master (commit) server in Burbank and a proxy in
Durham. It's the Durham location we want to change.

People from both locations need to be able to sync, edit, integrate, etc
from any of the depots. Edge servers talk about handling things locally
including branch specs and labels. We hardly use labels anymore, but we do
use branch specs for integrating between projects. Can Edge Servers handle
this?

Another reason we want to move away from a proxy is being more self
sufficient. If our VPN goes down, we lose Perforce access. Our tools
require Perforce access. Will either or both handle this situation? Any
caveats?

Thanks!
_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Garner Halloran]

Very useful, thanks!

I'm now leaning a little more towards edge servers, but I'm also
considering starting with a forward replica and converting it later if I
really need it. How much trouble is the conversion process?

Oh and one more question I forgot. What about shelving with Edge servers?
Are the shelves local or global?

Post by Michael Mirman
Garner -
We are in the process of replacing our forwarding replicas with edge servers.
We think it will take a few more months, but it's definitely worth it.

we do use branch specs for integrating between projects
Can Edge Servers handle this?

Certainly. Integrations are done locally, opening files in the clients on the edge server.

If our VPN goes down, we lose Perforce access. Our tools require

Perforce access.

Will either or both handle this situation?

This is a great question. I'd like to say with the 98% certainty, YES.
We understand that not only commands like "p4 commit" is passed through to
the commit server, but also things like "branch -i", "stream -i", and other
similar commands.
Then, what happens is: the edge server - just like a forwarding replica -
will wait until the information that was written on the commit server comes
back through the replication channel (pull).
Only after this information comes back and replayed on the edge server,
the user gets back control on the command line (or where ever the command
was issued).
So, in normal circumstances, we observe a delay when this happens -
sometimes small, sometimes not so small - it depends.
If the master goes down, and my "p4 submit" sees it immediately and fails
because it could not connect, I don't see any problem.
However, there are other cases, when the server is unresponsive, but the
TCP connection goes through.
Now I am stuck.
I think we've had some cases like this, when everything was hung, but it's
very rare, and I can't really give a specific workflow that would
definitely lead to it.
There are a number of issues we filed with Perforce Support in regards to
the edge servers, but almost all of them can be worked around.
The technology is still very young, but all in all, edge servers seem the way to go. :-)
--Michael Mirman
508-647-7555
MathWorks, Inc.
3 Apple Hill Dr, Natick, MA 01760
-----Original Message-----
Sent: Wednesday, July 09, 2014 2:38 PM
Subject: [p4] Edge server vs forward replica
Our company is trying to decide whether to use a forward replica or an edge
server and while I understand the basic differences I'd like some help in
determines which one best suits our needs.
Currently we have a master (commit) server in Burbank and a proxy in
Durham. It's the Durham location we want to change.
People from both locations need to be able to sync, edit, integrate, etc
from any of the depots. Edge servers talk about handling things locally
including branch specs and labels. We hardly use labels anymore, but we do
use branch specs for integrating between projects. Can Edge Servers handle
this?
Another reason we want to move away from a proxy is being more self
sufficient. If our VPN goes down, we lose Perforce access. Our tools
require Perforce access. Will either or both handle this situation? Any
caveats?
Thanks!
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Michael Mirman]

Easy questions this time. ;)


Ø How much trouble is the conversion process?

Not too much.
The biggest problem of the conversion that I see is the archive.
However, in your case, you will probably have the archive *not* NFS-shared since your geographic location is different.
In that case, you should be OK.

What I would do is this:

- Create a different server id for the edge server;

- Wait until the replica gets in sync with the master;

- Shut down the replica;

- Remove several db files (the way Perforce documented – let me know if you don’t know where – I can find it);

- Update the serverid on disk in the P4ROOT directory;

- Restart the server with a different server id.

I’m sort of thinking out loud, but it should work.
Alternatively, you can rebuild the server from a checkpoint. I would just save time since the replica is in sync with the master. After a restart it will continue replicating whatever happened on the master in the meantime.

More importantly IMHO is to figure out the DR strategy and maintenance.
One-time conversion is relatively easy. Maintenance is a whole different matter.

You may have some DR approach for the master. How will it work for the edge server?
Do you do fail-overs of the master?
You have to deal with replicas, so they would correctly “switch” from the old server to the new one.
The same thing – but somewhat more complex – is with the edge server.

We still have a number of wrinkles of the failover process, and having edge servers in the infrastructure further complicates the situation.
Test it well before going into production.

--Mike

From: Garner Halloran [mailto:***@gmail.com]
Sent: Wednesday, July 9, 2014 8:11 PM
To: Michael Mirman
Cc: perforce-***@perforce.com
Subject: Re: [p4] Edge server vs forward replica

Very useful, thanks!

I'm now leaning a little more towards edge servers, but I'm also considering starting with a forward replica and converting it later if I really need it. How much trouble is the conversion process?

Oh and one more question I forgot. What about shelving with Edge servers? Are the shelves local or global?

On Wed, Jul 9, 2014 at 3:29 PM, Michael Mirman <***@mathworks.com<mailto:***@mathworks.com>> wrote:
Garner -

We are in the process of replacing our forwarding replicas with edge servers.
We think it will take a few more months, but it's definitely worth it.

we do use branch specs for integrating between projects
Can Edge Servers handle this?

Certainly. Integrations are done locally, opening files in the clients on the edge server.

If our VPN goes down, we lose Perforce access. Our tools require Perforce access.
Will either or both handle this situation?

This is a great question. I'd like to say with the 98% certainty, YES.
I'm leaving a couple of percentage points for cases like this:

We understand that not only commands like "p4 commit" is passed through to the commit server, but also things like "branch -i", "stream -i", and other similar commands.
Then, what happens is: the edge server - just like a forwarding replica - will wait until the information that was written on the commit server comes back through the replication channel (pull).
Only after this information comes back and replayed on the edge server, the user gets back control on the command line (or where ever the command was issued).
So, in normal circumstances, we observe a delay when this happens - sometimes small, sometimes not so small - it depends.

If the master goes down, and my "p4 submit" sees it immediately and fails because it could not connect, I don't see any problem.
However, there are other cases, when the server is unresponsive, but the TCP connection goes through.
Now I am stuck.
I think we've had some cases like this, when everything was hung, but it's very rare, and I can't really give a specific workflow that would definitely lead to it.

There are a number of issues we filed with Perforce Support in regards to the edge servers, but almost all of them can be worked around.
The technology is still very young, but all in all, edge servers seem the way to go. :-)

--Michael Mirman
508-647-7555<tel:[phone]>
MathWorks, Inc.
3 Apple Hill Dr, Natick, MA 01760

-----Original Message-----
From: perforce-user-***@perforce.com<mailto:perforce-user-***@perforce.com> [mailto:perforce-user-***@perforce.com<mailto:perforce-user-***@perforce.com>] On Behalf Of Garner Halloran
Sent: Wednesday, July 09, 2014 2:38 PM
To: perforce-***@perforce.com<mailto:perforce-***@perforce.com>
Subject: [p4] Edge server vs forward replica

Our company is trying to decide whether to use a forward replica or an edge
server and while I understand the basic differences I'd like some help in
determines which one best suits our needs.

Currently we have a master (commit) server in Burbank and a proxy in
Durham. It's the Durham location we want to change.

People from both locations need to be able to sync, edit, integrate, etc
from any of the depots. Edge servers talk about handling things locally
including branch specs and labels. We hardly use labels anymore, but we do
use branch specs for integrating between projects. Can Edge Servers handle
this?

Another reason we want to move away from a proxy is being more self
sufficient. If our VPN goes down, we lose Perforce access. Our tools
require Perforce access. Will either or both handle this situation? Any
caveats?

Thanks!
_______________________________________________
perforce-user mailing list - perforce-***@perforce.com<mailto:perforce-***@perforce.com>
http://maillist.perf

[P4Lester]

Posted on behalf of forum user 'P4Lester'.

Quick answer: edge servers does more locally without the help from the commit
server. Forwarding replicas would pass all write commands over so there is more
(mostly network) overhead.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3412-edge-server-vs-forward-replica

[Michael Mirman]

I wonder if there is a whitepaper describing exactly what is passed to the commit server.

As we discovered yesterday, the command "p4 client -i" is *not* completely contained on the edge server, but rather needs to communicate with the commit server.
This is perfectly reasonable, and I am looking for insights what else may need the access to the commit server (besides obvious branch, label, protect, etc).
Another example I can think of is exclusive locking.

This is important as during the maintenance on the commit server we need to cut off the access to it from the edge servers, and we're considering different options how to do it.
One option would be to make the broker in front of the edge server reject all commands that may write something to the commit server.

--Michael Mirman
508-647-7555
MathWorks, Inc.
3 Apple Hill Dr, Natick, MA 01760

-----Original Message-----
From: perforce-user-***@perforce.com [mailto:perforce-user-***@perforce.com] On Behalf Of P4Lester
Sent: Wednesday, July 09, 2014 11:20 PM
To: perforce-***@perforce.com
Subject: Re: [p4] Edge server vs forward replica


Posted on behalf of forum user 'P4Lester'.

Quick answer: edge servers does more locally without the help from the commit
server. Forwarding replicas would pass all write commands over so there is more
(mostly network) overhead.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3412-edge-server-vs-forward-replica
_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

[P4TomT]

Posted on behalf of forum user 'P4TomT'.

When deciding what technology is best for users at remote sites, here's how
I view the major options:

Terms: HA - High Availability, DR - Disaster Recovery.

Level 0: No IT Support
* Encourage users to set 'compress' feature of a workspace, and connect
directly to the server from far away.
* Users can do this thsemelves when there's no IT support
* Note that the 'compress' feature is not needed when using a proxy,
forwarding replica, or edge.

Level 1: Proxy
* Reduces WAN bandwidth requirements.
* Near-zero maintenance requirements once installed.��Reduces network
bandwidth and speeds up sync operations.
* Simple technology.
* No need to backup, so no impact to HA/DR strategies.

Level 2: Forwarding replica
* Reduces WAN bandwidth requirements over a proxy.
* Reduces response times for a wider range of user operations, compared to a
simple Proxy.
* More sophisticated technology, requries more TLC (e.g. occasional reseeding
during upgrades, replication monitoring, etc.).
* No need to backup, so no impact to HA/DR strategies.

Level 3: Edge Server
* Reduces response times for a wider range of user operations, compared to a
basic Forwarding Replica.
* State-of-the-art technology, requries more TLC (e.g. occasional reseeding
during upgrades, replication monitoring, etc.).
* Must be checkpointed and backed up.��Unlike Level 0-2 solutions,
Edge Servers have unique data origniation and in some cases living only at the
remote site.
* HA and DR scenarios have more permutations of what can break, and what
you'd need to do to recover.��It's a more sophisticated world.
* If you invest in HA, you may require a local HA solution at each edge
site.��For this purpose, you can daisy-chain a read-only replica from
the edge server at each site, to provide alocal backup of the edge server.
* New Terms:��"Distributed Edge" is a normal edge server to
which humans connect directly.��A "Build Edge" is an edge
server used to relace a build-server replica.��Same technology, but
the distinction is that, because only robots (no humans) connect directly to it,
you decide not to back it up or proivde HA/DR solution for it.��If you
lose it, just build a replacement starting from scratch, sacrificaing the local
data (whose value is transient anyway).

All these solutions require a continuous network connection to the master/commit
server to function normally.��Edge servers are the least dependent on
the connection, but functionality when disconnected is still extremely
limited.��The technology provides a much better experience and faster
response in a globally distributed environment, but is not designed to work well
when the network connection is lost.��(I'm speaking as of P4D
2014.1).



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3412-edge-server-vs-forward-replica

[Michael Mirman]

Edge servers are the least dependent on the connection, but functionality when disconnected is still extremely limited.
(I'm speaking as of P4D 2014.1)

This is totally true for 2016.1, too.
Some of the reasons are that db.domain (as well as some other db tables) need to be updated very frequently on the commit server and then that information must be replicated to other edge servers.
Besides obvious global resources like change numbers, all changes in clients, which from user's perspective are kept on edge servers, are sent to the commit server. If the network connection is lost, the edge server soon gets to a complete stall.
--
Michael Mirman
MathWorks, Inc.
508-647-7555

-----Original Message-----
From: perforce-user [mailto:perforce-user-***@perforce.com] On Behalf Of mrose
Sent: Thursday, December 8, 2016 8:05 PM
To: perforce-***@perforce.com
Subject: Re: [p4] Edge server vs forward replica

Posted on behalf of forum user 'mrose'.



[http://forums.perforce.com/index.php?app=forums&module=forums&section=findpost&pid=14509]

All these solutions require a continuous network connection to the master/commit server to function normally.��Edge servers are the least dependent on the connection, but functionality when disconnected is still extremely limited.��The technology provides a much better experience and faster response in a globally distributed environment, but is not designed to work well when the network connection is lost.��(I'm speaking as of P4D 2014.1).

P4TomT: Is there any new/different information related to version 2016.2?