SAN advies gevraagd

[MuadD1b]

Heren,

Ik, als storage leek, zoek advies bij het aanschaffen van een eigen SAN. Voordat ik me volgende week laat voorlichten door deskundigen (verkopers) ben ik benieuwd wat het advies van de tweakers is.

Wij hebben momenteel een cluster van 3 ESX 4.0 servers (Dell R710). Hierop draaien ongeveer 50 virtuele windows servers.We huren 2TB storage van ons datacenter. Deze 2TB spreken we aan via NFS over 1Gbps.
Dit is natuurlijk veel te traag voor onze 50 servers, dus zijn we op zoek naar een eigen oplossing.

Waar moet ik op letten? Welke technieken moet ik gaan gebruiken?
Mocht het niet genoeg informatie zijn dan hoor ik het graag.

Gr, Erik

[Verwijderd]

Volgende keer zelf ff moeite doen he!

http://www.vmware.com/resources/techresources/583
http://www.vmware.com/resources/techresources/cat/91%2C123/

[leon1e]

Begin eerst maar eens met een meting van het aantal iops , en vraag je eens af welke vorm van redurantie je nodig hebt dubbele controllers, redurante switches etc. Hoezo is de 1Gbps een probleem, is NFS niet de bottleneck, of toch het aantal iops?

[MuadD1b]

Momenteel zitten we op 450 write iops.
Maar goed, de servers worden nu niet echt gebruikt. Ik zal morgen overdag eens kijken wat het zaakje doet.
Controllers en switches moeten eigenlijk redundant zijn. Maar dat zal een beetje afhangen van het prijskaartje

[The Eagle]

MuadD1b schreef op maandag 07 februari 2011 @ 21:30:
Momenteel zitten we op 450 write iops.
Maar goed, de servers worden nu niet echt gebruikt. Ik zal morgen overdag eens kijken wat het zaakje doet.
Controllers en switches moeten eigenlijk redundant zijn. Maar dat zal een beetje afhangen van het prijskaartje

Goedkoop is duurkoop in dit geval. Hou er rekening mee dat je SAN je SPOF wordt. Het datacenter waar je de boel van huurt zal dit ongetwijfeld ondervangen hebben. Die zitten niet op klagende klanten te wachten als er iets uitvalt, dus daar zal zeker redundantie aanwezig zijn.
Ik denk dat je voor jezelf goed moet beslissen of en zo ja wat er evt uit mag vallen en hoeveel je bereid bent voor die zekerheid te betalen. Als je 50 servers hebt (virtueel of niet) dan heb je OF een flink aantal klanten, OF een flink aantal gebruikers die van de bakken afhankelijk zijn. Either way: als jij een hoop (50+ ofzo) gebruikers een uur niet laat werken dan kost dat klauwen met geld. Kun je je klanten een uur niet servicen dan kost je dat ook een hoop geld (SLA anyone ).
Bovendien: als je SAN het SPOF is ben je zelf ook de dupe als het ding onderuit knalt. Ga dus iig niet (zoals mijn werkgever doet ) met blades werken die compleet afhankelijk van SAN disks zijn, maar zorg dat je OS of hypervisor lokaal staat op je fysieke bakken. Scheelt je een hoop ellende

[MuadD1b]

Helemaal mee eens. We moeten de uptime ook kunnen garanderen.
We werken echter met vmotion dus storage op de fysieke esx'en is dan (volgens mij) geen optie.

[The Eagle]

Ik ken VMware niet genoeg om daar een oordeel over te vellen, maar als het een cluster betreft wil je iig zorgen dat je Hypervisor software niet ook nog eens op de SAN disks draait.

Bij mijn weten (correct me if I'm wrong ) is Vmotion niks anders dan een techniek om een virtuele server van de ene naar de andere fysieke host machine te kopieren bij bijvoorbeeld gebrek aan resources. Da's leuk en aardig, maar als je SAN klapt, klapt (als je je ESX hypervisor op je SAN hebt draaien) dan dus ook je host machine. En dat wil je nou net voorkomen met Vmotion
Dus als het effe kan je ESX install op schijven die iig los van je SAN staan (hotswap Raid1 of R5 doet het voor een bootdisk iig prima, hoeft niet eens zo snel te zijn).

[Verwijderd]

Vmware kan je natuurlijk ook van USB stick draaien als je echt geen disken in je hosts wil.
Wij gebruiken zelf Lefthand over iSCSI voor onze ESX servers (HP blades) moet zeggen, een heel mooie oplossing voor ons en betaalbaar.

[johnkeates]

iSCSI of desnoods AoE met wat layers is een heel stuk beter dan NFS. Maar goed, zoals eerder gezegd, kijk eerst naar wat je nodig hebt qua performance, je moet weten waar je naar moet zoeken. Kijk dan naar redundantie, want je hebt niks aan een systeem dat je niet 'oneindig' kan draaien.

Mocht je vmware niet diskless kunnen gebruiken, dan kan je altijd nog Xen nemen, die kan dat wel, en heeft de zelfde functies (plus meer speed).

[ Voor 20% gewijzigd door johnkeates op 07-02-2011 22:46 ]

[EdwinW]

The Eagle schreef op maandag 07 februari 2011 @ 21:53:
[...]
Bovendien: als je SAN het SPOF is ben je zelf ook de dupe als het ding onderuit knalt. Ga dus iig niet (zoals mijn werkgever doet ) met blades werken die compleet afhankelijk van SAN disks zijn, maar zorg dat je OS of hypervisor lokaal staat op je fysieke bakken. Scheelt je een hoop ellende

Als je ellende krijgt doordat er iets van een SAN kapot gaat, is er bij dat ontwerp dus iets grondig mis gegaan. Alles van een SAN moet dubbel uitgevoerd zijn, zelfs replicatie naar een remote locatie behoort tot de mogelijkheden. Als bedrijven geld gaan besparen op redundantie, .... tja.

[Dysmael]

Kijk eens naar bv Equallogic. PS4000E bijvoorbeeld. Net als uiteraard bij vele andere SAN's is alles redundant. Twee voedingen, twee controllers en uiteraard de schijven in RAID. Support van Dell is zeer goed. Twee fatsoenlijke Cisco switches ernaast en je hebt een bloedsnel en stabiel SAN. Als prijzen lastig te vinden zijn kan ik ze wel bij Dell opvragen voor je.

Lokale storage is inderdaad een no-go bij vSphere als je van vMotion/HA gebruik wil maken.

[DGTL_Magician]

johnkeates schreef op maandag 07 februari 2011 @ 22:45:
iSCSI of desnoods AoE met wat layers is een heel stuk beter dan NFS. Maar goed, zoals eerder gezegd, kijk eerst naar wat je nodig hebt qua performance, je moet weten waar je naar moet zoeken. Kijk dan naar redundantie, want je hebt niks aan een systeem dat je niet 'oneindig' kan draaien.

Mocht je vmware niet diskless kunnen gebruiken, dan kan je altijd nog Xen nemen, die kan dat wel, en heeft de zelfde functies (plus meer speed).

Dat kun je niet zomaar 123 zeggen natuurlijk. Een NFS oplossing kan ook prima performen. Wij werken vooral veel met NetApp SAN's. Deze kunnen zowel NFS als FC en iSCSI en in veel gevallen is NFS een prima oplossing.

Heb je eigenlijk grafieken van de bandbreedte die het SAN op dit moment gebruikt?

[SpamLame]

Zoals anderen al aangaven hoeft NFS niet per definitie slecht te performen.
Performance is ook afhankelijk van cache, aantal spindels, type disk, connectivity front- and backend etc.
Weet je hoe die NAS in elkaar steekt?

Je zegt dat je 2Tb ruimte op een NAS hebt gehuurt.
Zijn er destijds afspraken gemaakt over performance etc?

[Keiichi]

Wat is het budget.

Met genoeg geld zijn er hele mooie oplossingen te maken

Wat vind je trouwens van een QNAP appliance? Niet duur, goede performance (wat ik gelezen heb) en ook feature rich.

[SpamLame]

The Eagle schreef op maandag 07 februari 2011 @ 22:35:
Ik ken VMware niet genoeg om daar een oordeel over te vellen, maar als het een cluster betreft wil je iig zorgen dat je Hypervisor software niet ook nog eens op de SAN disks draait.

Bij mijn weten (correct me if I'm wrong ) is Vmotion niks anders dan een techniek om een virtuele server van de ene naar de andere fysieke host machine te kopieren bij bijvoorbeeld gebrek aan resources. Da's leuk en aardig, maar als je SAN klapt, klapt (als je je ESX hypervisor op je SAN hebt draaien) dan dus ook je host machine. En dat wil je nou net voorkomen met Vmotion
Dus als het effe kan je ESX install op schijven die iig los van je SAN staan (hotswap Raid1 of R5 doet het voor een bootdisk iig prima, hoeft niet eens zo snel te zijn).

Voor local boot als SAN boot van ESX valt wat te zeggen, maar vMotion gaat je guests niet helpen als de datastores onbereikbaar zijn omdat je Storage onderuit is gegaan.
Wil je dat voorkomen dan zal je bv. op Storage nivo moeten repliceren icm Site recovery manager.

vMotion kan je guest overzetten naar een andere ESX bak voor onderhoud of iets dergelijks.
Indien je HA hebt wordt een guest middels vMotion overgebracht naar een andere ESX host indien de oorspronkelijke host onderuit gaat.

[RvV]

Inderdaad eerst kijken waar het nu precies op stuk loopt. Zelf heb ik met 10Gbit NFS gewerkt en dat werkte echt waardeloos op een EMC icm vmware. (hoewel er ook zat omgevingen blijken te zijn waarbij dit wel prima werkt) Er zijn veel meer belangrijkere zaken dan alleen de bandbreedte. Je kunt 100Gbit bandbreedte hebben maar als je uiteindelijk op 25 SATA spindles van 5400rpm zit...dan weet je het wel..

Ik heb ook met 1Gbit iSCSI gewerkt. Dat loopt over het algemeen prima. Lekker goedkoop in te richten op bestaande omgevingen. En 1Gbit trek je niet eens zo heel snel vol met algemeen gebruik.

En op dit moment werk ik veel met een 4Gbit FC omgeving. Loopt net een tikje vlotter dan iSCSI maar is uiteraard ook duurder. Overdag kom ik met +-75 windows VM's niet boven de 25MB/s uit. 's-Avonds loopt dit op naar ongeveer 250MB/s tijdens de backups.

Ik zou dus eerder een iSCSI omgeving verkiezen boven NFS, en als geld geen rol speelt en je het uiterste aan performance moet behalen, dan FC.

[leon1e]

MuadD1b schreef op maandag 07 februari 2011 @ 21:30:
Momenteel zitten we op 450 write iops.
Maar goed, de servers worden nu niet echt gebruikt. Ik zal morgen overdag eens kijken wat het zaakje doet.
Controllers en switches moeten eigenlijk redundant zijn. Maar dat zal een beetje afhangen van het prijskaartje

Dat is niet zo heftig , en over een periode van 24 uur? Hoe is je verhouding read/write, waar zitten je pieken, hoeveel mb heeft hij verwerkt? Zit je bij een piek echt tegen de max. van je verbinding? Ik neem aan dat de jongens van het datacenter ook wel stats hebben van jullie gedeelte van het san, die kun je dan mooi vergelijken.

[MuadD1b]

Ik heb gedetailleerde info opgevraagd bij ons datacenter.
Even afwachten

[Bastiaan V]

The Eagle schreef op maandag 07 februari 2011 @ 21:53:
[...]

Goedkoop is duurkoop in dit geval. Hou er rekening mee dat je SAN je SPOF wordt. Het datacenter waar je de boel van huurt zal dit ongetwijfeld ondervangen hebben. Die zitten niet op klagende klanten te wachten als er iets uitvalt, dus daar zal zeker redundantie aanwezig zijn.
Ik denk dat je voor jezelf goed moet beslissen of en zo ja wat er evt uit mag vallen en hoeveel je bereid bent voor die zekerheid te betalen. Als je 50 servers hebt (virtueel of niet) dan heb je OF een flink aantal klanten, OF een flink aantal gebruikers die van de bakken afhankelijk zijn. Either way: als jij een hoop (50+ ofzo) gebruikers een uur niet laat werken dan kost dat klauwen met geld. Kun je je klanten een uur niet servicen dan kost je dat ook een hoop geld (SLA anyone ).
Bovendien: als je SAN het SPOF is ben je zelf ook de dupe als het ding onderuit knalt. Ga dus iig niet (zoals mijn werkgever doet ) met blades werken die compleet afhankelijk van SAN disks zijn, maar zorg dat je OS of hypervisor lokaal staat op je fysieke bakken. Scheelt je een hoop ellende

Mag ik vragen waarom deze waarschuwing?
Wat heb je precies aan een server welke wel een hypervisor heeft, maar niet bij de VM's kan komen?
Wij zijn juist de andere kant op aan het migreren, ideaal om bij het toevoegen van een server/blade enkel de lun te clonen, en in een paar minuten VM's te kunnen migreren.

[DGTL_Magician]

Keiichi schreef op dinsdag 08 februari 2011 @ 10:00:
Wat is het budget.

Met genoeg geld zijn er hele mooie oplossingen te maken

Wat vind je trouwens van een QNAP appliance? Niet duur, goede performance (wat ik gelezen heb) en ook feature rich.

Een QNAP performed echt niet voor dit soort oplossingen. Leuk voor thuis of een test omgeving, maar in een productie omgeving hoort het echt niet thuis.

[Bjornmeijer935]

Bastiaan V schreef op dinsdag 08 februari 2011 @ 13:07:
[...]


Mag ik vragen waarom deze waarschuwing?
Wat heb je precies aan een server welke wel een hypervisor heeft, maar niet bij de VM's kan komen?
Wij zijn juist de andere kant op aan het migreren, ideaal om bij het toevoegen van een server/blade enkel de lun te clonen, en in een paar minuten VM's te kunnen migreren.

Waarom koppel je niet gewoon meerdere servers in een pool aan 1 lun, dit lijkt mij een stuk makkelijker dan iedere keer een lun klonen om dan vervolgens de zelfde dingen te gaan draaien, dit is een stuk efficienter en bespaart een hoop ruimte. Dell heeft hier opzich wel een goede oplossing voor en de prijs is ook wel redelijk gunstig t.o.v. de concurrentie.

Misschien begrijp ik je gewoon verkeerd maar just my 2 cents.

[SpamLame]

Bjornmeijer935 schreef op dinsdag 08 februari 2011 @ 13:56:
[...]


Waarom koppel je niet gewoon meerdere servers in een pool aan 1 lun, dit lijkt mij een stuk makkelijker dan iedere keer een lun klonen om dan vervolgens de zelfde dingen te gaan draaien, dit is een stuk efficienter en bespaart een hoop ruimte. Dell heeft hier opzich wel een goede oplossing voor en de prijs is ook wel redelijk gunstig t.o.v. de concurrentie.

Misschien begrijp ik je gewoon verkeerd maar just my 2 cents.

Dat doe je niet als boot lun, tenzij (o)vms, waar we het hier over hebben.
Daarnaast zijn bootluns van ESX dermate dat het weinig winst op zou leveren
De datastores zijn in de regel toegankelijk voor je hele ESX cluster.

[Keiichi]

DGTL_Magician schreef op dinsdag 08 februari 2011 @ 13:30:
[...]

Een QNAP performed echt niet voor dit soort oplossingen. Leuk voor thuis of een test omgeving, maar in een productie omgeving hoort het echt niet thuis.

In welke mate zou een Qnap server anders performen dan zo'n Dell Equallogic? Zo'n Qnap draait wellicht software raid, waar de equallogic hardware raid heeft, maar hoeveel gaat dat uitmaken voor een bak die enkel en alleen data serveert?

Ik heb thuis zelf een kleine NAS gebouwd welke de gbit verbinding er ruim uit serveert. (Met een oude xeon 2.0ghz) Zelfs al zou ik de 2 adapters op het moederbord bundelen, dan zou de verbinding nog de bottleneck zijn. Ik ga er voor de makkelijkheid van uit dat de dual core atom's die gebruikt worden, minstens zo snel zijn als oude xeons.

[RvV]

Ik denk dat een zelfbouw server goed kan performen als je niet al te veel zware VM's draait. Als je richting de 50-75 wat zwaardere VM's toe groeit, dan gaan 10-20 schijven het echt niet meer redden. (hoeveel passen er in een QNAP?) Denk aan de iops en niet alleen bandbreedte.
Daarnaast is het in een produktie omgeving belangrijk dat je iemand kunt bellen die je apparaat komt repareren als er iets mis mee is. Afhankelijk van hoe kritisch je omgeving is, moet je kijken wat voor support je erop wilt hebben. Ik zou niet graag een paar dagen zonder serverpark zitten omdat mn webshop een nieuwe QNAP moet bestellen bij de leverancier.

[Bigs]

Ik zou eens contact opnemen met je Dell account manager. Dell heeft hun eigen aantrekkelijk geprijsde MD storage arrays en als je wat zwaarders/flexibelers moet hebben ze hun Equalogic systemen. Wij hebben destijds iemand op bezoek gehad die het e.e.a. uit heeft gelegd en heeft geholpen met het meten van IOPS e.d. Erg waardevol als je niet thuis bent in de materie.

Wij hebben ook getwijfeld tussen een eigen iSCSI SAN en iSCSI storage afnemen van het datacenter en dat eerste bleek een stuk goedkoper te zijn (met prima performance voor ons). Bovendien hebben we nu redundante controllers en multipath (4x1Gbit verdeeld over 2 switches) wat we anders niet hadden gehad.

[SpamLame]

Bigs schreef op dinsdag 08 februari 2011 @ 15:35:
Ik zou eens contact opnemen met je Dell account manager. Dell heeft hun eigen aantrekkelijk geprijsde MD storage arrays en als je wat zwaarders/flexibelers moet hebben ze hun Equalogic systemen. Wij hebben destijds iemand op bezoek gehad die het e.e.a. uit heeft gelegd en heeft geholpen met het meten van IOPS e.d. Erg waardevol als je niet thuis bent in de materie.

Wij hebben ook getwijfeld tussen een eigen iSCSI SAN en iSCSI storage afnemen van het datacenter en dat eerste bleek een stuk goedkoper te zijn (met prima performance voor ons). Bovendien hebben we nu redundante controllers en multipath (4x1Gbit verdeeld over 2 switches) wat we anders niet hadden gehad.

Kijk niet alleen naar Dell, maar laat je ook een voorlichten door andere vendors.
HP heeft intressante spullen.
Compellent (nu dus Dell) heeft leuke oplossingen.
NetApp doet meen ik ook aan iSCSI, zou je die richting op willen gaan.
Nexsan
Als je zelfbouw wilt doen dan kan je ook kijken naar openfiller.

Houd er daarnaast rekening mee dat een dtorage omgeving wat langer blijft staan dan gemiddelde x86 server.
Ander gezegd kijk wat verder vooruit.

[leuk_he]

Keiichi schreef op dinsdag 08 februari 2011 @ 15:04:
[...]
In welke mate zou een Qnap server anders performen dan zo'n Dell Equallogic? Zo'n Qnap draait wellicht software raid, waar de equallogic hardware raid heeft, maar hoeveel gaat dat uitmaken voor een bak die enkel en alleen data serveert?

Volgens mij wordt je SAN (of dat nou die QNAP of de DELL middenklasser auto wordt) je shared storage en dus je single point of failure. Maar VMotion suggereert automatisch een shared storage oplossing (toch).

Dan heb je liever een goede of een reduanate oplossing hiervoor. Hoe? geen idee, maar zelf heb ik het idee dat 2 QNAP(of veel meer) meer reduantie mogelijkheden hebben dan 1 dell. Verder is het een kwestie van geld.

[Jazzy]

Voor bijna iedereen zal een redundant uitgevoerd SAN betrouwbaar genoeg zijn en niet snel als zwakke plek worden gezien. Maar ik heb een klant die erg argwanend tegenover een SAN staat omdat ze stevige problemen hebben gehad met hun SAN. Dat was een nette enterprise oplossing van een A-merk leverancier, maar toch...

Uiteindelijk is een SAN een SPOF en als je dat echt niet wilt dan heb je er twee nodig.

Interessant topic trouwens.

[ Voor 4% gewijzigd door Jazzy op 08-02-2011 16:04 ]

[Gardocki]

leuk_he schreef op dinsdag 08 februari 2011 @ 16:00:
[...]


Volgens mij wordt je SAN (of dat nou die QNAP of de DELL middenklasser auto wordt) je shared storage en dus je single point of failure. Maar VMotion suggereert automatisch een shared storage oplossing (toch).

Een "echte" SAN geen single point of failure, behalve bij brand bijvoorbeeld. Alles is dan redundant uitgevoerd. Disks, storage processors, stroomvoorziening, etc.

En vMotion heeft verder niks te maken met shared storage. Behalve dat shared storage een voorwaarde is om vMotion mogelijk te maken.

[Jazzy]

Gardocki schreef op dinsdag 08 februari 2011 @ 16:06:
[...]

Een "echte" SAN geen single point of failure, behalve bij brand bijvoorbeeld. Alles is dan redundant uitgevoerd. Disks, storage processors, stroomvoorziening, etc.

Een SAN is wel een SPOF, denk maar aan configuratiefouten of bijvoorbeeld enkelvoudig uitgevoerde onderdelen als een backplane.

[Bigs]

leuk_he schreef op dinsdag 08 februari 2011 @ 16:00:
[...]


Volgens mij wordt je SAN (of dat nou die QNAP of de DELL middenklasser auto wordt) je shared storage en dus je single point of failure. Maar VMotion suggereert automatisch een shared storage oplossing (toch).

Dan heb je liever een goede of een reduanate oplossing hiervoor. Hoe? geen idee, maar zelf heb ik het idee dat 2 QNAP(of veel meer) meer reduantie mogelijkheden hebben dan 1 dell. Verder is het een kwestie van geld.

Ik betwijfel of een oplossing met 2 losse QNAP systemen betrouwbaarder is dan een oplossing met een enkel, redundant uitgevoerd 'A-merk' SAN. Het enige onderdeel wat je niet kan vervangen is het backplane. Verder is alles redundant en hot swappable. Voordeel is dat je je geen zorgen hoeft te maken over mirroring en failover wat je bij die eerste wel moet.

Overigens zou ik sowieso nooit consumentenhardware gebruiken voor een servertoepassing

[ Voor 6% gewijzigd door Bigs op 08-02-2011 16:34 . Reden: aangepast ]

[Gardocki]

Jazzy schreef op dinsdag 08 februari 2011 @ 16:11:
[...]
Een SAN is wel een SPOF, denk maar aan configuratiefouten of bijvoorbeeld enkelvoudig uitgevoerde onderdelen als een backplane.

Dan zijn 2 SAN's aan elkaar geknoopt met een site recovery manager ook een SPOF. Aangezien je daar ook configuratiefouten mee kan maken Maar afgezien van mensen die een SPOF vormen, zou een goede SAN op hardware niveau geen single point of failure mogen hebben.

"A good SAN implementation will have built-in protection against just about any kind of failure imaginable. As we will see in later chapters, this means that not only must the links and switches composing the SAN infrastructure be able to survive component failures, but the storage devices, their interfaces to the SAN, and the computers themselves must all have built-in strategies for surviving and recovering from failures as well."

[DrFlash]

Bigs schreef op dinsdag 08 februari 2011 @ 16:17:
[...]
Het enige wat bij dat laatste namelijk problemen op kan leveren is het backplane. Verder is alles redundant en hot swappable.

Zelfs dat niet eens. ik ben hier de gelukkige die mag spelen met een stretched metro cluster op basis van Netapp hardware waarbij alle shelfs redudant zijn aangesloten op beide heads en de heads in active/active failover staan. maakt dus niet uit of er een hele shellf of een hele head uitvalt, alles blijft doordraaien. zelfs de switches zijn aan beide kanten redundant uitgevoerd dus hier mag 1 vd 2 server ruimtes volledig uitvallen zonder dat we er last van hebben.

tis qua aanschaf dan wel weer heel duur en ook de prijs/gb van de disken schiet omhoog aangezien je buiten het standaard raid 'verlies' van diskruimte nog extra verliest omdat je alles dubbel moet kopen.

[Bigs]

DrFlash schreef op dinsdag 08 februari 2011 @ 16:25:
[...]


Zelfs dat niet eens. ik ben hier de gelukkige die mag spelen met een stretched metro cluster op basis van Netapp hardware waarbij alle shelfs redudant zijn aangesloten op beide heads en de heads in active/active failover staan. maakt dus niet uit of er een hele shellf of een hele head uitvalt, alles blijft doordraaien. zelfs de switches zijn aan beide kanten redundant uitgevoerd dus hier mag 1 vd 2 server ruimtes volledig uitvallen zonder dat we er last van hebben.

tis qua aanschaf dan wel weer heel duur en ook de prijs/gb van de disken schiet omhoog aangezien je buiten het standaard raid 'verlies' van diskruimte nog extra verliest omdat je alles dubbel moet kopen.

Hmja ik had ook eigenlijk moeten zeggen 'het enige wat je niet kan vervangen' in plaats van 'het enige dat problemen op kan leveren'.

[erwinb]

net als DrFlash schreef, een NetApp storage omgeving is het beste wat je met VMware kan gaan gebruiken.
Zelf ben ik een groot fan van het NFS protocol als storage protocol voor VMware.
Bij een NetApp doen de filers de afhandeling van het filesystem bij gebruik van NFS. Als je de keuze maakt voor iSCSI dan zijn de ESX servers bezig met het afhandelen van het VMware clustered storage protocol (VMFS) waarbij je, afhankelijk van de belasting, 10 á 20% van de ESX CPU cycles verstookt aan VMFS. Bij gebruik van NFS kan de de dure ESX hosts en ESX licenties gebruiken waar ze voor zijn, het draaien van VM's.
En een reactie op EMC met NFS, dat is ook een weg die je niet wil bewandelen, dan krijg je een CX4-XXX met DART wat een FC lun uitserveerd naar de daarboven gelegen datamover/XBlade met FLAIR wat daar weer een NFS share van maakt. Dergelijke stacks zijn gedoemd een matige performance te leveren.

P.S.
Ik werk net voor NetApp, maar ben storage consultant en werk graag met NetApp.

Nog een voordeel van NetApp, Deduplicatie.....
Als alle VM's een beetje op elkaar lijken dan zijn alle "C" disken redelijk gelijk aan elkaar, met NetApp DeDupe zullen alle gelijke datablocken worden geelimineerd. Er zijn VMware omgevingen waarbij dit een storage besparing opleverd van wel 80%. Dan wordt duur ineens goedkoop.

[MuadD1b]

Deduplicatie is inderdaad een echte pre.

[SpamLame]

Een SAN kan een SPOF als n(o)SPOF zijn.

Denk dat het belangrijk is het onderscheid te maken in de daadwerkelijke opslag (Storage Array) en de interconnects (Storage Area Network). Ik kom vaak tegen dat zowel de opslag als interconnects onder de noemer SAN gevat worden. En ik denk dat ook een beetje te proeven in een aantal reacties boven mij.

Je SAN is de netwerk/transport laag waar je data over gaat maar feitelijk niet opgeslagen worden.
De Storage Array is waar de dat huist.

Nu het onderscheid er is, is ook gelijk duidelijk dat er twee zaken zijn als het op beschikbaarheid van de dienstverlening aankomt vanuit het oogpunt van de servers gezien.
1)Toegang tot de data, het netwerk dus > SAN
2)Aanwezigheid van data, de opslag > Storage Array

Wil je beide punten aanpakken dan zal je,naast de interne redundantie in de afzonderlijke componenten,
meerdere Storage array met replicatie willen
en een redundant SAN willen.

Meerdere Storage Array's en replicatie is makkelijk te visualiseren.
Een redundant SAN maak je door twee fabrics (sub netwerken die fysiek gescheiden en onafhankelijk in configuratie van elkaar zijn) op te bouwen. Je hosts en storage worden aan beide fabrics aangesloten.
Hoe dat precies in elkaar steekt verwijs ik je graag naar een al wat ouder maar nog steeds toepasbaar document > http://www.filibeto.org/s...brocade/53-0000231-05.pdf
Uitgangpunt is hier FCP over FC, maar evengoed toepasbaar op FC(P) over Ethernet, FCIP, iSCSI etc.

[RvV]

Om nog even terug te komen op het de-dup verhaal..

Een jaar of wat geleden kon netapp dat al, alleen was het toen ook niet alles in een virtuele omgeving. Er zouden zogenaamde hotspots optreden op bepaalde schijven omdat 1 bestand op 1 plek door heel veel VM's tegelijk werd aangesproken. Is dit al opgelost? Ik zag dat EMC ook zoiets heeft zitten op de Celerra maar mede door dat verhaal vond ik het een beetje eng om te gaan gebruiken.

[EdwinW]

erwinb schreef op dinsdag 08 februari 2011 @ 19:18:
Als je de keuze maakt voor iSCSI dan zijn de ESX servers bezig met het afhandelen van het VMware clustered storage protocol (VMFS) waarbij je, afhankelijk van de belasting, 10 á 20% van de ESX CPU cycles verstookt aan VMFS.

iSCSI off-loading op de netwerkkaart ?

[Bor]

erwinb schreef op dinsdag 08 februari 2011 @ 19:18:
net als DrFlash schreef, een NetApp storage omgeving is het beste wat je met VMware kan gaan gebruiken.

Ik ben benieuwd naar de argumentatie daar je imho net zo goed of beter kunt gaan voor EMC en het SAN op basis van fibre kunt koppelen. Kwaliteit, betrouwbaar, schaalbaar, proven technology en van dezelfde firma achter VMware. NFS is leuk maar als je het geld kunt missen is Fibre interessanter imho.

[ Voor 66% gewijzigd door Bor op 08-02-2011 22:12 ]

[erwinb]

@ EdwinW
iSCSI of IP offloading is een must. zowel iSCSI als NFS heeft daar een voordeel van.
Wat ik bedoel met het verstoken van CPU cycles heeft te maken met het afhandelen van VMFS. VMFS is een clustered file systeem waarvan de afhandeling door de ESX host wordt gedaan. Bij gebruik van NFS gebruik laat je het storage systeem het filesysteem afhandelen.

@ Bor de Wollef
met een FC storage systeem kan je meestal geen deduplicatie doen. met een file based protocol gaat dat een stuk eenvoudiger.
NFS is ook betrouwbaar, schaalbaar en zeker ook proven. NetApp doet al NFS vanaf ongeveer 1992.
Ik denk dat geld niet een issue is. een IP / NFS storage systeem met goede switches zal waarschijnlijk een vergelijkbare prijs hebben als een FC san.

[Aragnut]

Domme vraag mischien, maar biedt de hosting provider geen alternatieve storage? Ik denk dat als je tegen problemen aanloopt met de storage die ze nu leveren, je ook tegen problemen aanloopt als je dezelfde techniek zelf neer gaat zetten, tenzij je het veel duurder maakt. uiteraard kan je dan je eigen storage array en san netwerk gaan opbouwen, maar als dit er al ligt en gehuurd kan worden denk ik dat je dat beter kan gebruiken. Dan heb je de SLA plicht meteen bij het datacenter liggen en niet bij jezelf.

[leuk_he]

Gardocki schreef op dinsdag 08 februari 2011 @ 16:06:
[...]

Een "echte" SAN geen single point of failure, behalve bij brand bijvoorbeeld. Alles is dan redundant uitgevoerd. Disks, storage processors, stroomvoorziening, etc.

Je moet bij zo´n echte SAN ook investeren in kennisopbouw. Even een SAN neerzetten en er van uit gaan dat het voor dat bedrag automatisch zou gaan is een grote verspilling. Je krijgt dan niet de uptime en performance die zo´n san zou kunnen leveren.

Een aantal qnap apparaten zit wel een een klasse lager, maar ook een prijsklasse lager, Je hebt het gewoon ergens anders over.

Merk op dat je backup verhaal in beide gevallen gewoon nodig blijft, aan gezien een reduanante storage geen oplossing bied voor `gebruikersfouten`.

[Bl@ckbird]

Datacenter Networking kan je op verschillende manieren doen.

iSCSI
Hier heb je netwerkkaarten voor met iSCSI off-loading, zodat de CPU van de server hier geen CPU cycles voor verbruikt. Wat betreft switching kan je hier een standaard 2960S (L2) of 3560X / 3750X switch (L2/L3, afhankelijk van de IOS licentie) voor nemen, mits het niet al te data-intensief is. Bepaalde modellen van de 2960S kan je stacken. (20 Gbps) Ook de 3750X kan je stacken, (maar nu op de backplane @ 64 Gbps) wat handig is bij een groter SAN.

Voor data-intensievere iSCSI SAN's heeft Cisco de 4900 Data Center switches. De latency van deze switches is lager (6 microsecondes) dan bij normale switches. 4900 switches hebben ook grotere shared buffers. ( 16MB of 17.5MB voor de hele switch, t.o.v. 180kb per poort bij normale 3560 switches.) Lage latency en grote buffers zijn handig als je grote blokken data wil switchen.

Fibre Channel / Ethernet
Voor normaal netwerkverkeer is de server voorzien van een gigabit link. (Een gebundelde gigabit link als 2 Gbps throughput wil hebben. En 2x 2 Gigabit links, als je redundant gebundelde gigabit links wil hebben.) Eventueel is er nog een gigabit link voor je vMotion.

Voor je SAN stuk heb je in je server HBA's nodig. (Emulex / Qlogic) Daarnaast heb je een Fibre Channel switch nodig. Bijvoorbeeld van Brocade of Cisco MDS serie. Bij Cisco is de MDS 9100 de instap versie. De MDS 9222i is een stap hoger en deze kan ook services aan. (Zoals on-the-fly data encryptie en het kopieëren / clonen van data van SAN array A naar B, of van host naar SAN array A en B.)

FCoE / "Unified Fabric"
Je kan servers ook voorzien van Converged Network Adapters. (CNA's)
Dit zijn 10Gbps netwerk adapters waar men FC over doet. (Fibre Channel over Ethernet, FCoE)
Dit is wel een lossless variant van Ethernet. (DCE)

In tegenstelling tot het Fibre Channel / Ethernet voorbeeld, is de server bij FCoE maar voorzien van 2 poorten, die Fibre Channel over 10Gpbs Ethernet doen. Vooral bij grote aantallen servers scheelt dit veel kabels. (Die niet gelabeld, beheerd worden en stroom vragen.) Hoeveel bandbreedte van die 10Gbps kan je toewijzen aan FC of Ethernet. Voor het OS / ESXi lijkt het alsof je 2 ethernet adapters hebt en 2 HBA's.

Je hebt hiervoor CNA's voor nodig van bijvoorbeeld Emulex / Qlogic. Daarnaast heb je een Nexus 5000 nodig, die FCoE kan switchen. De Nexus 5000 is een L2 apparaat, de Nexus 5500 is een L3 apparaat.

Cisco zelf heeft nog een Virtual Interface Card waarmee je 56 virtuele interfaces hebt die je kan toewijzen aan individuele VM's binnen VMWare. (De hardware kan 128 virtuele interfaces aan, maar dit wordt nog verder ontwikkeld.) De Cisco VIC's zijn echter alleen beschikbaar voor hun UCS rack-mounted en blade servers.

Een software variant is er in de vorm van de Nexus 1000v. Dit is een distributed virtuele switch, die men binnen VMWare kan draaien. (Draait gewoon NX-OS, van de Nexus en MDS serie switches.) In de Nexus 1000v maak je een profiel aan. (Bijvoorbeeld "webserver" met ACL's op de virtuele netwerk interface, VLAN's en andere instellingen.) De beheerder van VMWare kan dit profiel via een drop-down menu toewijzen aan een VM. Doe je nu een VMotion, dan verhuist dit profiel (met alle instellingen) van ESXi host A naar B. Ook Ethernet counters blijven gewoon doorlopen. Je hebt goede scheiding van policies tussen VM's en tussen netwerkbeheerders en beheerders van de VMware omgeving. En het virtuele gedeelte van het netwerk is eenvoudiger te beheerden, vooral als je veel VM's hebt. Verder is er voor vCenter een plug-in, waarmee je vanuit vCenter een Cisco ACE load balancer kan beheren. VM je worden aangemaak worden zo automatisch opgenomen in de pool van virtuele servers op de load balancer.

Meestal werk je met een SAN Array A en een SAN Array B. (Die zich bij voorkeur in een ander datacenter bevindt.) Voor backup van je SAN kan je eventueel naar een cloud oplossing kijken. Riverbed heeft hier de Whitewater appliance voor. Data verkeer tussen het SAN en de cloud wordt gecached en, voordat het via het internet verzonden, wordt zwaar geoptimaliseerd en encrypt. Riverbed Whitewater kan je gebruiken in combinatie met Amazon S3 en EMC Atmos.

Cisco heeft voor hun data en storage networking uitgebreide Validated Designs. Ze werken nauw samen met EMC, VMWare en NetApp. Met EMC hebben ze vBlocks en met NetApp hebben ze Flexpods. Dit zijn uitgebreid geteste building blocks wat bestaat uit een stukje networking, storage networking, storage, computing en virtualisatie. Ook Cisco's TAC support organisatie is ingericht om deze building blocks te ondersteunen.

Als het niet al te data intensief is kan je prima uit de voeten met iSCSI. (Aangezien je maar 3 ESXi hosts hebt.) Wil je meer performance kijk dan naar FC of FCoE. De vraag is wat je in de toekomst wil doen. Wil je ontzettend meer VM's gaan draaien? (Virtuele servers of VDI omgeving.) Wil je VM's geautomatiseerd provisionen als een soort cloud service? Welke eisen stel je aan security? (Policy control en virtualisatie van je netwerk worden dan belangrijk.) Dit stelt allemaal eisen aan je storage array en je netwerk.

[Flyduck]

Ik ben ook op zoek naar een SAN ter vervanging van de huidige (zeer slecht presterende!) MSA 2012fc.
Ondanks de vele SAS 15k disks zakt de performance op drukke dagen tot onder de 40 IOPS per VM (crystal disk mark, random writes 4k. IOMeter heb ik zelfs een keer moeten stoppen omdat het te lang duurde voordat het testbestand van 4GB was aangemaakt)

Ik wil graag naar ISCSI (equallogic via ISCSI HBA's) maar door de vele meningen op internet raak ik steeds minder overtuigd.
We hebben zeer snelle access times nodig (hosted desktops op 15 terminal servers) naast Exchange en SQL met grote OLTP databases.

Door de slechte performance van de huidige MSA zijn de SQL en Exchange momenteel fysiek

Iemand die mij kan overtuigen aan de hand van eigen ervaring (nog meer meningen!) of we beter voor ISCSI / FC of na het lezen van dit topic NFS kunnen gaan?

[SpamLame]

Flyduck schreef op woensdag 09 februari 2011 @ 23:48:
Ik ben ook op zoek naar een SAN ter vervanging van de huidige (zeer slecht presterende!) MSA 2012fc.
Ondanks de vele SAS 15k disks zakt de performance op drukke dagen tot onder de 40 IOPS per VM (crystal disk mark, random writes 4k. IOMeter heb ik zelfs een keer moeten stoppen omdat het te lang duurde voordat het testbestand van 4GB was aangemaakt)

Ik wil graag naar ISCSI (equallogic via ISCSI HBA's) maar door de vele meningen op internet raak ik steeds minder overtuigd.
We hebben zeer snelle access times nodig (hosted desktops op 15 terminal servers) naast Exchange en SQL met grote OLTP databases.

Door de slechte performance van de huidige MSA zijn de SQL en Exchange momenteel fysiek

Iemand die mij kan overtuigen aan de hand van eigen ervaring (nog meer meningen!) of we beter voor ISCSI / FC of na het lezen van dit topic NFS kunnen gaan?

Ik heb een tijdje met MSA's 1000 1500 gewerkt, maar vond ze maar zwak.
Mijn indruk is dat de MSA2000 wel beter is, maar echt overtuigd ben ik niet.
Dan worden zaken als (que) blocksize diskalignment cacheinstelling etc. al gauw belangrijker.
Wellicht dat die MSA van jullie het werk beter aan kan als de inrichting anders wordt.

PS is je cache battery niet stuk?

Databases zou ik niet over NFS draaien. Misschien kan het en is het gesupport, maar ik heb daar geen ervaring mee.
Voor snelle access zou ik naar FC uitkijken, temeer ook omdat je nu al FC infra hebt liggen.

[Ethirty]

SpamLame schreef op donderdag 10 februari 2011 @ 08:17:
Ik heb een tijdje met MSA's 1000 1500 gewerkt, maar vond ze maar zwak.
Mijn indruk is dat de MSA2000 wel beter is, maar echt overtuigd ben ik niet.
Dan worden zaken als (que) blocksize diskalignment cacheinstelling etc. al gauw belangrijker.
Wellicht dat die MSA van jullie het werk beter aan kan als de inrichting anders wordt.

Er is dus kennelijk iets mis met die MSA-serie? Ik vraag dat omdat wij momenteel een P2000 G3 overwegen. Volgens de specs gaat deze fully loaded (149x 15k schijven) tot bijna 20k random IOPS. Wel is het zo dat een iSCSI versie met RAID6 niet veel verder komt dan max 4900 random IOPS.

[Verwijderd]

Wij hebben onlangs voor Greenbytes gekozen!

Goedkoop maar zeer snel door cashing op SSD disken. Ik zou het zeker meenemen in de overweging.

[Koffie]

Flyduck schreef op woensdag 09 februari 2011 @ 23:48:
Ik ben ook op zoek naar een SAN ter vervanging van de huidige (zeer slecht presterende!) MSA 2012fc.
Ondanks de vele SAS 15k disks zakt de performance op drukke dagen tot onder de 40 IOPS per VM (crystal disk mark, random writes 4k. IOMeter heb ik zelfs een keer moeten stoppen omdat het te lang duurde voordat het testbestand van 4GB was aangemaakt)

Ik wil graag naar ISCSI (equallogic via ISCSI HBA's) maar door de vele meningen op internet raak ik steeds minder overtuigd.
We hebben zeer snelle access times nodig (hosted desktops op 15 terminal servers) naast Exchange en SQL met grote OLTP databases.

Door de slechte performance van de huidige MSA zijn de SQL en Exchange momenteel fysiek

Iemand die mij kan overtuigen aan de hand van eigen ervaring (nog meer meningen!) of we beter voor ISCSI / FC of na het lezen van dit topic NFS kunnen gaan?

Lijkt me verstanig om hier zelf een topic voor te starten, in plaats van een bestaand topic te kapen.

[Flyduck]

Koffie schreef op donderdag 10 februari 2011 @ 10:51:

[...]

Lijkt me verstanig om hier zelf een topic voor te starten, in plaats van een bestaand topic te kapen.

??

Er zijn al zoveel SAN topics, ik probeer juist te voorkomen om een nieuw topic te openen. Beetje vreemde reactie.

[ZeRoC00L]

Ethirty schreef op donderdag 10 februari 2011 @ 09:29:
[...]

Er is dus kennelijk iets mis met die MSA-serie? Ik vraag dat omdat wij momenteel een P2000 G3 overwegen. Volgens de specs gaat deze fully loaded (149x 15k schijven) tot bijna 20k random IOPS. Wel is het zo dat een iSCSI versie met RAID6 niet veel verder komt dan max 4900 random IOPS.

Ik ben wel gecharmeerd van de P2000 G3 serie, maar wel de Fibre Channel variant. Met FC heb je 8Gb koppeling (liefst natuurlijk redundant) naar je SAN ipv 1Gb via iSCSI. Werkt als de brandweer.
Natuurlijk is je RAID level wel belangrijk, als we vSphere gebruiken komen de VM's op RAID10.

[Koffie]

Flyduck schreef op donderdag 10 februari 2011 @ 11:14:
[...]


??

Er zijn al zoveel SAN topics, ik probeer juist te voorkomen om een nieuw topic te openen. Beetje vreemde reactie.

Start dan een algemeen SAN-topic zou ik zeggen, maar ga niet zomaar iemand zijn topic kapen.

[SpamLame]

Ethirty schreef op donderdag 10 februari 2011 @ 09:29:
[...]

Er is dus kennelijk iets mis met die MSA-serie? Ik vraag dat omdat wij momenteel een P2000 G3 overwegen. Volgens de specs gaat deze fully loaded (149x 15k schijven) tot bijna 20k random IOPS. Wel is het zo dat een iSCSI versie met RAID6 niet veel verder komt dan max 4900 random IOPS.

Iets genuanceerder, ja ik vind de msa1000 en 1500 zwak en nee ik heb geen goed gevoel bij de 2000 reeks.
Dat wilt niet zeggen dat er iets mis is met die apparaten, maar meer over mij en het gebied waarop ik ze zou inzetten.
Verder heb ik niet zoveel op met de performance gegevens op de spec sheet omdat niet wordt aangegeven hoe groot de gebruikte dataset is. Als je dataset klein genoeg is dan past het allemaal in de cache, waardoor de getallen hard achteruit kunnen gaan zodra de backend aangesproken moet worden.
Daarnaast blijft het een lab setup waarbij de meest optimale configuratie gebruikt is.

Als je de 10GbE variant neemt zijn je resultaten weer wat beter.

[ Voor 3% gewijzigd door SpamLame op 10-02-2011 13:21 ]

[mieJas]

Wij hebben een relatief groot aantal virtuele machines die verbonden zijn aan een USP-V. Werkt prachtig. Omwille van van de deduplicatiemogelijkheden van NetApp (die hier toch stond), hebben we eens geprobeerd om een 10-tal hosts via NFS te draaien. Dat was een behoorlijke teleurstelling. Gemiddeld 90% CPU verbruik, 30% netwerkverbruik. iSCSI op diezelfde NetApps ging al een heel stuk beter. Gebaseerd op die ervaring, zou ik NFS afraden als het om 50 virtuele machines gaat.

Los hiervan, kan je eventueel een referentiebezoek of een hands-on evaluatie vragen. Zo weet je meteen ook de ervaringen van andere mensen en kan je beter inzien hoe die machines werken.

Beperkt je ook niet tot Dell en HP, maar ga eens aankloppen bij EMC, HDS of zelfs Oracle. Zeker bij die laatste kan je hele mooie kortingen krijgen t.o.v. de list price

[ Voor 11% gewijzigd door mieJas op 10-02-2011 15:09 ]

[SpamLame]

Flyduck schreef op donderdag 10 februari 2011 @ 11:14:
[...]


??

Er zijn al zoveel SAN topics, ik probeer juist te voorkomen om een nieuw topic te openen. Beetje vreemde reactie.

Als je geholpen wilt worden met je huidige omgeving, dan denk ik dat een seperaat topic beter is.
Als je advies wilt over iets nieuws, denk ik dat je hier wel goed zit, hoewel TS of moderator daar het laatste woord in heeft. Met de aanwezig deelnemers en uitstapjes zo links en rechts is de kans wel aanwezig dat dit het grote san advies topic word.

[erwinb]

mieJas schreef op donderdag 10 februari 2011 @ 15:07:
Wij hebben een relatief groot aantal virtuele machines die verbonden zijn aan een USP-V. Werkt prachtig. Omwille van van de deduplicatiemogelijkheden van NetApp (die hier toch stond), hebben we eens geprobeerd om een 10-tal hosts via NFS te draaien. Dat was een behoorlijke teleurstelling. Gemiddeld 90% CPU verbruik, 30% netwerkverbruik. iSCSI op diezelfde NetApps ging al een heel stuk beter. Gebaseerd op die ervaring, zou ik NFS afraden als het om 50 virtuele machines gaat.

Welke NetApp heb je getest ten opzichte van de HDS USP-V?
een NetApp FAS3020 bv vergelijken met een USP-V is redelijk appes met peren vergelijken. Een NetApp 6000 serie is zou wel een goede vergelijk zijn.

[SpamLame]

erwinb schreef op donderdag 10 februari 2011 @ 23:28:
[...]

Welke NetApp heb je getest ten opzichte van de HDS USP-V?
een NetApp FAS3020 bv vergelijken met een USP-V is redelijk appes met peren vergelijken. Een NetApp 6000 serie is zou wel een goede vergelijk zijn.

Een goede vergelijking zou ik niet zeggen, hij is wel eerlijker

[basprofessional]

leuk_he schreef op woensdag 09 februari 2011 @ 10:21:
[...]


Je moet bij zo´n echte SAN ook investeren in kennisopbouw. Even een SAN neerzetten en er van uit gaan dat het voor dat bedrag automatisch zou gaan is een grote verspilling. Je krijgt dan niet de uptime en performance die zo´n san zou kunnen leveren.

Een aantal qnap apparaten zit wel een een klasse lager, maar ook een prijsklasse lager, Je hebt het gewoon ergens anders over.

Merk op dat je backup verhaal in beide gevallen gewoon nodig blijft, aan gezien een reduanante storage geen oplossing bied voor `gebruikersfouten`.

Niet mee eens, het configureren en het onderhouden van een eqaullogic is echt kinderlijk eenvoudig..
Ik zou ook zeker zoals eerder vermeld gewoon Dell evt. ook Netapp eens opbellen zij kunnen je hierin prima adviseren en veel beter als dat wij dat kunnen zonder echt harde cijfers.

[SpamLame]

MuadD1b schreef op dinsdag 08 februari 2011 @ 11:48:
Ik heb gedetailleerde info opgevraagd bij ons datacenter.
Even afwachten

En is er wat nieuws te melden van jullie datacenter?

[Aragnut]

basproffesional schreef op vrijdag 11 februari 2011 @ 07:59:
[...]


Niet mee eens, het configureren en het onderhouden van een eqaullogic is echt kinderlijk eenvoudig..
Ik zou ook zeker zoals eerder vermeld gewoon Dell evt. ook Netapp eens opbellen zij kunnen je hierin prima adviseren en veel beter als dat wij dat kunnen zonder echt harde cijfers.

Heb je dan ook rekening gehouden met redundantie? hoeveel uptime moet de storage hebben, wat doe je tegen data verlies, hoe handel je de administratie af etc. etc. Het beheren van een storage omgeving is meer dan alleen een stuk hardware instellen.

[MuadD1b]

SpamLame schreef op vrijdag 11 februari 2011 @ 08:32:
[...]

En is er wat nieuws te melden van jullie datacenter?

Helaas nog niet.
Hopelijk kunnen we er vandaag nog even achteraan gaan.

[leuk_he]

basproffesional schreef op vrijdag 11 februari 2011 @ 07:59:
[...]


Niet mee eens, het configureren en het onderhouden van een eqaullogic is echt kinderlijk eenvoudig..
Ik zou ook zeker zoals eerder vermeld gewoon Dell evt. ook Netapp eens opbellen zij kunnen je hierin prima adviseren en veel beter als dat wij dat kunnen zonder echt harde cijfers.

Als je weet wat je wilt is het simpel. Maar als je niet de kennis hebt weet je niet wat je krijgt, of koop je een duurder apparaat dan je nodig hebt. Of je denkt reduant te draaien, maar je hebt ergens een stap vergeten.

Kijk maar hierboven over een aantal mensen die ontevreden zijn (over performance).

Uiteraard kun je deze kennis uitbesteden, mar dan nog moet je een aantal vragen goed stellen (groei, nivo van reduantie, uptime, MTTR )

[Jazzy]

Wat ik ook vaak zie is dat een SAN eenmalig wordt aangeschaft zonder voldoende rekening te houden met data-groei. Dan heeft klant budget gekregen voor aanschaf en hebben ze opeens een groot probleem als je binnen een jaar een nieuwe shelf moeten toevoegen. Is iets om goed over na te denken.

[Bor]

erwinb schreef op dinsdag 08 februari 2011 @ 23:22:
@ Bor de Wollef
Ik denk dat geld niet een issue is. een IP / NFS storage systeem met goede switches zal waarschijnlijk een vergelijkbare prijs hebben als een FC san.

Een vergelijkbare tot marginaal slechtere performance inderdaad. Als deduplicatie een must is zou IP / NFS storage interessant zijn maar in de andere gevallen ben ik toch nog steeds voorstander van FC.

Performance vergelijking op basis van hier zoveel genoemde Netapp:







En nog een met een veel groter verschil:



Persoonlijk denk ik dat geld zeker een issue is.

[ Voor 6% gewijzigd door Bor op 13-02-2011 01:11 ]

[SpamLame]

Je hebt twee keer fig17 gepost.
Misschien ook intressant te weten tegen welke NetApp dit is aangebouden.
Voor de minder oplettende lezer>> de grafieken zijn relatief aan FC (die op 100% is gezet)

[Bor]

SpamLame schreef op zaterdag 12 februari 2011 @ 23:31:
Je hebt twee keer fig17 gepost.
Misschien ook intressant te weten tegen welke NetApp dit is aangebouden.
Voor de minder oplettende lezer>> de grafieken zijn relatief aan FC (die op 100% is gezet)

Ik heb het even aangepast. Apparatuur Netapp is een FAS 3170.

[PcDealer]

Jazzy schreef op vrijdag 11 februari 2011 @ 13:38:
Wat ik ook vaak zie is dat een SAN eenmalig wordt aangeschaft zonder voldoende rekening te houden met data-groei. Dan heeft klant budget gekregen voor aanschaf en hebben ze opeens een groot probleem als je binnen een jaar een nieuwe shelf moeten toevoegen. Is iets om goed over na te denken.

En dan betaal je bij NetApp de hoofdprijs voor een shelf.

Bor de Wollef schreef op zaterdag 12 februari 2011 @ 17:31:
[...]


Een vergelijkbare tot marginaal slechtere performance inderdaad. Als deduplicatie een must is zou IP / NFS storage interessant zijn maar in de andere gevallen ben ik toch nog steeds voorstander van FC.

Performance vergelijking op basis van hier zoveel genoemde Netapp:

Ik mis de onderbouwing van deze cijfers. Ik mis het aantal gebruikte poorten en is er bij iscsi tcp/ip offloading gebruikt? 4Gb fc is trouwens wel achterhaald door 8Gb. Daarnaast is er ook nog 10Gb ethernet beschikbaar.

[SpamLame]

PcDealer schreef op zondag 13 februari 2011 @ 08:25:
[...]

En dan betaal je bij NetApp de hoofdprijs voor een shelf.


[...]

Ik mis de onderbouwing van deze cijfers. Ik mis het aantal gebruikte poorten en is er bij iscsi tcp/ip offloading gebruikt? 4Gb fc is trouwens wel achterhaald door 8Gb. Daarnaast is er ook nog 10Gb ethernet beschikbaar.

Ben met je eens dat de grafieken nog met eea aan info begeleid had kunnen worden.
Afgezet tegen 8G (wat in de 3170, naar mijn weten, niet mogelijk) is worden de cijfers slechter voor NFS en iSCSI. Fig 17 laat nl zien dat de getallen voor 10G NFS en iSCSI in de buurt komen van 4G FC.
Wat zou 10G FCoE hier gedaan hebben?

[Bor]

PcDealer schreef op zondag 13 februari 2011 @ 08:25:
[...]Daarnaast is er ook nog 10Gb ethernet beschikbaar.

Plaatje 3: 10 Gb iSCSI en 10 Gb NFS vs 4 GB FCP. Het hele test rapport heb ik helaas ook niet.

[ Voor 15% gewijzigd door Bor op 13-02-2011 10:45 ]

[Bl@ckbird]

SpamLame schreef op zondag 13 februari 2011 @ 08:51:
[...]
Wat zou 10G FCoE hier gedaan hebben?

The current generation of converged network adapters (CNAs) for FCoE support up to 4 Gbps of Fibre Channel traffic. The HBA driver and hardware on the shipping CNA is identical to that on the 4-Gbps Fibre Channel HBAs. The next generation of CNAs will support the 8-Gbps Fibre Channel standard.

Zie:
http://www.cisco.com/en/U...ite_paper_c11-501770.html

10Gbps FCoE is dus 4Gbps FC en de rest wordt door Ethernet en overhead gebruikt.
FCoE wordt vaak richting de hosts / servers gebruikt en 8G FC richting het SAN
en meerdere 10GE links richting het LAN.

[ Voor 8% gewijzigd door Bl@ckbird op 13-02-2011 19:41 ]

[SpamLame]

Bl@ckbird schreef op zondag 13 februari 2011 @ 19:38:
[...]


[...]


Zie:
http://www.cisco.com/en/U...ite_paper_c11-501770.html

10Gbps FCoE is dus 4Gbps FC en de rest wordt door Ethernet en overhead gebruikt.
FCoE wordt vaak richting de hosts / servers gebruikt en 8G FC richting het SAN
en meerdere 10GE links richting het LAN.

In die whitepaper (test) hebben ze een QLogic QLE8042 gebruikt.
Als ik diens datasheet er op na sla geeft dat de indruk dat FC transport op wirespeed gaat.
Ook een Brocade CNA 1010 of 1020 geeft de indruk dat het wirespeed moet zijn, dus 10G.
Iets wat in mijn ogen klopt, het ethernet pakket gaat met 10G, FC is maar ingekapseld.
Maak ik een denkfout?

Overigens een leuke whitepaper.

[Bl@ckbird]

4G Fibre Channel blijft 4G Fibre Channel.
Met ethernet kan je PAUSE control frames sturen. Het zit in de standaard, maar niemand gebruikte het.
PAUSE frames worden gebruikt om ethernet lossless te maken.

Huidige CNA's hebben een ASIC voor het ethernet gedeelte en voor het FC gedeelte. Een Menlo-ASIC combineert dit to FCoE. Nieuwere generatie CNA's hebben deze 3 ASIC geïntegreerd tot één ASIC.
Het wordt dan mogelijk om de 10G bandbreedte dynamisch te verdelen tussen ethernet of FC.

Dit verdelen van bandbreedte wordt gedaan met IEEE 802.1p class of service (CoS).
Er zijn 8 class of services en elke class kan PAUSE frames / Priority Flow Control gebruiken.

PFC uses the IEEE 802.1p CoS values in the IEEE 802.1Q VLAN tag to differentiate up to eight CoSs that can be subject to flow control independently.

Dus IEEE 802.1p class of service en PAUSE control frames (wat al jaren onderdeel vormen van de ethernet standaard) worden gebruikt om ethernet geschikt te maken om FC te transporteren en daarmee de losslessnes van FC te garanderen.

Meer whitepapers staan hier:
http://www.cisco.com/en/U...od_white_papers_list.html
( Maar hier staan ook wat minder technische tussen. Deze is ook wel handig. )

[mieJas]

erwinb schreef op donderdag 10 februari 2011 @ 23:28:
Welke NetApp heb je getest ten opzichte van de HDS USP-V?
een NetApp FAS3020 bv vergelijken met een USP-V is redelijk appes met peren vergelijken. Een NetApp 6000 serie is zou wel een goede vergelijk zijn.

Een V3160 aangesloten op de HDS. Een NFS-head, laten we maar zeggen. Moet genoeg zijn voor 10 simpele virtuele machines, leek ons.

PcDealer schreef op zondag 13 februari 2011 @ 08:25:
En dan betaal je bij NetApp de hoofdprijs voor een shelf.

Je kan een mooie vermindering krijgen als je het voor een bepaald soort beelden gaat gebruiken

[erwinb]

Bor de Wollef schreef op zaterdag 12 februari 2011 @ 17:31:
mijn eigen quote: - Persoonlijk denk ik dat geld zeker een issue is.

Wat ik bedoel te zeggen is dat een goed storage IP netwerk niet veel verschild qua kosten van een FC SAN.

[ Voor 3% gewijzigd door erwinb op 14-02-2011 16:52 ]

[PcDealer]

erwinb schreef op maandag 14 februari 2011 @ 16:51:
[...]


Wat ik bedoel te zeggen is dat een goed storage IP netwerk niet veel verschilt qua kosten van een FC SAN.

Mogelijk zelfs goedkoper.

[SpamLame]

MuadD1b schreef op vrijdag 11 februari 2011 @ 12:23:
[...]

Helaas nog niet.
Hopelijk kunnen we er vandaag nog even achteraan gaan.

Nu wat nieuws te melden, datacenter/provider heeft toch al een week+ de tijd gehad.

[Bor]

Ik ben eigenlijk ook wel benieuwd of er nieuws te melden is na alle input die hier is gegeven.

[MuadD1b]

SpamLame schreef op donderdag 17 februari 2011 @ 09:55:
[...]

Nu wat nieuws te melden, datacenter/provider heeft toch al een week+ de tijd gehad.

Inderdaad. En we krijgen niets van ze
Ze weigeren om technische details of statistieken op te hoesten. Dat ze geen technische details over het SAN willen geven snap ik nog enigszins maar dat we onze eigen statistieken niet in mogen zien is natuurlijk te triest voor woorden.
Omdat we op dit moment echt geen SAN performance meer hebben en de hoster aangeeft dat ze in april pas een vervangend SAN hebben draaien kiezen we ervoor om een nood-oplossing in te zetten.
Dit gaat waarschijnlijk een Dell PowerVault MD3000i worden. Helaas met een enkele controller maar op dit moment moeten we gewoon echt iets ondernemen omdat het niet verder kan.

[SpamLame]

MuadD1b schreef op vrijdag 25 februari 2011 @ 12:23:
[...]

Inderdaad. En we krijgen niets van ze
Ze weigeren om technische details of statistieken op te hoesten. Dat ze geen technische details over het SAN willen geven snap ik nog enigszins maar dat we onze eigen statistieken niet in mogen zien is natuurlijk te triest voor woorden.
Omdat we op dit moment echt geen SAN performance meer hebben en de hoster aangeeft dat ze in april pas een vervangend SAN hebben draaien kiezen we ervoor om een nood-oplossing in te zetten.
Dit gaat waarschijnlijk een Dell PowerVault MD3000i worden. Helaas met een enkele controller maar op dit moment moeten we gewoon echt iets ondernemen omdat het niet verder kan.

Lekkere partner dan. Weet je gelijk wat je te doen staat.
Aangezien je nu voor een noodoplossing en dus investeren gaat, zou ik zeker overwegen om te kijken of je je noodoplossing niet wat robuster en toekomst bestendig kan maken.
Ergo volledig zelf gaan doen ipv wachten tot de provider een nieuw SAN heeft staan dat wellicht ook niet voldoet. Sterker nog indien mogelijk zou ik zelfs een ander provider/datacenter gaan overwegen.

[MuadD1b]

De zeer kleine investering weegt op dit moment op tegen de nadelen. Zelfs als we hier maar 4 maanden op kunnen draaien heeft het ding zichzelf al terugverdiend.
Onze hoster is geen kleine jongen. Het is zelfs één van de grootste van NL.
Over het algemeen zijn we zeer tevreden over ze. Om alleen voor dit punt alles om te gooien is geen optie.

[SpamLame]

Nou misschien niet alles dan. Maar dit topic is ontstaan uit performance problemen met je huidige SAN oplossing.
Ze willen niet prijs geven wat ze nu gebruiken, maar het werkt niet voor jou.
Hoe weet je dat hun nieuwe setup (indien tijdig opgeleverd) wel voldoet aan je (herziene?) eisen?
Wat betaal je voor die storage?
Nu moet je je eigen lapmiddel gaan regelen, wat ook geld kost.
Tel de die twee bedragen bij elkaar op en kijk of je het voor dat bedrag zelf kan doen.
Je weet dan wat je hebt en je bent minder afhankelijk van je hoster.

Of je hoster nu groot of klein is, ik denk dat ze niet echt in de meedenk stand zitten en willen zitten en dat verwacht ik eerlijk gezegd wel. En dan weet ik niet of ik mijn opslag wel zou willen uitbesteden.

[MuadD1b]

Als ik zeg dat we nu 1000-1200 per maand uitgeven voor 2TB storage, en we voor ~5500 een MD3000i met 10TB aan kunnen schaffen dan is het niet zo moeilijk.
Eigenlijk willen we onze storage liever zelf in eigen handen hebben. (wie niet?)

[leon1e]

MuadD1b schreef op vrijdag 25 februari 2011 @ 15:47:
Als ik zeg dat we nu 1000-1200 per maand uitgeven voor 2TB storage, en we voor ~5500 een MD3000i met 10TB aan kunnen schaffen dan is het niet zo moeilijk.
Eigenlijk willen we onze storage liever zelf in eigen handen hebben. (wie niet?)

Hoe weet je nu dat de MD3000i wel genoeg performance levert voor je omgeving? En hoe ga je de redurantie oplossen? Ik neem aan dat je hoster dat netjes in orde heeft. Zo zonder metingen zou ik dat niet aandurven, anders doe je toch zelf een meting op je fysieke host?

[MuadD1b]

Dat weten we niet. Daar gaan we zelf achterkomen.
Zoals ik al aangaf, we moeten iets. Deze optie kunnen we morgen in huis hebben (om het even heel simpel te zeggen).
Als we een customized netapp solution willen dan zijn we zo een maand verder en dat gaat nu gewoon niet.

[SpamLame]

Ja daar had ik even geen rekening mee gehouden. Als je iets moet op korte termijn ben je wel afhenklijk van wat er beschikbaar is.
Ik hoop dat het enigzins verbetering zal brengen.

[leon1e]

Succes ermee dan , er zijn ook wel andere partijen die snel een fatsoenlijk SAN kunnen leveren hoor. Maar aan je reacties te zien vindt je dat helemaal niet interessant, koop gewoon een nieuwe als de MD3000i niet bevalt . Als jullie daadwerkelijk 1000 euro per maand betalen voor de dataopslag was ik ook nog wel even een serieus gesprek aan gegaan met de hoster, en hun een verklaring laten geven waarom het zo traag is dat mag je best verwachten.

[MuadD1b]

Dat gaan we allemaal doen. Maar op dit moment denken we eerst even aan onze klanten.

[Bor]

MuadD1b schreef op vrijdag 25 februari 2011 @ 15:47:
Als ik zeg dat we nu 1000-1200 per maand uitgeven voor 2TB storage, en we voor ~5500 een MD3000i met 10TB aan kunnen schaffen dan is het niet zo moeilijk.

Vergeet de kosten voor uitwijk (indien nodig), beheer en onderhouud / support contracten niet zou ik zeggen. Aanschafprijzen zijn maar een deel van de werkelijke kosten.

[erwinb]

Als je de storage morgen in huid zou moeten hebben tegen een redelijke prijs, dan kn je natuurlijk contact opnemen met een goede NetApp partner. De grote netapp partijen in nederland hebben altijd voldoende voorraad om partijen in nood snel te helpen.

[Bor]

erwinb schreef op zaterdag 26 februari 2011 @ 09:03:
Als je de storage morgen in huid zou moeten hebben tegen een redelijke prijs, dan kn je natuurlijk contact opnemen met een goede NetApp partner. De grote netapp partijen in nederland hebben altijd voldoende voorraad om partijen in nood snel te helpen.

Geldt natuurlijk ook voor andere leveranciers dan alleen Netapp, of is de keuze inmiddels al gemaakt?

[erwinb]

Als ik zo de laatste reacties lees dan lijkt het te gaan tussen NetApp (Lange leverduur?) en Dell-Equallogic (Snel leverbaar)

[Bor]

erwinb schreef op zaterdag 26 februari 2011 @ 11:47:
Als ik zo de laatste reacties lees dan lijkt het te gaan tussen NetApp (Lange leverduur?) en Dell-Equallogic (Snel leverbaar)

Wat ik een beetje mis is echte onderbouwing voor die keuze. Het lijkt meer op persoonlijke voorkeur gestoeld te zijn als ik het topic zo lees, net als de aanbevelingen voor bv NFS wat aantoonbaar minder presteert als ik de eerder geposte grafieken bekijk.

Imho is een snelle keuze voor een SAN lang niet altijd een goede keuze. De selectie van een key component als een SAN dient goed afgewogen te worden.

Wat ik ook een beetje mis is wat de TS nou eigenlijk zelf voor voorkeur heeft anders dan waar hij makkelijk aan denkt te komen.

[Aragnut]

Nu kun je binnen no time een SAN op de zaal hebben staan (van wat ik uit je posts haal), maar hoe ga je de kennis in huis halen om dat apparaat efficient en degelijk in te delen? storage beheer blijkt keer op keer toch lastiger dan het zomaar toekennen van een aantal luns. Je moet ook een distributie netwerk hebben. Als je het via NFS doet dan kun je het bestaande netwerk gebruiken, maar (zoals eerder aangegeven) haal je dan wel performance winst?

[leuk_he]

Wel aardig,


http://webwereld.nl/achte...m=website&utm_campaign=ww

Stap 1: Classificeer je data
Stap 2: Definieer je service levels
Stap 3: Herijk backup en recovery naar nieuwe situatie
Stap 4: Stel grenzen(Wat virtualiseer je wel en wat virtualiseer je niet? )
Stap 5: Leid beheerders op
Stap 6: Rol geleidelijk uit (en wat er fout kan gaan)

Topic starter heeft blijkbaar even de tijd hiervoor moeten kopen, maar heeft nu mooi de gelijkheid statistieken te gaan verzamelen nu de storage in eigen hand draait.

[Verwijderd]

SPAM verwijderd

[ Voor 97% gewijzigd door Koffie op 08-03-2011 09:53 ]

[SpamLame]

Verwijderd schreef op maandag 07 maart 2011 @ 14:31:
Ik zou gaan voor een STORAGEDATA oplossing, ze kunnen hele hoge IOPS leveren dan de HP en Dell's van deze wereld (vergelijkbaar met de Netapp) ! ....kniperdeknip

Geloof best dat ze veel IO's kunnen leveren, maar zie dat liever onderbouwt met argumenten of op zijn minst een specsheet die vertelt wat die IO's waren en hoe de verkregen zijn.
Ik kom hem iig niet tegen op de onafhankelijk http://www.storageperformance.org/ site

Zoals je bijvoorbeeld HP roept zou ik toch nuanceren over welke serie je het dan hebt?
HP levert bv. array's die op papier veel beter zijn uitgerust, zoals bv de net aangekocht 3Par of hun XP (OEM HDS USP-v(m) en VSP).

Dell heeft net Compellent gekocht en verkoopt ook de VNX lijn van EMC.

[Ethirty]

Sowieso roepen de combinatie van 8 SATA disks en veel IOPS bij mij meer vragen op dan ze beantwoorden.

Zo mag ik verwachten dat een P2000 met 24 15k SAS schijven heel wat meer IOPS kan leveren, al zal dat uiteraard weer duurder zijn.

[PcDealer]

EPOC-TXS werkt bij de betreffende distri, dusseh...

Doe de groeten aan Jan Niesen en Desmond Taling

[ Voor 5% gewijzigd door PcDealer op 07-03-2011 18:28 ]

[Bor]

Verwijderd schreef op maandag 07 maart 2011 @ 14:31:
Ook handig:
"De voedingen en koelingen zijn redundant uitgevoerd. Alle kritische onderdelen zijn hot swappable en binnen seconden te vervangen. De controller van de Xi3000 maakt gebruik van een 72-uur battery back-up module"

Handig? Dat vind ik eigenlijk niet meer dan basis. Elk SAN zou redundant uitgevoerde voedingen en koelingen moeten hebben.

[DrFlash]

PcDealer schreef op zondag 13 februari 2011 @ 08:25:
Ik mis de onderbouwing van deze cijfers. Ik mis het aantal gebruikte poorten en is er bij iscsi tcp/ip offloading gebruikt? 4Gb fc is trouwens wel achterhaald door 8Gb. Daarnaast is er ook nog 10Gb ethernet beschikbaar.

Daarbuiten wordt ook 4gb FC vergeleken met 1gb iSCSI of NFS, in onze setup gebruiken we een 4x1 gb trunk voor NFS en een 2x1 gb trunk voor iSCSI en nog 1 voor SMB.

Mooie van de NetApps hier is dat de wat grotere modellen gewoon simpel uit te breiden zijn met meerdere netwerkkaarten in ons geval zijn dat allemaal 4 poorts met een totaal van 12 ethernet poorten in elke filer op het moment. Daarnaast nog een aantal Fiber kaarten voor de shelfs en redundant path.

Het mooie van deze setup is gewoon dat het super schaalbaar is in vergelijking met een FC configuratie. Meer bandbreedte nodig, voeg een netwerk poort aan de trunk toe, als de head het dan echt niet meer bij kan houden vervang je deze door een snellere (schijven zijn nog te gebruiken) of je zet er een head naast en herverdeeld de shelfs.

Dit zal overigens gelden voor meer NAS leveranciers dan alleen NetApp. Voor mij in ieder geval nooit meer shared FC opslag, veels te statisch.