add network topology section

Author: gxben

content/en/docs/getting-started/create-kiwi.md

@@ -1,5 +1,5 @@
 ---
 title: Provisioning Kiwi
 description: Let's provision our Kiwi instances
-weight: 6
+weight: 7
 ---

content/en/docs/getting-started/create-region.md

@@ -1,7 +1,7 @@
 ---
 title: Create Your First Region
 description: Let's setup a new region and its Kiwi and Kaktus instances
-weight: 5
+weight: 6
 ---
 
 Orchestrator being ready, we can now boostrap our first region.

content/en/docs/getting-started/kahuna-setup.md

@@ -1,7 +1,7 @@
 ---
 title: Setup Kahuna
 description: Let's start with the orchestration core
-weight: 3
+weight: 4
 ---
 
 Now let's suppose that you've cloned the Git platform repository template and that your **Kahuna** instance server has been provisioned with latest Ubuntu LTS distribution. Be sure that it is SSH-accessible with some local user.

content/en/docs/getting-started/network-topology.png

@@ -1,7 +1,7 @@
 ---
 title: Provisioning Users
 description: Let's populate admin users and teams
-weight: 4
+weight: 5
 ---
 
 Your **Kahuna** instance is now up and running, let's get things and create a few admin users accounts. At first, we only have the super-admin API key that was previously set through Ansible deployment. We'll make use of it to provision further users and associated teams. After all, we want a nominative user acount for each contributor, right ?

content/en/docs/getting-started/provision-users.md

@@ -0,0 +1,31 @@
+---
+title: Network Topology
+description: Our Tutorial network topology
+weight: 3
+---
+
+Let's use this sample network topology for the rest of this tutorial:
+
+![](/docs/getting-started/network-topology.png)
+
+We'll start with a single **Kahuna** instance, with public Internet exposure. The instance's hostname will be **kowabunga-kahuna-1** and it has 2 network adapters and associated IP addresses:
+
+- a private one, **10.0.0.1**, in the event we'd need to peer further one with other instances for hugh-availability.
+- a public one, **1.2.3.4**, exposed as **kowabunga.acme.com** for WebUI, REST API calls to the orchestrator and WebSocket agents endpoint. It'll also be exposed as **grafana.acme.com**, **logs.acme.com** and **metrics.acme.com** for **Kiwi** and **Kaktus** to push logs and and metrics and allow for service's metrology.
+
+Next is the main (and only) region, **EU-WEST** and its single zone, **EU-WEST-A**. The region/zone will feature 2 **Kiwi** instances and 3 **Kaktus** ones.
+
+All instances will be connected under the same L2 network layer (as defined in requirements) and we'll use different VLANs and associated network subnets to isolate content:
+
+- **VLAN101** will be used as default, administration VLAN, with associated **10.50.101.0/24** subnet. All **Kiwi** and **Kaktus** instances will be part of.
+- **VLAN102** will be used for Ceph backpanel, with associated **10.50.102.0/24** subnet. While not mandatory, this allows differentiating the administrative control plane traffic from pure storage cluster data synchronization. This allows for better traffic shaping and monitoring, if ever needs be. Note that on enterprise-grade production systems, Ceph project would recommend to use dedicated NIC for Ceph traffic, so isolation here makes sense.
+- **VLAN201** to **VLAN209** would be application VLANs. **Kiwi** will bind them, being region's router, but **Kaktus** don't. Instantiated VMs will however, through bridged network adapters.
+
+{{% alert color="warning" title="Warning" %}}
+It is suggested to use manual fixed-address for **Kiwi** and **Kaktus** instances. Being critical, you wouldn't jeopardize the risk of service interruption because of a DHCP lease issue.
+{{% /alert %}}
+
+{{% alert color="success" title="Note" %}}
+Note that while **Kiwi** instances have static IP addresses (namely **.2** and **.3**), they'll also use a **.1** as virtual IP (VIP), which is used for failover. Consequently, the **.1** will always be the network's router/gateway here, whichever **Kiwi** instace will hold it.
+{{% /alert %}}
+