Commit 06ab453c authored by James Ramsay's avatar James Ramsay

Update links

parent 0c047594
Pipeline #17640864 passed with stages
in 49 seconds
......@@ -10,7 +10,7 @@ from source**](configuration_source.md) guide.
>**Note:**
This is the final step in setting up a secondary Geo node. Stages of the
setup process must be completed in the documented order.
Before attempting the steps in this stage, [complete all prior stages](README.md#using-omnibus-gitlab).
Before attempting the steps in this stage, [complete all prior stages](index.md#using-omnibus-gitlab).
The basic steps of configuring a secondary node are to replicate required
configurations between the primary and the secondaries; to configure a tracking
......@@ -90,7 +90,7 @@ with the same credentials as used in the primary.
GitLab integrates with the system-installed SSH daemon, designating a user
(typically named git) through which all access requests are handled.
In a [Disaster Recovery](../disaster_recovery/index.md) situation, GitLab system
In a [Disaster Recovery](../../disaster_recovery/index.md) situation, GitLab system
administrators will promote a secondary Geo replica to a primary and they can
update the DNS records for the primary domain to point to the secondary to prevent
the need to update all references to the primary domain to the secondary domain,
......@@ -144,7 +144,7 @@ keys must be manually replicated to the secondary node.
>**Warning**
Hashed storage is in **Beta**. It is not considered production-ready. See
[Hashed Storage](../repository_storage_types.md) for more detail,
[Hashed Storage](../../repository_storage_types.md) for more detail,
and for the latest updates, check
[infrastructure issue #2821](https://gitlab.com/gitlab-com/infrastructure/issues/2821).
......@@ -155,7 +155,7 @@ renames no longer require synchronization between nodes.
(`/admin/application_settings`) in your browser
1. In the `Repository Storages` section, check `Create new projects using hashed storage paths`:
![](img/hashed-storage.png)
![](img/hashed_storage.png)
### Step 4. (Optional) Configuring the secondary to trust the primary
......@@ -187,7 +187,7 @@ The initial replication, or 'backfill', will probably still be in progress. You
can monitor the synchronization process on each geo node from the primary
node's Geo Nodes dashboard in your browser.
![Geo dashboard](img/geo-node-dashboard.png)
![Geo dashboard](img/geo_node_dashboard.png)
If your installation isn't working properly, check the
[troubleshooting document](troubleshooting.md).
......
......@@ -10,7 +10,7 @@ using the Omnibus GitLab packages, follow the
>**Note:**
This is the final step in setting up a secondary Geo node. Stages of the setup
process must be completed in the documented order. Before attempting the steps
in this stage, [complete all prior stages](README.md#using-gitlab-installed-from-source).
in this stage, [complete all prior stages](index.md#using-gitlab-installed-from-source).
The basic steps of configuring a secondary node are to replicate required
configurations between the primary and the secondaries; to configure a tracking
......
......@@ -273,7 +273,7 @@ because we have not yet configured the secondary server. This is the next step.
sudo -i
```
1. [Check TCP connectivity](../raketasks/maintenance.md) to the
1. [Check TCP connectivity](../../raketasks/maintenance.md) to the
primary's PostgreSQL server:
```bash
......@@ -490,4 +490,4 @@ Read the [troubleshooting document](troubleshooting.md).
[external postgresql]: #external-postgresql-instances
[tracking]: database_source.md#enable-tracking-database-on-the-secondary-server
[FDW]: https://www.postgresql.org/docs/9.6/static/postgres-fdw.html
[toc]: README.md#using-omnibus-gitlab
[toc]: index.md#using-omnibus-gitlab
......@@ -392,4 +392,4 @@ Read the [troubleshooting document](troubleshooting.md).
[pgback]: http://www.postgresql.org/docs/9.6/static/app-pgbasebackup.html
[replication user]:https://wiki.postgresql.org/wiki/Streaming_Replication
[FDW]: https://www.postgresql.org/docs/9.6/static/postgres-fdw.html
[toc]: README.md#using-gitlab-installed-from-source
[toc]: index.md#using-gitlab-installed-from-source
......@@ -6,7 +6,7 @@ secondary Geo node that mirrors the one on the primary Geo node.
## Storage support
CAUTION: **Warning:**
If you use [local storage](../container_registry.md#container-registry-storage-driver)
If you use [local storage](../../container_registry.md#container-registry-storage-driver)
for the Container Registry you **cannot** replicate it to the secondary Geo node.
Docker Registry currently supports a few types of storages. If you choose a
......@@ -15,6 +15,6 @@ Registry on a primary Geo node, you can use the same storage for a secondary
Docker Registry as well. For more information, read the
[Load balancing considerations](https://docs.docker.com/registry/deploying/#load-balancing-considerations)
when deploying the Registry, and how to setup the storage driver for GitLab's
integrated [Container Registry](../container_registry.md#container-registry-storage-driver).
integrated [Container Registry](../../container_registry.md#container-registry-storage-driver).
[ee]: https://about.gitlab.com/products/
......@@ -5,7 +5,7 @@
Yes, but there are limitations to what we replicate (see
[What data is replicated to a secondary node?](#what-data-is-replicated-to-a-secondary-node)).
Read the documentation for [Disaster Recovery](../disaster_recovery/index.md).
Read the documentation for [Disaster Recovery](../../disaster_recovery/index.md).
## What data is replicated to a secondary node?
......
......@@ -6,7 +6,7 @@ described, it is possible to adapt these instructions to your needs.
## Architecture overview
![Geo HA Diagram](../img/high_availability/geo-ha-diagram.png)
![Geo HA Diagram](../../img/high_availability/geo-ha-diagram.png)
_[diagram source - gitlab employees only](https://docs.google.com/drawings/d/1z0VlizKiLNXVVVaERFwgsIOuEgjcUqDTWPdQYsE7Z4c/edit)_
......@@ -33,8 +33,8 @@ The two services will instead be configured such that
they will each run on a single machine.
For more information about setting up a highly available PostgreSQL cluster and Redis cluster using the omnibus package see the high availability documentation for
[PostgreSQL](../high_availability/database.md) and
[Redis](../high_availability/redis.md), respectively.
[PostgreSQL](../../high_availability/database.md) and
[Redis](../../high_availability/redis.md), respectively.
From these instructions you will need the following for the examples below:
* `gitlab_rails['db_password']` for the PostgreSQL "DB password"
......@@ -53,18 +53,18 @@ Make sure you have GitLab EE installed using the
On the **primary** backend servers configure the following services:
* [Redis](../high_availability/redis.md) for high availability.
* [NFS Server](../high_availability/nfs.md) for repository, LFS, and upload storage.
* [PostgreSQL](../high_availability/database.md) for high availability.
* [Redis](../../high_availability/redis.md) for high availability.
* [NFS Server](../../high_availability/nfs.md) for repository, LFS, and upload storage.
* [PostgreSQL](../../high_availability/database.md) for high availability.
On the **secondary** backend servers configure the following services:
* [Redis](../high_availability/redis.md) for high availability.
* [NFS Server](../high_availability/nfs.md) which will store data that is synchronized from the Geo primary.
* [Redis](../../high_availability/redis.md) for high availability.
* [NFS Server](../../high_availability/nfs.md) which will store data that is synchronized from the Geo primary.
### Step 2: Configure the Postgres services on the Geo Secondary
1. Configure the [secondary Geo PostgreSQL database](../gitlab-geo/database.md)
1. Configure the [secondary Geo PostgreSQL database](database.md)
as a read-only secondary of the primary Geo PostgreSQL database.
1. Configure the Geo tracking database on the secondary server, to do this modify `/etc/gitlab/gitlab.rb`:
......@@ -91,7 +91,7 @@ After making these changes be sure to run `sudo gitlab-ctl reconfigure` so that
In this topology there will need to be a load balancers at each geographical location
to route traffic to the application servers.
See the [Load Balancer for GitLab HA](../high_availability/load_balancer.md)
See the [Load Balancer for GitLab HA](../../high_availability/load_balancer.md)
documentation for more information.
### Step 4: Configure the Geo Frontend Application Servers
......@@ -192,5 +192,5 @@ On the secondary the following GitLab frontend services will be enabled:
Verify these services by running `sudo gitlab-ctl status` on the frontend
application servers.
[reconfigure GitLab]: ../restart_gitlab.md#omnibus-gitlab-reconfigure
[restart GitLab]: ../restart_gitlab.md#omnibus-gitlab-restart
[reconfigure GitLab]: ../../restart_gitlab.md#omnibus-gitlab-reconfigure
[restart GitLab]: ../../restart_gitlab.md#omnibus-gitlab-restart
......@@ -7,7 +7,7 @@
basic Geo features, or latest version for a better experience.
- You should make sure that all nodes run the same GitLab version.
- Geo requires PostgreSQL 9.6 and Git 2.9 in addition to GitLab's usual
[minimum requirements](../install/requirements.md)
[minimum requirements](../../../install/requirements.md)
- Using Geo in combination with High Availability is considered **GA** in GitLab Enterprise Edition 10.4
>**Note:**
......@@ -31,7 +31,7 @@ Your Geo instance can be used for cloning and fetching projects, in addition to
reading any data. This will make working with large repositories over large
distances much faster.
![Geo overview](img/geo-overview.png)
![Geo overview](img/geo_overview.png)
When Geo is enabled, we refer to your original instance as a **primary** node
and the replicated read-only ones as **secondaries**.
......@@ -52,14 +52,14 @@ improving speed for distributed teams
- Helps reducing the loading time for automated tasks,
custom integrations and internal workflows
- Quickly fail-over to a Geo secondary in a
[Disaster Recovery](../disaster_recovery/index.md) scenario
- Allows [planned fail-over](../disaster_recovery/planned_fail_over.md) to a Geo secondary
[Disaster Recovery](../../disaster_recovery/index.md) scenario
- Allows [planned fail-over](../../disaster_recovery/planned_fail_over.md) to a Geo secondary
## Architecture
The following diagram illustrates the underlying architecture of Geo:
![Geo architecture](img/geo-architecture.png)
![Geo architecture](img/geo_architecture.png)
[Source diagram](https://docs.google.com/drawings/d/1Abw0P_H0Ew1-2Lj_xPDRWP87clGIke-1fil7_KQqrtE/edit)
......@@ -89,7 +89,7 @@ current version of OpenSSH:
Note that CentOS 6 and 7.0 ship with an old version of OpenSSH that do not
support a feature that Geo requires. See the [documentation on Geo SSH
access](../operations/fast_ssh_key_lookup.md) for more details.
access](../../operations/fast_ssh_key_lookup.md) for more details.
### LDAP
......@@ -144,14 +144,14 @@ If you installed GitLab using the Omnibus packages (highly recommended):
1. [Install GitLab Enterprise Edition][install-ee] on the server that will serve
as the **secondary** Geo node. Do not create an account or login to the new
secondary node.
1. [Upload the GitLab License](../user/admin_area/license.md) on the **primary**
1. [Upload the GitLab License](../../../user/admin_area/license.md) on the **primary**
Geo node to unlock Geo.
1. [Setup the database replication](database.md) (`primary (read-write) <->
secondary (read-only)` topology).
1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md),
1. [Configure fast lookup of authorized SSH keys in the database](../../operations/fast_ssh_key_lookup.md),
this step is required and needs to be done on both the primary AND secondary nodes.
1. [Configure GitLab](configuration.md) to set the primary and secondary nodes.
1. Optional: [Configure a secondary LDAP server](../auth/ldap.md)
1. Optional: [Configure a secondary LDAP server](../../auth/ldap.md)
for the secondary. See [notes on LDAP](#ldap).
1. [Follow the "Using a Geo Server" guide](using_a_geo_server.md).
......@@ -164,11 +164,11 @@ If you installed GitLab from source:
1. [Install GitLab Enterprise Edition][install-ee-source] on the server that
will serve as the **secondary** Geo node. Do not create an account or login
to the new secondary node.
1. [Upload the GitLab License](../user/admin_area/license.md) on the **primary**
1. [Upload the GitLab License](../../../user/admin_area/license.md) on the **primary**
Geo node to unlock Geo.
1. [Setup the database replication](database_source.md) (`primary (read-write)
<-> secondary (read-only)` topology).
1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md),
1. [Configure fast lookup of authorized SSH keys in the database](../../operations/fast_ssh_key_lookup.md),
do this step for both primary AND secondary nodes.
1. [Configure GitLab](configuration_source.md) to set the primary and secondary
nodes.
......@@ -186,7 +186,7 @@ Read how to [update your Geo nodes to the latest GitLab version](updating_the_ge
## Configuring Geo HA
Read through the [Geo High Availability documentation](ha.md).
Read through the [Geo High Availability documentation](high_availability.md).
## Configuring Geo with Object storage
......@@ -226,7 +226,7 @@ This message shows that Geo detected that a repository update was needed for pro
## Security of Geo
Read the [security review](security-review.md) page.
Read the [security review](security_review.md) page.
## Tuning Geo
......
......@@ -13,10 +13,10 @@ they can use a replicated storage bucket. At this time GitLab does not
take care of content replication in object storage.
For LFS, follow the documentation to
[set up LFS object storage](../workflow/lfs/lfs_administration.md#setting-up-s3-compatible-object-storage).
[set up LFS object storage](../../../workflow/lfs/lfs_administration.md#setting-up-s3-compatible-object-storage).
For CI job artifacts, there is similar documentation to configure
[jobs artifact object storage](../job_artifacts.md#using-object-storage)
[jobs artifact object storage](../../job_artifacts.md#using-object-storage)
Complete these steps on all nodes, primary **and** secondary.
......
......@@ -21,7 +21,7 @@ to help identify if something is wrong:
- Is the node's secondary tracking database connected?
- Is the node's secondary tracking database up-to-date?
![Geo health check](img/geo-node-healthcheck.png)
![Geo health check](img/geo_node_healthcheck.png)
There is also an option to check the status of the secondary node by running a special rake task:
......
......@@ -13,5 +13,5 @@ but this may not lead to a more downloads in parallel unless the number of
available Sidekiq threads is also increased. For example, if repository sync
capacity is increased from 25 to 50, you may also want to increase the number
of Sidekiq threads from 25 to 50. See the [Sidekiq concurrency
documentation](../operations/extra_sidekiq_processes.html#concurrency)
documentation](../../operations/extra_sidekiq_processes.html#concurrency)
for more details.
......@@ -99,7 +99,7 @@ secondary if ever promoted to a primary:
>**Warning**
Hashed storage is in **Alpha**. It is considered experimental and not
production-ready. See [Hashed
Storage](../repository_storage_types.md) for more detail.
Storage](../../repository_storage_types.md) for more detail.
If you previously enabled Hashed Storage and migrated all your existing
projects to Hashed Storage, disabling hashed storage will not migrate projects
......@@ -111,16 +111,16 @@ migrated we recommend leaving Hashed Storage enabled.
>**Warning**
Hashed storage is in **Alpha**. It is considered experimental and not
production-ready. See [Hashed
Storage](../repository_storage_types.md) for more detail.
Storage](../../repository_storage_types.md) for more detail.
[Hashed storage](../repository_storage_types.md) was introduced
in GitLab 10.0, and a [migration path](../raketasks/storage.md)
[Hashed storage](../../repository_storage_types.md) was introduced
in GitLab 10.0, and a [migration path](../../raketasks/storage.md)
for existing repositories was added in GitLab 10.1.
## Upgrading to GitLab 10.0
Since GitLab 10.0, we require all **Geo** systems to [use SSH key lookups via
the database](../operations/fast_ssh_key_lookup.md) to avoid having to maintain consistency of the
the database](../../operations/fast_ssh_key_lookup.md) to avoid having to maintain consistency of the
`authorized_keys` file for SSH access. Failing to do this will prevent users
from being able to clone via SSH.
......@@ -314,4 +314,4 @@ and it is required since 10.0.
1. Repeat this step for every secondary node
[update]: ../update/README.md
[update]: ../../../update/README.md
......@@ -20,4 +20,4 @@ there are a few things to consider:
git remote set-url --push origin [email protected]:user/repo.git
```
[req]: README.md#setup-instructions
[req]: index.md#setup-instructions
This document was moved to [another location](../administration/geo/index.md).
This document was moved to [another location](../administration/geo/replication/index.md).
This document was moved to [another location](../administration/geo/configuration.md).
This document was moved to [another location](../administration/geo/replication/configuration.md).
This document was moved to [another location](../administration/geo/configuration_source.md).
This document was moved to [another location](../administration/geo/replication/configuration_source.md).
This document was moved to [another location](../administration/geo/database.md).
This document was moved to [another location](../administration/geo/replication/database.md).
This document was moved to [another location](../administration/geo/database_source.md).
This document was moved to [another location](../administration/geo/replication/database_source.md).
This document was moved to [another location](../administration/geo/docker_registry.md).
This document was moved to [another location](../administration/geo/replication/docker_registry.md).
This document was moved to [another location](../administration/geo/faq.md).
This document was moved to [another location](../administration/geo/replication/faq.md).
This document was moved to [another location](../administration/geo/high_availability.md).
This document was moved to [another location](../administration/geo/replication/high_availability.md).
This document was moved to [another location](../administration/geo/object_storage.md).
This document was moved to [another location](../administration/geo/replication/object_storage.md).
This document was moved to [another location](../administration/geo/security_review.md).
This document was moved to [another location](../administration/geo/replication/security_review.md).
This document was moved to [another location](../administration/geo/troubleshooting.md).
This document was moved to [another location](../administration/geo/replication/troubleshooting.md).
This document was moved to [another location](../administration/geo/tuning.md).
This document was moved to [another location](../administration/geo/replication/tuning.md).
This document was moved to [another location](../administration/geo/updating_the_geo_nodes.md).
This document was moved to [another location](../administration/geo/replication/updating_the_geo_nodes.md).
This document was moved to [another location](../administration/geo/using_a_geo_server.md).
This document was moved to [another location](../administration/geo/replication/using_a_geo_server.md).
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment