advies tbv hyper-v failovercluster omgeving

[stefanxxx511]

hallo

ik open dit topic omdat ik momenteel in een klein bedrijf een nieuwe server omgeving wil gaan inrichten en daar wellicht wat advies in kan gaan gebruiken.
plan is als volgt: momenteel draaien er veel oude server in de omgeving. dit wil ik terug gaan brengen naar 2 failover nodes met daarop hyper-v en physical to virtual gaan uitvoeren.
nu draait er ook een Synology RS3614RPxs deze is nog geen jaar oud. met zo'n 20TB het idee is om deze Syno te gaan her inrichten en daar LUN's op te zetten voor de Cluster shared volumes. en dit d.m.v multipath io aan de 2 nodes te hangen. (2x Dell Poweredge R740) 2x 10GB teamed nic naar de Syno

het plan is om zo'n 20 vm's te gaan draaien in die cluster. plan is ook later om iets met VDI te gaan doen daarin. maar qua performance oogpunt lijkt mij dat niet een goed plan

nu is mijn vraag zijn er ook mensen met ervaring die een goeie hyper-v failovercluster icm een Synology NAS. performance, stabiliteit etc

nu twijfel ik zelf over de performance. dat de vm daar issues mee gaan geven.
ik begrijp dat de Syno dan een singlepoint of failure zal zijn. maar omdat we nu eenmaal die syno hebben ben ik de mogelijkheden aan het bekijken. aangezien Synology dit op hun site dit toch aanprijst (bron)

anders neig ik toch naar een SAN oplossing met HBA controllers. maar hier ligt de investering weer hoger

[MAX3400]

De performance zal voldoende zijn gezien de theoretische specs. Het issue is meer, zoals je zelf ook aangeeft, dat je een SPOF creeert.

Imho is multipath juist not done; je gaat "onbekend" balanceren van host naar storage. Ik zou liever kiezen voor een "failover team" dus dat je maar 1x 10Gbit per host naar storage hebt en als 1 NIC "defect" raakt, dat de andere het overpakt.

Waar ik meer mee zit en dus geen antwoord op kan geven; hoeveel I/O verwacht je te genereren en welke latencies mogen jouw VM's zelf hebben? Een beetje fileserver zal niet vallen over een latency naar de virtual of direct storage maar een SQL-database met hoge load, kan er niet zomaar "enkele seconden" uit liggen.

Wil best meedenken maar dan waardeer ik het als je je startpost uitwerkt; over welke protocollen hebben we het die je naar je Syno wil sturen? Welke disk pools / spindle sizes / cache / etc... gaat het over? Hebben de R740's ook local storage?

[ElCondor]

Ik heb persoonlijk met Synology in een productie omgeving niet de beste ervaringen.
Het was welliswaar een eerder model dan dat jij hebt maar wij haalden te weinig OIPS er uit om het stabiel en vlot te laten draaien.
We habben er alles uit geperst maar er uiteindelijk voor gekozen om op de fysieke hosts voor local disks te gaan. Niet heel fijn voor live migration, maar het werkte eenvoudigweg niet.
Voor een Lab zou het te doen zijn, maar in een productie omgeving kun je eigenlijk alleen toe met een goed SAN.
Hoeveel VM's hebben we het uiteindelijk over? Heb je berekend hoeveel IOPS die VM's verbruiken?
Wat voor een VM's zijn het? Zijn het statische applicatie servers of SQL servers of fileservers?
Dat zoort zaken moet je allemaal meenemen in je plan. Ieder type server heeft zijn eigen vereisten en mogelijkheden en onmogelijkheden als je ze gaat virtualiseren.

[Frost_Azimov]

Als je performance en een SPOF wilt vermijden en toch de kosten laag wilt houden zou je eens kunnen kijken naar een oplossing met een Starwind VSAN.

De software is stabiel & simpel/intuitief, werkt eigenlijk behoorlijk goed. Er van uitgaande dan je op de hosts voldoende performing storage hebt.

Voordeel is wel echte HA (wat je met Hyper-V replicatie niet hebt) en betere performance. Overigens is een goed opgezet network nog steeds erg belangrijk, let vooral op de IOPS. Natuurlijk is wat er op draait wel erg belangrijk, maar voor een klein bedrijfje met 20 servers verwacht ik niet echt te veel requirement wise...

[ Voor 35% gewijzigd door Frost_Azimov op 13-04-2018 15:30 ]

[Question Mark]

stefanxxx511 schreef op vrijdag 13 april 2018 @ 14:58:
nu draait er ook een Synology RS3614RPxs deze is nog geen jaar oud. met zo'n 20TB het idee is om deze Syno te gaan her inrichten en daar LUN's op te zetten voor de Cluster shared volumes. en dit d.m.v multipath io aan de 2 nodes te hangen. (2x Dell Poweredge R740) 2x 10GB teamed nic naar de Syno

Hoe wil je dit precies gaan aanbieden? SMB of iSCSI? Dat maakt nogal uit nl.

stefanxxx511 schreef op vrijdag 13 april 2018 @ 14:58:
ik begrijp dat de Syno dan een singlepoint of failure zal zijn. maar omdat we nu eenmaal die syno hebben ben ik de mogelijkheden aan het bekijken. aangezien Synology dit op hun site dit toch aanprijst

In dat document staat toch echt bij het stuk over HA dat er twee van deze apparaten ingezet moeten gaan worden.

Wat zijn de eisen eigenlijk aan de omgeving met betrekking tot beschikbaarheid? Moet dit echt voor elke VM geregeld worden?

Je zou nl ook prima kunnen overwegen om elke host de helft van de storage te geven, en via replicatie op Hyper-V niveau je beschikbaarheid te gaan regelen voor alleen de vm's waar dit nodig voor is.

[DukeBox]

@stefanxxx511 Ik draai op heel wat locaties VMware i.c.m. Synology, ben er erg tevreden over. Hyper-V zal niet anders zijn denk ik.

MAX3400 schreef op vrijdag 13 april 2018 @ 15:14:
Imho is multipath juist not done; je gaat "onbekend" balanceren van host naar storage.

Wat bedoel je hier precies mee ? MPio is júíst heel precies te balanceren. Je kan zowat per TCP/IP pakketje op basis van je policy de belasting van beide paden bepalen.

[ Voor 15% gewijzigd door DukeBox op 13-04-2018 15:34 ]

[Linke Loe]

Frost_Azimov schreef op vrijdag 13 april 2018 @ 15:27:
Als je performance en een SPOF wilt vermijden en toch de kosten laag wilt houden zou je eens kunnen kijken naar een oplossing met een Starwind VSAN.

De software is stabiel & simpel/intuitief, werkt eigenlijk behoorlijk goed. Er van uitgaande dan je op de hosts voldoende performing storage hebt.

Voordeel is wel echte HA (wat je met Hyper-V replicatie niet hebt) en betere performance. Overigens is een goed opgezet network nog steeds erg belangrijk, let vooral op de IOPS. Natuurlijk is wat er op draait wel erg belangrijk, maar voor een klein bedrijfje met 20 servers verwacht ik niet echt te veel requirement wise...

TS had het volgens mij over een Hyper-V failover cluster ipv Hyper-V replica. Met een failover cluster heb je natuurlijk wel HA (op hypervisor nivo). Daarnaast kun je tegenwoordig, in plaats van een third party VSAN, kiezen voor Windows Server 2016 met Storage Spaces Direct, om de lokale storage uit je Hyper-V hosts te bundelen tot één storage pool, waar je je cluster shared volumes op aanmaakt.

[stefanxxx511]

de twee Dell's die ik aangaf, zijn nog niet aangeschaft. slechts een plan. de servers wil ik met iSCSI protocol gaan koppelen.
er zullen 2 redelijke VM's komen. 1 Exchange 2016 en een Microsoft SQL server tbv een CRM pakket.
de syno bevat een pool van 12 disks van 4 tb model (WD4000FYYZ)
allemaal in RAID5
idee is wel mocht dit afdoende zijn dan zal ik een paar disks met SSD's vervangen voor caching

[DukeBox]

stefanxxx511 schreef op vrijdag 13 april 2018 @ 15:46:
de syno bevat een pool van 12 disks van 4 tb model (WD4000FYYZ)
allemaal in RAID5

Alle 12 in RAID5 ?
Buiten dat dat al lang niet meer veilig is zal je denk ik qua write IO/s zwaar te kort komen.

[Linke Loe]

DukeBox schreef op vrijdag 13 april 2018 @ 15:48:
[...]

Alle 12 in RAID5 ?
Buiten dat dat al lang niet meer veilig is zal je denk ik qua write IO/s zwaar te kort komen.

Dat, plus het feit dat die Synology in tegenstelling tot een echt SAN maar één storage controller heeft, maakt dat apparaat wat mij betreft goed genoeg om backups naartoe weg te schrijven (bijvoorbeeld met Veeam en dan met Hyper backup op de Synology de Veeam backups naar Azure gooien).

Persoonlijk dat ik dat je eens serieus naar Storage Spaces Direct moet kijken. Lokale storage in je Hyper-V nodes aan je cluster aanbieden als een storage pool waar je je CSV's op aanmaakt.

[ Voor 37% gewijzigd door Linke Loe op 13-04-2018 15:54 ]

[DukeBox]

Linke Loe schreef op vrijdag 13 april 2018 @ 15:52:
Dat, plus het feit dat die Synology in tegenstelling tot een echt SAN maar één storage controller heeft,..

Niet als je ze in HA zet. Net als bijv. de HP 4000 lefthand series in mirror.
Vind ook niet dat je ze moet vergelijken met 'echte' SAN's maar daar is de prijs dan ook naar natuurlijk.

[ Voor 15% gewijzigd door DukeBox op 13-04-2018 15:58 ]

[Question Mark]

stefanxxx511 schreef op vrijdag 13 april 2018 @ 15:46:
er zullen 2 redelijke VM's komen. 1 Exchange 2016 en een Microsoft SQL server tbv een CRM pakket.

Waarom ga je die diensten niet op applicatieniveau hoog beschikbaar maken? Beide applicaties ondersteunen dat meer dan uitstekend.

Dat heeft nog als voordeel dat de dienst zelfs bij onderhoud (doorvoeren patches bv.) nog beschikbaar is.

Dat beschikbaarheid ook op infra niveau geregeld kan worden, wil nog niet zeggen dat dit altijd de beste keuze is. It all depends, dus nogmaals:

Question Mark schreef op vrijdag 13 april 2018 @ 15:27:
[...]
Wat zijn de eisen eigenlijk aan de omgeving met betrekking tot beschikbaarheid?

[vso]

begin eerst eens met IOPS benchmarks, en blijven benchmarken met elke wijziging.

Kijk eens naar intel fiber (+dac kabels) als pcie insteek moet kijken (of was je dit al van plan?)
Krijg je volgens mij ook "FCoE' als optie erbij .. bovenop SMB/Iscsi

kijk eens naar I/O read/write cache op de (dell)host daarmee kan je zoiezo de performance"dip" op de syno opvangen. uiterraard is SSD caching op de syno ook geen onverstandige optie.

Breek de 12disk raid 5 op naar een 4disk raid 10 voor bv "os-disk" en de rest voor storage (raid 6 btw)
vergeet niet hierbij snapshots & backup op een aparte nas / tape oid

Vergeet niet dat VDI vs VM(servers) enorm andere "spec"s hebben VDI leunt zwaar(der) op IOPS ik zou eerder overwegen een extra shell aan de syno te koppelen en daar bv cheap 1tb ssd's in te duwen

Trouwens je SPOF is eerder 2 hosts / enkele syno, vergeet niet dat je een externe sperate "backup" dc wilt hebben als je alles domain joined wilt hebben. en uitbreiding = 0 (of dure glas/10gb switch)

Kijk bv naar een blade oplossing waarbij je de blade enclosure nog kan "upgraden" op termijn (lees blade-servers erbij) dit scheelt op de lange termijn kosten.ipv nieuwe switch.
maar dit werkt ook wederkering doordat een extra nas/shelf ook makkelijk te koppelen is.

Daarnaast wat moet er in "HA" ? en hoe lang mag het eruit liggen ?

oftewel begin eerst met je
- eisen (bedrijf)
- eisen systeembeheer
- gewenste "doelen" (meetbaar zoals iops, downtime)
- noodprocedures (afdekking)
- hoe ga je wat testen (vaak vergeten en zeer belangrijk)
je test bv voor je verwachtingen .. en hoe ga je benchmarken .. (jij kent je omgeving het best)

planning .. (er is een tijd obv dingen te retouneren .. als het niet doet wat jij verwacht)

je zal de eerste sysbeheerder niet zijn die even een nieuw systeem in elkaar klikt ..

[ Voor 18% gewijzigd door vso op 13-04-2018 16:13 ]

[stefanxxx511]

ik heb inderdaad gekeken naar Storage Spaces Direct dit is een zeer mooie oplossing. dat is dan een hyper converged oplossing. maar wat ik gelezen heb dat het uit v1709 van Windows Server is verdwenen....

[Question Mark]

stefanxxx511 schreef op vrijdag 13 april 2018 @ 16:19:
ik heb inderdaad gekeken naar Storage Spaces Direct dit is een zeer mooie oplossing. dat is dan een hyper converged oplossing. maar wat ik gelezen heb dat het uit v1709 van Windows Server is verdwenen....

Start nu eerst eens met het bepalen van je requirements, kijk daarna pas naar de technische invulling.

[Frost_Azimov]

Linke Loe schreef op vrijdag 13 april 2018 @ 15:45:
[...]

TS had het volgens mij over een Hyper-V failover cluster ipv Hyper-V replica. Met een failover cluster heb je natuurlijk wel HA (op hypervisor nivo). Daarnaast kun je tegenwoordig, in plaats van een third party VSAN, kiezen voor Windows Server 2016 met Storage Spaces Direct, om de lokale storage uit je Hyper-V hosts te bundelen tot één storage pool, waar je je cluster shared volumes op aanmaakt.

Dat is zo, het is wel zo IMHO dat de starwind software fijner werkt. (Ik heb in het verleden wat met Storage Spaces Direct gespeeld in mijn lab en was er niet echt weg van, Starwind heb ik al jaren bij een klant draaien) Aan de andere kant kun je met Storage Spaces Direct wel weer PowerShell gebruiken, wat ik zelf weer handig vindt. Het is over het algemeen mijn ervaring dat kleine bedrijven niet zo'n hoohg tweaker gehalte hebben, en juist graag voor zo'n 'shrink-wrap' oplossing als Starwind kiezen. (want makkelijk beheerbaar met simple GUI)

Ik had kunnen zweren dat ik iemand iets zag schrijven over en replica, maar ik kan het nu niet meer vinden. (vardaar dat ik er aan refereerde) Ik zal me wel vergissen.

Feit blijft dat het hele HA verhaal natuurlijk op losse schroeven staat als je storage een single point of failure is.

Ik vindt @Question Mark wel een punt hebben, met name voor Exchange is het fijn een DAG te hebben en een voor een de servers naar een volgende patch level of CU te brengen. Neemt niet weg dat je dat natuurlijk alsnog kunt doen als je eenmaal de HA Hyper-V cluster op een HA storage oplossing hebt.

[ Voor 4% gewijzigd door Frost_Azimov op 13-04-2018 20:17 ]

[Bastiaan V]

Question Mark schreef op vrijdag 13 april 2018 @ 16:01:
[...]

Waarom ga je die diensten niet op applicatieniveau hoog beschikbaar maken? Beide applicaties ondersteunen dat meer dan uitstekend.

Dat heeft nog als voordeel dat de dienst zelfs bij onderhoud (doorvoeren patches bv.) nog beschikbaar is.

Dat beschikbaarheid ook op infra niveau geregeld kan worden, wil nog niet zeggen dat dit altijd de beste keuze is. It all depends, dus nogmaals:


[...]

Het wel of niet kunnen clusteren van SQL server is voornamelijk afhankelijk van de client applicaties. Wij komen er erg veel tegen die operaties uitvoeren die op een cluster domweg niet (mogen) draaien.

Daarnaast is er nog een kostenplaatje. Voor de prijs van een extra licentie voor laten we zeggen 12 cores, kan je ook een leuke xen/kvm omgeving opzetten (incl hardware!)

[MAX3400]

Bastiaan V schreef op vrijdag 13 april 2018 @ 20:25:
[...]

Het wel of niet kunnen clusteren van SQL server is voornamelijk afhankelijk van de client applicaties. Wij komen er erg veel tegen die operaties uitvoeren die op een cluster domweg niet (mogen) draaien.

Vreemd, de insteek van een cluster is juist dat 1 "listener" alle verkeer met (domme) clients afhandelt en zelf daarna regelt waar "het verkeer" heen moet.

Ik durf te stellen dat er meer applicaties last hebben van SQL Mirroring dan van een native SQL Cluster.

[Rolfie]

stefanxxx511 schreef op vrijdag 13 april 2018 @ 15:46:
1 Exchange 2016 en een Microsoft SQL server tbv een CRM pakket.

Ik zou de ondersteuning van Exchange op een Hyper-V cluster even uitzoeken. Volgens mij is dat namelijk niet ondersteund. Een betere oplossing is een DAG.
SQL zou je ook even moeten uitzoeken, hoe dit exact zit met de licenties. SQL Virtueel kan een behoorlijke kostenpost zijn.

De syno bevat een pool van 12 disks van 4 tb model (WD4000FYYZ) allemaal in RAID5
idee is wel mocht dit afdoende zijn dan zal ik een paar disks met SSD's vervangen voor caching

Volgens mij zit die met 12 disken vol, en als je dus met SSD's wilt gaan werken, zal je je raid volume moeten afbreken en opnieuw moeten maken. Iets wat je dus alleen bij bouw kan doen.
Daarnaast RAID5 . Risky voor je SPOF. Rebuild kan heel lang duren, waarbij je IO performance waarschijnlijk slecht zal zijn. EN dan maar hopen dat er niet een 2de disk defect gaat, want dan .

[vso]

Frost_Azimov schreef op vrijdag 13 april 2018 @ 20:09:
Feit blijft dat het hele HA verhaal natuurlijk op losse schroeven staat als je storage een single point of failure is.

Erhm, troost je 99,9% van elke omgeving is een SPOF design. Hoewel een NAS een inkoper is . zijn de volgende punten vaak slecht(er) geregeld
- backup
- networking (switches)
- internet
STROOMVOORZIENING (ups oid)
- Extra inkopper over commitment van resources (lees je backup ontwerp trekt het niet)

O hadden we het al gehad over "garantie?" yeah right .. 4 uur on site betekend gewoon in de regel dat al het kantoor personeel --> "tot morgen" gezegd kan worden.

de situatie:
Voordat je het "bekend" bent met het probleem is er een uur voorbij, dan debugging = 1 tot 2 uur extra voordat er uberhaupt aan "replacement" word gedacht .. en dan nog eens paar uur voordat de bare essentials op zijn.

Want wie doet er nu nog aan stekker trekken als het eenmaal draait .. hoezo testen ?? nah .. geen tijd voor.

UPS baterrij-en die dood zijn, is niet eens erg .. de stroompieken zijn vaak killer. dus die vang je op en bescherm je de apparatuur .. immers je hebt een Links(UPS) en rechts(non-ups) maar wel PDU's aan beide kanten.

Ik vindt @Question Mark wel een punt hebben, met name voor Exchange is het fijn een DAG te hebben en een voor een de servers naar een volgende patch level of CU te brengen. Neemt niet weg dat je dat natuurlijk alsnog kunt doen als je eenmaal de HA Hyper-V cluster op een HA storage oplossing hebt.

Dat betreft is O365 gewoon prettig geen gezeur meer met exchange

Overgens een syno is niet per direct een SPOF, zorg dat je een 2de hebt die je "backup" draait" en gebruik een extra shell voor de backup disks .. bij HW failure van de primairy rag je de disks over "paar settings" en 10 min later ben je weer up and running.

@Frost_Azimov, @MAX3400 en @Bastiaan V clustering is zo "slecht" het voegt vaak meer ellende toe dan geluk. Tuurlijk er zijn situaties waar het wel goedgaat maar die zijn eerder uitzondering dan regel.
je kan veel meer met loadbalancing bereiken en een goeie service window. HA is ook in veel gevallen daarmee ook niet eens nodig. Maar ja we zijn verwend .. we willen niet eens meer een server booten

Natuurlijk ben ik wat sarcastisch hier en daar ..Maar ik heb zo vaak gezien dat met wat DB(Admin) kennis en gewoon schoning van "troep" je 99% meer winst krijgt in je omgeving.

---

Overgens met een Synology zit je wel in een onder segment van storage .. je mag blij wezen als replication van data het goed doet.. kijk bv naar een backup solution van veeam als toevoeging.
De "enterprise" storage solutions bieden meer weerstand voor SPOF situaties maar betaal je ook arm/nier voor je krijgt dan wel Dedupe wat zeer nuttig (kan) zijn.

Dus @stefanxxx511 doe goed je huiswerk .. en begin eerst eens met beter je basis te beschrijven en dus wensen/eisen te sorteren. Het is normaal in oplossingen te denken.. maar beschrijf eerder de reden v.d oplossing ipv het product.

[Question Mark]

Bastiaan V schreef op vrijdag 13 april 2018 @ 20:25:
[...]

Het wel of niet kunnen clusteren van SQL server is voornamelijk afhankelijk van de client applicaties. Wij komen er erg veel tegen die operaties uitvoeren die op een cluster domweg niet (mogen) draaien.

Zeker weten dat je niet in de war bent met mirroring? Dat moet vanuit de client wel ondersteund worden, clustering zou geen enkel probleem moeten zijn.

Bastiaan V schreef op vrijdag 13 april 2018 @ 20:25:
[...]
Daarnaast is er nog een kostenplaatje. Voor de prijs van een extra licentie voor laten we zeggen 12 cores, kan je ook een leuke xen/kvm omgeving opzetten (incl hardware!)

Redudantie kost altijd veel geld, vandaar mijn eerdere vragen of dit ook echt wel nodig is. Een high available storage backend is ook niet goedkoop. Afhankelijk van de exacte situatie kan een techniek als mirroring, clustering of replicatie via een Hypervisor goedkoper zijn.

Frost_Azimov schreef op vrijdag 13 april 2018 @ 20:09:
[...]

Ik vindt @Question Mark wel een punt hebben, met name voor Exchange is het fijn een DAG te hebben en een voor een de servers naar een volgende patch level of CU te brengen. Neemt niet weg dat je dat natuurlijk alsnog kunt doen als je eenmaal de HA Hyper-V cluster op een HA storage oplossing hebt.

Neup, Een HA oplossing via de Hypervisor zorgt alleen voor beschikbaarheid van de virtuele hardware. Raakt data corrupt, dan wordt die corruptie gewoon mee gerepliceerd.

Dat is nu net het mooie voordeel van bv. een Exchange DAG en SQL mirror. Er zijn dan meerdere logische instanties die afzonderlijk een dienst kunnen aanbieden. Fouten in een OS of software worden niet gerepliceerd en blijven geisoleerd.

vso schreef op vrijdag 13 april 2018 @ 21:08:
[...]
Dat betreft is O365 gewoon prettig geen gezeur meer met exchange

Goed punt Afhankelijk van requirements kan dit voor mailgerelateerder functionaliteit een ontzettend goede oplossing zijn.

[bigfoot1942]

Idee, low budget en toch bijzonder effectief, een MD3200 / MD3220.
Soort disk shelf welke je via SAS op je servers kan aansluiten (DAS dus).
Lijkt qua design op je synology setup zonder extra iSCSI switches oid, wel redundant controllers.

RAID5 met 12 disks is qua lezen prima, qua schrijven een drama...
Verder, met 4TB drives zijn je rebuild tijden altijd een risico...

[ Voor 3% gewijzigd door bigfoot1942 op 21-04-2018 01:34 ]

[Dromer]

Wij gebruiken ook wel syno's voor een HA omgeving.
An sich werkt dat prima als je de eisen ook in ogenschouw neemt.
Verder kan je 2 SSD's toevoegen aan de syno voor caching, dit geeft de performance meestal ook wel een soort van boost.
Al met al, meten is weten

[Dennism]

Ik zou wel uitkijken met hardware zoals in de OP en op voorhand goed testen voordat je zoiets gaat aanbieden aan een klant. Niet al te lang geleden heb ik een soortgelijke opstelling getroubleshoot. (2x VMware Essentials Plus ipv Hyper-V maar wel een Syno, uit mijn hoofd ook 3416XS met 7200 RPM Sata disks in Raid 10 en 2x 512GB een cache SSD, Raid 5 zou ik nooit doen voor VM's met 7200 RPM sata drives. Al met al werkte het wel, maar de performance was niet geweldig en dat was maar met een VM of 10 en vrij licht gebruik. Herstarten van bijv. alle servers tijdens updates zorgde er regelmatig voor dat servers makkelijk 5-6 min deden over het booten, er vaak faillures waren bij het starten van services tijdens het booten (bijv. Exchange transport service of de store) wat voor een boel issues zorgde. Deze storage vervangen door een instap all flash storage (SAS in een DAS opstelling) en alles werkte een stuk beter. boot times van <1 min voor alle servers, zelfs de zwaarste, geen enkele storing meer gezien qua niet startende services sinds dien en ook geen andere vage zaken).

Een systeem als dit kan best werken, maar zorg dat je wel van te voren goed test voordat je zaken gaat bestellen en plaatsen zodat je niet achteraf een teleurstelling krijgt. Als ik je setup zo zie zie ik een mogelijk dikke overkill aan de compute kant (de 740's bedoel ik, 640's of zelfs 630 zijn vaak ruim voldoende en vaak een stuk goedkoper bij gelijke hardware, zeker bij een deployment met maar 20 vm's ). Misschien daar eens kijken, wat goedkopere nodes en wat duurdere storage zodat je een wat beter gebalanceerd systeem krijgt overall

Maar goed, ik zou vooral eerst:

De wensen, eisen en doelen in kaart brengen, het budget bepalen en vanuit daar pas aan techniek gaan denken en de haalbaarheid binnen budget.

[Vorkie]

Dennism schreef op woensdag 25 april 2018 @ 22:39:
Ik zou wel uitkijken met hardware zoals in de OP en op voorhand goed testen voordat je zoiets gaat aanbieden aan een klant. Niet al te lang geleden heb ik een soortgelijke opstelling getroubleshoot. (2x VMware Essentials Plus ipv Hyper-V maar wel een Syno, uit mijn hoofd ook 3416XS met 7200 RPM Sata disks in Raid 10 en 2x 512GB een cache SSD, Raid 5 zou ik nooit doen voor VM's met 7200 RPM sata drives. Al met al werkte het wel, maar de performance was niet geweldig en dat was maar met een VM of 10 en vrij licht gebruik. Herstarten van bijv. alle servers tijdens updates zorgde er regelmatig voor dat servers makkelijk 5-6 min deden over het booten, er vaak faillures waren bij het starten van services tijdens het booten (bijv. Exchange transport service of de store) wat voor een boel issues zorgde. Deze storage vervangen door een instap all flash storage (SAS in een DAS opstelling) en alles werkte een stuk beter. boot times van <1 min voor alle servers, zelfs de zwaarste, geen enkele storing meer gezien qua niet startende services sinds dien en ook geen andere vage zaken).

Een systeem als dit kan best werken, maar zorg dat je wel van te voren goed test voordat je zaken gaat bestellen en plaatsen zodat je niet achteraf een teleurstelling krijgt. Als ik je setup zo zie zie ik een mogelijk dikke overkill aan de compute kant (de 740's bedoel ik, 640's of zelfs 630 zijn vaak ruim voldoende en vaak een stuk goedkoper bij gelijke hardware, zeker bij een deployment met maar 20 vm's ). Misschien daar eens kijken, wat goedkopere nodes en wat duurdere storage zodat je een wat beter gebalanceerd systeem krijgt overall

Maar goed, ik zou vooral eerst:

De wensen, eisen en doelen in kaart brengen, het budget bepalen en vanuit daar pas aan techniek gaan denken en de haalbaarheid binnen budget.

Dat is wel vreemd, had je niet maar 1 pad en/of 1Gbit/s? want dan deel je 115MB/s met 10VM's... NFS kan geen Multipath (3.0 wat Syno heeft) 4.1 wel. ISCSI daarentegen weer wel, maar alsnog meerdere interfaces nodig. (ook al heb je LACP / TRUNK gebruik op je Synology, je ESX host is maar 1 mac-adres)

[Dennism]

Vorkie schreef op woensdag 25 april 2018 @ 22:47:
[...]

Dat is wel vreemd, had je niet maar 1 pad en/of 1Gbit/s? want dan deel je 115MB/s met 10VM's... NFS kan geen Multipath (3.0 wat Syno heeft) 4.1 wel. ISCSI daarentegen weer wel, maar alsnog meerdere interfaces nodig. (ook al heb je LACP / TRUNK gebruik op je Synology, je ESX host is maar 1 mac-adres)

Nee, was een 10Gbit opstelling, 2x 10Gbit in de Syno d.m.v. een optionele insteekkaart en 2x 10Gbit in beide hosts. Main issue is imho echter niet de netwerk interfaces of de maximale troughput, maar het feit dat de 7200RPM disks de boel niet aankunnen zodra de cache vol zit en je een enorme disk latency krijgt bij random IO.

[Vorkie]

Dennism schreef op woensdag 25 april 2018 @ 22:54:
[...]


Nee, was een 10Gbit opstelling, 2x 10Gbit in de Syno d.m.v. een optionele insteekkaart en 2x 10Gbit in beide hosts. Main issue is imho echter niet de netwerk interfaces of de maximale troughput, maar het feit dat de 7200RPM disks de boel niet aankunnen zodra de cache vol zit en je een enorme disk latency krijgt bij random IO.

Ja, als VAAI / ODX is ingeschakeld stuur je eigenlijk vanaf de host het copy / move commando naar de Synology.

https://www.petri.com/windows-server-odx
MSDN: Windows ODX test (Offloaded Data Transfers) – Shared technical ti...

Dan is je Hyper-V host / ESX host al klaar met kopiëren, maar is de Synology op de achtergrond nog de taak aan het uitvoeren en dan krijg je op je host een enorme hoge latency naar je virtuele disks.

Door er 10k schijven in te plaatsen of ODX uit te schakelen op de Hyper-V host kan je dit versnellen (ODX uitschakelen zorgt ervoor dat je Hyper-V host zelf alles gaat doen, maar met 2x10Gbit/s zou dat geen probleem moeten zijn).

Met ODX uit is de Hyper-V host daadwerkelijk klaar op het moment dat de actie is uitgevoerd, in plaats van dat de Synology op de achtergrond de taak afmaakt.

[Dennism]

Vorkie schreef op vrijdag 27 april 2018 @ 12:13:
[...]

Ja, als VAAI / ODX is ingeschakeld stuur je eigenlijk vanaf de host het copy / move commando naar de Synology.

https://www.petri.com/windows-server-odx
MSDN: Windows ODX test (Offloaded Data Transfers) – Shared technical ti...

Dan is je Hyper-V host / ESX host al klaar met kopiëren, maar is de Synology op de achtergrond nog de taak aan het uitvoeren en dan krijg je op je host een enorme hoge latency naar je virtuele disks.

Door er 10k schijven in te plaatsen of ODX uit te schakelen op de Hyper-V host kan je dit versnellen (ODX uitschakelen zorgt ervoor dat je Hyper-V host zelf alles gaat doen, maar met 2x10Gbit/s zou dat geen probleem moeten zijn).

Met ODX uit is de Hyper-V host daadwerkelijk klaar op het moment dat de actie is uitgevoerd, in plaats van dat de Synology op de achtergrond de taak afmaakt.

Klopt, maar dat is het volgens mij ook niet, dit was een heel simpel 2 node cluster met vSphere Essentials Plus, terwijl VAAI volgens mij begint bij Standaard. Dus ik zou eigenlijk denken dat VAAI er niets mee te maken heeft.

10K schijven zijn er ook voor zover ik weet niet voor deze Syno's, Sata only en volgens mij zijn 10K Sata schijven al een tijdje geen optie meer. De opstelling die daar draaide (niet door ons geleverd trouwens, wij kwamen voor het trouble shooten), waren dus 7200RPM disks met 512GB aan SSD cache (Read / Write), waardoor alle writes door de cache gaan samen met de belangrijkste "Hot data". Het issue dat je echter zal is dat zodra die 512GB aan SSD cache vol zat er een soort van "file" begint te ontstaan, de SSD cache gaat proberen als een malle te flushen naar de HDD's om cache ruimte vrij te krijgen, alle writes op dat moment bypassen de cache omdat deze vol zit en gaan dus direct naar de HDD's, alle reads van data die niet "Hot" is gaan ook direct naar de HDD's waardoor je volgens mij een situatie krijgt dat de schijven het niet aankunnen en je een zeer hoge latency krijgt zelfs bij relatief lage loads.

[Vorkie]

Dennism schreef op vrijdag 27 april 2018 @ 12:27:
[...]


Klopt, maar dat is het volgens mij ook niet, dit was een heel simpel 2 node cluster met vSphere Essentials Plus, terwijl VAAI volgens mij begint bij Standaard. Dus ik zou eigenlijk denken dat VAAI er niets mee te maken heeft.

10K schijven zijn er ook voor zover ik weet niet voor deze Syno's, Sata only en volgens mij zijn 10K Sata schijven al een tijdje geen optie meer. De opstelling die daar draaide (niet door ons geleverd trouwens, wij kwamen voor het trouble shooten), waren dus 7200RPM disks met 512GB aan SSD cache (Read / Write), waardoor alle writes door de cache gaan samen met de belangrijkste "Hot data". Het issue dat je echter zal is dat zodra die 512GB aan SSD cache vol zat er een soort van "file" begint te ontstaan, de SSD cache gaat proberen als een malle te flushen naar de HDD's om cache ruimte vrij te krijgen, alle writes op dat moment bypassen de cache omdat deze vol zit en gaan dus direct naar de HDD's, alle reads van data die niet "Hot" is gaan ook direct naar de HDD's waardoor je volgens mij een situatie krijgt dat de schijven het niet aankunnen en je een zeer hoge latency krijgt zelfs bij relatief lage loads.

Je kan het op de Synology heel duidelijk zien aan de I/O wait bij de CPU. Het verhaal van de SSD cache is net zo belangrijk natuurlijk, je moet je cache wel sizen op je omgeving (hoeveelheid file movements, er zit niet voor niets een SSD Cache advisor in ).

Verder benoemde ik natuurlijk het technische aspect voor de TS, dat, in het geval van Hyper-V i.c.m. Synology, ook kan zorgen voor "onverklaarbare" trage response tijden van de VM's, terwijl de host uit zijn neus zit te eten.

Met 20VM's zou de RS3614x het moeten kunnen bijbenen, als dit DC's zijn en een webservertje, maar ga je high I/O doen, veel writes (tegenover reads) moet je goed berekenen zoals overal. Ter vergelijking van DAS / 3PAR / NetApp (veel spindles) is Synology dan een "goedkope" oplossing, als je maar geen wonderen verwacht.

[squaddie]

Ik heb op het werk getest met Synology en Qnap nas en samengevat als de lees- en schrijfactie sequentieel is dan presteren ze goed zowel in raid10 als raid5/6 en kunnen ze concurreren met professionele san of nas. Bij virtualisatie is mijn ervaring dat de workload grotendeels uit random IO bestaat en dat is niet de sterkste kant van een Synology of Qnap, in raid10 is de performance redelijk, maar raid5/6 is ronduit slecht in vergelijking met het professionele broertje.

Het inzetten van SSDs als cache bij Synology helpt de performance op te krikken, maar de implementatie van cache was eenvoudig en performance van cache was niet brilliant. Terwijl dezelfde SSDs in raid 1 als normaal volume dan kreeg wel een goede performance, nooit helder weten krijgen wat nu exact het issue was.

Persoonlijk zou ik bedrijven niet aanraden om dergelijke nas als shared storage bij virtualisatie in te zetten en dat is niet op de eerste plaats om wat ik hierboven schrijf, maar vanwege het ontbreken van support. Bij een klant was de performance van de Synology die als backup opslag diende spontaan slecht, ik vermoedde een disk die rot was, maar kon niet vinden welke. De enige optie was mailen met Synology support, binnen de kantoortijden reageerde support binnen twee uur, echter buiten kantoortijden kreeg ik geen reactie. Nu was dit slechts voor backup, maar als daarop je VMs draaien dan sta je te kijken als je geen support kan contacteren. Als je niet de mogelijkheid heb om de VMs te verplaatsen naar andere storage, dan adviseer ik iets meer te betalen, maar wel de optie te hebben om indien nodig 24/7 support te kunnen contacteren als er een probleem optreed.

Je zou trouwens ook onderzoek kunnen doen naar shared nothing HyperV cluster. Waarbij er geen shared storage is, maar de nodes lokale opslag hebben en een replica naar een andere node synchroniseren.

[tomdabom]

Ik zou eens kijken naar HP VSA..