[WIN2008] 2 machine's - 1 IP - andere poort

[Verwijderd]

Goede morgen!

Ik zit met het volgende probleem:
We hebben bij het bedrijf waar ik werk momenteel 1 server staan welke 2 database engines bevat (MySQL en MSSQL).
Dit willen we uit elkaar gaan trekken zodat we 1 server met MySQL en 1 met MSSQL hebben draaien.
Dat is op zich geen probleem, dit is al geregeld.

Echter.... We hebben al flink wat gebruikers die hiernaartoe connection dmv een IP adres.
Sommigen gebruiken het interne IP en anderen het externe IP.

Wanneer ik de MSSQL engine naar de andere server zou verplaatsen dan krijgt hij uiteraard een ander IP en zijn alle gebruikers die nu het IP adres ingesteld hebben staan de verbinding kwijt.

Ik wilde het oplossen door op beide netwerkverbindingen van de 2 servers NLB te zetten en het IP adres van de oorspronkelijke server als 'cluster IP adres' te gebruiken en op basis van de poort het verkeer naar de juiste server te sturen.
Alleen vind de NLB dat niet zo leuk als ik op alle netwerk interfaces een NLB-cluster zet, elke keer bij het opstarten komt hij met een smerige foutmelding over UNICAST, dit heb ik al gewijzigd naar MULTICAST, maar de melding bleef en om de haverklap kunnen ze elkaar niet meer vinden en meer van dat soort problemen, daar ben ik dus mee gestopt.

Om een lang verhaal kort te maken:
Ik wil dat server1 en server2 op hetzelfde IP te bereiken zijn en dat de beslissing op basis van de poort wordt gemaakt waar hij uitkomt (voorkeur).
Of: er blijft 1 server met het IP en stuurt al het verkeer via poort 3306 door naar een andere server (liever niet, alleen als het niet anders kan)

[Verwijderd]

Je kunt toch in het register de RDP poorten aanpassen?

3389
3390

ExternIP:3389 server 1
ExternIP:3390 server 2

[ Voor 37% gewijzigd door Verwijderd op 26-10-2010 11:59 ]

[Verwijderd]

Ja, dat kan uiteraard.
Echter zie ik niet zo zeer wat RDP met mijn probleem te maken heeft?

Het probleem is dat ik de IP adressen niet wil/kan wijzigen en toch beide database engines op een aparte server wil hebben.

[aZuL2001]

Waarom moeten de machines op ipadres bereikbaar zijn ? Niemand wil toch allemaal ipadressen moeten onthouden ? Daarvoor hebben we DNS toch ?

Misschien de gebruikers laten omkatten naar mysql.hostname.org en mssql.hostname.org ?
Dan heb je ook in de toekomst flexibiliteit.

Of op je router regelen dat de portforward van mysql op een ander intern ip uitkomt dan mssql ?

[ Voor 23% gewijzigd door aZuL2001 op 26-10-2010 12:18 . Reden: aanvulling ]

[Verwijderd]

Ik zie het probleem echt niet, je kunt dit inderdaad gewoon je NAT table aanpassen in je router... en de juiste
port forwarden naar de juiste server...

[Verwijderd]

@aZuL2001: Dat kunnen we voor in de toekomst wel gaan doen, maar dat helpt de huidige gebruikers helaas niet, er zijn er al te veel die naar het direct IP verbinden om dat van de ene op de andere dag om te gaan gooien.

@cyrillic1: Dat zou inderdaad gaan als we überhaupt een router ertussen hadden zitten, alle servers zijn individueel aangesloten op het internet en het interne netwerk (servers staan in een datacentrum)...

[aZuL2001]

Maar je hebt nu een probleem, waar je toekomstgericht een oplossing voor zal moeten zoeken.

En dat gaat ergens pijn doen. Bij je gebruikers, bij jullie (financieel), maar het zal toch opgelost moeten worden lijkt me. Toch ?

Desnoods ga je bij je klanten langs om het, als service, aan te passen. Heb je gelijk een contactmoment.

[ Voor 18% gewijzigd door aZuL2001 op 26-10-2010 12:33 ]

[alt-92]

Verwijderd schreef op dinsdag 26 oktober 2010 @ 12:26:
@aZuL2001: Dat kunnen we voor in de toekomst wel gaan doen, maar dat helpt de huidige gebruikers helaas niet, er zijn er al te veel die naar het direct IP verbinden om dat van de ene op de andere dag om te gaan gooien.

Nou en?
Je weet (of althans - je hoort te weten) wie je users zijn.
je geeft ze een week van tevoren een heads-up, dag voor je change nogmaals en wie het dan nog niet gewijzigd heeft, heeft dikke pech omdat ze op een non-supported manier hebben zitten te werken.

Botte bijl, inderdaad, maar de enige manier om snel van je IP probleem af te zijn en lekker op FQDN te kunnen werken en jezelf niet meer klem te laten zetten door (semi)illegaal gebruik van je DB server.

[Verwijderd]

Ik snap wat je bedoelt, en als het niet anders is, dan moet dat ook maar.

Ik kan me alleen niet voorstellen dat ik de enige ben dit dit wil.
Windows moet toch in staat zijn om in ieder geval op basis van een poort het verkeer door te sturen?
Of de NLB te laten werken op beide NIC's

[Plague]

Hoewel ik er inhoudelijk weinig verstand van heb lijkt het mij zeer onwaarschijnlijk dat dit zonder tussenkomst van [insert apparaat] mogelijk is. Je connect namelijk in eerste instantie naar een bepaald IP, en 'binnen' dat IP gebruik je een poort. Twee machines met een zelfde IP lijkt mij dan ook onmogelijk: een pakketje 'splits' zich niet, waarna het zich aan beide servers aanbied. Het zoekt de eerste de beste met een bepaald IP, en dan wordt het pakketje doorgelaten of gebounced. Het wordt niet doorgestuurd naar een andere machine met een andere poort.
How about een load balancer/router die je op het originele IP laat draaien, en vanaf daar doorstuurt naar de nieuwe IP's op basis van poort? Voor mijn part een virtuele server. Kost je misschien 200 euro per maand - lijkt mij toch wel te doen.

Kun je vervolgens ook weer besparen op de individuele IP-adressen van alle andere machines. En firewalls, etc.

[ Voor 21% gewijzigd door Plague op 26-10-2010 12:48 ]

[sanfranjake]

Sim-pel: Routertje achter je routertje zetten. Externe interface dit ip geven. Geef beide servers een nieuw ip en een nieuwe NAT-mapping, en opgelost?

Maar de FQDN bespaart je natuurlijk bij toekomstige wijzigingen een hoop ellende en geniet de voorkeur.

[alt-92]

Verwijderd schreef op dinsdag 26 oktober 2010 @ 12:39:
Ik snap wat je bedoelt, en als het niet anders is, dan moet dat ook maar.

Lijkt mij het meest verstandige.

Ik kan me alleen niet voorstellen dat ik de enige ben dit dit wil.
Windows moet toch in staat zijn om in ieder geval op basis van een poort het verkeer door te sturen?
Of de NLB te laten werken op beide NIC's

Je pakt een oplossing in een techniek (een hamer) en probeert nu op zoek te gaan naar een spijker, maar het enige wat je aantreft zijn schroeven en moertjes.
Sowieso ga je IP conflicten krijgen als je het doet, dus wil je al een extra laag complicaties (NLB) gaan introduceren terwijl het stuk gereedschap niet voor dat doel is geschikt.

Je vraagstuk (twee services aanbieden) is eenvoudig genoeg. Beide services lopen op aparte tcp poorten, daar zit het probleem dus niet aangezien beide services op één hostname (!) kunnen draaien.
Koppel het IP verhaal even lost van je vraag.

Zodra je een hostname gaat gebruiken per service - en dat zul je sowieso willen zodra je met kerberos authenticatie aan de gang wil voor je MSSQL Server - kun je jezelf en je gebruikers het makkelijker maken door met een hostname te laten connecten (msdb.tralalie.tralala.tld en mydb.hatsieflatsie.tralala.tld) en heb je alle vrijheid om die machines qua IP om te nummeren indien nodig of zelfs ergens in een datacenter neer te zetten.

Enige wat je hoeft te doen is een DNS wijziging - intern en/of extern naar wens.
En dat allemaal zonder de dienstverlening te raken (zo goed als dan..).

Pech voor diegenen die het op IP doen, want die zorgen ervoor dat jij indien nodig nooit iets kan of mag wijzigen aan je netwerk.
Dat lijkt me nu niet bepaald de meest wenselijke manier.

[ Voor 7% gewijzigd door alt-92 op 26-10-2010 20:42 ]