High Availability SAN overwegingen

[Ethirty]

Met een HP C7000, wat full size BL480 blades, ingebouwde LAN en SAN switches en een volle MSA2000 array krijg je een half rack niet vol, maar kan al een heel eind in de hardware behoeftes van de TS worden voorzien. In zo'n C7000 kan je zelf PCI slots plaatsen gekoppeld aan een blade waarop je dan 1:1 draait (dus zonder virtualisatie).

Dan hou je zoveel ruimte over dat je hier en daar nog wel 1u ruimte tussen de doosjes kan laten. En 1 rack is met juist geplaatste airco's prima koel te houden zonder allerlei zaken als geforceerde luchtstromen.

[ Voor 14% gewijzigd door Ethirty op 17-04-2009 19:21 ]

[TrailBlazer]

Ik lees helemaal niks over de huidige infrastructuur. Als je voor een volledig redundante FC oplossing gaat zal je toch echt 2 FC switches moeten hebben. Die zijn ook niet heel erg goedkoop. Bij iSCSI kan je met een beetje mazzel gewoon van je huidige infrastructuur gebruik blijven maken. Je kan dan wel kiezen voor aparte VLANs voor het ISCSi verkeer en die over een andere trunk laten lopen als het gewone userverkeer. Als je switches wat intelligente queueing mechanismes hebben kan je daar wel wat bandbreedte toewijzing mee doen.
Ik weet dat Jep alles met iSCSI doet dus mischien kan hij je wel helpen.

[Ethirty]

In een C7000 passen makkelijk 2 L2/L3 ethernet en 2 FC switches en dan hou je nog 4 plekken over voor 10Gbit of andere zaken

2FC switches en een dual controller op je SAN geeft in active-active ook al zo'n 8Gbps, ik weet niet hoe snel je iSCSI tegenwoordig kan maken?

Maar goed, elk voordeel heb z'n nadeel. In een bladebehuizing wordt je backplane een spof en die zijn niet zo makkelijk dubbel uit te voeren. Daarnaast zijn die spullen ook niet goedkoop.

De insteek van de titel is trouwens high-availability. Hierover heb ik ook nog weinig langs horen komen. Hoe available moet het zijn. Zijn er onderhouds-windows, moet je garanties kunnen geven over hoe snel je weer in de lucht bent als het mis gaat. Hoeveel down-time kan en wil de organisatie tolereren? Dit gaat ook bepalen hoe je je infrastructuur moet gaan inrichten.

Met virtualisatie en een SAN kan je je volledige omgeving mirroren naar een backup locatie. Mocht er brand in de serverroom zijn, dan draai je gewoon verder vanuit de 2e locatie. Maar dit hangt dus al minimaal een factor 2 aan je kostenoverzichtje.

[TrailBlazer]

He is de bedoeling dat je storage direct op de chassis komen? Ik ging er even vanuit dat er wel iets meer nodig was dat dat.

[Snow_King]

Ik geef direct eerlijk toe, ik heb niet het hele topic gelezen.

Wij hebben zelf een EMC staan met daar in 30x 300GB FC en die doet iSCSI, top apparaat!

Maar waar ik vooral op reageer is de prijs van de disks, ik ben hier puur de messenger en vertel alleen wat aan mij is verteld door EMC.

Een 300GB FC disk kost bij EMC 1300 euro, hierbij krijg je:
- lifetime garantie en on-site replacement
- een lange burn-in test van EMC

Daarnaast zegt EMC met 520 byte sectoren te werken in plaats van 512 byte sectoren op de disks om zo een extra ECC controle toe te passen op de data.

Of je zo maar de sectoren van een disk kan aanpassen weet ik niet, maar dat is in ieder geval wat EMC zegt.

En ja, een beetje SAN kost geld, maar ik vind het dubbel en dwars waard.

[TrailBlazer]

Lifetime garantie is leuk maarwat kost het om met minder kwaliteitharddisk te hebben. Kijk naar de MTBF van een andere disk met vegelijkbare specs en ga dan rekenen wat het je kost over de leeftijd van dat SAN.

[SpamLame]

iSCSI kan zosnel als je IP verzenden kan, 10Ge momenteel.
Nadeel is dat ik nog geen 10Ge offload nics heb gezien, daarnaast kosten die switches ook aardig wat.
Je hebt wel storage array's met één of meerdere 10Ge poorten.
FC praat maximaal 8G of 10G (laatste zie je weinig), FCoE kan dan weer zo hard als Ethernet door een kabeltje wilt.
Of je dat ook allemaal nodig hebt is een ander verhaal.

[TrailBlazer]

IP kan wel harder dan 10Ge hoor kwestie van meer dan 1 van die linkjes bundelen. Ik heb laatst gesproken met wat storage jongens bij mij op mijn werk en die zijn nog erg huiverig voor 10Gbit ethernetadapter en FCoE is helemaal vloeken in de kerk voor die jongens.

[SpamLame]

TrailBlazer schreef op vrijdag 17 april 2009 @ 21:24:
IP kan wel harder dan 10Ge hoor kwestie van meer dan 1 van die linkjes bundelen. Ik heb laatst gesproken met wat storage jongens bij mij op mijn werk en die zijn nog erg huiverig voor 10Gbit ethernetadapter en FCoE is helemaal vloeken in de kerk voor die jongens.

Tuurlijk kan je bundelen, maar omdat FC dat ook kan, had ik ervoor gekozen niet er bij te halen.

[PolarBear]

TrailBlazer schreef op vrijdag 17 april 2009 @ 20:44:
Lifetime garantie is leuk maarwat kost het om met minder kwaliteitharddisk te hebben. Kijk naar de MTBF van een andere disk met vegelijkbare specs en ga dan rekenen wat het je kost over de leeftijd van dat SAN.

In een Enterprise omgeving is het fijn om binnen 4 uur een replacement te hebben. Ook over 4 jaar. Daar betaal je voor. Murphy ligt dan namelijk altijd om de hoek

[A_De2]

[quote]voodooless schreef op vrijdag 17 april 2009 @ 18:59:
[...]

Dat is een behoorlijk argument. Wist ik niet. Bronnen?


[...]

Kijk maar eens hier:
http://www.computable.nl/...oor-microsoft-hyperv.html

Nu hebben deze 2 partijen al eens eerder samengewerkt, denk maar aan Terminal Services. Dat is destijds geheel opgegaan in Microsoft.
Voor wat betreft VMware: dit is onderdeel van het (nog veel grotere) EMC. Ik vermoed dat die niet toestaan dat Microsoft VMware "opkoopt". Microsoft zelf heeft zicht overigens al langer bewezen in vastheid. Misschien niet altijd de beste producten, maar ze bestaan nog steeds.

Nu zijn er een aantal verschillende uitgangspunten om voor een leverancier te kiezen.
Technisch gezien kan VMware met ESX gewoon leukere kunstjes uithalen dan Microsoft, ook als Hyper-V 2.0 in Q1 van 2010 moet uitkomen. De vraag is of je dat ook daadwerkelijk allemaal nodig hebt. ESX Enterprise kost je een slordige 5K per host. Dan heb je Virtual Center nodig wat ook zoiets kost (exacte prijzen heb ik niet direct voor handen). Dat is voor jouw omgeving serieus geld.

Een voordeel van Microsoft is, is dat ze meerdere lagen in de markt bedienen. Daarmee bedoel ik dat ze naast een stuk hardware virtualisatie, ook de integrale tools hebben om alles te beheren (SCOM). Integratie met Linux is wel een stuk beperkter, over de hele linie denk ik dat Microsoft het beter voor elkaar heeft.

Ik kan hier nog wel even doorgaan maar dan gaan we misschien wat te veel offtopic. Mocht je vragen of ideeën hebben, pm me maar

[Ethirty]

TrailBlazer schreef op vrijdag 17 april 2009 @ 20:12:
He is de bedoeling dat je storage direct op de chassis komen? Ik ging er even vanuit dat er wel iets meer nodig was dat dat.

Als dit een reactie op mijn post was: nee, achter in een blade-chassis stop je een speciaal type switch met voornamelijk interne en enkele externe aansluitingen. De werking is gelijk aan een losse ethernet of FC switch.

@A_De2: in een kleine starter omgeving kan je ook beginnen met foundation voor iets meer dan 3.5k, hiermee draai je 3 hosts en maximaal 6 cpu's. De (optionele) extra's HA, DRS en vMotion maken het grapje een stuk duurder, maar als je dat in het begin nog niet nodig hebt. En je bespaart een hoop hardware en stroom.

[ Voor 25% gewijzigd door Ethirty op 18-04-2009 02:06 ]

[axis]

Sja, met betrekking tot het verhaal van de disks, kijk hier eens: Dell Equallogic: Prijzen disks absurd of logisch?

Eeuwige discussie. (Waar Sun met hun OpenStorage wat aan wil doen trouwens)

Bij EQL betaal je gewoon voor een totaalproduct, met een totaal aantal TB.. Ik heb ook een PS5000E staan, geweldig apparaat, maar daar worden door EQL gewoon huis-tuin-en-keuken schijfjes in geleverd. Maarja, daar halen ze juist de winst, niet bij het base-systeem..

[TrailBlazer]

PolarBear schreef op vrijdag 17 april 2009 @ 22:31:
[...]

In een Enterprise omgeving is het fijn om binnen 4 uur een replacement te hebben. Ook over 4 jaar. Daar betaal je voor. Murphy ligt dan namelijk altijd om de hoek

Dan leg je gewoon 10 van die schijven op de plank in je datacentre heb je ook je spares en in nog minder tijd dan 4 uur beschikbaar. Murphy is voor mij gewoon een zwaktebod voor niet goed je berekeningen doen met betrekking tot MTBF en MTTR. Er zijn zoveel opties mogelijk met hotspares, raid 5 arrays en weet ik veel wat.

Ethirty schreef op zaterdag 18 april 2009 @ 01:53:
[...]

Als dit een reactie op mijn post was: nee, achter in een blade-chassis stop je een speciaal type switch met voornamelijk interne en enkele externe aansluitingen. De werking is gelijk aan een losse ethernet of FC switch.

Ja dat wist ik ook wel. Ik ging er vanuit dat er een stuk meer chassis aangesloten zouden worden op het SAN.

[Ethirty]

TrailBlazer schreef op zaterdag 18 april 2009 @ 09:01:
Ja dat wist ik ook wel. Ik ging er vanuit dat er een stuk meer chassis aangesloten zouden worden op het SAN.

Dat is ook nog helemaal niet duidelijk. Als TS zijn servers 1 op 1 gaat vervangen kan hij voor gewone servers of blades gaan, als hij gaat virtualiseren ook. Hoeveel hij er van welk type dan nodig heeft is aan hem om te berekenen. Ik gaf alleen maar een voorbeeldje toen het over koeling ging voor het geval TS nog niet echt bekend is met blades.

[itlee]

maarum,...wat is je budget eigenlijk? dat heb ik nergens nog gelezen...(alleen maar mooie technische oplossingen)

nog even terugkomen waarom VMware,....?

- HyperV....daar wil ik het nog niet eens over hebben...kinderschoenen, leuk voor thuis maar is geen serieuze speler (nog).
- XEN, ik heb meegemaakt met een MD1000i en een 2950, iscsi niet aan de gang te krijgen (althans niet goed), red het/linux/unix goeroe erbij,...die via de shell volledig iscsi/meuk commands (ging mij zelfs te boven) aan uitvoeren was en uit eindelijk na heel lang pielen en klooien,...maar even ceedeetje vmware erin.

- basis install 1 uur...alles erop en draaien...
waarom vmware?
- goede drivers en dus goede performance
- goede software om beheer te doen, eenvoudig, logisch, duidelijk en voor een gemiddelde beheerder prima te snappen
- updates gaat centraal via virtual center met een paar muisklikken zonder dat je omgeving down hoeft (en vmotion naar de andere zijde en updaten maar)
- alle updates en nieuwe features zijn inbegrepen in je aanschaf prijs (eerste jaar support fee helaas verplicht, maar daarna kan je gewoon je updates binnen halen)
- veel merken/hardware ondersteuning, dat is veel waard.
- veel artikelen/hulp te vinden op internet
- goede rapportage mogelijkheden standaard in virtualcenter server

en zo kan ik nog wel even doorgaan,...ik ben geen xen specialist nog hyperV (wel gekeken naar het laatste product maar is geen serieuze speler)

Vmware is kostbaar in aanschaf maar het verdiend zich dan ook dubbel en dwars terug.
hou er wel rekening mee ik lees 10TB storage maar ik neem aan niet op 1 partitie of 1 LUN?

VMFS3 wordt geadviseerd om niet groter te zetten dan 1 TB per LUN met een max van 2 TB per LUN. anders moet je over naar RAW storage mappings dan kan je wel groter maar of dat wenselijk is?
oja, discussie over ISCSI, onder VMware niet doen, wordt zelfs afgeraden in grote zware omgevingen (documenten van vmware uit aug.2008).

iscsi is leuk voor cheap/low bandwith gebeuren,...ben je serieus bezig koop je fiber. ga ik niet eens over discusseren

[ Voor 99% gewijzigd door itlee op 18-04-2009 14:01 ]

[TrailBlazer]

mischien leuk om te weten dat ik op dit moment bij een project werk waar ze zo'n 6000 servers gaan virtualiseren die enkel gebruik gaan maken van iSCSI, NFS en CIFS. Dit is ook niet de eerste dat dit gedaan wordt door ons. Nu ben ik nauwlijks betrokken bij het storage deel maar het kan dus zeker wel zonder FC.

[ralpje]

Ik denk ook inderdaad echt dat bijna 90% van de corporate ESX oplossingen toch écht iSCSI gebruiken. Alleen de echt heule grote oplossing zullen FC draaien, simpelweg uit kostenoverweging.
Ik moet eerlijkheidshalve ook zeggen dat van alle oplossingen die wij tot nu toe geïmplementeerd hebben (al zijn dat geen supergrote projecten, wij doen met name de wat grotere MKB's) de daadwerkelijk gebruikte bandbreedte altijd een stuk lager uitviel dan we vooraf gedacht zouden hebben.

[LauPro]

Het probleem met FC zoals eerder genoemd zijn de gigantische SPOF's die je ermee maakt. En ja FC, kan redundant zijn maar dat zegt uiteindelijk niets. Het is veel verstandiger om met iSCSI losse eilandjes te maken en die vervolgens onderling te synchroniseren. Mocht er een ESX-server down gaan is dat uiteraard geen probleem, mocht er een iSCSI-storage down gaan dan is dat nog geen probleem want je kan overpakken vanaf een ander eiland.

FC was leuk bedacht met 1 groot centraal netwerk met allemaal redundante storage arrays, maar ze zijn er imo nog lang niet. Het is wel goed toepasbaar als je tientallen losse servers hebt die toch dezelfde storage aan moeten spreken. Maar bij virtualisatie heb je dat eigenlijk niet meer nodig.

Overigens kan ik ook beämen dat de support van VMWare echt subliem is. ESX heeft wel wat rarigheden nog waar je tot op heden veel 3rd party tools voor nodig hebt, maar dat gaat er de komende jaren nog wel uit.

[ Voor 12% gewijzigd door LauPro op 18-04-2009 15:17 ]

[JackBol]

10G iSCSI ga je niet redden. Datatransfer wordt er erg CPU intensief van en er zijn ook TCP windowing problemen waar je tegenaan loopt.

FCoE gaat een geweldige technologie worden, maar je moet het imho echt niet voor eind 2010 gaan aanschaffen.

wat interessant leesvoer:

http://www.digi.com/products/usb/anywhereusb.jsp
http://blogs.zdnet.com/storage/?p=162

[SpamLame]

Sorry LauPro, maar ik zie de link die jij (en kennelijk ook anderen) legt tussen FC (als netwerk neem ik aan niet als protocol) en SPOF niet zo 123.
Zelf veel gewerkt met FC netwerken (SAN's), maar ben daarin nog geen SPOF's tegengekomen.
De storage array's kunnen uiteindelijk wel een SPOF vormen maar dat staat los van FC of iSCSI

[LauPro]

SpamLame schreef op zaterdag 18 april 2009 @ 15:49:
Sorry LauPro, maar ik zie de link die jij (en kennelijk ook anderen) legt tussen FC (als netwerk neem ik aan niet als protocol) en SPOF niet zo 123.
Zelf veel gewerkt met FC netwerken (SAN's), maar ben daarin nog geen SPOF's tegengekomen.
De storage array's kunnen uiteindelijk wel een SPOF vormen maar dat staat los van FC of iSCSI

Het is gewoon heel simpel. De beste redundante systemen zijn systemen die onafhankelijk van elkaar kunnen functioneren. Zodra verschillende systemen afhankelijk zijn van een FC-netwerk dan kunnen storingen impact hebben op alle gekoppelde systemen.

Natuurlijk kan je ook meerdere kleinere SAN's maken, maar dan hef je het nut van een FC-netwerk een beetje op.

Ik geloof best dat er mensen zijn die een FC-netwerk perfect draaiende kunnen houden (ik heb de ook in werking gezien en mee gewerkt) toch is het imo een compleet andere SAN-structuur dan bij iSCSI.

[Ethirty]

En wat maakt een ethernet netwerk dan beter dan een FC netwerk? Imo zijn beiden net zo betrouwbaar uit te voeren en in een FC netwerk kan je ook gewoon meerdere arrays plaatsen.

Ook 1 groot SAN of meerdere losse kleine SAN's staat los van of je ethernet of FC gebruikt.

Dus ik ga met SpamLame mee: ik begrijp je nog steeds niet.

[LauPro]

Ethirty schreef op zaterdag 18 april 2009 @ 17:37:
En wat maakt een ethernet netwerk dan beter dan een FC netwerk? Imo zijn beiden net zo betrouwbaar uit te voeren en in een FC netwerk kan je ook gewoon meerdere arrays plaatsen.

Het zal niet zozeer beter zijn als in de technische kant maar kan je meer met iSCSI icm virtualisatie ivm de kostenafweging. En met name dus vanwege de argumenten die ik eerder heb genoemd. Met virtualisatieservers draai je al meerdere hosts waardoor je SPOF's aan het maken bent, met tools als VMotion kan je hier redundancy maken. Als vervolgens al die virtualisatieservers weer afhankelijk zijn van hetzelfde SAN dan zit daar je 'SPOF', hoe redundant het ook is.

Dus vandaar, systemen isoleren, zorg ervoor dat storingen niet als een inktvlek over je serverpark uit kunnen spreiden. En ik denk dat als met FC allemaal losse SAN's gaat bouwen je het hele concept ondermijnd.

[Ethirty]

Veel mensen denken dat een SAN alleen de storage zelf is, maar het is het geheel van array's, switches en bekabeling. Of je dan daarover FC, iSCSI of Chinees praat maakt dan niet uit voor je redundancy.

Wat jij zegt komt neer op: voor elk doel 1 server met lokale opslag. Beetje 2004 imo. Want als mijn ethernetswitch stuk gaat heb ik ook geen iSCSI SAN meer. Geen LAN ook trouwens, dus dat is dan zelfs een dubbele spof...

Het enige waar ik me in kan vinden is de kosten

[itlee]

ik had een foutje gemaakt...
vmfs3 volume max 64TB.
vmfs3 file size max 2TB...

even kleine correctie.

[LauPro]

Ethirty schreef op zaterdag 18 april 2009 @ 18:51:
Wat jij zegt komt neer op: voor elk doel 1 server met lokale opslag. Beetje 2004 imo. Want als mijn ethernetswitch stuk gaat heb ik ook geen iSCSI SAN meer. Geen LAN ook trouwens, dus dat is dan zelfs een dubbele spof...

Er is in dit topic al aangehaald dat je voor iSCSI een apart dedicated netwerk op moet zetten.

Als je aan mij vraagt wat ik liever zou willen onderhouden. 1 compleet geïntegreerd 'redundant' SAN of 5 losse eilandsystemen die aan elkaar zijn gesynchroniseerd dan ga ik toch echt voor het laatste. Grote SAN's hebben alleen maar zin als je 24/7 mensen hebt die dat in de gaten kunnen houden en support kunnen leveren. Daar komen ook die hoge Dell-prijzen vandaan.

Uiteindelijk moet je zelf kiezen wat je de beste optie vindt. Ik had ook veel liever 1 groot SAN gehad, maar de huidige techniek is daar gewoon nog niet rijp genoeg voor, misschien over 10 jaar dat het dan wat robuster en betaalbaarder is. Wat ook betaalbaarheid vertaalt zich weer in het extra kunnen investeren in redundantie.

[Ethirty]

LauPro schreef op zaterdag 18 april 2009 @ 22:22:
Er is in dit topic al aangehaald dat je voor iSCSI een apart dedicated netwerk op moet zetten.

En dat is wat je met FC ook gewoon doet. Alleen vervang je koper door glas.

Als je aan mij vraagt wat ik liever zou willen onderhouden. 1 compleet geïntegreerd 'redundant' SAN of 5 losse eilandsystemen die aan elkaar zijn gesynchroniseerd dan ga ik toch echt voor het laatste.

Als je eilandjes creëert kan je niet syncen. Zijn ze fysiek aan elkaar geknoopt (zoals ik al zei: dat is een SAN) dan kan hetzelfde met FC. Zet dan 2 of 3 kleine array's neer ipv 1 grote en doe wat jij met iSCSI wil doen.

Daarnaast heeft zo'n opzet ook nadelen. Een foutje in de data op de ene array kan vrolijk naar 4 andere array's syncen en dan heb je nog een probleem.

Dat brengt me op een puntje voor TS: vergeet niet een fatsoenlijke backup mee te nemen in je calculaties. Met zoveel TB heb je ook een flinke tapeloader nodig.

[LauPro]

Ethirty schreef op zaterdag 18 april 2009 @ 22:41:
En dat is wat je met FC ook gewoon doet. Alleen vervang je koper door glas.

Dan zijn we er uit

Als je eilandjes creëert kan je niet syncen. Zijn ze fysiek aan elkaar geknoopt (zoals ik al zei: dat is een SAN) dan kan hetzelfde met FC. Zet dan 2 of 3 kleine array's neer ipv 1 grote en doe wat jij met iSCSI wil doen.

In theorie zijn praktisch tegenwoordig *alle* systemen aan elkaar gekoppeld dmv internet. Met eilanden bedoel ik losse eenheden die op zichzelf kunnen functioneren en geen externe data nodig hebben. Verder kan je ook van servers meerdere instanties maken en die op aparte hosts neerzetten.

De synchronisatie die ik gebruik is geen bitwise 1:1 kopie maar gebaseerd op software in de virtual machines. Mocht een gevirtualiseerde server falen om wat voor een reden dan ook is het systeem op zichzelf dermate redundant dat het die gevirtualiseerde server als zodanig niet nodig heeft.

[Ethirty]

We komen al dichter naar elkaar toe

Hoe zie jij dat dan? Meerdere eenheden van 2 hosts + 1 storage? Als zo'n eenheid uitvalt werkt de rest gewoon door. Wordt een dure grap dan. Want bij

Met eilanden bedoel ik losse eenheden die op zichzelf kunnen functioneren en geen externe data nodig hebben.

denk ik aan een server met eigen storage.

Voordeel van virtualisatie + centrale storage is juist dat je met weinig hardware veel kan en betrekkelijk ongevoelig bent voor spof's.

Ik heb een beetje moeite om een fatsoenlijk storage array met dubbele controllers, dubbele voedingen, dubbele verbindingen en meerdere raid-arrays met hot-spares als een spof te zien. Misschien komt deze discussie daardoor

Mocht een gevirtualiseerde server falen om wat voor een reden dan ook is het systeem op zichzelf dermate redundant dat het die gevirtualiseerde server als zodanig niet nodig heeft.

Deze volg ik niet helemaal meer. Je praat hier over clusters van virtuele servers? Of bedoel je dat je een image (oid) hebt van die server die je makkelijk handmatig kan restoren al dan niet op een andere host?

offtopic:
Virtualisatie is volgens mij express lastig gemaakt. Naast virtuele servers en virtuele netwerken heb je ook virtuele storage en zelfs virtuele san's heb ik al gezien. What's next, virtuele beheerders

[Nowa]

Misschien een beetje ot maar wel een paar keer gezien in dit topic.
Hoe zit dat nou met 2003 licenties en het virtueel draaien op b.v. ESX?
Moet je hier nu een datacenter licentie voor hebben of kan dat ook gewoon met de standaard versie?

[Ethirty]

Kan ook gewoon. Ligt eraan of je al licenties hebt wat handiger is. Met enterprise mag je maximaal 4 virtuele servers draaien op 1 host (is goedkoper bij >2 losse licenties). Met datacenter betaal je ik geloof per cpu en mag je onbeperkt Windows installeren op die host. Ergens op de site van MS is een online calculator te vinden over wanneer welke versie gunstiger is.

[Nowa]

Ja had die calculator al gevonden maar die heeft het alleen over 2008.
We zitten hier met een 20tal 2003 standard licenties. Gaat wat kosten als we dat om moeten gaan zetten ben ik bang.

[Ethirty]

Zolang het geen OEM is zie ik geen problemen. Is het wel OEM dan moet je die kosten sowieso maken bij een vervangingsronde.

[LauPro]

Ethirty schreef op zaterdag 18 april 2009 @ 23:19:
Ik heb een beetje moeite om een fatsoenlijk storage array met dubbele controllers, dubbele voedingen, dubbele verbindingen en meerdere raid-arrays met hot-spares als een spof te zien. Misschien komt deze discussie daardoor

Ook dan kan door een foutieve firmware update van een controller het hele zaakje bijv. onderuit gaan. De opstelling die ik beschrijf kan bijvoorbeeld bestaat uit 2 eilanden:

Cluster 1:
- iSCSI SAN
-- Virtualisatiehost
---- Virtual machines

Cluster 2:
- iSCSI SAN
-- Virtualisatiehost
---- Virtual machines

Die virtual machines synchroniseren dan bijvoorbeeld met DFS of Database master/slave configuraties. Naast een synchronisatie binnen de VM's (dus op OS/App-niveau) is er dan ook nog een sync van de VM-disks en system states. Dus mocht een cluster down gaan draait alles op het andere cluster fijn door. Afhankelijk van de uptimes die per app behaald moeten worden kan je zo services redundant maken. Bij minder kritieke applicaties zou je ervoor kunnen kiezen om bijv. elke dag een back-up te maken, maar ik kan het persoonlijk anno 2009 niet meer verkroppen een dag werk kwijt te zijn.

offtopic:
Virtualisatie is volgens mij express lastig gemaakt. Naast virtuele servers en virtuele netwerken heb je ook virtuele storage en zelfs virtuele san's heb ik al gezien. What's next, virtuele beheerders

Virtualisatie is gestart bij de processor (met HyperThreading) en nu geëindigd bij complete virtualisatie van computernetwerken met virtual switches etc. Maar je moet wel oppassen dat de basis van die virtuele omgeving rocksolid is en dus niet je hele environment als een kaartenhuis in elkaar zakt bij 1 breakdown.

Ik heb genoeg, ook gerenommeerde, bedrijven gezien die kapitalen aan *goede* apparatuur in huis hebben gehaald en vervolgens een fockup maken in een config waarna ze 2+ dagen stront hebben. Terwijl de concurrent met iets mindere apparatuur misschien iets meer moet dweilen maar de zaak wel draaiende weet te houden, pijnlijk...

[Ethirty]

LauPro schreef op zondag 19 april 2009 @ 00:18:
Cluster 1:
- iSCSI SAN
-- Virtualisatiehost
---- Virtual machines

Cluster 2:
- iSCSI SAN
-- Virtualisatiehost
---- Virtual machines

En dat doet hetzelfde als
Cluster1:
- FC SAN
-- Host
--- Virtual machines

Cluster2:
- FC SAN
-- Host
--- Virtual machines

Ik geloof best dat je de materie begrijpt en het heeft weinig nut voor de TS. Zullen we er mee ophouden?

[Bl@ckbird]

LauPro schreef op zondag 19 april 2009 @ 00:18:
[...]

Virtualisatie is gestart bij de processor (met HyperThreading) en nu geëindigd bij complete virtualisatie van computernetwerken met virtual switches etc.

Virtualisatie is begonnen met computer netwerken. VLAN's / MPLS is er al jaren en wordt gebruikt om gebruikersgroepen uit elkaar te houden. Binnen bedrijven zijn dit bijvoorbeeld verschillende afdelingen. Netwerk virtualisatie is ook handig om bijvoorbeeld een managed dienst achter te hangen. Zo wordt MPLS door KPN gebruikt om epacity lijnen aan te bieden. Pas later zijn we grootschalig servers gaan virtualiseren. VMWare vSwitch / Cisco Nexus 1000v is idd wel nieuw.

@ Onderbuurman:
Mhwa... Dan heb ik het nog niet over multiple routing instances, zoals VRF's en virtuele firewall's. En MPLS kan ook redelijk complex worden. Overigens is het de vraag of je een virtuele switch wil draaien. Het kost toch CPU cycle's. (Ergens tussen de 0 en 10% heb ik horen zeggen.) Andere optie is om dataverkeer van VM's via VNLink naar een fysieke switch te trappen. De netwerk interface profielen blijven dan behouden en dat gaat wat verder dot1q trunk naar een fysieke server te sturen.

[ Voor 36% gewijzigd door Bl@ckbird op 19-04-2009 21:47 ]

[LauPro]

Ethirty schreef op zondag 19 april 2009 @ 00:31:
En dat doet hetzelfde als

Met factor 10 qua prijs . En ja ik heb ook al gezegd dat je een FC SAN kan gebruiken maar dan ondermijn je dus het hele concept achter FC... Zolang er reacties op mijn berichten komen zal ik ze beantwoorden .

Bl@ckbird schreef op zondag 19 april 2009 @ 00:35:
[...]
Virtualisatie is begonnen met computer netwerken.

Al hoewel het een hele prille vorm is van de huidige virtualisatietechnieken klopt het. Het blijft een virtueel LAN en geen virtuele switch. En dat is nou juist wat bijvoorbeeld ESX wel doet, die maakt hardware virtueel. Vlannen is een techniek die eigenlijk puur gebaseerd is op wat vlaggetjes en een filtertje in je switching gear, niets wilds aan. In de tijd dat HUB's nog overdadig aanwezig waren misschien.

[SpamLame]

Hmm ik weet niet of de TS wat aan de discussie FC-iSCSI heeft, zie hem niet meer reageren/erop ingaan.
Beide hebben hun nut en helaas ook hun eigen nadelen en voordelen. Beide standaarden kunnen stabiel zonder SPOF's hun werk doen, maar verkeerd gebruik of niet begrijpen zal het tegenovergestelde bereiken.

De TS heeft al aangegeven de voorkeur voor een box met iSCSI als FC te hebben.

[Ethirty]

Tot op zekere hoogte ging het over hoe je fout-tolerantie kan inzetten in een FC of iSCSI SAN. Ergens is dat een beetje weggezakt en werkt het een beetje een discussie a of b is beter. LauPro heeft me namelijk nog steeds niet overtuigd
/offtopic

SpamLame schreef op zondag 19 april 2009 @ 09:34:
De TS heeft al aangegeven de voorkeur voor een box met iSCSI als FC te hebben.

Én én bedoel je? Dat kan geloof ik ook nog, hoewel dat volgens mij extra duur wordt. Bij HP gebruik je dan een iSCSI gateway naar je FC netwerk. Hiervoor wordt bijv een normale server gebruiikt met HBA's en Windows Unified Storage Server.

[SpamLame]

Bij HP heb je inderdaad een extra apparaatje of server nodig, maar bv NetApp of EMC kunnen het in de box leveren. NetApp doet daarnaast dan ook nog CIFS en NFS. Wat de meerprijs is van die functionaliteit , is mij niet bekend.

En wat fout toleranter is ach ja, het gaat er om of hetgeen wat geïmplementeerd wordt de/een oplossing is voor de vraagstukken van de organisatie.

Mijn voorkeur gaat in eerste instantie uit naar FC vanwege mijn bekendheid daarmee. Ik herken hetgeen LauPro schreef niet in de omgevingen waar ik gezeten, hoewel ik eenmaal een ongelofelijke zooi ben tegengekomen door gebrek aan kennis, bemensing en de doorstroom van die bemensing.
Maar die zooi kan je evengoed aantreffen in een iSCSI setup.

Ook deel ik LauPro's mening van (iSCSI) SAN eilandjes bouwen niet. Soms kan of wil je het niet anders, maar het moet niet het uitgangspunt of doel zijn. Indien het gaat om een dedicated storage array dan zie ik die liever in een SAN dan twee (of meer) afzonderlijk eilanden.

Daarnaast zou de synchronisatie vanuit de VM op basis van software gebeuren, wat je zou kunnen aanduiden als SPOF en heb je andere afhankelijkheden en waarschijnlijk meer beheereffort nodig.
Mogelijkerwijs is het een pracht oplossing en snap ik niet goed wat LauPro bedoelt.

Hoe dan ook ieder heeft zijn eigen mening en voorkeuren.

Terug naar de vraag wat voor de TS als fouttolerante oplossing neergezet kan worden.
Als de TS de kennis in huis heeft of bereid is te investeren in kennisopbouw van FC netwerken, dan is een FC oplossing te overwegen.
Indien TS zich comfortabeler voelt met bestaande netwerken dan is een iSCSI oplossing waarschijnlijk de betere.

Valt me op dat er nog niet over security gespoken is.
Op de box kan je aan de slag met LUN Masking en in mijn ogen is dat de enige plek waar je dat zou moeten doen, er bestaat wel de mogelijkheid eea te doen op de hostzijde maar dat geeft mij geen goed gevoel.
Verder zou je iets kunnen doen aan de communicatie tussen initiators. Binnen FC netwerken doe je dit met Zoning, op iSCSI netwerken zou je met ACL's of VLAN's aan de slag kunnen al dan niet gecombineerd met een fysieke scheiding tussen het userdatalan en datablokkenlan.

[ Voor 35% gewijzigd door SpamLame op 19-04-2009 19:05 ]

[JackBol]

LauPro schreef op zondag 19 april 2009 @ 01:44:
[...]
Al hoewel het een hele prille vorm is van de huidige virtualisatietechnieken klopt het. Het blijft een virtueel LAN en geen virtuele switch.

Het is virtualisatie in zijn puurste vorm.

Stel je 3 unmanaged switches voor, met ieder een eigen subnet erop.
Nu stel je je 1 switch voor met 3 VLAN's voor, welke ieder een eigen subnet dragen. Dan heb je toch 3 unmanaged switches gevirtualiseerd?

En dat is nou juist wat bijvoorbeeld ESX wel doet, die maakt hardware virtueel. Vlannen is een techniek die eigenlijk puur gebaseerd is op wat vlaggetjes en een filtertje in je switching gear, niets wilds aan.

CPU Virtualisatie is niets meer dan wat vlaggetjes en een filtertje in je CPU en geheugenadressen, niets wilds aan.

[itlee]

wat ik mis in de hele (goede) discussie is hoeveel de topic starter te besteden heeft (budget)?
we kunnen allemaal prachtige oplossingen aanbieden maar ik ben wel is benieuwd wat hun voor dit project te besteden hebben?

[voodooless]

Leuk dat er nog wat meer discussie komt

Even een aantal reacties:

- Als eerste over de disk prijzen: Leuk dat je een lifetime garantie krijgt, maar die schijven zijn over 5 jaar afgeschreven, en dat ze een "burn-in" test doen. Maar als je, zeg 20 schijfjes koop, en die gaan allemaal 5x over de kop (en het zijn echt de zelfde disks als die in de pricewatch, want specs staan er gewoon bij), dan kan ik ook prima 100 schijfjes op de plank leggen voor het geval dat het mis gaat. Daar kun je nog behoorlijk mee doordraaien buiten de garantieperiode van de disks
- Budget: dat is nog niet keihard bepaald omdat we eerst willen kijken wat we voor welk budget kunnen krijgen, en daarna gaan kijken of dat het geld waard is. Maar ik denk dat je moet rekenen op ergens rond de 25k voor de SAN, even los van de VM machines en het switching spul.
- iSCSI of FC: Zo te zien is dat nogal een discussiepunt Iedereen heeft hier een andere mening over, en ik denk dat we hier het beste zelf een oordeel over zullen moeten vellen, al denk ik dat we toch voor iSCSI zullen kiezen.
- Meerdere losse SAN's lijkt me budget wise geen optie.
- XenServer of VMware: dat is iets waar we ook nog goed naar moeten kijken. Ik lees hierboven dat men iSCSI niet aan de praat kreeg. Lijkt me toch wel een vreemd verhaal. Sowieso zullen we gewoon moeten testen met beide systemen om te kijken wat wel en niet werkt, en hoe goed een en ander werkt, even los van een aantal andere afwegingen.

[ijdod]

Wat een deel van de FC vs iSCSI discussie betreft: Fouttolerantie op infra niveau is leuk, maar laten we eerlijk zijn: daar zit het verschil niet tussen de genoemde storage oplossing, uitgaande van een goede implementatie. Het merendeel van de verstoringen zit niet in technische defecten, maar in menselijk falen van diverse smaken. Een deugdelijk changeproces (dat dus ook door alle betrokken partijen gedragen wordt) is een onnoemelijk grotere uitdaging dat een nette LAN/WAN/SAN/server oplossing, wat het realiseren en waarborgen van uptime proces. Ik heb bergen goede technische oplossingen (al dan niet cost driven) gezien, maar nog nooit een echt goed change proces dat in de praktijk ook werkt .

[Ethirty]

voodooless schreef op maandag 20 april 2009 @ 10:28:
- Als eerste over de disk prijzen: Leuk dat je een lifetime garantie krijgt, maar die schijven zijn over 5 jaar afgeschreven, en dat ze een "burn-in" test doen. Maar als je, zeg 20 schijfjes koop, en die gaan allemaal 5x over de kop (en het zijn echt de zelfde disks als die in de pricewatch, want specs staan er gewoon bij), dan kan ik ook prima 100 schijfjes op de plank leggen voor het geval dat het mis gaat. Daar kun je nog behoorlijk mee doordraaien buiten de garantieperiode van de disks

Alle A-merken leveren in feite gewoon SAN-storage voor een licentieprijs per GB. Grotere of meer disks is dus per definitie duurder dan zelf uitbreiden omdat je 'licentie' duurder wordt. Ik geloof best dat een array blijft functioneren als je er zelf andere disks in stopt, maar bij een investering van 20-50k wil je echt niet dat je geen support krijgt als er iets mis gaat. Volgens mij koop je zo'n array ook niet elke 5 jaar. Misschien draait dat ding wel 10 jaar mee, al dan niet als archief.

Je kan ook zelf gaan lopen tweaken en een 15 TB storage-array met SATA disks gaan bouwen op Linux oid, maar wil je dat echt voor je bedrijfskritische data? Lvt noemen wij dat: leuk voor thuis.

[voodooless]

Ethirty schreef op maandag 20 april 2009 @ 12:34:
Alle A-merken leveren in feite gewoon SAN-storage voor een licentieprijs per GB. Grotere of meer disks is dus per definitie duurder dan zelf uitbreiden omdat je 'licentie' duurder wordt. Ik geloof best dat een array blijft functioneren als je er zelf andere disks in stopt, maar bij een investering van 20-50k wil je echt niet dat je geen support krijgt als er iets mis gaat. Volgens mij koop je zo'n array ook niet elke 5 jaar. Misschien draait dat ding wel 10 jaar mee, al dan niet als archief.

Als je 100 disk op de plank heb liggen denk ik dat je heus wel 10 jaar vooruit kan Ook met de helft lukt dat wel. 't is leuk dat je per GB moet betalen, maar dat zie ik niet zo zitten. Disks zijn commodity hardware, en derhalve op iedere straathoek te vinden (ook FC of SAS reken ik daartoe). Dat ik dan wat meer betaal voor service op die disks, prima.. Maar primair betaal ik voor die mooie kast waar het allemaal in kan en de software die erop draait en de service eromheen...

Je kan ook zelf gaan lopen tweaken en een 15 TB storage-array met SATA disks gaan bouwen op Linux oid, maar wil je dat echt voor je bedrijfskritische data? Lvt noemen wij dat: leuk voor thuis.

Dat was ook zeer zeker niet de bedoeling

[Ethirty]

Ja, maar de prijs van die software zit ook verwerkt in de prijs van de disk. Helaas betaal je én én. Als er al een partij opstaat die een HP/EMC/NetApp achtig product in de markt zet met een diskprijs die bedrijven graag zouden zien, dan worden die of de markt uitgewerkt of opgekocht.

Volgens mij zijn er maar 2 opties: teveel betalen of zelf doen. Je geeft zelf al aan dat het laatste niet de bedoeling is. Er is overigens met goed onderhandelen flink wat korting te krijgen bij de grote jongens. Las pas nog hier op GoT iemand die 30-35% korting kreeg op zijn array.

[SkiFan]

HP heeft heel regelmatig bundelacties, waarbij je het hele SAN gebeuren krijgt voor veel minder dan de totaalprijs van de delen.

[voodooless]

Dat lijkt me ook niet meer dan normaal bij dergelijke prijzen. Slapend rijk worden doen ze maar ergens anders

[Snow_King]

Ethirty schreef op maandag 20 april 2009 @ 12:34:
[...]

Je kan ook zelf gaan lopen tweaken en een 15 TB storage-array met SATA disks gaan bouwen op Linux oid, maar wil je dat echt voor je bedrijfskritische data? Lvt noemen wij dat: leuk voor thuis.

Daar is ook nog een hele leuke discussie over te voeren, maar dat kan misschien de focus van de discussie wat verleggen.

Stel je kiest voor een SAN op basis van Linux, kan heel betrouwbaar zijn (spreek uit ervaring), maar dan moet je wel de juiste kennis in huis hebben.

Draaien hier zelf al 1.5 jaar een iSCSI SAN (Multipathed) op basis van Ubuntu Linux en de uptime is 100% geweest. Dit is een volledig gespiegelde SAN, er staan twee machines die via een Cross-Link hun data syncen zodat bij uitval van een machine de ander het direct over neemt.

Reserve-onderdelen voor deze machines zijn geen probleem, het zijn standaard 15k RPM SAS disks van Seagate en Areca RAID-Controllers, allemaal prima te vinden.

Nu komt alleen de vraag of je dit wil en hier kan je twee kanten mee op:

Ja:
* Je hebt gedegen kennis van Linux of koopt dit in
* Je kan zo goedkoop spare-parts neerleggen

Nee:
* Je koopt een EMC/NetApp

Op mijn werk draait ook een inmiddels 3 jaar oude EMC, we hebben destijds voor EMC gekozen omdat onze Linux kennis toen nog niet ver genoeg reikte het zelf te doen.

SLA's met EMC zijn heel mooi, maar je neemt daar bijv geen SLA met EMC, maar met een partner in NL, dat is in EMC zijn geval Bull.

Stel je disk gaat op zaterdag kapot om 03:00 en je belt voor een nieuwe disk en ze komen niet of te laat, wat dan? Ja, je kan ze aanklagen achteraf, maar wat heb je daar aan? Je productie-proces ligt op dat moment plat.

Dat zijn overwegingen die je moet maken, mijn ervaringen met de EMC support zijn altijd prima geweest, al vroegen ze bij elke call opnieuw om mijn gegevens (zoals telefoonnummer) terwijl die al 10x in het systeem zouden zijn ingevoerd.

Wat mij eigenlijk de grootste zorgen baarde was: Wat als ze hun SLA niet nakomen?

Je kan dan misschien enkele duizenden euro's claimen, maar haalt dat het bij de inkomsten die je dan misloopt?

Maar dat geld ook voor een SAN op basis van Linux, als ie kapot is sta je er helemaal zelf voor.

[TheBrain]

voodooless schreef op donderdag 16 april 2009 @ 23:12:
Dat is helaas bijna niet te doen. Ik weet dat de huidige systemen vooral veel uit hun neus staan te vreten op enkele uitzonderingen na. Echter komen er diverse systemen bij waar wel degelijk wat eisen aan met name IO gesteld zijn. Helaas kunnen we daar moeilijk een (exacte) inschatting van maken. Daarnaast gaat en groot deel van de huidige systemen sowiso vervangen worden (kwa software), en dat zal een heel ander load patroon met zich meebrengen, en ook dat is nu nog zeer lastig te voorspellen. Het is momenteel dus nog behoorlijk koffiedik kijken vrees ik

Ik zou zeggen: kijk toch eens serieus naar PowerRecon. Die paar dollar per server per dag voor het meten gaat je de kop niet kosten als blijkt dat je er bij de aanschaf van je storage array zomaar € 10.000 mee kan besparen of kan voorkomen dat je een undersized storage array koopt.

Betreffende Xen vs. VMware:

Voor zover ik weet heeft Xen heeft o.a.:
- geen memory overcommit en page sharing mechanisme
- geen eenvoudige setup voor high availability
- geen storage vmotion
- alleen maar met NetApp en Equallogic integratie op storage level
- geen mechanisme voor customization van VM's voor provisioning van VM's
- geen mechanisme als Update Manager om VM's en hosts automatisch mee te updaten
- geen methode om Disaster Recovery mee te automatisren (a la Site Recovery Manager)
- geen methode om snapshots te maken van VM's

Het gaat allang niet meer om de hypervisor zelf maar juist om alles wat je erom heen moet doen als beheerder zijn en waar je absoluut zo min mogelijk tijd mee kwijt wil zijn. Je moet het ook zo zien: als je hardware koopt die op de HCL staat heb je daar dus nooit gezeur over bij een supportcall. Daarnaast is de HCL tegenwoordig zo uitgebreid dat je echt wel kan slagen, ook tegen een wat lager budget.

[voodooless]

TheBrain schreef op maandag 20 april 2009 @ 16:30:
Ik zou zeggen: kijk toch eens serieus naar PowerRecon. Die paar dollar per server per dag voor het meten gaat je de kop niet kosten als blijkt dat je er bij de aanschaf van je storage array zomaar € 10.000 mee kan besparen of kan voorkomen dat je een undersized storage array koopt.

Als dat een platformonafhankelijk tool is kan dat wel eens handig zijn. Maar zoals ik al eerder zei: de meeste spullen zijn binnenkort out-of-date, en de hele mikmak gaat anders lopen. Kortom: de metingen die je gaat doen geven je nog steeds geen beeld van wat er werkelijk te verwachten valt. Tevens vraag ik me af of een meting op andere hardware dan de doelmachine wel representatief is. Het aantal iops en transfer rates is toch nogal hardware afhankelijk.

Voor zover ik weet heeft Xen heeft o.a.:
- geen memory overcommit en page sharing mechanisme

Klopt!

- geen eenvoudige setup voor high availability

Voor zover ik kan zien is dat allemaal erg simpel: aanvinken en klaar.

- geen storage vmotion

Klopt, maar met een enkele SAN is dat ook niet nodig. Maar goed, het kan een groot voordeel zijn als er straks nog eentje bij komt, en je spullen wil migreren.

- alleen maar met NetApp en Equallogic integratie op storage level

Los configureren van de meuk lijkt me ook niet zo'n groot probleem

- geen mechanisme voor customization van VM's voor provisioning van VM's

Kan dynamic provisioning van XenServer dat niet?

- geen mechanisme als Update Manager om VM's en hosts automatisch mee te updaten

Lijkt me niet de meest spannende feature eigenlijk.

- geen methode om Disaster Recovery mee te automatisren (a la Site Recovery Manager)[/quote[
- geen methode om snapshots te maken van VM's

Dat is inderdaad niet aanwezig.

Het gaat allang niet meer om de hypervisor zelf maar juist om alles wat je erom heen moet doen als beheerder zijn en waar je absoluut zo min mogelijk tijd mee kwijt wil zijn. Je moet het ook zo zien: als je hardware koopt die op de HCL staat heb je daar dus nooit gezeur over bij een supportcall. Daarnaast is de HCL tegenwoordig zo uitgebreid dat je echt wel kan slagen, ook tegen een wat lager budget.

Dat is waar. Ik zie inderdaad dat VMware toch een aantal dingen biedt die nogal belangrijk kunnen zijn in de toekomst. HCL hardware vinden is inderdaad niet zo'n groot probleem, ook voor minder budget lukt dat wel.

Ik denk dat ik nu een stuk verder ben gekomen met het geheel! We gaan eerst eens kijken wat we nu precies willen als uitgangspunt, en van daaruit verder kijken naar wat daarbij past

[Ethirty]

voodooless schreef op maandag 20 april 2009 @ 17:03:
Klopt, maar met een enkele SAN is dat ook niet nodig. Maar goed, het kan een groot voordeel zijn als er straks nog eentje bij komt, en je spullen wil migreren.

Storage Vmotion gebruik je niet alleen tussen Arrays maar ook tussen LUN's. Stel je hebt 500GB en die loopt vol, je regelt een nieuw LUN en je moet wat machines heen en weer schuiven. Als de machine down kan gedurende de actie (al snel enkele uren als je pech hebt) niks aan de hand. Anders is sVmotion érg handig.

[voodooless]

Dat is een goeie inderdaad! Weer een punt voor VMWare

[TheBrain]

Oh ja: morgen is de officiële aankondiging van de nieuwe versie waarschijnlijk: http://www.vmware.com/landing_pages/nextgen.html

voodooless schreef op maandag 20 april 2009 @ 17:03:
[...]
Als dat een platformonafhankelijk tool is kan dat wel eens handig zijn. Maar zoals ik al eerder zei: de meeste spullen zijn binnenkort out-of-date, en de hele mikmak gaat anders lopen. Kortom: de metingen die je gaat doen geven je nog steeds geen beeld van wat er werkelijk te verwachten valt. Tevens vraag ik me af of een meting op andere hardware dan de doelmachine wel representatief is. Het aantal iops en transfer rates is toch nogal hardware afhankelijk.

Het is platform onafhankelijk en in de tool zitten configuratiegegevens van zeer veel servers. Je kan ook je eigen configuratiegegevens invoeren. Je kan consolidatiescenario's laten doorrekenen door de tool. Dat is overigens met name voor servers en niet voor servers maar IO gegevens zijn toch redelijk HW onafhankelijk.

Los configureren van de meuk lijkt me ook niet zo'n groot probleem

Het kunnen werken met templates die automatisch worden afgekonfigureerd werkt er prettig hoor het scheelt gewoon veel handwerk als je even een nieuwe server moet aanmaken.

Lijkt me niet de meest spannende feature eigenlijk.

Ook dit is weer erg gemakkelijk als je patches op je hosts of patches op VM's geautomatiseerd tegen een baseline kan laten testen en installeren. Voor windows machines regelt VUM ook de meestal verplichte reboot e.d.

[Dafjedavid]

Ethirty schreef op maandag 20 april 2009 @ 17:11:
[...]

Storage Vmotion gebruik je niet alleen tussen Arrays maar ook tussen LUN's. Stel je hebt 500GB en die loopt vol, je regelt een nieuw LUN en je moet wat machines heen en weer schuiven. Als de machine down kan gedurende de actie (al snel enkele uren als je pech hebt) niks aan de hand. Anders is sVmotion érg handig.

Sorry dat ik een klein beetje off-topic ga...
Ik heb bij ons op de zaak ook net onze omgeving voor het grootste gedeelte overgezet naar VMWare.
Even een vraagje over Storage Vmotion! Is deze alleen te benaderen via de CLI?

Dat is namelijk de enige manier die ik kan vinden via de gebruikelijke wegen....
Totdat ik een plugin tegenkwam op deze pagina.
Vroeg me af of er nog meer van deze tools zijn of dat jullie het allemaal via de CLI doen....?

[NoE]

Gewoon kijken naar een SUN S7410, zeer goedkoop op basis van ZFS (intern), SSD en SATA en de mogelijkheid tot allerlei connectie methodieken... (FC staat nog op de roadmap...)

Kuch, Oracle S7410 tegenwoordig...:)

[itlee]

ik had nog een vraag gesteld over budget?
want t wordt allemaal een hoop techiestuff...maar daar verkoop je je project intern nooit mee, een directie lid snapt het verschil tussen iscsi,fc, sata, sas enz. toch niet...die wil garantie, zekerheden, goed procedures en een transparante investering....

maarum,....hoeveel pesos heb je te besteden? of moet je nog lobbien voor euries?

[Ethirty]

Dafjedavid schreef op maandag 20 april 2009 @ 22:52:
Vroeg me af of er nog meer van deze tools zijn of dat jullie het allemaal via de CLI doen....?

Heb nog niet zoveel met echte productie-omgevingen gedaan, maar ik gebruik die plugin ook wel eens. Volgens mij is het gewoon een simpele GUI voor de CLI.

itlee schreef op dinsdag 21 april 2009 @ 00:23:
want t wordt allemaal een hoop techiestuff...maar daar verkoop je je project intern nooit mee, een directie lid snapt het verschil tussen iscsi,fc, sata, sas enz. toch niet...die wil garantie, zekerheden, goed procedures en een transparante investering....

Om te bepalen wat een omgeving gaat kosten moet je eerst als techie de mogelijkheden en de voor- en nadelen kennen. Dan kan je de argumentatie om je benodigde budget heen schrijven. Als de directie €10000 over heeft kan TS gelijk zeggen dat je daarmee niks begint om een goede betrouwbare nieuwe omgeving te bouwen.

[ Voor 48% gewijzigd door Ethirty op 21-04-2009 09:43 ]

[SpamLame]

Storage vMotion kan gewoon via de Virtual Center (nu vSphere) aanspreken.
Uiteraard met je daarvoor eerst een licentie gekocht hebben (trail versie indien mogelijk).

http://www.vmware.com/pro...age_vmotion_overview.html

[ Voor 16% gewijzigd door SpamLame op 21-04-2009 11:02 . Reden: linkje ]

[voodooless]

NoE schreef op maandag 20 april 2009 @ 22:58:
Gewoon kijken naar een SUN S7410, zeer goedkoop op basis van ZFS (intern), SSD en SATA en de mogelijkheid tot allerlei connectie methodieken... (FC staat nog op de roadmap...)

Goedkoop is het niet bepaald... Maar wel vet

* voodooless is ZFS fan

Ethirty schreef op dinsdag 21 april 2009 @ 09:40:
Om te bepalen wat een omgeving gaat kosten moet je eerst als techie de mogelijkheden en de voor- en nadelen kennen. Dan kan je de argumentatie om je benodigde budget heen schrijven. Als de directie €10000 over heeft kan TS gelijk zeggen dat je daarmee niks begint om een goede betrouwbare nieuwe omgeving te bouwen.

Precies. Er is niet echt een vast budget, zeker omdat de scope van het geheel nog niet vast staat. Als we een deel gaan doen, en dat kost X, kan het zijn dat het veel gustiger is om nog wat extra dingen te doen, wat Y kost. Dan kan Y best duurder uitvallen, maar voor de baas profitabeler zijn op den duur.. Dit soort dingen kun je niet bepalen zonder de techniek te doorgronden.

Edit: Ik heb zojuist wat benchmarks binnengekregen van de EonStor producten. Het verschil tussen iSCSI en FC is hier wel duidelijk zichtbaar. Ongeveer het dubbele aantal IOPS en dubbele transfer rates uit het zelfde aantal disks. Wat je wel ziet is dat de iSCSI oplossing mooi mee schaalt met het aantal netwerk poorten dat je gebruikt. De resultaten zijn zeker wel respectabel en zou zelfs voor onze grootste database voldoende performance moeten kunnen bieden, al zullen we die zeker niet als eerste op dit potentieel systeem aansluiten. Kans is groot dat het kleine prijsverschil de keuze voor FC kan rechtvaardigen...

[ Voor 20% gewijzigd door voodooless op 21-04-2009 19:24 ]

[Renegade]

Ik heb dit topic jammer genoeg vandaag pas ontdekt. Zelf zit ik hier uitsluitend tussen the verschillende HA storage vormen (voornamelijke EMC, NetApp, HP, HDS), waarbij ik zelf ook moet zeggen dat het niet echt uitmaakt welk product ik tot nog toe gebruikt heb, over de hele breedte is te zien dat iSCSI weliswaar redelijk goed scaled, maar je vooral bij IO-intensieve apps ziet dat je hier redelijke nadelen hebt. Bij RAW devices is de ervaring over het algemeen een 40% langzamer dan via FCSW, en op het moment dat je via de normale LUNs gaat met een FS daarop zit je al snel rond de 60%. Daarbij moet ik zeggen dat we in ons geval performance gemeten hebben over een normale workload simulatie, in een productieve omgeving (2-tier en 3-tier ERP en CRM) en onder stress-test voor produktvalidatie en testomgevingen. NIC-bonding kun je op dat moment wel toepassen maar de kaarten die daar officieel ondersteund worden en een eigen CPU hebben om het systeem niet te belasten zijn ook aardig aan de prijs.

Op het moment dat je gebruik wil maken van HA zul je al snel moeten gaan kijken naar MPIO, je ontkomt gewoon niet aan meerdere paden naar je storage toe. Clustering is een optie, want alleen de HA-module van ESX geeft je wel de mogelijkheid om je virtuele systeem te laten rebooten, maar schiet niet heel erg op op het moment dat je je applicatie(s) ook wil bewaken (klinkt alsof je dat wil, zit je in een productieomgeving?).

Ik ga nu richting huis, maar ik schrijf straks nog iets meer. Misschien kun je je omgeving nog iets meer detailleren of wat voor een eisen je hebt?

[Ethirty]

In de nieuwe ESX4/vSphere zit een clustering-achtige oplossing: Fault Tolerance, draait een 1-op-1 schaduw van je VM op een andere host, tot aan elke cpu-instructie en geheugenmapping toe.

[voodooless]

Ethirty schreef op woensdag 22 april 2009 @ 18:35:
In de nieuwe ESX4/vSphere zit een clustering-achtige oplossing: Fault Tolerance, draait een 1-op-1 schaduw van je VM op een andere host, tot aan elke cpu-instructie en geheugenmapping toe.

Heb ik gezien. Op zich erg interessant, al verwacht ik hier toch wel een flinke performance drop. Daar is echter nog niet echt iets over te vinden.

[Ethirty]

Er zijn met vSphere, volgens VMware dan, juist enorme performance winsten te behalen. Wel zit je voor FT vast aan bepaalde CPU generaties. Een Xeon 5100 en 5500 mixen kan bijv niet.

[voodooless]

Ethirty schreef op woensdag 22 april 2009 @ 19:32:
Er zijn met vSphere, volgens VMware dan, juist enorme performance winsten te behalen. Wel zit je voor FT vast aan bepaalde CPU generaties. Een Xeon 5100 en 5500 mixen kan bijv niet.

Mja, ik heb vanmiddag een leuk filmpje gezien daarover, maar echt overtuigend vond ik het niet. Op de zelfde hardware is een VM altijd trager dan op de naakte hardware. 't is leuk als je als server een dikke 4x 4-core machine hebt, terwijl de orginele machine op verouderde hardware draaide. Logisch dat het dan ook met VMware erg hard gaat...

vSphere is niet meer dan een update van Infrastructure. De hypervisor is gewoon dat wat we al kenden. Ik verwacht dus eigenlijk niet dat performance nu opeens zoveel beter zal zijn.

Wat betreft FT al helemaal niet. Je moet constant de state van twee CPU's aan elkaar gelijk houden, en dat kost je gewoon veel bandbreedte. Ik vraag me af hoe goed dat werkt op een Gbit link. Misschien valt het ook wel allemaal mee.. Helaas is daarover nog weinig te vinden.

Prijstechnisch is het ook weer een grote warboel geworden van pakketten Een goed gaan uitzoeken hoe dit nu weer in elkaar zit

[Ethirty]

Eerst bepalen welke van de technische functies je in je omgeving zoekt (HA, DRS, FT, etc) en dan de bijbehorende pakketjes erbij zoeken (verwacht je FT toch niet te gaan gebruiken, dan scheelt dat weer een hoop centjes). Ze richten zich nu voor het eerst ook op het SMB en hebben enkele functionaliteiten uit de hogere versies door laten druppelen zodat de kleintjes daar ook mee kunnen spelen.

[voodooless]

Mja, ontbreken van vMotion, maar wel hebben van HA vind ik nogal vreemd. Dat dwingt je eigenlijk altijd om het pakket met vMotion te nemen, want eigenlijk wil je altijd wel beiden hebben...

Wat betreft FT. Daar hangen nogal wat haken en ogen aan. Zo werkt het enkel met een uniprocessor VM. Verder dien je het liefst een 10Gbit verbinding te hebben tussen de fysieke machines om het te laten werken (al claimen ze dat het ook met Gbit zou moeten werken). Verder wordt je memory acces trager omdat de hardware assisted MMU uitgeschakeld wordt. Met goede hardwaresetup is de performance drop zo'n 5%. Maar dat is wel een forse investering, en dan heb je nog steeds geen vm waar je een serieuze database op zou laten draaien..

[Ethirty]

Nee, maar je kan wel relatief simpel een Exchange duplicaat neerzetten of een belangrijke applicatieserver met lichte tot medium belasting. Tot voor kort was 'clustering' of failover van dat soort functionaliteit behoorlijk prijzig en meestal niet rendabel, zeker voor het MKB.

Dat je op je allerzwaarste Oracle database (of iets anders) een paar procent verlies pakt door je hypervisor is logisch, maar je wint wel op flexibiliteit. Al draai je 1:1 via de hypervisor, je verhuist je VM naar een andere host en je doet je onderhoud. Dat is rechtstreeks op de hardware draaiend een stuk lastiger. Voor nog 5% verlies heb je ineens wel een échte failover oplossing. Een hardwarematig cluster is prijzig en ook niet zomaar 1-2-3 opgezet. Het ligt natuurlijk aan de toepassing of dat in jouw geval een acceptabel verlies in performance is.

HA is gewoon dat binnen x seconden je VM weer gestart is vanaf een andere host, vMotion kan deze live verhuizen. Er zullen zat klanten zijn die het eerste belangrijker vinden dat het tweede, wat eigenlijk vooral handig is bij DRS.

Klink af en toe misschien een beetje als fanboy... vind het gewoon mooie techniek, ik werk niet voor ze

[ralpje]

Ethirty schreef op woensdag 22 april 2009 @ 23:05:
Nee, maar je kan wel relatief simpel een Exchange duplicaat neerzetten

Alleen dit vind ik al een mooi voorbeeld. Om een Exchange 2007 (met alle rollen) redundant uit te voeren, heb je geloof ik zes machines nodig, die allemaal (in de gemiddelde situatie) niet super belast worden. Virtualisatie kan dan een uitkomst zijn.

[Renegade]

Ethirty schreef op woensdag 22 april 2009 @ 23:05:
*snip*

HA is gewoon dat binnen x seconden je VM weer gestart is vanaf een andere host, vMotion kan deze live verhuizen. Er zullen zat klanten zijn die het eerste belangrijker vinden dat het tweede, wat eigenlijk vooral handig is bij DRS.

Ik vind vooral de term "HA" daarbij niet echt helemaal gelukkig gekozen. Uiteindelijk ben je gewoon je applicatie kwijt op het moment dat de VM op zijn smoel gaat. vMotion is op zich een redelijk leuke tool, maar kan tegenwoordig ook met Xen worden gedaan en op het moment dat je een Oracle (;P) box hebt staan kun je ook gewoon met een xVM Ops Center soortgelijke geintjes uithalen.

Ik kan me alleen maar bij je eerdere opmerking aansluiten.

Maak een footprint van je belangrijkste applicaties en eisen, en van je "doorsnee" systemen, daarbij kun je denken aan volgende zaken die je al dan niet nodig heb of kunt invullent:

[list]• DR
• HA-clustering
• HA applicatie
• load balancing
• hardware
• named user (indien van toepassing)
• concurrent user (indien van toepassing)
• IO (peak, doorsnee, mostly read, mostly read, etc)
• systeemeisen
• groei

Daarnaast zou je bij de keuze van je SAN ook nog kunnen overleggen wat je daar voor een groei verwacht. Al naar gelang zou ik bijvoorbeeld ook waarde hechten aan het type opslag (EFD, FICON SAS, SATA) of als je bijvoorbeeld al boxen hebt staan zou je kunnen overleggen of je bijvoorbeeld een HDS USP-V of een NetApp vFiler gaat gebruiken zodat je features als dedupe, thin provisioning en meer van dat soort geintjes kan gebruiken onafhankelijk van de storage box dat daarachter staat (wellicht is de actie van HDS interessant voor je?).

Uiteindelijk komt het er op aan wat je precies wil gaan doen en wat voor eisen je hebt. Één ding is in ieder geval zeker. Je nu verdiepen maakt het later alleen maar makkelijker, maar de eerste duik richting SAN is niet echt een makkelijke.

[ralpje]

Renegade schreef op donderdag 23 april 2009 @ 15:34:
[...]

Ik vind vooral de term "HA" daarbij niet echt helemaal gelukkig gekozen. Uiteindelijk ben je gewoon je applicatie kwijt op het moment dat de VM op zijn smoel gaat. v

High Availability is natuurlijk wat anders dan Always Available

[Renegade]

ralpje schreef op donderdag 23 april 2009 @ 15:44:
High Availability is natuurlijk wat anders dan Always Available

Always available is iets totaal anders. Daarbij is eerder te denken aan systemen die ook een fout tolerantie systeem hebben en transacties berekenen om daarna beoordeeld worden. Dat zijn meer de systemen die je terug zult vinden in vliegtuigen en atoomreactoren.

Maar high availability kan wel degelijk te maken hebben met de logica achter het systeem. Uiteindelijk wil je zo min mogelijk (niet geplande) downtime. Dat betekend automatisch dat je niet alleen met je hardware te maken hebt. Uptime is normaal gesproken de tijd die het gehele systeem beschikbaar is voor de eingebruiker. Als je box nog netjes pingt, maar de DB is op zijn gat gevlogen praat je over het algemeen over een downtime. Op het moment dat je een productieband gekoppelt hebt aan je systeem en je afhankelijk bent van je applicatie (geen idee trouwens of dat hier het geval is) zul je over een andere vorm van HA praten. Op dat moment is de VMware HA + vMotion een mooi systeem, maar het garandeert niet dat je applicatie ook automatisch restart of je een alarmering krijgt als je Oracle DB nog in de backup modus loopt na een crash. Zit je in de hosting business dan komen daar nog de DR situaties bij, waar je buitenlandse klanten kunenn eisen dat je een 2^e site hebt met een minimale afstand tussen de servers (site-spanning of zelfs geo-spanning).

Uiteindelijk komt het er op neer dat je duidelijk moet neerzetten wat je wil en je daarna pas wat zinnigs kunt zeggen over een mogelijke oplossing. Maar dat is zoals het ons tweakers betaamt, niet dan?

[TheBrain]

voodooless schreef op woensdag 22 april 2009 @ 19:39:
[...]

vSphere is niet meer dan een update van Infrastructure. De hypervisor is gewoon dat wat we al kenden. Ik verwacht dus eigenlijk niet dat performance nu opeens zoveel beter zal zijn.

Ook in de hypervisor zijn wijzigingen aangebracht. Deze is nu echt 64bit. Daarnaast zijn er legio veranderingen om bijvoorbeeld distributed virtual switching mogelijk te maken, het licentiebeheer is aangepast en nog veel meer.

De overhead van de hypervisor zit bij VMware nu nog maar in de enkele procenten.

[delorean7]

iSCSI of FCP maakt voor de meeste applicaties echt niet uit, er zijn echter wel een aantal gotcha's

- Storage controllers moeten in staat zijn meerdere interfaces aan te bieden naar een lun
- Storage controllers moeten een native ontsluiting voor iSCSI bieden (geen gateway rotzooi)
- OS moet ondersteuning hebben voor multiple connections per sessions (active-active MPIO - VMware infrastr 3 dus niet )
- Hou de maximale IO over 1 touwtje in de gaten (afhankelijk van block size)
- cpu overhead iSCSI is er, maar is echt niet dramatisch (40% is echt onzin)

Overigens is de keuze voor de storage controller vele malen interessanter dan iSCSI vs FCP, zaken als thin provisioning, snapshot technologie, monitoring (!), cluster technologie, schaalbaarheid, ondersteuning voor multi tier technologie, max IO controllers (niet cache een cache burst!), RAID technologie, etc. etc. etc. zijn veel belangrijker.

[Yalopa]

Ik snap niet waarom het OS active active moet ondersteunen. Als je een OS kiest (of in het geval van virtualisatie een hypervisor) kies je die in functie van je totaal plaatje. Als vmware in jou situatie het beste virtualisatie platform is dan heb je het active / passive verhaal meegenomen in je overweging.

Active active kan een zegen zijn, maar ook een vloek, zeker als je vertrouwt op redundancy, maar je doormiddel van active active alles volgestouwd hebt...

[delorean7]

Yalopa schreef op vrijdag 01 mei 2009 @ 12:43:
Ik snap niet waarom het OS active active moet ondersteunen. Als je een OS kiest (of in het geval van virtualisatie een hypervisor) kies je die in functie van je totaal plaatje. Als vmware in jou situatie het beste virtualisatie platform is dan heb je het active / passive verhaal meegenomen in je overweging.

Active active kan een zegen zijn, maar ook een vloek, zeker als je vertrouwt op redundancy, maar je doormiddel van active active alles volgestouwd hebt...

Eensch, eerlijk gezegd vind ik mcs (active-active) ondersteuning niet zo belangrijk, maar in een heel gering aantal gevallen is dat doorslaggevend. Dat gaat overigens wel veranderen wanneer we tig cores en meer dan 100 GB aan geheugen in servers gaan steken, maar dat is nu niet aan de orde.

Mijn punt is dat het een van de slecht begrepen factoren is in de afweging.

[Verwijderd]

Ik ben van mening dat er maar 1 echt goed storage systeem is voor een goede Virtuele Omgeving, voor nu en in de toekomst.
Een storage systeem zou net zo virtueel moeten zijn, als de virtualisatie software die op de server laag draait.
Eerdere punten die ik lees over EMC2 systemen die tot 150.000 iops aankunnen is natuurlijk zwaar overdreven. Dit zijn marketing/powerpoint nummers die nergens op getest zijn.Als je ervan uit gaat dat een enkele disk 150IOPS aan kan en het apparaat maar schaalbaar is tot rond de 150 disken, kan je zelf ook wel uitrekenen dat dit totale onzin is. De cache die in een aparaat zit is nl. in een virtuele omgeving ook redelijk waardeloos, omdat we hier vooral spreken over random IOPS.

Onafhankelijke testen vind je op de Storage Performance Council

Deze laten ook zien dat 3PAR Utility storage het snelste storage systeem is, vandaag de dag op de markt.
http://www.storageperform...800_executive-summary.pdf

Naast deze performance bieden ze ook de mogelijkheid voor een perfect schaalbare storage omgeving, voor zowel kleine storage omgevingen als hele grote (MySpace/Facebook draaien hier ook 100% op).

Informatie over 3Par kan je na lezen op www.3par.com
Of op de website van bijvoorbeeld VMWare : http://www.vmware.com/pdf/esx3_3par_util_stor.pdf

3PAR ondersteund zowel FC als iSCSI.
Meerdere active-active controllers
Verschillende Raid types voor verschillende performance behoeftes
Online migreren tussen deze raid-types
Read/Write Snapshots
Thin Provisioning
etc.

Modbreak:

Knip..

[ Voor 4% gewijzigd door Equator op 14-05-2009 16:00 . Reden: Beetje spam verwijderd ]

[Snow_King]

Je registreert je net en komt gelijk over een storage systeem praten? Werk je toevallig voor een dealer? Wat vertroebeld de discussie wel wat.

[Verwijderd]

Zag inderdaad al die discussies over Storage, en het leek me wel leuk om eraan mee te doen.
Het is niet de bedoeling om de discussie te vertroebelen, maar om daadwerkelijk iets toe te voegen aan dit draadje.
Er staan nl. heel veel onjuistheden in, met betrekking tot de verschillende storage leveranciers. Op de Storage Performance Council, kan je deze (on) juistheden gewoon controleren.

En ja, ik werk net als de meeste hier in de IT op het gebied van storage en virtualisatie. Heb ervaring met verschillende storage leveranciers, en 3Par is naar mijn mening verreweg het beste storage systeem op de markt als we praten over: High Availability SAN oplossingen. Zowieso Next Generation Storage producten hebben duidelijke meerwaarden dan de huidige grote storage leveranciers (EMC, HDS, NetApp, HP).
NextGen Storage oplossingen bieden nl. meer en slimmere functionaliteiten met zich mee dan deze traditionele storage producten die hun producten hebben ontwikkeld lang voordat VMWare (of andere virtualisatie technieken) gedragen werden door de markt en zijn hier dus niet goed op ingespeeld.

[Equator]

Modbreak:

Geen probleem natuurlijk dat je mee wilt doen in de discussie, maar spammen met je eigenbedrijf is niet de bedoeling
Als je linkjes wilt plaatsen naar documenten, prima, maar aanbieden om meer info op te sturen gaan we niet aan beginnen.

[TheBrain]

Verwijderd schreef op donderdag 14 mei 2009 @ 15:23:
NextGen Storage oplossingen bieden nl. meer en slimmere functionaliteiten met zich mee dan deze traditionele storage producten die hun producten hebben ontwikkeld lang voordat VMWare (of andere virtualisatie technieken) gedragen werden door de markt en zijn hier dus niet goed op ingespeeld.

Alsof storage vendors met zulke R&D budgetten niet inspelen op die trend. EMC was een van de eerste waarbij je vanuit je Service Console storage commando's op je SAN kon afschieten om maar een voorbeeld te noemen. Geen heel sterk argument.

[Guru Evi]

Ikzelf heb een FibreChannel systeem via XSan en Promise VTrak. Inderdaad een Apple shop maar de producten zijn enorm gemakkelijk en goedkoop voor een kleine onderneming. Eenmaal je begint krijg je ook telefonische ondersteuning van een SAN Engineer tijdens setup.

Prijzen zijn enorm moeilijk samen te stellen. Je gaat altijd meer betalen voor de schijven die je krijgt van de fabrikant dan deze dat je krijgt bij de computerwinkel om de hoek. De schijven zijn meestal het server-type (zelf al zijn ze SATA) van de reeks en hebben reeds een burn-in test voor enkele uren gehad zodat ze niet crashen zodra je ze opstart. Sommige fabrikanten claimen ook fine-tuning van de firmware voor hun producten alhoewel sommige claims meer marketing dan wetenschap zijn.

Daarnaast hangt de prijs ook af van je huidige installatie: heb je reeds een FibreChannel installatie dan kan het goedkoop zijn. Extra (redundante) FibreChannel switches kunnen echter gemakkelijk 6-20k kosten. Een volledige installatie (hba's, switches, backup) kan gemakkelijk 50-100k kosten voor een schampere 16TB op 1TB SATA schijven terwijl je nog duurder kunt gaan als je 16TB aan 320GB @ 15k SCSI schijven wilt of een RAM cache ervoor wilt zetten.

Wat ik eerst zou bekijken:
1) Is er een fabrikant die de verkoper van mijn software aanraadt.
2) Is er een fabrikant of product waar de consultant of degene die mijn systeem onderhoudt mee bekend is
3) Wat is de kost om een consultant te huren of mijn systeembeheerder te onderwijzen (afhankelijk van de fabrikant kun je je systeembeheerder naar de VS sturen voor 2 weken en naast de reiskosten 10k of meer aan een opleiding spenderen)
4) Wat zijn de kosten over de volgende 3-5 jaar. Moeten er nog jaarlijkse licentie of onderhouds kosten bijkomen of moeten mijn systeembeheerders elk jaar een week verspillen om gecertifieerd te blijven
5) Hoe snel kan ik onderdelen krijgen en gaat het bedrijf die mij iets verkoopt er nog steeds zijn als ik binnen 3 jaar met een stukke controller zit. Momenteel zijn er veel bedrijven die vanalles verkopen voor SAN's (vooral in de iSCSI en goedkope/nagelnieuwe oplossing afdeling) maar veel van die bedrijven hebben zulke excentrieke producten dat je jezelf afvraagt of iemand die dingen uberhaupt koopt.

[JaQ]

Ik ben Oracle DBA, dus ik bekijk HA en virtualisatie uit een heel andere hoek dan een storage, vmware of OS-man. Als een klant mij vraagt om een systeem HA te maken, vraag ik altijd als eerste: wat bedoel je precies? Pas als je in kaart hebt gebracht wat de klant zoekt, kan je technische keuzes maken. Natuurlijk kan je gave technische toys kopen, maar dat is volgens mij niet de opdracht van de TS. Ongefundeerd geldu uitgeven kan je beter doen aan mooie vrouwen, dure auto's en/of drank De omvang van de omgeving die geschetst wordt geeft m.i. niet direct aanleiding om voor een oplossing met SAN en virtualisatie te kiezen.

Zo las ik in dit topic o.a. als argument voor VMWare dat er vmotion onontbeerlijk was, immers zonder vmotion geen HA. Is het echter daadwerkelijk zo dat de business geen enkele seconde downtime accepteert? Rechtvaardigen de kosten van enkele minuten downtime de kosten van je vmotion licentie? Dit zijn businessvragen die je productkeuze bepalen. Ook las ik e.e.a. over het o zo handige templaten van VM's. In combinatie met de overweldigende hoeveelheid virtuele machines die je wilt bouwen denk ik echt dat je die feature niet kan missen *proest* Natuurlijk zijn beide features leuk en kunnen ze een doorslaand argument zijn om voor VMWare (of een ander product) te kiezen, maar als je een feature helemaal niet nodig hebt....

Hoe dan ook, zonder een business-wise onderbouwing kom je niet weg met een investeringsvoorstel. Zonder duidelijk de voordelen van een omgeving, met geldende argumenten, te beschrijven is de hele discussie omtrent iScsi-eilandjes etc. onzin.

[alt-92]

JaQ schreef op zondag 31 mei 2009 @ 16:32:
Ik ben Oracle DBA, dus ik bekijk HA en virtualisatie uit een heel andere hoek dan een storage, vmware of OS-man. Als een klant mij vraagt om een systeem HA te maken, vraag ik altijd als eerste: wat bedoel je precies? Pas als je in kaart hebt gebracht wat de klant zoekt, kan je technische keuzes maken.

En zo hoort het ook toch? Lijkt me nou niet iets wat enkel aan een DBA voorbehouden is

[JaQ]

alt-92 schreef op zondag 31 mei 2009 @ 22:23:
En zo hoort het ook toch? Lijkt me nou niet iets wat enkel aan een DBA voorbehouden is

Dat is zeker niet voorbehouden aan een DBA, maar in dit topic lijkt de techniek voorrang te hebben op de business en dat is m.i. een slecht uitgangspunt.

[robertobadjo]

hey even een interessant topic gevonden.

hopelijk zit ik hier goed met mijn vraag.

hier willen wij ook over op centralized storage. moet dan een SAN worden met 2 servers eraan en esx4 erop met HA.

nou heb ik 2 offertes gekregen voor 2 verschillende sans.

eerste is:

een IBM DS3300 iscsi dual controler
9x 450GB hot-swap 3.5
met 3 jaar onsite support

de 2de is:

een hp 2012i/DC modular smart array
9x 450gb 15k 3.5"
3jaar support erop.

iemand ervaring met deze 2 systemen??

de prijzen liggen rond de 14K in euro's incl btw.

wat er op komt te draaien is voor ongeveer 100 gebruikers maar wel met een exchange 2007 installatie erop simpele DC en een file server en hier en daar een aparte server voor TS of andere kleine dingen.

weet niet wat de kosten zijn voor een netapp maar die dingen schijnen ook erg goed te wezen maar aangezien wij een school zijn moet het wel enigzins lowbudget.

hopelijk zit ik hier goed en kan iemand mij antwoord geven op me vragen.

[SpamLame]

Ook NetApp levert instap modellen vraag eens een quote aan bv databasement, die doen (ook) hosted storage (alleen NetApp), maar dat terzijde.
Beide zijn goed, in de zin van gevestigde namen produkt(lijnen) die al een tijdje bestaan.
iSCSI is wat nieuwer dan het gevestigde FC(P), maar mag de pret niet drukken.
Persoonlijk neig ik naar HP spullen boel, ken hun EVA en MSA lijn en weet wat ik ervan verwachten kan.
IBM heb ik geen persoonlijke ervaring mee.
Welke merken aan servers hebben jullie? Misschien wil je dit van dezelfde leverancier betrekken ivm kortingen (of juist niet ivm vendor lock).

[robertobadjo]

heb al een ML380 G5 van HP maar daar moet er nog 1 bijkomen dan anders heeft HA geen zin.

hoe zit het eigenlijks met de performance. ik snap dat EQL nog altijd bovenaan staat kwa I/O maar zal ik echt vertraging merken in mijn vm's met deze sans??

eventueel alternatieven sta ik ook wel voor open.

ik heb ook een tijdje gekeken naar de qnap 809 pro. kost niet zo gek veel voor een soort van NAS/SAN voor 3200 heb je er 1 met 8TB.

alleen de performance is waarschijnlijk om te huilen.

[jep]

Je merkt pas dat je niet genoeg IOPS kunt doen als 't te laat is. Heb je niet de mogelijkheid om te kijken hoeveel je nu doet op die omgeving?

Ik heb zelf enkele Equallogic units en daarmee zit je zowieso helemaal goed.

[robertobadjo]

nou echt veel doen we niet echt bepaald in die omgeving.

denk dan in de trand van word en excel processing in zeer kleine mate. misschien hier en daar eens af en toe flinke datastromen omdat er een backup gemaakt word van bepaalde applicaties maar meer ook niet eigenlijks.

ik kan ook nergens vinden hoe de performance is van die 2 machines en ja met een EQL zit je altijd goed maar daar is ook de prijs naar

[jep]

Dan zou ik idd naar 1 van de door jou genoemde dozen kijken.

[robertobadjo]

heb jij ervaring met 1 van de genoemde dozen???

had vanmiddag een gesprek met iemand dat een DAS oplossing ook erg vlot was en zeker niet duur hoeft te wezen.

de HP 2012SA is een direct attach storage geval... snelheid zit dan wel goed of zit ik dan geheel fout?

[Ethirty]

Dan heb je weinig aan je 2e server volgens mij.

[SpamLame]

robertobadjo schreef op woensdag 03 juni 2009 @ 18:42:
heb jij ervaring met 1 van de genoemde dozen???

had vanmiddag een gesprek met iemand dat een DAS oplossing ook erg vlot was en zeker niet duur hoeft te wezen.

de HP 2012SA is een direct attach storage geval... snelheid zit dan wel goed of zit ik dan geheel fout?

Deze kan je (dacht ik) aan 2 server aansloten (enkelvouding) indie gecombineerd met een C bladeenclosure en SASswitch in een interconnect bay zelfs meer. (blades) dan Het hoeft dus niet perse een DAS oplossing te zijn.
Tjek http://h18006.www1.hp.com...rays/msa2000sa/index.html voor je opties.

[ Voor 8% gewijzigd door SpamLame op 03-06-2009 20:43 ]

[robertobadjo]

Ethirty schreef op woensdag 03 juni 2009 @ 18:57:
Dan heb je weinig aan je 2e server volgens mij.

je kan er tot 4 servers direct op aansluiten.

dus het heeft dan wel zin.

beetje HA kan nooit geen kwaad dacht ik zo

[jep]

Maar kun je met die DAS dozen ook meerdere dozen op 1 volume hangen?

[ralpje]

VMotion is met DAS wel mogelijk, maar niet supported.

[SpamLame]

jep schreef op donderdag 04 juni 2009 @ 10:13:
Maar kun je met die DAS dozen ook meerdere dozen op 1 volume hangen?

Dat is afhankelijk van de gebruikte doos, die moet ondersteunen dat je een volume aan meerdere hosts kan knoppen. In mijn ogen is de gebruikte interconnect (FC,SAS,iSCSI) niet van afhankelijk of andersom.
Maar goed een vendor kan daar een ander mening over hebben.
Anders gezegd neem de specs of manual van de dozen die je op het oog hebt een door.

ralpje schreef op donderdag 04 juni 2009 @ 10:22:
VMotion is met DAS wel mogelijk, maar niet supported.

Niet alleen als reactie op ralpje
Gaat het er bij VMotion niet om dat het shared storage moet zijn? Moet de interconnect dan uitmaken (even los van wat VMware daar oveer zegt)?

[ Voor 24% gewijzigd door SpamLame op 04-06-2009 10:41 ]