Skip to content
Snippets Groups Projects
Verified Commit b4f03467 authored by anarcat's avatar anarcat
Browse files

gnt-dal: move secondary interface from eth2 to eth1

The rationale here is that when we can do link aggregation this will
provide redundancy between the two NICs on the servers.
parent d9529f87
No related branches found
No related tags found
No related merge requests found
......@@ -2585,11 +2585,11 @@ be reclaimed eventually.
`30.172.in-addr.arpa` zone and `torproject.org` zone, in the
`admin/dns/domains.git` repository
4. add the private IP address to the eth1 interface, for example in
4. add the private IP address to the `eth1` interface, for example in
`/etc/network/interfaces.d/eth1`:
auto eth2
iface eth2 inet static
auto eth1
iface eth1 inet static
address 172.30.131.101/24
Again, this IP must be allocated in the reverse DNS zone file
......@@ -2598,7 +2598,7 @@ be reclaimed eventually.
5. enable the interface:
ifup eth2
ifup eth1
6. setup a bridge on the public interface, replacing the `eth0` blocks
with something like:
......
......@@ -514,12 +514,11 @@ This network is split in those VLANs:
* "public": VLAN 82 - 204.8.99.0/24, directly accessible on the
global network, behind a Quintex router, `eth0` on all nodes, could
eventually be aggregated with `eth1`
eventually be aggregated with `eth2`
* "storage": VLAN 801 - 172.30.131.0/24, used by the Ganeti cluster
for DRBD replication, not accessible by the internet, `eth2` on all
nodes (except `dal-rescue-01` where it is `eth1`), could eventually
be aggregated with `eth3`
for DRBD replication, not accessible by the internet, `eth1` on all
nodes, could eventually be aggregated with `eth3`
* "OOB": VLAN 802 - 172.30.141.0/24, access to the "out of
band" (OOB) management interfaces, not accessible by the internet,
......@@ -530,6 +529,13 @@ Note that the above use the non-"predictable" interface names,
i.e. `eth0` and `eth1` instead of `eno1np0` and `eno1np1` or
`enp129s0f0` and `enp129s0f1`.
Also note that have the public and storage VLANs on the *same* NIC
(i.e. public on `eth0` and storage on `eth1`). This is because we plan
on doing aggregation in the long term and that will allow us to
survive a NIC failure. Assuming NIC one has `eth0` and `eth1` and NIC
two has `eth2` and `eth3`, if the public VLAN is on `eth0` and `eth2`,
it will survive a failure of one NIC.
It physically looks like this:
![Photo of the top of a 42U cabinet with three servers and a switch](quintex/gnt-dal-2023-02-10.jpeg)
......
......@@ -4,8 +4,8 @@ digraph quintex {
subgraph clusterhosts {
label = "server\ndal-node-NN"
labeljust=r
host_public [ shape=box label="eth0,eth1\npublic"]
host_storage [ shape=box label="eth2,eth3\nstorage"]
host_public [ shape=box label="eth0,eth2\npublic"]
host_storage [ shape=box label="eth1,eth3\nstorage"]
//host_mgmt [ shape=box label="eth2\nmanagement"]
host_idrac [ shape=box label="IPMI\nOOB"]
}
......
howto/quintex/topology.png

63.1 KiB | W: | H:

howto/quintex/topology.png

63.1 KiB | W: | H:

howto/quintex/topology.png
howto/quintex/topology.png
howto/quintex/topology.png
howto/quintex/topology.png
  • 2-up
  • Swipe
  • Onion skin
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment