Horizontal and Vertical Fragmentation on Distributed Database
The typical method employed where you need to replicate the data to both servers is to use a NEWSEQUENTIALID() as the default value for the primary key columns.

From the Microsoft Documentation for NEWSEQUENTIALID():


  Creates a GUID that is greater than any GUID previously generated by this function on a specified computer since Windows was started. After restarting Windows, the GUID can start again from a lower range, but is still globally unique.


SQL Server uses the UuidCreateSequential function to generate globally unique identifiers.  This function guarantees that no duplicates will be generated when used in a machine with a manufacturer-assigned ethernet MAC address.  If you are using virtual machines with locally generated MAC addresses where those MAC addresses are not guaranteed to be unique there is a slight possibility that the values will not be unique.

An example CREATE TABLE statement for your location table:

CREATE TABLE dbo.Locations
(
    LocationID uniqueidentifier NOT NULL
        CONSTRAINT Locations_PK
        PRIMARY KEY CLUSTERED
        CONSTRAINT Locations_PK_DF
        DEFAULT NEWSEQUENTIALID()
        ROWGUIDCOL
    , LocationName varchar(48) NOT NULL
) ON [PRIMARY];


Inserting location values looks like:

INSERT INTO dbo.Locations (LocationName)
VALUES ('Cydonia')
    , ('Utopia Planitia');


The inserted row now looks something like:

SELECT l.LocationID
    , l.LocationName
FROM dbo.Locations l;


╔══════════════════════════════════════╦═════════════════╗
║              LocationID              ║  LocationName   ║
╠══════════════════════════════════════╬═════════════════╣
║ A6044A1D-E286-E911-9C54-005056807260 ║ Cydonia         ║
║ A7044A1D-E286-E911-9C54-005056807260 ║ Utopia Planitia ║
╚══════════════════════════════════════╩═════════════════╝

I've created the same table structure on a second server; here we're inserting different rows on that server:

INSERT INTO dbo.Locations (LocationName)
VALUES ('Copernicus Crater')
    , ('Mare Imbrium');

SELECT l.LocationID
    , l.LocationName
FROM dbo.Locations l;


╔══════════════════════════════════════╦═══════════════════╗
║              LocationID              ║   LocationName    ║
╠══════════════════════════════════════╬═══════════════════╣
║ A27E42F8-E286-E911-94B4-9CB6D0087DC0 ║ Copernicus Crater ║
║ A37E42F8-E286-E911-94B4-9CB6D0087DC0 ║ Mare Imbrium      ║
╚══════════════════════════════════════╩═══════════════════╝

As you can see in the two sets of output shown above, each row has a unique LocationID value.  The values aren't generated in random order, they are generated sequentially, which is important for insert performance since it will limit fragmentation via page splits.  Be aware, however, those sequential starting points will change whenever the server hosting SQL Server is restarted.

Merge replication, which is a feature included in all versions of SQL Server from Standard to Enterprise (not SQL Server Express), automatically replicates rows between both servers.  The ROWGUIDCOL property included in the CREATE TABLE statement marks the LocationID column for use by Merge Replication.  Directions for setting up Merge Replication are beyond the scope of this answer.

Once Merge Replication completes, both servers will have this in their dbo.Locations table:

╔══════════════════════════════════════╦═══════════════════╗
║              LocationID              ║  LocationName     ║
╠══════════════════════════════════════╬═══════════════════╣
║ A27E42F8-E286-E911-94B4-9CB6D0087DC0 ║ Copernicus Crater ║
║ A37E42F8-E286-E911-94B4-9CB6D0087DC0 ║ Mare Imbrium      ║
║ A6044A1D-E286-E911-9C54-005056807260 ║ Cydonia           ║
║ A7044A1D-E286-E911-9C54-005056807260 ║ Utopia Planitia   ║
╚══════════════════════════════════════╩═══════════════════╝