Virtueel serverpark

[Moszle]

Hoi Allemaal,

Binnen niet al te lange tijd willen wil ik gaan gaan beginnen met virtualisatie binnen ons huidige server park. In het verleden (zo'n 2 jaar geleden) hebben wij hiervoor al een EqualLogic storage (SAN) met 14 schijven van 250Gb p/st aangeschaft. Op dit moment staat alle data inclusief onze oude NAS server op de EqualLogic. Verder hebben we een 6 tal servers draaien waarvan 2 in eerste instantie gevirtualiseerd gaan worden. Dit zijn de Domaincontroller en de exchange server. Ook bestaat er de mogelijkheid om het complete serverpark direct mee te virtualiseren afhankelijk van de mogelijkheden en de kosten uiteraard.

De overige servers zijn SQL server, Terminal Server, Navision Server en een Navision Test server, allemaal uitgevoerd met windows 2003 server.

Als virtualisatie programma heb ik op het oog VMware Infrastructure 3 standard of enterprise edition. Wat ik in ieder geval als prioriteit stel is High Availability.

Op dit moment zit de EqualLogic redelijk vol met data, wat ik dan ook voor ogen heb is bij een complete server park virtualisatie de EqualLogic compleet vrij te maken voor virtual servers en de data over te zetten naar een NAS oplossing. Deze zou ik dan ook het liefst High Availability willen zien maar heb ze zelf nog niet gezien, wellicht heeft iemand hier een oplossing voor!

Een extra EqualLogic erbij is in mij ogen een behoorlijke zware investering. of wellicht is het een mogelijkheid om alleen de eerste 2 server te virtualiseren en over 2 jaar een extra equallogic erbij te nemen. Zit ik dan wel weer met het verhaal dat de eerste EqualLogic weer vervangen moet worden omdat die dan al dik 4 jaar oud is.

De domaincontroller en de exchange server zijn echt toe aan vervanging, Ook hiervoor zullen er dus 2 nieuwe server aangeschaft moeten worden.

Wat zouden jullie aanraden en hebben jullie nog suggesties?

[Ethirty]

In ieder geval je primaire DC absoluut niet virtualiseren, hoewel de meningen daarover nog verdeeld zijn.

Op de site van VMware is precies te vinden welke versies HA bevatten. Je kan ook overwegen om de starter edition te kopen en daar los HA bij te nemen.

Als je SAN nu vol zit dan ga je het niet redden. De ruimte voor je OS'en heb je ook nodig. 6 servers, zeg 20GB elk voor je C-schijf, daarbij komt nog diskruimte voor je interne geheugen, suspend files en evt snapshots. Kom je al snel op 300GB. En dit is nog zonder data.

Moszle schreef op vrijdag 17 april 2009 @ 22:13:
Op dit moment zit de EqualLogic redelijk vol met data, wat ik dan ook voor ogen heb is bij een complete server park virtualisatie de EqualLogic compleet vrij te maken voor virtual servers en de data over te zetten naar een NAS oplossing. Deze zou ik dan ook het liefst High Availability willen zien maar heb ze zelf nog niet gezien, wellicht heeft iemand hier een oplossing voor!

Hier heb je volgens mij niet helemaal door wat HA is: het idee dat als een host server down gaat de virtuele servers op een andere host weer opnieuw opstarten.

Kan je je EqualLogic niet voorzien van grotere/meer disks?

[ Voor 4% gewijzigd door Ethirty op 18-04-2009 21:58 ]

[ralpje]

Ethirty schreef op zaterdag 18 april 2009 @ 21:56:

Hier heb je volgens mij niet helemaal door wat HA is: het idee dat als een host server down gaat de virtuele servers op een andere host weer opnieuw opstarten.

Volgens mij heeft hij prima door wat HA is: High Availability, oftewel Hoog Beschikbaar. Met andere woorden: zo min mogelijk downtime. En het is inderdaad logisch dat als je je servers HA wilt hebben (bijvoorbeeld door virtualisatie met VMotion en DRS, maar het kan uiteraard ook op andere manieren) dat je dan de data op je NAS ook HA wilt hebben. Je hebt zo weinig aan je servers als je geen data hebt om mee te werken

Je NAS zou je dan weer HA kunnen maken door bijvoorbeeld twee van die dingen te mirroren of clusteren.

[Ethirty]

Hij wil zijn NAS High Availability en da's een software trucje van VMware

Hij bedoelde waarschijnlijk gewoon dubbel uitgevoerd (idd mirror of cluster) en dat kan met veel van de betere NAS'jes wel geregeld worden.

[Turdie]

Ik zou gaan voor VMware ESX 3.5.

Ook heb je Storage VMotion, wat je in staat stelt je virtual disken live te migereren tussen storage array's.Ook zul je vCenter nodig hebben om je VM's te managen.

Ik zou een extra Equallogic bij kopen, en alles gaan virtualiseren. En dus verschillende data-stores aanmaken, waarmee dus beide SAN's kunt gebruiken. Als je alles gaan virtualiseren kun je vast wel aan de bazen laten zien hoeveel dat op fysieke hardware bespaart, daar zijn ook mooi rekenmodellen voor, waar managers altijd helemaal gek van worden.Met P2V is 't tegenwoordig erg makkelijk om fysieke servers te migereren naar virtuele servers.

[ Voor 12% gewijzigd door Turdie op 18-04-2009 22:33 ]

[Ethirty]

shadowman12 schreef op zaterdag 18 april 2009 @ 22:21:
Als je alles gaan virtualiseren kun je vast wel aan de bazen laten zien hoeveel dat op fysieke hardware bespaart, daar zijn ook mooi rekenmodellen voor, waar managers altijd helemaal gek van worden.Met P2V is 't tegenwoordig erg makkelijk om fysieke servers te migereren naar virtuele servers.

Dat is bij 6 servers lastiger als bij 40. Je hebt minimaal 2 fysieke bakken, VMware en een SAN nodig en dat is bij elkaar niet goedkoop. Voor dat geld koop je ook wel 6 fatsoenlijke servers voor een traditionele omgeving.

[DukeBox]

Aangezien je EQL perfect werkt met ESX(i) zou ik toch daar mee verder gaan.
Je weet dat je de 250GB's kan upgraden in stappen van 250GB naar 1.5TB ?
Als ik er vanuit ga dat je nog de PS100 series gebruikt, daar zijn upgrade kits voor en ze gaan per 7 hdd's.
Ik weet niet hoe je EQL nu is ingericht maar als ik van raid50 uit ga zit je nu op 2.5TB netto.
Als je alle 14 hdd's vervangt voor 7x 1TB zit je al op 5TB netto en kan je er altijd nog 7 hdd's bijzetten.

Hier (wel wat verouderde) prijzen:

95-0030 (7) 250 GB drives
(7) 250 GB drives
$3,185

95-0052 (7) 74 GB 10k RPM drives Type 1 and 2
(7) 74 GB 10k RPM drives Type 1 and 2
$2,830

95-0244 (7) 500 GB drives
(7) 500 GB drives
$5,210

95-0352 (7) 750 GB Drives Type 1 and 2
(7) 750 GB Drives Type 1 and 2
$6,950

En als je het aandurft kan je er ook gewoon SATA2 hdd's naar keuze instoppen. Let er wel op dat je dan modellen hebt waar je (softwarematig) de write cache kan uitzetten.
Ikzelf heb 2 PS100's draaien voor een ESX test omgeving, 1 met 14X2TB WD's raid50 (die green 5400rpm's), je moet er geen hele hoge IO's van verwachten maar voor test is her prima. De andere heb ik voorzien van 14 150GB raptors in RAID10 voor databases. Op mijn werk heb ik er wel gewoon officiele hdd's in zitten.

[ Voor 49% gewijzigd door DukeBox op 18-04-2009 23:57 ]

[Verwijderd]

Het is misschien verstandig om te controleren of de ondersteuning en technisch het toe laat om applicaties in virtual servers zoals VMware te gaan draaien. Er zijn al partijen die met oa Navision op beide vlakken problemen hebben gehad en resultaat was dat VMware er tussenuit moest.

[Question Mark]

Ethirty schreef op zaterdag 18 april 2009 @ 21:56:
In ieder geval je primaire DC absoluut niet virtualiseren, hoewel de meningen daarover nog verdeeld zijn.

Want?

't is gewoon een supported oplossing door MS. Ben benieuwd waarom je zo stellig aangeeft om dit niet te doen. Nog even afgezien van het feit dat ik bij god niet weet wat een primaire DC is. Ik ken wel vijf FSMO rollen, die ik met de juiste guidelines in gedachten over meerdere DC's mag verdelen.

[ Voor 31% gewijzigd door Question Mark op 19-04-2009 11:47 ]

[DukeBox]

Question Mark schreef op zondag 19 april 2009 @ 11:45:
[...]
Want?

't is gewoon een supported oplossing door MS. Ben benieuwd waarom je zo stellig aangeeft om dit niet te doen.

Het hangt een beetje van je omgeving af.. maar als als je DC's virtueel zijn (en dat je enige DNS servers zijn) en je hele omgeving ligt plat is het lastig deze online te krijgen zonder DNS. Zeker als je deze ook nog voor accounting gebruikt voor je virtual center.
ESX en met name HA/DRS hangt heel erg samen met DNS (ook reverse !).

[Ethirty]

Question Mark schreef op zondag 19 april 2009 @ 11:45:
[...]
Want?

't is gewoon een supported oplossing door MS. Ben benieuwd waarom je zo stellig aangeeft om dit niet te doen. Nog even afgezien van het feit dat ik bij god niet weet wat een primaire DC is. Ik ken wel vijf FSMO rollen, die ik met de juiste guidelines in gedachten over meerdere DC's mag verdelen.

Omdat ik dat op meerdere plekken las en er verschillende keren werd aangegeven dat dit problemen geeft. Als het probleemloos kan trek ik mijn opmerking in, maar ik vraag me af waarom er dan zoveel problemen zijn. Ik geef notabene nog een link waar je er meer dan genoeg over vind, voors én tegens.

Primaire DC is inderdaad een beetje ongelukkig gekozen kreet uit de NT4 tijd, toen had je de begrippen PDC en de BDC. In een kleine omgeving is vaak 1 DC met alle FSMO rollen (de 'primaire') en als het goed is een 2e als backup, funtioneel dus een beetje vergelijkbaar met 'toen'.

[ Voor 4% gewijzigd door Ethirty op 19-04-2009 12:45 ]

[DukeBox]

^ ik vind het ook veel handiger in grote omgevingen alles centraal te hebben (soms kan het ook niet anders wegens koppelingen).. als die met alle FSMO rollen uitvalt zet je ze toch zo over.

[ralpje]

Probleem met DC's was nog wel eens dat de guests in virtuele situatie tijdsynchronisatie deden aan de hand van de host machine, in plaats van binnen het AD netwerk. In ESX is dat één vinkje uitzetten, en dan werkt het probleemloos.

[Question Mark]

Ethirty schreef op zondag 19 april 2009 @ 12:43:
[...]
Omdat ik dat op meerdere plekken las en er verschillende keren werd aangegeven dat dit problemen geeft. Als het probleemloos kan trek ik mijn opmerking in, maar ik vraag me af waarom er dan zoveel problemen zijn. Ik geef notabene nog een link waar je er meer dan genoeg over vind, voors én tegens.

Ik weet dat er voors en tegens zijn om DC's te virtualiseren. Grootste issue was altijd dat dit niet supported was, maar tegenwoordig wordt het gewoon supported. Voor de overige nadelen geld dat per situatie bekeken moet worden of het handig is om de DC's te virtualiseren. Als je dat had geroepen was ik het roerend met je eens geweest.

Nu roep je echter direct al dat je een DC absoluut niet moet virtualiseren, wat ik een vreemde opmerking vind.

Laat ik het anders stellen: waarom vind jij dat de TS het in zijn omgeving absoluut niet moet doen?

[DukeBox]

Het is een beetje hetzelfde verhaal als je virtual center virtualiseren, je moet gewoon goed opletten dat je geen kip/ei verhaal creeërd.

[ Voor 31% gewijzigd door DukeBox op 20-04-2009 09:56 ]

[Ethirty]

Question Mark schreef op maandag 20 april 2009 @ 07:51:
Nu roep je echter direct al dat je een DC absoluut niet moet virtualiseren, wat ik een vreemde opmerking vind.

Laat ik het anders stellen: waarom vind jij dat de TS het in zijn omgeving absoluut niet moet doen?

Bij nader inzicht is het 'absoluut niet' misschien een beetje voorbarig geweest. Of je je DC virtualiseren wil is sterk afhankelijk van de grootte van de omgeving, de aanwezige kennis over DC's en virtualisatie en het besef dat er ook nadelen aan deze oplossing zitten. Als je hiervan op de hoogte ben, dan kan je voor jezelf wel bepalen of je het verstandig vind of niet.

Gezien de omvang van het serverpark verwacht ik niet dat daar héél veel kennis van de diverse onderdelen is (misschien onterecht). Anders was dit topic waarschijnlijjk niet gestart.

[Acmosa]

Ik heb een tip (voor de mensen die dit nog niet weten) die het kip ei verhaal kan afvangen.

Scenario: Alle vm's staan uit, je vc/vmware lic server is onbereikbaar en je hebt je esx hosts ook uit gezet.
Probleem: je krijgt je vm's waarschijnlijk niet aan omdat ze geen dns kunnen vinden en dus geen lic server.
Opossing: creer een extra externe dsn server.

Een andere oplossing om je licenties 2 keer te creeren bij vmware. eerst een licentie voor je lic server met alle licenties bij elkaar, daarna verwijder je al je licenties binnen vmware lic manager (website) en creer je per vm esx host een host licensence. De vm esx host configureer je met de esx host licensce file en de virtual server configureer je met de lic server file. Nu heeft iedere vm esx host altijd een licentie incl alle functionaliteit en is het dns kip ei probleem opgelost. De esx host heeft een licentie om de dns vm te starten waarna HA en DRS vanzelf weer gaan werken.

[Moszle]

Hoi Allemaal,

bedankt voor de vele bruikbare reacties.

Ik heb de EQL nog eens nagelopen en er is 1.17Tb vrijgemaakt voor data. Hier word 700Gb gebruikt heb nu nog dik 400Gb over. Nu heb ik ook nog eens naar de data zelf gekeken en deze kan ik met 25% wel terugbrengen naar 525 Gb. ik zou dan dus nu 600Gb overhouden. De schijfgroei toont aan dat er op dit moment nog geen 100Gb per jaar bij komt.

Ik zat nu te denken om de data-schijf op te delen. 400Gb te gebruiken voor virtualisatie (zoals Ethirty al aangaf ruimte voor interne geheugen, suspend files en evt snapshots).

Mocht ik over een geruime tijd ruimte te kort hebben, dan kan ik altijd nog overgaan op onderstaande:

DukeBox schreef op zaterdag 18 april 2009 @ 23:45:
Aangezien je EQL perfect werkt met ESX(i) zou ik toch daar mee verder gaan.
Je weet dat je de 250GB's kan upgraden in stappen van 250GB naar 1.5TB ?
Als ik er vanuit ga dat je nog de PS100 series gebruikt, daar zijn upgrade kits voor en ze gaan per 7 hdd's.
Ik weet niet hoe je EQL nu is ingericht maar als ik van raid50 uit ga zit je nu op 2.5TB netto.
Als je alle 14 hdd's vervangt voor 7x 1TB zit je al op 5TB netto en kan je er altijd nog 7 hdd's bijzetten.

Hier (wel wat verouderde) prijzen:

95-0030 (7) 250 GB drives
(7) 250 GB drives
$3,185

95-0052 (7) 74 GB 10k RPM drives Type 1 and 2
(7) 74 GB 10k RPM drives Type 1 and 2
$2,830

95-0244 (7) 500 GB drives
(7) 500 GB drives
$5,210

95-0352 (7) 750 GB Drives Type 1 and 2
(7) 750 GB Drives Type 1 and 2
$6,950

En als je het aandurft kan je er ook gewoon SATA2 hdd's naar keuze instoppen. Let er wel op dat je dan modellen hebt waar je (softwarematig) de write cache kan uitzetten.
Ikzelf heb 2 PS100's draaien voor een ESX test omgeving, 1 met 14X2TB WD's raid50 (die green 5400rpm's), je moet er geen hele hoge IO's van verwachten maar voor test is her prima. De andere heb ik voorzien van 14 150GB raptors in RAID10 voor databases. Op mijn werk heb ik er wel gewoon officiele hdd's in zitten.

Ook kan er dan nog gekeken worden of er een 2e EQL noodzakelijk is. Maar mijn voorkeur budget technisch gezien zou dan uitgaan naar wat Dukbox omschreef.

Verder ben ik er wel redelijk uit qua server, dit zullen 2x HP ProLiant DL385 G5p gaan worden met Virtual Infrastructure V3.x Enterprise & VirtualCenter Management Server V2.0. Verder zullen we de infrastructure Bare metal gaan draaien.

Wat betreft het verhaal over het niet Virtualiseren van de DC had ik eigenlijk nog niet echt aangedacht. Ik ben nog niet zo heel lang bezig met VM's en heb er tot nu toe nog geen problemen mee gehad maar het is wel iets om bij stil te staan natuurlijk.

[DukeBox]

Moszle schreef op dinsdag 21 april 2009 @ 10:12:
Ik heb de EQL nog eens nagelopen en er is 1.17Tb vrijgemaakt voor data. Hier word 700Gb gebruikt heb nu nog dik 400Gb over. Nu heb ik ook nog eens naar de data zelf gekeken en deze kan ik met 25% wel terugbrengen naar 525 Gb. ik zou dan dus nu 600Gb overhouden. De schijfgroei toont aan dat er op dit moment nog geen 100Gb per jaar bij komt.

Maak je al gebruik van thin provisioning ? Evt. kan dat een (tussen) oplossing zijn.

[P]inky schreef op maandag 20 april 2009 @ 13:40:
Scenario: Alle vm's staan uit, je vc/vmware lic server is onbereikbaar en je hebt je esx hosts ook uit gezet.
Probleem: je krijgt je vm's waarschijnlijk niet aan omdat ze geen dns kunnen vinden en dus geen lic server.
Opossing: creer een extra externe dsn server.

En wat als je firewall een vm appliance is.. of (niet ongebruikelijk) geheel is afgesloten van internet ?

Een andere oplossing om je licenties 2 keer te creeren bij vmware. eerst een licentie voor je lic server met alle licenties bij elkaar, daarna verwijder je al je licenties binnen vmware lic manager (website) en creer je per vm esx host een host licensence.

En wat nu als je bijv. je VC database moet restoren ?
Je ESX omgeving kan je niet opstarten en je restore kan je niet doen omdat de host license geen vcenter backup mogelijkheid heeft.

[ Voor 22% gewijzigd door DukeBox op 21-04-2009 21:02 ]

[Dafjedavid]

Dat gaat nu juist wel.
Je ESX omgeving is wel beschikbaar, alleen je Vcenter is niet beschikbaar.
Je kan met de VI-client inloggen op de host zelf.
Dan lees je de host-license file in, waarna je je VM's weer mag starten.

Kun je rustig een Vcenter-database restore doen, imo, aangezien je dan wel je VCB machine kan starten...

[ Voor 8% gewijzigd door Dafjedavid op 22-04-2009 10:48 ]

[Asteroid9]

Inderdaad, Virtualcenter is een hulpmiddel, en heel handig, maar niet strikt noodzakelijk!
Zaken als HA en DRS worden vanuit Virtualcenter aangestuurd, maar bij calamiteiten kun je prima zonder.

DC's virtualiseren gaat inderdaad prima, die oude discussies kwamen vooral voort uit de tijdssynchronisatie met de host.
Het beschikbaar zijn van DNS in geval van een calamiteit is een goed punt, maar dat geld voor meer services.
Goed over nadenken en documenteren in elk geval.

Alles virtueel en op 1 SAN levert een redelijk grote SPOF op, dat zeker...
Het kan ook een overweging zijn om 1 DC en 1 DNS server op lokale storage te zetten, dan ondervang je al heel wat risico's!

[Verwijderd]

Ik lees een hoop onzin over het niet kunnen starten van VM's zonder DNS en DC's die niet gevirtualiseerd mogen worden.

Ik kan onze totale omgeving (alle DC's en de VC-server draaien virtueel) platleggen en daarna gewoon netjes weer opstarten. En Dan Doet Hij Het Weer.

Laatst hebben we 1 volle dag zonder stroom gezeten. Gewoon netjes alles uitgezet (De UPS-en houden het een aardig eindje vol) en gewacht tot er weer prik was. De boel opstarten en weer rap naar huis. Niks aan het handje.

[ Voor 4% gewijzigd door Verwijderd op 22-04-2009 19:37 ]

[DukeBox]

De zin/onzin heeft vaak meer met persoonlijke ervaring te maken. Als je bijv. je hosts in lockdown mode hebt heb je toch echt een vcenter nodig om vm's te starten. Hoe dan ook, volg gewoon de best practice.. als je dan eens 'shit' hebt is het veel makkelijker support te krijgen.

[Ethirty]

Met lockdown kan je met de VI client toch ook gewoon lokaal op de host inloggen, mits je een lokale user hebt naast root?

[Dafjedavid]

Ethirty schreef op woensdag 22 april 2009 @ 23:06:
Met lockdown kan je met de VI client toch ook gewoon lokaal op de host inloggen, mits je een lokale user hebt naast root?

Ook met een root account kun je inloggen op een vmware-server met de VI-client. Althans, ikke wel....
Maar wij hebben dan ook niet zon spannende omgeving....

[DukeBox]

Ethirty schreef op woensdag 22 april 2009 @ 23:06:
Met lockdown kan je met de VI client toch ook gewoon lokaal op de host inloggen, mits je een lokale user hebt naast root?

Met over 140 hosts is het ondoenlijk alles lokaal bij te gaan houden. Laat staan de kans dat er een typefout is geweest met invoeren van lokale gegevens en daar op het verkeerde moment achter komt.

[basprofessional]

[b][message=31840319,noline]

Alles virtueel en op 1 SAN levert een redelijk grote SPOF op, dat zeker...
Het kan ook een overweging zijn om 1 DC en 1 DNS server op lokale storage te zetten, dan ondervang je al heel wat risico's!

Ik vind dit zelf een behoorlijk kromme opmerkingen.
Een groot voordeel van een SAN is de hogere data veiligheid en redundantie die je hebt
en dan kom jij met de oplossing voor lokale storage? Ik ben van mening dat een SAN niet
als SPOF gezien mag worden omdat alles redundant is uitgevoerd van harddisk tot controller
en van controller tot voeding. Die gedachte moet er bij veel mensen uit!
Met lokale storage maak je imo een veel grote SPOF vanwege
bijvoorbeeld een raidcontroler die niet dubbel is uitgevoerd. Het lijkt me wel slim om een aparte server
in te richten voor het draaien van een fail over AD+NS2.

[Ethirty]

DukeBox schreef op woensdag 22 april 2009 @ 23:18:
Met over 140 hosts is het ondoenlijk alles lokaal bij te gaan houden. Laat staan de kans dat er een typefout is geweest met invoeren van lokale gegevens en daar op het verkeerde moment achter komt.

Dat snap ik, maar het ging over of je in geval van een ramp, want daar spreek je wel van dan, je vCenter en DC weer in de lucht kan krijgen.

Ik denk dat als je 140 hosts hebt er wel budget was voor een losse DC en vCenter server

[Question Mark]

basproffesional schreef op woensdag 22 april 2009 @ 23:26:
[...]
Ik ben van mening dat een SAN niet als SPOF gezien mag worden omdat alles redundant is uitgevoerd van harddisk tot controller en van controller tot voeding. Die gedachte moet er bij veel mensen uit!

Je disken zitten nog steeds op één backplane aangesloten, die kan ook failen. Ik ben het volledig met je eens dat een SAN robuuster en meer redudant uitgevoerd is dan local storage, maar het blijft nog steeds één apparaat. Stel dat er een vliegtuig naar beneden dondert bovenop je rekencentra, dan blijft er weinig over van je redudante SAN.

Bij mij @Work is het beleid dat alles wat HA moet worden, verspreid wordt over meerdere datacenters, dus ook meerdere SAN's die realtime mirroren.

Het is maar net waar je de definitie van SPOF en redudancy neerlegd, en dat zal situatieafhankelijk zijn. In de meeste gevallen zal inderdaad een redudant SAN niet als SPOF gezien worden, bij mij op het werk is de eis dat een compleet rekencentrum uit moet kunnen vallen zonder downtime. In dat laatste geval is een SAN dan wel een SPOF.

[DukeBox]

Question Mark schreef op donderdag 23 april 2009 @ 08:06:
Je disken zitten nog steeds op één backplane aangesloten, die kan ook failen. Ik ben het volledig met je eens dat een SAN robuuster en meer redudant uitgevoerd is dan local storage, maar het blijft nog steeds één apparaat.

Daarom worden raid groepen over meerdere backplanes gemaakt.. en vaak zelfs over meerder bases bij de grotere omgevingen. Daarnaast heeft een SAN als voordeel dat je firmware updates en hardware swaps vaak online kan doen (en dan heb ik het niet over alleen de hdd's, maar ook controllers, fans, bbu's enz..)
Het enige waar ik je gelijk in kan geven is als je het op software gooit, een firmware bug in je SAN kan heel wat aanrichten zelfs totaan je offsite replica's enz.. maar gelukkig heb je daar weer een mooie backup omgeving voor (en dus gaan disk2disk op het san van hetzelfde merk).

[basprofessional]

Question Mark schreef op donderdag 23 april 2009 @ 08:06:
[...]
Je disken zitten nog steeds op één backplane aangesloten, die kan ook failen. Ik ben het volledig met je eens dat een SAN robuuster en meer redudant uitgevoerd is dan local storage, maar het blijft nog steeds één apparaat. Stel dat er een vliegtuig naar beneden dondert bovenop je rekencentra, dan blijft er weinig over van je redudante SAN.

Bij mij @Work is het beleid dat alles wat HA moet worden, verspreid wordt over meerdere datacenters, dus ook meerdere SAN's die realtime mirroren.

Het is maar net waar je de definitie van SPOF en redudancy neerlegd, en dat zal situatieafhankelijk zijn. In de meeste gevallen zal inderdaad een redudant SAN niet als SPOF gezien worden, bij mij op het werk is de eis dat een compleet rekencentrum uit moet kunnen vallen zonder downtime. In dat laatste geval is een SAN dan wel een SPOF.

En wat als er een vliegtuig op je lokale storage neerstort?
En inderdaad een ander groot voordeel van een SAN is dat het erg gemakkelijk is
om een offsite oplossing te creeëren, wat hier helaas niet binnen het budget past.

[Question Mark]

Jullie missen het punt even wat ik probeer te maken. Ik geef jullie ook gelijk op jullie argumenten, maar da's niet wat ik probeer aan te tonen.

Ondanks alle oplossingen die verzonnen worden om alle SPOF's binnen het apparaat te voorkomen, blijft het één apparaat. Bij mij op het werk is middels het beleid bepaald dat één enkel apparaat (hoe redudant dit ook uitgevoerd is) een SPOF is.

Dat is dus een andere insteek dan welke basprofessional hanteerd. Hij geeft aan dat aangezien alles in een SAN redudant uitgevoerd is geen SPOF genoemd mag worden. Ik ben het daar niet helemaal mee eens, en geef enkel aan dit dit situatieafhankelijk is.

[Asteroid9]

basproffesional schreef op woensdag 22 april 2009 @ 23:26:
[...]


Ik vind dit zelf een behoorlijk kromme opmerkingen.
Een groot voordeel van een SAN is de hogere data veiligheid en redundantie die je hebt
en dan kom jij met de oplossing voor lokale storage? Ik ben van mening dat een SAN niet
als SPOF gezien mag worden omdat alles redundant is uitgevoerd van harddisk tot controller
en van controller tot voeding. Die gedachte moet er bij veel mensen uit!
Met lokale storage maak je imo een veel grote SPOF vanwege
bijvoorbeeld een raidcontroler die niet dubbel is uitgevoerd. Het lijkt me wel slim om een aparte server
in te richten voor het draaien van een fail over AD+NS2.

Iets beter lezen voor je over kromme opmerkingen begint zou leuk zijn.
Ik heb het over 1 DC en 1 DNS op lokale storage, services die zelf al redundantie bieden.
Lokale storage plat? Geen probleem, overige DC's en DNS servers zijn gewoon bereikbaar.

En een SAN blijft gewoon 1 groot SPOF!
Zo, knuppel in het hoenderhok!

Tuurlijk gaan ze nooit stuk... ik heb in een paar maanden al 5 persoonlijke ervaringen gehoord die het tegendeel beweren.

Volledig stuk gaan ze niet snel, maar een corrupt LUN?
Of een HP EVA waarbij door een trilling 2 disks in dezelfde RSS set sneuvelen? Dag diskgroup...
Firmware probleem op een grote Netapp omgeving, alles weg!

Geen worst case scenario's, maar directe ervaringen van mijn eigen vrienden en kennissen.
Zoek hier maar eens op Tweakers, dan vindt je er nog veel meer.

Geen enkele SAN leverancier garandeert je beschikbaarheid, en als je even doorvraagt zullen ze altijd een dubbele SAN setup aanraden.
Nou wordt bij replicatie een corrupt filesystem direct naar het andere SAN gerepliceerd, helaas.

Begrijp me niet verkeerd, ik ben geen tegenstander van een SAN!
Ik ga net weer een selectietraject in voor een nieuwe storage omgeving.

Het is alleen een SPOF, simple as that!
De kans dat hij platgaat is relatief laag, maar de impact is gigantisch.
Dat moet elk bedrijf zich realiseren, en adequate maatregelen nemen.
Als je backup-restore echt goed op orde is kun je besluiten het risico te accepteren, maar roep niet dat het geen SPOF is...

[basprofessional]

Asteroid9 schreef op donderdag 23 april 2009 @ 12:05:
[...]


verhaal..

Wat ik krom vind is het preferen van een server met lokale storage qua redundantie boven een SAN omgeving!

[Asteroid9]

basproffesional schreef op donderdag 23 april 2009 @ 13:08:
[...]

Wat ik krom vind is het preferen van een server met lokale storage qua redundantie boven een SAN omgeving!

Geen onderbouwing, geen argumenten, zo komen we niet bepaald verder...
Als je nou wat beter leest zie je dat ik de lokale storage alleen als noodvoorziening schets indien het SAN toch problemen kent.

Nofi, maar aan een dergelijke discussie heeft niemand wat!

[Yalopa]

Ik sluit me toch aan bij het verhaal om bepaalde servers niet te virtualiseren, virtualisatie is een middel, geen doel..

mijn favorieten om niet te virtualiseren:

Management server: (VC server / SCVMM server/SAN management)

Primaire DC: Vergeet het dat je een hyper-v cluster nog online krijgt als er geen DC beschikbaar is. Het hebben van een DNS server is ook altijd handig, al is het maar om snel je servers terug te vinden.

Monitoring server: als je issues hebt op je omgeving en je monitor meld het niet omdat hij net ook op het stukje staat dat down gegaan is dan heb je het niet in de gaten

MS Clusters: MS clusters zijn niet gesupporteerd indien ze virtueel draaien.

[Verwijderd]

Yalopa schreef op maandag 27 april 2009 @ 21:00:

Primaire DC: Vergeet het dat je een hyper-v cluster nog online krijgt als er geen DC beschikbaar is. Het hebben van een DNS server is ook altijd handig, al is het maar om snel je servers terug te vinden.

Waarom zou je je DC niet virtualiseren op een VMware cluster? Er is meer dan alleen Hyper-V.

Monitoring server: als je issues hebt op je omgeving en je monitor meld het niet omdat hij net ook op het stukje staat dat down gegaan is dan heb je het niet in de gaten

Slecht argument. Je hoort sowieso een tweede monitor te hebben die de eerste monitor monitort en die wordt gemonitord door de eerste monitor. Dit geldt net zo goed op een fysieke monitoring server.

Ondanks dat ik het helemaal met je eens ben (virtualisatie is een middel, geen doel) ben ik het dus niet geheel eens met je beargumentering

[MorDrakka]

(virtualisatie is een middel, geen doel), 3 jaar geleden misschien. Nu: Physical is legacy.

[Verwijderd]

MorDrakka schreef op dinsdag 05 mei 2009 @ 09:03:
(virtualisatie is een middel, geen doel), 3 jaar geleden misschien. Nu: Physical is legacy.

Ok, en nu het hypothetische geval waarin ik een colocated fysieke server ergens wil ophangen omdat -als dat nodig is- ik het ding wil kunnen oppakken en ergens anders wil ophangen. Wat heb je daar over te zeggen?

[ppl]

basproffesional schreef op donderdag 23 april 2009 @ 09:34:
[...]

En wat als er een vliegtuig op je lokale storage neerstort?
En inderdaad een ander groot voordeel van een SAN is dat het erg gemakkelijk is
om een offsite oplossing te creeëren, wat hier helaas niet binnen het budget past.

Het voordeel van de eis dat een compleet datacentre uit mag vallen is dat in geval van een crash van een vliegtuig je dit moet herhalen voor alle dc's waar je spul staat. Dan moet je denken aan een aanslag groter dan dat van 11 september 2001. Die kans is wel erg klein en tegen zulke extreme situaties valt sowieso al erg weinig te doen. Je zult daarin een balans moeten vinden tussen kosten en baten. Als je lokale storage en je SAN in 1 gebouw hebt en er valt wat bovenop dan ben je inderdaad alsnog nat (overigens was hier de lokale storage een oplossing om problemen met het SAN/virtuele omgeving op te vangen). Ook hier geldt echter weer dat je een goede risicoanalyse moet maken: hoe groot is de kans, wat kost het als het gebeurt en is het te verantwoorden (qua kosten e.d.) om daar maatregelen voor te nemen. Je moet je dus zeker niet de illusie nemen dat je je overal tegen kunt beveiligen en dat het nemen van die maatregelen altijd mogelijk is. Je zit nog altijd met een zeker budget die het e.e.a. dicteert.

Verwijderd schreef op maandag 27 april 2009 @ 21:05:
Slecht argument. Je hoort sowieso een tweede monitor te hebben die de eerste monitor monitort en die wordt gemonitord door de eerste monitor. Dit geldt net zo goed op een fysieke monitoring server.

Ondanks dat ik het helemaal met je eens ben (virtualisatie is een middel, geen doel) ben ik het dus niet geheel eens met je beargumentering

Slecht argument indeed omdat ook hier het budget een rol speelt. Het is lang niet altijd mogelijk om de setup te maken die je nu voorstelt. Er zit in de praktijk een kloof tussen gewenst en mogelijk

Verwijderd schreef op dinsdag 05 mei 2009 @ 12:22:
[...]

Ok, en nu het hypothetische geval waarin ik een colocated fysieke server ergens wil ophangen omdat -als dat nodig is- ik het ding wil kunnen oppakken en ergens anders wil ophangen. Wat heb je daar over te zeggen?

Door het te virtualiseren haal je die hardware laag eruit en kun je dus een omgeving die over meerdere locaties verspreid is creëren. Dan hoef je je geen zorgen te maken bij het verwisselen van hardware en het heen en weer schuiven van de (virtuele) servers.

Moraal van het verhaal: allemaal erg leuk dat hele vergaande gediscussieer over redundatie, risico's, etc. maar het begint nu wel erg ver door te draven. Een stukje realisme is ook wel op z'n plek. Als je budget het niet toelaat om je san over 5 locaties in Nederland te verspreiden dan heeft het ook weinig zin om daar nog verder naar te kijken.