Vsan vs SAN

[Anoniem: 150659]

Beste,

Ik ben bezig met een nieuwe setup maar weet niet goed wat te kiezen daar mijn kennis van vsan nul is.
Daar ik altijd heb gewerkt met een SAN en deze altijd zijn waarde heeft getoond is de omschakeling naar VSAN moeilijk alhoewel ik goeie reacties lees.

Even mijn situatie schetsen.

Vandaag werken we met VMware (VMware Essentials Plus ) 3 hosts en een SAN .
Hardware is verouderd en aan vervanging toe.

Ik heb op dit moment 2 ideeen

1)

Aankoop 3 nieuwe Hosts + lics Vmware VSAN.
Vmware Essentials Plus (3 hosts) met VSAN - backup naar backupstorage icm Veeam.
Alles op 1 locatie.(behalve de backupstorage)

2)

Aankoop 2 nieuwe host + VNXe (EMC) - locatie 1
15 min replicatie naar 1 oudere server met oude SAN (disaster recovery via VEEam) - locatie 2
Backup naar backupstorage via Veeam. - locatie 3



Optie 2 is 10.000 euro goedkoper en heeft DR
Optie 1 is 10.000 euro duurder omwille van de 3de server en de VSAN lics.

Ik hoor overal dat VSAN de toekomst is , maar aan de andere kant heeft de SAN altijd zijn dienst bewezen.


Ik hoor graag jullie reacties.


Vriendelijke groeten

[ Voor 3% gewijzigd door Anoniem: 150659 op 11-11-2015 16:09 ]

[Wim-Bart]

Persoonlijk vind ik voor een professionele omgeving een 3-node VSan een risky business. Wat als 2 hosts crashen of een host crashed terwijl er een andere in maintenance mode staat. Beheer technisch is een los SAN voor mijn gevoel veiliger. Je hebt je storage laag los getrokken van je ESX omgeving en houd de rollen gescheiden.

VSan is een mooie techniek, maar het is een hobby oplossing voor mijn gevoel.

Een ander voordeel is dat je de IO handling weg trekt van ESX. Waardoor ESX kan doen waar het goed in is. Het hosten van VM's. Performance wise zou ik zelf naar een SAN gaan en volumes op NFS aanbieden via 10GBe. Daarmee win je twee zaken: 1. Storage overhead is weg bij ESX (VSAN -< SAN) en 2. VMFS filesystem taken verleg je naar SAN (VMFS op ESX servicen -> NFS op SAN servicen).

[DukeBox]

Ik zou voor een degelijke storage oplossing gaan. Zoals eerder genoemd, vsan is leuk maar idd een hobby bijsmaakje..
n.b. je weet dat er replicatie (vdp & vr) en backup (vdp) in je Essentials Plus zit ?

[ Voor 40% gewijzigd door DukeBox op 11-11-2015 16:33 ]

[SirDarkAngel]

Vind je opties nogal een vreemde vergelijking. Het klinkt alsof ik kinderen voor de tv zie zitten, speelgoed reclames voorbij komen en zei roepen: Die wil ik voor Sinterklaas en die en die, puur omdat het er leuk uitziet. Wat het precies doet is onbekend, lang leve de marketing.

Heb je requirements opgesteld waaraan je omgeving moet voldoen? Heb je gekeken of VSAN daarbij een oplossing biedt voor hetgeen wat je zoekt? Heb je functies gezien welke een SAN biedt waarbij jij denkt dat je iets mee kan? etc.

Daarbij ben ik benieuwd welke storage je gebruikt in je vergelijking. Welke storage gebruik je als je VSAN gaat gebruiken, welke storage als je een traditioneel SAN gaat gebruiken.

Zo is het nog wel even mogelijk om door te gaan. Ik denk dat niemand je hier een goed advies kan geven en alleen aan kan geven wat zei van VSAN vinden (kan je via Google ook vinden). Mijn advies (aan de hand van je verhaal) is om hiervoor een specialist te laten komen en samen met diegene je wensen en eisen bespreken.

_{Op VMware World is er aangekondigd dat VSAN binnenkort ook mogelijk is met 2 hosts.}

Edit:

DukeBox schreef op woensdag 11 november 2015 @ 16:31:
Ik zou voor een degelijke storage oplossing gaan. Zoals eerder genoemd, vsan is leuk maar idd een hobby bijsmaakje..
n.b. je weet dat er replicatie (vdp & vr) en backup (vdp) in je Essentials Plus zit ?

Onderbouw het "hobby bijsmaakje" eens. De vorige poster zet dit ook neer, maar op basis van een gevoel. Wanneer is een storage oplossing degelijk?

[ Voor 17% gewijzigd door SirDarkAngel op 11-11-2015 16:39 ]

[Anoniem: 150659]

Ik wou hier gewoon minder technisch klinken om een simpele situatie te schetsen.
Ik kan hier héél technisch in gaan maar dat wou ik juist niet doen.

soit ...

Wim-Bart ... mijn gedacht is hetzelfde als het jouwe.

en de 3 host oplossing is omdat de huidige klant enkel een Essentials plus heeft, ik zou ook liever meer hosts zien maar qua budget is dit geen optie.

Bedankt voor de reactie.

[ninjazx9r98]

Wim-Bart schreef op woensdag 11 november 2015 @ 16:28:
Een ander voordeel is dat je de IO handling weg trekt van ESX. Waardoor ESX kan doen waar het goed in is. Het hosten van VM's. Performance wise zou ik zelf naar een SAN gaan en volumes op NFS aanbieden via 10GBe. Daarmee win je twee zaken: 1. Storage overhead is weg bij ESX (VSAN -< SAN) en 2. VMFS filesystem taken verleg je naar SAN (VMFS op ESX servicen -> NFS op SAN servicen).

NFS is file based storage en is dus geen SAN maar NAS.
SAN is block based en daarmee verleg je integenstelling tot een NAS geen filesystem taken naar het storage device.

[Wim-Bart]

NFS is een toepassing die een deftig SAN tegenwoordig aanbied net zoals CIFS. Nergens zeg ik dat dit block level access is.

Mijn ervaringen met NFS als storage laag met ESX zijn dermate dat het altijd mijn voorkeur heeft wanneer je geen native FC hebt.

Maar zoals eerder aangegeven, wat is de use case, wat wordt er verwacht. In theorie is iedere storage oplossing een aantal disk met controllers die op een bepaalde manier gepresenteerd worden.

Maar zonder case is het eigenlijk simpel. Storage presenteren op een betrouwbare bewezen methode. En daarin gelijk de oplossing voor een mirror opnemen of een andere methodiek.

[Dennism]

Ik denk dat het vraagstuk van TS valt of staat met wat voor een SAN opstelling met VNXe nodes hij in gedachten heeft bij punt 2 een single node SAN zal namelijk in de basis nooit betrouwbaarder zijn dan een goed geconfigureerde vsan opstelling daar je gewoon een SPOF opneemt in je omgeving waardoor je van HA op storage niveau al niet meer kan spreken met alle risico's van dien.

Dit is binnen het SMB (waar ik verwacht dat TS ook zit gezien een essential opstelling met 3 hosts) een veel gemaakte fout, wel meerdere compute nodes, maar slechts 1 storage node. Iets waar je bij een VSAN opstelling geen "last" van hebt omdat je 3 compute en 3 storage nodes hebt bij een VSAN opstelling met 3 nodes. Zet je meerdere SAN nodes in, dan zou dat mogelijk inderdaad mijn voorkeur hebben boven VSAN, maar een single node SAN zou mij toch wat "te link" zijn tenzij downtime geen issue is, echter performance technisch zal een single node SAN ook niet alles zijn (VSAN of vergelijkbare technieken bieden veelal meer IOPS bij een vergelijkbaar of zelfs lager budget, bij een grotere veiligheid t.o.v. een single node SAN), maar een multinode SAN praat je waarschijnlijk ook over een stuk meer benodigd budget.

De grootste winst van een SAN t.o.v. DAS / Local storage met replicatie / VSAN (namelijk de schaalbaarheid) benut een MKB vaak totaal niet, terwijl je zelfs bij een single node SAN vaak wel de portomonee moet trekken voor een boel features die je nooit gaat benutten. Kijkt trouwens behalve naar VSAN ook eens naar zaken als HP Storevirtual of Starwind, deze partijen zijn al een stuk langer bezig met VSAN achtige technieken voor een flink lagere prijs, en ook meer bewezen in de praktijk. VSAN heeft dan wel weer het voordeel dat je de VMware Distributed vSwitch in de licentie erbij krijgt.

Afhankelijk van het budget (wanneer dit aan de lage kant is) zou je zelfs nog kunnen kijken naar local storage in de nodes in combinatie met replicatie, zeker wanneer je HA al op applicatie niveau kan afdekken. Qua snelheid vaak sneller (Meer IOPS voor een vergelijkbare of lagere prijs) dan een (single node) SAN en tegenwoordig ook gewoon vMotion e.d. mogelijk in een opstelling als deze ("vroeger" de #1 selling point voor shared storage als een SAN in het MKB) en je houd meer budget over voor bijv. een DR omgeving.

[ninjazx9r98]

Wim-Bart schreef op woensdag 11 november 2015 @ 22:40:
NFS is een toepassing die een deftig SAN tegenwoordig aanbied net zoals CIFS. Nergens zeg ik dat dit block level access is.

Dat is dan jouw eigen definitie van SAN maar block based is toch echt wat een SAN is en file based een NAS.
Ken overigens genoeg deftige storage oplossingen die helemaal geen NAS aanbieden tenzij je extra opties koopt.
Het is/raakt een beetje uit de gratie maar bij gebrek aan native fc is er ook nog iSCSI wat wel weer block based is.

De VNXe waar TS het over heeft is een hybride storage oplossing die zowel SAN (iSCSI) als NAS (CIFS, NFS) functionaliteit biedt.

[ Voor 21% gewijzigd door ninjazx9r98 op 12-11-2015 09:03 ]

[Wim-Bart]

ninjazx9r98 schreef op donderdag 12 november 2015 @ 07:20:
[...]

Dat is dan jouw eigen definitie van SAN maar block based is toch echt wat een SAN is en file based een NAS.
Ken overigens genoeg deftige storage oplossingen die helemaal geen NAS aanbieden tenzij je extra opties koopt.
Het is/raakt een beetje uit de gratie maar bij gebrek aan native fc is er ook nog iSCSI wat wel weer block based is.

De VNXe waar TS het over heeft is een hybride storage oplossing die zowel SAN (iSCSI) als NAS (CIFS, NFS) functionaliteit biedt.

Dat zeg ik niet. Ik zeg dat een deftig SAN ook functionaliteit als CIFS of NFS aan bied. Kortom NAS functionaliteit op een SAN. Maar wat is een SAN eigenlijk. Een SAN is een Storage Attached Network, dus niet alleen de onderliggende storage maar ook bijvoorbeeld de bijbehorende SAN Switches. Een NAS is een Network Attached Storage device. Een SAN kan ook een SAN device zijn. Sterker nog, wanneer je een netwerk adapter in een SAN device stopt om daar iSCSI op aan te bieden, in theorie is een SAN in dit geval een NAS.

Toen ik nog lid van de SNIA worstelden we met dit geval. Om een verschil te maken tussen SAN en NAS zijn de volgende zaken vastgesteld:

Connectivity:
--NAS uses TCP/IP Networks: Ethernet, FDDI, ATM (perhaps TCP/IP over Fibre Channel someday)
--SAN uses Fibre Channel (and Ethernet providing iSCSI)

The Protocols:
--NAS uses TCP/IP and NFS/CIFS/HTTP
--SAN uses Encapsulated SCSI (Over FC or iSCSI)

Functionality:
--A NAS identifies data by file name and byte offsets, transfers file data or file meta-data (file's owner, permissions, creation data, etc.), and handles security, user authentication, file locking
--A SAN addresses data by disk block number and transfers raw disk blocks.

Filesystem:
--File System managed by NAS head unit
--File System managed by servers

A SAN can provide NAS Functionality by adding a NAS Head.

[ninjazx9r98]

Wim-Bart schreef op donderdag 12 november 2015 @ 11:38:
[...]


Functionality:
--A NAS identifies data by file name and byte offsets, transfers file data or file meta-data (file's owner, permissions, creation data, etc.), and handles security, user authentication, file locking
--A SAN addresses data by disk block number and transfers raw disk blocks.

Met andere woorden, je zegt uiteindelijk precies hetzelfde als ik al zei (SAN is block based, NAS is file based) maar gebruikt er veel meer woorden voor

In geval van een NAS head (deftig SAN plus addon? ) wordt er dus block storage aangeboden aan de NAS head die vervolgens file based storage aanbiedt aan de 'eindgebruiker'.

[ Voor 13% gewijzigd door ninjazx9r98 op 12-11-2015 13:37 ]

[Question Mark]

Wim-Bart schreef op woensdag 11 november 2015 @ 22:40:
Mijn ervaringen met NFS als storage laag met ESX zijn dermate dat het altijd mijn voorkeur heeft wanneer je geen native FC hebt.

It all depends... Ik heb wel eens een prima functionerend SAN onder handen gehad, die via ISCSI luns aanbood. Werkte prima...

Later werd er storage aangeboden via NFS en toen ging het kreng compleet door zijn hoeven. CPU load van 100% en perfornance down the drain. Bleek dat de onboard cpu prima in staat was voor mgmt-taken, maar niet om NFS te hosten...

Bottomline, NFS performance is niet zondermeer te vergelijken met FC of ISCSI. Technisch zit er een enorm verschil in de technieken (blockbases vs filebased). Zonder achtergrondinformatie van de omgeving kan niet gesteld worden dat het één beter is dan het ander...

SirDarkAngel schreef op woensdag 11 november 2015 @ 16:35:
Heb je requirements opgesteld waaraan je omgeving moet voldoen?

^^ Dat

Begin eens met het uitleggen waar de oplossing aan moet voldoen.

Welke applicaties gebruik je, en is het noodzakelijk dat je de beschikbaarheid ook moet gaan regelen op hardwareniveau, of is dit ook in de software op te lossen?

[Anoniem: 150659]

Het gaat hier om een standaard omgeving.

2 Domain Controllers
1 Exchange Server 2016
1 SQL Server 2015 (ERP)
2 Terminal servers met een 50 tal gebruikers
1 All around server
1 Printer Server
1 Data Server
En een paar Virtual Appliances.

Het gaat niet om de super-snelste "oplossing" het gaat om de "toekomst gerichte" oplossing.
Als ik zo zie wat er allemaal op de roadmap staat van VMware Vsan lijkt me dat interessanter.
En aan de andere kant heeft een SAN oplossing mij nooit in de steek gelaten.

[Dennism]

Anoniem: 150659 schreef op zondag 15 november 2015 @ 18:59:
Het gaat hier om een standaard omgeving.

2 Domain Controllers
1 Exchange Server 2016
1 SQL Server 2015 (ERP)
2 Terminal servers met een 50 tal gebruikers
1 All around server
1 Printer Server
1 Data Server
En een paar Virtual Appliances.

Het gaat niet om de super-snelste "oplossing" het gaat om de "toekomst gerichte" oplossing.
Als ik zo zie wat er allemaal op de roadmap staat van VMware Vsan lijkt me dat interessanter.
En aan de andere kant heeft een SAN oplossing mij nooit in de steek gelaten.

Wat zijn o.a. de eisen en wensen qua uptime, high availability, Recovery tijden e.d.

Als ik deze omgeving namelijk zo zie zijn er imho geen directe use-case waar een single node SAN de beste oplossing zou zijn daar je een SPOF hebt en je ws nooit de voordelen van een fysiek SAN zal gaan gebruiken (De schaalbaarheid tot een flink aantal nodes). Terwijl je ook (bijna) alles HA kan maken op software niveau, echter zal een single node SAN die HA weer om zeep helpen vanwege het feit dat het single node is en dus bij bijv. een mobo faillure in de SAN je primaire systeem als nog helemaal plat ligt.

Ik zou eerst een goed de eisen en wensen op een rijtje zetten en vandaar uit gaan werken naar een oplossing die zoveel mogelijk

[drexciya]

Natuurlijk is een SAN een single-point-of-failure, maar hoe vaak gaat een SAN echt stuk? En als sommige machines heel belangrijk zijn kun je ook, el cheapo, vSphere replication gebruiken voor desbetreffende VMs (zit in Essentials Plus licentie). Een dubbel SAN is wel erg prijzig en dat zie ik niet zo snel terugkomen in de praktijk, dat doe je typisch als je ook volledige uitwijk wilt doen.

[CAPSLOCK2000]

Alles gaat ooit stuk. Je zal moeten bepalen welke risico's acceptabel zijn. Wat kost het als je hele omgeving 1 uur, 1 dag en 1 week down is?
Hoe lang kost het om te herstellen als er iets stuk gaat?
Wat is de kans dat het stuk gaat?

[hans_lenze]

Anoniem: 150659 schreef op woensdag 11 november 2015 @ 15:26:
...
1)

Aankoop 3 nieuwe Hosts + lics Vmware VSAN.
Vmware Essentials Plus (3 hosts) met VSAN - backup naar backupstorage icm Veeam.
Alles op 1 locatie.(behalve de backupstorage)

2)

Aankoop 2 nieuwe host + VNXe (EMC) - locatie 1
15 min replicatie naar 1 oudere server met oude SAN (disaster recovery via VEEam) - locatie 2
Backup naar backupstorage via Veeam. - locatie 3
...

Als je kunt leven met VSAN en zijn beperkingen, dan VSAN!

Maar een VSAN cluster met drie nodes is een slecht idee. Vier is het minimum voor een fijn werkbare omgeving (volgens het N+1 principe).

Je tweede optie heeft ook een complete DR omgeving. Waar komt die opeens vandaan?

Edit: VSAN heeft eigenlijk vSphere 6 nodig om lekker te werken en vSphere 6 en back-ups zijn op dit moment ehm.. laten we het maar sub-optimaal noemen
Zie ook http://kb.vmware.com/kb/2136854. Elke keer als ze een update uitbrengen om de CBT bug te pletten steekt er een nieuwe de kop op.

[ Voor 15% gewijzigd door hans_lenze op 26-11-2015 21:12 ]

[Biite]

Belangrijk is ook dat VSAN minimaal 1 SSD vereist per host voor caching en natuurlijk SAS, NL-SAS of SATA HDD's of SSD's.

Ik zou het vooral prijstechnisch eerst configureren. In de praktijk is een 'instap-SAN', zoals bijv. een HP MSA2040 met SAS-poorten goedkoper dan de VSAN licenties en de benodigde interne disken.

[hans_lenze]

In de praktijk is een Synology of Qnap NAS goedkoper dan een "instap-SAN". Je krijgt waar je voor betaalt.

[Yarisken]

Kijk is naar netapp. Daar heb je san en nas samen. Eens je met nfs hebt gewerkt kan je dit echt niet meer missen.

[Dysmael]

Vergeet NFS.
Netapp E2700 series met batterij schijven erin en dan via SAS aansluiten.
Erg makkelijk te implementeren en te onderhouden.

Qua kosten ook het meest voor de hand liggend. Je hebt namelijk toch de schijven nodig, wat je ook doet.

Gewoon DAS dus eigenlijk.

[arjants]

RolfLobker schreef op zondag 29 november 2015 @ 11:40:
Vergeet NFS.
Netapp E2700 series met batterij schijven erin en dan via SAS aansluiten.
Erg makkelijk te implementeren en te onderhouden.

Qua kosten ook het meest voor de hand liggend. Je hebt namelijk toch de schijven nodig, wat je ook doet.

Gewoon DAS dus eigenlijk.

Eensch
De E2700 serie met SAS heb ik na veel onderzoek begin dit jaar aangeschaft en de prijs/kwaliteit zit dik voor elkaar.
VEEAM backup/replication naar een synology ds2015xs via 10Gbit, ik ben tevreden voor deze MKB oplossing

[ Voor 6% gewijzigd door arjants op 29-11-2015 12:00 ]

[Dennism]

Biite schreef op vrijdag 27 november 2015 @ 13:53:
Belangrijk is ook dat VSAN minimaal 1 SSD vereist per host voor caching en natuurlijk SAS, NL-SAS of SATA HDD's of SSD's.

Ik zou het vooral prijstechnisch eerst configureren. In de praktijk is een 'instap-SAN', zoals bijv. een HP MSA2040 met SAS-poorten goedkoper dan de VSAN licenties en de benodigde interne disken.

Als die MSA units van HP nog steeds zo'n drama zijn en zoveel issues geven qua betrouwbaarheid en performance als een paar jaar geleden zou ik niemand aanraden een MSA unit in te zetten.

Als ik kijk wat voor issues ik gezien het met MSA units:

1. veel Controller uitval
2. relatief hoge diskuitval vergeleken met andere storage oplossingen van HP
3. Firmware updates die het apparaat brickten, controller instellingen wissen.
4. Support vanuit HP met support contract minimaal en soms zelfs slecht (heb monteurs zien komen met verkeerde controllers, die bij een defecte controller de config van de nieuwe controller over de config van de nog werkende controller kopieerde ipv de config van de werkende controller naar de zojuist vervangen controller en meer van dat soort gein)

Op een gegeven moment is het bedrijf waar ik destijds werkte gestopt met het verkopen van MSA units vanwege deze problemen en vanwege het feit dat maar weinig klanten echt tevreden waren over de MSA units.

arjants schreef op zondag 29 november 2015 @ 11:57:
[...]


Eensch
De E2700 serie met SAS heb ik na veel onderzoek begin dit jaar aangeschaft en de prijs/kwaliteit zit dik voor elkaar.
VEEAM backup/replication naar een synology ds2015xs via 10Gbit, ik ben tevreden voor deze MKB oplossing

DAS kan idd ook een mooie oplossing zijn, wel zie ik echter ook hier te vaak dat er veelal maar 1 unit gebruikt wordt en dat vaak bij de gewenste uptime van het bedrijf geen rekening gehouden wordt met de downtime die je hebt wanneer die ene unit een issue heeft, waardoor ze bij uitval voor een nare verrassing kunnen komen te staan wanneer er bijv. geen replicatie naar een andere storage is (zoals jij wel hebt). Is daar wel rekening mee gehouden en/of is downtime in dat opzicht een ingecalculeerd risico dan is zoiets zeker een mooie oplossing.

Al zou ik er zelf niet snel voor kiezen om te repliceren en te backuppen naar hetzelfde apparaat, dat zou ik persoonlijk liever toch gescheiden houden, zeker als de DAS unit en het replicatie target zich in hetzelfde pand bevinden.

[ Voor 37% gewijzigd door Dennism op 29-11-2015 12:09 ]

[Question Mark]

Yarisken schreef op zondag 29 november 2015 @ 11:25:
Eens je met nfs hebt gewerkt kan je dit echt niet meer missen.

Want?

NFS in combinatie met Vsphere kent ook wat flinke nadelen:

• Geen loadbalancing van storageverkeer
• Boot from SAN is niet mogelijk
• Geen suport voor MS clustering

Storage Protocol Comparison – A vSphere Perspective

[ Voor 50% gewijzigd door Question Mark op 29-11-2015 12:13 ]

[Yarisken]

Question Mark schreef op zondag 29 november 2015 @ 12:09:
[...]

Want?

NFS in combinatie met Vsphere kent ook wat flinke nadelen:

• Geen loadbalancing van storageverkeer
• Boot from SAN is niet mogelijk
• Geen suport voor MS clustering

Storage Protocol Comparison – A vSphere Perspective

Ok klopt maar in ons geval is loadbalacing niet nodig, boot from san zeker niet en we hebben vooral linux servers dus ms clustering is ook niet nodig.
Wat vooral leuk is aan nfs, zeker in een linux omgeving, is het gemak om te werken met mounts.
We gebruiken ook isci voor de windows servers en als ik daar een schijf wil vergroten, verkleinen of toevoegen dan ben ik daar toch altijd iets langer mee bezig.

[Dysmael]

Je moet VM's geen iSCSI schijven gaan toewijzen. Dat doe je op hypervisor-niveau.
Als je in een VM een iSCSI schijf toewijst ga je met back-ups ook gezeik krijgen.

Vergroten is voor zowel iSCSI als Hypervisor-gebaseerd een kwestie van het volume vergroten en dan simpelweg live extenden in het Guest-OS. Toevoegen gaat net zo eenvoudig. Verkleinen is altijd een issue; ongeacht of het Windows, Linux, NTFS, EXT4 of wat dan ook is. Daarom nooit meer toewijzen dan noodzakelijk. Vergroten kan later altijd eenvoudig en vlot (plm 3 minuten klikwerk)

[Dysmael]

Dennism schreef op zondag 29 november 2015 @ 11:58:
[...]

DAS kan idd ook een mooie oplossing zijn, wel zie ik echter ook hier te vaak dat er veelal maar 1 unit gebruikt wordt en dat vaak bij de gewenste uptime van het bedrijf geen rekening gehouden wordt met de downtime die je hebt wanneer die ene unit een issue heeft, waardoor ze bij uitval voor een nare verrassing kunnen komen te staan wanneer er bijv. geen replicatie naar een andere storage is (zoals jij wel hebt). Is daar wel rekening mee gehouden en/of is downtime in dat opzicht een ingecalculeerd risico dan is zoiets zeker een mooie oplossing.

Goede DAS/SAN is uit zichzelf redundant. NetApp E2700 series heeft gewoon twee controllers. Enige wat niet redundant is, dat is het metaal wat er omheen zit. Schijven zijn redundant, voeding is redundant en schijven zijn reduntant. Je mag dus eigenlijk ook niet stellen dat er sprake is van één unit.

Wil je toch meer, zoals replica dan kan je dat heel mooi oplossen door een tweede E2700 te plaatsen en deze het liefst met FC te verbinden. Met een dubbel uitgevoerde E2700 maak je heel simpel een mirrorvolume.

Ook kan je met Veeam erg mooi replica's klaarzetten. Wat ik dan het mooiste en meest elegantste vind is een aparte back-upserver met veel lokale opslag. Daar bewaar je alle back-ups en van daar uit kan je ook zeer snel herstellen of een replica / lab-omgeving creeeren. Dat hoeft niet op duurdere SAN-opslag. Verbind de back-upserver ook met FC / SAS voor een supersnelle connectie. Maar ook met Windows 2012R2 en NIC Teaming van 4x Gbit haal je al fantastische back-upsnelheden (300-400MB/s).

Voor de rest zorg je dat je de contracten in orde hebt. Heb je zelf een probleem veroorzaakt dan zet je eenvoudigweg je back-up terug (maak voor mij part elk uur een incremental back-up; daar mag productie niets van merken). Is er echt een issue met het SAN en zit dat in beide controllers dan schakel je de leverancier in en heb je een dag later als het moet een nieuw SAN. Kan je geen dag zonder dan mag je 25K extra uitgeven voor wat Brocades en een tweede SAN zodat je een mirror kan maken.

[ Voor 5% gewijzigd door Dysmael op 29-11-2015 19:10 ]

[Dennism]

RolfLobker schreef op zondag 29 november 2015 @ 19:09:
[...]


Goede DAS/SAN is uit zichzelf redundant. NetApp E2700 series heeft gewoon twee controllers. Enige wat niet redundant is, dat is het metaal wat er omheen zit. Schijven zijn redundant, voeding is redundant en schijven zijn reduntant. Je mag dus eigenlijk ook niet stellen dat er sprake is van één unit.

Ik zal ook zeker niet zeggen dat deze redundantie er niet is, enkel het feit dat het geen een unit genoemd zou mogen worden ben ik het niet volledig mee eens, echter heb ik aardig wat SAN/DAS Units bekeken en nog geen enkele kunnen ontdekken die in een single node geen SPOF heeft in het chassis in de vorm van een gezamelijke backplane in het chassis en / of een deel van het powercircuit dat beide voedingen met het chassis verbind voor verdeling van power naar de schijven en de controllers. Beide zijn geen groot risico op uitval, maar je moet ze wel onderkennen wanneer aanwezig en meenemen in je beschikbaarheids berekeningen. Ik ben beide in het verleden helaas al tegen gekomen bij defecten. Nu ken ik de E2700 zelf exact, dus ik kan niet met zekerheid zeggen dat deze ook onder deze categorie valt, maar het zou me niet verbazen.

Een beetje hetzelfde als de HP vertegenwoordiger die kwam vertellen hoe goed hun blade chassis wel niet waren omdat je met meerdere blades altijd redundant was, maar op de vraag of het chassis zelf ook defect kon gaan na enig zweten toch moet toegeven dat je met een enkel blade chassis een SPOF binnenhaalde omdat ook daar bepaalde zaken in het chassis zitten die defect konden gaan en niet redundant waren uitgevoerd.

Ook kan je met Veeam erg mooi replica's klaarzetten. Wat ik dan het mooiste en meest elegantste vind is een aparte back-upserver met veel lokale opslag. Daar bewaar je alle back-ups en van daar uit kan je ook zeer snel herstellen of een replica / lab-omgeving creeeren. Dat hoeft niet op duurdere SAN-opslag. Verbind de back-upserver ook met FC / SAS voor een supersnelle connectie. Maar ook met Windows 2012R2 en NIC Teaming van 4x Gbit haal je al fantastische back-upsnelheden (300-400MB/s).

Voor de rest zorg je dat je de contracten in orde hebt. Heb je zelf een probleem veroorzaakt dan zet je eenvoudigweg je back-up terug (maak voor mij part elk uur een incremental back-up; daar mag productie niets van merken). Is er echt een issue met het SAN en zit dat in beide controllers dan schakel je de leverancier in en heb je een dag later als het moet een nieuw SAN. Kan je geen dag zonder dan mag je 25K extra uitgeven voor wat Brocades en een tweede SAN zodat je een mirror kan maken.

ben ik volledig met je eens.

[Bigs]

We hebben hier vorig jaar voor eenzelfde keuze gestaan. Ik had verwacht dat VSAN het op prijs zou winnen maar dat viel toch wel tegen. Bovendien was VSAN toen nog vrij nieuw wat ons toch heeft doen kiezen voor de bewezen FC oplossing (IBM Storwize V3700). Geen seconde spijt van gehad. De V3700 is trouwens ook met SAS of iSCSI aan te sluiten.

[Dysmael]

Dennism schreef op zondag 29 november 2015 @ 20:06:
[...]


Ik zal ook zeker niet zeggen dat dit niet zo is, echter heb ik aardig wat SAN/DAS Units bekeken en nog geen enkele kunnen ontdekken die in een single node geen SPOF heeft in het chassis in de vorm van een gezamelijke backplane in het chassis en / of een deel van het powercircuit dat beide voedingen met het chassis verbind voor verdeling van power naar de schijven en de controllers.

Voor bijna elk SAN geldt dat het 'chassis' vrijwel niets meer is dan de kap er omheen.

Ik snap je punt aangaande de backplane. Uiteraard zijn de schijven ook op één printplaat aangesloten.
De componenten met een verhoogd risiko voor uitval zijn wel redundant en dus ook te servicen zonder uitval.

Wil je meer zekerheid dan plaats je een tweede SAN en ga je spiegelen of zorg je daarmee dat je snel back-ups / replica's in de lucht kan brengen. Je zet dan de kosten daarvan af tegen het zeer kleine risiko dat je er een dag uit ligt bij complete uitval van je enkele chassis.

Linksom of rechtsom, voor wat voor oplossing je ook gaat; je zal hem dan dubbel uit moeten voeren. Vaak zal een organisatie ervoor kiezen om het uiterst minimale risiko op een dag uitval voor lief te nemen in plaats van nu 25K neer te leggen. Het woord 'redundant' betekend namelijk nog altijd 'overbodig / overtollig'

Bigs schreef op zondag 29 november 2015 @ 20:18:
We hebben hier vorig jaar voor eenzelfde keuze gestaan. Ik had verwacht dat VSAN het op prijs zou winnen maar dat viel toch wel tegen. Bovendien was VSAN toen nog vrij nieuw wat ons toch heeft doen kiezen voor de bewezen FC oplossing (IBM Storwize V3700). Geen seconde spijt van gehad. De V3700 is trouwens ook met SAS of iSCSI aan te sluiten.

Yes, zelfde geldt voor E2700 en soortgelijken. E2700 is standaard voorzien van 4x SAS (veel organisatie hebben 3x host en dan 1x aparte back-upserver). Volgens mij is een licentie nodig voor iSCSI en voor FC zijn uitbreidmodules verkrijgbaar. Net als voor extra SAS aansluitingen.

Wat mij betreft is dit gewoon dè oplossing voor storage. Niet moeilijk doen, geen NFS / iSCSI of SAN met meer functies. Lekker schijven als DAS verbinden met vSphere / Windows. Met meer dan 4 hosts pak je FC. Voeg extra diskcabinets toe voor meer opslag / spindles en plaats een identieke opstelling in een ander rek als het zo bedrijfskritisch is dat je een soort twin datacenter moet creeren. Je zit dan namelijk niet alleen aan redundante opslag maar dan wil je ook extra hosts als uitwijk op een andere locatie hebben draaien.

[ Voor 30% gewijzigd door Dysmael op 29-11-2015 20:30 ]

[Dennism]

Bigs schreef op zondag 29 november 2015 @ 20:18:
We hebben hier vorig jaar voor eenzelfde keuze gestaan. Ik had verwacht dat VSAN het op prijs zou winnen maar dat viel toch wel tegen. Bovendien was VSAN toen nog vrij nieuw wat ons toch heeft doen kiezen voor de bewezen FC oplossing (IBM Storwize V3700). Geen seconde spijt van gehad. De V3700 is trouwens ook met SAS of iSCSI aan te sluiten.

VSAN heeft natuurlijk wel vrij hoge licentie kosten waardoor de prijs alsnog vrij hoog is.

[Bigs]

Dennism schreef op zondag 29 november 2015 @ 20:25:
[...]


VSAN heeft natuurlijk wel vrij hoge licentie kosten waardoor de prijs alsnog vrij hoog is.

Inderdaad.. lastig als je moederbedrijf een grote 'traditionele' storage vendor is, dan kun je niet zomaar op prijs concurreren

[ro3lie]

Wim-Bart schreef op woensdag 11 november 2015 @ 16:28:
VSan is een mooie techniek, maar het is een hobby oplossing voor mijn gevoel.

Dit vind ik snel geroepen en klinkt voor mijn gevoel alsof je het niet eens hebt getest. Kan je dit verder onderbouwen?
VMware opent met vSAN de concurrentie met HW SAN providers. Een strijd waarin ik zelf verwacht dat vSAN dit ook op een dag gaat winnen.. meer decentralisatie, minder single point of failures t.o.v. een dedicated SAN.
VMware zal nu ook met iedere releases meer features toevoegen waarmee vSAN gelijk komt te staan met de features van een SAN + meer.

vSAN is in mijn ogen een product welke veel potentie bied en waar je nog veel van zal zien/horen.
Vergeet niet dat vSAN een opvolger is van VSA (VMware VSA). Deze is met de introductie van vSAN direct end of sales.

Side note:
Mocht iemand vSAN willen testen kan je dit zelf eenvoudig opzetten, zie hiervoor ook:
http://www.virtuallyghett...etup-and-test-vmware.html
Of kijk eens naar VMware HOL (Hands on Labs), dit zijn gratis labs welke een paar uur werken en waarin je bepaalde zaken kan testen.

hans_lenze schreef op donderdag 26 november 2015 @ 21:06:
[...]

Edit: VSAN heeft eigenlijk vSphere 6 nodig om lekker te werken en vSphere 6 en back-ups zijn op dit moment ehm.. laten we het maar sub-optimaal noemen
Zie ook http://kb.vmware.com/kb/2136854. Elke keer als ze een update uitbrengen om de CBT bug te pletten steekt er een nieuwe de kop op.

Dit ben ik niet met je eens, dit is volledig afhankelijk van jouw omgeving, back-up pakket en meerdere componenten.
Bij mijn werkgever is vSphere 6 i.c.m. Veeam al een aantal maanden actief, geen problemen met CBT.
Overigens kan de TS dit probleem ook krijgen met een fysieke SAN i.c.m. vSphere 6, dit staat los van je opmerking met vSAN.

hans_lenze schreef op zondag 29 november 2015 @ 10:42:
In de praktijk is een Synology of Qnap NAS goedkoper dan een "instap-SAN". Je krijgt waar je voor betaalt.

Klopt, echter mag je een Synology/QNAP NAS niet mag vergelijken met een (instap-)SAN.
Een SAN bied nog altijd functies die een NAS niet kan bieden. Ook volledig afhankelijk van je wensen en in welke omgeving je dit neerzet.

Yarisken schreef op zondag 29 november 2015 @ 11:25:
Kijk is naar netapp. Daar heb je san en nas samen. Eens je met nfs hebt gewerkt kan je dit echt niet meer missen.

Ik werk met meerdere storage oplossingen en zie niet waarom NFS boven alle andere storage protocollen staat (FC/iSCSI/vSAN/etc.)

Iedere storage oplossingen heeft zijn voor- en nadelen.
Als je NFS met iSCSI gaat vergelijken kom je er al zo een paar tegen. Daar waar iSCSI een hypervisor direct block level access biedt kan NFS dit niet. Om deze reden creeert VMware dan ook een lock file om de .vmdk files te locken.
Performance gericht kan een iSCSI storage ook nog eens communiceren met de hypervisor om bepaalde zaken te finetunen, dit biedt een NFS ook niet.
Algoed.. dit kan al gauw een eindeloze discussie worden over welke storage het wint van een ander.. Kijk naar wat aansluit bij je wensen/eisen en maak kijk wat hier bij past qua kosten/budget.
Los van het protocol heb je ook weer te maken met je controllers, schijven etc.. SATA, SAS 10K/15K, SSD, etc..

[ Voor 3% gewijzigd door ro3lie op 29-11-2015 23:16 ]

[Question Mark]

Yarisken schreef op zondag 29 november 2015 @ 16:55:
[...]
We gebruiken ook isci voor de windows servers en als ik daar een schijf wil vergroten, verkleinen of toevoegen dan ben ik daar toch altijd iets langer mee bezig.

Dat ligt aan je SAN... Bij een SAN met een goede VAAI implementatie, is dit met een paar klikken geregeld vanuit de Vsphere Management console. (inclusief lun uitbreiding op het SAN).

[Dennism]

Question Mark schreef op maandag 30 november 2015 @ 08:17:
[...]

Dat ligt aan je SAN... Bij een SAN met een goede VAAI implementatie, is dit met een paar klikken geregeld vanuit de Vsphere Management console. (inclusief lun uitbreiding op het SAN).

Ik verwacht dat hij andere handelingen bedoeld (daar hij aangeeft dat hij iscsi gebruikt op Windows servers), n.l. vergroten van de lun in het SAN management en daarna vergroten via de Gui c.q. Diskpart op de Windows server zelf.

Ik zie trouwens ook niet zo snel hoe VAAI het aantal handelingen in een VMware omgeving bij het vergroten van een bestaand volume in een Windows VM verkleind. Wij hebben hier ook VAAI ondersteuning, maar als ik een Windows disk moet vergroten in VMware moet ik nog steeds in de VM settings de VMDK vergroten en dan op de VM via diskpart of de Gui in Windows het volume vergroten. Dat gaat hier iig niet via de vSphere Management console (behalve het editten van de settings van de VM) of de San plugin (waarmee ik bijv. wel in een paar klikken nieuwe lun's e.d. kan uitrollen, snel kan clonen, of bijv. nieuwe VMDK's uitrollen e.d.). Tenzij jij uiteraard nog iets anders bedoeld.