Onderwerp: SAN voor Xenserver

Oorspronkelijk geplaatst door Ahead-IT

Wido, ik lees dit:


Zit je dan bij vrij zware belasting (bv 400MB/s write, wat een SAS SANs gerust aankan) niet met twee SANs met elk verschillende data, omdat het nog niet gesynct is over de 1Gb verbinding?
Normaal moeten de SANs toch 1 op 1 (e.g. realtime) syncen? Je kan niet zomaar voor high-availability en realtime failover (VMware) een disk gaan koppelen via iSCSI failover die "iets" andere data bevat; anders heb je corrupte data? Bij ons doen we het syncen altijd over een 10GB verbinding met crossed cable, prijstechnisch nog steeds interessant; ; geen bottleneck en 1 op 1 synchnonisatie.

Daarvoor is juist protocol "C" in DRBD: http://www.drbd.org/users-guide/s-re...protocols.html

Daarmee sync je dus realtime en dat werkt goed. Op dit moment is in onze setup 1Gbit meer dan genoeg, op sommige machine's staat de syncer rate wel op 100M.

Maar je moet er wel voor zorgen dat beide machine's qua specs het zelfde zijn, anders krijg je rare bijwerkingen.

Bedankt voor de howto!

Oorspronkelijk geplaatst door Wido

Daarvoor is juist protocol "C" in DRBD: http://www.drbd.org/users-guide/s-re...protocols.html

Daarmee sync je dus realtime en dat werkt goed. Op dit moment is in onze setup 1Gbit meer dan genoeg, op sommige machine's staat de syncer rate wel op 100M.

Maar je moet er wel voor zorgen dat beide machine's qua specs het zelfde zijn, anders krijg je rare bijwerkingen.

Het uitgangspunt van DRBD is juist om realtime te syncen

Oorspronkelijk geplaatst door Thijs

Het uitgangspunt van DRBD is juist om realtime te syncen

Klopt, alleen heb je nog gradaties in hoe realtime A, B of C. Elk protocol met zijn voordelen en nadelen A is niet zo realtime als C is

Zijn er eigenlijk mensen die zelf al slechte ervaringen hebben gehad met openfiler? Ik ben deze nu enkele dagen intensief aan het testen (met enkel de iSCSI service enabled) en tot nu toe loopt dat echt perfect!

Bovendien kan je in openfiler via console ook heel eenvoudig DRBD en Heartbeat opzetten.

Oorspronkelijk geplaatst door GuusDeGraeve

Zijn er eigenlijk mensen die zelf al slechte ervaringen hebben gehad met openfiler? Ik ben deze nu enkele dagen intensief aan het testen (met enkel de iSCSI service enabled) en tot nu toe loopt dat echt perfect!

Hier in een test setup haalde die maar slechte resultaten in snelheid tegenover een eigen setup.

Tevens zijn er al meerdere verhalen dat die al zijn LVM's na een reboot wel eens kan vergeten.

Meerdere hangers op meerdere hardware bij echt intensief gebruik (lees echt de max van wat het ding toen kon)

Veel extratjes die draaien (ja zet je uit etc) maar toch, véél dingen die erin zitten die je niet nodig hebt als je enkel iSCSI gaat gebruiken.

Met webmin kan je stabieler LVM's gaan beheren. Het is niet dat je elke dag hierin moet gaan aanpassen, dus dat kan lijkt me van de CLI ook.


Nuja dat is mijn ervaring hierin.

Zelf ben ik echt wel te spreken over openfiler. Echter zijn er hier en daar toch wel belangrijke minpunten die ons tegenhouden om deze software te gaan gebruiken.

Zo is de performance waar Tim het al over had die abnormaal laag ligt. Een test met HDparm op CentOS van een Raid 5 met 3 hardeschijven gaf een disk read aan van 250MB/s. Openfiler echter met 5 hardeschijven in Raid 5 gaf zelfs maar een disk read van 131MB/s.
Daarnaast gebruikt Openfiler rPath wat het custom maken van dit systeem heel moeilijk maakt. Software om een hardware raid controller (MegaRaid van LSI in ons geval) te beheren is, buiten de CLI, niet mogelijk om te installeren.

Buiten dat is het control panel niet zo gebruiksvriendelijk opgebouwd. De support van dit project via het forum is ook niet echt om op terug te vallen in het geval van problemen.

Daarom ook dat wij waarschijnlijk toch zelf onze SAN zullen samen bouwen en gewoon iSCSI initiator zullen installeren op een CentOS.

Ook hier zal je eerst een lijstje moeten maken van wat je wil, en wat belangrijk is. Wil je alleen op een centrale plek data opslaan, wat voor performance eisen stel je daar aan. Wil je zelf 't beheer doen? Is uitbreidbaarheid belangrijk, etc.

Zelfbouw kan prima werken, een "echte" SAN kopen is natuurlijk niet alleen maar veel geld uitgeven. Je koopt ook bepaalde kosten af waar je anders zelf mee te maken krijgt (patch management, test omgeving, troubleshooting, kennisdeling). Verder kan het zijn dat een klant bepaalde eisen stelt. Als je een EMC SAN koopt weet je gewoon dat je storage omgeving een SLA heeft van 99,999%. Bij zelfbouw kan je dat hooguit bewijzen als je al een vergelijkbare oplossing langere tijd hebt staan, en dan blijft de populatie waarover de resultaten zijn berekend erg klein.

't Blijft een kwestie van vooraf prioriteiten en eisen stellen.

Oorspronkelijk geplaatst door Wido

Daarvoor is juist protocol "C" in DRBD: http://www.drbd.org/users-guide/s-re...protocols.html

Daarmee sync je dus realtime en dat werkt goed. Op dit moment is in onze setup 1Gbit meer dan genoeg, op sommige machine's staat de syncer rate wel op 100M.

Maar je moet er wel voor zorgen dat beide machine's qua specs het zelfde zijn, anders krijg je rare bijwerkingen.

Hey Wido,

Bedankt voor de mooie info wederom. Wij zijn op dit moment ook aan het oriënteren op nieuwe storage. Onze huidige open-e voldoet niet, de software levert ons meer problemen op dan dat het oplost.

Wat voor specs hebben jullie storage machines? Met name cpu/geheugen/raid controller/nics dan?

Alvast bedankt.

Oorspronkelijk geplaatst door Sander-

Hey Wido,

Bedankt voor de mooie info wederom. Wij zijn op dit moment ook aan het oriënteren op nieuwe storage. Onze huidige open-e voldoet niet, de software levert ons meer problemen op dan dat het oplost.

Wat voor specs hebben jullie storage machines? Met name cpu/geheugen/raid controller/nics dan?

Alvast bedankt.

Geen echte standaarden, maar we gebruiken twee modellen:

* 8x SAS (Dual Core, 8GB RAM)
* 16x SAS (Quad Core, 16GB RAM)

Dat is wat we ongeveer aanhouden, maar daarbij wel altijd een moederbord van minimaal 1.5 jaar oud, dit ivm driver ondersteuning e.d. Ook zijn daar de kinderziektes uit waardoor je een stuk stabieler systeem hebt.

Denk verder ook aan ECC Ram, BBU's voor je RAID Controller, redundante stroom, IPMI, etc, etc.

De echte performance van je storage komt toch uit je disks en RAID Controller, een snellere CPU of ander mobo gaat daar niet heel veel aan veranderen.

Zelf draaien wij op de X7 serie van SuperMicro, zowel in de 8x SAS als 16x SAS versies.

Verder de Areca ARC-1222 controller en de ARC-1680ix-16 (op de 1680 wat extra write-cache).

In de servers zit dan vaak nog een extra Intel Quad NIC kaart voor wat bonding en/of multipath.

Mag ik vragen hoeveel VPS-sen je hier van afdraait? Even een ruwe schatting, ligt natuurlijk helemaal aan wat voor klanten er op zitten, maar met een indicatie kan je tenminste enigzins een berekening maken tov SATA wat het nou eingelijk per vps kost.

Oorspronkelijk geplaatst door Bakker ICT

Mag ik vragen hoeveel VPS-sen je hier van afdraait? Even een ruwe schatting, ligt natuurlijk helemaal aan wat voor klanten er op zitten, maar met een indicatie kan je tenminste enigzins een berekening maken tov SATA wat het nou eingelijk per vps kost.

Mag je best vragen, maar is geen vergelijking op te maken. Het gaat om IOps, meer niet. Een VPS kan al een SAN van 16 disks plat trekken, maar je kan er ook 500 op draaien en allemaal niet zo veel doen.

@GuusDeGraeve:

Ben je ook al bekend met de Dell EqualLogic PS4000 serie? Die is vorige week woensdag gelanceerd en is gewoon een stuk goedkoper (heeft ook wat andere specs though).

Heb je daar al eens naar gekeken?

@wido Helemaal true, maar een normale/gemiddelde klant ? Ik neem aan dat je wel ongeveer weet hoeveel klanten je per SAN wilt hebben om het rendabel te hebben.

@DennisWijnberg Noem eens wat vanaf prijzen ? Voor de E en de X?

Ik heb ondertussen een Transtec Provigo 410 op de kop kunnen tikken . Heb dus voorlopig wat ik nodig heb. Nu de koppeling met een Xenserver pool nog in werking krijgen, blijkt ook niet simpel te zijn .