High Availability SAN overwegingen

[voodooless]

Wij staan momenteel op een punt om een groot deel van het serverpark te moeten vervangen. Aan de een kant omdat het oude meuk is waarvan we niet weten hoelang het nog blijft werken, en aan de andere kant omdat er wat nieuwe ontwikkelingen gaande zijn die een andere aanpak vergen. Aangezien wij een bedrijf zijn waar letterlijk rond om de klok gewerkt wordt en deze systemen van levensbelang kunnen zijn, is high availability voor (op zijn minst) een deel van de systemen van zeer groot belang.

Het idee is dus gevat om eerst een deel, en later steeds meer systemen te viritualiseren. Helaas zijn wij voor sommige toepassingen nog gebonden aan specifieke hardware die we niet viritueel kunnen draaien, zoals bijvoorbeeld een PCI ISDN adapter, of USB devices (dat kun je beperkt wel viritualiseren natuurlijk). Maar dat is maar een klein deel van de machines, en daar zijn ook vast wel oplossingen voor.

De rest zijn gewoon servers met diverse OS'en en toepassingen, die eigenlijk prima virtueel zouden kunnen draaien.

Omdat enkele servers ook tamelijk nieuw zijn kunnen die al prima gebruikt worden als VM machine. Eventueel een NIC erbij en wat memory, en ze zijn klaar . Virtualisatie zou gebeuren met XenServer. Gezien de kosten t.o.v VMWare en de wat openere structuur van het systeem lijkt ons dat voorlopig de betere keuze.

Anyway, dat is een beetje achtergrond. Waar we nu naar aan het kijken zijn is een SAN oplossing. En hierin vinden we een hele berg soorten en maten. Onze vaste hardware leverancier heeft twee producten in zijn mars:

- Infortrend EonStor storage systemen, dual controller, MPIO, uitbreidbaar met extra bay's, FC of iSCSI met genoeg bandbreedte, nette tools, relatief goedkoop
- Compellent storage platform, waar alleen al een 1TB SATA disk 750 euro moet kosten (i.p.v 151,- via pricewatch), erg mooie software, interessant mogelijkheden door middel van tiered storage voor een mix van SSD, SAS/FC en SATA, voor optimale performance. Maar erg duur over het algemeen (rip-off budget), en ook nog eens extra kosten voor alle leuke software features.

Belangrijk verschil tussen de twee - in ieder geval, voor zover ik heb kunnen begrijpen, want zo happig zijn ze allemaal niet met duidelijke informatie - is dat de Compellent op block level LUN's van uitdelen, waar bij de EonStor vast zit op LUN's die bestaan uit een combo van logical drives. Dat is natuurlijk een groot voordeel van de Compellent, waar je storage gewoon ergens op de disks staan, maar je weet niet waar. Maar misschien heb ik dat wel verkeerd gezien..

Aan de andere kant heb je voor onder de 20K een EonStor systeem staan, volledig redundant, met 16x 450GB 15k SAS, en 16x 1TB SAS, 8xFC.. om maar eens even wat te noemen (zonder FC switch) . Bij Compllent heb je dan enkel twee controllers, geen disks, en geen licenties. Lijkt me dus een duidelijk verhaal

We zijn echter nog verder aan het kijken. Dell heeft oplossingen van Equallogic en EMC die beiden ook prima zouden moeten werken, helaas wacht ik hier nog op prijzen. Ik heb ook nog geinformeerd bij NetApp, maar daarvan heb ik nog niets vernomen.

De tweede vraag is iSCSI of FC? Uit kostenoogpunt zou ik eigenlijk iSCSI nemen. Gezien de load die ik verwacht is dat voor de meeste machines meer dan zat, er zijn echter wat database toepassingen waar het krap zou kunnen worden, vooral kwa iops omdat de overhead hier toch voor wat vertraging gaat zorgen. Het bundelen van NIC's kan hier echter eenvoudig een oplossing bieden indien nodig.

Storage plek is een ander verhaal. We hebben een toepassing waarvan we verwachten dat deze 10TB nodig zal hebben, en dat is natuurlijk best fors. Gelukkig hoeft dat geen high performance storage te zijn.

Wat over de te verwachten load: In eerste instantie zullen er twee Windows 2003 machines met Citrix, een linux fileserver, en linux router geviritualiseerd worden. Load op het filesysteem zal niet erg hoog zijn op deze systemen. Daarna zal er een database op gaan draaien van enkele GB's, met veel inserts, waardoor redelijk wat io zal ontstaan. De 10 TB zal verbruikt worden door video-opslag en wordt iedere maand ververst. En dan hebben we uiteindelijk nog wat lichte applicatieservers, waarvan de meesten linux draaien.

Als allerlaatste hebben we dan nog een database server, die tegen die tijd wellicht een database van tussen de 300GB tot 500GB zal hebben. Deze draait nu nog op een losse machine met een flink disk array. De vraag is of dat ooit wel goed genoeg op een SAN zal draaien. Aan de andere kant zijn SAN's natuurlijk uitermate geschikt voor veel IO's.

Kortom: Er zijn een heleboel overwegingen te maken, en ik hoop dat jullie nog wat tips hebben? Misschien heb ik dingen over het hoofd gezien, of hebben jullie een heel andere insteek? Alle info is welkom

[Trax_Digitizer]

(Even diep in mijn geheugen graven, want mijn SAN kennis dateert uit 2003).

Bij grote prijsverschillen gaan er bij mij al belletjes rinkelen. Ik weet uit ervaring dat FC-disks erg duur zijn. In 2003 betaalde je voor een "Dell I EMC 73 GB FC-2 10.000 RPM (1,0") Hard Drive (100 MB/sec.)" 1455 euro. Dat zal inmiddels wel flink goedkoper zijn, maar ik zou gewoon eens wat RFP-tjes de deur uit doen.

Verder is het met name voor de IOPS belangrijk in de gaten te houden dat er genoeg cachegeheugen in je SAN zit. Ik hoef volgens mij niemand uit te leggen dat dit nog steeds vele malen sneller is dan de snelste FC-disk. Destijds kwam ik voor mijn project uit op een CX600 met 8 GB cache.

Je verhaal met de LUN's op blocklevel versus de LUN's op logical drives, kan ik niet helemaal volgen. Het grote voordeel van een SAN is dat deze juist LUN's op blocklevelniveau uitdeelt waarbij je volledig onafhankelijk bent geworden van de logical drives in je SAN array. Je kunt een LUN op elk willekeurig moment vergroten. Afhankelijk van het type filesystem wat je kiest, kun je zelfs zonder reboot/format van je server de opslagcapaciteit vergroten. Ik heb me er niet in verdiept maar die Infortrend oplossing klinkt een beetje als een middenweg, waarmee ik niet wil impliceren dat dit niet goed genoeg is.

iSCSI is inderdaad stukken goedkoper en zeker het overwegen waard. Zie ook deze link, waaruit blijkt dat FC niet altijd beter is. Het is afhankelijk van je toepassing en configuratie. In het geval van iSCSI zou ik zelf overigens voor een dedicated UTP-netwerk gaan.

Ik denk overigens dat de performance van je database server zal toenemen wanneer deze op een SAN draait. Een goed SAN laat een standaard SCSI disk array ver achter zich als het aankomt op performance. Voor puur en alleen storage waar performance niet zo'n issue is, zou je gebruik kunnen maken van andere (goedkopere) disks.

[voodooless]

Trax_Digitizer schreef op donderdag 16 april 2009 @ 00:06:
(Bij grote prijsverschillen gaan er bij mij al belletjes rinkelen. Ik weet uit ervaring dat FC-disks erg duur zijn. In 2003 betaalde je voor een "Dell I EMC 73 GB FC-2 10.000 RPM (1,0") Hard Drive (100 MB/sec.)" 1455 euro. Dat zal inmiddels wel flink goedkoper zijn, maar ik zou gewoon eens wat RFP-tjes de deur uit doen.

Tja, 450 GB FC kost zo'n 560 euro. Compellent vraagt voor exact de zelfde disk 1850 van die muntjes... Dat is gewoon ronduit belachelijk.

Verder is het met name voor de IOPS belangrijk in de gaten te houden dat er genoeg cachegeheugen in je SAN zit. Ik hoef volgens mij niemand uit te leggen dat dit nog steeds vele malen sneller is dan de snelste FC-disk. Destijds kwam ik voor mijn project uit op een CX600 met 8 GB cache.

Uiteraard, gewoon helemaal volgooien die machine. Geheugen is niet duur

Je verhaal met de LUN's op blocklevel versus de LUN's op logical drives, kan ik niet helemaal volgen. Het grote voordeel van een SAN is dat deze juist LUN's op blocklevelniveau uitdeelt waarbij je volledig onafhankelijk bent geworden van de logical drives in je SAN array. Je kunt een LUN op elk willekeurig moment vergroten. Afhankelijk van het type filesystem wat je kiest, kun je zelfs zonder reboot/format van je server de opslagcapaciteit vergroten. Ik heb me er niet in verdiept maar die Infortrend oplossing klinkt een beetje als een middenweg, waarmee ik niet wil impliceren dat dit niet goed genoeg is.

Ik volge het zelf ook allemaal niet helemaal meer. Het nare is dat je van geen enkel product echt hoogte kan krijgen via de informatie die op hun website staan Men laat het liefst zo veel mogelijk zo vaag mogelijk, lijkt he wel.

iSCSI is inderdaad stukken goedkoper en zeker het overwegen waard. Zie ook deze link, waaruit blijkt dat FC niet altijd beter is. Het is afhankelijk van je toepassing en configuratie. In het geval van iSCSI zou ik zelf overigens voor een dedicated UTP-netwerk gaan.

Uiteraard. Het plan was om iedere controller te verbinden met twee switches die onderling weer getacked zijn, en de VM servers met twee NIC's op ieder van de switches weer aan te sluiten. MPIO zou de rest moeten doen. Normaal netwerk verkeer gaat dan via de 3e NIC poort op de VM's.

Ik denk overigens dat de performance van je database server zal toenemen wanneer deze op een SAN draait. Een goed SAN laat een standaard SCSI disk array ver achter zich als het aankomt op performance. Voor puur en alleen storage waar performance niet zo'n issue is, zou je gebruik kunnen maken van andere (goedkopere) disks.

Nou, we halen zo zo'n 12.000 read iops (8k request) op onze huidige machine met 16x 15k SAS in real-life database situaties. Als ik zo naar de SAN's kijk, dan is dat denk ik wel haalbaar zou moeten zijn. Ik denk dat dat gewoon een kwestie van testen zal zijn.

[Verwijderd]

virtualiseren is niet de enige manier om high availability te garanderen (waarschijnlijk wel de goedkoopste). Je moet je altijd afvragen of het wel zinvol is. En je toch niet te vastgepint wordt op 1 spil (bijv. een SAN).

iScsi zou ik zowieso niet aan beginnen. Het is inderdaad een stuk goedkoper, maar ik zou liever voor een aantal bijv de msa2212fc van HP gaan (msa2000 zoeken, 2212fc kan oud type zijn ). Een aantal lijkt natuurlijk weer overdrijven, maar het is goedkoper als je hiermee geen fiberswitches hoeft te kopen (max 4 servers per san of 2 servers redundant te koppelen). En het voorkomt ook de shit van toch problemen in je totaal redundant zijnde SAN.

ik zal wel weer negatief zijn, maar van de week ook weer problemen meegemaakt in een "volledig redundant-zijnde" SAN waardoor er 150 vm's problemen hadden. Natuurlijk werd dit alles gesynct naar een andere SAN, waar exact dezelfde problemen waren . Ik ben dan ook van mening dat je moet uitkijken om alles te virtualiseren in high avail omgevingen, omdat je vaak toch een aantal redundante SPOF's (hahaha, ik hoop dat je begrijpt wat ik bedoel) introduceert, waardoor wel heel je omgeving in 1x kan omvallen ipv 1 servertje.

[voodooless]

iScsi zou ik zowieso niet aan beginnen.

Onderbouwing zou wel zinvol zijn.. Van wat ik lees zijn de meningen nogal verdeeld, met van beide kanten goede voor en tegenargumenten.

Het is inderdaad een stuk goedkoper, maar ik zou liever voor een aantal bijv de msa2212fc van HP gaan (msa2000 zoeken, 2212fc kan oud type zijn ). Een aantal lijkt natuurlijk weer overdrijven, maar het is goedkoper als je hiermee geen fiberswitches hoeft te kopen (max 4 servers per san of 2 servers redundant te koppelen). En het voorkomt ook de shit van toch problemen in je totaal redundant zijnde SAN.

ik zal wel weer negatief zijn, maar van de week ook weer problemen meegemaakt in een "volledig redundant-zijnde" SAN waardoor er 150 vm's problemen hadden. Natuurlijk werd dit alles gesynct naar een andere SAN, waar exact dezelfde problemen waren . Ik ben dan ook van mening dat je moet uitkijken om alles te virtualiseren in high avail omgevingen, omdat je vaak toch een aantal redundante SPOF's (hahaha, ik hoop dat je begrijpt wat ik bedoel) introduceert, waardoor wel heel je omgeving in 1x kan omvallen ipv 1 servertje.

Tja, dat is natuurlijk iets waar je voor moet waken, en sommige dingen kun je nu eenmaal niet volledig indekken, met name omdat je afhankelijk hebt van meuk van derden. We zullen ook zeker niet alles virtualiseren, of voor alles kiezen om de storage op de SAN te houden. Je kunt er bijvoorbeeld voor kiezen om een aantal applicaties die toch al zelf replicerend of redundant zijn te draaien in VM uit een lokaal filesysteem. Mocht de SAN falen, draaien deze gewoon door.

En dan hebben we natuurlijk nog het budget, dat niet vreselijk ruim is

[TheBrain]

Je geeft aan dat je wel high availability wil maar er blijkbaar geen budget voor is. Hoe belangrijk is het dan vraag ik me af?

Als het echt heel belangrijk is dan zal men toch een keer de portemonnee moeten trekken.

Dat punt even daargelaten:
Het belangrijkste voordat je aan de slag gaat met het ontwerp is de nulmeting van je huidige omgeving. Dat kan je uitbesteden maar ook zelf doen (als je tenminste weet hoe je de meetgegevens moet interpreteren of je daarin wil verdiepen. Wij gebruiken bij dergelijke assessments in de regel PowerRecon van Platespin. Met die software krijg je een volledig inzicht in je omgeving en worden er gedurende een door jou bepaalde periode (hou rekening met cycli in bedrijfsprocessen -- salarisverwerking eens per maand en dergelijke --) alle verbruiksstatistieken van de omgeving in een database gestopt. PowerRecon kan je ook kopen specifiek voor een consolidatieproject dus voor een vast aantal serverdagen. Het aantal serverdagen dat je nodig hebt is het aantal servers * het aantal dagen dat je gaat monitoren.

Op basis van die statistieken en de gegevens van de storage- en server leveranciers kan je consolidatiescenario's vaststellen. Tevens kan je op basis van de gegevens besluiten of je nog extra gegevens nodig hebt. Voor hele I/O intensieve applicaties kan je (in Windows) ook de perfmon statistieken uitlezen om een indicatie te krijgen van het aantal IOPS dat de server genereert.

Op basis van die statistieken valt ook een onderbouwd oordeel te geven of iSCSI een optie is of dat je het direct in de FC hoek moet zoeken. Tevens moet je ingaan op de toekomstplannen, statistieken van de storagegroei, middellange termijnbeleid van de company (zijn er overnames op komst bijvoorbeeld) en of er ook gerepliceerd moet gaan worden naar een DR site.

Full disclosure: ik werk voor een VMware Partner maar heb geen directe relatie met Platespin of andere hardware leveranciers.

[ Voor 10% gewijzigd door TheBrain op 16-04-2009 16:55 . Reden: aanvullingen ]

[voodooless]

TheBrain schreef op donderdag 16 april 2009 @ 16:52:
Je geeft aan dat je wel high availability wil maar er blijkbaar geen budget voor is. Hoe belangrijk is het dan vraag ik me af?

Als het echt heel belangrijk is dan zal men toch een keer de portemonnee moeten trekken.

Tja, je snapt natuurlijk dat in huidige tijden budget een lastige zaak is, ook al gaat het prima bij ons. En ook al ga je veel geld uitgeven, wil dat nog steeds niet zeggen dat dat ook gerechtvaardigd is, of dat veel geld je automatisch bij een beter eindresultaat gaat brengen. Kortom: slim geld uitgeven is het belangrijkste. We zijn op zoek naar de beste bang voor onze bucks Ik kan in ieder geval mijn baas niet uitleggen waarom een schijf van 150 euro 5 keer over de kop moet omdat ie toevallig in een SAN gezet gaat worden.

Dat punt even daargelaten:
Het belangrijkste voordat je aan de slag gaat met het ontwerp is de nulmeting van je huidige omgeving. Dat kan je uitbesteden maar ook zelf doen (als je tenminste weet hoe je de meetgegevens moet interpreteren of je daarin wil verdiepen.

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

[ Voor 4% gewijzigd door voodooless op 16-04-2009 23:48 ]

[Trax_Digitizer]

Een prijsverschil van zo'n 1200 euro voor één enkele FC disk van 450 GB? Dat is inderdaad wel een heel groot verschil. Weet je dan zeker dat het precies dezelfde producten zijn? Klinkt als abnormaal namelijk, maar misschien is het dat ook wel.

Verder zie ik de term "redundante SPOF" voorbij komen. Ik snap wat er wordt bedoeld, maar een "redundante single piont of failure" klinkt natuurlijk wel heel gek, laat dan op zijn minst het woord single weg. Waarschijnlijk is dat ook de reden dat er "hahaha" achter staat. Maar goed, problemen kunnen er altijd komen. Maar het lijkt me erg sterk dat een SAN spontaan ineens faalt door hardware falen. Als je gerepliceerde SAN dezelfde problemen kent, dan lijkt het toch heel erg op een fout die is veroorzaakt door menselijk handelen. Dit kunt je niet voorkomen door op een (lager) gedecentraliseerd niveau voor verschillende losse redundante oplossing te kiezen. De kans dat iets misgaat is dan net zo groot. Ok, de impact is misschien kleiner, maar dat is ook afhankelijk van je configuratie. En bedenk dat meerdere "losse" oplossingen qua beheer ook weer lastiger zijn. Om menselijke fouten te voorkomen kun je beter duidelijke procedures opzetten met dubbelchecks (testomgeving) die het maken van fouten in de productieomgeving tot een minimum beperken.

Verder spreek je over 12.000 IOPS voor je huidige database server. Het SAN waar ik hierboven over sprak (CX600) haalt 150.000 IOPS, dus over de performance hoef jij je geen zorgen te maken. De belangrijkste vraag is echter wat nu echt nodig is. Persoonlijk zou ik iSCSI of FC op voorhand niet uitsluiten. Ik zou grofweg het volgende doen:

1. Breng de huidige situatie eens in kaart (nulmeeting)
2. Stel randvoorwaarden op (bijvoorbeeld budgettaire beperkingen)
3. Stel samen met de business een risicoanalyse op vanuit de primaire processen, op basis waarvan je kan bepalen aan welke performance- en beschikbaarheidseisen de systemen moeten voldoen.
4. Op basis van de performance- en beschikbaarheidseisen ga je vervolgens kijken welke oplossingen hier bij passen en wat de voor- en nadelen zijn. In deze stap komen dan ook de tips van TheBrain goed van pas.

Als het uiteindelijk te duur uitvalt, dan is dat op zich niet erg. Maak dan in ieder geval wel duidelijk dat met minder geld ook minder beschikbaarheid gegarandeerd kan worden. Risico's laten bestaan is op zich niet zo'n ramp, als de business zich maar bewust is van het geaccepteerde risico.

Kortom, mijn tip: eerste denken in behoeften (afdekken van risico's), daarna pas gaan nadenken over oplossingen. Anders kom je er toch niet uit.

[Dronium]

Als er twijfels zijn over de performance van iSCSI zou je je eens moeten oriënteren op 10 Gb Ethernet. In combinatie met virtualizatie leverd dat een aantal interressante voordelen op:
- Performanceboost qua netwerk doorvoer bij lage latencies
- Een stuk minder bekabeling
Daar moet dan natuurlijk wel een iSCSI appliance bij die 10 GbE ondersteund (StoneFly bv).

Ik ben zelf bezig met een implementatie op 10GbE voor een Esx omgeving waarbij we voor de servers van 6x 1GbE overschakelen op 1x 10GbE. Dit is dan een combo van bestaande server met een Stonefly Storage Concentrator en een Arista 10GbE switch.

[itlee]

als eigen ondernemer die gespecialiseerd is in implementatie van virtualisatie en vmware (o.a.), ik doe nog wat zaken maar dat even terzijde.

ik vind twee zaken er tegenstrijdig in je verhaal (wat Thebrain al aangaf) aan de ene kant wil je voor een spreekwoordelijk dubbeltje op het eerste san zitten en ten tweede je kiest producten waarvan ik me twijfels heb.

- xenserver is tot op zekere hoogte niet HET product om je belangerijke omgeving te virtualiseren
- keuze van hardware is wat bijzonder
- eisen stellen zeer hoogwaardige redundante omgevingen

beginnend bij het eerste, xenserver is een leuk product maar staat niet in verhouding wat vmware enterprise kan. (DRS, vmotion, ondersteuning voor hardware, software technisch goede support en is veel informatie over te vinden. Kostbaar maar elke euro waard.

- je keuze van hardware, echt 100% behoorlijk (te) technische keuze en niet business wise. wat stelt de business aan eisen en hoeveel geld heb je te besteden?
primair, kies altijd voor A:producten; HP, Dell, IBM, san storage oplossingen (of blade)

- staar je niet blind op de IOps, op een single msa 2212fc met twee controllers haal je 18.000 iops, allemaal leuk maar zelfs de zwaarste kopieer acties (het deployen van vm uit een template) trek je 90 tot 100 mbyte per sec op je fiber san is maar een paar procent van je maximale belasting.

- als ik je fysieke machines bekijk, (sorry dat ik het zeg) is het niet echt spannend en kan je makkelijk op elk instap SAN van HP of dell prima draaien. (verschillende lun's achter verschillende storage processoren met eventueel mogelijk dubbele fiberpaden naar je SAN toe.)

- serverkeuze, absoluut belangerijk is niet het merk/type wat je kiest maar het MOET op de HCL zijn van het virtualisatie product wat je koopt. (vmware of xen)

- pricewatch vergelijken met een SAN schijf, is niet helemaal reeel, is op het zelfde nivo als 20mb tele2 internet thuis of een 2mb sdsl 1:1 met QOS full managed. ene kost 20eur p.m. andere 450 eur. p.m.

- iscsi is for low end storage prima oplossing, isci en hoge datathroughput gaan niet samen. dus voor je databases, mail, file gebeuren fiber gebruiken, voor archief/vmdk backup en low end gebeuren kan je isci prima gebruiken.

- TE redundant maakt onnodig complex bij update'n en maakt het beheer er ook niet makkelijker op. dus hou het een beetje simpel en gebruik je boerenvestand. als je tophardware koopt sluit een goed servicecontract af, is belangerijker dan drie dubbele san replicatie met dubbele fiberswitches, dubbele hba's en 6 dubbele redundante NIC's.

conclusie:

koop een isci bak voor je low end storage, data stroom via een apart vlan, geen dubbele switches maar gewoon knappe bekabeling en een knappe switch.

koop een hp/dell san msa2000/cx320 voor je high end storage, hoeveelheid zelf invullen.
koop geen equalogic, te duur, ze omzeilen alle features van vmware en ze willen je windows bakken met isci drivers rechtstreeks tegen een raw lun/partities laten aanpraten (om de snelheid te garanderen)

koop een hp/dell servers met voldoende geheugen begin met 12 of 16gb. 2 stuks. met 2x2 port nics of 3x2 nics. dual quad core is prima. local storage is raid 1 prima.

koop vmware en geen enkel ander product tis het beste wat je kan kopen en je kan bijna alles virtualiseren. (geen isdn meuk inderdaad)

san replicatie zou ik nu nog niet doen,....t is nog niet af,...en te fout gevoelig...
zorg voor een goeie backup van je vmdk's (esxranger van vizioncore bijv.)

wil je nog meer weten/vragen, kan je me inhuren...

succes met je keuzes.

[voodooless]

Als eerste wil ik alvast iedereen bedanken voor de bijdragen. Er zitten een paar nuttige tips tussen, en zeker ook dingen die we over het hoofd hebben gezien.

itlee schreef op vrijdag 17 april 2009 @ 00:05:
beginnend bij het eerste, xenserver is een leuk product maar staat niet in verhouding wat vmware enterprise kan. (DRS, vmotion, ondersteuning voor hardware, software technisch goede support en is veel informatie over te vinden. Kostbaar maar elke euro waard.

Niet?
- DRS: vind ik eigenlijk niet zo heel boeiend, zeker niet als je begint met een klein park van zeg 2 machines.
- Vmotion: heet bij Xen gewoon XenMotion en werkt grofweg hetzelfde
- ondersteuning van hardware: Aangezien Xen op een linux bases hypervisor draait zit je niet zo strak vast aan certified hardware, en is de support voor diverse hardware zeker niet minder dan bij VMware.
- support: geen idee hoe goed die is, nog bij Xen, nog bij VMWare

- je keuze van hardware, echt 100% behoorlijk (te) technische keuze en niet business wise. wat stelt de business aan eisen en hoeveel geld heb je te besteden?
primair, kies altijd voor A:producten; HP, Dell, IBM, san storage oplossingen (of blade)

Daar gaan we zeker ook naar kijken. Ik vind het echter een beetje makkelijk om de minder bekende links te laten liggen.

- staar je niet blind op de IOps, op een single msa 2212fc met twee controllers haal je 18.000 iops, allemaal leuk maar zelfs de zwaarste kopieer acties (het deployen van vm uit een template) trek je 90 tot 100 mbyte per sec op je fiber san is maar een paar procent van je maximale belasting.

Ik staar me zeker niet blind op IOPS. Echter is bij een dergelijke database waar ik het over had, is het aantal IOPS van groot belang. Met 12.000 iops van 8K is bijvoorbeeld je 1GB iSCSI kanaal gewoon vol. Op zich zou dat echter voor de betreffende databaseserver voldoende goed werken.

- als ik je fysieke machines bekijk, (sorry dat ik het zeg) is het niet echt spannend en kan je makkelijk op elk instap SAN van HP of dell prima draaien. (verschillende lun's achter verschillende storage processoren met eventueel mogelijk dubbele fiberpaden naar je SAN toe.)

Dat lijkt mij ook voor de meeste dingen zo te zijn. Alleen de instapmodellen bieden vaak helaas weinig redundancy, en dat is toch wel iets dat vereist wordt.

- serverkeuze, absoluut belangerijk is niet het merk/type wat je kiest maar het MOET op de HCL zijn van het virtualisatie product wat je koopt. (vmware of xen)

De aangeboden SAN's zijn beiden voor VMware gecertificeerd. Voor Xen gelden dit soort strenge eisen niet voor zover ik weet.

- pricewatch vergelijken met een SAN schijf, is niet helemaal reeel, is op het zelfde nivo als 20mb tele2 internet thuis of een 2mb sdsl 1:1 met QOS full managed. ene kost 20eur p.m. andere 450 eur. p.m.

Dat is appels en peren vergelijken. We hebben het hier over exact de zelfde hardware. Gewoon het zelfde ding. Je moet dan wel erg goede service erbij leveren wil je de 5 vijfvoudige prijs rechtvaardigen... Ik wil best voor de SAN betalen, en iets extra's voor de disk is ook best oke.

- iscsi is for low end storage prima oplossing, isci en hoge datathroughput gaan niet samen. dus voor je databases, mail, file gebeuren fiber gebruiken, voor archief/vmdk backup en low end gebeuren kan je isci prima gebruiken.

Zolang 10GB duurder is dan FC is dat zeker waar. Ik zoek ook het liefst een oplossing waar beiden (1GB/FC) mogelijk is, of je moet, zoals je al eerder aangaf, twee losse SAN's gebruiken. De vraag is echter of dat niet duurder is?

- TE redundant maakt onnodig complex bij update'n en maakt het beheer er ook niet makkelijker op. dus hou het een beetje simpel en gebruik je boerenvestand. als je tophardware koopt sluit een goed servicecontract af, is belangerijker dan drie dubbele san replicatie met dubbele fiberswitches, dubbele hba's en 6 dubbele redundante NIC's.

Dat is waarheid als een koe!

koop een isci bak voor je low end storage, data stroom via een apart vlan, geen dubbele switches maar gewoon knappe bekabeling en een knappe switch.

koop een hp/dell san msa2000/cx320 voor je high end storage, hoeveelheid zelf invullen.
koop geen equalogic, te duur, ze omzeilen alle features van vmware en ze willen je windows bakken met isci drivers rechtstreeks tegen een raw lun/partities laten aanpraten (om de snelheid te garanderen)

koop een hp/dell servers met voldoende geheugen begin met 12 of 16gb. 2 stuks. met 2x2 port nics of 3x2 nics. dual quad core is prima. local storage is raid 1 prima.

Dat is eigenlijk zo'n beetje het plan ja (al zouden dat niet perse Dell machines worden).

koop vmware en geen enkel ander product tis het beste wat je kan kopen en je kan bijna alles virtualiseren. (geen isdn meuk inderdaad)

Ik heb nog eigenlijk geen overtuigende argumenten gehoord om VMware te nemen. Over Xen hoor ik eigenlijk niets anders dan lovende dingen, ook uit productieomgevingen.

san replicatie zou ik nu nog niet doen,....t is nog niet af,...en te fout gevoelig...
zorg voor een goeie backup van je vmdk's (esxranger van vizioncore bijv.)

Dat was ik sowiso niet van plan. Good old backup werkt prima

[SpamLame]

Voor een kleine omgeving zou je iSCSI kunnen overwegen. Voor grotere omgeving is het in mijn ogen minder geschikt vanwege de lagere doorvoersnelheden.
Tuurlijk kan je daar met speciale nics en een afzonderlijk netwerk iets aan verbeteren. Met het inzetten van 10Ge kom je nog verder, maar de apparatuur (switch) is in de prijs niet echt veel verschil met een FC switch. Een 10Ge initiator (NIC met offload capabalities) heb ik nog niet gezien, maar zal evengoed niet goedkoop zijn.

[Ethirty]

voodooless schreef op donderdag 16 april 2009 @ 00:18:
Uiteraard, gewoon helemaal volgooien die machine. Geheugen is niet duur

Hier maak je mi een fout. Een SAN controller bevat een vaste hoeveelheid geheugen. Bijprikken is daar niet bij.

Ik mis in je verhaal een beetje hoeveel servers je gaat virtualiseren en hoeveel TB storage je nodig hebt. Met virtualisatie kan je beter met 8x 250GB dan met 2x1TB disks aan de gang, maar dan heb je wel meer cabinets nodig en véél disks als je ook nog eens veel opslag ruimte wil.

Ik zou in een productie SAN in ieder geval niet snel kiezen voor SATA/FATA maar voor SAS/FC disks.

Kijk eens naar de aangehaalde MSA2000 serie van HP, zitten geavanceerde functionaliteiten in van de hogere EVA serie zoals vArray. Leverbaar als FC, iSCSI en SAS. Hierover is onder de link genoeg docu te vinden. In de juiste config kan een heel cabinet aan disks wegvallen. Je kan in een MSA2000 ook SAS en SATA mixen voor een mooie balans tussen performance en capaciteit.

[ Voor 16% gewijzigd door Ethirty op 17-04-2009 12:53 . Reden: ik moet wel goed lezen ]

[voodooless]

Ethirty schreef op vrijdag 17 april 2009 @ 12:34:
Ik mis in je verhaal een beetje hoeveel servers je gaat virtualiseren en hoeveel TB storage je nodig hebt. Met virtualisatie kan je beter met 8x 250GB dan met 2x1TB disks aan de gang, maar dan heb je wel meer cabinets nodig en véél disks als je ook nog eens veel opslag ruimte wil.

Ongeveer 12 tot 15 TB aan trage storage, kan prima op 7200 rpm SATA/SAS disks. En voor het echte werk hebben we niet zoveel nodig (enkele TB is meer dan zat). Dat zou je met multiple 15k SAS disks kunnen doen.

Kijk eens naar de aangehaalde MSA2000 serie van HP, zitten geavanceerde functionaliteiten in van de hogere EVA serie zoals vArray. Leverbaar als FC, iSCSI en SAS. Hierover is onder de link genoeg docu te vinden. In de juiste config kan een heel cabinet aan disks wegvallen. Je kan in een MSA2000 ook SAS en SATA mixen voor een mooie balans tussen performance en capaciteit.

Dat is zeker een mooie oplossing, vergelijkbaar met de EonStor systemen, ook kwa prijs komt dat in de buurt.

Wat betereft geheugen bijprikken: ik heb al diverse producten gezien die upgradable zijn.

[ Voor 3% gewijzigd door voodooless op 17-04-2009 14:44 ]

[Ethirty]

Waarschijnlijk weet je het wel, maar hou in je calculaties ook rekening met de juiste raid-config's. Virtualisatie wil je R1+0 en 15TB aan data zeker in R6 (dat wordt dus al snel 18 of 19 disks, dus ook een extra cabinet weer). Vergeet ook niet voldoende hot-spares, 15TB rebuilden duurt wel even en het kan beter zsm beginnen.

[SpamLame]

@Ethirty: Wat is je motivatie om voor virtualisatie R1+0 te willen?
Als je het budget er voor hebt kan je het doen, maar het moet wel een probleem oplossen of meerwaarde hebben om de kosten te kunnen rechtvaardigen.
Ben met je eens dat meer kleinere spindles beter zijn voor de IOPS is dan minder maar grotere spindels, maar ook dat hangt weer af van de toepassing.

15Tb zou ik wegzetten op een aantal array's bestaande uit een 5 (of ander laag aantal) tal disken (R5 als uitgangspunt ivm de extra penalties van een R6 array).
Indien er dan gerebuild moet worden dan is dat sneller voor elkaar dan binnen 1 grote array, waar dat makkelijk een aantal dagen duren kan.
Mocht er dan toch een disk sneuvelen, wat niet ondenkbaar is bij disken die even oud en uit dezelfde batch komen, dan ben je minder data kwijt en heb je dus ook sneller gerestored.

@VooDooless
Enerzijds kan je op zoek gaan naar storage array's die zowel iSCSI als FC ondersteunen.
Zowel EMC als NetApp hebben zulke apparaten in de aanbieding, andere waarschijnlijk ook.
NetApp kan dan ook nog NFS of CIFS aanbieden waardoor je gelijk een NAS in huishaalt.
Anderzijds kan je beginnen met iSCSI of FC en wanneer noodzakelijk gateway's (bv van Brocade) aankopen om beide aan smaken aan te bieden danwel je iSCSI en FC SAN koppelen.

[Ethirty]

SpamLame schreef op vrijdag 17 april 2009 @ 16:33:
@Ethirty: Wat is je motivatie om voor virtualisatie R1+0 te willen?
Als je het budget er voor hebt kan je het doen, maar het moet wel een probleem oplossen of meerwaarde hebben om de kosten te kunnen rechtvaardigen.
Ben met je eens dat meer kleinere spindles beter zijn voor de IOPS is dan minder maar grotere spindels, maar ook dat hangt weer af van de toepassing.

R5 en R6 helemaal zijn wel snel met lezen maar traag met schrijven. Met 6*450 R1+0 heb je beperkte kosten, maar wel bijna 1.4TB ruimte. Als je dat dan afzet tegen een 4-disk R5 array dan zou ik toch kiezen voor de eerste. Of kan jij me overtuigen van een andere opzet?

15Tb zou ik wegzetten op een aantal array's bestaande uit een 5 (of ander laag aantal) tal disken (R5 als uitgangspunt ivm de extra penalties van een R6 array).
Indien er dan gerebuild moet worden dan is dat sneller voor elkaar dan binnen 1 grote array, waar dat makkelijk een aantal dagen duren kan.
Mocht er dan toch een disk sneuvelen, wat niet ondenkbaar is bij disken die even oud en uit dezelfde batch komen, dan ben je minder data kwijt en heb je dus ook sneller gerestored.

Als je 15TB aaneengesloten dataruimte wil gaat dit toch niet werken? Dan moet je in je OS de diverse lun's aan elkaar gaan knopen en in Windows betekent dat dynamic disks. brrrr...

Heb je 15TB aan totale ruimte verdeelt over diverse afdelingen/servers/whatever, dan geef ik je helemaal gelijk.

[A_De2]

Het belangrijkste wat ik tot hier heb gelezen is dat je vanuit de business requirements moet denken en daar een technische oplossing voor bedenkt. Ofwel, zoek je een antwoord bij een vraag of precies andersom?

Wat ik nog niet heb gezien is de argumentatie voor VMware of Xen. Waarom bijvoorbeeld geen Hyper-V? Een aantal zaken die je als uitgangspunt zou kunnen meenemen:
- Toekomstbestendigheid van de leverancier. Xen is bijvoorbeeld bezig richting Microsoft te schuifelen. Bestaat Xen over 2 jaar nog?
- Schaalbaarheid. Je gaf aan met 2 servers te beginnen. Dit gaat groeien naar? Denk daarbij aan de Microsoft licenties. Als je bijvoorbeeld W2K8 datacenter koopt (dacht 3K voor 2 cpu's) mag je op die host ongelimiteerd vm's aanmaken met W2K3 en W2K8. Dit geldt overigens ook als je VMware gebruikt. De Windows licentie "koppel" je aan de hardware.
- Welke technische kennis is vereist, aanwezig of hoe makkelijk kom je er aan als je het nodig hebt.
- Waar zitten je spof's en in welke mate zijn deze (de gevolgen als het knalt) door de business geaccepteerd?
- In je startpost heb je het over isdn adapters en usb keys. Als de isdn voor de fax is, kun je bijvoorbeeld ook faxen verzenden en ontvangen via de mailserver. o.a. Kpn heeft hiervoor een dienst. Usb keys worden nog wel eens gebruikt als software dongle. Misschien heeft de leverancier wel een andere authenticatiemiddel?
- Denk ook aan stroom en koeling. Virtuele systemen hebben de eigenschap relatief minder energie te verbruiken en dus minder warmte op te wekken. Echter, de concentratie van warmtebronnen is over het algemeen meer geconcentreerd (alle vm's starten vanaf hetzelfde san? Bladeservers? San-switches?) Overigens is energiekosten een mooi punt om mee te nemen in de tco berekening. In onze omgeving scheelt het tussen de 300 en 500 euro per vm per jaar aan energie en koelingskosten. Dat kan je wat wisselgeld opleveren om toch ff die technisch betere oplossing erdoorheen te krijgen. Het kost immers niet alleen geld, nee, het levert ook nog wat op. Altijd fijn toch?

Tot zover mijn "2 cents".

Succes met het pad naar je oplossing.

[SpamLame]

Ethirty schreef op vrijdag 17 april 2009 @ 16:42:
[...]

R5 en R6 helemaal zijn wel snel met lezen maar traag met schrijven. Met 6*450 R1+0 heb je beperkte kosten, maar wel bijna 1.4TB ruimte. Als je dat dan afzet tegen een 4-disk R5 array dan zou ik toch kiezen voor de eerste. Of kan jij me overtuigen van een andere opzet?

Overtuigen is niet mijn opzet geweest. Je deed de uitspraak dat je bij virtualisatie R1+0 wilt zonder motivatie erbij, vandaar. Overigens heb je gelijk dat R5 en zeker R6 minder goed zijn in schrijfacties vergeleken met R1+0.
Alleen is dat in mijn ogen niet enige wat mee moet wegen, aantal IOPS wat je nodig hebt/verwacht (IO profiel), gewenste capaciteit, budget, caching (algoritmes) van je controllers, beschikbaarheid. Alles (en misschien meer) bepalen wat de beste setup in theorie zou kunnen zijn.

Misschien wel de beste tip voor de TS, test het met je eigen omgeving, wat voor jou het beste werkt moet je doen. Als je niet kan testen vooraf kan je in de aanschaf misschien rekening houden met het duurste scenario (R1+0 bv). Indien later mocht lijken dat een R5 setup ook werkt heb je een gelijk wat speelruimte erbij.

Als je 15TB aaneengesloten dataruimte wil gaat dit toch niet werken? Dan moet je in je OS de diverse lun's aan elkaar gaan knopen en in Windows betekent dat dynamic disks. brrrr...

Heb je 15TB aan totale ruimte verdeelt over diverse afdelingen/servers/whatever, dan geef ik je helemaal gelijk.

Klopt, 15Tb aan een gesloten ruimte houd inderdaad in dynamic disk gebruiken onder windows (of LVM voor linux distro's). Zelf heb ik er niet zo'n problemen mee, maar ik heb dan ook geen ervaring met dynamic disken. Uit opmerking maak ik op dat je ervaring op dat vlak niet positief zijn. Vanuit LVM heb ik er wel vertrouwen in dat zo'n constructie goed gaat komen.
Maar links- of rechtsom blijft het geknutsel. 15Tb aaneengesloten (ik lees dan 1 Schijfletter/LUN
LVOL) backuppen is ook geen pretje.
De TS zal ook in deze voor zichzelf uit moeten maken (al dan niet geholpen door derden) wat het beste bij de wensen van zijn organisatie past en dat liefst binnen budget.

[ Voor 28% gewijzigd door SpamLame op 17-04-2009 19:01 ]

[voodooless]

A_De2 schreef op vrijdag 17 april 2009 @ 16:44:
Het belangrijkste wat ik tot hier heb gelezen is dat je vanuit de business requirements moet denken en daar een technische oplossing voor bedenkt. Ofwel, zoek je een antwoord bij een vraag of precies andersom?

Dat is zeker iets dat ik in mijn voorhoofd ga houden (in je achterhoofd ga je dit soort dingen vergeten ). Dat is nu ook een beetje het probleem. We weten het ongeveer wel, maar we moeten eens wat spul op papier gaan zetten, en dan kijken wat daarin past. Ik wil echter de techniek niet vergeten. Ik wil gewoon van te voren al weten wat er is en wat het kost.

Wat ik nog niet heb gezien is de argumentatie voor VMware of Xen. Waarom bijvoorbeeld geen Hyper-V? Een aantal zaken die je als uitgangspunt zou kunnen meenemen:
- Toekomstbestendigheid van de leverancier. Xen is bijvoorbeeld bezig richting Microsoft te schuifelen. Bestaat Xen over 2 jaar nog?

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

- Schaalbaarheid. Je gaf aan met 2 servers te beginnen. Dit gaat groeien naar? Denk daarbij aan de Microsoft licenties. Als je bijvoorbeeld W2K8 datacenter koopt (dacht 3K voor 2 cpu's) mag je op die host ongelimiteerd vm's aanmaken met W2K3 en W2K8. Dit geldt overigens ook als je VMware gebruikt. De Windows licentie "koppel" je aan de hardware.

We beginnen inderdaad met twee, en dat zal uitgroeien naar tussen de 5 tot 8 in de nabije toekomst. Afhankelijk van wat de toekomst brengt kan dat echter snel meer worden.

Licenties zijn inderdaad aan HW gekoppeld ongeacht de virtualisatie die je gebruikt. Meer dan 50% zijn sowieso linux machines, wat ook een rede is om in eerste instantie niet naar Hyper-V te kijken. 't kan wel, maar dat wil je eigenlijk niet.

- In je startpost heb je het over isdn adapters en usb keys. Als de isdn voor de fax is, kun je bijvoorbeeld ook faxen verzenden en ontvangen via de mailserver. o.a. Kpn heeft hiervoor een dienst. Usb keys worden nog wel eens gebruikt als software dongle. Misschien heeft de leverancier wel een andere authenticatiemiddel?

Nope, dat is geen oplossing. ISDN gebruiken we voor heel andere dingen, en daar hebben we persee een actieve ISDN controller met minimaal 8 kanalen (4x S0) voor nodig. Een soft oplossing bestaat hier helaas niet voor. USB zooi kun je ook via een netwerk naar USB interface regelen. Dan kan zelfs na een migratie naar een andere server, het USB spul gewoon nog werken, al is dat een SPOF (is niet erg, want dubbel uitgevoerd).

- Denk ook aan stroom en koeling. Virtuele systemen hebben de eigenschap relatief minder energie te verbruiken en dus minder warmte op te wekken. Echter, de concentratie van warmtebronnen is over het algemeen meer geconcentreerd (alle vm's starten vanaf hetzelfde san? Bladeservers? San-switches?) Overigens is energiekosten een mooi punt om mee te nemen in de tco berekening. In onze omgeving scheelt het tussen de 300 en 500 euro per vm per jaar aan energie en koelingskosten. Dat kan je wat wisselgeld opleveren om toch ff die technisch betere oplossing erdoorheen te krijgen. Het kost immers niet alleen geld, nee, het levert ook nog wat op. Altijd fijn toch?

Tja, er is net een tweede airco geïnstalleerd in onze ruimte. Maar dat was minder vanwege de capaciteit (dat kon nog net, maar meer omdat het een SPOF was. Kwa energiekosten ga ik het zeker eens uitrekenen, dat is misschien een mooi punt om wat centen terug te winnen.

De 10 TB die nodig zijn voor video komen helaas wel op een grote plek terecht. Niet echt ideaal, maar helaas is er geen andere mogelijkheid.

[Ethirty]

@SpamLame: Mja, misschien werkt R5 ook wel hoor, maar als ik bijv 10 servers op die lun wil zetten, dan heb ik in totaal volgens mij best wat IO en wil ik ook data kwijt dan ga ik best veel schrijf-acties krijgen.

Net deze week bij een klant een kleine test gedaan met 2 licht belastte Windows servers in hun testomgeving. Eerst op een 2 disk 15k R1 (oude opzet) en daarna 4 disk 10k R1+0. Boot-tijd verkorte van bijna 10min naar 30s. Machines reageren met alles nu ook gewoon vlotter. Nu weet ik nog niet of er op dat moment meer speelde, maar ik was behoorlijk verbaasd over het verschil.

Belangrijk voor TS is in ieder geval om zoals vermeld eerst een duidelijk kader te definieren (of zo duidelijk als mogelijk) en daar omheen je keuzes te gaan maken. Misschien komen zijn totale IOPS wel zo hoog uit dat hij eigenlijk naar een EVA-achtige omgeving moet gaan kijken, maar dan moet hij wel meer budget lospeuteren

@ hierboven: Als Xen richting MS gaat en je moet kiezen tussen Hyper-V en ESX, dan is de laatste denk ik een veel betere keus. VMware heeft jaren meer ervaring op dit vlak en inoveren veel meer. MS is alleen nog maar bezig met bijblijven.

[ Voor 11% gewijzigd door Ethirty op 17-04-2009 19:05 ]

[SpamLame]

Inhakend op warmteontwikkeling. Die van de pizzabox sanswitches vallen wel mij, tenzij je te intergreerd in een blade systeem. Niet dat ze dan meer warmte ontwikkelen maar het is wel geconcentreerder.
Storage arrays kunnen daarintegen al gauw veel warmte genereren, zeker als er veel activiteit is.

[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.