🥇 Erstellung einer ausfallsicheren IT-Infrastruktur. Teil 1 – Vorbereitung auf die Bereitstellung des oVirt 4.3 Clusters

Lesen Sie die Prinzipien des Aufbaus einer ausfallsicheren Infrastruktur für ein kleines Unternehmen innerhalb eines Rechenzentrums (RCZ), die in einem kleinen Artikelzyklus detailliert behandelt werden.

Einleitung

Pod Rechenzentrum (Rechenzentrum) kann verstanden werden als:

ein eigener Rack im eigenen "Serverraum" auf dem Betriebsgelände, der die minimalen Anforderungen an die Stromversorgung und Kühlung der Geräte erfüllt und zudem einen Internetzugang über zwei unabhängige Anbieter bereitstellt;
ein gemietetes Rack mit eigener Hardware, das sich in einem echten Rechenzentrum befindet – das sogenannte Colocation, das dem Tier-III- oder Tier-IV-Standard entspricht und das eine zuverlässige Stromversorgung, Kühlung und eine ausfallsichere Internetverbindung garantiert;
vollständig gemietete Ausrüstung im Rechenzentrum der Stufen Tier III oder IV.

Welches Platzierungsmodell gewählt werden soll, ist in jedem Fall individuell und hängt normalerweise von mehreren Grundfaktoren ab:

wofür ein Unternehmen überhaupt eine eigene IT-Infrastruktur benötigt;
was genau das Unternehmen von der IT-Infrastruktur erwartet (Zuverlässigkeit, Skalierbarkeit, Managebarkeit usw.);
der Höhe der anfänglichen Investitionen in die IT-Infrastruktur sowie der Art der Ausgaben dafür – kapitalintensiv (d.h. eigene Geräte werden gekauft) oder operativ (Geräte werden in der Regel gemietet);
dem Planungshorizont des Unternehmens selbst.

Man könnte viel über die Faktoren schreiben, die die Entscheidung des Unternehmens zur Einrichtung und Nutzung seiner IT-Infrastruktur beeinflussen, aber unser Ziel ist es zu zeigen, wie man diese Infrastruktur praktisch so schaffen kann, dass sie sowohl ausfallsicher ist, als auch Kosten gesenkt werden können – um Ausgaben für den Erwerb kommerzieller Software zu verringern oder sie ganz zu vermeiden.

Langfristige Erfahrung zeigt, dass man bei der Hardware nicht sparen sollte, denn der Geizige zahlt zweimal, und oft sogar wesentlich mehr. Andererseits ist gute Hardware nur eine Empfehlung, und letztendlich hängt es von den Möglichkeiten des Unternehmens und der "Sparsamkeit" seiner Führung ab. Dabei sollte das Wort "Sparsamkeit" im positiven Sinne verstanden werden, da es besser ist, in der Anfangsphase in Hardware zu investieren, um später keine ernsthaften Probleme bei deren Wartung und Skalierung zu haben. Falsche Planung und übermäßiges Sparen können in Zukunft zu größeren Ausgaben führen als bei der Projektinitialisierung.

Also, die Ausgangsdaten für das Projekt:

ein Unternehmen, das beschlossen hat, ein eigenes Webportal zu erstellen und seine Aktivitäten ins Internet zu bringen;
das Unternehmen hat beschlossen, einen Rackspace für die Unterbringung seiner Hardware in einem guten Rechenzentrum mit Tier-III-Zertifizierung zu mieten;
das Unternehmen hat beschlossen, bei der Hardware nicht zu sparen, und hat daher folgende Geräte mit erweiterten Garantien und Support gekauft:

Liste der Geräte

zwei physische Server Dell PowerEdge R640 in folgender Konfiguration:

zwei Intel Xeon Gold 5120 Prozessoren

512 Gb RAM

zwei SAS-Laufwerke im RAID1 für das Betriebssystem

eingebautes 4-Port 1G Netzwerkkarten

zwei 2-Port 10G Netzwerkkarten

eine 2-Port FC HBA 16G.

2-controller Storage Area Network Dell MD3820f, direkt per FC 16G mit Dell-Hosts verbunden;

zwei Layer-2-Switches — Cisco WS-C2960RX-48FPS-L in einem Stack verbunden;

zwei Layer-3-Switches — Cisco WS-C3850-24T-E, in einem Stack verbunden;

Rack, UPS, PDU, Konsolenserver – werden vom Rechenzentrum bereitgestellt.

Wie wir sehen, bietet die vorhandene Hardware gute Perspektiven für horizontale und vertikale Skalierung, falls das Unternehmen in der Lage ist, mit anderen ähnlich profilierten Firmen im Internet zu konkurrieren und Gewinne zu erzielen, die in die Erweiterung der Ressourcen für weiteren Wettbewerb und Gewinnwachstum investiert werden können.

Welches Equipment können wir hinzufügen, wenn das Unternehmen beschließt, die Leistung unseres Rechenzentrums zu erhöhen:

wir haben eine große Reserve an Ports auf den Switches 2960X, also können wir mehr physische Server hinzufügen;
Zwei FC-Switches nachkaufen, um SAN und zusätzliche Server anzuschließen;
Die bereits vorhandenen Server können aufgerüstet werden – mehr RAM hinzufügen, Prozessoren gegen leistungsstärkere austauschen, bereits vorhandene Netzwerkadapter für 10G verwenden;
Zur SAN können zusätzliche Festplattenregale mit dem notwendigen Festplattentyp – SAS, SATA oder SSD – hinzugefügt werden, abhängig von der geplanten Last;
Nach dem Hinzufügen der FC-Switches kann noch eine weitere SAN gekauft werden, um die Speicherkapazität weiter zu erhöhen. Wenn man zudem die spezielle Option Remote Replication hinzufügt, kann die Datenreplikation zwischen SANs sowohl innerhalb eines Rechenzentrums als auch zwischen Rechenzentren eingerichtet werden (aber das liegt bereits außerhalb des Rahmens dieses Artikels);
Außerdem gibt es Layer-3-Switches – Cisco 3850, die als ausfallresistentes Kernnetzwerk verwendet werden können, um Hochgeschwindigkeitsrouting zwischen internen Netzwerken zu ermöglichen. Das wird uns in Zukunft sehr helfen, während die interne Infrastruktur wächst. Auch die 3850 haben 10G-Ports, die später bei der Aktualisierung der Netzwerkausrüstung auf 10G genutzt werden können.

Da man ohne Virtualisierung heutzutage kaum auskommt, werden wir natürlich im Trend sein, zumal es eine hervorragende Möglichkeit ist, die Kosten für den Erwerb teurer Server für bestimmte Infrastrukturkomponenten (Web-Server, Datenbanken usw.) zu senken, die bei niedriger Last nicht immer optimal genutzt werden, wie es zu Beginn der Projektstart der Fall sein wird.

Darüber hinaus hat die Virtualisierung viele andere Vorteile, die uns sehr nützlich sein können: Ausfallsicherheit der VMs bei einem Hardwareausfall, Live-Migration zwischen den Knoten des Clusters zur Wartung, manuelle oder automatische Lastverteilung zwischen den Knoten des Clusters usw.

Für die Hardware, die das Unternehmen erworben hat, bietet sich das Deployment eines hochverfügbaren VMware vSphere-Clusters an, aber da jede Software von VMware für ihre „überteuerten“ Preise bekannt ist, werden wir kostenlose Software zur Verwaltung der Virtualisierung verwenden – oVirt, auf deren Grundlage das bekannte, aber bereits kommerzielle Produkt — RHEV.

Software oVirt Notwendig, um alle Elemente der Infrastruktur zu einem Ganzen zu verbinden, um eine bequeme Arbeit mit hochverfügbaren virtuellen Maschinen zu ermöglichen – das sind Datenbanken, Webanwendungen, Proxy-Server, Lastverteilungsgeräte, Server für Log-Sammlung und Analytik usw., also das, was unser Unternehmens-Webportal ausmacht.

Zusammenfassend erwartet uns in dieser Einleitung die folgenden Artikel, die in der Praxis zeigen werden, wie genau die gesamte Hardware- und Software-Infrastruktur des Unternehmens bereitgestellt wird:

Liste der Artikel

Teil 1. Vorbereitung auf den Einsatz des Clusters oVirt 4.3.
Teil 2. Installation und Konfiguration des Clusters oVirt 4.3.
Teil 3. Konfiguration des VyOS-Clusterns, Organisation einer ausfallsicheren externen Routing.
Teil 4. Konfiguration des Cisco 3850-Stapels, Organisation des internen Routings.

Teil 1. Vorbereitung auf den Einsatz des Clusters oVirt 4.3

Grundkonfiguration der Hosts

Die Installation und Konfiguration des Betriebssystems ist der einfachste Schritt. Es gibt unzählige Artikel, die erklären, wie man das Betriebssystem richtig installiert und konfiguriert, daher macht es keinen Sinn, in dieser Hinsicht etwas Exklusives zu versuchen.

Wir haben also zwei Dell PowerEdge R640-Hosts, auf denen das Betriebssystem installiert werden muss und die ersten Einstellungen vorgenommen werden müssen, um sie als Hypervisoren für den Betrieb von virtuellen Maschinen im Cluster oVirt 4.3 zu verwenden.

Da wir planen, die kostenlose nicht-kommerzielle Software oVirt zu verwenden, wurde für die Bereitstellung der Hosts das Betriebssystem CentOS 7.7gewählt, obwohl auch andere Betriebssysteme auf die Hosts für oVirt installiert werden können:

eine spezielle Build-Version basierend auf RHEL, bekannt als oVirt Node;
Das Betriebssystem Oracle Linux, das im Sommer 2019 unterstützt wurde, wurde angekündigt.

Vor der Installation des Betriebssystems wird empfohlen:

die Netzwerkschnittstelle iDRAC an beiden Hosts zu konfigurieren;
die Firmware für BIOS und iDRAC auf die neuesten Versionen zu aktualisieren;
das Systemprofil des Servers idealerweise im Leistungsmodus zu konfigurieren;
RAID aus lokalen Festplatten einzurichten (RAID1 wird empfohlen), um das Betriebssystem auf dem Server zu installieren.

Dann installieren wir das Betriebssystem auf dem über iDRAC erstellten Disk – der Installationsprozess ist gewöhnlich, es gibt keine besonderen Punkte. Der Zugriff auf die Konsole des Servers, um mit der Installation des Betriebssystems zu beginnen, kann ebenfalls über iDRAC erfolgen, obwohl nichts dagegen spricht, einen Monitor, eine Tastatur und eine Maus direkt mit dem Server zu verbinden und das Betriebssystem von einem USB-Stick zu installieren.

Nach der Installation des Betriebssystems führen wir die ersten Einstellungen durch:

systemctl aktivieren network.service
systemctl starten network.service
systemctl status network.service

systemctl stoppen NetworkManager
systemctl deaktivieren NetworkManager
systemctl status NetworkManager

yum install -y ntp
systemctl aktivieren ntpd.service
systemctl starten ntpd.service

cat /etc/sysconfig/selinux
SELINUX=deaktiviert
SELINUXTYPE=targeted

cat /etc/security/limits.conf
 *               soft    nofile         65536
 *               hard   nofile         65536

cat /etc/sysctl.conf
vm.max_map_count = 262144
vm.swappiness = 1

Wir installieren ein Basis-Softwarepaket

Für die ursprüngliche Konfiguration des Betriebsystems muss irgendeine Netzwerkschnittstelle auf dem Server konfiguriert werden, um Internetzugang zu erhalten, für Updates des Betriebssystems und die Installation der nötigen Software. Dies kann sowohl während der Installation des Betriebssystems als auch danach erfolgen.

yum -y install epel-release
yum update
yum -y install bind-utils yum-utils net-tools git htop iotop nmon pciutils sysfsutils sysstat mc nc rsync wget traceroute gzip unzip telnet

Alle oben genannten Einstellungen und Softwarepakete sind eine Frage der persönlichen Vorlieben, und dieses Paket hat lediglich einen empfehlenden Charakter.

Da unser Host als Hypervisor fungieren wird, aktivieren wir das erforderliche Leistungsprofil:

systemctl aktivieren tuned
systemctl starten tuned
systemctl status tuned

tuned-adm profil
tuned-adm profil virtual-host

Mehr über das Leistungsprofil kann hier gelesen werden: „Kapitel 4. tuned und tuned-adm«.

Nach der Installation des Betriebssystems gehen wir zum nächsten Teil über – der Konfiguration der Netzwerkschnittstellen auf den Hosts und dem Stack der Cisco 2960X-Switches.

Konfiguration des Cisco 2960X-Switch-Stapels

In unserem Projekt werden die folgenden VLAN-Nummern verwendet – oder Broadcast-Domänen, die voneinander isoliert sind, um verschiedene Arten von Verkehr zu trennen:

VLAN 10 – Internet
VLAN 17 – Verwaltung (iDRAC, Speicher, Switch-Management)
VLAN 32 – VM Produktionsnetzwerk
VLAN 33 – Interconnectionsnetzwerk (zu externen Auftragnehmern)
VLAN 34 – VM Testnetzwerk
VLAN 35 – VM Entwicklernetzwerk
VLAN 40 – Überwachungsnetzwerk

Vor Beginn der Arbeiten geben wir ein Schaubild auf L2-Ebene an, das wir letztendlich erreichen wollen:

Erstellung einer ausfallsicheren IT-Infrastruktur. Teil 1 – Vorbereitung auf die Bereitstellung des oVirt 4.3 Clusters

Für die Netzwerkkommunikation zwischen oVirt-Hosts und virtuellen Maschinen sowie zur Verwaltung unseres Speichers ist die Konfiguration des Cisco 2960X-Switch-Stapels erforderlich.

Die Dell-Hosts verfügen über integrierte 4-Port-Netzwerkkarten, daher ist es sinnvoll, ihre Verbindung zu Cisco 2960X über eine ausfallsichere Netzwerkverbindung zu organisieren, indem wir physische Netzwerkschnittstellen in einer logischen Schnittstelle gruppieren und das LACP-Protokoll (802.3ad) verwenden:

die ersten zwei Ports am Host werden im Bonding-Modus konfiguriert und mit dem Switch 2960X verbunden – an dieser logischen Schnittstelle wird konfiguriert. bridge mit einer Adresse zur Verwaltung des Hosts, zur Überwachung und zur Kommunikation mit anderen Hosts im oVirt-Cluster, die auch für die Live-Migration von virtuellen Maschinen verwendet wird;
Die letzten beiden Ports am Host werden ebenfalls im Bonding-Modus konfiguriert und an den 2960X angeschlossen – über dieses logische Interface wird mit oVirt ein Bridge in den entsprechenden VLANs erstellt, an den die virtuellen Maschinen angeschlossen werden.
Beide Netzwerkkarten in einem logischen Interface werden aktiv sein, d.h. der Datenverkehr kann gleichzeitig über sie übertragen werden, im Lastverteilungsmodus.
Die Netzwerkeinstellungen an den Cluster-Knoten müssen absolut IDENTISCH sein, mit der Ausnahme der IP-Adressen.

Grundkonfiguration des Switch-Stacks 2960X und seiner Ports

Vorab müssen unsere Switches sein:

in einem Rack montiert;
verbunden mit zwei speziellen Kabeln der benötigten Länge, z.B. CAB-STK-E-1M;
mit Strom versorgt;
über den Konsolenport mit dem Arbeitsplatz des Administrators verbunden, um sie initial zu konfigurieren.

Die notwendige Anleitung hierfür ist auf der offiziellen Seite des Herstellers.

Nach Durchführung der oben genannten Schritte konfigurieren wir die Switches.
Die Bedeutung jedes Befehls wird im Rahmen dieses Artikels nicht erläutert, bei Bedarf kann man alle Informationen selbständig finden.
Unser Ziel ist es, den Switch-Stack so schnell wie möglich zu konfigurieren und die Hosts sowie die Verwaltungsinterfaces des SAN anzuschließen.

1) Wir verbinden uns mit dem führenden Switch, wechseln in den privilegierten Modus, gehen dann in den Konfigurationsmodus und nehmen die Grundeinstellungen vor.

Die Basiskonfiguration des Switches:

 aktivieren
 konfigurieren Sie das Terminal

 hostname 2960X

 kein Dienst pad
 Dienststempel Debug-Datumszeit msec
 Dienststempel Protokoll Datumszeit lokale Zeit zeige Zeitzone msec
 kein Dienst Passwort-Verschlüsselung
 Dienst Sequenz-Nummern

 switch 1 Priorität 15
 switch 2 Priorität 14
 stack-mac anhaltender Timer 0

 Uhrzeit Zeitzone MSK 3
 vtp-Modus transparent
 ip subnet-zero

 vlan 17
 name Management

 vlan 32
 name PROD 

 vlan 33
 name Interconnect

 vlan 34
 name Test

 vlan 35
 name Dev

 vlan 40
 name Monitoring

 spanning-tree-Modus rapid-pvst
 spanning-tree etherchannel guard misconfig
 spanning-tree portfast bpduguard default
 spanning-tree extend system-id
 spanning-tree vlan 1-40 root primary
 spanning-tree loopguard default
 vlan interne Zuteilungspolitik aufsteigend
 port-channel load-balance src-dst-ip

 errdisable recovery cause loopback
 errdisable recovery cause bpduguard
 errdisable recovery intervall 60

line con 0
 session-timeout 60
 exec-timeout 60 0
 logging synchron
line vty 5 15
 session-timeout 60
 exec-timeout 60 0
 logging synchron

 ip http server
 ip http secure-server
 kein vstack

schnittstelle Vlan1
 keine ip-Adresse
 herunterfahren

 Ausstieg

Wir speichern die Konfiguration mit dem Befehl „wr mem“ und starten den Switch-Stack mit dem Befehl „reload“ auf dem Hauptswitch Switch 1.

2) Wir konfigurieren die Netzwerkports des Switches im Zugriffmodus (access) für VLAN 17, um die Verwaltungsinterfaces der Speicher- und iDRAC-Server anzuschließen.

Konfiguration der Verwaltungsports:

schnittstelle GigabitEthernet1/0/5
 Beschreibung iDRAC - host1
 switchport access vlan 17
 switchport modus access
 spanning-tree portfast edge

schnittstelle GigabitEthernet1/0/6
 Beschreibung Storage1 - Cntr0/Eth0
 switchport access vlan 17
 switchport modus access
 spanning-tree portfast edge

schnittstelle GigabitEthernet2/0/5
 Beschreibung iDRAC - host2
 switchport access vlan 17
 switchport modus access
 spanning-tree portfast edge

schnittstelle GigabitEthernet2/0/6
 Beschreibung Storage1 – Cntr1/Eth0
 switchport access vlan 17
 switchport modus access
 spanning-tree portfast edge
 Ausstieg

3) Nach dem Neustart des Stacks überprüfen wir, ob er korrekt funktioniert:

Überprüfung der Funktionsweise des Stacks:

2960X#show switch stack-ring speed

Stack Ring Geschwindigkeit      : 20G
Stack Ring Konfiguration: Voll
Stack Ring Protokoll       : FlexStack

2960X#show switch stack-ports
  Switch #    Port 1      Port 2
  --------    ------      ------
    1           Ok          Ok
    2           Ok          Ok

2960X#show switch neighbors
  Switch #    Port 1      Port 2
  --------    ------      ------
      1         2            2
      2         1            1

2960X#show switch detail
Switch/Stack Mac Adresse : 0cd0.f8e4.XXXX
Mac Persistenz Wartezeit: Unbegrenzt
                                           H/W   Aktuell
Switch#  Rolle   Mac Adresse     Priorität Version  Status
----------------------------------------------------------
*1        Master 0cd0.f8e4.XXXX    15     4       Bereit
 2        Mitglied 0029.c251.XXXX     14     4       Bereit

         Stack Port Status             Nachbarn
Switch#  Port 1      Port 2           Port 1   Port 2
--------------------------------------------------------
  1         Ok         Ok                2        2
  2         Ok         Ok                1        1

4) Konfiguration des SSH-Zugriffs auf den Stack 2960X

Für die Remote-Verwaltung des Stacks über SSH verwenden wir die IP 172.20.1.10, die auf SVI (Switch Virtual Interface) konfiguriert ist. VLAN17.

Obwohl es für Managementzwecke wünschenswert wäre, einen speziellen dedizierten Port am Switch zu verwenden, bleibt dies eine Frage der persönlichen Vorlieben und Möglichkeiten.

Einrichten des SSH-Zugangs zum Switch-Stack:

ip default-gateway 172.20.1.2

interface vlan 17
 ip address 172.20.1.10 255.255.255.0

hostname 2960X
 ip domain-name hw.home-lab.ru
 no ip domain-lookup

clock set 12:47:04 06 Dec 2019

crypto key generate rsa

ip ssh version 2
ip ssh time-out 90

line vty 0 4
 session-timeout 60
 exec-timeout 60 0
 privilege level 15
 logging synchronous
 transport input ssh

line vty 5 15
 session-timeout 60
 exec-timeout 60 0
 privilege level 15
 logging synchronous
 transport input ssh

aaa new-model
aaa authentication login default local 
username cisco privilege 15 secret my_ssh_password

Wir richten das Passwort für den Zugriff auf den privilegierten Modus ein:

enable secret *myenablepassword*
service password-encryption

Wir konfigurieren NTP:

ntp server 85.21.78.8 prefer
ntp server 89.221.207.113
ntp server 185.22.60.71
ntp server 192.36.143.130
ntp server 185.209.85.222

show ntp status
show ntp associations
show clock detail

5) Wir konfigurieren die logischen Schnittstellen des Etherchannels und die physischen Ports, die mit den Hosts verbunden sind. Zur Vereinfachung der Konfiguration werden alle vorhandenen VLANs auf allen logischen Schnittstellen erlaubt, jedoch wird normalerweise empfohlen, nur das zu konfigurieren, was benötigt wird:

Einrichtung der Etherchannel-Schnittstellen:

interface Port-channel1
 description EtherChannel mit Host1-Management
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 spanning-tree portfast edge trunk

interface Port-channel2
 description EtherChannel mit Host2-Management
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 spanning-tree portfast edge trunk

interface Port-channel3
 description EtherChannel mit Host1-VM
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 spanning-tree portfast edge trunk

interface Port-channel4
 description EtherChannel mit Host2-VM
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 spanning-tree portfast edge trunk

interface GigabitEthernet1/0/1
 description Host1-Management
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 1 mode active

interface GigabitEthernet1/0/2
 description Host2-Management
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 2 mode active

interface GigabitEthernet1/0/3
 description Host1-VM
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 3 mode active

interface GigabitEthernet1/0/4
 description Host2-VM
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 4 mode active

interface GigabitEthernet2/0/1
 description Host1-Management
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 1 mode active

interface GigabitEthernet2/0/2
 description Host2-Management
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 2 mode active

interface GigabitEthernet2/0/3
 description Host1-VM
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 3 mode active

interface GigabitEthernet2/0/4
 description Host2-VM
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 4 mode active

Ersteinrichtung der Netzwerk-Interfaces für virtuelle Maschinen auf Hosts Host1 und Host2

Überprüfen wir das Vorhandensein der für die Funktion des Bonding erforderlichen Module im System und installieren das Modul zur Verwaltung von Brücken:

modinfo bonding
modinfo 8021q
yum install bridge-utils

Konfiguration des logischen Interfaces BOND1 auf den Hosts für virtuelle Maschinen und seiner physischen Interfaces:

cat /etc/sysconfig/network-scripts/ifcfg-bond1
#BESCHREIBUNG - Verwaltung
DEVICE=bond1
NAME=bond1
TYPE=Bond
IPV6INIT=no
ONBOOT=yes
USERCTL=no
NM_CONTROLLED=no
BOOTPROTO=none
BONDING_OPTS='mode=4 lacp_rate=1 xmit_hash_policy=2'

cat /etc/sysconfig/network-scripts/ifcfg-em2
#BESCHREIBUNG - Verwaltung
DEVICE=em2
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
MASTER=bond1
SLAVE=yes
USERCTL=no
NM_CONTROLLED=no

cat /etc/sysconfig/network-scripts/ifcfg-em3
#BESCHREIBUNG - Verwaltung
DEVICE=em3
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
MASTER=bond1
SLAVE=yes
USERCTL=no
NM_CONTROLLED=no

Nach Abschluss der Einstellungen auf dem Stack 2960X und auf den Hosts starten wir das Netzwerk auf den Hosts neu und überprüfen die Funktionalität des logischen Interfaces.

auf dem Host:

systemctl restart network

cat /proc/net/bonding/bond1
Ethernet Channel Bonding Driver: v3.7.1 (27. April 2011)

Bonding-Modus: IEEE 802.3ad Dynamische Link-Aggregation
Übertragungs-Hash-Politik: layer2+3 (2)
MII-Status: up
MII-Abfrageintervall (ms): 100
Aufwärtsverzögerung (ms): 0
Abwärtsverzögerung (ms): 0
...
802.3ad Informationen
LACP-Rate: schnell
Min. Links: 0
Aggregator-Auswahl-Politik (ad_select): stabil
Systempriorität: 65535
...
Slave-Interface: em2
MII-Status: up
Geschwindigkeit: 1000 Mbps
Duplex: voll
...
Slave-Interface: em3
MII-Status: up
Geschwindigkeit: 1000 Mbps
Duplex: voll

auf dem Switch-Stack 2960X:

2960X#show lacp internal
Flags:  S - Gerät fordert langsame LACPDUs an
        F - Gerät fordert schnelle LACPDUs an
        A - Gerät ist im aktiven Modus       P - Gerät ist im passiven Modus

Kanalgruppe 1
                            LACP-Port     Admin     Oper    Port        Port
Port      Flags   Zustand     Priorität      Schlüssel       Schlüssel     Nummer      Zustand
Gi1/0/1   SA      bndl      32768         0x1       0x1     0x102       0x3D
Gi2/0/1   SA      bndl      32768         0x1       0x1     0x202       0x3D

2960X#sh etherchannel summary
Flags:  D - down        P - im Port-Channel gebündelt
        I - unabhängig s - ausgesetzt
        H - Hot-Standby (nur LACP)
        R - Layer3      S - Layer2
        U - in Gebrauch      N - nicht in Gebrauch, keine Aggregation
        f - konnte Aggregator nicht zuweisen

        M - nicht in Gebrauch, minimale Links nicht erfüllt
        m - nicht in Gebrauch, Port nicht aggregiert wegen nicht erfüllter minimaler Links
        u - ungeeignet zum Bündeln
        w - wartet auf Aggregation
        d - Standardport

        A - gebildet durch Auto LAG

Anzahl der verwendeten Kanalgruppen: 11
Anzahl der Aggregatoren:           11

Gruppe  Port-Channel  Protokoll    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         LACP      Gi1/0/1(P)  Gi2/0/1(P)

Ersteinrichtung der Netzwerk-Interfaces zur Verwaltung der Clusterressourcen auf Hosts Host1 und Host2

Konfiguration des logischen Interfaces BOND1 auf den Hosts zur Steuerung und seiner physischen Interfaces:

cat /etc/sysconfig/network-scripts/ifcfg-bond0
#BESCHREIBUNG - Verwaltung
DEVICE=bond0
NAME=bond0
TYPE=Bond
BONDING_MASTER=yes
IPV6INIT=no
ONBOOT=yes
USERCTL=no
NM_CONTROLLED=no
BOOTPROTO=none
BONDING_OPTS='mode=4 lacp_rate=1 xmit_hash_policy=2'

cat /etc/sysconfig/network-scripts/ifcfg-em0
#BESCHREIBUNG - Verwaltung
DEVICE=em0
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no 
NM_CONTROLLED=no 

cat /etc/sysconfig/network-scripts/ifcfg-em1
#BESCHREIBUNG - Verwaltung
DEVICE=em1
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no 
NM_CONTROLLED=no

Nach Abschluss der Einstellungen auf dem Stack 2960X und auf den Hosts starten wir das Netzwerk auf den Hosts neu und überprüfen die Funktionalität des logischen Interfaces.

systemctl restart network
cat /proc/net/bonding/bond1

2960X#show lacp internal
2960X#sh etherchannel summary

Wir konfigurieren die Verwaltungs-Netzwerkschnittstelle auf jedem Host in VLAN 17, und binden sie an die logische Schnittstelle BOND1:

Konfiguration von VLAN17 auf Host1:

cat /etc/sysconfig/network-scripts/ifcfg-bond1.17
DEVICE=bond1.17
NAME=bond1-vlan17
BOOTPROTO=none
ONBOOT=yes 
USERCTL=no 
NM_CONTROLLED=no 
VLAN=yes
MTU=1500  
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
IPADDR=172.20.17.163
NETMASK=255.255.255.0
GATEWAY=172.20.17.2
DEFROUTE=yes
DNS1=172.20.17.8
DNS2=172.20.17.9
ZONE=public

Konfiguration von VLAN17 auf Host2:

cat /etc/sysconfig/network-scripts/ifcfg-bond1.17
DEVICE=bond1.17
NAME=bond1-vlan17
BOOTPROTO=none
ONBOOT=yes 
USERCTL=no 
NM_CONTROLLED=no 
VLAN=yes
MTU=1500  
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
IPADDR=172.20.17.164
NETMASK=255.255.255.0
GATEWAY=172.20.17.2
DEFROUTE=yes
DNS1=172.20.17.8
DNS2=172.20.17.9
ZONE=public

Wir starten das Netzwerk auf den Hosts neu und überprüfen ihre Sichtbarkeit untereinander.

Damit ist die Konfiguration des Cisco 2960X Switch-Stacks abgeschlossen. Wenn alles richtig gemacht wurde, haben wir nun die Netzwerkverbindung aller Infrastrukturkomponenten auf L2-Ebene.

Konfiguration des Dell MD3820f SAN

Vor Beginn der Konfiguration des SAN muss es bereits mit dem Switch-Stapel von Cisco verbunden sein. 2960X mit den Verwaltungs-Schnittstellen sowie mit den Hosts Host1 und Host2 über FC.

Das allgemeine Schema, wie das SAN mit dem Switch-Stapel verbunden sein sollte, wurde im vorherigen Kapitel dargestellt.

Das Kabelschema des SAN über FC zu den Hosts sollte so aussehen:

Erstellung einer ausfallsicheren IT-Infrastruktur. Teil 1 – Vorbereitung auf die Bereitstellung des oVirt 4.3 Clusters

Beim Anschluss müssen die WWPN-Adressen für die FC HBA-Hosts, die an die FC-Ports des SAN angeschlossen sind, notiert werden – dies ist erforderlich für die spätere Konfiguration der Bindung der Hosts an die LUNs im SAN.

Auf dem Administrator-Arbeitsplatz laden wir das Dienstprogramm zur Verwaltung des Dell MD3820f herunter und installieren es – PowerVault Modular Disk Storage Manager (MDSM).
Wir verbinden uns über ihre Standard-IP-Adressen und konfigurieren dann unsere Adressen aus VLAN17, um die Controller über TCP/IP zu verwalten:

Storage1:

ControllerA IP - 172.20.1.13, MASK - 255.255.255.0, Gateway - 172.20.1.2
ControllerB IP - 172.20.1.14, MASK - 255.255.255.0, Gateway - 172.20.1.2

Nach der Adresskonfiguration gehen wir in die Verwaltungsoberfläche des SAN, setzen das Passwort, richten die Uhrzeit ein, aktualisieren die Firmware für Controller und Festplatten, falls erforderlich, usw.
Wie dies durchgeführt wird, ist beschrieben in Verwaltungshandbuch SAN.

Nach der Durchführung der oben genannten Einstellungen müssen wir nur noch einige wenige Schritte unternehmen:

Host-FC-Port-Identifikatoren konfigurieren – Host-Port-Identifikatoren.
Eine Gruppe von Hosts erstellen – Hostgruppe und unsere beiden Dell-Hosts hinzufügen.
Eine Festplattengruppe und darin virtuelle Festplatten (oder LUNs) erstellen, die den Hosts präsentiert werden.
Die Präsentation der virtuellen Festplatten (oder LUNs) für die Hosts konfigurieren.

Das Hinzufügen neuer Hosts und das Zuweisen von Host-FC-Port-Identifikatoren erfolgt über das Menü – Host-Zuordnungen -> Definieren -> Hosts…
Die WWPN-Adressen der FC-HBA-Hosts finden Sie beispielsweise im iDRAC des Servers.

Das Ergebnis sollte etwa so aussehen:

Erstellung einer ausfallsicheren IT-Infrastruktur. Teil 1 – Vorbereitung auf die Bereitstellung des oVirt 4.3 Clusters

Das Hinzufügen einer neuen Hostgruppe und das Zuweisen von Hosts erfolgt über das Menü – Host-Zuordnungen -> Definieren -> Host-Gruppe…
Für die Hosts den Betriebssystemtyp auswählen – Linux (DM-MP).

Nach dem Erstellen der Hostgruppe erstellen wir über den Tab Speicher & Kopierdienste, eine Festplattengruppe – Festplattengruppe, mit einem Typ, der von den Anforderungen an die Fehlertoleranz abhängt, beispielsweise RAID10, und darin die virtuellen Festplatten in der benötigten Größe:

Erstellung einer ausfallsicheren IT-Infrastruktur. Teil 1 – Vorbereitung auf die Bereitstellung des oVirt 4.3 Clusters

Und schließlich der letzte Schritt — die Präsentation der virtuellen Festplatten (oder LUNs) für die Hosts.
Dazu über das Menü – Host-Zuordnungen -> Lun-Zuordnung -> Hinzufügen… weisen wir die virtuellen Festplatten den Hosts zu, indem wir ihnen Nummern zuweisen.

Es sollte so aussehen wie auf diesem Screenshot:

Erstellung einer ausfallsicheren IT-Infrastruktur. Teil 1 – Vorbereitung auf die Bereitstellung des oVirt 4.3 Clusters

Damit beenden wir die Einrichtung der SAN, und wenn alles richtig gemacht wurde, sollten die Hosts die präsentierten LUNs über ihre FC-HBAs sehen.
Lassen Sie das System die Informationen über die angeschlossenen Festplatten aktualisieren:

ls -la /sys/class/scsi_host/
echo "- - -" > /sys/class/scsi_host/host[0-9]/scan

Sehen wir nach, welche Geräte auf unseren Servern sichtbar sind:

cat /proc/scsi/scsi
Angefügte Geräte:
Host: scsi0 Kanal: 02 Id: 00 Lun: 00
  Anbieter: DELL     Modell: PERC H330 Mini   Rev: 4.29
  Typ:   Direktzugriff                     ANSI SCSI Revision: 05
Host: scsi15 Kanal: 00 Id: 00 Lun: 00
  Anbieter: DELL     Modell: MD38xxf          Rev: 0825
  Typ:   Direktzugriff                     ANSI SCSI Revision: 05
Host: scsi15 Kanal: 00 Id: 00 Lun: 01
  Anbieter: DELL     Modell: MD38xxf          Rev: 0825
  Typ:   Direktzugriff                     ANSI SCSI Revision: 05
Host: scsi15 Kanal: 00 Id: 00 Lun: 04
  Anbieter: DELL     Modell: MD38xxf          Rev: 0825
  Typ:   Direktzugriff                     ANSI SCSI Revision: 05
Host: scsi15 Kanal: 00 Id: 00 Lun: 11
  Anbieter: DELL     Modell: MD38xxf          Rev: 0825
  Typ:   Direktzugriff                     ANSI SCSI Revision: 05
Host: scsi15 Kanal: 00 Id: 00 Lun: 31
  Anbieter: DELL     Modell: Universal Xport  Rev: 0825
  Typ:   Direktzugriff                     ANSI SCSI Revision: 05
Host: scsi18 Kanal: 00 Id: 00 Lun: 00
  Anbieter: DELL     Modell: MD38xxf          Rev: 0825
  Typ:   Direktzugriff                     ANSI SCSI Revision: 05
Host: scsi18 Kanal: 00 Id: 00 Lun: 01
  Anbieter: DELL     Modell: MD38xxf          Rev: 0825
  Typ:   Direktzugriff                     ANSI SCSI Revision: 05
Host: scsi18 Kanal: 00 Id: 00 Lun: 04
  Anbieter: DELL     Modell: MD38xxf          Rev: 0825
  Typ:   Direktzugriff                     ANSI SCSI Revision: 05
Host: scsi18 Kanal: 00 Id: 00 Lun: 11
  Anbieter: DELL     Modell: MD38xxf          Rev: 0825
  Typ:   Direktzugriff                     ANSI SCSI Revision: 05
Host: scsi18 Kanal: 00 Id: 00 Lun: 31
  Anbieter: DELL     Modell: Universal Xport  Rev: 0825
  Typ:   Direktzugriff                     ANSI SCSI Revision: 05

lsscsi
[0:2:0:0]    Festplatte    DELL     PERC H330 Mini   4.29  /dev/sda
[15:0:0:0]   Festplatte    DELL     MD38xxf          0825  -
[15:0:0:1]   Festplatte    DELL     MD38xxf          0825  /dev/sdb
[15:0:0:4]   Festplatte    DELL     MD38xxf          0825  /dev/sdc
[15:0:0:11]  Festplatte    DELL     MD38xxf          0825  /dev/sdd
[15:0:0:31]  Festplatte    DELL     Universal Xport  0825  -
 [18:0:0:0]   Festplatte    DELL     MD38xxf          0825  -
[18:0:0:1]   Festplatte    DELL     MD38xxf          0825  /dev/sdi
[18:0:0:4]   Festplatte    DELL     MD38xxf          0825  /dev/sdj
[18:0:0:11]  Festplatte    DELL     MD38xxf          0825  /dev/sdk
[18:0:0:31]  Festplatte    DELL     Universal Xport  0825  -

Auf den Hosts kann auch zusätzlich konfiguriert werden multipath, und obwohl dies bei der Installation von oVirt auch automatisch erfolgen kann, ist es besser, die Funktionsfähigkeit des MP zuvor selbst zu überprüfen.

Installation und Konfiguration von DM Multipath

yum install device-mapper-multipath
mpathconf --enable --user_friendly_names y

cat /etc/multipath.conf | egrep -v "^s*(#|$)"
defaults {
    user_friendly_names yes
            find_multipaths yes
}

blacklist {
  wwid 26353900f02796769
  devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"     
  devnode "^hd[a-z]"
 }

Wir richten den MP-Dienst für den Auto-Start ein und starten ihn:

systemctl enable multipathd && systemctl restart multipathd

Überprüfung der Informationen über die geladenen Module für den Betrieb des MP:

lsmod | grep dm_multipath
dm_multipath           27792  6 dm_service_time
dm_mod                124407  139 dm_multipath,dm_log,dm_mirror

modinfo dm_multipath
filename:       /lib/modules/3.10.0-957.12.2.el7.x86_64/kernel/drivers/md/dm-multipath.ko.xz
license:        GPL
author:         Sistina Software 
description:    Device-Mapper-Multipath-Ziel
retpoline:      Y
rhelversion:    7.6
srcversion:     985A03DCAF053D4910E53EE
depends:        dm-mod
intree:         Y
vermagic:       3.10.0-957.12.2.el7.x86_64 SMP mod_unload modversions
signer:         CentOS Linux Kernel-Signierschlüssel
sig_key:        A3:2D:39:46:F2:D3:58:EA:52:30:1F:63:37:8A:37:A5:54:03:00:45
sig_hashalgo:   sha256

Wir schauen uns die zusammenfassenden Informationen zur bestehenden Multipath-Konfiguration an:

mpathconf
Multipath ist aktiviert
find_multipaths ist deaktiviert
user_friendly_names ist deaktiviert
dm_multipath-Modul ist geladen
multipathd läuft

Nach dem Hinzufügen eines neuen LUN zur SAN und dessen Präsentation an den Host muss ein Scannen der an den Host angeschlossenen HBAs erfolgen.

systemctl reload multipathd
multipath -v2

Und schließlich überprüfen wir, ob alle LUNs an der SAN für die Hosts präsentiert wurden und ob alle über zwei Pfade erreichbar sind.

Überprüfung der MP-Funktion:

multipath -ll
3600a098000e4b4b3000003175cec1840 dm-2 DELL    ,MD38xxf
size=2.0T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='service-time 0' prio=14 status=active
| `- 15:0:0:1  sdb 8:16  active ready running
`-+- policy='service-time 0' prio=9 status=enabled
  `- 18:0:0:1  sdi 8:128 active ready running
3600a098000e4b48f000002ab5cec1921 dm-6 DELL    ,MD38xxf
size=10T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='service-time 0' prio=14 status=active
| `- 18:0:0:11 sdk 8:160 active ready running
`-+- policy='service-time 0' prio=9 status=enabled
  `- 15:0:0:11 sdd 8:48  active ready running
3600a098000e4b4b3000003c95d171065 dm-3 DELL    ,MD38xxf
size=150G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='service-time 0' prio=14 status=active
| `- 15:0:0:4  sdc 8:32  active ready running
`-+- policy='service-time 0' prio=9 status=enabled
  `- 18:0:0:4  sdj 8:144 active ready running

Wie zu sehen ist, sind alle drei virtuellen Festplatten an der SAN über zwei Pfade sichtbar. Somit sind alle vorbereitenden Arbeiten abgeschlossen, und wir können mit dem Hauptteil fortfahren – der Konfiguration des oVirt-Clusters, die im nächsten Artikel behandelt wird.

Quelle: habr.com