Oprettelse af en fejltolerant IT-infrastruktur. Del 1 - forberedelse til implementeringen af ​​klyngen oVirt 4.3

Læserne præsenteres for principperne for opbygning af en fejltolerance-infrastruktur for små virksomheder inden for rammerne af et datacenter, som vil blive detaljeret behandlet i en lille artikelserie.

Indledning

Under datacentret (Data Center) kan forstås som:

  • en egen rack i et "serverrum" på virksomhedens område, der opfylder minimumskravene til strøm- og kølekapacitet for udstyret samt har internetadgang gennem to uafhængige udbydere;
  • en lejet rack med eget udstyr, placeret i et rigtigt datacenter – såkaldt collocation, der svarer til Tier III eller IV-standard, hvor der garanteres pålidelig strøm, køling og fejltolerance internetadgang;
  • fuldt lejet udstyr i et Tier III eller IV datacenter.

Hvilken placeringsmulighed man skal vælge – i hvert tilfælde er det individuelt, og afhænger normalt af flere grundlæggende faktorer:

  • hvorfor virksomheden overhovedet har brug for sin egen IT-infrastruktur;
  • hvad virksomheden ønsker fra IT-infrastrukturen (pålidelighed, skalerbarhed, styrbarhed osv.);
  • omfanget af de indledende investeringer i IT-infrastrukturen, samt hvilken type udgifter man har til den – kapitaludgifter (det vil sige at eget udstyr købes) eller driftsudgifter (udstyret lejes normalt);
  • planlægningshorisonten for selve virksomheden.

Der kan skrives meget om de faktorer, der påvirker virksomhedens beslutning om oprettelse og brug af dens IT-infrastruktur, men vores mål er at vise i praksis, hvordan man skaber denne infrastruktur, så den både er fejltolerant og samtidig kan spare penge – reducere udgifterne til køb af kommerciel software eller helt undgå dem.

Som lang erfaring viser, er det ikke værd at spare på hardwaren, da den, der er nærig, betaler to gange, og ofte meget mere. Men igen – god hardware er kun en anbefaling, og hvad man i sidste ende skal købe og til hvilken pris, afhænger af virksomhedens muligheder og ledelsens 'nærighed'. Her bør ordet 'nærighed' forstås i god mening, da det er bedre at investere i hardware i starten, så man senere undgår alvorlige problemer med vedligeholdelse og opgradering, for forkert planlægning og overdreven besparelse kan føre til langt større omkostninger senere hen end ved projektstart.

Så, de indledende data for projektet:

  • der er en virksomhed, der har besluttet at oprette sin egen webportal og bringe sin aktivitet på internettet;
  • virksomheden har besluttet at leje en rackplads til at placere sit udstyr i et godt datacenter, der er certificeret efter Tier III-standard;
  • virksomheden har besluttet ikke at spare meget på hardwaren, så den har købt følgende udstyr med udvidede garantier og support:

Udskiftsliste

  • to fysiske servere Dell PowerEdge R640 med følgende konfiguration:
  • to Intel Xeon Gold 5120 processorer
  • 512 Gb RAM
  • to SAS-diske i RAID1 til installation af OS
  • indbygget 4-port netværkskort 1G
  • to 2-port netværkskort 10G
  • et 2-port FC HBA 16G.
  • 2-kontroller Dell MD3820f SAN, tilsluttet direkte til Dell-værter via FC 16G;
  • to niveau 2-switched – Cisco WS-C2960RX-48FPS-L, sammenkoblet i et stack;
  • to niveau 3-switched – Cisco WS-C3850-24T-E, sammenkoblet i et stack;
  • Rack, UPS, PDU, konsolservere – leveres af datacentret.

Som vi kan se, har det eksisterende udstyr gode muligheder for både horisontal og vertikal skalering, hvis virksomheden kan konkurrere med andre lignende virksomheder på internettet og begynder at generere overskud, som kan geninvesteres i at udvide ressourcerne for yderligere konkurrence og vækst i indtjeningen.

Hvilket udstyr kan vi tilføje, hvis virksomheden beslutter at øge ydeevnen af vores compute-klynge:

  • vi har en stor kapacitet til antal porte på switche 2960X, så der kan tilføjes flere hardware-servere;
  • købe to FC-switches for at tilslutte dem til SAN og ekstra servere;
  • de eksisterende servere kan opgraderes – tilføje mere hukommelse, erstatte processorer med mere kraftfulde, tilslutte til 10G-netværk med de allerede eksisterende netværksadaptere;
  • til SAN kan der tilføjes ekstra diskhylder med den nødvendige type diske – SAS, SATA eller SSD, afhængigt af den planlagte belastning;
  • efter at have tilføjet FC-switchene kan der købes endnu en SAN for at tilføje mere diskplads, og hvis der købes en speciel mulighed for Remote Replication til den, kan der opsættes datagendannelse mellem SAN'er både inden for et datacenter og mellem datacentre (men dette er uden for artikelens rammer);
  • der findes også lag 3-switches – Cisco 3850, som kan bruges som et failover-netværkskerne til højhastighedsruting mellem interne netværk. Dette vil være meget hjælpsomt i fremtiden, efterhånden som den interne infrastruktur vokser. 3850 har også 10G-porte, som kan bruges senere, når netværksudstyret opgraderes til 10G-hastighed.

Da virtualisering nu er uundgåelig, vil vi selvfølgelig være med på bølgen, især fordi det er en fremragende måde at reducere udgifterne til køb af dyre servere til separate dele af infrastrukturen (webservere, databaser osv.), som ikke altid anvendes optimalt i tilfælde af lav belastning, som det vil være i starten af projektets lancering.

Desuden kommer virtualisering med mange andre fordele, som vi kan få stor nytte af: VM's fejltilgivelighed fra hardwarefejl, Live migration mellem de fysiske noder i klyngen for vedligeholdelse, manuel eller automatisk belastningsfordeling mellem noderne i klyngen osv.

For det hardware, som virksomheden køber, er det nærliggende at implementere et højt tilgængeligt VMware vSphere-kluster, men da enhver software fra VMware er kendt for sine "høje" priser, vil vi bruge helt gratis software til at styre virtualisering – oVirt, som er grundlaget for et velkendt, men allerede kommercielt produkt — RHEV.

Software oVirt nødvendig for at samle alle infrastrukturelementer i én helhed, så man kan arbejde nemt med højt tilgængelige virtuelle maskiner – det er databaser, webapplikationer, proxyservere, belastningsbalancer, servere til logindsamling og analyse mv., altså det, som vores virksomheds webportal består af.

Sammenfattende denne introduktion, forventer vi følgende artikler, som i praksis vil vise, hvordan man udruller hele virksomhedens hardware- og softwareinfrastruktur:

Liste over artikler

  • Del 1. Forberedelse til udrulning af oVirt 4.3 kluster.
  • Del 2. Installation og konfiguration af oVirt 4.3 kluster.
  • Del 3. Konfiguration af VyOS kluster, oprettelse af fejltolerance udadgående routing.
  • Del 4. Konfiguration af Cisco 3850 stack, oprettelse af intern netværksrouting.

Del 1. Forberedelse til udrulning af oVirt 4.3 kluster

Basisopsætning af værter

Installation og konfiguration af OS – dette er det nemmeste trin. Der findes utallige artikler om, hvordan man korrekt installerer og konfigurerer et OS, så der er ikke noget formål i at forsøge at give noget eksklusivt omkring dette.

Så vi har to Dell PowerEdge R640 værter, som skal have et OS installeret og udføre forberedende indstillinger for at kunne bruges som hypervisorer til at køre virtuelle maskiner i oVirt 4.3 kluster.

Da vi planlægger at bruge den gratis ikke-kommercielle software oVirt, er der valgt OS til udrulningen af værterne CentOS 7.7, selvom der også kan installeres andre OS på værterne til oVirt:

  • en specialbygget version baseret på RHEL, den såkaldte oVirt Node;
  • OS Oracle Linux, som om sommeren 2019 blev annonceret at oVirt ville være understøttet på den.

Før installation af OS anbefales det:

  • at konfigurere iDRAC netværksgrænsefladen på begge værter;
  • at opdatere firmware til BIOS og iDRAC til de seneste versioner;
  • at konfigurere serverens System Profile helst i Performance-tilstand;
  • at konfigurere RAID af lokale diske (RAID1 anbefales) til installation af OS på serveren.

Derefter installeres OS på den tidligere oprettede disk via iDRAC – installationsprocessen er almindelig, der er ikke nogen særlige momenter i den. Adgang til serverens konsol for at starte installationen af OS kan også opnås via iDRAC, selvom der intet forhindrer en i at tilslutte en skærm, tastatur og mus direkte til serveren og installere OS fra en 'USB-nøgle'.

Efter installationen af OS, udfører vi dens indledende indstillinger:

systemctl enable network.service
systemctl start network.service
systemctl status network.service

systemctl stop NetworkManager
systemctl disable NetworkManager
systemctl status NetworkManager

yum install -y ntp
systemctl enable ntpd.service
systemctl start ntpd.service

cat /etc/sysconfig/selinux
SELINUX=disabled
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

Installerer det grundlæggende softwarepakke

For at foretage den indledende opsætning af operativsystemet, skal en hvilken som helst netværksinterface på serveren konfigureres, så man kan få internetadgang for opdatering af operativsystemet og installation af nødvendige softwarepakker. Dette kan gøres både under installationen af operativsystemet og efterfølgende.

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 de nævnte indstillinger og softwarepakker er en personlig præference, og dette udvalg er kun vejledende.

Da vores vært vil fungere som hypervisor, aktiverer vi den nødvendige ydeevneprofil:

systemctl enable tuned 
systemctl start tuned 
systemctl status tuned 

tuned-adm profile 
tuned-adm profile virtual-host 

Du kan læse mere om ydeevneprofilen her: «Kapitel 4. tuned og tuned-adm«.

Efter installationen af operativsystemet, går vi videre til næste del – konfigurationen af netværksinterfaces på værter og stakken af Cisco 2960X-switches.

Konfiguration af Cisco 2960X-switchstakken

I vores projekt vil følgende VLAN-numre — eller broadcast domæner, der er adskilt fra hinanden for at opdele forskellige typer trafik, blive brugt:

VLAN 10 – Internettet
VLAN 17 – Administration (iDRAC, SAN, switchadministration)
VLAN 32 – VM produktionsnetværk
VLAN 33 – sammenkoblingsnetværk (til eksterne leverandører)
VLAN 34 – VM testnetværk
VLAN 35 – VM udviklernetværk
VLAN 40 – Overvågningsnetværk

Før vi går i gang, giver vi en L2-niveau skitse, som vi i sidste ende skal nå frem til:

Oprettelse af en fejltolerant IT-infrastruktur. Del 1 - forberedelse til implementeringen af ​​klyngen oVirt 4.3

For netværksinteraktion mellem oVirt-værter og virtuelle maskiner indbyrdes, samt til at administrere vores SAN, er konfigurationen af Cisco 2960X-switchstakken nødvendig.

Dell-værterne har indbyggede 4-port netværkskort, derfor er det hensigtsmæssigt at forbinde dem til Cisco 2960X ved hjælp af en fejltolerant netværksforbindelse, ved at bruge en gruppering af fysiske netværksporte i et logisk interface og protokollen LACP (802.3ad):

  • de første to porte på værten konfigureres i bondingsmode og forbindes til switchen 2960X – på dette logiske interface vil der blive konfigureret bro med en adresse til administration af værten, overvågning og kommunikation med andre værter i oVirt-klyngen; det vil også blive brugt til live-migrering af virtuelle maskiner;
  • de sidste to porte på værten konfigureres også i bonding-tilstand og forbindes til 2960X - på denne logiske grænseflade ved hjælp af oVirt, vil der senere blive oprettet bridges (i de relevante VLAN’er), som de virtuelle maskiner vil blive tilsluttet.
  • begge netværksporte inden for én logisk grænseflade vil være aktive, hvilket betyder, at trafik kan sendes over dem samtidig i load balancing-tilstand.
  • netværksindstillingerne på klyngeknudepunkterne skal være absolut ENS, med undtagelse af IP-adresserne.

Grundlæggende opsætning af switch-stakken 2960X og dens porte

Vores switches skal forberedes som følgende:

  • monteret i rack;
  • forbundet med to specialkabler af den nødvendige længde, for eksempel CAB-STK-E-1M;
  • tilsluttet strøm;
  • forbundet til administratorens workstation gennem konsolporten for deres indledende konfiguration.

Den nødvendige vejledning til dette findes på den officielle side producentens side.

Når ovenstående handlinger er udført, konfigurerer vi switches.
Hvad hver kommando betyder vil ikke blive uddybet i denne artikel; al nødvendig information kan findes selvstændigt, hvis nødvendigt.
Vores mål er at konfigurere switch-stacken så hurtigt som muligt og tilslutte værterne og kontrolgrænsefladerne til SAN.

1) Forbind til den primære switch, gå til privilegeret tilstand, dernæst ind i konfigurationsmode og udfør de grundlæggende indstillinger.

Basiskonfiguration for switch:

 aktiver
 konfigurer terminal

 værtsnavn 2960X

 ingen service pad
 service tidsstempler debug datetime msec
 service tidsstempler log datetime localtime show-timezone msec
 ingen service password-encryption
 service sekvens-numre

 switch 1 prioritet 15
 switch 2 prioritet 14
 stack-mac vedholdende timer 0

 ur zone MSK 3
  vtp tilstand transparent
  ip subnet-zero

 vlan 17
  navn Management

 vlan 32
  navn PROD

 vlan 33
  navn Interconnect

 vlan 34
  navn Test

 vlan 35
  navn Dev

 vlan 40
  navn Monitoring

 spanning-tree tilstand 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 intern allocation politik stigende
 port-channel load-balance src-dst-ip

 errdisable recovery årsag loopback
 errdisable recovery årsag bpduguard
 errdisable recovery interval 60

linje con 0
 session-timeout 60
 exec-timeout 60 0
 logging synkron
linje vty 5 15
 session-timeout 60
 exec-timeout 60 0
 logging synkron

 ip http server
 ip http secure-server
 ingen vstack

interface Vlan1
 ingen ip adresse
 luk

 afslut 

Gemmer konfigurationen med kommandoen «wr mem» og genstarter switch-stakken med kommandoen «genstart» på den førende switch 1.

2) Konfigurer netværksportene på switchen i access-tilstand i VLAN 17 for tilslutning af kontrolgrænseflader for SANS og iDRAC-servere.

Konfiguration af styringsporte:

interface GigabitEthernet1/0/5
 beskrivelse iDRAC - host1
 switchport access vlan 17
 switchport mode access
 spanning-tree portfast edge

interface GigabitEthernet1/0/6
 beskrivelse Storage1 - Cntr0/Eth0
 switchport access vlan 17
 switchport mode access
 spanning-tree portfast edge

interface GigabitEthernet2/0/5
 beskrivelse iDRAC - host2
 switchport access vlan 17
 switchport mode access
 spanning-tree portfast edge

interface GigabitEthernet2/0/6
 beskrivelse Storage1 – Cntr1/Eth0
 switchport access vlan 17
 switchport mode access
 spanning-tree portfast edge
 afslut

3) Efter genstarten af stakken, kontrollerer vi, at den fungerer korrekt:

Kontrol af stakkens funktion:

2960X#show switch stack-ring speed

Stack Ring Speed        : 20G
Stack Ring Configuration: Full
Stack Ring Protocol     : 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 Address : 0cd0.f8e4.XXXX
Mac persistency ventetid: Ubegribelig
                                           H/W   Nuværende
Switch#  Rolle   Mac Adresse     Prioritet Version  Status
----------------------------------------------------------
*1       Master 0cd0.f8e4.XXXX    15     4       Klar
 2       Medlem 0029.c251.XXXX     14     4       Klar

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

4) Indstilling af SSH-adgang til stakken 2960X

Til fjernstyring af stakken via SSH, vil vi bruge IP 172.20.1.10, som er konfigureret på SVI (switch virtuel interface) VLAN17.

Selvom det anbefales at bruge en dedikeret port på switchen til administrationsformål, er det dog et spørgsmål om personlige præferencer og muligheder.

Konfiguration af SSH-adgang til switch-stakken:

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

Sætter adgangskoden til privilegeret tilstand:

enable secret *myenablepassword*
service password-encryption

Konfiguration af 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) Konfigurerer de logiske EtherChannel-grænseflader og de fysiske porte, der forbindes til værterne. For enkelhedens skyld vil alle eksisterende VLAN'er blive tilladt på alle logiske grænseflader, men det anbefales normalt at konfigurere kun det, der er nødvendigt:

Konfiguration af EtherChannel-grænseflader:

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

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

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

interface Port-channel4
 description EtherChannel med 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

Primær opsætning af netværksgrænseflader for virtuelle maskiner på værter Host1 og Host2

Vi kontrollerer tilgængeligheden af de nødvendige moduler til bonding i systemet og installerer modulet til styring af broerne:

modinfo bonding
modinfo 8021q
yum install bridge-utils

Opsætning af den logiske grænseflade BOND1 for virtuelle maskiner på værterne og dens fysiske grænseflader:

cat /etc/sysconfig/network-scripts/ifcfg-bond1
#BESKRIVELSE - styring
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
#BESKRIVELSE - styring
DEVICE=em2
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
MASTER=bond1
SLAVE=yes
USERCTL=no 
NM_CONTROLLED=no 

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

Efter afslutningen af indstillingerne på stakken 2960X og værterne, genstarter vi netværket på værterne og kontrollerer funktionaliteten af den logiske grænseflade.

  • på værten:

systemctl restart network

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

Bonding Mode: IEEE 802.3ad Dynamisk linkaggregation
Transmit Hash Policy: layer2+3 (2)
MII Status: op
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
...
802.3ad info
LACP rate: hurtig
Min links: 0
Aggregator selection policy (ad_select): stabil
System priority: 65535
...
Slave Interface: em2
MII Status: op
Hastighed: 1000 Mbps
Duplex: fuld
...
Slave Interface: em3
MII Status: op
Hastighed: 1000 Mbps
Duplex: fuld

  • på stakken af switche 2960X:

2960X#show lacp internal
Flags:  S - Enheden anmoder om langsomme LACPDUs
        F - Enheden anmoder om hurtige LACPDUs
        A - Enheden er i aktiv tilstand       P - Enheden er i passiv tilstand

Channel group 1
                            LACP port     Admin     Oper    Port        Port
Port      Flags   State     Priority      Key       Key     Number      State
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 - ned        P - bundet i port-channel
        I - selvstændig s - suspenderet
        H - Hot-standby (kun LACP)
        R - Lag3      S - Lag2
        U - i brug      N - ikke i brug, ingen aggregation
        f - fejlede at allokere aggregator

        M - ikke i brug, mindste links ikke mødt
        m - ikke i brug, port ikke bundet på grund af mindste links ikke mødt
        u - uegnet til bundling
        w - venter på at blive aggregeret
        d - standardport

        A - dannet af Auto LAG

Antal kanalgrupper i brug: 11
Antal aggregater:           11

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

Primær opsætning af netværksgrænseflader til styring af cluster ressourcer på værterne Host1 og Host2

Opsætning af den logiske grænseflade BOND1 på værterne til styring og dens fysiske grænseflader:

cat /etc/sysconfig/network-scripts/ifcfg-bond0
#BESKRIVELSE - administration
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
#BESKRIVELSE - administration
DEVICE=em0
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
NM_CONTROLLED=no

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

Efter afslutningen af indstillingerne på stakken 2960X og værterne, genstarter vi netværket på værterne og kontrollerer funktionaliteten af den logiske grænseflade.

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

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

Vi konfigurerer den administrative netværksgrænseflade på hver vært i VLAN 17, og binder den til den logiske grænseflade BOND1:

Konfiguration af VLAN17 på 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 af VLAN17 på 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

Vi genstarter netværket på værterne og kontrollerer deres synlighed over for hinanden.

Denne opsætning af Cisco 2960X-switchene er nu afsluttet, og hvis alt er gjort korrekt, har vi nu netværksforbindelse mellem alle infrastrukturelementer på L2-niveau.

Konfiguration af Dell MD3820f lagringssystemet

Før vi påbegynder opsætningen af lagringssystemet, skal det allerede være tilsluttet stakken af Cisco-switche 2960X administrative grænseflader samt til værterne Host1 og Host2 via FC.

Den samlede skema for, hvordan lagringssystemet skal tilsluttes stakken af switche, blev præsenteret i det foregående kapitel.

Diagrammet for tilslutning af lagringssystemet via FC til værterne skal se sådan ud:

Oprettelse af en fejltolerant IT-infrastruktur. Del 1 - forberedelse til implementeringen af ​​klyngen oVirt 4.3

Ved tilslutningen er det nødvendigt at notere WWPN-adresserne for FC HBA-værterne, der er tilsluttet FC-portene på lagringssystemet – dette vil være nødvendigt for den efterfølgende opsætning af bindingen af værterne til LUN'er på lagringssystemet.

Download og installer værktøjet til at administrere Dell MD3820f lagringssystemet på administratorens arbejdstation – PowerVault Modular Disk Storage Manager (MDSM).
Vi tilgår det via dens standard IP-adresser og derefter konfigurerer vi vores adresser fra VLAN17, for at administrere controllerne via TCP/IP:

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

Efter konfiguration af adresserne, logger vi ind i administrationsgrænsefladen for lagringssystemet, og angiver et kodeord, konfigurerer tid, opdaterer firmware til controllerne og diske, hvis nødvendigt osv.
Hvordan det gøres - er beskrevet i administrationsvejledning Lagringssystem.

Efter udførelsen af ovennævnte indstillinger, skal vi kun udføre et par handlinger:

  1. Konfigurere værts FC portidentiteter – Værtsportidentifikatorer.
  2. Oprette en værtgruppe – Værtgruppe og tilføje vores to Dell værter til den.
  3. Oprette en diskgruppe og i den virtuelle diske (eller LUN'er), der vil blive præsenteret for værterne.
  4. Konfigurere præsentationen af virtuelle diske (eller LUN'er) til værterne.

Tilføjelse af nye værter og sammenknytning af dem med værts FC portidentiteter gøres gennem menuen – Værtkortlægning -> Definer -> Værter…
WWPN adresserne til værternes FC HBA kan f.eks. findes i iDRAC serveren.

Som resultat skal vi få noget, der ligner dette:

Oprettelse af en fejltolerant IT-infrastruktur. Del 1 - forberedelse til implementeringen af ​​klyngen oVirt 4.3

Tilføjelse af en ny værtgruppe og sammenknytning af værterne til den gøres gennem menuen – Værtkortlægning -> Definer -> Værtgruppe…
For værterne vælger vi OS-typen – Linux (DM-MP).

Efter oprettelsen af værtgruppen, gennem fanen Lagring & kopi tjenester, opretter vi en diskgruppe – Diskgruppe, med type afhængig af kravene til fejltolerance, f.eks. RAID10, og i den virtuelle diske af nødvendige størrelser:

Oprettelse af en fejltolerant IT-infrastruktur. Del 1 - forberedelse til implementeringen af ​​klyngen oVirt 4.3

Og endelig, det sidste trin — præsentation af virtuelle diske (eller LUN'er) til værterne.
Til dette gøres der gennem menuen – Værtkortlægning -> Lun kortlægning -> Tilføj… sammenknytning af de virtuelle diske til værterne ved at tildele dem numre.

Det skal se sådan ud, som på dette screenshot:

Oprettelse af en fejltolerant IT-infrastruktur. Del 1 - forberedelse til implementeringen af ​​klyngen oVirt 4.3

Med opsætningen af lagringssystemet afslutter vi, og hvis alt er gjort korrekt, bør værterne kunne se de præsenterede LUN'er gennem deres FC HBA.
Lad os få systemet til at opdatere informationen om de tilsluttede diske:

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

Lad os se, hvilke enheder der er synlige på vores servere:

cat /proc/scsi/scsi
Vedhæftede enheder:
Vært: scsi0 Kanal: 02 Id: 00 Lun: 00
  Leverandør: DELL     Model: PERC H330 Mini   Rev: 4.29
  Type:   Direkte-Adgang                    ANSI SCSI revision: 05
Vært: scsi15 Kanal: 00 Id: 00 Lun: 00
  Leverandør: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direkte-Adgang                    ANSI SCSI revision: 05
Vært: scsi15 Kanal: 00 Id: 00 Lun: 01
  Leverandør: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direkte-Adgang                    ANSI SCSI revision: 05
Vært: scsi15 Kanal: 00 Id: 00 Lun: 04
  Leverandør: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direkte-Adgang                    ANSI SCSI revision: 05
Vært: scsi15 Kanal: 00 Id: 00 Lun: 11
  Leverandør: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direkte-Adgang                    ANSI SCSI revision: 05
Vært: scsi15 Kanal: 00 Id: 00 Lun: 31
  Leverandør: DELL     Model: Universal Xport  Rev: 0825
  Type:   Direkte-Adgang                    ANSI SCSI revision: 05
Vært: scsi18 Kanal: 00 Id: 00 Lun: 00
  Leverandør: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direkte-Adgang                    ANSI SCSI revision: 05
Vært: scsi18 Kanal: 00 Id: 00 Lun: 01
  Leverandør: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direkte-Adgang                    ANSI SCSI revision: 05
Vært: scsi18 Kanal: 00 Id: 00 Lun: 04
  Leverandør: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direkte-Adgang                    ANSI SCSI revision: 05
Vært: scsi18 Kanal: 00 Id: 00 Lun: 11
  Leverandør: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direkte-Adgang                    ANSI SCSI revision: 05
Vært: scsi18 Kanal: 00 Id: 00 Lun: 31
  Leverandør: DELL     Model: Universal Xport  Rev: 0825
  Type:   Direkte-Adgang                    ANSI SCSI revision: 05

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

På værter kan du også konfigurere yderligere multipath, og selvom oVirt kan gøre dette automatisk under installationen, er det bedre at kontrollere MP's funktionalitet på forhånd.

Installation og konfiguration af 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]"
 }

Vi indstiller MP-tjenesten til automatisk opstart og starter den:

systemctl enable multipathd && systemctl restart multipathd

Kontrol af information om de indlæste moduler til MP arbejde:

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 target
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 signing key
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

Vi gennemgår den samlede information om den eksisterende multipath-konfiguration:

mpathconf
multipath er aktiveret
find_multipaths er deaktiveret
user_friendly_names er deaktiveret
dm_multipath-modulet er indlæst
multipathd kører

Efter at have tilføjet en ny LUN til SAN og præsenteret den til værten, skal der udføres en scanning af de tilsluttede HBA'er på værten.

systemctl reload multipathd
multipath -v2

Og til sidst kontrollerer vi, om alle LUN'er er blevet præsenteret til SAN for værterne, og om der er to veje til hver.

Kontrol af MP:

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

Som det ses, er alle tre virtuelle diske på SAN synlige via to veje. Således er alle forberedende opgaver udført, og vi kan gå videre til den primære del – konfigurationen af oVirt-klusteret, som vil blive behandlet i den næste artikel.

Kilde: habr.com

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster