Category: vMWare

Blogs over vMWare problemen, weetjes, info etc.

VeeaM : Het automatisch testen van je backup met SureBackup

VeeaM : Het automatisch testen van je backup met SureBackup

VeeaM Backup testen met SureBackup

Backups maken is niet heel erg onbelangrijk, want het is niet de vraag óf je een keer iets moet restoren, maar wannéér !
En hoe maak je die backups dan ? Op tape ? naar een NAS of een dedicated backup appliance zoals bijvoorbeeld een StoreOnce ?
Vervolgens heb je een backup…maar hoe weet je nu of die backup ook echt goed en consistent is ?

Het zal namelijk niet de eerste keer zijn dat je backup altijd goed gaat, maar op het moment dat je iets moet restoren blijkt dat de backup zelf corrupt is.
Je hebt dan helemaal niets meer om te restoren !

Je kunt periodiek inplannen dat je een restore test doet waarbij je dus enkele servers en cruciale data op een alternatieve lokatie gaat restoren.
Dit is, afhankelijk van de hoeveelheid, een tijdrovende klus die veel storage kost en alles moet je handmatig doen.
Maar, en vooral als je ISO27001 gecertificeerd bent, moet een werkende backup gewaarborgd kunnen worden. Het liefst met een compleet rapport waarin staat wat er allemaal getest is en wat het resultaat was zodat je bij een audit kunt laten zien dat je bij een calamiteit een gegarandeerd werkende backup hebt.

Tijdrovend, veel werk…kan dat niet eenvoudiger ?

Goede vraag, en het antwoord is JA !
Sterker nog : het kan volledig geautomatiseerd !

We hebben hiervoor de VeeaM Backup and Replication Enterprise Edition nodig die voorzien is van het onderdeel SureBackup.
SureBackup is een soort virtueel laboratorium waarin VM’s direct vanuit de backup worden gestart in een afgesloten testomgeving waarna er testjes op losgelaten wordt.
Testjes zoals een heartbeat, ping en applicatie tests kunnen worden ingesteld.
Wanneer elke VM gestart en getest is, worden deze weer uitgeschakeld en wordt er een rapportje gemaakt.
Hierdoor weet je zeker dat je gerestorede VM’s op kunnen starten, consistente data bevatten en als je servers met een Active Directory, Exchange, SQL etc. Role hebt, kunnen die roles specifiek getest worden waardoor je hier ook zeker bent van werkende applicatie servers.

Klinkt goed ! Wat heb ik hier allemaal voor nodig ?

Hier geldt het gezegde : “Wie mooi wil zijn, moet pijn lijden” :

  • je hebt minimaal de op een na duurste variant van VeeaM Backup and Replication nodig, de Enterprise versie dus.
  • Een backup repository zoals bijvoorbeeld een NAS.
  • Een VMware cluster is nodig met in ieder geval 1 host die voldoende resources heeft om de gewenste VM’s te kunnen starten (CPU’s, RAM etc.)
  • Een VMware versie waarin Application Pools gelicentieerd zijn
  • Een stukje storage waarop tijdelijk data geplaatst kan worden die wordt gegenereerd bij SureBackup
    VeeaM beschikt over de mogelijkheid om VM’s rechstreeks vanuit de backup te kunnen opstarten zonder dat je eerst de data hoeft te restoren.
    Hierdoor heb je dus geen TerraBytes aan storage nodig om je backup te kunnen testen.

OK, heb ik ! en nu ?

Als je bovenstaande allemaal hebt, kun je Surebackup gaan inrichten.
Dit laten we hier niet stap voor stap zien, maar wel globaal.

SureBackup inrichten

Als je in VeeaM zit, gaan we naar Backup Infrastructure en selecteren daar SureBackup
Daar staat op volgorde al aangegeven welke stappen je moet maken :

Veeam surebackup inrichting 02

Stap 1 : Virtueel Lab maken

Om Surebackup te kunnen gebruiken, hebben we een Virtueel Lab nodig.
Zie dit als een echt laboratorium waar tests gedaan worden in een afgesloten en schone omgeving.

Om een SureBackup Virtual Lab in te richten heb je een aantal dingen nodig :

  • Een ESX Server die je aanwijst als machine waarop de VM’s worden getest
  • Een Datastore waarop data tijdens het testen wordt weggeschreven.
    Maak hiervoor een nieuwe datastore aan, dedicated voor SureBackup en deze hoeft niet heel erg groot te zijn, 100 GB is meer dan genoeg.
  • Een Application Pool (wordt automatisch in VMware aangemaakt wanneer je het lab activeerd.
  • SureBackup zal ook een proxy aanmaken welke als toegang wordt gebruikt wanneer je vanuit het productienetwerk in het testnetwerk wilt kunnen komen.
  • De verschillende netwerken waarin de betreffende VM’s zitten.
    Wanneer je meerdere netwerken hebt, zul je een geavanceerde setup moeten kiezen waarin je isolated networks maakt voorzien van een gateway zoals ook in het productienetwerk.
    De gateway wordt alleen in SureBackup gebruikt, dus heeft geen verbinding met het productie netwerk. Gebruik als IP adres/Subnet Mask hetzelfde als in het productie netwerk.

Veeam surebackup inrichting 13

En na het activeren van je Virtual Lab zoals hieronder :

Veeam surebackup inrichting 30

Wordt in VMware ook automatisch je SureBackup omgeving ingericht :
Een Application Pool met daarin de VeeaM Proxy VM.

Veeam surebackup inrichting 31

Wanneer je het lab ingericht hebt, heb je dus de beschikking over :

Een schone afgezonderde omgeving waarin VM gestart en getest kunnen worden, data die gegenereerd wordt door VM’s wordt weggeschreven op de aangewezen (kleine) storage.
Binnen in het Virtual Lab is je netwerk gelijk aan je productie netwerk, echter gescheiden door een proxy waardoor dit niet kan interfereren met de productieomgeving.

Stap 2 : Een Application Group maken

Een application group is een verzameling van VM’s die je selecteert om te testen.
Deze VM’s kun je met parameters laten starten bijvoorbeeld met hoeveel RAM geheugen etc. om het resource gebruik te beperken.
Ook kun je per VM aangeven welke rol deze heeft, bijvoorbeeld Domain Controller, Global Catalog, SQL of Exchange Server etc.
Aan de hand van de rol zullen ook de test scripts zullen worden aangepast, pas de tests aan naar eigen wens.
Meer hoef je hier niet te doen.

Veeam surebackup inrichting 21

Stap 3 : Maak een SureBackup job

Met een SureBackup Job koppel je de eerder gemaakte Virtual Lab aan een Application Group en stelt in wanneer deze moet starten.
Dit is het meest eenvoudige deel van de setup 🙂

Stap 4 : SureBackup Starten !

Als alles ingericht is, kunnen we de SureBackup starten.
Je zult dan zien dat 1 voor 1 de VM’s in een afgezonderde omgeving worden gestart en getest.

Veeam surebackup backup running 01

In de vSphere Interface van VMware zie je dat er het volgende gebeurd :

Veeam surebackup inrichting 32

De VM’s worden 1 voor 1 aangemaakt, opgestart en getest.
Elke VM bestaat uit de originele servernaam gevolgd door een aanvullende benaming zodat er geen dubbele namen ontstaan.
Je ziet ook uitroeptekentjes verschijnen in de gerestorede VM’s wat weer komt omdat er een MAC adres conflict is wat VMware detecteert.
Dit is geen probleem verder aangezien de backup VM’s en productie VM’s elkaar niet kunen “zien”.

Wanneer het testen klaar is, worden de VM’s weer uitgeschakeld en gederegistreerd.
Alles wordt netjes opgeruimd na voltooiing van de job.
Je ontvangt dan ook nog een rapport waarin staat wat er getest is en wat de resultaten waren.
Dit rapport kun je dan bijvoorbeeld weer aan de ISO27001 Auditor laten zien als bewijs dat je backup in orde en getest is.

Veeam surebackup inrichting 33

Puntje van aandacht

De combinatie Windows Server 2008R2 of Windows 7 in combinatie met een VMXNET3 driver heeft als resultaat dat bij het restoren de netwerkkaart opeens op DHCP staat.
Hierdoor kun je problemen met Exchange, SQL of je Domain Controller krijgen.

Hoe je dit op kunt lossen, lees je hier !

Conclusie

Tja…wel of niet investeren in deze mooie VeeaM optie ?
Het kost inderdaad een stuk meer dan de standaard versie, maar naast SureBackup krijg je er nog veel meer leuke opties bij.
En ja, het kost een stuk resources (op het moment dat de SureBackup Job draait) van je ESX host en je hebt een stukje dedicated storage nodig.
De vraag moet eigenlijk zijn : Wat kost het mij wanneer ik een belangrijke server of data moet restoren en de backup is corrupt ?
Waarschijnlijk zijn de kosten en zeker de lasten in dat geval veel zwaarder dan het aanschaffen van degelijke software waarvan je zeker kunt zijn dat je goede backups hebt !

Maar wat bijvoorbeeld te denken van :

  • VeeaM Exchange Explorer :
    • Direct vanuit een backup een enkele item of complete mailbox restoren in een paar klikken en minuten !
      Geen complete Exchange database meer terugzetten, cleanen, mounten en dan pas recoveren…gewoon direct vanuit de backup !
  • VeeaM Active Directory Explorer :
    • Per ongeluk een user of ander object verwijderd uit de AD ? Met de AD Explorer met een paar klikken en een paar minuten ben je al weer klaar !
  • VeeaM SQL Explorer :
    • Supersnel en heel eenvoudig SQL databases restoren ? Dat kan met de VeeaM SQL Explorer.

Het backuppen en restoren van data was nog nooit zo eenvoudig en snel !

Doe er je voordeel mee !

Na een VM restore staat de NIC op DHCP i.p.v. fixed !

Na een VM restore staat de NIC op DHCP i.p.v. fixed !

DHCP i.p.v. Static na een VM restore

Het restoren van een complete VM gaat makkelijk en snel, alleen soms duiken er wel eens wat rare dingetjes op.
Zo kan het bijvoorbeeld voorkomen dat een Server 2008R2 VM opeens na een restore zijn netwerkkaart op DHCP heeft staan i.p.v. statisch.
Normaal hoeft dat geen probleem te zijn, maar bij domain controllers, exchange servers etc. wil dat wel eens uitlopen op een niet werkende machine.

Oorzaak

De oorzaak zit hem in de VMXNET3 netwerkkaart driver.
Bij een restore, wat feitelijk een soort clonen is, zal Windows dit opmerken en zal de netwerkkaart een nieuw serienummer geven wat als gevolg heeft dat deze een nieuwe netwerkkaart zal installeren welke op default instellingen staat, dus DHCP.
Je kunt het zien aan de device manager dat er een nieuwe ethernet adapter geinstalleerd is.:

VM restore resulteert in DHCP 01

Dit zorgt er dus voor dat de restore 100% lukt, maar dat je achteraf nog moet gaan rommelen met de netwerkinstellingen.

Het probleem zit overigens alleen in Windows 7 en Windows Server 2008R2 in combinatie met de VMXNET3 driver.
Windows Server 2012 bijvoorbeeld heeft hier geen last van.

Oplossing

Microsoft heeft in samenwerking met VMware een hotfix uitgebracht hiervoor die er voor zorgt dat na het restoren geen nieuwe NIC meer geïnstalleerd wordt.
Deze fix is hier te downloaden voor Windows 7 / 2008R2 systemen met Service Pack 1.

Deze fix dient dan geïnstalleerd te worden op de VM waarna gereboot moet worden.
Backups die hierna gemaakt worden, kunnen dan gerestored worden waarbij de netwerkinstellingen behouden blijven !

VMware Syslog directory aanpassen naar eigen wens

VMware Syslog directory aanpassen naar eigen wens

VMware Syslog aanpassen

Het komt steeds vaker voor dat ESX servers geen local storage meer hebben en dat deze een interne SD geheugenkaart gebruiken.
Op deze SD kaart staat dan enkel de VMware installatie.
Maar deze kaartjes zijn vaak een GB of 8 groot, hoe doen we dat dan met de Syslogs om te voorkomen dat de SD kaarten vollopen met alle problemen van dien ?

Syslog lokatie aanpassen

We kunnen binnen VMware de syslog locatie aanpassen zodat deze niet naar de lokale SD kaart schrijft, maar bijvoorbeeld naar een datastore.
Deze lokatie moet natuurlijk door alle ESX hosts benaderbaar en writeable zijn.
Best Practice : Om deze wijziging door te voeren moet je de host na de aanpassing rebooten. Plan dit dus in aangezien dit voor downtime zorgt.
Wanneer de host gereboot is, zullen de syslogs naar de nieuwe lokatie geschreven worden.
Het werkt ook zonder reboot, wanneer de wijziging doorgevoerd is, zal ESX op een gegeven moment schrijven naar de nieuwe lokatie

Hoe moeten we de Syslog lokatie aanpassen ?

In dit artikel gaan we uit van ESX 6.5 welke enkel over vSphere Webclient beschikt.

Log in op de vSphere client en ga je naar je Datastores.
Bedenk goed op welke lokatie je de Syslogs weg wilt schrijven. Dit is later uiteraard wel weer te wijzigen maar dan zit je weer met downtime etc.
In mijn situatie heb ik een Hoofdmap ESX-CLUSTER-DATA gemaakt met daarin mappen voor elke ESX Host.

vmware logdir aanpassen 001

Als deze mappen gemaakt zijn, gaan we elke host af met de volgende stappen :

Selecteer de ESX Host en klik op het tabblad Configure.
Vervolgens ga je naar Advanced System Settings en klik je op de knop Edit
vmware logdir aanpassen 02

Er zijn heel erg veel settings, dus het makkelijkst kun je even zoeken op Syslog.global.logdir of gewoon logdir.
De setting Syslog.global.logdir duikt dan op. Bij Value moet je dan aangeven waar deze geschreven moeten worden.

Gebruik als formaat : [datastorenaam] rootfolder/subfolder

Druk als je klaar bent op OK
vmware logdir aanpassen 03

Nu is het tijd om de host te rebooten. In een VMware cluster met meerdere host kun je gewoon VM’s met vMotion migreren naar een andere host zonder dat deze down gaan.
Daarna start je de host opnieuw op.

Als de host weer opgestart is, kun je controleren of de syslogs inderdaad naar de nieuwe lokatie geschreven worden :
En inderdaad ! De map HV01 wordt beschreven met logfiles. Dit is dus in orde en kunnen we de rest van de hosts inrichten.

vmware logdir aanpassen 04

Klaar !

We zijn klaar, veel werk was het niet maar het zal veel gemak opleveren doordat je SD kaarten schoon van logging blijven.
Hoewel je per host over MB’s aan logging praat welke periodiek worden opgeschoond, niet veel dus, kan dat ook wel eens anders zijn wanneer er veel mutaties zijn waardoor de logging oploopt.
Met deze wijziging voorkom je dat je local storage volloopt.

3PAR 8200 Implementatie en indruk

3PAR 8200 Implementatie en indruk

HPE 3PAR 8200 Implementatie en indruk

Om ons storagecluster naar een nóg hoger plan te tillen zijn we gaan uitbreiden. Maar nu met 2x 3PAR 8200 Full Flash servers !
Ze zijn duur….ze zijn HEEL erg duur !
Maar wat krijg je voor al dat geld dan terug ? Het antwoord is vrij simpel : Veel, en vooral performance en uptime garantie.

Wat is 3PAR ?

3PAR is zo ongeveer de creme-de-la-creme op het gebied van storage. We hadden reeds StoreVirtuals (Lefthands) en dat zit in het middensegment van de storage markt.
De servers van 3PAR is Enterprise spul en dat merk je aan alle kanten, ten eerste aan de prijs, maar ook qua bestellen, leveren, opleveren, in gebruik nemen, garantie, support en performance.

3PAR is te herkennen aan de opvallende geel/zwarte servers :

3PAR 8200 Implementatie en indruk 01

Nadat er een 3PAR bestelling geplaatst is, neemt HP vervolgens contact met je op. De installatie wordt doorgesproken, er moeten configuratie documenten ingevuld worden en de installatie/oplever data worden geplanned. Daarbij krijg je ook de instructies om behalve de servers uit te pakken, niets te doen met de servers. Géén stekkers aansluiten, niet aanzetten, niks….

Dat hoort allemaal als service bij dit paradepaardje !
Om er zeker van te zijn dat de storage goed wordt aangesloten en ingericht, zal er een HP Hardware specialist komen die de hardware setup doet zoals aansluiten, opstarten en updaten van de firmwares.
Daarna komt de 3PAR Consultant om de storage daadwerkelijk voor gebruik in te richten.

Dit hebben we nu allemaal achter de rug en we kunnen dus gaan testen !

De geleverde 3PAR 8200 servers zijn 2 servers met elk 2 management/connectiviteit nodes en 10x 2TB Enterprise SSD schijven.
De garantie is standaard 5 jaar, ook op de SSD schijven en het monitoren gebeurd door HP zelf. De 3PAR’s sturen health informatie naar HP en mocht er wat aan de hand zijn dan zal HP sneller aan de telefoon hangen met de melding dat er een monteur onderweg is dan dat je zelf in de gaten hebt dat er iets mis is 🙂

3PAR Implementatie

De implementatie heeft nog wel wat voeten in de aarde, althans als het de eerste keer is.
Normaal gesproken worden de meeste 3PAR’s geleverd in een Fibre Channel omgeving, maar wij hebben een bestaande iSCSI omgeving. Maar ook dat is geen enkel probleem.
Het idee is om de 2 3PAR’s 8200 actief te gaan gebruiken op 2 sites, maar dat ze ook elkaars fail-over zijn in het ESX cluster.
Dit behoort allemaal tot de mogelijkheden en soms moet je, als je voor zekerheid gaat, op sommige vlakken concessies doen waar we straks op terug komen.

Laten we eerst eens de achterkant van een 3PAR 8200 bekijken :

We zien daar de 2 nodes zitten welke de iSCSI, Fibre Cannel, Remote Copy en Management regelen, en dan dubbel uitgevoerd voor het geval er 1 kapot zou gaan.

De aansluitingen zien we hieronder :

3PAR 8200 Implementatie en indruk 04

  1. 10GbE SFP+ aansluitingen t.b.v. iSCSI (3PAR in combinatie met HPE 5920AF-24XG 10GbE Switches in IRF setup)
  2. De gele netwerkkabels zijn voor het management van de 3PAR 8200
  3. De witte netwerkkabels zijn voor de Remote Copy optie.

Wat heb je nodig om een 3PAR op te kunnen leveren ?

Als eerste heb je een aantal subnets nodig :

  • iSCSI Subnet
  • Management Subnet
  • Remote Copy Subnet

Dan heb je de Service Processors nodig, dit kan een VM zijn maar ook een fysieke Service Processor.
De Service Processor bewaakt en configureert de 3PAR en rapporteert aan HP
Per 3PAR heb je een Service Processor nodig. In ons geval draaien we deze als VM.
Deze worden door HP aangeboden als een importeerbare OVA zodat deze snel uit te rollen is.

3PAR 8200 Implementatie en indruk 05

Als je met meerdere 3PAR’s gaat werken en failover moet ondersteunen, dan heb je een QUORUM-WITNESS nodig.
Ook dit is een VM en hoort op een 3e site te draaien.
In het geval van uitval (dat kan een 3PAR, kabel of netwerk zijn) zal de Quorum Witness als “scheidrechter” spelen welke 3PAR de actieve wordt en welke standby of in storing gezet moet worden.
Dit om eventuele Split Brains te voorkomen.

Deze hoeft alleen uitgerold te worden en voorzien te worden van een IP adres in het management subnet.
3PAR 8200 Implementatie en indruk 06

3PAR Subnets inrichten

Dit is uiteraard geheel aan jezelf om en hoe dit in te richten.
Denk daarbij aan :

  • iSCSI gedeelte moet kunnen praten met je iSCSI initiators (obvious :-))
  • De management interfaces van de 3PAR moet in hetzelfde subnet zitten als waar de Service Processor zich bevindt
  • De Remote Copy is 2x een 1Gbps link die d.m.v. 1 of meerdere switches de RC poorten van de 3PAR’s met elkaar verbindt.
    Hierover loopt het Remote Copy protocol, een soort TCP protocol maar dan wel heel effectief.

Alles ingericht ? Dan eindelijk aan de slag !

Als je je subnets, vlans en ip’s hebt ingericht en de 3PAR’s 8200 kunnen met de SP’s babbelen, dan kun je verder aan de slag.
Voor een failover moet je Remote Copy en een Remote Copy Group inrichten.
Dat is feitelijk niets anders dan een object dat verteld dat 3PAR-1 moet repliceren naar 3PAR-2 en andersom.

LUN’s die je aanmaakt moet je dan lid maken van deze Remote Copy group, anders wordt het volume niet gerepliceerd.

Dan nog even de Quorum Witness toevoegen voor een veilige failover.

Om LUN’s beschikbaar te maken zul je de aanwezige iSCSI initiators aan moeten maken zoals bijvoorbeeld de ESX servers en dan de LUN’s exporteren naar de Hosts.
Vervolgens kun je dan op de ESX servers de iSCSI adapter inrichten en storage toevoegen.

Even terugkomen op Remote Copy

We zouden nog even terugkomen op het doen van concessies wanneer je voor veiligheid gaat, dat gaan we nu doen !

Om een realtime datacopy op je tweede 3PAR te hebben, moet je dus de remote copy gebruiken.
Remote copy zorgt er voor dat de LUN’s op de ene 3PAR ook als passive, Read Only LUN aangemaakt wordt op de andere 3PAR en dat daar dan realtime replicatie plaatsvindt.
De ESX machines moeten via de iSCSI adapter beide 3PAR’s toevoegen.
Zodra, en dan praten we echt over millisecondes, een 3PAR onderuit gaat of zijn verbinding verliest, zorgt de remote copy er voor dat de passieve LUN actief wordt en Read/Write gemaakt wordt.
ESX Zal deze onderbreking ook merken en zal vervolgens d.m.v. multipathing (Round Robin) ook een failover doen naar de standby paden, dus de failover 3PAR.
De wijzigingen die dan plaatsvinden op dat LUN zullen later als de storing verholpen is door de herstelde 3PAR weer gesynchroniseerd worden en na de recover actie zal het passieve LUN weer Read Only worden en zullen de ESX servers weer hun iSCSI connecties herstellen.

3PAR 8200 Implementatie en indruk 07

  1. Zijn de standby paden naar de passieve LUN’s
  2. Zijn de aktieve paden naar de aktieve LUN’s

Bij een failover zullen de stanby paden dus active worden en de active zullen wijzigen naar “Dead links”

Deze failover hebben we op diverse manieren getest en dat werkt zo ontzettend goed dat je er niets van merkt als er een 3PAR uitvalt.
Je zult echt monitoring moeten gebruiken om te merken dat er wat gebeurd !

Maar nu komen we dan ook bij de concessie die gedaan moet worden om deze graad van datacontinuïteit te realiseren :
De 3PAR’s zijn met 4x 10GbE iSCSI verbonden. Wanneer een VM gaat lezen, merk je dit ook meteen : 1200MB+/seconde leessnelheden worden gehaald (=10GbE).
Maar het schrijven van data is een ander verhaal. Data pakketten worden pas gecommit wanneer Remote Copy de data weggeschreven heeft op de passieve LUN.
En dat gaat over 2x een 1Gbps link, dus max. 250 MB per seconde wat ook de schrijfsnelheid is van je VM’s !
Dat is de concessie die je moet overwegen : van 1200MB+ naar 250MB/Sec. maximale schrijfsnelheid.
Maar om een indruk te geven in de verschillen tussen 3PAR Full Flash SSD en een StoreVirtual HDD 6 node Cluster :

3PAR 8200 ServerStoreVirtual 4530 Cluster
3PAR 8200 Implementatie en indruk 083PAR 8200 Implementatie en indruk 09

Aan de andere kant : wanneer komt het voor dat je continue zoveel data aan het schrijven bent ?
En het aantal IOPS dat je haalt met full flash SSD maakt dat ook weer ruimschoots goed.
Het rebooten (dus afsluiten en weer opstarten) van bijvoorbeeld een Windows Server 2012 RDS VM is in luttele secondes klaar !

Wat ook een hele mooie optie is, is de Deduplication !
Je kunt LUN’s Thinly Deduped aanmaken en daarop je VM’s draaien.
Veelal bestaan virtuele machines als Windows Servers etc. uit dezelfde Operating Systems en dus ook dezelfde OS Systeem bestanden.
Deduplication zal er voor zorgen dat dezelfde bestanden maar 1 keer opgeslagen worden. Je wint hiermee dus enorm veel schijfruimte !

Indruk van de 3PAR’s

De eerste indruk is geweldig, die performance die eruit komt, de techniek achter de 3PAR, de service etc. het is allemaal geweldig !
Het failover gedeelte werkt echt perfect, zo snel heb ik nog nooit een failover zien plaatsvinden.

Als je uit de onder en middenklasse storage solutions komt, dan zal 3PAR een compleet nieuwe wereld zijn waarbij je je een paar keer achter de oren zult krabben om het kwartje achter bepaalde logica te doen laten vallen. Maar als je dat door hebt, en dat zal snel gebeuren, wil je niks anders meer !
Maar is dit echt het geld waard waarmee je een riant huis kunt kopen waard ?
Dat ligt er helemaal aan welke eisen je stelt aan je storage !
Wil je performance, stabiliteit, continuiteit, flexibiliteit en geweldige service en je server/storage gebeuren naar een hoog plan wilt werken ? Dat is dit het geld zeker waard.
Is dit allemaal minder belangrijk, kijk dan vooral naar minder kostende oplossingen, die zijn er namelijk ook legio welke prima voldoen.

3PAR biedt waar voor zijn geld en we gaan hier nog heel veel plezier aan beleven !

HPE 5920 IRF Stack bouwen met 4 switches

HPE 5920 IRF Stack bouwen met 4 switches

IRF Stack met 4 HPE 5920 Switches

IRF (Intelligent Resilient Framework), is een innovatie van H3C en HPE heeft deze techniek bemachtigd en daarmee hun 59xx switches uitgerust.
Met de IRF techniek kun je van meerdere switches 1 virtuele switch bouwen, dus je hebt 1 management IP adres en je zorgt voor een hoge mate van High Availability. De switches worden onderling verbonden d.m.v. IRF poorten welke je naar eigen wens kunt inrichten. Failover mechanismen zoals bijvoorbeeld Vrrp heb je hiermee niet meer nodig.

We gaan in dit artikel een IRF Stack bouwen met 4 switches, er van uitgaande dat de switches nog geen configuratie bevatten, bevat je 5920 al wél een bestaande configuratie ? Maak hier dan eerst een backup van !

Wat wordt het eindresultaat ?

  • Een werkende IRF Stack met 4 members
  • FAN Direction voorkeur is ingesteld
  • Het systeem heeft een naam

Hoe gaat het er uit zien ?

Onderstaand plaatje geeft aan hoe de switches met elkaar verbonden gaan worden en worden Slots genoemd :

IRF-5920

De configuratie van de switches

Er van uit gaande dat je de switches net uit de doos hebt gehaald en dus nog geen configuratie bevatten (de switches verliezen namelijk hun configuratie nadat je IRF hebt ingericht) gaan we dus met een lege config aan de slag.

De truc is om niet met de eerste switch te beginnen. De IRF Stack wordt dan namelijk niet actief.
Begin dus met de tweede switch, daarna de eerste, dan de derde en tot slot de vierde.

IRF Members maken

Als eerste dienen we de IRF members (fysieke switches zijn members) te nummeren en te prioriseren, switch 1 is reeds member 1, we beginnen met de tweede switch :

Switch 2

system-view

irf member 1 renumber 2

save force

quit

reboot

y (yes om te rebooten)

Switch 3

system-view

irf member 1 renumber 3

save force

quit

reboot

y (yes om te rebooten)

Switch 4

system-view

irf member 1 renumber 4

save force

quit

reboot

y (yes om te rebooten)

Na het rebooten kunnen we de IRF status controleren, we nemen even member 2 ter illustratie :

[HP]display irf
MemberID Role Priority CPU-Mac Description
*+2 Master 1 5c8a-38b0-bbcd —
————————————————–
* indicates the device is the master.
+ indicates the device through which the user logs in.

The Bridge MAC of the IRF is: 5c8a-38b0-bbcc
Auto upgrade : yes
Mac persistent : 6 min
Domain ID : 2

Hierboven zien we dat de MemberID op 2 staat, dus dit klopt.
Bij member 1, 3 en 4 zal dit ook goed moeten staan alvorens we verder kunnen.

IRF Poorten toewijzen

We beginnen zoals gezegd met Member 2 :

Er moeten 2 IRF poorten geconfigureerd worden, maar om dit te bereiken moeten deze eerst uitgeschakeld worden.
Volgorde voor elke switch :
– Poorten uitschakelen
– IRF Poorten maken
– Poorten activeren
– Configuratie opslaan
– IRF activeren

Switch 2

system-view

interface range Ten-GigabitEthernet 2/0/21 to Ten-GigabitEthernet 2/0/24

shutdown

irf-port 2/1

port group interface Ten-GigabitEthernet 2/0/21

port group interface Ten-GigabitEthernet 2/0/22

quit

irf-port 2/2

port group interface Ten-GigabitEthernet 2/0/23

port group interface Ten-GigabitEthernet 2/0/24

quit

interface range Ten-GigabitEthernet 2/0/21 to Ten-GigabitEthernet 2/0/24

undo shutdown

save force

irf-port-configuration active

Switch 1

system-view

interface range Ten-GigabitEthernet 1/0/21 to Ten-GigabitEthernet 1/0/24

shutdown

irf-port 1/1

port group interface Ten-GigabitEthernet 1/0/21

port group interface Ten-GigabitEthernet 1/0/22

quit

irf-port 1/2

port group interface Ten-GigabitEthernet 1/0/23

port group interface Ten-GigabitEthernet 1/0/24

quit

interface range Ten-GigabitEthernet 1/0/21 to Ten-GigabitEthernet 1/0/24

undo shutdown

save force

irf-port-configuration active

Als alles goed gaat, zal member 2 nu gaan rebooten, we kunnen verder met member 3 en 4

Switch 3

system-view

interface range Ten-GigabitEthernet 3/0/21 to Ten-GigabitEthernet 3/0/24

shutdown

irf-port 3/1

port group interface Ten-GigabitEthernet 3/0/21

port group interface Ten-GigabitEthernet 3/0/22

quit

irf-port 3/2

port group interface Ten-GigabitEthernet 3/0/23

port group interface Ten-GigabitEthernet 3/0/24

quit

interface range Ten-GigabitEthernet 3/0/21 to Ten-GigabitEthernet 3/0/24

undo shutdown

save force

irf-port-configuration active

Member 3 zal nu ook gaan rebooten, verder met member 4, de laatste !

Switch 4

system-view

interface range Ten-GigabitEthernet 4/0/21 to Ten-GigabitEthernet 4/0/24

shutdown

irf-port 4/1

port group interface Ten-GigabitEthernet 4/0/21

port group interface Ten-GigabitEthernet 4/0/22

quit

irf-port 4/2

port group interface Ten-GigabitEthernet 4/0/23

port group interface Ten-GigabitEthernet 4/0/24

quit

interface range Ten-GigabitEthernet 4/0/21 to Ten-GigabitEthernet 4/0/24

undo shutdown

save force

irf-port-configuration active

En je raadt het al, member 4 zal ook gaan rebooten 🙂

Mocht de IRF config niet opkomen, controleer dan de aansluitingen van de IRF poorten, deze moeten namelijk op volgorde aan worden gesloten zoals de afbeelding hierboven laat zien :
irf1/1 –> irf 2/2
irf2/1 –> irf 3/2
irf3/1 –> irf 4/2
irf4/1 –> irf 1/2

Als alle members weer actief zijn heb je als het goed is 1 grote virtuele switch bestaande uit 4 slots/members
De poorten van member 1 zijn genaamd 1/0/xx
De poorten van member 2 zijn genaamd 2/0/xx
De poorten van member 3 zijn genaamd 3/0/xx
De poorten van member 4 zijn genaamd 4/0/xx

Member priority instellen

Wanneer de IRF configuratie klaar is, is het belangrijk om te weten dat vanaf nu alle configuratie wijzigingen op member 1 plaats moeten vinden aangezien anders de config gewist zal worden !

We kunnen nu de priority instellen van de verschillende members op een waarde tussen 1 en 32 waarbij 32 de hoogste prioriteit is :

Connect met member 1 :

system-view

irf member 1 priority 32

irf member 2 priority 31

irf member 3 priority 30

irf member 4 priority 29

save force

Dat is alles !

Fan preferred direction instellen

Mogelijk brandt er een rood systemlampje welke eigenlijk groen moet branden. Dit ligt waarschijnlijk aan de configuratie van de fans in de switch.
Als dit door de fans komt, zul je meldingen op de console voorbij zien komen over fans in slot 1,2,3,4.

Dit is eenvoudig op te lossen !

Connect met member 1 :

Port-to-power of Power-to-port is afhankelijk van welke Fan module je in de switch hebt zitten !

fan prefer-direction slot 1 port-to-power
fan prefer-direction slot 2 port-to-power

fan prefer-direction slot 3 port-to-power
fan prefer-direction slot 4 port-to-power

save force

Je IRF Stack een systeem naam geven

Mocht je nog de systeem naam aan willen passen, dan kan dat ook eenvoudig :

system-view

sysname KIESEENNAAM

save force

Controle van de IRF configuratie

We kunnen met wat commando’s controleren of de IRF verbinding goed tot stand is gekomen :

Het commando display irf

dis irf

hpe 5920 irf 1

In bovenstaand overzicht zien we dat alle 4 members aanwezig zijn. Member 4 is de master (te zien aan het *) en op Member 1 zijn we ingelogged (te zien aan de +)

Het commando display device

dis device

hpe 5920 irf 2

Hier zien we een overzicht van de aanwezige switches, alle 4 staan ze er in.

Het commando display irf topology

dis irf topology

hpe 5920 irf 3

Nu krijgen we een overzicht te zien met de aanwezige links van en naar members.
Hier kun je dus zien welke IRF poort met welke Member verbonden is.

Het commando display lldp neighbour-information list

dis lldp neighbour-information list

hpe 5920 irf 4

Een overzicht van de door LLDP gedetecteerde neighbours en op welke poorten zich deze bevinden.

Ziet er allemaal goed uit dus !

Klaar !

Je hebt nu een werkende IRF Stack, of in ieder geval de basis om verder te configureren !
Nu kun je verder met vLAN’s, routing, port switching, toekennen van IP adressen etc en de stack dus helemaal naar eigen wens inrichten.

Dit artikel is gemaakt aan de hand van een IRF config die ik gemaakt heb op 4 HPE 5920AF-24XG switches waarbij 2 op Site A komen en onderling met 2 DAC kabels verbonden zijn en vanuit elke switch 2x 10Gbit glasvezel naar 2 switches op Site B welke onderling ook weer met 2 DAC kabels zijn verbonden.
De switches zullen als een 10Gbit backbone ingezet worden voor een VMware 6.5 Enterprise Plus cluster en een iSCSI cluster met 6 StoreVirtual nodes en 2 3PAR nodes wat als geheel vreselijk zal gaan vlammen ! 🙂

HPE 5920AF-24XG IRF
Wees er zeker van dat je een cirkel maakt om bij een defecte kabel een split-brain te voorkomen. In een cirkel kun je bij een kabel breuk altijd bij je bestemming komen.

De switches zullen komende tijd nog verder ingericht worden en bij leuke en/of interessante features zal ik dit artikel aanvullen.

Succes !

 

iSCSI Port Binding in VMware ESXi configureren

iSCSI Port Binding in VMware ESXi configureren

VMware iSCSI Port Binding

iSCSI Port Binding wordt gebruikt wanneer men meerdere paden naar een iSCSI target benodigd.
De standaard iSCSI configuratie op een VMware ESXi host maakt namelijk maar 1 pad aan naar een iSCSI target.
Bij uitval van een NIC of switch, zal de iSCSI target in dat geval niet meer bereikbaar zijn en daardoor alle VM’s uitvallen.
Met iSCSI Multipathing kun je dit voorkomen omdat elke VMware ESXi host meerdere paden heeft naar een iSCSI Target.

Introductie

Vóór vSphere 5.0, moesten beheerders iSCSI port binding via de command line configureren.
Er was geen andere manier en dit was meestal erg verwarrend zacht gezegd.

VMware heeft daarna een grafische user interface geintroduceerd welke tot in het huidige vSphere 6.5 terug te vinden is waarin iSCSI Port Binding in te richten is voor de iSCSI initiator.

We gaan deze wijzigingen aanbrengen waarbij we meerdere vmkernel ports gebruiken op de VMware ESXi host.

Maar, er zijn wel wat overwegingen te maken als je port binding wilt gaan gebruiken.
Hieronder een paar :

  • De target array moet in hetzelfde subnet zitten als de vmkernel poorten
  • Alle gebruikte vmkernel poorten moeten ook in dit subnet zitten
  • Port Binding ondersteund géén routing op dit moment

Dat gezegd hebbende, gaan we aan de slag met een iSCSI Port Binding voorbeeld

iSCSI Port Binding configureren met de vSphere Web Client

In dit voorbeeld gaan we 2 vmkernel poorten creëren op een nieuwe vSwitch.

Selecteer de ESXi host > Manage > Networking > Virtual Switches > Add Host Networking

iSCSI Port Binding configureren in VMware vSphere 6 - 1

Selecteer New standard switch

iSCSI Port Binding configureren in VMware vSphere 6 - 2

Voeg vmnic1 en vmnic2 toe vanuit de lijst met beschikbare fysieke adapters

iSCSI Port Binding configureren in VMware vSphere 6 - 3

Geef een label aan de vmkernel poort en laat de rest op de defaults staan

iSCSI Port Binding configureren in VMware vSphere 6 - 4

Geef het IP adres op voor de iSCSI1 vmkernel poort en klik op Next

iSCSI Port Binding configureren in VMware vSphere 6 - 5

Controleer de instellingen en klik op Finish

iSCSI Port Binding configureren in VMware vSphere 6 - 6

Nu voor de tweede vmkernel adapter, klik op Networking > vmkernel adapter > Add a new vmkernel port.
Selecteer een bestaande vSwitch (vSwitch1), geef de naam iSCSI2 aan de vmkernel poort.
Geef deze ook een IP adres en klik op Finish.
Je krijgt dan zoiets als onderstaande afbeelding (afhankelijk van jouw instellingen)

iSCSI Port Binding configureren in VMware vSphere 6 - 7

Het volgende dat we gaan doen is het opzetten van een NIC Teaming Policy voor de vmkernel poorten die we zojuist hebben gemaakt.
Klik op Networking > Virtual Switches > vSwitch1 > Select iSCSI1 > Klik op Edit.
Ga naar Teaming and Failover Section >

  • Selecteer de Load Balancing policy : Use Explicit failover order
  • Active adapter : vmnic1
  • Unused adapter : vmnic2

iSCSI Port Binding configureren in VMware vSphere 6 - 8

het moet er dan uit zien zoals hierboven.

Nu selecteer je de tweede vmkernel poort die we gemaakt hebben welke iSCSI2 is en doe hier het tegenovergestelde bij Active and Unused adapters.

iSCSI Port Binding configureren in VMware vSphere 6 - 9

Zo, nu hebben we het netwerkgedeelte van de iSCSI port binding gehad.

Software iSCSI adapter creëren

De volgende stap is het creëren van een Software iSCSI adapter. Klik op de host > Manage > Storage > Software Adapters > Add > Software iSCSI adapter

iSCSI Port Binding configureren in VMware vSphere 6 - 10

Je krijgt dan het volgende schermpje te zien, klik op OK.

iSCSI Port Binding configureren in VMware vSphere 6 - 11

Nu moeten we de Network Port Binding configureren voor de software iSCSI adapter die we zojuist gecreëerd hebben.

Vanuit de Storage adapters sectie, selecteer de vmhba33 adapter > Network Port Binding > Add

Selecteer de twee vmkernel poorten die we in het networking gedeelte hebben gemaakt en klik op OK.

iSCSI Port Binding configureren in VMware vSphere 6 - 12

Nu moeten we het Target IP adres opgeven welke de storage array is om de LUNs te kunnen zien.

Selecteer de vmhba33 adapter > Targets > Dynamic Discovery > Add

Geef het IP adres op of de FQDN.

iSCSI Port Binding configureren in VMware vSphere 6 - 13

Nu moeten we een rescan van de HBA adapters doen om de aanwezige LUNs te ontdekken op de storage array.

Als de scan klaar is, klik je op de Paths tab en moet je kunnen zien dat er 2 paden binnenkomen vanuit dezelfde array van de LUN.

iSCSI Port Binding configureren in VMware vSphere 6 - 14

iSCSI Port Binding inrichten via ESXCLI

Een andere manier om bovenstaand te realiseren is via de esxcli. De te nemen stappen zijn dezelfde als via de vSphere Web Client.

Hieronder de stappen om via esxcli bovenstaand te realiseren :

Maak een nieuwe standard vSwitch genaamd vSwitch1:

~ # esxcli network vswitch standard add -v vSwitch1

Wanneer dit gedaan is gaan we 2 portgroups maken iSCSI1 en iSCSI2:

~ # esxcli network vswitch standard portgroup add -p iSCSI1 -v vSwitch1
~ # esxcli network vswitch standard portgroup add -p iSCSI2 -v vSwitch1

Vervolgens koppelen we vmnic1 en 2 aan de nieuwe vSwitch:

~ # esxcli network vswitch standard uplink add -u vmnic1 -v vSwitch1
~ # esxcli network vswitch standard uplink add -u vmnic2 -v vSwitch1

De volgende stappen voeren we uit om deze te activeren

~ # esxcli network vswitch standard policy failover set -a vmnic1,vmnic2 -v vSwitch1

Nu moeten we vmnic1 aan iSCSI1 koppelen en vmnic2 aan iSCSI2

~ # esxcli network vswitch standard portgroup policy failover set -a vmnic1 -p iSCSI1
~ # esxcli network vswitch standard portgroup policy failover set -a vmnic2 -p iSCSI2

De laatste stap is het creëren van de VMkernel interfaces en te associëren met de portgroups die we zojuist gemaakt hebben en deze de correcte IP adressen geven.

~ # esxcli network ip interface add -p iSCSI1 -i vmk1
~ # esxcli network ip interface add -p iSCSI2 -i vmk2
~ # esxcli network ip interface ipv4 set -i vmk1 -I 192.168.0.18 -N 255.255.255.0 -t static
~ # esxcli network ip interface ipv4 set -i vmk2 -I 192.168.0.28 -N 255.255.255.0 -t static

Wanneer dit gebeurd is, is de netwerkconfiguratie klaar.

Vervolgens kunnen we een iSCSI target IP adres opgeven voor de Software iSCSI Adapter die gemaakt is.

~ # esxcli iscsi adapter discovery sendtarget add -a 192.168.0.108:3260 -A vmhba33

De laatste stap is de Network Port Binding.

~ # esxcli iscsi networkportal add –nic vmk1 –adapter vmhba33
~ # esxcli iscsi networkportal add –nic vmk2 –adapter vmhba33

Je kunt verifieren of multipathing correct werkt door het volgende commando op te geven :

~ # esxcli storage core path list

iSCSI Port Binding configureren in VMware vSphere 6 - 15

Beide manieren, via Webclient of esxcli leveren hetzelfde resultaat op.
Wat we nu hebben gemaakt is een failover voor het geval een iSCSI NIC kapot gaat of 1 van de switches.
Al het iSCSI verkeer zal dan over de nog werkende iSCSI connectie lopen en zal je cluster niet down gaan.
APC PowerChute Network Shutdown VMware Virtual Appliance

APC PowerChute Network Shutdown VMware Virtual Appliance

APC PowerChute Virtual Appliance

In dit artikel beschrijven we de installatie van de APC PowerChute Network Shutdown Virtual appliance.
Deze appliance zorgt er voor dat het VMware cluster netjes en goed wordt uitgeschakeld wanneer de UPS(‘en) leeg dreigen te raken.

PowerChute downloaden

Als eerste dienen we de appliance te downloaden. Deze is vanaf de APC webite gratis te downloaden.
Sla deze op een door jou gekozen lokatie op.

Om de appliance uit te rollen heb je de VMware vSphere client nodig. Kopieer het gedownloade bestand naar de plek waar de vSphere Client geinstalleerd is.
PowerChute heeft ongeveer 3 GB (Thick Provisioned) storage nodig. Qua CPU gebruikt de appliance 1 vCPU en heeft verder 512 MB vRAM nodig.

Pak het ZIP bestand uit, hier zit een OVA file in en start de vSphere client op.

PowerChute installeren

Onder File selecteer je nu “Deploy OVF File”
powerchute network shutdown installatie 1

Blader naar de map en selecteer de OVA file die je gedownload hebt en klik dan op Next.
powerchute network shutdown installatie 2

Hier zie je een overzicht wat de OVA inhoudt. Klik Next om door te gaan.
powerchute network shutdown installatie 3

Ga akkoord met de voorwaarden om door te kunnen gaan.
powerchute network shutdown installatie 4

Hier kun je de VM aan een locatie toevoegen. Klik daarna op Next om door te gaan.
powerchute network shutdown installatie 5

Dan dienen we een datastore te kiezen waar de VM op moet komen. Kies er 1 die je wilt en druk op Next.
powerchute network shutdown installatie 6

Hier kunnen we kiezen welke indeling de schijf moet krijgen. Kies welke je wilt, maar probeer zo veel mogelijk Thin Provisioning te ontwijken.
Je zult niet de eerste en zeker niet de laatste zijn die alles Thin Provisioned uitvoert en vervolgens met een volgelopen datastore zit met alle gevolgen van dien !
powerchute network shutdown installatie 7

Kies dan een netwerk waar de VM in komt te hangen.
powerchute network shutdown installatie 8

Vul hier de benodigde netwerk gegevens in zoals IP adres, DNS, Gateway en Subnet Mask.
powerchute network shutdown installatie 9

Tot slot krijgen we een overzicht te zien met de door ons gekozen settings. Wanneer dit allemaal klopt, druk dan op Finish.
powerchute network shutdown installatie 10

De deployment loopt nu en zal even duren
powerchute network shutdown installatie 11

En als de deployment klaar is, kun je op Close klikken.
powerchute network shutdown installatie 12

PowerChute opstarten en inrichten

Selecteer de PowerChute appliance en druk op het groene pijltje om deze te starten.
Je kunt ook de console er bij openen om te kijken wat er allemaal gebeurd.

powerchute network shutdown configureren 1

Het startscherm verschijnt waarna de appliance gaat booten.
powerchute network shutdown configureren 2

Laat de appliance booten….
powerchute network shutdown configureren 3

Eenmaal klaar, dan kom je in onderstaand scherm. druk op 1 om verder te gaan.
powerchute network shutdown configureren 4

Vervolgens krijg je de vraag om het root wachtwoord te wijzigen.
Verander dit en gebruik een sterk wachtwoord !
powerchute network shutdown configureren 5

Het opstarten is klaar. Nu gaan we kijken of er updates beschikbaar zijn voor de appliance.
Navigeer naar Login en druk op Enter
powerchute network shutdown configureren 6

Log dan in met de root credentials.
Om te updaten gebruik je het commando yum update
Maar om te kunnen updaten heb je uiteraard wel een internet verbinding nodig.
powerchute network shutdown configureren 7

Er wordt geinventariseerd welke updates er beschikbaar zijn. Vragen kun je met Y beantwoorden om door te gaan.
powerchute network shutdown configureren 8

Het updaten is klaar ! We kunnen nu de appliance gaan configureren !
powerchute network shutdown configureren 9

PowerChute configureren via de webinterface

Nu de appliance up and running en up to date is, kunnen we PowerChute daadwerkelijk gaan inrichten.

Start je favoriete browser en browse naar https://jouwappliance:6547

De meeste stappen spreken voor zich en zullen verder zonder begeleidende tekst getoond worden.
powerchute network shutdown setup 1

powerchute network shutdown setup 2

Kies hier of je een enkele VMware server hebt, of een cluster met meerdere VMware servers, gemanaged door een vCenter Server
powerchute network shutdown setup 3

Indien je een vCenter server gebruikt, dien je de credentials en het adres hiervan op te geven.
Let er ook even op dat je een vinkje onderin plaatst wanneer je je vCenter Server als VM Appliance draait en niet op een fysieke server.
powerchute network shutdown setup 4

powerchute network shutdown setup 5

Hier geef je op welke samenstelling van UPS’en je hebt. Heb je 1 UPS of meerdere ?
powerchute network shutdown setup 6

Vul de credentials in van de UPS gebruiker. Dit is dus een gebruiker die bekend is op de UPS !
Tevens is het verplicht de Authentication Phrase in te vullen. Pas de default phrase aan op de UPS en gebruik deze.
powerchute network shutdown setup 7

Vul het adres in van de UPS
powerchute network shutdown setup 8

powerchute network shutdown setup 9

powerchute network shutdown setup 10

powerchute network shutdown setup 11

powerchute network shutdown setup 12

powerchute network shutdown setup 13

powerchute network shutdown setup 14

powerchute network shutdown setup 15

powerchute network shutdown setup 16

powerchute network shutdown setup 17

Uiteraard zijn bovenstaande instellingen naar wens in te richten. Maar later kun je dit natuurlijk ook nog wijzigen.

Verder kun je niet heel erg veel aan de appliance wijzigen, maar daar is deze tenslotte ook niet voor.
De appliance zorgt ervoor dat er opdrachten uitgevoerd worden bij een UPS status wijziging.

Wanneer je onder Configure Events kijkt, kun je voor diverse gebeurtenissen acties instellen.
Bijvoorbeeld wanneer de resterende runtime onder de drempelwaarde komt, moet de appliance er voor gaan zorgen dat alle VM’s en hosts netjes worden afgesloten.
Je kunt hier alles instellen precies zoals jij dit wilt.
Heb je nog nooit met deze appliance gewerkt ? Test de diverse settings dan eerst in een testomgeving.
Een kleine instelling verkeerd zetten kan er namelijk voor zorgen dat je serverpark down gaat…oppassen dus !
PowerChute settings 1

Met de APC PowerChute Network Shutdown virtual appliance is je ESX cluster en VM’s beschermd mocht er een stroomstoring zijn die langer duurt dan de accu’s het volhouden.
Het serverpark zal dan vóórdat de accu helemaal leeg is ervoor zorgen dat alle machines netjes down gaan om zo problemen te voorkomen wanneer alles weer opgestart moet worden.
Dirty shutdowns kunnen namelijk vooral voor SQL en Exchange servers problematisch zijn omdat databases een dirty status hebben, niet meer willen mounten of gewoonweg corrupt geraakt zijn.

In ons geval moet het overigens een beste stroomstoring zijn aangezien we een APC Smart UPS met 10 Expansion Packs hebben staan. 1200 kilo aan accu’s zorgen er voor dat we bij stroomstoringen goed 6 uur door kunnen.
ups estimated runtime

 

VMware : A general system error occured: Authorize Exception

VMware : A general system error occured: Authorize Exception

VMware Authorize Exception

Wanneer je op een vCenter Server inlogged en deze melding krijgt, dan kan de vCenter Server Single Sign On geen verbinding krijgen met de domain controller via LDAP.
De melding luidt als volgt !
authorize-exception-1
A general system error occured: Authorize Exception

Voer onderstaande stappen uit om dit op te lossen :

Prerequisites :
– vCenter SSO
– het wachtwoord moet bekend zijn van admin@System-Domain
– Browser met Flash 11 ondersteuning

Stappenplan :
Begin eerst met het installeren van de vMWare vSphere Webclient, standaard installatie uitvoeren.

authorize-exception-2

Tijdens installatie komt onderstaande vraag. Zoals gezegd, moet dus het admin@System-Domain wachtwoord bekend zijn :
authorize-exception-3

Wanneer de installatie klaar is, krijg je een item in het start menu.
Start de vSphere Web Client en je komt in het volgende scherm :
authorize-exception-4

Vanzelfsprekend hier de juiste gegevens invullen.
Na het inloggen ga je naar het menu item “Administration” en dan naar Single Sign On configuration :
authorize-exception-5

Klik dan de LDAP connector aan en bewerk deze eerst om de bestaande gegevens te noteren.
Daarna de LDAP connector weggooien :
authorize-exception-6

Daarna een nieuwe connector aanmaken door op de + te klikken :
De bestaande config kun je namelijk niet aanpassen, vandaar dat we de oorspronkelijke config weggooien en een nieuwe aanmaken.

Dan is het nu afhankelijk waar het probleem zit.

Dat kunnen een tweetal zaken zijn (wat ik tot nu toe tegen ben gekomen)
– De Domain Controller staat geen anonieme queries toe via LDAP
– De Domain Controller staat geen connectie toe op poort 3268

Maak een nieuwe connector aan :
authorize-exception-7

Je kunt naar beneden scrollen en op “Test Connection” drukken.
Als alles goed is, krijg je de melding dat de connectie succesvol is en ben je klaar.

Wanneer je onderstaande melding krijgt :
authorize-exception-8

Dan staat de Domain controller geen anonieme queries via LDAP toe.
Maak dan een ldap user aan in de AD en wijzig de connector in onderstaand :
authorize-exception-9

Dan nog een keer op “Test Connection” klikken en de volgende melding zou dan moeten verschijnen:
authorize-exception-10

Hierna mag je alles bevestigen en de vSphere Webclient afsluiten.

Het kan nog zijn dat je de vMWare services of de vCenterserver even moet herstarten.

Nu kun je dan weer inloggen op de vCenterserver met de vSphere client en is het probleem opgelost ! :
authorize-exception-11

VMWare allemaal Orphaned Virtual Machines

VMWare allemaal Orphaned Virtual Machines

Orphaned VM’s in VMWare vCenter Server

Dat was even schrikken toen ik zag dat de VMWare backup niet goed had gelopen !
Er wordt een backup van 60 Virtual Machines gemaakt en 21 zijn er met een foutmelding uit geknald met verschillende foutmeldingen :
vranger-backup

De foutmeldingen :
Error: An error occurred performing query ‘DatastoreQuery’. Error: Unable to connect to the remote server
Error: An error occurred performing query ‘VirtualMachineConfigurationQuery’. Error: Unable to connect to the remote server
Object reference not set to an instance of an object
Error: API Call failed with message: A general system error occurred: vim.fault.GenericVmConfigFault
Error: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server

Hebben allemaal met de connectiviteit naar de vCenter Server te maken en diens hosts.

Toen maar even ingelogged op de vCenter Server om te checken wat er gaande was.
Ten eerste zag ik dat de 6 ESX Servers wel online waren, geen alarms of warnings.
Wat wel opviel was dat ALLE Virtual Machines als Powered Off zichtbaar waren met achter de VM Naam “(Orphaned)”
Onderstaand plaatje is niet een screenshot van ons serverpark maar een ander.
orphaned-vms

De “VM1 (orphaned)” is dus exact de melding die ik op alle 60 Virtual Machines kreeg.

Uiteraard heb ik de vCenter logbestanden nagekeken, maar daar was niets te zien. Ook viel op dat de Server statussen niet up to date waren.
Misschien was er iets aan de hand met de Management Agents op de ESX servers ?
Op alle ESX servers heb ik voor de zekerheid de Management Agents geherstart, maar dat haalde helaas niks uit.
Ook werd de vSphere Client er continue uitgegooid waardoor deze steeds weer opnieuw gestart moest worden.
Ondanks dat vSphere een enorme lading problemen presenteerde, vertelde de monitoring mij dat er niets aan de hand was !
Alle machines en alle services draaiden netjes.

Even ging door mijn gedachte om het complete serverpark te gaan rebooten, maar dat is zo goed als onmogelijk aangezien wij een 24/7 bedrijf zijn.
Op zo’n moment ga je dan dus zaken uitsluiten om voor een zo klein mogelijke impact te zorgen bij het troubleshooten :
– ALLE VM’s staan als orphaned, dus er is een probleem met ALLE ESX Hosts ?
– De ESX Hosts reageren allemaal netjes, rechtstreeks met vSphere connecten werkt beter, maar niet 100% (i.v.m. vCenter Agent)
– De monitoring zegt dat alles online is, en een quick check wijst dat inderdaad uit. Alles draait gewoon.
– vCenter Server crasht steeds, krijgt geen geüpdate data van de ESX Hosts.
– Connectiviteit is in orde
– Het StoreVirtual cluster draait ook gewoon zonder problemen.

Dit alles terug redenerend kan ik niet anders dan de conclusie trekken dat het probleem centraal ligt, dus op de vCenter Server.
Tenslotte kan niet alles opeens tegelijkertijd kapot gaan.
Eventlogs van Windows zelf gecontroleerd en dat was al snel BINGO !

Er kwamen vermeldingen voorbij over de SQL Database van de vCenter Server :
could not allocate space for object ‘dbo.vpx_host_vm_config_option’.’pk_vpx_host_vm_config_option’ in database…..

Could not allocate space…..dat klinkt alsof de database vol zit en er dus geen data meer bijgeschreven kan worden.
de VIM_SQLEXP SQL Instantie is een MS SQL Express instantie welke tot maximaal 10 GB grote databases kan handlen.
Dit gecontroleerd door in te loggen met de SQL Studio Express en bekeken hoeveel data er in de database stond.
Inderdaad was deze met 10 GB Data gevuld en liep tegen zijn max van de SQL Express versie !
Dat verklaard natuurlijk een hoop, maar hoe ga je nu die database kleiner maken zonder dat je je config kwijt raakt ?
Gelukkig is dit een bekend “probleem” bij VMWare en er wordt ook een oplossing aangeboden.
Deze oplossing houdt in dat je oude data verwijderd, maar alle configs en belangrijke zaken behoudt en bestaat uit slechts enkele stappen :

Voordat je begint : Maak EERST een backup van je vCenter Database !!!!!!!

Stap 1:
Stop alle vCenter Server Services

Stap 2:
Log in met SQL Studio Express op de vCenterdatabase en selecteer VIM_VCDB (1) en druk op New Query (2).
database-selecteren-en-nieuwe-query-uitvoeren

Stap 3:
Voer in de query het volgende in :
Create Table #Temp(Name sysname, rows int, reserved varchar(100), data varchar(100), index_size varchar(100), unused varchar(100))exec sp_msforeachtable ‘Insert Into #Temp Exec sp_spaceused ”?”, ”true”’ Select * From #Temp

En druk op Execute

Stap 4:
Maak een nieuwe query en voer daar het volgende in :
alter table VPX_EVENT_ARG drop constraint FK_VPX_EVENT_ARG_REF_EVENT, FK_VPX_EVENT_ARG_REF_ENTITY alter table VPX_ENTITY_LAST_EVENT drop constraint FK_VPX_LAST_EVENT_EVENT 
truncate table VPX_TASK 
truncate table VPX_ENTITY_LAST_EVENT
truncate table VPX_EVENT
truncate table VPX_EVENT_ARG
alter table VPX_EVENT_ARG add
constraint FK_VPX_EVENT_ARG_REF_EVENT foreign key(EVENT_ID) references VPX_EVENT (EVENT_ID) on delete cascade, constraint FK_VPX_EVENT_ARG_REF_ENTITY foreign key (OBJ_TYPE) references VPX_OBJECT_TYPE (ID) alter table VPX_ENTITY_LAST_EVENT add constraint FK_VPX_LAST_EVENT_EVENT foreign key(LAST_EVENT_ID) references VPX_EVENT (EVENT_ID) on delete cascade

En druk op Execute.
Dit zorgt er voor dat de Event History verwijderd wordt.

Stap 5:
In nog een nieuwe query voeren we het volgende in :
SELECT Count (*) FROM VPX_TEXT_ARRAY
WHERE NOT EXISTS(SELECT 1 FROM VPX_ENTITY WHERE ID=VPX_TEXT_ARRAY.MO_ID)

De VPX_TEXT_ARRAY houdt de informatie bij van de VM’s en Datastore informatie welke inclusief een samenvatting van de VM configs. Deze query is om te controleren hoeveel tabellen er zijn en wat de grootte is van VPX_TEXT_ARRAY

Stap 6:
In een nieuwe en laatste query voeren we de query in om oude data uit de VPX_TEXT_ARRAY te verwijderen :

DELETE FROM VPX_TEXT_ARRAY
WHERE NOT EXISTS(SELECT 1 FROM VPX_ENTITY WHERE ID=VPX_TEXT_ARRAY.MO_ID)
We zijn klaar met het onderhoud op de vCenter database !
Stap 7:
De laatste stap is het starten van de vMWare Services.
Wanneer alle services gestart zijn, start je de vSphere (Web) Client op en controleer je of alle hosts online zijn en alle VM’s weer normaal zichtbaar zijn.
Dat was inderdaad het geval !
Echter bij een heel aantal VM’s stond er een rood uitroeptekentje bij en het raadplegen van de Events vermeldde een probleem met de HA config :
ha-failure-vm
Dit is relatief eenvoudig op te lossen door de High Availability uit te schakelen en weer in te schakelen.
Noteer van tevoren even wat de exacte en juiste settings zijn omdat deze verwijderd worden !
Zet het vinkje uit bij “Turn On vSphere HA” en druk op OK.
configuratie-van-ha-in-vsphere
Het cluster zal zich dan herconfigureren en de uitroeptekens bij de VM’s zullen verdwijnen.
Als het configureren klaar is, ga je weer terug naar de eigenschappen van het cluster en dan zet je “Turn on vSphere HA” weer aan.
Neem tevens alle gegevens over die je genoteerd had van hoe de HA oorspronkelijk ingericht stond.
Als alles weer goed staat, druk je op OK en vCenter Server zal HA weer inschakelen met de door jouw ingestelde gegevens.
Het cluster draait nu weer als een HA cluster, uitroeptekentjes zijn weg, VM’s worden weer normaal getoond en we worden niet meer uit vSphere gegooid.
Probleem opgelost !
Link naar het originele vMWare KB Artikel
Android Watchlist client voor vMWare

Android Watchlist client voor vMWare

vSphere Watchlist voor Android/Apple Smartphones en tablets.

Watchlist is een prachtige en gratis mobile tool voor het monitoren van je vMWare cluster en het uitvoeren van basic onderhouds taken.
Je ziet alle connected hosts en VM’s die zich in het cluster bevinden.

Het is ook mogelijk om basis opdrachten uit te voeren zoals het rebooten van een ESX host of VM, een snapshot van een VM maken etc.
Tevens is de app voorzien van notificaties. Wanneer zich er iets voordoet in het cluster krijg je een pushmelding.
Je moet uiteraard hiervoor connectie hebben tot het ESX cluster via VPN o.i.d.

Bij het opstarten van de app vraagt Watchlist om in te loggen.
Het adres is het adres van de vCenter Server.
Username / Password zijn de credentials waarmee je normaal gesproken ook inlogged op de vCenter Server.

ESX + VM Overview

esx-host-overview

ESX Host Statistics

esx-host-statistics

ESX Host Grafieken

esx-graphs

ESX Host Tasks

esx-host-tasks

VM Statistics

vm-statistics

VM Tasks

vm-tasks

Je ziet het : vSphere Watchlist is een prachtige tool op je smartphone om remote inzage te krijgen op de status van je ESX cluster.
Ook heel handig als je onderweg bent en er is een probleem met een ESX host of VM, die je dan snel en makkelijk kun rebooten of ander eenvoudig onderhoud uit te voeren.

Watchlist Downloaden van Google Playstore!

Watchlist Downloaden van Apple Store

*TIP* :
Watchlist heeft de mogelijkheid de credentials op te slaan zodat je niet elke keer dit in hoeft te vullen waardoor dit een potentieel risico met zich mee brengt.
Mocht je deze tool willen gaan gebruiken op je smartphone, zorg er dan voor dat je telefoon voldoende beveiligd is met bijvoorbeeld vingerafdrukscan en/of wachtwoord om de telefoon te ontgrendelen.
Het is tenslotte alles behalve grappig wanneer je telefoon gestolen wordt, of kwijt raakt en iemand anders kan met 1 druk op de knop het hele ESX cluster onderuit gooien.
Bedenk dus heel goed van te voren of je telefoon of tablet voldoende beveiligd is voordat je dit soort tools gaat gebruiken !