In-house of ISP housing voor database- en webserver?

[Eelke Spaak]

Ik ben bezig met het ontwikkelen van een database applicatie voor een reisbureau. Er komt zowel een administration client voor de medewerkers (om telefonische reizen in te geven etc.) als een website aan te hangen. Ongeveer 30-40 full-time medewerkers zullen van de applicatie gebruik gaan maken; dit zorgt dus voor flink wat DB-queries naar de server (en resultsets terug).

Er zijn m.i. twee mogelijkheden voor het plaatsen van deze server: bij een ISP of bij het bedrijf zelf. Plaatsing bij een ISP heeft zeer gunstige gevolgen voor de snelheid van de website; de client voor de medewerkers kan dan echter wat laggy worden. Wanneer de server bij het bedrijf komt te staan zal dit de snelheid van de client ten goede komen, maar zal ervoor zorgen dat klanten de website niet met optimale snelheid kunnen benutten.

Ik heb al even onderzocht wat voor internetverbindingen er beschikbaar zijn; wat mij betreft komt er een 2300 kbps SDSL-lijn met 1:1 overboeking te liggen. Mijn vraag is: wat raden jullie aan qua plaatsing en internetverbinding?

edit:
Is dit het goede forum? Zo nee, welke dan wel..?

[ Voor 4% gewijzigd door Eelke Spaak op 03-10-2004 21:50 ]

[jep]

In een Datacenter, natuurlijk. Het kost vreselijk veel geld om een snelle In-house faciliteit op te zetten, en dat heeft ook nog allemaal nadelen. Met een APC en een KVM-switch (over ethernet) kun je zelfs een situatie creeeren waarbij je alleen in het geval van hardware storingen naar je datacenter hoeft.

Kijk wel even goed naar welk datacenter en netwerk je kiest, niet elke locatie is geschikt voor deze serieuze doeleinden.

[CyBeR]

Absoluut in een datacenter. Daar zijn die dingen voor De omgeving in een DC is peperduur om in-house na te maken en een snelle internetverbinding is voor klanten een vereiste. Ze zitten tegenwoordig allemaal op snelle lijnen, een trage website valt dan negatief op. De klanten zijn het belangrijkst: die hebben het geld dat jij wilt hebben

[TrailBlazer]

Ik zal het lekker op een housing lokatie zetten.
* De website heeft een hogere beschikbaarheid
* De housing partner kan eventueel backups voor je draaien
* Gegarandeerde spanning
enkel het lijntje ernaar toe moet je even kijken hoe je dat gaat doet. 2,3 MB SDSL lijkt me prima in orde eventueel kan je ook met QoS zorgen dat het DBase verkeer altijd voorrang krijgt

[Wiggert]

Hoe werkt de client? Is het een windows app?

Ik zou ook voor ISP housing gaan, icm VPN en eventueel Citrix oplossing indien de client niet een webapplicatie is

[Eelke Spaak]

OK bedankt voor de antwoorden! Het wordt dus toch in een datacenter denk ik.

De client voor de medewerkers is een Java-applicatie; geen webapplicatie i.v.m. de eisen voor een rich GUI.

[Verwijderd]

Ik heb wat ervaring met een soortgelijke constructie. De database (MySQL) draait in een datacenter en de werknemers raadplegen deze database via een clientapplicatie die lokaal draait. Over en weer gaan alleen SQL queries en dat werkt perfect. Prima performance, zelfs met een huis/tuin/keuken ADSL-verbinding.

Succes!

[Verwijderd]

Datacenter, duidelijk: zie bovenstaande redenen.

Om het laggy zijn van de verbinding zou ik me niet druk maken, de tweakers.net databases die zéér zwaar worden belast doen @ max nog geen 5mbit/s. Tel daarbij op dat je met een xdsl maximaal een 15ms van je server afzit (binnen NL, met fatsoenlijke providers) en ik zou voor het laggy zijn van de app niet al te bang zijn

[Bigs]

Als de client 100% lokaal draait en er dus alleen databaseverkeer over de verbinding naar het datacenter gaat dan zou ik gewoon voor de datacenter oplossing kiezen (en anders waarschijnlijk ook). Waarschijnlijk valt de lag reuze mee, ook met een wat minder dure verbinding (1:1 overboeking lijkt me een beetje overkill)

[Verwijderd]

Bigs schreef op 04 oktober 2004 @ 01:53:
Als de client 100% lokaal draait en er dus alleen databaseverkeer over de verbinding naar het datacenter gaat dan zou ik gewoon voor de datacenter oplossing kiezen (en anders waarschijnlijk ook). Waarschijnlijk valt de lag reuze mee, ook met een wat minder dure verbinding (1:1 overboeking lijkt me een beetje overkill)

Inderdaad: van die overboeking merk ik zelf niks.... KPN houdt 1:45 aan voor consumenten, maar ik haal _altijd_ me max. Als je een SDSL 1:25 of een 1:10 hebt lijkt me dat zat VPNtunnel eroverheen naar de server en klaar

[djluc]

Waarom niet ook een lokale server? Met behulp van database replicatie kan je er voor zorgen dat je gegevens op beide servers up-to-date blijven. Dit is zelfs mogelijk met je applicatie via bepaalde software. Valt je internet verbinding uit zal je geen probleem hebben, alleen zijn de gegevens op de website niet meer geheel actueel. Mocht de server bij de host kuren vertonen zou je zelfs nog tijdelijk op de lokale server je site kunnen hosten.

[Verwijderd]

djluc schreef op 04 oktober 2004 @ 17:00:
Waarom niet ook een lokale server? Met behulp van database replicatie kan je er voor zorgen dat je gegevens op beide servers up-to-date blijven. Dit is zelfs mogelijk met je applicatie via bepaalde software. Valt je internet verbinding uit zal je geen probleem hebben, alleen zijn de gegevens op de website niet meer geheel actueel. Mocht de server bij de host kuren vertonen zou je zelfs nog tijdelijk op de lokale server je site kunnen hosten.

Dan is een tweede dsl lijn denk ik goedkoper Desnoods een consumentenlijn als backuplijn, dan heb je ook zekerheid

[djluc]

Verwijderd schreef op 04 oktober 2004 @ 18:17:
[...]Dan is een tweede dsl lijn denk ik goedkoper Desnoods een consumentenlijn als backuplijn, dan heb je ook zekerheid

Met als verschil dat je ook het voordeel hebt van een lokale server. Uiteraard kan deze voor meerdere doeleinden gebruikt worden.

[CyBeR]

djluc schreef op 04 oktober 2004 @ 22:05:
[...]
Met als verschil dat je ook het voordeel hebt van een lokale server. Uiteraard kan deze voor meerdere doeleinden gebruikt worden.

Nadeel is dat je niet kunt garanderen dat de data op beide servers actueel is. Wat in dit geval wel handig is, lijkt me.

[Johnny]

Eelke Spaak schreef op 03 oktober 2004 @ 22:17:
OK bedankt voor de antwoorden! Het wordt dus toch in een datacenter denk ik.

De client voor de medewerkers is een Java-applicatie; geen webapplicatie i.v.m. de eisen voor een rich GUI.

offtopic:
Als je verstand van zaken hebt kun je de meest ingewikkelde GUI's maken in een webapplicatie met Java Applets, Flash/Director, DHTML of XUL, dus het is niet zo'n goede reden die je daar noemt.

[ Voor 8% gewijzigd door Johnny op 05-10-2004 01:30 ]

[Eelke Spaak]

Johnny schreef op 05 oktober 2004 @ 01:29:
[...]

offtopic:
Als je verstand van zaken hebt kun je de meest ingewikkelde GUI's maken in een webapplicatie met Java Applets, Flash/Director, DHTML of XUL, dus het is niet zo'n goede reden die je daar noemt.

Mja, maar ik denk dat dit type GUI zich toch echt veel beter leent om door een applicatie geïmplementeerd te worden. Er is namelijk behoefte aan een desktopframe met veel inner frames en dergelijke. Om dit allemaal 'na' te gaan maken met een webapplicatie geeft mij iets teveel codewerk .

En ja, met een Java applet kan je op GUI-gebied in principe hetzelfde als met een Java applicatie, maar een applet mag bijvoorbeeld al niet rechtstreeks verbinding maken met een database-server. Daar komt nog eens bij dat een Java applet nou niet echt een webapplicatie is; meer een applicatie die toevallig op een webpagina is geplakt.