VSAN

Zum Thema VSAN gibt es einige sehr schöne Demos zum Durchklicken unter

https://storagehub.vmware.com/#!/vmware-vsan/vmware-vsan-demonstrations

vSAN Lab HW

Raspi als WLAN Access Point und DHCP/DNS Server

Für einen “Spiel Cluster” wird ein DNS/DHCP Server gebraucht. Dieser sollte neben Ethernet auch gleichzeitig ein WLAN Access Point und ein WLAN Client sein. Hier eine Config von mir. eth0 und wlan0 sind die DNS/DHCP Netze. wlan0 ist Accesspoint. wlan1 (Edimax mini) ist WLAN Client.

Wir brauchen einige Pakete….

apt-get update
apt-get upgrade
 
apt-get install hostapd
apt-get install dnsmasq
apt-get install bridge-utils
apt-get install iptables-persistent

DNS in der /etc/hosts klar machen…

127.0.0.1       localhost
 
192.168.10.1    rasp-dns.schubi.local   rasp-dns
192.168.10.10   vcsa.schubi.local       vcsa
192.168.10.11   esx-1.schubi.local      esx-1
192.168.10.12   esx-2.schubi.local      esx-2
192.168.10.13   esx-3.schubi.local      esx-3
192.168.10.14   esx-4.schubi.local      esx-4

In der /etc/dhcpcd.conf den DHCP Server konfigurieren. Domain Server ist der Raspi selber, alles andere regelt Google…

static routers=192.168.10.1
static domain_name_servers=192.168.10.1 8.8.8.8

In der /etc/dnsmasq.conf wird die Domain festgelegt. Zwischen wlan0 und eth0 wird eine Bridge gebaut. Die Bridge ist das Device für DHCP. Damit bekommt man eine DHCP Adresse, egal ob über WLAN Accesspoint oder Ethernet…

expand-hosts
domain=schubi.local
 
interface=br0
  listen-address=127.0.0.1
  listen-address=192.168.10.1
  bind-interfaces
  server=192.168.10.1
  dhcp-range=192.168.10.50,192.168.10.128,255.255.255.0,24h

In der /etc/hostapd/hostapd.conf wird wlan0 als Accesspoint konfiguriert

interface=wlan0
bridge=br0
hw_mode=g
channel=7
wmm_enabled=1
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
ssid=vSAN_Schubi
wpa_passphrase=VMware1!

In der bash Shell wird die Bridge gebaut

brctl addbr br0
brctl addif br0 eth0
brctl show

In der /etc/network/interfaces konfigurieren wir eth0 und br0 und definieren dauerhaft die Bridge Ports. wlan1 wird WLan Client (in meinem Fall tether ich über das Telefon)

source-directory /etc/network/interfaces.d
 
auto eth0
allow-hotplug eth0
iface eth0 inet dhcp
 
auto br0
iface br0 inet static
address 192.168.10.1
netmask 255.255.255.0
network 192.168.10.0
dns-nameserver 192.168.10.1
dns-search schubi.local
 
bridge_ports eth0 wlan0
 
auto wlan1
allow-hotplug wlan1
iface wlan1 inet dhcp
wpa-ssid "iPhone von Schubi"
wpa-psk "XXXXXXX"

In der Bash wird nun noch das IP Masquerading auf wlan1 konfiguriert. Durch das iptables-persistent Paket wird dies sofort persistent.

iptables -t nat -A POSTROUTING -o wlan1 -j MASQUERADE
iptables -t nat -L

Zeit für einen Reboot…

hilfreiche Links:

PowerShell/PowerCLI auf dem Raspi

apt-get install libunwind8
 
wget https://github.com/PowerShell/PowerShell/releases/download/v6.2.3/powershell-6.2.3-linux-arm32.tar.gz
 
mkdir ~/powershell
tar -xvf ./powershell-6.2.3-linux-arm32.tar.gz -C ~/powershell
 
#Start der Shell mit
~/powershell/pwsh
 
#...oder Alias
alias powershell='~/powershell/pwsh'
$PSVersionTable
 
Install-Module -Name VMware.PowerCLI -Scope CurrentUser
 
Set-PowerCLIConfiguration -InvalidCertificateAction:Ignore
 
Get-PowerCLIVersion
Get-PowerCLIConfiguration

Raspi mit VLANs

apt-get install vlan

In der /etc/modules

8021q

In der /etc/network/interfaces die virtuellen VLAN Nics configurieren

#Vlan3 vMotion
auto eth0.3
iface eth0.3 inet static
address 192.168.3.1
netmask 255.255.255.0
network 192.168.3.0
vlan_raw_device eth0
dns-nameserver 192.168.10.1
dns-search schubi.local
 
#Vlan10 CLASS B
auto eth0.10
iface eth0.10 inet static
address 172.16.0.1
netmask 255.255.0.0
network 172.16.0.0
vlan_raw_device eth0
dns-nameserver 192.168.10.1
dns-search schubi.local
 
#Vlan100 CLASS A
auto eth0.100
iface eth0.100 inet static
address 10.0.0.1
netmask 255.0.0.0
network 10.0.0.0
vlan_raw_device eth0
dns-nameserver 192.168.10.1
dns-search schubi.local

In der /etc/dnsmasq.conf

interface=eth0.3
  listen-address=127.0.0.1
  listen-address=192.168.3.1
  bind-interfaces
  server=192.168.10.1
  dhcp-range=192.168.3.10,192.168.3.250,24h
 
interface=eth0.10
  listen-address=127.0.0.1
  listen-address=172.16.0.1
  bind-interfaces
  server=192.168.10.1
  dhcp-range=172.16.0.10,172.16.255.250,24h
 
interface=eth0.100
  listen-address=127.0.0.1
  listen-address=10.0.0.1
  bind-interfaces
  server=192.168.10.1
  dhcp-range=10.0.0.10,10.255.0.250,24h

Netzwerk checken

esxcli network ip interface set  -m 9000 -i vmk3
 
esxcli vsan health cluster list
 
esxcli network ip interface list
 
esxcli vsan network ip add -i vmk0 -T=witness

Durchsatz mit iperf checken:

  • Firewall ausschalten auf dem Ziel -
    esxcli network firewall set --enabled false
  • iperf im Listen Modus unter Angabe der horchenden IP Angeben -
    /usr/lib/vmware/vsan/bin/iperf3.copy -s -B <Kernelport IP>
  • auf der Quelle die Firewall ausschalten -
    esxcli network firewall set --enabled false
  • Auf der Quelle iperf unter Angabe der Ziel-IP starten -
    /usr/lib/vmware/vsan/bin/iperf3.copy -c <Kernelport IP>
  • nach dem Test nicht vergessen, die Firewall wieder einzuschalten -
    esxcli network firewall set --enabled true

VSAN Cluster verschieben

Default Repair Delay Time anpassen

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2075456

esxcli system settings advanced set -o /VSAN/ClomRepairDelay -i <value in minutes>
 
/etc/init.d/clomd restart

2-Node Cluster with esxcli

VSAN Fehlerscenarien und Reaktion darauf

VSAN Cluster lokal

VSAN stretched Cluster/Fault Domains

Ich betrachte hier mal vorrangig eine VSAN Cluster mit zwei Seiten und einer Witness Appliance.

Hintergrund und Konfiguration von Fault Domains ist am einfachsten bei Cormac Hogan nachzulesen.

http://cormachogan.com/2015/04/20/vsan-6-0-part-8-fault-domains/

http://cormachogan.com/2017/03/10/2-node-vsan-topologies-review/

http://cormachogan.com/2015/09/11/a-closer-look-at-the-vsan-witness-appliance/

http://cormachogan.com/2015/09/14/step-by-step-deployment-of-the-vsan-witness-appliance/

Ausfall einer Platte

In einem Stretched Cluster wird von der lokalen Seite gelesen und auf beiden Seiten geschrieben. Bei Ausfall einer Platte erfolgt:

  • Lesen und Schreiben der betroffenen Objekte von der Remote Site
  • Die Objekte werden auf anderen Disks der lokalen Seite neu gespiegelt.
    • nach 60 Minuten, wenn die Platte als “nicht da” markiert wird
    • sofort, wenn die Platte als defekt markiert wird
  • im Hybrid Cluster muss der Cache auf der Remote Site der betroffenen VMs erst einmal angewärmt werden (Advanced Parameter existiert, um beide Seiten für Lese- und Schreiboperationen im Normalbetrieb zu nutzen (Warmer Cache)

Ausfall eines Hosts

Ein Ausfall deines Hosts entspricht dem Ausfall einer Disk, nur das wesentlich mehr Componenten betroffen sind HA startet die VMs neu und die Objekte werden neu auf Disks anderer Hosts synchronisiert.

Ausfall Netzverbindungen zu Hosts einer Seite

Wenn auf einer Seite Netzwerkprobleme mit ein oder mehreren Hosts auftreten, werden folgende Aktionen durchgeführt:

  • bei einem Host
    • Host wird als isoliert erkannt
    • Der VSAN Host hat kein Mehrheitsprinzip und die VMs können auf dem Host nicht mehr zu VSAN Objekten schreiben
    • HA stoppt VMs und startet diese auf anderen Knoten neu (“Shutdown” als Isolation Response ist wichtig!)
    • der isolierte Host hat keine VSAN Aktivität mehr
    • Die betroffenen Objekte werden auf anderen Hosts neu synchronisiert
  • wenn mehrere Hosts einer Seite vom Rest des Clusters isoliert werden
    • Es wird eine neue Network Group in diesen Hosts etabliert (in der vCenter WebGUI sieht man Gruppen mit fortlaufenden Nummern)
    • Die Components dieser neuen Network Group haben aber keine N+1 Mehrheit mit der Witness und verlieren die Vote
    • HA startet die VMs auf anderen Hosts neu

Ausfall einer kompletten Seite

Wenn eine komplette Seite ausfällt, gibt's folgende Reaktion:

  • Die Components der verblieben Seite bilden mit der Witness zusammen die Mehrheit. Somit wird diese Seite als “aktiv” erkannt
  • die VMs der verbliebenen Seite laufen weiter
  • die VMs der Crash-Seite werden mittels HA auf der anderen Seite (Fault Domain) neu gestartet.
  • ist die Seite wieder da, werden die Components wieder aussynchronisiert und alles läuft normal weiter. Dabei kann mit DRS Regeln Einfluss genommen werden, wie die Maschinen wieder zurück wandern.

Ausfall der Netzverbindung zwischen den Seiten

Gibt es einen Netzausfall zwischen den Seiten, aber die Witness ist noch erreichbar, kommt zum ersten mal die “Preferred Site” zum Einsatz.

  • Beide Seiten können nicht mehr synchron schreiben
  • Beide Seiten haben über die Witness “eigentlich” ein N+1 Verhältnis
  • Dadurch, das beide Seiten die Witness sehen, wird die “Preferred Site” als einzige aktive Seite markiert.
  • HA schaltet auf der Secondary Site die VMs aus und startet diese auf der “Preferred Site”
  • Ist die Netzverbindung wieder da, werden die Components neu aussynchronisiert und VSAN läuft normal weiter.
  • Mit DRS Regeln können die sekundären VMs automatisch wieder auf ihre Seite gebracht werden

Ausfall der Witness

Wenn die Witness komplett ausfällt oder die Erreichbarkeit über Netz von der primären Seite und der sekundären Seite nicht mehr gegeben ist, hat dies erst einmal keinen direkten Einfluss auf das VSAN.

Was passiert:

  • Die Witness hält nur Metadaten
  • Beide Seiten haben die Mehrheit, kein Ausfall, alles geht wie gewohnt weiter
  • Kommt jedoch jetzt ein weiter Ausfall (Disk, Host) gibt es Ausfall für die entsprechenden VMs, die Components auf diesen Geräten hatte (da die verbliebenen gespiegelten Components keine Mehrheit mehr haben.
  • kommt die Witness zurück, werden die Metadaten aktualisiert und alles geht weiter
  • ist die Witness nicht mehr wiederherstellbar, muss eine neue Witness ausgerollt und dem VSAN Cluster zugewiesen werden
  • Die Witnessdaten werden wiederhergestellt und alles läuft weiter

Die Witness muss beide Seiten sehen, um in einen VSAN Cluster verbunden zu werden. Erst nach der Aussynchronisation kann eine Seite “fehlen”.

kompletter Netzausfall - alle Hosts isoliert

Wenn alle Hosts in einem VSAN Cluster untereinander isoliert sind, passiert folgends:

  • Es entstehen für jeden Host “Single Node Cluster”, in dem der Host Master ist
  • Der Host kann aber keinen Backup Host oder Agent Hosts finden, außerdem hat er für seine Components keine Mehrheit. Somit werden keine Schreibzugriffe mehr zugelassen
  • HA findet in diesem Scenario keine Failover Hosts und kann nichts machen
  • Die VMs auf dem Host werden zu “Zombie” VMs, da sie laufen, aber keine Schreiboperationen mehr ausführen können
  • Falls VMs mit FTT=0 auf einem Host laufen und durch Zufall alle zugehörigen Components ebenfalls auf diesem Host laufen, wird diese VM weiterhin ausgeführt
  • werden die Netzverbindungen wiederhergestellt, läuft alles nach einer Sync-Zeit weiter. Die Zombie VMs müssen meist resetet werden und es kann vorkommen, das der Original-VM Name im Inventory durch die interne ID ersetzt wurde.

Netzausfall zwischen allen Standorten

Wenn das Netz an allen Standorten noch funktioniert, aber zwischen den Standorten nichts mehr geht entsteht ei ähnliche Scenario wir “Alle Hosts sind isoliert”.

  • Auf beiden Seiten wird jeweils eine eigene Netzwerk Partition erstellt
  • Jede Seite wählt einen eigenen Master und Backup Host
  • Jedoch können die Components keine Mehrheit gewinnen
  • HA kann nicht auf die andere Seite Schalten
  • Die Components werden für Schreibzugriffe gesperrt
  • Es entstehen Zombie VMs
  • Ausnahme: VMs mit FTT=0 laufen weiter, aber da der Standort keine Ausenanbindung hat, nutzt das wenig…
  • Wird die Netzverbindung wiederhergestellt, wird alles aussynchronisiert und es geht weiter

Storage Policy mit PowerCLI ausrollen

$ds = Get-Datastore vsanDatastore
$sp = "thickProvisioned"
$vms = Get-VM -Datastore $ds
foreach ($vm in $vms) { $vm, (Get-HardDisk -VM $vm) | Set-SpbmEntityConfiguration -StoragePolicy $sp }

Löschen einer Diskgroup

Um eine Diskgruppe zu löschen, muss die entsprechende Cachedisk gelöscht werden.

esxcli vsan storage remove --ssd=naa.xxxxxxx

Adv. Params

esxcli system settings advanced set -o /Net/Vmxnet3HwLRO -i 0
esxcli system settings advanced set -o /Net/UseHwTSO -i 0
esxcli system settings advanced set -o /Net/UseHwTSO6 -i 0
esxcli system settings advanced set -o /Net/TcpipDefLROEnabled -i 0
 
esxcfg-advcfg -s 2047 /LSOM/heapSize
esxcfg-advcfg -s 110000 /LSOM/diskIoTimeout
esxcfg-advcfg -s 4 /LSOM/diskIoRetryFactor
esxcfg-advcfg -s 512 /VSAN/DomClientheapsize
esxcfg-advcfg -s 48 /LSOM/lsomLogCongestionHighLimitGB
 
vsish 
get /vmkModules/vsan/dom/MaxNumResyncCopyInFlight
Default: 50
 
vsish -e set /vmkModules/vsan/dom/MaxNumResyncCopyInFlight 25
 
 
esxcfg-advcfg -s 1 /VSAN/SwapThickProvisionDisabled
Value of SwapThickProvisionDisabled is 1
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International