VMware oplossing of Hyper-v

[xleeuwx]

Na enige tijd te gewerkt te hebben met Hyper-v en met VMware in verschillende omgevingen kan ik het met beide producten vinden. Voor het bedrijf waar ik werk zijn we opzoek naar een nieuwe oplossing voor onze servers. We hebben keuze uit 3 opties,

1. Cloud omgeving afnemen bij een datacenter.
2. Dedicated servers afnemen bij een datacenter.
3. Eigen servers kopen en in een datacenter hangen.

Op dit moment maken we gebruik van een Cloud omgeving bij bedrijf x en daar lopen we tegen het ene na het andere probleem aan .

Verder zouden we graag op 2 locaties willen zitten inverband dat de servers altijd maar dan ook altijd bereikbaar moeten zijn.

Op moment hebben wij 2 webservers draaien en 2 mail servers en nog een paar kleine andere maar die zijn niet zo heel erg belangrijk.

Ik heb zelf naar oplossingen gekeken zoals: VMware Stretched cluser and vCenter Recovery Manage
En neem aan dat Hyper-v ook iets deregelijks bied. Maar wat mij nog steeds niet duidelijk word is ik heb 2 webservers in locatie a en b (misschien c). Hoe kunnen ze locatie B benaderen als A helemaal uitgevallen is.

Misschien zit ik wel helemaal verkeerd te denken kwa oplossing en hebben jullie en veel beter en genialer plan .

ps. webservers draaien op Windows / IIS (standalone inc MySQL)

[Question Mark]

xleeuwx schreef op donderdag 09 oktober 2014 @ 10:34:
Verder zouden we graag op 2 locaties willen zitten inverband dat de servers altijd maar dan ook altijd bereikbaar moeten zijn.

Altijd maar dan ook altijd kun je vergeten... De kosten om die uptime te halen zijn astronomisch.

Hoe kunnen ze locatie B benaderen als A helemaal uitgevallen is.

Dat ligt eigenlijk aan de mogelijkheden en onmogelijkheden van je beide datacenters (en je applicatie). Ben je bijvoorbeeld in staat om één ip-subnet te stretchen over je datacenters?

Anyways, de meest gebruikte oplossing voor dit probleem is "Global Load balancing".

What is Global Server Load Balancing and how it works ?

Maar nogmaals, dit is een veel gebruikte oplossing. Of deze voor oplossing jouw doeleinde het meest geschikt is kan op dit moment (met de info die je nu aanlevert) niet bepaald worden.

[xleeuwx]

Question Mark schreef op donderdag 09 oktober 2014 @ 10:52:
[...]
Altijd maar dan ook altijd kun je vergeten... De kosten om die uptime te halen zijn astronomisch.

Klopt maar dicht bij proberen te komen is wel een vereiste.

[...]

Dat ligt eigenlijk aan de mogelijkheden en onmogelijkheden van je beide datacenters (en je applicatie). Ben je bijvoorbeeld in staat om één ip-subnet te stretchen over je datacenters?

Momenteel hebben wij een eigen subnet (32 ipjes), mede ook vanwege de SSL certificaten.

Anyways, de meest gebruikte oplossing voor dit probleem is "Global Load balancing".

What is Global Server Load Balancing and how it works ?

Dit zou inderdaad het probleem wegnemen voor de webservers, meer info gevonden: http://www.tenereillo.com/GSLBPageOfShame.htm

Maar nogmaals, dit is een veel gebruikte oplossing. Of deze voor oplossing jouw doeleinde het meest geschikt is kan op dit moment (met de info die je nu aanlevert) niet bepaald worden.

Welke informatie zou je nodig hebben ?
om idee te geven wij gebruiken per dan bij mysql: 214.3 GiB per server

onze huidige omgeving cloud omgeving heeft de volgende specs
CPU totaal: 64ghz,
RAM totaal: 64GB,
HDD totaal: 1TB (Veel te weinig )

[Question Mark]

xleeuwx schreef op donderdag 09 oktober 2014 @ 11:08:
[...]
Welke informatie zou je nodig hebben ?

Ik niks, jij moet en wilt iets... Jij hebt informatie nodig om je keuzes te kunnen maken

Wat ik altijd doe bij het ontwerpen en bouwen van een omgeving met een bepaalde beschikbaarheid is vaststellen op welk niveau de beschikbaarheid geregeld moet of kan worden:

• Op netwerklaag (bv. GSLB)
• Op infralaag, bv VMWare HA of MS Failoverclustering
• Op applicatieniveau
• Etc.

Qua oplossing kan er immers verschil zitten in webservers die statische content serveren, of webservers die dynamische data uit een database schrijven/lezen.

De webservers (of beter gezegd: de webservices) in dit voorbeeld kunnen wellicht via Loadbalancing (netwerklaag) HA gemaakt worden, terwijl de SQL database middels database-mirroring (applicatielaag) HA gemaakt wordt.

Inventariseer dus even welke services je een hoge beschikbaarheid wilt geven, en bepaal per service hoe dit het beste gerealiseerd kan worden.

Houdt daarbij ook rekening met technische randvoorwaarden. Voor een MS failovercluster mag bijvoorbeeld de maximum roundtriptime 500 ms bedragen tussen je datacenters. Is de latency tussen je datacenters hoger, dan valt deze optie al af.

[ Voor 8% gewijzigd door Question Mark op 09-10-2014 11:32 ]

[xleeuwx]

Question Mark schreef op donderdag 09 oktober 2014 @ 11:26:
[...]

Ik niks, jij moet en wilt iets... Jij hebt informatie nodig om je keuzes te kunnen maken

True

Wat ik altijd doe bij het ontwerpen en bouwen van een omgeving met een bepaalde beschikbaarheid is vaststellen op welk niveau de beschikbaarheid geregeld moet of kan worden:

• Op netwerklaag (bv. GSLB)
• Op infralaag, bv VMWare HA of MS Failoverclustering
• Op applicatieniveau
• Etc.

Qua oplossing kan er immers verschil zitten in webservers die statische content serveren, of webservers die dynamische data uit een database schrijven/lezen.

De webservers (of beter gezegd: de webservices) in dit voorbeeld kunnen wellicht via Loadbalancing (netwerklaag) HA gemaakt worden, terwijl de SQL database middels database-mirroring (applicatielaag) HA gemaakt wordt.

Inventariseer dus even welke services je een hoge beschikbaarheid wilt geven, en bepaal per service hoe dit het beste gerealiseerd kan worden.

Hoewel ik wel de basis kennis voor beheren van servers gaat het enterprice gedeelte mij gewoon nog even boven mij pet (iedereen zijn vak natuurlijk ).

Het belangrijkste is de webservice die 24/7 doorgaat en ook gewoon bezet is dan. Natuurlijk met de pieken tussen 08:00 en 18:00. Daarnaast draaien we de MySQL nog op de webserver. We hebben dus nog even de vraag of we dit willen splitsen in 2x webserver en 2x mysql server.

Als ik het goed begrijp zou je dus met GSLB kunnen verzorgen dat je op 2 locaties kan zitten met je server en dan gewoon webserver dubbel uitvoeren op 2 locaties en de een master / slave opzetten tussen de 2 locaties met MySQL.

Houdt daarbij ook rekening met technische randvoorwaarden. Voor een MS failovercluster mag bijvoorbeeld de maximum roundtriptime 500 ms bedragen tussen je datacenters. Is de latency tussen je datacenters hoger, dan valt deze optie al af.

Wij zijn eigelijk op zoek naar iets nieuws maakt niet uit wat voor datacenter of welke oplossing. We willen namelijk hoe dan ook van onze huidige infrastructuur af. Dus dit is natuurlijk gewoon uit te kiezen en dus nog steeds een optie.

[mbaltus]

Als de uptime zo kritisch is, dan vraag ik me af of je het zelf moet willen inrichten. In dat geval zul je er vrij dure infrastructuur onder moeten steken om de beschikbaarheid te halen. Je zou eens kunnen kijken naar AWS of Azure om zioiets op te hosten. Als je liever een private cloud gebruikt die ook in NL zit dan zijn daar voldoende alternatieven voor

[Question Mark]

xleeuwx schreef op donderdag 09 oktober 2014 @ 11:48:
[...]
Als ik het goed begrijp zou je dus met GSLB kunnen verzorgen dat je op 2 locaties kan zitten met je server en dan gewoon webserver dubbel uitvoeren op 2 locaties en de een master / slave opzetten tussen de 2 locaties met MySQL.

Dat zou één van de opties zijn ja. Je zou in plaats van database-mirroring ook database clustering kunnen gebruiken, of als je aan de voorwaarden voldoet zou je de SQL server ook met VSphere FT een hoge(re) beschikbaarheid kunnen geven.

Het ligt er ook een beetje aan hoe je de datacenters in wilt gaan zetten. Wil je deze active/active (beide datacenters draaien "produktie"), of active/passive(één datcenter dedicated produktie, een datacenter dedicated uitwijklokatie).

Ook hangt dit ondermeer af van de beschikbare bandbreedte, latency tussen de datacenters.

Zet per dienst die aangeboden moet worden tussen even goed op een rijtje op welke manieren de gewenste beschikbaarheid te realiseren is. Streep dan de opties af, die niet haalbaar zijn vanwege technische voorwaarden, budgettechnische redenen of iets dergelijks. Dan hou je vanzelf een paar opties over waar je keuzes uit zult moeten maken.

Vergeet ook je disaster recovery niet goed in te regelen overigens.

[xleeuwx]

Question Mark schreef op vrijdag 10 oktober 2014 @ 10:47:
[...]

Dat zou één van de opties zijn ja. Je zou in plaats van database-mirroring ook database clustering kunnen gebruiken, of als je aan de voorwaarden voldoet zou je de SQL server ook met VSphere FT een hoge(re) beschikbaarheid kunnen geven.

Het ligt er ook een beetje aan hoe je de datacenters in wilt gaan zetten. Wil je deze active/active (beide datacenters draaien "produktie"), of active/passive(één datcenter dedicated produktie, een datacenter dedicated uitwijklokatie).

Ook hangt dit ondermeer af van de beschikbare bandbreedte, latency tussen de datacenters.

Zet per dienst die aangeboden moet worden tussen even goed op een rijtje op welke manieren de gewenste beschikbaarheid te realiseren is. Streep dan de opties af, die niet haalbaar zijn vanwege technische voorwaarden, budgettechnische redenen of iets dergelijks. Dan hou je vanzelf een paar opties over waar je keuzes uit zult moeten maken.

Vergeet ook je disaster recovery niet goed in te regelen overigens.

het idee is inderdaad om locatie 1 als master te draaien en locatie 2 als uitwijk locatie te gebruiken.

Om dit zelf te beheren / cloud af te nemen bij een bedrijf zullen we kwa kosten moeten gaan bekijken. En onze klanten gaan het niet leuk vinden als we het bij een multinational neer zetten als Azure.

Disaster recovery is al geregeld op moment (zal wel wat aan moeten veranderen straks maar dat terzijde)

bedankt voor je input Question Mark

[Wim-Bart]

Je hebt meerdere keuzes, waarbij clustering het laatste is waar je aan moet denken of je moet er flink wat geld tegen aan gooien. SRM van VMWare is een oplossing, maar dat kost best wel wat om aan te schaffen en te implementeren.

Een andere oplossing is Hyper-V met replication. Server 2012R2 als Hyper-V platform en een VPN tunnel tussen locatie A en B. Met Hyper-V replicatie repliceer je de differntials van locatie A naar locatie B en op het moment dat locatie A plat gaat breng je alles op locatie B op, zelfde principe als VMware SRM.

Het enige nadeel wat je hebt is dat je je externe DNS moet omleiden naar nieuwe locatie. Maar ook dat is op te lossen door een lage zone tijd te nemen.

Wat je ook kan doen is met SRM/Hyper-V replicatie je backend repliceren en op locatie A laten draaien en dan aan de voorkant twee webservers neerzetten, 1 op locatie A en 1 op locatie B en dan gebruik maken van GSLB voor de web services. Maar als je je kan veroorloven om een uur off-line te zijn, dan is de replicatie methode voldoende. Gewoon er voor zorgen dat je dns-tijd laag genoeg is.