Consolidate opening text from about.gitlab.com and add active/passive note

doc/administration/high_availability/README.md

@@ -5,6 +5,20 @@ The solution you choose will be based on the level of scalability and
 availability you require. The easiest solutions are scalable, but not necessarily
 highly available.
 
+GitLab provides a service that is usually essential to most organizations: it
+enables people to collaborate on code in a timely fashion. Any downtime should
+therefore be short and planned. Luckily, GitLab provides a solid setup even on
+a single server without special measures. Due to the distributed nature
+of Git, developers can still commit code locally even when GitLab is not
+available. However, some GitLab features such as the issue tracker and
+Continuous Integration are not available when GitLab is down.
+
+**Keep in mind that all Highly Available solutions come with a trade-off between
+cost/complexity and uptime**. The more uptime you want, the more complex the
+solution. And the more complex the solution, the more work is involved in
+setting up and maintaining it. High availability is not free and every HA
+solution should balance the costs against the benefits.
+
 ## Architecture
 
 There are two kinds of setups:
@@ -37,6 +51,10 @@ Block Device) to keep all data in sync. DRBD requires a low latency link to
 remain in sync. It is not advisable to attempt to run DRBD between data centers
 or in different cloud availability zones.
 
+> **Note:** GitLab recommends against choosing this HA method because of the
+  complexity of managing DRBD and crafting automatic failover. This is
+  *compatible* with GitLab, but not officially *supported*.
+
 Components/Servers Required: 2 servers/virtual machines (one active/one passive)
 
 ![Active/Passive HA Diagram](../img/high_availability/active-passive-diagram.png)