VMware HA setup in orde brengen

[Phuncz]

Binnen en KMO'tje waar ik momenteel actief ben als systeembeheerder heeft men een tijd geleden het hele servergebeuren geplaatst op een vSphere 5.x HA setup bestaande uit twee servertjes en een SAN, waarop 10 VM'etjes draaien. We beschikken over een Essentials Plus licentie, zodat we de HA-voorziening kunnen gebruiken. De netwerkinfrastructuur bestaat uit enkele 100Mbit 3Com switches en een HP 1Gbit switch. Hoe de kabels lopen is gokken, zéér weinig gedocumenteerd. De laatste paar systeembeheerders waren allemaal van het type "het zit in m'n hoofd, dat is genoeg".

Nu mag ik de boel blijkbaar werkende houden. Ik heb ervaring met ESXi maar niet in een HA-setup (geen licentie tijdens opleiding) dus ik moet het doen met conservatieve aanpassingen op de live setup. Het probleem is dat ik niet kan testen wat ik doe in een testlab want dat is er nog lang niet. Het probleem is dat je bij sommige aanpassingen niet weet of je straks heel je infrastructuur offline haalt door een aanpassing en dat wil ik vermijden.

Er zijn echter toch wat problemen die ik bij de aanvang ontdek:

1. VMware klaagt over de enkele datastore (HP P2000 G3), dit heb ik kunnen omzeilen via een advanced setting zodat ik tenminste de VM's kan rebooten. Ik probeer het bestuur te overtuigen dat een backup datastore toch wel nodig is, zolang tot de mensen maar verder kunnen. Ik zoek hier eigenlijk een goedkope oplossing zodat 50-100 RDP-gebruikers nog steeds wat kunnen light-office'en (browsen, mail) als de P2000 eruit flikkert. Aangezien een tweede fibre-SAN weer vele duizenden euro gaat kosten waar men geen uitgaven aan wilt doen (idd: ), zijn er eventueel betaalbare SAN oplossingen of NAS-oplossingen die nuttig zijn ? Er draaien voornamelijk 50-100 gebruikers een RDP-sessie en de AD-structuur erachter.

2. de netwerkconfiguratie lijkt verre van optimaal:






Vreemd genoeg lijkt de ESXi op .201 niet verbonden te zijn met het netwerk, maar er draaien doodleuk 6 actieve VM's op.
Het probleem is echter dat vCenter Server klaagt over het ontbreken van redundancy in het Management Network voor host .202.

Dit is de Management Network NIC configuratie:

• .201 host
  • vmnic0 down (unused)
  • vmnic1 down (unused)
  • vmnic2 link 100Mbit (active)
  • vmnic3 link 1000Mbit (active)
• .202 host
  • vmnic0 link 1000Mbit (active)
  • vmnic1 link 1000Mbit (active)
  • vmnic2 down (unused)
  • vmnic3 down (unused)

Het lijkt me dus dat het komt omdat beide NIC's van de .202 host op dezelfde switch zitten.
Zover ik weet is het maar een bende unmanaged switches, dus ofwel heeft die HP 1Gbit switch RSTP ofwel mis ik iets.
Dan stel ik me de vraag: worden die secundaire, actieve connecties pas gebruikt zodra de eerste uitvalt ?

Het lijkt me best dat we kijken voor een nieuwe, tweede HP-switch die in de serverrack komt te hangen om die secundaire links te leggen, zodat ze bij uitval van de eerste HP-switch in de switch-rack, de vSphere hosts zichzelf nog zien en niet in paniek in Isolation Mode slaan.

Is het eigenlijk niet verstandig om bij beide hosts de overige twee poorten in te schakelen voor de Management Network ? Het lijkt me nogal vreemd dat VM Network en Management Network over dezelfde NIC's gegooid wordt maar misschien is hier een logica achter.
Dus opbouwen zoals volgende:

• .201 host
  • vmnic0 VM HP-Switch 1 (Active)
  • vmnic1 VM HP-Switch 2 (Standby)
  • vmnic2 MGMT HP-Switch 1 (Active)
  • vmnic3 MGMT HP-Switch 2 (Standby)
• .202 host
  • vmnic0 VM HP-Switch 1 (Standby)
  • vmnic1 VM HP-Switch 2 (Active)
  • vmnic2 MGMT HP-Switch 1 (Standby)
  • vmnic3 MGMT HP-Switch 2 (Active)

Kan ik deze aanpassingen maken zonder de boel uit HA te moeten halen, zonder de heartbeat monitors te triggeren en live, zolang ik telkens één connectie correct laat aangesloten of doe ik dit best in de late avond, vroege ochtend, weekend ?

3. Is er een manier om een HA-setup te maken in een testlab zonder een licentie te moeten kopen ? Volgens mijn leraar was dit enkel mogelijk als reseller of als de school bereid was zelf de licenties te betalen, maar dat zijn beide geen opties vrees ik. Het probleem is dat ik zo alles moet testen in een live-omgeving en het bestuur is helemaal niet van mening dat een test-omgeving ook maar een cent moet kosten. Natuurlijk is dat hun probleem maar je weet ook wie ervoor opdraait als heel de infrastructuur op zijn gat gaat als ik wat uitprobeer...

[tomtom901]

Zo snel op het eerste gezicht zie ik al dat je storage over het management (V)LAN lijkt mee te lopen in plaats van in een dedicated netwerk voor de storage infrastructuur. De 202 host zal waarschijnlijk over gefaild zijn naar vmnic2 of vmnic3 maar ik zie nergens de noodzaak voor stand by nics want VMware is prima in staat om dit zelf te kunnen.

Als inderdaad de primaire connectie uitvalt (lees: poort down) dan zal er overgeschakeld worden naar de stand by adapter. Er zijn echter meerdere methodes die gebruikt kunnen worden om te bepalen of een host in isolation staat of niet. Zo is er bijvoorbeeld communicatie onderling, maar ook bijvoorbeeld naar het default gateway adres wat ingesteld staat.

Daarbij komt nog dat er op de datastore die gedeeld wordt door beide hosts een .vSphere-HA mapje staat waar wat FDM (fault domain manager, de HA agent) spullen in staan. Ook dit wordt gebruikt wanneer een host geen netwerkconnectiviteit meer heeft over het management network, maar bijvoorbeeld nog wel naar de storage kan kletsen (al zal dat in jouw huidige setup ook niet meer gaan).

De default isolation response is leave powered on (je kan dit controleren door rechts te klikken op je cluster -> edit settings -> virtual machine options onder vSphere HA).

Ik zou in elk geval kijken of je een reden kunt achterhalen voor het standby zijn van al die adapters, en indien nee deze actief zetten.

Begrijp ik het tevens goed dat de management adressen van je host in hetzelfde subnet zitten als de productie machines en de storage? Dat is ook verre van ideaal.

Voor wat betreft je laatste vraag, je kan gewoon een trial licentie gebruiken (als je VMware installeert). Voor 60 dagen heb je dan de beschikking over zaken als HA, DRS en allemaal dat leuke speelgoed. vCenter kan je downloaden vanaf de VMware website en is ook als trial beschikbaar.

[CAPSLOCK2000]

1. Als je goedkoper gaat dan een P2000 moet je van de prestaties niet te veel verwachten. Ik denk dat je moet accepteren dat je dan niet "normaal" door kan draaien als de P2000 uit valt. Maar waarschijnlijk kun je in geval van nood wel een stel VMs opofferen en alleen het hoogstnoodzakelijke laten draaien.

2. Je voorgestelde netwerkconfiguratie ziet er goed uit. Kijk wel nog even naar je hardware van je hosts. Vaak zitten er twee netwerkkaarten op 1 chip. Die wil je dan ook weer verdelen over vms en mgmt. Het is goed mogelijk om het allemaal om te configureren zonder downtime, maar als het je eerste keer is zou ik het toch maar buiten kantooruren doen. Let er op dat je de verbinding met de ESX(i) machine zelf niet verbreekt. Om dat te voorkomen kan het handig zijn om een extra kernelport toe te voegen.

3. Voor de meeste VMWare-software kan je een gratis evaluatielicentie aanvragen.

[tomtom901]

CAPSLOCK2000 schreef op maandag 12 augustus 2013 @ 19:49:
2. Je voorgestelde netwerkconfiguratie ziet er goed uit. Kijk wel nog even naar je hardware van je hosts. Vaak zitten er twee netwerkkaarten op 1 chip. Die wil je dan ook weer verdelen over vms en mgmt. Het is goed mogelijk om het allemaal om te configureren zonder downtime, maar als het je eerste keer is zou ik het toch maar buiten kantooruren doen. Let er op dat je de verbinding met de ESX(i) machine zelf niet verbreekt. Om dat te voorkomen kan het handig zijn om een extra kernelport toe te voegen.

Die is er al, op 10.10.0.220 en 10.10.0.221 maar ik vraag me af waar deze voor gebruikt wordt. 2 management ingangen zou kunnen, een vMotion en / of ISCSI maar het blijft allemaal in hetzelfde subnet zitten voor zover ik zie.

Wat overigens wel handig is, TS, als je met standby adapters gaat werken, is om dit niet op de vSwitch te doen, maar op de port group. Dat wil zeggen dat je vSwitch dus alle adapters actief heeft, maar dat je op een andere laag (conform jouw voorbeeld op de VM en MGMT port groups) de active / standby aangeeft.

[ Voor 15% gewijzigd door tomtom901 op 12-08-2013 19:56 ]

[squaddie]

1. Je zou eens kunnen kijken naar een 2e hands (bijvoorkeur refurbished) SAN. Gezien je een P2000 san hebt is het lastig om nog goedkoper te gaan, het is een entry level SAN. Verder zou ik voor een productieomgeving oppassen met Qnap of soortgelijke apparaten die kunnen in mijn ervaring vaak onvoldoende IOs leveren die een gevirtualiseerde productie omgeving vereist.

2. Zoals het nu geconfigureerd is er 1 nic per host actief en bij uitval zal de standby nic overnemen. Maar dat heeft niets met te maken met de fysieke netwerkconfiguratie, maar alles met de configuratie in ESXi.

De eerste stap zou in mijn opinie zijn hosts te verbinden aan uitsluitend Gb switches, beide hosts twee nics te geven op elke switch zodat je in elk geval redundant bent en voor de loadbalancing zet je alle vier de kaarten actief.

Persoonlijk zou ik voor zo'n kleine omgeving geen apart netwerk bouwen voor management verkeer in mijn opinie is dat zonde van de redundancy en loadbalancing die je opoffert en maak je de omgeving nodeloos complex. Je zou eventueel een vlan kunnen optuigen om het enigzins te scheiden.

Zelfs al zou je HA triggeren heeft dat weinig effect omdat je VMs gelocked zijn door de hosts waarop ze draaien en zolang de lock actief is kan de andere hosts d VM niet herstarten onder HA. Uiteraard is het beter HA niet te triggeren door te zorgen dat de hosts contact blijven houden.

Als je weinig ervaring hebt zou ik of buiten kantoortijden sleutelen aan het netwerk zodat als het anders gaat dan verwacht dat je niet meteen een reeks gebruikers bij je bureau hebt staan of bijvoorkeur huur iemand in met ervaring en bespreek wat je wilt doen en hoe jij het wilt doen en laat hem dat beoordelen. Een paar uur consultancy kan een hoop ellende besparen.

3. Je kan ESXi en vCenter installeren zonder licentie in te geven en dan draait in evaluation mode en kan je alle features gebruiken en zo een testlab bouwen zonder licentiekosten. Je zal wel hardware moeten hebben om een testlab te kunnen bouwen inclusief shared storage.

[tomtom901]

squaddie schreef op maandag 12 augustus 2013 @ 19:56:
Zelfs al zou je HA triggeren heeft dat weinig effect omdat je VMs gelocked zijn door de hosts waarop ze draaien en zolang de lock actief is kan de andere hosts d VM niet herstarten onder HA. Uiteraard is het beter HA niet te triggeren door te zorgen dat de hosts contact blijven houden.

Exact wat er dus op die datastore staat, maar omdat zijn storage inline lijkt te zijn kan het wegvallen van de connectie wel een probleem zijn.

[squaddie]

Als ik de startpost goed heb gelezen heeft de TS een FC SAN en dan kan je in principe alle netwerkkabels lostrekken zonder dat HA zal triggeren vanwege Datastore Heartbeat. Zou dat uitstaan dan wordt HA actief, maar kan niets uitrichten vanwege de actieve locks die hosts hebben op de VMs.

Wat wel triggert bij lostrekken van alle netwerkkabels is de host isolation response en afhankelijk van de instelling kunnen je VMs alsnog worden uitgeschakeld.

[Phuncz]

Bedankt voor de vlotte en uitgebreide antwoorden, GoT laat zich weer van zijn beste kant zien !

tomverhaeg schreef op maandag 12 augustus 2013 @ 19:38:
Zo snel op het eerste gezicht zie ik al dat je storage over het management (V)LAN lijkt mee te lopen in plaats van in een dedicated netwerk voor de storage infrastructuur. De 202 host zal waarschijnlijk over gefaild zijn naar vmnic2 of vmnic3 maar ik zie nergens de noodzaak voor stand by nics want VMware is prima in staat om dit zelf te kunnen.

De reden dat ik standby adapters wil gebruiken is omdat we vermoedelijk allemaal unmanaged switches hebben, dus geen NIC teaming of Link Aggregation. Om te vermijden dat ik straks loops maak en heel de infrastructuur eruit flikker

tomverhaeg schreef op maandag 12 augustus 2013 @ 19:38:
Ik zou in elk geval kijken of je een reden kunt achterhalen voor het standby zijn van al die adapters, en indien nee deze actief zetten.

Bij één van de hosts stonden ze allemaal actief, bij de ander stond maar eentje actief. Nu heb ik bij elke host de tweede, linked, poort op standby gezet.

tomverhaeg schreef op maandag 12 augustus 2013 @ 19:38:Begrijp ik het tevens goed dat de management adressen van je host in hetzelfde subnet zitten als de productie machines en de storage? Dat is ook verre van ideaal.

Ja daar kwam ik toenstraks ook achter...
Sowieso wil ik ze fysiek gescheiden houden, evenals op derde laag zoals je zelf voorstelt. Hier zie ik echter wel wat issues om dit live te doen, het lijkt me dat hier veel kan misgaan als ik een klein foutje maak dus ik ga dit eerst grondig bekijken voordat ik het management onder een ander subnet zet.

tomverhaeg schreef op maandag 12 augustus 2013 @ 19:38:
Voor wat betreft je laatste vraag, je kan gewoon een trial licentie gebruiken (als je VMware installeert). Voor 60 dagen heb je dan de beschikking over zaken als HA, DRS en allemaal dat leuke speelgoed. vCenter kan je downloaden vanaf de VMware website en is ook als trial beschikbaar.

Aha dat is goed nieuws, hier was ik niet van op de hoogte. Hier kan ik zeker eens gebruik van maken.

CAPSLOCK2000 schreef op maandag 12 augustus 2013 @ 19:49:
1. Als je goedkoper gaat dan een P2000 moet je van de prestaties niet te veel verwachten. Ik denk dat je moet accepteren dat je dan niet "normaal" door kan draaien als de P2000 uit valt. Maar waarschijnlijk kun je in geval van nood wel een stel VMs opofferen en alleen het hoogstnoodzakelijke laten draaien.

Op zich zitten de zwaarste loads sowieso op de drie Terminal Services-servers, ik heb wel nog geen analyse van de data eisen kunnen doen. Helaas is het een non-profit en het verhaal van budgetten zal wel niet vreemd in de oren klinken. Het is voornamelijk dat we kunnen zeggen dat we effectief een High Availability setup hebben, iets wat nu niet is door de vele SPOF's die ik er probeer uit te werken.

CAPSLOCK2000 schreef op maandag 12 augustus 2013 @ 19:49:2. Je voorgestelde netwerkconfiguratie ziet er goed uit. Kijk wel nog even naar je hardware van je hosts. Vaak zitten er twee netwerkkaarten op 1 chip.

Het zijn beide HP DL360p G8's met elk één 4-port 1Gbit NIC, waarvan telkens maar twee poorten in gebruik. Daarmee dat ik die andere twee poorte ook in gebruik wil zien want dat is zielig zo
Het is natuurlijk niet volledig redundant, want 1 kaart per server, maar dan kan de setup toch tenminste een falende switch overleven, wat nu niet het geval is.

CAPSLOCK2000 schreef op maandag 12 augustus 2013 @ 19:49:Die wil je dan ook weer verdelen over vms en mgmt. Het is goed mogelijk om het allemaal om te configureren zonder downtime, maar als het je eerste keer is zou ik het toch maar buiten kantooruren doen. Let er op dat je de verbinding met de ESX(i) machine zelf niet verbreekt. Om dat te voorkomen kan het handig zijn om een extra kernelport toe te voegen.

Dat laatste is een handige tip, thx ! Maar je bedoelt toevallig niet de kernelport die elke host al heeft ? Hier ga ik me meer in moeten verdiepen wat ik daarmee kan.

tomverhaeg schreef op maandag 12 augustus 2013 @ 19:51:
Die is er al, op 10.10.0.220 en 10.10.0.221 maar ik vraag me af waar deze voor gebruikt wordt. 2 management ingangen zou kunnen, een vMotion en / of ISCSI maar het blijft allemaal in hetzelfde subnet zitten voor zover ik zie.

Geen iSCSI te zien hier, tenzij ik iets gemist heb. Ik weet ook niet waarom maar ik ga proberen deze vage zaken te achterhalen van de systeembeheerder die dat geplaatst heeft, als ik hem nog kan bereiken.

tomverhaeg schreef op maandag 12 augustus 2013 @ 19:51:
Wat overigens wel handig is, TS, als je met standby adapters gaat werken, is om dit niet op de vSwitch te doen, maar op de port group. Dat wil zeggen dat je vSwitch dus alle adapters actief heeft, maar dat je op een andere laag (conform jouw voorbeeld op de VM en MGMT port groups) de active / standby aangeeft.

Zijn port groups niet iets enkel voor Distributed Switch ? Deze zit namelijk niet in onze licentie (Essential Plus). Heb het even vluchtig bekeken en ik zie niet meteen het voordeel tov. het gebruiken van de fysieke poorten met een active/standby configuratie.

squaddie schreef op maandag 12 augustus 2013 @ 19:56:
1. Je zou eens kunnen kijken naar een 2e hands (bijvoorkeur refurbished) SAN. Gezien je een P2000 san hebt is het lastig om nog goedkoper te gaan, het is een entry level SAN. Verder zou ik voor een productieomgeving oppassen met Qnap of soortgelijke apparaten die kunnen in mijn ervaring vaak onvoldoende IOs leveren die een gevirtualiseerde productie omgeving vereist.

Hier had ik al schrik voor. Mijn ervaring met SAN en NAS in productieomgeving is nog te klein om aan te voelen wat nodig is, dus hier ben ik volledig afhankelijk van anderen hun kennis. Ik zal mijn oog openhouden voor een eventuele tweede P2000 SAN als ik ze ergens tegenkom "goedkoop".

squaddie schreef op maandag 12 augustus 2013 @ 19:56:
De eerste stap zou in mijn opinie zijn hosts te verbinden aan uitsluitend Gb switches, beide hosts twee nics te geven op elke switch zodat je in elk geval redundant bent en voor de loadbalancing zet je alle vier de kaarten actief.

Heb ik voor die load-balancing geen managed switches nodig ? Voorlopig is het ook niet nodig aangezien het RDP verkeer nu ook over WAN gaat, wat veel minder dan 1Gbit verbinding is en daarbuiten hebben we eigenlijk geen grote hoeveelheden netwerkdata, uitgezonderd nachtelijke backups.

squaddie schreef op maandag 12 augustus 2013 @ 19:56:
Persoonlijk zou ik voor zo'n kleine omgeving geen apart netwerk bouwen voor management verkeer in mijn opinie is dat zonde van de redundancy en loadbalancing die je opoffert en maak je de omgeving nodeloos complex. Je zou eventueel een vlan kunnen optuigen om het enigzins te scheiden.

Unmanaged switches helaas en een "apart netwerk bouwen" zou ik het niet meteen noemen wat ik van plan ben

squaddie schreef op maandag 12 augustus 2013 @ 19:56:
Zelfs al zou je HA triggeren heeft dat weinig effect omdat je VMs gelocked zijn door de hosts waarop ze draaien en zolang de lock actief is kan de andere hosts d VM niet herstarten onder HA. Uiteraard is het beter HA niet te triggeren door te zorgen dat de hosts contact blijven houden.

Als je weinig ervaring hebt zou ik of buiten kantoortijden sleutelen aan het netwerk zodat als het anders gaat dan verwacht dat je niet meteen een reeks gebruikers bij je bureau hebt staan of bijvoorkeur huur iemand in met ervaring en bespreek wat je wilt doen en hoe jij het wilt doen en laat hem dat beoordelen. Een paar uur consultancy kan een hoop ellende besparen.

Goede tips en hier ga ik zeker eens over praten met het bestuur. Ze dachten blijkbaar dat de koek af was maar er is nog veel werk aan om de setup af te maken, waar ze zich dus niet van bewust zijn.

squaddie schreef op maandag 12 augustus 2013 @ 20:19:
Als ik de startpost goed heb gelezen heeft de TS een FC SAN en dan kan je in principe alle netwerkkabels lostrekken zonder dat HA zal triggeren vanwege Datastore Heartbeat. Zou dat uitstaan dan wordt HA actief, maar kan niets uitrichten vanwege de actieve locks die hosts hebben op de VMs.

Wat wel triggert bij lostrekken van alle netwerkkabels is de host isolation response en afhankelijk van de instelling kunnen je VMs alsnog worden uitgeschakeld.

Aha duidelijk. Hier had ik me al eens op gestort maar het was niet volledig duidelijk maar nu dus wel. Het is idd een FC SAN: http://www8.hp.com/us/en/...oid=4118559#!tab=features

Nu ik echter de gegevens bekijk, lijkt het me dat we een dual-controller P2000 G3 hebben. Dit is een foto die ik geschoten heb recent:



Hieruit kun je ook opmaken dat ze gekozen hebben om de twee FC-links naar dezelfde host kaart te sturen. Hadden ze niet beter deze gesplitst over de twee host controllers ?
Zou ik hierdoor niet al aan de minimum eis kunnen voldoen voor de twee datastores of moeten het effectief twee verschillende RAID arrays zijn ?

[ Voor 7% gewijzigd door Phuncz op 12-08-2013 21:22 ]

[tomtom901]

Port Groups kan je ook zeker gebruiken met vSS (vSphere standard switches), sterker nog, je hebt er al in gebruik, en eentje heet er bijvoorbeeld VM network. . Het voordeel en daarmee de best practice is, dat je bijvoorbeeld een Port Group kan maken voor je vMotion netwerk en een andere voor je management, met beide een eigen NIC en een failover naar de andere NIC. Is weer net iets redudanter dan volledig active / standby.

Verder heb je geen managed switches nodig voor de loadbalancing van je verbindingen afhankelijk van welke policy je selecteert. Er zijn er die wel switch intelligentie nodig hebben (op IP hash bijv.) maar er zijn er ook die dit niet hebben.

Ik dacht te lezen dat het ISCSI was (online op type nummer) maar daar heb ik me in vergist. Alle opmerkingen romdom ISCSI kan je dus negeren.

Elke host heeft op dit moment zelfs al 2 kernelports, je management netwerk (en IP interface) is ook gebaseerd op een VMKernel Port en daarnaast hebben ze er nog een. Daarom vraag ik me af waar de tweede VMkernel port voor is, bijv op IP 10.10.0.221, kan je van de proporties daarvan eens een screenshotje schieten?

[squaddie]

Phuncz schreef op maandag 12 augustus 2013 @ 21:05:
Bedankt voor de vlotte en uitgebreide antwoorden, GoT laat zich weer van zijn beste kant zien !


[...]

De reden dat ik standby adapters wil gebruiken is omdat we vermoedelijk allemaal unmanaged switches hebben, dus geen NIC teaming of Link Aggregation. Om te vermijden dat ik straks loops maak en heel de infrastructuur eruit flikker

Om het in perspectief te te zetten als je een netwerkkaart als weg met een enkele rijstrook ziet dan ga je bij NIC teaming die meerdere wegen samenvoegen tot een weg met meerdere rijstroken en dit vereist dat zowel server als switch dit ondersteunt en hierbij een fout maken dan heb je een probleem met je netwerkverbinding.

ESXi doet dit niet die laat het losse wegen zijn en verdeelt het verkeer over de losse wegen en dit gaat heel kort door de bocht genomen bij twee actieve NICs als VM1 gaat over NIC1, VM2 gaat over NIC2, VM3 gaat over NIC1, enzovoort. Indien een weg uitvalt wordt het verkeer omgeleid over een andere weg. Het voordeel het vereist geen setup of managed switches, nadeel is dat de maximale netwerksnelheid voor een VM beperkt is tot de maximum snelheid van de fysieke NIC en het is absoluut niet een geavanceerde loadbalancing zoals NIC teaming.

ESXi slim genoeg om te voorkomen dat er een loop ontstaat als je meerdere NICs actief maakt.

Aha duidelijk. Hier had ik me al eens op gestort maar het was niet volledig duidelijk maar nu dus wel. Het is idd een FC SAN: http://www8.hp.com/us/en/...oid=4118559#!tab=features

Nu ik echter de gegevens bekijk, lijkt het me dat we een dual-controller P2000 G3 hebben. Dit is een foto die ik geschoten heb recent:

[afbeelding]

Hieruit kun je ook opmaken dat ze gekozen hebben om de twee FC-links naar dezelfde host kaart te sturen. Hadden ze niet beter deze gesplitst over de twee host controllers ?
Zou ik hierdoor niet al aan de minimum eis kunnen voldoen voor de twee datastores of moeten het effectief twee verschillende RAID arrays zijn ?

Volgens mij is dat geen fiber, maar SAS. En heb je het feitelijk niet meer over een SAN of NAS maar een DAS.

Puur afgaande op de foto zitten in de hosts inderdaad beide links op dezelfde controller aangesloten, terwijl zo te zien er rechts nog een SAS controller zit. Uit oogpunt van redundancy zou je verwachten dat per controller een kabel aangesloten wordt.

Wil je geen spof hebben dan zal je een tweede DAS moeten aanschaffen. Als het moederbord in de DAS nu kortsluit dan gaan eventuele meerdere raidsets en/of datastores nog steeds even hard plat. Meerdere raidsets kan er wel voor zorgen dat een uitval van meerdere schijven tegelijkertijd ervoor zorgt dat alles of een deel nog in de lucht is ipv de hele omgeving plat.

Wij hebben ook klanten die bewust kiezen voor een enkele SAN omdat de kosten voor een tweede te hoog zijn voor de klant, deze kiezen dan wel vaak voor een 24/7 supportcontract met bv 4 responstijd voor een looptijd van 3 tot 5 jaar. Zodat in het geval dat het apparaat een storing heeft er snel een monteur met onderdelen ter plaatse is.

[ Voor 39% gewijzigd door squaddie op 12-08-2013 22:31 ]

[Phuncz]

tomverhaeg schreef op maandag 12 augustus 2013 @ 21:51:
Port Groups kan je ook zeker gebruiken met vSS (vSphere standard switches), sterker nog, je hebt er al in gebruik, en eentje heet er bijvoorbeeld VM network. . Het voordeel en daarmee de best practice is, dat je bijvoorbeeld een Port Group kan maken voor je vMotion netwerk en een andere voor je management, met beide een eigen NIC en een failover naar de andere NIC. Is weer net iets redudanter dan volledig active / standby.

OK dan ga ik port groups zeker eens bekijken. Het hele HA hoofdstuk en de technische werking van vSphere is toch nog nieuw voor me maar ik probeer bij te blijven.

Daarom vraag ik me af waar de tweede VMkernel port voor is, bijv op IP 10.10.0.221, kan je van de proporties daarvan eens een screenshotje schieten?

Dat zal ik doen. Het zou toch nog kunnen dat het ineens iSCSI is maar dat zou me sterk verwonderen aangezien ik enkel HBA verwijzingen heb gezien bij de storage.

squaddie schreef op maandag 12 augustus 2013 @ 21:53:
ESXi doet dit niet die laat het losse wegen zijn en verdeelt het verkeer over de losse wegen en dit gaat heel kort door de bocht genomen bij twee actieve NICs als VM1 gaat over NIC1, VM2 gaat over NIC2, VM3 gaat over NIC1, enzovoort. Indien een weg uitvalt wordt het verkeer omgeleid over een andere weg. Het voordeel het vereist geen setup of managed switches, nadeel is dat de maximale netwerksnelheid voor een VM beperkt is tot de maximum snelheid van de fysieke NIC en het is absoluut niet een geavanceerde loadbalancing zoals NIC teaming.

ESXi slim genoeg om te voorkomen dat er een loop ontstaat als je meerdere NICs actief maakt.

Did not know that, dat is wel zeer leuk voor de noobs zoals mij. Ik vond het al raar dat het systeem niet tilt sloeg door de meerdere lijnen lopend naar dezelfde switch.

[tomtom901]

Als je wat meer wilt weten over HA en de technische werking zou je eens een boek kunnen kopen die over de VCP5 certificering gaat. Los van of je de certificering wilt en gaat doen staan er wel een aantal zaken goed en duidelijk in uitgelegd die je uiteindelijk een betere beheerder van (deze) VMware omgeving(en) maakt.

[pablo_p]

Over de loops: het loop prevention systeem vna ESX is heel simpel: verkeer dat een vSwitch binnenkomt over een fysieke interface, wordt nooit over een fysieke interface naar buiten gestuurd. Wat er wel kan gebeuren, is dat een MAC adres van een server over verschillende interfaces naar buiten wordt gestuurd, waar switches niet van houden (melding Cisco: flapping MAC address, als je daar op Googlet krijg je wel wat hits). Dit gebeurt als teaming niet gelijk ingesteld is aan beide kanten van multiple links tussen devices.

Het is wel mogelijk om loops te creeren met ESX, maar dan moet je het volgende bouwen (voorbeeld zonder gebruik van vlans)
switch <-> vswitch <-> virtual host die interfaces bridged <vswitch> switch

[Phuncz]

tomverhaeg schreef op dinsdag 13 augustus 2013 @ 08:31:
Als je wat meer wilt weten over HA en de technische werking zou je eens een boek kunnen kopen die over de VCP5 certificering gaat. Los van of je de certificering wilt en gaat doen staan er wel een aantal zaken goed en duidelijk in uitgelegd die je uiteindelijk een betere beheerder van (deze) VMware omgeving(en) maakt.

Hier ga ik best eens voor kijken ja, aangezien ik nu waarschijnlijk toch een testomgeving uit de mouw kan schudden.
Enig advies welke boeken goed zijn (Engels heeft mijn voorkeur), zijn altijd welkom ! Liefst een zo duidelijk mogelijke uitleg van de concepten lijken me belangrijk voor mij.

tomverhaeg schreef op maandag 12 augustus 2013 @ 21:51:
Daarom vraag ik me af waar de tweede VMkernel port voor is, bijv op IP 10.10.0.221, kan je van de proporties daarvan eens een screenshotje schieten?

.201 host:




.202 host:




Dit legt waarschijnlijk ook het management redundancy issue uit ? Want op de .201 host staat de link down voor default configuration.

[ Voor 6% gewijzigd door Phuncz op 13-08-2013 10:49 ]

[squaddie]

Phuncz schreef op dinsdag 13 augustus 2013 @ 09:35:
[...]

Hier ga ik best eens voor kijken ja, aangezien ik nu waarschijnlijk toch een testomgeving uit de mouw kan schudden.
Enig advies welke boeken goed zijn (Engels heeft mijn voorkeur), zijn altijd welkom ! Liefst een zo duidelijk mogelijke uitleg van de concepten lijken me belangrijk voor mij.

Er zijn maar weinig boeken over dergelijke onderwerpen in het nederlands. Mastering VMware van Scott Lowe is in mijn opinie wel een aanrader. Wil je vervolgens HA tot op de kleinste detail weten dan is VMware vSphere 5.1 Clustering Deepdive van Duncan Epping en Frank Denneman een aanrader.

[...]

.201 host:
[afbeelding]

[afbeelding]

.202 host:
[afbeelding]

[afbeelding]

Dit legt waarschijnlijk ook het management redundancy issue uit ? Want op de .201 host staat de link down voor default configuration.

Welke services zijn aangevinkt op general tabblad van de vmkernel?

[tomtom901]

Ik bedoelde inderdaad de general tab ja. . Ik ben erg tevreden over http://www.pearsonitcerti...ation-guide-9780789749314, met deze heb ik ook mijn VCP5 behaald via zelfstudie. Het geeft je een duidelijk inzicht in hoe de basis werkt met duidelijke voorbeelden en labs.

[Phuncz]

squaddie schreef op dinsdag 13 augustus 2013 @ 12:01:
Welke services zijn aangevinkt op general tabblad van de vmkernel?

Bij beide enkel vMotion.

Bedankt voor de cursustips, ga ik zeker bekijken !

[Ethirty]

Ik heb met vergelijkbare hardware al enkele clusters gebouwd en er onze eigen hosting dienst mee opgezet, dus ik hoop dat mijn verhaal duidelijk is voor iemand die er nog niet zoveel ervaring mee heeft.

Je hebt de P2000 G3 SAS versie, dat is 6Gbit shared SAS storage (net als iSCSI of FC een "echt" SAN) en deze werkt alleen icm HBA's in je server. Het is absoluut geen DAS oplossing! Dat is een snel genoeg apparaat voor de opstelling die je hebt (mits de disks in je SAN goed geschaald zijn). Wel is het raar dat ze beide aansluitingen op 1 HBA hebben gezet. Idealiter wil je vanaf elke HBA 1 kabel naar de P2000 controller hebben lopen; HBA1 naar controller 1 en HBA2 naar controller 2. De blauwe lipjes geven aan dat dit cold-swap is, dus je moet eigenlijk alles uitzetten om te wisselen. In mijn ervaring werkt het ook wel als je de kabel wisselt terwijl alles draait, MITS de instellingen in ESXi mbt de connectie naar de datastores niet afwijkend is ingesteld (dat kan lastig zijn gezien je voorganger(s)).

Qua netwerk is het lastig dat je met een unmanaged switch te maken hebt. De 4 netwerk poorten zijn verdeeld over 2 aparte chips (poort 1+2 en poort 3+4), dus ideaal is om poort 1 en 3 op switch 1 te hebben en poort 2 en 4 op switch 2. Zo vang je qua connectie elke storing op die je kan hebben.

Normaal zou je bijvoorbeeld vMotion verkeer via een apart subnet/VLAN laten lopen. Hier maak je dan een aparte poortgroep voor aan. Aangezien het een kleine omgeving is, is dit ook niet echt nodig. Wat je zou kunnen overwegen (onder voorbehoud van een netwerk loop door je unmanaged switch):
- haal NIC's 2 en 4 uit de configuratie van vSwitch0
- maak een nieuwe vSwitch aan en wijs poorten 2 en 4 toe.
- definieer op deze vSwitch een VM poort groep (doe dit op beide hosts, en maak de naam identiek, anders gaat het mis bij een HA of vMotion actie
- pas de netwerk instellingen per VM aan om de nieuw aangemaakt poortgroep te gebruiken
Dit zorgt ervoor dat management van je cluster en je productie netwerk binnen ESXi volledig van elkaar gescheiden zijn.

- op vSwitch0 heb je nu alleen actief de management poort (hier kan vMotion uit) en de VMkernel poort voor vMotion (je kan hier evt een aparte IP reeks voor gebruiken, hoeft niet eens in een VLAN te zitten)
- je kan nu in de instellingen per poort aangeven welke fysieke NIC je gebruikt. Stel voor management 1 als actief en 3 als standby. Voor vMotion doe je het omgekeerd: 3 actief en 1 als standby.

Zo maak je optimaal gebruik van de capaciteit van alle 4 de NIC's en mocht er wat uitvallen, dan is er altijd een tweede NIC die de taken kan overnemen.

Dat VMware klaagt over een enkele datastore heeft te maken met het HA mechanisme. Met 1 datastore kan host isolation niet betrouwbaar bepaald worden, aangezien er geen meerderheids stem behaald kan worden. Ik denk dat je dit artikel heb gevolgd? Die tweede datastore hoeft niet per se een ander SAN te zijn, je kan ook een tweede datastore in je P2000 aanmaken door het bijplaatsen van wat disks. Zo verdeel je je servers over 2 arrays en verlies je maar de helft van je servers als er iets mis gaat bij je array (bijv 2 schijven defect in je Raid5).

Ik zou eens kijken naar de KMO versie van Veeam icm een NAS, dan kan je dagelijks een volledige kopie van al je machines naar goedkope storage maken voor nood (hiervan runnen kan wel als je een replica ipv een backup maakt, maar is waarschijnlijk onwerkbaar traag).

Kijk ook eens op de blog van Yellow Bricks. Een Nederlandse engineer bij VMware die een aantal concepten van VMware (oa zijn HA deepdive) best goed uitlegd.

[Phuncz]

Bedankt voor de uitleg, zeker handige informatie ivm. de SAN-unit en de data-store. Onze SAN is ongeveer voor de helft gevuld in een RAID-6 configuratie met een global spare, dus er is ruimte om hier een tweede RAID-6 aan toe te voegen. Of er budget daarvoor is, dat weet ik niet maar ze waren al blij om te horen dat ze niet nóg een storage-system moesten aanschaffen.

Een backup oplossing hebben we momenteel lopen op een aparte server met gebruik van Symantec Backup Exec, maar ik ben eerlijk gezegd niet op de hoogte of deze ook de ESXi datastore ook doet.

Yellow Bricks ben ik al een paar keren tegengekomen en ik heb zijn HA deepdive inleiding al doorgenomen, om te concluderen dat mijn basiskennis niet voldoende was...

[Jeroen_ae92]

Welke disken gaan erin? Ik heb wellicht nog wel iets wat je gelukkiger kan maken... Let wel, morgen gaat het naar de schroot.

edit: http://www8.hp.com/nl/nl/...ml?oid=4118559#!tab=specs
Gevonden dus.

[ Voor 31% gewijzigd door Jeroen_ae92 op 13-08-2013 20:18 ]

[squaddie]

Ethirty schreef op dinsdag 13 augustus 2013 @ 18:17:
Je hebt de P2000 G3 SAS versie, dat is 6Gbit shared SAS storage (net als iSCSI of FC een "echt" SAN) en deze werkt alleen icm HBA's in je server. Het is absoluut geen DAS oplossing! Dat is een snel genoeg apparaat voor de opstelling die je hebt (mits de disks in je SAN goed geschaald zijn). Wel is het raar dat ze beide aansluitingen op 1 HBA hebben gezet. Idealiter wil je vanaf elke HBA 1 kabel naar de P2000 controller hebben lopen; HBA1 naar controller 1 en HBA2 naar controller 2. De blauwe lipjes geven aan dat dit cold-swap is, dus je moet eigenlijk alles uitzetten om te wisselen. In mijn ervaring werkt het ook wel als je de kabel wisselt terwijl alles draait, MITS de instellingen in ESXi mbt de connectie naar de datastores niet afwijkend is ingesteld (dat kan lastig zijn gezien je voorganger(s)).

Sorry, maar het is een DAS, om een apparaat te definieren als SAN of NAS zal het apparaat met zijn omgeving moeten communiceren via een netwerkprotocol zoals TCP bij ethernet en FCP bij Fibre Channel. SAS is geen netwerkprotocol en is het apparaat daarmee geclassificeerd als DAS. De term DAS of SAN zegt uitsluitend iets over hoe het apparaat met zijn omgeving communiceert, maar niets over opslagcapaciteit, prestatie, etc.

Phuncz schreef op dinsdag 13 augustus 2013 @ 18:45:
Een backup oplossing hebben we momenteel lopen op een aparte server met gebruik van Symantec Backup Exec, maar ik ben eerlijk gezegd niet op de hoogte of deze ook de ESXi datastore ook doet.

De datastore zelf is niet belangrijk, alleen de VMs op de datastore zijn belangrijk.

Backup Exec kent de mogelijkheid VMs te backuppen als hiervoor licenties zijn aangeschaft, echter deze zijn redelijk prijzig was mijn ervaring. Wat voor de hand ligt is dat Backup Exec dmv een agent op het OS binnen de VM backups maakt en totaal niet bewust is van de virtualisatie. Backup software zoals Veeam is ontworpen voor backups in gevirtualiseerde omgevingen en gaat backuppen op VM niveau niet op OS niveau zoals Backup Exec dit in het algemeen doet.

Het grote verschil komt bij het terugzetten van een server, bij Veeam geef je aan deze server terugzetten en Veeam maakt een VM aan met dezelfde instellingen als het origineel, zet vervolgens de virtuele schijven terug en als Veeam klaar is dan kan je VM inschakelen en weer werken.

Bij Backup Exec moet je zelf een nieuwe VM aanmaken met de juiste instellingen, vervolgens zet je deze aan en ga je bijvoorbeeld een rescue CD booten om de Backup Exec agent te starten zodat Backup Exec via de agent de data kan terugzetten.

[Ethirty]

squaddie schreef op dinsdag 13 augustus 2013 @ 20:32:
[...]

Sorry, maar het is een DAS, om een apparaat te definieren als SAN of NAS zal het apparaat met zijn omgeving moeten communiceren via een netwerkprotocol zoals TCP bij ethernet en FCP bij Fibre Channel. SAS is geen netwerkprotocol en is het apparaat daarmee geclassificeerd als DAS. De term DAS of SAN zegt uitsluitend iets over hoe het apparaat met zijn omgeving communiceert, maar niets over opslagcapaciteit, prestatie, etc.

Met een DAS box (bijvoorbeeld een D2700) is storage maar voor 1 host beschikbaar. Shared SAS komt niet veel voor, maar is wel degelijk meer SAN dan DAS. Er zijn ook SAS switches om nog meer hosts te kunnen aansluiten. En het medium zegt niks over het protocol. Je hebt ook FCoE, dat wordt niet ineens iSCSI omdat het over koper gaat.

[Equator]

offtopic:
Maar shared storage boxen(of het nu via ouderwets SCSI of SAS gaat), zijn geen SAN. SAN impliceert het gebruik van FC (FCoE of over glas) of iSCSI waarmee een LUn gekoppeld wordt.
Een NAS impliceert een netwerk file protocol als NFS/CIFS waarover een volume te bereiken is.

Dit staat overigens LOS van het feit dat je in een SAN opstelling met bijvoorbeeld een NetApp SAS bridges tegenkomt waarmee het FC stuk wordt gekoppeld aan disken die via SAS aangesproken worden.

[ Voor 25% gewijzigd door Equator op 14-08-2013 07:57 ]

[Ethirty]

offtopic:
Als je met 4 C7000 chassis en 8 SAS switches in theorie tot 64 hosts redundant kan aansluiten op een P2000, hoe valt dat dan buiten de categorie SAN? Je hebt alles (veel) wat je in een FC netwerk ook ziet: HBA, kabels, switches en een storagedoos met eigen controllers, WWN's en zoning.

[Phuncz]

Om terug over het P2000 G3 bekabeling gebeuren te praten, ik vind zeer weinig terug over "SAS duplexing" in de situatie met ESXi en de P2000 G3. Dus beide controllers op de P2000 verbinden met de twee HBA's per server om zo ook de HBA's redundant te maken.

Het enige wat ik hierover terugvind is dit topic: http://h30499.www3.hp.com...00-supported/td-p/5504113

Zou een oplossing zijn om nog een set SAS kabels aan te schaffen en de overige 4 poorten op beide controllers aan te sluiten op de andere HBA of ga ik hiermee problemen veroorzaken ? Ik vind dit niet meteen terug in de documentatie van de P2000, hier gaat men altijd uit van een enkele HBA per server.

[Ethirty]

Het levert je niks op. De controllers van een P2000 zijn zo dat altijd 1 controller owner is van een array. De andere controller is dan standby voor die array. Het systeem balanceert automatisch het aantal arrays over de controllers.

Je hebt dus in feite te maken met maximaal 1 actieve connectie gezien vanuit VMware. Je zou round-robin op de controllers kunnen instellen, maar dan sluist de passieve controller alle data intern in de P2000 door naar de owner die dan vervolgens de disks aanspreekt. Niet aan te raden dus.

Met de opstelling van 2 kabels in 1 HBA dek je je in tegen controller falen van de P2000, als je 1 kabel verhuist naar de andere HBA dek je het falen daarvan ook af. De docu van de P2000 zegt er misschien weinig over, maar ik kan je garanderen dat het werkt. Een groot aantal klanten is inmiddels afhankelijk van die constructie die ik gebouwd heb Het levert je in geen geval meer performance.

[Phuncz]

OK dat is duidelijk, dan zet ik dat alweer in de todo

Moet ik ergens mee rekening houden binnen beide ESXi hosts hun configuration als ik de huidige dual-port opstelling naar two single-port opstelling omzet, of is het beest slim genoeg om de nieuwe paths zelf te herkennen ? Beide controllers staan geinstalleerd trouwens:

[ Voor 91% gewijzigd door Phuncz op 14-08-2013 12:33 ]

[Ethirty]

Je kan in VMware naar de properties van de LUN kijken wat de instellingen daarvan zijn (failover, round-robin, etc). Misschien dat daar aan gesleuteld is.

Aangezien je maar 1 array hebt is het het veiligst om de kabels van controller B (onderste) om te prikken naar de tweede HBA. Als je op safe wil spelen zet je alles eerst uit, ik durf geen garanties aan je te geven over het live omprikken, al heb ik dat zelf al wel eens gedaan zonder problemen (enige manier om het echt goed te testen )

Als je firmware van je P2000 recent is (240 of hoger geloof ik) heb je ook de beschikking over VMware VAAI (mits je vSphere licentie dat toestaat). Dan kan VMware bepaalde zaken offloaden aan de controller ipv ze zelf te doen, maar bijvoorbeeld ook zelf de performance van de array in de gaten houden.

[Phuncz]

VAAI zit pas in de Enterprise licentie, wij hebben een Essentials Plus vrees ik

Sowieso was ik van plan de boel om te steken als het powered-down is, wil geen onnodige risico's nemen.

[Ethirty]

Check nog even de settings voor je LUN:



Het omprikken hoef je verder niks voor aan te passen in VMware. Je zal zien dat je LUN 0 (de controller), die nu 2x onder je HBA staat, gesplitst wordt zodat je die per HBA 1x ziet.

Het zou wel kunnen zijn dat in de P2000 de mappings naar de HBA nog niet ingesteld staan, zodat de tweede HBA geen toegang heeft tot de LUN's (uit mijn hoofd: hosts - configure mappings)

[Phuncz]

Ethirty schreef op woensdag 14 augustus 2013 @ 12:56:
Check nog even de settings voor je LUN:

.201 host


.202 host

Ethirty schreef op woensdag 14 augustus 2013 @ 12:56:
Het zou wel kunnen zijn dat in de P2000 de mappings naar de HBA nog niet ingesteld staan, zodat de tweede HBA geen toegang heeft tot de LUN's (uit mijn hoofd: hosts - configure mappings)

Daar zal ik maar vanuit gaan

[Phuncz]

Ethirty schreef op dinsdag 13 augustus 2013 @ 18:17:
Dat VMware klaagt over een enkele datastore heeft te maken met het HA mechanisme. Met 1 datastore kan host isolation niet betrouwbaar bepaald worden, aangezien er geen meerderheids stem behaald kan worden. Ik denk dat je dit artikel heb gevolgd? Die tweede datastore hoeft niet per se een ander SAN te zijn, je kan ook een tweede datastore in je P2000 aanmaken door het bijplaatsen van wat disks. Zo verdeel je je servers over 2 arrays en verlies je maar de helft van je servers als er iets mis gaat bij je array (bijv 2 schijven defect in je Raid5).

Hier wou ik het nog eens over hebben. Inderdaad, ik heb die setting toegepast voorlopig.

Aangezien tussen de aanschaf van de hardware toen en nu er het één en ander is veranderd, wil ik het bestuur alvast warm maken (het zal voor later zijn, laatste prioriteit blijkbaar) voor een aantal SSHD's om de redundancy te upgraden, een zestal van de nieuwe Seagate Turbo SSHD's in RAID 6, daarmee zouden we vergelijkbare of betere prestaties moeten halen dan met de huidige 12-disk RAID 6 bestaande uit deze: pricewatch: HP 507127-B21, 300GB

En het laat ook toe later nog uit te breiden. Dan moet ik wel nog 6 trays hebben maar dat is een fractie van de kosten. De capaciteit zal echter nodig zijn, aangezien we nu al ongeveer 2TB in gebruik hebben van die array.

Maar zou het veel verschil maken om hier een tweede enterprise-grade datastore voor in te richten of zou het ook een oplossing zijn door een bende consumer-grade SSHD's te plaatsen ? Zoals vier van deze pricewatch: Seagate Momentus STBD1000400, 1TB in een RAID 10, als het toch enkel maar zal dienen in de extreme uitzondering dat het nodig zal zijn om van datastore te moeten wisselen (onderhoud most likely).

[ Voor 13% gewijzigd door Phuncz op 16-08-2013 10:20 ]

[bigfoot1942]

pfff, ik denk dat je harder van stapel loopt dan je management beoogd (en je voorganger deed).
Ik ken de P2000 niet, maar voor je m volgooit met SSD's: RAID6 is niet het snelste RAIDlevel als het om schrijven gaat. Ergo, je gaat de bottleneck (raidcontroller) flink belasten want de disks krijgen het wel weggeschreven. Vraag is wat er gaat gebeuren...

Verder, consumentenHD's in het bedrijfsleven is not done, hooguit voor testomgevingen e.d. (non mission critical data). Ook weet ik niet hoe HP omgaat met niet HP-branded harddisks...

Ten laatste, voor je unsupported configs begint te bouwen, kijk eens of er een supportcontract op t apparaat zit welke je hiermee ongeldig maakt... En als je voor een geldige setup gaat, moet je je supportcontract aanpassen? Is het misschien voordeliger een nieuwe unit te kopen?

Maar vanuit VMWare is een extra partitie van 5GB ofzo al voldoende voor datastore heartbeating, dus waarom denk je extra harddisks nodig te hebben voor redundancy?

[Phuncz]

bigfoot1942 schreef op vrijdag 16 augustus 2013 @ 10:39:
pfff, ik denk dat je harder van stapel loopt dan je management beoogd (en je voorganger deed).

Dat is ook, maar ik wil een betrouwbare setup neerzetten, uiteindelijk is dit mijn verantwoordelijkheid. Je kent het wel: het bestuur is verantwoordelijk voor alles, behalve als de boel in de fik staat. Dan kijken ze ineens naar de sys-admin om schuld te plaatsen.

Ik ken de P2000 niet, maar voor je m volgooit met SSD's: RAID6 is niet het snelste RAIDlevel als het om schrijven gaat.

4 of 6 disks met SSD cache zou ik toch wel anders classeren als een de P2000 "volgooien" met SSD's? Het zullen voornamelijk leesoperaties zijn aangezien het over licht officegebruik gaat.

Verder, consumentenHD's in het bedrijfsleven is not done, hooguit voor testomgevingen e.d. (non mission critical data). Ook weet ik niet hoe HP omgaat met niet HP-branded harddisks...

Ten laatste, voor je unsupported configs begint te bouwen, kijk eens of er een supportcontract op t apparaat zit welke je hiermee ongeldig maakt... En als je voor een geldige setup gaat, moet je je supportcontract aanpassen?

Hier heb je een goed punt, dit moet ik zeker navragen.

Is het misschien voordeliger een nieuwe unit te kopen?

Bedoel je een tweede P2000 G3 van om en bij de 15.000€ ? Dat krijg ik ze niet uitgelegd

Maar vanuit VMWare is een extra partitie van 5GB ofzo al voldoende voor datastore heartbeating, dus waarom denk je extra harddisks nodig te hebben voor redundancy?

Aha, ik dacht dat dit een mirror moest zijn van de andere datastore. Maar dan ik ook eigenlijk gewoon een simpele NAS met NFS gebruiken als het toch maar dient voor heartbeat ?

[Ethirty]

Phuncz schreef op vrijdag 16 augustus 2013 @ 10:10:
Aangezien tussen de aanschaf van de hardware toen en nu er het één en ander is veranderd, wil ik het bestuur alvast warm maken (het zal voor later zijn, laatste prioriteit blijkbaar) voor een aantal SSHD's om de redundancy te upgraden, een zestal van de nieuwe Seagate Turbo SSHD's in RAID 6, daarmee zouden we vergelijkbare of betere prestaties moeten halen dan met de huidige 12-disk RAID 6 bestaande uit deze: pricewatch: HP 507127-B21, 300GB

Ik kan kort zijn: not supported.

Kan je de R6-array niet splitsen in 2x R5? Is wel een hoop werk (alles offline verplaatsen), maar levert je een boost in performance op, omdat je beide controllers en de cache volledig kan benutten.

[Phuncz]

In theorie is het mogelijk maar dat vereist wel wat gezeul met de data aangezien we van de 2.18TB beschikbaar zo'n 2TB in gebruik hebben. Het probleem is dat de P2000 voor mij onbekend territorium is en op dat moment ben ik bezig met data van meer dan 200 medewerkers, waar ik me niet helemaal comfortabel mee voel. Zeker omdat ik de backupvoorziening nog niet volledig heb verkend en deze blijkbaar nog nooit getest is geweest (yay).

Spannende tijden voor een junior

[Verwijderd]

Phuncz schreef op vrijdag 16 augustus 2013 @ 11:40:
In theorie is het mogelijk maar dat vereist wel wat gezeul met de data aangezien we van de 2.18TB beschikbaar zo'n 2TB in gebruik hebben. Het probleem is dat de P2000 voor mij onbekend territorium is en op dat moment ben ik bezig met data van meer dan 200 medewerkers, waar ik me niet helemaal comfortabel mee voel. Zeker omdat ik de backupvoorziening nog niet volledig heb verkend en deze blijkbaar nog nooit getest is geweest (yay).

Spannende tijden voor een junior

Lijkt mij dat je dan nu even je prioriteit gaat leggen bij het uitpluizen en testen van je backup i.p.v. het optimaliseren van je VMware cluster.

Uitval van je VMware omgeving kan, desnoods met hulp van een externe specialist, snel verholpen worden. Verlies van je data betekent in meer dan 50% van de gevallen (even uit mijn hoofd) een faillissement binnen 2 jaar.

[bigfoot1942]

Phuncz schreef op vrijdag 16 augustus 2013 @ 11:10:

Bedoel je een tweede P2000 G3 van om en bij de 15.000€ ? Dat krijg ik ze niet uitgelegd


[...]

Aha, ik dacht dat dit een mirror moest zijn van de andere datastore. Maar dan ik ook eigenlijk gewoon een simpele NAS met NFS gebruiken als het toch maar dient voor heartbeat ?

...of inderdaad een extra volume op dezelfde omgeving...

Verder, gratis tip: lees je meer in voordat je dingen gaat roepen en aanpassen.
Ik zou haast inschatten dat je te weinig ervaring hebt om 'even' de omgeving op orde te brengen.

Als je alles 'gefixt' hebt, en er gebeurt dan iets, is het jouw schuld. (ook als het misgaat tijdens je aanpassingen)
Als je aangeeft dat je tegen een bak erfenis / lijken in de kast aanloopt en stap voor stap de omgeving wil verbeteren, zal men veel meer begrip hebben en slaat een issue veel meer terug op de vorige beheerder dan op jou...

Ik zou inderdaad veel meer focussen op goede backup (daarmee kan je in een situatie als deze makkelijk 'de held' worden) en evt een extra 1GB switch zodat je die ook redundant krijgt.

Je netwerking plaatje zoals je gepost hebt is helemaal niks mis mee.

Een P2000 met redundante controllers is in theorie redundant (passive backplane e.d.), het enige waarvoor ESX aangeeft een extra datastore nodig te hebben is de eerdergenoemde heartbeating. Deze moet redundant primair vanwege evt volume-corruptie...
Een extra schijven in die P2000 geeft uiteraard geen enkele extra redundancy, zelfs al zou je datastores mirroren (dezelfde SPOF nl de backplane).

Zover ik weet bestaat er geen standaard mogelijkheid dat vsphere datastores mirrored...

[Ethirty]

Ik sluit me aan bij bovenstaande opmerkingen. Je gaat niet gokken met 2TB aan bedrijfsdata.

Inventariseer, maak een stappenplan en werk je door alle zaken heen. Te beginnen met een goed backup protocol. Onder normale omstandigheden gaat zulke apparatuur je echt niet zo snel in de steek laten. Verbeteren kan beter in kleine stapjes dan aan alles willen sleutelen waar je nog geen verstand van heb. De kennis komt met de tijd wel.

[Dennism]

Ik krijg een beetje het idee dat TS zo even in een nieuwe ongedocumenteerde omgeving is gerold.

Ik sluit me dan ook aan bij bovenstaande posters, zorg dat je er zeker van bent dat je backup werkt.

Ga daarna eens de omgeving goed in kaart brengen en documenteer dit, neem daarin ook de volgende punten op

1. Wat zijn de sterke punten (o.a. Zaken die al in HA draaien, zaken welke goed geschaald zijn naar de benodigde capaciteit.)
2. Wat zijn de zwakke punten (Spofs) en welke downtime kan een spof veroorzaken bij een calamiteit.
3. Breng alle garantie statussen/service contracten van alle hardware goed in kaart en de concequenties daarvan (ik heb wel eens een service case gehad met een defect aan een HP san die uit garantie was en geen carepack had waar bijna een week gewacht moest worden op een vervangend onderdeel omdat deze bij HP niet voorradig was voor niet contract klanten en dus besteld moest worden).

Ga hierna met de directie/direct leidinggevende om tafel om te bespreken hoe de huidige omgeving er voor staat, en welke eisen de directie stelt qua maximale downtime, impact van calamiteiten e.d.

Stel daarna een document op met verschillende scenario's qua downtime, calamiteiten die voor kunnen komen, capaciteits management e.d. en de bijbehorende investeringen die nodig zijn om de omgeving op het gewenste niveau te krijgen aan de hand van de eerder door het management gestelde eisen en wensen.

Ga daarna wederom zitten met directie/direct leidingevende om de verschillende scenario's en bijbehorende kosten / inzet van personeel e.d. te bespreken. Laat de directie ook duidelijk (schriftelijk, e-mail) bevestigen welke keuze ze maken om jezelf in te dekken. Wil de directie niet investeren en komt er downtime vanwege een spof heb je iig documentatie om aan te tonen dat de directie op de hoogte was van de risico's en zelf heeft gekozen geen actie te ondernemen.

Ga hierna pas verder sleutelen aan de omgeving om de omgeving in lijn te brengen met de keuze die eerder door de directie is gemaakt.

De wensen van de sysadmin en de wensen van de directie kunnen door verschillende kosten en baten analyses nog wel eens uit een lopen. Maar het is altijd belangrijk dat je als Sysadmin kan aantonen dat problemen bij een calamiteit niet voorvloeien uit door de sysadmin persoonlijk gemaakte keuzes, maar dat dit komt door keuzes welke door het management zijn vastgesteld.

[SpamLame]

Mcl.de heeft relatief goedkope msa's staan. Bv.
http://mcl.de/Storage-MCL...0GB-15k-LFF-Dual-SAS.html

[CAPSLOCK2000]

2TB data is nog goed te overzien Regel een eenvoudige 2TB consumenten schijf en kijk of je herstelprocedure werkt. Zo niet dan maak je een volledige backup naar die 2TB schijf en kun je met een gerust hart verder werken. Het is natuurlijk geen alternatief voor een professionele backup-oplossing maar je kan het binnen 24 uur geregeld hebben zonder risico's te nemen.

[Phuncz]

Dennism schreef op zaterdag 17 augustus 2013 @ 08:29:
Ik krijg een beetje het idee dat TS zo even in een nieuwe ongedocumenteerde omgeving is gerold.

Het is een beetje gedocumenteerd maar nauwelijks geoptimaliseerd en niet uitgerold op redundancy. Het is eigenlijk niet serieus genomen.

Ga daarna eens de omgeving goed in kaart brengen en documenteer dit, neem daarin ook de volgende punten op...

Goed advies, hier ga ik zeker gebruik van maken.

Het probleem is dat ik pas uit mijn opleiding kom en ik nog geen ervaring heb op sommige gebieden, zoals backups testen. Met vSphere en Windows Server heb ik dan wel weer ervaring, dus wou ik de kans op problemen zoveel mogelijk beperken zodat ik in de tussentijd andere kennis en ervaring kan opdoen dmv. de testomgeving die ik momenteel ineenknutsel. Ik kan ook niet zeggen: "hey lui, ik kan niet hetgeen een ervaren sys-admin kan, dus ik ga eerst nog een half jaar moeten bijleren voordat ik me nuttig kan maken." Ik ben al de persoon met de meeste IT-kennis daar dus het rust allemaal op mij.

[CAPSLOCK2000]

Verstandig. Rustig aan doen en niet teveel tegelijk willen. Toch wil ik je adviseren om te beginnen met backups. Waar gehakt wordt vallen spaanders. Als je zelf geen fouten maakt dan vliegt je apparatuur wel in brand. Als de boel uitvalt zal het je de kop niet kosten. Je baas snapt ook wel dat dingen sneuvelen. De echte vraag is hoe lang het duurt voor je de schade weer hebt hersteld.

[bigfoot1942]

Phuncz schreef op zaterdag 17 augustus 2013 @ 13:06:
[...]

Het is een beetje gedocumenteerd maar nauwelijks geoptimaliseerd en niet uitgerold op redundancy. Het is eigenlijk niet serieus genomen.


[...]

Goed advies, hier ga ik zeker gebruik van maken.

Het probleem is dat ik pas uit mijn opleiding kom en ik nog geen ervaring heb op sommige gebieden, zoals backups testen. Met vSphere en Windows Server heb ik dan wel weer ervaring, dus wou ik de kans op problemen zoveel mogelijk beperken zodat ik in de tussentijd andere kennis en ervaring kan opdoen dmv. de testomgeving die ik momenteel ineenknutsel. Ik kan ook niet zeggen: "hey lui, ik kan niet hetgeen een ervaren sys-admin kan, dus ik ga eerst nog een half jaar moeten bijleren voordat ik me nuttig kan maken." Ik ben al de persoon met de meeste IT-kennis daar dus het rust allemaal op mij.

Ik zou adviseren iemand langs te laten komen?

Met een dagje sparren met iemand die je netwerk en HA setup door komt lichten kan je een jaar vooruit; weet je in welke richting je moet bouwen en kan je de belangrijkste SPOFs direct aanwijzen. Ook het rechttrekken van de vSphere config (en een uitleg over hoe deze met netwerking omgaat) moet binnen die dag kunnen. Ook voorkom je de meeste valkuilen en risico's tijdens je verdere aanpassingen.
Niet heel goedkoop als je het per uur bekijkt, maar ik denk dat je er als beheerder(/bedrijf) wel veel aan hebt...
Tevens bespaart het mogelijk nogal in de hardware; zoals eerder gezegd moet je een goede backup hebben maar een tweede P2000, ik zou niet weten waar je die voor nodig hebt...

Had ik al gezegd dat ik dat soort klusjes wel eens doe?

Nog inhoudelijk:
1. op de .201 vmnic2 staat als snelheid 100mbit aangegeven. Dit lijkt me niet goed...
2. HA test licenties van VMWare is heel makkelijk: een verse installatie zonder key draait in 60-dagen-trial mode (met full features)

[Question Mark]

Waarom kies je niet voor redudancy op applicatieniveau ipv op infrastructuur niveau?

Druk wat disken in die ESX hosts, en maak daar eens een datastore op aan met daarop:

• Een domain controller
• Een of meerdere RDS servers

valt dan een ESX-host, of je P2000 uit dan kunnen gebruikers nog steeds doorwerken...

Phuncz schreef op maandag 12 augustus 2013 @ 18:33:
Ik zoek hier eigenlijk een goedkope oplossing zodat 50-100 RDP-gebruikers nog steeds wat kunnen light-office'en (browsen, mail) als de P2000 eruit flikkert.

Je mist dan wellicht mail, maar ook die zou je vanaf local storage kunnen draaien (en evt ook redudant opstellen).

[Phuncz]

Dat is ook een optie, heb ik zelfs nog niet overwogen. Daar ga ik eens iets rond bedenken, thx for the tip !

[Phuncz]

Momenteel heb ik als prioriteit de backups in orde te brengen. Na wat onderzoek blijkt dat ik veel werk heb: er is bijna niets gebackupped. Onze vSphere datastore draait dan wel RAID6, buiten een paar mapjes op een paar servers, wordt er geen backup getrokken.

Ik heb in het begin al gemeld dat wij gebruik maken van Symantec Backup Exec 2012 (op een HP StorageWorks X1400 G2 met blijkbaar ergens rond de 2TB opslag), waar deze backups nu op berusten.

Nu zou ik echter liefst ook een oplossing hebben voor de kans dat één (of meerdere) van de Windows servers omvalt.
Opties:
- alles via Backup Exec doen. Helaas is de flexibiliteit hiervan niet optimaal. Voor elk scheetje geeft hij een probleem en ik hou mijn hart al vast als we het effectief nodig hebben voor een system recovery.
- system images via Windows Backup. Hier heb ik een goede ervaring mee maar niet als het draait op een vSphere omgeving. Dit laat wel toe volledige system images te draaien wanneer live.
- snapshots van de VM's. Dit laat natuurlijk toe op een hoger niveau te "backuppen" maar ideaal is het niet de manuele voorziening. Ook heeft de datastore te weinig vrije opslag om hier van alles een backup te gaan nemen.
- Veeam aanschaffen. Ik ken het niet maar ik zie dat iedereen en zijn moeder het aanraad, dus het zal wel goed zijn. Echter vermoed ik dat we er met 500€ niet vanafkomen en het lijkt me ook weer wat extra ingewikkeldheid bij gebrek aan het volledig beheersen van vSphere.

We praten over één PDC (~25GB), drie Terminal Servers (elk ~75GB), één Exchange (~240GB incl. mail) en nog een vijftal appliances (boekhouding, RemoteApp,...), allemaal Windows Server 2008 R2.

[squaddie]

Hou rekening met het feit dat een snapshot geen backup is, het alleen maar een delta van de VM en als de VM weg is of corrupt dan is de snapshot waardeloos!

Van de geven opties gaat mijn voorkeur uit naar Veeam. Het werkt goed en met een klein beetje vmware kennis prima in te richten en te onderhouden. Na inrichting heeft weinig onderhoud nodig, in tegenstelling tot mijn ervaringen met verschillende versies van Backup Exec.

Veeam gebruikt een soort gelijk licentiebeleid als VMware ofwel elke fysieke CPU (aantal cores is met Veeam 7 niet meer van belang) van een host waarop VMs staan die je wilt backuppen heb je een licentie nodig. Ze hebben ook een essentials reeks met een 6 cpu licentie gericht op de kleinere omgevingen, volgens deze link kan je met een paar 100 euro klaar zijn afhankelijk welke features je wilt.

[Question Mark]

Wat zijn de eisen die je stelt aan backup?

• Puur disaster recovery of rcovery van actuele data?
• Hoelang mag een restore duren (RTO)
• Hoeveel data mag verloren gaan tijdens een disaster (RPO)
• Moet backupdata offsite gehaald worden
• Indien ja, moet de data versleuteld zijn
• Welke retentietijden
• Wil je end-user recovery
• etc

Zonder inzage in je eisen en wensen kan er natuurlijk weinig zinnigs gezegd worden over hetgeen je nodig bent.

[Phuncz]

squaddie schreef op dinsdag 27 augustus 2013 @ 16:49:
Veeam gebruikt een soort gelijk licentiebeleid als VMware ofwel elke fysieke CPU (aantal cores is met Veeam 7 niet meer van belang) van een host waarop VMs staan die je wilt backuppen heb je een licentie nodig. Ze hebben ook een essentials reeks met een 6 cpu licentie gericht op de kleinere omgevingen, volgens deze link kan je met een paar 100 euro klaar zijn afhankelijk welke features je wilt.

Mja met twee hosts en elke 2 CPU's betekent dat 4 sockets en dus 740€ excl. BTW (moeten wij betalen vrees ik). Dan ga ik onmiddellijk de vraag krijgen waarom ze 1.000€ aan software moeten betalen als ze specifiek een "backup server" (die HP X1400 G2) hebben gekocht hiervoor. Die kan ik wel beantwoorden maar dat het niet toereikend is, is niet wat ze willen horen. Maar ja dat is dan mijn probleem I guess

Question Mark schreef op dinsdag 27 augustus 2013 @ 16:52:
Wat zijn de eisen die je stelt aan backup?

• Puur disaster recovery of rcovery van actuele data? --> Beide
• Hoelang mag een restore duren (RTO) --> gerust 24u, dat komt niet zo nauw
• Hoeveel data mag verloren gaan tijdens een disaster (RPO) --> niet-vervangbare zaken zijn voornamelijk de dossiers, de boekhouding en de administratie. Van al die terabytes dus misschien 100GB.
• Moet backupdata offsite gehaald worden --> we zijn van plan een simpele NAS te plaatsen op een externe locatie die zich nog binnen ons lokaal netwerk bevindt.
• Indien ja, moet de data versleuteld zijn --> gevoelige materie, dus ja.
• Welke retentietijden --> meeste data is statisch na aanmaak (administratie en boekhouding), dus ik voorzie voor de belangrijke data geen grote groei. De user accounts en apps daarintegen wel maar die zijn niet belangrijk.
• Wil je end-user recovery --> iedereen werkt via RDS, dus profielen en TS-servers bevatten alle gegevens.

[bigfoot1942]

hardware en software schaf je apart aan, lijkt me dat je dat niet hoeft uit te leggen.
Kort door de bocht wil je Backup Exec vervangen door Veeam.

Overigens kan BE ook VMDK backup doen, dit is zeer geschikt voor jullie omgeving. Je zou dit naast elkaar kunnen leggen, BE upgrade naar VMDK mogelijkheden of Veeam. Ik verwacht dat je keuze dan vrij makkelijk wordt.

[Question Mark]

Bij Recovery Point Object (RPO) gaat het niet om de hoeveelheid data in GB's, maar om tijd. Van bepaalde databases wil je misschien per uur een backup maken, zodat je maximaal een uur aan produktie-data kwijt bent. Voor simpele filedata mogen wellicht de wijzigingen die de laatste 24 uur uitgevoerd zijn verloren gaan. Daarvan hoeft dan slechts eenmaal per dag een backup gemaakt hoeft te worden.

End-user recovery betekend dat een gebruiker via bv een web-interface zelf een restoreverzoek in kan dienen, die dan automatisch op de achtergrond uitgevoerd gaat worden. Het staat compleet los van type data, of waar deze staat.

Overigens stelde ik de vragen niet zozeer om de antwoorden te krijgen, maar meer om jezelf bewust te worden van het doel van backuppen. Je backupped nl altijd met een reden: bv. bij een calamiteit moet bedrijfsapplicatie A binnen 4 uur weer operationeel zijn. Je oplossing zal hierin moeten voorzien.

In jouw geval zul je overigens al blij zijn dat je uberhaubt een werkende backup hebt, en ik begrijp dat het ook nog eens niks mag kosten. Kijk even naar de "Veeam backup essentials" versie, die is bedoeld voor kleinere omgevingen en kost iets minder.

[Phuncz]

Question Mark schreef op woensdag 28 augustus 2013 @ 10:14:
Bij Recovery Point Object (RPO) gaat het niet om de hoeveelheid data in GB's, maar om tijd. Van bepaalde databases wil je misschien per uur een backup maken, zodat je maximaal een uur aan produktie-data kwijt bent. Voor simpele filedata mogen wellicht de wijzigingen die de laatste 24 uur uitgevoerd zijn verloren gaan. Daarvan hoeft dan slechts eenmaal per dag een backup gemaakt hoeft te worden.

24u is een goede indicatie. Het gaat zelden voorkomen (hopelijk) en we hanteren geen kritische data in de zin dat het ons veel geld kost als we een dag werk moeten inhalen. Het is voornamelijk administratief, bekijk ons als een administratief centrum met 200 "office-only" gebruikers.

End-user recovery betekend dat een gebruiker via bv een web-interface zelf een restoreverzoek in kan dienen, die dan automatisch op de achtergrond uitgevoerd gaat worden. Het staat compleet los van type data, of waar deze staat.

Ah nee, totaal niet nodig. De mensen hebben al problemen met basis-gebruik Windows, dan ga ik hun zeker niet voorzien in zelf backups terugplaatsen

Overigens stelde ik de vragen niet zozeer om de antwoorden te krijgen, maar meer om jezelf bewust te worden van het doel van backuppen. Je backupped nl altijd met een reden: bv. bij een calamiteit moet bedrijfsapplicatie A binnen 4 uur weer operationeel zijn. Je oplossing zal hierin moeten voorzien.

OK did not get that. Het probleem is dat ik als junior zijnde nooit een opleiding heb ervaren inzake backups. Daarom dat ik dus ook niet wist wat RTO, RPO en end-user recovery is.

In jouw geval zul je overigens al blij zijn dat je uberhaubt een werkende backup hebt, en ik begrijp dat het ook nog eens niks mag kosten. Kijk even naar de "Veeam backup essentials" versie, die is bedoeld voor kleinere omgevingen en kost iets minder.

Ja we gaan best uit van geen of zeer lage (<500€) kosten omdat dit altijd voor een hoop gedoe zorgt.
Dat de realiteit niet overeenkomt met de verwachtingen die voor de implementatie genomen worden, is helaas een dagelijkse strijd die ik nooit kan winnen.

Maar die Veeam Backup Essentials zoals hierboven aangehaald werd, lijkt toch makkelijk richting 1000€ incl. BTW te gaan waar ik nog niet eens voor moet proberen te vragen. Ook al geloof ik dat dit de moeite waard is en het nut ervan inzie. Dus totdat er budget hiervoor vrijkomt wil ik er het beste van maken zonder geld uit te geven.

Ik ga proberen dit te krijgen maar ik kan gewoon niet garanderen dat men openstaat om dit nu te kopen of pas binnen een jaar, daarmee dat ik ook voor nu oplossingen zoek.

[ Voor 3% gewijzigd door Phuncz op 28-08-2013 11:54 ]